425 次代码提交

包含重命名

作者	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
Mimingguang	11342ee25d	docs(changelog): #8005 前端已交付,回写 verified(mmg,hl-ui v2.1)	2026-09-20 13:27:20 +08:00
jw和Claude Opus 5	dde36e4548	docs(changelog): #8005 补 AC-11 退团口径回归取证 ... Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-20 13:00:28 +08:00
jw和Claude Opus 5	7aa66180af	docs(changelog): #8005 退单户候选列表与提交前预览（新增接口） ... Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-20 12:58:18 +08:00
jw和Claude Opus 5	ec1d8b3c69	docs(changelog): #7937 全团需求汇总车型座位合计补车型大类中文名 vehicleTypeName（修改接口） ... Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-20 12:14:27 +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	ae069b00a9	fix: frontmatter 未转义的引号让元数据对所有消费方隐形——修 19_7443 + 给校验器补语法层 ... 现象：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
jw和Claude Opus 5	8d644fc8f3	docs(changelog): #7925 全团需求汇总房间合计对齐预检判定 + 补房型中文名与需房/已提交户数（修改接口） ... Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-20 09:52:45 +08:00
jw和Claude Opus 5	afc2699499	docs(changelog): #7942 团期看板 keyword 支持按期号「第N期」精确搜索（修复） ... Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-20 09:42:54 +08:00
jw	f839961bf4	docs(changelog): #7539 团期出发推进定时任务 1041 启用与存量待出发团处置（无接口变更） ... Refs #7539	2026-09-20 09:29:21 +08:00
API Changelog Bot和Claude Opus 5	3b637393bc	docs(changelog): #7443 TRANSFER 提交开关测试服已开启，订正 18_7443 里 frontend_status=not_required 的判定依据 ... 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 个字段 ... 对 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	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	4c7d3f2773	docs(changelog): #7443 订正 PR-1 文档的错误码判定，并修掉两处发布门禁问题 ... 一、内容订正（本次的主体） 原文「三个端点对 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 条目 ... 新增 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
lc和Claude Opus 5	554c11bef7	docs(changelog): #7947 餐食删除编码、关联餐厅（含全部）、增加桌/人（修改接口·管理后台） ... Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-19 00:08:27 +08:00
lc	81934d4957	docs(changelog): #7741 订单用餐信息与用餐模版接口（新增 7 个接口·管理后台）	2026-09-18 20:20:59 +08:00
jw	d7c4a5d4bf	docs(changelog): #7949 定制师可读名下团期详情与子订单名单（修改接口·管理后台）	2026-09-18 18:16:37 +08:00
jw和Claude Opus 5	8a5c34f09f	docs(changelog): #7932 团期核团 7 个新增接口与验团前置核团行为变更 ... Refs wx/HL#7932 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-18 18:12:53 +08:00
Mimingguang	090ad8936f	docs(changelog): #7946 前端交付回写 verified(canTransferOrder 收紧仅 RECRUITING)	2026-09-18 17:22:48 +08:00
jw和Claude Opus 5	547035c39e	docs(changelog): #7946 团期转订单收紧为只允许招募中团期之间转（修改接口） ... Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-18 17:11:44 +08:00
Mimingguang	d7fbbdeb1d	chore(changelog): #7933 餐食单价说明回写 verified(复核发现 placeholder 旧口径已修)	2026-09-18 16:13:51 +08:00
Mimingguang	27ee86ea5f	chore(changelog): 团期看板 3 条交付回写 verified(#7939 统计条提示+月份分组正序+batchNo 移除) ... - #7939 → 8360287a(总览条 scopeFilterHint 两口径文案,scope 已摘除只提示不切) - 月份分组缺陷 → c19923be(默认月组倒序改升序,显式排序仍跟随行序) - batchNo 缺陷 → c6174f2c(仅删显示,keyword 搜索数据链不动) 各自定向 spec 6/6、21/21、9/9 + scoped checkpoint 全绿,hl-admin v2.1 已推。	2026-09-18 16:10:53 +08:00
lc和Claude Opus 5	6fbcb70331	docs(changelog): #7933 餐食单价说明改为「单价（元）」，不限定每人（修改接口，前端无需改代码） ... Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-18 16:05:44 +08:00
API Changelog Bot和Claude Opus 5	72e05778e2	docs(changelog): 团期看板不要显示 28 位班期编号 batchNo（前端缺陷，交接 mmg） ... 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
jw和Claude Opus 5	f9c6ce3dd1	docs(changelog): #7939 团期看板统计条回带 effectiveScope 与 filteredOutCount（修改接口） ... Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-18 15:43:39 +08:00
API Changelog Bot和Claude Opus 5	cffa47bc46	docs(changelog): 团期看板月份分组倒序应按出发日正序（前端缺陷，交接 mmg） ... 现象：班期列表按月份分组时 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
Mimingguang	aea21e188c	docs(changelog): #7928/#7930 前端回写 verified(mmg) ... #7928 资金流水 bizTypeName:ref 9917447b88cf3dfbc163e3a313f1ad30710881d7。 #7930 司导预支队列 remark 用途:ref aecb98724e7cf8f26f7cfb7dd041c8171e290086。 前端 hl-admin 按两条完成并验证,回写 frontend_status=verified + owner mmg + ref + status_note。	2026-09-18 14:57:27 +08:00
Mimingguang	59e978552a	docs(changelog): #7901 司导预支支付链接通前端回写 verified(mmg) ... 前端 hl-admin 按本条完成出纳 ADVANCE 页签接线并验证,回写 frontmatter: frontend_status=verified + owner mmg + ref 9e65d25bf551315cc6dea35475ef9803afadc04b + status_note 追加实现与验证说明(verified_at 沿用 2026-09-18)。	2026-09-18 14:35:27 +08:00
yaosutu	334d84e3ff	docs(changelog): #7928 资金流水分页/详情出参补 bizTypeName 中文名-管理后台 ... ORDER_REFUND 此前因前端硬编码 map 漏配回显英文枚举码。后端两个只读接口 /admin/finance/fund-flows/page 与 /{id} 出参各新增 bizTypeName（枚举 label， 14 业务类型全覆盖），bizType 英文码不变，零入参/零DDL。已部署测试服网关实调 8 项断言全 PASS。	2026-09-18 14:06:51 +08:00
yaosutu	755c690e24	docs(changelog): #7930 司导预支出纳队列行 remark 补预支用途快照（修改接口-管理后台） ... ADVANCE 待支付队列 GET /admin/finance/cashier/advance/queue 出参 remark 由恒 null 改为 fin_advance.purpose（申请用途快照）；纯出参补值向后兼容， 入参/路径/其余字段/错误码/付款接口均不变；历史单与未填用途单仍为 null。 PR #7931 已合并 dev-v3 尚未部署。	2026-09-18 12:44:32 +08:00
Mimingguang	514ab2cf1f	docs(changelog): #7919 供应商合同主/补充合同前端回写 verified(mmg) ... 前端 hl-admin 按本条完成破坏性表单重构并验证,回写 frontmatter: frontend_status=verified + owner mmg + ref dde41d86ffa2a6bd2cd0ae10b96e0ab1d78821fa + verified_at 2026-09-18 + status_note 追加实现与验证说明。	2026-09-18 12:23:13 +08:00
Mimingguang	e6be4be31d	docs(changelog): #7916 团期物资 categoryName 前端已实现并验证(hl-admin 08d13de3) ... frontend_status pending→verified,frontend_ref=08d13de33b27948c31cb1e511ad59f342420e88c, verified_at=2026-09-18,status_note 追加实现摘要。	2026-09-18 11:50:41 +08:00
Mimingguang	265dcd0408	docs(changelog): #7737 餐食管理前端已实现并验证(hl-admin 7d18b442) ... frontend_status pending→verified,frontend_owner=mmg, frontend_ref=7d18b442071bb50db9d260cb80224f9e413f3058,status_note 追加实现摘要。	2026-09-18 11:37:47 +08:00
yaosutu	26e995a97e	feat(changelog): 司导预支（司导借款）支付链接通——出纳 ADVANCE 页签 queue/pay 真实接通（Epic #7901，PR #7902/#7906/#7910 已合并 dev-v3 部署测试服 E2E 通过；原 598607 空壳下线，金额锁死 598610，新增错误码 599500-599505）	2026-09-18 11:28:02 +08:00
lc和Claude Opus 5	0119ffca67	docs(changelog): #7919 供应商合同改为主合同/补充合同，业务线改为资源并按资源选择主合同（修改接口） ... Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-18 11:14:48 +08:00
jw	4c8f93f978	docs(changelog): #7916 团期物资列表与候选补分类中文名 categoryName（修改接口）	2026-09-18 11:02:39 +08:00
lc和Claude Opus 5	4cdf3606e9	docs(changelog): #7737 餐食管理接口 1.1–1.7 与菜单（新增接口） ... Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-18 10:16:23 +08:00
Mimingguang	553aa99dd7	docs(changelog): #7443 接送机用车需求分叉 PR-1 前端判 not_required 回写 frontmatter	2026-09-18 08:13:01 +08:00
API Changelog Bot和Claude Opus 5	e4fc9d1a90	docs(changelog): 补 09-17 两份的 target_release，解开 pre-push 门禁 ... 推送被拦：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
Mimingguang	778d618ef4	chore(changelog): #7724 核单复核出参判 not_required(前端无复核调用点)	2026-09-17 23:52:43 +08:00
yaosutu	28effce68e	docs(changelog): 核单复核出参加报账字段（Issue #7724 / PR #7725）	2026-09-17 23:40:33 +08:00
Mimingguang	20f348694a	chore(changelog): #7897 发票列表订单侧字段前端已接入(verified@de19fb77)	2026-09-17 22:04:10 +08:00
yaosutu	a080db4c72	docs(changelog): 发票管理列表行补订单侧字段（Issue #7897 / PR #7899） ... GET /v3/admin/order/invoice/page 行级 records[] 纯新增 10 个订单侧字段： teamNo/createTime/orderStatus(含文案)/flowStatus(含文案)/orderAmount/paidAmount/refundedAmount/settlementAmount。 入参/既有出参/错误码零变化，NONE tab 同样回填，前端无需同步上线。	2026-09-17 21:55:24 +08:00
Mimingguang	2f7858e815	chore(changelog): #7857 收票进项发票域前端已交付(verified@f5751df4)	2026-09-17 19:51:40 +08:00
Mimingguang	a5346644a2	chore(changelog): #7883 供应商往来账页前端已交付(verified@a975f40b)	2026-09-17 19:20:15 +08:00