version: "1.0.0" name: kanban-test description: 'Test a kanban feature against its approved test plan or a bug against reproduction and regression scope. Write current-execution results with PASS/FAIL/REJECT/BLOCKED. Use in testing.'

Kanban Phase 4 — Testing (Autonomous)

Argument: <feature_name>.

Prove the feature against the plan's test cases. The report's status: IS the decision — kf stage reads it and blocks the wrong direction.

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 testing

kf stage {feature_name} testing

(Already there → skip.)

If kf stage refuses the move, run kf validate --change {feature_name} to see what is missing — unfinished tasks.md checkboxes block entry to testing (DoD), so tick them in implementation first.

Every entry to testing creates a new execution id. Keep old reports as evidence, but never reuse them as proof for the current implementation. Read the current id from kf status or kf instruct ... --change.

2. Run against the plan's test cases

Read the Test Strategy from phase-1-spec-requirement.md (Test Level / UI Tests / Tools / Coverage Target) — it was committed in the approved plan. Detect the real test tooling from the repo. Execute exactly what the level promises: unit → unit suite; unit+integration → + integration; full → + UI/E2E suite (Playwright/Cypress/...). If full and the UI tests are missing or skipped, that's a gap — report it, don't fake coverage.

Track TC-by-TC: Status / Actual / Expected / Tool / Evidence.

For kind: bug, use the bug report's reproduction, expected result, acceptance criteria and regression strategy instead of a phase-2 test plan. Verify the defect is fixed and run the affected regression suite; use descriptive test IDs or actual test names in the results table. Do not require FR/UC/TC artifacts for a bug.

3. Write testing-result

kf instruct testing-result --change {feature_name}

Fill phase-4-testing-result.md, set frontmatter status: to exactly one of:

• PASS — all tests pass, coverage target met
• FAIL — tests failing
• REJECT — feature does not meet acceptance criteria
• BLOCKED — cannot test (env/tooling)

Always write the report, including execution: from the current template. Include per-TC results, actual commands, evidence and coverage against the approved target. In the "Commands and Evidence" table the Exit code column must be the real numeric exit code of each command you ran; kf validate rejects a PASS report that has no command row or any exit code other than 0 (testing_exit_code). Keep status and conclusion consistent. Missing tooling, skipped required tests or unmeasured required coverage cannot count as PASS. Write outcomes here; keep phase-2-test-case.md unchanged.

4. The directional gate decides

• PASS → kf stage {feature_name} review
• FAIL/REJECT → loop to implementation, apply the fix, then enter testing again and write a result for the new execution id:

kf stage {feature_name} implementation

...then return here and re-test before attempting review again.

• BLOCKED → stop and report the environment/tooling blocker. Do not advance or substitute a known issue for required passing tests.

Still failing after one fix cycle → STOP, show failing tests, ask: fix deeper / record as known issue / abort.

Done

Report written with a decisive status. Hand off:

If PASS: load the kanban-review skill.
If FAIL/REJECT: kanban-implement first, then testing with a new execution id.
If BLOCKED: stop and report the blocker.