Merge-gate NO-GO with every code and CI gate verified, including the --expect-commit machine-check it
was told to exercise (9/9 JSON, exempted_steps 0, expected_commit == commit). The blocker was the body:
only "Refs #1000", no "Closes #N", and Mosaic completion requires a linked issue closed.
Third distinct metadata failure on one PR — missing commit binding, then a stale DO-NOT-MERGE body
describing a dead head, now an incomplete link. Each time the code was fine and the metadata was
unbound, stale, or incomplete. Nothing re-binds PR metadata to the head or checks it for completeness
until a gate does, and by then it costs a round trip.
The subtlety that makes it a real ruling: #1033 must NOT Closes#1000. The teardown defect stays open,
and #1000 is the exemption's own retirement trigger — auto-closing it would delete the retirement
trigger for the workaround being merged, turning a bounded exemption into a permanent one by side
effect. Hence a delivery issue distinct from the defect issue: #1034, with Closes#1034 added and
Refs #1000 kept.
Metadata-only, head never moved: verified by read-back that head is still 57cae04f, Closes#1034
present, Refs #1000 present, Closes#1000 ABSENT, review 70 still CURRENT with zero live
REQUEST_CHANGES, #1034 open. coder-mos1 stayed parked; nobody pushed.
Process gap ruled by Mos: every remediation delivery PR needs a delivery issue to Close, created at
OPEN-TIME rather than discovered at gate-time. #1032 already Closes#1019; #1033 had none.
Both provider writes went through the tea->API fallback — the same path that silently dropped #1033's
draft property at creation — so both were read back and verified by property, not by exit code.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>