收口V4 OWNER RATE目录数据

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`，并已完成 Room Information 后端展示模型和前端业务化展示第一版，以及 Rooming List 确认自动 DEF 后端联动；已补 Account 范围 Rate Code、Payment 附件预览、Rooming List 事项确认卡、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-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`，并已完成 Room Information 后端展示模型和前端业务化展示第一版，以及 Rooming List 确认自动 DEF 后端联动；已补 OWNER RATE Room Type / Rate Code 目录口径、Payment 附件预览、Rooming List 事项确认卡、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 同步后置和失败兜底；已记录 OWNER RATE `RATECODE (2)` 只读整理结论：Room Type 第一阶段收敛为 `RM2`、`RM3`、`RM4`、`SU1`、`SU2`、`SU3`，Rate Code 第一阶段暂不建立 Account 适用关系，Q.B.D / LIAN TAI 清单作为酒店级目录候选。 |
 | `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 总览后端补齐且前端已接入，Room Information 后端展示模型第一版、前端业务化展示和 Rooming List 确认自动 DEF 后端联动已落地；已确认 Rooming List 卡第一版只做事项确认，`REVIEW_REQUIRED` 保持原业务卡内编辑并统一显示“确认卡片”；后续仍需 Payment 附件预览、Account 范围 Rate Code lookup / 校验、测试机联调和真实 PMS / OPERA / OHIP 同步。
+- 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 总览后端补齐且前端已接入，Room Information 后端展示模型第一版、前端业务化展示和 Rooming List 确认自动 DEF 后端联动已落地；已确认 Rooming List 卡第一版只做事项确认，`REVIEW_REQUIRED` 保持原业务卡内编辑并统一显示“确认卡片”；OWNER RATE Room Type / Rate Code 目录导入口径已落地，后续仍需测试机联调和真实 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/backend-to-frontend-notes.md

@@ -61,8 +61,8 @@
 | `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 目录 | 当前 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/reservation/lookups/room-types` | 查询 V4 Room Type 目录 | 必须带 Bearer token，需要 `RESERVATION_TASK_READ`，支持 `hotel_id`、`keyword`、`page_num`、`page_size`；第一版只返回当前酒店 `ACTIVE` 房型目录，不接日期过滤，不代表 PMS 全量房型。M002-V4-owner-rate-catalog-data-alignment 后固定初始化目录已收敛为 `RM2`、`RM3`、`RM4`、`SU1`、`SU2`、`SU3` 六个 code。`keyword` 匹配房型 code 时后端按稳定 code 大写归一化处理，前端可传小写；匹配显示名仍按数据库比较规则。`keyword` 无匹配时按空选项处理，不要当作目录不可用。前端在 `options_source=reservation_v4_room_type_catalog` 时调用。 |
+| `GET /api/reservation/lookups/rate-codes` | 查询 V4 Rate Code 目录 | 当前 CP11 实现支持 `hotel_id`、`keyword`、`page_num`、`page_size`，返回当前酒店 `ACTIVE` Rate Code；M002-V4-owner-rate-catalog-data-alignment 后固定初始化目录已收敛为 OWNER RATE `RATECODE (2)` 的 40 个规范化酒店级 code。2026-07-21 结论是第一阶段暂不建立 Account 与 Rate Code 的适用关系，Rate Code lookup 继续按酒店级目录返回，不要求 `account_code` / `booking_type`。`pricing_available=false` 表示后端未接真实价格，不要据此展示价格。`keyword` 匹配 Rate Code 时后端按稳定 code 大写归一化处理，前端可传小写；匹配显示名仍按数据库比较规则。前端在 `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,7 +72,7 @@
 
 前端已在系统设置下新增 `/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[]` 中可编辑字段，后端以展示快照为基准合并，未开放字段会被忽略；Room Information 卡优先提交 `confirmed_payload.room_information.final_values`，后端写入稳定确认快照并重新派生 Nights / Breakfast / Group Booking Status 文案，不写 Agent `target_order`、Adult、邮件正文、附件 URL 或前端注入字段；确认 Rooming List 卡时前端只提交 `version` 即可，若同订单为 Group 且存在可更新 Room Information 确认快照，后端会自动把 Group Booking Status 置为 `DEF` 并写审计，刷新详情时 `display_payload` / `confirmed_payload` 均显示 DEF；没有可更新投影时确认仍成功且不创建不完整 Room Information；确认前会按当前酒店数据库目录校验 Account / Room Type / Rate Code，下一阶段 `rate_code` 还必须属于已确认 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`；确认后卡片 `CONFIRMED`、内部写入确认快照 / 确认人 / 确认时间并锁定，重复确认返回错误；成功返回刷新后的订单任务详情。 |
+| `POST /api/reservation/order-tasks/{orderTaskId}/cards/{cardId}/confirm` | 确认 V4 订单任务卡 | 必须带 Bearer token，需要 `RESERVATION_TASK_CONFIRM`，请求 JSON 带 `version`，可选 `confirmed_payload`；Basic Information 必须先确认，业务卡第一版不强制逐张顺序确认；前端只提交当前卡 `fields[]` 中可编辑字段，后端以展示快照为基准合并，未开放字段会被忽略；Room Information 卡优先提交 `confirmed_payload.room_information.final_values`，后端写入稳定确认快照并重新派生 Nights / Breakfast / Group Booking Status 文案，不写 Agent `target_order`、Adult、邮件正文、附件 URL 或前端注入字段；确认 Rooming List 卡时前端只提交 `version` 即可，若同订单为 Group 且存在可更新 Room Information 确认快照，后端会自动把 Group Booking Status 置为 `DEF` 并写审计，刷新详情时 `display_payload` / `confirmed_payload` 均显示 DEF；没有可更新投影时确认仍成功且不创建不完整 Room Information；确认前会按当前酒店数据库目录校验 Account / Room Type / Rate Code，Rate Code 第一阶段暂不校验 Account 适用关系；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`；确认后卡片 `CONFIRMED`、内部写入确认快照 / 确认人 / 确认时间并锁定，重复确认返回错误；成功返回刷新后的订单任务详情。 |
 | `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` 红字提示；Room Information 复核优先使用 `/room_information/final_values/...` pointer，不允许指向 `nights`、`target_order`、Adult、Block ID、Confirmation Number 等只读 / 派生字段；成功后卡片 `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 字符串当附件或正文直渲。 |
@@ -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。Rate Code 下一阶段必须带已选 / 已确认 `account_code` 和当前业务 event `booking_type`，不能再拉全酒店全量候选。`warnings[]` 非空时可做非阻塞提示。 |
+| `GET /api/reservation/lookups/accounts` / `/room-types` / `/rate-codes` | 新增 M002 V4 CP11 数据库目录 lookup。 | 前端从任务详情 `fields[].options_source` 选择调用哪个 lookup；只提交返回项的 `code`，不要提交显示名、派生 Market / Source、目录完整对象或前端自造 code。2026-07-21 结论是 Rate Code 第一阶段仍按酒店级目录 lookup，不做 Account 过滤；未来如新增适用关系，再另行扩展联动参数。`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` 是稳定枚举查询参数，前端不要传中文文案或自造状态码。
@@ -543,7 +543,7 @@ RESERVATION_ROOMING_LIST_GENERATE
 - 业务卡目录校验会递归检查稳定模型或历史兼容结构。例如 Room Information 新结构的房型位于 `/room_information/final_values/room_items/0/room_type_code`，错误详情会使用 `room_information.final_values.room_items.0.room_type_code`；历史兼容 `UPDATE_BOOKING` 的房型可能仍使用 `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":"/room_information/final_values/room_items/0/room_type_code","value":"RM2"}]}`。`confirmed_order_id` 在订单任务归属未解决时必填；如果订单任务已经绑定订单且 `target_resolution_status=RESOLVED`，只能不传或传当前同一个订单 ID，不能借该接口切换到其它订单。`field_pointer` 必须来自当前卡 `fields[]` 中可编辑的 `basic_information.*`、`room_information.final_values.*` 或历史兼容 `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 为只读派生字段。Room Information 字段统一返回 `/room_information/final_values/...`，例如 `/room_information/final_values/arrival_date`、`/room_information/final_values/room_items/0/room_type_code`；`REVIEW_REQUIRED` 状态下只要字段仍在当前卡业务白名单内且未被前置阻塞，就会返回 `editable=true` 并允许 `review-resolution` 提交同一个 pointer；即使该叶子字段原始值缺失、详情页显示 `value=null`，前端仍可按原样提交该 pointer。查询侧 editable 计算和命令侧 pointer 校验共用同一套 Room Information 字段策略。测试机如仍出现 `V4_REVIEW_POINTER_NOT_ALLOWED`，确认部署后让后端日志检索 `review_pointer_policy=m002_v4_review_pointer_runtime_fix_v1`，日志会输出两侧 pointer 白名单、validation error pointers、`display_payload_has_room_information_final_values` 和拒绝原因。前端不要自行补未返回字段。
