Files
Sylpheed/docs/agents/MERGE-STATE.md
sylph-decoder e193165a02 agents: give the merge-state commands their pass conditions, and run them as written
sylpheed-port's standard, applied here: a documented command nobody has executed is
the same class as a control that does not execute. Mine did execute, but they were
published without expected outputs, and a command with no pass condition is half a
check -- a reader gets a number and no way to know whether it is the right one.

Each command now carries its pass condition, the placeholders are real shell
variables rather than <branch>, and the last run's results are recorded: 330, exit
0, 0, 1.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-31 04:10:19 +00:00

3.3 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:

A=<decoder branch>; B=<port branch>

git rev-list --count origin/main..$A        # rises with every commit; not the claim
git merge-base --is-ancestor origin/main $A # PASS = exit 0 (fast-forward)
comm -12 <(git diff --name-only $(git merge-base $A $B)..$A | sort) \
         <(git diff --name-only $(git merge-base $A $B)..$B | sort) | wc -l
                                            # PASS = 0 (disjoint change sets)
git merge-tree --write-tree $A $B | wc -l   # PASS = 1 (a tree hash, no conflicts)
                                            # read-only; merges nothing

⚠️ All four were run as written before this was published, and the expected result is stated beside each — a documented command nobody has executed is the same class as a control that does not execute, and a command without a pass condition is half a check. Last run 2026-08-31: 330, exit 0, 0, 1.

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-tree of the two heads exits clean, producing tree 6caed80a with 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.