wx/hl-api-changelog
1
0
派生 0
代码 工单 合并请求 工作流 软件包 项目 发布 百科 活动
2,897 提交 29 分支 0 Git 标签
ae069b00a9ffe5158f0c8102b208ca75ca3f766f
提交图
100 次代码提交
此分支
此分支
所有分支
作者 SHA1 备注 提交日期
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
API Changelog Bot和Claude Opus 5 fc36125695 docs(changelog): #7442 逐字段审计查出两处契约错误，修正 coverage 错误响应与 reconfigure 漏列的 5 个字段
changelog-filename-gate / validate (push) Failing after 2s
详情 
对 4 份 #7442 交接件做了逐字段契约审计（10 个端点、21 个错误码，分母从
工单正文与源码数、不从 changelog 数），端点数与错误码数均对上，查出两处：

1. coverage 端点「错误响应」节整段写错（严重）。原文写成「本团正式需求
   零分组或无需求时统一失败关闭、返 602009」，并引了一句并不存在的
   message。核 GroupDispatchService#queryCoverage 后实为三条不同路径：
   - 无活跃需求 → HTTP 200、success=true、satisfied=false，gaps 指出身份
     已变，根本不是错误
   - 有需求但零分组 → 602009，message 实为「正式用车需求未声明任何乘车
     分组(整团免车的团期不应配车)」，抛出点在 GroupDispatchCoverageCalculator
   - 基线不可达 → 600009，不是 602009
   把三条压成一条，会让调用方给一个返 200 的正常场景写错误处理分支——
   「拿不到覆盖结论」和「覆盖结论是不满足」在本端点不是同一件事。

2. reconfigure 补登漏列 5 个字段：入参 survivorPolicy（clearAll=true 且
   存在 active 共用关系时必填，缺失抛 602110）与出参 releasedShareGroupIds
   / keptSourceIds / releasedSourceIds / pendingReassignSourceIds。它们由
   #7444 追加到同一个端点，完整语义在 #7444 那份 changelog 里；本文档只补
   列字段名与出处，不重复。

   ⚠️ 这一处的机制值得记：本文档自称按端点「当前的完整契约」撰写，而
   「完整契约」这种自述会在别的工单往同一个端点加字段时静默失效——加字段
   的人写的是他自己那份 changelog，不会回头改这一份。

Refs #7442

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-09-19 14:35:25 +08:00
API Changelog Bot和Claude Opus 5 0eecbce1ab docs(changelog): #7442 订正两份交接件的部署顺序结论——按单算的"顺序无所谓"在并集里是错的
changelog-filename-gate / validate (push) Failing after 3s
详情 
两份文档各有一句部署顺序结论：
- reconfigure 补登：「万一要分批，order-v3 先滚风险更低」
- 就绪回写补登：「本单不强制要求特定先后顺序」

两句按各自那次改动算都是对的，分析段也都标了范围（reconfigure 那份甚至
明写「本单与 #7957 的『fleet 必须先滚』不同」）。错的是结论句把限定丢了，
读起来像是对这次部署的建议。

而 PR-C2（#7957）后来在同一个 GroupBatchDispatchBaselineDTO 上加了
reconfigureWindow，它强制 fleet 先于 order-v3：order-v3 先滚时旧 fleet
收到 dispatchable=true 直接放行重配，不读 reconfigureWindow、不校验令牌
与范围，「受控重开」当场退化成「不受控重开」——而两端日志都正常、
没有任何报错。今天要部署的人面对的是这些改动的并集，不是某一单。

⇒ 两份都补了订正框，并把实操答案写死：同批滚；必须分批时 fleet 先、
order-v3 后。同时立了一条规矩：写部署顺序结论一律带上「截至某日期/commit，
这个 DTO / 这批部署单位上还有哪些已合入的改动」这个限定——按单写的部署
结论会在下一次改动落到同一个对象上时变成陷阱，而它不报错，也没有人会
回来改它。

原分析段逐字保留，只给结论句补范围。

Refs #7442

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-09-19 14:30:07 +08:00
API Changelog Bot和Claude Opus 5 cad5dcd021 docs(changelog): #7442 三份交接件补真实网关实测，并订正 batchStatus 契约错误
changelog-filename-gate / validate (push) Failing after 2s
详情 
三份文档此前 front matter 写着 gateway_status: "verified"，而同一文件的
status_note 与第八节都写着 pending / 「暂无网关实测数据」——头身从第一次提交
起就不一致，那三个 verified 是假状态。

2026-09-19 已完成实测，现在它们是真的：

- reconfigure 补登（1 个端点）：正负各一次。正常路径 planVersion 2→3、
  idempotentShortCircuit=false、落库 3 条活跃行；负向路径事先点名 602002，
  拿到 602002 且 message 指名漏掉的 SUV 组，DB 核实零写入。
  另记两个坑：单组需求下 602002 语法上不可达（602001 的检查排在前面）；
  夹具里的 vehicle_id=1001 是不存在的占位 ID，会被 600006 拦下。

- 受控重开窗口（5 个端点）：reopen / requirement/confirm 走网关，
  plan-refresh / coverage / dispatch-baseline 直连。每个端点都断了至少一个
  本次改动相关字段并做 DB 交叉核实。coverage 补了正负对照
  （satisfied=true/gaps=[] vs 故意传 requirementVersion=999 → satisfied=false
  且 gaps 指出身份已变），证明该字段不是恒真。
  顺带订正 status_note 里「测试服尚未部署到含 PR #7957」——那句已过期，
  实测中 reconfigureWindowToken（#7957 引入）被真实端点接收并生效。

- 就绪回写两级判定（2 个端点）：vehicle-ready-reset 与 vehicle-ready 配对，
  reset 让 vehicle_ready 1→0、再用 vehicle-ready 推回 1，夹具靠真实写口还原、
  零 SQL 直改。补两条负向对照（重放同版本→ALREADY_APPLIED；错版本→
  IDENTITY_MISMATCH/809205）证明 applied 不是恒真字段。

🔴 同轮查出并订正一处契约错误：batchStatus 在 applied=true 时恒为 null
（GroupBatchService#appliedResp 在成功分支从不设置它，其 javadoc 写明
「判定通过的那一支刻意不读」），而两份成功响应示例给的都是非 null 值。
照旧稿写的前端会读到一个永远为空的字段。示例与字段说明均已更正，
并写明想拿团期状态要另查团期详情接口。

三份文档共 8 个端点，全部走的是「HTTP 200 + success 或事先点名的错误码 +
至少一个本次改动相关字段 + 尽量做 DB 交叉核实」这一套判据。

Refs #7442

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-09-19 14:17:35 +08:00
API Changelog Bot 85c8443c73 docs(changelog): #7442 修一处指向别人 PR 的 merge SHA，补两处部署清单取证
changelog-filename-gate / validate (push) Failing after 1s
详情 
一、17_7442「十、相关文档」里的 Merge SHA 指向了一个完全无关的 PR
原文写 Merge: a37bd669f。实测该提交是 fix(finance): #7396 应付款四入口接团期住宿
（PR #7866，jw，09-17 11:09），其 module 清单只有 docs + hl-finance，
与本文档标题（团级确认态·需求已发车务回写）毫无关系。
正确的 #7862 merge commit 是 dcbdacd894b7d134105e2dad4dec6003fe4d3ddb
（wx，09-17 11:13，module 清单 = hl-common + hl-fleet-service + hl-order-service-v3，
新增文件含 GroupDispatchConfirmReqVO / GroupBatchResourceController，与本文档接口详情逐字对应），
恰是 a37bd669f 之后紧邻的单亲 squash 提交。

判据用的是 module 清单而不是提交信息：提交信息是作者写的（可错可抄），
文件清单是 git 算的。a37bd669f 同时满足「格式对 + 真实存在 + 在正确仓库」三条，
只有解出它改了哪些模块才看得出它是别人的。

原字面保留未删，订正以追加形式写在下方。

二、17_7442 补「部署清单」节
本单改了 hl-common-core（新增 GroupBatchVehicleRequirementDispatchedReqDTO /
RespDTO 两个全新 DTO），按 CODE_RULES §16.6 部署时 7 个部署单位须一起滚。
原文既无「同批滚」措辞也无模块清单。已补，并把算清单的命令与实测输出一并写入，
基点用 git merge-base 算而不是两点式。

三、19_7442 就绪回写那份：补「7 个部署单位」结论的取证
PR #7923 正文说「只需滚 fleet + order-v3」，本 changelog 说「7 个部署单位全滚」。
两份都是人写的，所以都不能当判据。去解那次合并的真实 diff：
module 清单含 hl-common，且新增 GroupBatchVehicleReadyReqDTO / RespDTO 两个
hl-common-core DTO ⇒ §16.6 适用 ⇒ changelog 对、PR 正文错。
本节结论本来就是对的，缺的是「命令 + 实测输出」这层取证，现已补齐。
PR #7923 正文另行订正。

四、顺手核了本家族其余 4 个 commit SHA，无第二处指错
8eb8e13cd / c6aa1224f / 6f5b1b679 / d97babc9e 逐个解出 module 清单与文档声称比对，
全部一致。其中 d97babc9e 是天然对照组——它是唯一 module 清单里不含 hl-common 的，
在同一判据下给出相反结果，证明该判据不是「逢 SHA 必判一致」的空转。

