diff --git a/changelogs-v2/2026-07/29_4777_房务清空配房信息与驳回按钮动作契约-前端待处理-管理后台.md b/changelogs-v2/2026-07/29_4777_房务清空配房信息与驳回按钮动作契约-前端待处理-管理后台.md
index 1870f5a..5ab2099 100644
--- a/changelogs-v2/2026-07/29_4777_房务清空配房信息与驳回按钮动作契约-前端待处理-管理后台.md
+++ b/changelogs-v2/2026-07/29_4777_房务清空配房信息与驳回按钮动作契约-前端待处理-管理后台.md
@@ -131,3 +131,65 @@ DELETE /v3/admin/order/hotel-requirements/{requirementId}/assignments/days/{dayN
 - 两晚订单第 1 晚、第 2 晚都有独立“清空”按钮。
 - 清空第 1 晚后，第 1 晚回到待配房，第 2 晚配房仍保留。
 - 清空不扣系统库存的配房时，不应释放资源库存。
+
+## 2026-07-07 补充：有任意配房/询房数据时禁止驳回
+
+本次补充针对前端底部“驳回需求”按钮误展示问题。后端口径不变，但前端需要严格按详情动作字段渲染，不能只看 `houseStatus` / 流程节点 / 是否处于“配房中”。
+
+### 后端已验证行为
+
+测试订单 `2074303545149980674` 当前第 1 晚已有配房/询房数据：
+
+```json
+{
+  "actions": {
+    "canRejectRequirement": {
+      "enabled": false,
+      "code": "REJECT_REQUIREMENT",
+      "label": "驳回需求",
+      "disabledReason": "已有配房, 不能驳回, 请先清空/删除配房"
+    },
+    "canClearAssignments": {
+      "enabled": true,
+      "code": "CLEAR_ASSIGNMENTS",
+      "label": "清空配房"
+    }
+  },
+  "requirement": {
+    "actions": {
+      "canRejectRequirement": false,
+      "canClearAssignments": true
+    }
+  }
+}
+```
+
+即使前端绕过按钮直接调用：
+
+```http
+POST /v3/admin/order/2074303545149980674/hotel-requirement/supplier-reject
+```
+
+后端也返回：
+
+```json
+{
+  "code": 582086,
+  "success": false,
+  "message": "该需求已有配房记录, 不能驳回, 请走替换/修改配房"
+}
+```
+
+### 前端必须调整
+
+1. 底部“驳回需求”按钮以 `data.actions.canRejectRequirement.enabled` 为唯一可点击依据。
+2. `enabled=false` 时必须隐藏或禁用按钮，并展示/保留 `disabledReason`，不能因为当前是 `CLAIMING` / “配房中”就展示可点击按钮。
+3. 判断“有数据”包括所有 active 配房行：已配房、已确认、询房中、替换中，只要详情里该需求还存在配房/询房行，就不能驳回。
+4. 每个 day 行清空后必须重新拉取订单详情；只有全部 day 清空到没有 active 配房行，后端返回 `enabled=true` 时，才允许驳回。
+5. 如果同时存在底部整体清空和 day 行清空，驳回按钮仍然只看刷新后的后端 action，不在前端自行推算。
+
+### 补充验收
+
+- 第 1 晚有“询房中”或已选酒店数据、第 2 晚待配房：底部“驳回需求”不可点击。
+- 清空第 1 晚后刷新详情，如果所有 day 都无配房/询房数据，底部“驳回需求”才可点击。
+- 前端强制调用驳回接口时，收到 `582086` 必须提示错误并刷新详情，不能把订单展示为已驳回。