7445 团期用车结算闸(584131+VEHICLE 软预警)与 7446 住宿结算闸判团口径 (584130 判据修正),经 grep 实证 hl-admin 前端均零改动: - 前端无按码分支,request.js 通用 bizError 兜底透传后端 message 原文, 584131/584130 文案已含订单号+需求状态+操作指引,透传即达标。 - detail.vue warnings 渲染只取 item.message 且兼容过渡期字符串,从不读 settlementId/dayNumber 定位明细行,category=VEHICLE 项(恒 null)正常展示。 - 7446 契约一字未变仅触发人群变化,前端对 584130 无专属处理不受影响。 frontmatter 翻 frontend_status=not_required + owner=mmg + status_note 追加, 无业务 commit,ref 留空。
两单的 §八「测试环境已验证」原先都写着「本节当前为空，网关实测尚未进行」， frontmatter 的 gateway_status 卡在 pending、pre-push 校验器报 E_GATEWAY_PENDING。 2026-09-11 网关实测已完成，本次把结果写进两份交接件： - #7445 四组（17:38 三组 + 18:36 补一组）：团期单 + 用车 PENDING → 584131； 推 DONE → 200；散客单两类需求都 PENDING → 200（两闸均不误触发）； 车费派生行全部软删 + 需求 PROCESSING → 仍 584131 - #7446 四组：方向甲 + 住宿 PENDING → 584130；推 DONE → 200； 待回填老单（product 非空 + group 为空 + 团期存活）→ 仍 584130；散客单 → 200 两份都如实写明了两条取证边界，不许读的人误推： 1. 全部前置都是 SQL 直更造出来的（直接改需求 status），不是走真实配车/配房链路产生的 2. 取证路上绕过了三道与本单无关的通用前置闸（584310 八分类未确认、584082 待收尾款、 车费草稿冻结确认），手段是 SQL 标 CONFIRMED / 清零应收；这三道闸自身的正确性未被验证 gateway_status pending→verified、verified_at 填 2026-09-11、status_note 改为如实描述。 frontend_status 保持 pending 未动。
Mimingguang
API Changelog Bot
Mimingguang
API Changelog Bot