Runs

A run is one execution of a plan. Runs records all of them across the project, including the ones that failed.

It is deliberately read-only. You do not operate work from here, you operate it from the initiative. This surface exists to answer questions after the fact.

What it is good for

Reconstructing what happened. Open a run to see its steps and their output. When a build produced something you did not expect, this is where the evidence is.

Seeing the pattern across runs. One failed run tells you little. Three failing the same way tells you the input is wrong, not the run.

Checking that nothing was lost. Runs are kept when work is set aside. A replanned initiative leaves its previous run here, and so does a build you started over.

What it is not

It is not the status of your work. An initiative’s own page is the current truth.

It is not a place to intervene. If a run is going wrong, the actions that change anything are on the initiative.

Reading a failed run

The useful question is not which step failed but why it stopped, and there are two very different answers.

An agent that halts because something was ambiguous has done the right thing, and the fix is upstream in whatever left it ambiguous. An agent that hit an infrastructure problem has told you nothing about your code.

When an agent gets it wrong covers telling them apart and what each one needs.