fix(client): gate Kimi capability on official CLI install

[yuezengwu]

Summary

• Kimi Computer capability now probes for a real host kimi CLI (daemon PATH → well-known install dirs including official $HOME/.kimi-code/bin → login-shell PATH), matching other provider binary discovery.
• Missing CLI → state=missing / available=false. Present CLI → state=ok / available=true, still with runtimeSource: bundled because @botiverse/kimi-code-sdk remains the execution engine.
• Detection stays existence-only (no launch, no credential read). Web install hint and the Kimi QA case checklist are aligned with this contract.

Cross-links Context Tree decision: https://github.com/agent-team-foundation/first-tree-context/pull/822

Test plan

• pnpm exec vitest run src/__tests__/kimi-code-capability.test.ts src/__tests__/kimi-binary.test.ts (packages/client) — 13 passed
• pnpm typecheck (packages/client)
• Full pnpm test in packages/client — 1652 passed
• Full pnpm test in packages/web — 1738 passed (includes kimi provider surface copy)
• Independent QA by yzw-codex on head c1dbcea90af77901db1fe9d9a171a6963f5841fa — change-scoped PASS (see QA comment); formal first-tree-qa remains BLOCKED for full product matrix

[baixiaohang]

Recommendation: request changes

• Rationale: The new gate implements the intended install-only Kimi contract, but it misses the official installer's default binary directory, so a supported installation can remain falsely unavailable.

Risk level: A

• Path baseline: includes packages/client/** → A
• Semantic lift: none (already A)

PR summary

• Author / repo: yuezengwu / agent-team-foundation/first-tree
• Problem: A user could previously select Kimi from a Computer merely because First Tree bundled the SDK, even when the host lacked the official CLI needed for provider-owned login and recovery.
• Approach: Gate the Kimi capability on an existence-only host kimi lookup, keep execution on the bundled SDK, and align Computer recovery copy plus the QA checklist with that split.
• Impacted modules: Client capability/binary discovery, Computer provider setup surfaces, and runtime QA guidance.

Review findings
❌ 1. The resolver does not search the official installer's default directory. The official macOS/Linux and Windows installers place the binary under $HOME/.kimi-code/bin / %USERPROFILE%\.kimi-code\bin, but wellKnownBinDirs(home) does not include that location. A running daemon keeps its pre-install process.env.PATH, and Windows deliberately has no login-shell PATH fallback, so installing Kimi through the recommended official script can leave every background re-probe at state=missing until a restart (and potentially beyond it, depending on service PATH propagation). Please add the Kimi-specific official install directory to the cheap well-known lookup and cover the empty-daemon-PATH / empty-login-shell case, including Windows naming. [R5 / packages/client/src/runtime/kimi-binary.ts:69]

Action taken

• Submitted request changes.

[yuezengwu]

Addressed the request-changes finding in c1dbcea90af77901db1fe9d9a171a6963f5841fa:

• Default well-known lookup now prepends the official installer binary dir ($HOME/.kimi-code/bin / %USERPROFILE%\.kimi-code\bin), matching install.sh / install.ps1 (KIMI_INSTALL_DIR default).
• Added hermetic coverage for empty daemon PATH + empty login-shell PATH (Unix kimi) and Windows kimi.exe via USERPROFILE with empty Path.

[yuezengwu]

Independent QA — exact head c1dbcea90af77901db1fe9d9a171a6963f5841fa

Formal first-tree-qa status: BLOCKED because the complete Docker-backed
whole-product cell did not reach QA READY (no live Kimi credential/turn or
connected Web UI/daemon matrix). The change-specific acceptance scope passed,
and I found no scoped defect.

Evidence:

• pnpm check, pnpm typecheck, and pnpm build passed.
• Focused Kimi suites: 2 files / 13 tests passed.
• Full client suite: 155 files passed, 1 skipped; 1652 tests passed, 3 skipped.
• All current-head GitHub CI checks passed, including Client & Web and CLI.
• Final built CLI with isolated HOME and PATH:
  • no executable kimi → missing, available=false;
  • executable only at $HOME/.kimi-code/bin/kimi → ok,
    available=true, while execution metadata remains bundled SDK;
  • sentinel remained absent, proving the capability probe did not launch the
    external CLI.
• Kimi probe latency was 0–1 ms; full probe wall time was 0.27–0.35 s.

The prior requested-change finding was submitted against 0c8a184....
Current head adds the official $HOME/.kimi-code/bin / Windows-equivalent
lookup and covers it in tests. GitHub will continue to show
CHANGES_REQUESTED until the original reviewer re-reviews.

Limitations: no real Kimi login/provider turn, no connected Web UI product
drive, and Windows behavior was unit-tested rather than run on a Windows host.

Case disposition: no-change.

[yuezengwu]

@baixiaohang Ready for re-review on current head c1dbcea90af77901db1fe9d9a171a6963f5841fa.

Your CHANGES_REQUESTED finding (official installer dir $HOME/.kimi-code/bin missing from well-known lookup) was addressed in that commit, with hermetic coverage for empty daemon PATH / empty login-shell PATH and Windows kimi.exe under %USERPROFILE%\.kimi-code\bin.

Independent QA locked that same head and reported no defects in the change scope (check/typecheck/build, focused + full client tests, all GitHub CI green, final built CLI probe behavior). Please re-review when you can.