From e2058d4e8404d9217918bac5c6447b15695f434f Mon Sep 17 00:00:00 2001 From: mos-dt-0 Date: Sat, 1 Aug 2026 12:43:01 -0500 Subject: [PATCH] =?UTF-8?q?docs(remediation):=20pre-register=20RM-02=20anc?= =?UTF-8?q?hor-round=20review=20=E2=80=94=20A1/P2=20ask=20if=20the=20contr?= =?UTF-8?q?ol=20point=20moved=20again?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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) --- docs/remediation/AC-RM02-ANCHOR.md | 58 ++++++++++++++++++++++++++++++ 1 file changed, 58 insertions(+) create mode 100644 docs/remediation/AC-RM02-ANCHOR.md diff --git a/docs/remediation/AC-RM02-ANCHOR.md b/docs/remediation/AC-RM02-ANCHOR.md new file mode 100644 index 00000000..deb4b8bc --- /dev/null +++ b/docs/remediation/AC-RM02-ANCHOR.md @@ -0,0 +1,58 @@ +# 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).**