docs(house): clarify requirement edit after hotel finalized

changelogs-v2/2026-07/18_订单详情已配房后缺少修改需求入口-前端待处理-管理后台.md

@@ -25,6 +25,33 @@
 
 “已配房 / 配房已完成”不代表需求不可再调整。定制师在订单未进入后续不可改阶段前，应仍可从住宿安排区域发起修改需求，用于触发房务重新处理。
 
+## 2026-07-05 补充复现
+
+新增复现订单：
+
+- 订单：`HL20260703140009570`
+- 订单 ID：`2072923330129653762`
+- 页面 URL：`/order-v2/detail/2072923330129653762`
+- 页面现象：顶部流程节点展示“配房-已完成”，住宿安排卡片只有“联系房务”，没有“修改需求/调整需求”入口。
+
+后端接口复验：
+
+```http
+GET /v3/admin/order/2072923330129653762/itinerary
+```
+
+关键返回：
+
+| 字段 | 值 |
+|------|----|
+| `hotelGroup.requirement.status` | `DONE` |
+| `hotelGroup.houseStatus` | `CONFIRMED` |
+| `hotelGroup.houseStatusLabel` | `已完成` |
+| `hotelGroup.finalized` | `true` |
+| `hotelGroup.returnStatusLabel` | `已回配` |
+
+这正是“配房已完成/已回配”场景。该状态下仍允许定制师修改住宿需求，前端不能因为上述状态隐藏入口。
+
 ## 前端处理要求
 
 请在订单详情住宿安排模块补回“修改需求”入口：
@@ -52,9 +79,18 @@ PUT /v3/admin/order/{id}/hotel-requirement
 
 前端只需要恢复入口和调用现有提交流程。
 
+源码契约中该接口的说明为：
+
+```text
+提交/修改/调整房型需求（三分支自动判断：无 active=INIT_SUBMIT，PENDING=PENDING_EDIT，DONE=DONE_ADJUST）
+```
+
+如果前端已经迁移到统一订单调整接口，也可以继续复用现有的“修改需求”提交流程提交 `updates.hotelRequirement`；关键是页面入口不要因 `DONE / CONFIRMED / finalized=true / 配房已完成` 被隐藏。
+
 ## 验收标准
 
 - `HL20260703140009401` 这类已配房订单，在住宿安排卡片可看到“修改需求”入口。
+- `HL20260703140009570` 这类 `requirement.status=DONE`、页面显示“配房-已完成”的订单，也能看到“修改需求”入口。
 - 点击后可打开现有需求编辑/调整弹窗。
 - 提交修改后页面能看到新需求/修改记录，房务侧进入重新处理链路。
 - “联系房务”“查看已配房”等已有按钮不受影响。