Decisions
Everything that needs a human lands in one place: the decision inbox. Each decision comes with kanman's recommendation and a few clear options.
kanman works on its own until it reaches something it should not decide alone. Then it stops and asks. All of these questions land in one place, the decision inbox, so nobody has to watch chat threads, PR comments and tracker notifications to find out what kanman is waiting for.
Click the inbox icon in the top bar (or press G then D) to open Decisions. A yellow number on the icon shows how many decisions are pending. The inbox has two tabs with their own addresses: Pending (/<workspace>/decisions) and Resolved (/<workspace>/decisions/resolved). Each decision has its own page at app.kanman.ai/<workspace>/decisions/<decision-key>, for example dec-4h2k.
What a decision looks like
Every decision has:
- a title that says what is being asked, for example Raise budget for this run?
- a body with kanman’s reasoning and the context: the story, the run, the gate output or the policy rule involved
- a recommendation: the option kanman would choose, shown after I recommend:
- 2 to 4 options, each one a concrete action
kanman writes “I” in decisions. It is one teammate, not a group of bots.
Each decision in the inbox names its story by key and title, so several “Ready to merge” questions are easy to tell apart, and shows when it was asked. Answering one shows your answer in its place before it folds away. The inbox has the tabs Pending and Resolved and can be filtered by kind and sorted by age. Weekly team reports you have not opened yet are shown above the tabs.
In the conversation, the same decision is answered with one click on the card:
Kinds of decisions
| Kind | When it comes up | Options |
|---|---|---|
| Plan approval | The policy requires approval of the plan before code | Approve plan, Request changes, Reject |
| Policy exception | A run needs something the policy denies, for example a denied path or a repository that is not allowed | Allow once, Reject |
| Question | The executor asked a question it cannot answer from the story | The answers kanman offers, or Answer and Stop this run |
| Budget stop | A run reached its budget | Raise to twice the run budget, Abandon |
| Scope change | The change is larger than max_changed_files or max_changed_lines allow |
Narrow the change, Allow this size once, Reject |
| Check failed | kanman could not write an acceptance spec that runs, fails before the change and tests the real app | Write the spec again, Keep it in Refining |
| Narrow, keep going or drop | The same failure came back after kanman checked the same code again and tried a different approach, or the story used its attempts | Narrow it: leave out what keeps failing, Keep going: one more attempt, Drop it for now |
| The spec contradicts the story | The same check failed twice and kanman found that the acceptance spec contradicts the story, not the code | Change the spec to match the story, Narrow it: leave out the contradicting part, Drop it for now |
| Verification failed | The rework attempt failed the gate as well (on the days kanman still works the earlier way) | Retry once more, Abandon the run |
| Diff guard | The implementation changed the acceptance spec | Revert spec changes and retry, Reject |
| Repeated gate failure | A gate failed more often than the failure budget allows | Retry with my guidance, Retry as is, Stop this run |
| No change made | A new attempt after failed checks ended without a new commit, so kanman did not run the same checks again. The decision quotes what kanman said at the end of the attempt. If the check that failed last was the reviewer (a model’s judgement) or judged an older commit, kanman recommends checking the current code again, without a new attempt. See Checking the current code again | Retry with my guidance, Re-run the checks on the current code, Retry as is, Stop this run |
| Ready to merge | All checks passed and the team’s merge policy asks a person to merge. Only owners and admins can choose Merge; if the code host refuses, the decision stays open and says why | Merge, Not now |
| Merge approval | All checks passed, but the change is larger than the auto-merge limit, or the code host refused kanman’s automatic merge | Merge, Do not merge |
| Merge request closed | The pull request was closed on the code host without being merged | Stop the run, Keep it in Review (I reopened it) |
| Main branch is red | CI on your main branch turned red; kanman holds its automatic merges | Keep holding merges while main is fixed, Release the merge hold |
| Revert approval | A pull request from a kanman run is the likely cause of a red main branch, and kanman opened a revert | Merge the revert pull request, Close the revert and fix forward |
| Your change and a red base | A colleague’s merged change turned a default branch red, and kanman opened a fix or a revert. Only the author gets it, with their next summary, see When someone else’s change turned the branch red | Merge the fix, I’ll handle it, Not my change |
| Obstacle alarm | One problem kanman is working on has held up all of a team’s work for two working hours. It comes at once, see When one problem holds up all the work | I’ll take it from here, Keep it with kanman |
| Maintenance proposal | A maintenance finding is not on the team’s allowlist | File as story, Dismiss |
| Strategy proposal | Maintenance mode proposes a feature based on your STRATEGY.md |
Start intake, Decline |
A decision is never created for transient failures such as a network error; kanman retries those on its own (see Runs).
Note
Decision titles, bodies and most option labels are written in English for now. The options of plan approvals, policy exceptions, scope changes and budget stops follow your language setting.
Example: a denied path
The Balanced preset denies infra/**. If a run’s change touches infra/alarms.tf, the run stops with status Blocked by policy and the run page says Path infra/alarms.tf is not allowed by policy Balanced. The decision offers Allow once and Reject, and kanman recommends Reject: the rule exists for a reason, and an exception only applies to this run.
If you choose Allow once, the card says You allowed it once. The policy is unchanged. The run goes on with that one file allowed, also through kanman’s checks and a second attempt if one is needed, and the next run is blocked again. To see the policy itself, ask kanman “Show me the policy” in the team’s chat: its settings open with the paths kanman must not change.
If you choose Reject with the note “Infra changes go through ops”, the run ends and the story returns to Backlog with your note as a comment. The audit log gets a policy_decision entry with the result denied and a decision_resolved entry with your name.
Who can answer
Every member of the workspace can answer decisions. Options that end or reject something ask for an optional note before you confirm; approvals take one click. Answers record who decided, when, how (the app, Slack, MCP or the API) and the note.
When you answer, kanman continues right away: a plan approval starts implementation, a raised budget resumes the run, a rejection returns the story with your note.
What kanman decides alone
Not every choice is a decision for you. kanman sorts each choice into one of three authority levels:
- AUTO: it acts and logs it.
- NOTIFY: it acts and records a notice.
- ESCALATE: it stops and asks in the decision inbox.
The table is fixed and deterministic, and a team can only make kanman more careful, never less. See Policies, presets and authority levels.
Statuses
| Status | Meaning |
|---|---|
| Pending | Waiting for an answer. Decisions do not expire; the run waits until someone answers |
| Waiting on the same question | kanman already asked this question; your answer to the open one answers this one too |
| Resolved | Answered |
| Superseded | No longer needed because the situation resolved itself, for example main turned green again |
kanman closes questions that no longer apply on its own, within about 15 minutes, and notes why on the decision: the story reached Ready (for “cannot reach Ready yet”), the run ended or a newer attempt took over, the story is done or was deleted, or someone resumed a paused run with Undo. An answer you gave first always wins.
Notifications
kanman tells you about new decisions in two ways:
- the number on the decisions icon in the top bar of the app
- at the top of the run page of the run that raised it, where you can answer it right away, and in the Setup card of a new team (Review the plan)
- a message in the team’s Slack channel with buttons to answer, if your workspace has Slack connected. See Answer decisions from Slack
Decisions about the stories of an outcome are collected on the outcome’s card in the team chat and grouped by outcome in Decisions, one question at a time, and the same question for several stories is asked once. See What an outcome needs from you.
kanman never asks you the same thing twice. When a question comes up that is already open, it waits on the open one, and your answer goes to both. When you already answered a question about access or about what you want, the same question later gets your answer without asking again; you see it on the decision. A question about a single attempt, such as whether a run may go on, is always asked fresh.
You can also answer a decision right in your conversation with kanman (the message carries the decision card) or in a Slack thread by replying, for example “approve dec-4h2k”.
Related
Last updated: January 1, 0001
Open kanman