fix: complete vendor coverage in kcap status and kcap --help (Gemini + Kiro)

[realtonyyoung]

Problem

Two fully-supported vendors were missing from user-facing surfaces:

• Gemini — absent from the kcap status per-agent Hooks line (and its help text), despite kcap plugin install --gemini being supported.
• Kiro — absent from the top-level kcap --help (usage) and the kcap status Hooks line (and its help text), despite full install/import/hook support that's already documented in the per-command help and the README.

Both are the same omission: a vendor was wired up end-to-end but never added to help-usage.txt and/or the status surface. Found while auditing kcap --help and kcap status for vendor completeness/consistency.

Fix

kcap status (StatusCommand.cs) — BuildHooksStatusLine now renders every supported agent in canonical order: Claude, Codex, Cursor, Copilot, Gemini, Kiro, Pi, via GeminiHooksInstaller.IsInstalled / KiroHooksInstaller.IsInstalled:

Hooks:   Claude ✓  Codex ✓  Cursor ✗  Copilot ✓  Gemini ✗  Kiro ✓  Pi ✓

• help-status.txt — Hooks description now lists Gemini and Kiro.
• help-usage.txt (kcap --help) — Kiro added to the import line, both plugin flag lists, the hooks header, and a new hook --kiro --event <name> line. (Gemini was already present in usage.)
• Tests — status line-builder extended from five → seven agents (Gemini ✓/✗ and Kiro ✓/✗). Added direct GeminiHooksInstaller.IsInstalled coverage (marker branch, settings-hooks fallback, negative); Kiro's IsInstalled is already covered by KiroHooksTests.

No README change needed — both vendors' install/import behavior is already documented there; the gap was only in usage + status.

Testing

• dotnet build succeeds (.NET 10 SDK).
• Unit suite: 1644 passed, 0 failed, 0 skipped.
• AOT publish (-c Release): no IL3050/IL2026 warnings.
• Verified live kcap status, kcap status --help, and kcap --help output for all seven vendors.

🤖 Generated with Claude Code

[qodo-code-review]

Qodo reviews are paused for this user.

Troubleshooting steps vary by plan Learn more →

On a Teams plan?
Reviews resume once this user has a paid seat and their Git account is linked in Qodo.
Link Git account →

Using GitHub Enterprise Server, GitLab Self-Managed, or Bitbucket Data Center?
These require an Enterprise plan - Contact us
Contact us →

[realtonyyoung]

Blocking

None.

Should-fix

None.

Nit

• test/Capacitor.Cli.Tests.Unit/StatusCommandHooksTests.cs:103
  The PR covers the pure rendered line, but not the actual kcap status Gemini detection path.
  Suggested change: add focused GeminiHooksInstaller.IsInstalled(...) tests for marker-based detection and settings fallback after PluginCommand.InstallGeminiHooks(...), matching the Codex/Cursor installer coverage style.

Looks-good

• src/Capacitor.Cli/Commands/StatusCommand.cs:61
GeminiHooksInstaller.IsInstalled(GeminiPaths.SettingsJson()) is the right detection call: GeminiPaths.SettingsJson() honors $GEMINI_HOME, and install writes/merges into that same shared settings file.

• src/Capacitor.Cli/Commands/PluginCommand.cs:1223 and src/Capacitor.Cli.Core/Gemini/GeminiHooksInstaller.cs:20
  Install writes both the merged kcap hook --gemini entries and a marker; detection checks marker first, then falls back to scanning hooks. False-positive behavior from a stale marker is consistent with the other marker-based vendors.

• src/Capacitor.Cli/Commands/StatusCommand.cs:153
  The rendered order is Claude, Codex, Cursor, Copilot, Gemini, Pi, matching the canonical order called out for this PR.

• src/Capacitor.Cli.Core/Resources/help-status.txt:8
  The help text now matches the real status output and accurately distinguishes Gemini hooks from Pi's extension.

• CLAUDE.md:50
  I don't think the README-sync rule requires a README change here: this is exposing an already-supported integration in status, not a new command, flag, default behavior, or prerequisite. README already documents Gemini install/remove behavior.

