feat: add unified OA event flow

docs/reference/pipeline-oa-event-flow.md

@@ -4,12 +4,12 @@ Pipeline 的最终控制模型必须是 100% OA 事件流驱动。开发过程
 
 ## Core Principles
 
-- OA backend 是 Pipeline runtime 的唯一控制总线；node、monitor、runner、UniDesk frontend 和 CLI 都只能通过 OA 事件表达事实、订阅事实或发出控制意图。
+- 统一 `oa-event-flow` 微服务是跨业务 OA 事件存储、tag 订阅和统计投影基础设施；Pipeline backend 在其上实现 Pipeline runtime 的唯一控制总线。node、monitor、runner、UniDesk frontend 和 CLI 都只能通过 OA 事件表达事实、订阅事实或发出控制意图。
 - Node 之间不得直接启动、暂停、重试或通知彼此；monitor 不得绕过 OA 直接控制 runner；frontend 不得直接写 Pipeline `.state`、prompt 文件、命令队列或 worker 状态文件。
 - 事实事件只描述已经发生的事实，策略判断由 OA 加载 Pipeline config/topology 后完成；`node-finished` 不得携带 `legacy audit policy flag`、`nextNodeIds`、`shouldStartDownstream` 这类控制决策字段。
 - 控制行为必须由 OA 控制/管理事件表达，例如 start downstream、pause、resume、single-step、append prompt、guide、modify、approve、redo/restart、skip、cancel 和 retry。
 - 如果 procedure 或 monitor 结束后缺少预期 OA 提交，runner 必须把它视为可恢复的 OA contract failure：在重试预算内通过 OA 事件写入明确反馈并启动 fresh attempt，不能直接把一次缺失提交升级成最终失败；预算耗尽后才 fail closed。
-- UI、CLI、E2E 和调试工具都应消费 OA 归一化读接口或通过 OA 控制 API 写入事件，不得解析 monitor 文本、worker log、runner 私有文件或旧 JSONL 文件来反推控制语义。
+- UI、CLI、E2E 和调试工具都应消费统一 OA 归一化读接口、`oa-event-flow` 事件表/tag stream 或通过 OA 控制 API 写入事件，不得解析 monitor 文本、worker log、runner 私有文件或旧 JSONL 文件来反推控制语义。
 - 旧的本地文件传输通道必须完全退出控制路径：不得创建、轮询或依赖 `control-prompts.jsonl`、`monitor-prompts.jsonl`、`monitor-control`、`control-events.jsonl`、monitor stop 文件、`.state/pipeline-runs/{runId}/control/commands/` 或给 monitor 容器挂载可读 `/pipeline-state` 来完成 prompt、stop、guide、approve、redo/restart、append 或 UI/Gantt 事件取证。
 
 ## Benchmark Prompt And Skill Boundary
@@ -41,8 +41,8 @@ Pipeline 的最终控制模型必须是 100% OA 事件流驱动。开发过程
 
 ## Event Identity And Tags
 
-- 每条事件必须有稳定 `eventId`、`type`、`createdAt`、`sourceKind`、`sourceId`、`correlationId` 和可选 `causationId`，用于排序、幂等、回放和追踪控制来源。
-- Pipeline 后端必须自动附加 scope tag：`pipeline:{pipelineId}`、`epoch:{runId}`，node 相关事件还必须带 `node:{nodeId}`；attempt/procedure 相关事件应带 `attempt:{attemptId}` 或 `procedure:{procedureRunId}`。
+- 每条事件必须满足统一 OA envelope：稳定 `eventId`、`type`、`createdAt`、`sourceKind`、`sourceId`、`aggregateType`、`aggregateId`、`correlationId`、可选 `causationId`、`tags` 和 `payload`，用于排序、幂等、回放和追踪控制来源；共享字段契约见 `docs/reference/oa-event-flow.md`。
+- Pipeline 后端必须自动附加 scope tag：`service:pipeline`、`pipeline:{pipelineId}`、`epoch:{runId}`，node 相关事件还必须带 `node:{nodeId}`；attempt/procedure 相关事件应带 `attempt:{attemptId}` 或 `procedure:{procedureRunId}`。
 - Monitor 在 config 中只声明要订阅的业务 tag 或事件类型，OA backend 在订阅时自动追加当前 `pipeline:{pipelineId}` 与 `epoch:{runId}` 限制，避免不同 pipeline 或 epoch 串流。
 - 一次 epoch 应绑定 config snapshot 或 config version；OA 的审核、拓扑推进、并发和单步策略都以该快照为准，避免运行中配置漂移导致控制解释不一致。
 - 控制事件必须有幂等键，重复投递同一个 start、approve、redo/restart 或 append prompt 时，OA 应识别为同一意图而不是重复启动或重复写入。
@@ -89,7 +89,8 @@ Pipeline 的最终控制模型必须是 100% OA 事件流驱动。开发过程
 
 ## Migration And Completion Gates
 
-- 分阶段重构只允许按“schema 文档与测试门禁 -> OA 事件写入 -> OA dispatcher 接管控制 -> UI/CLI 改为 OA 读写 -> 删除旧事件和旧控制路径”的方向前进，不得把双写/双读作为最终设计。
+- 分阶段重构只允许按“统一 oa-event-flow schema 文档与测试门禁 -> Pipeline/Code Queue 事实事件写入 -> OA dispatcher 接管 Pipeline 控制 -> UI/CLI 改为 OA 读写 -> 删除旧事件、旧统计和旧控制路径”的方向前进，不得把双写/双读作为最终设计。
+- 远端 Pipeline 尚未直接发布到主 server `oa-event-flow` 时，可以通过主 server Pipeline snapshot bridge 把 `/api/snapshot` 与 `/api/oa-event-flow/diagnostics` 形成的结构化运行事实以 `service:pipeline`、`pipeline:{pipelineId}` 和 `epoch:{runId}` tag 写入统一事件表；该 bridge 是迁移期单一路径接入层，只能保持幂等可见性，不能成为新的控制权威，也不得保留 ledger/snapshot 双路径 fallback。Pipeline 直接发布统一事件后必须删除该 bridge。
 - 完成态必须删除或禁用以下残留：`legacy detail audit policy flag` 作为权威策略字段、`legacy node audit request event` / `legacy monitor audit request event` 独立审核请求事件、`legacy batch completion gate` 控制推进、monitor 直接调用 runner、node 直接启动下游、frontend/CLI 直接写 `.state` 文件。
 - 完成态还必须删除文件传输残留：`PIPELINE_MONITOR_APPEND_FILE`、`PIPELINE_MONITOR_STOP_FILE`、`PIPELINE_MONITOR_CONTROL_DIR`、`PIPELINE_NODE_PROMPT_APPEND_FILE`、`control-events.jsonl`、`runControlEventFile`、`appendJsonLine`、`readJsonLineRecords`、`readPromptAppendFile`、`parseCommandFile`、`parseMonitorCommandFile`、`readMonitorCommands`、`fallbackMonitorInterventions`、`syntheticMonitorStopPrompt` 以及 monitor 的 `/pipeline-state` 挂载都不得出现在运行代码中。
 - E2E 必须覆盖有审核与无审核两条链路：无审核时由 OA 从 `node-finished` 推进下游；有审核时由 monitor 经 OA 控制事件推进下游；事件都必须带 `pipeline:{pipelineId}` 与 `epoch:{runId}` tag。