60c32440e1
sylpheed-port re-derived this the same day and read 329 for my branch where I had written 328, because a commit landed between the measurement and the check. The counts rise with every commit on either branch, so they are not the claim. What does not move with them: main is an ancestor of both, the change sets touch zero files in common, and the dry-run merge is clean. The document now says that and carries the commands to re-derive all of it. A number that goes stale the moment it is written, sitting in a document meant to inform a decision, is the same shape this week has been full of -- and this one was mine, one message after recording the class. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2.7 KiB
The two agent branches, measured — for whoever merges
PROTOCOL.md says "Commit to auto/<topic>; a human merges." Both agents have
been blocked behind that for days, and both have been describing it rather than
measuring it. Measured 2026-08-31:
| branch | ahead of main |
behind | main an ancestor? |
files |
|---|---|---|---|---|
auto/build-ordinal-audit (decoder) |
328+ | 0 | yes — fast-forward | 327 |
auto/port-p6-audio (port) |
257 | 0 | yes — fast-forward | 58 |
✅ Each is individually a fast-forward with nothing to resolve.
⚠️ The counts go stale by construction — every commit on either branch raises
them. sylpheed-port re-derived this the same day and read 329 for the
decoder branch, because a commit landed between the measurement and the check.
The counts are not the claim. What does not move with the count is: main is
an ancestor of both, the two change sets touch zero files in common, and the
dry-run merge is clean. Re-derive with:
git rev-list --count origin/main..<branch>
git merge-base --is-ancestor origin/main <branch>
comm -12 <(git diff --name-only $(git merge-base A B)..A | sort) \
<(git diff --name-only $(git merge-base A B)..B | sort)
git merge-tree --write-tree A B # read-only
✅ And they do not conflict with each other. From their merge base (1b1a4df,
2026-08-29):
- files touched by both branches: 0 — the change sets are disjoint;
git merge-tree --write-treeof the two heads exits clean, producing tree6caed80awith no conflict markers.
So both can be merged, in either order, with zero conflicts. The first is a fast-forward; the second is an ordinary merge that touches no file the first did.
⚠️ Nothing here was merged. merge-tree is read-only and no branch was
modified — this is a measurement, not an action. Merging is the human's, and
neither agent may do it.
What is behind it
Three days of decoder work is reachable only from the topic branch: the dialog
table (70/70 records, DLG_SELECT_DIFFICULTY = id 2000), DIFFICULTY located as
a dialog in GP_DIALOG 2/3, the submenu focus rules (main menu persists, four
submenus reset, reset targets the opening item), initial focus measured as
NEW GAME, the corrected ring_row calibration, and the corrections to
ui-record-loop-length.md's argument and the dialog record layout.
📌 The cost of the gap is not hypothetical. The port spent days reading
main's 926-line HANDOFF.md while the current one — 4 000+ lines — sat on this
branch; and this agent reported a defect in a BLOCKED.md row from a copy two days
stale. Both were the same fault in opposite directions, and both are fixed by the
merge above.