mos-dt-0andClaude Opus 5
dde38717dd
Registered at e910a45a before any reviewer read the diff. Verified first, so the set does not re-spend:
the narrowing sentence is verbatim in both the baseline and its control; the overclaim control fires
(clean exit 0, injected "protected, independently anchored" exit 84 INVENTORY_CLAIM_OVERSTATED); CI
2201 is 10/10 with the machine check bound and clean. D-48's failure mode is now mechanically caught.
N1 and N2 are the sharp checks. N1: the control only inspects the files it inspects, so is the claim
honest everywhere else — docs, comments, observations, CLI output? N2: the overclaim control is itself
PR-controlled, so can it be weakened or reworded so an overstatement passes? If it can, D-52 is re-armed
one level down, which is the recursion this PR has produced at every round. N3 asks whether it detects
semantic overclaim or only literal strings.
H2 and H3 re-check the two traps I found in the code by reading it, because they are the way (d) turns
back into a green: emitting the unverifiable state as an observation exits 0, and coverageBoundary
exclusion is declared rather than enforced. H4 requires the corrected residual, not the D-48 wording.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
6.4 KiB
6.4 KiB
RM-02 / PR #1030 — PRE-REGISTERED RE-REVIEW: honest narrowing + (d)-strict
Subject head (exact): e910a45ab3578a9c77ad3eeaa52b31b72611f6c6
Supersedes: the third NO-GO at fbb61912 (D-45/D-46/D-47) and the D-52 stop. Those are VOID.
Registered by: mos-remediation before any reviewer read the diff. Reviewer: rev-974.
Already reproduced by the orchestrator (do not re-spend here)
- The required narrowing sentence is verbatim in
gates/required-gates.baseline.jsonand inscripts/gate-inventory-claim-control.mjs: "Detects accidental and incompetent inventory drift within a checkout; does NOT survive an adversary who rewrites baseline, manifest, and verifier consistently — that guarantee requires RM-60's external boundary." - The overclaim control FIRES: clean ⇒ exit 0; injecting "protected, independently anchored" into
the baseline purpose ⇒ exit 84,
INVENTORY_CLAIM_OVERSTATED. - CI #2201 at the exact head, 10/10 incl.
clone; machine check bound,exempted_steps 0, no anomalies.
N — the narrowing (D-52's ruling is the wording)
| id | check |
|---|---|
| N1 | ★ Is the narrowed claim honest EVERYWHERE, or only where the control looks? Find any place — docs, comments, observations, manifest prose, CLI output — that still implies the baseline is protected or independently anchored. The control only checks the files it checks. |
| N2 | ★ Can the overclaim control itself be defeated? It is PR-controlled like everything else. Weaken/skip/reword it so an overstatement passes. If it can be trivially neutered, D-52 is re-armed one level down — the exact recursion this PR keeps producing. |
| N3 | Does the control detect semantic overclaim or only the literal strings it greps? An artifact could assert protection in different words and pass. |
| N4 | Is the narrowed claim TRUE? Verify the baseline genuinely catches accidental/inconsistent drift — not just that it says so. A narrowed claim that is still overstated is D-48 again. |
H — (d)-strict history removal
| id | check |
|---|---|
| H1 | Is the verifier structurally incapable of reporting history-provenance-verified, or merely not currently doing so? The manifest says "structurally incapable" — test the claim. |
| H2 | ★ TRAP 1 re-check: nothing emits the unverifiable state as an OBSERVATION (which exits 0). Confirm no path yields exit 0 while implying provenance was considered. |
| H3 | ★ TRAP 2 re-check: the exclusion is enforced, not merely declared in coverageBoundary.excluded. Re-enable history provenance without a trustworthy anchor — does a registered case go RED? |
| H4 | The residual is stated correctly — no local git state is trustworthy because PR code executes before the gate — NOT the D-48 wording ("compromised main"). |
B3 / R — evidence-subject and renderer
| id | check |
|---|---|
| B1 | Subject is on the EVIDENCE side and compared at consumption, not gate.evidenceSubject === gate.id metadata-vs-itself. Mutate the evidence-side subject per gate. |
| B2 | Can evidence still be moved or misbound while every gate satisfies its check? |
| R1 | Renderer now covers the final success stdout/stderr paths. |
C — integrity + CI
| id | check |
|---|---|
| C1 | Head e910a45a on git + provider; Closes #1029 present. |
| C2 | Exact-head CI terminal-green, -f json, counts incl. clone; machine-checked with --expect-commit e910a45ab3578a9c77ad3eeaa52b31b72611f6c6. |
| C3 | Nothing weakened fbb61912 → e910a45a. Red-first labels honest (D-8). |
| C4 | NO fourth local anchor was invented. Blocker 1 and blocker 2's adversarial guarantee both track RM-60. |
Reviewer instruction
Verdict bound to e910a45ab3578a9c77ad3eeaa52b31b72611f6c6, evidence enumerated, posted durably.
Unrunnable ⇒ say so. N1 and N2 are the sharp ones — this PR's history is that every fix
relocates the defect one level down, and N2 asks whether the control that enforces honesty is itself
honest. Attack outside the set: six for six so far.
No one dispatching this review may state a conclusion on an open check (D-39).