第 9 章：跨 Harness 适配——一份资产，多种投影
共同内容与平台特性分离
ECC 支持 Claude Code、Codex、Cursor、OpenCode、Gemini、Qwen、Zed、Hermes、OpenClaw、Kimi、CodeBuddy、JoyCode 等目标。它没有把全部仓库复制成 12 份，而是将共性和差异拆开：
共同资产：agents / skills / commands / rules / scripts
↓
target adapter / scaffold / plugin manifest
↓
Claude · Codex · Cursor · OpenCode · Gemini · ...
适配层的责任包括：目标根目录、用户级还是项目级、能否加载某种 module、如何合并 JSON、命令和 agent 的命名规则、是否需要构建插件 payload。
几个代表性投影
Claude Code
.claude-plugin/plugin.json 声明 skills 和 commands 目录；hooks/hooks.json 使用 Claude 的 lifecycle 事件。插件安装和手工安装是两种路径，README 明确建议不要叠加，以免重复加载。
Codex
.codex-plugin/plugin.json 提供 skills、MCP config 和 default prompt；.codex/AGENTS.md 与 .codex/config.toml 是项目级指导和可信配置。仓库还提供 scripts/sync-ecc-to-codex.sh，把 ECC 内容同步到用户 Codex 目录，并尽量保留已有文件、创建备份和合并配置。
Cursor
.cursor/ 里包含 agents、skills、commands、hooks 和 hooks.json 等项目级投影；installer 需要把通用规则按语言匹配到 Cursor 规则目录，并合并 MCP，而不是简单覆盖整个 JSON。
OpenCode
OpenCode 的适配更像“构建后再安装”：scripts/build-opencode.js 先生成 .opencode/dist，installer 通过 validation 检查 payload 是否已构建。这个特例说明 target adapter 不只是路径映射，也可以拥有自己的 build lifecycle。
为什么 adapter 需要显式声明
如果没有 target 过滤，用户会得到宿主完全不识别的文件；如果没有 adapter ownership，repair 可能覆盖用户自己的规则；如果没有 platform configs，MCP、插件和命令入口会在不同 harness 中失配。因此 install-modules.json 每个 module 都声明 targets，install-executor 将它们转成带策略的 operations。
适配的现实边界
跨 harness 不是“完全相同体验”：
- Claude 的 hook 事件和退出码语义不能直接假设在 Codex/Cursor 中存在。
- Skills 是最容易共享的层，hooks 和 rules 的兼容性更依赖宿主。
- 插件市场安装、项目级安装、同步脚本安装的生命周期不同。
- 功能 parity 需要持续 audit，不能仅凭目录存在就声称支持。
ECC 因此在 docs/、scripts/harness-audit.js、scripts/harness-adapter-compliance.js 和各 .*/README.md 中把支持情况写成“事实 + 限制”，而不是只列平台名称。