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

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. 任务列表 / 工作台接口字段补齐
 
 建议路径：