优化
This commit is contained in:
@@ -1,5 +1,56 @@
|
||||
# 测试环境单机部署与配置契约
|
||||
|
||||
## 尾程商业来源 TEST 发布与验收（2026-10-09）
|
||||
|
||||
本轮用户授权发布并测试。本次商业来源改动只发布 TEST Admin 与 Lastleg，未发布灰度。Admin `admin-web-test #539`，提交 `7a9e91b7ce9bcfec7636ae2b3a012b0ddff24703`；Lastleg 最终 `baiyue-firstleg-lastleg-service #240`，提交 `023b28e31f72569efffc023ab3b3b981e971b14d`，均 SUCCESS，实际镜像标签及容器 running/healthy 核对通过。其他任务未提交的地图、排车改动未纳入本次提交；当前分支合入了远端已发布的退货相关更新，没有回退既有版本。
|
||||
|
||||
列表、详情与导出区分商业来源与履约类型，正式关联返回商业单号和外接预订号；筛选本土散板覆盖独立与池来源。Admin 全量324文件/2631项测试和构建通过，部署资源含来源字段及筛选，页面入口HTTP 200。后端Jenkins1541项测试零失败、2项环境用例跳过；网关、拓扑及部署恢复25项合同通过。
|
||||
|
||||
初次Lastleg #239后真实HTTP暴露MySQL跨表排序规则不一致，来源筛选与关联投影返回S0500；最终版本分别比较来源字段，并将跨表客户/来货关联键转换到连接字符规则，#240后25项真实HTTP/导出断言全部通过：独立与池来源散板、池来源卡车、普通转运，列表/详情一致、商业单号/预订号精确及包含匹配、组合与空结果、分页、商业列表关联，以及1行XLSX四个来源字段与查询一致。配置客户额外验证读取成功、伪造customerId不扩大范围、平台接口拒绝；该客户散板样本为空，不声明非空跨客户隔离验收。
|
||||
|
||||
合入远端时发现空库基线被追加存量ALTER/回填，已将新增清点字段、索引及会话表收口到CREATE定义并恢复末尾PASS，原两项合同失败复验通过。本轮未执行数据库SQL、数据删除/重置或Nacos配置变更，既有履约状态未推进；只创建1份验收导出。真实浏览器交互及1920×1080人工截图仍待确认。证据：`baiyue-firstleg/reports/lastleg-business-source-test-20261009/`，保留首次失败说明、发布版本、最终容器、25项HTTP检查、导出和客户负向检查。
|
||||
|
||||
|
||||
## 拼车简化发布 TEST 验收（2026-10-09，完成）
|
||||
|
||||
用户授权发布 TEST 后端与 Admin，并要求真实 HTTP 联调及 1920×1080 页面点击验收。Lastleg `baiyue-firstleg-lastleg-service #236` SUCCESS，提交 `c4a7c2a22d92c58bd613f1d906a37bce2fe1ca84`，容器健康；流水线1518项测试，0失败、0错误、2跳过。Admin `admin-web-test #537` SUCCESS，提交 `826d444afa2d6e23a6bc7d5f3b2cae13318cd824`，容器与健康检查通过。本地前端321文件/2603项测试、类型检查与构建通过，后端52项定向测试及5项路由合同通过。本次未修改 SQL、Nacos 或 Gateway，未发布灰度。
|
||||
|
||||
真实 HTTP 创建专用车次 `TR-3E5258E2D00F4AFF`、关联排车单 `DS-WH-20261009-615169`，绑定后自动将占位卸货站匹配为 `ACY2 / FBA:ACY2`。随后在 TEST Admin 实际点击车次详情→发布拼车余位，逐键填写测试预计重量1000kg、体积2m³（默认1托位），一次确认完成容量保存和发布，生成 `FO-2108468322505900034`。截止时间自动采用计划发车时间，联系人与说明选填并默认收起；1920×1080、缩放100%截图确认窗口、输入项和提交按钮可见。
|
||||
|
||||
实际点击“查看需求池发布”后显示接单中及29托位/17000kg/88m³余位；“登记意向”可打开且卸货站列表包含ACY2，未额外提交客户意向。独立HTTP复核：planValid=true、状态OPEN、canCreateInquiry=true，默认可接运力列表及管理列表均仅1条对应发布；调度和理货审核均PENDING、车次仍PLANNED。专用HTTP会话已注销，用户浏览器会话保留。此验收覆盖简化发布与意向入口，不代表装车、发车或结算闭环验收。
|
||||
|
||||
证据位于 `baiyue-firstleg/reports/fleet-simple-20261009/`：`http-evidence.json`、`post-ui-http.json`、`created.json`，以及 `publish-dialog-1920x1080.jpg`、`published-offer-1920x1080.jpg`、`inquiry-acy2-1920x1080.jpg`。自动填充工具未保留数值时改用逐键输入成功；容量及发布写入均由实际页面点击完成，HTTP后置仅查询复核。
|
||||
|
||||
## 五项持续灰度验收（2026-10-09，进行中）
|
||||
|
||||
用户要求新批次整单闭环、PDA、船期来源、异常和版本统一验收；随后明确先用H5，真机在H5通过后另行确认。批次`gray-five-checks-20261009-150524`记录实际灰度镜像及容器状态，17个业务容器运行健康；停止的历史blue/green容器不混入运行健康计数。工作区其他未发布车次修改未纳入验收版本。
|
||||
|
||||
灰度TAX_REFUND、ROOT_FIRST新客户/根子单主链1332/1332通过、762个不同请求，最终VERIFIED；4项外部供应商缺口保留，不代表船司自动查询通过。双客户H5独立样本准备293项通过；实际海外PDA H5登录/仓绑定、任务列表与刷新保留上次作业标记、调度未审门禁、错码拒绝通过。调度审批后客户A拣货1箱成功，同车客户B未拣，整车发车正确阻断。
|
||||
|
||||
H5发现并在当前工作区修复：错误提示残留、目的仓码误当托盘码选择首项、错码保留旧选择及重复/歧义托盘反馈；退货收货4个尺寸/重量输入补提示。海外PDA214项测试及H5构建通过，尚未发布，正在本地H5连接灰度复验。客户B、整车发车、国内PDA H5、跨客户预约衔接、财务对账及外部来源核实仍未完成，不宣布五项全部通过。证据目录`baiyue-firstleg/reports/gray-five-checks-20261009-150524/`，含`flow.json`、`runtime-baseline.json`、`progress.json`和`h5-pick-a.png`；专用账号保存在仓库外配置目录，未写入文档。
|
||||
|
||||
|
||||
本批后续H5补验：本地修正版连接灰度，目的仓码拒绝、正确托盘清除旧错误、错码清空旧选择、客户B正式拣货1箱、已完成托盘重复扫码拒绝均通过；两客户现在各已拣1箱，整车仍被“请在平台确认本车实际装载”门禁阻止。截图`h5-fixed-repeat.png`。此证据是本地修正版H5＋灰度真实接口，线上PDA仍未更新；前述客户B未拣状态已被此补验更新，其余待验项继续保留。
|
||||
|
||||
本批第二轮补验：本批合成货物经正式装载确认及理货审核后，修正版海外PDA H5完成整车发车；两排车均DEPARTED、各实发1箱，车次IN_TRANSIT。两派送以明确标识验收用途的合成签收文件完成DELIVERED，同键重放版本稳定，不代表物理货物已实际运送。车次财务唯一两客户各30 CNY、合计60 CNY，无实收；分别生成/审核/出账REC-261009-0001、0002，客户A在1920×1080灰度Client页面确认，客户B真实HTTP确认及重放稳定；两客户读取对方账单均FIN_404，应收30、实收0、未收30保持不变。国内PDA H5登录义乌仓成功，但待拣0项，尚需新待拣任务，不能计作国内作业通过。
|
||||
|
||||
船期来源重新以灰度运行事实核对：Integration报告MATSON/SML/ZIM/EMC/HEDE均enabled/configured/READY，COSCO平台策略仍为人工；10个当前任务共76条节点，仅FIRSTLEG 10及MANUAL 66，实际供应商节点0。旧验收报告的4项外部缺口不能直接等同当前缺配置，已向用户索取真实在途柜号/提单号及船公司作查询验收。证据同批`live-provider-status.json`、`carrier-policies.json`、`carrier-source-detail.json`。当前只证实配置和人工来源，不宣布自动查询成功。
|
||||
|
||||
本批国内H5补验：增加显式`--prepare-domestic-pda-h5 true`准备边界，57项脚本合同通过；灰度准备301项通过但报告明确`fullAcceptance=false/PREPARED_NOT_VERIFIED`。新柜TSTU1599289在灰度国内PDA H5领取，错码拒绝、正确箱码即时拣1箱、重复扫描数量不增；五类标识QA用途的合成图片及封签号保存、刷新恢复成功，H5提交装柜完成后服务端taskStatus/workflowStatus均COMPLETED。原2箱准确形成1箱LOADED来源＋1箱REMAINDER，数量守恒。图片仅用于上传/证据接口验收，不证明真机相机或真实实物装柜；打印/设备广播仍按用户后续真机确认范围保留。证据同批`domestic-h5-preparation.json`、`domestic-before-complete-task.json`、`domestic-before-complete-evidence.json`、`domestic-after-complete-task.json`、`domestic-after-complete-tree.json`。
|
||||
|
||||
## 预约管理灰度发布（2026-10-09，完成）
|
||||
|
||||
用户明确授权灰度发布、已列明的结构及权限SQL，以及两个固定版本临时发布分支。后端PR25、Admin PR18合并后，源码树分别与TEST验证过的`7fd7699f6`、`73c29f5`完全一致；未纳入随后新增业务改动，发布分支已删除。本地工作分支未切换。
|
||||
|
||||
Lastleg `baiyue-firstleg-prod-lastleg-service #13`、Firstleg `baiyue-firstleg-prod-firstleg #14`均以`f60f44793f28`发布SUCCESS；复用已验证测试、保留测试编译。Admin `admin-web-prod #26`以`f9dd30b8b9c6`发布SUCCESS，容器健康检查通过。未部署其他服务或修改Nacos/Gateway。
|
||||
|
||||
执行前再次核对两张预约表均0条、权限编号和代码均未占用。仅ALTER预约主表及明细到当前13/9列和索引；无DROP TABLE、TRUNCATE或业务数据回填。新增预约读取/删除权限5107280/5107281，授予唯一现有平台管理员角色，推进1个相关主体权限版本；后置结构、权限及授权2条检查通过。
|
||||
|
||||
灰度真实HTTP验证登录、权限、到港日历、预约日历、入仓候选均成功；42天范围到港10条、预约0条。内置浏览器已以平台管理员验证预约菜单、真实日历和3条折叠预览（6条当天显示“还有3条”），未将TEST样例复制到灰度，未在灰度重新创建/删除业务预约。TEST中的写入闭环证据仍有效，灰度本次证据仅为发布及读取/页面冒烟范围，不声明全系统回归。
|
||||
|
||||
证据：`apps/admin-web/output/appointment-gray-release/`的`jobs.json`、`sql-postcheck.txt`、`http-postdeploy.json`、`preflight.json`、`gray-calendar.png`。应用暂不支持附加该Gitea PR链接，两个PR本身已正常合并。
|
||||
|
||||
|
||||
## 车次卸货站匹配修复灰度 Admin 发布（2026-10-09）
|
||||
|
||||
用户明确要求灰度更新并授权创建发布分支、合并后发布。PR #17（html/admin-web）仅包含 `TripLoadingPanel.vue` 与 `TripsBehavior.test.ts`，由 `fix/fleet-destination-gray-20261009` 合入 `main`；合并提交 `76a63070c5b6de4c187b9e29fd066c3516058dde`。未合入 TEST 分支的日历等其他差异，当前本地分支与未提交文件保持不变。
|
||||
|
||||
@@ -33,6 +33,15 @@
|
||||
|
||||
## 3. 发布与余位
|
||||
|
||||
### 页面发布操作简化（2026-10-09）
|
||||
|
||||
车次关联排车单时，在同一事务按真实货物目的地标识自动补齐卸货站；去重，不按同名合并，不改变已有有效站点顺序与索引。仅新车默认的“待确定卸货点”占位由真实目的地替换；外接预订路线门禁、缺失目的地拒绝与绑定变更后的重新审核继续生效。多目的地的行驶顺序仍由调度在车次计划确认。
|
||||
|
||||
车次“发布拼车余位”使用1080px居中窗口，同窗展示计划容量与交货截止；唯一匹配卸货站直接显示，不重复选择。已有计划数值自动带入，只补缺失的预计重量、体积并核对托位；尚无可靠实托测量字段时不拿计费重量或零值填充。交货截止默认计划发车时间，可提前；公开联系人与交货说明收起为选填，不将司机联系方式自动公开。
|
||||
|
||||
“确认发布”依次复用容量确认、发布信息保存、发布/恢复接口，传递各步最新版本，保留服务端权限、容量、状态及幂等检查；已有有效且未编辑的容量直接复用。保存草稿与发布不再要求两次点击。发布失败不宣称成功；未知发布结果保留原键续试，已成功的保存步骤不重做。发布完成提供“查看需求池发布”。暂停与关闭继续显式确认。尚未自动匹配的车次可在同窗“按货物补齐卸货站”，不能自由输入标识绕过货物来源。
|
||||
|
||||
|
||||
发布由有调度管理权限的用户在车次详情执行。前提：车次PLANNED，已分配可用车辆和司机，有真实起运仓及规范卸货站，发车/交货截止有效，容量计划有效。发布不替代调度审核、司机资质门禁或发车前理货审核。
|
||||
|
||||
本轮不新增“车牌司机尚未落实的虚拟运力”模型，沿用已分配资源的现有车次。计划容量或任何必须数据未就绪时给出具体阻断原因，不能以车型名字推算30托。
|
||||
@@ -76,6 +85,8 @@
|
||||
|
||||
唯一桥表`ll_fleet_pool_order_link`以booking_id唯一，保存客户、business_type、商业单ID/业务号和桥状态；来货生成后再绑定唯一incoming_no和lastleg_order_id。预订DTO商业号来自桥投影，不在两处维护可写副本。登记来货由现有FleetIncomingAdapter创建唯一WarehouseTransfer及真实尾程来源，并在同事务反绑商业单；客户、目的地或来源不符则回滚，不产生第二张尾程单。
|
||||
|
||||
尾程订单列表、详情与导出通过同客户、同尾程单的正式关联展示商业来源：池来源为“本土散板/本土卡车 · 拼车需求池”，独立散板为“本土散板 · 独立下单”，未关联商业单的外接来货为“仓储转运 · 外接来货”。`orderType` 继续表示履约类型，不改写为商业类型。`businessSource` 返回商业类型、来源中文说明、关联商业单号及外接预订号；缺少关联显示“—”，禁止解析备注。`businessType` 筛选本土散板时覆盖独立与池来源两条路径；商业单号和预订号支持服务端包含匹配。Admin 商业单号仅在具备目标列表权限时链接到带该单号筛选的既有本土业务列表，池来源继续从“承运安排”查看。
|
||||
|
||||
实托数与托位分开：询价提供可空的预计实托数；US_TRUCK确认前必须有正数预计实托数，不能拿palletSpaces当palletCount。预计箱数同样允许未知，确认前须补完整真实预报；不以0或1伪造未知。实收时以去重后的真实仓库托盘数记录实际实托，按核准每托占位合计记录托位。商业单预算仍是独立可空预算，不自动写入成交金额。
|
||||
|
||||
池询价未采集柜型或是否委托打盘服务，商业桥须将这两项保留为未知：卡车/散板的`containerType`及散板的`palletRequired`为null，不套用40HQ或YES。实托数、占用托位及实际托盘存在均不能证明客户委托打盘；Admin/Client列表和详情将未知显示为“—”。响应允许空值或省略空字段，详情经summary承载；普通独立Create/Update请求的必填、枚举及默认规则保持原合同。
|
||||
|
||||
+21
-1
@@ -85,11 +85,31 @@
|
||||
|
||||
### 客户订单列表的分页与待办读取
|
||||
|
||||
- 客户订单首页使用 `GET /api/merchant/v1/orders/workbench`，客户范围只取认证上下文，权限为 `merchant:order:list`。接口一次返回当前页、筛选后总数、全部/待费用确认/待上传报关资料/草稿四项数量及该客户完整渠道名称选项；不能先取前 200 条再在浏览器分页或统计。
|
||||
- 客户订单首页使用 `GET /api/merchant/v1/orders/workbench`，客户范围只取认证上下文，权限为 `merchant:order:list`。接口一次返回当前页、筛选后总数、全部/待费用确认/装柜完成/已报关/已清关/已排车/派送中/派送完成/待上传报关资料/草稿十项数量及该客户完整渠道名称选项；不能先取前 200 条再在浏览器分页或统计。
|
||||
- Order 在数据库内应用入仓码或 SKU、收货仓、渠道、目的仓类型、快递单号、创建时间、当前状态及待办筛选。草稿排在前面，同组按创建时间和订单 ID 倒序稳定分页；默认每页 10 条，上限 200 条。`DRAFT/CANCELLED` 是订单交易状态在客户读模型中的直接展示，不新增履约推进节点；默认列表排除已取消单。
|
||||
- Firstleg 通过受内部服务令牌保护的 `/internal/firstleg/v1/inbounds/unified-orders/workbench-filters` 提供当前客户匹配的履约和待办订单范围。费用待确认只取最新费用版本的未确认 `SENT`；报关待上传取最新已完成装柜计划、有效货柜及尚未上传齐当前客户退税入仓码资料的范围，不受同柜其他客户未上传影响。查询不创建报关记录、不更改船或柜、不跨 Schema 读表。
|
||||
- 翻页、换每页数量和筛选均重新请求服务端；快速切换时旧响应不得覆盖新页。筛选数量随当前条件计算，资料或费用确认后重新读取。分页响应不完整或依赖服务失败时明确报错，不能回退旧查询或显示成功的空列表。
|
||||
|
||||
### 客户头程订单履约分类
|
||||
|
||||
- 分类不是新增订单主状态。当前分类优先级为装柜完成、已报关、已清关、已排车、派送中、派送完成，采用已确认的最高当前进度；费用确认、报关资料上传是并行待办，可以与履约分类重叠。分类数量随当前查询条件计算，不从当前页推算。
|
||||
- Firstleg仅按客户实际装载片段读取有效货柜：装柜计划和实际拣货完成才算装柜；报关聚合`COMPLETED`才算已报关；目的港标准节点`PICKUP_READY`存在实际时间才算已清关。上传、回执确认、正式申报、预计时间和较晚船节点不能补造缺失清关事实。
|
||||
- Lastleg通过`POST /internal/lastleg/v1/customer-order-progress`只读返回认证客户来源订单的尾程进度。Order使用内部服务令牌调用，公网Gateway不公开该接口，不跨Schema联查。该查询依赖Lastleg可用，失败明确报错，不返回假的零数量。
|
||||
- 已排车取正式排车单`PENDING_DEPARTURE/PICKING/READY_TO_DEPART`的有效货物；预排草稿、取消排车不计。未收货托盘按计划分配来源，实收托盘按实际库存与本次拣货还原所有来源，混托不能用代表订单号归属整托。
|
||||
- 派送中必须有`DEPARTED + departAt`、关联出库`OUTBOUNDED`及对应目的地派送单`WAIT_DELIVERY/DELIVERING`；生成派送单不表示开始派送。取消、拒收、待退回及退回分支不伪装为正常派送中，原运输事实留在详情。
|
||||
- 分批履约返回`partial`，列表显示“部分装柜完成/部分已报关/部分已清关/部分已排车/部分派送中”。根订单合并自身及全部有效子单进度，子单继续独立展示；未同步尾程片段不能算整单完成。派送完成只认Order既有可信完成门禁，不凭某张派送单签收推定根订单完成。
|
||||
- 工作台响应`progress`与当前页订单一一对应，未到装柜阶段返回`none`并显示“—”；列表及导出保留当前订单状态并单独展示履约进度。历史节点仍由详情中的真实运输片段承载。
|
||||
|
||||
本次列表交互以用户提供的分类栏截图为依据：横向可滚动分类、计费待办角标、履约分类括号数量和右侧工具栏。截图未覆盖的“派送完成、上传资料、草稿”沿当前入口追加，履约进度列用于区分主状态与客户进度。详情、编辑、计费确认、资料弹框的承载方式沿现有实现，本次不改变。
|
||||
|
||||
列表交互核对范围：
|
||||
|
||||
| 页面/操作 | 原型依据与承载 | 实现口径 |
|
||||
|---|---|---|
|
||||
| 头程订单列表分类 | 用户提供分类栏截图：列表内横向滚动，计费角标、履约括号数量 | 按截图次序展示七个入口，随后保留完成、资料和草稿；筛选重新请求服务端 |
|
||||
| 列表状态展示 | 截图保留当前订单状态列；已确认方案补充履约进度 | 主状态不改义，新增可选履约进度列，部分事实明确标注“部分” |
|
||||
| 订单信息导出 | 原列表工具栏按钮与CSV下载承载 | 同步导出主状态及履约进度，不新增弹框 |
|
||||
|
||||
### 履约主链
|
||||
|
||||
```text
|
||||
|
||||
Reference in New Issue
Block a user