Your agent says the tests passed.

Most of the mechanics here exist elsewhere. One I have not found anywhere else: every entry into testing mints a fresh execution id, and a report is accepted only when its execution: field matches the current one.

Fix a failure, go round again, and yesterday's green report is inert. It is not deleted, argued with, or trusted less — it simply stops matching, so passing again costs exactly one honest test run.

Once you approve the plan, which starts the item, the session you work in runs the rest. It dispatches a test-writer, a developer and a code-reviewer per task, running developers, up to the live developer cap, at once in one worktree on tasks whose files overlap no open task, and the plan's task table names a file allowlist for every task. Approval seals it.

kf next reads the ledger, the plan, the reports and the verify logs and prints what is due now: which seat to dispatch, which task to verify, which ledger line to write, which task is complete, and where a judgement is the session's to make. It changes no file and starts nothing; the session still dispatches every seat. kf record writes each ledger line, stamped, under the item lock, and kf next --resume picks a loop up after compaction. Behind it runs one state machine per task, folded from the ledger, with a liveness guard: every open task gets an action, a seat in flight or a wait, or else a stop saying kf next has no rule for it, never silence.

The live developer cap starts at min(2, ceiling), steps up by one after each clean parallel wave and halves (never below 1) on a contention-shaped verify failure; the ceiling is harness.developers.max (integer 1..16, default 6). worktree.domains (boolean, default true) switches the .test domain off: with it false, there are no .test DNS or proxy probes, kf status prints only http://127.0.0.1:<port>, hooks get no KFW_WORKTREE_DOMAIN; ports and routes are still allocated and JSON outputs still carry domain.

After each task commit, kf verify decides the mechanical part, not the developer's report: it checks the files the task changed against the allowlist (--commits for the pipelined loop) and runs the verify commands you pinned in config, plus harness.verify.related with the task's changed files appended, so a task runs only its related tests. Once a wave's tasks are complete, kf verify user-login --wave 1 runs the full suite on the wave's head; the next wave's developers wait until that wave verify passed; kf loop-stats measures where the loop's time went. Before review, kf verify --stage records its run at the item's HEAD, and kf stage review moves only on a passing record (or a waiver the human gives when no stage commands are pinned) — never on the report's word. The review gate reuses the last wave's record when it passed at HEAD, so --stage runs only when kf status does not show PASS at HEAD. The work stops when a review PASS waits for its merge, or earlier with a named reason. The commands kf drive, kf run, kf runs, kf harness were removed.