[P0.29] Kilocode adapter invokes a `run` subcommand that does not exist — the CLI opens the TUI and the task hangs

[frankbria]

Found while building the binary-gated engine tier for #915 (P0.21) — this is exactly the defect that tier exists to catch, and it is the third shipped engine with an invented invocation (after #913 opencode and #914 codex).

Problem

KilocodeAdapter.build_command (codeframe/core/adapters/kilocode.py:84) builds:

[binary, "run", prompt, "--auto", "--workspace", str(workspace_path)]

There is no run subcommand. Verified against kilocode 0.22.0 — kilo --help declares Usage: kilocode [options] [command] [prompt] and its only commands are auth, config, debug, models. The prompt is a bare positional.

So run is consumed as the prompt, the real prompt becomes a stray argument, --auto never takes effect, and the CLI opens the interactive TUI and hangs until the adapter's timeout. --engine kilocode cannot do any work at all.

Evidence — reproduced live, both directions

Broken (exactly what the adapter builds):

$ kilo run "Create a file kilo_probe.txt containing exactly: works" --auto --workspace $D
exit=124            # killed at the 120s timeout
$ ls $D             # nothing written
out.log             # contains the Kilo Code TUI banner (ASCII art)

Working (identical, minus the bogus subcommand):

$ kilo "Create a file kilo_probe.txt containing exactly: works" --auto --workspace $D
exit=0
$ ls $D
kilo_probe.txt      # ' Task Completed / Created kilo_probe.txt with the content "works"'

--workspace is honoured (the file landed in the target dir), so unlike #1007 there is no cwd problem here — only the invented subcommand.

Why it shipped green

tests/core/adapters/test_kilocode.py asserts the adapter agrees with itself: it checks build_command contains "run" — pinning the bug rather than the CLI's contract. No test runs the real binary. Same mechanism as #913.

Acceptance criteria

• build_command produces kilo <prompt> --auto --workspace <path> with no run
• The unit test asserts against the CLI's documented surface, not the adapter's own output — i.e. it fails if run is reintroduced
• A binary-gated smoke test drives the adapter's own build_command against the installed kilo and asserts a file is written (not merely exit 0) — the TUI path exits 124/0 without doing work
• require_file_changes is set, so a zero-work exit-0 run is not reported completed (KilocodeAdapter currently does not set it, unlike claude-code and opencode)

Relationship to #915

#915's AC1 requires the tier to "drive one trivial task to a terminal state per engine"; kilocode cannot satisfy that until this lands, so this should go first.