Discrete mode used to put everything on a single intent branch. Inception, product, design, development, security — all of it, one branch, one PR at the end. That's fine for a 200-line change. It's a death march for anything real, because nobody reviews a 500-file PR that spans four lifecycle stages. They either rubber-stamp it or they give up.

So we stopped doing that.

The branch is the stage

In discrete mode, H·AI·K·U now creates a branch per stage:

haiku/{slug}/inception
haiku/{slug}/product
haiku/{slug}/design
haiku/{slug}/development

Each stage gets its own PR. Small, scoped, actually reviewable. Inception PR covers the elaboration artifacts. Product PR covers the specs. Design PR covers the wireframes and design tokens. Development PR covers the code. Your reviewer sees the work for one concern at a time and can give it real attention instead of scrolling past 400 file diffs hoping nothing blew up.

The stage isn't just a phase in the workflow anymore. It's a real unit of review.

Revisiting stages doesn't blow away later work

The scary thing about per-stage branches used to be the obvious one: what happens when you hit /haiku:revisit design during development because the specs were wrong? Do you lose all your development work? No.

Revisiting in discrete mode switches you to the target stage branch — the one you're going back to fix. Later stage branches stay intact, untouched. You fix the spec, the product PR gets updated, and when you return to development, the changes merge forward. Your development work is still there. Your new specs are reflected in it. Nothing is lost, nothing gets reinvented, and you didn't have to cherry-pick anything by hand.

This was the blocker for adopting per-stage branches in the first place. Once revisits became non-destructive, stage branches stopped being scary.

Hybrid mode: pick a threshold

Not every intent wants discrete from start to finish. Sometimes the early stages are high-ceremony (specs, reviews, legal sign-off on privacy) and the late stages are a tight build-test-iterate loop where you don't want to wait for a PR per wave.

Hybrid mode fixes that. You set a continuous_from stage. Before that stage, you're in discrete mode — per-stage branches, per-stage PRs, full ceremony. At or after that stage, the discrete branches consolidate into haiku/{slug}/main and the rest of the intent runs continuous from there. One branch, one moving PR, rapid iteration.

You get ceremony where ceremony helps and speed where speed helps. Same intent, two different gears.

How status crosses branches

Per-stage branches create a subtle problem: each stage's state lives on its own branch. While you're sitting on the development branch, where does the engine learn what the product stage is doing? That work is on a different branch, and checking out five branches to read each one would be slow and would thrash your working tree.

It doesn't check out. It reads what it needs straight from each stage branch, in place — no working-tree switch, no stash dance. Browse the intent, or kick off a repair, and the engine pulls the per-stage facts across all the branches in one pass. You see the whole intent regardless of which branch you happen to be standing on.

It's the kind of thing that's invisible when it works. Which is what you want.

Unit worktrees are mode-aware too

Unit worktrees (H·AI·K·U creates a worktree per unit so parallel execution in waves actually works) now know what mode they're in. In discrete mode, a unit worktree branches from its stage branch, not from main. In continuous mode, it branches from the intent branch. In hybrid, it picks the right parent based on where the consolidation threshold sits. You don't configure this. The orchestrator figures it out from the intent's mode and stage position.

Why this matters

Stages used to be a lifecycle concept — a workflow phase, a point in time where the agent was doing "elaboration" or "execution." Now they're also a version control concept. A stage is a branch. A stage is a PR. A stage is a unit of review with a clear diff, a clear description, and a clear merge commit. The lifecycle question ("what phase is this in?") and the review question ("what diff am I asking you to read?") now have the same answer.

The old single-branch model asked one big question. The new model asks four smaller ones.

DivergeOne question vs four

Old model

"Is the work done?" — one PR, one merge, one approval. Reviewers either tackle the whole thing or rubber-stamp it.

New model

"Is inception done? Is the spec done? Is the design done? Is the code done?" — four PRs, four moments to push back, four diffs sized for actual reading.

Smaller questions get better answers.