[martin-conur]

Summary

kiro workers can't show the ❓ "waiting on you" tab or trip the monitor's worker-awaiting signal, because kiro-cli 2.32.0 has no hook that fires while it waits on the user. There is nothing to wire, so this PR documents the gap with the evidence and the version checked, wherever the docs describe ❓ / worker-awaiting.

Closes #278

Findings (kiro-cli 2.32.0)

• No trigger. The agent-config hooks field accepts exactly agentSpawn, userPromptSubmit, preToolUse, postToolUse, stop (the trigger enum in the binary). No permission or notification trigger, unlike claude's PermissionRequest.
• No tool to match. No ask-the-user tool. The one confirm tool, switch_to_execution ("Ready to exit [plan] agent…"), belongs to kiro's built-in kiro_planner agent. No task-force kiro agent lists it in tools, and radio's hooks don't run inside kiro_planner.
• No payload field. Hook payload keys are hook_event_name, cwd, session_id, tool_name, tool_input, tool_response, assistant_response, with no approval-pending marker.
• No file substitute. The live sessions' ~/.kiro/sessions/cli/*.jsonl record only Prompt / AssistantMessage / ToolResults / Clear / Compaction. The V3 (KAS) engine has an awaiting_approval tool-call status in its session files, but it's unverified whether that's written while the prompt is up, and using it would mean polling rather than a hook.

How I probed

• Version: "/Applications/Kiro CLI.app/Contents/MacOS/kiro-cli-chat" --version → kiro-cli-chat 2.32.0.
• Static: strings over that binary (trigger enum, hook payload keys, tool names, status enums). Read-only ls/jq over ~/.kiro/sessions to see the session-log shapes.
• Live: a wrapper ran kiro-cli-chat directly with env -u TASK_FORCE_ROLE -u TASK_FORCE_PM_ROLE -u ZELLIJ -u ZELLIJ_SESSION_NAME HOME=<scratch> TASK_FORCE_HOME=<scratch>/tf, in a scratch workspace with a throwaway .kiro/agents/probe.json whose five hooks each appended the trigger name to a log file. execute_bash was left out of allowedTools to force an approval prompt. The only settings write (chat.enableAutoAgentUpgrade false) went to the scratch HOME.
• Disclosure, auth: to get past login under the scratch HOME I copied ~/Library/Application Support/kiro-cli/data.sqlite3 into the scratch HOME. I deleted it right after the probe. A find ~/.kiro -newer check afterwards showed nothing in the real ~/.kiro changed.
• Result, limited: the account hit its monthly usage limit before the model replied, so the approval-prompt ordering (does stop fire before the prompt?) could not be observed. The docs say "most likely busy" and call it unverified. A side observation: on that failed request, userPromptSubmit fired and stop did not, so a kiro tab may stay busy after an API error. That's out of scope, but it may be worth a ticket.

Changes

• README: a new "No awaiting state on kiro" subsection under kiro delivery, a "no waiting-on-user trigger" row in the kiro hook table, and the monitor Attention paragraph links to it.
• docs/task-monitor-schema.md, .claude/gh-workflow.md and all seven steering templates: "claude-only for now" becomes the gap plus the kiro-cli version checked.
• tests/task_monitor_snapshot.bats: a doc test pins the wording, the version and the README anchor. It passes on the tree, and it went red when I restored the old kiro-local doc and when I broke the anchor.
• CHANGELOG entry. Upgrading: nothing required.

Green

• ./run_tests.sh: 1461/1461 ok. The new test was also run on its own: ok.
• tools/check-drift.sh: 15 groups OK. No shell files changed.

🤖 Generated with Claude Code

[martin-conur]

Spec compliance

Issue #278 asked to investigate whether kiro-cli exposes a "waiting on the user" hook. If it does, wire it. If it doesn't, document the gap wherever ❓ / the monitor describe it, with the kiro-cli version checked.

• The PR takes the "not possible" branch and documents it. The version (2.32.0) is named everywhere.
• Every place that said "claude-only for now" is updated: the README Attention paragraph, a new README section and hook-table row, docs/task-monitor-schema.md, .claude/gh-workflow.md, and all 7 steering templates. A repo-wide grep finds no remaining "claude-only for now" outside old CHANGELOG entries and the test that asserts its absence.
• The scope bullet "probe with a scratch HOME / TASK_FORCE_HOME" is honoured, and the PR is candid that the live probe hit a usage limit. The unverified busy-during-approval claim is labelled unverified in the CHANGELOG, README and schema doc ("most likely").
• The PR body opens with ## Summary.
• CI ran on the head SHA (gh run list -c <sha> returns 1).

Code-review findings

No code changes, so there is nothing to find on correctness or security.

• New doc test: I ran ./run_tests.sh task_monitor_snapshot and all 47 tests pass, including the new one. The grep -qF patterns match the wrapped lines exactly (the signal sentence is on one line in each doc), and the negative claude-only for now check is meaningful.
• Not re-verified: I did not re-probe kiro-cli's binary. The claim that the hook trigger enum is exactly 5 values, and the kiro_planner / switch_to_execution details, rest on the author's investigation. They are version-pinned and hedged where unverified, which is the right shape for a doc claim.

Verdict

clean. The investigation is documented with evidence and a version, the docs are consistent across all loadouts, and the doc test pins them. Nothing to fix in this PR. Merge is PM's call.