The merge test
Three people editing one task on three branches, merged in every order, with zero conflicts.
The conflict study measured how often other people's task files conflict. This is the other direction: proving ours do not.
The scenario
Three authors each edit the same task on their own branch:
- one moves it across the board,
- one leaves a comment,
- one logs time against it.
Then all three branches are merged into one — in every possible order.
What is asserted
| Conflicts | zero, in every merge order |
| Every author's change | present after the merge |
| Final state | identical regardless of order |
That last row is the one that matters most. It is invariant I1: the same events always fold to the same state, whatever order the files are read in. If merge order could change the outcome, everything else the product claims would be unreliable.
Why it holds
Each command appends its own file, named by a ULID. Three authors produce three different files, and git has nothing to reconcile — it takes all three. There is no shared line for two branches to disagree about, because no file is ever rewritten.
This is not a merge strategy or a clever .gitattributes rule. It is a property
of storing events instead of state.
The test itself
It runs on real git branches in a temporary repository, not on a simulation, and it is part of the suite that gates every release: test/integration/merge.test.ts.
What it does not cover
Two branches creating tasks that resolve to the same label (KAD-4 on both
sides) is a different case. Identity is the ULID, and the label is derived while
folding — so both tasks survive, but the labels are renumbered on read rather
than colliding.