docs(P20T2-5): 差旅对公支付边界事件矩阵收口

docs/integration-boundaries.md

@@ -1,7 +1,7 @@
-# 集成边界冻结（P19 / P19+IM-1 / P19+ERP-3 / R10 / P19+MCP-1 / P19+AI-1 / P20+TRAVEL-1）
+# 集成边界冻结（P19 / P19+IM-1 / P19+ERP-3 / R10 / P19+MCP-1 / P19+AI-1 / P20+TRAVEL-1 / P20+TRAVEL-2）
 
 **快照日期**：2026-03-10
-**当前基线**：`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` 关联入站的一期差旅基线。
+**当前基线**：`P19+IM-1`、`P19+ERP-1`、`P19+ERP-2`、`P19+ERP-3`、`P19+MCP-1`、`P19+AI-1` 与 `P20+TRAVEL-1`、`P20+TRAVEL-2` 已完成；当前运行时已落地企微群机器人 + 深链 + Outbox 异步派发的一期协同适配，以及 ERP 主数据 Pull、报销付款凭证切片、采购双阶段 journal / 归档摘要出站、资产台账摘要出站、Postgres MCP 只读工具基线、报销 / 采购 / 资产详情页 AI 只读建议挂件，以及差旅申请主单 / 行程段 / 审批预算锁定 / `travel_orders` 关联入站与混合双轨对公支付闭环的两期差旅基线。
 **目标**：在保持核心域稳定的前提下，冻结 ERP / IM / AI / MCP / TRAVEL 的长期边界，并记录 IM 一期、ERP 三期、AI 一期与差旅一期的已实现范围、禁入规则以及 R10 之后的固定主线顺序。
 
 ## 1. 总体原则
@@ -142,7 +142,7 @@
 - 已在报销详情、采购详情、资产详情挂载 AI 建议卡片；当权限不足、总闸关闭、feature flag 未命中、上游超时或响应非法时，仅在卡片内降级展示，不影响主体页面渲染与业务动作。
 - 已固定审计动作 `AI_SUGGESTION_REQUESTED`，仅记录 `targetType / targetId / provider / model / promptHash / tokenUsage / featureFlag`，不记录原始 prompt、脱敏前 payload 或上游全文。
 
-## 5. 差旅一期边界
+## 5. 差旅边界
 
 ### 5.1 P20+TRAVEL-1 已实现范围
 - 已新增 `TravelRequest`、`TravelRequestSegment` 与 `travel_orders.travel_request_id`，形成“差旅申请主单 + 行程段明细 + 外部订单事实关联”的一期差旅模型。
@@ -157,6 +157,19 @@
 - 不做企业卡授权、交易导入、对公支付与清结算，这些能力继续固定在 `P20+TRAVEL-2` / `P20+TRAVEL-3`。
 - `travel_order.imported` 当前仍只是内部集成事实与入站表更新，不提升为稳定公共事件名。
 
+### 5.3 P20+TRAVEL-2 已实现范围
+- 已新增 `CardAuthorization`、`CardTransaction`、`travel_orders` 支付字段与 `invoice_pool.travel_order_id`，形成“申请预算轨 + 企业卡支付轨 + 手工结算入口”的混合双轨模型。
+- 已新增 `travel.payment.manage` 权限，以及 `GET /api/travel/authorizations`、`POST /api/travel/authorizations/import`、`GET /api/travel/transactions`、`POST /api/travel/transactions/import`、`POST /api/travel/transactions/:id/freeze-suggestion`、`POST /api/travel-orders/:id/mark-paid`、`GET /api/travel-requests/:id/payment-track`。
+- 已固定 `travel_request` 申请预算语义继续停留在 `reserve / confirm / release`；`TRAVEL-2` 新增支付预算语义 `authorize / settle / reverse`，实体维度分别落在 `card_authorization` 与 `card_transaction`。
+- 已固定 `charge + settled + 金额币种精确匹配` 才能把 `TravelOrder` 从 `imported` 推进到 `confirmed`；`mark-paid` 只允许 `confirmed -> paid` 或同 payload 幂等重放，不回改差旅申请审批状态。
+- 已固定 `travel_order.paid` 为本期唯一新增稳定公共事件名，并在 `erp_sync` 总闸开启时直接复用 `erp.journal.export` 出站 `travel_order_payment` journal；发票仅绑定到订单，默认不自动归档，AP 摘要与核销仍留给 `TRAVEL-3`。
+
+### 5.4 差旅二期明确不做
+- 不接真实商旅供应商 API，不做出票、改签、退票、拒付、退款回调或银行清结算。
+- 不把 `travel_request.approved -> budget confirm` 的申请预算语义后移到支付阶段。
+- 不在 `TRAVEL-2` 提前实现 AP 摘要桥接、核销批次、requeue / dead-letter 运营面板；这些能力继续固定在 `P20+TRAVEL-3`。
+- `card_authorization.imported`、`card_transaction.imported`、`card_transaction.reversed` 当前仍只作为内部导入事实与支付轨道明细，不提升为稳定公共事件名。
+
 ## 6. 事件与通知交付规范
 
 ### 6.1 事件最小结构
@@ -215,7 +228,7 @@
 ## 9. R10 后续路线冻结
 
 ### 9.1 固定主线顺序
-- `P20+TRAVEL-1` 已完成后，当前固定后续主线顺序为：`P20+TRAVEL-2 -> P20+TRAVEL-3 -> P21+PWA-1 -> P21+PWA-2`。
+- `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`。