docs: 收口 V4 任务卡展示与确认口径

CONTEXT.md

@@ -44,6 +44,12 @@ TH Hotel Simple 是一个前后端分离的酒店业务协同项目。
 - Email / Message Conversation：邮件和邮件会话，用于历史邮件查询、正文读取和会话级任务查询。
 - Reservation Case / Task：预订相关订单、任务卡、人工复核和任务结果。
 - Reservation Order Task / Card：M002 V4 后续采用的订单任务与多卡模型；一封来源邮件可按 `order_ref` 形成多个订单任务，每个订单任务下包含来源邮件展示卡、Basic Information 卡和若干业务卡。
+- Room Information Card：V4 订单任务中由 New Booking、Update Booking 或 Cancel Booking 触发的房型信息卡；它展示订单房型、日期、早餐、晚数和 Group 状态等可确认业务信息。
+- Review Required Card：V4 订单任务中需要人工复核的原业务卡状态；用户仍在原卡片内检查和修正业务字段，完成后确认卡片，不另建独立复核任务卡。
+- Reservation Account：预订业务中的公司、旅行社或客户账户，不是系统登录账号；它用于订单级 Basic Information，并影响可用 Rate Code 范围。
+- Rate Code Applicability：Rate Code 的业务适用范围；当前已确认先按 Reservation Account + booking type（GROUP / FIT）确定候选，不把全酒店 Rate Code 当成所有 Account 通用。
+- Rooming List Task Card：V4 订单任务中的 Rooming List 事项确认卡，表示当前来源消息包含需要人工处理的房表事项；它不同于独立的 Rooming List Excel 生成工具。
+- Payment Attachment Preview：Payment 卡中的付款凭证附件展示能力；业务事实仍是 `attachment_ids[]` 关联，图片可缩略图和大图预览，非图片统一文件列表和下载，附件外链必须走 SourceMessage 原文权限链路。
 - Source Message Notification：M002 V4 的 S10 纯通知模型；只表示来源邮件需要被查看和确认已处理，不形成订单任务或业务卡。
 - Identity / Access / Hotel / Menu：登录、用户、角色、权限、酒店授权和动态菜单底座。
 - Debug EML：受控调试入口，用于上传 EML 并触发 SuperAgent 调试链路。

PROJECT_STATE.md

@@ -4,16 +4,16 @@
 | --- | --- |
 | 最近更新 | 2026-07-20 |
 | 当前分支 | `feature/huangting` |
-| 当前阶段 | M002 V4 入站、多卡模型、持久化基线、入站写入、查询接口、卡片确认、复核解阻、目录校验、订单详情 V4 总览、DB 目录、Lookup API、前端 lookup 接入、目录管理后台 CP1 前后端、订单列表 V4 继续处理入口 / open count 收口、V4 业务审计查询、停止旧任务双写和 Debug EML V4 profile 对齐 |
-| 当前重点 | M002 V4 已停止普通业务入站双写旧 `workflow_reservation_task`，V4 后新业务主线只写 V4 order task / cards / source notification；Debug EML V4 smoke 默认复用实时 AgentBus V4 Open API subject，避免误走历史 Debug V2/V3 profile。开发阶段不维护 V2/V3 旧任务兼容，测试数据可重建，生产迁移策略后续上线前单独设计。`GET /api/reservation/orders` 可返回 V4 下一步订单任务、卡片、动作类型、动作状态、V4 open 数和统一展示字段 `open_work_item_count`；旧 `open_task_count` / `next_processable_task_id` 仅作历史诊断兼容。后续可继续做测试机 V4 smoke 复测、真实 PMS / OPERA / OHIP 同步或 SuperAgent 目录供给方案。 |
+| 当前阶段 | M002 V4 入站、多卡模型、持久化基线、入站写入、查询接口、卡片确认、复核解阻、目录校验、订单详情 V4 总览、DB 目录、Lookup API、前端 lookup 接入、目录管理后台 CP1 前后端、订单列表 V4 继续处理入口 / open count 收口、V4 业务审计查询、停止旧任务双写、Debug EML V4 profile 对齐、Account + booking type 过滤 Rate Code 文档口径、Payment 附件预览文档口径、Rooming List 事项确认卡文档口径、Room Information 展示模型文档口径，以及 V4 复核态卡片交互和字段白名单文档口径 |
+| 当前重点 | M002 V4 已停止普通业务入站双写旧 `workflow_reservation_task`，V4 后新业务主线只写 V4 order task / cards / source notification；Debug EML V4 smoke 默认复用实时 AgentBus V4 Open API subject，避免误走历史 Debug V2/V3 profile。开发阶段不维护 V2/V3 旧任务兼容，测试数据可重建，生产迁移策略后续上线前单独设计。`GET /api/reservation/orders` 可返回 V4 下一步订单任务、卡片、动作类型、动作状态、V4 open 数和统一展示字段 `open_work_item_count`；旧 `open_task_count` / `next_processable_task_id` 仅作历史诊断兼容。已确认 Rate Code 下一阶段按 Reservation Account + `booking_type`（GROUP / FIT）过滤和校验，不按全酒店 Rate Code 全量展示；已确认 Payment 卡展示付款凭证附件时，`attachment_ids[]` 第一版只读，前端只展示并确认卡片，不增删或替换附件集合，图片在卡片内显示缩略图并点击大图预览，非图片统一文件列表 + 下载，附件外链仍走 SourceMessage 原文权限链路；已确认 Rooming List 任务卡第一版只做事项确认，不做名单解析、附件预览、Excel 生成或 PMS 导入，用户点击“确认卡片”表示已人工处理该 Rooming List 事项；已确认 Room Information 卡下一阶段按 New / Update / Cancel 业务展示模型展示，后端派生 Nights、Breakfast 和最终值，Update 展示当前值到修改后值的差异，Cancel 展示本地订单投影只读，Group Booking Status 使用 `TEN-Tentative` / `DEF-Definite` / `INQ-Inquiry`，Rooming List 确认时 Group 自动变 `DEF`；已确认 `REVIEW_REQUIRED` 仍是原业务卡复核态，页面按钮统一叫“确认卡片”，复核态允许编辑当前卡 `fields[]` 白名单内业务字段，问题字段红字提示。后续可继续做测试机 V4 smoke 复测、Room Information 展示模型、Rooming List 前端轻量卡展示、Payment 附件预览、Account 范围 Rate Code lookup、真实 PMS / OPERA / OHIP 同步或 SuperAgent 目录供给方案。 |
 
 ## 1. 当前 Checkpoint
 
-- 名称：`M002-V4-debug-eml-route-v4-model-alignment`
-- 状态：Done，已定位 Debug EML 测试机旧任务残留主要来自默认 Open API subject 指向历史 Debug V2/V3 profile；后端已把 Debug EML 默认 subject 对齐实时 AgentBus V4 subject，并补充 Debug provider 的 V4 回调回归测试。
-- 目标：Debug EML V4 smoke 与正式 V4 SuperAgent 入站保持一致；Debug 服务自身不直接写业务模型，SuperAgent 后续通过正式回调 / MCP 写入时只创建 V4 order task / cards，不再创建旧 `workflow_reservation_task`。
-- 边界：不做生产数据迁移，不推进真实 PMS / OPERA / OHIP，不推进 M011 CP4，不删除 SourceMessage、V4 order task / cards、V4 source notification、目录、用户权限、酒店配置或 SuperAgent dispatch run。
-- 联调备注：历史 `th-hotel-debug-eml-upload` profile 如仍需排查旧 V2/V3 页面问题，必须显式配置 `SUPERAGENT_{ENV}_DEBUG_EML_EXTERNAL_SUBJECT_ID`，不能作为 M002 V4 smoke 默认入口。本次测试机 Debug EML 残留旧 task 可按开发 / 测试旧任务清理 SQL 传入旧 task ID 后限定清理。
+- 名称：`M002-V4-card-requirements-doc-tightening`
+- 状态：Docs Ready，已确认 V4 任务卡排序、复核态交互、可编辑字段白名单、Room Information 展示模型、Payment 附件预览、Rooming List 事项确认和 Rate Code 过滤口径，后续待后端和前端实现。
+- 目标：把 V4 任务详情页从通用 JSON 字段展示收口为可验收的业务卡交互：Basic Information 在顶部、业务卡居中、SourceMessage Display 在底部；`REVIEW_REQUIRED` 仍在原业务卡内编辑和确认；Room Information、Trace、Rooming List、Payment 分别按稳定业务字段渲染。
+- 边界：本 checkpoint 只落文档，不改业务代码；SuperAgent 不新增 Nights、Breakfast、Group Booking Status、Adult、Block ID 或 Confirmation Number 输出；Adult 第一版不在 Room Information 卡显示；Block ID / Confirmation Number 继续等待 PMS 或本地投影来源；`target_order.locator_value` 不直接编辑，但 New Booking 的最终订单投影字段 `group_block_name` / `fit_name` 允许在业务卡中编辑；Payment 第一版 `attachment_ids[]` 只读展示并确认，不支持前端增删或替换附件集合。
+- 联调备注：后端后续应在 V4 任务详情中补 Room Information 展示模型、复核态 `fields[]` 白名单、Payment 附件安全摘要和 Account 范围 Rate Code lookup / 校验；前端按后端 `fields[]` 渲染可编辑控件，复核态按钮文案统一为“确认卡片”，但内部调用 `review-resolution`。
 
 ## 2. 当前优先级
 
@@ -36,8 +36,8 @@
 - 后续每完成一个 Feature 或 Checkpoint，需要更新本文件，避免项目状态继续沉淀在聊天记录里。
 - M010 Rooming List Excel 生成后端 CP1 和前端 V1 已实现：前端 `/reservation/rooming-lists/new` 上传来源名单和手工字段，后端同步生成 `.xlsx` 直接下载，第一版不落库、不上传 OSS。
 - M011 Booking Excel 附件预处理 CP1/CP2/CP3 已实现：后端可排除人员名单类 Excel，按最近 6 个月候选窗口选择实际存在的最新 3 个业务月，抽取 Booking Update / 附加费表高亮行业务 JSON；Debug EML 和 AgentBus dispatch 在各自 include 开关与总开关同时启用时，会在调用 SuperAgent 前追加 `attachment_extractions[]`。测试机 AgentBus 增强已开启；生产链路仍默认关闭，生产开启需单独确认。
-- M002 V4 CP1 当前已完成入站解析和现有任务链路过渡适配；M002 V4 CP2 已完成订单任务与多卡领域模型设计；M002 V4 CP3 已完成 V4 订单任务、多卡和 S10/S99 来源通知表结构与 Repository 基线；M002 V4 CP4 已完成入站写入新模型；M002 V4 CP5 已完成前端查询接口并补齐订单详情 `v4_order_tasks[]` 时间线；M002 V4 CP6 已完成普通卡片确认和 S10/S99 来源通知 ack；M002 V4 CP7 已完成 `REVIEW_REQUIRED` 卡复核解阻和复核场景订单归属确认；M002 V4 CP8 已完成目录校验、V4 卡片 `fields[]` 字段白名单、确认写入白名单收口和嵌套业务字段目录校验；M002 V4 CP11 已完成数据库目录、初始化种子、启动补种子、Account / Room Type / Rate Code lookup API，并把 V4 入站、确认、复核目录校验切换到当前酒店数据库目录；M002 V4 CP12 已完成前端 lookup 接入第一版和 V4 订单任务时间线消费；M002 V4 CP13 目录管理后台 CP1 已完成前后端列表、新增、启用 / 停用闭环；M002 V4 CP14 已完成订单列表 V4 继续处理入口字段和前端入口消费，`GET /api/reservation/orders` 返回 V4 下一步订单任务、卡片、动作类型、动作状态、V4 open 数和统一展示计数 `open_work_item_count`，前端按 V4 优先跳转，并按 `open_work_item_count` 展示待处理数量；V4 业务审计查询已补齐订单任务审计和来源通知 ack 审计两个只读接口；订单详情已补齐并完成前端接入 V4 `order_overview`、`next_v4_action`、`related_source_messages[]` 和 `v4_order_tasks[].cards[]`；V4 普通业务入站已停止双写旧 `workflow_reservation_task`。真实 PMS 同步和 SuperAgent 目录机器接口仍未完成。
-- M002 V4 CP2 已确认：V4 工作台统一列表草案为 `/api/reservation/workbench-items`，业务订单任务接口新开 `/api/reservation/order-tasks/**`，S10/S99 来源通知详情草案为 `/api/reservation/source-notifications/{notificationId}`；S10/S99 使用来源通知模型，不再挂隐藏技术订单；`FIT + BOOKING_CODE` 不建 ACTIVE 唯一约束，匹配多条进人工复核；Basic Information 必须先确认；Account / Market / Source 当前通过数据库目录读取和派生；旧 V2/V3 任务详情和草稿确认接口后续可逐步废弃。
+- M002 V4 CP1 当前已完成入站解析和现有任务链路过渡适配；M002 V4 CP2 已完成订单任务与多卡领域模型设计；M002 V4 CP3 已完成 V4 订单任务、多卡和 S10/S99 来源通知表结构与 Repository 基线；M002 V4 CP4 已完成入站写入新模型；M002 V4 CP5 已完成前端查询接口并补齐订单详情 `v4_order_tasks[]` 时间线；M002 V4 CP6 已完成普通卡片确认和 S10/S99 来源通知 ack；M002 V4 CP7 已完成 `REVIEW_REQUIRED` 卡复核解阻和复核场景订单归属确认；M002 V4 CP8 已完成目录校验、V4 卡片 `fields[]` 字段白名单、确认写入白名单收口和嵌套业务字段目录校验；M002 V4 CP11 已完成数据库目录、初始化种子、启动补种子、Account / Room Type / Rate Code lookup API，并把 V4 入站、确认、复核目录校验切换到当前酒店数据库目录；M002 V4 CP12 已完成前端 lookup 接入第一版和 V4 订单任务时间线消费；M002 V4 CP13 目录管理后台 CP1 已完成前后端列表、新增、启用 / 停用闭环；M002 V4 CP14 已完成订单列表 V4 继续处理入口字段和前端入口消费，`GET /api/reservation/orders` 返回 V4 下一步订单任务、卡片、动作类型、动作状态、V4 open 数和统一展示计数 `open_work_item_count`，前端按 V4 优先跳转，并按 `open_work_item_count` 展示待处理数量；V4 业务审计查询已补齐订单任务审计和来源通知 ack 审计两个只读接口；订单详情已补齐并完成前端接入 V4 `order_overview`、`next_v4_action`、`related_source_messages[]` 和 `v4_order_tasks[].cards[]`；V4 普通业务入站已停止双写旧 `workflow_reservation_task`。Account + booking type 过滤 Rate Code、Payment 附件预览、复核态卡片字段白名单均已作为下一阶段文档口径确认，但后端 lookup / 校验、Payment 附件安全摘要、复核态整卡业务字段编辑和前端联动尚未实现；真实 PMS 同步和 SuperAgent 目录机器接口仍未完成。
+- M002 V4 CP2 已确认：V4 工作台统一列表草案为 `/api/reservation/workbench-items`，业务订单任务接口新开 `/api/reservation/order-tasks/**`，S10/S99 来源通知详情草案为 `/api/reservation/source-notifications/{notificationId}`；S10/S99 使用来源通知模型，不再挂隐藏技术订单；`FIT + BOOKING_CODE` 不建 ACTIVE 唯一约束，匹配多条进人工复核；Basic Information 必须先确认；Rooming List 卡第一版只做事项确认；Account / Market / Source 当前通过数据库目录读取和派生；旧 V2/V3 任务详情和草稿确认接口后续可逐步废弃。
 
 ## 5. Next Steps
 

docs/project/README.md

@@ -46,8 +46,8 @@
 | `requirements/M002-order-task-workflow-v3.md` | 当前有效 | M002 订单任务主流程 V3，基于 2026-07-11 P0 冻结基线和 2026-07-12 P0.1 Parent Group 修订，记录 S10/S99、40 路由、方案 C、type-known manual review 同卡解阻和 fail-closed 边界。 |
 | `requirements/M002-task-field-control-contract-v1.md` | 当前有效 | M002 任务卡字段控件契约 V1，记录任务详情 `fields[]` 控件元数据、人工复核控件复用和前后端开发边界。 |
 | `requirements/M002-v4-agent-callback-field-contract.md` | 当前有效 | M002 V4 Agent 回调字段契约，基于 2026-07-18 业务基线和最新答复，冻结 `source_message`、`order_contexts`、`message_events`、订单级 Basic Information、六类 Event、S10/S99 和校验口径；后端已完成 V4 入站解析、持久化、查询、确认、复核和当前酒店数据库目录校验。 |
-| `requirements/M002-v4-order-task-card-domain-model-cp2.md` | 当前有效 | M002 V4 CP2 订单任务与多卡领域模型设计，并记录 CP3-CP8 表结构、入站写入、查询、确认、复核和目录校验已落地状态；CP11 已完成 DB 目录与 lookup API，CP12 已完成前端 lookup 接入，CP13 已完成目录管理后台 CP1，CP14 已完成订单列表 V4 继续处理入口，CP15 已完成 V4 业务审计查询，CP15.1 已完成订单详情 V4 总览后端补齐，当前已停止 V4 普通业务双写旧 `workflow_reservation_task`；开发阶段不维护 V2/V3 旧任务兼容，测试数据可重建，生产迁移策略后置。 |
-| `requirements/M002-v4-real-catalog-lookup-api-design.md` | 当前有效 | M002 V4 真实目录与 Lookup API 设计及 CP11 / CP13 CP1 实现记录，记录 Account、Market、Source、Room Type、Rate Code 从固定种子导入数据库、前端 lookup API、目录管理后端接口、权限、缓存后置、PMS / OPERA / OHIP 同步后置和失败兜底。 |
+| `requirements/M002-v4-order-task-card-domain-model-cp2.md` | 当前有效 | M002 V4 CP2 订单任务与多卡领域模型设计，并记录 CP3-CP8 表结构、入站写入、查询、确认、复核和目录校验已落地状态；CP11 已完成 DB 目录与 lookup API，CP12 已完成前端 lookup 接入，CP13 已完成目录管理后台 CP1，CP14 已完成订单列表 V4 继续处理入口，CP15 已完成 V4 业务审计查询，CP15.1 已完成订单详情 V4 总览后端补齐，当前已停止 V4 普通业务双写旧 `workflow_reservation_task`；已补 Account 范围 Rate Code、Payment 附件预览、Rooming List 事项确认卡、Room Information 展示模型、V4 复核态卡片交互和可编辑字段白名单文档口径；开发阶段不维护 V2/V3 旧任务兼容，测试数据可重建，生产迁移策略后置。 |
+| `requirements/M002-v4-real-catalog-lookup-api-design.md` | 当前有效 | M002 V4 真实目录与 Lookup API 设计及 CP11 / CP13 CP1 实现记录，记录 Account、Market、Source、Room Type、Rate Code 从固定种子导入数据库、前端 lookup API、目录管理后端接口、权限、缓存后置、PMS / OPERA / OHIP 同步后置和失败兜底；已新增 Account + booking type 过滤 Rate Code 的下一阶段契约，房型 / 日期 / 价格规则后置。 |
 | `requirements/M002-v4-test-machine-smoke-checklist.md` | 当前有效 | M002 V4 测试机冒烟清单，覆盖登录、酒店权限、V4 工作台、订单任务详情、lookup、确认、复核解阻、S10/S99 ack、订单详情 V4 时间线和目录管理 CP1 排查点。 |
 | `requirements/M002-superagent-task-result-api-contract.md` | 阶段记录 | M002 SuperAgent 任务结果入站接口契约阶段记录；对外总契约以 `integrations/superagent-api-contract.md` 为准。 |
 | `requirements/M002-ai-query-minimal-fields.md` | 阶段记录 | M002 SuperAgent 查询上下文接口 1、2 最小字段落地记录；对外总契约以 `integrations/superagent-api-contract.md` 为准。 |
@@ -100,6 +100,6 @@
 - 接口暴露、权限、酒店隔离和审计边界以 `security-access-control-boundary.md` 为总检查清单；具体 SuperAgent / MCP / AgentBus 请求响应契约仍以 `integrations/` 下对应文档为准。
 - AI-NSES 的通用标准以 `../import/reusable/ai-native-software-engineering-standard.md` 为复用来源；本项目采用方式以 `ai-native-adoption.md` 为准。
 - M002 V1 只作为历史参考；V2 记录当前阶段实现；后续 M002 新开发以 `requirements/M002-order-task-workflow-v3.md` 为开发基线。
-- 2026-07-18 导入的业务基线已形成 `requirements/M002-v4-agent-callback-field-contract.md` 字段契约；M002 V4 入站解析 CP1 已落地，V4 订单任务 + 多卡领域模型设计和关键业务决策见 `requirements/M002-v4-order-task-card-domain-model-cp2.md`；M002 V4 CP3 已落地 V4 订单任务、任务卡、来源通知表结构和 Repository 基线，CP4 已落地普通 V4 业务包和 S10/S99 来源通知入站写入新模型，CP5 已落地工作台、订单任务和来源通知查询接口，CP6/CP7 已落地卡片确认、S10/S99 ack 和复核解阻，CP11 已落地 DB 目录与 lookup API，CP12 已落地前端 lookup 接入，CP13 已落地目录管理后台 CP1，CP14 已落地订单列表 V4 继续处理入口，CP15 已落地 V4 业务审计查询，CP15.1 已落地订单详情 V4 总览后端补齐；后续仍需前端订单详情 V4 化、测试机联调和真实 PMS / OPERA / OHIP 同步。
-- 前端展示 / 编辑字段以 2026-07-11 P0 冻结基线中的前端字段表、0712 字段控件说明和 `requirements/M002-task-field-control-contract-v1.md` 为白名单和控件契约基线；后端完整校验和 OPERA 映射仍以任务卡完整矩阵、0711 runtime 契约和后端规则为准。
+- 2026-07-18 导入的业务基线已形成 `requirements/M002-v4-agent-callback-field-contract.md` 字段契约；M002 V4 入站解析 CP1 已落地，V4 订单任务 + 多卡领域模型设计和关键业务决策见 `requirements/M002-v4-order-task-card-domain-model-cp2.md`；M002 V4 CP3 已落地 V4 订单任务、任务卡、来源通知表结构和 Repository 基线，CP4 已落地普通 V4 业务包和 S10/S99 来源通知入站写入新模型，CP5 已落地工作台、订单任务和来源通知查询接口，CP6/CP7 已落地卡片确认、S10/S99 ack 和复核解阻，CP11 已落地 DB 目录与 lookup API，CP12 已落地前端 lookup 接入，CP13 已落地目录管理后台 CP1，CP14 已落地订单列表 V4 继续处理入口，CP15 已落地 V4 业务审计查询，CP15.1 已落地订单详情 V4 总览后端补齐且前端已接入；已确认 Rooming List 卡第一版只做事项确认，Room Information 卡下一阶段按 New / Update / Cancel 展示模型实现，`REVIEW_REQUIRED` 保持原业务卡内编辑并统一显示“确认卡片”；后续仍需 Room Information 展示模型、Payment 附件预览、Account 范围 Rate Code lookup / 校验、复核态字段白名单实现、测试机联调和真实 PMS / OPERA / OHIP 同步。
+- V3 / 旧任务前端展示和编辑字段仍以 2026-07-11 P0 冻结基线中的前端字段表、0712 字段控件说明和 `requirements/M002-task-field-control-contract-v1.md` 为白名单和控件契约基线；V4 订单任务前端展示和编辑字段以 `requirements/M002-v4-order-task-card-domain-model-cp2.md`、后端返回的 `fields[]` 和 V4 前后端协作文档为准。
 - 时间点语义以 `backend-time-design.md` 为准；数据库时间点按 UTC 理解，API 返回带 `Z` 的 UTC 时间，页面再按酒店或用户时区展示。

