PJ2026-010401080313 纯Kafka权威架构偏离复盘

1. 事件摘要

字段	内容
严重度	P0 开发事故
日期	2026-07-14
影响规格	PJ2026-010401080313 Workbench实时权威
关联执行	pikasTech/HWLAB#2538、PR #2540
事故类型	未经授权改变 event authority、persistence 和 replay 架构，并引入数据库 schema 启动硬前置
当前状态	已停止继续扩展，正在通过新 PR 精确纠偏；禁止粗暴 reset 或覆盖无关修改

事故边界如下：

原始目标是修复 Workbench timing/duration 与一次 17 分钟投影异常。
原始架构要求坚持 agentrun.event.v1 -> hwlab.event.v1 -> 实时 SSE / Kafka retention 回放 SSE。
实际实现把链路替换为 PostgreSQL transactional projector、facts/outbox 和数据库 replay。
实际实现删除 direct publish、live Kafka SSE 与 Kafka refresh replay，构成对用户目标和实时权威的根本偏离。

2. 时间线

阶段	事实
事故前	运行配置启用 direct publish、live Kafka SSE、Kafka refresh replay；transactional projector 与 projection outbox relay 关闭。
任务定义	#2538 和 MDTODO 被错误写成“删除 direct/live/refresh，固定 transactional projector”，没有先证明 duration 故障需要改变 authority。
实现	`3e03e94e` 固定 transactional 投影并修改 timing；`fc87a7e5` 删除 direct/live/refresh；`bef23280` 删除 HTTP 自动补链；`2603b00c` 继续清理旧投影残余。
合并	PR #2540 通过 merge commit `6ae0d1b5a48118b6a65a521919de0bc5801e969d` 进入 `v0.3`。
部署	PipelineRun/GitOps 成功，但新 Cloud API Pod 因 `workbench_transactional_realtime_schema_blocked` CrashLoop；Argo 为 `Synced/Degraded`，旧 Pod 继续服务。
判定	数据库迁移被误认为新架构的必要条件，随后确认它不是原纯 Kafka实时/回放能力的依赖。
止损	主代理纠正 #2538 与 MDTODO，要求从最新 `v0.3` 建新分支和新 PR，逐文件恢复纯 Kafka路径并保留无关修复。

3. 影响

新 Cloud API Pod 无法启动，滚动发布退化；旧 Pod 暂时维持服务，因此未发生完整业务中断。
CI/CD 显示成功而运行面 Degraded，扩大了“流水线成功等于发布成功”的可见性误差。
原本无需数据库迁移的实时/回放链被增加 v8 schema 前置，导致修复路径被错误引向数据库迁移。
direct publish、live/replay Kafka 代码被删除，回退成本从配置切换扩大为代码纠偏。
子代理和主代理的多轮 review 围绕新架构内部一致性优化，消耗时间并偏离原始 Web 增强主线。

4. 直接原因

任务合同直接把未经用户授权的 PostgreSQL transactional projector 写成目标架构。
PR 删除原 authority 路径，并用启动断言强制新 schema 就绪。
review 把“Kafka 仍在链路中”误判为“纯 Kafka”，没有检查 Kafka 是否仍是实时和回放 authority。
canonical duration 修复与 authority 替换被耦合在同一 PR，未保持问题与架构变更的因果边界。

5. 系统性原因

派单前没有写出 current data flow、desired data flow 和两者差异，也没有要求用户授权 authority/persistence/replay 变化。
主代理以测试和内部一致性替代对用户目标、最新 SPEC、线上运行配置和数据流的优先审查。
较旧“Workbench唯一投影”规格包含数据库 outbox 设计，较新的纯 Kafka要求尚未形成明确优先级裁决；冲突未先解决就进入实现。
新测试验证了 transactional 架构，却没有证明该架构是被授权目标；测试把偏移固化成了代码门禁。
rollout 验证只看到 PipelineRun/GitOps 成功，没有把新 Pod readiness、Argo health 和启动 blocker 作为同一发布判定。

6. 主代理责任

主代理对事故负最终责任：主代理创建和接受了错误任务合同，未在派单前完成架构裁决；review 时继续要求删除旧路径；在看到 schema blocker 后仍一度沿数据库迁移方向调查。子代理按错误合同实现不能替代主代理的架构审查责任。

7. 检测与恢复

本次事故由新 Pod CrashLoop、Argo Synced/Degraded 和 workbench_transactional_realtime_schema_blocked 暴露。恢复不执行数据库迁移来承认新架构，而是从最新 v0.3 创建精确纠偏提交：

恢复 direct publish、live Kafka SSE 和 Kafka retention replay。
删除 v8 schema 作为 Cloud API 启动前置。
保留 canonical duration、feature config schema、HTTP fallback 禁令和无关修复。
通过新的 PR、自动 PaC/GitOps/Argo 上线，并在原入口校对 live/replay SSE、terminal/final 和 canonical duration。

禁止 reset、force push、整提交粗暴反转或人工 runtime patch，以免覆盖 PR #2540 中与架构偏移无关的正确修改。

8. 纠正与防复发措施

措施	Owner	完成判定
更新实时权威 SPEC	主代理	明确纯 Kafka data flow、数据库非阻塞边界和新旧规格优先级。
精确纠偏 PR #2540	HWLAB 实施代理	新 PR 恢复 live/replay 路径，Cloud API 不再依赖 v8 schema 启动。
原入口验证	主代理审核	自动上线后以同一 session/trace 校对实时、刷新回放、terminal/final 与 duration。
固化派单规则	主代理	`unidesk-subagent` 要求 current/desired data flow 和架构变化授权。
固化 review 顺序	主代理	先比较用户目标、SPEC、运行 data flow，再看代码内部一致性和测试。
CI/CD 可见性	独立任务	PipelineRun 成功但 Argo/Pod degraded 时明确报告发布未完成，不以 schema warning 阻塞滚动。

9. 长期判定

修复 timing、duration、丢事件或 UI 收敛问题时，不得默认改变 event authority、transport、persistence、replay 或 source of truth。若证据表明确需架构变化，必须先更新长期 SPEC，写清 current/desired data flow、迁移与回退方案，并取得用户明确授权；新增测试只能验证已授权架构，不能反向把未经授权的实现合法化。

6.2 KiB Raw Permalink Blame History Unescape Escape