wx/hl-api-changelog
1
0
派生 0
代码 工单 合并请求 工作流 软件包 项目 发布 百科 活动
3,178 提交 29 分支 0 Git 标签
ec2426eda718135c71ece0ccfa49d28a8c659f63
提交图
5 次代码提交
作者 SHA1 备注 提交日期
API Changelog Bot 85c8443c73 docs(changelog): #7442 修一处指向别人 PR 的 merge SHA，补两处部署清单取证
changelog-filename-gate / validate (push) Failing after 1s
详情 
一、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和Claude Opus 5 e4fc9d1a90 docs(changelog): 补 09-17 两份的 target_release，解开 pre-push 门禁
changelog-filename-gate / validate (push) Failing after 2s
详情 
推送被拦：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
Mimingguang 3f72bf305a docs(changelog-v2): #7442 前端已交付,回写 verified+ref(b84a5d6b)
changelog-filename-gate / validate (push) Failing after 2s
详情
2026-09-17 15:29:15 +08:00
API Changelog Bot和Claude Opus 5 125a22f36c docs(changelog-v2): #7442 团级确认态回写 + #7443 团期身份失败关闭与按团筛选
changelog-filename-gate / validate (push) Failing after 2s
详情 
两份前端交接件（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