8 次代码提交

包含重命名

作者	SHA1	备注	提交日期
Mimingguang	aa310a1d61	docs(changelogs-v2): #7442 PR-A reconfigure 前端增量2已交付回写 verified(mmg)	2026-09-21 10:34:40 +08:00
Mimingguang	2d8b287ca6	docs(changelogs-v2): #7988 与 #7442 PR-C2 前端增量1已交付回写 verified;PR-A reconfigure 注增量2待建(mmg)	2026-09-21 10:10:43 +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	fc36125695	docs(changelog): #7442 逐字段审计查出两处契约错误，修正 coverage 错误响应与 reconfigure 漏列的 5 个字段 ... 对 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 订正两份交接件的部署顺序结论——按单算的"顺序无所谓"在并集里是错的 ... 两份文档各有一句部署顺序结论： - 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和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