Agentification

iKAgent → Agentification (it was Observification; old links still open it) shows how agents check each task at five gates before it can be marked Done. Verification: each gate, how much of the work it saw and what it caught. To fix: the risks that hold a task back from Done, and the bugs found after Done. Validation time: where checking time goes, and what runs by itself. What agent did: each agent run, step by step. A task's risks also show on the task page, in its Check critic card.

Every number on the page counts real, distinct things, from the day its gate first ran for your team, and shows its last 8 weeks, so you can see whether it gets better.

Verification

• Control gates (below) opens the tab.
• Two cards under it: Caught by a gate counts each risk the check critic found once (a risk a newer review filed again is not counted again) and every stale reading the cache guard stopped; Got past every gate counts the bugs found after Done, and its line says how many of the tasks marked Done they hit (a task with two bugs counts once; plan tasks the Roadmap sync closed are not counted). Both cover the last 30 days. See the risks and See the bugs open that list on To fix.
• Banner: names each task that can't be marked Done yet, with its number of open risks. See the risks opens them on To fix. It turns green when every task can be marked Done.
• Control gates: the five checks between the work and Done, in the order they run, for the last 30 days. Each gate has a ring: the share of the work that went through it, green from 80%, orange from 30%, red below, grey with nothing to measure yet. Under it: what the gate found in a few words, its last 8 weeks as a line, the day it first ran for your team ("since"), and a button for the next step. The ? next to the title names each gate and what each colour means.

To fix

Search, beside the team picker, finds a task key, a task title or a word in a risk or bug. The Risks / Bugs switch, beside the tabs, shows one list at a time. Each list shows 4 task cards a page, with Previous, the page numbers and Next under it. A card shows its first 2 risks or bugs; Show N more opens the rest.

• Open risks: one card per task. Under the task: the check critic that found the risks, how many must be fixed before Done, how many are advice, and when. Each risk opens with one line; Show more opens the rest and how to check it. A red Must fix before Done risk keeps the task from being marked Done; an orange Advice · doesn't block Done risk, found before coding, does not. Mark as fixed (or the tick) asks how you fixed or checked it; Accept risk (owner or admin only) asks why it is fine to leave. The risk strikes through and leaves; the task's Check critic card keeps what you wrote. Each new review checks the work again, so it replaces the open risks of the task's older reviews of the same stage ("Filed again by a newer review"): the task shows only what its latest review still finds. When the review before Done is filed, the task's open advice risks close by themselves too ("Checked again by the before-Done review").
• Bugs found after Done: what was wrong, the test that would have caught it, and where it was found (dev, prod, a customer, or Where not said). A bug the runner or a bug task recorded says so. Remove takes a wrong record out of the count; the person who recorded it, a workspace owner or an admin sees it. Tasks marked Done per day shows the last 91 days, darker for more tasks, with a red dot on a day a bug was found after Done.
• The tab's name carries the count of open risks and bugs found after Done in the last 30 days.

Validation time

• Time spent checking work: minutes in the last 30 days; See the runs opens What agent did. Waiting for CI and deploys comes from Pipelines: each CI run counts once, and a stage counts at most 90 minutes (a held or stuck stage is not waiting on checks). Checking in the browser, Running tests and Writing guides and reports come from recorded agent runs (writing counts the time since the agent's previous step, at most 15 minutes, because the edit itself takes only milliseconds), and say "not recorded yet" until a run is recorded.
• What ran by itself: the checks of the last 30 days that no person had to start: test and lint runs and browser steps by agents (from What agent did), CI, build, deploy and smoke stages (from Pipelines, each run once), and bugs found after Done that recorded themselves. Each row links to where you see them.

The check critic

An agent that did not build the work reviews it without reading the builder's conclusion. It is the ikanban-check-critic kit skill, or MCP record_critic_review (the API calls its risks gaps). It runs twice:

Which agent reviews: you pick it in Agent settings → Runners → Which agent reviews, because it depends on the agent subscriptions you pay for. Auto (the default) uses another agent than the builder when Claude or Copilot has finished a run on that laptop, else the builder's own agent in a fresh session. Same as the builder, Claude, Copilot or Gemini names one. Gemini follows its own allow and deny rules, not the runner's read-only ones. If the picked agent files no review, the builder's agent reviews. In another app, such as Claude Desktop, the ikanban-check-critic kit skill does the same review.

Copilot as the check critic needs MCP allowed. Copilot files its review with iKanban's MCP tools. If your GitHub organisation's Copilot policy turns off MCP servers from outside GitHub, Copilot can't reach them (the CLI says Third-party MCP servers are disabled by your organization's Copilot policy), files no review, and the builder's agent reviews instead. An organisation owner turns it on in GitHub: the organisation's Settings → Copilot → Policies → MCP servers in Copilot.