docs/project/frontend-backend/README.md

@@ -45,7 +45,7 @@
 | SuperAgent 查询上下文接口 1、2 | `docs/project/requirements/M002-ai-query-minimal-fields.md` | 阶段记录，用于理解接口 1、2 的最小字段实现；如与总契约冲突，以总契约为准。 |
 | 订单任务主流程 V3 | `docs/project/requirements/M002-order-task-workflow-v3.md` | 当前开发基线，基于 0711 P0 冻结基线和 0712 P0.1 Parent Group 修订，覆盖 S10/S99、40 路由、方案 C、type-known manual review 同卡解阻和 fail-closed。 |
 | 任务卡字段控件契约 V1 | `docs/project/requirements/M002-task-field-control-contract-v1.md` | 后端已返回 `fields[]` 控件元数据，规定人工复核控件复用和前后端边界；前端待接入。 |
-| 订单任务多卡模型 V4 | `docs/project/requirements/M002-v4-order-task-card-domain-model-cp2.md` | 当前 V4 主入口；后端已开放工作台统一列表、V4 订单任务列表 / 详情、卡片确认、复核解阻、S10/S99 来源通知详情和 ack；前端已完成 V4 页面第一版、目录 lookup 接入、订单详情 V4 时间线消费和系统设置目录管理 CP1。 |
+| 订单任务多卡模型 V4 | `docs/project/requirements/M002-v4-order-task-card-domain-model-cp2.md` | 当前 V4 主入口；后端已开放工作台统一列表、V4 订单任务列表 / 详情、卡片确认、复核解阻、S10/S99 来源通知详情和 ack；前端已完成 V4 页面第一版、目录 lookup 接入、订单详情 V4 时间线消费和系统设置目录管理 CP1；Room Information 展示模型、Payment 附件预览和 Rooming List 轻量卡展示仍待后续实现。 |
 | Manual Invoice 手工开票生成 | `docs/project/requirements/M009-manual-invoice-generation-v1.md` | 当前有效；后端 CP2 已支持无订单 / 无任务手工填写字段、填 Excel 模板、转 PDF、OSS 输出和生成记录。 |
 | Rooming List Excel 生成 | `docs/project/requirements/M010-rooming-list-excel-generation-v1.md` | 当前有效；后端 CP1 已支持前端上传来源名单并填写目标字段，同步生成 `.xlsx` 直接下载；前端 V1 已新增 `/reservation/rooming-lists/new`，按 Blob 下载处理，不落库、不上传 OSS。 |
 | Booking Excel 附件预处理 | `docs/project/requirements/M011-booking-excel-pre-superagent-enrichment-v1.md` | 当前有效；Debug EML 和 AgentBus dispatch 已支持调 SuperAgent 前排除人员名单类 Excel、抽取 Booking / 附加费类 Excel 高亮行并生成 `attachment_extractions[]`；测试机 AgentBus 增强已开启，生产默认关闭；CP4 暂不推进。 |
@@ -67,6 +67,7 @@
 - Rooming List Excel 后端 CP1 和前端 V1 已按 M010 落地：接口为 `POST /api/reservation/rooming-lists/generations`，前端页面为 `/reservation/rooming-lists/new`，上传来源名单、填写每房人数和目标列字段，后端同步返回 `.xlsx` 下载；该能力不依赖订单或任务，第一版不落库、不上传 OSS，权限码为 `RESERVATION_ROOMING_LIST_GENERATE`。
 - Booking Excel 附件预处理已按 M011 落地 CP1/CP2/CP3：Debug EML 和 AgentBus dispatch 调用 SuperAgent 前由后端解析 Excel 附件，排除人员名单类文件，只把 Booking Update / 附加费表的高亮行业务摘要追加为 `attachment_extractions[]`；第一版不新增前端普通业务入口，测试机 AgentBus 增强已开启，生产默认关闭，CP4 暂不推进。
 - Reservation V4 目录管理后台 CP1 已前后端接入：系统设置下新增 `/system/reservation-catalogs`，需要登录用户具备 `RESERVATION_CATALOG_MANAGE`；前端可维护 Account、Room Type、Rate Code 的列表、新增、启用 / 停用，并明确提示停用目录不再进入普通 V4 任务卡 lookup。
+- V4 任务卡复核态已确认：`REVIEW_REQUIRED` 仍在原业务卡内编辑和确认，页面主按钮文案统一为“确认卡片”；前端必须按 `card_status` 调用普通确认或复核解阻接口，且只提交后端 `fields[]` 白名单内业务字段。
 
 ## 6. 前端开发注意事项
 

docs/project/frontend-backend/backend-to-frontend-notes.md

@@ -56,13 +56,13 @@
 | `GET /api/reservation/tasks` | 查询任务列表 / 工作台 | 必须带 Bearer token，需要 `RESERVATION_TASK_READ`；未传 `order_id` 时按来源消息接收时间倒序，传 `order_id` 时按同订单队列顺序正序；用 `can_process` 和 `readonly_reason_code` 控制入口按钮；列表不返回 AI 原始 payload、邮件正文或附件 URL；已返回来源邮件会话摘要字段，并支持 `order_status` 按任务所属订单状态筛选；旧 S000/S999 和 V3 S10/S99 以 `task_type=SOURCE_MESSAGE_ONLY` 只读任务返回，列表已透出 `result_type`、`ai_task_type`、`route_code`、`system_process_category`。V4 S10/S99 不再进入该旧任务表，应从 V4 工作台来源通知接口展示。 |
 | `GET /api/reservation/workbench-items` | 查询 V4 工作台统一列表 | 必须带 Bearer token，需要 `RESERVATION_TASK_READ`；返回 V4 业务订单任务和 S10/S99 来源通知混排摘要；支持 `hotel_id`、`item_type`、`keyword`、`page_num`、`page_size`；默认按 `source_received_at` 倒序，同一来源时间下按 `updated_at`、`created_at`、数字 `target_id` 倒序；列表不返回邮件正文、附件 URL、`ai_payload_json` 或来源通知原始 payload。 |
 | `GET /api/reservation/order-tasks` | 查询 V4 业务订单任务列表 | 必须带 Bearer token，需要 `RESERVATION_TASK_READ`；只返回 V4 业务订单任务，不包含 S10/S99 来源通知；支持 `hotel_id`、`order_id`、`order_task_status`、`card_status`、`keyword`、`page_num`、`page_size`；`order_task_status` 非 `OPEN` / `COMPLETED` 返回 400，`card_status` 非 V4 卡状态返回 400；`card_status` 只筛业务 / 可处理卡，固定来源邮件展示卡不参与筛选。 |
-| `GET /api/reservation/order-tasks/{orderTaskId}` | 查询 V4 订单任务详情 | 必须带 Bearer token，需要 `RESERVATION_TASK_READ`，后端按订单任务实际酒店校验访问权；返回 `order_task`、`source_message_summary`、`source_message_card`、`basic_information_card`、`business_cards[]`、`card_counts`、`adapter_contract_errors[]` 和 `availability`；来源摘要按酒店过滤，邮件正文和附件仍走 SourceMessage 会话接口。CP8 起每张 V4 任务卡返回 `fields[]`，前端应以该字段白名单渲染可编辑控件。 |
+| `GET /api/reservation/order-tasks/{orderTaskId}` | 查询 V4 订单任务详情 | 必须带 Bearer token，需要 `RESERVATION_TASK_READ`，后端按订单任务实际酒店校验访问权；返回 `order_task`、`source_message_summary`、`source_message_card`、`basic_information_card`、`business_cards[]`、`card_counts`、`adapter_contract_errors[]` 和 `availability`；来源摘要按酒店过滤，邮件正文和附件仍走 SourceMessage 会话接口。V4 任务详情页展示顺序固定为 Basic Information、业务卡、SourceMessage Display；来源邮件卡位于页面最下方，正文限定为当前触发该 order task 的 SourceMessage 正文，前端用 `source_message_summary.source_message_id` 调用 `GET /api/source-messages/{sourceMessageId}/conversation` 后定位当前邮件。Payment 卡下一阶段可返回 `payment_attachments[]` 安全摘要用于展示凭证附件，但本接口不得返回附件 URL；图片缩略图 / 大图和非图片下载 URL 仍通过 SourceMessage 会话权限链路取得。CP8 起每张 V4 任务卡返回 `fields[]`，前端应以该字段白名单渲染可编辑控件。 |
 | `GET /api/reservation/order-tasks/{orderTaskId}/audits` | 查询 V4 订单任务审计流水 | 必须带 Bearer token，需要 `RESERVATION_AUDIT_READ`，后端按订单任务实际酒店校验访问权；返回 `order_task_id` 和 `items[]`。`items[]` 用于展示 V4 卡片确认、复核解阻和订单归属确认轨迹，只包含脱敏后的审计摘要，不包含邮件正文、HTML、附件 URL、AI 原始 payload、token 或 secret。 |
 | `GET /api/reservation/source-notifications/{notificationId}` | 查询 V4 S10/S99 来源通知详情 | 必须带 Bearer token，需要 `RESERVATION_TASK_READ`，后端按来源通知实际酒店校验访问权；只返回通知摘要、来源邮件通知卡、会话摘要和 `availability`；不返回订单任务、业务卡、邮件正文、附件 URL 或原始 AI payload。 |
 | `GET /api/reservation/source-notifications/{notificationId}/audits` | 查询 V4 S10/S99 来源通知审计流水 | 必须带 Bearer token，需要 `RESERVATION_AUDIT_READ`，后端按来源通知实际酒店校验访问权；返回 `notification_id` 和 `items[]`。`items[]` 第一版用于展示来源通知 ack 记录，只包含脱敏后的审计摘要。 |
 | `GET /api/reservation/lookups/accounts` | 查询 V4 Account 目录 | 必须带 Bearer token，需要 `RESERVATION_TASK_READ`，支持 `hotel_id`、`keyword`、`page_num`、`page_size`；返回统一 wrapper：`hotel_id`、`catalog_type=ACCOUNT`、`catalog_source`、`catalog_version`、`stale`、`items[]`、`page`、`warnings[]`。`keyword` 匹配目录 code 时后端按稳定 code 大写归一化处理，前端可传小写；匹配显示名仍按数据库比较规则。`keyword` 无匹配时 `items=[]` / `page.total=0`，但只要酒店未过滤目录存在，`catalog_source/catalog_version` 仍保持真实目录元数据，不代表目录未初始化。前端在 `options_source=reservation_v4_account_catalog` 时调用，只提交 `items[].code`，Market / Source 以后端确认派生结果为准。 |
 | `GET /api/reservation/lookups/room-types` | 查询 V4 Room Type 目录 | 必须带 Bearer token，需要 `RESERVATION_TASK_READ`，支持 `hotel_id`、`keyword`、`page_num`、`page_size`；第一版只返回当前酒店 `ACTIVE` 房型目录，不接日期过滤，不代表 PMS 全量房型。`keyword` 匹配房型 code 时后端按稳定 code 大写归一化处理，前端可传小写；匹配显示名仍按数据库比较规则。`keyword` 无匹配时按空选项处理，不要当作目录不可用。前端在 `options_source=reservation_v4_room_type_catalog` 时调用。 |
-| `GET /api/reservation/lookups/rate-codes` | 查询 V4 Rate Code 目录 | 必须带 Bearer token，需要 `RESERVATION_TASK_READ`，支持 `hotel_id`、`keyword`、`page_num`、`page_size`；第一版只返回当前酒店 `ACTIVE` Rate Code，`pricing_available=false` 表示后端未接真实价格，不要据此展示价格。`keyword` 匹配 Rate Code 时后端按稳定 code 大写归一化处理，前端可传小写；匹配显示名仍按数据库比较规则。`keyword` 无匹配时按空选项处理，不要当作目录不可用。前端在 `options_source=reservation_v4_rate_code_catalog` 时调用。 |
+| `GET /api/reservation/lookups/rate-codes` | 查询 V4 Rate Code 目录 | 当前 CP11 实现只支持 `hotel_id`、`keyword`、`page_num`、`page_size`，返回当前酒店 `ACTIVE` Rate Code；下一阶段必须新增必填 `account_code`、`booking_type=GROUP/FIT`，只返回当前 Account + GROUP/FIT 适用的 Rate Code。`pricing_available=false` 表示后端未接真实价格，不要据此展示价格。`keyword` 匹配 Rate Code 时后端按稳定 code 大写归一化处理，前端可传小写；匹配显示名仍按数据库比较规则。Account 合法但无适用 Rate Code 时按空选项处理，不要当作目录不可用；`account_code` 缺失 / 无效或 `booking_type` 非法时按 400 处理。前端在 `options_source=reservation_v4_rate_code_catalog` 时调用。 |
 | `GET /api/admin/reservation/catalogs/accounts` | 管理后台 Account 目录列表 | 必须带 Bearer token，需要 `RESERVATION_CATALOG_MANAGE` 和目标酒店访问权；支持 `hotel_id`、`keyword`、`status=ACTIVE/DISABLED`、`page_num`、`page_size`；`keyword` 搜索 code 时大小写不敏感，显示名仍按数据库比较规则；返回 `items[] + page`，包含 `id`、`account_code`、`account_name`、`market_code`、`source_code`、`status`、`catalog_source`、`external_account_id`、`catalog_version`、`metadata_json`、`version`、`created_at`、`updated_at`。 |
 | `POST /api/admin/reservation/catalogs/accounts` | 管理后台新增 Account 目录 | 必须带 `RESERVATION_CATALOG_MANAGE`；请求 `hotel_id`、`account_code`、`account_name`、`market_code`、`source_code`，可选 `external_account_id`、`catalog_version`、`metadata_json`；后端校验 Market / Source 当前酒店 ACTIVE，新增后默认 `ACTIVE`、`catalog_source=SYSTEM_MANAGED`，写管理审计。 |
 | `PUT /api/admin/reservation/catalogs/accounts/{accountId}/status` | 管理后台启用 / 停用 Account | 必须带 `RESERVATION_CATALOG_MANAGE`；请求 `{"status":"ACTIVE"}` 或 `{"status":"DISABLED"}`；按记录所属酒店校验访问权；停用后普通 Account lookup 不再返回；如果提交的状态和当前状态一致，后端幂等返回当前记录，不新增管理审计。 |
@@ -72,8 +72,8 @@
 
 前端已在系统设置下新增 `/system/reservation-catalogs` 消费上述目录管理接口。页面入口要求 `RESERVATION_CATALOG_MANAGE`，列表过滤直接传 `hotel_id`、`keyword`、`status`、`page_num`、`page_size`；Account 新增第一版固定提交 `market_code=LEISURE`、`source_code=TRAVEL_AGENT`；状态重复提交按成功提示处理，不额外弹失败。
 
-| `POST /api/reservation/order-tasks/{orderTaskId}/cards/{cardId}/confirm` | 确认 V4 订单任务卡 | 必须带 Bearer token，需要 `RESERVATION_TASK_CONFIRM`，请求 JSON 带 `version`，可选 `confirmed_payload`；Basic Information 必须先确认，业务卡第一版不强制逐张顺序确认；前端只提交当前卡 `fields[]` 中可编辑字段，后端以展示快照为基准合并，未开放字段会被忽略；确认前会按当前酒店数据库目录校验 Account / Room Type / Rate Code，嵌套字段错误会返回如 `business_fields.after.room_items.0.room_type_code` 的路径，失败返回 `V4_FIELD_VALIDATION_FAILED`；确认后卡片 `CONFIRMED`、写 `confirmed_payload_json/confirmed_at/confirmed_by` 并锁定，重复确认返回错误；成功返回刷新后的订单任务详情。 |
-| `POST /api/reservation/order-tasks/{orderTaskId}/cards/{cardId}/review-resolution` | V4 复核解阻并确认卡片 | 必须带 Bearer token，需要 `RESERVATION_MANUAL_REVIEW_RESOLVE`，仅用于 `card_status=REVIEW_REQUIRED`；请求 JSON 带 `version`，可选 `field_overrides[]` 和 `reason`；订单任务归属未解决时 `confirmed_order_id` 必填，且必须是当前酒店下真实可见订单；目录错误字段可按 `validation_errors_json` / `fields[].validation_errors` 指向的 pointer 修正；成功后卡片 `CONFIRMED`、`review_status=RESOLVED`，写 `review_resolution_json/confirmed_payload_json/confirmed_at/confirmed_by` 并返回刷新后的订单任务详情。 |
+| `POST /api/reservation/order-tasks/{orderTaskId}/cards/{cardId}/confirm` | 确认 V4 订单任务卡 | 必须带 Bearer token，需要 `RESERVATION_TASK_CONFIRM`，请求 JSON 带 `version`，可选 `confirmed_payload`；Basic Information 必须先确认，业务卡第一版不强制逐张顺序确认；前端只提交当前卡 `fields[]` 中可编辑字段，后端以展示快照为基准合并，未开放字段会被忽略；确认前会按当前酒店数据库目录校验 Account / Room Type / Rate Code，下一阶段 `rate_code` 还必须属于已确认 Account + 当前业务 event `booking_type` 的适用范围；嵌套字段错误会返回如 `business_fields.after.room_items.0.room_type_code` 的路径，失败返回 `V4_FIELD_VALIDATION_FAILED`；确认后卡片 `CONFIRMED`、写 `confirmed_payload_json/confirmed_at/confirmed_by` 并锁定，重复确认返回错误；成功返回刷新后的订单任务详情。 |
+| `POST /api/reservation/order-tasks/{orderTaskId}/cards/{cardId}/review-resolution` | V4 复核解阻并确认卡片 | 必须带 Bearer token，需要 `RESERVATION_MANUAL_REVIEW_RESOLVE`，仅用于 `card_status=REVIEW_REQUIRED`；请求 JSON 带 `version`，可选 `field_overrides[]` 和 `reason`；订单任务归属未解决时 `confirmed_order_id` 必填，且必须是当前酒店下真实可见订单；`field_overrides[]` 只允许当前卡 `fields[]` 白名单内可编辑业务字段，问题字段可按 `fields[].validation_errors` 红字提示；成功后卡片 `CONFIRMED`、`review_status=RESOLVED`，写 `review_resolution_json/confirmed_payload_json/confirmed_at/confirmed_by` 并返回刷新后的订单任务详情。 |
 | `POST /api/reservation/source-notifications/{notificationId}/ack` | 确认 V4 S10/S99 来源通知已读 / 已处理 | 必须带 Bearer token，需要 `RESERVATION_TASK_CONFIRM`，请求 JSON 带 `version`；仅允许 `route_code=S10/S99`；确认后 `notification_status=ACKED`，写 `ack_by/ack_at`，成功返回刷新后的来源通知详情；重复 ack 返回当前已确认状态且不新增审计；该动作不创建订单、不参与订单阻塞。 |
 | `GET /api/reservation/order-tasks/{orderTaskId}/audits` / `GET /api/reservation/source-notifications/{notificationId}/audits` | 查询 V4 业务审计展示数据 | 必须带 Bearer token，需要 `RESERVATION_AUDIT_READ`；前端可在 V4 订单任务详情和 S10/S99 来源通知详情的“审计时间线”中调用。响应沿用旧审计行结构：`audit_id`、`actor_type`、`actor_id`、`action`、`reason`、`before_snapshot`、`after_snapshot`、`occurred_at`。快照已由后端脱敏，前端仍不要把未知 URL-like 字符串当附件或正文直渲。 |
 | `GET /api/reservation/orders/{orderId}` | 查询订单详情与任务时间线 | 必须带 Bearer token，需要 `RESERVATION_ORDER_READ`，后端按订单所属酒店做访问校验；`include_tasks=false` 可只取轻量摘要，此时旧 `tasks[]`、V4 `v4_order_tasks[]` 和 `related_source_messages[]` 都为空数组，`order_overview` 为空快照，`next_v4_action.action_type=NONE`；旧 `tasks[]` 按后端队列顺序返回，前端不要自行按创建时间重排；V4 `v4_order_tasks[]` 按同订单 V4 订单任务来源时间正序返回；隐藏技术订单详情不可作为普通订单页打开。 |
@@ -88,7 +88,7 @@
 | `GET /api/source-messages` | 查询来源消息安全摘要 | 必须带 Bearer token，需要 `SOURCE_MESSAGE_READ`；列表不返回邮件正文、HTML、附件 URL 或原始 payload；查询参数以 `hotel_id`、`external_message_id`、`external_conversation_id`、`page_num`、`page_size` 为准，后端暂兼容早期 camelCase 参数。 |
 | `GET /api/source-messages/{id}` | 查询来源消息安全详情 | 必须带 Bearer token，需要 `SOURCE_MESSAGE_READ`，后端按消息所属酒店做访问校验；只用于安全摘要详情。 |
 | `GET /api/source-messages/{id}/original` | 读取来源消息原文 | 必须带 Bearer token，需要同时拥有 `SOURCE_MESSAGE_READ` 和 `SOURCE_MESSAGE_ORIGINAL_READ`；后端按消息所属酒店做访问校验；返回 HTML 时前端展示前必须 sanitize。 |
-| `GET /api/source-messages/{sourceMessageId}/conversation` | 读取邮件会话详情 | 必须带 Bearer token，需要同时拥有 `SOURCE_MESSAGE_READ` 和 `SOURCE_MESSAGE_ORIGINAL_READ`；返回同一外部会话全部邮件的完整 text/html、`html_body_sanitized`、附件外链、内联图片和关联订单 / 任务摘要；前端不传原文读取 key，展示 HTML 时优先使用 `html_body_sanitized`。 |
+| `GET /api/source-messages/{sourceMessageId}/conversation` | 读取邮件会话详情 | 必须带 Bearer token，需要同时拥有 `SOURCE_MESSAGE_READ` 和 `SOURCE_MESSAGE_ORIGINAL_READ`；返回同一外部会话全部邮件的完整 text/html、`html_body_sanitized`、附件外链、内联图片和关联订单 / 任务摘要；前端不传原文读取 key，展示 HTML 时优先使用 `html_body_sanitized`。V4 Payment 卡图片预览和非图片下载也走该接口，前端只能使用当前触发 SourceMessage 且被 Payment `attachment_ids[]` 引用的附件。 |
 | `POST /api/system/debug/eml-superagent-runs` | Debug 页面上传 `.eml` 并调用 SuperAgent | 仅 dev/test 受控调试使用；会写入 SourceMessage Inbox。Debug 服务自身不直接创建订单和任务；如 SuperAgent 通过正式回调 / MCP 写入业务结果，必须按当前 M002 V4 契约创建 V4 order task / cards，不再创建旧 `workflow_reservation_task`。 |
 | `GET/POST/PUT /api/admin/users...` | 系统管理用户维护 | 需要 Bearer token 和 `SYSTEM_USER_MANAGE`；用户 ID 返回字符串；禁用用户会撤销其 ACTIVE session。 |
 | `GET/POST/PUT /api/admin/roles...` | 系统管理角色权限维护 | 需要 `SYSTEM_ROLE_MANAGE`；内置角色只读，自定义角色可新增、编辑和分配权限。 |
