完善M002 V4多卡领域模型设计

docs/project/requirements/M002-v4-agent-callback-field-contract.md

@@ -4,9 +4,9 @@
 
 | 项目 | 内容 |
 | --- | --- |
-| 文档版本 | 1.2 |
+| 文档版本 | 1.4 |
 | 日期 | 2026-07-18 |
-| 状态 | 当前 V4 字段基线；后端已完成 CP1 入站解析与数据模型基线，完整 V4 多卡模型仍需后续 checkpoint |
+| 状态 | 当前 V4 字段基线；后端已完成 CP1 入站解析基线，CP2 订单任务与多卡领域模型设计及关键决策已落文档，完整 V4 多卡代码仍需后续 checkpoint |
 | 适用范围 | 0718 业务基线下，Agent → Adapter / MCP → 信息系统的业务回调字段 |
 | 不适用范围 | 数据库表设计、前端视觉细节、真实 PMS API、技术失败后台重试、旧 M002 V3 数据兼容 |
 
@@ -16,6 +16,8 @@
 
 本契约用于后续 M002 V4 主流程设计、后端领域建模、前端页面模型、Adapter / MCP Schema 对齐和 SuperAgent 联调。当前后端已按本文完成 V4 入站解析基线：能识别 V4 包、校验关键契约、保存 AI transition / 任务卡原始 payload，并把可映射的六类 event 先接入现有订单任务链路。
 
+V4 订单任务与多卡领域模型的 CP2 设计已经单独落到 `M002-v4-order-task-card-domain-model-cp2.md`。该文档只代表后续开发方案，不代表表结构、接口或前端页面已经实现。
+
 当前已确认开发阶段数据可以清空，因此 M002 V4 后续可以按新模型重建，不要求兼容旧任务数据、旧草稿、旧 OPERA 模拟、旧 `S000/S999`、旧 Fallback 或旧 `case_keys`。
 
 ## 2. 输入资料与优先级
@@ -583,6 +585,8 @@ true
 - 只显示邮件展示卡。
 - 不显示 Basic Information、房间信息或其他业务卡。
 - 不需要 `order_ref`、`target_order`、Account 或业务字段。
+- 采用来源通知模型：任务列表 / 工作台展示，点击进入纯通知详情页，不挂隐藏技术订单。
+- 不创建订单、不进入订单列表、不参与订单阻塞，也不支持编辑、复核、OPERA 或人工终止。
 - 用户点击“确认”后任务完成。
 - 不提供人工终止。
 - 不调用 PMS，不修改订单。
@@ -665,7 +669,10 @@ AI 回调包
 | Payment 附件 | 正常 Payment 必须 `attachment_ids.length > 0` |
 | `manual_review` validator | 按各对象条件 Schema 校验，必须能由可识别未解决字段解释 |
 | Update room_items | 不存在 / `null` / 数组三态 |
-| Fit Booking Code 临时定位 | 当前无 Confirmation Number 时可用 Booking Code 查本地订单投影 |
+| Fit Booking Code 临时定位 | 当前无 Confirmation Number 时可用 Booking Code 查本地订单投影；第一版不建立 ACTIVE 唯一约束，匹配多条进入人工复核 |
+| V4 前端资源路径 | 新开 `/api/reservation/order-tasks/**`，不扩展旧 `/api/reservation/tasks/**` 作为 V4 主入口 |
+| Basic Information 前置 | Basic Information 必须先确认；业务卡之间第一版不强制逐张顺序确认 |
+| Account 目录 | 第一版使用信息系统后端固定种子数据 |
 
 ## 23. 后续仍需技术对齐
 
@@ -682,6 +689,9 @@ AI 回调包
 - 0718 业务基线覆盖 M002 V3 的任务级草稿、READY、OPERA 模拟、Fallback、S99 和旧 Need Manual Review 页面语义。
 - 新数据只按 `S10` 表达纯通知。
 - 用户可见任务按订单任务 + 多卡建模。
+- 普通业务邮件的来源邮件展示卡只读展示，不需要用户确认。
+- S10 因为没有业务卡，邮件展示卡需要确认按钮，用于记录已读 / 已处理。
+- Basic Information 必须先确认；其它业务卡第一版可以独立确认，不强制逐张顺序确认。
 - 每张业务卡独立确认、确认后永久锁定。
 - 不保存草稿。
 - 当前无 PMS API，不生成 OPERA 模拟操作和 PMS 成功语义。
@@ -710,3 +720,21 @@ AI 回调包
 - 尚未取消 V3 草稿 / OPERA 模拟骨架；现有可映射 event 仍复用 M002 V3 任务状态和任务卡创建链路。
 - 尚未接入真实 PMS / OPERA / OHIP。
 - 尚未改造前端 V4 页面模型；前端第一版只能通过现有任务详情字段和原始 payload 观察 V4 入站结果。
+
+## 26. 后端 CP2 设计文档状态
+
+2026-07-18 已新增 `M002-v4-order-task-card-domain-model-cp2.md`，明确以下后续开发方向：
+
+- 普通业务包按 `source_message_id + order_ref` 形成 V4 订单任务。
+- 普通业务包固定展示来源邮件卡，但该卡只读、不阻塞、不替代邮件会话接口。
+- 每个 `order_ref` 创建一张 Basic Information 卡。
+- 每个 `message_events[]` event 创建一张业务卡，卡片按固定业务顺序展示。
+- S10 后续按来源通知模型实现，不再挂隐藏技术订单；只在任务列表 / 工作台展示，并进入纯通知详情页确认已读 / 已处理。
+- `FIT + BOOKING_CODE` 不建立 ACTIVE 唯一约束；业务绑定查到多条时进入人工复核。
+- V4 前端工作台统一列表草案为 `/api/reservation/workbench-items`，业务订单任务接口新开 `/api/reservation/order-tasks/**`，S10 来源通知详情草案为 `/api/reservation/source-notifications/{notificationId}`。
+- V4 新数据不再保存后端草稿；用户只提交最终确认或复核解阻。
+- 卡片确认后锁定，错误修正后续通过审计和未来纠错流程表达，不覆盖原确认。
+- 技术异常只进入 AI transition / 技术运行记录，不进入用户可处理卡。
+- 后续建议新增 V4 订单任务表、V4 任务卡表和 V4 来源通知表，继续复用 SourceMessage、AI batch、AI transition、Reservation Order 和业务审计表。
+
+CP2 尚未实现代码、接口、Flyway 或前端页面。后续开发应从 CP3 表结构和 Repository 开始。