Epic: Dev-Memory Dogfood Loop
Roadmap item 3 of brehob-launch · parallel to items 2→4, invested, not thin (Dan's steer 6/10: load-bearing quality flywheel, not just API-hardening) · → North Star B3/B6; realizes the platform thesis (self-documenting dev-memory) on ourselves.
Objective
Every session ends by writing what happened and why into an Autri KB; every session begins by retrieving it. The compounding loop: session quality → product quality → compounds across the whole Brehob build. First real consumer of the consumable API (item 2), on a corpus we own — and that corpus is unstructured prose, so it exercises exactly the keyword-metadata + Haiku-grouping path Brehob needs, on our data first.
Security boundary (locked 6/10)
The dev-memory KB lives in a restricted library. Session transcripts will carry Brehob pricing, contract terms, and customer detail. Collaborator access (e.g. Jack, scoped to Foundry/lower-stakes work) must be grantable WITHOUT exposing this library — which the item-2 library-scoped keys give us by construction.
Work breakdown
- S1 — Episode format. A turn-by-turn session summary + the decisions made + their rationale, as structured prose. Design rule (carried feedback): embed at the semantic unit, display at the readable unit — don't compromise chunk size to serve both; the episode format should give the chunker natural semantic seams (decision blocks, topic turns).
- S2 —
/stophook integration. The stop skill generates the episode and POSTs it through the consumable API with a dev-memory-scoped key. Mechanical parts in deterministic code; the LLM writes only the semantic summary (carried principle: LLM does semantics, code does mechanics). - S3 — Library + key provisioning. The restricted library, its key, and who holds it.
- S4 — Session-start retrieval.
/start(and ad-hoc queries mid-session) search dev-memory: "have we decided this before?", "why did we pick X?". This is where the flywheel actually engages. - S5 — Backfill past sessions. Parse historical transcripts → episodes → ingest. Fallback ①: this story defers to post-go-live if sizing busts the window — the loop compounds forward without it.
- S6 — Quality check. A fresh session must retrieve the rationale for known past decisions (author ~10 gold queries from real history: "why did we keep Haiku grouping?", "why vend before corpus load?"). If retrieval misses, that's signal for item-1 tuning — which is the point of dogfooding.
Acceptance
A cold session answers "why" questions about past decisions from retrieval alone (S6 gold queries pass). Episode ingestion exercises the unstructured path with keyword metadata. A non-privileged key provably cannot read the dev-memory library.
References
DB-4 (promoted, the flywheel rationale — see the resolved brehob-launch annotation thread for the full argument), item-2 API (hard dependency), platform thesis (project_autri_platform_thesis).