feat: add Kimi Code CLI backend

[chaodu-agent]

Problem Statement

OpenAB supports a growing set of ACP-compatible coding agents, but Kimi Code CLI is not currently available as a packaged backend. Users cannot select Kimi Code through the standard OpenAB image, Helm examples, image build workflows, or backend documentation.

Issue: No existing issue is referenced; this PR implements the requested Kimi Code CLI backend addition.

At a Glance

Discord / Slack / gateway
          │
          ▼
     OpenAB broker ── ACP stdio JSON-RPC ── kimi acp
          │                                  │
          └── persistent ~/.kimi-code auth ─┘

Review Contract

Goal

Package Kimi Code CLI as a first-class OpenAB ACP backend with reproducible images, the native kimi acp command, interactive /login authentication guidance, CI/build registration, Helm configuration examples, and user-facing documentation.

Non-goals

This PR does not change OpenAB's broker protocol, ACP session handling, gateway behavior, or existing backend defaults. It does not add a new provider implementation to Kimi Code, automate account login, or merge the pull request.

Accepted Residual Risks

• Kimi Code is pinned to npm version 0.28.1 and uses the documented Node 24 runtime floor; future Kimi releases may require a deliberate version and image update.
• Authentication remains interactive: operators run kimi and enter /login, then persist /home/node/.kimi-code through the existing deployment storage mechanism.
• Full workspace validation is not green on the current origin/main baseline: 697 of 698 library tests passed, with secrets::tests::resolve_exec_nonzero_exit failing independently of this PR; clippy reports four pre-existing warnings in cron.rs and discord.rs; repository-wide cargo fmt --check also reports pre-existing formatting differences. These are reported transparently and are not modified by this backend-only change.

Acceptance Criteria

• Kimi is available through both the standalone Dockerfile.kimi image and the Dockerfile.unified kimi target.
• Both image variants install @moonshot-ai/kimi-code@0.28.1, expose kimi, and configure OPENAB_AGENT_COMMAND=kimi acp with kimi as the interactive auth helper.
• Docker Bake, image-build workflows, smoke tests, Helm examples, image-tag documentation, backend references, and both README files register Kimi consistently.
• The implementation preserves existing backend behavior and does not stage unrelated local files.
• Targeted configuration tests, YAML parsing, whitespace checks, Docker builds/smoke tests, and Docker Bake resolution provide reproducible evidence for the change.

Follow-ups

• Add a dedicated live ACP integration test against a non-production Kimi account when safe credentials and CI policy are available.
• Revisit package/runtime update automation and whether common Node 24 layers should be shared by future backends with the same runtime floor.
• Address the unrelated baseline test, clippy warnings, and formatting drift separately.

Prior Art & Industry Research

• OpenClaw demonstrates a multi-agent packaging and operational model where agent-specific runtime dependencies and persistent auth state are treated as deployment concerns.
• Hermes Agent provides relevant ACP-compatible agent packaging precedent and reinforces the value of keeping the broker boundary protocol-agnostic.
• This is a packaging/backend integration only; it adds no broker protocol change and keeps OpenAB's existing ACP stdio JSON-RPC boundary intact.

Proposed Solution

• Add a standalone Node 24 Kimi image and a corresponding unified Docker target.
• Pin @moonshot-ai/kimi-code to 0.28.1 and use its native kimi acp adapter.
• Set OPENAB_AGENT_AUTH_COMMAND=kimi, documenting that operators enter /login interactively.
• Register the backend across Docker Bake, build and smoke-test workflows, Helm examples, image documentation, configuration references, ADR inventory, multi-agent guidance, and README tables.
• Add Kimi-specific unified-image smoke checks for the package version and ACP command wiring.

Why this approach?

It follows OpenAB's existing per-backend image and workflow conventions while respecting Kimi Code's documented Node 24 requirement. Using Kimi's native ACP command avoids an additional adapter process and preserves the current broker architecture. Pinning the npm package makes image rebuilds reproducible, while the existing persistent home-volume model preserves Kimi credentials.

Alternatives Considered

• Use the shared Node 22 runtime: rejected because it does not meet Kimi Code's documented runtime requirement.
• Wrap Kimi with a third-party ACP adapter: rejected because Kimi provides a native ACP command and an extra adapter would add an unnecessary compatibility surface.
• Install Kimi dynamically at container startup: rejected because it makes startup dependent on network availability and weakens reproducibility.
• Change the broker or ACP protocol: rejected because the native kimi acp stdio boundary already matches OpenAB's existing architecture.

Validation

• git diff --check: passed.
• YAML parsing with Ruby for all modified workflows and charts/openab/values.yaml: passed.
• Remote targeted Rust configuration tests on macmini: 57 passed, 0 failed.
• Remote full cargo test --workspace on macmini: 697 passed, 1 unrelated pre-existing failure (secrets::tests::resolve_exec_nonzero_exit).
• Remote cargo clippy --workspace --all-targets -- -D warnings: blocked by four unrelated pre-existing warnings in cron.rs and discord.rs.
• Remote cargo fmt --all -- --check: blocked by extensive pre-existing formatting differences on origin/main; no unrelated formatting was changed.
• Unified Kimi image: built successfully with OrbStack Docker; smoke checks confirmed /usr/local/bin/openab, /usr/local/bin/kimi, OPENAB_AGENT_COMMAND=kimi acp, and package version 0.28.1.
• Standalone Kimi image: built successfully with the same smoke checks.
• docker buildx bake --print kimi: passed and resolved Dockerfile.kimi.

https://discord.com/channels/1491295327620169908/1491365150664560881/1528804085480951840

[chaodu-agent]

