前端调整V4预订事项用户化展示

docs/project/README.md

@@ -46,7 +46,7 @@
 | `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 后端联动；已补 OWNER RATE Room Type / Rate Code 目录口径、Payment 附件预览、Rooming List 事项确认卡、V4 复核态卡片交互和可编辑字段白名单文档口径；开发阶段不维护 V2/V3 旧任务兼容，测试数据可重建，生产迁移策略后置。 |
+| `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 复核态卡片交互、可编辑字段白名单和 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` 为准。 |
@@ -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` 保持原业务卡内编辑并统一显示“确认卡片”；OWNER RATE Room Type / Rate Code 目录导入口径已落地，后续仍需测试机联调和真实 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 目录导入口径已落地；V4 工作台 / 订单详情 / 任务详情页默认面向普通酒店员工，技术信息只允许放在高级筛选、折叠区或受控调试模式；真实 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

@@ -159,6 +159,8 @@ POST /api/auth/logout
 
 订单详情已经补齐并完成前端接入 V4 订单页总览字段：`order_overview`、`next_v4_action`、`related_source_messages[]` 和增强后的 `v4_order_tasks[].cards[]`。订单详情页定位为订单视角总览，不要在订单详情页直接编辑、确认或复核任务卡；点击 `next_v4_action.order_task_id` 或时间线 `order_task_id` 后进入 `/reservation/order-tasks/{orderTaskId}` 对应的 V4 订单任务详情页处理。
 
+订单详情页默认面向普通酒店员工，不面向开发 / 测试。页面标题、摘要和时间线区域应使用业务语言：`order_overview` 显示为“当前确认快照”或“订单信息总览”，`next_v4_action` 显示为“下一步处理”，`related_source_messages[]` 显示为“关联来源邮件”，`v4_order_tasks[]` 显示为“处理记录”或“来源邮件处理记录”，`cards[]` 显示为事项状态摘要。不要在默认主信息层级展示 `V4`、`order_id`、`order_task_id`、`card_id`、`source_message_id`、`action_type`、`action_status`、payload 字段名、route 或内部状态码；确需排查时只能放入折叠区或受控调试模式。订单详情主区域不展示确认 / 复核按钮，所有办理动作仍跳转到 V4 任务详情页。
+
 `order_overview` 只从已确认 V4 卡片派生：Basic Information 未确认时 Account / Market / Source 为空；Room Information 未确认时日期、Rate Code、房型房量为空。前端不要把未确认卡片 display payload 反推成订单事实。
 
 订单详情新增的 V4 `v4_order_tasks[]` 每项只返回订单任务安全摘要：
