mos-dt-0andClaude Opus 5
e2058d4e84
Registered atfbb61912before 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]>
59 lines
8.2 KiB
Markdown
59 lines
8.2 KiB
Markdown
# 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).**
|