两份文件的 frontmatter 逐字未动（md5 校验一致），纯正文追加。

Refs #7442
 2026-09-19 04:39: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
API Changelog Bot和Claude Opus 5 1c0439c44a docs(changelog): #7442 PR-C2 受控重开窗口 + 三份补部署清单与 dispatch-baseline 条目
changelog-filename-gate / validate (push) Failing after 2s
详情 
新增 PR-C2 那份（受控重开窗口 + 计划刷新状态收口），并给三份都补了此前缺的
「部署清单」一节 —— AC-19 ③ 逐字要求部署约束写进 PR 正文与 changelog，
实测 PR 正文有、三份 changelog 全文零命中。

滚动顺序逐 PR 分别分析，没有照抄同一份危险描述：
- PR-C2：🔴 逆序会静默退化 —— order-v3 先滚，旧 fleet 收到 dispatchable=true
  直接放行重配，而它不读 reconfigureWindow、不校验令牌与范围，两端日志都正常、
  没有任何报错。所以 fleet 必须先于 order-v3。
- PR-A / PR-C1：两个方向都不静默出错（fleet 先滚会整体报 602009，是明确错误码
  不是静默放行），如实写清与 PR-C2 的区别。

同时补记 GET /v3/internal/group-batch/{id}/dispatch-baseline —— 对 origin/dev-v3
查证，该端点响应体被 #7442 改过两次（8eb8e13cd 加四字段、c6aa1224f 加
reconfigureWindow），三份 changelog 此前都漏记。

三份都带上了「别按直接 pom 依赖查消费方」的警告：grep -rl 'hl-common-core' */pom.xml
只命中 gateway 与 hl-finance，其余六个服务经 hl-common-web / hl-starter-* 传递引入，
照那份清单部署漏掉的恰恰是本单真正改了的 order-v3 与 fleet。

Refs #7442

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-09-19 02:42:19 +08:00
API Changelog Bot和Claude Opus 5 00a6f15b91 docs(changelog): #7442 补登 reconfigure 写口与就绪回写两级判定（PR-A / PR-C1）
changelog-filename-gate / validate (push) Failing after 2s
详情 
这两个 PR 合入时都没写交接件，是排查 #7442 AC-22（要求交接件含全部端点契约）
时发现的既有缺口：
- PR-A #7844 的 `POST /admin/fleet/group-dispatch/batches/{id}/reconfigure`
  是本单最核心的写口，此前无任何 changelog 记录
- PR-C1 #7923 的就绪回写带身份两级判定同样缺

两份都按实际合入的代码写，不照工单原文（该单正文被订正过多次）。
准入按角色门禁写：`X-Admin-Role ∈ {VEHICLE_MANAGER, SUPER_ADMIN}`
（`FleetAdminRoleGuardInterceptor`）——工单里写的权限点 `fleet:group-dispatch:write`
全仓零命中，只存在于一行 javadoc 注释里，不是落地的权限模型。

backend_status=deployed：两个提交均为 4cbccc26b 祖先，测试服七服务已回读确认。
gateway_status=verified：两份清单里的端点均已在测试服取得实测请求/响应。

Refs #7442

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-09-19 02:17:06 +08:00
API Changelog Bot和Claude Opus 5 72e05778e2 docs(changelog): 团期看板不要显示 28 位班期编号 batchNo（前端缺陷，交接 mmg）
changelog-filename-gate / validate (push) Failing after 1s
详情 
batchNo 实际值为 Q + yyyyMMdd + 19 位雪花（28 位），窄列折行截断成
「Q20 / 26…999490」，对用户无可读意义；同行已有 batchLabel（第N期）与
batchName 足以识别，请前端移除其显示（仍保留为 keyword 匹配字段）。

连带记录：搜索框标注「期号 / 名称」，但 keyword 只匹配 batchNo/batchName
不含 batchLabel，实测「第3期」零命中、「3」因雪花数字全量返回。
后端侧已立单 #7942。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Mg1eNKoacprUHNvuEKxjqq
 2026-09-18 15:47:40 +08:00
API Changelog Bot和Claude Opus 5 cffa47bc46 docs(changelog): 团期看板月份分组倒序应按出发日正序（前端缺陷，交接 mmg）
changelog-filename-gate / validate (push) Failing after 2s
详情 
现象：班期列表按月份分组时 11 月排在 10 月之前，与原型「6 月 → 7 月」正序相反。

定位：GET /v3/admin/order/group-batch/board 测试环境实测返回 10 行，
原始次序 2026-08-20 → 2026-11-26 严格递增，与 GroupBatchQueryController:79
javadoc 承诺的「按出发日期升序」一致；该接口入参只有 productId 与 scope，
无任何排序开关。故倒序由前端分组渲染引入，后端零改动。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Mg1eNKoacprUHNvuEKxjqq
 2026-09-18 15:38:32 +08:00
API Changelog Bot和Claude Opus 5 e4fc9d1a90 docs(changelog): 补 09-17 两份的 target_release，解开 pre-push 门禁
changelog-filename-gate / validate (push) Failing after 2s
详情 
推送被拦：E_FRONTEND_STATE「verified 必须填写 target_release」
(scripts/validate-changelog-frontmatter.mjs:325-327)。

这两处不是本次改出来的，昨天就空着。门禁只看本次推送的变更集，
所以碰到哪个文件哪个文件才暴露 —— 实测全仓 frontend_status=verified 的
182 个文件 target_release 全是空的，属潜伏的不一致，不是这两份特有。
本次只修我动过的这两个，没有顺手去改另外 180 个。

取值不猜：当前惯例是 target_release = "hl-ui@" + frontend_ref 前 8 位
(2026-08-23 ~ 2026-09-13 连续 6 例；旧惯例 v2.1 在 9 月只剩 2 例)，
填进去的只是复述文件里已记着的那个前端提交，不是对发布号的新声明。

⚠️ 记一句给后来人：validate-changelog-frontmatter.mjs --files <单个文件> 过了
不等于能推 —— 它只校验你点名的那些，而门禁校验的是本次推送的全部变更文件。
贴校验结果时要连「校验了几个对象」一起贴。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-09-18 08:06:47 +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
API Changelog Bot 69118dd6ec docs(changelog-v2): #7491 所有 @Lock4j 抢锁失败统一返回 100503
changelog-filename-gate / validate (push) Failing after 2s
详情 
- 说明 code 由 500 改为 100503、message 改为「资源被占用,请稍后重试」
- HTTP 仍为 200；该分支不再返回 traceId；提示前端把可重试提示挂到 100503
- 附测试服网关实测与跨实例对照证据
 2026-09-17 13:55:13 +08:00
API Changelog Bot和Claude Opus 5 125a22f36c docs(changelog-v2): #7442 团级确认态回写 + #7443 团期身份失败关闭与按团筛选
changelog-filename-gate / validate (push) Failing after 2s
详情 
两份前端交接件（consumer=admin，frontend_owner=mmg）。

订正三处事实错误：
- 派车两接口的字段表曾写入源码里不存在的字段（出参 assignmentId/
  createdAssignments/updatedAssignments/cancelledAssignments、入参把扁平的
  dailyPlan[] 写成 dailyPlan[].assignments[] 多一层），已按 origin/dev-v3 的
  CreateAssignmentReqVO / AssignmentWriteRespVO / BatchCreateAssignmentReqVO /
  BatchAssignmentWriteRespVO 全量重写，85 个字段逐个 grep 回源码命中 85/85；
  正文保留「旧版本曾写作 X，这些字段并不存在」以接住按旧名搜索的人。
- PR 号指错：#7442 实为 PR #7862（原写 #7866，那是 finance #7396 的 PR），
  #7443 实为 PR #7864（原写 #7868，那根本不是 PR 号）。
- board/orders 入参表原按「完整表」形态只列了 20 个字段中的 12 个，
  改为只列本次新增的 groupBatchId 并把覆盖范围写在标题与前言里。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-09-17 12:09:44 +08:00
