From 995f8b6a24a898a6d387ee187654f79bc558e4e4 Mon Sep 17 00:00:00 2001 From: mos-dt-0 Date: Sat, 1 Aug 2026 10:24:24 -0500 Subject: [PATCH] docs(remediation): pre-register RM-02 keystone review ACs before the reviewer reads the diff MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Registered at head 83d2ecb2 before dispatch. Prior reviews 63/65 are superseded and this head carries no live review of any kind, so the keystone gets a full independent review. The crux is the one non-mechanical change, which f10-coder disclosed unprompted: activationCommit advanced f65e9ea6 -> f4fd5967 so that the newly merged pre-registry RM-61 commit is no longer treated as prospective. activationCommit sets the lower bound of the commit range required to carry own-tree registry provenance, so advancing it SHRINKS that set. The value is plausibly correct — a pre-registry commit cannot carry a registry manifest — but the change was made by the author to turn the author's own gate from red to green, which is the self-verification shape the charter warns about. Registered as A1-A6 without a verdict from me (D-39). A4 is the sharp one: the only validation on the field is merge-base --is-ancestor activationCommit head, and a commit is its own ancestor, so setting activationCommit = HEAD would empty the prospective range and the per-commit provenance loop would iterate zero times. Whether that makes the history check pass VACUOUSLY is for rev-974 to determine and report — an author-settable field that can inert the anti-inert-gate registry's own history check would be the disease inside the cure again. A5 asks whether a must-fail negative control exists for it, since RM-02's own founding rule is that a gate with no proven failure path manufactures evidence. B1/B2 carry Mos's scope ruling that the D-38 bind-to-subject and D-40 type-strict clauses land in THIS PR; B3 confirms D-42's clause is deliberately absent rather than forgotten. Co-Authored-By: Claude Opus 5 (1M context) --- docs/remediation/AC-RM02-REBASE.md | 71 ++++++++++++++++++++++++++++++ 1 file changed, 71 insertions(+) create mode 100644 docs/remediation/AC-RM02-REBASE.md 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.