优化

2026-10-19 17:56:33 +08:00
parent c116bcfe8a
commit 94bbdea386
15 changed files with 1865 additions and 4 deletions
@@ -17,6 +17,17 @@
 - 禁止在 `apps/*/`、`baiyue-firstleg/` 及业务模块内部新增 `.codex-temp/`、`.codex-tmp/`、`worktree/` 或类似项目副本。遗留目录须先确认没有运行进程和唯一证据，再按精确路径清理。
 - 端口冲突通过停止已知旧进程或指定其他端口解决，不得复制项目。普通验证应直接覆盖当前未提交修改，不为获得“干净目录”绕开真实变更。
 ## 本机重型检查与多对话限流
 - Windows 本机的测试、类型检查、构建、依赖安装和 Maven 命令统一经 `baiyue-firstleg/scripts/local-check.ps1`（PowerShell 7）执行。锁位于当前用户 `%LOCALAPPDATA%/Chongchong/LocalChecks/`，与工作目录和对话无关；同一用户下使用该入口的任务同时只有一个执行，等待者每 15 秒提示占用。它是入口级互斥，不拦截绕过入口的命令，也不会接管已经运行的任务。
 - 在工作区根使用：`& ./baiyue-firstleg/scripts/local-check.ps1 -WorkingDirectory ./apps/admin-web -Label 'Admin typecheck' -Command @('pnpm', 'typecheck')`。定向 Vitest 示例：`-Command @('pnpm', 'exec', 'vitest', 'run', 'src/目标.test.ts')`；后端示例：`-WorkingDirectory ./baiyue-firstleg -Command @('mvn', '-pl', '目标模块', '-am', 'test-compile')`。参数使用数组，不拼接命令字符串。
 - 查看占用：`& ./baiyue-firstleg/scripts/local-check.ps1 -Status`。默认最多排队 900 秒（`-WaitSeconds`），执行最多 1200 秒（`-TimeoutSeconds`）。排队超时退出 75 且不启动检查；执行超时退出 124 并回收本次进程树；其他情况透传命令退出码。锁由操作系统文件句柄维护，不删除锁文件抢占。正常结束、超时和包装器强制退出均由 Windows Job Object 回收本次后代；不按 Node/Java 进程名清理其他任务。
 - 子进程默认设置 Vitest 最多 2 个 worker；Node 单进程堆上限 2048MB；Java 单进程堆上限 1536MB、可见处理器 2 个。直接运行 `node --test` 时自动补 `--test-concurrency=2`；直接运行 Maven 时补 `-T 1 -DforkCount=1 -DreuseForks=true`，拒绝重复指定这些并发参数。嵌套 shell/自定义脚本不得另行提高并发、覆盖限制或并发启动重型任务；经包管理器间接调用 Node 内置测试时，在该测试命令中显式保留 `--test-concurrency=2`。这些是每进程限制，并非整个进程树的总内存限额。
 - 前后端全量入口 `backend-full-regression.ps1`、`frontend-full-regression.ps1` 执行时整批占一个名额，DryRun 不占用。已在入口保护下的批次执行原始命令，不重复申请锁；入口会拒绝嵌套调用，避免互相等待。
 - 每个任务先完成必要的定向检查；批次收尾再统一执行应用要求的全量门禁，不因排队取消必要验证。复用结果前核对命令、目录、相关源码/依赖/配置均相同；验证期间相关输入变化则作废重跑。入口仅保存最近一次执行摘要，不自动计算代码快照、不自动跳过测试，也不保证先来先执行。
 - 本机 `owner.json`、`last-result.json` 仅保存检查名称、目录、工具、PID、时间和退出码，不保存命令参数、凭据或测试输出；名称不得包含秘密。摘要不是业务/部署事实来源。无需凭据，不访问网络、数据库或部署环境；被包装命令原有的网络/写入能力及授权要求不变。
 - 只读检索和互不冲突的编辑可并行；开发服务按应用复用已有实例，不纳入短任务队列，也不通过本入口启动常驻服务。已有运行任务由所属对话收尾；本入口不自动终止它们。
 ## 当前开发阶段
 - 项目尚未上线，没有需要兼容的生产存量数据、线上客户端或已发布接口版本；所有代码与契约直接收敛到当前确认目标，用户确认上线或存在不可变外部契约后才重新建立版本兼容和升级规则。
@@ -219,6 +219,8 @@
 `density-actions` 使用 `gap` 管理间距，并将 `--cc-list-action-sibling-margin` 设为 0；`DataTable` 通过该变量保留未接入按钮的默认 8px 左边距。不得将两份间距叠加，也不以更强选择器在页面逐个覆盖。
 纯文字行操作由 `adminTextActions.css` 统一将按钮横向内边距和组间距减半：每侧 5px、组间距 3px（随公共间距变量缩放），相邻文字间留白由 26px 收紧为 13px。描边操作继续使用原间距；页面不单独覆盖文字操作间距。
 ### 防止维护退化
 1. **同一通用外观只有一个实现。** 已由公共类接管的按钮配色、页签高度、信息表边框或弹框内边距，删除原页面声明，不能保留两套后再增加优先级或 `!important`。
@@ -8,12 +8,16 @@
 ## 业务域文档
 - [业务快速索引](业务快速索引.md)：按关键词检索跨端代码入口与业务边界；先查根 AGENTS.md 短路由，按需读取命中行。
 - 终端业务细则：[Admin](../apps/admin-web/docs/business-index.md)、[Client](../apps/client-web/docs/business-index.md)、[海外 PDA](../apps/pda-overseas-uniapp/docs/business-index.md)；先从各应用 AGENTS.md 短表定位，行为变更再核对受影响条款。
 - [订单与客户](订单与客户/README.md)：登录认证、客户与企业、权限、头程订单和客户工作台。
 - [入库测量与计费](入库测量与计费/README.md)：预约取货、到仓收货、箱码与箱唛、测量、尺寸策略、计价和入库费用。
  - [Firstleg 按需业务索引](../baiyue-firstleg/firstleg/docs/business-index.md)：服务代码入口及测量、计价、装柜、PDA 资源结算细则；先读服务 AGENTS，再查受影响条款。
 - [国内货柜履约](国内货柜履约/README.md)：分柜与同柜、智能排柜、订舱、拖车、PDA 拣货、装柜、报关和国内出仓。
  - [船期日历功能规划](国内货柜履约/船期日历功能规划.md)：渠道、周模板、单次船期、收货截止时间和按渠道货量统计的独立日历规划。
 - [海外仓业务](海外仓业务/README.md)：船节点、海外接柜、入仓、库存、托盘、换标、转运、废弃、退货、排车、PDA 出库、派送、异常退回、客户回访、一件代发及海外本土业务。
  - [Lastleg 按需业务索引](../baiyue-firstleg/lastleg-service/docs/business-index.md)：服务代码入口及事件、查询、履约约束；先读服务 AGENTS，再查受影响条款。
  - [排车列表统一作业改造契约](海外仓业务/排车列表统一作业改造契约.md)：五阶段排车、一单一趟、跨客户同车、派送安排及四块排车详情的当前改造入口。
  - [排车流程修复规划](海外仓业务/排车流程修复规划.md)：取消释放、派送状态、换标全托、合托来源和前端草稿的修复边界、分工及回归要求。
  - [采购订单样品履约流程变更需求](海外仓业务/采购订单样品履约流程变更需求.md)：采购样品购买、装箱、面单、交寄、国内核费与寄客户的变更入口。
  - [船节点标准化契约](海外仓业务/船节点标准化契约.md)：统一船司原始状态、标准节点、预计/实际时间、异常事实、还柜停止规则和新增船司接入门禁。
@@ -41,6 +45,9 @@
 以上文件继续保留，分别用于历史现状、操作说明和方案追溯；开发规划、进度、门禁和验收记录也按业务域保留，不再与当前节点总表同步改写。
 - [跨区域认证与服务通信契约](跨区域认证与服务通信契约.md)：统一账号、国内/海外 Token、双区域 API、JWKS、Outbox/Inbox 与服务身份边界。
 - [双区域部署与 Nacos 规划](双区域部署与Nacos规划.md)：开发/测试同机共置、生产国内/海外独立控制面、Nacos、数据库及 Event Bridge 部署边界。
 ### 通用规则与专项入口
 - [平台、客户层级与权限契约](平台客户层级与权限契约.md)：平台/客户两级产品语义、列表包含详情的只读权限和跨层同步要求。
 - [统一订单主状态与操作契约](统一订单主状态与操作契约.md)：统一订单状态、操作编码、内部状态映射和可信履约回传边界。
 - [Admin/Client 前端原型还原验收规则](Admin-Client前端原型还原验收规则.md)：页面操作承载方式、视觉还原、响应式检查和验收证据要求。
@@ -49,7 +56,7 @@
 - [Admin 国内仓样式核对记录](Admin国内仓样式核对记录.md)：7 个菜单、关联详情与浮层的范围、样式复核和验收证据。
 - [Admin 货柜管理样式核对记录](Admin货柜管理样式核对记录.md)：订舱、拖车、送柜报关、清关提柜入口及共享组件边界。
 - [Admin 海外仓样式核对记录](Admin海外仓样式核对记录.md)：海外仓 10 个菜单、独立详情、作业弹框和共享组件显式接入边界。
- [AI 工程执行与协作约束](AI工程执行与协作约束.md)：工作区、依赖、Git、部署、数据库、质量门禁和独立任务协作规则。
+- [AI 工程执行与协作约束](AI工程执行与协作约束.md)：工作区、依赖、Git、部署、数据库、质量门禁、本机多对话重型检查限流和独立任务协作规则。
 - [数据库中文注释维护规范](数据库注释维护规范.md)：数据库注释口径、职责、迁移流程、自动门禁与实值验收要求。
 - [数据库版本迁移与 Jenkins 自动发布方案](数据库版本迁移与Jenkins自动发布方案.md)：两人团队自动迁移规划；统一工具入口、自动编号、开发/测试/生产执行分工、单服务迁移范围、漏写迁移检查、Flyway 校验、失败候选修订、发布证据保留、带数据升级演练及实施顺序。
 - [数据库迁移操作手册](../baiyue-firstleg/deploy/sql/数据库迁移操作手册.md)：开发者和发布执行人日常使用说明；包含新建、检查、生成清单、测试执行、生产晋级、失败处理和维护规则。
@@ -2,6 +2,10 @@
 本文件按需检索，不作为启动必读文档。以下路径均按工作区根目录或表内注明的应用源码根目录起算，不相对于 docs/。
 Firstleg 代码从 `baiyue-firstleg/firstleg/AGENTS.md` 的短表定位；状态、计价、装柜和 PDA 资源规则按需查 `baiyue-firstleg/firstleg/docs/business-index.md` 对应条款，不全文加载其他业务。
 Admin、Client、海外 PDA 从各应用 AGENTS.md 短表定位，行为变更按需查 [Admin 细则](../apps/admin-web/docs/business-index.md)、[Client 细则](../apps/client-web/docs/business-index.md)、[海外 PDA 细则](../apps/pda-overseas-uniapp/docs/business-index.md)；Lastleg 的事件、查询与履约细则见[服务业务索引](../baiyue-firstleg/lastleg-service/docs/business-index.md)，只读取受影响条款。
 架构/环境/部署查[测试环境单机部署与配置契约](测试环境单机部署与配置契约.md)；网关/Token/会话撤销/事件通信查[统一认证与服务通信契约](统一认证与服务通信契约.md)。下文旧区域服务路径用于定位现有实现，目标规则以这两份主契约为准。
 ## 常用说法与歧义分流
@@ -72,7 +76,7 @@
 美国各类预约统一总览、提柜/用车/送仓预约梳理：`docs/海外仓业务/美国预约管理统一总览与优化方案.md`（设计建议）；实际维护仍按下述来源模块进入。
 预约工作日历、多客户共车、中转分批后送、改期取消、重新预约和未定日期事项：先读 `docs/海外仓业务/预约工作日历V13变更说明.md`（正式业务规则与验收），再读 `docs/海外仓业务/预约工作日历开发协作契约.md`（接口与文件边界）；权威业务事实仍由下述来源模块维护。
-预约管理、预约列表、跨客户同仓送仓：Admin `apps/admin-web/src/modules/appointment-calendar/`，规则见 `docs/海外仓业务/README.md` 的“预约送仓”；送仓记录沿 Lastleg `inboundplan/`，到港沿 Firstleg `portschedule/`，区别于订舱级拖车预约。
+预约管理、预约列表、到港/排车/还柜/计划到仓四类日历：Admin `apps/admin-web/src/modules/appointment-calendar/`，当前入口与日期规则见 `docs/海外仓业务/预约工作日历V13变更说明.md` 的“2026-10-19 当前预约列表收敛规则”；原送仓业务仍从 `docs/海外仓业务/README.md` 的“预约送仓”进入。排车只取海外仓送往 FBA/客户仓的真实车次，区别于订舱级拖车和港口提柜。
 退货预报、签收、库存与合箱：Client `modules/overseas-warehouse/views/ReturnOrdersView.vue`、`ReturnInventoryView.vue`；Admin `modules/overseas-warehouse/pages/ReturnInventoryManagementView.vue`；海外 PDA `src/pages/return-receipt/return-receipt.vue`、`src/pages/return-packing/return-packing.vue`，API 与检查入口见 `apps/pda-overseas-uniapp/AGENTS.md`；Backend `lastleg-service/returnreceipt/`，执行规则先读 `baiyue-firstleg/lastleg-service/AGENTS.md`，详细接口与状态按需查 `baiyue-firstleg/lastleg-service/docs/business-index.md` 的退货入口，OpenAPI 为 `overseas-business-v1.yaml`。客户预报 → 平台审核 → PDA 签收 → 退货箱/SKU 库存 → 同客户合箱 → `delivery/` 退货出库；两个 PDA 页面均在 `src/pages.json` 注册，由 `src/data/overseas-workbench.js` 提供入口，真机验收另取证。派送异常退回仍归 `exceptionorder/`。
@@ -88,7 +92,7 @@
 | 客户头程订单批量导入 | 当前 Order 契约 | Client `modules/first-leg/views/FirstLegOrdersView.vue`、`api/firstLeg.ts`；Backend `order/` 的 `MerchantBatchImportService`、`MerchantWarehouseCatalogClient`、`MerchantPricingCatalogClient` 与 `order-v1.yaml`。中文 XLSX 模板按当前客户动态生成地址、全部有效仓库和渠道下拉；导入时重新校验动态选项与客户归属，最多 50 行，只创建草稿，支持部分成功或整批原子模式 |
 | 平台旧系统订单导入 | 当前 Order 契约 | Admin `modules/unified-orders/pages/UnifiedOrdersView.vue`、`api/unifiedOrders.ts`；Backend `order/` 的 `PlatformLegacyOrderImportService` 与 `/api/platform/v1/orders/first-leg/legacy-import`。固定归属启用客户“IT测试公司”，保留旧入仓码，按当前公共仓库和客户价格簿逐行校验，成功行进入待审核 |
 | 平台修改客户原始申报与履约渠道 | 当前 Order/Firstleg 契约 | Admin `modules/unified-orders/components/OrderDeclarationEditorDialog.vue`、`api/unifiedOrders.ts`；Backend `order/` 的 `OrderDeclarationUpdateService` 与 `order-v1.yaml`，通过 `ORDER_DECLARATION_UPDATED_V1` 同步 `firstleg/` 的 `OrderDeclarationSyncService`。只修改申报快照，不覆盖仓库/PDA 实测、测量审核、箱码或已确认费用；渠道变化额外校验分柜、同柜、装柜可逆性与重新计价，国内收货仓或中转仓变化必须重新下单 |
-| 脚本管理、全量验证与测试造数 | `baiyue-firstleg/scripts/AGENTS.md`、`baiyue-firstleg/scripts/README.md` | Backend `scripts/` 为仓库级入口，`scripts/admin-test-env-modules/` 为 Admin HTTP 内部模块；服务局部脚本留在 `<service>/scripts/`，不得散落到 `src/test/scripts/`；真实 HTTP、部署或环境写入仍须当前轮明确授权 |
+| 脚本管理、全量验证与测试造数 | `baiyue-firstleg/scripts/AGENTS.md`、`baiyue-firstleg/scripts/README.md` | 本机重型检查经 `scripts/local-check.ps1` 统一限流，规则见 `docs/AI工程执行与协作约束.md`；Backend `scripts/` 为仓库级入口，`scripts/admin-test-env-modules/` 为 Admin HTTP 内部模块；服务局部脚本留在 `<service>/scripts/`，不得散落到 `src/test/scripts/`；真实 HTTP、部署或环境写入仍须当前轮明确授权 |
 | 平台/企业 RBAC | 订单与客户契约；公共语义见 `docs/平台客户层级与权限契约.md` | Admin `modules/iam/`、`core/access/`；Client `modules/tenant-management/`；Backend `iam/`、`auth/` |
 | 消息中心与站内通知 | 触发业务的阶段/专题契约，收件箱以 IAM OpenAPI 为准 | Admin/Client `modules/notifications/`；Backend `iam/.../notification/`；生产者留在所属服务 |
 | PDA 拣货与柜级装柜证据 | 国内 PDA README、拣货原型、国内货柜履约需求确认 | PDA `pages/picking/`、`stores/picking.js`、`api/pda-loading.js`；证据以 `taskId + warehouseId` 进入任务专用 API，业务所有权固定真实 `containerBookingId`，不得按入仓单或客户拆分；上传以幂等键绑定包含文件内容的请求哈希，完全重放直接返回已有结果且不得重复上传 File；Backend `firstleg/`、`warehouse/`、`file/` |
@@ -118,7 +122,7 @@
 | 车辆管理、司机证照、保养加油、车辆维修/故障/救援/异常、外接货与车次 | `apps/admin-web/src/modules/overseas-master-data/AGENTS.md`、`baiyue-firstleg/lastleg-service/AGENTS.md`；原型范围有疑问时查 `docs/海外仓业务/车辆管理原型梳理与任务规划.md` | Admin `modules/overseas-master-data/`；Backend `lastleg-service/fleet/`，接口 `lastleg-service/src/main/resources/openapi/fleet-drivers-v1.yaml`、`fleet-trips-v1.yaml`、`fleet-vehicle-records-v1.yaml`；证照与运维照片存储查 `file/AGENTS.md` |
 | 拼车需求池、车次余位、销售拼车意向 | `docs/海外仓业务/内部拼车需求池首版开发契约.md`、`apps/admin-web/src/modules/overseas-master-data/AGENTS.md` | 复用 Lastleg Fleet 与本土业务；区分车次余位发布和客户订单，不从需求池生成第二套库存或费用 |
 | 国内出仓后船节点 | `docs/海外仓业务/README.md` | Admin `modules/port-schedules/`、`ocean-bookings/`、货柜详情；Backend `firstleg/portschedule/`、`integration-service/`；从确认国内出仓查询至目的港到达、提柜和还柜。节点按 `containerBookingId` 柜级聚合，跨区事件使用 `tenantId=0` 平台技术范围，不携带或校验客户 |
-| 海外出库、排车、派送、异常与回访 | 当前海外履约契约；缺陷修复边界查[排车流程修复规划](海外仓业务/排车流程修复规划.md) | Admin `modules/overseas-warehouse/pages/OutboundsView.vue`、`DeliveryOrdersView.vue`、`ExceptionOrdersView.vue`、`CustomerVisitsView.vue`；Backend `lastleg-service/dispatch/`、`delivery/`、`dropship/`、`exceptionorder/`、`customervisit/`；统一经 `gateway/`。异常单按 `PENDING → PROCESSING → COMPLETED` 流转，处理完成必须引用归属为 `OVERSEAS_EXCEPTION_EVIDENCE` 的证据；派送退回只从原出库拣货事实选择可退明细，退回海外仓时先把实收恢复到指定真实托盘/库位，再原子完成异常单并将派送置为 `RETURNED` |
+| 海外出库、排车、派送、异常与回访 | 排车改造查[排车列表统一作业改造契约](海外仓业务/排车列表统一作业改造契约.md)；既有缺陷修复查[排车流程修复规划](海外仓业务/排车流程修复规划.md) | Admin `modules/overseas-warehouse/pages/DispatchesView.vue`、`DispatchDetailView.vue`、`OutboundsView.vue`、`DeliveryOrdersView.vue`、`ExceptionOrdersView.vue`、`CustomerVisitsView.vue`；Backend `lastleg-service/dispatch/`、`delivery/`、`dropship/`、`exceptionorder/`、`customervisit/`；统一经 `gateway/` |
 | 海外业务费用来源与客户财务 | 当前实现查财务契约与统一认证与服务通信契约；阶段 0A—0E 开发再读 `docs/财务管理/海外仓费用统一接入阶段0技术契约.md` | 当前 V1 由 `lastleg-service/financefee/` 校验海外入仓、采购、美国卡车、本土散板和海外仓服务费，通过完整快照和 Outbox 直接投递 Finance 内部入口入池；阶段 0 目标改为收费身份/候选版本、Finance 接受或拒绝结果事件及版本化资金计划。必须沿代码确认落地范围，不把技术契约当成已实现状态；Client 仍只读取获准客户财务 |
 散货托盘码生成、打印与跨区传递：Admin `modules/loading-lists/components/PalletLabelPrintDialog.vue`；Firstleg `LoadingPalletLabelService`、`LoadingCompletedOutboxService`；Lastleg `LastlegSourcePalletMapper`、`InboundPlanService`。从各项目最近指引继续定位；散货 FBA 标签与一件代发实装托盘分别取各自冻结事实。
@@ -10,6 +10,8 @@
 ## 文档
 费用项目默认价格规则（2026-10-19）：平台公共项目可配置可空的 `defaultPrice`（CNY、非负、两位小数），不填表示人工录入，`0` 表示明确的零元默认价。入库与柜次费用仅在用户主动选择项目时带入；入库同时带入单价与金额，柜次带入金额，均允许人工修改。切换到无默认价格的项目时清除前项带价并回到零值待填；打开已有费用、切换供应商或保存业务费用不重新套用默认价。修改或清空项目默认价不追改已有费用，也不改变审核、发布与结算流程；本次不增加计费数量或条件报价。
 - [入库测量与计费 V2 需求确认清单（当前会议填写）](入库测量与计费V2需求确认清单.md)
 - [入库测量与计费需求优化版 V2：测量、计费、托盘入库主流程](入库测量与计费需求优化版-v2-测量计费入库主流程.md)
 - [入库测量与计费需求优化版：原型对照（上一版优化稿）](入库测量与计费需求优化版-原型对照.md)
@@ -19,6 +19,7 @@
 - 一级、二级菜单的名称、分组和顺序以当前确认原型及当前对话确认为准，唯一代码入口为 `apps/admin-web/src/core/navigation/adminNavigation.ts`。一级结构为首页数据看板、客户管理、国内头程、货柜管理、海外尾程、预约管理、车辆管理、海外业务、客户服务、财务管理、自营业务、通用、系统管理；二级菜单统一在该入口维护，实际显示继续由权限过滤。
 - 自营业务的经营总览、销量分析、库存分析、数据采集四个页面统一使用 `platform:self-operated-analytics:list`，包括任务详情只读和运行辅助查询；重试独立使用 `platform:self-operated-analytics:sync`，库存周转后台导出使用独立 `platform:self-operated-analytics:export`，下载中心创建、下载及重试均校验该导出权限和非代登录平台身份。IAM 菜单管理资源不替代上述实际读写授权，不能仅凭采集写权限打开只读页面。
 - 已实现菜单继续使用正式路由及服务端权限，不因改名、移动或仅调整菜单结构改变接口、状态和操作资格。当前原型未展示的既有入口通过 `hidden` 退出侧栏，正式路由和权限仍按现行合同管理；角色权限设置仍保留这些正式页面及操作的可分配权限。
 - 供应商列表按当前确认保留在“通用”分组，使用正式路由 `/suppliers` 与 `platform:supplier:list`，不因原型未展示而隐藏；新增、编辑及其他写操作继续使用各自独立权限。
 - 尚无正式页面的菜单不显示，不保留禁用占位或空分组，不接入原型假数据、虚构权限码或新增业务接口。后续功能实现时再核对正式页面、权限与服务端合同。
 ## 跨层同步
@@ -1,5 +1,95 @@
 # 测试环境单机部署与配置契约
 ## 列表操作文字间距减半 TEST Admin 发布（2026-10-19，已发布）
 所有已接入公共文字行操作的列表统一收紧按钮横向内边距与组间距：每侧10px改为5px，组间距6px改为3px，相邻文字留白由26px改为13px；字号、高度、业务动作及页面列宽保持。公共规则位于 `adminTextActions.css` 与 `adminDensity.css`，对应密度合同同步更新；以 Admin #647 为基线仅发布3文件，精确提交 `786f0d6b75c70a06f930b929e6f4887db82a8a9f`，固定标签 `admin-action-spacing-20261019-786f0d6b75c7`，保留已发布的供应商入口、ECharts与测量差异红字。
 Jenkins `admin-web-test #648` SUCCESS，精确检出、类型检查与构建通过；镜像 `admin-web-test:786f0d6b75c7`，镜像ID `sha256:920b5e2dc7d7e526325f2a05cc04497c7d16f95d2ff738598ce2e5d5244ddb62`，running / healthy。公网8项HTML/JS/CSS与容器SHA-256一致，已核对公共间距、供应商入口、图表及测量颜色规则；健康、订单、供应商及出车记录路由HTTP200。临时Job配置已恢复并核对原始SHA-256一致。
 定向5文件169项通过；本地按 `local-check.ps1` 的2 workers限制执行全量414文件3495项，全部通过，耗时629.44秒。本地 `pnpm typecheck` 与 `pnpm build` 均在规定的2048MB Node堆上限触发OOM，退出134，不能标记本地构建或类型检查通过；精确发布版本的CI构建已通过。视觉仍待用户1920×1080、100%截图确认。
 本次只发布Admin，没有发布后端、Client或PDA，没有执行SQL、修改业务数据、Nacos或账号权限。证据位于 Admin `.logs/admin-action-spacing-release-20261019/` 的 `manifest.json`、`checks.json`、`release-state.json`、Jenkins记录、`runtime-after.json` 及 `verification.json`。
 ## 测量差异红字 TEST Admin 发布（2026-10-19，已发布）
 测量弹框的10%差异提示、偏差说明及对比表非零差异文字统一使用红色；差异计算、提示阈值、警告背景、保存及审核逻辑保持。以 Admin #646 为基线，仅发布 `InboundMeasurementPanel.vue` 两处颜色声明及密度合同断言，共2文件；精确提交 `1b96ac128dcc6f0f45e8c1d39ea222485e4006c5`，固定标签 `admin-measurement-red-20261019-1b96ac128dcc`，保留已发布的ECharts及供应商入口。
 Jenkins `admin-web-test #647` SUCCESS，精确检出、类型检查及构建通过；镜像 `admin-web-test:1b96ac128dcc`，镜像ID `sha256:7e7f4242693f47460c09a68f54ef9c15d2592fe36df63abe8143526ad022727b`，running / healthy。公网6项HTML/JS/CSS与容器SHA-256一致，含测量差异红色声明；健康、订单、供应商及出车记录路由HTTP200，临时Job配置恢复并核对原始SHA-256一致。
 测量及密度66项定向检查通过。共享工作区全量使用8 workers、单例15秒测试期限运行，414文件/3485项中3481项通过、4项失败，均为在途 `SmartDispatchDialog.test.ts` 的3项DataCloneError及1项请求次数不符；工作区构建另受其他预约/排车测试Fixture缺失recordVersion阻断，均未纳入精确发布候选，不声称全量通过。视觉仍待用户1920×1080、100%截图确认。
 没有发布后端、Client或PDA，没有SQL、业务数据、Nacos或账号权限写入。证据在 Admin `.logs/admin-measurement-red-release-20261019/` 的 `manifest.json`、`release-state.json`、`checks.json`、Jenkins记录、`runtime-after.json` 及 `verification.json`；后续发布继续按实际运行版本核对。
 ## 出车记录 ECharts 精简统计 TEST Admin 发布（2026-10-19，已发布）
 当前出车记录使用项目既有 ECharts / vue-echarts 原生饼图、圆点图例和悬停数值，替代手写SVG；仍保留原有日期、目的地和币种分组。默认仅显示指标标题、主数值、四个饼图及短图例，日期图例按月日显示；页头“统计详情”按需展开完整图例数值、口径、出车汇总及成本，默认不再显示说明段落、重复系列标题、图例数值及底部成本行。多币种独立切换；顶部均价仍为最近统计日值，不混币种或简单平均日报价。
 发布以当时已成功运行的 Admin #645、`e2f9023156fe0fe1ce5a0abe5ca3bd8eb67492d4` 为基线，保留其已发布预约及费用改动；仅纳入8个本页、图表、导航、测试及矩阵文件，并恢复“通用 → 供应商列表”。精确提交 `61e9cfe196b4cf8befb75ee3366359adc4d1479c`，固定标签 `admin-trip-echarts-20261019-61e9cfe196b4`；没有创建或切换分支、工作树或项目副本，没有混入工作区其他未提交修改。
 Jenkins `admin-web-test #646` SUCCESS，耗时63.897秒，精确检出、干净类型检查与构建通过。镜像 `admin-web-test:61e9cfe196b4`，镜像ID `sha256:812e020a77631586bde685632179914ccf77fbc8f4ec280fc6194ef9d824d932`，容器 running / healthy。临时固定提交与完整SCM检出配置已恢复，原Job配置SHA-256一致。公网HTML、主JS、导航JS及本页JS/CSS共5文件与容器SHA-256逐项一致，健康页、供应商与出车记录路由HTTP200；公网模块包含ECharts Canvas配置、按需详情和精简样式，原SVG扇区、重复系列标题与常驻统计页脚样式已移除。
 自动检查：本页及密度合同38项、工作区类型检查/构建通过；工作区全量414文件/3444项中3442项通过，2项因5000ms超时失败，分别为海外出库退货SKU及入仓计划挂载测试。两文件随后以单worker独立重跑10项全部通过，未修改断言或超时配置；不将原全量命令标记为全部通过。组件测试检查ECharts配置与真实业务数据，不代替Canvas实际页面视觉；1920×1080、100%截图仍待用户确认。
 本轮只发布Admin，没有发布后端、Client或PDA，没有执行SQL、修改业务数据、Nacos或账号权限。证据位于 Admin `.logs/admin-style-echarts-release-20261019/` 的 `manifest.json`、`release-state.json`、`checks.json`、`jenkins-build.json`、`jenkins-console.txt`、`runtime-after.json` 及 `verification.json`。后续发布仍须以实际运行版本为基线，不能仅按分支HEAD覆盖固定标签中的本页与供应商改动。
 ## FBA新增预约与目的仓筛选 TEST 发布及真实HTTP验收（2026-10-19）
 用户明确授权发布本次Admin与Lastleg匹配版本到TEST并继续验收。范围为新增FBA预约入口、月视图4/5/6周自适应和目的FBA仓搜索筛选；普通客户仓未纳入。新增只读接口 `GET /api/platform/v1/last-leg/appointment-planning/cargo/destinations` 复用原Gateway通配路由及预约/尾程订单读取权限，不新增仓库管理权限、SQL、Schema或Nacos配置。
 Lastleg仅提交5个相关文件，精确候选 `a563f6385714cd2839751f9f4b7cb3a7b24c9d58`，固定标签 `appointment-dest-20261019-a563f6385714`。Jenkins `baiyue-firstleg-lastleg-service #368` SUCCESS，按该提交完整测试和打包；业务测试2949项、失败/错误0、跳过9，独立SQL语义测试51项通过。运行镜像 `lastleg-service:a563f6385714`，镜像ID `sha256:f18765f50b08d1a617fd5c4087c9039f2e8097fa3416926355b5af85eb7d22c5`，running / healthy。
 Admin本次14文件的功能提交为 `5a46198bf0d8923e1cfad64ecc3844472287d35f`。等待期间另一任务已完成Admin #644，因此最终候选以其实际运行提交 `d2f2ecf57a0f132ebb4cbafc3ce8d14550be0f0a` 为基线，保留10个已上线订单/出库文件，再合入本次14文件；精确提交 `e2f9023156fe0fe1ce5a0abe5ca3bd8eb67492d4`，固定标签 `appointment-fba-20261019-e2f9023156fe`。未创建或切换分支、工作树或项目副本，未强推已有分支，未纳入其他在途源码。Jenkins `admin-web-test #645` SUCCESS，检出与候选一致，类型检查和生产构建通过。镜像 `admin-web-test:e2f9023156fe`，镜像ID `sha256:7ac9ede4bdb10f0517e3ccbac6e892131d58119aa8d3fc5e93e672f79b337b8b`，running / healthy；临时固定提交的Job配置已恢复，原始XML语义一致。
 发布前真实探测曾发现目的仓选项接口HTTP200但业务码A0404，requestId `00afec57-3c9c-40c5-a2cf-f0f251121001`；保留为接口未发布时的失败证据，不按HTTP200判成功。发布后统一Gateway完整验收25项、Admin同源验收13项全部通过，逐请求核对HTTP、业务码、实际数据和完整响应体读取耗时；38项最慢588.87ms，无请求超过1000ms。覆盖完整目的仓选项、关键词组合、两页过滤、重置、空结果、非法目的仓拒绝、来源核对、预览、保存与详情回查、同键重放、同键异载荷及重复分配拒绝、未登录401与客户访问平台403。同源另回归到港/还柜、计划到仓和派送车次日历，月范围为2026-09-28至2026-11-02开区间。
 写入使用既有自动化测试货物 `AT308919F5D351FDD42AA5`，4箱、目的仓ABE4；新增待确认预约 `AP-20261019-007A8CED56CA`，计划当地时间2026-10-26 10:00—11:00，备注明确标记HTTP合成验收资料。5次预约写请求中只有首次产生新预约，2次原键重放返回同一预约，2次冲突写入被拒绝；详情、覆盖与货物资格回查确认仅一个有效预约、4箱未重复分配。记录保留供回查，未删除或重置。本轮证明平台内登记链路，正式FBA确认仍由原业务取得。
 公网HTML、入口JS/CSS、日历、创建面板及API分块共7文件与容器SHA-256逐项一致，另含健康入口和预约路由共9项通过，4个新增功能标记存在。本地预约与密度38文件/310项、构建、后端测试编译与13项定向测试、Gateway/部署/回滚17项合同通过。工作区全量413文件/3440项通过、1项其他车队弹窗超时，同文件单独3项复查通过，不合并描述为单次全量绿灯。人工1920×1080、100%截图仍待确认。
 证据：Admin `.logs/appointment-destination-release-20261019/` 的两端源码清单、Jenkins构建及控制台、`runtime-after.json`、Job恢复记录、`public-static-verification.json`；`.logs/appointment-destination-http-20261019/` 的 `probe-report.json`、`acceptance-report.json`、`same-origin-report.json`、原写入检查点及脚本。首次失败、拒绝场景和全部计时保留；自有平台/客户会话均已退出。本轮未执行SQL、配置发布、删除或重置，HTTP与资源验证不代替人工页面验收。
 ## 出车记录饼图与供应商入口 TEST Admin 发布（2026-10-19，已发布）
 用户确认四块统计均使用饼图，保留当前日期、目的地及币种分组，不改变后端统计口径；同时恢复“通用 → 供应商列表”，继续使用 `platform:supplier:list`，写操作权限独立。
 本轮以当时运行中的 Admin #642、`b92e5379bcc7196c034542087b6e9a6615f9ae71` 为基线，仅纳入8个出车记录页面、图表、导航、测试及矩阵文件；固定源码 `6738eae457195028855b2dd5c98561ca3e4dad5f`，发布标签 `admin-trip-pies-20261019-6738eae45719`。没有创建或切换分支、工作树或项目副本；未将其他预约、派送、散板及未发布远端改动混入本次发布，当前工作区仍保留这些在途修改。
 Jenkins `admin-web-test #643` 为 SUCCESS，实际检出上述精确源码，执行类型检查和构建；镜像 `admin-web-test:6738eae45719`，镜像ID `sha256:81a5e3566f99eef43f145c6b2cd49a37e2106d26530329327e5d9d86e36ed5a5`，容器 running / healthy。临时固定版本与完整SCM检出配置已恢复，原始Job配置SHA-256逐字节核对一致。
 本地工作区全量413文件/3435项测试、54项定向测试、类型检查与构建通过；精确发布由Jenkins单独完成干净类型检查与构建。公网HTML、主JS、导航JS及出车记录JS/CSS共5个文件与容器SHA-256逐项一致；健康页、供应商及出车记录路由均HTTP200。公网导航模块确认供应商不再隐藏，图表样式包含饼图与彩色图例，已移除原折线和排名条形样式。以上静态与HTTP检查不代替真实数据页面人工验收，1920×1080、100%截图仍待用户确认。
 本轮没有发布后端、Client或PDA，没有执行SQL、修改业务数据、Nacos或账号权限。证据在 Admin `.logs/admin-style-release-20261019/` 的 `manifest.json`、`release-state.json`、`jenkins-build.json`、`jenkins-console.txt`、`runtime-after.json` 及 `verification.json`。后续TEST发布须以实际运行版本为基线核对，不能仅凭分支HEAD假定本次固定标签改动已合入分支。
 ## 散板需求菜单 TEST Admin 发布（2026-10-19，已发布）
 用户最终确认本轮只发布菜单移动和改名；本土散板下单字段优化不进入本轮。以当时已成功发布的 Admin #639、`f7f6637c45ccc8fa4252dc99b98e9b6006a07a46` 为基线，仅加入5个菜单/路由标题/页面文案及对应测试文件，源码候选为 `763bd90d19cf372ce22e5c37b50e96125d5e5bf0`，固定发布标签 `admin-menu-only-20261019-763bd90d19cf`。未创建或切换分支、工作树或项目副本，未将工作区散板表单、派送、预约等其他未提交改动纳入发布。
 Jenkins `admin-web-test #640` 为 SUCCESS，实际检出与候选一致；当前 Admin 镜像 `admin-web-test:763bd90d19cf`、镜像ID `sha256:2e953cb75b8f3e1364387c38951ecb0c2b09ec7840348ad6566e2e51780f3144`，状态 running / healthy。Jenkins按精确提交完成类型检查与生产构建；固定版本与完整SCM检出只用于本轮，Job原始配置已恢复并核对完整语义一致。
 菜单由“车辆管理 → 拼车接货”调整为“海外业务 → 散板需求”，对应页面、页签辅助文案和返回入口同步改名；原路径、权限及业务功能保持。52项直接测试通过；公网与容器6项HTML/JS/CSS资源逐项SHA-256一致，另含健康与页面路由共8项检查通过；运行导航模块确认新入口位于海外业务，车辆管理下不再包含该入口。
 本轮未执行 SQL、未修改数据库或业务数据、未触发后端/客户端发布、未修改Nacos或权限配置。散板新增订单字段改造仅保留在工作区，不能将本次菜单发布视为该改造已上线。1920×1080、100%缩放的人工视觉验收仍待截图确认；静态资源与HTTP检查不代替人工点击验收。
 证据位于 Admin `.logs/menu-only-release-20261019/`：`manifest.json`、`release-state.json`、`jenkins-build.json`、`jenkins-console.txt`、`runtime-before.txt`、`runtime-after.txt`、`verification.json`。最初基于#638准备的候选在并行#639发布开始前未触发构建、未部署，随后重新以#639为基线生成并发布上述候选，避免覆盖其他已发布功能。
 ## 预约列表四类简化 TEST 发布（2026-10-19，已发布）
 用户本轮授权部署预约列表简化。恢复左侧月／周日历、右侧当天安排，仅保留到港、排车、还柜、计划到仓；实际到港优先、否则预计到港，加2个自然日带出默认计划，人工计划优先且保留原冻结门禁。排车来源限定海外仓出库派送用途（DELIVERY），上门取货（PICKUP）排除；同一实际车次只显示一次。原业务精确深链保留，日历通用新增和全局工作待办入口取消。
 | 发布单元 | Jenkins | 精确源码 | 实际镜像标签 | 状态 |
 |---|---|---|---|---|
 | Firstleg | baiyue-firstleg-firstleg #500 | aa195cef66b347b78ae3c34584b67a098bd828c4 | aa195cef66b3 | SUCCESS；running / healthy |
 | Lastleg | baiyue-firstleg-lastleg-service #364 | fafcf7501458f41d972ad10a99df627d011bbd86 | fafcf7501458 | SUCCESS；running / healthy |
 | Admin | admin-web-test #638 | 05cf82dbbcaaa8e333787a6f169034cb96ee0ea2 | 05cf82dbbcaa | SUCCESS；running / healthy |
 Firstleg镜像ID为`sha256:0d4e6781bc30e2655793bb0597dcba5ca10ca0fd20500af8c90d3dbf5914198a`；Lastleg为`sha256:cddb55e3384a9a4fb8906a2d183640c852af2abba92a8d566701cd3f8d1d4978`；Admin为`sha256:4e038b0639fde0f26ea384be063e6f733b5d3209535b089b2c639542366d9575`。Lastleg先由#363发布基础接口，#364追加排除取货用途；两次均按固定提交执行完整测试。Admin #637在轻量SCM检出时失败，未进入构建或更新容器；改用临时完整SCM检出后#638成功。固定提交及完整检出只用于本次发布，Job完整XML语义已恢复并核对原配置一致。
 验证：Admin工作区全量405文件/3372项、精确发布候选预约模块36文件/260项、类型检查及构建通过；直接受影响后端与Gateway、部署、回滚、Mapper合同通过。Jenkins Firstleg为1669项、失败/错误0、跳过9；最终Lastleg业务测试2938项、失败/错误0、跳过9，独立SQL语义测试51项全过，两个后端均SKIP_TESTS=false。发布门禁中既有取货测试Bean/API数量、输入提示/弹框密度/页签结构及空库SQL归属与表数问题已作最小源码修正；日历不新增Schema，未对环境执行SQL。
 发布后通过测试Gateway及Admin同源统一入口分别只读验证：到港/还柜来源GET、计划到仓查询POST、车次日历GET均HTTP200/业务200；本次42天窗口分别读取394个来源柜、234条还柜、408条整柜到仓投影及151个有地点资料的车次。POST为查询，业务写入0；仅创建并退出本次自有认证会话。公网健康页、预约路由及60个入口引用资源HTTP200；HTML、主JS/CSS和预约日历JS/CSS共5文件与部署容器逐项SHA-256一致，8项四类日历代码/样式标记存在。
 证据位于Admin `.logs/appointment-calendar-release-20261019/`：`release-complete.json`、`source-manifest.json`、`backend-purpose-manifest.json`、各Job构建/控制台记录、`runtime-after.json`、`smoke-after.json`、`smoke-admin-same-origin.json`、`public-static-verification.json`及`admin-job-configuration-restored.json`；后端基础21文件清单为Backend `.logs/appointment-calendar-release-manifest.json`。本轮未修改业务数据、Nacos或权限配置，未执行SQL/删除/重置。未提交工作区其他已有改动。1920×1080、浏览器100%缩放下的新页面与弹框人工视觉仍待用户截图确认，不将HTTP和自动测试作为人工验收。
 ## 随机数量演示批次D1681准备（2026-10-19）
 用户随后要求沿用流程、随机调整数量，选定12箱4托、每托3箱，现场演示9箱首批与3箱后批。此前D1680已实收入库，因此保留不改；本次通过正式TEST业务接口另建柜次 `D1681`、柜号 `TSTU2713380`、入仓码 `NYEXX2610190002`、国内订单 `FL2112001474456780802`、尾程订单 `FL-WH-20261019-328883`、海外入库单 `IP-ABE4-20261019-724033`。客户为IT测试公司，路线US-LAX-01洛杉矶仓至ABE4；4个真实托盘为 `D1681-126-001` 至 `D1681-126-004`，各3箱，已完成海外入库。货物核实、预约、9+3分批、排车、车次均留给现场；首批拟选择前三托，后批保留第四托。
@@ -2231,6 +2321,7 @@ Client #382（`a0736239e4ee4cd58b620dab912ffc0641360d9f`）正式页面在1920×
 上述脚本定向离线检查 8 文件/72 项通过；全范围离线检查分别为 scripts 根级 79 文件/709 项（696 通过、13 失败），Admin 模块 129 文件/1159 项（1154 通过、5 失败）。失败文件精确记录于同目录 result.json：agents-index-registry-contract.test.mjs、database-schema-alignment-migrations-contract.test.mjs、java-quality-summary.test.mjs、synchronous-dependency-contract.test.mjs，以及 admin-test-env-modules/initialization-baseline-contract.test.mjs、phase3-producer-chain-contract.test.mjs。AGENTS 索引门禁仍因登记表不符合固定三任务假设失败，未改动登记表或放宽断言。本次 HTTP 正常链通过不等于全仓质量门禁通过。
 ## 本土卡车与散板需求字段发布（2026-10-19）
 当前字段规则唯一见[海外仓业务 README](海外仓业务/README.md#本土散板简化下单)及同文“美国本土卡独立下单”。本轮仅发布 Lastleg、Client 与 Admin；没有发布 Gateway、Auth 或其它服务。
@@ -2247,6 +2338,7 @@ Client #382（`a0736239e4ee4cd58b620dab912ffc0641360d9f`）正式页面在1920×
 - 两端公网入口及本轮精确 JS 产物的 34 项静态 HTTP 检查通过，已核对车型、两端联系人、取送时间、散板商品和预计托数及分钟格式。运行证据为私有环境目录内的 `looseboard-release-status-20261019.json`、`truck-demand-http-report-20261019.json`、`looseboard-demand-http-report-20261019.json`、`looseboard-demand-frontend-http-20261019.json`，不提交凭据或运行报告。
 - 人工页面视觉仍待 1920×1080、浏览器 100% 截图确认；自动化接口及静态产物检查不代替视觉验收。
 ## Admin / Client 统一运输下单表单发布（2026-10-19）
 - 本轮只发布前端：Admin `b92e5379bcc7196c034542087b6e9a6615f9ae71`（`admin-web-test #642`）、Client `17580fb0a22ddf7dbf2576fc8fc4ab94a31cb4fd`（`client-web-test #429`），均核对精确 checkout，类型检查、构建及部署成功。Lastleg 沿用 #367；没有执行 SQL 或发布后端。
@@ -12,6 +12,8 @@
 ## 功能快速路由
 - [排车列表统一作业改造契约](排车列表统一作业改造契约.md)：五阶段排车、一单一趟、跨客户同车、派送安排及四块排车详情的当前改造入口。
 - [排车流程修复规划](排车流程修复规划.md)：排车撤销、派送状态、换标全托、合托来源及草稿交互的修改范围、分工与回归要求。
 - [采购订单样品履约流程变更需求](采购订单样品履约流程变更需求.md)：采购样品购买、装箱、面单、交寄、国内核费与寄客户的变更入口。
@@ -0,0 +1,361 @@
 # 排车列表前端原型核对
 ## 本轮范围与结论
 2026-10-19，前端任务 `01a1524f-52c7-7cc3-9b08-d34ad24c172a` 按总控 `01a15230-a9d6-7503-a8a9-d70691df49e5` 的首轮准备派工形成本文。工作区为 TEST 项目 `c64729ff-6710-43c6-8ef2-d84e9666cc1e`、host local、`C:/Users/BY-OY/Desktop/code/chongchong-global`；三项已经通过本机项目清单和cwd核对。首轮仅写文档；随后总控按共同契约第八至十节解锁前端生产代码和离线验证，本文同步维护实施切片。始终不提交／推送／部署／运行环境SQL或真实HTTP，不操作真实业务，不建分支／worktree或项目副本，不跨对话发信或递归委派。
 业务目标唯一见[排车列表统一作业改造契约](排车列表统一作业改造契约.md)。其最新第八至十节覆盖本文首轮矩阵中的历史待裁定表述；以下“当前实现”记录首轮读取快照，实施结果单列，不把旧快照当作仍未修改的事实。日历新增预约已分离，不由本任务设计、编写矩阵或实现；仅保留整车改造影响的已有预约直接消费者接线。
 首轮主要差异：Admin先创建客户排车再安排共享车次，审核进入旧车次详情；列表缺派送中、派送完成阶段。首轮排车详情为连续分区，首批现已改为独立页面四个彩色图标页签，真实数据对象仍待统一接入。PDA仍以 `tripNo/tripRecordVersion/tripDispatchCount` 执行旧多排车整车发车；目标语义已按正式契约确定，实际请求需等待公开提供者补全后原子替换，不用骨架冒充全链完成。
 本文行号绑定本轮读取的工作区文件；其他任务后续修改可能移动行号，实施时用同列符号重新定位。
 ## 证据与优先级
 | 编号 | 证据 | 使用方式 |
 | --- | --- | --- |
 | P | `C:/Users/BY-OY/Documents/WXWork/1688854456873012/Cache/File/2026-10/悦/悦/新版.html`；SHA-256 `844B6A602FBDD7382EFCF3C71A0F67018F5481C5B3189F3A6997CDF274A643C4` | 仅定向读取 `page-outbound-vehicle`、`page-outbound-vehicle-detail` 及其关联弹框、函数。下文 `P:行号` 均指此文件。 |
 | S1 | `C:/Users/BY-OY/AppData/Local/Temp/codex-clipboard-d961dfb7-bc3d-4d7b-95ac-6045d05ca279.png`；SHA-256 `C2567DABA3DFE91345CDBA043F5DEB50E1496821218BA8CAE46AEF2BEE5D4DE5` | 已用 `view_image` 核对：车辆信息、排车信息、单据信息、关联订单明细四块；字段和表列依据。截图截到了表格前部，不推断截断区域的行数或数据。 |
 | S2 | `C:/Users/BY-OY/AppData/Local/Temp/codex-clipboard-cb9010b0-8ce8-43e5-b40f-70f4a4d13150.png`；SHA-256 `72FC5CA97D8BA7FA717C201EDA135DAE18C2AE2608088C49E531F1D861D144AD` | 已用 `view_image` 核对现有横向彩色图标、激活底色及下划线。八个旧车次页签仅作样式参考，不作为本批详情内容。 |
 | C | 本批统一作业契约第一、二、三、六节 | 一单一车、五阶段、两种建单、临时外配、PDA 核平、四页签及附加能力保留优先于原型旧行为。 |
 | V | `docs/Admin-Client前端原型还原验收规则.md`；`docs/Admin高密度界面规范.md` 的样式维护边界和新模块接入规则 | 按逐操作判断承载方式；采用公共密度、白底紧凑字段、原有字号与页签，不照搬灰卡。真实页面待人工在 `1920×1080`、100% 缩放下截图确认。 |
 原型存在必须由 C 覆盖的行为：`P:18656 completeOutboundVehicleLoading` 同时写装车完成时间和 `depart`，不可复制；`P:18744–18746` 完成页从 `vehicleBusinessRecords` 取自营记录并有演示值拼接，必须改为排车自身的服务端正常签收汇总；`P:18840 saveBol` 一次只生成一张演示派送单，不满足按客户＋目的仓拆分；`P:18960 saveVehicleEdit` 禁止无订单保存，与本批允许空单冲突；原型手工车辆状态、浏览器时间和示例附件均不能成为业务事实。原型派送异常入口 `P:18791–18807` 不在本批扩展线上闭环。
 ## Admin 逐操作矩阵
 以下实现路径均相对 `apps/admin-web/src/`。原型尺寸作为业务承载依据，密度及公共样式沿 C/V；没有明确原型的新增行为列为总控冻结项，不自行选抽屉或增加页面。
 | 页面／操作 | 原型承载方式、尺寸与依据 | 当前实现与差异 | 本批结论与所需后端事实 |
 | --- | --- | --- | --- |
 | 排车列表／装车前 | `P:4489–4501` 独立列表，操作首列；`P:4492–4493` 主阶段＋车辆信息／调度审核／理货员审核三个子区，`switchOutboundVehicleTab/BeforeTab` 在 `P:18605–18606` | `overseas-warehouse/pages/DispatchesView.vue:54–79, 688–708` 有阶段和审核子区，但额外“全部／已取消”，默认全部；子区只改变展示列，未传审核子阶段；审核和资源依赖 `workflow.tripNo` | 五阶段作为主流程，装车前保留三个审核子区；“全部／取消”如何作为辅助筛选由总控冻结，不冒充第六阶段。需分页支持阶段、审核子阶段及总数；每行返回审核事实、车辆资源和独立动作资格，不在当前页做过滤后冒充总数。 |
 | 列表／装车中 | `P:18655, 18706–18707, 18757–18760` 同列表阶段、查看及管理资料；装车前理货通过转入装车中 `P:18643` | 现有 `LOADING` 筛选，旧流程却是调度通过后先 PDA 拣货、平台实测装载、再理货审核，顺序与 C 不同 | 理货通过后才进入装车；PDA 扫码仍是真实事实来源。行显示核平进度与阻断；不得仅改状态标签放行。需服务端阶段、审核顺序、核平进度、可确认装车完成资格。 |
 | 列表／装车后 | `P:4492, 18655–18656, 18750–18753` 同列表阶段，实际装车完成时间、管理资料 | 现有 `AFTER_LOADING` 依赖旧车次投影；`DispatchesView.vue:595, 609–679` 按 `canTransfer` 执行转派送，没有独立装车完成命令或后台发车动作 | 装车完成进入装车后；在此安排派送，完成后才能后台或 PDA 发车。需 `loadedAt` 类真实时间、安排派送进度及资格；不得将装车时间当发车时间。字段名待共同冻结。 |
 | 列表／派送中 | `P:18739` 动态插入派送中页签，`P:18681–18683` 轨迹；`getOutboundVehicleLoadStage` 在 `P:18655` | `DispatchQuery.stage` 和列表枚举均没有派送中；现有 `DEPARTED` 只是排车执行状态，不足以代表五阶段 | 新增服务端阶段筛选，读取真实发车时间、各派送单状态及异常提示。轨迹与异常功能不因原型存在而扩大本批。需全部派送单关联及状态汇总，不以某一单签收结束整车。 |
 | 列表／派送完成 | `P:18738, 18741–18747` 动态完成页签（原文“配送完成”） | 当前没有对应阶段；原型从另一业务记录取数据、显示值也有不一致 | 统一文案“派送完成”。只读服务端全部正常签收的汇总，部分签收／拒收／退回不自动完成；不增加人工“标记完成”按钮，不释放车辆／司机资源。 |
 | 新建／先选货建单 | `P:4491` 新建排车按钮；关联预排生成 `P:18575–18582`；现有智能预排的独立原型尺寸不在本次指定两页中确定 | `SmartDispatchDialog.vue:322–419, 499` 当前为宽 `min(1800px,100vw-40px)` 居中智能排车弹框，从 `InboundOrdersView.vue:17,249` 进入；非空装车容器分组原子提交，换标走整单专用提交；排车列表只有“安排车次” | 保留先选同起运仓可排来源／托盘建单，列表需有入口。新建入口如何复用现有宽弹框由总控冻结；不以 1120px 编辑框推定大型预排工作区尺寸。需创建直接产生一张整车单，显式多容器时返回逐组整车结果；跨客户货物保留归属，无需用户再安排共享车次。 |
 | 新建／先建空单 | `P:4491` 仅按钮，无空单表单和处理函数；`P:18960` 反而禁止空关联订单 | 当前 `SmartDispatchDialog.vue:336–339,674` 禁止无托盘，`TripPreparationDialog.vue:50–56` 也必须已有排车及主档资源 | C 明确允许，需新增空单创建模式；承载建议复用“维护车辆信息”的居中表单，精确字段和按钮由总控冻结，不伪造货物。需独立空单创建请求、起运仓和返回业务号／版本；空单可保存但不可审核进入作业／装车／派送／发车的确切门禁由后端返回。 |
 | 编辑／维护车辆及预约信息 | `P:12414–12446` 居中宽表单，最大1120px、96vw；三列规则 `P:12380–12389`，页头、正文滚动、固定底部；`P:18858–18875 editVehicle`，`P:18942 saveVehicleEdit` | `DispatchesView.vue:446–465,505–529,718` 居中900px三列；仅自由文本车牌／司机／电话／车队和时间预约，无主档切换、附件、加货；请求无版本和幂等；`departAt` 可编辑 | 本轮沿1120px维护弹框核对，不恢复原型手改状态／发车时间。计划时间和实际时间必须明确区分。需最新整车版本、编辑资格、资源模式、预约字段、备注；货物／关键资源变化后旧审核失效事实由服务端返回。 |
 | 车辆／司机主档选择 | 指定两页编辑原型只有手填 `P:12424–12426`；现有 `TripPreparationDialog.vue:38–44,77–80` 提供聚焦远程主档候选 | 现有选择器位于“安排车次”，不是排车维护；车型预排选项 `SmartDispatchDialog.vue:677` 只是360px车型选择，不是真实车辆档案 | C 明确支持主档。复用已公开候选能力、按需搜索，不在列表逐行查资源；容量／占用／证照由后端复核。需候选权限、主档ID及显示快照、允许选择状态、容量／证照阻断和提醒；保持长ID字符串。 |
 | 车辆／司机临时外配 | `P:12424–12426` 直接填车牌／车队／司机／电话 | 排车自由文本存在，但主档车次安排仍强制 vehicleId/driverId，无法闭环 | 明确主档与临时外配模式；临时模式不创建主档、不传伪造关联，不能靠前端把文本填回一个任意ID。需资源来源枚举、临时快照、服务端完整性／占用校验及模式切换时清除旧关联规则。 |
 | 加货 | `P:12438–12441` 维护弹框的关联订单页签；`P:12451–12457` 居中980px候选弹框，`openOutboundVehicleOrderSelect/confirmOutboundVehicleOrderSelection` 在 `P:18921,18935` | 现有编辑只能移除，API 没有加货命令；智能预排是新单，不可拿新建接口冒充已存在单加货 | 保留维护弹框内关联货物入口，候选居中980px；需同起运仓跨客户可排候选、来源锁／版本、追加及去重、返回整车新版、变更后审核重置。后端决定变更开放阶段与在途阻断，前端不自行放开。 |
 | 移除货物 | `P:12441,18917–18919` 关联订单删除为草稿移除，无明确确认 | `DispatchesView.vue:530–559,718` 居中危险确认后按真实明细ID移除，刷新快照与路线 | 保留确认、服务端 `canRemovePallet` 和失败上下文，不能照搬浏览器数组删除。需版本、幂等和原子返回；换标全托／同托来源／批次分配不能在前端合并或丢失。 |
 | 调度审核／通过 | `P:12436` 居中760px、95vw、88vh审核弹框；`P:18617–18627` 显示车辆、预约和附件；`P:18644` 通过后进入理货员审核 | `DispatchesView.vue:581–607` 跳车次；`TripDetailView.vue:135–149` 通过直接发请求，驳回另开简单prompt，未展示同一审核弹框 | 在本批排车流程内760px审核弹框承载，显示整车资源／货物摘要／附件、审核意见；通过意见可选，不加虚构审核清单。需调度独立资格、当前审核事实、版本和幂等请求、通过后最新单据。 |
 | 调度审核／驳回、原因查看与重提 | `P:12436–12437` 审核与被驳回详情两个760px居中弹框；`P:18629–18645` 驳回必填，回维护 | 当前审核依赖车次，列表可显示workflow原因，但没有原型被驳回详情与原位重提 | 驳回理由保留；维护后显式按新版本重提，不把保存自动当审核通过；需审核阶段／轮次、原因、时间、已失效事实和重提动作资格。驳回后的精确流转由共同契约冻结。 |
 | 理货员审核／通过 | 与调度复用 `P:12436,18622,18643`，标题为理货员审核，通过后装车中 | 旧车次 `reviewTripLoading` 在确认实载后执行；旧指引要求理货后才能发车，未把它作为开始装车前置 | 按 C 移到装车前，独立权限及动作资格；通过后允许PDA拣货并进入装车中，不能用旧 `canPick` 仅调度通过的规则。需两审核序列事实和剩余阻断。 |
 | 理货员审核／驳回、重提 | 同 `P:18640–18645`；驳回原因必填并回维护 | 现有车次prompt仅版本／结论／原因，无幂等及新顺序 | 在审核弹框内驳回；按服务端重提状态刷新，不能本地保留旧调度结论继续装车。需版本／轮次／事实失效及已开始PDA作业后的服务端禁止条件。 |
 | 装车完成／后台 | `P:18656 completeOutboundVehicleLoading` 有直接修改模型函数，未找到本页对应完整确认承载；它错误同时写发车时间 | 旧 `TripLoadingPanel.vue:62–82` 是实测容量确认，不是统一整车装车完成；Admin排车无该动作 | C第八节已明确确认装车弹框接入既有实载核对，有依据自动带出、缺项确认；必须PDA真实核平，不补录拣货数量，不新增第五页签。消费实际骨架LoadingComplete及其公开实载读取DTO后实施。 |
 | 装车完成／PDA | 指定Admin原型没有PDA承载；C 为行为依据 | `dispatch.vue:70,182–185` 只有“完成排车拣货”并调用 `/complete`，仅提交幂等键 | 已按第九节及实际骨架明确：最后扫码仅形成pickingReconciled，双端使用loading-complete独立确认装车，旧complete协议直接替换。PDA核平后、后台先确认、PDA重入应显示服务端已装车事实，不重复扣货。 |
 | 安排派送／费用 | `P:28480–28570 modal-bol` 居中1080px，三列派送字段、费用和货物表；`P:18808–18850` 打开和保存 | 现有1120px三列 `AppDialog`，`DispatchesView.vue:466–503` 打开后各一次读取运费和覆盖，`609–679` 提交整单一个 `fees[]`；返回deliveries按目的仓，缺客户维度 | 名称及行为为装车后“安排派送”；用共同后端预览按客户＋目的仓逐组核对派送资料、原费用覆盖、新增费用。建议沿现有宽版模态框容纳分组，宽度1080/1120差异由总控冻结；不得前端平均分费、复制整车费用到每组或先发车后补派送。需分组版本/hash、客户显示、货物来源、币种、覆盖明细、新费用及全组安排完成事实。 |
 | 实际发车／后台 | 指定两页没有明确后台发车确认表单，C明确新增两端能力 | 排车无按钮；旧 `TripDetailView.vue` 和AGENTS明确PDA发车，需随本批收敛 | 建议小型居中确认，展示车牌、司机、排车号和全组派送就绪，待总控冻结承载；必须独立于装车完成，消费服务端 `canDepart` 类能力。需统一版本、幂等、操作时间、真实发车后状态及两端重复结果。 |
 | 实际发车／PDA | C；现有设备页作为直接消费依据 | `dispatch.vue:75–81,187–195` 显示“车次＋共N张排车”，验证 `IN_TRANSIT + tripNo + dispatches包含当前单` 后再GET任务释放键 | 改为“一张排车单整车发车”；不能继续强迫用户理解多个客户排车。等待后端冻结业务号和响应模型，再校验同一整车及真实阶段，保留未知结果恢复，不伪造 `DEPARTED`。 |
 | 附件上传／预览 | `P:12430` 司机照片、车辆图片、驾驶证；`P:18882–18891` 居中900px图片预览／非图片下载；`P:18763–18790` 管理资料居中960px，图片图库和PDF文件 | 本批排车维护无附件API；旧BOL `DispatchesView.vue:407–423` 已用鉴权Blob新标签PDF；PDA交接状态为只读独立组件 | 审核与维护需要真实三类附件及按需鉴权预览，图片900px模态、PDF沿新标签预览；具体File提供者触点由总控分配。装车照片、BOL司机签收等管理资料角色／必填不由原型5张写死规则自动引入。需文件ID、角色、名称、媒体类型、权限、上传后绑定／替换语义及鉴权下载；列表不逐行下载附件。 |
 | BOL读取 | `P:18648–18653` 调度通过后下载演示HTML | 现有正式PDF读取路径，`getDispatchBolPdf` `dispatches.ts:203–207`，有弹窗拦截和失败反馈 | 保留真实PDF，不改回原型HTML。新整车BOL应覆盖多客户货物且正确隔离；调度审核后可读的准确资格需返回，不能以按钮永远显示推定允许。 |
 | 独立四页签详情 | `P:9448–9456,21711–21732,21751–21754` 独立页面，业务号、状态、返回、三字段块＋关联表；S1/C改为四页签，S2仅样式 | `DispatchDetailView.vue:79–135,153–165` 独立路由已存在；同页分区，无页签；单据信息用“关联订单”，更新时间／备注恒“—”；订单表集装箱恒“—”，按 `orderRefs` 将同托重量体积复制给多个订单 | 保持正式路由及返回上下文，四页签细则见下表；需服务端真实单据信息和订单级准确汇总。不得将同托整托重量重复归到每个订单，不以ID、样例或零替代未知。 |
 | 取消／删除 | 指定两页未定义删除／停用；C只要求保留附加能力、聚焦主流程 | `DispatchesView.vue:561–579` 已有取消危险确认和托盘释放提示，没有删除单据 | 保留现有取消能力、独立权限与服务端资格，配合新版版本／幂等；不新增删除／停用。新状态下的取消与资源释放边界交后端和总控冻结，不以“测试可丢弃”授权删除。 |
 ## 四页签内容与数据缺口
 页头保留排车单号、服务端阶段／状态、返回原入口及获准的主要操作；四页签顺序固定如下。采用 `el-tabs.density-element-tabs.density-contained-tabs`、`density-tab-icon`，页面不重定义公共字号／高度／底色／下划线。第一项车辆图标沿S2的 `🚚`，其余复用现有语义图标：`📋`、`📝`、`📦`（见 `DeliveryOrderDetailView.vue:75,92,118`）；具体映射是本轮建议，交总控冻结，不新增图标系统。
 | 页签（建议图标） | 固定字段／列顺序 | 现有来源与缺口 | 消费要求 |
 | --- | --- | --- | --- |
 | 车辆信息 `🚚` | 车牌号、司机、联系电话、拖车公司名称、车辆状态 | `DispatchSummaryDto.vehiclePlate/driverName/driverPhone/carrierName/status`；当前 `status` 是排车状态，是否作为车辆显示状态须明确 | 返回主档或临时外配的真实显示快照和明确车辆状态文案；紧凑白底4–6组短字段，长车队名跨列。不拿内部主档ID或“待分配”示例代替缺失值。 |
 | 排车信息 `📋` | 路线、发车时间、预计到达时间、FBA预约、车辆预约 | 已有route/departAt/estimatedArrivalAt/fbaAppointmentStatus/vehicleAppointmentStatus；整车多目的仓只有一个预约号／状态不足 | 路线由货物目的地真实事实生成，不手输演示“30托盘”；发车只显示实际时间。多目的仓预约需真实逐目的仓/批次事实或服务端明确整车摘要，不能显示一个仓已约即全车已约；冻结精确展示。 |
 | 单据信息 `📝` | 排车单号、关联派送单、创建时间、更新时间、备注 | `DispatchDetailView.vue:93–101` 使用orderNos且缺updatedAt/remark；现有 `TransferDeliveryItem` 不含客户归属，详情没有deliveries | 返回所有真实派送业务号、对应客户＋目的仓及状态供关联；多单号完整换行／明确链接，读取目标仍受各自权限；创建／更新时间与备注从服务端返回。关联订单不能代替关联派送单。 |
 | 关联订单明细 `📦` | 订单号、重量kg、托数、目的FBA仓、体积m³、集装箱号 | `DispatchItemDto` 无客户／containerNo，只有托级weight/volume及orderRefs；现有多订单循环重复累加整托载荷，containerNo恒空；bolLines有containerNo但不是订单级汇总映射 | 后端返回有客户归属的订单汇总行或足以准确归属的明细；同托多订单的重量／体积不可由浏览器猜分；未知显示“—”。只读通栏表，不为套规范新增操作列；订单业务号可完整展示，客户身份保留在模型，是否增显示列由总控决定，不自行改变S1六列。 |
 仅以上四页签。现有 `TripDetailView.vue:201` 的分配与货物、外接预订、计划容量、实际装载、结案与任务结束、在途交接、直接成本、历史八项不移入新详情；其代码和对应后端能力先保留。不得把“派送完成”等同“资源任务结束”，不得因隐藏页签自动释放资源。既有路线地图若继续入口，放在排车信息的明确操作位置，不新增路线页签，需总控冻结最小接线。
 ## 后端消费者要求与实际骨架接入
 首轮已读取两后端准备稿：[排车列表接口与数据设计](排车列表接口与数据设计.md)（主流程，首读快照SHA-256 `F4D8AE6D46DEC5A1AC36BDE6926DD495F7E3180FCE5691AE36BA3BDA386156D0`）与[排车列表派送费用接口设计](排车列表派送费用接口设计.md)（派送费用，首读快照SHA-256 `9BEE01228045D8C7A54BB3D1D4202ED52B6B550C36212EBA049BFB7DE4E536B5`）。两稿随后按正式契约收敛；实施以共同契约第八至十节及提供者实际Java公开DTO为准，首读哈希仅用于追溯差异，不作为最新接口冻结值。以下消费者要求保持为接入核对清单，已确定部分见下一节。
 | 范围 | 主流程后端必须明确 | 派送与费用后端必须明确 |
 | --- | --- | --- |
 | 一单一车及身份 | 唯一用户可见排车业务号；旧tripNo与新排车是否仍有技术关联、唯一关系及各直接消费者更新方式；不保留用户必须多单绑定车次的流程 | 派送关联回同一整车业务号，各组保留客户及目的仓归属；同仓、同目的仓不同客户不能合并收费 |
 | 详情／分页投影 | 五阶段、审核子阶段、业务状态分开；列表分页一次取动作摘要、审核、资源、货物统计；详情真实时间、备注、订单级载荷、集装箱、关联派送；动作资格缺失fail-closed | 每组计划／派送号、客户业务显示、目的仓、状态、费用覆盖摘要、正常签收与异常事实；不要求前端逐票查状态拼汇总 |
 | 命令及版本 | 创建空单／选货建单、加减货、资源维护、提交／重提、两审核、完成装车、实际发车的精确方法／路径／请求／响应；所有必要写动作稳定幂等、版本0有效；PDA拣货是否需单／明细／库存位置版本 | 安排派送预览和原子确认；版本/hash包含全部分组、来源、货物及收费基线；返回全组结果与整车安排完成事实，不部分成功后由浏览器补写 |
 | PDA真实核平 | 服务端返回计划／实拣／未拣、pickingReconciled及允许完成装车资格；旧complete替换为loading-complete；后台不能提交假的已拣数补齐，空单不可核平；两审核顺序服务端保证 | 装车后才可安排；未安排全组不可发车；同一拣货事实进入后续出库不得再拣一次、再扣一次或按派送拆分重复扣减 |
 | 资源和附加能力 | 主档与临时外配请求及切换、容量／占用／证照规则、已保留附加能力对版本／资格的影响；不让旧实际装载／理货入口绕过新阶段顺序 | 外接约定运费仍是冻结事实；直接成本与客户应收分开，不因本批未展示而删除或自动收费 |
 | 费用组归属 | 明细customer与source/destination/batch关系稳定，服务端跨客户权限；PDA只取Token仓，不收客户／仓范围入参 | 逐组原覆盖项、来源ID/版本/hash、金额币种、剩余新增费用、外接quote；`fullyCoveredServices`须按本组判断，不能用整车全覆盖隐去另一客户未覆盖费；不让前端平均分摊整车费 |
 | 完成／异常 | 发车后的整车阶段及最终正常完成事实投影；资源释放继续独立；审核失效后可操作资格同步 | 全部正常签收才完成；部分、拒收、退回、取消、空组不得误算正常完成。返回明确数量／异常摘要，不以 `remaining=0` 或任意terminal判断完成 |
 | 并发／未知结果 | 同命令同键同载荷重放、同键改载荷拒绝、版本冲突／业务失败／权限失败与未知网络结果的区分；返回业务号、最新版本、动作证据；可按原键核对或安全重放，不要求浏览器生成新键猜测 | 与完成装车／发车共用整车锁与一致性；费用基线变化冲突后重新预览，未知安排结果可原键恢复，不能生成第二批派送／费用 |
 | 附件／权限 | 附件元数据／绑定与审核关系、专属下载；前端既有dispatch/trip写权限如何收敛，list包含详情只读，命令权限独立；File触点交总控分配 | 客户只可读自己的货物、派送和费用；整车跨客户平台投影不能直接复用给客户。共同权限、SQL和OpenAPI均由总控集成 |
 现有Admin精确API基线：`api/dispatches.ts:188–286` 的平台排车列表／详情／更新／取消／移除、候选、预排和草稿；`293–345` 的转派送、约定运费和费用覆盖。现有PDA精确基线：`src/api/fulfillment.js:3,86–111` 的 `/pda/v1/last-leg/dispatches` 列表、详情、逐明细pick、complete、depart。这里只记录现状，目标是否复用或删除路径由共同接口冻结决定；不增加旧新别名或回退链。
 ### 两后端准备稿交叉核对与正式收敛
 首轮记录的两稿差异已由共同契约第七至九节裁定，以下为现行执行基线，不再要求用户重复确认。Java公共骨架现位于 `lastleg-service/src/main/java/com/baiyue/lastleg/dispatch/port/`；这里只读取实际DTO，不修改Java、不依据草稿猜API。
 | 事项 | 正式结论及实际骨架 | 前端执行要求 |
 | --- | --- | --- |
 | 整车与四页签 | 一张dispatch自动一对一Fleet资源记录；`DispatchViews.Detail`为vehicleInfo/dispatchInfo/documents/orderDetails；每客户一出库、每客户目的仓一派送 | dispatchNo为唯一主操作业务号；完整outbounds/deliveries数组，不保留单个outboundNo别名。附加能力代码保留，不移入四页签。 |
 | 状态、阶段与版本 | `DispatchTypes.Status=ACTIVE/CANCELLED`，Stage为五项；ReviewState和ReviewStatus独立；所有已有单写请求统一recordVersion，0合法 | status不再混用拣货/车次状态，取消不是第六阶段；列表按真实Query及Statistics筛选统计，不按当前页长度计算。 |
 | 临时外配证据 | 第八节已确认：空单先保存，审核前补齐本趟容量、司机证照和预计任务结束，调度核实；实际Vehicle/Driver分别有mode，DriverEvidence含证照号、到期、fileIds、expectedTaskEndAt | 两资源分别可MASTER/EXTERNAL；不创建主档、不伪造ID，不要求用户再次确认规则。附件提供者和公开候选读取仍须真实DTO。 |
 | 实载与零扫码变更 | 确认装车弹框接入真实实载；`LoadingComplete`要求manifestHash/measurements。`RETURN_TO_REVIEW`保留原号，仅零扫码可退回重审 | 核平与装车确认分开，缺项只确认真实重量/体积/卸货点，不补拣货数量；未读到实载公开读取DTO前不补造manifestHash。 |
 | 命令与业务摘要 | 全局唯一idempotencyKey，原主体/动作/单号/原版本/载荷绑定commandHash；安排单另有arrangementBusinessHash。`CommandResult`含action/key/status/stage/effect/result/replayed/alreadyArranged | 原键不换主体或载荷；新有权限主体以新键当前版本引用原安排，不再收费建单；校验同单同动作同键结果后GET当前事实，不用旧结果覆盖新阶段。 |
 | 库存与发车 | 库存SHIP已在真实扫码执行；安排/装车/发车均不再扣一次。发车只推进来源订单、客户出库及派送计数和事实 | 只消费排车公共版本和真实动作结果；PDA不再以trip版本和多客户子排车成员判断发车，不发起第二遍出库拣货。 |
 | 锁序 | 根trip→涉及的车辆→司机/资源→dispatch；扫码来源→库存且不锁派送；安排/发车先全部客户出库派送后来源费用；签收delivery→来源→持久信号 | 超时保留原键与载荷，不以换键自动重试掩盖死锁；不把列表资格快照当写入复验结果。后端对尚未核实的提供者锁点继续核对，前端不声称全域无死锁。 |
 | 正常完成 | 签收提交后可靠持久信号；派送保存和数据访问，主流程有界消费/退避/重扫；父锁下读取已提交事实，阶段CAS与信号确认同事务 | 页面只显示已提交真实stage；签收成功不直接本地改DELIVERED，刷新读取最终汇总；部分/退回/拒收不当正常完成，资源结束仍独立。 |
 | 组合安排 | `DispatchDeliveryModels.ArrangementPreview`含groups/arrange/cargoHash/loadingCompletionHash/arrangement；ArrangeDelivery公开recordVersion，逐组费用与证据 | 打开弹框一次组合GET；不再两辅助GET拼快照。严格组级覆盖，不跨客户免单、不平均分费。缺失字段交提供者补，不能客户端猜hash。 |
 | Client与预约边界 | 第八节已确认平台安排这类整车派送；本任务取得Client直接消费者移除权。日历新增预约已单列排除 | Client旧创建页/API/按钮移除，读及合法资料保留；共享routes/权限由总控已接管。已有WorkDispatchForm/WorkExistingDispatchForm/WorkSharedTripForm仅列影响，未取得精确移交前不写。 |
 接入前仍缺的公开消费事实（不是要求用户重新裁定业务）：①确认装车前的既有实载读取端点及DTO（manifestHash、真实测量行、卸货点）；②候选sourceVersion和草稿转换请求/结果的实际对外DTO；③新Detail与既有预约三表单使用的appointmentBatches、仓库和workflow差异及唯一写者；④临时证据上传/读取的真实File契约。主流程只产出port骨架不等于上述Controller/DTO及消费者均已完成。请求接入按实际提供者完成快照推进。
 ## PDA接口差异与恢复要求
 路径相对 `apps/pda-overseas-uniapp/`。
 | 问题 | 源码证据／当前行为 | 目标及接口差异 |
 | --- | --- | --- |
 | tripNo／tripRecordVersion | `src/api/fulfillment.js:27–29,107–111` 将车次版本转字符串，接受0；depart请求用trip版本，不是排车版本 | 冻结唯一整车版本及业务身份；不把dispatch版本误当trip版本。若模型移除trip相关字段，直接同步API／页面／草稿／测试，不做双协议解析。若仍保留技术关联，不在UI要求另一车次操作。 |
 | 多排车整车响应 | `dispatch.vue:75,189–194` 显示共N张排车，按trip与dispatches成员验证整车 `IN_TRANSIT`，随后GET排车期待DEPARTED | 新单本身即整车，改验新响应的同一业务号、真实阶段和动作事实；不得保留“多张客户排车”UI或把IN_TRANSIT直接灌进旧单status。 |
 | 真实拣货与两审核 | `dispatch.vue:120–123` 拣货和complete均依赖canPick；提示“调度审核后拣货”；明细以scheduled/picked、库位、退货箱作业 | 服务端canPick须包含调度＋理货通过及当前版本；本地数量只做交互校验，不替代核平。保留真实托盘业务码、退货箱唛、同托多来源选择；禁止目的仓码代替实物码。需可信进度、空单阻断、作业失效事实。 |
 | 完成拣货／装车／发车 | `dispatch.vue:102,118,182–185` 多个完成状态别名，complete仅幂等；`187–195` 发车独立但缺装车后派送安排的明确事实显示 | 冻结唯一状态集与complete语义。装车完成、派送已安排、发车三事实分明；新增资格严格消费boolean true；后台完成后PDA刷新直接显示事实，不能再次complete。 |
 | 拣货未知结果 | `submitPick:174–179` 键按单／明细／position或carton／数量生成，POST后GET成功才释放 | 保留稳定请求键与原载荷；POST超时或GET失败时禁止改数量再重放旧键。若业务GET已反映拣货但没有动作证据，不能仅用“数量已增”判定原请求是谁执行；需原键回放／查询确定结果，避免滞留旧键误吞下一次相同数量拣货。 |
 | 完成／发车未知结果 | complete键只含dispatchNo；depart键含tripNo和版本；store只保存signature→key，不存完整请求，刷新取得新版本会生成另一signature | 必须保存操作类型、单号、原版本／hash、原载荷、幂等键及未知结果标记；未知时先查服务端／重试原请求。不得因为刷新版本变大而生成新键重发旧动作。已证实成功后清理原pending；明确业务失败后才允许按新快照重新决策。 |
 | Admin与PDA竞争 | 当前只有本页busy阻止双击，不能协调跨端；PDA pick/complete请求缺统一recordVersion | 两端同一服务端规则。并发确认只一次推进，失败方刷新读取已完成事实，不将合法重复误报成新成功；货物／资源变更造成旧审核和旧核平资格失效时服务端拒绝旧请求。 |
 | GET迟到与切任务 | `openTask:148–150` 一次读取后覆盖current；`run:198` 全局busy/loading防重复；没有独立目标请求序列 | 新恢复流程需要请求代次／单号校验，迟到旧详情不能覆盖当前任务、当前版本或pending键；成功提示属于确认过的原操作单，不依据已切换current。 |
 | 草稿隔离与进入方式 | `stores/fulfillment.js:30–45` 按操作员＋绑定仓隔离；`dispatch.vue:125–152` 默认任务列表，仅 `resume=1` 显式恢复；closeTask不清pending | 保留隔离、上次作业标记和显式恢复；草稿是交互状态，不是库存／核平事实。退出详情可保留未决操作，重入优先核对，不跨单重放；权限撤回、主体／仓变化继续由会话层清理。 |
 | 出库和附加能力 | `dispatch.vue:41` 发车后挂载 `DispatchHandoverStatus.vue`；其只读get及版本watch；出库扫码可显式跳转排车 | 保留组件实现；新阶段的挂载条件和trip标识映射交总控冻结，不把交接新增为详情页签。`outbound`共用API/store域保持完整，整车安排派送后出库扫码必须定位同一新排车，不增加重复拣货。 |
 ## 直接消费者及受保护接线
 | 触点 | 已核实引用／最小调整 | 写入边界 |
 | --- | --- | --- |
 | Admin排车主链 | `DispatchesView.vue`、`DispatchDetailView.vue`、`SmartDispatchDialog.vue`、`api/dispatches.ts`、`types.ts:103`、直接测试；`InboundOrdersView.vue:17,249` 当前智能排车入口 | 本轮只读；接口冻结解锁后再按精确文件实施。 |
 | 旧车次强制步骤 | `DispatchesView.vue:41–47,77–79,585–603,689`；`TripPreparationDialog.vue:46–83`；`api/trips.ts:81–87,122–125`；`tripTypes.ts:35–56`；`TripDetailView.vue:135–149,201` | 本批主流程不再跳转强制安排／审核车次。旧附加能力代码保留；若技术模型改变这些API，先由总控裁定最小接线，不能删除八页签能力或只改标题假装完成。 |
 | 预约按批排货 | `appointment-calendar/WorkDispatchForm.vue:5–6,88–102,117–123` 提交准确batchAllocations后再安排车次；成功跳旧trip详情 | 保留batch/source/destination/packageCount事实；新创建直接返回整车后跳排车详情，去掉第二次安排步骤的接线由总控协调。当前预约文件有他人在途修改，本任务不覆盖。 |
 | 预约已有排车 | `WorkExistingDispatchForm.vue:19–26,34,41–42` 校验批次后用TripPreparationDialog，“尚未关联车次”与旧trip跳转 | 保留批次一致性校验及外部跳转关闭事项弹窗语义；改用新整车资格和详情目标，交总控／当前写者处理。 |
 | 预约跨客户共车 | `WorkSharedTripForm.vue:23–36,42–48` 明确要求各客户分别备排车，再两单共车 | 与一单一车冲突，不能继续作为本批主入口。最小建议改为同一排车加同仓货物，保持已有批次分配、前置货物状态与返回上下文；交总控协调，不自行删表单。 |
 | 到港／排车日历 | `tripCalendar.ts:36–38,56–80` 读取fleet/trips/calendar，按tripNo去重，`sourcePath`指向旧trip；`AppointmentCalendarView.vue:64–68` 使用trip:list权限；`AppointmentCalendarPanel.vue:77` 只按sourcePath打开 | 后端冻结投影中的排车业务号与整车唯一关系后，最小更新去重键、标题、深链和权限；保留起运仓当地计划／实际发车时间语义、取消与缺资料投影，不改变其他日历业务。只读交总控。 |
 | 共享装配／密度 | `routes.ts:38–44` 已有排车列表及详情；导航、根路由、permissions、`src/styles/adminDensity.test.ts` | 根路由、导航、权限与公共密度由总控协调；adminDensity.test.ts已有他人未提交修改，不接管。详情只选择现有公共类，若需更新显式消费者清单由总控安排唯一写者。 |
 | PDA直接链 | `pages/dispatch/dispatch.vue`、`api/fulfillment.js`、`stores/fulfillment.js`、`utils/dispatch-error.js`、`components/DispatchHandoverStatus.vue`、出库扫码恢复入口、直接测试 | 后续解锁前明确必要新增写权；共用fulfillment文件的outbound/cargoDiscard能力不得丢失，不扩大其他业务整页。 |
 2026-10-19准备时 `git status --short`：Admin存在预约日历、工作事项、schedule相关文件、`self-operated/pages/OverviewView*` 及 `styles/adminDensity.test.ts` 的其他未提交修改；PDA未报告未提交修改。本轮没有覆盖、暂存、回退或格式化它们。
 ### 既有预约三表单的精确替换清单（只读交总控）
 本表仅为整车改造造成的直接消费者接线，不涉及日历新增预约。以下路径相对 `apps/admin-web/src/modules/appointment-calendar/`，三个文件及其测试本任务均未写入。
 | 文件／符号 | 现有字段／请求或分支 | 最小替换及须由提供者补全的真实事实 |
 | --- | --- | --- |
 | `WorkDispatchForm.vue` imports、result、pending、save | `DispatchSummaryDto`；旧drafts/pre-arrange返回`response[0].dispatch`；pending仅token/containerId/rows；创建后再TripPreparationDialog | 改成正式草稿转换命令结果，验证`dispatchNo/action/idempotencyKey`再GET新Detail；冻结原key/recordVersion/完整cargo和batchAllocations后重试。实际草稿结果DTO目前未公开，不能假定CommandResult数组外壳；仍保留容器对应和批次来源完整性校验。 |
 | 同文件 `load/select/save` | 单客户自动全选条件、选择时不同customer拒绝、save用`new Set(customerId).size!==1`拒绝；按钮“创建本客户排车单” | 删除这三处单客户限制，改为同一起运仓和服务端来源资格；仍保留批次来源、allocations customer断言、托位限制及实物去重。BatchDispatchCandidate需返回真实warehouseId/sourceVersion，缺失不凭相同批次推仓；文案改为创建整车排车单。 |
 | 同文件 result模板、tripSaved | `result.overseasWarehouseId/Name`、TripPreparationDialog、WorkSharedTripForm和旧trip详情路径 | 创建已自动关联Fleet，删后续“继续安排本批车辆／两单共车”步骤和对应import/ref；直接沿dispatchNo打开正式排车详情并保留emit external/update及事项弹窗关闭。剩余可排实物继续使用既有批次读取，不触及新增预约。 |
 | `WorkExistingDispatchForm.vue` load.matches | `row.id`拼`DISPATCH:${row.id}`、`row.appointmentBatches`做batchKey/customerId核对 | 必须保留真实批次＋客户关联验证。实际新Detail尚不含该关联；由主后端公开权威BatchReference及DISPATCH批次关系后改读，不以orderDetails客户清单、展示号或空数组替代；不继续从客户端内部ID拼权威批次键。 |
 | 同文件 prepare/writable、selected、saved、模板 | `PENDING_DEPARTURE`、`!workflow`、`overseasWarehouseId`、顶层`packageCount`、TripPreparationDialog、旧trip:list/edit权限 | 新单`status=ACTIVE`、`stage`五项，操作资格读`actions.EDIT/ADD_CARGO/RETURN_TO_REVIEW`相应Gate；数量读counts.packageCount，资源不再另建车次。Detail需真实起运仓投影；使用正式排车详情入口办理资源／加货，移除prepare弹框与旧trip跳转，保留readonly/ready事件和批次不一致失败。 |
 | `WorkSharedTripForm.vue` prepare/saved及整段双单交互 | 输入otherNo、同时get两排车、比较旧status/workflow/overseasWarehouseId、`dispatchNos=[A,B]`后prepareTrip | 一单一车不能把两张整车再合为一车；移除双单共车操作及TripPreparationDialog调用。在同一dispatchNo下打开“添加同仓货物”，消费真实AddCargo（recordVersion/key/cargo/batchAllocations），或最小链接到该单加货；不得迁移另一张已排单货物或自动解锁其占用。按钮是否保留为加货由总控协调原写者，不在本任务直接改。 |
 | 三文件共同权限／恢复 | 旧smart-dispatch、trip:list/edit及useWorkDraft；部分unknown键不含完整最终请求 | 创建权限收敛由总控IAM/前端权限集成；加货/资源沿排车edit及服务端Gate，不给日历读取权限追加整车写能力。保留useWorkDraft、原请求未知结果、当前批次分配与已保存预约关系，禁止结果未明就重新建单。 |
 | 直接测试 | `WorkDispatchForm.test.ts`、`WorkExistingDispatchForm.test.ts`、`WorkSharedTripForm.test.ts`，`WorkBatchContinuation.test.ts`及`WorkDetailPanel.test.ts`中的实际引用 | 更换Mock及断言为正式整车结果／批次事实；补同仓跨客户、未决请求、批次客户不符、零扫码退回重审；原事项关闭、原单跳转、剩余实物恢复和错误后禁止重复创建回归继续保留。只读列明，写者由总控核对。 |
 ## 后续回归设计（首轮设计，按实施切片记录执行）
 | 场景 | 输入／竞争方式 | 必须观察到的结果 | 拟落点 |
 | --- | --- | --- | --- |
 | 五阶段及子审核分页 | 切换五阶段与装车前子区，旧请求后返回；含空页、失败重试、无权限 | 服务端筛选／总数一致，旧响应丢弃；加载／空态／错误可用；动作资格缺失关闭写入；不逐行查详情 | Admin `pages/DispatchesView.test.ts`、`api/dispatches.test.ts` |
 | 两种建单 | 空单保存后再加货；先选同仓两客户两目的仓；另加跨仓候选 | 两种方式均直接取得整车业务号；不要求第二次安排车次。空单不得产生核平或发车事实；跨仓由服务端拒绝，表单上下文保留 | Admin新建／加货行为测试及API精确载荷；后端对应场景由后端执行 |
 | 资源模式 | 主档切临时再切回，延迟候选响应，过期证照／资源占用 | 不混传主档ID和临时快照；不建主档；警告与阻断区分；旧候选不覆盖新模式 | Admin维护组件测试、API类型检查 |
 | 审核通过／驳回／重提 | 两审核各通过、驳回空理由、重提；期间加货／更换资源 | 顺序正确；驳回必填；旧审核失效；理货通过前PDA不可拣；权限只读可看但不能写 | Admin审核弹框行为、PDA canPick门禁、后端命令测试 |
 | 真实拣货核平 | 未扫物、部分拣、重复扫码、错码、同托同仓不同来源、多行同palletNo、退货箱 | 只能按真实明细／实物码提交；不静默取第一行、不按目的仓码匹配；后台不能补数量绕核平；空单不算全部拣完 | PDA `tests/fulfillment-workflows.test.mjs` 中现有计算／方法注入harness扩充；后端核平事实验证 |
 | 装车完成与发车分离 | 全部PDA核平→后台完成装车→PDA刷新；尚未安排派送时两端尝试发车 | 完成装车只进入装车后、loadedAt有值、实际departAt仍空；派送未就绪canDepart=false；PDA不重复complete | Admin动作测试、PDA页面方法行为测试 |
 | 两端并发完成／发车 | Admin与PDA同版本同时确认，各种响应先后及一端409 | 服务端只推进一次；两端最终同阶段及真实时间；失败方刷新而非换新键盲试；不二次扣库存或生成派送／费用 | 双端Promise可控Mock行为；服务端并发验证不能由Mock通过代替 |
 | 版本0与大版本 | 首版0、缺失、负值、非数字、精度边界；旧trip版本与单版本不同 | 0有效，错误／缺失版本关闭操作；长ID不转Number；严格只用冻结版本域，不解析旧别名回退 | PDA API请求单测、Admin类型／序列化测试 |
 | POST未知与GET失败 | pick/complete/depart/安排派送：POST已执行但超时；POST成功后GET失败；关闭／重进／刷新 | 保留同一键、原载荷、原版本；按原请求安全核对后清pending；新快照不生成新键重放旧动作；相同数量下一次拣货不得被旧键吞掉 | PDA store与真实页面方法注入；Admin分组派送／动作组件延迟Mock |
 | 同键载荷变化 | 未知期间修改数量／费用／资源，再点提交 | 冻结未决载荷，提示先核对原结果；不能同键改内容，也不能用新键制造重复命令 | 双端未知结果测试；服务端幂等合同 |
 | 多客户费用 | 同仓客户A/B都送ONT8，另送LAX9；仅A有原派送费覆盖，含外接报价变化 | 按客户＋目的仓独立组；B仍需未覆盖费；原费用不新增重复行；hash变化重取；未知重试仍同批单据 | Admin费用分组测试、后端派送／费用测试 |
 | 正常完成及异常 | 三组仅两组正常签收；最后一组分别拒收／退回／取消／正常签收 | 前三种不自动派送完成；只有全部正常签收汇总完成，资源仍按原独立生命周期；不伪造退库／账务 | Admin阶段投影测试；后端正常完成事实测试 |
 | 四页签与长数据 | 四页签、长排车／派送号、多单号、多订单同托、未知重量、缺集装箱 | 只有四项且顺序固定；真实字段不混用；重量体积不重复分摊；无内部ID回退、无假零；表格只读无新增操作列 | `pages/DispatchDetailView.test.ts`；人工1920×1080截图 |
 | 附件 | 图片／PDF、403、网络失败、替换失败、关闭后迟到响应 | 鉴权按需读，业务错误不当图片；失败保留已绑定文件；关闭／卸载释放Blob、旧响应不打开已关闭预览；审核可读不等于可上传 | 新附件组件/API行为测试；人工预览 |
 | 入口／返回与附加能力 | 入仓预排、预约批次、已有单、跨客户货物、日历深链、出库扫码resume、发车后交接 | 进入同一整车且来源／批次不丢；返回原上下文；默认PDA列表和显式resume保持；旧附加实现保留且不绕过新门禁 | 现有直接消费者测试，预约写者集成；PDA navigation/workbench/trip-handover测试 |
 解锁实施后的最低检查按实际改动执行：Admin定向 `pnpm test`（上述页面／组件/API及 `prototypeContract.test.ts`、实际直接车次消费者），`pnpm typecheck`，最终全量 `pnpm test` 和 `pnpm build`；公共密度合同由总控安排；PDA运行 `node --test tests/fulfillment-workflows.test.mjs tests/business-identifiers-ui.test.mjs` 及实际受影响的navigation/project-contract/workbench/trip-handover测试，最终 `npm test`、`npm run build:h5`、`npm run build:app`。具体不重复跑未变输入；离线通过不等于真实HTTP、页面或PDA硬件通过。
 ## 首批实施结果（14:36前历史检查点）
 已按共同契约第八至十节解锁，不再停在仅准备阶段。2026-10-19当前可独立集成的切片：
 | 实际文件 | 变化与结果 |
 | --- | --- |
 | Admin `pages/DispatchDetailView.vue` | 保持独立路由与返回语义，将连续四块改为仅四个Element彩色图标页签：车辆信息、排车信息、单据信息、关联订单明细；使用density-element-tabs、density-contained-tabs、density-tab-icon，删除旧分区布局样式，不写公共CSS、不改附加能力。当前数据读取仍待原子接入新DTO，不声称字段缺口已解决。 |
 | Admin `pages/DispatchDetailView.test.ts` | 增加真实Element页签顺序、激活状态、可见内容和不重复请求的行为回归。6项通过。 |
 | Admin `layoutAcceptance.test.ts` | 将已被本批四页签取代的document-section CSS断言改为公共页签及精确四页签合同；其他页面断言保留。 |
 | Client `views/DeliveryOrderCreateView.vue` | 删除旧客户直接创建这类派送的生产页面，不保留跳转别名或假成功页。 |
 | Client `views/DeliveryOrdersView.vue` | 移除创建按钮、入口事件和独立创建权限消费，保留全部本客户列表／详情／筛选。 |
 | Client `api/deliveryOrders.ts` | 移除createDeliveryOrder、DeliveryTransferPayload/Result，保留本客户分页、详情、费用读取、签收资料及鉴权二进制下载。 |
 | Client `deliveryOrders.test.mjs` | 改为平台专属安排边界，确认无客户POST、无创建页／按钮／路由／权限映射，保留客户读取隔离、签收数量、文件和负向权限回归。 |
 | 总控集成，非本任务写入 | 总控已移除Client `order-management/routes.ts`中的orders/delivery/create整段，以及 `tenant-management/contracts.ts`中该创建权限的分组／映射。`clientNavigation.test.mjs`旧权限仅负向用例保留。 |
 已执行证据：Client全量 `pnpm test` 601/601通过，`pnpm typecheck`通过，`pnpm build`通过；Admin `pnpm typecheck`和`pnpm build`通过。最终定向命令 `pnpm test src/modules/overseas-warehouse/pages/DispatchDetailView.test.ts src/modules/overseas-warehouse/layoutAcceptance.test.ts src/modules/overseas-warehouse/pages/DispatchesView.test.ts src/modules/overseas-warehouse/pages/prototypeContract.test.ts src/modules/loading-lists/components/LoadingListsView.creation.test.ts --maxWorkers=2` 为5文件66/66通过（9.62s）。首次Admin全量406文件、3386测试中3384通过、2失败：本批旧布局CSS断言（已更新且定向通过）及未改装柜创建用例5秒超时（隔离通过）；`pnpm test --maxWorkers=4`最终406文件中397通过/9失败、3386测试中3375通过/11失败（557.59s）；11项全部报5秒超时，分布为audit/CustomerAuditLogsPanel、customers/CustomersView、finance/FinanceG3G4Views三项、container-loading/GlobalSmartLoadingView、ocean-bookings/OceanBookingDetailView.release、overseas-warehouse/DispatchesView、RelabelOrdersView、warehouses/WarehousesView、warehouse-resources/pallets/PalletsView。没有放宽超时或修改这些生产页，不能声称全量通过。共享工作区其他写者仍有在途变更，上述结果绑定当时读取输入，不代表整车新接口或未来集成候选通过。真实视觉仍“待人工截图确认”，未做真实业务或PDA硬件验收。
 上述为14:36前首批历史输入。后续原生DTO、五阶段和PDA接入已按第0/0.1节实际骨架推进，当前切片、验证和未关闭缺口统一见本文末“原生接口接入交付检查点”；首批Admin typecheck/build成功不代表当前集成候选通过。
 本任务保持当前分支和工作区，不触及appointment-calendar、adminDensity.test.ts、自营等他人在途修改；只在自身对话报告，由总控主动读取。后续按公共提供者实际DTO和总控精确移交推进，不自行扩大日历新增预约、客户内部平台操作或附加功能整页。
 ## 本轮原生类型接入的受保护编译断点（总控接线）
 2026-10-19总控14:36正式绑定13个公共port文件后，已删除旧DispatchSummaryDto、PreArrangeDispatchDraftPayload及preArrangeDraftDispatch导出，没有保留旧状态或字段别名。当前真实typecheck在下列保护中的文件报错；这些文件及测试仍未写入，本表供总控按精确写者处理。
 | 文件／符号 | 真实断点与最小接线 |
 | --- | --- |
 | WorkDispatchForm.vue:imports/result/save | DispatchSummaryDto与preArrangeDraftDispatch已移除。改用CommandResult、DispatchDetail、DispatchDraft/ConvertDraft及convertDispatchDraft；后续读新详情。createDispatchDraftContainer改为一个对象{recordVersion,idempotencyKey,draftToken,capacity}返回完整Draft，容器标识为draftContainerId；lockDispatchDraftPallet改为DraftSelection（当前草稿版本、原键、容器、真实CargoSelection.sourceVersion）；releaseDispatchDraft也携草稿版本/键。 |
 | WorkDispatchForm.vue:load/select/save | 三处单客户限制应移除，保留逐来源batchAllocations的客户断言；同仓由服务端Candidate.warehouseId/sourceVersion及原子转换复验；不能按客户拆若干旧客户排车再共车。 |
 | WorkExistingDispatchForm.vue:load.matches | getDispatch现返回DispatchDetail。appointmentBatches实际在dispatchInfo.appointmentBatches；客户逐batch的校验留在此数组，不提升到旧顶层字段。`DISPATCH:${row.id}`已无row.id，需原域权威批次引用校验，不重加内部ID或拼编号回退。 |
 | WorkExistingDispatchForm.vue:prepare/template | 删除旧PENDING_DEPARTURE、workflow、overseasWarehouseId/Name和packageCount消费；新status ACTIVE/CANCELLED，stage五项、actions的EDIT/ADD_CARGO等Gate，数量在counts。直接打开同一dispatchNo的独立详情继续维护资源，不再调用TripPreparationDialog；起运仓如需展示，从真实ListRow按dispatchNo精确匹配获取，不从订单目的仓推导。 |
 | WorkSharedTripForm.vue:prepare/template | getDispatch现返回四块详情，不存在workflow与旧仓字段。整段“两张客户排车安排同一车次”与新模型冲突，改为同一排车加同仓真实货物（AddCargo）或指向该单加货；不保留双单prepare/bind写协议。 |
 | 三个同名.test.ts | Mock从旧客户Summary切换真实Detail/Page/Draft/CommandResult；缺版本拒绝、0合法、完整batch/source/货物归属、原事项关闭/原单跳转及未知请求恢复继续回归。WorkBatchContinuation/WorkDetailPanel实际受影响用例由总控一并协调。 |
 上表是保护中文件的接线清单，实际原生切片已完成到下节检查点；整体typecheck尚未通过，不把局部测试通过当成集成完成。日历新增预约不在该接线范围。
 ## 原生接口接入历史检查点（2026-10-19 15:25，后续状态见文末）
 本节替代前述首批检查点中的待实施状态。按总控14:36派工完成本任务独占的Admin/PDA原生接入切片；整体集成仍未通过。再次逐个核对实际13个公共Java port文件SHA-256，全部与主流程设计第0节一致（13匹配、0变化）。本任务17个生产文件候选聚合SHA-256为`15931a9917bb562068eebfa7583288b41d653cbeb1819abe5dc17e74eb22239d`：按完整仓库相对路径字典序，将每项“路径+LF+文件原始字节+LF”顺序输入SHA-256；清单为Admin本表13个排车生产文件、Master Data index.ts和PDA三个生产文件，测试与本文不计入。自查和验证绑定此候选。
 不改Java，不保留旧DispatchSummaryDto、PENDING_DEPARTURE、旧trip版本发车、旧complete路径或旧参数别名。
 | 本轮实际文件 | 已实现行为 |
 | --- | --- |
 | Admin `dispatchContracts.ts`、`api/dispatches.ts` | 对应实际四块Detail、Page/Statistics、CandidateList、Draft/ConvertDraft、LoadingPreview、ArrangementPreview及动作判别CommandResult。已有单写入严格recordVersion，缺失/null/负数/非整数字符串/不安全number拒绝，显式0合法；长标识不转Number。预约更新仅支持referenceNo和预约自身recordVersion。移货实际为POST remove，装车完成为loading-complete；草稿转换完整组提交，不调用旧standalone pre-arrange。保留原预约域getBatchDispatchCandidates提供者，不伪造第三套协议。 |
 | Admin `dispatchPresentation.ts`、`pages/DispatchesView.vue` | 原生五阶段、独立ACTIVE/CANCELLED/ALL、装车前三个分区（车辆信息、调度审核、理货审核）；分页/统计由服务端返回，丢弃迟到旧查询。写按钮同时核对严格boolean Gate和独立权限。审核、重审、加货、实载、安排与发车直接弹框；BOL鉴权Blob与按需路线读取保留，不逐行请求详情。列表提供跨筛选范围的原请求恢复入口。 |
 | Admin `pages/DispatchDetailView.vue` | 独立详情仅四个彩色图标Element页签，公共密度样式；真实vehicleInfo/dispatchInfo/documents/orderDetails，显示全部客户派送单及实际更新时间/备注。订单表保留服务端来源归属、客户、入仓码、真实集装箱与未知测量，不前端分摊或用内部ID回退。 |
 | Admin `components/SmartDispatchDialog.vue`、`smartDispatchWarehouseTab.ts` | 明确真实起运仓、空单建单、候选完整性/来源版本校验、显式恢复服务器草稿、逐组加货/移货/释放/原子转换。保留仓库展示Tab、来源单号/入仓码/托盘码/目的地地址邮编、集装箱及参考重量体积。每个容器分别维护车辆/司机/时间/备注，允许同仓跨客户；预约分配仍核对逐来源客户。草稿未知请求冻结原完整body/key/version，转换成功凭据先保存，全部新单详情核对后才清除；后续GET失败不再次转换。 |
 | Admin `components/DispatchResourceFields.vue`、`overseas-master-data/index.ts` | 通过实际公共候选API分别按权限查询车辆/司机，分别支持MASTER/EXTERNAL及混用，模式切换只清本资源。外配容量、证照号/到期/预计结束直接维护，不创建主档；保留已绑定证据。已关联主档选择器显示车牌/姓名或明确待核实，不泄露长ID。附件提供者仍未接入，见下表。Master Data只增加实际候选/类型公共导出，未删改原成本、容量、预订、交接、释放实现。 |
 | Admin `components/DispatchWorkflowDialog.vue` | 1120px维护/加货/实载/安排，760px两审核；驳回、退回、取消明确原因。实载只自动使用actual=true证据或相同manifest的confirmedLoad，参考分摊不填实测；逐托正数重量体积、整数托位及已匹配卸货序号验证。装车完成与实际发车独立。弹框目标变化立即重读，不能拿旧单版本/资料提交另一单。 |
 | Admin `components/DispatchArrangeFields.vue` | 一次组合GET，不再两个辅助GET拼快照；按客户+目的地显示全部货物、派送字段、真实报价和原费证据。每服务显式覆盖选择并携版本/hash，外接报价匹配同客户+入仓来源；部分覆盖仍保留未覆盖费用，不能跨客户免单。只显示适用服务的新增费用；不填伪零，不平均分摊整车费。一次POST发送全部组。 |
 | Admin `dispatchCommandRecovery.ts` | 同一登录主体共享一个完整未决命令，sessionStorage留原动作/业务号/body/key/version。未知结果先按原键查询，真实404才同键原请求重放；校验同单/动作/键及原装车/发车结果。先持久原结果，再GET当前详情并确认版本不早于命令版本后清pending；原结果不覆盖最新阶段。首次明确4xx业务拒绝可重新核对，5xx和网络结果未知、或前次未知后的迟到拒绝均不能丢键重建。CREATE与已有单动作恢复分开，不会将原DEPART发到建单API。 |
 | Admin直接测试及类型/索引 | 重写原API、列表、详情、Smart与仓库Tab测试；新增Workflow/Resource/Arrange、命令恢复、原生fixture测试。prototypeContract、layoutAcceptance、types合同只更新本批被替代的排车断言，其他页面断言保留。`index.ts`导出实际新公共类型，`types.ts`删除旧DispatchListItem。 |
 | PDA `src/api/fulfillment.js` | 只消费原生PdaTask/actions/items/positions/returnCartons，0版本合法，缺版本拒绝；pick/loading-complete/depart各自带原生版本，新增loading和commands GET。删除旧completeDispatchPicking和tripDepartureRequest，不提交客户/仓作用域；普通outbound与cargo-discard API保持。 |
 | PDA `src/stores/fulfillment.js` | 排车保存完整pendingCommand，按登录人+冻结仓隔离恢复；不再用“同内容同键”吞掉下一次相同数量的实拣。结果确认才清命令，普通outbound保留原pendingKeys语义。 |
 | PDA `src/pages/dispatch/dispatch.vue` | 原生五阶段与Gate；真实实物码/退货箱唛拣货，错码清旧选择，同托多客户明细不能静默取首行。仓位选择跳过已拣分配，本次量同时受该位置可用量、分配余量和本明细余量限制。空单不核平；全部真实拣货+服务端pickingReconciled才可打开实载。实测确认独立于发车；未知重试与成功后GET失败保留原命令，支持另一端已推进阶段时读回最新事实。默认任务列表、显式resume、只读在途交接组件继续保留。 |
 | PDA直接测试 | 同步fulfillment-workflows既有有意义断言，保留普通出库/收货/退货测试；新增dispatch-workflow真实页面方法harness，覆盖版本0、物理来源、分配上限、两级资格、未知POST、GET失败、跨端新阶段、5xx未知、旧详情版本和下一次等量扫码新键。 |
 验证输入为当前工作区未提交候选，无隔离分支/副本，未提交、推送或部署：
 - Admin定向12文件96/96通过（15:23，14.23s）：api/dispatches、dispatchCommandRecovery、DispatchDetailView、DispatchesView、SmartDispatchDialog、DispatchWorkflowDialog、DispatchArrangeFields、DispatchResourceFields、prototypeContract、smartDispatchWarehouseTab、layoutAcceptance、types。随后本地版本校验错误改为明确DispatchInputError，受影响API/恢复/Workflow再跑3文件38/38通过（15:25）。
 - Admin最新完整`pnpm typecheck`仍失败，错误仅在保护中的WorkDispatchForm、WorkExistingDispatchForm、WorkSharedTripForm及其同名测试；本任务原生实现/直接测试无剩余类型错误。精确符号见前表。`pnpm build`前置即vue-tsc，当前不再重复打包或宣称构建通过；总控完成受保护接线后再验。未通过的全量11项5秒超时保留在历史记录，本轮依指令未重跑全量追绿、未放宽超时。
 - PDA最终`npm test`280/280通过；最后代码输入的`npm run build:h5`和`npm run build:app`均成功，H5初轮样式@import顺序警告已修正并重编译确认消失。App仅资源编译，不代表APK签名或设备验收。
 - Client代码本轮未变；此前601/601、typecheck/build通过记录仍绑定此前切片，不重新触发全量。
 - Admin/PDA独占变更`git diff --check`通过（仅Git LF/CRLF提示）；构建产物不纳入源码。自查覆盖实际13个公共Java records、请求序列化、直接消费者和失败/恢复分支，未冒充独立代理审查。
 | 15:25时尚未关闭事项（非当前结论） | 当时事实与接线边界 |
 | --- | --- |
 | 三个预约表单与同名测试 | 当前仍引用被删除的DispatchSummaryDto、preArrangeDraftDispatch、旧draft id/签名、PENDING_DEPARTURE/workflow/顶层仓及appointmentBatches。保持只读，由总控/精确写者同步到同一原生接口；不得恢复旧类型别名遮盖断点。当前Admin尚不能作为可发布集成候选。 |
 | 附件取证/预览 | Vehicle.evidenceFileIds和Driver.evidence.fileIds已真实保留，但公共骨架无本趟证据上传/绑定/鉴权下载元数据提供者；页面明确未接入。不编造File路径、不允许手填内部文件ID，不以空证据声称审核闭环。 |
 | 实载卸货序号 | LoadingPreview已有deliveryIndex，双端只使用真实返回值；没有目的地/路线选择及更新提供者。缺值时明确阻断loading-complete，不猜顺序、不用行下标替代。 |
 | 装车前移除货物UI | 已接实际POST items/{itemId}/remove及版本/原因API测试；平台Detail只有orderDetails/sourceKey，无可移除dispatchItemId。LoadingPreview是逐托实载，ArrangementPreview.cargo明确为不可变实际拣货来源，不能假设它覆盖装车前未拣明细，也不能借PDA任务接口取平台数据。故未伪造移货按钮或用sourceKey/仓托盘ID冒充itemId，需主流程提供装车前权威明细读取后补UI。 |
 | 权限/入口/最新指引 | 本任务直接动作消费create、loading-complete、depart以及既有审核/edit等权限，统一IAM/SQL/导航由总控集成；入仓旧smart-dispatch权限消费者也需同步，不加OR旧权限降级。PDA AGENTS的旧canPick/tripDepartureRequest说明、Admin局部指引相关旧模型说明应由总控在最终索引维护批次更新；本任务未争写AGENTS。 |
 | 真实验收 | 未调用真实HTTP、未写测试业务数据、未运行环境SQL/部署。双端Mock证明前端不重复发送和正确恢复，不证明服务端并发事务/库存/费用唯一性；后端及全链验收另核。Admin/Client仍待人工1920×1080、100%截图确认；PDA扫码枪/音效/离线重连/安装仍待真机。 |
 仅在本对话交付供总控主动读取；没有跨对话回复、创建新聊天或内部代理。新增日历预约仍在本任务范围外。
 ## 六表单有限接线检查点（2026-10-19 15:50）
 总控按主契约第九节精确移交WorkDispatchForm、WorkExistingDispatchForm、WorkSharedTripForm及三个同名测试；修改前逐文件git status无差异，并记录原SHA-256。六文件没有发现其他写入，当前继续为本任务唯一写者；其他日历文件仍未修改。
 - WorkDispatchForm改为从真实ReceivingContext.batch.originWarehouseId限定同仓，将原批次实物与原生Candidate.sourceVersion精确关联，一个服务器草稿容器直接转换一张跨客户整车；逐来源batchAllocations保留客户/批次/目的地/数量，错客户/错来源/重复实物/未知数量/跨仓/不完整候选阻断。服务器草稿token和版本真实取得，不再客户端造token或按客户拆单。
 - 草稿各步完整body/key/version和转换CommandResult按登录人及批次范围持久；未知响应只重放原步骤，原成功结果先保存再读详情，GET失败不再转换；事项关闭后的只读面板仍可核对原未决请求。首次明确拒绝才可显式读取本拥有者草稿新版本并释放，不以迟到冲突清除原未知命令。
 - WorkExistingDispatchForm消费dispatchInfo.appointmentBatches逐客户验证。DISPATCH批次通过实际resolveBatchWork核对批次与业务号，不从内部ID拼字段回退；原单只读/继续维护均导航独立详情。
 - WorkSharedTripForm保留文件名与父组件事件边界，内容改为同一排车ADD_CARGO，严格消费Gate/阶段/版本并复用实际WorkflowDialog及全局原命令恢复。删除另一客户子单输入和TripPreparationDialog共车写流程，不搬已扫码货物。
 - public overseas-warehouse/index.ts只补实际原生API/类型/Workflow和命令恢复公共导出，未恢复旧别名。原批次分批、已有单恢复、原事项更新/跳转、剩余实物显式读取和unknown导航保护继续回归。
 已运行：三个表单、WorkBatchContinuation、WorkDetailPanel及本任务原12个排车直接测试共17文件142/142通过（20.67s）；完整pnpm typecheck通过；pnpm build包含再次vue-tsc和Vite构建均成功（Vite5.33s，仅已有大chunk提示）。此前三个表单造成的Admin类型阻塞已解除，不能把15:25的阻塞记录继续当作当前结论。该点后按总控新移交读取DispatchWorkModels与实际items/route/evidence端点，继续补三个此前缺提供者的UI，不把端点存在当作真实HTTP验收。
 ## 历史候选检查点（2026-10-19 16:03，已由下方 Long 修正候选替代）
 六表单检查点后，已按总控追加移交完成原Admin独占范围的移货、既有路线排序及本趟附件UI。读取实际新增`dispatch/port/DispatchWorkModels.java`（SHA-256 `1e91da656e38aebbc554b4b4275b080d387e6bdb2eefaa14d5ae1ebd5b1aec64`，比较时忽略大小写）、DispatchAggregateController、DispatchAggregateService、DispatchEvidenceGateway/HttpDispatchEvidenceGateway，以及FleetTripService真实站序校验；未修改这些Java提供者。
 | 本次生产变化 | 已完成的实际行为 |
 | --- | --- |
 | `dispatchContracts.ts`、`api/dispatches.ts` | 精确接入DispatchWorkModels.Items/CargoItem、Route/Stop/RouteCommand和File元数据；GET items、GET/PUT route、POST multipart evidence/{VEHICLE或DRIVER}、GET文件元数据及/content。上传FormData只有file，不伪造业务类型、客户/仓范围或文件归属；所有版本化请求继续拒绝缺版本并接受0。 |
 | 移货UI | 列表和四页签详情直接动作打开真实items清单，展示客户/订单/入仓码/托盘/应装/真实已拣及逐项remove Gate；只允许选服务端允许且pickedPackages=0的真实dispatchItemId。原因必填，POST path使用该真实明细ID；原itemId作为本地恢复目标与原body/key/version一起保留，不放进ReasonCommand JSON，不用sourceKey或仓托盘ID冒充。换标整源/已扫码等阻断原样保留。 |
 | 路线UI | 原列表/详情增加“调整卸货顺序”居中弹框，仍只有四个详情页签；起运仓只读，只对实际Route.stops中的既有目的地上/下移。保存检查完整唯一目的地集合、版本、原因和Route.edit Gate；不能新增、删除、猜目的地，包含外接点。请求只交原destinationKeys顺序，后端保留真实名称地址。完成提示明确重新核对两级审核。 |
 | 路线未知结果 | 后端实际账本动作是EDIT，前端只增加本地operation=ROUTE标记来保留原端点选择；该标记不进入公开请求。重放仍原动作/键/body/version，不能把路线原请求发送到资源Update；原CommandResult核对及GET当前详情规则继续复用。 |
 | `components/DispatchEvidenceFiles.vue` | 新增本车、两种实际证据类型的上传/替换/移除引用/鉴权预览组件。限PDF/JPG/PNG、10MiB；成功且元数据校验后才更换待保存引用，失败保留旧引用。上传本身不伪装成主单保存，随后通过原生版本化EDIT保存Vehicle.evidenceFileIds或Driver.evidence.fileIds，不自动删除File对象。 |
 | 附件接入点 | 车辆维护弹框可上传并保存本趟证据；两级审核弹框及车辆详情页签只读预览。空单建单时尚无整车身份，提示先保存再维护附件，不编造创建前文件归属。Resource主档切换、模式、容量和证照输入保持。 |
 | 图片/PDF与失败保护 | 当前弹框按需读取元数据，只有用户预览才GET本车/content Blob；图片900px居中，PDF用户点击时先开新窗再放入鉴权Blob URL。JSON业务错误不能当图像；身份/内容类型/大小不符拒绝预览；权限/网络错误保留code/requestId/traceId。切单、关闭、卸载后迟到响应不绑定/打开；撤销图片和卸载时回收URL，PDF URL定时回收。无匿名存储地址或内部ID显示回退。 |
 本轮最终离线证据：
 - Admin相关18文件155/155通过（15:59，22.12s）：六表单对应三个测试、WorkBatchContinuation、WorkDetailPanel、原生排车API/恢复/列表/详情/Smart/Workflow/Resource/Arrange/Evidence、原型/密度/仓库Tab/类型合同。新增有意义回归包含真实itemId恢复、已扫码禁止移货、外接目的地不得丢失、路线原端点重放、只读附件、替换失败、切单迟到上传、JSON错误、关闭后迟到内容、PDF与弹窗阻断等。
 - 路线成功提示与资格禁用最后收口后，受影响Workflow与WorkSharedTripForm再跑2文件13/13通过（16:01，3.96s）。
 - 完整`pnpm typecheck`通过；当前最后`pnpm build`再次包含完整vue-tsc并成功打包（Vite4.09s）。只有大chunk常规提示，没有放宽类型或测试超时。`git diff --check`通过，仅Git行尾转换提示。
 - PDA本轮源码未变，沿用此前280/280和H5/App资源构建通过证据；Client仍为此前未变601/601及typecheck/build证据。未新增全量Admin追绿运行，历史11个超时不因此宣称消失。
 自查/验证绑定21个本任务生产文件，聚合SHA-256为`4d27e7fef94948d7169703c008a35e3e9ce86af8b2a0bc09effaff76842c32bd`；算法仍为完整仓库相对路径字典序，每项路径+LF+原始字节+LF。清单为前一17文件、DispatchEvidenceFiles.vue及三个预约生产表单；测试、指引和本文不计入。此前17文件聚合只表示15:25历史输入，不能代替此候选。
 当前结论：本任务已解除此前三个预约表单的类型阻塞，并完成三个新增提供者的UI消费，可以交总控集成；仍未提交/推送/部署、未启动后端、未写测试数据/SQL、未执行真实HTTP。尚需主后端对运行端点、批次关联、路由、版本/幂等/并发及完整持久化链统一验收，文件/货物/路线真实提供者运行状态由其实际检查证明。LoadingPreview若仍缺deliveryIndex或真实测量，双端继续阻断，不因路线UI存在而猜值补齐。Admin/Client视觉仍待人工1920×1080、100%截图，PDA硬件/安装仍待真机。统一权限/OpenAPI/索引由总控维护；WorkDetailPanel、WorkCreateAppointmentForm、AppointmentCreatePanel、planningApi、日历面板和adminDensity.test.ts均未修改。
 ## 历史候选：Long 响应边界修正（2026-10-19 16:39，已由下方批次版本候选替代）
 已按总控授权解除本任务原有生产文件与直接测试的冻结，仅处理已确认的 Long 响应问题。common-web 的 Long/long 序列化实际输出十进制字符串，公共 JSON 解析器保留引号内的字符串；此前 WorkDispatchForm 的可用箱数严格比较、Workflow 的已拣数量零判断，以及附件元数据/Blob 大小比较因此错误阻断。本候选在排车 API 响应边界统一修正，保留既有组件业务判断，不向各页面散落 Number 转换。
 - 新增 `dispatchWire.ts`，明确区分 HTTP Wire DTO 与应用内模型。统一校验并归一化全部实际 Long 数量：列表分页、Counts、统计/审核计数、候选、草稿 sources、明细应装/已拣、装载预览应装/已拣、文件大小、安排派送货物箱数/件数与出库/派送引用计数，以及 PICK/DEPART/ARRANGE_DELIVERY 命令结果、转换草稿内嵌结果。各实际 GET/POST/PUT/DELETE 消费边界均接入对应转换；Blob 内容仍走原鉴权下载。
 - 仅接受非负安全整数，字符串必须是规范十进制整数；缺失、null、布尔值、空白、带符号、前导零、小数、指数写法、NaN/Infinity 和超出 MAX_SAFE_INTEGER 的值明确失败。ID、sourceVersion、recordVersion、reviewRound 均保持无损；Java int/Integer 的容量、站序、批次分配箱数，以及可空托数、BigDecimal 测量/金额不按 Long 数量转换。未修改共享 JSON 解析器、DataTable 或规划 API。
 - PDA 仅加强原 normalizeDispatchTask 的已有转换：明细、库存位置和退货箱件数使用相同非负安全整数边界；既有数字和规范数字字符串均可读取，缺失及越界值阻断。ID 和 recordVersion 原样保留，出库等其他业务适配未动。
 - 三个组件回归经真实 parseApiJsonResponse 和实际排车 API 执行：候选 availablePackages=字符串12 对接批次 Integer12 后可整车创建；pickedPackages=字符串0 可以移除权威未拣 itemId；sizeBytes=字符串3 可通过附件元数据与 Blob 校验、预览并替换，长文件ID不变。API 测试样例已按真实 items/loading/evidence/draft/converted 响应结构收敛，原版本、端点、幂等与分组断言保留。
 - 同批较大回归发现附件预览 AppDialog 根缺少公共密度类，已仅在本任务 DispatchEvidenceFiles.vue 补 admin-density-dialog；未修改密度合同测试或其他共享样式。修复后密度与附件2文件38/38通过。
 最终离线验证绑定本候选：Admin受影响19文件209/209通过（16:38，24.24s），其中新增 Wire 边界与三条真实字符串组件链；完整 pnpm typecheck 通过，最终 pnpm build 再次包含完整 vue-tsc 并成功打包（Vite4.22s，仅已有大chunk提示）。PDA npm test 282/282通过，build:h5 与 build:app 顺序完成；git diff --check 通过，仅Git行尾转换提示。没有调整超时、使用 any 或执行真实HTTP；此前 Admin全量11项超时没有在本轮重跑或宣称消失。Client本轮未变，先前601/601及构建证据仍仅代表先前输入。
 当前聚合 SHA-256：`63feb551c2325450ddd0bd7840c81191620372aa2cf64ea2dfb97027282c429f`，共22个本任务生产文件。算法为完整仓库相对路径按字典序排序，每项依次写入“路径 + LF + 原始文件字节 + LF”后计算 SHA-256；测试和本文不计入。精确清单：
 `apps/admin-web/src/modules/overseas-warehouse/` 下：dispatchContracts.ts、dispatchWire.ts、dispatchPresentation.ts、dispatchCommandRecovery.ts、api/dispatches.ts、pages/DispatchesView.vue、pages/DispatchDetailView.vue、components/SmartDispatchDialog.vue、components/DispatchWorkflowDialog.vue、components/DispatchArrangeFields.vue、components/DispatchResourceFields.vue、components/DispatchEvidenceFiles.vue、smartDispatchWarehouseTab.ts、types.ts、index.ts；另含 apps/admin-web/src/modules/overseas-master-data/index.ts，apps/admin-web/src/modules/appointment-calendar/ 下 WorkDispatchForm.vue、WorkExistingDispatchForm.vue、WorkSharedTripForm.vue，以及 apps/pda-overseas-uniapp/ 下 src/api/fulfillment.js、src/stores/fulfillment.js、src/pages/dispatch/dispatch.vue。
 最新源码只读核对表明，SmartDispatchController 已采用 destinationWarehouseCode 与原生 drafts/pre-arrange 契约，DispatchPdaController 已采用原生任务/装载完成/发车/命令结果入口，平台 DispatchAggregateController 也已有 /{dispatchNo}/depart 并调用 DispatchDepartureService；旧检查点关于这些源码仍未迁移的描述不能作为当前结论。本文只证明本任务消费与离线验证，没有修改 Java、共享权限/OpenAPI或环境配置。
 可交总控集成；尚未提交、推送、部署、启动后端、写入测试数据/SQL或执行真实 HTTP。后端真实路由、权限、完整持久化和幂等并发链仍由总控统一验收；Admin/Client 人工1920×1080、100%截图与 PDA 真机扫码/安装仍待确认。本任务自查不冒充独立复核。
 ## 当前可集成候选：既有批次版本与权限接线（2026-10-19 17:38）
 按总控本轮精确授权，仅解除原排车模型/API/wire、SmartDialog、Workflow ADD_CARGO和既有Work排车表单对此版本字段的冻结；不触及日历新增预约、planningApi、面板生产逻辑、公共密度、PDA、Java或Maven。修改前已核对公共Java实际签名：DispatchContracts.BatchAllocation(..., Long recordVersion)、BatchReference(..., Long recordVersion)都要求显式非负版本且零合法；BatchReference的自动DISPATCH引用使用其真实主单版本。该文件读取摘要为73b5b83fcd0155bf09b18c18b1bd6a5bbb0175221102a13101248f92ca84f641。预约Provider的Allocation随后也实际增加recordVersion；AppointmentWorkDispatchCandidates第43行已用appointment.version().longValue()返回权威版本，前端不从Result.version、显示约号或默认零补造字段。
 本次生产变化：
 - dispatchContracts.ts的两个批次模型均增加必填Version字段；requireBatchVersions只校验并比较同批次版本，不改变原始值。0、字符串0及超过JS安全整数范围的长整数字符串均无损；缺失/null/非法/不安全number版本阻断，并提示重新读取候选。同一批次出现不同版本也阻断。
 - dispatchWire.ts在真实候选、草稿sources和原车详情批次引用的响应边界检查版本；沿用公共JSON解析器，大整型裸JSON经公共解析器安全转成字符串后保留，不把合法长版本当数量做Number转换。批次箱数仍是Java int，原Long数量校验保持。
 - api/dispatches.ts在直接创建、加货、全部组草稿转换前统一校验嵌套分配版本，跨组比较同批次版本；既有batch dispatch-candidates的分配必须带真实版本才交给组件。原请求对象与版本均原样发送。
 - SmartDispatchDialog和DispatchWorkflowDialog将每个真实BatchReference.recordVersion原样写入对应BatchAllocation；创建/加货仍使用原来源/客户/目的地/数量，整车顶层recordVersion独立。原键恢复保留完整原body和嵌套批次版本，候选之后变化不能改写未知原请求。
 - WorkDispatchForm使用原批次候选返回的allocation.recordVersion，核对同批次及原生引用版本一致后提交；不以Result.version代填。WorkExistingDispatchForm与WorkSharedTripForm生产无需改动：原详情经wire校验，既有加货经Workflow消费。index.ts仅公开本应用内部实际跨模块使用的版本校验入口。
 - 原入仓单入口前批已单独获准收口：InboundOrdersView.vue要求dispatch:list与dispatch:create，并在打开方法再次守卫；permissions.ts删除旧inboundOrderSmartDispatch键、增加dispatchCreate。直接3文件30/30已通过，该输入本轮未再改动。
 - 总控追加交付的CapacityInquiryTable.vue和CapacityInquiryDialog.vue修改前均无未提交差异，未见重叠写者；各只把bind动作旧smart门禁换成dispatch:create，capacity-offer:manage、booking-edit、trip:edit及业务/样式保持。负面测试继续证明旧smart权限无效，缺少其余任意一项也不能出现排入本车动作。
 直接测试修改为dispatchWire、dispatches API、SmartDialog、Workflow、WorkDispatchForm和WorkExistingDispatchForm的合同样例及回归；TripAppointmentPanel.test.ts是类型检查发现的直接模型消费者，仅补一处样例recordVersion，不改面板生产文件。CapacityOffersBehavior.test.ts新增两入口共享的四权正负矩阵。WorkSharedTripForm和CapacityInquiryDialog直接测试按实际影响重跑但未改断言。
 最终离线证据：批次包8文件145/145通过（17:34，30.52s），外接入口2文件38/38通过（17:36，4.39s），共10文件183项；包含零/长版本、缺失/非法版本、同批多版本拒绝、原键重试不换版本、已有关联读与加货、四权正例及旧权限负例。完整pnpm typecheck通过；最终pnpm build再次包含完整vue-tsc，Vite4.46s成功。git diff --check通过，仅Git行尾提示；没有重跑无变化的PDA全量和构建，也未重做全量Admin209或声称真实HTTP通过。
 候选指纹：原22文件清单的当前聚合为709936a8236fee3a20e3facf6b07d5a8590ac7f0784e4a3deefa1e475fb33fb4；合并前批2个入仓入口权限文件及本批2个外接入口后的完整26生产文件聚合为2047b6dd54146fb394e63ae433e569e6079110864116f7f56a6deeff48cf9351。算法仍为完整仓库相对路径按字典序排序，依次写入path+LF+原始字节+LF后SHA-256；测试和本文不计入。完整26路径：
 ```text
 apps/admin-web/src/modules/appointment-calendar/WorkDispatchForm.vue
 apps/admin-web/src/modules/appointment-calendar/WorkExistingDispatchForm.vue
 apps/admin-web/src/modules/appointment-calendar/WorkSharedTripForm.vue
 apps/admin-web/src/modules/overseas-master-data/components/CapacityInquiryDialog.vue
 apps/admin-web/src/modules/overseas-master-data/components/CapacityInquiryTable.vue
 apps/admin-web/src/modules/overseas-master-data/index.ts
 apps/admin-web/src/modules/overseas-warehouse/api/dispatches.ts
 apps/admin-web/src/modules/overseas-warehouse/components/DispatchArrangeFields.vue
 apps/admin-web/src/modules/overseas-warehouse/components/DispatchEvidenceFiles.vue
 apps/admin-web/src/modules/overseas-warehouse/components/DispatchResourceFields.vue
 apps/admin-web/src/modules/overseas-warehouse/components/DispatchWorkflowDialog.vue
 apps/admin-web/src/modules/overseas-warehouse/components/SmartDispatchDialog.vue
 apps/admin-web/src/modules/overseas-warehouse/dispatchCommandRecovery.ts
 apps/admin-web/src/modules/overseas-warehouse/dispatchContracts.ts
 apps/admin-web/src/modules/overseas-warehouse/dispatchPresentation.ts
 apps/admin-web/src/modules/overseas-warehouse/dispatchWire.ts
 apps/admin-web/src/modules/overseas-warehouse/index.ts
 apps/admin-web/src/modules/overseas-warehouse/pages/DispatchDetailView.vue
 apps/admin-web/src/modules/overseas-warehouse/pages/DispatchesView.vue
 apps/admin-web/src/modules/overseas-warehouse/pages/InboundOrdersView.vue
 apps/admin-web/src/modules/overseas-warehouse/permissions.ts
 apps/admin-web/src/modules/overseas-warehouse/smartDispatchWarehouseTab.ts
 apps/admin-web/src/modules/overseas-warehouse/types.ts
 apps/pda-overseas-uniapp/src/api/fulfillment.js
 apps/pda-overseas-uniapp/src/pages/dispatch/dispatch.vue
 apps/pda-overseas-uniapp/src/stores/fulfillment.js
 ```
 共享提供者仍在途，不能把上述前端离线证据当预约—排车端到端接通：17:38读取的DispatchAggregateService与DispatchDraftService候选构造仍分别在第158/265行传入空appointmentBatches；尤其Smart草稿逐托选择/恢复后需由真实Provider保留引用和版本，前端不能拿旧显示约号或旧候选补造。总控/主后端继续处理实际候选/草稿提供、数据库锁内批次版本、完整持久化和发车复验。尚未提交、推送、部署、执行真实HTTP或写环境数据。新增日历预约及车辆预约权威提供者不在本前端包。
@@ -0,0 +1,526 @@
 # 排车列表接口与数据设计
 > 2026-10-19 已按[正式契约](排车列表统一作业改造契约.md)第八至十节进入首批实现，替代仅准备门禁。四项业务选择已确认；公共Java契约骨架见第0节。运行端点、持久化主流程和集成尚未完成，骨架不表示已部署。仅在独占范围实现及离线验证，不提交、部署、执行环境SQL或真实HTTP；共同SQL/OpenAPI/权限由总控集成。其余尚未实现的设计文字不能覆盖正式契约。
 唯一写者：排车后端 `01a1524f-4f11-70c2-8a46-8e06e73a2d86`。总控 `01a15230-a9d6-7503-a8a9-d70691df49e5`；TEST 项目、host、cwd 按协作登记 2026-10-19 节。派送设计由 `01a1524f-56a9-7320-a5fd-8ff76fa4356b` 独占[另一设计文件](排车列表派送费用接口设计.md)，双方不并写。本文创建前该文件及本文均不存在，未发现本文其他写者；源代码工作区已有其他未提交改动，未覆盖。
 ## 0 公共Java契约骨架交接
 以下文件已经实际新增，均位于 `baiyue-firstleg/lastleg-service/src/main/java/com/baiyue/lastleg/dispatch/port/`，仅依赖JDK17，无业务Entity或对方实现类。所有下游以实际record组件/端口方法为准，不以旧准备稿伪造同义DTO。Execution与Completion已进入实际实现，草稿由总控分配的唯一写者实现；当前代码/验证交接以10.3为准，公共骨架不表示整链上线。
 | 文件 | SHA-256 |
 | --- | --- |
 | DispatchTypes.java | ecd710d123747fa28f1c39c6fbafcd58f7bbe8656717135b81c80ff0736177d2 |
 | DispatchContracts.java | 1c96bc5d4e471714a5f5829a5dd264aedd78d08deaa376ad5e8a11d59e2cac5e |
 | DispatchCommands.java | f487b7bf7c21aac194b3525aa706da4fa6ab8ba0852de7eed3c68282d5a8497c |
 | DispatchResults.java | 2355f33a878c8aba599122b4d94fb97f88db1b27622f541f3082dadc27dc1e94 |
 | DispatchViews.java | f5f8a273e693496f27075fb8d2e839ee33f6b35317e107048025dbcb96664b85 |
 | DispatchDeliveryModels.java | a8452477225b71400996992896f0a8a3ed385118cf988d5c4ed7b014c4e85896 |
 | DispatchExecutionPort.java | 06ab14af3879ba90a7f4e5d6b2c56a8142bbdc3068911c8eaa9336807c8c8457 |
 | DispatchPlanningModels.java | 33e3512544ec49aa6d9dd332cfc2e271303519058f8aac978125d91fa3c72f8d |
 | DispatchPlanningPort.java | 2ecc408b6d5adb31fab23fa677916608e4434013716bade9a88dbd2655f64b88 |
 | DispatchDeliveryPort.java | 1963618f71d831482a1a8527da68467773721db980c84b5c970832b1c3dafbd6 |
 | DispatchCompletionPort.java | 4a222f0d3b3a34267f7469aa0242cf62486f70496c15481838ac889b5e64a76d |
 | DispatchSignalPort.java | 85b26c63d98f87abbc9ddbbcd5b18961ac32c4bb60e5cb74832997a4ff233c07 |
 | DispatchApi.java | 584a973627365c4987e4fad05bb26ca8dbea538c779472f0df83b9ee81302c25 |
 实际端口精确签名（类型均为同包对应容器内record）：
 - `DispatchExecutionPort`：`Context preview(Actor,String)`；`LoadingPreview loading(Actor,String)`；`Context lockForArrangement(Actor,String)`；`Optional<CommandResult> replay(Context,Actor,CommandIdentity)`；`void requireFreshArrangement(Context,long recordVersion)`；`CommandResult recordArrangement(Context,Actor,CommandIdentity,ArrangementFact,boolean alreadyArranged)`。lock方法只取得顺序锁及身份上下文，原命令恢复先于新命令资格；新命令必须调用fresh方法，不能以拿到Context视为已允许。
 - `DispatchDeliveryPort`（派送实现）：`ArrangementPreview preview(Context)`；`CommandResult arrange(Actor,String,ArrangeDelivery)`；`DepartureFacts departureFacts(Context,boolean lock)`；`DepartureResult markDeparted(Context,Actor,Instant,String commandKey)`；`NormalDeliveryFacts normalDeliveryFacts(Context)`。markDeparted仅改客户单据事实，不执行库存SHIP。
 - `DispatchCompletionPort`（主流程实现）：`CompletionResult reconcile(Signal)`，新事务内主阶段CAS与signal确认同提交。
 - `DispatchSignalPort`（派送实现）：`List<Signal> due(Instant,int)`；`void acknowledge(Signal,Instant)`（MANDATORY，同汇总事务）；`void failed(Signal,Instant nextRetryAt,String errorCode)`（父事务回滚后REQUIRES_NEW）；`void enqueue(String dispatchNo,String deliveryNo,long deliveryVersion,Instant occurredAt)`（原签收事务内）。due不持信号锁进入父事务；主流程唯一负责调度/退避/重扫。
 字段/端点对应：所有端点常量在DispatchApi。平台POST根→DispatchCommands.Create；PUT单号→Update；POST items→AddCargo；remove/cancel→ReasonCommand；submit-review→SubmitReview；dispatch-review/loading-review→ReviewCommand；return-to-review→ReturnToReview；双端loading-complete→LoadingComplete（新增真实measurements和manifestHash，不含补录packages）；双端depart→Depart；PDA items/pick→Pick；平台transfer-delivery→DispatchDeliveryModels.ArrangeDelivery。所有命令响应统一DispatchContracts.CommandResult，严格区分replayed与alreadyArranged；arrangement数组在result中，不保留单outboundNo。GET列表/详情分别为DispatchViews.Page/Detail，PDA为PdaTask，组合预览为ArrangementPreview。公开参数均recordVersion，0合法；Actor和CommandIdentity均服务端内部类型，不绑定HTTP请求体。
 实际列表统计record字段采用lowerCamelCase：ReviewCounts为notSubmitted/pending/approved/rejected，Stage键仍是五项枚举。实际详情VehicleInfo为vehicle/driver两个显式mode快照，DispatchInfo/Documents/OrderDetails保持四对象；以这些实际字段取代准备稿中的展示性伪代码。数值ID沿项目Long序列化约定输出，内部ID不作业务号回退。
 已运行JDK17 `javac --release 17` 编译上述全部生产骨架及 `src/test/java/com/baiyue/lastleg/dispatch/port/DispatchPortCompileContract.java`，随后离线合同输出 `PASS`，不启动Spring/HTTP/数据库。此结果只证明共享类型编译、五阶段/版本域/整车客户边界/完整单据数组及端口方法可静态引用，不证明持久化、鉴权或事务行为。Maven暂未运行，待派送写者稳定后由本任务统一执行。总控已提供路由合同5/5和Lastleg依赖合同既存9通过3失败（pickup→transfer未审阅边）的基线；本任务不修改pickup或豁免，后续分别报告新增结果。
 ### 0.1 骨架修订：缺版本、既有预约、实载与草稿
 公开已有单/草稿写请求的recordVersion均改为Long并在record紧凑构造器拒绝null/负数，显式0合法；创建主单/草稿没有既有版本。不是仅依赖Controller @Valid或Jackson对primitive的默认0。Update.vehicleAppointment已收敛为`DispatchCommands.AppointmentReference(referenceNo,Long recordVersion)`，没有status/appointmentAt写字段，保存时必须读取权威已有预约并复验版本；读模型仍可显示实际确认状态/时间，本批不新建预约流程。没有关联提供者解锁时该写接线待总控分配，不能拼一个本地确认状态替代。
 新增实际种子及端口见 `DispatchPlanningModels.java/DispatchPlanningPort.java`，源数据生产者已沿原方法核对，前端按下表接入；当前尚无新Controller映射或可调用运行端点，不以端点常量冒充实现。
 | 方法/路径 | 实际请求/响应类型 | 权威来源及边界 |
 | --- | --- | --- |
 | GET D/candidates | CandidateQuery→CandidateList（含Candidate.sourceVersion、selection、真实客户/起运仓/来源/目的地/参考测量/批次） | 原DispatchCandidateMapper/ReturnDispatchCandidateMapper及专用换标来源；sourceVersion将由服务端以稳定sourceKey、客户/仓/目的地、当前业务资格、真实来源库存组成版本及箱数、测量依据组成规范化SHA256，选择/转换锁内重算；不存在可靠摘要时不得填0 |
 | GET D/drafts；POST D/drafts | List<Draft>；CreateDraft→Draft | 当前操作者拥有的持久草稿；服务端生成token，主单和草稿版本分开、均不信任布局赋权 |
 | POST D/drafts/containers；POST D/drafts/snapshot | CreateContainer/DraftSnapshot→Draft | 带draft recordVersion及原请求键，保存类型化containers/sources；不继续使用raw containersJson作另一写协议 |
 | POST D/draft-locks/lock、unlock、release | DraftSelection或DraftRelease→Draft | 选择携sourceVersion，先复验仓、真实来源、实托排他，再保存；不释放其他拥有者占用 |
 | DELETE D/drafts/{draftToken}/containers/{containerId} | ReasonCommand（含草稿版本及键）→Draft | 原容器/拥有者/版本下释放，禁止无版本覆盖新选择 |
 | POST D/drafts/pre-arrange | ConvertDraft→ConvertedDraft | groups每项DraftVehicle(draftContainerId,Create dispatch)，每组一个真实整车；全部组一个事务，失败全回滚。vehicles每项为容器ID及完整CommandResult；不按客户拆单、不保留原客户PreArrange DTO |
 | GET D/{dispatchNo}/loading；GET P/{dispatchNo}/loading | LoadingPreview | 双端分别检查平台list权限或PDA角色/绑定仓；返回当前排车recordVersion、manifestHash、逐实托scheduled/picked、真实实测值/证据、缺项、confirmedLoad及loadingComplete资格。只读、不新增页签 |
 | GET详情 | Detail.dispatchInfo.appointmentBatches | 读取现有AppointmentWorkDispatchPort.references的真实batchKey/batchNo/customer/sources，不新增日历预约权威模型 |
 实载数据必须区分证据：`FleetTripExecutionService.loading/confirmLoad`已有load_json（manifest匹配时）是CONFIRMED_LOAD；`RelabelPalletMeasurementService.snapshots`有库存组成stockVersion的真实测量是RELABEL_MEASUREMENT，组成过期必须缺项。普通候选grossWeightKg来自订单/入仓快照按托分摊、volumeCbm来自allocated_volume_cbm，是ORDER_SNAPSHOT_ALLOCATION参考，MeasurementEvidence.actual=false，只显示suggested值，不自动填真实weightKg/volumeCbm；未知托位/卸货段也明确missingFields。LoadingComplete仅接受用户核对的measurements，不接受PDA箱数补录。候选摘要计算及这些真实服务适配尚待主流程实现，不声称GET已可调用。
 `dispatch/service/DispatchCommandCodec.java`已提供按Action封闭解码：Saved/Picked/Loaded/Departed/ArrangementResult具体类型由动作决定，拒绝缺结果字段或错误动作数据；复用正式时间/Long配置，树解析使用BigDecimal保留原精度，避免实测或费用经过double。其SHA256为`0e61307658495fb05e6dfed3b7029e89d1f92ab100bae777be8f4f7ef35871f4`。`DispatchPublicJsonContract`已实际通过15类请求missing/null/negative拒绝及显式0、预约伪造字段拒绝、全部Action持久JSON跨Codec/ObjectMapper实例恢复和原键重放；`DispatchPublicContractTest`供后续Maven统一执行同一组真实合同。此处是跨实例JSON恢复证据，未声称数据库事务/实际进程重启全链验收。
 本轮依赖合同重新运行仍为9通过3失败，仅输出总控已登记的3条pickup→transfer.entity及fleet出向变化，无本批新增类型边违规；不扩大到pickup修复或豁免。编译最初受到Windows命令行长度限制，已改用target内javac/java参数文件；随后发现并修复中间JsonNode导致实测BigDecimal精度/scale变化，最终合同通过。测试产物仅在target，不纳入源码。
 ### 0.2 严格摘要及命令账本首片实现
 独占新增 `dispatch/service/DispatchCommandHasher.java`、`DispatchCommandLedger.java`、`dispatch/entity/DispatchCommandRecord.java`、`dispatch/repository/DispatchCommandRepository.java`、`dispatch/mapper/DispatchCommandMapper.java`。摘要绑定actor/action/原版本/排车/规范载荷；业务摘要排除actor/版本/键，无序货物/费用/组排序而路线stops保持顺序。账本全局查询原键后先拒绝异主体，再判断动作/版本/摘要，结果恢复用真实Codec；保存只insert，不更新旧结果，唯一键冲突抛失败让外层回滚。方法MANDATORY，Repository/Mapper分层，不接入旧按customer分片幂等。
 总控SQL精确需求：`ll_dispatch_command`字段为`id BIGINT PK`、`dispatch_id BIGINT`、`dispatch_no VARCHAR(64)`、`action VARCHAR(40)`、`operator_id VARCHAR(128)`、`idempotency_key VARCHAR(255) NOT NULL UNIQUE`、`record_version BIGINT NOT NULL`（原请求版本）、`command_hash CHAR(64)`、`result_json LONGTEXT`、`created_at DATETIME(3)`（UTC）；各成功记录业务字段实际均应NOT NULL，创建前不落半成品行。dispatch_id/dispatch_no在创建成功结果产生后一起落账本。索引建议dispatch_id+created_at辅助审计，不以客户/操作者拆全局唯一键；中文备注由总控与基线/统一SQL一起集成。本任务未写共享SQL，也未执行环境SQL。
 新增真实 `dispatch/service/DispatchCommandLedgerPersistenceTest.java`：H2内存表+实际MyBatis Mapper/Repository保存、提交，关闭Session并换Codec/ObjectMapper实例后读取原结果；异主体/换版本/换单拒绝，以及严格摘要和安排业务摘要区别、无序组与有序路线差异均已独立编译运行PASS。测试仅覆盖此首片持久/业务身份，不表示Spring事务代理、并发主单CAS、所有客户费用回滚或完整HTTP通过；完整Maven仍待另一后端稳定后统一运行。公共13个port文件保持本次哈希，后续主单/审核/装车/发车及Controller集成尚未完成。
 ## 1 已核对的现状及必须收敛点
 以下 Java 路径相对 `baiyue-firstleg/lastleg-service/src/main/java/com/baiyue/lastleg/`。
 | 实际入口 | 当前事实 | 本批影响 |
 | --- | --- | --- |
 | `dispatch/service/DispatchService.java` 的 `preArrangeContainer/preArrangeDraft/requireSingleCustomerScope` | 主表 `DispatchOrder.customerId` 单客户；草稿每组也强制单客户；一组一张客户单 | 真实改为整车主单和跨客户明细，删除单客户头部推导，不能生成若干客户排车再仅在 UI 合并 |
 | `fleet/trip/FleetTripPreparationService.java`、`FleetTripService.bindDispatch` | 先建客户排车，再建/选共享车次，循环绑定多张排车；调度审核落在绑定记录 | 新建排车一次完成内部车次关联，审核归整车；不让用户先去车次页 |
 | `dispatch/dto/DispatchRequests.Stage` | 装车前对应 `PENDING_DEPARTURE`；装车中包含 `READY_TO_DEPART`；装车后实际映射到已发车 | 替换为五阶段真实状态，不能继续用旧映射表示装车后 |
 | `FleetTripExecutionService.reviewLoading/confirmLoad` | 理货通过要求实际装载 hash；实际装载又读取拣货就绪 manifest | 理货审核改到装车前，不能保留“先拣货才允许审核”的循环；实载事实核对独立在装车完成门禁 |
 | `dispatch/pda/service/DispatchPdaWorkflowService.pick` | 普通仓位依次 allocate/pick/ship；扫码成功是当前库存扣减点；逐入仓归属落在 `ll_dispatch_pda_pick_order` | 保留扣减时点和真实来源，装车完成、实际发车均不得再扣一次库存 |
 | 同类 `pick/completePicking` | 最后一条扫码自动将 task 设为 `COMPLETED`、排车设为 `READY_TO_DEPART`；`complete` 无版本且仅 PDA | 拣货核平事实与用户确认装车完成分开；最后扫码只开放确认资格，后台/PDA调用同一确认服务 |
 | `delivery/service/DeliveryTransferService.transferResolved` | 从主单 customer 生成一张客户出库单及按目的地拆分派送单，可在待发车/拣货中提前转派送 | 仅装车后安排，全车一次命令按客户再按目的地拆分；由派送后端实现 |
 | `dispatch/fleet/DispatchFleetAdapter.completion` | 签收或真实退回核平都可满足旧车次结案 | 保留旧附加结案能力；排车五阶段的“派送完成”单独只认全部正常签收，不能复用“退回也完成”的布尔值 |
 | `inboundplan/work/AppointmentWorkDispatchBinding/Mapper` | 分配事实带真实客户；但 bind 内按 dispatch 全量删除重建，部分 SQL 以 `d.customer_id` Join | 不可逐客户循环旧 bind，否则后一个客户覆盖前一个；须一次保存整车完整分配且以明细客户关联 |
 上一批修复保留：取消历史与活动关联分开；已拣货/发车不得取消；普通和退货换标按整申请全部应排托盘；同托多来源按拣货归属核算外接承诺和费用；退货箱不伪造普通库存仓位。工作区 `exceptionorder/service/ExceptionOrderDispatchReturnSourceTest.java` 有其他未提交修改，本任务只读。
 ## 2 推荐模型：排车是真主单，Fleet 保留资源与附加能力
 ### 2.1 主单与资源的唯一关系
 推荐继续使用 `ll_dispatch_order`，将其改为平台整车作业主单，删除 `customer_id`；不填写 0、假客户或所谓共享客户。每张整车主单自动且唯一关联一条 `ll_fleet_trip`，后者继续承载车辆司机占用、逐段容量、外接预订、成本、交接、资源结束及其历史。两个编号是不同职责的业务编号，排车列表只要求用户使用排车号；不能由前端按客户创建多张子排车后再隐藏。
 保留 `ll_fleet_trip_dispatch` 作为排车与资源记录的一对一关联，删除其中 `customer_id/review_json`，保留 `dispatch_id/dispatch_no/trip_id/trip_no/package_count/bound_by/bound_at`。增加 `trip_id` 唯一约束、原 `dispatch_id` 主键及 `dispatch_no` 唯一约束；本批绑定对象只有整车主单。`tripPurpose=PICKUP` 的接货流程不是本批排车流程，冻结前核实其直接调用，不能因收敛配送车次误改接货能力。
 整车新建事务内同时建立上述两条记录及关系；空单允许 Fleet 的未分配资源、未确定卸货点和未知计划时间，不通过虚构站点、计划时间或容量去调用旧 Create DTO。起运仓必须真实存在；空单没有 PDA 拣货事实、实际装载、出库单或派送单。Fleet 的 `PLANNED/IN_TRANSIT/COMPLETED` 继续只表示资源运输生命周期；排车 `stage` 是五阶段的唯一事实，排车 `status` 仅表达 ACTIVE/CANCELLED 生命周期，详见第3节。正常签收汇总不自动执行 Fleet 结案或资源释放。
 ### 2.2 主单字段
 | 字段 | 语义与约束 |
 | --- | --- |
 | `id/dispatchNo` | 内部关联键/全局唯一排车业务号；不将 id 当展示编号 |
 | `overseasWarehouseId/Code/Name` | 唯一起运仓及目录快照；有货物后禁止换仓；空单换仓如开放需同事务更新 Fleet，不得单改展示 |
 | `status`、`stage` | status仅ACTIVE/CANCELLED；stage仅BEFORE_LOADING/LOADING/AFTER_LOADING/DELIVERING/DELIVERED。取消保留实际停止阶段，不再推进；无第六阶段、无两字段同义状态映射 |
 | `recordVersion` | 主流程公共版本，所有前台可写命令必须提交并 CAS 递增；不再让 PDA 用 tripRecordVersion 代替排车版本 |
 | `cargoRevision/cargoHash` | 货物集合、真实来源/箱数、目的地与有效批次分配的修订号及稳定摘要；用于审核/装载/派送快照有效性，不与每次扫码计数混用 |
 | `reviewRound/reviewBasisHash` | 审核轮次与当轮关键事实摘要；摘要包括 cargo、资源身份/能力、计划/目的地及批次版本；无关备注不改变审核依据 |
 | `dispatchReview/loadingReview` | 当前轮状态、决定、原因、操作者、时间、依据摘要；历史追加保存，不能覆盖旧驳回记录 |
 | `vehicle/driver/carrier` | 详情读取内部 Fleet 权威分配及临时资源快照；不再允许排车、派送请求分别覆盖出两套司机车牌 |
 | `plannedDepartureAt/estimatedArrivalAt` | 可空计划时间，推荐 API 统一 ISO-8601 Instant、数据库 UTC DATETIME(3)；不把计划发车保存为实际发车 |
 | `loadingCompletedAt/loadingCompletionHash/departedAt/deliveryCompletedAt` | 服务端实际动作时间及装车事实摘要；摘要绑定cargo修订、真实pick/归属集合和实载快照，确认命令不接受客户端伪填实际时间 |
 | `itemCount/palletCount/packageCount/pickedPackageCount/shippedPackageCount` | 全车计数；托数按实物托盘去重；逐订单展示不可重复计算同一托盘 |
 | `remark/createdAt/updatedAt` | 详情所需备注及时间；updatedAt 当前 DTO 缺失需补齐 |
 `departAt` 旧混合语义在 API 中直接拆为 `plannedDepartureAt/departedAt`，同步消费者，不保留双字段别名。路线从起运仓和真实目的地按稳定顺序生成；请求不允许任意改路线字符串。
 ### 2.3 货物、客户及来源
 `ll_dispatch_item` 保留真实 `customer_id>0`，保留计划托盘、实物托盘、退回入仓、换标申请及目的地字段。一次货物选择以来源键表达，客户端不提供权威客户。服务端批量解析选中来源，复验客户、仓、暂扣、可排箱数、实物及有效占用后写入；允许同车不同客户/目的地，不允许跨起运仓。
 同托多来源不能用 `orderNo/orderRefs/inboundCode` 展示快照作为分摊依据。复用 `ll_dispatch_pda_pick_order` 的逐入仓/退回来源和真实箱数，不另造第二套逐箱库存模型；拣货前的容量/预约/候选读取真实库存组成，拣货后派送和费用读取不可变拣货来源。每条 pick 的客户必须等于对应 item 和真实来源客户。普通、退回入仓、`RELABEL`、`RETURN_RELABEL` 四类实际分支均保留；来源阶段不是客户端随意传入的业务状态。
 原来源锁 `ll_dispatch_pallet_lock` 保留真实客户与来源；实物托盘的全局唯一占用防止两个来源别名被分配两车，PLAN 与 RECEIVED 不能成为同一实物的两个有效锁。现有 `(customer_id,active_key)` 不足以单独证明实物全局排他，建议增加可空 `active_warehouse_pallet_id` 唯一索引，仍保留来源占用键；取消只释放属于当前主单的活动锁，不碰其他新单占用。
 PDA 每车一个平台作业 task，删除 task 的 customer 头部；pick 与 pick_order 继续每条真实客户。task 业务号沿正式编号生成器生成，不能继续 `DPDA + 内部ID` 展示。主流程操作/幂等归平台整车，不借客户表承载。
 ### 2.4 主档与临时外配
 推荐车辆、司机分别使用显式联合类型，支持一个选档案、另一个临时填写：
 - `vehicle: { mode: MASTER, vehicleId }` 或 `{ mode: EXTERNAL, plate, carrierName, capacity: { palletSpaces, maxLoadKg, maxVolumeCbm } }`。
 - `driver: { mode: MASTER, driverId }` 或 `{ mode: EXTERNAL, name, phone }`。
 MASTER 的状态、区域、能力、证照及占用由服务端主档复验；请求不能覆盖主档快照。EXTERNAL对应ID必须为空，不生成主档、不造资源ID，不进入主档ID占用锁。按已确认规则由建单人补齐本趟真实容量、证照证据及预计任务结束，调度审核核实；空单可先保存、审核前补齐，快照进入审核依据及发车历史。临时车牌与既有主档占用的交集仍须核对正式资源规则，不以mode跳过必要校验。
 ## 3 五阶段与审核/动作资格
 | 阶段 | 当前事实及允许的正常主操作 | 推进条件 |
 | --- | --- | --- |
 | 装车前 `BEFORE_LOADING` | 新建/加货/移除未拣货货物、修改资源与计划、提交调度审核、调度决定、理货决定 | 有货且资源等必需事实齐备才可提交；调度通过后才可理货；理货通过原子进入装车中 |
 | 装车中 `LOADING` | PDA逐托/来源拣货，后台/PDA确认装车完成 | 两审核当前轮有效；每条明细 PDA 真实箱数等于应装数量、正数、有完整来源且未超量；确认完成后进入装车后 |
 | 装车后 `AFTER_LOADING` | 后台安排派送，后台/PDA实际发车 | 派送/客户出库/费用核对完整且对应当前 cargoHash；资源、审核、批次接收资格再次有效；发车一次性进入派送中 |
 | 派送中 `DELIVERING` | 派送侧真实执行与正常签收、读取异常提示 | 所有当前有效派送均正常签收且逐客户逐来源数量覆盖本车实发后，自动汇总派送完成 |
 | 派送完成 `DELIVERED` | 只读本次作业；附加结案/资源结束保留原权限和入口 | 不自动释放车辆/司机，不把财务入账或成本结算当成完成条件 |
 审核流程字段为 `reviewState=DRAFT|DISPATCH_PENDING|DISPATCH_REJECTED|LOADING_PENDING|LOADING_REJECTED|APPROVED`，每张审核记录自己的 `status=NOT_SUBMITTED|PENDING|APPROVED|REJECTED`。正常为DRAFT→DISPATCH_PENDING→LOADING_PENDING→APPROVED；调度/理货驳回分别进入对应REJECTED状态，两种拒绝不改变五阶段，仍停装车前。驳回原因必填。修改后显式重新提交，从调度开始新轮次，不复用旧理货通过。审核变更不自动补 PDA 或装车事实。
 公开主单语义只保留一套：`status=ACTIVE|CANCELLED` 表示作业单是否有效，`stage` 表示唯一实际作业阶段，`reviewState` 表示审核子流程；不能再把Fleet状态、PDA task.status或单张delivery.status写到主单status。取消令status变CANCELLED，stage保留最后真实阶段供历史查询，所有主动作关闭；不生成CANCELLED阶段。主单新建为ACTIVE+BEFORE_LOADING，正常完成为ACTIVE+DELIVERED。数据库和DTO同步替换旧PENDING_DEPARTURE/READY_TO_DEPART/DEPARTED等主单状态，不保留旧字段别名。车辆状态、审核状态等嵌套字段均使用明确对象命名。
 审核有效性不以 `review.recordVersion == 当前版本` 判断：审核命令及扫码本身都会加版本，应以 `reviewRound + reviewBasisHash` 判断。货物集合/来源数量/目的地、关键资源或资格/能力、关键计划及批次变化使相关审核和装载/派送快照失效。装车前编辑直接回草稿；已进入装车后的变更策略见第 10 节，不以后台编辑偷偷回滚状态或重新扣库存。
 最后一次 PDA 扫码可记录 `pickingReconciled=true`，主单仍为 LOADING；后台/PDA再调用 `loading-complete`。后台没有数量补录字段，不允许用“全车总数相等”代替逐 item/source 核平。确认装车不要求已生成派送单，避免与“装车后才能安排派送”形成循环。
 服务端统一返回 `actions`，每个动作为 `{ allowed, blockCode, blockReason }`，覆盖 create/add/remove/edit/cancel/submit/dispatchReview/loadingReview/pick/loadingComplete/arrangeDelivery/depart。列表批量计算阶段/审核/派送摘要，不逐行查详情；详情返回同一资格函数。资格包括当前用户权限和仓范围，按钮隐藏不替代写入时复验。
 ## 4 提议 API 与 DTO（待冻结）
 统一 Gateway 前缀仍是 `/api`；Admin 客户端一般调用 `/platform/v1/...`，由 http base 拼接 `/api`；PDA同理。以下列完整公网路径。全部业务拒绝沿统一 ApiResponse 约定，不把代码内 ResponseStatusException 推定为最终 HTTP 响应。
 ### 4.1 平台接口
 令 `D=/api/platform/v1/last-leg/dispatches`。
 | 方法与路径 | 请求/响应提案 | 调整 |
 | --- | --- | --- |
 | `GET D`、`GET D/{dispatchNo}` | Query及统计见4.5；公开status/stage按第3节唯一定义，ListRow/Detail均带recordVersion | 保留路径，替换旧三阶段；平台customerId仅以真实item筛车，不改变主单归属 |
 | `GET D/candidates` | 按仓、来源类型、订单/目的仓过滤，返回真实 customer/sourceKey/availablePackages/sourceVersion/blockReasons | 保留路径，移除多客户 planIds 的单客户推断；有界批量读取 |
 | `POST D` | `Create { idempotencyKey, warehouseId, vehicle?, driver?, plannedDepartureAt?, estimatedArrivalAt?, remark?, cargo[], batchAllocations[] }` → CommandResult | 新入口；cargo为空建空单，非空同事务选货建车；没有customerId/tripNo字段；未取得服务端生成号时通过原POST同键恢复 |
 | `PUT D/{dispatchNo}` | `Update { recordVersion,idempotencyKey,vehicle?,driver?,plannedDepartureAt?,estimatedArrivalAt?,vehicleAppointment?,remark? }` | 保留路径；关键字段修改触发审核失效；不接收 status 或实际时间 |
 | `POST D/{dispatchNo}/items` | `AddCargo { recordVersion,idempotencyKey,cargo[],batchAllocations[] }` | 新入口；可继续在空单加货；批次分配提交最终完整快照，来源锁和保存原子 |
 | `POST D/{dispatchNo}/items/{itemId}/remove` | `{ recordVersion,idempotencyKey,reason? }` | 替换旧无版本 DELETE，保留删除历史与占用证据；不物理删除已执行事实 |
 | `POST D/{dispatchNo}/cancel` | `{ recordVersion,idempotencyKey,reason }` | 替换旧无版本 DELETE；取消前真实未拣货、无活动派送/出库；保留原取消历史及资金作废语义 |
 | `POST D/{dispatchNo}/submit-review` | `{ recordVersion,idempotencyKey,remark? }` | 新入口，建立审核轮次及当前依据 |
 | `POST D/{dispatchNo}/dispatch-review` | `{ recordVersion,idempotencyKey,decision: APPROVED或REJECTED,reason? }` | 调度审核归整车；不再按客户子单调度 |
 | `POST D/{dispatchNo}/loading-review` | 同上 | 理货审核在拣货前；不要求派送或实际拣货 |
 | `POST D/{dispatchNo}/loading-complete` | `{ recordVersion,idempotencyKey,remark? }` → CommandResult | 后台/PDA共享服务，后台没有拣货数量字段 |
 | `POST D/{dispatchNo}/depart` | 同上 → CommandResult | 新增后台入口，与PDA同一版本/命令持久化语义 |
 | `GET D/{dispatchNo}/prints/bol` | 全车真实来源、单据与客户分组的PDF | 保留路径，SQL去除主单 customer 假设；只读list权限 |
 | `GET D/{dispatchNo}/external-freight`、`POST D/{dispatchNo}/transfer-delivery` | 由派送设计冻结，主流程建议保留已有路径，POST带整车版本/请求键及逐客户目的地费用数据 | 只在 AFTER_LOADING 开放写；由派送后端独占，本文不定义费用具体字段 |
 `CargoSelection` 建议为判别联合类型：`{ sourceType: INBOUND_PLAN,planPalletId,sourceVersion }`、`{ sourceType: RETURN_RECEIPT,returnReceiptId,sourceVersion }`、`{ sourceType: RELABEL,relabelNo,warehousePalletId,sourceVersion }`；服务端再识别 RELABEL/RETURN_RELABEL，不信任客户传入阶段。sourceVersion 用于识别选择后事实变化；若当前来源没有可靠单行版本，应定义其真实组成摘要，不能常量填0。
 `batchAllocations` 保持 `planPalletId/batchKey/customerId/sourceKey/destinationKey/packageCount` 当前语义，customerId 是待复验的分配断言，不是写入客户权威。混合客户一次校验完整集合再保存。换标全申请选择门禁保留，不自动开放分批。
 ### 4.2 智能草稿与旧车次操作
 草稿能力保留：`GET /drafts`、`POST /drafts/snapshot`、`/drafts/containers`、`/draft-locks/lock|unlock|release`。草稿及每个装车容器不再带单客户归属，锁保留真实客户。每个容器最终生成一张整车主单，跨客户是同一 cargo[]，不是先按客户拆子单。正式转换建议由现有 `POST D/drafts/pre-arrange` 接收每组完整 Create 内容和持久请求键，组装车元数据可空；沿同一 create 服务实现。直接 `POST D/pre-arrange` 的生产消费者全部改用 `POST D` 后删除旧入口，不保留双建单协议。
 `fleet/trips/prepare`、`/{tripNo}/dispatches/bind|unbind`、客户单调度审核旧路径不再用于配送排车主流程，直接调用者同步收敛。旧“多张排车共车”入口必须替换为给同一主单加货；不能把旧操作留为绕过新状态门禁的写入通道。车次容量/外接/成本/交接/资源结束等非该旧协议能力继续保留，进入 DELIVERY 关联主单时遵守共同锁和审核失效规则。PICKUP及独立附加能力的精确接线由总控裁定，不能笼统删整个 Controller。
 ### 4.3 PDA 与恢复
 令 `P=/api/pda/v1/last-leg/dispatches`。`GET P`、`GET P/{dispatchNo}` 保留，返回本绑定仓整车 task，加入 `recordVersion/stage/reviews/actions/pickingReconciled`；items 保留真实来源、业务号、应装/已拣箱数。移除要求用户操作旧子单的 `tripDispatchCount`，内部 tripNo 可在附加追溯中读取，不能作为主动作请求身份。
 - `POST P/{dispatchNo}/items/{itemId}/pick`：现有 positionId/packages/productQuantity/cartonMark/remark/idempotencyKey 加 `recordVersion`；客户、起运仓均从服务端明细和Token取得。
 - `POST P/{dispatchNo}/loading-complete`：与平台同 `LoadingComplete` DTO；替换旧 `/complete` 的仅PDA完成协议，两端调用同服务。返回装车后阶段及动作结果。
 - `POST P/{dispatchNo}/depart`：保留路径，改用整车排车 recordVersion；与平台同 Depart DTO、结果和持久命令。
 - 两端均提供 `GET D或P/{dispatchNo}/commands/{idempotencyKey}`；按当前身份/动作权限/仓绑定及第6.2节授权表读取原结果。未知键返回业务错误 `DISPATCH_COMMAND_NOT_FOUND`（data为空，非成功结果），不把未找到解释成动作未执行；原POST同键同载荷可安全恢复。数据库提交中途尚不可见也可能暂未找到，客户端继续保留原键及payload，不能立即换键。跨主体键不返回原结果。
 统一公开 `CommandResult { dispatchNo,action,idempotencyKey,recordVersion,status,stage,occurredAt,effect,counts,result,replayed }`：recordVersion是该命令完成时排车版本（0有效），status/stage是该时刻事实；effect为APPLIED或EXISTING；result为动作判别联合类型（CREATE/EDIT返回已保存身份及变化，PICK返回item/source核平事实，LOADING_COMPLETE返回loadingCompletionHash，DEPART返回departedAt/逐客户实发单据，ARRANGE_DELIVERY返回完整outbounds[]/deliveries[]/arrangementKey）。不得只返回布尔成功或单个outboundNo。所有平台/PDA命令及GET命令结果使用同一schema；原结果除replayed标记外不可变，禁止将后来阶段塞进旧动作快照。前端校验同一dispatchNo/action/idempotencyKey后，再GET当前详情恢复UI；旧结果证明原动作，不覆盖新详情。响应不再要求用Fleet IN_TRANSIT加客户子排车数组猜当前排车成功。
 ### 4.4 详情字段供四页签使用
 ListRow 返回业务号、五阶段、审核和装车/派送摘要、车辆司机、起运仓、计划/实际发车、数量、版本及动作资格；不装载完整订单/附件集合。Detail补充：
 - `vehicleInfo { vehicleMode,vehicleId?,plate,driverMode,driverId?,driverName,driverPhone,carrierName,vehicleStatus? }`；临时车辆没有主档状态时显示“—”，不虚构启用状态。
 - `dispatchInfo { route,plannedDepartureAt,departedAt,estimatedArrivalAt,fbaAppointments[],vehicleAppointment }`。多目的仓不能只返回一个 FBA 约号；预约从有效批次读，保留未知与待复核，不用头部可编辑约号覆盖正式预约。
 - `documents { dispatchNo,deliveries:[{customerId,deliveryNo,destinationKey,status}],createdAt,updatedAt,remark }`；完整返回业务单号，列表摘要批量读取。
 - `orderDetails[]`：真实客户、订单号/入仓码、重量kg、托数、目的FBA仓、体积m³、集装箱号及来源键。按真实订单组成批量组装，不把同托全量重量/体积复制到每个订单；没有可信分摊则对应字段null。`containerNo`、updatedAt、remark、多派送单当前排车DTO缺失需补齐。
 ### 4.5 列表审核分区、分页和统计
 完整Query提案：`{ page>=1,size=1..200,dispatchNo?,vehiclePlate?,warehouseId?,customerId?,fbaAppointmentNo?,status=ACTIVE|CANCELLED|ALL,stage?,beforeLoadingSection?,reviewStatus? }`。status缺省ACTIVE；ALL仅为查询选项，不是保存值/第六阶段。stage严格五项；beforeLoadingSection为`VEHICLE_INFO|DISPATCH_REVIEW|LOADING_REVIEW`，仅在status=ACTIVE且stage=BEFORE_LOADING时合法，其他组合拒绝参数错误，不能静默忽略。reviewStatus仅在某个审核分区存在时合法。
 三个装车前分区保留同一整车集合和不同列投影，不能擅自将“车辆信息”解释成未提交队列并隐藏已审核单。`VEHICLE_INFO`不接reviewStatus；`DISPATCH_REVIEW`按本轮dispatchReview.status过滤；`LOADING_REVIEW`按本轮loadingReview.status过滤，均支持NOT_SUBMITTED/PENDING/APPROVED/REJECTED，未传reviewStatus时不过滤该状态。尚未提交/尚未轮到的审核是NOT_SUBMITTED，不伪造PENDING；旧轮失效通过history/invalidatedReason展示，当前轮重新待提交，不将旧APPROVED算入当前。
 返回 `DispatchPage { records,total,page,size,pages,statistics,snapshotAt }`；statistics结构固定为：
 ```text
 statistics {
  matchedTotal, activeTotal, cancelledTotal,
  stageCounts: { BEFORE_LOADING, LOADING, AFTER_LOADING, DELIVERING, DELIVERED },
  beforeLoadingReviewCounts: {
    vehicleInfoTotal,
    dispatchReview: { NOT_SUBMITTED, PENDING, APPROVED, REJECTED },
    loadingReview: { NOT_SUBMITTED, PENDING, APPROVED, REJECTED }
  }
 }
 ```
 `total`是当前status+stage+审核筛选后的整车总数，与分页records一致；客户筛选通过EXISTS item.customerId选车，每车只计一次。statistics的共同基集只套当前用户范围及dispatchNo/vehiclePlate/warehouse/customer/正式预约号等搜索条件，排除分页、status/stage/分区/reviewStatus；matchedTotal=activeTotal+cancelledTotal，stageCounts仅ACTIVE且五项之和=activeTotal。beforeLoadingReviewCounts只统计ACTIVE+BEFORE_LOADING，vehicleInfoTotal=该阶段数；两审核状态各四项之和同样等于该阶段数，三个分区不是三份互斥货物。零项明确为0，不返回当前页长度冒充总数。
 页面、数量及动作投影在同一只读一致快照事务读取，statistics不逐行查详情。stage筛选影响records/total，不影响顶部各阶段计数；审核筛选不影响同基集的审核分布。用户选择客户筛选仍是平台整车查询，行数量为全车数量；若需要仅本客户数量，必须另名customerMatchedPackages，不能把全车总量悄悄改成筛选客户量。本节是后端可实现的查询提案，分区是否默认只看待审属界面默认值，不新增业务阶段。
 ## 5 派送后端可读取事实和共同端口提案
 端口不共享持久化Entity，不让派送方从 `DispatchOrder.customerId` 推导归属。建议在本任务 `dispatch/port/` 新增只包含 DTO/接口的契约，由总控冻结后移交派送方实现其端口；实现仍遵守各自唯一写权。所有端口同 Lastleg 本地事务，不新建HTTP内部调用。
 | 端口 | 签名/事实语义 | 实现者 |
 | --- | --- | --- |
 | `DispatchExecutionPort.lockForArrangement(actor,dispatchNo)` | 返回Context：dispatchId/no、tripId/no、warehouse、recordVersion、cargoRevision/hash、stage、审核/装车事实、当前资源及cargo；先锁定和核对身份供命令恢复，首次写入另调requireFreshArrangement | 主流程后端；先统一锁，不能派送方先锁delivery再回头锁主单；不得在查原结果前拒绝旧版本 |
 | `Context.cargo()` | 返回CargoLine：dispatchItemId、真实customer、来源与pick/attribution、退货/换标/实托、Destination、packages及批次；精确字段见实际Java | 主流程提供稳定身份；逐来源查询可由派送方沿现有DispatchCargoSourceQuery/DispatchFeeCargoMapper适配，只保留一份来源权威 |
 | `DispatchExecutionPort.recordArrangement(context,actor,identity,fact,alreadyArranged)` | 首次安排CAS递增整车版本并记录公共命令，阶段仍AFTER_LOADING；已存在同业务仅记当前新键EXISTING结果，不重建单据 | 主流程后端；派送服务全部客户成功后同事务调用，字段/签名以第0节为准 |
 | `DispatchDeliveryPort.departureFacts(locked,lock)` | 返回 arrangementRevision/hash、客户出库单和逐客户目的地派送单、覆盖箱数、费用核对有效性及 blockReasons；逐来源精确覆盖，不能只比总数 | 派送后端 |
 | `DispatchDeliveryPort.markDeparted(locked,departedAt,commandKey)` | 所有客户出库/派送推进，返回逐客户实发事实；不扣已扫码库存、不更新排车阶段 | 派送后端，与主流程发车同事务，任一失败全车回滚 |
 | `DispatchDeliveryPort.normalDeliveryFacts(context)` | 批量普通读NormalDeliveryFacts，返回全部本车派送原实发/签收/退回/异常、expectedDeliveryNos、allNormallySigned、factsHash及正常签收最大时间；不加历史来源订单锁 | 派送后端；空集合不是真，拒签/退回不得正常完成 |
 | `DeliveryFactsChanged(dispatchNo,deliveryNo,deliveryVersion)` | 签收事务内记录唯一持久待核对事实，签收提交后消费/重试 | 派送后端保存事实，主流程在新事务汇总；不在原签收子锁下申请父锁 |
 | `DispatchCompletionPort.reconcile(signal)` | 主流程新事务先取得trip/dispatch锁，再普通读全部已提交签收事实，CAS stage DELIVERING→DELIVERED并递增recordVersion，记录唯一汇总依据和完成时间，signal确认同事务 | 主流程后端；重复提醒无副作用，失败回滚后记录退避；写权按6.5 |
 `allNormallySigned` 至少要求：当前有效派送单非空、没有缺项/取消/异常，全部有真实正常签收事实且逐客户/目的地/来源覆盖本车实发；分批签收仍未完成。原 `FleetCompletionModels` 中“正常签收或真实退回可结案”继续只服务附加结案，不能替代此端口。
 本稿完成后已只读核对派送稿第6节：采纳其“签收保持本派送→来源订单锁、提交后持久提醒再汇总”的建议，以保留已有跨多趟来源完成证明并避免扩大签收锁范围。正常签收后另发退货不重开本趟完成，完成时间取本趟最后真实签收；不能只因当前派送状态后来出现退货就否认已完成的原运输。汇总不二次发布来源完成事件、回访或费用。提醒待处理记录归派送域，主流程消费/重扫归dispatch域，确切存储和调度入口仍由总控冻结。
 发车事务按6.4精确链：trip根锁→原命令恢复或新命令资源锁→dispatch→全部客户outbound/delivery→task/批次→真实来源订单和业务行→单据及订单统计推进→写唯一DEPART历史、stage=DELIVERING及不可变命令结果；status保持ACTIVE。库存扣减已在PDA扫码，不在此事务再ship；资料核验可普通读，不允许适配器在锁齐派送前提前取得来源订单锁。
 派送服务安排事务按6.4先取得父级及安排行、outbound/delivery锁（首次为先完成子单插入），再取需要的来源/费用锁和写Outbox，最后recordArrangement及共同命令结果同事务提交；首次命令只允许ACTIVE+AFTER_LOADING。相同目的仓不同客户不合单；逐客户目的地费用具体由派送设计定义，不由本任务猜测。
 ## 6 事务、版本、幂等与锁顺序
 ### 6.1 共同命令与两种摘要
 公开写命令统一 `recordVersion`（创建无既有单版本除外），不存在公开expectedVersion。新增 `ll_dispatch_command { id,dispatch_id,dispatch_no,action,operator_id,idempotency_key,command_hash,result_json,created_at }`，`idempotency_key`平台全局唯一，operator作为不可改的所有者字段，不能用`(operator,key)`分片后让另一个操作者重建同键动作。Admin/PDA共享表、schema及当前身份权限规则；渠道不进入命令身份，同一账号从另一端恢复仍先核验该端权限/绑定仓。
 - **commandHash**：绑定可信主体operatorId、动作、目标业务号、原recordVersion及规范化完整业务payload（含真实证据版本/hash）；排除随机键本身和传输字段。Create无目标号时使用CREATE作用域及完整创建内容，结果绑定服务端生成业务号。对象属性排序、集合按稳定业务键排序、金额精度固定，不能因显示顺序不同误判；集合只有确认为无序时才排序。原键不能改变主体/动作/单号/原版本/任一业务字段。
 - **arrangementBusinessHash**：仅安排派送有此业务去重摘要，包含dispatch身份、cargoHash、loadingCompletionHash、逐客户目的地完整组、资源快照、费用/报价/覆盖证据及全部业务字段；排除operatorId、recordVersion、idempotencyKey、客户端显示顺序等纯命令身份。另一操作者/另一键也不能创建第二套安排或费用。它不用于吞掉两次数量相同但实际不同的PDA扫码，不代替commandHash。
 - `ll_dispatch_delivery_arrangement`以dispatchId唯一保存业务摘要、单据集合和原事实状态；派送域独占写，本地command与安排事实、子单、费用及Outbox同事务。首条Arrange命令的不可变原结果保存在共同命令表；不能在delivery再建立一套不同授权的命令键协议。
 既有命令查验在版本/阶段门禁之前；当前权限和仓绑定校验始终在结果披露之前。新命令使用CAS及当前recordVersion；版本冲突整体回滚，不将换版本当成同一未决命令重试。原结果恢复不递增版本、不重复扣库存/发布费用。没有持久成功命令的未知结果继续以原payload重试；失败或超时不自动改键。
 ### 6.2 授权、恢复与不同请求键判定表
 | 场景 | 权限和判断顺序 | 结果/副作用 |
 | --- | --- | --- |
 | 原键、原主体、原完整payload；当前阶段/版本已推进 | 先核验当前端身份、原动作权限及PDA绑定仓；再校验commandHash和业务号；先于旧版本拒绝 | 原不可变CommandResult，replayed=true；不重新执行；再GET当前详情 |
 | 原键、原主体但改recordVersion/动作/单号/数量/费用等 | 当前权限后检查严格commandHash | `DISPATCH_COMMAND_CONFLICT`，不覆盖原记录、不返回“按新版本成功” |
 | 原键、不同主体，即使有同等权限或同样安排业务 | 当前身份后比较命令所有者，不披露原payload/结果 | `DISPATCH_COMMAND_FORBIDDEN`；必须用自己的新键走当前事实授权流程；不复用他人命令身份 |
 | 原主体同键，但权限已撤销、角色不符或PDA已换仓 | 先检查当前授权范围 | 拒绝读取/重放；历史成功不授予当前访问权 |
 | 新键、原主体或另一有权限主体、同一有效安排业务 | 先核验平台安排写权限和全车范围，再校验新命令recordVersion；锁内比较全车唯一安排的businessHash及有效状态 | 不新建单据/费用；保存属于新主体/新键的严格命令及EXISTING结果，返回原完整单据集合，replayed=false；同一新键再次请求则replayed=true |
 | 新键同安排业务但recordVersion过期 | 新命令不享受旧命令重放豁免 | `DISPATCH_VERSION_CONFLICT`；GET当前事实后另起明确命令，不静默替换未决payload |
 | 新键同车但安排业务不同，或原安排已取消/失效 | 复验当前唯一安排及businessHash/状态 | `DISPATCH_ARRANGEMENT_CONFLICT/INACTIVE`；返回可公开的阻断原因，不重建、不重复发布；原键仍只能恢复其历史结果 |
 | 新键重复装车完成/发车 | 即使载荷看似相同，也无第二次动作；有权限者可读当前事实 | `DISPATCH_ALREADY_LOADING_COMPLETED/ALREADY_DEPARTED`；不插第二执行事实。需恢复成功证明时用原键查询 |
 | GET原键不存在/尚未提交可见 | 当前身份/权限/仓后查询 | `DISPATCH_COMMAND_NOT_FOUND`且无成功data；保留原payload同键POST核对，不把“未找到”等同“可重新生成” |
 | GET他人键/仅有list权限但没有原写动作权限 | list仅允许读当前业务事实，不允许冒充原命令所有者 | 原结果拒绝；另有已定义审计端口时走独立审计权限，不在本次泛化开放 |
 以上错误码是设计提案，由总控统一映射ApiResponse。业务错误沿项目HTTP200+body.code规范；真实认证/基础设施拒绝按现有401/403等规则，不把表内业务冲突强制解释成HTTP409。命令查询与当前详情都不会将内部ID作为业务编号。
 ### 6.3 本轮沿实际Java核对的锁点
 以下是当前源码事实，不是新设计已证明无死锁；`→`表示同一事务中先取得/执行，括号“读”不表示行锁。
 | 操作与实际方法 | 已核对顺序和边界 |
 | --- | --- |
 | `FleetTripService.assign` | `planned→repository.lockTrip` → `vehicles.lockById` → `DriverService.requireDispatchable→drivers.lockById` → resource reserve/release DML → `DispatchFleetAdapter.lockForAssignment`锁dispatch → 锁outbound → 锁task → assign再锁相关deliveries。资源占用`FleetResourceMapper.find`只是SELECT，不能当成FOR UPDATE；新增/删除占用由唯一键及DML串行化 |
 | `FleetTripExecutionService.depart` | trip行锁 → vehicle档案锁 → occupancy普通读 → driver档案锁 → `manifests(true)`逐dispatch行锁、outbound锁、task锁，manifest末尾`DeliveryExecutionGuard.departureBlockReason(...,true)`锁deliveries → `AppointmentWorkDispatchBinding.requireDeparture`批次锁 → 真发车子操作。不可改写成“先来源再派送” |
 | `DispatchPdaWorkflowService.depart`（MANDATORY，外层已持Fleet父锁） | 重入dispatch锁 → binding锁 → outbound锁 → `DeliveryExecutionGuard.requireDeparture`派送锁 → task锁 → `DispatchPickOrderAttributionService.depart`按订单数字ID锁来源订单并更新订单计数 → 转运/换标业务更新 → 来源占用释放/DML。此处没有inventory.ship；订单计数移动不等于库存移动 |
 | `DispatchPdaWorkflowService.pick` | dispatch行锁 → task行锁 → binding锁 → `preparePicking`按orderId锁真实来源订单/已有退回收据 → inventory的allocate/pick/ship；每个`InventoryCommandService.execute`先查/插幂等operation（唯一键DML），再`locked`取得position行锁→balance行锁。随后写pick/归属；没有outbound/delivery行锁。RETURN_RELABEL先`prepareNativeReturn`锁来源订单，再`ReturnRelabelDispatchStock.pick`锁真实退货箱；不伪造position |
 | `DeliveryTransferService.platformTransfer/transferResolved` | dispatch行锁 → 活动outbound锁/原键查询 → binding锁 → bindReceivedPallets更新item（DML锁）→ freight/coverage及费用证据校验 → 插入outbound/子单及费用/来源更新。不是天然trip父锁入口，必须接新上下文端口；安排流程不得照搬旧提前转换资格 |
 | `DeliveryTransferService.cancelOutbound` | 非锁读定位 → dispatch锁（有关联时）/独立relabel锁（对应类型）→ outbound锁 → binding锁及未执行资格 → delivery集合锁 → 按业务分支的退货/转运/任务/来源更新；普通dispatch分支后续按订单ID锁tailOrders。不能从outbound锁后才请求trip锁 |
 | `DispatchService.cancel` | repository.lockOrder锁dispatch → binding锁且当前requireUnbound → outbound锁 → 来源换标/退货释放及活动锁DML。新一对一主单恒有关联，须改为父级协调取消，不能保留“必须unbound”造成永远不能取消；不等于授权已拣/已装车撤销 |
 | `DeliveryDocumentService.save`及`SourceDeliveryCompletionQuery.proveAll` | 显式READ_COMMITTED，先本delivery行锁；outbound以普通读判断已出库，避免反向outbound锁；随后proveAll按orderId锁相关真实来源订单，普通读历史发运证明，不锁历史delivery/dispatch/exception/inventory。不可持这些子锁再调trip/dispatch汇总 |
 源码证据还表明已有逐来源订单记账方法 `LastlegOrderMapper.transferPickedToShipped` 是尾程订单picked/shipped统计移动，普通扫码调用的 `InventoryCommandService.ship` 才是仓位/库存实际扣减。新设计分别命名 `finalizeSourceOrderShipmentCounters` 与“库存SHIP事实”，不再写含糊的picked→shipped。装车完成、安排、发车只核对并消费已存在pick/attribution/SHIP流水；发车仍要按真实来源更新订单/出库/派送计数，不能因不再ship就漏掉订单统计。
 ### 6.4 新实现逐操作锁协议（待冻结，替换相反提案）
 共同根为trip行锁，沿现有Fleet顺序固定为 **trip→必要vehicle档案→必要driver档案/占用DML→dispatch**。不能本任务保留trip→dispatch→资源而另一任务保留资源→dispatch。身份只读解析不加锁，锁trip后重读一对一关系；所有会改主单的原Fleet/后台/PDA/派送入口必须走同一根，旧直锁dispatch入口不得遗留。原键命令可在trip锁后直接授权重放，不能先要求当前司机仍可派车才允许恢复过去结果；新命令才按下列顺序取得资源及子锁并复验。
 | 新操作 | 根以后实际需要的链 | 不能做的事 |
 | --- | --- | --- |
 | 装车前编辑/审核/资源变更 | 根→资源（涉及才取）→dispatch→binding；涉及批次/来源变更再按batchKey及真实来源ID锁，触及预建出库时先取出库/派送再取来源 | 不将审核前置查询直接解释为来源已锁；不在库存锁后改批次或派送 |
 | PDA扫码 | 根→必要资源校验→dispatch→binding→task/item→真实来源订单升序→退回来源行（对应分支）→position→balance，库存命令和pick归属同事务 | 本链不请求outbound/delivery行锁，不写整车派送完成；否则会与签收的delivery→source相反 |
 | 装车完成 | 根→必要资源→dispatch→binding→task/item；批次/装载快照按当前事实复验，读取既有pick/归属；若需要来源锁则按ID升序且不再申请delivery锁 | 不先造派送以满足装车门禁；不执行allocate/pick/ship |
 | 安排/发车/关联出库取消 | 根→资源→dispatch→binding→整车安排行/命令检查→全部客户outbound（客户/ID排序）→全部delivery（客户/ID排序）→task/item（需锁才取）→相关预约批次→真实来源订单/转运/换标等来源行→费用来源/Outbox及DML | 所有需取得的delivery行必须在第一个来源订单锁之前取得；不在持来源锁后补锁另一张派送，不再扣库存；取消只适用已有未执行合法分支 |
 | 签收资料/来源完成证明 | 本delivery→来源订单升序（保持既有显式READ_COMMITTED链）→业务完成/Outbox/待汇总信号提交 | 不取得trip/dispatch/outbound行锁；来源证明只读历史证据，不以父锁替代跨趟来源序列化 |
 | 主流程汇总 | 新事务trip→dispatch（不请求资源锁）→普通读全部已提交本趟签收/异常事实→CAS主stage→acknowledge本信号→同事务提交 | 不调用SourceDeliveryCompletionQuery.proveAll、不锁来源/历史派送；资源不因汇总释放；失败阶段与ack同时回滚 |
 关键交集论证：发车和签收都将需要的delivery置于来源订单之前；扫码只持来源/库存而不再申请delivery，持有来源锁的扫码最终可提交，不等待签收持有的delivery；汇总不持子锁申请父锁。仅trip共同根不能解决跨trip共享来源的反向等待，以上限定正为此而设。安排内若费用/报价/来源适配器提前锁来源，必须后移至全部delivery锁已取得（首次新建子单也先完成插入），不把当前旧调用顺序原样当新协议。
 多客户统一排序：客户用已验证客户ID的数值顺序（现有API字符串只做传输），内部订单/出库/派送/仓位用Long数值顺序，batchKey按稳定字符串排序。不是把`"10"`放在`"2"`前的随意字典序。跨车资源替换应预先按资源类型/数值ID锁定本次全部旧/新主档，再执行占用变化，避免两车交换资源相互等锁；额外主档/交接入口仍需精确写权。
 未证实的锁边界保留为实施门禁：预约编辑/取消/替换与来源/费用的外部入口是否会在持batch/source/fee锁后回头申请本车父锁，尚未遍历验证；对这些已列直接消费者须由总控分配后逐一核对，不允许靠一句“顺序统一”宣称全局无死锁。新增测试要覆盖跨车同来源签收/发车、两车资源交换及预约变更竞争；本轮只静态核对，未运行并发验证。
 出站费用与业务事件只写本地Outbox并随事务提交，远程成功不等于本地事务原子性；资金/文件/其他服务继续正式端口协作，不跨Schema Join。
 ### 6.5 正常签收持久信号的唯一写者
 派送任务独占 `delivery/` 下拟新增 `DeliveryFactsChangedSignal`、Repository/Mapper及 `DeliveryReconcileSignalPort` 实现：签收提交前在同事务插入 `(dispatchId,deliveryId,deliveryVersion)` 唯一信号，保存PENDING、attempts、nextRetryAt、lastError；相关结构由总控统一SQL集成。纯内存afterCommit可作唤醒加速，不能代替持久信号。
 主流程任务独占 `dispatch/service/DispatchDeliveryCompletionWorker.java`、`DispatchCompletionService.java`及直接重试/并发测试；使用服务已有调度能力有界扫描due信号，逐车调用新事务reconcile。端口返回信号时不持delivery/source/signal行锁跨入父锁事务；多实例可重复处理，父锁/CAS及唯一汇总依据保证幂等。按正式契约第九节，阶段CAS和本次signal acknowledge在同一汇总事务提交，禁止旧稿“先提交阶段再另事务markProcessed”；任一失败两者均回滚。失败后才独立短事务记attempts/nextRetryAt/错误；未核齐的合法部分签收已完成本次核对，可在同汇总事务确认该信号，后续签收会发新信号。
 增加有界修复性重扫只读定位“DELIVERING且存在未处理签收信号/已具备全签候选”的本车，仍调用相同reconcile，不写造签收事实；它是本功能可靠消费重试，不是测试存量回填。信号记录/markProcessed端口由派送写，消费/调度/重试决策/重扫由本主流程写，Maven仍本任务唯一执行。普通最终一致窗口内页面读真实stage=DELIVERING，不在签收POST成功后由前端直接置DELIVERED。
 ## 7 权限与隔离提案
 平台入口限定 PLATFORM 且 tenantId=0；列表详情及只读候选使用正式list权限，写权限分别检查。真实客户只来自来源，平台头部不是一位客户。客户已有派送/出库读取继续Token客户隔离：按客户明细/单据读投影，不向客户暴露整车客户清单、其他客户费用、附件或完整整车详情。按用户已确认规则，由派送任务移除旧merchantTransfer创建此类派送的写入口，客户继续合法读取本客户单据/资料，不保留客户改整车旁路。
 建议具体权限如下，由总控统一维护 `OverseasPermissions`、IAM/SQL及前端，不由本任务写共享文件：
 | 动作 | 权限提案 |
 | --- | --- |
 | 整车列表/详情/BOL | 既有 `platform:overseas-warehouse:dispatch:list`，不因可读详情而可调用写命令 |
 | 命令结果GET及同键POST恢复 | 当前原动作写权限+原主体+业务范围/PDA绑定仓，按6.2；list不授予恢复他人命令的权利 |
 | 新建/选货建单 | 新增 `platform:overseas-warehouse:dispatch:create`；旧智能排车权限消费者由总控映射/收敛 |
 | 修改/加货/移除/提交审核 | 既有 `platform:overseas-warehouse:dispatch:edit`；提交是申请，不是审核通过 |
 | 取消 | 既有 `platform:overseas-warehouse:dispatch:cancel` |
 | 调度/理货决定 | 推荐沿用既有 `platform:fleet:trip:dispatch-review/loading-review`，总控同步排车操作资源，不新增一套同义审核权限 |
 | 后台装车完成/实际发车 | 建议新增 `platform:overseas-warehouse:dispatch:loading-complete/depart`，不借edit或PDA角色授权后台 |
 | 安排派送 | 既有 `platform:overseas-warehouse:dispatch:transfer-delivery`，费用确认权限另按派送设计 |
 | PDA列表/扫码/装车完成/发车 | `lastleg:pda:operate` 加海外PDA角色和Token绑定仓；不接收customerId/warehouseId改变范围 |
 已有车辆主档/司机资格/资源占用仍由服务端验证，不能因为排车详情不显示附加能力而省略。主单、task、每条货物、出库派送所属起运仓一致；PDA跨仓读/写和同键恢复都拒绝。后台目前没有PDA的绑定仓事实，不从客户端PDA token或伪造身份调用PDA Controller；后台使用平台权限并复用领域服务。
 ## 8 精确实施清单与直接消费者
 ### 8.1 本任务后续独占生产触点
 | 路径 | 计划变更 |
 | --- | --- |
 | `dispatch/controller/DispatchController.java`、`DispatchQueryController.java`、`SmartDispatchController.java` | 上述平台API、五阶段过滤、整车跨客户建单、删除单客户推断 |
 | `dispatch/dto/DispatchRequests.java`、`DispatchResponse.java`、`DispatchDraftGroupResult.java` | Create/Add/版本命令、资源联合类型、五阶段、四页签事实、全车结果；禁止别名兼容 |
 | `dispatch/entity/DispatchOrder.java`、`DispatchItem.java`、`DispatchDraft.java`、`DispatchPalletLock.java` | 主单/草稿去客户头部、主单版本/审核/实际节点、明细真实客户与实物排他 |
 | `dispatch/mapper/DispatchOrderMapper.java`、`DispatchItemMapper.java`、`DispatchCandidateMapper.java`、`ReturnDispatchCandidateMapper.java`、`DispatchPalletLockMapper.java`、`DispatchDraftMapper.java` | 全车查锁、按明细客户过滤、来源解析批量化、保留真实客户库存条件和退回来源 |
 | `dispatch/repository/DispatchMutationRepository.java`；拟新增 `DispatchRepository.java`、`DispatchCommandRepository.java` 与 `dispatch/mapper/DispatchCommandMapper.java` | 接管触及服务直调Mapper、主单和命令持久化；不把SQL搬进Service |
 | `dispatch/service/DispatchService.java`；拟新增 `DispatchExecutionService.java`、`DispatchReviewService.java`、`DispatchCompletionService.java`、`DispatchDeliveryCompletionWorker.java` | 创建/加货/审核/五阶段状态机；双端共同装车与发车；主流程唯一消费持久签收信号、重试与重扫，不两端各写一套 |
 | `dispatch/pda/controller/DispatchPdaController.java`、`dto/DispatchPdaRequests.java`、`DispatchPdaResponses.java` | 整车身份/版本、仓绑定、替换complete协议、恢复结果 |
 | `dispatch/pda/service/DispatchPdaWorkflowService.java`、`DispatchPickOrderAttributionService.java`，以及 `dispatch/service/ReturnRelabelDispatchStock.java` | item真实客户、全车核平、扣减一次、归属/换标退货事实；不改变已修库存规则 |
 | `dispatch/pda/entity/DispatchPdaTask.java`、`DispatchPdaOperation.java` 及对应Task/Operation/Pick/PickOrder Mapper | task去客户头部、命令集中；pick继续真实客户，查询不能再按单一头部customer过滤全task |
 | 拟新增 `dispatch/pda/repository/DispatchPdaRepository.java` | PDA读写经Repository；逐来源账本与库存命令保留其领域入口 |
 | `dispatch/fleet/DispatchFleetAdapter.java`、`FleetDispatchPlanningAdapter.java`、`FleetDispatchPlanningMapper.java` | 快照不再单客户；manifest分解为拣货核平/实载/派送三个事实，保留sourceCargo/交接/成本直接消费者 |
 | `dispatch/service/DispatchBolPrintService.java`、`dispatch/mapper/DispatchBolMapper.java` | 全车BOL、按明细真实客户取来源；补Repository边界 |
 | `fleet/trip/FleetTripEntity.java`、`FleetTripDispatch.java`、`FleetTripModels.java`、`FleetExecutionModels.java`、`FleetTripReview.java` | 一对一关联、去客户绑定审核、临时资源快照、内部和外部版本区分 |
 | `fleet/trip/FleetTripService.java`、`FleetTripExecutionService.java`、`FleetTripPreparationService.java`、`FleetDispatchBindingGuard.java`、`FleetDispatchGateway.java`、`FleetDispatchWorkflowQuery.java` | 自动资源记录、统一阶段/审核资格、消除多客户子单绑定流程；保留附加能力及其服务端验证 |
 | `fleet/trip/FleetTripRepository.java`、`FleetTripMapper.java`、`FleetTripDispatchMapper.java`、`PlatformFleetTripController.java` | 一对一关系和明确旧接口删除、附加API仍可用；新建资源不伪填旧必填值 |
 | `fleet/trip/FleetTripCompletionService.java`、`FleetTripCostService.java`、`FleetTripCostBasis.java`、`FleetTripHistory.java`、`FleetTripHistoryMapper.java` | 按真实客户货物读取，原结案/成本历史与资源结束保持；不将资源COMPLETED当五阶段完成 |
 | `fleet/trip/VehicleFulfillmentMapper.java`、`FleetTripCalendarService.java`、`fleet/trip/work/AppointmentWorkTripMapper.java` | 已发现b.customer_id连接需改按派送/货物真实客户；日历保留真实时间和空单缺项，不再假定计划时间全非空 |
 新增文件名为推荐落点，冻结时可按既有层次合并；不能为少建Repository继续跨层SQL。`FleetBookingFreight.java` 归派送任务，本任务只提出 SourceCargo/绑定关系变化，不修改。
 ### 8.2 必须由总控分配或集成的外部触点
 | 精确触点 | 必须处理的影响/写者 |
 | --- | --- |
 | `delivery/service/DeliveryTransferService.java`、`DeliveryFeeCoverageService.java`、`DispatchCargoSourceQuery.java`、`delivery/repository/DispatchCargoSourceRepository.java`、`delivery/mapper/DispatchFeeCargoMapper.java` | 派送后端；所有 dispatch.getCustomerId 消费改为真实分组，签名不能留旧头部参数 |
 | `delivery/service/DeliveryDocumentService.java`、`DeliveryExecutionGuard.java` 及客户Controller/DTO、Outbound/Delivery Mapper | 派送后端；共同锁在单据锁之前；正常签收汇总端口、跨客户出库覆盖与唯一键 |
 | `inboundplan/work/AppointmentWorkDispatchBinding.java`、`AppointmentWorkDispatchMapper.java`、`appointmentwork/AppointmentWorkDispatchPort.java` | 超出本任务当前生产写权，总控分配唯一写者；必须一次校验/保存全车各客户分配，移除d.customer_id Join；保留稳定batch/source/customer/目的地和已接收门禁 |
 | `exceptionorder/service/ExceptionOrderService.java` | 已发现DispatchOrder直接消费者；改用派送/拣货真实客户归属，保留 RETURN_RELABEL 原箱回溯；总控分配，不能覆盖在途测试修改 |
 | `fleet/exception/FleetHandoverPdaQuery.java` 及直接交接事实调用 | 客户从派送事实而非整车头部获取；保留未完成派送资源和完成时历史快照，总控分配 |
 | `customervisit/service/CustomerVisitService.java`、`delivery/model/DeliveryStatusPolicy.java` | 已修状态门禁继续有效，签收/状态写入需共同锁入口；总控确认派送后端接管范围 |
 | `src/main/resources/db/lastleg.sql`、`deploy/sql/头程数据库统一增量-MySQL8.sql`、IAM权限资源 | 总控唯一集成；按新基线收敛，不迁移/回填测试存量，不执行SQL |
 | OpenAPI `overseas-business-v1.yaml`、`fleet-trips-v1.yaml`、`fleet-preparation-v1.yaml`、`appointment-work-v1.yaml`、必要新增 dispatch 文档 | 总控唯一集成；删除旧协议与消费者同批完成；统一Gateway既有last-leg通配应离线验证，不能凭路径推定运行可达 |
 | `file` 附件提供者 | 共享整车BOL/附件若改变授权归属，先列出正式接口由总控分配；不把客户附件改为平台公共附件，本轮不改file代码 |
 前端直接消费者已定位：Admin `overseas-warehouse/api/dispatches.ts`、`pages/DispatchesView.vue`、`pages/DispatchDetailView.vue`、`components/SmartDispatchDialog.vue`，以及 `overseas-master-data/api/trips.ts`、`components/TripPreparationDialog.vue`、`components/TripBookingPanel.vue`；PDA `src/api/fulfillment.js`、`src/stores/fulfillment.js`、`src/pages/dispatch/dispatch.vue`。归前端任务。
 预约在途消费者只读列明：Admin `appointment-calendar/WorkDispatchForm.vue` 当前调用 drafts/pre-arrange 后弹车次准备和同仓共车，`WorkSharedTripForm.vue`要求两张客户排车，`WorkExistingDispatchForm.vue`仍以旧PENDING_DEPARTURE/workflow判断“继续安排本批车辆”。三者必须接入同一整车创建/加货及actions，保留事项弹窗关闭、原单跳转和已操作批次事实；总控分配接线，不由本任务覆盖。
 脚本直接消费者已发现 `scripts/admin-test-env-modules/{grouped-dispatch-acceptance,dispatch-repair-acceptance,fleet-cross-customer-acceptance,fleet-cross-customer-fixture,fleet-external-dispatch-acceptance,fleet-fee-coverage-acceptance,fleet-booking-reservation-acceptance,fleet-return-redispatch-acceptance,fleet-handover-acceptance,fleet-trip-cost-acceptance,fleet-trip-fulfillment,phase3-outbound-dispatch,phase4-overseas-dispatch,phase5-overseas-fulfillment}.mjs` 等及其合同。这里只登记实际路径命中，不读取历史报告或执行真实HTTP；协议冻结后总控定向分配旧请求/状态更新，不能让旧fixture继续构造客户子排车。
 ### 8.3 结构变更给总控的清单
 1. `ll_dispatch_order` 去customer，新增stage五阶段列、status收敛ACTIVE/CANCELLED、主版本、cargo修订/摘要、当前审核轮/依据、装车/发车/正常派送完成实际时间、备注；索引改仓/status/stage/计划时间及业务号，客户检索走item索引。审核详情可JSON但历史不可覆盖。
 2. `ll_fleet_trip_dispatch` 去customer/review；一对一唯一约束；`ll_fleet_trip`新增临时资源快照/模式，允许新建草稿时计划、资源、卸货点未知，检查直接DTO/Mapper均不伪造默认值。
 3. `ll_dispatch_item`保留customer，新增或明确稳定来源键/摘要，补全详情真实来源字段；索引按dispatch+customer+目的地及来源核对。物理托数与来源明细数分开统计。
 4. `ll_dispatch_pda_task`去customer且dispatch唯一；pick/pick_order继续真实客户与来源；新增公共command（idempotencyKey全局唯一且operator不可改）及主单历史表，废除重复PDA整车命令记录协议。派送域持久待汇总信号表按6.5由派送任务设计、总控集成。
 5. `ll_dispatch_draft`去客户头部，锁明细保留客户，补实物唯一活动锁；转换请求原子创建对应整车及Fleet。
 6. `ll_dispatch_appointment_allocation`保留客户与逐来源箱数，不改成整车客户；全量替换时原子校验全车，必要索引加dispatch+customer+item。
 7. 派送方同步将出库活动唯一键确定为 `(dispatch_order_id,customer_id)`，派送按客户+目的地；取消历史保持可追溯，不能以删除历史满足唯一键。费用和单据结构具体由另一文档给总控。
 8. 全部中文表/字段备注、主外关联和索引同时进模块最新基线及统一结构脚本。无迁移、双写、别名、回填或测试存量修复；本清单不是执行数据库授权。
 ## 9 实施后的最小验证包（本轮未执行）
 已有测试精确触点（相对 `lastleg-service/src/test/java/com/baiyue/lastleg/`）：
 | 测试 | 必须覆盖 |
 | --- | --- |
 | `dispatch/service/DispatchServiceTest.java`、`DispatchRepairWorkflowTest.java` | 同仓多客户多目的地一张真主单、空单再加货、来源不可伪造、跨仓拒绝、取消只释放本单、上一批换标全托/退货/合托修复 |
 | `dispatch/controller/SmartDispatchControllerTest.java`、`DispatchQueryControllerTest.java`、`dispatch/DispatchSchemaContractTest.java` | 新API/五阶段/权限和去客户头部结构；草稿每容器一整车、不同客户同组 |
 | `dispatch/controller/DispatchQueryControllerTest.java`及新增真实Mapper分页/统计用例 | status/stage正交，取消保留最后阶段；审核分区+状态SQL过滤、NOT_SUBMITTED不算PENDING、多客户一车只计一次、分页total和全基集统计/零值/一致快照 |
 | `dispatch/DispatchCandidateMapperContractTest.java`、`DispatchPalletLockPersistenceContractTest.java`、`DispatchPhysicalWeightTest.java` | 实物别名排他、真实来源客户、重量未知不填零或材积重 |
 | `dispatch/pda/service/DispatchPdaWorkflowServiceTest.java`、`DispatchPickOrderAttributionServiceTest.java`、`ReturnedDispatchAllowancePersistenceTest.java` | 未审核禁扫、后台不能补录、逐项核平、只扣一次库存、最后扫码不自动装车完成、跨客户来源、错仓/超量/同键异内容 |
 | `fleet/trip/FleetTripPersistenceTest.java`、`FleetTripAuthorizationTest.java`、`FleetTripApiContractTest.java`、`FleetDispatchWorkflowQueryTest.java`、`FleetTripMatchedStopsTest.java` | 自动唯一关系、审核重提/关键修改失效、主档占用与资格、保留站点顺序/外接容量、临时ID为空及审核依据 |
 | `dispatch/service/DispatchAppointmentCancellationPersistenceTest.java`、`inboundplan/work/AppointmentWorkDispatchBindingTest.java` | 跨客户batch不互删，旧取消后重排不占用失效批次，改批次版本拒绝，已接收门禁；后者写权需总控分配 |
 | `fleet/trip/FleetTripCostPersistenceTest.java`、`FleetTripCostContractTest.java`、`FleetTripCalendarServiceTest.java`、`FleetTripCalendarMapperTest.java` | 附加能力保留；空计划不伪时间；成本实发事实及资源结束仍独立 |
 | 拟新增 `dispatch/service/DispatchExecutionConcurrencyTest.java`、`DispatchReviewServiceTest.java`、`DispatchCommandPersistenceTest.java` | 双端同版本竞争只有一次装车/发车；同键原快照恢复；先派送后发车原子性；任一客户失败全车回滚；审核前后及取消/发车竞争 |
 | 拟新增 `dispatch/service/DispatchDeliveryCompletionWorkerTest.java` | 信号提交后崩溃恢复、阶段CAS后ack前故障两者均回滚、重复信号/多实例、部分签收、重试/重扫、最后全签只CAS一次；签收持子锁期间不得回调申请父锁 |
 派送方测试由其独占：`DeliveryTransferServiceTest`、费用覆盖/来源持久化、正常/部分/异常签收和汇总回调。共同集成应证明：未安排不可发车；部分/拒签/退回不自动DELIVERED；全部正常签收只推进一次且不释放资源；多客户同仓费用、来源和客户只读不串。
 实现全部集成后，由本任务唯一串行执行后端 Maven `mvn -pl lastleg-service -am test-compile` 和对应行为测试（最终 `mvn -pl lastleg-service -am test`）；先核对本批测试/基线稳定。总控集成后运行 Gateway 路由合同，新增Mapper运行 mapper-scan，跨包端口变化运行 lastleg-dependencies 检查。输入未变不重复跑。代码检查、真实HTTP、人工截图/PDA真机分别记录；本稿仅做源码只读分析，全部这些验证尚未执行。
 ## 10 需要总控冻结或裁定的具体问题
 ### 10.1 四项业务选择已确认，不再待问
 正式契约第八节用户确认“四项都按建议执行”，替代前两轮选项表。本任务执行以下唯一基线，不再请用户重复决定。
 | 场景 | 当前确定行为 | 本任务影响 |
 | --- | --- | --- |
 | 临时外配取证 | 建单人保存本趟真实容量/证照资料及预计任务结束，调度核实；空单可先保存，审核前补齐 | MASTER/EXTERNAL明确分离，不造主档；证据提供者变更交总控逐文件分配 |
 | 实际装载核对 | 确认装车弹框接入既有实载，有依据数据带出、缺项按真实事实确认 | LoadingComplete携manifestHash和measurements；必须先核平PDA，不新增第五页签、不代填拣货 |
 | 零扫码变更 | 保留原业务号，显式退回装车前，修改后两审重提 | ReturnToReview命令及历史；已有任何真实扫码/库存SHIP则不开放本批退装/回库 |
 | 客户旧创建入口 | 整车安排仅平台执行，移除旧客户创建此类派送入口，客户保持自己单据读取 | 派送任务和前端任务按各自写权处理；不实现客户意图第二协议 |
 新增预约明确属于日历，不在本任务设计、矩阵或实现范围；只保留整车改造影响的既有预约读取/关联，提供者未解锁前不修改。
 ### 10.2 总控工程冻结清单（无需用户重复裁定技术细节）
 - 本稿已依据共同契约统一公开recordVersion、平台全局唯一请求键绑定主体、严格commandHash与arrangementBusinessHash及6.2授权恢复表；派送稿若尚保留expectedVersion或“同键跨主体也返回原结果”，由总控同步其唯一写者收敛，不让前端拼第三套协议。
 - status/stage按第3节正交唯一语义、审核查询统计按4.5、命令GET及结果按4.3确定一套共同OpenAPI，前端移除旧状态和trip版本协议；这是数据/接口选择，不要求用户再选技术字段名。
 - 锁协议采用6.3源码事实及6.4逐操作新顺序；其中库存position→balance、发车delivery→来源、签收delivery→来源已核对。预约/费用/其他主档入口反向加锁尚未逐一验证，须分配后验，不能标注“已无死锁”。
 - 签收信号记录归派送，主流程worker/消费/重试/重扫及直接测试归本任务（6.5）；接口包名选一套消费域端口，禁止双向具体实现依赖或为了编译加循环豁免。
 - `AppointmentWorkDispatchBinding/Mapper/Port`及`WorkSharedTripForm`等预约触点、Client、File、脚本和共享SQL/OpenAPI/权限仍需总控精确分配唯一写者；保留预约保存/事项关闭/原单跳转及上一批真实来源修复。
 - 旧多单Fleet prepare/bind/unbind配送协议收敛，PICKUP和外接/容量/成本/交接/资源结束保留原能力；原独立取消“必须unbound”改成父级协调，不新增已扫码撤销路径。本稿已只读比对派送稿，不修改另一文档、不跨对话发消息。
 下游按第0节已落地骨架接入，不再以准备稿猜字段；实现范围以正式契约第九节为准，额外文件仍需总控精确分配。公共类型后续变更先更新交接点和哈希，再同步已发现直接消费者。
 ### 10.3 真实主单切片与精确集成依赖（2026-10-19）
 2026-10-19补充作业公开DTO：新增`dispatch/port/DispatchWorkModels.java`，SHA256=`1e91da656e38aebbc554b4b4275b080d387e6bdb2eefaa14d5ae1ebd5b1aec64`。原13文件未改；新文件仅JDK依赖，确切record以实际源码为准：`Items(dispatchNo,recordVersion,status,stage,List<CargoItem>)`，CargoItem含真实dispatchItemId、真实客户、sourceKey/sourceVersion/sourceType、planPalletId/returnReceiptId/relabelNo、warehousePalletId/palletNo、orderNo/inboundCode、destination、scheduledPackages/pickedPackages/remove Gate；不能从orderDetails.sourceKey或warehousePalletId替代删除身份。`Route(dispatchNo,recordVersion,List<Stop(index,name,address,destinationKey)>,edit Gate)`使用真实Fleet持久顺序，0为起运仓，其余index可直接对应LoadingMeasurement.deliveryIndex；`RouteCommand(recordVersion,idempotencyKey,List<String> destinationKeys,reason)`只重排完整既有目的地，服务端保留真实名称/地址、起点及外接卸货点，采用既有Action.EDIT严格幂等。
 新增已接线平台端点（D=`/api/platform/v1/last-leg/dispatches`）：`GET D/{dispatchNo}/items`返回Items，`GET D/{dispatchNo}/route`返回Route，`PUT D/{dispatchNo}/route`接收RouteCommand返回CommandResult；读权限dispatch:list、改路线dispatch:edit。四详情对象不加第五页签。`GET D/{dispatchNo}/loading`及`POST D/{dispatchNo}/loading-complete`使用已冻结LoadingPreview/LoadingComplete/CommandResult；后者权限dispatch:loading-complete，显式确认前保持LOADING。
 附件正式入口已接线：`POST D/{dispatchNo}/evidence/{kind}`，kind=`VEHICLE|DRIVER`，multipart字段`file`，权限dispatch:edit，返回`{fileId,fileName,contentType,sizeBytes}`；上传不自动替换主单引用，后续使用当前recordVersion的Update保存evidenceFileIds/evidence.fileIds。`GET D/{dispatchNo}/evidence/{kind}/{fileId}`返回同一元数据，`GET .../{fileId}/content`返回鉴权代理字节、inline Content-Disposition及no-store，读权限dispatch:list；不能使用匿名URL。内部File按平台0＋新类别＋真实dispatchId＋fileId核验。File类别由总控新分配的派送后端补齐，本任务不修改File源码；本域新入口仍待离线/真实验收分别核对。
 主单新增`loading_confirmation_json`精确字段，已纳入DispatchAggregate和saveState Mapper；内容是已冻结ConfirmedLoad完整快照。DispatchExecutionPort现由DispatchAggregateService实际实现，preview/lock/replay/fresh/recordArrangement使用同一主单、逐项真实扫码和不可变归属；新的DispatchExecutionReadMapper/Repository批量读取，不用计划数量凑核平。装车完成沿原Fleet容量策略并核对外接预订，保存实载但不调用库存SHIP。以上新输入测试正在运行，不用前一轮通过结果替代。
 已经实施`DispatchAggregate`及其Mapper/Repository、`DispatchAggregateService/Controller`、`DispatchReadMapper`、`DispatchSourceMapper/Repository`，并沿允许的Fleet原生应用入口建立真实一对一资源记录。主单没有customer字段；同仓多客户只在真实明细保留归属。空单、选货建单、加货、分页和四对象详情、命令持久恢复已接线。候选返回共同`CandidateList`，按真实起运仓在SQL取有界多客户集合，来源摘要由当前库存版本、仓、收货组成、目的地及换标轮次生成。两级审核、驳回重提、资源编辑与零真实扫码退回已进入本域实现，新增验证仍进行中。
 共享SQL精确输入：主单字段以`DispatchAggregate`实际属性为准，移除customer_id，trip_id唯一；Fleet计划、资源允许空值，`ll_fleet_trip_dispatch`移除customer_id/review_json并唯一trip_id；明细新增customer_name/source_key/source_version/source_snapshot_json；来源锁新增nullable且唯一active_warehouse_pallet_id，与customer_id/active_key唯一键共同防别名重复占托；不可变`ll_dispatch_history`字段id/dispatch_id/record_version/action/operator_id/reason/snapshot_json/occurred_at；命令表见0.2。路线须容纳多目的地真实地址，不能沿用短VARCHAR截断。未写共享DDL、未执行SQL。
 本域新增临时资源证据适配`dispatch/gateway/DispatchEvidenceGateway`及`HttpDispatchEvidenceGateway`，只读写File现有通用内部业务文件路径。File提供者精确触点是`file/src/main/java/com/baiyue/file/service/BusinessFileCategory.java`：需要两个平台固定0、businessId为真实dispatchId、PDF/JPG/PNG、10MiB、POSITIVE_LONG类别`OVERSEAS_DISPATCH_VEHICLE_EVIDENCE`与`OVERSEAS_DISPATCH_DRIVER_EVIDENCE`，以及直接类别/归属测试和必要OpenAPI。该提供者未分配给本任务，未修改；由总控分配唯一写者。Lastleg按平台0＋类别＋本车ID＋文件ID复验，不复用司机主档证照类别，不为临时输入自动建主档。公开上传/读取入口尚待接线；File类别和真实调用未验收，不把测试夹具的文件提供者模拟视为真实文件验证。
 预约精确触点仍是`AppointmentWorkDispatchPort.bind/Binding/Mapper`：现接口按单客户调用且会删除整车所有分配，查询仍以头客户联接；不能跨客户循环调用或静默丢掉已有批次。本域暂明确拒绝有既有批次的建单/加货和车辆预约编辑；需要总控分配提供者最小适配后解除，不表示业务取消预约能力。候选appointmentBatches尚未填充，后续读取须同一权威提供者接通。
 离线证据：首轮生产与全部测试源码编译通过，主单/公共合同/账本/查询及派送交付的19个直接类共144项中143项通过；唯一Merchant OpenAPI残留由总控处理，之后复测推进到第133行旧POST残留。主单3项实际MyBatis/H2事务测试通过，证明空单一车一记录、同仓多客户多目的地一头、过滤不缩减整车、原结果恢复及后项冲突全事务回滚；选货 authority 提供者当时为受控输入，不证明完整来源链。补跑旧回归66项有3项旧夹具缺新依赖，修夹具后Fleet57项全部通过，DispatchRepair还需补真实dispatch_no关联继续验证。Gateway路由合同5/5；Mapper扫描389个/10模块。新增审核和候选改动待下一次串行Maven，不把既往结果覆盖新输入。依赖分析旧fleet/pickup三项基线未改。
 2026-10-19后续实现：`DispatchAggregateService`实际实现Execution端口，`DispatchCompletionService`实际实现Completion端口；`DispatchDeliveryCompletionWorker`有界读取到期信号、逐车新事务汇总、失败回滚后独立退避、按真实已签收版本重扫缺失信号。主阶段CAS、唯一完成历史、指定信号ack同事务；合法部分签收只ack本次通知，后续版本独立产生新信号；全部正常签收才DELIVERED，不释放资源、不二次发布来源/费用。
 PDA实际Controller已切到共同DTO：GET根与单号返回DispatchViews.PdaTask；列表query使用stage；POST items/{itemId}/pick接收DispatchCommands.Pick；新增GET loading、POST loading-complete、GET commands/{idempotencyKey}；POST depart接收DispatchCommands.Depart并返回CommandResult；旧/complete不再注册。身份由DispatchActorFactory.pda→PdaWarehouseIdentity取操作者及唯一绑定仓，请求不接受客户/仓。DispatchPdaQueryService＋DispatchWholePdaReadMapper批量装配多客户明细/仓位/原生退货箱/真实归属，列表不逐车查详情。整体taskNo明确以排车业务号识别；底层任务现按dispatch唯一且不含customerId；taskNo直接使用dispatchNo，真实客户继续留在pick/pick_order及库存命令。
 新增DispatchPickingService与DispatchDepartureService。扫码沿原InventoryCommandService、DispatchPickOrderAttributionService和原生退货生产者执行；实际来源订单先于库存锁，最后一箱只核平、阶段仍LOADING。版本化发车先根锁，再收齐所有出库/派送锁，再锁全部实际来源订单；调用原来源计数及转仓/换标/FleetPool生产者，不再扣库存；原命令恢复先于阶段资格。旧DELETE移货/取消已退出Controller，使用POST items/{itemId}/remove和POST cancel＋ReasonCommand，释放精确原占用，旧键重放不能释放新车占用。实际扫码、发车及原提供者整链正在验证，不能将编译视为这些生产者已证明。
 草稿唯一写权已移交原派送后端：Draft/Container实体及Mapper、SmartDispatchController、Draft专用Service/Repository/占用Mapper及直接测试；本任务停止写入。按派送设计第12节已补最小桥接：`DispatchService.lockDraftSources(String,List<CargoSelection>): List<WholeSource>`，MANDATORY，允许草稿逐托暂存换标但正式create仍要求完整申请；`DispatchAggregateService.lockDraftCreationResources(Actor,List<Create>): void`，MANDATORY，锁齐全批车辆升序→司机升序→车辆占用升序→司机占用升序，再取全批来源。转换里的新trip是当前事务创建且外部不可见的身份，正式create只重入已持资源身份锁，不在第二组取新资源。已移除旧DispatchService草稿读写/占用/分组转换公开方法及对应旧测试，不恢复Draft.customerId；旧单客户建单/Fleet适配尚待整体退出。
 新增离线证据：最新完整Lastleg Maven在固定输入下生产及442个测试源码编译通过，53项中52项通过，包含主单/审核/真实明细与路线/显式实载/失败归属8项SQL测试、Schema中文注释3项；唯一Merchant第133行由原写者修正路径块提取，保留其他业务合法POST，后续新候选待复验。JDT曾把错误字节码写入target/classes，javap确认含Unresolved compilation problems；只对Lastleg target运行一次mvn clean后恢复编译，没有修改转仓/本土卡车源码或停止IDE。
 随后在草稿在途输入之外，使用明确19个生产文件的javac独立输出及JUnit 1.10.3实际启动器运行本域23项直接测试全部通过：9项根/版本/审核/路线/实载/移货取消SQL、2项完成CAS与ack共同回滚及重试/部分签收、1项worker退避顺序、2项真实来源订单/库存/实收SQL与锁序、2项持久账本、5项证据归属/模拟HTTP下载MIME长度签名及业务错误、2项公共合同（16类请求缺/null/负/零版本、全部Action重启恢复）。这是固定本域快照，不是新增PDA/草稿完整Maven，也不把受控库存/归属/文件提供者当真实环境证明。后续新增PDA查询与扫码测试正在进行。
 共享验证：IAM四类24项全部通过，输入未变不重复；File新证据测试在145/146/171/175行未处理IOException导致测试源码编译失败，已给原写者精确定位，本任务不改File。Gateway路由5/5、Mapper390个/10模块通过；依赖分析仍为原fleet/pickup三项失败，未加豁免，后续新Mapper输入需重新核对。
 主要未闭环：既有预约/车辆预约权威写提供者仍按总控保护，禁止循环旧bind或静默丢批次；FleetTripDispatch旧customerId/reviewJson及旧单客户适配/直接消费者尚未完全收敛；草稿新候选及全域测试编译、实际PDA扫码/发车与全部正常签收联合验证尚未完成。所有结果均不表示已部署、真实HTTP、人工页面或PDA真机验收通过。
 2026-10-19 16:58本域继续收口：`DispatchPdaTask`已移除customerId，TaskMapper只按dispatch读取，PickingService按根锁创建唯一任务并以dispatchNo作taskNo。新增双客户实扫用例验证一张任务、两条真实客户扫码、各自库存命令及最后扫码仍LOADING；H2用例有dispatch唯一约束。`FleetTripDispatch`已移除customerId/reviewJson，DispatchBinding/PreviousDispatch去客户头，新增FleetDispatchGateway.workflows批量从本域真实主单读取两级审核；Fleet详情/历史投影、拣货门禁不再读取绑定级审核。已撤下PlatformFleetTripController旧调度审核、理货审核及独立实载确认写入口；原公开Fleet资源/计划入口对已关联主单拒绝写，必须走共同主单版本与审核。公共原13文件和WorkModels未修改。余下旧手工绑定/prepare、外接来货入车及旧DispatchOrder适配正继续调整，不视为本批完成。
 稳定草稿输入上的Maven：1056个生产源码及450个测试源码test-compile通过；31个直接类共178项，176通过，两项草稿失败为SmartDispatchControllerTest:65把非路由方法计入权限遍历，以及DispatchDraftPersistenceTest:151转换重启恢复的抽象Payload反序列化失败；失败报告交原写者，不修改其文件。主单双端发车竞争及源生产者失败全事务回滚2项均通过，明确源发布生产者在该用例受控模拟。File七类串行命令再次停于DispatchEvidenceFileTest:145/146/171/175四个IOException测试编译错误，未执行测试，输入未变不重复。
 上述模型收口后PDA Maven34项出现13项非法DispatchPdaTask.class字节码VerifyError（本机JDT写target产生），不能视为业务失败或通过。随后在固定本域显式源码列表的独立javac输出中重编译受影响实体/Mapper/Service，运行JUnit真实启动器36/36通过：根SQL/审核/资源/路线/实载/取消移货9，完成事务/worker3，真实来源SQL2，共同账本2，模拟HTTP证据5，公共JSON/依赖2，PDA真实读1，PDA扫码3，批量资源锁2，PDA路由/DTO6，实际发车事务2。此轮Fleet历史审核已通过真实DispatchFleetAdapter.workflows→AggregateRepository→MyBatis/H2读取，不再模拟绑定级旧审核。仍需稳定后的全域Maven、最新正式SQL合同与附加能力集成验证。
 保护范围精确触点：`inboundplan/work/FbaAppointmentExecutionAdapter.java:78`仍用TerminalEvidence.customerId决定整车归属且状态仍使用旧DEPARTED/PENDING_DEPARTURE/PDA_PENDING；`FbaAppointmentTransportAdapterTest.java:48`旧DispatchBinding构造器含客户参数，需原提供者在唯一写权下同步。TerminalEvidence本身尚未改，不能设置0、首客户或空值当整车客户完成收敛。实际客户仍必须从逐条TerminalDelivery/扫码/归属取值。
 2026-10-19 17:08 File冻结修复验证：`DispatchEvidenceFileTest.java`当前SHA-256=bba87946457fb1290960218127087552de95b59f443eb6d5dacf354084d04a19，与总控候选匹配。唯一串行命令`mvn -pl file -am '-Dtest=DispatchEvidenceFileTest,BusinessFileStorageTest,InternalBusinessFileServiceTest,InternalBusinessFileControllerTest,DriverLicenseFileTest,TripOperationEvidenceFileTest,VehicleCarePhotoTest' '-Dsurefire.failIfNoSpecifiedTests=false' test`实际49/49通过，其中证据新类别12/12。输出`.logs/dispatch-file-fixed-tests.log`，JUnit报告`file/target/surefire-reports/`，输入未变不重跑。草稿当前稳定摘要b0db1bb5191fa3578dacfa0f07c7c2a6a30346f0198047e34fc1fe3a99b0e554及17项待下一Lastleg编译窗口，不将写好当通过。
 36项固定输出证据位于`lastleg-service/target/dispatch-owned-compile/model-tests.log`（SHA-256 325ccd6c326aee5465639e5b017c46ba5f641b8f9268e81b6b7e9238e3046084）、`model-36-evidence.json`（当时仍未变化的10份PDA/测试源码指纹及范围说明）、`verified-36-classes.jar`（SHA-256 43d626ac44389dbbe9ee522a832b980e0a6b85dbedb9b6cb7f2c20d68dcd7ff9）。后续Fleet适配/附加能力接线不由该结果覆盖。
 Fleet现继续按真主单收敛：`FleetDispatchGateway.Snapshot(dispatchId,dispatchNo,warehouseId,packageCount)`与`TerminalEvidence(dispatchNo,warehouseId,shippedPackages,deliveries)`、`FleetTransitEvidence(dispatchNo,warehouseId,shippedPackages,deliveries)`均去客户头；逐行TerminalDelivery/Delivery.cargo保留真实客户。SourceCargo结构未变，读取改为`sourceCargo(dispatchNo,customerId)`，客户参数仅由服务端真实货物/预订归属传入；`customers(dispatchNo)`返回本车真实明细客户。DispatchFleetAdapter不再读旧DispatchOrder或旧客户PDA任务，交接/结束读取所有客户出库及所有派送并逐客户核平，先全部outbound后全部delivery锁。正常全签后退回仍保留原已履约，不从主单客户裁切全车。在途更换只更新对应未终结客户派送。
 旧Fleet主流程写协议已撤下：POST fleet/trips、POST /prepare、GET /{tripNo}/dispatch-candidates、POST /{tripNo}/dispatches/bind、POST /{tripNo}/dispatches/unbind、POST /{tripNo}/dispatches/{dispatchNo}/review、POST /{tripNo}/loading-review、POST /{tripNo}/loading。旧PreparationService及旧PDA list/task/pick/complete/depart应用方法退出，PDA SourceWorkflow仅保留真实来源发车计数/状态生产者。外接预订bind/arrange保留，但只核对/加入该Fleet已唯一关联主单，不创建或挂入第二张客户排车；普通取货createPickup保留。`PlatformFleetCapacityOfferController`arrange-dispatch已把旧smart-dispatch改为当前dispatch:create，并继续要求原capacity-offer manage、booking-edit、trip-edit。共同OpenAPI/保护中的预约提供者/外部前端入口由总控协调，当前尚未全域编译/回归完成。
 受保护生产直接消费者新增精确交集：`FbaAppointmentTransportAdapter.java:95/102`调用已退役FleetTripService.unbindDispatch/bindDispatch；`FbaAppointmentExecutionAdapter.java:87`调用已移除TerminalEvidence.customerId。不得恢复旧头字段、循环旧bind或加成功空实现。旧手工H2与Fleet/预约直接测试必须按新模型继续调整，当前36项不能替代这些回归。外配任务结束现在不对不存在的主档ID释放占用或修改主档状态，仍保存真实结束时间/地点与状态；待直接测试。
 2026-10-19 既有预约接线取得用户授权后的公共合同：`DispatchContracts.BatchAllocation(planPalletId,batchKey,customerId,sourceKey,destinationKey,packageCount,Long recordVersion)`及`BatchReference(batchKey,batchNo,customerId,sources,Long recordVersion)`末尾增加权威记录版本，compact constructor拒绝缺失/null/负数、0合法，不提供旧签名重载。FBA引用取原预约版本；自动DISPATCH引用取实际对应整车recordVersion，不伪造FBA版本，也不接受客户端以自动引用替代FBA分配。DispatchContracts.java SHA-256=73b5b83fcd0155bf09b18c18b1bd6a5bbb0175221102a13101248f92ca84f641。其余原公开DTO当前未改，原13文件“全部不变”指纹表从本次字段变更起只作历史基线，不再代表当前。
 新增JDK内部端口`dispatch/port/DispatchAppointmentAmendmentPort.java`，SHA-256=45aca62fa8a52f3b97a3e666c87b85d2ae0ca5372ca46e1c29ef76f27887b238。精确方法为`void lockExistingAppointmentDispatches(Actor,List<String> dispatchNos)`和`CommandResult applyExistingAppointmentChange(Actor,String dispatchNo,ReasonCommand identity,List<PhysicalItem> touchedItems,List<BatchAllocation> expectedAllocations,List<BatchAllocation> nextAllocations,boolean removePhysicalItems)`；PhysicalItem为`(Long itemId,String customerId,Long planPalletId,String sourceStage,Integer packages)`。两方法MANDATORY内部协作、不注册HTTP；先全范围trip→全部资源→全部dispatch，再全部必要子单→批次→来源→协调guard。ReasonCommand为本车公共版本+原父预约命令键，内部按父键/真实操作者/本车派生稳定子键，共用公共账本并优先恢复原结果。expected/next只接原权威scope，必须逐项核DB真实明细/原分配及完整实物，BEFORE_LOADING/零真实扫码/无下游执行；移客户货物不解绑或取消整车。端口源码先交付，实际实现和主流程接入正继续，不能据接口存在推定已完成。
 获得最小写权的ExceptionOrderService.java:548已将任务查找改为findByDispatch(dispatchId)，后续本客户pick/item/归属过滤保持；直接ExceptionOrderDispatchReturnSourceTest仅移除两个任务头客户setter并收敛两个mock调用，保留该文件此前未提交业务修改。异常原箱Mapper、客户进度、库存发运证明及派送Mapper中旧头客户SQL仍需总控独占分派，不顺手扩写。
 本次公共版本字段变更前的独立1052份源码构建（明确排除原预约ExecutionAdapter/TransportAdapter及当时未获写权的ExceptionOrderService，不是全服务Maven）运行62项，57通过，仅Fleet权限类5项缺新增Gateway测试Bean；补真实方法安全上下文依赖后该5项单独5/5通过。草稿新17项、主单/PDA/发车、SQL实体合同3项及Fleet审核只读1项在57通过之内；输出`target/dispatch-owned-compile/fleet-draft-tests.log`、`fleet-auth-tests.log`、输入`draft-input-evidence.json`（实际13/13及聚合b0db...554匹配）。后续公共预约版本字段、Provider及Fleet在途适配修正未由该结果覆盖，最终Maven仍须串行重跑。
 2026-10-19 17:39 IAM权限新输入串行验证：`mvn -pl iam -am '-Dtest=Phase5DeliveryPermissionSqlContractTest,Phase5DeliveryPermissionSqlExecutionTest,AuthorizationSnapshotServiceTest,IamOpenApiContractTest,OverseasPhase4PermissionSqlContractTest' '-Dsurefire.failIfNoSpecifiedTests=false' test`实际29/29（1+5+7+5+11）通过。源码与target/classes/db/lastleg-permissions.sql SHA-256均为9deef80d2bcf383918b5ad48a63bea893ced2d9a32528e33268c02e73bbd4f67。输出`.logs/dispatch-iam-retired-smart-tests.log`；报告`iam/target/surefire-reports/`。File49当前输入未变，本轮未重跑。
 预约接线正在实施：已新增`DispatchAppointmentAllocations`按Provider实际record字段顺序逐字段映射（Provider版本在第3字段，公共DTO在末尾），一次合并当前保留分配+新请求版本预锁，缺失/负数/同批混版本拒绝；create/add与草稿全groups预锁位于来源锁前。仅将已保存DispatchItem的真实客户传给bindItems，touched增量保留他人。源码已增加Fleet全范围父级/全部资源预锁及主单排序锁、内部预约改量端口实现：原主版本/零真实扫码/BEFORE_LOADING、完整实物及原分配集合复验、稳定父键子命令恢复，移出不解绑/取消整车，主单/来源/审核/历史随父事务回滚。新测试与整体验证尚在补齐；候选真实批读仍待Provider实际薄签名后接入，不能将这些源码视为已编译通过或链路完成。旧DispatchService.preArrange及两个私有单客户创建实现已移除，不恢复Provider旧bind/requireReplay；BOL仍待从旧platformDetail读取切到整车投影，旧测试和残留DTO同步继续。
@@ -0,0 +1,620 @@
 # 排车列表派送费用接口设计
 > 2026-10-19 已按正式契约第八至十节解锁首批实施。本文保留设计依据，实际骨架与本轮实现交接见第10、11节；与旧准备措辞冲突时以正式契约及实际共享骨架为准。Java编译/单测由主后端统一执行，尚无本轮部署或真实验收结论。
 业务唯一基线为[排车列表统一作业改造契约](排车列表统一作业改造契约.md)。本任务为 `01a1524f-56a9-7320-a5fd-8ff76fa4356b`，总控为 `01a15230-a9d6-7503-a8a9-d70691df49e5`；主流程后端为 `01a1524f-4f11-70c2-8a46-8e06e73a2d86`。本文件只提出 `delivery/`、必要 `financefee/` 和 `FleetBookingFreight.java` 的接口、数据及验证方案；共同 OpenAPI、权限、SQL 由总控集成，主流程类由主流程任务实现。
 ## 1 改造前核对与本批差异
 下表路径相对 `baiyue-firstleg/lastleg-service/src/main/java/com/baiyue/lastleg/`，记录实施前的源码定位，不是当前实现或部署完成证明；旧单客户转换类/DTO已按第10节清除。
 | 当前入口 | 当前行为与必须调整之处 |
 | --- | --- |
 | `delivery/service/DeliveryTransferService.platformTransfer/transferResolved` | 先锁全局排车，以 `DispatchOrder.customerId` 作为所有明细、出库和费用的客户；一个排车生成一个 `WAIT_OUTBOUND` 出库头，再按目的地生成派送单。当前未要求先确认装车完成，与新阶段不一致。 |
 | 同类 `validateTransferFees`、费用发布循环 | 全请求按 `direction:feeType` 去重；普通费用只挂第一张或第一个相关目的地派送单，不能表达同车多客户多目的地分别收费。 |
 | `delivery/mapper/OutboundOrderMapper` | `findByDispatch/lockByDispatch` 带客户且 `LIMIT 1`，可作为“每客户一张出库单”查询，不能充当新整车唯一出库查询。 |
 | `delivery/service/DispatchCargoSourceQuery`、`DispatchFeeCargoMapper` | 普通整托按库存组成及本次已拣恢复来源，核平每条排车箱数；换标、退货使用专用事实，不能改回展示入仓码或计划托单一来源。 |
 | `fleet/trip/FleetBookingFreight.preview` | 单客户参数；按真实入仓码找外接预订，检查 BOUND、车次/排车、目的地、实收托盘及数量、确认版本、约定币种和价格，返回报价及摘要。明确零约定只记商业事实，不发布零费用。 |
 | `delivery/service/DeliveryFeeCoverageService` | 单客户查询 Finance；核对费用 ID/版本/hash/状态和货物 hash。引用服务仅为派送、装车、买约；全相关货物已覆盖才免新增应收，供应商应付独立。 |
 | `delivery/service/DeliveryExecutionGuard` | 按一张客户出库核对派送覆盖、客户、数量和未执行状态；新整车应遍历完整客户出库集合并核对来源集合，不能只比较总箱数。 |
 | `delivery/service/DeliveryDocumentService.save` | 显式 READ_COMMITTED，先锁本派送；首次签收资料保存要求真实 OUTBOUNDED，校验文件归属及版本/请求键，写 signedAt/signedPackages、资料版本、完成 Outbox、回访。存在真实退回时可签剩余部分。 |
 | `delivery/service/SourceDeliveryCompletionQuery` | 调用方先锁自己的派送，再一次锁齐同客户全部相关来源订单（数字 ID 升序）；历史派送/排车/异常/库存只读，不反向加锁。用于跨多次发运证明头程来源全签，不能用一趟车全签替代。 |
 | `dispatch/fleet/DispatchFleetAdapter.completion`、`fleet/trip/FleetTripCompletionService` | 旧结案允许实签加真实退库等于实发；不是本批五阶段“全部正常签收”的判据。保留附加结案及资源释放能力，但不拿该结果自动映射本批派送完成。 |
 | `delivery/service/DeliveryTransferService.cancelOutbound` | 按 dispatch→outbound→delivery 锁序；已拣/已发禁止取消，车次须先解除；恢复来源原状态、清空关联、增加版本；只申请作废未履行的有效派送费应收，其他费用保留。 |
 | `delivery/controller/MerchantDeliveryController` | 客户列表/详情/签收资料严格取身份客户；当前另有客户 POST 创建接口，直接调用单客户转派送。该写入口与本批“后台安排整车派送”需要总控裁定收敛，不能悄悄开放整车操作。 |
 已观察到 `DeliveryTransferService`、`DeliveryFeeCoverageService` 有 Service 直调 Mapper，`OverseasFeeBusinessGuard` 有 JDBC。实施触及的方法须按后端指引收敛为 Service→Repository→Mapper，并补中文方法/关键规则注释；本轮未整改，不扩展无关财务业务。
 ## 2 推荐单据结构与归属
 ### 2.1 整车、客户出库、目的地派送
 推荐保留客户出库头模型：**一张整车排车 → 每客户一张出库单 → 每客户每目的地一张派送单**。不把出库头或费用的 customerId 写成平台 0，也不选第一个客户代替其他客户。
 示例仅说明数量关系：同车 A/ONT8、A/LAX9、B/ONT8 三组货物，产生 A、B 两张出库单和三张派送单。同一目的仓的不同客户永不合单；每张费用的客户必须与其业务派送单一致。
 - `ll_outbound_order` 保留真实 customer_id、dispatch_order_id/dispatch_no、仓及 `DISPATCH_DELIVERY` 类型。冻结提案为 `UNIQUE(dispatch_order_id,customer_id)`，约束语义与现有反序唯一键相同，不同时新增冗余反序索引；整车出库集合的 customerId 必须精确等于货物客户集合，每客户恰好一张，仓及排车引用一致。所有整车读取改为集合查询，不使用第一张出库单代表全车。
 - `ll_delivery_order` 保留真实 customer_id、所属客户出库、整车排车、目的地、地址及联系信息。保留 `UNIQUE(customer_id,outbound_order_id,delivery_group_key)`；每个“客户＋目的地”恰好一张，客户与所属出库相同，整车派送组集合与货物组集合精确相等。取消历史不删除、不靠清空关联绕唯一键；本批没有取消后新建第二次安排的协议。
 - 明细必须保存原排车明细标识及不可变实际来源关联；出库及派送都能由该关联还原每个客户、来源订单、来源入仓、实际箱数。不得仅从 `ll_order.outbound_order_no/delivery_order_no` 当前指针还原历史。
 - `deliveryGroupKey` 延续既有目的地键：FBA `CODE:<大写仓码>`，私人地址 `PRIVATE:<trim地址>:<trim邮编>`；仅有内部目的仓 ID 的情况需由主流程提供真实目的地，缺失阻断，页面不能展示 ID 回退。避免同时存在旧 CODE 和新 FBA 两套键；外接 `destinationKey` 与派送键只做显式、可测试的领域映射。
 - 对外预览的 `groupKey` 是客户与上述目的地的稳定摘要，包含 customerId；请求不能靠换 customerId 或 destinationKey 把一组货物移给另一客户。服务端完整重算分组，组集合必须与实际货物精确相等。
 - 物理托盘数按真实仓托盘 ID 去重；逐客户、逐目的地货物行不可当整车物理托数直接相加。实际重量/体积沿主流程确认值，不拿计费材积重补实测值。
 - 安排时只映射已完成的真实 PDA 拣货事实，不生成第二套 PDA 出库任务。普通 `DispatchPdaWorkflowService.pick` 已在扫码事务调用 `inventory.allocate/pick/ship`；退货换标由专用库存入口完成实际扣减。安排、装车完成和实际发车均不得再次调用这些已完成数量的库存 `ship` 或其他扣减命令。
 - 本稿的 **picked→shipped 仅指 `ll_order` 业务履约计数及单据快照转换**：`DispatchPickOrderAttributionService.depart` 锁来源订单，再调用 `LastlegOrderMapper.transferPickedToShipped` 将订单 picked_package_count 减少、shipped_package_count 增加、设置出库关联；它不是库存余额/仓位变更。发车仅对真实归属拣货执行一次该业务更新、更新客户出库/派送和整车阶段，全部客户同事务，任一失败全车回滚；扫码已经提交的库存事实保持，不因失败重做或伪造退库。
 - 出库明细已拣计数只来自对应客户、明细及来源的真实拣货，不能直接把计划箱数填成已拣，也不可表单补录。发车更新此类快照不增加任何第二笔库存流水。
 ### 2.2 整车安排记录（提交总控的结构提案）
 已落地delivery域 `ll_dispatch_delivery_arrangement` 的Entity/Mapper/Repository：唯一 `dispatch_order_id`，保存整车依据、business_hash、首次请求键及操作者、完整结果与来源JSON；具体列见第11节SQL提案。严格commandHash及每次请求结果使用主流程全局唯一键共同账本，不在安排表复制第二套命令协议。
 结果引用各客户出库和各组派送；出库头不新增冗余arrangement_id。出库明细保存dispatch_item_id及真实source_attribution_id、source_order_id、source_inventory_position_id、source_return_receipt_id、source_return_carton_id，避免混托/退回消费者仅凭展示入仓码猜来源。完整结果和cargo_json用于整车精确集合核对。不得仅以“有任意出库单”表示安排完成。
 必须有同一排车唯一安排、全局请求键共同账本和子单唯一约束三层防重复。正式契约已选定全局唯一idempotencyKey，不按客户/操作者分片；安排表original_command_key也唯一。键对应原主体、动作和排车不可更改，复用别人的键拒绝；新键同业务经当前权限及版本核验只引用原事实。实际调用DispatchExecutionPort.replay/recordArrangement，不在delivery自建主体校验账本。
 ## 3 待冻结 API 与 DTO
 下列均为拟议契约。统一平台前缀 `/api/platform/v1/last-leg`，复用 Gateway 已有 Lastleg 路由；本轮未改 Controller/OpenAPI/权限。
 | 方法与路径 | 请求/返回及权限建议 |
 | --- | --- |
 | GET `/dispatches/{dispatchNo}/delivery-arrangement` | 新增组合预览及业务事实恢复入口，`dispatch:list`。返回阶段、recordVersion、装车完成事实、canArrange/blockReason、cargoHash、groups、各组外接报价/原费候选/应填服务、已存在的安排结果。一次 GET 内共享同一 Lastleg 只读快照，前端只调用这一次，不再并发两个辅助 GET 拼不同版本；恢复不依赖客户端重组结果。严格命令原请求/原结果另受命令主体授权，不因 list 权限开放别人的原请求。 |
 | POST `/dispatches/{dispatchNo}/transfer-delivery` | 复用路径，替换旧单客户 DTO 为整车安排请求，独立 `dispatch:transfer-delivery` 权限。只允许平台且装车后、未发车；不接收顶层 customerId、货物数量或车辆司机覆盖值。 |
 | GET `/dispatches/{dispatchNo}/external-freight` | 现有只读辅助入口按客户和目的地分组返回，报价增加真实 customerId/groupKey。与组合预览共用同一查询，不维护第二种算法。 |
 | GET `/dispatches/{dispatchNo}/fee-coverage` | 现有只读辅助入口按客户和目的地返回货物/原费用候选；保持平台权限，不能将整车 Finance 费用候选暴露给客户。 |
 | GET `/delivery-orders`、`/delivery-orders/{deliveryNo}`及资料接口 | 平台沿现有权限与客户定位，客户沿身份客户过滤；新结构不改变单张派送资料的归属。客户只读响应不带其他客户出库、派送或原费用快照。 |
 拟议记录（名字和 JSON 字段供总控冻结，整数 ID 对外按既有 Long 字符串约定）：
 ```text
 ArrangeDeliveryRequest {
  idempotencyKey, recordVersion, cargoHash, loadingCompletionHash,
  groups: [ {
    groupKey, groupCargoHash,
    plannedDeliveryAt, deliveryMethod, waybillNo, carrierName, pickupMethod,
    loadingType, vehicleType, vehicleSize, appointmentAccount, sellerName, remark,
    externalFreightHash, feeCoverageCargoHash,
    feeCoverage: [{ financeFeeId, sourceVersion, sourceHash, services }],
    fees: [ FeeItem ]
  } ]
 }
 ArrangementResult {
  dispatchNo, recordVersion, arrangementKey, cargoHash, arrangedAt,
  outbounds: [{ customerId, customerName, outboundNo, status, packageCount, palletCount }],
  deliveries: [{ groupKey, customerId, customerName, outboundNo, deliveryNo,
                destinationWarehouseCode, destinationWarehouseName,
                destinationType, deliveryAddress, status, packageCount, palletCount }],
 }
 CommandResult { dispatchNo, action, idempotencyKey, recordVersion, status, stage,
                occurredAt, effect, counts, result: ArrangementResult, replayed, alreadyArranged }
 ```
 - `FeeItem` 复用现有费用字段：类型、名称、方向、币种、金额、数量/单位/单价、期间、供应商、结算方式、直接已付信息及凭证；按组确认，不再把整车总金额默认挂第一客户或第一目的地。每组 `(direction,feeType)` 唯一，整车不同组可重复同类型。
 - 对外安排请求只用 `recordVersion`，0 是合法首版；无 `expectedVersion` 别名。内部锁/CAS 参数如叫 expectedVersion 仅表示预期含义，不进入公开 JSON。派送资料等本批实际触及 DTO 的版本命名也由总控统一收敛，不把当前源码字段当作新契约别名。
 - 车辆司机只从主流程已确认快照复制（包括真实临时外配信息和空主档关联），安排请求无权改派。`carrierName` 等派送字段不得反向修改整车资源。
 - 返回所有出库和派送单，不保留单个 `outboundNo` 作为多客户响应别名；Admin、恢复逻辑及脚本同批更新。`replayed` 仅表示原严格命令重放；`alreadyArranged` 表示查到既有整车安排而未再次建单，两种情形按第5节区分。不可变动作结果中的 recordVersion 是原动作版本；组合 GET 的顶层 recordVersion/stage 才是当前事实，前端不能用旧结果覆盖当前详情。缺失业务编号显示“—”，内部 arrangement ID 仅用于技术关联。
 - 既有费用更正继续走正式来源更正，不通过换请求键重新安排、重发外接报价或重建单据。
 - 用户已确认本类整车派送仅平台安排。本轮已删除Merchant创建POST及merchantTransfer服务入口，保留客户列表、详情、签收资料及下载。Client直接消费者由前端任务删除，共同权限/OpenAPI与脚本由总控集成，不保留另一套客户部分安排协议。
 组合 GET 拟在一层 `REPEATABLE_READ, readOnly=true` 事务里一次读取整车上下文、全部客户货物、子单、费用本地快照，再按该上下文生成分组与本地摘要；内部查询必须加入同一事务，不各开快照。Finance 远程候选无法参与 Lastleg 数据库快照，按客户带费用版本/hash及读取时间返回，POST重新确认，不声称跨服务同刻快照。组内缺来源/报价变化/候选不可用分别返回结构化 `blockReasons`、`sourceComplete`、`feeCoverageStatus`，不把失败转成已覆盖；需要该证据的确认必须阻断。前端不能在同一弹框重复辅助 GET 另拼资格。
 ## 4 来源、报价与费用校验
 ### 4.1 实际货物摘要
 主流程提供不可变、已核平来源行：`customerId, dispatchItemId, sourceStage, orderId, sourceRegion, sourceInboundId, inboundCode, warehouseId, warehousePalletId, palletNo, destinationKey, packages, pickId/attributionId, inventoryPositionId, receiptId/returnReceiptId`，以及退货/换标所需真实箱和数量引用。不能因为某类没有头程来源 ID 就伪造一个。
 排车明细箱数、真实拣货箱数、来源归属箱数按“客户＋排车明细”逐条相等，明细集合也相等；同托多来源全部保留。排除展示 `MIN(inboundCode)`、订单声明 SKU 箱数、FIFO 猜来源。装车后费用范围以本趟冻结拣货为准，不能把该托后来新进的可用库存算入本次派送。
 `cargoHash` 应按稳定字段、明确 null 语义及固定排序计算；排序至少按 customerId/dispatchItemId/attributionId。分组 hash 包含客户、目的地、实际来源及数量；装车 hash/事实版本单独保留。规范化仅对契约声明无序的组、费用及选择集合排序、金额固定精度序列化；不能把有业务意义的顺序或原载荷值丢掉。
 两类摘要职责严格分开：
 - **commandHash**：动作 ARRANGE_DELIVERY、排车号、可信原请求主体（userId/appCode/客户范围/PDA绑定仓如适用）、原始 recordVersion、完整规范化请求载荷（含所有业务与证据字段）。请求键作为独立唯一键；除该键外不删除 recordVersion、操作者或请求字段。角色/权限每次读取实时验证，不把旧角色 hash 当当前授权。原键要求主体、动作、单号、版本、载荷全部相同。
 - **arrangementBusinessHash**：排车号＋货物/装车依据＋全部客户目的地派送信息＋费用内容和引用证据，移除请求键、操作者及纯并发 recordVersion。仅用于同车已有安排与另一请求键的业务等价判定及防重复；不能用它验证原命令重放、越权主体或旧版本。
 请求 DTO 不接受客户端自报上述两个可信摘要；由服务端计算。前端保留原载荷、原 recordVersion 和键，未知结果不自动改版本再重试。
 ### 4.2 外接实收报价
 - `FleetBookingFreight` 以真实客户分片接收来源和绑定上下文；Quote 增加 customerId/groupKey，按 `(customerId,inboundCode)` 识别，不能用全车 inboundCode 集合跨客户免收费。
 - 保留 BOUND、排车及车次身份、预订 recordVersion、实收记录、完整托盘数量、目的地、PALLET/整单计价和 CNY/USD 校验。预览 hash 包含客户及主流程货物 hash；确认前在整车父锁协议内重验，报价/实收变化一律冲突，不补造库存。
 - 正数约定只发到同客户同目的地派送，费用键基于真实 bookingNo＋本趟排车＋组＋FREIGHT，稳定且与操作者无关；现有费用命令即使包含 operatorId，整车安排唯一事实也必须阻止换人重复发布。
 - 明确零约定保存确认操作和来源版本，不发布零费用。全部为外接已约定来源的组禁止另填派送应收；混托普通来源仍按该组未覆盖的真实普通货物收费，不能整托免单。
 - `priorInboundCodes` 按客户查询原有效派送应收；未确认作废前保持阻断。申请撤销、超时、拒绝均不能当作已作废再次收费。
 ### 4.3 原费用覆盖与新增收费
 - Finance 仍按既有内部批量只读契约，每客户查询真实头程 sourceInboundId；不跨库、不扩大 Finance 账务模型。只有请求确实选择原费覆盖时才强制 Finance 可用，不能在失败后静默认定已覆盖；未选择覆盖的预览也应明确候选加载失败。
 - 确认复核 financeFeeId、customerId、sourceInboundId、sourceVersion、sourceHash、原费类型/状态/币种及实际货物摘要；跨客户费用或过期证据直接拒绝。该协议是确认时有效快照，之后财务更正不追溯改写发运，不声称拥有跨服务数据库原子锁。
 - 覆盖选择在客户内按 `(sourceInboundId,service)` 去重；同一真实原费覆盖的来源分到多个目的地时允许分别引用证据，不能据此复制原费用。每组计算未覆盖来源，不能用“全车 coveredServices”免除另一客户或目的地应收。
 - 原费只证明明确服务覆盖，不复制费用、不按原金额抵扣、不生成伪零费用。新增派送应收仅针对未覆盖普通来源；散装/混装装车费、买约费沿现有规则逐组核对，买约仍要求卖家。
 - 供应商应付独立，不能因客户原费覆盖而免掉。金额必须正数，费用币种 CNY/USD，已付凭证继续按真实客户/来源校验，不伪造支付。
 - 每笔费用 `businessType=DELIVERY_ORDER`、businessId/businessNo 为本组派送；customerId 与该派送相同。只有来源唯一时附 orderId/inboundCode/集装箱引用；多来源不借第一票展示码冒认归属，由派送及冻结来源明细证明范围。
 - 费用来源、自动审核、不可变 Outbox 与安排单据处于同一 Lastleg 事务；Finance 入池经现有投递、幂等和 ACK。安排成功只代表本地费用与 Outbox 已保存，不代表 Finance 已到账、已收款或已结算。
 ## 5 事务、幂等与锁顺序
 ### 5.1 安排与发车
 采用显式READ_COMMITTED写事务；正式契约第九节已选定 **trip→车辆→司机/资源→dispatch**，取代准备稿的相反序列。先非锁定定位父身份，锁后重验一对一关系；delivery只调用实际DispatchExecutionPort.lockForArrangement，不自行取得或重排父/资源锁。安排与发车先收齐全部客户出库/派送锁，再来源/费用；尚未完成联合并发验证，不能宣称全域无死锁。
 严格命令与业务重复的处理：
 | 场景 | 授权与结果 |
 | --- | --- |
 | 同键、同主体、同原版本/完整载荷 | 每次先核验当前平台写权限及合法范围；commandHash一致才返回该命令原不可变结果，`replayed=true`。命令恢复在首次写入版本/阶段检查前，允许原命令后阶段已变化；不再创建单据、递增版本或发布费用。 |
 | 同键、不同动作/单号/原版本/载荷 | 409，不能拿相同 businessHash 豁免严格冲突。 |
 | 同键、不同操作者/主体 | 403或不泄露原内容的冲突，禁止读取或借用原请求。其他操作者即使有安排权限，也不能重放别人的命令；正式审计读取如有既有独立权限只读原证据，不获得执行身份。 |
 | 新键、同车同业务、同或不同操作者 | 当前主体须具有安排写权限，recordVersion须为当前版本；锁内比 arrangementBusinessHash。既有安排完整有效则只引用原事实，`alreadyArranged=true,replayed=false`，在共同命令账本保存本主体此次“引用既有安排”不可变结果，不增加主版本、不产生新费用。以后重放此新键仍按其自身 commandHash。 |
 | 新键、同车不同业务或旧版本 | 409，费用调整另走正式流程，不能第二次建单。新键使用旧版本即使业务相同也先冲突，不自动刷新版本；用户读取当前事实后才形成明确的新请求。 |
 | 原安排取消/失效/缺子单 | 严格原键仍可取原不可变动作证据，当前状态通过GET另查；新键不得把它报作有效已安排，也不补建残缺集合。GET返回实际状态/缺项并阻断新写，等待正式业务处理。 |
 安排首次写入顺序：当前身份授权→父锁→严格命令恢复/全局键归属→recordVersion与装车后资格→核对全车来源快照/分组→锁或创建**全部**客户出库及派送→锁齐本次需要更新的来源订单/换标/转运→来源关联→逐组费用/Outbox→主流程 `finishArrangement`→完整命令结果。不能每组“锁来源、写费用后再去锁下一组派送”；全部子行先于任何来源写锁。新建子单此时未提交不可能合法签收，已有安排在恢复分支返回，不对同一事实重复执行此链。
 发车顺序：父锁→命令恢复/当前版本→资源/审核/PDA核平及预约批次复验→锁齐完整客户出库/派送并核对来源集合→`DispatchDeliveryPort.markDeparted` 写已锁子单→主流程 `DispatchPickOrderAttributionService.depart` 按真实来源逐单转换**订单履约计数**及换标/转运/Fleet履约事实→整车阶段/唯一历史/命令结果。后段不得再获取一张此前未锁定的派送行；安排、装车、发车均不执行普通扫码已经完成的库存 ship。
 所有客户、所有目的地、全部来源绑定、费用来源/Outbox和主单CAS均在一个 Lastleg 事务内；任意一笔失败全体回滚，不能逐客户 REQUIRES_NEW 提交。数据库唯一键竞争用当前读确认 commandHash/业务hash及完整数组结果，不能依赖旧快照或吞掉部分写失败。未知结果保留原键，业务组合 GET 可查既有单据，原命令查询/POST重放才证明该次操作归属；404或查到相似单据不能当原命令成功。
 列表和组合预览批量查询，不逐行请求详情/附件；资格只是展示，写入必须重验。不得在锁内投递 Finance HTTP 写命令。Finance 原费只读确认如放在锁内必须有现有超时并失败回滚；可先预检，再在锁内做最终只读复验，不把锁前结果冒充确认结果。
 ### 5.2 本轮沿代码核对的实际锁点与拟收敛执行链
 | 入口及当前实际锁点 | 本批精确收敛要求/唯一写者 |
 | --- | --- |
 | `FleetTripExecutionService.depart` 当前先trip，后车辆及资源，再 `DispatchFleetAdapter.manifest` 的 dispatch→outbound→task→delivery；随后子发车 | 正式共同根锁保持trip→车辆→司机/资源→dispatch，预约批次按batchKey固定顺序，完整客户子单先于来源锁。主流程所有入口须复用同序列，不能回退准备稿trip→dispatch→资源。 |
 | `DispatchPdaWorkflowService.pick` 当前 dispatch→task→`requirePickingApproved`内binding；`preparePicking`再锁来源订单数字ID升序及退回实收记录，库存内部 `locked()` 为position→balance；退货换标先 `prepareNativeReturn` 来源订单再锁箱 | 主流程共同根锁为trip→车辆→司机/资源→dispatch；随后task/binding→来源订单/实收→position→balance（或退货专用箱锁）。扫码不申请出库/派送行锁，结束前不进入派送回调。保留库存内部顺序和真实扣减；不能改成balance→position。 |
 | 旧 `DeliveryTransferService.platformTransfer` 为dispatch→已有outbound→binding，按目的地循环创建再绑定来源；新Controller已改接DispatchDeliveryService | 新服务只通过主流程父端口取得trip→车辆→司机/资源→dispatch，再完成全部子出库/派送创建或锁定，最后才统一锁来源/绑定/费用。普通UPDATE也产生行锁，不能仅统计显式FOR UPDATE。旧内部实现与跨域旧测试的最终清理由后续联合收口列明。 |
 | `DispatchPdaWorkflowService.depart` 当前 dispatch→binding→outbound→`DeliveryExecutionGuard.requireDeparture`锁派送→task→`DispatchPickOrderAttributionService.depart`锁来源订单 | 主流程与本任务协作：父级→task/只读核平→全部客户outbound→全部delivery→来源。`markDeparted`先于来源更新，来源更新只触及已锁的单据集合；不重新请求其他派送锁。 |
 | `DeliveryTransferService.cancelOutbound` 当前先dispatch/相关relabel，后outbound→delivery，之后费用来源、来源恢复 | 有整车关联的合法未执行取消，先非锁定定位，再父级/必要批次→全部目标outbound/delivery→来源/相关relabel→费用及历史；已拣直接拒绝。其他独立出库类型维持其已确认协议，不伪造trip。父级改动归主流程，取消实现归本任务，跨relabel/转运的真实锁点实施时定向复核。 |
 | `CustomerVisitService.updateDeliveryStatus` 当前 outbound→delivery，不申请dispatch；`DeliveryDocumentService.save` 当前delivery→`SourceDeliveryCompletionQuery.proveAll`的来源订单 | 普通状态变更若与发车竞争需先取得共同父级再outbound→delivery，由总控分配该类写权。签收资料保持delivery→来源，不拿outbound写锁、不反向父锁；仅提交后持久提醒。 |
 | `FleetPoolOrderBridge.signed/departed` 在来源处理后 `links.lockDispatch`，再由 `move` 锁本土卡车/散板商业单；不申请父trip | 这两条既有直接副作用保留来源→pool link→商业单顺序，不在其后回取派送/父锁；全部相关来源应在进入商业事实更新前收齐锁。主流程/Fleet商业域写权不足的触点交总控，不能以“只写历史”忽略商业单真实行锁。 |
 约束是分命令的有向次序，不是把所有领域拼成一条虚构的全局序列：**扫码为父级→task/binding→来源→库存，且不再取派送锁；安排/发车/相关取消为父级→完整子出库/派送→来源→费用；签收为本派送→来源→本地提醒，始终不取父锁。** 来源订单对多客户使用统一数字ID升序（ID全局唯一），同一客户下也保持现有数字顺序；子单按customerId数字值、业务ID升序，明细/来源集合一次收齐，不边持后序锁边发现新前序行。
 预约批次/资源提供者、换标和转运的直接调用是否会回头取父/派送锁仍属实施审查项，触点未分配不得改；若发现反向锁必须由总控调整唯一入口或分配写权后再实施，不能以“整车已串行”忽略跨历史来源并发。现阶段只是完成上述代码锁点核对，未运行并发测试或证明全域无死锁。
 ### 5.3 取消、修改和财务竞争
 - 本批安排发生在真实拣货并装车完成后，既有“已拣禁止直接取消出库”仍成立；不能为新流程放开取消或伪造退库。装车后取消/退装的新增业务流程尚未授权，不提供快捷撤销接口。
 - 既有其他尚未执行出库类型的取消保留其业务限制；有整车父关联时按第5.2节父级→出库/派送→来源取得锁，禁止子单自行解除全车。物流取消不释放另一客户占用或自动恢复实发库存。
 - 来源原状态只从真实本次转换历史恢复，清空关联和版本规则保留；混托来源各自核对。费用只申请作废本派送当前有效 DELIVERY_FEE 应收，装车费、买约费、供应商应付及其他来源不自动作废。
 - 费用调整/撤销保留现有 READ_COMMITTED、来源行锁和未决撤销检查；Finance APPLIED/DUPLICATE 且 hash 匹配才确认 VOIDED。若调整与整车证据变化会影响发车，主流程须按安排事实失效规则阻断，不能静默重写原安排费用。
 - 改货物、目的地、关键资源后如何使审核/装车/安排失效由主流程提供单一规则；delivery 不解锁修改、不隐式删除派送。冻结时需说明是否在存在安排事实后直接拒绝这类修改，或如何经过明确重审动作；不得保留“修改了车、货但派送仍旧可发”的窗口。
 ## 6 正常签收汇总与异常边界
 `NormalDeliveryFact` 建议包含：`customerId, dispatchNo, arrangementKey, outboundNo, deliveryNo, groupKey, deliveryVersion, originalPackages, signedPackages, signedAt, outboundCompleted, returnedPackages, activeReturnCount, status`。来源为真实出库、派送签收字段、资料修订及退回事实；不以附件数、状态文字或最后更新时间单独判定。
 整车正常完成必须同时满足：已真实发车；安排组集合和实际派送集合精确相等；全部客户出库已 OUTBOUNDED；每张原实发大于零；每张具有真实 signedAt 且 signedPackages 等于本张原实发；本趟没有以退回替代正常签收的数量及未处理异常；签收时间不早于实际发车且不晚于当前时间。完成时间取本趟最后实际签收时间，空集合/部分签收绝不完成。
 - `DeliveryDocumentService.save` 保留 READ_COMMITTED、本派送锁、版本、请求 hash、文件客户＋业务＋类别归属；首次签收仍先验证实际出库和活动异常。BOL/装车资料可提前准备，签收资料不能提前伪造完成。
 - 一张单发生拒收、RETURN_PENDING、真实退回，或退回后仅签剩余部分，本趟仍不能汇总“派送完成”。既有异常单及真实退库能力保留，本批不新建异常闭环，也不把线下处理意见当作全量正常签收。
 - 已经全量签收后再另发起退货，保留原运输不可变签收事实，不重开已正常完成的本趟；核对退回事实是否发生在本次全签之前，不能只看当前状态或任何历史退货存在就否认原运输完成。
 - 整车正常完成不代替 `SourceDeliveryCompletionQuery` 跨全部历史发运的头程来源证明；跨次拆发、实退再派必须沿真实来源及流水证明，防止提前发布头程整来源完成事件。
 - 现有 `FleetPoolOrderBridge`、完成 Outbox 和回访只消费各客户真实签收；不因整车汇总二次发布费用或重复扣库存。车辆/司机释放仍是独立事实，不随五阶段完成自动释放。
 ### 汇总调用建议：提交后重读，避免反向锁
 当前签收锁序为本派送→全部相关来源订单。**不要在该事务持有派送或来源锁时回调申请父车次/排车锁。** 采纳主流程稿第5/6节持久 `DeliveryFactsChanged` 方向，具体持久化边界提案如下，等待总控冻结表名/调度入口，不留“靠内存通知”分支。
 | 环节 | 具体提案及唯一写者 |
 | --- | --- |
 | 记录结构 | delivery域新增 `ll_delivery_facts_changed`，字段 `id,customer_id,dispatch_id,dispatch_no,delivery_id,delivery_no,delivery_version,facts_hash,occurred_at,state,attempt_count,next_attempt_at,last_error_code,processed_at`；状态仅PENDING/PROCESSED，唯一 `(customer_id,delivery_id,delivery_version)`。只作同Lastleg本地待核对事实，不新增跨服务事件类型；DDL交总控集成。 |
 | 事实写入 | 本任务在 `DeliveryDocumentService.save` 正常签收事实落库、来源证明/完成Outbox/回访成功的**同一事务**插入PENDING；回滚则提醒也不存在。原资料命令重放在写入前返回，无第二条提醒。未来其他合法入口改变正常完成依据，也须同事务写提醒，由总控分配其文件写者，不让本任务越权修改异常/回访。 |
 | 数据访问 | 本任务独占 delivery内Entity、Repository、Mapper及直接持久化测试；通过共同端口提供 `pendingCandidates(limit,now)` 普通读、`ackProcessed(ids)`、`recordFailure(id,code,nextAt)`，不从签收线程调用主流程Service。消费端不直调delivery Mapper。 |
 | 消费与汇总 | 主流程唯一维护 dispatch内有界任务/调度入口（拟 `DispatchDeliveryCompletionJob`）及 `DispatchCompletionPort.reconcile`。先普通读已提交PENDING候选；每趟另起READ_COMMITTED事务，trip→dispatch锁，调用 `DispatchDeliveryPort.normalDeliveryFacts` 批量普通读全部已提交事实，再CAS五阶段及唯一完成依据，最后经delivery端口确认本次已核对的候选。整个事务不锁历史来源、不执行库存/费用/回访完成副作用。 |
 | 领取和确认顺序 | 不先锁/持有提醒行再申请父锁。候选扫描不使用FOR UPDATE、也不在父事务外预持PROCESSING锁；两个执行器可看见同一候选，由父锁/CAS与幂等汇总串行。提醒确认置PROCESSED与主单汇总处于同一事务，顺序为父→普通读事实→主单写→提醒行；不能先标处理完再更新阶段。未全签但已核对完的候选也可确认，后续客户签收会产生自己的新提醒。 |
 | 失败和崩溃恢复 | 主流程负责重试、退避/批量上限及有界重扫已发车未正常完成整车；本任务提供提醒持久化操作。汇总或确认失败整体回滚、PENDING保留；错误次数/下次时间只能在回滚后独立短事务记录，不持提醒锁回头申请父/来源锁。进程提交前退出仍为PENDING，签收提交后通知丢失靠持久扫描恢复，重复消费没有二次阶段/历史副作用。无需新增长期调度平台或依赖内存afterCommit；如用afterCommit只作唤醒优化。 |
 | 测试边界 | 本任务写“签收与提醒原子、签收重放无重复、提醒Repository及状态操作”测试；主流程写“两个最后签收、重复消费、消费中断/重试、确认回滚、未完成整车有界重扫、父锁汇总不反向子锁”测试并统一运行Maven。跨两包集成fixture由总控指定唯一写者。 |
 `facts_hash` 仅证明触发时的派送事实版本；消费必须重新读取全部客户，不将消息中的allSigned结论直接落主单。只确认已扫描且确实核对过的事件ID，不能批量吞掉扫描后新产生的提醒。组合GET可返回已提交当前阶段，签收提交到汇总提交之间允许短暂保持派送中，前端不直接写成完成；故障可观测字段若需公开由总控另冻最小schema。
 主流程汇总只普通读客户出库/派送，不调用会锁来源订单的 `SourceDeliveryCompletionQuery`。来源全签证明继续在签收自己的事务完成，整车汇总不重复发布原来源事件。以上是有明确写者的提案，尚未写记录、调度器或运行恢复测试。
 ## 7 实际主流程端口与共同实现核对
 本次差异修订选用主流程稿第5节的一套 `dispatch/port/` 契约名作为冻结提案；该包仅放DTO/接口，不依赖任一实现/Entity，delivery实现派送端口、消费主流程执行端口，不再并建初稿的ContextPort/ArrangementQuery/Departure/NormalFacts四套同义接口。主流程类不得注入派送具体实现反向调用其公开Controller；依赖分析仍待实施验证，包名最终由总控冻结。以下不是已存在代码。
 | 方向 | 拟议端口 | 必须保证 |
 | --- | --- | --- |
 | delivery→主流程 | 实际 `DispatchExecutionPort.preview(actor,dispatchNo)`，来源在Context.cargo | 加入组合GET同一只读事务；返回全车/逐客户已核平来源、仓、recordVersion、阶段、装车事实及车辆司机快照，真实临时外配无需伪造档案。cargo使用唯一权威来源，不能两域各推一份数量。 |
 | delivery→主流程 | 实际 `DispatchExecutionPort.lockForArrangement(actor,dispatchNo)` | MANDATORY，trip→车辆→司机/资源→dispatch；先只锁及复验身份/关联供严格命令恢复，新命令才验证recordVersion和阶段，不能在恢复前拒绝旧版本。这里只取得父/资格事实，不先锁来源后让delivery反向锁子单。 |
 | delivery→主流程 | 实际 `DispatchExecutionPort.replay(context,actor,identity)`、`requireFreshArrangement(context,recordVersion)`、`recordArrangement(context,actor,identity,fact,alreadyArranged)` | 严格命令恢复先于新版本阶段校验；首次全部客户成功才CAS/历史及安排引用，阶段仍装车后；不写派送表。新键同业务只复用事实，不增版本或重复收费。 |
 | 主流程→delivery | `DispatchDeliveryPort.departureFacts(locked,lock)` | 全部客户出库/派送/费用确认事实及精确来源集合；lock=true仅在父锁写事务中，按第5.2节一次锁齐子单，之后才能请求来源写锁。 |
 | 主流程→delivery | 实际 `DispatchDeliveryPort.markDeparted(context,actor,departedAt,commandKey)` | MANDATORY，更新已锁全部客户出库/派送执行快照，返回逐客户实发业务事实；不调用库存ship、不转换ll_order计数、不更新整车阶段。主流程随后唯一调用订单归属发车更新，任一失败所有客户同事务回滚。 |
 | delivery→持久记录→主流程 | `DeliveryFactsChanged(dispatchNo,deliveryNo,deliveryVersion)`、提醒数据访问端口 | delivery保存提醒及Repository实现；主流程扫描/消费/重试，经端口确认；明细及ack边界见第6节，无签收线程同步reconcile。 |
 | 主流程→delivery | 实际 `DispatchDeliveryPort.normalDeliveryFacts(context)` | 批量普通读所有本趟客户出库/派送、正常签收/异常/缺项，返回expectedDeliveryNos、数量、allNormallySigned、factsHash及最后正常签收时间；空集合为false，不锁来源，不分页漏项。 |
 | 主流程消费入口 | 实际 `DispatchCompletionPort.reconcile(signal)` | 主流程新事务父锁后读取已提交正常签收事实，幂等CAS阶段和完成时间/依据；最后经DispatchSignalPort确认已核对提醒，不能回原签收事务执行。 |
 | 主流程→FleetBookingFreight | 权威整车绑定/客户来源上下文 | 逐客户真实派送来源＋统一父身份、预订/实收版本；`FleetBookingFreight` 不在子锁后反向申请父锁。其他 fleet 文件改动归主流程。 |
 共同实现核对项：
 1. 一对一fleet父行及trip→车辆→司机/资源→dispatch已由正式契约确定；公开dispatchNo、recordVersion及五阶段以实际DispatchContracts/DispatchTypes为准，主流程来源由共享Context.cargo提供。
 2. 逐客户 `dispatchItemId`、实际来源/拣货/退货/换标事实字段、目的地规范与组键；尤其父排车头平台范围时，`DeliverySourceEvidenceMapper` 当前 `ds.customer_id=d.customer_id` 的联查必须同步调整为权威整车关联＋明细客户隔离，不能直接删客户校验。
 3. 装车完成事实/hash、严格commandHash与arrangementBusinessHash、全主体安排键注册与共同命令账本的唯一约束；原键恢复先于新版本/阶段判断，新键复用须当前recordVersion和当前写权限。旧严格命令跨主体不可重放。
 4. 具体采用本稿每客户一出库及每客户目的地一派送、全数组响应与组合GET单一快照的提案；缺项/加载失败schema及HTTP 409/403/404；单客户DTO/单出库消费者同批替换。
 5. delivery只更新子出库/派送；主流程唯一更新订单履约计数和整车阶段；扫码已完成的普通库存ship不再调用。全部客户发车原子回滚，预约批次/工作事项及外接BOUND守卫保留。
 6. 第6节持久提醒表/端口及主流程任务类名称、重试/重扫上限和唯一写者；第5.2节所有父/子/来源锁序，预约/换标/转运附加锁点还需对应写者审查；旧fleet结案只作为附加事实保留。
 7. 客户旧创建入口已获批准移除；Client由前端任务、脚本/权限/OpenAPI由总控集成。临时外配证据、实载弹框和零扫码退回重审已按第八节确认，不再待用户重复裁定。日历新增预约按第十节排除，不新增其设计、API或矩阵。
 已读取主流程实际dispatch/port骨架并接入DispatchExecutionPort、DispatchDeliveryPort、DispatchSignalPort；它们覆盖早期提案的签名。主根锁、全局键及客户创建去向已由正式契约冻结；剩余为真实实现及联合验证，不能沿用准备稿相反序列或另造DTO。
 ## 8 直接生产者、消费者和文件写权
 | 文件/范围 | 本批关系及归属 |
 | --- | --- |
 | Lastleg `delivery/controller/DeliveryTransferController.java`、`PlatformDeliveryFeeCoverageController.java`、`MerchantDeliveryController.java`、DTO/Entity/Repository/Mapper/Service及本域测试 | 本轮已按解锁范围实施，实际差异见第10节；其他独立出库业务保留。 |
 | `fleet/trip/FleetBookingFreight.java`、`FleetBookingFreightTest` | 本任务独占；其引用的 FleetBookingMapper/Reservations/DispatchGateway 变化由主流程提供端口，不能顺手修改其他 fleet 文件。 |
 | `financefee/service/OverseasFeeSourceService.java`、`OverseasFeeBusinessGuard.java`、相关 Repository/Mapper/直接测试 | 仅发生真实归属/幂等或必须分层整改时修改；既有 Outbox、撤销 ACK、币种/供应商校验保留，不扩大 Finance。 |
 | `dispatch/pda/service/DispatchPdaWorkflowService.java`、`dispatch/fleet/DispatchFleetAdapter.java`、`fleet/trip/FleetTripExecutionService.java`、`FleetTripCompletionService.java` | 主流程唯一写者：当前依赖单客户、单出库、旧完成规则的主消费者。 |
 | `delivery/mapper/DeliverySourceEvidenceMapper.java`、`SourceDeliveryCompletionQuery`、完成 Outbox | 本任务同步新父关联/分组和历史实际来源证明；跨次来源锁协议保留。 |
 | `customervisit/service/CustomerVisitService.java`、`exceptionorder/`、File 提供者 | 直接相关但本任务未获生产写权；单据归属/签收事实若要求触及，列精确方法给总控分配。不能删除异常、回访或附件权限。 |
 | Admin `overseas-warehouse/api/dispatches.ts`、`pages/DispatchesView.vue`及测试 | 前端任务处理组合预览、逐客户目的地费用、完整数组响应与恢复；详情仅消费已冻结契约。 |
 | Client `order-management/views/DeliveryOrderCreateView.vue`、`api/deliveryOrders.ts`、`deliveryOrders.test.mjs` | 已由正式契约批准移除，前端任务负责直接消费者；客户列表/详情/签收下载继续真实客户隔离。 |
 | PDA `fulfillment.js`、dispatch 工作流 | 前端及主流程任务同步全车结果/版本，保持真实拣货、装车与发车动作分离；不消费平台整车费用候选。 |
 | `src/main/resources/openapi/overseas-business-v1.yaml`、安全权限、基线及统一 SQL、Gateway | 总控统一集成。派送资料/客户契约的 schema 引用一并核对，不由本任务并写。 |
 | 后端 `scripts/overseas-relabel-fulfillment-acceptance.mjs`、`prod-release-overseas-stage.mjs`、`admin-test-env-modules/phase5-root-fulfillment.mjs`、`phase5-overseas-fulfillment.mjs`、`fleet-external-dispatch-acceptance.mjs`、`fleet-fee-coverage-acceptance.mjs`、`fleet-test-env-acceptance.mjs`及其合同测试 | 已命中旧转派送路径或单出库形态，需总控分配脚本同步；本轮不执行、不假定未命中的脚本都无需修改。 |
 既有工作区还有其他模块未提交修改，包含 `ExceptionOrderDispatchReturnSourceTest.java`；本任务未写这些文件，后续跨域测试冲突交总控协调。
 ## 9 用例与后续验证命令
 以下为待实施的行为测试清单，不是本轮通过结果。Maven 全部交主流程任务串行执行。
 | 组 | 必覆盖行为与证据 |
 | --- | --- |
 | 单据与客户 | A/ONT8、A/LAX9、B/ONT8 得两出库三派送；同目的仓不串客户；所有子单来源集合完整；客户 B 查询/附件/原费引用不能访问 A；伪造 groupKey/customer/destination 被拒。 |
 | 阶段与空单 | 空单、拣货未齐、未确认装车、装车 hash 过期、已发车禁止首次安排；装车后安排成功才能发车；不能通过普通状态编辑绕过。 |
 | 真实来源 | 普通多入仓混托、混普通/外接、换标、退货换标及真实退回重派；扫码库存只扣一次，安排/装车/发车没有新增ship流水；发车只变订单picked/shipped计数及出库事实，同托后到货不改变已冻派送；实际SKU/箱来源不从声明推定。 |
 | 原费 | A 引用 B 原费、过期版本/hash、Finance 不可用、同源同服务重复选择拒绝；部分覆盖仅免对应来源；全覆盖不造新/零费用；不同目的地引用同源证据不复制原费；供应商应付独立。 |
 | 外接 | 两客户相同或相似入仓码不串价；预订/实收/目的地/数量/绑定改变拒绝；明确零只记事实；普通混货仍收未覆盖部分；前笔撤销未 ACK 不重收。 |
 | 事务与竞争 | 同键同主体严格原载荷恢复；同键改recordVersion/动作/单号/操作者拒绝；新键同业务仍核当前权限/版本，只引用既有事实不重收；已撤权/换仓恢复拒绝；第N组失败所有客户及费用/Outbox/主单CAS全回滚；安排与Admin/PDA发车、改车/货竞争，发车一处失败全回滚；验证真实Mapper与唯一约束，不能仅靠Mock。 |
 | 组合GET与数组 | 一次GET共享本地只读快照，无单出库别名；过程中本地版本变化不拼接新旧组，Finance候选保留版本并POST复核；来源不全/候选失败明确表达；数组覆盖全客户目的地，业务GET不泄露原命令请求或凭它冒认当前操作者成功。 |
 | 签收 | 未出库不准首次签收；部分签收、异常/退回和签剩余不汇总完成；全部原实发正常签收自动汇总且完成时间取实际最后签收；签后另退不改原运输；重复保存和本地提醒不重复 Outbox/回访。 |
 | 并发汇总 | 两客户同时最后签收、签收与提醒原子提交、提交后通知丢失、消费前/汇总中进程中断、重复扫描/消费、汇总CAS或提醒确认失败；父与ack同事务回滚，未扫描新提醒不被误确认，有界重扫最终恢复；无签收子锁回父，跨多趟来源证明保持RC＋来源锁协议。 |
 | 取消与撤销 | 保留已拣禁止取消、未执行合法取消原状态/关联恢复、仅派送应收申请作废、其他费用保留；与发车竞争只允许一个合法结果；请求撤销不当作确认作废。 |
 复用/扩充现有测试：`DeliveryTransferServiceTest`、`DispatchDeliveryFeesTest`、`DispatchFeeCargoMapperTest`、`FleetBookingFreightTest`、`DeliveryExecutionGuardTest`、`DeliveryDocumentServiceTest`、`PlatformDispatchOutboundContractTest`、`MerchantDeliveryControllerTest`、`DeliverySourceEvidenceMapperTest`、`DeliverySourcePublicationPersistenceTest`、`SourceDeliveryCompletionConcurrencyTest`、`OverseasFeeCancellationPersistenceTest`。主流程的 `DispatchRepairWorkflowTest`、PDA/FleetTrip 直接测试由其唯一写者同步；新增整车安排持久化/竞争测试放本任务 `delivery/` 测试包，不与主流程测试并写。
 主流程可采用以下后端根命令，具体 Test 类以最终实际新增为准：
 ```powershell
 mvn -pl lastleg-service -am test-compile
 mvn -pl lastleg-service -am test '-Dtest=DeliveryTransferServiceTest,DispatchDeliveryFeesTest,DispatchFeeCargoMapperTest,FleetBookingFreightTest,DeliveryExecutionGuardTest,DeliveryDocumentServiceTest,PlatformDispatchOutboundContractTest,MerchantDeliveryControllerTest,DeliverySourceEvidenceMapperTest,DeliverySourcePublicationPersistenceTest,SourceDeliveryCompletionConcurrencyTest,OverseasFeeCancellationPersistenceTest' -Dsurefire.failIfNoSpecifiedTests=false
 mvn -pl lastleg-service -am test
 node --test scripts/gateway-route-contract.test.mjs
 node scripts/mapper-scan-contract.mjs
 ```
 新增端口/依赖边界后按服务指引执行 `node --test lastleg-service/scripts/analyze-lastleg-dependencies.test.mjs`，核对依赖基线，不登记临时循环豁免。总控同步 SQL 后运行 Schema/中文注释合同；Client、Admin、PDA 的直接调用和构建由其获权执行者完成。真实 HTTP、部署、SQL、人工页面/真机验收仍待各自单独授权及证据。
 ## 10 本轮交付与停止点
 首批实现已写入delivery域：DispatchDeliveryService实现实际DispatchDeliveryPort，DispatchDeliveryFees处理逐组报价/覆盖/发布，DeliveryCargoGroups与NormalDeliveryCompletionPolicy核对来源及正常签收。已复核总控14:36就绪的共享骨架，ArrangeDelivery按实际Long版本构造，缺失/负数拒绝、0合法。新安排事实/信号均有独立Mapper→Repository；DeliveryDocumentService触及的数据访问收进DeliveryDocumentRepository，签收经实际DispatchSignalPort入队、不回调父流程。
 Controller的整车POST已使用共享ArrangeDelivery并返回CommandResult，新增组合GET返回ArrangementPreview；原辅助GET共用组合服务和PreviewGroup。Merchant创建POST和merchantTransfer服务入口已删除，客户读取及签收资料下载保留。未改SQL/OpenAPI/权限/主流程/预约在途文件；未提交、部署、执行环境SQL/HTTP或跨对话发信，未执行Maven。
 已执行：Mapper扫描合同通过（10持久化模块、384 Mapper）；Gateway路由合同5/5通过；git diff --check无空白错误。Lastleg依赖合同12例中9过3失败，均指出工作区fleet/pickup三类对WarehouseTransferOrder的新依赖，超出本任务写权，未放宽基线。该结果绑定当次工作区快照，不替代后续集成复验。
 Java新增直接用例：DeliveryCargoGroupsTest、NormalDeliveryCompletionPolicyTest、DispatchDeliveryFeesTest、DispatchDeliveryServiceTest、DispatchDeliveryArrangementPersistenceTest、DeliveryFactsChangedPersistenceTest；另更新Merchant、资料、平台合同及来源持久化直接测试。全部尚未由Maven执行，不能声称编译或行为测试已通过。
 旧单客户平台转换内部实现、DeliveryFeeCoverageService及旧Transfer/FeeItem/TransferResult DTO已清除；原行为用例由新整车领域用例承接，其他出库及取消用例保留。取消已接共同父锁端口，触及的数据访问收进DeliveryCancellationRepository；全部子单锁后先锁来源、再费用，保留费用撤销ACK及原状态恢复，不放开已拣取消。
 联合收口事项：主流程DispatchExecutionPort实现、共同命令账本/阶段CAS/消费器；Context逐行实测重量/体积须为实际归属值、不能重复整托总量；主流程独占DispatchRepairWorkflowTest、FleetTripPersistenceTest手工fixture需注入新DispatchExecutionPort和DeliveryCancellationRepository，并补出库明细新来源字段。异常退回消费者须按新增不可变来源字段核对真实行；ExceptionOrderService超出本任务写权，交总控分配。真实转仓/换标及预约提供者的交集锁审查同样由总控分配唯一写者。共同SQL/OpenAPI/权限及真实跨客户竞争由总控集成、主后端串行验证。
 本稳定点提供本域代码及测试供主后端统一编译/运行；接口实现/结构及外部消费者尚未联合完成，不标整体验收通过。日历新增预约始终在本任务范围外。
 ## 11 给总控的精确结构、API与验证提案
 ### 11.1 SQL（仅提案，未写共享SQL、未执行）
 以下表/列与本轮Mapper完全一致。保留现有出库客户唯一键和派送客户目的地唯一键，不并加反序冗余索引；共同全局命令表由主流程提供。
 ```sql
 CREATE TABLE IF NOT EXISTS ll_dispatch_delivery_arrangement (
  id BIGINT NOT NULL COMMENT '安排事实内部主键',
  dispatch_order_id BIGINT NOT NULL COMMENT '唯一整车排车主单ID',
  dispatch_no VARCHAR(128) NOT NULL COMMENT '真实排车业务号',
  arrangement_key VARCHAR(128) NOT NULL COMMENT '本次唯一安排业务事实标识',
  business_hash CHAR(64) NOT NULL COMMENT '排除操作者及纯并发版本的安排业务摘要',
  cargo_hash CHAR(64) NOT NULL COMMENT '本车实际拣货来源摘要',
  loading_completion_hash CHAR(64) NOT NULL COMMENT '装车完成事实摘要',
  original_command_key VARCHAR(255) NOT NULL COMMENT '首次安排的全局请求键',
  original_operator_id VARCHAR(128) NOT NULL COMMENT '首次安排操作主体',
  result_json JSON NOT NULL COMMENT '全部客户出库及客户目的地派送不可变结果',
  cargo_json JSON NOT NULL COMMENT '逐客户逐拣货归属的不可变真实来源',
  created_at DATETIME(3) NOT NULL COMMENT '本次安排实际创建时间',
  PRIMARY KEY (id),
  UNIQUE KEY uk_dispatch_arrangement_dispatch (dispatch_order_id),
  UNIQUE KEY uk_dispatch_arrangement_key (arrangement_key),
  UNIQUE KEY uk_dispatch_arrangement_command (original_command_key)
 ) COMMENT='整车排车唯一派送安排事实';
 CREATE TABLE IF NOT EXISTS ll_delivery_facts_changed (
  id BIGINT NOT NULL COMMENT '持久信号内部主键',
  customer_id VARCHAR(128) NOT NULL COMMENT '真实签收货物客户ID',
  dispatch_id BIGINT NOT NULL COMMENT '整车排车主单ID',
  dispatch_no VARCHAR(128) NOT NULL COMMENT '真实排车业务号',
  delivery_id BIGINT NOT NULL COMMENT '本客户派送单ID',
  delivery_no VARCHAR(128) NOT NULL COMMENT '真实派送业务号',
  delivery_version BIGINT NOT NULL COMMENT '触发信号的真实派送版本',
  facts_hash CHAR(64) NOT NULL COMMENT '该版本真实签收事实摘要',
  occurred_at DATETIME(3) NOT NULL COMMENT '签收事实实际发生时间',
  state VARCHAR(16) NOT NULL DEFAULT 'PENDING' COMMENT '待核对PENDING或已核对PROCESSED',
  attempt_count INT NOT NULL DEFAULT 0 COMMENT '已记录的汇总失败次数',
  next_attempt_at DATETIME(3) NOT NULL COMMENT '下次可重试时间',
  last_error_code VARCHAR(64) NULL COMMENT '最近失败诊断码不保存敏感异常正文',
  processed_at DATETIME(3) NULL COMMENT '与主阶段汇总同事务确认时间',
  PRIMARY KEY (id),
  UNIQUE KEY uk_delivery_fact_version (customer_id,delivery_id,delivery_version),
  KEY idx_delivery_fact_due (state,next_attempt_at,id),
  KEY idx_delivery_fact_dispatch (dispatch_id,state,id)
 ) COMMENT='正常签收事实变化的本地持久待汇总信号';
 ALTER TABLE ll_outbound_pallet_item
  ADD COLUMN dispatch_item_id BIGINT NULL COMMENT '本次排车作业明细ID',
  ADD COLUMN source_attribution_id BIGINT NULL COMMENT '不可变PDA拣货归属ID',
  ADD COLUMN source_order_id BIGINT NULL COMMENT '本行真实来源尾程订单ID',
  ADD COLUMN source_inventory_position_id BIGINT NULL COMMENT '本行实际拣货库存仓位ID',
  ADD COLUMN source_return_receipt_id BIGINT NULL COMMENT '本行实际退回再派实收记录ID',
  ADD COLUMN source_return_carton_id BIGINT NULL COMMENT '本行实际退货换标来源箱ID',
  ADD UNIQUE KEY uk_outbound_source_attribution (customer_id,source_attribution_id);
 ```
 本轮不为开发存量设计迁移/回填或自动删重；总控在最新基线及统一结构脚本按列存在性集成，以上ALTER仅字段提案，不能直接当成可重复执行脚本。新来源字段在其他正式独立出库类型可空，排车来源按共享CargoLine逐行填真实值；同一真实归属不能在两次出库重复使用。主流程消费者必须先父锁，再普通读取事实，再阶段CAS及ack同事务；失败后调用DispatchSignalPort.failed独立短事务退避。due上限当前200，调用者使用1—200有界批量。
 ### 11.2 OpenAPI与权限
 - 新增GET `/api/platform/v1/last-leg/dispatches/{dispatchNo}/delivery-arrangement`：dispatch:list，ArrangementPreview及其共享嵌套记录；顶层recordVersion/stage为当前快照，arrangement为不可变原结果。
 - POST同前缀 `/{dispatchNo}/transfer-delivery`：dispatch:transfer-delivery，完整共享ArrangeDelivery请求；响应为DispatchContracts.CommandResult，result是ArrangementResult，replayed/alreadyArranged在外层，不保留单个outboundNo。
 - 两个既有辅助GET external-freight、fee-coverage当前返回 `List<PreviewGroup>`，复用组合查询；前端弹框仅用一次组合GET，不再拼两个快照。
 - 删除Merchant集合POST及其创建schema/权限资源；保留Merchant集合GET、单单GET及签收资料/下载。精确Client消费者见第8节，脚本由总控分配，不在本任务改动。
 - 统一Gateway已有Lastleg通配覆盖，上述源码路由合同已通过；运行时部署及共享OpenAPI仍待总控集成，不推定已可访问。
 - 服务AGENTS当前仍指向已删除的DeliveryFeeCoverageService；由总控在共享指引同步时改为DispatchDeliveryService/DispatchDeliveryFees及全局安排模型，并按整批指引门禁统一检查，本任务未并写AGENTS。
 ### 11.3 主后端串行运行包
 ```powershell
 mvn -pl lastleg-service -am test-compile
 mvn -pl lastleg-service -am test '-Dtest=DeliveryCargoGroupsTest,NormalDeliveryCompletionPolicyTest,DispatchDeliveryFeesTest,DispatchDeliveryServiceTest,DispatchDeliveryArrangementPersistenceTest,DeliveryFactsChangedPersistenceTest,DeliveryTransferServiceTest,DeliveryDocumentServiceTest,DeliverySourcePublicationPersistenceTest,MerchantDeliveryControllerTest,PlatformDispatchOutboundContractTest,DispatchFeeCargoMapperTest,FleetBookingFreightTest,SourceDeliveryCompletionConcurrencyTest,OverseasFeeCancellationPersistenceTest' -Dsurefire.failIfNoSpecifiedTests=false
 ```
 主流程旧直接fixture签名与共享OpenAPI完成后再运行本包及Lastleg全量；尤其Merchant OpenAPI测试当前明确要求旧POST/create权限已删除，不能用旧共享文件使测试放宽。旧来源证明并发用例、外接报价、费用撤销ACK与取消竞争沿第9节纳入最终回归。
 ### 11.4 本域稳定文件快照
 本轮固定delivery主源码和测试39个变更路径（37个现存文件、2个删除路径），不含本设计文档。统一编译反馈后，总控先解除`delivery/controller/MerchantDeliveryControllerTest.java`测试文件冻结，随后授权修正`delivery/PlatformDispatchOutboundContractTest.java`的当前Controller/DTO直接消费者；生产文件不变，测试类/路径集合不变。当前候选摘要采用**JavaScript `paths.sort((a,b) => a.localeCompare(b))`，不传locale/options参数**：
 `90b54852f18e5f1244aeee81313f99bee50cb5abf405e372718c322ad60427c2`
 此次测试文件SHA-256为`c45c68d01b54a67dab7f1fc7e3c55b4511530eb0aad716561ae84d6cda94dcb6`。派送列表/详情以及签收资料/下载均按精确路径块提取，到下一同级路径或根章节停止；保留禁止客户创建、Token客户隔离和签收资料只读的全部断言。新增一个相邻业务POST不误入、派送自身POST仍可检出的回归方法。未删除共享OpenAPI中的合法仓储转运和弃货POST。File三文件哈希与上一交付一致。
 `PlatformDispatchOutboundContractTest.java`当前SHA-256为`e59a2bb29d3122aeb93a5dc0618bad8831ca83b5621a5a07d8316dfb5475b619`。取消反射及直接调用使用`DispatchAggregateController.cancel(user,dispatchNo,DispatchCommands.ReasonCommand)`，校验`POST /{dispatchNo}/cancel`和请求体；更新反射及字段集合使用`DispatchCommands.Update`。保留各动作独立权限、无customerId参数、客户在业务查找前拒绝，客户取消按公共身份工厂的`BizException(FORBIDDEN)`核对且验证整车Service零交互。草稿切片中按总控反馈进一步将旧vehicleSize整份YAML字符串断言改为当前DispatchArrangeDelivery的公共版本、完整groups及分组身份/费用证据，并核对结果outbounds/deliveries两数组、禁止旧DeliveryTransfer schema；未改共同OpenAPI。取消修正时的中间候选90778a9b…由本候选取代。
 首版候选摘要`ab2a553af145d7a2c708f1b44d88eb2c349970d81295bbbe4504af5f55ed2f81`以及仅修正Merchant测试的中间候选`ef2d6bd5063f2aa9b030d68faef950582ac956e09a5ca349a615efc2f45ac130`均由当前候选取代。首版曾与Ordinal排序摘要`932c52c825613ae020ea60538a7cb8efa4941c905975b67644c7c926fae4bda1`有排序差异：小写controller子目录与大写Delivery文件的先后不同；该历史对照不代表当前测试输入。
 精确重算算法（在后端根由Node执行，只读文件；这里保留为候选输入定义，不是新增测试入口）：路径统一使用Git返回的正斜线相对路径；Set精确去重后按上述localeCompare排序；每行 `path + U+0020 + 小写文件SHA256`，删除路径后缀为DELETED；LF连接、末尾无换行；无BOM的UTF-8字节再做SHA-256。
 ```javascript
 const { execFileSync } = require('node:child_process');
 const { existsSync, readFileSync } = require('node:fs');
 const { createHash } = require('node:crypto');
 const scope = [
  'lastleg-service/src/main/java/com/baiyue/lastleg/delivery',
  'lastleg-service/src/test/java/com/baiyue/lastleg/delivery',
 ];
 const changed = execFileSync('git', ['diff', '--name-only', '--', ...scope], { encoding: 'utf8' });
 const untracked = execFileSync('git', ['ls-files', '--others', '--exclude-standard', '--', ...scope], { encoding: 'utf8' });
 const paths = [...new Set((changed + '\n' + untracked).split(/\r?\n/).filter(Boolean))]
  .sort((a, b) => a.localeCompare(b));
 const rows = paths.map(path => path + ' ' + (existsSync(path)
  ? createHash('sha256').update(readFileSync(path)).digest('hex') : 'DELETED'));
 console.log(createHash('sha256').update(rows.join('\n'), 'utf8').digest('hex'));
 ```
 当前测试类集合仍为第11.3节列出的15个测试类，编译反馈后只更新其中Merchant与Platform两份合同测试。精确路径离线提取检查和`git diff --check`通过；JUnit/Maven未运行，由主后端串行重跑`mvn -pl lastleg-service -am '-Dtest=MerchantDeliveryControllerTest,PlatformDispatchOutboundContractTest' '-Dsurefire.failIfNoSpecifiedTests=false' test`。本次未修改生产代码、SQL、OpenAPI或File文件。
 该快照只用于总控确定本次待统一编译/测试的候选，不是提交、构建通过或部署证据。主后端实际编译发现接口或用例问题时再修改并更新快照；当前本域文件继续固定，等待统一验证反馈。
 ### 12 有界草稿实现输入（2026-10-19）
 本任务新接管SmartDispatchController、DispatchDraft/Container及其Mapper，新增专用Draft Service/Repository、占用Mapper和持久命令记录及直接测试；共享port、AggregateService、DispatchSourceMapper、旧DispatchService、PDA/Fleet仍由原写者维护。公开请求/返回严格使用DispatchPlanningModels/Port及Admin现有dispatches.ts：GET/POST drafts、POST drafts/containers及snapshot、draft-locks lock/unlock/release、DELETE空container（ReasonCommand请求体）、POST drafts/pre-arrange；旧standalone pre-arrange不再注册。
 共享SQL由总控唯一同步，精确模型输入：`ll_dispatch_draft`增加`warehouse_id BIGINT NOT NULL`、`record_version BIGINT NOT NULL DEFAULT 0`、`sources_json LONGTEXT NOT NULL`（服务器解析的Candidate数组），保留operator_id、token唯一、plan_ids_json、status ACTIVE/RELEASED/CONVERTED及真实created/updated/expires/released时间；草稿头无客户语义。`ll_dispatch_draft_container`增加`source_keys_json LONGTEXT NOT NULL`，保留draft_id/token、sequence_no、capacity(15/30)、时间，唯一`(draft_id,sequence_no)`。新增`ll_dispatch_draft_command(id BIGINT PK,idempotency_key VARCHAR(128) NOT NULL UNIQUE,operator_id VARCHAR(64) NOT NULL,action VARCHAR(32) NOT NULL,target_token VARCHAR(128) NOT NULL,request_hash CHAR(64) NOT NULL,result_json LONGTEXT NULL,created_at DATETIME(3) NOT NULL)`；命令预占与结果同事务，绝不提交未完成命令，原键全载荷/主体/动作/原版本一致才恢复原结果。草稿占用复用`ll_dispatch_pallet_lock`，dispatch_order_id对草稿允许NULL，draft_token、draft_container_id、operator_id、expires_at必须填写，source/实托两个活动唯一键沿主流程现有规则；释放仅匹配本token/owner且dispatch_order_id IS NULL，不触碰已转换正式占用。
 写事务顺序为命令唯一行→本owner草稿根→容器普通读；选择时真实来源订单升序→来源托盘/收据→库存→活动占用。布局JSON只允许移动当前已锁来源，不新增来源资格；全布局必须精确覆盖原容器/来源集合，序号唯一，单仓，按物理实托去重计算capacity。移除只允许空容器。释放/取消选择在草稿根之后仅释放本占用，不反取资源父锁。
 转换先校验所有非空容器恰好一组、每组cargo精确等于该容器服务器选择及原sourceVersion、每组warehouse同草稿；再锁齐全批资源→全批来源→本草稿占用，释放草稿原键，逐组调用真实Aggregate.create（每组一张整车、不按客户/目的地拆），全部结果和草稿CONVERTED及命令结果同事务提交。任一失败回滚全部来源占用、主单/Fleet/历史/命令，不先提交部分组。
 需要主后端唯一写者接线的最小方法：①`DispatchService.lockDraftSources(String warehouseId,List<DispatchCommands.CargoSelection> selections): List<DispatchService.WholeSource>`，MANDATORY，沿现有lockWholeSources的真实身份/仓/订单/库存/版本核验，草稿选择允许换标申请逐托暂存，正式create继续要求完整申请；②`DispatchAggregateService.lockDraftCreationResources(Actor actor,List<DispatchCommands.Create> creates): void`，MANDATORY，一次按正式资源全局顺序锁齐所有新建车辆/司机及关联资源，不能在锁完一组来源后才去取下一组资源。新增草稿服务不会自行改这两个提供者。旧DispatchService草稿方法及旧DTO的最终清理由其唯一写者负责；本轮Controller不再调用旧客户拆单链。
 当前桥接已由主后端落地并接入。草稿头`customerId`已从本包实体移除，不恢复旧字段以维持编译；旧Service存量草稿方法已由主后端移除。`plan_ids_json`已由总控在两份共享SQL中改为LONGTEXT：公开筛选允许最多500个正数Long，JSON可能超过原VARCHAR(4000)。候选参数唯一为`destinationWarehouseCode`。按总控最终确认的正式权限口径，候选及草稿两个GET均为`platform:overseas-warehouse:dispatch:list`，八个草稿写入口均为`platform:overseas-warehouse:dispatch:create`；不保留旧入仓权限，不添加OR，不修改共享角色/IAM。
 容器序号交换在同一草稿根事务内先将原正序号变为负数，再写全部新正序号，避免`(draft_id,sequence_no)`的临时碰撞；失败与草稿命令一起回滚。直接测试使用真实MyBatis/H2/Spring事务代理验证命令恢复、拥有者/旧版本拒绝、真实共享唯一占用竞争、同版本并发、序号互换、布局不能新增来源、单仓/容量、退回/换标选择字段互斥，以及第二辆车失败使全批与原占用释放回滚。来源和整车提供者在边界隔离，生产端到端创建/来源资格仍由主后端集成测试验证，不用该夹具冒充完整联调通过。Maven仅由主后端执行。
 ### 12.1 草稿切片稳定输入
 草稿包精确13路径（10个生产文件、3个直接测试），当前修复候选聚合指纹`b0db1bb5191fa3578dacfa0f07c7c2a6a30346f0198047e34fc1fe3a99b0e554`，取代首轮`db84f7527d8ee88a5b893ed291081041c5a1461d7dbdafc66716014c575d3ac0`。按第11.4节同一localeCompare排序、path加空格加文件SHA256、LF连接无尾换行算法生成；不含设计文档、共享端口/桥接/SQL/OpenAPI，也不把原39路径并入草稿包。原39路径指纹保持第11.4节值；本批另仅修改原File包的DispatchEvidenceFileTest两处受检异常声明，File类别和独占契约未变。
 ```text
 lastleg-service/src/main/java/com/baiyue/lastleg/dispatch/controller/SmartDispatchController.java 63cf9f9644a8fb1b08cbbff66ef646943bba23950c5662232ae540bb470195fc
 lastleg-service/src/main/java/com/baiyue/lastleg/dispatch/entity/DispatchDraft.java 4f1509204cfff1a6993f75cfc7dd2ab62b8a56c3217c58e2e00326958db76a12
 lastleg-service/src/main/java/com/baiyue/lastleg/dispatch/entity/DispatchDraftCommand.java 38366ac363927ada62a25e1ea1cd3cb39bd76df10242e3fa5ff8dd4d3745c14f
 lastleg-service/src/main/java/com/baiyue/lastleg/dispatch/entity/DispatchDraftContainer.java deded482497de649ae66600f372c4ed2d9450f4cfe08da249feaacaa3008d619
 lastleg-service/src/main/java/com/baiyue/lastleg/dispatch/mapper/DispatchDraftClaimMapper.java f23aa194955b7058da25992e43ee786ce3cde0c3ba9025a9ae13440c36aafc66
 lastleg-service/src/main/java/com/baiyue/lastleg/dispatch/mapper/DispatchDraftCommandMapper.java e63f642901fbb0a0f1b3895e871c3c93539cea9b7928a86899073bee05a46920
 lastleg-service/src/main/java/com/baiyue/lastleg/dispatch/mapper/DispatchDraftContainerMapper.java 4a752ec506f3dbd7f86ad41b5f9fc1751b166e0b25f5d394b8d9c588e1b2c142
 lastleg-service/src/main/java/com/baiyue/lastleg/dispatch/mapper/DispatchDraftMapper.java 141df6769ed0c9399a59a550204998c8d0b0c23e935e108f96602d1729c319dd
 lastleg-service/src/main/java/com/baiyue/lastleg/dispatch/repository/DispatchDraftRepository.java 6ee39efc395352f43ce36003545956c917990e2f2913dd2be5ca7c19dea9675d
 lastleg-service/src/main/java/com/baiyue/lastleg/dispatch/service/DispatchDraftService.java 4a97ba8a592278ab635317a54f525268c51a7ac7f0ed04699085712e534af0c3
 lastleg-service/src/test/java/com/baiyue/lastleg/dispatch/controller/SmartDispatchControllerTest.java d577703bafa8cd51fd877c613b38c4bfcf16455a2cd4e8cb539b26f1bb418ef4
 lastleg-service/src/test/java/com/baiyue/lastleg/dispatch/service/DispatchDraftPersistenceTest.java d9ff50b04abddd54fba5c8c7528cb10c08dc7df8e3eecf43bc5172f7b20aeeec
 lastleg-service/src/test/java/com/baiyue/lastleg/dispatch/SmartDispatchOpenApiContractTest.java cab62da8a36e47f8f2c923f43429fa2565f242ac7e568f43640aff2f7b9404ea
 ```
 主后端报告首轮输入test-compile通过（1056生产/450测试），直接178项176通过、2失败，失败为本包路由权限反射和转换结果重启恢复；本任务未自行执行Maven。独立只读审查另确认等待来源锁跨到期的占用漏洞，纳入同一修复。当前三份草稿测试共17个用例（DispatchDraftPersistenceTest 10、SmartDispatchControllerTest 6、SmartDispatchOpenApiContractTest 1），修复后尚未重跑。Mapper扫描393项及原静态检查是首轮证据；本轮已完成差异检查、构造器直接消费者核对、两个GET/八个写入口精确权限静态核对。共同OpenAPI的草稿业务必填列表已由总控补齐，不再作为待处理项。
 请主后端在本输入上统一执行`mvn -pl lastleg-service -am -DskipTests test-compile`及`mvn -pl lastleg-service -am '-Dtest=DispatchDraftPersistenceTest,SmartDispatchControllerTest,SmartDispatchOpenApiContractTest,PlatformDispatchOutboundContractTest' '-Dsurefire.failIfNoSpecifiedTests=false' test`。本任务不启动Maven，不执行环境操作，不将静态核对写成编译、事务或并发通过。
 ### 12.2 首轮反馈修复范围
 本批仅解除13包中Controller、Service、Repository、ClaimMapper及两份直接测试的冻结，原派送生产/其他测试保持不变。权限测试先按真实HTTP映射筛选并核对仍为10个路由，再逐项校验精确权限字符串，不能跳过正式路由鉴权。转换恢复注入现有DispatchCommandCodec，对每个嵌套车辆结果按原action解码；仅外层批次标记replayed，子车的原版本/时间/Saved载荷不变，不执行create、不读取当前快照、不注册第三套多态协议。
 到期修复在阻塞来源/占用锁返回后重新核对原deadline，变更/转换最后写入后再次核对；续期后在锁内逐项核对选择集合、owner/token/容器/客户/实托和统一expiresAt，不能只延长草稿根。保留renew原拥有者、ACTIVE、尚未到期及未转换谓词，不复活过期行；更新行数与真实有效行集合联合核对，允许驱动对未改变值返回0，但不允许缺失/过期占用冒充成功。新增firstSelectionWaitingAcrossExpiryRollsBackSelectionClaimAndCommand：真实H2来源行锁、共享原子UTC测试时钟，从原到期前1ms跨至后1ms，要求失败无新选择/占用/命令且原版本不变，之后其他拥有者能唯一取得有效占用。该回归尚未运行。
 File七类验证此前被DispatchEvidenceFileTest受检IOException编译阻塞；本批仅为uploadsKeepPlatformDispatchScopeAndImmutableObjects与metadataAndDownloadEnforceEveryScopeKeyBeforeReading补throws Exception，未改变断言。该文件新SHA-256为`bba87946457fb1290960218127087552de95b59f443eb6d5dacf354084d04a19`；BusinessFileCategory仍`b274532a0e4a263c56558eae68eb5717182791dec8e399e21bd459f6dffd32ff`，dispatch-evidence-v1.yaml仍`b3bc23d9f25513b258f0282886743e4323cb65b89c0203d4d2921ac89da08d14`。File七类测试此前尚未执行，本轮仍交主后端唯一Maven窗口。
 ### 13 既有预约整车接线只读提案
 本节仅为总控决定唯一写者的提案。没有修改生产/测试/共享SQL/OpenAPI，没有运行Maven/HTTP，没有接管日历新增预约；草稿13路径与File包继续冻结。以下代码位置绑定本节末SHA快照，后续原写者继续改动的文件不是稳定实现承诺。
 #### 13.1 优先解除的真实编译与运行交集
 - FbaAppointmentExecutionAdapter.eligibility约87行仍调用TerminalEvidence.customerId()，当前FleetDispatchGateway.TerminalEvidence已只有dispatchNo/warehouseId/shippedPackages/deliveries，客户在TerminalDelivery与Outcome明细中。不能补回头客户或取首客户；按当前member.customerId过滤全部明细，再按destinationKey核齐本客户原实发/真实签收退回。read仍按旧DEPARTED判断是否读取证据，eligibility仍判断PENDING_DEPARTURE；应读取TransportRow的正交status/stage/主单recordVersion，保持现行执行资格，不给ACTIVE一个“待发车”别名。
 - FbaAppointmentExecutionAdapterTest.proof约60行仍用5参数TerminalEvidence，改为实际4参数并增加同车多客户明细。FbaAppointmentTransportAdapterTest约46行仍用7参数DispatchBinding（含已移除customerId），实际为6参数；Detail当前6参数并未过期，不应盲目改它。
 - FbaAppointmentTransportAdapter.apply约95/101/102行分别调用已移除的FleetTripService.unbindDispatch、FleetDispatchGateway.removeItem、FleetTripService.bindDispatch，直接测试的同名mock也已失效。不能恢复这些旧入口；原预约运输调整必须委托整车命令，不能自行解绑/重绑共享车次或更新数量表。原测试以A/B/C三张客户排车共用一车且头部存customer_id，须改为一张整车、真实明细客户、一个整车PDA任务；逐客户出库只在其真实阶段存在。
 - AppointmentWorkDispatchMapper.references/transportRows仍联接d.customer_id；InboundFbaAppointmentQueryMapper.countActiveDispatches约47行也一样。后者由InboundFbaAppointmentService.batchContext直接调用，故不只是分配引用，既有批次候选读取在无头客户的新基线上也会失败。
 - DispatchAggregateService.create/addCargo的requireBatchProvider以及addResolved的activeAppointments均是明确保护门禁。不能只删第一个门禁就宣称接通：旧bind(customer,...)在50/79行按dispatch_id删整车所有分配，循环A/B调用会互相覆盖；空分配加货也会因整车原有别的客户FBA分配被误拒绝。
 #### 13.2 最小分配Provider合同
 建议由原唯一写者替换旧按头客户bind，不加旧签名重载或兼容分支。复用原physical/pickedPhysical、AppointmentWorkPhysicalSources.canonical、真实batchContext与收货权威：
 ```java
 record PhysicalItem(Long itemId, String customerId, Long planPalletId,
                    String sourceStage, Integer packages) {}
 // MANDATORY；所有预期批次按既有统一字符串顺序一次锁齐、逐批核对当前版本。
 void lockBatches(Map<String, Long> expectedBatchVersions);
 // MANDATORY；仅替换touchedItems，Provider在DB核对它们属于该整车及真实明细客户。
 void bindItems(long dispatchId, List<PhysicalItem> touchedItems,
               List<Allocation> allocations);
 // 这两个整车读取/校验签名可保留。
 Map<Long, List<BatchReference>> references(List<Long> dispatchIds);
 void requireDeparture(String dispatchNo);
 ```
 PhysicalItem.customerId必须从已保存DispatchItem读取，不能从头部、请求customerId或Allocation反向推定。Allocation中的客户只作为必须匹配的断言。排车选择键PLAN:/RETURN:/RELABEL:也不能直接当预约逐票sourceKey；后者仍由真实订单规范化为BOOKING:/ORDER:，连同destinationKey核对。
 创建时touched为本车全部新明细；加货时仅为新明细。Provider先读整车原分配，形成effective=原未触及行+本次新增/替换行，再按(batch,customer,source,destination)校验“其他整车已分配+effective本车量”不超真实批次。不能沿用allocated(... exclude dispatch)+仅本次增量的公式遗漏本车原量。删除限定dispatch_id与touched item IDs；A原分配应保持原样，给B加无批次/客户仓货物不能清空或要求重填A。客户仓自动DISPATCH:引用继续原规则，不伪造FBA预约版本。
 版本是当前明确合同缺口：AppointmentWorkDispatchCandidates.Result已有version，但现Allocation、DispatchContracts.BatchAllocation和Admin DispatchBatchAllocation均不携带；当前sourceVersion摘要也不含预约版本，不能声称校验了用户选中时的原版本。若要满足该保证，最小补充是给两端Allocation增加嵌套recordVersion（明确指batchKey的权威版本，Long，0合法），并给候选BatchReference返回该版本；同批次多行版本必须一致，锁后比较真实FBA版本。该公共合同补充由总控/主后端与原前端写者统一决定和同步，不能本任务暗加字段。若不补，只能称“锁内当前权威核验”，原预览版本门禁不能宣告完成。
 Aggregate候选当前appointmentBatches为空；应由既有来源逐票关联批次的只读Provider补真实引用/版本，不让前端猜批次或拿显示约号造绑定。可在既有DispatchCandidates读能力上增加有界批量“真实客户+planPalletId→相关批次”内部查询，不新增预约创建接口。
 SQL最小修正：a→d按dispatch_id，a→i按dispatch_item_id+dispatch_order_id+真实customer_id；outbound按dispatch_id+a.customer_id，PDA按dispatch_id；transportRows增加d.stage与d.record_version。references/countActiveDispatches同样由明细证明客户。候选占用查询还应计入expires_at及全局实托占用，不能把已过期ACTIVE草稿永久判为占用，也不能遗漏RETURN/RELABEL别名对同一实托的占用。GET只筛选有效状态，不做清理写入。
 #### 13.3 原运输调整消费者的最小桥接，不恢复旧绑定流程
 ExecutionAdapter按TerminalDelivery.customerId与Outcome.customerId投影；completed必须来自本客户全部实发目的地的真实终态，不能用全车shippedPackages替代本客户数量，也不能用其他客户完成代替。批次范围版本摘要仍覆盖同批所有真实事实，不能因只选择客户B而漏掉A变化。
 TransportAdapter.inspect按真实整车stage/计数和批次客户投影，Vehicle行至少按(dispatchNo,batchKey,customerId)分组，不能取首行客户再合并全车量。apply保留完整实物选择/原数量/同事务scope一致性守卫，但把旧unbind/bind/removeItem换成原主流程拥有的窄内部整车命令。建议接口形状如下，仅供唯一写者实现/审定，不是新增公开API：
 ```java
 CommandResult applyExistingAppointmentChange(
    Actor actor, String dispatchNo, ReasonCommand identity,
    List<PhysicalItem> touchedItems,
    List<Allocation> expectedAllocations,
    List<Allocation> nextAllocations,
    boolean removePhysicalItems);
 ```
 其输入只能来自原批次与本事务lockAndInspect已核对的scope；主流程再核当前主版本、BEFORE_LOADING、零真实扫码、无下游执行、明细客户和原分配精确集合。移出只按已核齐完整item处理，不接受部分箱数猜实物；原绑定/来源/审核/版本/历史/资源投影与原预约改量同一事务。不得先删关联来绕过现有removeCargo保护。整车主单/资源关联保留当前统一规则，不能把“客户B退出”误作整车解绑/取消；所有明细退出也由当前空单/取消命令规则处理，不在Provider自动结案/释放资源。把父预约命令键透传为可验证的子命令身份，不能编造新随机键重做未知结果。为此FbaAppointmentTransportPort.apply及FbaReceivingService的直接调用需透传原idempotencyKey；沿用现有原命令账本，不新增第三套业务幂等协议。
 此桥接之前，原预约改量消费者应显式保持未接通/不可执行，不恢复旧Fleet方法追求编译或放宽守卫；同样不能把只读/绑定修复当作该写链已完成。
 #### 13.4 统一锁序与已确认反序
 建议统一为：全范围trip父记录→全部车辆/司机/资源（同域稳定顺序）→全部dispatch→全部客户outbound→全部delivery（需要时）→全部既有预约批次（现有batchKey字符串排序）→来源自身既有申请/订单/实托/库存/占用稳定顺序→收货组等业务行→工作协调guard；命令键唯一记录沿各域原事务协议。锁后复读真实集合与版本，范围新增则拒绝并重试完整范围。
 已有发车DispatchDepartureService约44行先requireDispatchDeparture取批次锁，46行才锁来源订单；原FBA分批/收货改量同样先batch后resolveForWrite的ll_order锁。若在Aggregate.addResolved取来源后直接补旧bind，将形成“源→批次”对“批次→同一源”的确定反序。可复现场景为一事务加同来源另一托，另一事务持原批次分批/发车后等待该来源。修法是Aggregate.create/add在来源之前预锁“原未变分配+本次请求”的全部批次；草稿转换已在调用create前锁来源，因此主后端lockDraftCreationResources必须在返回草稿域前就预锁全批groups的预约，不能只在后面的create补锁。不改冻结草稿服务来循环取另一批次锁。
 FbaTransport.lockAndInspect目前只先锁trip、再dispatch，没有完整车辆/司机资源预锁；需复用主流程有界“全范围根/资源锁”入口，不循环单车方法形成trip1→resource1→trip2。当前DispatchFleetAdapter.completion已是dispatch→全部outbound→全部delivery，不能继续引用旧实现推断其仍反向取父锁。
 协调锁方面，changes.requirementsChanged会UPDATE单行guard；FbaReceiving.resolve约115行seedFollowup经store.lock先拿guard，121行才transport.apply，后续可能继续取业务锁。应先收齐原运输/批次/来源/收货行与主流程变更，再做继承/失效协调写；不能把guard搬到整条业务入口后再取得父级/来源。当前guard-first同步/事项读取的直接查询未发现相反FOR UPDATE链，但这不是全域无死锁证据；新增接线必须做两会话锁竞争验证。
 发车仍复用requireDeparture整车签名：批次锁内对每个实际(batch,customer)重读pending、ACTIVE agreement、SUCCESS及真实预约时间、唯一成员、source+destination覆盖/数量和替代批次状态，再核真实pickedPhysical。按(customer,item,pallet)核物理量，不能因某客户成功就放行另一个客户。发车核对当前权威，不机械冻结为初次绑定版本；后续真实收货确认可以产生新版本，结构/数量变化则按真实核对结果阻断。
 #### 13.5 精确写入候选与直接回归（均待授权/未执行）
 原预约消费者必需文件：AppointmentWorkDispatchPort、inboundplan/work下DispatchBinding/DispatchMapper/DispatchCandidates、InboundFbaAppointmentQueryMapper、FbaAppointmentExecutionAdapter/TransportAdapter及它们两份直接测试。主流程接线由其唯一写者处理DispatchAggregateService、必要的DispatchReadMapper/共享BatchAllocation与BatchReference，以及上述内部整车变更端口/实现；发车现有FleetTripExecutionService.requireDispatchDeparture入口可复用，不另建发车接口。原改量桥接才触及FbaAppointmentTransportPort、FbaReceivingService（父命令身份/协调顺序）。公共字段同步涉及原Admin dispatchContracts.ts、主后端共享port及总控OpenAPI；不能由本只读任务抢写。
 车辆预约：当前只定位到旧DispatchOrder.vehicleAppointmentStatus/旧请求手填状态、新AppointmentReference(referenceNo,recordVersion)、DispatchInfo空投影及Aggregate.update显式拒绝；Lastleg实际业务入口/直接调用中未定位到可验证的独立车辆预约权威记录。不能用FBA批次、外接FleetBooking或旧手填状态代替。接线所需最小契约为“verifyExisting(AppointmentReference requested, Context dispatch)→原权威referenceNo/recordVersion/status/appointmentAt及可核归属”；如为远程仅能声明版本快照，不能声称跨服务原子锁。原提供者未明确前保持该门禁；持久关联位置、详情版本与审核/发车复验也需随真实提供者明确，不能只删reject然后丢弃请求。本批排除任何新的车辆预约权威表、创建API、日历新建/表单和新的预约业务流程。既有FBA收货确认/改量及其已存在后送批次属于原预约消费者，不等于本轮新增预约。
 建议直接回归：①无头customer的新基线能读batchContext/references/transportRows，fixture一车多客户一PDA；②加B保留A原分配逐行不变，含A已有FBA而B无FBA/客户仓；③effective含本车原量，跨车/同车超分配均拒绝；④批次原版本0合法、缺失/混版本/替代/旧预览拒绝；⑤A已确认B未确认或pending必须挡车，B补齐后核全部真实拣货/数量，不能用头部SUCCESS；⑥同车A完成不伪造B完成，终态读使用四字段TerminalEvidence明细，未发车保持真实阻断；⑦B退出保留同车A/C与主单编号，不调用旧bind/unbind，部分110不能匹配实物时全部回滚；⑧加货/发车/原预约分批/收货确认两会话按批次→来源锁序竞争，资源与guard不能反向；⑨父命令/主版本/后续写失败时主单、原分配、来源占用、审核/历史与原批次改量全回滚，未知结果只恢复原账本。以上仅清单，没有执行。
 本次读取SHA-256（源码随原写者继续变动时须重核）：
 ```text
 lastleg-service/src/main/java/com/baiyue/lastleg/appointmentwork/AppointmentWorkDispatchPort.java 45d1b7bdcb675cc6ef2f0020eac1651dd778538296913cf8d517380157ca954a
 lastleg-service/src/main/java/com/baiyue/lastleg/inboundplan/work/AppointmentWorkDispatchBinding.java 26db8a78d747d4cf25204255bbc5c2fdcde9efc0adebaea35dadec872d684e64
 lastleg-service/src/main/java/com/baiyue/lastleg/inboundplan/work/AppointmentWorkDispatchMapper.java 856a0fa618ecb143b6591cfd2ccde982c161b36181c4dc5bdf177973dd0f3351
 lastleg-service/src/main/java/com/baiyue/lastleg/inboundplan/work/AppointmentWorkDispatchCandidates.java bbd2bbdcaab8b418ef0f4732e44b765da7f9bc919c6492bc770e6ba7fc4c8c9a
 lastleg-service/src/main/java/com/baiyue/lastleg/inboundplan/work/FbaAppointmentExecutionAdapter.java fc7be6a167dd279d02b0055f8425703343eb763f2beabfd43de21ced6fa0b245
 lastleg-service/src/main/java/com/baiyue/lastleg/inboundplan/work/FbaAppointmentTransportAdapter.java e07c8049206927fe47b24734ac071f80ca3000174891053dcd86967f5376484b
 lastleg-service/src/main/java/com/baiyue/lastleg/inboundplan/mapper/InboundFbaAppointmentQueryMapper.java ca61cb28603aa8a922bec4b3f8caab39fb29d6eb818fdf151e34856a378b5980
 lastleg-service/src/main/java/com/baiyue/lastleg/dispatch/service/DispatchAggregateService.java 4dae88abe91fd872c0d0441d0ffa9f10574623bb4effdfaa9c3031cfa5d5d93b
 lastleg-service/src/main/java/com/baiyue/lastleg/dispatch/service/DispatchDepartureService.java 3123fe0e2beb47caa30c8ecc262efc084b42fd96c1f04eb7e08ca7f54a0c0878
 lastleg-service/src/main/java/com/baiyue/lastleg/fleet/trip/FleetDispatchGateway.java c71831f0af4330622a30a7f304b8ceeda91e58f982f27a5542f4d23bf64677e9
 lastleg-service/src/main/java/com/baiyue/lastleg/fleet/trip/FleetTripModels.java d3419d0cb473b9cd688d8eab2bced47fcc4b073dfb23c30ac930948c09dbdaeb
 lastleg-service/src/main/java/com/baiyue/lastleg/fleet/trip/FleetTripService.java 703f2a844486b484396db68f694b1c441901fec54ad66a7b9a66bef41e9ab91b
 lastleg-service/src/test/java/com/baiyue/lastleg/inboundplan/work/FbaAppointmentTransportAdapterTest.java 86a0e46ef135db7b9a89b9f33d33d62c61b28b77547f058a477bfb2ea504dda6
 lastleg-service/src/test/java/com/baiyue/lastleg/inboundplan/work/FbaAppointmentExecutionAdapterTest.java 736901b404d085447f676a5cd049a225d998519d5358ee30c506d9bc42a0d14e
 lastleg-service/src/main/java/com/baiyue/lastleg/inboundplan/service/InboundFbaAppointmentService.java e917cced0f40b7475bb3310754a4b3dc37bc26117f6c99f697d6db3b5941ddb0
 lastleg-service/src/main/java/com/baiyue/lastleg/inboundplan/receiving/FbaReceivingService.java 34f4ae02c448d0abcdef0b37c163ea7214b35c92819367c995436eda7d35635d
 ```
 #### 13.6 总控可审批的两层范围（只读，不代表获权）
 编译最小包精确四文件：inboundplan/work/FbaAppointmentExecutionAdapter.java、FbaAppointmentTransportAdapter.java，以及test/java对应FbaAppointmentExecutionAdapterTest.java、FbaAppointmentTransportAdapterTest.java。前者用当前四字段TerminalEvidence的明细客户，不恢复customerId getter；后者删除三处不可编译旧调用及对应mock。若整车变更桥接尚未实施，apply应明确保持未接通并拒绝写入，保留scope/版本/执行守卫，不让测试模拟旧写成功；不能补回旧bind/unbind/removeItem追绿。测试按当前TerminalEvidence四参数、DispatchBinding六参数，并淘汰头客户/旧主状态夹具。该包只能证明编译和失败关闭，不能宣告原预约改量业务恢复。
 完整接线包在上述四文件外，核心必须圈定AppointmentWorkDispatchPort、AppointmentWorkDispatchBinding、AppointmentWorkDispatchMapper、AppointmentWorkDispatchCandidates、InboundFbaAppointmentQueryMapper、DispatchAggregateService；如实施既有改量写链，再圈定FbaAppointmentTransportPort、FbaReceivingService及主后端内部整车变更端口/实现。建议新增的有界父锁方法为void lockExistingAppointmentDispatches(Actor actor,List<String> dispatchNos)，同事务一次锁全范围trip/车辆司机资源/dispatch，不能逐车交错获取。其后适配器读原Mapper复核完整scope，才取批次和来源。applyExistingAppointmentChange中的removePhysicalItems只能由已核齐原scope的服务端决定，不能新增为用户可随意选择的公开字段；expected/nextAllocations必须来自原权威与本次真实核心改量结果，不以删除关联绕过守卫。
 严格原批次版本若采用13.2的Allocation.recordVersion补充，须另外精确圈定dispatch/port/DispatchContracts.java、DispatchReadMapper、FleetTripService等已知直接BatchReference构造者、原Admin dispatchContracts.ts及总控OpenAPI；不因此授予目录级扩写。候选/绑定/发车只消费原预约，不新增预约权威表、日历表单或创建API。车辆预约权威当前未定位，列为外部契约依赖，保持门禁；停止扩大搜索，不为填空自建Provider/表。
 总控另转交ExceptionOrderService.java约548行dispatchPdaTasks.findByDispatch(customerId,dispatchId)属于独立旧PDA消费者，待总控协调原唯一写者；未纳入本只读包写权、未读取或修改该文件。
 ## 14. 第13节既有预约接线实施包（2026-10-19）
 本轮授权后实际实现包为下列19个后端路径；主流程公共合同、Aggregate桥接和锁实现由主后端独占，根接走的旧查询3+1不在本包。File冻结；草稿仅解除DispatchDraftService候选/视图及其直接测试，生命周期、命令重放、到期修正保持。此处仅是实施交接，编译和回归仍由唯一Maven执行者确认，不将新增测试或静态检查记为通过结果。
 - 原Provider：`Allocation(planPalletId,batchKey,Long recordVersion,customerId,sourceKey,destinationKey,packageCount)`；`PhysicalItem(itemId,customerId,planPalletId,sourceStage,packages)`；`BatchReference(batchKey,batchNo,Long recordVersion,customerId,sources)`。版本显式必填，零合法；移除旧bind/requireReplay。批次预锁固定String键排序，一次锁齐，事务后续只能复用已经声明的集合。
 - 候选实际入口：`Map<CandidatePhysical,CandidateBatches> candidateBatches(List<CandidatePhysical>)`；`CandidatePhysical(String customerId,Long planPalletId)`；`CandidateBatches(List<BatchReference> appointmentBatches,List<String> blockReasons,boolean occupied)`。最多1000个输入，整页两次本地SQL，来源去重后遵守原100票边界分块规范化；不逐候选循环batchContext。真实客户/计划托盘、BOOKING/ORDER、批次版本、目的地、跨车原分配余量与全来源有效实托占用共同决定结果。sources.packageCount由本托逐票实物和该批余量共同限定，零余量不伪装成可选项；缺失/陈旧归属返回阻断。occupied含本草稿自身，调用方仍按真实草稿身份核占用，不能直接阻断自己的已选来源。
 - 增量绑定：逐项重查真实DispatchItem客户、托盘、阶段和数量；保留未触及实物，将保留行与新行共同计入本车批次余量。只按明确item删除，不再整车清空。发车按真实客户/item/pallet分组，重新检查当前收货确认、替代批次和实际逐票拣货。
 - 原运输：消费实际DispatchAppointmentAmendmentPort。锁定方法增加真实operator；apply增加parentCommandKey。expectedAllocations只含touched原分配，next为空、removePhysicalItems=true表示完整实物移出本车；主流程派生稳定子键。没有恢复旧Fleet bind/unbind/remove别名，不凭某客户退出解绑整车。
 - 执行判断：当前ACTIVE/BEFORE_LOADING等真实阶段，TerminalEvidence使用四参数结构；客户身份取TerminalDelivery/Outcome，整车发运总数不能替代客户完成量。
 - guard：跟进seed移至批次、来源、运输和收货组全部写完后；Provider失效标记在同一原事务beforeCommit统一写入，避免逐item移货时先拿guard、再释放后续来源。失效失败仍使原事务回滚，无异步补偿或第三套账本。
 - 草稿：整页批读当前预约投影，显式映射公共DTO末尾recordVersion；不推进草稿版本，不改来源摘要、占用和转换逻辑；同键重试仍恢复原命令结果，当前GET允许反映最新预约版本。
 新增/调整直接回归覆盖同车280箱（101=80、202=100+60、303=40）、B退出剩120、完整60移出剩220、无法完整匹配110拒绝、后续失败整体回滚、同车其他客户/同客户其他实物保留、跨车并发批次余量、伪客户/版本缺失或过期、真实BOOKING来源、有界候选批读、过期草稿及RETURN/RELABEL同实托占用、草稿投影刷新与原键结果不变。原批次/来源或主流程边界被测试替身隔离的用例不等于这些生产者自身集成验收。
 本轮仅执行静态直接引用核对、无BOM/尾随空白核对和git diff --check，均通过；未运行Maven、javac、HTTP、SQL环境或部署。建议唯一执行者直接运行：
 ```powershell
 mvn -pl lastleg-service -am '-Dtest=AppointmentWorkDispatchBindingTest,AppointmentWorkDispatchPersistenceTest,FbaAppointmentExecutionAdapterTest,FbaAppointmentTransportAdapterTest,AppointmentWorkPreArrangementPersistenceTest,FbaAppointmentPersistenceTest,FbaReceivingPersistenceTest,DispatchDraftPersistenceTest' '-Dsurefire.failIfNoSpecifiedTests=false' test
 ```
 车辆预约未定位权威提供者，现有拒绝门禁保持；未新增预约权威表、预约创建API或日历表单/面板。
 19路径聚合SHA256：`a1ebcebf57812efcab400b49f8681f596941e0a3864ea2f48d937991d604fdd7`。按JS默认localeCompare排序，使用`path + 空格 + 小写SHA256`以LF连接，末尾无换行、UTF-8无BOM：
 ```text
 lastleg-service/src/main/java/com/baiyue/lastleg/appointmentwork/AppointmentWorkDispatchPort.java 33f2ec5f8a19eaa814a9f618dc7e91908dfb609174912a98224fb89be47cd653
 lastleg-service/src/main/java/com/baiyue/lastleg/dispatch/service/DispatchDraftService.java 0330fe2f78484a0a744b4d5fbdb5471dd1ad1fbe5360af190040377419114d46
 lastleg-service/src/main/java/com/baiyue/lastleg/inboundplan/mapper/InboundFbaAppointmentQueryMapper.java 018193279a361234401dee825d255e2c72e557b08a0fd4edb5a1c58cdf38e280
 lastleg-service/src/main/java/com/baiyue/lastleg/inboundplan/receiving/FbaAppointmentExecutionPort.java 64b0dab0e5a8ad74dc2b1412cd2d628b9f7f5850da72c121bb265e654b288efd
 lastleg-service/src/main/java/com/baiyue/lastleg/inboundplan/receiving/FbaAppointmentTransportPort.java c9cba7c2688fc0621d127b83ba0dca1693201bdff711f962e2eddc34a30b8083
 lastleg-service/src/main/java/com/baiyue/lastleg/inboundplan/receiving/FbaReceivingService.java 17cba0f20cb3ff2c13c8c6ad9cd38843e05aab8954f885a1e08685f36b541310
 lastleg-service/src/main/java/com/baiyue/lastleg/inboundplan/work/AppointmentWorkDispatchBinding.java a9b6c9004960f9ad0b763b156a68dc4ca59f9cbdc2646fe612a6d7a9f78be3a1
 lastleg-service/src/main/java/com/baiyue/lastleg/inboundplan/work/AppointmentWorkDispatchCandidates.java b43ced699717dfd8eafb429e67b95109d0b5189281ec37902cc70c318f1e84bc
 lastleg-service/src/main/java/com/baiyue/lastleg/inboundplan/work/AppointmentWorkDispatchMapper.java 1d0dc2a6d27eead02730fbe90263dc78435dfc258f1760e65cd5e6263375d015
 lastleg-service/src/main/java/com/baiyue/lastleg/inboundplan/work/FbaAppointmentExecutionAdapter.java eb7b3069c8557043d573cfaa96eec068047bda93a1701f9e4f0886ab7372fd43
 lastleg-service/src/main/java/com/baiyue/lastleg/inboundplan/work/FbaAppointmentTransportAdapter.java 4124e454ea63d6803cf1d82f5376a009806088ce8213f2d736759edf369f2c9c
 lastleg-service/src/test/java/com/baiyue/lastleg/dispatch/service/DispatchDraftPersistenceTest.java 846aa50bb8af260a16f806cb92686f155bf5c81d2dc607f94216965e66220e96
 lastleg-service/src/test/java/com/baiyue/lastleg/inboundplan/service/AppointmentWorkPreArrangementPersistenceTest.java 8300008cda492a6be58542e1ec5e22409ebb2b22caec315b797a2c5dd83643a2
 lastleg-service/src/test/java/com/baiyue/lastleg/inboundplan/service/FbaAppointmentPersistenceTest.java dd31a3bad09797cc4c60cdaa199978deb1f217608b98590ecc823cfc932d0596
 lastleg-service/src/test/java/com/baiyue/lastleg/inboundplan/service/FbaReceivingPersistenceTest.java 0b33acb5ad56882f11746909167178d4e802c4d9e4d1885cd6f0ff35414836ed
 lastleg-service/src/test/java/com/baiyue/lastleg/inboundplan/work/AppointmentWorkDispatchBindingTest.java df2b0e6a7f86f2678ae8c857a20016e1ce9a7ed2adf6870571e0577974212e61
 lastleg-service/src/test/java/com/baiyue/lastleg/inboundplan/work/AppointmentWorkDispatchPersistenceTest.java 06b3fb5da55e373f874e6f700a699f60f5edd1c8d1a33498be2da3e154853f27
 lastleg-service/src/test/java/com/baiyue/lastleg/inboundplan/work/FbaAppointmentExecutionAdapterTest.java 076198846409ee929853807d3e822c9cbf106bf26fb09a69def7bbe2d715774f
 lastleg-service/src/test/java/com/baiyue/lastleg/inboundplan/work/FbaAppointmentTransportAdapterTest.java f84644e00665b1579d960ae9a6378490b1f325f862c6beccbbef9291f5b7d533
 ```
@@ -0,0 +1,159 @@
 # 排车列表统一作业改造契约
 本契约规定排车列表五阶段、整车与客户货物归属、派送安排及 Admin 和海外 PDA 的共同目标。2026-10-19 用户确认一张排车单代表一趟车，并指定当前对话为本批总控；经逐项问答确定本契约的业务和界面基线，再下发三个任务做技术准备，共同接口冻结后才解锁生产代码实现。本契约描述目标及实施边界，不表示代码、部署或真实验收已完成；部署与真实验收事实仍维护在两份环境主契约。
 本批规则优先于旧车次独立列表及多张客户排车关联共享车次的交互说明。旧缺陷修复规划仅用于核对已修复行为，不覆盖本批目标。
 ## 一 用户已确认的业务目标
 1. 排车列表一次覆盖装车前、装车中、装车后、派送中、派送完成五个阶段。
 2. 一张排车单就是一趟车，允许同车多个客户、多个目的仓；各票货物、库存、单据和费用必须保留真实客户归属。
 3. 装车前包含车辆信息、调度审核、理货员审核；维护车辆信息后提交调度审核，再经理货员审核进入装车中。
 4. 装车完成与实际发车是两个动作，均允许后台和 PDA 确认；两端使用相同服务端规则、版本和防重复约束。
 5. 装车完成进入装车后；后台在装车后、实际发车前办理安排派送，核对派送信息及各客户费用，按客户和目的仓拆分派送单。派送安排完成后才允许后台或 PDA 确认发车。
 6. 实际发车进入派送中；全部正常派送签收完成后自动汇总派送完成。拒收、退回等作为异常，先线下人工处理，不自动视为正常签收完成，不在本批新建线上异常闭环或伪造库存恢复、签收、账务结果。
 7. 本批聚焦排车列表、详情、直接关联操作及必要生产者和消费者。车辆列表、司机管理、自有业务、外配业务、出车记录的整页改造后续逐页处理。
 8. 同时支持先选同一起运仓的可排货物/托盘再生成排车单，以及先创建空排车单再添加货物；空单不能伪造货物、拣货、装车或发车事实。
 9. 车辆和司机既可从已有档案选择，也允许临时填写外配车辆和司机；临时填写不伪造车辆或司机档案关联，不自行创建主档。
 10. 后台确认装车完成必须以PDA真实拣货核平为前提。后台不提供替代PDA的拣货数量补录来绕过此条件；PDA和后台均可确认装车完成及实际发车的既有确认保持。
 11. 用户随后澄清本次“新增预约”是预约日历的功能需求，先与本批排车改造分开整理。本批不新增日历预约创建或独立约车流程；排车已有FBA预约、车辆预约字段及权威关联继续保留。此前确认的先保存后关联意见保留为日历需求输入，不作为本批扩大实现范围的授权。
 ## 二 原型依据与详情四块
 原型为用户提供的新版 HTML，页面 `page-outbound-vehicle`、`page-outbound-vehicle-detail`，以及本轮最新排车详情截图。HTML 位于用户提供的本机原型路径，实施者沿本契约和目标模块矩阵定向读取，不扫描原型其他模块。截图最新确认优先于前一条“三块”的描述。
 排车详情继续使用独立页面、页头排车单号、状态和返回入口。用户在最新确认中明确将下列四块分别作为四个彩色图标页签，样式沿用现有后台横向页签；此确认取代此前同页四分区的布局描述。原型灰色卡片仅保留业务字段依据，具体字号、密度、底色、边线与页签使用现有公共规范。不新增路线或操作记录页签：
 | 分区 | 截图字段或列 | 布局 |
 | --- | --- | --- |
 | 车辆信息 | 车牌号、司机、联系电话、拖车公司名称、车辆状态 | 第一个彩色图标页签；紧凑字段布局 |
 | 排车信息 | 路线、发车时间、预计到达时间、FBA预约、车辆预约 | 第二个彩色图标页签；紧凑字段布局 |
 | 单据信息 | 排车单号、关联派送单、创建时间、更新时间、备注 | 第三个彩色图标页签；多单号完整展示 |
 | 关联订单明细 | 订单号、重量kg、托数、目的FBA仓、体积m³、集装箱号 | 第四个彩色图标页签；通栏只读表格 |
 页签复用当前详情的 `density-element-tabs`、`density-tab-icon` 及公共密度令牌，保留图标、激活底色、下划线、字号和间距的一致规则；页面不另写第二套页签样式。图标优先从现有对应语义复用，具体映射在逐操作矩阵中列明。新增、编辑和审核等操作按新版原型对应弹框分别核对，详情四页签不授权改变弹框承载方式。
 原型示例编号、路线示例、日期和数量仅作为样式及字段参考，不写入真实数据或作为缺失值回退。长编号和多派送单不能省略成内部ID；缺失显示“—”。样式沿现行高密度规范，保持上述业务分组。真实视觉验收由用户在1920×1080、100%缩放下提供截图。
 ## 三 现有附加能力的保留边界
 用户明确要求外接预订、计划容量、直接成本、在途交接、车辆和司机任务结束等能力先保留，后续再接入。本批不删除这些能力及实现，不把它们新增为排车详情分区或页签，不扩展为全面车队产品改版。
 排车主流程不再要求用户先进入独立车次管理建立或关联车次。车辆管理侧栏中的“车次管理”通过hidden退出菜单，日常作业从“排车列表”进入；原车次详情路由与外接预订、容量、成本、交接、资源结束等附加代码先保留。“出车记录”是实际发车后的运营查询入口，继续保留，不与独立车次管理一起移除。既有容量、资源占用、司机证照和客户隔离等必要服务端校验须随主流程保留。技术模型收敛方案由后端提出，总控核对并冻结后实施；不能仅改页面名称而继续要求用户执行旧的多单关联流程，也不能因暂不展示资源任务结束而自动释放车辆或司机。
 原附加能力的直接引用若与新主流程冲突，先列明精确调用点，由总控裁定最小接线；不自行删除旧附加能力或重做其他整页。
 ### 下发基线与问题处理
 上述三项新增规则已经由用户逐项确认，准备任务按确认结果提出技术设计。原型未定义或代码与已确认规则冲突时，执行者列出具体场景、当前行为和最小建议交总控处理，不自行添加业务限制、删除能力或改变用户操作。
 所有任务以本契约、目标模块指引、用户新版原型和最新详情/样式截图为共同输入；不把旧车次交互、历史缺陷修复终点或演示值改写成本批规则。
 ## 四 实施任务与唯一写者
 所属项目为测试环境 `c64729ff-6710-43c6-8ef2-d84e9666cc1e`，host为local，工作区为 `C:/Users/BY-OY/Desktop/code/chongchong-global`。全部任务留在当前工作区和分支；不创建worktree、分支、项目副本或复制依赖。
 总控为当前对话 `01a15230-a9d6-7503-a8a9-d70691df49e5`。旧排车对话已归档、派工未送达；用户随后明确新建三个独立任务。依后端工作量采用两个后端和一个Admin/PDA联合前端任务。技术准备和两后端交接点修订已经完成；本轮按第九节分阶段解锁，未解锁的预约在途文件及额外提供者仍保持只读。新批次不继承上一批发布、SQL或环境验收授权。
 | 对话与task_id | 本批唯一职责 | 文件写入边界 |
 | --- | --- | --- |
 | 排车后端 `01a1524f-4f11-70c2-8a46-8e06e73a2d86` | 排车主单与货物客户归属、建单/加货、五阶段、审核、装车/发车共同执行规则；后端Maven唯一执行者 | Lastleg `dispatch/`、`fleet/trip/`及实际直接引用的Repository、Mapper、DTO与测试，`FleetBookingFreight.java`除外；不写`delivery/`及`financefee/`。后端共同接口设计文档由本任务唯一维护；File等提供者先列触点由总控分配 |
 | 排车派送与费用后端 `01a1524f-56a9-7320-a5fd-8ff76fa4356b` | 装车后安排派送、按客户和目的仓拆单、费用归属/覆盖/发布及正常签收汇总事实 | Lastleg `delivery/`、必要`financefee/`、`fleet/trip/FleetBookingFreight.java`及对应测试；不写`DispatchService`、排车DTO/Mapper、`FleetTripExecutionService`。先在独占设计文件提出给主流程的事实查询与事务约定 |
 | 排车前端与PDA `01a1524f-52c7-7cc3-9b08-d34ad24c172a` | Admin排车列表、四页签详情、直接弹框、API/类型、PDA装车/发车及直接测试 | Admin `overseas-warehouse`排车页面/API/类型/直接组件、`overseas-master-data`经核实的直接触点；海外PDA `src/pages/dispatch/`、`src/api/fulfillment.js`、`src/stores/fulfillment.js`及直接测试/组件。预约日历在途文件先只读列明接线，不覆盖；不写Java |
 | 当前总控 | 业务范围、共同契约、任务协调、共享文件及集成检查 | 本契约、协作登记、必要索引；最终共享导航/根路由/权限/统一SQL/Gateway接线；修改前核对相关文件现有写者 |
 任何任务不递归委派、不新建对话、不跨项目操作、不覆盖其他未提交修改。执行者在自身对话报告，由总控读取；收到派工不自动获得向其他对话发消息的授权。两个后端不并写同一Java类、DTO或Mapper；共同OpenAPI、权限及SQL由总控按各自提案集成。
 ## 五 就绪顺序与交付要求
 1. 主流程后端提供共同接口和数据设计：整车编号与明细客户归属、五阶段及异常事实、每阶段可操作资格、审核/装车/发车请求、版本/幂等、历史与权限、结构变更及直接消费者。派送后端并行提出按客户目的仓拆单、费用与签收事实接口；两者先对齐主单/明细、动作资格、完成事实、事务边界与锁顺序。API路径和模型未冻结前，不让下游按猜测实现。
 2. 前端任务同步完成Admin逐操作原型矩阵、字段缺口，以及PDA真实拣货、装车完成、发车和两端竞争的接口差异及回归场景。此时可并行只读分析，各任务在自身对话交付准备结果；不启动真实环境验收脚本。
 3. 总控核对共同设计后更新本契约的接口补充，明确解锁各实现任务。技术例行选择不再请用户重复批准；遇到改变业务行为或截图分组的问题及时向用户确认。
 4. 两个后端各自实现与自身测试，前端统筹Admin及PDA实现与测试；同一文件一个写者，后端Maven由主流程后端统一串行执行并覆盖另一后端的直接测试。共享导航/SQL/权限等由总控统一集成。
 5. 交付需包含实际差异、直接消费者、已执行检查、未验证项及待发布单元。代码通过、真实HTTP通过、人工页面及PDA真机通过分别记录，不互相替代。
 ## 六 必须覆盖的验证
 - 同一仓多个客户、多个目的仓装一车；同一目的仓不同客户的派送及费用不串客户，客户只读只能访问自己的货物和单据。
 - 调度审核与理货员审核的正常通过、驳回与重提；未通过不能进入装车，改货物或关键资源后旧审核不得误用。
 - 装车完成与发车分离，未安排派送不得发车；后台与PDA对同一版本同时操作只产生一次合法结果，未知结果按原请求键核对和重试。
 - 全部正常签收才汇总派送完成；部分签收仍未完成，异常不伪造完成、退库或费用结算。
 - 普通入仓、换标/退货来源、同托多来源及既有预约批次/工作事项的直接调用不丢来源、不重复扣库存或收费；保留上一批修复约束。
 - 加载、空态、错误、无权限、附件预览及四页签长编号展示；不逐行查询列表详情或附件。
 - 后端受影响测试与测试源码编译、网关路由合同、必要Mapper扫描；Admin类型检查/直接及全量测试/构建；PDA测试及H5/App资源编译按实际改动执行。
 本批授权覆盖代码开发及必要离线检查。没有本轮额外授权，不提交推送、不部署、不执行环境SQL、不操作测试业务数据、不启动本地Java/Nacos/数据库。环境主契约只在存在真实证据时维护，不把本契约作为发布完成证明。
 ## 七 技术准备的共同对齐要求
 三份独占准备文档不能代替本契约或自动解锁生产实现。准备阶段的共同对齐要求如下；本轮已按第九节明确解锁的范围进入实现，其他范围仍只读。
 1. 公开写命令的版本字段统一为 `recordVersion`，包括安排派送；`expectedVersion` 如有需要仅作内部参数含义，不形成第二套公开字段或兼容别名。
 2. 严格命令请求摘要与派送安排业务摘要分开：原键不能改操作者、动作、单号、原版本或载荷；另一请求键也不能重复创建同车派送或重复发布费用。全局唯一安排事实与跨操作者授权/重放边界须在两稿使用一致定义。
 3. PDA已经形成的真实库存扣减与拣货来源只执行一次。安排、装车完成及实际发车不得二次扣库存；派送稿中的 `picked→shipped` 必须明确究竟更新单据计数还是执行库存命令，不能留下两种解释。
 4. 正常签收资料保存维持派送到来源的原事务链，不能持子锁回头申请整车父锁。采用持久可恢复的待汇总事实，在提交后由主流程取得父锁读取已提交真实签收；两稿明确记录、消费、重试/重扫及测试的唯一写者。
 5. 安排、发车、取消及扫码的实际锁点须沿代码逐一核对，明确父记录、资源、排车、客户出库/派送、来源、库存之间的具体顺序。不能各自保留一条相反序列，也不能仅靠文档宣称已无死锁。
 6. 临时外配取证、实载核对、零扫码变更和客户旧创建入口按第八节用户已确认规则实施；日历新增预约按第十节留待独立整理，不再派给本批。未确认的新业务行为继续单列问题交总控，不自行扩大范围、加必填、放松校验或删除能力。
 ## 八 用户已确认的执行细则
 用户明确回复“四项都按建议执行”，以下四项自本轮起作为开发基线；不再重复请求相同业务确认。
 | 事项 | 确定规则 | 决策影响 |
 | --- | --- | --- |
 | 临时外配取证 | 建单人补齐本趟车辆容量、司机证照和预计任务结束，由调度审核核实；空单可先保存，审核前补齐 | 临时输入、证据上传、资格快照及审核必填；不自动建车辆或司机主档 |
 | 实际装载核对 | 在确认装车弹框接入既有实载核对，有依据的实际数据自动带出，缺项再确认；保持PDA真实拣货核平前置 | 实载来源/字段/弹框及双端核验；不新增第五个详情页签，不代填拣货箱数 |
 | 零扫码变更 | 保留原排车单号，显式退回装车前，修改后两级审核重提 | 新审核轮次、权限和历史；已经扫码的退装/回库不在本批新增 |
 | 客户直接创建派送 | 本批整车安排仅由平台执行，客户继续查看自己的派送单，移除旧客户直接创建这类派送入口 | 派送后端移除对应Merchant创建写入口；前端任务按第九节更新Client直接消费者，保留本客户读取及合法资料操作 |
 工程事项仍由总控负责：公开版本字段、请求摘要与业务摘要、真实库存扣减点、子单与来源锁序、签收持久提醒的写入和消费职责等不要求用户裁定技术细节。尚未核实的资源/预约提供者反向锁点必须在实现前补齐证据，不能用业务确认替代代码和并发验证。
 ## 九 工程基线与首批实现解锁
 本节为总控在用户确认业务后下发的工程基线，优先于三份准备稿中仍标“待用户裁定”、旧版本字段或相反锁序的段落。精确Java/TypeScript记录、端口签名及对外Schema由唯一接口提供者先产出，消费者读取实际骨架后接入，不自行补第三套协议。
 1. 采纳主流程稿的真整车主单：`ll_dispatch_order`不再以单客户头部代表全车；客户归属保留在真实货物/来源/子单。主单自动一对一关联Fleet资源记录，保留附加能力，不要求用户建立多张客户排车或操作旧绑定流程。派送采用每客户一张出库单、每客户每目的地一张派送单；公开返回完整数组，不保留单个outboundNo别名。
 2. 公共主单`status=ACTIVE|CANCELLED`，`stage=BEFORE_LOADING|LOADING|AFTER_LOADING|DELIVERING|DELIVERED`，审核子流程按主流程稿第3节；取消不是第六阶段。公开版本唯一`recordVersion`，0合法。Admin/PDA均以dispatchNo识别本车；车辆/司机主档和临时填写分别使用明确mode，用户可先保存空单，审核前补齐已确认依据。
 3. 公网前缀继续`/api/platform/v1/last-leg/dispatches`和`/api/pda/v1/last-leg/dispatches`。主流程API/查询统计/四页签对象采用主流程稿第4节语义，派送组合GET及整车POST采用派送稿第3节语义，依用户第八节补实载确认、零扫码退回重审及临时证据。详情仅vehicleInfo/dispatchInfo/documents/orderDetails四块；不把接口提案当已上线。
 4. 采用全局唯一idempotencyKey的共同持久命令账本，绑定原主体/动作/排车及严格commandHash；同键不得换主体或载荷。安排业务另有整车唯一事实及arrangementBusinessHash，当前有权限的主体用新键、当前版本引用同一已安排业务，不再生成单据或收费；`replayed`与`alreadyArranged`语义分开。原动作结果不可变，前端随后GET当前事实。
 5. 共同根锁按已核对Fleet顺序为trip→涉及的车辆主档→司机/资源→dispatch；不采用准备稿早期trip→dispatch→资源的相反序列。扫码只走来源→库存链且不取派送锁；安排/发车先收齐全部客户出库/派送锁，再取得来源/费用锁；签收保持delivery→来源→持久信号、始终不回头申请父锁。装车/安排/发车不重复执行扫码已完成的库存SHIP。未核实的预约/资源提供者交集仍须补源码和竞争测试，不宣称已证明全域无死锁。
 6. 共享契约只定义在`dispatch/port/`的DTO/接口，主流程后端唯一写入。采用DispatchExecutionPort、DispatchDeliveryPort、DispatchCompletionPort及明确的提醒数据访问端口；实现分别归dispatch和delivery，不跨域共享Entity或注入对方具体Controller/Service。派送任务保存持久信号及数据访问实现，主流程负责有界消费/退避/重扫；主阶段CAS和本次已核对信号确认在同一汇总事务中完成，失败回滚，错误记录在回滚后独立短事务更新。
 7. 平台新增排车、确认装车完成和确认实际发车分别使用`platform:overseas-warehouse:dispatch:create`、`platform:overseas-warehouse:dispatch:loading-complete`、`platform:overseas-warehouse:dispatch:depart`，列表/详情仍为dispatch:list，两级审核沿用既有独立审核权限。整车草稿及选货候选GET统一使用dispatch:list，草稿全部写动作统一使用dispatch:create；前端既有入仓单选货建排车入口同样核对排车查看与新建权限，不再依赖旧入仓单智能排车权限，不增加OR别名或通过补授旧权限绕过。客户仅保留本客户派送读取，不再登记或默认授予`merchant:warehouse:delivery:create`；海外PDA继续使用其独立作业角色、权限和仓绑定，不通过后台按钮权限进入作业。正式权限目录和角色关联以IAM源码及国内统一基线为准。
 ### 首批解锁和停止点
 | 任务 | 当前允许实施 | 依赖与停止点 |
 | --- | --- | --- |
 | 排车后端 | 先产出公共枚举、DTO/端口精确骨架及对应编译合同，然后实施主单/来源模型、版本幂等、五阶段和审核/装车/发车本域逻辑与测试 | 公共骨架完成在自身对话提交文件/签名/哈希供总控读取；下游按骨架接入。不得擅改delivery或预约在途文件；共同SQL/OpenAPI/权限提供精确提案交总控集成 |
 | 排车派送与费用后端 | 实施本域分组/单据/费用/持久提醒模型、Repository/Mapper及测试；实际整车适配读取主流程公开骨架后接入；按已确认规则移除旧merchant创建写入口 | 不更改主流程公共骨架，缺字段交总控；不执行Maven，稳定交付点把用例交主流程统一运行。不承担日历新增预约设计或实现，不抢写预约提供者 |
 | 排车前端与PDA | 四页签独立详情、五阶段列表/动作弹框与双端请求按实际公共DTO接入；同时移除Client这类派送创建直接消费 | Client范围为order-management的DeliveryOrderCreateView.vue、api/deliveryOrders.ts及真实入口/直接测试，修改前读Client指引；共享路由/导航交总控。预约页面与adminDensity.test.ts在途改动保持，不承担日历新增预约矩阵；不猜API或临时兼容旧版本 |
 所有任务先保留现场未提交修改；各自独占文件内可开展生产代码和必要离线验证，不提交、不部署、不执行环境SQL或真实HTTP。后端Maven仍由主流程唯一执行，测试前核对另一后端的文件稳定；中间编译/单测结果不代表全链完成。
 ### 当前并行收口分工
 用户检查发现仅主后端执行后，总控核对两个已交付任务及实际文件，复用三个既有任务推进剩余接线，不新建任务。以下为有限实施包，覆盖对应文件的此前只读等待，不接管日历新增预约：
 - 派送后端暂接File证据登记，唯一写入`file/src/main/java/com/baiyue/file/service/BusinessFileCategory.java`、新增`file/src/test/java/com/baiyue/file/service/DispatchEvidenceFileTest.java`及`file/src/main/resources/openapi/dispatch-evidence-v1.yaml`。仅登记主后端实际网关已使用的`OVERSEAS_DISPATCH_VEHICLE_EVIDENCE`和`OVERSEAS_DISPATCH_DRIVER_EVIDENCE`，平台0/整车内部主键归属，沿既有PDF/JPG/PNG、10MiB和内容签名规则；不改通用存储/Controller，不放宽其他类型。代码和用例就绪后交主后端串行执行File检查，仍不独占运行Maven。
 - 前端任务取得三个既有排车消费者及同名测试的唯一写权：`appointment-calendar/WorkDispatchForm.vue`、`WorkExistingDispatchForm.vue`、`WorkSharedTripForm.vue`及三个`.test.ts`。只收敛整车创建/加货/已有单跳转和原命令恢复，消除旧客户子单/共车协议及真实类型断点；不改新增预约、WorkDetailPanel、日历面板、planningApi或公共密度测试。上述六文件移交前已核对无未提交差异；若实际遇到新写入立即停止该文件并报告。
 - 总控继续集成时确认旧草稿生产链尚未收敛，主后端明确释放有限草稿包，交由既有派送后端任务唯一维护：`dispatch/entity/DispatchDraft.java`、`DispatchDraftContainer.java`、对应两个Mapper、`SmartDispatchController.java`及新增专用草稿Service/Repository/Mapper、命令持久记录和直接测试。候选仍委托主后端真实提供者；按已冻结PlanningModels及前端真实调用处理草稿版本、拥有者、来源占用及全部容器原子转换，不保留单客户旧协议。共享port、AggregateService、DispatchSourceMapper、旧DispatchService不移交；必要本域桥接由主后端写入。原派送生产及File文件仍冻结，SQL/OpenAPI交总控，草稿任务不启动Maven。
 - 主后端继续唯一维护上述草稿移交包以外的`dispatch/`、`fleet/trip/`和共享端口，补审核/装发、实际来源、PDA、Fleet一对一收敛及真实读写合同；不新增页面或业务规则。主后端保留唯一Maven执行权，按稳定输入覆盖File和派送用例。前端冻结后的只读差异核对已发现Long数量/附件大小字符串造成的真实阻断，总控仅解除其原有独占范围冻结以修正响应边界、直接消费者和真实wire回归；ID/版本继续无损，不改共享解析器、DataTable、导航或新增预约。
 - 总控直接承担共享数据库基线、OpenAPI、权限及根入口收口，其他任务不写这些文件；File上述独占契约除外。索引/AGENTS最终统一维护，避免另建重复状态文档。
 ### 既有预约接线的本轮授权
 2026-10-19用户明确批准按《排车列表派送费用接口设计》第13节接线，新增预约不动。本段覆盖下列既有消费者的此前只读限制，不接管日历新增预约或建立车辆预约权威表。
 - 派送后端唯一维护`appointmentwork/AppointmentWorkDispatchPort`、`inboundplan/work/AppointmentWorkDispatchBinding`、`AppointmentWorkDispatchMapper`、`AppointmentWorkDispatchCandidates`、`FbaAppointmentExecutionAdapter`、`FbaAppointmentTransportAdapter`、`inboundplan/mapper/InboundFbaAppointmentQueryMapper`，以及原`FbaAppointmentTransportPort`、`FbaReceivingService`和实际受影响的直接测试。先产出批量预锁和仅替换本次明细的薄合同供主流程消费；不写主流程公共port或AggregateService。
 - 主后端继续唯一维护`dispatch/port/`和主流程，给既有批次候选引用、分配补权威`recordVersion`（0合法、缺失及同批混版本拒绝），提供版本化的窄内部原预约变更命令；负责创建、加货以及草稿全批转换在来源锁之前预锁完整批次集合。另取得`ExceptionOrderService`及其直接测试的最小适配权，仅修正新共享PDA任务接口消费并保留明细/扫码/订单按真实客户隔离，不新增异常功能。
 - 前端只在原排车模型/API/wire/弹框、三个已授权既有Work排车表单及直接测试内，按实际Java合同透传批次版本；原冻结候选仅对此接线解除冻结，其他部分保持。不得猜版本、补0或改日历新增预约、面板、planningApi及公共密度文件。
 - 批次分配采用本次触及明细的增量替换，保留其他客户与未变明细的原分配，并以整车有效总量复核。统一锁序为全部父trip/资源/dispatch及必要的全部客户outbound、delivery，再全部既有批次、来源及实物/库存占用，协调guard在业务锁与变更之后；不能形成来源→批次反序。原命令身份、两级审核失效、主版本、零真实扫码、完整实物及整事务回滚规则不变，不补回退役Fleet绑定/移货别名。
 - 车辆预约仍须明确原权威记录、版本和归属提供者。当前未定位到该提供者时保持显式门禁，不能用FBA批次、外接预订或旧手填状态替代；此授权不包含新的车辆预约表、创建API或日历业务。
 共享SQL、OpenAPI、权限仍由总控集成，Maven仍由主后端唯一执行；不增加任务、不部署、不执行环境SQL或真实业务写入。
 ## 十 日历新增预约的范围分离
 用户澄清“新增预约”应放在预约日历，并指定由对话 `01a15231-2507-7802-8015-34b01f5eb2c4` 处理，明确本总控不用接管。三个排车任务不修改预约日历的新增预约表单、权威预约模型或预约新建API，也不承担其设计和矩阵；本批只处理整车改造确实影响的既有预约读取/关联消费者，有限接线写权见第九节，不自行接管新增预约或跨对话派工。
 此前关于FBA预约可先保存、后关联真实货物和排车，以及车辆可先独立预约、后关联排车的答复仅保留为日历需求输入，其后续规则和实现由用户指定对话处理；此处不继续整理日历方案、不创建新任务、不跨对话转派，也不删除已经存在的预约功能或关联。
@@ -1,5 +1,20 @@
 # 预约工作日历 V13 变更说明
 ## 2026-10-19 当前预约列表收敛规则
 本节来自用户本次确认，优先于下文 V13 对预约列表入口、类型与承载方式的早期规定；下文数量、客户隔离、真实执行等原业务约束继续适用于各自业务模块。
 - 预约列表恢复用户截图 `codex-clipboard-840bcc07-6b54-4afa-9dc7-666d09ff04f2.png` 的左侧月/周日历、右侧当天安排。类型仅为到港、排车、还柜、计划到仓；每日期格最多三条预览，完整记录在右侧查看。保留当前范围搜索和未定日期入口。
 - 月视图按当月所需显示4、5或6个完整周，仅在首尾周补齐相邻月份日期，不固定追加六周。2026年10月显示9月28日至11月1日，不显示11月2—8日整周；日历查询同步采用实际展示范围，周视图仍为7天。
 - 到港优先实际到港，缺实际时采用预计到港。计划到仓默认在该到港当地日期上加两个自然日，跨月和夏令时仍按日期加两天，不补造具体时刻。人工保存的整柜时间优先，已有入库计划的冻结时间保持；尚未人工维护和未建计划的默认日期随到港事实变化。该默认值属于日历日期推算，不自动写入入库计划、不充当实际到仓。人工调整复用整柜预计到仓命令、原编辑权限、版本及幂等键；已有入库计划后仍不可改。
 - 排车仅指海外仓送往 FBA/客户仓的真实车次，同车多客户只展示一次；已发车按实际起运仓当地日期，未发车按计划日期，取消车次不列入活动安排。港口提柜送海外仓不作为排车类型。
 - 还柜未完成按原业务截止日期提醒，完成后按实际还柜日期展示；日历不独立计算或改写还柜状态，登记进入原货柜业务。
 - 用户随后明确恢复日历顶部“新增预约”：本次先支持FBA，普通客户仓不在本次范围。居中弹框选择已有货物，核对真实来源后复用原预约表单与保存接口；同起运仓、同目的FBA仓可跨客户合约，保留原写权限、版本/幂等、未知结果重试及未保存保护。货物查询栏支持可搜索、可清空的目的FBA仓下拉框；选项来自同权限范围的权威美国FBA目录，不从当前分页推算。提交查询后回到第一页，翻页沿用目的仓条件，重置恢复全部目的仓；跨页已选货物仍保留并执行同起运仓、同目的仓校验。保存成功显示真实预约编号及内容，不自动创建车次，不增加第五类日历或手工编造到港/还柜等事实。
 - 入口移除全局工作待办、流程筛选、负责人分派、跟进、复核、责任交接，以及货物核实/分批/共约/共车编排入口；这些原业务在相应模块继续处理。仍由其他业务页面实际使用的精确来源或事项深链可以打开原业务表单，不恢复旧全局待办及筛选协议。
 - 缺权限、来源失败或缺时区明确提示数据范围不完整，不能显示为全部完成或完整空日历。未知日期保留未定，不用浏览器当前日期、内部 ID 或假数据补齐。
 代码与自动检查、部署、真实 HTTP 及人工视觉验收分别判定；本次 UI 目标仍为1920×1080、100%缩放，用户截图确认后才记录视觉通过。
 确认日期：2026-10-16。用户已确认 V13 原型，并要求按现有开发分工继续实施。本文是本轮产品行为、业务约束与验收场景的正式变更依据；确认需求不表示业务代码、部署或真实环境验收已经完成。
 接口和唯一文件写者继续由[开发协作契约](预约工作日历开发协作契约.md)维护。本文维护业务规则，不另建开发进度台账；实现进度由“预约”开发总控维护既有检查点，部署与整体验收事实仍归环境主契约。早期[优化方案](美国预约管理统一总览与优化方案.md)及 V11/V12 评审记录用于追溯，冲突时以本次确认和现行正式契约为准。
@@ -1,5 +1,63 @@
 # 测试环境独立任务协作登记
 ## 2026-10-19 排车列表统一作业改造
 用户明确当前对话 `01a15230-a9d6-7503-a8a9-d70691df49e5` 为本批总控并要求先定义规则再下发。旧三个排车对话已归档，本轮消息未送达，保持归档状态；用户随后明确新建三个独立任务。所属TEST项目 `c64729ff-6710-43c6-8ef2-d84e9666cc1e`、host local、cwd `C:/Users/BY-OY/Desktop/code/chongchong-global` 已核对。用户已确认四个彩色图标详情页签、两种建单方式、允许临时填写外配车辆司机、PDA拣货核平后后台才能确认装车完成。新建任务如下，依后端工作量采用两个后端和一个Admin/PDA联合前端任务；首批仅做技术准备，共同接口冻结并由总控明确解锁前不修改生产代码。本批业务和文件边界唯一见[排车列表统一作业改造契约](海外仓业务/排车列表统一作业改造契约.md)。
 | task_id | 对话 | 本批稳定职责 |
 | --- | --- | --- |
 | `01a1524f-4f11-70c2-8a46-8e06e73a2d86` | 排车后端 | 排车主单与明细客户归属、建单/加货、五阶段、审核及装车/发车；`dispatch/`、`fleet/trip/`及对应测试唯一写者（`FleetBookingFreight.java`除外），后端Maven唯一执行者。 |
 | `01a1524f-56a9-7320-a5fd-8ff76fa4356b` | 排车派送与费用后端 | `delivery/`、必要`financefee/`、`FleetBookingFreight.java`及对应测试；客户目的仓拆单、费用和正常签收汇总事实，不写排车主流程类/DTO/Mapper。 |
 | `01a1524f-52c7-7cc3-9b08-d34ad24c172a` | 排车前端与PDA | Admin排车列表、四页签详情、弹框/API/类型，以及海外PDA任务/装车/发车/恢复与直接测试；不写Java，预约日历在途文件先只读。 |
 当前总控负责业务与共同接口冻结、共享导航/根路由/权限/SQL/Gateway及共同OpenAPI集成、协调检查和交付。两个后端先对齐主单/明细、动作资格、派送完成事实、事务和锁顺序；前端并行准备原型矩阵和双端接口差异；接口冻结后再解锁实现。各任务自行报告，由总控读取，不自动获得向其他对话发消息或递归委派的授权。
 用户随后明确“四项都按建议执行”，再澄清“新增预约”是预约日历功能，先与排车改造分开整理。此前两类预约先保存后关联的答复仅保留为日历需求输入，不派给本批三个任务。当前依主契约第八至十节进入分阶段实施：主流程先产出公共DTO/端口骨架；派送后端实施本域拆单/费用/提醒；前端接入真实骨架、四页签及双端，并取得Client旧派送创建直接消费的最小移除权。预约在途文件保持只读；确受整车改造影响的既有关联调用先核对唯一写者再逐文件解锁；`adminDensity.test.ts`等其他在途内容不得覆盖。共同SQL/OpenAPI/权限/根路由仍由总控集成，Maven仍由主流程唯一执行。此前仅准备的阶段门禁由本段及主契约第九节的精确解锁取代。
 用户进一步指定日历新增预约由既有对话 `01a15231-2507-7802-8015-34b01f5eb2c4` 处理，并明确本总控不用管；此记录仅标注避免冲突，不授予本总控对该对话的读取、派工或接管职责。
 本批本地实施检查点：三个任务已收到第九节实施派工且状态为执行中。总控已移除Client `order-management/routes.ts`的旧派送创建路由及`tenant-management/contracts.ts`对应权限展示/映射，前端任务负责同步直接测试并统一运行Client检查。实现前网关路由合同5项通过；Lastleg依赖合同9项通过、3项失败，现有`fleet/pickup`三个类直接依赖`transfer.entity.WarehouseTransferOrder`不符合基线，尚未由本批扩大修改或添加豁免。最终检查必须区分这项既存阻断与本批新增问题；以上不表示新流程已实现、已部署或已完成真实页面/PDA验收。
 后续本地检查点：四页签结构和Client移除已有实际差异，总控已核对；前端专项报告四页签6项、Client全量601项及typecheck/build通过，真实页面仍待人工验收。`dispatch/port/`公共骨架已生成但尚未完整冻结：主后端负责补实载只读查询、候选来源版本、草稿转换和既有预约批次投影；同时处理缺失recordVersion不得默认为合法0、预约结果不得由请求伪造、命令结果持久化多态恢复。派送专项按实际端口接入信号/分组，前端先保持预约表单只读并交最小接线清单。总控下一步核对补齐后的生产者合同与消费者，再集成共享SQL/OpenAPI/权限，不以骨架或局部通过推定全链完成。
 2026-10-19 14:05跟踪：主后端已在实际请求DTO中将版本改为Long并拒绝缺失/负值，0保持合法，车辆预约写请求收敛为引用和版本；其编译、恢复测试及完整接口仍待交付。派送域已新增签收持久信号Entity/Repository/Mapper及实际端口实现，签收资料保存同事务只入信号、不回调父流程；拆单、费用、完成汇总及结构尚未集成验证。四页签代码仍严格为车辆信息、排车信息、单据信息、关联订单明细。前端专项新报告Admin全量存在旧布局断言及另一页面超时，正在区分本批失败和独立失败；当前不能标记Admin全量通过。负责人分别保持主后端补齐公共合同、派送后端本域实现、前端给精确失败和既有预约消费者清单；日历新增预约不接管。
 2026-10-19 14:36跟踪：总控已逐文件核对主设计第0节13个port文件SHA-256，全部匹配，公共骨架可供下游绑定；实载GET/候选版本/类型化草稿结果/既有批次投影已具备实际类型，Controller和来源适配仍未完成。主后端报告独立JDK17合同、全部Action跨实例JSON恢复、真实MyBatis/H2命令账本及身份冲突测试通过，Maven尚待派送稳定窗口；主单/审核/双端装发仍未交付。前端报告Client601项、Admin定向66项及两应用typecheck/build通过；旧布局断言已更新并定向通过，最终Admin全量3375项通过、11项5秒超时，不能标全量通过。五阶段列表及PDA仍未实现。派送后端仍执行中，正移除旧单客户生产转换链并补整车费用/回滚用例，尚无完整交付。已按既有写权衔接下一包：主后端接续主单/查询/建单和审核装发，前端按已核对骨架接续五阶段和PDA，派送继续原独占范围；不是重派已完成切片。受保护预约三表单与File证据仍是后续集成依赖，共享SQL/OpenAPI/权限由总控待最终提供者清单集成。未新增任务、文件写权或环境操作。
 2026-10-19 14:56跟踪：派送后端本域代码已交付并冻结，39路径快照经总控按JS localeCompare排序独立重算，匹配`ab2a553af145d7a2c708f1b44d88eb2c349970d81295bbbe4504af5f55ed2f81`；最初ordinal排序差异已解释，没有代码漂移证据。总控已读实际整车安排/发车/签收事实链：按客户出库及客户目的地拆单、全体子单锁先于来源、签收只入持久信号；共享执行端口实现及并发组合仍未验证。本域Maven未执行，设计11.1—11.3已有两表/来源字段SQL及准确用例；已交主后端在当前切片稳定后统一test-compile和直接测试，并更新其独占手工fixture。主后端正在实现整车自动资源记录、主单持久化与查询，旧绑定尚未退出；前端实际代码已接五阶段、装车前三分区、带来源版本的整车草稿新建，四彩色页签保持，尚未给新输入测试结果/PDA交付。当前阶段为联合实现和编译前集成，不可部署；共享结构/API/权限及保护中的既有消费者仍待收口。未新增任务或扩大写权，未操作日历新增预约。
 2026-10-19 15:16跟踪：主后端报告生产及测试源码均已编译通过，定向144项中143通过，唯一失败为Merchant OpenAPI旧创建POST。总控已核对实际Merchant测试报告失败位置并在共享`overseas-business-v1.yaml`删除对应7行POST描述，保留客户读取/详情/签收资料，diff检查通过；已交唯一Maven写者重跑该失败类，当前待复验，不把修文档当测试已绿。主单真实Mapper/H2三项测试报告3/3通过，总控已核对空单一对一Fleet、双客户一车及事务回滚断言；实际选货来源在该用例是受控输入，权威来源解析和完整审核/装发仍未验收。PDA专项报告全量278项通过，新增覆盖断网原命令恢复、同数量下一次实拣换新键、成功后GET失败及另一端已发车恢复；总控已核对实际API/store/页面差异，H5/App编译和Admin新输入检查仍在进行。派送冻结输入无变化；下一步主后端复验OpenAPI并继续真实来源/状态链，前端完成资源构建与Admin验证，总控继续共享结构/权限及受保护消费者集成，不部署或写环境。
 本节作为三个对话在本批的职责依据，生产写权以主契约第九节的首批范围和停止点为准；上一批提交、发布、SQL和真实HTTP授权不延续。保留当前工作区和分支，不建worktree或项目副本，不提交推送、部署、执行环境SQL或真实业务写入。部署与真实验收事实仍只维护两份环境主契约。
 2026-10-19用户要求检查“只有一个对话慢慢跑”：核实主后端active，另两项各自切片交付后idle。总控按主契约第九节“当前并行收口分工”重新衔接有限包：派送后端独占File的BusinessFileCategory、DispatchEvidenceFileTest及dispatch-evidence-v1.yaml三文件；前端独占WorkDispatchForm/WorkExistingDispatchForm/WorkSharedTripForm及同名测试六文件，仅处理原有排车消费者。上述文件已定向核对无在途未提交差异；WorkDetailPanel和新增预约文件继续保护。主后端保留主流程/公共端口/唯一Maven，总控承担共享SQL/OpenAPI/权限；不新建任务或业务范围，不接管用户指定日历对话。此有限移交覆盖此前三表单和File登记只读等待，其他边界保持。
 2026-10-19 15:39跟踪：三个既有任务均active，File限定包及六表单接线均已确认接收，未出现新权限/业务决定阻塞。总控已实际同步模块及海外统一空库源SQL：公共命令账本、整车唯一派送安排、签收持久信号及出库不可变来源字段；并按当前DispatchAggregate完整收敛整车无客户头、五阶段、审核/版本/资源及loading_confirmation_json，新增追加历史和货物来源字段。静态比对两份整车列集合与实体全部字段一致，主单/历史定义一致，diff检查通过；Fleet/PDA/草稿与完整权限/API结构仍未收口，不能视为SQL整体验证通过或已执行。主后端继续主流程/附件公开端点，派送后端File提供者，前端既有排车消费者；无新建任务、无环境操作、无日历新增预约改动。
 用户要求总控也直接参与实现后，总控独占完成权限集成8文件：OverseasPermissions、IAM phase5-delivery-permissions.sql及iam-v1.yaml、国内统一基线、四个直接IAM测试。新增dispatch:create/loading-complete/depart（5107065/66/67），移除客户创建5306001及默认关联，客户只读；来源目录20项、仓库操作岗19项、理货只读5项，PDA未获后台权限。主后端按唯一串行窗口运行后，总控核对四份实际Surefire报告合计24项全部通过，并核对target中执行的权限SQL/OpenAPI与当前源码哈希一致；这是本权限包验证，不代替Lastleg全链或环境验收。
 File三文件实际哈希已逐项匹配交付，12个新增用例交主后端统一运行。前端六表单接线报告17文件142项及Admin typecheck/build通过，现按实际DispatchWorkModels/Controller接附件、移货和路线。派送专项继续只读审查集成，并收到一次精确编译反馈修正：MerchantDeliveryControllerTest第133行误将delivery之外的warehouse-transfer/cargo-discard合法POST纳入禁止范围；仅解除该测试文件冻结，按精确路径块修正并重记候选，生产文件及File三文件仍冻结，不为追绿删除其他业务接口。总控后续继续平台OpenAPI及其余Fleet/PDA/草稿结构收口。
 2026-10-19 16:05跟踪：主后端报告生产源码编译通过，但全部测试源码被派送合同测试的旧取消调用阻断。总控核实`PlatformDispatchOutboundContractTest`仍引用旧`DispatchController.cancel`和旧更新DTO；实际取消已迁至`DispatchAggregateController`的版本化POST。已复用派送任务，仅解除该直接测试的冻结以修正调用、反射及实际受影响路由断言，保留客户拒绝和独立权限，不恢复旧接口、不自行运行Maven；主后端知悉并继续修正证据网关将HTTP200错误JSON当文件、业务拒绝误归上游故障的两项问题。派送任务已恢复执行。前端报告18个相关测试文件155项、Admin类型检查及构建通过，路线提示和资格禁用状态仍在最终收口；这是专项报告，尚非全量回归及真实页面/PDA验收。总控继续负责剩余共享OpenAPI和Fleet/PDA/草稿结构；无新增任务、无环境操作，日历新增预约仍不接管。
 2026-10-19继续实施：前端已交付并冻结当前21生产文件候选，18文件155项及收口13项、typecheck/build通过；派送已修旧取消/更新消费者测试，待主后端运行。总控发现PDA Controller、草稿及Fleet关联仍为旧生产模型，主后端确认未完成；不得再以生产编译通过代表本批实现完成。主后端明确释放的草稿包已按主契约第九节移交派送任务唯一实施，PDA/发车/汇总/Fleet及公共端口仍由主后端负责。前端仅只读对账实际API/Controller，不重写已冻结生产。总控已同步两份SQL的Fleet草稿计划时间可空及活动物理托盘唯一锁，继续OpenAPI及共享结构。该分工复用既有三任务，没有新增对话、子代理或环境操作。
 2026-10-19 16:25收口检查点：用户发现侧栏仍有车次管理，总控已将`fleet-trips`设为hidden并同步既有导航断言，实际16/16通过；出车记录按实际发车运营查询继续保留，旧车次详情和附加代码不删除。总控同步源及统一SQL的草稿拥有者/起运仓/版本/来源快照、容器来源键/序号唯一及草稿命令表，相关10表字段集合、重复字段、中文注释静态核对通过；同时纠正了上一轮明细中订单号列重复声明。平台29组路径与PDA7组原生路径已按实际Controller更新，两份OpenAPI共享实际DTO及Long字符串wire，537个引用及重复键检查通过；移除旧取消/移货DELETE、已退出fee-coverage、单客户standalone预排及PDA旧complete/车次版本发车协议。网关合同5/5通过，未运行环境SQL或HTTP。草稿主后端桥接已落地；旧DispatchService草稿方法仍须由其唯一写者清理。前端只读复现了批次货物数量严格比较、零扫码移货及附件大小校验三处真实字符串阻断，已仅在原独占范围解除冻结修正并补wire回归；此前155项不能代替新输入。当前仍待两个后端稳定编译及行为回归、既有预约批次/车辆预约权威提供者接通（现主流程仍显式拒绝其写入）、Fleet/PDA旧模型最终收敛、证据网关与全链事务验证。新增日历预约仍不接管。
 2026-10-19 16:42跟踪：旧DispatchService草稿读写/占用/转换方法已由主后端删除，原草稿客户字段编译交集从源码中消失；主后端报告含桥接及原生PDA的当前生产快照编译通过，完整测试仍待稳定输入统一运行。草稿专项13文件稳定候选`db84f7527d8ee88a5b893ed291081041c5a1461d7dbdafc66716014c575d3ac0`经总控逐项及聚合复算全部匹配；3份16用例已写好未运行，已交唯一Maven写者。总控同步plan_ids_json为LONGTEXT以容纳500个Long引用，并补齐草稿公开业务必填；两份OpenAPI537引用及10表静态核对通过。总控同时收敛3份最近AGENTS中的旧排车流程指引，最终索引合同1161项通过。前端报告新候选Admin19文件209/209、PDA282/282及类型检查/H5/App/Admin构建通过，测试文件恢复后已复测；总控实际复算22生产文件摘要`63feb551c2325450ddd0bd7840c81191620372aa2cf64ea2dfb97027282c429f`匹配，源码响应边界保留ID/版本且安全归一化数量，之前3处字符串阻断已有真实wire回归。草稿和前端候选保持冻结，不代表后端全链或人工/真机通过。派送任务接续仅只读审查既有预约Provider的客户归属、分配保留、发车收货复核和锁序，不新增写权、不接管新增预约；主后端继续本域及统一编译/回归，总控收口共同契约。
 2026-10-19 16:57跟踪：主后端已运行本批Lastleg定向轮次，总控此前读取28份实际Surefire报告合计178项、1失败和1错误；两项分别是草稿Controller权限测试错误遍历非HTTP方法，以及转换原结果的嵌套Payload恢复失败。已交草稿唯一写者修正，不恢复旧协议、不重做原转换。前端专项只读另发现并由总控核实首次选货在来源锁等待期间跨过草稿到期点，可能返回成功但没有有效占用；同一草稿写者补原租约锁后复核、完整续期校验和真实行锁/可控时钟回滚用例。上述有限草稿包仅为这三项解除冻结，修复后重记候选交主后端唯一Maven执行。File七类验证仍被原证据测试4处IOException编译错误阻断，已交该文件原写者最小修复；不能记作File运行通过。总控已同步两份SQL中单排车PDA任务唯一约束及Fleet关联去客户头部/旧审核镜像，12直接表静态核对通过；主后端继续Java模型及两客户单任务回归。后续PDA轮次13项被DispatchPdaTask非法字节码VerifyError阻断，主后端正处理本地target重编译，不能归类业务断言失败；总控实际报告核对证据网关5项通过、双端发车持久2项通过。前端22生产文件保持冻结，另接只读新建/草稿/候选权限调用链核对；预约Provider只读审查暂缓于草稿运行缺陷，尚未解除其写权。以上没有部署、SQL或真实页面/PDA验收，日历新增预约仍不接管。
 2026-10-19 17:02跟踪：前端只读核对证实新建入口使用dispatch:create，但草稿接口仍依赖旧入仓智能排车权限，当前默认仓操作角色会被业务鉴权拒绝；总控按主契约9.7统一为候选/草稿GET使用dispatch:list、八个草稿写使用dispatch:create。Controller及直接测试由草稿唯一写者同批修正，前端仅在原模块内修正无重叠写者的InboundOrdersView/permissions及直接测试；原22生产文件保持冻结。总控已同步共享OpenAPI并实际重验537引用、重复键、路径及两份12表静态结构通过。草稿三项缺陷与File受检异常修正已有源码，最终指纹及唯一Maven重跑尚待交付。主后端报告隔离target异常后的定向JUnit36/36，含两客户单任务/发车竞争/回滚；总控已索要既有报告和源码指纹，尚不记完整Maven或全链通过。预约Provider客户头部消费者及锁序适配仍待处理，没有扩大其写权或接管新增预约。
 2026-10-19 17:05交付复核：草稿唯一写者已停止该包写入，总控逐文件及聚合复算13文件新指纹`b0db1bb5191fa3578dacfa0f07c7c2a6a30346f0198047e34fc1fe3a99b0e554`匹配，当前17用例（持久10、Controller6、OpenAPI1）与File七类一并交主后端串行重跑。File测试新指纹`bba87946457fb1290960218127087552de95b59f443eb6d5dacf354084d04a19`及其余两文件已核对，运行通过仍待证据。入仓选货建排车入口4文件哈希均匹配交付，专项30/30及typecheck通过，原22文件候选聚合保持一致。派送任务接续此前暂停的预约Provider只读提案，不获得生产写权；前端停止待新反馈。总控另将原主后端独占的FleetCapacityOfferController arrange-dispatch旧智能排车权限消费交其随本域收敛，保留附加业务及其他独立权限；在全部直接消费者核清前不删除仍被引用的旧权限资源。没有新增任务或环境操作。
 2026-10-19 17:12验证更新：总控已读取File本轮7份实际Surefire报告，合计49/49、0失败0错误，其中DispatchEvidenceFileTest12/12；测试源码指纹仍与交付`bba87946…84d04a19`一致，原File编译阻断关闭。总控另核对固定输出JUnit日志36/36、清单10份源码哈希、日志和编译jar指纹全部一致；该证据明确不覆盖随后Fleet重写。前端独立只读复核也匹配草稿新13文件指纹，确认此前跨期来源占用漏洞在源码上闭合，未发现本次修正明确回归；新17用例和完整生产提供者事务仍待运行。预约只读审查确认ExecutionAdapter及两份测试仍消费旧客户头，车辆预约带版本权威提供者尚未定位，不能拿FBA批次或Fleet预订代替；未扩写预约文件或接管新增预约。
 2026-10-19 17:25授权及接续：总控已核对派送设计第13节的具体接线提案，用户明确答复“允许按清单接线，新增预约不动”。据此解除该节既有预约Provider/Execution/Transport/QueryMapper、原TransportPort/ReceivingService及直接测试只读限制，交派送后端唯一维护；主后端继续公共port/批次版本/主流程预锁和窄原预约变更命令，另最小适配ExceptionOrderService旧共享PDA调用与直接测试；前端按实际合同同步原排车模型和三个已授权Work表单。精确边界与批次→来源锁序已写主契约第九节新授权段，三个既有任务已收到接续派工，不新建对话。车辆预约独立权威仍未定位，此授权不允许新建权威表/API或接管日历新增预约。当前隔离编译显式排除3个未接线消费者，不能记整服务通过；新一轮62项中57通过、5个Fleet方法权限用例因缺测试Bean失败，其后单独5/5报告已出现，仍需主后端交完整输入和最终结果。此前File49/49和固定输出36/36证据保留原范围。
 2026-10-19 17:32接线检查点：两侧薄合同已实际落地并由总控核对SHA，公共DispatchContracts为`73b5b83f…ca84f641`、窄DispatchAppointmentAmendmentPort为`45aca62f…7887b238`、原AppointmentWorkDispatchPort为`81107e69…717a784b`。两个公共批次DTO版本在末尾、Provider版本在中间，已向双方明确逐字段映射；版本必填、0合法，不增加HTTP入口。前端已据真实公共DTO接续，B开始从真实明细/分配读取客户并实现保留旧分配的增量。总控已将公共批次版本同步OpenAPI，4份相关OpenAPI的重复键/653引用/退役路径/版本规则及两份12表静态结构通过；Fleet已移除8个退役操作且保留附加能力入口，实际网关路由合同5/5通过。Fleet旧未用schemas及最新响应类型仍待最终提供者清单，不记完整契约收口。原22前端候选仅为此次版本消费解除相应冻结，包含DispatchWorkflowDialog ADD_CARGO直接调用；没有再次申请同一已授权范围。各本域实现和全服务编译/联合行为回归仍未完成。
 ## 2026-10-18 预约演示问题交接与原总控退出
 用户明确指定既有对话 `01a14f36-9fae-7dc0-90e6-1d3c54d22de6`（Bug 处理-1）处理 D1674 演示中的三个问题：保存预约后页面 A0409、查看原排车单后事项弹窗未关闭、继续安排本批车辆提示操作资格已变化；并明确 `01a13df2-c639-7560-a3e2-30bc23a579b3`（预约）不再担任总控。原对话已将操作指南、四张用户截图路径、已有诊断和保护边界发送给指定对话，停止开发调度、修改与部署。下方历史预约总控身份不再代表当前授权；本次不指定新的全局总控、不新建长期专项。
@@ -227,4 +227,5 @@ JWT 不携带角色或权限集合，只保留必要身份、客户/应用/仓
 三对话发布后只读冒烟（2026-10-10）：Lastleg #254 与 Admin #555 的精确提交及健康证据见单机部署主契约。统一 Auth 的 admin1 独立会话经 Gateway 查询 `/platform/v1/last-leg/appointment-planning/impacts`、`/appointment-planning/external-candidates`（同属 Lastleg 前缀）及 `/platform/v1/last-leg/overseas-procurements` 均 HTTP 200、业务码200，随后退出自身会话成功。仅证明本轮读接口与新增表接线可用，不代替船期事项认领/记录/关闭的完整写入与权限验收；证据 `reports/three-threads-release-http-20261010.json`。
 2026-10-19 本土卡车与散板字段发布后的真实 HTTP 已核对：客户查询/编辑仅使用认证客户范围，伪造其它客户参数不能读取或修改其订单；客户访问平台入口、平台身份访问客户入口及未登录请求均按现有合同拒绝。平台、客户独立测试会话均退出成功。本轮未发布 Gateway/Auth，未重跑全部撤销、事件或 PDA 仓绑定矩阵；精确版本及 111 项业务 HTTP、34 项端侧产物检查证据统一见[本土卡车与散板需求字段发布](测试环境单机部署与配置契约.md#本土卡车与散板需求字段发布2026-10-19)。
`@@ -227,4 +227,5 @@ JWT 不携带角色或权限集合，只保留必要身份、客户/应用/仓`

	三对话发布后只读冒烟（2026-10-10）：Lastleg #254 与 Admin #555 的精确提交及健康证据见单机部署主契约。统一 Auth 的 admin1 独立会话经 Gateway 查询 `/platform/v1/last-leg/appointment-planning/impacts`、`/appointment-planning/external-candidates`（同属 Lastleg 前缀）及 `/platform/v1/last-leg/overseas-procurements` 均 HTTP 200、业务码200，随后退出自身会话成功。仅证明本轮读接口与新增表接线可用，不代替船期事项认领/记录/关闭的完整写入与权限验收；证据 `reports/three-threads-release-http-20261010.json`。	三对话发布后只读冒烟（2026-10-10）：Lastleg #254 与 Admin #555 的精确提交及健康证据见单机部署主契约。统一 Auth 的 admin1 独立会话经 Gateway 查询 `/platform/v1/last-leg/appointment-planning/impacts`、`/appointment-planning/external-candidates`（同属 Lastleg 前缀）及 `/platform/v1/last-leg/overseas-procurements` 均 HTTP 200、业务码200，随后退出自身会话成功。仅证明本轮读接口与新增表接线可用，不代替船期事项认领/记录/关闭的完整写入与权限验收；证据 `reports/three-threads-release-http-20261010.json`。


	2026-10-19 本土卡车与散板字段发布后的真实 HTTP 已核对：客户查询/编辑仅使用认证客户范围，伪造其它客户参数不能读取或修改其订单；客户访问平台入口、平台身份访问客户入口及未登录请求均按现有合同拒绝。平台、客户独立测试会话均退出成功。本轮未发布 Gateway/Auth，未重跑全部撤销、事件或 PDA 仓绑定矩阵；精确版本及 111 项业务 HTTP、34 项端侧产物检查证据统一见[本土卡车与散板需求字段发布](测试环境单机部署与配置契约.md#本土卡车与散板需求字段发布2026-10-19)。	2026-10-19 本土卡车与散板字段发布后的真实 HTTP 已核对：客户查询/编辑仅使用认证客户范围，伪造其它客户参数不能读取或修改其订单；客户访问平台入口、平台身份访问客户入口及未登录请求均按现有合同拒绝。平台、客户独立测试会话均退出成功。本轮未发布 Gateway/Auth，未重跑全部撤销、事件或 PDA 仓绑定矩阵；精确版本及 111 项业务 HTTP、34 项端侧产物检查证据统一见[本土卡车与散板需求字段发布](测试环境单机部署与配置契约.md#本土卡车与散板需求字段发布2026-10-19)。