Measured against the register before acting, and the item survives in direction but not
in numbers or remedy.
Option (d) has been authorized since 2026-07-19 — Stroke 4 of the register's own
authoritative head block — and simply never executed; Stroke 2, the ~25-30 entry
verification-ladder batch-append, is authorized and unexecuted in the same slot.
But Stroke 4's method ("ruled items collapse to verdict lines") cannot achieve the goal:
of 190 table rows, 13 are ruled and 177 are open. Collapsing every ruled row removes ~7%
of the file. The register is not large with settled history; it is large with open
proposals, so the prescribed remedy leaves it over the cap and the loop still broken.
The item's counts are unreliable and so were mine until I stated an inclusion rule; with
one stated, 123 PROPOSED / 8 BUILT / 4 AUTHORIZED over table rows. The item's own
falsifier is not triggered — 166,589 bytes, 177 open, oldest 2026-05-24 — so the
diagnosis stands and only the arithmetic needs restating.
Newly found: one section spans 411 lines and 58% of the file while carrying 33 distinct
dates from 2026-05-24 to 2026-07-19. Five weeks of wrap-appends landed in an existing
section rather than new dated ones, so the register misreports its own chronology and
§1.6's append step is silently mis-filing.
Proposed method, on the MEMORY.md precedent that already worked (213KB -> 17KB): a live
index of open proposals plus a detail archive, ~19 KB, lossless in the working tree,
compacting by form rather than by dropping items. Proposed and not applied: Stroke 4
authorized compaction, not this method, and restructuring the surface that decides what
reaches the steward is PROPOSAL-class by the item's own test.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01WuMjg3ipEVa3n8CoSzoyvc
