From 36018be8d10f1f5b8c19b8ae8014c8ac4cccf0fe Mon Sep 17 00:00:00 2001 From: mos-dt-0 Date: Fri, 31 Jul 2026 20:44:34 -0500 Subject: [PATCH] =?UTF-8?q?docs(remediation):=20bank=20D-23=20=E2=80=94=20?= =?UTF-8?q?the=20mandatory=20queue=20guard=20has=20never=20worked,=20for?= =?UTF-8?q?=20any=20input?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit RM-02's registered fixtures found this before the registry was built. Worse than the banked unknown=>exit 0: ci-queue-wait.sh:266 pipes the payload into a classifier starting 'python3 - < --- docs/remediation/TASKS.md | 46 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 46 insertions(+) diff --git a/docs/remediation/TASKS.md b/docs/remediation/TASKS.md index 9491ec12..fc53913c 100644 --- a/docs/remediation/TASKS.md +++ b/docs/remediation/TASKS.md @@ -93,6 +93,52 @@ and must not be cited as merge evidence. Rely on reviewer clearance + real CI. Three independent live instances in a single session — format gate, agent context reset, queue guard — is the class confirmed, not anecdote. +### D-23 — the mandatory CI queue guard has never worked, for any input, ever + +RM-02's registered fixtures found this **before the registry was even built** — the sharpest possible +argument for the task. It is materially worse than the already-banked "unknown ⇒ exit 0" (D-6/D-10). + +`ci-queue-wait.sh:266` pipes the provider payload into a classifier that begins `python3 - <<'PY'`. +**`python3 -` reads its _program_ from stdin, and the heredoc supplies that program** — so +`json.load(sys.stdin)` never sees the piped JSON, EOFs, and falls through to `unknown`. + +Proven empirically, not inferred: + +``` +payload={"state":"success"} -> unknown +payload={"state":"failure"} -> unknown +payload={"state":"pending"} -> unknown +payload=not-json -> unknown +``` + +**Every input classifies as `unknown`; `unknown` exits 0.** So the mandatory pre-push / pre-merge guard +returns **PASS for every possible input — including a genuinely FAILING CI.** It has never distinguished +anything. My six observed "meaningless greens" were not an edge case; they were **the only output it can +produce.** + +**The fix already exists and is parked.** PR **#1023** — _"parse the payload it was handed, not stdin"_ — +is open, mergeable, and its body diagnoses this precisely: _"binds stdin to the program text, so +`json.load(sys.stdin)` EOFs, the state falls through to `unknown`, and the guard exits 0 on every +invocation, every branch, every repo, both platforms."_ + +Two aggravating details from that PR's own body: + +1. **`pr-ci-wait.sh:38` documented this exact bug and its remedy — and it was never backported to the + mandatory sibling.** A known defect, with a known fix, written down in one tool and never applied + where it was load-bearing. That is D-14 propagation failure with a security-adjacent blast radius. +2. It was _"opened per board instruction without re-verification"_ — the fix for an unverified gate was + itself shipped unverified. + +**Escalation, for Jason, on #1023's disposition.** Every merge gated on this guard since it was +introduced was **ungated**. The guard cannot fail. This does not mean those merges were bad — CI itself +ran and was checked by humans and reviewers — but the _automated_ gate contributed **zero** signal +throughout, while being cited as merge evidence. The standing doctrine ("treat its green as +zero-information") was more literally correct than anyone realised when it was written. + +**RM-02 records `required` vs `actual` per case with `DEFECT (owner: RM-03)`** and stays sensitive to any +change in either direction. No RM-03 lane was opened; `ci-queue-wait.sh` was not edited; source and +installed copy remain byte-identical at the observed SHA-256. + ### D-22 — the registry would have verified the wrong artifact Surfaced while ruling RM-02's design. The gate that **actually runs** when the fleet invokes a wrapper is