@@ -111,7 +111,7 @@
 | `GET /api/source-messages/{sourceMessageId}/conversation` | 新增邮件会话详情接口，并补齐 `html_body_sanitized` / `html_render_mode`。 | 当前唯一推荐路径是这个接口；前端渲染邮件 HTML 时优先使用 `html_body_sanitized`；不要调用历史讨论过的 `/api/source-message-conversations/{externalConversationId}`。 |
 | `POST /api/system/debug/eml-superagent-runs` | 新增 Debug EML 上传到 SuperAgent 调试接口，并补齐独立 Debug 外部消息 ID、原始 Message-ID 保留、安全 HTML 字段和入口通知识别。 | 只用于调试页面；请求为 multipart/form-data；必须传 `X-TH-Hotel-Debug-Upload-Key`，但该 key 不能写进前端源码、构建产物、URL、localStorage 或错误上报；SuperAgent 返回旧 S000/S999 或新 S10/S99 入口通知时都不应被前端视为 JSON 解析失败。测试机 V4 smoke 默认使用实时 AgentBus V4 subject，历史 Debug V2/V3 profile 只能由后端显式配置，不应作为 V4 smoke 入口。 |
 | `GET /api/reservation/workbench-items` / `/api/reservation/order-tasks/**` / `/api/reservation/source-notifications/{notificationId}` | 新增 M002 V4 CP5 查询接口，并在 CP6 打开卡片确认 / 来源通知 ack availability。 | 这是 V4 新模型前端主入口；前端应按每张卡或通知返回的 `availability.confirmable`、`availability.ackable`、`readonly_reason_code` 控制按钮。工作台条目已返回 `created_at` / `updated_at` 作为排序兜底和调试字段；前端不要继续从旧 `/api/reservation/tasks/**` 推断 V4 多卡详情。 |
-| `GET /api/reservation/lookups/accounts` / `/room-types` / `/rate-codes` | 新增 M002 V4 CP11 数据库目录 lookup。 | 前端从任务详情 `fields[].options_source` 选择调用哪个 lookup；只提交返回项的 `code`，不要提交显示名、派生 Market / Source、目录完整对象或前端自造 code。`warnings[]` 非空时可做非阻塞提示。 |
+| `GET /api/reservation/lookups/accounts` / `/room-types` / `/rate-codes` | 新增 M002 V4 CP11 数据库目录 lookup。 | 前端从任务详情 `fields[].options_source` 选择调用哪个 lookup；只提交返回项的 `code`，不要提交显示名、派生 Market / Source、目录完整对象或前端自造 code。Rate Code 下一阶段必须带已选 / 已确认 `account_code` 和当前业务 event `booking_type`，不能再拉全酒店全量候选。`warnings[]` 非空时可做非阻塞提示。 |
 | `GET/POST/PUT /api/admin/reservation/catalogs/...` | 新增 M002 V4 目录管理后台 CP1 后端接口。 | 仅供系统设置 / 管理后台页面使用，必须带 `RESERVATION_CATALOG_MANAGE`；支持 Account、Room Type、Rate Code 列表、新增、启用 / 停用；停用后普通 lookup 不再返回该目录项。 |
 
 V4 CP5 分页注意：`page_num` 从 1 开始，后端第一版安全上限为 100；`page_size` 最大 100。超出上限时后端按上限处理并在 `page.page_num` / `page.page_size` 中返回实际使用值。`order_task_status` 和 `card_status` 是稳定枚举查询参数，前端不要传中文文案或自造状态码。
@@ -184,6 +184,7 @@ POST /api/auth/logout
 - 第一版仅处理 HTML 内容安全；`inline_images[]` 和 `attachments[]` 的 `externalUrl` 来自本系统 OSS 服务，暂不做额外拦截，但前端仍不得写入普通日志、错误上报、localStorage 或 URL query。
 - 会话详情接口由后端内部写原文读取审计，actor 使用当前登录用户稳定 ID；前端不传 `X-TH-Hotel-Source-Original-Read-Key`、`X-TH-Hotel-Actor` 或 `X-TH-Hotel-Access-Scene`。
 - 会话详情外层字段主要是 snake_case，但媒体对象沿用原文读取接口字段，当前是 `mediaType`、`fileName`、`contentType`、`sizeBytes`、`externalUrl`、`externalMediaId` 这种 camelCase，前端类型定义需要单独处理。
+- Payment 卡附件预览规则：业务卡里的 `attachment_ids[]` 是付款凭证引用，第一版只读展示并确认卡片，不允许前端增删或替换附件集合；后端下一阶段可返回 `payment_attachments[]` 安全摘要辅助展示。图片附件按 `contentType` 以 `image/` 开头判断，在卡片中展示缩略图，点击后打开大图预览；非图片附件统一展示文件名、类型、大小和下载按钮，不在 Payment 卡中内嵌 PDF / Word / Excel 预览。预览和下载必须先通过会话接口定位当前 SourceMessage，再按 `externalMediaId` / `payment_attachments[].external_media_id` 或附件 ID 匹配，不能按文件名猜测。
 
 ### 5.5 订单列表接入注意
 
@@ -495,7 +496,7 @@ RESERVATION_ROOMING_LIST_GENERATE
 后端已提供以下 V4 查询和写接口，前端接入时按这些约束实现；在前端页面正式集成并完成联调前，不把 V4 前端页面视为完成：
 
 - `/reservation/tasks` 应使用 `GET /api/reservation/workbench-items` 作为默认工作台列表入口，展示 V4 订单任务和 S10/S99 来源通知混排摘要；当筛选工作项类型为订单任务时，改用 `GET /api/reservation/order-tasks`，仅发送后端当前支持的 `keyword`、`order_task_status`、`card_status`、`page_num`、`page_size`。
-- `/reservation/order-tasks/{orderTaskId}` 应使用 `GET /api/reservation/order-tasks/{orderTaskId}` 展示 `source_message_card`、`basic_information_card`、`business_cards[]`、`card_counts`、`order_task` 摘要和 `adapter_contract_errors[]` 只读诊断。
+- `/reservation/order-tasks/{orderTaskId}` 应使用 `GET /api/reservation/order-tasks/{orderTaskId}` 展示 `basic_information_card`、`business_cards[]`、`source_message_card`、`card_counts`、`order_task` 摘要和 `adapter_contract_errors[]` 只读诊断；页面顺序固定为 Basic Information、业务卡、SourceMessage Display。
 - `/reservation/source-notifications/{notificationId}` 应使用 `GET /api/reservation/source-notifications/{notificationId}` 展示 S10/S99 来源通知详情，并通过 `POST /api/reservation/source-notifications/{notificationId}/ack` 确认已读 / 已处理。
 - V4 审计时间线应分别调用 `GET /api/reservation/order-tasks/{orderTaskId}/audits` 和 `GET /api/reservation/source-notifications/{notificationId}/audits`；按钮权限使用 `/api/auth/me.permissions[]` 中的 `RESERVATION_AUDIT_READ`。
 - V4 卡片确认应使用 `POST /api/reservation/order-tasks/{orderTaskId}/cards/{cardId}/confirm`，请求带 `version`；前端只从当前卡 `fields[]` 中挑选 `editable=true`、`raw_readonly!=true`、`write_target` 指向确认 payload 的字段构造 `confirmed_payload`。
@@ -503,8 +504,9 @@ RESERVATION_ROOMING_LIST_GENERATE
 - 所有按钮应按后端 `availability.confirmable`、`availability.reviewable`、`availability.ackable` 和前端权限共同控制；不可操作原因优先展示 `readonly_reason_message`，否则按 `readonly_reason_code` 做友好映射。
 - `fields[].validation_errors` 应展示在对应字段旁边；接口返回 `V4_FIELD_VALIDATION_FAILED` 且 `details[]` 带嵌套路径时，前端应尝试定位到对应 field，定位不到则在当前卡片动作错误区展示。
 - `options_source=reservation_v4_account_catalog`、`reservation_v4_room_type_catalog`、`reservation_v4_rate_code_catalog` 时，前端应调用对应 lookup API，不再硬编码固定种子；如果 lookup 返回空列表或 `warnings[]`，前端展示非阻塞提示，但提交时仍以后端目录校验为准。
-- 前端不展示 `ai_payload_json`、邮件完整正文、附件 URL、raw evidence 或 SuperAgent 原始 payload；来源邮件详情仍从邮件会话页面查看，卡片内仅展示后端普通接口返回的安全摘要、邮件片段和附件名称。
-- V4 来源消息卡读取 `attachments`、`uploaded_media`、`file_references` 时，只允许展示附件名称、类型和大小等安全摘要；如果后端 payload 中异常出现 `https://`、`oss://`、`s3://` 等直接 URL 字符串，前端必须替换为“未命名附件”或隐藏，不得把 URL 渲染到普通业务页面。
+- Trace 卡 `trace_items[].department_code` 第一版先固定下拉选项 `FO`、`HSK`、`FO+HSK`，不要调用不存在的 Department lookup API，也不要允许自由文本；正式 Department 目录和后端目录校验后续单独扩展。
+- 前端不展示 `ai_payload_json`、附件 URL、raw evidence 或 SuperAgent 原始 payload；V4 任务详情页底部 `SOURCE_MESSAGE_DISPLAY` 可展示当前触发该 order task 的 SourceMessage 正文，但必须通过 `GET /api/source-messages/{sourceMessageId}/conversation` 读取并写原文读取审计，不能要求 `GET /api/reservation/order-tasks/{orderTaskId}` 直接返回正文。Payment 卡如展示付款凭证图片，也必须通过同一会话接口获取受控附件 URL：卡片内显示缩略图，点击打开大图预览；非图片只显示文件列表和下载。HTML 邮件优先渲染 `html_body_sanitized`，缺少原文权限或接口失败时降级为安全摘要和“查看邮件会话”入口。
+- V4 来源消息卡读取 `attachments`、`uploaded_media`、`file_references` 时，只允许展示附件名称、类型和大小等安全摘要；如果后端 payload 中异常出现 `https://`、`oss://`、`s3://` 等直接 URL 字符串，前端必须替换为“未命名附件”或隐藏，不得把 URL 渲染到普通业务页面。`SOURCE_MESSAGE_DISPLAY` 的邮件正文默认做长度折叠，用户可展开全文。
 - V4 主流程不调用旧 V2/V3 草稿、旧任务确认、旧同卡复核接口，也不展示 OPERA 模拟操作入口。
 - 2026-07-20 测试机 smoke 注意：订单详情页依赖 `GET /api/reservation/orders/{orderId}` 返回 `order_overview`、`next_v4_action`、`related_source_messages[]` 和 `v4_order_tasks[].cards[]`。如果测试机响应仍只有旧 `order`、`tasks[]`、基础 `v4_order_tasks[]` 和 `warnings`，应先确认测试机后端是否部署了包含 M002 V4 CP15.1 的最新包；前端不要为了该旧响应重新做兼容逻辑，避免把部署问题固化成页面分支。
 
@@ -524,6 +526,12 @@ RESERVATION_ROOMING_LIST_GENERATE
 - M002 V4 入站解析与数据模型基线已完成第一版：后端可接收 `source_message + order_contexts[] + message_events[]`，识别 `NEW_BOOKING`、`UPDATE_BOOKING`、`CANCEL_BOOKING`、`TRACE_RESERVATION_NOTES`、`ROOMING_LIST`、`PAYMENT`，并保存 V4 原始 payload、`route_code`、系统处理分类和 `field_contract_version=20260718-v4`。前端暂不需要直接调用 V4 回调接口。
 - M002 V4 CP5 已完成查询接口：普通 V4 业务包可通过 `/api/reservation/workbench-items`、`/api/reservation/order-tasks`、`/api/reservation/order-tasks/{orderTaskId}` 查看；V4 S10/S99 来源通知可通过 `/api/reservation/source-notifications/{notificationId}` 查看。M002 V4 CP6 已开放普通卡片确认和 S10/S99 ack 写接口；M002 V4 CP7 已开放 `POST /api/reservation/order-tasks/{orderTaskId}/cards/{cardId}/review-resolution` 复核解阻接口；M002 V4 CP8 已开放 V4 卡片 `fields[]` 白名单和目录校验；M002 V4 CP11 已把固定种子迁移到数据库目录，并开放 Account / Room Type / Rate Code lookup API；目录管理后台 CP1 已开放 Account / Room Type / Rate Code 后端列表、新增、启用 / 停用接口；V4 业务审计查询已补齐订单任务审计和来源通知 ack 审计两个只读接口。
 - V4 任务卡的 `display_payload_json` 只保留后端白名单展示字段；`ai_payload_json` 才包含完整 SuperAgent 原始 event。后续 V4 查询接口不得把 `ai_payload_json`、附件 URL 或 raw evidence 直接给普通页面渲染；前端对来源消息卡附件字段仍做 URL-like 文本兜底脱敏。
+- Room Information 卡下一阶段应由后端返回业务展示模型，前端不要自行从 Agent raw payload 计算。`NEW_BOOKING` 展示最终值，Group 的最终订单投影字段 `group_block_name` 可编辑，默认来自 `target_order.locator_value` 且 `locator_type=GROUP_CODE`；Fit 的最终订单投影字段 `fit_name` 可编辑，默认来自 `guest_name ?? target_order.locator_value`；Agent 原始 `target_order.locator_value` 始终只读，用户编辑只影响本系统最终订单投影和确认快照。`UPDATE_BOOKING` 展示本地当前值到 Agent 修改后值的 `change_summary[]`，日期变化时连带展示 Nights 差异，字段区展示合并后的最终值；`CANCEL_BOOKING` 从本地订单投影只读展示。Nights 由后端按酒店本地日期派生，Adult 不显示。
+- Room Information 卡 Breakfast 前端显示为“含早”勾选框：Group 固定勾选且只读；Fit 由后端按最终 Rate Code 中 `RB` / `RO` 派生，无法派生时作为必填勾选项。Group Booking Status 仅 Group 显示，稳定 code 为 `TEN` / `DEF` / `INQ`，展示文案为 `TEN-Tentative`、`DEF-Definite`、`INQ-Inquiry`；New Group 默认 `TEN`，`NEW_BOOKING` / `UPDATE_BOOKING` 确认前可改选，`CANCEL_BOOKING` 只读。
+- Rooming List 卡确认存在跨卡联动：同订单为 Group 时，确认 `ROOMING_LIST` 后后端应把 Group Booking Status 自动置为 `DEF`，即使此前为 `TEN` 或 `INQ`；Fit 不显示也不变更该状态。该自动变更需由后端写审计，前端只展示刷新后的状态。
+- Rooming List 卡第一版是轻量事项确认卡：前端展示卡片标题、状态、目标订单信息和“确认卡片”按钮即可；不要做名单 rows、附件预览、Excel 生成或 PMS 导入入口。确认仅表示该 Rooming List 事项已人工处理。
+- Payment 卡下一阶段建议由后端在 `display_payload_json.payment_attachments[]` 返回安全摘要，字段只包含附件 ID、文件名、类型、大小、是否图片、是否可预览 / 下载等，不包含外链。第一版 `attachment_ids[]` 是 Agent 返回的只读业务事实，前端只展示并确认卡片，不允许用户增删、替换或重新选择附件集合，也不把 `attachment_ids[]`、`externalUrl` 或完整附件对象提交回确认接口。
+- V4 复核态卡片仍是原业务卡，不新建单独复核任务卡；页面状态显示“需要复核”，问题字段用 `fields[].validation_errors` 红字提示，主按钮文案统一为“确认卡片”。前端内部必须根据 `card_status=REVIEW_REQUIRED` 调用 `review-resolution`，不要调用普通 `confirm`。
 - V4 可映射 event 现阶段仍保留现有任务详情结构作为过渡兼容；任务详情中若出现 `field_contract_version=20260718-v4` 或 AI payload 内的 `v4_source_message`、`v4_order_context`、`v4_message_event`，前端第一版只读展示即可，不要据此假定完整 V4 多卡页面已经完成。
 - V4 `PAYMENT.attachment_ids[]` 不匹配、`UPDATE_BOOKING` 携带 `rate_code` 等问题会出现在任务详情同批次的 `adapter_contract_errors[]` 只读诊断块中，不展示保存、确认、执行或重试按钮。该字段只返回白名单诊断字段，不返回完整 AI payload、邮件正文、附件 URL 或 raw evidence。
 - V4 包级契约错误只会保存在 AI transition 中，不会出现在普通任务列表；V4 event 级契约错误如果同批次存在其它业务任务，前端仍按任务详情里的 `adapter_contract_errors[]` 只读展示诊断信息。
@@ -533,9 +541,9 @@ RESERVATION_ROOMING_LIST_GENERATE
 - CP11 起 V4 入站阶段按当前酒店数据库目录做校验：Account 缺失或不存在时 Basic Information 卡直接 `REVIEW_REQUIRED`；业务卡已有 `room_items[].room_type_code` 或 `rate_code` 但不在当前酒店目录时，业务卡也会直接 `REVIEW_REQUIRED`，错误会回显在 `fields[].validation_errors`。
 - CP8 确认接口也按 `fields[]` 白名单收口：前端可以只提交用户修改过的可编辑字段，不建议整包回传 `display_payload`。后端会从当前卡展示快照生成确认快照，并只合并可写叶子字段；来源邮件、路由、`target_order`、`order_ref`、`manual_review`、校验诊断字段以及前端额外注入字段不会写入 `confirmed_payload_json`。
 - 业务卡目录校验会递归检查 `business_fields` 下的嵌套结构。例如 `UPDATE_BOOKING` 的房型可能位于 `/business_fields/after/room_items/0/room_type_code`，错误详情会使用 `business_fields.after.room_items.0.room_type_code`；前端展示错误时优先用 `fields[].validation_errors`，接口 400 时可直接展示 `details[]`。
-- `review-resolution` 请求示例：`{"version":0,"reason":"确认房型映射","confirmed_order_id":"123456","field_overrides":[{"field_pointer":"/business_fields/room_items/0/pms_room_type_code","value":"RM2"}]}`。`confirmed_order_id` 在订单任务归属未解决时必填；如果订单任务已经绑定订单且 `target_resolution_status=RESOLVED`，只能不传或传当前同一个订单 ID，不能借该接口切换到其它订单。`field_pointer` 必须来自当前卡允许编辑的 `basic_information.*` 或 `business_fields.*` 叶子字段；展示 payload 有 `missing_fields[]` 时只提交清单里的 pointer，没有显式清单时只提交当前值为 `null` / 空字符串的未解决叶子字段；如果是目录校验错误，也可以提交后端 `fields[].validation_errors` 对应的字段 pointer。前端不要提交来源邮件、路由、`target_order`、`order_ref`、缺失字段清单、`manual_review`、raw evidence、校验诊断字段，也不能替换整个对象 / 数组。
+- `review-resolution` 请求示例：`{"version":0,"reason":"确认房型映射","confirmed_order_id":"123456","field_overrides":[{"field_pointer":"/business_fields/room_items/0/pms_room_type_code","value":"RM2"}]}`。`confirmed_order_id` 在订单任务归属未解决时必填；如果订单任务已经绑定订单且 `target_resolution_status=RESOLVED`，只能不传或传当前同一个订单 ID，不能借该接口切换到其它订单。`field_pointer` 必须来自当前卡 `fields[]` 中可编辑的 `basic_information.*` 或 `business_fields.*` 叶子字段；复核态允许编辑当前卡业务白名单内字段，不再限定只能改空值、`missing_fields[]` 或目录错误字段。前端不要提交来源邮件、路由、`target_order`、`order_ref`、缺失字段清单、`manual_review`、raw evidence、校验诊断字段，也不能替换整个对象 / 数组。
 - V4 `fields[]` 第一版字段说明：Basic Information 固定返回 `/basic_information/account_code`、`/basic_information/market_code`、`/basic_information/source_code`；其中 Account `control_type=select`、`options_source=reservation_v4_account_catalog`，Market / Source 为只读派生字段。业务卡会按展示 payload 里的业务叶子字段返回字段白名单，例如 `/room_items/0/room_type_code` 或 `/business_fields/room_items/0/pms_room_type_code`；前端不要自行补未返回字段。
-- V4 CP11 已开放独立目录 lookup API。前端应使用 `GET /api/reservation/lookups/accounts`、`GET /api/reservation/lookups/room-types`、`GET /api/reservation/lookups/rate-codes` 渲染 Account / Room Type / Rate Code 选项；用户提交确认或复核时只提交稳定 `code`，不要提交显示名、派生 Market / Source 或目录完整对象；后端确认前仍会重新校验目录。`keyword` 查不到只表示当前筛选无结果，不能仅凭 `items=[]` 判断目录未初始化，应结合 `catalog_source`、`catalog_version` 和 `warnings[]`。
+- V4 CP11 已开放独立目录 lookup API。前端应使用 `GET /api/reservation/lookups/accounts`、`GET /api/reservation/lookups/room-types`、`GET /api/reservation/lookups/rate-codes` 渲染 Account / Room Type / Rate Code 选项；用户提交确认或复核时只提交稳定 `code`，不要提交显示名、派生 Market / Source 或目录完整对象；后端确认前仍会重新校验目录。Rate Code 下一阶段依赖 Account + `booking_type`：前端需在 Account 已选 / 已确认且能取得当前业务 event `booking_type` 后再请求 Rate Code，Account 改变后清空或重新校验已选 Rate Code；缺失条件时禁用或空态，不硬编码 OWNER RATE Excel。`keyword` 查不到只表示当前筛选无结果，不能仅凭 `items=[]` 判断目录未初始化，应结合 `catalog_source`、`catalog_version` 和 `warnings[]`。
 - M002 V4 CP12 前端已接入上述三个 lookup API：V4 多卡详情页会按当前卡 `fields[].options_source` 拉取目录选项，空 `items[]`、`stale=true` 和 `warnings[]` 作为非阻塞提示展示；Account 选择后只展示目录返回的 `market_code` / `source_code` 辅助确认，确认 / 复核请求仍只提交用户选择的 code。
 - V4 新模型确认口径是不保存后端草稿、卡片最终确认后锁定、技术异常不进入用户可处理卡、当前不生成 OPERA 模拟操作。Basic Information 必须先确认；其它业务卡第一版不强制逐张顺序确认。现有 V3 `draft`、`confirm`、`manual-review-resolutions` 和 OPERA 模拟接口仍只代表旧链路能力，不能直接等同 V4 多卡最终接口。
 - V4 S10/S99 已采用来源通知模型入库：新 V4 `route_code=S10/S99` 不再挂隐藏技术订单，也不再创建旧 `SOURCE_MESSAGE_ONLY` 任务；对应工作台 / 来源通知详情查询接口和 ack 写接口已开放。旧 `SOURCE_MESSAGE_ONLY` 只读任务仅代表 V3 S10/S99 和旧 S000/S999 兼容数据。