@@ -496,7 +498,15 @@ 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/tasks` 默认面向普通酒店员工，页面名称和空态应使用“待处理预订事项”“预订事项”“暂无需要处理的预订事项”等业务语言，不直接显示“V4 工作台”“Order Task 列表”“任务卡列表”等技术描述。
+- 任务列表默认视图优先展示需要用户处理的事项，例如待确认、需要复核、待确认已读的来源通知；已完成事项保留筛选入口，但不作为默认工作队列。`ORDER_TASK` 显示为“预订事项”，`SOURCE_NOTIFICATION` 显示为“来源通知”或“需查看邮件”，不直接展示内部 `item_type` code。
+- 任务列表普通筛选建议为“全部”“待处理”“需要复核”“已完成”“来源通知”；技术筛选如 `item_type`、`order_task_status`、`card_status`、`route_code`、`system_process_category` 只能放在高级筛选或受控调试模式，不作为默认筛选文案。
+- 任务类型标签应映射为业务名称，例如新预订、修改预订、取消预订、付款凭证、跟进事项、房表事项；前端业务判断仍使用稳定 code，不使用展示文案反推类型。
 - `/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/order-tasks/{orderTaskId}` 默认面向普通酒店员工，页面定位是“订单事项办理页”，不是“V4 任务卡模型调试页”。前端默认主标题、摘要和业务事项区域不得直接展示 `V4`、Task Card 模型、`order_task_id`、`card_id`、`order_ref`、`source_event_index`、`version`、JSON Pointer、`write_target`、payload 字段名、`route_code`、adapter 诊断或内部状态码；这些字段只能用于路由、提交、并发和排查，确需展示时放入折叠区或受控调试模式。
+- V4 任务详情普通用户文案应使用业务名称：Basic Information 展示为“预订基础信息”，Room Information 展示为“房型与日期”或“房型信息”，Payment 展示为“付款凭证”，Trace 展示为“跟进事项”，Rooming List 展示为“房表事项”，SourceMessage Display 展示为“来源邮件”。`PENDING_CONFIRM`、`REVIEW_REQUIRED`、`CONFIRMED`、`RESOLVED`、`OPEN`、`COMPLETED` 等稳定 code 只能作为业务判断依据，页面应映射为“待确认”“需要复核”“已确认”“复核已完成”“待处理”“已完成”等用户可理解文案。
+- V4 任务详情顶部摘要优先回答“这封邮件识别出了什么事项、当前还有什么要处理、下一步该点哪里”，不要把卡片数量、数据库 ID 或模型字段作为第一视觉层级。已完成事项可以折叠为摘要，待处理和需复核事项应突出；来源邮件固定在业务事项之后，默认折叠正文。
+- 每张事项卡的主动作按钮放在该事项卡右侧，和状态同区域展示；移动端空间不足时可放到卡片底部右对齐。不要做页面底部统一确认按钮，避免用户误以为一次确认整页。`REVIEW_REQUIRED` 仍显示“确认卡片”，但前端内部调用 `review-resolution`。
 - `/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=confirmed_payload` 的字段构造 `confirmed_payload`。
@@ -507,6 +517,7 @@ RESERVATION_ROOMING_LIST_GENERATE
 - Trace 卡第一版使用稳定业务展示模型：普通事项内容字段统一为 `trace_items[].text`，不要使用或提交 `trace_items[].content`；`GENERAL` 的可编辑字段为 `/trace_items/{index}/text` 和 `/trace_items/{index}/department_code`，`EXTRA_BED` 的可编辑字段为 `/trace_items/{index}/target_room_type_code`、`/trace_items/{index}/extra_bed_room_count` 和 `/trace_items/{index}/department_code`。`department_code` 固定下拉 `FO`、`HSK`、`FO+HSK`，后端在对应字段返回 `options_source=reservation_v4_trace_department_fixed` 和 `fixed_options[]`；`target_room_type_code` 使用 Room Type lookup，`extra_bed_room_count` 为正整数；确认和复核都只提交 `fields[]` 暴露的白名单 pointer，不要提交 `target_order`、邮件正文、附件 URL、raw evidence 或 Agent 原始 payload。
 - 前端不展示 `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` 的邮件正文默认做长度折叠，用户可展开全文。
+- 技术折叠区或调试模式也必须遵守同一安全边界：不得展示邮件正文、HTML、附件 URL、AI 原始 payload、raw evidence、PMS 原始响应、Secret、Token 或跨酒店数据。若后续需要专门 Debug 视图，应按 `FRONTEND_DEBUG` 能力和安全边界另行登记，不要把 Debug 信息混入普通业务办理页。
 - 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 的最新包；前端不要为了该旧响应重新做兼容逻辑，避免把部署问题固化成页面分支。
 

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

@@ -53,6 +53,30 @@
 | `GET /api/reservation/task-card-field-whitelist` | 未发现后端实现 | 不可以 | 若任务详情 `fields[]` 已补齐 3.0 元数据，可后置。 |
 | `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` 过滤参数。 |
 
+## 2.2 V4 工作台、订单详情和任务详情页用户化展示口径
+
+2026-07-21 已确认：V4 工作台 / 任务列表、订单详情页和任务详情页默认面向普通酒店员工，不面向开发 / 测试。当前后端 `GET /api/reservation/workbench-items`、`GET /api/reservation/order-tasks`、`GET /api/reservation/orders/{orderId}` 和 `GET /api/reservation/order-tasks/{orderTaskId}` 已返回前端完成第一版用户化展示所需的业务数据、订单确认快照、下一步入口、`fields[]` 白名单、`availability`、来源邮件摘要和安全 payload；本 checkpoint 原则上不要求后端新增接口或改变入站 / 确认 / 复核模型。
+
+前端下一轮 UX 重构应按以下口径实现：
+
+- 工作台 / 任务列表页面定位为“待处理预订事项列表”或“预订事项工作台”，不是“V4 模型工作台”。
+- 任务列表默认视图优先展示待确认、需要复核、待确认已读的来源通知；已完成事项保留筛选入口，不作为默认工作队列。
+- 任务列表普通筛选建议为“全部”“待处理”“需要复核”“已完成”“来源通知”。技术筛选如 `item_type`、`order_task_status`、`card_status`、`route_code`、`system_process_category` 可放入高级筛选或受控调试模式，不作为默认筛选文案。
+- `ORDER_TASK` 用户可见文案为“预订事项”，`SOURCE_NOTIFICATION` 用户可见文案为“来源通知”或“需查看邮件”；新预订、修改预订、取消预订、付款凭证、跟进事项、房表事项等任务类型应显示业务名称，不直接展示内部 code。
+- 列表行主动作使用“继续处理”“查看详情”“确认已读”等业务语言；空态使用“暂无需要处理的预订事项”，不显示内部模型空态。
+- 订单详情页定位为“订单总览页”，不是 V4 时间线调试页；`order_overview` 显示为“当前确认快照”或“订单信息总览”，`next_v4_action` 显示为“下一步处理”，`related_source_messages[]` 显示为“关联来源邮件”，`v4_order_tasks[]` 显示为“处理记录”或“来源邮件处理记录”，`cards[]` 显示为事项状态摘要。
+- 订单详情页标题优先显示订单业务名、Group Code、Confirmation Number 或用户可理解订单名称；不把数据库 `order_id`、V4 字段名、`order_task_id`、`card_id`、`source_message_id`、`action_type`、`action_status` 等作为主信息层级。订单详情不展示确认 / 复核按钮，所有办理动作仍跳转到任务详情页。
+- 页面定位为“订单事项办理页”，不是“V4 任务卡模型调试页”。
+- 主标题、顶部摘要和业务事项区域使用普通用户可理解文案，不直接展示 `V4`、Task Card 模型、`order_task_id`、`card_id`、`order_ref`、`source_event_index`、`version`、JSON Pointer、`write_target`、payload 字段名、`route_code` 或内部状态码。
+- 技术字段可以继续用于路由、提交、并发校验、错误定位和自动化测试；确需展示时只能放在“技术信息”折叠区或受控调试模式，不得占据默认主信息层级。
+- 用户可见业务名称建议：Basic Information = 预订基础信息；Room Information = 房型与日期 / 房型信息；Payment = 付款凭证；Trace = 跟进事项；Rooming List = 房表事项；SourceMessage Display = 来源邮件。
+- 用户可见状态建议：`PENDING_CONFIRM` = 待确认；`REVIEW_REQUIRED` = 需要复核；`CONFIRMED` = 已确认；`RESOLVED` = 复核已完成；`OPEN` = 待处理；`COMPLETED` = 已完成。前端业务判断仍使用稳定 code，不使用展示文案反推状态。
+- 顶部摘要应优先表达“这封邮件识别出了什么事项、当前还有什么要处理、下一步该点哪里”；已完成事项可以折叠为摘要，待处理和需复核事项应突出。
+- 每张事项卡的主动作按钮放在该事项卡右侧，和状态同区域展示；移动端空间不足时可放到卡片底部右对齐。不要做页面底部统一确认按钮。`PENDING_CONFIRM` 和 `REVIEW_REQUIRED` 的用户可见主按钮都叫“确认卡片”，但前端内部仍按状态分别调用普通确认或 `review-resolution`。
+- 来源邮件固定放在业务事项之后，默认折叠正文；正文、图片预览和非图片下载仍走 `GET /api/source-messages/{sourceMessageId}/conversation` 原文权限链路。
+
+如果前端实现时发现现有接口不足，可单独向后端提出字段补充，例如用户友好的 `display_title`、任务级 `next_step_label`、业务摘要短句或调试区可见性标记；在提出前不得由前端自行展示 AI 原始 payload 或解析后端内部字段来补标题。
+
 ## 3. 任务列表 / 工作台接口字段补齐
 
 建议路径：

docs/project/frontend-development-guidelines.md

@@ -154,6 +154,7 @@ th-TH
 - 避免引入大型 Admin Template。
 - 页面应优先表达业务主线，而不是堆叠技术字段。
 - Debug 页面可以显示技术 ID，但业务页面应优先展示可理解的业务状态和来源摘要。
+- V4 工作台 / 任务列表、订单详情页和任务详情页默认面向普通酒店员工，应呈现为“待处理预订事项列表”“订单总览页”和“订单事项办理页”；`V4`、`ORDER_TASK`、`SOURCE_NOTIFICATION`、Task Card 模型、JSON Pointer、payload、version、route、数据库 ID 等技术信息不得出现在默认主信息层级，只能放在高级筛选、折叠区或受控调试模式。
 - 预检、人工复核、任务确认要清楚区分：
   - 外部 Provider 建议
   - 人工确认值
@@ -345,13 +346,16 @@ pnpm test -- SomeSpecName.spec.ts
 中文说明：
 
 - 任务列表是独立菜单，服务于“按任务处理”的工作方式，不是订单列表的复制。
-- 列表数据来自 `GET /api/reservation/tasks`；该接口已存在第一版，前端应直接接真实接口，不展示 fixture 假数据。
+- 本低保真结构图主要记录 V2/V3 旧任务列表结构；V4 默认工作台 `/reservation/tasks` 应按 `M002-v4-order-task-card-domain-model-cp2.md` 的用户化契约使用 `GET /api/reservation/workbench-items` 和 `GET /api/reservation/order-tasks`，展示“待处理预订事项 / 预订事项”，不直出 `ORDER_TASK`、`SOURCE_NOTIFICATION`、`card_status` 等技术筛选文案。
+- V2/V3 历史列表数据来自 `GET /api/reservation/tasks`；该接口已存在第一版，前端应直接接真实接口，不展示 fixture 假数据。
 - 每行任务至少展示 `task_id`、关联订单、任务卡名称、任务类型 / 子类型、任务状态、队列顺序、是否可处理、只读原因和来源邮件摘要。
 - 每行操作保留“查看任务”“查看订单”“查看邮件会话”三个入口；邮件会话入口按该任务的 `source_message_id` 或 `external_conversation_id` 打开。
 - 如果来源邮件会话字段暂未接入，邮件会话入口置灰或展示“接口待补”，不使用假会话数据。
 
 ### 18.3 订单详情与任务卡低保真结构图
 
+本节低保真结构图保留 V2/V3 旧任务流的页面骨架。V4 订单详情页默认是普通酒店员工使用的“订单总览页”，只展示订单当前确认快照、下一步处理、关联来源邮件和处理记录摘要；不在订单详情页直接渲染当前任务卡、保存草稿、确认任务或 OPERA 模拟操作。V4 订单详情、任务详情和工作台的当前展示契约以 `M002-v4-order-task-card-domain-model-cp2.md` 和前后端协作文档为准。
+
 ```text
 ┌────────────────────────────────────────────────────────────────────────────┐
 │ 订单详情  GRP-001 / TMP-20260707-0001        ACTIVE / TEMPORARY             │
