From eabe04bc5e412bad5fb28eb678de99aeda78bf08 Mon Sep 17 00:00:00 2001 From: mos-dt-0 Date: Fri, 31 Jul 2026 20:50:46 -0500 Subject: [PATCH] =?UTF-8?q?docs(remediation):=20bank=20D-24=20=E2=80=94=20?= =?UTF-8?q?mergeable:true=20cited=20as=20merge-readiness;=20D-23=20correct?= =?UTF-8?q?ed=20backward?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Mos verified #1023 before relaying and corrected my framing. Verified independently: review id-58 REQUEST_CHANGES at f6334080, the current head — the block is live, and its findings are that #1023's own fix is defective (unknown still exits 0, payload-as-argv hits ARG_MAX, tests do not assert exits). mergeable:true is git-mergeability, not readiness. The charter's first principle committed by the orchestrator inside an escalation about proxies. Fifth instance of mine. The mechanism, named because it will recur: mergeable is not a lie, it is a true answer to a different question. A false field would have been caught; a true-but-adjacent field passes every sniff test — which is why the discipline must be mechanical, not attentive. D-23 corrected backward per D-14-as-amended, original framing quoted. RM-02: readiness cases must assert the decision-relevant property — latest review state, CI terminal status on the exact head, required approvals — never a structural proxy. Co-Authored-By: Claude Opus 5 (1M context) --- docs/remediation/TASKS.md | 36 ++++++++++++++++++++++++++++++++++-- 1 file changed, 34 insertions(+), 2 deletions(-) diff --git a/docs/remediation/TASKS.md b/docs/remediation/TASKS.md index fc53913c..709ad3fc 100644 --- a/docs/remediation/TASKS.md +++ b/docs/remediation/TASKS.md @@ -93,6 +93,30 @@ 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-24 — the orchestrator cited `mergeable: true` as evidence of merge-readiness + +Escalating D-23, I wrote that the fix "exists and is parked, open and mergeable" — framing that invited +the reading _merge this and the gate is fixed_. **Mos verified #1023 before relaying, and corrected me.** + +`mergeable: true` is **git-mergeability**: the absence of textual conflicts. It says nothing about review +state, CI, or correctness. Verified independently after the correction: **review id-58, +`REQUEST_CHANGES`, at commit `f6334080` — the current head.** The block is live, and its findings are +that #1023's _own fix_ is defective. + +**This is the charter's first principle — observe the property, not the proxy — committed by the +orchestrator, inside an escalation about a proxy being mistaken for a property.** I spent the session +demanding that discipline of others, then read a JSON field whose name resembled the question I cared +about and reported it as the answer. **Fifth instance of mine.** + +Worth naming precisely, because it will recur: **`mergeable` is not a lie — it is a _true answer to a +different question_.** A false field would have been caught. A true-but-adjacent field passes every sniff +test, which is exactly why the discipline must be **mechanical rather than attentive**. + +**Requirement on RM-02.** A registered case asserting readiness must assert the **decision-relevant +property** — latest review state, CI terminal status on the exact head, required approvals — never a +transport-level or structural proxy. A case that reads an adjacent field is D-17 (the set does not cover) +in a convincing disguise. + ### 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 @@ -116,8 +140,8 @@ returns **PASS for every possible input — including a genuinely FAILING CI.** 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 +**A fix was ATTEMPTED and is parked — but it is NOT ready.** PR **#1023** — _"parse the payload it was handed, not stdin"_ — +diagnoses the defect precisely in its own body: _"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."_ @@ -129,6 +153,14 @@ Two aggravating details from that PR's own body: 2. It was _"opened per board instruction without re-verification"_ — the fix for an unverified gate was itself shipped unverified. +> ⚠ **CORRECTED (D-24), propagated backward per D-14-as-amended.** This entry originally read +> _"The fix already exists and is parked … open, mergeable"_ — framing that invited _merge it and the +> gate is fixed_. **`mergeable: true` is git-mergeability — the absence of conflicts — not readiness.** +> Verified independently: #1023's latest review is **rev-974 id-58, `REQUEST_CHANGES`, at commit +> `f6334080`, which IS the current head** — the block is **live, not superseded**. That review found +> #1023's own fix defective: `unknown` still exits 0, payload-as-argv hits **ARG_MAX**, and its tests do +> not assert exit outcomes. So "merge #1023 and the guard is fixed" is false twice over. + **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