docs(P20T1-5): 差旅边界事件矩阵与校验器收口

2026-03-10 19:58:46 +08:00
@@ -1,8 +1,8 @@
-# 集成边界冻结（P19 / P19+IM-1 / P19+ERP-3 / R10 / P19+MCP-1 / P19+AI-1）
+# 集成边界冻结（P19 / P19+IM-1 / P19+ERP-3 / R10 / P19+MCP-1 / P19+AI-1 / P20+TRAVEL-1）

 **快照日期**：2026-03-10
-**当前基线**：`P19+IM-1`、`P19+ERP-1`、`P19+ERP-2`、`P19+ERP-3`、`P19+MCP-1` 与 `P19+AI-1` 已完成；当前运行时已落地企微群机器人 + 深链 + Outbox 异步派发的一期协同适配，以及 ERP 主数据 Pull、报销付款凭证切片、采购双阶段 journal / 归档摘要出站、资产台账摘要出站、Postgres MCP 只读工具基线与报销 / 采购 / 资产详情页 AI 只读建议挂件。
-**目标**：在保持核心域稳定的前提下，冻结 ERP / IM / AI / MCP 的长期边界，并记录 IM 一期与 ERP 三期的已实现范围、禁入规则以及 R10 之后的固定主线顺序。
+**当前基线**：`P19+IM-1`、`P19+ERP-1`、`P19+ERP-2`、`P19+ERP-3`、`P19+MCP-1`、`P19+AI-1` 与 `P20+TRAVEL-1` 已完成；当前运行时已落地企微群机器人 + 深链 + Outbox 异步派发的一期协同适配，以及 ERP 主数据 Pull、报销付款凭证切片、采购双阶段 journal / 归档摘要出站、资产台账摘要出站、Postgres MCP 只读工具基线、报销 / 采购 / 资产详情页 AI 只读建议挂件，以及差旅申请主单 / 行程段 / 审批预算锁定 / `travel_orders` 关联入站的一期差旅基线。
+**目标**：在保持核心域稳定的前提下，冻结 ERP / IM / AI / MCP / TRAVEL 的长期边界，并记录 IM 一期、ERP 三期、AI 一期与差旅一期的已实现范围、禁入规则以及 R10 之后的固定主线顺序。

 ## 1. 总体原则

@@ -142,9 +142,24 @@
 - 已在报销详情、采购详情、资产详情挂载 AI 建议卡片；当权限不足、总闸关闭、feature flag 未命中、上游超时或响应非法时，仅在卡片内降级展示，不影响主体页面渲染与业务动作。
 - 已固定审计动作 `AI_SUGGESTION_REQUESTED`，仅记录 `targetType / targetId / provider / model / promptHash / tokenUsage / featureFlag`，不记录原始 prompt、脱敏前 payload 或上游全文。

-## 5. 事件与通知交付规范
+## 5. 差旅一期边界

-### 5.1 事件最小结构
+### 5.1 P20+TRAVEL-1 已实现范围
+- 已新增 `TravelRequest`、`TravelRequestSegment` 与 `travel_orders.travel_request_id`，形成“差旅申请主单 + 行程段明细 + 外部订单事实关联”的一期差旅模型。
+- 已固定独立 `travel.*` 权限命名空间，并将 `travel_request` 纳入工作流实体映射、待办页、移动审批与通知深链 `/travel-requests?id=<id>`。
+- 已固定差旅一期持久状态仅 `draft / reviewing / approved / rejected`；`return` 与 `withdraw` 均回到 `draft`，释放预算并允许修改后重提。
+- 已复用预算三段语义：提交 `reserve`、审批通过 `confirm`、驳回 / 退回 / 撤回 `release`；预算池由 `legal_entity_id + cost_center_id + start_date` 自动解析。
+- 已固定一期工作流为直属经理单层审批，并把审批通过 / 驳回结果分别映射到 `travel_request.approved`、`travel_request.rejected` 通知类型。
+
+### 5.2 差旅一期明确不做
+- 不创建 `travel_request_commitment` journal，不写 `IntegrationOutbox`，不提前进入 `erp.travel.export`。
+- 不接真实票务 / 酒店 / 商旅供应商 API，不做自动出票、改签、退票。
+- 不做企业卡授权、交易导入、对公支付与清结算，这些能力继续固定在 `P20+TRAVEL-2` / `P20+TRAVEL-3`。
+- `travel_order.imported` 当前仍只是内部集成事实与入站表更新，不提升为稳定公共事件名。
+
+## 6. 事件与通知交付规范
+
+### 6.1 事件最小结构
 后续若继续扩展领域事件 / Outbox，建议统一包含：
 - `eventName`
 - `eventId`
@@ -155,72 +170,73 @@
 - `payloadVersion`
 - `payload`

-### 5.2 幂等要求
+### 6.2 幂等要求
 - 同一 `eventId` 必须可安全重放。
 - 消费端必须以 `eventId` 或 `entityId + status / version` 方式做幂等。
 - 不允许消费端以“收到多次事件”为理由修改核心业务状态。

-### 5.3 当前 IM 一期实现说明
+### 6.3 当前 IM 一期实现说明
 - 运行时仍以通知类型驱动 IM 入队，而不是直接暴露新的领域事件名。
 - `notification.im` 的 `dedupeKey` 固定为：
  - `${notificationType}:${targetType}:${targetId || targetPath}:${channelId}`
 - IM 失败仅影响 Outbox 状态，不回滚业务事务。

-## 6. MCP 基线
+## 7. MCP 基线

