ECC Phase 1 问题工单包剖析选择性安装、安装生命周期与会话适配契约的落地方案【免费下载链接】ECCThe agent harness performance optimization system. Skills, instincts, memory, security, and research-first development for Claude Code, Codex, Opencode, Cursor and beyond.项目地址: https://gitcode.com/GitHub_Trending/ev/ECC本指南基于 docs/PHASE1-ISSUE-BUNDLE-2026-03-12.md 这份规划文档展开它为 GitHub 精选项目 ECCAgent Harness Performance Optimization System梳理了一批 Phase 1 落地任务从按 manifest 驱动的选择性安装、带 install-state 的安装生命周期list-installed / uninstall / doctor / repair到ECC 2.0 控制平面所需的规范化会话适配契约与生成/导入技能的去向与溯源策略。读完本文你将理解这些工单的来龙去脉——问题拆解、范围与非目标、验收标准——并看到它们与仓库内已有地基manifests/install-profiles.json、schemas/install-state.schema.json、docs/SESSION-ADAPTER-CONTRACT.md 等之间的一一对应关系。背景从Mega Plan到可执行 Issue Bundle文档本身是一份问题草案集合issue draft bundle。它记录了 2026 年 3 月 11 日的 mega plan 与 3 月 12 日交接内容如何被整理成可投递到 GitHub 的工单正文并保留了关键历史细节起草者最初尝试在 MCP 会话中直接创建 GitHub issue因GitHub 认证缺失而被拦截之后通过ghCLI 成功投递共 5 个工单#423、#421、#424、#422、#425文档正文仅保存了其中 4 个完整工单本地源 bundle作为投递用正文的权威来源。这种先在仓库维护权威草稿、再投递到外部工单系统的做法本身就是一种可追踪的工程管理手段Issue 正文的每次演进都有本地源码可供 diff 与审计。文档中也明确说明了 4 个工单与 GitHub 编号的对应关系整理如下本地工单GitHub Issue标题关注主题Issue 1#423Implement manifest-driven selective install profiles for ECC按配置/模块的选择性安装执行Issue 2#421Add ECC install-state plus uninstall / doctor / repair lifecycle安装状态与生命周期命令Issue 3#424Define canonical session adapter contract for ECC 2.0 control plane会话适配契约与快照Issue 4#422Define generated skill placement and provenance policy技能放置与溯源策略文档仅列标题#425Define governance and visibility past the tool call工具调用之后的治理与可见性这四个工单共享一条主线把 ECC 从能装能用推进到可解释、可审计、可治理。下面逐份展开。Issue 1基于 manifest 的选择性安装配置#423问题本质地基已就绪缺的是执行工单指出 ECC 的安装长期以来按 target 与语言进行legacy 模式尽管仓库已经具备首批选择性安装 manifest 与非变更式non-mutating计划解析器但安装器本身还没有消费这些 profile。也就是说问题不再出在设计探索而在于把 profile/module 解析真正接入安装流程同时保持向后兼容。文档点名了当时已经落地的地基文件manifests/install-modules.jsonmanifests/install-profiles.jsonscripts/ci/validate-install-manifests.jsscripts/install-plan.js其中scripts/install-plan.js的核心角色正如其文件头注释所写Inspect selective-install profiles and module planswithout mutating targets——它是一个只读的计划视图在写任何文件之前先回答装什么、装到哪、跳过什么。Scope为三种目标实现 manifest 驱动安装工单明确本期执行范围为三个已支持的安装目标claude、cursor、antigravity并要求新增首轮 CLI 能力ecc-install --profile name按命名 profile 解析并安装ecc-install --modules id,id,...显式指定模块 ID 安装基于模块目标支持度的target-aware 过滤目标不支持该模块则确定性跳过或拒绝过渡期保持 legacy 语言模式安装的向后兼容。Non-Goals本期明确不做的事工单刻意收敛范围避免一次吞下太多不在同一 issue 中做完整 uninstall/doctor/repair 生命周期留给 Issue 2若阻碍发布Codex/OpenCode 安装目标不做进首轮当前仓库 manifest 里opencode、codex等目标已扩展说明这是后续的演进结果不把仓库重组成多个独立发布包。验收标准可验证的安装行为工单给出 6 条验收标准翻译成可测试断言即install.sh能解析并安装一个具名 profileinstall.sh能解析显式模块 ID目标不支持的模块被确定性跳过或拒绝legacy 语言安装模式仍然可用测试覆盖 profile 解析与安装器行为文档解释新的推荐 profile/module 安装路径。仓库现状manifest 背后的真实结构理解这个工单关键是看清 profile 与 module 两层数据结构。当前 manifests/install-profiles.json 定义了多个具名 profile例如minimal面向低上下文 Claude Code 场景包含 rules/agents/commands/platform-configs/workflow-quality不含 hook runtimecore最小编制的 harness 基线在上述基础上加hooks-runtimedeveloper面向大多数应用代码库场景的默认工程 profile在 core 上叠加 framework-language、database、orchestration 等security安全侧重配置research研究与内容创作场景research-apis、business-content、social-distribution 等full当前已分类模块的全量安装。而 manifests/install-modules.json 为每个模块声明了id、kindrules/agents/commands…、描述、paths该模块拥有哪些相对路径、targets支持哪些目标、dependencies、defaultInstall、cost与stability。例如rules-core的paths为[rules]支持claude、cursor、antigravity等十余个目标commands-core则把commands目录以及scripts/harness-audit.js、scripts/skills-health.js两个脚本收进同一模块。可见target-aware 过滤在 manifest 层就已经有了数据基础。scripts/install-plan.js在命令行层将这些数据暴露给用户常用形式为node scripts/install-plan.js --list-profiles # 列出所有 profile node scripts/install-plan.js --list-modules # 列出所有模块 node scripts/install-plan.js --profile developer # 解析 developer profile 的计划 node scripts/install-plan.js --modules rules-core,commands-core --target claude node scripts/install-plan.js --config path # 从 ecc-install.json 读取安装意图 node scripts/install-plan.js --profile core --without hooks-runtime --json其中--json输出机器可读的计划供上层安装器或 CI 消费--with / --without允许在 profile 基础上做增量微调--skills skill-id会把技能组件以skill:id前缀纳入解析。计划解析背后由 scripts/lib/install-manifests.js 的resolveInstallPlan承担并与 scripts/lib/install/request.js 的normalizeInstallRequest协同——先把原始请求规范化成profile modules include/exclude components legacy 语言的统一结构再做模块筛选。Issue 2install-state 与 uninstall / doctor / repair 生命周期#421问题本质没有安装状态记录生命周期全靠猜工单的核心论断非常精炼ECC 没有规范化的已安装状态记录installed-state record导致卸载、修复与安装后检查都不确定。仓库虽然能对可安装内容分类却无法可靠回答四个问题装的是什么 profile / 哪些模块装进了哪个 targetECC 拥有哪些路径如何只移除或修复 ECC 管理的文件。一旦缺少 install-state生命周期命令就只是猜测lifecycle commands are guesswork。Scope引入持久化 install-state 契约与首批生命周期命令工单规划了四个命令正好对应仓库根目录下的四个可执行脚本ecc list-installed→ scripts/list-installed.jsecc uninstall→ scripts/uninstall.jsecc doctor→ scripts/doctor.jsecc repair→ scripts/repair.js工单还给出了建议的 state 存放位置按 target 区分Claude~/.claude/ecc/install-state.jsonhome 级Cursor./.cursor/ecc-install-state.json项目级Antigravity./.agent/ecc-install-state.json项目级state 文件至少需要捕获安装版本、时间戳、target、profile、解析后的模块列表、复制/管理的路径、以及来源仓库版本或包版本。Non-Goals避免推倒重来不从零重建安装器架构不做完整远程/云端控制面功能除自然演进外不扩展本地安装器之外的目标支持。验收标准成功的安装确定性地写入 install-statelist-installed能干净地报告 target/profile/modules/versiondoctor报告缺失或漂移drifted的管理路径repair依据记录的 install-state 恢复缺失的管理文件uninstall只移除 ECC 管理的文件不碰无关本地文件测试覆盖 install-state 创建与生命周期行为。仓库现状install-state 契约已经落地这条验收标准的确定性在仓库中被翻译成了 JSON Schemaschemas/install-state.schema.json。它定义了ecc.install.v1契约顶层必填字段为schemaVersion固定ecc.install.v1installedAt以及可选的lastValidatedAttargetid、root、installStatePath且kind只能是home或project——这正好印证工单里home 级 vs 项目级两种 state 位置设计request完整记录用户的安装请求包括profile可为 null、modules、includeComponents、excludeComponents、legacyLanguages、legacyMode布尔与可选的hookConsentresolutionselectedModules与skippedModules两个数组——这让哪些模块被选中、哪些被跳过在事后依然可审计sourcerepoVersion、repoCommit、manifestVersion实现工单要求的来源仓库版本或包版本operations逐条记录复制/写入操作每条含kind、moduleId、sourceRelativePath、destinationPath、strategy、ownership、scaffoldOnly可选contentSha25664 位十六进制从而精确圈定ECC 拥有哪些路径。也就是说路径所有权在 schema 层通过每个 operation 的ownership字段显式声明这为uninstall只删 ECC 管理文件、repair按 operation 重建、doctor比对文件是否存在提供了结构化依据。运行实现则集中在 scripts/lib/install-lifecycle.js例如discoverInstalledStates与uninstallInstalledStates分别支撑 list 与 uninstall。list-installed.js的人类可读输出按 adapter 列出Root、Installed时间、Profilelegacy/custom 时标注与Modules并支持--target与--jsonuninstall.js还额外处理了 legacy 的sync-ecc-to-codex.sh制品仅在存在 legacy 所有权清单时清理必要时用--legacy-codex-sync强制走 legacy 路径并支持--dry-run先演练再动手——这与验收标准中只移除 ECC 管理的文件一脉相承。Issue 3ECC 2.0 控制平面的规范会话适配契约#424问题本质编排已有但都是实现特化工单描述的现状分层很清晰tmux/worktree 编排已存在机器可读的会话快照已存在Claude 本地会话历史命令已存在但缺少的是一个harness 无关的适配边界adapter boundary用来把以下会话/任务来源归一化tmux 编排的 workers普通 Claude 会话Codex worktreesOpenCode 会话未来的远程或 GitHub 集成操作面。如果不定义这个契约任何未来的 ECC 2.0 operator shell 都只能被迫直接读取 tmux 专属与 markdown 协调细节。Scope首批适配层交付物adapter 注册表registry规范会话快照 schema由现有编排代码支撑的dmux-tmuxadapter由现有会话历史工具支撑的claude-historyadapter用于检查规范快照的只读 inspection CLI。Non-Goals不在同一 issue 内做完整 ECC 2.0 UI不做商业化 / GitHub App 实现不做远程多用户控制面。验收标准有文档化的规范快照契约现有 tmux 编排快照代码被包装为 adapter而不是继续充当顶层产品契约存在第二个非 tmux adapter以证明抽象是真实的测试覆盖 adapter 选择与规范化快照输出设计清晰区分 adapter 关注点与编排、UI 关注点。仓库现状ecc.session.v1契约与实现这条验收标准在仓库里同样有明确落点。docs/SESSION-ADAPTER-CONTRACT.md 就是规范文档声明规范快照契约为ecc.session.v1并以 scripts/lib/session-adapters/canonical-session.js 为实现与消费者的规范来源。契约规定每个 adapter 必须返回一个可 JSON 序列化的对象顶层形状固定为{ schemaVersion: ecc.session.v1, adapterId: dmux-tmux, session: { id: workflow-visual-proof, kind: orchestrated, state: active, repoRoot: /tmp/repo, sourceTarget: { type: session, value: workflow-visual-proof } }, workers: [ { id: seed-check, label: seed-check, state: running, health: healthy, branch: feature/seed-check, worktree: /tmp/worktree, runtime: { kind: tmux-pane, command: codex, pid: 1234, active: false, dead: false }, intent: { objective: Inspect seeded files., seedPaths: [scripts/orchestrate-worktrees.js] }, outputs: { summary: [], validation: [], remainingRisks: [] }, artifacts: { statusFile: /tmp/status.md, taskFile: /tmp/task.md, handoffFile: /tmp/handoff.md } } ], aggregates: { workerCount: 1, states: { running: 1 }, healths: { healthy: 1 } } }从这个快照结构可以读出设计意图runtime.kind如tmux-pane只是 worker 运行时细节被归入一个字段而非顶层health与state是归一化后的业务语义aggregates让控制面无需遍历所有 worker 即可得到聚合视图。这样无论底层是 tmux pane、Codex worktree 还是未来远程会话上层 UI/operator shell 读到的都是同一套字段正好兑现工单不再直接读 tmux 细节的目标。Issue 4生成技能的去向与溯源策略#422问题本质技能面在增长策略没跟上工单点出 ECC 的技能面skill surface已经大且持续增长但生成generated/导入imported/学习learned的技能缺少清晰的长期放置与溯源策略进而引发四类问题策展技能curated与生成/学习技能之间边界不清校验器对本地可能有也可能没有的目录产生噪声导入或机器生成内容的溯源薄弱未来自动化学习产物的存放位置不确定。仓库中skills/下既有大量手动维护的 SKILL.md又有 agent-self-evaluation、continuous-learning-v2、rules-distill、skill-stocktake 这类会产出学习结果或自动生成内容的技能目录这正是工单所述矛盾的直接背景。Scope定义仓库级策略策展 vs 生成 vs 导入技能的放置规则溯源元数据要求校验器对可选/生成目录的行为生成技能是随包发布、被 ignore、还是在 install/build 步骤中物化materialize。Non-Goals不做完整的外部技能市场不一次性重写全部现有技能内容不试图在同一 issue 解决所有内容质量问题。验收标准存在文档化的生成/导入技能放置策略溯源要求明确校验器不再对可选/生成技能位置产生含糊行为策略清楚说明什么可发布、什么仅本地后续实现工作被拆分为具体、有界的 PR 级步骤。仓库现状溯源 Schema 与放置政策的落实当前 docs/SKILL-PLACEMENT-POLICY.md 已把工单的验收要求展开为具体规则可归纳为以下分层技能类别来源溯源要求策展技能ECC 仓库直接维护通过SKILL.mdfrontmatter 的origin如 ECC、community标注归属无单独 provenance 文件学习/演进技能evaluate-session、/learn、instinct evolve 等自动产出必须有与SKILL.md同级的.provenance.json导入技能URL、文件复制等外部来源必须有与SKILL.md同级的.provenance.json本能导出instincts由源 instinct 继承而来溯源从源继承无需单独.provenance.json策略文件还给出了实现链路的精确指针溯源 schema 定义在 schemas/provenance.schema.json校验逻辑在scripts/lib/skill-evolution/provenance.js的validateProvenance并规划了分批落地步骤——先落策略与 schema再把溯源校验接入 learned-skill 写入路径接着让 instinct-cli evolve 写入可选溯源最后视需要把scripts/validate-provenance.js接入 CI。值得注意的是第 5 个工单#425Define governance and visibility past the tool call在文档的 GitHub 状态列表中列出但其正文未包含在本地 bundle 内。从主题看它与上述四份工单方向一致都指向工具调用安装、执行、生成之后如何治理、如何可见这一 Phase 1 的总体目标。四份工单的共性方法论把这四份 issue 放在一起可以看到 ECC 团队处理平台级演进时反复使用的一套可复用方法这对任何希望用 issue 驱动重构的仓库都有借鉴价值先盘点已落地地基再定义缺失步骤。Issue 1 明确说missing step is no longer design discovery... missing step is executionIssue 2 列出现有分类能力Issue 3 列出 tmux/快照/历史命令三个已有事实。这避免了重复造轮子也让 issue 的剩余工作量边界清晰。每条验收标准都可测试、可演示。四份工单的验收标准几乎都能翻译成 shell 命令 断言解析 profile、写入 state、报告 drift、恢复文件、输出归一化快照、生成 provenance 文件。范围控制靠 Non-Goals 显式声明。每份工单都写下本期不做清单防止把市场、UI、远程控制面等大主题卷进小迭代。设计契约先于产品实现。Issue 3 专门要求第二个非 tmux adapter 证明抽象真实并用ecc.session.v1schema、ecc.install.v1schema、provenance.schema.json这类版本化 JSON 契约把约定固化为可校验文件。延伸阅读manifests/install-profiles.json 与 manifests/install-modules.json选择性安装的 profile 与模块数据源schemas/install-state.schema.jsoninstall-state 的ecc.install.v1契约docs/SESSION-ADAPTER-CONTRACT.md会话快照ecc.session.v1的规范说明docs/SKILL-PLACEMENT-POLICY.md 与 schemas/provenance.schema.json技能放置策略与溯源契约相关设计文档docs/SELECTIVE-INSTALL-ARCHITECTURE.md、docs/SELECTIVE-INSTALL-DESIGN.md命令实现scripts/install-plan.js、scripts/list-installed.js、scripts/uninstall.js、scripts/doctor.js、scripts/repair.js以及底层 scripts/lib/install-manifests.js 与 scripts/lib/install-lifecycle.js。【免费下载链接】ECCThe agent harness performance optimization system. Skills, instincts, memory, security, and research-first development for Claude Code, Codex, Opencode, Cursor and beyond.项目地址: https://gitcode.com/GitHub_Trending/ev/ECC创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考