feat: add Kiro CLI adapter

[mvanhorn]

Summary

Adds a Kiro CLI adapter to agent-manager so AI DevKit can detect, list, start, and route messages to Kiro CLI sessions, the same way it already does for Claude Code, Codex, Copilot, Gemini CLI, OpenCode, and Pi.

Why this matters

Closes the maintainer-declared work item in #109 ("Support Kiro CLI in agent-manager"). Kiro was the one requested coding agent not yet wired into the adapter layer, so agent list, agent start --type kiro, agent sessions --type kiro, and the channel bridge had no way to reach it.

Changes

• New KiroAdapter (packages/agent-manager/src/adapters/KiroAdapter.ts), mirroring the existing PiAdapter: process detection, PID-to-session tracker matching, defensive JSONL session parsing, conversation/listSessions support, and idle/waiting status. Reads sessions from ~/.kiro/cli/sessions and gracefully returns empty results when that directory is absent.
• Extended the AgentType union with 'kiro' and exported KiroAdapter from adapters/index.ts and agent-manager/src/index.ts.
• Registered kiro in the AGENTS registry (launch command kiro-cli; process matcher accepts the kiro-cli or kiro basename) and added it to StartableAgentType.
• Registered new KiroAdapter() in both AgentManager factories (cli/src/commands/agent.ts and cli/src/services/channel/channel-runner.ts), added the Kiro display label, extended the --type help text, and added 'kiro' to VALID_AGENT_TYPES.
• Updated the README agent-support table to list Kiro CLI.

Testing

• New KiroAdapter.test.ts (type identity, kiro-cli/kiro process matching with no false positives, session detection) — agent-manager suite: 435 passed.
• Updated sessions.test.ts, agent.test.ts, channel.test.ts, and StartAgentPane.test.ts for the new type/registration/cycle order — cli suite: 808 passed.
• nx run-many -t build -p agent-manager (swc + tsc typecheck) and nx run-many -t lint -p agent-manager cli both clean.

Fixes #109

AI was used for assistance.

[codeaholicguy]

Hi, thank you for your contribution, but this PR doesn't seem to resolve the integration. I'm not sure that it was tested or not. There is no such ~/.kiro/cli/sessions when Kiro is running.

There are things that can give you hints to solve the integration:

• All Kiro sessions are stored under ~/.kiro/sessions/cli/
• When a session is running, there will be a lock file in the session folder such as `~/.kiro/sessions/cli/.lock; this file will contain PID info; we can use this to map with process. If the session is ended, the lock file will gone.
• ~/.kiro/sessions/cli/<session-id>.json contains all metadata of the session, such as cwd, etc
• ~/.kiro/sessions/cli/<session-id>.jsonl contains the conversation history, including user message, assistant message, tool use, etc

Please make sure you test all the workflows, from agent list, agent send, agent open, and all the features work well with the new agent type (kiro) in the agent console.

Thank you.

[mvanhorn]

You were right, it was not tested against a running Kiro and the path was wrong.

Now reads ~/.kiro/sessions/cli/, discovers running sessions from the lock file in that directory, and resolves each lock to its sibling metadata and transcript, rather than scanning ~/.kiro/cli/sessions which never exists.

431 tests pass in agent-manager, typecheck and lint clean. I still have not been able to run it against a live Kiro session, so if you can spot-check the lock and transcript shapes against a real one that would help.

[mvanhorn]

@codeaholicguy thanks for the pointers, they were exactly what was needed. Pushed in 27ec937.

The adapter now reads sessions from ~/.kiro/sessions/cli/ instead of the ~/.kiro/cli/sessions path that never existed, and it treats the per-session lock file as the running signal: a session counts as active only when its lock file parses and its PID belongs to a live Kiro process. Malformed locks are ignored, and a lock whose transcript is missing still surfaces the process rather than dropping it.

Tests cover the running-session mapping, the PID liveness check, malformed lock files, and the missing-transcript case.

Ready for another look when you have time.

[mvanhorn]

@codeaholicguy before I port this onto the current adapter layout (main has moved far enough that it is a re-implementation, not a rebase): is a Kiro CLI adapter still something you want in ai-devkit? If yes, I will redo it against main with the lock-file session discovery you pointed me at and keep the diff to the adapter plus its tests. If the answer is no, or it is on hold, I would rather close this than leave it conflicting in your queue.

[codeaholicguy]

@mvanhorn yes, if possible, please sync with the latest structure and update the PR, I will follow up after the PR is updated

[mvanhorn]

Synced. The branch is now rebuilt on current main rather than trailing it, so the diff is just the Kiro adapter against today's structure.

What changed in the port:

• Process discovery follows GrokCliAdapter now. The adapter declares processNames and resolves against the shared AgentDetectionContext snapshot when one is passed, falling back to captureProcessSnapshot only when called standalone, so the manager scans processes once per refresh instead of the adapter doing its own listing. node is in processNames because Kiro can run under it; canHandle still narrows on the kiro basename.
• Registered in the adapter index, the StartableAgentType union and the AGENTS registry, the CLI --type filters, and the docs.
• Formatting matches current main (oxfmt clean on the files this touches).

The Kiro suite is 12/12. Running the agent-manager suite before and after this change gives the same 224 pre-existing failures on main, with 13 more passing tests after, so this adds coverage without touching anything that was already red.