On the task's Check critic card, any member marks a risk as fixed and says how. An owner or admin may accept a risk with a reason instead; the reason and who accepted are kept.

On the runner it runs by itself. When a task runs on your laptop runner, the runner starts a fresh session of the same agent before coding and another after a build that ended well. Neither session sees the builder's conversation, neither may change, commit or push a file, and each stops after 15 minutes. The task's activity says when each review starts and how many risks it found. A follow-up, a Wiki run, a security scan and a turn with customer feedback get no review. Turn it off in Agent settings → Runners → Check critic; it adds two agent sessions to each task run.

Marking Done. While a risk found before Done is open, moving the task to Done is refused everywhere: the board, the task page, MCP update_task, the AI chat, a Roadmap plan sync and automations. The refusal (409) says how many risks are open. On Starter the check critic still reports its risks, and the task can still be marked Done.

Bugs found after Done

When a person or an agent finds a bug in work whose tests passed, the ikanban-missed-bug kit skill (or MCP record_missed_bug) records what was wrong, the test that would have caught it, who found it (person or agent) and where (dev, prod or a customer). That test then joins the feature's map.

A person reports one from the task itself: on a done task, Report a bug found after Done asks what was wrong, the test that would have caught it and where you found it. It also opens the fix task (type bug), in the same project and feature, assigned to you.

Three things also record one by themselves, so the count does not depend on someone remembering:

Each one records once per reopen, bug task or run. If it was not a bug, select Remove on Verification. A bug recorded by itself has no test yet: its row says Test not named yet, and Name the test saves the test that would have caught it. The check critic also names one on its next run on that task.

What agent did

Each agent run, step by step. A tile per plan and phase adds up its runs: time, tool uses and errors, tokens and cost; click a tile to show only its runs, and click it again to show all. Each run card shows the task, the agent and model, who recorded it (the runner or the laptop hook), a badge when the run did not pass (Failed, Stopped or running), time, tool uses and errors, and tokens in and out; its bar is its tool uses, red for the ones that failed. The line under the task is the first line of the agent's last reply, so the card says what the run did. Errors are failed tool uses and the agent's own error messages; npm's log lines ("npm notice", "npm warn") are not errors. A failed step says why it failed (the tool's answer, or why it was refused or timed out). Filter by outcome, and by agent when the team has more than one. The runs show 6 a page, with page numbers under the list. The newest run opens by default; click another run (or press Enter or Space on it) to open it. Where the time went draws one bar per tool the agent used, from start to finish, on the run's own time scale, red when it failed. Below it, every step in order (tool uses, tool outputs, replies, errors); a long step shows two lines, and Show all opens the rest.

• Who records it: the laptop runner, or the kit's trace hook for a Claude Code, Gemini CLI or Copilot CLI session on your laptop. The hook is off until you run node .iKanban/hooks/trace.js --on in the repository and add it to the agent's hook settings (the kit's README has the lines for each agent). Never the model: each trace has a write token that only the recorder holds, kept outside the repository. The check critic's runs are recorded too, marked check critic before coding or check critic before Done.
• What a step produced: a step that made a commit shows the commit id; a step that recorded a check (a review, a closed or accepted risk, a test run) or a bug found after Done links to Verification.
• What is kept: step text is scrubbed of secrets (a key keeps its first 4 characters) and cut at 8 KB per step.
• How long: 30 days on Pro, 90 days on Pro+. What agent did is not on Starter.
• Export: Download trace on a run downloads the run as OpenTelemetry OTLP JSON (GenAI semantic conventions: one invoke_agent span, an execute_tool span per tool call, replies as events). Post the file as it is to a collector's /v1/traces, such as Langfuse. Agents get the same with MCP get_agent_trace and format: "otlp".
• MCP: list_agent_traces, get_agent_trace, get_verification.

Deploy check (cache guard and intent check)

Agent settings → Pipelines → Deploy check, one card per team. Workspace owners and admins change it; members see it.

• Deploy check: on or off. Off: no laptop checks a deploy for this team, even with a local deploy_check block in .iKanban/settings-local.json.
• Deploy commands: one per line. A shell command the agent runs that contains one of them is a deploy.
• Build marker URL: a page that names the commit the site was built from (https, or http on localhost). After a deploy, the agent reads or checks the site only when this page names the commit just deployed.
• Site URL: the page the agent opens to show that the change does what the task asked.

The kit's hook (.iKanban/hooks/deploy-check.js) reads the card with the developer's key at most once in 5 minutes, so a change reaches each laptop within 5 minutes. When iKanban does not answer, the hook uses its last saved copy, else the local deploy_check block.