[noderaven]

Release 1.6.7: scripted merges and the git identity.

On a machine with no global git identity, where the commit rules name one with git -c user.name=... -c user.email=... (which doctor accepts), every join wave merge failed: scripts/merge-wave ran git merge itself, without that identity, and git refused ("Committer identity unknown"). merge-wave reported any failed merge as a conflict. On r166 that sent each unit to an Opus resolver (4 extra agents); on r167, the run that built this release, the merge agent reported it as a failure instead and the run stopped until a temporary repo identity was set and the run resumed. A supervised run would have stopped asking for a conflict that did not exist to be resolved by hand.

Now setup records the commit rules' -c name and email as setup_result.git_identity (with doctor's parser, moved to scripts/_identity.py), and the run uses it for every merge and every commit it spells out: merge-wave gets --git-config, and the integrate, resolver and supervised-stop commands carry the -c options. With no pairs in the commit rules nothing changes. Doctor now checks the author identity as well as the committer's.

A merge git refuses for any reason other than a content conflict (a missing identity, a failing hook, a held index.lock) is now status: failed with git's message (exit 4). It never goes to a resolver: the run stops with that message. A held index.lock gets one retry after 2 s first.

Also in this release:

• The engine guards the wave merge result: a conflict with no conflicting files is a failure; a done that left a unit out stops the run; a missing merge result reads no result from <name> merge, so it is relaunched like any other missing result.
• Wave and recovery merges are named chore: join wave <n>: merge <unit> and chore: join recovery: merge <unit>, and every reviewer is told these (and the old forms) are the engine's own messages, not findings.
• The ledger records every wave merge, conflict and refusal (r166's ledger had no record of one of its two merges); the wave resolver records the merge it makes; join_tip follows only events that merged, so a relaunch's history check is not thrown off.
• Final reviewers run only the focused checks a finding needs (verify runs the full suite after them) and keep scratch files in their own mktemp -d folder. On r166 and r167 a final reviewer spent about 10 minutes running test files itself.
• Agent rules: Edit and Write turn a typed backslash-u escape into the character itself, so agents generate such text with a script and byte-check the file; reading a file before editing it means the Read tool, not grep or sed output.

Testing: built by a parallel-lanes run on 1.6.6 (r167): 7 tasks in 3 lanes and a join, each implemented and reviewed with no fix rounds. Its first launch stopped on the very bug this release fixes; it resumed through the 1.6.5 relaunch path, whose recovery merge brought in the two finished join tasks in one call. Then integration, a three-lens final review (9 minor findings: 2 fixed, 6 declined, all about the 1.6.6 engine's recovery merge messages in this run's own history, which is never rewritten) and verify. After the run I made the index.lock retry test prove the retry (it now fails with the retry disabled) and rewrapped three doc paragraphs. Tests include merge-wave refusals in a repo with no identity (missing identity, a failing hook, a held lock, a refusal after an earlier merge), and an end-to-end join on real git with the identity only in the commit rules: one merge agent, no resolver, the right author and committer. Full suite on Windows (Python 3.15): 1751 tests, 1735 pass, 16 skipped, 0 fail. Not run: a run with this release installed on a project with join waves.