The daily loop

Session start

A fresh session rebuilds context in a fixed order, and it verifies before it trusts.

• The repo's own CLAUDE.md, for the conventions and any kickoff ritual it mandates.
• The repo map, so I never read a 22,000 line spec file whole.
• NEXT.md, the working ledger: what is on deck, what is in flight, what is blocked, and the exact next command.
• Then git. git status, git log --oneline -5, and the repo's own test command.

When the ledger and git disagree, git wins. Commits and merged branches are facts. A ledger is a claim about facts. I fix the ledger first, then continue. Never build on top of an unreconciled disagreement.

Worktrees, one per lane

Every lane gets its own git worktree on its own branch. The primary checkout is the merge point and nothing else. Two agents in one working tree is how you lose an afternoon to a diff neither of them made.

git worktree add ../wt-lane-slashmenu -b lane/slash-menu master

Builds are worktree local. Tear the worktrees down at the end of a wave: mine leak three to four gigabytes of build output each.

The loop itself

Frame, decompose, red tests, dispatch, verify, kick back or merge. Module 2 covers the first three. This is the back half.

Dispatch runs lanes in parallel, but not many. I cap four builders at once plus one validator. Eight at once hit my session limit in one wave, and eight parallel test builds pushed the machine load past 900 and killed simulators. Parallelism has a ceiling and it is lower than it looks.

Verify is mine and it is adversarial. I re-run the tests myself. I read the diff. I check the changed file list against the scope list before I read any logic. For a merge to the main branch I add an Opus 4.8 validator with no authorship bias.

Kick back names the gap: the failing assertion, the unread edge case, the missing evidence. It is a fresh dispatch with a new pack and the new numbers, never a resumed conversation. Two misses on one unit means the unit is mis-scoped. Split it.

Merge is mine. Always.

Compaction discipline

Anything that lives only in the conversation dies at a compaction. I lost a background task handle that way once and rebuilt the state from worktree branch names.

So the rule is: the moment a fact exists only in context, write it to the ledger. Background task handles, branch names, in flight intent, the exact next command. Then /compact costs nothing.

The ledger skeleton

# NEXT

## Now
The single active task, with the exact next command to run.

## Next
On deck, in priority order.

## Blocked
What is blocked, on whom, and what unblocks it.

## State
Branch, test status, open PR numbers, background task handles, anything a fresh
session needs to trust but verify.

Keep it short. Mine is capped at 150 lines and a test enforces the cap. Older entries roll into a dated archive file, verbatim, rather than being deleted.

Set it up

1. Create NEXT.md in your repo with the four sections above, if it does not have one.
2. At session start, read CLAUDE.md, then NEXT.md, then run git status and the test command before doing anything.
3. Add one worktree per lane, on a branch that is not your main line.
4. Cap parallel builders at four. Add the fifth only when you have measured that your machine can take it.
5. After every returned lane, re-run the tests yourself and read the changed file list before the diff.
6. Before any long build, any session end, and any compaction, write the state to NEXT.md. Commit the tree first.
7. Tear down the lane worktrees when the wave lands.

What you can do now

You can run a full day of lanes and pick the work back up cleanly in a fresh session tomorrow.

Next module

Module 7 is how a model earns a place in the routing table: the calibration protocol, and the hold list.