# 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.