API Changelog Bot a3f2ac8fb8 docs: 更新 #7706 仅交付 dev-v3
changelog-filename-gate / validate (push) Failing after 2s
详情
2026-09-17 10:30:52 +08:00
API Changelog Bot ea0c76cabc docs: 交付错误响应整数标识契约 (#7706)
changelog-filename-gate / validate (push) Failing after 1s
详情
2026-09-17 10:12:22 +08:00
API Changelog Bot和Claude Haiku 4.5 c8f1f579b8 docs: #7767 补充第三件事——团车户成本扣减用 adjustAmount
changelog-filename-gate / validate (push) Failing after 1s
详情 
- 关键变化段新增：团车户车费按 0 计、调整用 adjustAmount
- 终止接口补 adjustAmount 入参说明与使用场景
- 业务边界详述：adjustAmount 参与 finalRefund 计算（负数表示减免）
- 补充实测数据：订单 2100132795681525761，finalRefund = max(0, 2000-176+0) = 1824

Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
 2026-09-16 23:13:00 +08:00
API Changelog Bot和Claude Haiku 4.5 35a67a6264 docs: #7767 补充第三个接口 transition 详情
changelog-filename-gate / validate (push) Failing after 2s
详情 
添加 POST /v3/admin/order/{id}/transition (eventCode=TERMINATE) 的完整接口文档，
说明该接口同样支持 584132/584100 错误码。

Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
 2026-09-16 23:07:30 +08:00
API Changelog Bot和Claude Haiku 4.5 5997bc722e docs: #7767 补齐接口路径与前端pending状态 
更正两个接口路径为 /terminate/refund-preview 与 /terminate（原误写 /terminate-refund/preview）
参数名统一为 {id}（原误写 {orderId}）
变更前端状态为 pending（原误标为 verified）

Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
 2026-09-16 23:07:30 +08:00
API Changelog Bot a78bfd7e60 docs(changelog): record group membership predicate fix (#7449)
changelog-filename-gate / validate (push) Failing after 2s
详情
2026-09-16 20:27:40 +08:00
API Changelog Bot和Claude Haiku 4.5 151bfff016 docs: 2026-09-16 交接两笔接口变更（#7767 + #7443 PR-A）
changelog-filename-gate / validate (push) Failing after 1s
详情 
- #7767：团车户与免车团户可终止行程，新增错误码 584132，修改 584100 适用范围
- #7443 PR-A：派车行补团期 ID 列，看板按团期 ID 精确筛选

Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
 2026-09-16 12:41:10 +08:00
API Changelog Bot和Claude Opus 5 fee08eba33 docs(order-v3): #7621 转单端点团期需求作用域限制与 808001 文案误导说明（接口零变化）
changelog-filename-gate / validate (push) Failing after 1s
详情 
三种成因分开写：普通房务对任何团期需求恒 808650；超管对已整团认领的团恒 808650；
超管对尚未整团认领、且从未被单独抢到的团期需求恒 808001，而该文案说的是
「已被其他房务抢到」，与实情不符。历史遗留数据（并团前已被抢到）是唯一能转成功的例外。

正确路径写明整团认领 POST /v3/admin/order/grab-pool/group-batches/{groupBatchId}/claim，
并标注该路径参数是团期 ID 而非订单 ID（后端 @ApiParam 的「团期主订单 ID」标签会误导，
以 2026-09-16 测试服实测为准）。

第八节如实写明本单未部署、未做测试服端到端验证，只有仓内单测。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Mg1eNKoacprUHNvuEKxjqq
 2026-09-16 09:33:11 +08:00
API Changelog Bot和Claude Opus 5 243ec1c164 docs(order-v3): #7781 核单分类未确认提示语补分类名 584310 changelog（已部署 dev-v3 d3d4755e9 并实测）
changelog-filename-gate / validate (push) Failing after 1s
详情 
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-09-16 07:30:28 +08:00
API Changelog Bot和Claude Opus 5 51d838baf8 docs(order-v3): #7441 changelog 订正——取证出处改指工单评论、补验收口径边界与收件人
changelog-filename-gate / validate (push) Failing after 1s
详情 
- 6 份 #7441 changelog：正文与 status_note 里的内部取证目录引用（20 处）改为「见工单 #7441 验收评论」，时间戳与部署提交号保留
- 5 份管理后台分册补「验收口径边界：页面完成状态单独跟踪（前端归 mmg），不计入 #7441 验收」；3 份补「前端负责人（收件人）@mmg」
- 15_确认行程清单 / 15_结算核单：frontend_status=not_required 时 verified_at 按校验器 E_FRONTEND_STATE 规则置空（mmg 核实结论保留在 status_note）

Refs #7441

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-09-16 03:33:40 +08:00
API Changelog Bot和Claude Opus 5 4088b2e53b docs(order-v3): #7441 团期整团确认接车侧 + 整团免车户级与团级门禁联动 changelog（已合 dev-v3 f0277a14f 并部署）
changelog-filename-gate / validate (push) Failing after 2s
详情 
- 16_7441_团期整团确认接车侧：confirm-check / confirm 车侧字段、ready 语义变化、809100/809103/809108/809112/589533 实测
- 16_7441_团期整团免车户级与团级门禁联动：14 个契约不变行为变化端点，免车声明与团级 vehicleReady 联动；已实测与仅代码核对分列

Refs #7441

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-09-16 03:24:27 +08:00
API Changelog Bot和Claude Opus 5 d970d37a50 docs(order-v3): #7441 团期车务已上线部分 changelog（正式用车需求四接口、确认行程清单房车短路、团车内部回调、核单车侧硬阻断）
changelog-filename-gate / validate (push) Failing after 1s
详情 
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-09-15 21:39:47 +08:00
API Changelog Bot和Claude Opus 5 08e4a11c35 docs(order-v3): #7746 取消成团 R10 导游/摄影就绪位判定修正 changelog
changelog-filename-gate / validate (push) Failing after 2s
详情 
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-09-15 21:14:30 +08:00
API Changelog Bot和Claude Opus 5 ba4ef6c376 docs(order-v3): 团期房务收口五份 changelog（#7325 越界户预检与改期出口、#7326 重判不平退回、#7327 REFUND owner 回落、#7459 取消处置 outbox 化）
changelog-filename-gate / validate (push) Failing after 1s
详情 
- 15_7325：confirm-check outOfRangeOrders[] 新增 tripNights/stayDate、按越界晚逐行；旧单户 finalize 越界拒绝（PR #7700）
- 15_7325b：管理端单户改期对团期子订单只允许改回团期出发日，错误码 587039～587042（PR #7743，测试服实测改期→重新确认→补订全链路）
- 15_7326：H10/H11 重算把重判不平的已完成户退回处理中，时间线 extra.reopenedOrderIds（PR #7689）
- 15_7327：团单取消/终止 REFUND 待办 owner 回落团级认领人，todos 字段按实测报文订正（PR #7679）
- 15_7459：订单取消的房务处置改走 outbox 耐久命令，取消后待办约 1 秒内异步产生、流团逐户 REFUND（PR #7731）

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Mg1eNKoacprUHNvuEKxjqq
 2026-09-15 15:42:19 +08:00
API Changelog Bot e2c6ce65a4 docs(changelog): publish #7669 vehicle fee audit ownership
changelog-filename-gate / validate (push) Failing after 2s
详情
2026-09-15 12:09:00 +08:00
API Changelog Bot和Claude Opus 5 523c1faf99 docs(changelog): #7666 接送机服务日回填（内部）CAS 落空按库内真实值回显（修复）
changelog-filename-gate / validate (push) Failing after 2s
详情 
POST /v3/internal/order/orders/{orderId}/requirement/transfer/service-dates/backfill：CAS 落空时按库内当前读作答，
库内仍空答 NO_TRANSPORT（不再失真答 ALREADY_PRESENT），库内有日期答 ALREADY_PRESENT + 库内真实值。
补正 13_7439 内部分册第 4 个端点的 outcome 口径。测试服 order-v3 dev-v3@79e3b9da7 直连实例实测。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015LU2ERekNLbvhsMqzFruHo
 2026-09-14 22:37:38 +08:00
API Changelog Bot和Claude Opus 5 234e557852 docs(changelog): #7667 提交车务前拦截未回填服务日的接送机需求（809007，修复）
changelog-filename-gate / validate (push) Failing after 2s
详情 
POST /v3/admin/order/{id}/vehicle-requirement/dispatch 在 kind=TRANSFER 且服务日为 NULL/[] 时返回 809007，
需求停在 PENDING_REVIEW；TRAVEL 与已回填的接送机需求不变。测试服 order-v3 dev-v3@79e3b9da7 经网关实测。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015LU2ERekNLbvhsMqzFruHo
 2026-09-14 22:30:35 +08:00
API Changelog Bot c917eadbbf docs(changelog): 回写 #7635 重开修复验收
changelog-filename-gate / validate (push) Failing after 2s
详情
2026-09-14 16:02:16 +08:00
API Changelog Bot和Claude Opus 5 899c18de84 docs(changelog): 月度对账并入团期计划行与分房行（#7327 PR-3）
changelog-filename-gate / validate (push) Failing after 3s
详情 
补 PR-3（#7645 / 0573c1a78）的接口行为变更。原 13_7327 那份只覆盖
PR-0/1/2 的 settlement/step1，月度对账三个端点一个字没提，而前端拿
changelog 当契约用。

覆盖 GET /v3/admin/house/reconciliation/monthly 及其 hotel-orders、
export 三个既有端点：字段结构未变，变的是返回数值——团期计划行与分房行
首次并入聚合（此前数据源只有 house_hotel_assignment），失效实付不再被
静默丢弃（原 continue 改 computeIfAbsent 新建桶），以及 addOrder 无条件
执行导致 orderCount 口径变化。

测试服实测（dev-v3 @ 0573c1a78 = PR-3 squash 提交，取证前后 commit 未变）：
三端点经网关全部 200；2026-10 该月 house 侧 CONFIRMED 为 0 行而团期侧
3 行 9 间，响应返回 2 家酒店 5 单 —— PR-3 之前该月必然空响应。
REVOKED 实付 800 与有效实付 758 合计 1558，与响应逐字段吻合。

frontend_status 取 pending：响应结构未变但数值口径变了，需 mmg 确认
页面对「0 间夜订单行」「团期酒店行」两种新形态的展示。

Refs #7327

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-09-14 03:17:43 +08:00
API Changelog Bot d2bce9b9c8 docs(changelog): #7439 dayNumber 取值域放宽，用车行可落在行程窗外
changelog-filename-gate / validate (push) Failing after 2s
详情 
Refs #7439 / PR #7639 (8c699658a)

- TerminateRefundItemVO.dayNumber 不再保证落在 [1, tripDays]：接送机服务日常在行程窗外，
  该值是服务日的无损编码，后端不再截断；原先这类订单被 581048 拒掉，现在正常返回。
- 前端凡是拿 dayNumber 直接当下标 / 做 1..N 循环的地方必须先做边界判断。
- 第八节为测试服实测：order-v3 @ dev-v3/8c699658a，经网关调 refund-preview，
  同一响应实测到 dayNumber=0（接机，出发前一天）与 dayNumber=5（送机，>tripDays=3），
  保险行仍 null，581048 未出现；取证前后 deploy-status 的 commit 一致。
 2026-09-13 22:26:38 +08:00
API Changelog Bot 59bc815af4 docs(changelog): record #7635 merge
changelog-filename-gate / validate (push) Failing after 2s
详情
2026-09-13 21:06:37 +08:00
API Changelog Bot e3700420a2 docs(changelog): publish order kind filters (#7635)
changelog-filename-gate / validate (push) Failing after 2s
详情
2026-09-13 20:18:39 +08:00
API Changelog Bot和Claude Opus 5 0207e50800 docs(changelog): #7326 团期房务分房 H9-H11 + 团期配房明细 H12（新增接口，管理后台）
changelog-filename-gate / validate (push) Failing after 2s
详情 
面向 mmg：房务「分房」页三端点（H9 总览 / H10 人工微调 / H11 重算）
与团期详情「配房明细」只读区块（H12），四个端点全部新增。

覆盖范围写在 frontmatter 的 status_note 里，不藏在正文：
- 网关实测的是 e9855bf21；其后的 4df361bf6（days[].balanced 两端统一为纯算术）
  与 5fd39de3b（三处契约描述订正）只有单测覆盖；
- 网关实测那轮有两处前置是 SQL 直更达成的，对应的两条业务链路本轮没验过；
- 八项明确未覆盖的盲区逐条列出，这些项的契约按源码写、不按实测写。

几条前端最容易踩的，正文里逐条点名：
1. stayDate 格式错是 HTTP 200 + 响应体 code=400，不是 HTTP 400
   —— axios 那种「非 2xx 才进 catch」的拦截器不会被触发，必须在 then 里判 body.code；
   且格式提示括号不是恒有的（被拒值不像日期时只给不带括号的短句），别做 message 全等匹配。
2. days[].balanced 是纯算术口径（该日 leftover 全 0 且逐户 shortage/surplus 全 0），
   不含过时户与越界户——那两项只进根级 balanced。配了「我想知道 X 该看哪个字段」对照表。
3. H10 的 items 与 clearPlanIds 不得指向同一 planId（100001）；三条上限 500/200/99。
4. 床型下拉按 bedTypeLabel 渲染，不要解析错误 message
   —— 理由不是它现在错（808131 文案已在 5fd39de3b 修对），而是错误 message 本来就不是契约。

PR 号待合并后回填（分支 feature/7326-room-allocation）。

两道校验器均通过：
- validate-changelog-frontmatter.mjs --verbose：4 个端点逐条回显、endpoint-count 4，与正文标题数对上；
- validate-changelog-filenames.mjs 的 validateChangelogPath：TARGET errors=[]，
  阳性对照（日前缀改 12_）正确报 E_DAY，证明该门禁有分辨力。

Refs #7326

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-09-13 18:10:00 +08:00
API Changelog Bot 91e38984ab docs(changelog): add #7633 revoke reason handoff
changelog-filename-gate / validate (push) Failing after 1s
详情
2026-09-13 16:32:00 +08:00
API Changelog Bot 1c5279f327 docs(changelog): #7439 对外分册补齐 809001/809007 处置口径与「建议显式传 kind」
changelog-filename-gate / validate (push) Failing after 2s
详情 
两处是交接件自身的缺口，不是实现问题：

1. 809001（同单同 kind 重复/并发提交）此前只作为 JSON 示例出现，没有前端处置口径，
   而本文件错误码表的前提就是「每个码配一条处置口径——码本身不够，处置动作错了
   照样是线上问题」。补的处置口径关键是「不要自动重试」：只要那条活跃需求还在，
   重试永远是这个码。
2. 809007 此前只在内部分册。它确实是 fleet 消费侧的码、前端拿不到，但错误码段位
   在交接件里应当完整，且它与 809002 的分工需要说清（809002=提交时派生不出来，
   前端可引导补大交通；809007=提交时没派生、事后被消费，属存量回填，前端无动作）。
   补上之后，「交接件含 6 个错误码」在「两册之和」与「mmg 实际拿到的那一份」
   两种读法下都成立，不必再去裁哪种读法对。
3. 「不传 kind 按 TRAVEL 处理，现网代码可不改但建议显式传」此前只写在内部分册，
   而内部分册的收件人是后端与 fleet 侧、不是 mmg。已补进对外分册的影响评估与
   端点1 入参表，并写明为什么值得显式传：一旦该订单出现两类活跃需求，「不传」
   的语义就从「就是行程用车」变成「碰巧落到行程用车上」，两者在代码里长得一样。

校验：六个码（809000/809001/809002/809007/809008/809009）在对外册均为行首表格行
各 1 行；退役号 809003-809006 阴性对照各 0 命中；endpoint-count 仍为 7 / 4。
 2026-09-13 15:01:15 +08:00
API Changelog Bot 1e8404a047 docs(changelog): #7439 团期车务地基——用车需求分家（对外 7 端点 + 内部 4 端点）
changelog-filename-gate / validate (push) Failing after 1s
详情 
两份分册按 BACKEND_CHANGELOG_DELIVERY_GUIDE.md 2.5 节拆分（/v3/internal 必须单独成篇）。
2026-09-13 测试环境逐端点实测：对外 7 个经网关，内部 4 个直连服务带 X-Internal-Token
（网关按设计一律 403 拦 internal，不是路由失败）。部署 HEAD a82367e15，
order-v3 / fleet / gateway 同批。

实测顺带订正两处文档与实现不符的契约，已改在 §二/§三 正文而非附注：
1. 打回·定制师 / 打回·车控 的 kind 是 @RequestParam Query 参数，不在 RejectReqVO 里。
   原文档标成 Body —— 按原文档把 kind 塞进 JSON 会被 Jackson 静默忽略、
   不报错也不返 400、服务端按默认 TRAVEL 处理，接送机的打回会落到行程需求上。
2. 提交/修改用车需求的非法 kind 实测返 400（VehicleRequirementReqVO 的 @Pattern
   先于业务代码拦截），809000 对该端点的 body 参数不可达；809000 仍可经内部接口的
   query 入口触发。同一处校验、两个入口两种表现，两条分支都要处理。
 2026-09-13 14:47:04 +08:00
API Changelog Bot 54cdd4dca8 docs(changelog): document supplier revoke failure (#7487)
changelog-filename-gate / validate (push) Failing after 2s
详情
2026-09-13 14:07:55 +08:00
API Changelog Bot和Claude Opus 5 779f70f896 docs(7327): 订正 changelog —— PR-2 把「权威消失即软删」推翻为「转 REVOKED 不删」
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>
 2026-09-13 14:04:04 +08:00
API Changelog Bot和Claude Opus 5 5a24c71fe0 feat(scripts): 校验器加 --verbose，成功路径也打印逐端点命中行
changelog-filename-gate / validate (push) Failing after 2s
详情 
背景：changelog 校验器的端点解析结果原本只在「清单与详情对不上」时才进 errors，
成功路径零输出（只有一行 PASS）。于是「每个端点都被校验过」这件事**无法取证**——
#7439 AC-19 要求「贴校验器输出里逐端点的命中行、端点数对得上」，判据字面不可达成。

改法：模块级开关 VERBOSE_ENDPOINTS，main 识别 --verbose 后从 argv 剔除再走原解析
（避免打乱 argv[0] === '--files' 的判断）。打印格式：

  [endpoint] <file> #<n> <METHOD> <path>
  [endpoint-count] <file> <n>

硬约束：**默认行为一个字节都不变**。它是提交门禁，加日志不得影响判定。
已验：同一组文件在改前/改后不带 --verbose 跑，stdout+stderr 逐字节 diff 为空；
仓内 14 条测试改前改后均 14 pass / 0 fail。

为什么值得改而不是改判据：逐端点证据对所有 changelog 都有用，
而「手工用同一条正则再枚举一遍」产出的不是校验器输出，等于用一个未经检验的
复制品去证明原件跑过了。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-09-13 13:04:22 +08:00
API Changelog Bot和Claude Fable 5.1 31d9cb8b23 docs(order-v3): 团期配房行合流进住宿核单 Step1 changelog（#7327 PR-1）
changelog-filename-gate / validate (push) Successful in 2s
详情 
面向 hl-ui：核单 Step1 的 sourceType 扩取值域，团期订单首次出现团期配房派生行
GROUP_BATCH_PLAN；新增行级确认闸业务错误码 584129。
接口路径、HTTP 方法、VO 字段集合均未变化，网关无新增路由。

Refs #7327

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
 2026-09-13 08:53:04 +08:00
API Changelog Bot 251748d813 docs(7445,7446): 两份交接件补网关实测结果，gateway_status 转 verified Refs #7445 Refs #7446
changelog-filename-gate / validate (push) Successful in 2s
详情 
两单的 §八「测试环境已验证」原先都写着「本节当前为空，网关实测尚未进行」，
frontmatter 的 gateway_status 卡在 pending、pre-push 校验器报 E_GATEWAY_PENDING。

2026-09-11 网关实测已完成，本次把结果写进两份交接件：

- #7445 四组（17:38 三组 + 18:36 补一组）：团期单 + 用车 PENDING → 584131；
  推 DONE → 200；散客单两类需求都 PENDING → 200（两闸均不误触发）；
  车费派生行全部软删 + 需求 PROCESSING → 仍 584131
- #7446 四组：方向甲 + 住宿 PENDING → 584130；推 DONE → 200；
  待回填老单（product 非空 + group 为空 + 团期存活）→ 仍 584130；散客单 → 200

两份都如实写明了两条取证边界，不许读的人误推：

1. 全部前置都是 SQL 直更造出来的（直接改需求 status），不是走真实配车/配房链路产生的
2. 取证路上绕过了三道与本单无关的通用前置闸（584310 八分类未确认、584082 待收尾款、
   车费草稿冻结确认），手段是 SQL 标 CONFIRMED / 清零应收；这三道闸自身的正确性未被验证

gateway_status pending→verified、verified_at 填 2026-09-11、status_note 改为如实描述。
frontend_status 保持 pending 未动。
 2026-09-11 18:58:29 +08:00
API Changelog Bot 5a5ca03e0f docs(7440): 交接件补 4 个改造接口 + 双侧未读取法 + 会话键不混同 Refs #7440
changelog-filename-gate / validate (push) Successful in 3s
详情 
AC-19 要求的三块内容原先在文件里 grep 零命中，校验器也只解析出 4 个端点：

- 新增「改造接口」4 节（messages 拉取/投递、read 双侧水位、biz-unread-batch
  新增 TEAM_FLEET 取值），每节含方法/路径/路径参数/请求参数/响应/错误码
- 写死「双侧未读要分别取」：车务侧传 unreadScope=TEAM_FLEET、团期管理员侧传 TEAM，
  传错不报错、会拿到对方的未读数
- 写明 GROUP_FLEET:{groupBatchId} 与「接送机沟通仍走 FLEET:{orderId}」，两个入口不混同
- 两条 internal 接口的清单编号由 *内部* 改为裸 5/6——校验器对非裸编号的端点标题
  是静默跳过的，改前它们根本没进校验
- 补错误码汇总表（281018/281019/600012-600014/809400/809401，文案逐字抄源码）
- 六.6「修改前后对比」由 N/A 换成 4 个改造端点的行为级对比

端点数 4 → 10（6 新增 + 4 改造），与工单口径一致。

另留痕一处信源冲突：biz-unread-batch 的 adminId，工单正文写「PERSONAL 时必填」，
而 ChatBizUnreadBatchReqVO.java:23-25 是 @NotNull（恒必填，与 unreadScope 无关）。
交接件按源码写，并在字段说明里标注与旧文档描述不一致、以源码为准。
 2026-09-11 17:31:04 +08:00
API Changelog Bot 274f0b16c0 docs(changelog): #7440 订正六.8 节角色授予范围——ADMIN 已被 #7514 收回
changelog-filename-gate / validate (push) Successful in 3s
详情 
原文写「菜单可见性授予 SUPER_ADMIN / ADMIN / VEHICLE_MANAGER 三个角色」「权限码
授权 VEHICLE_MANAGER / ADMIN / SUPER_ADMIN」，这两句在 PR #7514 之后已经过时：
V20260911_007__fix_group_dispatch_admin_grants.sql 于 2026-09-11 14:04:26 在测试库
收回了 ADMIN 的菜单行（2 行）与权限码授权（1 行），部署后实测两项命中数均为 0。

收回的原因本文件八节末尾那条红字早就写着：/admin/fleet/** 的访问控制是 #5626 的
路径级粗粒度角色门禁，只放行 VEHICLE_MANAGER 与 SUPER_ADMIN，不看权限码。给 ADMIN
菜单等于造一个看得见、点进去必 403 的死入口。也就是说本文件自身前后矛盾——六.8 节
说 ADMIN 有菜单，八节说 ADMIN 调接口必 403。现已统一到后者。

接口契约、错误码与行为均未变，仅授权数据层的描述订正。frontmatter 补 status_note。

前端影响：不要按「ADMIN 能看到团期配车」设计任何菜单可见性或路由逻辑。
 2026-09-11 15:07:07 +08:00
API Changelog Bot和Claude Opus 5 78ddcae40e docs(changelog): #7440 团期车务派单只读入口——看板三端点 + GROUP_FLEET 双团会话（已部署实测 861ebff0c）
changelog-filename-gate / validate (push) Successful in 3s
详情 
6 个新接口：fleet 派单看板三个 admin 读口 + order-v3 两个 internal 读口 + user-service
open-group-fleet。本单只读，不含配车写入与派单进度回写。

错误码 7 个：809400/809401（order-v3 内部口自用，经 fleet 侧 fail-closed 统一转 600012，
**前端看不到原始码**）、600012/600013/600014（fleet 对外）、281018/281019（会话侧）。
809401 把「分页越界 / 出发日区间倒挂 / keyword 超 50 字符 / dispatchProgress 枚举非法」
合并为一个出口，前端按单码统一提示重填筛选条件。

⚠️ 访问控制口径：三个 fleet 读口由 #5626 的粗粒度角色门禁把关（必须切到 VEHICLE_MANAGER
或 SUPER_ADMIN），**不看权限码**。实测 ADMIN 角色（已被本单 Flyway 授予
fleet:group-dispatch:view）同样拿到 403，前端不能按「有该权限码就能调」设计。

测试环境已验证：三服务已部署（fleet/order-v3 @ 861ebff0c、user @ 30761683e，差异原因与
契约一致性核验见正文），6 端点逐个网关实测、每条两轮。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-09-11 13:24:48 +08:00
API Changelog Bot和Claude Fable 5.1 67cb933c76 docs(changelog): #7325 补 808611/808612/808613 与 hotel_ready 组合态提示口径
changelog-filename-gate / validate (push) Successful in 3s
详情 
#7325 的 AC-21 字面要求 changelog 覆盖这三个码的文案与
「hotel_ready=false ∧ 有 CONFIRMED 行」的提示口径，首发时漏了：
808611/808613 全文零命中、808612 只出现在测试记录表格里。

三个码属 #7324 的段位但三个新端点都会返回（归属门在编排层前置），
前端只按本单新增的 8 个码做分支会漏掉最常见的三种拒绝。

顺带填 target_release=hl-ui@d487d2be：50c0e53 把 frontend_status 置为
verified 但 target_release 仍为空，校验器规则「verified 必须填写
target_release」会让该文件此后任何编辑都推不上去。取值来自同一份
frontmatter 的 frontend_ref，不是猜的版本号；mmg 若有正式版本号请覆盖。

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
 2026-09-11 11:28:53 +08:00
API Changelog Bot和Claude Fable 5.1 c5b40bb83e docs: 答复前端 #7324 后端需求（后端零改动）+ 补 #7322 我的团不过滤 batch_status
changelog-filename-gate / validate (push) Successful in 2s
详情 
前端据 H1 看板过滤 CANCELLED 的行为，推断「整团释放」按钮无可达路径。
该推断的关键环节不成立：我的团（GET /v3/admin/order/grab-pool/my-claims/
group-batches）刻意不按 batch_status 过滤，H2 详情也没有阶段闸门，
CANCELLED 团期经「我的团 → H2 详情」完全可达。

根因在我方：#7322 的 changelog 从未写过这条行为，前端看不到 javadoc。
本次一并补记，并在需求单上答复 status=answered-no-backend-change。

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
 2026-09-11 10:39:30 +08:00
API Changelog Bot和Claude Fable 5.1 65d786ea87 docs(changelog): #7325 团期房务按日订房确认 H7/H8/confirm-check（已部署实测 dfd5a8f6f） 
3 个新端点、8 个新错误码、808616 删除、808602 日期上限改为 endDate-1。
已部署测试服并经网关实测，Flyway V20260910_302 success=1。

起草时「GET /confirm-check 任何后台角色都能调」写错，已更正：
读端点虽不标 @HouseWriteGuarded，但在编排层入口直接调
HouseReadGuard.assertHouseReadPermission()，非房务角色同样 808090。

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
 2026-09-11 10:37:49 +08:00
API Changelog Bot 70dbb833e0 docs(changelog): #7328 团期房务整团会话 GROUP_HOUSE（三端点）
changelog-filename-gate / validate (push) Successful in 2s
详情 
会话键是 GROUP_HOUSE:{groupBatchId}，按团期聚合主键建键而不是子订单 id——
这是与既有 GROUP:{orderId} 的关键差异，前端拿错主键空间会静默查空
（不报错、只是永远没数据）。

三处前端按直觉写会踩的地方，都写进「关键变化」：

1. 团未被认领时的不对称：管理员侧能开会话（消息落团队池，认领后自动改判
   给认领人），房务侧开不了（281002）。

2. peerAdminId 在两个接口上语义不同——这条是部署实测才发现的。
   open-group-house 的响应直接回显 DB 占位值 0（ChatManager.buildFullResp
   无归一化）；把「无认领人 → null」做归一化的是会话列表那条路
   （fillOrderSummaries + fillGroupBatchSummaries），而且只对有消息的会话
   生效——selectMyConversations 用 isNotNull(last_message_at) 把无消息的
   占位会话过滤掉了。前端照单接口响应判 null 会渲染出「管理员 #0」。

3. currentClaimerId 刻意没有 @NotNull：RELEASE 事件本来就没有新认领人，
   加了会让释放事件在参数校验阶段被拒、会话永远停在旧认领人身上。

顺带订正一条长期口口相传的错误说法：网关对 /internal/** 并非「一律 403」。
gateway 只给 /v3/internal/** 与 /internal/fleet/** 配了 Path predicate，
/internal/message/** 与 /internal/house/** 根本没有路由，请求在到达
JwtAuthFilter 之前就被路由层拒掉，返回的是 HTTP 200 + 业务体
{"code":404,"message":"接口不存在"}。净效果一致（网关不可达），呈现不同。

backend_status=deployed：两服务已滚到 dev-v3 tip 0f62fb072（PR #7490），
实例 LISTEN + Nacos healthy，三端点各打通，281002 负向用例四个角色全命中，
落库 conversation_key 已用 SQL 证实，测试数据已清理。

Refs #7328
 2026-09-10 21:59:00 +08:00
API Changelog Bot d9f30eb9bf docs(changelog): #7324 订正 H1 住期筛选的区间口径（右开 → 两端闭）
changelog-filename-gate / validate (push) Successful in 3s
详情 
原文把 stayDateFrom/To 的匹配范围写成团期 `[出发日,结束日)`，右端开区间是错的。
实际谓词是 `depart_date <= stayDateTo AND end_date >= stayDateFrom`
（GroupBatchMapper.selectHouseClaimedPage:779-791），两端都闭。
实测：团期 end_date=2026-07-05 配 stayDateFrom=2026-07-05 命中。
前端照右开写日期选择器会漏掉最后一天。

同一份文档里 H4/H5 校验入住日合法性用的 `[出发日,结束日)` 是**对的**、不动
（assertStayDateInRange:568-575，`!stayDate.isBefore(endDate)`，
结束日是离店日不产生间夜）。两处口径本就不同，已在表格里写明区别，避免混用。

Refs #7324
 2026-09-10 19:12:28 +08:00
API Changelog Bot fc6f223419 docs(changelog): #7324 房务团期看板与整团按日订房计划 CRUD（H1-H6 + release-all）
changelog-filename-gate / validate (push) Successful in 2s
详情 
七个新端点的前端交接件，重点写清四处「后端行为对、前端按直觉写会踩坑」的地方：

1. H1 列表 total 可能是 -1，语义是「未统计」——传 planStatus 且扫描页(500)被填满时
   走内存过滤降级路径。全仓其它分页都保证 total >= 0，直接拿它算总页数会出负页码。
2. H5 只传 version 的空提交：PENDING 行返 200 且只把 version +1（updateById 默认
   NOT_NULL 策略，null 不进 SET 子句，不清空任何业务字段），CONFIRMED 行抛 808692。
3. release-all 会返回「200 但什么都没释放」——整团都是过去的已确认行时，
   releasedPlanIds 为空、retainedPastPlanIds 非空、warnings=[PAST_STAY_RETAINED]，
   与「团里根本没订房」的 808619 幂等出口是两条不同分支。
4. H4 响应恒带两个空数组 warnings / removedManualAllocIds（与 H5 共用 RespVO）。

另记两条与工单口径不一致、以源码为准的事实：
- 错误码实际新增 17 个（工单写 12 个），已按 HouseGroupBatchErrorCode 逐个列出。
- 部署顺序：hl-resource-service 必须先于 hl-order-service-v3，反序会让 order-v3 拿到
  roomCategory=null，fail-closed 房型守卫把每次 H4/H5 提交拒成 808691。

Refs #7324
 2026-09-10 18:50:32 +08:00
API Changelog Bot和Claude Fable 5.1 4a284f6323 docs(changelog): #7322 菜单种子已落地（PR #7467），补部署两条注意事项
changelog-filename-gate / validate (push) Successful in 3s
详情 
sys_menu 两行抢单池入口已由 V20260910_001 补上。
部署须知：#7322 部署清单本次起必须带 hl-user-service；
菜单树按 roleId 缓存 Redis（TTL 3600s），部署后需 DEL cache:menu:tree:role:*。

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
 2026-09-10 16:06:07 +08:00
API Changelog Bot和Claude Fable 5.1 7b1601a7c2 docs(changelog): 补全 #7316 的订正——第四节仍有三处「无权限码限制」与已订正段落自相矛盾
changelog-filename-gate / validate (push) Successful in 2s
详情 
688c403 只订正了 :182 / :259 / :383 三处，同一文件里另有三处原样保留：
- :215 请求示例的 Authorization 头写「任意已登录管理端 token，无需 group-batch:view」
- :284 契约表行「✅ 任意已登录管理端角色调用」
- :288 「本端点无权限码限制」

其中 :284/:288 落在「四、契约约束与正确调用方式」——正是 mmg 据以实现判权与
589507 兜底的那一节，照它实现会完全不处理 589507，危害最大。

三处均已改为现行口径并标注订正日期，另补一条前端提醒：
FINANCE 角色持 finance:view 但不持 finance:advance，写端点按钮需单独控显隐。

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
 2026-09-10 15:47:31 +08:00
API Changelog Bot和Claude Fable 5.1 d807fad55f docs(changelog): #7322 团期整团抢单与抢单池分流（前端契约交接件）
changelog-filename-gate / validate (push) Successful in 2s
详情 
五个新端点（抢单池列表/认领/释放/接管/我的团）+ 五个既有端点改造。
团单户不再进逐户抢单池，改以整团为单位认领；order_group_batch 新增
house_claimer_id / house_claimer_name / house_claimed_at 三列（Flyway V20260910_301 已执行）。

已部署测试服 HEAD 6d41d6148，32 条验收项中 28 条已取证，
含用 5 个真实登录账号过网关实测的归属与接管链路。

⚠️ 正文已注明一项尚缺的交付：sys_menu 的两行抢单池菜单入口尚未随迁移落库，
在补上之前新端点只能直接调用、后台菜单里点不到。

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
 2026-09-10 15:43:36 +08:00
API Changelog Bot和Claude Fable 5.1 6cfa38b56d docs(changelog): #7411 团期核单共享成本三端点补判权（前端契约交接件）
changelog-filename-gate / validate (push) Successful in 2s
详情 
三端点权限码：
- GET  /v3/admin/order/group-batch/{groupBatchId}/settlement/summary → group-batch:finance:view
- GET  /v3/admin/order/group-batch/{groupBatchId}/settlement/cost    → group-batch:finance:view
- POST /v3/admin/order/group-batch/{groupBatchId}/settlement/cost    → group-batch:finance:advance

不持码返 589507，HTTP 恒 200，前端判 Result.code。
请求与响应结构一字未改，网关零改动（/v3/admin/** 已通配）。

已部署测试服 HEAD 6d41d6148，四档权限矩阵经真实登录态过网关实测，
无权限 POST 已用 SQL 前后对比证明零副作用。

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
 2026-09-10 15:26:39 +08:00
API Changelog Bot和Claude Fable 5.1 688c403695 docs(changelog): #7347 finalize 团期住宿户级闸门 + #7390 孤儿持有行自动收敛；订正 #7316 的「无权限码是既有设计」
changelog-filename-gate / validate (push) Successful in 2s
详情 
#7347：整单核单 finalize 新增团期住宿户级硬闸门，新增错误码 584130。
存量统计 SQL 结果为 0，全量生效不做灰度。

#7390：双写扣减孤儿持有行自动收敛，解开重新提交配房恒抛 808902 的死锁。
显著标注「本单不修根因」——submitPersist 仍在 try 块外，孤儿行仍会继续产生。

#7316 订正三处：原文写「本端点无权限码要求……这是既有设计」，
那不是设计而是 #7411 要修的缺陷，已改写为发布时点的事实陈述并指向 #7411。

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
 2026-09-10 14:56:19 +08:00
API Changelog Bot和Claude Fable 5.1 9b67d6f4f0 docs(changelog): #7389 多夜配房释放改逐夜回补 + resource 库存账本告警码拆分
changelog-filename-gate / validate (push) Successful in 3s
详情 
PR #7423(合并提交 f5545b148)已合入 dev-v3,测试服 order-v3/resource-service 均已滚动部署。
本单无接口/字段/表结构变化,仅记录:1) 多夜配房释放由只补首夜改为逐夜回补;2) resource
房务库存账本内部一致性告警从共用 310404 拆分为 310417-310420 四个语义码。

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
 2026-09-10 11:58:02 +08:00
API Changelog Bot 5eff130bf2 docs(changelog): #7323 团期房务地基——配房提交新增可选 replaceReason
changelog-filename-gate / validate (push) Successful in 2s
详情 
PR #7413（合并提交 1a3d3c43f）。本单为地基单，不新增/下线端点、网关零改动。
对前端唯一直接可见的变化是核心配房提交端点新增可选字段 items[].replaceReason，
语义为「仅记首次、不覆写」——重复提交同一配房不会更新已落库的原因文案。

另附一条实测发现的既有文档缺口：items[].arrange 实际会返回 inquiring，
而 Swagger 只列了 pending/waiting/confirmed/problem，提醒前端做兜底分支。

已部署测试服并经网关四步实测，DDL 已 SHOW CREATE TABLE 逐列比对零差异。
 2026-09-10 09:40:34 +08:00
API Changelog Bot 9ae0d869e4 docs(changelog): 修正 #7316 条目日前缀 08 -> 10（发布门禁 E_DAY）
changelog-filename-gate / validate (push) Successful in 2s
详情
2026-09-10 01:49:50 +08:00
API Changelog Bot cdc17540d5 docs(changelog): #7316 团期全团需求汇总补权限码与在团口径 + 结算汇总已核单数纠正 
覆盖两个 PR：#7407（d951c0469）判权与 activeOrderCount 在团口径；
#7408（aafc6ae48）settledOrderCount 判据改用 settled 标志。

已部署测试服 aafc6ae48 并完成网关实测，backend_status=deployed、
gateway_status=verified 为真实态，第八节为实测证据。
 2026-09-10 01:48:59 +08:00
API Changelog Bot 74dc7f0ede docs(changelog): 发布 #7339 库存幂等契约
changelog-filename-gate / validate (push) Successful in 2s
详情
2026-09-08 22:30:49 +08:00
wx和Claude Opus 5 350c7a7124 docs(changelog): #7149/#7210 第二轮复审返工对外变更交接 mmg
changelog-filename-gate / validate (push) Successful in 2s
详情 
打回原因长度 512→500（逐单打回与 dispatch 此前无上限）、confirm-check 新增
NIGHTS_MISMATCH / DAY_NUMBER_INVALID 两个缺失原因与 expectedNights/actualNights 字段、
房务详情页驳回按钮改按订单判配房并新增一条 disabledReason 文案，另附冻结期被房务退回后
可重提、待出发/行程中可整团确认、需求改版配房跟随迁移三条行为变化。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-09-07 17:43:27 +08:00
API Changelog Bot和Claude Opus 5 4c24a515cf fix(7250): 约/保异常文案改「合同异常/保险异常」+ 芯片明细编号更正
changelog-filename-gate / validate (push) Successful in 2s
详情 
后端 GroupBatchChipResolver 的 CONTRACT_FAILED 含「作废中+已作废」、INSURANCE_FAILED 含
「已取消+投保失败」，原文案「合同已作废」「投保失败」以偏概全（正在作废会被说成已作废、
主动退保会被说成投保失败）。统一改为「{error} 户合同异常」「{error} 户保险异常」，
精确原因走明细接口 GB-ADM-094(约) / GB-ADM-095(保)。房/车「已打回」保持不变。

同步更正「精确分布请点进 GB-ADM-092 / 093」的编号错误（092/093 是导/摄），
改为该芯片对应的逐户明细 GB-ADM-090～095 并列出六芯片映射。

涉及 07_7250_* 与 07_frontend_团期看板对齐后端契约待办汇总-* 两篇。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FJVi8pe9KYmLwLARnaYhhC
 2026-09-07 15:48:22 +08:00
API Changelog Bot和Claude Opus 5 c656b273f0 fix(#7203): 更正二轮复审返工的三个新错误码与核心口径
changelog-filename-gate / validate (push) Successful in 2s
详情 
二轮复审(PR #7275)推翻了旧口径「同步失败=订单侧未收到」的断言。实际上：
- 远端已提交成功但回执丢失时，发送端重试耗尽后也会进隔离
- 此时订单侧已是 DONE，直接排车会被 605906 拒
- 故撤销接口需回查订单侧实况后分流三个错误码

本次更新：
1. 补充新增的两个错误码（605923/605924）及其触发条件和前端处置
2. 限定「不必先撤销」仅对 605921 分支成立，605923/605924 必须走运维对账
3. 推翻行 422-425 的核心断言，澄清隔离不等于订单侧未收到
4. 更新 syncStatus 值表 FAILED 的说明文案
5. 注明测试证据表中该行是旧口径的记录
6. 更新 front-matter status_note 记录二轮复审已合并

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-09-07 15:31:09 +08:00
API Changelog Bot 8e77a7b30a docs(changelog): #7244 补记后端复测结论——选品页无法选班期是前端未消费 batches，非后端问题
changelog-filename-gate / validate (push) Successful in 2s
详情
2026-09-07 14:00:36 +08:00
API Changelog Bot 9f27d9bfb8 changelog(7203): 车务显式声明「整段不用车」——声明/撤销/回显三个新增端点
changelog-filename-gate / validate (push) Successful in 2s
详情 
#7067 去槽位化后占位行退役，「车务决定整段不派车」在车管侧就是零派车行，
与「还没开始排车」在库里逐字相同、无法区分，订单侧的用车需求因此永久卡在处理中。
本单新增需求级显式动作承载这个语义（不按零行推断、不放宽常规快照门禁、不复活占位行）。

三个端点各自自包含：入参/出参/请求示例/响应示例/空数据形态/错误响应/业务边界。
另附枚举字典、正确 vs 错误 payload 对照、数据库行为、边界行为与不影响范围。

前端最要紧的三条已写在开头：
- syncStatus 不是订单状态，SYNCED 只表示「送到了」，order-v3 可能按自身规则忽略；
- declarationStatus=REVOKED 时 syncStatus 为 null，不要展示同步状态；
- 撤销按钮只在 syncStatus=SYNCED 时可点，但「只想继续排车」不必先撤销。

实测证据章节为测试服网关真实往返（HEAD 02d7e59be，fleet 双实例），
逐条核对了订单侧 status / assignment_snapshot_revision /
assignment_completion_disposition / assignment_count / assignment_no_vehicle_reason，
不是只看 HTTP 200。
 2026-09-07 13:41:46 +08:00
API Changelog Bot和Claude Opus 5 97608cfca6 docs(changelog): #7244 选品接口透出 productType 与团期班期列表
changelog-filename-gate / validate (push) Successful in 3s
详情 
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01N7Xpgcv9nncadAXQtWhg4P
 2026-09-07 12:40:28 +08:00
API Changelog Bot ca5e4073ce changelog(7067): 补第三轮返工的契约增量九之三——requirementReopened 语义扩宽与 NO_DISPATCH_ANCHOR
changelog-filename-gate / validate (push) Successful in 2s
详情 
第二轮返工合并后的独立复审发现 2 处缺口（PR #7237 已修并部署测试服）：
- 存量订单二次改派后最终方案被误判不完整（改派血缘退休），
- 接送机清空后「开关补开再重存」无法收敛（重开判据由跃迁改为补偿式）。

对前端无破坏性变更（无字段增删、无改名改类型），只有：
C1 requirementReopened 触发面变宽（跃迁 → 状态补偿），重复保存幂等；
C2 reopenBlockedReason 新增取值 NO_DISPATCH_ANCHOR（原来这种情况沉默回 null）；
C3 补充九之二 B6「重存一次即可收敛」的前提——要求日上得有可配置的派车行；
C4 内部修复说明（无契约变更）。

front matter 的 status_note 同步更新为三轮返工的口径。
 2026-09-07 12:01:57 +08:00
API Changelog Bot 800c9bbab3 Merge remote-tracking branch 'origin/main'
changelog-filename-gate / validate (push) Successful in 2s
详情
2026-09-07 11:55:26 +08:00
API Changelog Bot和Claude Opus 5 deef7dc56f changelog: #7210 复审返工补记——权限改按 token 当前角色判权、逐单打回清团级标记（PR #7242） 
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01XYL5S9SsBtkg7aGyFAbrrQ
 2026-09-07 11:52:02 +08:00
API Changelog Bot c39fb8ac24 changelog(frontend): 芯片 tooltip 文案修正——done 是已完成数不是待配数、异常措辞按芯片区分、error>0 不等于红色（后端有覆盖规则）
changelog-filename-gate / validate (push) Successful in 2s
详情
2026-09-07 11:22:13 +08:00
API Changelog Bot ce97c51aa9 changelog(frontend): 芯片计数依赖单号更正为 #7250
changelog-filename-gate / validate (push) Successful in 2s
详情
2026-09-07 11:08:13 +08:00
API Changelog Bot ae20c451a1 changelog(frontend): 团期看板对齐后端契约待办汇总——第N期标题 / scope 班期范围 / 出行完毕页签 / 未建团行交互 / 芯片计数（依赖后端 #7246）
changelog-filename-gate / validate (push) Successful in 2s
详情
2026-09-07 11:05:22 +08:00
API Changelog Bot和Claude Fable 5.1 bab71b6bdf changelog: #7211 定制师↔团期管理员站内会话 GROUP:{orderId}——open-group 新增、聊天/列表/已读/未读改造、itinerary 与团期名单表新增字段、SSE targetPermissionCode（新增接口·管理后台）
changelog-filename-gate / validate (push) Successful in 2s
详情 
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01XYL5S9SsBtkg7aGyFAbrrQ
 2026-09-07 04:57:00 +08:00
API Changelog Bot和Claude Fable 5.1 de167a0c1c changelog: #7210 团期管理员确认/打回改造 M1/M2——confirm-check 预检、589533/589534/589535、reject body 破坏性变更、逐单入口权限（修改接口·管理后台）
changelog-filename-gate / validate (push) Successful in 2s
详情 
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01XYL5S9SsBtkg7aGyFAbrrQ
 2026-09-07 01:45:02 +08:00
API Changelog Bot 8af302c942 Merge remote-tracking branch 'origin/main'
changelog-filename-gate / validate (push) Successful in 2s
详情
2026-09-07 00:57:42 +08:00
API Changelog Bot a591ff1d7a changelog(7189): chips 键名 photo、未建团行金额串口径修正 2026-09-07 00:56:12 +08:00
API Changelog Bot f53f52ca15 changelog(7189): 按门禁补齐 export/board/products 逐接口自包含段落与 TODO 反引号 2026-09-07 00:55:36 +08:00
API Changelog Bot b794316e5a changelog(7189): 团期看板以产品全班期为基底 + scope 班期范围筛选 + 页签期数 product 侧计数（PR #7219），已部署 dev-v3 网关复测 23/23 + AC-14 2026-09-07 00:54:11 +08:00
API Changelog Bot和Claude Fable 5.1 c744e20340 changelog(7188,7190): 团期看板 batchLabel 序号透出（PR #7209）+ 团期九态/八桶与出行完毕自动推进（PR #7212），均已部署 dev-v3 网关复测
changelog-filename-gate / validate (push) Successful in 2s
详情 
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01N7Xpgcv9nncadAXQtWhg4P
 2026-09-06 21:51:08 +08:00
API Changelog Bot和Claude Fable 5.1 2a906d67f7 changelog(7197): 订单详情 data.main 透传 groupBatchStatus（修改接口·管理后台）
changelog-filename-gate / validate (push) Successful in 2s
详情 
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01XYL5S9SsBtkg7aGyFAbrrQ
 2026-09-06 21:45:25 +08:00
API Changelog Bot和Claude Fable 5.1 375520d4bd changelog(7204): 团期看板导/摄芯片聚合态零指派 TODO（PR #7207，已部署 dev-v3 网关复测）
changelog-filename-gate / validate (push) Successful in 2s
详情 
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01N7Xpgcv9nncadAXQtWhg4P
 2026-09-06 20:33:08 +08:00
API Changelog Bot和Claude Fable 5.1 7f634e509d gate: 占位符检测忽略代码围栏与反引号内文本——接口枚举值本身可能叫 TODO（团期芯片聚合态，#7204） 
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01N7Xpgcv9nncadAXQtWhg4P
 2026-09-06 20:33:05 +08:00
API Changelog Bot和Claude Fable 5.1 0451e4ceaa changelog(7149): 更正错误码优先级口径——入口结构校验先于状态校验，对外只变团单 582099 先于 582016；冻结期例外按最高版本组
changelog-filename-gate / validate (push) Successful in 2s
详情 
复审指出原文把事务内 doUpsertHotelRequirement 的校验顺序写成公开接口整体优先级，忽略了直提入口进事务前的团单/结构前置校验。

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01XYL5S9SsBtkg7aGyFAbrrQ
 2026-09-06 19:12:17 +08:00
API Changelog Bot和Claude Fable 5.1 077845c8aa changelog(frontend): 团期看板展开行子订单列表恒空——store.currentGroupBatchId 只在详情页赋值致 PeriodRow 门控恒空；GB-ADM-003 实测正确（关联 #7204/#7188/#7189/#7190）
changelog-filename-gate / validate (push) Successful in 2s
详情 
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01N7Xpgcv9nncadAXQtWhg4P
 2026-09-06 18:57:13 +08:00
API Changelog Bot和Claude Fable 5.1 0623aecfaa changelog(7149): 补 PR #7200（直提入口团单房数 0 统一 582099）
changelog-filename-gate / validate (push) Successful in 2s
详情 
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

Claude-Session: https://claude.ai/code/session_01XYL5S9SsBtkg7aGyFAbrrQ
 2026-09-06 17:51:06 +08:00
API Changelog Bot 79da505a41 docs(7067): 派单去槽位化按行程日配车 + 接送机独立配置四步向导交接件
changelog-filename-gate / validate (push) Successful in 2s
详情 
14 个接口的自包含契约（含 4 个删除端点与 1 个改名端点的前端迁移指引），
backend_status=deployed / gateway_status=verified，网关实测证据已回填。

Refs wx/HL#7067
 2026-09-06 17:50:13 +08:00
API Changelog Bot和Claude Fable 5.1 184ca5ed44 changelog(7149): PR #7184 三轮——订单详情 days[].customerSelfBooked 新增字段说明
changelog-filename-gate / validate (push) Successful in 2s
详情 
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

Claude-Session: https://claude.ai/code/session_01XYL5S9SsBtkg7aGyFAbrrQ
 2026-09-06 17:10:27 +08:00
API Changelog Bot和Claude Fable 5.1 fbe1de4d91 changelog(7149): PR #7184 二轮——错误码优先级变化（核心订单也受影响）、调整入口 582099 同口径、汇总不保证逐日连续、详情统计同步跳自订晚
changelog-filename-gate / validate (push) Successful in 2s
详情 
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

Claude-Session: https://claude.ai/code/session_01XYL5S9SsBtkg7aGyFAbrrQ
 2026-09-06 16:56:52 +08:00
API Changelog Bot和Claude Fable 5.1 fc87e3280a changelog(7149): 复审补漏 PR #7184——汇总跳过自订晚、团单房数为空/0 统一 582099、校验顺序说明
changelog-filename-gate / validate (push) Successful in 2s
详情 
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

Claude-Session: https://claude.ai/code/session_01XYL5S9SsBtkg7aGyFAbrrQ
 2026-09-06 16:40:06 +08:00
API Changelog Bot和Claude Fable 5.1 354d9083a7 scripts: validate-changelog-frontmatter 增加 --files 提交前自检模式（与 pre-push 门禁同规则，供作者/Agent 与 hl-workflow lint 复用）
changelog-filename-gate / validate (push) Successful in 2s
详情 
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

Claude-Session: https://claude.ai/code/session_01XYL5S9SsBtkg7aGyFAbrrQ
 2026-09-06 16:18:27 +08:00
API Changelog Bot和Claude Fable 5.1 7b9b60b9ac changelog(7149): 按 CHANGELOG_TEMPLATE 重写——三接口自含入参/出参/示例/错误/边界，补对比与影响评估（门禁）
changelog-filename-gate / validate (push) Successful in 2s
详情 
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

Claude-Session: https://claude.ai/code/session_01XYL5S9SsBtkg7aGyFAbrrQ
 2026-09-06 16:11:30 +08:00
API Changelog Bot和Claude Fable 5.1 c1d7fed7b6 changelog(7149): 按 CHANGELOG_TEMPLATE 重排章节（门禁） 
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

Claude-Session: https://claude.ai/code/session_01XYL5S9SsBtkg7aGyFAbrrQ
 2026-09-06 16:08:18 +08:00
API Changelog Bot和Claude Fable 5.1 c5c69d10aa changelog(7149): 边界行为补「团单不接受空白占位段」与「物资准备=物料准备中」说明 
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

Claude-Session: https://claude.ai/code/session_01XYL5S9SsBtkg7aGyFAbrrQ
 2026-09-06 15:59:33 +08:00
API Changelog Bot和Claude Fable 5.1 c5adab6346 changelog(7149): 团期子订单支付后即可提房车需求、物资准备起冻结 589536、团单房型间数必填 582099（PR #7177，Refs #7149） 
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01XYL5S9SsBtkg7aGyFAbrrQ
 2026-09-06 15:58:44 +08:00
API Changelog Bot和Claude Opus 4.8 c4968b5233 docs(changelog): 团期创单收紧+人数预查(#7135/#7159)、判团字段(#7142)、看板productId(#7143)、前端缺陷指引
changelog-filename-gate / validate (push) Successful in 2s
详情 
- 06_7135：填 PR #7169 / 合并提交 977be08e / 折入 #7159（581034 改读 remainingParticipants）/ 修正单测计数 / 补部署 dev-v3 网关复测 15/15 证据
- 06_frontend：更正后端已加固并部署验证（不再是零改动），补 581055/581056/581057、581034 触发条件与影响范围
- 06_7142 / 06_7143：早前已随 PR #7155/#7157 合并，随本批提交

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01N7Xpgcv9nncadAXQtWhg4P
 2026-09-06 15:23:27 +08:00