调整订单列表待处理数量口径

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

@@ -52,7 +52,7 @@
 | `POST /api/auth/login` | 用户名密码登录 | 成功后返回 `access_token`、当前用户、可访问酒店、权限码和可见菜单；token 只放 `sessionStorage`，不要放 `localStorage`、URL、日志或错误上报。 |
 | `GET /api/auth/me` | 恢复当前登录态 | 前端启动后带 `Authorization: Bearer <access_token>` 调用；401 时清理 token 并进入登录页。 |
 | `POST /api/auth/logout` | 登出当前 session | 带 `Authorization: Bearer <access_token>`；成功后前端必须清理本地 token 和当前用户上下文。 |
-| `GET /api/reservation/orders` | 查询订单列表 | 必须带 `Authorization: Bearer <access_token>`，需要 `RESERVATION_ORDER_READ`；默认返回全部订单状态；按后端维护的订单最近业务活动时间倒序，当前落库字段为 `workflow_reservation_order.latest_activity_at`，前端不要自行重排；`open_task_count` 排除 `COMPLETED` 和 `FAILED`；已补齐 V4 继续处理入口字段，前端有 `next_v4_order_task_id` 时优先跳 V4 订单任务详情；隐藏技术订单不返回，因此 S10/S99 和旧 S000/S999 不会在订单列表形成订单。 |
+| `GET /api/reservation/orders` | 查询订单列表 | 必须带 `Authorization: Bearer <access_token>`，需要 `RESERVATION_ORDER_READ`；默认返回全部订单状态；按后端维护的订单最近业务活动时间倒序，当前落库字段为 `workflow_reservation_order.latest_activity_at`，前端不要自行重排；`open_work_item_count` 是订单列表统一待处理展示数量，前端订单列表已用它展示待处理数，第一版等于 V4 未完成订单任务数；`open_task_count` 仍保留为旧 V2/V3 诊断计数，排除 `COMPLETED` 和 `FAILED`；已补齐 V4 继续处理入口字段，前端有 `next_v4_order_task_id` 时优先跳 V4 订单任务详情；隐藏技术订单不返回，因此 S10/S99 和旧 S000/S999 不会在订单列表形成订单。 |
 | `GET /api/reservation/tasks` | 查询任务列表 / 工作台 | 必须带 Bearer token，需要 `RESERVATION_TASK_READ`；未传 `order_id` 时按来源消息接收时间倒序，传 `order_id` 时按同订单队列顺序正序；用 `can_process` 和 `readonly_reason_code` 控制入口按钮；列表不返回 AI 原始 payload、邮件正文或附件 URL；已返回来源邮件会话摘要字段，并支持 `order_status` 按任务所属订单状态筛选；旧 S000/S999 和 V3 S10/S99 以 `task_type=SOURCE_MESSAGE_ONLY` 只读任务返回，列表已透出 `result_type`、`ai_task_type`、`route_code`、`system_process_category`。V4 S10/S99 不再进入该旧任务表，应从 V4 工作台来源通知接口展示。 |
 | `GET /api/reservation/workbench-items` | 查询 V4 工作台统一列表 | 必须带 Bearer token，需要 `RESERVATION_TASK_READ`；返回 V4 业务订单任务和 S10/S99 来源通知混排摘要；支持 `hotel_id`、`item_type`、`keyword`、`page_num`、`page_size`；默认按 `source_received_at` 倒序，同一来源时间下按 `updated_at`、`created_at`、数字 `target_id` 倒序；列表不返回邮件正文、附件 URL、`ai_payload_json` 或来源通知原始 payload。 |
 | `GET /api/reservation/order-tasks` | 查询 V4 业务订单任务列表 | 必须带 Bearer token，需要 `RESERVATION_TASK_READ`；只返回 V4 业务订单任务，不包含 S10/S99 来源通知；支持 `hotel_id`、`order_id`、`order_task_status`、`card_status`、`keyword`、`page_num`、`page_size`；`order_task_status` 非 `OPEN` / `COMPLETED` 返回 400，`card_status` 非 V4 卡状态返回 400；`card_status` 只筛业务 / 可处理卡，固定来源邮件展示卡不参与筛选。 |
