Files
stack/docs/remediation
mos-dt-0andClaude Opus 5 1aedf32523 docs(remediation): RM-03 gate-ready, RM-02 round 4 to coder-mos2
RM-03 #1032 freshened onto post-RM-61 main and re-cleared at 868b9b87: review 74 APPROVED bound to the
exact head, CI 2199 9/9 including clone, mergeable true. The deliverable is proven against production
rather than asserted — rev-974 invoked the exact-head ci-queue-wait.sh itself against isolated provider
fixtures and got exit 3 with ASSERTED_NOT_READY on terminal failure, no-status, malformed payload and
an indeterminate neutral status, plus timeout 124 on pending. D-23 said the guard returns pass for
every possible input; that is now false at this head. Merge-gate assigned, Jason's approval standing.

My own spot-check went further than the range-diff I asked for: ci-queue-wait.sh and pr-merge.sh blobs
are byte-identical across the old approved head and this one, so no guard implementation moved in the
rebase — the only delta is commit 1's additive test enumeration, a union preserving both sides.

RM-02 round 4 dispatched to coder-mos2, a fresh dedicated identity at 0.5% context, so no D-41
manual-respawn problem. I asserted its capability differentially before dispatch per my own D-11b
addendum rather than accepting it on report: authenticated push True, unauthenticated False.

Its brief carries the two traps I found by reading the code, both binding, because the first is how
anyone would naturally build (d): emitting the unverifiable state as an observation exits 0, and
coverageBoundary.excluded is schema-validated but not enforced. The claim goes away rather than being
annotated, and the exclusion needs a must-fail control or it is a gate with no proven failure path.
It also carries the CORRECTED residual — no local git state is trustworthy because PR code executes
before the gate — not the D-48 wording three of us approved.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
2026-08-01 13:55:29 -05:00
..