docs(changelog): #8294/#8341/24_frontend 更新时间列 前端回写 verified
changelog-filename-gate / validate (push) Failing after 1s

这个提交包含在:
Mimingguang
2026-09-24 17:40:38 +08:00
父节点 694c1a71be
当前提交 079c4ded20
共修改 3 个文件,包含 16 行新增和 16 行删除
@@ -7,12 +7,12 @@ author: "wx(GIT)"
change_type: "修改接口" change_type: "修改接口"
backend_status: "deployed" backend_status: "deployed"
gateway_status: "verified" gateway_status: "verified"
frontend_status: "pending" frontend_status: "verified"
frontend_owner: "" frontend_owner: "mmg"
frontend_ref: "" frontend_ref: "e5a34cd13e641ac10394a9a245f0548461894a02"
target_release: "" target_release: "v2.1"
verified_at: "" 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×车数。" 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" updated_at: "2026-09-24"
base: "dev-v3" base: "dev-v3"
--- ---
@@ -7,12 +7,12 @@ author: "jw(GIT)"
change_type: "修改接口" change_type: "修改接口"
backend_status: "deployed" backend_status: "deployed"
gateway_status: "verified" gateway_status: "verified"
frontend_status: "pending" frontend_status: "verified"
frontend_owner: "" frontend_owner: "mmg"
frontend_ref: "" frontend_ref: "d2585f3c766c9ad7e102f7409f1a7419792636dd"
target_release: "" target_release: "v2.1"
verified_at: "2026-09-24" 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" updated_at: "2026-09-24"
base: "dev-v3" base: "dev-v3"
--- ---
@@ -7,12 +7,12 @@ author: "wx(GIT)"
change_type: "前端优化" change_type: "前端优化"
backend_status: "not_required" backend_status: "not_required"
gateway_status: "not_required" gateway_status: "not_required"
frontend_status: "pending" frontend_status: "verified"
frontend_owner: "mmg" frontend_owner: "mmg"
frontend_ref: "" frontend_ref: "6e6fe48982e6b39f01aba5f5c1236437f999b7de"
target_release: "" target_release: "v2.1"
verified_at: "" 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 同款(“六状态列无独立时间戳”)。该列对房/车两块芯片永远渲染不出值,属纯前端展示问题,无需后端改动。" 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" updated_at: "2026-09-24"
base: "dev-v3" base: "dev-v3"
--- ---