diff --git a/docs/remediation/AC-RM02-REBASE.md b/docs/remediation/AC-RM02-REBASE.md new file mode 100644 index 00000000..66c8dfa2 --- /dev/null +++ b/docs/remediation/AC-RM02-REBASE.md @@ -0,0 +1,71 @@ +# RM-02 / PR #1030 — PRE-REGISTERED ACCEPTANCE CHECKS (post-rebase, keystone) + +**Subject head (exact):** `83d2ecb2243f1b0987ef2bc14de47f444285a684` +**Rebased onto:** `main` @ `f4fd5967fc5d4cbc72d680b199d88224aa855131` (post-RM-61) +**Registered by:** `mos-remediation` **BEFORE the reviewer read the diff.** **Reviewer:** `rev-974` +(author ≠ reviewer; branch commits are `f10-coder`'s and `coder-mos1`'s). +**Prior reviews 63 / 65 are SUPERSEDED; this head carries NO live review of any kind.** + +RM-02 is the **keystone**: it is the anti-inert-gate registry every downstream gate is measured against. +A defect that survives here propagates into every gate this mission ships. + +## ★ CRUX — the one non-mechanical change, made by the author, that turned a red green + +The rebase was clean. One further commit was **not** purely mechanical and the author disclosed it +unprompted (`83d2ecb2` — advance registry activation seam): + + gates/gates.manifest.json + - "activationCommit": "f65e9ea656ec466e12640bf6ab5d46fe07ff160c" + + "activationCommit": "f4fd5967fc5d4cbc72d680b199d88224aa855131" + +Stated rationale: after the rebase, `pnpm gate:verify` correctly failed because the newly-merged +pre-registry RM-61 commit was treated as _prospective_ and required a manifest that could not exist. + +`activationCommit` sets the lower bound of `activationCommit..HEAD` — **the set of commits required to +carry own-tree registry provenance** (`gate-history.mjs:314` → `listProspectiveCommits`). Advancing it +**shrinks that set**. + +**Determine, do not assume — and I have deliberately formed and stated no verdict (D-39):** + +| id | check | +| ------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| **A1** | **Is the advance JUSTIFIED?** Can a pre-registry commit on `main` (e.g. `f4fd5967`) satisfy the provenance requirement at all, or is requiring it impossible-by-construction? If impossible, is advancing the seam the _correct_ remedy, or does a correct remedy exist that does not move an author-controlled field? | +| **A2** | **Is the advance MINIMAL?** Was it advanced exactly to the new parent baseline, or beyond it? Does any commit that _should_ remain covered fall outside the new range? | +| **A3** | **Are all 7 branch commits still PROSPECTIVE under the new seam?** Enumerate them and show each is still required to carry provenance. The author claims "own-tree provenance over every registry-era branch commit" — verify the claim, do not accept it. | +| **A4** | ★★ **IS THE SEAM ITSELF CONSTRAINED?** The only validation found is `merge-base --is-ancestor activationCommit head` (`gate-history.mjs:288`). **A commit is its own ancestor.** Determine what `activationCommit = HEAD` does: is the prospective range empty, does the per-commit loop iterate zero times, and does the history check therefore PASS VACUOUSLY? If so, the anti-inert-gate registry contains an author-settable field that can inert its own history check. **Run it. Report the observed exit and whether any failure is raised.** | +| **A5** | **If A4 shows vacuity is reachable, is there a registered MUST-FAIL negative control for it?** RM-02's own founding rule is that a gate with no proven failure path manufactures evidence. Does the registry hold a case that goes RED when the seam is over-advanced? If not, that is a hole in the registry's coverage of itself. | +| **A6** | **Self-verification shape (charter / D-19 / D-39b):** the field was advanced by the change's own author to make the author's gate pass. Independent of whether the value is correct, determine whether the _mechanism_ permits an audited party to relax its own audit, and whether that needs a constraint, an owner, or an escalation. | + +## Registry substance — the clauses this PR must now carry + +| id | check | +| ------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| **B1** | **D-38 clause present and enforced:** the registry asks of every gate _"does this gate BIND its evidence to the subject under review?"_ Ruled in-scope for THIS PR by Mos. Verify it exists as a checked clause, not prose. | +| **B2** | **D-40 clause present and enforced:** _"discriminator and comparison inputs must be TYPE-STRICT."_ Also ruled in-scope for THIS PR. `== 0` matching `False`/`0.0` is the banked instance; the clause is the general form. | +| **B3** | **D-42's clause is CORRECTLY ABSENT** — provider-side negative control tracks separately (Mos: landing it now would give the registry a clause with nothing to satisfy it, going red on its own clause). Confirm its absence is deliberate and recorded, not forgotten. | +| **B4** | **The four founding clauses still hold** (`MISSION.md`): every check proven **right** (red for its own stated reason), the set **covers**, no two criteria **conflict**, and criterion evolution **retains original text + restatement + reason**. | +| **B5** | **Nothing was weakened, skipped, or deleted by the rebase.** Diff `f9746b23` → `83d2ecb2` and confirm no registered case, test, or assertion was removed or relaxed to make the rebase land. | +| **B6** | **`coverageBoundary.excluded[]` is honest in BOTH directions** (charter principle 4): what it does NOT cover is stated beside what it DOES, and the gap is tracked (`trackedBy: RM-54`) rather than implied-fixed. | +| **B7** | **The RM-02 execution boundary** (`gate-history.mjs`, DOES / DOES NOT, owner RM-60, xref RM-59) states its limits in both directions and names a tracked owner — not a documented gap with no owner. | + +## Head + CI (re-run these; do not carry them forward from the author's report) + +| id | check | +| ------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| **C1** | Head `83d2ecb2…` on **both** git and provider; `Closes #1029` present in the body (delivery-issue rule, D-38c). | +| **C2** | Exact-head CI terminal-green by **full `-f json` scan**, counts stated **including `clone`**. Note the count changed 9 → **10** (this PR adds `gate-verify`) — confirm the new step is real, not a miscount. | +| **C3** | **Machine-check it, do not assert it:** `verify-terminal-green.py --expect-commit 83d2ecb2243f1b0987ef2bc14de47f444285a684`. Report exit, `exempted_steps`, `commit == expected_commit`. | +| **C4** | `exempted_steps=0` is expected here — `ci-postgres` succeeded, so the #1000 exemption was **not needed**. Confirm the exemption is present-but-unused rather than silently inapplicable. | + +## Reviewer instruction + +Verdict bound to `83d2ecb2243f1b0987ef2bc14de47f444285a684`, evidence enumerated per check, posted +durably under your own identity. If a check is unrunnable, **say so** — never substitute a variant that +passes. Scan CI from `-f json`, never default text (D-33); state your counts. + +**A4 is the check I most want an answer to and the one I have least confidence about.** Attack outside +this set as well: every blocker found on this mission so far came from mutating something nobody had +registered a check for. + +**No one dispatching this review may state a conclusion on an open check (D-39).** Observations may be +relayed to you; verdicts may not. The ruling is yours.