@@ -384,7 +388,7 @@ pnpm test -- SomeSpecName.spec.ts
 
 中文说明：
 
-- 订单详情页必须沿用“订单归档容器 + 同订单任务队列 + 当前任务卡 + OPERA 模拟操作 + 审计时间线”的既有结构，不另起一套订单详情布局。
+- V2/V3 旧订单详情页沿用“订单归档容器 + 同订单任务队列 + 当前任务卡 + OPERA 模拟操作 + 审计时间线”的既有结构；V4 订单详情页不沿用该“当前任务卡 + OPERA 模拟操作”主布局，而是作为订单总览页，通过下一步入口跳转到 V4 任务详情页办理。
 - 后续任务如果被前置任务阻塞，应在任务队列和任务卡操作区同时体现只读状态。
 - 任务卡字段必须按后端字段矩阵分组渲染，不直接把 AI 原始 JSON 展示成自由表单。
 - 邮件入口按任务粒度展示：每个任务可能来自不同 `source_message_id`，也可能落在不同 `external_conversation_id`。点击“邮件会话”只打开该任务来源消息所在的完整邮件会话，不代表订单下所有来源消息的合集。

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

@@ -271,6 +271,66 @@ V4 当前不做 OPERA / PMS 执行，但仍需要保留同订单处理顺序，
 - Rooming List 卡第一版没有可编辑业务字段；页面展示为轻量事项确认卡，用户点击“确认卡片”仅表示已人工处理当前 Rooming List 事项，不代表名单已解析、Excel 已生成或 PMS 已导入。
 - Room Information 卡下一阶段采用业务展示模型，不再只依赖通用 `fields[]` 扁平渲染；具体规则见“Room Information 卡展示模型”。
 
