How it works

The problem that had to be solved

A language model has a context window. A real software project does not fit inside it — not the requirements, not the existing code, certainly not both at once. Put a whole project into one prompt anyway and you get a sketch back, not a program.

Prompt slicing is the answer: the requirements are not summarised, they aredecomposed. Each TaskSlice is small enough to fit into a prompt completely — together with the context that this particular step needs.

Two axes: phases and slices

Execution runs on two crossing levels. Phases run one after another, separated by barriers: a phase starts only when every work step of the previous one is done. At the end stands a consistency pass over the whole. It is built so that a missing or disturbed measurement never waves anything through: it reports red and sends the affected work steps into capped repair rounds. The measurement itself is optional and not yet switched on in the hosted service. An additional build-and-test pass over the full state is optional; the hosted service runs it. TaskSlices run in parallel within a phase — as many at once as the deployment provides workers.

That is the difference between "typing faster" and "building more at the same time": order is preserved where it matters and dropped where it only slows things down.

REQUIREMENTS: The task description becomes a verified picture of requirements — open questions are recorded as assumptions and stay visible throughout the run.
ARCHITECTURE: Structure, interfaces and dependencies are settled before the first line of code exists.
IMPLEMENTATION: The actual work: each TaskSlice is exactly one AI prompt on one worker, with its own working tree.
RECONCILIATION (optional, on in the hosted service): The parts built in parallel are checked against each other and merged.
TEST: Tests are created as work steps of their own, not as an afterthought.
VERIFY (optional, on in the hosted service): The result is checked against the requirements — not against the intention that produced it.
DOCUMENTATION: What was built gets described while the context is still fresh.
CONSISTENCY: One final pass over the whole: does what was built separately fit together?

Illustration: one large glowing block is split on the anvil into a row of equally sized small billets — an epic becomes stories — An epic pulled onto the trigger state decomposes itself into evenly cut user stories — each one runs only after a human releases it individually.

What a worker does

A worker takes exactly one TaskSlice, executes one AI prompt, validates the result and commits it. No worker sees the overall plan; it sees its step and the context that step needs. Coordination sits with the coordinator, which holds the graph and distributes slices through a durable queue.

If a worker dies, its slice is not lost — it is redelivered. If a slice sits unacknowledged, it counts as demand and a worker is scaled up (optional).

What you see during a run

A run is not a black box. The cockpit shows live what is happening: which TaskSlice is being worked on, which changes it produces and which intermediate steps the model takes.

That includes cost — not summarised at the end of the month, but itemised per TaskSlice: which step consumed how much. If you want to know where a run's time or budget went, the answer is in the run itself, not in a reconstruction after the fact.

The result is a repository, not a suggestion

The result is not a chat transcript someone copies code out of. It is a Git repository with history: every TaskSlice leaves its commit, every phase its state. What sits there is verifiable — by a human, by a pipeline, by an auditor.