I almost let a stale personal branch wreck a hotfix

My local preview branch was 304 commits behind origin/preview, and the /sync skill had no idea.

The ticket was a clean hotfix: the CAD exchange rate was hardcoded at 1.4 and had been silently overcharging Canadian customers. Changing it to 1.31 touched four files across checkout, packages, and receipt mailers. Short diff, clear business impact. I ran /sync, the skill fetched origin, found the ticket branch clean and ready, and was about to merge.

What it did not do was fast-forward preview first.

The skip logic was reasonable and wrong

/sync treats personal branches carefully. The reasoning is that my preview branch carries custom state: commits from teammates, preview-only changes that are not ready for develop. Merging into preview without understanding that state could clobber work. So the skill skipped personal branches entirely, every session, accumulating drift it never surfaced.

304 commits is not a lot in absolute terms, but those commits contained a substantial amount of upstream work that my local clone did not have. When I started the merge, git began trying to reconcile the two histories. The merge would have tried to replay 71,000-plus insertions already present in the remote branch. It would not have failed loudly. It would have produced a merge commit that looked internally consistent and was mostly noise.

I caught it because the diff preview was enormous. Not because the tooling stopped me.

What fast-forward instead of skip actually means

The fix was one change to /sync. Personal branches no longer get skipped; they get fast-forwarded first. If the local cannot fast-forward cleanly because the histories have genuinely diverged, the skill halts and surfaces the conflict. Fast-forward only means no merge commits get quietly created, no silent replays, no diff that looks complete but contains 71,000 lines that were never supposed to be in this changeset.

I also updated the written branch rules. The formal order is now fetch, fast-forward, then merge. The handoff for review branches is explicit: confirm local is current with origin/preview before anything touches it. These rules existed before in a loose way. They live in a file now, and the skill enforces them.

What compression does to drift

The platform’s workflow runs across multiple repo clones, and when Claude is doing the file edits and /sync is handling the merge path, the cycle time for a ticket compresses significantly. That is the point. It means I can close more tickets and keep the queue moving. It also means I run through sessions without the natural pauses where I used to catch things like branch currency.

Manual, slow work has informal safety checks baked into its slowness. You read the branch name twice because you typed it twice. You notice the diff is strange because you waited for it to generate. I do not want the slowness back. But the habits I built during the slow era were calibrated to that pace, and moving fast with the same habits means the habits stop catching things.

The 304-commit gap was not a recent development. The skip logic was not a bug introduced in the last sprint. It was a reasonable default that stopped being appropriate without announcing itself.

The branch model was correct and insufficient

The branch model is preview for the preview tip, develop for the release tip, master for prod. The team understands it. But a branch model is a set of intentions, and intentions do not enforce themselves at merge time. The /sync skill enforces things at merge time. If the skill’s behavior does not match the model’s invariants, the model is documentation, not infrastructure.

Changing one behavior in /sync made that gap concrete. A skip that let stale state accumulate invisibly became a halt that surfaces the drift and requires a decision. The class of near-miss that produced a 71,000-line preview merge cannot recur silently, because the skill will not let it stay silent.

When a workflow accelerates merges, stale local state does not get cheaper to carry. The /sync skill now makes that cost visible before it lands.

dxdev LESSON · paste into your AI coding agent
LESSON: A Merge Tool That Skips a Branch to Protect It Still Lets Drift Pile Up Silently
SOURCE: dxdev.com/blog/2026-04-24_stale-branch-wreck-hotfix
WHAT HAPPENED: A sync tool treated a personal branch carefully by skipping it entirely on every run, reasoning that merging into it without understanding its custom state could clobber work. The skip was reasonable, but it meant the branch never got compared against its own remote either, so the local copy silently fell 304 commits behind. When a routine hotfix merge was about to run against that stale local, it would have tried to reconcile two histories that had diverged that far, producing a merge commit that looked complete while replaying tens of thousands of lines that were never meant to be part of the change. It was caught because the diff preview was unusually large, not because anything in the tooling stopped it.
THE RULE: A workflow tool that skips touching a branch to avoid damaging it still needs to check that branch's currency against its remote every time, even if it takes no other action. "Skip to be safe" and "never verify" are not the same caution, and a skip that never checks currency lets drift accumulate invisibly until something else forces a merge against it. The safe default for a branch a tool is cautious about is fetch and fast-forward, then halt and surface a conflict if the histories have actually diverged, not silence.
CHECK MY CODE, then report PASS or FAIL with file:line for each:
  1. Any merge, sync, or deploy tool that skips a branch or environment entirely (rather than fast-forwarding and halting on real divergence) because merging into it is considered risky.
  2. Any workflow where a skipped branch's currency against its own remote is never checked, so drift has no way to surface until an unrelated operation runs into it.
  3. Any recent near-miss where a large or unexpected diff was the only thing that caught a problem the tooling itself should have caught first.
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.