docs(order-v3/adjustment): 车需求快照回显 fleet/specialTags(#4545) + 候选换房型清旧预算(前端处理)

changelogs-v2/2026-06/39_4545_调整订单快照车需求回显fleet与specialTags-修改接口-管理后台.md

@@ -0,0 +1,48 @@
+# 调整订单快照：车需求回显 fleet / specialTags（前端对接）
+
+> 模块：订单 · 调整订单弹窗 · 车辆安排（管理后台）
+> 类型：**接口补字段（snapshot 车需求段新增 fleet/specialTags 回显）**
+> 关联：工单 #4545 · PR #4547（已合 dev-v3 + 测试服实测通过）
+> 日期：2026-06-28
+
+---
+
+## 一、背景（修车辆 tab 幻影「已修改」）
+
+调整订单弹窗「车辆安排」tab 恒显示「已修改」橙点 + 提交调整(1)，即使没改过车辆。根因：调整订单是无草稿统一提交模式，「已修改」由前端拿表单当前态 diff snapshot 算的；但 snapshot 的车需求段 `vehicleRequirement` **漏返了 fleet 和 specialTags**（VO 里压根没这俩字段，只有恒为 null 的 vehicleType/requiredSeats），前端拿不到车需求当前值基线 → 无法正确 diff → 幻影「已修改」。
+
+本次后端把 snapshot 车需求段补齐为「无损回显」（与房需求段口径一致），前端据此建立正确 diff 基线即可消除幻影已修改。
+
+## 二、接口变化
+
+`GET /v3/admin/order/{id}/adjustment/snapshot`（scope 含 `VEHICLE_REQ` 或不限定时返回）
+
+`response.data.vehicleRequirement` **新增两个字段**：
+
+| 字段 | 类型 | 说明 |
+|------|------|------|
+| `fleet` | `Array<{vehicleType, seats, count}>` | 车型组合（多车型混合用车的每一组：车型/座位数/数量），结构与 submit 入参的 fleet 完全一致 |
+| `specialTags` | `Array<String>` | 通用特殊诉求标签码（儿童安全座椅/大行李空间/中文司机… 的 code） |
+
+测试服实测返回示例：
+```json
+"vehicleRequirement": {
+  "id": ..., "version": 2, "status": "DONE",
+  "vehicleType": null, "requiredSeats": null,   // 旧兼容字段，恒 null，勿用
+  "remark": "...",
+  "fleet": [{"vehicleType": "SUV", "seats": 5, "count": 2}],
+  "specialTags": []
+}
+```
+
+> `vehicleType`/`requiredSeats` 是历史兼容字段、恒为 null，**车型/座位/数量请一律读 `fleet`**；特殊诉求读 `specialTags`。
+
+## 三、前端要做
+
+1. 车辆表单回显改为读 snapshot 的 `vehicleRequirement.fleet`（多车型组）+ `specialTags`（诉求 chips），而非默认值/别处。
+2. 车辆 tab 的「已修改」脏检测，baseline 用 snapshot 的 fleet/specialTags/remark；用户未改时三者与 snapshot 一致 → 不再误判已修改。
+3. 提交时车辆改动仍按原 submit 结构（fleet + specialTags + remark）提交，结构与回显对称。
+
+## 四、后端
+
+snapshot 车需求装配镜像房需求（fleet/specialTags JSON 反序列化回填），纯增量字段、无 DB 列/schema 变更。

changelogs-v2/2026-06/40_调整订单酒店候选换房型后预算残留旧房型协议价_前端处理-管理后台.md

@@ -0,0 +1,30 @@
+# 调整订单·酒店候选：换房型后「预算/晚」残留旧房型协议价（前端处理）
+
+> 模块：订单 · 调整订单弹窗 · 酒店安排（管理后台）
+> 类型：**前端处理说明（后端无改动，行为符合预期）**
+> 日期：2026-06-28
+
+---
+
+## 一、现象
+
+调整订单弹窗 → 酒店安排 → 某晚候选，把房型从 A 换成 B（B **没有价格日历**），「预算/晚」仍显示 ¥320.00——这 320 是**上次选的房型 A 的协议价**残留，没随房型切换清掉。
+
+## 二、根因（后端正确，前端没刷新）
+
+- 「预算/晚」的值来自 snapshot：`GET /v3/admin/order/{id}/adjustment/snapshot` → `hotelDayDefaults[].segments[].budget`，它是**上次提交时按协议价持久化的段预算**。
+- 预算是**后端权威**：后端在提交（submit）时按 `(hotelId, roomCategory, stayDate)` Feign 查协议价、对该段候选取最高非空协议价覆盖预算（**前端传的预算值不作数**），房型无价格日历时该段协议价为 null。提示语「预算按酒店协议价为准、提交后房控据此回配」即此意。
+- 所以预算只在**提交时**才按当前房型重算。用户在弹窗里把房型 A 换成 B 后、提交前，前端显示的还是 snapshot 里 A 的持久化协议价（320），没有随房型变化刷新 → 看起来「B 这个无日历房型却显示了 A 的协议价」。
+- **目前没有「按单个房型实时查协议价」的端点**给前端在换房型时即时刷新预算（协议价仅在 submit/snapshot 链路内部经 Feign 查）。
+
+## 三、前端要做
+
+用户在某候选**切换房型**时，把该候选的「预算/晚」**清空**（不要保留旧房型的值）：
+
+- 预算本就是后端权威、提交时按新房型协议价回填，前端展示的是参考值；换房型后旧值已失效，应清空，可显示占位提示如「提交后按协议价回填」。
+- B 这类无价格日历的房型，提交后后端算出的协议价就是 null（空预算），与清空一致；有日历的房型，提交后会回填该房型协议价。
+
+## 四、后端
+
+无改动。预算口径（提交时按协议价权威覆盖、无日历返 null）符合设计。
+若后续希望换房型时即时展示新房型协议价（而非清空待提交回填），需后端新增一个「按 hotelId+roomCategory+date 查协议价」的轻量只读端点——属增强、非本次必需，可另提需求。