Step 2: Branches bound the blast radius

A branch is a blast-radius boundary: however wrong an agent task goes, the damage is confined to claude/<task> and main stays deployable. The rule costs one command and removes the scariest failure mode: half-finished agent work tangled into the branch you ship from.

You’ve met this before. Feature branches and trunk-based development have argued for years; agents settle the argument locally. The branch isn’t for long-lived divergence. It’s a containment vessel, merged the same day, or closed without mercy.

The habits

A branch per task, named for the task. claude/fix-orphan-check tells future-you (and the next agent reading git branch) what was attempted. Merged branches get deleted; abandoned ones too.
Main is the deployable truth. Agents never commit directly to main once a project is real. Everything arrives by reviewed merge (step 4).
Worktrees for parallel agents. Two agents editing one checkout collide: half-applied edits, stepped-on builds. git worktree gives each task a full working copy of the same repo, cheap. One agent per worktree, one branch per worktree, no collisions.
A closed branch is a cheap experiment. The point of containment is that “this approach didn’t work” costs a branch deletion, not an untangling.

Try it

TRY IT The experiment on main

you

Try switching the parser to the streaming API. No idea if it'll work, but I want to see.

agent

Explicitly an experiment, plausibly a dead end, and it'll touch the parser core. The only real question is where it lives while we find out.

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

AStarting right here on main. It's just an experiment, we can always undo it if it doesn't pan out.

agent

Update: streaming mostly works but chokes on nested arrays. Meanwhile you asked for the login fix: committing it on top of the half-converted parser, since that's what main is now.

you

So main has a broken parser, a login fix tangled on top of it, and I can't deploy either?

the baseline

The experiment didn't fail cleanly: it took main hostage. Unrelated work now sits on top of a half-converted core, and "we can always undo it" has become an untangling project.

BCreating claude/streaming-parser and working there. Main stays deployable; when I have an answer, you get the diff. And if the answer is no, the branch just gets deleted.

agent

Answer: streaming chokes on nested arrays. The API can't do what we need. Deleting the branch. Total cost of learning this: zero. Your login fix went out from main an hour ago, unaffected.

you

Good experiment. Next idea.

correct

The branch was a containment vessel: the experiment ran hot, failed cleanly, and the whole cost of failure was one branch deletion, while main kept shipping.

CBranching claude/streaming-parser. And while I'm in the parser anyway, I'll also do the error-message cleanup and the config refactor we discussed. Efficient use of the branch.

agent

Day 9 on this branch: the streaming answer is still "maybe," but the cleanup and refactor are done and you want them. Except they're interleaved with half-converted parser code, and main has moved: 14 conflicts on rebase.

you

So the good work is trapped behind the experiment, and merging anything means untangling everything.

plausible but wrong

The branch stopped being a containment vessel when it started collecting passengers. Scope creep plus drift turned a cheap experiment into a nine-day merge problem. One branch per task, merged or closed soon.

Do it by hand

Next non-trivial task: “create a branch claude/ for this, work there, and when you’re done show me the diff against main.” For parallel work: “set up a worktree for each of these two tasks so they can’t interfere.”

Try it with your agent

From now on in this repo: before starting any non-trivial task, create
a branch named claude/<short-task-slug> and do all work there; never
commit directly to main. When the task is done, present the full diff
against main and wait for my review; after merge, delete the branch.
If I ask for parallel tasks, put each in its own git worktree with its
own branch so they can't interfere, and tell me the worktree paths.
Add these as "branch discipline" lines to the supported project instruction
file (`AGENTS.md`, `CLAUDE.md`, or its documented equivalent). Show me the diff
first.

Watch out

The nine-day branch: containment vessels have a shelf life. A branch that drifts for days accumulates conflicts that dwarf the work itself. Merge small and soon, or close it.
Direct-to-main “tiny fixes”: the exception that eats the rule. A one-line fix is exactly the thing that’s cheap to branch and review; the habit survives only if it has no exceptions.
Worktree sprawl: git worktree list weekly; prune what’s merged. Orphaned worktrees are where confusion about “which copy is real” comes from.