# RM-02 / PR #1030 — PRE-REGISTERED RE-REVIEW: the four-blocker hardening pass **Subject head (exact):** `32b490a712a5e8e77f13c40c60099b51feb38994` **Supersedes:** the NO-GO at `83d2ecb2` (D-44, four silent-defeat paths). That verdict is VOID. **Registered by:** `mos-remediation` **before any reviewer read the diff.** **Reviewer:** `rev-974`. ## Framing — attack the FIX, not the original bug Every round on this mission, **the remediation introduced the next hole**: the commit-binding fix shipped a type confusion; the type-strict fix was clean but the registry around it had four defeats. So the highest-value checks here are **not** "was each blocker fixed" — the orchestrator already reproduced three of the four attacks as dead — but **"is the NEW mechanism itself defeatable?"** Blocker 1's fix replaced an author-settable field with a **derivation**. A derivation has inputs. **The question is who controls them.** ## H — the new derivation (highest value) | id | check | | ------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **H1** | `deriveHistoryBoundary` = parent of the first first-parent commit introducing `gates/gates.manifest.json`. **Are its inputs author-controlled?** Can a PR author influence the derived value by adding, moving, renaming, deleting-and-recreating, or symlinking that path — or by adding a SECOND manifest earlier in history? If the derivation is gameable, blocker 1 is not fixed, only relocated. | | **H2** | **First-parent traversal:** what happens on a merge commit, an octopus merge, a squash, a rebase that reorders, or a branch where the introducing commit is not on the first-parent chain? Does the boundary silently move, or fail closed? | | **H3** | **Shallow/partial clone:** the branch previously needed an unshallow fix (`e8959975` "unshallow gate replay history"). If history is shallow, does the derivation fail CLOSED or silently derive a wrong/empty boundary? | | **H4** | **Path deletion:** if `gates/gates.manifest.json` is absent at HEAD, or was deleted and re-added, what is derived? Fail closed, or a boundary that excludes the deletion window? | | **H5** | Are the **three registered seam controls (HEAD, HEAD^, introduction) genuinely RED-FIRST** — do they fail against the PRE-fix code for their own stated reason? A control that was always green is a regression guard, not a must-fail control (D-8). | ## S — the recursive schema closure | id | check | | ------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **S1** | **Is closure COMPLETE or enumerated?** The author lists the objects they closed. Find one they did **not** — any nested object anywhere in the manifest — and inject an unknown key there. If it is accepted, the fix covers instances, not the class. | | **S2** | **Wrong-type, not just unknown-key:** `outputPattern` as a number/array/object/null rather than misspelled. Does the closed schema type-check values, or only key names? | | **S3** | **Empty/degenerate values:** `outputPattern: ""` — does an empty regex match everything and silently neuter the assertion the same way a typo did? The author claims an empty-pattern control; verify it is bound. | | **S4** | Confirm the registered typo/wrong-type/empty-pattern controls are **genuine red-first** against pre-fix code, and that anything labelled a regression guard is honestly labelled as one. | ## E — provider evidence (blocker 4) | id | check | | ------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **E1** | Global validation runs **before** per-commit filtering **on every path**, including the HEAD-only path the author calls out. Is there any code path that reaches per-commit assessment without it? | | **E2** | **Duplicate identity by another key:** the fix makes pipeline NUMBER globally unique. Can two records still collide on a different identity dimension — same commit + different number, same URL, same step-id — and certify the wrong subject? | | **E3** | "Exactly one gate-verify step per record" — what if a record has zero, or two with different outcomes? Fail closed? | ## C — clauses, integrity, CI | id | check | | ------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **C1** | The three new criteria (`RM02-EVIDENCE-SUBJECT-BINDING`, `RM02-TYPE-STRICT-SCHEMA`, `RM02-HISTORY-BOUNDARY`) are **checked criteria with bidirectionally bound cases**, not prose. Orchestrator observed caseRefs 1 / 3 / 3 — verify the bindings actually run and can fail. | | **C2** | **B1/B2 satisfied in substance:** does `RM02-EVIDENCE-SUBJECT-BINDING` express D-38 generally ("does this gate bind its evidence to its subject?") or only the one pipeline-number instance? Same for D-40 vs the one typo instance. **A clause that only covers its originating instance is not a clause.** | | **C3** | **Nothing weakened:** diff `83d2ecb2` → `32b490a7` removes/relaxes no existing case, test, or assertion. | | **C4** | Exact-head CI terminal-green, full `-f json`, counts stated **including `clone`**; machine-checked with `verify-terminal-green.py --expect-commit 32b490a712a5e8e77f13c40c60099b51feb38994`. | | **C5** | `Closes #1029` still present (D-38c). | ## Reviewer instruction Verdict bound to `32b490a712a5e8e77f13c40c60099b51feb38994`, evidence enumerated, posted durably under your own identity. If a check is unrunnable, **say so** — never substitute a passing variant. **H1 and S1 are the two I most want answered**, because they ask whether each fix closed a **class** or an **instance**. Attack outside this set: four of the last five blockers on this PR came from mutating something nobody had registered. **Environment note:** `pnpm gate:verify` fails on `checkout-preflight` with outcome 42 (bubblewrap class) in at least one worktree. If you hit it, report it as an environment limitation — do not treat it as a finding, and do not let it mask one. **No one dispatching this review may state a conclusion on an open check (D-39).**