Skip to content

feat(harness): add kimi as a verified crewmate/secondmate adapter#657

Draft
dannyyounes wants to merge 1 commit into
kunchenguid:mainfrom
dannyyounes:worktree-kimi-adapter
Draft

feat(harness): add kimi as a verified crewmate/secondmate adapter#657
dannyyounes wants to merge 1 commit into
kunchenguid:mainfrom
dannyyounes:worktree-kimi-adapter

Conversation

@dannyyounes

Copy link
Copy Markdown

Summary

  • Verifies Moonshot AI's Kimi Code CLI (kimi-cli 1.49.0) as a crewmate/secondmate harness and wires it into fm-spawn.sh.
  • Kimi has no positional/stdin initial-prompt injection that keeps its interactive session alive (-p/stdin both run one-shot and exit), so the launch template starts it bare and a post-launch step types the brief into the composer as the first message, reusing the existing fm_backend_send_text_submit primitive fm-send.sh already uses for steers.
  • Busy-pane detection relies on firstmate's existing hash-based staleness layer rather than a text signature: kimi's only busy cue is an animating spinner glyph with no stable ASCII footer text, and this was verified empirically to keep the pane hash changing through a real blocking tool call (a live 12-second sleep).
  • Scoped to crewmate/secondmate use only; kimi has no primary turn-end guard, PreToolUse seatbelt, or watcher protocol in this pass.
  • Full verification narrative (exit/interrupt/resume/skill-invocation, the tmux liveness-probe caveat mirroring pi's, the known-gap note on kimi's unexplored native hooks = [] config) lives in .agents/skills/harness-adapters/SKILL.md.

Test plan

  • bin/fm-lint.sh (ShellCheck 0.11.0, pinned) clean on the full file set
  • New tests/fm-kimi-harness.test.sh (fake-tmux driven) passes: confirms the bare launch + post-launch brief injection lands as two distinct tmux calls with no unsubstituted __BRIEF__
  • Full existing suite (tests/*.test.sh, 1325 assertions) re-run: 6 pre-existing failures reproduce identically on the unmodified base commit (cd218f2, confirmed via a clean detached worktree) and are unrelated to this change (orca/zellij/backend teardown env issues, backlog-handoff, decision-hold-lifecycle, secondmate-lifecycle-e2e)
  • Live empirical verification against a real authenticated kimi session: multi-line brief buffering, busy/idle/pending composer classification, Ctrl-C interrupt, /exit, and kimi -r <session-id> resume all confirmed working

Kimi Code CLI has no positional or stdin initial-prompt injection that
keeps its interactive session alive, so fm-spawn.sh launches it bare and
types the brief into the composer as the first message once it reports
ready, reusing the same fm_backend_send_text_submit primitive fm-send.sh
uses for an ordinary steer. Busy-pane detection relies on firstmate's
existing hash-based staleness layer rather than a text signature, since
kimi's only busy cue is an animating spinner glyph with no stable ASCII
footer text; this was verified to keep the pane hash changing through a
real blocking tool call. Scoped to crewmate/secondmate use only, kimi has
no primary turn-end guard, PreToolUse seatbelt, or watcher protocol yet.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant