docs(korus): record the owner ruling that "Merge when ready" is enqueuing

[wshallwshall]

What this changes

The Never arm auto-merge bullet in section 5 named a mechanism rather than an effect, and the two operations that button performs are not the same here. main requires a merge queue, so the mutation behind "Merge when ready" adds a queue entry rather than merging on green. A seat reading the rule literally cannot tell those apart and stops.

That is not hypothetical: it happened on 2026-09-05. A Lander seat holding the merge queue reached the point of filling it, hit this bullet, and held rather than guess.

Owner ruling 2026-09-05. Enqueuing through that button is permitted. Arming auto-merge on a branch that would merge without the queue stays forbidden. The Console-enqueues / Lander-merges division is unchanged.

The original hazard is kept and quoted in full

The bullet's warning — auto-merge fires on the head it saw, so a later push is dropped, the PR reads MERGED, the branch stays alive, and nothing reports a problem — is preserved verbatim in the amendment rather than deleted.

It is kept because nobody has measured it under a queue. Whether a queued entry drops a push landing underneath it is unmeasured. What this repository has measured is eviction and group rebuild, which is a different event with a different cause. The amendment states that explicitly and names the conservative course (dequeue before pushing) instead of implying the hazard was disproved. Deleting the rule would have deleted the observation with it.

No BACKLOG number is cited, deliberately

scripts/coord/alloc.ps1 cannot run in this environment — no pwsh, and its allocation registry lives beside a shared object store that a fresh cloud clone cannot see. Allocating from here would mean grepping for max + 1, which section 5 forbids by name and which has corrupted the ledger three times. So the subject is named rather than a number burned, per that same section's rule on citing numbers you have not allocated.

The a PR that implements BACKLOG #N must update BACKLOG.md gate is satisfied: with no BACKLOG #N token in this PR, that job reports "nothing to enforce".

Does not collide with #889

#889 also edits CLAUDE.md. Checked against the same base (b9f4f381): this change ends at line 390 and #889's nearest hunk opens at line 400, with nine untouched lines between. Non-overlapping regions of one file merge cleanly.

Type of change

• Documentation
• Bug fix / New Connection or transport / Refactor / Architecture change

Checklist

• No real PHI or customer data anywhere in the diff — this is a governance-doc edit, no fixtures or payloads.
• No new dependency.
• Docs updated: this PR is the doc change.
• Uses Connection / Router / Handler vocabulary; no new declarative "channel" element; no GUI or web-framework imports in engine packages; no Black. Not applicable to a prose edit, and nothing here touches them.
• No docs/BACKLOG.md item is completed by this PR, so no status banner applies.
• Reliability invariants, store/queue, staged pipeline, auth/RBAC, code-first graph model — untouched.

Checks run

Gate	Result
scripts/docs/claude_section_check.py	exit 0 — sections unchanged, 746 citations across 292 files still resolve
scripts/quality/control_char_check.py	exit 0 — no control bytes outside TAB/LF/CR
scripts/docs/dangling_citation_check.py	exit 0 — no unresolved backlog citation
scripts/security/scan_forbidden.py	exit 0, but degraded
test coupling	no test asserts on this bullet's text — checked every test module that reads CLAUDE.md

Read the leak-gate leg as degraded, not clean. scan_forbidden.py reported STRUCTURAL-ONLY: no token source configured — it had no corpus to match against, so its exit 0 means the structural pass found nothing, not that a token scan ran. That is an environment limit here, not a property of the change, and CI's own leg is the one to trust.

Not run: ruff, mypy and pytest were not run — no Python changed. The hosted-runner legs, including windows-service-smoke, must be read from CI by whoever picks this up.

Notes for the reviewer

The amendment is longer than the rule it replaces, on purpose. The rule failed by being terse enough to read as covering a case it had never been tested against, so the replacement carries the ruling, the retained hazard, and the boundary of what is actually known.

🤖 Generated with Claude Code

https://claude.ai/code/session_01YRrLas4mbUrhYQMKcYLxJh

---

Generated by Claude Code

[wshallwshall]

Standing down on the one red, deliberately. a reviewer has read this failed at head 91ac0e5 and I am not fixing it.

What it is. review-gate.yml reads the PR's labels and refuses one carrying no reviewed label. This PR has none, so the check reports exactly what it was built to report. It is a label check: it does not execute this diff, and nothing in the change could turn it green.

Why I am not clearing it by labelling. The obvious move is --add-label reviewed, and it is the wrong one. I opened this PR. CLAUDE.md section 5 says in terms that the gate "records that a step happened, not that an independent party looked, so labelling your own PR unread satisfies the machine and defeats the point." Self-labelling to silence a check I tripped is that failure exactly, and this PR is a governance-doc change where doing so would be self-refuting.

What I verified, and what I did not. The claim this stand-down rests on is that the context was de-required from main's branch protection on 2026-09-04, taking the required set from 14 to 13, so a red here blocks no merge. I did not measure that myself. My evidence is two independent PRs, #887 and #889, each recording a live gh api .../branches/main/protection read that afternoon. I tried to corroborate it against an instrument that does read the live server, the drift job in required-workflow-state.yml — it cannot answer: its most recent run on main was 2026-09-04T12:01:20Z, hours before the retirement, and it is on a daily cron. .github/required-contexts.txt cannot answer either, because it still names 14 and being wrong about precisely this is what #884, #887 and #889 exist to fix.

So: two consistent secondhand readings, no firsthand one, and the instrument that would settle it is stale rather than agreeing. That is weaker than "verified" and I would rather say so than round it up. If the context turns out to still be required, this PR is blocked and the remedy is a reviewer other than its author reading the diff — not a label from me.

No re-run fired. A re-run reproduces this result exactly; the label state has not changed and this is not a flake. Re-running would spend a slot in a backlog that is the evening's actual problem.

Nothing else is red. The remaining checks are queued behind that backlog.

---

Generated by Claude Code

[github-actions]

Thanks for your contribution! Before we can merge it, please read our Contributor License Agreement and sign it by posting the comment below.

---

I have read the CLA and I agree to its terms.

---

_{You can retrigger this bot by commenting recheck in this Pull Request. Posted by the CLA Assistant Lite bot.}