This isn’t meant to be a tidy ending. mem-local is built to admit what it doesn’t know yet, so the honest way to close this timeline is with what’s still unresolved, still deferred, or only half-answered — not rounded off into a finished story.
The read-trigger tension
The write side got a firm rule early: propose, then approve. The read side never got an equally clean answer, and it’s the highest-leverage open question in the whole project because of what happens if it’s wrong in either direction.
The settled default is auto-fire one project-snapshot query when a conversation enters a known project, then manual @mem thereafter — cheap, predictable, and it directly serves the “shape of a project” gap named all the way back in 01-origin-and-requirements. But that default has a named failure mode that isn’t hypothetical: it’s the mirror image of the write side’s own known trap. “This is the same trap as proposal fatigue on the write side. If the manual pull is a clunky tool invocation you have to phrase carefully, you won’t do it, and the unused-memory failure creeps back in through the side door.” A store nobody queries is, in practice, a store that doesn’t exist, and unlike a write mistake, an under-retrieval failure is quiet — nothing errors, nothing looks wrong, the conversation just carries on slightly worse-informed than it could have. The mitigation settled on was a cheap, memorable manual trigger (a sigil like @mem <what>) rather than trying to detect the gap automatically, but whether that’s actually enough friction-reduction to stop the quiet failure from happening in practice is not yet proven — it’s a bet, not a closed decision.
The companion half of the same decision — framing retrieved entries as reference, not instruction so a query result can never read as something to obey — is more settled, and doubles as the read-side half of the prompt-injection defence covered in theme-human-approval-write-gate.
Is SKILL.md actually self-sufficient?
As of the last consolidation, the project’s own stated next action is to find out — not by inspection, but by taking @mem into other, unrelated projects and treating every stumble (recall confusion, not knowing how to capture something, reaching for context that isn’t there) as a defect in SKILL.md to route back and fix. This is deliberately the outsider-read done for real rather than imagined: a system whose own author already knows all its unstated assumptions can’t judge whether the operating document actually carries them. The answer isn’t known yet. A by-exception manual, covering whatever turns out to be too heavy for SKILL.md itself, is explicitly ordered after this validation rather than before it — you can’t document a system whose operating doc hasn’t been checked against someone who doesn’t already know it.
Historical semantic search — deferred on purpose, not by accident
The live path only holds a vector for the current graph — supersede an entry and its vector is evicted, not carried forward. Anything superseded drops to keyword-only (FTS) retrieval, tagged plainly as retrieval_mode: historical/keyword-only so the degradation is visible rather than a silent surprise. This is a genuine capability gap against graph-first, full-temporal-embedding systems, and it was named as the one disadvantage worth taking seriously — not the no-auto-capture or no-multi-hop-traversal gaps, which were declined on purpose because they solve problems that don’t exist here. (The eviction policy itself, and why it replaced an earlier “retain everything” design, is covered in Stage 2.)
The actual plan for closing this gap already has a name and a home — Path 2, deliberate-invocation local compute on the RX 6600 XT over a read-only replica of the store, re-embedding retained assertion text on demand rather than keeping every historical vector forever. It’s decided, not hypothetical. It’s also, as of this writing, not built — mem-local’s own internal Stage 2 is where it lives (the same naming clash flagged in Stage 2 of this timeline: two different countings sharing a number), and it stays deliberately off the live MCP path so the eviction policy’s benefit is never quietly undone by an automatic historical query. The harder problem flagged for whenever it does get built isn’t the re-embedding itself, it’s the evaluation: the existing golden set only knows how to judge current-state retrieval, and a historical query’s “right answer” depends on which date you’re asking as-of. Ship this without a matching eval and it’ll return confident nonsense that feels like it works.
Hard deletion — left open by design
Append-only is built to never remove a row. A genuine erasure — for something that shouldn’t have entered the store at all — has to be able to do exactly that, and the two requirements are in direct tension. The honest scope of the problem, flagged before any sensitive content goes anywhere near the store: the blast radius of a real deletion is wider than the one row asked for, since it has to reach any survivor row that absorbed a merged duplicate’s content or aliases, plus the FTS, vector, and same-as derivatives built from it. This is explicitly parked rather than solved, with the condition attached: settle it before anything genuinely sensitive enters the store, not after.
What this stage is, honestly
Every other stage in this timeline describes something that got decided. This one describes what’s still being carried — not because the project stalled, but because pretending these were settled would be exactly the kind of false precision the whole system was built to refuse. The register’s own discipline — say “owed,” not silently assumed, if it hasn’t actually been checked — applies here as much as it does to any single decision.
Sources: Project planning and workflow development, 18 Jun 2026 (Decision A/A2, read-trigger and framing); mem-local e2 (next_action — validate SKILL.md), e29 (open question — SKILL.md self-sufficiency); register decisions I, T, U (Path 2 / RX 6600 XT, historical search, chat:ai-memory-system-oversight-2026-07-20); Decision needed on attached documentation, 29 Jun 2026; register Decision H (hard deletion). Note on sourcing: the earlier, unpublished notes memory-system-differentiation-and-historical-search-decision describes an earlier version of the historical-search plan (retain every embedding rather than evict) that the register shows was struck the same day it was proposed — superseded by the eviction-plus-Path-2 design described above, not a live alternative.