Ran Phase A's classifier against the frozen EMB-7KJ4VR4G archive. Since the
fleet shares one devbox image this is a reasonable prior for tor-ms22 and
MBP-M1-2020:
mined (source_file set) 15949 98.9% re-mine, never replay
diary entries 116 0.7% replay + §7.6 suffix skip
agent-authored drawers 60 0.4% replay, idempotent
KG open facts 34 -- server guard dedupes
KG closed facts 0 -- nothing to do
Two consequences that shrink this project: the replay-only surface is 176
records, not thousands, so the writer is a small job and the §7.6 diary guard
treated as the blocker governs 116 records; and there are ZERO closed KG facts,
so the unguarded-closed-fact gap is real in the code but empty in the data.
filed_at spread in the same archive -- 12 in May, 52 in June, 15174 in July, 887
in August -- is the concrete argument for the history-preserving regime.
Two corrections to the first draft:
1. CLOSETS were omitted entirely. mempalace_closets is a second Chroma
collection (1560 rows, ~10% of the palace) and there is NO MCP tool that
writes one -- mcp_server.py exposes only _purge_source_closets, and
closet_llm.py says outright that regex closets are always created by the
miner. So closets cannot be replayed even in principle; they return only by
re-mining. Same category as hallways/known_entities/palace-graph, and it
resolves itself for the ~99% that gets re-mined anyway.
2. Census gotcha: chroma.sqlite3 holds BOTH collections, so an embeddings-wide
query over-counts by ~10%. Must join segments->collections and keep
mempalace_drawers. Doing so reconciles exactly: 14,778 = the 14,777 seeded to
the primary + the one known post-snapshot chunk.
Also drops the earlier "438 of 14,829" figure, which conflated central's
no_source count (which includes its own later agent writes) with the archive's
actual replay surface.
Joakim Persson
2f9170428c