#1032 merged 58b971ab and #1019 closed, both verified by property. RM-03 is delivered to main. And the
guard that actually executes on this host is unchanged: installed 291 lines with ZERO occurrences of
ASSERTED_NOT_READY, main 482 lines with five. Differing SHA-256. Measured, not inferred — the installed
guard contains none of the tri-state logic.
This is the install-drift disease the postmortem indicts, caught in the act on the mission's own fix.
Every completion signal is green — merged PR, closed issue, terminal CI, merge-gate GO — and the defect
is still live in the thing that runs. D-23's origin was an assumed-propagated-but-didn't guard; this is
that origin reproduced by the delivery of its own remedy.
Merge is not delivery for tool changes. Rules banked from Mos: propagate only via the canonical path
(mosaic upgrade / deploy pipeline), never a hand-copy that could diverge while appearing to fix it; the
installed guard stays zero-information until re-sync, so every state=unknown exit 0 this mission logged
remains correctly uncited; and on re-sync VERIFY THE PROPERTY by running the installed guard against a
known-red pipeline to confirm it exits non-zero and blocks. Closing this by assuming the upgrade worked
would reproduce D-23 a third time.
Generalises: every framework/tool change this mission delivers has the same main-to-installed gap. It
belongs on the completion checklist for tool-affecting tasks and mechanically on RM-63 — the same
systemd-service architecture that mechanises rotation also mechanises propagation.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