docs/project/frontend-backend/frontend-to-backend-api-requests.md

@@ -12,6 +12,7 @@
 | P0 | 任务列表接口 `GET /api/reservation/tasks` | 任务列表菜单、订单详情任务入口 | 已完成第一版，已补来源邮件会话字段和 `order_status` 筛选 |
 | P0 | 订单详情接口 `GET /api/reservation/orders/{orderId}` | 订单详情页 | 已完成第一版，已补旧 `tasks[]` 来源邮件会话字段和 V4 `order_overview` / `next_v4_action` / `related_source_messages[]` / `v4_order_tasks[].cards[]`，前端订单详情总览页已接入 |
 | P0 | 任务详情读取接口 `GET /api/reservation/tasks/{taskId}` | 任务详情页动态渲染 | 已完成第一版，已补来源邮件字段和 3.0 字段元数据 |
+| Done | V4 订单任务详情接口 `GET /api/reservation/order-tasks/{orderTaskId}` | V4 任务详情页 | 已完成第一版；页面展示顺序调整为 Basic Information、业务卡、SourceMessage Display，来源邮件正文通过 SourceMessage conversation 接口读取当前触发邮件 |
 | P0 | 任务详情操作接口 | 任务详情保存、确认、OPERA、审计 | 已完成；前端可直接接入 |
 | P0 | 邮件会话详情接口 `GET /api/source-messages/{sourceMessageId}/conversation` | 邮件会话详情页 | 已完成第一版 |
 | 联调 | 演示数据 seed 接口 `POST /api/system/reservation/demo-data` | 本地 / test 前端页面看效果 | 已完成；仅 dev/test 受控使用 |
@@ -32,6 +33,7 @@
 | `GET /api/reservation/tasks` | 已完成第一版，已补来源邮件会话字段和所属订单状态筛选 | 可以 | `order_status` 按任务所属订单状态过滤；不传时保持当前全部任务列表行为。 |
 | `GET /api/reservation/orders/{orderId}` | 已完成第一版，已补旧 `tasks[]` 来源邮件会话字段、V4 总览和 V4 `v4_order_tasks[]` 时间线，前端订单详情总览页已接入 | 可以 | 暂无；`include_tasks=false` 时旧 `tasks[]`、V4 `v4_order_tasks[]` 和 `related_source_messages[]` 都返回空数组，`order_overview` 为空快照，`next_v4_action.action_type=NONE`。 |
 | `GET /api/reservation/tasks/{taskId}` | 已完成第一版，已补任务顶层来源邮件字段和 `fields[]` 3.0 元数据 | 可以 | 当前 Controller 不接收 `hotel_id`；如后续多酒店隔离需要前端显式传酒店上下文，请后端补可选入参或确认按 taskId 全局唯一即可。 |
+| `GET /api/reservation/order-tasks/{orderTaskId}` | 已完成第一版；Room Information 展示模型、复核态字段白名单和 Payment 附件安全摘要待补齐 | 可以，但 Room Information 业务化展示、复核态整卡编辑和 Payment 预览需后端补模型 / 摘要后再完整联动 | V4 任务详情页展示顺序为 Basic Information、业务卡、SourceMessage Display；Trace 卡 `department_code` 第一版固定为 `FO` / `HSK` / `FO+HSK` 三个下拉值，不调用 Department lookup，不开放自由输入。Room Information 下一阶段由后端返回业务展示模型：New 展示最终值，Update 展示 `change_summary[]` 和合并后的最终值，Cancel 展示本地订单投影只读；Nights 后端按酒店本地日期派生，Breakfast 前端为含早勾选框，Group Booking Status 显示 `TEN-Tentative` / `DEF-Definite` / `INQ-Inquiry`；New Booking 最终订单投影字段 `group_block_name` / `fit_name` 可编辑，Group 默认来自 `target_order.locator_value` 且 `locator_type=GROUP_CODE`，Fit 默认来自 `guest_name ?? target_order.locator_value`，但 Agent 原始 `target_order.locator_value` 只读且不被用户编辑回写。`REVIEW_REQUIRED` 仍是原业务卡复核态，问题字段红字提示，按钮统一显示“确认卡片”，前端内部调用 `review-resolution`。Rooming List 卡第一版只做事项确认，前端展示标题、状态、目标订单信息和“确认卡片”按钮，不做名单 rows、附件预览、Excel 生成或 PMS 导入。本接口仍不直接返回邮件正文或附件 URL。来源邮件卡正文限定为当前触发该 V4 order task 的那封 SourceMessage 正文，前端用 `source_message_summary.source_message_id` 调用 `GET /api/source-messages/{sourceMessageId}/conversation` 后定位当前邮件，默认长度折叠并可展开；缺少 `SOURCE_MESSAGE_ORIGINAL_READ` 或会话接口失败时降级展示安全摘要。Payment 卡下一阶段建议返回 `payment_attachments[]` 安全摘要，供前端展示图片缩略图 / 非图片文件列表；`attachment_ids[]` 第一版只读，不支持前端增删、替换或重新选择附件集合；实际大图预览和下载 URL 仍走 SourceMessage conversation。 |
 | `PUT /api/reservation/tasks/{taskId}/draft` | 已完成 | 可以 | 当前 Controller 不接收 `hotel_id`；如写操作需要酒店上下文幂等 / 权限校验，请后端补可选入参或请求体字段。 |
 | `POST /api/reservation/tasks/{taskId}/confirm` | 已完成 | 可以 | 当前 Controller 不接收 `hotel_id`；如写操作需要酒店上下文幂等 / 权限校验，请后端补可选入参或请求体字段。 |
 | `GET /api/reservation/tasks/{taskId}/audits` | 已完成 | 可以 | 当前 Controller 不接收 `hotel_id`；如审计查询需要酒店上下文隔离，请后端补可选入参。 |
@@ -43,13 +45,13 @@
 | `GET /api/source-messages/{id}` | 已完成单条安全摘要 | 可以 | 不能替代邮件会话全文接口。 |
 | `GET /api/source-messages/{id}/original` | 已完成单封原文权限读取 | 谨慎接入 | 必须带 Bearer token，需要同时拥有 `SOURCE_MESSAGE_READ` 和 `SOURCE_MESSAGE_ORIGINAL_READ`；只能读单封邮件，不能返回同一 conversation 全量邮件。 |
 | `GET /api/reservation/orders` | 已完成第一版 | 可以 | 默认查询全部订单状态；订单列表待处理展示使用 `open_work_item_count`；V4 普通业务已停止双写旧任务，旧 `open_task_count` 仅作为历史诊断计数。 |
-| `GET /api/source-messages/{sourceMessageId}/conversation` | 已完成第一版，已补 `html_body_sanitized` 和 `html_render_mode` | 可以 | 必须带 Bearer token，需要同时拥有 `SOURCE_MESSAGE_READ` 和 `SOURCE_MESSAGE_ORIGINAL_READ`；返回完整 text/html、后端清洗后的 HTML、媒体外链和关联订单 / 任务摘要；前端不传原文读取 key，页面展示优先使用 `html_body_sanitized`。 |
+| `GET /api/source-messages/{sourceMessageId}/conversation` | 已完成第一版，已补 `html_body_sanitized` 和 `html_render_mode` | 可以 | 必须带 Bearer token，需要同时拥有 `SOURCE_MESSAGE_READ` 和 `SOURCE_MESSAGE_ORIGINAL_READ`；返回完整 text/html、后端清洗后的 HTML、媒体外链和关联订单 / 任务摘要；前端不传原文读取 key，页面展示优先使用 `html_body_sanitized`。V4 Payment 卡图片大图预览和非图片下载也复用该权限链路，只能使用当前触发 SourceMessage 且被 `attachment_ids[]` 引用的附件。 |
 | `POST /api/system/reservation/demo-data` | 已完成 | 仅本地 / test 联调可用 | 默认关闭，必须后端配置访问口令；不能作为生产页面接口。 |
 | `POST /api/system/debug/eml-superagent-runs` | 已完成第一版 | 仅 dev/test Debug 页面可用 | 默认关闭，必须后端配置访问口令、阿里云 OSS 和 SuperAgent Open API；Debug 服务自身只展示 SuperAgent 结果，不直接创建订单和任务；如 SuperAgent 通过正式回调 / MCP 写入业务结果，V4 smoke 必须创建 V4 order task / cards，不再创建旧 `workflow_reservation_task`；已能识别旧 S000/S999 和新结构化 S10/S99。 |
 | `GET /api/source-message-conversations/{externalConversationId}` | 未发现后端实现 | 不可以 | 历史讨论过的候选路径，当前不提供；前端统一使用 `GET /api/source-messages/{sourceMessageId}/conversation`。 |
 | `GET /api/reservation/message-notifications` | 未发现后端实现 | 不可以 | 历史候选路径，当前不提供。旧 S000/S999 和 V3 S10/S99 兼容数据通过 `SOURCE_MESSAGE_ONLY` 任务展示；V4 S10/S99 新数据走 V4 工作台和 `/api/reservation/source-notifications/{notificationId}`，不要再请求本候选路径。 |
 | `GET /api/reservation/task-card-field-whitelist` | 未发现后端实现 | 不可以 | 若任务详情 `fields[]` 已补齐 3.0 元数据，可后置。 |
-| `GET /api/reservation/lookups/accounts` / `room-types` / `rate-codes` | M002 V4 CP11 已实现 | 可以 | 用于 V4 任务卡下拉 / 搜索选择；Bearer token + `RESERVATION_TASK_READ` + 酒店访问权；支持 `hotel_id`、`keyword`、`page_num`、`page_size`，第一版只返回 ACTIVE 目录。 |
+| `GET /api/reservation/lookups/accounts` / `room-types` / `rate-codes` | M002 V4 CP11 已实现；Rate Code Account 范围过滤待补齐 | 可以，但 Rate Code 需后端新增过滤参数后再改前端联动 | 用于 V4 任务卡下拉 / 搜索选择；Bearer token + `RESERVATION_TASK_READ` + 酒店访问权；Account / Room Type 支持 `hotel_id`、`keyword`、`page_num`、`page_size`，只返回 ACTIVE 目录。Rate Code 下一阶段必须新增 `account_code`、`booking_type=GROUP/FIT` 必填过滤，只返回当前 Account + GROUP/FIT 适用候选。 |
 
 ## 3. 任务列表 / 工作台接口字段补齐
 
@@ -330,7 +332,7 @@ GET /api/reservation/orders/{orderId}
 | `result_type` / `ai_task_type` / `route_code` / `system_process_category` | V3 路由展示字段，和任务列表字段语义一致。 |
 | `order_overview` | V4 订单详情当前确认快照，只从已确认 V4 卡片派生；未确认 AI 建议不会进入这里。 |
 | `order_overview.account_code` / `account_name` / `market_code` / `source_code` | 来自已确认 Basic Information 卡；为空表示 Basic Information 尚未确认或无可靠确认值。 |
-| `order_overview.arrival_date` / `departure_date` / `rate_code` / `room_items[]` | 来自已确认 Room Information 卡；后出现的已确认卡会覆盖前面同字段。 |
+| `order_overview.arrival_date` / `departure_date` / `rate_code` / `room_items[]` | 来自已确认 Room Information 卡；后出现的已确认卡会覆盖前面同字段。下一阶段 Room Information 展示模型实现后，可继续从确认快照派生 `nights`、`breakfast_included` 和 Group Booking Status。 |
 | `order_overview.trace_card_status` / `rooming_list_card_status` / `payment_card_status` | 当前订单下对应业务卡最新状态，方便订单详情页展示是否还有待处理事项。 |
 | `order_overview.latest_confirmed_at` | 当前订单 V4 卡片最近确认 UTC 时间。 |
 | `next_v4_action` | 订单详情页下一步处理入口，口径与订单列表 V4 入口一致；前端点击后跳 `/reservation/order-tasks/{order_task_id}`。 |
@@ -511,11 +513,14 @@ GET /api/source-message-conversations/{externalConversationId}
 
 - 该接口已经完成权限收口：请求必须带 `Authorization: Bearer <access_token>`，当前用户必须同时拥有 `SOURCE_MESSAGE_READ` 和 `SOURCE_MESSAGE_ORIGINAL_READ`，后端会按 SourceMessage 实际所属酒店校验访问权。
 - “全部邮件”指同一个 `externalConversationId` 下的历史邮件、当前邮件和后续回复，不是只展示任务对应的单封来源邮件。
+- V4 任务详情页的 `SOURCE_MESSAGE_DISPLAY` 卡如果展示正文，只展示当前触发该 V4 order task 的那一封 SourceMessage；前端应按入口 `sourceMessageId` 在 `messages[]` 中定位对应 `id`，不要把整条会话全部铺在任务详情卡片里。
+- V4 Payment 卡如果展示付款凭证附件，前端先用任务详情里的 `payment_attachments[]` 安全摘要渲染 UI：图片显示缩略图，点击后通过本接口取得受控 `externalUrl` 打开大图预览；非图片统一展示文件名、类型、大小和下载按钮，不在卡片内嵌 PDF / Word / Excel 预览。
 - 邮件会话详情页需要展示完整正文或清洗后的 HTML、附件、内联图片、发件人展示值、发送 / 接收时间、主题和关联订单 / 任务。
 - 前端不在页面上做业务截断或隐藏；但仍只调用本项目后端接口，不直接访问邮箱、AgentBus、数据库或外部附件 URL Secret。
 - 原文读取审计由后端在该业务接口内部处理，actor 使用当前登录用户稳定 ID；前端不保存或传递 `X-TH-Hotel-Source-Original-Read-Key` 一类受控访问 key。
 - 2026-07-08 后端已新增 `html_body_sanitized` 和 `html_render_mode`；前端页面展示邮件 HTML 时应优先使用 `html_body_sanitized`，`html_body` 只作为原始内容兼容字段，不建议生产直渲。
 - 第一版仅处理 HTML 内容清洗；附件和内联图片 URL 来自本系统 OSS 服务，暂不做额外拦截或代理转换。
+- Payment 卡预览 / 下载匹配必须使用后端返回的附件 ID / `externalMediaId`，不能按文件名猜测；前端不得把 `externalUrl` 放进确认 payload、日志、错误上报、URL query 或 localStorage。
 
 建议入参：
 
@@ -1193,4 +1198,6 @@ POST /api/reservation/tasks/{taskId}/order-binding
 - `manual-review-resolutions` 成功响应中的 `opera_operations[]` 数量请后端最终确认；前端不写死两条，只按返回内容刷新展示。
 - 系统管理菜单树增强接口已完成：`GET /api/admin/menus/tree`、`PUT /api/admin/menus/tree-order`。
 - Manual Invoice 第一阶段的客户 / 联系人目录来源、模板初始文件、VAT 配置和生成记录是否必须落库，已在 M009 中列为开发前确认项。
-- V4 真实目录与 Lookup API 第一版已在后端 CP11 落地，前端 CP12 已接入 `GET /api/reservation/lookups/accounts`、`GET /api/reservation/lookups/room-types`、`GET /api/reservation/lookups/rate-codes` 用于 V4 字段选择控件。前端按 `options_source` 选择接口，空列表 / stale / warnings 只做非阻塞提示，确认和复核仍只提交 code；真实 PMS 同步、目录管理后台和 SuperAgent 目录机器接口仍后置。
+- V4 真实目录与 Lookup API 第一版已在后端 CP11 落地，前端 CP12 已接入 `GET /api/reservation/lookups/accounts`、`GET /api/reservation/lookups/room-types`、`GET /api/reservation/lookups/rate-codes` 用于 V4 字段选择控件。前端按 `options_source` 选择接口，空列表 / stale / warnings 只做非阻塞提示，确认和复核仍只提交 code；Rate Code 下一阶段已确认要按 Account + `booking_type` 过滤，前端需等后端新增 `account_code`、`booking_type` 参数和适用性校验后再联动，不能自行硬编码 OWNER RATE Excel；真实 PMS 同步、目录管理后台扩展和 SuperAgent 目录机器接口仍后置。
+- V4 Payment 附件预览下一阶段已确认：后端需补 `payment_attachments[]` 安全摘要；前端图片缩略图 + 点击大图预览，非图片文件列表 + 下载；预览和下载仍走 SourceMessage conversation 原文权限链路。`attachment_ids[]` 第一版作为 Agent 返回的只读业务事实，前端只展示并确认卡片，不做附件集合编辑。
+- V4 复核态交互已确认：`REVIEW_REQUIRED` 不新建独立复核任务卡，仍在原业务卡内编辑当前卡 `fields[]` 白名单业务字段；问题字段红字提示；主按钮文案统一为“确认卡片”，但前端内部调用 `POST /api/reservation/order-tasks/{orderTaskId}/cards/{cardId}/review-resolution`。

docs/project/integrations/superagent-api-contract.md

@@ -124,6 +124,8 @@ SuperAgent 不应知道或依赖内部 SourceMessage Inbox ID，也不需要为
 - Basic Information 必须先确认；业务卡逐卡确认或复核解阻，确认后永久锁定；V4 第一版不提供前端草稿。
 - `route_code=S10/S99` 使用 V4 来源通知模型，不创建隐藏技术订单，不进入订单详情时间线，不阻塞普通订单；前端只展示和 ack。
 - Account / Market / Source、Room Type、Rate Code 以本系统数据库目录稳定代码为准；SuperAgent 不应输出显示文案作为业务判断依据。
+- Rate Code 下一阶段按当前 `order_ref` 的 `basic_information.account_code` + event `target_order.booking_type`（GROUP / FIT）限定候选；SuperAgent 仍只输出稳定 `rate_code`，不输出价格、显示名或目录对象。
+- Room Information 卡的 Nights、Breakfast、Group Booking Status、当前值 / 最终值 / 差异摘要由本系统后端展示模型提供；SuperAgent 不输出这些展示派生字段。
 
 开发阶段不维护 V2/V3 旧任务兼容，测试数据可重建；该策略仅限开发 / 测试阶段，不代表生产迁移方案。生产数据迁移策略不在当前 checkpoint 处理，后续上线前另开迁移方案。
 
@@ -529,7 +531,7 @@ V4 普通业务包示例：
       },
       "arrival_date": "2026-07-26",
       "departure_date": "2026-07-29",
