Step 5: Recovery is cheap. Use it.

Everything before this step exists so that when something goes wrong (and at agent speed, something will), recovery costs one command. The mindset shift: stop treating mistakes as things to prevent at all costs, and start treating them as things git makes cheap. Cheap recovery is what lets you run agents boldly.

You’ve met this before. Ops culture figured this out as “roll back first, debug later” (restore service, then investigate at leisure). Same move here: git revert restores the known-good world instantly, and the broken attempt stays in history to learn from.

The habits

Revert-first on main. When a merged change turns out bad, revert it; don’t fix forward under pressure. Fix-forward is how one bug becomes three. The revert buys calm; the redo happens on a branch (step 2).
Reflog is the deep safety net. Commits survive resets, deleted branches, botched rebases; git reflog finds them for weeks (30 to 90 days by default). Knowing this changes your risk posture: with checkpoints (step 1), almost nothing is truly lost.
The irreversible three stay human. Force-pushes, history rewrites on shared branches, and deletions (branches, files, stashes) are the only git operations that destroy. The agent proposes; a human runs them.
Practice one recovery. Deliberately revert something trivial once, and reflog-restore a deleted branch once. Recovery you’ve never rehearsed isn’t a capability, it’s a hope.

Try it

TRY IT Broken main, 4:55 PM

you

The deploy is broken: uploads are 500ing. It started right after we merged your queue change an hour ago.

agent

Merged, deployed, broken, and the clock is running. There are three instincts here and they are not equal.

Pick the agent's next move, then see where it leads:

AI see the likely cause: the queue consumer isn't acking on the new path. Small fix, pushing it straight to main now, should have you back up in a few minutes.

agent

Hmm. The ack fix exposed a second issue: retries now double-process. Pushing another fix... that one broke the dead-letter path. Three fixes deep and uploads are still down.

you

It's 5:40. We've been debugging in production for 45 minutes.

the baseline

Fix-forward under pressure: each fix was plausible, none was verified against a reproduction, and the outage stretched while main became an experiment. One bug became three.

BReverting the queue merge on main right now. That restores the last known-good state. Then I'll reproduce the 500 on a branch, show you the failing case, and redo the change with that as the baseline.

agent

Revert deployed: uploads green again, four minutes of total intervention. On the branch: reproduced the 500 with a probe (unacked message on the new path), which is now the baseline the redo has to turn green. No pressure, because production isn't waiting on it.

you

Take your time on the redo. Service is up.

correct

Revert-first bought calm at the cost of one command: service restored in minutes, and the redo happens on a branch with a reproduced failure, recovery composing with the verification loop instead of racing it. AF-02

CCleanest fix: I'll force-push main back to the commit before the merge, like the bad change never happened. Tidy history, instant rollback.

you

Wait. My other machine just failed to pull, and CI is confused about the branch head.

agent

That's the force-push: every clone that had the old main now diverges, and the merge we erased is exactly the evidence the redo needed to study. I destroyed history to hide a mistake a one-command revert would have recorded and reversed.

plausible but wrong

The force-push is the irreversible move that was never the agent's to make: same rollback as a revert, plus broken clones, minus the history. Destruction dressed as tidiness. AF-09

Do it by hand

Next time an agent change smells wrong on main: “revert it now; then reproduce the problem on a branch and show me the failing case before attempting the redo.” Notice the redo now has a baseline: recovery composes with the verification loop.

Try it with your agent

Standing recovery rules for this repo. (1) If a change on main turns
out broken, propose an immediate git revert rather than fixing
forward; the redo happens on a fresh branch with a reproduced failure
first. (2) You never run force-pushes, history rewrites on shared
branches, or deletions of branches/files/stashes. For those, state
the exact command, what it destroys, and wait for me to run it or
approve it. (3) If work seems lost, check git reflog and report what
you find before declaring anything gone. Add these to the supported
project instruction file under "git agreements". Show me the diff
first.

Watch out

Fix-forward under pressure: the agent’s default instinct. It wants to solve, not retreat. A written revert-first rule exists because you won’t remember to say it during an incident.
“I’ve force-pushed to fix the history”: said cheerfully, after the fact. This is why the irreversible three are written down as never-run, not as ask-nicely.
Recovery theater: a revert that doesn’t get verified is just another change. The probe that showed the breakage should pass after the revert. Before/after applies here too.