harness-plugin-architecturelisted

# 多 Harness 插件架构 你负责把项目维护成 paragoge 式的多 harness plugin/CLI 工程。先保护结构边界，再改具体实现。 ## 先判断任务类型 - 改 runtime skill 语义：进入 `plugin/src/skills/<skill>/canonical/`。 - 改某 host 如何接收 skill：进入 `plugin/src/skills/<skill>/adapters/<host>/strategy.yaml` 和 `plugin/src/skills/_hosts/<host>/`。 - 改单个 hook 的业务契约：进入 `plugin/src/hooks/<hook>/CONTRACT.md`；改 coverage / stage / registration contract 才进入 `plugin/src/hooks/_manifest/`。 - 改某 host 的 hook 实现：进入 `plugin/src/hooks/<hook>/implementations/<host>/` 和 `plugin/src/hooks/_hosts/<host>/`。 - 改跨 hooks / commands / skills / ccm 的用户可见能力：进入 Capability Card，再按 Track A / Track B 找单 surface contract 与 host adapter；读 `references/n-host-capability-parity.md`。 - 改可安装产物：改 projection 脚本，不手改 `plugin/dist/<host>/`。 - 改发布、打包、版本线：读 `plugin-release-system.md`。 ## 架构不变量 `plugin/src/` 是语义源，`plugin/dist/<host>/` 是生成产物。不要从 dist 反推 source，也不要在 dist 中手修 bug。 Skills 走 SAP： ```text plugin/src/skills/<skill>/ canonical/ adapters/<host>/strategy.yaml ``` Hooks 走 PHIP： ```text plugin/src/hooks/ _manifest/ _hosts/<host>/ <hook>/implementations/<host>/ ``` Commands 和 host manifests 可以先保持当前 host 源布局，但一旦出现第二个 host，就必须下沉到 host adapter 层，避免共享 source 带 host 假设。 ## 工作流程 1. 先确认目标 host、当前已支持的 host 集合和改动属于 plugin adapter 还是另一种 execution surface。 2. 列出会被改动的 projection surface：skills、hooks、commands、manifest、CLI install、release package。 3. 对每个 surface 明确 source-of-truth 和 generated output。 4. 改 source，并运行 projection。 5. 验证 host-native dist，而不是只验证 source。 ## 何时读 reference