-      "rate_code": "BAR",
+      "rate_code": "GRPA1",
       "booking_scenario": "STANDARD",
       "room_items": [
         {
@@ -586,20 +588,27 @@ V4 字段说明：
 | `message_events[]` | 普通业务必填 | 逐 event 入站，后端按数组顺序处理。 |
 | `message_events[].event_type` | 是 | 第一版支持 `NEW_BOOKING`、`UPDATE_BOOKING`、`CANCEL_BOOKING`、`TRACE_RESERVATION_NOTES`、`ROOMING_LIST`、`PAYMENT`。 |
 | `message_events[].target_order` | 是 | `GROUP + GROUP_CODE`，或 `FIT + BOOKING_CODE / CONFIRMATION_NUMBER`。 |
+| `message_events[].rate_code` | NEW_BOOKING 必填，可为 `null` | Rate Code 稳定 code；下一阶段必须属于同 `order_ref` 的 Basic Information Account + 当前 `booking_type` 的适用范围。 |
 | `message_events[].manual_review` | 是 | 只能是 `null` 或布尔 `true`；`true` 必须能由当前对象中的未解决字段解释。 |
-| `PAYMENT.attachment_ids[]` | PAYMENT 必填 | 必须引用同包 `source_message.attachments[].id`。 |
+| Room Information 展示派生字段 | 不需要 | Nights、Breakfast、Group Booking Status、Adult、Block ID、Confirmation Number、当前订单值和差异摘要均由本系统后端查询或派生；SuperAgent 不输出。 |
+| New Booking 最终订单展示名 | 不需要 | Group Block Name / Fit Name 是信息系统最终订单投影字段，可由用户在 V4 任务卡中确认前编辑；Group 默认来自 `target_order.locator_value` 且 `locator_type=GROUP_CODE`，Fit 默认来自 `guest_name ?? target_order.locator_value`；SuperAgent 仍只输出 `target_order.locator_value` 作为目标定位线索，系统不得回写修改该原始定位值。 |
+| `TRACE_RESERVATION_NOTES.trace_items[].department_code` | Trace 必填 | 第一版固定为 `FO` / `HSK` / `FO+HSK`，不接受自由文本；正式 Department 目录后续再扩展。 |
+| `ROOMING_LIST` 专属业务字段 | 不需要 | 第一版只识别 Rooming List 事项并生成可确认任务卡；SuperAgent 不输出名单 rows、同住分组、附件 ID、Excel 或 PMS 导入参数。 |
+| `PAYMENT.attachment_ids[]` | PAYMENT 必填 | 必须引用同包 `source_message.attachments[].id`；SuperAgent 不在 PAYMENT event 内复制附件名称、URL 或完整附件对象。第一版这些 ID 是只读业务事实，用户只确认卡片，不增删或替换附件集合；前端图片缩略图 / 大图预览和非图片下载由本系统根据这些 ID 匹配 SourceMessage 附件后提供。 |
 
 当前已支持的 V4 行为：
 
 - 命中 SourceMessage 后保存 AI batch / transition，并按 `source_message + order_contexts[] + message_events[]` 处理。
 - 普通业务包按 `source_message + order_ref` 创建 V4 订单任务，并创建 `SOURCE_MESSAGE_DISPLAY`、`BASIC_INFORMATION` 和业务事件卡。
 - Basic Information 必须先确认；业务卡逐卡确认或复核解阻，确认后永久锁定；V4 第一版不提供前端草稿。
+- `ROOM_INFORMATION` 卡只由 `NEW_BOOKING`、`UPDATE_BOOKING`、`CANCEL_BOOKING` 触发；New / Update / Cancel 的最终值、差异、Nights、Breakfast、Group Booking Status 和本地订单投影展示由本系统后端展示模型提供，不扩大 SuperAgent 输入契约。
+- `ROOMING_LIST` 卡第一版只做事项确认；用户点击“确认卡片”表示已人工处理，不代表名单已解析、Excel 已生成或 PMS 已导入。
 - `route_code=S10/S99` 创建 V4 来源通知，工作台可见，订单列表和订单详情不可见；来源通知只能 ack，不创建订单、不阻塞订单。
 - V4 包级结构错误如果仍能通过 `source_message.source_message_id` 定位 SourceMessage，会返回成功接收并写入 `adapter_contract_error` transition；不创建订单任务、任务卡或来源通知。`source_message_id` 缺失或找不到 SourceMessage 时仍返回明确错误。
 - `PAYMENT.attachment_ids[]` 引用不存在的附件、`UPDATE_BOOKING` 携带不允许字段、目录代码无法匹配当前酒店数据库目录，以及其他 V4 event 契约错误，只写 `adapter_contract_error` transition，不创建用户可处理业务任务。
 - 技术契约错误不会自动转为 S10/S99，也不会创建前端可处理业务任务。
 
-当前仍未完成：真实 OPERA / OHIP、真实 PMS / OPERA / OHIP 目录同步、普通任务切换订单、SuperAgent 目录机器接口和前端订单详情 V4 化。
+当前仍未完成：Room Information 卡业务展示模型、Payment 卡附件安全摘要和预览 / 下载联动、Account + booking type 过滤 Rate Code 的后端 lookup / 校验和前端联动、真实 OPERA / OHIP、真实 PMS / OPERA / OHIP 目录同步、普通任务切换订单、SuperAgent 目录机器接口。
 
 ### 8.3 V3 S10/S99 结构化请求体
 
@@ -635,7 +644,7 @@ S10 示例：
 }
 ```
 
-S99 与 S10 使用相同结构，但 `route_code=S99`，`agent_assessment.status=material_package_unavailable`，且 `manual_review` 必须是完整入口复核对象。
+S99 与 S10 使用相同结构，但 `route_code=S99`，`agent_assessment.status=material_package_unavailable`。当前 V4 来源通知第一版不输出入口 `manual_review` 对象，`manual_review` 固定为 `null`；历史 V3 / 0711 入口复核对象只作为兼容资料，不作为 V4 新数据契约。
 
 ### 8.4 V3 业务根请求体
 

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

@@ -16,7 +16,7 @@
 
 本契约用于后续 M002 V4 主流程设计、后端领域建模、前端页面模型、Adapter / MCP Schema 对齐和 SuperAgent 联调。当前后端已按本文完成 V4 入站解析和多卡模型基线：能识别 V4 包、校验关键契约、保存 AI transition / 任务卡原始 payload，并把可映射的六类 event 写入 V4 订单任务和任务卡模型。
 
-V4 订单任务与多卡领域模型的 CP2 设计已经单独落到 `M002-v4-order-task-card-domain-model-cp2.md`。截至 CP14 和停止旧任务双写 checkpoint，表结构、Entity、Mapper、Repository、SuperAgent V4 入站写入、V4 查询、普通卡片确认、S10/S99 ack、V4 复核解阻、数据库目录、Account / Room Type / Rate Code Lookup API、目录管理后台 CP1 后端接口、订单列表 V4 继续处理入口字段，以及 V4 普通业务不再创建旧 `workflow_reservation_task` 已实现。真实 PMS 同步仍后置，方案见 `M002-v4-real-catalog-lookup-api-design.md`。
+V4 订单任务与多卡领域模型的 CP2 设计已经单独落到 `M002-v4-order-task-card-domain-model-cp2.md`。截至 CP14 和停止旧任务双写 checkpoint，表结构、Entity、Mapper、Repository、SuperAgent V4 入站写入、V4 查询、普通卡片确认、S10/S99 ack、V4 复核解阻、数据库目录、Account / Room Type / Rate Code Lookup API、目录管理后台 CP1 后端接口、订单列表 V4 继续处理入口字段，以及 V4 普通业务不再创建旧 `workflow_reservation_task` 已实现。下一阶段已确认 Rate Code 需要按订单级 Account + `booking_type`（GROUP / FIT）过滤和校验，当前实现仍是酒店级 Rate Code 目录；Room Information 卡需要补 New / Update / Cancel 展示模型、Nights / Breakfast 派生、Group Booking Status 和 Rooming List 确认联动，但这些不扩大 SuperAgent 输入字段；Payment 卡需要补付款凭证附件安全摘要和预览 / 下载联动；真实 PMS 同步仍后置，方案见 `M002-v4-real-catalog-lookup-api-design.md`。
 
 当前已确认开发阶段数据可以清空，因此 M002 V4 后续可以按新模型重建，不要求兼容旧任务数据、旧草稿、旧 OPERA 模拟、旧 `S000/S999`、旧 Fallback 或旧 `case_keys`。
 
@@ -154,7 +154,7 @@ SuperAgent、Adapter、MCP Schema 和信息系统最终必须使用完全相同
 
 URL 由上游邮件监听或文件存储层提供。Agent 只原样转发，不生成、拼接、刷新或签发 URL。
 
-Payment 只按 `attachment_ids[]` 引用附件，不在 Event 内复制文件名、类型、URL 或完整附件对象。
+Payment 只按 `attachment_ids[]` 引用附件，不在 Event 内复制文件名、类型、URL 或完整附件对象。前端 Payment 卡的缩略图、预览和下载由本系统根据 `attachment_ids[]` 匹配当前 SourceMessage 附件后展示；这不改变 SuperAgent 输入结构。
 
 ## 7. order_contexts
 
@@ -199,7 +199,7 @@ Agent 给出非空 `account_code`，但信息系统运行时目录不存在该
 - Market / Source：由 Account 派生，当前分别为 `LEISURE` / `TRAVEL_AGENT`。
 - SuperAgent 不需要输出 `market_code`、`source_code`、`account_name`，也不要输出显示名称替代 `account_code`。
 - 如果 SuperAgent 输出的 `account_code` 不在上述目录，后端会创建 `REVIEW_REQUIRED` Basic Information 卡，并在 `validation_errors_json` / 查询 `fields[].validation_errors` 中返回目录错误。
-- 如果 SuperAgent 输出的业务卡 `room_items[].room_type_code` 或 `rate_code` 不在当前酒店数据库目录，后端会创建 `REVIEW_REQUIRED` 业务卡，并在 `validation_errors_json` / 查询 `fields[].validation_errors` 中返回目录错误；用户可通过 V4 复核解阻接口提交对应字段 pointer 修正。
+- 如果 SuperAgent 输出的业务卡 `room_items[].room_type_code` 或 `rate_code` 不在当前酒店数据库目录，后端会创建 `REVIEW_REQUIRED` 业务卡，并在 `validation_errors_json` / 查询 `fields[].validation_errors` 中返回目录错误；下一阶段 `rate_code` 还必须属于该 `order_ref` 的 Basic Information Account + 当前 event `target_order.booking_type` 的适用关系，否则同样进入 `REVIEW_REQUIRED`。用户可通过 V4 复核解阻接口提交对应字段 pointer 修正。
 
 ## 8. message_events 公共字段
 
@@ -336,7 +336,7 @@ Fit 条件字段：
 | --- | --- | --- | --- |
 | `arrival_date` | Group / Fit | 是，可为 `null` | 入住日期，酒店本地日期 |
 | `departure_date` | Group / Fit | 是，可为 `null` | 离店日期，酒店本地日期 |
-| `rate_code` | Group / Fit | 是，可为 `null` | 订单级 Rate Code |
+| `rate_code` | Group / Fit | 是，可为 `null` | 订单级 Rate Code；下一阶段必须属于该订单 Account + `booking_type` 的适用范围 |
 | `room_items[]` | Group / Fit | 是 | 完整房型清单 |
 | `room_items[].room_type_code` | Group / Fit | 是，可为 `null` | 受控 RoomType code |
 | `room_items[].room_count` | Group / Fit | 是 | 房量，正整数 |
@@ -347,9 +347,10 @@ Fit 条件字段：
 
 - Group Code 已在 `target_order.locator_value`，同时作为 Block Name。
 - Fit Booking Code 已在 `target_order.locator_value`。
-- Agent 不输出 `booking_name`、独立 `booking_code`、Nights、Breakfast、Group Booking Status、Adult、Block ID 或 Confirmation Number。
+- Agent 不输出 `booking_name`、独立 `booking_code`、Nights、Breakfast、Group Booking Status、Adult、Block ID 或 Confirmation Number；这些属于本系统 Room Information 展示模型、系统派生字段、本地订单投影或未来 PMS 返回。New Booking 页面允许用户编辑最终订单投影字段 `group_block_name` / `fit_name`，但不改写 Agent 原始 `target_order.locator_value`。
 - `proposal` 不再使用布尔字段，改为 `booking_scenario=STANDARD | PROPOSAL`。
-- Adult 由信息系统按 RoomType 映射派生。
+- Adult 第一版不在 Room Information 卡展示。
+- New Group 的 Group Booking Status 由本系统默认 `TEN`，`booking_scenario` 只作为 Agent 场景参考，不映射 Group Booking Status。
 - `room_items=[]` 只能表示已识别 New 但完整房型清单未解决，并必须 `manual_review=true`。
 
 ## 12. UPDATE_BOOKING
@@ -399,7 +400,7 @@ Fit 条件字段：
 - 不使用空数组表达“无法形成完整房型清单”。
 - 如果修改后整笔订单不再保留任何房间，应按整单 `CANCEL_BOOKING` 处理，而不是提交空的 Update 房型清单。
 - Rate Code 不允许出现在 Update。若 Agent 仍输出，按业务契约错误处理，不能静默忽略后继续执行。
-- Before、原订单和完整最新订单由信息系统查单后生成，不由 Agent 输出。
+- Before、原订单和完整最新订单由信息系统查单后生成，不由 Agent 输出。Room Information 展示模型中的 `change_summary[]`、最终值、Nights 和 Breakfast 由本系统按本地订单投影 + Agent `after` 合并后派生。
 
 ## 13. CANCEL_BOOKING
 
@@ -423,7 +424,7 @@ Fit 条件字段：
 - `CANCEL_BOOKING` 本身已经表示整单取消。
 - 不输出 `cancel_scope`、`cancel_reason`、`after` 或当前订单快照。
 - 减少房量、删除房型、修改日期或修改 Fit Name 属于 Update，不是 Cancel。
-- 当前订单快照由信息系统查单后只读展示。
+- 当前订单快照由信息系统查单后只读展示。Cancel 的 Room Information 卡只读显示本地订单投影，不由 Agent 输出当前值。
 
 ## 14. TRACE_RESERVATION_NOTES
 
@@ -462,7 +463,7 @@ Fit 条件字段：
 | `trace_items[]` | Trace | 是 | 同一订单一张 Trace 卡，卡内多条事项 |
 | `item_type` | Trace item | 是 | `GENERAL` 或 `EXTRA_BED` |
 | `text` | GENERAL | 是，可为 `null` | 普通备注内容 |
-| `department_code` | GENERAL / EXTRA_BED | 是 | 信息系统受控部门或组合部门 code |
+| `department_code` | GENERAL / EXTRA_BED | 是 | 第一版固定为 `FO` / `HSK` / `FO+HSK`，分别表示前厅、客房和前厅 + 客房组合 |
 | `target_room_type_code` | EXTRA_BED | 是，可为 `null` | 加床目标房型 |
 | `extra_bed_room_count` | EXTRA_BED | 是 | 加床房间数量 |
 
@@ -470,7 +471,7 @@ Fit 条件字段：
 
 - EXTRA_BED 不输出自由 `content`；信息系统固定显示 `SET EXTRA BED`。
 - EXTRA_BED 不输出 `adult_after_extra_bed`；信息系统按当前 / 基础 Adult +1 计算，页面确认前允许用户纠正。
-- Department code 由 Agent 必传，值来自信息系统维护的受控部门目录或组合目录。
+- Department code 由 Agent 必传。第一版先固定为 `FO`、`HSK`、`FO+HSK` 三个值，不接受自由文本；正式 Department 目录和 lookup API 后续单独扩展。
 - 加床目标房型不在当前订单时，Trace 卡不能确认，并提示用户核对目标房型和订单关联。
 - 只有订单定位本身不可信时，才触发共享查单门槛阻断整个订单上下文。
 
@@ -498,7 +499,8 @@ Fit 条件字段：
 - 不输出 `rows[]`、逐人名单、同住分组、18 列、Excel 或 PMS 导入参数。
 - 当前也不要求 Rooming List Event 单独输出 `attachment_ids[]`。
 - 原附件已经在包级 `source_message.attachments[]`，只在邮件展示卡查看。
-- 页面固定展示 12 个必填字段表头的标准表格示意，当前内容不代表附件已经真实转换。
+- 页面第一版只展示 Rooming List 事项卡和“确认卡片”按钮；用户确认表示已人工处理该事项。
+- Rooming List 卡确认不代表名单已解析、Excel 已生成或 PMS 已导入。
 - 未来取得 PMS API 后，按真实接口重新冻结住客与执行参数，不直接恢复历史草案中的 `rows[]`。
 
 ## 16. PAYMENT
@@ -528,6 +530,7 @@ Fit 条件字段：
 - 一笔订单多份凭证放在同一个 Payment Event。
 - `attachment_ids[]` 没有业务顺序。
 - Payment 不输出 `account_code`、金额、付款日期、付款人、交易号、银行账号、付款状态、Department 或完整附件对象。
+- Payment 卡展示层下一阶段可由后端补 `payment_attachments[]` 安全摘要：图片显示缩略图并支持点击大图预览，非图片显示文件列表并提供下载；附件外链不进入 V4 任务详情普通 payload，只能通过 SourceMessage 原文权限链路读取。
 
 没有任何凭证附件时，不能创建正常的空 Payment 卡：
 
@@ -629,17 +632,18 @@ true
 
 ## 20. 受控 code 目录
 
-Account、RoomType、RateCode、Department 的目录由信息系统或其主数据服务统一维护，并作为唯一事实源。
+Account、RoomType、RateCode 的目录由信息系统或其主数据服务统一维护，并作为唯一事实源。Department 第一版先固定 `FO`、`HSK`、`FO+HSK` 三个 code；正式 Department 目录、系统管理维护和 lookup API 后续单独扩展。
 
 规则：
 
-- SuperAgent 只能输出目录中已有的稳定 code。
+- SuperAgent 只能输出目录中已有的稳定 code；Trace `department_code` 在 Department 目录未正式落地前只能输出 `FO`、`HSK`、`FO+HSK`。
+- SuperAgent 输出 `rate_code` 时必须结合当前 `order_ref` 的 `basic_information.account_code` 和 event `target_order.booking_type` 判断候选范围；本阶段只要求 Account + GROUP/FIT，不要求按房型、入住日期或价格计算。
 - 不允许输出自由文本或自行创造 code。
 - Agent 无法可靠匹配时，按对应业务字段的未解决规则处理。
 - Agent 输出非空 code、但信息系统目录不存在该值时，属于目录校验或契约问题。
 - Market 和 Source 由信息系统根据订单级 `account_code` 派生，不由 Agent 输出。
 
-当前项目接受“SuperAgent 确定后把目录给本系统”的落地方式。第一阶段已用固定种子目录完成开发闭环；真实目录、系统管理维护、PMS / OPERA / OHIP 同步、前端 lookup API、缓存、权限和兜底策略已在 `M002-v4-real-catalog-lookup-api-design.md` 中设计。该设计不改变 SuperAgent V4 输入契约：SuperAgent 仍只输出稳定 code，不输出显示名或自由文本。
+当前项目接受“SuperAgent 确定后把目录给本系统”的落地方式。第一阶段已用固定种子目录完成开发闭环；真实目录、系统管理维护、PMS / OPERA / OHIP 同步、前端 lookup API、缓存、权限和兜底策略已在 `M002-v4-real-catalog-lookup-api-design.md` 中设计。Account 范围 Rate Code 不改变 SuperAgent V4 输入结构：SuperAgent 仍只输出稳定 `rate_code`，不输出显示名、价格或目录完整对象；适用性由本系统后端目录服务最终校验。
 
 ## 21. 后端 V4 建模建议
 
@@ -691,7 +695,7 @@ AI 回调包
 1. SuperAgent、Adapter、MCP Schema 和信息系统 DTO 使用同一份 V4 Schema。
 2. `body_content_type` 的来源是 AgentBus / 邮件监听层还是 Adapter 派生。
 3. `dispatch_run_id`、超时、错误 channel 和技术失败查询入口如何落地。
-4. Account、RoomType、RateCode、Department 目录如何提供给 SuperAgent，仍需在真实目录实现后确认是离线目录包还是独立机器接口。
+4. Account、RoomType、RateCode 目录如何提供给 SuperAgent，仍需在真实目录实现后确认是离线目录包还是独立机器接口；Department 暂按 `FO`、`HSK`、`FO+HSK` 固定枚举处理。
 5. 如需 `event_id` 或幂等键，应作为 transport 字段设计，不作为业务页面字段。
 
 ## 24. 当前开发结论
@@ -717,6 +721,8 @@ AI 回调包
 - V4 `route_code=S10/S99` 写入 `workflow_reservation_v4_source_notification` 来源通知模型；旧 `SOURCE_MESSAGE_ONLY` 只读特殊任务仅保留给 V3 S10/S99 和旧 S000/S999 兼容数据。
 - 普通业务包要求 `route_code=null`，并按 `message_events[]` 数组顺序处理。
 - 第一版识别六类 `event_type`：`NEW_BOOKING`、`UPDATE_BOOKING`、`CANCEL_BOOKING`、`TRACE_RESERVATION_NOTES`、`ROOMING_LIST`、`PAYMENT`。
+- `ROOM_INFORMATION` 卡只由 `NEW_BOOKING`、`UPDATE_BOOKING`、`CANCEL_BOOKING` 触发；Nights、Breakfast、Group Booking Status、Block ID、Confirmation Number 和本地当前值展示均由本系统后端展示模型派生或查询，不扩大 SuperAgent 输出字段。
+- `ROOMING_LIST` 第一版只表达 Rooming List 事项需要人工处理，确认卡片即表示人工已处理；不承载名单解析、附件预览、Excel 生成或 PMS 导入语义。
 - 能映射到现有稳定任务卡的 event 会创建业务任务，并在 `ai_payload_json` 中保存 `v4_source_message`、`v4_order_context`、`v4_message_event`、`route_code`、系统处理分类和 `field_contract_version=20260718-v4`。
 - V4 入站校验和路由已拆分为独立 Validator / Router，主业务 service 只负责编排、幂等和落库。
 - V4 包级契约错误在 SourceMessage 可定位时只写 `adapter_contract_error` transition，不创建订单、任务或用户可处理卡。
@@ -741,13 +747,14 @@ AI 回调包
 - `POST /api/reservation/order-tasks/{orderTaskId}/cards/{cardId}/confirm` 确认 V4 卡片，强制 Bearer 登录、`RESERVATION_TASK_CONFIRM`、酒店访问权和 version 并发校验。
 - `POST /api/reservation/source-notifications/{notificationId}/ack` 确认 V4 S10/S99 来源通知已读 / 已处理，强制 Bearer 登录、`RESERVATION_TASK_CONFIRM`、酒店访问权和 version 并发校验。
 - CP7 已完成 `POST /api/reservation/order-tasks/{orderTaskId}/cards/{cardId}/review-resolution` 复核解阻和复核场景订单归属确认。
-- CP8 已完成 Account / Room Type / Rate Code 目录校验和 V4 任务卡 `fields[]` 白名单；CP11 已把固定种子导入数据库目录并开放 Account / Room Type / Rate Code lookup API；CP13 已完成目录管理后台 CP1；CP14 已在 `GET /api/reservation/orders` 补齐 V4 下一步处理入口字段。真实 PMS 同步仍未实现。
+- CP8 已完成 Account / Room Type / Rate Code 目录校验和 V4 任务卡 `fields[]` 白名单；CP11 已把固定种子导入数据库目录并开放 Account / Room Type / Rate Code lookup API；CP13 已完成目录管理后台 CP1；CP14 已在 `GET /api/reservation/orders` 补齐 V4 下一步处理入口字段。Account + booking type 过滤 Rate Code 已确认为下一阶段待实现；真实 PMS 同步仍未实现。
 
 当前仍未完成：
 
-- 普通 V4 业务包暂时仍保留旧 V3 任务状态、草稿和 OPERA 模拟骨架兼容，便于前端过渡；V4 写接口和前端页面完成后再逐步废弃旧链路。
+- Account + booking type 过滤 Rate Code 的后端 lookup / 适用性校验和前端联动。
+- Payment 卡付款凭证附件安全摘要、图片缩略图 / 大图预览、非图片文件列表 + 下载联动。
 - 尚未接入真实 PMS / OPERA / OHIP。
-- 尚未改造前端 V4 页面模型。
+- SuperAgent 目录机器接口和生产目录同步方案仍后置。
 
 ## 26. 后端 CP2 设计文档状态
 

docs/project/requirements/M002-v4-order-task-card-domain-model-cp2.md

@@ -16,7 +16,7 @@ M002 V4 CP1 已完成 SuperAgent V4 回调包入站解析、基础校验、路
 
 本文是 CP2 设计文档，用于把 2026-07-18 V4 字段契约落成后续可开发的数据模型和接口草案。
 
-截至 CP14、V4 业务审计查询和停止旧任务双写补齐，后端已实现本文第 10、11、12 节中的持久化和查询基线，并已把 SuperAgent V4 入站结果写入新表：普通业务包只创建 V4 订单任务、来源邮件展示卡、Basic Information 卡和业务卡，不再创建旧 `workflow_reservation_task`；V4 S10/S99 创建来源通知。当前已开放 V4 工作台、订单任务列表 / 详情、来源通知详情查询接口、订单详情 V4 订单任务时间线、V4 卡片确认接口、S10/S99 来源通知 ack 接口、V4 `REVIEW_REQUIRED` 卡复核解阻接口、V4 订单任务 / 来源通知审计查询接口、当前酒店数据库目录校验、卡片 `fields[]` 白名单、Account / Room Type / Rate Code lookup API、目录管理后台 CP1，以及订单列表 V4 继续处理入口字段。真实 PMS 同步继续后置，设计见 `M002-v4-real-catalog-lookup-api-design.md`。
+截至 CP14、V4 业务审计查询和停止旧任务双写补齐，后端已实现本文第 10、11、12 节中的持久化和查询基线，并已把 SuperAgent V4 入站结果写入新表：普通业务包只创建 V4 订单任务、来源邮件展示卡、Basic Information 卡和业务卡，不再创建旧 `workflow_reservation_task`；V4 S10/S99 创建来源通知。当前已开放 V4 工作台、订单任务列表 / 详情、来源通知详情查询接口、订单详情 V4 订单任务时间线、V4 卡片确认接口、S10/S99 来源通知 ack 接口、V4 `REVIEW_REQUIRED` 卡复核解阻接口、V4 订单任务 / 来源通知审计查询接口、当前酒店数据库目录校验、卡片 `fields[]` 白名单、Account / Room Type / Rate Code lookup API、目录管理后台 CP1，以及订单列表 V4 继续处理入口字段。下一阶段已确认 Rate Code 需要按订单级 Account + `booking_type`（GROUP / FIT）过滤和校验，当前后端 CP11 实现仍是酒店级 Rate Code 目录，是待补齐缺口；Room Information 卡需要补 New / Update / Cancel 业务展示模型、Nights / Breakfast 派生、Group Booking Status 和 Rooming List 确认联动；Payment 卡下一阶段需要展示付款凭证附件，图片为缩略图 + 点击大图预览，非图片为文件列表 + 下载，但附件 URL 仍必须走 SourceMessage 原文权限链路；真实 PMS 同步继续后置，设计见 `M002-v4-real-catalog-lookup-api-design.md`。
 
 后续如本文与 `M002-v4-agent-callback-field-contract.md` 的字段契约冲突，以字段契约为准；如与安全边界冲突，以 `security-access-control-boundary.md` 为准。
 
@@ -89,10 +89,10 @@ V4 package / event contract error
 | `SOURCE_MESSAGE_DISPLAY` | `source_message` | 否 | 否 | 普通业务包内固定展示当前邮件和附件入口 |
 | `SOURCE_MESSAGE_NOTIFICATION` | `route_code=S10` | 是，仅确认已读 | 否 | 纯通知邮件，只需要用户确认已读 / 已处理 |
 | `BASIC_INFORMATION` | `order_contexts[].basic_information` | 是 | 是 | 订单级 Account / Market / Source 卡，第一版 Agent 只给 `account_code` |
-| `ROOM_INFORMATION` | `NEW_BOOKING` / `UPDATE_BOOKING` / `CANCEL_BOOKING` | 是 | 是 | 房间信息卡，卡内根据 event_type 展示新建、修改或整单取消字段 |
+| `ROOM_INFORMATION` | `NEW_BOOKING` / `UPDATE_BOOKING` / `CANCEL_BOOKING` | 是 | 是 | 房型信息卡，卡内按 New / Update / Cancel 展示最终值、差异和系统派生字段 |
 | `TRACE_RESERVATION_NOTES` | `TRACE_RESERVATION_NOTES` | 是 | 是 | Trace 卡，卡内可有普通备注和加床备注多条事项 |
-| `ROOMING_LIST` | `ROOMING_LIST` | 是 | 第一版可只读或确认 | 识别到 Rooming List 任务，不在 Agent 回调里保存名单 rows |
-| `PAYMENT` | `PAYMENT` | 是 | 第一版主要确认附件关联 | 付款凭证卡，只按 `attachment_ids[]` 引用包级附件 |
+| `ROOMING_LIST` | `ROOMING_LIST` | 是 | 否 | 第一版只做事项确认；不在 Agent 回调里保存名单 rows，不生成 Excel，不导入 PMS |
+| `PAYMENT` | `PAYMENT` | 是 | 第一版主要确认附件关联 | 付款凭证卡；业务事实仍是 `attachment_ids[]` 引用包级附件，展示层可返回匹配后的附件安全摘要 |
 
 说明：
 
@@ -173,7 +173,7 @@ V4 新数据不再提供后端草稿保存。前端可以在页面本地维护
 - 用户修正写入 `review_resolution_json` 和 `confirmed_payload_json`。
 - CP11 起确认和复核都会校验当前酒店数据库目录字段；Basic Information 的 `account_code` 必须来自当前酒店 ACTIVE Account 目录，通过后后端派生 `market_code` / `source_code`。
 - 通过校验后卡片直接进入 `CONFIRMED`，不再进入 V3 `READY` 状态。
-- `field_overrides[].field_pointer` 必须是当前卡 `display_payload_json` 中允许编辑的 RFC 6901 JSON Pointer；如果当前卡展示 payload 中存在显式 `missing_fields[]`，只允许提交该清单内的 pointer；如果没有显式清单，第一版只允许 `basic_information.*` 或 `business_fields.*` 下已经存在且值为 `null` / 空字符串的未解决叶子字段，或后端 `validation_errors_json` 指向的目录错误字段，不允许替换对象或数组。
+- `field_overrides[].field_pointer` 必须是当前卡 `fields[]` 白名单中允许编辑的 RFC 6901 JSON Pointer。`REVIEW_REQUIRED` 是整张原业务卡的复核状态，前端仍在原卡片内展示业务表单，问题字段用红字 / `validation_errors` 强调；用户可修改当前卡业务白名单内字段，不再限定只能改空值、`missing_fields[]` 或目录错误字段。
 - 来源消息、路由、订单定位关系、诊断、缺失字段清单、`manual_review`、raw evidence 等只读字段不得提交。
 - 如果订单任务归属未解决，复核请求必须提交 `confirmed_order_id`；后端按当前订单任务酒店校验该订单存在、非逻辑删除且不是系统隐藏订单。
 - 如果订单任务已经有 `order_id` 且 `target_resolution_status=RESOLVED`，复核请求不能提交不同的 `confirmed_order_id`，否则返回 `V4_ORDER_REBIND_NOT_ALLOWED`；普通任务任意切换订单继续后置。
@@ -203,9 +203,9 @@ CP11 数据库初始化种子：
 | Market | 由 Account 派生，当前固定为 `LEISURE` |
 | Source | 由 Account 派生，当前固定为 `TRAVEL_AGENT` |
 | Room Type | `TWN`、`KING`、`DBL`、`SGL`、`TRP`、`RM1`、`RM2`、`RM3` |
-| Rate Code | `BAR`、`RACK`、`PACKAGE`、`GROUP`、`FIT` |
+| Rate Code | `BAR`、`RACK`、`PACKAGE`、`GROUP`、`FIT`；下一阶段候选需按 Account + `booking_type` 过滤 |
 
-说明：Room Type / Rate Code 当前只作为确认和字段控件的第一版校验 / 选项来源代码；已开放 `GET /api/reservation/lookups/accounts|room-types|rate-codes`，但尚未接真实 PMS 房型目录、Rate Code 配置中心、目录管理后台或同步 run。
+说明：Room Type / Rate Code 当前只作为确认和字段控件的第一版校验 / 选项来源代码；已开放 `GET /api/reservation/lookups/accounts|room-types|rate-codes`。Rate Code 下一阶段需引入 Account + `booking_type` 适用关系，前端不再展示全酒店 Rate Code 全量候选；房型 / 日期 / 价格过滤、真实 PMS 房型目录、Rate Code 配置中心和同步 run 后置。
 
 ## 8. 订单归属和 target_order
 
@@ -251,20 +251,23 @@ V4 当前不做 OPERA / PMS 执行，但仍需要保留同订单处理顺序，
 推荐固定顺序：
 
 ```text
-10 SOURCE_MESSAGE_DISPLAY
-20 BASIC_INFORMATION
+10 BASIC_INFORMATION
 30 ROOM_INFORMATION
 40 TRACE_RESERVATION_NOTES
 50 ROOMING_LIST
 60 PAYMENT
+90 SOURCE_MESSAGE_DISPLAY
 ```
 
 规则：
 
-- `SOURCE_MESSAGE_DISPLAY` 只读，不阻塞。
 - `BASIC_INFORMATION` 未确认时，其它业务卡只能查看，不能确认。
 - 除 Basic Information 必须先确认外，第一版不强制业务卡之间逐张顺序确认；业务卡可独立确认，但页面仍按固定顺序展示。
 - 同类型多张业务卡按 `source_event_index` 排序。
+- `SOURCE_MESSAGE_DISPLAY` 只读、不阻塞，V4 任务详情页固定放在最下方，用于查看当前触发该订单任务的 SourceMessage 正文和附件摘要。
+- Trace 卡 `trace_items[].department_code` 第一版固定为 `FO`、`HSK`、`FO+HSK` 三个值；前端可先做固定下拉，后端正式 Department 目录、lookup API 和目录校验后续单独 checkpoint 扩展。
+- Rooming List 卡第一版没有可编辑业务字段；页面展示为轻量事项确认卡，用户点击“确认卡片”仅表示已人工处理当前 Rooming List 事项，不代表名单已解析、Excel 已生成或 PMS 已导入。
+- Room Information 卡下一阶段采用业务展示模型，不再只依赖通用 `fields[]` 扁平渲染；具体规则见“Room Information 卡展示模型”。
 
 ### 9.2 同一本地订单下多个订单任务
 
@@ -560,7 +563,54 @@ GET /api/reservation/order-tasks/{orderTaskId}
 
 来源邮件摘要必须按当前查询酒店过滤。如果 V4 订单任务因脏引用指向了其它酒店的 SourceMessage，详情接口只能返回该 `source_message_id` 的空摘要占位，不得透出对方酒店的主题、外部消息 ID、发件人或会话信息。
 
-前端 V4 来源消息卡只展示来源邮件安全摘要、邮件片段和附件名称 / 类型 / 大小等非 URL 摘要；如果 `source_message_card.display_payload` 中的 `attachments`、`uploaded_media` 或 `file_references` 异常包含直接 URL 字符串，前端必须兜底显示为未命名附件或隐藏，不能在普通业务页面渲染具体 URL。
+V4 任务详情页的 `SOURCE_MESSAGE_DISPLAY` 固定展示在 Basic Information 和业务卡之后。该卡在页面上应展示“当前触发这条 V4 order task 的那封 SourceMessage 正文”，但正文不由本接口直接返回；前端应使用 `source_message_summary.source_message_id` 调用 `GET /api/source-messages/{sourceMessageId}/conversation`，并在同会话结果中定位当前 SourceMessage。HTML 邮件优先使用 `html_body_sanitized`，纯文本邮件使用 `text_body`；如果用户缺少 `SOURCE_MESSAGE_ORIGINAL_READ` 或会话接口失败，降级展示安全摘要和查看邮件会话入口。
+
+来源邮件卡附件仍只展示名称 / 类型 / 大小等非 URL 摘要；如果 `source_message_card.display_payload`、会话返回的附件或内联媒体中包含直接 URL 字符串，前端不得在 V4 任务详情普通卡片区域直接渲染具体 URL，附件外链只能在 SourceMessage 原文权限链路中按既有规则处理。
+
+Room Information 卡展示模型：
+
+- `ROOM_INFORMATION` 卡只由 `NEW_BOOKING`、`UPDATE_BOOKING`、`CANCEL_BOOKING` 三类 event 触发；`TRACE_RESERVATION_NOTES`、`ROOMING_LIST`、`PAYMENT` 不触发房型信息卡。
+- SuperAgent 仍只输出字段契约中的业务字段。Nights、Breakfast、Group Booking Status、Block ID、Confirmation Number 和 Adult 不由 SuperAgent 输出；其中 Adult 第一版不在卡内展示。
+- 后端下一阶段应在 V4 任务详情中为 Room Information 卡补展示模型，建议拆为 `current_values`、`proposed_values`、`final_values`、`change_summary[]`、`derived_fields` 和 `field_controls`。前端按该展示模型渲染业务 UI，`fields[]` 继续作为确认 / 复核的可编辑字段白名单。
+- `NEW_BOOKING`：卡片展示创建后的最终值。Agent 提供 `target_order`、`arrival_date`、`departure_date`、`rate_code`、`booking_scenario`、`room_items[]`，Fit 可提供 `guest_name`；后端派生 `nights`、`breakfast_included` 和 Group Booking Status。
+- `UPDATE_BOOKING`：后端从本地订单投影读取当前值，用 Agent `after` 合并得到最终值；页面上方展示本次实际变化的 `change_summary[]`，例如 `入住日期：2026-07-12 -> 2026-07-20`。如果日期变化导致 `nights` 变化，`nights` 也必须出现在差异区；字段区展示合并后的最终值。
+- `CANCEL_BOOKING`：不使用 Agent 输出当前订单快照；后端从本地订单投影读取当前值并只读展示，用户只确认整单取消。Cancel 卡不允许编辑 Group Booking Status、Breakfast、日期、Rate Code 或房型房量。
+- `nights` 由后端按酒店本地业务日期计算：`departure_date - arrival_date`，不涉及时区和 UTC；日期缺失、非法或差值小于等于 0 时，`nights` 为空并阻止确认。
+- `breakfast_included` 是卡片展示和确认使用的布尔字段。Group 固定含早，前端显示勾选且只读；Fit 按 Rate Code 派生，Rate Code 包含 `RB` 时含早，包含 `RO` 时不含早；如果 Rate Code 无法派生，前端显示必填勾选框，由用户确认是否含早。
+- Group Booking Status 仅 Group 显示，稳定 code 为 `TEN`、`DEF`、`INQ`，前端显示 `TEN-Tentative`、`DEF-Definite`、`INQ-Inquiry`。New Group 默认 `TEN`；`booking_scenario=STANDARD | PROPOSAL` 仅保留为 Agent 场景参考，不映射 Group Booking Status。`NEW_BOOKING` / `UPDATE_BOOKING` 确认前可手动改选，`CANCEL_BOOKING` 只读。
+- `ROOMING_LIST` 卡确认时，如果同订单为 Group，后端应把 Group Booking Status 自动置为 `DEF`，即使此前为 `TEN` 或 `INQ`；该自动变更应写入审计。Fit 不显示也不变更 Group Booking Status。
+- `target_order.locator_value` 不作为前端可编辑字段；订单归属错误时通过 V4 复核选择正确订单或创建正确订单投影，不直接改写 Agent 原始 `target_order.locator_value`。但 New Booking 创建 / 确认的最终订单投影字段允许编辑：Group 显示并允许编辑 `group_block_name`，默认值来自 `target_order.locator_value` 且 `locator_type=GROUP_CODE`；Fit 显示并允许编辑 `fit_name`，默认值来自 `guest_name ?? target_order.locator_value`。用户修改这些字段只影响本系统最终订单投影和确认快照，不回写 Agent 原始定位字段。
+- Block ID 和 Confirmation Number 第一版只读；存在本地投影或未来 PMS 结果时展示，否则为空。Block ID 仅 Group 显示，Confirmation Number 仅 Fit 显示。
+
+V4 任务详情页第一版字段白名单：
+
+| 卡片 | 可编辑字段 | 只读 / 派生字段 |
+| --- | --- | --- |
+| `BASIC_INFORMATION` | `basic_information.account_code` | `market_code`、`source_code`、Account 显示名等由后端按 Account 目录派生 |
+| `ROOM_INFORMATION` / `NEW_BOOKING` | `group_block_name` 或 `fit_name`、`arrival_date`、`departure_date`、`rate_code`、`room_items[].room_type_code`、`room_items[].room_count`、Group 的 `group_booking_status`、无法从 Fit Rate Code 派生时的 `breakfast_included` | `nights`、Group 固定 `breakfast_included=true`、Fit 可由 Rate Code 派生的 `breakfast_included`、Adult、Block ID、Confirmation Number、Agent 原始 `target_order` |
+| `ROOM_INFORMATION` / `UPDATE_BOOKING` | 修改后的 `arrival_date`、`departure_date`、`room_items[].room_type_code`、`room_items[].room_count`、Group 的 `group_booking_status`、无法从 Fit Rate Code 派生时的 `breakfast_included` | 当前值、本次变化摘要、`nights` 差异、Rate Code、Adult、Block ID、Confirmation Number、Agent 原始 `target_order` |
+| `ROOM_INFORMATION` / `CANCEL_BOOKING` | 无；用户只确认取消事项 | 本地订单投影当前值、`nights`、`breakfast_included`、Group Booking Status、Rate Code、房型房量、Block ID、Confirmation Number |
+| `TRACE_RESERVATION_NOTES` | `trace_items[].content`、`trace_items[].department_code` | Department 第一版只允许 `FO`、`HSK`、`FO+HSK`，不允许自由文本 |
+| `ROOMING_LIST` | 无；用户只确认 Rooming List 事项 | 来源邮件正文和附件摘要通过底部 `SOURCE_MESSAGE_DISPLAY` 查看；确认后 Group 自动置为 `DEF` |
+| `PAYMENT` | 无；用户只确认附件关联事项 | `attachment_ids[]`、`payment_attachments[]` 安全摘要、图片缩略图、文件名、类型、大小、预览 / 下载可用性 |
+| `SOURCE_MESSAGE_DISPLAY` | 无 | 当前触发该 V4 order task 的 SourceMessage 正文，只读且默认长度折叠，可展开全文 |
+
+Rooming List 卡事项确认规则：
+
+- Rooming List 卡第一版只做事项确认，不做名单解析、附件预览、Excel 生成或 PMS 导入。
+- `ROOMING_LIST` event 不输出 `rows[]`、逐人名单、同住分组、18 列、Excel 或 PMS 导入参数，也不要求单独输出 `attachment_ids[]`。
+- 页面应展示卡片标题、状态、目标订单信息和“确认卡片”按钮；如需查看来源内容，仍通过本订单任务底部的 `SOURCE_MESSAGE_DISPLAY` 查看当前触发 SourceMessage 正文和附件摘要。
+- 用户点击“确认卡片”表示已人工处理该 Rooming List 事项；该确认只更新 V4 卡片状态和订单任务派生状态，不代表 M010 Rooming List Excel 已生成，也不代表 PMS / OPERA / OHIP 已执行。
+- 独立 Rooming List Excel 生成能力仍属于 M010 `/reservation/rooming-lists/new` 工具页面，第一版不嵌入 V4 Rooming List 卡。
+
+Payment 卡附件展示规则：
+
+- Payment 卡业务字段仍以 Agent 返回的 `attachment_ids[]` 为准，用于确认这些附件是否为当前订单付款凭证；这不代表已收款、已入账或付款状态已确认。第一版 `attachment_ids[]` 是只读业务事实，前端展示后只允许“确认卡片”，不允许用户增删、替换或重新选择附件集合。
+- 后端下一阶段应在 Payment 卡 `display_payload` 中补 `payment_attachments[]` 安全摘要，由 `attachment_ids[]` 匹配当前触发 SourceMessage 的包级附件生成。建议字段为 `attachment_id`、`file_name`、`content_type`、`size_bytes`、`is_image`、`preview_available`、`download_available`，可选 `external_media_id`；不得包含 `externalUrl`、OSS URL、签名参数或附件原始二进制。
+- 图片判断以 `content_type` 以 `image/` 开头为主；图片在 Payment 卡内展示缩略图，点击后打开大图预览。缩略图和大图实际 URL 不从 `GET /api/reservation/order-tasks/{orderTaskId}` 返回，前端必须在具备 `SOURCE_MESSAGE_READ + SOURCE_MESSAGE_ORIGINAL_READ` 时调用 `GET /api/source-messages/{sourceMessageId}/conversation`，定位当前 SourceMessage 后按 `external_media_id` / `attachment_id` 匹配对应附件。
+- 非图片附件统一显示文件列表，至少展示文件名、类型和大小，并提供下载动作；第一版不在 Payment 卡内嵌 PDF、Word、Excel 或压缩包预览。
+- 入站 `PAYMENT.attachment_ids[]` 无法匹配同包 `source_message.attachments[].id` 时，不创建用户可处理 Payment 卡，只写 `adapter_contract_error` transition 或按 S10 / 技术异常规则处理。只有 `attachment_ids[]` 已合法匹配、但用户缺少原文读取权限、会话接口失败、附件 URL 缺失或媒体预览链路暂不可用时，Payment 卡才展示安全摘要和“无法预览 / 无法下载”的状态，不应把附件 URL 或错误详情暴露给普通用户。
+- 前端不得把附件外链写入日志、错误上报、URL query、localStorage 或确认 payload；Payment 第一版确认卡片时只提交 `version` 和必要审计说明，不提交 `attachment_ids[]`、附件 URL 或完整附件对象。后续如需支持人工选择 / 增删付款凭证附件，必须另行定义数组编辑契约和后端审计口径。
 
 ### 12.4 S10/S99 来源通知详情
 
@@ -603,7 +653,7 @@ GET /api/reservation/orders/{orderId}
 `order_overview` 只从已确认 V4 卡片派生：
 
 - Basic Information 已确认后，返回 `account_code`、`account_name`、`market_code`、`source_code`；
-- Room Information 已确认后，返回 `arrival_date`、`departure_date`、`rate_code`、`room_items[]`；
+- Room Information 已确认后，返回 `arrival_date`、`departure_date`、`rate_code`、`room_items[]`；下一阶段 Room Information 展示模型实现后，可继续从确认快照派生 `nights`、`breakfast_included` 和 Group Booking Status；
 - Trace / Rooming List / Payment 返回对应最新卡片状态，方便订单详情展示待处理事项；
 - 未确认 AI 建议不得进入 `order_overview`，避免把未处理内容展示成订单事实。
 
@@ -705,7 +755,7 @@ POST /api/reservation/order-tasks/{orderTaskId}/cards/{cardId}/confirm
 - 请求 JSON 必须携带 `version`；`confirmed_payload` 可选，未传时后端使用当前展示 payload 作为确认快照。
 - 前端只应提交当前卡 `fields[]` 中可编辑字段。后端确认时以当前卡展示快照为基准合并 `confirmed_payload`，未出现在展示快照 / 字段白名单中的字段会被忽略，不会写入 `confirmed_payload_json`。
 - Basic Information 确认时 `basic_information.account_code` 必须是当前酒店数据库 Account 目录值；后端确认前会派生 `account_name`、`market_code` 和 `source_code` 写入 `confirmed_payload_json`。
-- 业务卡确认时，第一版会递归校验已有 `rate_code`、`room_items[].room_type_code` 是否在当前酒店数据库目录中；`UPDATE_BOOKING` 等嵌套结构会返回类似 `business_fields.after.room_items.0.room_type_code` 的错误路径，失败返回 `V4_FIELD_VALIDATION_FAILED`。
+- 业务卡确认时，当前已递归校验已有 `rate_code`、`room_items[].room_type_code` 是否在当前酒店数据库目录中；下一阶段 `rate_code` 还必须属于当前订单 Basic Information 已确认 Account + 当前业务 event `booking_type` 的适用关系。`UPDATE_BOOKING` 等嵌套结构会返回类似 `business_fields.after.room_items.0.room_type_code` 的错误路径，失败返回 `V4_FIELD_VALIDATION_FAILED`。
 - 不提交草稿。
 - 必须带 `version` 做并发校验。
 - 后端确认后卡片 `CONFIRMED` 并锁定。
@@ -727,8 +777,8 @@ POST /api/reservation/order-tasks/{orderTaskId}/cards/{cardId}/review-resolution
 - 可提交复核场景订单归属确认。
 - 请求 JSON 必须携带卡片 `version`；可选 `reason` 写入业务审计摘要；`confirmed_order_id` 表示复核场景确认后的本地订单 ID。
 - 如果订单任务当前 `order_id=null` 或 `target_resolution_status!=RESOLVED`，`confirmed_order_id` 必填；后端会按订单任务所属酒店查询并校验真实可见订单。
-- `field_overrides[]` 每项包含 `field_pointer` 和 `value`；`field_pointer` 只允许指向当前卡展示 payload 中的可编辑业务字段，不允许指向 `source_message`、`route_code`、`card_type`、`target_order`、`order_ref`、`missing_fields`、`manual_review`、`raw_evidence`、`validation_errors` 等只读诊断字段。
-- 第一版允许的写入容器是 `basic_information` 和 `business_fields`；如果展示 payload 中存在显式 `missing_fields[]`，只允许提交清单中的 pointer；否则只能改已存在且值为 `null` / 空字符串的叶子字段，或后端 `validation_errors_json` 指向的目录错误字段，不能修改其它已有有效值、替换整个对象 / 数组或新增未知字段。
+- `field_overrides[]` 每项包含 `field_pointer` 和 `value`；`field_pointer` 只允许指向当前卡 `fields[]` 中可编辑业务字段，不允许指向 `source_message`、`route_code`、`card_type`、`target_order`、`order_ref`、`missing_fields`、`manual_review`、`raw_evidence`、`validation_errors` 等只读诊断字段。
+- 第一版允许的写入容器是 `basic_information` 和 `business_fields`。复核态允许编辑当前卡业务字段白名单内的已有叶子字段；不允许替换整个对象 / 数组、新增未知字段或提交后端未返回为可编辑的字段。
 - 复核提交后同样执行目录校验；Basic Information 复核成功后会在 `confirmed_payload_json.basic_information` 中写入派生的 `account_name`、`market_code`、`source_code`。
 - 如果订单任务已经有 `order_id` 且 `target_resolution_status=RESOLVED`，`confirmed_order_id` 只能为空或等于当前订单 ID；提交其它订单 ID 会返回 `V4_ORDER_REBIND_NOT_ALLOWED`。
 - Basic Information 必须先确认；如果 Basic Information 自身是 `REVIEW_REQUIRED`，允许通过本接口先复核并确认 Basic。
@@ -799,7 +849,7 @@ S10/S99 已确认采用来源通知模型，不继续复用隐藏技术订单或
 | 确认卡片 | `FRONTEND_USER` | `RESERVATION_TASK_CONFIRM` | 写业务审计 |
 | 复核解阻 | `FRONTEND_USER` | `RESERVATION_MANUAL_REVIEW_RESOLVE` | 写业务审计 |
 | 确认 S10/S99 来源通知 | `FRONTEND_USER` | `RESERVATION_TASK_CONFIRM` | 写业务审计 |
-| 读取邮件正文 / 附件 | `FRONTEND_USER` | `SOURCE_MESSAGE_READ` + `SOURCE_MESSAGE_ORIGINAL_READ` | 写原文读取审计 |
+| 读取邮件正文 / 附件 / Payment 凭证预览和下载 | `FRONTEND_USER` | `SOURCE_MESSAGE_READ` + `SOURCE_MESSAGE_ORIGINAL_READ` | 写原文读取审计 |
 | SuperAgent V4 回调 | `THIRD_PARTY_SUPERAGENT` | HMAC 机器鉴权 | 写 AI batch / transition |
 
 AI 原始 payload、邮件正文、附件 URL 和技术 trace 不应直接进入普通列表接口。
@@ -820,6 +870,11 @@ AI 原始 payload、邮件正文、附件 URL 和技术 trace 不应直接进入
 | M002-V4-CP12 | 前端 Lookup 接入 | V4 卡片字段按 `options_source` 调用 lookup，替换固定种子硬编码选项，处理 stale / warning / 空目录 |
 | M002-V4-CP13 | 目录管理后台 V1 | Account / Market / Source 管理，临时 Room Type / Rate Code 管理，目录维护权限和管理审计 |
 | M002-V4-CP14 | 订单列表 V4 继续处理入口 | 已完成：`GET /api/reservation/orders` 返回 V4 下一步订单任务、卡片、动作类型、动作状态和 open 数，前端可优先跳 V4 订单任务详情 |
+| M002-V4-CP14.5 | Account 范围 Rate Code Lookup | 待实现：按 Account + `booking_type` 管理和查询 Rate Code 适用关系；业务卡确认 / 复核校验 Rate Code 适用性；前端在 Account 确认后加载对应 GROUP/FIT 候选 |
+| M002-V4-CP14.6 | Payment 附件预览 | 待实现：Payment 卡返回付款凭证附件安全摘要；前端图片缩略图 + 大图预览，非图片文件列表 + 下载；预览 / 下载走 SourceMessage 原文权限链路 |
+| M002-V4-CP14.7 | Rooming List 事项确认卡 | 待实现前端轻量展示：Rooming List 卡第一版只展示事项和确认按钮，不解析名单、不预览附件、不生成 Excel、不导入 PMS |
+| M002-V4-CP14.8 | Room Information 展示模型 | 待实现：New / Update / Cancel 按业务模型展示最终值、差异、Nights、Breakfast、Group Booking Status 和本地订单投影；Adult 不显示；Rooming List 确认时 Group 状态自动置 `DEF` |
+| M002-V4-CP14.9 | 复核态卡片字段白名单和统一确认交互 | 待实现：`REVIEW_REQUIRED` 保持原业务卡内编辑，问题字段红字提示，前端按钮显示“确认卡片”但调用 `review-resolution`；后端 `fields[]` 返回当前卡业务字段白名单，复核写入不再只限空值或目录错误字段 |
 | M002-V4-CP15 | V4 业务审计查询 | 已完成：`GET /api/reservation/order-tasks/{orderTaskId}/audits` 和 `GET /api/reservation/source-notifications/{notificationId}/audits` 返回卡片确认、复核解阻和来源通知 ack 的脱敏审计流水 |
 | M002-V4-CP15.1 | 订单详情 V4 化后端补齐 | 已完成：`GET /api/reservation/orders/{orderId}` 返回 `order_overview`、`next_v4_action`、`related_source_messages[]` 和 `v4_order_tasks[].cards[]`，支撑订单总览页 |
 | M002-V4-CP16 | PMS / OPERA / OHIP 目录同步 | 同步 Adapter、同步 run、最后成功快照、失败重试和同步状态管理入口 |

docs/project/requirements/M002-v4-real-catalog-lookup-api-design.md

@@ -4,11 +4,11 @@
 
 | 项目 | 内容 |
 | --- | --- |
-| 文档版本 | 0.3 |
-| 日期 | 2026-07-19 |
-| 状态 | CP11 已落地第一版数据库目录与 lookup API；目录管理后台 CP1 已落地后端接口；真实 PMS 同步继续后置 |
-| 适用范围 | M002 V4 Account、Market、Source、Room Type、Rate Code 目录来源、数据模型、前端 lookup、缓存、酒店隔离、权限和失败兜底 |
-| 不适用范围 | 真实 OPERA / OHIP 写操作、真实价格计算、前端页面实现、SuperAgent Prompt 修改、目录同步任务、SuperAgent 机器目录接口 |
+| 文档版本 | 0.4 |
+| 日期 | 2026-07-20 |
+| 状态 | CP11 已落地第一版数据库目录与 lookup API；目录管理后台 CP1 已落地后端接口；Account + booking type 过滤 Rate Code 和 Room Information 早餐派生已确认为下一阶段待实现契约；真实 PMS 同步继续后置 |
+| 适用范围 | M002 V4 Account、Market、Source、Room Type、Rate Code 目录来源、Room Information 早餐派生、数据模型、前端 lookup、缓存、酒店隔离、权限和失败兜底 |
+| 不适用范围 | 真实 OPERA / OHIP 写操作、真实价格计算、房型 / 日期 / 价格级 Rate Code 适用规则、前端页面实现、SuperAgent Prompt 修改、目录同步任务、SuperAgent 机器目录接口 |
 
 ## 1. 文档定位
 
@@ -16,7 +16,9 @@ M002 V4 CP8 已实现第一版固定种子目录校验；M002 V4 CP11 已把该
 
 - Basic Information 的 `account_code` 必须存在于当前酒店数据库 Account 目录。
 - Market / Source 由 Account 派生，不由 SuperAgent 输出。
-- Room Type / Rate Code 第一版使用当前酒店数据库目录校验和字段选项提示。
+- Room Type 第一版使用当前酒店数据库目录校验和字段选项提示。
+- Rate Code 当前 CP11 实现仍是酒店级目录校验和字段选项提示；下一阶段已确认需要按订单级 Account + `booking_type`（`GROUP` / `FIT`）过滤候选和校验适用性。
+- Room Information 卡中 Breakfast 第一版由后端派生：Group 固定含早；Fit 按 Rate Code 中 `RB` / `RO` 判断，无法派生时要求用户在卡片中必填确认。
 - 目录错误会让对应 V4 卡片进入 `REVIEW_REQUIRED`，用户通过复核解阻选择合法 code。
 
 本文记录真实目录和 lookup API 的设计与 CP11 第一版实现。CP11 新增 `workflow_reservation_catalog_account`、`workflow_reservation_catalog_code` 两张表，并通过 Flyway 初始化 `HOTEL-TEST`、`HOTEL-DEV` 以及迁移执行时已存在的 `ACTIVE` 平台酒店的固定种子目录；同时新增 `ReservationV4CatalogBootstrapRunner`，在平台默认酒店由启动流程创建后，如果该酒店目录为空，会补一份 `FIXED_SEED_IMPORT` 初始化目录。不再在运行时代码中把固定种子作为全局目录事实。目录管理后台 CP1 已新增 Account、Room Type、Rate Code 后端查询、新增、启用 / 停用接口；`workflow_reservation_catalog_sync_run`、真实 PMS / OPERA / OHIP 同步、Market / Source 独立管理页面和 SuperAgent 机器目录供给接口继续后置。
@@ -33,7 +35,7 @@ CP11 之前固定种子实现位于后端 `ReservationV4DirectoryService` 和 `F
 | Market | 由 Account 派生的订单级 Market | 当前 Account 均派生 `LEISURE` | 已进入通用代码目录，前端仍不直接编辑 |
 | Source | 由 Account 派生的订单级 Source | 当前 Account 均派生 `TRAVEL_AGENT` | 已进入通用代码目录，前端仍不直接编辑 |
 | Room Type | 房型 code 校验和字段选项提示 | `TWN`、`KING`、`DBL`、`SGL`、`TRP`、`RM1`、`RM2`、`RM3` | 已进入数据库初始化目录，仍不是 PMS 全量房型；后台 CP1 可新增、启用 / 停用 |
-| Rate Code | Rate Code 校验和字段选项提示 | `BAR`、`RACK`、`PACKAGE`、`GROUP`、`FIT` | 已进入数据库初始化目录，不按日期、账号、房型过滤，不含价格；后台 CP1 可新增、启用 / 停用 |
+| Rate Code | Rate Code 校验和字段选项提示 | `BAR`、`RACK`、`PACKAGE`、`GROUP`、`FIT` | 已进入数据库初始化目录；当前实现仍是酒店级目录，下一阶段改为 Account + booking type 适用范围过滤；不按房型、日期或价格过滤；后台 CP1 可新增、启用 / 停用 |
 
 当前固定种子只能支撑开发和演示闭环，不能作为生产长期事实源。
 
@@ -47,6 +49,7 @@ CP11 之前固定种子实现位于后端 `ReservationV4DirectoryService` 和 `F
 4. 目录有来源、版本、更新时间和启停状态，便于排查 SuperAgent 输出 code 与系统目录不一致的问题。
 5. PMS / OPERA / OHIP 不稳定或暂未接入时，系统仍可使用最后一次成功目录快照或系统管理目录兜底。
 6. 固定种子目录可以作为 dev/test 或导入初始化兜底，但生产不应默认靠代码固定值。
+7. Rate Code 不再作为全酒店通用下拉；业务卡 Rate Code 候选必须先受当前订单 Basic Information 的 Account 和 event `booking_type` 限定。
 
 ## 4. 目录来源分层
 
@@ -55,7 +58,7 @@ CP11 之前固定种子实现位于后端 `ReservationV4DirectoryService` 和 `F
 | 阶段 | 来源 | 中文说明 | 适用目录 |
 | --- | --- | --- | --- |
 | Phase 0 | `FIXED_SEED_IMPORT` | CP11 已将固定种子通过 Flyway 和启动补种子流程导入数据库，不再作为运行时代码全局 Map | 当前 Account、Market、Source、Room Type、Rate Code |
-| Phase 1 | `SYSTEM_MANAGED` | 本系统数据库目录，由初始化脚本、管理后台或导入文件维护 | Account、Market、Source；也可临时维护 Room Type、Rate Code |
+| Phase 1 | `SYSTEM_MANAGED` / `IMPORT_FILE` | 本系统数据库目录，由初始化脚本、管理后台或受控导入文件维护；`IMPORT_FILE` 用于 OWNER RATE 等人工确认过的目录 / 适用关系导入 | Account、Market、Source；也可临时维护 Room Type、Rate Code 和 Account + booking type 的 Rate Code 适用关系 |
 | Phase 2 | `PMS_SYNC` | 后端从 PMS / OPERA / OHIP 同步目录到本系统本地表，业务查询只读本地快照 | Room Type、Rate Code 优先；Account、Market、Source 视 PMS 能力再接 |
 
 原则：
@@ -72,9 +75,9 @@ CP11 之前固定种子实现位于后端 `ReservationV4DirectoryService` 和 `F
 | Market | 本系统管理目录 | 可选同步 PMS market code 配置 | 否，随 Account 派生展示 | 前端不直接改 Market；修改 Account 后后端派生 Market |
 | Source | 本系统管理目录 | 可选同步 PMS source code 配置 | 否，随 Account 派生展示 | 前端不直接改 Source；修改 Account 后后端派生 Source |
 | Room Type | PMS / OPERA / OHIP 同步目录优先 | 同步酒店有效房型、展示名、人数、启停状态 | 是，业务卡选择房型 | 若 PMS 未接入，可临时由系统管理维护或固定种子初始化 |
-| Rate Code | PMS / OPERA / OHIP 同步目录优先 | 同步有效 Rate Plan / Rate Code；价格和日期适用规则后置 | 是，New Booking 选择 Rate Code | 第一版 lookup 只选 code，不做价格计算 |
+| Rate Code | PMS / OPERA / OHIP 同步目录优先；在 PMS 未接前可由系统管理或导入文件维护 Account 适用关系 | 同步有效 Rate Plan / Rate Code；Account、booking type、房型、日期和价格适用规则逐步扩展 | 是，New Booking 选择 Rate Code | 下一阶段先按 Account + GROUP/FIT 过滤候选，只选 code，不做价格计算 |
 
-Department 目录在 V4 字段契约中也会被 Trace 使用，但当前固定种子 CP8 尚未实现。后续可沿用本文模型扩展 `DEPARTMENT`，不放入本 checkpoint。
+Department 目录在 V4 字段契约中也会被 Trace 使用。当前任务详情页第一版先固定 `FO`、`HSK`、`FO+HSK` 三个 Department code，用于 Trace 卡下拉和 SuperAgent 输出约束；这不是正式数据库目录。后续可沿用本文模型扩展 `DEPARTMENT`、lookup API、系统管理维护和目录校验，不放入本 checkpoint。
 
 ## 6. 数据模型草案
 
@@ -135,7 +138,53 @@ Market、Source、Room Type、Rate Code 可先使用统一 code 表。
 uk_reservation_catalog_code(hotel_id, catalog_type, code)
 ```
 
-### 6.3 推荐表：`workflow_reservation_catalog_sync_run`
+### 6.3 推荐表：`workflow_reservation_rate_code_applicability`
+
+Rate Code 本身仍保存在 `workflow_reservation_catalog_code` 中，`catalog_type=RATE_CODE` 表示该 code 是当前酒店已知的 Rate Code；是否对某个 Account、GROUP/FIT 可用，由适用关系表表达。这样可以避免在 `metadata_json` 中写不可查询的业务规则，也避免前端硬编码 OWNER RATE Excel。
+
+本 checkpoint 只确认 Account + booking type 粒度，不纳入房型、日期和价格规则。后续如果需要按 Room Type 或入住日期进一步过滤，应在此表或独立价格规则表上扩展，不改变前端只提交稳定 `rate_code` 的基本原则。
+
+| 字段 | 中文说明 |
+| --- | --- |
+| `id` | 内部主键 ID |
+| `hotel_id` | 酒店 ID，必须和 Account、Rate Code 同酒店 |
+| `account_code` | Reservation Account 稳定 code，引用当前酒店 Account 目录 |
+| `booking_type` | `GROUP` / `FIT`；用于区分团队价和散客价候选 |
+| `rate_code` | Rate Code 稳定 code，引用当前酒店 `RATE_CODE` 目录 |
+| `status` | `ACTIVE` / `DISABLED`；普通 lookup 只返回 `ACTIVE` |
+| `source_system` | `SYSTEM_MANAGED` / `IMPORT_FILE` / `PMS_SYNC` / `FIXED_SEED_IMPORT` |
+| `catalog_version` | 适用关系版本，用于排查和前端非阻塞提示 |
+| `sort_order` | 同一 Account + booking type 下的默认展示排序 |
+| `metadata_json` | 扩展说明，例如导入文件行号、业务备注；不得作为唯一可查询条件 |
+| `version` | 乐观锁版本 |
+| `created_at` / `updated_at` | UTC 创建和更新时间 |
+| `logic_deleted_at` / `logic_deleted_reason` | 逻辑删除时间和原因 |
+
+建议唯一约束：
+
+```text
+uk_reservation_rate_code_applicability(hotel_id, account_code, booking_type, rate_code)
+```
+
+建议外键 / 逻辑校验：
+
+- `account_code` 必须存在于同酒店 `workflow_reservation_catalog_account` 且为 `ACTIVE`，否则不进入普通 lookup。
+- `rate_code` 必须存在于同酒店 `workflow_reservation_catalog_code` 且 `catalog_type=RATE_CODE`、`status=ACTIVE`，否则不进入普通 lookup。
+- 停用 Account 或 Rate Code 后，普通 Rate Code lookup 不再返回对应适用关系；已确认历史卡片不回滚。
+
+### 6.4 Rate Code 早餐派生
+
+Room Information 卡需要展示 `breakfast_included` 布尔字段，但该字段不由 SuperAgent 输出。
+
+第一版派生规则：
+
+- Group 固定含早，`breakfast_included=true`，前端显示勾选且只读。
+- Fit 根据最终 Rate Code 派生：Rate Code 中包含 `RB` 时 `breakfast_included=true`，包含 `RO` 时 `breakfast_included=false`。
+- Fit Rate Code 同时无法命中 `RB` / `RO` 时，后端应把 `breakfast_included` 标为未解决，前端显示必填勾选框，由用户确认是否含早。
+- 该规则只用于 Room Information 卡展示和确认，不代表真实价格计算，也不替代 PMS Rate Plan 规则。
+- 后续如果目录表显式维护早餐属性，可优先使用目录元数据；但普通前端仍消费布尔 `breakfast_included`，不要自行按 Rate Code 字符串猜测。
+
+### 6.5 推荐表：`workflow_reservation_catalog_sync_run`
 
 如果接 PMS / OPERA / OHIP 同步，建议记录每次同步运行。
 
@@ -168,6 +217,7 @@ workflows.reservation.service
     - findAccount(hotelId, accountCode)
     - isKnownRoomTypeCode(hotelId, roomTypeCode)
     - isKnownRateCode(hotelId, rateCode)
+    - isRateCodeApplicable(hotelId, accountCode, bookingType, rateCode)
 
 workflows.reservation.repository
   ReservationV4CatalogRepository
@@ -178,6 +228,7 @@ workflows.reservation.service
     - listAccounts(...)
     - listRoomTypes(...)
     - listRateCodes(...)
+    - listRateCodesByAccountAndBookingType(...)
 
 integrations.ohip / integrations.pms
   CatalogSyncAdapter
@@ -187,6 +238,7 @@ integrations.ohip / integrations.pms
 规则：
 
 - V4 入站、确认、复核只调用 `ReservationV4DirectoryService`。
+- Basic Information 的 `account_code` 先确认或在同次复核中修正后，业务卡 Rate Code 才能按该 Account + `booking_type` 做适用性校验。
 - 前端 lookup Controller 调用 `ReservationV4CatalogLookupService`，该服务同样只读本地目录表。
 - PMS / OHIP 同步 Adapter 只能写本地目录表或同步 run，不直接参与用户确认事务。
 - 如果目录服务不可用，确认接口 fail closed，不接受自由文本。
@@ -318,10 +370,12 @@ GET /api/reservation/lookups/rate-codes
 | 参数 | 必需 | 中文说明 |
 | --- | --- | --- |
 | `hotel_id` | 否 | 当前酒店 ID |
+| `account_code` | 是 | 已选择或已确认的 Reservation Account code；必须属于当前酒店 ACTIVE Account 目录 |
+| `booking_type` | 是 | `GROUP` / `FIT`；取自当前业务 event 的 `target_order.booking_type` |
 | `keyword` | 否 | 匹配 Rate Code 或显示名 |
 | `page_num` / `page_size` | 否 | 分页 |
 
-第一版固定只返回 `ACTIVE` Rate Code，不接 `booking_type`、`account_code`、`arrival_date` / `departure_date`，适用范围和价格过滤后置。
+下一阶段 Rate Code lookup 必须按 `account_code + booking_type` 返回 `ACTIVE` 且适用的 Rate Code。`account_code` 未传、无效或不属于当前酒店时返回 400；`booking_type` 非 `GROUP` / `FIT` 时返回 400；Account 合法但当前无适用 Rate Code 时返回空 `items[]`。前端在 Account 未选时不应拉全酒店 Rate Code。`arrival_date` / `departure_date`、房型和价格过滤后置。
 
 响应草案：
 
@@ -329,15 +383,17 @@ GET /api/reservation/lookups/rate-codes
 {
   "hotel_id": "HOTEL-TEST",
   "catalog_type": "RATE_CODE",
-  "catalog_source": "FIXED_SEED_IMPORT",
-  "catalog_version": "seed-20260719-v1",
+  "account_code": "QBD_TRAVEL",
+  "booking_type": "GROUP",
+  "catalog_source": "IMPORT_FILE",
+  "catalog_version": "owner-rate-20260720-v1",
   "stale": false,
   "items": [
     {
-      "code": "GROUP",
-      "display_name": "GROUP",
+      "code": "GRPA1",
+      "display_name": "GRPA1",
       "status": "ACTIVE",
-      "catalog_source": "FIXED_SEED_IMPORT",
+      "catalog_source": "IMPORT_FILE",
       "pricing_available": false
     }
   ],
@@ -353,7 +409,8 @@ GET /api/reservation/lookups/rate-codes
 前端用途：
 
 - `fields[].options_source=reservation_v4_rate_code_catalog` 时调用。
-- 第一版只选 `rate_code`，不展示或计算真实价格。
+- 只能在当前订单 Basic Information 已有有效 Account，且当前业务 event 有 `booking_type` 时调用；Account 切换后必须清空或重新校验已选 Rate Code。
+- 下一阶段只选 `rate_code`，不展示或计算真实价格。
 - V4 契约仍禁止 `UPDATE_BOOKING` 携带 Rate Code；lookup API 不改变该规则。
 
 ### 8.4 Market / Source Lookup
@@ -370,7 +427,7 @@ Market / Source 第一版不作为用户可编辑字段，不建议给普通业
 | --- | --- | --- |
 | `reservation_v4_account_catalog` | `GET /api/reservation/lookups/accounts` | 渲染 Account 下拉 / 搜索选择，展示派生 Market / Source |
 | `reservation_v4_room_type_catalog` | `GET /api/reservation/lookups/room-types` | 渲染房型搜索选择 |
-| `reservation_v4_rate_code_catalog` | `GET /api/reservation/lookups/rate-codes` | 渲染 Rate Code 搜索选择 |
+| `reservation_v4_rate_code_catalog` | `GET /api/reservation/lookups/rate-codes?account_code=...&booking_type=...` | 渲染当前 Account + GROUP/FIT 适用的 Rate Code 搜索选择 |
 | `static_enum` | 使用 `fields[].enum_options` | 不调用 lookup |
 | `system_case_lookup` | 后续订单 / 任务对象 lookup | 不属于本目录 checkpoint |
 
@@ -423,7 +480,7 @@ Market / Source 第一版不作为用户可编辑字段，不建议给普通业
 | --- | --- | --- | --- | --- |
 | `GET /api/reservation/lookups/accounts` | `FRONTEND_USER` | `RESERVATION_TASK_READ` | 按用户可访问酒店校验 | 只读不写业务审计 |
 | `GET /api/reservation/lookups/room-types` | `FRONTEND_USER` | `RESERVATION_TASK_READ` | 按用户可访问酒店校验 | 只读不写业务审计 |
-| `GET /api/reservation/lookups/rate-codes` | `FRONTEND_USER` | `RESERVATION_TASK_READ` | 按用户可访问酒店校验 | 只读不写业务审计 |
+| `GET /api/reservation/lookups/rate-codes` | `FRONTEND_USER` | `RESERVATION_TASK_READ` | 按用户可访问酒店校验；`account_code` 和 `booking_type` 只能用于当前酒店目录过滤 | 只读不写业务审计 |
 
 复用 `RESERVATION_TASK_READ` 的原因：
 
@@ -480,14 +537,16 @@ SuperAgent 当前不调用本 lookup API。SuperAgent 目录供给后续有两
 2. 遍历每张卡 `fields[]`。
 3. 只有字段 `editable=true` 且 `control_type=select/lookup` 时才加载 lookup。
 4. 根据 `options_source` 选择 lookup 接口。
-5. 搜索输入做 debounce，不一次性拉全量。
-6. 显示 `stale=true` 或 `warnings[]` 时给用户非阻塞提醒。
-7. 用户提交确认或复核时只提交 code，不提交显示名、Market / Source 派生值或目录完整对象。
-8. 确认成功后以后端返回的 `confirmed_payload_json` / 刷新详情为准更新页面。
+5. Rate Code 字段必须先取得当前订单 Basic Information 的 Account 和当前业务 event 的 `booking_type`；缺任一条件时禁用或显示空态，不调用全酒店 Rate Code 全量查询。
+6. 搜索输入做 debounce，不一次性拉全量。
+7. 显示 `stale=true` 或 `warnings[]` 时给用户非阻塞提醒。
+8. 用户提交确认或复核时只提交 code，不提交显示名、Market / Source 派生值或目录完整对象。
+9. 确认成功后以后端返回的 `confirmed_payload_json` / 刷新详情为准更新页面。
 
 前端禁止：
 
 - 硬编码 PMS 房型或 Rate Code 全集。
+- 硬编码 OWNER RATE Excel 中 Account 到 Rate Code 的映射；该映射必须由后端目录 / 适用关系接口提供。
 - 把目录显示名当业务 code 提交。
 - 绕过 `fields[]` 自行补业务字段。
 - 使用 lookup API 给 SuperAgent、AgentBus 或 Debug 链路拼接输入。
@@ -501,6 +560,7 @@ SuperAgent 当前不调用本 lookup API。SuperAgent 目录供给后续有两
 | M002-V4-CP12 | 前端 Lookup 接入 | V4 卡片字段渲染按 `options_source` 调用 lookup，替换固定种子硬编码选项，处理 stale / warning / 空目录 |
 | M002-V4-CP13 | 目录管理后台 V1 | CP1 已完成 Account / Room Type / Rate Code 前后端列表、新增、启用 / 停用闭环、`RESERVATION_CATALOG_MANAGE` 权限和管理审计；Market / Source 独立管理后置 |
 | M002-V4-CP14 | 订单列表 V4 继续处理入口 | 已完成：订单列表返回 V4 下一步订单任务、卡片、动作类型、动作状态和 open 数，前端可优先跳 V4 订单任务详情 |
+| M002-V4-CP14.5 | Account 范围 Rate Code Lookup | 待实现：新增 Account + booking type 适用关系模型 / 导入种子，Rate Code lookup 接收 `account_code`、`booking_type`，确认和复核校验 Rate Code 适用性，前端联动 Account 后展示候选 |
 | M002-V4-CP15 | PMS / OPERA / OHIP 目录同步 | 同步 Adapter、同步 run 表、失败重试、最后成功快照、同步状态管理入口 |
 | M002-V4-CP16 | SuperAgent 目录供给 | 明确目录版本如何给 SuperAgent，必要时新增机器目录接口或导出包 |
 
@@ -512,7 +572,7 @@ CP11 已作为后端第一步落地，因为它不依赖真实 PMS，也能让
 2. Account code 是否继续使用本系统定义的稳定 code，例如 `QBD_TRAVEL`，还是必须对齐 PMS profile code。
 3. Market / Source 是否只允许随 Account 派生，还是未来允许用户在 Basic Information 中单独改选。
 4. Room Type 第一版后端已支持系统管理维护；后续是否仍要接 PMS / OHIP 同步替换为主来源待确认。
-5. Rate Code 第一版是否只校验 code，还是需要按 `booking_type`、`account_code`、入住日期过滤。
+5. Rate Code 已确认下一阶段按 `account_code + booking_type` 过滤；入住日期、房型和价格是否也要进入过滤仍待后续确认。
 6. 生产是否允许 `FIXED_SEED` 作为兜底，还是只允许 dev/test 使用。
 7. SuperAgent 是否需要读取目录；如果需要，是离线给目录包，还是新增 HMAC 机器接口。
 

docs/project/requirements/M010-rooming-list-excel-generation-v1.md

@@ -13,6 +13,8 @@
 
 本功能第一版只解决“来源名单到目标 Rooming List”的结构转换和分房填表问题，不依赖订单、任务、SuperAgent、AgentBus 或 OPERA。
 
+M002 V4 `ROOMING_LIST` 任务卡与本工具是两个独立能力：V4 卡第一版只做 Rooming List 事项确认，不调用本工具、不解析名单、不生成 Excel、不导入 PMS。
+
 ## 2. 第一阶段定位
 
 第一阶段应做到：

docs/project/security-access-control-boundary.md

@@ -49,17 +49,17 @@
 | `GET /api/reservation/tasks/{taskId}` | `FRONTEND_USER` | 已强制 Bearer 登录 + `RESERVATION_TASK_READ`；按任务实际所属酒店校验访问权 | 保持登录 + `RESERVATION_TASK_READ` + 任务所属酒店访问权 | 只读查询默认不写业务审计 |
 | `GET /api/reservation/workbench-items` | `FRONTEND_USER` | 已实现 M002 V4 CP5；强制 Bearer 登录 + `RESERVATION_TASK_READ` + 酒店访问权 | 保持登录 + `RESERVATION_TASK_READ` + 酒店访问权；统一返回 V4 业务订单任务和 S10/S99 来源通知摘要 | 只读查询默认不写业务审计；不得返回邮件正文、附件 URL、AI 原始 payload 或来源通知原始 payload；同来源时间下使用 `updated_at` / `created_at` / 数字 ID 稳定排序 |
 | `GET /api/reservation/order-tasks` | `FRONTEND_USER` | 已实现 M002 V4 CP5；强制 Bearer 登录 + `RESERVATION_TASK_READ` + 酒店访问权 | 保持登录 + `RESERVATION_TASK_READ` + 酒店访问权；只返回 V4 业务订单任务，不返回 S10/S99 来源通知 | 只读查询默认不写业务审计；不得返回 AI 原始 payload；`card_status` 只匹配业务 / 可处理卡，固定来源邮件展示卡不参与筛选 |
-| `GET /api/reservation/order-tasks/{orderTaskId}` | `FRONTEND_USER` | 已实现 M002 V4 CP5；强制 Bearer 登录 + `RESERVATION_TASK_READ` + 订单任务所属酒店访问权 | 保持登录 + `RESERVATION_TASK_READ` + 订单任务所属酒店访问权 | 只读查询默认不写业务审计；邮件正文和附件读取仍走 SourceMessage 原文权限；不得返回 `ai_payload_json` 或附件 URL；同批次 `adapter_contract_errors[]` 只返回白名单诊断字段；前端普通业务卡如遇 URL-like 附件字符串必须二次脱敏 |
+| `GET /api/reservation/order-tasks/{orderTaskId}` | `FRONTEND_USER` | 已实现 M002 V4 CP5；强制 Bearer 登录 + `RESERVATION_TASK_READ` + 订单任务所属酒店访问权 | 保持登录 + `RESERVATION_TASK_READ` + 订单任务所属酒店访问权；V4 任务详情页展示顺序为 Basic Information、业务卡、SourceMessage Display；Room Information 展示模型只返回当前酒店本地订单投影、Agent 白名单字段和系统派生值；Payment 卡可返回付款凭证附件安全摘要；Payment 第一版 `attachment_ids[]` 只读展示，不支持前端增删或替换附件集合 | 只读查询默认不写业务审计；本接口不得直接返回邮件正文、HTML 或附件 URL，来源邮件卡正文和 Payment 图片预览 / 非图片下载必须通过 `GET /api/source-messages/{id}/conversation` 的 SourceMessage 原文权限链路读取；Room Information 展示模型不得返回 PMS 原始响应、价格明细、AI 原始 payload 或跨酒店订单值；Payment 安全摘要只能包含附件 ID、文件名、类型、大小、是否图片、是否可预览 / 下载等；不得返回 `ai_payload_json`；同批次 `adapter_contract_errors[]` 只返回白名单诊断字段；前端普通业务卡如遇 URL-like 附件字符串必须二次脱敏 |
 | `GET /api/reservation/order-tasks/{orderTaskId}/audits` | `FRONTEND_USER` | 已强制 Bearer 登录 + `RESERVATION_AUDIT_READ` + V4 订单任务所属酒店访问权 | 保持登录 + `RESERVATION_AUDIT_READ` + 订单任务所属酒店访问权；仅返回卡片确认和复核解阻审计摘要 | 查询审计不再写审计；返回快照必须脱敏，不返回原始邮件正文、HTML、附件 URL、AI 原始 payload、token 或 secret |
 | `GET /api/reservation/source-notifications/{notificationId}` | `FRONTEND_USER` | 已实现 M002 V4 CP5；强制 Bearer 登录 + `RESERVATION_TASK_READ` + 来源通知所属酒店访问权 | 保持登录 + `RESERVATION_TASK_READ` + 来源通知所属酒店访问权 | 只读查询默认不写业务审计；邮件正文和附件读取仍走 SourceMessage 原文权限；不得返回来源通知原始 payload 或附件 URL；前端普通通知卡如遇 URL-like 附件字符串必须二次脱敏 |
 | `GET /api/reservation/source-notifications/{notificationId}/audits` | `FRONTEND_USER` | 已强制 Bearer 登录 + `RESERVATION_AUDIT_READ` + 来源通知所属酒店访问权 | 保持登录 + `RESERVATION_AUDIT_READ` + 来源通知所属酒店访问权；仅返回 S10/S99 来源通知 ack 审计摘要 | 查询审计不再写审计；返回快照必须脱敏，不返回原始邮件正文、HTML、附件 URL、AI 原始 payload、token 或 secret |
 | `GET /api/reservation/lookups/accounts` | `FRONTEND_USER` | 已实现 M002 V4 CP11；强制 Bearer 登录 + `RESERVATION_TASK_READ` + 酒店访问权 | 保持登录 + `RESERVATION_TASK_READ` + 酒店访问权；只返回 Account code、显示名、派生 Market / Source 和目录安全元数据 | 只读查询默认不写业务审计；不得返回 PMS 原始响应、Secret 或外部同步错误详情 |
 | `GET /api/reservation/lookups/room-types` | `FRONTEND_USER` | 已实现 M002 V4 CP11；强制 Bearer 登录 + `RESERVATION_TASK_READ` + 酒店访问权 | 保持登录 + `RESERVATION_TASK_READ` + 酒店访问权；只返回当前酒店可选 ACTIVE 房型目录快照 | 只读查询默认不写业务审计；不得返回 PMS 原始响应、价格敏感细节或跨酒店房型 |
-| `GET /api/reservation/lookups/rate-codes` | `FRONTEND_USER` | 已实现 M002 V4 CP11；强制 Bearer 登录 + `RESERVATION_TASK_READ` + 酒店访问权 | 保持登录 + `RESERVATION_TASK_READ` + 酒店访问权；只返回当前酒店可选 ACTIVE Rate Code 目录快照，不做真实价格计算 | 只读查询默认不写业务审计；不得返回 PMS 原始响应、价格明细、Secret 或跨酒店 Rate Plan |
+| `GET /api/reservation/lookups/rate-codes` | `FRONTEND_USER` | 已实现 M002 V4 CP11；强制 Bearer 登录 + `RESERVATION_TASK_READ` + 酒店访问权；当前实现仍是酒店级目录 | 下一阶段保持登录 + `RESERVATION_TASK_READ` + 酒店访问权，并强制 `account_code` + `booking_type=GROUP/FIT` 过滤；只返回当前酒店、当前 Account、当前 booking type 可选 ACTIVE Rate Code 目录快照，不做真实价格计算 | 只读查询默认不写业务审计；不得返回 PMS 原始响应、价格明细、Secret、跨酒店 Rate Plan 或其他 Account 的 Rate Code 适用关系 |
 | `PUT /api/reservation/tasks/{taskId}/draft` | `FRONTEND_USER` | 第一版未全量强制登录；actor 仍待迁移 | 登录 + `RESERVATION_TASK_EDIT` + 酒店访问权 | 写草稿审计可按业务需要记录 |
 | `POST /api/reservation/tasks/{taskId}/confirm` | `FRONTEND_USER` | 第一版未全量强制登录；actor 仍待迁移 | 登录 + `RESERVATION_TASK_CONFIRM` + 酒店访问权 | 必须写业务审计 |
-| `POST /api/reservation/order-tasks/{orderTaskId}/cards/{cardId}/confirm` | `FRONTEND_USER` | 已实现 M002 V4 CP6/CP8/CP11；强制 Bearer 登录 + `RESERVATION_TASK_CONFIRM` + 订单任务所属酒店访问权 + version 并发校验 + 当前酒店数据库目录校验 | 保持；Basic Information 前置确认，确认后卡片锁定，不返回 AI 原始 payload；Basic Account、Room Type、Rate Code 目录错误返回 `V4_FIELD_VALIDATION_FAILED` | 必须写业务审计，actor 使用当前登录用户 |
-| `POST /api/reservation/order-tasks/{orderTaskId}/cards/{cardId}/review-resolution` | `FRONTEND_USER` | 已实现 M002 V4 CP7/CP8/CP11；强制 Bearer 登录 + `RESERVATION_MANUAL_REVIEW_RESOLVE` + 订单任务所属酒店访问权 + version 并发校验 + 当前酒店数据库目录校验 | 保持；仅用于 V4 `REVIEW_REQUIRED` 卡，不开放普通任务任意切换订单；字段指针只允许当前卡可编辑业务字段，优先按显式 `missing_fields[]`、未解决叶子值或 `validation_errors_json` 指向字段收口；订单归属未解决时必须提交当前酒店下真实可见订单 ID，已 `RESOLVED` 的订单任务不得换绑不同订单 | 必须写业务审计，记录复核字段指针、复核说明和订单归属确认摘要；不返回或写入 AI 原始 payload |
+| `POST /api/reservation/order-tasks/{orderTaskId}/cards/{cardId}/confirm` | `FRONTEND_USER` | 已实现 M002 V4 CP6/CP8/CP11；强制 Bearer 登录 + `RESERVATION_TASK_CONFIRM` + 订单任务所属酒店访问权 + version 并发校验 + 当前酒店数据库目录校验 | 保持；Basic Information 前置确认，确认后卡片锁定，不返回 AI 原始 payload；Rooming List 卡确认只表示事项已人工处理，不新增名单解析、附件预览、Excel 生成或 PMS 导入权限；Payment 第一版确认只提交 `version` 和必要审计说明，不提交 `attachment_ids[]`、附件 URL 或完整附件对象；同订单为 Group 时确认 Rooming List 可自动把 Group Booking Status 置为 `DEF`；Basic Account、Room Type、Rate Code 目录错误返回 `V4_FIELD_VALIDATION_FAILED`；下一阶段 Rate Code 还必须校验属于已确认 Account + 当前业务 event `booking_type` 的适用范围 | 必须写业务审计，actor 使用当前登录用户；Rooming List 触发的 Group Booking Status 自动变更也必须记录安全摘要 |
+| `POST /api/reservation/order-tasks/{orderTaskId}/cards/{cardId}/review-resolution` | `FRONTEND_USER` | 已实现 M002 V4 CP7/CP8/CP11；强制 Bearer 登录 + `RESERVATION_MANUAL_REVIEW_RESOLVE` + 订单任务所属酒店访问权 + version 并发校验 + 当前酒店数据库目录校验 | 保持；仅用于 V4 `REVIEW_REQUIRED` 卡，不开放普通任务任意切换订单；字段指针只允许当前卡 `fields[]` 白名单内可编辑业务字段，不允许提交来源邮件、路由、Agent 原始定位、诊断、`manual_review`、附件 URL 或 AI 原始 payload；订单归属未解决时必须提交当前酒店下真实可见订单 ID，已 `RESOLVED` 的订单任务不得换绑不同订单 | 必须写业务审计，记录复核字段指针、复核说明和订单归属确认摘要；不返回或写入 AI 原始 payload |
 | `POST /api/reservation/source-notifications/{notificationId}/ack` | `FRONTEND_USER` | 已实现 M002 V4 CP6；强制 Bearer 登录 + `RESERVATION_TASK_CONFIRM` + 来源通知所属酒店访问权 + version 并发校验 | 保持；只用于 `route_code=S10/S99` 的 V4 来源通知确认已读 / 已处理，不创建订单、不参与订单阻塞；重复 ack 幂等返回当前状态且不新增审计 | 首次确认必须写业务审计，记录已读 / 已处理确认，actor 使用当前登录用户 |
 | `POST /api/reservation/tasks/{taskId}/manual-review-conversions` | `FRONTEND_USER` | 第一版已写业务审计，但 actor 待迁移 | 登录 + `RESERVATION_MANUAL_REVIEW_RESOLVE` + 酒店访问权 | 必须写业务审计和原因 |
 | `POST /api/reservation/tasks/{taskId}/manual-review-resolutions` | `FRONTEND_USER` | 第一版已写业务审计，但 actor 待迁移 | 登录 + `RESERVATION_MANUAL_REVIEW_RESOLVE` + 酒店访问权 | 必须写业务审计 |
@@ -75,7 +75,7 @@
 | --- | --- | --- | --- | --- |
 | `GET /api/source-messages` | `FRONTEND_USER` | 已强制 Bearer 登录 + `SOURCE_MESSAGE_READ`；列表条件中的酒店按当前用户可访问酒店校验 | 保持登录 + `SOURCE_MESSAGE_READ` + 酒店访问权 | 只读摘要不写审计 |
 | `GET /api/source-messages/{id}` | `FRONTEND_USER` | 已强制 Bearer 登录 + `SOURCE_MESSAGE_READ`；按消息实际所属酒店校验访问权 | 保持登录 + `SOURCE_MESSAGE_READ` + 消息所属酒店访问权 | 只读摘要不写审计 |
-| `GET /api/source-messages/{id}/conversation` | `FRONTEND_USER` | 已强制 Bearer 登录 + `SOURCE_MESSAGE_READ` + `SOURCE_MESSAGE_ORIGINAL_READ`；按消息实际所属酒店校验访问权；返回会话完整 text/html 和媒体 URL | 保持登录 + `SOURCE_MESSAGE_READ` + `SOURCE_MESSAGE_ORIGINAL_READ` + 消息所属酒店访问权 | 必须写原文读取审计，actor 使用当前登录用户稳定 ID |
+| `GET /api/source-messages/{id}/conversation` | `FRONTEND_USER` | 已强制 Bearer 登录 + `SOURCE_MESSAGE_READ` + `SOURCE_MESSAGE_ORIGINAL_READ`；按消息实际所属酒店校验访问权；返回会话完整 text/html 和媒体 URL | 保持登录 + `SOURCE_MESSAGE_READ` + `SOURCE_MESSAGE_ORIGINAL_READ` + 消息所属酒店访问权；V4 任务详情页来源邮件卡读取正文、Payment 图片大图预览和非图片下载都必须走本接口，并且只使用当前触发该 order task 的 SourceMessage 内容和被 Payment `attachment_ids[]` 引用的附件 | 必须写原文读取审计，actor 使用当前登录用户稳定 ID；前端展示 HTML 优先使用 `html_body_sanitized`；前端不得把附件 `externalUrl` 写入确认 payload、日志、错误上报、URL query 或 localStorage |
 | `GET /api/source-messages/{id}/original` | `FRONTEND_USER` | 已强制 Bearer 登录 + `SOURCE_MESSAGE_READ` + `SOURCE_MESSAGE_ORIGINAL_READ`；按消息实际所属酒店校验访问权；不再使用原文读取 access key | 保持登录 + `SOURCE_MESSAGE_READ` + `SOURCE_MESSAGE_ORIGINAL_READ` + 消息所属酒店访问权 | 必须写原文读取审计，actor 使用当前登录用户稳定 ID |
 
 ### 3.4 系统管理后台接口
@@ -193,7 +193,7 @@
 | --- | --- | --- |
 | 管理审计 | `platform_admin_audit_log` | 用户、角色、权限、菜单、酒店的写操作 |
 | 业务审计 | `workflow_reservation_audit_log` | 任务确认、人工复核、订单归属确认、V4 来源通知 ack、OPERA 执行 / 重试 |
-| 邮件原文读取审计 | `platform_source_message_original_access_audit` | 读取邮件正文、HTML、附件外链 |
+| 邮件原文读取审计 | `platform_source_message_original_access_audit` | 读取邮件正文、HTML、附件外链、Payment 图片预览和非图片下载 |
 | SuperAgent 入站追踪 | `workflow_reservation_ai_batch`、`workflow_reservation_ai_transition` | task-results / MCP 提交、路由、adapter error |
 | AgentBus 分发追踪 | `platform_superagent_dispatch_run` | SourceMessage 自动分发 SuperAgent、重试、失败摘要 |
 | 安全审计 | 后续可新增平台安全审计表 | 登录失败、签名失败、nonce 重放、越权访问 |