修复V4房型信息展示安全边界

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

@@ -6,7 +6,7 @@
 | --- | --- |
 | 文档版本 | 0.8 |
 | 日期 | 2026-07-20 |
-| 状态 | CP2 设计已确认；CP3-CP8、CP11、CP13、CP14、V4 业务审计查询和停止 V4 普通业务双写旧任务已实现 |
+| 状态 | CP2 设计已确认；CP3-CP8、CP11、CP13、CP14、V4 业务审计查询、停止 V4 普通业务双写旧任务和 Room Information 后端展示模型第一版已实现 |
 | 适用范围 | M002 V4 入站后的订单任务、多卡、状态、查询和写操作设计 |
 | 不适用范围 | 真实 PMS / OPERA / OHIP、前端页面视觉稿、生产历史数据迁移 |
 
@@ -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 继续处理入口字段。下一阶段已确认 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`。
+截至 CP14、V4 业务审计查询、停止旧任务双写和 Room Information 后端展示模型补齐，后端已实现本文第 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 继续处理入口字段，以及 Room Information New / Update / Cancel 第一版业务展示模型。下一阶段已确认 Rate Code 需要按订单级 Account + `booking_type`（GROUP / FIT）过滤和校验，当前后端 CP11 实现仍是酒店级 Rate Code 目录，是待补齐缺口；Rooming List 确认联动 Group Booking Status 自动置 `DEF` 仍未实现；Payment 卡下一阶段需要展示付款凭证附件，图片为缩略图 + 点击大图预览，非图片为文件列表 + 下载，但附件 URL 仍必须走 SourceMessage 原文权限链路；真实 PMS 同步继续后置，设计见 `M002-v4-real-catalog-lookup-api-design.md`。
 
 后续如本文与 `M002-v4-agent-callback-field-contract.md` 的字段契约冲突，以字段契约为准；如与安全边界冲突，以 `security-access-control-boundary.md` 为准。
 
@@ -571,11 +571,12 @@ 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[]` 继续作为确认 / 复核的可编辑字段白名单。
+- 后端已在 `GET /api/reservation/order-tasks/{orderTaskId}` 的 Room Information 业务卡 `display_payload.room_information` 中补稳定展示模型，结构为 `event_type`、`booking_type`、`current_values`、`proposed_values`、`final_values`、`change_summary[]`、`group_booking_status_options[]`。前端按该展示模型渲染业务 UI，不再从 Agent raw payload / `target_order` 自行推导；`fields[]` 继续作为确认 / 复核的可编辑字段白名单。
+- `fields[]` 的 Room Information 主路径统一为 `/room_information/final_values/...`，例如 `/room_information/final_values/arrival_date`、`/room_information/final_values/room_items/0/room_type_code`。确认接口收到该结构时，后端会从展示模型派生 `confirmed_payload_json.room_information.final_values`，并重新计算 `nights`、`breakfast_included` 和 `group_booking_status_label`；只读字段、Agent `target_order`、Adult 和前端注入字段不会写入确认快照。
 - `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` 为空并阻止确认。
+- `nights` 由后端按酒店本地业务日期计算：`departure_date - arrival_date`，不涉及时区和 UTC；日期缺失、非法或离店早于入住时，`nights` 为空。第一版确认校验要求日期必填，后续如需更严格营业日规则另开 checkpoint。
 - `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。
@@ -755,7 +756,8 @@ 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` 是否在当前酒店数据库目录中；下一阶段 `rate_code` 还必须属于当前订单 Basic Information 已确认 Account + 当前业务 event `booking_type` 的适用关系。`UPDATE_BOOKING` 等嵌套结构会返回类似 `business_fields.after.room_items.0.room_type_code` 的错误路径，失败返回 `V4_FIELD_VALIDATION_FAILED`。
+- Room Information 确认时，前端优先提交 `confirmed_payload.room_information.final_values` 中当前 `fields[]` 可编辑字段；后端会生成稳定确认快照 `confirmed_payload_json.room_information.final_values`。该快照不包含 Agent 原始 `target_order`，也不包含邮件正文、附件 URL、raw evidence、Adult 或前端注入字段。
+- 业务卡确认时，当前已递归校验已有 `rate_code`、`room_items[].room_type_code` 是否在当前酒店数据库目录中；下一阶段 `rate_code` 还必须属于当前订单 Basic Information 已确认 Account + 当前业务 event `booking_type` 的适用关系。Room Information 新结构的错误路径形如 `room_information.final_values.room_items.0.room_type_code`；旧兼容结构可能返回类似 `business_fields.after.room_items.0.room_type_code` 的路径，失败返回 `V4_FIELD_VALIDATION_FAILED`。
 - 不提交草稿。
 - 必须带 `version` 做并发校验。
 - 后端确认后卡片 `CONFIRMED` 并锁定。
@@ -778,7 +780,7 @@ 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` 只允许指向当前卡 `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`、Room Information 的 `room_information.final_values` 和历史兼容 `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。
@@ -873,7 +875,7 @@ AI 原始 payload、邮件正文、附件 URL 和技术 trace 不应直接进入
 | 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.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[]`，支撑订单总览页 |