mos-dt-0andClaude Opus 5
86cd1a0f46
Mos ruled BLOCKING on the exit_code type confusion. Both of us had leaned non-blocking on the
unreachability argument and neither shipped it. The two decisive grounds: the direction is
wrong-ACCEPT (false and 0.0 GRANT the exemption), which is this mission's disqualifying direction and
exactly why RR12 was tolerable; and "Woodpecker is Go with an int type" is structurally the same
incidental-correlate argument RM-61 itself forbade for the signature — you cannot certify the
discriminator against infra-shift and then defend a hole in it with an infra-stability assumption.
Generalised into an RM-02 standing clause, which is the real prize: discriminator and comparison
inputs must be TYPE-STRICT. A comparison that accepts a type it should not is a wrong-ACCEPT hole by
construction; `== 0` matching False and 0.0 is one instance of a class. D-40 is the instance, the
clause is the fix. It sits alongside the D-38 clause (does this gate bind its evidence to its subject).
D-39b banks the roles-swapped half: the author does not adjudicate its own PR's blocker status and
does not move the head to enforce it. Symmetric with D-39 — a seat with a stake in the answer does not
settle the question, and a conservative motive exempts neither direction.
ACs are registered NOW, before coder-mos1 pushes and before any reviewer reads a diff; at registration
the fix exists only as an unpushed local commit I have not read, so there is no diff to retrofit to.
They also state explicitly which cases are genuine RED-FIRST (false, 0.0 — currently wrongly exempting)
and which are only regression guards ("0", null — already blocking), because demanding an impossible
red for the latter two invites weakening something real to manufacture it.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
6.1 KiB
RM-61 / PR #1033 — PRE-REGISTERED ACCEPTANCE CHECKS: exit_code TYPE-STRICTNESS (D-40)
Registered by: mos-remediation (orchestrator) — BEFORE the fix was pushed and before any
reviewer read a diff. At registration time the fix existed only as an unpushed local commit
(6e7a336d) on coder-mos1's machine which I have not read. There is therefore no diff for these
checks to have been retrofitted to.
Subject head: TBD — binds to the NEW head once coder-mos1 pushes. The prior head
033b2ffb46674b2c0bcc5197273c109b461f62d9 and its review 69 / pipeline #2193 go VOID on that push;
that cost was accepted deliberately by Mos's BLOCKING ruling on D-40.
Ruling being enforced (Mos, 2026-08-01): exit_code must be accepted ONLY as a real integer.
false, 0.0, "0", and null must all fail to satisfy the exemption. Wrong-ACCEPT is the
disqualifying direction; this hole sits inside the load-bearing discriminator.
⚠ Read this before writing the tests — RED-FIRST HERE IS NOT UNIFORM
Two of the four near-miss values already block at 033b2ffb. Demanding "all four observed RED
first" would be demanding an impossible red for two of them, and the predictable response to an
impossible demand is a fudge — weakening something real to manufacture the red. So state it precisely:
| value | behaviour at 033b2ffb (pre-fix) |
what the new case is |
|---|---|---|
false |
WRONGLY EXEMPTS (exit 0) | genuine RED-FIRST |
0.0 |
WRONGLY EXEMPTS (exit 0) | genuine RED-FIRST |
"0" |
correctly blocks (exit 1) | regression guard only |
null |
correctly blocks (exit 1) | regression guard only |
Claiming red-first for "0" or null would be a false claim about your own evidence. Say which is
which. Do not weaken anything to make a green case go red (D-8).
Checks
| id | check | verdict form |
|---|---|---|
| TS1 | ★RED-FIRST. exit_code: false on the real #2188 record is observed wrongly exempting at 033b2ffb (exit 0, exempted_steps 1), then blocks after the fix |
pre-fix ⇒0/exempt 1 · post-fix ⇒1/exempt 0 |
| TS2 | ★RED-FIRST. Same for exit_code: 0.0 |
pre-fix ⇒0/exempt 1 · post-fix ⇒1/exempt 0 |
| TS3 | REGRESSION GUARD. exit_code: "0" blocked before AND after — state honestly that it was already green |
both ⇒1, exempted_steps 0 |
| TS4 | REGRESSION GUARD. exit_code: null blocked before AND after |
both ⇒1, exempted_steps 0 |
| TS5 | ★NOT OVER-TIGHTENED. The genuine artifact — real #2188, real integer exit_code: 0, correctly bound head — still passes |
⇒0, exempted_steps 1, exactly one WP-K8S-1000-CI-POSTGRES-TEARDOWN |
| TS6 | The strictness sits on the value the EXEMPTION rests on, not on a cosmetic sibling. Show the guarded comparison is the one feeding exemption_applies |
reviewer quotes the line |
| TS7 | bool is excluded EXPLICITLY, not incidentally. A bare isinstance(x, int) still admits True/False — verify the not isinstance(x, bool) clause exists |
⇒ clause present; true also blocks |
| TS8 | Negative control unaffected: a genuine failed step with a real integer non-zero exit still blocks | ⇒1, exempted_steps 0 |
| TS9 | NO REGRESSION ON THE PRIOR ROUND'S BINDING WORK: mutated record commit ⇒1; --expect-commit omitted ⇒2; record commit absent ⇒1 |
⇒1 / ⇒2 / ⇒1 |
| TS10 | Signature conjunction NOT widened elsewhere by this fix — POD_NOT_FOUND / name / type / state untouched |
diff-scoped ⇒ no widening |
| TS11 | Still no fetch / trigger / retry / re-roll / sleep / network | grep ⇒ no call sites |
| TS12 | Full harness passes at the new head; state the case count (12 previously, expected 16 — confirm the actual number rather than the expected one) | ⇒0, count stated |
Reviewer instruction
Verdict bound to the NEW head, evidence enumerated per check, CI counts from pipeline-status.sh -f json
(never default text — it omits clone, D-33). If a check is unrunnable, say so; never substitute a
passing variant.
Attack outside this set and report what you find. Both blockers on this PR so far — the missing commit binding, and this type confusion — were found outside the registered set, by mutating a field nobody had registered a check for. That is now the expectation, not a bonus.
Nobody dispatching this review may state a conclusion on an open check here (D-39). If you are sent an observation, it is an observation; the ruling is yours.