+### 9.1.1 V4 任务详情页用户化展示边界
+
+2026-07-21 已确认：`/reservation/order-tasks/{orderTaskId}` 默认面向普通酒店员工，不面向开发 / 测试。该页面的产品定位是“订单事项办理页”，不是“V4 任务卡模型调试页”。底层仍保持 Order Task / Task Card / SourceMessage 领域模型不变，但前端默认展示必须把模型语言翻译成业务语言。
+
+展示口径：
+
+- 页面主标题不直接使用“V4”“后端任务卡模型”“Task Card 模型”等技术描述，建议使用“处理预订事项”“订单事项处理”等业务文案。
+- `Reservation Task Card` 在普通页面上显示为“事项”“待确认事项”或具体业务名称，不直接称为“卡片模型”。
+- `SOURCE_MESSAGE_DISPLAY` 面向用户显示为“来源邮件”，固定在业务事项之后，默认折叠正文；正文仍只通过 SourceMessage conversation 权限链路读取。
+- Basic Information 显示为“预订基础信息”，Room Information 显示为“房型与日期”或“房型信息”，Payment 显示为“付款凭证”，Trace 显示为“跟进事项”，Rooming List 显示为“房表事项”。
+- 技术 ID、`order_task_id`、`card_id`、`source_event_index`、`order_ref`、`version`、`route_code`、JSON Pointer、`write_target`、payload 字段名、adapter 诊断和内部状态码默认不得出现在主摘要或业务事项区域；确需排查时只能放在折叠区或受控调试模式。
+- 普通用户可见状态应使用业务文案映射，例如 `PENDING_CONFIRM` 显示为“待确认”，`REVIEW_REQUIRED` 显示为“需要复核”，`CONFIRMED` 显示为“已确认”，`RESOLVED` 显示为“复核已完成”，`OPEN` / `COMPLETED` 显示为“待处理” / “已完成”。
+- 顶部摘要优先回答“这封邮件识别出了什么事项、当前还有什么要处理、下一步该点哪里”，而不是优先展示卡片数量和数据库 ID；已完成事项可以折叠为摘要，待处理或需复核事项应突出。
+- 每张可处理事项卡的主动作按钮放在该事项卡右侧，和该卡状态同区域展示；`PENDING_CONFIRM` 和 `REVIEW_REQUIRED` 的用户可见主按钮均为“确认卡片”，但前端内部仍按卡片状态分别调用普通确认或复核解阻接口。已确认事项不显示主动作按钮，只显示“已确认”或“复核已完成”等状态。移动端可降级为卡片底部右对齐，但仍属于当前事项卡，不做页面底部统一确认按钮。
+
+安全边界：
+
+- 技术折叠区或调试模式也不得展示邮件正文、HTML、附件 URL、AI 原始 payload、raw evidence、PMS 原始响应、Secret、Token 或跨酒店数据。
+- 如果后端接口为了路由、并发和提交必须返回 ID、`version`、`fields[]`、`write_target` 等稳定技术字段，前端可以用于内部逻辑，但默认用户页面不得把这些字段原样作为主文案。
+- 本节只约束展示和信息层级，不改变 V4 入站、确认、复核、审计、权限、酒店隔离或 SourceMessage 读取链路。
+
+### 9.1.2 V4 工作台 / 任务列表用户化展示边界
+
+`/reservation/tasks` 默认面向普通酒店员工，产品定位是“待处理预订事项列表”或“预订事项工作台”，不是 V4 模型列表。该页面可以继续使用 `GET /api/reservation/workbench-items` 和 `GET /api/reservation/order-tasks` 的稳定 code 做查询、路由和筛选，但普通用户可见文案不得直接暴露内部 item type、card status 或 route 语汇。
+
+默认展示口径：
+
+- 列表标题建议使用“待处理预订事项”“预订事项”或“工作台”，不直接使用“V4 工作台”“Order Task 列表”“任务卡列表”等技术描述。
+- 默认视图优先展示需要用户处理的事项，例如待确认、需要复核、待确认已读的来源通知；已完成事项保留筛选入口，但不应淹没默认工作队列。
+- `ORDER_TASK` 面向用户显示为“预订事项”，`SOURCE_NOTIFICATION` 面向用户显示为“来源通知”或“需查看邮件”，不直接展示内部 `item_type` code。
+- 任务类型面向用户显示为业务名称，例如新预订、修改预订、取消预订、付款凭证、跟进事项、房表事项；不要默认展示 `NEW_BOOKING`、`TRACE_RESERVATION_NOTES`、`ROOMING_LIST`、`PAYMENT` 等技术 code。
+- 筛选项第一版面向普通用户建议为“全部”“待我处理 / 待处理”“需要复核”“已完成”“来源通知”。技术筛选如 `item_type`、`order_task_status`、`card_status`、`route_code`、`system_process_category` 可放入高级筛选或受控调试模式，不作为默认筛选文案。
+- 列表行主动作保持业务化，例如“继续处理”“查看详情”“确认已读”；不把 V4 入口、旧任务 fallback 或 SourceMessage 模型差异暴露给普通用户。
+- 空态文案使用业务语言，例如“暂无需要处理的预订事项”，不要显示“暂无 ORDER_TASK”或“暂无 V4 card_status 匹配结果”。
+
+安全边界：
+
+- 列表默认不展示邮件正文、附件 URL、AI 原始 payload、adapter 诊断、raw evidence、JSON Pointer、数据库 ID 或 route 诊断；必要的技术信息只能用于内部逻辑、高级筛选或受控调试模式。
+- 高级筛选或调试模式不得突破酒店隔离、权限、SourceMessage 原文读取权限和敏感数据脱敏规则。
+
+### 9.1.3 V4 订单详情页用户化展示边界
+
+`/reservation/orders/{orderId}` 默认面向普通酒店员工，产品定位是“订单总览页”，不是 V4 时间线或任务卡调试页。该页面只展示订单当前确认快照、下一步处理入口、关联来源邮件和处理记录摘要，不在订单详情页直接确认、复核或编辑任务卡；具体办理动作仍进入 `/reservation/order-tasks/{orderTaskId}`。
+
+展示口径：
+
+- 页面标题优先显示订单业务名、Group Code、Confirmation Number 或用户可理解的订单名称，不把数据库 `order_id`、V4 字段名或内部 ID 作为第一视觉层级。
+- `order_overview` 面向用户显示为“当前确认快照”或“订单信息总览”，不显示为 `order_overview` 或 V4 payload。
+- `next_v4_action` 面向用户显示为“下一步处理”，例如“下一步：确认房型与日期”“下一步：复核付款凭证”；不直接展示 `action_type`、`action_status`、`card_id` 等内部 code。
+- `related_source_messages[]` 面向用户显示为“关联来源邮件”，不直接展示 SourceMessage 模型名或内部 SourceMessage ID；需要正文时仍通过 SourceMessage conversation 权限链路读取。
+- `v4_order_tasks[]` 面向用户显示为“处理记录”或“来源邮件处理记录”，不显示为“V4 时间线”。`cards[]` 面向用户显示为事项状态摘要，不显示为“卡片安全摘要”。
+- 订单详情页可以显示业务状态摘要，例如预订基础信息、房型与日期、付款凭证、跟进事项、房表事项的状态；但不在该页展示可编辑表单、确认按钮或复核提交入口。
+- 技术 ID、`order_task_id`、`card_id`、`source_message_id`、`version`、`route_code`、payload 字段名和内部状态码默认不得出现在订单详情主信息层级；确需排查时只能放入折叠区或受控调试模式。
+
+安全边界：
+
+- 订单详情 `order_overview` 只展示已确认 V4 卡片派生的订单事实，不把未确认 AI 建议或 display payload 当成订单事实。
+- 订单详情不得直接返回或展示邮件正文、HTML、附件 URL、AI 原始 payload、raw evidence、PMS 原始响应、Secret、Token 或跨酒店数据。
+- 本节只约束展示和信息层级，不改变订单详情接口作为订单总览页的定位，也不改变任务卡确认、复核、审计或 SourceMessage 读取链路。
+
 ### 9.2 同一本地订单下多个订单任务
 
 如果多个 SourceMessage 或多个回调包绑定到同一本地订单：

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

