diff --git a/changelogs-v2/2026-07/18_房务已完成配房后再次配房被缺少需求ID拦截-前端待处理-管理后台.md b/changelogs-v2/2026-07/18_房务已完成配房后再次配房被缺少需求ID拦截-前端待处理-管理后台.md
new file mode 100644
index 0000000..6c217b5
--- /dev/null
+++ b/changelogs-v2/2026-07/18_房务已完成配房后再次配房被缺少需求ID拦截-前端待处理-管理后台.md
@@ -0,0 +1,67 @@
+# 房务已完成配房后再次配房被“缺少需求ID”拦截（前端待处理）
+
+- 日期：2026-07-03
+- 端：管理后台
+- 页面：房务管家 / 待处理详情弹窗
+- 示例订单：`HL20260703140009401`
+- 订单 ID：`2072923329412427777`
+- 当前状态：房务已完成配房，详情展示“已完成 / 配房进度 2/2”
+- 当前结论：已完成配房的订单也允许再次修改需求/重新配房，前端当前拦截不正确。
+
+## 现象
+
+在 `/housekeeper/todos` 打开订单详情弹窗后，订单已经完成配房，住宿行仍显示「配房」按钮。
+
+点击「配房」时，前端弹出提示：
+
+```text
+缺少需求 ID，暂无法配房
+```
+
+但业务口径是：**已经完成配房的订单也可以改**，配置完成后仍可以提出修改需求/重新配房。
+
+## 前端问题
+
+当前前端疑似在已完成配房场景下：
+
+1. 没有从详情数据中正确取到当前住宿需求 `requirementId`；或
+2. 因为订单/房务状态是“已完成 / 已回配 / CONFIRMED”，前端把需求 ID 当成不可用；或
+3. 点击「配房」时只读取待配房状态下的字段，没有兼容已完成配房状态下的 active requirement。
+
+这个拦截不对。
+
+## 业务口径
+
+- 已完成配房不等于需求不可改。
+- 定制师/房务在已完成配房后仍可以再次提出修改需求。
+- 房务侧已完成配房后，也应允许基于当前订单/当前需求进入再次配房或修改需求链路。
+- 不应因为 `houseStatus=CONFIRMED`、页面展示“已完成”、住宿行展示“已确认/已配房”就阻断操作。
+
+## 前端处理要求
+
+请调整房务详情弹窗里的「配房」/修改需求相关入口逻辑：
+
+1. 已完成配房订单点击「配房」时，不要弹出“缺少需求 ID，暂无法配房”。
+2. 应从订单详情/房务详情返回数据中取当前 active 住宿需求 ID。
+3. 如果当前展示的是已回配/已确认的住宿行，也应保留当前需求上下文，用于再次配房或发起修改需求。
+4. 若确实没有 requirementId，应先复查接口字段映射，不要直接在前端拦截掉已完成配房场景。
+5. 操作入口应兼容以下状态：
+   - 待配房
+   - 配房中
+   - 待最终确认
+   - 已完成/已确认/已回配
+
+## 后端接口说明
+
+本次无后端接口变更。
+
+后端已有房务需求/配房数据，当前示例订单能展示配房行、配房进度、已确认酒店，说明订单与房务需求上下文存在。
+
+前端需要修正字段取值和状态判断。
+
+## 验收标准
+
+- `HL20260703140009401` 这种已完成配房订单，点击住宿行「配房」不再提示“缺少需求 ID”。
+- 已完成配房订单可以进入再次配房/修改需求操作流程。
+- 状态为“已完成 / 配房进度 2/2”的订单仍可基于当前需求继续操作。
+- 待配房、配房中、待最终确认等原有状态操作不受影响。