From 96d989981be2ca8e941a74b7620ca0db382f040d Mon Sep 17 00:00:00 2001 From: wshallwshall Date: Mon, 24 Aug 2026 20:22:07 -0500 Subject: [PATCH] backlog: #1336's banner said build while an owner ruling 105 lines below took its only route out of scope Read against origin/main at 39a0e02d. THE HARM, measured on me. The row's banner block carries `Verdict: build` at body line 4. The owner ruling that closes its only remaining route sits at body line 109. I read the banner, dispatched the row to a builder lane, and had to retract it twenty minutes later. `scripts/coord/dispatch_gate.py` green-lit it for the same reason: it reads the banner block, which was wrong. THE RULING STANDS AND IS NOT TOUCHED. Owner answer 2026-08-25, routed via the Liaison: keep the out-of-scope ruling, fix the banner. They declined both reopening scope and closing the row. The row stays open because the defect is real and unfixed -- `git grep -n "seg.Scan" origin/main` returns scripts/hooks/worktree_gate.ps1:1291, matching the danger key against the quote-blanked string, with `$seg.Raw` at :1319-1321 as the same-file positive control so both spellings are visible and only the key match is wrong. THE EDIT IS TWO FIELD VALUES, BOTH FROM THE DOCUMENTED VOCABULARY. `scripts/coord/dispatch_gate.py:26-28` declares the contract: > Verdict: build | research | demand-gate | owner-ruling > Closing-act: code | scorecard-rescore | owner-ruling | banner-only so `owner-ruling` is a defined value for both fields. No new vocabulary is introduced, and no prose in the body is altered. CONTROLS RUN, not asserted: parse_items before 363 items / 247 open / 116 closed parse_items after 363 items / 247 open / 116 closed expected delta for a body amendment is 0/0/0 -- met diff is 2 insertions, 2 deletions, both inside #1336's banner block line endings unchanged: blob and working copy both LF-only at 16,122, size delta exactly +15 bytes, which is the two token substitutions VERIFIED WITH THE INSTRUMENT THE FIX IS FOR, self-test first so a pass means something: `dispatch_gate.py --self-test` PASSES 5 cases; `dispatch_gate.py 1336` now advises "closes by 'owner-ruling' ... NOT by the builder", where an untouched builder-closable control (#1348) produces no advisory. The gate still calls it workable -- that is the gate's stated design ("NAME THE CLOSING ACT, NEVER REFUSE IT"), not a gap in this edit. Whether a verdict of `owner-ruling` should itself change the gate's answer is BACKLOG #1334, already in a lane. Co-Authored-By: Claude Opus 5 --- docs/BACKLOG.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/BACKLOG.md b/docs/BACKLOG.md index d68fd7fe..15b2b043 100644 --- a/docs/BACKLOG.md +++ b/docs/BACKLOG.md @@ -15159,9 +15159,9 @@ per-lane virtualenv. ## 1336. Rule 3c asks one string two questions, so every fix for the false deny widens the bypass and back > 🔢 **Filed 2026-08-23 - not started.** `#1066` (a quoted danger key is invisible, FAIL OPEN) and `#1086` (a quoted body reads as a command, FALSE DENY) are **the same design error pulling in opposite directions**: rule 3c asks both questions of `$seg.Scan`, the quote-blanked text. Blanking more fixes `#1086` and widens `#1066`. Blanking less does the reverse. **Neither row can be fixed alone.** -> Verdict: build +> Verdict: owner-ruling > Research: none -> Closing-act: code +> Closing-act: owner-ruling **Cluster:** commit gates / secret scanning. **Priority:** P1 -- higher than either row it reconciles, because **a fix to either one alone makes the other worse and the last three attempts did exactly