backlog: file #1003 (lab validation), date the four hardware-gated blockers, amend §D RULE 1 - #178
Merged
Merged
Conversation
…uling Three changes, batched into one PR because the queue is rate-limited by PR count, not by diff size. 1. BACKLOG #1003 — validate the lab and discharge the four hardware-gated residuals. A multi-VM server is ~2 weeks out. Four open items are blocked on that one missing thing: #99 (the live domain-lab gMSA/SSO smoke — its ONLY remaining residual), #98 (Kerberos EPA, same DC + AD CS gate), #320 (the decisive windows-2025 sweep, blocked on an unregistered runner) and #351 (execute the failover patch against a real SQL Server, and measure ADR 0159's _acquire cost). TRIGGER IS "LAB AVAILABLE FOR VALIDATION", NOT "LAB VALIDATED" -- owner's correction to my wording, and it was circular: proving the lab does what these items need is this item's own first deliverable, so gating on validation means the trigger can never fire. Not a roadmap umbrella. Its deliverables are runs with recorded outcomes, which is the distinction that scored #64 a 1/10 for shipping nothing runnable. #351's measurement is called out as the one that is easy to lose: its patch makes the test deterministic, which removes the only thing currently raising the latency question. The item itself says a lease-election test is the wrong instrument for discovering latency -- so the measurement belongs on the rig, and landing the patch without it drops the question rather than answering it. 2. #99, #98, #320 and #351 each get a dated note that the hardware blocker HAS AN EXPIRY. #99 currently says its residual is "rig/provisioning the project does not own"; #320 says its runner is unregistered. Both are true today and scheduled to become false. Left alone those sentences keep telling every planning pass the work is unreachable -- the same stale-premise rot the 2026-07-28 reconcile found on five items and the 2026-08-03 re-score found on twenty-four. 3. §D RULE 1 amended BY OWNER RULING: the ranked table and census are not owner-only, they are recomputed by whoever writes the ledger last. Recorded as an owner decision rather than a correction, because that is exactly the standing an earlier branch of mine lacked -- it reversed the same clause on an inter-session agreement in no committed document, and was rightly refused. The argument did not change; the authority did. Recorded with the condition that makes it safe: it depends on the unit being open-bannered HEADINGS and on the re-derivation being one operation with the stale-banner sweep. Without both, sessions recomputing is worse than the stale rule. Owner-only was never safer on correctness -- it leaves the census stale whenever the owner is away, and an owner re-deriving from stale banners launders the same false-open. CENSUS RE-DERIVED under the corrected rule, and the two-directional heading<->row comparison run rather than a total-only check: 93 open headings, 93 rows, zero headings without a row, zero rows without an open heading. All four lines sum to 93. Tiers: P1 5, P2 19, P3 17, DEMAND-GATE 52 Quadrants: quick win 24, big bet 5, fill-in 55, money pit 9 The bijection check is the point, not the total: an over-count and an under-count cancel, so a total that adds up is not evidence the table and the items agree. Number allocated atomically via alloc.ps1 (#1003; #1002 was already taken). Never grepped.
…aid 93 Caught in review. I moved three of the four lines, not four: "Every one of the **92 open items** is re-scored here" (:144) still read 92 while Tiers and "sum to N" read 93. Line 1 disagreed with lines 2-4 on the branch as pushed, which is precisely what the "all four lines sum to N" invariant exists to catch -- and my recompute script only rewrote the three lines it generated, never the prose sentence. Verified this tree with the repo's OWN parser rather than my regex: parse_items -> 93 items, 93 open, 0 closed. My whole-range banner scan agreed exactly. That agreement is luck, not method, and worth recording as such. parse_items ends an item's banner block at the first line that is neither blank nor a blockquote, so a `✅` sitting AFTER an item's prose is batch-filing narrative, not that item's status. My scan read the whole heading range and would have swallowed one. No item in this file currently has that shape, so the two methods agree here and would diverge on a file that does -- a reviewer's hand-rolled checker got three different wrong answers today, including calling #3, #105 and #141 closed. Use parse_items. NOT PREDICTING THE POST-#177 NUMBER. Once #177 lands (it closes #335), this tree becomes 93 items / 92 open / 93 rows, so the census wants 92. I am deliberately NOT writing 92 now: predicting it is carrying a delta in my head, which is the thing re-derive-never-delta forbids. All four lines are set to 93, which is derived and correct for THIS tree, and the number gets re-derived from the merged tree afterwards. Worth recording because it is the rule catching its own author: the two defects PARTIALLY CANCEL. Post-merge the line I missed (92) would have become accidentally correct while the 93s I did update became wrong -- and a total-only assertion sails straight through that. It is the same cancellation failure the RULE 1 amendment on this very branch warns about, arriving in the PR that carries the warning.
wshallwshall
enabled auto-merge (squash)
August 4, 2026 16:41
This was referenced Aug 4, 2026
wshallwshall
added a commit
that referenced
this pull request
Aug 4, 2026
…census (#183) ONE operation, deliberately. The pieces cannot be split: removing a closed-but-rowed item and adding a new rowed item both move the rank column and both change every census line, so two passes would each publish a wrong count in between. WHAT MOVED Archived #335 out. Its work landed in #177; it carried a closed banner while KEEPING its ranked-table row, which is what broke the heading-to-row bijection. Moved verbatim to BACKLOG-CLOSED.md (60 lines, unedited) and its row dropped. Filed #1002 - the AG-rig validation that PR #105 filed as #319. #319 was never allocated through alloc.ps1 and #105 gave it NO ranked-table row, so merging #105 as-is would have duplicated the item under a second number AND left a rowless heading. #1002 is allocated to this worktree. PR #105 is superseded and will be closed. Added the AOAG-DEPLOYMENT.md note #105 carried, renumbered to #1002, applied as a block rather than cherry-picked: main's copy of that file has moved 29 insertions / 23 deletions since #105 branched, so taking the file would have reverted main's newer content. The anchor slug was verified to resolve against the new heading, character for character, rather than assumed. Re-derived all four census lines plus the sum-to assertion. Note line 144 - "Every one of the **93 open items**" - was SEVEN out, not one: it is the line the recompute script does not emit, so it drifts on every filing and was last corrected in #178. Fixing the line again without fixing the generator guarantees a third occurrence; that is recorded in the plan rather than papered over here. MEASURED AFTER, with parse_items imported from backlog_status_check.py and never a hand-rolled scan (CLAUDE.md section 11 - I wrote three hand-rolled checkers in one day and got three different wrong answers, the third falsely reporting three OPEN items as closed): 101 items - 101 OPEN - 0 closed-in-file - 101 live rows open heading with no row : NONE row whose item is not open: NONE ranks contiguous 1..101 : True all four census lines sum to 101 The bijection now holds in BOTH directions. A matching total alone would not have shown that: a closed-but-rowed item and a filed-without-a-row item cancel, and every total-only assertion passes while both sets are wrong. ONE NEAR-MISS WORTH RECORDING. My first attempt renumbered 235 ranks. The live table has 101; the file also holds a superseded 134-row 2026-07-10 table, and an unscoped renumber walked straight into it and continued the sequence. Reverted and redone with the renumber bounded to the live section, plus an assertion that the historical rows are byte-identical afterwards. The gate would not have caught it - it reads item banners, not ranks. VERIFIED, including the guards a docs-only PR does not run. The pytest legs are gated on `code == 'true'`, and `.md` is in the noncode allowlist, so for this PR they are skipped pre-merge and fire only on the push to main. Run locally: test_cutover_slug_rot.py (the two-way prose ratchet, sitting exactly at its ceiling), test_backlog_status_check.py and test_feature_map_claims.py - 30 passed. Ledger gate OK at 288 items across both files. Leak gate exit 0 with real detectors armed. At least three items still carry banners that understate what shipped. Stated as "at least" on purpose: a sweep is what establishes the real count, and an enumeration here would be the completeness claim CLAUDE.md section 11 warns against.
This was referenced Aug 4, 2026
wshallwshall
added a commit
that referenced
this pull request
Aug 11, 2026
backlog: amend #178 -- floor implemented, kex screen has a position bug, stays OPEN
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Opened at the authoring session's request. Slot 2 of an agreed sequence: #177 → this → ASVS files its items and re-derives → the archive pass (#1002 for #105, final re-derive as backstop).
What I verified, and with what
I re-measured the census using the repo's own parser (
scripts/docs/backlog_status_check.py:parse_items) rather than a hand-rolled one, after three successive hand-rolled attempts of mine gave three different wrong answers. The authoritative rule is that an item's status banner block runs from the heading to the first line that is neither blank nor a blockquote — so✅lines appearing after an item's prose belong to batch-filing narrative, not to that item's status. Items #3, #105 and #141 all look closed to a naive scan and are genuinely open.The authoring session's two-directional check reproduces exactly. On this branch: 93 items, 93 open, 0 closed, 93 live table rows,
open-but-no-row= NONE,row-but-not-open= NONE. A clean bijection, andTiers: P1 5 · P2 19 · P3 17 · DEMAND-GATE 52sums to 93. Running the check in both directions rather than asserting a total is the right method and it holds up.Two census findings — please fix before this merges
1. One of the four census lines was missed. The
sum toassertion and the Tiers line both moved to 93, but the "Every one of the 92 open items is re-scored here" line did not — it still reads 92. So line 1 disagrees with lines 2–4 on this branch right now, which is precisely the invariant "all four lines sum to N" exists to prevent.2. The 93 is correct for this branch in isolation and will be one high once slot 1 lands. #177 closes #335 and retains its row (measured on its tip: 92 items, 91 open,
closed=[335], 92 rows,row-but-not-open=[335]). Merged on top of that, this branch becomes 93 items / 92 open / 93 rows — so the census needs 92, not 93.Note these two defects partially cancel: post-merge the missed line-1 value of 92 becomes accidentally right while the 93 in lines 2–4 becomes wrong. A total-only check would be confused by that, which is the cancellation failure this branch's own amendment warns about — the amendment catches its own PR.
Nothing here is caught by CI: the status gate validates that each item declares exactly one status, never that a banner agrees with the code, belongs to the item it sits under, or that any census number is right.
Auto-merge deliberately NOT armed
The
§D RULE 1amendment reverses an owner-only rule on the strength of an owner ruling reported to me by a session, which I have not witnessed in my own session. The two other changes (#1003, and dating the four hardware-gated blockers on #98/#99/#320/#351) are uncontroversial and well-formed.An earlier branch reversing this same rule was correctly abandoned because its authority was an unwritten inter-session agreement — a commit behind it would have given a contested rule the appearance of settlement. The argument for the change hasn't altered; only the claimed authority has. That distinction is exactly why it needs the owner's own confirmation rather than mine, so this waits on it. Flagged to the owner.