5 次代码提交

包含重命名

作者	SHA1	备注	提交日期
Mimingguang	1e59aac339	chore(8152/8164): 回写前端闭环(8152 订正残留已清 0b65814a;8164 核验 not_required 透 message 自动覆盖)	2026-09-22 16:35:50 +08:00
API Changelog Bot和Claude Opus 5	000e93c6be	docs(changelog): 8152 交接件补记前端侧同源残留两处（statusName 编造取值的下游落点） ... e011960 订正了本交接件里 statusName 的四个编造取值，但那四个字符串已被 hl-admin 抄进两处：VehicleHouseholdsSection.vue:191 的注释与该组件 spec 的夹具。两处都不影响运行（组件 :78 是纯透传、用例断言的是透传行为）， 但下一个人 grep「待处理」会同时撞上它们，需要能分清哪些是错的。 同时把责任归属写明：四个取值是后端先写错在交接件里、前端照抄的。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-22 15:36:32 +08:00
API Changelog Bot和Claude Opus 5	e011960e45	fix(changelog): 订正 8152 交接件 vehicle-households 端点 statusName 编造取值 ... `three` 处示例/字段说明里的 statusName 中文值（"已完成"/"待处理"）系凭空编造，既不是修复前的房务口径值（"配房完成"/"待房务配"），也不是修复后的车务口径值。核对 GroupBatchConverter.resolveRequirementStatusName(code, true) 源码后改为实测口径：PENDING→待车队配、PROCESSING→配车中、DONE→配车完成。 同时订正 六.5 枚举表里同样错误的三个取值，并补一段说明——该端点 statusName 原实现直接取 RequirementStatus 枚举的房务侧 label，已由 45adfd7ed（PR #8173）改调 resolveRequirementStatusName(code, true) 修正，附完整取值表。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-22 15:16:10 +08:00
Mimingguang	ff16082a23	docs(changelog): #8152/#8151/#8153 前端已交付回写 verified(hl-admin v2.1 @ 14cb7110)	2026-09-22 14:57:27 +08:00
API Changelog Bot和Claude Opus 5	312ecd0f1f	docs(changelog): 团期用车需求结构化 + 团期管理员只读查看子订单，两份前端交接件 (#8152 #8151 #8153 #8154) ... - 22_8152_…：团级用车需求补 seats/count/specialTags/remark 四个结构化字段；新增 `GET .../requirement/vehicle-households` 子订单用车需求记录端点；requirement-summary 补 transferSummary 聚合；confirm-check 补 transferSubmitEnabled 与接送机缺口名单。 - 22_8154_…：团期管理员（GROUP_BATCH_MANAGER）可只读打开团期子订单详情（10 个端点放行）， 13 个金额/成本/流水面端点对该角色收回（581008），写面全域拒绝。 两份均已回填测试服活体实测读数：order-v3 @ f1986f996，user-service / fleet @ c4321f961。 #8154 的前后对照含一条关键读数——改动前该角色读订单被拒、写订单却畅通，本批一并收口。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-22 13:20:00 +08:00