-- 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[]`。
+- 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 或目录完整对象；后端确认前仍会重新校验目录。2026-07-21 结论是 Rate Code 第一阶段继续按当前酒店级目录查询，不依赖 Account + `booking_type` 过滤，也不硬编码 OWNER RATE Excel 中的 Account 映射；未来如新增适用关系，再由后端接口提供联动能力。`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

@@ -51,7 +51,7 @@
 | `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 已实现；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 适用候选。 |
+| `GET /api/reservation/lookups/accounts` / `room-types` / `rate-codes` | M002 V4 CP11 已实现；M002-V4-owner-rate-catalog-data-alignment 已收敛 Room Type / Rate Code 数据；2026-07-21 结论是 Rate Code 第一阶段暂不做 Account 范围过滤 | 可以 | 用于 V4 任务卡下拉 / 搜索选择；Bearer token + `RESERVATION_TASK_READ` + 酒店访问权；Account / Room Type / Rate Code 支持 `hotel_id`、`keyword`、`page_num`、`page_size`，只返回 ACTIVE 目录。Room Type 当前固定初始化为 `RM2`、`RM3`、`RM4`、`SU1`、`SU2`、`SU3`；Rate Code 当前按酒店级目录返回 OWNER RATE 40 个规范化 code；未来如新增 Account 适用关系，再由后端扩展 `account_code` / `booking_type` 过滤参数。 |
 
 ## 3. 任务列表 / 工作台接口字段补齐
 
@@ -204,10 +204,10 @@ GET /api/reservation/orders/{orderId}
     "source_code": "TRAVEL_AGENT",
     "arrival_date": "2026-07-26",
     "departure_date": "2026-07-29",
-    "rate_code": "BAR",
+    "rate_code": "GRPA2-850UP",
     "room_items": [
       {
-        "room_type_code": "RM1",
+        "room_type_code": "RM2",
         "room_count": 2
       }
     ],
@@ -1198,7 +1198,7 @@ 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；Rate Code 下一阶段已确认要按 Account + `booking_type` 过滤，前端需等后端新增 `account_code`、`booking_type` 参数和适用性校验后再联动，不能自行硬编码 OWNER RATE Excel；真实 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；2026-07-21 结论是 Rate Code 第一阶段暂不按 Account + `booking_type` 过滤，继续使用酒店级 `RATE_CODE` 目录，前端不要硬编码 OWNER RATE Excel 中的 Account 映射；真实 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`。
 - V4 Room Information smoke 修复已完成：`REVIEW_REQUIRED` 下当前卡白名单业务字段会按 `fields[].editable=true` 暴露给前端，`/room_information/final_values/...` pointer 可用于复核提交；Basic Information 和普通业务卡的 `display_payload` / `confirmed_payload` 不返回 Agent `target_order`，普通业务卡也会移除邮件 HTML、raw evidence、附件原始 URL 和 PMS 原始响应等敏感字段；Rooming List 自动 DEF 后刷新任务详情的 Room Information `display_payload` / `confirmed_payload` 应显示 DEF，审计接口返回 `V4_ROOMING_LIST_AUTO_DEF`；当前订单详情 `order_overview` 不返回 Group Booking Status 字段。

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

@@ -124,7 +124,7 @@ 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`，不输出价格、显示名或目录对象。
+- Rate Code 第一阶段按当前酒店级 `RATE_CODE` 目录校验；2026-07-21 结论是暂不按 `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 处理，后续上线前另开迁移方案。
@@ -531,11 +531,11 @@ V4 普通业务包示例：
       },
       "arrival_date": "2026-07-26",
       "departure_date": "2026-07-29",
-      "rate_code": "GRPA1",
+      "rate_code": "GRPA2-850UP",
       "booking_scenario": "STANDARD",
       "room_items": [
         {
-          "room_type_code": "TWN",
+          "room_type_code": "RM2",
           "room_count": 2
         }
       ],
@@ -588,7 +588,7 @@ 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[].rate_code` | NEW_BOOKING 必填，可为 `null` | Rate Code 稳定 code；第一阶段只要求属于当前酒店 `ACTIVE` 的 `RATE_CODE` 目录。 |
 | `message_events[].manual_review` | 是 | 只能是 `null` 或布尔 `true`；`true` 必须能由当前对象中的未解决字段解释。 |
 | 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` 作为目标定位线索，系统不得回写修改该原始定位值。 |
@@ -608,7 +608,7 @@ V4 字段说明：
 - `PAYMENT.attachment_ids[]` 引用不存在的附件、`UPDATE_BOOKING` 携带不允许字段、目录代码无法匹配当前酒店数据库目录，以及其他 V4 event 契约错误，只写 `adapter_contract_error` transition，不创建用户可处理业务任务。
 - 技术契约错误不会自动转为 S10/S99，也不会创建前端可处理业务任务。
 
