mos-dt-0andClaude Opus 5
995f8b6a24
Registered at head83d2ecb2before 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 advancedf65e9ea6->f4fd5967so 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) <[email protected]>
72 lines
10 KiB
Markdown
72 lines
10 KiB
Markdown
# 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.
|