docs(remediation): scope rulings banked; D-43 elevated onto RM-34 — the control plane has no verifier

SCOPE (Mos): D-38 (bind evidence to subject) and D-40 (type-strict discriminator inputs) land IN the
RM-02 PR — cheap registry-coverage clauses, satisfiable now, and RM-02 literally IS the registry, so
codifying what its own delivery learned about how gates fail is the coherent move.

D-42 splits, and the reason is sharper than "needs experimentation": landing its clause in-PR today
would give the registry a clause with NOTHING to satisfy it, so the registry would go red on its own
clause and couple the keystone's landing to infra work. Wrong coupling. So (a) the infra experiment
proving the pin enforces via the negative case, in Mos's D-37/D-41/D-42 cluster; (b) the registry
clause "provider-side enforcement requires an OBSERVED negative control", in a follow-up RM-02
increment once (a) gives it something to check. Named owner, not a vacuous check and not a silent
omission.

D-43 point 3 elevated to the PRIMARY requirement on RM-34, with the table that makes it plain: code has
rev-974, gates have the merge-gate, CI has the JSON scan, and the control plane has NOTHING. Every
other layer earned a verifier from a live failure; the board never did, and it is the artifact every
other decision is staged from. "Validate the checkpoint" must mean re-derive the board's claims from
ground truth — not that the file parses or that a successor can read it. It belongs to the
coordinator-daemon deliverable: the control plane needs its own verifier the way every other layer got
one. Today's catch was discipline, not mechanism.

Interim rule binding on BOTH seats until that mechanism exists, and Mos adopted it against himself:
re-derive a board claim from ground truth before any load-bearing use. The orchestrator does it before
dispatch; the coordinator does it before acting on or relaying a board claim that gates a decision.

D-11b addendum: the false-NEGATIVE twin. /user returns 403 on a least-privilege seat token (no
read:user) and reads exactly like an unprovisioned seat. The real assertion is the DIFFERENTIAL —
authenticated push=true vs unauthenticated push=false proves the token caused the difference. A single
endpoint can be true for anyone or refused for an unrelated scope reason. Would have escalated a
working seat as unprovisioned and stalled the keystone on a phantom.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>

docs/remediation/TASKS.md

@@ -534,6 +534,30 @@ board against reality.** Every other artifact on this mission has an independent
 **RM-34** ("a handoff must VALIDATE the checkpoint"): validation must include **re-deriving the board's
 claims from the provider**, not merely confirming the file parses or that a successor can read it.
 
+> **★★ ELEVATED — THE PRIMARY REQUIREMENT ON RM-34 (Mos, 2026-08-01). THE CONTROL PLANE IS THE ONE
+> UNVERIFIED SURFACE IN THE ENTIRE ARCHITECTURE.**
+>
+> | layer             | independent verifier               |
+> | ----------------- | ---------------------------------- |
+> | code              | `rev-974` (author ≠ reviewer)      |
+> | gates             | the merge-gate seat                |
+> | CI                | the full `-f json` step scan       |
+> | **control plane** | **NONE — sole-written, unchecked** |
+>
+> Every other layer earned a verifier from a live failure. The board never did, and it is the artifact
+> every other decision is staged from. **RM-34's "validate the checkpoint" therefore means RE-DERIVE THE
+> BOARD'S CLAIMS FROM GROUND TRUTH** — not "the file parses", not "a successor can read it". This
+> belongs to the **coordinator-daemon deliverable (Build 3)**: the control plane needs its own verifier
+> the way every other layer got one.
+>
+> Today the re-derivation happened **only because the orchestrator chose to**. That is **discipline, not
+> a mechanism** — and this mission's thesis is that discipline without a mechanism eventually fails.
+>
+> **INTERIM RULE, binding on BOTH seats until the mechanism exists (Mos adopted it against himself
+> too):** re-derive a board claim from ground truth before any **load-bearing** use of it. The
+> orchestrator does so before dispatch; **the coordinator does so before acting on or relaying a board
+> claim that gates a decision** — Mos noted he had relayed board-derived state to Jason all session.
+
 ### D-42 — the head-pin is an enforcement mechanism whose NEGATIVE CONTROL has never been observed
 
 `merge-gate.md` states it directly: **a successful merge is NOT evidence the pin worked.** Only the
