perf(build): isolate CLI Core capability closure

docs/architecture/cli-product-line-design.md

@@ -171,6 +171,9 @@ CLI-local 配置只保存终端形态偏好与调用入口设置。共享权限
 
 CLI 通过 `DeliveryProfile::Cli` 消费经过校验的产品 Runtime parts。产品定义、Delivery Profile、Runtime Configuration 和 Capability Availability 是不同概念：
 
+- 编译期由 CLI 显式选择 `agent-runtime`、`canvas-runtime`、`external-sources`、
+  `plugin-runtime` 与 `ssh-remote` owner feature；这保持现有 CLI capability plan，
+  但不继承 Desktop 后续加入 `product-full` 的能力。
 - 隐藏入口不证明后端依赖被移除。
 - CLI 不读取 authoring product definition 作为运行时业务配置。
 - 品牌、资源、数据 namespace、更新渠道和内置扩展由产品定制 owner 生成，CLI 只消费结果。

docs/architecture/platform-portability-design.md

@@ -93,7 +93,7 @@ Cargo package `bitfun-cli` 的 `aarch64-unknown-linux-ohos` 目标依赖解析
 
 | 问题域 | 当前识别结果 | 主要风险 | 后续专题需要回答 |
 |---|---|---|---|
-| 产品依赖闭包 | CLI 仍通过 `bitfun-core/product-full` 拉入 remote、browser、canvas、plugin、watch、Git、SQLite、PTY 等能力 | 无关平台依赖阻塞构建；为过编译而破坏共享 owner | CLI 真正需要哪些能力，哪些依赖应保留、隔离或移出目标闭包 |
+| 产品依赖闭包 | CLI 已显式选择 `agent-runtime`、`canvas-runtime`、`external-sources`、`plugin-runtime` 与 `ssh-remote` Core owner feature，不再继承 `product-full`；当前闭包仍主动保留 remote、browser、canvas、plugin、watch、Git、SQLite、PTY 等现有能力 | 无关平台依赖阻塞构建；为过编译而破坏共享 owner | 在不改变现有 CLI 规格的前提下，哪些 owner 还应继续拆分或针对目标平台隔离 |
 | Rust 与依赖解析 | 仓库无根 `Cargo.lock`；Rust 1.94.1 探针先被要求 Rust 1.95 的 `oxc-browserslist`、`oxc_sourcemap` 阻塞 | 把通用 MSRV/解析问题误判为 OHOS 问题；构建不可复现 | 仓库认可的 Rust、依赖解析和构建基线 |
 | TUI/TTY | `ratatui/crossterm` 依赖 `mio`、rustix、signal-hook 和终端系统调用 | 能编译但 raw mode、输入、resize、信号或恢复不可用 | 真实系统终端支持范围与 TUI 退化边界 |
 | 剪贴板与语法高亮 | `arboard -> x11rb` 带入 X11；`syntect-tui` 重新带入 `onig_sys` | 桌面 Linux/C 原生依赖进入 OHOS 产物 | 这些能力是否必需，以及各自可维护的鸿蒙化路线 |

docs/architecture/product-architecture.md

@@ -724,12 +724,13 @@ flowchart LR
 ```mermaid
 flowchart TB
   Desktop["Desktop"] --> Full["product-full"]
-  CLI["CLI / TUI"] --> Full
+  CLI["CLI / TUI"] --> CliClosure["Core owner feature closure"]
   ACP["ACP"] --> Parts["Runtime Parts"]
   SDKHost["SDK Host"] --> Parts
   ServerBootstrap["Server agent bootstrap · dormant"] --> Full
 
   Full --> Coordinator["ConversationCoordinator"]
+  CliClosure --> Coordinator
   Parts --> Coordinator
   Ownership["CoreRuntimeOwnership"] -. "first-party composition injects once" .-> Coordinator
 ```
@@ -753,8 +754,8 @@ flowchart LR
 | 当前入口 | 已有能力 | 明确边界 |
 |---|---|---|
 | Desktop | 使用 `product-full`；显示外部来源、审批、冲突、诊断和 Host 能力 | 可执行能力在事实所在 Host 运行；Safe Mode 只阻止新调用，不改来源、不取消正在运行的调用 |