-当前仍未完成：Payment 卡附件安全摘要和预览 / 下载联动、Account + booking type 过滤 Rate Code 的后端 lookup / 校验和前端联动、真实 OPERA / OHIP、真实 PMS / OPERA / OHIP 目录同步、普通任务切换订单、SuperAgent 目录机器接口。
+当前仍未完成：真实 OPERA / OHIP、真实 PMS / OPERA / OHIP 目录同步、普通任务切换订单、SuperAgent 目录机器接口和生产目录迁移方案。
 
 ### 8.3 V3 S10/S99 结构化请求体
 

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` 已实现。Room Information 卡 New / Update / Cancel 展示模型、Nights / Breakfast / Group Booking Status 派生，以及 Rooming List 确认后 Group 自动置 `DEF` 的后端联动已实现；这些均不扩大 SuperAgent 输入字段。下一阶段已确认 Rate Code 需要按订单级 Account + `booking_type`（GROUP / FIT）过滤和校验，当前实现仍是酒店级 Rate Code 目录；Payment 卡需要补付款凭证附件安全摘要和预览 / 下载联动；真实 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` 已实现。Room Information 卡 New / Update / Cancel 展示模型、Nights / Breakfast / Group Booking Status 派生，以及 Rooming List 确认后 Group 自动置 `DEF` 的后端联动已实现；这些均不扩大 SuperAgent 输入字段。2026-07-21 OWNER RATE `RATECODE (2)` 只读整理已确认：Room Type 第一阶段只维护 `RM2`、`RM3`、`RM4`、`SU1`、`SU2`、`SU3` 六个稳定 code，不建 Account -> Room Type 关系；Rate Code 第一阶段暂不建立 Account 适用关系，Q.B.D / LIAN TAI 的 40 个规范化 Rate Code 作为酒店级目录候选；真实 PMS 同步仍后置，方案见 `M002-v4-real-catalog-lookup-api-design.md`。
 
 当前已确认开发阶段数据可以清空，因此 M002 V4 后续可以按新模型重建，不要求兼容旧任务数据、旧草稿、旧 OPERA 模拟、旧 `S000/S999`、旧 Fallback 或旧 `case_keys`。
 