@@ -557,6 +581,24 @@ enforcement mechanisms**, not only in-repo checks. A gate whose enforcement live
 a gate, and "the API accepted our parameter" is not evidence the API _honours_ it — the same
 true-answer-to-a-different-question shape as D-24 and D-38.
 
+> **★ SCOPE RULING (Mos, 2026-08-01) — D-42 SPLITS IN TWO, and not merely because it needs
+> experimentation.** If D-42's clause landed in the RM-02 PR today it would have **nothing to satisfy
+> it** — no provider-side negative control for the pin exists yet — so **the registry would go red on
+> its own clause**, coupling the keystone's landing to infra work. That is the wrong coupling.
+>
+> - **(a) INFRA EXPERIMENT** — prove the pin enforces on mosaicstack Gitea via the **negative case** (a
+>   wrong `head_commit_id` must be refused). Sits in the **D-37 / D-41 / D-42 cluster, owned by Mos.**
+> - **(b) REGISTRY CLAUSE** — _"provider-side enforcement requires an OBSERVED negative control"_ —
+>   lands in a **follow-up RM-02 increment ONCE (a) gives it something to check.**
+>
+> A documented gap **with a named owner** — neither a vacuous check nor a silent omission.
+
+> **★ SCOPE RULING — WHAT LANDS IN THE RM-02 PR ITSELF (Mos, 2026-08-01):** the **D-38** clause (does
+> this gate bind its evidence to the subject?) and the **D-40** clause (are discriminator/comparison
+> inputs type-strict?) **land IN the current RM-02 PR.** They are cheap registry-coverage clauses, they
+> are satisfiable now, and **RM-02 literally IS the registry** — codifying in the registry what the
+> registry's own delivery just learned about how gates fail is the coherent move.
+
 ### D-38c — PR metadata failed a THIRD time on the same PR, and the process gap behind it
 
 The merge-gate returned **NO-GO on `#1033`** with every code and CI gate verified — including the
@@ -1598,6 +1640,21 @@ lands as RM-04 at a non-critical seam, or immediately if any seat needs a tea-on
 capability registry. It is **necessary but not sufficient**. Capability is **per-path**: the token file
 governs the raw-API path, the tea login governs the tea path, and the two can disagree silently.
 
+> **★ D-11b ADDENDUM — THE FALSE-NEGATIVE TWIN (found 2026-08-01, banked by Mos).** D-11b warns against
+> the false POSITIVE: a token file that proves nothing. The mirror error is just as costly. Asserting
+> `f10-coder` before an RM-02 dispatch, the orchestrator probed `/api/v1/user` and got `login: None` —
+> which reads exactly like an unprovisioned seat. It is not. The seat token is **least-privilege**
+> (`write:issue,write:repository`, **no `read:user`**), so `/user` returns **403 by design**.
+>
+> **The real assertion is the DIFFERENTIAL, not any single endpoint:** authenticated repo permissions
+> return `push: true` while **unauthenticated returns `push: false`** — that gap proves **the token
+> caused the difference**. A single-endpoint read can be true for anyone (false positive) or refused for
+> a scope reason unrelated to the capability (false negative).
+>
+> **RULE: a capability probe must assert the differential.** Without it, this would have escalated a
+> perfectly working seat to the coordinator as unprovisioned — burning a provisioning round trip and
+> stalling the keystone on a phantom.
+
 ### D-12 — a requested SAFETY flag was silently degraded, and I did not check
 
 I created PR #1027 with `pr-create.sh ... -d` (draft) because it carries **partial, unproven work**.