diff --git a/changelogs-v2/2026-07/69_房务最终确认后修改配房按钮被旧前端隐藏-前端待处理.md b/changelogs-v2/2026-07/69_房务最终确认后修改配房按钮被旧前端隐藏-前端待处理.md
new file mode 100644
index 0000000..931478e
--- /dev/null
+++ b/changelogs-v2/2026-07/69_房务最终确认后修改配房按钮被旧前端隐藏-前端待处理.md
@@ -0,0 +1,56 @@
+# 房务最终确认后修改配房按钮被旧前端隐藏（前端待处理）
+
+## 现象
+
+订单 `HL20260719151313174` 已最终确认、配房进度 `2/2`，房务详情配房行程只显示“询房”按钮；既有配房行未显示“替换”“改协议价”“移除”等修改入口。
+
+业务要求：最终确认后房务仍可修改配房。发起修改时先将住宿需求从完成态解冻回配房中，再执行替换、移除、改价等操作。
+
+## 已确认原因
+
+`192.168.100.160:9527` 当前 Vite 服务实际返回的 `OrderDetailModal.vue` 仍包含旧门槛：
+
+```js
+const canMutateRequirement = computed(
+  () =>
+    canEditHouseOrder.value &&
+    !requirementReadOnly.value &&
+    (merged.value?.finalized !== true || merged.value?.reopenAction?.enabled === true)
+)
+```
+
+后端详情当前有意将 `reopenAction` 设为 disabled，不再把“回配”作为单独按钮；后端各直接编辑入口会调用 `reopenIfFinalizedForDirectEdit()` 自动解冻。因此旧前端条件在 `finalized=true` 时恒为 false，连真正的修改按钮也全部隐藏。
+
+当前 `D:/work2/hl-ui` 源码已经改为：
+
+```js
+const canMutateRequirement = computed(
+  () => canEditHouseOrder.value && !requirementReadOnly.value
+)
+```
+
+并由 `ensureRequirementEditable(reqId)` 在写操作前调用 `reopenRequirement(reqId)`，与后端自动解冻语义一致。
+
+## 前端处理要求
+
+1. 同步当前 `D:/work2/hl-ui` 正确实现到 `192.168.100.160:9527` 实际运行工作树，重启 Vite 服务。
+2. `canMutateRequirement` 不得用 `finalized` 或 `reopenAction.enabled` 隐藏配房修改入口。
+3. 最终确认后，只要订单属于当前房务、需求仍生效且未驳回/作废，应继续显示：
+   - 当晚“替换”；
+   - 已确认配房行“改协议价”；
+   - 已确认配房行“移除”。
+4. 写操作前沿用 `ensureRequirementEditable()`；不得要求用户先点击一个独立“回配”按钮。
+5. 驳回需求、作废需求、非本人订单、组长只读入口仍保持只读，不得放宽权限边界。
+
+## 后端依据
+
+- `HouseAssignmentService.reopenIfFinalizedForDirectEdit()`：最终确认后的直接编辑自动解冻。
+- 替换、移除、改协议价等多个写入口均已调用该方法。
+- `HouseDetailAggregator` 不暴露独立 reopen action 属预期行为，不需要后端恢复该按钮。
+
+## 验收
+
+- 打开订单 `HL20260719151313174`，完成态仍可看到“替换”“改协议价”“移除”。
+- 点击修改后 Network 先出现 reopen 或对应写接口自动解冻，操作成功，房务状态回到配房中。
+- 重新配房并逐日确认后，可再次最终确认。
+- 非本人、驳回、作废及只读入口仍不显示写操作。