diff --git a/changelogs-v2/2026-06/30_4489_去房务抢单上限+改期改天数补需求变更重配待办-管理后台.md b/changelogs-v2/2026-06/30_4489_去房务抢单上限+改期改天数补需求变更重配待办-管理后台.md
new file mode 100644
index 0000000..83dc9be
--- /dev/null
+++ b/changelogs-v2/2026-06/30_4489_去房务抢单上限+改期改天数补需求变更重配待办-管理后台.md
@@ -0,0 +1,48 @@
+# 去房务抢单上限(30单) + 改期/改天数后补「需求变更重配」待办
+
+> 变更类型：🔧 行为变更（房务管家·抢单/待办）
+> 端类型：管理后台（房务管家）
+> 日期：2026-06-27 ｜ 工单：#4489 ｜ PR：#4490 ｜ 服务：hl-order-service-v3（双实例已部署测试服，API 实测通过）
+
+---
+
+## 一、去除房务抢单上限（不再限单数）
+
+房务抢单/转单**不再有「同时在跟 30 单」上限**。
+- 抢单 `POST /v3/admin/order/hotel-requirements/{requirementId}/claim`：**不再返 `808003`「你已达到同时在跟订单上限（30 单）」**。
+- 转单接收人：**不再返 `808015`「接收人已达上限」**。
+- 错误码 `808003` / `808015` **已删**，前端可去掉相关上限提示/拦截逻辑。
+- 转单候选选人页：所有房务**恒可选**（不再因「在跟 ≥30 单」灰掉）；卡片仍展示「在跟订单数 activeCount」供参考。
+
+前端需：移除抢单/转单的「30 单上限」错误提示与前置拦截。
+
+---
+
+## 二、改期/改天数/改酒店后，待办列表新增「需求变更重配」（修复待办⑤永空）
+
+此前**定制师在调整订单改出发日期/行程天数/行程/酒店需求后，房务侧不产任何提醒**（待办类型 `REQUIREMENT_ADJUSTED` 一直为空）。现已修复：
+
+`GET /v3/admin/order/todos` 的 `list[]` 现会出现 **`todoType=REQUIREMENT_ADJUSTED`「需求变更重配」** 待办：
+- 触发：定制师调整订单命中 **出发日期 / 行程天数 / 行程 / 酒店需求** 任一维度后，AFTER_COMMIT 自动产生。
+- 归属：**上个房务**（被作废旧版的 claimer，`ownerUserId`=上个房务）；解析不到时广播（任一房务可见）。
+- 内容：`title`「客户调整需求 · 原配房失效, 请重新配房」，`urgency=DANGER`，`fromValue`=上个房务名。
+- 幂等：同一新需求版本只产 1 条（`dedupKey=REQADJ-{requirementId}`）。
+- `stats.REQUIREMENT_ADJUSTED` 计数同步生效。
+- 抢单池：该订单重版回池后标 **返工单 `isRework=true`** + 显示「上个房务:X」（依赖此待办存在）。
+
+前端需：待办列表渲染 `REQUIREMENT_ADJUSTED`（持久化、可处理类，与 REFUND 同款交互）；抢单池卡片读 `isRework`/上个房务名区分新单/返工单。
+
+---
+
+## 三、测试服实测
+
+- 房务在跟 37 单时仍可抢单（去上限生效，原 808003 不再）。
+- 改期 06-28→06-30 后：`REQUIREMENT_ADJUSTED` 待办正确产出，`ownerUserId`=上个房务、`dedupKey=REQADJ-{新版需求ID}`。
+
+> 后端已完成并实测，前端按本单接入。
+
+---
+
+> ⚠️ 关联（订单侧/聊天侧另开工单交后端，前端先知会）：
+> - **改行程天数(减天)** 目前订单侧不级联重置酒店配房 → 超范围晚库存暂未释放（#4491，订单侧修复中）。
+> - **④定制师未读消息** 待办在「房务先抢单、定制师后联系房务」顺序下暂不触发（#4492，聊天会话子系统修复中）。