docs: cite all three diagnostic runs; record (g) — the window is bounded

[YinkaMetrics]

Summary

HANDOFF.md + the diagnostic's STATUS block. Internal tier — self-merges.

Promotes the missing citations, records (g), and corrects a framing error of mine from the previous entry.

The full seven-arm picture, now with sources

Arm	Outcome	Detail	Results file
(a)	RE_ADD_VISIBLE	0s, 4 reads, 5 units	…_1785797173.json
(b)	RE_ADD_VISIBLE	0s, 4 reads, 5 units	…_1785797173.json
(c)	RE_ADD_VISIBLE	0s after 60s settle	…_1785797173.json
(d)	RE_ADD_VISIBLE	—	…_1785800147.json
(e)	RE_ADD_VISIBLE	—	…_1785800147.json
(f)	WRITE_LOST	never retrievable, 25 reads / 120s	…_1785828208.json
(g)	WRITE_VISIBLE	0s after 60s settle, 3 reads, 4 units	…_1785828208.json

(f) LOST + (g) VISIBLE resolves the fork

Matches the branch stated in advance for transient reaping:

• The reaping window after delete_all is real — polling until empty is not sufficient, which is exactly what reset() did before e7e89dc.
• It is bounded — a 60s settle cleared it completely, write retrievable at 0s.
• delete_all stays usable as a reset primitive, provided the caller verifies writability rather than trusting emptiness. That's what the sentinel does, and this is the evidence it converges.

Every per-key arm passed; the one delete_all arm failed. Six arms across three executions isolate the mechanism to the namespace-wide delete.

Correcting my own framing

The previous entry said (f) shows "the condition persisting for at least 120s". That reads as a claim about the window, and it isn't one.

(f) polls a single already-swallowed write. Such a write is dead permanently, so 120s of polling measures how long we waited — not how long the store reaps. (g) is the only bound on the window, and it bounds it from above at 60s. The lower bound is still unmeasured.

Corrected in a new entry rather than edited in place, since the previous entry is merged and public.

Sizing: still not guessing

_CONVERGE_TIMEOUT stays at 30s. The window lies in (0s, 60s], and the sentinel's retry procedure differs from the arm's single-write one. empty_to_writable_s — emitted on every deleting reset since e7e89dc — measures it directly, under the right procedure. First real run settles it.

The 003 abort — terminal-reported, no results file

Provenance: memorycheck run scenarios --adapter mem0 --seeds 2, founder's Mac, 2026-08-03, terminal output only. Aborted at op #26 — 003-scope-boundaries seed 0, write, 31.20s. Cited as terminal-reported, and the entry states plainly that no JSON exists for it.

One inference, marked as inference. Op counts are structural — fixed by the scenario pack, not the provider. On that ordering 003-scope-boundaries seed 0 occupies ops 25–29, with op 25 the reset and op 26 the scenario's first write. So the abort landed on the first write immediately after a reset — precisely the (f) condition. 31.20s also sits just past the adapter's 30s write-convergence ceiling, consistent with a swallowed write rather than a slow one.

For that reset to have deleted at all, the namespace must have held residue (e.g. re-running after an earlier aborted run). That fits — but it is not measured: the run predates the [reset] logging, so nothing recorded whether that reset took the delete path. The next run answers it directly.

Verification

pytest -q: 71 passed, 4 skipped. py_compile clean.

Not publishable yet

One execution per arm. The harness-side story is evidenced end to end, but whether this mechanism caused the 012/003 aborts is still unproven — the op #26 inference is suggestive and cheap to confirm on the next run.

External launch remains HELD.

---

Generated by Claude Code