> ## Documentation Index
> Fetch the complete documentation index at: https://docs.kanaeru.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Outcomes

> The outcome lifecycle, from queued to completed, and what moves an outcome between phases.

An outcome is Kanaeru's unit of delivered value: one cycle of work that ends in something you can use. Every outcome moves through the same seven phases in order.

| Phase | What happens | Who moves it on |
| - | - | - |
| **Queued** | The outcome is on the roadmap, waiting to start | You, or Kana in a vision session |
| **Planning** | Kana produces blueprints, breaks the outcome into tasks, and writes requirements | Kana, once the required blueprints are ready |
| **Review** | You review the blueprints and plan, resolve understanding gaps, and approve tasks | You, or Koa if you've handed the outcome to him |
| **Execution** | Tasks run through their pipelines in parallel and open pull requests | Kana, once every task is done, deferred, or cancelled |
| **Delivery** | Delivery pull requests are opened, and you review the result against the evidence | You only |
| **Retrospective** | Kana reviews how the cycle went, including metrics and cost | Kana, once the retrospective is recorded |
| **Completed** | The outcome is finished | |

An outcome can only move to the phase directly after its current one. There are two ways back: from **Review** to **Planning**, when you send the plan back with feedback, and from **Execution** to **Review**, when the understanding quiz shows the plan wasn't understood.

## Starting execution

Moving from Review to Execution is the most expensive decision in the lifecycle, so it has extra checks:

* Every task you want built must be approved. Approval checks that the task has requirements, review gates, and acceptance coverage.
* Blocking understanding gaps must be resolved.
* You confirm that Kana quizzed you on the outcome in the review session and you passed.

Once execution starts, Kanaeru starts every task that's eligible and creates its worktree. There's no separate "start task" action.

## Sending an outcome back to planning

If review shows the plan is wrong, send the outcome back to planning with your feedback instead of approving it. In the CLI:

```bash theme={null}
kana outcomes replan <outcome> --reason "The import flow needs to support CSV, not just JSON"
```

## Accepting a delivery

Once the delivery pull request has merged, choose **Start retrospective**. When the retrospective session has finished, choose **Accept delivery and complete outcome** to complete the outcome. This needs at least one retrospective feedback item on record. If the retrospective's drift check shows a **Drift blocker** (a regression shipped), the outcome can't complete until the regression is fixed and the check is re-run, or until you accept the blocker in chat and Kana records your acknowledgement. Open [spec drifts](/concepts/blueprints#spec-drift) don't block completion.

## Working with outcomes from the CLI

```bash theme={null}
kana outcomes list --phase execution
kana outcomes get <outcome-id>
kana outcomes transition <outcome-id> execution --quiz-passed
```

See the [command reference](/cli/reference#kana-outcomes).


## Related topics

- [How Kanaeru works](/concepts/how-kanaeru-works.md)
- [Command reference](/cli/reference.md)
- [Kanaeru overview](/index.md)


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.