diff --git a/changelogs-v2/2026-09/24_8294_团期配车就绪检查座位不足黄牌扣司机座，新增-passengerSeatTotal-修改接口-管理后台.md b/changelogs-v2/2026-09/24_8294_团期配车就绪检查座位不足黄牌扣司机座，新增-passengerSeatTotal-修改接口-管理后台.md index f99b8581..ee2c9abd 100644 --- a/changelogs-v2/2026-09/24_8294_团期配车就绪检查座位不足黄牌扣司机座，新增-passengerSeatTotal-修改接口-管理后台.md +++ b/changelogs-v2/2026-09/24_8294_团期配车就绪检查座位不足黄牌扣司机座，新增-passengerSeatTotal-修改接口-管理后台.md @@ -7,12 +7,12 @@ author: "wx(GIT)" change_type: "修改接口" backend_status: "deployed" gateway_status: "verified" -frontend_status: "pending" -frontend_owner: "" -frontend_ref: "" -target_release: "" -verified_at: "" -status_note: "PR #8305 已合并 dev-v3（2a3b9df59）。部署：hl-fleet-service dev-v3 @ 2a3b9df59，2026-09-24 09:48:52 起滚，09:50:13 完成，8087/8187 两实例均 UP；实测 09:52 晚于部署完成时刻。测试服网关真实 GET /admin/fleet/group-dispatch/batches/{groupBatchId}/readiness：团期 2101514348969226242 返回 WARN_SEAT_SHORTAGE，seatTotal=7、passengerSeatTotal=6、headcount=40、gap=34（7-1=6 证明扣座、40-6=34 证明 gap 按新口径）；团期 2102066067272826881 座位合计 0 时 passengerSeatTotal=0 不为负；团期 2101997326354862082（座位合计 5/可载客 4/人数 4）与 2101690789438570497（7/6/6）warned=false，证明取等号时不误报。fleet 定向单测 778/0/0（含 GroupDispatchReadinessServiceTest 26、VehicleSeatCapacityTest 4、FleetRedLineArchTest 18）+ spotless:check 绿；回退判据后 3 个用例转红（含「20 座车 20 人应报缺 1 座」），恢复后转绿。gateway_status: verified —— 路径本就在既有 admin-fleet-service 路由 Path=/admin/fleet/** 下，本次零路由改动，并已通过真实网关实测。frontend_status: pending —— 前端需读新字段 passengerSeatTotal，且 gap 的语义已变（改为 用车人数 − 已扣司机座的可载客数），若仍按「用车人数 − seatTotal」渲染会差 1×车数。" +frontend_status: "verified" +frontend_owner: "mmg" +frontend_ref: "e5a34cd13e641ac10394a9a245f0548461894a02" +target_release: "v2.1" +verified_at: "2026-09-24" +status_note: "PR #8305 已合并 dev-v3（2a3b9df59）。部署：hl-fleet-service dev-v3 @ 2a3b9df59，2026-09-24 09:48:52 起滚，09:50:13 完成，8087/8187 两实例均 UP；实测 09:52 晚于部署完成时刻。测试服网关真实 GET /admin/fleet/group-dispatch/batches/{groupBatchId}/readiness：团期 2101514348969226242 返回 WARN_SEAT_SHORTAGE，seatTotal=7、passengerSeatTotal=6、headcount=40、gap=34（7-1=6 证明扣座、40-6=34 证明 gap 按新口径）；团期 2102066067272826881 座位合计 0 时 passengerSeatTotal=0 不为负；团期 2101997326354862082（座位合计 5/可载客 4/人数 4）与 2101690789438570497（7/6/6）warned=false，证明取等号时不误报。fleet 定向单测 778/0/0（含 GroupDispatchReadinessServiceTest 26、VehicleSeatCapacityTest 4、FleetRedLineArchTest 18）+ spotless:check 绿；回退判据后 3 个用例转红（含「20 座车 20 人应报缺 1 座」），恢复后转绿。gateway_status: verified —— 路径本就在既有 admin-fleet-service 路由 Path=/admin/fleet/** 下，本次零路由改动，并已通过真实网关实测。frontend_status: pending —— 前端需读新字段 passengerSeatTotal，且 gap 的语义已变（改为 用车人数 − 已扣司机座的可载客数），若仍按「用车人数 − seatTotal」渲染会差 1×车数。 前端已交付并验证：实证黄牌 b.message 直显、seatTotal/gap/headcount 零数值消费，新文案自动生效；group-dispatch.js JSDoc 订正新口径（透 message 禁文本匹配/自算 gap，seatTotal+gap≠headcount 正常须 passengerSeatTotal+gap 闭合），drawer spec fixture/断言改新文案回归锁 7 例全绿。hl-admin@e5a34cd1。" updated_at: "2026-09-24" base: "dev-v3" --- diff --git a/changelogs-v2/2026-09/24_8341_团期核单结算反结算同步子订单与结算589568列未提交户-修改接口-管理后台.md b/changelogs-v2/2026-09/24_8341_团期核单结算反结算同步子订单与结算589568列未提交户-修改接口-管理后台.md index 54f74ac2..a37ddba8 100644 --- a/changelogs-v2/2026-09/24_8341_团期核单结算反结算同步子订单与结算589568列未提交户-修改接口-管理后台.md +++ b/changelogs-v2/2026-09/24_8341_团期核单结算反结算同步子订单与结算589568列未提交户-修改接口-管理后台.md @@ -7,12 +7,12 @@ author: "jw(GIT)" change_type: "修改接口" backend_status: "deployed" gateway_status: "verified" -frontend_status: "pending" -frontend_owner: "" -frontend_ref: "" -target_release: "" +frontend_status: "verified" +frontend_owner: "mmg" +frontend_ref: "d2585f3c766c9ad7e102f7409f1a7419792636dd" +target_release: "v2.1" verified_at: "2026-09-24" -status_note: "六节点定案（SRS §0.27.7）：团期单子订单的核单结算状态由团期驱动，与团期状态变更同一事务、全有全无。① 团期进入核单（POST .../review/start 或首次 POST .../settlement/cost 把团期从 TRIP_FINISHED 推到 REVIEWING）：在团户中 flow=PENDING_REVIEW 的户同步为 review IN_PROGRESS / flow REVIEWING，已在核单中或已提交的户不动，幂等命中（alreadyStarted=true / 第二笔成本）不同步。② 团期结算 POST .../settle = 整团财务复核：待结算户逐户做与「财务复核确认结算」相同的写入（settlement COMPLETED / flow SETTLED / settled_at、SETTLEMENT_CONFIRM 日志、推送 BZ 报账单），已结算户跳过；有逐户核单未提交（或定稿后被逐户反确认）的户，整团拒绝 589568「整团核单当前状态不允许该操作：结算需要所有在团订单逐户核单已提交，未提交订单：{订单 ID，「、」分隔}」，零写入。③ 团期反结算 POST .../settle/reopen：已结算户退回 flow PENDING_SETTLE / settlement PENDING、清 settled_at，review 与逐户核单快照不动，已生成的报账单不撤（重新结算按 settlementId 幂等命中）。路径、入参、成功出参均不变；已取消户不受影响。前端需：处理团期结算的 589568 新原因（提示先去对应订单提交逐户核单）；团期结算后不必再引导运营逐户点「结算确认」。" +status_note: "六节点定案（SRS §0.27.7）：团期单子订单的核单结算状态由团期驱动，与团期状态变更同一事务、全有全无。① 团期进入核单（POST .../review/start 或首次 POST .../settlement/cost 把团期从 TRIP_FINISHED 推到 REVIEWING）：在团户中 flow=PENDING_REVIEW 的户同步为 review IN_PROGRESS / flow REVIEWING，已在核单中或已提交的户不动，幂等命中（alreadyStarted=true / 第二笔成本）不同步。② 团期结算 POST .../settle = 整团财务复核：待结算户逐户做与「财务复核确认结算」相同的写入（settlement COMPLETED / flow SETTLED / settled_at、SETTLEMENT_CONFIRM 日志、推送 BZ 报账单），已结算户跳过；有逐户核单未提交（或定稿后被逐户反确认）的户，整团拒绝 589568「整团核单当前状态不允许该操作：结算需要所有在团订单逐户核单已提交，未提交订单：{订单 ID，「、」分隔}」，零写入。③ 团期反结算 POST .../settle/reopen：已结算户退回 flow PENDING_SETTLE / settlement PENDING、清 settled_at，review 与逐户核单快照不动，已生成的报账单不撤（重新结算按 settlementId 幂等命中）。路径、入参、成功出参均不变；已取消户不受影响。前端需：处理团期结算的 589568 新原因（提示先去对应订单提交逐户核单）；团期结算后不必再引导运营逐户点「结算确认」。 前端已交付并验证：实证对 589568 零按码分支（核团域同码不同场景均透 message），验团成功文案无「引导逐户结算确认」残留，透 message 即达标；settle/reopen/review-start JSDoc 补同步语义与 589568 新原因（禁解析订单 ID 自建链接），AuditTab 注释订正。纯文档零行为改动，hl-admin@d2585f3c。" updated_at: "2026-09-24" base: "dev-v3" --- diff --git a/changelogs-v2/2026-09/24_frontend_团期详情配房配车明细更新时间列恒为空-前端优化-管理后台.md b/changelogs-v2/2026-09/24_frontend_团期详情配房配车明细更新时间列恒为空-前端优化-管理后台.md index f0bc0387..93d2b2c9 100644 --- a/changelogs-v2/2026-09/24_frontend_团期详情配房配车明细更新时间列恒为空-前端优化-管理后台.md +++ b/changelogs-v2/2026-09/24_frontend_团期详情配房配车明细更新时间列恒为空-前端优化-管理后台.md @@ -7,12 +7,12 @@ author: "wx(GIT)" change_type: "前端优化" backend_status: "not_required" gateway_status: "not_required" -frontend_status: "pending" +frontend_status: "verified" frontend_owner: "mmg" -frontend_ref: "" -target_release: "" -verified_at: "" -status_note: "浏览器实测（测试服 web.test.1814.love，2026-09-24 17:0x，团期 2102981652823302146，4 户）：团期详情 → 配房 / 配车 两个芯片明细列表的“更新时间”列四行全部为「—」。对照后端契约：GET /v3/admin/order/group-batch/{groupBatchId}/chips/hotel 与 /chips/vehicle 的 items[].updateTime 恒为 null；后端源码 GroupBatchChipResolver#toItem 明确注释“无状态时间列时 updateTime=null”，ChipItem.updateTime 字段 javadoc 同款（“六状态列无独立时间戳”）。该列对房/车两块芯片永远渲染不出值，属纯前端展示问题，无需后端改动。" +frontend_ref: "6e6fe48982e6b39f01aba5f5c1236437f999b7de" +target_release: "v2.1" +verified_at: "2026-09-24" +status_note: "浏览器实测（测试服 web.test.1814.love，2026-09-24 17:0x，团期 2102981652823302146，4 户）：团期详情 → 配房 / 配车 两个芯片明细列表的“更新时间”列四行全部为「—」。对照后端契约：GET /v3/admin/order/group-batch/{groupBatchId}/chips/hotel 与 /chips/vehicle 的 items[].updateTime 恒为 null；后端源码 GroupBatchChipResolver#toItem 明确注释“无状态时间列时 updateTime=null”，ChipItem.updateTime 字段 javadoc 同款（“六状态列无独立时间戳”）。该列对房/车两块芯片永远渲染不出值，属纯前端展示问题，无需后端改动。 前端已交付并验证：ChipItemsTable 更新时间列改数据驱动显隐——全行 updateTime 为 null（房/车契约恒 null）整列不渲染，任一行有真值（约/保）出列截到分钟直显；不读 chipLabel 判芯片，禁拿 status-logs 凑值；列表弹层 ChipDetailModal 共用同组件自动生效。ChipStaffDisplay spec 7 例全绿（新增 2 例），hl-admin@6e6fe489。" updated_at: "2026-09-24" base: "dev-v3" ---