hl-api-changelog

3,133 提交 29 分支 0 Git 标签

3 次代码提交

包含重命名

作者	SHA1	备注	提交日期
Mimingguang	d9926ebb8f	docs(changelog): 19_7443 复核维持 not_required、#8218 判 not_required(前端直显后端 *Name) changelog-filename-gate / validate (push) Failing after 1s 详情	2026-09-24 17:28:26 +08:00
API Changelog Bot和Claude Opus 5	ae069b00a9	fix: frontmatter 未转义的引号让元数据对所有消费方隐形——修 19_7443 + 给校验器补语法层 changelog-filename-gate / validate (push) Failing after 1s 详情现象：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 的判定依据 changelog-filename-gate / validate (push) Failing after 2s 详情 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

作者

SHA1

备注

提交日期

Mimingguang

d9926ebb8f

docs(changelog): 19_7443 复核维持 not_required、#8218 判 not_required(前端直显后端 *Name)

changelog-filename-gate / validate (push) Failing after 1s

详情

2026-09-24 17:28:26 +08:00

API Changelog Bot和Claude Opus 5

ae069b00a9

fix: frontmatter 未转义的引号让元数据对所有消费方隐形——修 19_7443 + 给校验器补语法层

changelog-filename-gate / validate (push) Failing after 1s

详情

现象：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 的判定依据

changelog-filename-gate / validate (push) Failing after 2s

详情

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