Files
stack/docs
mos-dt-0andClaude Opus 5 495cb6a1fb docs(remediation): D-38c — PR metadata failed a THIRD time on #1033; delivery-issue gap ruled
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]>
2026-08-01 09:48:16 -05:00
..