Skip to main content
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. 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:

​
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 don’t block completion.

​
Working with outcomes from the CLI

See the command reference.