diff --git a/changelogs-v2/2026-07/18_订单详情已配房后缺少修改需求入口-前端待处理-管理后台.md b/changelogs-v2/2026-07/18_订单详情已配房后缺少修改需求入口-前端待处理-管理后台.md
index 2a5538f..ca776ba 100644
--- a/changelogs-v2/2026-07/18_订单详情已配房后缺少修改需求入口-前端待处理-管理后台.md
+++ b/changelogs-v2/2026-07/18_订单详情已配房后缺少修改需求入口-前端待处理-管理后台.md
@@ -1,4 +1,4 @@
-# 订单详情已配房后缺少“修改需求”入口（前端待处理）
+# 订单详情住宿需求任何房务阶段都应保留“修改需求”入口（前端待处理）
 
 - 日期：2026-07-03
 - 端：管理后台
@@ -6,24 +6,29 @@
 - 示例订单：`HL20260703140009401`
 - 订单 ID：`2072923329412427777`
 - 当前状态：住宿已回配，流程节点展示“配房已完成”
-- 当前结论：后端已支持已配置/已回配后继续提出修改需求，前端需要保留或补回入口。
+- 当前结论：后端已支持住宿需求在任意房务阶段继续提出修改，前端需要保留或补回入口。
 
 ## 现象
 
-在订单详情页的「行程安排」页签中，住宿安排已显示为“已回配/配房已完成”，但页面上没有“修改需求”按钮。
+在订单详情页的「行程安排」页签中，住宿安排进入房务处理后，页面不应隐藏“修改需求”按钮。
+
+已观察到的问题包括：
+
+- 配房中/询房中：前端容易只展示“联系房务”，隐藏“修改需求”。
+- 已配房/已回配/配房已完成：前端容易认为流程完成后不可再改，隐藏“修改需求”。
 
 截图复现口径：
 
 - 订单：`HL20260703140009401`
 - 页面 URL：`/order-v2/detail/2072923329412427777`
 - 当前卡片只看到「联系房务」和「查看已配房」等入口。
-- 业务期望：即使房务已经配置/回配完成，定制师仍然可以再次发起“修改需求”。
+- 业务期望：只要订单有住宿需求，定制师在配房中、询房中、待最终确认、已配房、已回配等房务阶段都可以再次发起“修改需求”。
 
 ## 业务口径
 
-配置完成后也可以提出修改需求。
+住宿需求任何房务阶段都可以提出修改需求。
 
-“已配房 / 配房已完成”不代表需求不可再调整。定制师在订单未进入后续不可改阶段前，应仍可从住宿安排区域发起修改需求，用于触发房务重新处理。
+“配房中 / 询房中 / 待最终确认 / 已配房 / 配房已完成 / 已回配”都不代表需求不可再调整。前端不要用房务状态判断是否隐藏入口；修改需求入口应作为住宿安排的常驻动作，由提交接口和后端状态机处理后续分支。
 
 ## 2026-07-05 补充复现
 
@@ -52,14 +57,16 @@ GET /v3/admin/order/2072923330129653762/itinerary
 
 这正是“配房已完成/已回配”场景。该状态下仍允许定制师修改住宿需求，前端不能因为上述状态隐藏入口。
 
+补充口径：不只是完成态可以改，配房中也可以改。后端会按最新 active 需求状态自动判断是草稿编辑还是完成后调整。
+
 ## 前端处理要求
 
-请在订单详情住宿安排模块补回“修改需求”入口：
+请在订单详情住宿安排模块把“修改需求”作为常驻入口：
 
-1. 当订单存在住宿需求，且住宿卡片处于已配房/已回配/配房完成展示态时，仍显示“修改需求”按钮。
+1. 当订单存在住宿需求时，住宿卡片应显示“修改需求”按钮。
 2. 点击“修改需求”后复用现有需求编辑/调整弹窗或跳转逻辑。
 3. 提交后走现有后端需求提交/调整接口，不需要新增后端接口。
-4. 不要因为 `roomControlStatus=DONE`、`houseStatus=CONFIRMED`、页面展示“配房已完成”就隐藏修改需求入口。
+4. 不要因为 `roomControlStatus=PROCESSING/DONE`、`requirement.status=PROCESSING/DONE`、`houseStatus=CLAIMING/PENDING_FINALIZE/CONFIRMED`、页面展示“配房中/询房中/配房已完成/已回配”就隐藏修改需求入口。
 
 ## 后端接口说明
 
@@ -75,7 +82,7 @@ PUT /v3/admin/order/{id}/hotel-requirement
 
 - 无 active 需求：首次提交。
 - active 需求待处理：编辑当前需求。
-- 已完成/已回配需求：提交修改需求，生成新版本或触发房务重新处理。
+- 配房中/已抢单/已发询房/已配房/已回配需求：提交修改需求，生成新版本或触发房务重新处理。
 
 前端只需要恢复入口和调用现有提交流程。
 
@@ -85,12 +92,21 @@ PUT /v3/admin/order/{id}/hotel-requirement
 提交/修改/调整房型需求（三分支自动判断：无 active=INIT_SUBMIT，PENDING=PENDING_EDIT，DONE=DONE_ADJUST）
 ```
 
-如果前端已经迁移到统一订单调整接口，也可以继续复用现有的“修改需求”提交流程提交 `updates.hotelRequirement`；关键是页面入口不要因 `DONE / CONFIRMED / finalized=true / 配房已完成` 被隐藏。
+源码实际分支：
+
+| 当前 active 需求状态 | 后端分支 | 前端理解 |
+|----------------------|----------|----------|
+| 无 active | `INIT_SUBMIT` | 首次提交住宿需求 |
+| `PENDING / PENDING_REVIEW` | `PENDING_EDIT` | 待处理需求编辑 |
+| `DONE / PROCESSING / REJECTED_*` | `DONE_ADJUST` | 配房中或完成后调整 |
+
+如果前端已经迁移到统一订单调整接口，也可以继续复用现有的“修改需求”提交流程提交 `updates.hotelRequirement`；关键是页面入口不要因任何房务子流程状态被隐藏。
 
 ## 验收标准
 
 - `HL20260703140009401` 这类已配房订单，在住宿安排卡片可看到“修改需求”入口。
 - `HL20260703140009570` 这类 `requirement.status=DONE`、页面显示“配房-已完成”的订单，也能看到“修改需求”入口。
+- `requirement.status=PROCESSING` 或页面显示“配房中/询房中”的订单，也能看到“修改需求”入口。
 - 点击后可打开现有需求编辑/调整弹窗。
 - 提交修改后页面能看到新需求/修改记录，房务侧进入重新处理链路。
 - “联系房务”“查看已配房”等已有按钮不受影响。