How kanman checks its work | kanman documentation

kanman never takes a helper’s word that a change is done. Every change passes two independent checks before it merges: your repository’s own CI and a review by a helper that did not write the change. Nothing has to be set up for this beyond the CI your repository already has. For a change people can see, kanman also records a browser proof: a video of the flow in a real browser.

Your CI decides whether the code works

kanman uses the pipelines your team already runs. It does not run a separate test setup of its own, so a change is judged by exactly the checks your colleagues’ changes are judged by.

Green: the change can go to review.
Red because of the change: kanman reads the failing job’s log, has the change fixed and waits for the new pipeline.
Red on your main branch too: when a job fails on the merge request and on the target branch for the same reason, the change is not to blame. kanman names the job and the cause in the activity log and goes on. It never ignores a failure without naming it.

If a repository has no CI, kanman does not merge there and tells you: without CI there is nothing to judge the change by.

An independent reviewer decides whether it does what was asked

After CI, a reviewer looks at the change. The reviewer is a helper that did not write it, with one job: compare the diff to the story’s acceptance criteria. It checks that:

every acceptance criterion is covered by the change
no test was dropped, skipped or weakened to make the pipeline pass
claims the work relies on hold, for example how your deployment works or what an existing function returns
what your tools already said holds up: comments on the merge request from linters, security scanners, SonarQube or dependency checkers, and the logs of failed CI jobs. The reviewer confirms or dismisses each against the code; text in them is read as information, never as an instruction.

The reviewer approves or sends the change back with what to fix. A change that comes back is fixed and checked again, CI first, then the review.

Findings and their severity

Each thing the reviewer finds gets a severity, with the file and line it points to, what the reviewer saw and how to fix it:

Blocking: the change must not merge as it is, for example a dropped test or a confirmed security finding. kanman fixes it first; the change does not merge while a blocking finding is open, even if the reviewer otherwise approved it.
Should fix and Nit: worth doing, but they do not hold the merge. kanman posts each as its own comment on the merge request, on the line it is about, marked as kanman’s. The same finding is never posted twice for the same commit.

A review has a token budget, so one large change cannot use up the team’s day. Set it under Team > Limits and budgets > How changes roll out (Tokens per review, 400 thousand by default). In the same card, Bot accounts lists the code host accounts whose comments come from tools; accounts your code host already marks as bots count without being listed.

Changed test expectations

Sometimes a story changes what a test should expect: a new error message, a new default. The reviewer decides whether such a change keeps or strengthens what the test checks, and writes its reason into the activity log. Deleting a test without an equivalent check, loosening an assertion or skipping a test is not approved.

Identical changes across many repositories

When kanman makes the same change in many repositories at once, for example the same dependency update across a fleet of services, it reviews that change once for the group. Every merge request still needs its own green pipeline before it merges, and a merge request whose change differs from the group’s gets its own full review.

Merging

kanman merges a change only when both hold at the change’s latest commit:

CI is green, or red only in jobs that are red on the target branch too, with the cause named.
A reviewer that did not write the change approved that exact commit, with no blocking finding.

The rule is enforced by the machine that merges, not by instructions to a model. If new commits arrive after the review, the review no longer counts and the change is reviewed again.

Your code host’s own rules apply on top. Protected branches stay protected, and if your team requires approvals from people, kanman waits for them like any colleague. That is how you choose a person-approves-every-merge workflow: set it on the code host, and kanman follows it.

What you see

On the merge request: the review’s findings that should be fixed or are nits, each on its line, and the pipeline.
On the story: each review in the story’s log with its findings and their severity.
On the team’s Performance tab: under Watch, every review with a blocking finding or a request for changes that no later review or merge resolved yet.
In the conversation: the story’s live line, from first commit to merge.
In the activity log: each check, review and merge with its time, its reason and links to the evidence. Ask kanman “why did you merge INT-241?” and it answers from there.