feat: add KiloCode agent support

[Solar2004]

Summary

Add KiloCode as a supported AI coding CLI in hcom (like Claude, Gemini, Codex, OpenCode). Includes Tool enum variant, LaunchTool, PTY launcher, hook lifecycle handlers, preprocessing, config support, help entries, status checks, and TUI support.

Changes

• Tool::Kilo variant in src/tool.rs
• Full hook lifecycle in src/hooks/kilo.rs (start/status/read/stop)
• src/tools/kilo_preprocessing.rs — bash auto-approval env vars
• src/opencode_plugin/kilo-hcom.ts and hcom_kilo.ts — KiloCode plugins

[aannoo]

good idea but has some issues:

PR #45 - KiloCode Integration

Branch: feat/kilo

Approximate size: +2,008/-67, 29 files

Verdict

Do not merge as-is.

KiloCode is structurally an OpenCode-family tool, but the PR implements it as a mostly duplicated new tool with inconsistent names, wrong upstream paths, broken hook command names, and resume/fork drift. The contributor's instinct to reuse OpenCode-style integration is right; the execution multiplies everything instead of parameterizing the OpenCode family.

What The PR Adds

• New Kilo/KiloCode tool surfaces.
• New hook files and OpenCode-derived plugin code.
• New help specs.
• Kilo-related preprocessing files.
• Resume/fork advertised in help.

Blockers

1. Wrong upstream namespace.

   Upstream Kilo uses kilo, kilo.db, and KILO_CONFIG_DIR. Per packages/shared/src/global.ts the global constant is const app = "kilo", and packages/opencode/src/storage/db.ts returns path.join(Global.Path.data, "kilo.db") with an inline // kilocode_change start - always use kilo.db regardless of channel comment.

   The PR's src/hooks/kilo.rs (get_kilocode_db_path, get_kilocode_plugin_dir, scan_plugin_dirs) and src/commands/resume.rs consistently use kilocode/kilocode.db, $XDG_CONFIG_HOME/kilocode/plugins, and KILOCODE_CONFIG_DIR. The plugin is installed where KiloCode does not read it; transcript_path recorded on the instance row points at a non-existent file; hcom resume cannot replay.

2. Hook command names disagree.

   src/tool.rs registers KILO_HOOKS = ["kilocode-start", "kilocode-status", "kilocode-read", "kilocode-stop"]. The embedded plugin src/opencode_plugin/kilo-hcom.ts invokes nine kilo-* calls and only one kilocode-status. Tool::from_hook_name returns None for the kilo-* names; session binding (kilo-start), message reading (kilo-read), ack, and shutdown all fail to dispatch. Only status updates work.

3. User-facing command mismatch.

   src/launcher.rs recovery text says "Run: hcom hooks add kilo", but src/commands/hooks.rs::HOOK_TOOLS accepts kilocode only. A user following the suggestion gets "Unknown tool: kilo". Direct UX trap.

4. Tool string drift.

   Different code paths use kilo, kilocode, and duplicated KILO_SPEC/KILOCODE_SPEC. The launcher writes tool: "kilo" on the instance row, but src/hooks/kilo.rs calls bootstrap with "kilocode", src/hooks/family.rs registers under "kilocode", and RELEASED_TOOLS includes "kilocode". This breaks detection, help, resume, and future maintenance.

5. Resume/fork is advertised but not reachable.

   src/commands/help.rs ships both KILO_SPEC and KILOCODE_SPEC with has_fork = true. src/commands/resume.rs::build_resume_args only special-cases "kilocode"|"opencode" — and the launcher wrote "kilo" on the row. hcom r <stopped-kilo> falls into the unknown-tool branch instead of using OpenCode-style --session/--fork semantics. Advertised capability, not implemented.

6. Plugin duplication is excessive.

   src/opencode_plugin/ ships three near-identical files: hcom.ts (live, used by OpenCode), kilo-hcom.ts (live, used by Kilo), and hcom_kilo.ts (496 lines, zero references in the repo per git grep hcom_kilo). Future bug fixes to hcom.ts apply to one of three forks; the dead hcom_kilo.ts is unreachable; the kilo and opencode plugins can diverge silently.

7. Dead preprocessing file.

   src/tools/kilocode_preprocessing.rs is added but src/tools/mod.rs declares only pub mod kilo_preprocessing;. The file is never compiled.

8. Coverage is missing.

   There is no PTY end-to-end test for the new tool. A basic test would have caught the hook-name mismatch in Blocker 2.

What To Keep

• KiloCode support is a reasonable feature.
• Treating Kilo as OpenCode-family is the right direction.
• One shared plugin installed to multiple OpenCode-family locations is the likely correct implementation.

Required Shape

1. Model Kilo as an OpenCode-family variant/alias, not a full parallel tool stack.
2. Use upstream's kilo namespace consistently across kilo.db, Global.Path.data, and KILO_CONFIG_DIR.
3. Reuse src/opencode_plugin/hcom.ts through a small template or parameterized install path, installing to both ~/.config/opencode/plugins/ and ~/.config/kilo/plugins/.
4. Delete dead/duplicate plugin and preprocessing files (hcom_kilo.ts, kilocode_preprocessing.rs).
5. Derive help, hooks, launch, resume, and release metadata from a central IntegrationSpec so the tool-string drift in Blocker 4 cannot recur.
6. Add an end-to-end test that proves hook callbacks bind, status updates fire, transcript lookup resolves, and resume/fork behavior uses one consistent tool id.
7. Drop README changes pointing to a third-party fork URL.

Merge Recommendation

Reject. Counter-propose a much smaller OpenCode-family integration, roughly a few hundred lines, using the correct upstream kilo namespace and shared plugin code.

[aannoo]

cfa3ede