docs(changelog): 房务E2E揪出3 bug修复对接(#4491改天数级联/#4492反序聊天/#4529切角色token)

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

changelogs-v2/2026-06/36_4491_改行程天数减天级联重置酒店配房还原库存_前端对接-管理后台.md

@@ -0,0 +1,31 @@
+# 改行程天数(减天)级联重置酒店配房 + 还原库存（前端对接）
+
+> 模块：订单调整（adjustment）/ 房务配房（管理后台）
+> 类型：后端 bug 修复（PR #4491 已合 dev-v3 + 测试服实测生效）+ **前端需配合一项**
+> 日期：2026-06-28
+
+## 背景 / 修了什么
+
+定制师调整订单**减少行程天数**后，原先房务侧「超出新天数范围那几晚」的已配房 + 已扣 resource 库存**完全不被清理、永久泄漏**（2 天行程却挂着 3 晚酒店配房、第 3 晚库存永久占用）。
+
+现已修复（与「改出发日期」同款级联）：减行程天数提交后，后端自动
+- **软删超出新范围的酒店配房行** + **还原对应 resource 库存**；
+- 把该订单的酒店需求**重版回抢单池**（回到「待配房」），房务重新认领/配房；
+- 订单 room_control 回 PENDING、生成「需求变更(REQUIREMENT_ADJUSTED)」待办。
+
+测试服实测：4 天 3 晚→配 3 晚确认(扣库存)→减到 2 天 → 第 3 晚 3 行配房全软删、`stock_used` 还原、需求回「待配房」。
+
+## 前端需配合（1 项）
+
+**减行程天数时，请同时下发裁剪后的酒店需求 `hotelRequirement.days`（只保留新天数范围内的晚）。**
+
+- 后端库存泄漏已彻底修复（超范围配房软删 + 库存还原，与前端是否下发裁剪无关）。
+- 但若前端减天数时**只改 itinerary、不同步下发裁剪后的 `hotelRequirement.days`**，则重版后的新「待配房」需求的 days 模板仍含「那一晚」的天条目（不影响库存、不影响 active 配房=0，仅房务重新配房时会多看到一晚空档）。前端同步裁剪即完全对齐。
+
+另：请确认前端「改行程天数」入口对 CORE（短途/定制）产品是否开放；本修复对任何减天数路径都生效。
+
+## 影响接口
+- `POST /v3/admin/order/{orderId}/adjustment/submit`（itinerary 减天数分支，行为增强，入参结构不变）
+- 房务侧详情/日历/待办随之反映（需求回待配房、库存释放、REQUIREMENT_ADJUSTED 待办）
+
+后端无需前端改即不再泄漏库存；前端配合下发裁剪 days 可让重配体验完全一致。

changelogs-v2/2026-06/37_4492_房务先抢单后定制师开聊天会话不通已修_知悉-管理后台.md

@@ -0,0 +1,24 @@
+# 房务先抢单、定制师后开聊天「会话不通」已修（前端知悉，无需改动）
+
+> 模块：站内信聊天（房务订单会话）/ 管理后台
+> 类型：后端 bug 修复（PR #4492 已合 dev-v3 + 测试服实测生效）—— **前端无需改动，透明修复**
+> 日期：2026-06-28
+
+## 背景 / 修了什么
+
+房务订单会话此前有个**反序断链**（最常见的生产顺序中招）：
+
+- 序A（原本 OK）：定制师**先**开聊天（抢单前）→ 房务**后**抢单 → 抢单时补齐会话 → 聊天正常。
+- 序B（原本断、最常见）：房务**先**抢单 → 定制师**后**点「联系房务」开聊天 → 因为定制师不知道房务是谁、不传对端，后端只挂了个占位对端（peer=0）→ **定制师发的消息房务永远收不到、房务读消息被拒（281002）、④未读消息待办永不触发**。
+
+现已修复：定制师开房务会话时，**后端自动按订单反查当前接单房务**作为真实对端，建出双方真实会话成员行。无论「定制师先开」还是「房务先抢」，聊天都正常连通。
+
+测试服实测（序B）：房务先抢单 → 定制师 open-house（不传对端）→ 后端解析到房务 → 双方成员行建出 → 定制师发消息 → 房务 `unread_count=1` → 房务读消息 200（不再 281002）→ ④未读消息待办触发。
+
+## 前端
+
+**无需改动**。`POST /admin/chat/open-house` 入参/出参结构不变；前端**传不传对端 `peerAdminId` 都可**（不传/传占位时由后端反查解析）。原本在「房务先抢单」顺序下聊不通的问题现已透明修复。
+
+## 影响接口
+- `POST /admin/chat/open-house`（行为增强：peer 缺省/占位时后端反查当前房务 claimer，出参 `peerAdminId/peerName/peerRole` 现会带真实房务）
+- 跨服务：order-v3 `chat-summary-batch` 内部接口响应补 `claimerId`（前端不感知）

changelogs-v2/2026-06/38_4529_切角色与刷新token原子保存_前端必改-管理后台.md

@@ -0,0 +1,26 @@
+# 切角色 / 刷新令牌「掉登」已修 + 前端必改一项（原子保存 token）
+
+> 模块：admin 鉴权（hl-user-service）/ 管理后台
+> 类型：后端 bug 修复（PR #4529 已合 dev-v3 + 测试服实测生效）+ **前端必改一项加固**
+> 日期：2026-06-28
+
+## 背景 / 修了什么（后端）
+
+两个掉登 bug 已修：
+
+- **Bug1（切角色被登出）**：超管切到「房务」等角色后刷新页面报「刷新令牌无效或已过期」被踢回原角色。根因：切角色会轮转 refresh 令牌、使旧 refresh 立即失效，前端若没存住新 refresh 就被登出。
+  - 后端修复：**切角色不再轮转 refresh**（只换发带新角色的 access，refresh 复用、保持有效）。即使前端不改也不会再因切角色被登出。
+- **Bug2（刷新偶发掉登）**：整页刷新偶发「刷新令牌无效或已过期」。根因：refresh 校验与续期非原子，并发刷新读到中间态。
+  - 后端修复：refresh 校验+续期改为 Redis 原子执行，并发刷新不再误判。
+
+测试服实测：切角色后用原 refresh 刷新 200（不掉登）；同一 refresh 并发 3 次刷新全 200；切「定制师/房务」回归全正常。
+
+## 前端必改（1 项加固）
+
+**切角色 `POST /admin/auth/switch-role` 与刷新 `POST /admin/auth/refresh` 的响应里，`token`(access) 与 `refreshToken` 要原子地一起保存**（两者同时落本地存储，避免只存其一），切角色后用响应里的新 `token` 调后续接口。
+
+- 说明：后端每次 switch-role / refresh 都换发**新 access**并把旧 access 轮转出（access 白名单 last-issued-wins）。所以切角色/刷新后**必须改用响应里的新 access**，旧 access 会失效（这是既有设计，非本次改动）。本次修复保证的是 **refresh 不会因切角色失效**，刷新链路稳定。
+
+## 影响接口
+- `POST /admin/auth/switch-role`（行为：refresh 不再轮转；响应结构不变）
+- `POST /admin/auth/refresh`（行为：校验+续期原子化；响应结构不变）