@@ -69,6 +69,18 @@
 | `POST /api/reservation/invoices/manual-generations` | `FRONTEND_USER` | 已实现 M009 CP2；强制 Bearer 登录 + `RESERVATION_INVOICE_GENERATE` + 酒店访问权；`task_id` / `order_id` 可为空，传入时反查对象所属酒店 | 保持登录 + `RESERVATION_INVOICE_GENERATE` + 酒店访问权；后续如增加历史列表或预填接口需单独登记权限 | 写业务审计，记录来源类型、模板版本、生成结果摘要；生成失败写入生成记录安全错误摘要 |
 | `POST /api/reservation/rooming-lists/generations` | `FRONTEND_USER` | 已实现 M010 CP1；multipart 上传来源名单并直接下载 `.xlsx`；已在 multipart 参数绑定前前置校验登录和生成权限 | 登录 + `RESERVATION_ROOMING_LIST_GENERATE` + 酒店访问权；第一版不落库、不上传 OSS | CP1 不落生成记录表；错误响应不得记录完整名单和证件信息，后续若增加历史记录再补业务审计 |
 
+### 3.2.1 V4 工作台、订单详情和任务详情页展示层技术信息边界
+
+2026-07-21 已确认：`/reservation/tasks`、`/reservation/orders/{orderId}` 和 `/reservation/order-tasks/{orderTaskId}` 默认是普通酒店员工使用的预订事项工作台、订单总览页和订单事项办理页，不是开发 / 测试调试页。`GET /api/reservation/workbench-items`、`GET /api/reservation/order-tasks`、`GET /api/reservation/orders/{orderId}` 和 `GET /api/reservation/order-tasks/{orderTaskId}` 为了路由、筛选、并发、提交和排查可以返回 `item_type`、`order_task_status`、`card_status`、`order_id`、`order_task_id`、`card_id`、`source_message_id`、`version`、`fields[]`、`write_target`、`availability` 等稳定技术字段，但前端普通业务页面不得把这些字段作为主标题、默认筛选文案、顶部摘要、订单总览或业务事项正文直接展示。
+
+展示规则：
+
+- 默认主信息层级使用业务文案，例如“待处理预订事项”“预订事项”“订单总览”“当前确认快照”“下一步处理”“关联来源邮件”“处理记录”“处理预订事项”“预订基础信息”“房型与日期”“付款凭证”“跟进事项”“房表事项”“来源邮件”。
+- 普通筛选使用“全部”“待处理”“需要复核”“已完成”“来源通知”等业务文案；`item_type`、`order_task_status`、`card_status`、`route_code`、`system_process_category` 等技术筛选只能放在高级筛选或受控调试模式。
+- 技术 ID、JSON Pointer、payload 字段名、adapter 诊断、内部状态码和模型名只能用于内部逻辑；确需给开发 / 测试排查时，放在折叠区、高级筛选或受控调试模式。
+- 技术折叠区或调试模式仍不得展示邮件正文、HTML、附件 URL、AI 原始 payload、raw evidence、PMS 原始响应、Secret、Token、外部签名 URL 或跨酒店数据。
+- 如果后续需要单独的 Debug 视图或更完整的技术诊断页，应按 `FRONTEND_DEBUG` 分类、环境开关、专门权限和调试审计重新登记，不能把普通业务页变成调试页。
+
 ### 3.3 来源邮件接口
 
 | 接口 / 能力 | 分类 | 当前管控 | 目标管控 | 审计要求 |