API Changelog Bot和Claude Opus 5
c7ce1009d6
新增 18_7443：派车批量创建与接送机配置两个端点新增可选入参 kind（TRAVEL|TRANSFER，
不传=TRAVEL，存量请求形状不变），新增错误码 602200/602201/602202/602205。
字段表逐条对源码反向 grep，53/53 全命中。
文档里写明了两条前端必须知道的限制：
1. 上游写口还关着——PUT /v3/admin/order/{id}/vehicle-requirement 传 kind=TRANSFER
恒返 809009（transfer-kind-submit-enabled 默认 false，无 @RefreshScope 要重启），
即产品上目前产不出 TRANSFER 需求，前端可按契约对接但别排进本期可演示范围。
2. 已建出的 TRANSFER 派车行，确认与改派仍会 605041（三个内部命令对象不携带 kind，
属跨服务契约缺口，已登记 #7443 AC-24）。
八、测试环境已验证写的是实测：单元层 fleet 全量 4220/0/0/4、完整性 322/322；
网关端到端 AC-6/AC-7 均通过（batch 带 kind=TRANSFER 返回 200，落库两行服务日
2026-10-11 与 2026-10-17 均在行程窗外，未出现 605041/605062/605905；改接机行后
送机行逐字段未变）。同时保留限定：那条 TRANSFER 需求行是 SQL 构造的，订单侧真实
写口不在本次证据范围内——没有写成「全链路已验证」。
订正 17_7442 与 17_7443 的错误响应示例（共 3 处）：原写 {"code": 200, ...,
"errorCode": <业务码>}，两处都错——Result 没有 errorCode 字段，而业务失败时
GlobalExceptionHandler 走 Result.error(e.getCode(), message) 把业务码放进 code。
前端照原文按 code == 200 判成功，会把业务失败读成成功。
⚠️ success 是真实字段没有删：Result.java:43 public boolean isSuccess() 没有
@JsonIgnore（全类只有 :142 getCheckedData 被忽略），Jackson 会序列化它——
只按 private 字段清单 grep 会误判它是编的，差点据此把一个前端正在读的字段删掉。
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>