Kanban Phase 5 — Review (Autonomous)

Argument: <feature_name>.

Stand on quality, not survivor. Load layered review rules, audit the changes, and write a report whose status: is the truth kf trusts.

Invoked through kf run? If your prompt starts with kf-run:, you are a worker for this stage only: skip the "move to stage" step below, never run kf stage / kf approve / kf archive / kf run, never edit approved contract artifacts, do not commit, and end your final message with two lines exactly: STATUS: DONE | DONE_WITH_CONCERNS | BLOCKED | NEEDS_CONTEXT and Summary: <one or two sentences>. The main agent reads them and decides the transition.

---

1. Move to review

kf stage {feature_name} review

(Already there → skip. If the move is refused, run kf validate --change {feature_name} — a missing/stale or non-PASS testing report blocks this direction; loop back through kanban-test.)

2. Load review rules

• Resolve rules per filename in project → user → package order. Include general, security and performance plus the project's stack rule when available.
• Project: {project_root}/.kf/review/rules/*.md; user: ~/.kf/review/rules/*.md; package: kanban-flow/review/rules/*.md beside the installed CLI's package.json. If no rule source is available, report the missing rules instead of silently skipping review.
• Stack packs (node, go, rust, python, php, ruby, java) are opt-in: if the project's stack has no {stack}.md, suggest kf rules (auto-detect) or kf rules --stack <id> to install it — they are not auto-loaded from kanban-flow/review/stacks/.

Review only files actually changed. Record findings with severity HIGH / MEDIUM / LOW. Reproduce plausible failures — don't infer.

AI-assisted code risk lens — hunt for the failure modes AI-generated code produces most:

• Phantom tests: tests that execute code but never assert the behavior the spec requires
• Catch-and-swallow: catches that hide errors instead of handling or rethrowing with context
• Generic helpers without a domain anchor: abstractions invented for one call site
• Scope drift: changes outside the approved contract and task list
• Unrelated broad rewrites: reformatting or refactoring files beyond the diff's purpose
• Polished comments/commits that describe the change but never explain intent or risk

Preserve decisions: do not reopen verified findings or silently undo user-chosen scope, libraries, or thresholds. Before applying a security finding, threat-model it — state what the code stores, protects, and exposes; a finding without a reachable attack path is LOW.

Use the ## Baseline recorded at the top of tasks.md (starting HEAD + pre-existing working-tree changes) to include committed, staged, unstaged and new untracked feature files. Preserve unrelated pre-existing changes. Verify the testing report is PASS for the current execution id. After any implementation fix, loop through testing again before writing a new review result.

Worktree items: when kf status shows a Worktree:/Domain: block, the reviewed changes live on branch kf/<feature> in that worktree — review git diff/git log of that branch (from the main checkout or inside the worktree), not the main checkout's own dirty files. The worktree teardown on archive refuses while it is dirty, so uncommitted review-relevant changes must be called out as a finding.

3. Write review-report

For kind: bug, review against the bug report and existing feature behavior. Check reproduction evidence, regression tests and fix scope; do not demand feature planning artifacts. Record the verified root cause and whether related feature docs need an update. If no documentation changes are needed, say why.

A bug fix is reviewed adversarially, because a narrow fix is the most common way a bug comes back wearing different clothes. Two things go in every bug review report, and "none" is a valid answer only when you say what you looked at:

• Reachable regressions. Name what else calls the code you changed, and what a plausible caller passes that the fix did not consider. A guard added for one entry point rarely covers the others — list the sibling paths and say, for each, whether you checked it or not. Do not write "no regressions"; write what you reached for.
• Claims you disproved. State at least one thing the implementer asserted that you tried to break and could not — the root cause, the blast radius, a "this cannot happen" in a comment. Re-run the reproduction yourself rather than trusting the report, and if an explanation in a comment is load-bearing, verify it instead of reading it. Comments that justify a fix have been wrong in exactly the direction that made the fix look correct.

A test that passes proves the code does something; it does not prove the test would fail if the fix were removed. When a fix turns on one predicate, delete or invert it and confirm a test goes red. A test that stays green under that is not protecting anything, and should be reported as a finding.

kf instruct review-report --change {feature_name}

Fill phase-5-review-report.md, set frontmatter status: to exactly one of:

• PASS — no HIGH blockers; change is shippable
• FAIL — HIGH blockers / broken tests
• REJECT — does not meet DoD / acceptance criteria
• REQUIREMENT_BUG — the requirement itself is wrong vs. real product need

Set execution: to the current id from instruct and keep Review Status/Final Decision consistent with frontmatter. Assess MEDIUM findings against acceptance and DoD; do not declare PASS merely because there are no HIGH findings.

4. The directional gate decides

• PASS → ask the human once: ship or archive directly? Ship (code item, PR/release wanted) → load kanban-ship and kf stage <f> shipping. Nothing to ship (docs/config/research) → load kanban-archive and kf archive straight from review.
• FAIL/REJECT → structural fix needed: loop back, re-implement, then the feature must be re-tested before review again (kanban-test skill).

kf stage {feature_name} implementation

• REQUIREMENT_BUG → STOP FEATURE. Do not silently rewrite the requirement — report back to the user what the review found and ask how to proceed. kf stage blocks all movement here by design.

---

Done

A decisive report written. Hand off:

If PASS: ship gate — kanban-ship when there is something to deliver, kanban-archive when there is not.
If FAIL/REJECT: load kanban-implement (then kanban-test before returning here).
If REQUIREMENT_BUG: stop and report to the user.