# 房务最终确认后修改配房按钮被旧前端隐藏（前端待处理）

## 目标前端

- **端类型：管理后台（Web）**
- **目标仓库：`mmg/hl-ui`**
- **仓库地址：`https://git.1814.love:8443/mmg/hl-ui.git`**
- **前端本地测试环境：`http://192.168.100.160:9527`**
- **小程序：无需处理**

本通知应由管理后台前端负责人在 `mmg/hl-ui` 处理，不属于后端仓库 `wx/HL`，也不属于小程序前端。

## 现象

订单 `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 或对应写接口自动解冻，操作成功，房务状态回到配房中。
- 重新配房并逐日确认后，可再次最终确认。
- 非本人、驳回、作废及只读入口仍不显示写操作。