@@ -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` 中返回目录错误；下一阶段 `rate_code` 还必须属于该 `order_ref` 的 Basic Information Account + 当前 event `target_order.booking_type` 的适用关系，否则同样进入 `REVIEW_REQUIRED`。用户可通过 V4 复核解阻接口提交对应字段 pointer 修正。
+- 如果 SuperAgent 输出的业务卡 `room_items[].room_type_code` 或 `rate_code` 不在当前酒店数据库目录，后端会创建 `REVIEW_REQUIRED` 业务卡，并在 `validation_errors_json` / 查询 `fields[].validation_errors` 中返回目录错误；Rate Code 第一阶段暂不校验 Account 适用关系。用户可通过 V4 复核解阻接口提交对应字段 pointer 修正。
 
 ## 8. message_events 公共字段
 
@@ -310,11 +310,11 @@ Fallback、`Need Manual Review`、独立 Voucher、旧 Payment Evidence、Vouche
   },
   "arrival_date": "2026-07-26",
   "departure_date": "2026-07-29",
-  "rate_code": "RATE_CODE",
+  "rate_code": "GRPA2-850UP",
   "booking_scenario": "STANDARD",
   "room_items": [
     {
-      "room_type_code": "TWN",
+      "room_type_code": "RM2",
       "room_count": 1
     }
   ],
@@ -336,7 +336,7 @@ Fit 条件字段：
 | --- | --- | --- | --- |
 | `arrival_date` | Group / Fit | 是，可为 `null` | 入住日期，酒店本地日期 |
 | `departure_date` | Group / Fit | 是，可为 `null` | 离店日期，酒店本地日期 |
-| `rate_code` | Group / Fit | 是，可为 `null` | 订单级 Rate Code；下一阶段必须属于该订单 Account + `booking_type` 的适用范围 |
+| `rate_code` | Group / Fit | 是，可为 `null` | 订单级 Rate Code；第一阶段只要求属于当前酒店 `ACTIVE` 的 `RATE_CODE` 目录 |
 | `room_items[]` | Group / Fit | 是 | 完整房型清单 |
 | `room_items[].room_type_code` | Group / Fit | 是，可为 `null` | 受控 RoomType code |
 | `room_items[].room_count` | Group / Fit | 是 | 房量，正整数 |
@@ -371,7 +371,7 @@ Fit 条件字段：
     "departure_date": "2026-07-30",
     "room_items": [
       {
-        "room_type_code": "TWN",
+        "room_type_code": "RM2",
         "room_count": 3
       }
     ]
@@ -447,7 +447,7 @@ Fit 条件字段：
     },
     {
       "item_type": "EXTRA_BED",
-      "target_room_type_code": "TWN",
+      "target_room_type_code": "RM2",
       "extra_bed_room_count": 1,
       "department_code": "FO+HSK"
     }
@@ -638,13 +638,13 @@ Account、RoomType、RateCode 的目录由信息系统或其主数据服务统
 规则：
 
 - 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，不要求按房型、入住日期或价格计算。
+- SuperAgent 输出 `rate_code` 时只需要输出当前酒店目录中的稳定 code；第一阶段不要求结合当前 `order_ref` 的 `basic_information.account_code` 或 event `target_order.booking_type` 判断候选范围。
 - 不允许输出自由文本或自行创造 code。
 - Agent 无法可靠匹配时，按对应业务字段的未解决规则处理。
 - Agent 输出非空 code、但信息系统目录不存在该值时，属于目录校验或契约问题。
 - Market 和 Source 由信息系统根据订单级 `account_code` 派生，不由 Agent 输出。
 
-当前项目接受“SuperAgent 确定后把目录给本系统”的落地方式。第一阶段已用固定种子目录完成开发闭环；真实目录、系统管理维护、PMS / OPERA / OHIP 同步、前端 lookup API、缓存、权限和兜底策略已在 `M002-v4-real-catalog-lookup-api-design.md` 中设计。Account 范围 Rate Code 不改变 SuperAgent V4 输入结构：SuperAgent 仍只输出稳定 `rate_code`，不输出显示名、价格或目录完整对象；适用性由本系统后端目录服务最终校验。
+当前项目接受“SuperAgent 确定后把目录给本系统”的落地方式。第一阶段已用固定种子目录完成开发闭环；真实目录、系统管理维护、PMS / OPERA / OHIP 同步、前端 lookup API、缓存、权限和兜底策略已在 `M002-v4-real-catalog-lookup-api-design.md` 中设计。OWNER RATE 第一阶段暂不引入 Account 范围 Rate Code；SuperAgent 仍只输出稳定 `rate_code`，不输出显示名、价格或目录完整对象；是否存在于当前酒店目录由本系统后端目录服务最终校验。
 
 ## 21. 后端 V4 建模建议
 
@@ -748,12 +748,10 @@ 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 下一步处理入口字段。Account + booking type 过滤 Rate Code 已确认为下一阶段待实现；真实 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 下一步处理入口字段。OWNER RATE Room Type / Rate Code 目录口径已记录，Account + Rate Code 适用关系第一阶段暂不实现；真实 PMS 同步仍未实现。
 
 当前仍未完成：
 
-- Account + booking type 过滤 Rate Code 的后端 lookup / 适用性校验和前端联动。
-- Payment 卡付款凭证附件安全摘要、图片缩略图 / 大图预览、非图片文件列表 + 下载联动。
 - 尚未接入真实 PMS / OPERA / OHIP。
 - SuperAgent 目录机器接口和生产目录同步方案仍后置。
 

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 业务审计查询、停止旧任务双写、Room Information 后端展示模型、Rooming List 确认自动 DEF 后端联动和 Payment 附件安全摘要后端第一版，后端已实现本文第 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 第一版业务展示模型、Rooming List 确认触发 Group Booking Status 自动置 `DEF`，以及 Payment 卡 `payment_attachments[]` 安全摘要。下一阶段已确认 Rate Code 需要按订单级 Account + `booking_type`（GROUP / FIT）过滤和校验，当前后端 CP11 实现仍是酒店级 Rate Code 目录，是待补齐缺口；Payment 前端仍需基于安全摘要接入缩略图 / 文件列表交互，真实预览和下载 URL 必须走 SourceMessage 原文权限链路；真实 PMS 同步继续后置，设计见 `M002-v4-real-catalog-lookup-api-design.md`。
+截至 CP14、V4 业务审计查询、停止旧任务双写、Room Information 后端展示模型、Rooming List 确认自动 DEF 后端联动和 Payment 附件安全摘要后端第一版，后端已实现本文第 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 第一版业务展示模型、Rooming List 确认触发 Group Booking Status 自动置 `DEF`，以及 Payment 卡 `payment_attachments[]` 安全摘要。2026-07-21 OWNER RATE `RATECODE (2)` 只读整理已确认：Room Type 第一阶段只维护 `RM2`、`RM3`、`RM4`、`SU1`、`SU2`、`SU3` 六个稳定 code，不建 Account -> Room Type 关系；Rate Code 第一阶段暂不建立 Account 适用关系，Q.B.D / LIAN TAI 的 40 个规范化 Rate Code 作为酒店级目录候选。真实 PMS 同步继续后置，设计见 `M002-v4-real-catalog-lookup-api-design.md`。
 
 后续如本文与 `M002-v4-agent-callback-field-contract.md` 的字段契约冲突，以字段契约为准；如与安全边界冲突，以 `security-access-control-boundary.md` 为准。
 
@@ -194,7 +194,7 @@ V4 新数据不再提供后端草稿保存。前端可以在页面本地维护
 - 用户只能从信息系统已有 Account 目录中选择。
 - 后端不得反向篡改 Agent 原始 `basic_information.manual_review`。
 
-CP11 起 Account / Market / Source 目录使用本系统数据库目录，不依赖 SuperAgent 动态提供目录文件。当前初始目录来自固定种子导入，`source_system=FIXED_SEED_IMPORT`；V24 会覆盖 `HOTEL-TEST`、`HOTEL-DEV` 和迁移执行时已有的 `ACTIVE` 酒店。后续 Account / Market / Source 优先由系统管理维护，Room Type / Rate Code 未来优先来自 PMS / OPERA / OHIP 同步，本地目录表和 lookup API 设计见 `M002-v4-real-catalog-lookup-api-design.md`。
+CP11 起 Account / Market / Source 目录使用本系统数据库目录，不依赖 SuperAgent 动态提供目录文件。当前初始目录来自固定种子导入，`source_system=FIXED_SEED_IMPORT`；V24 会覆盖 `HOTEL-TEST`、`HOTEL-DEV` 和迁移执行时已有的 `ACTIVE` 酒店。M002-V4-owner-rate-catalog-data-alignment 起，V25 和启动补种子已将 Room Type / Rate Code 固定种子收敛到 OWNER RATE 第一阶段目录。后续 Account / Market / Source 优先由系统管理维护，Room Type / Rate Code 未来优先来自 PMS / OPERA / OHIP 同步，本地目录表和 lookup API 设计见 `M002-v4-real-catalog-lookup-api-design.md`。
 
 CP11 数据库初始化种子：
 
@@ -203,10 +203,10 @@ CP11 数据库初始化种子：
 | Account | `QBD_TRAVEL`、`LIAN_TAI`、`HANATOUR_TD` |
 | Market | 由 Account 派生，当前固定为 `LEISURE` |
 | Source | 由 Account 派生，当前固定为 `TRAVEL_AGENT` |
-| Room Type | `TWN`、`KING`、`DBL`、`SGL`、`TRP`、`RM1`、`RM2`、`RM3` |
-| Rate Code | `BAR`、`RACK`、`PACKAGE`、`GROUP`、`FIT`；下一阶段候选需按 Account + `booking_type` 过滤 |
+| Room Type | `RM2`、`RM3`、`RM4`、`SU1`、`SU2`、`SU3` |
+| Rate Code | OWNER RATE `RATECODE (2)` 中 Q.B.D / LIAN TAI 的 40 个规范化酒店级候选，第一阶段暂不按 Account 过滤 |
 
-说明：Room Type / Rate Code 当前只作为确认和字段控件的第一版校验 / 选项来源代码；已开放 `GET /api/reservation/lookups/accounts|room-types|rate-codes`。Rate Code 下一阶段需引入 Account + `booking_type` 适用关系，前端不再展示全酒店 Rate Code 全量候选；房型 / 日期 / 价格过滤、真实 PMS 房型目录、Rate Code 配置中心和同步 run 后置。
+说明：Room Type / Rate Code 当前只作为确认和字段控件的第一版校验 / 选项来源代码；已开放 `GET /api/reservation/lookups/accounts|room-types|rate-codes`。Rate Code 第一阶段仍按酒店级目录 lookup；房型 / 日期 / 价格过滤、Account 适用关系、真实 PMS 房型目录、Rate Code 配置中心和同步 run 后置。
 
 ## 8. 订单归属和 target_order
 
@@ -759,7 +759,7 @@ POST /api/reservation/order-tasks/{orderTaskId}/cards/{cardId}/confirm
 - 前端只应提交当前卡 `fields[]` 中可编辑字段。后端确认时以当前卡展示快照为基准合并 `confirmed_payload`，未出现在展示快照 / 字段白名单中的字段会被忽略，不会写入 `confirmed_payload_json`。
 - Basic Information 确认时 `basic_information.account_code` 必须是当前酒店数据库 Account 目录值；后端确认前会派生 `account_name`、`market_code` 和 `source_code` 写入 `confirmed_payload_json`。
 - 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`。