Important

CHANGES REQUESTED ⚠️ — The Kimi backend is registered broadly, but the standalone image and provider documentation still diverge from the unified/runtime contracts.

Consolidated review: #1429 (comment)

GitHub event: COMMENT — self-review delivery only; this is not an approval.

[chaodu-agent]

[chaodu-agent]

Important

CHANGES REQUESTED ⚠️ — The Kimi backend is registered broadly, but the standalone image, architecture inventory, and provider-credential guidance are not yet consistent with the implementation and vendor contract.

What This PR Does

This PR adds Kimi Code CLI as a packaged ACP backend with standalone and unified Docker images, native kimi acp wiring, interactive authentication guidance, CI/build registration, Helm examples, and documentation. It keeps the broker protocol unchanged and relies on Kimi's native stdio ACP adapter.

How It Works

Dockerfile.kimi and the kimi target in Dockerfile.unified install the pinned @moonshot-ai/kimi-code@0.28.1 package and expose kimi acp. The PR registers Kimi across image matrices, Docker Bake, Helm examples, README/backend references, and unified-image smoke checks, while persisting Kimi state under /home/node/.kimi-code.

Findings

#	Severity	Finding	Location
F1	🟡	The standalone image omits runtime packages included by the unified Kimi target (git, bubblewrap, and socat), so the two advertised image paths do not provide the same coding-agent runtime.	Dockerfile.kimi:23-25
F2	🟡	The OAuth ADR's agent inventory says 15 variants but omits the existing devin target; the unified Dockerfile contains 16 agent targets after Kimi is added.	docs/adr/openab-agent-oauth.md:28-29
F3	🟡	The provider guide says shell environment variables can supply Kimi credentials through [agent].inherit_env/[agent].env, but Kimi's official provider contract requires credentials in config.toml and does not use shell-environment fallback.	docs/kimi.md:94
F4	🟢	Native kimi acp wiring, pinned package-version checks, and registration across standalone and unified smoke/build paths provide good integration coverage.	Dockerfile.kimi:27-28, .github/workflows/docker-smoke-test-unified.yml:127-140

Finding Details

🟡 F1: Keep standalone and unified Kimi images functionally aligned

The standalone runtime installs only ca-certificates curl procps ripgrep tini unzip (Dockerfile.kimi:23-25), while the unified kimi target installs those packages plus bubblewrap socat git (Dockerfile.unified:160-162). The standalone path is used by docker-bake.hcl and the standalone smoke matrix, so users selecting it get a materially different runtime; normal repository workflows cannot rely on git being available. Please align the package sets, or document and test a deliberate difference before treating both image variants as equivalent.

🟡 F2: Correct the OAuth ADR inventory

docs/adr/openab-agent-oauth.md now says there are 15 variants and lists Kimi, but it still omits the pre-existing devin variant. Dockerfile.unified defines 16 agent targets: kiro, claude, codex, kimi, copilot, cursor, gemini, grok, hermes, mimocode, opencode, devin, antigravity, pi, native, and agentcore. Please update the count and list so this architecture inventory remains accurate.

🟡 F3: Do not promise unsupported shell-environment credential injection

The new paragraph directs operators to pass a provider key through the broker environment using [agent].inherit_env or [agent].env. Kimi's official provider documentation says credentials are resolved from the provider's api_key field or its [providers.<name>.env] TOML subtable, and explicitly says shell environment variables are not a fallback. Please revise this guidance to recommend configToml/the Kimi credential store and clearly distinguish OpenAB environment inheritance from Kimi provider configuration; otherwise users following this paragraph can still receive a missing-credentials error.

Official references: Kimi providers and models and config overrides.

🟢 F4: Good coverage of the new backend

The PR correctly uses Kimi's native ACP command, pins the npm package, validates the installed version and command wiring in the unified smoke workflow, and registers the backend across the build matrices and documentation surfaces.

Baseline Check

• PR opened: 2026-07-20.
• Main already has: unrelated Kimi model-name references, but no Kimi backend Docker image, ACP command registration, image-matrix entry, Helm example, or backend guide.
• Net-new value: standalone/unified Kimi packaging and the associated CI, deployment, configuration, and documentation integration.
• Validation observed at review time: local git diff --check and pinned-package metadata checks passed; the repository's Docker build/smoke validation was reported in the PR body, but the full PR check matrix was not independently completed in this environment.

Addressing External Reviewer Feedback

No external GitHub review comments or submitted reviews were present for this SHA when this round was prepared. The prior keyed review was submitted against the superseded SHA and is preserved as history; its findings are re-evaluated here against the requested commit.

What's Good (🟢)

• The implementation keeps the broker and ACP boundary unchanged.
• The npm dependency is pinned to 0.28.1, and the package metadata confirms the published kimi executable and Node >=22.19.0 requirement, which the Node 24 images satisfy.
• Kimi is wired into the standalone and unified build/smoke registrations rather than only documented.

5️⃣ Three Reasons We Might Not Need This PR

1. Existing ACP support may be sufficient — Operators could run Kimi outside the image and point OpenAB at it, avoiding another bundled backend variant.
2. Two image paths increase drift risk — Maintaining standalone and unified Dockerfiles creates package and version parity work, as F1 demonstrates.
3. The integration still depends on vendor-specific interactive auth — Without a live authenticated ACP regression test, packaging checks alone may not prove a production login/session flow.

[chaodu-agent]

Important

CHANGES REQUESTED �� � The standalone image, OAuth inventory, and provider-credential guidance need correction.

Consolidated review: #1429 (comment)

GitHub event: COMMENT � self-review delivery only; this is not an approval.