Source: This page and docs/case_studies/vault-memory-github-session-2026-04.md are kept in sync; edit both when the narrative changes.

Case study: Vault memory ingest, GitHub tracking, and shipping enterprise audit (April 2026)

A multi-turn working session in Cursor: ingesting external and assistant-generated content into the ClawQL MCP memory_ingest / memory_recall Obsidian vault, prioritizing GitHub work, opening tracking issues, and delivering a concrete feature slice (audit tool, #89) plus docs / Helm / website wiring.

Audience: Operators and contributors who use vault memory for long-running context, GitHub for execution, and want a repeatable pattern for "ingest → prioritize → issue → implement."

---

1. Why this session mattered

Long-horizon product work generates more context than any single chat can hold: vendor analyses, roadmap essays, ecosystem posts, and cross-session prioritization. Without a durable store, you re-argue the same design every week. This session used the vault as the system of record for that material, then used GitHub as the system of execution — issues, epics, and shipped code.

The three durability tiers in play:

---

2. Narrative timeline (April 2026)

1. Ingest wave: External threads (Grok cross-checks, Agent vision, gRPC/Gallery notes) landed in the vault with stable titles and often append: true so related updates consolidated rather than fragmenting.
2. Tracker sync: Open issues were listed, deduped, and extended — iac_inspect duplicate closure (#39 → #69), new epics #88–#91 for gateway, enterprise tools, synthetics, Gallery downstream work.
3. Prioritization: Among schedule/notify/vision (#76–#78), memory epics (#68), docs/evals (#70–#71), docs site (#87), and new items, the group picked #89 for a vertical slice with a clear acceptance condition: one enterprise tool shipped end-to-end.
4. Implementation: audit — design doc, code, tests, Helm/K8s/env/docs/site/Cursor skill — through to npm test green.

---

3. What was ingested into the vault (memory_ingest)

Structured insights plus verbatim or summarized conversation blocks were stored under stable titles (append-friendly) so Obsidian [[wikilinks]] and memory_recall stay useful:

Prefer memory_ingest for durable decisions; use cache() only for session scratch the user asked not to persist. Use wikilinks to connect roadmap ↔ GitHub issue notes ↔ architecture sketches so memory_recall with maxDepth can pull related pages, not only keyword hits.

---

4. GitHub: issues created and housekeeping

Gallery issues are disabled on the fork; #91 in this repo tracks downstream PRs.

Tracking duplicates explicitly reduces split-brain prioritization and keeps search / execute automation aligned with a single canonical thread per topic.

---

5. Prioritization snapshot (session)

Open work included #76–#78 (schedule, notify, vision), #69 / memory epics, #87 (docs site), #88–#91 (new). The suggested order discussed: dedupe iac_inspect (done), optional tools #76 → #77 → #78, memory under #68, docs #70 / eval #71, public gateway when ready.

The session picked #89 for implementation because it was scoped to ship something observable in MCP + Helm + docs — a forcing function for the optional-tool plumbing (CLAWQL_ENABLE_*, chart values, website tables) that future enterprise tools (metrics, governance) reuse.

---

6. Why audit was the right vertical slice

The enterprise epic needed a first tool with specific properties. It had to be off by default so existing deployments saw no surprise behavior. Operators needed to list recent events without SSHing to grep logs. The ring buffer plus CLAWQL_AUDIT_MAX_ENTRIES kept storage bounded — no silent unbounded log file on disk. And the tool's threat-model language paired naturally with docs/mcp/enterprise-mcp-tools.md.

audit covers runtime MCP events. The vault covers human-readable narrative. The two stores serve different purposes and neither substitutes for the other.

---

7. Work completed: enterprise audit (#89)

1. Design: docs/mcp/enterprise-mcp-tools.md — flags, threat model, future metrics / governance.
2. Code: src/clawql-audit.ts — append / list / clear; unconditional registration in src/tools.ts; optional flags in src/clawql-optional-flags.ts cover other tools.
3. Tests: src/clawql-audit.test.ts, extended optional-flags + stdio smoke (src/server.test.ts).
4. Docs / env: docs/mcp/mcp-tools.md, .env.example, README.md, CHANGELOG.md.
5. Ops: docs/deployment/deploy-k8s.md, docs/deployment/helm.md — audit is ClawQL Core (no Helm/env toggle).
6. Website & Cursor: site copy (website/src/app/tools/page.mdx, related MDX), .cursor/skills/clawql-vault-memory/SKILL.md — clarifies audit vs vault.

npm test green before merge.

---

8. Optional tools: audit vs cache vs vault

---

9. Helm and website wiring

Docs and Helm describe audit as ClawQL Core (alongside search / execute, always on, no opt-out) so docs.clawql.com matches the diagram and the server's tool list.

---

10. Outcomes and follow-ups

---

11. References

• MCP tools: mcp-tools.md
• Enterprise design: enterprise-mcp-tools.md
• Vault memory skill: integrations/cursor-vault-memory.md
• Issues: #88–#91, #89

© Copyright 2026. All rights reserved. · ClawQL on GitHub