+- 业务卡确认时，当前已递归校验已有 `rate_code`、`room_items[].room_type_code` 是否在当前酒店数据库目录中；Rate Code 第一阶段暂不校验 Account 适用关系。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` 并锁定。
@@ -874,9 +874,9 @@ 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 卡返回付款凭证附件安全摘要，不返回 URL；前端待接图片缩略图 + 大图预览、非图片文件列表 + 下载；预览 / 下载走 SourceMessage 原文权限链路 |
-| M002-V4-CP14.7 | Rooming List 事项确认卡 | 待实现前端轻量展示：Rooming List 卡第一版只展示事项和确认按钮，不解析名单、不预览附件、不生成 Excel、不导入 PMS |
+| M002-V4-CP14.5 | OWNER RATE 目录导入口径 | 已完成：V25 和启动补种子按人工确认结果维护 6 个 Room Type 和 Q.B.D / LIAN TAI 的 40 个酒店级 Rate Code 候选；暂不新增 Account + Rate Code 适用关系 |
+| M002-V4-CP14.6 | Payment 附件预览 | 已完成前后端第一版：Payment 卡返回付款凭证附件安全摘要，不返回 URL；前端通过 SourceMessage 原文权限链路做图片缩略图 / 大图预览和非图片下载 |
+| M002-V4-CP14.7 | Rooming List 事项确认卡 | 已完成前端轻量展示：Rooming List 卡第一版只展示事项和确认按钮，不解析名单、不预览附件、不生成 Excel、不导入 PMS |
 | M002-V4-CP14.8 | Room Information 展示模型 | 已完成前后端第一版：后端返回 `display_payload.room_information` 稳定展示模型；前端按 New / Update / Cancel 业务表单展示最终值、差异、Nights、Breakfast、Group Booking Status 和本地订单投影；Adult 不显示 |
 | M002-V4-CP14.9 | Rooming List 确认自动 DEF | 已完成后端第一版：确认 `ROOMING_LIST` 卡时，Group 同订单存在可更新 Room Information 确认快照则自动置 `DEF` 并写审计；Fit 不变更；无投影不造脏数据 |
 | M002-V4-CP14.10 | 复核态卡片字段白名单和统一确认交互 | 已完成前端第一版：`REVIEW_REQUIRED` 保持原业务卡内编辑，问题字段红字提示，前端按钮显示“确认卡片”但调用 `review-resolution`；后端 `fields[]` 返回当前卡业务字段白名单，复核写入不再只限空值或目录错误字段 |

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

@@ -4,9 +4,9 @@
 
 | 项目 | 内容 |
 | --- | --- |
-| 文档版本 | 0.4 |
-| 日期 | 2026-07-20 |
-| 状态 | CP11 已落地第一版数据库目录与 lookup API；目录管理后台 CP1 已落地后端接口；Account + booking type 过滤 Rate Code 和 Room Information 早餐派生已确认为下一阶段待实现契约；真实 PMS 同步继续后置 |
+| 文档版本 | 0.5 |
+| 日期 | 2026-07-21 |
+| 状态 | CP11 已落地第一版数据库目录与 lookup API；目录管理后台 CP1 已落地后端接口；OWNER RATE `RATECODE (2)` 只读整理已确认 Room Type 第一版只维护 6 个稳定 code，Rate Code 第一阶段暂不建立 Account 适用关系；Room Information 早餐派生和真实 PMS 同步继续后置 |
 | 适用范围 | M002 V4 Account、Market、Source、Room Type、Rate Code 目录来源、Room Information 早餐派生、数据模型、前端 lookup、缓存、酒店隔离、权限和失败兜底 |
 | 不适用范围 | 真实 OPERA / OHIP 写操作、真实价格计算、房型 / 日期 / 价格级 Rate Code 适用规则、前端页面实现、SuperAgent Prompt 修改、目录同步任务、SuperAgent 机器目录接口 |
 
@@ -16,8 +16,8 @@ M002 V4 CP8 已实现第一版固定种子目录校验；M002 V4 CP11 已把该
 
 - Basic Information 的 `account_code` 必须存在于当前酒店数据库 Account 目录。
 - Market / Source 由 Account 派生，不由 SuperAgent 输出。
-- Room Type 第一版使用当前酒店数据库目录校验和字段选项提示。
-- Rate Code 当前 CP11 实现仍是酒店级目录校验和字段选项提示；下一阶段已确认需要按订单级 Account + `booking_type`（`GROUP` / `FIT`）过滤候选和校验适用性。
+- Room Type 第一版使用当前酒店数据库目录校验和字段选项提示；2026-07-21 经需求方确认，正式业务目录先收敛为 `RM2`、`RM3`、`RM4`、`SU1`、`SU2`、`SU3` 六个稳定 code，不按 Account 限定房型可用范围。
+- Rate Code 当前 CP11 实现仍是酒店级目录校验和字段选项提示；2026-07-21 经需求方确认，第一阶段暂不建立 Account 与 Rate Code 的适用关系，先把 OWNER RATE `RATECODE (2)` 中已确认 Account 的 Rate Code 作为酒店级 `RATE_CODE` 目录候选维护。
 - Room Information 卡中 Breakfast 第一版由后端派生：Group 固定含早；Fit 按 Rate Code 中 `RB` / `RO` 判断，无法派生时要求用户在卡片中必填确认。
 - 目录错误会让对应 V4 卡片进入 `REVIEW_REQUIRED`，用户通过复核解阻选择合法 code。
 
@@ -34,11 +34,53 @@ CP11 之前固定种子实现位于后端 `ReservationV4DirectoryService` 和 `F
 | Account | Basic Information 可选目录；SuperAgent 和用户提交都使用稳定 code | `QBD_TRAVEL`、`LIAN_TAI`、`HANATOUR_TD` | 已进入数据库初始化目录，仍不是 PMS 全量 Account；后台 CP1 可新增、启用 / 停用 |
 | 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` | 已进入数据库初始化目录；当前实现仍是酒店级目录，下一阶段改为 Account + booking type 适用范围过滤；不按房型、日期或价格过滤；后台 CP1 可新增、启用 / 停用 |
+| Room Type | 房型 code 校验和字段选项提示 | `RM2`、`RM3`、`RM4`、`SU1`、`SU2`、`SU3` | 已通过 `V25__align_owner_rate_catalog_data.sql` 和启动补种子收敛为 OWNER RATE 第一阶段目录，仍不是 PMS 全量房型；后台 CP1 可新增、启用 / 停用 |
+| Rate Code | Rate Code 校验和字段选项提示 | OWNER RATE `RATECODE (2)` 的 40 个规范化 Rate Code | 已通过 `V25__align_owner_rate_catalog_data.sql` 和启动补种子收敛为当前酒店级目录；第一阶段暂不建立 Account 适用关系，不按房型、日期或价格过滤；后台 CP1 可新增、启用 / 停用 |
 
 当前固定种子只能支撑开发和演示闭环，不能作为生产长期事实源。
 
+## 2.1 OWNER RATE `RATECODE (2)` 目录整理结论
+
+本节来自 2026-07-21 对 `/Users/andy/Downloads/OWNER RATE.xlsx` 中 `RATECODE (2)` sheet 的只读整理。M002-V4-owner-rate-catalog-data-alignment 已把本节 6 个 Room Type 和 40 个 Rate Code 写入固定初始化种子与 `V25__align_owner_rate_catalog_data.sql`；不处理 `RATECODE` sheet，不新增 Account 适用关系，不改变 lookup 接口参数契约。
+
+### 2.1.1 Room Type 第一阶段稳定集合
+
+需求方已确认当前系统第一阶段只维护以下 6 个 Room Type code：
+
+| code | 中文说明 |
+| --- | --- |
+| `RM2` | 高级花园景观大床房 |
+| `RM3` | 高级花园景观双床房 |
+| `RM4` | 高级花园景观家庭房 |
+| `SU1` | 花园景观小套房（大床） |
+| `SU2` | 泳池景观小套房（大床） |
+| `SU3` | 家庭套房 |
+
+结论：
+
+- 第一阶段不建立 `Account -> Room Type` 关系表。
+- 所有 Account 默认都可使用上述 6 个 Room Type。
+- `RM2/RM3`、`SU1/SU2` 这类 Excel 组合值在后续导入或人工维护时应拆成多个候选 code；前端和 SuperAgent 最终提交仍只能提交单个稳定 `room_type_code`。
+- 其它 Excel 文本，例如 `Deluxe TWN`、`GLSPCB-1800`，暂不进入第一阶段 Room Type 目录，除非后续人工确认映射到上述 6 个 code 或新增正式房型。
+
+### 2.1.2 Q.B.D 与 LIAN TAI Rate Code 参考清单
+
+Rate Code 取 `RATECODE (2)` sheet 的 E 列原值，仅做连字符两边空格清理，例如 `GRPA2 - 850UP` 规范化为 `GRPA2-850UP`；不拆分价格、餐食、早餐地点或其它说明，不强行派生 `booking_type`。
+
+第一阶段暂不建立 `Account -> Rate Code` 适用关系。下表只记录来源 Account 下出现过的 Rate Code，便于后续导入酒店级 `RATE_CODE` 目录、人工核对或未来再建适用关系。
+
+| source_account_name | 当前系统 Account code 参考 | Rate Code 清单 |
+| --- | --- | --- |
+| `Q.B.D` | 当前固定种子为 `QBD_TRAVEL`；是否改为更短 `QBD` 待确认 | `GRPA2-850UP`、`GRPA2-1275`、`GRPA2-1400`、`GRPA2-1800`、`GRPA2-2400`、`GRPA1-900`、`GRPA1-1400`、`GRPA1-1300`、`GRPA1-1150`、`GRPA1-1725`、`GRPA1-2300`、`GRPA3-1200*B'FAST BUALUANG`、`GRPA3-2000*B'FAST BUALUANG`、`GRPA3-1400*B'FAST BUALUANG`、`GRPA3-1800*B'FAST BUALUANG`、`GRPA3-2400*B'FAST BUALUANG`、`GRPA4-1200*B'FAST LEELA`、`GRPA4-2000*B'FAST LEELA`、`GRPA4-1400*B'FAST LEELA`、`GRPA4-1800*B'FAST LEELA`、`GRPA4-2400*B'FAST LEELA` |
+| `LIAN TAI` | `LIAN_TAI` | `WHO1-850UP`、`WHO1-1275`、`WHO1-1400`、`WHO1-1800`、`WHO1-2400`、`GRP1-900`、`GRP1-1400`、`GRP1-1300`、`GRP1-1800`、`GRP1-2400`、`WHO2-1100`、`WHO2-1600`、`WHO2-1400`、`WHO2-1800`、`WHO2-2400`、`WHO3-1200`、`WHO3-1800`、`WHO3-1400`、`WHO3-2400` |
+
+目录落地口径：
+
+- 当前固定初始化和 V25 已把上表 40 个去重值作为当前酒店 `workflow_reservation_catalog_code.catalog_type=RATE_CODE` 的候选目录维护，`code` 和 `display_name` 暂相同。
+- 这些值是 OWNER RATE 人工整理口径，不等同 PMS / OPERA / OHIP 的最终 Rate Plan code。
+- `B'FAST BUALUANG`、`B'FAST LEELA`、`850UP`、数字价格等内容第一阶段只作为 Rate Code 字符串的一部分保留，不单独进入价格、早餐或餐厅规则。
+- 后续如果需求方要求按 Account 限制 Rate Code，再新建适用关系表并从本节清单回填，不影响第一阶段酒店级目录校验。
+
 ## 3. 设计目标
 
 真实目录能力要解决以下问题：
@@ -49,7 +91,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` 限定。
+7. Rate Code 第一阶段仍作为当前酒店级目录下拉；暂不按 Account、Room Type、入住日期或价格过滤。后续若需求方明确 Account 适用范围，再新增关系表和联动过滤。
 
 ## 4. 目录来源分层
 
