#17962: fix(cli): speed up completion plugin loading

## Summary - Problem: `openclaw completion` did plugin work it does not need, which made shell completion startup noticeably slower. - Why it matters: completion runs often and should feel immediate; plugin registration overhead was on the hot path. - What changed: completion now uses an explicit completion context to avoid unnecessary plugin/pairing work, plugins can declare `hasCliCommands: false` in manifests to skip completion-time module loading, plugin loader cache keys are mode-aware, and plugin-sdk completion-related subpath entrypoints are included in production build output. - What did NOT change (scope boundary): normal CLI behavior and pairing help behavior remain the same outside completion generation. ## Change Type (select all) - [x] Bug fix - [ ] Feature - [x] Refactor - [x] Docs - [ ] Security hardening - [ ] Chore/infra ## Scope (select all touched areas) - [x] Gateway / orchestration - [ ] Skills / tool execution - [ ] Auth / tokens - [x] Memory / storage - [ ] Integrations - [x] API / contracts - [x] UI / DX - [ ] CI/CD / infra ## Linked Issue/PR - Closes #N/A - Related https://github.com/forketyfork/openclaw/pull/2 ## User-visible / Behavior Changes - `openclaw completion` is faster. - Pairing command help remains normal outside completion generation; channel details are still shown on `openclaw pairing approve --help`. - Plugin manifest docs now include optional `hasCliCommands` guidance for completion optimization. ## Security Impact (required) - New permissions/capabilities? (`No`) - Secrets/tokens handling changed? (`No`) - New/changed network calls? (`No`) - Command/tool execution surface changed? (`No`) - Data access scope changed? (`No`) - If any `Yes`, explain risk + mitigation: ## Repro + Verification ### Environment - OS: Darwin 25.2.0 - Runtime/container: Node v25.6.1 - Model/provider: N/A - Integration/channel (if any): N/A - Relevant config (redacted): local openclaw install `2026.2.15` vs PR build `2026.2.16` ### Steps 1. `pnpm build` 2. Run repeated timings: - `node openclaw.mjs completion --shell zsh` - `openclaw completion --shell zsh` 3. Repeat both in default environment and with `NODE_DISABLE_COMPILE_CACHE=1`. ### Expected - PR build completion command is faster than local installed build. ### Actual - PR build is consistently faster in both benchmark modes. ## Evidence - [x] Perf numbers (if relevant) ### Benchmarks (`completion --shell zsh`) Default environment (5 runs): | Run | PR build 2026.2.16 (s) | Local install 2026.2.15 (s) | | --- | ---: | ---: | | 1 | 0.94 | 2.36 | | 2 | 0.86 | 1.26 | | 3 | 0.82 | 1.23 | | 4 | 0.82 | 1.28 | | 5 | 0.84 | 1.30 | | **Average** | **0.856** | **1.486** | With `NODE_DISABLE_COMPILE_CACHE=1` (5 runs): | Run | PR build 2026.2.16 (s) | Local install 2026.2.15 (s) | | --- | ---: | ---: | | 1 | 0.94 | 1.36 | | 2 | 0.91 | 1.40 | | 3 | 0.96 | 1.40 | | 4 | 0.93 | 1.36 | | 5 | 0.94 | 1.39 | | **Average** | **0.936** | **1.382** | ## Human Verification (required) What I personally verified (not just CI), and how: - Verified scenarios: - Completion generation in production entrypoint (`node openclaw.mjs`) is faster than local installed binary. - Pairing command help behavior remains normal outside completion generation; channel details are shown on `openclaw pairing approve --help`. - Completion-path behavior uses explicit context, not process-wide env mutation. - Edge cases checked: - Cache separation between `cli` and `full` plugin loader modes. - What you did **not** verify: - Full end-to-end checks across all channel plugins on live environments. ## Compatibility / Migration - Backward compatible? (`Yes`) - Config/env changes? (`No`) - Migration needed? (`No`) - If yes, exact upgrade steps: ## Failure Recovery (if this breaks) - How to disable/revert this change quickly: - Revert this PR commit; completion path returns to previous plugin loading behavior. - Files/config to restore: - `src/cli/completion-cli.ts`, `src/plugins/loader.ts`, `src/cli/program/register.subclis.ts`, `src/cli/pairing-cli.ts` - Known bad symptoms reviewers should watch for: - Completion latency regressions. - Pairing help labels missing in non-completion CLI paths. ## Risks and Mitigations - Risk: - Plugin registry cache may cross-contaminate completion and full modes. - Mitigation: - Cache key now includes plugin load mode; regression test covers `cli` then `full` load path. ## AI Assistance - [x] AI-assisted PR - Testing degree: Fully tested for build + targeted plugin/CLI tests + direct perf measurements <!-- greptile_comment --> <h3>Greptile Summary</h3> Optimizes `openclaw completion` startup time by ~42% by avoiding unnecessary plugin module loading. The PR introduces a "cli" mode for the plugin loader that skips importing plugin modules when `hasCliCommands: false` is declared in manifests. Cache keys are now mode-aware to prevent cross-contamination. Completion generation uses an explicit `forCompletion` context flag to skip plugin registry initialization, and pairing CLI defers channel label resolution during completion builds. Several bundled plugins are marked as having no CLI commands. New plugin-sdk subpath exports (`device-pairing`, `config-schema`) are added to support manifest-only loading scenarios. <h3>Confidence Score: 4/5</h3> - Safe to merge with low risk; changes are well-tested and scoped to completion performance - Strong implementation with comprehensive test coverage, clear performance gains, and backward-compatible design. Cache separation prevents mode cross-contamination. Minor risk around fallback behavior in pairing CLI when plugins fail to load, but this is handled with try-catch. - No files require special attention _{Last reviewed commit: 7cc005a} <!-- greptile_other_comments_section --> _{(2/5) Greptile learns from your feedback when you react with thumbs up/down!} <!-- /greptile_comment -->