From f3c100f81405f414e753023b347fbb2b291cc5b3 Mon Sep 17 00:00:00 2001 From: mos-dt-0 Date: Sat, 1 Aug 2026 09:52:01 -0500 Subject: [PATCH] =?UTF-8?q?docs(remediation):=20bank=20D-42=20=E2=80=94=20?= =?UTF-8?q?the=20head-pin's=20negative=20control=20has=20never=20been=20ob?= =?UTF-8?q?served?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit merge-gate.md says it outright: a successful merge is NOT evidence the pin worked, only the negative case is. On mosaicstack Gitea a merge against a WRONG head_commit_id has never been attempted, so every head-pinned merge to date is equally consistent with the pin working and with the pin being ignored. That is D-23's class — the queue guard "ran" and returned pass for every possible input; the pin "holds" on every merge that would have succeeded anyway. By the mission's own standard (every gate-introducing task carries a registered must-fail negative control; a gate with no proven failure path manufactures evidence) the head-pin is unregistered in substance however it reads in the runbook. Not blocking #1033: that head is coordinator-frozen with both the orchestrator and coder-mos1 holding, so there is no concurrent pusher for the pin to defend against — its protection is only load-bearing on a contested head. Raised by Mos while assigning the merge; Mos owns it and has filed it as an infra task in the D-37/D-41 cluster, to be proven before any contested-head merge. Requirement on RM-02: the negative-control clause must cover provider-side enforcement mechanisms, not only in-repo checks. "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. Co-Authored-By: Claude Opus 5 (1M context) --- docs/remediation/BOARD.md | 6 +++--- docs/remediation/TASKS.md | 23 +++++++++++++++++++++++ 2 files changed, 26 insertions(+), 3 deletions(-) diff --git a/docs/remediation/BOARD.md b/docs/remediation/BOARD.md index d4566820..3a94cb9f 100644 --- a/docs/remediation/BOARD.md +++ b/docs/remediation/BOARD.md @@ -29,8 +29,8 @@ 1. **Nothing is waiting on you that is urgent.** RM-03 waits on Jason; RM-61 is gate-ready and waits on Mos; RM-02 unblocks once RM-61 merges. Read the record before touching any lane. -2. **`docs/remediation/TASKS.md` is authoritative**, not the newest voice in a chat. It holds 42 findings - (D-1…D-6 in `BOARD-LEDGER.md`, D-7…D-41 + D-38c in TASKS.md), every ruling with its rationale, and the +2. **`docs/remediation/TASKS.md` is authoritative**, not the newest voice in a chat. It holds 43 findings + (D-1…D-6 in `BOARD-LEDGER.md`, D-7…D-42 + D-38c in TASKS.md), every ruling with its rationale, and the requirements each finding placed on RM-02/RM-34/RM-50/RM-55. 3. **`MISSION.md` carries five first-class principles**, all earned by live failures — observe the property not the proxy · pre-registration prevents retrofitting and nothing else · never ship an @@ -91,7 +91,7 @@ board is one of the six stale restatements below. ## Decisions log — full record in [`TASKS.md`](./TASKS.md) -All 42 findings (D-1…D-6 in `BOARD-LEDGER.md`, D-7…D-41 + D-38c in `TASKS.md`) and every ruling with its +All 43 findings (D-1…D-6 in `BOARD-LEDGER.md`, D-7…D-42 + D-38c in `TASKS.md`) and every ruling with its rationale live there. **Not duplicated here** — a second copy is a second thing to go stale, which this board had done three times in one night (gate list, capability registry, DECISION-1 status), and three more times by the next rotation seam (RM-61 "building", "nothing implemented yet", DECISION-1/2/3 diff --git a/docs/remediation/TASKS.md b/docs/remediation/TASKS.md index 712b674b..18763b4e 100644 --- a/docs/remediation/TASKS.md +++ b/docs/remediation/TASKS.md @@ -500,6 +500,29 @@ holds the head.** `coder-mos1` was RIGHT to want it fixed and WRONG to try to se right again immediately after, ACKing the hold and volunteering unprompted that it held an unpushed local commit. That disclosure is the behaviour to reinforce. +### 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 +negative case is — a merge attempted against a WRONG `head_commit_id` must be refused (409). On +mosaicstack Gitea **that negative case has never been run.** Every head-pinned merge to date is +consistent with the pin working _and_ equally consistent with the pin being ignored. + +**This is D-23's class exactly** — the queue guard "ran" and returned pass for every possible input. +Here the pin "holds" on every merge that would have succeeded anyway. By the mission's own standard — +_"every gate-introducing task carries at least one registered must-fail negative control; a gate with no +proven failure path manufactures evidence"_ — the head-pin is currently **unregistered in substance**, +however it reads in the runbook. + +**Not blocking `#1033`:** that head is coordinator-frozen with both the orchestrator and `coder-mos1` +holding, so there is no concurrent pusher for the pin to defend against. The pin's protection is only +load-bearing on a **contested** head. Raised by Mos while assigning the merge, and **Mos owns it** — +filed as an infra task in the **D-37 / D-41 cluster**, to be proven BEFORE any contested-head merge. + +**Requirement it places on RM-02:** the registry's negative-control clause must cover **provider-side +enforcement mechanisms**, not only in-repo checks. A gate whose enforcement lives in the forge is still +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. + ### 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