hl-api-changelog

2,949 提交 29 分支 0 Git 标签

3 次代码提交

包含重命名

作者	SHA1	备注	提交日期
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

作者

SHA1

备注

提交日期

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