3 次代码提交

包含重命名

作者	SHA1	备注	提交日期
API Changelog Bot和Claude Opus 5	047a4be4fd	feat(gate): 新增 E_WAIT_LANGUAGE——交接件正文禁「让前端等我们」的措辞 ... 2026-09-21 wx 第二次点名：「不要在changelog里写让前端等待部署 这不是你第一回犯错了 工作流是你部署完测试环境推送changelog」。 §2.1 的 backend_status 门禁挡得住预告式推送，挡不住这一类：20_7443 的 frontmatter 已经是 deployed、CI 全绿，但正文 status_note 结尾写着「该缺陷已在修……修好后另发 交接件」。mmg 因此一直没动工，隔天才来问「这个是有啥问题吗 还是没做到呢」——门禁 只看 frontmatter，看不见自由文本里的这句话，所以「deployed + 校验绿」并不代表这份 交接件可执行。消费方也没有能力消解这种不确定性：他查不了我们的部署状态、看不到 dev-v3、不知道「另发」是哪天，读到「等」就只能等，而且是静默地等。 - scripts/validate-changelog-frontmatter.mjs：新增 validateNoWaitLanguage，对所有 v2 文档逐行扫描（与 change_type 无关，前端条目同样适用）。三类措辞：部署状态对冲、 未来交付承诺、直接叫停对接；「等待」做共现判定而非裸词匹配，避免把「前端需轮询 等待支付回调」这类业务语义一起拦掉。前向引用（「以后续订正为准」「见后续订正」） 一并封住——它和「修好后另发」是同一件事换个说法，实测被绕过一次。 - tests：4 个用例，含 1 个阴性对照（灰度开关状态、已知缺口工单号、业务流程里的等待 必须放行），防止作者为了过门禁把该写的契约边界一起删掉。 - BACKEND_CHANGELOG_DELIVERY_GUIDE.md §2.1：写明规则、背景与那条分界线——这条影响 他「怎么写代码」，还是只影响他「什么时候开始写」？后者一律删。 阳性对照：对已推送的 HEAD 版 20_7443 跑新规则，命中 2 处（第 308、451 行「修好后另发」）， 即它能抓住真实发生过的那次。既有 changelog-path-aliases 测试对 11_7510 的 2 条 E_ALIAS_STATE 红是本次改动之前就存在的，与本提交无关，pre-push 钩子也不跑该用例。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-21 15:27:37 +08:00
lc	3d6f6245a0	补齐行政区划三级联动接口文档与模板门禁（#6422）	2026-08-26 16:23:19 +08:00
wx	6cbe22f40a	feat: track frontend changelog consumption (#5218)	2026-07-24 15:22:10 +08:00