These screenshots follow a single story through the console on a small demo project, a personal bookshelf app. They are captures of one run, including the attempts that failed, because those are part of the record too.
The pipeline has five columns and a story only ever moves left to right across them. You decide twice: whether a suggestion is real work, and whether what came back delivers what was asked. Until requirements exist, the NEXT line says so, and nothing downstream can be planned or built.
Analysing a short brief for a bookshelf app produced eight requirements, each with its relationships stated: waits for, constrained by, needed by. Drafts are not scope. Agreeing one, here R3, makes it part of the scope and accepts the checks attached to it, and story S1 is planned from it.
Laid out in dependency order, so what a requirement depends on sits to its left. The colour of a node is its state, and the legend underneath spells out every state and every kind of link, so nothing has to be inferred.
The first build of S1 reached a question it would not guess at. It stopped, put the question on the story card with the button that answers it, and the NEXT line points there. Nothing restarts on its own, and answering records your call.
Inside the run there are six fixed stages, from reading the story to putting the pieces together. The story was broken into tasks, each worked by two independent workers on a local model, and the timeline replay shows each worker’s activity as it happens.
Every task shows its workers with the turns and tokens they used, and red marks a candidate that failed. When the last task failed in both workers, a repair round started with four further attempts rather than handing a broken result upwards.
Every worker attempt on one axis, green where it passed and red where it failed, including the repair workers. This is the recorded session rather than a reconstruction after the fact, and it can be replayed at 1×, 4× or 16×.
The build finished and landed in Came back with its commit named on the card. This is the second decision: accept the delivery, or send it back. Nothing behind it moves until you decide.
Accepted, so the story is done, with its check verified and its commit recorded on the card. The run that produced it stays one click away.
Back in requirements, R3 now reads delivered, with 1/1 checks passing and S1 as the story that delivered it. The trace runs both ways: from the requirement to the commit, and from the commit back to what it was for.
All six stages complete. The graph and the timeline are kept as they were, failed attempts included, so whoever audits this delivery later sees what actually happened rather than a summary of it.
Two decisions from you, everything between them done by the machine, and a record you can walk back through afterwards.
Agentic software development with full traceability, built on ZeroZ4j by Franz Schöning, Principal Enterprise Architect.