diff --git a/changelogs-v2/2026-07/18_房务已最终确认后仍允许直接修改配房-前端待处理-管理后台.md b/changelogs-v2/2026-07/18_房务已最终确认后仍允许直接修改配房-前端待处理-管理后台.md
new file mode 100644
index 0000000..06be3e8
--- /dev/null
+++ b/changelogs-v2/2026-07/18_房务已最终确认后仍允许直接修改配房-前端待处理-管理后台.md
@@ -0,0 +1,69 @@
+# 房务已最终确认后仍应允许房务直接修改配房（前端待处理）
+
+- 日期：2026-07-03
+- 端：管理后台
+- 页面：房务管家 / 房务订单详情弹窗
+- 示例订单：`HL20260703140009401`
+- 订单 ID：`2072923329412427777`
+- 当前状态：房务已最终确认，详情展示“已完成 / 配房进度 2/2”
+- 当前结论：前端拦截口径错误。房务可以直接修改，不需要定制师重新提出修改；完成后的任何状态都可以修改。
+
+## 现象
+
+在房务详情弹窗里，订单已经完成配房并最终确认。
+
+房务点击住宿行「配房」时，前端弹出：
+
+```text
+配房已最终确认，不可直接修改；如需变更请由定制师重新调整需求
+```
+
+这个提示和拦截不符合业务口径。
+
+## 正确业务口径
+
+房务侧可以直接修改配房结果。
+
+- 不需要定制师重新提出修改需求。
+- 已最终确认也可以改。
+- 已完成配房也可以改。
+- 任意房务状态下，只要房务有操作入口，都应允许进入修改/重新配房流程。
+
+也就是说，前端不能因为以下状态阻断房务修改：
+
+- `houseStatus=CONFIRMED`
+- 页面展示“已完成”
+- 页面展示“已最终确认”
+- 住宿行展示“已确认 / 已配房 / 已完成”
+- 配房进度 `2/2`
+
+## 前端处理要求
+
+请移除房务侧这个拦截：
+
+```text
+配房已最终确认，不可直接修改；如需变更请由定制师重新调整需求
+```
+
+调整为：
+
+1. 房务在已最终确认/已完成/已回配状态下点击「配房」，仍进入配房编辑或重新配房流程。
+2. 不要求定制师先提出修改需求。
+3. 不因为已完成状态隐藏或禁用房务修改入口。
+4. 若需要当前住宿行 ID、assignmentId、requirementId，请从当前房务详情数据中取，不要用“已最终确认”作为前端阻断条件。
+5. “修改需求”是定制师侧调整需求的入口；房务侧修改配房是另一条操作链路，不能混为一谈。
+
+## 后端接口说明
+
+本次无后端接口变更。
+
+后端当前已有配房行数据，页面能展示酒店、房型、价格、确认状态，说明房务 assignment 上下文存在。
+
+前端需要放开状态判断，继续调用现有房务配房/修改配房接口链路。
+
+## 验收标准
+
+- `HL20260703140009401` 已最终确认后，房务点击住宿行「配房」不再出现“不可直接修改，请由定制师重新调整需求”的提示。
+- 已完成配房订单可以由房务直接进入修改/重新配房流程。
+- 不需要定制师先发起修改需求。
+- 待配房、配房中、待最终确认、已完成等任意房务状态下，房务修改入口逻辑一致可用。