docs(P20T3-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 / P20+TRAVEL-2）
+# 集成边界冻结（P19 / P19+IM-1 / P19+ERP-3 / R10 / P19+MCP-1 / P19+AI-1 / P20+TRAVEL-1 / P20+TRAVEL-2 / P20+TRAVEL-3）
 
 **快照日期**：2026-03-10
-**当前基线**：`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` 关联入站与混合双轨对公支付闭环的两期差旅基线。
+**当前基线**：`P19+IM-1`、`P19+ERP-1`、`P19+ERP-2`、`P19+ERP-3`、`P19+MCP-1`、`P19+AI-1` 与 `P20+TRAVEL-1`、`P20+TRAVEL-2`、`P20+TRAVEL-3` 已完成；当前运行时已落地企微群机器人 + 深链 + Outbox 异步派发的一期协同适配，以及 ERP 主数据 Pull、报销付款凭证切片、采购双阶段 journal / 归档摘要出站、资产台账摘要出站、Postgres MCP 只读工具基线、报销 / 采购 / 资产详情页 AI 只读建议挂件，以及差旅申请主单 / 行程段 / 审批预算锁定 / `travel_orders` 关联入站、混合双轨对公支付闭环与批次级对账摘要桥的三期差旅基线。
 **目标**：在保持核心域稳定的前提下，冻结 ERP / IM / AI / MCP / TRAVEL 的长期边界，并记录 IM 一期、ERP 三期、AI 一期与差旅一期的已实现范围、禁入规则以及 R10 之后的固定主线顺序。
 
 ## 1. 总体原则
@@ -170,6 +170,19 @@
 - 不在 `TRAVEL-2` 提前实现 AP 摘要桥接、核销批次、requeue / dead-letter 运营面板；这些能力继续固定在 `P20+TRAVEL-3`。
 - `card_authorization.imported`、`card_transaction.imported`、`card_transaction.reversed` 当前仍只作为内部导入事实与支付轨道明细，不提升为稳定公共事件名。
 
+### 5.5 P20+TRAVEL-3 已实现范围
+- 已新增 `TravelReconciliationBatch` 与 `TravelReconciliationItem`，固定采用“批次快照 + 明细快照”持久化结构；人工确认、ERP 出站、track / requeue 都基于 batch，而不是 request-level 运行时即席对比。
+- 已固定 `TRAVEL-3` 只覆盖 `TravelOrder.status = paid` 的统付订单、同范围 `CardTransaction.status in (settled, reversed)` 的支付交易，以及不落在本批次范围内的 `orphan transaction`；`linked_reimbursement_id` 仅作为只读快照上下文保留。
+- 已新增 `/api/travel/reconciliation/batches`、`/api/travel/reconciliation/items/:itemId/confirm|reopen`、`/api/travel/reconciliation/batches/:batchId/finalize`，并固定 `matched` 项自动确认、其余 anomaly 必须人工确认后才能把 batch 从 `draft` 推进到 `reconciled`。
+- 已新增批次级集成事件 `erp.travel.export`，在 `erp_sync` 总闸开启且 batch 已 `reconciled` 时，按 `travel_reconciliation_batch:<batchId>:summary` dedupe key 出站 AP/对账摘要；成功派发后统一沉淀 `travel_payable_summary` 与 `travel_settlement_batch` 两类 binding。
+- 已把前端入口固定在 `/travel-requests?tab=reconciliation&batchId=<id>`，在同一路径下展示 KPI、异常明细、人工确认与 ERP 轨道，不新增独立差旅对账路由。
+
+### 5.6 差旅三期明确不做
+- 不自动修正 `TravelOrder.amount/status`、不自动改 `TravelRequest`、不自动改预算账轨；对账只做差异发现与人工接受，不做自动修复。
+- 不把 `travel_order_payment` journal 并入 `erp.travel.export`；`TRAVEL-2` 的订单支付出站继续保留，`TRAVEL-3` 只新增批次级 AP/对账摘要桥。
+- 不做真实商旅供应商清结算、拒付、退款回调、税分摊、复杂票规，也不新增 workflow 审批实例。
+- 若源数据变化，只允许新建下一批 reconciliation batch，不回刷已 finalized 的历史批次快照。
+
 ## 6. 事件与通知交付规范
 
 ### 6.1 事件最小结构
@@ -228,7 +241,7 @@
 ## 9. R10 后续路线冻结
 
 ### 9.1 固定主线顺序
-- `P20+TRAVEL-2` 已完成后，当前固定后续主线顺序为：`P20+TRAVEL-3 -> P21+PWA-1 -> P21+PWA-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`。