@@ -101,7 +101,7 @@
 
 | 接口 | 本轮变化 | 前端接入注意 |
 | --- | --- | --- |
-| `GET /api/reservation/orders` | 补齐订单列表 V4 继续处理入口字段；前端已接入。 | `order_status` 不传时默认查询全部订单状态；`page_num` 从 1 开始；`page_size` 后端有最大值保护；`open_task_count` 排除 `COMPLETED` 和 `FAILED`；旧 `next_processable_task_id` 继续保留。V4 新增 `next_v4_order_task_id`、`next_v4_action_card_id`、`next_v4_action_type`、`next_v4_action_status`、`v4_open_order_task_count`；前端“继续处理”已按优先级实现：存在 `next_v4_order_task_id` 时跳 `/reservation/order-tasks/{next_v4_order_task_id}`，否则回退旧 `/reservation/tasks/{next_processable_task_id}`；两者都没有时展示无待处理状态。 |
+| `GET /api/reservation/orders` | 补齐订单列表 V4 继续处理入口字段，并新增统一 open count 字段；前端展示已接入。 | `order_status` 不传时默认查询全部订单状态；`page_num` 从 1 开始；`page_size` 后端有最大值保护；`open_work_item_count` 是订单列表展示用统一待处理数量，开发阶段不考虑旧数据，第一版直接等于 `v4_open_order_task_count`；前端展示待处理数量时只读该字段，不自行计算旧任务数和 V4 数，也不使用旧 `open_task_count` 作为展示数量；旧 `open_task_count` 和 `next_processable_task_id` 继续保留用于 V2/V3 兼容与排查。V4 新增 `next_v4_order_task_id`、`next_v4_action_card_id`、`next_v4_action_type`、`next_v4_action_status`、`v4_open_order_task_count`；前端“继续处理”已按优先级实现：存在 `next_v4_order_task_id` 时跳 `/reservation/order-tasks/{next_v4_order_task_id}`，否则回退旧 `/reservation/tasks/{next_processable_task_id}`；两者都没有时展示无待处理状态。 |
 | `GET /api/reservation/tasks` | 补齐来源邮件会话摘要字段，并新增 `order_status` 查询参数。 | `order_status` 按任务所属订单状态过滤，支持 `TEMPORARY`、`ACTIVE`、`ENDED`、`LOGIC_DELETED`；列表仍然只返回安全摘要，不返回正文、HTML、附件 URL 或 AI 原始 payload；点击邮件入口时使用 `source_message_id` 调会话详情。 |
 | `GET /api/reservation/orders/{orderId}` | 补齐旧 `tasks[]` 来源邮件会话摘要字段，并新增 V4 `v4_order_tasks[]` 订单任务时间线。 | `include_tasks=false` 可只取订单摘要，此时 `tasks[]` 和 `v4_order_tasks[]` 都为空；旧 `tasks[]` 顺序由后端按订单队列返回，V4 `v4_order_tasks[]` 按 `source_received_at`、`source_message_id`、`order_context_index`、`created_at`、数字 ID 正序返回；前端不要自行重排。`include_source_summary` 第一版不作为前端裁剪字段的强约束，前端暂不要依赖它减少返回字段。 |
 | `GET /api/reservation/tasks/{taskId}` | 补齐顶层来源邮件字段，并扩展 `fields[]` 元数据。 | 顶层来源字段用于打开邮件会话；`fields[]` 中的 `result_type`、`task_type`、`task_subtype`、`default_value_source` 用于前端字段分组、调试和白名单对齐。 |
@@ -181,7 +181,8 @@ POST /api/auth/logout
 
 - `GET /api/reservation/orders` 默认返回全部订单状态，包括 `TEMPORARY`、`ACTIVE`、`ENDED`、`LOGIC_DELETED`。
 - `keyword` 会匹配订单业务号、临时订单号、展示名、订单状态，也会匹配来源消息安全摘要命中的 SourceMessage ID；前端可以用邮件主题、外部消息 ID 或会话 ID 辅助查订单。
