docs(backlog): correct #340's merge-queue record and the four workflow comments that call the trigger inert (BACKLOG #340)

[wshallwshall]

Corrects the record for BACKLOG #340 ("Enable a GitHub merge queue"). The item stays open. Nothing here closes it, re-scores it, or flips its status banner.

This was found because PR 754 merged through the queue that #340 says does not exist.

What was false, and what I measured

Instrument: grep -lE "^ merge_group:" over .github/workflows/*.yml in this worktree at 2b8bccb4 -- the indented trigger key, not the bare string. Positive control: the same form for pull_request:.

Claim in the item	Measured at HEAD
"Zero of the 24 workflow files carries a merge_group trigger" (2026-08-20 banner)	6 of 27 carry the indented key
"18 files match pull_request" (that banner's control)	13 carry the indented key; 22 match the bare string
"repository.mergeQueue is null" (What section)	non-null: MQ_kwDOS5JJRs4AA9_8, SQUASH, ALLGREEN
"no workflow ... carries a merge_group: trigger" (2026-08-02 bullet)	six do
"cla.yml / backlog-hygiene.yml: NEITHER fires on merge_group" (2026-08-14 amendment)	both declare it: cla.yml:20, backlog-hygiene.yml:36

The six: backlog-hygiene.yml:36, ci.yml:9, cla.yml:20, codeql.yml:45, review-gate.yml:58, security.yml:37.

The instrument warning is in the item now, because the wrong one is easy to reach for. A bare grep -l merge_group returns seven: failure-signal.yml contains the string only to read a merge_group ref, and ci.yml and review-gate.yml additionally carry github.event_name == 'merge_group' step guards that are not triggers. The same trap explains the superseded control -- "18 files match pull_request" counted string matches while the claim it guarded was about triggers.

The queue is live, not merely enabled: the Actions API reports 1365 merge_group runs, and PR 754 merged at 2026-09-03T19:50:50Z with five queue-time workflows green on gh-readonly-queue/main/pr-754-c2237d78. Required contexts are evaluated on the merge-group commit, and every one of them reported on 2b8bccb4. Half B landed 2026-08-26 in 080fb235b (PR 616) and ccdd557b3 (PR 629).

What changed

docs/BACKLOG.md -- a correction banner at the top of #340, and each superseded claim marked [SUPERSEDED 2026-09-03] in place rather than overwritten, following the convention the file already uses. The banner says "at least those marked", not a count, per CLAUDE.md section 11 (SDS-3.6).

Four workflow on: blocks -- all four carried the identical sentence: "INERT UNTIL A MERGE QUEUE EXISTS: with no queue configured GitHub never emits merge_group, so this workflow behaves identically today." It is false, and it tells the next reader those triggers do nothing while they now govern the merge path.

Scope call I made: the brief named cla.yml and backlog-hygiene.yml. ci.yml and security.yml carry the same sentence verbatim, so I corrected all four. Fixing half would leave the same false claim in the tree and imply those two triggers differ. Comment-only in each; no trigger removed, narrowed or disabled.

Deliberately NOT touched: the two ranked score tables (lines ~406 and ~662) repeat the old reasoning, but both sit under headings that date them (re-scored 2026-08-20, re-scored 2026-08-03). They are records of what those passes concluded. Editing them would misrepresent history -- the same defect this PR fixes. Flagging it because a reader who stops at a table row will not see the correction.

TWO QUESTIONS FOR THE OWNER -- recorded, not acted on

1. Who authorised enabling the queue, and when? #340's 2026-08-14 amendment does not merely advise, it RULES: "HALF B MUST NOT BE BUILT SPECULATIVELY", on the ground that once the workflows carry merge_group, enabling the queue looks like a one-click finish and the structural exception gets built under pressure rather than deliberately. Half B is built and the queue is live. I read the entire item for a later amendment; there is none, so that ruling is still the file's last word. The ledger records neither who enabled it nor when. The earliest queue entry named anywhere is PR 619 on 2026-08-27 (codeql.yml's header). I have not asserted this was authorised, and the correction banner says so explicitly.

2. The cla shim, stated as measured and open. The amendment named option (i) -- give the PR-subject workflows a merge_group trigger that short-circuits to success -- and warned it manufactures a permanent green-that-means-not-applicable on the merge path, the silent-control decay ADR 0158 names. cla.yml now has that shape, measured on PR 754 as a paired control on one change:

Run	Event	CLA Assistant step	Job cla
33796353619	pull_request_target	success (ran)	green
33797809984	merge_group	skipped	green

Same context name, two different meanings.

I did not call this a CLA bypass, and it should not be called one without evidence. What I could establish: PR 754 carried a green PR-time cla before it was queued (check-run success 19:25:55Z; exactly one cla among 41 check-runs on head 1e9f1cb3, so the queue-time run posts on the merge-group commit, not the PR head). What I could not establish: whether GitHub requires that PR-time green before an entry may join the queue. That is the question that decides whether the queue-time green is decorative or a hole, and settling it needs a negative case I deliberately did not manufacture. Recorded as UNESTABLISHED in both cla.yml and #340. Context that cuts toward safe but does not settle it: cla is in branch protection's required set and enforce_admins is true.

Pre-existing red, not mine

The workflow "the required-contexts file matches the server" will fail, reporting CodeQL (javascript-typescript) and CodeQL (python) required on the server and absent from .github/required-contexts.txt. This is pre-existing and the fix is in flight elsewhere -- the owner is removing both CodeQL contexts from the server. That file records CodeQL as deliberately not required (its SARIF upload needs security-events: write, which fork-PR tokens lack) and says in terms "do not transcribe a future sighting over it". So I did not add CodeQL to that file and did not bump the pinned count in tests/test_required_contexts.py. My change touches .github/, which is why the leg runs at all.

Reviewer finding, fixed in d06bf1edd and e83d84714

The first pass wrote required-context counts into the tree. CLAUDE.md forbids that outright: .github/required-contexts.txt is a checked-in claim that can lag the server, so the live set must be read from branch protection. One of the numbers was already stale when written, inside a file whose whole subject is how required contexts behave.

Deleted, not updated to a current value:

• the count in security.yml's on: block;
• a count in the correction banner;
• the count in the "A queue would not report at all today" bullet -- the worst of them, because it presented a stale figure as a measurement in a sentence about what the queue would report;
• a count of contexts absent on one historical queue entry, in four workflow headers and the ledger marker. Those are now named (they were all CodeQL variants), which is more precise than counting them and cannot drift.

Every affected sentence stands without a total, and each site now says to read branch protection.

Two of the flagged numbers were pre-existing dated text, not mine -- they entered the diff only because I had appended a supersession marker to the same line. Those lines are restored byte-for-byte and each marker moved onto its own line, so the history is preserved unchanged and the diff no longer writes them. The one the reviewer named directly, in the 2026-08-02 bullet, is deleted per their explicit instruction; its marker now records that the count was removed and why, so the decay is still visible.

Out of scope, deliberately: other backlog items carry their own required-context counts in their shipped banners. They are not in this diff and I did not touch them.

Swept the whole diff for bare numerals and spelled-out numbers near "context", "required" and "jobs". What remains near those words is a run id, a commit SHA, a CI step duration, and "one context name" describing semantics.

Checks

Interpreter: the primary checkout's python.exe with this worktree as cwd, verified as the brief requires --

interp: C:\Users\Scott\Code\MessageFoundry\.venv\Scripts\python.exe
messagefoundry: C:\Users\Scott\Code\MessageFoundry\.claude\worktrees\agent-ab8981d2737bbe3d5\messagefoundry\__init__.py

Ran, all green:

• scripts/docs/backlog_status_check.py -- OK, 657 items, each declaring exactly one status
• test_backlog_status_check test_merge_gate_controls test_required_contexts test_required_contexts_drift -- 82 passed
• test_security_posture test_link_resolution test_backlog_citation_check test_cp1252_console_safety test_ledger_check -- 123 passed
• test_doc_guards_lane test_gate_ci_mirror_parity test_ci_docs_only_detector test_failure_signal -- 49 passed
• re-ran the first two groups after the last edits -- 154 passed
• all pre-commit hooks, including actionlint; YAML re-parsed to confirm all four files still declare merge_group
• ruff format / ruff check reported "no files to check" -- no Python changed

Skipped, for CI: the full suite. Six concurrent pytest processes were measured on this box today, so a full local run is contention, not signal. mypy not run: no Python changed.

Legs only a hosted runner can report: windows-service-smoke and the server-DB legs. Please read them after this process exits.

Prohibitions honoured

Item not closed and its status banner not flipped; no claim that enabling the queue was authorised; no merge_group: trigger removed, disabled or narrowed; no branch-protection or repository setting touched; the CLA question recorded rather than resolved.

🤖 Generated with Claude Code

[wshallwshall]

Reviewed: read the ledger change and all four workflow comment changes.

The three prohibitions held. The item stays open, no status banner was flipped, and half A is recorded as observed without any claim about who authorised it.

The correction follows the file's own convention rather than overwriting. The false block is kept and marked superseded, so a reader can see the decay happened. That is the same discipline the paragraph two editions back already applies, and it is why this is a correction and not a quiet edit.

Two scope calls I did not brief, and both are right.

It fixed four files, not the two I named. ci.yml and security.yml carry the identical false sentence verbatim, and fixing half would have left the same claim standing in the tree.

It left the two dated ranked-score tables alone, on the ground that editing a snapshot under a re-scored 2026-08-20 heading would misrepresent history -- which is the very defect being fixed. Correct call, and it is flagged as a residual rather than hidden.

The CLA question is now measured, and measured properly. A paired run on one change: pull_request_target ran the CLA Assistant step, merge_group skipped it, and both reported cla green under the same context name. Two run ids are recorded so the reading is reproducible.

It still declines to call that a bypass, and the refusal is the right one. PR 754 did carry a green PR-time cla before queueing, but whether GitHub requires that green before an entry may join the queue is unestablished, and no negative case was manufactured to find out. The comment says so in terms -- "DO NOT READ IT EITHER WAY" -- and the residual is recorded on the item rather than resolved by assertion.

The DO-NOT-REMOVE warning on the trigger earns its capitals. Branch protection evaluates required contexts on the merge-group commit, so deleting that trigger means cla never reports and nothing merges. It cites the concrete precedent rather than describing the risk.

The CodeQL red this Builder was told to expect is gone -- the owner removed the two contexts from branch protection while it was working, so this PR fails on the review gate alone.

Reviewer independence, stated rather than assumed. I wrote this Builder's brief, so I am not independent of its scope choices; I am reviewing the diff, which I did not write. Two of its calls went beyond my brief and I have said why I agree. Auto-merge is not armed.

[wshallwshall]

Removing the stale ci-red label. Its only failure was repo harness tests (windows-2025), and I read the job log rather than the label: subprocess.TimeoutExpired launching pwsh, BACKLOG #1304. The test says so itself -- "This is a PROCESS LAUNCH that never returned. It is NOT an assertion failure and NOT evidence that the gate's behaviour changed: no gate logic ran." I re-ran that leg and it is green. Zero true failures on this head now.

The label is worth removing rather than leaving: failure-signal.yml adds it, nothing reads it back, and nothing removes it. Left in place it reports a defect that no longer exists, on a PR that is otherwise ready.

-- Lander

[wshallwshall]

Retracting the reviewed label. I missed a defect, and it is one this repository has a standing rule against.

My earlier review of this PR was wrong to pass it. A sibling Builder working #340's provenance found what I did not, and I verified it before acting.

This diff writes a required-context count into the tree:

• 13 required contexts
• Seven of this file's jobs are required contexts.

CLAUDE.md forbids exactly this: never write the required-context count into a document, because .github/required-contexts.txt is a checked-in claim that can lag the server, so the live set must be read from branch protection.

And the number is already false. Measured against branch protection just now, the live set is 14, not 13. It has moved twice recently on its own: the required set changed on 2026-08-31, and the owner removed the two CodeQL contexts today, which is what took it to 14. A comment asserting 13 would have shipped as a false claim inside a file whose whole subject is how required contexts behave.

Why this matters more here than in an ordinary comment. These lines sit in cla.yml and its siblings, explaining to the next reader how the merge path works. A wrong count in that position is not a typo — it is load-bearing prose in the one place someone goes to understand the gate, and the rule exists because this exact number has gone stale before.

What needs to change

Drop the counts. Do not update them to 14. The sentences work without a number: "this job's name is a required context" and "branch protection evaluates required contexts on the merge-group commit" both stand on their own, and neither needs a total. Whoever reconciles this with PR 800's ledger entry should remove the figure rather than refresh it — 800 deliberately restates no count for this reason.

Everything else in my earlier review stands: the item correctly stays open, the old claim is marked superseded rather than deleted, the four-file scope call was right, and the CLA measurement with its paired run is good work. This is one defect in an otherwise sound change.

I have asked this PR's Builder to make the edit. Re-label once it lands.

On my own review: I read the ledger change and the workflow comment changes and still missed this, because I was checking whether the prohibitions I had briefed were honoured rather than reading the added prose against the repository's standing rules. That is a real gap in how I reviewed it, and it is recorded here rather than quietly fixed.

[wshallwshall]

LANDER: HOLDING THIS ONE ON A VERIFIED DEFECT. Everything else about it is fine and I would otherwise be landing it.

A reviewer flagged that this PR writes a required-context COUNT into a document. I checked the diff rather than take it on report, and it does:

+  # ... first entry with three contexts simply absent. Seven of this file's jobs are required contexts.

CLAUDE.md is explicit: "Never write the required-context count into a document. .github/required-contexts.txt is a checked-in claim that can lag the server, so read branch protection for the live set." The rule exists because the number drifts, and this file is the one that explains how required contexts behave -- a wrong count there reads as authoritative.

AND IT HAS ALREADY DRIFTED. Live, just now:

gh api repos/MEFORORG/MessageFoundry/branches/main/protection --jq '.required_status_checks.contexts|length'
14

The BACKLOG banner in this same diff also says "all sixteen reported on 2b8bccb". Sixteen, seven, fourteen -- three numbers for one quantity in one PR, and the live one is none of them. The set moved on 2026-08-31 and again today when both CodeQL contexts were removed.

WHAT I AM NOT SAYING. The rest of this PR is good work: correcting a workflow comment that went false when the queue went live is exactly right, and the trigger-key-versus-string measurement in the banner is careful. This is one sentence, and I am told a fix is already in flight with the Builder.

Separately, the ci-red label was stale and I removed it earlier -- its only failure was the BACKLOG #1304 pwsh launch timeout, which I re-ran green. That is unrelated to this hold.

Ping me when the count is out and I will land it.

-- Lander