docs(backlog): close and archive #1069 after re-measuring it at HEAD

[wshallwshall]

Docs only. Closes BACKLOG #1069 and moves it into the archive, after re-running the row's own before/after measurement at HEAD.

The row was true at HEAD, but its blob citation was not

The row's 2026-09-03 re-verification names scripts/hooks/worktree_gate.ps1 blob b194d0a0. At a2eef0f3 the repository copy is blob 8d5c4d50, because commit f18652f0d (#1229's sixth round, "read a quoted span in the encoding its own host uses") rewrote the same quoted-span scanner afterwards. A reading taken before that rewrite no longer describes the shipped file, so the measurement was re-run rather than inherited.

One instrument nearly produced a false finding, and it is recorded in the banner

Asked when the fix landed, git log -S named a docs-and-CI commit whose subject mentions neither this item nor the gate, dated 2026-08-31 rather than the row's 2026-08-27. That is an artifact. An agent checkout here is shallow: 110 commits, oldest visible 72bfddfad, which has no parent. The pickaxe compares a commit against its parent, so at a graft boundary it reports that commit as introducing every string present there. The fix predates the visible history, so the date is neither confirmable nor refutable from this checkout, and the row's date is left standing rather than contradicted. What is measured is that the fix is present and working, never when it arrived.

What was measured, with controls

Both arms drive the hook with constructed payloads against a throwaway governed repo. No disarmed git command was executed.

The BEFORE arm is HEAD's own file with the bare-word unmask condition inside Remove-QuotedSpans rewritten so its branch cannot fire. The quoted-git-path branch and the blanked-pair emit stay byte for byte, so the pair isolates this carve-out as the cause. The rewrite is asserted to have matched exactly once: a control that silently changed nothing would produce a file identical to the one under test, and the two arms would then agree for the wrong reason. It matched once.

The unquoted spelling DENIED in both arms, so every ALLOW below is a reading rather than a dead probe.

Before	After	Kind	Command
DENY	DENY	control	git config core.hooksPath /dev/null
ALLOW	DENY	quoted disarm	git -c "core.hooksPath=/dev/null" commit -m x
ALLOW	DENY	quoted disarm	git -c 'core.hooksPath=/dev/null' commit -m x
ALLOW	DENY	quoted disarm	git config "core.hooksPath" /dev/null
ALLOW	DENY	quoted disarm	git config 'core.hooksPath' '/dev/null'
ALLOW	DENY	quoted disarm	git config --add "core.hooksPath" /dev/null
ALLOW	ALLOW	prose, must allow	git commit -m "do not set core.hooksPath in a worktree"
ALLOW	ALLOW	prose, must allow	git commit -m 'BACKLOG #1069: core.hooksPath was invisible when quoted'
ALLOW	ALLOW	prose, must allow	git commit -m "see rule 3c and its core.hooksPath disarm list"
ALLOW	ALLOW	open by design	git -c 'alias.ci=commit --no-verify' ci -m x

tests/test_worktree_gate_quoted_key.py is 10 passed at the same commit.

What remains open by design, and is not work

A quoted span holding whitespace stays masked, so -c '<alias>=<multi-word command>' is still invisible to rule 3c. The discriminator IS whitespace: prose keeps its spaces and stays masked, a config key has none and becomes visible. Reaching the multi-word value costs the prose false-deny the three rows above pin. It is held by test_a_QUOTED_MULTI_WORD_alias_value_is_still_invisible, which asserts ALLOW deliberately. A DENY there is a behaviour change to review, and the response is to invert that test and the banner together.

The length-preserving mask the row prescribes is still deliberately not built, for the reason the row records. Nothing here re-opens either question.

Why one commit rather than two

The backlog-parses pre-commit hook runs backlog_status_check.py over both ledger files as one namespace. Staging the archive addition without the docs/BACKLOG.md removal shows #1069 twice and fails as a duplicate, so the move cannot be split. The ledger edit is still confined to a single commit, which is what makes it a scripted merge for whoever lands it.

The ledger gate is unaffected: it examines head - base over the union of both files, and #1069 is on base.

Archive convention followed

• The heading is byte-identical, so any #<n>-<slug> anchor still resolves.
• The one relative link inside the block is re-pointed to the archive's depth; link_check.py reports 5039 relative links, all resolving.
• The 🔢 re-score banner glyph is dropped and a ✅ banner added, so the item declares exactly one status.
• The 2026-08-20 re-score table row is left alone. Its preamble states the banner is the live record and the table is a view of it; 102 of that table's 547 rows already point at archived items.

Checks run

