Codex
1.8 KiB
1.8 KiB
R2.1 任务报告
完整只读审计见 UniDesk #1869，执行任务为 qt_c4072b7278ed409f94dc271d69f39540。
需求与失效边界
- 架构已从 #891 的单一 24 小时 dry-run 演进为多 runner、全局 latest/history、Dashboard、cadence freshness 与 OTel；#1861 是执行到 record/index 断点的局部实证，不是唯一架构依据。
- 当前 monitorRoot 只是选择某个 sentinel 的 public root，不是中心聚合服务。
- 每 runner 私有 SQLite 在单实例可用，但跨 runner 必然产生多权威、fan-out、部分失败和不同 latest 语义。
- monitor-web 绑定当前 runner API，并对历史 run 发出 N+1 detail 请求；聚合留在 UI 会使 CLI、页面和服务看到不同事实。
- runner 服务同时持有执行、索引、查询和前端，已越过可维护边界。
必须满足
- 配置、Host PG role/database/export/Secret consumer、迁移与切换状态全部 YAML-first。
- 每 sentinel 只有一个 cadence/CronJob 调度权威，并明确区分业务 cadence 与 heartbeat。
- runner 负责 observe/analyze 与不可变 artifact；中心 Monitor 拥有全局 durable index/read model。
- global latest/history/finding/artifact locator 由同一中心 API 选择，CLI 与 monitor-web 共用。
- 复用 NC01 Host PG；一次性迁移可计数、校验、切换、回滚，完成后无永久双写、SQLite fallback 或第二索引。
- 近 3000 行 service 按执行、持久化、查询和 UI 边界拆分。
方案选择
拒绝 runner API fan-out 聚合与共享 runner/PVC/SQLite。采用中心 Monitor service + NC01 Host PG；runner 保留执行与 artifact owner，monitor-web 只读中心 API。artifact 文件是否迁移由 R2.2 冻结。