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

docs/project/requirements/M002-order-task-workflow-v3.md

@@ -4,9 +4,9 @@
 
 | 项目 | 内容 |
 | --- | --- |
-| 文档版本 | 0.3 |
-| 日期 | 2026-07-13 |
-| 状态 | 0712 P0.1 增量确认版；已完成任务卡字段控件契约 V1 后端第一版 |
+| 文档版本 | 0.4 |
+| 日期 | 2026-07-18 |
+| 状态 | 0712 P0.1 增量确认版；已补充 M002 V4 CP1 入站现状和 CP2 多卡模型设计入口 |
 | 适用范围 | SourceMessage 之后的 SuperAgent 输出适配、任务路由、只读通知卡、人工复核同卡解阻、前后端协作边界 |
 | 主要读者 | 产品、后端、前端、测试、SuperAgent 对接方、后续协作 agent |
 
@@ -42,7 +42,7 @@ V3 以以下资料和决策为输入：
 
 - M002 V3 正式采用 0711 P0 基线，并从 2026-07-12 起采用 P0.1 Parent Group / Allotment 增量修订。
 - 旧数据 `S000/S999` 继续在任务列表可见；新数据迁移为 `S10/S99`。
-- `S10/S99` 继续复用隐藏技术订单 + 任务列表只读卡，不进入订单列表和订单执行队列。
+- M002 V3 / P0.1 阶段 `S10/S99` 继续复用隐藏技术订单 + 任务列表只读卡，不进入订单列表和订单执行队列；M002 V4 新模型已确认 S10 改为来源通知模型，不再挂隐藏技术订单。
 - 缺少 `source_message.source_message_id` 时，后端已按 `HTTP 400 + infrastructure_input_error + retryable=true` 的技术错误响应返回，不创建 SourceMessage、AI transition、订单、任务或通知卡。
 - 内部任务模型采用“方案 C”：完整保存 AI 三元组，系统处理分类和前端展示分类单独维护。
 - type-known manual review 使用同一张业务卡复核解阻，不生成第二张 normal task。
@@ -152,6 +152,8 @@ V3 接收端按根结构分流：
 - 不允许保存草稿、最终确认、复核转换、普通切换订单、执行 OPERA、重试 OPERA。
 - 任务详情展示来源邮件、邮件会话、附件、SuperAgent 原始返回、`route_code` 和入口说明。
 
+以上是 M002 V3 / P0.1 当前实现口径。M002 V4 新模型落地时，S10 改为来源通知模型：任务列表 / 工作台展示，点击进入纯通知详情页，只显示邮件展示卡和确认按钮；不创建订单、不进订单列表、不参与订单阻塞，也不支持编辑、复核、OPERA 或人工终止。
+
 ### 6.3 旧 S000 / S999 兼容
 
 旧数据 `S000/S999` 已经在系统中以只读特殊任务展示。V3 不删除旧数据，也不要求历史回写。
@@ -248,7 +250,7 @@ V3 内部模型采用方案 C，避免把 SuperAgent 的任务三元组直接等
 - 有 `group_code`、`confirmation_number` 等可定位字段时，优先挂靠或创建相应订单。
 - 同一个 `hotel_id + GROUP_CODE` 只能有一个 `ACTIVE` 订单。
 - 同一个 `hotel_id + CONFIRMATION_NUMBER` 只能有一个 `ACTIVE` 订单。
-- `S10/S99` 使用隐藏技术订单，不进入订单列表。
+- M002 V3 / P0.1 当前实现中，`S10/S99` 使用隐藏技术订单，不进入订单列表；M002 V4 S10 目标模型改为独立来源通知，不再挂订单。
 
 P0 新增明确：复核场景下需要支持用户确认订单归属。它不是普通任务切换订单：
 
@@ -467,8 +469,17 @@ V3 P0.1 不做以下事项：
 - MCP submit V2 兼容路径已在 `tools/list` 暴露 `ai_task_results[]` item schema，并在 adapter 层校验必填字段、字段类型、允许 `result_type` 和未知字段。
 - MCP submit 对缺失 `source_message.source_message_id` 或整个 `source_message` 保留业务入站层 `MISSING_SOURCE_MESSAGE_ID` 错误语义；对 V3 event 业务契约问题不提前整批拒绝，由业务入站层保存 `adapter_contract_error` transition。
 
+M002 V4 CP2 设计文档已落地：
+
+- 文档路径：`docs/project/requirements/M002-v4-order-task-card-domain-model-cp2.md`。
+- 设计内容：SourceMessage 邮件展示卡、S10 来源通知、`source_message_id + order_ref` 订单任务、Basic Information 独立卡、每个 V4 event 的业务卡、卡片确认 / 复核 / 锁定、同订单阻塞、表结构草案和后续接口草案。
+- 已确认：V4 工作台统一列表新开 `/api/reservation/workbench-items`，业务订单任务新开 `/api/reservation/order-tasks/**`，S10 来源通知使用 `/api/reservation/source-notifications/**`；S10 采用来源通知模型；`FIT + BOOKING_CODE` 不建 ACTIVE 唯一约束，匹配多条进人工复核；Basic Information 必须先确认，其它业务卡第一版不强制逐张确认；Account / Market / Source 目录第一版使用后端固定种子数据。
+- 当前状态：只完成文档设计，未新增表、Entity、Repository、接口或前端页面。
+
 仍需后续 checkpoint 实现：
 
-- V4 订单任务 + 多卡领域模型重建，尤其是 Basic Information 订单级独立卡、邮件展示卡和各业务卡独立确认 / 锁定。
+- V4 表结构和 Repository 落地，包括 V4 订单任务表、V4 任务卡表和 V4 来源通知表。
+- V4 入站写入新模型，真正创建 SourceMessage 展示卡、Basic Information 卡和业务卡。
+- V4 查询接口、卡片确认 / 复核 / 锁定、同订单阻塞和业务审计。
 - V4 前端页面模型、任务详情字段矩阵和目录校验完全切换。
 - 真实 OPERA / OHIP、普通任务任意切换订单、字段矩阵从当前扁平结构整体迁移到 0711 P0 新结构、历史旧 Parent Cancel Booking payload 批量迁移。