7 次代码提交

包含重命名

作者	SHA1	备注	提交日期
Mimingguang	1eae62b9f4	docs(changelog): 7 条前端实证判 not_required,翻状态+补实证 status_note(#7949/#7932-验团前置/#7442-vehicle-ready/#7539/#7942/#7925/#7937)	2026-09-20 13:27:20 +08:00
API Changelog Bot和Claude Opus 5	25e77cf72e	docs(7442): 修 5 处指向「从未存在过的文件名」的悬空引用，改为单号+glob ... #7442 的两份交接件里有 5 处引用 `19_7444_团期配车就绪门禁与同团车辆共用关系-新增接口-管理后台.md`。 该文件名在全历史零命中（阳性对照：同一条命令能找到确知已提交的 `*7442*reconfigure补登*`，所以零命中是真空不是 glob 写错）——它是起草期的 一份草稿名，该稿已并入现存的 `*_7444_*` 交接件、名字不再存在。 不改成「现存的那个文件名」，因为那会埋一次必然的再次失效： ① 那份文件还没提交（门禁按设计拦着 backend_status=pending）； ② 本仓文件名带提交日前缀，它哪天被推名字就是哪天； ③ 「指向文件名」本身就是错的抽象层——文件名会变，单号不会。 改成「#7444 的交接件（按 `*_7444_*` 检索）」，这个形态不需要第二次维护。 旧名在括号里保留一句接住 grep。 Refs #7444 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-20 12:05:46 +08:00
API Changelog Bot和Claude Opus 5	0eecbce1ab	docs(changelog): #7442 订正两份交接件的部署顺序结论——按单算的"顺序无所谓"在并集里是错的 ... 两份文档各有一句部署顺序结论： - 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 契约错误 ... 三份文档此前 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，补两处部署清单取证 ... 一、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和Claude Opus 5	1c0439c44a	docs(changelog): #7442 PR-C2 受控重开窗口 + 三份补部署清单与 dispatch-baseline 条目 ... 新增 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） ... 这两个 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