diff --git a/docs/remediation/TASKS.md b/docs/remediation/TASKS.md index 3f87abd4..765d907e 100644 --- a/docs/remediation/TASKS.md +++ b/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**.