进度同步契约¶

ECC 2.0 跟踪跨 GitHub、Linear、本地交接和仓库路线图之间的执行状态。本契约定义了状态更新在声称某个泳道为最新之前所需的最小证据。

事实来源¶

流程泳道¶

仓库镜像使用这些流程泳道，以便 ECC 工作不会坍缩为一个未分级的积压：

• 队列卫生和陈旧工作回收
• 发布、命名、插件发布和公告
• 测试框架适配器合规性
• 本地可观测性、HUD/状态和会话控制
• 评估器/RAG 和自我改进测试框架循环
• AgentShield 企业安全平台
• ECC Tools 计费、PR 风险检查、深度分析和 Linear 同步
• 遗留工件审计和翻译器/人工审查尾部

每个流程泳道需要一个负责人工件、一个当前证据来源和一个下一步行动。如果这三个字段中有任何一个缺失，则该泳道不处于最新状态。

重要合并批次更新¶

在重要合并批次之后，使用以下内容更新 Linear 和交接：

1. 受跟踪 GitHub 仓库的当前公共队列计数。
2. 已合并 PR 编号、提交 ID 和验证证据。
3. 如有变更，变更后的发布门禁。
4. 延迟或跳过的工作以及明确原因。
5. 接下来的一到两个实现切片。

当 Linear 项目状态更新不可用时，请使用项目文档加上项目/问题评论，而不是创建占位问题。问题容量可用于持久执行泳道，但不要将该问题容量用作有证据支持的项目状态的替代。仅当泳道需要持久执行负责人时，才创建或复用精确标题的问题，并将这些问题链接到仓库证据。

实时边界¶

本地实时路径默认基于文件：

• node scripts/work-items.js sync-github --repo <owner/repo> 将当前 GitHub PR 和问题状态导入 SQLite 工作项存储。
• node scripts/status.js --json 和 node scripts/work-items.js list --json 为 HUD、交接或后续 Linear 同步暴露本地状态。
• Linear 仍然是外部状态表面；仓库不要求托管遥测即可达到发布就绪。

可以稍后添加 PostHog 等托管遥测，但它必须消费相同的事件模型，而不是成为第二个事实来源。

发布门禁¶

不要仅凭本契约就发布、打标签、公告、提交市场包或声称插件可用。发布就绪仍然需要发布就绪证据文档、最新的队列检查、包检查、插件检查以及明确维护者批准。