100 次代码提交

此分支

此分支

所有分支

作者	SHA1	备注	提交日期
API Changelog Bot和Claude Opus 5	ba87a9b611	docs(changelog): #7987 订正被 mmg 实证推翻的「前端必须新增渲染分支」，并清空 not_required 上的认领字段 ... 正文第 38 行说「前端必须新增这两个 event_type 的渲染分支」，而 mmg 在 frontmatter 里已用实证翻成 not_required（StatusLogsPanel 渲染 eventTypeName || eventType || '事件'，后端直供中文名+原码兜底，前端无自建 映射表，零改动）。订正了状态位却没回头改正文，那句话会让下一个读的人以为 前端还有活。原句划掉保留接 grep，并注明这条结论依赖「后端继续直供 eventTypeName」——该字段哪天返 null，渲染缺口会重新成立。 frontend_owner/frontend_ref 清空：交付指南写死 not_required 条目任何人 （含前端）不得回写这 4 个认领字段，填了会被 E_FRONTEND 残留校验拦下 （2026-08-19 #6077 先例）。本文件能推上去是因为门禁只扫新增路径， 不是因为合规。mmg 的实证本身原样保留。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-21 09:02:10 +08:00
API Changelog Bot和Claude Opus 5	9d4b4387f0	docs(changelog): #8061 清理 status_note 里重复的 gateway_status 说明 ... 连续修订留下一段标着 frontend_status 却在讲 gateway_status 语义的残渣， 标签与内容不符会误导下一个填这个字段的人。内容并入括注，标签改回对的。 mmg 的 frontend_status=not_required 原样保留：他们在自己代码库里查实 getOrderOperationLog(api/fleet/board.js:58) 全仓零调用方、src/views/fleet 无 operationType 命中，后端担心的白名单过滤层尚不存在。那是前端负责人 带证据的判定，比后端的推断硬。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-21 00:15:45 +08:00
API Changelog Bot和Claude Opus 5	bc07d07f20	docs(changelog): #7980 AC-6 司机险年保台账两写口补同名锁——新增 100503（内部接口，无 C 端） ... PR #8072（合并提交 8bf9c520c）。三个端点都在 /v3/internal/insurance/**，只有 fleet 经 Feign 调，fleet 侧 Controller 全挂 /admin/fleet/drivers/**，无小程序 C 端路径。 🔴 本次只有两个端点新增 100503，不是三个： - driver-annual/upsert 与 driver-annual/{driverId}/invalidate 共用 name=driver-ins:ledger， 这两者之间新增互斥，因此新增 100503。 - driver-purchase 补的是自成一域的 name=driver-ins:purchase，锁语义与改前完全等价 （只是 Redis 键字符串从「类全名+方法名」变成显式 name），未新增任何错误码。 唯一可能传导到 hl-ui 的路径已逐行核实：DriverInsuranceService:352-353 投保后同步作废 旧 MANUAL 台账，失败在 :226 被 catch(AnnualBindingRollbackQueuedException) 捕获并统一 包装成既有错误码 600206，前端看到的仍是既有码，无需为 100503 新增处理。 backend_status=deployed：2026-09-20 23:43 order-v3 滚到 8bf9c520c（运行版本与合并提交 精确相等），两实例 12/13 秒起监听。「八、测试环境已验证」明写了没有做任何功能调用取证、 100503 在测试服上一次都没触发过——是「没测」不是「测过不会触发」，理由是端点不经网关且 手动触发会污染真实司机台账、触发真实保游扣费。 文件名日前缀用 21 是因为提交日已跨过零点；updated_at 同步为 2026-09-21。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-21 00:00:11 +08:00
API Changelog Bot和Claude Opus 5	6ce29f1872	docs(changelog): #7980 补三份 @Lock4j 同名锁 changelog（房务7口/出行人+发票8口/产品库存2口） ... 三份同属一个机制：@Lock4j 未写 name 时 lock4j 把方法名拼进锁键，keys 逐字相同的 多个方法各持一把锁、互不阻塞。本批给各组补同一个显式 name，互斥才真正生效。 对前端唯一可见的变化是这些端点新增一个可能返回的 100503（HTTP 200 + body code）。 路径、方法、请求/响应字段全部零变化。 - 配房工作台 7 个写口（PR #8069）：全 admin，无 mp/C 端。 - 出行人删改 + 发票申请 8 个写口（PR #8049）：三组全部触达小程序 C 端， 逐端点沿 hl-mp-service 的 Feign 与公网 Controller 查证了调用链。 - 产品库存扣减/恢复 2 个 internal 口（PR #8047）：当前零调用方，修复是预防性的。 三份 backend_status 均为 deployed 且附真实部署读数：product-v2 滚到 ba8aab3ab （部署前 4cbccc26b，落后 93 个提交）、order-v3 滚到 ba8aab3ab（部署前 c35251b07）， merge-base --is-ancestor 逐个验过。其中 AC-5 的 b9738a20f 在部署前确实不在运行版本内， 是真正的「从不生效到生效」。 🔴 三份的「八、测试环境已验证」都明写了没有做功能调用取证及其原因（写口调用会真实 改动配房行/出行人行/库存，测试服数据多会话共用且撤不回来），并写明 100503 一次都 没触发过——是「没测」不是「测过不会触发」。互斥由落库级并发 IT 与按效果枚举的契约 用例覆盖，这是 name 契约类改动的恰当取证层级。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-20 23:26:24 +08:00
API Changelog Bot和Claude Opus 5	6ade6e1332	docs(changelog): #8061 解除共用关系只清成员占用，同槽非成员不动 ... fleet 已部署测试服 00930f5d6，网关实测取得阳性与阴性两条对照： 阳性 releasedSourceIds 恰为两个成员且库内真变 unassigned； 阴性 非成员 C 的 assignment_status/vehicle_id/driver_id 解除前后逐一相等。 两条缺一不可——只有阳性的话，「C 没变」与「解除没跑起来」观测相同， 且阳性在修复前同样成立（旧实现一样释放成员，只是顺手把 C 也清了）。 frontend_status=pending：请求/响应字段零增删，但派车操作日志新增 operation_type 取值 share_release_cleared，前端若按白名单过滤会静默 丢掉这条记录，而那正是本次补留痕要解决的问题。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-20 23:21:18 +08:00
API Changelog Bot和Claude Opus 5	e813ea774d	docs(changelog): #7990 候选资源槽位需求锚点按 requirementId 反查（AC-8 修复） ... 本单名下已有一份 changelog（看板身份三元组，PR #8048），但按内容 grep 那份已推送 文件，requirementMatched / seatsEnough / requirementMismatchReasonCode / 候选 / 座位 六个关键词全部 0 命中——AC-8 的候选面行为变化一个字都没有。 这正是 #7443 被重开的形态：按单号数文件全绿，按内容查全空。所以另写一份， 而不是让那份顶数。 行为变化（POST /admin/fleet/assignments/candidates）： TRANSFER-only 订单上，seatsEnough / requirementMatched / requirementMismatchReasonCode 由「恒空/退化」变为按 TRANSFER 需求真实判定。 修复前 AssignmentCandidateService.resolveSlotRequirement 的车型/座位锚点恒取 TRAVEL 需求：两类并存时接送机槽锚到 TRAVEL 需求的第 fleetItemIndex 项；TRANSFER-only 单上 取到 null、锚点整块退空、座位判据回退到整单 headcount，于是 5 座 SUV 反而「够」， 只剩车型一条提示（少报一半）。 两种失败出口都是 SlotRequirement.empty() 这条「仅提示不限制」的正常路径——不抛错、 不打日志。车务只看到提示不对，没有任何信号能顺藤摸瓜。这条静默属性已写进正文。 网关实测（2026-09-20 22:0x，同一次请求两辆车判定截然相反）： 7 座 SUV 蒙A-U1557 → seatsEnough=true / requirementMatched=true / reasonCode=null； 5 座 SUV 蒙P321A → seatsEnough=false / requirementMatched=false / reasonCode=SEATS。 修复前两车都会是 requirementMatched=null。这组阴性对照排除了「返回一堆候选但根本 没过滤」这个竞争解释。 取证前先补了部署缺口：开测时 fleet 停在 c35251b07，而 bf4fba5a2(#8062) 触及 fleet 却未部署，重新部署到 0/N 才开测，否则会测到旧字节。 请求契约完全不变：修法是按 requirementId 匹配式反查 kind，不是给请求补 kind 位。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-20 20:00:03 +08:00
API Changelog Bot和Claude Opus 5	ff834a4858	docs(changelog): #8051 订正 PR 字段——写的是「待建」，实际已合入 ac9efb735 ... 交接件里的「待建」会活得比它的语境久：下一个人看到它会以为代码还没合。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-20 19:40:10 +08:00
API Changelog Bot和Claude Opus 5	52b3f81fd0	docs(changelog): #8051 解除共用关系不再跨服务日跨团误清派车行 ... 代码 PR #8058（squash ac9efb735）已合入 dev-v3，fleet 测试服部署在 c35251b07 （2026-09-20 18:58，STATE=ok），merge-base --is-ancestor ac9efb735 c35251b07 = 真， 并用 jar 字节正负两向自证：新类 AssignmentOccupancyDayScope 部署前不在 jar 里、 部署后在（只查后一次没有分辨力）。 网关两轮独立实测 DELETE .../share-groups/{id}?survivorPolicy=RELEASE，两半边都取了： - 阳性对照：本服务日那张确实被处理（assigned/有车 -> unassigned/NULL，且在 releasedSourceIds 里）； - 负对照：跨日的独立派单三字段逐一不变，跨日+跨团的原受害者所在三个团七个服务日 共 7 行 fleet_group_dispatch 释放前后逐字段完全一致。 缺任一半，「另一日没变」与「解除根本没跑起来」观测上完全一样。 frontend_status=not_required：本次不改请求/响应形状、不增删字段、不新增错误码。 但仍是给 mmg 的知会件——「解除共用关系」这个动作的影响范围变了，看板上此前莫名 变成「待派车」的那些户，原因在此。 一并订正两处事实： - 误伤是 6 行不是 7 行（第 7 行同日同槽，RELEASE 策略下本就在处置范围，补了日期 过滤照样会被释放）； - 修复只动了 ASSIGNMENT 侧，GROUP_DISPATCH 侧本就按 trip_date 精确过滤、从无此 bug。 仍未解决且不在本篇范围：同一资源同一服务日上的非成员在途行仍会被 RELEASE 一并 软清（releaseClaims 不引用 members），已另立工单 #8061 待产品口径。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-20 19:39:07 +08:00
API Changelog Bot和Claude Opus 5	91cca38c2e	docs(changelog): #7987 #7988 #8013 网关实测通过，gateway_status 置 verified，并订正 #7987 一处契约偏差 ... 2026-09-20 18:22-18:46 经网关 api.test.1814.love:9443 实测（账号 cw_test_7444）： - #7988 GET .../vehicle-requirement：七个只读观测字段全部出现，字段名/类型与正文 一字对应，逐字段对照无出入。 - #7987 GET .../status-logs：开窗（BATCH_VEHICLE_REQUIREMENT_REOPENED）与重配 （BATCH_VEHICLE_DISPATCH_RECONFIGURED）两类事件均取到，extra 各项齐全。 - #8013 POST/GET .../share-groups：只改 costBearer 不改成员，写出的历史行是 COST_BEARER_CHANGED 而非 MEMBER_ADDED，且按正文声明的口径用事后 GET 查证， 没有拿 POST 响应体推断。 订正 #7987 一处契约偏差（5 个位置）：重配事件的 operatorId 正文写字符串 "SYSTEM"， 实测为 null，与库里其它 SYSTEM 类事件（如 BATCH_VEHICLE_REQUIREMENT_DONE）惯例一致， 判为文档写错而非实现错。前端若按原文档判空会得到相反预期，故订正与发布同一批。 backend_status 的判据是 merge-base --is-ancestor 对各自 squash 提交与测试服部署点 （fleet 311dc92ee / order-v3 e179e09bd）逐条为真，不是「已在主线」这种弱判据。 verified_at 留空：该字段归 frontend_status 用，与 gateway 的验证时刻是两码事。 同批还有 #7444 与 #7973 两份草稿未推送，gateway_status 如实保持 pending—— #7444 缺 reconfigure / restore-cancel happy path / DELETE 三处证据， #7973 的 confirmCrossResident 入参未被真正走到（目标资源已占用，未触发 605036 分支）。 「同一个端点被调通了」不等于「本篇登记的那个入参被验过了」。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-20 19:00:10 +08:00
API Changelog Bot和Claude Opus 5	73e0def125	docs(changelog): #7990 车务看板订单详情按需求各返一组身份三元组，接送机确认参数有来源了 ... GET /admin/fleet/board/orders/{orderId} 新增 requirementIdentities： 每条用车需求各一项，含 kind / requirementId / requirementVersion / requirementSha256 / dispatchPlanGeneration。 顶层原有的那一组三字段语义不变，仍指行程用车（TRAVEL），前端不改也不炸。 为什么前端必须接：POST /admin/fleet/assignments/requirements/{id}/confirm 的三个 expected 入参（version / sha256 / planGeneration，均 @NotNull 或 @NotBlank） 唯一公开来源就是本端点，而此前它只给 TRAVEL 那一组 ⇒ 接送机需求在管理后台确认不动。 同时修掉一个必 500 的场景：同一订单同时有两条已确认需求时， 本端点每一次都抛 IllegalStateException。现改为正常返回； 真出现无法判定的代际时抛新业务码 605311（HTTP 200）。 行为变化（是修复不是回归）：接送机需求未定稿时，它的待派车行 现在会出现在逐日计划里——那些行归它自己的需求，先前隐藏它们才是缺陷。 gateway_status=verified 的依据是真实调用不是推断：经测试网关拿到 requirementIdentities 两项后，原样用于需求级确认返 code=200、 confirmed=true、finalPlanPublished=true ⇒ 该字段不只是返回了， 而是真的能驱动接送机确认走通。 Refs #7990 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-20 17:59:50 +08:00
API Changelog Bot和Claude Sonnet 5	24dde670d1	docs(changelog): #7443 AC-26 TRANSFER 派车行四端点网关实测收尾，gateway_status 回填 verified ... 四个既有端点（candidates/change/confirm(assignmentId)/confirm(requirementId)）经网关 逐一实测通过；此前缺失的 confirm(requirementId) 借新上线的 GET /admin/fleet/board/orders/{orderId} requirementIdentities 字段取得 expectedRequirementVersion/Sha256/expectedPlanGeneration 真值补齐验证。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-20 17:52:04 +08:00
API Changelog Bot和Claude Opus 5	9ee36c0b94	docs(changelog): #7980 AC-4 发票签发组三写口补同一把锁，新增可重试冲突码 100503（会触达小程序 C 端） ... order-v3 的 InvoiceAdminService.issueInvoice / reuploadInvoice 与 InvoiceMpService.reissueInvoice 三处 @Lock4j 写了逐字相同的 keys 却都没写 name；lock4j 的 Redis 键在 name 缺省时退化成 「类全限定名+方法名」，于是三处各持一把锁。后果是 reupload ∥ reissue 会留下一单两张有效票。 本次三处补同一个 name = "order-invoice:issue"。PR #8043 → 09b8f2323 已合 dev-v3。 接口路径、方法、请求/响应字段、既有错误码全部零增删。唯一契约变化是新增一个可能返回的错误码 100503 （RESOURCE_LOCKED「资源被占用,请稍后重试」），且它以 HTTP 200 + body code 返回—— 前端只看 HTTP 状态码会把它当成功。 该码会触达小程序 C 端：reissue 经 hl-mp-service 两个入口透传 （MpV3InvoiceController:54 直接透传；MpInvoiceController:108 经 getCheckedData()， Result:143-148 用上游 code 原样重抛）。用户点「申请重开发票」时若财务端正在同一张票上操作， 等最多 3 秒后收到该提示；反向同理。此前这几条互不阻塞。 测试服证据（backend_status 因此才从 pending 转 deployed；此前门禁 E_BACKEND_PENDING 正确拦下过一次， 没有为换绿灯改状态，而是去把部署真的做了）：运行版本 5d14bc524， merge-base --is-ancestor 09b8f2323 5d14bc524 → YES。 ⚠️ 如实记：部署前 COMMIT 已是 5d14bc524（另一会话此前推上去的），本次重跑不等于「使它从不生效变生效」。 🔴 证据强度按实际收窄，没有拔高：redis-cli MONITOR 抓到键 lock4j:order-invoice:issue#order-invoice:issue:<invoiceId>、无方法名混入， 但 MONITOR 只跑了三个写口里的一个（issueInvoice）；另两处由代码同源 + 反射守卫用例 InvoiceIssueLockNameGuardTest（断言三处 name 非空且相等）覆盖，未在测试服上单独抓包。 正文里 §2/§3 原本写「同第 1 节，链路一致」会被读成「也实测过」，已改成明确写「未单独抓包」。 100503 未复现：并发两个 issueInvoice，一个 code=200、另一个 code=581502（INVOICE_CANNOT_ISSUE 业务状态守卫），不是锁超时码。原因是临界区极短（与 fleet 那轮 34 并发未触发同因）。 第二个请求被业务守卫拦下说明没产生并发脏写，但这是旁证不是互斥证据。 两面都写：路径源码级真实存在（已读码确认 + IT 里实测过等 3024ms），但测试服未能触发， 不代表更长事务／生产数据量下不会触发。 取证干净：三张票全是测试夹具（客户名「核团甲/乙/丙」，apply_reason 为 #7932 造数）， 改前均 REQUESTED/NULL/NULL，已按改前快照逐列 UPDATE 还原并复读一致， Redis --scan lock4j:*order-invoice* 复扫为空。过程中发生过一次 code=401（token 被别的会话顶掉）， 该次调用前无任何读数，已重登并把那段整个重做。 顺带修掉一个会挂门禁的文件名 bug：原名后缀写的是「小程序管理后台」，而 changelogs-v2/ 根目录 要求端类型字面量必须是「管理后台」，改名前文件名校验确实报 E_CLIENT。 Refs #7980 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-20 17:47:14 +08:00
API Changelog Bot和Claude Opus 5	8ff7f0761e	docs(changelog): #5935 改期残留清理——前端要的能力已具备，用现有读写口即可 ... 前端 2026-09-20 待办清单第 4 项要求读侧补 residueServiceDates 日期数组， 并称写口 POST .../slots/{slotId}/clear-residue-dates 已就绪。两条都不成立： - 那个写口在 origin/dev-v3 上零命中——「槽位(slot)」概念已随 #7067 退役， 基于 slotId 的写口不会再有； - 读侧能力早就有，只是不叫 residueServiceDates：candidates 响应的 cells[] 逐日带 rescheduleResidue + serviceDate + assignmentId， 另有 editableServiceDates 已并入残留日期。 故本件是用法说明，后端零代码改动：逐日清理走 DELETE /assignments/{id}， 整批清理走 POST /batch 不提交残留项（diff 会精确取消）。 已写明真正的写侧边界——POST /batch 有「已过去日期不可改」硬门禁， 而改期后延场景的残留日多半已过去。 DELETE 路径对已过去日期是否放行未取证，如实标【需确认】； 若实测也挡住，那才需要另开工单放开残留行的过去日期取消。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-20 17:41:05 +08:00
API Changelog Bot和Claude Opus 5	41c0f752f9	docs(changelog): #7972 接送机的免车闸与结算闸改为非对称判据，809114 放宽 / 584131 新增拒绝 ... PR #7976（572dc4037）改了两个既有错误码的抛出条件，零新增错误码： - 809114（整团免车被派车阻塞）改为只看 TRAVEL——「只订接送机、没有团车」 是合法的在团户，不该被上游拒绝免车，属于放宽。 - 584131（团期用车未就绪）对 TRANSFER 补独立的非对称判据：不存在放行 / DONE 放行 / 其余拒。原 TRAVEL 的抛出与放行结论逐字不变。 整团免车现在只短路 TRAVEL 一支，两类互不豁免。 🔴 运维注意已写进正文：存量里停在 PENDING 的 TRANSFER 需求行，其所在户的 finalize 会从 200 变 584131——那是本次改动的预期行为，不是回归。 backend_status=deployed 依据 572dc4037 是测试服 order-v3 所在提交的祖先； gateway_status=not_required 依据本次不涉及网关路由变更（仅后端判定条件）。 校验器 PASS，校验对象 4 个端点。 Refs #7972 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-20 17:35:19 +08:00
API Changelog Bot和Claude Opus 5	89d7e4f75d	docs(changelog): 订正 01_6905 里「estimatedCost 已可用」这条错误交接（共 4 处，非 1 处） ... 前端会话核出 01_6905 第 446 行写着「预计毛利 = totalPrice − estimatedCost 现可直接算 （estimatedCost 已可用）」，而该字段从未有过数据。前端据此规划的「预计毛利」列在任何时点都算不出来。 本会话独立复核成立，并补上两个原 grep 会漏的口径： - setEstimatedCost 在 main 代码 0 命中； - getEstimatedCost 也是 0 命中——这条关键，MyBatis-Plus 的 LambdaUpdateWrapper.set(Entity::getXxx, v) 用的是 getter 引用，只 grep setter 会整类漏掉； - 字段名在整个 Java 侧只出现在实体 OrderInfo.java 自身的声明里，其余全是 docs 与建表 DDL ⇒ 没有任何别的 DTO/VO 带这个属性名，连 BeanUtil 那种反射拷贝也无从填它。 ⇒ order_main.estimated_cost 全仓零写入点，estimatedCost 自 #6905(47aaff0be) 透出那天起恒 null， 不是后来才失效；已于 #7536(6182d566d) 从 003 出参删除。 ⚠️ 同一条错话在正文共 4 处（字段表 :281、totalPrice 行的毛利公式 :282、 新增/派生对照表 :390、联调口径第 4 条 :446），外加在途返工表 :455 的半句。 只改被举报的那一处会让订正本身成为新的不一致来源，故五处一并改，并做了全文残留断言： 无订正标记而仍出现 estimatedCost 的行 = 0。 订正一律保留原文加删除线、不抹除，旧串仍可被 grep 接住（estimatedCost 出现 11 次）。 同时指向现行宿主：逐户毛利在核团接口 GET /v3/admin/order/group-batch/{groupBatchId}/audit 的 allocs[].grossProfit / costAmount（GroupBatchAuditRespVO:204-208 声明， GroupBatchAuditService:742-743 真实填值，见 18_7932，亦即 14_7536:97「毛利改核单页」所指）。 顺带订正出处：estimatedCost 由 #6905(47aaff0be) 引入，不是 df8dbea0c——后者只加了 totalPrice。 发现来源：前端问题会话对 origin/dev-v3 的两轮核查（核查 + 对抗复核）。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-20 17:30:44 +08:00
API Changelog Bot和Claude Opus 5	7bc90b0be6	docs(changelog): #7980 价格日历四个写接口补齐真实并发互斥 + 新增可重试冲突码 100503 ... hl-fleet-service 车型价格日历四个写口（批量设价 / 多车型批量设价 / 批量改状态 / 清除价格日历） 此前虽各自写了相同的 @Lock4j keys，但都没写 name；lock4j 落 Redis 的锁键含方法名， name 缺省时退化成「类全限定名 + 方法名」，四处因此各自持有一把互不相干的锁—— 接口文档里一直写着的「四个价格写端点全互斥」此前并不成立。本次补上同一个显式 name，互斥才真正生效。 接口路径、方法、请求/响应字段、既有 4 个业务错误码（600500-600503）均零增删。 唯一的契约变化是新增一条可能返回的错误码 100503（RESOURCE_LOCKED，「资源被占用,请稍后重试」）， 且它以 HTTP 200 + body code 的形式返回——前端只看 HTTP 状态码会把它当成功。 关于 100503 的触发频率，正文两面都写，缺一面都会误导前端： - 该路径源码级真实存在（acquireTimeout 默认 3000ms + LockFailureExceptionHandler 转 100503 + @ResponseStatus(HttpStatus.OK)，三处均已读码确认）； - 但测试服用 4/8/17/34 并发 × 365 天多轮尝试均返回 200，一次未触发（推断原因：本次优化后 单车型 366 天的 DB 往返从 732 次降到个位数，临界区极短，累计排队远小于 3 秒）。 ⇒ 前端仍应防御性处理并允许重试，但不必按高频路径设计交互； 同时不能因为测试服没测到就当它不会发生——更长事务 / 更大载荷 / 生产数据量下的行为未知。 测试服证据（backend_status 因此才从 pending 转为 deployed，此前门禁 E_BACKEND_PENDING 正确拦下过一次）： 部署前 53c2ff2d1 → 部署后 10efbaddf，merge-base --is-ancestor ee1937950 10efbaddf 返回 ANCESTOR_YES； redis-cli MONITOR 实时抓包证实 12 并发只命中同一把锁键 lock4j:fleet:pricing-calendar:write#fleet:pricing-calendar:write，改前那种含方法名的坏形态一次未现， 12 组干净的 acquire→release、未观察到两个持有者同时持锁；71 次回归调用全部 code=200。 测试数据写在原本全空的未来年份（2027 部分/2028/2031/2032/2033，71 组车型×年份）， 已用 71 次 DELETE 逐一还原并按年复核归零，真实业务数据（2026-09 丰田普拉多 24 条）抽查与改前一致。 gateway_status 记 not_required：四端点路径/方法零变化、hl-gateway 版本未动（4cbccc26b）， 是判定不是漏验证，判据已写进 status_note。 Refs #7980 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-20 16:29:13 +08:00
API Changelog Bot	f5596bf88e	docs(changelog): 20_7443 按 CHANGELOG_TEMPLATE 重构分章节,过接口类门禁(#7443) ... E_API_TEMPLATE 要求接口类正文必须有 二/三/四/六/七/八/十/关联 八个章节。 内容零丢失,只重组结构并补齐模板要求的缺失章节。 三处不能丢的都逐字保留: - 覆盖边界(本文只验到「提交」为止;TRANSFER 同步车务 outbox 恒 605905) 在「六、边界行为」子节原样保留,文首「关键变化」只做导读不做替代 - 阳性对照注脚(两字段 fleet 恰好相同不能证明按 kind 取数生效,真正证明 它的是全 null 对照与 id 不同)在「八」原样保留 - 809002/809009 分开处置(去补大交通 / 找后端开开关)新建对照表,两码 各自一行,不混提示 代理顺带查实并订正三处: - 路径参数按源码 AdjustmentAdminController 实为 {id} 而非 {orderId} - status 枚举以 RequirementStatus 为准共 6 个;RespVO 注释里的 CLAIMED 在源码里根本不存在,已显式点出分歧而非悄悄抹平 - 文件实际行尾是 LF 不是 CRLF,按现状保持	2026-09-20 15:35:01 +08:00
API Changelog Bot	b8a079fda0	docs(changelog): 调整订单「车辆安排」页同页提交行程用车+接送机用车两类需求(#7443) ... 后端已合入 dev-v3(PR #8024 -> 920f29d76)并部署测试服,四条真实网关调用取证: 读口双槽(带全 null 阳性对照) / 一次 submit 同交两份落两条 active 行 / 两条 label 原文不同的调整记录 / 无大交通时 809002。 service_dates 两个 kind 分别派生成行程三天与接机送机两天,前端一个日期都不传。 覆盖边界写在正文与 status_note 里: 本文只验到「提交」为止。同一次实测观测到 TRANSFER 需求同步车务的 outbox 恒失败 605905(fleet AssignmentService:11492 取当前需求不带 kind),前端可并行开工但端到端尚未打通。	2026-09-20 15:35:01 +08:00
API Changelog Bot和Claude Opus 5	584df5a90d	docs(changelog): #8016 standard_double 已修掉（PR #8025）——警告改为订正 ... 原文用一句「那是过期垃圾，不要照抄」绕过 roomCategory 入参的过期 Swagger example。该前提今天已被 PR #8025（squash 合并 dev-v3 = 819a147a2）消除： example 现为 DELUXE，value 文案补上取值集合与过滤语义。 按「订正要留着旧编号接住 grep」：standard_double 字面量原样保留（删除线内）， 仍搜到旧值的人会落到这条订正上，而不是搜不到任何东西。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-20 15:05:14 +08:00
API Changelog Bot和Claude Opus 5	9df9dbb442	docs(changelog): #8016 团期候选酒店 roomCategory 入参真正参与房型过滤 ... 工单 #8016 追加范围，PR #8022 合并提交 7b713305e，测试服 order-v3 已部署并网关取证。 契约零增删字段，仅行为变化：matchedRoomTypeId 现在只落在同 roomCategory 的房型上， matchedRoomTypeLabel 恒为房型真实中文名（不再回显入参 code），新增置灰文案「所选房型今日无房」， todayAvailable 口径不变（全房型合计）。 前端行动项（mmg）：第二个房型下拉需按第一个下拉选定的大类过滤，数据早已在 roomTypes[].roomCategory（工单 #4204），用现有字段即可实现，无需等后端。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-20 14:43:16 +08:00
API Changelog Bot和Claude Opus 5	e53008aef4	docs(changelog): 团期酒店候选放开池外 + 候选恒空修复（#7991 #8016） ... 同一端点 GET /v3/admin/hotel-candidates 上 2026-09-20 先后上线的两次行为变更合写一份： #7991 修复 GROUP 候选恒空（排序器以未接线的 batchRoomRemain 硬过滤，池内每家都被丢）、 #8016 放开池外（产品固定房池由硬门降级为加分项，池内恒排最前并带徽章）。 契约零增删，但 GROUP 的 isPoolMatch / poolMatchBadge / recommended / recommendSource 取值域由「恒真/恒非空」变为「可假/可 null」，前端若对 GROUP 写过恒为池内的假设必须改。 实测读数取自测试服 order-v3 @7d44ca268 经网关实调，候选 1→21。 Refs #7991 #8016 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-20 13:49:37 +08:00
API Changelog Bot和Claude Opus 5	25e77cf72e	docs(7442): 修 5 处指向「从未存在过的文件名」的悬空引用，改为单号+glob ... #7442 的两份交接件里有 5 处引用 `19_7444_团期配车就绪门禁与同团车辆共用关系-新增接口-管理后台.md`。 该文件名在全历史零命中（阳性对照：同一条命令能找到确知已提交的 `*7442*reconfigure补登*`，所以零命中是真空不是 glob 写错）——它是起草期的 一份草稿名，该稿已并入现存的 `*_7444_*` 交接件、名字不再存在。 不改成「现存的那个文件名」，因为那会埋一次必然的再次失效： ① 那份文件还没提交（门禁按设计拦着 backend_status=pending）； ② 本仓文件名带提交日前缀，它哪天被推名字就是哪天； ③ 「指向文件名」本身就是错的抽象层——文件名会变，单号不会。 改成「#7444 的交接件（按 `*_7444_*` 检索）」，这个形态不需要第二次维护。 旧名在括号里保留一句接住 grep。 Refs #7444 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-20 12:05:46 +08:00
API Changelog Bot和Claude Opus 5	ae069b00a9	fix: frontmatter 未转义的引号让元数据对所有消费方隐形——修 19_7443 + 给校验器补语法层 ... 现象：Gitea 上打开这份 changelog 看不到元数据表，页面表现就是「这份文件没有元数据」， 而文件里其实写着完整的 16 个键。 根因：status_note 是 YAML 双引号标量，正文里夹着未转义的 ASCII 双引号 （...请勿据此对外宣称"确认/改派已验证可用"）。YAML 在第一个内部引号处截断， 整块 frontmatter 解析失败，Gitea 于是静默不渲染。 为什么一直没人发现：本仓校验器的 parseFrontmatter 是朴素行解析——按第一个冒号切开、 两端引号成对就剥掉——它对「这份 YAML 下游读不读得了」零分辨力。于是这类文件长期处于 「校验器 PASS，而 Gitea 与任何 YAML 解析器都读不到」的状态，没有任何一处报错。 校验器回答的是自己那套宽松读法，不是消费方的读法。 改动两部分： 一、修 19_7443 那两个引号。转义只改字节不改语义，验过三条：改后 yaml.safe_load 成功、 解析出的值与作者本意逐字相同、正文一个字节没动。 二、给校验器补上它完全没有的那一层：validateFrontmatterSyntax，新错误码 E_FRONTMATTER_SYNTAX。本仓刻意零依赖，所以不引 YAML 库，按实际出过的三类伤写 定向判据：内部未转义双引号 / 收尾引号丢失 / 非法转义序列。语法校验排在所有按键 取值的校验之前——frontmatter 读不了的话，后面那些校验都是在校验一份只有本脚本 能读的东西。 自验两个方向：三种人造伤各自被拦（exit=1）；全仓 1030 份逐批跑完，新增错误码 E_FRONTMATTER_SYNTAX 命中 0 次，无连带误伤；独立口径用真 YAML 解析器扫全仓， 546 份带 frontmatter 的全部可解析。 ⚠️ 同一毛病另有 7 份存量文件未修（05_5530 / 08_5592 / 06_7149 / 10_7328 / 13_7625 / 15_7327 / 15_fund-account）。它们的元数据同样对 Gitea 隐形，修法已验证可行， 但每份都带着 1~3 条与本次无关的历史门禁错误（E_FRONTEND_STATE「verified 必须填写 target_release」为主，另有 E_AUTHOR / E_API_TEMPLATE / E_BACKEND_STATUS）， 推不上去。补那些字段需要编造内容，不做。 🔴 值得记一笔的因果：正是门禁这个严格度让这 8 份一直坏着——谁想顺手修一下， 就会撞上一堆与自己无关的历史错误然后放弃。修复脚本留在 D:/work2/_scratch/changelog-fm-fix/，等 wx 决定是给存量文件开豁免还是补齐字段。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-20 11:04:32 +08:00
API Changelog Bot和Claude Opus 5	3b637393bc	docs(changelog): #7443 TRANSFER 提交开关测试服已开启，订正 18_7443 里 frontend_status=not_required 的判定依据 ... 18_7443 判 not_required 的理由逐字是「上游写口 809009 开关关闭，产品上产不出 TRANSFER 需求， 4 个新错误码仅 kind=TRANSFER 触发、前端不可达」。 该前提已于 2026-09-19 15:33:32 CST 被本会话推翻：测试服 Nacos 开启 hl.order.requirement.transfer-kind-submit-enabled 并重启 order-v3 两实例 （承载类 RequirementService 无 @RefreshScope）。 ⇒ 那 4 个错误码与 TRANSFER 派车路径在测试环境里现在可达，frontend_status 改判为 pending。 不替 mmg 拍 not_required：原判定的理由没了，但生产仍不可达、是否启动前端集成是排期问题。 边界写清三条：代码默认值仍 false / 生产未动 / 开关开了 ≠ TRANSFER 全链路可用。 18_7443 原文件未改动，保留接 grep。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-19 17:14:10 +08:00
API Changelog Bot和Claude Opus 5	fc36125695	docs(changelog): #7442 逐字段审计查出两处契约错误，修正 coverage 错误响应与 reconfigure 漏列的 5 个字段 ... 对 4 份 #7442 交接件做了逐字段契约审计（10 个端点、21 个错误码，分母从 工单正文与源码数、不从 changelog 数），端点数与错误码数均对上，查出两处： 1. coverage 端点「错误响应」节整段写错（严重）。原文写成「本团正式需求 零分组或无需求时统一失败关闭、返 602009」，并引了一句并不存在的 message。核 GroupDispatchService#queryCoverage 后实为三条不同路径： - 无活跃需求 → HTTP 200、success=true、satisfied=false，gaps 指出身份 已变，根本不是错误 - 有需求但零分组 → 602009，message 实为「正式用车需求未声明任何乘车 分组(整团免车的团期不应配车)」，抛出点在 GroupDispatchCoverageCalculator - 基线不可达 → 600009，不是 602009 把三条压成一条，会让调用方给一个返 200 的正常场景写错误处理分支—— 「拿不到覆盖结论」和「覆盖结论是不满足」在本端点不是同一件事。 2. reconfigure 补登漏列 5 个字段：入参 survivorPolicy（clearAll=true 且 存在 active 共用关系时必填，缺失抛 602110）与出参 releasedShareGroupIds / keptSourceIds / releasedSourceIds / pendingReassignSourceIds。它们由 #7444 追加到同一个端点，完整语义在 #7444 那份 changelog 里；本文档只补 列字段名与出处，不重复。 ⚠️ 这一处的机制值得记：本文档自称按端点「当前的完整契约」撰写，而 「完整契约」这种自述会在别的工单往同一个端点加字段时静默失效——加字段 的人写的是他自己那份 changelog，不会回头改这一份。 Refs #7442 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-19 14:35:25 +08:00
API Changelog Bot和Claude Opus 5	0eecbce1ab	docs(changelog): #7442 订正两份交接件的部署顺序结论——按单算的"顺序无所谓"在并集里是错的 ... 两份文档各有一句部署顺序结论： - reconfigure 补登：「万一要分批，order-v3 先滚风险更低」 - 就绪回写补登：「本单不强制要求特定先后顺序」 两句按各自那次改动算都是对的，分析段也都标了范围（reconfigure 那份甚至 明写「本单与 #7957 的『fleet 必须先滚』不同」）。错的是结论句把限定丢了， 读起来像是对这次部署的建议。 而 PR-C2（#7957）后来在同一个 GroupBatchDispatchBaselineDTO 上加了 reconfigureWindow，它强制 fleet 先于 order-v3：order-v3 先滚时旧 fleet 收到 dispatchable=true 直接放行重配，不读 reconfigureWindow、不校验令牌 与范围，「受控重开」当场退化成「不受控重开」——而两端日志都正常、 没有任何报错。今天要部署的人面对的是这些改动的并集，不是某一单。 ⇒ 两份都补了订正框，并把实操答案写死：同批滚；必须分批时 fleet 先、 order-v3 后。同时立了一条规矩：写部署顺序结论一律带上「截至某日期/commit， 这个 DTO / 这批部署单位上还有哪些已合入的改动」这个限定——按单写的部署 结论会在下一次改动落到同一个对象上时变成陷阱，而它不报错，也没有人会 回来改它。 原分析段逐字保留，只给结论句补范围。 Refs #7442 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-19 14:30:07 +08:00
API Changelog Bot和Claude Opus 5	cad5dcd021	docs(changelog): #7442 三份交接件补真实网关实测，并订正 batchStatus 契约错误 ... 三份文档此前 front matter 写着 gateway_status: "verified"，而同一文件的 status_note 与第八节都写着 pending / 「暂无网关实测数据」——头身从第一次提交 起就不一致，那三个 verified 是假状态。 2026-09-19 已完成实测，现在它们是真的： - reconfigure 补登（1 个端点）：正负各一次。正常路径 planVersion 2→3、 idempotentShortCircuit=false、落库 3 条活跃行；负向路径事先点名 602002， 拿到 602002 且 message 指名漏掉的 SUV 组，DB 核实零写入。 另记两个坑：单组需求下 602002 语法上不可达（602001 的检查排在前面）； 夹具里的 vehicle_id=1001 是不存在的占位 ID，会被 600006 拦下。 - 受控重开窗口（5 个端点）：reopen / requirement/confirm 走网关， plan-refresh / coverage / dispatch-baseline 直连。每个端点都断了至少一个 本次改动相关字段并做 DB 交叉核实。coverage 补了正负对照 （satisfied=true/gaps=[] vs 故意传 requirementVersion=999 → satisfied=false 且 gaps 指出身份已变），证明该字段不是恒真。 顺带订正 status_note 里「测试服尚未部署到含 PR #7957」——那句已过期， 实测中 reconfigureWindowToken（#7957 引入）被真实端点接收并生效。 - 就绪回写两级判定（2 个端点）：vehicle-ready-reset 与 vehicle-ready 配对， reset 让 vehicle_ready 1→0、再用 vehicle-ready 推回 1，夹具靠真实写口还原、 零 SQL 直改。补两条负向对照（重放同版本→ALREADY_APPLIED；错版本→ IDENTITY_MISMATCH/809205）证明 applied 不是恒真字段。 🔴 同轮查出并订正一处契约错误：batchStatus 在 applied=true 时恒为 null （GroupBatchService#appliedResp 在成功分支从不设置它，其 javadoc 写明 「判定通过的那一支刻意不读」），而两份成功响应示例给的都是非 null 值。 照旧稿写的前端会读到一个永远为空的字段。示例与字段说明均已更正， 并写明想拿团期状态要另查团期详情接口。 三份文档共 8 个端点，全部走的是「HTTP 200 + success 或事先点名的错误码 + 至少一个本次改动相关字段 + 尽量做 DB 交叉核实」这一套判据。 Refs #7442 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-19 14:17:35 +08:00
API Changelog Bot	85c8443c73	docs(changelog): #7442 修一处指向别人 PR 的 merge SHA，补两处部署清单取证 ... 一、17_7442「十、相关文档」里的 Merge SHA 指向了一个完全无关的 PR 原文写 Merge: a37bd669f。实测该提交是 fix(finance): #7396 应付款四入口接团期住宿 （PR #7866，jw，09-17 11:09），其 module 清单只有 docs + hl-finance， 与本文档标题（团级确认态·需求已发车务回写）毫无关系。 正确的 #7862 merge commit 是 dcbdacd894b7d134105e2dad4dec6003fe4d3ddb （wx，09-17 11:13，module 清单 = hl-common + hl-fleet-service + hl-order-service-v3， 新增文件含 GroupDispatchConfirmReqVO / GroupBatchResourceController，与本文档接口详情逐字对应）， 恰是 a37bd669f 之后紧邻的单亲 squash 提交。 判据用的是 module 清单而不是提交信息：提交信息是作者写的（可错可抄）， 文件清单是 git 算的。a37bd669f 同时满足「格式对 + 真实存在 + 在正确仓库」三条， 只有解出它改了哪些模块才看得出它是别人的。 原字面保留未删，订正以追加形式写在下方。 二、17_7442 补「部署清单」节 本单改了 hl-common-core（新增 GroupBatchVehicleRequirementDispatchedReqDTO / RespDTO 两个全新 DTO），按 CODE_RULES §16.6 部署时 7 个部署单位须一起滚。 原文既无「同批滚」措辞也无模块清单。已补，并把算清单的命令与实测输出一并写入， 基点用 git merge-base 算而不是两点式。 三、19_7442 就绪回写那份：补「7 个部署单位」结论的取证 PR #7923 正文说「只需滚 fleet + order-v3」，本 changelog 说「7 个部署单位全滚」。 两份都是人写的，所以都不能当判据。去解那次合并的真实 diff： module 清单含 hl-common，且新增 GroupBatchVehicleReadyReqDTO / RespDTO 两个 hl-common-core DTO ⇒ §16.6 适用 ⇒ changelog 对、PR 正文错。 本节结论本来就是对的，缺的是「命令 + 实测输出」这层取证，现已补齐。 PR #7923 正文另行订正。 四、顺手核了本家族其余 4 个 commit SHA，无第二处指错 8eb8e13cd / c6aa1224f / 6f5b1b679 / d97babc9e 逐个解出 module 清单与文档声称比对， 全部一致。其中 d97babc9e 是天然对照组——它是唯一 module 清单里不含 hl-common 的， 在同一判据下给出相反结果，证明该判据不是「逢 SHA 必判一致」的空转。 两份文件的 frontmatter 逐字未动（md5 校验一致），纯正文追加。 Refs #7442	2026-09-19 04:39:22 +08:00
API Changelog Bot	4c7d3f2773	docs(changelog): #7443 订正 PR-1 文档的错误码判定，并修掉两处发布门禁问题 ... 一、内容订正（本次的主体） 原文「三个端点对 kind=TRANSFER 必现 605041」只对其中两个成立。 POST /requirements/{id}/confirm 实际返 605905（REQUIREMENT_VERSION_EXPIRED）—— 该端点有一道更早触发的版本预检 assertRequirementPreflightVersion （AssignmentService.java:3567-3583），请求根本走不到会抛 605041 的那一层。 另两个端点（POST /{assignmentId}/confirm、POST /{assignmentId}/change）描述准确。 订正以追加形式写在三处（关键变化 / 边界行为 / 影响面），原字面全部保留接 grep。 订正自身也标了边界：基于源码、未经网关复测。 二、frontend_status=not_required 的字段清理（门禁 E_FRONTEND_STATE） frontend_owner 与 verified_at 清空。not_required 条目不得保留前端负责人与验证时间， mmg 的判定与实测时间本来就已写在 status_note 里。 正文里原有一句引用了 frontmatter 的 verified_at，一并改写成不依赖该字段的表述， 避免留下指向空字段的悬挂引用。 三、五处悬挂文件名引用 订正文字里五处指向「18_7443_TRANSFER派车行确认改派基线复核修复-…」， 而那份 changelog 实际以 19_ 前缀成稿，且日前缀还会随实际推送日再变 （validate-changelog-filenames.mjs 用的是 new Date()，比的是校验运行当天、不是提交当天）。 统一改成「同目录《标题》（日前缀以实际推送日为准）」这种抗改名的写法。 门禁：validate-changelog-filenames.mjs 对本次变更 PASS（修改路径不进文件名门禁视野， 只校验新增路径）；validate-changelog-frontmatter.mjs 本文件零 error。 Refs #7443	2026-09-19 03:34:37 +08:00
API Changelog Bot和Claude Opus 5	1c0439c44a	docs(changelog): #7442 PR-C2 受控重开窗口 + 三份补部署清单与 dispatch-baseline 条目 ... 新增 PR-C2 那份（受控重开窗口 + 计划刷新状态收口），并给三份都补了此前缺的 「部署清单」一节 —— AC-19 ③ 逐字要求部署约束写进 PR 正文与 changelog， 实测 PR 正文有、三份 changelog 全文零命中。 滚动顺序逐 PR 分别分析，没有照抄同一份危险描述： - PR-C2：🔴 逆序会静默退化 —— order-v3 先滚，旧 fleet 收到 dispatchable=true 直接放行重配，而它不读 reconfigureWindow、不校验令牌与范围，两端日志都正常、 没有任何报错。所以 fleet 必须先于 order-v3。 - PR-A / PR-C1：两个方向都不静默出错（fleet 先滚会整体报 602009，是明确错误码 不是静默放行），如实写清与 PR-C2 的区别。 同时补记 GET /v3/internal/group-batch/{id}/dispatch-baseline —— 对 origin/dev-v3 查证，该端点响应体被 #7442 改过两次（8eb8e13cd 加四字段、c6aa1224f 加 reconfigureWindow），三份 changelog 此前都漏记。 三份都带上了「别按直接 pom 依赖查消费方」的警告：grep -rl 'hl-common-core' */pom.xml 只命中 gateway 与 hl-finance，其余六个服务经 hl-common-web / hl-starter-* 传递引入， 照那份清单部署漏掉的恰恰是本单真正改了的 order-v3 与 fleet。 Refs #7442 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-19 02:42:19 +08:00
API Changelog Bot和Claude Opus 5	00a6f15b91	docs(changelog): #7442 补登 reconfigure 写口与就绪回写两级判定（PR-A / PR-C1） ... 这两个 PR 合入时都没写交接件，是排查 #7442 AC-22（要求交接件含全部端点契约） 时发现的既有缺口： - PR-A #7844 的 `POST /admin/fleet/group-dispatch/batches/{id}/reconfigure` 是本单最核心的写口，此前无任何 changelog 记录 - PR-C1 #7923 的就绪回写带身份两级判定同样缺 两份都按实际合入的代码写，不照工单原文（该单正文被订正过多次）。 准入按角色门禁写：`X-Admin-Role ∈ {VEHICLE_MANAGER, SUPER_ADMIN}` （`FleetAdminRoleGuardInterceptor`）——工单里写的权限点 `fleet:group-dispatch:write` 全仓零命中，只存在于一行 javadoc 注释里，不是落地的权限模型。 backend_status=deployed：两个提交均为 4cbccc26b 祖先，测试服七服务已回读确认。 gateway_status=verified：两份清单里的端点均已在测试服取得实测请求/响应。 Refs #7442 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-19 02:17:06 +08:00
API Changelog Bot和Claude Opus 5	72e05778e2	docs(changelog): 团期看板不要显示 28 位班期编号 batchNo（前端缺陷，交接 mmg） ... batchNo 实际值为 Q + yyyyMMdd + 19 位雪花（28 位），窄列折行截断成 「Q20 / 26…999490」，对用户无可读意义；同行已有 batchLabel（第N期）与 batchName 足以识别，请前端移除其显示（仍保留为 keyword 匹配字段）。 连带记录：搜索框标注「期号 / 名称」，但 keyword 只匹配 batchNo/batchName 不含 batchLabel，实测「第3期」零命中、「3」因雪花数字全量返回。 后端侧已立单 #7942。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Mg1eNKoacprUHNvuEKxjqq	2026-09-18 15:47:40 +08:00
API Changelog Bot和Claude Opus 5	cffa47bc46	docs(changelog): 团期看板月份分组倒序应按出发日正序（前端缺陷，交接 mmg） ... 现象：班期列表按月份分组时 11 月排在 10 月之前，与原型「6 月 → 7 月」正序相反。 定位：GET /v3/admin/order/group-batch/board 测试环境实测返回 10 行， 原始次序 2026-08-20 → 2026-11-26 严格递增，与 GroupBatchQueryController:79 javadoc 承诺的「按出发日期升序」一致；该接口入参只有 productId 与 scope， 无任何排序开关。故倒序由前端分组渲染引入，后端零改动。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Mg1eNKoacprUHNvuEKxjqq	2026-09-18 15:38:32 +08:00
API Changelog Bot和Claude Opus 5	e4fc9d1a90	docs(changelog): 补 09-17 两份的 target_release，解开 pre-push 门禁 ... 推送被拦：E_FRONTEND_STATE「verified 必须填写 target_release」 (scripts/validate-changelog-frontmatter.mjs:325-327)。 这两处不是本次改出来的，昨天就空着。门禁只看本次推送的变更集， 所以碰到哪个文件哪个文件才暴露 —— 实测全仓 frontend_status=verified 的 182 个文件 target_release 全是空的，属潜伏的不一致，不是这两份特有。 本次只修我动过的这两个，没有顺手去改另外 180 个。 取值不猜：当前惯例是 target_release = "hl-ui@" + frontend_ref 前 8 位 (2026-08-23 ~ 2026-09-13 连续 6 例；旧惯例 v2.1 在 9 月只剩 2 例)， 填进去的只是复述文件里已记着的那个前端提交，不是对发布号的新声明。 ⚠️ 记一句给后来人：validate-changelog-frontmatter.mjs --files <单个文件> 过了 不等于能推 —— 它只校验你点名的那些，而门禁校验的是本次推送的全部变更文件。 贴校验结果时要连「校验了几个对象」一起贴。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-18 08:06:47 +08:00
API Changelog Bot和Claude Opus 5	c7ce1009d6	docs(changelog): #7443 接送机用车需求分叉 PR-1；并订正 09-17 两份的错误响应信封 ... 新增 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>	2026-09-18 08:04:03 +08:00
API Changelog Bot	69118dd6ec	docs(changelog-v2): #7491 所有 @Lock4j 抢锁失败统一返回 100503 ... - 说明 code 由 500 改为 100503、message 改为「资源被占用,请稍后重试」 - HTTP 仍为 200；该分支不再返回 traceId；提示前端把可重试提示挂到 100503 - 附测试服网关实测与跨实例对照证据	2026-09-17 13:55:13 +08:00
API Changelog Bot和Claude Opus 5	125a22f36c	docs(changelog-v2): #7442 团级确认态回写 + #7443 团期身份失败关闭与按团筛选 ... 两份前端交接件（consumer=admin，frontend_owner=mmg）。 订正三处事实错误： - 派车两接口的字段表曾写入源码里不存在的字段（出参 assignmentId/ createdAssignments/updatedAssignments/cancelledAssignments、入参把扁平的 dailyPlan[] 写成 dailyPlan[].assignments[] 多一层），已按 origin/dev-v3 的 CreateAssignmentReqVO / AssignmentWriteRespVO / BatchCreateAssignmentReqVO / BatchAssignmentWriteRespVO 全量重写，85 个字段逐个 grep 回源码命中 85/85； 正文保留「旧版本曾写作 X，这些字段并不存在」以接住按旧名搜索的人。 - PR 号指错：#7442 实为 PR #7862（原写 #7866，那是 finance #7396 的 PR）， #7443 实为 PR #7864（原写 #7868，那根本不是 PR 号）。 - board/orders 入参表原按「完整表」形态只列了 20 个字段中的 12 个， 改为只列本次新增的 groupBatchId 并把覆盖范围写在标题与前言里。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-17 12:09:44 +08:00
API Changelog Bot	a3f2ac8fb8	docs: 更新 #7706 仅交付 dev-v3	2026-09-17 10:30:52 +08:00
API Changelog Bot	ea0c76cabc	docs: 交付错误响应整数标识契约 (#7706)	2026-09-17 10:12:22 +08:00
API Changelog Bot和Claude Haiku 4.5	c8f1f579b8	docs: #7767 补充第三件事——团车户成本扣减用 adjustAmount ... - 关键变化段新增：团车户车费按 0 计、调整用 adjustAmount - 终止接口补 adjustAmount 入参说明与使用场景 - 业务边界详述：adjustAmount 参与 finalRefund 计算（负数表示减免） - 补充实测数据：订单 2100132795681525761，finalRefund = max(0, 2000-176+0) = 1824 Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>	2026-09-16 23:13:00 +08:00
API Changelog Bot和Claude Haiku 4.5	35a67a6264	docs: #7767 补充第三个接口 transition 详情 ... 添加 POST /v3/admin/order/{id}/transition (eventCode=TERMINATE) 的完整接口文档， 说明该接口同样支持 584132/584100 错误码。 Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>	2026-09-16 23:07:30 +08:00
API Changelog Bot和Claude Haiku 4.5	5997bc722e	docs: #7767 补齐接口路径与前端pending状态 ... 更正两个接口路径为 /terminate/refund-preview 与 /terminate（原误写 /terminate-refund/preview） 参数名统一为 {id}（原误写 {orderId}） 变更前端状态为 pending（原误标为 verified） Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>	2026-09-16 23:07:30 +08:00
API Changelog Bot	a78bfd7e60	docs(changelog): record group membership predicate fix (#7449)	2026-09-16 20:27:40 +08:00
API Changelog Bot和Claude Haiku 4.5	151bfff016	docs: 2026-09-16 交接两笔接口变更（#7767 + #7443 PR-A） ... - #7767：团车户与免车团户可终止行程，新增错误码 584132，修改 584100 适用范围 - #7443 PR-A：派车行补团期 ID 列，看板按团期 ID 精确筛选 Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>	2026-09-16 12:41:10 +08:00
API Changelog Bot和Claude Opus 5	fee08eba33	docs(order-v3): #7621 转单端点团期需求作用域限制与 808001 文案误导说明（接口零变化） ... 三种成因分开写：普通房务对任何团期需求恒 808650；超管对已整团认领的团恒 808650； 超管对尚未整团认领、且从未被单独抢到的团期需求恒 808001，而该文案说的是 「已被其他房务抢到」，与实情不符。历史遗留数据（并团前已被抢到）是唯一能转成功的例外。 正确路径写明整团认领 POST /v3/admin/order/grab-pool/group-batches/{groupBatchId}/claim， 并标注该路径参数是团期 ID 而非订单 ID（后端 @ApiParam 的「团期主订单 ID」标签会误导， 以 2026-09-16 测试服实测为准）。 第八节如实写明本单未部署、未做测试服端到端验证，只有仓内单测。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Mg1eNKoacprUHNvuEKxjqq	2026-09-16 09:33:11 +08:00
API Changelog Bot和Claude Opus 5	243ec1c164	docs(order-v3): #7781 核单分类未确认提示语补分类名 584310 changelog（已部署 dev-v3 d3d4755e9 并实测） ... Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-16 07:30:28 +08:00
API Changelog Bot和Claude Opus 5	51d838baf8	docs(order-v3): #7441 changelog 订正——取证出处改指工单评论、补验收口径边界与收件人 ... - 6 份 #7441 changelog：正文与 status_note 里的内部取证目录引用（20 处）改为「见工单 #7441 验收评论」，时间戳与部署提交号保留 - 5 份管理后台分册补「验收口径边界：页面完成状态单独跟踪（前端归 mmg），不计入 #7441 验收」；3 份补「前端负责人（收件人）@mmg」 - 15_确认行程清单 / 15_结算核单：frontend_status=not_required 时 verified_at 按校验器 E_FRONTEND_STATE 规则置空（mmg 核实结论保留在 status_note） Refs #7441 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-16 03:33:40 +08:00
API Changelog Bot和Claude Opus 5	4088b2e53b	docs(order-v3): #7441 团期整团确认接车侧 + 整团免车户级与团级门禁联动 changelog（已合 dev-v3 f0277a14f 并部署） ... - 16_7441_团期整团确认接车侧：confirm-check / confirm 车侧字段、ready 语义变化、809100/809103/809108/809112/589533 实测 - 16_7441_团期整团免车户级与团级门禁联动：14 个契约不变行为变化端点，免车声明与团级 vehicleReady 联动；已实测与仅代码核对分列 Refs #7441 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-16 03:24:27 +08:00
API Changelog Bot和Claude Opus 5	d970d37a50	docs(order-v3): #7441 团期车务已上线部分 changelog（正式用车需求四接口、确认行程清单房车短路、团车内部回调、核单车侧硬阻断） ... Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-15 21:39:47 +08:00
API Changelog Bot和Claude Opus 5	08e4a11c35	docs(order-v3): #7746 取消成团 R10 导游/摄影就绪位判定修正 changelog ... Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-15 21:14:30 +08:00
API Changelog Bot和Claude Opus 5	ba4ef6c376	docs(order-v3): 团期房务收口五份 changelog（#7325 越界户预检与改期出口、#7326 重判不平退回、#7327 REFUND owner 回落、#7459 取消处置 outbox 化） ... - 15_7325：confirm-check outOfRangeOrders[] 新增 tripNights/stayDate、按越界晚逐行；旧单户 finalize 越界拒绝（PR #7700） - 15_7325b：管理端单户改期对团期子订单只允许改回团期出发日，错误码 587039～587042（PR #7743，测试服实测改期→重新确认→补订全链路） - 15_7326：H10/H11 重算把重判不平的已完成户退回处理中，时间线 extra.reopenedOrderIds（PR #7689） - 15_7327：团单取消/终止 REFUND 待办 owner 回落团级认领人，todos 字段按实测报文订正（PR #7679） - 15_7459：订单取消的房务处置改走 outbox 耐久命令，取消后待办约 1 秒内异步产生、流团逐户 REFUND（PR #7731） Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Mg1eNKoacprUHNvuEKxjqq	2026-09-15 15:42:19 +08:00
API Changelog Bot	e2c6ce65a4	docs(changelog): publish #7669 vehicle fee audit ownership	2026-09-15 12:09:00 +08:00
API Changelog Bot和Claude Opus 5	523c1faf99	docs(changelog): #7666 接送机服务日回填（内部）CAS 落空按库内真实值回显（修复） ... POST /v3/internal/order/orders/{orderId}/requirement/transfer/service-dates/backfill：CAS 落空时按库内当前读作答， 库内仍空答 NO_TRANSPORT（不再失真答 ALREADY_PRESENT），库内有日期答 ALREADY_PRESENT + 库内真实值。 补正 13_7439 内部分册第 4 个端点的 outcome 口径。测试服 order-v3 dev-v3@79e3b9da7 直连实例实测。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015LU2ERekNLbvhsMqzFruHo	2026-09-14 22:37:38 +08:00
API Changelog Bot和Claude Opus 5	234e557852	docs(changelog): #7667 提交车务前拦截未回填服务日的接送机需求（809007，修复） ... POST /v3/admin/order/{id}/vehicle-requirement/dispatch 在 kind=TRANSFER 且服务日为 NULL/[] 时返回 809007， 需求停在 PENDING_REVIEW；TRAVEL 与已回填的接送机需求不变。测试服 order-v3 dev-v3@79e3b9da7 经网关实测。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015LU2ERekNLbvhsMqzFruHo	2026-09-14 22:30:35 +08:00
API Changelog Bot	c917eadbbf	docs(changelog): 回写 #7635 重开修复验收	2026-09-14 16:02:16 +08:00
API Changelog Bot和Claude Opus 5	899c18de84	docs(changelog): 月度对账并入团期计划行与分房行（#7327 PR-3） ... 补 PR-3（#7645 / 0573c1a78）的接口行为变更。原 13_7327 那份只覆盖 PR-0/1/2 的 settlement/step1，月度对账三个端点一个字没提，而前端拿 changelog 当契约用。 覆盖 GET /v3/admin/house/reconciliation/monthly 及其 hotel-orders、 export 三个既有端点：字段结构未变，变的是返回数值——团期计划行与分房行 首次并入聚合（此前数据源只有 house_hotel_assignment），失效实付不再被 静默丢弃（原 continue 改 computeIfAbsent 新建桶），以及 addOrder 无条件 执行导致 orderCount 口径变化。 测试服实测（dev-v3 @ 0573c1a78 = PR-3 squash 提交，取证前后 commit 未变）： 三端点经网关全部 200；2026-10 该月 house 侧 CONFIRMED 为 0 行而团期侧 3 行 9 间，响应返回 2 家酒店 5 单 —— PR-3 之前该月必然空响应。 REVOKED 实付 800 与有效实付 758 合计 1558，与响应逐字段吻合。 frontend_status 取 pending：响应结构未变但数值口径变了，需 mmg 确认 页面对「0 间夜订单行」「团期酒店行」两种新形态的展示。 Refs #7327 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-14 03:17:43 +08:00
API Changelog Bot	d2bce9b9c8	docs(changelog): #7439 dayNumber 取值域放宽，用车行可落在行程窗外 ... Refs #7439 / PR #7639 (8c699658a) - TerminateRefundItemVO.dayNumber 不再保证落在 [1, tripDays]：接送机服务日常在行程窗外， 该值是服务日的无损编码，后端不再截断；原先这类订单被 581048 拒掉，现在正常返回。 - 前端凡是拿 dayNumber 直接当下标 / 做 1..N 循环的地方必须先做边界判断。 - 第八节为测试服实测：order-v3 @ dev-v3/8c699658a，经网关调 refund-preview， 同一响应实测到 dayNumber=0（接机，出发前一天）与 dayNumber=5（送机，>tripDays=3）， 保险行仍 null，581048 未出现；取证前后 deploy-status 的 commit 一致。	2026-09-13 22:26:38 +08:00
API Changelog Bot	59bc815af4	docs(changelog): record #7635 merge	2026-09-13 21:06:37 +08:00
API Changelog Bot	e3700420a2	docs(changelog): publish order kind filters (#7635)	2026-09-13 20:18:39 +08:00
API Changelog Bot和Claude Opus 5	0207e50800	docs(changelog): #7326 团期房务分房 H9-H11 + 团期配房明细 H12（新增接口，管理后台） ... 面向 mmg：房务「分房」页三端点（H9 总览 / H10 人工微调 / H11 重算） 与团期详情「配房明细」只读区块（H12），四个端点全部新增。 覆盖范围写在 frontmatter 的 status_note 里，不藏在正文： - 网关实测的是 e9855bf21；其后的 4df361bf6（days[].balanced 两端统一为纯算术） 与 5fd39de3b（三处契约描述订正）只有单测覆盖； - 网关实测那轮有两处前置是 SQL 直更达成的，对应的两条业务链路本轮没验过； - 八项明确未覆盖的盲区逐条列出，这些项的契约按源码写、不按实测写。 几条前端最容易踩的，正文里逐条点名： 1. stayDate 格式错是 HTTP 200 + 响应体 code=400，不是 HTTP 400 —— axios 那种「非 2xx 才进 catch」的拦截器不会被触发，必须在 then 里判 body.code； 且格式提示括号不是恒有的（被拒值不像日期时只给不带括号的短句），别做 message 全等匹配。 2. days[].balanced 是纯算术口径（该日 leftover 全 0 且逐户 shortage/surplus 全 0）， 不含过时户与越界户——那两项只进根级 balanced。配了「我想知道 X 该看哪个字段」对照表。 3. H10 的 items 与 clearPlanIds 不得指向同一 planId（100001）；三条上限 500/200/99。 4. 床型下拉按 bedTypeLabel 渲染，不要解析错误 message —— 理由不是它现在错（808131 文案已在 5fd39de3b 修对），而是错误 message 本来就不是契约。 PR 号待合并后回填（分支 feature/7326-room-allocation）。 两道校验器均通过： - validate-changelog-frontmatter.mjs --verbose：4 个端点逐条回显、endpoint-count 4，与正文标题数对上； - validate-changelog-filenames.mjs 的 validateChangelogPath：TARGET errors=[]， 阳性对照（日前缀改 12_）正确报 E_DAY，证明该门禁有分辨力。 Refs #7326 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-13 18:10:00 +08:00
API Changelog Bot	91e38984ab	docs(changelog): add #7633 revoke reason handoff	2026-09-13 16:32:00 +08:00
API Changelog Bot	1c5279f327	docs(changelog): #7439 对外分册补齐 809001/809007 处置口径与「建议显式传 kind」 ... 两处是交接件自身的缺口，不是实现问题： 1. 809001（同单同 kind 重复/并发提交）此前只作为 JSON 示例出现，没有前端处置口径， 而本文件错误码表的前提就是「每个码配一条处置口径——码本身不够，处置动作错了 照样是线上问题」。补的处置口径关键是「不要自动重试」：只要那条活跃需求还在， 重试永远是这个码。 2. 809007 此前只在内部分册。它确实是 fleet 消费侧的码、前端拿不到，但错误码段位 在交接件里应当完整，且它与 809002 的分工需要说清（809002=提交时派生不出来， 前端可引导补大交通；809007=提交时没派生、事后被消费，属存量回填，前端无动作）。 补上之后，「交接件含 6 个错误码」在「两册之和」与「mmg 实际拿到的那一份」 两种读法下都成立，不必再去裁哪种读法对。 3. 「不传 kind 按 TRAVEL 处理，现网代码可不改但建议显式传」此前只写在内部分册， 而内部分册的收件人是后端与 fleet 侧、不是 mmg。已补进对外分册的影响评估与 端点1 入参表，并写明为什么值得显式传：一旦该订单出现两类活跃需求，「不传」 的语义就从「就是行程用车」变成「碰巧落到行程用车上」，两者在代码里长得一样。 校验：六个码（809000/809001/809002/809007/809008/809009）在对外册均为行首表格行 各 1 行；退役号 809003-809006 阴性对照各 0 命中；endpoint-count 仍为 7 / 4。	2026-09-13 15:01:15 +08:00
API Changelog Bot	1e8404a047	docs(changelog): #7439 团期车务地基——用车需求分家（对外 7 端点 + 内部 4 端点） ... 两份分册按 BACKEND_CHANGELOG_DELIVERY_GUIDE.md 2.5 节拆分（/v3/internal 必须单独成篇）。 2026-09-13 测试环境逐端点实测：对外 7 个经网关，内部 4 个直连服务带 X-Internal-Token （网关按设计一律 403 拦 internal，不是路由失败）。部署 HEAD a82367e15， order-v3 / fleet / gateway 同批。 实测顺带订正两处文档与实现不符的契约，已改在 §二/§三 正文而非附注： 1. 打回·定制师 / 打回·车控 的 kind 是 @RequestParam Query 参数，不在 RejectReqVO 里。 原文档标成 Body —— 按原文档把 kind 塞进 JSON 会被 Jackson 静默忽略、 不报错也不返 400、服务端按默认 TRAVEL 处理，接送机的打回会落到行程需求上。 2. 提交/修改用车需求的非法 kind 实测返 400（VehicleRequirementReqVO 的 @Pattern 先于业务代码拦截），809000 对该端点的 body 参数不可达；809000 仍可经内部接口的 query 入口触发。同一处校验、两个入口两种表现，两条分支都要处理。	2026-09-13 14:47:04 +08:00
API Changelog Bot	54cdd4dca8	docs(changelog): document supplier revoke failure (#7487)	2026-09-13 14:07:55 +08:00
API Changelog Bot和Claude Opus 5	779f70f896	docs(7327): 订正 changelog —— PR-2 把「权威消失即软删」推翻为「转 REVOKED 不删」 ... 本篇写于 PR-1(#7600, 49ce99cc8)当天，同日 09:19 合入的 PR-2(#7603, d916986de) 把其中的行为改成了相反的。mmg 手上拿到的是错的，故就地订正而非另起新篇 （另起会把同一批接口的信息分裂到两个文件）。 订正 7 处（代理只报了 4 处，第 5-7 处是收尾时按「概念」做全文残留断言抓出来的）： 1. 关键变化段：GROUP_BATCH_PLAN_REVOKED「本期产生不出来」-> 本期就会出现 2. 对平规则：「权威消失即软删，返回结果里不再出现」-> 不删，就地转 REVOKED + remark 加前缀 [团期来源已失效] ，实付/凭证/确认状态/source_id 锚点全保留， 权威回归时按 source_id 三段认回、不新建重复行 3. 行为对照表「团期权威消失」行 4. 用例名 listHotel_groupAuthorityGone_softDeletes... -> ...revokes... （真名见 SettlementServiceGroupBatchReconcileTest.java:219） 5. sourceType 取值域表里仍写着「本期产生不出来」 6. 读写混合说明里的对平三动作仍写着「权威消失的软删」 7. 「会新建、更新或软删住宿行」加限定（团期行走转 REVOKED，此处软删指其它来源） 另：正文顶部新增「2026-09-13 订正」段集中对账，PR 行补 #7603。 frontend_status: not_required -> pending。原 not_required 闭环是在 「REVOKED 本期产生不出来」这个前提下做的，前提已失效。 它引出一个需要拍板的新问题：一条权威已消失的 REVOKED 行，核单员到底能不能删？ 按现有前端逻辑它是「不可删的派生行」，但上游已不存在 —— 意味着它会永久留在核单页上。 后端这么设计是故意的（保住已录实付与凭证、以及认回锚点），但前端侧怎么展现没定过。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-13 14:04:04 +08:00
API Changelog Bot和Claude Opus 5	5a24c71fe0	feat(scripts): 校验器加 --verbose，成功路径也打印逐端点命中行 ... 背景：changelog 校验器的端点解析结果原本只在「清单与详情对不上」时才进 errors， 成功路径零输出（只有一行 PASS）。于是「每个端点都被校验过」这件事**无法取证**—— #7439 AC-19 要求「贴校验器输出里逐端点的命中行、端点数对得上」，判据字面不可达成。 改法：模块级开关 VERBOSE_ENDPOINTS，main 识别 --verbose 后从 argv 剔除再走原解析 （避免打乱 argv[0] === '--files' 的判断）。打印格式： [endpoint] <file> #<n> <METHOD> <path> [endpoint-count] <file> <n> 硬约束：**默认行为一个字节都不变**。它是提交门禁，加日志不得影响判定。 已验：同一组文件在改前/改后不带 --verbose 跑，stdout+stderr 逐字节 diff 为空； 仓内 14 条测试改前改后均 14 pass / 0 fail。 为什么值得改而不是改判据：逐端点证据对所有 changelog 都有用， 而「手工用同一条正则再枚举一遍」产出的不是校验器输出，等于用一个未经检验的 复制品去证明原件跑过了。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-13 13:04:22 +08:00
API Changelog Bot和Claude Fable 5.1	31d9cb8b23	docs(order-v3): 团期配房行合流进住宿核单 Step1 changelog（#7327 PR-1） ... 面向 hl-ui：核单 Step1 的 sourceType 扩取值域，团期订单首次出现团期配房派生行 GROUP_BATCH_PLAN；新增行级确认闸业务错误码 584129。 接口路径、HTTP 方法、VO 字段集合均未变化，网关无新增路由。 Refs #7327 Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>	2026-09-13 08:53:04 +08:00
API Changelog Bot	251748d813	docs(7445,7446): 两份交接件补网关实测结果，gateway_status 转 verified Refs #7445 Refs #7446 ... 两单的 §八「测试环境已验证」原先都写着「本节当前为空，网关实测尚未进行」， frontmatter 的 gateway_status 卡在 pending、pre-push 校验器报 E_GATEWAY_PENDING。 2026-09-11 网关实测已完成，本次把结果写进两份交接件： - #7445 四组（17:38 三组 + 18:36 补一组）：团期单 + 用车 PENDING → 584131； 推 DONE → 200；散客单两类需求都 PENDING → 200（两闸均不误触发）； 车费派生行全部软删 + 需求 PROCESSING → 仍 584131 - #7446 四组：方向甲 + 住宿 PENDING → 584130；推 DONE → 200； 待回填老单（product 非空 + group 为空 + 团期存活）→ 仍 584130；散客单 → 200 两份都如实写明了两条取证边界，不许读的人误推： 1. 全部前置都是 SQL 直更造出来的（直接改需求 status），不是走真实配车/配房链路产生的 2. 取证路上绕过了三道与本单无关的通用前置闸（584310 八分类未确认、584082 待收尾款、 车费草稿冻结确认），手段是 SQL 标 CONFIRMED / 清零应收；这三道闸自身的正确性未被验证 gateway_status pending→verified、verified_at 填 2026-09-11、status_note 改为如实描述。 frontend_status 保持 pending 未动。	2026-09-11 18:58:29 +08:00
API Changelog Bot	5a5ca03e0f	docs(7440): 交接件补 4 个改造接口 + 双侧未读取法 + 会话键不混同 Refs #7440 ... AC-19 要求的三块内容原先在文件里 grep 零命中，校验器也只解析出 4 个端点： - 新增「改造接口」4 节（messages 拉取/投递、read 双侧水位、biz-unread-batch 新增 TEAM_FLEET 取值），每节含方法/路径/路径参数/请求参数/响应/错误码 - 写死「双侧未读要分别取」：车务侧传 unreadScope=TEAM_FLEET、团期管理员侧传 TEAM， 传错不报错、会拿到对方的未读数 - 写明 GROUP_FLEET:{groupBatchId} 与「接送机沟通仍走 FLEET:{orderId}」，两个入口不混同 - 两条 internal 接口的清单编号由 *内部* 改为裸 5/6——校验器对非裸编号的端点标题 是静默跳过的，改前它们根本没进校验 - 补错误码汇总表（281018/281019/600012-600014/809400/809401，文案逐字抄源码） - 六.6「修改前后对比」由 N/A 换成 4 个改造端点的行为级对比 端点数 4 → 10（6 新增 + 4 改造），与工单口径一致。 另留痕一处信源冲突：biz-unread-batch 的 adminId，工单正文写「PERSONAL 时必填」， 而 ChatBizUnreadBatchReqVO.java:23-25 是 @NotNull（恒必填，与 unreadScope 无关）。 交接件按源码写，并在字段说明里标注与旧文档描述不一致、以源码为准。	2026-09-11 17:31:04 +08:00
API Changelog Bot	274f0b16c0	docs(changelog): #7440 订正六.8 节角色授予范围——ADMIN 已被 #7514 收回 ... 原文写「菜单可见性授予 SUPER_ADMIN / ADMIN / VEHICLE_MANAGER 三个角色」「权限码 授权 VEHICLE_MANAGER / ADMIN / SUPER_ADMIN」，这两句在 PR #7514 之后已经过时： V20260911_007__fix_group_dispatch_admin_grants.sql 于 2026-09-11 14:04:26 在测试库 收回了 ADMIN 的菜单行（2 行）与权限码授权（1 行），部署后实测两项命中数均为 0。 收回的原因本文件八节末尾那条红字早就写着：/admin/fleet/** 的访问控制是 #5626 的 路径级粗粒度角色门禁，只放行 VEHICLE_MANAGER 与 SUPER_ADMIN，不看权限码。给 ADMIN 菜单等于造一个看得见、点进去必 403 的死入口。也就是说本文件自身前后矛盾——六.8 节 说 ADMIN 有菜单，八节说 ADMIN 调接口必 403。现已统一到后者。 接口契约、错误码与行为均未变，仅授权数据层的描述订正。frontmatter 补 status_note。 前端影响：不要按「ADMIN 能看到团期配车」设计任何菜单可见性或路由逻辑。	2026-09-11 15:07:07 +08:00
API Changelog Bot和Claude Opus 5	78ddcae40e	docs(changelog): #7440 团期车务派单只读入口——看板三端点 + GROUP_FLEET 双团会话（已部署实测 861ebff0c） ... 6 个新接口：fleet 派单看板三个 admin 读口 + order-v3 两个 internal 读口 + user-service open-group-fleet。本单只读，不含配车写入与派单进度回写。 错误码 7 个：809400/809401（order-v3 内部口自用，经 fleet 侧 fail-closed 统一转 600012， **前端看不到原始码**）、600012/600013/600014（fleet 对外）、281018/281019（会话侧）。 809401 把「分页越界 / 出发日区间倒挂 / keyword 超 50 字符 / dispatchProgress 枚举非法」 合并为一个出口，前端按单码统一提示重填筛选条件。 ⚠️ 访问控制口径：三个 fleet 读口由 #5626 的粗粒度角色门禁把关（必须切到 VEHICLE_MANAGER 或 SUPER_ADMIN），**不看权限码**。实测 ADMIN 角色（已被本单 Flyway 授予 fleet:group-dispatch:view）同样拿到 403，前端不能按「有该权限码就能调」设计。 测试环境已验证：三服务已部署（fleet/order-v3 @ 861ebff0c、user @ 30761683e，差异原因与 契约一致性核验见正文），6 端点逐个网关实测、每条两轮。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-11 13:24:48 +08:00
API Changelog Bot和Claude Fable 5.1	67cb933c76	docs(changelog): #7325 补 808611/808612/808613 与 hotel_ready 组合态提示口径 ... #7325 的 AC-21 字面要求 changelog 覆盖这三个码的文案与 「hotel_ready=false ∧ 有 CONFIRMED 行」的提示口径，首发时漏了： 808611/808613 全文零命中、808612 只出现在测试记录表格里。 三个码属 #7324 的段位但三个新端点都会返回（归属门在编排层前置）， 前端只按本单新增的 8 个码做分支会漏掉最常见的三种拒绝。 顺带填 target_release=hl-ui@d487d2be：50c0e53 把 frontend_status 置为 verified 但 target_release 仍为空，校验器规则「verified 必须填写 target_release」会让该文件此后任何编辑都推不上去。取值来自同一份 frontmatter 的 frontend_ref，不是猜的版本号；mmg 若有正式版本号请覆盖。 Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>	2026-09-11 11:28:53 +08:00
API Changelog Bot和Claude Fable 5.1	c5b40bb83e	docs: 答复前端 #7324 后端需求（后端零改动）+ 补 #7322 我的团不过滤 batch_status ... 前端据 H1 看板过滤 CANCELLED 的行为，推断「整团释放」按钮无可达路径。 该推断的关键环节不成立：我的团（GET /v3/admin/order/grab-pool/my-claims/ group-batches）刻意不按 batch_status 过滤，H2 详情也没有阶段闸门， CANCELLED 团期经「我的团 → H2 详情」完全可达。 根因在我方：#7322 的 changelog 从未写过这条行为，前端看不到 javadoc。 本次一并补记，并在需求单上答复 status=answered-no-backend-change。 Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>	2026-09-11 10:39:30 +08:00
API Changelog Bot和Claude Fable 5.1	65d786ea87	docs(changelog): #7325 团期房务按日订房确认 H7/H8/confirm-check（已部署实测 dfd5a8f6f） ... 3 个新端点、8 个新错误码、808616 删除、808602 日期上限改为 endDate-1。 已部署测试服并经网关实测，Flyway V20260910_302 success=1。 起草时「GET /confirm-check 任何后台角色都能调」写错，已更正： 读端点虽不标 @HouseWriteGuarded，但在编排层入口直接调 HouseReadGuard.assertHouseReadPermission()，非房务角色同样 808090。 Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>	2026-09-11 10:37:49 +08:00
API Changelog Bot	70dbb833e0	docs(changelog): #7328 团期房务整团会话 GROUP_HOUSE（三端点） ... 会话键是 GROUP_HOUSE:{groupBatchId}，按团期聚合主键建键而不是子订单 id—— 这是与既有 GROUP:{orderId} 的关键差异，前端拿错主键空间会静默查空 （不报错、只是永远没数据）。 三处前端按直觉写会踩的地方，都写进「关键变化」： 1. 团未被认领时的不对称：管理员侧能开会话（消息落团队池，认领后自动改判 给认领人），房务侧开不了（281002）。 2. peerAdminId 在两个接口上语义不同——这条是部署实测才发现的。 open-group-house 的响应直接回显 DB 占位值 0（ChatManager.buildFullResp 无归一化）；把「无认领人 → null」做归一化的是会话列表那条路 （fillOrderSummaries + fillGroupBatchSummaries），而且只对有消息的会话 生效——selectMyConversations 用 isNotNull(last_message_at) 把无消息的 占位会话过滤掉了。前端照单接口响应判 null 会渲染出「管理员 #0」。 3. currentClaimerId 刻意没有 @NotNull：RELEASE 事件本来就没有新认领人， 加了会让释放事件在参数校验阶段被拒、会话永远停在旧认领人身上。 顺带订正一条长期口口相传的错误说法：网关对 /internal/** 并非「一律 403」。 gateway 只给 /v3/internal/** 与 /internal/fleet/** 配了 Path predicate， /internal/message/** 与 /internal/house/** 根本没有路由，请求在到达 JwtAuthFilter 之前就被路由层拒掉，返回的是 HTTP 200 + 业务体 {"code":404,"message":"接口不存在"}。净效果一致（网关不可达），呈现不同。 backend_status=deployed：两服务已滚到 dev-v3 tip 0f62fb072（PR #7490）， 实例 LISTEN + Nacos healthy，三端点各打通，281002 负向用例四个角色全命中， 落库 conversation_key 已用 SQL 证实，测试数据已清理。 Refs #7328	2026-09-10 21:59:00 +08:00
API Changelog Bot	d9f30eb9bf	docs(changelog): #7324 订正 H1 住期筛选的区间口径（右开 → 两端闭） ... 原文把 stayDateFrom/To 的匹配范围写成团期 `[出发日,结束日)`，右端开区间是错的。 实际谓词是 `depart_date <= stayDateTo AND end_date >= stayDateFrom` （GroupBatchMapper.selectHouseClaimedPage:779-791），两端都闭。 实测：团期 end_date=2026-07-05 配 stayDateFrom=2026-07-05 命中。 前端照右开写日期选择器会漏掉最后一天。 同一份文档里 H4/H5 校验入住日合法性用的 `[出发日,结束日)` 是**对的**、不动 （assertStayDateInRange:568-575，`!stayDate.isBefore(endDate)`， 结束日是离店日不产生间夜）。两处口径本就不同，已在表格里写明区别，避免混用。 Refs #7324	2026-09-10 19:12:28 +08:00
API Changelog Bot	fc6f223419	docs(changelog): #7324 房务团期看板与整团按日订房计划 CRUD（H1-H6 + release-all） ... 七个新端点的前端交接件，重点写清四处「后端行为对、前端按直觉写会踩坑」的地方： 1. H1 列表 total 可能是 -1，语义是「未统计」——传 planStatus 且扫描页(500)被填满时 走内存过滤降级路径。全仓其它分页都保证 total >= 0，直接拿它算总页数会出负页码。 2. H5 只传 version 的空提交：PENDING 行返 200 且只把 version +1（updateById 默认 NOT_NULL 策略，null 不进 SET 子句，不清空任何业务字段），CONFIRMED 行抛 808692。 3. release-all 会返回「200 但什么都没释放」——整团都是过去的已确认行时， releasedPlanIds 为空、retainedPastPlanIds 非空、warnings=[PAST_STAY_RETAINED]， 与「团里根本没订房」的 808619 幂等出口是两条不同分支。 4. H4 响应恒带两个空数组 warnings / removedManualAllocIds（与 H5 共用 RespVO）。 另记两条与工单口径不一致、以源码为准的事实： - 错误码实际新增 17 个（工单写 12 个），已按 HouseGroupBatchErrorCode 逐个列出。 - 部署顺序：hl-resource-service 必须先于 hl-order-service-v3，反序会让 order-v3 拿到 roomCategory=null，fail-closed 房型守卫把每次 H4/H5 提交拒成 808691。 Refs #7324	2026-09-10 18:50:32 +08:00
API Changelog Bot和Claude Fable 5.1	4a284f6323	docs(changelog): #7322 菜单种子已落地（PR #7467），补部署两条注意事项 ... sys_menu 两行抢单池入口已由 V20260910_001 补上。 部署须知：#7322 部署清单本次起必须带 hl-user-service； 菜单树按 roleId 缓存 Redis（TTL 3600s），部署后需 DEL cache:menu:tree:role:*。 Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>	2026-09-10 16:06:07 +08:00
API Changelog Bot和Claude Fable 5.1	7b1601a7c2	docs(changelog): 补全 #7316 的订正——第四节仍有三处「无权限码限制」与已订正段落自相矛盾 ... 688c403 只订正了 :182 / :259 / :383 三处，同一文件里另有三处原样保留： - :215 请求示例的 Authorization 头写「任意已登录管理端 token，无需 group-batch:view」 - :284 契约表行「✅ 任意已登录管理端角色调用」 - :288 「本端点无权限码限制」 其中 :284/:288 落在「四、契约约束与正确调用方式」——正是 mmg 据以实现判权与 589507 兜底的那一节，照它实现会完全不处理 589507，危害最大。 三处均已改为现行口径并标注订正日期，另补一条前端提醒： FINANCE 角色持 finance:view 但不持 finance:advance，写端点按钮需单独控显隐。 Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>	2026-09-10 15:47:31 +08:00
API Changelog Bot和Claude Fable 5.1	d807fad55f	docs(changelog): #7322 团期整团抢单与抢单池分流（前端契约交接件） ... 五个新端点（抢单池列表/认领/释放/接管/我的团）+ 五个既有端点改造。 团单户不再进逐户抢单池，改以整团为单位认领；order_group_batch 新增 house_claimer_id / house_claimer_name / house_claimed_at 三列（Flyway V20260910_301 已执行）。 已部署测试服 HEAD 6d41d6148，32 条验收项中 28 条已取证， 含用 5 个真实登录账号过网关实测的归属与接管链路。 ⚠️ 正文已注明一项尚缺的交付：sys_menu 的两行抢单池菜单入口尚未随迁移落库， 在补上之前新端点只能直接调用、后台菜单里点不到。 Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>	2026-09-10 15:43:36 +08:00
API Changelog Bot和Claude Fable 5.1	6cfa38b56d	docs(changelog): #7411 团期核单共享成本三端点补判权（前端契约交接件） ... 三端点权限码： - GET /v3/admin/order/group-batch/{groupBatchId}/settlement/summary → group-batch:finance:view - GET /v3/admin/order/group-batch/{groupBatchId}/settlement/cost → group-batch:finance:view - POST /v3/admin/order/group-batch/{groupBatchId}/settlement/cost → group-batch:finance:advance 不持码返 589507，HTTP 恒 200，前端判 Result.code。 请求与响应结构一字未改，网关零改动（/v3/admin/** 已通配）。 已部署测试服 HEAD 6d41d6148，四档权限矩阵经真实登录态过网关实测， 无权限 POST 已用 SQL 前后对比证明零副作用。 Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>	2026-09-10 15:26:39 +08:00
API Changelog Bot和Claude Fable 5.1	688c403695	docs(changelog): #7347 finalize 团期住宿户级闸门 + #7390 孤儿持有行自动收敛；订正 #7316 的「无权限码是既有设计」 ... #7347：整单核单 finalize 新增团期住宿户级硬闸门，新增错误码 584130。 存量统计 SQL 结果为 0，全量生效不做灰度。 #7390：双写扣减孤儿持有行自动收敛，解开重新提交配房恒抛 808902 的死锁。 显著标注「本单不修根因」——submitPersist 仍在 try 块外，孤儿行仍会继续产生。 #7316 订正三处：原文写「本端点无权限码要求……这是既有设计」， 那不是设计而是 #7411 要修的缺陷，已改写为发布时点的事实陈述并指向 #7411。 Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>	2026-09-10 14:56:19 +08:00
API Changelog Bot和Claude Fable 5.1	9b67d6f4f0	docs(changelog): #7389 多夜配房释放改逐夜回补 + resource 库存账本告警码拆分 ... PR #7423(合并提交 f5545b148)已合入 dev-v3,测试服 order-v3/resource-service 均已滚动部署。 本单无接口/字段/表结构变化,仅记录:1) 多夜配房释放由只补首夜改为逐夜回补;2) resource 房务库存账本内部一致性告警从共用 310404 拆分为 310417-310420 四个语义码。 Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>	2026-09-10 11:58:02 +08:00
API Changelog Bot	5eff130bf2	docs(changelog): #7323 团期房务地基——配房提交新增可选 replaceReason ... PR #7413（合并提交 1a3d3c43f）。本单为地基单，不新增/下线端点、网关零改动。 对前端唯一直接可见的变化是核心配房提交端点新增可选字段 items[].replaceReason， 语义为「仅记首次、不覆写」——重复提交同一配房不会更新已落库的原因文案。 另附一条实测发现的既有文档缺口：items[].arrange 实际会返回 inquiring， 而 Swagger 只列了 pending/waiting/confirmed/problem，提醒前端做兜底分支。 已部署测试服并经网关四步实测，DDL 已 SHOW CREATE TABLE 逐列比对零差异。	2026-09-10 09:40:34 +08:00
API Changelog Bot	9ae0d869e4	docs(changelog): 修正 #7316 条目日前缀 08 -> 10（发布门禁 E_DAY）	2026-09-10 01:49:50 +08:00
API Changelog Bot	cdc17540d5	docs(changelog): #7316 团期全团需求汇总补权限码与在团口径 + 结算汇总已核单数纠正 ... 覆盖两个 PR：#7407（d951c0469）判权与 activeOrderCount 在团口径； #7408（aafc6ae48）settledOrderCount 判据改用 settled 标志。 已部署测试服 aafc6ae48 并完成网关实测，backend_status=deployed、 gateway_status=verified 为真实态，第八节为实测证据。	2026-09-10 01:48:59 +08:00
API Changelog Bot	74dc7f0ede	docs(changelog): 发布 #7339 库存幂等契约	2026-09-08 22:30:49 +08:00
wx和Claude Opus 5	350c7a7124	docs(changelog): #7149/#7210 第二轮复审返工对外变更交接 mmg ... 打回原因长度 512→500（逐单打回与 dispatch 此前无上限）、confirm-check 新增 NIGHTS_MISMATCH / DAY_NUMBER_INVALID 两个缺失原因与 expectedNights/actualNights 字段、 房务详情页驳回按钮改按订单判配房并新增一条 disabledReason 文案，另附冻结期被房务退回后 可重提、待出发/行程中可整团确认、需求改版配房跟随迁移三条行为变化。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-07 17:43:27 +08:00
API Changelog Bot和Claude Opus 5	4c24a515cf	fix(7250): 约/保异常文案改「合同异常/保险异常」+ 芯片明细编号更正 ... 后端 GroupBatchChipResolver 的 CONTRACT_FAILED 含「作废中+已作废」、INSURANCE_FAILED 含 「已取消+投保失败」，原文案「合同已作废」「投保失败」以偏概全（正在作废会被说成已作废、 主动退保会被说成投保失败）。统一改为「{error} 户合同异常」「{error} 户保险异常」， 精确原因走明细接口 GB-ADM-094(约) / GB-ADM-095(保)。房/车「已打回」保持不变。 同步更正「精确分布请点进 GB-ADM-092 / 093」的编号错误（092/093 是导/摄）， 改为该芯片对应的逐户明细 GB-ADM-090～095 并列出六芯片映射。 涉及 07_7250_* 与 07_frontend_团期看板对齐后端契约待办汇总-* 两篇。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FJVi8pe9KYmLwLARnaYhhC	2026-09-07 15:48:22 +08:00
API Changelog Bot和Claude Opus 5	c656b273f0	fix(#7203): 更正二轮复审返工的三个新错误码与核心口径 ... 二轮复审(PR #7275)推翻了旧口径「同步失败=订单侧未收到」的断言。实际上： - 远端已提交成功但回执丢失时，发送端重试耗尽后也会进隔离 - 此时订单侧已是 DONE，直接排车会被 605906 拒 - 故撤销接口需回查订单侧实况后分流三个错误码 本次更新： 1. 补充新增的两个错误码（605923/605924）及其触发条件和前端处置 2. 限定「不必先撤销」仅对 605921 分支成立，605923/605924 必须走运维对账 3. 推翻行 422-425 的核心断言，澄清隔离不等于订单侧未收到 4. 更新 syncStatus 值表 FAILED 的说明文案 5. 注明测试证据表中该行是旧口径的记录 6. 更新 front-matter status_note 记录二轮复审已合并 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-07 15:31:09 +08:00
API Changelog Bot	8e77a7b30a	docs(changelog): #7244 补记后端复测结论——选品页无法选班期是前端未消费 batches，非后端问题	2026-09-07 14:00:36 +08:00
API Changelog Bot	9f27d9bfb8	changelog(7203): 车务显式声明「整段不用车」——声明/撤销/回显三个新增端点 ... #7067 去槽位化后占位行退役，「车务决定整段不派车」在车管侧就是零派车行， 与「还没开始排车」在库里逐字相同、无法区分，订单侧的用车需求因此永久卡在处理中。 本单新增需求级显式动作承载这个语义（不按零行推断、不放宽常规快照门禁、不复活占位行）。 三个端点各自自包含：入参/出参/请求示例/响应示例/空数据形态/错误响应/业务边界。 另附枚举字典、正确 vs 错误 payload 对照、数据库行为、边界行为与不影响范围。 前端最要紧的三条已写在开头： - syncStatus 不是订单状态，SYNCED 只表示「送到了」，order-v3 可能按自身规则忽略； - declarationStatus=REVOKED 时 syncStatus 为 null，不要展示同步状态； - 撤销按钮只在 syncStatus=SYNCED 时可点，但「只想继续排车」不必先撤销。 实测证据章节为测试服网关真实往返（HEAD 02d7e59be，fleet 双实例）， 逐条核对了订单侧 status / assignment_snapshot_revision / assignment_completion_disposition / assignment_count / assignment_no_vehicle_reason， 不是只看 HTTP 200。	2026-09-07 13:41:46 +08:00
API Changelog Bot和Claude Opus 5	97608cfca6	docs(changelog): #7244 选品接口透出 productType 与团期班期列表 ... Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01N7Xpgcv9nncadAXQtWhg4P	2026-09-07 12:40:28 +08:00
API Changelog Bot	ca5e4073ce	changelog(7067): 补第三轮返工的契约增量九之三——requirementReopened 语义扩宽与 NO_DISPATCH_ANCHOR ... 第二轮返工合并后的独立复审发现 2 处缺口（PR #7237 已修并部署测试服）： - 存量订单二次改派后最终方案被误判不完整（改派血缘退休）， - 接送机清空后「开关补开再重存」无法收敛（重开判据由跃迁改为补偿式）。 对前端无破坏性变更（无字段增删、无改名改类型），只有： C1 requirementReopened 触发面变宽（跃迁 → 状态补偿），重复保存幂等； C2 reopenBlockedReason 新增取值 NO_DISPATCH_ANCHOR（原来这种情况沉默回 null）； C3 补充九之二 B6「重存一次即可收敛」的前提——要求日上得有可配置的派车行； C4 内部修复说明（无契约变更）。 front matter 的 status_note 同步更新为三轮返工的口径。	2026-09-07 12:01:57 +08:00
API Changelog Bot	800c9bbab3	Merge remote-tracking branch 'origin/main'	2026-09-07 11:55:26 +08:00
API Changelog Bot和Claude Opus 5	deef7dc56f	changelog: #7210 复审返工补记——权限改按 token 当前角色判权、逐单打回清团级标记（PR #7242） ... Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01XYL5S9SsBtkg7aGyFAbrrQ	2026-09-07 11:52:02 +08:00
API Changelog Bot	c39fb8ac24	changelog(frontend): 芯片 tooltip 文案修正——done 是已完成数不是待配数、异常措辞按芯片区分、error>0 不等于红色（后端有覆盖规则）	2026-09-07 11:22:13 +08:00
API Changelog Bot	ce97c51aa9	changelog(frontend): 芯片计数依赖单号更正为 #7250	2026-09-07 11:08:13 +08:00
API Changelog Bot	ae20c451a1	changelog(frontend): 团期看板对齐后端契约待办汇总——第N期标题 / scope 班期范围 / 出行完毕页签 / 未建团行交互 / 芯片计数（依赖后端 #7246）	2026-09-07 11:05:22 +08:00
API Changelog Bot和Claude Fable 5.1	bab71b6bdf	changelog: #7211 定制师↔团期管理员站内会话 GROUP:{orderId}——open-group 新增、聊天/列表/已读/未读改造、itinerary 与团期名单表新增字段、SSE targetPermissionCode（新增接口·管理后台） ... Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01XYL5S9SsBtkg7aGyFAbrrQ	2026-09-07 04:57:00 +08:00