cascade
Cascade — cascading development loops
The move: don't charge at a big task, cascade it. A blunt prompt — "do X, and make no
mistakes" — is the signal to STOP and plan first, not to start typing. You replace one
unstructured push with a chain of bounded loops: each loop produces one state change,
proves it with checkable artifacts, and its EXIT triggers the next loop. Between loops you
either flow straight through or pause for the user's go/no-go (see Pacing). Nothing advances
on vibes: an exit criterion that can't be pointed at (a passing test, a live trace file, a
scoreboard delta, a merged PR verified at HEAD) is not a criterion. This is the same
discipline the product ships (loop_until with an accept contract, bounded rounds, honest at
the bound) applied to our own development.
Pick the branch
- PLAN — the user hands a goal, plate, issue, or lever list. Cut it into a chain doc + task graph. Do this before any BUILD.
- ADVANCE — a chain exists and a loop is mid-flight. Find position, run the next ribbon step.
- TAKEOVER — resuming after a gap, a compaction, or inheriting another session's chain. Re-evaluate the priors skeptically before advancing — prior-you's conclusions (especially anything inside a noise band) get a fresh read, not automatic trust.