@@ -58,7 +100,7 @@ CP11 之前固定种子实现位于后端 `ReservationV4DirectoryService` 和 `F
 | 阶段 | 来源 | 中文说明 | 适用目录 |
 | --- | --- | --- | --- |
 | Phase 0 | `FIXED_SEED_IMPORT` | CP11 已将固定种子通过 Flyway 和启动补种子流程导入数据库，不再作为运行时代码全局 Map | 当前 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 1 | `SYSTEM_MANAGED` / `IMPORT_FILE` | 本系统数据库目录，由初始化脚本、管理后台或受控导入文件维护；`IMPORT_FILE` 用于 OWNER RATE 等人工确认过的目录导入。当前结论是不先导入 Account 与 Rate Code 的适用关系 | Account、Market、Source；也可临时维护 Room Type、Rate Code |
 | Phase 2 | `PMS_SYNC` | 后端从 PMS / OPERA / OHIP 同步目录到本系统本地表，业务查询只读本地快照 | Room Type、Rate Code 优先；Account、Market、Source 视 PMS 能力再接 |
 
 原则：
@@ -75,7 +117,7 @@ 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 同步目录优先；在 PMS 未接前可由系统管理或导入文件维护 Account 适用关系 | 同步有效 Rate Plan / Rate Code；Account、booking type、房型、日期和价格适用规则逐步扩展 | 是，New Booking 选择 Rate Code | 下一阶段先按 Account + GROUP/FIT 过滤候选，只选 code，不做价格计算 |
+| Rate Code | PMS / OPERA / OHIP 同步目录优先；在 PMS 未接前可由系统管理或导入文件维护酒店级 Rate Code 目录 | 同步有效 Rate Plan / Rate Code；Account、booking type、房型、日期和价格适用规则后续按真实需求扩展 | 是，New Booking 选择 Rate Code | 第一阶段暂不按 Account 过滤，只选 code，不做价格计算 |
 
 Department 目录在 V4 字段契约中也会被 Trace 使用。当前任务详情页第一版先固定 `FO`、`HSK`、`FO+HSK` 三个 Department code，用于 Trace 卡下拉和 SuperAgent 输出约束；这不是正式数据库目录。后续可沿用本文模型扩展 `DEPARTMENT`、lookup API、系统管理维护和目录校验，不放入本 checkpoint。
 
@@ -138,11 +180,11 @@ Market、Source、Room Type、Rate Code 可先使用统一 code 表。
 uk_reservation_catalog_code(hotel_id, catalog_type, code)
 ```
 
-### 6.3 推荐表：`workflow_reservation_rate_code_applicability`
+### 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。
+Rate Code 本身仍保存在 `workflow_reservation_catalog_code` 中，`catalog_type=RATE_CODE` 表示该 code 是当前酒店已知的 Rate Code。2026-07-21 最新结论是第一阶段暂不建立 Account 与 Rate Code 的适用关系；普通 lookup 继续返回当前酒店 `ACTIVE` Rate Code 目录。
 
-本 checkpoint 只确认 Account + booking type 粒度，不纳入房型、日期和价格规则。后续如果需要按 Room Type 或入住日期进一步过滤，应在此表或独立价格规则表上扩展，不改变前端只提交稳定 `rate_code` 的基本原则。
+如果后续需求方明确“某些 Account 只能使用部分 Rate Code”，再引入本备选表表达 Account + booking type 粒度的适用关系。后续如果还需要按 Room Type 或入住日期进一步过滤，应在此表或独立价格规则表上扩展，不改变前端只提交稳定 `rate_code` 的基本原则。
 
 | 字段 | 中文说明 |
 | --- | --- |
@@ -228,7 +270,6 @@ workflows.reservation.service
     - listAccounts(...)
     - listRoomTypes(...)
     - listRateCodes(...)
-    - listRateCodesByAccountAndBookingType(...)
 
 integrations.ohip / integrations.pms
   CatalogSyncAdapter
