diff --git a/changelogs-v2/2026-07/18_订单详情已配房后缺少修改需求入口-前端待处理-管理后台.md b/changelogs-v2/2026-07/18_订单详情已配房后缺少修改需求入口-前端待处理-管理后台.md
index ca776ba..a510062 100644
--- a/changelogs-v2/2026-07/18_订单详情已配房后缺少修改需求入口-前端待处理-管理后台.md
+++ b/changelogs-v2/2026-07/18_订单详情已配房后缺少修改需求入口-前端待处理-管理后台.md
@@ -59,6 +59,59 @@ GET /v3/admin/order/2072923330129653762/itinerary
 
 补充口径：不只是完成态可以改，配房中也可以改。后端会按最新 active 需求状态自动判断是草稿编辑还是完成后调整。
 
+## 2026-07-06 定位补充：不是数据问题，是前端锁定门控误挡按钮
+
+复查订单 `HL20260703140009570` / `2072923330129653762`：
+
+```http
+GET /v3/admin/order/2072923330129653762/itinerary
+```
+
+关键返回确认：
+
+| 字段 | 值 |
+|------|----|
+| `hotelGroup.requirement.requirementId` | `2072923330259677186` |
+| `hotelGroup.requirement.status` | `DONE` |
+| `hotelGroup.houseStatus` | `CONFIRMED` |
+| `hotelGroup.finalized` | `true` |
+| `hotelGroup.returnStatusLabel` | `已回配` |
+| `hotelGroup.assignments.length` | `2` |
+
+结论：接口数据中住宿需求没有丢，已配房记录也存在，所以不是后端数据问题。
+
+本地前端 `v2.1` 代码辅助定位到隐藏原因：
+
+```js
+// src/views/order-v2/detail/_shared/v3Adapter.js
+lockedAt: m.confirmedAt
+
+// src/views/order-v2/detail/components/RoomArrangeCard.vue
+const isLocked = computed(() => !!props.order.lockedAt)
+
+const action = computed(() => {
+  if (isLocked.value) return null
+  // ...
+})
+```
+
+同一订单主详情返回：
+
+| 字段 | 值 |
+|------|----|
+| `main.confirmedAt` | `2026-07-03 14:00:09` |
+| `main.flowStatus` | `RESOURCE_PREPARING` |
+| `main.orderStatus` | `CUSTOMIZING` |
+
+因此前端把“订单已确认时间 `confirmedAt`”映射成 `lockedAt` 后，住宿安排卡片 `action` 直接返回 `null`，即使 `roomRequest` 已存在也不会显示“修改需求”。
+
+前端处理建议：
+
+1. 住宿安排卡片不要用 `confirmedAt -> lockedAt` 隐藏“提交/修改需求”入口。
+2. 只要 `order.roomRequest` 存在，应显示“修改需求”；已配房、已回配、待最终确认都一样。
+3. 如确实存在整单不可编辑状态，请使用明确的终态/作废/结算完成字段单独判断，不要把 `confirmedAt` 当成住宿需求不可编辑标志。
+4. 最小修复点可以是移除或替换 `RoomArrangeCard.vue` 中 `action` 的 `if (isLocked.value) return null` 门控。
+
 ## 前端处理要求
 
 请在订单详情住宿安排模块把“修改需求”作为常驻入口：