diff --git a/changelogs-v2/2026-06/23_4279_车辆VIN重复错误码600107改600113_管理后台.md b/changelogs-v2/2026-06/23_4279_车辆VIN重复错误码600107改600113_管理后台.md
new file mode 100644
index 0000000..6f9a150
--- /dev/null
+++ b/changelogs-v2/2026-06/23_4279_车辆VIN重复错误码600107改600113_管理后台.md
@@ -0,0 +1,37 @@
+# 车辆档案: VIN 重复错误码 600107 → 600113
+
+> **服务**: hl-fleet-service
+> **PR**: #4279
+> **Issue**: #4278
+> **日期**: 2026-06-23
+> **影响范围**: 管理后台 · 车辆管理（新增/编辑车辆时 VIN/车架号重复校验）
+
+---
+
+## ⚠️ 关键变化
+
+新增/编辑车辆时**车架号(VIN)已存在**的业务错误码，从 **600107** 改为 **600113**（message 不变，仍为「车架号已存在」）。
+
+- 以前：VIN 重复返 `code=600107`
+- 现在：VIN 重复返 `code=600113`
+- 同时 **600107 现在专指另一含义**：车型「型号已配置价格，不能删除」(`MODEL_HAS_PRICING`)
+
+**前端只要按 `message` 文案展示则无需改动**（文案没变）。**只有当前端对 `code=600107` 写了特殊分支逻辑时，才需把「VIN 重复」分支改判 `600113`**，否则会把 VIN 重复误判成「型号已配价不能删」。
+
+---
+
+## 一、背景
+
+600107 此前被**两个**业务错误码同 owner(hl-fleet-service)双占：车辆档案的「VIN 重复」与车型库的「型号已配价不能删」。错误码 Registry 不校验同 owner 段内重叠，导致前端拿到 600107 无法区分到底是哪种错误。第 3 轮审计整改：把「VIN 重复」让位下移到车辆档案段下一空闲码 600113，600107 归还车型库专用。
+
+## 二、变更错误码清单
+
+| 含义 | 旧 code | 新 code | message | 触发场景 |
+|------|--------|--------|---------|----------|
+| VIN/车架号已存在 | 600107 | **600113** | 车架号已存在 | 新增/编辑车辆，VIN 与库内已有车辆重复 |
+| 型号已配价不能删 | （600107 双占） | 600107（独占） | 型号已配置价格… | 删除车型时该型号已挂价格日历 |
+
+## 三、前端动作
+
+- 默认展示后端 `message`：**无需改动**。
+- 若有针对 `600107` 的特殊 UI 分支：将「VIN 重复」判定改为 `600113`。
diff --git a/changelogs-v2/2026-06/23_4284_4286_4295_车务未派看板数据打通-定制师提用车需求自动建占位_管理后台.md b/changelogs-v2/2026-06/23_4284_4286_4295_车务未派看板数据打通-定制师提用车需求自动建占位_管理后台.md
new file mode 100644
index 0000000..9c4e7b3
--- /dev/null
+++ b/changelogs-v2/2026-06/23_4284_4286_4295_车务未派看板数据打通-定制师提用车需求自动建占位_管理后台.md
@@ -0,0 +1,37 @@
+# 车务派单: §7.2「未派看板」数据打通（定制师提用车需求 → 自动出现未派车）
+
+> **服务**: hl-order-service-v3 + hl-fleet-service
+> **PR**: #4284 / #4286 / #4295
+> **Issue**: #4283 / #4285 / #4295
+> **日期**: 2026-06-23
+> **影响范围**: 管理后台 · 车管控制台（§7.2 矩阵未派清单 / §7 矩阵甘特）
+
+---
+
+## ⚠️ 关键变化（数据打通，**接口契约不变**）
+
+§13.5 用车需求 → 派单 expand 链路已打通并经测试服真实数据 e2e 验证。**`GET /admin/fleet/matrix/unassigned-orders` 等 §7 看板接口的请求/响应结构没有任何改动**，唯一变化是：**这些接口现在会返回真实的未派车占位数据**（此前因 expand 未接线、看板长期为空）。
+
+车管控制台可以开始用真实数据联调 §7 矩阵 / §7.2 未派清单了。
+
+---
+
+## 一、未派数据怎么产生 / 怎么消失（前端理解数据流即可，无需调用 expand 接口）
+
+| 触发动作（已有接口） | 结果（§7.2 未派看板） |
+|---|---|
+| 定制师提交用车需求 `PUT /v3/admin/order/{id}/vehicle-requirement`（fleet[] 填 N 个车型） | 对应订单在未派清单出现 **N 行**未派占位（一车型一行，按 fleetItemIndex 区分） |
+| 定制师**改提**用车需求（同接口，PENDING_EDIT/DONE_ADJUST） | 未派行按新需求刷新；旧需求的未派占位自动清除（#4295 修复，**不再残留孤儿**） |
+| 订单取消 `POST /v3/admin/order/{id}/cancel/pre-trip` | 该订单的未派占位自动从看板消失 |
+| 车管在看板对某未派行配车（§8 派单） | 该行从「未派」转入「已派」 |
+
+## 二、测试服 e2e 实证（已验证，可放心联调）
+
+- 核心订单提 2 车型用车需求 → §7.2 未派看板即时出现 2 行（车型/接送日期/紧急徽标 T-N 正确）。
+- 订单取消 → 2 行未派占位即时消失。
+- 改提需求（1 车→2 车）→ 看板正好 2 行（#4295 修复前会残留 1 条孤儿，现已修复）。
+
+## 三、前端动作
+
+- **无接口改动，无需改代码**。§7 / §7.2 看板接口照原契约调用即可。
+- 若此前因看板返回空数据而无法联调，现可用真实数据继续。