ECC 2.0 可观测性就绪¶

ECC 2.0 在变得更加自主之前应当具备可观测性。本地默认是一个可选启用、由仓库拥有的就绪门禁，用于检查核心信号是否存在，而不会将遥测发送到任何地方。

运行：

npm run observability:ready
node scripts/observability-readiness.js --format json

该门禁是确定性的，并且可安全地在 CI 中运行。它只检查仓库文件，并报告发布面是否能够暴露运维人员所需的信号。

信号模型¶

• 实时状态：scripts/loop-status.js 可以输出 JSON、监视活动循环，并为仪表盘或交接写入快照。
• HUD/状态契约：docs/architecture/hud-status-session-control.md 和 examples/hud-status-contract.json 定义了用于上下文、工具调用、活动代理、待办事项、检查、成本、风险、队列、会话控制和跟踪器同步的可移植负载。
• 会话跟踪：scripts/session-inspect.js 可以检查 Claude、dmux 和基于适配器的会话，然后写入规范快照。
• 框架基线：scripts/harness-audit.js 为工具覆盖、上下文效率、质量门禁、记忆持久性、评估覆盖、安全护栏和成本效率提供可重复的记分卡。
• 工具活动：scripts/hooks/session-activity-tracker.js 记录本地 tool-usage.jsonl 事件，ECC2 可以同步这些事件。
• 风险台账：ecc2/src/observability/mod.rs 对工具调用进行评分，并存储分页台账以供审查。
• 进度同步：docs/architecture/progress-sync-contract.md 定义了 GitHub、Linear、本地交接、仓库路线图以及 scripts/work-items.js 在合并批次和发布门禁审查期间如何保持一致。
• 发布安全：在任何公开标签、包发布、插件提交或公告操作之前，必须存在 docs/releases/2.0.0-rc.1/publication-readiness.md、加固后证据、供应链事件响应、工作流安全验证、npm pack 检查和发布面测试。

参考压力¶

当前的代理工具生态系统正在收敛到相同的运维需求：

• dmux、Orca 和 Superset 强调隔离的工作树，外加一个查看代理状态以及合并/审查工作的地方。
• Claude HUD 使上下文、工具活动、代理活动和待办进度在编码循环中可见。
• Autocontext 将每次运行记录为持久跟踪、报告、工件和可复用改进。
• Meta-Harness 将框架本身视为需要评估和改进的对象，这需要关于提议者行为和结果的清晰日志。
• Zed 和 OpenCode 强调代理控制界面、可审查的更改，以及应保留可移植项目知识的框架特定配置。

ECC 的答案默认不是托管分析依赖。第一个候选发布门禁是本地且基于文件的。托管遥测可以稍后引入，但只有在本地事件模型足够有用、值得信任之后才行。

运维工作流¶

1. 运行 npm run observability:ready。
2. 运行 npm run harness:audit -- --format json 以获取更广泛的框架记分卡。
3. 在较长的自主批次期间，运行 node scripts/loop-status.js --json --write-dir .ecc/loop-status。
4. 在接入新的 HUD 或运维仪表盘之前，审查 examples/hud-status-contract.json。
5. 运行 node scripts/session-inspect.js --list-adapters 以确认可用的会话界面。
6. 在依赖受跟踪仓库的本地工作项状态之前，运行 node scripts/work-items.js sync-github --repo <owner/repo>。
7. 在提高自主性之前，使用 ECC2 工具日志进行风险操作、冲突分析和交接审查。
8. 在任何公开发布操作之前，重新运行发布安全证据检查：发布就绪、供应链事件响应、工作流安全验证、包面和发布面测试。

最终状态是务实的：在要求 ECC 运行更大的多代理循环之前，运维人员可以证明系统具备实时状态、持久会话跟踪、基线记分卡、本地风险台账，以及一个进度同步契约，该契约可防止 GitHub、Linear、交接和路线图证据彼此偏离。