Stories
Stories are the units of work that Pipemason executes.
When a program decomposes an intent, it breaks it into stories. A story is a single, self-contained slice of work — sized so it can flow through the per-story pipeline cleanly and be reviewed as one coherent change. Each story is executed by a run: one story, one branch.
How stories are created
You do not write stories by hand. A program's planning stage produces the roadmap, and the stories are the nodes in it. Each story carries enough context to execute on its own and declares which other stories it depends on.
Dependencies and order
Stories are arranged in a dependency graph (a DAG), so a story runs only after the work it relies on is finished. This is what lets a program build something layered — for example, a data layer before the API that uses it, and the API before the web UI that calls it — without you sequencing it manually.
Note
Story status
As a program iterates, each story carries a status you can read in PROGRAM.md and on the dashboard:
- pending — waiting for its dependencies, not yet started
- in progress — its run is walking the pipeline now
- complete — its run finished and the branch is pushed
- blocked / gated — stopped, awaiting a decision or fix from you
When a story stops
A story's run follows the same rule as any run: it escalates rather than guessing when it cannot safely proceed. A blocked story records what it needs in the workspace and pauses; the program does not advance past it until you resolve it and resume.
Stories and the pipeline
Each story is handed to the per-story pipeline, which walks it through the phases from analyze to finalize. See Phases for what each phase does, and the State machine for how a story advances and when it loops back or escalates.