Context
Sub of #13624 (axis 3 of the 3-axis decomposition — see issuecomment-4758705660). This is the operator's "room for future corruptions + new daemons" thread, surfaced as @neo-opus-grace's V-B-A finding (2026-06-20).
Authorship note: this ticket captures @neo-opus-grace's finding so it's tracked per the operator's "we need the tickets now" directive — assigned to her to refine with the exact insert-paths + the guard-twin design. Created by Vega from her A2A; grace owns the substance.
The Problem (per @neo-opus-grace's V-B-A)
Graph-node inserts to the live Memory-Core graph are unguarded under any non-UNIT_TEST_MODE run. The existing safety guards are destructive-only (deleteCollection + guardProductionWipe) — there is no insert twin. So a future daemon, a bad migration, or new code can write corrupting/garbage nodes into the live graph with no guard, no validation gate, no production-write protection. As the orchestrator gains daemons (the #13624 arc), this is the latent corruption surface.
The Fix (direction — @neo-opus-grace to refine)
A symmetric insert/write guard twin for the destructive guards — a production-write protection / validation gate on the graph-node insert path (mirroring guardProductionWipe's shape for the write/insert direction). Exact insert-paths, the guard contract, and the UNIT_TEST_MODE interaction: grace's V-B-A to specify.
Acceptance Criteria (seed — @neo-opus-grace to refine)
Out of Scope
- Session-summary churn/marker (#13637, axis 1) + miniSummary throughput (#13638, axis 2). This axis is purely the insert-guard / corruption-prevention surface.
Related
Parent epic: #13624 (axis 3). Surfaced by @neo-opus-grace's V-B-A (A2A, 2026-06-20). Existing destructive guards: deleteCollection, guardProductionWipe.
Origin Session ID: a0f40f62-6d2f-4f83-b035-9a6342ec9fdc
Retrieval Hint: "graph-node insert guard twin unguarded production-write guardProductionWipe #13624 axis-3"
Context
Sub of #13624 (axis 3 of the 3-axis decomposition — see issuecomment-4758705660). This is the operator's "room for future corruptions + new daemons" thread, surfaced as @neo-opus-grace's V-B-A finding (2026-06-20).
The Problem (per @neo-opus-grace's V-B-A)
Graph-node inserts to the live Memory-Core graph are unguarded under any non-
UNIT_TEST_MODErun. The existing safety guards are destructive-only (deleteCollection+guardProductionWipe) — there is no insert twin. So a future daemon, a bad migration, or new code can write corrupting/garbage nodes into the live graph with no guard, no validation gate, no production-write protection. As the orchestrator gains daemons (the #13624 arc), this is the latent corruption surface.The Fix (direction — @neo-opus-grace to refine)
A symmetric insert/write guard twin for the destructive guards — a production-write protection / validation gate on the graph-node insert path (mirroring
guardProductionWipe's shape for the write/insert direction). Exact insert-paths, the guard contract, and theUNIT_TEST_MODEinteraction: grace's V-B-A to specify.Acceptance Criteria (seed — @neo-opus-grace to refine)
UNIT_TEST_MODE(twin of the destructive-op guard).UNIT_TEST_MODE.Out of Scope
Related
Parent epic: #13624 (axis 3). Surfaced by @neo-opus-grace's V-B-A (A2A, 2026-06-20). Existing destructive guards:
deleteCollection,guardProductionWipe.Origin Session ID: a0f40f62-6d2f-4f83-b035-9a6342ec9fdc Retrieval Hint: "graph-node insert guard twin unguarded production-write guardProductionWipe #13624 axis-3"