wx/hl-api-changelog
1
0
派生 0
代码 工单 合并请求 工作流 软件包 项目 发布 百科 活动
3,125 提交 29 分支 0 Git 标签
10b46812d23a51304c00ee1537254b4a07c7265c
提交图
4 次代码提交
作者 SHA1 备注 提交日期
Mimingguang ac12dabe20 docs(changelog): #7443 C 车务侧+13_7439/18_7443/20_7990 前端已交付 verified(hl-admin v2.1 662310ea/6c091ef24)
changelog-filename-gate / validate (push) Failing after 2s
详情 
18_7443 挂起期回头补落地(派车弹窗 kind 切换+batch/pickup-dropoff-config 显式 kind);
20_7990 requirementIdentities 已消费;13_7439 硬契约点 A+B 已补(809008/显式 kind/reject 走 query);
20_7443 AC-24 维持 not_required 仅补 C 段实证
 2026-09-21 17:52:22 +08:00
API Changelog Bot 4c7d3f2773 docs(changelog): #7443 订正 PR-1 文档的错误码判定，并修掉两处发布门禁问题
changelog-filename-gate / validate (push) Failing after 2s
详情 
一、内容订正（本次的主体）
原文「三个端点对 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
Mimingguang 553aa99dd7 docs(changelog): #7443 接送机用车需求分叉 PR-1 前端判 not_required 回写 frontmatter
changelog-filename-gate / validate (push) Failing after 2s
详情
2026-09-18 08:13:01 +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