Files

T

mos-dt-0andClaude Opus 5 e2058d4e84 docs(remediation): pre-register RM-02 anchor-round review — A1/P2 ask if the control point moved again

Registered at fbb61912 before any reviewer read the diff. I reproduced three things first so the review
does not re-spend on them: the derived boundary equals an independently computed git merge-base HEAD
origin/main (f4fd5967 — the same value f10-coder once set by hand, now derived rather than asserted);
emptying the registry populations fails with the precondition's own language; the both-directions
bootstrap statement is present with the Builds 1-2 residual.

A1 and P2 are the sharp ones and they ask the same question the last two rounds answered badly: did the
fix REMOVE the author's control point or MOVE it? A1 — refs/remotes/origin/main is a local ref; who
controls it where the gate runs, and can an author rewrite remote.origin.url or craft that ref in their
own clone? P2 — the seven required gate IDs are an anchor list; if the author can edit it, that is D-45
one level in. A4 asks about the natural failure mode of this fix, over-inclusion causing false reds.

P3 independently confirms the production fixture-profile bypass the author found and removed in their
own pre-commit review — self-disclosed, so it gets verified rather than credited.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>

2026-08-01 12:43:01 -05:00

8.2 KiB

Raw Blame History

RM-02 / PR #1030 — PRE-REGISTERED RE-REVIEW: the merge-base anchor round

Subject head (exact): fbb61912981abb250d289ec7aafd4316db6fdb11 Supersedes: the second NO-GO at 32b490a7 (D-45/D-46/D-47). That verdict is VOID. Registered by: mos-remediation before any reviewer read the diff. Reviewer: rev-974.

What the orchestrator already reproduced (do not re-spend the review here)

Derived boundary f4fd5967 equals an independently computed git merge-base HEAD origin/main.
Emptying criteria/gates/proseClaims/compatibilityScenarios now fails with "population must be non-empty and anchored before evaluation".
The both-directions bootstrap statement is present in gate-history.mjs with the Builds 1–2 residual.

A — attack the ANCHOR (highest value)

id	check
A1	`targetRef` is the literal `refs/remotes/origin/main`. Who controls that ref in the environment where the gate runs? Can a PR author influence it — a `remote.origin.url` rewrite, a crafted `refs/remotes/origin/main` in their own clone, a push to a fork's `main`? If the gate trusts a locally-writable ref, the anchor moved from the manifest into git config.
A2	Absent/stale target: if `refs/remotes/origin/main` is missing, stale, or the fetch is shallow, does it fail CLOSED (line 57 suggests it does) or silently derive a narrower range?
A3	Delayed introduction — the round-2 attack, re-run. Commit a gate change BEFORE adding the manifest. Does it now stay in range and fail the own-tree read?
A4	Branch from an old main: branch from a point far behind `origin/main`, so merge-base is old. Does the range widen correctly (safe) or include unrelated main commits that cannot carry manifests (a new false-red)? Over-inclusion is the natural failure mode of this fix.
A5	Is the bootstrap residual recorded as a tracked dependency on Builds 1–2, not prose? (D-19's third mandatory move.)

P — the non-empty/anchored precondition

id	check
P1	Does the precondition run before every quantified check, on every path — or only the ones the author enumerated? Find a quantified check that still runs before its precondition.
P2	Seven required gate IDs anchored to canonical sources — can that anchor list itself be emptied, shrunk, or pointed elsewhere? An anchor list the author edits is D-45 again, one level in.
P3	The author reports finding and REMOVING a production CLI fixture-profile bypass in their own pre-commit review. Verify it is gone from the shipped CLI path, that the remaining relaxation is test-support only and non-executable in production, and that the CLI rejection is tested. This was self-disclosed — confirm it independently.

Q — clauses quantified over the population (D-47)

id	check
Q1	`gateRefs` exactly spans every registered gate. Can a gate be added WITHOUT a corresponding ref — i.e. does adding a gate to the population escape the clause?
Q2	Deleting `gateRefs`, or shrinking gates and refs together, must fail. Shrink-together is the D-46 shape; verify it is a genuine control and not a regression guard mislabelled.
Q3	Do the population controls iterate all seven gates and mutate evidence-subject and comparison-type per gate, or only a representative one?
Q4	Honest labelling: author claims delayed-introduction, empty-populations, fixture-profile bypass and removable gateRefs as genuine red-first, and shrink-together/exact-span as regression guards. Verify each claim against pre-fix code (D-8).

C — head, CI, integrity

id	check
C1	Head `fbb61912` on git and provider; `Closes #1029` present.
C2	Exact-head CI terminal-green, full `-f json`, counts stated incl. `clone`; machine-checked with `verify-terminal-green.py --expect-commit fbb61912981abb250d289ec7aafd4316db6fdb11`.
C3	Nothing weakened: `32b490a7` → `fbb61912` removes/relaxes no existing case, test, or assertion.

Reviewer instruction

Verdict bound to fbb61912981abb250d289ec7aafd4316db6fdb11, evidence enumerated, posted durably under your own identity. If a check is unrunnable, say so.

A1 and P2 are the ones I most want answered — both ask whether the fix moved the author's control point again rather than removing it, which is now the mission's named first-class principle and has recurred three times. Attack outside this set.

No one dispatching this review may state a conclusion on an open check (D-39).

8.2 KiB Raw Blame History Unescape Escape