-### 6.1 P19+MCP-1 已实现范围
+### 7.1 P19+MCP-1 已实现范围
 - 已新增 `docs/mcp-tools.md`，作为项目级 MCP 工具目录与使用边界事实源。
 - 已新增 `.mcp.json.example`，仅提供 `postgres` 只读示例配置，不提交任何真实密钥、PAT 或数据库连接串。
 - 已新增 `scripts/validate-mcp-tools.py`，用于校验工具目录、示例配置与 `AGENTS.md` 引用关系。
 - 已明确当前 shell 中 `codex mcp list --json` 不可作为唯一事实源，因此工具目录固定以官方 package 文档、执行合同与仓库校验脚本共同收口。

-### 6.2 当前允许的 MCP 范围
+### 7.2 当前允许的 MCP 范围
 - `postgres MCP`：当前唯一允许启用的 MCP server，用于只读排障、迁移核对、账本核对。
 - `postgres:query`：固定用于只读 SQL 查询；所有查询必须处于 `READ ONLY` 事务语义下。
 - schema resources：允许读取表结构、字段类型与 schema 元数据，不得反向修改业务数据。

-### 6.3 Deferred candidate
+### 7.3 Deferred candidate
 - `github MCP`：当前仅记录为 deferred candidate，不纳入 enabled servers。
 - 原因：官方 GitHub MCP server 当前暴露读写混合工具集，不满足 `Read-only Tools Baseline`。
 - 若未来需要启用，必须通过新的路线合同显式解锁，并单独治理最小权限 PAT、读写边界与回滚策略。

-### 6.4 禁止事项
+### 7.4 禁止事项
 - 禁止提交真实 `.mcp.json`、真实数据库连接串、PAT、API Token 或其他密钥。
 - 禁止在没有 `docs/mcp-tools.md` 的前提下默认启用 MCP。
 - 禁止用 MCP 绕过仓库内已存在的本地验证命令。
 - 禁止将 MCP 用作写生产数据或修改业务状态的通道。

-## 7. 当前阶段明确不做
+## 8. 当前阶段明确不做
 - 不新增新的集成总线表结构
 - 不接入 ERP 真实写回逻辑
 - 不接入飞书 / 钉钉真实生产推送
 - 不新增 AI 写库动作
 - 不引入绕过工作流与权限体系的外部回调路径

-## 8. R10 后续路线冻结
+## 9. R10 后续路线冻结

-### 8.1 固定主线顺序
- `R10` 之后的固定主线顺序为：`P19+MCP-1 -> P19+AI-1 -> P20+TRAVEL-1 -> P20+TRAVEL-2 -> P20+TRAVEL-3 -> P21+PWA-1 -> P21+PWA-2`。
+### 9.1 固定主线顺序
+- `P20+TRAVEL-1` 已完成后，当前固定后续主线顺序为：`P20+TRAVEL-2 -> P20+TRAVEL-3 -> P21+PWA-1 -> P21+PWA-2`。
+- 历史主线顺序仍保持：`P19+MCP-1 -> P19+AI-1 -> P20+TRAVEL-1 -> P20+TRAVEL-2 -> P20+TRAVEL-3 -> P21+PWA-1 -> P21+PWA-2`。
 - 后续阶段继续遵循“先治理，再工具，再建议，再业务，再移动”的总顺序，不并行开启两个重业务 phase。
 - 每个 phase 固定遵循：`执行合同 CSV -> 方案批准 -> 开发 -> 测试 -> 文档矩阵收口 -> 合并 main`。

-### 8.2 MCP / AI 前置关系
+### 9.2 MCP / AI 前置关系
 - `P19+MCP-1` 已完成，并已把 `docs/mcp-tools.md`、`.mcp.json.example` 与 MCP 校验脚本固化为仓库治理基线。
 - 当前唯一允许启用的 MCP server 为 `postgres`；`github` 继续保持 deferred，不进入 enabled servers。
 - `P19+AI-1` 已在 `P19+MCP-1` 之后完成落地，并继续遵守“AI 只做建议，不直接写库”的硬边界。
 - 当前 AI 一期已覆盖采购、报销、资产详情的只读建议工作台；自由聊天、自动审批与 agent 自治仍明确不做。

-### 8.3 差旅统付主线
- `P20+TRAVEL-1` 固定负责差旅申请、行程段与 `travel_orders` 入站整合，作为对公统付的前置主数据与流程基线。
+### 9.3 差旅统付主线
+- `P20+TRAVEL-1` 已完成差旅申请、行程段、审批预算与 `travel_orders` 入站整合，作为对公统付的前置流程基线。
 - `P20+TRAVEL-2` 固定采用企业卡 / 虚拟卡授权与交易导入路线，优先复用 `docs/adr/adr-enterprise-card-control.md` 的既有结论。
 - `P20+TRAVEL-3` 固定负责核销闭环与 ERP / AP 摘要桥接；个人垫资报销继续与对公统付并存，不互相替代。

-### 8.4 PWA 兑现顺序
+### 9.4 PWA 兑现顺序
 - `P21+PWA-1` 固定先做移动资产扫码与盘点增强，优先兑现一线资产作业的生产价值。
 - `P21+PWA-2` 固定后做离线动作队列与企微深链增强，继续复用现有 `APP_ORIGIN + targetPath` 深链规范。
 - PWA 路线继续限定在浏览器 / PWA 栈内，不引入原生 App、小程序或双栈移动壳。

-### 8.5 后置 backlog
+### 9.5 后置 backlog
 - `P19+IM-2 / IM-3 / IM-4`、`P22+VEH-1`、`P22+ASSET-FIN-1` 明确列为后置 backlog，本轮不进入主线。
 - 这些方向只保留“触发条件 / 进入时机”的规划地位，不提前写入已完成矩阵或事实源校验器。
 - 若后续优先级发生变化，必须通过新的路线合同显式改序，不直接口头跳 phase。