docs(house): 补齐4907三页面前端验收要求

changelogs-v2/2026-07/56_4907_订单调整保留配房与房务驳回定制师待办-管理后台.md

@@ -62,6 +62,23 @@ GET /v3/admin/order/todos?scope=mine&status=OPEN&page=1&pageSize=20
 - `HOTEL_REPLY_TIMEOUT`、`UNREAD_CHAT` 可与返工标签并存，不能因为互斥普通新抢标签而一并隐藏。
 - 当前未完成阻塞项仍是 §1 的目标晚次选择和“调整”入口；该页面未验收前 Issue #4907 保持 OPEN。
 
+### 0.4 首页、待办列表、订单详情必须保持一致
+
+前端需要同时验收以下三处，不能只修其中一个页面：
+
+1. 房务首页：直接按 `GET /admin/profile/dashboard` 返回的 `todoCards[].todoType` / `todoLabel` 渲染。
+2. 房务待办列表：直接按 `GET /v3/admin/order/todos` 返回的 `list[].todoTypes[]` 渲染完整标签，顶层 `todoType/title` 只作为主标签兼容字段。
+3. 房务订单详情：业务动作成功后重新加载房务详情，并同步刷新首页和待办列表；不得沿用进入详情前的旧标签或旧计数。
+
+同一订单在三处页面必须遵守同一口径：
+
+- 存在 OPEN `REQUIREMENT_ADJUSTED` 时，主标签只能是“需求变更重配”，不得再显示“刚抢单待配房”。
+- 最终确认、房务驳回或订单取消成功后，前端必须重新请求接口；对应返工待办已关闭时，三处均不得继续显示旧标签。
+- `HOTEL_REPLY_TIMEOUT`、`UNREAD_CHAT` 等独立提醒可以与返工主标签共存，但不得自行拼接同需求的 `PENDING_ARRANGE`。
+- 调整配房只能提交目标 `dayNumber`，不得自行提交或计算 `stayDate`；入住日期由后端根据当前行程晚次推导。
+
+Issue #4907 的前端关闭证据必须包含同一订单在“房务首页、待办列表、订单详情”三处的刷新后截图，并能证明标签、数量和当前业务状态一致。缺少任一页面截图，或详情仍无“调整”入口，Issue 保持 OPEN。
+
 ## 1. 订单调整后的房务口径
 
 定制师通过以下接口修改行程天数、出发日期或出行人数：
@@ -223,6 +240,8 @@ Content-Type: application/json
 10. 历史需求和旧配房均继续展示，不得只渲染当前需求而丢失历史证据。
 11. 需求变更返工订单只展示 `需求变更重配` 主标签，不得再从 `CLAIMING` 自行补出 `刚抢单待配房`；询房超时、未读消息等独立标签照常展示。
 12. 每条已有配房均提供“调整”入口，可选择当前有效晚次并同时修改酒店、房型、房间数和库存口径；改期后从 6 月 1 日调整到当前第 1 晚 6 月 5 日时提交 `dayNumber=1`。
+13. 同一返工订单在房务首页、待办列表、订单详情三处的主标签、数量和当前状态一致；动作成功后均使用重新请求的数据，不使用本地旧缓存补标签。
+14. 前端提交单条配房调整时只提交 `dayNumber`，不得提交 `stayDate`；关闭 #4907 前提供三处页面刷新后的同订单截图。
 
 ## 5. 后端验证证据