@@ -238,7 +279,7 @@ integrations.ohip / integrations.pms
 规则：
 
 - V4 入站、确认、复核只调用 `ReservationV4DirectoryService`。
-- Basic Information 的 `account_code` 先确认或在同次复核中修正后，业务卡 Rate Code 才能按该 Account + `booking_type` 做适用性校验。
+- Rate Code 第一阶段只校验是否属于当前酒店 `ACTIVE` 的 `RATE_CODE` 目录；如未来引入 Account 适用关系，再基于 Basic Information 的 `account_code` 和业务 event 的 `booking_type` 扩展适用性校验。
 - 前端 lookup Controller 调用 `ReservationV4CatalogLookupService`，该服务同样只读本地目录表。
 - PMS / OHIP 同步 Adapter 只能写本地目录表或同步 run，不直接参与用户确认事务。
 - 如果目录服务不可用，确认接口 fail closed，不接受自由文本。
@@ -370,12 +411,10 @@ 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` | 否 | 分页 |
 
-下一阶段 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`、房型和价格过滤后置。
+当前 Rate Code lookup 保持酒店级目录查询，只返回当前酒店 `ACTIVE` Rate Code。2026-07-21 结论是第一阶段暂不接收 `account_code`、`booking_type` 作为必填过滤条件，也不按房型、入住日期、价格或 Account 限制候选；如未来引入 `workflow_reservation_rate_code_applicability`，再扩展查询参数和校验规则。
 
 响应草案：
 
