Silent truncation in the seg-store loader · found, fixed, and gated · 2026-07-25
The board every workstream reads to decide what to eat disagreed with itself. Measured, not inferred:
| Reader | Rows visible | Newest debt |
|---|---|---|
nx_debt list | 125 | 2026-07-18 — 7 days stale |
nx_debt_view | 734 | 2026-07-23 |
nx_seat boot | 668 open | today, sev 9 |
sts_load reads a single count key q:n and loops seq < cnt. When q:n is stale the loader stops early with no error and no flag. The plane held 734+ rows across 629 segments while q:n resolved to 125 — so nx_debt list printed total=125 as fact.
It was self-reinforcing: add and eat rewrite the whole plane from that partial buffer, driving q:n low again on every call. The tool used to file debt was the tool destroying it.
sts_load_honest() loads identically but also reports declared_qn, loaded, and unreachable_beyond_qn, and prints a DEBT-TRUNCATED-LOAD banner when a listing is partial. sts_load itself is left byte-identical — the whole reader family links it.
q:n truncates silently; a too-high q:n is harmless, because misses are skipped. So probing past the declared count can detect the gap but cannot corrupt the plane.
q:n belong to an older generation — loading them would duplicate live rows and revive eaten ones as open.
The existing bulk-load gate already built the exact corruption as a fixture (seed 5 rows, re-seed 3, leaving two rows reachable past q:n). Two teeth were composed onto it rather than writing a second gate:
T1 single-seg-identical PASS T2 supersede-newest-wins PASS T3 shrink-stale-invisible PASS T4 absent-plane-zero PASS T5 compare-non-vacuous PASS T6 honest-detects-unreachable PASS declared=3 loaded=3 unreachable=2 T7 honest-no-false-positive PASS healthy plane reports 0 NX-STS-BULKLOAD-GATE pass=7/7 verdict=GREEN
T6 asserts exact values, not merely non-zero. T7 is the anti-vacuity control: an always-on detector would pass T6 and fail T7. Executed live over tools/call, status=200 exit_code=0.
q:n would revive eaten rows as open.Three times during this work the careful check reversed the answer. A file listing truncated by a tooling cap produced a confident but wrong root cause. The obvious recovery would have corrupted the board. An empty-plane test looked green while proving nothing.
An instrument that truncates silently reports its own blindness as fact. That is why unreachable_beyond_qn exists.
Related, same subsystem: platform stability — store handles are opened without a close path.