Vision
The vision is the long-term result you’re aiming for. One vision usually takes several outcomes to reach, and you can refine it as you learn. Each vision lives in its own workspace: creating a workspace means describing a vision.Roadmap and backlog
The roadmap holds every item needed to reach the vision. Items come from you, from Kana’s suggestions, and from your connected tools. Proposed items stay proposed until you accept them. Items that aren’t part of an outcome yet sit in the backlog. They wait there until they’re scoped into an outcome. Kana’s auto-suggested items wait there too, for you to review. A refinement session is where you shape the roadmap with Kana. Start one with New Refinement. In it, Kana can:- reorder, merge, split, and clarify items
- check whether an item already exists before adding a new one
- pull in detail from your connected tools and the code
- group backlog items into new or existing outcomes
Outcome
An outcome is one cycle of work toward your vision that ends in something you can actually use. It groups roadmap items into a deliverable and moves through a fixed lifecycle: planning, review, execution, delivery, and a retrospective. See Outcomes.Tasks, journeys, and blueprints
In the outcome’s planning session, Kana breaks it into tasks. Each task covers one or more user journeys, the paths a user takes through what you’re building. Each journey carries:- Acceptance criteria: scenarios written as Given / When / Then. A task isn’t done until its acceptance tests pass.
- Blueprints: the designs that journey needs, generated before any code is written so you can check what Kana understood.
See Blueprints for every type and how to review them.
Tasks without a declared dependency run in parallel.
Understanding gaps
An understanding gap is a place where what Kana understood may not match what you meant. She raises it at the narrowest level it affects: one journey, one task, the task list, or the whole outcome. Some gaps are routine: missing information, an ambiguity, an assumption to confirm, or a recorded decision. Others are blocking: a risk, an escalation, a spec gap, intent drift, a comprehension check, or context only you hold. Blocking gaps must be resolved before execution can start. See Understanding gaps.Review
You review the plan in the Plan & Review section of the outcome, in the same order it was built: the task breakdown, then each task’s journeys, then each journey with its acceptance criteria and blueprints. Start Outcome stays locked until everything it depends on is in place:- every task you want built is approved, with its requirements reviewed
- every blueprint is approved, with no open blocking annotations
- no blocking understanding gaps are left
- you’ve passed Kana’s quiz
Pipelines
As each task becomes ready, a task planning session designs its pipeline, the exact steps that will build and check it. An independent reviewer checks the plan before any step runs. A pipeline has three levels:- Phases: always Biz Logic, API, UI, QA, and Deploy, in that order. A phase that doesn’t apply is skipped with a recorded reason.
- Layers inside each phase, matching the parts of the codebase. Biz Logic has domain and use-case layers. API has controllers, adapters, and API clients. UI has components, pages, state management, and front-end use cases.
- Steps inside each layer, run one at a time.
- Build. Most layers write the code first, then its tests. Use-case layers are test-first: the tests, and the interface they define, come before the implementation. Every piece of generated code is lint-fixed immediately.
- Review and fix. A review step checks the code or the tests just written. If it rejects the work, the pipeline sends it back to the step that wrote it, then reviews it again. After a few rejections, an escalation judge decides whether to accept it, send it back again, or block it for you.
Delivery and retrospective
Task pull requests merge into the outcome’s own branch (outcome/<id>). When the last one has merged, Kanaeru opens one delivery pull request per repository, from the outcome branch into your default branch. Merging it ships the whole outcome at once. If you’d rather review another way, ask Kana. For example, she can stack task pull requests or merge each one straight into your base branch.
Once the delivery pull request is merged, choose Start retrospective. The retrospective covers what went well, what didn’t, and what it cost. Once at least one piece of feedback is recorded (yours or Kana’s) and you’ve checked the evidence package (test results, diffs, approvals, and gate results), choose Accept delivery and complete outcome. Findings from the retrospective are saved as learnings that later Kana sessions draw on, so the next outcome starts where this one left off. See Learning loop.