Programs
One specification can span many plans across many services. The workstream graph is persisted and scheduled — not rendered into a prompt and discarded.
What used to happen to a large objective#
A big goal produced a convincing plan with a workstream graph and a milestone roadmap. Both were rendered into prose for the planning prompt and then thrown away. There was no scheduler, no persisted workstream state, and no code path that ever built the second milestone.
A program is the layer that fixes it. It is what lets one specification span many plans, in dependency order, across many services, until the whole product exists.
How a program behaves#
- Dependency-ordered
- Units are scheduled against the graph, and overlapping units are merged before anything is scheduled rather than colliding later.
- Serial branch topology
- Deliberately serial, so the history stays reviewable and merges stay comprehensible.
- A blocked unit does not end the program
- Work that can proceed proceeds; remediation units are raised for what cannot.
- Budgeted
- A program carries its own budget, so a long build cannot quietly become an open-ended one.
- Resumable
- State is durable, so a crash resumes rather than restarts.
The checks still apply, per unit
A program skips nothing. Every unit passes the same checks, and nothing goes live unless they pass — a program is a scheduler, not an exemption.
Common questions
Can I stop a program partway?
Yes, and controls exist on every surface — the command line and the workspace, wherever you open it.