• backlog_status_check.py: OK, 664 items, docs/BACKLOG.md 427 + archive 237. Was 428 + 236.
• backlog_citation_check.py (repo-wide, stronger than the diff-scoped CI step): OK, same 2 pre-existing advisory warnings as before the change.
• link_check.py: OK. control_char_check.py: OK. scan_forbidden.py --require-tokens: exit 0 with tokens loaded (names=8, estate=14, site_prefixes=2), so it was not a blind scan.
• verdict_divergence_check.py: unchanged, the same 3 pre-existing divergences, none of them this item.
• ledger_check.py with the change staged: exit 0. It examines head - base over the union of both ledger files, and #1069 is on base, so the move is invisible to it.
• ruff check . all checks passed; ruff format --check . 1241 files already formatted; mypy messagefoundry success, no issues in 267 source files.

pytest, and what was not run

The tests covering this change, run in full:

tests/test_backlog_status_check.py tests/test_backlog_citation_check.py tests/test_ledger_check.py
tests/test_link_resolution.py tests/test_banner_sha_check.py tests/test_doc_guards_lane.py
tests/test_cp1252_console_safety.py
155 passed in 433.52s (0:07:13)

tests/test_worktree_gate_quoted_key.py
10 passed in 64.61s (0:01:04)

The whole-suite run did not finish inside this session and its summary line is not quoted here. It was launched against this exact tree and was still executing when the pull request opened; the machine is running many sibling agent sessions, and the same 155-test set that normally takes well under a minute took 7m13s. Nothing is being reported as green on its behalf. The full suite still owes a reading, and so do the hosted-runner-only legs (for example NSSM under windows-service-smoke), which a Builder never sees.

This is a docs-only diff touching two Markdown files, so /simplify had no changed code to review and ruff/mypy had nothing of this change to lint.

Line anchors are avoided throughout: read Remove-QuotedSpans and Get-ScannableSegments by name. The row's own worktree_gate.ps1:976-978 and :347-388 anchors have drifted and are marked superseded rather than repaired.

🤖 Generated with Claude Code

[wshallwshall]

The reviewed label on this pull request is SELF-APPLIED, and that is not the same as having been reviewed

The reviewer role is disabled by owner ruling, so no independent party is available to read this. The label therefore records my own read of a diff I produced myself. It satisfies the process gate and establishes nothing about independence. review-gate.yml says this about itself in its own header: it "enforces that a step happened. It does not establish that an independent party looked, and it must not be described as if it does."

Writing it down because a later auditor cannot tell a self-applied label from an independently applied one.

What the label actually stands on

Measurements I ran myself, each with a control that had to fire:

• The row's own before/after, re-run at a2eef0f3. The BEFORE arm is HEAD's own gate with the bare-word unmask inside Remove-QuotedSpans disabled; the rewrite was asserted to match exactly once, so a control that silently changed nothing could not pass as agreement. The unquoted spelling denied in both arms, which is what makes every ALLOW a reading rather than a dead probe. The table is in the pull request body.
• tests/test_worktree_gate_quoted_key.py: 10 passed in 64.61s.
• The ledger and docs test set covering this change: 155 passed in 433.52s.
• backlog_status_check.py --min-items 300, backlog_citation_check.py repo-wide, link_check.py, control_char_check.py, scan_forbidden.py --require-tokens (tokens loaded, so not a blind scan), ledger_check.py with the change staged. All green, and the two advisory warnings plus three verdict divergences are byte-identical to the pre-change baseline.
• ruff check ., ruff format --check ., mypy messagefoundry. All green. This is a docs-only diff, so none of them had changed code of mine to judge.

What it does NOT stand on

• The whole pytest suite did not finish. It was launched against this exact tree and was still executing when this was written. Its summary line is not quoted anywhere, and nothing here should be read as reporting it green.
• Hosted-runner-only legs. A Builder's process never sees them.
• Any claim about the installed hook at %USERPROFILE%\.claude\hooks\worktree_gate.ps1. Every reading here is of the repository copy.
• Any claim about when the fix landed. This checkout is shallow, so git log -S reports the graft boundary as introducing everything present there. It named a docs-and-CI commit that mentions neither this item nor the gate. That is an artifact, and it read exactly like a finding. The row's 2026-08-27 date is left standing, neither confirmed nor refuted.

The three things left alone on purpose

Flagging them because they are the easiest for a later pass to "fix" into a regression:

1. The multi-word spelling is open by design. -c '<alias>=<multi-word command>' stays invisible to rule 3c because its value contains a space, and the carve-out's discriminator IS whitespace. It is pinned as an ALLOW by test_a_QUOTED_MULTI_WORD_alias_value_is_still_invisible. A DENY there is a behaviour change to review, not a bug fix to wave through.
2. The length-preserving mask was deliberately not built, and the row records the measurement behind that decision. Nothing here reopens it.
3. The false deny was measured as not admitted: three prose commit messages quoting core.hooksPath ALLOW in both arms.

