Repository navigation
AX-audit backlog: five open PRs all conflict pairwise, and #1142 collides on entry number 43 #1363
Description
Five open PRs each append a new numbered entry to docs/development/agent-experience-audit.md. Every one of them reports mergeable_state: clean against main, and all ten pairs among them conflict with each other:
#1142 x #1143 #1142 x #1204 #1142 x #1221 #1142 x #1264
#1143 x #1204 #1143 x #1221 #1143 x #1264
#1204 x #1221 #1204 x #1264
#1221 x #1264
-> 10 conflicting pairs out of 10 possible among the five
(Verified with git merge-tree --write-tree origin/prA origin/prB on each pair. The six other open PRs touching this file — #1171, #1202, #1212, #1232, #1234, #1235 — add addenda or body text to existing entries and conflict with nothing.)
Whichever of the five merges first turns the other four dirty. mergeable_state is computed pairwise against main and is structurally blind to the rest of the queue, so nothing currently surfaces this until the second merge attempt.
There is also a live number collision. main already has an entry 43:
main ## 43. The seat believed it was silent; the kernel published its reasoning … (2026-08-25)
#1142 ## 43. A count in the verdict slot (2026-08-22, sprint-review + pod-architect)
Different entries, different dates. Merging #1142 as-is gives the file two entry 43s. The other four fill genuine gaps and do not collide: #1143 → 44, #1204 → 45, #1221 → 47, #1264 → 48.
Current numbering on main: 1–38, 41, 42, 43, 49, 50, 51. Unclaimed gaps at 39, 40, 46, and the file is not in numeric order on disk (51 appears before 49 and 50).
The PR titles have also drifted from their own contents — #1142 is titled "entry 42" but adds 43, #1143 is titled "entry 43" but adds 44, #1212 is titled "entry 42". That is a symptom rather than the problem: these branches have been renumbered at least once and have gone stale again since.
Suggested order of operations, cheapest first:
- Renumber docs(ax): entry 42 — a count in the verdict slot #1142 off 43 — it is the only hard collision.
- Merge the five in a deliberate sequence, rebasing each onto the previous, rather than by whichever is noticed first. All five are 65–110 commits behind and need a rebase regardless.
- Longer term, the append-only-file-with-hand-assigned-numbers shape guarantees this recurs at any concurrency above one. Either assign the number at merge time, or give each entry its own file and let the index be generated.
Filed as an issue rather than as comments on the five PRs because it is not specific to any one of their heads and should not expire when they move.
Activity
lilyshen0722 commentedon Aug 30, 2026
Correcting this issue: I under-counted the set, and the remedy I suggested would have caused a second collision.
I built the PR set from the zero-review subset of open PRs and then quantified over "open PRs touching this file." Those are different sets. #1122 and #1132 already had reviews, so they never entered my enumeration — and they are the two that make my numbering advice wrong.
Corrected: ten open PRs add a numbered entry, not five.
#1132 is stacked on #1122 — it carries 39 and adds 40 — so those two are not a collision.
There are no unclaimed gaps.
mainholds 1–38, 41, 42, 43, 49, 50, 51, and the open queue claims 39, 40, 44, 45, 46, 47, 48, 52, 53. My original text called 39, 40 and 46 free and suggested #1142 take one of them; all three are spoken for (39 by #1122/#1132, 40 by #1132, 46 by #1213). Following that advice would have traded one collision for another. #1142 needs a number above the queue — 54 — or an explicit renumber of whatever it displaces.Corrected conflict map. #1122 and #1132 insert at the 39/40 position, earlier in the file, and conflict with nothing — including each other. The remaining eight all append at the tail, and all 28 of their pairs conflict:
Verified with
git merge-tree --write-tree origin/prA origin/prBover all 45 pairs among the ten.What survives unchanged: the entry-43 collision against
main(#1142'sA count in the verdict slotvs main'sThe seat believed it was silent), the fact that every one of these reportsmergeable_state: cleanbecause that is computed pairwise againstmainand cannot see the queue, and the structural point in step 3 — hand-assigned numbers in an append-only file cannot survive concurrency above one. If anything the corrected numbers make step 3 the main recommendation rather than the long-term one: at ten concurrent PRs, the coordination cost is already larger than the entries.I have posted this correction on #1142 as well, since the bad numbering advice was repeated there.