-| CLI / TUI | 使用 `product-full`；提供 `/extensions`、统一 `/hooks`（旧 `/hooks_external` 为别名）、`/tools` 和 `/agents`；Claude Code/Codex 命令 Hook 可经显式审阅复制为原生层 | 生态解析仍在适配器，不启动第二套 Agent Runtime；OpenCode Hook 仍只静态发现；远程能力未接入时不回退本机 |
-| ACP | 使用 `DeliveryProfile::Acp` 和 Runtime Parts | load 成功后才发布活动状态；close 排空后再卸载；完整历史和配置仍由 Core/ACP 管理 |
+| CLI / TUI | 使用显式 Core owner feature closure（`agent-runtime`、`canvas-runtime`、`external-sources`、`plugin-runtime`、`ssh-remote`）；提供 `/extensions`、统一 `/hooks`（旧 `/hooks_external` 为别名）、`/tools` 和 `/agents`；Claude Code/Codex 命令 Hook 可经显式审阅复制为原生层 | 保持现有 CLI capability plan，但不自动继承 Desktop 后续加入 `product-full` 的能力；生态解析仍在适配器，不启动第二套 Agent Runtime；OpenCode Hook 仍只静态发现；远程能力未接入时不回退本机 |
+| ACP | 使用 `DeliveryProfile::Acp`、Runtime Parts，以及 `agent-runtime`/`canvas-runtime`/`external-sources`/`ssh-remote` Core owner feature | load 成功后才发布活动状态；close 排空后再卸载；完整历史、Canvas 工具物化、兼容指令来源和配置仍由 Core/ACP 管理 |
 | Peer / Server | Server 提供 control/catalog；Peer Host 执行真实工作区操作；当前 HTTP Server 不装配 Agent Runtime | 控制端不替远端发现或执行；旧 Host 明确降级，SSH Remote 未接入时返回不支持；只读 Server 不声明 Runtime ownership |
 | Web / Mobile Web | 依赖现有后端入口 | 不持有插件执行单元，也不能据空 profile 宣称独立能力 |
 | HarmonyOS 手机 Remote | phone-only ArkTS 远程入口 | 不等于 HarmonyOS PC 本地 Runtime、CLI/TUI 或 GUI |

docs/plans/core-decomposition-plan.md

@@ -22,7 +22,7 @@
 | 事实 | 当前状态 | 结论 |
 |---|---|---|
 | 产品能力组装 | `DeliveryProfile`、`ProductAssembler`、能力计划、服务可用性和测试已存在 | 这些是可测试的 assembly facts，不代表产品入口已接入 |
-| CLI / Desktop / ACP | 三者仍按需启用 `bitfun-core/product-full`；CLI 与 ACP 已分别提交对应 `DeliveryProfile` 并消费 Runtime Parts/SDK，Desktop 主交互已消费由现有 owner 构造的窄口径 SDK 接口 | 三个入口均复用单一 Core owner；完整 Desktop profile 和剩余兼容操作仍需逐项迁移 |
+| CLI / Desktop / ACP | CLI 与 ACP 已分别提交对应 `DeliveryProfile`、消费 Runtime Parts/SDK，并选择经过评审的 Core owner feature closure；Desktop 仍启用 `bitfun-core/product-full`，主交互已消费由现有 owner 构造的窄口径 SDK 接口 | 三个入口仍复用单一 Core runtime owner；完整 Desktop profile 和剩余兼容操作仍需逐项迁移 |
 | Server | 当前生产路由只形成 health/info/ping 基线 | 没有插件状态或独立产品组装完整流程 |
 | Server / Remote / Web / Mobile Web / SDK profile | 当前为空计划、未接入入口或仅有 preview 测试 | 不得据枚举值宣称产品能力已交付 |
 | Agent Runtime SDK | 已有无 `bitfun-core` 依赖的 v3 preview 接口和 smoke test | 发布边界仍需真实嵌入方证明 |

docs/plans/product-architecture-evolution-plan.md

@@ -32,7 +32,7 @@
 | CLI/TUI | 宿主 `ACTION_SPECS` 已统一 Slash、Palette、Help、Keymap 与 dispatch；启动页及活动 turn 的 Linux PTY / Windows ConPTY 行为由进程级契约保护 | 保持现有 renderer 与交互规格，只按真实故障样例补可靠性契约；macOS 活动 PTY 另行验收 |
 | OpenCode | Prompt Command、受支持的单文件 JavaScript Tool 和 Subagent 安全子集已分别通过能力专属 provider 接入；受管 package plugin 仍只有静态预览 | 先收敛三条已交付路径的诊断、运行时提示和配置失败语义，再按真实阻塞样例评估下一能力切片 |
 | HarmonyOS PC | 未来平台目标，当前未实现 | 目标、问题、风险和旧设计闭环见平台规约；具体工作后续分别立项 |
-| 入口迁移 | CLI 已消费 Runtime Parts；Desktop 主交互消费由现有 owner 构造的窄口径 Runtime SDK 门面，完整 Desktop Runtime Parts 尚未组装；CLI/ACP/Desktop 仍按需保留 `bitfun-core/product-full` 兼容 owner | 保持单一 owner，按真实端口逐项迁移，不批量删除兼容门面或用桩服务提前声明能力 |
+| 入口迁移 | CLI 已消费 Runtime Parts；Desktop 主交互消费由现有 owner 构造的窄口径 Runtime SDK 门面，完整 Desktop Runtime Parts 尚未组装；CLI 与 ACP 选择经过评审的 Core owner feature closure，Desktop 仍保留 `bitfun-core/product-full` 兼容 owner | 保持单一运行时 owner，按真实端口逐项迁移，不批量删除兼容门面或用桩服务提前声明能力 |
 
 ## 3. 工作流一：边界与依赖可信