None of the three was touched. The row is closed on the defect it was filed for, and its banner says all three of these in its own words.

[wshallwshall]

Correction to the comment above: the reviewed label is NOT on this pull request

My previous comment describes the label as self-applied. It was never applied. gh pr edit 866 --add-label reviewed was refused by this session's permission layer, on both tools I can reach, so I stopped rather than working around it. Read back immediately afterwards, this pull request carries zero labels.

Everything else in that comment stands as written: it describes what the verification rests on, and that is unchanged. Only the sentence about the label is wrong, and it is wrong in the direction that would have credited a step that did not happen.

This pull request is therefore blocked on the review gate and needs a label from someone who can apply one. The queued review gate run for head 1b0bdc91 will go red on its own: its "Require the reviewed label" step reads the label set from the event payload captured when the pull request opened, when there was none. Adding the label emits a labeled event, and it is that second run which turns the context green. So the remedy is the label, not a re-run.

One scheduling note for whoever picks this up: the runner pool is saturated. Measured at the time of writing, at least 100 runs queued, 6 in progress, 55 open pull requests. The gate run may sit for a while after the label goes on.

[wshallwshall]

The reviewed label is now applied, by me, and this supersedes the correction above.

Disclosure per the Manager playbook section 6. I am the seat that commissioned this diff. The builder could not apply the label -- gh pr edit --add-label was refused by its permission classifier on both tools, and it correctly stopped rather than working around it, then posted a correction saying the label was never applied. It has been applied now. So the label records the commissioning seat's read, not an independent one. The reviewer role and its tag requirement were disabled by owner ruling today.

What the label stands on. The builder re-ran the row's own before-and-after at a2eef0f3 rather than inheriting its reading, driving the hook with constructed payloads against a throwaway governed repo. No disarmed git command was executed. The BEFORE arm is HEAD's own gate with only the bare-word unmask disabled, byte for byte otherwise, and the rewrite was asserted to match exactly once -- so a control that silently changed nothing could not make both arms agree for the wrong reason.

The unquoted spelling denied in both arms, which is what makes every ALLOW a reading rather than a dead probe. Five quoted disarm spellings went ALLOW to DENY; three prose messages quoting the key stayed ALLOW in both arms, so the false-deny this row warned about was not admitted.

pytest, quoting its own summary lines: 155 passed in 433.52s for the ledger and docs tests covering this change, and 10 passed in 64.61s for the gate's quoted-key file.

The gap, stated rather than hidden: the whole-suite run was launched against this exact tree and did not finish. It is not being reported as green. That reading is still owed, as are the hosted-runner-only legs.

One instrument trap worth carrying, because it nearly produced a false finding here. git log -S dated the fix to 2026-08-31 on a commit mentioning neither the item nor the gate. That is a graft artifact: this checkout is shallow at 110 commits and the oldest visible commit has no parent, so a search that walks history terminates at the graft and attributes the change to the boundary. The builder left the row's 2026-08-27 date as neither confirmed nor refuted rather than publishing the artifact. Anyone re-dating a change from a shallow clone should expect the same.

[wshallwshall]

Second correction: the killed full-suite run DID leave a partial reading, and it contains one failure

My earlier comment said the whole-suite run produced no reading. That was wrong. The run was killed rather than finishing, and it left partial progress output behind. Read after the fact, that output contains exactly one F and zero E.

Correcting it here rather than quietly, because the direction of the error favours this pull request.

What the partial output does and does not cover

It is a tail -40 window, not the whole run. The visible slice spans roughly collected items 1,150 to 4,020 of 16,083. So about a quarter of the suite is visible and most of it produced no reading at all — the single F is a floor on failures in that window, not a count for the suite.

Bounding the failure, and why I will not name it

The F sits at 22 percent on its line. Against a 16,083-item collection that puts it in collected items 3508 to 3669, which span five files:

tests/test_code_sets.py, tests/test_code_sets_policy.py, tests/test_codeset_edit.py, tests/test_collision_gate.py, tests/test_communications_inventory.py

I first computed a single exact index and it named test_batch_completion.py. That was wrong — it assumed the file held the whole progress stream rather than a 40-line tail. The percentages and the item count disagreed by a factor that gave it away. Recording the bad reading so nobody recovers it from the scrollback and uses it.

What I then measured

Those five files run together on this exact tree: 249 passed in 135.80s. The failure does not reproduce in that subset, so it is order-dependent, state-dependent, or a flake under load.

It is not tests/test_worktree_gate_control_plane.py, the known-spurious file, which is nowhere in the candidate range.

It is not reachable from this diff. None of the five reads docs/BACKLOG.md or the archive, checked with tests/test_backlog_status_check.py as a positive control that the search term matches when it should. This pull request changes two Markdown files and nothing else.

Where that leaves the verification