-- `open_task_count` 只统计未关闭任务，排除 `COMPLETED` 和 `FAILED`。
+- `open_work_item_count` 是订单列表统一展示数量，第一版按 V4 未完成订单任务计算，即等于 `v4_open_order_task_count`；前端展示待处理数量时只使用它，不回退旧 `open_task_count`，也不要自行把旧任务数和 V4 数相加。
+- `open_task_count` 只统计旧 V2/V3 未关闭任务，排除 `COMPLETED` 和 `FAILED`，当前保留用于兼容和问题排查。
 - `next_processable_task_id` 是后端按同订单队列实时计算出的下一条可处理任务；前端可以用它做“继续处理”入口。
 - V4 订单任务入口字段由后端实时派生：`v4_open_order_task_count` 统计当前订单下 `order_task_status!=COMPLETED` 的 V4 订单任务；`next_v4_order_task_id` 是同订单第一条仍需用户处理的 V4 订单任务；`next_v4_action_card_id` 是该订单任务下第一张待处理卡；`next_v4_action_type` 取 `CONFIRM` / `REVIEW` / `NONE`；`next_v4_action_status` 取 `PENDING_CONFIRM` / `REVIEW_REQUIRED` 或空。
 - V4 派生规则：Basic Information 必须优先于业务卡；Basic 已确认后，业务卡中 `REVIEW_REQUIRED` 优先于普通 `PENDING_CONFIRM`；`COMPLETED` 的 V4 订单任务不计入 open；S10/S99 来源通知不挂订单，不进入这些订单列表字段。

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

@@ -42,7 +42,7 @@
 | `GET /api/source-messages` | 已完成安全摘要列表 | 可以 | 不能替代邮件会话全文接口。 |
 | `GET /api/source-messages/{id}` | 已完成单条安全摘要 | 可以 | 不能替代邮件会话全文接口。 |
 | `GET /api/source-messages/{id}/original` | 已完成单封原文权限读取 | 谨慎接入 | 必须带 Bearer token，需要同时拥有 `SOURCE_MESSAGE_READ` 和 `SOURCE_MESSAGE_ORIGINAL_READ`；只能读单封邮件，不能返回同一 conversation 全量邮件。 |
-| `GET /api/reservation/orders` | 已完成第一版 | 可以 | 默认查询全部订单状态；`open_task_count` 排除 `COMPLETED` 和 `FAILED`。 |
+| `GET /api/reservation/orders` | 已完成第一版 | 可以 | 默认查询全部订单状态；订单列表待处理展示使用 `open_work_item_count`；旧 `open_task_count` 仅作为 V2/V3 兼容诊断计数。 |
 | `GET /api/source-messages/{sourceMessageId}/conversation` | 已完成第一版，已补 `html_body_sanitized` 和 `html_render_mode` | 可以 | 必须带 Bearer token，需要同时拥有 `SOURCE_MESSAGE_READ` 和 `SOURCE_MESSAGE_ORIGINAL_READ`；返回完整 text/html、后端清洗后的 HTML、媒体外链和关联订单 / 任务摘要；前端不传原文读取 key，页面展示优先使用 `html_body_sanitized`。 |
 | `POST /api/system/reservation/demo-data` | 已完成 | 仅本地 / test 联调可用 | 默认关闭，必须后端配置访问口令；不能作为生产页面接口。 |
 | `POST /api/system/debug/eml-superagent-runs` | 已完成第一版 | 仅 dev/test Debug 页面可用 | 默认关闭，必须后端配置访问口令、阿里云 OSS 和 SuperAgent Open API；第一版只展示 SuperAgent 结果，不创建订单和任务；已能识别旧 S000/S999 和新结构化 S10/S99。 |