@@ -383,17 +422,15 @@ GET /api/reservation/lookups/rate-codes
 {
   "hotel_id": "HOTEL-TEST",
   "catalog_type": "RATE_CODE",
-  "account_code": "QBD_TRAVEL",
-  "booking_type": "GROUP",
-  "catalog_source": "IMPORT_FILE",
-  "catalog_version": "owner-rate-20260720-v1",
+  "catalog_source": "FIXED_SEED_IMPORT",
+  "catalog_version": "owner-rate-20260721-v1",
   "stale": false,
   "items": [
     {
-      "code": "GRPA1",
-      "display_name": "GRPA1",
+      "code": "GRPA2-850UP",
+      "display_name": "GRPA2-850UP",
       "status": "ACTIVE",
-      "catalog_source": "IMPORT_FILE",
+      "catalog_source": "FIXED_SEED_IMPORT",
       "pricing_available": false
     }
   ],
@@ -409,8 +446,8 @@ GET /api/reservation/lookups/rate-codes
 前端用途：
 
 - `fields[].options_source=reservation_v4_rate_code_catalog` 时调用。
-- 只能在当前订单 Basic Information 已有有效 Account，且当前业务 event 有 `booking_type` 时调用；Account 切换后必须清空或重新校验已选 Rate Code。
-- 下一阶段只选 `rate_code`，不展示或计算真实价格。
+- 当前第一阶段可以按当前酒店目录查询 Rate Code，不要求已有 Account 或 `booking_type`。
+- 第一阶段只选 `rate_code`，不展示或计算真实价格。
 - V4 契约仍禁止 `UPDATE_BOOKING` 携带 Rate Code；lookup API 不改变该规则。
 
 ### 8.4 Market / Source Lookup
@@ -427,7 +464,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?account_code=...&booking_type=...` | 渲染当前 Account + GROUP/FIT 适用的 Rate Code 搜索选择 |
+| `reservation_v4_rate_code_catalog` | `GET /api/reservation/lookups/rate-codes` | 渲染当前酒店级 Rate Code 搜索选择 |
 | `static_enum` | 使用 `fields[].enum_options` | 不调用 lookup |
 | `system_case_lookup` | 后续订单 / 任务对象 lookup | 不属于本目录 checkpoint |
 
@@ -537,7 +574,7 @@ SuperAgent 当前不调用本 lookup API。SuperAgent 目录供给后续有两
 2. 遍历每张卡 `fields[]`。
 3. 只有字段 `editable=true` 且 `control_type=select/lookup` 时才加载 lookup。
 4. 根据 `options_source` 选择 lookup 接口。
-5. Rate Code 字段必须先取得当前订单 Basic Information 的 Account 和当前业务 event 的 `booking_type`；缺任一条件时禁用或显示空态，不调用全酒店 Rate Code 全量查询。
+5. Rate Code 字段第一阶段按当前酒店级目录查询；如未来引入 Account 适用关系，再要求先取得当前订单 Basic Information 的 Account 和当前业务 event 的 `booking_type`。
 6. 搜索输入做 debounce，不一次性拉全量。
 7. 显示 `stale=true` 或 `warnings[]` 时给用户非阻塞提醒。
 8. 用户提交确认或复核时只提交 code，不提交显示名、Market / Source 派生值或目录完整对象。
@@ -546,7 +583,7 @@ SuperAgent 当前不调用本 lookup API。SuperAgent 目录供给后续有两
 前端禁止：
 
 - 硬编码 PMS 房型或 Rate Code 全集。
-- 硬编码 OWNER RATE Excel 中 Account 到 Rate Code 的映射；该映射必须由后端目录 / 适用关系接口提供。
+- 硬编码 OWNER RATE Excel 中 Account 到 Rate Code 的映射；当前仅允许后端目录维护酒店级 Rate Code，未来若引入适用关系也必须由后端接口提供。
 - 把目录显示名当业务 code 提交。
 - 绕过 `fields[]` 自行补业务字段。
 - 使用 lookup API 给 SuperAgent、AgentBus 或 Debug 链路拼接输入。
@@ -560,11 +597,11 @@ 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-CP14.5 | OWNER RATE 目录导入口径 | 已完成：固定初始化种子和 V25 已把 Room Type 收敛为 `RM2`、`RM3`、`RM4`、`SU1`、`SU2`、`SU3`，并将 Q.B.D / LIAN TAI 的 40 个 Rate Code 候选作为酒店级 `RATE_CODE` 目录维护；暂不新增 Account + Rate Code 适用关系 |
 | M002-V4-CP15 | PMS / OPERA / OHIP 目录同步 | 同步 Adapter、同步 run 表、失败重试、最后成功快照、同步状态管理入口 |
 | M002-V4-CP16 | SuperAgent 目录供给 | 明确目录版本如何给 SuperAgent，必要时新增机器目录接口或导出包 |
 
-CP11 已作为后端第一步落地，因为它不依赖真实 PMS，也能让前端后续不再硬编码当前固定种子。CP13 CP1 继续沿用本地目录表，不接真实 PMS，也不改变 SuperAgent 输入契约。
+CP11 已作为后端第一步落地，因为它不依赖真实 PMS，也能让前端后续不再硬编码当前固定种子。CP13 CP1 继续沿用本地目录表，不接真实 PMS，也不改变 SuperAgent 输入契约。CP14.5 已完成 OWNER RATE 目录数据收口，但只替换系统固定种子；测试 / 开发库如果存在人工新增的旧 Room Type / Rate Code，需要按本文第 16 节的限定 SQL 清理或重建。
 
 ## 15. 仍需确认的问题
 
@@ -572,8 +609,48 @@ 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 已确认下一阶段按 `account_code + booking_type` 过滤；入住日期、房型和价格是否也要进入过滤仍待后续确认。
+5. Rate Code 第一阶段已确认暂不按 `account_code + booking_type` 过滤；如未来出现 Account 专属候选、入住日期、房型或价格过滤诉求，再单独确认是否引入适用关系或价格规则表。
 6. 生产是否允许 `FIXED_SEED` 作为兜底，还是只允许 dev/test 使用。
 7. SuperAgent 是否需要读取目录；如果需要，是离线给目录包，还是新增 HMAC 机器接口。
 
 在这些问题未确认前，当前实现仍按 DB 管理目录 + 前端 lookup 查询 + 后台 CP1 手工维护闭环推进，不接真实 PMS，也不替换 SuperAgent 输入契约。
+
+## 16. 测试 / 开发库 OWNER RATE 目录清理步骤
+
+`V25__align_owner_rate_catalog_data.sql` 只替换 `source_system=FIXED_SEED_IMPORT` 的 Room Type / Rate Code 固定种子，不清理人工通过管理后台新增的目录项。测试机或开发库如果在 V25 前已经手工新增了旧目录值，且希望 lookup 严格只返回本阶段 6 个 Room Type 和 40 个 Rate Code，可以先备份后执行下面的限定更新。该步骤只停用当前酒店旧 Room Type / Rate Code，不清理 Account、Market、Source、用户、权限、SourceMessage、V4 order task 或 task card。
+
+```sql
+-- 执行前先确认目标酒店。
+SET @target_hotel_id = 'HOTEL-TEST';
+
+UPDATE workflow_reservation_catalog_code
+SET status = 'DISABLED',
+    updated_at = UTC_TIMESTAMP(6),
+    version = version + 1
+WHERE hotel_id = @target_hotel_id
+  AND catalog_type = 'ROOM_TYPE'
+  AND status = 'ACTIVE'
+  AND code NOT IN ('RM2', 'RM3', 'RM4', 'SU1', 'SU2', 'SU3');
+
+UPDATE workflow_reservation_catalog_code
+SET status = 'DISABLED',
+    updated_at = UTC_TIMESTAMP(6),
+    version = version + 1
+WHERE hotel_id = @target_hotel_id
+  AND catalog_type = 'RATE_CODE'
+  AND status = 'ACTIVE'
+  AND code NOT IN (
+      'GRPA2-850UP', 'GRPA2-1275', 'GRPA2-1400', 'GRPA2-1800', 'GRPA2-2400',
+      'GRPA1-900', 'GRPA1-1400', 'GRPA1-1300', 'GRPA1-1150', 'GRPA1-1725', 'GRPA1-2300',
+      'GRPA3-1200*B''FAST BUALUANG', 'GRPA3-2000*B''FAST BUALUANG',
+      'GRPA3-1400*B''FAST BUALUANG', 'GRPA3-1800*B''FAST BUALUANG',
+      'GRPA3-2400*B''FAST BUALUANG',
+      'GRPA4-1200*B''FAST LEELA', 'GRPA4-2000*B''FAST LEELA',
+      'GRPA4-1400*B''FAST LEELA', 'GRPA4-1800*B''FAST LEELA',
+      'GRPA4-2400*B''FAST LEELA',
+      'WHO1-850UP', 'WHO1-1275', 'WHO1-1400', 'WHO1-1800', 'WHO1-2400',
+      'GRP1-900', 'GRP1-1400', 'GRP1-1300', 'GRP1-1800', 'GRP1-2400',
+      'WHO2-1100', 'WHO2-1600', 'WHO2-1400', 'WHO2-1800', 'WHO2-2400',
+      'WHO3-1200', 'WHO3-1800', 'WHO3-1400', 'WHO3-2400'
+  );
+```

docs/project/requirements/M002-v4-test-machine-smoke-checklist.md

@@ -91,7 +91,7 @@ GET /api/reservation/order-tasks/{orderTaskId}
 ```text
 GET /api/reservation/lookups/accounts?hotel_id=HOTEL-TEST&keyword=QBD
 GET /api/reservation/lookups/room-types?hotel_id=HOTEL-TEST&keyword=RM2
-GET /api/reservation/lookups/rate-codes?hotel_id=HOTEL-TEST&keyword=GROUP
+GET /api/reservation/lookups/rate-codes?hotel_id=HOTEL-TEST&keyword=GRPA2
 ```
 
 期望：

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

@@ -54,11 +54,11 @@
 | `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` + 酒店访问权，并强制 `account_code` + `booking_type=GROUP/FIT` 过滤；只返回当前酒店、当前 Account、当前 booking type 可选 ACTIVE Rate Code 目录快照，不做真实价格计算 | 只读查询默认不写业务审计；不得返回 PMS 原始响应、价格明细、Secret、跨酒店 Rate Plan 或其他 Account 的 Rate Code 适用关系 |
+| `GET /api/reservation/lookups/room-types` | `FRONTEND_USER` | 已实现 M002 V4 CP11；M002-V4-owner-rate-catalog-data-alignment 后固定初始化目录收敛为 6 个 OWNER RATE Room Type；强制 Bearer 登录 + `RESERVATION_TASK_READ` + 酒店访问权 | 保持登录 + `RESERVATION_TASK_READ` + 酒店访问权；只返回当前酒店可选 ACTIVE 房型目录快照 | 只读查询默认不写业务审计；不得返回 PMS 原始响应、价格敏感细节或跨酒店房型 |
+| `GET /api/reservation/lookups/rate-codes` | `FRONTEND_USER` | 已实现 M002 V4 CP11；M002-V4-owner-rate-catalog-data-alignment 后固定初始化目录收敛为 OWNER RATE 40 个规范化 Rate Code；当前实现仍是酒店级目录 | 2026-07-21 结论是第一阶段继续保持登录 + `RESERVATION_TASK_READ` + 酒店访问权，并按当前酒店 `ACTIVE` Rate Code 目录返回；暂不强制 `account_code` + `booking_type=GROUP/FIT` 过滤，不做真实价格计算 | 只读查询默认不写业务审计；不得返回 PMS 原始响应、价格明细、Secret、跨酒店 Rate Plan；未来如新增 Account 适用关系，也不得泄露其他 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；Rooming List 卡确认只表示事项已人工处理，不新增名单解析、附件预览、Excel 生成或 PMS 导入权限；Payment 第一版确认只提交 `version` 和必要审计说明，不提交 `attachment_ids[]`、附件 URL 或完整附件对象；同订单为 Group 时确认 Rooming List 已自动把可更新 Room Information 确认快照中的 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 自动变更或跳过都必须记录 `V4_ROOMING_LIST_AUTO_DEF` 安全摘要 |
+| `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 已自动把可更新 Room Information 确认快照中的 Group Booking Status 置为 `DEF`，没有可更新投影时不创建不完整事实；Basic Account、Room Type、Rate Code 目录错误返回 `V4_FIELD_VALIDATION_FAILED`；Rate Code 第一阶段只校验当前酒店 `ACTIVE` 目录存在，暂不校验 Account 适用关系 | 必须写业务审计，actor 使用当前登录用户；Rooming List 触发的 Group Booking Status 自动变更或跳过都必须记录 `V4_ROOMING_LIST_AUTO_DEF` 安全摘要 |
 | `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` + 酒店访问权 | 必须写业务审计和原因 |