API Changelog Bot和Claude Opus 5
779f70f896
changelog-filename-gate / validate (push) Failing after 2s
本篇写于 PR-1(#7600, 49ce99cc8)当天，同日 09:19 合入的 PR-2(#7603, d916986de) 把其中的行为改成了相反的。mmg 手上拿到的是错的，故就地订正而非另起新篇 （另起会把同一批接口的信息分裂到两个文件）。 订正 7 处（代理只报了 4 处，第 5-7 处是收尾时按「概念」做全文残留断言抓出来的）： 1. 关键变化段：GROUP_BATCH_PLAN_REVOKED「本期产生不出来」-> 本期就会出现 2. 对平规则：「权威消失即软删，返回结果里不再出现」-> 不删，就地转 REVOKED + remark 加前缀 [团期来源已失效] ，实付/凭证/确认状态/source_id 锚点全保留， 权威回归时按 source_id 三段认回、不新建重复行 3. 行为对照表「团期权威消失」行 4. 用例名 listHotel_groupAuthorityGone_softDeletes... -> ...revokes... （真名见 SettlementServiceGroupBatchReconcileTest.java:219） 5. sourceType 取值域表里仍写着「本期产生不出来」 6. 读写混合说明里的对平三动作仍写着「权威消失的软删」 7. 「会新建、更新或软删住宿行」加限定（团期行走转 REVOKED，此处软删指其它来源） 另：正文顶部新增「2026-09-13 订正」段集中对账，PR 行补 #7603。 frontend_status: not_required -> pending。原 not_required 闭环是在 「REVOKED 本期产生不出来」这个前提下做的，前提已失效。 它引出一个需要拍板的新问题：一条权威已消失的 REVOKED 行，核单员到底能不能删？ 按现有前端逻辑它是「不可删的派生行」，但上游已不存在 —— 意味着它会永久留在核单页上。 后端这么设计是故意的（保住已录实付与凭证、以及认回锚点），但前端侧怎么展现没定过。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>