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).**