The carry moves the applied-patch record in a second write, so a quit between the two leaves #236's state

The gap

Linking a ticket and taking trunk's loose work along writes the branch's meta and then moves the applied-patch record onto it, as two separate writes to electron-store:

await mergeBranchMeta(sitePath, branchRef, { tracTicket, baseOid, lastUsedAt });
await mergeSiteMeta(sitePath, { tracTicket, currentBranch: checkoutRef });
if (carriedFrom === TRUNK) { await carryAppliedPatch(sitePath, branchRef); … }

Each write is indivisible on its own — changeSiteMeta has no await between its read and its write, and so does every other siteMeta writer in src/main.js — so no concurrent flow can observe the record in both places or in neither. The pair is not. A crash or a quit landing between them persists exactly the state #236 described: the files on the branch, the claim about them still on trunk.

The window is two consecutive microtasks with no I/O in it, which is why this is filed rather than fixed alongside #473.

The idea

Fold both into one changeSiteMeta: build branches[branchRef] with tracTicket, baseOid, lastUsedAt and appliedPatch, and clear m.appliedPatch, in a single callback. That is not in tension with the rule #172 left behind — the entry is still created holding its branch point, in the same write that gives it one.

It reshapes the handler's tail, which is the only reason it was not done in the fix itself.

Related

• #236 — the bug this window is the residue of
• #473 — the fix, which closes the ordinary case
• #172 — the rule about not creating a branch entry without its branch point

Start in src/main.js at the handler tail that calls mergeBranchMeta, mergeSiteMeta, and carryAppliedPatch, then read changeSiteMeta and the related metadata writers. Done means the carried branch metadata and applied-patch move are persisted through one electron-store write, so quitting between the operations cannot leave the record on trunk.