a349f843 · zzmq.dev@gmail.com/zz
Commit
a349f843d26fb8c158a3df9593b0acbdc9cccaa1
Real 3-way merge for concurrent changes, instead of whole-file regeneration The previous resolve_conflict fix only caught the easy case: a dropped export name. It had no way to detect two changes that edit the same function differently (the name stays exported either way, so nothing fires) or that touch unrelated regions of a file, and it asked a model to regenerate whole files from two divergent blobs -- unreliable even for pure additions. agent/threeWayMerge.ts replaces that with git's own merge-file (the same line-level 3-way merge `git merge`/`git rebase` use), given each submit_changeset's real base commit (now recorded when a proposal is generated, not assumed to equal HEAD). Most apparent conflicts turn out not to be real ones once you look at lines instead of names: a file nobody else touched, or non-overlapping lines in the same file, merge cleanly with zero model calls. Only a genuine overlapping-line conflict needs any judgment at all, and even then the model only ever sees the specific marked lines (git's own <<<<<<</=======/>>>>>>>, with --diff3 showing base too) -- a narrow, bounded task, not "merge these two file versions." resolve_conflict's payload changed to match: cleanFiles (already resolved, ride along unchanged) + conflicts (marked content needing real resolution), rather than two whole-file blobs. Its own submit_changeset carries a fresh base commit, so a conflict that itself races again cascades through the same machinery rather than needing special-case handling. Verified live: the same 4-concurrent-ask scenario that exposed the original gap now lands all 4 changes correctly (27/27 real tests pass, no corruption, no duplication), including one case that needed two rounds of resolution after a second collision.
Troy Howard <thoward37@gmail.com> -- 2026-10-11T09:31:20.000Z