Runs

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

The list answers questions after the fact. Opening a run gives you the full record of what was attempted: its steps, what the agent decided, what it proved, and what changed.

Each step also shows what Taiga’s own checks concluded: whether the tests it ran after the step passed, and whether the repository’s formatter ran. Tests that failed and checks that did not run show on the step and in a note at the top of the run, so work Taiga did not verify does not read as verified.

The list shows the newest run first, and you can narrow it to the runs that are working, completed or halted; the narrowing is kept in the page address, so a link to the list opens the same view. A halted run shows its error in the list, so you can see why it stopped without opening it.

An initiative’s own runs are listed on its page, under the plan. They are numbered in the order they started, so its first run is Run #1; that is how the initiative’s page, its activity and the breadcrumb from the initiative name the run. The Runs list and its breadcrumb name a run by its initiative’s title with the number after it. A maintenance run has no number and goes by its finding’s title.

A run is a record, not a control panel

Nothing on a run page changes the work. You can move between its steps, open its changes and filter its feed, but none of that starts, stops or rebuilds anything. That is deliberate: a run is the record of one attempt, and by the time you are reading it the decision in front of you is about the work, not about that attempt. You act on the initiative, which is where the work lives.

What you want	Where to do it
Stop a run that is working	Move its initiative out of Build. Setting the initiative aside stops the run it is building.
Carry on after a stop or a failure	The initiative says it needs you and offers Resume build. The steps that already completed are kept, so it does not start from the beginning.
Build the plan afresh	The initiative offers Start over when a run failed or was stopped, or ended without an open or merged pull request.

After a failure or a stop, Start over is the other choice beside Resume build: instead of carrying the run on, it builds the initiative’s current plan, which may be newer than the one this run was built from, as a new run. The old run stays in the list.

Start over is the one that keeps nothing, and the only one limited to initiative work. A maintenance run has no plan to rebuild from, so a fix that needs another attempt is retried from the finding instead.

Normally a run whose pull request is open or merged needs nothing from you, and that is deliberate. Feedback on the pull request needs no control: when someone submits a review that requests changes or leaves a comment, or a check fails, the agent takes it up and pushes fixes to the same branch. A comment on a line is answered in its thread. A request with no line, the summary of a review or a conversation comment that mentions @taiga, is read ask by ask when a review hands the pull request back: the agent makes each change it can, answers each question, and leaves the rest with a reason. It replies to that review once, with a line per ask saying what was done and in which commit, or why not.

A conflict with the base branch needs no request either. When the base moves and the pull request no longer merges, the agent merges the base into the branch, resolves the conflicts and pushes the result to the same pull request, as a merge commit and never a rebase, so your review comments stay where they are. It says on the pull request which files it resolved, so you can check them. A conflict it cannot resolve on its own, such as a file deleted on one side, a binary file or more than 25 conflicting files, is left untouched with a comment naming the files.

The exception is when it gives up. After enough passes without progress, when a pass on failing checks pushed nothing and the checks still fail on the same commit, or when the fixes it made to get the checks passing edited a CI workflow or removed a test, the agent stops working on that pull request and says why on the run and on its initiative: which check kept failing and after how many rounds, which commit a round could not move past, or which change loosened a check. When it stops because its fixes are not getting the checks to pass, it says so on the pull request too. A green check does not make the pull request ready on its own while its description still says why it is a draft: a plan that did not complete, tests that failed after the build, or a fix that loosened a check, such as a suppressed error or a skipped test, instead of fixing the code. The description lists each loosening, and the agent hands the pull request to you rather than marking it ready. Then it is yours: submitting a review on the pull request, requesting changes or leaving a comment, hands it back.

What it is good for

Reconstructing what happened. Open a run to see its steps and their output. When a run 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 run you started over.

The feed is the agent narrating

A step opens with what happened: its feed, with the outcomes it produced first, and a failed step’s error above it. The step’s summary, its acceptance criteria, its plan and its changes follow.

The feed is not a log of tool calls. Agents report events with meaning: a decision and the tradeoff behind it, an assumption made where the input was silent, something worth your attention, a capability that now exists, a test that failed and was rechecked, the self-review verdict.

The assumptions are the entries to read. An agent that meets an ambiguity does not stop to ask. It decides, records the assumption here, and keeps building, because halting on every open question would trade one visible question for hours of silence. The feed is where those decisions wait for you, and reading it is how a wrong assumption gets caught while it is one step old instead of six.

Runs that started themselves

A run says on its own page when nobody pressed anything to start it.

Today that means its plan landed in a product that builds plans as they land, which is your decision taken earlier: either you planned the initiative yourself and the product does not stop to read the plan first, or it reached the front of the queue and its turn came. The wording is careful, because it is still your decision, taken earlier. A run Taiga chose to start on its own would say something different, and nothing in the product does that today.

What it is not

It is not the status of your work. An initiative’s own page is the current truth, and decisions about the work itself, replanning above all, live there.

Reading a failed run

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

A run that failed on something transient, the infrastructure rather than the work, has told you nothing about your code. Resume the build from the initiative; completed steps are kept.

A run that failed on the work itself is telling you something, and the feed is where it said it. Read the decisions and assumptions leading up to the failure before resuming, because a wrong assumption there is the cause, and the failed step is just where it finally showed.

When an agent gets it wrong covers choosing the response.