• AOT safety: no new reflection/dynamic-code issue found in the PR diff. The added status code is ordinary method calls/string rendering, and no new JsonArray collection-expression risk is introduced.

Tests were not run, per review instructions.

Verdict: approve-with-nits.

[realtonyyoung]

Addressed the test nit in 570578c: added focused GeminiHooksInstaller.IsInstalled coverage in GeminiHooksTests.cs — marker-file detection, the settings-hooks fallback when no marker is present, and a no-kcap-hooks negative (mirrors the Cursor/Pi installer-detection style).

🤖 Addressed by Claude Code

[realtonyyoung]

Scope note: expanded this PR to also cover Kiro, which had the identical gap — fully supported (install/import/hooks, documented in per-command help + README) but missing from kcap --help (usage) and the kcap status Hooks line. Added it alongside Gemini in the same files since it's the same omission and the same lines. Title/description updated; commit 097d8a7.

🤖 Note from Claude Code

[realtonyyoung]

Codex review (round 2) — verdict: request-changes

Should-fix: kcap uninstall is the remaining missed completeness surface for Kiro. The updated kcap --help now says uninstall removes all agent integrations, but UninstallCommand and help-uninstall.txt still omit Kiro: the confirmation list has no ~/.kiro/agents/kcap.json, the command never calls plugin remove --kiro, the marker cleanup never deletes KiroHooksInstaller state, and help-uninstall.txt still lists selective cleanup without --kiro. A user can install Kiro hooks, run kcap uninstall --yes, and still leave the Kiro kcap agent/default-agent integration behind. Suggested: add Kiro to the uninstall imports/summary/confirmation list, call PluginCommand.HandleAsync(["plugin", "remove", "--kiro"]), clean KiroHooksInstaller.DeleteMarker(KiroPaths.KcapAgentJson()), and update help-uninstall.txt including the plugin remove list.

Looks good otherwise: KiroHooksInstaller.IsInstalled(KiroPaths.KcapAgentJson()) matches the $KIRO_HOME-aware install path and marker/file-content detection; Gemini detection still matches the shared $GEMINI_HOME settings path; status/help-usage vendor order is Claude, Codex, Cursor, Copilot, Gemini, Kiro, Pi; help-status.txt correctly treats Kiro as hooks and Pi as the extension; the added Gemini detection tests cover marker and settings fallback; and I did not see new NativeAOT/reflection or JsonArray collection-expression risk in the diff. I did not build or run tests per instructions.

— Codex review (automated)

[realtonyyoung]

Fixed in e2a7033: kcap uninstall now tears down the Kiro integration too — added plugin remove --kiro (restores the previous default agent + deletes ~/.kiro/agents/kcap.json), the Kiro confirmation-list line, and KiroHooksInstaller.DeleteMarker; updated help-uninstall.txt (prose + selective plugin remove --kiro, and noted the previously-undocumented Pi extension). plugin remove --kiro no-ops cleanly (exit 0) when Kiro was never installed — verified by the existing no-Kiro uninstall tests plus a new positive Kiro-removal test. Full suite 1645 pass, no AOT warnings.

🤖 Addressed by Claude Code

[realtonyyoung]

Codex review (round 3) — verdict: approve

The round-2 request-changes is resolved. The fix adds Kiro to the uninstall confirmation list, calls plugin remove --kiro unconditionally, deletes the Kiro marker in the belt-and-braces cleanup, and updates help-uninstall.txt prose plus the selective plugin remove list. I traced the Kiro-less path: missing settings returns null, the default-agent restore is skipped unless chat.defaultAgent == "kcap", missing ~/.kiro/agents/kcap.json/marker no-ops, and RemoveKiro returns 0, so this should not break uninstall on machines that never had Kiro. The restore-before-delete retry-safety is intact, uninstall does not require kiro-cli, Kiro failures flow into hadFailures without masking later cleanup, and I saw no new AOT/reflection or dynamic JsonArray risk in the delta. I did not build or run tests per instructions.

— Codex review (round 3, automated)