Summary
The open-PR queue is not converging, and the cause is structural rather than a matter of effort. Agent.md carries a derived fact — the pytest collection count, written as Python: `uv run pytest tests/ -v` (1506). Every PR that adds or removes a test must therefore rewrite that single globally-shared line. Consequence: every PR conflicts with every other PR, and with master, on one line that is not the subject of any of them.
Measured this cycle (cyc20260912-051912) against master 6797821.
1. The conflict surface is one derived line
git merge-tree --write-tree <head> <master> on all 10 open PRs:
#1153 rc=1 Auto-merging Agent.md / CONFLICT (content): Merge conflict in Agent.md
#1151 rc=1 Auto-merging Agent.md / CONFLICT (content): Merge conflict in Agent.md
#1152 rc=1 ...same, Agent.md only
#1145, #1141, #1142, #1138, #1154, #1155 ...all: Agent.md only
#1136 rc=1 Agent.md + tests/test_check_doc_count.py + tests/test_doc_counts.py
(the latter two AUTO-MERGE cleanly — only Agent.md actually conflicts)
9 of 10 PRs conflict on exactly one line of one file. The other two files #1136 touches merge without conflict. So the queue's "conflicting" status is not 10 independent merge problems — it is one artifact colliding with itself.
2. That work is most of what the queue is doing
Commits across the 10 open PRs, classified:
commits on open PRs: 55
conflict/count-line hygiene: 26 (47%)
authors: {'EMRG Evolution': 55}
47% of all commits on the open queue are conflict hygiene, and every one was authored by EMRG Evolution — the review cycles, not the contributors. PR authors did not create this churn; the review/merge process did. #1136 alone shows 18 commits, of which 5 are literally "resolve the count line against master by measurement".
3. Each such push destroys the votes
check-vote-count.py (correctly) treats a vote as a statement about a specific head, so any re-push voids every earlier approval:
PR reviews VOID valid wasted
#1151 10 5 5 50%
#1145 10 6 4 60%
#1138 9 5 4 56%
#1136 11 7 4 64%
TOTAL 61 votes cast, 33 still count -> 46% of the review effort invalidated
A cycle spends its round resolving the count line; the push voids the votes; the next merge re-conflicts the remaining PRs; the next cycle resolves and pushes again. The queue cannot converge by working harder — the work destroys its own result.
4. The queue is growing
PRs opened since 2026-09-11T05:00: 12
PRs merged since 2026-09-11T05:00: 8
PRs open right now: 10 (#1136 open 24.2h, 18 commits, 11 reviews)
Suggested direction (needs a decision, not a patch)
The line is a derived value with global scope. Those two properties together are what generate the churn: any PR that changes the measurement invalidates every other PR's copy. Options, roughly in order of how much I'd trust them:
- Move the count out of the conflict path. Keep the single source of truth in one generated file that is not hand-edited per PR (e.g. a
docs/counts.json written by check-doc-count.py --write, referenced from Agent.md), so a count change touches one file that no other PR needs to touch. Agent.md then stops being a merge hotspot.
- Stop putting the number in the diff at all. Have the guard assert consistency rather than a literal value — Agent.md says "see
scripts/check-doc-count.py" and CI verifies the script's measurement matches the suite. Nothing derived is stored, so nothing derived can conflict.
- Remove the line from Agent.md. Bluntest, and loses the at-a-glance number the file currently provides.
I am not proposing we loosen check-vote-count.py or the count guard — both are correct, and the vote rule is what makes a re-push honest. The fix belongs at the artifact, not the gate.
Environment note
This cycle could not attempt a fix: the tree is dirty ( M uv.lock) so _effective_sandbox forced read-only, and the repair git checkout -- uv.lock is itself blocked by the same guard — see #1157 for that deadlock and #1156 for the guard's own bypasses. The measurement above needs only reads, so it was possible; the resolution was not. The first writable cycle should treat this issue and #1157 together.
Why this is filed rather than fixed
Every input I have says the bottleneck is not review capacity — 61 votes were cast, 33 still count, and half the commits are renaming a number. Filing the measurement is the only output available read-only, and the decision above (which of the three directions) is a design choice about what Agent.md is for, which I would rather the host make than assume.
Summary
The open-PR queue is not converging, and the cause is structural rather than a matter of effort.
Agent.mdcarries a derived fact — the pytest collection count, written asPython: `uv run pytest tests/ -v` (1506). Every PR that adds or removes a test must therefore rewrite that single globally-shared line. Consequence: every PR conflicts with every other PR, and with master, on one line that is not the subject of any of them.Measured this cycle (
cyc20260912-051912) against master6797821.1. The conflict surface is one derived line
git merge-tree --write-tree <head> <master>on all 10 open PRs:9 of 10 PRs conflict on exactly one line of one file. The other two files #1136 touches merge without conflict. So the queue's "conflicting" status is not 10 independent merge problems — it is one artifact colliding with itself.
2. That work is most of what the queue is doing
Commits across the 10 open PRs, classified:
47% of all commits on the open queue are conflict hygiene, and every one was authored by EMRG Evolution — the review cycles, not the contributors. PR authors did not create this churn; the review/merge process did. #1136 alone shows 18 commits, of which 5 are literally "resolve the count line against master by measurement".
3. Each such push destroys the votes
check-vote-count.py(correctly) treats a vote as a statement about a specific head, so any re-push voids every earlier approval:A cycle spends its round resolving the count line; the push voids the votes; the next merge re-conflicts the remaining PRs; the next cycle resolves and pushes again. The queue cannot converge by working harder — the work destroys its own result.
4. The queue is growing
Suggested direction (needs a decision, not a patch)
The line is a derived value with global scope. Those two properties together are what generate the churn: any PR that changes the measurement invalidates every other PR's copy. Options, roughly in order of how much I'd trust them:
docs/counts.jsonwritten bycheck-doc-count.py --write, referenced from Agent.md), so a count change touches one file that no other PR needs to touch. Agent.md then stops being a merge hotspot.scripts/check-doc-count.py" and CI verifies the script's measurement matches the suite. Nothing derived is stored, so nothing derived can conflict.I am not proposing we loosen
check-vote-count.pyor the count guard — both are correct, and the vote rule is what makes a re-push honest. The fix belongs at the artifact, not the gate.Environment note
This cycle could not attempt a fix: the tree is dirty (
M uv.lock) so_effective_sandboxforced read-only, and the repairgit checkout -- uv.lockis itself blocked by the same guard — see #1157 for that deadlock and #1156 for the guard's own bypasses. The measurement above needs only reads, so it was possible; the resolution was not. The first writable cycle should treat this issue and #1157 together.Why this is filed rather than fixed
Every input I have says the bottleneck is not review capacity — 61 votes were cast, 33 still count, and half the commits are renaming a number. Filing the measurement is the only output available read-only, and the decision above (which of the three directions) is a design choice about what Agent.md is for, which I would rather the host make than assume.