@@ -279,7 +279,7 @@ GET /api/reservation/orders/{orderId}
 GET /api/reservation/orders
 ```
 
-当前状态：后端已完成第一版。默认查询全部订单状态；`open_task_count` 排除 `COMPLETED` 和 `FAILED`，`next_processable_task_id` 按旧 V2/V3 同订单队列可处理状态实时计算。M002 V4 CP14 已补齐 V4 继续处理入口字段，前端已按 `next_v4_order_task_id` 优先进入 V4 订单任务详情，并在无 V4 入口时回退旧任务详情。
+当前状态：后端已完成第一版。默认查询全部订单状态；`open_task_count` 排除旧 V2/V3 的 `COMPLETED` 和 `FAILED`，`next_processable_task_id` 按旧 V2/V3 同订单队列可处理状态实时计算。M002 V4 CP14 已补齐 V4 继续处理入口字段；后端新增 `open_work_item_count` 作为订单列表统一待处理展示数量，第一版直接等于 V4 未完成订单任务数，不叠加旧任务。前端已按 `next_v4_order_task_id` 优先进入 V4 订单任务详情，并在无 V4 入口时回退旧任务详情；订单列表待处理数量已改为只展示 `open_work_item_count`。
 
 默认排序：按后端维护的订单最近业务活动时间倒序返回，保证最近有业务活动的订单排在前面。后端当前使用 `workflow_reservation_order.latest_activity_at` 作为排序字段，并在订单创建、任务创建、草稿保存、最终确认、人工复核解阻、任务状态变更等写路径维护；前端不要再基于任务时间或更新时间自行重排。
 
@@ -310,6 +310,7 @@ GET /api/reservation/orders
       "group_code": "GRP-001",
       "display_name": "GRP-001",
       "open_task_count": 2,
+      "open_work_item_count": 1,
       "next_processable_task_id": "10002",
       "next_v4_order_task_id": "30001",
       "next_v4_action_card_id": "31002",
@@ -331,13 +332,14 @@ V4 继续处理字段说明：
 
 | 字段 | 说明 |
 | --- | --- |
+| `open_work_item_count` | 订单列表统一待处理展示数量。第一版忽略旧数据，直接等于 `v4_open_order_task_count`；前端展示 open count 时只使用该字段，不回退旧 `open_task_count`，也不要自行相加。 |
 | `next_v4_order_task_id` | 当前订单下第一条仍需用户处理的 V4 订单任务 ID；为空表示没有 V4 待处理订单任务。 |
 | `next_v4_action_card_id` | `next_v4_order_task_id` 下第一张仍需确认或复核的卡片 ID。 |
 | `next_v4_action_type` | `CONFIRM` / `REVIEW` / `NONE`。`CONFIRM` 调卡片确认接口，`REVIEW` 调复核解阻接口。 |
 | `next_v4_action_status` | `PENDING_CONFIRM` / `REVIEW_REQUIRED`；`NONE` 时为空。 |
 | `v4_open_order_task_count` | 当前订单下未完成 V4 订单任务数，`COMPLETED` 不计入。 |
 
-前端“继续处理”入口优先级：优先使用 `next_v4_order_task_id` 跳转 V4 订单任务详情；没有 V4 待处理时再使用旧 `next_processable_task_id` 跳旧任务详情；两者都没有时展示无待处理状态。S10/S99 来源通知不创建订单，不进入订单列表字段统计。
+前端“继续处理”入口优先级：优先使用 `next_v4_order_task_id` 跳转 V4 订单任务详情；没有 V4 待处理时再使用旧 `next_processable_task_id` 跳旧任务详情；两者都没有时展示无待处理状态。S10/S99 来源通知不创建订单，不进入订单列表字段统计。订单列表展示“待处理数量”时只使用 `open_work_item_count`，不使用旧 `open_task_count` 作为展示数量，也不在前端自行计算 `open_task_count + v4_open_order_task_count`；旧 `open_task_count` 和 `v4_open_order_task_count` 保留用于兼容与排查。
 
 ## 6. 前端联调演示数据 seed 接口
 

docs/superpowers/plans/2026-07-20-order-list-open-work-count.md

@@ -0,0 +1,86 @@
+# Order List Open Work Count Implementation Plan
+
+> **For agentic workers:** REQUIRED SUB-SKILL: Use superpowers:subagent-driven-development (recommended) or superpowers:executing-plans to implement this plan task-by-task. Steps use checkbox (`- [ ]`) syntax for tracking.
+
+**Goal:** 订单列表待处理数量展示统一使用后端 `open_work_item_count`，不再使用旧 `open_task_count` 或前端自行相加。
+
+**Architecture:** 类型层在订单列表 item 上补齐 `open_work_item_count`，页面层新增展示列和格式化 helper，只读取该统一字段。继续处理入口仍复用现有 V4 优先、旧任务回退 helper，不改变 V4 任务详情、任务列表或 S10/S99 来源通知逻辑。
+
+**Tech Stack:** Vue 3, TypeScript, Vue Router, Vue I18n, Vitest, Vue Test Utils.
+
+## Global Constraints
+
+- 不改后端接口。
+- 不改 V4 订单任务详情页。
+- 不改任务列表。
+- 不改 S10/S99 来源通知逻辑。
+- 不在前端计算 `open_task_count + v4_open_order_task_count`。
+- 提交时不带入 `.idea`、`client/dist.zip`、后端代码或其他无关工作区改动。
+
+---
+
+### Task 1: Order List Uses Backend Unified Open Count
+
+**Files:**
+- Modify: `client/src/types/reservation.ts`
+- Modify: `client/src/views/reservation/ReservationOrderListView.vue`
+- Modify: `client/src/tests/reservationViews.spec.ts`
+- Modify: `client/src/tests/reservationService.spec.ts`
+- Modify: `client/src/i18n/locales/zh-CN.ts`
+- Modify: `client/src/i18n/locales/en-US.ts`
+- Modify: `client/src/i18n/locales/th-TH.ts`
+
+**Interfaces:**
+- Consumes: `ReservationOrderListItem.open_work_item_count?: number | null`
+- Produces: 订单列表“待处理”列只展示 `open_work_item_count`
+
+- [x] **Step 1: Write failing view test**
+
+Add a case where `open_task_count=99`, `v4_open_order_task_count=88`, and `open_work_item_count=3`; assert the order row shows `3` under the open count column and does not show `99` or `88`.
+
+- [x] **Step 2: Verify red**
+
+Run `CI=true pnpm --dir client test -- reservationViews.spec.ts`.
+Expected: FAIL because the current order list has no `open_work_item_count` display.
+
+- [x] **Step 3: Implement types and UI**
+
+Add `open_work_item_count` to `ReservationOrderListItem`. Add a “待处理 / Open work” column and render only `formatOpenWorkItemCount(order)`.
+
+- [x] **Step 4: Update service test**
+
+Add `open_work_item_count` to the order list service mock and assert the value is preserved.
+
+- [x] **Step 5: Verify green**
+
+Run `CI=true pnpm --dir client test -- reservationViews.spec.ts reservationService.spec.ts`.
+
+### Task 2: Documentation, Review, Verification, Commit
+
+**Files:**
+- Modify: `PROJECT_STATE.md`
+- Modify: `docs/project/frontend-backend/backend-to-frontend-notes.md`
+- Modify: `docs/project/frontend-backend/frontend-to-backend-api-requests.md`
+
+**Interfaces:**
+- Produces: 前端已改用 `open_work_item_count` 的状态说明
+
+- [x] **Step 1: Update docs**
+
+Record that frontend order list display now uses `open_work_item_count` and no longer uses `open_task_count` as the displayed count.
+
+- [x] **Step 2: Run verification**
+
+Run:
+- `CI=true pnpm --dir client lint`
+- `CI=true pnpm --dir client typecheck`
+- `CI=true pnpm --dir client test`
+- `CI=true pnpm --dir client build`
+
+- [x] **Step 3: Code review**
+
+Review routing invariants, open count source, tests, docs, and staged files.
+
+- [x] **Step 4: Commit**
+
+Stage only related frontend/doc files and commit with a Chinese message.