docs(remediation): pre-register RM-02 narrowing review — N2 asks if the honesty control is itself honest
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]>
This commit is contained in:
mos-dt-0
co-authored by
Claude Opus 5
Claude Opus 5
parent
d9207d4c1a
commit
dde38717dd
@@ -0,0 +1,59 @@
|
||||
# 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.json` and in
|
||||
`scripts/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).**
|
||||
Reference in New Issue
Block a user