docs(remediation): bank D-24 — mergeable:true cited as merge-readiness; D-23 corrected backward

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) <[email protected]>

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