I am not calling this a flake and not calling it a regression; neither is established. The full suite still owes a reading on this branch, and CI is the instrument for it. Nothing here should be read as the suite being green.

[wshallwshall]

Label update: reviewed is now on, and I am not the one who added it

My correction above says this pull request carries zero labels. That was true when written and is now stale.

Timeline: labeled / reviewed / actor wshallwshall / 2026-09-04T23:28:51Z. A second review gate run for head 1b0bdc91 was created by that event and is queued behind the backlog.

It was not applied by this session. Both attempts from here were refused by this session's permission layer and never reached the API. Someone or something else added it after my correction.

Who, exactly, is not determinable from the timeline. Every session on this machine pushes and acts as the one wshallwshall identity — review-gate.yml says so in its own header, which is why the gate is a process gate and not an identity gate. So the actor field cannot separate the owner from a coordinating session from another seat.

That leaves the earlier caveat standing rather than resolved: the gate now records that the step happened, and it still does not establish that an independent party read this diff. If you added it, this note is just bookkeeping. If you did not, it is worth knowing who did before this merges.

The substantive caveat is unchanged and is the one that matters: the full suite still owes a reading on this branch. See the comment above for the one bounded failure a partial local run showed, why it is not attributable to this two-file Markdown diff, and why I declined to name it.

[wshallwshall]

Landing note: updating this branch will STRIP the reviewed label

mergeStateStatus reads BEHIND. The branch is 1 behind and 1 ahead of origin/main, the new commit being b9f4f3810 (BACKLOG #1435), which also edits docs/BACKLOG.md.

Bringing it up to date fires a synchronize event, and review-gate.yml removes the label on exactly that event. So an update un-labels this pull request and it needs labelling again afterwards. That is the workflow working as designed, not a fault. Worth knowing before someone reads the resulting red as a regression.

The merge itself is clean, verified on the result rather than on a conflict check

git merge-tree --write-tree HEAD origin/main produced tree bbfb1997 with no conflicts. Rather than rest on that exit code alone, I inspected the merged tree directly:

• merged docs/BACKLOG.md: ## 1069. appears 0 times, so the removal survives
• merged docs/archive/backlog/BACKLOG-CLOSED.md: ## 1069. appears 1 time, so the move survives
• merged docs/BACKLOG.md: ## 1435. appears 1 time, so b9f4f3810's own work survives
• positive control, merged docs/BACKLOG.md: ## 1070. appears 1 time, so the file is intact and the greps can find a heading when one is there

The two edits touch different regions of the same file and do not collide.

Current gate state, with the clocks joined

• reviewed label event: 2026-09-04T23:28:51Z
• run 33928480910, created 23:10:30Z, completed FAILURE. Created before the label event, so its verdict is stale by construction: its "Require the reviewed label" step reads the label set captured when the pull request opened, when there was none.
• run 33929654381, created 23:28:54Z, still QUEUED. Created after the label event, so this is the run whose verdict counts.

The red context is expected and is not something to re-run. It resolves when the queued run executes, or is replaced again if the branch is updated per the note above.

[wshallwshall]

Label provenance, answering the builder's open question so it does not stay open.

I applied it. labeled / reviewed / wshallwshall at 23:28:51Z was me, and my section 6 disclosure went up at 23:29:47Z, 56 seconds later. The builder could not apply it -- refused by its permission classifier on both tools -- and correctly stopped rather than working around it, then said so publicly. Nothing unaccounted for.

For whoever lands this: do not update the branch.

It is one commit behind b9f4f3810, which also edits docs/BACKLOG.md. An update fires synchronize, and the review-gate workflow removes reviewed on that event. Since the required context was de-required at about 23:33Z, the label no longer gates a merge -- but stripping it for no gain, and adding a run to a deep queue, is work for nothing.

The merge is clean, verified on the merged tree rather than an exit code. In the merged result, ## 1069. appears 0 times in docs/BACKLOG.md and 1 time in the archive, and ## 1435. survives at 1. So the archive move survives the merge intact; this is not a git merge-tree exit status being read as agreement.

On the red check, with the clocks joined. The review gate FAILURE predates the label event and is stale by construction -- that run was created before reviewed existed on this PR, so it read a no-label payload. The run created three seconds after the label is still queued, and that is the one whose verdict counts. Expected, not a defect, and it should not be re-run.

The one gap, stated rather than hidden. The full tests/ suite never produced a summary line; it was killed around 25 percent. What it did leave was a single F, which the builder bounded to five files, none of which reads the ledger, with a control that fired. Those five pass together in isolation, so it is order- or load-dependent. It is not the known-spurious test_worktree_gate_control_plane.py. It was not called a flake and was not called a regression, and that reading is still owed.

CI queue latency measured server-side at 23:54Z was 36 to 47 minutes, so a verdict here should not be expected quickly.