统一客户端新增页布局与字段校验设计规范

静态索引合同免排队仅限直接扫描文件的只读脚本；node --test 形式的合同测试与 pnpm test/typecheck/build、mvn 仍必须经 local-check.ps1。

AI工程执行与协作约束.md

@@ -17,10 +17,38 @@
 - 禁止在 `apps/*/`、`baiyue-firstleg/` 及业务模块内部新增 `.codex-temp/`、`.codex-tmp/`、`worktree/` 或类似项目副本。遗留目录须先确认没有运行进程和唯一证据，再按精确路径清理。
 - 端口冲突通过停止已知旧进程或指定其他端口解决，不得复制项目。普通验证应直接覆盖当前未提交修改，不为获得“干净目录”绕开真实变更。
 
+## 本机重型检查与多对话限流
+
+- Windows 本机的测试、类型检查、构建、依赖安装和 Maven 命令统一经 `baiyue-firstleg/scripts/local-check.ps1`（PowerShell 7）执行。两个锁位于当前用户 `%LOCALAPPDATA%/Chongchong/LocalChecks/`，与工作目录和对话无关；同一用户下最多同时执行 2 项，两槽都占用时才排队，每 15 秒提示占用。首槽沿用 `heavy.lock`，在途旧入口继续计入首槽；第二槽为 `heavy-2.lock`。已启动的旧版等待者仍只等待首槽，新调用自动选择可用槽；不终止或接管现有任务。入口不拦截绕过入口的命令。
+- 在工作区根使用：`& ./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-check.ps1` 及前后端全量入口 `backend-full-regression.ps1`、`frontend-full-regression.ps1` 执行时整批占一个名额，DryRun 不占用。已在入口保护下的批次执行原始命令，不重复申请锁；入口会拒绝嵌套调用，避免互相等待。
+- 按下文“验证范围选择”完成必要检查，不因批次收尾扩大范围；排队也不改变检查范围。复用结果须核对命令、目录和相关源码/依赖/配置；输入变化只作废依赖该输入的结果，补跑受影响检查，不自动重跑整批。交付简述范围、结果和未验证项；不能仅凭时间接近或上次绿灯推定有效。入口仅保存最近摘要，不自动计算快照或跳过测试，也不保证先来先执行。
+- 本机每槽独立保存占用者与最近结果：首槽 `owner.json`、`last-result.json`，第二槽 `owner-2.json`、`last-result-2.json`。只保存检查名称、目录、工具、PID、槽号、时间和退出码，不保存命令参数、凭据或测试输出；名称不得包含秘密。`-Status` 分别展示两槽及总占用，摘要不是业务/部署事实来源。无需凭据，不访问网络、数据库或部署环境；被包装命令原有的网络/写入能力及授权要求不变。
+- 只读检索和互不冲突的编辑可并行；开发服务按应用复用已有实例，不纳入短任务队列，也不通过本入口启动常驻服务。已有运行任务由所属对话收尾；本入口不自动终止它们。
+- 免排队范围仅限离线只读的静态合同：`baiyue-firstleg/scripts/agents-index-contract.ps1`、`scripts/mapper-scan-contract.mjs` 等直接扫描文件的 PowerShell/MJS 脚本；`node --test` 形式的合同测试文件仍属测试。任何 `pnpm test`、`pnpm typecheck`、`pnpm build`、`node --test` 和 `mvn` 命令必须经 `local-check.ps1`，不得以“离线合同”为由绕过。
+
+## 验证范围选择
+
+从本轮差异、修改行为及直接引用确定范围，不把整个工作区已有改动算作本轮任务。各应用命令表是可用命令，不是每轮执行清单。
+
+| 改动 | 默认验证 |
+|---|---|
+| 文案、注释、纯展示字段增删 | 核对差异及模板；已有断言受影响则调整并定向运行，不机械新增测试 |
+| 文件内小逻辑、局部交互 | 覆盖修改分支和必要边界的定向测试，不自动整模块回归、typecheck 或构建 |
+| 类型、签名、接口、模板绑定、模块引用、公共组件或共享逻辑 | 沿符号追踪实际消费者并运行相关测试；类型关系可能受影响时，补覆盖相关生产与测试源码的最小类型检查或编译 |
+| 依赖、打包配置、模块装配 | 按变更选择受影响构建或测试；需要构建不等于同时需要全量测试 |
+| 广泛公共变更或完整集成验收 | 先说明具体影响及定向检查不足的原因，再选择模块/全量范围；未调查清楚不能作为全量理由 |
+
+- 用户明确要求完整回归时按指定范围执行；普通提交、对话结束、触及多个文件或发现他人未提交修改均不触发全量。
+- 权限、金额、库存、状态和并发等关键行为必须覆盖相关边界，但不据此扫描或测试无关业务。定向失败先定位，不自动扩大测试范围。
+- 仅复用编译配置、覆盖文件及相关输入相同的成功结果；构建未覆盖测试源码时，不能替代受影响测试的类型检查。API、Mapper、AGENTS 静态合同按各自触发条件执行；文档改动不触发业务回归。
+
 ## 当前开发阶段
 
 - 项目尚未上线，没有需要兼容的生产存量数据、线上客户端或已发布接口版本；所有代码与契约直接收敛到当前确认目标，用户确认上线或存在不可变外部契约后才重新建立版本兼容和升级规则。
-- 收敛范围包括源码结构、接口与 DTO、字段、状态机、权限、配置键、OpenAPI、数据库结构与初始化 SQL、事件、路由、页面、前端消费者、Mock/Fixture、测试和脚本；旧实现冲突时同步修改全部生产者与消费者并直接删除旧实现。
+- 收敛范围限于本轮目标实际影响的源码结构、接口与 DTO、字段、状态机、权限、配置键、OpenAPI、数据库结构与初始化 SQL、事件、路由、页面、前端消费者、Mock/Fixture、测试和脚本；旧实现与本轮目标冲突时，同步修复实际受影响的生产者与消费者并删除被替代实现。
 - 禁止为旧代码、旧调用或开发环境存量保留旧接口/旧字段别名、兼容分支、双协议、双写、灰度、回滚版本、降级解析、旧行为回退、临时适配层、迁移脚本、回填脚本、清理补偿或新旧版本并行；不得以“稳妥”“兼容历史数据”或“先保留以后删除”为由延迟收敛。
 - 开发环境数据库记录、上传文件、缓存、会话、消息、搜索索引和其他运行状态均可丢弃；正常验证方式是更新最新初始化基线、重新造数或上传，并直接运行受影响回归，不模拟生产迁移。已有历史 SQL 只用于开发追溯，不构成兼容依据。
 - 后端位于独立 Git 仓库 `../baiyue-firstleg/`，执行 Git 命令前确认当前工作目录。“无需兼容、直接修复”不授权自动重置数据库、删除数据/文件、执行 SQL、部署或修改环境。测试环境授权只读 `独立任务协作登记.md`，开发全流程授权只读 `开发环境独立任务协作登记.md`；未登记任务和生产环境仍需用户在当前轮明确授权。
@@ -28,25 +56,25 @@
 ## 联调、部署与数据库
 
 - 默认只准备代码、验证结果和人工部署步骤，不触发 Jenkins、不启动本地 Java/Nacos/数据库。开发全流程总控可按 `开发环境独立任务协作登记.md` 的授权操作开发数据库、部署开发环境并执行开发环境真实 HTTP；登记专项可按 `独立任务协作登记.md` 的持续授权查询和修改用户指定的测试数据库。两类授权不得跨环境复用，也不得自动扩大到 Jenkins 或生产环境。
-- 只有用户在当前轮明确授权指定环境、服务和提交时，才可部署或执行 HTTP 验收；测试数据库的读写例外仅适用于登记表中已持续授权的总控与专项，并遵守其中的职责和破坏性操作门禁。
+- 只有用户在当前轮明确授权指定环境、服务和提交时，才可部署或执行 HTTP 验收；同一环境和服务的非破坏性写入可复用本轮授权，删除、重置、执行 SQL、部署或发布仍逐项授权。测试数据库的读写例外仅适用于登记表中已持续授权的总控与专项，并遵守其中的职责和破坏性操作门禁。
 - 环境地址、凭据和 Token 不写入源码或 `AGENTS.md`。接口不可用或契约不一致时记录路径、状态、错误码、`requestId`/`traceId` 和阻断原因，不回退到模拟成功。
 - 测试环境联调、部署和验收命令读取 `测试环境Jenkins部署指南.md`；开发全流程只按 `开发环境独立任务协作登记.md` 的授权与目标项目指引执行，不把测试 Jenkins 流程当作开发部署入口。
 
 ## 通用工程与质量门禁
 
 - 对外 API 新增、改名、删除或访问域变化，以“调用端实际路径（含 API Base）→ 对应区域 Gateway → Controller → OpenAPI → 权限”作为一个交付单元；不能只在修改网关文件时才检查注册。已被正确通配路由覆盖时无需重复添加路由，内部服务令牌接口不得为通过检查而公开。
-- 提交前运行 `node --test scripts/gateway-route-contract.test.mjs` 及受影响服务/调用端的定向测试；路由合同失败不得提交或声称完成。该离线合同检查源码映射、目标服务及内部路径隔离，不代替权限、HTTP 方法、运行时 Nacos 或真实 HTTP 验收；前端 Mock 测试、类型检查及服务单测通过也不证明网关可达。
+- 仅对外 API 路径/访问域新增、改名、删除或 Gateway 路由配置变化时，运行 `node --test scripts/gateway-route-contract.test.mjs` 及受影响服务/调用端测试；命中的路由合同失败不得声称完成。纯文案、内部逻辑和路径未变的前端消费不触发。该离线合同不代替权限、HTTP 方法、运行时 Nacos 或真实 HTTP 验收。
 - 交付列明变更接口、路由是否复用或新增、验证结果及部署单元；Gateway 配置变化必须包含对应网关，Nacos 配置变化单独说明发布项。没有环境授权时只交付代码和待验收说明，不自动部署、发布配置或调用真实 HTTP。
 
-- 保持变更小而聚焦，遵循目标项目现有命名、分层和格式，不顺手重构无关代码。
+- 修改范围与停止条件遵循[工作区根指引](../AGENTS.md#修改范围与停止条件)，保持目标项目现有命名、分层和格式。
 - 优先复用现有依赖和公共能力；新增或升级依赖前说明必要性、影响范围和替代方案。
 - 不提交依赖目录、构建产物、运行日志、编辑器缓存或本地临时文件；不写入密钥、令牌、真实客户数据或环境特定地址。
 - 用户可见文案保持清晰一致；代码标识符使用英文，业务说明和文档可使用中文。
-- 仅运行目标项目实际声明的安装、检查、测试和构建命令。每次变更至少验证直接受影响的项目，跨项目变更还要验证对应消费者。
+- 仅运行目标项目实际支持的检查命令，按上文选择最小有效范围；“验证受影响项目”不等于运行该项目全部命令。
-- 修改方法、构造器、组件 Props、函数、接口、DTO 或请求/响应参数时，定向检索全部生产调用、测试调用、Mock、Fixture、契约测试和脚本引用，并同步修改。
+- 签名、组件 Props、接口/DTO、请求响应结构或影响调用方的行为变化时，用 `rg` 按变更符号核对直接生产调用、测试、Mock、Fixture、契约测试与脚本；只修改实际受影响的引用，必要时沿直接依赖继续追踪。仅内部实现调整且调用契约与对外行为未变时，验证受影响逻辑，不自动修改调用方、Mock、Fixture 或文档。
 - 参数或类型签名变化必须运行会编译测试源码的最小检查；无法验证时明确列出未验证范围。
-- 修复缺陷优先增加复现测试；没有现成测试设施时不为小改动引入整套框架，应记录验证步骤和剩余风险。
+- 行为缺陷优先用已有测试复现，缺失时补必要用例；文案和纯展示不机械新增测试，不为小改动引入框架。
-- UI 变更按受影响范围检查加载、空态、错误态、权限、目标视口和可访问性；Admin/Client 视觉细则查 `Admin-Client前端原型还原验收规则.md` 和目标应用指引。
+- UI 只检查本轮影响的状态与交互，不机械遍历加载、空态、错误态和权限；布局或承载方式变化再按前端验收规则核对对应视觉证据。
 - 需求、技术栈或接口未确认时停在可逆设计阶段，不自行作出高成本平台决策。
 
 ## 独立任务与多任务协作

Admin-Client前端原型还原验收规则.md

@@ -2,68 +2,53 @@
 
 ## 目标
 
-Admin 与 Client 已向客户讲解或确认过的页面，必须以对应原型为直接事实来源逐页还原。不得先统一套用现有设计系统、抽屉、弹框、详情页或图标规范，再局部调整。
+本文只维护逐操作核对方法、验收范围和证据要求。Admin 当前样式的唯一依据为 [Admin 界面规范](Admin高密度界面规范.md)；Client 新增、新建、下单的通用外观按 [Client 界面样式规范](Client界面样式规范.md) 的“新增页面”章节，其他操作读取该规范的适用条款和已确认原型，不自动采用 Admin 风格。本文不重复定义配色、密度、按钮或弹窗尺寸。
+
+页面业务字段、顺序、分组和操作承载以当前业务契约及逐操作确认为准；已有原型作为直接核对证据。Admin / Client 主规范已经确认替代的外观使用对应现行规则，其余差异逐项记录，不因套用公共组件而改动承载方式。
 
 ## 修改门禁
 
-每个页面修改前必须先形成以下矩阵，并给出原型文件及行号、元素 ID、函数名或截图证据：
+新页面、整体视觉还原、布局重排或页面/弹框/抽屉承载变化，才对受影响操作形成以下矩阵，并给出原型或用户截图依据。文案、单个展示字段增删、局部逻辑及不改变承载方式的小调整，直接核对差异，不要求矩阵、完整原型检索或全页面验收：
 
 | 页面 | 操作 | 原型承载方式 | 原型尺寸/布局 | 当前实现 | 结论 |
 |---|---|---|---|---|---|
 | 示例 | 详情 | 独立页面 | 页面级头部、返回列表 | 右侧抽屉 | 改为正式路由页面 |
 
-操作至少分别核对：详情、新增、编辑、审核/确认、文件预览、删除/停用确认。不得以其中一个操作的结论推断其他操作。
+只核对本轮受影响操作，不机械遍历详情、新增、编辑、审核、预览和删除；不得用一个操作的结果推断其他操作已通过。
 
 ## 承载方式
 
 - 原型使用独立页面：必须使用正式路由、页面级布局和明确返回入口；不得改成抽屉或弹框。
-- 原型使用居中弹框：必须使用居中模态框，并按原型宽度、标题、正文、底部按钮和关闭方式还原；不得改成右侧抽屉。
+- 原型使用居中弹框：必须使用居中模态框，核对标题、正文、底部按钮和关闭方式；Admin / Client 外观分别按各自现行样式规范和已确认业务例外，承载尺寸按对应操作确认，不得改成右侧抽屉。
 - 原型使用侧滑面板：仅该操作允许使用抽屉，并按原型方向、宽度和内部布局还原。
 - 原型未定义：先停在矩阵中标记待确认，不得因为公共组件方便而自行选择。
 - 同一列表的详情、新增、编辑、审核可以采用不同承载方式，必须逐操作判断。
 
 ## 视觉与排版
 
-- 字段顺序、分组、摆放、列宽、控件宽高、换行、对齐、外边距、内边距、间隙和留白按原型逐项核对。
+- Admin 按 [主规范任务入口](Admin高密度界面规范.md#按任务阅读)选择对应章节核对；Client 按 [样式规范](Client界面样式规范.md) 的适用章节及对应操作原型逐项核对。矩阵标明当前依据及业务例外，不把旧试点和过程记录当成另一套通用规则。
-- 顶部背景色、页面背景、区块背景、边框、圆角、阴影、字号、字重和文字颜色直接取原型值。
+- 核对字段分组、列宽、换行、对齐、控件、表格、按钮及图标；保留原型的业务语义和操作资格。主规范未授权的装饰、功能与交互不得自行添加。
-- 按钮位置、顺序、尺寸、颜色、危险语义、悬停态、禁用态按原型还原；不得自行增加“更多”菜单或纯文字替代。
+- 长编号、长地址、长文件名、多字段、空值和业务状态使用真实形态的数据核对；不能靠缩小字号、裁切关键值或减少字段通过验收。
-- 原型已提供图标、字符图标、图片或 SVG 时直接复用原型资源；不得自行绘制或替换。
-- 表格按原型核对外边框、单元格边框、表头背景、斑马纹、行悬停背景、行高和横向滚动。
-- 原型没有的公司名称图标、下划线、卡片装饰、悬停上浮、缩放和渐变效果不得添加。
-
-### Admin 已确认布局基线
-
-- 订单样板及国内仓样式统一采用 [Admin 高密度界面规范](Admin高密度界面规范.md)。其已确认的密度、容器和页签图标规则优先于历史原型中的对应视觉；字段、业务分组、权限、操作语义与页面/弹框/抽屉承载方式继续逐操作核对。该规范不表示其他页面已完成验收。
-- Admin 是高信息密度业务系统。保留原型字段、顺序、业务分组和交互语义，但普通短字段优先使用连续白底、多列键值网格、描述表或紧凑列表，不把“一个标签 + 一个值”做成独立卡片。
-- 详情页顶部尽量合并返回、标题、核心状态和主要操作；路由壳层已显示标题时正文不重复。状态或流程结论只保留一个主要视觉落点，除真实错误、阻断或危险外不叠加大面积彩色横幅。
-- 在 `1920×1080` 下短字段通常并排 `4–6` 组；长文本、地址、备注和异常原因可以跨列或换行。长编号集中省略说明列宽设计失败，应调整列数、宽度或跨列，不继续缩小字号。
-- 同一详情页使用一致的内容底色和容器语言；连续白底区域用分隔线和间距分区，同级独立卡片的背景、圆角、边框和外间距保持一致。
-- 高信息密度不授权缩小可点击区域、删除标签、强制截断关键值或牺牲可访问性。使用真实长编号、空值、状态徽标和多字段数据核对首屏。
-- 原型明确的承载方式和视觉细节优先；历史原型仅因大量字段卡片、重复状态块或过度留白与当前密度基线冲突时，收敛承载方式但不改变字段、分组和交互语义。
 
 ## 响应式与可访问性
 
 - Admin、Client 当前只按 `1920×1080`、浏览器缩放 `100%` 验收；不检查或整改 `720px`、`320px` 等窄屏，也不删除已有响应式能力。用户恢复多视口验收后再统一调整。
 - 弹框正文超过视口时只滚动正文，标题和操作区保持可见；独立详情页按正常页面滚动。
-- 字段数量较多、两列会导致弹框明显过高时，在 `1920×1080`验收视口下改用宽版三列表单；短字段单列占位，地址、长文本、备注、文件和表格按内容跨列或整行。小型确认类弹框不因此扩宽。
+- 弹窗尺寸和字段列数按当前样式依据及业务例外核对，不在验收阶段另设通用尺寸；核对长正文、校验错误、附件和底栏是否可用。
 - 保留键盘操作、焦点、表单标签、图标按钮名称和足够对比度。可访问性调整不得改变原型的主要布局与视觉语义。
 
 ## 执行与验收
 
-1. 先提交逐页矩阵，不直接批量替换公共组件。
+1. 仅满足上述矩阵触发条件时记录受影响操作；局部小改直接核对差异，不批量替换公共组件。
-2. 总控冻结该页结论后，任务只修改职责内模块，不触碰其他任务在途文件。
+2. 按当前对话确认的范围修改目标模块，保留其他任务在途改动；存在总控协作时沿已冻结结论执行，不因普通样式任务额外创建总控流程。
-3. 修改后由人工在 `1920×1080`、`100%` 缩放下操作并提供截图，标注与原型仍存在的差异；缺少截图时记录“待人工截图确认”，AI 不自行批量取证。
+3. 需要视觉验收的布局/承载变化，由人工在 `1920×1080`、`100%` 缩放下提供受影响操作截图；缺少时记“待人工截图确认”，AI 不批量取证。文案、小逻辑和局部展示改动不以重新提交整页截图作为代码交付门禁，不据此宣称已通过视觉验收。
-4. 运行直接测试与类型检查；共享组件变更必须检查全部消费者。
+4. 按 `AI工程执行与协作约束.md` 的“验证范围选择”执行最小有效检查，不因页面修改自动全量测试、类型检查或构建；需要的重型检查经过 `local-check.ps1`。共享组件核对实际消费者，公共浮层选择器变化覆盖受影响的嵌套、Teleport、工具栏及全屏场景。
 5. 不触发 Jenkins、不部署、不提交，除非当前对话另有明确授权。
 
-## 已确认示例
+已改造弹框回看时，复用原固定编号清单，从本轮确定的当前项逐个处理，不另建全量清单、不重排编号。单项流程为“原改造记录与当前代码核对 → 实际截图核对 → 明确保留项和必要局部修正 → 有修改时完成相应代码检查 → 本项人工确认 → 下一项”。缺少截图时只记录源码事实与待核对项，不声称视觉通过；本项未确认前不并行修改后续弹框。复杂窗口的分栏、步骤、树表、预览与已确认尺寸分别核对，不按普通表单模板统一重排。
 
-Admin 客户管理原型：
+## 证据记录
 
-- 客户详情：独立页面（`page-tenant-detail`）。
+逐操作矩阵记录：页面／路由、具体操作及承载方式、原型或用户确认依据、采用的主规范章节／业务例外、自动检查结果和人工截图结论。各模块复用现有记录，不另建一份全端进度副本。示例原型的尺寸不覆盖当前已确认的业务尺寸。
-- 新增客户：居中宽版弹框（`modal-tenant-add`，宽度约 1120px），基础资料和联系与商务使用三列，地址、备注和资质表格整行。
-- 编辑客户：复用新增客户的居中宽版三列弹框（`modal-tenant-edit`，宽度约 1120px）。
-- 重置密码：居中弹框（`modal-tenant-reset-password`，宽度约 520px）。
-- 入驻审核：居中弹框（`modal-tenant-audit`，宽度约 900px）。
 
-这些结论只适用于上述操作，不自动推广到其他页面。
+人工核对独立打开／刷新、列表到详情、页签切换、长内容、宽表、空态、部分数据、失败与重试、只读／无权限及浮层普通／全屏／关闭重开。自动检查不能证明浏览器像素布局和实际滚动已通过。

Admin列表样式推广核对记录.md

@@ -0,0 +1,136 @@
+# Admin 列表样式推广核对记录
+
+> 文档职责：仅维护模块范围、业务例外与检查／截图记录。通用样式统一以 [Admin 界面规范](Admin高密度界面规范.md) 为准；下文日期批次中的旧外观不再作为新改造要求。普通样式任务只在涉及本模块范围、例外或验收证据时查阅本文。
+
+## 本轮依据与边界
+
+2026-10-21 后续视觉确认：列表页签对齐与灰白斑马纹以[蓝白工作台当前规范](界面参考/蓝白卡片式工作台风格参考.md#视觉基线与维护入口)为准；下文“无斑马纹”为此前批次实现记录，不再作为接入要求。
+
+2026-09-30，用户确认排车列表样式后授权按客户管理、国内仓、货柜管理、海外仓顺序推广；特殊页面保留待人工确认。直接视觉依据为本轮截图 `41fea1ee-f30a-46db-97b0-82ec96846ec7/image-1.png` 与 [排车样板](Admin排车列表样式试点.md)。仅修改测试环境工作区 `apps/admin-web`，不部署或发布。
+
+统一布局：左侧列表名称、右侧原业务按钮与字段设置，搜索和表格位于同一连续卡片。仅列表操作列采用蓝色普通文字、红色危险文字、悬停无下划线；查询、顶部、弹框按钮不变。列显隐、排序和拖动宽度使用公共浏览器偏好存储。保持所有业务字段、状态、权限和事件，不改变详情、新增、编辑、审核、文件预览与删除确认的承载方式。
+
+## 修改前页面与操作矩阵
+
+以下实现路径均相对 `apps/admin-web/src/modules/`。列表变化依据上述截图；其它操作以现有组件和事件为核对入口，保持原样，未定义的新承载方式不在本轮引入。
+
+| 模块 | 页面 / 入口 | 当前实现与操作证据 | 本轮结论 |
+|---|---|---|---|
+| 客户管理 | 客户列表 `/customers` | `customers/pages/CustomersView.vue`：`customerRowActions`、`handleCustomerRowAction`、`openCreate`，客户详情路由及编辑/审核/重置密码弹框 | 接入连续列表；详情、新增、编辑、审核、资质与确认操作保持 |
+| 客户管理 | 海外仓阶梯费用 | `customers/pages/OverseasStorageFeesView.vue`：`openEdit`、`save`，费用编辑 AppDialog | 接入连续列表；费用编辑弹框保持 |
+| 国内仓 | 订单列表 | `unified-orders/pages/UnifiedOrdersView.vue`：状态页签、`unifiedOrderRowActions`、详情分支及批量审核、导入、扣货与文件入口 | 仅列表分支接入；详情和各弹框保持 |
+| 国内仓 | 订单测量 / 测量数据审核 | `inbounds/components/InboundTaskList.vue`：`taskLabel`、客户查询警告、测量和审核选择事件 | 两个路由共用列表接入；作业弹框和确认保持 |
+| 国内仓 | 预装清单 | `loading-lists/components/LoadingListsView.vue`：`mode`、列表权限判断、清单行操作、详情导航 | 接入连续列表；权限错误态和详情保持 |
+| 国内仓 | 库位管理 | `warehouse-resources/locations/pages/LocationsView.vue`：仓库加载与列表分别失败、编辑与删除确认 | 接入连续列表；独立错误提示、维护弹框和确认保持 |
+| 国内仓 | 托盘管理 | `warehouse-resources/pallets/pages/PalletsView.vue`：仓库加载、新增/编辑/停用/删除行操作 | 接入连续列表；维护弹框和确认保持 |
+| 国内仓 | 整柜业务 | `domestic-containers/pages/DomesticContainersView.vue`：入库/出库/库存页签、库存汇总及维护入口 | 三个视图共用连续列表，页签、汇总和原操作保持 |
+| 国内仓 | 船期日历 | `sailing-calendar/pages/SailingCalendarView.vue`：日历和渠道/模板/船期管理工作区 | 保留现状；日历布局待人工确认 |
+| 货柜管理 | 订舱列表 | `ocean-bookings/pages/OceanBookingsView.vue`：列表查询、行操作和订舱资料入口 | 接入连续列表；新建、编辑、详情、放舱及文件保持 |
+| 货柜管理 | 拖车列表 | `trucking/pages/TruckAppointmentsView.vue`：拖车查询和行操作 | 接入连续列表；创建、编辑、详情和确认保持 |
+| 货柜管理 | 送柜报关 / 清关提柜 | `container-loading/pages/ContainersView.vue`：`workbench` 双模式、在途/历史页签、行操作、预计到仓维护 | 两个工作台共用列表接入；所有详情、节点、订舱、资料、邮件和确认保持 |
+| 海外仓 | 尾程订单 | `overseas-warehouse/pages/LastMileOrdersView.vue`：普通列表与柜子工作台分支、行操作和柜级计划弹框 | 普通列表可接入；柜子工作台保留业务结构并单独核对 |
+| 海外仓 | 入库单 | `overseas-warehouse/pages/InboundOrdersView.vue`：预约、行操作及详情 | 接入连续列表；预约和详情保持 |
+| 海外仓 | 海外库位 | `overseas-warehouse/pages/LocationsView.vue`：普通/A0/虚拟库位资格和维护操作 | 接入连续列表；受保护资格和确认保持 |
+| 海外仓 | 排车列表 | `overseas-warehouse/pages/DispatchesView.vue` 已确认样板 | 保留样板；字段设置和列宽偏好保持 |
+| 海外仓 | 出库单 | `overseas-warehouse/pages/OutboundsView.vue`：按类型新建、取消、出库详情和选择作业弹框 | 仅主列表接入；新建候选及各弹框保持 |
+| 海外仓 | 派送单 | `overseas-warehouse/pages/DeliveryOrdersView.vue`：行操作、资料汇总和签收入口 | 接入连续列表；签收、详情和资料保持 |
+| 海外仓 | 换标单 | `overseas-warehouse/pages/RelabelOrdersView.vue`：新增、详情与编辑入口 | 接入连续列表；表单与详情保持 |
+| 海外仓 | 托盘管理 | `overseas-warehouse/pages/PalletsView.vue`：详情、单张打印及原维护入口 | 接入连续列表；打印尺寸和其它操作保持 |
+| 海外仓 | 库存管理 | `overseas-warehouse/pages/InventoryView.vue`：库存汇总、导出、详情和行操作 | 接入连续列表；汇总数据、导出及详情保持 |
+| 海外仓 | 退货库存 / 退货箱号 | `overseas-warehouse/pages/ReturnInventoryManagementView.vue` 两种 `mode` | 沿实际公共列表组件接入；明细和作业保持 |
+| 海外仓 | 进销存记录（关联入口） | `overseas-warehouse/pages/InventoryTransactionsView.vue`：只读边界提示、关系查询、导出 | 接入连续列表；只读边界与关系查询保持 |
+
+## 本轮实现与待确认项
+
+客户管理 2 个、国内仓 7 个、货柜管理 4 个、海外仓 11 个菜单列表已接入；另外接入海外库存关联的进销存记录，共 25 个列表入口（含原排车样板）。包装页面继续复用实际公共列表组件；整柜的三种业务页签、测量与审核双模式、货柜国内/海外双工作台、尾程订单隐藏柜子工作台和退货库存/流水/箱号分支均保留。
+
+船期日历 `/sailing-calendar` 保留原样。日历与渠道/模板/船期管理工作区不等同于标准业务列表；需要人工确认顶部按钮、查询及日历的排列，再决定如何接入。本轮没有隐藏或移除该入口。
+
+尾程订单隐藏柜子工作台仍保留自身卡片与分页，通过公共 `results` 插槽承载。修正了共享表格在自定义工作台或列表加载失败时重置页码的问题；普通列表继续使用原服务端分页。
+
+新增页面的视觉均待人工在 1920×1080、100% 缩放下截图确认；样板截图不代表其余页面视觉已验收。重点核对页签、多字段查询、长编号横向滚动、汇总、危险文字、每页数量、字段显隐及拖动后刷新列宽。
+
+## 验证记录
+
+客户管理相关回归 9 个文件、120 项通过；特殊工作台、公共表格和其它受影响回归 7 个文件、180 项通过。源码审计确认已接入页面的原业务点击事件全部保留；除退货列表增加列配置与公共表格导入外，业务脚本保持不变，API 和权限没有修改。退货库存/流水/箱号增加行为回归，覆盖搜索分页、偏好隔离与详情入口。
+
+2026-09-30 最终完整 `pnpm test`：263 个文件、2131 项全部通过。`pnpm build`（包含 `vue-tsc --noEmit`）通过。仅修改本地测试环境代码；未提交、未部署或发布。
+
+
+## 第二批修改前页面与操作矩阵（2026-09-30）
+
+用户授权继续客户服务、海外仓、财务管理、通用、系统管理等剩余页面；沿当前菜单扩展海外业务和消息入口。上一批海外仓标准列表复核并保持。隐藏原型菜单不启用，首页数据看板不是列表，保留并记录待人工确认。
+
+本批仍只改变主列表布局和操作列外观。下列实现路径相对 `apps/admin-web/src/modules/`；详情、新建、编辑、审核、文件预览、打印及删除/停用确认仍沿原组件、路由和事件，不引入新承载方式。视觉依据与第一批相同。
+
+| 模块 | 页面 / 路由 | 当前列表实现及操作核对入口 | 结论 |
+|---|---|---|---|
+| 客户服务 / 通用 | 异常订单 `/overseas-warehouse/exception-orders` | `overseas-warehouse/pages/ExceptionOrdersView.vue`：toolbar-actions、actions、related、handlerName、status、pagination-left；原详情/表单/确认保持 | 接入公共连续列表；业务展示与操作保持 |
+| 客户服务 / 通用 | 客户回访 `/overseas-warehouse/customer-visits` | `overseas-warehouse/pages/CustomerVisitsView.vue`：actions、status、pagination-left；原详情/表单/确认保持 | 接入公共连续列表；业务展示与操作保持 |
+| 客户服务 / 通用 | 称重机器 `/general/mojia-sku-sync` | `overseas-warehouse/pages/MojiaSkuSyncView.vue`：toolbar-start、toolbar-actions、actions、sourceCode、kind、image、dimensions、syncStatus、match、measuredAt、failure；原详情/表单/确认保持 | 接入公共连续列表；业务展示与操作保持 |
+| 海外业务 | 海外采购订单 `/overseas-business/purchases` | `overseas-business/pages/PurchaseOrdersView.vue`：actions、pagination-left；原详情/表单/确认保持 | 接入公共连续列表；业务展示与操作保持 |
+| 海外业务 | 本土卡车 `/overseas-business/trucks` | `overseas-business/pages/TransportOrdersView.vue`：toolbar-actions、actions、pagination-left；原详情/表单/确认保持 | 接入公共连续列表；业务展示与操作保持 |
+| 海外业务 | 本土散板 `/overseas-business/looseboards` | `overseas-business/pages/TransportOrdersView.vue`：toolbar-actions、actions、pagination-left；原详情/表单/确认保持 | 接入公共连续列表；业务展示与操作保持 |
+| 财务管理 | 客户账户 `/finance/customer-accounts` | `finance/pages/FinanceCustomerAccountsView.vue`：toolbar-actions、actions、customerName、customerCode、contactName、contactPhone、lastChangedAt、actualBalance、frozenBalance、availableBalance、creditLimit、creditExpiresOn、creditUsed、pendingRechargeCount、status、pagination-left；原详情/表单/确认保持 | 接入公共连续列表；业务展示与操作保持 |
+| 财务管理 | 客户应收应付 `/finance/customer-arap` | `finance/pages/FinanceCustomerArapView.vue`：toolbar-actions、actions、customerName、direction、businessReference、sourceType、supplierName、sourceStatus、status、generated、businessDate、pagination-left；原详情/表单/确认保持 | 接入公共连续列表；业务展示与操作保持 |
+| 财务管理 | 应收款统计表 `/finance/receivable-statistics` | `finance/pages/FinanceReceivableStatisticsView.vue`：toolbar-actions、customerName、totalReceivable、totalReceived、totalOutstanding、pagination-left；原详情/表单/确认保持 | 接入公共连续列表；业务展示与操作保持 |
+| 财务管理 | 客户对账单 `/finance/customer-statements` | `finance/pages/FinanceCustomerStatementsView.vue`：toolbar-actions、actions、status、customerConfirmationStatus、customerName、lastPaymentAt、settled、createdByName、createdAt、submittedAt、reviewedAt、issuedAt、customerConfirmedByName、customerConfirmedAt、updatedByName、updatedAt、pagination-left；原详情/表单/确认保持 | 接入公共连续列表；业务展示与操作保持 |
+| 财务管理 | 结算单应收 `/finance/settlement-receivables` | `finance/pages/FinanceSettlementReceivablesView.vue`：包装页，实际列表为 FinanceFormalSettlementPage 的 kind 双模式；原详情/表单/确认保持 | 接入公共连续列表；业务展示与操作保持 |
+| 财务管理 | 结算单应付 `/finance/settlement-payables` | `finance/pages/FinanceSettlementPayablesView.vue`：包装页，实际列表为 FinanceFormalSettlementPage 的 kind 双模式；原详情/表单/确认保持 | 接入公共连续列表；业务展示与操作保持 |
+| 通用 | 供应商列表 `/suppliers` | `suppliers/pages/SuppliersView.vue`：toolbar-actions、actions、name、category、truckingScope、carrierCodes、license、status、settlement；原详情/表单/确认保持 | 接入公共连续列表；业务展示与操作保持 |
+| 通用 | 快递公司 `/master-data/express-companies` | `master-data/express-companies/pages/ExpressCompaniesView.vue`：toolbar-actions、actions、company、website、status、empty、pagination-left；原详情/表单/确认保持 | 接入公共连续列表；业务展示与操作保持 |
+| 通用 | 往来单位 `/master-data/counterparties` | `master-data/counterparties/pages/PartnersView.vue`：toolbar-actions、actions、partner、type、address、status、pagination-left；原详情/表单/确认保持 | 接入公共连续列表；业务展示与操作保持 |
+| 通用 | 费用项目 `/master-data/fee-items` | `fee-items/pages/FeeItemsView.vue`：toolbar-actions、actions、feeItem、tradeScope、pickup、warehouse、supplierCategory、allocationFee、description、status、empty、pagination-left；原详情/表单/确认保持 | 接入公共连续列表；业务展示与操作保持 |
+| 通用 | 海外仓报价 `/overseas-master-data/quotes` | `overseas-master-data/pages/OverseasQuotesView.vue`：toolbar-actions、actions、status；原详情/表单/确认保持 | 接入公共连续列表；业务展示与操作保持 |
+| 通用 | 汇率管理 `/overseas-master-data/exchange-rates` | `overseas-master-data/pages/ExchangeRatesView.vue`：toolbar-actions、actions、conversion、status；原详情/表单/确认保持 | 接入公共连续列表；业务展示与操作保持 |
+| 通用 | 车辆列表 `/overseas-master-data/vehicles` | `overseas-master-data/pages/VehiclesView.vue`：toolbar-actions、actions、status、region；原详情/表单/确认保持 | 接入公共连续列表；业务展示与操作保持 |
+| 通用 | 仓库管理 `/warehouses` | `warehouses/pages/WarehousesView.vue`：toolbar-actions、actions、warehouse、warehouseType、countryCode、address、contact、status、pagination-left；原详情/表单/确认保持 | 接入公共连续列表；业务展示与操作保持 |
+| 通用 | 船期价格表 `/first-leg-pricing/carrier-rates` | `fba-pricing/carrier-rates/pages/CarrierRatesView.vue`：toolbar-actions、actions、version、scope、status、contents、issues、empty、pagination-left；原详情/表单/确认保持 | 接入公共连续列表；业务展示与操作保持 |
+| 通用 | 下载中心 `/downloads` | `downloads/pages/DownloadCenterView.vue`：pagination-left、actions、type、status、progress、requester、requestedAt、completedAt、expiresAt；原详情/表单/确认保持 | 接入公共连续列表；业务展示与操作保持 |
+| 系统管理 | 用户管理 `/system/users` | `iam/pages/InternalUsersView.vue`：toolbar-actions、actions、roles、status、lastLoginAt、pagination-left；原详情/表单/确认保持 | 接入公共连续列表；业务展示与操作保持 |
+| 系统管理 | 角色权限 `/system/roles` | `iam/pages/RolesView.vue`：toolbar-actions、actions、role、permissionSummary、roleType、status、pagination-left；原详情/表单/确认保持 | 接入公共连续列表；业务展示与操作保持 |
+| 系统管理 | 菜单权限 `/system/permissions` | `iam/pages/PermissionsView.vue`：toolbar-start、toolbar-actions、actions、name、code、endpoint、status、pagination-left；原详情/表单/确认保持 | 接入公共连续列表；业务展示与操作保持 |
+| 系统管理 | PDA版本 `/system/pda-releases` | `pda-releases/pages/PdaReleasesView.vue`：toolbar-start、toolbar-actions、actions、app、packageType、status、mandatory、sizeBytes、createdAt、publishedAt；原详情/表单/确认保持 | 接入公共连续列表；业务展示与操作保持 |
+| 消息入口 | 我的消息 `/notifications` | `notifications/pages/PlatformNotificationsView.vue`：toolbar-actions、pagination-left、actions、category、sentAt、status；原详情/表单/确认保持 | 接入公共连续列表；业务展示与操作保持 |
+| 消息入口 | 消息管理 `/notifications/messages` | `notifications/pages/MessageManagementView.vue`：toolbar-actions、pagination-left、actions、category、scheduledAt、sentAt、status；原详情/表单/确认保持 | 接入公共连续列表；业务展示与操作保持 |
+| 消息入口 | 模板管理 `/notifications/templates` | `notifications/pages/MessageTemplatesView.vue`：toolbar-actions、pagination-left、actions、status；原详情/表单/确认保持 | 接入公共连续列表；业务展示与操作保持 |
+
+应收款统计保留月份、客户筛选、汇总、CNY 边界、打印/导出及原打印媒体规则；权限树保留展开、收起、保护提示和树形参数；PDA 版本保留国内/海外应用切换、当前版本事实和发布/停发确认；称重机器保留现有筛选、连接测试、人工推送和分页。这些页面沿实际结构单独处理，不删功能套标准模板。
+
+第二批新增 29 个列表路由，复用 27 个实际列表组件；两个结算单包装路由继续复用 `FinanceFormalSettlementPage`，应收/应付各自保存字段和列宽偏好，本土卡车/散板继续共用原运输订单列表。菜单核对覆盖当前全部正式可见业务列表，加上三个消息入口与库存流水关联入口，共 54 个接入入口；未发现遗漏。隐藏原型菜单保持隐藏。
+
+称重机器从独立 Element 分页改为公共表格分页，保留原 10/20/30/40/50/100 选项、服务端分页和查询条件。新增行为回归验证查询及每页数量变化回到第一页、每页数量变化仅发送一次查询、字段设置可用、列宽重新挂载恢复和原操作入口。PDA 与称重机器原加载中的 `aria-busy` 状态随列表保留。
+
+源码核对确认第二批全部原点击表达式和业务脚本保留，仅清理已移除的装饰图标导入；未修改 API、权限、计算规则、状态或详情/表单承载方式。旧样式断言同步到连续卡片、通知区、纯文字“更多”和无斑马纹；原业务断言继续保留。
+
+## 第二批异常及待确认清单
+
+| 项目 | 当前处理 | 后续确认 |
+|---|---|---|
+| 首页数据看板 `/dashboard` | 保留原工作区，未套列表布局 | 人工确认是否需要独立调整看板顶部 |
+| 船期日历 `/sailing-calendar` | 已按用户截图制作连续工作台版本，保留日历及渠道/模板/船期工作区 | 待人工确认新版按钮、查询与日历排列；见单页收尾记录 |
+| 财务统计/打印、结算汇总、权限树、PDA应用切换、供应商分类及尾程柜子工作台 | 沿原结构接入，保留全部业务控件；自动检查通过 | 人工重点核对汇总、页签、树展开、打印和条件切换 |
+| 所有新增页面真实视觉 | 未使用 AI 操作页面或截图替代验收 | 待人工 1920×1080、100% 缩放截图确认 |
+| 完整测试中的 Vue 编译提示 | 出现 `v-model` 对 `const reactive query` 的非阻断提示；完整测试及构建通过，本轮未扩展修改 | 后续专项核查对应绑定 |
+
+## 第二批验证结果
+
+2026-09-30 完整 `pnpm test`：264 个文件、2133 项全部通过。`pnpm build`（包含 `vue-tsc --noEmit`）通过，`git diff --check` 通过。菜单/包装组件核对和原操作事件审计通过。所有修改均在本地测试环境工作区；未提交、未部署或发布。视觉验收仍待人工截图确认。
+
+## 船期日历单页收尾（2026-09-30）
+
+用户提供当前页面截图 `codex-clipboard-e64ee273-3108-4711-be25-f63785611e59.png`，授权按上述建议制作一版。仅处理测试环境的船期日历；首页数据看板和其它待确认页面留到后续逐页处理。
+
+| 操作 | 截图/当前代码依据 | 本版结论 |
+|---|---|---|
+| 页头、筛选、日历与当日船次 | 截图显示独立筛选、日历、当日详情卡片；`SailingCalendarView.vue` 的 `calendar-toolbar`、`calendar-layout` | 共用连续容器；左标题/右业务按钮，下面筛选与日历/当日详情；保留月切换、今天、时区和船期数量 |
+| 查询与重置 | 原筛选字段绑定、下拉自动查询、关键字回车及 `resetFilters` | 全部保留，重置仍在筛选区 |
+| 单次新增/编辑 | 原 `dialogOpen` 居中 760px 表单及 `openCreate`/`openEdit` | 保留原表单与承载方式；页头保留新增单个船次，当日详情新增仍保留 |
+| 渠道与周模板/批量生成 | 原 `openManagement` 居中管理工作区 | 按钮移到页头右侧；内部管理表格、生成步骤及权限保留 |
+| 船次详情、货量明细、历史、订柜建议 | 原右侧详情、`openVolumeDetail`/`openHistory`/`openBookingAdvice` | 保留原交互和浮层，只合并外层卡片 |
+| 复制、取消及批量生成确认 | 原 `copySelected`、`cancelSelected`、`confirmTemplateGeneration` | 原权限、确认、处理中和提示保留；不改业务状态 |
+| 文件预览/审核 | 本页面无此类独立入口 | 不新增 |
+
+公共页头及筛选沿 `DataTable appearance="integrated"` 的 `results` 插槽接入日历工作台；无列表列配置，不展示字段设置或虚构分页。日期格紧凑排列，保留日期、数量、航线和容量提示。修改后的视觉待人工在 1920×1080、100% 缩放下截图确认。
+
+本版验证：公共表格与密度合同 51 项通过；新增船期日历行为回归 2 项通过，覆盖月切换、日期/船次选择、关键字查询、重置、失败重试及只读权限。源码审计确认除公共组件导入外业务脚本未变，全部事件和查询绑定保留。完整测试 265 个文件、2135 项通过，构建（含类型检查）及 `git diff --check` 通过。代码版本已完成，未提交、未部署；新版视觉待用户截图确认。

Admin客户管理样式核对记录.md

@@ -1,5 +1,7 @@
 # Admin 客户管理样式核对记录
 
+> 文档职责：仅维护模块范围、业务例外与检查／截图记录。通用样式统一以 [Admin 界面规范](Admin高密度界面规范.md) 为准；下文日期批次中的旧外观不再作为新改造要求。普通样式任务只在涉及本模块范围、例外或验收证据时查阅本文。
+
 ## 范围与依据
 
 按当前客户管理导航的两个入口：客户列表、海外仓阶梯费用；客户详情及两个入口实际调用的编辑、审核、预览一并收敛。用户要求按钮使用纯文字，避免图标占位；详情页签保留已确认的彩色 Emoji。沿用《Admin 高密度界面规范》，验收视口为 1920×1080、100% 缩放。
@@ -102,3 +104,31 @@
 5. 计费规则及海外仓费用：只读分组、默认规则入口、规则编辑、币种与多档阶梯、取消和未保存提示；核对单位、公式与底部操作。
 6. 操作日志：筛选、详情抽屉、成功/失败记录及快照长内容。
 7. 海外仓阶梯费用列表：多档位行、横向空间、编辑弹框两类费用并排、档位增删后的表格及校验。
+
+
+## 2026-10-20 蓝白样式接入
+
+沿用上方逐操作矩阵及现有承载。客户列表、客户详情、海外仓阶梯费用三个路由页面，以及实际调用的计费规则、海外仓费用和审计面板显式接入 `admin-workbench`；列表使用外层 `workbench-table`，资质预览、编辑、审核、密码、凭证及危险确认保留各自尺寸和处理逻辑。详情成员表及阶梯表复用 `density-table` 与 `workbench-evidence`，移除原有重复表格外观；正常规则标题的“箱规计算说明”支持键盘聚焦，长公式从常驻横栏移入说明，初始化、权限与错误提示仍常驻。
+
+不恢复当前已注释的运营指标区；`CustomerOperatingMetricCard` 无活动渲染入口，本批未修改。箱规与权重的数据层 `dimension-config` 保持原样。审计详情继续使用抽屉，业务脚本与绑定未变。定向验证及本批共同限制见下述结果；视觉均为待人工截图确认。
+
+本组自动核对：31 个 Vue 模板及样式编译、业务脚本与模板指令对比通过，37 处表格外层、39 处弹框、7 处抽屉作用域通过。61 个受影响测试文件共 611 项已通过首轮及失败项修正后的定向复验；箱规说明以真实组件聚焦验证可读。随后按总控公共合同补齐七处 `is-drawer` 与独立查询栏 `workbench-query`，对应七文件 95 项复验通过，最终 SFC/绑定核对再次通过。全量测试、类型检查与构建由本批总控统一执行；本记录不宣称已部署或已完成人工验收。
+
+
+2026-10-20 用户追加修正：整页主列表与详情外壳使用 `is-page-surface` 取消外围整圈边框、圆角与阴影，页面保持连续白底；本组共 22 处主列表和 6 处详情容器，内部子表、指标/图表卡片、独立并列面板及弹框保持原边界。布局、内边距和脚本不因本修正改变；公共规则与全量门禁由总控统一收口。财务相关三文件 41 项定向复验通过，视觉仍待人工截图确认。
+
+
+## 2026-10-21 弹框可用性回归
+
+确认的问题：新增/编辑客户仍为已确认的 1120px 居中框，但基础资料与联系商务的短字段回退成两列；资质区前的表单因此加长。恢复两个分组每行三个短字段，保持原字段顺序、必填项和绑定；注册资本、地址、备注保留整行。普通标签宽度为 120px，较长的统一社会信用代码标签单独保留 144px。客户计费、资质预览、审核、结果及危险确认的原有承载未改。
+
+实际挂载验证包含三列单元格与整行跨列、客户名称真实 blur 校验后的错误提示、底部保存入口、原编辑与资质预览行为。测试插件按本项目其他 Element 行为测试采用同一 CJS 运行时，避免混用 ES/CJS 表单上下文使校验无法触发。客户 34 项和消息中心 22 项定向回归通过；该结果只证明挂载与交互，不证明真实排版已验收。普通/全屏、长公司名称、信用代码、文件名、多条错误、关闭重开与预览关闭后返回编辑，均待用户 1920×1080、100% 人工截图确认。
+
+## 2026-10-22 客户编辑表单确认
+
+用户提供当前客户编辑弹框截图并确认继续采用这套输入控件外观；通用规则唯一维护在[Admin 界面规范“输入框与字段”](Admin高密度界面规范.md#输入框与字段)，本节仅记录本窗口落点。
+
+- 保留 1120px 弹框、三列短字段及注册资本／地址／备注整行；普通标签 120px，“营业执照企业名称”和统一社会信用代码标签单独 144px。
+- 输入控件白底、浅灰边框、8px 圆角，悬停加深、聚焦蓝框；注册资本与账期数字左对齐，客户昵称占位文字为“选填，默认自动生成”。通过 `density-form--outlined` 接公共边框，客户模块仅限定本编辑框的圆角与数值对齐。
+- 删除底部保存／审核流程说明及已登记信用代码旁的只读说明；信用代码仍按原资格只读，保存、资质上传及提交审核行为不变。“企业认证资料”、帮助入口和现有状态标签同一行。
+- 用户截图已核对输入边界和企业名称标签单行；后续数字对齐、占位文字及状态同行调整已获用户确认纳入规范。未据此推定资质区下半部分、错误态、普通／全屏及关闭重开的全部场景均完成视觉验收。相关定向检查已通过，本次写规范仅核对文档差异与引用，不重复执行业务测试。

Admin排车列表样式试点.md

@@ -0,0 +1,46 @@
+# Admin 排车列表一体式布局试点
+
+> 文档职责：仅维护历史试点依据与检查记录。通用样式统一以 [Admin 界面规范](Admin高密度界面规范.md) 为准；下文日期批次中的旧外观不再作为新改造要求。普通样式任务只在涉及本模块范围、例外或验收证据时查阅本文。
+
+初次试点仅接入测试环境代码的 `/overseas-warehouse/dispatches`。依据为用户提供截图及 `新版.html` 的 `page-outbound-vehicle`（4472–4484 行）；用户明确保留字段设置、搜索与表格不分离。2026-09-30 用户确认样板后授权推广至客户管理、国内仓、货柜管理和海外仓，并继续客户服务、海外业务、财务管理、通用、系统管理及消息列表。范围及例外见 [推广核对记录](Admin列表样式推广核对记录.md)。
+
+船期日历单页收尾按用户当前截图接入相同的页头、筛选和连续容器，通过 `results` 插槽保留日历与当日船次详情。日历不具备表格列配置，明确关闭字段设置且不添加分页；日历日期格和右侧详情布局由业务页维护。
+
+## 修改前核对
+
+| 页面/操作 | 参考布局或承载方式 | 当前实现 | 本轮结论 |
+|---|---|---|---|
+| 排车列表 | 同一容器内：左标题/右按钮、搜索、表格、分页 | 路由标题、独立搜索面板、表格面板及列设置工具栏 | 改为一体式容器，标题只出现一次，字段设置放右上角 |
+| 查询/重置 | `search-row` 紧接表格 | QueryToolbar，含 FBA 预约号及筛选布局偏好 | 保留全部筛选与偏好，只调整容器外观 |
+| 表格字段设置 | 用户明确要求保留 | DataTable 列显隐/排序及持久化 | 继续使用原组件、原 preference-key |
+| 新建/导出 | 参考页顶部有示例按钮 | 正式排车列表无这两项操作 | 仅参考排列，不新增业务功能；公共组件保留 toolbar-actions 插槽 |
+| 查看 | 当前正式路由详情页 | DispatchDetailView | 不变 |
+| 编辑/转派送 | 当前居中表单弹框 | AppDialog | 不变 |
+| 打印 BOL/取消 | 当前 PDF 窗口/二次确认 | 服务端 PDF、ElMessageBox | 不变 |
+| 审核/停用/文件上传 | 本列表无相应入口 | 无 | 不新增 |
+
+## 公共接入
+
+`DataTable` 使用 `appearance="integrated"` 启用公共样式，`toolbar-start` 放页面标题，`toolbar-actions` 放已有业务按钮，`filters` 放 QueryToolbar，条件 `state` 插槽放加载错误与重试。表格字段偏好、行操作和分页继续由 DataTable 管理。该模式下标题、搜索、表格共用边框与圆角，搜索和表格间没有卡片外间距。
+
+页面自行关闭列表路由 `showPageHeading`，避免重复标题；详情路由保留原配置。样式唯一维护位置为 `src/shared/components/DataTable.vue`，业务页不复制样式。未在本轮范围内的页面继续保持默认外观。
+
+一体式列表的搜索区默认输入框、选择框、日期框和按钮共用 `--el-component-size: 36px`。选择框默认外框的最小高度由公共 DataTable 同步，避免 Element Plus 固定的 `32px` 与输入框产生高度差；显式 small/large 尺寸及多选换行继续按组件自身规则处理。该规则同时覆盖 QueryToolbar 和搜索插槽内直接使用的选择框。
+
+Admin 仍使用 Element Plus。普通 `el-select` 由构建组件解析器统一接入 `src/shared/components/AdminSelect.ts`，仅将 `filterable` 默认值设为 `true`，使用 Element Plus 原有渲染、插槽、事件和公开方法；列表、表单、弹框及分页选择框均可输入关键词筛选当前选项。已有 `remote-method`、`filter-method`、多选、禁用和清空行为保持原有配置；搜索不改变候选业务范围，也不会自动新增远程接口调用。虚拟托盘选择框 `el-select-v2` 已显式启用远程搜索。
+
+已接入列表的表格“操作”列使用纯文字按钮：无描边、填充或装饰图标，字重为普通正文的 `400`，普通操作蓝色，取消等危险操作红色，悬停无下划线；禁用为灰色，保留加载反馈、键盘焦点和危险确认。通过 `RowActions` 的 `text-actions` 接入，更多菜单使用相同配色与普通字重；已有手写按钮组使用 `row-actions density-actions admin-text-actions`，危险语义仍由原来的 `data-tone="danger"` 或 `type="danger"` 显式提供。搜索区、顶部字段设置、分页、列设置面板及弹框按钮保持原样。公共行操作外观维护在 `src/styles/adminTextActions.css`，随 `adminDensity.css` 加载；未接入页面默认不启用。
+
+推广时列设置显式使用 `column-settings-mode="show"`。已有 `preference-key` 保持，新接入的退货库存、流水和箱号各使用独立偏好键。存在非阻断警告时使用 `notices` 插槽，列表失败时通过 `results-visible` 隐藏结果和分页，标题、查询与重试保持可用；`before-results` 保留原统计与汇总。特殊工作台可使用 `results` 插槽承载原内容和自身分页，公共表格不重置它的页码与每页数量。
+
+列宽保存为公共 DataTable 能力，与已有列设置一同启用（提供 `preference-key` 且列设置可用），不依赖试点样式。拖动表头边界松开时，将宽度按稳定列键写入同一份本地偏好；重排、隐藏再显示不会丢失，刷新/重新进入时恢复。账号与表格分别隔离，仅保存到当前浏览器，不跨设备同步。“恢复默认”同时重置列顺序、显隐和宽度，重新采用页面声明的 width/minWidth。未启用列设置的表格不写入列宽偏好。
+
+## 验收
+
+代码检查与真实页面视觉验收分别记录。视觉待人工在 1920×1080、100% 缩放下截图确认，重点核对顶部字段设置、搜索连表格、长编号、横向滚动、分页、加载/空态/失败重试，以及原有操作权限。
+
+2026-09-29 代码验证：定向 78 项通过；完整 `pnpm test` 的 262 个测试文件、2118 项测试通过；`pnpm build`（含 `vue-tsc --noEmit`）通过。未提交、未部署，当前修改不涉及 API、权限或业务状态。
+
+纯文字按钮追加验证：相关 6 个文件、81 项检查通过，类型检查与构建通过。完整测试运行 2118 项通过、1 项失败，失败为原型合同硬编码了 RowActions 属性顺序；改为检查真实动作绑定后，该文件 21 项定向复测通过。视觉仍待人工确认。
+
+列宽保存追加验证：完整 262 个文件、2125 项测试通过；列属性类型调整后公共表格与偏好存储 33 项再次通过；类型检查与构建通过。覆盖拖动保存、重新挂载、排序与显隐保留、恢复默认、独立表格/账号范围、异常宽度与关闭偏好场景。尚未部署，真实表头拖动效果待人工确认。

Admin海外仓样式核对记录.md

@@ -1,8 +1,10 @@
 # Admin 海外仓样式核对记录
 
+> 文档职责：仅维护模块范围、业务例外与检查／截图记录。通用样式统一以 [Admin 界面规范](Admin高密度界面规范.md) 为准；下文日期批次中的旧外观不再作为新改造要求。普通样式任务只在涉及本模块范围、例外或验收证据时查阅本文。
+
 ## 范围与依据
 
-本轮用户确认继续“海外仓”模块。范围以 `adminNavigation.ts` 的 `overseas-inventory` 分组为准，包含 10 个菜单、对应独立详情和实际调用的作业弹框。客户服务、海外业务、隐藏产品库和旧箱号页面不在范围内。
+本轮用户确认继续“海外仓”模块。范围以 `adminNavigation.ts` 的 `overseas-inventory` 分组为准，按当前公开菜单、对应独立详情和实际调用的作业弹框逐项核对；当前分组包含11个菜单，废弃单和海外库位管理均单独登记。客户服务、海外业务、隐藏产品库和旧箱号页面不在范围内。
 
 视觉采用 [Admin 高密度界面规范](Admin高密度界面规范.md)，保留当前路由、字段、权限、服务端状态资格及操作承载方式。原型入口为 `悦/货代SAAS平台后台/prototype-src/modules/03-overseas-warehouse.html`；入库、出库、换标、托盘详情分别见 706、714、720、726 行，尾程列表/详情见 894/927 行，库存详情/流水见 974/1022 行。当前真实业务契约优先于历史原型占位。
 
@@ -28,7 +30,7 @@
 | 派送单资料 | `DeliveryDocumentsDialog` 上传、替换、删除、下载、保存、重新加载确认 | 1040px；关闭放弃未保存修改 | 保留文件生命周期，正文单一滚动区 |
 | 换标单 | `RelabelOrdersView` 新增、审核、查看 | 760px 表单；独立详情 | 保留创建与审核模式、状态候选与必填字段 |
 | 换标详情 | `RelabelOrderDetailView` 完工证据、总 PDF、明细 PDF 上传/预览 | 连续详情、预览 900px | 保留 PDF 物理预览尺寸与绑定数据，紧凑文件行 |
-| 托盘管理 | `PalletsView` 汇总、新增、编辑、查看；`PalletDetailView` | 760px 表单；独立详情 | 汇总改紧凑行；保留仓库编辑限制 |
+| 托盘管理 | `PalletsView` 汇总、新增、编辑、查看；`PalletDetailView` | 顶部四张等宽统计卡片，采用公共紧凑卡片及图标样式，不继承186px最小高度；760px 表单；独立详情 | 统计卡片按2026-10-22用户参考截图并依后续反馈压缩高度：白底圆角、浅色图标、蓝色数字和“个”单位；原四项统计与筛选口径、仓库编辑限制保留；压缩后待人工1920×1080、100%缩放截图确认 |
 | 库存管理 | `InventoryView` 汇总、查看、导出；`InventoryDetailView` | 独立详情，库位/托盘箱号/流水表 | 连续汇总、信息表；不改变库存口径 |
 | 库存流水 | `InventoryTransactionsView` 导出、返回、关联数据 | 列表深链；共享关联框 1060px | 只为本轮调用显式接入共享框，保留分区域只读权限 |
 | 退货库存管理 | `ReturnInventoryManagementView mode=inventory` | 库存/流水页签、查询、分页 | 两页签保留各自数据和查询模式 |
@@ -48,6 +50,14 @@
 
 ## 用户截图复核修正
 
+2026-10-21 接续原“整理页面风格”对话的两张截图：`b93804b4-c276-49bb-bc41-7fc054f889f5` 显示排车顶部执行阶段比下方审核分区多缩进一层；`72efa811-a846-41a4-a074-3dde6d4c2ae0` 为用户指定的销量分析灰白行底色样板。本次仅调整公共对齐与表格斑马纹，修复后仍待人工截图确认。
+
+| 操作 | 截图现状与目标 | 本次修正 |
+|---|---|---|
+| 排车列表执行阶段切换、审核分区及筛选 | 顶部页签叠加工具栏 12px 缩进，下方分区未叠加 | 主列表首个状态页签由公共样式抵消重复缩进；前置返回按钮、嵌套列表保留自己的间距与布局 |
+| 排车及其他标准列表查看、悬停、选中 | 多数列表显式关闭斑马纹；销量分析默认灰白相间 | 清理历史关闭属性，使用 DataTable 默认斑马纹；保留悬停／选中提示和业务行色，行底色不穿透内嵌表 |
+| 主列表底部分页 | 用户补充底部 padding 过大；集成列表仍为最小 64px、上下 14px | 公共主列表分页收紧到最小 48px、上下 6px、左右 12px；保持按钮尺寸与换行，内嵌表格不继承该布局；待人工截图 |
+
 用户提供尾程详情与国内订单详情截图后，确认上一轮仅接入密度变量不足以达到样板一致：尾程存在重复页头标签、缺少业务摘要、自定义绿色状态边框、页签首项贴边且选中底色缺失、基本信息被两个标题拆断。截图证据为本轮附件 f76bcf5f（尾程）与 151a1d06（国内样板）。
 
 | 操作 | 样板及现状 | 本次修正 |
@@ -90,3 +100,297 @@
 后续截图 `codex-clipboard-1adadeb3-9d55-4c41-81c1-d6dafba87293.png` 确认搜索与批量按钮占行过多：海外仓搜索（280px）和一件代发订单搜索及查询/重置（640px）同排，移除独立批量按钮行，已选数并入分页左侧。普通说明收为单行文字，跨客户警告仍保留，备注默认一行并按输入自动增高至三行。
 
 已增加真实组件回归覆盖分页选择、筛选后跨页勾选、半选状态、每页条数切换、仓库变更清空选择、提交明细数量以及多客户提交门禁。仅使用测试 Mock 验证提交，无真实出库单创建或 PDA 推送。修正后视觉仍待 1920×1080、100% 截图确认。
+
+
+## 统一弹窗整理：尾程订单主窗口（2026-10-20）
+
+依据当前统一弹窗样板、浅色背景、无左侧色条和连续编辑表；当前入口为尾程订单列表、独立详情及列表调用的WarehouseTransferReviewDialog。截图编号唯一维护在[跨模块清单](Admin国内仓样式核对记录.md)，本组为279—309。最近指引与旧样式矩阵中的转运审核尺寸不一致时，按当前实际420px简短确认保留，只提交APPROVE，不恢复旧详细审核或新增驳回功能。
+
+| 操作 / 状态 | 当前承载与尺寸 | 本组处理 | 保留边界 |
+|---|---|---|---|
+| 转仓 | AppDialog，默认560px | 票数标题、连续FBA/备注、全屏 | 公共ACTIVE FBA仓、空态/错误、原选择与转仓请求 |
+| 按柜生成与恢复资源 | AppDialog，1240px | 连续选择、浅绿服务端汇总、浅蓝分组、结果表、全屏 | 托数/阻断/快照及原请求重试、完整结果和原确认门禁 |
+| 单票入库计划 | AppDialog，720px | 冻结资料文字、浅黄连续登记、全屏 | 原托数约束、一件代发固定托数、开关/备注、版本与幂等键 |
+| 暂扣 / 解除 | AppDialog，620px | 单号标题、连续状态/计费/原因、全屏 | 原开放状态、原因、0版本和原请求 |
+| 人工节点 | AppDialog，700px | 单号标题、八行连续时间表、全屏 | 全部8项、0版本、原警告及完整提交 |
+| 换标退回重做 | AppDialog，620px | 换标号标题、连续单号/原因、全屏 | 原应用候选、复核任务版本、原因及幂等键 |
+| 仓储转运审核 | AppDialog，420px，align-center | 单号标题、浅蓝客户和确认后果 | 原返回/通过、无详情请求、原客户范围及提交锁定 |
+| 详情新增费用 | AppDialog，720px | 单号标题、连续费用登记、全屏 | 原应收/应付、USD/CNY、供应商、期间、数量与完整载荷 |
+| 合托、废弃/退货/贴标审核及换标确认 | 原ElMessageBox | 业务单号/勾选票数标题 | 原通过/驳回/取消/关闭分支、原因校验、权限与请求 |
+
+原隐藏柜子详情及接柜仓修改窗口保留，不恢复隐藏页签；旧隐藏工作台样式未借本轮扩大处理。原单票/按柜命令与服务端事实、版本、幂等、未知结果及资源恢复逻辑不变。普通来源说明改为InlineHelp；清关后不可更改、固定托数、人工节点覆盖、阻断与资源未确认等提示保留可见。节点表和按柜分组取消内部纵向限高，正文承担主要滚动；横向业务列宽保留。全部写入只以本地Mock验证，不执行真实计划、库存、节点、审核或费用写入。
+
+详情内WarehouseTransferFulfillmentPanel库存分配、WarehouseTransferReceiptPanel签收箱号/增加预报/箱内清点三个子窗口在下节接续；其余海外仓正式菜单尚待整理，本组不视为整个海外仓完成。
+
+自动检查：12个文件、211项定向检查通过；类型检查与构建通过；全量432个文件、3796项测试通过。均通过统一local-check入口串行执行，沿用用户本轮授权的Node 6GB堆上限。冻结的30项源码、测试、共享组件、声明和构建输入前后哈希一致；生成声明与依赖/构建配置未改变，git diff --check通过。主清单1—309号连续且无重复。回归修正了费用标题误传订单对象和计费单位显式disabled覆盖表单保存锁定的问题；原费用载荷不变。
+
+仅完成本地实现与自动检查，未提交、推送、部署或写入测试业务数据；279—309号视觉待人工1920×1080、100%缩放截图确认。
+
+## 统一弹窗整理：转运分配与签收子窗口（2026-10-20）
+
+沿尾程独立详情的实际import进入WarehouseTransferFulfillmentPanel和WarehouseTransferReceiptPanel；同票出库/目标仓实收仍由WarehouseTransferMovementPanel原页面内操作承担，本批不改变承载方式。截图编号310—321唯一维护在[跨模块清单](Admin国内仓样式核对记录.md)。
+
+| 操作 / 状态 | 当前承载与尺寸 | 本组处理 | 保留边界 |
+|---|---|---|---|
+| 库存来源分配 | AppDialog，1320px | 转运号标题、浅绿数量核对、浅蓝完整候选表、全屏 | 原客户/库存权限、可分配箱数、选择总量、来源阻断、冻结原请求与明确拒绝后重新选择 |
+| 签收箱号明细 | AppDialog，1120px | 转运号标题、已清点箱汇总、连续箱号表、全屏 | 只统计COUNTED箱，原托盘/箱唛/SKU/尺寸/重量/体积和箱内入口 |
+| 增加预报箱数 | AppDialog，520px | 原箱数与增加后核对、浅黄连续表单、固定底栏、全屏、失败诊断与输入保留 | 原客户/单号、开窗箱数快照、expectedPackageCount及最终packageCount；正整数与既有5000箱上限同时约束按钮和提交入口 |
+| 箱内清点明细 | AppDialog，820px | 箱唛标题、只读箱唛/清点时间、浅蓝多SKU实收、直接展示差异原因、全屏 | 原混箱SKU、件数与品名；子窗口关闭后保留箱号父窗口和其全屏状态 |
+
+三个弹窗内DataTable显式以空max-height取消其默认纵向限高，由弹窗正文承担主滚动；长字段仍复用DataTable的默认单行省略与悬停完整文本，横向列宽不变。未将预报箱视为实收，也未改动SKU件数、测量汇总、打印入口或后台请求格式。增加预报的普通说明收进InlineHelp，失败原因及requestId等诊断保留可见。保存时锁定表单、底栏和关闭；切换客户或来源单号时关闭旧窗口，迟到响应不更新新票或展示旧错误；取消后重开恢复新增1箱。
+
+自动检查：12个文件、204项定向检查、类型检查与构建均通过；全量432个文件、3808项测试通过。均经统一local-check入口串行执行，沿用用户本轮授权的Node 6GB堆上限。31项冻结源码、测试、共享组件、声明与构建输入前后哈希一致；业务API文件、生成声明、依赖和构建配置未改变；git diff --check通过。主截图清单1—321号连续且无重复。原库存分配脚本仅增加公共样式导入，分配、原请求重试和明确拒绝后的重新选择逻辑保持原样。
+
+本批只以本地Mock验证分配、重试和增加预报，未执行真实库存/箱唛/预报写入，也未生成真实打印资料；未提交、推送或部署。310—321号视觉待人工1920×1080、100%缩放截图确认。海外入库单的预约、计划编辑和托盘移库弹窗在下节接续，其余海外仓正式菜单仍待整理。
+
+## 统一弹窗整理：海外入库单预约计划编辑与托盘移库（2026-10-20）
+
+实际入口为InboundOrdersView两个AppDialog、显式continuous的FbaAppointmentFields，以及InboundOrderDetailView的移库AppDialog。编号322—336唯一维护在[跨模块截图清单](Admin国内仓样式核对记录.md)。列表及独立详情、智能排车入口、同接仓点/同FBA选择与多批预约跳转保持原样；本批不代表智能排车及其子窗口已整理完成。
+
+| 操作 / 状态 | 原承载与尺寸 | 本组处理 | 保留边界 |
+|---|---|---|---|
+| 预约 / 编辑 / 只读预约 | AppDialog，1080px | 数量/FBA浅绿核对、系统约号/时区文字、浅黄连续登记、业务号标题和全屏 | 原PENDING/SUCCESS/FAILED/CANCELLED、外部约号、计划与确认起止时间、补充时段、重叠时差清空、必填原因和原完整请求 |
+| 原批次已替代或只读权限 | 同预约窗口 | 原替代预约号直接警示、真实表单禁用 | 原列表只读、取消/替代批次不可写；原预约状态和替代关系不变 |
+| 预约结果未确认 | 同预约窗口 | 弹窗内诊断、原请求重试和字段冻结 | 原pendingAppointment载荷、版本、幂等键与关闭/路由守卫；明确拒绝后可重新填写的原分支不变 |
+| 编辑入库单 | 默认560px AppDialog | 单号/版本文字、连续目的仓选择、全屏、读取/保存锁定和错误诊断 | 原平台候选、客户范围、目的仓ID/编码/名称与版本0完整提交；候选失败仍关闭窗口并保留列表错误 |
+| 托盘移库 | AppDialog，560px | 来源单/托盘文字、浅黄连续目标/原因、全屏、候选空态/错误/重试、保存锁定与诊断 | 原仓库范围、普通/A0过滤、当前托盘版本、业务码及移库载荷；原服务端canMove阻断仍留窗，不作为成功刷新 |
+
+共享FbaAppointmentFields只为本列表的continuous调用新增布局，预约工作台等已有消费者保留默认结构；全部原模型字段均保留。本地调整不改变预约确认口径、时区/DST解析、API路径或服务端载荷。移库原先用真假值禁用了合法版本0，现区分版本0和未返回版本；缺失版本或托盘号不可操作。移库保存增加重复提交门禁并锁定原输入，候选读取失败与服务端错误在窗口内保留诊断；每次移库调用原有幂等键生成方式保持不变，本批不另行设计移库命令恢复协议。
+
+自动检查：16个文件、181项定向检查、类型检查与构建通过；全量433个文件、3825项测试通过。均经统一local-check入口串行执行，沿用本轮授权的Node 6GB堆上限。38项冻结源码、共享字段直接消费者、测试、声明与构建输入前后哈希一致；预约/计划/库位API、appointmentForm载荷转换、生成声明、依赖及构建配置未改变；git diff --check通过。连续分支与原字段集合对比为10项且无差异；实际5个预约工作台消费者均保留默认布局并完成定向回归。主截图清单1—336号连续、无重复。
+
+仅进行本地Mock验证，未创建真实预约、修改计划、移动库存、提交、推送或部署。322—336号视觉待人工1920×1080、100%缩放截图确认。入库单实际引用的SmartDispatchDialog新建排车作业窗口及资源字段在下节接续；其余海外仓和Admin模块仍待整理。
+
+## 统一弹窗整理：新建排车与资源登记（2026-10-20）
+
+从入库单及排车列表实际引用的SmartDispatchDialog进入，直接复用的DispatchResourceFields另有DispatchWorkflowDialog消费者；本批仅对新建排车显式启用连续资源登记，不改变后者默认布局。当前1800px AppDialog、先选货/先建空单、候选与装车组双栏、原版本化草稿命令及真实排车核对均保留。
+
+| 当前操作 / 承载 | 本批整理目标 | 保留边界 |
+|---|---|---|
+| 建单方式、起运仓、分组时间与备注 | 浅黄连续表单、原生标题与全屏、装车组上下文 | 原同仓、按组独立settings、空单与整车分支 |
+| 车辆/司机档案及本趟临时资源 | 显式连续资源表、完整字段与禁用反馈 | 档案权限/搜索、实际容量、证照/任务结束、本趟资料不建档案 |
+| 草稿恢复、新建/释放、装车组增删 | 浅绿草稿汇总与连续分组 | 原token、版本、容量15/30、来源锁定及未知结果恢复 |
+| 货物查询、仓库分类和来源明细 | 浅蓝候选、长文本省略、完整来源组展开、正文主滚动 | 原查询条件、完整候选、整组资格、全部真实来源与加入/移除 |
+| 提交/未知结果/明确拒绝/读取失败 | 原固定底栏、可见阻断与诊断、原请求重试 | 原会话内请求、幂等键、响应身份/版本和整车核对，不重造协议 |
+
+实施结果：新建排车启用原生全屏，设置与车辆司机分成浅黄连续表，草稿管理和装车组采用浅绿分区，候选采用浅蓝分区。保留1800px和候选/分组双栏；移除候选表420px纵向限高，由弹窗正文承担主要滚动，明细列宽及横向滚动保留。普通长列使用原生溢出提示，业务引用和托盘号使用LineClampText；完整来源组可展开查看全部来源，选取资格和整组请求不变。外配仅本趟、空单不可核平/装车/发车、未知结果冻结和明确拒绝后的重新核对仍直接显示。
+
+共享DispatchResourceFields新增显式continuous分支，默认消费者DispatchWorkflowDialog布局保持不变；档案和外配的全部原绑定、档案权限、实际容量、任务结束与证照字段保留，未生成假档案或按计划托位推算车辆容量。初次生成组配置时，原逻辑直接返回赋值表达式的原始对象，资源切换后可能出现界面仍有车牌、实际配置已为空的情况。现先存入响应式settings再返回其代理对象；真实组件回归验证车牌、容量、司机及分组切换后的完整载荷，保留原版本、幂等、转换和恢复协议。未选择装车组时，先选货模式的车辆/司机/时间/备注保持禁用，建单方式及起运仓仍可设置；空单模式不受装车组前置限制，避免资料落入未提交的占位组配置。
+
+自动检查：16个文件、242项定向检查、类型检查与构建通过；全量434个文件、3839项测试通过。均经统一local-check入口串行执行，沿用用户授权的Node 6GB堆上限。42项冻结源码、直接消费者、测试、共享组件、API/模型/恢复输入、声明与构建输入前后哈希一致。除已说明的组配置初始化修复及样式导入/显式属性外，两组件脚本与本批修改前一致；资源连续分支包含全部14项原绑定。原有API、模型和恢复协议的工作区修改均保留，本批未改动；生成声明、依赖及构建配置未产生改动。git diff --check通过，主截图清单1—351号连续且无重复。
+
+截图337—351唯一维护在[跨模块清单](Admin国内仓样式核对记录.md)，视觉待人工1920×1080、100%缩放截图确认。本地Mock覆盖先建空单、档案/临时资源、组配置保留、整组来源展开、未知结果原请求、明确拒绝重选及已证明转换后的详情重读；未真实创建或转换草稿、排车、档案及业务数据，未提交、推送或部署。下一批接续排车详情的维护/审核/移货/卸货顺序等动作窗口及附件预览，其余Admin模块仍待整理。
+
+## 排车第14、16项当前核对（2026-10-22）
+
+依据本轮确认：移除“调整已有排车货物”入口，调度审核采用约1100px居中弹框，信息、三类照片与审核操作分区清晰。尺寸与滚动继续使用《Admin高密度界面规范》的资料审核弹框规则。
+
+| 页面 / 操作 | 确认承载与布局 | 当前实现 | 验收结论 |
+|---|---|---|---|
+| 智能排车 / 新建安排 | 保留新建草稿选货；删除已有排车调整入口 | 删除旧页签、独立组件及调用；保留三栏草稿选货、分组转换与空单创建 | 自动检查通过；待1920×1080、100%缩放实页确认 |
+| 排车 / 调度及理货审核 | 居中弹框约1100px，三类照片横向并排 | 1100px及原全屏能力；车辆与货物、排车与预约、照片和审核意见分区；底部保留驳回、审核通过 | 自动检查通过；待1920×1080、100%缩放实页确认 |
+
+本轮159项相关检查通过（5份业务测试157项、2项排车样式合同），AGENTS索引合同1622项通过。第15项已核对各阶段、装车前分区及DELIVERY/PICKUP/LOCAL_TRUCK均显示后端主单createdAt，沿用现有实现。共享样式整文件另有4项非本轮页面失败：订单详情概览类、货柜尾程费用行操作类、订舱详情局部36px规则、入仓预约分区旧断言；未修改对应页面，不将其计作通过。本轮仅本地实现与检查，未执行提交、部署或真实HTTP验收。
+
+本轮文件（相对`apps/admin-web/`）：修改`src/modules/overseas-warehouse/components/SmartDispatchDialog.vue`、`SmartDispatchDialog.test.ts`、`DispatchWorkflowDialog.vue`、`DispatchWorkflowDialog.test.ts`、`DispatchWorkflowDialog.layout.test.ts`；删除同目录`SmartDispatchExistingCargo.vue`及`SmartDispatchExistingCargo.test.ts`；同步`src/modules/overseas-warehouse/AGENTS.md`、`src/modules/overseas-warehouse/pages/prototypeContract.test.ts`、`src/styles/adminDensity.test.ts`及本记录。前述预约/BOL与6–9、11项改动保留；此包已停止编辑，交总控统一集成验收。
+
+以下2026-10-20记录保留当时证据；本轮涉及的入口与审核尺寸以本节为准。
+
+## 统一弹窗整理：排车详情操作与取证附件（2026-10-20）
+
+实际操作承载为DispatchWorkflowDialog，直接引用DispatchResourceFields、DispatchArrangeFields和DispatchEvidenceFiles；后者也供DispatchDetailView只读取证使用。保留560/760/1120px动作尺寸及900px图片预览，不改变详情路由、服务器Gate、版本化命令、费用覆盖、文件鉴权或恢复协议。
+
+| 操作 / 原承载 | 本组整理目标 | 保留边界 |
+|---|---|---|
+| 维护车辆、司机、时间及备注 | 业务号标题、浅黄连续登记、共享资源显式接入、全屏 | 原资源档案/外配、证据引用、完整EDIT载荷 |
+| 调度/理货审核及简单确认 | 浅蓝事实、浅黄结果/原因或备注、可见业务警示 | 原两级审核、驳回必填、取消/回退/发车及服务端资格 |
+| 添加/移除货物、卸货顺序 | 浅蓝完整明细、来源展开、原生长文本提示、正文主滚动 | 真实来源组、逐项移货Gate、已扫码限制、既有全部站点及调整原因 |
+| 装车完成与依据 | 实测连续表、逐托证据表、全屏 | PDA核平、真实实测与参考区分、manifest及卸货顺序 |
+| 整车分组派送 | 各组连续安排、完整货物/外接报价/原费覆盖及新增费用 | 原客户/目的地归属、覆盖哈希、未覆盖正数费用及买约卖家必填 |
+| 本趟附件与图片预览 | 操作在前的紧凑附件表、只读/上传资格、全屏图片框 | 原字符串文件ID、上传/替换/移除引用、鉴权Blob/PDF、迟到响应及URL释放 |
+| 上传、未确认结果与错误 | 固定底栏与关闭锁定、原错误和原请求重试 | 原证据busy、未知结果冻结、明确拒绝后重新核对 |
+
+实施结果：动作窗口标题携带原排车业务号，车辆/司机与计划时间、操作原因、分组派送均采用浅黄连续表；原审核资料、完整货物来源、逐托测量依据及附件采用浅蓝分区，无左色条。1120/760px窗口开放原生全屏，560px简单确认保留紧凑尺寸，底栏与关闭在提交和上传期间锁定。移除货物420px、添加候选380px、派送分组货物240px的表内纵向限高取消，由弹窗正文承担主滚动；列宽与横向滚动保留。原生长列溢出提示和LineClampText承载完整文本；完整来源组可展开全部来源，实测与参考依据直接区分。
+
+DispatchArrangeFields脚本及费用覆盖算法保持原样，派送、原费用、外接报价与新增费用的全部原绑定和业务字段保留；两级审核、真实dispatchItemId、全部既有卸货点、合法版本0及长版本、manifest、费用哈希和原命令恢复协议不变。原服务器资格与前端权限同时决定表单禁用，提交校验继续保留。本地回归发现失败操作关闭重开后，重新读取会用服务端旧资料覆盖当前实例已提交的输入，而重试仍使用原请求；现仅按当前实例记录的幂等键和原业务号保留该请求对应的表单与诊断。新实例恢复仍读取当前事实，明确拒绝后重新核对仍先清除被拒请求再读取，不新增存储或恢复协议。
+
+DispatchEvidenceFiles保留原本车/附件类型鉴权、字符串引用、上传校验、Blob/PDF读取、迟到响应隔离及URL释放；附件表将操作放前，失败诊断可重新读取，原上传与主单引用保存提示直接显示。图片预览保留900px与图片72vh适配上限并增加全屏；此上限只控制图片适配，不建立嵌套滚动。DispatchDetailView只读取证直接消费者一并回归，未添加上传资格。
+
+自动检查：17个文件、251项定向检查、类型检查与构建通过；全量435个文件、3855项测试通过。均经统一local-check入口串行执行，沿用用户授权的Node 6GB堆上限。52项冻结源码、直接消费者、API/模型/恢复输入、测试、共享组件、生成声明与构建输入前后哈希一致；生成声明、依赖与构建配置未改变，git diff --check通过。三个组件脚本扣除已列明的样式/显示组件导入和当前实例请求标记后，与本批修改前哈希一致；派送组件13项原模型绑定无缺失。原有选货分组/API/模型工作区修改保持原样，本批未改动。主截图清单1—375号连续且无重复。
+
+截图352—375唯一维护在[跨模块清单](Admin国内仓样式核对记录.md)，视觉待人工1920×1080、100%缩放截图确认。本批仅使用本地Mock，未真实审核、移货、发车、创建派送/费用、上传业务附件或写入测试数据；未提交、推送或部署。其他海外仓及Admin模块仍待继续整理。
+
+## 统一弹窗整理：新建出库三种模式（2026-10-20）
+
+当前实际入口为OutboundsView的1760px上限AppDialog，保留独立出库详情及列表/详情原取消原因提示框；本批不改动派送列表、资料窗口和详情路由。
+
+| 操作 / 当前承载 | 本组目标 | 保留边界 |
+|---|---|---|
+| 一件代发出库 | 浅黄连续类型/仓库/查询、浅蓝完整候选、正文主滚动、原全屏 | inventoryPositionId+SKU跨页选择、本页全选、同客户同仓、实际可出箱数和三项测量 |
+| 退货出库 | 浅黄连续客户/收件/仓库/退货单、浅蓝SKU与实物箱双栏、原分页 | 原整包裹/整箱/整托、原箱内SKU与数量、原退货来源，不引入部分SKU直接出库 |
+| 仓储转运目的地绑定 | 浅蓝真实转运单、浅黄FBA/私人仓连续信息 | 按客户+转运单合并托盘、无目的地资格、全部真实绑定对象及原目的地载荷 |
+| 候选/资源读取、保存、失败与重开 | 锁定读取/提交期间的编辑和关闭、错误诊断与重读、保留失败输入 | 原读取接口、客户范围、原写请求与幂等键生成方式；新会话重新初始化 |
+| 取消出库关联核对 | 保留原ElMessageBox承载与admin-density-confirm | 原取消原因、费用处理警示、关联排车释放及权限，不将取消视为库存自动回滚 |
+
+实施结果：保留当前1760px上限、原生全屏、固定底栏及三种真实模式；类型、仓库与订单查询、收件/退货来源、FBA/私人仓目的地、备注采用浅黄连续表。原一件代发候选及转运单采用浅蓝分区，退货SKU与实物箱保留双栏和各自分页，全部原候选列及18项模型绑定保留。取消360/380/400px表内纵向限高和旧候选列表300px限高，由弹窗正文承担主滚动；保留横向滚动、每页条数128px及原窄屏规则。长客户/品名、业务号、箱内SKU和托盘继续使用原生溢出提示；无客户名称的转运单显示“客户名称待补充”，不回退内部ID。
+
+读取/保存期间，表单、选择框、分页、提交和关闭均锁定；提交方法独立检查当前开窗、权限、读取/保存状态及候选失败，防止重复调用或在来源读取失败时继续提交。基础资料及候选读取失败在弹窗内保留ApiErrorMeta诊断，可按原范围重读；创建失败保留当前输入与选择，由原提交入口重试。重新新建清空上一单备注、收件信息、退货来源和箱托方式，默认一件代发；失败留窗、切换全屏不清空当前输入。一件代发候选重读保留仍有对应键的选择；退货候选重读仍沿用原加载逻辑重新核对整箱选择。
+
+原创建校验与请求正文逐字核对保持一致：按库存位置+SKU出全部可用箱数，同客户同海外仓；退货仍按原物理包裹/箱号或托盘，不引入部分SKU载荷；转运仍按客户+转运单聚合并绑定目的地，不直接创建出库。原接口路径、客户作用域、幂等键生成方式与取消处理协议未改变，本批不新增未知结果恢复协议。列表及详情取消确认仅关联核对，保留原承载、费用警示、原排车释放和权限逻辑。
+
+自动检查：10个文件、135项定向检查、类型检查与最终构建通过；全量436个文件、3865项测试通过。均经统一local-check入口串行执行，沿用用户授权的Node 6GB堆上限。32项冻结源码、测试、共享组件、原API与模型、生成声明及构建输入前后哈希一致；原出库/退货API、独立出库详情、取消确认、依赖与生成声明未改变，git diff --check通过。布局合同改为核对实际消费的公共全宽控件规则，原取消、权限、数量、跨页选择与实际请求断言均保留。主截图清单1—391号连续且无重复。
+
+截图376—391唯一维护在[跨模块清单](Admin国内仓样式核对记录.md)，视觉待人工1920×1080、100%缩放截图确认；本批仅本地Mock验证，未创建真实出库/退货、绑定目的地、推送PDA、取消业务单据或部署。下一组接续派送状态、标记退货和资料管理，其他Admin模块仍待整理。
+
+## 统一弹窗整理：派送状态退货与资料（2026-10-20）
+
+| 操作 / 当前承载 | 本组目标 | 保留边界 |
+|---|---|---|
+| 编辑派送状态，520px AppDialog | 业务号标题、浅蓝只读事实、浅黄连续状态/备注、读取/保存锁定 | 最新版本0、服务端allowedActions、冲突重读、原取消须经出库提示 |
+| 标记退货，720px AppDialog | 业务号标题、连续原因/去向/物流、来源表操作在前、全屏 | 原尾程主单、原出库明细与可退上限、原退货箱整箱、真实来源标识与原幂等请求 |
+| 派送资料，1040px AppDialog | 业务号标题、浅绿摘要、连续BOL、三类浅蓝附件表、全屏 | 原只读/管理资格、每类20份/50MiB、上传/替换/删除草稿、保存版本/幂等、签收文件完成派送 |
+| 资料重新加载确认 | 保留ElMessageBox与admin-density-confirm | 原未保存资料放弃确认、关闭丢弃草稿、重开读取真实快照 |
+
+实施结果：520px状态窗口保留紧凑承载，标题携带派送业务号，当前状态/关联出库采用浅蓝普通文字，允许状态及备注采用浅黄连续表。读取/保存时锁定表单及关闭；版本冲突保留备注、禁用提交，原重读只保留最新仍允许的状态；最新已无可选状态时直接提示。720px退货窗口增加原生全屏，主单、原因、去向、物流采用连续表；原出库明细改为操作在前的来源/上限/箱数表，LineClampText承载完整业务来源，原箱固定1箱与整箱警示保留。读取失败可在原派送号/客户范围重新读取；提交失败仍由原入口重试同一载荷和幂等键。
+
+1040px资料窗口增加原生全屏、浅绿资料摘要、连续BOL登记与三类浅蓝附件表；文件动作放前，长文件名使用LineClampText，上传时间、已保存/待保存状态仍完整显示。未保存文件继续不可下载，上传/替换/删除仍只改草稿，完整保存后生效；只读BOL采用普通文字，保留已保存文件下载。读取和上传/保存锁定关闭，读取失败摘要显示“资料未返回”，避免误示仍在读取。版本冲突保留草稿，重新加载继续使用原放弃未保存资料确认；关闭/重开继续读取服务端原三类快照。
+
+两个组件的业务脚本扣除长文本显示组件导入后均与修改前逐字一致，原14项和2项模型绑定无缺失；状态版本0、allowedActions、尾程/来源归属、整数可退上限、原箱来源、每类20份/50MiB、文件上传/下载作用域、版本及幂等协议保持原样。原权限/数量/错误/请求断言保留，既有测试仅将弹窗选择器改为匹配携带业务号的标题前缀；未修改服务端契约、API路径或写入载荷。列表及独立详情承载保持原样。
+
+自动检查：12个文件、160项定向检查、类型检查与最终构建通过；全量437个文件、3876项测试通过。均经统一local-check入口串行执行，沿用用户授权的Node 6GB堆上限。37项冻结源码、直接消费者、原API/来源模型、测试、共享组件、生成声明及构建输入前后哈希一致；原API、独立派送详情、依赖与生成声明未改变，git diff --check通过。主截图清单1—409号连续且无重复。
+
+截图392—409唯一维护在[跨模块清单](Admin国内仓样式核对记录.md)，视觉待人工1920×1080、100%缩放截图确认；本批仅本地Mock验证，未真实修改状态、生成异常退货、上传业务文件、保存资料、提交、推送或部署。下一组接续换标单及实际引用的作业窗口，其他Admin模块仍待整理。
+
+## 统一弹窗整理：换标新增审核与PDF（2026-10-20）
+
+| 操作 / 当前承载 | 本组目标 | 保留边界 |
+|---|---|---|
+| 新增换标单，760px AppDialog | 连续基础/作业表、公共候选、全屏、处理中与失败反馈 | 客户及公共收货仓独立读取、必填、箱数/金额、原幂等键及创建载荷 |
+| 审核换标单，同一760px窗口 | 原完整多SKU/数量普通文字、连续动作与备注、业务号标题 | 原审核资格、尾程审核分流、驳回原因及状态请求 |
+| 作废、完工确认、退回重新贴标 | 保留ElMessageBox密度确认 | 原权限、状态、复核版本与PDA退回原因 |
+| 总/明细PDF预览，900px AppDialog | 业务号、全屏、加载/错误重试、关闭释放URL | 原TOTAL/ITEM及明细标识、鉴权下载、原iframe72vh/760px适配 |
+| PDF上传与箱唛映射 | 原PDF入口、权限禁用、操作在前、缺失仓码不显示内部ID | Controller上传使用relabel-order:create，下载使用list；原类型/50MB及请求保持 |
+| 贴标文件共享下载表 | 仅将原下载操作列放前 | RelabelOrderDetailView与LastMileOrderDetailView两个直接消费者，原两列及文件分类/归属/下载不变 |
+
+实施结果：新增/审核保留760px并增加原生全屏，新增采用自动编号文字、浅黄连续基础/作业/备注表；审核将原多SKU、新SKU逐项数量、箱数、关联订单、品名、货件号、要求及费用完整显示为浅蓝普通文字，只保留原动作和备注可编辑。19项原模型绑定无缺失，创建与审核的原验证/请求正文逐字一致。客户与公共收货仓继续独立读取，候选失败各自显示诊断与重读；新建/审核在读取或保存期间锁定编辑和关闭，失败留窗保留原字段与原创建幂等键。审核详情读取失败仍按原规则关闭并提示；合箱入口仍跳转原库存来源选择，不恢复旧本地合箱表单或把箱数当SKU数量。
+
+原作废、完工确认和退回重新贴标继续使用密度ElMessageBox，提示携带业务号，真实确认/原因输入仍触发原业务请求；完工确认和退回动作增加互相禁用与处理门禁，避免等待结果时并发发起另一动作，原退回复核版本0及原因保留。详情PDF预览增加原生全屏、业务号/文件名标题、读取中与错误重读；保留900px、iframe的72vh/760px尺寸和PDF内部查看方式。关闭/切换业务号/卸载释放URL并忽略迟到预览响应；TOTAL/ITEM和明细标识保持原样。PDA完工照片仍沿原鉴权读取、浏览器页签及60秒URL释放流程，不改变承载。
+
+上传入口和提交方法按现行Controller的relabel-order:create权限约束，预览下载保留list只读访问；原PDF校验、50MiB及上传接口保持不变，上传处理中防重复，失败在详情保留诊断，旧请求结果不覆盖另一业务号。箱唛映射表将原明细PDF动作放前，长文件名使用LineClampText；缺失FBA仓码显示“—”，不再回退内部仓ID。共享RelabelDocumentsPanel只重排原两列，脚本逐字未变；换标详情及尾程详情两个直接消费者均纳入回归，不增加原来省略的文件名字段或修改分类/下载规则。
+
+自动检查：14个文件、147项定向检查、类型检查、最终构建通过；全量438个文件、3889项测试通过。均经统一local-check入口串行执行，沿用用户授权的Node 6GB堆上限。39项冻结源码、直接消费者、API、权限依据、测试、共享组件、生成声明及构建输入前后哈希一致；服务端Controller、API、依赖与生成声明未修改，git diff --check通过。
+
+截图410—430唯一维护在[跨模块清单](Admin国内仓样式核对记录.md)，视觉待人工1920×1080、100%缩放截图确认。本批仅本地Mock验证，未创建/审核/作废真实换标、推进完工、退回PDA、上传业务文件、写入测试数据、提交、推送或部署。下一组接续海外仓托盘管理，其他Admin模块仍待整理。
+
+## 统一弹窗整理：海外仓托盘新增与编辑（2026-10-20）
+
+| 操作 / 当前承载 | 本组目标 | 保留边界 |
+|---|---|---|
+| 新增托盘，760px AppDialog | 一张浅黄连续资料表、横排标签、原生全屏 | 原8项字段、默认值、五种类型、三种状态、容积/价格精度、必填校验及创建载荷 |
+| 编辑托盘，同一760px窗口 | 托盘编码标题、仓库普通文字、读取/保存锁定 | 原固定仓库、当前服务端版本含0、更新载荷及权限 |
+| 编辑详情读取 / 失败 | 留在业务号窗口、诊断与同范围重读 | 原仓库与托盘字符串标识，失败不显示上次编辑资料、不允许提交 |
+| 候选读取 / 失败 | 原候选来源、弹窗内错误与重读期间门禁 | 原公共收货仓和ACTIVE FBA仓；不按客户缩小候选、不新增候选协议 |
+| 保存 / 失败 / 取消 | 防重复、失败保留、关闭重开默认值 | 原验证、完整请求、更新版本及关闭丢弃规则 |
+| 单张打印与独立详情 | 沿用现有PDF下载和只读路由 | 不创建打印预览弹窗、不改模板、原仓库/托盘标识及下载URL释放 |
+
+实施结果：760px弹窗增加原生全屏，原顶部标签/双列栅格改为横排120px标签与连续资料表；只使用共享浅黄录入背景，不增加左侧强调线和嵌套汇总。编码、类型、容积、采购价格、海外仓、FBA仓、状态、备注共8项模型绑定保留；编辑仓库直接展示名称和仓码，其余资料继续可编辑。原容积四位/价格两位、必填规则、备注500字上限保持；备注使用两行并显示字数。
+
+编辑窗口先显示托盘业务号与读取状态，读取成功后才显示表单；失败保留本次对象并提供诊断和原仓库/托盘范围重读。候选来源与读取逻辑保持原样，原上下文失败同时出现在弹窗并阻止保存，重新读取时锁定关闭。读取、保存和候选重读过程中锁定编辑、关闭及再次打开；创建/编辑入口和保存方法核对原独立权限。保存失败留窗保留原输入，版本冲突不静默覆盖或改写旧请求版本。
+
+原8项绑定、必填验证、payload构造与创建/更新请求、候选/列表读取、标签打印函数经修改前后逐字比对均保持；不修改API、权限码、模型、独立只读详情或服务端模板。单张打印继续使用现有鉴权PDF下载，不新增预览承载。
+
+自动检查：8个文件、109项定向检查、类型检查、最终构建通过；全量439个文件、3898项测试通过。均经统一local-check入口串行执行，沿用用户授权的Node 6GB堆上限；29项冻结源码、直接依赖、原API/模型/权限、测试、生成声明及构建输入前后哈希一致，git diff --check通过。主截图清单1—440号连续、无重复。
+
+截图431—440唯一维护在[跨模块清单](Admin国内仓样式核对记录.md)，视觉待人工1920×1080、100%缩放截图确认。本批只使用本地Mock，未创建或修改真实托盘、下载业务标签、写入测试数据、提交、推送或部署。下一组接续海外库位管理，其他Admin模块仍待整理。
+
+## 统一弹窗整理：海外库位维护（2026-10-20）
+
+| 操作 / 当前承载 | 本组目标 | 保留边界 |
+|---|---|---|
+| 新增 / 编辑，560px AppDialog | 连续录入、横排标签、原生全屏、固定仓库普通文字 | 公共收货仓、普通库位、原仓库及库位标识、原创建/更新接口 |
+| 候选加载 / 保存 / 失败 | 明确加载和诊断、防重复、失败保留原输入 | 原候选与查询、关闭规则、原权限；不新增服务端接口 |
+| 启用 / 停用，ElMessageBox | 原业务编码确认、统一密度与操作锁定 | 原NORMAL资格、A0/共享溢出与虚拟库位保护、原状态请求 |
+| 删除，ElMessageBox | 停用且无托盘的普通库位确认、处理中和失败反馈 | 服务端禁止A0/虚拟库位和绑定托盘删除，前端不扩大为其他类型 |
+
+实现前契约核对：现行LocationRequests.SaveRequest只接收locationCode、locationType、maxLoadKg、status、remark，没有库位名称；最大承重必须大于0。WarehouseResourceService的状态包含INACTIVE，不包含DISABLED，且禁止删除虚拟库位。原页面存在无保存字段的名称输入、INACTIVE编辑默认成ACTIVE及删除入口只判断DISABLED的问题；本组在弹窗收敛时按现行契约修正，不增加名称接口或修改服务端。托盘全量检查通过并核对冻结输入后才写入库位改动。
+
+实施结果：560px新增/编辑增加原生全屏，统一浅黄连续单列表与110px横排标签，不再使用顶部标签及本地editor-grid外观。海外仓、库位编码、承重及备注4项实际可保存资料保留；移除没有保存接口的库位名称输入。编辑固定海外仓采用名称和仓码普通文字；标题携带原库位编码。取消后新建恢复原默认仓库、空编码/承重与备注，全屏不清空输入。
+
+编辑INACTIVE库位保留停用状态，已停用筛选直接提交INACTIVE；最大承重增加有限正数校验、最小0.001，保留三位精度及kg单位。删除资格收敛为NORMAL、INACTIVE且无托盘，保留A0编码、共享溢出类型/标记和虚拟库位保护。启用/停用与删除仍采用原ElMessageBox，统一密度、业务编码及危险语义，原创建/更新/状态/删除API、完整业务载荷与原版本参数保持；不宣称服务端额外校验未实现的版本参数。
+
+候选和列表错误采用原读取范围重试并显示诊断；候选失败在弹窗同时明确阻断保存。读取/保存锁定编辑及关闭，操作确认与命令执行期间锁定其他维护动作；失败保留表单或列表上下文、显示诊断，取消不发写请求。保存方法再次核对独立权限。页面不复制公共外观、无新增本地CSS，不改API、DTO、权限码、数据库或服务端。
+
+自动检查：7个文件、113项定向检查、类型检查、最终构建通过；全量440个文件、3911项测试通过。均经统一local-check入口串行执行，沿用用户授权的Node 6GB堆上限。36项冻结源码、直接依赖、原API/模型/权限、测试、生成声明、构建输入及只读服务端契约依据前后哈希一致，git diff --check通过。主截图清单1—453号连续、无重复。
+
+截图441—453唯一维护在[跨模块清单](Admin国内仓样式核对记录.md)，视觉待人工1920×1080、100%缩放截图确认。本批只使用本地Mock，未新增/编辑/启停/删除真实库位、写入测试数据、提交、推送或部署。下一组接续已注册的废弃单详情与审核窗口，其他Admin模块仍待整理。
+
+## 统一弹窗整理：废弃单详情与审核（2026-10-20）
+
+| 操作 / 当前承载 | 本组目标 | 保留边界 |
+|---|---|---|
+| 废弃单详情，920px AppDialog | 业务号标题、普通文字摘要、完整明细、原生全屏 | 原6项详情摘要、5列废弃明细及实际箱唛、只读资格 |
+| 审核并推送PDA，ElMessageBox | 业务编码、统一密度、危险提示与处理中锁定 | 原PENDING_REVIEW与discardApprove权限、APPROVE请求及客户范围，不增加驳回/取消入口 |
+| 现场照片缩略图 / 大图 | 原150px图片与原生大图查看、逐图加载/失败重试 | 原鉴权文件与客户范围、关闭/切换/卸载释放URL、迟到响应隔离 |
+| 详情读取 / 失败 | 先显示本次业务号、明确加载和原范围重读 | 原详情接口及客户参数，失败不显示上次单据资料 |
+| 客户候选 / 列表读取 | 候选及列表独立错误、原范围重读 | 原ACTIVE客户第1页200条与原筛选/分页请求，不新增候选协议 |
+
+实现前已核对CargoDiscardController：照片下载要求discard:list及显式customerId，审核由服务端核对审批权限。详情cartonMarks来自各来源的真实所选箱唛；缺失时不得据此推断“全部库存”。本组保留原审核及PDA流程、API和原生图片查看，不新增业务动作或改库存扣减。
+
+实施结果：原920px只读详情增加原生全屏与废弃单号标题，6项原摘要采用浅绿普通文字表，原5列废弃明细采用浅蓝分区；入仓码、SKU、品名和箱唛通过LineClampText单行省略并保留完整悬停及键盘内容。缺失箱唛显示“—”，不再推断全部库存；原状态流转记录以时间、状态、备注连续表承载，顺序及原展示内容保留，空照片和空流转分别明确提示。页面只维护摘要列宽、照片排列与150px业务图片面积，不复制公共外观或添加左侧强调条。
+
+详情先显示本次业务号与读取状态，失败保留本次单据及客户范围重试，不复用上次资料。图片仍经原鉴权接口读取Blob、原生ElImage大图查看，保留源照片顺序、当前索引及150px缩略图；逐图失败显示诊断和同文件重试，缺少客户范围直接阻断，不向接口传undefined字符串。关闭/切换/卸载释放URL、清除状态并隔离迟到详情及照片响应；图片读取期间仍允许正常关闭，不新增独立图片弹窗。
+
+审核仍使用原ElMessageBox和原APPROVE请求，原权限及PENDING_REVIEW双重资格在入口及确认后核对，确认正文包含废弃单号与推送PDA后果。确认和请求期间锁定其他操作及重复提交；失败保留列表并显示诊断，取消/关闭不发写请求。原6项摘要、列表请求构造和审批调用逐字核对保持；不增加驳回/取消业务动作、审批载荷、API、权限码或服务端变更。
+
+客户候选和列表各自加载、错误诊断及原范围重读，客户读取失败不阻断其他列表条件；候选仍为原ACTIVE第1页200条。查询采用原字段/分页参数，旧查询响应不会覆盖新结果。列表操作显式采用公共文字操作样式，操作列保留首列固定并扩为180px容纳原两项动作；状态缺失显示“—”。
+
+自动检查：8个文件、121项定向检查、类型检查、最终构建通过；全量441个文件、3925项测试通过。均经统一local-check入口串行执行，沿用用户授权的Node 6GB堆上限。45项冻结源码、直接依赖、原API/模型/权限、测试、生成声明、构建输入及只读服务端契约依据前后哈希一致，git diff --check通过。主截图清单1—469号连续、无重复。
+
+截图454—469唯一维护在[跨模块清单](Admin国内仓样式核对记录.md)，视觉待人工1920×1080、100%缩放截图确认。本批只使用本地Mock，未审核真实废弃申请、推送PDA作业、下载真实业务照片、扣减库存、写入测试数据、提交、推送或部署。下一组接续退货库存/箱号及原合箱作业窗口，其他Admin模块仍待整理。
+
+## 统一弹窗整理：退货库存合箱与箱号（2026-10-20）
+
+| 操作 / 当前承载 | 本组目标 | 保留边界 |
+|---|---|---|
+| 创建合箱计划，1380px AppDialog | 连续基础/来源/备注表、原生全屏、正文单一滚动 | BOX整箱和SKU部分两模式、原物理箱唛+SKU数量绑定、原来源分页/过滤/上限与创建请求 |
+| 合箱计划详情，1400px AppDialog | 普通文字摘要、来源/流向/完成时快照、原生全屏 | 仍读取原本页计划快照，不新增详情接口；原预计取出/剩余和实际完成数量、当前箱唛打印资格 |
+| 退货箱号详情，1080px AppDialog | 业务箱唛标题、只读资料与合箱流水、全屏及读取失败重试 | 原11项箱号资料、换标实际/占用数量、箱内SKU、来源/目标和流向 |
+| 计划审核 / 取消 | 原直接审核与ElMessageBox取消确认、处理中互锁 | 原状态资格、原请求与释放库存语义；不新增业务确认步骤 |
+| 箱唛打印 | 保留现有浏览器HTML打印入口 | 原鉴权标签、opener隔离、服务端printableHtml及打印内容/尺寸，不生成第二套模板 |
+
+实现前已核对PlatformReturnPackingPlanController和PlatformReturnInventoryController：创建/审核/取消要求退货库存列表权限和lastleg:inventory:manage；来源选择另要求退货箱号列表权限；箱号详情/标签要求退货箱号列表权限。本组补齐对应前端资格与只读状态，不改变服务端权限或库存流程。退货客户候选原有全分页、公共收货仓、来源分页与旧查询隔离继续保留。
+
+实施结果：原1380px创建、1400px计划详情、1080px箱号详情均增加原生全屏，保留两个详情原无底栏承载。创建采用110px横排标签、浅黄基础/备注和浅蓝来源连续表，8项原模型绑定集合无缺失；BOX与SKU来源分别采用原选择方式，保留箱唛、来源退货单、载体、完整混箱SKU和逐物理箱+SKU数量。移除原260px内部纵向滚动与窗口resize覆盖，来源表头继续粘性定位，正文使用AppDialog单一滚动。两行备注保留1000字上限及原锁源/新箱/PDA箱规说明。
+
+原来源分页、去重筛选、BOX包含任一SKU、SKU精确匹配、模式切换清空及数量归集函数逐字保持；增加正整数/可用上限校验和整数控件，不改原提交计算及API。原幂等键生成从每次提交移至本次打开或深链打开，失败重试保留原键和输入，关闭/成功后结束本次键；不新增HTTP协议或恢复流程。读取失败显示同范围诊断/重读，候选失败不误示空库存；客户与仓库仍由原allSettled入口加载，客户全分页和公共仓来源保留。来源关闭/切换/卸载隔离迟到结果并停止继续分页；提交期间锁定编辑与关闭，阻止重复提交。
+
+计划详情保留原本页快照，不新增服务端详情接口。6项摘要改为浅绿普通文字，来源、流向和完成/计划明细采用同级连续分区；原计划来源/取出/剩余与完成箱计算函数逐字保持，完成时快照和当前可打印箱资格分开显示，原说明及箱规/重量/时间/操作员保留。打印当前箱唛操作列前置，已MERGED或清空的当前箱仍不可打印；无箱号列表权限时隐藏打印操作列。
+
+箱号详情保留11项原资料、换标实际完成/占用数量、箱内SKU和合箱流水；摘要改为普通文字，业务号/中文品名使用LineClampText保留完整悬停与键盘内容，缺失合箱计划号显示“—”，不推断现场或历史流程。读取先显示本次箱唛，失败在原范围重试，不显示上次资料；关闭/卸载隔离迟到响应。原标签读取及popup.opener=null、原服务端HTML写入、focus/print正文逐字保持，不改变打印尺寸或模板；增加重复打印门禁和失败诊断。
+
+原直接审核不增加确认步骤；取消仍使用原密度ElMessageBox，确认中携带计划号与释放来源库存后果。创建/审核/取消/来源/箱号及标签分别按当前Controller权限核对，管理动作互锁，失败保留表单或列表，取消不发写请求。四种主列表仍采用原查询/分页和独立偏好键，补充错误诊断及原范围重读，旧查询响应不覆盖新结果。原14项列表/业务测试全部保留，只为明确授权场景补入权限Mock，并将一处点到表格隐藏测量行的详情选择器改为真实箱唛行，增加业务箱唛请求断言。
+
+自动检查：8个文件、127项最终定向检查、类型检查、最终构建通过；全量442个文件、3939项测试通过。均经统一local-check入口串行执行，沿用用户授权的Node 6GB堆上限。56项冻结源码、直接依赖、原API/模型/权限、测试、生成声明、构建输入及只读服务端契约依据前后哈希一致，git diff --check通过。主截图清单1—496号连续、无重复；另已只读核对ReturnInventoryService对同幂等键请求内容的hash校验，本组不改服务端协议。
+
+截图470—496唯一维护在[跨模块清单](Admin国内仓样式核对记录.md)，视觉待人工1920×1080、100%缩放截图确认。本批只使用本地Mock，未创建/审核/取消真实合箱计划、打印真实箱唛、占用/释放库存、写入测试数据、提交、推送或部署。下一组补齐库存流水与国内入库共用的入仓码关联数据窗口，其他Admin模块仍待整理。
+
+## 统一弹窗整理：库存与入库关联数据（2026-10-20）
+
+| 操作 / 当前承载 | 本组目标 | 保留边界 |
+|---|---|---|
+| 国内入库单 / 海外库存流水 → 入仓码关联数据，1060px AppDialog | 两个实际入口显式dense、原生全屏、只读分区与长文本 | 原三个独立权限、原三个读取API与业务号，默认非dense样式保持 |
+| 订单基础 / 装柜PDA / 海外库存 | 公共背景、连续普通文字、完整业务标识及库存数 | 原6项基础、6项装柜、客户/仓库、尾程单/计划/托盘和SKU库存，不显示内部ID |
+| 空码 / 无权限 / 未找到 / 局部失败 | 原警示、局部空态与各分区诊断/重读 | 仍只查当前允许的读模型，原重试重读全部允许分区，不新增接口或权限 |
+| 关闭 / 切换 / 卸载 | 原可在读取中关闭、迟到响应隔离、清理读取状态 | 不改readonly承载及请求作用域，修正空码/无权限提前返回时旧loading未清理的问题 |
+
+实际直接调用方仅InboundOrdersView与InventoryTransactionsView，另有共享组件合同测试；不会把原关联框重新引入统一订单或InboundTaskList。dense外观通过现有显式参数启用，默认模式不启用新背景或全屏；原API、显示字段、合法业务编号回退和权限过滤保持。
+
+实施结果：原1060px框架通过现有dense参数增加原生全屏，国内入库单实际入口同步显式启用dense，海外库存流水入口继续保持显式启用。基础/装柜采用公共只读来源背景，海外入仓与库存采用汇总背景；标题与状态仍同行，保留无底栏、destroy-on-close和读取中可关闭的原承载。旧边框、背景、15px标题、正文高度/内边距仅限制在默认非dense模式，删除原dense零边框/零内边距及通用字体覆盖，避免抵消公共背景；新模式只配置两列、宽行、表头及内容约束。
+
+原6项基础、6项装柜、海外客户与仓库、完整尾程单/入库计划/托盘、SKU/产品和库存箱数全部保留。dense长值使用LineClampText，尾程单/计划/托盘采用同一连续资料表的宽行及两行省略；原状态组合文本、顺序及柜号/柜次业务号回退保持，数量0仍显示。非dense保留原标题属性、旧列表和布局，不启用新背景/全屏/长文本组件。真实未找到与已找到但无SKU库存分别提示；原仓库未分配和名称未返回语义不变。
+
+三个权限过滤和API任务段经前后逐字对比未改，继续只读当前允许的服务端读模型，各分区错误保留诊断及原重试读取全部允许分区规则。修正空码/无权限提前返回及关闭时旧loading未复位；卸载增加serial失效，切码/关闭/权限变化后的迟到结果不覆盖当前数据。不改请求路径/参数/访问域或后端契约，不新增业务动作。
+
+自动检查：10个文件、139项最终定向检查、类型检查、最终构建通过；全量443个文件、3951项测试通过。包含共享默认/密度两模式、真实Element过渡关闭、国内直接页面及海外真实API Mock挂载，均经统一local-check入口串行执行，沿用用户授权的Node 6GB堆上限。66项冻结源码、直接调用方及其测试、原API/模型/权限、共享组件、生成声明与构建输入前后哈希一致，git diff --check通过。主截图清单1—510号连续、无重复。
+
+截图497—510唯一维护在[跨模块清单](Admin国内仓样式核对记录.md)，视觉待人工1920×1080、100%缩放截图确认。本批仅本地Mock，未读取真实关联数据、写入测试环境、提交、推送或部署。下一组接续预约管理当前日历入口的新增FBA与计划到仓窗口，其余原业务办理分支继续逐操作整理。

Admin消息中心样式核对记录.md

@@ -16,3 +16,20 @@
 本次只调整样式，消息发送、标记已读、模板写入、取消与重试均仅使用离线 Mock 验证，不向真实账号发送消息。42 项定向检查、253 个文件 / 1981 项全量测试、类型检查、构建和 git diff --check 均通过；本地 Vite 五个组件资源均返回 200。三个列表、两处抽屉、两处编辑弹框及状态确认均待人工在 1920×1080、100% 缩放下截图确认。
 
 对五个组件的脚本 AST 与修改前比较，排除样式导入和确认框 customClass 后相同。新增原生 Element Plus 挂载用例核对了按权限查看/已读、任务与模板状态操作、两处详情抽屉、模板不可变编码/变量预览/版本及定时发送表单。实际字段校验、消息发送及服务端结果仍由人工业务验收补充。
+
+
+## 2026-10-20 蓝白样式接入
+
+沿用上方六行逐操作矩阵。三个正式列表及新建消息/模板编辑两个弹框显式接入主题；列表使用外层 `workbench-table`，两个弹框自身带 `admin-workbench is-dialog`，我的消息和任务详情仍分别为 680px/820px 抽屉并声明 `admin-workbench is-drawer` 独立主题作用域。取消/重试、激活/禁用确认同样显式接入；正文、模板变量、接收范围、失败原因和投递明细保持原语义。
+
+消息中心定向回归通过；全量门禁由总控统一执行，所有修改后的状态及浮层均待人工截图确认。未新增渠道、草稿、导出或业务写入，未部署。
+
+
+2026-10-20 用户追加修正：整页主列表与详情外壳使用 `is-page-surface` 取消外围整圈边框、圆角与阴影，页面保持连续白底；本组共 22 处主列表和 6 处详情容器，内部子表、指标/图表卡片、独立并列面板及弹框保持原边界。布局、内边距和脚本不因本修正改变；公共规则与全量门禁由总控统一收口。财务相关三文件 41 项定向复验通过，视觉仍待人工截图确认。
+
+
+## 2026-10-21 弹框可用性回归
+
+新建消息的模板变量名称来自服务端白名单，原来与普通字段共用固定 100px 左侧标签；长英文变量名没有换行约束。仅将变量字段标签上置，使用自动宽度及允许单词内换行，其他发送设置、定时选择、权限和请求数据保持。真实组件挂载新增长变量名与发送载荷回归，和原全屏、失败保留草稿、关闭/重开及详情抽屉用例共 22 项通过。
+
+仍待用户截图核对长变量标签、输入区、定时发送、长正文和错误状态；不以挂载测试替代排版与正文/页脚滚动验收。公共 CSS 与 AppDialog/AppDrawer 修复由唯一公共写者集成，本域不覆盖公共规则；未打开浏览器、未截图、未部署。

Admin财务管理样式核对记录.md

@@ -41,3 +41,16 @@
 2026-09-14 检查结果：财务、公共密度和导出提示定向测试 183 项通过；全量 `pnpm test --maxWorkers=4` 为 251 个文件、1950 项通过；`pnpm typecheck`、`pnpm build`、`git diff --check` 通过。新增/编辑、审核、上传、部分核销、金额守恒及导出行为沿用原有财务测试，未删除这些业务断言。
 
 代码检查与财务行为测试不等同于视觉验收；所有本轮修改后的页面和弹框仍待人工在 1920×1080、100% 缩放下截图确认。
+
+
+## 2026-10-20 蓝白样式接入
+
+保留上方六菜单、11 路由和逐操作矩阵。五个主体页面显式接入蓝白主题，两个应收/应付路由封装继续复用同一主体；列表、流水、充值申请和对账单明细通过外层 `workbench-table` 接入，独立结算/对账单详情使用 `workbench-panel is-flush`，表单与凭证弹框分别声明主题作用域。保留行密度、宽表横向滚动、原有权限、幂等、金额和危险状态；未恢复没有当前路由消费者的 `CustomerStatementsPanel`。
+
+应收款统计打印继续隐藏查询、工具栏与分页，并在打印媒体中取消新增页面内边距、卡片阴影，沿用原打印尺寸。直接 `el-table` 的主题支持由总控公共样式统一集成，不在财务模块复制配色规则。财务相关定向回归通过；本组共同 SFC/绑定核对及 61 文件 611 项定向结果见客户管理核对记录的同日结果。全量门禁由总控统一完成；11 路由及弹框仍待 1920×1080、100% 人工截图确认，未发布。
+
+
+2026-10-20 用户追加修正：整页主列表与详情外壳使用 `is-page-surface` 取消外围整圈边框、圆角与阴影，页面保持连续白底；本组共 22 处主列表和 6 处详情容器，内部子表、指标/图表卡片、独立并列面板及弹框保持原边界。布局、内边距和脚本不因本修正改变；公共规则与全量门禁由总控统一收口。财务相关三文件 41 项定向复验通过，视觉仍待人工截图确认。
+
+
+2026-10-21 浮层回归抽查：实际挂载检查客户账户充扣/授信/充值审核与凭证、费用来源和对账单生成/调整、应收应付创建与部分核销。沿用当前表单、宽表、错误和草稿逻辑，本批未发现需改写财务展示文件的新问题。相关选定行为回归通过；公共浮层修复合并后，普通/全屏、错误长文、凭证二级预览和正文/底部操作仍待人工截图确认。

Admin货柜管理样式核对记录.md

@@ -1,5 +1,341 @@
 # Admin 货柜管理样式核对记录
 
+> 文档职责：仅维护模块范围、业务例外与检查／截图记录。通用样式统一以 [Admin 界面规范](Admin高密度界面规范.md) 为准；下文日期批次中的旧外观不再作为新改造要求。普通样式任务只在涉及本模块范围、例外或验收证据时查阅本文。
+
+## 拖车预约说明提示清理（2026-10-21）
+
+依据用户本轮拖车预约详情截图：移除说明图标及其提示内容，让页面更清爽。
+
+| 页面 / 操作 | 现有承载与截图依据 | 本次变更 | 验收 |
+|---|---|---|---|
+| 拖车预约详情 | 原独立详情页；截图中的历史关联快照、拖车费、派车信息 | 删除三处 InlineHelp 及无用导入/样式；共享表单的新建与编辑入口同步移除费用和派车说明 | 定向5文件44项通过；待人工1920×1080、100%截图确认 |
+| 拖车预约详情 → 单号去重 | 用户追加截图指出同一提单号显示四次 | 顶部仅保留预约号和状态，删除包含订舱号/提单号/订单号的副标题及历史关联快照行；订舱号在选择框、提单号与仓库在订舱带入信息各保留一处 | 定向5文件44项通过；待人工截图确认 |
+
+保留订舱/供应商业务资料、字段、折叠区、校验、权限、状态操作及真实错误/阻断提示；只对展示位置去重，不改数据或共享提示组件。
+
+本次类型检查、生产构建通过；全量4255项中4254项通过，唯一失败是并行排车文案改动后的 `overseas-warehouse/pages/prototypeContract.test.ts:264` 仍断言旧提示文字，与本次拖车提示清理无关。报告：工作区 `.codex-tmp/trucking-help-cleanup-20261021-tests.json`、`.codex-tmp/trucking-help-cleanup-20261021-full.json`。未改动排车在途文件。
+
+## 浮层隔离与附件布局复查（2026-10-21）
+
+本轮由用户反馈“推广后弹框混乱、不好用”触发，保留原承载与业务规则；不因定向测试通过关闭人工验收。
+
+| 入口 / 操作 | 代码定位与问题 | 已修范围 | 人工待验 |
+|---|---|---|---|
+| 船期详情 → 人工补录节点 | `CarrierScheduleQueryPanel` 的子 AppDialog 原留在父框 DOM 内 | 子框显式挂到 body，保留原宽度、权限和提交 | 普通／全屏、长内容、错误重试、取消重开和父框独立状态 |
+| 拖车预约 → 附件 | `TruckAttachmentDialog` 文件选择区无收缩边界 | 文件区可收缩、长文件名换行，上传／删除按钮不被挤压 | 长文件名、上传失败、全屏与重开 |
+| 货柜／预装清单 → 新增模拟柜 | `ContainerSimulationCreate` 位于 DataTable 工具栏插槽，子框仍是工具栏 DOM 后代 | 显式挂到 body；工具栏公共样式另由公共唯一写者限制作用域 | 两入口普通／全屏、底部按钮尺寸、取消重开与创建失败 |
+
+首两项定向9文件92项通过。模拟柜问题先经真实 DataTable + Element 挂载复现，第二轮4文件75项通过，保留校验、创建、取消与重开行为；公共浮层及工具栏第二轮10文件148项通过，覆盖嵌套表格和子表单密度。总控最终在 `db3b5f7157c900b885ade2626014f70c61cb0849` 输入上完成全量466文件4255项全部通过、应用类型检查与生产构建通过，1127份源码及配置快照前后一致；证据为 Admin `.logs/admin-style-audit-20261021/verification.json` 和 `full.json`。公共框架、独立主题根及工具栏选择器隔离规则统一见[风格参考](界面参考/蓝白卡片式工作台风格参考.md#弹框与抽屉的布局边界)。以上为本地代码验证，人工截图仍待确认，本轮总控未触发发布。
+
+## 智能装柜跨客户加入与箱数对齐（2026-10-20）
+
+### 智能装柜嵌套弹框回归（2026-10-21）
+
+| 入口 / 操作 | 当前承载及源码依据 | 本次问题与修复范围 | 人工待验 |
+|---|---|---|---|
+| 订单 → 智能装柜 → 加入当前柜次 | `SmartLoadingDialog → GlobalSmartLoadingView → AppDialog`，外层默认全屏且body裁切，内层920px并可全屏 | 二级弹框未声明 `append-to-body`，实际DOM留在外层裁切/主题范围内；仅二级加入独立挂载，保留失败信息和原输入 | 父子普通/全屏、长成员表、失败保留输入、取消重开、父框状态与滚动 |
+| 单柜智能装柜 → 按入仓码分配箱数 | `SmartLoadingWorkbenchView.vue`，780px确认弹框 | 四列表格右半行又套140px表单标签，标签与资料列错位并压缩输入；改用同一表格标签列并保留必填、上下限和提交 | 普通数量、整组/整托、输入及底部操作 |
+
+本轮不继续修改跨客户装柜后端或权限，保留上一轮修复及错误诊断展示。`SmartLoadingCandidateInbounds` 的展开内容与主工作台三栏暂未发现新的局部裁切规则；公共AppDialog/主题部位选择器由公共唯一写者处理。当前没有新增真实页面截图，全部视觉项待人工1920×1080、100%确认。
+
+本轮与国内测量、上传直接消费者合并运行定向6文件123项复验通过；装柜部分覆盖 `GlobalSmartLoadingView`、`SmartLoadingWorkbenchView`、`SmartLoadingDialog`。新增实际DOM断言证明二级加入位于外层工作台之外，取消不关闭父框，父子全屏独立，重开恢复原输入初始化；原待审核/普通/整托/同柜组提交、失败保留输入与诊断断言保留。仅两份装柜展示文件有变化，业务脚本一致；普通/全屏高度、滚动、分页及底部按钮实际视觉仍待人工截图，不因自动检查通过宣称验收完成。
+
+用户截图 `codex-clipboard-708cec4f-a0c5-4f76-a2f5-8bfceeb998ca.png` 反馈确认加入后提示无权限、箱数输入未对齐；原始响应为 `A0403 / 客户归属不匹配`。源码确认是 `SmartLoadingService` 将柜次关联订舱的客户快照误作候选/加入/调整的客户白名单，并被前端统一403提示掩盖；不是本次管理员缺少操作权限。
+
+后端移除该旧限制，候选、普通入仓、待审核占位、整托、调整及推荐允许跨客户，仍保留每票权威客户身份、显式筛选、权限、版本、占用、容量及作业门禁。正式语义见[阶段三4.3](头程到尾程分阶段流程/阶段三-国内货柜履约与出仓.md#43-智能推荐和人工加入)。未改IAM、网关或账号权限，也不修改测试存量数据。
+
+“本次分配箱数”改用与上方相同的原生表格标签列，输入位于其余三列，保留必填语义、原上下限及提交逻辑。加入失败及诊断标识在当前分配弹框内呈现，保留箱数输入；主工作区不重复同一错误。真实缺权限仍按原403拒绝，不自动重试或放宽授权。
+
+经 `local-check.ps1` 完成前端定向2文件50项测试及类型检查，均通过。后端定向 `SmartLoadingServiceTest` 的 Maven 检查已完成生产源码编译，但测试编译被工作区另一处 `FirstlegDocumentNumberGeneratorTest` 的3处旧 `JdbcTemplate` 构造参数阻断，尚不能认定服务回归通过；未改写该编号重构的在途文件。跨客户候选、普通加入和待审核加入的回归断言已同步。未部署，真实接口与1920×1080、100%缩放下的对齐效果待更新服务后人工确认。
+
+## 货柜详情截图反馈（2026-10-20）
+
+依据用户截图 `codex-clipboard-3e6e27f8-10fe-4b74-93a3-0bcd5ead5a11.png`，本次只调整共享货柜详情及其实际消费的异常、履约轨迹展示；当前工作区的其他在途改动保留。
+
+| 页面 / 操作 | 截图依据与当前承载 | 本次结论 |
+|---|---|---|
+| 国内 / 海外货柜详情、页签切换 | `ContainerDetailView.vue` 独立页面，摘要后有较大间距；Element 页签混用原生按钮组布局类 | 采用现有 compact 页面间距，页签只用 Element 密度原语；保留路由、返回、页签及其权限 |
+| 货柜信息与异常只读 | 六项字段以四列排布，最后半行空白；无异常记录仍显示表头 | 六项按两行三列展示；空异常只保留提示，有记录时保留原表头与完整历史 |
+| 船期维护与历史 | 船名航次标题、按钮、资料各占一行；长船名航次换行较多 | 维护入口移至标题同行，船名航次列加宽；原船期弹框、读写权限与保存流程不变 |
+| 履约轨迹与人工补录入口 | 五列无表头列表，操作人字号偏小，说明与来源区域难区分 | 高密度模式复用公共资料表，增加时间、类型、事件、说明、操作人 / 来源表头；完整换行，保留记录与排序；非高密度消费者继续沿用原列表，人工节点仍使用原弹框 |
+
+首次定向10文件195项及类型检查通过。随后其他任务更新公共密度样式，定向复验10文件196项中193项通过；3项公共合同失败指向本次未修改的 `UnifiedOrdersView.vue`、`DispatchesView.vue`、报废页面的缺失闭合标签。本次货柜布局合同、全部9个直接业务测试文件继续通过。构建已执行，在类型检查阶段被海外仓换标订单 `RelabelOrdersView.vue` 的缺失变量错误阻断；不改写其他任务在途页面以消除失败。
+
+全量检查完成：455个文件通过、9个文件失败；4099项通过、5项失败，另7个测试套件加载失败。失败证据包括其他页面未解决的合并标记、缺失闭合标签、重复插槽、测试文件加载失败，以及模拟柜表单字段数与其测试断言不一致。检查期间公共 `adminDensity.css`、`adminWorkbench.css` 及公共合同继续发生变化，此结果不作为全工作区冻结验收；本次三个业务组件及轨迹测试的散列保持一致，差异空白检查通过。未部署，视觉待人工在1920×1080、100%缩放下截图确认。
+
+## 智能装柜弹框截图优化（2026-10-20）
+
+依据用户截图 `codex-clipboard-79bcfb9c-3433-4b62-af9c-d3e6a4bbce19.png`，保留 `SmartLoadingDialog → GlobalSmartLoadingView` 的默认全屏、普通尺寸、三栏作业和二级分配弹框。
+
+| 操作/区域 | 截图与现有实现 | 本次结论 |
+|---|---|---|
+| 主工作区 | 中间柜次栏占20%，候选客户列70px，左右关键数量/重量/体积排在较后位置 | 中间改240px，左右共享剩余空间；客户、数量与重量/体积优先，托盘和规则等字段保留横向查看；不缩小行高、字号 |
+| 柜次选择 | 卡片重复标题与柜次号；无集装箱号显示“空柜” | 柜次号作主标题，保留柜号、渠道、仓库/柜型和选择态；缺柜号显示“模拟柜次/待补录”，不推断货物为空 |
+| 查询 | 两个日期框均只显示“开始日期/结束日期” | 明确创建和预计到货起止含义，保留查询参数、布局偏好和原查询/重置事件 |
+| 普通/全屏与滚动 | 外层边缘贴紧；表格撑满高度后分页仍占用额外空间 | 正文保留紧凑边距，普通模式加宽；三栏各自滚动，表格与分页共享列高；保留原关闭/重开和全屏状态行为 |
+
+本次只改上述组件的展示配置、模板和局部布局；API、权限、计划状态、数量/金额计算与提交逻辑保持。顶部去掉与右侧容量条重复的重量/体积，分配箱数明确归属当前柜次。视觉结论待人工1920×1080、100%截图确认。
+
+已落实为：柜次栏240px，左右按1.05:1分配剩余空间；客户列120px、入仓码180px，数量及重量/体积前移，其他字段和固定操作列保留。普通弹框加宽至最多1840px，正文保留公共12px紧凑边距；主弹框正文样式限定在直接子元素，不串入二级弹框。表格和分页改为同列伸缩，柜次卡片压缩重复标题并保留长编号换行与键盘焦点。
+
+经 `local-check.ps1` 完成定向3文件51项覆盖，首轮一项旧“柜子数量”文案断言失败，更新后工作台47项复验通过；主弹框作用域最后2项复验通过，类型检查及差异空白检查通过。业务脚本核对仅查询展示参数和列配置有变化。未部署，未自行打开浏览器；普通/全屏、长编号、空态、宽表和分页的实际布局待用户截图确认。
+
+## 蓝白工作台接入矩阵（2026-10-20）
+
+本批按[蓝白样板](界面参考/蓝白卡片式工作台风格参考.md)接入，复用本记录及国内仓固定编号，不另建进度表。保留原独立详情、弹框、嵌入工作台、打印和表格尺寸；本批未部署，人工视觉均待 1920×1080、100% 截图确认。
+
+用户随后要求移除包住整页主要内容的整圈边框：货柜、预装/装柜清单、订舱、拖车、报关、国内出仓和船期信息的主列表外壳，以及清单非内嵌独立详情增加 `is-page-surface`。公共去边框规则和页面边距由总控维护；嵌入清单、智能装柜三栏弹框/子表格、详情内部独立分区和各业务弹框保留原边框。本批仅修改14个源码中的15处模板类名并补记原矩阵，不改 padding、脚本、打印或业务承载，不重复全量检查；待人工截图确认。
+
+用户继续指出详情主面板重复 padding：`LoadingListDetailDrawer` 的 `workbench-panel is-compact is-page-surface` 在独立清单详情叠加页面12px，在货柜清单页签叠加外层业务卡14px。本次由公共屏幕样式将显式主面板 padding 设为0；页根、货柜独立业务卡及原打印内距保留，组件参数、业务脚本和操作承载不变。独立预装、正式装柜清单和国内／海外货柜清单页签均为直接回归范围，视觉待人工新截图确认。
+
+顶部排列收口：共享 `ContainersView` 的“未完结/已完结”页签移至 `DataTable #toolbar-start`，替代重复列表标题，保留原状态类并加入 `workbench-list-tabs`。查询仍在 `filters`，新增模拟柜与其他操作位置、权限和事件不变；`ContainerWorkbenchView` 的国内装柜/海外清关提柜属于业务阶段切换，保留外层独立导航，不与列表状态页签合并。预装/装柜、订舱、拖车等无同级业务页签的列表仅沿公共工具栏紧凑规则，不删标题。视觉待人工截图确认。
+
+| 页面与代码证据（相对 Admin `src/modules/`） | 操作与现有承载 | 本批结论 |
+|---|---|---|
+| `container-loading/pages/ContainerWorkbenchView.vue`、`ContainersView.vue`：国内/海外模式 | 两个正式列表；45—51号编辑、模拟柜、订舱关联、还柜、邮件与拖车记录浮层 | 共用列表外框和阶段页签接入；现有模拟柜加宽及其他在途逻辑保留 |
+| `container-loading/pages/ContainerDetailView.vue` 及实际 Overview/Customs/Fees 子组件 | 国内/海外独立详情，52—82号还柜、DO、异常、清关、卸货、拖车、柜费、托盘打印与船节点 | 连续详情、资料/历史表及浮层主题接入，未知、失败和危险语义保留 |
+| `container-loading/pages/SmartLoadingWorkbenchView.vue`：分配表、候选表；`SmartLoadingDialog → GlobalSmartLoadingView` | 柜次智能装柜独立路由；订单列表及预装清单的全局三栏弹框和二级弹框 | 保留分配与候选布局、各栏滚动及模型面积，接入表格、面板及独立浮层主题 |
+| `loading-lists/components/LoadingListsView.vue`、`PreloadPlanDetailView.vue`、`ConfirmedLoadingListDetailView.vue`、`LoadingListDetailDrawer.vue` | 预装/装柜两类列表及独立详情；运输、备注、确认、托盘/PDF打印与柜次费用弹框 | 列表及详情接入；名含 Drawer 的内嵌详情保持原承载；打印纸张规则保留 |
+| `ocean-bookings/pages/OceanBookingsView.vue`、`OceanBookingDetailView.vue`、Documents/Print 子组件 | 订舱列表、新增/详情独立页、36—41号打印选择/PDF预览、放舱、文件替换/作废及删除确认 | 列表、资料分组与浮层接入；PDF版面、原放舱资格和不可逆警告保留 |
+| `trucking/pages/TruckAppointmentsView.vue`、Create/Detail、Form/Attachment 子组件 | 预约列表、新增/详情独立页、42—44号附件与状态确认 | 紧凑表单及详情面板接入；不改订舱快照、承运商与状态 |
+| `customs/pages/CustomsCasesView.vue`、`outbound-dispatch/pages/OutboundDispatchesView.vue` | 历史报关、国内出仓列表及原详情弹框、提交/确认操作 | 查询/表格及浮层显式接入；门禁和原操作保留 |
+| `port-schedules/pages/PortSchedulesView.vue`、Carrier/Container 面板 | 船期列表、维护/历史弹框、货柜详情履约轨迹及人工节点浮层 | 保留两类节点含义与详情滚动，统一外框及证据表 |
+
+公共组件和全量门禁由总控统一维护；本组仅做必要定向检查。接口、权限、状态、金额及业务脚本不在本批改造范围。
+
+本批实际源码清单（均相对 `apps/admin-web/src/modules/`）：
+
+| 模块 | 修改文件 |
+|---|---|
+| `container-loading` | `pages/ContainerWorkbenchView.vue`、`ContainersView.vue`、`ContainerDetailView.vue`、`GlobalSmartLoadingView.vue`、`SmartLoadingWorkbenchView.vue`；`components/ContainerCustomsPanel.vue`、`ContainerLastLegFeesPanel.vue`、`ContainerOverviewPanel.vue`、`ContainerSimulationCreate.vue`、`OceanBookingLinkDialog.vue`、`SmartLoadingDialog.vue` |
+| `loading-lists` | `components/LoadingListsView.vue`、`LoadingListDetailDrawer.vue`、`ContainerFeesPanel.vue`、`PalletLabelPrintDialog.vue`；`pages/ConfirmedLoadingListDetailView.vue`、`PreloadPlanDetailView.vue` |
+| `ocean-bookings` | `pages/OceanBookingsView.vue`、`OceanBookingDetailView.vue`；`components/OceanBookingDocumentsPanel.vue`、`OceanBookingPrintDialog.vue` |
+| `trucking` | `pages/TruckAppointmentsView.vue`、`TruckAppointmentCreateView.vue`、`TruckAppointmentDetailView.vue`；`components/TruckAppointmentForm.vue`、`TruckAttachmentDialog.vue` |
+| `customs` | `pages/CustomsCasesView.vue` |
+| `outbound-dispatch` | `pages/OutboundDispatchesView.vue` |
+| `port-schedules` | `pages/PortSchedulesView.vue`；`components/CarrierScheduleQueryPanel.vue`、`ContainerPortSchedulePanel.vue` |
+
+已完成列表真实外壳、详情卡片、资料/证据表与浮层主题接入；旧报关、出仓及船期详情的广域 `:has` 弹框覆盖和重复正文滚动已移除，使用原 AppDialog 公共框架。三栏智能装柜的表格外层保留伸缩和独立滚动；清单独立详情采用卡片，货柜页签内保持平铺；打印保留原紧凑正文内边距并去掉屏幕卡片阴影。缺失查询任务编号显示“—”。已有客户选择器、放舱修正与模拟柜1000px宽度改动均保留，未发现活动写入冲突。
+
+总控集成时需把本批49个真实消费者纳入公共合同，并补原生 `el-table` 的中性色覆盖（订单详情、测量/审核、价格版本、柜级尾程费用、清单历史、托盘打印、船期日历与出仓门禁）。这些表格保留原几何和状态色，本组未复制一套公共表格默认规则。独立查询已使用 `workbench-query`，关联抽屉已使用 `is-drawer`。
+
+本批定向65文件807项的分段检查、失败复验及最终模板编译结果统一记录于[国内仓本批检查结果](Admin国内仓样式核对记录.md#蓝白工作台接入矩阵2026-10-20)。业务脚本与本批起点的散列核对无漂移（仅排除样式及帮助组件导入）；API、类型、权限和路由未修改。全量集成检查及人工1920×1080、100%截图待总控和用户完成。
+
+新增模拟柜加宽的当前发布状态见[模拟柜宽度 TEST 发布记录](测试环境单机部署与配置契约.md#admin-simulation-width-test-20261020)，下方尚未部署为修改当时的检查记录。
+
+货柜搜索区修正的当前发布状态见[Admin 展示修正 TEST 发布记录](测试环境单机部署与配置契约.md#admin-display-fixes-test-20261020)。下方未部署说明为修改当时的记录，当前状态以主契约为准。
+
+## 新增模拟柜宽度反馈（2026-10-20）
+
+| 页面 | 操作 | 截图依据及当前实现 | 本次结论 |
+|---|---|---|---|
+| `/container-loading/domestic` | 新增模拟柜 | 用户截图 `codex-clipboard-fe50c8ba-755f-43c0-9c20-385564d80d06.png`；560px弹窗、两组横排，仓库和渠道占位文字被截断、规格说明多次换行 | 已接入高密度的货柜入口宽度改为1000px，并保留视口减28px上限；未接入高密度的其他消费者仍为560px。字段、标签、两组排列、默认柜型、规格、仓库渠道联动及创建请求不变 |
+
+定向3文件114项、类型检查、构建通过；组件测试同时验证高密度入口1000px、其他入口560px及原创建请求。全量454文件4105项中4103项通过，2项导航/海外主数据路由断言失败，分别为 `adminNavigation.test.ts` 的菜单清单及 `overseas-master-data/routes.test.ts` 的路径与权限清单；本次未修改这两处实现或断言。组件脚本未变，组件及直接测试在检查前后散列一致。本次宽度调整尚未部署，待人工1920×1080、100%缩放截图确认。
+
+## 货柜列表搜索区截图反馈（2026-10-20）
+
+| 页面 | 操作 | 截图依据及当前实现 | 本次结论 |
+|---|---|---|---|
+| `/container-loading/domestic` | 客户、关键词、柜型、状态及预计开船日期筛选 | 用户截图 `codex-clipboard-d6d00778-4a50-4222-a75e-841261550182.png`；页面将公共搜索栏最后一组设为 `width:100%; flex:0 0 100%`，日期和按钮被强制另起一行 | 删除页面的强制整行覆盖，沿用 QueryToolbar 按可用宽度自然换行；最后一个筛选与查询、重置、布局按钮继续成组。筛选字段、顺序偏好、字段宽度、查询及重置行为不变 |
+
+仅删除共享货柜列表的一行局部布局声明，不修改公共组件或筛选业务；同源海外工作台沿用同一排布。未部署；1920×1080、100% 缩放的新布局待人工截图确认。
+
+检查结果：初次定向 3 文件 / 118 项、类型检查、构建通过；全量执行 448 文件 / 4056 项通过，但期间其他任务修改了 16 项源码输入，该结果不作为最新工作区冻结快照的完整验收。补查本页、模拟柜直接依赖、公共搜索栏及密度合同共 120 项，119 项通过，1 项失败：另一处修改删除了模拟柜说明中的“创建后自动生成柜次号”，`ContainersView.test.ts:632` 的旧文案断言尚未同步。本次未改写该组件或该断言；搜索布局合同与公共搜索栏检查通过，最终类型检查及构建重新通过。搜索页面、公共搜索栏和本次密度合同在检查前后散列一致。
+
+## 统一弹窗整理：预装清单与全局智能装柜（2026-10-20）
+
+本批沿预装清单的正式详情路由，以及订单列表实际调用的`SmartLoadingDialog → GlobalSmartLoadingView`进入，依据已确认的[测量样板](界面参考/Admin弹窗样板-测量.png)和[高密度规范](Admin高密度界面规范.md)。全局智能装柜实际为候选、柜次、方案三栏数据工作台，本批保留三栏尺寸、筛选、独立滚动及默认全屏。截图编号从91接续。
+
+| 操作 | 当前承载 | 本批实施结论 |
+|---|---|---|
+| 补录/纠正集装箱号及航次 | `PreloadPlanDetailView`，620px AppDialog | 原3项字段改浅黄连续表，标题带预装单号；保留大写规范化、纠错原因、PDA状态门禁和版本 |
+| 编辑预装明细备注 | 680px AppDialog，客户备注为禁用输入 | 800px连续表，客户备注显示只读文字、原3项备注可编辑，支持全屏；保留两层版本、操作号及冲突后保留输入 |
+| 确认预装并推送PDA | 520px AppDialog，分散描述块 | 浅绿连续资料表、业务编号标题及原警告，保留外部作业员选择、可确认条件与原请求 |
+| 全局智能装柜工作台 | 默认全屏AppDialog，普通模式1600px/94vh | 接入统一标题/底栏和显式密度根，保留三栏几何、各自滚动和返回普通尺寸；行内操作接入现有公共样式 |
+| 普通/待审核候选加入 | 全局工作台`assignOpen` | 920px来源浅蓝、填写浅黄连续表、业务编号标题及全屏；保留普通与待审核各自API、平均毛重/体积、数量上下限及跨渠道警告 |
+| 同柜组/封托整托加入 | 同一窗口的两种分支 | 保留完整组成及不可拆提示，无部分箱数控件，继续走原子分配接口 |
+| 普通/同柜组/整托移除、移除全部未拣 | 现有ElMessageBox | 接入公共确认样式及柜次标题；原拣货保护、联动范围、数量、版本和请求顺序不变 |
+
+本批不新增PDA分配入口、装柜方式或权限，不修改三栏工作台的业务筛选和容量统计。
+
+代码已落实为91—103号，唯一截图入口继续维护在[固定编号清单](Admin国内仓样式核对记录.md#当前修改的截图核对清单)。客户备注保留换行并显示为只读文字；运输、其余备注、预装确认的原字段、权限、规范化、版本和操作号均保留。全局工作台新增显式密度根及公共行操作样式，原固定字号改为公共变量；选中柜次使用背景、边框和`aria-pressed`，去掉左侧色条。
+
+外层工作台保留默认全屏、普通模式1600px/94vh及各栏独立滚动。业务专属零内边距和隐藏外层滚动使用更明确的几何选择器，避免公共弹窗样式覆盖后引入第二层滚动。分配窗口保留目标、集装箱号、发货仓、双方渠道、未知测量值及跨渠道警告；同柜组和整托保持完整组成，无部分分配控件。移除确认只补业务标题和公共样式，原请求顺序、范围、拣货保护和版本不变。
+
+三个组件的脚本在排除标题格式化、确认框样式及密度导入后与本批起点一致。初次定向检查识别出旧固定字号和描述块标签断言；已按公共变量及同一确认表格的资料项收敛，未放宽样式所有权检查。新增真实表单验证沿用仓库现有CJS入口，避免测试导入方式影响校验器；覆盖补录/纠错、客户备注只读、全屏保留输入、双版本冲突后重试及PDA作业员必选。全局补查普通与整托精确载荷、待审核未知测量/跨渠道提示、整组和整托原子接口及批量移除。
+
+本批最终验证（2026-10-20）：
+
+- 定向8文件151项通过；类型检查、构建及Admin完整419文件3551项测试全部通过，最终四项退出码均为0。
+- 重型检查经统一入口串行执行，临时沿用用户已授权的6GB Node堆上限；项目配置、统一入口和worker并发保持原值。
+- 本批25个直接源码、测试、API、类型、公共框架、样式和依赖输入在最终完整检查前后散列一致；差异空白检查通过，生成声明、依赖清单和锁文件没有改动。
+- 当前仍在`release/test`；本批未提交或部署，91—103号继续等待人工1920×1080、100%缩放截图确认。
+- 持续目标未完成。下一组从104号整理客户管理的新增/编辑/查看、资质预览、入驻审核、账号结果及受限操作窗口；已从`CustomersView`的实际调用定位，尚未改写其原权限、资质、账号或凭据流程。当前货柜和预装清单通过不能替代客户管理及其余Admin模块验收。
+
+## 统一弹窗整理：原柜船期与智能装柜（2026-10-19）
+
+本批依据用户确认的[测量样板](界面参考/Admin弹窗样板-测量.png)及[统一高密度规范](Admin高密度界面规范.md)，沿`container-loading/routes.ts`的实际货柜列表、详情和智能装柜子路由核对。截图从83号接续；以下为修改前实施矩阵。
+
+| 操作 | 当前承载 | 实施结论 |
+|---|---|---|
+| 登记原柜船期 | `ContainerPortSchedulePanel`，1120px AppDialog，12项字段 | 原归属资料浅蓝只读表、填写区浅黄连续表、历史浅蓝，标题带柜次，支持全屏；来源、有效期与截止校验保留 |
+| 原柜船期维护及历史 | 同一窗口，1000px；4项船运资料及修改原因 | 连续表与原历史记录，去掉内部65vh二次滚动；保留原客户/订舱/货柜归属、版本、冻结请求与关闭后忽略迟到响应 |
+| 仅列表权限查看 | 同一窗口，禁用输入框 | 当前四项船运事实直接显示文字，历史保持可见；不新增写权限，不将修改原因输入当作当前事实 |
+| 普通入仓码分配箱数 | 智能装柜工作台`assignOpen`，默认AppDialog | 780px浅黄连续表，原货物、可用箱数与本次箱数紧凑横排；保留整数、上下限及原接口 |
+| 同柜组／封托托盘加入 | 同一窗口两种分支 | 原来源组成浅蓝、整组/整托事实及不可拆提示保留，无部分箱数输入；支持全屏、原子分配接口不变 |
+| 移除普通明细／同柜整组 | 两种原ElMessageBox确认 | 仅标题补柜次业务编号，保留风险提示、联动移除及原版本链 |
+
+实际列表路由经过`ContainerWorkbenchView`复用此前已整理的`ContainersView`；详情的其余直接子面板及打印/费用窗口见前批固定编号。`ContainerOverviewPanel`无额外业务弹框，智能装柜本页只发现上述分配窗口与两种移除确认；不以这一条路由审计推定所有Admin模块已完成。
+
+代码已落实为83—90号，唯一截图入口见[跨模块固定编号](Admin国内仓样式核对记录.md#当前修改的截图核对清单)。原柜归属、当前四项船运事实及历史快照均保留；只读账号不再显示不可编辑的灰色表单，也不将本次修改原因输入当作当前事实。写入账号保留12项首次登记、5项维护字段，以及处理中/待重试时的冻结控件和原请求。
+
+智能装柜仍为独立页面。仅重排居中分配窗口：普通入仓码保留可用箱数、本次数量、摘要及核验说明；同柜组保留全部订单和入仓片段；封托托盘继续使用原入仓组成展开组件。窗口标题显示入仓码、同柜组号或托盘号，移除确认显示柜次。未重写已存在的页头帮助改动、表内箱数编辑或原分配/移除接口。
+
+两份业务脚本在排除本批标题/样式导入，并保留本批之前已存在的`InlineHelp`导入后，与本批起点一致。初次定向6文件102项通过，覆盖原归属校验、首次来源必填、无变化不保存、冲突/失败重试、迟到响应、只读历史、全屏保留值，以及三种分配的精确请求；已将新接入的原柜船期组件纳入公共样式所有权清单。
+
+本组最终验证：
+
+- 补查托盘组成组件后，定向7文件104项通过；类型检查、构建和Admin完整418文件3545项测试全部通过，最终四项退出码均为0。
+- 检查经统一入口串行执行，临时沿用用户已授权的6GB Node堆上限；没有修改入口、项目配置或worker并发。
+- 本组22个源码、测试、类型、公共框架、样式和依赖输入在最终完整检查前后散列一致；差异空白检查通过，生成声明、依赖清单和锁文件无改动。
+- 当前仍在`release/test`，本组未提交或部署；83—90号等待人工1920×1080、100%缩放截图确认。
+- 持续目标未全部完成。下一组从91号整理预装清单详情的运输信息、备注、确认推送，以及订单列表实际调用的`SmartLoadingDialog → GlobalSmartLoadingView`及其子窗口。全局工作台通过弹窗嵌入，并非本次已处理的货柜智能装柜子路由；不以同名业务或当前路由通过推定其完成。
+
+## 统一弹窗整理：柜次费用、托盘打印与船节点（2026-10-19）
+
+本组沿货柜详情的实际调用继续，依据用户确认的[测量样板](界面参考/Admin弹窗样板-测量.png)和[高密度规范](Admin高密度界面规范.md)。修改前实施矩阵如下，截图编号从77接续。
+
+| 操作 | 当前承载与直接消费者 | 本组实施结论 |
+|---|---|---|
+| 新增/调整柜次费用 | `ContainerFeesPanel`的AppDialog，货柜详情唯一调用 | 1080px浅黄连续表，调整资料只读文字与日期/金额同表，支持全屏；保留付款校验、单票和分摊组请求及版本 |
+| 多票费用分摊 | 同一费用窗口的逐条卡片 | 同一表单内连续明细表，客户/订单/入仓码只读，金额编辑及合计末行；原分摊限制不变 |
+| 驳回/作废柜次费用 | 原AppDialog/ElMessageBox | 原白底原因/确认框，标题带业务编号；保留整组审核、原因必填和版本 |
+| 散货托盘码打印选择 | `PalletLabelPrintDialog`的760px AppDialog，货柜详情及清单详情调用 | 仅dense模式改920px，接入浅黄打印选择、浅蓝服务器清单和全屏，标题使用服务端柜号；默认模式和PDF标签格式保留 |
+| 人工补录船节点 | `CarrierScheduleQueryPanel`的620px AppDialog | dense模式改780px浅黄连续填写表和全屏，父货柜传业务编号供标题展示；默认消费者保留原排列，窗口观测时间、幂等键及原失败重试不变 |
+| 清单详情/清单打印 | 现有页内详情和`window.print()` | 保留既有承载与纸张样式；详情组件本身无额外业务弹框，不因名称含Drawer改造承载 |
+
+本组不会改写其他任务已移除的页面说明，也不将业务编号展示属性写入费用或船节点请求。
+
+代码已落实为77—82号，完整截图入口维护在[固定编号清单](Admin国内仓样式核对记录.md#当前修改的截图核对清单)。新增费用的条件付款字段及备注保留；调整资料不再使用另一套描述组件，方向、项目、供应商、结算和既有备注为只读文字，日期与金额使用原控件。多客户分摊使用同一表单内的连续明细表及合计末行，原分摊范围、正数/合计限制、整组审核和版本不变。
+
+凭证选择提示改为文件格式及最多20个，不展示内部用途枚举。托盘码仅改变选择窗口，不改服务端编号、PDF格式、按仓张数或下载文件名；未开启dense模式的消费者保留原尺寸和排列。船节点同样仅在dense模式接入新布局，默认消费者保留旧排列，业务编号只作标题展示。
+
+三个组件的业务脚本在排除展示标题及柜次上下文后与本组修改前相同。定向覆盖费用权限、候选异步过期、单票及跨客户分摊、调整载荷、已付凭证、托盘码两种密度模式的按仓打印、船节点两种布局下的冲突重试、关闭/全屏和直接货柜详情消费者。后续原柜船期窗口仍待整理，本组不代表全部货柜入口已完成。
+
+首轮定向7文件123项、类型和构建通过；完整检查发现货柜详情的一条旧源码断言将标题、计划及货柜属性拼接为固定相邻顺序，新增展示属性后失败，其余417文件3544项通过。已将该断言改为在同一个`ContainerFeesPanel`标签内逐项核对原标题、计划、真实货柜、客户及业务归属，并核对新增展示属性；没有降低原关联要求或改动运行代码。最终门禁按修正后的测试输入重新执行。
+
+本组最终验证：
+
+- 补齐直接消费者后的定向8文件134项通过；类型检查、构建及完整418文件3545项测试全部通过，最终四项退出码均为0。
+- 检查统一经`local-check.ps1`串行执行，沿用本轮已授权的6GB临时Node堆上限，未修改配置或worker并发。
+- 本组22个源码、测试、公共框架、样式及依赖输入在最终完整检查前后散列一致；差异空白检查通过，生成声明、依赖清单及锁文件无改动。
+- 当前仍在`release/test`；本组未提交或部署，77—82号等待人工1920×1080、100%缩放截图确认。
+- 持续目标仍未完成。下一组从83号进入`ContainerPortSchedulePanel`的登记原柜船期、维护/只读及修改历史，随后继续核对货柜剩余入口；不能以本组通过推定所有Admin弹窗已完成。
+
+## 统一弹窗整理：报关与尾程费用（2026-10-19）
+
+本批沿货柜详情的实际共享组件进入，不改变报关与财务流程。视觉依据为本轮用户确认的[测量弹窗样板](界面参考/Admin弹窗样板-测量.png)及[高密度界面规范](Admin高密度界面规范.md)，沿用无左色条、浅色背景和紧凑连续表。修改前实施矩阵如下；固定截图编号从62接续，人工视觉结果与自动检查分别记录。
+
+| 操作 | 当前承载 | 本批实施结论 |
+|---|---|---|
+| 标记海关异常/结果 | 460px原生弹框 | 同尺寸AppDialog、白底短表单、固定底栏；标题带申报批次，保留其他原因必填和原关闭规则 |
+| 七种报关确认/说明 | ElMessageBox | 仅补柜次号或申报批次标题，保留确认文本、原因校验、版本和资格 |
+| 新增/调整尾程费用 | 620px AppDialog | 920px浅黄连续编辑表、原条件字段与固定底栏、支持全屏；调整时所属客户显示只读文字 |
+| 付款凭证预览 | 900px AppDialog | 浅蓝预览区、业务编号标题、完整文件名；图片支持全屏，保留下载、错误和Blob释放 |
+| 四种费用确认/原因 | ElMessageBox | 标题带柜次或真实柜号，保留审核、驳回、作废及版本/幂等语义 |
+
+柜次号仅用于窗口标识，真实集装箱号仍独立作为费用写入门禁和请求字段。没有新增权限、状态、业务字段或接口。
+
+本组代码已落实为62—76号，唯一截图入口维护于[跨模块固定编号清单](Admin国内仓样式核对记录.md#当前修改的截图核对清单)。两个共享组件的脚本在排除标题格式化及新增柜次上下文后，与本组修改前完全相同；保存请求、版本、原因校验、上传异步隔离和资源释放没有变化。货柜详情只新增柜次号展示属性，费用业务编号与真实柜号请求仍使用原字段。
+
+新增交互覆盖其他原因必填及原批次版本、取消开始报关、条件付款字段、全屏保留输入、实际费用载荷、调整客户只读和真实柜号缺失门禁。已有凭证替换/移除、客户切换忽略旧上传、只读预览释放资源和报关只读/下载测试保留。样式所有权检查仅将显式`density-table--editable`内的表单按钮与列表行操作区分，普通数据表的行操作检查继续生效。
+
+本组最终验证：
+
+- 定向4文件86项通过；`pnpm typecheck`、`pnpm build`及Admin完整418文件3541项测试全部通过，最终三项退出码均为0。
+- 所有重型检查经统一入口串行执行，临时沿用用户已授权的6GB Node堆上限；没有修改项目配置、统一入口或worker并发。
+- 本组15个直接源码、测试、样式、框架及依赖输入在最终检查前后散列一致，差异空白检查通过；生成声明、依赖清单和锁文件没有改动。
+- 当前仍在`release/test`分支，本组未提交或部署。62—76号等待人工1920×1080、100%缩放截图确认，不以自动检查替代视觉验收。
+- 持续目标仍未全部完成。下一组从77号接续共享柜次费用、清单/打印及船节点窗口；本组没有将这些未整理入口计为完成。
+
+## 统一弹窗整理：货柜列表与详情（2026-10-19）
+
+本批从当前`ContainersView`、`ContainerDetailView`的12个实际居中窗口及5个ElMessageBox确认进入，沿用用户已确认的紧凑信息表、浅色背景、无左色条和固定底栏。以下为修改前实施矩阵，正式详情路由保留；不以旧版密度验收或单个消费者推定整组完成。
+
+| 操作 | 当前承载/尺寸 | 本批实施结论 |
+|---|---|---|
+| 列表 → 编辑基础资料 | `editorOpen`，820px | 17项字段改为1080px三组横排的连续编辑表；只读柜号、柜次、容量、限重直接显示文字；保持仓库/柜型等校验和原保存载荷 |
+| 列表 → 新增模拟柜 | `ContainerSimulationCreate`，560px，另由预装入口消费 | 仅dense模式接入紧凑连续表与浅黄填写区；默认消费者保留原样，仓库渠道联动和固定规格不变 |
+| 列表/详情 → 关联订舱 | `OceanBookingLinkDialog`，680px | 同一连续表展示柜次号、候选与可选真实柜号；柜次只读，业务编号标题、支持全屏；原筛选/版本/规范化不变 |
+| 列表 → 还柜登记 | `drayageActionOpen`，520px | 原短白底时间/备注表单，标题带柜次或集装箱号，原资格与版本保留 |
+| 列表 → 邮件记录／重试确认 | `emailHistoryOpen`，1100px；ElMessageBox | 只读浅蓝表格、全屏、业务编号标题；保留最近100封、正文展开、发送风险说明和重试门禁 |
+| 列表 → 码头拖车记录 | `drayageHistoryOpen`，980px | 浅绿状态汇总、浅蓝历史表格，编号标题和全屏；错误重试、列与排序保留 |
+| 详情 → 确认还柜 | `emptyReturnOpen`，520px | 原白底时间/备注表单及警告、业务编号标题；保留冻结载荷、幂等键重试与关闭保护 |
+| 详情 → DO资料 | `documentOpen`，520px | 浅黄上传区和编号标题；当前上传控件重置、替换历史及错误反馈保留 |
+| 详情 → 标记/取消异常 | `exceptionOpen`，520px | 白底原因表单及原危险/警告语义，标题带业务编号，必填原因与历史保留 |
+| 详情 → 目的港清关资料 | `clearanceOpen`，520px | 浅黄上传区、完成状态沿用原提示；上传与完成动作放入固定底栏，保留加载/提交锁定及原资格 |
+| 详情 → 直送卸货登记 | `directOpen`，1080px | 来源浅蓝表格、当前票浅黄连续表；只读票/无写权限显示文本，编辑使用原字段；支持全屏，保持冻结重试和退出保护 |
+| 详情 → 提柜安排与执行 | `terminalOpen`，780px | 当前事实与填写内容在同一连续表中；三项原业务动作移到固定底栏，支持全屏，保持权限/待重试载荷/未保存保护 |
+| 详情 → 国内出仓／三种未保存确认 | 现有ElMessageBox | 仅补业务编号标题，保留确认文本、动作、阻断和路由保护 |
+
+标题统一使用本模块的柜次号优先、真实集装箱号其次；两个业务标识均缺失时只显示操作名，不使用内部ID补位。本批未新增业务操作或字段，后续固定截图编号从45接续。
+
+本组代码已落实，固定截图编号为45—61，入口唯一清单见[跨模块截图编号](Admin国内仓样式核对记录.md#当前修改的截图核对清单)。四个业务组件的script在排除标题导入/格式化调整后与基线一致，未改动请求、校验、权限、版本、幂等键或关闭保护。直送只读内容显示实际来源记录，不把填写区的默认时间当作已签收事实。
+
+模拟柜仅在显式dense模式使用连续表；默认模式保留原表单。两个模式均通过真实表单必填校验和相同固定规格载荷检查，预装入口的创建消费者同步回归。简短说明、定制固定底栏分别使用公共`density-dialog-note`和`density-actions--footer`；页面只维护字段排列、尺寸与表格列数，不复制公共配色/字号。
+
+本组定向8文件137项通过，类型检查通过。覆盖列表与详情、国内/海外资格、版本0、还柜/提柜/签收冻结重试、关闭保护、全屏保留输入、只读签收凭据、关联订舱规范化与模拟柜两种密度模式。旧的820px双列和无业务编号标题断言已按本次矩阵更新，原业务请求与阻断断言保留。视觉仍待人工1920×1080、100%截图确认，未提交或部署。
+
+初次完整检查418文件3535项及类型/构建通过后，代码复核发现提柜事实表的空值展示还需收敛：真实柜号不能回退为柜次号或窗口标题；已绑定车队但名称缺失时显示“—”，不误称尚未安排。已修正并新增来源响应空值用例，详情交互单文件35项通过，最终完整门禁按修正后的输入重新执行。
+
+本组最终验证：
+
+- `pnpm typecheck`、`pnpm build`均通过；Admin全量418个测试文件、3536项全部通过，三项退出码均为0。
+- 所有检查经统一入口串行执行，临时沿用已授权的6GB Node堆上限；统一入口、并发限制与项目配置未修改。
+- 本组18个相关源码、测试及共享框架/样式输入在最终完整检查前后散列一致，差异空白检查通过；生成声明、依赖清单和锁文件无本组改动。
+- 本组未提交或部署。45—61号继续等待人工1920×1080、100%缩放截图确认，不以自动检查替代视觉验收。
+- 持续目标尚未完成。下一组沿实际调用处理`ContainerCustomsPanel`的海关结果与报关确认、`ContainerLastLegFeesPanel`的费用编辑/凭证预览及确认，再接续共享头程费用、清单/打印和船节点窗口；新增截图编号从62开始。没有把这些尚未整理的子窗口记为本组完成。
+
+## 统一弹窗整理：订舱与拖车（2026-10-19）
+
+本批依据《Admin高密度界面规范》的统一弹窗目标和本轮用户对紧凑布局、无左色条的确认，沿实际组件实施以下矩阵。固定截图编号接续《Admin国内仓样式核对记录》的1—35，不另行重排；代码检查与人工截图分别记录，不以旧版密度检查推定新版已通过。
+
+| 页面 → 操作 | 当前承载/直接消费者 | 本批结论 |
+|---|---|---|
+| 订舱列表／订舱详情 → 选择打印类型 | `OceanBookingPrintDialog`，1120px AppDialog；列表、详情两处调用 | 原两种PDF保留，选择区浅蓝，单选与说明紧凑排列；标题和当前订舱仅用订舱号，缺失不展示内部ID |
+| 上一窗口 → PDF预览、返回选择、下载 | 同一1120px窗口和iframe | 保留PDF载体与正常预览高度，PDF阶段增加全屏，固定原底栏；核对返回、关闭、重新选择时的选择值和Blob释放；文件名不以内部ID回退 |
+| 订舱详情 → 确认放舱 | `OceanBookingDetailView.releaseDialogOpen`，560px AppDialog | 标题带订舱号，浅绿只读资料表和原警告；去掉面向用户的数据库处理说明，保留不可修改/删除语义及原保存后放舱版本链 |
+| 订舱资料 → 替换文件／作废文件 | `OceanBookingDocumentsPanel`，现有ElMessageBox | 沿用已接入的公共确认框样式，标题带订舱号；保留文件名、二次确认、上传限制、作废历史和版本链，操作人缺失不展示数据库ID |
+| 订舱详情 → 删除草稿确认 | `OceanBookingDetailView.removeDraft`，现有ElMessageBox | 标题带订舱号，保留原不可恢复说明、删除权限、版本和成功后的列表跳转 |
+| 订舱新建／详情、资料主面板 | 正式路由与详情页内组件 | 保留现有承载；不将新建或资料面板改为弹窗 |
+
+订舱详情向共享船期组件仅传`oceanBookingId`，本页不能打开其要求`containerBookingId`的人工补录窗口；该窗口归后续货柜实际消费者整理，不将其列为订舱弹窗完成项。
+
+同批接续下一个实际菜单“拖车列表”，新增与编辑仍沿独立页面执行，仅整理以下浮层：
+
+| 页面 → 操作 | 当前承载/直接消费者 | 本批结论 |
+|---|---|---|
+| 拖车详情 → 预约附件 | `TruckAttachmentDialog`，640px原生居中弹框；详情唯一直接调用 | 收敛为同尺寸AppDialog，保留原关闭/遮罩规则和固定关闭底栏；预约号标题，上传区浅黄、现有附件浅蓝，长文件名完整换行，支持全屏 |
+| 预约附件 → 删除附件 | 原ElMessageBox确认 | 保留删除权限与忙碌门禁，标题带预约号，确认中明确文件名，不展示内部ID |
+| 拖车详情 → 状态变更确认 | `TruckAppointmentDetailView.changeStatus`的现有ElMessageBox | 原目标状态、权限及接口保留，仅标题补充预约号；改期沿用页面已有装货时间来源，未新增状态表单 |
+
+固定截图编号为36—44，完整入口继续维护于[截图核对清单](Admin国内仓样式核对记录.md#当前修改的截图核对清单)。打印选择与资料确认属于订舱列表/详情直接消费者；附件窗口由拖车详情唯一调用，正式新增、编辑和详情路由未改动。
+
+按两模块当前Vue文件中的AppDialog/原生弹框和ElMessageBox调用复核，本批覆盖3个居中窗口和5个确认框；打印窗口的选择/预览两种状态分开编号，共9个截图入口。订舱引用的共享船期人工补录窗口不在本页开放，未据此声称共享货柜窗口已完成。
+
+除业务编号标题、缺失值文案及打印资源生命周期外，订舱资料、放舱、拖车附件和状态变更的业务script经差异还原核对与基线一致；保持全部请求字段、权限、版本及文件限制。打印窗口关闭/重开后，迟到的旧请求不会创建或覆盖新的Blob预览；返回选择、退出全屏及下载仍使用当前单据与原打印类型。预览只增加本组件显式全屏布局，不修改AppDialog、公共颜色/字号默认值或PDF输出内容。
+
+本组关键交互与公共密度定向5文件63项通过，覆盖打印类型/全屏/返回/缺失编号/旧请求隔离、资料替换与作废版本链、放舱当前编辑值及附件只读/上传/删除。扩大到订舱、拖车及密度的首次定向检查发现两处新用例的挂载与Blob断言问题，已修正后复验；最终回归还覆盖全屏后保留已选附件和类型。
+
+本组最终验证：
+
+- `pnpm typecheck`、`pnpm build`均通过；Admin全量416个测试文件、3530项全部通过，三项退出码均为0。
+- 检查均经统一入口串行执行，临时沿用已授权的6GB Node堆上限；未修改统一入口、并发限制或项目配置。
+- 本组14个相关源码、测试及共享样式/框架输入在完整检查前后散列一致，差异空白检查通过；生成声明、依赖清单和锁文件无本组改动。
+- 人工视觉仍待1920×1080、100%缩放下按36—44号截图确认，本轮未提交或部署。
+- 持续目标尚未完成。下一组从货柜列表的`container-loading/pages/ContainersView.vue`开始，核对当前4个列表窗口及模拟柜、关联订舱直接消费者，再接续`ContainerDetailView.vue`当前6个窗口和其共享子窗口；国内/海外实际消费者分别核对，正式详情路由继续保留。新增截图编号从45开始，不以本组通过推定整个Admin弹窗完成。
+
 ## 本次范围与状态
 
 用户确认继续优化货柜管理的 4 个菜单。本轮按下表实现列表、独立新建/详情页、智能装柜工作台及关联弹框的密度统一。代码检查结果在文末记录；未进行本轮浏览器视觉验收，所有修改后效果均待人工截图确认。
@@ -31,7 +367,7 @@
 
 原型先读 [局部指引](悦/货代SAAS平台后台/AGENTS.md)，目标模块为 `prototype-src/modules/06-containers.html`：订舱 `page-booking-list` / `page-booking-detail`，拖车 `page-truck-list` / `page-truck-add` / `page-truck-edit`，历史货柜与装柜入口 `page-ct-list` / `page-ct-manifest` / `page-ct-board`。
 
-历史原型没有完整表达当前国内/海外双工作台，不能照其页面数量恢复旧菜单。本轮以用户确认的密度规则和当前实际组件、事件为依据，保留如下承载方式：
+当前菜单以用户提供的新版.html为准，恢复订舱、拖车、货柜、装柜清单、预装清单五个入口；货柜入口提供国内/海外阶段切换，沿用各自服务端权限与动作。本轮以用户确认的密度规则和当前实际组件、事件为依据，保留如下承载方式：
 
 | 页面/模式 | 操作与承载方式 | 当前组件与依据 | 采用公共规则/业务例外 | 验证与截图 |
 |---|---|---|---|---|
@@ -77,3 +413,18 @@
 - `pnpm typecheck`、`pnpm build` 与 `git diff --check` 通过；AGENTS 索引合同 1050 项通过。
 - 本轮业务脚本与修改前版本对比，仅增加样式导入、确认浮层类和可选密度参数，没有修改业务处理逻辑。实际浏览器加载、长数据布局、浮层普通/全屏/重开及各权限状态仍待 1920×1080、100% 缩放人工截图确认。
 - 本轮未部署、未启动后端或修改业务数据。代码验证不替代实际业务写入及视觉验收。
+
+## 新版菜单回归矩阵（2026-10-08）
+
+依据：用户提供 `新版.html`，货柜菜单 1480–1487 行、货柜列表 `page-ct-list`（8133、8162 行）、装柜清单 `page-ct-manifest`（8202 行）、尾程计划 `modal-lmo-inbound-plan`（9647 行）。本轮用户确认恢复五菜单并承接海外操作，不回退现行整柜预计到仓规则。
+
+| 页面 | 操作 | 原型承载与布局 | 本轮处理 |
+|---|---|---|---|
+| 货柜列表 | 国内、海外操作 | 同一货柜入口，宽表含清关/DO/PU/车队/到港/还柜 | 同一菜单内阶段切换，保留现有独立详情与原操作弹框；两阶段分别鉴权 |
+| 装柜清单 | 查询、查看 | 独立列表，明细在列表下方展开；宽表水平滚动 | 恢复正式列表路由，复用真实清单查询与嵌入明细 |
+| 装柜清单 | 打印 | 行内打印动作 | 读取所选清单成功后打印明细，不打印失败或过期响应 |
+| 装柜清单 | 备注、删除 | 原型备注弹框，删除为提示占位 | 当前正式已确认清单只读，不增加未经服务端支持的修改/删除 |
+| 尾程计划 | 到仓日期 | 居中计划弹框中日期输入 | 服从现行整柜统一规则，保留只读并补充带柜号跳转维护、计划生成后锁定说明 |
+| 其他既有操作 | 新增、编辑、确认、文件 | 见上方逐操作矩阵 | 保留原组件、业务权限与状态门禁，不改变提交契约 |
+
+人工视觉：待用户在1920×1080、100%缩放下截图确认。自动测试与部署结果分别记入主契约，不以源码核对代替真实页面验收。

Admin通用资料样式核对记录.md

@@ -56,3 +56,30 @@
 - 本地 5173 返回这七页及排车列表的新密度代码，HTTP 均为 200。排车列表已是纯省略号入口；代码与开发服务验证不能代替页面截图。
 
 通用 10 菜单代码检查完成，全部待人工在 1920×1080、100% 缩放下核对修改后截图。首页、系统管理另行继续。
+
+
+## 2026-10-20 客户财务基础组蓝白接入
+
+本组覆盖供应商列表/独立新增/编辑/详情及资质弹框、快递公司列表/580px 编辑抽屉/批量导入、往来单位列表/680px 详情与编辑抽屉/批量导入、费用项目列表/620px 编辑抽屉/各自确认、仓库列表/650px 编辑/760px 导入、下载中心列表/720px 任务详情。另按实际入口覆盖 `warehouse-resources` 的库位与托盘列表及原居中编辑弹框；不扩展当前页面没有的业务操作。
+
+各页面保留现有密度类并显式接入 `admin-workbench`；DataTable 的外层接入 `workbench-table`，Teleport 弹框及批量导入自身带 `admin-workbench is-dialog`，抽屉自身带 `admin-workbench is-drawer`。局部普通配色使用公共主题变量，危险色、状态、下载/重试资格和打印流程保持。当前公共批量导入消费者通过父传 class 显式接入，不修改共享组件。
+
+上述本组页面、弹框及抽屉的定向回归通过，仍待人工截图确认。全量门禁由总控统一执行；没有部署、推送或真实业务写入。海外资料和国内价格簿属于另组，其结论以对应任务为准。
+
+
+2026-10-20 用户追加修正：整页主列表与详情外壳使用 `is-page-surface` 取消外围整圈边框、圆角与阴影，页面保持连续白底；本组共 22 处主列表和 6 处详情容器，内部子表、指标/图表卡片、独立并列面板及弹框保持原边界。布局、内边距和脚本不因本修正改变；公共规则与全量门禁由总控统一收口。财务相关三文件 41 项定向复验通过，视觉仍待人工截图确认。
+
+### 列表顶部紧凑化
+
+依据 2026-10-20 用户整柜截图的最新要求，减少列表标题、操作和页签叠层；本组按实际结构核对如下，视觉待人工截图确认。
+
+| 页面或范围 | 当前结构与操作证据 | 本轮收敛 |
+|---|---|---|
+| 供应商列表 `suppliers/pages/SuppliersView.vue` | 标题与新增在工具栏；分类、统计数量和筛选另占下方区域，分类通过 `switchCategory` 切换 | 原分类导航整块移入 `toolbar-start`，保留 `supplier-tabs density-status-tabs` 并加 `workbench-list-tabs`；新增仍在 `toolbar-actions`，`QueryToolbar` 仍在 `filters`。分类图标、数量、ARIA 和事件保持 |
+| PDA 版本 `pda-releases/pages/PdaReleasesView.vue` | 国内／海外 radio 与当前 APK/WGT 信息在单独上下文行；刷新、上传在工具栏 | 原应用切换与版本事实整块移入 `toolbar-start` 并加 `workbench-list-tabs`，保留原类、radio 键盘语义、绑定、当前版本与未发布状态；刷新、上传及发布／停发确认保持 |
+| 客户、财务及本组其余标准列表 | 已有标题、操作同处工具栏，没有独立列表分类页签 | 复用总控维护的公共紧凑尺寸，不批量删除标题，不改客户费用特殊入口、汇总、状态或警告；客户详情内审计面板不参与此次列表合并 |
+
+只调整上述两页列表模板及对应既有结构断言，不改脚本、API、权限、详情或弹框。通过 `local-check.ps1` 运行 `SuppliersView.test.ts`、`SupplierRouteReuse.behavior.test.ts`、`PdaReleasesView.test.ts`，3 个文件、17 项测试通过；公共尺寸和全量门禁由总控统一维护。
+
+
+2026-10-21 浮层回归抽查：供应商资质、仓库创建/导入、快递公司编辑/导入、费用项目编辑、下载任务详情与审计详情的选定组件回归通过；本批不因静态检查未见问题就批量改写这些页面。与财务/IAM/客户费用一起，选定 12 文件 200 项回归通过；另客户与消息局部修复 56 项通过。长内容、校验、关闭重开、全屏与页脚的真实排版仍待截图，不能由挂载结果推定视觉通过。

Admin首页与系统管理样式核对记录.md

@@ -26,3 +26,16 @@
 - 本地 5173 的四页源码编译请求均为 200，并返回密度样式入口；该证据只证明开发服务提供了当前代码。
 
 此批无剩余代码检查失败；修改后视觉仍待人工截图。全模块沿组件引用继续复核，不能由四页通过推断其他共享子弹框全部通过。
+
+
+## 2026-10-20 平台用户与权限蓝白接入
+
+本组只覆盖 IAM 三个正式页面：平台用户、角色权限、菜单权限及原有 650px/860px/720px 居中编辑框、启停/删除确认。页面和浮层显式接入蓝白主题，DataTable 采用外层 `workbench-table`；保留权限树、半选、受保护账号/资源、海外 PDA 仓库绑定和未保存逻辑。活动客户远程选择器 `useActiveCustomerOptions`、公开导出及其既有在途修改均未接管。首页由本批总控负责，本节不推断首页完成状态。
+
+IAM 相关定向回归通过；全量门禁由总控统一完成，三页及其操作待人工在 1920×1080、100% 缩放下截图确认。未部署。
+
+
+2026-10-20 用户追加修正：整页主列表与详情外壳使用 `is-page-surface` 取消外围整圈边框、圆角与阴影，页面保持连续白底；本组共 22 处主列表和 6 处详情容器，内部子表、指标/图表卡片、独立并列面板及弹框保持原边界。布局、内边距和脚本不因本修正改变；公共规则与全量门禁由总控统一收口。财务相关三文件 41 项定向复验通过，视觉仍待人工截图确认。
+
+
+2026-10-21 浮层回归抽查：平台用户与角色权限实际挂载回归通过，含海外 PDA 仓绑定、权限树初始化与半选、错误后保留草稿、确认和关闭行为。本批未修改 IAM 展示文件或在途客户选择器。长权限名称、展开后的树、普通/全屏和底部保存的实际排版仍待用户截图确认；首页不属于本组回归结论。

Admin高密度界面规范.md

@@ -1,33 +1,32 @@
-# Admin 高密度界面规范
+# Admin 界面规范
 
-## 确认依据与适用范围
+本文件是 **Admin 样式的唯一主规范**，统一维护蓝白风格、业务密度、列表、详情、弹窗、提示文字与公共样式接入。沿用原文件路径，已有引用无需迁移。验收视口为 **1920×1080，浏览器缩放 100%**。
 
-2026-09-14，用户在 Admin 样式优化对话中确认订单列表样板，并要求以此推进国内仓样式统一。样板包括订单列表、测量与订单审核弹框、订单详情的基本信息、货品信息、费用信息、状态历史、测量数据、其他、拆分履约。详情页签使用与客户管理一致的彩色 Emoji 图标。
+## 按任务阅读
 
-本规范固定该样板的视觉与密度规则。验收视口为 **1920×1080，浏览器缩放 100%**。其他页面采用本规范不等于其功能或视觉已验收。
+先看本节和“基本原则”，再只读任务对应章节，不要求每次通读全文。
 
-这是一套后续 Admin 页面可复用的基线。新增菜单按“新模块接入规则”实施，不复制订单或客户模块 CSS；货柜管理的入口与共享组件边界见 [货柜管理核对记录](Admin货柜管理样式核对记录.md)。海外仓的 10 个菜单及共享详情边界见 [海外仓核对记录](Admin海外仓样式核对记录.md)。列入下一批入口不代表页面已完成改造或验收。
+| 当前任务 | 本文入口 |
+|---|---|
+| 调整列表、搜索、页签、行操作 | [列表](#列表)、[尺寸与颜色](#尺寸与颜色) |
+| 调整详情、费用、历史或测量 | [详情与基本信息](#详情与基本信息)、[费用、汇总与测量](#费用汇总与测量)、[历史、备注与空态](#历史备注与空态) |
+| 新增、编辑、审核、上传、预览或确认弹窗 | [弹框与表单](#弹框与表单) |
+| 提示小字、加载反馈、点击后页面跳动 | [提示文字与加载布局](#提示文字与加载布局) |
+| 配色、工作台、指标卡或图表 | [蓝白主题与图表](#蓝白主题与图表)；需要查看样板时再打开[样板目录](界面参考/蓝白卡片式工作台风格参考.md#其他页面该参考哪个样板) |
+| 公共样式维护或新页面接入 | [公共样式维护边界](#公共样式维护边界)、[新模块接入规则](#新模块接入规则) |
+| 确认验收方法与证据 | [前端验收规则](Admin-Client前端原型还原验收规则.md)；其中不再另定 Admin 样式 |
 
-当前推广范围包括 Admin 导航中的“国内仓”，以及本轮确认的“客户管理”两个入口：客户列表、海外仓阶梯费用，包含各入口实际使用的详情、页签、新增、编辑、审核、确认、图片/文件预览和其他业务弹框。客户管理下的海外仓阶梯费用属于客户费用配置，不扩大到海外仓作业菜单。跨菜单跳转应记录目标入口和共享组件影响；不因此把另一个菜单的全部页面自动加入改造范围。Client、PDA 与其他菜单采用规范时另行明确范围。
+## 适用范围与文档职责
 
-样板实现入口：
+- 本规范是后续 Admin 改版基线：订单与客户管理样板确立业务密度，测量样板仅供参考弹窗基础框架，其分区配色与作业布局属于局部例外；蓝白自营样板确立配色、工作台和少提示文字风格。已确认的样式优先于历史原型中的对应外观；业务字段、分组、权限、状态、API、计算口径及页面／弹窗／抽屉承载方式仍按当前业务契约和逐操作确认保留。
-
+- 规范适用于 Admin；Client、PDA 不自动套用。按用户确定的模块和操作范围逐批实施，规范统一不代表全端已改造或验收，也不授权批量替换公共默认值或发布。
-- [公共密度样式](../apps/admin-web/src/styles/adminDensity.css)：页面显式使用 `admin-density`，Teleport 弹框显式使用 `admin-density-dialog`；默认不改变其他菜单。
+- 本文只维护当前有效规则，不并列保留已被替代的通用样式。新增确认直接修改对应条款，不在文末继续追加另一套规则。代码令牌是数值的唯一实现入口，变更须同步本文对应条款。
-- [公共密度变量](../apps/admin-web/src/styles/adminDensityTokens.css)：两模块的字号、间距、控件/行/按钮/页签高度、圆角、底色和按钮语义色的唯一默认值入口。
+- [蓝白样板目录](界面参考/蓝白卡片式工作台风格参考.md)只保存页面参考和原图；[排车列表试点](Admin排车列表样式试点.md)只保存历史依据。二者不再定义通用样式。
-- [维护合同检查](../apps/admin-web/src/styles/adminDensity.test.ts)：限定已接入消费者，检查变量归属、公共样式作用域及页面重复实现。
+- 模块记录只维护本模块改造范围、业务例外、检查结果与截图证据，不覆盖本文通用规则： [国内仓](Admin国内仓样式核对记录.md)、[客户管理](Admin客户管理样式核对记录.md)、[货柜管理](Admin货柜管理样式核对记录.md)、[海外仓](Admin海外仓样式核对记录.md)、[列表推广](Admin列表样式推广核对记录.md)、[自营](../apps/admin-web/src/modules/self-operated/operation-matrix.md)。只读本轮实际涉及的记录，不要求全部加载。
-- [测量作业密度](../apps/admin-web/src/modules/inbounds/measurement/measurementDensity.css)：测量与审核共享作业布局，宽度由测量弹框自身提供。
-- [国内仓逐操作核对记录](Admin国内仓样式核对记录.md)：三组页面的承载方式、例外和验收证据。
-- [客户管理局部密度样式](../apps/admin-web/src/modules/customers/customerDensity.css)：客户列表、详情、计费与相关弹框的显式密度入口。
-- [客户管理逐操作核对记录](Admin客户管理样式核对记录.md)：两个菜单入口及关联详情、审核、编辑与预览的范围和人工验收项。
-- [订单列表与详情](../apps/admin-web/src/modules/unified-orders/pages/UnifiedOrdersView.vue)：列表、顶部摘要、描述表、页签、日志表及订单弹框。
-- [订单局部密度样式](../apps/admin-web/src/modules/unified-orders/styles/orderDensity.css)：费用、履约与测量弹框的局部样式。
-- [国内仓导航](../apps/admin-web/src/core/navigation/adminNavigation.ts)：`domestic-warehouse` 分组是菜单范围来源。
-
-本规范与 [Admin/Client 前端原型还原验收规则](Admin-Client前端原型还原验收规则.md) 配合使用。在本规范适用范围内，已确认的密度、容器和页签图标规则优先于历史原型中的大卡片、大留白和单色页签图标；字段、业务分组、权限、操作语义及页面/弹框/抽屉承载方式仍按当前业务契约和逐操作矩阵核对。样板中某个字段的专属宽度不能直接当作其他页面的固定宽度。
 
 ## 基本原则
 
-表格顶部操作栏的桌面尺寸统一由 `DataTable.vue` 维护：`padding: 6px 12px`、`min-height: 44px`。普通栏与 `.is-compact` 共用尺寸，后者只改变对齐；不再按 1920px 断点切换尺寸。公共密度样式和业务页面不得重复声明这部分 padding / height；组件现有移动端排列规则保留。
+表格顶部操作栏的基础桌面尺寸由 `DataTable.vue` 维护：`padding: 6px 12px`、`min-height: 44px`；显式接入蓝白主题的主列表使用本文“蓝白主题与图表”的 48px 最小高度。普通栏与 `.is-compact` 只改变对齐，不按 1920px 断点切换尺寸；页面不得重复声明公共 padding / height，已有移动端排列规则保留。
 
 1. 普通业务内容采用连续白底、细边框、描述表与数据表格。短字段以“标签 + 值”连续排列，不制作独立指标卡片。
 2. 先压缩重复标题、重复汇总、容器层数和无意义留白，再调整列宽与行高。正文保持可读，不通过缩小整页、浏览器缩放或截断关键值提高密度。
@@ -49,42 +48,64 @@
 | 页签图标 | 17px，固定 18px 占位，独立彩色显示 |
 | 普通表格行 | 基准 36px，单元格上下内边距 4px；按内容自然增高 |
 | 普通输入框与工具栏按钮 | 通常 32px |
-| 表格内操作按钮 | 28px，保留文字、焦点和禁用反馈 |
+| 表格内操作按钮 | 基准 28px；已接入标准列表使用纯文字行操作，保留焦点、禁用与处理中状态 |
 | 区块间距 | 通常 12px；标准列表遵守现有 ListPageLayout 的单一间距，不叠加页级空白 |
 | 普通内容内边距 | 12px；弹框正文 12px 16px |
-| 容器圆角 | 0–4px；普通数据区无装饰阴影、渐变或上浮效果 |
+| 容器圆角 | 普通业务数据区 0–4px；独立搜索区 5px、作业分区 8px、蓝白指标卡 16px 按各自规则，不叠加整页外框 |
 | 内容底色 | 白色 |
-| 表头、描述表标签底色 | 浅灰，参考 #f8fafc / #f9fafb |
+| 表格表头 | 浅蓝底 `#edf4ff`、深蓝文字 `#284b78`，标准列表、工作台、弹框／抽屉内 Element 表格及 `density-table` 共用 |
+| 描述表标签底色 | 浅灰，参考 #f8fafc / #f9fafb，不跟随表格表头变蓝 |
 | 边框 | 现有 `--cc-border`；表格参考 #e5e7eb |
 | 悬停、斑马纹 | 轻量区分，参考 #f3f7fb / #fcfcfd |
 
-颜色优先复用当前 `--cc-*` 与 Element Plus 语义变量。金额和测量数字可使用等宽数字排版，只有总计或关键结论适度加粗，不将每个值都加粗。
+表头颜色由 `foundation.css` 的 `--cc-list-table-header-bg` 与 `--cc-list-table-header-text` 唯一维护。颜色优先复用当前 `--cc-*` 与 Element Plus 语义变量。金额和测量数字可使用等宽数字排版，只有总计或关键结论适度加粗，不将每个值都加粗。
+
+## 提示文字与加载布局
+
+2026-10-21 用户确认：Admin 页面默认不额外添加提示小字、装饰性副标题、功能介绍或独立说明行；用户明确要求展示的业务信息按实际用途保留。
+
+- 常规加载、刷新、查询及页签切换不新增“页签数量加载中…”“数据加载中…”等独立文字行，不为每个局部请求补充提示小字。
+- 加载反馈复用原位置、固定尺寸的加载图标、按钮 loading、区域遮罩或与内容等尺寸的骨架；加载前、加载中、完成后保持页签、工具栏、筛选区和表格的布局稳定，不因临时提示插入或移除而推挤内容、改变区块高度或造成页面跳动。不为被禁止的提示行额外预留空白。
+- “覆盖加载状态”“保留状态反馈”不等于新增可见说明行。保留 `aria-busy` 等可访问语义；必要的读屏播报不得占用可见布局。
+- 接口失败与重试、表单校验、权限限制、过期或异常状态、实际操作阻断和危险后果继续清楚反馈，在对应位置集中表达，避免重复；不得以精简小字为由隐藏影响用户判断或操作的信息。
+
+- **详细口径按需展开。** 计算公式、统计口径、图例、来源解释和操作说明放入已有说明入口或 `InlineHelp`／tooltip，支持键盘聚焦；不为每张卡增加介绍段、装饰性副标题或长解释。确需影响判断的周期、单位和版本保留最短必要表达。
+- **同一事实只讲一次。** 多张卡共用的统计周期、完整性或来源在分区层级统一表达；卡片仅显示自身特有状态。主状态、进度环、数量卡与阶段节点不重复整段等待原因。
+- **异常优先合并到一个清晰入口。** 同一异常影响多块内容时，在相关区域保留一条简短状态与查看详情／重试入口；不要在每张卡和图表下重复警告。独立异常仍在对应位置明确呈现，不能合并后丢失作用范围。
+- **关键异常与阻断常驻。** 当前失败、未知、陈旧、权限不足、操作阻断及危险后果必须能直接识别；细节可以展开，关键状态不能只藏进 tooltip。正常完整状态不需要逐卡反复宣告。
+- **事实与视觉分开。** `0` 表示已知零值，`—` 或“待确认”表示未知；历史结果和陈旧快照要有简短标识。精简文案不得把未知显示为零、把暂停显示为完成，也不得隐藏真实风险。
+
+库存分析样板按这套规则收敛：快照解释、“本仓概览／截至日期／采集时间”整行及图表范围说明移入已有说明入口；正常指标卡只保留名称、数值和单位，删除重复的“已确认”。真实未知、陈旧和异常继续显示简短提示。删除独占一行的“展开图表”，将图表操作并入顶部简短入口。完整数值来源、采集时点和估算细节可在说明或 tooltip 中查看；估算值必须能辨认其估算属性，不得因精简文案冒充实测值。
+
 
 ## 各类页面规则
 
 ### 列表
 
-- 继续使用 `ListPageLayout + QueryToolbar + DataTable`。查询、批量操作、表格、分页构成连续工作区，不重复放置正文大标题或统计卡片。
+- 使用 `ListPageLayout + QueryToolbar + DataTable`，搜索／筛选区与下方表格分成独立区块，搜索区圆角统一 5px。`foundation.css` 的 `--cc-list-query-radius` 与 `--cc-list-query-gap` 维护尺寸；DataTable 筛选容器提供边框、底色及下方 16px 间距，内部 QueryToolbar 不重复套卡片。独立 QueryToolbar 使用相同圆角及列表已有区块间距。
-- “操作”列始终第一列，需要固定时固定在左侧。最多三个高频操作直接显示，更多操作使用已有菜单约定；保留页面已确认的直接操作数量。国内仓全部 7 个菜单及客户管理的行内业务操作采用下述纯文字描边按钮。危险动作保留明确文字与确认。
+- 同级状态／分类页签与顶部业务按钮共用工具栏：页签放 `toolbar-start`，操作放 `toolbar-actions`／`toolbar-end`，查询放 `filters`；蓝白页签加 `workbench-list-tabs`。不叠加重复路由标题、页签行、按钮行；保留真实业务子分区、统计数量、失败重试与当前范围。
-- 列宽按实际编号、状态和按钮数量决定；不能把样板的 260px 操作列套给所有列表。核对最多按钮、加载中和权限变化后的布局。
+- “操作”列在第一列，需要固定时固定在左侧。默认最多三个高频操作直接显示，其余用更多菜单；保留已确认的直接操作数量、权限和危险确认。更多入口为 `…`（`MoreHorizontal`），保留业务对象相关的可访问名称与悬停提示，菜单项纯文字。
-- 数值列右对齐，单位优先放表头；编号按业务需要设置宽度。保留横向滚动、列偏好、分页和已有行内编辑能力。
+- 已接入标准列表的行操作采用纯文字：无描边、填充或装饰图标，400 字重，普通操作蓝色、危险操作红色、禁用灰色、悬停无下划线。`RowActions` 用 `text-actions`；手写按钮组用 `row-actions density-actions admin-text-actions`，危险语义通过 `data-tone="danger"` 或 `type="danger"` 显式指定。统一外观由 `adminTextActions.css` 维护，不再沿用早期国内仓描边行按钮。顶部、查询及弹框提交按钮按各自用途保留，不机械套用行操作外观；尚未接入的消费者在本轮明确范围内再调整。
+- 状态列前置：有主要业务编号时紧跟编号，没有编号时紧跟主要名称；多个当前状态集中排列，操作列仍在第一列。DataTable 的状态列通过 `afterColumn` 显式指定跟随的列键，恢复已保存的列序时仍遵守该位置，状态列不独立拖动；其他列的个人顺序、列宽和显隐继续保留。历史记录中的原状态、新状态及状态变化保留事件阅读顺序。
+- 列宽按实际编号、状态和按钮数量决定，核对长编号、最多按钮、加载与权限变化；不把样板操作列宽套给所有列表。数值列右对齐，单位优先放表头；保留横向滚动、列偏好、分页和行内编辑。
+- 标准 DataTable 沿用默认灰白斑马纹，不由页面显式关闭；行底色复用 `--admin-row-stripe`，悬停行、当前行及悬停单元格由 Element 状态样式处理，父表底色不穿透子表。
+- 表格与分页交界只画一条底线：Element Plus 的 `el-table__inner-wrapper::before` 保留，紧邻该表格的 DataTable 分页不再叠加上边框；自定义结果区域仍保留原分页分隔线。不全局隐藏表格底线，避免空表和无分页表格缺边。
+- `appearance="integrated"` 保留原组件组合能力，不再表示搜索与表格必须相连。样式维护在 DataTable 和公共 CSS，不为接入样式切换业务模式。
+- 详情内的充值申请、账户流水等连续表格同样使用 `workbench-table is-page-surface` 去掉 DataTable 外壳的重复边框、圆角和阴影，保留表格本体边线、横向滚动和分页。筛选放在 DataTable 的 `filters` 插槽时，接入 `appearance="integrated"`，由筛选容器独占边框与底色；内部 QueryToolbar 不再绘制第二层边框或阴影。优先复用这些公共入口，不在页面追加隐藏边框的覆盖规则。
 
-#### 国内仓行内按钮（以订单列表样板统一）
+#### 公共列表能力
 
-依据用户提供的白底描边按钮参考图，订单列表行内操作采用纯文字、白底、1px 细边框，无阴影，圆角 6px；保持 28px 高、13px 字号、600 字重、左右内边距 10px、按钮间距 6px。该按钮圆角为明确例外，普通内容容器仍为 0–4px。
+Admin 仍使用 Element Plus。普通 `el-select` 由构建组件解析器统一接入 `src/shared/components/AdminSelect.ts`，仅将 `filterable` 默认值设为 `true`，使用 Element Plus 原有渲染、插槽、事件和公开方法；列表、表单、弹框及分页选择框均可输入关键词筛选当前选项。已有 `remote-method`、`filter-method`、多选、禁用和清空行为保持原有配置；搜索不改变候选业务范围，也不会自动新增远程接口调用。虚拟托盘选择框 `el-select-v2` 已显式启用远程搜索。
 
-- 默认行内操作（详情、编辑、备注、更多）：蓝色文字 `#1777ff` 与浅灰边框，由 `--admin-action-neutral` 统一维护。
+推广时列设置显式使用 `column-settings-mode="show"`。已有 `preference-key` 保持，新接入的退货库存、流水和箱号各使用独立偏好键。存在非阻断警告时使用 `notices` 插槽，列表失败时通过 `results-visible` 隐藏结果和分页，标题、查询与重试保持可用；`before-results` 保留原统计与汇总。特殊工作台可使用 `results` 插槽承载原内容和自身分页，公共表格不重置它的页码与每页数量。
-- 审核“通过”：橙色文字与浅橙边框，保留原确认流程。
-- 测量：紫色文字与浅紫边框。
-- 悬停使用对应浅色底，键盘焦点保持可见；禁用、处理中状态保留。更多入口统一为 `…`（Lucide `MoreHorizontal`），保留包含业务对象的“更多操作”悬停提示和可访问名称；下拉项纯文字。
 
-该规则覆盖订单列表、订单测量、测量数据审核、预装清单、库位管理、托盘管理、整柜业务以及其详情中的行内操作。查看/编辑/备注为默认蓝色 `#1777ff`，测量为紫色，审核为橙色，启用为绿色，停用/删除为红色。预装共用组件只在 `preload` 模式接入，已确认装柜清单模式保持原规则。顶部查询/新增/批量操作和弹框提交仍使用 32px 主次按钮，不机械改成行内按钮，也不增加样板中不存在的业务操作。
+列宽保存为公共 DataTable 能力，与已有列设置一同启用（提供 `preference-key` 且列设置可用），不依赖试点样式。拖动表头边界松开时，将宽度按稳定列键写入同一份本地偏好；重排、隐藏再显示不会丢失，刷新/重新进入时恢复。账号与表格分别隔离，仅保存到当前浏览器，不跨设备同步。“恢复默认”同时重置列顺序、显隐和宽度，重新采用页面声明的 width/minWidth。未启用列设置的表格不写入列宽偏好。
 
 #### 客户管理按钮与详情
 
 - 客户列表、海外仓阶梯费用及关联详情、编辑、审核、预览的业务操作按钮采用纯文字；查询、重置、复制也去掉装饰图标。分页箭头、列设置、筛选布局、关闭与全屏等独立图标控件保留，处理中旋转图标保留。
-- 客户列表行内按钮沿用 28px 白底描边、6px 圆角、6px 间距：详情/编辑/更多为默认蓝色 `#1777ff`，审核为橙色，重置密码为紫色，跳转登录为蓝色，启用为绿色，停用/删除为红色。更多入口与订单列表统一显示 `…`，不显示“更多”文字；悬停提示及可访问名称保留，菜单项纯文字，保留原权限与操作分配。
+- 客户列表行操作采用上文统一纯文字规则；保留原权限、操作分配、更多入口和危险确认。
-- 海外仓阶梯费用列表按原档位顺序显示“天数：单价”，在费用单元格中连续排列、整组自然换行；不制作每档独立白块，不强制左右两列，不隐藏后续档位。币种只在独立列展示，计费单位保留在表头；零单价照常显示 `0`，没有档位显示“—”。编辑按钮沿用默认蓝色 `#1777ff` 文字、白底描边。
+- 海外仓阶梯费用列表按原档位顺序显示“天数：单价”，在费用单元格中连续排列、整组自然换行；不制作每档独立白块，不强制左右两列，不隐藏后续档位。币种只在独立列展示，计费单位保留在表头；零单价照常显示 `0`，没有档位显示“—”。列表编辑按钮沿用统一纯文字行操作。
 - 阶梯费用编辑弹框中的“新增阶梯”为蓝字浅蓝边、“删除”为红字浅红边，均使用 28px 高、6px 圆角的白底纯文字按钮；客户详情的海外仓费用编辑同步执行。底部保存/取消沿用 32px 主次按钮。按钮规则同时覆盖页面与 Teleport 弹框，并显式设置普通、悬停、焦点及禁用状态，避免默认主题色覆盖。
 - 客户详情保留彩色页签；企业信息用连续四组键值表，联系与合作信息保留三组键值表，长地址整行。资质文件采用连续行，企业成员使用表格。
 - 客户新增/编辑保留 1120px 三列表单，入驻审核保留 1040px，箱规规则编辑保留 1200px，海外仓阶梯编辑保留 1120px。宽度属于当前内容的适配值，不推广为全局默认。
@@ -94,17 +115,19 @@
 - 第一行集中放返回、业务编号、核心状态及主要操作。下一行用可换行摘要展示关键上下文，不使用大数字概览卡。
 - 返回使用 `density-back` 轻量导航，与业务编号和状态排在同一行，保留箭头、文字、键盘焦点及原返回目标。该行并入连续白底详情区域，不为返回单独增加卡片或空白行；整柜库存的标题行与基本信息共用一个信息区。
 - 页签紧接摘要。页签已表达的标题不再在正文重复占用一大行；数量、更新时间与相关操作可放紧凑工具栏。
-- 短字段通常每行四组，长内容跨两组或整行。描述表标签浅灰、数值白底，边线连续；标签宽度以 112px 为样板参考，按字段实际长度调整。
+- 短字段通常每行 4–6 组，按内容和业务分组调整，长内容跨列或整行。描述表标签浅灰、数值白底，边线连续；标签宽度以 112px 为样板参考，按字段实际长度调整。
 - 保留字段顺序和业务分组，不使用会改变阅读顺序的自动密集填空布局。
 - 同一个订单或实体内部的内容连续分区，不再层层套卡片。
 
 ### 费用、汇总与测量
 
 - 汇总使用单行摘要或紧凑描述表。自动费用与其他费用保持各自业务口径，金额、单价、计费量、附加费和版本完整展示。
+- 客户资金账户详情采用已确认的六项紧凑金额卡片，复用公共 `workbench-metric is-compact` 外观；保留授信有效期、到期和负余额状态。导出流水与充值、扣款、授信操作集中在详情页头，流水区不再单独设置导出工具栏。结算单应收／应付详情同样使用三项紧凑金额卡片展示应收／应付、已收／已付、未结余额，到期日保留在基本信息中。以上为已确认的详情页例外，不推广到其他详情。
 - 保留公式、计费依据和价格来源入口，不能为了减少行数合并不同口径的金额或重量。
 - 测量各来源保留独立分组；展开时在表尾显示合计，折叠时在标题显示摘要，同一口径不在上下重复占位。
+- 测量作业弹框采用用户确认的分区配色：申报与实测对比白色（`#fff`）、客户申报明细浅蓝（`#f7f9ff`）、平台实测箱规白色（`#fff`），保留细边框和 8px 圆角，不使用左侧强调色条，作为连续白底规则的局部例外。区块不得使用负外边距伸出正文；左右内边距由 `measurementDensity.css` 统一维护，通用密度规则不得将其清零。保持 1560px、92vh 居中作业弹框及原有业务分组，各区按当前确认配色呈现，不恢复已移除的绿色背景。 三个分区同级排列，客户申报不得嵌套在实测大框内。箱数、毛重、体积集中在“指标／客户申报／平台实测／差异（实测 − 申报）”表中，不在下方重复总数；未采集显示“未测量／待测量”，申报缺失显示“—”，相等显示“一致”。净重、材积重单独显示平台事实，不与申报毛重混比。 客户申报区保持只读；实际品名和预计托数放在“平台实测箱规”区，沿用原保存与权限规则。未采集时只保留主状态，有箱规和来源后显示采集来源；平台补充数据的口径说明通过提示展示。提交按钮旁显示当前订单状态、缺少测量或称重等实际阻断原因。 桌面布局中，对比区标题与客户、渠道、状态同排；申报区标题与原单据号码同排，标签和值横向排列；实测箱规标题、实际品名、预计托数及录入操作共享一行。长内容自然换行，不截断编号或缩小字号。提交阻断原因集中在固定底栏，正文不重复显示同一提示，业务状态、偏差和冲突提醒保留。
 - 同一计算策略只保留一个明确操作入口，保存中、无权限、冻结与失败信息照常显示。
-- 称重图片可用缩略图加紧凑事实行；保留查看原图、托盘/库位信息和人工修正入口。可视化、图纸、标签预览、库位示意等按业务用途保留合适尺寸。
+- 测量称重图片可用缩略图加紧凑事实行；审核称重图片使用表格承载，保留查看原图、托盘/库位信息和人工修正入口。可视化、图纸、标签预览、库位示意等按业务用途保留合适尺寸。
 
 ### 历史、备注与空态
 
@@ -114,12 +137,93 @@
 
 ### 弹框与表单
 
-- 保留各操作已确认的独立页面、居中弹框或抽屉承载方式。审核确认不自动变为完整详情；简单备注不套用大型作业弹框。
+本节是 **Admin 弹窗基础规范** 的唯一维护入口。通用统一范围限于白底框架、基础字号与控件、标题与操作区的可用性、间距和滚动边界；不统一业务正文结构、分区数量、字段排列、固定尺寸或装饰底色。普通表单与复杂作业弹框默认白底，按各自业务组织内容。测量样板的分区配色仅适用于已明确确认的具体窗口，不自动推广到其他新增、编辑、审核、上传、预览或确认弹窗。
-- 标题和底部操作保持可见，长内容只滚动正文。优先使用 `AppDialog` 的原生标题栏和已有全屏能力。
+
-- 宽度按内容选择：简单确认/备注参考 560–600px，普通双列表单参考 680–920px，批量预览参考 1100px；订单测量作业样板为 1560px、92vh。以上是类型参考，不是所有弹框的统一固定尺寸。
+参考图：[测量弹窗原始截图](界面参考/Admin弹窗样板-测量.png)（原附件 `codex-clipboard-3eeb665f-6eee-437e-886b-75d3cc0dc78e.png`）。仅参考基础框架及该测量场景，不据此复制其他窗口的配色、分区、表格结构或尺寸；验收仍为 1920×1080、浏览器 100%，不按图片像素反推控件尺寸。
-- 普通弹框参考上边距 6vh、最大高度 88vh；大型测量作业参考上边距 4vh、最大高度 92vh。全屏时使用组件的完整视口规则。
+
-- 表单控件、单位、必填标识、校验错误和原因说明完整保留。长表单按业务分组排两至四列，文本域按需跨列。
+![Admin 弹窗样板：测量作业](界面参考/Admin弹窗样板-测量.png)
-- 审核确认清楚展示业务对象；批量审核保留逐票预览、选中数量和不可操作原因。保留处理中锁定、关闭未保存确认与失败上下文。
+
+#### 外框、标题与滚动
+
+- 使用白色外框、细边线和紧凑标题栏；标题为“操作名称 · 业务编号”，没有业务编号时仅显示操作名称，缺失值不以数据库 ID 补位。复用现有标题字号、字重和分隔线。
+- 标题栏与底部操作区固定可见，长内容只滚动正文；同一内容区保持一个主要纵向滚动容器。明细表保留业务所需的横向滚动。
+- 优先使用 `AppDialog` 的原生标题栏和已有全屏能力；关闭、全屏/退出全屏位于右上角，保留可访问名称。大型表格和作业弹窗按需启用全屏，小型确认弹窗无需强行加入全屏。
+- 普通弹窗按内容自然增高，上边距参考 6vh、最大高度 88vh；测量等大型作业弹窗按已确认作业高度使用上边距 4vh、最大高度 92vh。全屏采用组件的完整视口规则。小表单不设置无业务依据的固定大高度或大块空白。
+- 各操作已确认的独立页面、居中弹框或抽屉承载方式继续保留。此次统一弹窗外观不改变正式详情路由，也不将抽屉自动改成弹框。
+
+#### 按内容选择尺寸
+
+| 用途 | 桌面宽度参考 | 内容排列 |
+|---|---|---|
+| 简单确认、备注、原因填写 | 560–600px | 紧凑单列，按内容增高 |
+| 普通新增、编辑 | 680–920px | 通常双列；长地址、备注、附件跨列 |
+| 多字段表单、资料审核 | 1040–1200px | 短字段通常三列，按业务分组，长内容整行 |
+| 批量预览、对照与选择 | 约 1100px，随实际列宽调整 | 表格为主，保留数量、逐条明细和不可操作原因 |
+| 测量等大型作业 | 样板 1560px、92vh | 业务分区、作业表格和固定操作底栏 |
+
+以上只用于没有已确认尺寸的新窗口，不作为重排现有弹框的模板，也不覆盖已有逐操作确认的业务尺寸，例如客户重置密码 520px、客户新增/编辑 1120px。复杂工作台按真实信息量保留宽高、分栏与独立工作区；宽度受视口边距约束，不靠缩小字号、隐藏字段或截断关键编号容纳内容。
+
+#### 正文分区、配色与密度
+
+- 默认使用白底，通过原有业务标题、间距与必要分隔线组织内容；不得因存在录入、只读、汇总或多分区就套黄、蓝、绿背景，也不为套样板新增标题、卡片或分区。
+- 保留已有表单、左右分栏、主从表、步骤、树表、筛选候选、图文对照及预览区域。字段多或交互复杂不构成改成连续信息表、三列表单或同级彩色区块的理由；确有布局问题时先记录具体问题，再单独调整该窗口。
+- 只读值清楚展示，可编辑控件保留可辨识的边框、焦点、标签和校验；不为了连续表外观隐藏输入特征。仅在该窗口的信息关系适合且逐项确认后使用连续编辑表，不把只读与录入强制合并、不机械横排或并入汇总末行。
+- 下表只记录测量作业的已确认配色例外，不是按信息用途自动映射颜色的通用规则。其他具体窗口需要彩色分区时，在本窗口核对记录中说明业务用途与确认依据；旧批次记录中的“黄色录入区”不等于本轮已确认保留。
+
+| 适用窗口 | 已确认分区 | 浅底色 |
+|---|---|---|
+| 测量作业主弹框 | 申报与实测对比 | `#fff`（白底、普通细边框） |
+| 测量作业主弹框 | 客户申报明细 | `#f7f9ff` |
+| 测量作业主弹框 | 平台实测箱规 | `#fff`（白底、普通细边框） |
+| 测量作业主弹框 | 测量偏差提示 | `#fff`（保留红色警示文字与图标） |
+
+- 表格单元格以白底为主，表头采用“尺寸与颜色”的统一浅蓝底、深蓝文字；普通字号、控件高度、行高、间距沿用公共令牌。单位、必填标识、校验错误、表单标签及原因说明完整保留。
+- 汇总尽量只出现一次；表格已完整表达的字段不再另做统计卡片。错误、警告、成功及禁用状态继续使用现有语义，彩色分区不掩盖真实风险。
+
+#### 输入框与字段
+
+2026-10-22 用户确认以客户新增／编辑弹框的输入控件外观作为后续同类表单的参考；只统一控件外观与可用性，不据此复制客户的三列布局、表格结构或弹框尺寸。
+
+- 文本、数字、日期、下拉选择及多行文本使用白底、可辨识的浅灰边框和 8px 圆角（`--cc-radius-lg`）；悬停边框加深、聚焦使用蓝色边框。普通单行控件沿用通常 32px 的公共高度，多行文本保留业务需要的行数。不能通过透明边框把可编辑内容显示成普通文字。
+- 普通文本与表单数字左对齐，包括注册资本、账期等；数字增减按钮与单位、币种保留原功能。此条不改变只读数据表的金额、数量列对齐方式。
+- 横向排列的表单标签与控件垂直居中，由 `adminDensity.css` 统一处理；顶部标签保持原有上下排列。普通短字段标签优先单行，较长标签按实际文字单独加宽，不缩小字号或截断标签；长地址、备注等保留已确认跨列方式。
+- 占位文字简短，避免长说明被输入框截断，例如客户昵称使用“选填，默认自动生成”。标签始终保留，不能仅靠占位文字说明字段含义；详细规则确有必要时放入已有说明入口。
+- 只读值直接展示，与可输入控件明确区分；禁用、权限不足、校验错误、处理中和实际操作阻断保留原反馈。精简文案不改变字段可编辑资格、保存及审核流程。
+- 分区标题、已有帮助入口与该分区状态标签优先同一行，例如“企业认证资料”与“启用”；不为简短状态单独占一行。内容过长时自然换行，不强行裁切。
+- 字段旁及底部不重复铺设保存／审核流程介绍、只读规则等常驻小字，按[提示文字与加载布局](#提示文字与加载布局)处理；实际风险、错误和阻断原因仍须清楚反馈。
+- 实现复用 Element Plus 控件。连续编辑表内的表单通过 `density-form--outlined` 接入 [adminDensity.css](../apps/admin-web/src/styles/adminDensity.css) 的白底与中性边框规则；客户参考实现为 [CustomersView.vue](../apps/admin-web/src/modules/customers/pages/CustomersView.vue) 与 [customerDensity.css](../apps/admin-web/src/modules/customers/customerDensity.css)，后者当前限定客户编辑框的圆角和数字对齐。后续在明确修改范围内接入，通用外观维护在公共入口，不逐页复制颜色与控件规则，也不自动批量改造其他弹框。
+
+#### 底部操作与交互
+
+- 底部以细分隔线与正文区分，右侧排列原有取消、保存、提交等操作；一个阶段突出一个主操作，其他操作保持次级样式。按钮职责、顺序和保存触发方式按当前业务确认保留，不新增原本没有的“暂存”或“保存并提交”。
+- 自定义底栏可显式使用`density-actions density-actions--footer`，由公共样式维护右对齐、换行和按钮间距，不在业务页复制底栏通用布局。
+- 左侧可显示当前状态、选中数量或实际提交阻断原因，同一阻断说明集中显示；只读、预览和小型确认弹窗按其实际动作提供关闭/取消/确认。
+- 审核、确认清楚展示业务对象；批量操作保留逐票预览、选中数量和不可操作原因。加载中、无数据、接口失败、无权限、禁用与处理中均应有明确反馈。
+- 保留提交锁定、原有遮罩/Esc/关闭规则、未保存保护及失败上下文；全屏切换、关闭和重开不丢失应保留的输入，不允许重复提交。关闭、全屏等功能图标保留，不为统一风格给标题、字段或按钮添加装饰 Emoji。
+
+#### 作用域与嵌套
+
+新增、编辑先参考公共 `AppDialog`／`AppDrawer`，表单字段排列仍参考本业务已确认的样板。客户新增／编辑使用三列短字段，地址、备注和长内容跨列；小型确认框保留原宽度。智能装柜等工作台保留原有宽版和 92vh 高度，不把所有浮层压成同一尺寸。
+
+- 标题、正文和页脚样式只匹配当前浮层的直接子节点；业务页的 `:deep` 规则也必须限定自身，不能通过任意后代选择器影响子弹框。
+- 不假设 `AppDialog` 默认一定挂到 body。嵌在另一个弹框、工具栏或有裁切的容器中的独立浮层，应明确设置 `append-to-body`，并把主题类放到实际浮层根。核对关闭、重开、全屏和取消仅影响对应窗口。
+- 标题与底部操作不随长正文滚走，正文使用单一纵向滚动区；真实宽表可在自己的区域横向滚动。不要通过整框 `overflow: hidden`、固定短高度或隐藏按钮解决溢出。
+- 底部多按钮可换行且保持间距；已有复合底栏（统计、分页、提交等）保留自身布局，不强制改成一排普通按钮。工具栏的紧凑按钮尺寸不得传入浮层。
+- 工具栏只控制自身操作按钮及已核实的包装层，遇到浮层、弹出菜单或内嵌 DataTable 就结束作用范围；保留按钮组与下拉按钮，不能为隔离而使已有操作失去样式。
+- 长校验错误应占据正常布局空间，不能遮住下一行；长文件名允许换行，文件选择、上传和删除按钮保持可用宽度。必填标识、字段标签、错误和提交反馈不为清爽而删除。
+
+#### 公共维护与分模块落地
+
+- 框架能力维护在 `AppDialog.vue`，基础尺寸、字号和间距维护在 `adminDensityTokens.css`，通用外观维护在 `adminDensity.css`。模块保留业务结构及已确认尺寸；不得通过修改公共默认值，批量去色、重排或重置所有弹框。
+- `density-dialog-section` 及其 `data-tone="summary/source/work"` 是既有彩色分区实现能力，不是所有弹框的必选结构；仅在明确确认保留的场景使用。分区标题类为 `density-dialog-section__title`，容器类为 `density-dialog-sections`，存在公共类不构成采用理由。普通弹窗通过 `admin-density-dialog` 接入基础外观；抽屉按实际查看／编辑用途保留 `admin-density-drawer--detail`／`admin-density-drawer--editor` 等边界，不因此改成连续编辑表或复制测量分区。共用 `--admin-dialog-*` 令牌只统一基础能力。
+- 确有必要且已确认的弹窗说明使用 `density-dialog-note`，由公共样式维护外观；是否展示遵循“提示文字与加载布局”，不因存在说明类就新增小字。
+- JSON及原文快照显式使用 `density-code-block`，由公共样式维护代码字号、底色和边框；长内容完整换行，沿用外框正文滚动，不另设固定高度、内容截断或纵向滚动。快照属于诊断证据，不据此将数据库ID展示为业务编号。
+- 连续信息表需要单元格编辑时，在 `density-table` 上显式添加 `density-table--editable`；数值与单位使用 `density-table-editor` 横排。输入的普通边框融入表格，保留悬停、键盘焦点及禁用反馈；页面只配置标签列宽和字段排列，不复制输入框外观。
+- 小表单继续使用 `density-form`；末项已有明确紧凑尾距约定时显式添加 `density-form--flush-end`，不改变其他表单末项为校验错误保留的空间。
+- Teleport 弹框自身显式使用 `admin-density-dialog`，原有 `ElMessageBox` 使用 `admin-density-confirm`；原生 `el-dialog` 的外观按同一规范接入，是否收敛到 `AppDialog` 按实际能力和消费者核对，避免一次替换全部弹窗。抽屉继续使用既有 `admin-density-drawer` 边界。
+- 已改造弹框按原固定编号清单逐项复核，方法见 [前端验收规则](Admin-Client前端原型还原验收规则.md#执行与验收)。每项先核对改造记录、当前实现及实际截图，再决定保留或局部修正；一个样板通过不授权批量推广其业务布局和配色。共享弹框记录全部直接调用方，已有代码检查与历史截图不能替代本次视觉确认。
+- 后续每个大模块按同一流程开展，进度和截图结论写入对应模块核对记录；本规范只维护稳定规则。页面字段、状态、权限、接口、计算口径、校验和提交逻辑继续按当前业务契约执行。
+- 代码检查与人工视觉结论分别报告，逐项核对普通/全屏/关闭重开、长内容、空态、错误和权限状态；缺少截图时标记“待人工截图确认”。按模块汇总发布范围，部署继续沿用对应环境授权规则。
 
 ## 彩色图标
 
@@ -140,50 +244,149 @@
 
 彩色图标用于详情页签。国内仓 7 个菜单的行内按钮与客户管理业务操作使用纯文字；返回箭头、顶部与弹框的既有功能图标可保留。不要给操作按钮、表头或字段添加 Emoji。
 
-## 国内仓推广清单与顺序
-
-此表是实施入口，不是完成状态。每个入口必须继续沿实际组件引用盘点可达弹框与详情，不把父页面验收等同于所有子界面通过。
-
-| 顺序 | 菜单 | 主入口（相对 apps/admin-web/src） | 本组应覆盖 |
-|---|---|---|---|
-| 样板 | 订单列表 | `modules/unified-orders/pages/UnifiedOrdersView.vue` | 列表、详情全部页签、测量、单票/批量审核及实际可达弹框 |
-| 1 | 订单测量 | `modules/inbounds/pages/InboundMeasurementsView.vue` | 列表、测量作业、称重图片与相关编辑/预览 |
-| 1 | 测量数据审核 | `modules/inbounds/pages/MeasurementReviewsView.vue` | 列表、审核工作区、明细、确认及当前实际存在的修正操作 |
-| 2 | 预装清单 | `modules/loading-lists/pages/PreloadPlansView.vue`、`PreloadPlanDetailView.vue` | 列表、详情各页签、相关确认及打印/预览容器 |
-| 3 | 库位管理 | `modules/warehouse-resources/locations/pages/LocationsView.vue` | 列表、详情、新增/编辑及实际存在的批量操作 |
-| 3 | 托盘管理 | `modules/warehouse-resources/pallets/pages/PalletsView.vue` | 列表、详情、新增/编辑及实际存在的关联操作 |
-| 3 | 整柜业务 | `modules/domestic-containers/pages/DomesticContainersView.vue`、`DomesticContainerInventoryDetailView.vue` | 入库/出库/库存工作区、库存详情与实际可达弹框 |
-
-每组先统一列表，再处理详情与弹框；同一业务工作区一起交付人工查看。未注册、已重定向或只存在于历史原型的页面不能只凭文件存在就恢复或加入本轮。
-
 ## 实现与验收
 
-1. 改造前读取最近指引，沿菜单、路由、组件与事件定位实际页面；填写逐操作矩阵。原型已有承载方式不因密度统一而替换，明确的样式改造可在已授权范围内推进。
+逐操作矩阵、人工截图与自动检查的证据要求统一见 [前端验收规则](Admin-Client前端原型还原验收规则.md)。本规范不记录通过状态；缺少截图保留“待人工截图确认”。实现前核对实际路由与直接消费者，保持字段、单位、排序、权限、提交及错误处理，测试不能锁定已废弃外观或删掉业务断言。
-2. 多个真实消费者使用同类密度时，将稳定尺寸与布局能力收敛到本应用的样式变量或现有共享组件的可选能力。先明确接入范围，不让全局默认变化影响尚未改造的菜单。
-3. `adminDensityTokens.css` 定义默认值，`adminDensity.css` 承载通用组件规则；`orderDensity.css`、`measurementDensity.css`、`customerDensity.css` 只保留各自业务布局与引用公共变量的局部规则。按钮外观不得在模块中另写一套。跨菜单共用组件（如模拟柜创建、托盘码打印）通过可选 `dense` 参数接入；未传参数的调用保持原布局。
-4. 弹框经 Teleport 后必须仍能获得对应样式。检查普通、全屏、关闭、重开以及多个入口使用同一组件时的表现；避免无边界的全局 `.el-dialog`、`.el-table` 或 `!important` 覆盖。
-5. 每页检查长编号、长地址、多条数据、空态、失败态、无权限、禁用态及处理中状态；所有字段、单位、排序、权限与操作资格应保留。测试不得继续锁定已废弃的卡片结构，也不能删除业务断言以换取通过。
-6. 按 Admin 指引运行直接影响测试、类型检查、全量测试与构建；公共组件检查实际消费者。视觉默认由用户在指定视口操作并截图，缺少证据标记“待人工截图确认”；用户明确要求 AI 界面验收时，按本轮授权操作并记录实际证据，不将代码测试当作视觉通过。
-7. 每组交付说明修改页面、公共影响、检查结果、剩余视觉差异。任何尺寸或布局例外记录在逐页矩阵中，避免把一次性例外写成新的全局默认。
 
-逐页核对记录模板：
+## 蓝白主题与图表
 
-| 页面/路由 | 操作及承载方式 | 原型或确认依据 | 采用规则/业务例外 | 检查与截图结论 |
+### 视觉基线与维护入口
-|---|---|---|---|---|
-| 填写具体页面 | 分别填写详情、编辑、审核、预览等 | 原型 ID、代码入口或用户确认 | 列表/描述表/日志/作业弹框等 | 代码检查结果；待人工截图确认或实际结论 |
 
-规范只记录稳定规则和入口。各组进度、临时问题与验收结果写入对应核对记录，不写入 `AGENTS.md`。
+| 维护内容 | 唯一实现入口 |
+|---|---|
+| DOM 配色、字号、间距、圆角、阴影与辅助色 | [`adminWorkbenchTokens.css`](../apps/admin-web/src/styles/adminWorkbenchTokens.css) |
+| 标题、指标卡、列表外壳、页签、阶段、图表空态与弹窗外观 | [`adminWorkbench.css`](../apps/admin-web/src/styles/adminWorkbench.css) |
+| Canvas 图表字体、颜色、坐标网格与提示框主题 | [`adminWorkbenchChartTheme.ts`](../apps/admin-web/src/styles/adminWorkbenchChartTheme.ts) |
+| 显式接入范围、变量归属、公共类与浮层作用域合同 | [`adminWorkbench.test.ts`](../apps/admin-web/src/styles/adminWorkbench.test.ts) |
+| 原有表格、控件和弹窗密度 | [`adminDensityTokens.css`](../apps/admin-web/src/styles/adminDensityTokens.css)、[`adminDensity.css`](../apps/admin-web/src/styles/adminDensity.css) |
+| 弹框与抽屉的标题、正文滚动和底部操作 | [`AppDialog.vue`](../apps/admin-web/src/shared/components/AppDialog.vue)、[`AppDrawer.vue`](../apps/admin-web/src/shared/components/AppDrawer.vue)；真实 Element 挂载回归见 [`AppDialog.layout.test.ts`](../apps/admin-web/src/shared/components/AppDialog.layout.test.ts) |
 
-## 国内仓、客户管理的样式维护边界
+下列取值只用于显式 `admin-workbench` 主题内的对应元素；业务表格、控件与表单继续沿用上文密度值。代码以对应令牌为准，修改数值只改唯一实现入口并同步本表，不在页面重新声明默认值。
 
-本节适用于已接入的两个菜单及其实际子组件，不改变其他菜单默认样式。此次收敛以保留业务字段、权限、计算与承载方式为前提。
+| 项目 | 样板基线 |
+|---|---|
+| 主操作与链接 | `--workbench-primary`，`#3784FA`；悬停、按下与禁用使用配套令牌 |
+| 重点数字 | `--workbench-number`，`#1890FF` |
+| 正文与辅助文字 | `--workbench-text`，`#1F2937`；`--workbench-muted`，`#64748B` |
+| 表面与边框 | 白色主体，浅灰蓝辅助区；`--workbench-border`，`#E5EAF2` |
+| 卡片与图标底座 | 卡片圆角 16px、图标底座圆角 12px，低强度阴影；使用公共令牌 |
+| 普通指标卡高度 | `--workbench-metric-min-height: 186px`；长内容可自然撑高，紧凑指标不继承此最小高度 |
+| 空间 | 外壳内容区上／左右 12px、底部 16px；工作台根内边距 `--workbench-page-padding: 12px`；区块间距仍为 24px，普通卡片内边距 20px、紧凑卡片内边距 14px、同级网格间距 18px |
+| 主列表顶部 | 工具栏最小高度 48px、上下内边距 6px；筛选区上下 8px；两区左右统一 12px，普通按钮与筛选控件 32px；内容多时自然换行，不截断或固定总高度 |
+| 主列表底部分页 | 最小高度 48px（border-box）、上下内边距 6px、左右 12px，与筛选区对齐；保留 32px 翻页按钮和长统计换行，不沿用集成列表旧的 64px 高度、14px 上下留白 |
+| 文字层级 | 页标题 24px、分区标题 18px、普通指标名称 15px、重点数字 34px、紧凑指标数字 26px |
+| 辅助色 | 青、绿、紫、黄、红用于图标、分区与真实状态，不能代替状态文字 |
+
+白色和细边框负责分层，不反复套大卡片；标题与数值形成重点，单位和补充说明降低权重。蓝色强调重点数据，不要求所有数字着色。红、黄继续表示风险、失败或警告；趋势是否改善由业务决定，不能仅凭上涨或下降设绿色。
+
+原有 `--admin-*` 密度默认值继续有效。公共控件、表格行高、行内操作、弹窗尺寸和滚动由原组件与密度规范管理；蓝白外观只在显式主题范围内生效。
+
+页面边缘采用紧凑双层留白：`.page-container` 与 `.admin-workbench.admin-page` 分别使用 12px，避免旧外壳 20px 再叠加工作台 24px 挤占内容。页边距与区块间距使用独立令牌，不通过缩小表格行高、控件或文字来换空间。
+
+页面内复用另一个完整 `AdminPage` 时，仅在嵌入调用上显式加 `is-embedded`，去掉内层重复 padding；独立路由打开仍保留原页边距。订单内的测量审核分支是此用法的参考。不要在业务页重复声明公共间距变量，也不要全局清空所有面板内距。
+
+整页主体是一块连续白底，不再额外套一圈边框、圆角和阴影。包住主要列表的 `workbench-table`／`workbench-toolbar` 或整页详情 `workbench-panel` 显式增加 `is-page-surface`；内部指标、图表、并列独立面板继续保留细边框，表格单元格、表头和操作分隔线也保留。不能通过清除全部 `border` 把卡片、控件和表格边界一起抹掉。
+
+详情主容器的 `workbench-panel.is-page-surface` 在屏幕展示时不再叠加 padding，即使同时有 `is-compact` 也由外层页面或业务分区提供唯一一层留白。独立预装／装柜清单详情和货柜内的清单页签按此规则接入；内部独立紧凑卡片仍为 14px，普通卡片仍为 20px。该规则排除 `AdminPage` 页根并仅用于屏幕，不覆盖页面原有 12px 或打印内距。
+
+财务详情通过 `financeDensity.css` 的 `finance-density-detail` 统一收敛：账户、费用来源、对账单和结算单的页头、摘要、正文及底栏在屏幕上不重复增加左右内边距，由外层 `AdminPage` 提供。嵌套 `AdminPage` 必须使用 `admin-workbench is-embedded`；区块纵向间距、金额卡片、描述表单元格和筛选控件的内部留白保留，打印内距不变。
+
+国内／海外托盘、整柜业务、应收款统计和应收／应付结算单的顶部统计卡片独立置于列表工具栏与筛选区上方。卡片网格与紧随其后的 DataTable 工具栏之间外层 `gap` 为 `0`，留白由工具栏已有的上下 padding 与最小高度提供，不能再叠加 6px 或默认页面间距；卡片之间的网格间距独立保留。此规则仅适用于这类直接相邻结构，不清零普通业务分区或筛选区与表格之间的间距。
+
+间距和边框核对必须包含公共组件编译后的 scoped 选择器、模块规则、断点及加载顺序。显式接入规则应有稳定的优先级，不能仅凭源码出现 `gap: 0` 或 `padding: 0` 就判断已生效；自动合同检查与实际截图核对分别报告，不用 `!important` 或负外边距掩盖重复容器。
+
+### 公共样式接入
+
+页面直接导入 `@/styles/adminWorkbench.css`，保留原有密度入口，并在实际页面根容器增加 `admin-workbench`。不依赖先打开样板页后残留的 CSS，不将主题放入全局入口，不修改 `:root`。导航、顶栏、页签由总控在各自容器显式接入，不给包含业务页面的 `.app-shell` 或 `.app-main` 添加主题类；业务页和 Teleport 浮层仍须自己接入。
+
+```vue
+<script setup lang="ts">
+import '@/styles/adminDensity.css'
+import '@/styles/adminWorkbench.css'
+// 继续使用该页面原有数据、筛选、权限与事件。
+</script>
+
+<template>
+  <AdminPage class="admin-density admin-workbench">
+    <ListPageLayout>
+      <div class="workbench-table is-page-surface">
+        <DataTable :data="rows" :columns="columns">
+          <!-- 原有工具栏、查询和操作插槽 -->
+        </DataTable>
+      </div>
+    </ListPageLayout>
+    <AppDialog
+      v-model="detailOpen"
+      class="admin-density-dialog admin-workbench is-dialog"
+    >
+      <!-- 原有内容与尺寸配置 -->
+    </AppDialog>
+  </AdminPage>
+</template>
+```
+
+这个片段只说明主题作用域。`rows`、`columns`、弹窗宽高、事件与组件导入仍按目标页原实现补齐，不代表需要新建弹窗或更换承载方式。
+
+| 场景 | 公共类与用法 |
+|---|---|
+| 页头与分区 | `workbench-heading`、`workbench-title`、`workbench-meta`、`workbench-section`、`workbench-section-heading`、`workbench-section-title`、`workbench-badge` |
+| 普通指标卡 | `workbench-metric`、`workbench-metric-heading`、`workbench-icon`、`workbench-metric-label`、`workbench-metric-value`、`workbench-status`、`workbench-note` |
+| 紧凑指标 | 在指标卡和图标上增加 `is-compact`；不继承总览卡片的最小高度 |
+| 面板与提示 | `workbench-panel`、`workbench-notice`、`workbench-skeleton`；紧凑／自带头部面板使用 `is-compact`／`is-flush` |
+| 图表与空态 | `workbench-chart`、`workbench-chart-heading`、`workbench-chart-title`、`workbench-chart-actions`、`workbench-chart-canvas`、`workbench-chart-empty`、`workbench-chart-empty-icon` |
+| 标准列表 | **外层 `div.workbench-table` 包裹 DataTable**，统一外框、表头、边框、行悬停和分页强调；不修改业务列宽或行密度 |
+| 整页主要内容 | 主要列表的 `workbench-table`／`workbench-toolbar`、整页详情的 `workbench-panel` 增加 `is-page-surface`，去掉整页外框、圆角和阴影；详情主容器的屏幕 padding 为 0，保留页面根及内部卡片内距；主表顶部同时使用公共紧凑高度与左右边界，子表格不自动套用 |
+| 嵌入完整页面 | 仅在嵌入调用上加 `is-embedded`，清除内层 AdminPage 的重复内距；独立路由不加 |
+| 独立查询区 | QueryToolbar 自身添加 `workbench-query`，保留控件与换行；位于 DataTable 的筛选区时由外层提供独立搜索区的边框、底色及间距，内部不重复套卡片 |
+| 列表页签与操作 | 页签放 `toolbar-start` 并加 `workbench-list-tabs`，按钮保留原操作插槽；标准主表统一 48px 最小工具栏、32px 控件，无需销量页专属紧凑类。保留自动换行与键盘切换，嵌套表格、详情和弹框不继承该布局 |
+| 只有查询工具栏 | 外层 `div.workbench-toolbar` 包裹 DataTable，保留组件原有工具栏和筛选排列 |
+| 原生页签与输入 | 页签父级 `workbench-tabs`，保留按钮的 `aria-pressed` 和点击事件；原生输入使用 `workbench-input`，页面只保留业务宽度 |
+| 阶段节点 | `workbench-step`、`workbench-step-index`，从已确认的 `data-state` 选择状态，不从任务名或阶段顺序推断完成 |
+| 证据内容 | 容器 `workbench-evidence`；已有 `density-table` 保留行密度 |
+| 详情与表单 | 显式主题根保留原密度类，已有 `density-detail-*`、`density-fields`、`density-descriptions`、`density-form`、`density-form-section` 适配中性外观；字段列数、字号、业务色、校验及尺寸保持原契约 |
+| 抽屉 | 实际根使用 `admin-density-drawer admin-workbench is-drawer`，保留原有详情／编辑 modifier、方向、宽度、贴边形态和正文滚动 |
+| 白色品牌资源底座 | `workbench-brand-mark` 提供蓝底与公共圆角；图片比例、容器宽高由实际布局决定，不替换品牌图形 |
+| 辅助色 | 元素增加 `workbench-tone`，按需选择 `data-tone` 为 `blue`、`teal`、`green`、`purple`、`amber` 或 `rose`；语义胶囊可加 `workbench-badge is-toned` |
+
+DataTable 的属性透传目标是内部表格，不能只把 `workbench-table` 加到组件上就认为外框已接入。默认与 integrated 模式各保留原密度，不能为了外观切换模式。Teleport 弹框必须自身带 `admin-workbench is-dialog`，页面祖先不能替代；同时保留 `admin-density-dialog`、全屏、关闭、重开和正文滚动规则。抽屉使用 `is-drawer`，不能套用弹窗类改变承载。
+
+业务页只保留列数、排列、业务宽度与高度；接入公共类后删除被接管的私有配色、边框和标题外观，不能保留两套 CSS 再叠加优先级或 `!important`。共享组件应明确接入模式并核对实际调用者，避免影响尚未推广的页面。
+
+### 图表与数据表达
+
+Canvas 图表显式导入 `adminWorkbenchChartTheme`，在 option 构建处组合字体、轴标签、网格、颜色与 tooltip；不注册全局 ECharts 主题。业务 option 入口分别为 [`skuTrendChart.ts`](../apps/admin-web/src/modules/self-operated/skuTrendChart.ts)、[`dashboardChartOptions.ts`](../apps/admin-web/src/modules/self-operated/dashboardChartOptions.ts)、[`turnoverPresentation.ts`](../apps/admin-web/src/modules/self-operated/turnoverPresentation.ts)。
+
+- 趋势使用蓝色直线和轻面积。只有连续完整数据段可以填充，未知与缺失日期继续断线，未完整日继续以虚线／空心点表达。
+- 柱图使用圆角、真实数值尺度和清晰单位；未知分类用灰色并显示文字，不把缺失量补成零。排名、tooltip 内容、精度和点击业务键由业务模块负责。
+- 进度环只表达当前已知阶段；总量未知、分母为零或数量异常时保留未知状态。待机不等于全部完成，当前阶段 100% 不代表报表已发布。
+- 普通、加载、空数据、错误和部分数据都保留已有语义。减少装饰不能删掉覆盖不足、过期、权限或操作阻断提示。
+- 图表面积按用途选择。库存周转保留 360px 面板及内部伸缩画布，不机械套用固定画布类；体积图保留右侧数值标签空间。长标签、长数字及单位不得挤出可视区域。
+
+- 同类指标统一千分位，保留业务小数精度和单位，不为排版缩写成“万”或先舍入再计算；筛选文案明确对象，不使用多个无上下文的“全部”。
+- 运行看板区分主状态、阶段进度、发布结果及等待原因；已关闭／暂停与保留进度应同时可辨认，不把保留进度表达为正在续采。采集完整与修订核对未知分别表达。
+- 横向宽表保留业务标识的可见性；只读库存表可固定 SKU 首列，有操作列的业务表仍将操作列放第一列。按钮按用户理解的结果命名，保留原行为、权限和禁用条件。
+
+### 导航外壳
+
+自营样板不包含导航外壳；后续 Admin 推广由总控统一维护公共样式、共享组件和外壳，各业务任务按实际消费者逐模块接入。外壳参考 `AppLayout.vue`、`WorkspaceTabs.vue` 和 `shell.css`：白色顶栏、蓝色激活态、轻分隔线，现有白色 Logo 保留蓝底承载；折叠菜单和页签下拉单独声明 `popper-class` 主题范围。保留菜单尺寸、彩色图标、未保存标记、权限与页签行为，不能通过全局注入主题或替换所有 Element 默认样式跳过验收。Client、PDA 不自动套用。
+
+折叠侧栏保留 76px 宽度，展开仍为 240px。菜单宽度随纵向滚动条占用后的实际可用空间伸缩，折叠触发器去掉重复横向 padding 和图标右边距并居中；侧栏只允许纵向滚动，悬浮子菜单继续 Teleport 到侧栏滚动区之外，不能为去掉横向滚动条而裁切子菜单。
+
+## 公共样式维护边界
+
+<a id="国内仓客户管理的样式维护边界"></a>
+
+密度、蓝白主题与基础组件分别维护各自能力；模块只提供字段、列数、跨列、业务宽高及已确认例外，不重复定义公共默认值。下表适用于本轮已明确接入的实际消费者。
 
 | 要修改什么 | 唯一维护位置 | 页面需要做什么 |
 |---|---|---|
 | 正文/辅助/分区/页头字号 | `adminDensityTokens.css` 的 `--admin-font-*` | 引用变量，不重新写 13px 等普通字号 |
 | 表格行高、输入高度、操作按钮高度、页签高度 | `--admin-row-height`、`--admin-control-height`、`--admin-action-height`、`--admin-tab-height` | 使用已有公共组件和公共类 |
 | 常用间距、圆角、普通数据区底色 | `--admin-space-*`、`--admin-radius`、`--admin-surface` 等 | 业务布局引用变量；不可在页面重定义变量默认值 |
+| 表头配色、独立搜索区圆角与间距 | `foundation.css` 的 `--cc-list-table-header-*`、`--cc-list-query-*` | 标准组件消费统一值，不在模块重定义 |
+| 列表纯文字行操作 | `adminTextActions.css`，`RowActions` 的 `text-actions`／手写组的 `admin-text-actions` | 保留动作资格与显式危险语义，不复制旧描边行按钮 |
 | 描边按钮外观、悬停/禁用/焦点状态 | `adminDensity.css` 的 `.density-action` | 只选择 `data-tone` 与业务事件 |
+| 列表状态／分类页签（国内订单、尾程订单、车辆、供应商、整柜业务、国内／海外货柜工作台、退货库存） | `adminDensity.css` 的 `.density-status-tabs` | 原生按钮使用 `is-active`，Element 页签同时保留 `density-element-tabs`；保留业务分类、图标、数量、查询与切换，不在页面复制页签样式；详情页签继续使用原有详情规则 |
 | 详情返回导航 | `.density-back` | 使用 `link`，保留返回事件和可访问名称；客户管理按纯文字约定保留返回文字 |
 | 详情页头与业务摘要 | `.density-detail-header` / `.density-detail-heading` / `.density-detail-title` / `.density-detail-overview` | 与国内订单样板共用排版；页面提供实际业务编号、状态及摘要，不复制标题字号和摘要间距 |
 | 连续白底独立详情容器 | `DetailPageLayout` 上的 `.density-detail-layout` | 显式接入统一页头分隔线、正文间距与零区块间隙；正文去掉重复面板，业务仅保留列数和长字段跨列 |
@@ -199,6 +402,8 @@
 
 ### 使用约定
 
+下列 `density-action` 是非列表行操作的描边按钮原语；标准列表行操作使用上文 `text-actions`／`admin-text-actions`，不照搬此描边示例。
+
 ```html
 <!-- 业务按钮只选择语义，不复制尺寸、颜色及交互状态规则 -->
 <el-button class="density-action" @click="edit">编辑</el-button>
@@ -215,13 +420,15 @@
 
 `density-actions` 使用 `gap` 管理间距，并将 `--cc-list-action-sibling-margin` 设为 0；`DataTable` 通过该变量保留未接入按钮的默认 8px 左边距。不得将两份间距叠加，也不以更强选择器在页面逐个覆盖。
 
+纯文字行操作由 `adminTextActions.css` 统一将按钮横向内边距和组间距减半：每侧 5px、组间距 3px（随公共间距变量缩放），相邻文字间留白由 26px 收紧为 13px。描边操作继续使用原间距；页面不单独覆盖文字操作间距。
+
 ### 防止维护退化
 
 1. **同一通用外观只有一个实现。** 已由公共类接管的按钮配色、页签高度、信息表边框或弹框内边距，删除原页面声明，不能保留两套后再增加优先级或 `!important`。
 2. **新增通用尺寸先改变量。** 模块与页面只引用 `--admin-*`；禁止在页面重定义公共默认值。局部标签宽度是明确的业务参数，不改变全局标签宽度。
 3. **不要把代码搬到模块 CSS 就称为公共化。** 多个业务共用的按钮、页签、信息表与弹框规则留在公共层；模块 CSS 不能依赖另一个业务模块的类名，也不引入第二套按钮颜色变量。
 4. **保留显式接入边界。** 公共样式不能使用无范围的 `.el-button`、`.el-table`、`.el-dialog` 选择器。Teleport 的弹框、抽屉必须自己携带密度类；不能仅依赖页面父级。
-5. **共用组件保留未接入消费者。** CSS 变量的兜底值用于独立渲染和未接入入口；两个已接入模块始终由公共变量决定实际值，兜底值不是第二份密度配置。打印标签、PDF 尺寸、原图、画布和既有窄屏规则不能机械替换。
+5. **共用组件保留未接入消费者。** CSS 变量的兜底值用于独立渲染和未接入入口；已接入消费者始终由公共变量决定实际值，兜底值不是第二份密度配置。打印标签、PDF 尺寸、原图、画布和既有窄屏规则不能机械替换。
 6. **公共调整按消费者回归。** `adminDensity.test.ts` 维护明确的页面/组件清单，不扫描全部后台。检查模板中公共按钮、页签和信息表的真实祖先是否带有密度入口，不能仅断言文件导入了 CSS 或出现过密度类；页面弹框带有 `admin-density-dialog` 不代表列表与详情已接入。新增接入时同步清单及逐操作矩阵，运行合同、受影响测试、类型检查、全量测试和构建。
 7. **视觉与代码分开记录。** 本轮默认人工截图；代码通过不等于视觉验收通过。已确认业务宽度和工作区高度可以保留为例外，例外写入核对记录。
 
@@ -230,33 +437,16 @@
 ### 先确定范围，再选择公共能力
 
 1. 用导航与实际路由列出全部菜单入口，以及新建、详情、编辑和深链页面；不能把文件夹数量当作页面覆盖数。为每个页面沿实际组件引用列出弹框、抽屉、消息确认、预览与打印入口，按逐操作矩阵记录承载方式。
-2. 默认复用普通表格 36px 行高、正文 13px、辅助文字 12px、行内描边按钮 28px、页签 38px、轻量返回和连续信息表。新模块的行内业务操作默认纯文字；顶部/提交保留 32px 主次按钮。动作语义色沿用本规范，不通过按钮文字自动猜测。
+2. 默认复用普通表格 36px 行高、正文 13px、辅助文字 12px、行内操作基准 28px、页签 38px、轻量返回和连续信息表。新模块的行内业务操作默认纯文字；顶部/提交保留 32px 主次按钮。动作语义色沿用本规范，不通过按钮文字自动猜测。
 3. 模块只保留业务列宽、字段跨列、布局与图纸尺寸等参数。`density-fields` 的四列是默认值，不是固定业务要求；返回位置与大弹框尺寸也不能从订单整页复制。
 4. 编辑表格、流程图、装柜模型、数据看板、图片、标签和 PDF 保留业务所需面积；指标卡和图表不得套用 `.density-fields`或其他详情表格样式，模型画布和打印尺寸不套普通行高。空态、错误、长内容、处理中、只读和无权限仍要可用。
+5. 获准采用蓝白外观的页面按 [蓝白样板接入入口](界面参考/蓝白卡片式工作台风格参考.md#其他页面该参考哪个样板) 选择对应页面类型；列表参考销量分析，复杂分析参考库存分析，运行看板参考数据采集，不一律复制经营总览的大指标卡。保留现有密度根，显式接入主题根和公共类，浮层自行声明作用域；具体覆盖与截图结论回到目标模块现有矩阵。
 
-### 完整接入示例
+### 密度类与浮层接入
 
-下面展示已有页面的接入结构，`rows`、`columns`、事件与表单仍使用该页面原实现。页面脚本直接导入 `@/styles/adminDensity.css`，不依赖先进入其他菜单后残留的样式，也不把这份 CSS 放入 `scoped` 样式块。
+页面直接导入 `@/styles/adminDensity.css`，实际根使用 `admin-density`；蓝白主题的组合示例见本文“蓝白主题与图表”。
 
-```vue
+样式接入不授权新增业务动作。详情复用页面根节点的 `admin-density`；原生详情页签用 `density-tabs` / `density-tab-icon`，连续信息表用 `density-fields`。既有 Element 页签使用 `density-element-tabs`；页签栏与正文分离时隐藏空内容容器。在 `el-tab-pane` 内承载正文的页面必须同时使用 `density-contained-tabs`，保留正文并由公共样式设置内容间距。不得依赖页面 CSS 覆盖隐藏规则。既有原生资料/历史表用 `density-table`，分组表单用 `density-form`。返回按钮使用 `link class="density-back"`，跟编号、状态排在同一行。
-<AdminPage class="admin-density">
-  <ListPageLayout>
-    <DataTable :data="rows" :columns="columns">
-      <template #actions="{ row }">
-        <div class="density-actions">
-          <el-button class="density-action" @click="openDetail(row)">详情</el-button>
-          <el-button class="density-action" data-tone="warning" @click="review(row)">审核</el-button>
-        </div>
-      </template>
-    </DataTable>
-  </ListPageLayout>
-  <AppDialog class="admin-density-dialog" v-model="editorOpen" title="编辑资料">
-    <!-- 原有业务表单 -->
-  </AppDialog>
-</AdminPage>
-```
-
-此结构只说明样式接入，不授权新增审核等业务动作。详情复用页面根节点的 `admin-density`；原生详情页签用 `density-tabs` / `density-tab-icon`，连续信息表用 `density-fields`。既有 Element 页签使用 `density-element-tabs`；页签栏与正文分离时隐藏空内容容器。在 `el-tab-pane` 内承载正文的页面必须同时使用 `density-contained-tabs`，保留正文并由公共样式设置内容间距。不得依赖页面 CSS 覆盖隐藏规则。既有原生资料/历史表用 `density-table`，分组表单用 `density-form`。返回按钮使用 `link class="density-back"`，跟编号、状态排在同一行。
 
 Teleport 弹框用 `admin-density-dialog`，抽屉框架用 `admin-density-drawer`，`ElMessageBox` 用 `customClass: 'admin-density-confirm'`；这些浮层必须各自声明，页面祖先不能替代。抽屉当前公共框架负责字号、标题和正文边距；其正文若复用页面级表格、信息表或按钮原语，在正文业务根节点显式接入 `admin-density`。不要把名为 Drawer 的嵌入组件当作实际抽屉，承载方式以模板和调用端为准。
 

Client界面样式规范.md

@@ -2,14 +2,17 @@
 
 ## 范围与验收状态
 
-- 本规范由客户端样式对话确认建立，首个验收样板为“头程物流 → 订单列表”（`/orders/first-leg`）。当前为首版实现，待人工截图确认；通过后再逐模块推广。
+- 本文是客户端样式的现行维护正文，按新增页面和列表分别定义规则。后续客户端的新增、新建、下单操作统一采用下文“新增页面”的风格；列表沿用列表章节，不把两者的控件尺寸和间距混用。
+- 新增页以“海外采购下单”和“美国本土卡车下单”在当前对话确认的外观与布局为样板：满宽、无阴影、精简说明、12px 模块间距、浅色 placeholder 和字段右上角校验提示。两页的不同字段排列见下文，不按整页截图机械复制。规范确定不等于所有新增页已改造或通过视觉验收。列表首个验收样板为“头程物流 → 订单列表”（`/orders/first-leg`），其验收状态见文末。
 - 只维护 `apps/client-web/` 内的样式和公共组件，不与 Admin 跨应用链接依赖。
 - 左侧菜单背景保持现状，不修改 `shell.css` 中的导航背景，也不通过全局品牌变量间接改变导航。
-- 标准通过正文容器 `.client-ui` 接入；首批覆盖订单列表。创建、详情与其他模块需分别核对承载方式和字段，不以列表通过代替整模块验收。
+- 标准通过正文容器 `.client-ui` 接入；新增页在本页或新增表单容器内覆盖对应令牌，不将新增页尺寸写入全局默认值。创建、详情与其他模块需分别核对承载方式和字段，不以某个样板通过代替整模块验收。
 - 按 1920×1080、浏览器缩放 100% 验收，保留现有窄屏能力。
 
 ## 公共入口与职责
 
+按任务阅读：新增、新建、下单读“新增页面”；列表读“尺寸与布局”“颜色与按钮”及适用的列表样板条款。视觉核对方法只维护在 [Admin / Client 前端原型还原验收规则](Admin-Client前端原型还原验收规则.md)。
+
 | 入口（相对 apps/client-web） | 职责 |
 |---|---|
 | `src/styles/client-ui.css` | `--client-*` 颜色、尺寸、间距；正文按钮和状态外观 |
@@ -17,11 +20,136 @@
 | `src/components/common/DataTable.vue` | 表格、工具栏、行操作、分页；工具栏内容用插槽提供 |
 | `src/components/common/tableActions.ts` | 三个操作以内全部展示，超过三个折叠；禁用和加载状态执行保护 |
 | `src/modules/first-leg/utils/firstLegOrder.ts` | 头程状态码 → 语义色，不在公共样式中判断业务状态码 |
+| `src/modules/cross-border/views/ProcurementView.vue` 的新增分支 | 新增页外观样板；只参考当前新增分支，不跨模块导入该业务页面 |
+| `src/modules/cross-border/components/BusinessOrdersView.vue` 与 `TransportDemandForm.vue` 的新增分支 | 本土卡与散板共用新增外观；参考三列短字段、两列详细地址和右上角校验。编辑分支及各业务的视觉验收分别核对，不从共用组件推定已通过 |
 
 页面只提供字段、操作、业务状态与权限，不再覆盖公共工具栏 padding、表格行高及分页 padding。确有业务差异时增加明确的组件能力，避免重复页面 CSS。
 
+## 新增页面
+
+### 适用范围与设计依据
+
+- 后续客户端新增、新建、下单操作按本章实施。既有页面在对应任务触及时按授权范围调整，不因规范更新批量改造其他页面。
+- 本章替代最初海外采购 HTML / UI Redesign Spec 中的 1240px 内容宽度上限、26px 模块间距、24px 表单卡片内边距及重复说明文字；不采用带阴影的大圆角截图版本。桌面导出文件是参考材料，后续规则统一更新本文，不要求开发者依赖个人桌面文件或设计工具链接。
+- 统一外观不统一业务表单：字段、顺序、分组、必填条件、默认值、权限、计算口径和提交行为仍按各业务契约及已确认原型。海外采购的采购方向、币种、收件资料等不自动成为其他新增页的字段。
+- 独立页面、居中弹框、抽屉仍按对应操作的已确认承载方式；本规范不将所有新增操作改成独立页面。后续用户明确确认的外观例外优先于本章，其余通用外观不回退到旧原型的大留白、阴影或说明堆叠。
+- 本章只约束新增内容区。复用现有侧边栏、顶栏、页签和面包屑，不复制设计稿中的静态用户名、菜单或页签，不因新增页改造修改公共外框。
+
+### 页面组织与信息密度
+
+1. 独立新增页使用一个清晰标题，右侧按现有列表访问权限提供返回入口；默认不增加标题下的解释性段落。
+2. 摘要区按业务需要使用，展示数量、预算等真实表单派生值。已有三项摘要时等宽三列；没有必要摘要的表单直接进入业务区，不为套用样板硬凑三个指标。
+3. 表单按业务分组呈现为独立白色卡片，标题位于卡片上方，以小圆点区分分组。常规短字段使用三列等宽网格；成对详细地址可使用两列，单个长地址、链接、长备注可占满整行。具体排列按下文样板及业务确认，不把所有区域强制设成相同列数。既有明确分组和摆放不得因凑满网格擅自重排。
+4. 独立页底部操作靠右，返回列表在前、主提交按钮在后；返回资格沿用现有权限。弹框或抽屉保留其已确认的取消、关闭和提交语义，不硬加“返回列表”。
+5. 内容填满所在容器的可用宽度，使用 `width: 100%`、`min-width: 0`；独立页不设置 1240px 等固定内容上限造成右侧空白。弹框和抽屉中的满宽指其正文容器，不是铺满浏览器视口；保留应用壳层或容器已有边距，不重复包一层大 padding。
+6. 在 1920×1080、100% 缩放下优先减少无效留白和重复文案，使主要填写内容更集中。长表单允许正常滚动，不通过隐藏必要字段、缩小字号、裁切内容或未经确认拆步骤强行塞进一屏；一屏效果以人工截图为准。
+
+### 字段列数与宽度
+
+“内容区满宽”“字段单独一行”和“控件占满整行”是三个不同要求，实施前按下表区分。
+
+| 场景 | 当前标准 | 样板 |
+|---|---|---|
+| 页面、表单卡片 | 铺满可用正文宽度，不留下固定宽度上限造成的右侧空白 | 两个新增页 |
+| 常规短字段 | 一行三列等宽，横向间距 20px；输入框填满所在列 | 采购品类／商品名称／商品规格；本土卡取货地／联系人／电话 |
+| 前置选择项独立一行 | 单独占一行位置，控件只占三列中的一列，与下一行第一列对齐，右侧留空 | 采购方向、车辆类型 |
+| 成对详细地址 | 同一行两列等宽，分别放取货地址、送达地址 | 本土卡运输信息 |
+| 单个长字段 | 按已确认分组占满该行，例如商品链接、完整收货地址、备注 | 海外采购及本土卡备注 |
+
+- 前置选择项的一列宽度按正文网格计算：`calc((100% - 40px) / 3)`，其中 40px 是两个 20px 列间距。不得改成任意固定的 280px，也不得把“独立一行”理解成下拉框横跨整张卡片。
+- 混合三列短字段与两列地址时，可以使用六列基础网格，短字段跨两格、详细地址跨三格；这只是实现方式，用户看到的仍是三列或两列。前置项独占整行位置，再将自身宽度限制为标准一列。
+- 字段按实际阅读顺序写入模板，键盘 Tab 顺序与视觉顺序一致；不只用 CSS `order` 把同一组联系人拆散重排。
+
+### 两个样板的具体排列
+
+以下是后续页面可对照的布局依据，不是要求其他业务复制相同字段、默认值或摘要指标。
+
+| 页面／区域 | 已确认排列 |
+|---|---|
+| 海外采购／摘要 | 数量、预算单价、币种三张等宽卡片，数值与当前表单联动 |
+| 海外采购／商品与预算 | 采购方向独立一行、控件一列宽；其后采购品类／商品名称／商品规格三列，采购数量／预算单价／预算币种三列；商品链接整行，预算总上限用普通文本 |
+| 海外采购／收件资料 | 收件人、联系电话各占三列网格的一列，第三列留空；完整收货地址、采购要求各占整行 |
+| 本土卡／运输信息 | 车辆类型独立一行、控件一列宽；取货地／取货联系人／取货联系电话一行三列；送达地／送达联系人／送达联系电话一行三列；取货地址／送达地址一行两列 |
+| 本土卡／货物信息 | 托数／总重量／总体积一行三列 |
+| 本土卡／费用与时效 | 预算总价与币种组成同一字段，占两列网格的左列，右列留空；取货时间／送达时间一行两列；备注整行 |
+
+代码参考：[海外采购新增分支](../apps/client-web/src/modules/cross-border/views/ProcurementView.vue)、[本土卡页面外框](../apps/client-web/src/modules/cross-border/components/BusinessOrdersView.vue)、[本土卡表单](../apps/client-web/src/modules/cross-border/components/TransportDemandForm.vue)。新业务先确定字段分组与承载方式，再使用通用外观；若要调整上述排列或推广到其他共用分支，须在对应任务中明确范围，不顺手扩展。
+
+### 尺寸与间距
+
+以下数值分别适用，不将所有间距一律改为 12px。
+
+| 元素 | 新增页标准 |
+|---|---|
+| 页头、摘要区、表单模块底部间距 | `margin-bottom: 12px` |
+| 摘要卡之间 | 横向 gap 16px |
+| 摘要卡内部 | padding 12px 16px；纵向 gap 8px |
+| 摘要标题行 | 图标与标题 gap 12px；图标底块 44×44px，圆角 8px；线性图标 20px |
+| 表单卡片 | padding 16px；1px 边框；圆角 10px |
+| 摘要卡片 | 1px 边框；圆角 10px |
+| 分组标题 | 下方 margin 10px；圆点 9px；圆点与标题 gap 10px |
+| 表单网格 | 常规三列等宽，两列／整行区域按上文布局；纵向 gap 12px、横向 gap 20px；单项不另叠加底部 margin |
+| 标签与控件 | 间距 6px；标签行高 20px |
+| 字段校验提示 | 字段右上角、标签同行，12px 字号、20px 行高；不增加底部占位和字段高度 |
+| 输入框、选择框 | 最小高 44px；圆角 6px；padding 10px 14px |
+| 多行输入 | 最小高 110px；padding 11px 14px；允许纵向调整；字数计数在下方右侧，间距 4px |
+| 预算等必要汇总值 | 上方 margin 10px；字号 13px、行高 20px；普通文本，不做说明横幅 |
+| 底部按钮间距 | gap 12px |
+| 次按钮 | 最小高 44px；padding 10px 18px；圆角 6px |
+| 主按钮 | 最小高 44px；padding 12px 28px；圆角 6px |
+
+### 字体、颜色与状态
+
+字体沿用中文无衬线栈：`"PingFang SC", "Microsoft YaHei", "Noto Sans SC", sans-serif`。
+
+| 用途 | 标准 |
+|---|---|
+| 独立页标题 | 26px / 700；margin 0 |
+| 分组标题 | 18px / 700 |
+| 正文、输入内容 | 14px / 400 |
+| 字段标签 | 14px / 600 |
+| 摘要标题、数值、单位 | 15px / 600；30px / 700；14px / 500 |
+| 内容底色、卡片及控件底色 | `#F4F7FC`、`#FFFFFF` |
+| 主文字、标签、次要文字 | `#1F2937`、`#374151`、`#6B7280` |
+| 占位文字 placeholder | `#B0B7C3`；输入框、多行输入和选择框的未填写提示统一使用，已填写内容保持正文色 |
+| 卡片边框、控件及次按钮边框 | `#E3E8F0`、`#D5DCE8` |
+| 主按钮 | `#2F7BFF` 背景、白字 |
+| 次按钮、摘要数值 | `#1D5FE0`；次按钮白底描边 |
+| 必填星号 | `#E5484D` |
+| 焦点 | 2px `#2F7BFF` outline；无发光阴影 |
+
+- 卡片、输入框、选择框及其弹出层、按钮均不使用装饰阴影、渐变、毛玻璃或位移动效；分隔依靠边框与底色。
+- 主要操作以蓝色为强调色，其他颜色仅用于必要的业务状态、错误反馈和小面积分组标记。样板图标底块可使用蓝 `#EAF2FF / #2F7BFF`、绿 `#E8F8F0 / #16A34A`、橙 `#FFF5E0 / #D97706`；分组圆点使用蓝色或青色 `#0EA5A4`，不把整块表单染成状态色。
+- 已确认的原型图标沿用对应资源；未定义的图标使用项目既有图标库，不引入第二套组件库或表情图标。无需要时不添加装饰图标。
+- 保留清晰的禁用、提交中、焦点和错误状态，状态不只依赖颜色表达；不得为了“干净”删去校验、失败重试或权限说明。
+
+### 文案与数据绑定
+
+- 删除重复解释性提示：不恢复页头“一单一个商品及规格……”、摘要卡下的说明行，也不新增类似的常驻说明段落或黄色提示横幅。
+- 字段标签与简短占位提示负责说明输入用途；校验错误、提交失败、无权限及必要业务提示按实际状态就近出现。保留影响客户正确操作的必要信息，不将“去提示”理解为关闭验证或隐藏错误。
+- 未填写字段应提供简短 placeholder，例如“请选择车辆类型”“请输入取货联系人姓名”“请选择取货日期和时间”；不要通过 `placeholder=""` 将必要输入提示清空。按字段性质标明选填，不使用整段业务说明代替占位文字；已存在默认值时显示真实值，不为显示 placeholder 清除默认值，尤其不得把有效的 `0` 当作空值。
+- 保留真实汇总数据，例如货款预算总上限；摘要和汇总跟随当前表单实时更新，不能保留设计稿中的静态 `1`、`USD` 或 `0 / 1000`。
+- 空值显示“—”，合法零值按零展示；金额沿用现有精度处理，不因样式调整改变校验或金额口径。支持多个币种或方向的业务继续联动展示，不用原型示例缩减现有能力。
+
+### 必填校验与稳定布局
+
+- 字段错误提示统一放在输入框右上方，与字段标签同行、靠右对齐；保留必填星号与错误边框。提示出现、纠正或清空时，后续字段和整张卡片不得上下跳动。
+- 错误不参与正常文档流，不在控件下面额外预留 16px 空行；标签区应能同时容纳标签与简短错误文案。对当前明确的单行标签，可相对 `.el-form-item__content` 使用 `bottom: calc(100% + 6px)`、`right: 0` 定位，宽度避开标签。更长标签或提示须单独核对，不截断必要错误或覆盖标签、输入内容。
+- 必填星号必须配套字段级校验：Element Plus 表单绑定 `ref`、`model`、`rules`，校验项绑定对应 `prop`；文本失焦、选项变化时校验当前字段，提交时校验全部必填项。未通过时不发送创建请求，不用整页错误代替缺失字段提示。
+- 填写正确并再次触发校验后清除该字段错误；重置表单时清除校验状态；提交中防重复点击，失败保留填写内容。采购预算单价 `0` 是有效值，不得误报必填。
+- 已有金额、格式、权限和服务端校验继续保留；非字段级请求失败仍按原有页面错误反馈处理。本规范不改变业务规则，也不将两页未统一的所有校验逻辑推定为已统一。
+
+### 接入与核对
+
+- 使用现有 Vue、Element Plus 和 `.client-ui`；新增页所需 44px 控件、14px 字号、配色等在新增内容容器内覆盖。列表仍使用下文的 32px 控件，不修改全局 `:root` 使其他页面跟随变化。
+- 同一组件同时承载列表、新增和详情时，新增样式必须限制在新增分支；不得扩大到列表、详情或侧边导航。跨模块稳定复用时按应用指引抽取通用能力，不跨模块导入采购页，也不复制设计工具的 React 运行时。
+- 新增或整体重排页面时，按前端验收规则核对该操作的承载方式、满宽、字段分组和按钮；重点检查前置选择项是否与三列网格对齐、短字段和成对地址列数、placeholder、长值、摘要联动、空值与零值、校验出现／消失时的位置稳定及正常滚动。纯文案或小间距调整只核对差异，不重复建立完整矩阵。
+- 自动检查按实际变更选择；文案和纯样式不自动升级为全量测试、类型检查或构建。真实视觉由人工提供截图确认，部署成功或静态资源命中不等于一屏布局通过；不开展当前阶段未要求的窄屏验收。
+
 ## 尺寸与布局
 
+本节用于列表、查询栏和表格工具栏；新增表单使用上文“新增页面”的尺寸。
+
 | 项目 | 标准 |
 |---|---|
 | 正文、表格、按钮字号 | 13px |
@@ -42,6 +170,8 @@
 
 ## 颜色与按钮
 
+本节用于列表操作和状态语义；新增表单按钮的外观使用上文“新增页面”，业务危险语义和权限要求仍须保留。
+
 | 用途 | 文字色 | 背景色 |
 |---|---|---|
 | 默认操作 | `#1777ff` | 白色 |

README.md

@@ -1,62 +1,49 @@
-# 虫虫出海文档索引
+# 虫虫出海文档入口
 
-项目交付文档按业务域组织。当前开发环境以端到端全流程为统一范围；历史规划、确认和验收记录保留在对应业务域目录，仅用于追溯决策，不构成功能边界。
+本文件只负责选入口，不保存业务规则或部署进度。已知页面、文件、API 或当前正文时跳过本文件；未知代码入口查[业务索引](业务快速索引.md)的命中行，不沿所有 README 逐层读取。
 
-## 业务域文档
+## 按任务选一种入口
 
-- [业务快速索引](业务快速索引.md)：按关键词检索跨端代码入口与业务边界；先查根 AGENTS.md 短路由，按需读取命中行。
+| 任务 | 从哪里开始 |
+|---|---|
+| 改代码、文案或局部逻辑 | 已知目标文件及适用 `AGENTS.md`；业务语义不明才补一段正文 |
+| 只有中文业务词或多义词 | [业务索引](业务快速索引.md)，代码入口与规则正文分开选择 |
+| 跨阶段流程、节点关系或上下游交接 | [全流程维护入口](头程到尾程/README.md)，只查受影响阶段 |
+| 已知某个业务域，需要找规则 | 下表选择该域；找到正文后停止扩展 |
+| 运行、验证、部署或数据库操作 | 下方工程专题，按操作类型只选对应章节 |
 
-- [订单与客户](订单与客户/README.md)：登录认证、客户与企业、权限、头程订单和客户工作台。
+## 业务域入口
-- [入库测量与计费](入库测量与计费/README.md)：预约取货、到仓收货、箱码与箱唛、测量、尺寸策略、计价和入库费用。
-- [国内货柜履约](国内货柜履约/README.md)：分柜与同柜、智能排柜、订舱、拖车、PDA 拣货、装柜、报关和国内出仓。
-- [海外仓业务](海外仓业务/README.md)：船节点、海外接柜、入仓、库存、托盘、换标、转运、废弃、退货、排车、PDA 出库、派送、异常退回、客户回访、一件代发及海外本土业务。
-  - [船节点标准化契约](海外仓业务/船节点标准化契约.md)：统一船司原始状态、标准节点、预计/实际时间、异常事实、还柜停止规则和新增船司接入门禁。
-- [财务管理](财务管理/README.md)：应收、应付、费用池、账单、收款、成本、核销、凭证以及国内外业务费用来源。
-- [打印标签维护](打印标签维护/README.md)：箱唛、各类托盘标、HOLD、BOL 与其他单据的现状盘点、参考样张和逐项改版记录。
 
-## 全流程公共契约
+| 业务域 | 入口 |
+|---|---|
+| 客户、企业、权限与头程订单 | [订单与客户](订单与客户/README.md) |
+| 到仓、测量、箱码、计价与入库费用 | [入库测量与计费](入库测量与计费/README.md) |
+| 分柜、装柜、订舱、拖车、报关与国内出仓 | [国内货柜履约](国内货柜履约/README.md) |
+| 接柜、库存、库内服务、排车、预约与海外本土业务 | [海外仓业务](海外仓业务/README.md) |
+| 费用入池、账单、资金账户与收付款 | [财务管理](财务管理/README.md) |
+| 自营经营、库存周转与领星采集 | [自营业务](自营业务/README.md) |
+| 箱唛、托盘标、HOLD 与 BOL | [打印标签维护](打印标签维护/README.md) |
 
-- [头程下单到尾程出库全流程操作手册](头程下单到尾程出库全流程操作手册.md)：从客户头程下单、国内收货测量、分柜装柜和国内出仓，贯通跨区尾程建单、海外接柜入仓、排车、PDA 拣货与尾程出库的角色、操作、状态、编号、门禁和异常处理。
+## 公共契约与工程专题（命中才读）
-- [头程下单到尾程出库现状流程全景清单](头程下单到尾程出库现状流程全景清单.md)：以 F01～F40 盘点现有主链、并行流程、条件分支和异常流，明确操作人、入口/出口状态、单据、编号、数据交接和评审项；应先评审本清单，再进入优化。
-- [头程到尾程分阶段流程](头程到尾程分阶段流程/README.md)：F01～F40 六个阶段现状文档已全部完成，逐阶段记录操作、字段、状态、数据流、异常、完成判定和上下游交接条件，可按阶段评审并进入优化。
-- [头程到尾程 AI 流程优化上下文包](头程到尾程AI流程优化上下文包.md)：统一 AI 分析所需的术语、流程变体、RACI、阶段合同、阻断分类、问题证据、指标口径、优化卡模板和完成定义。
-- [头程下单到尾程出库流程易用性与数据流转优化方案](头程下单到尾程出库流程易用性与数据流转优化方案.md)：基于已走通主链梳理现状操作问题，提出统一进度、下一动作、操作回执、数据归属、跨区可观测、PDA 易用性、P0-P2 优先级和验收指标。
-- [跨区域认证与服务通信契约](跨区域认证与服务通信契约.md)：统一账号、国内/海外 Token、双区域 API、JWKS、Outbox/Inbox 与服务身份边界。
-- [双区域部署与 Nacos 规划](双区域部署与Nacos规划.md)：开发/测试同机共置、生产国内/海外独立控制面、Nacos、数据库及 Event Bridge 部署边界。
-- [平台、客户层级与权限契约](平台客户层级与权限契约.md)：平台/客户两级产品语义、列表包含详情的只读权限和跨层同步要求。
-- [统一订单主状态与操作契约](统一订单主状态与操作契约.md)：统一订单状态、操作编码、内部状态映射和可信履约回传边界。
-- [Admin/Client 前端原型还原验收规则](Admin-Client前端原型还原验收规则.md)：页面操作承载方式、视觉还原、响应式检查和验收证据要求。
-- [Admin 高密度界面规范](Admin高密度界面规范.md)：已确认订单样板的字号、间距、表格、描述表、弹框和彩色页签规则，以及国内仓、客户管理推广入口。
-- [Admin 客户管理样式核对记录](Admin客户管理样式核对记录.md)：客户列表、海外仓阶梯费用及关联详情和弹框的样式与人工验收项。
-- [Admin 国内仓样式核对记录](Admin国内仓样式核对记录.md)：7 个菜单、关联详情与浮层的范围、样式复核和验收证据。
-- [Admin 货柜管理样式核对记录](Admin货柜管理样式核对记录.md)：订舱、拖车、送柜报关、清关提柜入口及共享组件边界。
-- [Admin 海外仓样式核对记录](Admin海外仓样式核对记录.md)：海外仓 10 个菜单、独立详情、作业弹框和共享组件显式接入边界。
-- [AI 工程执行与协作约束](AI工程执行与协作约束.md)：工作区、依赖、Git、部署、数据库、质量门禁和独立任务协作规则。
-- [数据库中文注释维护规范](数据库注释维护规范.md)：数据库注释口径、职责、迁移流程、自动门禁与实值验收要求。
-- [数据库版本迁移与 Jenkins 自动发布方案](数据库版本迁移与Jenkins自动发布方案.md)：两人团队自动迁移规划；统一工具入口、自动编号、开发/测试/生产执行分工、单服务迁移范围、漏写迁移检查、Flyway 校验、失败候选修订、发布证据保留、带数据升级演练及实施顺序。
-- [数据库迁移操作手册](../baiyue-firstleg/deploy/sql/数据库迁移操作手册.md)：开发者和发布执行人日常使用说明；包含新建、检查、生成清单、测试执行、生产晋级、失败处理和维护规则。
-- [生产服务监控告警与无停机发布方案](生产服务监控告警与无停机发布方案.md)：容器与外部可用性监控、部署期告警处理、自动恢复、发布通知及滚动/蓝绿发布演进方案。
-- [测试环境 Jenkins 部署指南](测试环境Jenkins部署指南.md)：测试环境持续部署授权、Job 参数、健康检查与失败处理。
-- [阿里云生产环境选型、压测与上线手册](阿里云生产环境选型压测与上线手册.md)：ECS/ALB、RDS MySQL、Redis、OSS、Nacos、RocketMQ、压测、高可用、监控、备份与上线清单。
-- [阿里云 OSS 文件中心接入设计与评审](阿里云OSS文件中心接入设计与评审.md)：Admin、Client、国内/海外 PDA 文件接入 OSS 的区域拓扑、存储适配、权限、一致性、实施拆分、验收门禁和方案评审。
-- [首页数据看板真实化与统计策略规划](首页数据看板真实化与统计策略规划.md)：首页指标、实时与缓存边界、统计口径和实施顺序。
-- [墨家设备测量上传接口说明 V3](墨家设备测量上传接口说明-V3.md)：测量设备经 Gateway 上传箱码、尺寸、重量和图片的接口契约。
 
-## 环境协作
+| 主题 | 当前入口 |
+|---|---|
+| 服务拓扑、环境配置、部署状态与验收项 | [部署主契约](测试环境单机部署与配置契约.md) |
+| Gateway、Auth 会话、服务身份与可靠投递 | [认证与通信主契约](统一认证与服务通信契约.md) |
+| 平台/客户、菜单与操作权限 | [层级与权限契约](平台客户层级与权限契约.md) |
+| 单据编号、订单主状态与操作 | [编号契约](业务单据编号契约.md)、[订单状态契约](统一订单主状态与操作契约.md)，按问题选一项 |
+| 本机资源、最小验证、工作区与协作执行 | [工程执行约束](AI工程执行与协作约束.md) |
+| Admin 样式、Client 样式或视觉验收 | [Admin 样式](Admin高密度界面规范.md)、[Client 样式](Client界面样式规范.md)、[前端验收](Admin-Client前端原型还原验收规则.md)，不将三份作为共同必读 |
+| 测试 Jenkins、数据库操作与中文注释 | [测试部署指南](测试环境Jenkins部署指南.md)、[数据库操作手册](../baiyue-firstleg/deploy/sql/数据库迁移操作手册.md)、[数据库注释规范](数据库注释维护规范.md)，按操作选读 |
+| 测量设备上传 | [墨家接口说明](墨家设备测量上传接口说明-V3.md) |
 
-- [开发环境独立任务协作登记](开发环境独立任务协作登记.md)：开发环境全流程总控与长期专项的稳定任务、职责及开发数据库/部署/HTTP 授权。
+## 方案、证据与历史（按需）
-- [测试环境独立任务协作登记](独立任务协作登记.md)：登记已清空，任务由用户手动管理。
-- [测试任务盘点与需求台账](测试任务盘点与需求台账.md)：历史任务快照、未闭环需求、提交线索和待核实证据，不作为当前调度依据。
 
-## 参考资料
+- 独立主题设计只在该任务触发：[数据库发布方案](数据库版本迁移与Jenkins自动发布方案.md)、[生产发布方案](生产服务监控告警与无停机发布方案.md)、[生产环境方案](阿里云生产环境选型压测与上线手册.md)、[OSS 设计](阿里云OSS文件中心接入设计与评审.md)、[看板规划](首页数据看板真实化与统计策略规划.md)。方案不证明已实现或已部署。
+- 原型与截图按应用指引定向查找；样板、样式核对记录、进度表和验收报告不作为日常开发入口。
+- [历史流程](归档/头程到尾程/README.md)、[货柜历史](国内货柜履约/归档/README.md)、[财务历史](财务管理/归档/财务闭环盘点历史记录.md)仅用于追溯；旧双区域架构不覆盖当前主契约。
+- 只有独立任务协作才查[开发环境独立任务协作登记](开发环境独立任务协作登记.md)或[测试环境独立任务协作登记](独立任务协作登记.md)，不同时读取两表。
 
-- `悦/`：产品原型、流程图、历史架构资料和调研数据，只作为需求参考，不直接定义当前范围。
+## 维护边界
-- `superpowers/`：按日期和主题保留的具体功能设计与实施记录。
 
-## 维护规则
+同一主题优先更新现行正文，不为每轮对话新增方案、总结、进度或交接文件。只有独立主题且现有正文无法承载时才新增，并在所属域登记角色、触发条件和替代关系。已完成的过程材料冻结归档；索引只同步路径或职责变化，不复制阶段数量、字段、状态、测试结果或完成进度。事实优先级及修改范围遵循工作区根指引。
-
-- 新文档按业务域归档，不新增以开发批次编号命名的目录、文件、标题、任务或范围标签。
-- 当前交付范围始终按端到端全流程理解；业务域目录只用于检索和职责归属，不用于排除上下游流程。
-- 范围、字段或流程冲突时，按“当前对话确认 > 正式契约与确认记录 > 项目指引与代码 > 原型 > 历史记录”判断。
-- 新增或修改业务能力时，同步更新业务域 README、跨端契约、接口、权限、SQL、测试和验收入口。
-- 原型中出现的功能不自动成为有效实现；必须由正式契约、代码和验收证据共同确认。

业务单据编号契约.md

@@ -0,0 +1,48 @@
+# 业务单据编号契约
+
+## 格式与分配
+
+纳入本契约的新建业务单据采用 `前缀 + yyyyMMdd + 四位流水`，无分隔符。前缀为 2～4 位大写英文字母，总长度为 14～16 位，例如 `FL202610200001`。
+
+- 业务日期统一按 `Asia/Shanghai` 计算；每个前缀每天独立分配 `0001` 至 `9999`。
+- 同一前缀不按客户或仓库分段；服务内所有创建入口共用同一个序列。前缀按下表归属，禁止在不同服务重复分配同一前缀。
+- 单号由服务端生成并保持不变。编辑、审核、作废、重复提交不换号；幂等重放返回原业务记录及原号，不重新取号。
+- 序列在所属服务数据库内以原子更新和独立短事务分配；外层业务回滚允许断号，已分配号不回收。不以最大业务编号加一、时间戳、随机串、实体 ID 或其截断值生成。
+- 单日四位流水用尽时明确失败，不改为五位、不循环或随机回退。日期在取号前确定，不能在格式化时重新读取日期。
+- 本契约不授权对已有测试数据改号、回填、重置或执行 SQL；数据库与部署操作须独立授权。
+
+## 前缀登记
+
+| 服务 | 前缀与单据 |
+|---|---|
+| Order | `FL` 头程主订单 |
+| Warehouse | `ZGRK` 国内整柜入库、`ZGCK` 国内整柜出库 |
+| Firstleg | `OB` 订舱、`TA` 国内拖车派车、`LP` 预装/正式装柜计划、`DECL` 报关申报批次、`BR` 报关行批次、`PS` 船节点船期、`SL` 船期日历航次、`ST` 船期周模板、`CLG` 同柜组 |
+| Lastleg 入出库 | `WC` 头程来源尾程订单、`IP` 入仓计划、`CK` 普通出库、`DFCK` 一件代发出库、`HBCK` 换标出库、`THCK` 退货出库、`PDA` 出库作业任务、`DL` 派送、`EX` 异常、`CD` 废弃 |
+| Lastleg 库内服务 | `TB` 换标、`ZY` 转运、`TH` 退货、`THHB` 退货换标、`RR` 退货收货、`RB` 收货批次、`HX` 合箱计划、`YY` 送仓预约 |
+| Lastleg 商业业务 | `TR` 本土卡车、`LB` 散板、`CG` 采购订单、`PR` 采购实收、`PJ` 采购交寄、`PF` 采购费用（含更正与退款费用）、`PN` 采购说明、`PX` 采购关闭、`PG` 采购更正记录 |
+| Lastleg 车队 | `PC` 海外排车（原规则已符合）、`CT` 车次、`FB` 车队预订、`FO` 运力发布、`VR` 车辆运维记录 |
+| Finance | `REC` 对账单、`AR` 应收结算、`AP` 应付结算、`RC` 充值申请、`AC` 账户流水、`VC` 车辆成本、`VP` 车辆付款、`PAY` 结算付款流水 |
+
+同柜组按入仓码查询的公开摘要返回 `groupNo`；结算详情的付款流水返回 `transactionNo`，均取已生成的业务号。应收结算引用的收款凭证不生成 PAY 号，其 `transactionNo` 为空，不以内部 ID 或银行参考号替代。
+
+同一类型的所有创建入口共用序列：例如普通卡车下单与车队商业池创建均使用 `TR`；正常车次与取货车次均使用 `CT`。预装和正式装柜清单继续使用同一个 `LP` 计划编号。
+
+海外出库作业任务统一使用 `PDA + yyyyMMdd + 四位流水`，例如 `PDA202610230001`；一件代发、退货、转运和换标出库共用该序列，不拼接内部实体 ID。PDA 出库列表及详情以出库单号为主标识，任务号标明“任务号”作为辅助信息；扫描出库单号或任务号均可定位当前任务。入仓任务编号不在此规则范围内。
+
+头程来源尾程订单采用 `WC + yyyyMMdd + 四位流水`，共14位，例如 `WC202610210001`，按来源柜 `sourceContainerBookingId` 复用：该来源柜首次创建尾程订单时在柜级行锁内取号，后续同柜的入仓单、不同客户或跨日交接事件复用原号；事件重放不重新取号。真实集装箱号 `containerNo` 不作为复用身份，不同来源柜即使使用相同集装箱号也不能共用尾程编号。
+
+## 明确保留的规则
+
+- 入仓码、拆分子订单号和子入仓码不变。子订单继续使用主订单号加拆分后缀；新主订单改号后子单自然继承主号，但不改拆分算法或重新分配独立流水。
+- 柜次号继续使用全局连续的 `D0001`，不按日期重置，超过四位自然增长。
+- 实物箱码、散货托盘码、退货/转运箱码及一件代发 `DP-yyMMdd-####` 托盘标签不纳入本次改号。
+- 换标、转运、退货来源尾程订单继续沿用对应业务单号，不增加第二套业务身份。
+- 自营采集任务号、主数据编码及未列入登记表的其他编号不在本次范围。
+- 外部提单号、真实集装箱号、运单号、FBA 货件号、银行流水号等保留外部原号。
+
+## 实现与验收
+
+通用格式由 `baiyue-firstleg/common-core/.../number/DailyDocumentNumber.java` 提供；各服务通过自己的 `DocumentSequenceRepository → DocumentSequenceMapper` 访问本库编号表。海外排车继续复用原 `DispatchNumberSequence`。
+
+验证覆盖北京时间跨日、前缀独立、并发唯一、外层回滚不复用、缓存绕过、9999 上限、业务重放及保留编号规则。数据库变更同步模块空库基线和 `deploy/sql/` 统一空库入口；本地测试不代表已执行数据库变更或已部署。

业务实现边界.md

@@ -0,0 +1,315 @@
+# 业务实现边界
+
+角色：按主题读取的跨端实现约束正文，承接原业务快速索引中的边界说明；不作为启动必读或部署进度来源。已知目标代码时直接工作，只有接口、状态、权限或业务归属不明确时才读取命中章节。
+
+用 `rg -n -F '主题词' docs/业务实现边界.md` 定位标题，只读该标题到下一个同级标题。路径从工作区根或文中注明的应用 `src/` 起算；专题正式契约优先，新增专题规则只在其主文档维护，本文件保留必要的实现引用。
+
+公共架构按主题选择[部署契约](测试环境单机部署与配置契约.md)或[认证与通信契约](统一认证与服务通信契约.md)，不因读取本文件而同时加载两份契约，也不在本文另建环境、会话或投递规则。
+
+## 登录认证
+
+范围依据：`docs/订单与客户/README.md`。
+
+Admin `modules/auth/`、`core/auth/`；Client `modules/auth/`；Backend `auth/`、`iam/`。统一 Token 不携带角色或权限集；各端读取 Auth 登录/刷新响应的顶层授权快照用于展示，Gateway 与业务服务通过统一会话及 Auth 权威校验执行授权，不再依赖 Lastleg 安全投影
+
+## 客户与企业
+
+范围依据：`docs/订单与客户/README.md`、`docs/订单与客户/订单与客户头程订单闭环设计.md`。
+
+Admin `modules/customers/`；Client `modules/tenant-management/`、`modules/account/`；Backend `iam/`、`auth/`、`file/`。公司联系电话/邮箱是企业资料，不作为成员登录标识且不要求跨企业唯一；成员登录手机号归账号链路，修改时同步 Auth 并撤销该账号会话。审核必填资质仅营业执照与统一社会信用代码；法人身份证选填，可在已有营业执照后单独补传或替换，营业执照仍须与统一社会信用代码整包提交；默认尺寸配置由 IAM 持久任务异步调用 `firstleg/`，未就绪不得审核通过
+
+## 供应商与国内整柜
+
+范围依据：`docs/国内货柜履约/国内货柜履约需求确认表.md`。
+
+Admin `modules/suppliers/`、`modules/domestic-containers/`；Backend `warehouse/`；OpenAPI `supplier-v1.yaml`、`domestic-container-v1.yaml`
+
+## 平台收货仓
+
+范围依据：`docs/订单与客户/订单与客户头程订单闭环设计.md`。
+
+Admin `modules/warehouses/`；Client `modules/first-leg/`；Backend `warehouse/`
+
+## 头程订单、批量审核预览与入仓码关系
+
+范围依据：`docs/订单与客户/README.md`、头程订单闭环设计。
+
+Admin `modules/first-leg-orders/`、`modules/unified-orders/`；Client `modules/first-leg/api/inboundCodeAssociations.ts`、`modules/first-leg/`；Backend `order/` 的 `InboundCodeAssociationService`、`UnifiedOrderQueryService`、`BatchOrderReviewPreviewService` 与 `firstleg/`。Order 为 `SUBMITTED` 时，即使 Firstleg 已存在准备中入库投影，统一列表仍固定显示 `PENDING_REVIEW` 并提供审核动作；批量审核弹框只调用 `/orders/first-leg/batch-review-preview` 一次获取按请求顺序返回的快照，不逐票查询详情，主要展示入仓码而非内部订单 ID
+
+## 客户头程订单批量导入
+
+范围依据：当前 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`。
+
+本机重型检查经 `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/`
+
+## 到仓测量、测量库位、箱规策略与头程计费
+
+范围依据：`docs/入库测量与计费/README.md`；规则查 `baiyue-firstleg/firstleg/AGENTS.md` 对应入口。
+
+Admin `modules/inbounds/measurement/InboundMeasurementDialog.vue`、`InboundMeasurementPanel.vue`，称重 `modules/inbounds/weight/components/WeightOcrPanel.vue`；Backend `firstleg/` 的 `InboundMeasurementService`、`MeasurementLocationOccupationService`、`FbaPricingService`。库位归 `warehouse/`，图片归 `file/`，OCR 归 `integration-service/`；只按实际调用增加服务指引
+
+## 客户专属报价、柜级阶梯运费与费用调整
+
+范围依据：当前 Firstleg 计价契约、`docs/入库测量与计费/README.md`。
+
+Admin `modules/fba-pricing/carrier-rates/`、`modules/inbounds/fee/`、`modules/unified-orders/components/InboundFeeDetailManager.vue`；Backend `firstleg/` 的 `PlatformPriceBookService`、`ActivePriceBookEstimator`、`FbaPricingService`、`ContainerTierAmountAllocator`、`InboundFeeDetailService` 与 `fba-pricing-v1.yaml`。公共报价使用 `customerId=0`，客户专属报价按客户独立版本化并优先于公共 ACTIVE 版本；柜级区域重量阶梯只聚合同柜同客户中费用快照同为 `REGION_WEIGHT_TIER` 的成员并守恒分摊，混柜的固定仓价等其他模型不参与阶梯且保持原费用，装柜成员变化只重算未锁定的区域阶梯费用。人工调整计费量限系统基准上下 10% 且必须带版本、原因和二次确认；`PRIVATE_LAST_MILE_DELIVERY` 只允许私人目的仓；一件代发在预装确认前完成计价，`WAIT_PALLETIZE` 试算不得回退托盘化状态
+
+## 箱唛、箱码与单箱测量
+
+范围依据：`docs/入库测量与计费/入库测量与计费需求优化版-v2-测量计费入库主流程.md`、`docs/墨家设备测量上传接口说明-V3.md`。
+
+Admin `modules/inbounds/measurement/`；Client `modules/first-leg/`；Backend 按 `firstleg/AGENTS.md` 的箱唛与测量入口
+
+## 称重确认、整票库位块与部分拣货资源结算
+
+范围依据：`baiyue-firstleg/firstleg/AGENTS.md` 的称重入口、`baiyue-firstleg/warehouse/AGENTS.md` 的 A0/资源结算规则。
+
+Admin `modules/inbounds/weight/components/WeightOcrPanel.vue`；Backend Firstleg `MeasurementLocationOccupationService`、`InboundMeasurementService`、`MeasurementSubmissionService` → Warehouse `LocationBlockService`。国内整票资源结算按 `reservationId` 定位；称重、槽位容量和部分拣货的详细门禁留在所属服务指引
+
+## 入库扣货、解除与凭证
+
+范围依据：入库测量与计费、国内货柜履约契约。
+
+Admin `modules/unified-orders/pages/UnifiedOrdersView.vue`、`modules/inbounds/core/api.ts`；Backend `firstleg/` 的 `InboundHoldService`、`InboundHoldGuard`、`InboundHoldEvidenceService`，文件归 `file/` 的 `INBOUND_HOLD_EVIDENCE`。扣货状态必须阻断后续物理履约写入；已发生拣货、装柜或出仓时禁止手工扣货/解除，命令携带版本与幂等键，只有进入不可变历史的凭证可下载
+
+## 财务管理与柜级公共费用分摊
+
+范围依据：`docs/财务管理/` 产品确认、五页验收契约、Firstleg-Finance 跨服务契约。
+
+Admin `modules/finance/`、`modules/loading-lists/components/ContainerFeesPanel.vue`；Client `modules/finance/views/FinanceBillsView.vue`，账单行按 `inboundCode` 复用头程入仓关系详情；Backend `finance/`、`firstleg/`，契约 `container-fees-v1.yaml`；导出与凭证归 `file/`。跨客户公共柜费按柜内真实客户与订单归属原子建组，金额合计等于柜费总额，审核、驳回、调整和作废整组处理，单行入口不得破坏组一致性
+
+## 客户资金账户、充值、授信与业务扣费
+
+范围依据：[客户资金账户规则](财务管理/财务对账结算P1闭环.md#客户资金账户)；资金指令投递查[统一通信契约](统一认证与服务通信契约.md#b-逐事件直接投递与结果确认)。
+
+Admin `modules/finance/pages/FinanceCustomerAccountsView.vue`；Client `modules/finance/views/FinanceAccountView.vue`；Backend `finance/` 的 `FinanceWalletService` 与三类 Wallet Controller。充值申请经 File 保存凭证，平台审核或手工充扣；余额、授信、冻结、结算和释放以 Finance 主账为准。海外业务经 `WALLET_COMMAND_REQUESTED/COMPLETED` Outbox 直接投递往返，不跨区同步调用钱包
+
+## 订单编排、分柜、同柜不可拆组与柜次
+
+范围依据：`docs/国内货柜履约/README.md`、`docs/国内货柜履约/国内货柜履约需求确认表.md`、`docs/统一订单主状态与操作契约.md`。
+
+Admin `modules/unified-orders/api/coLoadGroups.ts`、`modules/unified-orders/`、`container-loading/`；Client `modules/first-leg/`；Backend `firstleg/loading/coload/`、`firstleg/split/`、`firstleg/loading/`、`order/`；同柜组按订单创建，由服务端冻结每票全部可用入仓片段，仅要求同国内仓、同渠道，允许跨客户及不同目的仓港
+
+## 全局智能排柜、预装与真实集装箱号后补
+
+范围依据：`docs/国内货柜履约/README.md`、`docs/国内货柜履约/国内货柜履约需求确认表.md`、`docs/统一订单主状态与操作契约.md`。
+
+Admin `modules/container-loading/components/SmartLoadingDialog.vue` 内嵌 `pages/GlobalSmartLoadingView.vue`，柜次页 `SmartLoadingWorkbenchView.vue`，预装详情 `loading-lists/pages/PreloadPlanDetailView.vue`；PDA `pages/picking/`；Backend `firstleg/` 的 `PlatformSmartLoadingController`、`SmartLoadingService`、`PendingReviewOrderClient`、`loading/`，待审核事实来自 Order `PendingReviewOrderQueryService`。全局候选覆盖 `PENDING_REVIEW/WAIT_MEASURE/WAIT_SPLIT/LOADING`，状态只用于筛选展示，能否加入以服务端 `canAssign` 为准；待审核/待测量可提前占位，但确认预装或启动 PDA 前必须进入 `WAIT_SPLIT`。暂估明细的 `totalPackageCount/remainingPackageCount` 在测量前取 Order 原始申报箱数，测量完成后取最新已审核测量箱数，读取补充失败只回退当前已分配数，写入调整仍重新校验权威数量。同柜不可拆组仅在全员命中状态集合时作为一个分页与分配单元；人工加入允许跨渠道，智能推荐仍按柜次渠道。计划可一次性移除全部未拣明细，但任一成员已拣的同柜组必须整组保留。创建柜次时原子生成唯一预装计划，加入入仓码即建立关联；真实集装箱号不阻塞订舱关联，但确认预装和创建 PDA 任务前必须补齐。历史缺号任务允许在预装详情首次补录，保存后恢复 PDA 可进入状态
+
+## 客户入库结果与头程费用确认
+
+范围依据：入库测量与计费主流程、当前 Firstleg 契约。
+
+Client `modules/first-leg/components/InboundBillingPanel.vue`、`api/inboundBilling.ts`；Backend `firstleg/` 的 `MerchantInboundBillingController`、`MerchantInboundBillingService`、`FbaPricingService` 与 `firstleg-v1.yaml`。客户仅能确认本客户 `SENT` 的最新费用版本，提交 `expectedFeeVersion` 与幂等键；确认记录当前成员和时间并永久锁定该版本，平台不得再修改
+
+## 订舱资料、放舱、出仓前船期与订舱级拖车
+
+范围依据：国内货柜履约 README、需求确认和实施边界。
+
+Admin `modules/ocean-bookings/`、`port-schedules/`、`trucking/`；Backend `firstleg/oceanbooking/`、`firstleg/portschedule/`、`TruckAppointmentService`。拖车预约由 `RELEASED` 订舱拥有，不按客户、柜次、装柜计划或真实柜号归属；每个订舱最多一张非终态拖车单，创建候选由服务端排除缺提单/有效订舱文件或已有有效拖车单的订舱；PDA 装柜完成不推进拖车状态；全部要求货柜确认国内离仓后自动完成，人民币拖车费按实装体积分摊为柜次应付并经 Finance Outbox 入池
+
+## 目的港码头拖车与还空预警
+
+范围依据：`docs/海外仓业务/README.md`。
+
+与订舱级拖车预约是不同生命周期。Admin 海外清关提柜列表/详情 `modules/container-loading/pages/OverseasContainersView.vue`、`modules/container-loading/pages/OverseasContainerDetailView.vue`；Firstleg 拖车 API `api/terminalDrayages.ts`，柜级到仓 API `api/containerArrivalTimes.ts`。原预约/实际提柜列改为预计/实际到仓：预计时间由平台在列表快捷选择并同步 Lastleg 整柜尾程订单，实际时间取海外 PDA 首次开始收货；车队、邮件、还柜与 `unloadingCompletedAt + 72h` 预警仍归 `firstleg/terminaldrayage/`。
+
+## 整柜报关资料与完成文件
+
+范围依据：国内货柜履约契约。
+
+装柜完成后由 Admin `modules/container-loading/components/ContainerCustomsPanel.vue` 管理整柜报关，Client `modules/first-leg/components/CustomsDocumentsDialog.vue`、`api/customs.ts` 按订单处理本客户退税资料；Backend `firstleg/customs/container/`、`customs-v1.yaml`，文件归 `file/`。客户资料可覆盖同柜多个退税入仓码，开始报关后冻结；平台逐资料回传完成文件，全买单柜走平台确认与明细导出
+
+## 国内出仓确认
+
+范围依据：国内货柜履约契约。
+
+Admin `modules/outbound-dispatch/`；Backend `firstleg/outbound/dispatch/`
+
+## 客户统计与平台日志
+
+范围依据：[客户统计指引](../apps/admin-web/src/modules/customers/AGENTS.md)、[操作审计指引](../apps/admin-web/src/modules/audit/AGENTS.md)，按对象选一项。
+
+Admin `modules/customers/`、`modules/audit/`；Backend `firstleg/customerstatistics/`、`audit-service/`
+
+## 客户工作台账户与设置
+
+范围依据：订单与客户契约。
+
+Client `modules/account/`、`system/`、`tenant-management/`；Backend `iam/`、`auth/`
+
+## 企业订单与跨境业务
+
+范围依据：订单与客户、国内货柜履约契约。
+
+Client `modules/order-management/`、`cross-border/`；Backend `order/`、`firstleg/`、`integration-service/`
+
+## 海外接柜、入库与库内库存
+
+范围依据：`docs/海外仓业务/README.md`。
+
+Admin 按 `apps/admin-web/AGENTS.md` 海外模块入口；海外入口 `gateway/`；尾程/入仓/换标/库存 `lastleg-service/`；仓库主档归国内 `warehouse/`，库位/托盘/锁归 `warehouse-overseas-service/` 并只引用国内 warehouseId；与排车、出库、派送共同组成海外仓全流程
+
+## 尾程订单控制与柜级入仓计划转换
+
+范围依据：`docs/海外仓业务/README.md`。
+
+Admin `modules/overseas-warehouse/pages/LastMileOrdersView.vue`、`LastMileOrderDetailView.vue`、`api/lastMileOrders.ts`；Backend `lastleg-service/` 的 `LastlegOrderController`、`LastlegOrderCommandService`、`InboundPlanService`、`ContainerInboundPlanConversionCoordinator`，资源归 `warehouse-overseas-service/` 的 `WarehousePalletBatchService`。`orders/container-summaries` 按 `sourceContainerBookingId` 跨客户聚合并分页返回全部稳定来源柜，已完成计划转换的柜仍保留用于接柜仓查询与修改；生成动作只消费 `allPlansReady/pendingPlanCount/resourcePendingPlanCount`，详情不受列表分页截断。确认前从 `/inbound-plans/container-preview` 读取服务端分组、托数、阻断项与 `snapshotVersion/snapshotHash`；`convert-container` 锁柜重算后先批量预留真实托盘，再本地原子生成剩余独立计划并确认资源，失败仅补偿未确认资源，同柜重放不得产生第二批资源。单票手工计划保存后，全柜计划齐全且预览就绪时自动生成并绑定托盘资源，一票柜立即触发；`resourcePendingPlanCount` 表示自动生成异常后的重试入口，资源未齐不得进入 PDA 接柜。自动入口见 Lastleg `ContainerInboundPlanConversionCoordinator.convertManualAndAutoMaterialize`。单票可维护完整入库计划、暂扣/解除及八行人工节点快照；命令提交订单版本与幂等键，新增暂扣只允许完成入库后执行并仅阻断该票后续排车/出库，不阻断入库计划或入库作业；人工节点首次保存后固定 `MANUAL` 来源且不得回退柜级节点
+
+### Admin 入仓计划页面约束
+
+代码路径相对 `apps/admin-web/src/modules/overseas-warehouse/`，含 `../` 的路径按模块关系解析。
+
+柜子工作台按 `sourceContainerBookingId` 消费 `/orders/container-summaries`；服务端分页返回全部稳定来源柜，计划已经齐全的柜仍保留用于接柜仓查询和修改，并按冻结 `plannedArrivalAt` 升序、空值最后排序。详情返回全柜订单且不受列表分页截断；单票手工计划保存后，由服务端在整柜最后一票计划齐全时自动生成并绑定全柜托盘码，一票柜立即生成；`resourcePendingPlanCount` 只表示自动生成异常的重试入口，不是正常人工步骤。柜级确认弹框先调用 `/inbound-plans/container-preview`，按服务端 FBA/一件代发/私人地址分组展示头程已有、海外仓补充和最终托数以及 `readiness/blockers`；散货最终托数不得少于头程已有托盘码，差额连续补码且不阻断流程；一件代发必须严格按不可变头程封托托盘数整体入库，单票表单托数锁定且服务端再次失败关闭校验。前端不计算托数、不逐票建计划、不预占托盘，再把同一 `snapshotVersion/snapshotHash` 原样提交 `/inbound-plans/convert-container`，快照冲突后重新获取预览。服务端只为剩余订单逐票生成独立计划，并为异常遗留的人工计划补齐真实托盘，整批原子且重放不得产生第二批资源。单票完整入库计划、暂扣/解除和八行人工节点均从 `api/lastMileOrders.ts` 提交订单版本与幂等键；入库弹框每次打开通过 `/orders/container-arrival-times/query` 读取柜级权威到仓结果，不使用订单列表旧快照作为显示或提交门禁；优先展示人工时间，未维护且未建计划时展示服务端按到港当地日期加两个自然日返回的 `plannedDate/isDefault`，默认日期不补零点，首个计划生成后沿用冻结日期。加载中、读取失败、缺失或同柜不一致时阻止提交；预计到仓时间不进入人工计划请求，服务端按整柜校验并写入同一日期；入仓码只读展示并提交订单冻结值，不允许人工改写。新增暂扣只在 `INBOUND_COMPLETED` 开放，解除暂扣保持可用；暂扣不阻断入库计划，只限制后续排车和出库。人工节点一经保存不得回退柜级节点。转仓候选只取 `../iam/api/platformIam.ts` 的平台公共 `ACTIVE + FBA` 仓主档；Backend `lastleg-service/`
+
+## 海外仓 PDA
+
+范围依据：`apps/pda-overseas-uniapp/AGENTS.md`；执行规则查 `baiyue-firstleg/lastleg-service/AGENTS.md`，跨模块流程才查海外仓 README。
+
+入仓 `src/pages/operation/`、`src/api/inbound.js`；排车与出库 `src/pages/dispatch/`、`src/pages/outbound/`、`src/api/fulfillment.js`。Backend `lastleg-service/inboundplan/pda/`、`dispatch/pda/`、`delivery/`；统一经 `gateway/`。柜级收货与单票客户隔离按 Lastleg“PDA 入仓”规则核对
+
+## 海外采购、本土卡车与散板
+
+范围依据：`docs/海外仓业务/README.md`。
+
+Admin `modules/overseas-business/`；Client `modules/cross-border/`；Backend `lastleg-service/` 的 `procurement/`、`trucking/`、`looseboard/`；统一经 `gateway/`
+
+## 采购样品、货款、装箱清单、面单、预估快递费、国内收货寄客户
+
+范围依据：`docs/海外仓业务/采购订单样品履约流程变更需求.md`。
+
+采购流程变更入口；代码从上述采购模块进入
+
+## 海外仓库与通用资料
+
+范围依据：主档查 [Warehouse 指引](../baiyue-firstleg/warehouse/AGENTS.md)，海外库位、托盘与锁查 [Warehouse Overseas 指引](../baiyue-firstleg/warehouse-overseas-service/AGENTS.md)。
+
+全部仓库主档进入 Admin `modules/warehouses/` 与国内 `warehouse/`；海外库位/托盘/锁进入 `warehouse-overseas-service/` 并引用国内 warehouseId；报价、汇率、车辆按海外服务实际契约
+
+## 车辆管理、司机证照、保养加油、车辆维修/故障/救援/异常、外接货与车次
+
+范围依据：`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)；既有缺陷修复查[排车流程修复规划](海外仓业务/排车流程修复规划.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/`
+
+以下 Admin 条款来自模块指引，按具体页面选读；排车状态、照片门禁及自动发车时机以本节排车现行契约为准。代码路径相对 `apps/admin-web/src/modules/overseas-warehouse/`，含 `../` 的路径按模块关系解析。
+
+### Admin 出库与派送页面约束
+
+`api/outbounds.ts`、`api/deliveryOrders.ts`；出库详情使用 `deliveries` 展示按目的 FBA 仓拆出的全部派送单，派送列表和详情必须显示目的 FBA 仓。人工状态入口不提供完成派送；签收资料保存成功后提示自动完成并刷新列表。出库列表按类型筛选并展示中文类型，状态须覆盖 `WAIT_PICK/待拣货`、`PICKING/拣货中`、`PICKED/已拣货`、`WAIT_OUTBOUND/待出库`、`OUTBOUNDED/已出库` 和 `CANCELLED/已取消`；仅未开始的 `WAIT_PICK/WAIT_OUTBOUND` 允许取消。一件代发新建弹窗直接跨客户加载服务端可用候选，不单独展示客户筛选，海外仓必选并优先默认洛杉矶仓；订单条件可按订单号、入库单号、客户、托盘号、SKU 或品名查询/重置，以托盘+SKU 行分页多选。提交时从所选行解析唯一客户，并校验所选行属于当前唯一海外仓，不要求先选客户。退货出库客户下拉同时展示客户名称与联系电话并支持手机号检索，客户和仓库选项独立容错加载；选择客户后须立即按当前默认/已选海外仓加载库存。SKU 与箱号查询均使用输入态/已查询态分离，只允许点击查询按钮后生效；支持英文逗号批量条件，查询时清除空格并按任一条件命中，左右列表分别提供每页 5/10/20/50 条选择。SKU 列表只展示 `availableQuantity > 0` 的未占用可用数量，合箱后已扣减为零的 SKU 不再作为可选库存显示，实际作业以可用箱唛选择和箱内 SKU 明细扣减为准。取消、派送列表/详情及退回入口对应 Backend `lastleg-service/delivery/`、`dropship/`
+
+### Admin 排车审核附件
+
+- 排车调度／理货审核分区仅显示审核、详情；审核弹框的车辆图片、司机照片和驾驶证照片通过既有本车附件接口上传，随 `ReviewCommand.attachments` 保存，不调用资源编辑命令。已有资源与审核附件只读预览，详情合并展示；当前审核权限与服务端 Gate 控制上传及提交，列表查看权限控制读取。
+
+### Admin 一件代发出库候选
+
+- 一件代发出库候选选择：`pages/OutboundsView.vue` 按 `inventoryPositionId + skuCode` 保留跨页选择，只提供本页全选；查询/重置回到第一页，切换海外仓清空选择。提交仍校验同客户、同海外仓，数量取所选行的 `availablePackages`（箱数），不能按 SKU 件数替代；候选同时展示当前可出箱数对应的毛重、材积重和体积，创建出库单时服务端按本次出库箱数占实际入库箱数的比例冻结三项测量快照。候选交互回归见 `pages/OutboundsView.selection.test.ts`；状态展示与取消门禁见 `pages/OutboundsView.test.ts`、`pages/OutboundDetailView.test.ts`。
+
+### Admin 货物计划与装车命令
+
+- 装车完成通过`completeDispatchLoading`一次提交，返回状态、照片可上传阶段与自动推进条件按本节排车现行契约消费；原请求恢复不重建单据。未知费用保持未确认，由既有后台费用管理维护，不按金额推断覆盖或重复记费。已有排车加货和移货仅从`SmartDispatchDialog.vue`内的`SmartDispatchExistingCargo.vue`进入；移货必须使用`GET items`返回的真实dispatchItemId及逐项remove Gate；路线仅重排`GET route`返回的既有全部目的地，包含外接点，不能新增或猜测目的地。附件沿`DispatchEvidenceFiles.vue`的本车鉴权上传/读取，上传与主单引用保存分开。
+
+- 排车列表车辆信息编辑、BOL PDF 和装车完成从 `pages/DispatchesView.vue` → `api/dispatches.ts` 进入；列表和详情不另设添加／移除货物入口。货物计划统一由 `components/SmartDispatchDialog.vue` 承载：新建使用候选、草稿及托盘锁，已有排车经 `components/SmartDispatchExistingCargo.vue` 读取实际明细并按版本增减；两类服务端命令不得混用。原加货／移货未知请求也在智能排车恢复。回归为对应组件测试、`pages/DispatchesView.test.ts`、`pages/DispatchDetailView.test.ts` 及 `pages/prototypeContract.test.ts`。
+
+### Admin 取消与费用展示
+
+- 出库取消提示先解除车次关联，取消后仍须在排车列表释放原排车占用；不提示库存已自动回滚。派送详情费用读取reviewStatus/sourceStatus/voidStatus，同一详情响应展示待财务确认、待财务处理、确认作废，不逐行查询，也不把取消成功视为费用作废。货柜费用面板直接消费同一费用来源接口，待确认时同样禁止调整和重复作废，沿用原页面/弹框承载。
+
+### Admin 业务导出
+
+- 尾程订单、库存余额与进销存记录导出统一使用 `../downloads/` 的 `useExportTask` 创建 XLSX 任务；保留当前筛选和业务导出权限，并要求 `platform:download:list`。Lastleg 内部 Provider 契约为 `lastleg-exports-v1.yaml`，业务页面不再请求同步 CSV。
+
+### Admin 装车照片与资料入口
+
+- 装车照片与资料从 `components/DispatchDocumentsDialog.vue` → `DispatchLoadingDocuments.vue` → `api/dispatchLoadingDocuments.ts` 进入；五框按整车保存，不依赖派送权限或派送单。原上传/绑定结果未知保留原文件、版本及键；明确版本冲突后刷新再用原文件保存。两端共享及自动推进规则唯一见排车正式契约。
+
+## 海外业务费用来源与客户财务
+
+范围依据：当前实现查财务契约与统一认证与服务通信契约；阶段 0A—0E 开发再读 `docs/财务管理/海外仓费用统一接入阶段0技术契约.md`。
+
+当前 V1 由 `lastleg-service/financefee/` 校验海外入仓、采购、美国卡车、本土散板和海外仓服务费，通过完整快照和 Outbox 直接投递 Finance 内部入口入池；阶段 0 目标改为收费身份/候选版本、Finance 接受或拒绝结果事件及版本化资金计划。必须沿代码确认落地范围，不把技术契约当成已实现状态；Client 仍只读取获准客户财务
+
+## 自营销量与领星统计
+
+范围依据：`docs/自营业务/README.md`。
+
+领星 WMS 自研系统（OMP）、经营总览图表、自营 SKU 日销量、热销与滞销排行、分仓产品库存与可售天数、库存周转、数据采集：先读 `apps/admin-web/src/modules/self-operated/AGENTS.md`；查询与采集编排查 `baiyue-firstleg/lastleg-service/AGENTS.md` 的自营入口，签名/限流/供应商分页问题才读 `baiyue-firstleg/integration-service/AGENTS.md`。区别于整箱库存和客户 WMS 作业库存。
+
+自营专题按任务选择：总览图形/下钻查 `docs/自营业务/经营总览图表设计.md`，库存周转查 `docs/自营业务/库存周转视图设计.md`，采集交互查 `docs/自营业务/数据采集页面设计.md`，查询性能查 `docs/自营业务/领星统计查询性能优化方案.md`，外部接口联调查 `docs/自营业务/领星WMS接口联调手册.md`。架构/表结构不明时从 `docs/自营业务/README.md` 定位一期方案，不默认同时读取所有专题。
+
+## 预约管理与工作日历
+
+范围依据：`docs/海外仓业务/预约工作日历V13变更说明.md`（业务规则）；`docs/海外仓业务/预约工作日历开发协作契约.md`（接口与文件边界），按本次问题选一项。
+
+美国各类预约统一总览、提柜/用车/送仓预约梳理：`docs/海外仓业务/美国预约管理统一总览与优化方案.md`（设计建议）；实际维护仍按下述来源模块进入。
+
+预约工作日历、多客户共车、中转分批后送、改期取消、重新预约和未定日期事项：先读 `docs/海外仓业务/预约工作日历V13变更说明.md`（正式业务规则与验收），再读 `docs/海外仓业务/预约工作日历开发协作契约.md`（接口与文件边界）；权威业务事实仍由下述来源模块维护。
+
+预约管理、预约列表、到港/排车/还柜/计划到仓四类日历：Admin `apps/admin-web/src/modules/appointment-calendar/`，当前入口与日期规则见 `docs/海外仓业务/预约工作日历V13变更说明.md` 的“2026-10-19 当前预约列表收敛规则”；原送仓业务仍从 `docs/海外仓业务/README.md` 的“预约送仓”进入。排车只取海外仓送往 FBA/客户仓的真实车次，区别于订舱级拖车和港口提柜。
+
+## 退货预报、签收、库存与合箱
+
+范围依据：`baiyue-firstleg/lastleg-service/docs/business-index.md` 的退货入口。
+
+退货预报、签收、库存与合箱：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/`。
+
+## 散货托盘码生成、打印与跨区传递
+
+范围依据：`docs/打印标签维护/README.md`；各应用/服务最近指引。
+
+散货托盘码生成、打印与跨区传递：Admin `modules/loading-lists/components/PalletLabelPrintDialog.vue`；Firstleg `LoadingPalletLabelService`、`LoadingCompletedOutboxService`；Lastleg `LastlegSourcePalletMapper`、`InboundPlanService`。从各项目最近指引继续定位；散货 FBA 标签与一件代发实装托盘分别取各自冻结事实。

业务快速索引.md

@@ -1,12 +1,12 @@
 # 业务快速索引
 
-本文件按需检索，不作为启动必读文档。以下路径均按工作区根目录或表内注明的应用源码根目录起算，不相对于 docs/。
+本文件只负责消除歧义与定位，不是启动必读清单。已知文件、组件或 API 时跳过本文件；先按终端选应用，再用 `rg -n -F '组合词' docs/业务快速索引.md` 读取命中行。
+
+代码问题直接进入列出的模块并读适用指引；只有业务边界不清时才读“边界正文”的命中章节，不串读各层 README、其他应用索引或整个正文文件。表内代码入口相对工作区根，前端仍按任务终端分流；服务端入口不要求纯展示任务先读后端。
 
 ## 常用说法与歧义分流
 
-仓储转运审核、转运驳回：Admin 尾程订单 `apps/admin-web/src/modules/overseas-warehouse/pages/LastMileOrdersView.vue` → `apps/admin-web/src/modules/overseas-warehouse/components/WarehouseTransferReviewDialog.vue`；权限、状态及 API 见该模块 `AGENTS.md` 的“仓储转运审核、通过与驳回”。不要按“审核”误入头程订单审核，也不要按“转运”误入排车转派送。
+取“终端＋对象＋动作”组合词；只读命中行。不同解释会改变范围且仍无法判断时再询问。
-
-先从任务中取“终端 + 业务对象 + 动作”，如“海外 PDA + 柜号 + 收货”。下面是检索提示，不替代业务契约；代码路径均从工作区根起算。用短词检索，不拿整句自然语言做精确匹配。
 
 | 常用说法 | 区分依据 | 首个定位范围 |
 |---|---|---|
@@ -19,72 +19,91 @@
 | 接柜、卸柜、收货、签收 | 海外 PDA 柜号认领、照片、实收 | `apps/pda-overseas-uniapp/src/pages/operation/operation.vue`；后端查 `ReceivingContainerService` |
 | 入仓计划、生成计划、按柜生成 | 平台尾程订单预览与确认，不是现场实收 | `apps/admin-web/src/modules/overseas-warehouse/pages/LastMileOrdersView.vue`；后端查 `ContainerInboundPlanConversionCoordinator` |
 | 审核、审单、批量审核 | 客户头程订单待审核 | `apps/admin-web/src/modules/unified-orders/`；后端查 `BatchOrderReviewPreviewService` |
+| 订单审核、头程订单审核、批量审单 | 平台审核客户头程订单，状态以 Order `SUBMITTED` 和服务端 `canApprove/blockReason` 为准；不要按仓储转运审核定位 | Admin `apps/admin-web/src/modules/unified-orders/`；Client 只读订单状态查 `apps/client-web/src/modules/first-leg/`；Backend `baiyue-firstleg/order/` 的 `BatchOrderReviewPreviewService`、`PlatformFirstLegOrderController` |
 | 审核、测量审核、实测审核 | 仓库测量结果审核 | `baiyue-firstleg/firstleg/AGENTS.md` 中“审核与初始计价”；页面先查 Admin 入库模块 |
 | 费用、运费、报价、计费、船期价格表、价格簿 | 单票入仓计价、客户专属报价或调价 | `apps/admin-web/src/modules/inbounds/fee/`、`apps/admin-web/src/modules/fba-pricing/carrier-rates/pages/CarrierRatesView.vue`（列表/上传）、`apps/admin-web/src/modules/fba-pricing/carrier-rates/pages/CarrierRateDetailView.vue`（版本详情/映射确认）；后端查 `FbaPricingService` |
 | 柜费、公共费用、分摊 | 国内柜费来源归 Firstleg；海外柜费来源归 Lastleg；账单与结算结果归 Finance | 业务路由查“财务管理与柜级公共费用分摊”或“海外业务费用来源与客户财务”，按实际请求区分 |
-| 充值、余额、授信、账单、核销 | 客户自助与平台管理先按终端区分 | Client `apps/client-web/src/modules/finance/`；Admin `apps/admin-web/src/modules/finance/` |
+| 钱包、充值、余额、授信、账单、核销 | 客户自助与平台管理先按终端区分 | Client `apps/client-web/src/modules/finance/`；Admin `apps/admin-web/src/modules/finance/` |
+| 客户账单、客户对账单、账单确认 | 客户查看和确认本企业账单，不是平台柜费分摊或充值审核 | Client `apps/client-web/src/modules/finance/views/FinanceBillsView.vue`；Admin 平台账单查 `apps/admin-web/src/modules/finance/`；Backend `baiyue-firstleg/finance/` 的 Client Finance Controller |
 | 自动生成托盘、托盘码没生成、计划齐全、重试生成托盘码 | 海外入库计划保存后资源生成，不是国内托盘标签打印 | Admin `apps/admin-web/src/modules/overseas-warehouse/pages/LastMileOrdersView.vue`；Backend `baiyue-firstleg/lastleg-service/docs/business-index.md` 的“人工计划自动生成托盘与资源重试”，执行规则先读该服务 `AGENTS.md` |
 | 托盘码、托盘标签、补打 | 先区分散货装柜、一件代发和海外实体托盘 | 散货 `apps/admin-web/src/modules/loading-lists/components/PalletLabelPrintDialog.vue`；一件代发 `apps/admin-web/src/modules/inbounds/core/DropshipPalletPrintPanel.vue`，从订单“托盘打印”页签进入；海外单张打印 `apps/admin-web/src/modules/overseas-warehouse/pages/PalletsView.vue`，详见各应用/模块指引 |
 | 箱码、箱唛、箱标、单箱扫码 | 单箱身份与测量，不是托盘或库位 | 业务路由查“箱唛、箱码与单箱测量”；后端查 `InboundCartonLabelService` |
-| 库位、托盘、占位、释放 | 国内称重整票块归 Warehouse；海外实物托盘资源归 Warehouse Overseas；业务任务归 Lastleg | 业务路由查“称重确认”或“海外仓库与通用资料”；用国内/海外和业务阶段继续限定 |
+| 库位、托盘、占位、释放 | 国内资源归 Warehouse；海外资源归 Warehouse Overseas；海外库存业务归 Lastleg | 业务路由查“称重确认”或“海外库位”；仓库名称/地址查“海外仓库主档” |
 | 拖车、派车、提柜、还柜 | 国内订舱拖车与目的港码头车队是不同业务；海外配送排车另属 Lastleg | 国内 `apps/admin-web/src/modules/trucking/`；目的港 `apps/admin-web/src/modules/container-loading/api/terminalDrayages.ts`；配送查“海外出库、排车” |
 | 报关资料、退税资料、完成文件 | 平台整柜操作与客户订单上传先按终端区分 | Admin `apps/admin-web/src/modules/container-loading/components/ContainerCustomsPanel.vue`；Client `apps/client-web/src/modules/first-leg/components/CustomsDocumentsDialog.vue` |
 | 退货、退货预报、退货换标、退货签收、退货合箱 | 客户退货预报及签收库存，区别于派送异常退回 | Client `apps/client-web/src/modules/overseas-warehouse/views/ReturnOrdersView.vue`；Admin `apps/admin-web/src/modules/overseas-warehouse/pages/ReturnInventoryManagementView.vue`；PDA `apps/pda-overseas-uniapp/AGENTS.md`；Lastleg `returnreceipt/`，见下文“退货预报、签收、库存与合箱” |
+| PDA 出库、PDA 发车、扫码出库、整托出库 | 海外 PDA 执行排车和出库，不是平台排车配置或客户派送查询 | 海外 PDA `apps/pda-overseas-uniapp/src/pages/dispatch/dispatch.vue`、`src/api/fulfillment.js`；Backend `baiyue-firstleg/lastleg-service/dispatch/pda/`；统一经 `gateway/` |
 | 异常、退回、退仓、回访 | 派送异常退回与库存退货业务不可混用 | 派送查 `apps/admin-web/src/modules/overseas-warehouse/pages/ExceptionOrdersView.vue`；退货预报/库存查 Lastleg `returnreceipt/` |
-
+| 仓储转运审核、转运通过 | 平台转运审核通过弹框 | `apps/admin-web/src/modules/overseas-warehouse/components/WarehouseTransferReviewDialog.vue` |
-## 定位步骤与反馈
+| 转运驳回、REJECT | API 审核结论；当前弹框无此动作 | `apps/admin-web/src/modules/overseas-warehouse/api/warehouseTransfers.ts` 的 `reviewWarehouseTransfer`；界面能力查最近指引 |
-
-- 已知文件、组件或请求路径：读取适用指引后直接进入该文件或限定服务搜索路由，无需经过词表。
-- 页面问题：终端指引 → 命中页面 → 实际 import/API → 对应 Controller/Service。纯展示问题定位到相关组件即可；遇到后端业务判断再追踪调用链。
-- 状态或权限问题：已知请求时先定位 Controller 的权限与 Service 的状态门禁，再核对前端消费；尚不知请求时从触发动作找到 API。不要先扫所有权限初始化 SQL。
-- 无精确命中：从用户原话提取短词查本表；仍有歧义时利用页面标题、业务编号类型和国内/海外范围缩小。每次只扩展相邻业务范围。
-- 实际任务若发生入口误导、路径失效或重复扩大搜索，在当次交付中简记“原说法 → 最终入口 → 绕路原因”，并修正命中的索引行；进度与临时结果不写回本文件。
-- 评价检索质量看首次入口是否正确、扩大范围次数、找到目标前额外读取的无关文件数；文件存在或离线合同通过只能证明部分有效性，不能代替真实任务耗时。普通任务不额外建立计时脚本或登记台账。
 
 ## 业务快速路由表
 
-退货预报、签收、库存与合箱：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/`。
+| 业务 | 首个代码入口 | 边界正文（仅需要规则时读） |
-
-本表只路由到范围依据和首个代码入口；Admin/Client 路径从对应应用的 `src/` 起算，国内 PDA 路径从 `apps/pda-uniapp/` 起算，海外 PDA 路径从 `apps/pda-overseas-uniapp/src/` 起算，Backend 路径从 `baiyue-firstleg/` 起算。进入目标后继续读最近的 `AGENTS.md`，不要把根表当作模块细节清单。
-
-| 业务 | 范围依据 | 首个代码入口 |
 |---|---|---|
-| 登录认证 | `docs/订单与客户/README.md` | Admin `modules/auth/`、`core/auth/`；Client `modules/auth/`；Backend `auth/`、`iam/`。海外 Token 不携带角色或权限集，Admin/Client/海外 PDA 从 Auth 登录与刷新响应的顶层授权快照读取，海外 Gateway 再按 IAM 安全投影校验 |
+| 登录认证 | [模块指引](../apps/admin-web/src/modules/auth/AGENTS.md) | [对应章节](业务实现边界.md#登录认证) |
-| 客户与企业 | `docs/订单与客户/README.md`、`docs/订单与客户/订单与客户头程订单闭环设计.md` | Admin `modules/customers/`；Client `modules/tenant-management/`、`modules/account/`；Backend `iam/`、`auth/`、`file/`。公司联系电话/邮箱是企业资料，不作为成员登录标识且不要求跨企业唯一；成员登录手机号归账号链路，修改时同步 Auth 并撤销该账号会话。审核必填资质仅营业执照与统一社会信用代码；法人身份证选填，可在已有营业执照后单独补传或替换，营业执照仍须与统一社会信用代码整包提交；默认尺寸配置由 IAM 持久任务异步调用 `firstleg/`，未就绪不得审核通过 |
+| 客户与企业 | [模块指引](../apps/admin-web/src/modules/customers/AGENTS.md) | [对应章节](业务实现边界.md#客户与企业) |
-| 供应商与国内整柜 | `docs/国内货柜履约/国内货柜履约需求确认表.md` | Admin `modules/suppliers/`、`modules/domestic-containers/`；Backend `warehouse/`；OpenAPI `supplier-v1.yaml`、`domestic-container-v1.yaml` |
+| 供应商与国内整柜 | [模块指引](../apps/admin-web/src/modules/suppliers/AGENTS.md) | [对应章节](业务实现边界.md#供应商与国内整柜) |
-| 平台收货仓 | `docs/订单与客户/订单与客户头程订单闭环设计.md` | Admin `modules/warehouses/`；Client `modules/first-leg/`；Backend `warehouse/` |
+| 平台收货仓 | [模块指引](../apps/admin-web/src/modules/warehouses/AGENTS.md) | [对应章节](业务实现边界.md#平台收货仓) |
-| 头程订单、批量审核预览与入仓码关系 | `docs/订单与客户/README.md`、头程订单闭环设计 | Admin `modules/first-leg-orders/`、`modules/unified-orders/`；Client `modules/first-leg/api/inboundCodeAssociations.ts`、`modules/first-leg/`；Backend `order/` 的 `InboundCodeAssociationService`、`UnifiedOrderQueryService`、`BatchOrderReviewPreviewService` 与 `firstleg/`。Order 为 `SUBMITTED` 时，即使 Firstleg 已存在准备中入库投影，统一列表仍固定显示 `PENDING_REVIEW` 并提供审核动作；批量审核弹框只调用 `/orders/first-leg/batch-review-preview` 一次获取按请求顺序返回的快照，不逐票查询详情，主要展示入仓码而非内部订单 ID |
+| 头程订单、批量审核预览与入仓码关系 | [模块指引](../apps/admin-web/src/modules/unified-orders/AGENTS.md) | [对应章节](业务实现边界.md#头程订单批量审核预览与入仓码关系) |
-| 客户头程订单批量导入 | 当前 Order 契约 | Client `modules/first-leg/views/FirstLegOrdersView.vue`、`api/firstLeg.ts`；Backend `order/` 的 `MerchantBatchImportService`、`MerchantWarehouseCatalogClient`、`MerchantPricingCatalogClient` 与 `order-v1.yaml`。中文 XLSX 模板按当前客户动态生成地址、全部有效仓库和渠道下拉；导入时重新校验动态选项与客户归属，最多 50 行，只创建草稿，支持部分成功或整批原子模式 |
+| 客户头程订单批量导入 | [模块指引](../apps/client-web/src/modules/first-leg/AGENTS.md) | [对应章节](业务实现边界.md#客户头程订单批量导入) |
-| 平台旧系统订单导入 | 当前 Order 契约 | Admin `modules/unified-orders/pages/UnifiedOrdersView.vue`、`api/unifiedOrders.ts`；Backend `order/` 的 `PlatformLegacyOrderImportService` 与 `/api/platform/v1/orders/first-leg/legacy-import`。固定归属启用客户“IT测试公司”，保留旧入仓码，按当前公共仓库和客户价格簿逐行校验，成功行进入待审核 |
+| 平台旧系统订单导入 | [模块指引](../apps/admin-web/src/modules/unified-orders/AGENTS.md) | [对应章节](业务实现边界.md#平台旧系统订单导入) |
-| 平台修改客户原始申报与履约渠道 | 当前 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 实测、测量审核、箱码或已确认费用；渠道变化额外校验分柜、同柜、装柜可逆性与重新计价，国内收货仓或中转仓变化必须重新下单 |
+| 平台修改客户原始申报与履约渠道 | [模块指引](../apps/admin-web/src/modules/unified-orders/AGENTS.md) | [对应章节](业务实现边界.md#平台修改客户原始申报与履约渠道) |
-| 脚本管理、全量验证与测试造数 | `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) | [对应章节](业务实现边界.md#脚本管理全量验证与测试造数) |
-| 平台/企业 RBAC | 订单与客户契约；公共语义见 `docs/平台客户层级与权限契约.md` | Admin `modules/iam/`、`core/access/`；Client `modules/tenant-management/`；Backend `iam/`、`auth/` |
+| 平台/企业 RBAC | [模块指引](../apps/admin-web/src/modules/iam/AGENTS.md) | [对应章节](业务实现边界.md#平台企业-rbac) |
-| 消息中心与站内通知 | 触发业务的阶段/专题契约，收件箱以 IAM OpenAPI 为准 | Admin/Client `modules/notifications/`；Backend `iam/.../notification/`；生产者留在所属服务 |
+| 消息中心与站内通知 | [模块指引](../apps/admin-web/src/modules/notifications/AGENTS.md) | [对应章节](业务实现边界.md#消息中心与站内通知) |
-| PDA 拣货与柜级装柜证据 | 国内 PDA README、拣货原型、国内货柜履约需求确认 | PDA `pages/picking/`、`stores/picking.js`、`api/pda-loading.js`；证据以 `taskId + warehouseId` 进入任务专用 API，业务所有权固定真实 `containerBookingId`，不得按入仓单或客户拆分；上传以幂等键绑定包含文件内容的请求哈希，完全重放直接返回已有结果且不得重复上传 File；Backend `firstleg/`、`warehouse/`、`file/` |
+| PDA 拣货与柜级装柜证据 | [模块指引](../apps/pda-uniapp/AGENTS.md) | [对应章节](业务实现边界.md#pda-拣货与柜级装柜证据) |
-| 到仓测量、测量库位、箱规策略与头程计费 | `docs/入库测量与计费/README.md`、测量计费入库主流程 | Admin 测量 `modules/inbounds/measurement/InboundMeasurementDialog.vue`、`InboundMeasurementPanel.vue`，称重 `modules/inbounds/weight/components/WeightOcrPanel.vue`，以及 `warehouse-resources/`、`fba-pricing/`、`dimension-config/`、`fee-items/`；Backend `firstleg/` 的 `InboundMeasurementService`、`MeasurementLocationOccupationService`、`MeasurementSubmissionService`、`CustomerDimensionConfigService`、`CustomerDimensionWeightingService`、`FbaPricingService`，并联查 `warehouse/`、`file/`、`integration-service/`。整票库位按确认图片数与有效体积容量需求的较大值尽力预留，扩容只追加且删除图片保留空槽；库位指引失败不阻断称重确认或测量提交。客户固定四档箱规可选择 `ADD/MULTIPLY`，计价和费用确认以服务端及当前实际测量明细为准 |
+| 到仓测量、测量库位、箱规策略与头程计费 | [模块指引](../apps/admin-web/src/modules/inbounds/AGENTS.md) | [对应章节](业务实现边界.md#到仓测量测量库位箱规策略与头程计费) |
-| 客户专属报价、柜级阶梯运费与费用调整 | 当前 Firstleg 计价契约、`docs/入库测量与计费/README.md` | Admin `modules/fba-pricing/carrier-rates/`、`modules/inbounds/fee/`、`modules/unified-orders/components/InboundFeeDetailManager.vue`；Backend `firstleg/` 的 `PlatformPriceBookService`、`ActivePriceBookEstimator`、`FbaPricingService`、`ContainerTierAmountAllocator`、`InboundFeeDetailService` 与 `fba-pricing-v1.yaml`。公共报价使用 `customerId=0`，客户专属报价按客户独立版本化并优先于公共 ACTIVE 版本；柜级区域重量阶梯只聚合同柜同客户中费用快照同为 `REGION_WEIGHT_TIER` 的成员并守恒分摊，混柜的固定仓价等其他模型不参与阶梯且保持原费用，装柜成员变化只重算未锁定的区域阶梯费用。人工调整计费量限系统基准上下 10% 且必须带版本、原因和二次确认；`PRIVATE_LAST_MILE_DELIVERY` 只允许私人目的仓；一件代发在预装确认前完成计价，`WAIT_PALLETIZE` 试算不得回退托盘化状态 |
+| 客户专属报价、柜级阶梯运费与费用调整 | [模块指引](../apps/admin-web/src/modules/fba-pricing/AGENTS.md) | [对应章节](业务实现边界.md#客户专属报价柜级阶梯运费与费用调整) |
-| 箱唛、箱码与单箱测量 | `docs/入库测量与计费/入库测量与计费需求优化版-v2-测量计费入库主流程.md`、`docs/墨家设备测量上传接口说明-V3.md` | Admin `modules/inbounds/measurement/`；Client `modules/first-leg/`；Backend 按 `firstleg/AGENTS.md` 的箱唛与测量入口 |
+| 箱唛、箱码与单箱测量 | [模块指引](../baiyue-firstleg/firstleg/AGENTS.md) | [对应章节](业务实现边界.md#箱唛箱码与单箱测量) |
-| 称重确认、整票库位块与部分拣货资源结算 | 入库测量与计费主流程、国内货柜履约 PDA 契约 | Admin `modules/inbounds/weight/components/WeightOcrPanel.vue`；Backend `firstleg/` 的 `MeasurementLocationOccupationService`、`InboundMeasurementService`、`MeasurementSubmissionService` 与 `warehouse/` 的 `LocationBlockService`。测量提交审核前至少上传并确认一张称重图片，单箱也不得免称重；称重确认尽力建立整票块，提交时再次补齐，库位指引失败不阻断称重确认或测量提交。容量按确认图片数与有效体积折算的较大值，最新测量批次内实测/冻结申报体积取有效较大值；删除图片只清空绑定不释放槽位。部分拣货有余量时整段转移给子单，整票拣完才一次性释放全部普通位与共享 A0，资源身份以 `reservationId` 为准 |
+| 称重确认、整票库位块与部分拣货资源结算 | [模块指引](../baiyue-firstleg/warehouse/AGENTS.md) | [对应章节](业务实现边界.md#称重确认整票库位块与部分拣货资源结算) |
-| 入库扣货、解除与凭证 | 入库测量与计费、国内货柜履约契约 | Admin `modules/unified-orders/pages/UnifiedOrdersView.vue`、`modules/inbounds/core/api.ts`；Backend `firstleg/` 的 `InboundHoldService`、`InboundHoldGuard`、`InboundHoldEvidenceService`，文件归 `file/` 的 `INBOUND_HOLD_EVIDENCE`。扣货状态必须阻断后续物理履约写入；已发生拣货、装柜或出仓时禁止手工扣货/解除，命令携带版本与幂等键，只有进入不可变历史的凭证可下载 |
+| 入库扣货、解除与凭证 | [模块指引](../apps/admin-web/src/modules/unified-orders/AGENTS.md) | [对应章节](业务实现边界.md#入库扣货解除与凭证) |
-| 财务管理与柜级公共费用分摊 | `docs/财务管理/` 产品确认、五页验收契约、Firstleg-Finance 跨服务契约 | Admin `modules/finance/`、`modules/loading-lists/components/ContainerFeesPanel.vue`；Client `modules/finance/views/FinanceBillsView.vue`，账单行按 `inboundCode` 复用头程入仓关系详情；Backend `finance/`、`firstleg/`，契约 `container-fees-v1.yaml`；导出与凭证归 `file/`。跨客户公共柜费按柜内真实客户与订单归属原子建组，金额合计等于柜费总额，审核、驳回、调整和作废整组处理，单行入口不得破坏组一致性 |
+| 财务管理与柜级公共费用分摊 | [模块指引](../apps/admin-web/src/modules/finance/AGENTS.md) | [对应章节](业务实现边界.md#财务管理与柜级公共费用分摊) |
-| 客户资金账户、充值、授信与业务扣费 | `docs/财务管理/README.md`、跨区域认证与服务通信契约 | Admin `modules/finance/pages/FinanceCustomerAccountsView.vue`；Client `modules/finance/views/FinanceAccountView.vue`；Backend `finance/` 的 `FinanceWalletService` 与三类 Wallet Controller。充值申请经 File 保存凭证，平台审核或手工充扣；余额、授信、冻结、结算和释放以 Finance 主账为准。海外业务经 `WALLET_COMMAND_REQUESTED/COMPLETED` Outbox/Event Bridge 往返，不跨区同步调用钱包 |
+| 平台资金账户、充值审核、手工充扣与授信 | [Admin 财务](../apps/admin-web/src/modules/finance/AGENTS.md) | [资金账户规则](财务管理/财务对账结算P1闭环.md#客户资金账户) |
-| 订单编排、分柜、同柜不可拆组与柜次 | `docs/国内货柜履约/README.md`、`docs/国内货柜履约/国内货柜履约需求确认表.md`、`docs/统一订单主状态与操作契约.md` | Admin `modules/unified-orders/api/coLoadGroups.ts`、`modules/unified-orders/`、`container-loading/`；Client `modules/first-leg/`；Backend `firstleg/loading/coload/`、`firstleg/split/`、`firstleg/loading/`、`order/`；同柜组按订单创建，由服务端冻结每票全部可用入仓片段，仅要求同国内仓、同渠道，允许跨客户及不同目的仓港 |
+| 客户资金账户、余额、授信与充值申请 | [Client 财务](../apps/client-web/src/modules/finance/AGENTS.md) | [资金账户规则](财务管理/财务对账结算P1闭环.md#客户资金账户) |
-| 全局智能排柜、预装与真实集装箱号后补 | 同上 | Admin `modules/container-loading/components/SmartLoadingDialog.vue` 内嵌 `pages/GlobalSmartLoadingView.vue`，柜次页 `SmartLoadingWorkbenchView.vue`，预装详情 `loading-lists/pages/PreloadPlanDetailView.vue`；PDA `pages/picking/`；Backend `firstleg/` 的 `PlatformSmartLoadingController`、`SmartLoadingService`、`PendingReviewOrderClient`、`loading/`，待审核事实来自 Order `PendingReviewOrderQueryService`。全局候选覆盖 `PENDING_REVIEW/WAIT_MEASURE/WAIT_SPLIT/LOADING`，状态只用于筛选展示，能否加入以服务端 `canAssign` 为准；待审核/待测量可提前占位，但确认预装或启动 PDA 前必须进入 `WAIT_SPLIT`。暂估明细的 `totalPackageCount/remainingPackageCount` 在测量前取 Order 原始申报箱数，测量完成后取最新已审核测量箱数，读取补充失败只回退当前已分配数，写入调整仍重新校验权威数量。同柜不可拆组仅在全员命中状态集合时作为一个分页与分配单元；人工加入允许跨渠道，智能推荐仍按柜次渠道。计划可一次性移除全部未拣明细，但任一成员已拣的同柜组必须整组保留。创建柜次时原子生成唯一预装计划，加入入仓码即建立关联；真实集装箱号不阻塞订舱关联，但确认预装和创建 PDA 任务前必须补齐。历史缺号任务允许在预装详情首次补录，保存后恢复 PDA 可进入状态 |
+| 服务端资金账户、授信、冻结、结算与业务扣费 | [Finance](../baiyue-firstleg/finance/AGENTS.md) | [资金账户规则](财务管理/财务对账结算P1闭环.md#客户资金账户) |
-| 客户入库结果与头程费用确认 | 入库测量与计费主流程、当前 Firstleg 契约 | Client `modules/first-leg/components/InboundBillingPanel.vue`、`api/inboundBilling.ts`；Backend `firstleg/` 的 `MerchantInboundBillingController`、`MerchantInboundBillingService`、`FbaPricingService` 与 `firstleg-v1.yaml`。客户仅能确认本客户 `SENT` 的最新费用版本，提交 `expectedFeeVersion` 与幂等键；确认记录当前成员和时间并永久锁定该版本，平台不得再修改 |
+| 订单编排、分柜、同柜不可拆组与柜次 | [模块指引](../apps/admin-web/src/modules/container-loading/AGENTS.md) | [对应章节](业务实现边界.md#订单编排分柜同柜不可拆组与柜次) |
-| 订舱资料、放舱、出仓前船期与订舱级拖车 | 国内货柜履约 README、需求确认和实施边界 | Admin `modules/ocean-bookings/`、`port-schedules/`、`trucking/`；Backend `firstleg/oceanbooking/`、`firstleg/portschedule/`、`TruckAppointmentService`。拖车预约由 `RELEASED` 订舱拥有，不按客户、柜次、装柜计划或真实柜号归属；每个订舱最多一张非终态拖车单，创建候选由服务端排除缺提单/有效订舱文件或已有有效拖车单的订舱；PDA 装柜完成不推进拖车状态；全部要求货柜确认国内离仓后自动完成，人民币拖车费按实装体积分摊为柜次应付并经 Finance Outbox 入池 |
+| 全局智能排柜、预装与真实集装箱号后补 | [模块指引](../apps/admin-web/src/modules/container-loading/AGENTS.md) | [对应章节](业务实现边界.md#全局智能排柜预装与真实集装箱号后补) |
-| 目的港码头拖车与还空预警 | `docs/海外仓业务/README.md` | 与订舱级拖车预约是不同生命周期。Admin 海外清关提柜列表/详情 `modules/container-loading/pages/OverseasContainersView.vue`、`modules/container-loading/pages/OverseasContainerDetailView.vue`；Firstleg 拖车 API `api/terminalDrayages.ts`，柜级到仓 API `api/containerArrivalTimes.ts`。原预约/实际提柜列改为预计/实际到仓：预计时间由平台在列表快捷选择并同步 Lastleg 整柜尾程订单，实际时间取海外 PDA 首次开始收货；车队、邮件、还柜与 `unloadingCompletedAt + 72h` 预警仍归 `firstleg/terminaldrayage/`。 |
+| 客户入库结果与头程费用确认 | [模块指引](../apps/client-web/src/modules/first-leg/AGENTS.md) | [对应章节](业务实现边界.md#客户入库结果与头程费用确认) |
-| 整柜报关资料与完成文件 | 国内货柜履约契约 | 装柜完成后由 Admin `modules/container-loading/components/ContainerCustomsPanel.vue` 管理整柜报关，Client `modules/first-leg/components/CustomsDocumentsDialog.vue`、`api/customs.ts` 按订单处理本客户退税资料；Backend `firstleg/customs/container/`、`customs-v1.yaml`，文件归 `file/`。客户资料可覆盖同柜多个退税入仓码，开始报关后冻结；平台逐资料回传完成文件，全买单柜走平台确认与明细导出 |
+| 订舱资料、放舱、出仓前船期与订舱级拖车 | [模块指引](../apps/admin-web/src/modules/ocean-bookings/AGENTS.md) | [对应章节](业务实现边界.md#订舱资料放舱出仓前船期与订舱级拖车) |
-| 国内出仓确认 | 国内货柜履约契约 | Admin `modules/outbound-dispatch/`；Backend `firstleg/outbound/dispatch/` |
+| 目的港码头拖车与还空预警 | [模块指引](../baiyue-firstleg/firstleg/AGENTS.md) | [对应章节](业务实现边界.md#目的港码头拖车与还空预警) |
-| 客户统计与平台日志 | 当前统计/审计契约 | Admin `modules/customers/`、`modules/audit/`；Backend `firstleg/customerstatistics/`、`audit-service/` |
+| 整柜报关资料与完成文件 | [模块指引](../apps/admin-web/src/modules/container-loading/AGENTS.md) | [对应章节](业务实现边界.md#整柜报关资料与完成文件) |
-| 客户工作台账户与设置 | 订单与客户契约 | Client `modules/account/`、`system/`、`tenant-management/`；Backend `iam/`、`auth/` |
+| 国内出仓确认 | [模块指引](../apps/admin-web/src/modules/outbound-dispatch/AGENTS.md) | [对应章节](业务实现边界.md#国内出仓确认) |
-| 企业订单与跨境业务 | 订单与客户、国内货柜履约契约 | Client `modules/order-management/`、`cross-border/`；Backend `order/`、`firstleg/`、`integration-service/` |
+| 客户统计与运营指标 | [客户模块](../apps/admin-web/src/modules/customers/AGENTS.md) | [统计与日志边界](业务实现边界.md#客户统计与平台日志) |
-| 海外接柜、入库与库内库存 | `docs/海外仓业务/README.md` | Admin 按 `apps/admin-web/AGENTS.md` 海外模块入口；海外入口 `gateway-overseas/`；尾程/入仓/换标/库存 `lastleg-service/`；仓库主档归国内 `warehouse/`，库位/托盘/锁归 `warehouse-overseas-service/` 并只引用国内 warehouseId；与排车、出库、派送共同组成海外仓全流程 |
+| 平台日志、操作日志、审计日志与操作人缺失 | [审计模块](../apps/admin-web/src/modules/audit/AGENTS.md) | [统计与日志边界](业务实现边界.md#客户统计与平台日志) |
-| 尾程订单控制与柜级入仓计划转换 | `docs/海外仓业务/README.md` | Admin `modules/overseas-warehouse/pages/LastMileOrdersView.vue`、`LastMileOrderDetailView.vue`、`api/lastMileOrders.ts`；Backend `lastleg-service/` 的 `LastlegOrderController`、`LastlegOrderCommandService`、`InboundPlanService`、`ContainerInboundPlanConversionCoordinator`，资源归 `warehouse-overseas-service/` 的 `WarehousePalletBatchService`。`orders/container-summaries` 按 `sourceContainerBookingId` 跨客户聚合并分页返回全部稳定来源柜，已完成计划转换的柜仍保留用于接柜仓查询与修改；生成动作只消费 `allPlansReady/pendingPlanCount/resourcePendingPlanCount`，详情不受列表分页截断。确认前从 `/inbound-plans/container-preview` 读取服务端分组、托数、阻断项与 `snapshotVersion/snapshotHash`；`convert-container` 锁柜重算后先批量预留真实托盘，再本地原子生成剩余独立计划并确认资源，失败仅补偿未确认资源，同柜重放不得产生第二批资源。单票手工计划保存后，全柜计划齐全且预览就绪时自动生成并绑定托盘资源，一票柜立即触发；`resourcePendingPlanCount` 表示自动生成异常后的重试入口，资源未齐不得进入 PDA 接柜。自动入口见 Lastleg `ContainerInboundPlanConversionCoordinator.convertManualAndAutoMaterialize`。单票可维护完整入库计划、暂扣/解除及八行人工节点快照；命令提交订单版本与幂等键，新增暂扣只允许完成入库后执行并仅阻断该票后续排车/出库，不阻断入库计划或入库作业；人工节点首次保存后固定 `MANUAL` 来源且不得回退柜级节点 |
+| 客户工作台账户与设置 | [模块指引](../apps/client-web/AGENTS.md) | [对应章节](业务实现边界.md#客户工作台账户与设置) |
-| 海外仓 PDA | `docs/海外仓业务/README.md` | Overseas PDA 入仓 `api/inbound.js`、`api/receiving-adapter.js`、`pages/operation/`，库内/换标按工作台入口，排车与出库 `pages/dispatch/`、`pages/outbound/`；Backend `lastleg-service/inboundplan/pda/`、`pda/`、`dispatch/pda/`、`delivery/`；统一经 `gateway-overseas/`。接柜候选、会话、照片和整柜完成按 `sourceContainerBookingId + containerNo` 聚合且不绑定客户，允许同柜多客户；各入仓码的计划、任务、SKU、托盘与库存仍按自身客户隔离。多计划同柜按服务端返回的 `assigned/mergeAllowed/urgent` 展示，合托只是现场可选提示；扫码实收确认计划生成时预留的真实托盘与库位，不重新分配资源；派送与回访由 Admin/Client 承载 |
+| 企业订单与跨境业务 | [模块指引](../apps/client-web/AGENTS.md) | [对应章节](业务实现边界.md#企业订单与跨境业务) |
-| 海外采购、本土卡车与散板 | `docs/海外仓业务/README.md` | Admin `modules/overseas-business/`；Client `modules/cross-border/`；Backend `lastleg-service/` 的 `procurement/`、`trucking/`、`looseboard/`；统一经 `gateway-overseas/` |
+| 海外接柜、入库与库内库存 | [模块指引](../apps/admin-web/src/modules/overseas-warehouse/AGENTS.md) | [对应章节](业务实现边界.md#海外接柜入库与库内库存) |
-| 海外仓库与通用资料 | `docs/海外仓业务/README.md` | 全部仓库主档进入 Admin `modules/warehouses/` 与国内 `warehouse/`；海外库位/托盘/锁进入 `warehouse-overseas-service/` 并引用国内 warehouseId；报价、汇率、车辆按海外服务实际契约 |
+| 尾程订单控制与柜级入仓计划转换 | [模块指引](../apps/admin-web/src/modules/overseas-warehouse/AGENTS.md) | [对应章节](业务实现边界.md#尾程订单控制与柜级入仓计划转换) |
-| 国内出仓后船节点 | `docs/海外仓业务/README.md` | Admin `modules/port-schedules/`、`ocean-bookings/`、货柜详情；Backend `firstleg/portschedule/`、`integration-service/`；从确认国内出仓查询至目的港到达、提柜和还柜。节点按 `containerBookingId` 柜级聚合，跨区事件使用 `tenantId=0` 平台技术范围，不携带或校验客户 |
+| 海外仓 PDA | [模块指引](../apps/pda-overseas-uniapp/AGENTS.md) | [对应章节](业务实现边界.md#海外仓-pda) |
-| 海外出库、排车、派送、异常与回访 | 当前海外履约契约 | Admin `modules/overseas-warehouse/pages/OutboundsView.vue`、`DeliveryOrdersView.vue`、`ExceptionOrdersView.vue`、`CustomerVisitsView.vue`；Backend `lastleg-service/dispatch/`、`delivery/`、`dropship/`、`exceptionorder/`、`customervisit/`；统一经 `gateway-overseas/`。异常单按 `PENDING → PROCESSING → COMPLETED` 流转，处理完成必须引用归属为 `OVERSEAS_EXCEPTION_EVIDENCE` 的证据；派送退回只从原出库拣货事实选择可退明细，退回海外仓时先把实收恢复到指定真实托盘/库位，再原子完成异常单并将派送置为 `RETURNED` |
+| 海外采购、本土卡车与散板 | [模块指引](../apps/admin-web/src/modules/overseas-business/AGENTS.md) | [对应章节](业务实现边界.md#海外采购本土卡车与散板) |
-| 海外业务费用来源与客户财务 | 财务契约、`docs/跨区域认证与服务通信契约.md` | 海外入仓、采购、美国卡车、本土散板和海外仓服务费由 `lastleg-service/financefee/` 校验真实业务归属并版本化审核；通过 `BUSINESS_FEE_SOURCE_CHANGED` 完整快照、`event-bridge-service/` 和国内 Finance `/internal/finance/v1/business-fee-source-events` 可靠入池。`PAYABLE + DIRECT_PAID` 进入已确认成本且不得再次进入 AP 待结算；Client 仍从 `modules/finance/` 读取获准客户财务，不自动开放平台费用来源维护页 |
+| 采购样品、货款、装箱清单、面单、预估快递费、国内收货寄客户 | [模块指引](../apps/admin-web/src/modules/overseas-business/AGENTS.md) | [对应章节](业务实现边界.md#采购样品货款装箱清单面单预估快递费国内收货寄客户) |
+| 海外仓库主档、名称、地址与能力 | 前端 [Admin](../apps/admin-web/src/modules/warehouses/AGENTS.md)；后端 [Warehouse](../baiyue-firstleg/warehouse/AGENTS.md) | [资源归属](业务实现边界.md#海外仓库与通用资料) |
+| 海外库位、托盘与资源锁 | [Warehouse Overseas](../baiyue-firstleg/warehouse-overseas-service/AGENTS.md) | [资源归属](业务实现边界.md#海外仓库与通用资料) |
+| 车辆管理、司机证照、保养加油、车辆维修/故障/救援/异常、外接货与车次 | [模块指引](../apps/admin-web/src/modules/overseas-master-data/AGENTS.md) | [对应章节](业务实现边界.md#车辆管理司机证照保养加油车辆维修故障救援异常外接货与车次) |
+| 拼车需求池、车次余位、销售拼车意向 | [模块指引](../apps/admin-web/src/modules/overseas-master-data/AGENTS.md) | [对应章节](业务实现边界.md#拼车需求池车次余位销售拼车意向) |
+| 国内出仓后船节点 | [模块指引](../apps/admin-web/src/modules/port-schedules/AGENTS.md) | [对应章节](业务实现边界.md#国内出仓后船节点) |
+| 海外出库、排车、派送、异常与回访 | [模块指引](../apps/admin-web/src/modules/overseas-warehouse/AGENTS.md) | [对应章节](业务实现边界.md#海外出库排车派送异常与回访) |
+| 海外业务费用来源与客户财务 | [模块指引](../baiyue-firstleg/finance/AGENTS.md) | [对应章节](业务实现边界.md#海外业务费用来源与客户财务) |
+| 自营销量与领星统计 | [模块指引](../apps/admin-web/src/modules/self-operated/AGENTS.md) | [对应章节](业务实现边界.md#自营销量与领星统计) |
+| 预约管理与工作日历 | [模块指引](../apps/admin-web/src/modules/appointment-calendar/AGENTS.md) | [对应章节](业务实现边界.md#预约管理与工作日历) |
+| 退货预报、签收、库存与合箱 | [模块指引](../baiyue-firstleg/lastleg-service/AGENTS.md) | [对应章节](业务实现边界.md#退货预报签收库存与合箱) |
+| 散货托盘码生成、打印与跨区传递 | [模块指引](../apps/admin-web/src/modules/loading-lists/AGENTS.md) | [对应章节](业务实现边界.md#散货托盘码生成打印与跨区传递) |
 
-散货托盘码生成、打印与跨区传递：Admin `modules/loading-lists/components/PalletLabelPrintDialog.vue`；Firstleg `LoadingPalletLabelService`、`LoadingCompletedOutboxService`；Lastleg `LastlegSourcePalletMapper`、`InboundPlanService`。从各项目最近指引继续定位；散货 FBA 标签与一件代发实装托盘分别取各自冻结事实。
+## 原型入口索引
+
+仅在根指引的原型触发条件满足时读取。路径从工作区根起算；按终端只查命中行，不把原型当作当前部署或验收事实。
+
+| 范围 | 首选入口 |
+|---|---|
+| 平台管理后台 | `docs/悦/货代SAAS平台后台/AGENTS.md`，按其中模块索引读取拆分原型；完整入口 `docs/悦/货代SAAS平台后台/index.html` |
+| 企业客户端栏目与业务架构 | `docs/悦/柏悦物流客户端/柏悦物流客户端-栏目架构图.html` |
+| 企业工作台与头程下单 | `docs/悦/官网头程下单/workbench.html` |
+| 官网与企业入口 | `docs/悦/官网头程下单/index.html`、`docs/悦/官网头程下单/login.html`、`docs/悦/官网头程下单/register.html` |
+| 微信小程序 | `docs/悦/虫虫出海小程序/index.html` |
+| PDA 拣货 | `docs/悦/PDA拣货/pda-picking.html` |
+| WMS 字段补充 | `docs/悦/货代SAAS平台后台/wms_full_data.json`、`docs/悦/货代SAAS平台后台/柏悦WMS系统文档.md` |
+| 国内货柜履约原型盘点 | `docs/国内货柜履约/国内货柜履约页面与原型清单.md` |
+| 海外仓全流程 | [海外仓页面 ID](海外仓业务/业务规则.md#原型页面定向索引) |
+| 海外仓 PDA | `apps/pda-overseas-uniapp/AGENTS.md`、`apps/pda-overseas-uniapp/src/data/overseas-workbench.js`、`apps/pda-overseas-uniapp/src/pages/operation/operation.vue` 与[海外仓页面 ID](海外仓业务/业务规则.md#原型页面定向索引) |
+| Admin/Client 验收 | `docs/Admin-Client前端原型还原验收规则.md` |

入库测量与计费/README.md

@@ -10,6 +10,8 @@
 
 ## 文档
 
+费用项目默认价格规则（2026-10-19）：平台公共项目可配置可空的 `defaultPrice`（CNY、非负、两位小数），不填表示人工录入，`0` 表示明确的零元默认价。入库与柜次费用仅在用户主动选择项目时带入；入库同时带入单价与金额，柜次带入金额，均允许人工修改。切换到无默认价格的项目时清除前项带价并回到零值待填；打开已有费用、切换供应商或保存业务费用不重新套用默认价。修改或清空项目默认价不追改已有费用，也不改变审核、发布与结算流程；本次不增加计费数量或条件报价。
+
 - [入库测量与计费 V2 需求确认清单（当前会议填写）](入库测量与计费V2需求确认清单.md)
 - [入库测量与计费需求优化版 V2：测量、计费、托盘入库主流程](入库测量与计费需求优化版-v2-测量计费入库主流程.md)
 - [入库测量与计费需求优化版：原型对照（上一版优化稿）](入库测量与计费需求优化版-原型对照.md)

双区域部署与Nacos规划.md

@@ -1,166 +1,5 @@
-# 双区域部署与 Nacos 规划
+# 双区域部署与 Nacos 规划（已替代）
 
-## 1. 适用范围与结论
+自 2026-09-29 起，不再规划开发/测试/生产与 CN/OVERSEAS 双区域。当前唯一目标为单一测试环境、所有服务同机部署。唯一部署主契约见[测试环境单机部署与配置契约](测试环境单机部署与配置契约.md)，认证通信见[统一认证与服务通信契约](统一认证与服务通信契约.md)。
 
-本文冻结国内头程与海外仓服务在开发、测试和生产环境中的部署拓扑、Nacos、数据库及 Event Bridge 边界。账号、Token、API 路由和事件语义继续以《跨区域认证与服务通信契约》为准。
+此文件仅保留旧链接入口，不再定义有效规则。运行配置切换仍待实施与验证。
-
-当前结论：
-
-- 开发、测试采用单宿主机共置：同一环境内同时部署国内 Compose 与海外 Compose，通过独立容器、网络、端口、Nacos Namespace 和数据库 Schema 隔离。
-- 生产采用国内、海外两套独立区域控制面：各自使用本区域 Nacos 集群、数据库和 Redis，不允许海外服务跨境依赖国内 Nacos、MySQL 或 Redis。
-- 跨区域只开放双区域 API、JWKS 公钥和 Event Bridge 接收入口，不使用跨区域服务发现。
-
-## 2. 环境拓扑
-
-| 环境 | 宿主与网络 | Nacos | 数据库 | 适用目的 |
-|---|---|---|---|---|
-| development | 单宿主机共置国内/海外 Compose | 一套开发 Nacos，国内/海外独立 Namespace | 可共用一个开发 MySQL 实例，但必须使用独立 Schema | 日常开发联调 |
-| test | 单宿主机共置国内/海外 Compose | 一套测试 Nacos，国内/海外独立 Namespace | 可共用一个测试 MySQL 实例，但必须使用独立 Schema | 集成测试和验收 |
-| production-cn | 国内独立部署单元 | 国内高可用 Nacos 集群 | 国内独立 MySQL/Redis | Auth、IAM、头程、国内仓和 Finance |
-| production-overseas | 海外独立部署单元 | 海外高可用 Nacos 集群 | 海外独立 MySQL/Redis | 海外 Gateway、Lastleg 和海外 Warehouse |
-
-如果开发与测试实际共用同一套 Nacos 实例，必须创建四个 Namespace，不得复用：
-
-```text
-development-cn
-development-overseas
-test-cn
-test-overseas
-```
-
-Namespace 名称不是服务名。环境变量必须填写 Nacos 实际 Namespace ID；控制台自动生成 UUID 时使用 UUID，不使用展示名称代替。
-
-## 3. 服务归属
-
-### 3.1 国内区域
-
-- `gateway`、`auth-service`、`iam-service`
-- `firstleg-service`、`order-service`、`finance-service`
-- 国内 `warehouse-service`、`file-service`、`audit-service` 等公共服务
-- 国内 Event Bridge，用于接收目标区域为 `CN` 的事件并投递本地 Firstleg
-
-### 3.2 海外区域
-
-- `gateway-overseas`
-- `lastleg-service`，同时持有 `baiyue_lastleg` 内的 IAM 安全事件 Inbox/投影，并开放内部事件接收和实时校验端点
-- `warehouse-overseas-service`
-- 海外 `file-service`，独占海外 RDS 中的 `baiyue_file`，只访问海外本区域私有 OSS Bucket；详细边界见《[阿里云 OSS 文件中心接入设计与评审](阿里云OSS文件中心接入设计与评审.md)》
-- 海外 Event Bridge，用于接收目标区域为 `OVERSEAS` 的事件；业务事件和三类 IAM 安全事件按事件类型投递 Lastleg 的不同内部入口
-
-海外浏览器请求直接进入海外 Gateway，不经过国内 Gateway。Auth 仍只部署在国内；海外服务通过受控 JWKS 地址验证 Auth 签发的短时海外 Token，不访问国内 Redis。
-
-## 4. Nacos 规划
-
-### 4.1 开发与测试
-
-非生产环境允许一套 Nacos 实例承载多个 Namespace。国内配置发布自 `baiyue-firstleg/config/nacos/cn/`，海外配置发布自 `baiyue-firstleg/config/nacos/overseas/`，相同 Data ID 依靠 Namespace 隔离。
-
-国内环境变量：
-
-```dotenv
-NACOS_SERVER_ADDR=<当前环境Nacos地址>
-NACOS_NAMESPACE=<当前环境国内Namespace ID>
-REGION_CODE=CN
-DEPLOYMENT_CELL=<environment>-cn
-DATA_RESIDENCY=CN
-```
-
-海外环境变量：
-
-```dotenv
-OVERSEAS_NACOS_SERVER_ADDR=<当前环境Nacos地址>
-OVERSEAS_NACOS_NAMESPACE=<当前环境海外Namespace ID>
-OVERSEAS_DEPLOYMENT_CELL=<environment>-overseas
-```
-
-海外 Compose 必须强制传入 `REGION_CODE=OVERSEAS` 和 `DATA_RESIDENCY=OVERSEAS`，不得继承共享文件中的国内默认值。
-
-### 4.2 生产
-
-生产国内、海外分别部署本区域 Nacos 集群。服务只注册到本区域，不同步或复制临时服务注册表，也不通过公网访问另一地区 Nacos。
-
-```dotenv
-# 国内生产凭据
-NACOS_SERVER_ADDR=<国内Nacos内网地址>
-NACOS_NAMESPACE=<production-cn Namespace ID>
-
-# 海外生产凭据
-OVERSEAS_NACOS_SERVER_ADDR=<海外Nacos内网地址>
-OVERSEAS_NACOS_NAMESPACE=<production-overseas Namespace ID>
-```
-
-生产 Nacos 必须启用认证、网络 ACL 和持久化；不暴露公网管理端口。数据库密码、JWT 私钥、内部服务 Token 和第三方密钥不得写入 Nacos 明文，继续由 Jenkins Credentials 或生产密钥管理系统注入。
-
-## 5. 数据库隔离
-
-开发、测试即使共用一个 MySQL 实例，也必须保持以下 Schema 独立：
-
-| 区域 | 服务 | Schema |
-|---|---|---|
-| 国内 | Event Bridge | `baiyue_event_bridge` |
-| 海外 | Event Bridge | `baiyue_event_bridge_overseas` |
-| 海外 | Lastleg | `baiyue_lastleg` |
-| 海外 | Warehouse | `baiyue_lastlag_warehouse` |
-
-生产必须进一步使用区域内独立数据库实例或集群。国内服务不得查询海外 Schema，海外服务不得查询国内 Schema；跨区域事实只通过版本化事件或已确认的受保护内部接口传递。
-
-## 6. Event Bridge 双实例
-
-每个区域部署一个相同制品、独立数据库的 Event Bridge：
-
-```text
-Firstleg Outbox
-  -> 海外 Event Bridge Inbox
-  -> Lastleg 本地消费者
-
-Lastleg Outbox
-  -> 国内 Event Bridge Inbox
-  -> Firstleg 本地消费者
-```
-
-国内 Firstleg 配置海外 Bridge 基础地址，Feign 自动追加接收路径：
-
-```dotenv
-LASTLEG_EVENT_BRIDGE_URL=<海外Event Bridge基础地址>
-```
-
-海外 Lastleg 配置国内 Bridge 基础地址：
-
-```dotenv
-FIRSTLEG_EVENT_BRIDGE_URL=<国内Event Bridge基础地址>
-```
-
-区域内消费者使用本地服务地址：
-
-```dotenv
-# 海外 Bridge
-EVENT_CONSUMER_URL=http://lastleg-service:9303/internal/lastleg/events
-
-# 国内 Bridge
-FIRSTLEG_CONTAINER_EVENT_CONSUMER_URL=http://firstleg:9202/internal/firstleg/v1/container-events
-```
-
-跨区域 Bridge 接收入口使用 TLS、内部服务身份、网络白名单和幂等校验；不得暴露数据库或消费者内部接口。
-
-## 7. Jenkins 与环境文件
-
-开发、测试可以各用一份 Secret File，同时包含国内和海外非敏感路由变量；Compose 负责选择本区域变量。生产必须拆分凭据：
-
-```text
-firstleg-production-cn-env
-firstleg-production-overseas-env
-```
-
-生产海外部署不得读取国内数据库、Redis 或 Nacos 地址。Event Bridge 同一制品需要按 `CN`、`OVERSEAS` 两个部署单元分别发布，使用不同 Compose Project、容器名、端口和数据库。
-
-## 8. 当前仓库实施差距
-
-目标架构已冻结，但当前部署代码仍需完成以下收敛：
-
-1. `docker-compose.overseas.yml` 当前仍从 `NACOS_SERVER_ADDR` 取值，应改为显式使用 `OVERSEAS_NACOS_SERVER_ADDR`。
-2. `deploy/scripts/deploy-built-service.sh` 与 `deploy-services.sh` 的海外服务门禁应校验 `OVERSEAS_NACOS_SERVER_ADDR`。
-3. Jenkins 生产配置需要拆分国内/海外 Secret File，并为 Event Bridge 提供明确区域部署参数或独立 Job。
-4. 海外 Nacos Namespace 创建、配置发布、JWKS 可达性和双向 Event Bridge 真实投递必须分别验收，不能以容器健康检查代替。
-5. 海外 Gateway 和 Nacos 已存在 File Service 入口，但海外统一 SQL 与部署清单尚未包含海外 `file-service`、`baiyue_file`；OSS 接入实施前必须补齐并完成区域内真实上传、下载和双实例读取验收。
-
-这些差距未完成前，不得声称生产双区域部署已就绪。

国内货柜履约/README.md

@@ -1,51 +1,41 @@
-# 国内货柜履约文档
+# 国内货柜履约
 
-国内货柜履约以国内头程后程作业为范围，完成从排柜、订舱、拖车和仓内拣货，到装柜证据齐全并进入 `LOADED`/装柜完成的业务闭环。`DELIVERED`/派送完成由到达海外仓后的可信回传推进，不属于国内国内货柜履约操作范围。
+本目录负责国内分柜、订舱、拖车、拣货、装柜、装柜后的报关协同、送港、进港和甩柜事实。本入口只维护流程路由；代码、部署和验收状态以环境主契约及实际证据为准，不在此重复记录。
 
-> 范围更正：国内货柜履约只维护订舱和出仓前所需的船名航次、港口、ETD/ETA 等资料。柜子确认离开国内仓库后的 `CarrierScheduleQuery`、六家船公司查询、每 3 天/最多 3 次、来源/过期标识和后续定时船节点查询整体归海外仓业务，见 `../海外仓业务/README.md`。国内货柜履约不再建设或验收这套查询。
+## 当前流程入口
 
-## 当前主体模型与开工禁令
+- [头程到尾程流程节点梳理](../头程到尾程流程节点梳理.md)：三大业务块总览和 F01-F40 节点总表。
+- [阶段三：国内货柜履约与出仓](../头程到尾程分阶段流程/阶段三-国内货柜履约与出仓.md)：分柜、订舱、拖车、拣货、装柜、报关和国内出仓的详细操作。
+- [阶段四：海运、目的港与尾程计划](../头程到尾程分阶段流程/阶段四-海运目的港与尾程计划.md)：实际开船后的海运、目的港和尾程计划衔接。
+- [报关资料与船期价格接入梳理](报关资料与船期价格接入梳理.md)：报关资料、报关行回执、客户确认/打回、正式申报、海关结果和船期价格专题。
+- [船期日历功能规划](船期日历功能规划.md)：渠道、周模板、单次船期、收货截止时间和按渠道货量统计的独立日历规划。
+- [报关代码开发交接清单](../头程到尾程/报关代码开发交接清单.md)：报关专项的实现范围与验收线索，任务确实涉及时读取，不代表当前完成状态。
 
-- 国内货柜履约继续按业务单租户、“平台—客户”两级开发，客户之间严格隔离。Java 与接口中的业务 `tenant_id > 0` / `tenantId` 当前表示客户 ID；`tenant_id=0` 是平台身份、平台 RBAC 和平台公共仓库、快递公司、托盘、库位等公共资源技术作用域。客户往来单位、订单、文件和费用仍归属客户 `tenant_id>0`。
+## 货柜关键节点
-- 国内货柜履约不得新增租户主表、租户选择器、客户所属租户配置、租户切换、租户级 RBAC 或租户级配置，也不得把当前 `tenant_id` 从客户 ID 改义为上级租户 ID。
-- `tenant`、`Tenant*`、`merchant`、接口路径和字段属于历史兼容命名，继续保留；真实租户能力必须等未来独立需求、数据迁移和跨服务契约方案确认后再实施。
 
-## 文档
+货柜对外统一使用 `cabinetNo` 柜次号（`D0001` 起，全局连续、不按日期重置），创建时只生成一次；日历、提柜、智能装柜、货柜详情及出仓均读取该值。`containerBookingId` 仅用于技术关联，`containerNo` 为真实集装箱号。货柜不再维护独立的 CB 格式 `bookingNo`；海运订舱和外接货登记各自的 `bookingNo` 不属于货柜编号，保留各自业务语义。
 
-- [国内货柜履约闭环审计报告（2026-08-08）](国内货柜履约闭环审计报告-2026-08-08.md)：基于当前代码、接口、自动化和测试环境证据的闭环审计，列出阻断项、优先级和 GO 准入标准。
+```text
-- [国内货柜履约装柜闭环产品确认表（2026-08-08）](国内货柜履约装柜闭环产品确认表-2026-08-08.md)：提供给产品直接填写的纯业务确认表，不包含技术实现细节。
+分柜/订舱/拖车 → 拣货 → 装柜完成（LOADED）
-- [国内货柜履约装柜闭环开发前确认单（2026-08-08）](国内货柜履约装柜闭环开发前确认单-2026-08-08.md)：用于产品确认直接开发前的状态、门禁、PDA 取证、冲正和验收细节。
+                    ├─ 报关协同：资料 → 报关行回执 → 客户确认/打回重做
-- [国内货柜履约开发规划：国内出仓](国内货柜履约开发规划.md)
+                    │              → 全部客户确认 → 整柜提交 → 正式申报 → 海关结果
-- [国内货柜履约开发进度表](国内货柜履约开发进度表.md)：参考订单与客户采用“大任务 → 详细任务 → 里程碑 → 未确认事项 → 开工准入 → 验收”结构维护。
+                    ↓ 报关完成
-- [虫虫出海国内货柜履约开发进度表（Excel）](虫虫出海国内货柜履约开发进度表.xlsx)：可筛选、可下拉维护并使用公式汇总的项目进度工作簿。
+                  进入待发区
-- [国内货柜履约需求确认表](国内货柜履约需求确认表.md)：集中跟踪 P3-Q1～P3-Q13、负责人和最终结论。
+                    ↓
-- [国内货柜履约开工门禁](国内货柜履约开工门禁.md)：维护已确认范围、跨端硬边界和局部阻断项；模块指引引用本文件，不重复维护阶段状态。
+          送港运输：离仓 → 送港 → 进港 → 甩柜/改配（如发生）
-- [国内货柜履约页面与原型清单](国内货柜履约页面与原型清单.md)：按管理后台、企业客户端和 PDA 维护页面范围及原型状态。
+                                  ↓
-- [国内货柜履约验收任务拆分与待确认清单](国内货柜履约验收任务拆分与待确认清单.md)：真实 HTTP/真机验收覆盖、coverageGap 解除条件和并行任务入口。
+                         船舶实际开航后进入海运节点
-- `参考资料/出仓流程.png`：本期 9 个核心动作及业务终点的原始参考图。
+```
 
-## 当前状态
+报关完成是进入待发区的门槛。进入待发区后再推进离仓、送港、进港和船期；甩柜/改配只改变运输船次，不影响已完成的报关资料、回执和客户确认。报关行回执、客户确认、正式申报、海关放行、进港、甩柜和实际开船分别记录，不能用其中一个节点代替另一个节点。
 
-国内货柜履约已进入分模块部署联调。已确认不新建独立出仓单，现有订单列表/详情承载主状态；支持一单多柜、一个柜拼多个订单，并采用“父订单→子订单→柜次”关系，已装载数量形成子订单，未装载数量自动生成后续子订单。进入 `LOADED`/装柜完成前，订舱完成、拖车完成、报关放行回执、PDA 拣货完成及五类证据完整均为服务端硬门禁；`LOADED` 后错误统一线下人工处理，国内 Admin/PDA 不提供在线冲正或手工推进 `DELIVERED`。当前不能因子链路已通过而宣告整期完成，最终结论以真实 HTTP 全链路验收为准。
+费用确认属于头程下单块的并行事项，不阻断排柜、拣货或装柜；装柜完成时仍未确认的当前有效费用按系统默认确认并保留来源。这个默认确认只适用于费用，不适用于报关资料的客户确认。
 
-柜子出仓后的船公司/船节点查询已重新归入海外仓业务。国内货柜履约报关首版不做系统对接，全部由人工整理、线下提交和人工上传回执。仓库初始化角色包括操作员、拣货员、理货员，具体权限矩阵由 IAM 契约任务落表。
+## 当前变更相关文档
 
-P3-Q1～P3-Q13 均已确认；P3-Q4 采用 uni-app 开发并支持在线更新，Android 广播扫描已接入。P3-Q5 复用入库测量与计费实时库存、当前位置和可用量接口，不扩展完整 WMS。
+- [国内货柜履约需求确认表](国内货柜履约需求确认表.md)：需要核对已确认的业务口径时使用。
+- [国内货柜履约页面与原型清单](国内货柜履约页面与原型清单.md)：需要核对页面范围或原型入口时使用。
 
-### PDA 当前确认口径（2026-08-10）
+## 冻结记录（只用于追溯）
 
-- Android 扫描广播方式已接入；PDA 采用 uni-app 开发并支持在线更新，按既定发布安排完成真机验收。
+开发规划、进度、门禁、验收矩阵、审计、产品确认和旧任务卡已移入[国内货柜履约历史记录](归档/README.md)。这些文件不删除、不回写；若要调整当前流程，修改总览、对应阶段或报关专题，并同步实际接口/权限契约。
-- 正式作业仅支持在线：进入任务即标记“拣货中”，扫描保存在绑定作业员+任务+柜次的设备持久化草稿，点击提交时批量写后端。
-- 允许部分拣货或跳拣，但每个未完成项必须填写异常原因；存在未解决异常时不能完成或进入 `LOADED`。
-- 重复提交返回原结果，版本冲突提示员工刷新重试。
-- PDA 只能现场拍照，Admin 可人工上传；五类证据各至少 1 张有效照片，可同类型多张追加，错图只作废不硬删除。
-- 单柜次只允许一名作业员作业，不做多人并行和任务接管；进入任务即标记“拣货中”，扫描草稿按作业员+任务+柜次隔离，点击提交时批量写入后端。
-- 后台操作员、理货员可按权限人工上传证据；拣货员只负责 PDA 现场拍照，不开放后台人工上传。照片无限期保留，客户不可见照片和锁码。
-
-### 发布与真实验收状态（2026-08-10）
-
-- Admin 已部署 `b593d72`：智能装柜、预装清单、装柜清单均可访问真实接口；预装/装柜清单不再要求选择仓库，详情仍使用列表行返回的真实仓库归属。
-- Firstleg 已部署 `3bfc11a`：修复 PDA 拣货时库位分配状态提前变更的问题；真实复跑仍发现 PDA `pick` 第二处 `S0500`，当前仍阻断 PDA 复核、装柜完成、报关 LOADED 关联和最终门禁，不能标记国内货柜履约闭环完成。
-- 验收 fixture 顺序已核实为 `orders → inbound-measurement → phase3-container-loading → phase3-loading → phase3-customs → phase3-port-schedules → phase3-loading-finalize`；脚本保留真实失败，不以 mock、历史资源或 coverage gap 伪装通过。
-- PDA“点击提交时批量写入后端”的原子 batch 契约尚未实现；当前页面仍不能证明整批事务、批次幂等、服务端库存快照和失败整批回滚已具备。
-- ZIM hCaptcha、COSCO 动态页继续按产品确认的人工兜底保留为 `MANUAL_REQUIRED`，不作为自动查询 PASS。

国内货柜履约/国内货柜履约需求确认表.md

@@ -8,7 +8,7 @@
 
 - 状态统一使用：待确认、确认中、已确认、已取消。
 - 阻断级别统一使用：开工阻断、模块阻断、非阻断。
-- 结论确认后同步更新 `国内货柜履约开发规划.md`、`国内货柜履约开发进度表.md` 和受影响的页面原型。
+- 结论确认后同步更新 `归档/国内货柜履约开发规划.md`、`归档/国内货柜履约开发进度表.md` 和受影响的页面原型。
 - 未确认事项只能作为候选方案，不能直接写成固定开发或验收承诺。
 
 ## 二、确认事项
@@ -22,13 +22,16 @@
 | P3-Q5 | 拣货是否依赖实时库存和库位可用量？ | 默认使用入库测量与计费处理单元和当前位置；如需完整库存，单独评估 WMS 范围 | 开工阻断 | 已确认 | 产品/业务 | 2026-08-10 | PDA 拣货必须依赖实时库存和库位可用量；首版复用入库测量与计费处理单元、当前位置和可用量接口，超量、库存不足和库位不可用由服务端拒绝；不扩展完整 WMS | 入库测量与计费及国内货柜履约契约、拣货、库存边界 |
 | P3-Q6 | 柜封照片有哪些必传类型、数量、采集方式、处理规则和留存期限？ | 五类证据、角色和留存按确认版直接进入契约 | 模块阻断 | 已确认 | 产品/业务 | 2026-08-10 | 空仓、半仓、满仓、锁仓、带锁码照五类各至少 1 张有效照片，同类型可无限追加；PDA 只能现场拍照；后台操作员和理货员可人工上传；拣货员只负责 PDA 现场采集，不开放后台人工上传；错图不硬删除，按原因、操作人、时间作废；带锁码照必须填写锁码文本；照片无限期保留，客户不可见照片和锁码 | 装柜、PDA 拍照、Admin 上传、文件存储、订单后程门禁 |
 | P3-Q7 | 报关资料清单是否按国家、渠道和货物类型变化？ | 清单配置化，并保存业务使用的清单版本 | 模块阻断 | 已确认 | 产品/业务 | 2026-08-10 | 首版不对接海关或代理系统；按人工维护资料清单、收集/补件并保存版本，具体清单可配置 | 客户资料、报关审核、文件版本 |
-| P3-Q8 | 报关代理如何接收资料并返回回执？ | 首版系统内整理、线下提交，正式接口后续评估 | 模块阻断 | 已确认 | 产品/业务 | 2026-08-10 | 全部人工处理：平台整理资料后线下交代理，授权人员人工上传代理回执；系统记录提交批次、回执版本和时间，不建设自动对接 | 报关协同、回执上传 |
+| P3-Q8 | 报关代理如何接收资料并返回回执？ | 首版系统内整理、线下提交，正式接口后续评估 | 模块阻断 | 已确认 | 产品/业务 | 2026-08-10；2026-09-24 更正 | `LOADED` 后平台按客户/入仓码收集资料并线下发给报关行；授权人员上传每轮报关行回执，发给对应客户确认。客户打回后重新上传、重新发报关行并生成新回执，直到该客户确认；记录资料版本、回执版本、roundNo、发送时间和确认/打回审计 | 报关协同、客户确认、回执上传 |
 | P3-Q9 | “港务信息”指船期、港口作业状态还是两者，包含哪些字段，由谁维护？ | 国内货柜履约只维护订舱与出仓前船期资料 | 已重新归期 | 已确认 | 产品/业务 | 2026-08-19 | 柜子确认离开国内仓库后的船公司/货物跟踪查询、每 3 天最多 3 次、来源、更新时间和过期标识整体归海外仓业务；国内货柜履约不建设或验收该查询 | 国内货柜履约订舱资料、海外仓业务船节点查询 |
 | P3-Q10 | 订单进入“装柜完成”后发现错误如何处理？ | 仅保留线下人工处理和审计，不建设在线冲正 | 模块阻断 | 已确认 | 产品/业务 | 2026-08-10 | `LOADED` 后不提供在线冲正/回退入口，统一线下人工处理；系统保留原状态和审计记录，不由国内 Admin/PDA 推进 `DELIVERED` | 装柜完成门禁、权限、审计 |
-| P3-Q11 | 九个动作中哪些是强制前置，哪些允许并行？ | 统一门禁按已确认前置执行；PDA 单柜次单人作业 | 开工阻断 | 已确认 | 产品/业务 | 2026-08-10 | 订舱完成、拖车完成、报关资料完成且有放行回执、PDA 拣货完成及五类证据完整均为进入 `LOADED` 的强制门禁；PDA 单柜次单人作业，不做多人并行；进入任务即拣货中，提交时批量写入 | 全流程、状态机、PDA、页面进度 |
+| P3-Q11 | 九个动作中哪些是强制前置，哪些允许并行？ | 统一门禁按已确认前置执行；PDA 单柜次单人作业 | 开工阻断 | 已确认 | 产品/业务 | 2026-08-10；2026-09-24 更正 | 费用确认不阻断排柜、预装、PDA 或装柜。进入 `LOADED` 只校验物理装柜、PDA、数量、真实柜号和五类证据；`LOADED` 后先完成退税报关，报关完成后进入待发区，再推进送港和船期；甩柜/改配只改变船次，不重做已完成报关；PDA 单柜次单人作业 | 全流程、状态机、PDA、报关、送港、页面进度 |
-| P3-Q12 | 报关回执包含哪些类型，海关放行是否为装柜完成硬门禁？ | 有效放行回执作为硬门禁，首版人工上传 | 开工阻断 | 已确认 | 产品/业务 | 2026-08-10 | 首版回执由人工上传；必须存在有效放行回执才能通过 `LOADED` 门禁。回执类型和版本可追溯，具体字段按人工业务单据映射 | 报关状态、装柜完成门禁、客户回执 |
+| P3-Q12 | 报关回执包含哪些类型，客户确认和海关放行如何衔接？ | 首版人工上传回执并保留版本 | 开工阻断 | 已确认 | 产品/业务 | 2026-08-10；2026-09-24 更正 | `LOADED` 后按客户/入仓码收集资料并发送报关行；报关行回执发对应客户确认，客户打回则重新上传、重新发送并生成新回执；所有客户确认后才向报关行提交整柜资料并正式申报；之后分别记录查验、不查验放行、补件/退回等海关结果。回执上传不等于客户确认，客户确认也不等于海关放行 | 报关状态、客户回执、整柜申报、海关结果 |
 | P3-Q13 | 国内货柜履约终点以什么状态为准？ | 国内系统以能掌控的最后环节为终点 | 开工阻断 | 已确认 | 用户当前对话确认 | 2026-08-08 | 国内货柜履约终点为 `LOADED`/装柜完成；`DELIVERED`/派送完成只能在到达海外仓后由海外仓可信回传推进，不属于国内国内货柜履约操作和验收范围 | 阶段边界、状态、里程碑、验收、海外仓回传 |
 | P3-Q14 | 订舱、渠道柜次、放舱与智能排柜的先后关系是什么？ | 线下已订妥的订舱在创建时完整登记五项真实运输快照并直接确认；放舱不覆盖首次快照 | 开工阻断 | 已确认 | 用户当前对话确认 | 2026-08-12 | 订舱创建请求必须携带提单号、船名、航次、预计开船时间、预计到港时间五项真实运输数据，并直接进入 `CONFIRMED`；渠道、箱型和数量同时确定，系统按箱型需求数量生成绑定渠道的稳定内部柜次。未放舱不影响候选查询、智能推荐、人工调整和保存装柜计划；同一柜次只能装同渠道入库单，服务端禁止跨渠道混装。`RELEASED` 仅作为后续放舱/PDA 门禁，不补录、不覆盖首次五项运输快照；真实集装箱号可在放舱时或之后录入 | 订舱、柜次、智能排柜、预装、PDA、运输信息 |
+| P3-Q15 | 客户未确认费用是否阻断排柜、装柜？装柜完成后如何处理？ | 费用作为并行事实，装柜完成时对当前有效版本做系统默认确认 | 模块阻断 | 已确认 | 用户当前对话确认 | 2026-09-24 | 客户费用确认不阻断排柜、预装、PDA 或装柜。装柜完成后，针对本次已装范围的当前有效且已发布费用版本，若客户未确认则记录“系统默认确认（装柜完成）”；保留客户确认与 `SYSTEM_AUTO_AT_LOADED` 来源、版本、柜次/入仓码、时间和幂等标识。没有有效费用版本不得伪造确认；部分装载不确认余量或整张未完成订单 | 费用版本、装柜完成、客户进度、审计、部分装载 |
+| P3-Q16 | 报关资料何时收集、何时正式报送？ | 装柜后通知报关，按客户确认轮次完成后正式提交 | 模块阻断 | 已确认 | 用户当前对话确认 | 2026-09-24 | `LOADED` 后以最终实装清单通知报关行，按客户/入仓码收集资料并发送报关行；回执发客户确认，打回则重新上传、重新发送并产生新回执，循环至所有客户通过；全部客户确认后再提交整柜资料给报关行确认，由报关行正式申报；海关查验/不查验放行等结果单独记录；报关完成后进入待发区 | 客户资料、回执轮次、客户确认、整柜申报、待发区 |
+| P3-Q17 | 送港和报关是否互相等待？甩柜何时发生？ | 报关完成后进入待发区，实际开船才进入海运 | 开工阻断 | 已确认 | 用户当前对话确认 | 2026-09-24 | `LOADED` 后先完成报关；报关完成后进入待发区，再安排拖车、送港和进港。船舱不足记录 `ROLLED_OVER`，保存原船次、改配船次、滚动次数和通知；甩柜/改配不影响已完成报关资料、回执和客户确认；只有承运船舶真实开航才写 `VESSEL_DEPARTED`/海运节点 | 送港、船次、甩柜、海运节点 |
 
 ### 2.1 PDA 已确认子决策
 
@@ -44,7 +47,7 @@
 | P3-PDA-D08 | 2026-08-09 | 同类型证据允许多张并采用追加记录；错误/重复照片不硬删除，只作废 | 每条照片独立保存；作废记录原因、操作人和时间，历史可追溯 |
 | P3-PDA-D09 | 2026-08-09 | 空仓、半仓、满仓、锁仓、带锁码照五类证据各至少 1 张有效且未作废的照片，可多张；带锁码照同时要求锁码文本 | 服务端完整性门禁按“每类至少一张有效记录”校验，不能按单槽位替换模型实现 |
 
-> 验收映射：当前自动化已真实覆盖五类证据上传、同类型多图追加、跨类型/伪造 `fileId` 拒绝、锁码文本门禁和错图作废审计；设备在线、持久化草稿批量提交仍按[验收任务拆分与待确认清单](国内货柜履约验收任务拆分与待确认清单.md)保留 coverageGap。
+> 验收映射：当前自动化已真实覆盖五类证据上传、同类型多图追加、跨类型/伪造 `fileId` 拒绝、锁码文本门禁和错图作废审计；设备在线、持久化草稿批量提交仍按[验收任务拆分与待确认清单](归档/国内货柜履约验收任务拆分与待确认清单.md)保留 coverageGap。
 
 ## 三、已确认架构决策
 
@@ -52,9 +55,10 @@
 |---|---|---|---|
 | P3-D1 | 2026-08-08 | 国内货柜履约不新建独立出仓单，现有订单列表承载全部主状态；柜次、订舱、拖车、拣货、证据和报关作为订单关联子对象 | 取消出仓单页面和数据模型规划，改为增强现有订单列表/详情及服务端统一编排 |
 | P3-D2 | 2026-08-10 | 订单拆分采用“父订单→子订单→柜次”；已装载数量形成子订单，未装载数量自动生成后续子订单；支持一单多柜和多订单拼柜 | 后端必须保留父子订单、柜次、数量分摊和整体时间线；不得把未装载部分静默丢弃 |
-| P3-D3 | 2026-08-10 | `LOADED` 的硬门禁包含订舱完成、拖车完成、报关放行回执、PDA 拣货完成和五类证据完整；`LOADED` 后错误线下人工处理 | 统一门禁服务负责校验，国内页面不提供在线冲正或 `DELIVERED` 操作 |
+| P3-D3 | 2026-08-10；2026-09-24 更正 | `LOADED` 只表示物理装柜完成，门禁包含真实柜号、PDA 拣货、数量守恒和五类证据；报关完成后进入待发区，再推进送港/进港；甩柜只影响船期，不影响已完成报关；`LOADED` 后错误线下人工处理 | 统一门禁服务分别维护物理装柜、报关案例、待发区、送港/进港、甩柜和实际开船事实；国内页面不提供在线冲正或 `DELIVERED` 操作 |
 | P3-D4 | 2026-08-10；2026-08-19 更正归期 | 船公司官网查询：每 3 天一次、最多 3 次，保存来源、更新时间和过期标识 | 该能力及首批六家来源整体归海外仓业务，国内货柜履约只保留订舱与出仓前船期资料 |
 | P3-D5 | 2026-08-10 | 初始化仓库常用角色：操作员、拣货员、理货员；按最小权限授予拣货、证据上传和查看能力 | 角色初始化由 IAM/统一 SQL 任务实现，具体权限矩阵在技术契约评审中落表 |
+| P3-D6 | 2026-09-24 | 费用确认不阻断排柜和装柜；装柜完成后对已装范围的当前有效已发布版本执行系统默认确认，来源与客户主动确认分开审计；`LOADED` 后报关采用“报关行回执→客户确认/打回重做→所有客户通过→整柜正式申报→查验/放行”，报关完成后进入待发区，送港/船次单独记录甩柜和实际开船 | 同步费用版本、部分装载、客户报关案例、回执轮次、整柜申报、待发区、送港/船次和客户/后台节点 |
 
 ## 四、建议确认顺序
 
@@ -73,8 +77,8 @@
 
 ### 5.2 会议输入
 
-- 本确认表中的 P3-Q1～P3-Q13。
+- 本确认表中的 P3-Q1～P3-Q17。
-- `国内货柜履约开发规划.md` 的流程、状态、里程碑和任务骨架。
+- `归档/国内货柜履约开发规划.md` 的流程、状态、里程碑和任务骨架。
 - `国内货柜履约页面与原型清单.md` 中已有参考原型和待补页面。
 - 入库测量与计费输出契约、目标 PDA 信息、文件存储能力及报关/港务协作现状。
 
@@ -93,3 +97,4 @@
 - 国内货柜履约范围内/范围外清单及跨期依赖。
 - 仍有风险的事项、责任人和完成日期。
 - 已允许进入 T02 契约设计与任务拆分；未决技术项只阻断其对应实现，不反向阻断整期已确认范围。
+

国内货柜履约/归档/README.md

@@ -0,0 +1,18 @@
+# 国内货柜履约历史记录
+
+本目录保存国内货柜履约的开发规划、进度、开工门禁、验收、审计和旧确认材料。内容不删除，也不作为当前流程入口；当前规则以[国内货柜履约 README](../README.md)、[头程到尾程流程节点梳理](../../头程到尾程流程节点梳理.md)和[报关资料与船期价格接入梳理](../报关资料与船期价格接入梳理.md)为准。
+
+## 文件
+
+- [开发规划](国内货柜履约开发规划.md)
+- [开发进度表](国内货柜履约开发进度表.md)
+- [开发进度表（Excel）](虫虫出海国内货柜履约开发进度表.xlsx)
+- [需求确认表之外的开工门禁与验收记录](国内货柜履约开工门禁.md)
+- [验收任务拆分与待确认清单](国内货柜履约验收任务拆分与待确认清单.md)
+- [货柜管理全链验收矩阵](货柜管理全链验收矩阵-2026-08-13.md)
+- [货柜履约原型字段验收矩阵](货柜履约原型字段验收矩阵-2026-08-17.md)
+- [闭环审计报告](国内货柜履约闭环审计报告-2026-08-08.md)
+- [装柜闭环产品确认表](国内货柜履约装柜闭环产品确认表-2026-08-08.md)
+- [装柜闭环开发前确认单](国内货柜履约装柜闭环开发前确认单-2026-08-08.md)
+- [Wave1 开发任务卡](国内货柜履约Wave1开发任务卡-2026-08-09.md)
+

国内货柜履约/归档/国内货柜履约Wave1开发任务卡-2026-08-09.md

@@ -1,5 +1,7 @@
 # 国内货柜履约 Wave 1 开发任务卡
 
+> **历史版本声明（2026-09-24）**：本文是旧版低风险任务拆分，不能直接作为当前开发排期或门禁依据。当前流程改为“柜前资料预收集 → 物理装柜 `LOADED` → 按最终实装清单正式报关 → 有效放行回执后 `DEPARTED_WAREHOUSE`”，费用确认不阻断装柜，装柜完成时按已装范围对当前有效已发布费用版本执行系统默认确认。当前开发范围以 [头程到尾程流程节点梳理（重构版）](../../头程到尾程流程节点梳理.md)、[报关资料与船期价格接入梳理](../报关资料与船期价格接入梳理.md) 和最新需求确认表为准。
+
 整理日期：2026-08-09  
 用途：产品确认后用于研发排期和任务分派。  
 当前范围：只做低风险基础能力；不提前实现未确认的主状态机规则。
@@ -53,3 +55,4 @@
 - 允许无拣货、缺照片或缺锁码进入 `LOADED`。
 - 国内 Admin/PDA 手工推进 `DELIVERED`。
 - 在产品未确认前固化部分拣货拆单和一单多柜聚合规则。
+

国内货柜履约/归档/国内货柜履约开发规划.md

@@ -2,12 +2,12 @@
 
 > 创建日期：2026-07-28  
 > 状态：已进入分模块开发规划  
-> 流程依据：[出仓流程](参考资料/出仓流程.png)中的头程物流“03 出仓”；用户已于 2026-08-08 确认国内国内货柜履约以 `LOADED`/装柜完成为阶段终点
+> 流程依据：[出仓流程](../参考资料/出仓流程.png)中的头程物流“03 出仓”；当前以 `LOADED` 作为物理装柜节点，报关线和送港线在装柜后并行，实际开船后进入海运节点。
-> 前置阶段：[订单与客户文档](../订单与客户/README.md) · [入库测量与计费文档](../入库测量与计费/README.md)
+> 前置阶段：[订单与客户文档](../../订单与客户/README.md) · [入库测量与计费文档](../../入库测量与计费/README.md)
 
-> 2026-08-10 产品确认版：国内货柜履约不新建独立出仓单；支持一单多柜、一个柜拼多个订单，采用“父订单→子订单→柜次”关系，已装载数量形成子订单，未装载数量自动生成后续子订单。`LOADED` 硬门禁为订舱完成、拖车完成、报关放行回执、PDA 拣货完成和五类证据完整；`LOADED` 后错误线下人工处理。五类证据各至少 1 张有效照片，同类型多张追加，PDA 仅现场拍照，后台操作员和理货员可人工上传，照片无限期保留且客户不可见。
+> 2026-08-10 产品确认版；2026-09-24 按最新流程更正：国内货柜履约不新建独立出仓单；支持一单多柜、一个柜拼多个订单，采用“父订单→子订单→柜次”关系，已装载数量形成子订单，未装载数量自动生成后续子订单。`LOADED` 仅校验真实柜号、PDA 拣货、数量守恒和五类证据；装柜后报关线按“客户资料→报关行回执→客户确认/打回重做→所有客户通过→整柜正式申报→查验/放行”推进，送港线独立记录离仓、进港、甩柜和改配，实际开船才进入海运。费用确认不阻断排柜和装柜；装柜完成后对已装范围的当前有效已发布费用版本执行系统默认确认，保留客户/系统来源。`LOADED` 后错误线下人工处理。五类证据各至少 1 张有效照片，同类型多张追加，PDA 仅现场拍照，后台操作员和理货员可人工上传，照片无限期保留且客户不可见。
 
-> 当前范围更正：原 `P3-PORT-01`、六家船公司官网查询及 `CarrierScheduleQuery` 是柜子确认离开国内仓库后的业务，整体重新归入海外仓业务。国内货柜履约仅保存订舱与出仓前所需的船名航次、港口和 ETD/ETA 等资料，不建设或验收出仓后的定时节点查询。
+> 当前范围更正：国内货柜履约保留 `DEPARTED_WAREHOUSE`、`PORT_RECEIVED`、`ROLLED_OVER` 和实际开船前的船次/港口事实；承运船舶真实 `VESSEL_DEPARTED` 后的六家船公司官网查询、`CarrierScheduleQuery` 和定时节点查询归入海外仓业务。国内侧不以预计 ETD 提前展示海运中。
 
 > 主体模型与硬约束：国内货柜履约只实现“平台—客户”两级，业务 `tenant_id > 0` / `tenantId` 当前表示客户 ID；`tenant_id=0` 是平台身份、平台 RBAC 和平台公共仓储资源技术作用域，客户往来单位、订单、文件和费用归属客户 `tenant_id>0`。禁止新增租户主表、租户选择器、客户所属租户配置、租户切换、租户级 RBAC 或租户级配置，禁止把现有 `tenant_id` 改义为上级租户 ID；历史类名、路径和字段继续兼容。
 
@@ -20,16 +20,15 @@
 ```text
 智能排柜 → 订舱 → 预约拖车
     ↓
-PDA 拣货 → 装柜并上传货柜/铅封照片
+PDA 拣货 → 装柜并上传五类证据
     ↓
-客户上传报关资料 → 平台整理提交报关代理 → 上传回执供客户下载
+`LOADED`/装柜完成
-    ↓
+    ├─ 报关：通知报关行 → 客户资料 → 报关行回执 → 客户确认/打回重做
-维护订舱与出仓前所需的船名航次、港口和预计时间
+    │          → 所有客户通过 → 整柜正式申报 → 查验/放行
-    ↓
+    └─ 送港：拖车 → 离仓 → 送港/进港 → 甩柜/改配（如发生）→ 实际开船
-国内国内货柜履约完成：`LOADED`/装柜完成
 ```
 
-国内货柜履约完成标准是同一订单/柜次已完成排柜和 PDA 拣货，空仓、半仓、满仓、锁仓、带锁码照五类证据各至少 1 张有效照片已真实上传，锁码文本已保存，服务端门禁通过并将订单推进为 `LOADED`/装柜完成。`DELIVERED`/派送完成必须等货物到达海外仓后由海外仓可信回传推进，不是国内国内货柜履约人工操作。
+国内货柜履约的装柜完成标准是同一订单/柜次已完成排柜和 PDA 拣货，空仓、半仓、满仓、锁仓、带锁码照五类证据各至少 1 张有效照片已真实上传，锁码文本已保存，数量守恒且服务端门禁通过后推进为 `LOADED`/装柜完成。`LOADED` 后报关线和送港线同时启动；客户确认不阻断送港，进港不代表报关完成，容量不足记录甩柜；只有承运船舶实际开航后才进入海运节点。`DELIVERED`/派送完成必须等货物到达海外仓后由海外仓可信回传推进，不是国内国内货柜履约人工操作。
 
 ### 原型动作覆盖
 
@@ -42,8 +41,8 @@ PDA 拣货 → 装柜并上传货柜/铅封照片
 | 5. 拍货柜及铅封照上传 | 装柜及柜封证据 | P3-LOAD-01、P3-LOAD-02 | 已确认五类证据各至少 1 张有效照片、同类型可多张，锁码文本必填 |
 | 6. 客户上传报关资料 | 报关资料协同 | P3-CUS-01 | 已覆盖 |
 | 7. 整理给到报关代理报关 | 报关资料协同 | P3-CLEAR-01 | 已覆盖 |
-| 8. 回执上传到系统供客户下载 | 报关回执与客户下载 | P3-CLEAR-01、P3-CUS-02 | 已覆盖，首版由授权人员人工上传放行回执 |
+| 8. 回执上传并由客户确认 | 报关行回执与客户确认 | P3-CLEAR-01、P3-CUS-02 | 待补齐多轮回执、客户确认/打回和整柜正式提交 |
-| 9. 出仓后查询港务/船节点 | 海外仓业务船节点定时查询 | 原 P3-PORT-01、P3-CUS-02 对应查询部分 | 已重新归入海外仓业务，不是国内货柜履约动作或验收项 |
+| 9. 送港、甩柜与实际开船 | 送港/船次事实 | P3-TRUCK-01、P3-CUS-02 | 装柜后与报关线并行；实际开船后进入海运节点 |
 
 ## 二、阶段边界
 
@@ -54,8 +53,9 @@ PDA 拣货 → 装柜并上传货柜/铅封照片
 - 预约拖车、车辆司机、到仓装柜和离仓记录。
 - PDA 任务领取、扫码拣货、部分拣货、异常、复核和幂等提交。
 - 装柜、柜号、铅封号及货柜/铅封照片证据。
-- 客户上传报关资料、平台审核补件、整理并提交报关代理。
+- `LOADED` 后通知报关行，客户上传报关资料、平台审核补件、线下发送报关行。
-- 报关回执上传、版本、客户可见范围和授权下载。
+- 报关行回执上传、版本、客户确认/打回重做、客户可见范围和授权下载；所有客户确认后才提交整柜资料正式申报。
+- 装柜后送港、进港、甩柜/改配和实际开船事实。
 - 装柜完成门禁、确认、时间线和站内通知；`LOADED` 后纠错走线下人工流程。
 
 ### 明确不纳入国内货柜履约
@@ -65,7 +65,7 @@ PDA 拣货 → 装柜并上传货柜/铅封照片
 - GPS 实时跟车、电子铅封、称重设备、摄像头 OCR 和 IoT 自动采集。
 - 自动报关、关税计算、退税、完整清关业务和自动单证识别。
 - 海上运输、海外清关、目的港提柜、海外仓入库和末端派送。
-- 柜子确认离开国内仓库后的 `CarrierScheduleQuery`、船公司查询、定时船节点和到港跟踪；整体归海外仓业务。
+- 承运船舶真实 `VESSEL_DEPARTED` 后的 `CarrierScheduleQuery`、船公司查询、定时船节点和海上到港跟踪；整体归海外仓业务。国内侧保留送港、进港和甩柜事实。
 - 无人工确认的全自动排柜、自动订舱和不可逆业务操作。
 
 ## 三、参与角色与数据边界
@@ -87,7 +87,7 @@ PDA 拣货 → 装柜并上传货柜/铅封照片
 
 ## 四、流程与状态设计
 
-原型以 1 至 9 编号表达动作顺序。产品确认后，订舱、拖车、报关放行、PDA 拣货和证据完整是进入 `LOADED` 的强制前置；智能排柜、订舱、拖车和资料整理可按子流程并行，但服务端不得绕过门禁。PDA 单柜次单作业员，不实现多人并行或任务接管。
+原图以 1 至 9 编号表达展示动作顺序。按本轮确认，费用确认不阻断排柜或装柜；`LOADED` 只校验物理装柜事实，装柜后报关线和送港线并行，客户确认不阻断送港，进港不代表报关完成，实际开船才进入海运。PDA 单柜次单作业员，不实现多人并行或任务接管。
 
 ### 1. 现有订单的国内货柜履约主状态
 
@@ -95,7 +95,7 @@ PDA 拣货 → 装柜并上传货柜/铅封照片
 |---|---|---|
 | `WAIT_SPLIT` | 待分柜 | 入库测量与计费已完成，等待排柜/预装 |
 | `LOADING` | 装柜中 | 预装已确认，PDA 执行拣货和装柜证据上传 |
-| `LOADED` | 装柜完成 | 订舱、拖车、报关放行回执、PDA 拣货完成，且五类证据各至少 1 张有效照片和锁码文本已通过服务端门禁 |
+| `LOADED` | 装柜完成 | 真实柜号、PDA 拣货与数量守恒、五类证据各至少 1 张有效照片和锁码文本已通过服务端门禁；装柜后同时启动报关线和送港线 |
 | `DELIVERED` | 派送完成 | 货物到达海外仓后由海外仓可信回传推进；属于国内货柜履约之后的只读状态 |
 
 ### 2. 子流程状态
@@ -103,8 +103,8 @@ PDA 拣货 → 装柜并上传货柜/铅封照片
 - 订舱：待订舱、订舱中、已订舱、订舱失败、已取消。
 - 拖车：待预约、已预约、车辆已到仓、装柜中、已离仓、改约、已取消。
 - 拣货：待分配、待拣货、拣货中、待复核、已完成、异常挂起、已取消。
-- 报关：资料待上传、资料待审核、待补件、待提交、已提交代理、回执待上传、回执已上传、已退回、已取消；有效放行回执是 `LOADED` 硬门禁，首版由授权人员人工上传。
+- 报关：`LOADED` 后待通知报关、客户资料待上传/审核、已发报关行、回执待客户确认、客户已确认、客户打回待重做、所有客户已确认、整柜正式申报、查验、放行/退回；回执上传不等于客户确认，客户确认不等于海关放行。
-- 出仓前船期资料：待维护、已确认、信息变更；出仓后节点和“已开船”等运输事实归海外仓业务。
+- 送港/船期：待送港、已离仓、送港中、已进港、甩柜/改配、待开船；只有实际 `VESSEL_DEPARTED` 后进入海运节点。
 
 主状态由服务端根据已确认的必要子流程推进。客户端不得通过传任意目标状态跳过拣货复核、装柜证据或已配置的装柜完成门禁。
 
@@ -127,10 +127,10 @@ PDA 拣货 → 装柜并上传货柜/铅封照片
 
 ### 3. 订舱与出仓前船期资料
 
-- 国内货柜履约只维护订舱和装柜/出仓交接所需的预计开船、到港等静态资料，不执行出仓后的船公司或船节点查询。
+- 国内货柜履约维护订舱、送港、进港、甩柜/改配和实际开船前的状态；承运船舶实际开航后由海外仓业务执行船公司和船节点查询。
 - 船公司/订舱代理、航线、订舱号、船名航次、起运港、目的港、截单、截关、截港、ETD 和 ETA 暂列为候选字段。
 - 订舱失败、改船、甩柜、船期延误和取消暂列为候选异常场景，按业务确认结果实现。
-- 六家船公司来源、每 3 天/最多 3 次、最近有效结果和过期标识，以及对应适配层全部移至海外仓业务船节点查询维护。
+- 六家船公司来源、每 3 天/最多 3 次、最近有效结果和过期标识，以及对应适配层在 `VESSEL_DEPARTED` 后由海外仓业务船节点查询维护。
 - 国内货柜履约页面展示的 ETD/ETA 必须明确为订舱或人工确认快照，不得伪装成出仓后的实时查询结果。
 - 建议关键信息变更保留旧值、新值、原因，并向授权用户发送站内提醒。
 
@@ -165,18 +165,20 @@ PDA 拣货 → 装柜并上传货柜/铅封照片
 
 ### 7. 报关资料协同
 
-- 客户按资料清单上传发票、箱单、合同、委托书和申报要素等文件。
+- `LOADED` 后按最终实装清单建立每个客户/入仓码的报关案例；客户按资料清单上传发票、箱单、合同、委托书和申报要素等文件。
 - 资料清单可按国家/地区、渠道和货物类型配置，并保存订单使用的清单版本。
 - 平台报关专员审核完整性，可退回具体文件并记录补件原因和时限。
-- 提交报关代理时生成提交批次，冻结该批次关联的文件版本。
+- 资料发送报关行时记录 roundNo 和发送时间，报关行回执上传后发对应客户确认；客户打回则重新上传、重新发送并生成新回执版本。
+- 柜内所有客户确认后才生成整柜正式提交批次，冻结该批次关联的文件版本并交报关行正式申报。
 - 首版采用系统内整理加线下提交，不直接对接海关单一窗口。
 
 ### 8. 报关回执与客户下载
 
-- 授权人员人工上传代理回传的报关回执并关联提交批次；有效放行回执是装柜完成硬门禁，回执类型、版本和操作者可追溯。
+- 授权人员人工上传报关行回传的每轮回执并关联客户报关案例；回执类型、版本、roundNo、操作者和客户确认/打回结果可追溯。
 - 替换文件产生新版本，不覆盖原记录；退单或补件形成明确任务。
 - 客户只能下载本企业且标记为客户可见的回执。
 - 文件下载使用授权地址并记录审计，不暴露内部存储路径。
+- 所有客户确认后，平台向报关行提交整柜资料；报关行正式申报后另行记录查验、不查验放行、补件/退回等海关结果。
 
 ### 9. 装柜完成确认与海外回传边界
 
@@ -246,8 +248,8 @@ PDA 拣货 → 装柜并上传货柜/铅封照片
 | P3-M2 订舱与拖车 | 订舱、出仓前船期资料、拖车预约和异常处理可用 | 服务商与权限可用 |
 | P3-M3 PDA 拣货 | 在线任务、持久化草稿、批量提交、差异、复核和幂等可用 | 服务端任务与库存契约可用 |
 | P3-M4 装柜封柜 | 柜号、铅封和照片证据完整，门禁生效 | 文件能力与必传清单确认 |
-| P3-M5 报关协同 | 客户上传、平台审核、补件、提交和回执下载闭环 | 报关资料清单确认 |
+| P3-M5 报关协同 | `LOADED` 后客户资料、报关行回执、客户确认/打回重做、所有客户通过、整柜正式申报和查验/放行闭环 | 报关资料清单确认 |
-| P3-M6 装柜完成 | 订舱、拖车、放行回执、PDA 拣货、五类证据和锁码文本满足门禁后进入 `LOADED`/装柜完成 | 装柜完成硬门禁已确认 |
+| P3-M6 装柜完成及并行送港 | 真实柜号、PDA 拣货、数量守恒、五类证据和锁码文本满足门禁后进入 `LOADED`；随后并行推进送港/进港/甩柜和报关线，实际开船才进入海运 | 装柜完成、报关线和送港线分开 |
 | P3-M7 联调验收 | 跨端、设备、安全、弱网、性能、迁移和发布完成 | P3-M1 至 P3-M6 验收通过 |
 
 ## 九、建议开发任务
@@ -259,18 +261,18 @@ PDA 拣货 → 装柜并上传货柜/铅封照片
 | P3-DSP-01 | 后台 | 订单国内货柜履约编排 | 在现有订单列表/详情中接入柜次、子流程、异常、时间线和门禁操作 | P0 | P3-BASE-02 |
 | P3-PLAN-01 | 公共 | 排柜规则 | 按已确认规则实现输入、约束、偏好和冲突判断 | P0 | P3-BASE-02、P3-Q1 |
 | P3-PLAN-02 | 后台 | 智能排柜 | 按已确认范围实现建议、人工确认和追溯 | P0 | P3-PLAN-01 |
-| P3-BOOK-01 | 后台 | 订舱 | 订舱和经确认的船名航次、港口、变更及异常；订舱完成是 `LOADED` 门禁 | P0 | P3-DSP-01 |
+| P3-BOOK-01 | 后台 | 订舱 | 订舱和经确认的船名航次、港口、变更及异常；订舱/拖车服务送港线，不作为 `LOADED` 的报关前置 | P0 | P3-DSP-01 |
-| 原 P3-PORT-01 | 后台/服务端 | 出仓后船节点查询 | 已重新归入海外仓业务，不作为国内货柜履约交付或验收项；沿用现有 `CarrierScheduleQuery`，不得重复实现 | 海外仓业务 | P3-BOOK-01、确认国内出仓 |
+| P3-PORT-01 | 后台/服务端 | 送港、进港与甩柜 | 记录 `DEPARTED_WAREHOUSE`、`PORT_RECEIVED`、`ROLLED_OVER`、改配船次和客户通知；不以预计 ETD 推进海运 | P0 | P3-BOOK-01、P3-TRUCK-01 |
-| P3-TRUCK-01 | 后台 | 拖车预约 | 服务商、车辆司机、时间窗、到离仓和异常 | P0 | P3-DSP-01 |
+| P3-TRUCK-01 | 后台 | 拖车预约 | 服务商、车辆司机、时间窗、到离仓、进港和异常 | P0 | P3-DSP-01 |
 | P3-PICK-01 | 公共 | 拣货任务 | 按排柜方案生成任务、明细、差异和复核规则 | P0 | P3-PLAN-02 |
 | P3-PDA-01 | PDA | 在线扫码拣货 | 进入任务标记拣货中、扫描草稿、部分/跳拣异常原因和批量提交 | P0 | P3-PICK-01 |
 | P3-PDA-02 | PDA/服务端 | 草稿与提交安全 | 作业员+任务+柜次持久化草稿、幂等重试、版本冲突、成功/放弃清理 | P0 | P3-PDA-01 |
 | P3-LOAD-01 | 后台 | 装柜封柜 | 柜号、锁码文本、装柜节点、五类多图证据和门禁复核 | P0 | P3-PICK-01 |
 | P3-LOAD-02 | PDA/Admin/服务端 | 柜封拍照上传 | PDA 现场拍摄、Admin 人工上传、五类证据多图追加、真实文件上传、预览、失败重试、作废和提交 | P0 | P3-LOAD-01、文件能力可用 |
-| P3-CUS-01 | 客户端 | 报关资料 | 清单、上传、补件、版本和进度查看 | P0 | 文件能力可用 |
+| P3-CUS-01 | 客户端 | 报关资料与客户确认 | `LOADED` 后清单、上传、补件、回执查看、确认/打回和轮次进度 | P0 | 文件能力可用 |
-| P3-CLEAR-01 | 后台 | 报关协同 | 人工审核、补件、线下提交代理、人工上传放行回执和版本审计 | P0 | P3-CUS-01 |
+| P3-CLEAR-01 | 后台 | 报关协同 | 通知报关行、人工审核、回执轮次、客户确认汇总、所有客户通过后整柜正式提交、查验/放行记录 | P0 | P3-CUS-01 |
-| P3-CUS-02 | 客户端 | 回执及出仓前船期资料 | 回执下载、订舱预计开船/到港快照和变更时间线；出仓后查询展示归海外仓业务 | P0 | P3-BOOK-01、P3-CLEAR-01 |
+| P3-CUS-02 | 客户端 | 回执及送港/船期资料 | 回执确认、打回重做、送港/进港/甩柜和实际开船前状态展示 | P0 | P3-BOOK-01、P3-CLEAR-01 |
-| P3-GATE-01 | 服务端 | 装柜完成门禁 | 校验订舱、拖车、报关放行回执、PDA 拣货、五类证据和锁码文本，幂等推进 `LOADED`；`LOADED` 后仅线下人工处理 | P0 | P3-PICK-01、P3-LOAD-01、P3-LOAD-02 |
+| P3-GATE-01 | 服务端 | 装柜完成与并行分支门禁 | 校验真实柜号、PDA 拣货、数量守恒、五类证据和锁码文本，幂等推进 `LOADED`；随后分别创建报关案例和送港任务，实际开船才推进海运 | P0 | P3-PICK-01、P3-LOAD-01、P3-LOAD-02 |
 | P3-OVERSEAS-01 | 服务端 | 海外仓派送完成回传 | 只接受海外仓可信回传，校验身份、签名、时间窗、防重放和幂等，推进 `DELIVERED` | P1/后续阶段 | 海外仓契约 |
 | P3-NOTIFY-01 | 公共 | 通知异常 | 站内通知、阻塞、责任人、时限和失败补偿 | P1 | 核心流程完成 |
 | P3-TEST-01 | 公共 | 自动化测试 | 权限、排柜、幂等、并发、文件、门禁和状态测试 | P0 | 所有 P0 模块 |
@@ -305,11 +307,12 @@ PDA 拣货 → 装柜并上传货柜/铅封照片
 | P3-Q5 | 拣货是否依赖实时库存和库位可用量？ | 已确认依赖入库测量与计费实时库存、当前位置和可用量接口；不扩展完整 WMS |
 | P3-Q6 | 柜封照片有哪些必传角度和留存期限？ | 已确认：五类各至少 1 张、同类型可多张追加、后台操作员/理货员可上传、拣货员仅 PDA 现场采集、错图作废、无限期保留、客户不可见 |
 | P3-Q7 | 报关资料清单是否按国家、渠道和货物类型变化？ | 已确认首版人工维护清单和版本，不接自动报关 |
-| P3-Q8 | 报关代理如何接收资料和返回回执？ | 已确认线下提交，授权人员人工上传回执 |
+| P3-Q8 | 报关代理如何接收资料和返回回执？ | 已确认 `LOADED` 后线下提交；授权人员人工上传每轮回执，客户确认/打回，所有客户通过后再提交整柜资料 |
-| P3-Q9 | 原型中的“港务信息”具体指船期、港口作业状态还是两者，包含哪些字段，由谁维护？ | 当前更正：国内货柜履约只维护订舱与出仓前船期资料；六家船公司及出仓后节点查询整体归海外仓业务 |
+| P3-Q9 | 原型中的“港务信息”具体指船期、港口作业状态还是两者，包含哪些字段，由谁维护？ | 当前更正：国内货柜履约维护送港、进港、甩柜/改配和实际开船前状态；只有实际开船后进入海运节点查询 |
 | P3-Q10 | 进入装柜完成后发现错误如何处理？ | 已确认线下人工处理，当前不提供在线冲正 |
-| P3-Q11 | 九个动作中哪些是强制前置，哪些允许并行？ | 已确认订舱、拖车、报关放行、PDA 拣货和五类证据为 `LOADED` 硬门禁；单柜次单作业员 |
+| P3-Q11 | 九个动作中哪些是强制前置，哪些允许并行？ | 费用确认不阻断排柜/装柜；`LOADED` 只校验物理装柜、PDA、数量和证据；报关线和送港线并行，客户确认不阻断送港，进港不代表报关完成；单柜次单作业员 |
-| P3-Q12 | “报关回执”具体包含哪些类型，海关放行是否为国内出仓硬门禁？ | 已确认有效放行回执为 `LOADED` 硬门禁，首版人工上传 |
+| P3-Q12 | “报关回执”具体包含哪些类型，海关放行如何与客户确认衔接？ | 已确认：回执人工上传并发客户确认；客户打回则重做并生成新回执；所有客户通过后才整柜正式申报，查验/放行单独记录 |
+| P3-Q17 | 送港和报关是否互相等待？甩柜何时发生？ | 已确认：`LOADED` 后两条线同时启动；送港可先到港，报关可先完成客户确认；船舱不足记录甩柜/改配，实际开船才进入海运 |
 | P3-Q13 | 国内货柜履约终点以什么状态为准？ | 已确认为 `LOADED`/装柜完成；`DELIVERED`/派送完成由海外仓回传，不属于国内国内货柜履约 |
 
 ## 十二、建议实施顺序
@@ -320,3 +323,5 @@ PDA 拣货 → 装柜并上传货柜/铅封照片
 4. 完成管理后台的出仓编排，再接 PDA 现场执行和客户资料协同。
 5. 使用脱敏数据演练拼柜、一单多柜、未装数量生成子订单、错拣、补件和改船；`LOADED` 后不演练在线冲正。
 6. 在真实 PDA 和代表性仓库网络环境中完成联调、验收和灰度发布。
+
+

国内货柜履约/归档/国内货柜履约开发进度表.md

@@ -8,7 +8,7 @@
 
 ## 一、国内货柜履约目标
 
-国内货柜履约承接入库测量与计费到仓、实测、差异处理、处理单元编码和当前位置记录，完成智能排柜、订舱、拖车预约、PDA 拣货、装柜拍照、报关协同、港务信息查询，并将现有订单推进到 `LOADED`/装柜完成。
+国内货柜履约承接入库测量与计费到仓、实测、差异处理、处理单元编码和当前位置记录，完成智能排柜、订舱、拖车预约、PDA 拣货、装柜拍照，并在 `LOADED` 后分别推进报关客户确认闭环和送港/进港/甩柜；只有承运船舶实际开航才进入海运节点。
 
 当前验收基线已确认为 `LOADED`/装柜完成。`DELIVERED`/派送完成只能在货物到达海外仓后由海外仓可信回传推进，不属于国内国内货柜履约操作和验收范围。
 
@@ -24,8 +24,8 @@
 | T06 | 拖车预约 | 服务商、车辆司机、预约时间窗、到离仓节点和异常 | 联调中 | 80% | 2026-08-10 | 待排期 | Firstleg/Admin | 预约生命周期和服务中心串联已通过，最终 LOADED 门禁待 PDA |
 | T07 | PDA 拣货与复核 | 在线进入任务、持久化扫描草稿、批量提交、部分拣货、异常、幂等和单人作业 | 已阻塞 | 45% | 2026-08-10 | 待排期 | Firstleg/PDA | `pick` 第二处真实 S0500 未收口；原子 batch、库存快照、失败整批回滚未实现 |
 | T08 | 装柜及柜封证据 | 装柜节点、柜号、铅封号、PDA 现场拍照、后台角色上传、多图追加、作废和复核 | 联调中 | 80% | 2026-08-10 | 待排期 | Firstleg/Admin/PDA | 五类证据、多图追加、作废和硬门禁已通过；终态仍依赖 PDA |
-| T09 | 报关资料与回执 | 人工资料清单、后台审核补件、线下提交代理、人工上传放行回执 | 联调中 | 70% | 2026-08-10 | 待排期 | Firstleg/Admin | 人工清单和资料版本已通过；LOADED 子订单关联受 PDA 失败级联阻断 |
+| T09 | 装柜后报关资料与客户确认 | `LOADED` 后通知报关行；客户资料→报关行回执→客户确认/打回重做→所有客户通过→整柜正式申报→查验/放行 | 联调中 | 70% | 2026-09-24 | 待排期 | Firstleg/Admin | 多轮回执、客户确认和整柜提交仍待实现 |
-| T10 | 装柜完成门禁 | 校验订舱、拖车、报关放行、PDA 拣货、五类证据和锁码文本，推进 `LOADED` | 已阻塞 | 70% | 2026-08-10 | 待排期 | Firstleg | 门禁逐项读取和 fail-closed 已通过，真实推进 `LOADED` 等 PDA 修复 |
+| T10 | 装柜完成与送港/开船门禁 | `LOADED` 校验物理装柜；送港线独立校验订舱/拖车、离仓、进港和甩柜；实际开船才进入海运 | 已阻塞 | 70% | 2026-09-24 | 待排期 | Firstleg | 报关线和送港线并行口径已确认，真实推进与 PDA 修复仍待完成 |
 | T11 | 客户端国内货柜履约协同 | 装柜进度、柜次、回执、预计开船/到港和变更时间线 | 待开始 | 0% | 待排期 | 待排期 | 待分配 | 客户不查看装柜照片和锁码；依赖 T05、T09、T10 |
 | T12 | 联调测试与发布 | 跨端联调、自动化测试、PDA 真机、安全、弱网、迁移、验收和发布 | 联调中 | 70% | 2026-08-10 | 待排期 | 总控/测试 | Admin、Firstleg 已分模块部署并持续真实 HTTP 验收；PDA S0500、batch 契约和真机验收未收口 |
 
@@ -43,8 +43,8 @@
 | P3-T06-00 | T06 | 后台/服务端 | 拖车预约 | 服务商、车辆司机、时间窗、到离仓和异常；完成状态供门禁校验 | P0 | 联调中 | 80% | P3-T03-00 | Firstleg/Admin | 预约、附件、历史及服务中心链路已通过真实接口 |
 | P3-T07-00 | T07 | PDA/后台/服务端 | PDA 拣货与复核 | 按单柜次单作业员实现在线草稿、批量提交、异常、幂等和实时库存校验 | P0 | 已阻塞 | 45% | P3-T04-00 | Firstleg/PDA | 广播扫描已接入；真实 pick S0500 与原子 batch 契约仍待收口 |
 | P3-T08-00 | T08 | PDA/后台/服务端 | 装柜及柜封证据 | 实现五类多图追加、角色上传、作废和无限期留存，客户不可见 | P0 | 联调中 | 80% | P3-T07-00 | Firstleg/Admin/PDA | 五类证据与安全边界已通过，真机拍照和终态待验收 |
-| P3-T09-00 | T09 | 客户端/后台/服务端 | 报关资料与回执 | 实现人工清单、补件、线下提交记录、人工放行回执上传 | P0 | 联调中 | 70% | P3-T02-00 | Firstleg/Admin | 人工协同接口已部署，最终子订单关联受 PDA 失败级联阻断 |
+| P3-T09-00 | T09 | 客户端/后台/服务端 | 报关资料与客户确认闭环 | 实现客户案例、报关行回执轮次、确认/打回重做、所有客户通过后整柜正式提交、查验/放行记录 | P0 | 联调中 | 70% | P3-T02-00 | Firstleg/Admin | 人工协同接口已部署，客户确认闭环仍待实现 |
-| P3-T10-00 | T10 | 后台/服务端 | 装柜完成门禁 | 实现订舱/拖车/放行/PDA/证据硬门禁并推进 `LOADED` | P0 | 已阻塞 | 70% | P3-T07-00、P3-T08-00、P3-T09-00 | Firstleg | 门禁读取已通过；推进 LOADED 受 PDA 主链阻断 |
+| P3-T10-00 | T10 | 后台/服务端 | 装柜完成与送港/开船事实 | 实现物理 `LOADED`、送港/进港、甩柜/改配和实际开船分层事实，不以报关确认阻断送港 | P0 | 已阻塞 | 70% | P3-T07-00、P3-T08-00、P3-T09-00 | Firstleg | 门禁读取已通过；推进 LOADED 受 PDA 主链阻断 |
 | P3-T11-00 | T11 | 客户端/服务端 | 客户端国内货柜履约协同 | 展示柜次、装柜进度、客户可见回执和船期；不返回照片与锁码 | P0 | 待开始 | 0% | P3-T05-00、P3-T09-00、P3-T10-00 | 待分配 | - |
 | P3-T12-00 | T12 | 公共 | 联调测试与发布 | 维护定向/全量真实 HTTP、PDA 真机、安全和发布回归 | P0 | 联调中 | 70% | P3-T02-00～P3-T11-00 | 总控/测试 | 已进入分模块部署验收；不得用 mock、历史资源或 coverage gap 伪装通过 |
 | P3-T01-PROTO-01 | T01 | 公共 | 原型盘点 | 盘点流程图、后台、企业客户端和 PDA 中与国内货柜履约相关的页面及交互 | P0 | 已完成 | 100% | - | 待分配 | 2026-07-28 已完成首次盘点，来源为 `docs/悦` |
@@ -97,12 +97,12 @@
 | P3-M2 订单国内货柜履约编排 | 现有订单、柜次、排柜、订舱、港务和拖车可关联追溯 | 联调中 | 待排期 |
 | P3-M3 仓内出仓 | PDA 拣货、复核、装柜和柜封证据闭环 | 已阻塞 | 待排期 |
 | P3-M4 报关协同 | 客户资料、后台审核、提交代理、回执上传下载闭环 | 联调中 | 待排期 |
-| P3-M5 装柜完成 | 订舱、拖车、放行回执、PDA 和证据门禁满足后进入 `LOADED`；后续错误线下处理 | 已阻塞 | 待排期 |
+| P3-M5 装柜完成及并行分支 | 真实柜号、PDA、数量守恒和五类证据门禁满足后进入 `LOADED`；随后并行推进报关客户确认闭环和送港/进港/甩柜，实际开船才进入海运 | 已阻塞 | 待排期 |
 | P3-M6 国内货柜履约上线 | 联调、真机、安全、测试、验收和生产发布完成 | 进行中 | 待排期 |
 
 ## 七、未确认事项（需求确认进度）
 
-当前 13 项主确认事项均已有产品最终结论；P3-Q4 已确认采用 uni-app、在线更新与 Android 广播扫描。完整结论统一维护在 [国内货柜履约需求确认表](国内货柜履约需求确认表.md)。
+当前 13 项主确认事项均已有产品最终结论；P3-Q4 已确认采用 uni-app、在线更新与 Android 广播扫描。完整结论统一维护在 [国内货柜履约需求确认表](../国内货柜履约需求确认表.md)。
 
 验收拆分已建立：PDA 进入任务、拣货幂等/版本冲突、五类证据真实上传、多图追加和锁码门禁进入自动化；真机在线、设备草稿批量提交、证据作废、设备与权限留存等仍保留 coverageGap，详见[国内货柜履约验收任务拆分与待确认清单](国内货柜履约验收任务拆分与待确认清单.md)。
 
@@ -118,8 +118,8 @@
 | P3-Q8 | 模块阻断 | 报关代理接收资料和返回回执的方式 | 已确认 | 线下提交、人工上传回执 |
 | P3-Q9 | 开工阻断 | 港务信息的业务含义、字段和维护方 | 已确认 | 六家船公司查询、三日周期、三次上限、过期标识 |
 | P3-Q10 | 模块阻断 | 装柜完成后的错误处理和冲正方式 | 已确认 | 线下人工处理，不提供在线冲正 |
-| P3-Q11 | 开工阻断 | 九个动作的强制前置和并行关系 | 已确认 | 订舱/拖车/放行/PDA/证据为硬门禁；单柜次单人 |
+| P3-Q11 | 开工阻断 | 九个动作的强制前置和并行关系 | 已确认 | `LOADED` 后报关线和送港线并行；客户确认不阻断送港，进港不代表报关完成；单柜次单人 |
-| P3-Q12 | 开工阻断 | 报关回执类型及海关放行是否为装柜完成硬门禁 | 已确认 | 有效放行回执为硬门禁，人工上传 |
+| P3-Q12 | 开工阻断 | 报关行回执、客户确认、正式申报和海关结果 | 已确认 | 回执必须发客户确认，打回则重做；所有客户通过后才整柜正式申报，查验/放行单独记录 |
 | P3-Q13 | 开工阻断 | 国内货柜履约终点 | 已确认 | `LOADED`/装柜完成；`DELIVERED` 由海外仓回传，移出国内货柜履约验收 |
 
 ## 八、开工准入记录
@@ -128,7 +128,7 @@
 
 | 准入编号 | 准入条件 | 当前状态 | 责任方 | 完成证据 |
 |---|---|---|---|---|
-| P3-GO-01 | P3-Q1～P3-Q13 均形成产品结论 | 已完成 | 产品、业务 | `国内货柜履约需求确认表.md` 已同步最终结论 |
+| P3-GO-01 | P3-Q1～P3-Q17 均形成产品结论 | 已完成 | 产品、业务 | `国内货柜履约需求确认表.md` 已同步最终结论 |
 | P3-GO-02 | 确认结论已同步开发规划、进度表、页面清单和验收范围 | 已完成 | 产品、项目负责人 | README、进度表、页面清单和验收口径已按确认版同步 |
 | P3-GO-03 | 关键缺失原型已补齐并评审，包括订单装柜完成门禁、客户端国内货柜履约页面和 PDA 五类多图拍照 | 进行中 | 产品、设计、业务 | 页面清单中的关键页面达到已确认状态 |
 | P3-GO-04 | T02 公共契约完成，入库测量与计费输入、状态机、权限、数据模型、接口、错误码和审计口径稳定 | 进行中 | 前后端、架构/技术负责人 | 主体契约已部署；PDA 原子 batch 契约仍缺 |
@@ -152,3 +152,4 @@
 3. 完成 PDA 真机广播扫码、在线草稿、五类证据拍照、多图追加和作废验收。
 4. 收口 T11 客户端国内货柜履约页面及客户可见性、安全边界。
 5. 复跑国内货柜履约定向和默认全量真实 HTTP 验收，完成发布记录后再评估国内货柜履约完成状态。
+

国内货柜履约/归档/国内货柜履约开工门禁.md

@@ -6,14 +6,15 @@
 
 - 已确认规则可进入契约、数据、接口、页面和测试拆分，不需要等待整期所有模块完成。
 - 订单继续承载国内货柜履约主状态，不新建独立出仓单；支持父订单、子订单与柜次关系，以及一单多柜和多订单拼柜。
-- 智能排柜、订舱与船期、拖车预约、PDA 在线拣货、五类装柜证据、人工报关回执和 `LOADED` 服务端门禁按需求确认表执行。
+- 智能排柜、订舱与船期、拖车预约、PDA 在线拣货、五类装柜证据、`LOADED` 后客户报关确认闭环、送港/甩柜和实际开船按本轮确认流程执行。
 - 国内货柜履约的国内终点为 `LOADED`；`DELIVERED` 只由海外仓可信回传推进。
 
 ## 跨端硬边界
 
-- `LOADED` 前必须由服务端校验订舱完成、拖车完成、有效报关放行回执、PDA 拣货完成和五类有效证据完整；国内 Admin/PDA 不提供在线冲正或手工推进 `DELIVERED`。
+- `LOADED` 前必须由服务端校验真实柜号、PDA 拣货与数量守恒、五类有效证据和未解决异常。`LOADED` 后报关线和送港线分别校验：报关线按客户资料、报关行回执、客户确认/打回、所有客户通过、整柜正式申报和海关结果推进；送港线按订舱/拖车、离仓、进港、甩柜和实际开船推进。客户确认不阻断送港，进港不代表报关完成。国内 Admin/PDA 不提供在线冲正或手工推进 `DELIVERED`。
 - PDA 正式作业仅在线；单柜次只允许一名作业员，不支持多人并行、任务接管或换班释放。进入任务即由服务端标记拣货中，扫描草稿按作业员、任务和柜次隔离，提交时批量写入。
 - 每类证据至少一张有效照片，允许同类型追加；错误照片只能作废并保留审计。客户不可见照片与锁码。
+- 报关在 `LOADED` 后正式启动：每个客户经历资料上传、报关行回执、客户确认或打回重做，所有客户通过后才提交整柜资料给报关行正式申报；送港线独立记录拖车、进港、甩柜和实际开船。费用确认不阻断排柜/装柜，装柜完成后对已装范围的当前有效已发布费用版本记录系统默认确认，来源和客户主动确认必须分开审计。
 - 前端页面、菜单和路由只能在对应服务端契约、权限和数据模型稳定后发布；原型中的完整 WMS、海外仓及未确认能力不属于国内货柜履约默认范围。
 
 ## 局部阻断项
@@ -27,3 +28,4 @@
 1. 先读 `README.md`、`国内货柜履约需求确认表.md` 和本文件，确认任务属于已确认范围。
 2. 再进入目标应用或服务的 `AGENTS.md`，按本地模块入口实现。
 3. 发现新的产品决策或门禁变化时，先更新确认表与本文，再更新受影响模块指引；不要将短期进度、联调故障或环境地址写回模块规则。
+

国内货柜履约/归档/国内货柜履约装柜闭环产品确认表-2026-08-08.md

@@ -1,5 +1,7 @@
 # 国内货柜履约装柜闭环产品确认表
 
+> **历史版本声明（2026-09-24）**：本文仅保留 2026-08-08 的原始讨论记录，其中“装柜完成即结束”和报关/离仓关系等内容已被当前流程替代。当前规则以 [头程到尾程流程节点梳理（重构版）](../../头程到尾程流程节点梳理.md)、[报关资料与船期价格接入梳理](../报关资料与船期价格接入梳理.md) 和最新需求确认表为准：`LOADED` 只表示物理装柜完成；正式报关在装柜完成后按最终实装清单执行，放行回执参与 `DEPARTED_WAREHOUSE` 离仓门禁。
+
 > 确认方式：产品只需在“产品确认”一列填写“同意”，或写明修改后的规则。  
 > 会议目标：本表确认后直接进入开发，不再补完整高保真原型。
 
@@ -64,3 +66,4 @@
 | 本次明确不做的内容 |  |
 | 产品确认人 |  |
 | 确认日期 |  |
+

国内货柜履约/归档/国内货柜履约装柜闭环开发前确认单-2026-08-08.md

@@ -1,5 +1,7 @@
 # 国内货柜履约装柜闭环开发前确认单
 
+> **历史版本声明（2026-09-24）**：本文是旧版“以 `LOADED` 作为国内履约终点”的开发前确认材料，旧规则已被本轮新流程替代。当前按三大业务块梳理；`LOADED` 只表示物理装柜完成，正式报关在装柜完成后按最终实装清单执行，放行回执、订舱、拖车和异常门禁用于推进 `DEPARTED_WAREHOUSE`。费用确认不阻断装柜，当前有效已发布费用版本在 `LOADED` 时按已装载范围默认确认。开发以 [头程到尾程流程节点梳理（重构版）](../../头程到尾程流程节点梳理.md)、[报关资料与船期价格接入梳理](../报关资料与船期价格接入梳理.md) 和当前确认记录为准。
+
 > 整理日期：2026-08-08  
 > 用途：产品、业务、仓库、研发在直接开发前确认最小闭环细节  
 > 当前建议：不补完整高保真原型，确认本清单后直接开发
@@ -144,3 +146,4 @@ DELIVERED / 海外仓已收货
 2. 更新 `国内货柜履约需求确认表.md` 中对应的 P3-Q2/P3-Q4/P3-Q5/P3-Q6/P3-Q10/P3-Q11/P3-Q12。
 3. 明确是否允许按“服务端门禁 -> PDA -> Admin -> 联调验收”的顺序直接开发。
 4. 将本清单作为接口、页面和测试验收的共同依据。
+

国内货柜履约/归档/国内货柜履约闭环审计报告-2026-08-08.md

@@ -1,5 +1,7 @@
 # 虫虫出海国内货柜履约闭环审计报告
 
+> **历史记录声明（2026-09-24）**：本文记录的是 2026-08-08 的旧口径和旧审计结论，不再作为当前流程或开发门禁依据。当前统一采用三大业务块和“装柜完成后正式报关”的新流程：`LOADED` 只确认物理装柜完成；装柜完成后按最终实装清单正式报送，取得有效回执/放行结果后，结合订舱、拖车和异常门禁推进 `DEPARTED_WAREHOUSE`。费用确认不阻断装柜，装柜完成时对当前有效已发布版本按已装载范围默认确认。当前规则以 [头程到尾程流程节点梳理（重构版）](../../头程到尾程流程节点梳理.md)、[报关资料与船期价格接入梳理](../报关资料与船期价格接入梳理.md) 和本轮确认记录为准。
+
 > 审计日期：2026-08-08
 > 审计范围：入库测量与计费终点→智能排柜→订舱→拖车→PDA 拣货→装柜/柜封证据→`LOADED`/装柜完成
 > 审计对象：Admin、Client、PDA、`baiyue-firstleg` 后端、OpenAPI/SQL、自动化测试与现有测试环境报告
@@ -239,3 +241,4 @@ PDA 已有调用拣货/证据/装柜接口的适配代码，但当前仍存在
 > **国内货柜履约已确认复用现有订单列表承载全部主状态，不新建出仓单，国内终点为 `LOADED`/装柜完成；已完成排柜/预装/PDA 拣货/装柜清单子链路，订舱和拖车 API 可用。但订单国内货柜履约统一编排、五张装柜照片与锁码文本硬门禁、报关协同、冲正、Client 协同和 PDA 真机仍未闭环，且国内手工推进 `DELIVERED` 的现有能力必须整改，当前不具备整期验收条件。**
 
 因此，现阶段不应标记“国内货柜履约完成”，应标记为“**子能力已实现，闭环整改中**”。
+

国内货柜履约/归档/国内货柜履约验收任务拆分与待确认清单.md

@@ -12,9 +12,9 @@
 | 五类装柜证据 | 空仓、半仓、满仓、锁仓、带锁码照均上传真实文件并按客户/柜次绑定 | `phase3-loading.mjs` |
 | 同类型多图 | 同一证据类型追加第二张真实图片，原记录与新增记录同时保持有效 | `phase3-loading.mjs` |
 | 锁码门禁 | 缺少锁码照片或锁码文本为空时，完成装柜请求被拒绝 | `phase3-loading.mjs` |
-| 统一装柜门禁 | 订舱未完成、拖车未完成、报关无有效放行回执、PDA 未完成或五类证据不完整时，真实 `LOADED` 请求均被拒绝 | `service-center-flow.mjs` / `phase3-loading.mjs` |
+| 统一装柜门禁 | 真实柜号缺失、PDA 未完成、数量不守恒或五类证据不完整时，真实 `LOADED` 请求被拒绝；`LOADED` 后分别验收客户报关回执确认闭环和送港/进港/甩柜事实，任何一条线都不反向阻断物理装柜 | `service-center-flow.mjs` / `phase3-loading.mjs` |
 | 订单/柜次聚合 | 一单多柜、一个柜多订单、父子订单数量分摊及未装数量自动生成子订单可追溯 | `phase3-order-aggregate.mjs`（待补） |
-| 出仓后船节点查询 | 已重新归入海外仓业务，不属于国内货柜履约验收 | 海外仓业务沿用现有 `CarrierScheduleQuery` 设计验收入口，不再补 `phase3-vessel-tracking.mjs` |
+| 实际开船后船节点查询 | 只有承运船舶真实开航后才进入海运节点；送港、进港和甩柜属于国内货柜履约并行线 | 海外仓业务沿用现有 `CarrierScheduleQuery` 设计验收入口，不再用预计 ETD 或 `DEPARTED_WAREHOUSE` 提前推进海运 |
 | 仓库角色 | 操作员、拣货员、理货员初始化、最小权限和跨客户隔离 | `phase3-role-contract.mjs`（待补） |
 | 伪造与交叉归属 | 不存在 `fileId`、其他证据类型的 `fileId` 不能绑定 | `phase3-loading.mjs` |
 
@@ -33,3 +33,4 @@
 4. `P3-ACCEPT-PDA-RELEASE`：按既定 uni-app 在线更新安排完成发布与真机验收。
 
 每个任务完成后，必须把真实请求、响应状态、业务码、`requestId/traceId` 写入报告，并删除对应 coverageGap；不得以 mock 或数据库直写替代接口验收。
+

国内货柜履约/归档/货柜履约原型字段验收矩阵-2026-08-17.md

@@ -42,3 +42,4 @@
 - `phase3-container-loading` 对 ACTIVE 货柜、预装清单和完成装柜清单执行字段断言。
 - `ocean-bookings`、`phase3-port-schedules`、`truck-appointments`、`phase3-customs`、`phase3-outbound-dispatch` 在既有本轮资源响应上执行字段断言，不增加历史查询或伪造回退。
 - 默认 Admin 全量入口已包含上述生产模块；真实 HTTP 仅在测试环境重新部署且当前对话明确授权后执行。
+

国内货柜履约/归档/货柜管理全链验收矩阵-2026-08-13.md

@@ -219,3 +219,4 @@
 | 全量编排 | 默认入口先运行 `phase3-container-loading` 完成“模拟柜新增 -> 同仓同渠道排货 -> 首次 link -> PDA”，再由证据、finalize、出仓模块沿本轮 marker 的稳定 ID 继续；禁止历史数据和 mock 回退 | Node 入口合同已锁定，待默认全量 HTTP 验证 |
 
 离线合同：`container-simulation-association-contract.test.mjs` 锁定跨层契约及全量顺序；`phase3-producer-chain-contract.test.mjs`、`phase3-order-splitting-contract.test.mjs`、`ocean-booking-channel-contract.test.mjs` 锁定生产者只使用 DRAFT/RELEASED、需求关联且不在订舱阶段自动建柜。
+

国内货柜履约/报关资料与船期价格接入梳理.md

@@ -0,0 +1,207 @@
+# 报关资料与船期价格接入梳理
+
+> **当前用途：报关与船期价格专题参考。** 报关流程已经确认，第一批代码和页面已经接入测试环境；开发交接看[报关代码开发交接清单](../头程到尾程/报关代码开发交接清单.md)。主流程和节点关系以[头程到尾程流程节点梳理](../头程到尾程流程节点梳理.md)为准；本文保留资料字段、回执轮次、价格口径和接口查找信息。
+>
+> 文中“目标、实施顺序、进入条件、待确认事项”等段落属于原评审记录。开发已经完成后，不再据此重新拆开发任务；若与当前确认不一致，以总览和最新业务确认修正对应专题段落。
+
+本文是企业客户端“报关资料”“船期价格”入口的专题评审记录。当前使用时只取已确认的流程、资料和价格口径；“建议”和“待确认”保留为历史评审痕迹，不再自动生成开发任务或验收门禁。
+
+**当前基线**：以最新用户确认和[头程到尾程流程节点梳理](../头程到尾程流程节点梳理.md)为准。旧版需求表、README、开发规划和本文件中的历史建议若发生冲突，先在当前入口记录收尾变更，再决定是否需要修改专题细节。
+
+**当前实现快照（2026-09-29）**：两份文件链路已经落到平台、客户和 Firstleg 报关接口，客户端“报关资料”和“船期价格”也已经作为独立模块接入导航和路由。客户资料、报关行回执、客户整份回执确认/打回、平台发送报关行执行、真实报关完税文件分别保存并受版本门禁控制。回执发送给报关行后不可再替换；只有包含退税货物的柜才允许走发送执行接口；全买单柜仍走平台直接完成。`brokerSubmittedAt` 只表示发送执行时间，不表示报关完成。PDA 只负责产生 `LOADED` 前置事实，报关验收不创建或操作 PDA 任务；船期、甩柜和改配只修改原柜运输信息，不重置报关资料和确认结果。
+
+## 客户报关资料菜单待办红标
+
+- 侧栏“报关资料”在文字右侧显示红底白字数量，白色描边；无待办时隐藏，超过99显示“99+”。承载依据为客户提供的菜单截图，菜单入口和资料弹框保持原承载方式。
+- 数量按当前客户需要处理的**柜次去重**：最新实际装柜的退税货物尚缺本客户有效资料，或者报关中本客户冻结资料的当前回执待确认（PENDING）。同柜多个入仓码、多份回执合计1个红标待办；已确认、已打回等待平台重做、已完成及同柜其他客户的待办不计入。
+- `GET /api/merchant/v1/customs/pending-summary` 由Firstleg只读聚合返回`pendingCount`，客户范围来自认证上下文，读取权限`merchant:order:view`；复用现有网关customs路由，不在侧栏逐票加载报关详情或创建报关记录。计数与订单列表“上传资料”的订单数不是同一单位，不能相互替代。
+- 首次进入工作台、页面可见时每60秒、窗口重新获得焦点、报关资料刷新及资料操作后重新查询。刷新期间保留已确认数值；失败显示红色“!”并说明数量加载失败，不把失败显示成零。退出或失去菜单权限立即清空，旧会话响应不能写入新会话。
+
+| 页面/操作 | 原型依据与承载 | 实现 |
+|---|---|---|
+| 报关资料菜单红标 | 用户提供菜单截图，文字右侧圆形红色数量 | 真实待办数、白描边、同柜去重；不添加新弹框 |
+| 资料处理后更新 | 原有上传、覆盖范围、删除及回执确认/打回操作 | 查询最新待办数，不在浏览器自行减1 |
+
+## 当前差异与下一步
+
+当前主流程和代码的关系已经收敛：F01-F24（国内头程、报关、待发区、送港、进港、甩柜和实际开航）有最新真实 HTTP 证据；F25-F40（目的港、海外入库、库存、出库、派送和最终回写）已有综合真实 HTTP 证据和页面实现。客户端两个独立模块、订单快捷入口、平台整柜报关工作台和船期价格查询均已接入，不需要再按“新增页面”拆任务。
+
+2026-09-29 的最新综合 F01-F40 验收报告为 `baiyue-firstleg/reports/fba-full-current-20260929.json`。报告前段业务链大量通过，但尾程和海外 PDA 产生了环境型阻断：`test-api-overseas.buggoglobal.com` 当时 DNS 不可解析，后续请求均为 `fetch failed`，因此这份报告不能作为全流程全绿结论，也不能据此判断报关或船期代码失败。此前报关专项 `customs-current-20260928.json`（543/543）和运输专项 `transport-current-20260929.json`（1036/1036）仍是当前可复用的绿色证据。
+
+当前状态分为三类任务：
+
+1. **规则已简化并确认**：不维护资料类型清单，也不区分逐项责任人；客户或平台只要在资料包上传文件即可。查验、扣货、补资料均由平台人工标记异常，选择预设理由；选择“其他”时填写备注即可，不要求接入短信或自动海关系统。
+2. **环境/外部验收**：恢复海外测试域名解析后重新跑 F25-F40；COSCO 官方接口凭据、COSCO 动态页面和 ZIM hCaptcha 仍是外部非阻断项；Android/HBuilderX 真机扫码、弱网和在线草稿仍需现场设备验收。
+3. **后续增强**：报关行接收回执/回执轮次和下载凭证仍可增强，但不影响当前两份文件闭环、客户确认、正式申报和报关完成后进入待发区。
+4. **费用默认确认**：业务规则已经确认，但代码仍主要完成费用发布/客户确认；`LOADED` 时按已装范围写入 `SYSTEM_AUTO_AT_LOADED`、费用版本、柜次/入仓码和幂等审计的落地实现，仍需单独补齐，不能把 `SENT` 直接当成默认确认。
+
+你当前不需要先操作系统或确认代码。资料上传和异常人工处理规则已经足够继续开发；其余技术修复和重新验收由开发侧继续处理。
+
+## 先锁定的范围
+
+国内货柜履约的物理装柜节点为 `LOADED`。`LOADED` 后先完成退税客户的报关协同，报关完成后进入待发区，再推进船期运输：
+
+1. **报关线**：仅对退税客户通知报关行，收集退税客户资料，发送报关行，接收报关行回执并发客户确认；客户认为不正确时打回、重新上传、重新发送并生成新回执，循环至柜内退税客户均确认；全部确认后，再将退税申报资料提交报关行确认，由报关行正式申报，记录查验、不查验放行或其他海关结果。买单货物不进入这条资料和回执流程。
+2. **船期线**：报关完成并进入待发区后，安排拖车、从仓库发运、送港、进港；港口容量不足时记录甩柜和改配船次。甩柜/改配只改变运输船次，不重新处理已完成的报关资料、回执和客户确认；`PORT_RECEIVED` 不等于海运中，只有船舶真实开航后才进入海运节点。
+
+报关完成是进入待发区的前置；进入待发区后才推进船期运输。首期不对接海关单一窗口或报关代理系统：报关行回执以文件上传为主，正式申报由授权人员人工提交，客户确认和海关结果由平台人工记录。
+
+费用确认是并行事实，不阻断排柜、预装、PDA 或装柜。装柜完成后，对应已实装范围若客户仍未确认当前有效且已发布费用版本，系统记录“系统默认确认（装柜完成）”；不伪造客户点击，保留 `SYSTEM_AUTO_AT_LOADED` 来源、费用版本、柜次/入仓码、时间和幂等标识。没有有效费用版本时不得生成零额或伪造确认，须保留费用异常待办。
+
+实际装船、提单、舱单、结关、退税正式资料和船公司节点查询仍属于跨服务或外部业务事实；当前国内货柜链已实现本柜船期编辑、送港、进港和实际开航节点，外部船公司自动查询以及更复杂的提单/舱单凭证继续按独立来源和只读快照接入。若国内页面需要展示，只能消费已确认的跨服务只读快照，并单独定义事件、来源、更新时间和责任边界。
+
+## 入口与权威数据
+
+| 入口 | 本期职责 | 权威数据 | 当前状态 |
+|---|---|---|---|
+| 客户端“报关资料” | `LOADED` 后查看本企业资料包，上传/替换/补件，查看报关行回执并确认或打回 | Firstleg 报关协同；文件由 File 服务保存 | **已实现：独立入口 + 订单快捷入口** |
+| 订单中的“上传资料” | 带订单和入仓码上下文进入同一资料包 | 与独立入口共用 packageId 和接口 | **现有快捷入口** |
+| 平台整柜报关工作台 | 按实际装柜清单通知报关行，管理客户资料、回执轮次、全部确认、整柜正式提交和海关结果 | Firstleg 柜级报关、提交批次和结果事实 | **已实现：四态 + 独立正式申报/海关结果投影** |
+| 客户端“船期价格” | 查询当前企业可见的有效渠道、参考船期、最晚进仓、参考时效和估价 | 生效价格簿及服务端估价 | **已实现：独立入口** |
+| 平台“船期价格表” | 上传、解析、核对、发布公共或客户专属价格簿 | Firstleg 价格簿版本 | **已有平台能力** |
+
+平台端应写“按申报组整理并线下提交”。在跨客户合并规则确认前，默认禁止把不同客户放入同一正式报关单；不得在结论表中把待决规则写成既定能力。
+
+## 当前实现事实
+
+1. 客户端现在同时提供独立“报关资料”入口和订单快捷入口，二者共用同一资料包和版本历史；仅对 `LOADED` 后的退税订单开放，按客户/入仓码收集资料、接收报关行回执、提交客户确认并支持打回重做。资料可上传、替换、改关联、删除并保留版本；每轮发送和回执都留痕，客户确认后才进入该客户的 `CUSTOMER_CONFIRMED`。对应接口和权限见 [customs-v1.yaml](../../baiyue-firstleg/firstleg/src/main/resources/openapi/customs-v1.yaml#L48)。
+2. 当前柜级状态为 WAITING_CUSTOMER_DOCUMENTS → READY_TO_START → DECLARING → COMPLETED；客户确认轮次、首次发送批次、整柜正式提交、查验/放行和送港子状态通过独立事实和只读投影承载。资料关联以 loadingPlanId、柜级聚合、客户报关案例和整票入仓码为根。
+3. 当前 COMPLETED 会发布报关完成事件并参与待发区门禁。契约将“客户资料确认轮次”“整柜正式提交”“海关查验/放行”分开；报关完成后才允许进入待发区，船期事实独立维护。
+4. 全买单柜已有独立的二次确认接口和导出契约；它不创建退税客户资料、回执和确认案例，运输节点仍按装柜、待发区、送港和开船事实推进。
+5. 客户端现有价格接口为按起运仓查询渠道，以及按指定渠道估算参考费用。/estimate 只返回基础参考费用，不含复杂附加费和最终结算调整；pricingTaxMode 不等同于订单 taxMode。见 [fba-pricing-v1.yaml](../../baiyue-firstleg/firstleg/src/main/resources/openapi/fba-pricing-v1.yaml#L130)。
+6. 原型文档仍有“待原型/部分参考”的历史表述，但当前页面已按现行契约接入；页面范围以客户端路由、平台报关工作台和当前 OpenAPI 为准，不再把原型中的待建入口当作开发缺口。
+
+7. **费用默认确认目前是目标变更，不是现有实现。** 当前装柜完成逻辑只会自动发送/发布费用，不能把 `SENT` 直接当成客户确认；现有费用锁定也主要依赖客户确认时间。实现本轮目标时必须增加确认来源和幂等审计，并改为“客户确认或装柜默认确认 + 已装柜完成后才最终锁定”。部分装载只能确认本次已装范围，余量不能被顺手确认。
+
+8. **本轮报关完成→待发区门禁和船期例外需要保持独立。** 报关完成后才允许进入待发区；`ROLLED_OVER` 只记录新旧船次和运输变更，不回退或重新评估已完成的报关资料、回执和客户确认。
+
+## 报关资料模型
+
+### 0. `LOADED` 后报关完成与待发区
+
+| 线路 | 触发时点 | 顺序 | 结果 |
+|---|---|---|---|
+| 报关线 | `LOADED` 事件产生后 | 通知报关行 → 收集每个客户资料 → 发报关行 → 接收回执 → 发客户确认 → 打回则重传重发并生成新回执 → 所有客户确认 → 整柜资料交报关行确认 → 正式申报 → 查验/放行 | 客户确认轮次、整柜正式申报、海关结果 |
+| 送港线 | 报关完成并进入待发区后 | 安排拖车 → 仓库离开 → 送港 → 进港 → 等待船次；装不下时在原柜船期上人工修改船信息并留痕 | `DEPARTED_WAREHOUSE`、`PORT_RECEIVED`、`ROLLED_OVER`、实际开船 |
+
+报关资料未完成时不得进入待发区；完成报关并进入待发区后才推进送港。已进港也不代表已经进入海运；只有船舶真实开航后，才写入海运起点。
+
+客户确认是每个客户报关案例的完成条件；海关放行是整柜正式申报后的外部结果，不能用上传回执或任意“完成文件”代替。
+
+### 1. 客户报关案例与资料包
+
+报关资料主流程在 `LOADED` 后启动。每个客户/入仓码在本柜建立一个 `customerCustomsCase`，再挂载稳定的 `packageId` 和文件版本。首期不定义文件类型清单和逐项责任人；资料包只需支持文件上传、替换、版本、报关行发送时间、回执文件版本、客户确认/打回人和时间、打回原因、当前 `roundNo`、客户可见范围和审计记录。
+
+资料包不能只关联整票入仓码。已确认支持一单多柜、拆批和父订单—子订单关系，因此每个关联项保存客户、订单、入仓码和装柜明细引用；部分装柜只展示本柜实际箱数并标记线下处理，不在系统内自动做数量分摊。柜次一旦装柜完成不因甩柜改船而变化，受影响案例不能静默重置回执轮次。
+
+### 2. 实际装柜绑定快照
+
+资料包与 loadingPlanId、containerBookingId 的关系应通过绑定记录表达，而不是覆盖原资料包。绑定记录至少保存实际装柜明细引用、实装箱数、客户、订单、入仓码、柜次和绑定版本。`LOADED` 后开始本轮报关时冻结该范围；部分装柜只生成箱数展示和线下处理标记，甩柜改船不使资料绑定和回执轮次失效。
+
+### 3. 申报组与柜级总览
+
+申报组归属一次实际装柜和一次整柜正式提交，记录成员客户案例、合并关系、报关代理、每轮回执、客户确认结果、正式提交时间、正式业务编号、查验/放行结果和异常历史。跨客户合并在业务确认前默认拒绝；若未来开放，必须增加授权、客户可见投影、组成员冻结快照和取消/重组规则。
+
+柜级总览仅供平台使用，汇总实际装柜行、退税/买单行、缺件、提交批次和门禁结果。客户端接口必须按当前企业裁剪返回，不返回同柜其他客户的名称、数量、资料包 ID、申报组 ID 或异常细节。
+
+### 4. 买单、退税和混合柜完成条件
+
+三类柜不能用一条“缺回执即阻断”的规则代替：
+
+| 柜型 | `LOADED` 前 | `LOADED` 后报关线 | 完成条件与开船影响 |
+|---|---|---|---|
+| 全买单 | 装柜物理门禁独立判断 | 不进入本报关资料、报关行回执和客户确认流程；继续按买单装柜、导出和运输节点处理 | 不创建退税报关案例，不以报关资料或回执作为门禁 |
+| 退税柜 | 装柜物理门禁独立判断 | 对每个参与入仓码收集/补件，发送报关行，逐份接收回执并让对应客户确认；打回则重做当前案例 | 所有退税客户案例确认后才允许整柜正式提交；正式申报后的查验/放行单独记录 |
+| 混合柜 | 装柜物理门禁独立判断 | 仅退税行建立报关资料和回执确认案例；买单行不进入该流程，仍保留买单装柜和导出事实 | 仅退税客户案例全部确认后才允许提交退税申报批次；不得把买单明细冒充报关确认 |
+
+同一客户多个入仓码可以共享其授权资料；跨客户物理拼柜不等于允许跨客户正式合报。跨客户合并仍默认禁止，必须有独立授权和客户可见隔离契约。
+
+## 状态、事实与门禁
+
+建议把状态拆成独立事实面，页面总状态只做投影：
+
+| 事实面 | 建议状态 | 说明 |
+|---|---|---|
+| 客户报关案例 | WAITING_DOCUMENTS、SENT_TO_BROKER、RECEIPT_PENDING_CUSTOMER_CONFIRM、CUSTOMER_CONFIRMED、NEEDS_RESUBMIT、INVALIDATED | 每轮 `roundNo` 保存资料版本、发送时间、报关行回执、客户确认/打回原因；回执上传不等于客户确认 |
+| 整柜申报批次 | WAITING_ALL_CUSTOMER_CONFIRM、ALL_CUSTOMERS_CONFIRMED、FORMAL_SUBMITTED_TO_BROKER、DECLARED、INSPECTION、NO_INSPECTION、RELEASED、REJECTED | 所有客户案例确认后才允许整柜正式提交；首期由授权人员人工记录报关行确认和海关结果 |
+| 送港/船期事实 | PORT_DELIVERY_PENDING、DEPARTED_WAREHOUSE、IN_TRANSIT_TO_PORT、PORT_RECEIVED、ROLLED_OVER、VESSEL_DEPARTED | 与报关案例独立；进港和甩柜不等于海运中，只有真实开船才进入海运节点 |
+| 装柜门禁 | PASS/BLOCKED | 只判断是否满足 LOADED 的已确认前置 |
+
+上述是首期状态投影。回执首期以文件为主、客户确认整份回执；正式申报由平台授权人员人工提交并回填结果；查验、扣货、补资料和其他情况均由平台人工点击标记异常、选择理由，选择“其他”时填写备注；异常解除也由平台人工点击处理。实际开航首期人工录入，甩柜/改配人工修改原柜船信息并保留原报关事实，不重新评估申报批次。当前四态不能直接承担新流程；收敛时应明确旧状态的映射和删除时点，不保留双协议。
+
+物理 `LOADED` 门禁必须明确校验以下事实：
+
+1. 真实柜号、预装计划和数量版本完整；
+2. PDA 拣货和复核完成，整批提交成功；
+3. 空仓、半仓、满仓、锁仓、带锁码照五类证据各有至少一张有效照片，锁码文本已保存；
+4. 数量守恒、无未解决 PDA 异常。
+
+`LOADED` 后创建报关案例；报关案例完成整柜正式申报并达到报关完成条件后，才允许进入待发区并创建/推进送港任务。送港任务继续校验装柜完成、真实柜号、订舱/拖车等运输条件。到港后如船舱不足记录 `ROLLED_OVER`；只有实际 `VESSEL_DEPARTED` 才进入海运节点。报关放行、送港和甩柜不能反向作为 `LOADED` 的前置，甩柜也不改变已完成的报关事实。
+
+每个写动作都需要 Idempotency-Key、expectedVersion、规范化请求哈希、乐观锁冲突码、审计事件和结果回放。上传、替换、改关联、补件、审核、提交批次、回执上传和门禁确认不得仅靠前端推进。
+
+## 权限、文件与接口边界
+
+现有报关接口使用 merchant:order:view/edit 和 platform:firstleg:customs:list/manage。新增独立入口前必须确认是复用还是拆分为报关专用权限，并落到客户端路由、导航、Controller、OpenAPI x-permission、IAM 初始化 SQL 和服务端对象级校验：
+
+- 客户查看、上传/替换、补件确认和下载分别校验当前企业、订单/子订单、入仓明细和客户可见标记；不能信任请求中的 tenantId、订单 ID 或入仓码。
+- 平台查看、审核/退回、生成提交批次、上传回执和发布结果分别授权；列表权限只包含详情只读，写权限独立。
+- File 文件类型、业务 ID、客户归属、版本、冻结和下载审计必须定义。现有 `LOADING_LIST_CUSTOMS_SOURCE`、`LOADING_LIST_CUSTOMS_RECEIPT`、`LOADING_LIST_CUSTOMS_RESULT` 只负责不可变文件对象，不能替代客户案例、提交批次和海关结果对象；正式申报与海关结果的独立接入见[专题设计](../头程到尾程/正式申报与海关结果接入设计.md)。
+- File 上传成功但业务写入失败、业务写入成功但 File 失败、替换/作废和重试都要有补偿或可重放规则；不能产生越权文件或孤儿记录。
+
+独立客户列表、详情、待办计数和平台筛选必须补充明确的路径、分页、稳定排序、筛选参数、空态/无权限响应和错误码。不能只写“新增列表”或继续复用单订单查询接口。
+
+## 船期价格接入
+
+### 展示边界
+
+客户页只展示当前企业可见的有效价格簿快照：渠道、起运仓、目的地、pricingTaxMode、计费单位、单价、币种、参考船期、最晚进仓、参考时效、附加费说明、价格簿版本和更新时间。价格簿中的预计船期是参考文本，不是已订舱 ETD、实际开船或到港节点；时区、有效期、来源和过期展示必须明确。
+
+客户专属与公共价格按版本作用域选择：先选择当前企业专属 ACTIVE 版本；只有不存在专属 ACTIVE 版本时才选择公共 ACTIVE 版本，不能按单条费率缺行再逐行回退。页面展示业务版本号或生效时间，不直接把内部 priceBookVersionId 当作用户可见编号。
+
+### 批量估价契约
+
+若要跨渠道列表展示，服务端新增批量估价契约，至少定义：起运仓、目的类型/目的地、渠道候选、重量、体积、pricingTaxMode、版本快照、批量上限、超时、无命中错误、计费量、单位、币种、基础金额、未包含附加费、舍入规则和排序规则。不得由浏览器自行计算或逐渠道扇出。
+
+“价格优选”只有在币种、目的地、税模式、计费口径和附加费范围可比时才允许启用；否则只展示参考结果。订单创建时必须重新校验渠道资格和生效版本，明确旧报价失效、金额变化和重新报价的用户提示，不把客户端显示金额当成最终结算金额。
+
+价格导出如需上线，应另定义客户可见字段、公共/专属价格隔离、导出审计、快照版本、文件保留期限和下载权限；在这些规则确认前不纳入本期上线。
+
+## 实施顺序与进入条件
+
+1. **冻结业务规则**：确认文件可上传即可、回执轮次、打回重做、所有客户确认、整柜正式申报、异常理由/备注、甩柜/改配和跨客户合并；已确认规则以[需求确认表](国内货柜履约需求确认表.md#L24)为准。
+2. **先做服务端契约**：完成 customerCustomsCase、资料版本、报关行回执轮次、客户确认、整柜申报批次、送港/进港/甩柜/开船事实、状态投影、权限、幂等、审计、File 类别和初始化 SQL；同步更新 OpenAPI、Gateway、IAM 和相关消费者。
+3. **接入客户入口**：独立列表/详情与订单快捷入口共用 packageId；仅在 `LOADED` 后进入本柜报关案例，覆盖资料上传、报关行回执查看、确认、打回、重新上传和新回执版本。
+4. **接入平台协同**：`LOADED` 后按最终实装快照通知报关行，逐客户处理资料和回执，全部客户确认后提交整柜资料；平台人工记录正式申报，并通过异常节点选择查验、扣货、补资料或其他理由，必要时填写备注和处理结果。送港线独立接入拖车、进港、甩柜和实际开船。
+5. **接入船期价格**：先复用有效价格簿和单渠道参考估价，再实现批量估价；批量列表、排序和导出必须先通过接口和价格可比性评审。
+
+## 已确认的简化规则
+
+| 问题 | 阻断范围 | 需要形成的结论 |
+|---|---|---|
+| 报关资料上传 | 客户案例、整柜提交 | 不区分文件类型；有文件即可上传、替换和保留版本 |
+| 客户确认/打回原因和回执轮次 | 客户案例、整柜提交 | 回执版本、roundNo、确认人、打回重做规则 |
+| 海关查验、扣货、补资料和其他异常 | 整柜申报批次、客户展示 | 平台人工标记异常并选择理由；选择“其他”时填写备注，不接短信或自动海关系统 |
+| 送港、进港、甩柜、改配船次和实际开船事件 | 待发区、送港线、海运节点 | 事实字段、重试规则、客户通知和船次历史；首期人工录入实际开航，改配人工修改原柜船信息但不改变已完成报关事实 |
+| 价格比较、导出、报价有效期和金额变化提示 | 客户报价页、下单 | 统一币种/税模式/附加费和失效处理 |
+
+## 最低验收矩阵
+
+- 客户 A 无法查询、上传、替换或下载客户 B 的资料、回执、价格和导出文件。
+- 独立入口与订单快捷入口返回同一 packageId、版本历史和待办结果，不产生双历史。
+- 同一幂等键同请求只产生一次记录；同键不同请求、版本冲突、并发换柜和重复回执均返回明确业务错误。
+- `LOADED` 后每个客户案例都能经历“资料上传→报关行回执→客户确认”；打回后只重开对应案例，重新上传、重新发送并产生新回执轮次，其他客户历史不被覆盖。
+- 所有客户案例均 `CUSTOMER_CONFIRMED` 后，平台才允许生成整柜正式提交；正式提交后分别验收查验、不查验放行和其他海关结果。
+- 缺 PDA 结果、缺五类证据、真实柜号或数量不守恒时，`LOADED` 门禁失败；报关完成后才进入待发区，再验收离仓、进港和甩柜；只有真实开船才进入海运节点，甩柜不重做已完成报关。
+- 全买单柜、退税柜和混合柜分别验证状态、权限、导出、回执和门禁结果。
+- 价格无命中、失效版本、跨渠道批量估价、不同币种/税模式、附加费说明和订单创建重验均有可验证结果。
+- 页面覆盖加载、空态、失败、无权限、过期和数据冲突；客户端按 1920×1080、100% 缩放人工验收。
+
+## 接入核对入口
+
+- 客户端订单与现有报关：apps/client-web/src/modules/first-leg/routes.ts、views/FirstLegOrdersView.vue、components/CustomsDocumentsDialog.vue、api/customs.ts。
+- 客户端导航和新页面：apps/client-web/src/navigation/clientNavigation.ts 及对应页面注册、权限和 release 配置。
+- 平台整柜报关：apps/admin-web/src/modules/container-loading/components/ContainerCustomsPanel.vue、api/platformContainerCustoms.ts。
+- 后端报关：`../baiyue-firstleg/firstleg/src/main/java/com/baiyue/firstleg/customs/container/`、[customs-v1.yaml](../../baiyue-firstleg/firstleg/src/main/resources/openapi/customs-v1.yaml#L1)、`phase3-container-customs-schema.sql`。
+- 报价：`../apps/client-web/src/modules/first-leg/api/firstLeg.ts`、`../apps/admin-web/src/modules/fba-pricing/carrier-rates/`、[fba-pricing-v1.yaml](../../baiyue-firstleg/firstleg/src/main/resources/openapi/fba-pricing-v1.yaml#L130)。
+- 国内边界、状态和门禁：[国内货柜履约 README](README.md:3)、[国内货柜履约开发规划（归档）](归档/国内货柜履约开发规划.md:166)、[国内货柜履约需求确认表](国内货柜履约需求确认表.md:24)。

国内货柜履约/船期日历功能规划.md

@@ -0,0 +1,672 @@
+# 船期日历功能规划
+
+> 文档状态：首版开发规划；2026-09-27 复核补充了数据闭环规则。本文是开发依据，不是代码完成或上线验收证明。
+> 规划对象：Admin「国内头程 → 船期管理」独立船期日历。
+> 目标：支持人工维护渠道和船期规律，按周或单次生成具体船期，并按渠道/船期查看收货体积。
+
+> **当前展示版范围已重新冻结：只做船期维护和只读展示，不做自动归班、不消费预报、不改写收货审核、不自动改绑，也不改变现有智能排柜流程。** 首版只需要让管理人员看到每个航次的已收/预计货量、可用容量、按柜型初算的建议柜数、已订柜和待补柜，并据此人工判断是否合并到其他船。后续若要增加货物归班，再单独立项评审。第 15.8 节覆盖本文此前关于自动归班和异常改配的旧口径。
+
+> **展示版统计口径**：日历仅展示上海时区今天及以后开船的计划。未离仓审核实测货量优先保留有效订舱和排柜对应的船期，未安排或原安排失效的余量按“收货仓 + 渠道”展示在最近一班尚未截仓的有效船期；各船期继续展示自身起运港和目的港。顺延只改变日历货量和订柜参考，不创建或变更船期归班、订舱或排柜事实。订柜数按统一柜型容量向上取整，已离仓柜的容量不再抵扣余货需求，最终以现有智能排柜和人工确认结果为准，详细规则以第 15.8 节为准。
+
+## 1. 输入来源与现状边界
+
+本规划以当前需求描述为业务输入，以用户提供的截图作为页面布局参考。截图中的红框、日期、船名、航次、数量和示例数据均不构成额外指令，也不代表需要沿用的真实业务数据。
+
+仓库当前已有 `apps/admin-web/src/modules/port-schedules/` 和 Firstleg 的 `portschedule` 服务。现有“港务船期”记录绑定客户、订舱或柜次，主要保存船公司/码头/API 的船期观测、过期时间和海运节点查询结果；对应表为 `fl_port_schedule`。它服务于已存在的订舱和货柜履约链路，不直接承载本规划的排班模板、周循环生成或收货量统计。现有 `port-schedules/routes.ts` 也不是本规划新页面的正式入口；新日历应作为独立 Admin 页面、路由和权限接入，不能把现有隐藏/嵌入式船期组件直接改成排班管理页。
+
+本功能建议新增“船期计划”域，与现有港务船期并列：
+
+- 船期计划是运营人员提前安排“哪个渠道哪天开哪班船”，可以没有订舱和真实柜次；价格簿中的参考船期、最晚进仓和参考时效也不能直接当作该计划的实际开船事实。
+- 港务船期是某个订舱/柜次的外部船期事实或人工观测，继续按现有接口和状态机运行。
+- V1 先建立“计划实例 ↔ RELEASED 订舱”的最小关联用于订柜统计；真实柜次、港务船期和海运节点的完整关联后置，不能用计划数据覆盖已产生的运输事实。
+
+本规划默认这是平台内部运营日历：渠道主数据平台级维护，模板和实例至少按收货仓隔离，实收汇总按“收货仓 + 渠道 + 收货日期”聚合并对平台运营人员可见。V1 不按客户拆分船期计划；如果实际业务存在客户专属船期或价格承诺，必须在开发前把客户作为模板、实例、查询和权限的正式维度，不能在上线后再用名称筛选补救。
+
+## 2. 要解决的问题
+
+运营人员需要在一个页面完成以下工作：
+
+1. 维护当前可售或可安排的运输渠道，例如“MATSON / 美森”。
+2. 配置固定每周哪几天有船，也可以只添加一班临时船期。
+3. 根据开船时间和渠道的提前收货天数，自动算出收货截止时间。
+4. 在月历上看到每天有几班船，以及每个渠道已收多少立方米、预计有多少货、容量还剩多少和建议订几个柜。
+5. 对已生成的具体船期进行编辑、取消、复制和查看关联货量，并保留变更历史。
+
+## 3. 建议的 V1 范围
+
+### 3.1 本轮纳入
+
+- 船期渠道的新增、编辑、启用/停用。
+- 一次性船期的手工添加。
+- 每周模板的配置，按指定周几生成未来具体船期。
+- 每条模板/实例必填收货仓；首版不使用“全部仓”这种模糊范围。
+- 开船时间、预计到港时间、收货截止时间和容量的维护与计算。
+- 月历视图、月份切换、按收货仓/起运港/渠道/船名航次筛选。
+- 选中日期的船期详情和渠道体积汇总。
+- 船期实例的人工编辑、取消、复制下一班和变更历史。
+- 货量按收货仓与渠道只读展示已收实测体积、预计体积、截止前参考量、截止后风险量、已订柜和待补柜；不产生归班事实、不提供货量改绑。
+- 按现有柜型目录计算只读的“建议订柜数”，不直接创建正式订舱或货柜。
+
+### 3.2 暂不纳入
+
+- 船公司官网或第三方 API 自动抓取船期。
+- 自动订舱、舱位分配、放舱、拖车、报关和实际出仓状态推进。
+- 自动归班、预报消费、实收批次绑定、取消后自动改配和异常重新安排。
+- 在收货审核、测量审核或智能排柜流程中增加回调、写入或阻断。
+- 复杂的价格计算、客户报价和财务结算。
+- 以计划日历替代现有订舱/柜次船期事实。
+- 在没有业务确认前自动修改历史入仓数据或批量回溯全部历史货量。
+- 复杂节假日规则、跨时区排班和通知中心；这些作为后续扩展点保留。
+- 容量预占、超容强制处理、正常货量的批量改绑和跨客户拆分；异常货的最小重新安排按第 6.10 节纳入 V1。
+
+## 4. 核心概念与生命周期
+
+| 对象 | 作用 | 关键生命周期 |
+| --- | --- | --- |
+| 渠道 Channel | 表示一类运输服务，如 MATSON / 美森 | `ACTIVE`、`INACTIVE` |
+| 船期模板 Schedule Template | 描述每周固定规律；固定添加一班直接创建实例，不再套一层单次模板 | `DRAFT`、`ACTIVE`、`INACTIVE` |
+| 船期实例 Sailing | 某一具体日期的某一班船，是日历和货量统计的主体 | `DRAFT`、`OPEN`、`CLOSED`、`DEPARTED`、`CANCELLED`、`COMPLETED` |
+| 归班事实 Sailing Assignment | 保存预计量/收货批次与船期的自动归班结果及历史 | `FORECAST_MATCHED`、`RECEIVED`、`LATE`、`UNMATCHED`、`SUPERSEDED` |
+| 订舱关联 Sailing Booking Link | 将已放舱订舱的柜型需求关联到计划船期，用于订柜建议 | `ACTIVE`、`REVOKED` |
+
+模板生成实例后，实例保存自己的船名、航次、港口、截仓时间和容量快照。以后修改模板不回写已经生成、已编辑或已关联货量的实例；需要调整时由运营人员编辑实例或重新生成未落地的未来实例。
+
+## 5. 页面信息架构
+
+### 5.1 顶部筛选和操作区
+
+- 月份：默认当前月，提供上月、下月和“今天”。
+- 收货仓：按仓库筛选；船期计划至少要绑定一个收货仓，不能只靠渠道和起运港推断。
+- 出发港：按港口代码和名称筛选。
+- 船期渠道：按启用渠道筛选，停用渠道仍可用于查询历史。
+- 船名/航次：模糊搜索。
+- 状态：全部、可收货、已截止、已取消、已开船、已完成。
+- 归班状态：全部、预计可赶船、已收、晚到、未安排；用于把“漏排或赶不上”的货量变成运营待办。
+- 操作：`新增船期`、`渠道与模板管理`。
+
+另设“待安排/异常货量”入口，集中展示当前权限和仓库/渠道范围内仍待处理的货物，显示实际收货日或预计到仓日、等待天数及异常原因。未安排记录没有开船日期，不强行放进某个开船月，也不混入月历主合计；切换月份不使这些待办消失。
+
+筛选条件应由服务端参与查询，不能先拉取整月全部记录后在浏览器本地拼装统计。
+
+### 5.2 月历区
+
+- 周一至周日为列，显示跨月日期但以浅色区分。
+- 每个日期格显示当天船期数量和航线摘要。
+- 摘要优先显示渠道名和收货体积，例如“美森 120 m³ / 200 m³”；渠道较多时显示前几项并提供“更多”。
+- 当前日期、选中日期、已截止日期、容量超限日期分别使用清晰但不依赖颜色的标签/图标表达。
+- 点击日期后，右侧详情区同步刷新；点击船期卡片可直接进入实例详情。
+
+### 5.3 选中日期详情区
+
+每个船期卡片至少展示：
+
+- 渠道、船名、航次和船期业务编号。
+- 起运港 → 目的港。
+- 预计开船、预计到港、最终收货截止时间。
+- 已收总量、本船可赶实收、预计可赶、晚到量、已订柜数、建议订柜数和待补柜数；各指标按第 6.6 节计算，已收总量不能直接当作可赶量。班次容量上限和剩余体积仅在已配置班次容量时展示，V1 不因容量不足自动改绑或强制拦截。
+- 当前状态和风险提示：已过截止、接近满舱、超过容量、已取消。
+- `编辑`、`复制为下一班`、`取消船期`、`查看货量明细`。
+
+删除仅适用于未开船、未关联任何货量的草稿/实例；有货量或已产生履约事实的实例只能取消，不能物理删除。
+
+### 5.4 新增/编辑弹窗
+
+弹窗提供两个明确入口：
+
+**按周添加**
+
+- 选择渠道、起运港、目的港。
+- 选择收货仓；同一渠道可按不同收货仓配置不同截止规则。
+- 选择一个或多个周几。
+- 选择开船时间、航程天数或预计到港时间。
+- 设置提前收货天数、有效起止日期和默认容量。
+- 设置船名固定值或船名规则；设置航次生成规则。
+- 选择未来生成范围（建议 4 / 8 / 12 周）。
+- 先预览将生成的实例，再确认批量生成。
+
+**固定添加一个**
+
+- 直接填写开船日期时间、船名、航次、起运港、目的港。
+- 填写或确认收货截止时间、预计到港时间、容量。
+- 保存为一条独立实例，可选关联一个模板作为来源。
+
+周模板中的船名是生成实例的默认值；船司确认后可逐班编辑船名、航次和截止时间。当前展示版编辑实例时保留已保存的绝对截止时间，切换到“按开船前 N 天”后才重新计算；规则快照和覆盖原因待后端契约补齐后再做完整留痕。
+
+### 5.5 区间汇总
+
+月历上方建议提供当前筛选范围的渠道汇总卡：已收实测 CBM、预计可赶 CBM、风险/未安排 CBM、已订柜数、建议订柜数、待补柜数、晚到批次数和船期数量。V1 卡片固定标明“按开船月”，收货月仅在详情和后续报表中使用；多班同渠道同日时仍按船期实例分开，不能只显示一个渠道总数。
+
+## 6. 业务规则
+
+### 6.1 收货截止时间
+
+首版把“收货截止时间”正式命名为**最晚到仓时间 `warehouseCutoffAt`**，表示货物最晚什么时候到达我司收货仓，和船公司的截单、截关、截港时间分开保存。默认公式：
+
+```text
+最晚到仓日期 = 预计开船本地日期 - 提前收货天数
+最晚到仓时间 = 收货仓截收时刻
+```
+
+- 计算使用仓库业务时区，V1 默认 `Asia/Shanghai`；接口统一传 ISO 8601 时间。
+- 计划截止计算只基于实例保存的计划 `etdAt`；后续实际开船时间属于订舱/船节点事实，不反向改写已经产生的收货归班。
+- “提前 N 天”首版固定按自然日计算；工作日和节假日规则放到后续工作日历阶段。
+- 若收货仓暂未配置截收时刻，首版按 18:00 默认并记录规则来源，不能由前端使用浏览器本地时刻隐式补齐。
+- 首版默认使用 `3` 个自然日和 `18:00`；这个默认值不是从截图推断的，而是初始运营参数，后续按试运行数据校准。
+- 单班页面允许选择提前 2/3/4 个自然日或自定义本班截止时间；当前展示版保存计算后的最终 `warehouseCutoffAt`，规则快照与覆盖原因审计字段待后端契约补齐后再启用，页面不宣称已完成服务端留痕。
+- 最终截止时间必须严格早于开船时间；开船时间、截止时间和容量的校验由服务端最终执行。
+- 时间边界统一到毫秒：实际/预计到仓时间等于截止时间视为准时；当前时间大于截止时间才停止新归班，不能由不同页面采用不同的 `<`、`<=` 判断。建议值由服务端计算并返回，前端只展示。
+- 是否跳过周末/节假日、节假日向前顺延几天，需要在产品确认后接入工作日历，不能由前端自行猜测。
+
+### 6.2 每周模板生成
+
+- 按模板有效期和周几生成具体日期，跨月日期仍属于实例，查询某月时按开船时间落入月份返回。
+- V1 采用“预览后手工确认生成”，不做后台滚动生成；页面默认未来 8 周，并提供未来 4/8/12 周快捷范围，生成范围由操作人确认后提交。
+- 生成请求必须幂等；同一模板、日期、航次规则只能生成一条有效实例。
+- 已编辑、已关联货量、已关闭、已开船或已完成的实例不被重新生成覆盖。
+- 发现相同日期/航次冲突时返回冲突清单，让用户选择跳过或进入实例处理，不能静默覆盖。
+- 模板停用只阻止未来生成，不删除历史实例。
+- V1 如遇某周停航或临时改船，允许在生成预览中跳过日期或生成后取消实例；节假日批量例外规则放到后续阶段。
+- 去重和冲突检查必须跨模板执行，至少按“收货仓 + 渠道代码 + ETD 本地日期时间 + 航次”判断，不能只用 `template_id + date` 作为唯一键。
+- 同一收货仓、渠道、起运港和目的港下，若多班船的 ETD 相同，V1 按不可变的 `sailing_no` 升序确定唯一归班；复杂的运营优先级后置。
+
+### 6.3 航次号和船名
+
+V1 支持固定值和“前缀 + ETD 本地日期”两种航次生成规则；每个生成实例允许人工覆盖航次。顺序号和按船名递增规则后置，避免首版因船公司编号规则不同而误生成正式航次。
+
+业务唯一性首版约束“收货仓 + 渠道代码 + 起运港 + 目的港 + ETD 本地日期时间 + 航次”；同一航次跨不同起运港可以存在，但不能在同一组合内重复。`sailing_no` 在实例创建时生成后保持不变，用于同一 ETD 的确定性排序；展示给用户的业务编号应为船期编号、船名和航次，不能回退显示数据库 ID。
+
+### 6.4 可赶船判断和人工改绑
+
+默认推荐某一入仓记录时，只允许候选实例同时满足：
+
+- 渠道、起运港和目的港匹配。
+- 状态为 `OPEN`，且当前时间未超过最终收货截止时间。
+- 后续启用容量控制时再校验未超过容量；V1 只展示已配置容量和超量提示，不因容量字段缺失阻断归班。无上限实例可明确标记为“不限舱位”。
+- 按“最早可开船”或产品确认的优先规则排序。
+
+超过截止时间时不能自动分配到该船期；容量不足在 V1 只显示明确预警，不阻断自动归班，也不能把预警状态伪装成已锁定舱位。任何已关闭、已取消或已开船的船期都不能作为新的自动归班候选。人工改绑必须记录操作者、原船期、新船期、时间和原因。
+
+建议把“预计归班”和“实际收货统计”分成两条事实：
+
+- 预计归班可使用入仓单的 `expectedArrivalAt`，只有预计到仓时间早于或等于最终截止时间，才标记为“预计可赶船”。没有预计到仓时间的记录进入“待确认”，不能凭渠道名称或创建时间猜测。
+- 实际统计使用已确认的实际收货时间和审核后的实测体积。已有计划归班的货实际到仓晚于截止时，保留原计划并标记“晚到风险”，不能自动塞到下一班。首次形成实收事实且从未归班的货，若仓库、正式渠道和航线明确，可首次自动选择仍开放且未过截止的最早匹配船期，同时校验实际到仓时间不晚于该船截止；无候选或资料不全则写入“未安排”。因取消、晚到而进入未安排的货不属于“从未归班”，须走第 6.10 节。
+- 同一收货批次只能有一个有效计划归班。自动匹配以收货仓、渠道、港口和最早可赶上的有效实例为条件；同一时间存在多班时，必须有固定排序规则。
+- 归班在入仓计划审核、预计到仓时间/渠道/仓库变化或实际收货确认时重新计算；船期取消时只新增一条 `UNMATCHED` 变更记录并标记待人工处理，不自动塞入下一班。船期仍为 `OPEN` 且尚未达到最终收货截止时间、没有锁班/订舱事实时允许动态重算。船期达到截止时间后冻结当前归班，即使实例仍显示为 `OPEN` 也不再自动换到下一班；截止前尚未匹配的对象才继续寻找后续可赶船。运营确认订舱、船期进入 `CLOSED` 或船期取消后的改配必须产生新的人工或明确改配记录。
+
+建议的状态落库规则是：预计匹配但尚未收货为 `FORECAST_MATCHED`；实际收货时间不晚于截止且有审核实测体积为 `RECEIVED`；实际收货晚于截止仍沿用原计划为 `LATE`；没有可解释的计划归班为 `UNMATCHED`；重新计算后被新结果替代的旧记录为 `SUPERSEDED`。这些状态首版必须持久化，详情中追溯匹配规则、时间、来源和被替代关系。
+
+首版自动归班采用“写入事实 + 版本化重算”：
+
+- 预计匹配、实际收货、晚到和未安排都写入归班事实，不能只在查询时临时计算。
+- 船期仍为 `OPEN` 且未锁班时，重新计算不覆盖旧记录，而是将旧记录标记 `SUPERSEDED` 并写入新版本。
+- 船期进入 `CLOSED` 或已确认订舱后，原归班结果保留；取消、甩柜或改配只新增变更记录，不静默改写历史。
+- V1 仅开放第 6.10 节的异常重新安排，来源记录为 `MANUAL`；正常货量的批量改绑、拆分分配和强制赶船后置。
+- 冻结的是船期归属，不是收货事实的数值。冻结后最终审核、复测、冲正仍更新事实版本及其统计值；原归属保留，不因数值变化自动换船。
+
+### 6.5 货量统计
+
+V1 建议至少将“已收体积”和“预计体积”分开；“预占体积”只有在确认需要锁定容量后再启用：
+
+- **已收体积**：入仓事实已达到产品确认的可计入状态，并有有效体积。
+- **预计体积**：按预计归班的未收货量单独展示，不直接计入“已收体积”，也不自动扣减容量，除非产品确认要按预计量锁舱。
+- **预占体积**：已明确锁定该船期但尚未形成收货事实的货量；V1 若不做预占则固定为 0。
+- **剩余体积**：配置容量上限时按 `容量上限 - 已收体积 - 预占体积` 计算；V1 未启用预占时预占值为 0，预计体积不扣减剩余容量；结果不得小于 0，无上限显示“—”。
+
+体积字段必须统一单位为 m³，并保存统计快照时间。V1 只统计明确达到“已收货”状态、且有正数 `actualVolumeCbm` 的收货批次；实测体积是后续作业的权威输入，申报体积仅作对比，计费体积不能冒充“已收体积”。当前 `inboundedAt` 会在多个入库流程节点写入，不能单独视为最终收货事实；V1 必须新增或正式暴露稳定的收货批次事实，不能把 `inboundedAt` 作为替代。取消、草稿、作废或不符合统计口径的记录不计入已收体积。拆批、复测和冲正均按收货批次版本守恒。
+
+### 6.5.1 V1 数据来源契约（必须一并实现）
+
+当前入仓模型已经有 `warehouseId`、`channelCode`、`expectedArrivalAt`、`actualVolumeCbm` 和测量审核状态，但没有稳定的收货批次 ID、实际收货时间和可靠的未收预计 CBM；现有 `originalVolumeCbm` 是客户申报值，不能作为预计可赶体积。首版必须补齐下面两类事实，不能在页面层临时拼接：
+
+| 事实 | V1 必须提供的字段 | 统计和归班规则 |
+| --- | --- | --- |
+| 收货批次事实 `ReceiptBatchFact` | `receiptBatchId`、`inboundId`、`receivingWarehouseId`、`channelCode`、起运港/目的港快照、`receivedAt`、`actualVolumeCbm`、最终测量批次 ID、审核状态、冲正/作废状态 | 仅 `RECEIVED/APPROVED` 且实测 CBM 大于 0 的批次计入已收；复测替换同一批次最新有效值，冲正/作废不重复计入 |
+| 未收货量预报 `InboundVolumeForecast` | `forecastId`、`inboundId` 或可收货批次键、收货仓/渠道/起运港/目的港、`expectedArrivalAt`、`forecastVolumeCbm`、来源、有效状态、版本和更新时间 | 只有有效状态、预计体积大于 0 且有 ETA 的预报可计入预计可赶量；不得使用 `originalVolumeCbm`、申报箱数或计费体积代替 |
+
+补充规则：
+
+- 当前系统没有上述稳定事实的部分，V1 必须由 Firstleg 提供正式的收货批次和货量预报服务事实；页面不直接读取入仓单分页拼装。没有可靠预报时允许只显示已收和风险，但应显示“未提供有效预报”及缺资料票数，不能把未知量写成“预计无货”。数据生产入口按第 6.5.2 节落地。
+- 预报和实收按明确的预报批次关联，不以同一 `inboundId` 就认定整票预报已收完。实收只替换其明确对应的预计批次；未到货部分保留独立有效预报，禁止用实测 CBM 直接减整票预计 CBM。具体拆批与复测规则见第 6.5.2 节。
+- 航线匹配优先使用入仓/预报事实中的起运港和目的港；事实缺失时，仅当启用渠道存在唯一的默认起运港/目的港映射，才使用该映射并保存 `route_source=CHANNEL_DEFAULT`。渠道没有唯一默认航线时进入 `UNMATCHED`/风险，不按目的仓名称或自由文本猜测。
+- 一票分批到仓时按批次统计；复测、冲正和作废必须以版本或状态替换旧值，并保留审计历史。
+- 收货仓、渠道或航线缺失时，批次/预报进入 `UNMATCHED` 或风险清单，不得按渠道名称、订单创建时间或目的地名称猜测。
+
+日历汇总应与右侧详情使用同一服务端统计口径，避免页面格子和详情卡片出现不同数字。建议由服务端按收货仓、渠道、船期、收货日聚合后一次返回；前端不得跨分页拉取入仓单再自行求和。超过容量时返回明确的 `overCapacity=true`，前端只负责展示。月历按开船日期展示班次，详情中应能展开实际收货日期和未安排/晚到记录，避免把“收货发生日”和“船期开船日”混为一个日期。
+
+日期维度固定为两种：月历落格使用 `etdAt` 的本地日期；已收体积明细保留收货批次的 `receivedAt` 日期。V1 月历默认按“开船月”汇总，并将归属该船期的已收实测体积展示在对应开船日；收货月只用于详情展开和后续报表，不参与首版月历主合计。没有稳定 `receivedAt` 的批次只能进入风险/未安排，不能回退使用 `inboundedAt`。月历主合计排除已取消实例；取消实例仍可查历史快照，当前货量进入独立异常待办，重新安排后只计入目标实例，不能在两班重复相加。
+
+### 6.5.2 事实产生、分批收货与预报替换
+
+- **实际收货来源**：仓库完成一批到货确认时生成稳定收货批次业务键，记录真实 `receivedAt`、仓库和对应箱/件范围；最终测量审核通过后，该批次的实测体积才能计入已收。到货确认和最终审核是两个独立条件，审核操作时间不能冒充实际到仓时间。到货待审核单列票数；体积未知显示“待测量”，不补成 0 m³。
+- **未收预报来源**：V1 推荐由运营在入仓详情的“货量预报”区域维护预计批次、预计到仓时间、预计 CBM 和航线，Firstleg 保存来源、录入人及版本；更新/作废预报沿用入仓写权限，服务端核验仓库范围。日历消费这些正式事实。客户申报值可作录入参考，但不得未经运营确认直接成为有效预报。
+- **分批规则**：一条有效预报表示一批可对应收货的货物；部分到仓前或确认到仓时，将其拆成“本次到货预报部分”和“剩余未到货部分”，子批次保留父预报键、各自预计 CBM 和预计到仓时间。拆分必须显式确认且预计量合计等于拆分前预计量；修订预计总量则另存一个有原因的新版本。
+- **替换规则**：本次到货批次一经确认，就停止把该部分计为未收预报；尚未测量审核时归入“已到待审核”，审核通过后用该批的实际体积替换。剩余批次继续按自己的预计体积统计。复测只更新对应实收批次，不能改变其他未到货批次的预计量。
+- **无法对应**：实收与预报无法确认对应关系时，相关预计量暂列“待核对”，不与可能重复的实收量一起计入可赶总量；展示缺口原因，运营补齐关系后再恢复。不得凭实测体积相近自动抵消。
+- **首版批次关联入口**：审核事件若能携带 `SAILING_FORECAST:<forecastKey>`，服务端只消费该预报批次；多条有效预报且事件没有明确批次键时，实收保持 `UNMATCHED`/待核对，不自动按相近体积抵销。运营可通过预报维护接口显式绑定实收批次、修订预报或作废预报，所有动作均追加版本并保留原记录。
+- **事件与版本**：到货、审核、预报修订/拆分、冲正和作废均带稳定业务键及版本；同一事件重复到达不重复记量。来源版本更新与归班更新必须具备重试及对账机制，返回事实版本、归班版本和计算时间，不能只声明建了四张表就认为数据链路完成。
+
+示例：整票预计 100 m³，先拆成本批预计 40、后批预计 60。本批实际到货审核后为 45，则“已收 45 + 未收预计 60 = 可赶 105”；复测为 43 后变成 103。不能用 `100 - 45` 把后批预计改成 55。
+
+### 6.6 订柜数量建议
+
+订柜数量是只读的运营建议，不是正式订舱或货柜创建。首版按以下口径展示：
+
+```text
+本船可赶实收 CBM = 当前有效归班为 RECEIVED 的审核实测 CBM
+可赶总 CBM = 本船可赶实收 CBM + 有效未收预计可赶 CBM
+已收口径建议柜数 = 向上取整(本船可赶实收 CBM / 规划装载容量)
+建议订柜数 = 向上取整(可赶总 CBM / 规划装载容量)
+已订规划容量 = 求和(每个有效订舱需求的柜数 × 该柜型规划装载容量)
+待补 CBM = max(0, 可赶总 CBM - 已订规划容量)
+待补柜数（某柜型方案） = 向上取整(待补 CBM / 该方案柜型规划装载容量)
+```
+
+- “有效预计 CBM”只取有明确预计到仓时间、渠道/仓库/航线匹配且不晚于最晚到仓时间的有效入仓计划；没有 ETA 的货列为风险，不直接导致多订柜。
+- `LATE` 仍保留在该船历史和已收总量中，但不计入本船可赶实收或订柜建议。已收总量与可赶量是不同指标，不要求相等。
+- 超过截止但尚无到货确认的原预报，保留原归属并标为“到仓待核实”，退出有效预计可赶量；实际到货事实到达后依据真实到仓时间判为准时或晚到。不得仅凭“当前时间已过截止”把所有未审核批次判成晚到。
+- `规划装载容量`、柜型、重量和装载约束复用现有统一柜型目录和智能排柜规则，不在船期日历中另写一套容量或利用率。未选择柜型时，按 40GP/40HQ/45HQ 分别展示方案，不能给出无条件的单一柜数。
+- 已订柜型混合时，展示各柜型数量及合计柜数，先按各自规划容量折算已订容量再计算待补量；不能拿“已订 1 个小柜”直接抵掉“建议 1 个大柜”。柜型容量缺失时待补数显示“待核实”，不默认为 0。
+- 班次容量上限只触发超量预警，不用它截断可赶总量。例如可赶 150 m³、班次上限 100 m³，建议仍按 150 m³ 计算，并标明超出 50 m³；不能少显示所需柜数。
+- 各柜型方案表示“如果待补量全部采用该柜型”的体积初算，未执行重量、混装及实际摆放优化；页面不用“必须订柜数”表示已经确认的订舱指令。
+- 页面必须标注“按体积初算，最终以智能排柜/人工确认结果为准”；重量、箱数、货物混装限制或数据缺失会使结果进入风险提示。
+- 已订柜数只读取 V1 计划船期-订舱关联下的有效 `RELEASED` 订舱需求；日历只保存建议计算的输入、规则版本、计算时间和结果快照，不直接生成正式柜次。
+
+### 6.7 容量提示
+
+- 0%～80%：正常。
+- 80%～100%：接近满舱提示。
+- 大于 100%：超容量提示；V1 不自动阻断只读汇总，也不提供绕过容量的强制关联。异常重新安排仍须满足目标船期状态、截止时间和履约锁定校验。
+- 无容量上限：展示“—”或“不限”，不参与百分比计算。
+
+### 6.8 船期实例状态转换
+
+建议只允许以下状态转换：
+
+```text
+DRAFT → OPEN → CLOSED → DEPARTED → COMPLETED
+  └──────────────→ CANCELLED
+OPEN → CANCELLED
+CLOSED → CANCELLED（尚未开船；必须确认影响）
+```
+
+`CLOSED` 表示停止收货，`DEPARTED`/`COMPLETED` 表示计划记录的运营状态，不得代替现有订舱、装柜或实际船节点事实。实例一旦有有效收货或预占记录，不能回到 `DRAFT`，取消后仍保留货量关联和审计历史。
+
+建议 `OPEN → CLOSED` 由服务端根据最终截止时间自动生效，页面只展示结果；`CLOSED` 不因刷新或修改筛选重新打开。`DEPARTED`、`COMPLETED` 在 V1 仅允许明确的运营动作或后续已确认事实推进，不能由“预计开船时间已到”直接推断。
+
+### 6.9 停用、取消和甩柜
+
+- 渠道停用只阻止新模板和新实例生成；已经生成且仍为 `OPEN` 的实例默认继续有效，是否批量关闭必须由运营人员明确操作。
+- 取消实例前必须展示影响范围：预计归班量、已收量、预占量和已关联订舱/柜次。已有已收量的实例只能取消或进入改配流程，不能删除。
+- 取消后，将原有效归班标记 `SUPERSEDED`，新增 `UNMATCHED` 版本并保存原船期及 `reason=CANCELLED`，展示为“未安排/待人工处理”；不自动把货量塞进下一班。新版本保留事实引用，原版本可追溯，不原地覆盖历史。
+- 同一取消操作将有效订舱关联改为 `REVOKED`，保留历史快照；不自动作废、重开或修改正式订舱。关联解除后当前订柜统计重新计算，正式订舱是否改船由已有订舱流程处理。
+- 甩柜/改配时保留原实例、原归班和实际收货事实，新增目标实例关联；不能回写或覆盖现有港务船期、订舱资料或报关事实。
+
+### 6.10 V1 受限的异常重新安排
+
+这是本轮推荐的范围补充，解决“异常已展示，但首版没有办法处理”的缺口。只允许处理未安排、晚到或因船期取消而待处理的货，正常批次批量改绑仍后置。
+
+1. 运营在异常待办选择货物，查看原船期、当前事实版本、原因及匹配候选；选择目标并填写原因后确认，保存前先显示两班的货量变化。
+2. 目标须仓库、正式渠道、港口相符，状态 `OPEN` 且当前未过截止；预报另核验预计到仓时间，实收另核验真实到仓时间。V1 不提供绕过截止、强行修改实收时间或跨仓挪量的入口。
+3. 服务端核验独立异常安排权限、当前归班版本及目标船期版本；原有效版本转 `SUPERSEDED`，新版本写 `MANUAL`，保留原/新船期、操作者、时间和原因。并发重复确认只能成功一次。
+4. 货物如已绑定真实柜次、预装或装柜履约，先阻止在日历直接改配，并指向既有履约流程；不得通过改日历归班绕过实物锁定。无符合条件的目标时继续待安排，可先新增临时船期。
+5. 归班重新安排不自动转移订舱关联；目标班的已订柜仍只来自重新校验后建立的有效订舱关联。
+
+## 7. 建议数据模型
+
+以下为规划字段，具体命名应在接口和 SQL 评审时统一。
+
+### 7.1 `fl_sailing_channel`
+
+| 字段 | 说明 |
+| --- | --- |
+| `id` | 渠道业务主键 |
+| `channel_code` | 稳定渠道代码；固定渠道可映射现有渠道目录，自定义渠道也必须先建立稳定代码。现有装柜的九类渠道分组只作为兼容映射，不能把枚举写死为日历渠道全集 |
+| `channel_name` | 渠道名称，如 MATSON / 美森 |
+| `source_type` | `CATALOG`（复用现有物流渠道）或 `SCHEDULE_ONLY`（仅用于排班，尚未映射为可订舱渠道） |
+| `mapped_channel_code` | 自定义排班渠道对应的正式物流渠道代码，可为空；为空时不能被订舱/价格接口当作正式渠道 |
+| `default_departure_port_code` | 默认起运港，可被模板覆盖 |
+| `default_destination_port_code` | 默认目的港，可被模板覆盖 |
+| `default_cutoff_days` | 默认提前收货天数 |
+| `status` | `ACTIVE` / `INACTIVE` |
+| `remark` | 备注 |
+| `created_at` / `updated_at` | 审计时间 |
+
+标准渠道优先复用现有仓库范围内的 ACTIVE 物流渠道和稳定 `channelCode`，不能只保存一个自由文本名称。自定义排班渠道必须通过 `SCHEDULE_ONLY` 明确标记，后续若要用于订舱或报价，先完成正式渠道映射。渠道停用不影响历史实例和历史统计；停用后不能新建模板或自动生成未来实例。
+
+### 7.2 `fl_sailing_template`
+
+| 字段 | 说明 |
+| --- | --- |
+| `template_no` | 模板业务编号 |
+| `channel_id` | 所属渠道 |
+| `receiving_warehouse_id` | 收货仓；截止规则和可赶船判断的范围键 |
+| `template_type` | V1 固定为 `WEEKLY` |
+| `weekdays` | 周一至周日的选中集合 |
+| `effective_from` / `effective_to` | 规则有效期 |
+| `departure_time` | 开船本地时间 |
+| `voyage_rule` | 船名/航次生成规则快照 |
+| `transit_days` 或 `eta_time` | 预计到港计算依据 |
+| `cutoff_days` | 模板级提前收货天数 |
+| `cutoff_local_time` | 收货仓默认截收时刻，可被实例覆盖 |
+| `default_capacity_cbm` | 可选的班次计划容量；不替代统一柜型目录的柜容 |
+| `status` | `DRAFT` / `ACTIVE` / `INACTIVE` |
+
+### 7.3 `fl_sailing`
+
+| 字段 | 说明 |
+| --- | --- |
+| `sailing_no` | 船期实例业务编号 |
+| `template_id` | 来源模板，可为空（独立单次船期） |
+| `channel_id` | 渠道快照引用 |
+| `channel_code_snapshot` / `channel_name_snapshot` | 生成时的渠道编码和名称快照 |
+| `receiving_warehouse_id` | 收货仓 |
+| `departure_port_code` / `destination_port_code` | 港口快照 |
+| `vessel_name` / `voyage_no` | 船名和航次 |
+| `etd_at` / `eta_at` | 预计开船、预计到港 |
+| `suggested_cutoff_at` | 计算出的建议截止时间 |
+| `cutoff_at` | 最终收货截止时间 |
+| `cutoff_override` / `cutoff_override_reason` | 是否人工覆盖及原因 |
+| `cutoff_rule_version` | 计算时使用的时区、自然日/工作日和截收时刻规则版本 |
+| `capacity_cbm` | 可选的班次计划容量上限；空值表示不做班次容量提示，不替代统一柜型目录的柜容 |
+| `container_type_code` | 默认柜型；为空时按可用柜型分别给出建议 |
+| `status` | 实例生命周期状态 |
+| `generated_key` | 模板生成幂等键 |
+| `version` | 乐观锁版本 |
+| `created_at` / `updated_at` | 审计时间 |
+
+不建议把已收体积、剩余体积作为可直接修改的主表字段；它们应由关联事实聚合，必要时做带统计时间的服务端快照。
+
+### 7.4 `fl_sailing_assignment`（V1 自动归班；V1 受限异常重新安排）
+
+V1 必须由服务端持久化自动归班结果；常规人工改绑、拆分分配和预占仍放到 Phase 2，第 6.10 节的异常重新安排除外。归班对象以收货批次或货量预报为最小粒度，不以整张订单或整张入仓单代替。`sailing_id` 可以为空，表示已记录但尚未找到可解释班次的 `UNMATCHED` 结果。
+
+| 字段 | 说明 |
+| --- | --- |
+| `id` | 归班事实 ID |
+| `sailing_id` | 船期实例；`UNMATCHED` 时为空 |
+| `inbound_id` / `receipt_batch_id` / `forecast_id` | 归班对象；至少有一个稳定业务键 |
+| `assignment_source` | V1 为 `AUTO`；预留 `MANUAL`、`ROLLOVER` |
+| `assignment_version` | 同一归班对象的版本号，重算递增 |
+| `match_status` | `FORECAST_MATCHED` / `RECEIVED` / `LATE` / `UNMATCHED` / `SUPERSEDED` |
+| `volume_cbm` | 本次归属的已收实测体积；V1 固定来自审核后的 `actualVolumeCbm` |
+| `forecast_volume_cbm` | 本次归属的未收有效预计体积，与已收体积分开 |
+| `forecast_source` | 预计体积来源；没有可靠预计体积时为空，不得用申报值冒充已收体积 |
+| `route_source` | 航线来自入仓/预报事实或 `CHANNEL_DEFAULT`，用于追溯匹配依据 |
+| `volume_source` | 已收状态固定为 `MEASURED_ACTUAL`；仅预计状态为空，计费/申报仅作对比或后续扩展 |
+| `rule_version` | 自动归班规则版本 |
+| `matched_at` / `superseded_at` | 归班和被替代时间 |
+| `locked_at` / `lock_reason` | 达到船期截止、确认订舱或船期关闭后冻结归班的时间和原因 |
+| `operator_id` / `reason` | 自动任务/后续人工操作审计 |
+
+同一批次或预报在同一时刻只能有一个 `AUTO` 有效归班版本；重新计算采用旧版本 `SUPERSEDED` + 新建版本，不能静默覆盖旧历史。
+
+“同一业务对象”在这里指收货批次，不是整票订单或整张入仓单；一票分批到仓、复测或冲正时，必须按批次守恒，不能用单据级唯一键把后续批次锁死。
+
+### 7.5 `fl_sailing_booking_advice_snapshot`
+
+这是订柜建议的可追溯快照，不是正式订舱记录。每次刷新或人工确认建议时保存：
+
+| 字段 | 说明 |
+| --- | --- |
+| `sailing_id` / `container_type_code` | 船期和柜型 |
+| `received_cbm` / `forecast_catchable_cbm` / `risk_cbm` | 已收、可赶预计和风险体积 |
+| `planning_capacity_cbm` | 从统一柜型目录读取的规划容量快照 |
+| `recommended_container_count` | 按体积初算的建议柜数 |
+| `booked_container_count` / `shortage_count` | 已订柜数和待补柜数 |
+| `rule_version` / `calculated_at` | 计算规则版本和计算时间 |
+| `risk_codes` | ETA 缺失、重量缺失、箱数缺失、混装限制等风险 |
+
+### 7.6 `fl_sailing_booking_link`（V1 最小订舱关联）
+
+首版要显示“已订柜数”和“待补柜数”，因此必须在 V1 建立计划船期与订舱的最小关系；复杂的实际柜次、甩柜和海运节点关联仍放到后续阶段。
+
+| 字段 | 说明 |
+| --- | --- |
+| `sailing_id` | 计划船期实例 |
+| `ocean_booking_id` | 海运订舱 |
+| `link_status` | `ACTIVE` / `REVOKED`；解除关系保留历史 |
+| `booking_status_snapshot` | 关联时的订舱状态快照；当前只有订舱状态为 `RELEASED` 才允许计数 |
+| `warehouse_id` / `channel_code` / 起运港 / 目的港 | 关联时的业务匹配快照 |
+| `linked_at` / `operator_id` / `reason` | 关联审计 |
+
+V1 采用以下计数契约：
+
+- 只有当前订舱状态为 `RELEASED` 且关联记录为 `ACTIVE` 的订舱才计入已订柜；`DRAFT`、已作废或已解除关联的不计入。`RELEASED` 是订舱状态，不是关联记录状态。
+- 已订柜数按该订舱的柜型需求 `quantity` 汇总，不按已生成真实柜次数量、不按装柜完成数量替代。
+- 一个 `RELEASED` 订舱首版只能关联一个计划船期；如果未来需要一个订舱拆到多班，再升级到按柜型需求行分摊的关系。
+- 关联时必须校验收货仓、渠道代码、起运港、目的港和计划船期一致；不一致进入冲突，不允许仅凭船名/航次文字关联。
+- 订舱解除、作废或计划取消后，已订柜数应在服务端重新计算，并保留原关联历史；不得把已订柜数当作人工可编辑字段。
+
+## 8. 接口草案
+
+接口路径和 DTO 以最终服务端归属为准，以下只作为拆分和评审入口：
+
+| 能力 | 建议接口 | 说明 |
+| --- | --- | --- |
+| 月历查询 | `GET /platform/v1/sailings/calendar` | 按月份、收货仓、港口、渠道、关键词、状态返回实例和服务端汇总；同时返回未安排/晚到摘要 |
+| 实例详情 | `GET /platform/v1/sailings/{sailingId}` | 返回实例、统计、关联货量和操作权限 |
+| 新增单次实例 | `POST /platform/v1/sailings` | 幂等创建，支持无模板来源 |
+| 编辑/取消实例 | `PUT/PATCH /platform/v1/sailings/{sailingId}` | 乐观锁；取消保留历史 |
+| 渠道管理 | `GET/POST/PUT /platform/v1/sailing-channels` | 启用、停用和主数据维护 |
+| 模板管理 | `GET/POST/PUT /platform/v1/sailing-templates` | 周模板和启停；固定单次船期直接走实例接口 |
+| 生成预览 | `POST /platform/v1/sailing-templates/{id}/generation-preview` | Phase 1 必须支持；返回日期、航次、冲突和截止时间预览 |
+| 批量生成 | `POST /platform/v1/sailing-templates/{id}/generate` | 使用幂等键，返回成功、跳过和冲突清单 |
+| 货量明细 | `GET /platform/v1/sailings/{id}/volume-summary` | V1 返回自动归班结果、服务端汇总和收货批次明细，不要求已经存在人工改绑 |
+| 收货批次事实 | Firstleg 服务正式事实查询（路径以 Controller 归属评审为准） | 提供 `receiptBatchId`、`receivedAt`、最终实测 CBM、审核/冲正状态及仓库/渠道/航线快照；船期页面不得从入仓单分页自行拼装 |
+| 货量预报事实 | Firstleg 服务正式事实查询（路径以 Controller 归属评审为准） | 提供 `forecastId`、`expectedArrivalAt`、`forecastVolumeCbm`、有效状态、版本和来源；没有可靠预报时只返回风险/未安排 |
+| 订柜建议 | `GET /platform/v1/sailings/{id}/booking-advice` | 按柜型返回已收、可赶预计、风险、已订柜、建议柜数和待补柜数；只读 |
+| 订舱关联 | `POST /platform/v1/sailings/{id}/booking-links` | V1 关联一个 `RELEASED` 订舱并校验仓库、渠道、港口和船期；只建立最小关系，不创建柜次 |
+| 手工关联/改绑 | `POST /platform/v1/sailings/{id}/volume-allocations` | Phase 2+；校验截止、容量、收货仓归属和幂等键 |
+| 变更历史 | `GET /platform/v1/sailings/{id}/history` | 实例、模板和手工改绑审计 |
+
+所有写接口建议使用 `Idempotency-Key`、`expectedVersion` 和服务端权限校验；错误响应应能区分重复生成、容量不足、已截止、状态冲突和归属不一致。
+
+## 9. 权限建议
+
+权限按“看”和“改”拆分，至少包括：
+
+- `platform:firstleg:sailing-calendar:list`：查看月历、详情、货量汇总和只读历史。
+- `platform:firstleg:sailing-calendar:create`：新增单次船期。
+- `platform:firstleg:sailing-calendar:edit`：编辑、复制和取消。
+- `platform:firstleg:sailing-volume:exception-reassign`：V1 受限异常重新安排；只能处理取消、晚到和未安排货量，不能绕过截止、容量或真实履约锁定。
+- `platform:firstleg:sailing-volume:bind`：常规人工改绑、拆分和预占，Phase 2+ 才启用。
+- `platform:firstleg:sailing-booking:link`：建立或解除计划船期与订舱的最小关联。
+- `platform:firstleg:sailing-template:manage`：渠道、模板、批量生成和停用。
+- `platform:firstleg:sailing-volume:bind`（Phase 2+）：关联/改绑货量。
+- 审计导出或跨业务检索如确有需要，再单独增加权限；普通详情历史不另造重复的只读权限。
+
+权限只由服务端决定，前端按钮隐藏不能替代后端校验。
+
+## 10. 分期建议
+
+### Phase 1：可用的日历排班
+
+- 渠道主数据、单次船期、周模板。
+- 截止时间计算和实例生成。
+- 生成预览、冲突清单和确认后批量生成。
+- 月历、日期详情、渠道维度的预计/已收体积汇总。
+- 服务端自动归班的只读结果：预计可赶船、已收、晚到风险、未安排。
+- 按现有柜型目录计算只读订柜建议：可赶总 CBM、建议柜数、已订柜数、待补柜数和风险提示。
+- 保存自动归班事实和版本历史；建立计划船期与 `RELEASED` 订舱的最小关联，用于计算已订柜数；为取消、晚到和未安排货提供受限异常重新安排。
+- 实例编辑、取消和基础历史。
+
+Phase 1 不提供正常货量的批量改绑、强制赶截止和容量预占；只提供第 6.10 节的受限异常重新安排。若没有明确归班事实，只展示“未安排”，不能把按渠道汇总的体积伪装成某一班船已收。
+
+### Phase 2：排班辅助和容量控制
+
+- 模板复制和批量调整。
+- 在 V1 已实现的收货仓、渠道、港口、截止时间和确定性排序基础上，Phase 2 再增加复杂优先级、容量约束和多班冲突处理。
+- 容量阈值、超容拦截和有权限的强制处理。
+- 手工关联、改绑、预占和货量明细。
+
+### Phase 3：运营增强
+
+- 工作日/节假日日历。
+- 月度/渠道汇总导出和报表。
+- 截止提醒、异常通知和更完整的审计检索。
+- 与真实柜次、港务船期、甩柜/改配和实际海运节点的完整可追溯关联，但不覆盖已有运输事实；V1 的最小订舱关联已经前置。
+
+## 11. 验收标准
+
+1. 新建“美森每周周四”模板，预览并生成指定月份的所有周四实例；再次生成不产生重复实例。
+2. 新增一条固定船期，能够编辑开船时间、船名、航次、截止时间和容量；已有归班或已收货事实后只能取消，不能物理删除。
+3. 日历格和日期详情显示同一套渠道统计口径；至少能区分预计体积、已收体积、未安排/晚到和剩余容量。
+4. 根据收货仓、起运港、渠道、船名/航次和月份筛选后，月历数量、日期详情和统计合计一致；跨月日期不会重复或漏显示。
+5. 截止时间按服务端规则计算，人工覆盖有明确标识；超过截止或已取消的船期不能被自动推荐。
+6. 接近容量上限和超容量有明确状态；V1 只读提示，不能因为体积初算直接生成正式柜次。
+7. 停用渠道的历史实例可查询，停用后不能创建新的模板实例；渠道改名不改变历史实例的名称快照。
+8. 写接口具备幂等和乐观锁；重复提交、并发编辑、重复生成均返回可理解的冲突信息。
+9. 列表/详情只读、实例编辑/取消、模板管理、货量改绑分别受权限控制；操作历史可追溯到操作者和原因。
+10. 页面展示业务编号、船名、航次、港口和渠道，不以内部数据库 ID 作为用户可见回退。
+11. 对一班固定船和一班临时船，系统能分别展示已收 CBM、截止前预计 CBM、风险 CBM、已订柜数、建议订柜数和待补柜数；建议结果标注计算时间、柜型和规则版本，并明确最终以智能排柜/人工确认结果为准。
+12. 同一收货批次先产生预计归班，之后实际收货并复测；系统保留旧归班版本、只计最新有效实测体积，且不把预计体积与实测体积重复相加。
+13. 同一时刻建立两班船，自动归班结果稳定选择 `sailing_no` 较小者；船期截止后刷新页面，原归班仍显示为 `LATE` 或 `RECEIVED`，不会变成无历史的未安排。
+14. 一个 `RELEASED` 订舱关联一条计划船期，柜型需求数量计入已订柜；`DRAFT` 订舱、未关联订舱和真实柜次数量不会被错误计入。
+15. 自动归班在截止前可以重算；达到截止后原归班被冻结，后续实际收货标记为 `LATE` 时仍保留原船期。没有稳定收货批次或预报事实时只显示风险/未安排，不得用 `inboundedAt`、`originalVolumeCbm` 或入仓单分页合计补出数字。
+
+## 12. 首版已冻结与后续校准
+
+本轮已先采用以下口径，开发按此实现：
+
+1. 船期模板/实例必须绑定收货仓、渠道、起运港和目的港；不使用“全部仓”作为模糊范围。
+2. 已收只统计 V1 收货批次事实中明确完成收货、最终测量审核通过且 `actualVolumeCbm > 0` 的批次；申报体积和计费体积不计入已收。
+3. V1 新增或正式暴露稳定的 `receiptBatchId + receivedAt` 收货批次事实；不能用现有会被多个流程节点更新的 `inboundedAt` 单独代替。
+4. V1 新增或正式暴露 `forecastVolumeCbm + expectedArrivalAt` 货量预报事实；`originalVolumeCbm`、申报箱数和计费体积不得作为预计可赶量。
+5. 预计可赶量只纳入有明确 ETA、预计体积、渠道/仓库/航线匹配且不晚于 `warehouseCutoffAt` 的有效预报；没有 ETA 或航线的货列为风险/未安排。
+6. 自动归班选择最早可赶的 `OPEN` 船期，并在 V1 持久化 `FORECAST_MATCHED`、`RECEIVED`、`LATE`、`UNMATCHED` 和 `SUPERSEDED` 历史；截止前且未锁班时可以版本化重算，达到截止、`CLOSED` 或已确认订舱后冻结当前归班；船期取消只转为风险/待人工处理，不自动换班；晚到不自动改班。
+7. 同一收货仓、渠道、起运港和目的港下，ETD 相同的多班船按 `sailing_no` 升序确定唯一归班；同一归班对象同一时刻只能有一个有效版本。
+8. `warehouseCutoffAt` 暂定为开船本地日期前 3 个自然日、收货仓 18:00，时区为 `Asia/Shanghai`；它与官方截单/截关/截港分开。
+9. V1 建立计划船期与 `RELEASED` 订舱的最小关联；已订柜数按关联订舱的柜型需求 `quantity` 统计，`DRAFT` 不计入，不按真实柜次数量替代。
+10. 订柜建议复用现有柜型目录、容量和已订柜事实，只读展示建议柜数和待补柜数，不直接创建正式柜次；结果标注“按体积初算，最终以智能排柜/人工确认结果为准”。
+11. V1 航次规则只支持固定值或“前缀 + ETD 本地日期”，生成实例允许人工覆盖；不做顺序号自动递增。
+12. V1 采用人工预览后生成固定周模板实例；停航或临时变更先手工跳过/取消，暂不做节假日自动日历。
+
+以下事项不阻断首版，但需要在试运行或进入后续阶段前校准：
+
+1. 多个收货仓是否能共同供货给同一班船；如果可以，建立明确的收货仓组，再做线路级合计，不能直接跨仓混算。
+2. 提前天数是否从自然日升级为工作日，周末/节假日是否接入工作日历。
+3. 渠道是否需要客户专属范围；若需要，客户必须进入模板、实例、查询和权限维度。
+4. 同一渠道同一天多班船的复杂运营优先级、航次生成规则和模板覆盖策略。
+5. 订柜建议是否支持多柜型混合、重量约束和装载率优化；首版按体积初算，最终以智能排柜/人工确认结果为准。
+6. 计划实例与真实柜次、港务船期的完整关联时机，以及甩柜、改配后的运输事实展示。
+
+## 13. 工程接入门禁
+
+进入实现阶段后，页面与接口需要同步维护以下入口：
+
+- Admin 页面放在 `apps/admin-web/src/modules/` 的独立业务模块内，包含 `pages/`、`routes.ts`、`api/` 和 `types.ts`；不能把模板和实例逻辑塞入现有 `CarrierScheduleQueryPanel.vue`。
+- 正式接入时同步 `src/app/router/index.ts`、`src/core/navigation/adminNavigation.ts` 和平台 IAM 权限初始化；菜单归属应在“国内仓”与“货柜管理”中选定后固定。
+- Firstleg 若承载服务端能力，需同步 Controller、OpenAPI、数据库基线、Gateway 路由和权限契约；月历统计由服务端返回，前端不以 `InboundOrderSummary` 分页结果自行拼装。
+- 需要优先复用现有仓库范围内的正式 `channelCode`/渠道目录，再为确有需要的排班专用渠道建立明确映射；同时校验入库实测字段、订舱/货柜船期和价格簿的引用边界。新计划不能回写港务船期观测或订舱快照。
+- V1 开发前必须先落地 `ReceiptBatchFact`、`InboundVolumeForecast`、`fl_sailing_assignment` 和 `fl_sailing_booking_link` 的服务端事实与索引；Firstleg 的当前基线对应 `phase4-sailing-facts-schema.sql`、`sailingcalendar/fact/entity` 和 `SailingFactsRepository`，部署统一增量也必须包含这四张表。如果这些事实没有来源，接口只能返回风险/未安排，不能伪造已收或已订柜数字。
+- 订柜建议必须读取统一柜型目录和 `RELEASED` 订舱需求；不得另建 40GP/40HQ/45HQ 容量常量，也不得用真实柜次数量替代订舱需求数量。
+- 页面验收覆盖正常、空数据、加载、失败、无权限、并发冲突、已截止、超容量和已取消状态，并按 Admin 当前 1920×1080、100% 缩放基线执行。
+
+## 14. 建议实施顺序
+
+1. 按第 12 节首版冻结口径建立统一的术语、体积、归班、截止时间和订柜建议规则。
+2. 画出模板、实例、货量关联和现有港务船期之间的关系，并评审权限与审计边界。
+3. 先落地服务端查询模型和月历返回结构，再实现 Admin 月历页面，避免前端自行拼装统计。
+4. 用“美森每周周四 + 一条临时船期 + 一批预计到仓数据 + 一批已收实测数据 + 一批晚到数据”做端到端造数和验收。
+5. 完成 Phase 1 后再决定手工改绑、容量预占、工作日历、导出和外部船期接入，避免首期把订舱和船公司接口一起带入。
+
+## 15. 本轮复核结论与验收算例
+
+本轮复核后的结论是：**基础排班可以进入开发；完整的收货统计、订柜建议和异常处理必须按本节算例验收后，才能认为首版可用。** 下面的数字是验收用例，不是初始化数据，也不是对截图示例的默认值。
+
+### 15.1 分批收货不能用整票相减
+
+- 一票有效预报拆为 A 批 40 m³、B 批 60 m³。
+- A 批实际到货并审核为 45 m³时，结果为“已收 45 m³ + 未收预计 60 m³”；不能把整票 100 m³ 直接减去 45 m³后把 B 批改成 55 m³。
+- A 批复测为 43 m³时，只更新 A 批实收版本；B 批仍为 60 m³。任一版本重复消费都不得重复计量。
+- 如果实收不能明确对应 A 或 B，相关预报暂列“待核对”，不把实收和预报同时计入可赶总量。
+
+### 15.2 无预报直接收货与晚到的区别
+
+- 没有预报但首次形成 20 m³审核实收，且仓库、渠道、航线明确、实际到仓时间不晚于某个 `OPEN` 船期截止：自动归入该船，状态为 `RECEIVED`。
+- 已经归属于周四船的批次，实际到仓晚于周四截止：保留周四历史，状态为 `LATE`；已收总量增加，但周四的“本船可赶实收”和订柜建议不增加。
+- 没有归班、资料缺失或已过截止才首次到仓的批次进入异常待办，不能仅因体积或渠道相似自动塞进下一班。
+
+### 15.3 订柜建议要排除晚到并抵扣真实柜型容量
+
+- 40HQ 规划容量按统一柜型目录读取，不能在日历模块复制常量。
+- 一班船有本船可赶实收 40 m³、有效未收预报 28 m³、晚到 35 m³；建议计算量为 68 m³，晚到 35 m³只在已收总量/风险中展示。
+- 若已有一个 40GP 和一个 40HQ 的 `RELEASED` 订舱关联，已订规划容量按两个柜型各自容量折算；不能只按“已订 2 柜”抵扣，也不能把 `DRAFT` 订舱计入。
+- 班次规划容量小于可赶总量时只显示超容量和超出体积，不能静默截断可赶量或降低建议柜数。
+
+### 15.4 取消后的异常重新安排
+
+- `CLOSED` 且尚未开船的船期可以取消；取消会保留原归班和订舱关联历史，将当前货量转为异常待办，不自动改到下一班。
+- 运营有异常重新安排权限时，选择目标 `OPEN` 船期、填写原因，系统同时校验仓库、渠道、港口、截止时间、目标版本和履约锁定状态。
+- 成功后旧归班为 `SUPERSEDED`，新归班为 `MANUAL`，目标班只计一次；目标班订柜关联必须另行建立或确认，不随货量改配自动转移。
+- 已有真实柜次、预装或装柜履约锁定的货不能从日历直接改配，必须回到对应履约流程处理。
+
+### 15.5 开发完成判定
+
+满足以下条件才通过首版业务验收：事实来源可追溯、预报和实收不重复、晚到不增加原班可赶量、取消后有异常处理入口、订柜按柜型需求折算且仅统计有效 `RELEASED` 关联、月历与详情使用同一服务端快照。仅完成页面、接口返回空数组或通过类型/编译检查，均不能作为通过依据。
+
+### 15.6 成熟货代系统的排船期做法
+
+成熟系统把“排船期”视为一条可执行的运输计划，而不是日历上的一个标记，通常分为四层：
+
+1. **服务/周班模板**：维护渠道、收货仓、起运港、目的港、固定星期、开船时间、时区、默认航程和默认截止规则。固定周班按滚动窗口生成未来 8～12 周的具体航次；模板停用只影响未来生成，不回写历史实例。Oracle OTM 也支持按固定星期时间或相对开船时间的偏移配置航次截点：[Oracle Cutoff Recovery Time](https://docs.oracle.com/en/cloud/saas/transportation/26c/otmol/planning/power_data/rates_and_codes/cutoff_recovery_time_details.htm)。
+2. **具体航次实例**：每班保存自己的船名、航次、计划 ETD/ETA、内部收货截止、船司确认的各类截止、状态和容量。模板只提供默认值；船司确认或运营人工覆盖后，只更新实例并保留变更历史。
+3. **货物归班事实**：预计到仓、审核后的实收批次、体积版本和当前归属独立保存，能追溯自动归班、晚到、取消和人工改配的前后航次。
+4. **订舱执行**：预报量、已收量、已订柜量、待补柜量分开统计。只有已确认/已放舱的订舱关联计入已订柜，草稿和取消订舱不计入。
+
+一个航次不应只有一个“截止时间”。至少区分：我司仓库最晚收货时间、订舱接受截止、截单/SI、截关/CY、VGM，以及危险品/冷柜等特殊货类截止。DCSA 将这些作为不同的业务节点，并指出其会随船期、码头和货类变化：[DCSA Cut-off Times](https://dcsa.org/newsroom/cut-off-times-in-shipping)。VGM 还必须在装船前提前提交，才能满足装载条件：[IMO VGM](https://www.imo.org/en/ourwork/safety/pages/verification-of-the-gross-mass.aspx)。因此，本系统的“开船前 3 个自然日、收货仓 18:00”只能作为我司内部 `warehouseCutoffAt` 默认值，不能当作船司截关时间。
+
+自动归班采用以下顺序：先按收货仓、渠道、起运港、目的港筛选 `OPEN` 且尚未超过 `warehouseCutoffAt` 的候选，再按 ETD 最早排序。实际到仓时间等于截止时间仍算准时；超过截止时间后，未锁班、未订舱的货物自动寻找下一班，下一班不存在时进入 `UNMATCHED/待人工`。已经锁班或已确认订舱的货物即使晚到，也保留原 `sailingId`，标记 `LATE/MISSED_CUTOFF`，由运营确认是否转下一班，不能静默改写原归属。
+
+例如美森固定周四 10:00 开船，义乌仓内部收货截止为周二 18:00：周二 17:59 和 18:00 到仓的货物可赶本周四；周二 18:01 首次到仓的货物只能进入下一周四；已经确认归属本周四的晚到货物则保留本周四并进入晚到异常。
+
+建议状态补充 `NEAR_CUTOFF` 和 `BOOKING_CONFIRMED/LOCKED`。`NEAR_CUTOFF` 只用于预警，仍允许收货；超过内部截止后由服务端禁止新的自动归班。船司延误、甩柜或取消时，保留原实例和归班历史，生成异常待办并要求明确改配，不直接把货物静默塞入下一班。
+
+### 15.7 从当前版本到可运营版本的改造顺序
+
+结论是保留现有“模板 → 航次实例 → 收货归班 → 货量汇总 → 订柜建议”主模型，不重做日历页面，先补齐以下规则和闭环。
+
+**P0：上线前必须完成**
+
+1. 服务端统一执行收货截止门禁。候选航次必须同时满足 `status=OPEN` 和 `arrivalAt <= warehouseCutoffAt`；首次晚到不能继续挂当前航次，已存在归班的晚到只能保留原航次并标记 `LATE`。
+2. 建立锁班和字段冻结。已有确认订舱、人工锁班或履约事实后，禁止直接修改收货仓、渠道、港口、ETD、截止时间等关键字段；需要调整时走复制、取消或异常改配。
+3. 完善预报与实收的批次关联。同一收货批次只能消费一个有效预报；多个预报、错误的预报键、预报作废和拆分必须进入待核对，不能同时计入预报量和实收量。
+4. 取消/甩柜只产生异常待办，不自动把货物静默塞进下一班；人工改配必须记录原航次、目标航次、操作者、时间、原因和目标版本。
+5. 收货仓、渠道、起运港和目的港使用主数据选择并由服务端校验，不能长期依赖前端自由填写名称或 ID。
+6. 月历和详情只统计同一服务端口径：已收使用审核实测 CBM，晚到不计入原班可赶量，取消航次不计入主汇总，已订柜只统计有效的 `RELEASED/CONFIRMED` 关联。
+
+**P1：首版稳定运行后完成**
+
+1. 增加预报维护、异常待办、人工改配、订舱关联/撤销等 Admin 操作入口。
+2. 模板支持完整有效期、停班例外、跨月生成和生成前冲突预览；默认滚动生成未来 8～12 周。
+3. 增加 `NEAR_CUTOFF`、待补柜、超容量、未安排等风险提示，并提供按渠道的 CBM 和柜量分组汇总。
+4. 所有写操作接入统一幂等和版本校验，避免重复点击、重复生成和并发覆盖。
+
+**P2：运营增强**
+
+再接入船司/码头实际截点、节假日工作日历、容量预占、自动提醒、外部船期同步和更复杂的混合柜型优化。它们不应阻塞首版排船和收货统计上线。
+
+### 15.8 当前展示版范围修正（以本节覆盖前文自动归班口径）
+
+本轮需求已明确：船期日历先作为**展示和决策辅助页面**，不接管现有收货、预报、智能排柜或订舱流程。前文关于 `Sailing Assignment` 自动写入、自动下一班、晚到改配、取消后异常重排和收货审核回调的内容，全部降为后续规划，不纳入当前开发验收。
+
+当前版本允许运营人员维护渠道、周模板和具体船期；货量相关能力全部只读：
+
+- **有效船期与过期**：按 `Asia/Shanghai` 自然日，月历和汇总只纳入今天及以后开船的计划；今天之前的计划自然过期并从日历移除，不删除记录、不伪造已开船状态。服务端返回上海本地时间 `nextRefreshAt`，取下一零点和同仓、同渠道范围内最近截仓时刻之后 1 毫秒的较早值；截仓查询不受展示月份、船名、港口或状态筛选限制。页面据此自动刷新，失败后延迟 60 秒重试，避免跨月顺延后货量停留在旧值。
+- **已收 CBM 与未发货顺延**：读取现有收货/测量流程已经产生且尚未确认国内离仓的有效实测体积。已排柜且关联有效 `RELEASED` 订舱的部分，保留在其开船日期不早于今天、状态为 `OPEN/CLOSED` 的船期，截仓后仍保留；支持既有跨仓、跨渠道安排。未安排或原安排取消、日期过期的余量，按原收货仓和渠道选取 `OPEN`、开船日期不早于今天且截止时间不早于当前时刻的最近一班，按开船时间、船期编号、ID 稳定排序。同一份货量只计入一班，部分排柜按体积分开，不受原收货月份限制；没有下一有效船期时保留原货物事实，后续新增有效计划即可承接。这里只改变只读展示，不改已确认订舱、排柜或真实运输安排。
+- **预计 CBM**：读取现有入仓预报或智能排柜可读数据；没有可靠来源时显示“暂无数据”，不凭渠道名称或订单分页猜测。
+- **截止前参考量**：对顺延后的待发货量按收货时间与 `warehouseCutoffAt` 区分参考量和风险量，不表示货物已经绑定该船。每次月历查询共用一个业务时刻，避免跨过截仓瞬间造成重复。
+- **已明确本船量**：只读取现有系统已经明确关联到该船名/航次或现有订舱/柜次事实的数据；日历不新增关联。
+- **建议订柜数**：对展示的待发实测与可核验预计体积之和，除以统一柜型容量向上取整；正货量不足一柜也算一柜，零货量为零柜。晚到/风险标签不直接抹除已收货量。待补柜按货量先扣除未离仓柜的可用订舱容量，再按对应柜型向上取整，下限为零；已离仓柜的容量不能抵扣仓内余货。日历卡片、汇总和各柜型方案保持一致。不创建订舱、不锁舱位、不改柜次。
+- **合船判断**：页面只提供“本船未满、建议关注相邻船期”的提示，并展示相邻船的可用容量和货量对比；不自动合并、不自动改绑。
+
+展示版的数据实现口径再明确一层：已收实测只统计测量审核为 `APPROVED` 且有 `actual_volume_cbm` 的有效入库单，限定 `WAIT_PALLETIZE/WAIT_SPLIT/LOADING/LOADED`。未拆分单与拆分后的余量单各按自身实测体积统计；PDA 拣货结算后处于 `FULLY_SPLIT + LOADING/LOADED` 的源单已归一化为实际装柜部分，未离仓前同样保留，不能与整票原始体积重复。每票按有效装柜明细拆分为已离仓体积、有效订舱占用体积与未安排余量；已离仓要求客户、入库单和柜次一致，离仓状态为 `WAITING_FOR_LOADING` 且存在确认时间。扣除已离仓和有效订舱占用后，余量最低为零；订舱占用部分单独计入对应船期，撤销离仓后按现有运输安排重新纳入。当前没有可核验的预计体积来源时，预计量按 0 展示并在页面提示“暂无可核验数据”，不得把申报体积、原始体积或分页列表合计冒充预计量。已订柜读取已放舱订舱的柜型需求，存在有效显式关联时只认该关联；没有有效显式关联才用仓库、渠道、港口、船名、航次和开船日期做确定性只读匹配，每条订舱只选一班。已订总容量保存在 `bookedPlanningCapacityCbm`，扣除已离仓柜后的可用容量为 `availableBookedCapacityCbm`；按订舱需求中的柜型容量整柜扣除，同柜多票只扣一次，撤销离仓后恢复。日历页面不创建关联，待补柜只做提示。
+
+当前版本明确不做以下写操作：
+
+1. 收货审核通过时，不调用船期日历服务，不写入 `fl_sailing_assignment`、预报消费或船期实收事实。
+2. 创建或修订预报不自动生成船期归班；预报维护接口不作为本轮页面入口。
+3. 取消船期后未离仓货量按上述规则顺延展示；不改写货物实际归属，仍由原智能排柜和订舱流程维护。
+4. 页面不提供货量异常改配、手工绑定实收、订舱关联/解除等操作；这些操作留在现有业务流程。
+
+因此，本轮验收重点从“自动归班正确”改为：船期维护正确、展示口径透明、未发货量顺延且不重复、建议柜数向上取整、取消或截止只影响只读展示，不会改变原收货和智能排柜数据。后续如果需要让管理人员在页面上确认“合并到哪一班”，再单独增加人工确认动作和正式归属模型。

头程到尾程/README.md

@@ -0,0 +1,32 @@
+# 头程到尾程当前维护入口
+
+这里集中列出 F01-F40 全流程变更需要查找和修改的文档；实现与验收范围以[全流程实现对照](头程至实际开船节点冻结矩阵与缺口清单.md)为准。日常只从本目录进入，历史开发材料统一放在[文档归档](../归档/README.md)。
+
+## 当前流程文档
+
+| 用途 | 文档 | 修改什么 |
+|---|---|---|
+| 总览与节点 | [头程到尾程流程节点梳理](../头程到尾程流程节点梳理.md) | 三大业务块、客户进度、后台节点、真实明细和 F01-F40 关系 |
+| 分段流程 | [头程到尾程分阶段流程](../头程到尾程分阶段流程/README.md) | 六个阶段的字段、页面操作、权限、状态和异常 |
+| 货柜入口 | [国内货柜履约 README](../国内货柜履约/README.md) | 分柜、装柜、报关协同、送港和进港的货柜范围 |
+| 报关与船期专题 | [报关资料与船期价格接入梳理](../国内货柜履约/报关资料与船期价格接入梳理.md) | 客户资料、报关行回执、客户确认/打回、正式申报、海关结果和船期价格 |
+| 报关开发交接 | [报关代码开发交接清单](报关代码开发交接清单.md) | 报关代码完成条件、已验收范围和后续增强项 |
+| 头程与报关交互矩阵 | [头程节点与报关清关交互矩阵](头程节点与报关清关交互矩阵.md) | F01-F24 各节点的客户、平台、PDA、报关行和船期交互 |
+| 全流程实现对照 | [全流程节点矩阵与缺口清单](头程至实际开船节点冻结矩阵与缺口清单.md) | F01-F40 节点、现行规则、实现差异和验证边界；保留原文件路径 |
+| 正式申报与海关结果 | [正式申报与海关结果接入设计](正式申报与海关结果接入设计.md) | F22.7 正式申报批次、报关单号、F22.8 查验/补资料/放行/扣货/其他结果及三端边界 |
+| 甩柜改配接入设计 | [甩柜改配接入设计](甩柜改配接入设计.md) | F23.3 原柜人工修改船信息并保留修改历史 |
+
+## 变更查找
+
+- **改客户看到的主节点或三大块关系**：先改总览，再检查对应阶段文档。
+- **改头程下单**：查阶段一、阶段二；费用确认仍是并行事项，不阻断排柜和装柜。
+- **改海运（货柜）**：查阶段三、阶段四和报关专题；报关完成后进入待发区，甩柜只影响船期，实际开船后才进入海运节点。
+- **安排报关开发**：只看[报关代码开发交接清单](报关代码开发交接清单.md)，流程规则回看报关专题，不再从归档的开发规划开始。
+- **改尾程入库和派送**：查阶段五、阶段六。
+- **改页面范围或已确认需求**：查[页面与原型清单](../国内货柜履约/国内货柜履约页面与原型清单.md)和[需求确认表](../国内货柜履约/国内货柜履约需求确认表.md)。
+
+## 归档位置
+
+- [头程到尾程历史文档](../归档/头程到尾程/README.md)：全流程手册、旧现状全景、AI 上下文、易用性方案。
+- [国内货柜履约历史记录](../国内货柜履约/归档/README.md)：开发规划、进度、门禁、验收、审计和旧确认材料。
+- 跨区域认证、权限、统一订单状态、船节点、部署和数据库等正式契约继续留在原业务目录，不归入流程历史归档。

头程到尾程/头程至实际开船节点冻结矩阵与缺口清单.md

@@ -0,0 +1,248 @@
+# 全流程节点矩阵与缺口清单
+
+本文按当前确认结果冻结 F01-F40 全流程范围：从头程下单开始，完成国内履约、报关协同、送港运输、实际开航、海外入库、出库和最终回写。F01-F24 是国内头程至实际开航的前段，F25-F40 是海运目的港及尾程履约。流程基线同时采用《报关代码开发交接清单》和《头程到尾程流程节点梳理》；原型只用于页面字段和承载方式参考。
+
+## 一、阶段边界
+
+```text
+头程下单
+  F01-F13：下单、审核、到仓、测量、计费、费用确认、国内扣货/解除、组托、待分柜
+国内货柜履约
+  F14-F21：分柜、订舱、拖车、拣货、装柜、LOADED
+报关完成后进入待发区
+  F22：报关协同
+  F23：待发区、送港、进港、甩柜、改配
+海运起点
+  F24：承运船舶实际开航
+目的港与海外入库
+  F25-F30：目的港处理、尾程订单、入仓计划、接柜、收货、库存入账
+海外库存与出库
+  F31-F37：库内操作、暂扣、库内服务、排车、生成出库/派送单、拣货发车、出库
+派送与完成
+  F38-F40：签收、异常退回、回访和完成回写
+```
+
+国内前段 F01-F24 的终点是实际开航，全流程继续至 F40；其中 F37 为海外出库。`LOADED` 只表示物理装柜完成；报关完成是进入待发区的前置条件，待发区和船期节点分别保存，不能把其中一条线的结果写成另一条线的结果。
+
+### 实现与验证口径
+
+“已有实现”不等于最新版本已完成验收。下表的既有 HTTP 证据只证明对应报告范围与版本；历史通过不能替代当前完整链路、页面或 PDA 现场验证。报关和运输专项的通过也不能外推为 F01-F40 全部通过。后续增强项不作为首期主流程缺失处理。
+
+当前部署版本、已验证场景和未关闭项统一查阅[测试环境单机部署与配置契约](../测试环境单机部署与配置契约.md)文首的最新验收状态。本文以下带日期的复验记录及矩阵内历史状态保留作为当时证据，不替代该主契约的最新结论。
+
+### 2026-09-30 当前复验结论
+
+**F01-F40 尚未完成逐节点全量验收，不能宣布全部完工或出库以后没有问题。** 以下旧报告保留为对应版本证据，不代表本轮完整验收结论。
+
+- 装柜完成后订单拣货汇总仍显示进行中的缺陷已修复。Firstleg 提交 `e5832d5c` 经测试环境 Jenkins #459 部署成功；服务测试 1,477 项，0 失败、0 错误、9 跳过。本轮实际 HTTP 已在 8 组装柜场景核对订单列表和详情的拣货汇总均为 `COMPLETED`。
+- 本轮已通过实际页面打开普通 FBA 入仓码 `NYEXX2609290171`，核对列表和详情显示已完成；这是买单样本，不能替代同一票退税报关至签收完成的证据。页面截图为后端仓库 `reports/fba-completed-order-page-20260930.jpg`。
+- 当前 Admin 全量 HTTP 复验已于 2026-09-30 11:23（上海时间）结束：11,642 项检查，11,638 通过、4 失败，148 次模块执行、120 个独立模块、7,427 次请求、0 跳过模块，整体未通过。其中 3 条失败来自“真实投递重试与同事件幂等证据”覆盖阻断；重复读取不等于同一事件重复消费，不能据此认定业务重试实现失效。另 1 条为海外托盘汇总接口返回 `A0404`，闲置、占用和报废数量未取得，须定位修复后复验。
+- 海外托盘汇总的 `A0404` 已定位为脚本使用旧路径。已改为现行 `/api/platform/v1/overseas-warehouse-resources/pallets/summary`，相关 9 项离线检查通过；11:28 实际 HTTP 返回成功，总数 3,101 = 闲置 1,915 + 占用 1,010 + 报废 176。证据为 `reports/overseas-pallet-summary-current-20260930.json`。这是定向修复复验，不改写上一轮全量失败结果，也不代表剩余覆盖阻断已解除。
+- 六阶段 77 项明确完成条件已作静态映射，其中 29 项只有部分或间接断言。另有 6 类待补证据：同柜多退税客户确认隔离；正式申报和各类人工海关异常；事件故障后重试与幂等；同一派送退回异常的收货、处理及库存恢复；出库前后库存和流水只扣一次；有效分片未全部签收不得提前完成及客户最终状态/签收文件访问。这些是当前验收覆盖缺口，不自动等于功能缺失。
+- 正式申报批次忽略其他未处理异常而提前关闭的问题已修复，提交 `c7f88030` 经 Firstleg Jenkins #460 部署。之后发现平台公共订舱的船期任务触发器将空客户与平台范围 0 错误比较，以及报关完成后的自动出仓事务不能保证独立提交/回滚；提交 `125ca34b` 已修复，测试环境对应触发器已更新，Firstleg #461 部署成功、容器健康，1,485 项服务测试，0 失败、0 错误、9 跳过。61 项定向测试包含真实事务回滚与重试。
+- 报关 r4 于 12:45（上海时间）结束为 702 项检查、701 通过、1 失败；唯一失败是平台范围船期任务详情读取被正客户范围校验错误拦截。该问题已由 `eae630e6` 修复、Firstleg #462 部署，1,493 项服务测试，0 失败、0 错误、9 跳过，容器健康；原任务详情、历史、唯一出仓船节点/系统历史和访问隔离 6 项真实检查通过。新的完整报关 r5 于 13:10 结束，702 项全部通过、9 个模块、452 次请求、0 跳过模块。范围包含同柜两位退税客户和买单客户、资料/确认隔离、打回替换、正式申报、四类人工异常及全部处理门禁、全部完成文件齐全、客户下载隔离、自动出仓及唯一船期任务/节点/历史。保留 r1-r4 的失败报告，不改写为通过。
+- 客户签收文件接口和页面已部署：后端 `4a14001a` 经 Lastleg #184，客户端功能 `6abb8b7` 随 `6564d412` 经 Client #361。新增“入库订单、派送订单”菜单 `706e3e87` 经 Client #362 部署成功，34 项定向检查通过，实际页面已核对菜单、详情面包屑、签收文件和下载按钮。新尾程 r1 的客户文件 HTTP 检查通过，包含下载字节一致及其他客户拒绝访问；浏览器实际下载等待仍超时，不能记作页面下载通过，也不能用历史页面样本替代本轮同票全流程。
+- 原排车单 `DS-WH-20260930-262785`、原退回异常 `EX-WH-20260930-960514` 的库存来源问题已由 `d320e78b` 修复，经 Lastleg #186 部署且容器健康。原异常使用原托盘、原证据成功完成，恢复 1 箱、只新增 1 条 `RETURN_STOCK_IN`，派送变为 `RETURNED`。首轮续验 r3 为 29 项检查、27 通过、2 失败：实际完成及重放成功，但脚本错误地用余额 DTO 未提供的入仓码字段过滤，漏掉位置。原异常后续对账及原完成请求重放 19 项全部通过，独立核平全部库存桶、目标位置/原票身份及流水，并验证重放零漂移。r2/r3 原失败报告保留。
+- 新完整尾程 r1 于 13:21（上海时间）结束：5,714 项检查，5,706 通过、8 失败，99 次模块执行、75 个独立模块、3,484 次请求、0 跳过模块，整体未通过。其中原异常完整退回/库存恢复和客户签收文件 HTTP 场景已通过；6 条失败来自船期脚本把平台客户范围 0 当作非法 ID，已由 `7f3c0690` 修正，13 项本地检查通过。另 2 条分别为按 SKU 汇总余额与单条真实余额混用导致出库库存取证不完整，以及误把 PDA 任务完成状态当作排车待发状态。脚本已改为从正式 PDA 任务冻结真实余额/位置，独立核对位置、真实余额、客户仓汇总及流水，并分别核对任务与排车状态；23 项本地合同通过。
+- 新尾程 r2 于 13:51（上海时间）结束：5,822 项检查，5,821 通过、1 失败，99 次模块执行、75 个独立模块、3,538 次请求、0 跳过模块。船期范围与发车门禁已通过；唯一失败仍为“PDA扫码及重放实际库存只扣本出库数量一次”，证据显示取证范围 `before=6, after=3, expected=9, SHIPRows=5`，原因正在核对，不能据此宣布出库数量已核平，也不能直接判定为业务重复扣库。该轮退回恢复、重放、客户文件下载及隔离通过；不改写 r1 失败报告。真机与外部第三方覆盖缺口另列，不能计作已验收。
+- 新尾程 r3 于 14:29（上海时间）结束：5,830 项检查，5,828 通过、2 失败，99 次模块执行、75 个独立模块、3,536 次请求、0 跳过模块。正式 PDA 冻结的全部来源位置、原始余额、汇总余额和 SHIP 流水扣减及重放检查通过；r2 的代表入仓码过滤漏取同托其他来源问题已在脚本纠正，保留原失败报告。两项失败均为平台/客户统一订单期望 `COMPLETED`；实际只读诊断确认该根订单原有 4 箱，仅装运签收 1 箱，另有 3 箱真实余量子单未履约。根保持 `PROCESSING`，自身 `OVERSEAS_DELIVERED` 事实只有一次，统一展示 `DELIVERED` 符合未全部完成的门禁；需纠正旧样本预期，并另验两片全部实际签收。证据：`reports/fulfillment-stock-receipt-current-20260930-r3.json`、`reports/root-completion-r3-diagnostic-20260930.json`。
+- 真实 Firstleg → Lastleg 装柜完成事件故障演练已通过：同一事件 12 次真实 ACK 丢失进入 DEAD，受保护接口重试原事件后得到 DUPLICATE 并最终 PUBLISHED，42 项检查全部通过，业务单据/消费事实零新增，生产服务原配置和健康状态已恢复、故障代理已停止。证据：`reports/event-ack-fault-current-20260930.json`。这不外推为反向卸柜/签收事件已取得同事件幂等证据。
+- F40 修复已实现根自身签收事实与全部有效子单完成门禁、最后余量取消后的聚合、事务内历史/事件及 Firstleg 摘要可靠同步；92 项本地测试全部通过，含真实 SQL、事务回滚和并发，API 路由门禁 5 项通过。`041a27c3` 已经 Order #173、Firstleg #463 部署，容器健康；服务测试分别为 317 项零失败/零跳过和 1,500 项零失败/9 跳过。真实两箱、两柜根/余量子单的根先签和子先签专项已实现、本地合同通过，尚待实际 HTTP 和完成 Outbox 唯一发布验收。六阶段 77 项完成条件复核仍有 19 项证据不足，客户页面实际下载也未通过；这些不能按总断言数量折算完成率。
+- 后续补验发现人工完成接口仍能绕过余量完成门禁，以及真实余量子单再次装柜时托盘标签数量为 0。两项已分别由 `71202bce`、`1a7e4800` 修复，统一提交 `1a7e4800` 经 Order #174、Firstleg #464 部署且健康；服务测试分别为 318 项零失败/零跳过、1,517 项零失败/9 跳过。原失败余量子柜重新准备标签及全部/指定仓 PDF 打印均通过；旧人工完成入口返回 `A0404`，原未完成根单的状态、版本、历史及完成事件零变化，8 项真实检查全部通过。证据：`reports/node-closure-original-regression-20260930-r1.json`。两片全部签收和合法取消末票余量仍待实际验收。
+- 尾程补充只读取证已核对 123 项事实、11 项负向自检：8 个来源各唯一关联尾程/入仓单；标准 6 票在途共 12 箱，全部 8 票的 13 条入库流水及 13 条收货记录共 20 箱且完整键匹配；每票各有一次 `INBOUND_COMPLETED`；5 柜首次收货时间及完成结果一致，5 组卸柜 Outbox/Inbox 各一次、事件 ID/摘要/负载一致且均已发布/处理，国内还空预估精确为卸柜后 72 小时。原 r1 错误事件字面量的查询不作为事件结论，实际事件证据取修正后的 r2。核验结果为 `reports/tail-node-readonly-evidence-20260930-r1-verified.json`；这是当前/不可变事实，不能替代收货重放前后完整库存零漂移，不能换算为 77 项完成条件全部通过。
+- 最新逐条审计 `reports/fba-stage-completion-audit-current-20260930-r2.json` 已按现行六阶段正文重新核对 77 条完成条件，65 条具备本轮限定范围证据，12 条仍待闭环；这不表示 65 条已完成全部产品/页面验收，不换算总体完成率。待补条件为 C05 订单类型/申报组合、C21 同退税柜改船前后报关摘要稳定、C36/C37 共托逐箱权属与冻结快照、C39 不提前创建国内库存、C49 收货重放完整库存前后、C52 排车线路目的地集合、C60 反向完成同事件去重、C62 根/余量全部签收与合法取消完成回写、C63 客户最终状态及页面下载、C66 独立船异常、C77 重试资源锁数量。已由用户确认拆为 4 个独立任务，总控在本对话汇总；稳定职责与任务 ID 见 `docs/独立任务协作登记.md`。
+- 阶段三、四、六文档已统一客户文件确认链、原柜人工改船、统一 Gateway 和事件直接投递。船期任务可在出仓确认后创建并查询进港事实，只有实际开航才推进海运节点。全部业务页面仍无逐节点完整操作证据。
+
+本轮证据位于后端仓库：`reports/firstleg-node-convergence-deploy-20260930.json`、`reports/firstleg-node-convergence-local-20260930.log`、`reports/admin-full-current-20260930-r1.json`、`reports/fba-stage-coverage-audit-20260930.json`、`reports/customs-open-exception-deploy-20260930.json`、`reports/customs-auto-dispatch-atomic-deploy-20260930.json`、`reports/customs-multi-customer-current-20260930-r4.json`、`reports/lastleg-return-receipts-deploy-20260930.json`、`reports/lastleg-return-sku-source-deploy-20260930.json`、`reports/dispatch-return-same-exception-current-20260930-r2.json`、`reports/client-receipt-download-deploy-20260930.json`。静态审查、局部修复通过和单票完成均不能替代全流程验收。
+
+最新专项证据：`reports/customs-multi-customer-current-20260930-r5.json`、`reports/carrier-platform-scope-deploy-20260930.json`、`reports/lastleg-canonical-return-deploy-20260930.json`、`reports/dispatch-return-current-reconciliation-20260930-r2.json`、`reports/fulfillment-stock-receipt-current-20260930-r3.json`、`reports/client-order-navigation-deploy-20260930-r2.json`、`reports/root-completion-local-20260930-r2.json`、`reports/node-closure-order-deploy-20260930.json`、`reports/node-closure-firstleg-deploy-20260930.json`、`reports/node-closure-original-regression-20260930-r1.json`、`reports/tail-node-readonly-evidence-20260930-r1-verified.json`。完成门禁和后续修复已部署；剩余实际验收边界见上文。
+
+### 2026-09-29 对应版本历史证据
+
+2026-09-29 修复后的默认全量真实 HTTP 回归已通过：Admin 11,627 项检查、120 个模块、7,429 次请求，0 失败、0 跳过模块；Client 195 项检查全部通过。F31 换托同库位比较、A0 共享溢出位移库、F33 无贴标转仓查询及跨服务错误处理已修复并部署测试环境；验收脚本补齐直接贴标审核、返工重新领取及禁止回移虚拟收货位的边界。离线合同 128 个文件、773 项断言全部通过。
+
+同票普通 FBA 主链证据为入仓码 `NYEXX2609290171`、柜次 `D1063`、柜号 `TSTU3425326`、排车单 `DS-WH-20260929-067073`、出库单 `OB-WH-20260929-158402`；两张目的仓派送单签收后，已核对来源入仓单 `DELIVERED` 和来源订单 `COMPLETED`。随后故意执行的退回异常测试会改变留存单据状态，不能把最终留存状态误读成未曾完成。退税报关分支另由同一全量报告中的混合柜检查覆盖，不冒充同一票退税至签收证据。
+
+对应证据：`baiyue-firstleg/reports/admin-full-current-20260929-r7.json`、`reports/client-full-current-20260929-r3/client-test-env-20260929063613-e54d44dd.json`、`reports/fba-main-chain-evidence-20260929.json`（后两个路径同属后端仓库）。Admin/Client 报关详情已按 1920×1080 页面核对；船期日历网络恢复后重载正常。未离仓测试柜 `TSTU7897110` 已实际验证首次发送、普通文本回执上传、客户确认后的平台执行、正式申报、其他理由必填备注、异常保存与人工处理；客户确认通过该客户自己的 HTTP 接口完成。异常处理后回执确认保留，未上传完税文件仍保持报关中并阻断离仓。
+
+页面复验发现并修复异常发生时间早 8 小时的问题：国内 `LocalDateTime` 接口改为接收上海业务时间。Admin 提交 `4ead51a5feedf65be9443ddfe3dd45da7ca49e64` 已通过测试环境 Jenkins #482 部署；262 个测试文件、2,121 项测试和构建通过。部署后真实页面新增查验记录的发生时间与服务器记录时间相差 0.879 秒。详见后端仓库 `reports/customs-time-postdeploy-20260929.json` 和 `reports/customs-other-resolved-1920-20260929.jpg`。Android 真机、弱网和外部船司正式凭据仍属于单列验证边界，不纳入本次内置浏览器与 HTTP 通过结论。
+
+## 二、F01-F40 节点冻结矩阵
+
+| 节点 | 客户可见进度 | 后台业务对象 | 必须形成的真实事实 | 当前状态 | 本阶段缺口 |
+|---|---|---|---|---|---|
+| F01-F07 | 待下单、审核中、已审核 | 企业、订单、审核任务 | 提交、补件、审核、入仓单生成 | 已有主链 | 按现有订单契约回归，不在本轮重做 |
+| F08-F10 | 待到仓、测量中、待确认 | 入仓单、测量记录 | 收货、扫码、称重、测量、审核 | 已有主链 | 只核对是否能稳定产出排柜事实 |
+| F11 | 费用待确认 | 费用版本、客户确认记录 | 计费推送、客户主动确认、版本留痕 | 已有实现；旧总览的默认确认表述与阶段二及服务指引冲突 | 按现行规则，装柜可自动发布费用，但不能代替客户确认；不将缺少 `SYSTEM_AUTO_AT_LOADED` 列为必修代码缺陷 |
+| F12 | 国内扣货中、已解除 | 国内入仓单 HOLD 记录 | 扣货、解除、原因和后续作业门禁 | 已实现；最新全量 inbound-hold 模块通过 | 与报关海关异常、海外库存暂扣分别维护，不能混为同一节点 |
+| F13 | 待组托、待分柜 | 一件代发清点、托盘和封托记录 | 逐箱清点、归托、封托 | 已有主链 | 结合一件代发路径验证；不要求普通散货重复执行一件代发清点流程 |
+| F14-F20 | 待分柜、订舱中、装柜中 | 柜次、装柜计划、拖车、PDA 任务 | 分柜、订舱、排车、拣货、照片、铅封、数量核对 | 主链已有 | 核对真实柜号、订舱和装柜快照能否冻结 |
+| F21 | 国内已装柜 | 装柜计划、物理货柜、装柜证据 | 实际柜号、实装箱数、装柜证据、`LOADED` | 已有 | 报关案例按最终实装范围建立；部分装柜只显示已装箱数并标记线下处理，不在系统内自动分摊 |
+| F22.1 | 报关确认中 | 柜级报关聚合内的客户资料范围 | 每客户范围、入仓码范围、混合柜隔离、实装范围回显 | 已实现并通过真实 HTTP 验收 | 独立“案例”对象仍可在正式批次设计时补充；部分装柜仍线下处理 |
+| F22.2 | 待提交资料、待补资料 | 客户资料包 | 上传、替换、关联范围、版本、冻结 | 已实现并通过真实 HTTP 验收 | 首期不维护资料类型清单；有文件即可上传，补件通过人工异常理由和备注说明 |
+| F22.3 | 已发送报关行 | 独立首次发送批次 `brokerSubmission` | 业务批次号、发送人、发送时间、冻结版本、资料快照、幂等历史 | 已实现并通过定向测试与测试环境部署 | 报关行接收确认和回执轮次对象待补 |
+| F22.4 | 待客户确认 | 回执/完成文件版本 | 文件版本、关联客户范围、客户可下载 | 已实现；回执历史和确认动作历史均只读投影 | 独立回执返回时间/下载凭证仍待补 |
+| F22.5 | 客户确认中、已打回 | 客户确认记录与动作历史 | 确认/打回、回执版本、操作人、时间、原因 | 已实现并通过定向测试与测试环境部署 | 通知聚合和报关行回执轮次待补 |
+| F22.6 | 等待整柜确认 | 完税文件齐全门禁 | 所有退税客户确认、发送执行、真实完税文件齐全 | 已实现并通过专项真实 HTTP 验收 | 查验、扣货、补资料作为平台人工异常节点处理，不新增自动凭证门禁 |
+| F22.7 | 已提交正式申报 | 正式申报批次 | 报关行确认、正式申报时间、操作人、批次、报关单号 | 已实现并通过真实 HTTP 7 步联调 | 后续可补报关行接收时间和下载凭证 |
+| F22.8 | 查验中、待补资料、已放行、扣货/其他 | 海关结果事实 | 报关单号、结果类型、时间、人工理由、备注和处理结果 | 已实现；真实 HTTP 与人工异常页面保存/处理通过，发生时间偏差已修复并部署复验 | 不接短信或自动海关系统；真机及外部系统不在页面验证范围 |
+| F23.1 | 待发区、送港中、已离仓 | 待发区与送港/出仓任务 | 报关完成时间、待发区门禁、离仓时间、车辆/任务、操作人、证据 | 已实现并通过真实 HTTP 验收 | 继续补待发区客户/平台投影展示 |
+| F23.2 | 已送港、已进港 | 运输和港口事实 | 送港时间、进港时间、来源和凭证 | 已实现；平台范围船期详情错误已部署修复，原任务与新报关 r5 均通过 | 继续补充实际页面操作证据 |
+| F23.3 | 已甩柜、等待改船后承运 | 船期记录修改历史 | 甩柜原因、发生时间、修改前后船名/航次/船期、处理人 | 已实现并通过测试环境真实 HTTP；平台与客户端最新船期投影一致 | 继续补页面截图和更复杂异常分支；柜次、订舱关联和报关事实不变 |
+| F24 | 海运中 | 船次实际节点 | 承运船舶、航次、实际开航时间、来源/凭证 | 已实现；实际节点与查询任务已有真实 HTTP 证据 | 继续补充最新一轮页面证据；只允许实际开航事实推进海运节点 |
+| F25 | 目的港处理中、待海外接柜 | 船节点、目的港清关/提柜、尾程订单 | 到港、卸船、清关、提柜和可接柜事实 | 已实现并有综合真实 HTTP 证据 | 外部码头/车队差异继续按异常分支补充 |
+| F26 | 尾程订单待建计划 | 跨区事件、尾程订单 | 装柜完成、船节点和来源入仓单快照可靠投递与消费 | 正常投递及 Firstleg→Lastleg 真实 ACK 丢失、DEAD 原事件重试、零重复 42 项通过 | 继续补逐来源唯一尾程映射和收货前在途库存归属证据 |
+| F27 | 待建立海外入仓计划 | 入仓计划、计划托盘和资源锁 | 按柜内每票生成计划、预计到仓和托盘资源冻结 | 已实现并有综合真实 HTTP 证据 | 继续补齐异常重试页面证据 |
+| F28 | 待接柜、接柜中 | 海外 PDA 接柜会话 | 柜号认领、三类签收照片和签收确认 | 已实现并有综合真实 HTTP 证据 | Android 真机验收仍是独立非阻塞项 |
+| F29 | 入库中 | 海外 PDA 收货任务 | FBA 散货、海外仓逐箱、一件代发整托等实收事实 | 已实现并有综合真实 HTTP 证据 | 继续补充现场设备和弱网证据 |
+| F30 | 入库完成 | 入库任务、库存和跨区回写事件 | 全柜核平、库存同事务入账、卸柜完成事件 | 已实现并有综合真实 HTTP 证据 | 保持事件幂等和库存数量守恒 |
+| F31 | 库存可用、库内服务中 | 库存、库位、托盘、盘点 | 上架、移库、合托/拆托、盘点和库存流水 | 已实现并有综合真实 HTTP 证据 | 继续补充大批量库存性能验收 |
+| F32 | 暂扣中、已解除 | 暂扣记录和库存锁 | 暂扣原因、解除原因、操作人和库存可用性变化 | 已实现并有综合真实 HTTP 证据 | 暂扣与出库并发场景继续补充 |
+| F33 | 换标/转运/废弃处理中 | 换标、转运、废弃子单 | 客户确认、箱唛/托盘变更、库存锁和实际扣减事实 | 已实现并有综合真实 HTTP 证据 | 继续补充复杂返工和跨仓异常 |
+| F34 | 待派送、排车中 | 智能预排、排车单 | 候选、草稿锁、正式排车和目的仓分配 | 已实现并有综合真实 HTTP 证据 | 继续补充多车多目的仓页面证据 |
+| F35 | 待转派送、待出库 | 排车转派送、出库单、派送单 | 出库/派送单生成、目的仓拆分、费用只发布一次 | 已实现并有综合真实 HTTP 证据 | 保持转派送前不可发车 |
+| F36 | 拣货中、待发车 | 海外 PDA 排车任务 | 托盘扫描、数量核平、车辆资料和发车门禁 | 已实现并有综合真实 HTTP 证据 | Android 真机和弱网恢复仍需专项验证 |
+| F37 | 已出库、派送中 | 出库单、派送单 | 出库完成、库存扣减和派送任务关联 | r3 拣货、发车、重放的来源位置/原始余额/汇总/SHIP 流水数量及零重复通过 | 不将整轮仍有其他失败的报告描述为全流程通过 |
+| F38 | 派送中、已签收 | 派送单、签收凭证 | 签收文件、签收时间和每个目的仓派送完成 | 已实现；当前部署、文件操作与隔离验收范围见[测试环境主契约](../测试环境单机部署与配置契约.md)的 C63 记录 | 原样本下载缺口已有通过证据，其他样本/格式及逐节点页面边界以主契约为准，不沿用旧“浏览器下载未通过”结论 |
+| F39 | 异常退回处理中 | 异常单、退回入仓和库存恢复 | 拒收/部分拒收、退回、库存恢复和原因历史 | 不可变出库来源解析已部署修复，原异常成功恢复及重放/完整对账通过 | 新完整尾程生命周期及多次退回/部分恢复组合场景待验 |
+| F40 | 已完成、待回访 | 客户回访、跨区完成事件、订单回写 | 回访记录、`DELIVERED` 回写及订单 `COMPLETED` 收口 | 已实现根单余量门禁及可靠完成回写；当前版本和各签收次序/恢复场景的验收事实见[测试环境主契约](../测试环境单机部署与配置契约.md) | 两种签收次序、取消、同事件和完成 Outbox 幂等均须分别核对对应证据；新车辆退回重派组合及逐节点页面不得由历史局部通过推定关闭 |
+
+## 三、当前实现与目标的主要断点
+
+### 1. 客户范围和首次发送批次已落地，回执轮次属于后续增强
+
+当前 `fl_customs_container` 仍是柜级状态聚合，但客户资料通过客户和入仓码范围隔离，真实验收已覆盖同柜多客户和混合柜。正式申报批次、海关结果事实、首次发送报关行批次和客户确认动作历史已经独立落地；尚未独立建模的是报关行接收回执、回执轮次和更细的客户案例聚合。
+
+### 1.1 费用自动发布与客户确认必须区分
+
+阶段二“费用计费与确认”和 `baiyue-firstleg/firstleg/AGENTS.md` 明确规定：费用不阻断排柜和装柜，装柜完成不得代替客户自动确认，客户确认与本票装柜完成共同构成最终冻结条件。`FbaPricingService.autoSendAfterLoadingCompleted` 执行平台费用确认与发送，`confirmByCustomer` 才记录客户确认人和时间；`SENT` 不等于客户确认。旧总览要求 `SYSTEM_AUTO_AT_LOADED` 的表述与现行规则冲突，不能据此直接新增自动代客确认。若未来明确改变该规则，再同步费用版本、确认来源和冻结边界。
+
+### 1.2 海关异常按人工节点处理
+
+海关短信由平台人员人工查看和操作，系统不接短信、不自动判断查验或扣货。平台在正式申报批次上人工标记异常，选择“查验”“扣货”“补资料”或“其他”等理由；选择“其他”时填写备注，后续由平台人员人工解除或录入处理结果。异常是申报批次上的附加事实，不改变已上传资料、回执和客户确认历史。
+
+目标至少需要以下关系：
+
+```text
+物理货柜
+  ├─ 最终实装快照
+  ├─ 客户报关案例 × N
+  │    ├─ 客户资料包与版本
+  │    ├─ 报关行回执轮次 × N
+  │    └─ 客户确认/打回记录与动作历史 × N
+  ├─ 整柜正式申报批次
+  └─ 海关结果事实 × N
+```
+
+### 2. 当前“报关完成”仍需与正式申报、海关结果区分
+
+现有完成动作是平台上传每份完成文件，或对全买单柜直接确认；客户确认和完成文件链路已有真实验收。正式申报批次、报关单号和海关结果已经分别记录，仍不能把其中任何一个状态直接当成海关放行或所有运输事实。
+
+### 3. 报关完成与待发区的门禁关系
+
+当前 `CustomsDispatchGateContributor` 要求 `fl_customs_container.status=COMPLETED` 才通过国内出仓门禁，`CustomsAutoDispatchCoordinator` 也在报关完成后自动尝试确认出仓。按最新口径，这不是冲突：报关完成后货柜进入待发区，待发区是送港运输真正开始前的状态门槛；甩柜只在船期运输层处理，不触碰报关事实。
+
+需要重新定义：
+
+- 待发区门禁先检查报关 `COMPLETED`，再叠加装柜、PDA、订舱、证据等运输条件；通过后只推进到 `WAITING_FOR_LOADING`。
+- 报关线单独保存客户确认、整柜申报和海关结果；这些事实不会被船期修改覆盖。
+- 报关完成事件只能推进待发区，不得自动伪造送港、进港或开船事实。
+- 实际开航只能由船次实际节点推进。
+
+### 4. 客户端基础报关协同闭环已完成
+
+当前客户端 `CustomsDocumentsView.vue` 提供独立报关资料列表和待办入口，`CustomsDocumentsDialog.vue` 已支持上传、替换、调整关联入仓码、查看和下载报关行回执/真实报关完税文件、确认整份回执和填写原因打回，并展示回执历次上传版本及确认/打回动作历史；仍缺少：
+
+- 客户案例的进度和通知。
+
+### 5. 平台端基础整柜协同闭环已完成
+
+当前 `ContainerCustomsPanel.vue` 已展示退税资料、首次发送报关行批次、回执/完成文件、客户范围、确认状态、回执历次上传版本和确认/打回动作历史，并支持正式申报批次和海关结果基础操作；仍缺少：
+
+- 按客户查看案例和实际装柜覆盖；
+- 报关行接收回执和回执轮次管理；
+- 报关行接收回执时间和下载凭证等更细历史。
+
+## 四、接口、权限、审计和测试缺口
+
+### 接口与数据库
+
+- OpenAPI 不能继续只暴露旧的四态 `ContainerView`。
+- 需要继续补充报关行接收回执、回执轮次和下载凭证的查询/命令契约；资料包、首次发送批次、回执版本和确认动作只读历史、整柜申报和海关结果基础契约已落地。
+- 文件仍由 File 服务保存，但每个文件必须绑定业务类型、客户案例/申报批次、版本和覆盖范围。
+- 每个写命令都要带版本和幂等键；重放同参数返回原结果，不同参数返回冲突。
+- 换柜时需要保留新旧柜关联；部分装柜只记录已装箱数和线下处理标记，不在系统内自动做数量分摊或覆盖旧资料。
+
+### 权限
+
+至少区分：
+
+- 客户上传、替换、补件、确认、打回；
+- 平台客服接收、核对、退回补件；
+- 平台报关操作员发送报关行、上传回执、提交正式申报；
+- 平台人员录入查验、放行、扣货及其他海关结果；
+- 客户和平台各自的只读下载权限。
+
+### 审计
+
+需要保留客户范围、资料版本、回执轮次、确认人、打回原因、提交批次、报关单号、异常理由、备注和操作时间。客户 A 的动作不能出现在客户 B 的案例中；柜级汇总可以看到客户名和业务编号，但客户端只能看到自身范围。
+
+### 测试
+
+最小验收矩阵至少覆盖：
+
+1. 单客户和多客户同柜。
+2. 一客户打回时其他客户继续保持已确认。
+3. 同一请求重放、同幂等键换参数、版本冲突。
+4. 未全部客户确认时正式提交被拒绝。
+5. 正式申报、查验、不查验放行、扣货和其他结果分别显示。
+6. 报关完成后货柜进入待发区，等待船舶承运。
+7. 甩柜改配在原柜上人工修改船信息并留痕，柜子和报关事实不变。
+8. 只有实际开航事实推进 F24。
+9. 客户越权读取同柜其他客户资料被拒绝。
+10. 部分装柜能显示实际箱数并留下线下处理标记；换柜不能直接覆盖原案例和历史回执。
+
+## 五、后续增强（无需当前业务确认）
+
+以下内容不阻断当前开发：回执接收时间、回执轮次和下载凭证可以后续增强；海关短信、查验、扣货、补资料和其他异常按平台人工标记、选择理由和填写备注处理。
+
+### 已冻结的业务规则
+
+| 规则 | 冻结口径 | 依据 |
+|---|---|---|
+| 资料提交时点 | `LOADED` 后按最终实装快照建立客户案例并进入本轮报关 | 交接清单“一、必须实现的报关流程”；总流程 F21/F22 |
+| 同柜客户边界 | 一个客户案例只属于一个客户；同一客户多个入仓码可以共享资料，但跨客户正式合报默认禁止 | 报关专题“申报组与柜级总览”“买单、退税和混合柜完成条件” |
+| 回执与客户确认 | 首期以报关行回执文件为主，客户对整份回执确认；回执上传不等于客户确认 | 本轮业务确认 |
+| 资料与部分装柜 | 报关资料、报关行回执都按文件保存；部分装柜只展示箱数，线下人员处理后续，不做系统内数量分摊 | 本轮业务确认 |
+| 首期正式申报 | 由平台授权人员人工提交并回填报关行确认和海关结果 | 本轮业务确认；报关专题状态约定 |
+| 报关与待发区关系 | 报关完成后货柜才能进入待发区；待发区是等待船舶承运的运输状态，报关和船期事实分开保存 | 本轮业务确认 |
+| 海运起点与改配 | 首期人工录入实际开航；甩柜/改配只变更船期/航次，不重新处理已完成报关资料；只有实际开航事实推进 F24 | 本轮业务确认；交接清单第二条；总流程 F23/F24 |
+
+### 本轮补充确认的甩柜/改配口径
+
+| 项目 | 已确认口径 |
+|---|---|
+| 发起与确认 | 平台人员直接编辑原柜船期，记录操作人、时间、原因和修改前后船信息。 |
+| 资料继承 | 报关完成后资料、平台回执和客户确认与船期独立；甩柜/改配不触发重新上传或重新确认。 |
+| 航次任务 | 平台人工修改原柜船信息，继续使用原任务；保留修改历史和已有节点。 |
+
+### 已确认的字段和操作规则
+
+1. （已确认）首期不维护资料类型清单和逐项责任人；资料包只要有文件即可上传、替换和留版本。
+2. （已确认）查验、扣货、补资料和其他结果由平台人员人工标记异常、选择理由；选择“其他”时填写备注，异常解除也由平台人工点击。
+3. （已确认）第一版由平台人员直接修改原柜船名、航次和船期，填写原因并保留修改历史。
+4. （已确认）平台人工修改原柜船名、航次和船期；柜子与原任务不变。
+5. （已确认）原航次退税资料、回执和客户确认与船期独立，甩柜/改配不触发重新确认。
+6. （已确认）修改船信息不生成实际开航事实；只有本柜实际随船开航后才记录 `DEPARTED_ORIGIN_PORT`。
+
+### 代码接入前置缺口
+
+最新确认取消新增航次对象和重建任务的方案。复用现有船期编辑及修改历史，柜次、订舱关联和查询任务保持不变。测试环境已核验平台与客户端都会投影修改后的最新船期，报关资料、回执、完成文件和客户确认保持不变；证据见 `baiyue-firstleg/reports/platform-and-client-transport-projection-20260927.json`。
+
+## 六、冻结结论
+
+- 全流程基线覆盖 F01-F40；F01-F24 终点为实际开航，F25-F40 继续完成目的港、海外入库、出库、派送和最终回写。
+- F22 报关完成后货柜进入 F23 待发区；甩柜/改配只改变运输航次，不改变报关事实。
+- 客户确认、报关行回执、整柜正式申报、海关放行、离仓、进港、甩柜和实际开航都是独立事实。
+- 节点清单覆盖完整范围；各节点实现与验证程度以表内状态为准，不将整张矩阵标为全部验收完成。
+- F25-F40 已有实现，最新默认全量 HTTP 回归已通过，并核对同票签收后的国内完成回写；本轮报关可写异常页面操作已完成，设备和外部船司边界继续单列，不能用 HTTP 全绿替代这些证据。

头程到尾程/头程节点与报关清关交互矩阵.md

@@ -0,0 +1,78 @@
+# 头程节点与报关清关交互矩阵
+
+> 本文把 F01-F40 全流程中的头程、海运与报关清关交互放在同一张图里；其中 F01-F24 是国内头程到实际开航，F25-F40 由阶段四至阶段六继续承接。报关资料只适用于包含退税货物的柜，买单货物不创建客户资料协同。
+
+## 一、总链路
+
+```text
+客户下单/入仓
+  → 收货、测量、计费、费用确认
+  → 分柜、订舱、拖车、PDA 装柜
+  → LOADED（物理事实）
+  → 客户上传报关资料
+  → 平台冻结资料并首次发送报关行（生成独立批次）
+  → 报关行回执
+  → 客户确认整份回执/打回
+  → 平台把客户确认后的回执发送报关行执行
+  → 报关行完成
+  → 平台上传真实报关完税文件
+  → 报关完成
+  → 待发区、送港、进港
+  → 甩柜/改配只修改原柜船期
+  → 实际开航
+```
+
+`LOADED` 是 PDA 产生的装柜事实，也是当前客户报关详情的准入条件；PDA 不参与资料、回执、确认或完税文件接口。报关完成是待发区的门禁，实际开航只由船次实际事实推进。
+
+## 二、F01-F21：报关前的头程节点
+
+| 节点 | 客户动作 | 平台动作 | PDA/运输动作 | 报关影响 |
+|---|---|---|---|---|
+| F01-F07 下单、审核、补件 | 提交订单、补充订单信息 | 审核订单、生成入仓单 | 无 | 仅确定客户、订单和退税/买单属性；不创建报关资料 |
+| F08-F10 到仓、收货、测量 | 查看入仓进度 | 收货、扫码、称重、测量并审核 | 仓内作业 | 形成后续实装范围的来源数据 |
+| F11-F13 计费、费用确认、组托、待分柜 | 查看/确认费用 | 发布费用版本、记录确认、组托封托 | 无 | 费用确认不能代替报关资料确认 |
+| F14-F20 分柜、订舱、拖车、拣货、装柜中 | 查看柜次和船期 | 建立柜次、订舱、拖车和装柜计划 | PDA 领取、拣货、复核、装柜 | 仍不能启动客户报关资料入口 |
+| F21 `LOADED` | 查看实际装箱数 | 固化实际柜号、实装箱数和装柜证据 | PDA 提交并产生 `LOADED` | 按最终实装范围建立退税客户报关资料范围 |
+
+部分装柜只回显实际箱数并留下线下处理标记，系统不自动分摊数量，也不覆盖原始资料范围。
+
+## 三、F22：报关平台与客户交互
+
+| 子节点 | 平台页面/接口 | 客户页面/接口 | 关键状态与门禁 |
+|---|---|---|---|
+| F22.1 建立资料范围 | Admin 查看柜级退税客户、入仓码和实装范围 | Client 只能看到自身订单范围 | 退税客户按租户和入仓码隔离；买单客户不建资料 |
+| F22.2 客户上传资料 | `GET /api/platform/v1/customs/loading-plans/{planId}` 查看汇总 | `GET /api/merchant/v1/customs/orders/{orderId}`；`POST .../documents/upload`；可替换、调整入仓码范围 | 当前要求 `LOADED`；资料版本和幂等键受门禁控制 |
+| F22.3 首次发送报关行 | Admin `POST .../{planId}/send-to-broker` | 只读看到批次和发送时间 | 资料全部冻结后生成独立 `brokerSubmission` 批次；未首次发送不能上传回执；只适用于含退税货物的柜 |
+| F22.4 上传回执 | Admin `POST .../documents/{documentId}/receipt/upload` | `GET .../receipt/download` | 回执进入 `PENDING`；回执不是报关完成文件 |
+| F22.5 客户确认/打回 | Admin 查看每客户回执状态 | `POST .../receipt/confirm` 或 `.../receipt/reject` | 确认整份回执；打回必须填写原因；版本冲突拒绝 |
+| F22.6 回执冻结与执行 | Admin `POST .../{planId}/submit-to-broker` 再次发送客户确认后的回执 | Client 只能查看确认结果和动作历史 | 发送执行后回执不能替换；`brokerSubmittedAt` 仅表示发送执行时间 |
+| F22.7 正式申报与报关行完成 | Admin 创建/提交正式申报批次、回填报关单号，并上传真实报关完税文件：`POST .../final/upload` | `GET .../final/download`；只读批次投影 | 完税文件齐全后整柜状态才可 `COMPLETED`；正式申报批次和完税文件是两件事，不能把回执或客户确认当成正式申报 |
+| F22.8 清关结果 | 平台人工补录查验、补资料、放行、扣货等独立事实；可处理未决结果 | 客户只读查看自身可见结果和凭证 | 已落地 `customs_declaration_batch`、`customs_clearance_result`；结果不推进待发区、船期或 PDA |
+
+当前客户端状态映射：`WAITING_UPLOAD` → `DOCUMENT_UPLOADED` → `DECLARING` → `CUSTOMS_COMPLETED`。平台柜级状态映射：`WAITING_CUSTOMER_DOCUMENTS` → `READY_TO_START` → `DECLARING` → `COMPLETED`。`COMPLETED` 仍需继续与正式申报、海关放行和运输节点拆开。
+
+## 四、F23-F24：报关完成后的运输交互
+
+| 节点 | 平台动作 | 客户可见内容 | 报关资料处理 |
+|---|---|---|---|
+| F23.1 待发区、送港、离仓 | 报关完成后通过待发区门禁，记录送港/离仓事实 | 查看待发、送港状态和当前船期 | 资料、回执、完税文件只读保留 |
+| F23.2 进港 | 记录进港时间、来源和凭证 | 查看进港节点 | 不改变报关状态 |
+| F23.3 甩柜/改配 | 平台人员编辑原柜船名、航次、预计时间并记录前后值、原因、操作人 | 查看修改后的当前船期和历史 | 柜号、订舱关联、资料、回执、客户确认和完税文件不变，不重新确认 |
+| F24 实际开航 | 人工录入承运船舶实际开航事实 | 查看海运已开航 | 只记录关联关系，不重做报关 |
+
+甩柜只改变运输信息，不生成新柜、不重建报关任务、不把预计船期修改误写成实际开航。
+
+## 五、当前接口覆盖与待补项
+
+已落地并部署的基础闭环：客户资料上传/替换/范围调整、平台查看、冻结资料首次发送报关行并生成独立批次、回执上传及历次版本只读投影、客户整份回执确认/打回及动作历史、平台发送报关行执行、真实完税文件上传/下载、退税与买单分流、版本和幂等门禁；当前平台与客户页面均读取最新预计船期字段，实际开航字段单独保留。
+
+仍需补齐：
+
+1. 报关行接收确认、回执轮次和回执下载凭证的独立对象及更细历史投影。
+2. 待发区客户/平台投影的更细页面展示和截图证据；`LOADED → 报关 → 待发区` 已在混合柜报告中通过，平台与客户改船后的当前船期双端回读已验收。F25-F40 的海运目的港、海外入库、库存、出库、派送和最终回写由阶段四至阶段六维护，综合证据见 `baiyue-firstleg/reports/admin-overseas-chain-final-fixture-20260924.json`。
+
+正式申报批次和海关结果已在本轮实现并通过真实 HTTP：平台创建/提交批次、录入查验、查询并处理结果，客户按自身订单查询结果；证据见 `baiyue-firstleg/reports/formal-customs-declaration-and-clearance-result-20260927.json`。
+
+报关专项真实 HTTP 证据、构建号和当前 PDA 边界见[报关代码开发交接清单](报关代码开发交接清单.md)、`baiyue-firstleg/reports/focused-customs-flow-without-pda-20260927.json`、`baiyue-firstleg/reports/customs-mixed-20260927i.json` 及 `baiyue-firstleg/reports/customs-prep-container-20260926.json`。专项证据验证客户确认回执、发送报关行、上传完税文件和客户回读 `COMPLETED`，没有调用 PDA；新建混合柜全链路报告已通过 532/532。
+
+F22.7/F22.8 的独立批次、报关单号和海关结果设计见[正式申报与海关结果接入设计](正式申报与海关结果接入设计.md)；该设计不改变现有两份文件闭环，也不把结果事实写入船期或 PDA 状态。

头程到尾程/报关代码开发交接清单.md

@@ -0,0 +1,110 @@
+# 报关代码开发交接清单
+
+> **当前状态：报关协同已接入测试环境。** 客户资料、首次发送报关行批次、回执、客户确认历史和真实完税文件已形成独立链路；海关查验、扣货、补资料和其他结果由平台人员人工标记异常、选择理由并填写备注，不接短信或自动海关系统。报关行接收回执和下载凭证仍可后续增强。头程至尾程的全流程范围和缺口以[头程至实际开船节点冻结矩阵与缺口清单](头程至实际开船节点冻结矩阵与缺口清单.md)为准；流程规则以[报关资料与船期价格接入梳理](../国内货柜履约/报关资料与船期价格接入梳理.md)为准，节点关系以[头程到尾程流程节点梳理](../头程到尾程流程节点梳理.md)为准。
+
+> **本轮补充确认：** 首期报关行回执以文件为主，客户确认整份回执；正式申报由平台授权人员人工提交并回填结果；报关完成后货柜进入待发区；实际开航首期人工录入，甩柜/改配只变更船期，不重新处理已完成报关资料。
+
+> **验收证据：** 既有全链路报告保留旧版 526/526、混合柜 532/532 记录；本轮新增代码、数据库和三端已部署，已用现有完成柜做接口烟测并核对首次发送门禁。完整造数到报关回归已补齐测试环境专用国内 PDA 作业员并通过；当前报关主链报告为 543/543，运输节点报告为 1036/1036。
+
+## 一、必须实现的报关流程
+
+从装柜完成（`LOADED`）开始，按柜内客户分别处理：
+
+1. 按最终实装清单建立客户报关案例和资料包。
+2. 收集客户上传、替换或补充的资料，冻结后由平台生成独立批次首次发送给报关行。
+3. 接收报关行回执并发给对应客户确认。
+4. 客户打回时，只重开对应客户当前轮次，重新上传、重新发送并生成新回执；保留每轮资料、回执、确认人、时间、动作历史和打回原因。
+5. 柜内所有客户确认后，平台发送客户确认后的回执给报关行执行。
+6. 报关行执行完成后，平台上传真实报关完税文件；全部退税资料对应的完税文件齐全后，整柜报关完成。
+7. 分别记录海关查验、不查验放行、扣货或其他正式结果。
+
+报关行回执、客户确认、整柜正式申报和海关放行是不同节点。客户确认不能自动完成，平台费用确认与发布也不能代替报关资料确认。
+
+## 二、报关完成与待发区关系
+
+- `LOADED` 只表示物理装柜完成；报关资料、回执、客户确认和正式申报仍需独立完成。
+- 报关完成后，货柜才能进入待发区；待发区表示等待船舶承运，不表示已经开船。
+- 送港、进港、甩柜和改配是运输事实；甩柜只在原柜船期记录上人工修改船信息，不回退或重新处理已完成报关资料。
+- 只有承运船舶实际开航后，才推进 `DEPARTED_ORIGIN_PORT` 海运节点。
+
+## 三、当前代码交接重点
+
+### 已落地的第一批能力
+
+- 平台端和客户端都能展示当前视角的实际装箱数；部分装柜只展示箱数，后续由线下人员处理，系统不做数量分摊。
+- 报关资料和报关行回执继续按文件上传、覆盖、版本和下载处理；页面文案已区分“回执”和“完成”，避免把上传回执误认为客户确认或正式申报。
+- 首次发送报关行单独记录 `brokerSubmission`（业务批次号、冻结资料版本、快照、操作人和时间）；未完成首次发送时不能上传回执，也不能发送客户确认结果给报关行执行。
+- 报关资料链路仅适用于退税货物；买单货物不创建客户报关资料、回执和客户确认流程。
+- 回执上传后进入待确认状态；客户端已提供整份回执确认和打回入口，平台与客户端都展示每个回执版本的确认/打回历史，打回原因回传后再由平台重新上传回执。
+- 后端 OpenAPI、平台/客户端模型和基础测试已同步实际箱数字段；管理员端、客户端类型检查及相关组件测试已通过。
+
+旧版资料与回执基础链路已通过测试环境真实 HTTP 验收；两份文件新流程已通过本地单测、契约测试和测试环境部署。报关闭环不依赖 PDA；真实 HTTP 验收应使用已经处于待发区的柜作为前置，不能因为装柜/PDA 前置失败而把报关结论判为失败。
+
+### 报关与 PDA、船期的边界
+
+- PDA 只负责装柜现场作业，产出 `LOADED` 事实；本报关模块不创建、领取、认领或提交 PDA 任务。
+- 报关模块只消费已完成装柜且可进入待发区的柜。装柜链路可以作为系统级前置验收，但不属于报关两份文件闭环的验收内容。
+- 船期、价格、甩柜和改配属于运输模块。甩柜时只人工修改原柜的船名、航次和时间，柜号、报关资料、回执、客户确认和完税文件不变，也不重新创建报关任务。
+
+### 本轮对 PDA 关系的落地说明（2026-09-26）
+
+- PDA 没有参与本轮代码修改，也没有被报关接口调用；客户资料、报关行回执、客户确认和真实报关完税文件仍由平台与客户/报关行接口独立处理。
+- 当前客户报关详情接口只对已完成装柜的订单开放，未达到 `LOADED` 时返回“订单尚未完成装柜”。因此 PDA 只是报关入口的上游准入事实，不是报关协同动作的一部分。
+- 若后续业务确认“装柜前就允许客户上传报关资料”，应单独调整 `LOADED` 准入门禁；不能通过在报关模块里偷偷创建或操作 PDA 任务解决。
+- 本轮测试已用真实 HTTP 建立退税柜、订舱和船期关联，并确认装柜计划仍为 `EDITING`、`readyForPda=false` 时不启动报关；证据见 `baiyue-firstleg/reports/customs-prep-container-20260926.json`。
+
+### 本轮报关专项真实 HTTP 证据（2026-09-27）
+
+- 使用测试库中已完成装柜的退税计划 `loadingPlanId=2103494180160507905`，没有调用任何 PDA 接口。
+- 客户确认回执：HTTP 200、业务码 `200`，报关状态仍为 `DECLARING`。
+- 平台发送客户确认结果给报关行：HTTP 200、业务码 `200`，产生 `brokerSubmittedAt`，状态仍为 `DECLARING`。
+- 平台上传真实报关完税文件：HTTP 200、业务码 `200`；随后平台和客户查询均返回 `COMPLETED`，并可见完成文件。
+- 完整证据：`baiyue-firstleg/reports/focused-customs-flow-without-pda-20260927.json`。该证据证明两份文件报关协同闭环本身不依赖 PDA。
+- 早期全量验收报告 `customs-full-20260926h.json` 的失败项集中在 PDA 任务被分配给其他作业员，导致装柜链未进入 `LOADED`；修正验收作业员绑定并补齐 File 服务回执类型后，新的全链路报告 `customs-mixed-20260927i.json` 已通过 532/532，报关模块 223+47+23 项全部通过。
+
+### 本轮部署证据
+
+- 本轮 Firstleg 后端 `backend-java #652`、下游 `baiyue-firstleg-firstleg #455`、平台管理端 `admin-web-test #473`、客户端 `client-web-test #355` 均已成功部署到测试环境，健康检查为 `UP`。
+- 客户端报关资料定向测试 61/61 通过；报关服务单测、OpenAPI 契约测试和平台报关组件测试结果记录在本轮交接记录及对应构建产物中。
+- 正式申报/海关结果接入提交：Firstleg `ed692ee3`、路由合同修正 `95da66c7`、执行顺序修正 `4bec639a`，`backend-java #639/#640/#641` 成功；Admin `29cb0bd`、顺序修正 `855d8c0`，`admin-web-test #461/#462` 成功；Client `8c8fdbc`、`client-web-test #350` 成功。正式申报和结果真实 HTTP 7 步全部通过，证据见 `baiyue-firstleg/reports/formal-customs-declaration-and-clearance-result-20260927.json`。
+- 甩柜改配投影提交 `ac3acfce`、`f1218cef`，平台容器读模型修复提交 `2c4f1ea3`；当前分支的船期展示修复已由 `backend-java #649`、`baiyue-firstleg-firstleg #452` 和 `client-web-test #351` 成功部署。真实验证确认改船只更新原柜船期，平台与客户端同步最新船期，柜号和报关资料/回执/完成文件保持不变，证据见 `baiyue-firstleg/reports/platform-and-client-transport-projection-20260927.json`。
+- 回执历史投影提交 Firstleg `f6e70ea5`、Admin `ffe91a1`、Client `3e28478` 已成功部署：`backend-java #650`、`baiyue-firstleg-firstleg #453`、`admin-web-test #471`、`client-web-test #353`。健康检查为 `UP`，平台和客户真实接口均返回 `receiptHistory`；证据见 `baiyue-firstleg/reports/customs-receipt-history-20260928.json`。
+- 本轮首次发送批次与确认动作历史提交为 Firstleg `e63cb2b2`、Admin `730defa`、Client `8fd4063`；数据库已核对 `fl_customs_broker_submission` 与 `fl_customs_completion_action_history`。现有完成柜烟测返回 `A0409 当前柜不在报关中`，确认新首次发送接口的状态门禁；证据见 `baiyue-firstleg/reports/customs-send-batch-confirmation-history-20260928.json`。
+- 本轮页面回归又修复了一个实际问题：Client 订单列表契约此前没有保留 `taxMode`，导致真实退税订单在“报关资料”页被过滤为 0 个资料包；Client `214fe4f` 已补齐退税字段映射，测试部署 `client-web-test #357` 成功。随后发现船期价格页首次加载重复请求渠道列表，`32c5241` 已收敛初始化监听，`client-web-test #358` 成功。
+- 后续回归又修复两个页面事实问题：未知海外仓不再把内部仓库 ID当作客户可见名称；报关完成详情改为明确提示“真实报关完税文件已齐全”。同时同步了现有实现对应的离线合同断言，客户端全量 `npm test` 已通过 `398/398`，生产构建通过，提交 `ffbe348`，测试部署 `client-web-test #359` 成功。
+- 测试环境内置浏览器已按 1920×1080 复验 Admin 与 Client：最新 Admin 柜次详情展示 `LOADED`、8 条仓内节点、PDA 作业摘要 100%、报关“已完成”、国内离仓“已自动离仓”和 7/7 门禁通过；最新 Client 报关资料页展示退税资料包“报关完成”，详情可见回执版本、客户确认状态、真实完税文件和下载入口。Client 船期价格查询以 100 KG/1.2 CBM 真实调用 15 个估价接口并返回 4 个匹配渠道；同一页面初始化只保留 1 次渠道列表请求。
+- 页面请求量抽样：Admin 货柜详情 13 个 API 请求且无重复；Client 报关资料列表 10 个不同 API 请求，打开两个资料详情各刷新一次资料接口；Client 船期价格初始化 1 次渠道请求，查询阶段 15 次并行估价请求，符合当前“每渠道估价”契约。完整新造数 HTTP 链已解除 PDA 前置阻塞并通过；报告 `baiyue-firstleg/reports/customs-current-20260928.json` 共 543/543 项通过，包含订单、测量、PDA 装柜、混合柜报关资料、回执、客户确认、报关行执行、完税文件、自动离仓和客户端下载。
+- 2026-09-28 再次复核：测试 API 健康检查、Admin 货柜列表/详情和 Client 报关资料页均返回 HTTP 200；Admin 与 Client 均在 1920×1080 下重新打开验证。已完成柜调用首次发送接口并携带确认参数，服务端返回 `A0409 当前柜不在报关中`，证明已完成柜不会重复创建报关批次；当前无新增数据库记录。客户端全量测试保持 `398/398` 通过，`client-web-test #359` 成功。
+
+当前仍需继续补齐的不是客户资料协同、正式申报和海关结果基础链路，而是：
+
+- 报关行回执的外部确认/接收回执、下载凭证和回执轮次的更细对象；首次发送批次与客户确认动作历史已经落地；
+- 更细的报关行接收回执和下载凭证；海关异常继续按人工理由和备注处理，不新增自动结果凭证门禁；
+- 将正式申报/海关结果继续扩展到待发区、送港、进港和实际开航的只读投影，保持运输线独立；F23.3 的船期投影已完成真实 HTTP 核验。
+
+开发时不要只增加页面节点文案，也不要把旧的 `COMPLETED` 直接当成客户确认、正式申报或海关放行。
+
+## 四、开发入口
+
+先核对当前代码和 OpenAPI，再决定复用或调整现有接口：
+
+- 客户端报关资料：`apps/client-web/src/modules/first-leg/`，重点查看 `routes.ts`、`CustomsDocumentsDialog.vue` 和 `api/customs.ts`。
+- 平台整柜报关：`apps/admin-web/src/modules/container-loading/`，重点查看 `ContainerCustomsPanel.vue` 和 `api/platformContainerCustoms.ts`。
+- 后端报关：`baiyue-firstleg/firstleg/src/main/java/com/baiyue/firstleg/customs/container/`。
+- 接口与数据：`baiyue-firstleg/firstleg/src/main/resources/openapi/customs-v1.yaml`、报关相关数据库脚本和 IAM 权限初始化。
+
+具体类名、接口路径、状态编码和数据库字段以当前代码核对结果为准；本清单只定义业务完成条件，不预先替换技术实现。
+
+## 五、完成条件
+
+- 客户 A 与客户 B 的资料、回执和确认严格隔离。
+- 每个客户都能完成“资料上传 → 报关行回执 → 客户确认/打回”，资料和完成文件保留版本，客户范围严格隔离。
+- 首次发送报关行必须生成独立业务批次；客户每次确认或打回都保留对应回执版本、操作人、时间和原因。
+- 未全部客户确认时不能完成整柜报关；正式申报批次、海关回填结果和报关单号已独立建模，不能把客户确认或完税文件上传直接当作海关放行事实。
+- 海关查验、不查验放行、扣货、补资料和其他结果已落地为批次下独立事实；平台人员人工选择理由，选择“其他”时填写备注并人工处理异常。
+- 报关完成后才能进入待发区；进入待发区后才推进送港/进港。甩柜/改配只修改原柜船名、航次和船期并保留历史，不能伪造或覆盖报关资料、回执和客户确认。
+- 重复请求、版本冲突、换柜、部分装柜箱数展示和权限越界都有明确结果和审计记录；部分装柜的后续处理在线下完成。
+- F22 和阶段三的实现状态已按当前代码和真实 HTTP 结果回写；后续继续按 `COMPLETED`、海关放行和运输节点分别验收，不把报关完成合并成海运或尾程完成。
+
+- 2026-09-29：补齐测试环境专用 `CN_FIRSTLEG_PDA_OPERATOR` 账号并验证登录，重新执行 `phase3-container-customs` 正式 HTTP 造数链；订单、测量、PDA 领取/扫码/提交、`LOADED` 硬门禁、混合柜 BUY/TAX 隔离、首次发送批次、回执幂等、客户确认、报关行执行、完税文件、`COMPLETED`、自动离仓和 Client 完税文件下载共 543/543 通过，348 个唯一 HTTP 请求，0 个 coverage gap。报告：`baiyue-firstleg/reports/customs-current-20260928.json`。
+- 2026-09-29：继续执行头程运输节点造数链；订舱、港务船期、甩柜改船、拖车预约、报关完成后的待发区、国内离仓门禁和船司查询策略共 1036/1036 通过，641 个唯一 HTTP 请求，0 个阻塞缺口。甩柜只更新原柜船期，柜次及报关事实不变。报告：`baiyue-firstleg/reports/transport-current-20260929.json`；剩余 4 个缺口均为非阻塞的 COSCO/ZIM 外部接入或 Android 真机验收。

头程到尾程/正式申报与海关结果接入设计.md

@@ -0,0 +1,128 @@
+# 正式申报与海关结果接入设计
+
+本文只补 F22.7、F22.8 的业务对象和交互边界，不改变已经验收的退税报关基础闭环：客户上传退税资料 → 平台发送报关行 → 报关行回执 → 客户确认或打回 → 平台发送确认结果给报关行 → 平台上传真实报关完税文件。
+
+## 一、先冻结现有边界
+
+```text
+LOADED
+  ↓
+客户退税资料齐全
+  ↓ 平台开始报关，冻结资料范围和版本
+DECLARING
+  ↓ 报关行回执
+客户确认整份回执 / 打回
+  ↓ 平台发送客户确认结果给报关行
+等待真实报关完税文件
+  ↓ 每个退税客户均有完成文件
+COMPLETED（平台已收到本轮完税文件）
+  ↓
+WAITING_FOR_LOADING（进入待发区）
+```
+
+`COMPLETED` 只表示平台收到本轮真实完税文件，不能解释为海关放行、正式申报成功或船舶已开航。正式申报批次可以在报关行执行后、完税文件回传前建立；PDA 只在上游产出 `LOADED`；待发区、送港、甩柜、改配和船舶实际开航属于运输线，不能由正式申报对象反向改写。
+
+## 二、F22.7 正式申报批次
+
+正式申报批次是平台授权人员人工提交后形成的独立事实，粒度为整柜一次申报批次。它引用当前柜级报关聚合和已冻结的客户资料/回执快照，不复制文件内容。
+
+建议对象：`customs_declaration_batch`
+
+| 字段 | 说明 |
+|---|---|
+| `id` | 平台长 ID，前端按字符串传输 |
+| `customsContainerId` / `loadingPlanId` | 绑定整柜报关聚合和装柜计划，创建后不可换柜 |
+| `batchNo` | 平台生成的批次号，人工提交前为空或草稿号 |
+| `status` | `READY`、`SUBMITTED`、`ACKNOWLEDGED`、`RESULT_PENDING`、`CLOSED`、`CANCELLED` |
+| `sourceVersion` | 提交时整柜报关聚合版本，防止提交后资料范围漂移 |
+| `receiptSnapshot` | 提交时客户资料、回执、确认结果的客户范围和文件版本快照 |
+| `customsEntryNo` | 报关单号，平台人工回填；同一有效批次唯一 |
+| `submittedBy/submittedAt` | 平台提交人和时间 |
+| `acknowledgedBy/acknowledgedAt` | 报关行或平台确认受理人和时间 |
+| `remark` | 提交说明，长度受服务端限制 |
+
+创建或提交门禁：
+
+1. 柜级报关已进入 `DECLARING`，且整柜退税资料已覆盖实际装柜退税票；批次也允许在完税文件上传后的 `COMPLETED` 阶段补建。
+2. 所有退税客户的当前回执均为 `CONFIRMED`。
+3. 已执行发送动作，`brokerSubmittedAt` 已存在。
+4. 提交使用版本号和幂等键；相同请求重放返回同一批次，不同载荷返回冲突。
+5. 提交后禁止修改客户资料范围、回执和确认结果；补资料必须通过新批次或明确的退回重提动作产生新版本，不能覆盖历史批次。
+
+建议平台接口：
+
+- `GET /api/platform/v1/customs/loading-plans/{planId}/declaration-batches`
+- `POST /api/platform/v1/customs/loading-plans/{planId}/declaration-batches`
+- `POST /api/platform/v1/customs/loading-plans/declaration-batches/{batchId}/submit`
+- 提交时在请求体回填 `customsEntryNo`，不另设独立改单接口。
+
+客户端只读当前批次的可见投影，不提供提交和修改入口；客户只能看到自己资料覆盖的结果。
+
+## 三、F22.8 海关结果事实
+
+海关结果不是柜级状态字段，而是批次下的不可变事实记录。一次正式申报可以先产生“待结果”，之后根据实际回执追加查验、补资料、放行、扣货或其他结果；修正不能覆盖历史记录。
+
+建议对象：`customs_clearance_result`
+
+| 字段 | 说明 |
+|---|---|
+| `id` | 结果事实长 ID |
+| `declarationBatchId` | 所属正式申报批次 |
+| `resultType` | `INSPECTION`、`SUPPLEMENT_REQUIRED`、`RELEASED`、`DETAINED`、`OTHER` |
+| `resultStatus` | `OPEN`、`RESOLVED`、`CANCELLED` |
+| `customsEntryNo` | 报关单号快照，必须与批次一致 |
+| `occurredAt` | 海关事实发生时间 |
+| `recordedAt/recordedBy` | 平台录入时间和操作人 |
+| `resolution` | 处理结果、补资料说明或扣货原因 |
+| `evidenceFileId` | 可选结果凭证，文件由 File 保存，归属由 Firstleg 校验 |
+| `previousResultId` | 更正或追加结果的前序事实，不能原地覆盖 |
+
+结果门禁：
+
+- `INSPECTION` 和 `SUPPLEMENT_REQUIRED` 未解决时，客户看到处理中/待补资料，平台不能显示放行。
+- `RELEASED` 只表示海关放行事实，不自动写入送港、进港或实际开航。
+- `DETAINED` 进入扣货/异常处理，保留原因和凭证，不自动删除报关文件。
+- `OTHER` 必须有说明，不能用空状态吞掉未知海关结果。
+- 只有平台授权人员可以新增或更正结果；客户只能读取自身可见的结果和凭证。
+
+建议平台接口：
+
+- `GET /api/platform/v1/customs/loading-plans/declaration-batches/{batchId}/results`
+- `POST /api/platform/v1/customs/loading-plans/declaration-batches/{batchId}/results`
+- `POST /api/platform/v1/customs/loading-plans/clearance-results/{resultId}/resolve`
+- `GET /api/merchant/v1/customs/orders/{orderId}/clearance-results`
+
+## 四、三端交互
+
+| 参与方 | 可以做什么 | 不可以做什么 |
+|---|---|---|
+| 客户 | 上传/替换自身退税资料；查看并确认或打回整份回执；查看自身批次、报关单号、海关结果和凭证 | 不能查看同柜其他客户；不能提交正式申报；不能录入放行/扣货 |
+| 平台报关人员 | 核对资料和回执；发送报关行；创建/提交正式申报批次；回填报关单号；录入和解决海关结果 | 不能用客户确认代替正式申报；不能用完税文件代替放行结果 |
+| 报关行 | 线下处理申报并返回回执、报关单号和海关结果文件 | 不直接调用客户接口；所有回执和结果由平台留痕上传 |
+| PDA/运输 | PDA 产出 `LOADED`；运输处理待发区、送港、进港、甩柜、改配和实际开航 | 不创建报关批次，不修改报关结果，不因甩柜重置资料或确认 |
+
+## 五、状态投影
+
+平台柜级状态继续保留当前四态，用新增投影补充信息：
+
+| 现有状态 | 新增投影 | 客户文案 |
+|---|---|---|
+| `WAITING_CUSTOMER_DOCUMENTS` | 无有效批次 | 待上传退税报关资料 |
+| `READY_TO_START` | 可开始报关 | 资料已齐，等待平台发送报关行 |
+| `DECLARING` | 回执确认中/已发送报关行/正式申报中 | 报关处理中 |
+| `COMPLETED` | 完税文件齐全，正式申报或结果可能仍未关闭 | 报关文件已完成，等待海关结果（如有） |
+
+运输投影单独读取待发区和船期对象；甩柜只更新原柜船名、航次和时间历史，不变更批次、资料、回执、结果或客户确认。
+
+## 六、最小验收矩阵
+
+1. 未全部客户确认时创建/提交正式批次返回业务冲突，数据零漂移。
+2. 同一幂等键重放返回同一批次；换参数返回冲突。
+3. 提交后资料范围、回执和客户确认不可修改。
+4. 同一批次可追加查验、补资料、放行、扣货和其他结果，历史顺序稳定。
+5. 查验/补资料未解决时不显示放行；扣货保留原因和凭证。
+6. 客户 A 不能读取客户 B 的批次、结果和文件。
+7. 报关结果不推进送港、进港或实际开航；甩柜只改变原柜船期。
+8. 正式申报和结果事实可以在报关 `COMPLETED` 后继续存在，不能把 `COMPLETED` 直接当成 `RELEASED`。
+
+本设计已完成代码接入：Firstleg 建立正式申报批次和海关结果表、版本/幂等/审计门禁及平台/客户接口；Admin 页面提供创建、提交、录入和处理入口，Client 页面展示本订单可见结果。真实 HTTP 证据见 `baiyue-firstleg/reports/formal-customs-declaration-and-clearance-result-20260927.json`。当前仍保持 `COMPLETED`、海关放行、待发区和实际开航的状态边界，PDA 与船期不参与结果对象。

头程到尾程/测试环境真实联调记录-20260925.md

@@ -0,0 +1,109 @@
+# 测试环境真实联调记录（2026-09-25）
+
+本记录只登记已经在测试环境真实调用得到的结果，不把本地单测或设计文档当作真实验收证据。环境配置来自本机受控配置目录，不在文档中记录密码、Token 或 Jenkins 凭据。
+
+## 一、本批部署
+
+| 部署单元 | 测试构建 | 结果 | 说明 |
+|---|---:|---|---|
+| `backend-java` | 618 | 成功 | `firstleg` 选择构建；第 617 次因测试仍引用已删除旧方法失败，修正后第 618 次成功 |
+| `admin-web-test` | 454 | 成功 | 平台回执上传不再携带 `finalConfirmation`，上传后等待客户确认 |
+| `client-web-test` | 331 | 成功 | 客户端新增整份回执确认、打回和原因展示 |
+
+路由合同检查通过；后端报关服务定向测试和 Controller 合同测试通过，Admin 类型检查及报关组件测试通过，Client 类型检查通过。
+
+## 二、真实接口证据
+
+测试客户属于退税客户，使用已完成装柜的测试订单和柜次进行验证。测试库已补齐 `fl_customs_completion_document` 的客户确认字段，现有记录仅用于本次测试。
+
+### 1. 客户查看退税报关资料
+
+调用：
+
+```text
+GET /api/merchant/v1/customs/orders/{orderId}
+```
+
+结果：`200`。客户只能看到自身资料，返回实际箱数 `40`、退税资料 `1` 份；部分装柜的系统展示只读箱数，不做数量拆分。
+
+### 2. 平台查看柜级报关状态
+
+调用：
+
+```text
+GET /api/platform/v1/customs/loading-plans/{loadingPlanId}
+```
+
+结果：`200`。平台视角返回同一柜次实际箱数 `40`、退税资料覆盖数和回执状态；客户视角没有返回同柜其他客户资料。
+
+### 3. 平台上传报关行回执
+
+调用：
+
+```text
+POST /api/platform/v1/customs/loading-plans/documents/{documentId}/completion/upload?expectedVersion=1
+```
+
+结果：`200`，回执状态为 `PENDING`，文件版本变为 `2`。上传回执没有自动把柜次标记为报关完成。
+
+### 4. 客户打回整份回执
+
+调用：
+
+```text
+POST /api/merchant/v1/customs/documents/{documentId}/receipt/reject
+```
+
+结果：`200`，回执状态为 `REJECTED`，打回原因被保存，柜次仍为 `DECLARING`。
+
+### 5. 客户确认整份回执
+
+调用：
+
+```text
+POST /api/merchant/v1/customs/documents/{documentId}/receipt/confirm
+```
+
+结果：`200`，回执状态为 `CONFIRMED`；该柜唯一退税客户确认后，柜次变为 `COMPLETED`。相同幂等键重放仍返回同一完成结果。
+
+### 6. 头程到报关真实 HTTP 回归
+
+在补齐国内 PDA 测试作业员凭据后，使用 `scripts/admin-test-env-acceptance.mjs --modules phase3-container-customs` 重新执行依赖闭环，覆盖客户下单、审核、入库测量、分柜/订舱、预装、PDA 装柜、`LOADED`、退税资料上传、平台回执上传、客户回执确认、自动离仓及船期查询任务。
+
+结果：报告 `baiyue-firstleg/reports/e2e-phase3-container-customs-20260925d.json`，`526/526` 断言通过，`0` 失败；其中混合柜验证确认回执后才进入 `COMPLETED`，自动离仓 `SYSTEM` 历史为 `1` 条，`OUTBOUND_CONFIRM` 船期查询任务为 `1` 条。验收脚本同步提交为 `8940c4bc`。
+
+### 7. 送港、船期与实际开航真实 HTTP 回归
+
+使用 `phase3-port-schedules,phase3-carrier-schedule-queries,phase3-outbound-dispatch` 执行送港和出仓链路，报告 `baiyue-firstleg/reports/e2e-phase3-transport-20260925.json`，`1024/1024` 通过；验证报关完成后国内离仓门禁、拖车自动完成、`OUTBOUND_CONFIRM` 任务唯一性及 `DEPARTED_WAREHOUSE` 事实。
+
+随后使用 `phase4-carrier-pickup-ready` 执行船节点人工回填，报告 `baiyue-firstleg/reports/e2e-phase4-carrier-pickup-ready-20260925.json`，`1093/1093` 通过；节点按顺序推进到 `AT_ORIGIN_PORT`、`LOADED_ON_VESSEL`、`DEPARTED_ORIGIN_PORT`，并覆盖幂等重放、旧版本冲突、旧节点回写禁止和至 `PICKUP_READY` 的连续事实。
+
+## 三、当前已确认的业务边界
+
+- 报关资料、报关行回执和客户确认流程只适用于退税货物。
+- 买单货物不创建客户报关资料、回执和客户确认流程；买单装柜、导出和运输节点独立处理。
+- 报关资料和回执均为文件；回执状态单独保存，文件版本覆盖会重新进入待确认。
+- 部分装柜只展示实际箱数，后续由线下人员处理，系统不自动分摊数量。
+- `LOADED` 后先完成报关协同；报关完成后货柜进入待发区，等待船期承运。甩柜/改配只影响运输航次，不回退或重做报关资料、回执和客户确认。
+
+## 四、F01-F24 验证状态
+
+| 范围 | 当前证据 | 状态 |
+|---|---|---|
+| F01-F13 下单、审核、到仓、测量、计费、费用确认、组托 | 本批依赖闭环已通过真实 HTTP；仍需拆分逐节点证据和异常分支 | 主链路已验收 |
+| F14-F21 分柜、订舱、拖车、拣货、装柜、`LOADED` | 本批依赖闭环已通过真实 HTTP，包含 PDA 领取、提交、审核和 `LOADED` 冻结 | 主链路已验收 |
+| F22 退税报关资料、回执、客户确认 | 已完成真实平台/客户端闭环 | 本批已验收 |
+| F23 送港、进港、甩柜、改配 | 送港/进港/出仓和船期查询主链路已通过真实 HTTP；已用测试环境真实柜次验证平台人工修改原柜船名/航次/预计时间，柜次、订舱关联和船期记录 ID 不变，修改历史新增 `UPDATE`；报关事实保持不变 | 主链路和原柜人工改船已验收；完整装柜依赖链仍需补 PDA 凭据后复跑 |
+| F24 实际开航 | 已通过人工船节点回填验证 `DEPARTED_ORIGIN_PORT`，顺序、版本和旧节点冲突均通过 | 本批已验收 |
+| F25 以后目的港清关、海外入仓、尾程 | 已有综合真实 HTTP 证据覆盖目的港节点、海外 PDA 收货、库存、排车、出库、派送和跨区回写；`admin-full-postdeploy-66c2651b.json` 相关模块失败数为 0 | 已有主链证据；仍需按具体柜次补最终业务签字和页面截图 |
+
+## 五、下一批开发入口
+
+下一批聚焦 F23 的人工改船页面回读、客户侧船期投影和异常分支；当前已确认只变更原柜船期，柜次、订舱关联和报关事实均不被覆盖。尾程节点再按 F25 以后阶段推进。每批完成后继续追加真实 HTTP 证据。
+
+## 六、2026-09-27 追加验证：F23.3 客户船期投影
+
+- 后端提交 `f1218cef` 已由 `backend-java #643` 完整测试并部署，Firstleg 独立任务 `baiyue-firstleg-firstleg #446` 成功；随后提交 `2c4f1ea3` 由 `backend-java #645` 完整测试并部署，Firstleg 独立任务 `baiyue-firstleg-firstleg #448` 成功；当前分支追加船期展示修复后，`backend-java #647` 与 `baiyue-firstleg-firstleg #450` 也已成功。
+- 修复统一订单运输摘要仍读取订舱初始船名/航次的问题：现在按客户、订舱和柜次读取最新 `fl_port_schedule` 记录，采用窗口函数选取最新观测，保留柜次与报关对象独立性。
+- 对退税柜 `TSTU0152125` 实际执行“创建原柜改配船期 → 平台容器详情与客户订单同时查询 → 版本更新恢复原船信息”。平台和客户端均读到新船名、航次及预计时间；柜号不变，恢复后两端再次一致。本轮不涉及 PDA，PDA 仍只作为 `LOADED` 上游事实。
+- 详细请求结果和断言见 `baiyue-firstleg/reports/platform-and-client-transport-projection-20260927.json`；此前客户侧单独投影证据仍保留在 `transport-projection-after-schedule-update-20260927.json`。

头程到尾程/甩柜改配接入设计.md

@@ -0,0 +1,39 @@
+# 甩柜与改配接入设计（F23.3）
+
+## 最新确认
+
+柜子不会变。平台人员在原柜子的船期信息上人工修改船名、航次和预计时间即可；保留修改前后内容、修改人和时间。报关资料、回执、完成文件和客户确认保持不变。
+
+## 操作流程
+
+1. 退税报关完成后进入待发区，等待船舶承运。
+2. 原船装满导致甩柜时，平台编辑该柜当前船期，填写实际安排的船名、航次和预计开船/到港时间。
+3. 保存后继续使用原柜次和原船期查询任务；保留已经发生的离仓、进港事实。
+4. 货柜实际随船开航后，再记录实际开航节点。修改预计船期本身不表示已经开船。
+
+不新建柜子、订舱关联或航次变更审批对象，不重建船期任务，也不重新上传或确认报关资料。此前建议的 voyage-changes 接口和批次评估状态已取消。
+
+## 现有接入入口与待验收项
+
+入口放在原柜详情的“船名航次信息”区域，通过“船期维护与历史”打开居中弹框；不依赖已退出路由的独立 `PortSchedulesView.vue`。后端返回与当前运输展示来自同一条记录的只读 `currentPortScheduleId`，前端按此加载详情；不得自行从其他柜或全量船期中选择记录。`PortScheduleService.update` 保持客户、订舱和柜次归属不变，并保存版本和修改前后历史。
+
+已有记录只修改船名、航次、ETD、ETA及本次原因，其余来源与有效期字段保留；提交携带原版本和幂等键，网络结果不明时重试原请求，未改运输值不重复发送。只读权限可查看历史，新增和编辑权限分别校验。无当前记录时，允许在原客户、原订舱和原柜上登记船期信息，来源、确认时间、信息有效至及截港时间须明确填写，不自动编造门禁有效期。
+
+交互依据沿用既有船期维护的居中表单和货柜详情分区；已有记录使用1000px弹框，首次登记使用1120px三列表单，原因跨列，历史展示修改前后四项运输字段、修改人、原因和时间。实际1920×1080页面验收及发布证据仅维护在测试环境主契约，不以此设计说明替代验收结果。
+
+当前船期展示已改为读取同一客户、订舱和柜次下最新船期记录，不再固定读取订舱初始快照。平台人工改船后，客户端会同步显示最新船名、航次和预计时间。
+
+## 验收要求
+
+- 修改后柜次、柜号、装柜清单、订舱关联和船期查询任务不变。
+- 船名、航次和预计时间正确更新，平台与客户可见的当前船期一致。
+- 修改前后历史、操作人和时间可追溯，重复请求和版本冲突有明确结果。
+- 报关状态、资料、回执、完成文件、客户确认与修改前一致。
+- 已发生的物理节点不重置，预计时间调整不推进实际开航。
+
+## 真实联调证据（2026-09-27）
+
+测试柜 `TSTU0152125`（`containerBookingId=2104006600809353218`）的退税报关计划
+`2104006600830324737` 已完成资料、回执确认和完税文件闭环。平台创建一次原柜船期改配记录后，客户端同一订单立即读到新船名、航次和预计时间；柜号、柜次不变，报关状态、退税客户数量、资料/回执/完成文件 ID 与版本均未变化。随后已用版本更新恢复原船信息，恢复后的客户端投影再次一致。完整证据见
+`baiyue-firstleg/reports/platform-and-client-transport-projection-20260927.json`（平台与客户端同时回读）以及
+`baiyue-firstleg/reports/transport-projection-after-schedule-update-20260927.json`。

头程到尾程分阶段流程/README.md

@@ -1,36 +1,32 @@
-# 头程到尾程分阶段流程文档
+# 头程到尾程分阶段流程
 
-本目录把“头程下单 → 尾程出库”拆成六个可独立评审、以后也可独立优化的阶段。各阶段统一描述现状操作和数据流，不在流程确认前直接决定改版方案。
+本目录是端到端流程的分段查找入口。F01-F40 流程基线已确认，当前用于全流程收尾变更；本入口不记录代码、部署或验收进度，相关事实只查环境主契约。总览和节点关系看[《头程到尾程流程节点梳理》](../头程到尾程流程节点梳理.md)，字段、页面操作、权限和异常细节在对应阶段文件维护。
 
-当前六个阶段的现状基线均已完成。下一步按阶段组织业务、产品、运营、国内仓、海外仓和技术评审；每阶段确认后，再将评审结论转入易用性和数据流转优化方案。
+## 三大业务块与六个分段
 
-## 分阶段计划
+| 业务块 | 分段 | 节点范围 | 详细文档 |
-
-| 阶段 | 范围 | 对应全景流程 | 文档 |
 |---|---|---|---|
-| 阶段一 | 客户准入、基础资料、单票/批量下单、提交、审核、订单交接 | F01～F07 | [阶段一：客户准入与头程下单](阶段一-客户准入与头程下单.md) |
+| **头程下单** | 阶段一：客户准入与头程下单 | F01-F07 | [打开阶段一](阶段一-客户准入与头程下单.md) |
-| 阶段二 | 国内到仓、箱码、测量、称重、费用、扣货、一件代发组托 | F08～F13 | [阶段二：国内到仓、测量计费与组托](阶段二-国内到仓测量计费与组托.md) |
+| **头程下单** | 阶段二：国内到仓、测量计费与组托 | F08-F13 | [打开阶段二](阶段二-国内到仓测量计费与组托.md) |
-| 阶段三 | 模拟柜、排柜、订舱、拖车、预装、国内 PDA、报关、出仓 | F14～F23 | [阶段三：国内货柜履约与出仓](阶段三-国内货柜履约与出仓.md) |
+| **海运（货柜）** | 阶段三：国内货柜履约与出仓 | F14-F23 | [打开阶段三](阶段三-国内货柜履约与出仓.md) |
-| 阶段四 | 海运节点、目的港、跨区尾程建单、尾程入仓计划 | F24～F27 | [阶段四：海运、目的港与尾程入仓计划](阶段四-海运目的港与尾程计划.md) |
+| **海运（货柜）** | 阶段四：海运、目的港与尾程计划 | F24-F27 | [打开阶段四](阶段四-海运目的港与尾程计划.md) |
-| 阶段五 | 海外接柜、实收、库存、暂扣和库内服务 | F28～F33 | [阶段五：海外接柜、库存与库内服务](阶段五-海外接柜库存与库内服务.md) |
+| **尾程入库和派送** | 阶段五：海外接柜、库存与库内服务 | F28-F33 | [打开阶段五](阶段五-海外接柜库存与库内服务.md) |
-| 阶段六 | 海外排车、转派送、PDA 出库、派送、异常和最终回写 | F34～F40 | [阶段六：海外排车、出库、派送与最终回写](阶段六-海外排车出库派送与回写.md) |
+| **尾程入库和派送** | 阶段六：海外排车、出库、派送与最终回写 | F34-F40 | [打开阶段六](阶段六-海外排车出库派送与回写.md) |
 
-## 每阶段统一模板
+## 修改时只看这三层
 
-1. 阶段目标、起点和终点；
+1. **总览层**：三大块、客户进度和节点关系变化，改总览节点梳理。
-2. 角色、终端和权限边界；
+2. **分段层**：某一段的页面操作、字段、权限、状态或异常，改对应阶段文件。
-3. 前置主数据和检查项；
+3. **专题层**：报关资料、报关行回执、客户确认、送港/甩柜和船期价格，改[报关资料与船期价格接入梳理](../国内货柜履约/报关资料与船期价格接入梳理.md)，并回看总览中的 F22/F23。
-4. 页面逐步操作；
-5. 字段与条件必填规则；
-6. 状态机、可用动作和不可逆节点；
-7. 单据、编号、快照和数据归属；
-8. 同步/异步调用和上下游交接；
-9. 正常流、条件分支和异常恢复；
-10. 阶段完成判定与评审清单。
 
-总览入口：
+## 跨段交接
 
-- [现状流程全景清单](../头程下单到尾程出库现状流程全景清单.md)
+- 阶段二完成后进入阶段三的分柜；费用确认是并行事项，不阻断排柜、拣货和装柜。
-- [一票主链操作手册](../头程下单到尾程出库全流程操作手册.md)
+- 阶段三的装柜完成（`LOADED`）后先完成退税报关；报关完成后货柜进入待发区，再推进送港运输。甩柜/改配只影响船期，不改变已完成报关事实。
-- [易用性与数据流转优化草案](../头程下单到尾程出库流程易用性与数据流转优化方案.md)
+- 报关协同必须经过“客户资料 → 报关行回执 → 客户确认/打回重做”，柜内所有客户确认后才提交整柜资料并正式申报。
-- [AI 流程优化上下文包](../头程到尾程AI流程优化上下文包.md)
+- 送港完成、进港或甩柜都不等于海运中；承运船舶实际开航后才进入阶段四的海运节点。
+- 阶段四形成海外接柜输入后，阶段五负责实收、入库和库存，阶段六负责出库、派送、签收和异常回写。F01-F37 以海外出库为阶段性业务终点，F38-F40 继续完成派送、签收和国内最终回写。
+
+## 旧文档的使用范围
+
+全流程操作手册、现状全景清单、AI 优化上下文、开发规划、进度表、开工门禁和验收任务继续保留，用于追溯历史决策和实现记录；它们不是当前节点维护入口。新增规则只写入总览、对应阶段或专题文件，避免同一流程在多份历史文档中重复修改。

头程到尾程分阶段流程/阶段三-国内货柜履约与出仓.md

@@ -2,8 +2,8 @@
 
 > 对应全景流程：F14～F23。  
 > 阶段起点：入库单主状态为 `WAIT_SPLIT`，不存在有效 HOLD。  
-> 阶段终点：整柜满足国内出仓门禁，产生唯一实际 `DEPARTED_WAREHOUSE` 节点并开始出仓后的船节点查询。  
+> 阶段终点：装柜后完成退税报关并进入待发区，再完成送港线的仓库离开/进港事实；实际开船 `VESSEL_DEPARTED` 由阶段四承接。
-> 本阶段复用订单、入库单、柜次和装柜计划，不新建独立“出仓单”。
+> 本阶段复用订单、入库单、柜次和装柜计划，不新建独立“出仓单”。`LOADED` 后先推进报关协同，报关完成后进入待发区，再推进送港；费用确认是并行事实，装柜完成后对已装范围的当前有效费用版本执行系统默认确认。
 
 ## 1. 阶段目标和边界
 
@@ -15,19 +15,19 @@
 4. 模拟柜与订舱柜型需求、真实集装箱号关联；
 5. 预装确认、动态增减和普通散货托盘标签；
 6. 国内 PDA 拣货、整托装柜和异常闭环；
-7. 四步装柜照片、铅封照片与铅封号；
+7. 空仓、半仓、满仓、锁仓、带锁码照五类装柜证据与锁码文本；
 8. 装柜完成、部分装载分片和跨区交接快照；
-9. 客户资料、整柜出口报关与放行；
+9. `LOADED` 后通知报关行、客户资料收集、回执确认、整柜正式申报和海关结果；
-10. 国内出仓门禁、离仓确认和拖车费用归集。
+10. 送港、进港、甩柜/改配、实际离仓和拖车费用归集。
 
-`LOADED` 表示货物已经完成实际装柜，不等于柜子已经离开国内仓。报关放行等条件在国内出仓环节统一校验；国内 Admin/PDA 不得把订单推进到海外派送完成 `DELIVERED`。
+`LOADED` 表示货物已经完成实际装柜。此时先触发报关线：收集退税客户资料、发送报关行、处理回执和客户确认；报关完成后进入待发区，才允许推进拖车、离仓和进港。已进港不代表报关完成，容量不足时记录甩柜和改配船次；甩柜不影响已完成报关资料、回执和客户确认。只有实际开船后才进入海运节点。国内 Admin/PDA 不得把订单推进到海外派送完成 `DELIVERED`。
 
 ## 2. 角色、终端和对象
 
 | 角色 | 终端 | 主要操作 |
 |---|---|---|
 | 排柜操作员 | Admin | 创建模拟柜、搜索候选、推荐/人工加入、调整预装 |
-| 订舱操作员 | Admin | 建订舱草稿、维护运输资料、上传文件、放舱 |
+| 订舱操作员 | Admin | 建订舱草稿、维护运输资料、放舱 |
 | 国内调度 | Admin | 建订舱级拖车预约、选择供应商、维护时间和附件 |
 | 仓库主管 | Admin | 预装确认、真实柜号补录、任务和证据监督 |
 | PDA 拣货员 | 国内 PDA | 领取唯一柜次任务、扫码、异常、拍照、完成装柜 |
@@ -55,7 +55,7 @@
 - 柜型规格、国内中转仓、有效渠道和供应商主档可用；
 - 操作员理解模拟柜、真实柜号、订舱和拖车是不同对象；
 - 同柜不可拆组、已占用数量和版本冲突均以服务端返回为准；
-- 费用仍可并行维护，但已经确认/发送或客户已确认版本不得被静默改写。
+- 费用仍可并行维护，客户未确认不阻断排柜、预装、PDA 或装柜；装柜完成后对已装范围的当前有效已发布版本记录系统默认确认。客户确认和系统默认确认来源分开审计；缺少有效费用版本不伪造确认，部分装载不得把余量一起确认。
 
 ## 4. F14 模拟柜与智能排柜
 
@@ -89,6 +89,10 @@
 
 人工加入：选择候选，填写普通货分配箱数或选择一件代发整托，携带计划版本提交。系统重新校验资格；页面旧结果不能作为写入依据。
 
+平台柜次允许拼装多个客户的货物。关联订舱中的客户资料是业务快照，不是柜次的客户准入名单；不能据此裁剪其他客户的候选，或拒绝其普通箱数、待审核占位、整托分配及后续数量调整。智能推荐仍遵循渠道和用户显式选择的客户/入仓码范围。
+
+跨客户拼柜不改变货物归属。每条明细仍以权威订单、入库单及托盘的原客户身份取数、写入和重算费用；客户端、文件、费用、报关资料及其他客户可见接口继续按原客户隔离，不能把物理拼柜当作跨客户读取授权。
+
 一件代发一票多托时逐托展示，其中一托已分配不得隐藏其他未分配托盘。容量不足时跳过整托，不能回退成按箱拆托。
 
 ### 4.4 调整与费用影响
@@ -111,9 +115,12 @@
 3. 选择 `ACTIVE/BOOKING` 订舱供应商；
 4. 填写三类参与方和已知运输资料；
 5. 至少维护一项、最多二十项柜型需求，数量为正整数；
-6. 保存为 `DRAFT`，系统生成 `OB-yyMMdd-####` 订舱号。
+6. 录入预报（委）件数、毛重、体积及包装单位、品名、唛头；未确定的数据留空；
+7. 保存为 `DRAFT`，系统生成 `OB-yyMMdd-####` 订舱号并留在详情，可继续维护资料、上传文件和打印托运单。
 
-草稿允许资料不完整、替换文件和继续编辑。柜型需求只表达需要多少个什么柜型，不创建真实货柜行。
+草稿允许资料不完整和继续编辑；关系方名称未填时，其已录入的联系人、邮箱、电话、税号和地址仍随草稿保存，放舱前必须补齐三方名称。柜型需求只表达需要多少个什么柜型，不创建真实货柜行。
+
+新建页面默认柜型 `40HQ`、整箱 `FCL`，运费条款 `FREIGHT PREPAID`、运输条款 `CY-CY`、包装单位 `CARTONS`，均按实际业务维护。港口、日期、品名、免用箱要求及货量不写样例默认值；包装单位可选 CARTONS、PCS、PALLETS，货量为本订舱总量。
 
 ### 5.2 补齐并放舱
 
@@ -123,16 +130,26 @@
 - 船名、航次、起运港、目的港、ETD、ETA 和运输条款完整；
 - 渠道仍有效；
 - 柜型需求与平台规格一致；
-- 存在有效 `BOOKING_CONFIRMATION` 或 `BILL_OF_LADING` 文件；
+- 不要求上传订舱确认文件或提单文件；订舱页面不再展示“订舱资料”模块；
 - 订舱供应商仍为有效主档。
 
-点击放舱后状态从 `DRAFT` 进入 `RELEASED`，运输快照永久只读。放舱不要求真实柜号，不得为了通过校验伪造柜号。
+点击放舱后状态从 `DRAFT` 进入 `RELEASED`，运输和预报货量快照永久只读；实际货量通过独立受控入口补录。放舱不要求真实柜号，不得为了通过校验伪造柜号。
+
+### 5.3 客服补实与单据打印
+
+- 客服手工录入本订舱的实际件数、毛重（KGS）和体积（CBM），不自动汇总关联柜或覆盖仓库测量事实。未采集保持 NULL；已填写数值必须大于零，件数为整数，重量、体积最多三位小数。
+- 草稿保存委/实资料；放舱后仅持有订舱编辑权限的人员可通过 `PUT /api/platform/v1/ocean-bookings/{oceanBookingId}/actual-cargo` 补录或修正三项实值，必须提交当前版本、幂等键和原因，同事务递增版本并记录前后快照、操作人和时间。运输资料、三方关系人、柜型需求、预报货量和文件关联仍冻结。
+- 核心资料右侧并排展示发货人、收货人、通知人，下方独立展示船名、航次、提单号。保留仓库、渠道、预计到港及多柜型需求，移除订舱文件入口。
+- “打印托运单”读取已保存的委值；“打印提单确认件”读取已保存的实值。两类单据复用现有 A4 PDF 模板和预览/下载，未填字段显示“—”，实值缺失不能回退为委值，也不以柜型容量代替货量。未保存修改须先保存再打印。
+- 柜量描述按柜型需求和数量生成，件数英文大写按对应的委/实件数及包装单位生成；品名、唛头及三方联系信息来自已保存资料。没有来源的传真、代理联系人等保持“—”。
+- 系统仅生成提单确认件，正式提单由外部提供；不新增正式提单签发模板。订舱页面移除附件资料模块，放舱及后续拖车预约、派车不依赖订舱附件。
+- 不在订舱新增中实现 FBA 同组入仓 30 天校验；该规则须先明确分组与时间事实后单独确认。
 
 ## 6. F16 订舱级国内拖车
 
 入口：Admin → 国内拖车预约。
 
-1. 从服务端候选中选择已 `RELEASED`、有提单号和有效订舱文件的订舱；
+1. 从服务端候选中选择已 `RELEASED` 且有提单号的订舱（不要求订舱文件）；
 2. 选择 `ACTIVE/TRUCKING/DOMESTIC` 供应商；
 3. 填写计划装柜时间、联系人和附件；
 4. 保存/提交预约；
@@ -225,13 +242,13 @@ PDA 装柜完成不推进拖车状态。只有订舱要求的全部柜型数量
 
 ## 10. F20 装柜证据与铅封
 
-PDA 按现场顺序拍摄：
+PDA 按现场要求采集五类证据：
 
-1. `PHOTO_STEP_1`：装柜初始/空柜；
+1. `EMPTY`：空仓照片；
-2. `PHOTO_STEP_2`：装载过程；
+2. `HALF`：半仓照片；
-3. `PHOTO_STEP_3`：接近完成；
+3. `FULL`：满仓照片；
-4. `PHOTO_STEP_4`：满柜/关门前；
+4. `LOCKED`：锁仓照片；
-5. `SEAL`：带有效铅封号的封柜照片。
+5. `SEAL`：带有效铅封号的带锁码照片。
 
 每类至少一张有效照片，同类允许追加。PDA 仅允许现场相机拍摄；有权限的 Admin 操作员/理货员可人工补充，普通拣货员不开放后台上传。
 
@@ -245,7 +262,7 @@ PDA 点击“完成装柜”时，服务端重新校验：
 - 真实集装箱号存在；
 - 所有普通箱码或一件代发整托均核平；
 - 没有未解决异常；
-- 四步照片和带铅封号的 `SEAL` 完整；
+- 空仓、半仓、满仓、锁仓、带锁码照五类证据和锁码文本完整；
 - 计划明细、已拣数量和最终实装数量守恒。
 
 校验通过后：
@@ -260,45 +277,54 @@ PDA 点击“完成装柜”时，服务端重新校验：
 
 ## 12. F22 客户资料与整柜出口报关
 
-### 12.1 客户上传资料
+### 12.1 F22-A `LOADED` 后按退税客户范围收集资料
 
-入口：Client → 头程订单 → 报关资料。
+入口：`LOADED` 事件 → Admin/Client → 报关资料。
 
-客户只可对本企业订单上传退税/报关资料，选择资料类型并填写说明。文件归属、订单归属和客户身份由服务端校验，文件名不能代替合法文件 ID。
+1. 装柜完成后按最终实装清单确定本柜每个退税客户及其入仓码范围；首期复用柜级报关聚合与客户资料范围，不强制新增独立 `customerCustomsCase` 对象；
+2. 退税客户上传本企业资料，平台校验客户、订单、入仓码、实际装载范围和文件归属；有文件即可，不要求资料类型清单。买单订单不走这条客户资料和回执确认链；
+3. 平台将资料发送给报关行，记录首次发送批次、发送人、时间、资料版本和范围快照；
+4. 报关行返回回执，平台上传文件并向对应退税客户展示整份回执确认任务，保留文件版本和确认动作历史；独立回执轮次对象属于后续增强。
 
-### 12.2 平台整柜报关
+柜前可以存在资料准备或历史附件，但不创建本柜正式客户确认轮次，也不能显示“已通知报关”。客户资料缺失形成报关补件待办，未完成报关不得进入待发区或推进送港。
 
-入口：Admin → 柜次详情 → 出口报关。
+### 12.2 F22-B 报关行回执与客户确认循环
 
-1. 查看柜内所有入仓码及其资料覆盖情况；
+客户查看报关行回执后有两个结果：
-2. 对退税资料逐项核对，缺件时联系对应客户补充；
-3. 开始报关时冻结当前参与资料和版本；
-4. 线下向报关代理提交；首版不做外部系统直连；
-5. 完成后为每份退税资料上传一一对应的完成文件；
-6. 全买单柜由平台确认买单，并从导出中心获取最终实装买单明细；
-7. 点击完成整柜报关，写入放行结果和历史。
 
-报关完成后系统立即尝试国内出仓；若其他门禁尚未齐全，保留明确阻断项并由受控补偿重试，不能伪装为已离仓。
+1. **确认**：该客户当前整份回执确认状态为 `CONFIRMED`，保存确认人、确认时间、回执版本和幂等键；
+2. **打回**：保存本客户对当前回执的打回状态和原因；客户重新上传/替换资料，平台与报关行线下处理后上传新的回执版本，再由该客户确认。首期通过资料、回执版本和动作历史追溯，不强制新增 `roundNo` 对象。
 
-## 13. F23 国内出仓
+客户打回只改变对应客户资料范围的确认状态，不重置其他客户已确认的回执。只有所有退税客户的当前回执都已确认，平台才可发送客户确认结果给报关行执行，并进入整柜正式申报。首期首发和确认后发送执行是两次独立动作。
+
+### 12.3 F22-C 所有客户通过后的整柜正式申报
+
+1. 平台检查所有退税客户当前回执均已确认，已发送确认结果给报关行执行，冻结本柜最终实装和资料/回执版本，生成整柜正式申报批次；
+2. 将整柜资料提交报关行确认，报关行完成正式申报；首版不做外部系统直连，保留人工提交和审计记录；
+3. 海关结果独立记录为查验、免查验放行、补件/退回、扣货等，不把客户确认回执直接当成海关放行；
+4. 报关行执行后，平台上传对应退税资料范围的真实报关完税文件；每个退税客户的完成文件齐全才完成报关并进入待发区。完税文件、正式申报及海关结果分别留痕，不互相冒充；海关异常由平台人工选择理由、填写说明并处理，“其他”必须填写备注；
+5. 报关事实不覆盖送港线的离仓、进港、甩柜事实。甩柜只人工修改原柜船名、航次和船期，保留修改历史；原柜和原任务不变，不回退报关资料、回执或客户确认。
+
+## 13. F23 送港、进港与甩柜
 
 ### 13.1 出仓硬门禁
 
-整柜所有关联入库单逐项检查：
+送港线的离仓/进港门禁逐项检查：
 
 - 无有效 HOLD；
 - 入库单为 `LOADED`；
 - 装柜计划为 `COMPLETED`；
 - PDA 柜次任务为 `COMPLETED`；
 - 订舱已 `RELEASED` 且分配当前柜次；
-- 四步照片与有效铅封完整；
+- 五类证据与有效锁码文本完整；
-- 整柜报关已完成并放行。
+- 送港任务和当前船次分配完整；
+- 报关完成是进入待发区以及后续仓库离开、送港和进港的前置。
 
-独立拖车状态和独立船期字段提供调度参考，但不是当前确认离仓的硬门禁。拖车在全部订舱柜次离仓后自动完成。
+订舱、拖车、仓库离开和港口进场属于待发区之后的送港线事实。容量不足导致甩柜时，由平台人工编辑原柜船名、航次和预计船期，保存原因、修改前后值、操作人和时间；柜子、订舱关联和原船期任务不变，不新建航次对象，也不重新生成报关批次或客户确认任务。
 
 ### 13.2 自动与人工确认离仓
 
-报关完成或其他门禁变化时系统自动尝试收敛。未自动完成时，平台在柜次/国内出仓页面：
+送港状态变化或其他送港门禁满足时系统自动尝试收敛。未自动完成时，平台在柜次/送港页面：
 
 1. 打开门禁清单；
 2. 逐项处理未通过原因；
@@ -309,13 +335,13 @@ PDA 点击“完成装柜”时，服务端重新校验：
 成功后系统：
 
 - 写入整柜唯一国内离仓事实；
-- 创建 `CarrierScheduleQuery`；
 - 写入实际 `DEPARTED_WAREHOUSE` 节点；
-- 触发出仓后船节点查询；
+- 写入 `PORT_RECEIVED` 或 `ROLLED_OVER`；
+- 维护船次和开船前等待，不把预计 ETD 记成海运在途；
 - 检查并尝试完成订舱级拖车；
 - 保持跨区交接事件可重试且不重复建单。
 
-实际离仓节点产生后禁止撤销。发现错误转入线下和后续阶段异常处理，不提供修改历史伪装未离仓的能力。
+实际离仓和进港节点产生后禁止撤销。发现错误转入线下和后续阶段异常处理，不提供修改历史伪装未离仓或未进港的能力。报关线的客户打回、重新发送和海关查验单独记录，不回滚送港事实。
 
 ## 14. 状态和动作总表
 
@@ -325,8 +351,11 @@ PDA 点击“完成装柜”时，服务端重新校验：
 | 装柜计划 | `EDITING → LOADING → COMPLETED` | 预装调整/PDA 作业/最终完成 |
 | 订舱 | `DRAFT → RELEASED` | 补齐资料并放舱 |
 | 拖车 | 非终态 → `COMPLETED` | 所有要求柜次实际离仓后自动完成 |
-| 报关 | 资料收集 → 已冻结办理中 → 已完成/放行 | 客户上传、平台开始、上传回执并完成 |
+| 柜级报关 | `WAITING_CUSTOMER_DOCUMENTS → READY_TO_START → DECLARING → COMPLETED` | 装柜后收集退税资料并首次发送；回执必须经对应客户确认，平台发送确认结果后等待所有真实完税文件 |
-| 国内出仓 | 等待门禁 → 可出仓 → 已离仓 | 自动尝试或平台确认 |
+| 客户回执确认 | `PENDING → CONFIRMED / REJECTED` | 当前文件版本整份确认或填写原因打回；替换回执只重置对应客户范围，保留历史 |
+| 正式申报与海关结果 | 批次、结果分别保存 | 平台人工正式提交、回填报关单号、标记查验/补资料/扣货/其他及人工处理，不改柜级报关四态和运输事实 |
+| 送港 | `WAITING_FOR_LOADING → PORT_DELIVERY_PENDING → DEPARTED_WAREHOUSE → IN_TRANSIT_TO_PORT → PORT_RECEIVED / ROLLED_OVER` | 报关完成后进入待发区，再安排拖车和进港；容量不足时在原柜船期上人工修改船信息并留痕 |
+| 海运 | `WAITING_SAILING → VESSEL_DEPARTED → IN_TRANSIT` | 只有承运船舶真实开航才进入海运节点 |
 
 主状态只表达阶段结果。订舱、拖车、PDA、证据和报关保持关联子状态，页面应汇聚展示，但不能互相覆盖。
 
@@ -358,8 +387,11 @@ WAIT_SPLIT 入库单/已封托托盘
   → 预装确认/动态调整
   → PDA 实装 + 五类证据
   → COMPLETED / LOADED + 数量分片 + 跨区快照
-  → 整柜报关放行
+      ├─ 报关线：通知报关 → 客户资料 → 报关行回执 → 客户确认/打回重做
-  → 国内离仓 + DEPARTED_WAREHOUSE + 船节点查询任务
+      │             → 所有客户通过 → 整柜正式申报 → 查验/放行
+      └─ 送港线：拖车 → DEPARTED_WAREHOUSE → PORT_RECEIVED
+                    → 甩柜/改配（如发生）→ 等待实际开船
+  → VESSEL_DEPARTED → 海运节点查询
 ```
 
 阶段完成必须同时满足：
@@ -367,14 +399,14 @@ WAIT_SPLIT 入库单/已封托托盘
 - [ ] 最终柜次、装柜计划、订舱、真实柜号关联可追溯
 - [ ] 全部实装箱/托盘/SKU 与入库单数量守恒
 - [ ] PDA 任务完成且无未解决异常
-- [ ] 四步照片、铅封照片和铅封号完整有效
+- [ ] 五类证据和锁码文本完整有效
 - [ ] 装柜计划 `COMPLETED`，实装入库单 `LOADED`
 - [ ] 部分装载时已装子单和余量子单正确
-- [ ] 整柜报关已完成并放行
+- [ ] 报关线按每个退税客户隔离资料和入仓码范围，回执、确认/打回及文件版本可追溯；完成文件覆盖全部退税范围
-- [ ] 所有入库单无 HOLD
+- [ ] 送港线已记录唯一国内离仓历史；如已进港，存在 `PORT_RECEIVED`，如甩柜，存在原船次/改配船次历史
-- [ ] 唯一国内离仓历史存在
+- [ ] 客户全部确认后才允许整柜正式提交；正式申报后的查验/放行结果单独记录
-- [ ] 第一条实际 `DEPARTED_WAREHOUSE` 存在
+- [ ] 只有实际 `DEPARTED_ORIGIN_PORT` 才推进 F24海运中；离仓后唯一查询任务可预先建立，甩柜仍使用原任务
-- [ ] 船节点查询任务和跨区事件可幂等重试
+- [ ] 跨区事件可幂等重试；甩柜/改配只新增船期事实，不覆盖报关资料、回执和客户确认
 
 ## 17. 易用性与数据流评审问题
 
@@ -408,7 +440,7 @@ WAIT_SPLIT 入库单/已封托托盘
 
 - `docs/国内货柜履约/README.md`
 - `docs/国内货柜履约/国内货柜履约页面与原型清单.md`
-- `docs/头程下单到尾程出库现状流程全景清单.md`
+- `docs/归档/头程到尾程/头程下单到尾程出库现状流程全景清单.md`
 - `docs/统一订单主状态与操作契约.md`
 - `apps/admin-web/src/modules/container-loading/`
 - `apps/admin-web/src/modules/loading-lists/`
@@ -422,3 +454,4 @@ WAIT_SPLIT 入库单/已封托托盘
 - `baiyue-firstleg/firstleg/src/main/java/com/baiyue/firstleg/service/SmartLoadingService.java`
 - `baiyue-firstleg/firstleg/src/main/java/com/baiyue/firstleg/service/LoadingPickService.java`
 - `baiyue-firstleg/firstleg/src/main/java/com/baiyue/firstleg/outbound/dispatch/service/OutboundDispatchService.java`
+

头程到尾程分阶段流程/阶段二-国内到仓测量计费与组托.md

@@ -574,7 +574,7 @@ Firstleg 正式入库单 + 稳定箱码
 
 ## 16. 事实来源
 
-- `docs/头程下单到尾程出库现状流程全景清单.md`
+- `docs/归档/头程到尾程/头程下单到尾程出库现状流程全景清单.md`
 - `docs/入库测量与计费/README.md`
 - `docs/入库测量与计费/入库测量与计费需求优化版-v2-测量计费入库主流程.md`
 - `docs/统一订单主状态与操作契约.md`
@@ -590,3 +590,4 @@ Firstleg 正式入库单 + 稳定箱码
 - `baiyue-firstleg/firstleg/src/main/java/com/baiyue/firstleg/service/InitialInboundPricingService.java`
 - `baiyue-firstleg/firstleg/src/main/java/com/baiyue/firstleg/service/DropshipPalletizationService.java`
 - `baiyue-firstleg/firstleg/src/main/resources/openapi/dropship-palletization-v1.yaml`
+

头程到尾程分阶段流程/阶段五-海外接柜库存与库内服务.md

@@ -28,7 +28,7 @@
 | 企业操作员 | Client | 查看本企业库存，发起换标、转运、废弃等自助服务 | 不查看其他客户或直接改实物托盘 |
 | 换标作业员 | 海外 PDA | 认领、扫描旧/新标、拍照、提交复核 | 不自行批准复核或客户确认 |
 | 换标复核员 | Admin | 退回返工、核对作业事实 | 已由客户确认后不能退回 |
-| 废弃审核员 | Admin/PDA | 审批一件代发废弃并触发实际扣减 | 创建申请时不得直接扣库存 |
+| 废弃审核员 | Admin | 审批一件代发废弃，授权仓库执行 | 申请与审批均不扣库存；由海外 PDA 实际废弃确认时扣减 |
 | Lastleg | 后端 | 入仓作业、库存业务、子单、状态和事件权威 | 不拥有物理仓/托盘主档 |
 | Warehouse Overseas | 后端 | 海外库位、实物托盘、资源锁和物理状态 | 不拥有库存客户归属和尾程订单 |
 
@@ -48,6 +48,8 @@
 
 只要任一计划仍缺真实资源，就不能准备、签收或开始该柜。PDA 首次扫码只确认计划阶段已预留资源，不在现场重新分配托盘或库位。
 
+本地计划和托盘行已保存，不代表远端资源批次已确认。原柜级转换命令处于 `LOCAL_COMMITTED` 时，仅该命令冻结明细中的计划继续显示待资源确认，并计入平台可恢复的柜；同柜此前已确认的计划保持原状态。平台关闭重开后仍使用原幂等键、版本和摘要完成资源确认，不新建计划或预留；远端确认完成后才恢复已计划状态和PDA操作资格。读取预览不自动执行确认。
+
 ## 4. F28 海外 PDA 柜号签收
 
 ### 4.1 查看待卸货柜
@@ -297,7 +299,15 @@ PDA 扫描托盘后按服务端返回的 `palletVersion`、`positionVersion` 执
 4. 通过后冻结对应库存并进入转运出库；
 5. 实际移出和目标收货按转运单、库存流水和资源操作闭环。
 
-转运状态保存在子单，不覆盖尾程主状态 `INBOUND_COMPLETED`。
+既有库存转运的执行入口承载于 Admin 尾程订单详情中的“转运与换标履约”：来源分配完成且本票必要换标已获客户确认后，按执行权限确认出库；出库后按已发运未实收的来源选择目标海外收货仓、实际托盘及该托盘绑定的库位，逐笔确认目标仓实收。此入口与 PDA 来货转运测量、通用派送出库不同，不能以另一条状态链的按钮替代。
+
+目标实收按本票已发运的来源位置逐笔进行。服务端核对真实海外收货仓、托盘绑定库位和冻结FBA目的仓，先保存原请求及摘要，再取得有效资源占用；同一转运的多个来源收到同一目标托盘时共享一次物理占用。资源服务已成功而本地库存事务失败时，保留原请求供原键原载荷恢复，不盲目释放、换键或更换目标。库存、收货凭据、来源状态及最终关联换标费用/结算命令在本地同一事务完成；原成功请求重放不重复入账、占用或收费，钱包最终结果由既有结算回执确认。
+
+转运详情须提供本客户本票持久化的实收命令状态、原请求和权威目标。关闭重开或换浏览器后，未完成命令仍按原载荷继续；已完成命令的目标可供本票其他来源续收，不能仅因托盘为OCCUPIED而拒绝本票，也不能仅凭浏览器缓存将其他单据占用的托盘放行。出库未知结果先读取正式转运状态核对，不自动新建操作重复出库。
+
+转运目标库存继续归属于该来源余额的真实入仓单ID、入仓单号及入仓码，不能使用转运尾程订单ID冒充入仓单身份。转运号作为本次操作和收货凭据的业务关联保留；目标海外仓、目的仓、托盘与库位取本次确认的权威资源。不同来源入仓单即使落入同一物理托盘，也应分别保留库存归属；后续库存选择与再次转运必须仍能解析合法的入仓来源。
+
+转运状态保存在子单，不覆盖已经成立的尾程主状态 `INBOUND_COMPLETED`。既有库存转运须分别区分原来源尾程订单和本票独立转运尾程订单：原来源不因本次转运修改状态；本票在库存分配后已建立的INBOUND_COMPLETED也不能被换标回调的ALLOCATED、转运出库的IN_TRANSIT或转运实收的COMPLETED覆盖。具体转运进度由转运单及 `sub_order_status` 表达，此规则不替代后续真正的派送出库与签收主链。
 
 ### 9.5 一件代发货物废弃
 
@@ -305,12 +315,13 @@ PDA 扫描托盘后按服务端返回的 `palletVersion`、`positionVersion` 执
 
 1. 客户选择箱唛并创建申请；
 2. 箱从 `AVAILABLE` 锁定为 `DISCARD_PENDING`，此时不扣 SKU 箱数；
-3. 有 `lastleg:cargo-discard:approve` 权限的仓库/PDA 人员现场审核；
+3. 平台由具有 `lastleg:cargo-discard:approve` 权限的人员审核；审核通过只批准作业，不提前扣库存；
 4. 拒绝时只释放锁，不扣库存；
-5. 通过时在同一事务调用专用 discard adjustment；
+5. 仓库/PDA人员确认实际废弃数量时，在同一事务调用专用 discard adjustment，确认即扣库存（2026-10-05用户确认）；
-6. 箱进入 `DISCARDED`，写逐箱流水和唯一幂等键；
+6. 实际废弃的箱进入 `DISCARDED`，写逐箱流水和幂等事实；
-7. 校验扣减前箱数减废弃箱数等于扣减后箱数，且逐箱合计等于申请总数；
+7. 校验扣减前箱数减实际废弃箱数等于扣减后箱数，逐箱合计与实际确认总数一致；
-8. 任一失败整体回滚。
+8. 实际确认失败时扣减、状态及流水整体回滚；同单同托相同完整载荷重放不得重复扣减或追加完成历史，异数量拒绝；
+9. 全部PDA作业完成后平台结案；结案及其重放不再次扣库存。审批驳回仍只释放锁。
 
 ## 10. 状态与数据归属
 
@@ -341,10 +352,12 @@ PDA 扫描托盘后按服务端返回的 `palletVersion`、`positionVersion` 执
 | 暂扣票参与排车 | 服务端拒绝，先按权限解除 |
 | 换标一项未完成 | 混合单不计整箱完成 |
 | 换标被退回 | 展示备注，清理设备草稿后按新轮返工 |
-| 废弃审批失败 | 锁定和扣减整体回滚，不产生半套流水 |
+| 废弃实际确认失败 | 本次扣减、确认状态和流水整体回滚，不产生半套流水；审批不提前扣减 |
 
 ## 12. 阶段完成判定
 
+测试环境综合证据 `baiyue-firstleg/reports/admin-full-postdeploy-66c2651b.json` 已覆盖海外 PDA、收货、库存、库内服务和 `phase5-overseas-fulfillment`；上述模块失败数均为 0。这里的清单继续保留为逐票验收条件，不能用综合报告替代具体柜次的业务核对。
+
 主链完成必须满足：
 
 - [ ] 柜号由正确仓库操作员认领

头程到尾程分阶段流程/阶段六-海外排车出库派送与回写.md

@@ -73,6 +73,8 @@ PDA 只调用 `/api/pda/**` 专用接口，客户和仓库由 Token、Gateway
 6. 草稿锁原子转换为正式排车锁；
 7. 生成排车单，初始为 `PENDING_DEPARTURE`。
 
+普通智能预排按界面非空装车容器分组，一次提交整份草稿；服务端核对每组容器归属、当前托盘锁、唯一客户/海外仓及托位容量，逐组生成独立排车单和PDA任务。任一组失败时整批回滚，不能先成功一组再把其余组隐藏。相同分组重新提交返回各自对应原单，不重复创建或将不同容器合并；空容器不产生排车。单张排车接口不得接收多个草稿容器混合的平铺托盘数组。换标仍按其单张申请的完整量排车，多容器选择必须明确拒绝，不能静默合并。
+
 路线由已排托盘目的仓编码去重并稳定排序生成，预排和普通编辑都不接收人工路线文本。
 
 ### 4.3 排车编辑和取消
@@ -81,6 +83,8 @@ PDA 只调用 `/api/pda/**` 专用接口，客户和仓库由 Token、Gateway
 
 未执行、未产生不可逆拣货事实的排车可取消并释放正式锁。开始拣货后不能用取消恢复库存或抹掉作业历史。
 
+取消后保留原排车明细作为历史；入库单的排车状态及“已排车/未排车”筛选只计入同客户、同来源订单的未取消排车。若没有其他有效排车，显示未排车并可重新排车；存在替代排车或已发车、已完成的排车时仍显示已排车。列表与分页总数采用同一判断，不以历史明细存在代替当前排车状态。
+
 ## 5. F35 排车转派送
 
 允许状态：`PENDING_DEPARTURE`、`PICKING`、`READY_TO_DEPART`，且必须早于发车。
@@ -213,7 +217,7 @@ Admin/Client 按权限查看拆分后的单仓派送单、目的地、车辆/快
 
 ### 10.2 跨区完成事件
 
-每张实际完成的派送单在业务事务内写 Outbox。Event Bridge 跨区投递后，Firstleg：
+每张实际完成的派送单在业务事务内写 Outbox。Lastleg Relay 按[统一认证与服务通信契约](../统一认证与服务通信契约.md)直接投递 Firstleg 内部消费者；只有匹配原事件 ID、Payload 哈希和允许结果的持久化消费 ACK 才记为投递成功。Firstleg：
 
 1. 校验内部身份、事件版本、ID 和 Payload 哈希；
 2. 校验来源订单、来源入仓单、入仓码和 FBA 目的仓；
@@ -223,7 +227,13 @@ Admin/Client 按权限查看拆分后的单仓派送单、目的地、车辆/快
 
 ### 10.3 Order 最终完成
 
-Firstleg 检查同一 Order 的全部有效入库单。只有全部都为 `DELIVERED` 时，才调用 Order 推进交易状态为 `COMPLETED`。
+Firstleg 检查同一来源 Order 的全部有效入库单。只有全部都为 `DELIVERED` 时，才向 Order 回写该来源单的签收完成事实，并携带真实履约根订单。
+
+余量拆分后，根订单仍承载自身第一批实装货物，子订单分别承载余量。子订单可独立完成；根订单只有自身实装货物已经签收，且全部未删除、未取消的子订单均为 `COMPLETED` 时，才进入 `COMPLETED`。仅明确 `CANCELLED` 的子单排除，草稿、待审核或其他未完成状态均阻断根订单收口。最后余量取消也重新计算根完成条件。来源单签收事实和根最终完成历史分开保存，不能用子单完成代替根自身签收。
+
+Order 在同一事务内写完成状态、历史和完成 Outbox，经内部接口可靠同步 Firstleg 订单状态摘要。来源单与根的状态分别返回，根尚未完成时不得把根摘要提前标成完成。
+
+平台不提供人工完成订单接口。普通订单状态操作不得直接设置 `COMPLETED`，完成状态只能由真实签收回写及符合上述门禁的取消后聚合产生，不能绕过仍有效的余量子单。
 
 部分装载形成的余量子单、另一柜或另一目的仓尚未完成时，Order 不能提前完成。重复事件不得重复推进、重复写历史或重复生成费用。
 
@@ -264,6 +274,8 @@ INBOUND_COMPLETED + 可用库存
 
 ## 13. 全流程最终完成判定
 
+测试环境综合证据 `baiyue-firstleg/reports/admin-full-postdeploy-66c2651b.json` 已覆盖 `phase4-overseas-dispatch`、`phase5-terminal-drayage`、`phase5-overseas-fulfillment`、客户服务和跨区回写模块，相关模块失败数均为 0。清单仍按具体派送单保留，最终上线前需要用业务柜次逐项复核。
+
 - [ ] 排车候选来自真实、可用且未被其他业务占用的库存
 - [ ] 草稿锁、正式锁和取消/完成释放均可追溯
 - [ ] 排车路线由实际目的地生成

头程到尾程分阶段流程/阶段四-海运目的港与尾程计划.md

@@ -1,7 +1,7 @@
 # 阶段四：海运、目的港与尾程入仓计划
 
 > 对应全景流程：F24～F27。  
-> 阶段起点：柜次已确认国内离仓，存在实际 `DEPARTED_WAREHOUSE` 节点和可查询的真实订舱/柜次。  
+> 阶段起点：柜次已完成送港/进港或甩柜处理，并产生承运船舶实际 `VESSEL_DEPARTED`/`DEPARTED_ORIGIN_PORT` 节点；真实 `DEPARTED_WAREHOUSE` 和 `PORT_RECEIVED` 属于阶段三送港线事实。  
 > 阶段终点：跨区尾程订单完整生成，整柜每票入仓计划及托盘/库位资源已生成或有明确资源失败待办，订单进入 `INBOUND_PLANNED`。  
 > 本阶段同时维护船舶/货柜轨迹和尾程业务准备，但两类状态不得互相冒充。
 
@@ -9,7 +9,7 @@
 
 本阶段完成四条相互关联但独立的链路：
 
-1. 从国内离仓开始查询并保存十个标准船节点；
+1. 从承运船舶实际开航开始查询并保存十个标准船节点；
 2. 管理目的港清关、海外码头车队、提柜、预计到仓和还空；
 3. 将国内最终实装快照可靠投递到海外区域并创建尾程订单；
 4. 按整柜维护每票计划并转换为可执行的海外入仓计划和资源。
@@ -26,18 +26,18 @@
 | 企业成员 | Client | 查看本企业尾程订单和允许展示的船期/计划进度 |
 | Firstleg | 后端 | 拥有查询任务、标准节点、目的港码头拖车和装柜完成 Outbox |
 | Integration Service | 后端 | 调用船司/轨迹供应商，解析并返回标准化结果，不保存业务主数据 |
-| Event Bridge | 跨区通道 | 版本化、认证地投递业务事件 |
+| 业务服务 Outbox Relay | 内部直接投递 | 按事件类型选择消费者，验证事件身份、摘要和持久化消费 ACK，有限重试与受保护人工恢复 |
 | Lastleg | 海外后端 | Inbox 幂等消费、尾程订单、计划、在途库存和海外业务状态 |
 | Warehouse | 国内主数据 | 海外共享仓、FBA 目的仓和供应商主档权威 |
 | Warehouse Overseas | 海外资源 | 海外库位、实物托盘和资源锁 |
 
-所有浏览器海外接口经 `gateway-overseas/`。国内 Auth 仍是账号和 Token 签发方；跨区业务写入通过内部身份、Inbox/Outbox 和事件契约完成，不允许浏览器伪造跨区事件。
+所有浏览器接口经统一 `gateway/`，Auth 是唯一账号、Token 和会话权威。业务服务保持各自数据归属和客户隔离；服务间写入通过内部身份、Inbox/Outbox 和事件契约直接投递，不允许浏览器伪造服务间事件。现行投递和结果确认规则见[统一认证与服务通信契约](../统一认证与服务通信契约.md)。
 
 ## 3. 阶段前置检查
 
-- 柜次存在真实集装箱号、订舱、提单号和国内离仓事实；
+- 柜次存在真实集装箱号、订舱、提单号、送港/进港事实和实际开船节点；
 - 装柜完成事件包含最终实装订单、入仓单、目的类型、箱数及必要托盘/SKU/箱唛快照；
-- 国内四步照片和铅封证据已经冻结；
+- 国内五类装柜证据和锁码文本已经冻结；
 - 接柜海外仓是 Warehouse 中 `ACTIVE + OVERSEAS + RECEIVING` 的平台共享物理仓；
 - FBA 目的仓是 Warehouse 有效公共主档，不能用接柜仓或国内仓代替；
 - 船司/轨迹查询标识足以唯一指向目标订舱和柜次；
@@ -47,9 +47,11 @@
 
 ### 4.1 查询任务创建
 
-国内出仓确认事务幂等创建 `CarrierScheduleQuery`。任务必须绑定真实订舱、柜次以及可用的船司、船名航次、提单号或柜号，不创建脱离业务单据的孤立轮询任务。
+确认国内离仓后，系统按订舱与柜次幂等建立唯一 `CarrierScheduleQuery`，触发来源为 `OUTBOUND_CONFIRM`，用于后续送港和船节点查询。任务必须绑定真实订舱、柜次以及可用的船司、船名航次、提单号或柜号，不创建脱离业务单据的孤立任务。任务已建立不表示船舶已开航；只有实际 `DEPARTED_ORIGIN_PORT` 事实才能推进 F24“海运中”，不能用预计 ETD 或查询任务存在提前推进。
 
-首个实际节点由国内出仓写入：
+标准节点保留国内送港事实，但海运查询的起点是实际开船：
+
+`DEPARTED_WAREHOUSE`、`AT_ORIGIN_PORT` 和 `LOADED_ON_VESSEL` 可以作为送港/装船历史记录，查询任务也可收集开航前的实际港口事实。客户的“海运中”节点以真实 `DEPARTED_ORIGIN_PORT` 为起点。甩柜时人工编辑原柜船信息并保留历史，继续使用原任务，不因改船或预计日期生成实际开航事实。
 
 ```text
 10 DEPARTED_WAREHOUSE       已离开国内仓
@@ -187,9 +189,9 @@ Firstleg 在装柜完成后按最终实装生成 `FIRST_LEG_LOADING_PLAN_COMPLET
 
 Outbox 可重复投递，不能因网络失败直接丢事件或在事务外临时拼装 Payload。
 
-### 6.2 Event Bridge 投递
+### 6.2 Outbox 直接投递
 
-Event Bridge 校验允许的事件类型、版本、来源/目标区域和内部服务身份后投递 Lastleg。IAM 安全事件使用独立入口，不能交给装柜完成消费者。
+Firstleg 的 Outbox Relay 将装柜完成和船节点事件直接投递 Lastleg 的内部消费者，保留原事件 ID、版本和 Payload 哈希。只有持久化消费 ACK 的身份、摘要和允许的结果全部匹配才记录投递成功；临时故障按有限退避重试，耗尽后进入 DEAD，由受保护运维入口审计后重试原事件。重复消费不能重复建单；同一事件 ID、不同摘要必须拒绝。IAM 安全事件不能交给装柜完成消费者。
 
 ### 6.3 Lastleg Inbox 消费
 
@@ -219,6 +221,13 @@ Lastleg 消费步骤：
 
 ## 7. F27 尾程计划维护和整柜转换
 
+### 7.0 尾程订单列表页签
+
+- 页签固定为“全部、开船前、开船后”。“全部”保留所有订单类型；后两个页签仅包含国内头程订单（`orderType=FIRST_LEG`，不再额外以内部来源字段限制）。一件代发、换标、仓储转运、本土散板、退货及废弃等其他类型只在“全部”展示。
+- “开船后”依据实际柜级船节点序号达到 40（实际离开起运港）及后续节点；只有预计开船、装船或尚无实际节点仍归“开船前”。订单启用人工节点覆盖后，仅按该票 `ACTUAL_DEPARTURE` 是否有时间判断，不回退柜级节点。
+- 船阶段筛选不改变订单主状态或排车、排约等操作资格；状态筛选继续独立生效。服务端在分页前过滤，列表总数及导出使用相同口径；客户端不按当前页记录二次筛选。
+- 按柜批量生成入库计划入口在三个页签保留，仍使用全柜预览和原计划门禁，不将船阶段视为生成计划的资格。
+
 ### 7.1 柜级工作台
 
 入口：Admin → 海外仓 → 尾程订单 → 柜级工作台。
@@ -292,6 +301,8 @@ Lastleg 消费步骤：
 
 整批转换原子且幂等：相同命令重放不生成第二批计划或资源；本地失败只补偿尚未确认的远端资源；远端确认失败的重放只重试确认。
 
+资源确认失败后，即使关闭弹框或刷新页面，也必须恢复原柜级命令。预览在 `LOCAL_COMMITTED` 时额外返回 `resourceRetry`，包含原 `idempotencyKey`、`snapshotVersion` 和 `snapshotHash`；页面用这一整组原值重试。外层快照与分组继续反映当前计划状态，用于展示，不能替换恢复命令的快照。其他命令状态不返回该恢复字段；缺少原重试依据时拒绝操作，不新建命令、计划或第二批资源。此字段不改变服务端“同键不同载荷拒绝”的规则。
+
 ## 8. 状态、编号与数据归属
 
 | 维度 | 关键状态/编号 | 权威系统 |
@@ -327,6 +338,8 @@ Lastleg 消费步骤：
 
 ## 10. 阶段完成判定
 
+现有测试环境综合证据 `baiyue-firstleg/reports/admin-full-postdeploy-66c2651b.json` 中，`phase4-carrier-nodes`、`phase4-overseas-pda`、`phase4-overseas-pda-operations`、`phase4-overseas-inbound-operations`、`phase4-overseas-dispatch`、`phase4-tail-order-controls` 和 `phase5-overseas-fulfillment` 均为通过；每个模块的失败数为 0。F23.3 的最新船期客户端投影另见 `baiyue-firstleg/reports/transport-projection-after-schedule-update-20260927.json`。
+
 - [ ] 国内离仓产生的船节点任务绑定真实订舱和柜次
 - [ ] 节点预计/实际/观测时间没有混用
 - [ ] 异常事实与正常节点分开保存

头程到尾程流程节点梳理.md

@@ -0,0 +1,91 @@
+# 头程到尾程流程节点梳理
+
+> **当前用途：全流程收尾变更的流程入口。** F01-F40 的业务基线已经确认，报关协同代码已接入并通过测试环境验收；本文件只保留三大业务块、关键节点和节点之间的关系，便于查找和修改。报关实现细节请看[报关代码开发交接清单](头程到尾程/报关代码开发交接清单.md)，历史开发规划、进度、门禁和评审不在这里继续维护。
+>
+> **维护原则：** 客户看到的是进度投影，后台看到的是业务对象节点，明细节点记录真实操作和结果。三者使用同一组业务事实，不另建一套客户状态。
+
+## 一、三大业务块
+
+| 业务块 | 覆盖范围 | 对外主要进度 | 后台主要对象 | 分段详情 |
+|---|---|---|---|---|
+| **头程下单** | 客户下单、审核、国内到仓、测量、计费、确认、组托 | 待下单 → 审核中 → 待到仓/测量 → 待分柜 | 订单、入仓单、测量记录、费用记录、托盘 | [阶段一](头程到尾程分阶段流程/阶段一-客户准入与头程下单.md)、[阶段二](头程到尾程分阶段流程/阶段二-国内到仓测量计费与组托.md) |
+| **海运（货柜）** | 分柜、订舱、拖车、拣货、装柜、报关协同、待发区、送港、进港、甩柜、实际开船、目的港和尾程计划 | 待分柜 → 装柜中 → 报关中 → 待发区 → 送港/待开船 → 海运中 → 待入仓 | 柜次、装柜任务、报关批次、待发区、送港任务、船次、尾程入仓计划 | [阶段三](头程到尾程分阶段流程/阶段三-国内货柜履约与出仓.md)、[阶段四](头程到尾程分阶段流程/阶段四-海运目的港与尾程计划.md)、[报关专题](国内货柜履约/报关资料与船期价格接入梳理.md) |
+| **尾程入库和派送** | 海外接柜、拆柜实收、入库、库存服务、排车、出库、派送、签收、异常回写 | 待接柜 → 入库中 → 待派送 → 出库/派送中 → 已签收/异常 | 接柜任务、入库单、库存、出库单、派送单、异常单 | [阶段五](头程到尾程分阶段流程/阶段五-海外接柜库存与库内服务.md)、[阶段六](头程到尾程分阶段流程/阶段六-海外排车出库派送与回写.md) |
+
+三大块是客户和产品的展示分组；F01～F40 是后台查找和验收用的内部编号，不代表客户必须看到 40 个节点，也不代表所有动作严格串行。
+
+## 二、主流程
+
+```text
+头程下单
+  客户下单 → 订单审核 → 国内到仓 → 测量/计费 → 费用确认（不阻断）→ 组托/待分柜
+        ↓
+海运（货柜）
+  分柜/订舱/拖车 → 拣货 → 装柜完成（LOADED）
+        └─ 报关协同：客户资料 → 报关行回执 → 客户确认/打回重做 → 全部客户通过
+                       → 整柜资料交报关行 → 正式申报 → 查验或不查验放行
+                                      ↓ 报关完成
+                                  进入待发区
+        送港运输：待发区 → 离仓 → 送港 → 进港 → （容量不足时）甩柜/改配
+                         ↓
+                    船舶实际开航后进入海运节点
+        ↓
+  目的港清关/提柜 → 尾程入仓计划
+        ↓
+尾程入库和派送
+  海外接柜 → 拆柜实收 → 入库/库存 → 排车 → 出库 → 派送 → 签收/异常回写
+```
+
+## 三、关键节点总表
+
+| 编号 | 业务块 | 客户进度节点 | 后台管理节点 | 真实明细节点 | 完成结果或分支 |
+|---|---|---|---|---|---|
+| F01-F07 | 头程下单 | 待下单、审核中、已审核 | 企业、订单、审核任务 | 填写、提交、补件、审核、生成入仓单 | 审核通过后进入国内履约 |
+| F08-F10 | 头程下单 | 待到仓、测量中、待确认 | 入仓单、测量记录 | 到仓收货、扫码、称重、测量、审核 | 形成可排柜的实测数据 |
+| F11-F13 | 头程下单 | 费用待确认、国内扣货/解除、待组托、待分柜 | 费用版本、确认记录、HOLD 记录、托盘 | 计费、推送、客户确认、国内扣货/解除、组托/封托 | 费用确认不阻断主链；国内扣货单独控制作业门禁；装柜不能代替客户确认费用 |
+| F14-F20 | 海运（货柜） | 待分柜、订舱中、装柜准备/进行中 | 柜次、装柜计划、拖车任务、拣货任务 | 分柜、订舱、排车、拣货、拍照、铅封、数量核对 | 通过装柜门禁后才能完成装柜 |
+| F21 | 海运（货柜） | 国内已装柜 | 装柜任务已完成 | 实际柜号、实装数量、装柜证据确认 | 产生 `LOADED`；完成报关后才进入待发区 |
+| F22 | 海运（货柜） | 报关确认中、待补资料、已提交报关 | 客户报关案例、报关批次 | 收集资料、发报关行、接收回执、客户确认或打回、重新上传和重发 | **已实现并通过真实 HTTP 验收**；柜内所有客户确认后，才能提交整柜资料并正式申报；客户确认不等于海关放行 |
+| F23 | 海运（货柜） | 待发区、送港中、已进港、待开船、已甩柜 | 待发区、送港/拖车任务、港口和船次事实 | 报关完成后入待发区、离仓、送港、进港、甩柜、改配 | 报关完成是进入待发区的门槛；甩柜/改配只改变运输船期，不重做已完成报关 |
+| F24 | 海运（货柜） | 海运中 | 船次实际状态 | 承运船舶实际开航、船期回写 | 只有实际开航后进入海运节点 |
+| F25-F27 | 海运（货柜） | 目的港处理中、待海外接柜 | 目的港清关/提柜、尾程订单、入仓计划 | 清关、提柜、创建尾程计划 | 形成海外接柜输入，不等于已经入库 |
+| F28-F33 | 尾程入库和派送 | 待接柜、入库中、库存可用 | 接柜任务、入库单、库存 | 接柜、拆柜、收货核对、上架、盘点及库内服务 | 实收核平并入账后形成可用库存 |
+| F34-F37 | 尾程入库和派送 | 待派送、出库处理中、已出库 | 排车、出库单、派送单 | 生成出库/派送单、拣货、复核、发车 | 出库和签收分开记录 |
+| F38-F40 | 尾程入库和派送 | 派送中、已签收、异常 | 派送单、签收和异常单 | 送达、签收、拒收/部分拒收、退回、最终回写 | 异常保留原事实和恢复结果；全部有效分片完成后订单收口 |
+
+## 四、必须保持的流程关系
+
+### 1. 报关完成后进入待发区，船期单独推进
+
+`LOADED` 只表示货物已经实际装入集装箱并完成装柜记录。之后先完成报关协同，报关完成后货物进入待发区：
+
+- **报关协同线**：通知报关行，按客户/入仓码收集资料；报关行生成回执后发客户确认。客户打回时，只重做对应客户的资料、发送和回执，直到柜内所有客户都确认。全部确认后，将整柜资料交报关行确认，再记录正式申报和海关结果。
+- **待发区与船期线**：报关完成后进入待发区，再安排离仓、送港和进港；船舱不足时记录甩柜和改配。甩柜/改配只人工修改原柜的船名、航次和船期，不影响已完成的报关资料、回执和客户确认。
+
+报关行回执、客户确认、正式申报、海关放行、进入待发区、进港、甩柜和实际开船是不同事实，不能合并成一个“报关完成”或“海运中”。
+
+### 2. 费用确认不阻断装柜主链
+
+费用确认是头程下单块中的并行事项。客户未确认时可以继续排柜、拣货和装柜。按阶段二及 Firstleg 当前服务指引，装柜完成可以触发平台费用确认与发布，但不能代替客户主动确认；客户已确认且本票装柜完成时才最终冻结。费用确认与报关资料的客户确认分别记录。
+
+### 3. 异常附着在主节点上
+
+查验、扣货、资料打回、甩柜、拒收和跨区回写失败都应保留发生在哪个主节点、责任人、处理结果和恢复时间。异常可以阻断对应分支，但不要用“异常”覆盖主流程已经发生的事实。
+
+## 五、三层节点的使用口径
+
+| 层级 | 解决的问题 | 示例 |
+|---|---|---|
+| 客户进度节点 | 客户现在处于哪一段、下一步做什么 | 报关确认中、送港中、海运中、入库中 |
+| 后台管理节点 | 哪个业务对象正在处理、由谁处理 | 报关批次待客户确认、送港任务已进港、派送单已出库 |
+| 真实明细节点 | 事实何时发生、凭什么证明 | 上传资料、回执版本、客户确认、离仓时间、进港记录、签收凭证 |
+
+客户页面只展示与自身相关的进度和资料；后台详情保留完整明细；异常作为附加状态展示，不另建一条互相矛盾的主流程。
+
+## 六、查找和修改规则
+
+1. **改流程关系或客户节点**：先改本文件，再检查对应阶段文档的名称和链接。
+2. **改单个阶段的字段、页面操作或权限**：只改对应的六份阶段文档和实际契约，不回写历史开发规划。
+3. **改报关资料、回执确认或船期价格**：以[报关资料与船期价格接入梳理](国内货柜履约/报关资料与船期价格接入梳理.md)为专题入口，同时核对本文件中的 F22/F23 关系。
+4. **开发规划、进度、开工门禁、验收任务、旧审计和优化方案**：保留原文作为追溯资料，标记为冻结，不作为当前流程入口。
+5. **新增或调整节点时**：先判断它属于客户进度、后台对象还是明细事实；只有确实改变三大块关系时才改总表，避免在多份文档复制同一段流程。

平台客户层级与权限契约.md

@@ -14,9 +14,17 @@
 - 当前尚未上线；同一资源已有 `*:list` 时，不保留或新增独立 `*:view` 兼容分支。前端不得使用 `permissionAnyOf` 接受旧 `view`，后端不得使用 `hasAnyAuthority(list, view)`，初始化 SQL 应停用或删除旧 `view` 资源及其角色关联。
 - 供应商固定使用 `platform:supplier:list` 作为菜单、列表和详情唯一只读权限；`platform:supplier:view` 必须停用或移除，不得在导航、路由、页面、Controller、OpenAPI 或 SQL 中恢复兼容。
 
+### Admin 菜单结构与显示
+
+- 一级、二级菜单的名称、分组和顺序以当前确认原型及当前对话确认为准，唯一代码入口为 `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`，不因原型未展示而隐藏；新增、编辑及其他写操作继续使用各自独立权限。
+- 尚无正式页面的菜单不显示，不保留禁用占位或空分组，不接入原型假数据、虚构权限码或新增业务接口。后续功能实现时再核对正式页面、权限与服务端合同。
+
 ## 跨层同步
 
-- 菜单结构、路由权限、页面按钮、Controller `@PreAuthorize`、OpenAPI 权限说明及 IAM 初始化/统一增量 SQL 必须同步核对，不能以局部测试通过替代跨层一致性。
+- 新增、修改或删除权限码、访问域或授权语义时，仅对实际受影响的菜单、路由、页面按钮、Controller `@PreAuthorize`、OpenAPI 权限说明及 IAM 初始化/统一增量 SQL 同步核对；核对不等于必须修改各层，不能以局部测试通过替代跨层一致性。按钮或菜单的界面调整及对已有状态、权限和操作资格的消费不触发本节联动，服务端鉴权与业务校验仍须保留。
 - 业务功能任务只维护所属页面与接口，不得根据局部旧上下文覆盖共享导航、根路由装配、IAM 菜单权限初始化或统一增量脚本中的已确认语义。
 - 发现共享文件与本契约冲突时，保留现有其他任务改动并交由对应总控统一收口；只有用户当前明确改变本契约时才能调整。
 

归档/README.md

@@ -0,0 +1,10 @@
+# 文档归档
+
+这里保存已经完成开发阶段、当前不作为日常流程入口的历史文档。归档只改变文件位置，不删除内容；需要追溯旧决策、旧验收或旧开发计划时再进入对应子目录。
+
+## 归档目录
+
+- [头程到尾程](头程到尾程/README.md)：全流程操作手册、旧现状全景、AI 上下文和易用性方案。
+- [国内货柜履约归档](../国内货柜履约/归档/README.md)：开发规划、进度、门禁、验收矩阵、审计和旧确认材料。
+
+当前流程只从 [头程到尾程流程节点梳理](../头程到尾程流程节点梳理.md) 开始查找。

归档/头程到尾程/README.md

@@ -0,0 +1,11 @@
+# 头程到尾程历史文档
+
+本目录只保留历史操作说明、旧版现状盘点和流程优化材料。它们不再作为当前流程或开发计划入口；当前节点关系以[头程到尾程流程节点梳理](../../头程到尾程流程节点梳理.md)为准，分段细节见[头程到尾程分阶段流程](../../头程到尾程分阶段流程/README.md)。
+
+## 文件
+
+- [全流程操作手册](头程下单到尾程出库全流程操作手册.md)
+- [现状流程全景清单](头程下单到尾程出库现状流程全景清单.md)
+- [AI 流程优化上下文包](头程到尾程AI流程优化上下文包.md)
+- [易用性与数据流转优化方案](头程下单到尾程出库流程易用性与数据流转优化方案.md)
+

归档/头程到尾程/头程下单到尾程出库全流程操作手册.md

@@ -5,7 +5,7 @@
 > 当前口径：以现行服务端模块指引、页面入口和代码状态机为准。历史设计与当前实现冲突的地方集中列在第 11 节，旧文档不能直接作为操作依据。  
 > 不在主链内展开：换标、仓储转运、货物废弃、退货换标、异常退回、客户回访、海外采购和本土散板；这些能力在第 9 节说明如何接入出库。
 
-> 完整现状流程目录：见[《头程下单到尾程出库现状流程全景清单》](头程下单到尾程出库现状流程全景清单.md)。该清单以 F01～F40 覆盖主链、并行流程、条件分支和异常流；本文侧重一票主链如何实际操作。
+> 当前流程基线：见[《头程到尾程流程节点梳理（重构版）》](../../头程到尾程流程节点梳理.md)。[《头程下单到尾程出库现状流程全景清单》](头程下单到尾程出库现状流程全景清单.md)仅保留旧版 AS-IS 证据；本文侧重一票主链如何按最新报关/送港并行流程实际操作。
 
 ## 1. 一张图看完整主链
 
@@ -23,10 +23,11 @@
 创建模拟柜/订舱 → 智能或人工排柜 → 预装确认
   ↓
 国内 PDA 拣货装柜 → 五类证据和铅封 → 装柜完成 LOADED
+  ├─ 报关线：通知报关行 → 客户资料 → 报关行回执 → 客户确认/打回重做
+  │          → 所有客户通过 → 整柜正式申报 → 查验/放行
+  └─ 送港线：拖车 → 离仓 → 送港/进港 → 甩柜/改配（如发生）→ 实际开船
   ↓
-整柜出口报关完成 → 系统自动收敛或平台确认国内出仓
+实际开船后进入海运节点：装船/离港 → 在途 → 到目的港 → 卸船 → 可提柜
-  ↓
-船节点：离开国内仓 → 起运港 → 装船 → 在途 → 到目的港 → 卸船 → 可提柜
   ↓
 装柜完成事件跨区 → 海外生成 PENDING_ASSIGNMENT 尾程订单
   ↓
@@ -43,9 +44,10 @@
 
 主链有三个不能混淆的“出库/出仓”：
 
-1. 国内装柜完成：入库单为 `LOADED`，表示货已经装入国内出口柜，不等于柜已离开国内仓。
+1. 国内装柜完成：入库单为 `LOADED`，表示货已经装入国内出口柜；同时启动报关线和送港线。
-2. 国内出仓：整柜通过报关等门禁并确认离仓，系统开始船节点跟踪。
+2. 国内送港：送港线记录拖车、仓库离开、进港和甩柜；客户报关确认不阻断送港，进港不等于报关完成。
-3. 海外尾程出库：海外仓库存经排车/PDA 作业离仓，出库单为 `OUTBOUNDED`。
+3. 海运起点：承运船舶真实开航后才进入海运节点，预计 ETD 不推进海运中。
+4. 海外尾程出库：海外仓库存经排车/PDA 作业离仓，出库单为 `OUTBOUNDED`。
 
 ### 1.1 操作与交接总表
 
@@ -63,10 +65,10 @@
 | 8 | 国内履约运营 / Admin | 创建模拟柜，选择候选，人工/智能排柜 | 生成稳定柜次、预装计划、分配明细和容量占用 | 订舱/柜务运营 |
 | 9 | 订舱/柜务运营 / Admin | 建订舱草稿、补资料、放舱，关联柜次并录入真实柜号 | 冻结订舱和运输快照，建立订舱需求与柜次分配关系 | 国内履约运营 |
 | 10 | 国内履约运营 / Admin | 核对预装清单并确认 | 固化预装快照，生成或开放国内 PDA 任务 | 国内 PDA |
-| 11 | 国内 PDA | 扫箱/整托拣货，批量提交，拍四步照片和铅封，完成装柜 | 计划 `COMPLETED`、入库单 `LOADED`，发布最终实装事件 | 报关/出仓运营 |
+| 11 | 国内 PDA | 扫箱/整托拣货，批量提交，拍五类证据和锁码，完成装柜 | 计划 `COMPLETED`、入库单 `LOADED`，发布最终实装事件并启动报关/送港两条线 | 报关/送港运营 |
-| 12 | 报关运营 / Admin | 上传出口报关资料并完成报关 | 报关状态完成；系统自动尝试收敛国内出仓门禁 | 出仓运营/系统 |
+| 12 | 报关运营 / Admin、Client | `LOADED` 后收集客户资料、发报关行、上传回执、发客户确认；打回则重做，所有客户通过后提交整柜正式申报 | 每客户确认轮次可追溯；整柜正式申报后记录查验/放行，不把回执上传当成客户确认 | 报关运营/客户 |
-| 13 | 出仓运营 / Admin | 自动未收敛时，在柜次门禁面板点击“确认离仓” | 整柜进入已离仓事实，自动建船节点任务和 `DEPARTED_WAREHOUSE` | 船务/海外运营 |
+| 13 | 送港运营 / Admin | 独立安排拖车、离仓、送港和进港；容量不足记录甩柜/改配 | 写入 `DEPARTED_WAREHOUSE`、`PORT_RECEIVED` 或 `ROLLED_OVER`，不等待报关客户确认 | 船务/海外运营 |
-| 14 | 船务 / Admin、第三方 | 查看自动轨迹，缺失时按权限补录真实节点 | 实际节点单调推进；到 `PICKUP_READY` 后开放海外 PDA 候选 | 海外计划运营、海外 PDA |
+| 14 | 船务 / Admin、第三方 | 只在承运船舶真实开航后查看/补录船节点 | 写入 `VESSEL_DEPARTED` 并进入海运节点；到 `PICKUP_READY` 后开放海外 PDA 候选 | 海外计划运营、海外 PDA |
 | 15 | 海外计划运营 / Admin | 在尾程订单按柜预览阻断项并确认转换入仓计划 | `PENDING_ASSIGNMENT → INBOUND_PLANNED`；逐票建计划并生成/绑定托盘资源 | 海外 PDA |
 | 16 | 海外 PDA | 选柜锁定，拍车牌/封签/开柜照片，确认签收 | 建立柜级收货会话，冻结实际接柜仓和操作员 | 海外 PDA |
 | 17 | 海外 PDA | FBA 按 SKU+箱数收货，OVERSEAS 按箱唛逐箱收货，完成整柜 | 尾程进入 `INBOUND_COMPLETED`；生成库存余额、仓位、托盘、流水并回写国内 | 海外排车运营 |
@@ -239,43 +241,37 @@
 
 装柜证据：
 
-- 空仓、半仓、满仓、锁仓四步照片；
+- 空仓、半仓、满仓、锁仓、带锁码照五类证据和锁码文本；
-- 带有效铅封号的铅封证据；
 - 同类可追加，错误证据作废并保留审计，不硬删除历史。
 
 最终完成门禁：全部计划明细核平、五类有效证据齐全、铅封号存在且真实柜号已就绪。完成后装柜计划为 `COMPLETED`，来源入库单为 `LOADED`。
 
-### 6.3 出口报关与国内出仓
+### 6.3 报关线与送港线
 
-入口：Admin → 货柜管理 → 柜次详情/国内出仓。
+入口：Admin → 货柜管理 → 柜次详情；客户确认入口为 Client → 头程订单 → 报关资料。
 
-当前整柜出仓门禁：
+**报关线**按客户案例推进：
 
-| 门禁 | 要求 |
+1. `LOADED` 后通知报关行，按客户/入仓码收集资料并发送；
-|---|---|
+2. 授权人员上传报关行本轮回执，客户查看并确认；
-| 扣货 | 柜内入库单均未被扣货 |
+3. 客户打回时保存原因，重新上传/替换资料，重新发送报关行并生成新回执轮次；
-| 入库单 | 所有绑定入库单为 `LOADED` |
+4. 柜内所有客户均确认后，冻结整柜资料并提交报关行正式申报；
-| 装柜计划 | `COMPLETED` |
+5. 记录查验、不查验放行、补件/退回等海关结果。
-| 国内 PDA | 拣货任务 `COMPLETED` |
-| 订舱 | 已放舱并分配当前柜次，状态 `RELEASED` |
-| 装柜证据 | 四步照片和有效铅封齐全 |
-| 出口报关 | 整柜报关 `COMPLETED` |
 
-拖车状态和独立船期当前只作为参考，不属于服务端硬门禁。出口报关完成后，系统会在全部门禁满足时自动尝试确认离仓；若未自动收敛，平台可在“国内出仓门禁”面板点击“确认离仓”。
+**送港线**独立推进：
 
-成功结果：
+1. 校验 `LOADED`、真实柜号、订舱和拖车条件，安排车辆离仓、送港和进港；
+2. 写入唯一 `DEPARTED_WAREHOUSE` 和 `PORT_RECEIVED` 事实；
+3. 船舱不足时写入 `ROLLED_OVER`，保存原船次、改配船次、滚动次数和客户通知；
+4. 送港线不等待客户报关确认，报关线也不等待送港完成。
 
-- 整柜出仓状态进入 `WAITING_FOR_LOADING`（现有内部编码，业务含义是已确认离开国内仓）；
+只有承运船舶真实开航才写入 `VESSEL_DEPARTED` 并进入海运节点。预计 ETD、已离仓或已进港不能显示为海运中。
-- 只写一次整柜离仓历史；
-- 自动创建唯一船节点查询任务和第一条实际 `DEPARTED_WAREHOUSE`；
-- 尝试完成同订舱关联的国内拖车单；
-- 已产生实际离仓节点后不得撤销。
 
 ## 7. 阶段四：海运节点、跨区尾程建单和海外入仓
 
 ### 7.1 船节点推进
 
-船节点任务由国内出仓自动创建，不能由操作员另造一套。标准实际节点按以下顺序单调推进：
+船节点任务在承运船舶真实开航后幂等创建，不能由操作员另造一套。标准实际节点按以下顺序单调推进：
 
 `DEPARTED_WAREHOUSE → AT_ORIGIN_PORT → LOADED_ON_VESSEL → DEPARTED_ORIGIN_PORT → IN_TRANSIT → ARRIVED_DESTINATION_PORT → DISCHARGED_FROM_VESSEL → PICKUP_READY → PICKED_UP → EMPTY_RETURNED`
 
@@ -481,8 +477,8 @@ OVERSEAS：
 
 1. 费用不再阻断待分柜。旧测量文档把“发送费用给客户”写成入库成功节点；当前 Firstleg 口径是测量审核通过后直接进入 `WAIT_SPLIT`，费用独立版本化。
 2. 跨区事件不自动建海外入仓计划。旧海外验收手册曾写“装柜完成事件直接生成入仓计划”；当前只生成 `PENDING_ASSIGNMENT` 尾程订单，平台必须按柜预览并确认转换。
-3. 国内出仓硬门禁不含拖车和独立船期。当前服务端硬门禁是未扣货、入库单 `LOADED`、装柜计划/PDA完成、订舱 `RELEASED`、装柜证据与出口报关完成；拖车和独立船期仅展示参考。
+3. `LOADED` 只校验物理装柜。报关线按客户回执确认、整柜正式申报和海关结果推进；送港线按拖车、离仓、进港和甩柜推进，两条线互不替代。
-4. 国内出仓既有自动收敛也保留人工入口。出口报关完成后系统会自动尝试确认；未收敛时平台可在柜次或国内出仓页手工确认，二者共享同一服务端门禁与幂等结果。
+4. 只有实际开船才进入海运节点。`DEPARTED_WAREHOUSE` 和 `PORT_RECEIVED` 是送港事实，`ROLLED_OVER` 是船次异常，预计 ETD 不推进海运中。
 5. 真实柜号最迟时点存在历史指引差异。当前代码允许在 `EDITING/LOADING` 补录，但最终 PDA 完成前必须存在；为避免页面入口差异，正式操作统一要求预装确认前补齐。
 6. 尾程主状态与子单状态分开。入仓后主流程固定在 `INBOUND_COMPLETED`，排车、出库、派送、换标和转运的精确状态保存在子单，不得互相覆盖。
 
@@ -510,7 +506,10 @@ OVERSEAS：
 - [ ] 模拟柜、订舱、真实柜号、预装计划和订单分配关系一致
 - [ ] 国内 PDA 全部拣货，五类证据和铅封齐全
 - [ ] 装柜计划 `COMPLETED`，来源入库单 `LOADED`
-- [ ] 整柜出口报关完成，国内出仓成功并生成船节点任务
+- [ ] 每个客户完成“资料→报关行回执→客户确认”，打回客户已重新上传、重新发送并生成新回执
+- [ ] 所有客户确认后，整柜资料已提交报关行正式申报，并记录查验/放行结果
+- [ ] 送港线已记录 `DEPARTED_WAREHOUSE`、`PORT_RECEIVED` 或 `ROLLED_OVER`
+- [ ] 承运船舶实际开航后才生成 `VESSEL_DEPARTED` 和船节点任务
 - [ ] 实际船节点到 `PICKUP_READY` 后海外 PDA 才看到柜号
 - [ ] 海外只先生成 `PENDING_ASSIGNMENT` 尾程订单，平台按柜转换计划成功
 - [ ] 海外 PDA 三类签收照片齐全，FBA/OVERSEAS 按正确模式实收
@@ -526,7 +525,7 @@ OVERSEAS：
 - `docs/业务快速索引.md`
 - `docs/订单与客户/订单与客户头程订单闭环设计.md`
 - `docs/入库测量与计费/入库测量与计费需求优化版-v2-测量计费入库主流程.md`
-- `docs/国内货柜履约/货柜管理全链验收矩阵-2026-08-13.md`
+- `docs/国内货柜履约/归档/货柜管理全链验收矩阵-2026-08-13.md`
 - `docs/海外仓业务/README.md`
 - `docs/海外仓业务/虫虫出海全流程人工验收手册.md`
 - `baiyue-firstleg/order/AGENTS.md`
@@ -536,3 +535,4 @@ OVERSEAS：
 - `apps/pda-overseas-uniapp/AGENTS.md`
 
 本文用于统一业务操作和评审口径；接口字段、权限码、并发版本和错误码仍以对应 Controller、DTO、OpenAPI 与服务端状态机为最终依据。
+

归档/头程到尾程/头程下单到尾程出库流程易用性与数据流转优化方案.md

@@ -461,3 +461,4 @@ P0 不改变核心状态机，主要是聚合查询、反馈和导航，风险
 5. 国内/海外 PDA 接入稳定错误原因、恢复动作和操作回执。
 6. 完成 P0 人工验收和埋点基线后，再做表单向导、自动带出和批量体验。
 7. 最后基于真实操作数据决定 P2 的智能推荐和 SLA 预警，不凭主观增加自动化。
+

归档/头程到尾程/头程下单到尾程出库现状流程全景清单.md

@@ -1,5 +1,7 @@
 # 头程下单到尾程出库现状流程全景清单
 
+> **历史现状声明（2026-09-24）**：本文记录旧版 AS-IS 盘点，报关/送港的单线门禁、柜前资料和“四步证据”等内容不再作为当前业务依据。当前流程以 [头程到尾程流程节点梳理（重构版）](../../头程到尾程流程节点梳理.md)、[报关资料与船期价格接入梳理](../../国内货柜履约/报关资料与船期价格接入梳理.md) 和最新需求确认表为准：`LOADED` 后报关线与送港线并行，客户回执确认完成后整柜正式申报，甩柜独立记录，实际开船才进入海运节点。
+
 > 文档性质：现状流程盘点（AS-IS），先描述现在业务怎么走，不在本文讨论页面改版或技术优化。  
 > 覆盖起点：企业具备下单资格。  
 > 主链终点：海外仓完成尾程出库；为保证交接完整，附带记录派送、异常退回和国内最终完成回写。  
@@ -568,7 +570,7 @@ INBOUND_COMPLETED
 - `docs/入库测量与计费/README.md`
 - `docs/入库测量与计费/入库测量与计费需求优化版-v2-测量计费入库主流程.md`
 - `docs/国内货柜履约/README.md`
-- `docs/国内货柜履约/货柜管理全链验收矩阵-2026-08-13.md`
+- `docs/国内货柜履约/归档/货柜管理全链验收矩阵-2026-08-13.md`
 - `docs/海外仓业务/README.md`
 - `docs/海外仓业务/虫虫出海全流程人工验收手册.md`
 - `baiyue-firstleg/order/AGENTS.md`
@@ -579,3 +581,4 @@ INBOUND_COMPLETED
 - `apps/client-web/AGENTS.md`
 - `apps/pda-uniapp/AGENTS.md`
 - `apps/pda-overseas-uniapp/AGENTS.md`
+

归档/头程到尾程/头程到尾程AI流程优化上下文包.md

@@ -1,5 +1,7 @@
 # 头程到尾程 AI 流程优化上下文包
 
+> **规则基线声明（2026-09-24）**：本文中的旧状态表和阶段合同可能保留历史口径，不能覆盖当前流程。当前分析必须先采用 [头程到尾程流程节点梳理（重构版）](../../头程到尾程流程节点梳理.md) 和 [报关资料与船期价格接入梳理](../../国内货柜履约/报关资料与船期价格接入梳理.md)：`LOADED` 后报关线、送港线并行，客户逐轮确认后整柜正式申报，送港可甩柜，实际开船后才进入海运节点。
+
 > 用途：给 AI、产品、业务和技术提供同一份优化输入规范。本文不替代六阶段现状文档，也不直接改变状态机；它定义分析顺序、术语、证据、指标、输出格式和实施门禁，防止 AI 只根据局部页面提出脱离业务事实的建议。
 
 ## 1. 第二轮完整性审计结论
@@ -34,7 +36,7 @@
 
 优化分析的默认入口：
 
-- 总览：[分阶段流程目录](头程到尾程分阶段流程/README.md)
+- 总览：[分阶段流程目录](../../头程到尾程分阶段流程/README.md)
 - 操作：[全流程操作手册](头程下单到尾程出库全流程操作手册.md)
 - 现状：[现状流程全景清单](头程下单到尾程出库现状流程全景清单.md)
 - 方案：[易用性与数据流转优化方案](头程下单到尾程出库流程易用性与数据流转优化方案.md)
@@ -294,3 +296,4 @@ AI 应优先：复用服务端权威动作与门禁、减少重复输入、显
 10. 国内离仓、海外入仓、海外出库和最终签收的客户可见进度语义。
 
 每项决定应记录：结论、负责人、确认日期、影响阶段、是否改变接口/状态/权限，以及需要更新的文档。未决定项保持“待确认”，不能由 AI 默认选择。
+

数据库版本迁移与Jenkins自动发布方案.md

@@ -182,7 +182,7 @@ baiyue-firstleg/
 
 ## 6. 自动编号和文件命名
 
-SQL 迁移使用每个 schema 内递增的整数序号，由创建工具生成。业务版本、Git commit 和 Jenkins 构建号只用于发布追踪，不参与 SQL 序号计算。无需开发人工决定“这次是 0.0.10 还是 0.0.11”。
+2026-09-22 确认：SQL 迁移保持 `V1、V2、V3、V4、V5……`，每个 schema 独立递增，由创建工具生成，不采用时间戳编号。序号随变更自然增长，不因位数增加而重置、归零或重新编号。生产发布版本、Git commit 和 Jenkins 构建号只用于发布追踪，不参与 SQL 序号计算。
 
 ```text
 migrations/cn/baiyue_order/V1__add_order_reference.sql
@@ -225,6 +225,24 @@ migrations/cn/baiyue_auth/V1__create_login_audit_table.sql
 - 同一库内按完整版本链推进，不按某个服务或某个文件跳过中间版本。该库随包包含的其他待执行变更必须一并评审；尚不具备发布条件时阻断本候选，不通过删文件、临时降低目标或开启乱序绕过。
 - 例如只发布 Auth，且与 Firstleg 无依赖，则只核验并迁移 Auth 的必要库。同一提交中 Firstleg 的待执行 SQL 不被带入；若 Auth 确实依赖 Firstleg 的新结构，则先补齐发布范围和测试证据再发布。
 
+### 6.3 功能分支与生产发布编号
+
+以下为确认的发布工作流；跨分支检查和发布编号自动分配尚待流水线实现，不代表当前工具已经提供这些门禁。
+
+| 记录 | 示例 | 增长规则 |
+|---|---|---|
+| 单库 SQL 迁移编号 | Auth 的 `V1`、`V2`；Order 的 `V1`、`V2` | 该库新增数据库逻辑变更时自动生成；普通提交、重复构建和重复部署不增加 |
+| 生产发布版本 | `release-1`、`release-2` | Jenkins 为新的生产发布候选自动分配，不要求开发手工维护版本文件；只有发布成功才更新当前生产版本 |
+
+生产发布版本与 SQL 编号不绑定。例如 `release-12` 可以对应 Auth `V3`、Order `V7`；纯代码发布仍有新发布版本，但数据库目标不变。发布编号须在受保护记录中唯一分配，失败编号不回收；同一制品重试沿用原发布编号，修改代码、SQL 或其他制品内容后分配新编号并重新验证。`release-13` 失败时保留失败记录，当前生产版本仍为最近成功版本；各库和服务的实际状态另行记录，不能据此假定没有发生部分更新。
+
+1. 功能分支从最新 `main` 创建，代码与 SQL 在同一分支维护；这里约定后续团队流程，不自动创建或切换本次工作区分支。
+2. 进入共享测试前，拉取并合并最新 `main`，检查同库重复编号和执行顺序。冲突只调整尚未冻结、未在保留历史环境执行的草稿；成功文件不改内容、不改编号，修复使用新增迁移。冻结失败候选只能按第 13.2.1 节处理。
+3. 两人可以并行开发；共享测试同一时间只验收一个待合并功能。前一功能测试通过、合并并完成发布或处理失败后，下一功能同步最新 `main` 再进入测试，避免未合并 SQL 污染其他功能的验证起点。
+4. 测试结果绑定提交和 SQL 哈希；合并前重新检查 `main` 是否变化，变化时同步并重新验证，不能仅凭“以前拉取过 main”放行。
+5. 合并后的 `main` 构建正式候选并再次自动验证；生产使用该正式候选原制品。功能分支测试证据不自动等同于合并后候选证据；已成功的 SQL 保持原编号及内容，由数据库历史决定跳过或执行。
+6. 发布记录绑定 `release-N`、`main` 的完整提交、镜像 digest、SQL 清单及各库版本，并保存成功发布的 Git 标签。`main` 表示已合并代码，实际生产版本以成功发布记录为准，不通过分支名称推断数据库历史。
+
 ## 7. 迁移类型
 
 ### 7.1 版本迁移
@@ -581,7 +599,7 @@ MySQL DDL 可能已隐式提交，不能假定整个文件自动回滚。按以
 - Jenkins 构建号。
 - Git commit 和镜像标签。
 - 发布身份、清单/SQL 包 SHA-256、各镜像 digest、审批及发布锁状态。
-- 候选制品身份、可选的业务发布标签，以及对应测试通过记录；不维护独立手工 SQL 发布版本。
+- 候选制品身份、生产发布版本 `release-N`、发布状态及对应测试通过记录；不维护独立手工 SQL 发布版本，编号规则见第 6.3 节。
 - 环境与区域。
 - schema 名称。
 - Flyway 镜像版本。
@@ -651,6 +669,7 @@ MySQL DDL 可能已隐式提交，不能假定整个文件自动回滚。按以
 - 实现 `plan/run` 及分阶段校验配置，在获授权的隔离数据库验证原始 SQL、首次执行、重复执行、结构断言与失败恢复；验证单服务范围隔离，并用应用预期结构及实际读写测试发现漏写迁移。
 - 单服务 Job 先支持构建与部署解耦；总控固定为“全部目标镜像就绪 -> SQL 阶段 -> 同批镜像部署”，此能力必须先于共享测试接入完成。
 - 全部独立部署入口纳入环境锁和候选资格校验，补齐归档保护、镜像保留、未决状态及撤销记录；禁止旧 Job 绕过新的 SQL 门禁。
+- 接入第 6.3 节的 main 同步检查、分支编号冲突检查和合并后候选验证；自动分配并保护 `release-N`，同一候选重试不换号，成功后更新生产版本和发布标签。
 - 对从未成功、未进入生产的失败候选验证第 13.2.1 节修订链；对已成功或生产尝试过的文件验证例外被拒绝。
 
 ### 阶段 D：共享测试完整演练

测试环境Jenkins部署指南.md

@@ -1,159 +1,53 @@
-# 开发/测试环境 Jenkins API 自动部署指南
+# TEST 环境 Jenkins 部署指南
 
-> 最后核对：2026-08-25
+更新日期：2026-09-29。本指南描述唯一 TEST 单机目标；仓库配置已收敛不表示实际服务器已部署。统一架构切换与验收以[测试环境单机部署与配置契约](测试环境单机部署与配置契约.md)为准。
->
-> 只适用于当前开发、测试阶段。生产环境启用后必须重新收紧权限、轮换并移除开发 Token。
 
-## 1. 使用场景
+## 授权与边界
 
-本指南用于长时间全量测试或夜间任务。用户在当前对话明确要求“持续修复并部署”“自动部署并测试”或等价表述后，工具可以在本次授权范围内循环执行：
+默认只做本地修改与离线检查。实际Jenkins构建发布、Nacos发布、SQL和清理分别落实本轮授权范围；本指南不授予持续部署权限。不得读取或覆盖其他任务维护的真实生产/测试凭据。运行事实与本目标不一致时先核对，不自行改名或删除运行环境。
 
-`定位失败 → 修改代码 → 本地门禁 → 提交并推送 → API 部署 → 等待终态 → 健康/业务验收 → 继续修复`
+## 唯一发布入口
 
-同一轮任务不需要每次提交或重试都重新询问。以下情况仍必须停下确认：
+| 对象 | 入口 |
-
-- 涉及预发布或生产环境。
-- 需要执行 SQL、初始化数据库、修改真实数据或清理容器/数据。
-- 需要跳过测试、停止他人构建或扩大到未授权服务。
-- 缺少环境凭据，或连续三次遇到同一个外部阻断。
-
-## 2. 本机一次性配置
-
-Jenkins API 信息固定保存在以下未提交文件：
-
-`C:/Users/BY-OY/.codex/jenkins-api.env`
-
-文件格式：
-
-```dotenv
-JENKINS_URL=https://jenkins.example.com
-JENKINS_USER=admin
-JENKINS_API_TOKEN=replace-with-current-development-token
-DEV_GATEWAY_URL=https://dev-api.example.com
-TEST_GATEWAY_URL=https://test-api.example.com
-```
-
-工具直接读取该文件，不把 Token 输出到 commentary、最终回复、命令日志或仓库。使用 API Token 的 Jenkins 请求不需要 CSRF Crumb。
-
-连通性检查：
-
-```bash
-curl -fsS --user "$JENKINS_USER:$JENKINS_API_TOKEN" \
-  "${JENKINS_URL%/}/api/json?tree=nodeName,mode"
-```
-
-## 3. Job 对照
-
-| 环境 | 后端总控 | Admin | Client | 后端分支 | 下游前缀 |
-|---|---|---|---|---|---|
-| 开发 | `backend-java-dev` | `admin-web-dev` | `client-web-dev` | `dev` | `baiyue-firstleg-dev-` |
-| 测试 | `backend-java` | `admin-web-test` | `client-web-test` | `test` | `baiyue-firstleg-` |
-
-后端可部署服务：
-
-`gateway`、`gateway-overseas`、`auth`、`iam`、`firstleg`、`finance`、`order`、`warehouse`、`file`、`print`、`integration-service`、`lastleg-service`、`warehouse-overseas-service`、`event-bridge-service`、`audit-service`。海外安全投影随 `lastleg-service` 部署，不再有独立 Job。
-
-正常从总控 Job 发起。只有重跑同一提交的单个失败服务时，才直接触发下游 Job。
-
-## 4. API 触发
-
-### 4.1 前端
-
-```bash
-curl -fsS -X POST \
-  --user "$JENKINS_USER:$JENKINS_API_TOKEN" \
-  -D build.headers -o /dev/null \
-  "${JENKINS_URL%/}/job/admin-web-dev/build"
-```
-
-按目标环境和应用替换 Job 名称。
-
-### 4.2 后端
-
-开发环境选择两个服务的示例：
-
-```bash
-curl -fsS -X POST \
-  --user "$JENKINS_USER:$JENKINS_API_TOKEN" \
-  -D build.headers -o /dev/null \
-  --data-urlencode 'BUILD_MODE=SELECT' \
-  --data-urlencode 'SERVICE_GATEWAY_OVERSEAS=true' \
-  --data-urlencode 'SERVICE_LASTLEG=true' \
-  --data-urlencode 'ENVIRONMENT=development' \
-  --data-urlencode 'DEPLOY=true' \
-  --data-urlencode 'SKIP_TESTS=false' \
-  --data-urlencode 'EVENT_BRIDGE_REGION=BOTH' \
-  --data-urlencode 'DOWNSTREAM_JOB_PREFIX=baiyue-firstleg-dev-' \
-  "${JENKINS_URL%/}/job/backend-java-dev/buildWithParameters"
-```
-
-规则：
-
-- 日常优先 `AUTO`；明确修复单个或少量服务时使用 `SELECT`。
-- `SELECT` 只把目标 `SERVICE_*` 设为 `true`，其余保持 `false`。
-- `ALL` 只用于用户明确授权的全量部署。
-- 开发环境固定 `ENVIRONMENT=development`；测试固定 `ENVIRONMENT=test`。
-- 开发/测试默认 `DEPLOY=true`、`SKIP_TESTS=false`。
-- 事件桥默认 `BOTH`；单区故障重跑才使用 `CN` 或 `OVERSEAS`。
-- 不在 API 参数中传密码、数据库凭据或服务 Token。
-
-## 5. 自动等待终态
-
-触发响应的 `Location` 是队列地址：
-
-```bash
-QUEUE_URL="$(awk 'BEGIN{IGNORECASE=1} /^Location:/{gsub("\r",""); print $2}' build.headers)"
-curl -fsS --user "$JENKINS_USER:$JENKINS_API_TOKEN" \
-  "${QUEUE_URL%/}/api/json?tree=id,why,cancelled,executable[number,url]"
-```
-
-出现 `executable.url` 后，将其作为 `BUILD_URL`：
-
-```bash
-curl -fsS --user "$JENKINS_USER:$JENKINS_API_TOKEN" \
-  "${BUILD_URL%/}/api/json?tree=number,building,result,url,duration,estimatedDuration"
-```
-
-每 5–10 秒轮询一次。只有 `building=false` 且 `result=SUCCESS` 才成功；进入队列、拿到构建号或 HTTP POST 成功都不算完成。后端总控还必须确认每个下游 Job 都是 `SUCCESS`。
-
-失败时读取：
-
-```bash
-curl -fsS --user "$JENKINS_USER:$JENKINS_API_TOKEN" \
-  "${BUILD_URL%/}/consoleText"
-```
-
-删除本次产生的临时 `*.headers` 文件，不提交。
-
-## 6. 夜间自动闭环
-
-1. 记录目标环境、服务和远端 commit。
-2. 运行直接受影响的本地测试；签名变化必须编译测试源码。
-3. 只提交当前修复文件并推送目标分支。
-4. 用 API 触发对应 Job，保存队列 URL、构建 URL 和构建号。
-5. 等待总控及全部下游进入终态。
-6. 失败时读取第一个有效错误，修改后使用新 commit 再部署。
-7. 网络抖动、镜像拉取等瞬时基础设施错误允许同一提交重试，最多两次。
-8. 部署成功后检查 Gateway `/actuator/health`，再执行本轮真实 API/全量测试。
-9. 全部通过后汇总 commit、构建号、服务结果和验收结果。
-
-不要因为某个服务失败就盲目重跑全量；优先修复并只重跑失败服务。部署脚本会在新容器不健康时自动回滚，任务仍视为失败。
-
-## 7. 快速故障判断
-
-| 现象 | 处理 |
 |---|---|
-| `401` | 检查本机 API Token 和反向代理 `Authorization` 头 |
+| 后端总控 | `backend-java`，仓库 `baiyue-firstleg/Jenkinsfile` |
-| `403` | 检查 Job Read/Build 权限；不要关闭 CSRF |
+| 后端单服务 | `baiyue-firstleg-<module>`，`Jenkinsfile.service` |
-| `400` | 参数名或 Choice 值与当前 Job 不一致 |
+| 构建/部署节点 | `java-builder` / 同机 `java-test` |
-| 队列长期等待 | 查询队列 `why`，检查节点、执行器和部署锁 |
+| 环境凭据 | Jenkins Secret File `firstleg-test-env`，真实值不入库 |
-| Maven/测试失败 | 修复代码并产生新 commit，不跳过测试 |
+| 服务与镜像列表 | [service-map.yml](../baiyue-firstleg/deploy/service-map.yml) |
-| 容器不健康 | 读取 Job 自动采集的容器日志和回滚结果 |
+| Compose | [docker-compose.yml](../baiyue-firstleg/deploy/docker-compose.yml)，项目 `firstleg-test` |
-| 镜像被其他任务覆盖 | 核对同服务部署锁和实际运行镜像标签 |
+| 环境模板 | [.env.test.example](../baiyue-firstleg/deploy/env/.env.test.example) |
-| 总控成功但下游失败 | 整体仍按失败处理，只重跑失败服务 |
+| Nacos | [config/nacos/test](../baiyue-firstleg/config/nacos/test/README.md)，14个Data ID、一个实际Namespace ID |
+| 执行顺序与恢复 | [TEST单机部署执行清单](../baiyue-firstleg/deploy/TEST单机部署执行清单.md) |
 
-## 8. 完成记录
+保留13个服务：gateway、auth、iam、order、firstleg、finance、warehouse、warehouse-overseas-service、lastleg-service、file、print、audit-service、integration-service。Gateway Overseas、两区Event Bridge不在新发布清单。停旧服务必须等统一认证、直接投递、撤销和四端切换验证完成；源码退役不等于获准停止当前服务。
 
-最终只需记录：环境、Job、服务、分支、commit、Jenkins 构建号、最终结果、健康检查、业务验收及剩余阻断。不得输出 Token、Cookie、Jenkins Credential 或环境文件内容。
+旧开发/生产Job不再匹配当前流水线，不能借环境参数使本版本执行生产部署。已有其他环境应由其独立明确授权任务处理，不在本次TEST发布中操作。
 
-参考：[Jenkins Remote Access API](https://www.jenkins.io/doc/book/using/remote-access-api/)、[Jenkins CSRF Protection](https://www.jenkins.io/doc/book/security/csrf-protection/)。
+## 参数与门禁
+
+总控支持AUTO、SELECT、ALL。AUTO保留失败服务重试与直接依赖识别；架构首次切换使用审核后的完整匹配发布清单，不以AUTO遗漏服务。ENVIRONMENT仅test，下游前缀仅baiyue-firstleg-。DEPLOY默认false；IMAGE_REPOSITORY首次在各Job参数默认值中配置已核镜像仓库，后续流水线沿用当前Job参数值，不在每次构建后重置为空；总控仍明确向下游传递本次地址。更换仓库才需修改，空值、示例域名与格式校验仍保留，不在源码固定环境地址。DOCKER_BASE_IMAGE由构建节点可访问的Java17镜像提供。不得将凭据拼入参数、URL或日志。
+
+默认执行Maven测试；仅明确选择SKIP_TESTS时跳过执行，仍编译测试源码。总控先统一测试，再向固定commit的单服务任务传递跳过重复执行。发布前还须完成网关路由、部署拓扑、失败回滚和受影响前端合同。离线检查不能证明镜像健康或HTTP闭环。
+
+总控 `TEST_SCOPE=AUTO` 在单个 Lastleg 的可追踪局部 Java 变更中，按反向类型引用、接口实现、测试夹具和变更写入 SQL 的同表消费者选择测试；公开契约变更追加相关静态合同。基线仅取带有新门禁通过标记、确实测试了目标服务的成功构建；跳过测试、失败、取消或仅测过其他服务的构建均不能作基线。公共模块、共享模型、配置、Schema、未知路径、多服务、其他服务或基线不可用时保持完整模块测试；`TEST_SCOPE=MODULE` 可显式执行完整回归，临时灰度始终保持 MODULE。完整生产和测试源码编译及既有 1GB/单 fork/类隔离不变。定向测试必须逐类取得本轮非零执行报告；真实环境 opt-in 类单独列为未执行，不计为通过，仍由完整模块/专项授权入口负责。此静态筛选不能发现所有运行时耦合，涉及未被 Java/SQL 引用表达的跨业务影响时须选 MODULE。首次发布本次流水线变更需先执行完整模块测试建立新基线。流水线/发布脚本变化仍命中既有 AUTO 全服务规则，首次可使用 SELECT 仅选 Lastleg、TEST_SCOPE=MODULE 建立基线；后续 AUTO 才按关联范围执行。精确耗时以部署后 Jenkins 为准。
+
+同机测试代理的执行器数量固定为1，避免构建与其他重任务挤占业务服务。总控测试和单服务打包还必须共用 `firstleg-test-maven` 跨Job锁，经 `deploy/scripts/run-ci-maven.sh` 执行；仅 `disableConcurrentBuilds()` 不能限制不同Job并发。入口按同一构建账号使用本机flock，控制端掉线后已有任务仍持锁时拒绝再起Maven，不删除锁文件绕过互斥。部署的SOURCE_COMMIT必须包含此入口及 `ci-bounded` POM配置，旧提交缺少防护时应失败，不能回退到裸mvn。
+
+当前初始预算：Maven堆768MiB、测试堆1GiB、单测试fork，并分别限制元空间和直接内存；Surefire保留JaCoCo，启用父进程心跳检查、停止时kill、fork运行20分钟和退出30秒上限。宿主机GNU timeout提供45分钟期限及30秒强制终止，Jenkins内部另设50分钟上限。预算不是总RSS保证，须在真实Linux节点核对代理内存、memory.events/pressure和完整服务测试峰值；不足时按证据调整，不能重新放开三个Maven并发，也不能仅提高MemoryHigh挤占业务服务。代理服务保持 `KillMode=control-group`、`SendSIGKILL=yes`；代理掉线或构建中止后，先检查该服务cgroup是否仍有构建/测试子进程，确认退出再恢复，不把Job的ABORTED当作进程已清理。
+
+单服务任务在取目标节点执行器前锁定对应服务，目标节点通过同一env文件拉镜像并更新容器。没有HEALTHCHECK、启动失败、不健康、退出或超时均判失败。只有同协议同Schema版本才可显式启用ALLOW_SAME_CONTRACT_ROLLBACK；架构切换保持false，恢复原则见执行清单。
+
+## 配置与端侧
+
+容器共用firstleg-test-network；同网络Web Nginx使用http://gateway:9000。Gateway宿主机发布仅127.0.0.1，业务服务只内部expose。Auth使用http://auth:9100，不能把Nacos应用名当Docker DNS。宿主机中间件通过host.docker.internal访问，不能使用容器localhost。
+
+所有服务使用同一Nacos Namespace ID/Group、Redis DB与会话前缀。Auth独占签名私钥；JWKS和内部会话验证共用Auth。EVENT_OPERATIONS_TOKEN独立于内部业务令牌，留空禁用运维操作。现有文件卷和非桥业务MQ保留，topic/group使用test-前缀。
+
+Admin与Client各自Compose项目共接后端网络，发布必须给出CLIENT_WEB_URL/VITE_ADMIN_WEB_ORIGIN；两个PDA保留独立产物及仓绑定，H5 直接上传宿主机 Nginx 站点，不纳入容器或 Jenkins 镜像发布；执行方式以[部署契约](测试环境单机部署与配置契约.md)的“PDA H5 发布方式”为准。域名、Namespace ID、MQ范围、数据卷和主机容量必须据实际清单核实，不能用模板默认值充当验收。
+
+## 发布与验收
+
+按执行清单记录镜像、配置、SQL与四端版本，在停写窗口发布完整匹配版本。SQL不由Compose/Jenkins自动运行，初始化脚本仅接受两份显式审核的空库基线并受授权开关保护。禁止整机清空Redis/MQ/文件。
+
+启动就绪后先验证统一登录/撤销/隔离/仓绑定、资源查询和文件，再用新造数据验证装柜至尾程、资金指令结果回传及故障恢复。真实API通过后还需页面/PDA验收。未部署、未验证项目必须明确标记；不能以Job成功替代整条业务链完成。

海外仓业务/README.md

@@ -1,100 +1,29 @@
-# 海外仓业务范围与快速索引
+# 海外仓业务文档入口
 
-## 已确认业务边界
+本文件只帮助选择正文，不定义字段、状态或部署进度。已定位页面、API 或服务时跳过本文件；代码从目标应用/服务最近 `AGENTS.md` 进入，业务依据只读下表命中的主题或条款。
 
-- 当前开发环境按端到端全流程交付，不再用开发批次切断上下游。订单与客户、入库测量与计费、国内货柜履约、海外仓业务和财务共同组成一条连续业务链。
+## 当前业务正文
-- 海外仓业务从国内装柜完成及确认出仓后的船节点开始，覆盖海运在途、海外接柜、卸货入仓、库存与托盘、换标、转运、废弃、退货、排车、PDA 拣货与出库、发车、转派送、派送完成、异常退回、客户回访和一件代发。
-- 海外采购、本土卡车、本土散板、海外仓报价、汇率和车辆主数据属于同一海外业务域，并统一经 `gateway-overseas/` 访问。
-- 功能是否可用以正式路由、Controller/OpenAPI、权限、数据库结构和验收证据为准；历史规划只用于追溯，不再用于排除已经纳入全流程的能力。
 
-## 人工验收入口
+| 任务 | 读取入口 |
+|---|---|
+| 尾程订单、入仓计划、接柜、库存与仓储资源 | [系统边界](业务规则.md#系统边界与索引维护)，按订单/计划/托盘等符号只读命中条款 |
+| 海外排车、出库与派送改造 | [排车现行契约](排车列表统一作业改造契约.md)；已有缺陷追溯才读[修复规划](排车流程修复规划.md) |
+| 外配车辆与承运 | [外配业务契约](外配业务首版开发契约.md) |
+| 预约工作日历、多客户共车、分批、改期取消 | [V13 业务规则](预约工作日历V13变更说明.md)；接口/文件归属问题才读[开发协作契约](预约工作日历开发协作契约.md) |
+| 船节点、查询频率、还柜与码头邮件 | [船节点契约](船节点标准化契约.md)；实现补充查[定时查询](业务规则.md#船节点定时查询边界)或[码头邮件](业务规则.md#码头车队邮件) |
+| 本土卡车与散板表单 | [统一表单](业务规则.md#本土卡车与散板统一前端下单)、[散板](业务规则.md#本土散板简化下单)、[美国本土卡](业务规则.md#美国本土卡独立下单)，按任务选一项 |
+| 采购样品、面单与寄送 | [采购样品流程](采购订单样品履约流程变更需求.md) |
+| 司机、证照、车队与拼车需求池 | [车辆业务范围](车辆管理原型梳理与任务规划.md)、[拼车业务契约](内部拼车需求池首版开发契约.md)，按具体业务选读 |
+| 自有业务 | [自有业务契约](自有业务首版开发契约.md)；接口细节查[接口设计](自有业务后端接口设计.md) |
 
-- 端到端人工验收统一使用[《虫虫出海全流程人工验收手册》](虫虫出海全流程人工验收手册.md)。手册覆盖客户与订单、国内履约、跨区事件、海外 PDA 入仓、库存与库内服务、排车出库、派送、异常退回、一件代发、海外主数据和海外业务，并区分页面、真机和自动化证据。
+专题契约描述确认目标，不表示代码、部署或真实验收已完成。只改唯一规则正文；入口或职责变化才同步本表。
 
-## 功能快速路由
+## 预约送仓
 
-| 业务域 | 能力范围 | 原型入口 |
+送仓预约的基础边界见[预约送仓正文](业务规则.md#预约送仓)；日历相关变更优先按上表定位 V13，不默认再读取总体优化方案和开发协作契约。
-|---|---|---|
-| 海外仓 | 尾程订单、入库单、换标单、托盘管理、库存管理；箱号管理与产品库当前暂不进入海外仓业务正式入口；Admin 入口 `../../apps/admin-web/src/modules/overseas-warehouse/` | 原型 `../悦/货代SAAS平台后台/prototype-src/modules/03-overseas-warehouse.html`；Backend `../../baiyue-firstleg/lastleg-service/`、`../../baiyue-firstleg/warehouse-overseas-service/`，经 `gateway-overseas/` |
-| 海外仓排车与智能预排 | 平台查看排车列表/详情，按入仓计划或已收托盘创建预排，并完成编辑、取消、拣货、出库、发车和转派送 | Admin `../../apps/admin-web/src/modules/overseas-warehouse/pages/DispatchesView.vue`、`api/dispatches.ts`；Backend `../../baiyue-firstleg/lastleg-service/src/main/java/com/baiyue/lastleg/dispatch/` |
-| 海外仓客户自助服务 | 客户工作台正式开放贴标申请、仓储转运、货物废弃和退货换标；所有查询和写入只使用登录态客户范围 | Client `../../apps/client-web/src/modules/overseas-warehouse/routes.ts`、`views/WarehouseServiceView.vue`、`api/warehouseServices.ts`；Backend `../../baiyue-firstleg/lastleg-service/` 的 `relabel/`、`transfer/`、`discard/`，经 `gateway-overseas/` |
-| 海外仓 PDA 柜号签收与退货入库 | 独立应用 `../../apps/pda-overseas-uniapp/`；拆柜收货完成柜号认领、三类照片、按目的类型实收与全柜完成；退货入库支持扫描退货单号或 SKU 候选并按本包实收生成退货箱和计费批次，签收后可按同客户退货单合箱 | 拆柜前端 `src/api/inbound.js`、`receiving-adapter.js`、`pages/operation/operation.vue`；退货前端 `src/api/return-receipt.js`、`src/api/return-packing.js`、`pages/return-receipt/return-receipt.vue`、`pages/return-packing/return-packing.vue`；Backend 分别为 `inboundplan/pda/` 与 `returnreceipt/controller/PdaReturnReceiptController.java`、`PdaReturnInventoryController.java`，经 `gateway-overseas/` |
-| 海外仓 PDA 库内、托盘、换标与查询 | Lastleg 提供盘点、同仓整托移库、托盘组拆换绑、换标和库存/库位/托盘查询能力；当前终端入口按工作台能力开关启用，未进入 PDA 的操作由 Admin/Client 正式页面承载 | Backend `../../baiyue-firstleg/lastleg-service/src/main/java/com/baiyue/lastleg/pda/stocktake/`、`pda/move/`、`pda/warehouse/`、`palletops/`、`relabel/pda/`；契约 `src/main/resources/openapi/overseas-pda-operations-v1.yaml` |
-| 海外仓出库与派送 | 排车编辑/取消、PDA 排车拣货、出库任务、发车门禁、转派送、客户派送单和派送完成 | Admin `../../apps/admin-web/src/modules/overseas-warehouse/`；Overseas PDA `../../apps/pda-overseas-uniapp/src/pages/dispatch/`、`src/pages/outbound/`；Backend `../../baiyue-firstleg/lastleg-service/src/main/java/com/baiyue/lastleg/dispatch/`、`delivery/` |
-| 异常退回与客户回访 | 异常建档、派送退回入仓、派送状态、签收/回访附件和客户回访 | Admin `ExceptionOrdersView.vue`、`CustomerVisitsView.vue`；Backend `exceptionorder/`、`customervisit/` |
-| 一件代发 | 国内订单强制 SKU 快照、装柜工作托盘、海外 SKU/箱唛库存和一件代发出库 | Backend `order/`、`firstleg/`、`lastleg-service/dropship/`；跨区事件见 `common-event-contract/` |
-| 海外业务 | 本土散板、采购订单、本土卡车；Admin 入口 `../../apps/admin-web/src/modules/overseas-business/` | 原型 `../悦/货代SAAS平台后台/prototype-src/modules/07-overseas-business.html`；Backend `../../baiyue-firstleg/lastleg-service/` 的 `procurement/`、`trucking/` 及后续本土散板子域 |
-| 仓库主数据与海外资源 | 仓库 ID、类型、状态、地址、能力统一由国内仓库主数据维护；海外服务只维护库位、托盘和资源锁 | Admin `../../apps/admin-web/src/modules/warehouses/`；国内权威 `../../baiyue-firstleg/warehouse/`；海外资源 `../../baiyue-firstleg/warehouse-overseas-service/` |
-| 通用资料 | 海外仓报价、汇率管理、车辆列表；Admin 入口 `../../apps/admin-web/src/modules/overseas-master-data/` | `../悦/货代SAAS平台后台/prototype-src/modules/10-general.html` |
-| 国内出仓后船节点 | 对已确认离开国内仓库的订舱/柜次定时查询船节点，保存最新节点、异常和查询历史，贯通目的港提柜至还柜事实 | 标准语义见[船节点标准化契约](船节点标准化契约.md)；Admin `../../apps/admin-web/src/modules/port-schedules/`、`ocean-bookings/` 及货柜详情；Backend `../../baiyue-firstleg/firstleg/src/main/java/com/baiyue/firstleg/portschedule/`、`../../baiyue-firstleg/integration-service/` |
 
-## 原型页面定向索引
+## 原型与验收（按需）
 
-原型本地完整入口为 `../悦/货代SAAS平台后台/index.html`。页面任务优先读取下列命中模块和页面 ID，不先加载完整原型。
+- 页面还原按[页面 ID 索引](业务规则.md#原型页面定向索引)读取命中页面；不加载全部原型。
-
+- 用户明确要求全流程人工验收时查[人工验收手册](虫虫出海全流程人工验收手册.md)；普通修改按根指引选择最小验证。
-### 海外仓
+- [美国预约总体优化方案](美国预约管理统一总览与优化方案.md)、[PDA 改造评审](海外仓PDA拆柜收货改造方案评审稿.md)、后端缺口清单和原型核对属于专项设计/评审资料，不是普通开发的必读清单。
-
-- 尾程订单：`last-mile-orders`、`last-mile-order-detail`。
-- 入库单：`fba-inbound-order`、`fba-inbound-order-detail`；入库和退货入库相关库存视图按任务联查 `overseas-inbound`、`fba-return-inbound`。
-- 换标单：`fba-relabel-order`、`fba-relabel-order-detail`；换标库存视图按任务联查 `overseas-relabel`、`fba-return-relabel`。
-- 托盘管理：`fba-pallet`、`fba-pallet-detail`。
-- 箱号管理：`fba-carton`、`fba-carton-detail` 当前暂缓，不注册正式菜单和路由。
-- 产品库：`fba-product`、`fba-product-detail` 当前暂缓，不注册正式菜单和路由。
-- 库存管理：`fba-stock-management`、`overseas-location`、`inventory-overview`、`warehouse-stock`、`overseas-stock`、`warehouse-stock-detail`、`inventory-transactions`、`purchase-stock`、`purchase-stock-detail`、`fba-return-stock`。
-
-### 海外业务
-
-- 采购订单：`overseas-purchase`、`overseas-purchase-edit`、`overseas-purchase-detail`。
-- 本土卡车：`overseas-truck`、`overseas-truck-add`、`overseas-truck-edit`。
-- 本土散板：`overseas-looseboard`、`overseas-looseboard-add`、`overseas-looseboard-edit`。
-- `domestic-*` 和 `legacy-*` 页面不是海外仓业务默认入口；只有实际流程明确复用时才联查。
-
-### 仓库与通用资料
-
-- 海外仓合作仓：优先核对 `gen-partner-warehouse`，并同步核对现有平台仓库类型、接口和初始化 SQL。
-- 海外仓报价：`gen-overseas-quote`；涉及车队报价时再联查 `delivery-fleet-quote`。
-- 汇率管理：`gen-exchange-rate`。
-- 车辆列表与详情：`vehicle`、`vehicle-detail`。
-
-## 终端与模块边界
-
-- 海外仓出库、派送、异常退回和一件代发已经纳入全流程，不再作为海外入仓之后的独立开发批次。
-- 派送业务由 Admin/Client 承载，不进入海外 PDA；海外 PDA 负责现场入仓、托盘、排车拣货和出库等已注册作业。
-- 箱号和产品信息作为入仓、库存、箱唛及 SKU 快照的一部分使用；是否提供独立维护页面由正式路由决定，不影响全流程状态推进。
-- 高级 BI、开放平台和独立移动 APP 属于独立产品能力，不与现有业务全流程完成状态混为一谈。
-
-## 船节点定时查询边界
-
-- 所有供应商统一节点、时间语义、异常事实、停止规则和新增船司接入门禁以[船节点标准化契约](船节点标准化契约.md)为准；供应商缺失的节点保持缺失，不推测补齐。
-
-- 现有 `CarrierScheduleQuery` 查询任务及其查询尝试、历史、来源、过期标识和频率约束整体重新归入海外仓业务；不再把它列作国内货柜履约港务/船期查询能力，也不得另建一套重复任务。
-- 定时查询对象必须关联真实订舱、柜次以及可用的船司/船名航次或跟踪标识，不建立脱离业务单据的孤立轮询任务。
-- Firstleg `portschedule/` 负责任务编排、业务关联、最新节点、节点历史、幂等和停止条件；`integration-service/` 只负责船司或轨迹供应商适配、限流、超时、重试和错误归一化，不保存业务主数据。
-- 查询从确认柜子离开国内仓库后开始，贯通目的港到达、卸船、清关、提柜和还柜事实，默认在实际 `EMPTY_RETURNED` 后停止；这只扩展货柜轨迹事实，不纳入海外派送、海外仓出库或库存离仓业务。失败不能伪造成功节点，需保留来源、观测时间、最近成功时间和失败原因。
-- 现有“每 3 天一次、窗口最多 3 次”、六家船公司来源、最近有效结果和过期标识是同一查询能力的既有约束，归海外仓业务继续核对；后续若调整自动轮询频率、供应商额度、退避或停止规则，应只修改海外仓业务契约和这套任务。
-- 当前原型没有独立的“船节点定时查询”页面；涉及页面展示时从订舱、船期或货柜详情进入，不得为了匹配原型菜单把它归入海外派送。
-
-## 系统边界与索引维护
-
-- 托盘管理提供当前托盘单张标签 PDF：Admin `PalletsView.vue` → `warehouse-overseas-service` 的 `GET /api/platform/v1/warehouse-admin/{warehouseId}/pallets/{id}/label`。有 FBA 仓码的托盘与国内统一使用 Print `FBA_PALLET_A4_LANDSCAPE_V1`（297×210 mm）：顶部 SCK8 等仓码，中间 Code 128、底部完整托盘号，141 等内部编号保留在托盘号中；其他托盘使用 `INBOUND_MARK_V1`（100×100 mm）。只按真实托盘编码打印，不重新生成编号；模板约束、服务接入与权限见海外资源服务 `AGENTS.md`。
-
-- 海外仓合作仓是现有头程仓库主数据的类型扩展，需同步核对 Admin `warehouses`、Warehouse Service 的 DTO/Controller/OpenAPI/SQL 及实际消费者；不得因此把海外库存业务写入国内 Warehouse Service。
-- 海外库存、库内作业和海外本土业务已有明确服务入口：`gateway-overseas/` 是海外 API 网关，`lastleg-service/` 拥有尾程订单、入仓计划、换标、库存业务、采购和本土卡车；国内 `warehouse-service` 是仓库主数据唯一权威，`warehouse-overseas-service/` 只拥有库位、托盘及资源锁并引用国内 `warehouseId`。不得把海外库存业务塞入国内 `firstleg/` 或 `warehouse/`。
-- 国内装柜完成事件只在海外生成 `PENDING_ASSIGNMENT` 尾程订单、冻结快照和 `FIRST_LEG` 在途库存，不自动生成入仓计划。平台通过 `GET /api/platform/v1/last-leg/orders/container-summaries` 按稳定 `sourceContainerBookingId` 服务端聚合全柜订单、入仓码、计划数、未操作数和 `allPlansReady`，分页返回全部稳定来源柜，已生成计划的柜仍保留供接柜仓查询与修改；`pendingPlanCount` 区分待建计划，`resourcePendingPlanCount` 区分托盘资源待生成，后者仅用于自动生成异常后的重试；详情 `/{sourceContainerBookingId}` 返回柜内全部订单与计划且不受订单分页截断。`plannedArrivalAt` 只来自装柜完成事件 `estimatedWarehouseArrivalAt` 冻结到 Lastleg `ll_order.estimated_warehouse_at` 的计划到仓事实，不得使用创建时间、预计到港或当前时间替代，并按该时间升序、空值最后排序。确认后调用 `POST /api/platform/v1/last-leg/inbound-plans/convert-container`；服务端一次锁定整柜、每票独立生成一个计划，整批原子且幂等。转换成功才将尾程订单推进为 `INBOUND_PLANNED`，并把库存余额的来源入仓码展示快照替换为各自 `planNo`。
-- 尾程订单的 `inboundCode` 只保存并展示真实来源入仓码；换标申请、本土散板等没有入仓关系的海外本土业务保持为空，由页面显示 `—`，不得用换标单号、本土散板单号或内部 ID 冒充入仓码。
-- 平台可按单票尾程订单入库计划（托数、托盘类型、分配/可合托/加急和备注）；入库仓、入仓码和预计到仓时间均展示冻结事实，不允许人工改写。预计到仓日期由服务端锁定来源柜全部订单的 `estimated_warehouse_at`，缺失或同柜不一致时阻断，人工与自动计划统一写入该柜日期。写入时校验订单版本、客户归属、仓库主档和幂等键；一票柜保存后立即自动生成并绑定托盘码、海外仓托盘和资源锁，多票柜在最后一票计划齐全时自动为全柜完成同一动作。`resourcePendingPlanCount` 只用于自动生成失败后的显式重试，不是正常人工步骤。分配、可合托、加急必须随入库单列表和海外 PDA 入仓码作业返回并展示，其中“可合托”只向现场提供选择：合托时扫描同目的仓已使用的托盘码，独立收货时扫描新托盘码，不作为实收或完成门禁。新增暂扣只允许货物完成入库后执行；暂扣只作用于该票并仅阻断排车和出库，不阻断入库计划或入库作业，同柜其他订单不受影响。
-- 头程散货在预装确认且真实集装箱号就绪后，按 `集装箱号-FBA仓编码-三位序号` 冻结托盘码；序号在当前柜、当前 FBA 仓内从 001 独立递增。送柜报关、清关提柜和预装清单共用同一按 FBA 仓分组的打印清单，可整柜打印或选择单仓前 N 张补打。该编号随装柜完成事件进入海外，生成入库计划与海外实体托盘时原样沿用；一件代发继续使用国内装箱打托形成的托盘号，不参与散货重新编号。
-- 头程与海外仓允许装托密度不同。尾程最终托数取不低于头程已有托盘码数的海外计划结果：头程已有编码全部保留，数量不足时在同柜、同 FBA 内按连续下标补码，不因数量差异阻断。柜级预览必须分别返回并展示头程已有、海外仓补充和最终托数；最终总数不得标成“本次新增”。
-- 尾程订单人工节点固定为国内报关完成、预计/实际开船、预计到港、国外清关完成、实际到港等待卸船、预约提柜和卸柜八行完整快照。第一次保存后该订单永久使用 `MANUAL` 来源，读取和页面展示不得再回退柜级节点，也不得反向修改货柜船节点。
-- 目的港码头拖车仍归 Firstleg 货柜聚合，但 Admin 清关提柜列表不再使用预约/实际提柜作为到仓业务时间：原两列改为“预计到仓/实际到仓”。预计到仓在列表内人工选择并由 Lastleg 按 `sourceContainerBookingId` 原子同步整柜尾程订单，已有入库计划后锁定；实际到仓只取海外 PDA 首次开始收货的 `ll_receiving_container_session.receiving_at`。车队、邮件、还柜及 `unloadingCompletedAt + 72h` 还空预警仍按原码头拖车链路处理。
-- 手动还柜以真实海外卸柜完成且尚未还柜为准，仍校验独立还柜权限；无需事先存在车队、预约或提柜时间。首次命令使用版本 0 创建拖车记录，车队字段可为空，不补造提柜事实。还柜时间不得早于卸柜完成时间或已有提柜时间，成功后同步标准还柜节点并解除报空预警。
-- 船节点是头程海运在途事实与海外接柜之间的衔接能力，业务聚合继续由 Firstleg 按 `containerBookingId` 柜级持有，不绑定客户；跨区域事件使用 `tenantId=0` 平台技术范围，到港/可提柜结果通过明确契约提供给海外区域，不复制第二套轮询任务。
-- Admin、Client 仍使用统一账号体系，并按根 `AGENTS.md` 的双区域 API、海外 Token 和跨区域事件约定接入；业务页面不自行实现第二套登录。
-- 海外仓 PDA 使用独立 `apps/pda-overseas-uniapp/` 工程和发布身份，但账号仍由国内 Auth 唯一签发；真实作业请求必须经海外 Gateway 的显式 PDA 路由。工作台只展示已注册并启用的现场作业，其他业务通过 Admin/Client 完成，不以某个终端是否承载全部操作判断端到端流程是否完成。
-- 海外 PDA 的实际收货仓是国内 `warehouse-service` 中 `tenant_id=0`、类型为 `OVERSEAS`、状态 `ACTIVE` 且启用 `RECEIVING` 能力的平台共享物理仓，并由 `WAREHOUSE_PICKER` 的 Token Claim 固定；海外数据库只保存相同 `warehouseId` 引用。PDA 不接收仓库 ID，也不能切换柜号。海外 Gateway 对每个 `/api/pda/**` 请求在本地验签后向 Auth 实时核对账号 `token_version` 与当前仓绑定，换仓或清空绑定后旧 Token 立即失效，Auth 不可用时拒绝请求。待收柜在首次准备时原子认领到该仓，入仓计划、尾程订单和收货会话冻结实际仓 ID/名称；国内装柜事件的仓库仅作为来源仓快照，目的仓/FBA 仓也不得冒充实际收货仓。
-- 海外 PDA 接柜候选、认领会话、国内五类装柜照片对照、海外三类签收照片与整柜完成均按 `sourceContainerBookingId + containerNo` 聚合，不保存客户并允许同柜多个客户。国内照片在签收阶段展开、收货阶段折叠，只读加载失败不阻断拆柜。签收后为柜内每个计划按其自身客户生成任务；入仓码解析、SKU 实收、托盘占用和库存入账继续按该票真实客户隔离，整柜完成需全部计划核平且只发布一次柜级完成事件。
-- 新增实际代码模块、API、权限、OpenAPI 或数据库入口后，同步更新根 `AGENTS.md`、对应应用/服务 `AGENTS.md` 和本文件；不把排期、完成比例或临时任务状态写入快速索引。
-
-## 码头车队邮件
-
-首次选择车队后从清关提柜列表发送请求，更换车队时原子保存原车队取消和新车队提柜两封邮件；同一车队重复选择不发信。邮箱读取供应商资料，缺失或无效时阻断发送或换队。邮件顺序投递，失败待人工核对后重试。接口、临时模板和启用方式见 [Firstleg 车队邮件说明](../../baiyue-firstleg/firstleg/docs/terminal-drayage-mail.md)。

海外仓业务/业务规则.md

@@ -0,0 +1,173 @@
+# 海外仓业务规则与实现边界
+
+角色：业务规则正文，不是导航或部署进度。已知代码入口时直接沿模块指引工作；需要业务依据时，按索引链接或 `rg -n -F '符号或主题' docs/海外仓业务/业务规则.md` 读取命中标题/条款，不全文加载。
+
+专题正式契约优先：排车查《排车列表统一作业改造契约》，预约查《预约工作日历V13变更说明》，船节点查《船节点标准化契约》，纸张与标签查打印标签维护入口；下列实现约束不得覆盖这些当前主题规则。部署与验收状态只查工作区根指引指定的环境主契约。
+
+## 业务范围
+
+- 当前开发环境按端到端全流程交付，不再用开发批次切断上下游。订单与客户、入库测量与计费、国内货柜履约、海外仓业务和财务共同组成一条连续业务链。
+- 海外仓业务从国内装柜完成及确认出仓后的船节点开始，覆盖海运在途、海外接柜、卸货入仓、库存与托盘、换标、转运、废弃、退货、排车、PDA 拣货与出库、发车、转派送、派送完成、异常退回、客户回访和一件代发。
+- 海外采购、本土卡车、本土散板、海外仓报价、汇率和车辆主数据属于同一海外业务域，并统一经当前 `gateway/` 访问。
+- 功能是否可用以正式路由、Controller/OpenAPI、权限、数据库结构和验收证据为准；历史规划只用于追溯，不再用于排除已经纳入全流程的能力。
+
+## 预约送仓
+
+本轮变更行为以[预约工作日历 V13 变更说明](预约工作日历V13变更说明.md)为主入口。下述接口用于定位既有业务归属；涉及整票占用、分批、取消及重约的实现须按 V13 收敛，不能由接口入口存在推定本轮规则已全部实现。
+
+内部历史展示读取仓库元数据使用`POST /internal/warehouses/platform-metadata/batch`，由Warehouse权威提供，内部服务令牌鉴权且不经公网Gateway。每批1至2000个不重复正数ID，只读平台公共仓的编号、名称、类型、国家、原时区和状态，包含停用仓；不存在、非公共或已删除的ID统一列为缺失，不返回联系人及客户数据。调用方不得把原固定偏移或缺失时区猜成IANA地点时区；国家/时区不明时单列待定位，不放入美国当地日期格。接口合同见Warehouse `warehouse-v1.yaml`。
+
+仓库主档时区使用IANA地点标识（如`America/New_York`），不以固定UTC偏移表示当地时间。国内默认`Asia/Shanghai`；明确单一时区的美国州可自动选择，多时区或存在地方例外的州须按实际地址确认。新增、编辑和导入在Warehouse共用校验。初始化地址资料无法确定地点时区时保留为空并阻止正式预约确认；不根据旧偏移批量猜测或迁移现有主档。参考[IANA时区数据说明](https://www.iana.org/time-zones)。
+
+- 预约以同一美国起运仓和目的FBA仓组织，允许多个客户的真实货源统一安排。未建入仓计划也可保存；同仓不同日期/时段、不同货物可以分别建约。主单不归属单一客户，客户归属保留在每票货物明细，库存、订单、费用及派送的客户隔离不随合并改变。
+- 预约管理日历和入仓单中的预约操作共用 Lastleg 的 FBA 预约记录。平台可读取完整预约；客户只能经自己的订单/入仓单读取本客户货物，不开放跨客户预约详情。
+- FBA日历按地点当地时段与查询范围相交读取，跨日安排在覆盖的每一天展示同一业务记录；午夜结束不占次日，仅日期安排只占当天。确认时段与计划时段成对选用，不用旧计划结束时间补齐未知确认结束时间。卡片保留完整起止日期，切换已加载日期不追加查询。
+- 系统生成全局唯一AP业务单号，外部确认号单独保存并按目的FBA仓唯一。创建和编辑携带持久化幂等键、操作者及请求摘要，同键同内容返回原命令快照，即使后来编辑也不改变原结果；异内容拒绝。主单、明细和命令记录同事务。本轮分批后的占用按 V13 逐来源数量及有效批次身份收敛，不能继续用整票唯一占用阻断合法部分分配；取消后恢复原单或重约仍须重新核对当前占用。
+- 计划日期、可选计划时段、对方确认时段分别保存；仅有日期不补09点/零点，未定日期进入未定时列表。PENDING允许外部约号及箱数暂缺，不伪造值；SUCCESS必须有真实货量、FBA货件号或追踪号、外部确认号以及目的仓权威IANA时区，校验夏令时并保存对应UTC时间点。结束时间未知保持空。预计装车归运输安排，不再作为FBA预约写入字段；没有权威装车事实的关联查询明确返回未知。
+- 入仓明细入口仅用lineIds选择业务货物，服务端批量转换成原ORDER/BOOKING整票来源；外接来货后仍保持BOOKING键，禁止同时以ORDER别名建约。主表和明细只有一套，不并行维护“提前预约”副本。仓储转运的目的地和货件资料读取实际转运主记录，不能把未填充的尾程展示投影误报为目的地变化。
+- 取消/未约成须记录原因，解除失效预约的有效覆盖/绑定，并保留原计划、确认事实和历史；仍需送货的批次数量与后续需求按 V13 第六至七节保留，不回退库存或使同一货量再次可选。已有有效排车时先核对并处理运输安排。编辑使用版本校验，已确认预约不能直接退回待确认。
+- 用车计划来源读取Fleet日期范围接口，一车一条，保留计划/实际出发及司机任务预计结束的UTC时间点，不表示收货预约已确认。前端最多显示42个起运仓当地日期，通过前后各14小时的UTC检索余量覆盖跨日，已发车按实际出发时间、未发车按计划出发时间检索并逐条按权威地点时区落格，原计划保留供核对，改期不移动已执行事实；缺仓库、国家或时区时独立展示待定位记录，不用浏览器时区猜测。服务端UTC保护窗口最多44天，超过2000条明确拒绝并要求缩小范围，不逐页扫描或静默截断。读取仍需车次列表权限，正常一个车次SQL和一次内部仓库元数据批量调用；目录失败不可当作空结果。
+- 提柜日历读取Firstleg原码头拖车记录，入口为`GET /api/platform/v1/terminal-drayages/calendar`，同时要求预约列表与码头拖车列表权限。按启用目的仓国家筛选美国业务范围，不推断港口国家；已提柜按船节点权威实际日期、未提柜按预约日期检索和展示，原预约时间独立保留，改期不移动已执行事实；原业务日期无时区事实时显示待核实，不套用收货仓时区或转为UTC。日期范围最多42天，预约来源和船节点实际来源分别有界读取并按柜去重；任一来源超出1000条或目的仓无法分类时标记统计不完整，目录失败报错，不能假装无预约。详情回到原清关提柜业务，不由日历直接写原状态。
+- Admin 入口为 `../../apps/admin-web/src/modules/appointment-calendar/`，既有入仓单入口为 `modules/overseas-warehouse/`。日历读取权限为 `platform:appointment:list`，既有预约写权限独立；API 合同见 `../../baiyue-firstleg/lastleg-service/src/main/resources/openapi/fba-appointment-calendar-v1.yaml`。合并预约不表示已经排车或发车，运输执行继续按既有排车与共享车次流程处理。
+
+#### 在途货源与拼车外接货的预约跟进合同
+
+本节规定来源解析、人工跟进和已有预约覆盖的共同边界。美国全类型预约的总体目标见[优化方案](美国预约管理统一总览与优化方案.md)；本节接口不代表总体目标、环境发布或整链验收已经完成。
+
+| 事实 | 唯一来源与规则 |
+|---|---|
+| 头程已开船货 | `ORDER:<尾程订单ID>`；依据真实船节点和美国接仓点/FBA目录读取，不要求先建入仓计划。建计划后仍是同一来源，不重复计票。内部ID仅用于关联，不作为业务编号展示。 |
+| 拼车外接货 | `BOOKING:<原登记号>`；Fleet提供客户、目的地、接仓点、承运阶段、版本及可空的实际订单关联。确认承运后尚未来货可记录联系；生成订单后保持BOOKING键，禁止同时以ORDER别名重复计货。未知箱数保持空值。 |
+| 时间 | 在途列表的预计到港/到仓是订单保存的快照；船节点观察时间不代表实时ETA。预约已确认时间只读，不被预计时间更新覆盖。原预约缺少时区时明确待核实，不按操作者浏览器时区猜测。 |
+| 人工跟进 | `ll_appointment_followup`保留追加历史，跟进人取登录主体；允许没有入仓计划、约号、车辆时保存。提柜联系与码头申请按稳定柜次共享，接仓联系按柜次及实际接仓点共享，FBA联系按ORDER/BOOKING货源及客户保存；各事项独立，不推进正式确认或作业状态。 |
+| 预约覆盖 | `AppointmentCoverageService.query`按稳定来源及客户批量读取FBA预约，数量核对未覆盖、部分覆盖、待确认、已确认和待复核。外接货尚无订单但已保存安排时返回待确认及资料缺项，不返回假确认。正式确认号、地点时区和已核实来源版本分别读取；来源版本变化仅提示复核，不声称已完成精确船期影响分析。仓储转运的目的地与货件资料以转运主记录为准，缺少资料与实际目的地变化分开表达。 |
+| 运输和容量 | 车次、正式排车关联、容量、余位及发布由Fleet维护。预约侧读取其真实结果，不以联系记录生成库存、托盘、车次或容量，也不在前端扣减余位。 |
+
+HTTP入口为`/api/platform/v1/last-leg/appointment-planning`，包括`GET /cargo`、`GET /sources/resolve`及`GET/POST /sources/{sourceKey}/follow-ups`；请求和响应定义见[预约筹划OpenAPI](../../baiyue-firstleg/lastleg-service/src/main/resources/openapi/appointment-planning-v1.yaml)。深链进入预约页时须由后端重新核对客户、来源与目的仓，不能信任URL赋予资格。读取同时要求`platform:appointment:list`与`platform:overseas-warehouse:last-mile-order:list`，追加跟进另需`platform:appointment:followup`；仅平台主体可用，客户端不暴露跨客户货源。
+
+整柜入口为`GET /containers`、`GET /containers/{containerId}`与`GET/POST /containers/{containerId}/follow-ups`，沿用上述权限。未传`warehouseId`记录整柜提柜或码头联系，传入时仅记录该柜实际接仓点的接仓联系。共享来源键由服务端生成`CONTAINER:<柜次>`或`CONTAINER:<柜次>:WAREHOUSE:<仓库>`，技术平台作用域不接收客户端客户参数，也不在界面展示内部键。原货源写入口仅接受FBA联系，不能逐客户重复登记整柜事项。
+
+整柜列表读取实际已开船且仍有效的头程货物，覆盖美国接仓点的各种目的地类型；不要求先建入仓计划。关键词命中某票后仍统计同柜全部美国范围货物，接仓点一次批量分组加载。任一票箱数未知则汇总箱数显示待核实；同柜另有未知或非美国接仓点时明确标记范围不完整并禁止新联系记录。来源预计到港仍是订单快照，不能当作实时船期或预约确认。已有联系历史在来源离开活动列表后保留可读。
+
+跟进写入携带事项版本和持久化幂等键。同键、同操作者、同内容重试返回原记录；异内容或不同版本冲突拒绝，未知结果重试保持原请求。跟进保存成功不代表预约申请或确认成功。仓库目录失败必须报错；日历某来源失败时保留其他来源结果并标注统计不完整。
+
+跨客户合批核对入口为`POST /batches/preview`，读取权限与来源查询相同，单批最多100票。服务端批量核对ORDER/BOOKING来源、客户归属及真实订单，拒绝重复别名、不同起运仓/目的FBA仓、暂扣、多目的地及已有有效预约；未知箱数保留缺项。`POST /appointments`重新核对后保存同一FBA预约聚合，另需既有FBA预约写权限；`GET /appointments/unscheduled`按预约列表权限分页读取无日期安排。允许未建计划及已确认承运但尚未来货的真实来源，不能信任浏览器预览作为写入依据。两种创建入口均自动提交选择时的接仓点和目的FBA仓，服务端在锁定货源后与当前事实比对；任一变化返回冲突并要求重新核对，不静默改约至新仓，也不增加人工填写字段。备妥窗口无权威依据时明确待核实，不能用预计到港或到仓替代。部署与真实验收状态见环境主契约。
+
+已确认承运的外接货从原登记深链或`GET /external-candidates`服务端分页列表进入，必须经服务端核对后才能加入既有预约合批工作区；使用同一预览/创建接口，与同起运仓、同目的FBA仓的头程货共同保存，保留原BOOKING键，不生成ORDER别名。来源已有有效预约时不再提供新增入口；未形成入仓码或箱数未知仍可保存待确认安排，正式确认继续核验资料。
+
+外接候选由Fleet只读适配器按原登记分页发现，限已确认承运/已实收/已绑定、车次未取消或完成、权威启用美国接仓点和FBA目的仓范围；支持登记号、车次号、客户名称及来货号检索，每页最多100票。预约侧对当页来源和覆盖批量核实，保留客户归属、原登记、真实订单关联及未知箱数；目录失败显式报错。Admin仅打开外接货源列表时请求，切换头程/外接保留同一合批选择，保存后刷新覆盖。它不提供承运确认、车次容量或发布写入。
+
+共同样例：两柜头程货送同一美国接仓点再送ONT8，提柜分别按两柜联系，FBA货源保留各票ORDER来源；同一车次接入外部登记B-1时保留BOOKING:B-1。B-1确认承运但尚未来货时可以跟进和保存安排，不伪造入仓码或对方确认；实际来货在原登记行锁和同一事务内，将已有有效预约明细关联到真实订单及入仓码，继续通过同一BOOKING键读取覆盖；关联失败则来货事务一起回滚。该关联不自动改写预约数量快照、确认时间或来源版本，也不扫描补填历史记录。预约保存按登记号和订单号的稳定顺序锁定货源，并在订单锁定后清除查询缓存、重新核对来源，防止使用锁定前的旧事实。客户不符、目的仓变化、重复别名或已取消承运均不能借用其他货物的预约结果。跨来源筹划、正式确认和变化处理遵循总体方案，读取或核对成功不能代替保存和正式确认成功。
+
+| 业务域 | 能力范围 | 原型入口 |
+|---|---|---|
+| 海外仓 | 尾程订单、入库单、换标单、托盘管理、库存管理；箱号管理与产品库当前暂不进入海外仓业务正式入口；Admin 入口 `../../apps/admin-web/src/modules/overseas-warehouse/` | 原型 `../悦/货代SAAS平台后台/prototype-src/modules/03-overseas-warehouse.html`；Backend `../../baiyue-firstleg/lastleg-service/`、`../../baiyue-firstleg/warehouse-overseas-service/`，经统一 `gateway/` |
+| 海外仓排车与智能预排 | 平台查看排车列表/详情，按入仓计划或已收托盘创建预排，并完成编辑、取消、拣货、出库、发车和转派送 | Admin `../../apps/admin-web/src/modules/overseas-warehouse/pages/DispatchesView.vue`、`api/dispatches.ts`；Backend `../../baiyue-firstleg/lastleg-service/src/main/java/com/baiyue/lastleg/dispatch/` |
+| 海外仓客户自助服务 | 客户工作台正式开放贴标申请、仓储转运、货物废弃和退货换标；所有查询和写入只使用登录态客户范围 | Client `../../apps/client-web/src/modules/overseas-warehouse/routes.ts`、`views/WarehouseServiceView.vue`、`api/warehouseServices.ts`；Backend `../../baiyue-firstleg/lastleg-service/` 的 `relabel/`、`transfer/`、`discard/`，经统一 `gateway/` |
+| 海外仓 PDA 柜号签收与退货入库 | 独立应用 `../../apps/pda-overseas-uniapp/`；拆柜收货完成柜号认领、三类照片、按目的类型实收与全柜完成；退货入库支持扫描退货单号或 SKU 候选并按本包实收生成退货箱和计费批次，签收后可按同客户退货单合箱 | 拆柜前端 `src/api/inbound.js`、`receiving-adapter.js`、`pages/operation/operation.vue`；退货前端 `src/api/return-receipt.js`、`src/api/return-packing.js`、`pages/return-receipt/return-receipt.vue`、`pages/return-packing/return-packing.vue`；Backend 分别为 `inboundplan/pda/` 与 `returnreceipt/controller/PdaReturnReceiptController.java`、`PdaReturnInventoryController.java`，经统一 `gateway/` |
+| 海外仓 PDA 库内、托盘、换标与查询 | Lastleg 提供盘点、同仓整托移库、托盘组拆换绑、换标和库存/库位/托盘查询能力；当前终端入口按工作台能力开关启用，未进入 PDA 的操作由 Admin/Client 正式页面承载 | Backend `../../baiyue-firstleg/lastleg-service/src/main/java/com/baiyue/lastleg/pda/stocktake/`、`pda/move/`、`pda/warehouse/`、`palletops/`、`relabel/pda/`；契约 `src/main/resources/openapi/overseas-pda-operations-v1.yaml` |
+| 海外仓出库与派送 | 排车编辑/取消、PDA 排车拣货、出库任务、发车门禁、转派送、客户派送单和派送完成 | Admin `../../apps/admin-web/src/modules/overseas-warehouse/`；Overseas PDA `../../apps/pda-overseas-uniapp/src/pages/dispatch/`、`src/pages/outbound/`；Backend `../../baiyue-firstleg/lastleg-service/src/main/java/com/baiyue/lastleg/dispatch/`、`delivery/` |
+| 异常退回与客户回访 | 异常建档、派送退回入仓、派送状态、签收/回访附件和客户回访 | Admin `ExceptionOrdersView.vue`、`CustomerVisitsView.vue`；Backend `exceptionorder/`、`customervisit/` |
+| 一件代发 | 国内订单强制 SKU 快照、装柜工作托盘、海外 SKU/箱唛库存和一件代发出库 | Backend `order/`、`firstleg/`、`lastleg-service/dropship/`；跨区事件见 `common-event-contract/` |
+| 海外业务 | 本土散板、采购订单、本土卡车；Admin 入口 `../../apps/admin-web/src/modules/overseas-business/` | 原型 `../悦/货代SAAS平台后台/prototype-src/modules/07-overseas-business.html`；Backend `../../baiyue-firstleg/lastleg-service/` 的 `procurement/`、`trucking/` 及后续本土散板子域 |
+| 仓库主数据与海外资源 | 仓库 ID、类型、状态、地址、能力统一由国内仓库主数据维护；海外服务只维护库位、托盘和资源锁 | Admin `../../apps/admin-web/src/modules/warehouses/`；国内权威 `../../baiyue-firstleg/warehouse/`；海外资源 `../../baiyue-firstleg/warehouse-overseas-service/` |
+| 通用资料 | 海外仓报价、汇率管理、车辆列表；Admin 入口 `../../apps/admin-web/src/modules/overseas-master-data/` | `../悦/货代SAAS平台后台/prototype-src/modules/10-general.html` |
+| 车辆管理、司机资质与保养加油 | 业务范围见[车辆管理原型梳理与任务规划](车辆管理原型梳理与任务规划.md)；后端 `../../baiyue-firstleg/lastleg-service/src/main/java/com/baiyue/lastleg/fleet/`，OpenAPI `fleet-drivers-v1.yaml`、`fleet-trips-v1.yaml`、`fleet-vehicle-records-v1.yaml`；证照和运维照片复用 File | Admin 接入目录 `../../apps/admin-web/src/modules/overseas-master-data/`；原型来源和页面 ID 按规划第 1、2 节定位 |
+| 自有业务运营视图 | [自有业务首版开发契约](自有业务首版开发契约.md)、[后端接口设计](自有业务后端接口设计.md) | Admin海外通用资料模块；Lastleg `fleet/ownedbusiness/`，原排车为主事实，File分类契约 `fleet-owned-business-photos-v1.yaml` |
+| 外配业务运营视图 | [外配业务首版开发契约](外配业务首版开发契约.md) | Admin海外通用资料模块；Lastleg `fleet/outsourcedbusiness/`，复用原排车事实和附加运营记录 |
+| 内部拼车需求池 | [内部拼车需求池首版开发契约](内部拼车需求池首版开发契约.md)：车次余位发布、销售意向、确认占位、本土订单关联及统一我仓上车 | 复用上述车辆管理及本土业务入口；不开放客户端运力市场 |
+| 国内出仓后船节点 | 对已确认离开国内仓库的订舱/柜次定时查询船节点，保存最新节点、异常和查询历史，贯通目的港提柜至还柜事实 | 标准语义见[船节点标准化契约](船节点标准化契约.md)；Admin `../../apps/admin-web/src/modules/port-schedules/`、`ocean-bookings/` 及货柜详情；Backend `../../baiyue-firstleg/firstleg/src/main/java/com/baiyue/firstleg/portschedule/`、`../../baiyue-firstleg/integration-service/` |
+
+## 原型页面定向索引
+
+原型本地完整入口为 `../悦/货代SAAS平台后台/index.html`。页面任务优先读取下列命中模块和页面 ID，不先加载完整原型。
+
+### 海外仓
+
+- 尾程订单：`last-mile-orders`、`last-mile-order-detail`。
+- 入库单：`fba-inbound-order`、`fba-inbound-order-detail`；入库和退货入库相关库存视图按任务联查 `overseas-inbound`、`fba-return-inbound`。
+- 换标单：`fba-relabel-order`、`fba-relabel-order-detail`；换标库存视图按任务联查 `overseas-relabel`、`fba-return-relabel`。
+- 托盘管理：`fba-pallet`、`fba-pallet-detail`。
+- 箱号管理：`fba-carton`、`fba-carton-detail` 当前暂缓，不注册正式菜单和路由。
+- 产品库：`fba-product`、`fba-product-detail` 当前暂缓，不注册正式菜单和路由。
+- 库存管理：`fba-stock-management`、`overseas-location`、`inventory-overview`、`warehouse-stock`、`overseas-stock`、`warehouse-stock-detail`、`inventory-transactions`、`purchase-stock`、`purchase-stock-detail`、`fba-return-stock`。
+
+### 海外业务
+
+- 采购订单：`overseas-purchase`、`overseas-purchase-edit`、`overseas-purchase-detail`。
+- 本土卡车：`overseas-truck`、`overseas-truck-add`、`overseas-truck-edit`。
+- 本土散板：`overseas-looseboard`、`overseas-looseboard-add`、`overseas-looseboard-edit`。
+- `domestic-*` 和 `legacy-*` 页面不是海外仓业务默认入口；只有实际流程明确复用时才联查。
+
+### 仓库与通用资料
+
+- 海外仓合作仓：优先核对 `gen-partner-warehouse`，并同步核对现有平台仓库类型、接口和初始化 SQL。
+- 海外仓报价：`gen-overseas-quote`；涉及车队报价时再联查 `delivery-fleet-quote`。
+- 汇率管理：`gen-exchange-rate`。
+- 车辆列表与详情：`vehicle`、`vehicle-detail`。
+
+## 终端与模块边界
+
+- 海外仓出库、派送、异常退回和一件代发已经纳入全流程，不再作为海外入仓之后的独立开发批次。
+- 派送业务由 Admin/Client 承载，不进入海外 PDA；海外 PDA 负责现场入仓、托盘、排车拣货和出库等已注册作业。
+- 箱号和产品信息作为入仓、库存、箱唛及 SKU 快照的一部分使用；是否提供独立维护页面由正式路由决定，不影响全流程状态推进。
+- 高级 BI、开放平台和独立移动 APP 属于独立产品能力，不与现有业务全流程完成状态混为一谈。
+
+## 船节点定时查询边界
+
+- 所有供应商统一节点、时间语义、异常事实、停止规则和新增船司接入门禁以[船节点标准化契约](船节点标准化契约.md)为准；供应商缺失的节点保持缺失，不推测补齐。
+
+- 现有 `CarrierScheduleQuery` 查询任务及其查询尝试、历史、来源、过期标识和频率约束整体重新归入海外仓业务；不再把它列作国内货柜履约港务/船期查询能力，也不得另建一套重复任务。
+- 定时查询对象必须关联真实订舱、柜次以及可用的船司/船名航次或跟踪标识，不建立脱离业务单据的孤立轮询任务。
+- Firstleg `portschedule/` 负责任务编排、业务关联、最新节点、节点历史、幂等和停止条件；`integration-service/` 只负责船司或轨迹供应商适配、限流、超时、重试和错误归一化，不保存业务主数据。
+- 查询从确认柜子离开国内仓库后开始，贯通目的港到达、卸船、清关、提柜和还柜事实，默认在实际 `EMPTY_RETURNED` 后停止；这只扩展货柜轨迹事实，不纳入海外派送、海外仓出库或库存离仓业务。失败不能伪造成功节点，需保留来源、观测时间、最近成功时间和失败原因。
+- 现有“每 3 天一次、窗口最多 3 次”、六家船公司来源、最近有效结果和过期标识是同一查询能力的既有约束，归海外仓业务继续核对；后续若调整自动轮询频率、供应商额度、退避或停止规则，应只修改海外仓业务契约和这套任务。
+- 当前原型没有独立的“船节点定时查询”页面；涉及页面展示时从订舱、船期或货柜详情进入，不得为了匹配原型菜单把它归入海外派送。
+
+## 本土卡车与散板统一前端下单
+
+- 同一业务在 Admin 新增/编辑和 Client 下单使用一致的字段、顺序、控件、默认值、校验及提交转换；Admin 新增额外选择客户，编辑固定原订单客户；Client 的客户仅由登录会话确定，业务请求体不携带客户标识。
+- 业务表单统一为运输信息、货物信息、费用与时效和备注。起运地/目的地、两端联系人、电话及详细地址左右对应；件数、预计托数、重量和体积默认零，预算默认为空、币种 USD，空预算和零预算分别保留。车辆只在卡车填写，商品与预计托数只在散板填写。
+- 两端统一使用数字控件和 USD/CNY 选择；重量支持三位小数、体积六位小数、预算两位小数；取送时间按当地分钟输入并提交秒为零的值，不进行时区转换。四项联系信息及两个时间均必填，送货不能早于取货。
+- 各应用内部由 `TransportDemandForm.vue` 和 `transportDemandForm.ts` 复用表单、校验与业务请求转换；两端对应源码按同一内容核对，不建立跨应用目录依赖。创建保留稳定幂等键；平台编辑保留客户、业务单号和版本，受状态及只读承运来源限制。
+
+## 本土散板简化下单
+
+- 平台代客创建必须显式选择客户；客户端客户范围只取认证会话。新增、编辑保持现有独立页面；平台普通编辑仍只允许待接单且非拼车来源订单，池来源继续只读展示真实承运安排。
+- 下单移除运输方式及柜型字段，不再要求选择自送或我司提货。拼车或优先拼载属于内部安排，不再冒充交货方式或作为下单必填项；运输类型和是否打盘不在新增主表单要求填写，未知安排保持空，不自动补造。散板移除柜型字段。
+- 需求保存取货地、目的地、可选详细地址补充、起运地联系人及联系电话、目的地联系人及联系电话、商品名称、预计托数、件数、总重量、总体积、预算总价、币种、取货与送达时间和备注。商品名称、预算和备注选填；四项联系人信息与取货、送货时间全部必填；预计托数、件数及重量体积可为零，不能为负。件数、地址补充和备注按统一前端下单表单展开填写。
+- `estimatedPalletCount` 是下单预计托数；`packageCount` 是件数，二者独立。下单不生成实物托盘，不把预计托数写成实际收货或实占托位；拼车来源沿真实询价的货名与预计托数保存。
+- `pickupAt` 与 `deliveryAt` 保存不带时区的当地日期时间，按分钟输入、原值显示，不进行 UTC 转换。取货与送货时间均必填；送货时间不能早于取货时间。预算明确显示 USD 或 CNY，金额空值与零值区分。
+- 平台和客户接口共用 Lastleg `looseboard/dto/LocalLooseboardRequests.java`、`LocalLooseboardResponses.java` 及 `overseas-business-v1.yaml`，不保留旧运输枚举或要求日期别名。现有 API 路径与权限复用，空库结构同步模块基线及海外统一初始化，不回填测试存量，不自动执行 SQL 或部署。
+
+## 美国本土卡独立下单
+
+- 客户端和平台新增/编辑共用同一服务端需求合同：移除运输类型、柜型、下单预报托盘数及原要求时间；车辆类型为必选的“15拖”（`PALLET_15`）或“30拖”（`PALLET_30`）。车辆主档仍独立维护实际容量，车型不等于本票货量。
+- 起运地联系人、起运地联系电话、目的地联系人、目的地联系电话、取货时间和送货时间全部必填。时间按日期及小时分钟填写，不进行时区转换；送货不能早于取货。列表、详情与平台编辑展示同一份保存值，客户端不提交客户标识。
+- 独立下单不生成预报托盘，首次实际收货确定确认托数；已有拼车来源的真实预报及实际履约继续独立记录。拼车来源未提供的车型、目的地联系人/电话、送货时间保持未知，页面显示“—”，不捏造数据。美本土散板按本文“本土散板简化下单”使用独立需求合同。
+- 接口及字段唯一实现合同为 Lastleg `trucking/dto/UsTruckOrderRequests.java`、`UsTruckOrderResponses.java` 与 `src/main/resources/openapi/overseas-business-v1.yaml`；数据结构同步模块基线及海外统一空库初始化。页面承载核对见 Client `cross-border/PROTOTYPE_MATRIX.md` 和 Admin `overseas-business/PROTOTYPE_MATRIX.md`。
+
+## 系统边界与索引维护
+
+- 托盘管理的单张标签 PDF 从 Admin `PalletsView.vue` → `warehouse-overseas-service` 的 `GET /api/platform/v1/warehouse-admin/{warehouseId}/pallets/{id}/label` 进入，只按真实托盘编码打印，不重新生成编号。纸张、方向和模板字段只查[打印标签当前入口](../打印标签维护/README.md)的对应类型；服务接入与权限见海外资源服务 `AGENTS.md`，不在本文复制模板常量或尺寸。
+
+- 海外仓合作仓是现有头程仓库主数据的类型扩展，需同步核对 Admin `warehouses`、Warehouse Service 的 DTO/Controller/OpenAPI/SQL 及实际消费者；不得因此把海外库存业务写入国内 Warehouse Service。
+- 海外库存、库内作业和海外本土业务已有明确服务入口：`gateway/` 是统一 API 网关，`lastleg-service/` 拥有尾程订单、入仓计划、换标、库存业务、采购和本土卡车；国内 `warehouse-service` 是仓库主数据唯一权威，`warehouse-overseas-service/` 只拥有库位、托盘及资源锁并引用国内 `warehouseId`。不得把海外库存业务塞入国内 `firstleg/` 或 `warehouse/`。
+- 国内装柜完成事件只在海外生成 `PENDING_ASSIGNMENT` 尾程订单、冻结快照和 `FIRST_LEG` 在途库存，不自动生成入仓计划。平台通过 `GET /api/platform/v1/last-leg/orders/container-summaries` 按稳定 `sourceContainerBookingId` 服务端聚合全柜订单、入仓码、计划数、未操作数和 `allPlansReady`，分页返回全部稳定来源柜，已生成计划的柜仍保留供接柜仓查询与修改；`pendingPlanCount` 区分待建计划，`resourcePendingPlanCount` 区分托盘资源待生成，后者仅用于自动生成异常后的重试；详情 `/{sourceContainerBookingId}` 返回柜内全部订单与计划且不受订单分页截断。`plannedArrivalAt` 只来自装柜完成事件 `estimatedWarehouseArrivalAt` 冻结到 Lastleg `ll_order.estimated_warehouse_at` 的计划到仓事实，不得使用创建时间、预计到港或当前时间替代，并按该时间升序、空值最后排序。确认后调用 `POST /api/platform/v1/last-leg/inbound-plans/convert-container`；服务端一次锁定整柜、每票独立生成一个计划，整批原子且幂等。转换成功才将尾程订单推进为 `INBOUND_PLANNED`，并把库存余额的来源入仓码展示快照替换为各自 `planNo`。
+- 尾程订单的 `inboundCode` 只保存并展示真实来源入仓码；换标申请、本土散板等没有入仓关系的海外本土业务保持为空，由页面显示 `—`，不得用换标单号、本土散板单号或内部 ID 冒充入仓码。
+- 平台可按单票尾程订单入库计划（托数、托盘类型、分配/可合托/加急和备注）；入库仓、入仓码和预计到仓时间均展示冻结事实，不允许人工改写。预计到仓日期由服务端锁定来源柜全部订单的 `estimated_warehouse_at`，缺失或同柜不一致时阻断，人工与自动计划统一写入该柜日期。写入时校验订单版本、客户归属、仓库主档和幂等键；一票柜保存后立即自动生成并绑定托盘码、海外仓托盘和资源锁，多票柜在最后一票计划齐全时自动为全柜完成同一动作。`resourcePendingPlanCount` 只用于自动生成失败后的显式重试，不是正常人工步骤。分配、可合托、加急必须随入库单列表和海外 PDA 入仓码作业返回并展示，其中“可合托”只向现场提供选择：合托时扫描同目的仓已使用的托盘码，独立收货时扫描新托盘码，不作为实收或完成门禁。新增暂扣只允许货物完成入库后执行；暂扣只作用于该票并仅阻断排车和出库，不阻断入库计划或入库作业，同柜其他订单不受影响。
+- 头程散货在预装确认且真实集装箱号就绪后，按 `集装箱号-FBA仓编码-三位序号` 冻结托盘码；序号在当前柜、当前 FBA 仓内从 001 独立递增。送柜报关、清关提柜和预装清单共用同一按 FBA 仓分组的打印清单，可整柜打印或选择单仓前 N 张补打。该编号随装柜完成事件进入海外，生成入库计划与海外实体托盘时原样沿用；一件代发继续使用国内装箱打托形成的托盘号，不参与散货重新编号。
+- 头程与海外仓允许装托密度不同。尾程最终托数取不低于头程已有托盘码数的海外计划结果：头程已有编码全部保留，数量不足时在同柜、同 FBA 内按连续下标补码，不因数量差异阻断。柜级预览必须分别返回并展示头程已有、海外仓补充和最终托数；最终总数不得标成“本次新增”。
+- 尾程订单人工节点固定为国内报关完成、预计/实际开船、预计到港、国外清关完成、实际到港等待卸船、预约提柜和卸柜八行完整快照。第一次保存后该订单永久使用 `MANUAL` 来源，读取和页面展示不得再回退柜级节点，也不得反向修改货柜船节点。
+- 目的港码头拖车仍归 Firstleg 货柜聚合，但 Admin 清关提柜列表不再使用预约/实际提柜作为到仓业务时间：原两列改为“预计到仓/实际到仓”。未人工维护且未建入库计划时，预计到仓按[预约日历统一日期规则](预约工作日历V13变更说明.md#2026-10-19-当前预约列表收敛规则)展示到港日期加两个自然日的默认值，列表与详情一致且不自动写入。人工调整在列表内选择日期时间并由 Lastleg 按 `sourceContainerBookingId` 原子同步整柜尾程订单，已有入库计划后锁定；实际到仓只取海外 PDA 首次开始收货的 `ll_receiving_container_session.receiving_at`。车队、邮件、还柜及 `unloadingCompletedAt + 72h` 还空预警仍按原码头拖车链路处理。
+- 手动还柜以真实海外卸柜完成且尚未还柜为准，仍校验独立还柜权限；无需事先存在车队、预约或提柜时间。首次命令使用版本 0 创建拖车记录，车队字段可为空，不补造提柜事实。还柜时间不得早于卸柜完成时间或已有提柜时间，成功后同步标准还柜节点并解除报空预警。
+- 船节点是头程海运在途事实与海外接柜之间的衔接能力，业务聚合继续由 Firstleg 按 `containerBookingId` 柜级持有，不绑定客户；跨区域事件使用 `tenantId=0` 平台技术范围，到港/可提柜结果通过明确契约提供给海外区域，不复制第二套轮询任务。
+- Admin、Client 及海外 PDA 按当前统一 Gateway、Auth 会话与可靠直接投递契约接入；不沿用旧双区域 API 或独立海外 Token，业务页面不自行实现第二套登录。
+- 海外仓 PDA 使用独立 `apps/pda-overseas-uniapp/` 工程和发布身份，但账号仍由国内 Auth 唯一签发；真实作业请求必须经统一 Gateway 的显式 PDA 路由。工作台只展示已注册并启用的现场作业，其他业务通过 Admin/Client 完成，不以某个终端是否承载全部操作判断端到端流程是否完成。
+- 海外 PDA 的实际收货仓是国内 `warehouse-service` 中 `tenant_id=0`、类型为 `OVERSEAS`、状态 `ACTIVE` 且启用 `RECEIVING` 能力的平台共享物理仓，并由当前海外 PDA 作业账号的仓绑定固定，角色与会话字段以统一认证契约为准；海外数据库只保存相同 `warehouseId` 引用。PDA 不接收仓库 ID，也不能切换柜号。统一 Gateway 对每个 `/api/pda/**` 请求在本地验签后向 Auth 实时核对账号 `token_version` 与当前仓绑定，换仓或清空绑定后旧 Token 立即失效，Auth 不可用时拒绝请求。待收柜在首次准备时原子认领到该仓，入仓计划、尾程订单和收货会话冻结实际仓 ID/名称；国内装柜事件的仓库仅作为来源仓快照，目的仓/FBA 仓也不得冒充实际收货仓。
+- 海外 PDA 接柜候选、认领会话、国内五类装柜照片对照、海外三类签收照片与整柜完成均按 `sourceContainerBookingId + containerNo` 聚合，不保存客户并允许同柜多个客户。国内照片在签收阶段展开、收货阶段折叠，只读加载失败不阻断拆柜。签收后为柜内每个计划按其自身客户生成任务；入仓码解析、SKU 实收、托盘占用和库存入账继续按该票真实客户隔离，整柜完成需全部计划核平且只发布一次柜级完成事件。
+- 业务规则只改本主题正文或相应正式契约；仅代码入口、职责或路径变化时更新实际受影响的索引与最近指引，不批量同步所有层级。不把排期、完成比例或临时任务状态写入快速索引。
+
+## 码头车队邮件
+
+首次选择车队后从清关提柜列表发送请求，更换车队时原子保存原车队取消和新车队提柜两封邮件；同一车队重复选择不发信。邮箱读取供应商资料，缺失或无效时阻断发送或换队。邮件顺序投递，失败待人工核对后重试。接口、临时模板和启用方式见 [Firstleg 车队邮件说明](../../baiyue-firstleg/firstleg/docs/terminal-drayage-mail.md)。

海外仓业务/内部拼车需求池首版开发契约.md

@@ -0,0 +1,236 @@
+# 内部拼车需求池首版开发契约
+
+日期：2026-10-07。当前版本：V5，五轮开发前审核修订完成，进入开发。本文为本功能唯一范围与实现契约；审核记录随文维护。部署和实际验收结论仅写入两份环境主契约，不能用本文的方案代替已实现证明。
+
+## 1. 目标与首版范围
+
+### 当前页面范围（2026-10-21）
+
+用户确认「海外业务 → 散板需求」当前仅作为平台内部的排车余位需求池，人工联系、下单，不向客户公开运力市场。2026-10-22 简化智能排车：搜索区仅提供默认不勾选的“发布公共需求”，统一应用于本次生成的所有排车单，每车独立保存；移除下方计划时间与备注填写区，需求时间直接使用关联排车的计划发车时间，时间和备注沿用“维护车辆信息”维护。2026-10-23 收敛为仅在“智能排车”建单时选择发布，默认不勾选；排车列表和入库单复用同一智能排车弹窗。维护车辆不再提供发布、取消发布或恢复发布，编辑命令不接收发布字段；预约工作日历创建排车不自动发布，服务端新建缺省也不发布。需要重发时，按原取消门禁取消当前排车，再通过智能排车重新创建并勾选发布。发布选择与新建命令同事务保存，沿用原权限和幂等键。
+
+数据源直接来自当前排车主单，不再依赖旧车次的人工余位发布记录，也不创建另一份车次、发布单或占位。仅勾选发布、ACTIVE、DELIVERY、未实际发车且处于装车前/装车中/装车后的排车进入列表；取消排车、实际发车/进入派送中或任一已知容量维度满载时自动退出。取货和本土卡车排车不参与。查询复用实时排车快照，按本车业务号一行展示，不返回客户货物、司机私人信息或内部ID。
+
+车辆容量与已排实托数分别展示，不将实托数等同标准托位。可靠装载确认存在时，用去重实托的标准托位、重量和体积计算起运段可再接的余量；首版均从我仓上车，沿途只卸货。任一已知维度已满即退出；缺少可靠装载/容量资料时保留需求并明确“余位待确认”，不填零、不按车型名称或默认30托推算。不存在可公开的调度联系方式时，不以司机电话替代。新列表仅读取运输和容量摘要，不开放详情跳入旧车次、登记、确认承运、来货、核量或排入本车等操作。
+
+原需求池与后续拼车实现保留，不增加开放登记的功能开关、不删除组件或业务处理代码。客户本土散板下单入口保持独立；下文完整拼车流程描述保留能力，不能据此认为当前页面已开放。新增发布字段、读接口与页面的代码完成不等于已执行SQL、已部署或已通过真实环境验收。
+
+### 2026年10月9日操作简化开发定稿与预约交接
+
+本次已收到开始开发指令，采用《拼车数据入口与操作简化评估草案》第七、八节的完整范围：已有车次接货，分阶段登记、服务端缺项及角色提示、原登记连续履约、合格排车候选、共用车次准备与实收排入。保留直接外接预订来源，不新增独立待配货池、虚拟运力或跨车改配。本文记录规则，发布与实际验收继续归环境主契约。
+
+文件归属：本侧维护 Admin `overseas-master-data/`、其公开出口和所需 `overseas-warehouse` 排车消费者；Backend `fleet/`、`dispatch/fleet/`、相关既有排车候选 Mapper 及 Fleet OpenAPI/测试。预约实施侧维护 `appointment-calendar/`、预约服务、预约投影及其 OpenAPI，并统一整合 `lastleg.sql`、公共导航和新增权限种子；本侧不重叠写这些共享文件。不改变已存在的财务修改。
+
+预约交接的稳定身份：成交前为 `bookingNo`，成交后关联 `businessOrderNo`；安排来货后增加 `incomingNo`，实收依据为 `receiptHash + warehousePalletId + packages`；正式排车以 `dispatchNo` 及其完整来源组成核对。货物上车资格以同客户、同起运仓、同真实来货来源、完整实收托盘组成、未绑定其他车次为准。来源尚未形成合格排车或实际托盘时，预约侧只能保存筹划，不能通过本侧创建假托盘或实载。
+
+现有共用 API 前缀为 `/api/platform/v1/last-leg/fleet`：`/trips` 维护真实车次；`/trips/{tripNo}/assignment` 分配资源；`/trips/{tripNo}/dispatches/bind` 关联合格排车；`/trips/{tripNo}/capacity-plan` 核对计划；`/capacity-offers` 及发布命令维护每车次唯一发布。当前 UI 以车次详情及 `CapacityOfferSettingsDialog.vue` 为入口；新增共用入口实现后通过模块 `index.ts` 导出，不允许预约侧直接引用内部组件。预约侧覆盖投影尚待交接，以正式来源查询结果为准，不在本侧新增预约状态。
+
+共同样例：两柜真实货物的合格排车进入同一30托位车次，自有计划占18，确认外接登记8后同区间余4；外接实收排入后，8由预留转入真实计划，仍只计一次。来货绑定导致旧计划失效时，余位返回待核对，不能继续展示旧余4或自动恢复发布。托位、重量、体积逐段同时校验，三类阶段（预约筹划、外接保位、正式排入）不互相替代。
+
+登记保存即对获准调度可见，不保位；后续必填与始终选填分区展示。`Inquiry.progress` 为只读派生的阶段、保位说明、负责角色、主要动作及缺项，不能被前端写成状态。承运资格同时检查本票资料与目的站余位，最终写命令仍锁定并复验。后续履约读取和操作以原登记身份进入，查看本人记录不授予整车其他客户或司机资料的读取权限。
+
+用户场景：调度约定30托位车辆去目的仓A，自有货占18托位，将剩余12托位发布给内部销售；销售联系外部客户、登记意向，调度确认承运和占位，客户订单随后走真实到仓、装车、配送和签收。
+
+本功能的“需求池”是**已发布车次的剩余运力目录**，不是客户待配货需求库。一条发布对应一个车次；销售从具体车次登记意向，不新建无车次撮合平台。
+
+首版边界：
+
+- 仅内部Admin展示运力池，Client不开放余位市场。客户只查看自己的本土订单和获准的承运安排。
+- 所有外接货统一在我仓上车。客户自行送仓，或我方在线下安排提货回仓，均从实际到仓后开始系统收货。可记录两种交货说明，不能宣称已有独立提货任务闭环。
+- 沿途提货直送、行驶途中新增承运、独立提货车调度及交接、自动撮合、销售临时限时锁位、整单拆分到多个干线车次均不在首版。
+- 询价不占位，调度确认承运才占位。订单预算不等于成交运费，承运确认不等于收款。
+- 本轮用户已授权TEST部署、测试数据库、真实HTTP和内置浏览器验收，Admin/Client固定1920×1080、100%缩放。操作目标为TEST，不沿用上轮灰度配置；密钥仅从私有配置读取。
+
+## 2. 单一事实来源与复用
+
+| 内容 | 权威来源与本轮处理 |
+| --- | --- |
+| 车次、线路、时间、车辆容量 | 现有FleetTrip及当前车辆主档；不建立第二套车次 |
+| 自有货计划占位 | 当前有效capacity-plan及货物hash，保留三维容量 |
+| 外接占位 | 复用外接预订CONFIRMED/RECEIVED；BOUND后由实际货物计入，不双扣 |
+| 发布信息 | 新增每车次唯一的发布记录：业务编号、状态、交货截止、公开给销售的联系人/备注、版本和审计 |
+| 客户意向 | 复用外接预订DRAFT，增加发布关联、服务端销售负责人、交货说明及本土业务类型 |
+| 本土订单 | 本土散板/本土卡车保存客户委托；预订关联真实业务单号，不再重复产生无关商业订单 |
+| 实收与发运 | 现有外接来货→WarehouseTransfer→库存→客户排车→共享车次→派送链 |
+| 费用 | 沿现有实际派送费用来源发布，需求/询价阶段不新增应收。成交价、预算与实收款独立展示 |
+
+开发前源码缺口记录：当时没有发布列表，预订没有销售负责人/发布来源，本土订单没有真实外接履约关联；本土散板create会另建逻辑尾程单，不能直接再调用外接来货形成两个来源；本土卡车原库存动作尚不等于外接真实库存链。此段说明本次设计起因，当前实现及验收结果以测试环境主契约为准。
+
+## 3. 发布与余位
+
+### 页面发布操作简化（2026-10-09）
+
+车次关联排车单时，在同一事务按真实货物目的地标识自动补齐卸货站；去重，不按同名合并，不改变已有有效站点顺序与索引。仅新车默认的“待确定卸货点”占位由真实目的地替换；外接预订路线门禁、缺失目的地拒绝与绑定变更后的重新审核继续生效。多目的地的行驶顺序仍由调度在车次计划确认。
+
+车次“发布拼车余位”使用1080px居中窗口，同窗展示计划容量与交货截止；唯一匹配卸货站直接显示，不重复选择。已有计划数值自动带入，只补缺失的预计重量、体积并核对托位；尚无可靠实托测量字段时不拿计费重量或零值填充。交货截止默认计划发车时间，可提前；公开联系人与交货说明收起为选填，不将司机联系方式自动公开。
+
+“确认发布”依次复用容量确认、发布信息保存、发布/恢复接口，传递各步最新版本，保留服务端权限、容量、状态及幂等检查；已有有效且未编辑的容量直接复用。保存草稿与发布不再要求两次点击。发布失败不宣称成功；未知发布结果保留原键续试，已成功的保存步骤不重做。发布完成提供“查看需求池发布”。暂停与关闭继续显式确认。尚未自动匹配的车次可在同窗“按货物补齐卸货站”，不能自由输入标识绕过货物来源。
+
+
+发布由有调度管理权限的用户在车次详情执行。前提：车次PLANNED，已分配可用车辆和司机，有真实起运仓及规范卸货站，发车/交货截止有效，容量计划有效。发布不替代调度审核、司机资质门禁或发车前理货审核。
+
+本轮不新增“车牌司机尚未落实的虚拟运力”模型，沿用已分配资源的现有车次。计划容量或任何必须数据未就绪时给出具体阻断原因，不能以车型名字推算30托。
+
+发布状态为DRAFT、OPEN、PAUSED、CLOSED。满位、超过交货截止、已发车/取消、容量待核对为服务端计算的接单资格，不另维护可手改的余位数字。暂停/关闭不取消已确认预订或删除客户订单；恢复发布必须重新校验。首版车次发车后不再新增承运。
+
+状态转换为DRAFT→OPEN，OPEN→PAUSED/CLOSED，PAUSED→OPEN/CLOSED；CLOSED为终态，同车次不能另建发布规避关闭。OPEN但事实失效时允许调度显式“重新核对并恢复”更新事实指纹，仍须完整资格校验。
+
+时间以服务端Clock的Instant为准，开放新询价/编辑须OPEN且`now < cutoff <= plannedDepartureAt`、车次仍PLANNED；询价不承诺运力，可在满位或待核对时保留草稿并明确提示，确认承运则必须所有资格有效。关闭、截止或发车后，销售仍可经“我的意向”只读跟踪本人已登记/成交业务；暂停不接受新询价或编辑，仅允许既有规则下的查看/取消。
+
+容量按起运仓至选定卸货站的每段最小可用量校验，托位、重量和体积同时满足。列表展示分目的站的可接量，不能用全车某一个余位数字代表所有运输区间。30−18−已确认8=4仅为同一区间同规格例子。
+
+读取可接资格、发布、确认承运均复验车辆当前启用状态和实际容量与计划是否一致；当前车辆停用或容量变更使旧计划不可承诺。改派/改线/新增自有货/绑定或解绑货物导致计划失效时，显示“待调度核对”、余位为未知并拒绝新确认，不回退到旧计划或显示0。确认承运仍由服务端在车次锁内重新计算。
+
+发布保存本次核对的路线/发车时间、车辆容量和有效容量计划的事实指纹。仅询价、确认预订导致的版本变化不使发布失效；实际货物/容量计划或上述承诺事实变化则待核对，重新确认计划后由调度显式恢复接单，不静默恢复。GET只计算资格，不修改发布状态。表格采用“已关联货物计划占用 + 未关联外接预留(CONFIRMED/RECEIVED) + 可接余位”；BOUND外接已在计划内，若另示外接总量，只作信息列，绝不再次相加。
+
+所有发布和预订写命令先锁车次，再按需锁实时车辆，随后锁发布记录、预订及商业关联；暂停/关闭与承运确认也共用该车次锁。实际实现须与现有车次/资源锁顺序一致。权限、登录身份与来源归属校验不能省略；已成功命令的同键同载荷重放在重新评估截止/OPEN等业务资格之前返回原结果，异载荷仍冲突。
+
+## 4. 销售与调度权限
+
+- 新增独立发布池列表权限，包含发布详情和不含敏感信息的只读辅助投影；不要求销售拥有trip:list。
+- 销售可查看OPEN发布的线路、时间、容量、调度联系信息；登记并查看/修改/取消本人DRAFT意向。销售负责人取登录userId，不接受浏览器冒充，不按姓名判定归属。
+- 调度管理权限可查看各销售意向、发布/暂停/关闭、确认承运和处理取消；不能通过一般销售写权限确认占位。
+- 当前IAM无稳定销售客群ACL，只有salesOwnerName文本。本轮不新增CRM归属体系。授予本功能意向登记权限即允许在用途限定的客户候选中选择公司ACTIVE客户，仅返回ID、客户编号、名称，不返回电话/证照/财务资料；必须在文档与接口中明确该公司共享选单目录口径。
+- 他人意向的直接编号访问、修改及取消须在服务端拒绝；发布总余位可以包含全部预订，但不向销售返回他人客户名称、货物、价格、司机私人信息或采购成本。
+- Client根据自身客户身份查询本土订单，不提供发布池接口或其他客户预订详情。
+
+建议权限族：`platform:fleet:capacity-offer:list/manage`与`platform:fleet:capacity-offer:inquiry-create/inquiry-edit/inquiry-cancel`。manage授权调度读取全部意向并确认承运，普通list只读取本人意向；列表和详情只读语义一致。最终路径与权限同步Controller、OpenAPI、IAM种子、导航和测试。
+
+读取发布/本人意向允许list或manage；销售写操作同时要求list和对应inquiry写权限，manage可管理全部。所有查询/写入都由服务端取销售身份；池来源预订经既有trip booking接口操作时也必须执行一致的来源、权限、发布、订单桥和取消门禁，不能借旧接口绕过。
+
+## 5. 意向、成交与本土订单
+
+销售从发布详情登记意向：客户、本土散板或本土卡车类型、当前路线卸货站、货名、预计箱数/托位/重量/体积、交货方式、预计到仓、联系人、报价方式/币种/金额、备注。未完成询价允许缺预计载荷或价格；确认承运前必须完整且与本轮计划匹配。空值不等于0，报价库引用与手填成交价按既有权限规则处理。
+
+首版每条外接意向整单绑定一个干线车次，不提供销售拆分数量。仅可选择本车现有卸货站，新增目的地须调度先改车次路线并重核计划；不能以自由文本地址伪造目的仓匹配。
+
+确认承运采用一次服务端命令：验证发布/车次/预订版本、登录权限、客户资格、路线、时间、实际有效余位及成交价→创建本土商业订单及唯一桥关联→确认预订占位→返回新版本及业务单号。不可由浏览器串行三次写入拼接“成功”；使用稳定幂等键，同键同载荷返回原结果，同键异载荷拒绝。未知结果保留原键与内容，不能生成新单重试。
+
+确认成交只新建一张池来源商业主单，不接受任意已有独立订单号。LOCAL_LOOSEBOARD通过专用内部方法创建主单与历史，不执行原独立下单生成占位ll_order的分支；US_TRUCK同样只建商业主单，不生成模拟实托记录。独立下单保持其合法业务入口，池内订单走真实运输桥，不以“兼容”保留两套同单行为。
+
+唯一桥表`ll_fleet_pool_order_link`以booking_id唯一，保存客户、business_type、商业单ID/业务号和桥状态；来货生成后再绑定唯一incoming_no和lastleg_order_id。预订DTO商业号来自桥投影，不在两处维护可写副本。登记来货由现有FleetIncomingAdapter创建唯一WarehouseTransfer及真实尾程来源，并在同事务反绑商业单；客户、目的地或来源不符则回滚，不产生第二张尾程单。
+
+尾程订单列表、详情与导出通过同客户、同尾程单的正式关联展示商业来源：池来源为“本土散板/本土卡车 · 拼车需求池”，独立散板为“本土散板 · 独立下单”，未关联商业单的外接来货为“仓储转运 · 外接来货”。`orderType` 继续表示履约类型，不改写为商业类型。`businessSource` 返回商业类型、来源中文说明、关联商业单号及外接预订号；缺少关联显示“—”，禁止解析备注。`businessType` 筛选本土散板时覆盖独立与池来源两条路径；商业单号和预订号支持服务端包含匹配。Admin 商业单号仅在具备目标列表权限时链接到带该单号筛选的既有本土业务列表，池来源继续从“承运安排”查看。
+
+实托数与托位分开：询价提供可空的预计实托数；US_TRUCK确认前必须有正数预计实托数，不能拿palletSpaces当palletCount。预计箱数同样允许未知，确认前须补完整真实预报；不以0或1伪造未知。实收时以去重后的真实仓库托盘数记录实际实托，按核准每托占位合计记录托位。商业单预算仍是独立可空预算，不自动写入成交金额。
+
+池询价未采集柜型或是否委托打盘服务，商业桥须将这两项保留为未知：卡车/散板的`containerType`及散板的`palletRequired`为null，不套用40HQ或YES。实托数、占用托位及实际托盘存在均不能证明客户委托打盘；Admin/Client列表和详情将未知显示为“—”。响应允许空值或省略空字段，详情经summary承载；普通独立Create/Update请求的必填、枚举及默认规则保持原合同。
+
+池来源商业单状态映射：成交为WAITING_INBOUND；真实收货开始为RECEIVING；实收并核量确认后为WAITING_CONSOLIDATION（散板新增对应状态）；完整关联客户排车后为PENDING_DISPATCH；整车实际出库/发车为IN_TRANSIT；全部实际货物签收为COMPLETED；安全取消为CANCELLED。不得把绑定车次标为已发车。状态与历史由实际来源事务推进并带来源业务号/时间；退回、部分签收保持未完成，并展示实际派送摘要。重复保存回执不得重复追加完成历史。
+
+真实出库/签收需要本地桥回传：现国内完成Outbox只覆盖FIRSTLEG来源，不能依赖它完成本土单。按桥中唯一来源和同客户派送/实际货量核对后回写主单；不得创建第二笔运费。池来源散板编辑/手工状态、卡车编辑/审核/手工收托/超托审核/分配/发车/完成/取消等入口必须识别来源后拒绝旁路，并返回当前应操作入口；不能只在页面隐藏按钮。
+
+运费仍由真实转派送的`FLEET:{bookingNo}:{dispatchNo}:FREIGHT`唯一来源发布；商业主单、发布池、来货和签收回传均不重复发布该费用。全外接货不能另填一份派送应收。成交价、实际约定运费、Finance应收/实收各自表达，零价沿现有正式规则处理，不能绕过费用门禁。
+
+成交/取消锁顺序沿第3节：车次→资源→发布→预订→商业关联/商业单。实际收货/签收在既有作业锁之后仅锁商业关联/商业单，不反向锁车次/发布/预订。商业单旧手工入口在本单锁内识别池来源直接拒绝，不反向协调车次。已有池来源来货也不得独立从旧来货取消入口取消而留下有效承诺；本轮登记来货后的取消/跨车改配明确阻断。
+
+Admin和Client自己的本土订单列表/详情返回同一批查询产生的`fleetArrangement`摘要：来源类型、真实商业单号、预订号、计划发车、起运仓和目的地、交货说明、实际履约阶段/时间、约定运费（非实收）及只读原因，并提供已签/未签/退回数量和异常摘要；独立订单该字段为null。不返回发布池内部ID、余位、他人货物、司机私人信息或采购成本。原列表/详情不得逐行额外调用池接口。首版不额外建设任意存量订单批量导入/撮合。
+
+## 6. 真实到仓、变更与取消
+
+已确认后复用登记来货、PDA实际收货、运营核量确认、生成客户排车并关联本车、调度审核、PDA拣货、实测装载、理货审核、整车发车、目的仓签收、结案及资源释放。需求池提供关联业务跳转和实时摘要，不再建立一套“手填已发车”状态。
+
+实收托位/重量/体积改变，须重新核量、检查本车剩余容量和确认费用；超量不可自动覆盖承诺。整单价和按托价保持既有口径，不静默把预算写为应收。BOUND预订由真实货物占位替代预订，不能叠加扣减；对应容量计划失效时停止继续接单，待重核。
+
+DRAFT由本人或调度取消；池来源CONFIRMED仅在尚未登记来货时由调度一体取消商业关联、预订及占位。已有incoming、实收或BOUND拒绝池内快捷取消，进入既有实际作业处理；现有booking.cancel允许RECEIVED的行为不能旁路该池来源门禁。不可通过关闭发布或取消意向删除库存、清除已拣货或把已发车货物变回草稿。首版不提供实收后跨车次改配，遇到该请求明确拒绝并保留原单据，不自动重造。
+
+## 7. 页面、请求预算与错误处理
+
+Admin「车辆管理」的「拼车接货」包含“可拼车次”“我的登记”两个独立页签，仅加载激活页签；调度默认进入“待我处理”登记范围，销售默认进入“可拼车次”。调度可选全部登记范围，服务端拒绝销售越权该范围。主列表一行一发布车次：操作、发布号/车次号、起运仓、目的站/路线、发车/交货截止、已关联货物计划占用、未关联外接预留、各目的地可接托位/重量/体积、接单状态和调度联系信息；多目的站在同一行分行展示，详情展开分段表。查询起运仓/目的地使用文本条件，日期和状态使用本地选项，不为筛选增加目录请求。“我的登记”跨发布状态可读历史，不依赖OPEN列表。可拼车次默认使用 `scope=AVAILABLE`，在数据库分页前按 `OPEN + PLANNED + now < cutoff <= plannedDepartureAt` 筛选，管理员也遵循同一默认范围；满位或容量待核对但允许草稿登记的发布仍保留。管理员显式选择“全部发布（含历史）”时使用 `scope=ALL`，普通销售不得请求该范围。车次发布设置查找已有发布显式使用ALL，避免遗漏草稿或过期发布。详情页有登记权限时保留“登记意向”按钮，业务资格不足则置灰并展示服务端原因；无登记权限不显示按钮。
+
+发布详情为独立页，首个响应带运输摘要、分段余位及获准意向首20条、total/page/size；意向翻页单独1次请求。池接口只返回专用offer/inquiry DTO，不复用含司机或客户联系信息的TripDetail/FleetCustomerOption。offer独立返回canCreateInquiry、canConfirm和blockReason，满位或待核对不错误禁用允许的草稿登记；未取得有效容量时显示“待调度核对”，已知满位才显示0。
+
+操作承载矩阵：发布详情独立页；登记/编辑/查看意向为1080px居中；车次详情内“发布设置”采用居中表单；确认承运复用1080px登记窗口，同窗补齐资料、核对并通过save-and-confirm一次保存确认，不追加独立确认框；取消采用现有确认框，明确对象和影响。当前新增操作没有外部原型，按用户授权、本文矩阵及已确认车次高密度样式实现，不能拿方便的抽屉替换。未保存提醒覆盖取消、X、Esc及路由离开；结果未知时保留原请求键和载荷。
+
+Admin本土订单池来源行增加“承运安排”只读入口（1080px居中），原编辑深链也只能展示只读原因和安排；正常独立订单保持原操作。关联车次/来货/排车跳转逐项检查目标权限，无权限只显示业务号。Client沿原详情展示同一客户摘要，不新增公开池。两端同步散板新状态标签和筛选，不能显示裸内部状态码。
+
+未知预计箱数与预计实托数的可空类型须同步既有bookingTypes、tripBookings normalizer、TripBookingPanel及对应测试，旧面板不得把pool询价解析失败或自动补成1。池来源确认/修改操作同样使用服务端允许动作；管理面板不得将未完成商业关联的旧确认视为成功。
+
+样式复用Admin高密度、integrated DataTable、操作列左置、统一查询/分页/按钮/错误态；不接入演示假数据。Client只在自己的订单响应中增加承运安排摘要，沿既有列表详情展示，无新公开拼车菜单。
+
+| 操作 | 业务请求预算（登录/公共外壳另计） |
+| --- | --- |
+| 任一页签进入/切换/查询/重置/翻页 | 每动作1次活动页签分页；不预加载另页签，不逐行查询车次或容量 |
+| 打开发布详情 | 1次详情，含分段余位和获准意向首20条及total/page/size；后续翻页各1次 |
+| 打开登记表单 | 复用详情事实；客户候选首次聚焦/搜索才请求，输入防抖，取消迟到响应 |
+| 报价候选 | 仅用户显式查询/翻页各1次，走池作用域专用候选接口；无报价权限0次，手填价不附加报价权限 |
+| 确认/修改/取消意向 | 1次写命令返回新摘要；必要时最多1次当前详情刷新，不全表逐项刷新 |
+| Admin/Client本土订单列表/详情 | 仍各1次，不逐单补查运力或预订；Admin行内打开已有承运摘要额外0次 |
+
+加载时保留上下文；区分无发布、筛选无结果、本人无意向、候选为空及接口失败；网络错误显示诊断和重试，不伪装空数据；版本冲突要求重新核对；写入处理中禁重复提交。切页/关闭/切发布时忽略旧响应。筛选重置和页码watch只能有一个实际加载入口，避免重复请求。真实请求计数包含非第一页重置、快速切页和写成功后的刷新，不能只测首屏。
+
+普通运力列表由数据库执行起运仓、目的地、日期、状态和文本筛选及分页，仅核对当前页的实时容量。显式启用`canConfirm`接单资格筛选时，先统计基础筛选后的候选；超过100趟即返回缩小起运仓、目的地或日期范围的提示，不展开逐车容量查询。100趟以内计算实时资格并返回精确总数，不能按当前页过滤后伪造总数或在后台扫描全部车次。
+
+## 8. 实现归属与部署
+
+Backend仍归Lastleg，Gateway复用现有fleet/last-leg通配路由；按API变更执行gateway-route-contract。新增持久化Mapper须显式@Mapper并跑注册合同。数据库基线、权限种子和测试环境差异SQL统一维护，不清库、不重复执行已成功未知结果SQL。
+
+部署单元预计Lastleg、Admin及受DTO展示影响的Client；IAM若仅新增库内权限种子则核对实时权限刷新，不无故部署全服务；必要时按实际依赖补充清单。TEST单机Maven只使用现有锁及单执行器，禁止并发构建挤压服务。部署与数据库写入由当前对话串行操作，内部协作仅分文件实现与只读/离线核对。
+
+## 9. 必验场景
+
+### 冻结的接口和实现分工
+
+服务前缀为`/api/platform/v1/last-leg/fleet/capacity-offers`；Admin浏览器HTTP基址已经含`/api`，消费路径省略该前缀，避免重复。新增接口沿既有Lastleg Gateway路由，不暴露内部接口。
+
+| 方法与相对路径 | 语义 |
+| --- | --- |
+| GET / | 当前用户获准的发布分页，含逐目的站余位和资格；text起运/目的地、日期、状态、可接筛选 |
+| POST /，PUT /{offerNo} | 调度创建发布草稿及编辑公开信息，校验车次/发布版本 |
+| GET /{offerNo} | 发布详情及获准意向首20条；非OPEN仅调度或本人已有意向者可读受限投影 |
+| POST /{offerNo}/publish、pause、resume、close | 显式发布状态命令，版本和持久幂等 |
+| GET /inquiries，GET /inquiries/{bookingNo} | 本人意向及单条详情；调度可选择全部范围，销售不能用参数越权 |
+| POST /{offerNo}/inquiries，PUT /inquiries/{bookingNo} | 登记/编辑草稿，登录人冻结销售负责人 |
+| POST /inquiries/{bookingNo}/confirm、cancel | 调度成交与适用范围的取消，唯一桥及容量事务 |
+| GET /customer-options | 用途限定ACTIVE客户ID/编号/名称目录，不返回联系人或电话 |
+| GET /{offerNo}/quote-candidates | 公开给该场景的销售报价候选，需额外quote:list，按本车及客户/卸货站/币种/计价方式过滤 |
+
+offer写入携带tripNo、tripRecordVersion、存在时offerRecordVersion、cutoffAt、公开联系信息、remark和idempotencyKey；意向含offer/trip/booking版本、customerId、businessType(LOCAL_LOOSEBOARD/US_TRUCK)、deliveryMode(SELF_DELIVERY/MANUAL_PICKUP_TO_WAREHOUSE)、estimatedArrivalAt、独立expectedPalletCount、cargo、quoteRef、idempotencyKey。Cargo.packageCount可空，确认前完整校验；可空不以虚假默认数替代。对象主身份使用发布号、预订号等业务编号；ID仅用于明确接口关联。
+
+Admin路由：`/overseas-master-data/capacity-offers`及`/overseas-master-data/capacity-offers/:offerNo`。菜单与路由允许list或manage；销售写另需对应inquiry权限。客户端不增加运力路由。
+
+持久化：每trip唯一`ll_fleet_capacity_offer`、持久命令记录（作用域/动作/键/请求hash/原结果）、预订新增发布/销售负责人/业务类型/交货方式/预计到仓/独立实托数字段、唯一`ll_fleet_pool_order_link`。桥表booking_id、booking_no、(business_type,business_order_id)唯一，incoming_no/lastleg_order_id为nullable unique；来源未发生保持null。不得只保存“最后一次键”而丢失旧成功请求的重放事实。Mapper/基线/统一空库SQL/本轮精确结构补齐/权限种子分别核对，无清库、存量修复或双写兼容。
+
+实现分工：运力池工作包独占fleet发布及预订服务和其测试；订单桥工作包独占fleet/business、商业订单/来货/实际作业回写及其测试；前端工作包独占业务页面/API/types/tests和矩阵。当前对话集成共享路由/导航/权限、SQL、OpenAPI与部署。跨包调用FleetPoolOrderBridge在已有事务中执行，不另开事务、不双写费用；源码签名先在实现者间固定，禁止两个工作包同时改同一服务文件。
+
+### 验收用例
+
+1. 自有18/总30，同路段外接8确认后余4；另一客户再确认5失败，原已确认事实不变；重量或体积先满同样拒绝。
+2. 两名调度同时确认来自不同销售的最后余位意向，最多允许容量内的承诺；销售自身调用确认必须拒绝；原键重放不增加订单、预订或费用。
+3. 两个不同登录账号但同姓名仍相互隔离；销售猜测他人意向编号、调用调度确认或车次敏感接口被拒绝；Client不能查看运力池。
+4. 暂停、关闭、截止、发车/取消、改派/路线/自有货变化、车辆停用/缩容均不能沿旧余位继续接单。
+5. 意向到本土订单/来货/排车/派送保持同客户和唯一来源；实收超量阻断、预订转实载不双扣、允许的取消释放且不删除事实。
+6. 本土散板和本土卡车分别从池内成交走到签收，本土订单真实终态回传；不制造第二张虚假尾程来源，不重复收费。
+7. Admin按调度和销售最小权限、Client按本票客户，在1920×1080检查列表、详情、表单、加载/空/错态、动作门禁和网络请求次数；保留截图与脱敏网络计数证据。
+8. 保留当前车次自有货链的核心回归：审核、拣货、改派后复审、整车发车、签收及资源分别释放；新需求池不得旁路这些规则。
+
+## 10. 五轮审核记录
+
+每轮必须有实际发现、修订和复核依据，前一轮改完再检查下一轮；五个“通过”标题不能代替审核。五轮结束后冻结开发版，发现实现与合同冲突仍须修正并补测。
+
+| 轮次 | 检查重点 | 当前记录 |
+| --- | --- | --- |
+| 1 | 用户范围、池的对象、延期功能与现有实现差距 | 已识别“车次余位池”被误解为“待配货客户需求池”的偏差，纠正为每车次发布、销售从具体车次登记；三种完整愿景与统一我仓首版分开；不引入沿途提货门禁改造 |
+| 2 | 容量/并发/权限/状态与车辆实时事实 | 审核V1后修订V2：补齐统一锁序、暂停与确认竞争、服务端截止及成功重放顺序、关闭后本人历史可读、池来源未登记来货才可取消、BOUND不重复扣位、旧接口旁路及事实指纹失效后显式恢复；依据FleetBookingService、FleetTripService.persist、capacityPlan及Reservations |
+| 3 | 本土订单唯一来源、实际履约、状态和费用 | 审核V2后修订V3：确认仅创建池来源商业单，散板不再建独立占位来源；新增唯一桥、来货反绑、实托/托位分离、真实状态回写、旧手工入口和来货取消防旁路、唯一运费来源及回传不反向锁车次；依据LocalLooseboardService、UsTruckOrderService、FleetIncomingAdapter、DeliveryTransfer及国内完成事件范围 |
+| 4 | Admin/Client交互、最小权限、请求预算与验收 | 审核V3后修订V4：补独立我的意向历史入口、Admin本土单只读承载、offer/inquiry/fleetArrangement专用投影、可空箱数直接消费者、两端状态标签/筛选、逐动作请求预算/分页上限、未知与满位区分、完整弹框关闭保护；按现Trips/Booking/TransportOrders及Client消费者核对 |
+| 5 | 全文一致性、接口/SQL/权限/测试/部署可执行性 | 总核对V4并冻结V5：去除“任意既有单关联”残留，明确关闭终态与显式恢复；补接口/字段/路由及数据库唯一约束、持久重放、实现归属；Admin/Client请求预算统一，测试覆盖两类商业单、权限及取消旁路；本轮只授权TEST，部署与浏览器证据不由文档通过替代 |
+
+### 预约侧可直接使用的来源解析边界
+
+`FleetPoolSourceResolver.resolve(List<SourceRef(customerId, bookingNo)>)` 在同一服务内批量只读，每次最多100条；返回 bookingNo、tripNo、bookingStatus、warehouseId、destinationKey/Label、incomingNo、lastlegOrderId、businessOrderNo、fulfillmentStage 和登记recordVersion。未成交也保留登记来源；没有对应别名时返回null，不能计作另一票货。不返回私人联系方式。调用侧先校验每个来源的权限；不匹配客户或不存在的来源不返回，调用侧须比较请求/返回集合并提示缺失。
+
+本侧期望预约覆盖以 `customerId + bookingNo` 查询并返回同一键、覆盖状态、预约业务号/确认号列表、缺项、sourceVersion及changeReviewRequired；别名由上述解析入口提供，预约侧负责归一化及货量去重。实际生产者签名由预约侧确定后本侧接入，不使用假覆盖结果。
+
+来源解析补充：`Source` 同时返回 nullable `packageCount`、`expectedPalletCount`（均为预报，不是实收）、`estimatedArrivalAt`（数据库UTC LocalDateTime，到我仓预计到仓，不是目的地预约）。货量未知保持null。
+
+B接受由A在 `appointmentplanning` 公开包建立唯一预约覆盖生产者。建议Java入口 `AppointmentCoverageQuery.query(List<SourceRef>)`，SourceRef为customerId、sourceKey（BOOKING:业务号或ORDER:订单标识）、destinationKey；结果以相同键返回status、appointments（预约业务号/外部确认号/确认时间）、missingFields、sourceVersion、changeReviewRequired。必须按同客户正式别名归一化；无真实货件资料可返回待补，不可伪造已确认。B在生产者存在后消费其公开DTO/服务，不维护第二套覆盖判断；若A采用不同签名，以A公开实现和测试为准收口消费者。
+
+### 共用准备和连续处理接口定稿
+
+- `POST /fleet/trips/prepare`：新建（计划、车辆、司机、排车单）或加入已有车次（车次号、版本、排车单）两种输入互斥；一次事务全部完成，失败不留下半成品车次。持久幂等复用现有命令记录，重试不得重复建车。共用UI `TripPreparationDialog`参数为warehouseId、warehouseName、dispatchNos，通过模块index.ts导出，实际仓库/来源由服务端再校验。
+- `GET /fleet/trips/{tripNo}/dispatch-candidates`：本仓、未绑定、未开始执行且无其他车次外接承诺的候选，数据库分页；`TripDispatchSelector`替代手填编号。
+- `POST /capacity-offers/inquiries/{bookingNo}/save-and-confirm`：同窗核对后一次命令更新资料、创建商业关联并保位，全部回滚或全部成功，保持原MANAGE权限；不自动生成来货。
+- 原登记下`/fulfillment`按需只读本票；`/incoming`、`/receipt-confirmation`和`/arrange-dispatch`分别明确安排来货、确认实收、排入本车。池manage并不自动获得原车次booking-edit/booking-confirm/trip-edit或智能排车权限；服务端和前端同时校验对应权限。
+- 实收排入优先复用唯一的同客户同来源完整排车；没有时使用真实实收计划托盘调用原预排。多张、混入其他来源、实收不完整或被其他车次绑定时整体拒绝。不创建假库存，不自动改配，不重复扣减预留；关联后旧容量失效须核对，审核/装载/发车仍独立。
+- “待我处理”使用scope=TODO，仅调度可读；未完成候选超过100条要求按客户或登记号缩小范围，实时投影后返回准确total并分页，普通列表仍数据库分页。仓库尚未实收的记录由仓库负责，不混入调度核量待办；收货阶段以批量权威状态读取，不逐行请求详情。
+- 后续输入/返回和权限完整定义在`baiyue-firstleg/lastleg-service/src/main/resources/openapi/fleet-preparation-v1.yaml`；本次复用现有表，无新增SQL结构或权限码。

海外仓业务/外配业务首版开发契约.md

@@ -0,0 +1,39 @@
+# 外配任务开发契约
+
+## 已确认业务边界（2026-10-21更新）
+
+本页是原排车装车后实际接入拼车货物的运营视图，与自有业务按是否实际拼车区分，不按车辆归属区分。仅显示 ACTIVE 且 AFTER_LOADING、DELIVERING、DELIVERED 的原排车，一单一行，多个目的地、预约在行内展开。自有车辆、档案外配车辆、临时外配车辆均可进入；车辆信息继续读取原装车证据，不在GET回填旧样本。原排车四页签及履约流程不变。
+
+实际拼车判定复用原关系：`ll_fleet_external_booking.offer_id`非空、状态BOUND、有实收确认，且trip_id/dispatch_no指向本车；来货客户和入仓来源须在本车真实计划托盘组成中，实托已关联且货物箱数为正。只发布余位、询价、确认占位、未排入的实收、已取消或移出本车的货物不计；非需求池来源的普通外接登记和多客户同车本身也不计。用EXISTS判断，至少一票即整车归入外配任务，多票不得重复计数。自有入口使用相同条件的否定；列表、全量统计、详情和运营操作保持一致。装车后货物不能普通增删，已绑定预订不能普通取消；复用这些现行门禁及关联事实，不新增分类持久化或回填链路。
+
+用户本轮明确批准：后台登记整车承运金额，单价为金额除以实际物理托数；保留逐目的仓实际到达时间和五个装车照片位，省略实际里程、油耗与两个油耗照片位。不实现原型的自有货/外接货拆分成本或自动分摊、应付/支付；不增加报价、派单、改派或异常状态机。异常仍按已确认的线下处理规则。
+
+沿自有业务已确认的计划发车日期筛选、完整筛选统计、三阶段、物理托盘去重、币种 CNY/USD 显式选择、金额零值与空值区分、两位单价及版本/原键恢复约束。承运商、车牌、司机电话来自原资源快照；临时外配 vehicleId 为空合法，缺承运商显示“—”，不猜当前档案。装车及运营信息不推定真实签收。
+
+## 共同接口与承载
+
+- API 前缀 `/api/platform/v1/last-leg/fleet/outsourced-business`；前端路由 `/overseas-master-data/outsourced-business` 和 `/:dispatchNo`；权限 `platform:fleet:outsourced-business:list/edit/upload`，查看含详情、历史及已授权照片读取。原权限与客户隔离不放宽，外配权限不能调用自有 API，反之亦然。
+- list/detail/history/operations/photos/commands 八类路径及请求方法沿自有业务结构；查询字段与同筛选四项统计相同，不拿当前页算总数。公开标识只用 dispatchNo，后台权威金额与托数计算，不逐行 GET。
+- 外配 DTO 单独明确表达精简字段：`operations={money,arrivals}`，无实际里程/油耗；`vehicle={vehicleId,plate,ownership,carrierName}`，vehicleId 可空；`photoSummary={loadingCount}`。其他 Row/Detail/History/Command 字段及版本语义沿已确认自有合同，附加与原主单版本独立。后台拒绝本域不支持的油耗写入/照片槽，不能仅前端隐藏。
+- 五框枚举为 LOADING_SCENE、LOADING_LIST、PRE_DEPARTURE_CHECK、DRIVER_LICENSE、RECEIPT；复用已经发布的原排车装车照片 File 分类，不新增 File 分类。上传与绑定分开，multipart 内 file/idempotencyKey，未知停写、绑定失败复用原 fileId 与原键。
+- 详情三个彩色图标页签：任务与车辆信息、路线货物与凭证、操作记录。运营登记和照片居中弹窗沿现有组件规范；照片只有装车五框。列表操作列第一列；缺值明确“—”，无 GPS/ETA 样例。
+- 复用四张附加表及原装车捕获；服务端按实际拼车分类与可信入口限定业务访问，原车辆冻结证据只保证真实车辆信息。vehicle.ownership允许OWNED/DISPATCHED，不能固定返回DISPATCHED。本次不扩展两页运营表单及照片槽，本域不新增业务表、不改原主单/库存/财务。
+
+## 本批职责与验证
+
+总控为当前 TEST 对话 `01a15230-a9d6-7503-a8a9-d70691df49e5`，工作区保持 `C:/Users/BY-OY/Desktop/code/chongchong-global`。复用用户明确指定的三个独立对话，不创建新对话。
+
+- 排车派送与费用后端 `01a1524f-56a9-7320-a5fd-8ff76fa4356b`：外配后端唯一实现者；可写 `fleet/outsourcedbusiness/`、直接测试和本域独立 OpenAPI；为复用原附加记录，允许定点调整 `fleet/ownedbusiness/` 的公共内部作用域/查询/命令服务及其直接测试，保留自有公开合同和已有行为。不得写 dispatch 主流程、File、IAM、共享 SQL、导航或其他后端域；共享触点交根。先返回计划改动路径和共同 DTO 确认，再按本契约实现。
+- 排车前端与 PDA `01a1524f-52c7-7cc3-9b08-d34ad24c172a`：外配 Admin 页面、组件、类型、API 及直接测试；不得改自有在途生产组件或共享导航/路由/权限。先做显示与交互，再按后端真实合同接线，禁止 Mock/Fixture 进入实际页面。
+- 排车后端 `01a1524f-4f11-70c2-8a46-8e06e73a2d86`：本批转为自有发布候选及 HTTP 验收专项；共享环境只在根明确交接执行窗口后写入，不与根同时发布或造数。
+- 根唯一维护公共契约、导航/根路由/权限/SQL/API 门禁、发布和集成；自有固定发布对象 `7c6a3af473e892a7e244ddc0b88cf00ca5708a7d` 与后续外配源码分开核实，不夹带在途外配进入本次自有发布。
+
+测试经 local-check，先受影响回归、同批统一门禁；同时覆盖自有不回归、两类外配身份、缺快照、三个阶段、多客户同托、多目的地、完整过滤统计、金额清空/零值/两位单价、到达、五图历史/授权/幂等，以及油耗写入拒绝。实现完成、检查通过、TEST 发布、真实 HTTP 与1920×1080、100%人工页面验收分别记录；下节记录已交付的实现与验证，最新运行及HTTP事实只查部署主契约，不将准备阶段状态当作当前状态。
+
+## 本轮实现、验证与执行交接
+
+首版已交付：前端19个新文件，摘要`e33793d079d06010a8c221eaebb337424988489ce77ea14b0f3a60aa89c1efa2`；后端14文件，包含三外配生产类、内部固定作用域复用、独立OpenAPI及14个新增测试。根首次编译发现限定泛型的类型注解问题，已改为显式导入Arrival后复验。联合Maven82项全部通过，覆盖原自有35、scope10、外配合同4、原装车24及读适配/Mapper/schema门禁；IAM权限种子4项、Gateway/依赖联合34项通过，八公开路径及56条引用可解析，AGENTS索引1229项通过。
+
+前端36项定向、默认资源类型检查与构建通过。完整Admin461文件4144项中4094通过、50失败，来自其他在途客户选择器改造的三份OceanBooking/GlobalSmartLoading测试，本域及导航路由没有失败。不修改或发布这些在途文件，不标记完整全绿。外配最小24路径及23项直接依赖已与实际Admin#661一致核对，用户批准固定Admin`3f4021c0ab05b9811bbb193bf47ebb6e9bf4c5db`、Lastleg`9f3755f8e246f763054d1048e58ef52f7e0fca39`发布和三权限最小SQL；不新增表或重置数据。真实发布与HTTP结果唯一维护在部署主契约。
+
+用户进一步要求发布和联调也分配三个对话：56执行已授权IAM及Lastleg，52独立审IAM后执行Admin，4f在根交接环境窗口后执行自有/外配真实HTTP；根停止环境写操作，维护门禁、回执核对及调度。各任务修改新独占一次性发布/验收驱动，不相互覆盖根已冻结的驱动和原人工样本；未知写必须按原意图核对，不能自动重试。

海外仓业务/拼车数据入口与操作简化评估草案.md

@@ -0,0 +1,313 @@
+# 拼车数据入口与操作简化评估草案
+
+日期：2026-10-09；状态说明更新：2026-10-10。本文保留优化目标与评估依据，后续用户已授权按建议实施；已选定的开发规则以正式拼车契约为准，未选定建议不自动成为本批需求。
+
+**已确认的业务起点：已有车次，销售为余位寻找客户货物。** 本批围绕“选车登记 → 调度确认 → 安排来货 → 实收后排入本车”简化，不建设独立的待配货需求池。
+
+目标是让用户打开页面就能回答：**这票货保位了吗？现在轮到谁？下一步点哪里？** 同一份资料只录入一次，同一票货始终能从原登记记录跟进。
+
+本草案供业务评估和交付对照，不替代[内部拼车需求池首版开发契约](内部拼车需求池首版开发契约.md)。以下目标不表示均已实现；原文档整理阶段“仅修改草案、不启动开发”的限制已被后续实施授权替代。部署及验收结论以[测试环境单机部署与配置契约](../测试环境单机部署与配置契约.md)为准。
+
+与预约优化并行时，本文负责拼车接货和共用车次操作简化；[美国预约管理统一总览与优化方案](美国预约管理统一总览与优化方案.md)负责在途筹划、对外预约与变化跟进。跨方案职责、交接及先后顺序统一见该文[第九节](美国预约管理统一总览与优化方案.md#九-建议实施顺序与协同分工)，本草案不再维护另一套整链排期。当前已进入实施；拼车常用路径与预约扩展分别核对，不能以预约日历全部完成代替拼车易用性验收。
+
+## 评估先看这里
+
+**建议把用户操作收敛成两条路径：调度准备车次并发布余位；销售选车登记客户货物，再由原记录持续跟进。** 系统负责带出资料和关联单据，人员只负责需要业务判断的确认。以下为目标方案，具体边界见后文，不代表测试或灰度环境已全部具备。
+
+### 数据从哪里进来
+
+| 业务起点 | 用户从哪里操作 | 系统应带入什么 | 人员仍需确认什么 |
+| --- | --- | --- | --- |
+| 已有待运货物，需要安排车辆 | 排车列表选择合格货物，点击“安排车次” | 起运仓、所选排车单、客户归属和目的地 | 使用已有车次还是新建；车辆、司机、时间及多站顺序 |
+| 已有车次，希望利用余位接货 | 车次详情点击“发布拼车余位” | 本车路线、计划发车、有效容量及已有货物占用 | 交货截止、缺失资料，以及是否正式对外接货 |
+| 销售已有客户，想搭这趟车 | 拼车接货列表直接点击“登记客户货物” | 所选车次、起运仓、路线、截止时间；单一目的地自动选中 | 客户；多目的地时选卸货站，已知货量可先填 |
+| 客户确认要送货 | 原登记记录继续处理 | 已登记的客户、货量、报价及交货资料 | 调度确认承运；明确安排来货 |
+| 客户货物已实际到仓 | 仓库按原收货流程操作，调度从原记录查看 | 真实收货结果、原车次和订单关联 | 实收差异、容量和费用；确认排入本车 |
+
+**创建车次、绑定排车单，并不等于已经发布余位。** 在用户提供的车次截图中，路线仍显示“待确定卸货点1”，登记窗口也没有可选卸货站。这可以说明该操作位置缺少可选站点，但不能单凭截图判断是数据未补齐还是程序异常。目标交互应在车次准备时就列出缺项并提供“完善卸货站”，避免用户到登记窗口才遇到“无数据”。
+
+### 哪些操作可以省掉
+
+| 现有操作负担或需要避免的做法 | 建议处理 | 保留的业务边界 |
+| --- | --- | --- |
+| 为找入口先进入详情，再寻找登记按钮 | 在可拼车次每行直接放“登记客户货物” | 不符合登记条件时，原位置展示原因和下一步 |
+| 反复录入仓库、车次、目的地和已填货量 | 从来源带入，同一登记连续复用 | 来源变化后提示重新核对，不覆盖人工确认结果 |
+| 只有一个卸货站还要再选一次 | 自动选中并展示 | 多站时仍需用户选择 |
+| 初次接触客户就填写全部货量、价格和交货信息 | 先登记，确认承运前再补齐必要信息 | 未知数量留空；保存登记不保位 |
+| 再点一次“提交调度”才进入待办 | 建议省去；保存后调度可见，按缺项分配待办 | 页面明确告知保存后的可见范围 |
+| 确认承运后再手工创建关联本土订单 | 系统沿正式承运命令生成唯一关联 | 失败不能显示已保位，重试不能重复建单 |
+| 查找、复制、粘贴排车单号完成关联 | 使用合格候选；实收后按真实来源复用或生成并关联 | 来源冲突、部分已安排、候选不唯一时停止自动处理 |
+| 销售查看容量计算和全部专业单据 | 默认只看可接货量、当前进度、负责人和下一步 | 调度仍能查看容量依据和关联单据 |
+| 将承运、来货、排入、发车压成一次“完成” | 不建议省略这些事实节点，只简化各节点的录入 | 防止未到货就生成实收、未审核就发车 |
+
+### 最少需要填写多少
+
+这是建议目标，不是当前表单的实测字段数量。自动带入值也应可见，避免用户不知道系统选了什么。
+
+- **首次登记：**单目的地车次，最低只选择客户；多目的地再选择卸货站。允许同时填写已知货量，不强制分两次录入。
+- **确认承运：**只补缺失的货量、价格和交货资料，已填有效内容无需重填。托位、重量、体积的容量核验不能仅用其中一项替代。
+- **安排来货：**复用已核实的预计到仓和交货说明，只补本阶段缺项。没有可靠来源的到仓时间不能自动猜测。
+- **实收后排入：**展示实收结果和差异，正常情况下不手输订单号、来货号、排车号；有异常由调度明确处理。
+
+### 可行性及实施成本判断
+
+| 优化类别 | 初步判断 | 需要核对的关键点 |
+| --- | --- | --- |
+| 文案、字段分组、单站自动选中、列表直接登记 | 相对容易，优先改善可发现性 | 隐藏字段不能隐藏必填缺项；不同角色可见范围正确 |
+| 数据复用、角色待办、同一记录跟进 | 可行，需要页面与服务端共同提供事实 | 谁负责、缺什么、能做什么不能仅由前端猜测 |
+| 一次完成建车关联、补齐资料并承运 | 可行，但涉及多项写入，不能只合并按钮 | 全部成功或明确续办；并发、版本和原请求重试正确 |
+| 实收后复用或生成排车并关联原车次 | 可行，业务校验较多 | 实收来源唯一、库存真实、外接预留只替换一次、审核继续有效 |
+| 自动报价、自动选多站路线、自动改车或拆分运输 | 本次不建议默认自动化 | 商业承诺、路线和货物拆分规则需单独确定 |
+
+### 建议您重点评估的五个问题
+
+1. **业务起点是否覆盖日常工作？** 当前以“有车找货”为主；如果大量客户先报货、暂时没有合适车次，应另评估“待配货登记”，不能让这类货物被迫绑定一趟不确定的车。
+2. **保存后直接让调度看见是否合适？** 建议省去单独提交步骤；资料不全交销售补，资料齐全才成为调度承运待办。
+3. **确认承运前的资料是否都必要？** 第四节逐项说明阶段。评估时可调整采集时点，但涉及容量、价格和真实交货的必要信息不能直接取消。
+4. **承运确认与安排来货是否保留两个动作？** 建议保留，因为“答应接货”与“确定何时到仓”可能不是同一时刻；信息齐备时可以在同一窗口连续完成。
+5. **异常流程的覆盖是否足够？** 首批先覆盖正常接货、缺资料、满位、实收差异和重试；拆运、来货后的取消与跨车改配，需要明确业务规则后再扩展。
+
+建议先用第九节的新人操作任务验证常用路径，再决定是否扩展分支。不要仅按按钮减少数量评价效果，还要看用户是否知道“是否保位、轮到谁、下一步做什么”。
+
+### 本批范围收口
+
+先对照“选车登记 → 确认承运 → 安排来货 → 实收排入”验证少填写和连续处理。首次登记默认展开客户与卸货站；已知货量可展开填写，业务类型默认值明确可见并可在确认前调整。调度默认进入待我处理，销售默认进入可拼车次。原登记突出一个符合当前阶段和权限的主要动作，其余操作及关联单据放次要位置。
+
+预约覆盖作为必要关联结果保留；统一日历、船期变化影响及其他预约来源按预约方案单独交付，不作为继续扩大本轮拼车界面的理由。本文不宣称代码、部署或1920×1080验收已完成。
+
+## 一 简化方向
+
+1. **一个直白入口。** 建议菜单使用“拼车接货”；销售看到“可拼车次”和“我的登记”，调度直接看到“待我处理”及发布入口。保留现有菜单位置，不额外增加并列菜单。
+2. **一票货持续跟进。** 登记后从同一记录查看资料、处理当前事项和跟踪进度；本土订单、来货、排车等放入“关联单据”。不要求销售理解单据关系，也不再重复下单。
+3. **每次只突出当前要做的事。** 页面显示当前进度、下一步负责人、具体缺项和一个主要动作；其他合法操作保留在次要位置。
+4. **资料已知就能填，未知不强填。** 区分“现在必填”“确认前待补”和“始终选填”，不把后续必填统称为选填，不用虚假默认数补齐。
+5. **简化录入和关联，保留真实作业。** 容量校验、实际收货、调度审核、拣货、实测装载、理货审核及PDA发车继续有效。
+
+销售新增外部货源、等待匹配车辆的独立“先有货、后找车”登记、虚拟运力、自动撮合和实收后跨车改配不在本批。已有头程在途货的提前筹划属于预约方案，不受上述外部需求池边界排除；它仍须通过真实货源和排车资格进入共用车次能力。若以后业务改变，再单独评估，不让这些分支影响本次常用路径。
+
+## 二 首页让人一眼看懂
+
+### 销售看可拼车次
+
+一行一趟已发布车次，操作列在左，主要按钮为“登记客户货物”。默认突出以下信息：
+
+| 信息 | 展示要求 |
+| --- | --- |
+| 起运仓、目的地 | 使用业务名称；多目的地分别展示，不让销售猜哪一站能接货 |
+| 计划发车、最晚送仓 | 两个时间分别标注，不能只写含义不明的“截止”；最晚送仓对应现有交货截止，不另造一套时间 |
+| 可接货量 | 按目的地同时展示剩余托位、重量、体积，不用全车单一数字代表所有路段 |
+| 当前能做什么 | 可登记时显示登记入口；暂不能承诺但仍允许登记时，明确“可先登记，待调度核对，尚不保位” |
+
+展示示例，仅说明文案，不代表真实容量：
+
+> 目的仓 A：余 4 托位｜最多 2.5 吨｜18 m³；三项须同时满足。  
+> 可登记客户货物，调度确认承运后保留货位。
+
+未知容量显示“待调度核对”，已知满位才显示0。能否登记与能否确认承运分别由服务端判断，不能用“暂不可确认承运”代替销售的登记资格。暂停、关闭、截止等限制继续遵循正式契约。
+
+销售默认列表不展开分段计划占用、外接预留和容量计算过程，这些放入调度详情。业务单号及调度公开联系信息仍可查看；不得展示司机私人信息或他人客户货物。
+
+发布时调度核对交货截止，结合实际收货、理货和装载安排预留时间。当前截止默认与发车一致只是已有默认值，不代表来货可在发车时才开始收货；本批不凭空规定统一提前时长。
+
+### 同一登记记录持续跟进
+
+“我的登记”跨发布状态保留本人记录，车次关闭或已发车后仍能跟踪获准的历史。记录顶部突出“客户＋目的地”、车次业务号、当前阶段、是否保位及下一步负责人。
+
+当前可执行的资料补充、承运确认和来货安排尽量在同一处理窗口完成；需进入仓库或排车专业页面时，直接定位对应业务，避免重新搜索和输入编号，并提供返回原记录的路径。仓库继续使用现有收货页面和PDA，不另建一套作业入口。
+
+关联单据按权限提供链接，无目标权限时只显示业务号。底层仍复用同一意向、预订及正式业务关联，不新建另一张独立“拼车单”。
+
+## 三 常用操作路径
+
+```mermaid
+flowchart LR
+    A[调度发布本车余位] --> B[销售登记客户货物]
+    B --> C[销售补齐待确认资料]
+    C --> D[调度确认承运并保位]
+    D --> E[调度明确安排来货]
+    E --> F[仓库实际收货]
+    F --> G[调度核对实收与费用]
+    G --> H[确认排入本车]
+    H --> I[审核 拣货 实测装载 理货 发车]
+```
+
+资料已齐时无需再做一次补充操作。该图表示本票货的衔接，不要求整车所有货物齐备后才开始每张排车单的审核。
+
+### 销售登记与补齐资料
+
+销售直接从车次列表点击“登记客户货物”。先选客户；只有一个卸货站时自动选中并展示，多个站时明确选择。货量已知就填，未知允许先保存；多站不能替用户猜目的地。
+
+本批建议只有“保存登记”，暂不新增“提交调度”命令。**保存后调度可见，不是仅自己可见的私人草稿；保存也不保位。** 使用现有DRAFT及资料完整性，区分以下处理提示：
+
+- 资料未齐：显示“待补资料”，具体列出销售还需补充的内容。
+- 资料已齐：在调度待办中显示“待调度确认”；若容量、路线或资源存在阻断，则显示“待调度核对”及具体原因。
+- 已确认承运：才显示“已保留货位”。资料填齐不能替代承运成功。
+
+资料完整性、缺项和动作资格由服务端提供或按正式合同补充，不能只靠前端判断。它们是处理提示，不新增可手改的业务状态。若以后确需销售明确提交后调度才可见，须另行定义交接命令、权限和撤回规则，不能只增加一个按钮。
+
+销售负责补充客户货物预报、约定价格、交货联系人和交货资料；调度负责车辆、路线、容量及承运资格。有权限的调度可代补已核实资料，但不凭猜测代填。
+
+### 调度确认承运与安排来货
+
+调度从“待我处理”进入，在一个窗口核对客户、目的地、完整预报货量、约定价格与币种、交货安排及本车有效余位。已填内容直接复用；缺资料明确指向销售，缺容量或路线则由调度处理。
+
+点击“确认承运”成功后，系统保留货位并生成唯一关联本土订单，提示“已保留货位，尚未安排来货”。保存资料与确认结果分别反馈，不能把保存成功当成承运成功。
+
+“客户货物登记”和预约侧的“预约安排”是不同记录。确认承运只证明本车保位，不表示FBA/收货方已接受这票货；需预约的目的站应关联预约侧返回的覆盖结果，缺货件资料或需补充/改约时引导有权限人员处理。可预约阶段和核对时点在共同交接阶段确定，不能用现有登记DRAFT充当预约状态，也不能自行创建第二套收货预约。
+
+确定客户来货安排后，由有权限的调度明确点击“安排来货”，沿用客户、目的地、预计到仓和交货说明，补齐本阶段必要资料。承运确认不自动生成仓库待办；“线下安排提货回仓”只是交货说明，不表示系统已生成独立提货任务。
+
+### 实收后确认排入本车
+
+仓库按现有流程实际收货，系统展示预报与实收差异。调度核对实际货量、占用托位及约定运费；有差异先处理，不能以预报覆盖实收。
+
+核量完成后提供“确认排入本车”，整合合格排车单选择或生成及车次关联。成功提示“已排入本车”，并显示服务端返回的下一待办；通常仍需调度审核。**排入本车不等于已经装车或发车。** 后续审核、拣货、实测装载、理货和PDA发车继续按真实事实推进。
+
+## 四 字段按阶段展示
+
+| 阶段 | 默认展示和需要确认的内容 | 自动带入或延后 |
+| --- | --- | --- |
+| 首次登记 | 客户、目的地；已知的预报货量可直接填 | 本车仓库、路线、发车和交货截止带入；单站自动选中。单站时允许只选客户先保存 |
+| 确认承运前待补 | 箱数、托位、重量、体积、按业务类型要求的预计实托数、约定价格与币种、必要联系人和交货安排 | 已填内容复用；业务类型明确可见。收起时仍显示“确认前还差哪些项”，不得标成普通选填 |
+| 始终选填 | 货物备注及额外说明 | 收起展示，不挤占首屏；已知的后续资料仍允许提前填写 |
+| 安排来货 | 核对预计到仓、交货说明；私人地址补全必要收件资料 | 沿用客户、目的地、商业订单和车次关联，不重复建单 |
+| 核对实收 | 实收与预报差异、实际占用托位、实际约定运费及容量影响 | 箱数、实托、重量、体积来自真实收货；调度只补必要核对项 |
+| 确认排入本车 | 实际货物、目标车次及关联后的容量、审核影响 | 系统选择或生成排车并关联，无须手输编号 |
+
+“确认前待补”与“始终选填”分区显示，已填字段不重复录入。必要项按业务类型及正式契约校验，例如本土卡车确认前要求正数预计实托数。
+
+- 预计箱数、实际托盘数和占用托位分别表达，不能互相替代。托位可解释为“占用车上多少个标准托盘位置”。
+- 未知数量保持未知，不用0或1补齐；计费重量不能替代真实装载重量。
+- 仅从可靠来源带入默认值，允许查看来源；币种、计价方式、业务类型在确认摘要中可见。
+- 客户联系人不能取司机私人联系方式；客户候选目录也不应被假定包含联系人资料。
+- 来源变化时提示差异和影响范围；无效的路线、报价或容量须重新核对。
+
+## 五 当前进度、负责人和主要动作
+
+下表是目标展示示例，最终动作须同时满足实际阶段、服务端资格和当前用户权限；销售只处理本人获准记录。
+
+| 当前情况 | 谁处理 | 提示示例 | 主要动作 |
+| --- | --- | --- | --- |
+| 预报或成交资料不全 | 销售 | 待你补充重量和约定运费，尚未保位 | 补充资料 |
+| 资料已齐，等待承运决定 | 调度 | 待你确认是否接货，尚未保位 | 核对并确认 |
+| 路线或容量需要复核 | 调度 | 本车货物已变化，需重新核对余位 | 核对容量或路线 |
+| 承运已确认，来货未安排 | 调度 | 已保留货位，尚未安排来货 | 安排来货 |
+| 已安排来货，货物未到仓 | 销售跟进客户；仓库等待来货 | 已安排来货，等待实际到仓 | 查看来货安排 |
+| 仓库收货进行中 | 仓库 | 仓库正在收货 | 销售、调度查看进度；仓库沿原作业继续收货 |
+| 实收与预报有差异 | 调度，必要时销售联系客户 | 实收比预报多1托，待核对容量和运费 | 核对差异 |
+| 实收已核对，满足关联资格 | 调度 | 本票已核对，可排入原车次 | 确认排入本车 |
+| 已排入本车，审核待办存在 | 对应审核人员 | 已排入本车，待调度审核或理货审核 | 打开对应审核事项 |
+| 实际已发车 | 原派送作业人员 | 已发车，按实际派送状态跟进 | 查看运输进度 |
+
+同一事实对不同角色采用对应文案：销售看到“等待调度确认”，调度看到“待你确认”。无权操作时展示负责角色及进度，不以无权限按钮作为唯一下一步。
+
+非本角色待办仍可跟踪，但不混入“待我处理”。暂停、截止或关闭后不能继续编辑的登记，只显示获准的查看、取消等实际可用动作，不能一直提示销售去补一个已无法保存的表单。
+
+## 六 异常时也要知道怎么办
+
+| 情况 | 当前处理边界 | 页面应给出的下一步 |
+| --- | --- | --- |
+| 资料不足 | 未确认、不占位 | 列出销售待补字段，回到对应输入处；容量问题单独交调度 |
+| 满位或容量待核对 | 仍可登记时允许保存，禁止越过容量门禁确认承运 | 明确“尚未保位”；已知满位等待调度决定，计划失效由调度重新核对并按资格恢复接单 |
+| 发布暂停、关闭、截止或车次事实变化 | 按服务端资格限制登记、编辑和承运；发布关闭不等于取消已确认业务 | 说明具体原因，保留已登记业务跟踪；已确认承诺由调度核查影响，不宣称自动改车或恢复接单 |
+| 已确认但尚未登记来货，需要取消 | 由调度按正式命令一体取消预订、商业关联并释放占位 | 显示取消对象和影响，确认成功后反馈；不要求分别取消多张单 |
+| 已登记来货后需要取消或跨车改配 | 登记来货后，池内取消及跨车改配按正式契约明确阻断；不得通过旧来货取消入口旁路 | 明确限制及负责调度，保留原单据和库存；仅链接实际存在且允许的作业，不展示虚假的“去改车”按钮 |
+| 部分货物未收齐 | 本批不自动把一条意向拆到多车，不将未到货算成实收 | 仓库继续收货，销售跟进缺货；若客户确认不再送齐，交调度核查现有可用处理方式，不能直接点完收货 |
+| 实收超量或价格变化 | 重新核量，检查托位、重量、体积及费用；不能自动扩大承诺 | 展示预报、实收和差异，调度核对；超出本车容量时阻断排入，明确当前不支持自动改配 |
+| 已排到其他车次、来源不一致或候选不唯一 | 不重复创建排车，不把任意已有库存接成本意向 | 显示冲突业务号及原因，交调度核查；不自动解绑或绕过改配限制 |
+| 保存部分成功、超时或他人已修改 | 保存不等于承运成功，结果未知不等于失败 | 说明已完成步骤；未知结果保留原请求续试，版本冲突保留填写内容并要求重新核对 |
+
+不支持的动作要明确说明边界和负责角色，不能用笼统“查看待处理事项”掩盖没有处理能力的情况。
+
+## 七 调度准备车次与发布余位
+
+本批以已有车次为主，准备车次保留两种现有业务起点，不让销售参与车次资源配置。
+
+本节是两份方案共用车次操作的唯一设计展开处，由拼车/车次实施职责负责。预约页带入已核对来源后，复用同一候选、资格、建车/关联和发布入口；不另建表单、容量算法或写命令。预约筹划关联、外接确认保位、实收后正式排入本车分别通过各自资格，不能因共用入口合并门槛。
+
+- **已有待运货物：**在排车列表勾选合格排车单，点击“安排车次”，选择加入已有车次或新建车次。仓库、货物、目的地自动带入；车辆、司机、计划发车及预计任务结束由调度确认，多站顺序由调度确认。
+- **先有运输安排：**保留车次新建入口，再用候选列表添加本仓待运货物，替代查找和手输排车号。
+- **发布余位：**同窗展示自有货占用、有效容量和截止时间，只补缺失数据；明确“确认发布”，保留部分成功后的续办能力。
+
+不同仓库、已绑定其他车次或状态不允许的排车单不能混选提交。允许跨客户共享车次，但货物归属和每单审核独立。自动补齐卸货站不等于自动优化路线。
+
+无自有货、仅准备接外部货的完整发布能力仍需定向核对；不能用空货单假定已有有效的零占用计划。没有落实车辆、司机的虚拟运力不在本批。
+
+## 八 实施顺序与必要边界
+
+以下是拼车侧内部交付包，不是工期承诺或独立于预约方案的发布排期。第一批主要对应共同顺序的并行工作，第二批对应共用车次接入，第三批对应外接履约衔接；具体依赖以[共同工作包](美国预约管理统一总览与优化方案.md#工作包与先后依赖)为准。
+
+| 顺序 | 建议交付内容 | 完成判断 |
+| --- | --- | --- |
+| 第一批：先让常用流程走得明白 | 入口文案、销售简明列表、直接登记、分阶段字段、单站自动选择、缺项及角色待办、同一记录进度、来货资料复用；把合格排车单候选选择前移，减少手输编号 | 从选车到后续履约，每阶段知道是否保位、谁处理、从哪里继续；已有排车单可选择关联。无排车单时可直达现有作业，尚不能宣称已实现一键生成并关联 |
+| 第二批：减少调度的跨页准备 | 勾选排车单安排车次、同窗补齐资料并确认承运、准备与发布的连续操作 | 新建、分配、绑定或保存部分成功时能继续，不重复建车、建单或宣称占位成功 |
+| 第三批：整合实收后排入本车 | 一次业务操作复用或生成合格排车并关联，协调库存、预留替换、容量及复审 | 正常实收排入无需手工组织中间单据；异常、超时、并发及复审均有明确结果 |
+
+“确认排入本车”的已有排车复用必须同时满足：**同客户、同一真实来货来源、覆盖本次全部实收货物、未绑定其他车次，并通过现有库存及排车资格校验。** 没有合格排车时才按真实来源生成；候选不唯一或已有部分安排时先核查，不自动另建重复单。其他已有在仓货继续从正常待运货物入口处理，不导入任意独立订单或库存来拼接本意向。
+
+- 客户商业订单、来货及真实尾程来源保持唯一关联；外接预留转为真实货物计划占用时只计一次，不重复占位或收费。
+- 一次用户操作涉及多个写入时，需要相应服务端编排或明确的部分成功续办机制；承运确认中的订单创建与占位必须保持正式契约的一次命令，不由前端拼接成功。
+- 资料完整性、负责人提示和候选列表若缺少服务端数据，需补相应合同；不把全部优化误判为纯前端改文案。
+- 列表不逐行请求详情，详情和候选按需读取；写命令继续复验权限、版本、来源及资格。重复点击和未知结果重试不重复创建、占位或收费。
+- 直接外接预订是否有不经销售发布的独立用途仍需核对；本批保留入口，对池来源标记“来自拼车登记”，不强行合并不同业务来源。
+
+### 交给拼车与车次实施对话的任务说明
+
+- **目标：**完成本文选车登记、确认保位、安排来货、实收后排入本车的连续操作，并提供预约侧可复用的车次准备、容量和发布能力。
+- **先交付：**具体文件写入清单、货源/排车资格、逐站余位与发布资格的交接示例；明确外接预留如何在实收关联后被替换，并与预约侧核对外接货进入FBA预约的阶段和来源。
+- **独占业务：**销售登记、外接预订、商业/来货关联、车次与排车关联、容量和发布。预约候选/覆盖/确认结果由预约侧提供，本侧维护消费与跳转。
+- **依赖：**读取预约侧的来源关联、时间/材料摘要、预约覆盖及变更结果；共同接口确定后可以先做不依赖对方实现的表单和流程简化。
+- **交付物：**选定正式契约改动、受影响接口/类型/权限/SQL清单、实现与定向验证结果、供预约侧接入的实际入口，以及尚未部署/人工验收的事项。公共文件按共同分工交单一写入者整合后，本侧复验其业务。
+- **完成条件：**既有货源可通过唯一车次能力组织运输；外接货从原登记跟进到实际履约，确认保位/安排来货/排入/发车含义清楚，预留替换不双扣，不重复建单或收费，来源、容量、权限和失败重试均可核对。
+
+该工作包已由用户安排实施；环境操作仍按对应授权与统一执行窗口处理。
+
+## 九 用新人实际操作验收
+
+以下是建议验收目标，尚不是测得的效果。Admin按1920×1080、浏览器100%缩放，由人工操作并提供截图，AI核对证据；没有截图时标记“待人工截图确认”，自动检查结果单独报告。
+
+找一名未参与开发的业务人员，不先讲解“意向、预订、预排、绑定”的区别，让其完成以下任务：
+
+| 任务 | 应能独立完成的动作 | 应能准确说出的结果 |
+| --- | --- | --- |
+| 销售选车并登记 | 找到目的地、发车、最晚送仓及三维余位；单站自动带入，未知货量仍可保存 | 保存后尚未保位，调度可见；知道缺什么、由谁补 |
+| 调度确认接货 | 找到需要自己处理的登记，同窗核对已填资料和容量，再确认承运 | 已保位并关联本土订单；尚未安排来货时仓库没有因此收到新来货待办 |
+| 跟进实际收货 | 从原登记查看来货及收货进度，识别当前负责角色 | 知道是否需要自己操作；不把预报当实收 |
+| 实收有差异 | 看懂预报、实收和差异，找到核量及容量处理入口 | 知道超量为什么不能排入；不会误认为能自动改车或拆运 |
+| 确认排入本车 | 按当前实施批次选择已有合格排车，或使用已实现的生成并关联操作 | 已排入不等于已装车、已发车；知道下一审核或作业环节 |
+
+每次操作前让试用者回答：**保位了吗？轮到谁？下一步点哪里？** 记录答错、停顿、求助、重复填写、跨页找单和复制编号的位置，再据此调整，不预先承诺节省比例或完成时间。
+
+同时检查以下底线：
+
+1. 主操作和下一步提示首屏可见；后续必填与选填能区分，缺项不藏在笼统的“补充资料”里。
+2. 单目的地不重复选择；多目的地不自动误选；所有数量未知与0分开，容量三项及各目的地口径正确。
+3. 已保存且有效的客户、目的地、到仓及交货信息沿链路复用；业务编号用于识别，不把内部ID显示给用户。
+4. 第一批已有排车选择无需复制编号；第三批正常实收排入无需另行查单建单。各批按实际交付范围验收，不提前声称全链已打通。
+5. 满位、暂停、过期、路线变化、实收超量、冲突和结果未知均给出具体原因及实际可用动作。
+6. 确认承运只生成一份关联商业订单；重复操作不重复创建、占位或收费；取消和改配不越过正式边界。
+7. 每单调度审核、真实收货、实测装载、整车理货审核和PDA发车门禁继续有效。
+
+## 十 当前数据关系与实现依据
+
+当前“拼车需求池”是已发布车次的余位目录；尚无独立待配需求池。本节用于开发定位，不要求销售学习这些对象。
+
+| 当前对象 | 沿用关系 |
+| --- | --- |
+| 排车单与车次 | 多张客户排车单可关联共享车次，各客户归属及审核保留 |
+| 运力发布 | 每车次一条发布，余位依据有效计划和已确认外接占用计算 |
+| 客户意向与外接预订 | 复用同一预订，保存发布来源和销售负责人；未确认不占位 |
+| 本土订单 | 确认承运时自动生成唯一关联订单，不需独立再下单 |
+| 外接来货 | 由明确操作创建，关联真实收货来源及库存，不能以预报代替实收 |
+| 外接货排车 | 实收核量后关联原车次，由真实计划占用替代外接预留，不能重复扣减 |
+
+当前已有单站匹配、容量与发布同窗、未知货量暂存和承运自动生成本土订单等能力。主要待优化的是同时展示过多字段、角色待办不清、跨页查找编号，以及实收后的连续处理；这些调整不能仅凭既有接口存在认定已完成。
+
+- [内部拼车需求池首版开发契约](内部拼车需求池首版开发契约.md)：当前范围、权限、容量、订单及取消规则。
+- [海外车辆模块指引](../../apps/admin-web/src/modules/overseas-master-data/AGENTS.md)：车次、预订及履约入口。
+- [拼车列表](../../apps/admin-web/src/modules/overseas-master-data/pages/CapacityOffersView.vue)：当前销售列表、字段与资格展示。
+- [车次计划表单](../../apps/admin-web/src/modules/overseas-master-data/components/TripPlanDialog.vue)：当前建车与路线输入。
+- [意向表单](../../apps/admin-web/src/modules/overseas-master-data/components/CapacityInquiryDialog.vue)：当前同时展示的字段及保存操作。
+- [外接履约窗口](../../apps/admin-web/src/modules/overseas-master-data/components/TripBookingFulfillmentDialog.vue)：当前来货、实收及手填排车号关联。
+
+进入开发定稿时，将选定的交互、字段责任、资格投影及实施范围同步到唯一正式契约；本草案不作为已实现或已验收证明。

海外仓业务/排车列表前端原型核对.md

@@ -0,0 +1,369 @@
+# 排车列表前端原型核对
+
+## 本轮范围与结论
+
+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预约 | 当前原生dispatchInfo提供路线、实际发车和逐批FBA预约；车辆预约字段及关联已按用户最新裁定移除 | 路线由货物目的地真实事实生成，不手输演示“30托盘”；发车只显示实际时间。多目的仓FBA预约按真实逐目的仓/批次事实展示，不能显示一个仓已约即全车已约。 |
+| 单据信息 `📝` | 排车单号、关联派送单、创建时间、更新时间、备注 | `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或写环境数据。新增日历预约及车辆预约权威提供者不在本前端包。
+
+## 当前候选：取消排车车辆预约及完整构建复验（2026-10-19 19:03）
+
+用户最新确认取消排车信息中的车辆预约字段及关联；FBA预约保留，详情仍严格为车辆信息、排车信息、单据信息、关联订单明细四个彩色图标页签。改动为API、模型、详情及直接样例/测试共8文件，精确清单与逐文件SHA在根`.codex-temp/dispatch-remove-vehicle-appointment-20261019.json`。总控已逐项核对8/8无漂移，聚合为`f256c5a71bc67ad146702a28d30d7da0579fc69bb4ea92642c7f47ea44835957`；4文件73项定向测试通过为前端执行证据。
+
+完整类型检查先在2GB下OOM，启用节省内存选项仍OOM，均不计通过。用户随后明确授权本次完整检查临时使用4GB；总控经local-check执行`node --max-old-space-size=4096 --optimize-for-size ./node_modules/vue-tsc/bin/vue-tsc.js --noEmit --pretty false`，实际退出0（工具输出ef45f8）。随后恢复正常2GB限制，单独执行`pnpm exec vite build`，实际退出0，5135模块、Vite4.06s（工具输出79545d）。两步共同证明当前输入的完整类型检查与打包通过，没有排除测试、修改tsconfig或提高后续检查默认内存。上述结果不清除早前全量测试超时，也不代表真实页面、HTTP或PDA硬件验收。
+
+日历新增预约仍归用户指定的其他对话，本批不接管。17:38候选的提供者缺失描述仅表示当时输入，当前公共字段/版本以最新主契约、Java和实际检查为准。

海外仓业务/排车列表接口与数据设计.md

@@ -0,0 +1,659 @@
+# 排车列表接口与数据设计
+
+> 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和DispatchInfo均无该属性，不输出空占位。FBA预约及真实批次继续按原权威核验，日历新增预约不在本批范围。
+
+新增实际种子及端口见 `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` 保留真实客户与完整逻辑来源键，引用独立物理占用 `ll_dispatch_physical_pallet_lock`。活动实托唯一键只属于物理层；逻辑层不保留 `active_warehouse_pallet_id` 空别名。同一拥有者的多个真实来源可共享一个实托，跨主单、跨草稿容器仍排他。物理拥有者是主单或原草稿容器，不以第一条来源或第一客户代表。释放逻辑来源后，只有本拥有者最后一条活动成员结束才释放物理占用；取消、到期与转换不能触碰后续新拥有者的占用。
+
+#### 2.3.1 同实托多换标来源的共同读取合同
+
+本批支持两张换标单合到同一实托后整托同车。物理托盘、实载重量体积和实际容量只计一次；客户、换标业务号、逻辑箱数、真实扫码与费用归属保留分行。既有整申请全部应排托盘规则保留，因此完整选货集合是“申请包含的全部应排托盘”与“实托包含的全部有效逻辑来源”共同形成的闭包。不得只依据页面当前筛选结果或托盘展示号拼组。
+
+`DispatchPlanningModels` 的冻结参数顺序如下，无旧签名兼容构造器：
+
+```java
+SelectionGroup(String groupKey, String groupVersion,
+    List<SelectionGroupSource> sources, List<SelectionGroupPallet> pallets,
+    boolean complete, List<String> blockReasons)
+SelectionGroupSource(CargoSelection selection, String sourceKey,
+    String customerId, String customerName, String sourceBusinessType,
+    String sourceBusinessNo, long packages)
+SelectionGroupPallet(Long warehousePalletId, String palletNo,
+    List<String> sourceKeys, long packageCount)
+Candidate(CargoSelection selection, String sourceKey, String sourceVersion,
+    String customerId, String customerName, String warehouseId, String warehouseCode,
+    String warehouseName, String orderNo, String inboundCode, String planNo,
+    String palletNo, String containerNo, Destination destination, long availablePackages,
+    BigDecimal suggestedWeightKg, BigDecimal suggestedVolumeCbm, String measurementSource,
+    List<BatchReference> appointmentBatches, List<String> blockReasons,
+    SelectionGroup selectionGroup)
+```
+
+`selectionGroup` 由服务端完整来源事实生成；缺失组、缺少组版本或 `complete=false` 都不构成完整可选证明。组版本绑定全部成员及来源版本、换标完工/确认轮次、实际位置和组成；不得用单条来源版本冒充组版本。页面选择组后，`Create/AddCargo.cargo[]` 仍显式提交组中全部逐来源选择；服务端在锁内重算闭包并核对精确集合。草稿 `DraftSelection.source` 请求形状保持，单次加入/移除命令由服务端原子处理完整组并返回全部成员，不由前端循环单来源命令凑组；容器布局与正式转换不得拆开同一完整组。
+
+草稿解除、释放及纯租约动作使用原冻结实托集合先取得共同串行行，再读取逻辑成员及物理拥有者，避免与到期接管的物理→逻辑顺序交叉。来源事实变旧不妨碍合法拥有者释放原占用；这些动作不新增当前来源资格条件。选货、布局和转换仍先锁完整申请/订单，再取得共同实托锁。
+
+`DispatchViews` 的冻结参数顺序如下：
+
+```java
+PdaItem(Long dispatchItemId, String customerId, String customerName, String palletNo,
+    Destination destination, long scheduledPackages, long pickedPackages,
+    List<Position> positions, List<ReturnCarton> returnCartons,
+    String sourceKey, String sourceBusinessType, String sourceBusinessNo)
+OrderDetail(String customerId, String customerName, String orderNo, String inboundCode,
+    BigDecimal grossWeightKg, Integer palletCount, String destinationFbaWarehouse,
+    BigDecimal volumeCbm, String containerNo, String sourceKey,
+    String sourceBusinessType, String sourceBusinessNo)
+```
+
+来源业务号直接取真实 `sourceBusinessNo`，换标来源为对应换标申请号；普通来源无该业务号时保持空，由页面显示“—”。不得解析 `sourceKey` 或以内部 ID 回退。PDA 保留逐 `dispatchItemId` 的既有 `Pick` 形状，不改为整托一次多写；同托多来源必须辨明逻辑来源，所选位置的额度和不可变拣货归属按本来源核对。`CargoSelection` 形状不变。
+
+`LoadingPreview.pallets` 按实际 `warehousePalletId` 一托一行，计划箱数、已拣箱数为该实托各逻辑来源合计。不得把同一整托重量体积复制给每条逻辑 `CargoLine`；逐来源没有真实测量时保持未知，不按箱数分摊。现有同实托目的地一致、整申请排车、退货箱隔离和重做轮次规则保持，不引入拆托卸货或第五个详情页签。
+
+普通换标贡献须保留逐 `RelabelItem` 的原货源快照与实际绑定位置。`application.lastlegOrderId` 可为独立申请生成的换标履约单，不等于所有原货源订单。工作事实先按申请和 item 聚合再关联，通知箱数不冒充成功箱数，成功/异常结果和新旧箱唛保留。无真实 SKU 件数时不能从箱数推算件数。原生退货继续使用真实退货箱及已有转换事实，不能伪造普通库存位置或收货凭据。
+
+新增物理占用与来源贡献表后，`scripts/fleet-trip-rollback-test-env.mjs` 的全字段数据库基线也是直接消费者，必须纳入新事实后才可继续声称完整回滚；当前已验收脚本版本保持独立冻结，不与来源模型实现同时修改。
+
+PDA 每车一个平台作业 task，删除 task 的 customer 头部；pick 与 pick_order 继续每条真实客户。task 业务号沿正式编号生成器生成，不能继续 `DPDA + 内部ID` 展示。主流程操作/幂等归平台整车，不借客户表承载。
+
+#### 2.3.2 换标贡献提供者的内部Java合同
+
+提供者入口为 `relabel/port/RelabelDispatchSourcePort.java`，实现分别位于 `relabel/service/RelabelDispatchSourceService.java`、`relabel/repository/RelabelDispatchSourceRepository.java`、`relabel/mapper/RelabelDispatchSourceMapper.java`，保持 Service → Repository → Mapper。dispatch 只消费公开port，不直读换标持久化实体。方法与嵌套record参数顺序如下：
+
+```java
+Snapshot snapshot(String warehouseId, List<Long> warehousePalletIds);
+void lockApplications(List<String> relabelNos);
+Snapshot lockedSnapshot(String warehouseId, List<Long> warehousePalletIds);
+
+UnitFact(Long id, String oldLabel, String newLabel, String result, Integer quantity)
+Application(Long applicationId, String relabelNo, String customerId,
+    Long fulfillmentOrderId, String status, String fulfillmentStatus,
+    String deliveryMethod, String roundKey,
+    LocalDateTime updatedAt, LocalDateTime customerConfirmedAt)
+BoundSource(Long applicationId, String relabelNo, Long itemId,
+    String customerId, String warehouseId, Long warehousePalletId,
+    Long inventoryPositionId, Long inventoryBalanceId,
+    Long sourceInventoryBalanceId, Long sourceInboundOrderId,
+    String sourceInboundOrderNo, String sourceInboundCode,
+    long notifiedPackageCount, long boundPackageCount,
+    Long productQuantity, String bindingBasisHash, List<UnitFact> unitFacts)
+Position(Long positionId, String customerId, Long inventoryBalanceId,
+    Long warehousePalletId, long availablePackages, long holdPackages,
+    long allocatedPackages, long pickedPackages, long receivingPackages,
+    long recordVersion)
+Snapshot(List<Application> applications, List<BoundSource> sources,
+    List<Position> positions, String compositionVersion,
+    boolean complete, List<String> blockReasons)
+```
+
+`snapshot` 读取当前完整运输组成，不按页面筛选或排车资格隐藏关系。已作废 `CANCELLED` 申请保留在原业务历史中，不再扩展为当前运输来源；实际库存位置全部保留，残余HOLD无法由当前贡献解释时仍阻断。其他状态的资格由消费方判断。`lockApplications` 必须在调用方事务内按换标业务号稳定顺序一次锁齐。`lockedSnapshot` 重新读取已锁申请组成，不提前取得库存锁。dispatch 先计算闭包，固定申请全集→真实来源订单全集→共同 `ll_physical_pallet_guard` 实托串行行→组成重读→库存和运输占用顺序；发现新申请、订单或实托不得临时按发现顺序追加锁，整笔冲突重试。仓内组拆托入口使用同一共同串行点。
+
+此port只提供换标及库存事实，不反查dispatch账本；`Snapshot.complete` 用于零扫码选货阶段。两申请共享position时，贡献总箱数须与该position真实HOLD共同核对，不能只逐item各自判断HOLD足够。实际扫码后仍读取原身份、轮次和逐件事实，但箱数以已冻结 `ll_dispatch_item_source` 减去不可变 `ll_dispatch_pda_pick_order` 已消费额度，再核对全实托剩余贡献与真实HOLD；不得将零扫码完整性或最初通知数当作当前剩余额度。
+
+`ll_dispatch_item_source.relabel_round_key` 保存原提供者的真实作业轮次。原 `bindingBasisHash` 保留完整选货依据，但含库存数量、版本及申请生命周期，不用于要求正常扫码后摘要保持不变。执行锁内分别比较冻结轮次、申请/明细/客户、实际位置与余额、原货源、通知及商品件数和逐件事实；当前位置剩余HOLD按冻结贡献减已消费额度核对。PDA逐逻辑明细只显示本来源实际位置和剩余额度，同一position不向每个申请重复提供整仓位HOLD。
+
+正常TRUCK客户确认到实际扫码前仍保持HOLD，通用AVAILABLE合拆托不能移动冻结仓位；实际扫码在单一事务连续RELEASE/ALLOCATE/PICK/SHIP，不形成已提交AVAILABLE窗口。转运关联换标走原RESERVED/WAIT_TRANSFER_OUTBOUND分支，退出普通RELABEL候选。公开库存release仍可能使事实改变，因此必须保留锁内聚合及版本校验，不能宣称HOLD全局不可改变。原生退货箱继续由原提供者提供，不被普通位置贡献替代。
+
+#### 2.3.3 派送与费用消费的换标原货源快照
+
+共同字段位于 `DispatchContracts`，冻结顺序为：
+
+```java
+SourceOrigin(Long dispatchItemSourceId, Long relabelApplicationId, Long relabelItemId,
+    Long sourceInventoryBalanceId, Long sourceInboundOrderId,
+    String sourceInboundOrderNo, String sourceInboundCode, Long productQuantity)
+```
+
+`CargoLine` 保留原参数顺序，在末尾 `List<BatchAllocation> batchAllocations` 后追加 `SourceOrigin sourceOrigin`。`SourceOrigin` 实际为上述八字段，不另加字段别名或旧签名构造器。普通换标的第四真实拣货来源必须链接冻结贡献，并由此带出原货源；其他分支保留原真实receipt/return凭据，`sourceOrigin`为空。`DepartureFacts`等外层形状不变。
+
+`CargoLine.orderId` 仍是本条真实履约计数归属，不以原货源订单替换或把独立换标申请的履约单伪装成原货源。`SourceOrigin.productQuantity` 表示本次归属中有真实依据的件数，未知为空；不复制整个贡献或实托的总件数。出库、派送及费用快照保留这份不可变来源，用户界面显示原业务号而不回退内部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?,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[],appointmentBatches[] }`。多目的仓不能只返回一个 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行锁，不写整车派送完成；不得按当前item才逐个补取申请和订单 |
+| 装车完成 | 根→必要资源→dispatch→binding→全部换标申请→真实来源订单升序→共同实托串行行→库存及冻结贡献复验；读取既有pick/归属与当前装载清单 | 不先造派送以满足装车门禁；不执行allocate/pick/ship，不再申请delivery锁 |
+| 安排/发车/关联出库取消 | 根→资源→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同步继续。
+
+2026-10-19 18:13 当前源码收口：主候选已使用实际Provider candidateBatches有界批读，校验返回覆盖每个真实客户/计划实物；owned draft由外层校验，未将本操作者自己的占用误判为他人占用。BOL已从旧platformDetail改为DispatchBolReadService一致快照，整车SQL逐明细客户取原订单组成，按客户+实际目的地分组；退回实收/换标不套用原完整计划箱数。旧DispatchService单客户页/详情/创建/修改/取消及旧PDA公开扫码流程已移除，来源与原换标占用规则保留，未恢复旧Provider接口。
+
+最近一次实际完整Maven展开1062生产源码及453测试源码：生产编译通过；测试阻断已收敛为移交原派送写者的DispatchRepairWorkflowTest旧调用。原预约两FBA测试由总控修复父命令键；Fleet直接消费者、取货负断言已按现行createPickup收口。新增主单原预约移货/父事务回滚/客户数量原分配校验/真实扫码守卫和BOL两客户/部分退回SQL测试尚待统一运行。旧增量输出曾因IDE更新显示Nothing to compile，不能据此认定完整测试编译或回归通过；最终仍用稳定源码重新构建。主单cancel已改为仅活动非CANCELLED出库阻断，保留历史单据和原版本、阶段、零真实扫码边界，实际回归待运行。
+
+2026-10-19 18:24 本轮实际闭环证据：标准Maven完整`test-compile`实际重新编译1055个生产源码、454个测试源码并BUILD SUCCESS（此前移除6个本域旧DTO/实体/Mapper及原派送无生产调用Query；当前Mapper扫描为10模块/392 Mapper通过）。记录`.logs/dispatch-full-current-test-compile.log` SHA256=3852983b13e1182be8d22baeea4adaf774e4ddf57db11fe0354c0a900913d85f；旧客户头类class已核不存在，不用排除消费者的局部编译代替全服务编译。
+
+行为回归先运行71类438项，实际423通过、8断言失败和7错误；随后按新输入只复跑修正项与新增直接消费者，9类69/69、8类90/90、3类16/16均BUILD SUCCESS。按每类最新结果去重共80类501项，0失败/0错误；这是分批组合覆盖，不宣称一次501项全绿Maven。机器可核摘要为`.logs/dispatch-final-evidence.json`，包含每份日志SHA256和每类最新来源日志。实际覆盖原预约分配/整票移货/父事务回滚、主单PDA双客户真实库存命令、装发/签收消费、来源发布并发、取消重排、归箱与异常来源、候选批读、BOL真实SQL、网关与资源附加能力。测试替身隔离的提供者和手工准备的已发运夹具不等同真实环境整链验收。File49及IAM29输入未变，仍引用先前实际通过结果，未重复计入501。
+
+FleetAppointmentImpactMapper已使用唯一binding+真实item客户EXISTS（SHA256=36ae1dccaff96dcc49a8bc1a43ebaba18950b641440cf6bc5682ffa0e6911381）；VehicleFulfillmentMapper也以真实item客户证明替代binding头客户（SHA256=79ec8f7a818c412931e81f7e2b6a5299cb4c8bf38939ca5f645a5a5d43d70761），车辆履约7项与权限/只读合同2项在90项中通过。其夹具为一张整车、两客户、一条车次绑定，并保留伪客户、原发车、换车及交接断言。
+
+依赖门禁本轮先发现新增既有预约→整车公共端口7条精确类型引用未登记，已按获批接线加入reviewedClassDependencies（不加整个slice许可）；随后总控接管该基线和反向越界检查，最终Node结果以总控交付后复跑为准。原fleet.pickup的Mapper/Repository/Service到WarehouseTransferOrder三条旧直接实体引用及fleet outgoing限制仍是开工前既存阻断，不在排车作业里放行。未执行部署、SQL、环境写入、真实HTTP/PDA或人工截图验收。
+
+2026-10-19 18:26 总控冻结依赖输入后实际Node复跑13项：10通过、3失败；新增original appointment adapters use only the reviewed dispatch port types合同通过，包括未知消费者及主流程实现类型的反向拒绝。剩余失败仅由上述开工前取货三实体直接依赖及fleet outgoing限制触发，未放宽slice。日志`.logs/dispatch-lastleg-dependency-contract.log` SHA256=6a767619db627952ce59aaba5d4530413728d18a4c21928b61ca2f05008a6cff；501行为组合覆盖及编译证据摘要已同步依赖结果。最终Mapper合同为10模块/392个Mapper通过，受影响路径git diff --check通过。
+
+2026-10-19 18:27 最终冻结输入的一次联合Maven已实际完成：80类501/501，0失败/0错误/0跳过，BUILD SUCCESS；日志`.logs/dispatch-final-joint-regression.log` SHA256=b56da123ceb74409530793c3de92467cac686b03d97eb4afc34febc1a4b83238。这次结果独立于前述分批组合，不用组合结果冒充单次通过。完整命令参数及源码/合同快照在`.logs/dispatch-final-inputs.json`（运行前后1519份文件逐项SHA一致，其中生产Java1055、测试Java454；归一化路径排序聚合3ff451e8b6e6774e53bbc62fba5b2fcd2b7098e129d490434468b3ef91594de9；快照文件SHA256=ae07cb978c639488c8de78b458e9c1995fe6e66bee1fcd4bb8e34a79a644ad12），摘要`.logs/dispatch-final-evidence.json`已追加finalJointRun，未排除任何测试编译消费者。
+
+Gateway路由合同最终5/5通过（`.logs/dispatch-final-gateway-route.log`）。AGENTS索引第一次仅“海外PDA指引超过8000字符预算”失败，没有缺失路径；总控已交原前端写者精简该唯一指引，源码及本次501输入不受其文案变化影响，待新指引后单独复验。整体依赖门禁仍为10/13，不标为全通过；现有取货依赖是独立限制。行为已通过输入不再反复测试。
+
+最新用户裁定取消排车车辆预约字段及关联：Create原本无该字段；本次从Update和DispatchInfo彻底删除vehicleAppointment及AppointmentReference/VehicleAppointment类型，Aggregate删除对应拒绝分支和固定null参数，无别名或空占位。车辆预约不再列为待接通依赖。FBA预约及批次保留，日历新增预约不变。此前单次501回归绑定删除字段前的输入；本次签名变更以新的全测试编译及直接消费回归为准，保留旧日志作为历史证据。
+
+2026-10-19 18:38 按“取消车辆预约字段”新输入完成无排除test-compile，BUILD SUCCESS（`.logs/dispatch-without-vehicle-appointment-test-compile.log` SHA256=50cc293c71a64a8242ca6f5852875542d7a8ff822def7f012fae926dd9103071）。直接受影响5类25/25、0失败/错误/跳过，BUILD SUCCESS；日志`.logs/dispatch-without-vehicle-appointment-direct-tests.log` SHA256=dbadeab653c67610b8c2b09ac8cd9af8177c0d7decdb0b7ab7bd94f8748475f7，真实Update新增验证计划保存/原键恢复及详情JSON无车辆预约字段，并保留FBA展示。相对旧501快照恰好8份Java/合同/测试输入变化，新源码快照`.logs/dispatch-vehicle-appointment-removal-inputs.json`，聚合1607ea98c3f9a8fadf66541f95c70f33e4ebae55cb3823b3801d52d5196b0685；完整命令和变更列表见`.logs/dispatch-final-evidence.json`的新vehicleAppointmentRemovalVerification。不重跑未受影响库存、发车或派送501组合。
+
+公共类型新SHA256：DispatchCommands.java=0553f0af5dbe31bb9d63701872540261398536f1925edfc3d7f309202aeeea56；DispatchViews.java=2c027f2516ee7a1a0a544e52aaa4a8be70b1439a0b94008223335d499ebf2ae9。两被移除嵌套类型的target/classes也已核不存在。新AGENTS长度已合格，但第二次索引仅缺两段固定文字“涉及业务行为变更时必须核对对应细则”“不得与国内 PDA 混用”；继续交原前端指引写者恢复，尚未记索引门禁通过。
+
+Java候选交接边界：总控已核取消车辆预约后无排除test-compile及25项直接回归均BUILD SUCCESS。Java本域停止对未变输入重复检查；Maven写权仅供后续真实Java问题续接。此前501单次回归继续绑定旧字段输入，不冒充新协议501通过。总控继续统一AGENTS索引、前端及现行HTTP验收脚本消费者，未将它们标记为本Java域已完成。总控报告当前OpenAPI按源重生97 schemas、29平台+7PDA路径、649 refs和两SQL静态通过，无车辆预约字段；该重生输出及索引/脚本最终证据由总控持有。依赖门禁仍10/13，旧取货直接实体引用不豁免；无环境发布/真实HTTP/PDA/截图验收。
+
+2026-10-19 C52路线事实修复：FleetTripService.updateDispatchCargo不再仅追加旧路线。起点与本车起运仓一致；按当前真实货物目的地和有效外接预订（CONFIRMED/RECEIVED/BOUND）目的地保留原站点相对顺序，删除没有任何有效支持的旧站，新货目的地追加。有效预订要求的站若原路线已缺失则整笔主单事务失败，不编造站名/地址。原计划容量、实载和理货快照继续随货物修改清空；车次更新增加原版本条件，和明细、来源占用、绑定货量、命令账本同事务回滚。直接提供者仅新增FleetBookingReservations.requiredRouteDestinations并复用到原requireRoute，未扩展其他业务或公共API。
+
+实际检查经scripts/local-check.ps1单槽执行，未提高Maven默认1536MB/2处理器限制：无排除test-compile exit0/BUILD SUCCESS；5类33/33、0失败/错误/跳过/BUILD SUCCESS，其中FleetDispatchRoutePersistenceTest新7项涵盖多站末托移除、有效站原序/新站追加、同目的地多托保留、空车仅起点、三种有效预订保护与取消后去站、缺失必要站冲突、真实绑定写入失败后的主单/路线/占用/货量/账本回滚及同键重放。其余直接回归为DispatchAggregatePersistenceTest11、FleetTripPersistenceTest7、FleetReceiptCapacityTest5、FleetTripMatchedStopsTest3。Fixture复用真实服务/Mapper/H2事务，目录与选货权威仍是受控提供者，预订作为持久化输入；不宣称真实环境HTTP/库存或预订确认整链验收。
+
+C52源码SHA256：FleetTripService.java=28eca09b87337b07a04955039a50c3c55805289955c24db75fe9df6fbf0b3bcc；FleetBookingReservations.java=84906c28ccaf94125a41c03a30c9df392400af74569ed26c2da8abd5c116144c；FleetDispatchRoutePersistenceTest.java=687248640255a40456f4197cab28dd32e8a16f97a833858fc868e171dcf2b62c。3路径聚合9fab733033d4fffaeb716b4cb2720dd72b26c14ece1b97d6bd6d2e30db502aa2（规范化路径Unicode顺序、path+空格+小写SHA、LF连接无尾LF）。命令/资源限制/3份源文件时间与哈希、5份JUnit XML摘要及用例名、Maven日志均在`.logs/dispatch-route-evidence.json`，SHA256=642624474f2d978247e5d02582dc4f4ced3a89000bf694091de0cb15a5fd892d。Wrapper日志`.logs/dispatch-route-test-compile.log`/`dispatch-route-regression.log`，原始子进程输出分别留在`dispatch-route-test-compile.maven.log`/`dispatch-route-regression.maven-tail.log`，后者完整保留5类结果及BUILD SUCCESS。33通过后生产和测试输入未再修改；没有重跑501/索引/无变化门禁，没有环境写入或部署。

海外仓业务/排车列表派送费用接口设计.md

@@ -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个后端路径；总控随后只对`FbaAppointmentPersistenceTest`与`FbaReceivingPersistenceTest`补齐13处父命令键参数（部分移动直接断言原键`partial-confirm`），其余17文件保持交付输入，本节已更新两文件及聚合摘要；主流程公共合同、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：`70526153276ae4d8f5be3e211b5067ca3a8ae79a24eefe7b490df4b1486ad658`。按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 222cc71e3b24f7bbe25cc743fc964891f6d2c385e276744af59b45d5abe72d7c
+lastleg-service/src/test/java/com/baiyue/lastleg/inboundplan/service/FbaReceivingPersistenceTest.java 504c79ab02cac49cbb5c4698959ace76d2c3970532bf9e3c372e64930f449407
+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
+```

海外仓业务/排车列表统一作业改造契约.md

@@ -0,0 +1,233 @@
+# 排车列表统一作业改造契约
+
+本契约规定排车列表作业阶段、整车与客户货物归属、派送安排及 Admin 和海外 PDA 的共同目标。2026-10-19 用户确认一张排车单代表一趟车，并指定当前对话为本批总控；经逐项问答确定本契约的业务和界面基线，再下发三个任务做技术准备，共同接口冻结后才解锁生产代码实现。本契约描述目标及实施边界，不表示代码、部署或真实验收已完成；部署与真实验收事实仍维护在两份环境主契约。
+
+本批规则优先于旧车次独立列表及多张客户排车关联共享车次的交互说明。旧缺陷修复规划仅用于核对已修复行为，不覆盖本批目标。
+
+## 一 用户已确认的业务目标
+
+2026-10-22 用户最新确认：允许先排车后预约，也允许先预约后排车；本条替代同日此前“FBA必须先约才能选入排车”的口径。一张排车单同一FBA目的仓仅填写一个约好的编号，同仓多票、多托及跨客户货物共用该目的仓编号；两个目的仓填写两个编号，不要求客服逐票关联或分配预约箱数。尚未预约不阻止普通入仓货物候选、新建、加货、草稿及正式转换，未实收仍沿真实计划来源，不伪造库存。客服在维护车辆信息中按目的仓填写，保存允许暂缺；提交调度审核必须补齐本车所有FBA目的仓编号，缺失时明确提示仓码。调度和理货通过、真实拣货、装车及发车继续复验，取消、驳回回车辆信息及失败后继续操作的规则保留。换标、退货独立来源不新增预约创建入口，实际客户、货物数量与库存归属保持逐来源核验。
+
+车辆维护在现有派送信息区直接展示“目的仓／预约号／确认送达时间／货件号”表格，同仓只出现一行及一个预约号输入框，确认时间和全部货件号自动带出；修改编号后保存前不沿用原编号的确认时间，不再从关联订单跳转逐票预约分配弹框。已有完整且唯一的已确认预约来源可自动携带，按目的仓合并编号；同仓存在多个不同确认号时由客服明确填写本车使用的一个号，不任选第一条。未选正式批次时仍按本车真实客户、来源与箱数保存内部实物关联；已有明确批次引用继续核实归属及分配数量，但不要求客服逐票操作。维护写入沿用原Update的`maintenance.destinationAppointments[{destinationKey,appointmentNo}]`，存于既有resourcesJson，不新增表、权限或预约创建接口；原整车单号、货物和库存不变，编号变化使原审核依据失效。非法目的仓、重复仓、过期版本及阶段不符须拒绝并回滚，页面保留输入、重新读取后可重试。
+
+列表、详情、审核、PDA与车辆维护共用按目的仓汇总的预约投影，BOL沿同一目的仓使用客服保存的编号，各票客户归属及箱数不改变；预约号筛选包含目的仓登记值，不再命中该仓已被人工改选覆盖的旧编号。已确认时间仍取匹配编号的当前有效正式确认，保留当地时区和原时段校验；仅填写编号不伪造正式确认时间，显示已登记，不能用计划发车或预计到达代替。货件号沿本车真实客户、计划逐票分配及直接订单关联读取，不依赖是否存在正式FBA预约批次；手填目的仓预约号时也须带出实际货件，同仓合并去重，不把其他客户货物并入本票。排车列表司机与联系电话保持两列，仅消费真实字段，缺失显示“—”。所有阶段、装车前审核分区和排车类型均展示主单created_at的真实创建时间，不以计划发车或更新时间替代，不逐行请求详情。
+
+2026-10-22 车辆与图片门禁：车辆候选按海外在役状态及真实车次占用在服务端分页前筛选，排除其他车次占用并保留本车资源；当前选择失效可清除或改选，提交仍复验。草稿允许分步保存，提交审核及审核通过必须分别具备至少一张有效车辆图片、司机照片、驾驶证照片；选图未上传、上传失败、作废文件不计为有效资料；驾驶证接受PDF/JPG/PNG原件。每次放行复核文件有效性及分类归属；主档驾驶证按冻结来源读取，本趟补传图片按排车归属保留，不因主档解析丢失。主档换证后再次保存，服务端按原冻结来源标记剔除旧主档引用，再由车队解析当前主档；保留本趟补传图片及原历史，不把旧主档证照改按排车附件校验。
+
+2026-10-21 新增内部散板需求发布选项，2026-10-22 简化智能排车入口；当前发布选项、时间来源及派送排车的候选、满载退出和未知容量口径统一见[内部散板需求池当前范围](内部拼车需求池首版开发契约.md#当前页面范围2026-10-21)。选项仅随新建命令按车同事务持久化，编辑不修改发布选择，不改变排车审核、实际拣货、装车照片或发车流程。
+
+1. 2026-10-21 用户最新确认：排车列表恢复装车前、装车中、装车后、派送中、派送完成五个作业阶段。装车中可同步上传资料；确认装车完成且资料齐全才进入派送中。装完但资料未齐留在装车后，资料先齐则确认装车时直接派送；此规则替代同日此前“装完即发车”的确认。
+2. 一张排车单就是一趟车，允许同车多个客户、多个目的仓；各票货物、库存、单据和费用必须保留真实客户归属。
+3. 装车前包含车辆信息、调度审核、理货员审核；维护车辆信息后提交调度审核，再经理货员审核进入装车中。2026-10-21 用户确认审核链：客服在最初的车辆信息入口维护并提交，不新增独立客服审批级别；调度或理货员任一环节驳回均须填写原因，并统一回车辆信息／客服处理分区，离开待审队列。客服处理期间保留驳回环节、原因和原审核记录，编辑不抹除原因；重新提交开启新轮次，必须重新经过调度及理货审核，不复用旧批准。理货审核允许 Admin 或绑定仓 PDA 操作，两端共用版本、幂等和审核依据；通过前不得真实拣货，通过后才进入装车中。
+   2026-10-21 用户确认精简车辆维护入口：仓库派送排车的列表、详情隐藏“调整卸货顺序”和独立“提交调度审核”；提交统一放在“维护车辆信息”弹框，保留“保存”和“提交审核”。提交审核先保存本次车辆、司机、时间与附件，再读取最新版本和服务端资格提交；两步分别执行，失败提示后保留输入并结束请求态，用户再次点击按当前事实重新请求。车辆维护和提交审核不提供备注输入，保留已有备注；调度／理货审核的驳回原因仍必填。到仓取货沿独立运输操作入口，不受本次车辆维护弹框合并影响。
+   2026-10-21 用户进一步确认：调度审核、理货员审核两个列表分区只提供“审核、详情”，不展示维护车辆信息或其他操作菜单。Admin审核弹框可补充车辆图片、司机照片、驾驶证照片，已有证据只读预览；新增附件随本次通过或驳回保存，不借维护车辆信息重写车辆/司机资料或改变审核依据。上传及提交均按当前待审环节的审核权限校验，并逐文件核验本车及分类归属；附件读取沿列表查看权限。理货驳回、客服修改保留已提供证据，新一轮提交清当前审核附件并保留历史。PDA继续使用既有审核入口，本次不新增PDA上传界面。
+
+   维护资料通过 `DispatchCommands.Update.maintenance` 保存到现有 `resourcesJson.maintenance`，详情对称返回 `vehicleInfo.maintenance`，唯一类型为 `DispatchContracts.Maintenance`。整体及八字段均可空，空白文本规范为 null，允许空草稿保存：`plannedDeliveryDate` 为 ISO 日期 `YYYY-MM-DD`；`deliveryMethod` 为 FBA自提／客户自提／卡派打托／卡派地板／快递／外配；`pickupMethod` 为一提一卸／一提多卸；`loadType` 为托盘／地板／混装；`fleetEmail` 最多254字符；`vehicleType` 为厢式货车／平板车／集装箱卡车；`appointmentAccount` 最多128字符；`destinationAppointments` 按本车目的仓去重，每项为目的仓业务键和最多128字符的预约号，空白可暂存但提交审核必须齐全。不新增审核级别或权限，正式确认时间、实际发车及派送费用口径保留。MASTER／EXTERNAL 车辆的本趟 `evidenceFileIds` 均保留到资源快照，不能被主档解析清空；保存及审核对非空照片逐项核验本排车及 VEHICLE 类别、有效性，调度审核读取同一已保存证据，不写入车辆主档。
+   2026-10-21 用户确认：在装车前清除“有效排车”筛选后，仍保留车辆信息、调度审核、理货员审核三个页签及当前选中项；查询沿用空值默认有效排车的规则，切换页签继续按当前审核分区查询。
+4. 2026-10-21 用户确认：装车完成确认真实实载，Admin与PDA成功结果在资料未齐时为AFTER_LOADING、资料已齐时为DELIVERING。装车中及装车后均提供司机驾驶证、车牌照片、装车完成、封车照片、BOL司机签字五类资料（每类1至5份），两端均可拍照/选择图片、上传、预览及替换，按整张排车单共用当前照片与附加资料版本，不依赖派送单或按客户重复上传。五框全部绑定保存且已确认装车完成后自动进入派送中；不以选图、文件上传回执或重复槽位充数。保留真实拣货核平、实载校验、版本及防重复约束。
+   自动带入规则：理货审核通过、进入装车阶段时，服务端将本趟已核验驾驶证和车辆照片分别复制为“司机驾驶证”“车牌照片”类别的独立装车附件，PC与PDA共用同一份照片记录及版本。每类最多带入5份，仅填充空类别，来源未变化时保留已有现场照片及替换结果，重复审核不重复复制；退回后保存车辆身份、司机身份或对应证照附件变更时，对应类别的旧资料（含手工上传）与资源修改同事务失效，保留文件和历史，车辆身份变化还须失效装车完成和封车照片，司机身份变化还须失效BOL司机签字；同一身份仅补换证照图片时保留其他现场凭证。再次理货通过后仅按新来源带入驾驶证及车牌资料，失效的现场凭证须重新上传。上传携带选择照片时的审核轮次reviewRound，服务端保存到原上传账本；绑定携uploadKey，核对文件、类别、操作者及当前审核轮次，旧轮次上传即使采用最新资料版本也不得绑定。后续主档换图不改本趟附件。司机人像不放入驾驶证类别，其余三类由现场上传。驾驶证支持PDF原件（计一份）并可在两端查看；其他类别只接受JPG/PNG。复制失败时本次审核与资料绑定同事务回滚；GET保持只读，不执行测试存量补写。
+
+5. 装车已完成时，第五张装车照片绑定与按客户和目的地生成出库／派送单、记录实际发车并进入派送中在同一事务完成；照片先齐时，这些动作随装车确认在同一事务完成，仍无人工安排派送及确认发车入口。上传和绑定各保留稳定原请求键；第五张绑定或派送失败时保留装车后、前四张及原上传文件，原请求可恢复，不能留下半车或重复派送。PDA每次按Token绑定仓校验，Admin沿排车list只读、edit上传保存。照片使用原整车附加记录及文件归属，不新增存储表；五个既有技术槽位按顺序映射上述五类资料，不替代司机审核或真实签收。真实外接报价沿原费用路径发布，未知派送补充资料与费用保持未确认，不猜测金额或原费用覆盖、不填写零费；后续由既有后台资料／费用管理维护。装车中上传齐资料不会提前发车；照片先齐时派送失败回滚本次装车确认、保留已保存照片，原请求可重试。装车完成原键恢复本次事务原最终阶段（AFTER_LOADING或DELIVERING），资料保存原键恢复原保存结果，当前阶段须另读；不重复扣库存。
+6. 实际发车后为派送中；全部正常签收完成后自动进入配送完成。派送中可以“标记异常”：类型必填（拒收、部分签收、车辆异常），退货去向选填（退回海外仓、其他），说明和图片选填。登记沿排车维护权限，按本车版本及原请求键防重，异常记录和图片保存在主单并于现有“排车信息”详情回看；阶段仍为派送中，不自动创建退货、恢复库存或确认签收。异常后续处置由人工处理，本轮不新增线上异常闭环。
+   资料入口（2026-10-28 最新确认）：装车中、装车后从“管理资料”打开整车五类资料；有效排车在派送中从“管理资料”居中弹框进入，签收文件、装车资料两个页签，配送完成列表不再提供“管理资料”入口；2026-10-22 暂隐藏油耗图片上传和展示入口，原图片、版本及历史保留；按本车真实关联派送单及客户范围切换。签收文件与 BOL 复用派送单原附件记录；排车装车资料只维护整车共用的五类资料，不再同时显示另一套派送单装车照片上传框。派送单既有附件仍可从派送单资料入口查看，当前页签的上传类别统计只包含该页签内容。签收文件保存即沿现行逻辑完成对应派送单，全车全部正常签收才汇总配送完成；其他资料后补，不作为完成门禁。车辆与司机审核附件只读回看，油耗图片按车复用车队附加照片、版本及历史；保留原油耗接口的dispatch:list读取、dispatch:edit上传权限，当前排车页面不挂载油耗框，不改变车队原独立权限。外配任务原入口仍只输出五个装车框，但共享记录允许排车入口补充油耗图片；不复制派送签收文件为车队照片，不新增状态或数据库表。
+
+
+   2026-10-21 本轮登记契约：`POST /api/platform/v1/last-leg/dispatches/{dispatchNo}/exceptions`，动作`MARK_EXCEPTION`，`recordVersion/idempotencyKey/exceptionType`必填；`returnDirection/description/imageFileIds`选填。说明最多1000字、图片最多20张；异常图片类型`OVERSEAS_DISPATCH_EXCEPTION_EVIDENCE`，平台0、本车ID归属，非空JPG/PNG、单文件10MiB。主表新增可空`exceptions_json`，与原版本、历史、命令账本同事务保存；代码及基线已准备，未执行SQL或部署。
+7. 本批聚焦排车列表、详情、直接关联操作及必要生产者和消费者。车辆列表、司机管理、自有业务、外配业务、出车记录的整页改造后续逐页处理。
+8. 同时支持先选同一起运仓的可排货物/托盘再生成排车单，以及先创建空排车单再添加货物；空单不能伪造货物、拣货、装车或发车事实。2026-10-21 用户进一步明确先排车和货物，车辆、司机在建单后由调度或客服在后台补充，不涉及客户自助填写；新建排车不展示或要求填写车辆、司机及证照，先完成货物分组，允许选填每趟计划时间和备注。计划托位仅用于预排分组，不表示已绑定真实车辆。后续维护车辆信息及提交审核继续使用既有资源资格校验。用户随后明确：货物计划增减统一在智能排车办理，排车列表车辆信息及详情不再单独提供添加／移除货物。智能排车同时承载新建及已生成排车货物调整，已有单使用原排车号和正式货物命令，不转换为草稿或重建单据；保留真实PDA拣货，已扫码禁止调整，理货审核通过且零扫码时先显式退回重审后再调整。
+
+2026-10-21 区域入口确认：智能排车新建选货删除查询区的海外仓选择，仅保留“全部／洛杉矶／纽约”。候选接口 `warehouseId` 可选，不传时按区域做数据库分页、计数；指定仓的已有排车和预约消费者保持单仓查询。首个选中来源决定草稿真实起运仓，草稿建立后按该仓读取并禁止切换至其他区域混仓；全部表示该草稿仓的全部候选。未确定起运仓且区域匹配多个仓时不能提前创建服务器车辆容器，先选货再确定仓。空单没有来源可推断仓，其起运仓放入排车设置内选择。创建、锁货和转换的同仓约束保持不变。
+9. 车辆和司机既可从已有档案选择，也允许临时填写外配车辆和司机；临时填写不伪造车辆或司机档案关联，不自行创建主档。
+10. 后台确认装车完成必须以PDA真实拣货核平为前提。后台不提供替代PDA的拣货数量补录来绕过此条件；PDA和后台均可确认装车完成；两端可在装车中同步上传五类装车资料，由服务端在装车与资料均完成时自动发车。
+11. 用户随后澄清本次“新增预约”是预约日历的功能需求，先与本批排车改造分开整理。本批不新增日历预约创建或独立约车流程；排车保留已有FBA预约关联；用户随后对车辆预约权威来源问题答复“那就不要”，因此排车取消车辆预约字段、关联操作及公开协议，不再等待或新建该权威提供者。此前确认的先保存后关联意见保留为日历需求输入，不作为本批扩大实现范围的授权。
+12. 用户进一步明确“本批支持整托同车”：两张换标单已合到同一实托时，整托进入同一排车主单，物理托盘及容量只计一次，各换标单的箱数、客户及扫码归属分别保留。不得只装第一来源、借第一客户承载其他来源，或把同一实托拆成两张排车绕过排他占用；此确认取代该场景的待决定状态及仅作前置拦截的候选方案。
+13. 用户进一步确认：换标已由客户确认完成、关联出库单尚未扫码时，只取消本次出库安排，保留已完成的换标成果，退回待安排。不得将已确认换标申请一并作废；取消须清除本次有效出库关联，保持真实客户、原换标成果及重新安排资格。此规则不放开已扫码取消或新增回库流程，整车取消仍遵循既有阶段、版本和零扫码门禁。2026-10-21 用户确认排车安排与货物事实分离：整车取消只撤销本车运输安排、预约分配及逻辑/物理占用，恢复本车换标预占，不改变货物实收、库存或已完成换标成果；未实收计划无需实托，已有实托也不重新按当前库存数量、来源组成或装车资格校验取消。取消仍先锁本车原换标申请及原实托串行点，并保留版本、装车前、零真实扫码、无有效出库及车队未执行门禁；扫码、装车和发运继续使用原严格货源校验。
+
+14. 2026-10-21 用户确认：排车BOL前端仅在本轮调度审核通过后展示下载入口，无需等待理货审核或装车完成；未提交、待审核、驳回及审核失效时隐藏。用户明确本次仅改前端，后端下载接口不增加审核判断。审核分区仍仅保留审核、详情。2026-10-20 用户在人工BOL验收中最终确认：保持现有一次下载/预览PDF的方式，PDF内按“目的地＋预约号”分别生成BOL；同仓同预约号的货物合并，不同预约号分成各自BOL，不按客户拆打印分组。用户前述“不同PDF”在后续“就和现在一样”的答复中已明确沿用现有承载，总控已说明当前实际是一个PDF包含多张BOL；不新增选择弹框、压缩包或下载协议。没有预约号也能打印，预约号栏留空，同目的地且均无号的货物合成一份。各BOL明细超页时可有自身续页，按原分页容量处理；打印分组不修改各票货物、库存、派送和费用的真实客户归属。货物按真实预约分配及数量归集，不把同一明细全量重复复制到每个预约。
+
+15. 2026-10-20 用户确认排车业务号为`PC`前缀、八位日期、四位日流水，例如`PC202610200001`。日期沿用平台业务时区`Asia/Shanghai`，每天从0001开始，全平台跨客户和仓库统一递增；首次建单分配，命令重放返回原号。流水在独立短事务中原子分配，避免持车辆/来源锁时延长全平台序列锁；取消或建单失败不复用已分配号，最大流水反映编号进度，准确单量以列表主单统计为准。四位当日用满后明确拒绝，不回绕重号。本条不表示DDL执行或环境发布完成。
+
+16. 2026-10-20 用户澄清“预约排车”指入库单的智能排车：货物离港后，即可按入库计划预排，无需等待海外仓实收。自动生成并预留的托盘码不是实收库存；尚未开始收货的预留托盘按 PLAN 来源选择和占用，不能据其仓托关联过滤在途候选。全部真实来源按权威柜节点或已覆盖的人工节点核对实际离港，人工覆盖后不回退柜节点。预排不伪造库存、拣货、装车或发车；后续实收身份及数量沿原计划绑定与 PDA 门禁复核。智能排车保持居中弹框，按起运仓与方式、选货分组、当前组车辆时间组织操作，草稿与多组原子转换继续沿现有公开协议。
+
+17. 用户要求真实 HTTP 跑通“货柜实际出港→实收前预排→到仓→原排车出库”完整流程，并要求请求完整响应小于 1s；单用现有库存直接排车不覆盖该验收。用户允许在全量候选优化后仍慢时采用分页显示。分页须由服务端处理查询范围、筛选和排序，明确当前页与总量语义，不先完整计算所有候选后仅切片；选货仍按权威完整选择组核对跨页同托来源，不以当前可见页冒充整托完整货物。此条记录目标与条件授权，不表示已实现分页或已通过性能验收。
+
+    候选分页参数为`page`（默认1）、`size`（默认20，最大50）及服务端仓库页签`warehouseTab=ALL/LAX/NYC`；沿用原仓、计划、订单、目的仓、来源阶段和草稿筛选。响应`total/page/size/pages`明确筛选全集及当前页，顶层`complete`仅首且唯一页包含全部来源时为true，不能用于拒绝普通分页；`selectionGroup.complete`继续独立证明同托及整申请完整来源。原草稿一次选取仍由服务端解析完整组，不能按页拆开锁货。
+
+    2026-10-22 用户进一步确认：逐托数量在拆柜清点并确认入库时确定，收货9+11，原车出货也必须为9+11；不能等首次出货再补写数量。实收前的预排估算仅保留计划依据，不作为实收后逐托箱数相等的门禁。确认入库在原事务内先锁齐原车辆、排车与预约，再按已确认的逐客户、订单及托盘来源更新原排车实托绑定、明细箱数、整车/车次汇总和预约逐票分配；失败整体回滚，不产生出库扣减。预约归属沿原选择唯一匹配，不按托数均分实收、不替现场猜测多批次分配；身份及归属不变的自然实收保留原审核与历史。PDA任务GET只读取收货已交接事实，不投影修正数量；出货扫码只执行已确认的实托及箱数，不补绑定或改写收货数量，默认带出本来源可拣数量。未实收、来源身份变化、冻结/其他占用及重复扣货仍须阻止，不能吞入其他客户、订单或未选中的同托来源。诊断接口补仓位不算正式PDA产品链路通过。
+
+    2026-10-23 用户确认：普通入仓货物实收前保留计划分托估算；确认入库时，按各来源订单毛重×本托确认箱数÷该来源应收箱数汇总毛重（保留三位小数），体积汇总收货端记录的逐来源体积，并在原事务内同步原预排明细，包括清除已失去来源依据的计划值。后续新建/加货的已收货候选按当前可用库存位置及余额关联的真实入仓来源计算，以来源毛重/体积×当前可用箱数÷来源总箱数汇总，毛重三位、体积四位；拆合托及部分出库后不复用原整托收货数量，合入不同来源逐来源计算，缺少任一有效来源依据时对应指标保持未知。客户来货的仓储转运优先使用同一转运来源、同仓、全量可用且未拆合换绑的唯一逐托实测值；不将尾程订单ID当作入仓单ID，不把整托实测复制给部分库存。分摊值不冒充实测，不以材积重、零或旧计划值补齐未知货量；实际装载仍遵循独立实测证据契约。来源身份、箱数、预约归属、审核保留及失败整体回滚规则不变，关联订单仍按原来源逐行展示，不回填历史排车快照。
+
+## 二 原型依据与详情四块
+
+2026-10-21 用户确认排车列表的主筛选改为“车辆状态”，本次提供待发车、配送中、已送达，已返回及返仓确认后续再补。这里表示本趟运输进度：有效排车的装车前／装车中／装车后显示待发车，派送中显示配送中，派送完成显示已送达；不读取车辆档案的在役、维修或归还状态作为本趟进度。列表新增同名状态列，取消单显示“—”，仍由单据状态标识已取消。单据范围（有效排车／已取消／全部单据）移至高级筛选，收起时仍提示非默认范围；切换单据范围为已取消或全部单据会清除车辆状态，选择车辆状态则回到有效排车。状态查询与现有阶段页签联动：配送中／已送达切到对应阶段，待发车保留当前装车前、装车中或装车后，否则切回装车前；切换阶段时同步已选车辆状态。查询、页码、总量与审核分区沿用服务端阶段分页，待发车仍按当前装车阶段／审核分区查看，不在浏览器截取当前页筛选。重置清除全部筛选（含收起的单据范围），恢复有效排车，保留当前阶段及审核分区。
+
+原型为用户提供的新版 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对同一版本同时操作只产生一次合法结果，自动建单、发车和命令结果同事务，服务端继续保证版本校验和业务防重。2026-10-21 用户确认取消Admin排车前端的未确认请求持久化、旧请求重放及失败锁页：仅请求进行中防连点，任何失败均结束请求态并保留输入，下一次点击按当前事实重新请求；关闭重开不恢复历史失败请求，也不阻断其他排车或操作入口。
+- 全部正常签收才汇总派送完成；部分签收仍未完成，异常不伪造完成、退库或费用结算。
+- 普通入仓、换标/退货来源、同托多来源及既有预约批次/工作事项的直接调用不丢来源、不重复扣库存或收费；保留上一批修复约束。
+- 加载、空态、错误、无权限、附件预览及四页签长编号展示；不逐行查询列表详情或附件。
+- 后端受影响测试与测试源码编译、网关路由合同、必要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`；装车完成自动建单和发车，不额外要求已移除人工入口的安排／发车权限，列表/详情仍为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最终统一维护，避免另建重复状态文档。
+
+### 换标同实托多来源的实施冻结
+
+用户已确认本批支持整托同车。本次按真实物理托盘与逻辑运输来源分层：同一车内共享物理占用，来源分别保留客户、换标业务号、原货源与可拣贡献；跨车及跨草稿容器继续物理排他。只移除一条来源不得提前释放仍有其余来源的实托，取消、草稿失效/转换及零扫码重审沿同一完整集合执行，不通过第一条来源或FIFO推断其他来源。
+
+候选由服务端返回完整选择组及组成版本，使用未被页面筛选截断的事实闭包，兼顾既有整申请规则；前端不按当前可见相同托盘码自行拼组。正式Create/AddCargo保留显式逐来源选择并在服务端复核全组；草稿单来源动作须服务端一次命令原子处理完整组，不能用前端循环多个写请求代替整组一致性。PDA保留逐明细精确扫码，展示明确换标业务号及该来源可拣位置/额度，全部逻辑来源核平后才允许装车；不新增整托一键多次扫码或自动补拣数量。
+
+装车确认仅传当前版本、清单摘要与幂等键，服务端按已扫实托去重计算托数（每实托一托），沿已有路线确定卸货站。已有重量、体积保留原实测依据，未知不要求现场重复测量、不填零、不推算；已知货量超出容量仍拦截，未知重量体积不作为可售余量。LoadingPreview及实际容量按每实托一行，逻辑箱数、来源状态与费用分别按真实归属保留。整托实测重量/体积不复制到每逻辑来源；业务份额只使用实际来源证据，缺少证据保持未知，不按箱数推件数或平均分摊重量。主流程先产出字段级公共骨架及唯一接口设计，前端以实际Java记录对齐；来源贡献的仓库生产者/移动触点及精确DDL由主流程提出，总控核对现有写者后逐文件分配。共享SQL/OpenAPI仍由总控集成，Maven仍由主流程唯一执行；此前普通流程通过结果不覆盖本次新增模型。
+
+来源贡献的直接验证按主流程明确释放的有限边界并行：派送专项唯一新增`lastleg-service/src/test/java/com/baiyue/lastleg/dispatch/service/DispatchItemSourcePersistenceTest.java`，验证冻结贡献、逐明细/客户/位置消费、已消费额度、HOLD合计及事务回滚；该文件移交前主流程确认未创建、未写入。`DispatchItemSourceService`、Repository、Mapper、Entity及公共port仍由主流程唯一维护，派送专项不并修生产；提供者受控输入的组件测试不能代替真实provider与主流程的组合回归，Maven仍只由主流程执行。
+
+### 实托组成冻结的共同串行点
+
+当前运输组成须排除已由既有换标作废事务结束的申请历史，不沿其旧明细指针扩展实托闭包；真实库存位置仍完整保留，残余HOLD没有当前来源贡献解释时继续阻断。活跃、尚未取得排车资格的申请仍参加完整性核对。普通纯SKU的既有履约资格和库存生命周期保持原规则。
+
+草稿纯释放和续租入口（UNSELECT、RELEASE、CREATE_CONTAINER、REMOVE_CONTAINER）须先按原草稿冻结实托集合取得共同Serial，再读取逻辑和物理占用，并在等待后复核原租约；不重新要求当前来源业务资格。SELECT、SNAPSHOT及CONVERT继续遵循既有资源、申请、订单到Serial的完整锁序，不把Serial提前到来源锁之前。到期接管与原草稿动作共享该串行点，不能分别采用逻辑成员到物理占用、物理占用到逻辑成员的相反锁序。
+
+主流程已提出且总控冻结窄协议：`inventory/port/PhysicalPalletSerialPort.java`仅提供`void lock(List<Long> warehousePalletIds)`。永久表`ll_physical_pallet_guard`仅有真实全局`warehouse_pallet_id`主键与首次`created_at DATETIME(3)`，没有客户、状态、TTL或运输owner。调用方事务内对去重升序实托执行保留原时间的主键upsert及逐行FOR UPDATE，空目标也取得同一串行点；未关联实托的计划不伪造ID。
+
+原有资源/主单父锁之后，预读完整源目标组成，稳定取得全部申请、真实订单，再取得全部实托串行行，重读组成，最后库存及运输claim。新增申请、订单或实托必须整笔冲突，不能持锁后追加无序集合。仓内移动、原托保留、return/unbound都覆盖普通库存、原生退货及空目标；不得给仓内作业新增暂扣资格限制。退货远端physical.apply须置于门禁之后，原业务失败补偿在共同串行锁仍持有时完成。
+
+本有限包文件分配：既有B专项唯一新增inventory下上述port、`service/PhysicalPalletSerialService.java`、`repository/PhysicalPalletSerialRepository.java`、`mapper/PhysicalPalletSerialMapper.java`和对应真实Mapper/H2持久化测试，不修改排车/草稿消费者。主流程A唯一接入正式排车与草稿，并仍唯一维护公共排车模型及执行Maven。既有内部`native_fleet_script`唯一修改`palletops/service/PdaPalletOperationService.java`、其原直接测试，按必要最小范围修改本域Repository/Mapper及新增`PdaPalletDispatchFreezePersistenceTest.java`，不写inventory共同实现或dispatch/relabel提供者。SQL两基线与初始化合同总控唯一维护。各包先读取最近指引，交付准确SHA与未验证项；不得增加HTTP、状态协议或迁移。
+
+草稿后续接线按主流程明确交接再次细分：B唯一维护`DispatchDraftService.java`、`DispatchDraftRepository.java`、`DispatchDraftClaimMapper.java`、`DispatchDraftPersistenceTest.java`四文件，A确认当前未写且暂停这四文件；A保留完整来源解析、正式主流程、PDA及公共模型。B以`selectionGroup(warehouse, selection)`读取完整组，以`lockDraftSources(warehouse, 全部组成员)`锁定并复核，选择、解除、布局、释放、到期与转换不得拆开同一完整组；按物理实托共享claim并只计一次容量，按逻辑来源保留真实客户及箱数。源版本与组成必须服务端核验，不增加前端循环写或公开协议别名。永久串行点的草稿接入由该B四文件包消费A来源锁方法，覆盖上段原先由A统一接draft的安排，其他边界不变。`DispatchItemSourcePersistenceTest.java`仍B唯一维护，按A明确新增`relabel_round_key VARCHAR(128) NOT NULL`同步手写建表并保持原16场景；SQL仍根维护。
+
+### 既有预约接线的本轮授权
+
+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绑定/移货别名。
+- 用户最新明确取消排车的车辆预约：删除页面展示/输入、Update引用字段、详情字段、对应公开类型和拒绝占位分支，FBA预约不变；不保留旧字段别名或空字段，也不新增车辆预约表、创建API或日历业务。此前“保留权威关联、未定位时拒绝”的安排被本次裁定替代。
+
+共享SQL、OpenAPI、权限仍由总控集成，Maven仍由主后端唯一执行；不增加任务、不部署、不执行环境SQL或真实业务写入。
+
+本轮收口为减少串行等待，总控独占适配四个实际旧查询消费者：`exceptionorder/mapper/ReturnCartonStockReceiptMapper`、`inventory/mapper/ReturnStockReceiptMapper`、`delivery/mapper/DeliverySourceEvidenceMapper`、根`mapper/CustomerOrderProgressMapper`，并补齐同一旧任务客户头引用的`delivery/mapper/DeliveryOperationMapper.returnReceipts`，及直接查询测试`CustomerOrderProgressMapperTest`、`DeliverySourceEvidenceMapperTest`、`SharedDispatchReturnQueryTest`。仅消除已退出的主单/任务客户头、旧状态及发车列依赖，保留真实明细/扫码/订单/派送客户隔离与原数量规则；派送任务不并写移交的查询Mapper。原前端写者同步`CapacityInquiryTable`、`CapacityInquiryDialog`两处同一外接入车API的当前新建权限，保留其他三项独立权限。派送任务另独占`ReturnCartonReturnPersistenceTest`及主后端随后明确释放的`DispatchRepairWorkflowTest`的新模型夹具和构造器适配，主后端不并写该文件；现有归箱、逐SKU恢复、幂等、客户隔离、回滚和真实结案断言保留。总控另精确接手已交付19文件包内`FbaAppointmentPersistenceTest`、`FbaReceivingPersistenceTest`的transport.apply父命令键测试签名收敛，派送任务不并写这两个测试；其他17文件保持冻结。总控另唯一维护`DeliveryTransferService`及其直接测试：PDA解析改用真实整车Repository并保留绑定仓，取消出库不再被整车自动创建的唯一Fleet关系误阻断；ACTIVE/装车前/零真实扫码发运、子单未执行与费用门禁保留。本轮总控还收敛实际旧模型的直接查询消费者：`DispatchFeeCargoMapper`及`DispatchFeeCargoMapperTest`、`PlatformDispatchOutboundContractTest`；无生产调用的`DispatchCargoSourceQuery`删除，原真实来源断言转到现行FleetAdapter。另由总控唯一修改`LastlegOrderMapper.findDispatchStatuses`、`InventoryCommandMapper.shipmentSources`、`InboundPlanQueryMapper.SCHEDULED_DISPATCH`、`AppointmentImpactRelationMapper.dispatches`及四份直接查询测试；仅调整共享头身份/阶段，明细客户、真实库存命令、仓库及取消边界继续核验，不改预约创建。`FleetAppointmentImpactMapper`由主后端单写同一模型的绑定查询，双方不并写。没有新增异常、库存、外接或预约业务。
+
+### 本轮测试环境实施授权补充
+
+用户随后明确授权总控部署测试环境、操作测试数据库、调用真实HTTP，并使用内置浏览器登录验收样式、交互及请求量；Admin/Client按1920×1080，国内/海外PDA按390×848。此前仅离线检查、默认不部署和由用户截图的限制在此精确范围内由新授权取代。目标仍为本契约所属TEST项目及当前排车改造，不接管日历新增预约，不操作开发或生产环境。总控统一协调发布、SQL及环境写入，先核对匹配源码、结构、权限和现有运行版本，执行后按实际证据维护环境主契约；部署成功、HTTP通过和浏览器验收分别记录。
+
+本轮换标出库取消修正的唯一实现者为总控内部`native_capacity_consumers`，只写`DeliveryTransferService.java`、`DeliveryCancellationRepository.java`及`ReturnOutboundClosureTest.java`；覆盖原生箱及普通仓托，保留原配送方式、已确认成果及库存事实，TRUCK退回待排车，其他方式退回待独立安排。不把非TRUCK来源改成TRUCK、不重跑换标完工确认或新增旧独立出库安排API。非TRUCK再次独立安排入口的接线尚不属于本次取消修正，不以取消持久化成功推定再次安排已完成。后端其他写者冻结这三文件，Maven仍由主后端统一执行。
+
+## 十 日历新增预约的范围分离
+
+用户澄清“新增预约”应放在预约日历，并指定由对话 `01a15231-2507-7802-8015-34b01f5eb2c4` 处理，明确本总控不用接管。三个排车任务不修改预约日历的新增预约表单、权威预约模型或预约新建API，也不承担其设计和矩阵；本批只处理整车改造确实影响的既有预约读取/关联消费者，有限接线写权见第九节，不自行接管新增预约或跨对话派工。
+
+此前关于FBA预约可先保存、后关联真实货物和排车，以及车辆可先独立预约、后关联排车的答复仅保留为日历需求输入，其后续规则和实现由用户指定对话处理；此处不继续整理日历方案、不创建新任务、不跨对话转派，也不删除已经存在的预约功能或关联。

海外仓业务/排车流程修复规划.md

@@ -0,0 +1,145 @@
+# 排车流程修复规划
+
+本规划覆盖海外仓预排、客户排车、共享车次、PDA 拣货出库、派送及撤销之间的衔接。目标是修复取消后的占用死路、派送状态旁路、换标漏排及合托来源识别，补齐与服务端一致的前端操作入口。
+
+2026-10-18 用户明确：当前规划对话只维护文档和分工，由指定的三个修复对话实施。本文是修改目标、文件边界和验收要求，不表示修复完成。部署状态、实际验证结果和未关闭环境验收项继续唯一维护在[测试环境主契约](../测试环境单机部署与配置契约.md)及适用的[统一认证与服务通信契约](../统一认证与服务通信契约.md)。
+
+## 一、保持的业务主链
+
+1. 从入仓单或已确认可出库的换标货选择托盘，创建预排分组和客户排车单。
+2. 同起运仓的客户排车关联共享车次，分配车辆、司机和卸货站；跨客户共车保留各自库存与费用归属。
+3. 每张客户排车单分别完成调度审核，PDA 才能拣货并逐明细核平。
+4. 转派送可在待发车、拣货中或待发车就绪阶段执行，须早于发车；生成一张出库单和按目的地拆分的派送单，费用按原覆盖及外接约定复核。
+5. 确认实际装载并通过理货审核，PDA 按车次统一发车；任一子单失败，全车事务回滚。
+6. 签收或真实退回核平后结案，车辆、司机分别记录实际结束事实并释放。
+
+本批保留预约稳定批次、逐票分配、工作事项通知、真实来源、客户隔离和仓绑定，不改为独立排车直接发车，不引入自动路线优化或换标分批履约新功能。
+
+## 二、必须修复的问题与落点
+
+下列路径中的 `java/` 指 `../../baiyue-firstleg/lastleg-service/src/main/java/com/baiyue/lastleg/`，`admin/` 指 `../../apps/admin-web/src/modules/overseas-warehouse/`。行号以评估时源码为定位参考，开工以当前符号和实际调用核对。
+
+### DR-01 取消出库后释放排车并重新安排
+
+**触发与后果：** 未拣货排车转派送，解除车次关联并取消出库后，出库记录仍关联排车。排车取消和移托只判断出库记录存在，再次转派送又重放旧取消单，形成占用死路。
+
+**主要修改位置：**
+
+- `java/delivery/service/DeliveryTransferService.java`：`cancelOutbound`、`transferResolved`、`replayTransfer`。
+- `java/delivery/mapper/OutboundOrderMapper.java`：`findByDispatch`、`lockByDispatch` 及直接消费者。
+- `java/dispatch/service/DispatchService.java`：`cancel`、`requirePalletEditingAllowed`、草稿正式锁释放。
+- `java/dispatch/fleet/DispatchFleetAdapter.java` 和 `java/dispatch/pda/service/DispatchPdaWorkflowService.java`：核对取消单不可被发车、结案查询当作有效单据。
+- `admin/pages/OutboundsView.vue`、`admin/pages/DispatchesView.vue`：取消顺序、下一步和失败提示。
+
+**本批目标：** 先解除未执行车次关联，再取消出库，最后取消原排车并释放占用；货物可通过新预排重新安排。保留原取消单据、来源、费用处理与操作历史，不删除历史以绕过关联。不要求复用已取消排车重新生成出库；相同请求重放必须明确返回原取消结果，不能提示重新建单成功。活动关联判断与历史查询应分清语义，不能全局过滤取消记录后破坏审计。
+
+**通过条件：** 完整执行上述顺序后，原活动排车锁和有效预约运输占用释放，原单据仍可追溯；同货物可重新预排。重复取消不重复撤销费用、不释放新排车占用；已有拣货、发车、其他客户或仍有车次关联时正确拒绝并保持事务不变量。财务作废仍以 Finance 确认结果为准。
+
+### DR-02 派送状态必须服从实际出库事实
+
+**触发与后果：** 发车未自动进入派送中时，派送仍为 `WAIT_DELIVERY`，普通状态编辑允许直接改 `CANCELLED`。后续签收、退回和车次结案均受阻；提前取消派送也可能未被发车门禁发现。
+
+**主要修改位置：**
+
+- `java/customervisit/service/CustomerVisitService.java`：`updateDeliveryStatus`。
+- `java/delivery/model/DeliveryStatusPolicy.java`：人工状态转移和 `allowedActions`。
+- `java/delivery/service/DeliveryTransferService.java`：统一取消入口及列表/详情能力返回。
+- `java/dispatch/fleet/DispatchFleetAdapter.java`：`manifest`、`completion`。
+- `java/dispatch/pda/service/DispatchPdaWorkflowService.java`：发车前一致性复核。
+- `admin/pages/DeliveryOrdersView.vue`、对应 API/类型及直接测试。
+
+**本批目标：** 取消统一经未执行出库的聚合命令，不能由普通派送状态编辑单独制造取消终态。已出库/发车禁止直接取消；开始派送、拒签应核对实际出库事实。发车要求关联派送完整且均可执行。签收仍由合法签收资料触发，拒签仍经真实退回处理，不开放人工直接完成或任意恢复终态。
+
+**通过条件：** 未出库提前开始/拒签、已发车取消均被后端拒绝且页面不提供误导入口；并发取消与发车只能有一个合法结果，不能出现已发车加取消派送。正常签收、部分退回、签收后另退货、车次结案和原键重放保持原语义。
+
+### DR-03 普通换标必须完整选择本申请托盘
+
+**触发与后果：** 一张普通换标单有两托，只选一托也能预排；服务端随后把整张申请改为 `PRE_DISPATCH_CREATED`，剩余托盘从候选中消失。
+
+**主要修改位置：**
+
+- `java/dispatch/service/DispatchService.java`：`preArrangeRelabel`。
+- `java/dispatch/mapper/DispatchCandidateMapper.java`：`relabelAvailable`、`markRelabelPreDispatched`、`restoreRelabelPreDispatch`。
+- `admin/components/SmartDispatchDialog.vue`：换标候选、提交检查和提示。
+
+**本批最小修复目标：** 沿用当前整单状态机，普通换标与退货换标均须一次选择本申请全部应排托盘。服务端锁定申请后重新计算完整集合并校验，前端提示不能替代服务端检查。拒绝部分选择时不得建排车、推进申请或残留占用；不在本批扩展换标分批发运。
+
+**通过条件：** 两托选一托拒绝且零副作用；完整两托成功；重复托盘、候选变更、不同申请混选正确拒绝；取消原未执行排车后可完整重排。确认前后并发提交只能产生一张有效排车。
+
+### DR-04 合托后按真实来源绑定外接货和约定运费
+
+**已确认代码缺口：** 候选的入仓码为展示性单来源，箱数却为整托实际库存；`sourceCargo` 和外接运费预览继续用这组值识别原承运登记。同客户、同目的地的普通货与外接货合托后，存在漏识别外接来源或误报实收量不符的风险。实际整条混托发运后果尚需组合测试证明。
+
+**主要修改位置：**
+
+- `java/dispatch/fleet/DispatchFleetAdapter.java`：`sourceCargo`。
+- `java/fleet/trip/FleetBookingReservations.java`：`bindIncoming`。
+- `java/fleet/trip/FleetBookingFreight.java`：`preview`。
+- `java/delivery/service/DeliveryTransferService.java`：`externalFreight`。
+- 按实际引用核对已有 `DispatchFeeCargoMapper`、库存组成与拣货来源接口；需要持久查询时按现有分层新增最小 Repository/Mapper，不跨库读取。
+- `java/palletops/service/PdaPalletOperationService.java` 只在证据证明需要维护承运实收的拆合托约束时修改，不扩展通用库内业务。
+
+**本批目标：** 先用可执行测试固化普通来源/外接来源分别成为展示来源的两种场景。绑定和运费按实际客户、来源、目的地和本次箱数核对，展示入仓码不能替代真实组成。承运托盘证据因拆合托变化时，给出已有业务可执行的重新核对路径，不放宽承诺车次和完整实收量限制。
+
+**通过条件：** 外接承诺不得遗漏或错误跨车绑定；逐来源数量守恒，容量不重复占位；约定运费不遗漏、不重复发布，普通货仍执行其独立费用规则。不能只修展示名称或把无法识别的外接货当普通货静默通过。
+
+前端还须核对 `overseas-master-data/components/TripBookingPanel.vue` 的实收确认入口：服务端允许尚未绑定排车的 `RECEIVED` 重新核对时，页面应按相同状态、权限和车次限制开放，并复用现有确认接口、当前版本和新请求键。拆合托后的新实托、重量/体积及原承诺须重新核验，不因仅扩大按钮可见条件就认定整链完成。
+
+### DR-05 页面动作与服务端门禁一致
+
+**主要修改位置：** `admin/pages/DispatchesView.vue` 的 `canEdit/canCancel/canTransfer`、移托和车次跳转；`admin/pages/DispatchDetailView.vue`、`admin/api/dispatches.ts` 及必要 DTO；派送/出库页面只沿受影响操作跟进。
+
+**本批目标：** 已绑定车次、已有有效出库、已拣货等限制在进入写操作前明确展示，提供处理原车次/出库的准确入口。优先消费已有服务端能力；缺失时由后端统一补充最小动作资格与阻断原因，前端不得另建一套状态机。转派送成功重放不应冒称新生成单据。
+
+**通过条件：** 列表、详情和服务端一致；只有列表权限的用户保持只读；已取消、已关联、已转派送和并发刷新场景不能出现误导性的成功提示。保留已确认页面承载方式和操作列位置。
+
+### DR-06 换标草稿锁定与恢复必须真实
+
+**主要修改位置：** `admin/components/SmartDispatchDialog.vue` 的移入/移除、关闭重开、草稿查询错误处理及“已锁定”提示；如接入统一换标草稿锁，由后端任务独占对应 `DispatchService`、DTO、Mapper 和契约实现。
+
+**本批目标：** 不再对仅存浏览器的换标选择显示服务端已锁定。后端先明确是否能在现有统一草稿模型中锁定该来源，再由前端接入；未持久化的选择必须明确其状态，不增加第二套占用协议。草稿读取失败显示独立错误和重试，不得用空数组伪装无草稿并丢失原选择。
+
+**通过条件：** 普通、退货、换标三个来源的展示与实际锁行为相符；刷新/关窗/重开、超时、锁冲突和查询失败时原选择及占用可解释、可恢复或明确释放；后端最终防重复能力仍保留。
+
+## 三、需先证实的来源边界
+
+`RETURN_RELABEL` 拣货以 `returnCartonId` 记账，而 `ExceptionOrderService.appendDispatchPickSources` 跳过无 `inventoryPositionId` 的拣货记录。独立审查任务应核实是否存在当前正式替代入口，并尝试用组合测试证明拒签后能否取回原箱来源。
+
+如确认缺口，由后端任务在既有异常退回链中补真实来源、客户/数量校验及原子入账，前端只接入同一候选契约；不可虚构普通库存仓位替代退货箱。尚未证实前不登记为普通排车全局故障，也不扩展一整套新退货流程。
+
+`PLAN` 提前预排能力、自动配车优化、换标分批和页面全面重做不在本批实施范围；发现相关事实时只记录依赖或另列业务决策。
+
+## 四、三个对话的唯一分工
+
+所有任务固定使用 TEST 项目 `c64729ff-6710-43c6-8ef2-d84e9666cc1e`、host `local`、工作目录 `C:/Users/BY-OY/Desktop/code/chongchong-global`，保持当前分支。任务身份与授权集中维护在[独立任务协作登记](../独立任务协作登记.md)。
+
+| 对话 | 唯一职责 | 写入范围与交付 |
+| --- | --- | --- |
+| 排车修复 | 后端实现和代码集成负责人 | DR-01 至 DR-06 涉及的 Lastleg 生产代码、直接测试、DTO/OpenAPI及必要数据库结构定义；先修前三项，再收口已证明的来源问题。唯一维护共享后端文件、后端契约和必要公共测试支撑；组织串行 Maven 检查。不得修改前端或本规划。 |
+| 排车修复-2 | Admin/PDA 前端实现 | 本文列出的海外仓页面、组件、API/类型和相邻测试；必要时沿公开入口修改车次组件、海外 PDA 门禁消费。先修独立草稿错误提示，再接入稳定后端契约。不修改后端和共享基础样式，不扩大到预约页面。 |
+| 排车修复-3 | 独立审查和连续场景回归 | 只读审查后端/前端差异；唯一可新增或修改 `baiyue-firstleg/lastleg-service/src/test/java/com/baiyue/lastleg/dispatch/service/DispatchRepairWorkflowTest.java`。该文件先核实不存在其他写入者；不改生产代码、已有测试、共享 fixture、POM、SQL或前端。回归使用现有测试框架与真实被测行为，不能用替身把待验证门禁模拟为成功。 |
+
+当前规划对话唯一维护本规划、协作登记和最小文档路由，读取三个对话的交付，不接管代码、SQL或构建。各执行者在自己的对话报告；可只读查看本批另外两个指定对话的进展及冻结交付，避免等待已经具备的输入。本轮未授权它们主动向其他对话发消息，接口与测试窗口由规划对话转达。独立审查不等于真实环境验收。
+
+### 文件重叠与并行事项
+
+- 先读取各自适用 AGENTS 和当前差异，保留所有未提交修改。`DispatchService`、`DeliveryTransferService`、`DispatchFleetAdapter` 等后端热点始终只由“排车修复”写入；前端热点只由“排车修复-2”写入；独立组合测试只由“排车修复-3”写入。
+- 本批最新分工仅适用于本文缺陷，不接管预约核心、工作事项、来源同步性能或其他在行任务。不得删除已有预约批次分配和工作通知接线。
+- 派工时已知“预约”对话正在执行固定 18 文件的提交、TEST Lastleg 发布及有限采样。其环境授权不传递给本批。开工重新核对活动写者、实际差异和构建进程；与活动任务重叠的文件或共享构建先保持只读，继续无冲突工作并报告精确范围，不能覆盖或使用全目录暂存混入其发布。
+- 后端 Maven 仅由“排车修复”执行，运行前确认没有其他任务占用同一后端构建目录；独立测试作者交付代码后停止写入，负责人再统一编译执行。Admin检查由“排车修复-2”执行，避免同应用并行全量构建。
+- 公共 IAM、统一 SQL、Gateway、根导航等共享入口不因本次派工自动转移写权。若确需调整，先交付精确变更提案，由规划对话协调唯一写者后再由代码负责人落实；规划对话自身不修改这些文件。
+- 不创建新用户可见对话、分支、worktree 或项目副本；不复制依赖，不提交或推送，不启动本地服务，不执行 SQL、真实 HTTP、部署或环境数据修改。
+
+## 五、依赖顺序与交付门槛
+
+1. 后端先冻结取消路径、人工派送动作、整单换标集合校验及最小能力字段；前端可先处理不依赖接口的错误提示和误导文案；审查任务先建立连续场景与缺口清单。
+2. 前端只按实际后端契约接入；新增/改名/删除接口或访问域时，由后端同步 Controller、DTO、OpenAPI、权限及 Gateway 合同，不以 Mock 通过代替真实契约。
+3. 三个执行者交付精确文件清单、修改行为、验证命令和限制。审查绑定稳定差异/哈希；审查期间相关文件停止修改，发现由原唯一写者修复。
+   候选冻结是复审交接点，不能代替本批完成。有已知失败时区分测试夹具、生产缺陷和环境待验，交给唯一写者继续处理；不得删除有效正向断言或把仍可离线验证的事项全部转成环境待验。测试作者先修自有夹具并明确停止写入，后端负责人再运行；各自阶段结果与下一依赖在本对话明示。
+4. 至少覆盖 DR-01 至 DR-03 的完整连续场景，以及 DR-04 两种合托来源、DR-05 状态/权限一致、DR-06 草稿失败恢复。失败、重放、并发和客户隔离不只检查最后状态，还要检查单据、占用、库存和费用副作用。
+5. 后端负责人运行受影响测试及会编译测试源码的检查，前端运行相邻测试、类型检查和应用要求的完整门禁；API/Mapper/索引变化按适用指引补门禁。未改输入不重复跑无关检查。
+6. 本地实现、离线测试、独立审查、环境部署、真实 HTTP 和人工视觉验收分别报告。页面视觉留待用户提供 1920×1080、100% 截图；本轮不自行生成“视觉通过”结论。未经后续环境授权，不安排部署或写入式验收脚本执行。
+
+## 六、执行者回报格式
+
+每个对话在自身最终回复列明：处理的 DR 编号；实际改动文件与关键行为；接口/Schema/权限是否变化；已运行命令和结果；独立审查发现与未处理项；需要其他写者配合的精确文件或契约；建议部署单元及尚未执行的环境验收。不要把计划写成已实现，不复制密钥、Token、环境凭据或客户数据。

海外仓业务/美国预约管理统一总览与优化方案.md

@@ -0,0 +1,457 @@
+# 美国预约管理统一总览与优化方案
+
+日期：2026-10-09  
+文档性质：需求梳理与设计建议。统一展示美国段各类预约是原方案整体方向；本轮用户进一步提出开船后提前安排提柜、到仓、FBA送仓与车次余位拼车的目标。下述页面、状态、字段与实施方式供产品评审，不代表已确认全部细则、已实现或已发布。现行预约、到仓与拼车规则仍以各自维护入口为准；需要调整的合同在本文明确列为设计缺口。部署与验收状态仍以[测试环境单机部署与配置契约](../测试环境单机部署与配置契约.md)为准。
+
+本文维护在途筹划、对外预约与变化跟进；[拼车数据入口与操作简化评估草案](拼车数据入口与操作简化评估草案.md)维护销售接货及共用车次操作简化。两份文档保留独立业务范围，跨方案职责与交接顺序仅在本文[第九节](#九-建议实施顺序与协同分工)维护；不另建重复总方案。用户后续已安排A/B实施，原“仅整理文档、不启动开发”的阶段限制已被该授权替代；本方案仍是目标定义，实际部署与验收只以环境主契约为准。
+
+2026-10-15 本轮预约工作日历已授权并行开发，接口及文件边界见[预约工作日历开发协作契约](预约工作日历开发协作契约.md)。本文早期的整票限制描述用于定位实现缺口，不限制本轮分批目标；第九节原 A/B 分工不覆盖本轮三任务登记。
+
+2026-10-16 用户已确认 V13，并要求按现有任务继续开发。日历首屏、多客户共车、分批后送、改期取消、重新预约和未定日期跟进的正式规则统一维护在[预约工作日历 V13 变更说明](预约工作日历V13变更说明.md)。以下 V11—V13 评审记录保留当时状态，不再代表尚待原型确认，也不代表实现或环境验收完成。
+
+## 2026-10-16 · V13 后送与重约评审（待用户确认）
+
+V13 原型沿用下方同一路径。本轮下述浏览器路径及此前 24 项原型回归已通过。本节仅为原型评审记录，正式变更文档待用户确认，不代表业务代码、接口或环境完成验收，也不新增开发授权。
+
+- 乙 160 箱移出后，可重新约仓、安排新车并登记发车；甲、丁原车仍为 120 箱，原预约不变。本次取消安排仍保留货物及送货需求。
+- 后送 60 箱可单送至签收结束，也可与另一客户 40 箱组成新车并走完整条执行链。若仅从这 60 箱中安排 40 箱，原车客户卡片分别显示 20 箱待排和 40 箱新批，各一次；沿分配去向追踪，不显示失效的 0 箱事项。确认后原车仍为 220 箱，乙的各批合计保持 160 箱。
+- 整份共约取消后清除失效目标，可在原批次、原车上一次办理重新共约或分别预约，明确本次覆盖范围；新共约形成新分组，再次改期、取消按新范围处理，已另约客户自动排除。退出的乙若复用甲、丁仍在使用的旧约号，会被阻止。
+- 新增“与同仓待排货物一起安排”，只预选当前后送 60 箱，再由用户选择其他货物。尚未落实的单客户新批次隐藏多余变化入口；独立车辆的下一步使用本批车辆文案，不再称为共用车辆。
+
+## 2026-10-16 · V12 共车变化原型评审补充（待用户确认）
+
+原型沿用下方同一路径，点击“演示场景 → 共车后：客户改期 / 取消 / 缺货”。本轮新增 10 项原型浏览器检查通过，结论仅限原型；正式变更文档待用户确认，不代表业务代码、接口或测试环境完成验收，也不新增开发授权。
+
+- 新变化场景使用 CC020 / TR020，甲 80、乙 160、丁 40，共 280 箱；原 CC001 / CC003 多客户选货流程保留，两段演示分别评审。
+- 独立预约下，乙改期或取消本次安排后，160 箱移出原车继续跟进；甲、丁合计 120 箱的预约不变。乙先送 100、后送 60 时，原车为 220 箱，逐来源数量守恒；填 0 可整批移出。本次取消仅取消该次安排，保留货物和送货需求，不表示订单取消或客户撤销运输需求。
+- 共用预约下，单客户移出须明确取得仓库同意；整份预约改期同步 3 个客户，整份取消列出 3 客户加 1 车的影响，已取消预约不能再选择保留。原车安排核对一次，无实际变化的保存不重复触发复核。
+- 执行页货未齐可直接进入对应客户处理；尚未获回复可保存待确认内容及勾选，原值保留并阻止发车，再进入可直接续办。本轮夏令时切换中不存在的当地时间样例已验证阻塞；这些演示结果不代替完整权限、并发或时间规则验收。
+
+## 2026-10-16 · V11 原型评审补充（待用户确认）
+
+原型入口：`C:/Users/BY-OY/.codex/visualizations/2026/10/14/01a13a8d-e968-7962-906b-1a514792d921/appointment-calendar-guided.html`。本节仅供 V11 原型评审，不是正式变更文档，不新增开发或部署授权；原方案正文、已完成实现及技术验收事实保留。
+
+**现有能力：不同客户同目的仓可以共用一车。** 本轮改善预约页一次选货、连续办理预约与共车的操作，各客户来源、数量与结果仍分别保留；同车不等于共用预约号，已有核实、分批和返回上下文也不列为新增。
+
+**原遗漏**指前两轮原型中海上提前安排、取消后跟进、延期逐项处理及部分失败续办的交互分支；**操作改善**指多客户一次选量、多行分批、计划回复确认连续填写和保存后下一步，不代表既有业务功能不存在。
+
+### 五条可走通的原型评审路径
+
+1. **演示场景 → 海上提前安排。** 打开 CC007，核对已有预排起止窗口，填写意向车队和联系结果后保存，再用下一步继续；该柜已有目标，不属于未定日期。此场景码头尚未开放正式预约，可以留计划和回复，不能登记为已确认。
+
+2. **演示场景 → 中转分批 / 多客户共车。** 选择 CC001 / CC003 示例货物，共 280 箱（甲 80、乙 160、丁 40），按来源选量后统一填写车辆；默认分别保留客户预约号，只有仓库明确允许才选择共用约号。保存后逐客户查看结果并继续车辆安排；另可独立评审原批分成 3 批，核对逐来源自动余量、各批目标和总量守恒。
+
+3. **演示场景 → 整柜直送 / 还空。** CC002 的 TR002 同时承担提柜和直送，仓库收货确认独立办理，不重复约车。沿下一步查看执行条件：实际目的仓卸空前不能还空；还空转交新车队后须再次明确接手，不能沿用原车队的接手结果。
+
+4. **演示场景 → 未定日期 / 取消。** 打开 CC004 客户仓收货，目标日期留空，先保存资料或回复；取得结果后登记确认，再取消预约，核对事项回到未定日期且继续保留跟进。客户仓按真实要求选择是否预约，不强迫填写 FBA 货件号；无需预约时补收货要求，不伪造约号或确认结果。
+
+5. **演示场景 → 延期逐项处理。** 模拟 CC003 备货延期，已完成提柜、卸柜保持原事实，只核对未执行的送仓与用车。逐项选择“保留原安排”“重新约时间”或“调整本批货物”；调整货物仅把部分数量移出至未定日期，剩余货量重新取得确认，不是任意换入新货。处理当前项后继续其他影响项；无实际变化的保存和关闭本项复核不重复触发关联复核。
+
+### 待确认边界与未演示规则
+
+- 当前异常演示仅有共车表单的“第二客户组已保存货物，但关联车辆失败”和“模拟当前账号无写入权限”。前者只重试失败关联，保留已保存货物与数量占用；后者保留输入，不代表完整权限与异常验收。
+- 请求结果未知、并发版本冲突、原幂等请求重试及新影响版本保护属于实施建议，尚无原型实际模拟，待实现验证。各类型动态开放条件也未完整模拟，当前仅演示 CC007 海上码头未开放阻塞与确认字段校验。
+- 默认负责人、跟进日期、分批行数和选择范围仍待用户确认；负责人仅有 3 名授权示例，DST 仅有特定演示日期的歧义选择。原型通过不代替接口、权限、数量或真实执行门禁验收。
+
+## 一 页面定位与核心结论
+
+“预约管理—预约列表”应成为美国段提前筹划和预约跟进的统一入口。从真实开船及在途货物清单出发，让运营知道：哪些柜快到了、各目的仓有多少待送货、何时有望备妥、现在该联系谁、哪些已经约成、哪些车还有可发布的余位。
+
+范围包括提柜、海外仓接仓卸柜、用车、FBA及其他送货、还空等美国段事项。保留现有菜单名称，页面标题使用“预约工作日历”；默认日历首屏，待办、货柜和送货批次明细承接具体操作。尚未约到时间及未定日期的工作必须能被看到。
+
+统一的是查看入口、关联信息和操作入口。提柜、车次、派送、收货仍由各自业务模块保存权威事实；总览读取和联查这些记录，修改时回到对应业务命令，避免运营在多个页面重复维护同一事实。
+
+需要区分三种事情：
+
+| 事项 | 例子 | 总览如何表达 |
+|---|---|---|
+| 对外预约 | 码头提柜时段、FBA收货时段、客户现场收货约定 | 显示预约状态、当地时间、地点、对方确认信息 |
+| 内部作业计划 | 安排车辆司机、预计装车、计划发车 | 显示执行准备和资源安排，不冒充对外预约成功 |
+| 参考节点与提醒 | 预计到港、实际到港、还柜截止 | 单独图层或待办提示，不计入预约成功数量 |
+
+**“约车送FBA”通常同时涉及运输安排和FBA收货预约。** 车已安排不代表仓库已确认收货；仓库约好也不代表货齐、车到、可以发车。页面应把两者关联展示，分别保留状态。
+
+### 1.1 从开船开始并行筹划
+
+| 阶段 | 系统应提供的信息与建议动作 | 人工负责的决定 |
+|---|---|---|
+| 已开船、货在海上 | 读取真实柜内货物、接柜海外仓、目的FBA仓、最新ETA及来源；形成提柜联系待办和送仓货量预览 | 核对接仓地点、货量和预计时间，指定负责人 |
+| 预计到港前 | 展示目标提柜/到仓窗口，按目的仓和货物可备妥窗口汇总；准备联系资料和约车需求 | 联系拖车公司、接仓方、送货承运商；允许先记录意向和对方反馈 |
+| 对方开放预约且资料满足 | 提示可申请、缺资料、等待开放或等待对方回复；保留申请时的货物范围 | 人工提交预约，取得对方结果后登记确认时段、确认号及凭据 |
+| 货到仓前后 | 核对实际提柜、到仓、卸柜/理货与预计货量差异；把已选在途货关联到后续真实作业单据 | 确认送货批次、承运车次和时间；处理少货、换标未完或延期 |
+| 车次具备发布条件 | 带入有效的自有货计划占用和逐目的站剩余容量，链接现有拼车需求池 | 调度确认发布；销售登记意向，调度确认承运才占位 |
+
+提柜沟通、收货仓排班、FBA预约准备和承运商询车可以并行。正式提柜、实收入库、拣货和发车仍按实际作业条件执行，不因提前安排而推进完成状态。
+
+### 1.2 时间按用途分开，预约按对方规则办理
+
+建议展示一条可追溯的时间链：**预计到港 → 预计可提柜 → 预计到海外仓 → 预计货物可备妥 → 目标送达 → 对方确认时段**。前三项也不能相互替代。
+
+- ETA来自当前权威船节点，保留来源、更新时间和变更前后值。未查到ETA时进入“待补到港预报”，不直接用开船日加固定航程伪造。
+- 预计可提柜需考虑卸船、清关/放行及码头可提信息；预计到仓还涉及拖车与接仓安排；货物可备妥还涉及卸柜、理货、打托或换标。可以由运营维护预计区间和依据，不要求首版建设复杂预测引擎。
+- 目标送达需在预计备妥后留出装车、行驶和业务缓冲。先做可解释的区间预排；按港口、仓库、线路维护经验参数时，应允许人工核对，不能全美国统一写死“到港后两天送FBA”。
+- 将“希望约的时间”“已申请的时间”“对方确认的时间”分开；可以提前联系，但正式可申请时间取决于具体码头、仓库和承运商。
+- 每个预约地点按需维护预约方式、联系人、当地时区、开放条件、所需材料、改期/取消要求和规则核对日期。外部账号凭据不放在预约备注里。
+
+外部规则核对（2026-10-09）：[APM Terminals洛杉矶预约说明](https://akamai.apmterminals.com/en/los-angeles/online-services/truck-appointment-system)要求进口柜卸船后才能设置提柜预约，说明“提前安排拖车”和“码头正式约号”可能发生在不同时间；不能将这一家码头的条件推广为所有港口。[Amazon美国Carrier Central手册](https://images-na.ssl-images-amazon.com/images/G/01/magicarp/common/Carrier_Central_Manual_USAmazon.pdf)区分申请日期与授予时段，要求承运商有把握按约送达，并禁止使用货件资料建立占坑或重复预约。本文据此建议先做好内部预排，再按对应机构条件确认，不预设“开船当天即可拿到所有正式预约”。
+
+### 1.3 以送货批次连接货物、预约和车次
+
+建议在现有业务内补齐“送货批次”的计划关系：按**实际接货海外仓 + 目的FBA仓/准确收货地址 + 可备妥时间窗口 + 运输与收货要求**组织候选，再由运营选择。它表示这批货打算一起送，不能代替客户订单、库存、车次或对方预约。优先复用现有预约、货物和排车关系承载，选货与保存安排意向一次完成，不要求运营额外手工建一张中间单；是否需要新增持久化实体在实现评审中确定。
+
+- 同一柜按目的仓拆成不同候选组；不同柜可以在同一接货仓、相容时间窗口内合并。首版默认只合并同一目的站，跨站同车由调度沿既有路线能力明确安排。
+- 同时展示在途预报、已到仓未备妥、已备妥三类货量，以及已有安排与尚待安排量。箱数、预计实托、预计托位、重量、体积分别表达；未知保持未知，不以头程托数冒充海外最终托位。
+- 选货必须关联稳定来源货物明细及本次数量，并检查已有有效安排；建入库计划或收货后延续同一来源关系，不再把这批货计为新增需求。现行模型不能拆分同一明细行时，首版仍整行选择，不在页面虚构拆批能力。
+- 对FBA申请，系统准备已有货件号、目的仓、箱/托等清单；缺少该机构要求的资料时显示缺项，不能只凭“有多少托去ONT8”就标记可正式申请。
+- 内部预排允许货未到仓、司机未定、外部约号未取得；这些缺项应作为跟进事项。转成正式承诺和现场执行时，再核对对应阶段条件。
+
+例如：两个在途柜分别有同一接仓点、相近备妥窗口的ONT8货物，预计占10和8托位，可人工合成一个18托位送货批次。选用实际容量为30托位的车后，还须校验重量、体积和已确认外接占位；若同一路段三维容量均允许，才可能发布12托位。一个柜延期时应明确指出受影响的这10托位、预约及车次，由调度决定等货、换货或改期，不能自动拆单或更改对方约定。数字只作业务示例，不是默认车型或固定容量。
+
+## 二 当前能力与缺口
+
+以下为当前源码入口盘点，属于实现结构判断，不代替环境验收。
+
+| 业务 | 已有承载 | 当前信息基础 | 统一总览的缺口 |
+|---|---|---|---|
+| FBA送仓预约 | Lastleg入仓计划预约；Admin预约日历 | 预约号、目的仓、开始/结束时间、预计装车时间、状态、跨客户货物明细 | 当前总览主要覆盖这一类；排车的预约字段与预约主记录分开维护 |
+| 船舶到港 | Firstleg到港日历 | 预计/实际到港、柜号、船名航次 | 已显示，但属于参考节点，需要来源与类型标识 |
+| 码头拖车提柜 | Firstleg目的港码头拖车；海外清关提柜 | 车队、预约提柜时间、实际提柜、还空信息、允许操作 | 尚未接入预约日历；现有查询主要按柜次ID读取，不能直接当全美国按日期查询 |
+| 海外仓预计到仓 | Lastleg柜级到仓接口 | 预计到仓、PDA实际到仓、版本 | 预计到仓不等于收货仓确认的预约时段；不能直接标成“已预约” |
+| 车辆和司机安排 | Lastleg共享车次 | 计划发车、预计司机结束、车/司机、站点、审核、实际装载 | 尚未接入总览；车次是运输执行载体，不是单一收货预约 |
+| 普通送货及FBA派送 | Lastleg派送单 | 计划送达、目的仓/地址、关联排车、承运资源、签收 | 派送计划时间不能直接作为对方确认时间；需关联具体收货预约 |
+| 外接货承运预订 | 车次外接预订 | 客户、货量、既有卸货站、确认承运、来货实收 | 确认承运不等于目的地预约确认；不应重复生成一条同义送仓预约 |
+| 本土卡车、本土散板 | 海外业务订单 | 需求日期、目的地、联系信息、订单及车次关联 | 需求日期不是精确预约时段；缺少时段时应显示“待确认时间” |
+| 内部拼车需求池 | 共享车次余位发布、销售意向与外接预订 | 已有专门开发契约和实现入口 | 预约页缺少与车次发布资格、余位和销售跟进的衔接；应复用现有池，不能再建一套 |
+
+当前页面主要从“已经有日期的预约”出发；用户需要从“还在海上的货及尚未约好的工作”出发。关键缺口是开船后的待办生成、按目的仓归集的在途货量、可备妥窗口、人工联系记录，以及船期变化对既有安排的影响。
+
+本轮已读到的当前规则还提示两个实施边界：FBA预约以入仓计划明细为选择对象；柜级预计到仓在已有入库计划后锁定。提前规划不能靠提前伪造收货，也不能直接把持续变化的ETA写进已冻结的到仓字段。相关源码核对与建议见第八节。
+
+## 三 统一展示的业务范围
+
+### 核心范围
+
+| 类型 | 一条记录代表什么 | 关联对象 | 创建或维护方式建议 |
+|---|---|---|---|
+| 码头提柜预约 | 某柜在某码头的一次提柜预约 | 柜次、集装箱、码头、承运车队，必要时关联运输任务 | 选择已有货柜，自动带入柜与港信息；填写时段及确认信息 |
+| 海外仓接仓预约 | 接仓方接受某柜/批来货的到仓卸货时段 | 接柜海外仓、柜次或来货单、运输安排 | 预计到仓作为参考；人工联系仓库，单独登记仓库确认的接收时段 |
+| 用车与装车安排 | 一个车次的装车/出发安排 | 车次、车/司机或外包车队、起点、站点、客户排车 | 选择或关联车次，复用资源分配、审核和容量校验 |
+| FBA收货预约 | 某FBA仓在某时段接收一批货 | 多客户入仓货物、预约主记录、承运车次/站点 | 搜索仓库，选择同仓货物，登记收货预约 |
+| 普通客户送货预约 | 某客户地址或非FBA仓的一次收货约定 | 派送单、地址、收货联系人、车次/站点 | 从派送目的地带入信息，补充收货时段与确认结果 |
+
+### 同一总览应覆盖的扩展事项
+
+以下应纳入分类设计；缺少正式预约模型的部分，需要补齐业务合同后接入，不能直接把现有日期换个标题就当作预约。
+
+| 类型 | 建议处理 |
+|---|---|
+| 还空柜安排 | 还柜预约与还柜截止提醒分开，实际还空由原业务事实更新 |
+| 客户自提/承运商提货预约 | 按出库或派送来源建约，区分对方来我仓提货与我方送货 |
+| 仓间转运/退货提送 | 有实际运输和收货时间约定时纳入；库存移库、退货申请本身不生成运输预约 |
+| 临时其他预约 | 最后考虑受控兜底类型，至少有事项、地点、时间或待定标识、负责人；能归到正式业务类型的必须归类 |
+
+“美国所有可预约数据”指系统经营范围内、业务地点属于美国的预约和计划，不是承诺接入全美国所有仓库或码头的外部预约平台。第三方代约、查号与自动确认需各自接口、账号和验收支持。
+
+国内订舱拖车继续留在国内业务。美国范围应由业务地点的国家主档确定，不能把全部海外记录或所有FBA仓一律当成美国。
+
+## 四 预约 货物 车次之间的关系
+
+### 一次预约可以关联多个客户和入仓码
+
+例如A、B、C、D、E五个客户送ONT8同一时段：建立一张收货预约，货物明细保留各客户归属，再关联承运车次。预约卡片展示“ONT8 · 09:00–11:00 · 20票 / 5客户”，不拆成五张重复预约。
+
+同仓同时间并不自动等于同一预约。是否合并还应核对对方预约要求、货物资格及实际承运安排；操作员明确勾选后由服务端校验。
+
+### 一辆车可以有多站 不同站分别预约
+
+车次T先去ONT8，再去LAX9：用车安排只有一条；ONT8和LAX9分别保留收货预约，均关联车次T及对应站点。总览可以按车次分组展开，不能把两站合成一条没有明确地点的预约。
+
+一个入仓单后续若允许拆批或多车配送，关联必须落实到本批货物/数量，防止整票重复占用。目前FBA预约按入仓明细行占用，不能未经模型调整就宣称支持同一行拆分预约。
+
+### 多条业务单据不重复计算同一个预约
+
+预约、排车、派送引用同一收货预约时，总览只显示一个收货预约事件；卡片内列出关联车次、排车和派送数量。用车计划作为不同类型的关联事件保留，不与收货预约混成一个状态。
+
+建议明确：FBA预约号和预约状态由预约主记录维护；排车、派送展示按货物关系读取。一张排车覆盖多站、多预约时，展示预约列表或“2个预约”，不能把单个字符串覆盖成最后一次预约。
+
+当前排车预约字段独立维护的问题必须在实施前收敛，否则页面会同时出现“预约成功”和“排车待预约”。此项是建议的修正方向，尚未代替现有业务合同。
+
+### 车次余位与现有拼车池衔接
+
+沿用[内部拼车需求池首版开发契约](内部拼车需求池首版开发契约.md)：一车次一发布，外接货统一在我仓上车；询价不占位，调度确认承运才占位。预约页只增加发布资格摘要及进入原发布操作的入口，销售继续在原需求池工作。
+
+**建议允许提前做用车需求和送货批次，但保持正式余位发布条件。** 尚无车辆/司机、真实起运仓/卸货站或有效容量计划时，显示“预排中，暂不可发布”及具体缺项。承运商仅口头表示“预计有车”不能当作可发布运力；如以后要销售尚未落实车辆的远期运力，应另行评审，而不是本轮放松现有门禁。
+
+车次准备、容量核对、发布窗口及部分成功续办统一由[拼车优化草案第七、八节](拼车数据入口与操作简化评估草案.md#七-调度准备车次与发布余位)细化；预约页读取车次服务返回的逐目的站余位、资格与缺项，不实现第二套计算或发布表单。船期/货物变化由预约侧提供影响依据，车次侧重新核对运输承诺；不自动扩大余位或静默取消已确认外接订单。实际规则继续以拼车正式契约为准。
+
+拼车新增货物后，预约侧按稳定来源核对目的仓、货件材料及预约覆盖，车次侧展示同一结果并引导处理。确认承运保位不能推定收货方已经接受新增货物；需要补充货件或改约时交预约负责人，不自动再建一张同义预约。两类货源的可预约阶段与检查时点须在第九节的首次交接中明确。
+
+## 五 页面和交互优化
+
+### 总览布局
+
+建议在同一菜单内使用三个工作视图，避免把所有业务字段塞进一个通用大表：
+
+| 工作视图 | 一行/事件的组织单位 | 首屏信息与主要动作 |
+|---|---|---|
+| 提柜与到仓 | 一个来源货柜 | 操作、柜次/柜号、港口→接仓点、ETA及更新标识、目标提柜/到仓窗口、拖车联系/码头约号结果、当前缺项、负责人/下次跟进；进入原货柜业务维护 |
+| 送仓与排车 | 尚未安排的同仓同窗口候选组，或已建立的送货批次；二者明确标识 | 操作、起运仓→目的仓、预计备妥窗口、货量/可用状态、收货预约、承运安排、余位发布资格、负责人；选货保存安排、登记预约结果，带入共用车次入口，不另建建车/发布表单 |
+| 预约日历 | 去重后的预约事件；内部作业及预报可选显示 | 按日/周查看对方确认时段及待确认安排，可切换列表；按类型、地点或车次查看，不用一条综合状态覆盖所有事项 |
+
+日常进入预约工作日历，顶部全局待办显示全部、今日跟进、超期、未定日期和需复核，不受月份、流程与类型勾选影响。点击后进入对应明细。每条待办展示负责人、下一步和下次跟进日期；同一柜或批次的多个问题合并提示，展开后逐项处理，避免提醒数量淹没实际货量。
+
+“送仓与排车”增加目的仓货量汇总，默认按实际起运仓及未来可备妥窗口查询，可按需要切换7/14/30天。每个目的仓分别展示在途、在仓未备妥、已备妥货量及待安排量；未确定备妥日期的货物单列“日期待定”。已安排货物不再次进入未安排候选，跨窗口统计不能重复累计同一批货。
+
+顶部保留日期、类型、地点/仓库、状态和关键词搜索。日期条件需注明当前筛选的是“预计到港”“预计备妥”还是“预约时段”；不能切换视图后无提示地把同一个日期变成另一种含义。关键词支持预约号、柜号、入仓码、车次号及客户业务名称；车牌、司机、负责人等放入更多筛选。
+
+前两个视图使用工作列表；第三个统一承载月/周/日历及对应时间安排列表，不为每个工作视图再建一套日历。月视图负责概览，周/日视图负责排班，列表负责搜索、批量核对和导出。统一日历与其列表切换时保留筛选；跨业务视图保留通用条件并清楚显示各自日期口径。操作列按Admin规范放在第一列；大量货物明细只在展开或详情按需读取。
+
+月历单格固定高度，按已勾选工作类型聚合数量，点击类型或状态数量进入当天明细，不随事项数量堆叠卡片。明细按实际、确认或目标日期与时间展示；未定日期事项进入独立待办，不伪造09:00或00:00占位。
+
+到港参考通过独立开关显示，不计工作量；还空属于必需工作类型。工作数量包含未安排、已确认、无需预约、需复核及已完成，并明确统计口径；预约取消保留原记录、工作需求与继续安排入口，不能从待办漏掉。
+
+以上为信息结构建议，尚不是已冻结视觉原型。实施时逐操作核对现有新增、详情、编辑的承载方式；未定义操作形成评审矩阵，人工按1920×1080、100%缩放确认，不以本方案代替视觉验收。
+
+### 卡片内容
+
+首屏只展示类型、地点、时段与时区、预约状态、运输安排摘要、货物统计和需要处理的问题。联系人、附件、操作历史、客户与货物明细按需展开。
+
+入仓码独占一行区域，默认3条并显示总数，展开后独立滚动；大量货物使用可搜索、可分页的关联明细，不能一次拼接数百个编号到卡片中。备注缺失不占一整格；长备注默认摘要。
+
+卡片提供“查看来源单据”“查看关联车次”等操作。编辑、改期、取消是否可用由来源业务权限和当前状态决定，不因用户能看总览就允许修改所有类型。
+
+### 新增流程
+
+1. 优先从货柜或目的仓货量发起，自动带入业务对象与货物；通用“新增”入口再选择提柜、接仓、FBA或普通送货等类型。
+2. 先保存“预约安排”：目标日期/窗口、负责人与下一步；允许对方约号、车辆和司机暂缺。原有待办应直接补充，不另建一份重复事项。这与拼车侧的“客户货物登记”分别命名、分别维护，不能共用一个含义不明的“意向状态”。
+3. 人工通过电话、邮件或外部预约平台沟通，记录联系对象、方式、结果及下次跟进；系统可整理/导出既有货柜与货件资料，不能把资料导出当作已发送或已申请。
+4. 申请后登记申请时间及反馈；对方确认后再记录确认时段、外部号或适用的确认凭据。回到关联批次核对承运和货物是否就绪。
+
+新增入口可以预先带入当前选中的日期，但时间应由用户确认；地点改变后重新核对时区、可选货物及资源，清空不再匹配的选择。继续保留并发版本校验和稳定幂等，避免重复点击创建重复预约。
+
+## 六 减少填写项的具体规则
+
+| 信息 | 建议 | 约束 |
+|---|---|---|
+| 仓库/码头 | 主档搜索选择，显示编码与名称；码头可由货柜带入 | 不接受自由文本冒充已存在地点；地点未维护时给出维护入口 |
+| 客户/入仓码/柜号 | 选业务对象或货物后带入 | 不能让运营在预约表单再手填一遍；保留真实归属 |
+| 箱数/托数 | 从所选货物汇总，计划值和实收值分别标识 | 不允许为了少填而拿预计值冒充实际值 |
+| 车辆/司机/电话 | 关联车次后读取，外包运输复用承运车队信息 | 不在FBA预约中重复编辑司机档案；允许预约先于派车 |
+| 预约日期与时段 | 核心操作信息；支持“时间待确认” | 待定事项不计入已确认时间表，确认预约时按类型校验 |
+| 预约结束时间 | 选填；对方给出时间窗时填写 | 不自动假定两小时，不用司机任务结束时间替代 |
+| 预计装车时间 | 移到车次/装车安排；在预约详情作为关联信息查看 | 当前FBA接口与表结构要求非空，实施要同步调整，不能仅隐藏字段或伪造默认值 |
+| 预约状态 | 根据确认操作更新，普通新建可默认待确认 | 保存表单不等于对方确认；执行完成以来源事实为准 |
+| 预约编号 | 区分系统业务号与外部确认号 | 建议系统生成内部业务号，外部号在取得时补录；现有appointmentNo语义与唯一约束需先明确，不能把随机号当码头/FBA确认号 |
+| 联系人/地址 | 从目的地或来源单据读取，缺失时按类型补充 | 美国客户地址不强制伪装成FBA仓；变更需要留痕 |
+| 负责人/联系记录/下次跟进 | 默认带入当前操作者，可按权限分派；一次联系只补结果和下一步 | 拖车承诺、码头确认、收货仓确认分别记录对应公司，不能用一个“对方已确认”混用 |
+| 货物预报与预约材料 | 从柜内货物、来源订单及后续入仓计划读取已有内容，只补实际缺项 | 内部入仓码不能代替对方要求的FBA货件号、BOL或其他预约资料 |
+| 备注/附件 | 默认收起，异常、改期等动作按需要求原因或凭据 | 不删除业务真正需要的例外说明；文件仍遵守原权限 |
+| 运费/成本/账单 | 留在报价、运输和财务流程，可关联查看 | 不放进通用预约新增表单要求运营重复填写 |
+
+目标是“系统已有的不用再填，只填本次预约新增的信息”，而非简单删除所有字段。
+
+## 七 时间 状态与提醒
+
+### 美国当地时间
+
+预约录入和确认以业务地点时区为准，使用主档中的IANA时区，界面显示时区标签。存储和聚合需要同时保留可比较的时间点及业务地点时区；仅有无时区日期字符串时，必须先确认来源时区，不能按操作者电脑时间自行解释。
+
+单地点视图默认当地时间。跨时区总览明确展示所选总览时区，卡片同时保留地点当地时间；日历分组和查询范围使用同一明确时区，避免日期错一天。夏令时切换时重复或不存在的当地时刻要明确校验，不静默偏移。
+
+仅有日期的本土运输需求显示“当日待定时段”；没有日期的事项显示在待安排列表，不凭空推算。预计、已约、实际时间分别保存和展示。
+
+### 状态分开表达
+
+建议预约确认状态归纳为待安排、已申请待回复、已确认、已取消、未约成；“待联系、未开放、缺资料”作为待办原因，不增加大量互斥状态。作业执行显示未执行、进行中、已完成及异常提示；货物准备与承运安排各自显示摘要。各来源已有状态需建立显式映射，不直接替换所有服务的状态机。拖车公司承诺可提、码头给出约号、接仓方接受到仓时间属于不同确认对象，不能互相代替。
+
+改期是一项有前后时间和原因的操作，不应覆盖掉原确认历史；已发车或执行中的改期要检查影响的收货站、司机任务及派送计划。取消预约不能自动取消车次或回滚已发生的库存。
+
+异常优先展示：缺时间/地点、预约未确认、已约未安排承运、货物未就绪、资源冲突、已过约定时间未完成。冲突有完整资源与时段依据时才判断；缺少行程耗时不能断言车辆一定赶不到。
+
+还柜截止必须使用现有业务服务返回的规则结果。当前内部72小时预警口径不能等同所有船公司、码头的免箱期或费用规则，也不能拿预计还柜时间当实际还柜。
+
+### 船期与货量变化后的处理闭环
+
+上游变化后更新有来源依据的最新预测，重新比较下游安排，形成“变化原因 → 受影响对象 → 建议动作 → 负责人 → 处理结果”。建议至少覆盖：
+
+| 变化 | 需要提示的影响 | 人工处理 |
+|---|---|---|
+| ETA或预计可提柜推迟 | 提柜意向、接仓窗口、受影响货物的预计备妥窗口 | 再联系车队/仓库；尚未形成正式约号时调整意向 |
+| 预计备妥晚于计划装车或目标送达 | 具体送货批次、收货预约、车次及关联外接承诺 | 判断等货、取消本批或按合法命令调整货物/申请改期；正式约定保留至取得新结果 |
+| 实收箱托/重量体积与预报不同 | 车次容量、剩余可接量和需要更新的预约资料 | 调度重核容量及对方资料；已确认外接货不能被静默挤出 |
+| 对方改期、拒约或取消 | 关联装车/车辆安排及货物等待情况 | 指定下一次联系、补资料或另申请；保留原结果和原因 |
+| 船期来源过期或关键资料缺失 | 当前计划判断依据不足 | 标为待核实，负责人补充；不能继续显示无条件“可送达” |
+
+首版提醒先做有明确依据的日期先后、资料缺项、超时未回复与来源变更。缺少可靠装卸/行车耗时，只能提示“需要核对”，不能自动判定违约。若变化可能影响运输承诺且暂无完整重算依据，先要求调度复核再确认新的外接承运；不改写已确认订单或凭空计算新余位。
+
+跟进事项以同一来源与事项保持稳定身份，更新后保留处理历史，不在每次船期刷新时新增重复待办。待办完成要对应实际反馈或已处理的安排，不能仅因运营打开过详情就消失。首版岗位建议：提柜负责人跟进车队/码头，仓库负责人核对接仓和备妥，送仓调度跟进FBA/收货方及车次，销售在原拼车池跟进外接意向；具体人员由组织分工确定。
+
+## 八 数据与接口实现建议
+
+### 提前筹划必须补齐的当前接口边界
+
+以下为2026-10-09只读源码核对，不代表已部署验证：
+
+| 当前事实 | 对本目标的影响 | 建议调整 |
+|---|---|---|
+| `InboundFbaAppointmentQueryMapper`从入仓计划及其明细查候选，预约创建未要求入库完成 | 已有计划的海上货可以提前约；尚无计划的在途订单不在该入口 | 在既有Lastleg业务内提供在途货量及预约准备关系，直接引用真实来源明细；后续关联计划行，不为凑候选而伪造收货或重复建货源 |
+| `BatchFbaAppointmentRequest`要求预约号、预约时间及预计装车时间；关联仅接收完整`lineIds` | 刚开始联系时无法真实填写；不支持同一明细自由拆量 | 支持先保存筹划信息，再补确认结果；首版按完整来源明细组织，拆批数量分配另行定义后才开放 |
+| `LastlegOrderService`在同柜任意入库计划生成后禁止修改柜级预计到仓 | 提前建计划后无法持续修订该字段，不能仅靠预约页面解决 | 先区分来源最新预测与入库计划确认时的时间快照；明确各自来源和显示，预测变化走影响提示。若要修订已确认计划日期，需同步修改当前到仓合同和实际消费者，不能直接移除锁定校验 |
+| `FleetTripExecutionService`从已关联客户排车读取计划货源，要求货物、托盘、车辆与目的地；`FleetCapacityOfferService`发布还校验司机及有效容量计划 | 已支持拣货前核对容量，但不能直接把海上FBA汇总当成可售余位 | 复用现有排车/车次关联；先验证计划货源可在哪个阶段合法形成这些事实，补齐在途批次到现有货源的关联闭环；尚未具备事实时仅预排，不许前端凭空发布 |
+
+“开船后提前筹划”与“开船后立即发布远期可成交余位”是不同交付要求。前者是本轮明确目标；后者只有满足现有资源、容量及履约条件的车次才能开放。若业务要求更早发布，必须在本方案中明确新的可承诺条件，再调整拼车主契约。
+
+### 聚合读取 原业务写入
+
+总览提供按日期范围、类型、地点和权限过滤的聚合读取能力。Firstleg负责码头提柜/还空及船节点，Lastleg负责FBA、车次、派送和仓库收货相关业务，Warehouse提供地点主档。服务端通过明确接口聚合，不跨服务Schema查询。
+
+先接已有事实，不为每种来源复制一套预约数据。不具备预约状态或确认时段的业务，补充自己的模型后再作为正式预约接入；仍可先以“待安排计划”展示。
+
+建议统一返回：稳定事件标识、来源类型和业务号、预约类型、地点与时区、时间含义/开始/结束、确认状态、执行状态、货物统计、关联单据摘要、可执行动作、版本及来源更新时间。内部ID用于关联但不作为用户可见业务编号。
+
+事件按来源及业务阶段建立稳定去重键，不能按客户复制，也不能用会随改期改变的日期作为唯一标识。改期更新同一业务事件，保留历史；跨日时段按与查询区间相交纳入，不能只查开始日期。
+
+在途预报、已建计划和实收入库应按稳定货源关联去重。建议新增的筹划信息仅保存负责人、目标窗口、联系记录、批次关联等现有业务没有的事实，归Lastleg相关业务承载，不建设独立预约微服务或通用工作流引擎。提柜/船节点继续由Firstleg提供；筹划查询不跨服务Schema取数，不把来源快照复制成第二套可编辑货物清单。
+
+### 性能与错误处理
+
+按时间范围批量查询并分页读取当天明细，禁止先加载所有业务单据再在浏览器过滤，也禁止日历每个卡片再请求一次详情。现有FBA和到港接口可复用；提柜现有按柜次ID接口需要新增按范围的读取合同，不能假设它已支持。
+
+某一来源失败时，明确显示该分类暂不可用及重试，不把整个页面清成“当天无预约”。所有分类的总数必须说明是否完整，避免部分结果冒充全部。筛选和切换日期时丢弃迟到响应。
+
+### 权限与审计
+
+统一入口按平台员工权限过滤各来源，后端同时执行数据范围和动作权限校验。仅有总览权限不自动取得提柜、排车或取消权限。聚合失败、无权查看和确实无数据应区分处理。
+
+跨客户预约只在平台完整展示；客户仍只能看到自己的货物和获准公开的信息。改期、取消、关联/解除记录操作人、时间、原因和原新值。发送车队邮件属于显式业务操作，不因新增日历卡片自动发送。
+
+## 九 建议实施顺序与协同分工
+
+### 两份文档 两个实施职责
+
+建议由用户安排两个实施对话：A负责预约并协调本次集成，B负责拼车接货及共用车次能力；可以复用已有对应对话，不额外创建第三个协调对话。A/B仅为待分派的职责代号，不是已登记或已创建的任务；本次文档整理对话不承担A或B开发职责。本文维护跨方案分工，拼车草案只链接本节并保留自己的操作细节。正式规则仍回到各自当前契约，评审稿不能代替开发定稿。
+
+| 工作范围 | 唯一实现职责 | 另一侧如何使用 |
+|---|---|---|
+| 在途货量、ETA/备妥窗口、提柜与接仓联系、预约安排 | A | B读取获准的货物/时间摘要，不另建预测与联系记录 |
+| FBA/收货预约、货物关联、确认/改期、预约覆盖结果、日历 | A | B展示同一预约结果，缺项进入预约操作；不独立维护预约状态 |
+| 车次创建、车辆司机、路线、排车关联及正式排入本车 | B | A带入真实来源，使用同一候选、资格与业务命令；不另建运输单或排车命令 |
+| 计划容量、占位、余位、发布与恢复资格 | B | A只展示摘要和进入共用操作的入口，不在浏览器重算 |
+| 销售登记、确认承运、安排来货、实收后连续处理 | B | A按稳定来源联查货物及预约，不复制拼车登记或商业订单 |
+| 船期/货量变化影响 | A识别时间及预约影响；B维护车次容量/发布资格 | 各自维护自己的事实，通过明确关联衔接，不互相覆盖状态 |
+| 本次共用文件集成与整链核对 | A协调单一写入者，保留既有项目文件归属 | B提交精确改动并对其业务复验；不因此将B的业务责任移交A |
+
+实施前按目标文件列出写入范围，不能只写“前端归A、后端归B”。A通常涉及`appointment-calendar`、预约服务及所需船节点/提柜读取，B通常涉及`overseas-master-data`、Fleet及排车关联；同在Lastleg不等于可同时修改同一服务文件。排车中的预约展示/关联由A定义预约事实，B修改其负责的排车消费者。
+
+实际重叠的`lastleg.sql`、导航、根路由、权限种子、公共导出/类型、OpenAPI和相邻合同测试须逐文件指定唯一写入者；已有项目负责人持有的文件沿用其归属。B负责的公共变更由B提供精确变更清单或补丁，单一写入者在当前工作区串行整合，B复验业务行为。普通工作仍在当前工作区、当前分支，不复制项目或创建worktree。
+
+#### 已选定的预约与拼车交接文件
+
+实施交接的来源、权限与跟进规则维护在[业务主入口的预约跟进合同](README.md#在途货源与拼车外接货的预约跟进合同)，HTTP定义维护在预约筹划OpenAPI；本表只明确文件写入归属。
+
+| 文件或精确目录 | 写入方 | 边界 |
+|---|---|---|
+| Admin `src/modules/appointment-calendar/` | A | 在途列表、来源深链、跟进、覆盖展示及预约日历 |
+| Lastleg `appointmentplanning/`及同包测试、`openapi/appointment-planning-v1.yaml` | A | `AppointmentExternalSourceGateway`由A定义；`AppointmentCoverageService.query`提供共同只读结果 |
+| Lastleg `fleet/business/FleetPoolSourceResolver.java`、`FleetAppointmentSourceAdapter.java` | B | B适配原登记真实来源到A的端口，A不直接依赖Fleet实现 |
+| Admin `overseas-master-data/`、Lastleg `fleet/`与排车消费者 | B | B消费覆盖投影，提供共享车次候选、安排和容量；不复制预约写命令 |
+| Admin `core/navigation/adminNavigation.ts`及对应测试、`overseas-master-data/routes.ts`菜单标题 | A串行整合 | 此次仅“拼车接货”标题调整由A写入；B保留其页面及路由功能改动 |
+| `lastleg-service/src/main/resources/db/lastleg.sql`、`deploy/sql/海外区域统一增量-MySQL8.sql` | 按新增表块串行 | A仅写`ll_appointment_followup`块；B维护Fleet块，其他业务负责人持有的块保持原归属 |
+| `iam/src/main/resources/db/lastleg-permissions.sql`、`deploy/sql/头程数据库统一增量-MySQL8.sql` | A整合预约权限行 | A维护`platform:appointment:followup`及平台管理员授权，保留其他任务的种子变化 |
+
+深链为`/appointment-calendar?sourceKey=BOOKING:<登记号>&customerId=<客户ID>&destinationKey=FBA:<仓码>`，各参数须编码。它进入核实后的来源跟进与覆盖展示，不等价于外部预约确认。B的原登记入口必须满足读取权限，写入另受跟进权限约束。共用Lastleg编译目录串行使用，不能两侧同时运行Maven并将编译产物竞争误判为源码故障。
+
+### 开工前先确定六项交接
+
+1. **货物来源与数量：**已有头程在途货、拼车外接货分别如何关联来源明细、来货、入仓计划和实收；避免入库前后重复计货，首版不默认拆分同一明细。
+2. **时间与状态：**预测、计划快照、对方确认时间分别归谁；预约安排、拼车登记、确认保位、实收后排入各自允许什么操作，不互相推进状态。
+3. **预约资格与覆盖：**两类货源分别在哪个阶段可以准备/正式申请FBA预约，需要哪些资料；新增拼车货如何进入候选、核对原预约货件及检查时点。预约服务给出结果，车次侧消费，不在最终联调才补来源支持。
+4. **车次接入：**A传真实来源及计划关系，B返回可用候选/阻断原因、关联车次和版本；无正式排车资格时只保留筹划，不生成假托盘或实际装载。
+5. **余位与变更：**B提供各目的站可接量、发布资格、缺项和版本；A传递预测/货物变化依据，双方明确哪些变化触发人工复核，不自动重约或替换已确认承诺。
+6. **权限、失败与重试：**查看和写入分开，变更使用版本与幂等；明确部分保存成功、结果未知和重试行为，同一次动作不生成重复业务。
+
+以“两柜已有货合送同FBA，再接一票外部货”为共同样例，给出上述输入/返回示例、来源关联、可用动作及失败情形。选定规则在实现前同步到对应唯一正式契约与接口定义；本节只规定交接项，不提前宣称新接口或状态已经存在。
+
+### 工作包与先后依赖
+
+| 顺序 | A：预约与集成 | B：拼车与共用车次 | 进入下一步的条件 |
+|---|---|---|---|
+| 0 先确定共同边界 | 明确在途及外接货预约来源、预测/确认时间和关联结果 | 明确三类占用阶段、车次资格、容量和发布结果 | 六项交接有样例；正式契约、具体文件归属和受影响检查已明确 |
+| 1 两侧独立工作并行 | 在途货量、提柜/接仓列表、负责人、联系记录、无约号的预约安排 | 销售简明列表、分阶段字段、单站带入、同一登记记录、角色待办和已有排车候选 | 各自定向验证通过；不编造约号、数量或资源；独立改动不等待对方全部完成 |
+| 2 共用能力只做一次 | 实现对外预约/改期及货物关联，按已确定接口接入车次和资格展示 | 完成共用安排车次、排车关联、容量核对与连续发布，提供实际消费者可用的接口和操作入口 | A/B复用同一车次能力；源码、类型、OpenAPI、权限及必要SQL一起收敛，不能靠临时兼容接口拼接 |
+| 3 接通变化与外接履约 | 完成统一日历、船期影响、外接货预约覆盖和待补/改约提示 | 完成安排来货、实收核量、排入原车次及预留替换；消费预约结果 | 从原登记可跟踪整链；延期可定位影响；不重复占位、建单或收费 |
+| 4 统一验收本轮闭环 | A组织整链核对和问题归属，各侧修复自己负责的部分 | B复验共享车次及外接履约，保留原审核/拣货/发车门禁 | 必要自动检查完成；真实环境和人工截图按授权执行，代码、部署与验收分别报告 |
+
+第1—3步共同交付首个完整闭环，不以一个更大的日历或仅改表单文案替代。B的内部操作细节及局部分批见拼车草案第八节，不另排一条互相冲突的整链发布顺序。可以按可独立验证的工作包推进；本表不是工期、上线或环境写入授权。
+
+共同回归至少覆盖：已有货在途预约；合格车次发布后接外部货并补齐预约覆盖；外接实收后预留替换只算一次；一个柜延期时关联预约/车次/已接货均可追踪；三维容量不足、重复提交、版本冲突与权限拒绝。自提、还空、转运/退货提送的扩展仍保留总体范围，排在主链后，不占用第一轮共同接口建设。
+
+### 交给预约实施对话的任务说明
+
+- **目标：**完成从已有在途货开始的提柜/接仓跟进、按目的仓筹划、对外预约、日历及船期变化影响，并接入拼车侧提供的共用车次能力。
+- **先交付：**具体文件写入清单，已有头程货和拼车外接货的稳定关联、可预约阶段、时间语义、预约覆盖与失败情形；与B共同确定六项交接，不等到最后才处理外接货来源。
+- **独占业务：**在途/备妥预测展示、人工联系、预约安排与确认/改期、预约货物关联和覆盖结果。车次创建、排车命令、容量及发布由B提供，本侧只接入。
+- **依赖：**B提供真实货源进入车次的资格、车次/排车关联、各目的站余位、发布资格和对应操作入口；本侧不得为提前完成页面而自建同义接口或虚假资源。
+- **交付物：**选定正式契约改动、受影响接口/类型/权限/SQL清单、实现与定向验证结果、公共文件串行集成记录和整链核对结果；部署与人工验收分别列出，不由源码测试推定完成。
+- **完成条件：**货在海上且未建入库计划时可真实筹划，未取得约号仍能跟进；两类货源的预约覆盖可追踪，预测变化能定位下游影响，预约和车次结果一致，未重复占货、建车或发布。
+
+拼车实施职责的交接说明见[拼车草案第八节](拼车数据入口与操作简化评估草案.md#交给拼车与车次实施对话的任务说明)。上述工作包供用户分派给其他对话；本轮只交付文档，不创建对话、发送开发任务或修改业务代码。
+
+## 十 验收场景
+
+1. 同一美国日期包含提柜、用车、FBA和客户送货，列表/日历均可找到且类型明确；国内拖车不混入。
+2. 五客户二十票同仓同批预约只计一张，客户统计正确，入仓码默认三条；每个客户只读到自己的货物。
+3. 一车两站两个收货预约，在车次视图可以关联查看；车次计划不会被重复算成两个用车安排。
+4. 预约成功后，排车和派送显示同一来源事实；多预约排车不会丢掉其中一站，不能再出现无依据的独立“待预约”。
+5. 选仓自动加载货物；换仓清空旧选择；不可预约货物有原因；仓库接口失败不允许自由输入假仓库绕过。
+6. 新建待确认事项无需编造外部确认号、装车时间、司机或费用；转为已确认时按业务类型核验必要资料。
+7. 提柜时间、预计到仓、实际到仓互不覆盖；实际作业只由原业务事实推进。
+8. 改期更新原记录而不新增重复事件；取消保留历史；已执行业务不被日历操作回滚。
+9. 跨时区、跨日、只有日期、无时间及夏令时边界正确显示；地点时区缺失明确待补。
+10. 日格三条预览、大量当天安排和大量关联货物保持有限高度，展开可用键盘操作；关键业务号可查看完整内容。
+11. 来源接口部分失败、无权限、版本冲突和重复提交均有明确行为，统计不把缺失来源当零。
+12. 车次调度/理货、PDA拣货发车、库存和客户费用隔离继续有效，预约页面不能跳过这些门禁。
+13. 柜已开船但尚未生成入库计划时，真实货物出现在在途货量及预约准备中；无需假约号、假实收或假司机即可分派跟进。
+14. 同起运仓、同FBA、相容备妥窗口的两柜货可人工组织批次；起运仓不同、日期不相容或已占用的货不得被无提示合入。同一来源建计划/入库后不重复累计。
+15. 码头尚未开放正式申请时，保留拖车沟通与待开放事项；车队答应不自动标记码头已确认，接仓方和FBA确认也不互相替代。
+16. ETA延后时展示旧/新预测及来源，准确指出受影响批次与预约；已确认外部时间和已冻结计划不被覆盖，待办有负责人及处理结果。
+17. 海上预排货量不能直接发布可成交余位；达到现有车次、资源、有效计划容量条件后复用原发布。托位有余但重量/体积不足时，不发布虚假可接量。
+18. 在同一路段30托位车辆、自有18、有效外接预留8的示例中，剩余为4；外接货转为已关联货物后不再额外扣8。计划失效则显示待核对，不继续承诺旧余位。
+19. 联系资料可由已有货物生成；缺少FBA所需资料显示缺项。记录、导出资料、申请和取得确认是不同动作，不能相互推定完成。
+
+## 十一 评审需要确定的事项
+
+本轮用户明确目标：开船后依据预计到港提前人工联系提柜，同时掌握预计到海外仓的货物和各FBA仓货量，准备送货车辆，并把符合条件的车次余位接入现有拼车需求池。原方案已有方向：美国段预约统一入口、同仓跨客户合并、减少重复填写和控制卡片高度。
+
+本次建议作为产品评审基线，尚未生效为代码合同的规则：
+
+- 保留“预约列表”菜单和“美国预约总览”标题；以提柜与到仓、送仓与排车、预约日历三个工作视图组织，不另开一套拼车市场。
+- 从真实在途货开始筹划，先保存目标窗口和人工联系结果，后补外部确认；预计装车时间由车次维护，预约按关联读取。
+- 首版同起运仓、同目的地、相容窗口内人工组批，整来源明细选择；不同站点同车沿现有调度，一行货自由拆批不随页面优化默认开放。
+- 最新预测与已确认入库计划时间分开；船期变化提醒人工处理受影响承诺。修订已确认计划日期的命令与权限需另在当前合同中明确。
+- 正式拼车发布继续要求现有车次、车辆/司机及有效容量计划；无资源的远期运力先保留内部预排。
+
+实施前还需结合运营习惯确定：
+
+- 常用港口、接仓点与FBA线路的预计卸柜/备货/行车时间及缓冲；首版可由人工维护，不能给所有线路统一默认天数。
+- 提柜、接仓、FBA/客户送货分别由哪些岗位联系，对方是否由承运商代约，以及超时未回复时由谁接手。
+- 总览默认使用哪个业务时区，以及跨时区团队是否保存个人显示偏好。
+- 尚未满足现有拼车发布条件时，仅预排是否满足经营需要；如必须提前成交远期运力，需明确范围和承诺方式，不能省略这项能力差异。
+
+## 十二 现有实现入口
+
+| 用途 | 入口 |
+|---|---|
+| 当前预约页面与字段 | [AppointmentCalendarView.vue](../../apps/admin-web/src/modules/appointment-calendar/AppointmentCalendarView.vue)、[日历读取API](../../apps/admin-web/src/modules/appointment-calendar/api.ts) |
+| FBA预约现行边界 | [海外仓业务预约送仓](README.md#预约送仓)、[预约服务](../../baiyue-firstleg/lastleg-service/src/main/java/com/baiyue/lastleg/inboundplan/service/InboundFbaAppointmentService.java) |
+| FBA必填字段 | [创建请求](../../baiyue-firstleg/lastleg-service/src/main/java/com/baiyue/lastleg/inboundplan/dto/BatchFbaAppointmentRequest.java)、[Lastleg初始化基线](../../baiyue-firstleg/lastleg-service/src/main/resources/db/lastleg.sql) |
+| FBA预约货源与柜级到仓锁定 | [预约查询Mapper](../../baiyue-firstleg/lastleg-service/src/main/java/com/baiyue/lastleg/inboundplan/mapper/InboundFbaAppointmentQueryMapper.java)、[尾程订单服务](../../baiyue-firstleg/lastleg-service/src/main/java/com/baiyue/lastleg/service/LastlegOrderService.java) |
+| 码头提柜与还空 | [terminalDrayages.ts](../../apps/admin-web/src/modules/container-loading/api/terminalDrayages.ts) |
+| 柜级预计及实际到仓 | [containerArrivalTimes.ts](../../apps/admin-web/src/modules/container-loading/api/containerArrivalTimes.ts) |
+| 车次及运输资源 | [tripTypes.ts](../../apps/admin-web/src/modules/overseas-master-data/tripTypes.ts)、[trips.ts](../../apps/admin-web/src/modules/overseas-master-data/api/trips.ts) |
+| 外接承运预订 | [tripBookings.ts](../../apps/admin-web/src/modules/overseas-master-data/api/tripBookings.ts) |
+| 车次计划容量及拼车发布 | [车次执行服务](../../baiyue-firstleg/lastleg-service/src/main/java/com/baiyue/lastleg/fleet/trip/FleetTripExecutionService.java)、[余位发布服务](../../baiyue-firstleg/lastleg-service/src/main/java/com/baiyue/lastleg/fleet/trip/FleetCapacityOfferService.java)、[拼车主契约](内部拼车需求池首版开发契约.md) |
+| 排车独立预约字段 | [dispatches.ts](../../apps/admin-web/src/modules/overseas-warehouse/api/dispatches.ts)、[DispatchService.java](../../baiyue-firstleg/lastleg-service/src/main/java/com/baiyue/lastleg/dispatch/service/DispatchService.java) |
+| 派送计划与实际签收 | [deliveryOrders.ts](../../apps/admin-web/src/modules/overseas-warehouse/api/deliveryOrders.ts) |
+| 本土运输需求日期 | [海外业务类型](../../apps/admin-web/src/modules/overseas-business/types.ts) |
+| 全流程维护入口 | [头程到尾程README](../头程到尾程/README.md) |

海外仓业务/自有业务后端接口设计.md

@@ -0,0 +1,222 @@
+# 自有业务后端接口设计
+
+2026-10-20 总控已冻结v1，进入独占包实现；尚未执行Maven或环境验收。业务唯一依据为[首版开发契约](自有业务首版开发契约.md)，已纳入其第11/12条：计划发车日期筛选、四项统计同一完整筛选，以及独立居中的运营登记弹窗。所有编号以 `dispatchNo` 为用户入口。
+
+用户最新定位已收敛：本页是**原生排车列表装车完成后的自有车辆运营视图**。不创建第二个任务/车次主单，不保存第二份排车货物、预约、单据或审核/装车/发车/签收状态机；外配后续也消费同一排车事实。
+
+### 原排车查询能否直接复用
+
+- `DispatchViews.Query` 当前没有车辆ownership、计划发车日期范围和目的仓关键词过滤；`ListRow` 没有完整目的地/预约和附加运营信息。因此不能靠浏览器取一页后筛OWNED、求统计或逐行GET补齐，列表需要本包新增**只读数据库投影**。
+- 原主单详情在服务端通过公开窄端口读取 `dispatch.port.DispatchDetailReader.detail(Actor, dispatchNo)` 的 `DispatchViews.Detail`，再组合本页附加信息；已核实其真实来源，不重写主单查询协议或状态推算。新详情响应建议保留一个明确的 `dispatch: DispatchViews.Detail` 字段；独立三页签由现有事实和附加信息映射展示，不改变排车四页签。
+- 新API是有自身list/edit/upload权限的投影视图与附加信息入口，**不是第二套排车API**；原排车查询/Controller/DTO/Mapper全部保持只读，不要求额外公开主流程写动作。
+
+## 1. 事实来源与装车归属捕获
+
+| 事实 | 当前权威代码/数据 | 本页处理 |
+| --- | --- | --- |
+| 主单、三个阶段、计划/实际发车、装车时间 | `dispatch/entity/DispatchAggregate.java`；`ll_dispatch_order` | 只读 `ACTIVE` 且 `AFTER_LOADING/DELIVERING/DELIVERED`，必须有真实装车确认；不以 `DEPART` 历史作为入选前置 |
+| 实际托数 | `DispatchContracts.ConfirmedLoad.pallets`；`loading_confirmation_json` | 按 `warehousePalletId` 去重数，不取逻辑明细数，不合计 `palletSpaces`；缺少可信确认时不伪造托数 |
+| 车辆、司机、容量 | `resources_json` 的 `DispatchContracts.Resources` | 读取本趟快照；`VehicleSnapshot` 没有 ownership 字段，`MASTER` 也不等于自有 |
+| 当前车辆归属 | `masterdata/vehicle/.../VehicleRepository.VehicleSnapshot.ownership`；`ll_vehicle.ownership` | 有真实 `OWNED/DISPATCHED`，但车辆可在未占用时改归属；当前表不能独自证明历史归属 |
+| 历史车辆归属 | 原快照未保存ownership | 已冻结在装车完成同事务捕获真实OWNED/DISPATCHED；根接唯一hook，旧已装车TEST无快照不回填、不按当前主档降级 |
+| 多目的仓、货物、各客户 | `ll_dispatch_item`、真实来源及其 destinationKey | 服务端批量汇总；同车一行，各客户来源保留 |
+| 预约号、时间和分配数量 | `ll_dispatch_appointment_allocation` + `ll_inbound_fba_appointment`；查询规则见 `DispatchReadMapper.batches` | 按 destinationKey/实际分配关联返回数组，不取首个预约，也不按客户重复整车 |
+| 到达、里程、燃油、运营金额 | 当前主单无此页独立权威登记 | 新增附加记录；不推导到达、不改签收、不写Finance、不改排车版本 |
+
+`fleet/reporting/TripOperationsRepository` 仅查实际发车且按货源分类，并使用旧 JdbcTemplate；本模块不复用它的业务过滤或持久化实现。新模块严格 `Controller → Service → Repository → @Mapper`。
+
+## 2. API、权限与入口
+
+统一前缀 `/api/platform/v1/last-leg/fleet/owned-business`。全部要求可信平台身份 `appCode=PLATFORM, tenantId=0`，服务端重复核对真实归属、阶段和仓权限，不接受浏览器声明 ownership/客户归属/托数。
+
+| 方法与相对路径 | 权限 | 作用 |
+| --- | --- | --- |
+| `GET /` | `platform:fleet:owned-business:list` | 分页与完整筛选四项统计同一只读快照返回；浏览器不逐行GET |
+| `GET /{dispatchNo}` | 同上 | 独立三页签所需任务车辆、路线货物与凭证、附加信息及版本 |
+| `GET /{dispatchNo}/history?page=1&size=20` | 同上 | 真实操作记录分页；无模拟初始操作 |
+| `PUT /{dispatchNo}/operations` | `platform:fleet:owned-business:edit` | 运营弹窗保存；整车金额、逐目的地到达、里程与燃油同一附加版本 |
+| `POST /{dispatchNo}/photos/{slot}/uploads` | `platform:fleet:owned-business:upload` | multipart `file` + `idempotencyKey`，只准备一个真实文件，不假称已经保存照片 |
+| `PUT /{dispatchNo}/photos/{slot}` | 同上 | 将已上传的 fileId 绑定/替换到该分类框；独立于运营编辑权限 |
+| `GET /{dispatchNo}/photos/{slot}/files/{fileId}/content?revisionVersion=` | list | 当前或明确历史版本中已绑定文件的授权代理读取，不返回File内部地址 |
+| `GET /{dispatchNo}/commands/{idempotencyKey}` | list | 按当前操作者恢复本页写命令；不允许读取别人的命令载荷 |
+
+没有创建主单、改变运输状态、删除运输或费用发布接口；不公开内部 dispatchId/tripId 作为业务编号。
+
+## 3. 冻结v1 DTO
+
+以下为已冻结v1结构，源码与OpenAPI按本节同步。所有 Long ID/版本通过现有Jackson策略无损输出；Money/数量测量用规范十进制字符串传输并在服务端BigDecimal校验，金额/单价不交前端重新计算。
+
+```ts
+type Stage = 'AFTER_LOADING' | 'DELIVERING' | 'DELIVERED'
+type PhotoSlot = 'LOADING_SCENE' | 'LOADING_LIST' | 'PRE_DEPARTURE_CHECK'
+  | 'DRIVER_LICENSE' | 'RECEIPT' | 'FUEL_START' | 'FUEL_END'
+type Money = { currency: string; amount: string }
+type Arrival = { destinationKey: string; actualArrivedAt: string | null }
+type Photo = { slot: PhotoSlot; category: 'LOADING'|'FUEL'; fileId: string;
+  fileName: string; contentType: 'image/jpeg'|'image/png'; sizeBytes: string;
+  uploadedAt: string; savedAt: string | null }
+type Operations = { money: Money | null; actualDistanceMiles: string | null;
+  fuelConsumptionLitresPer100Km: string | null; arrivals: Arrival[] }
+type Gate = { allowed: boolean; blockReason: string | null }
+type Destination = { destinationKey: string; warehouseCode: string | null;
+  warehouseName: string | null; address: string | null;
+  appointments: { appointmentNo: string; confirmationNo: string | null;
+    scheduledAt: string | null; allocatedPackages: string }[];
+  actualArrivedAt: string | null }
+type Row = { dispatchNo: string; stage: Stage; plannedDepartureAt: string;
+  loadingCompletedAt: string; departedAt: string | null; deliveryCompletedAt: string | null;
+  origin: { warehouseId: string; warehouseCode: string; warehouseName: string };
+  vehicle: { vehicleId: string; plate: string; ownership: 'OWNED' };
+  driver: { name: string | null; phone: string | null };
+  destinations: Destination[]; actualPalletCount: number | null;
+  operations: Operations; unitPrice: string | null; recordVersion: string;
+  dispatchRecordVersion: string;
+  photoSummary: { loadingCount: number; fuelCount: number };
+  actions: { edit: Gate; upload: Gate }; sourceIssues: string[] }
+type Query = { page?: number; size?: number; plannedDepartureFrom?: string;
+  plannedDepartureTo?: string; keyword?: string; stage?: Stage; warehouseId?: string }
+type ListResult = { records: Row[]; page: number; size: number; total: number;
+  summary: { dispatchCount: number; afterLoadingCount: number;
+    deliveringCount: number; deliveredCount: number } }
+type Detail = { row: Row; dispatch: DispatchViews.Detail;
+  cargo: { sourceKey: string; customerId: string; customerName: string | null;
+    orderNo: string | null; inboundCode: string | null; palletNo: string;
+    destinationKey: string; packages: string }[]; photos: Photo[] }
+type SaveOperations = { recordVersion: string; idempotencyKey: string;
+  operations: Operations; reason: string | null }
+type BindPhoto = { recordVersion: string; idempotencyKey: string; fileId: string }
+type Command = { dispatchNo: string; action: 'SAVE_OPERATIONS'|'UPLOAD_PHOTO'|'BIND_PHOTO';
+  idempotencyKey: string; state: 'SUCCEEDED'|'PENDING'|'UNKNOWN_RESULT'|'REJECTED';
+  recordVersion: string | null; replayed: boolean; result: Detail | Photo | null;
+  errorCode: string | null; retryAllowed: boolean }
+type History = { eventSource: 'DISPATCH'|'OPERATIONS'; recordVersion: string | null; dispatchRecordVersion: string | null; action: string; operatorName: string | null;
+  occurredAt: string; reason: string | null; operations: Operations; photos: Photo[] }
+```
+
+- 日期筛选明确对应 `planned_departure_at`；接口接收带时区的ISO时间边界，`[from,to)`，前端按最终选定显示时区将日期范围转换，不能靠数据库会话时区猜测。
+- page默认1、size默认20且1–200，keyword最长128；匹配dispatchNo/车牌/实际目的仓，不匹配内部ID。
+- 四项统计与列表使用完全相同过滤条件，按dispatch去重，统计不带LIMIT；stage筛选也同时作用于统计。标题为“排车数”，没有“固定今天”分支。
+- `recordVersion` 是本页附加版本，未登记时只读返回`0`，不因GET建记录；第一笔成功绑定/登记返回`1`。不占用、不回写主单recordVersion。
+- `dispatchRecordVersion`仅用于原排车事实的只读定位；运营保存和照片绑定提交本页`recordVersion`，不可混用这两个版本。
+- 0金额表示明确登记零；`money=null`表示未登记。Money存在时currency和amount必须成对完整，金额`DECIMAL(18,2)`非负；单价`amount/actualPalletCount`按HALF_UP两位，只读返回；未知/零托数返回null。
+- 币种仅CNY/USD，不预选、不换汇；同一dispatch只有一份money，允许同一版本化编辑更正或清空，并留不可变历史。money=null与明确0严格区分。
+- 多目的地实到以原车实际destinationKey集合为边界，不额外设置站数上限，禁止重复/不属于该车的key；不要求首站到达等于签收。输入时间必须带时区；不以estimatedArrivalAt或signedAt回填。
+- actualDistanceMiles为mile；fuelConsumptionLitresPer100Km为手工登记的L/100km，均可空或明确0，非负、DECIMAL(12,3)。不派生总燃油量，不写默认18.6。
+- 7个PhotoSlot来自原型最终函数的5个装车框和2个油耗框；`DRIVER_LICENSE`/`RECEIPT`只表示本页图片位置，不审批司机资格，也不触发派送签收。每框一个当前文件，替换保存不可变历史，不删除File对象。无照片清空入口，避免扩大当前原型操作。
+
+## 4. 保存、命令恢复与错误
+
+1. 编辑/绑定先核对平台、权限、真实自有资格和三个阶段，再读取/创建附加行。并发首次创建依dispatch唯一约束串行；同一附加行内CAS版本、命令成功结果及历史同事务提交。
+2. 命令唯一键为dispatchId + idempotencyKey，另存operatorId并强制匹配；摘要包含action、原recordVersion和完整规范化载荷。同键同操作者同摘要返回原结果，不同操作者403、同键异载荷409。重放先于新写版本判断，不修改原版本重发。
+3. 新增独立上传命令意图，文件调用前持久化`PENDING`且不持业务行锁跨HTTP；成功后记录原fileId和元数据，不推进附加版本。上传响应未知转`UNKNOWN_RESULT`且`retryAllowed=false`，禁止自动换键/重复上传；GET命令返回原已知状态。现有File没有此业务上传请求键的查找接口，因此不承诺把未知上传自动恢复为成功。
+4. 绑定时复核File的tenantId=0、两个受控businessType之一、businessId=本单内部dispatchId、fileId、JPG/PNG及大小；绑定成功才标记照片已保存。上传失败不创建新的业务主单；已知成功上传的fileId可保留原请求另行明确恢复绑定，未知文件不伪造已上传。
+5. 不持派送、库存、Finance或车辆占用写锁；只写本页附加行/命令/历史。源读取与CAS的并发保护需要第7节捕获的稳定装车事实；没有新排车状态机。
+6. 入口沿现有HTTP200+业务code约定；缺版本/无效金额/非法目的地为参数错误，身份与权限拒绝为403/A0403，缺主单为404/NOT_FOUND，附加版本变化/源事实变化/同键异载荷为409/A0409。普通参数/权限/缺失/版本错误沿项目A0400/A0403/A0404/A0409；上传命令另存OWNED_UPLOAD_UNKNOWN_RESULT诊断码，正文不向用户展示内部ID。
+
+## 5. 新增结构（根维护实际DDL）
+
+全部在Lastleg schema，MySQL8，内部BIGINT主键；表与列按根要求完整中文COMMENT。新包不写初始化或增量SQL文件。
+
+| 表 | 精确主要字段与约束 |
+| --- | --- |
+| `ll_fleet_owned_business_record` | `id BIGINT PK`；`dispatch_id BIGINT NOT NULL UNIQUE`；`record_version BIGINT NOT NULL`（持久行首次成功为1）；`currency VARCHAR(3) NULL`；`total_amount DECIMAL(18,2) NULL`；`actual_distance_miles DECIMAL(12,3) NULL`；`fuel_consumption_litres_per_100km DECIMAL(12,3) NULL`；`arrivals_json JSON NOT NULL`；`photos_json JSON NOT NULL`；`created_by/updated_by VARCHAR(64)`、`created_at/updated_at DATETIME(3)`。Money成对、非负与JSON形状由业务层及可实现CHECK约束共同保证 |
+| `ll_fleet_owned_business_command` | `id BIGINT PK`；`dispatch_id BIGINT`、`idempotency_key VARCHAR(128)`联合唯一；另存`operator_id VARCHAR(64) NOT NULL`；`action VARCHAR(32)`；`expected_version BIGINT NULL`（上传无需编辑版本）；`request_hash CHAR(64)`；`request_json JSON`；`status VARCHAR(24)`；`result_json JSON NULL`；`error_code VARCHAR(64) NULL`；`created_at/updated_at DATETIME(3)`。保留原请求和原结果，不只保存hash |
+| `ll_fleet_owned_business_history` | `id BIGINT PK`；`dispatch_id BIGINT`、`record_version BIGINT`唯一；`action VARCHAR(32)`、`operator_id VARCHAR(64)`、`reason VARCHAR(1000) NULL`、`snapshot_json JSON`、`occurred_at DATETIME(3)`；索引`(dispatch_id,record_version)` |
+| `ll_fleet_owned_business_ownership` | `dispatch_id BIGINT PK`；`vehicle_id BIGINT NULL`；`resource_mode VARCHAR(16) NOT NULL`；`vehicle_ownership VARCHAR(16) NOT NULL`；`vehicle_record_version BIGINT NULL`；`ownership_captured_at DATETIME(3) NOT NULL`；`loading_completion_hash VARCHAR(128) NOT NULL`；`loading_completed_at DATETIME(3) NOT NULL`。MASTER读真实VehicleRepository；原dispatch EXTERNAL资源原样保存，并记DISPATCHED及null车辆版本；仅保存归属证据，不复制主单/货物/状态 |
+
+金额、arrival、photo可以用有界JSON存附加行，暂不新增逐目的地/逐图片业务表；历史提供文件旧版本授权依据。并发初建使用唯一键+事务锁，不用未保存的随机业务ID假造记录；主单表不更新。
+
+## 6. 查询与分层实现
+
+新增包内 `controller/OwnedBusinessController`、`model/OwnedBusinessModels`、`service/OwnedBusinessQueryService`、`OwnedBusinessRecordService`、`OwnedBusinessPhotoService`、`repository/OwnedBusinessRepository`、`mapper/OwnedBusinessQueryMapper`、`OwnedBusinessRecordMapper`、`OwnedBusinessCommandMapper`、`OwnedBusinessHistoryMapper` 及`gateway/OwnedBusinessFileGateway`。
+
+所有Mapper显式`@Mapper`，由既有Lastleg根扫描注册。GET为repeatable-read快照；count/四项统计共用同一SQL过滤片段，再做主单分页，页内目的地、预约及货物使用dispatchId集合批量查询，Mapper局部只读复用真实表，不循环调用排车GET或浏览器逐行补数据。细节API直接给三个页签所需数据，不把旧车次八页签整体搬来。
+
+## 7. 根负责的精确外部触点
+
+1. **已冻结唯一捕获hook**：根在DispatchAggregateService.loadingComplete最终确认时点同事务调用本包port.OwnedBusinessOwnershipCapture.capture(long dispatchId, Long vehicleId, String resourceMode, String loadingCompletionHash, Instant loadingCompletedAt)。实现经Repository→Mapper持久化，MASTER只普通读VehicleRepository真实归属/版本，不反向加车辆写锁；EXTERNAL记DISPATCHED。相同原事实捕获重放只返回，异事实拒绝；原命令已成功的回放不补写。
+2. **旧已装车单**：无归属快照不回填、不在GET降级使用当前主档；本页不纳入，原排车读取完全不变。新原生样本用装车同事务快照验收。
+3. **文件分类（根已明确冻结）**：`OVERSEAS_DISPATCH_LOADING_PHOTO`、`OVERSEAS_DISPATCH_FUEL_PHOTO`，平台tenantId固定0、businessId为原dispatch内部ID，JPG/PNG、每文件10MiB及内容签名校验。根唯一修改File分类、直接测试和契约；本包新增代理只按此消费，并承担原dispatch可见性、类别及当前/历史引用授权。不复用客户POD、司机、运维或车次运营类别授权，也不把dispatchId冒充tripId。内部HTTP沿`/internal/file/v1/business-files/0/{type}/{dispatchId}`，不将该地址或内部业务ID交浏览器。根共享File接线不阻断本包结构实现。
+4. **IAM/导航/Gateway/SQL**：根集成3权限及角色授权、Admin路由菜单、Lastleg及统一基线、Gateway合同。路径已落在现有Lastleg域，但仍由根验证实际路由注册，不推定可达。
+5. **照片保存语义已冻结**：逐槽上传后绑定立即保存；绑定失败保留原fileId和原绑定键恢复，不重复上传；绑定成功才显示已保存，关闭弹框不写数据。
+
+## 8. 冻结与验证安排
+
+v1所有业务项已冻结。仅根接共享hook、File、权限及4表基线；独占包继续实现，不等待其他无关任务。
+
+本包实现及有意义的定向测试预计2–3小时；根统一排队的编译/Maven、共享接线和环境验收另计。每阶段交付记录在本设计末尾，实际通过仅按根执行证据报告。
+
+## 实现检查点（根统一验证前）
+
+- port.OwnedBusinessOwnershipCapture及MANDATORY捕获提供者已落源码；根只需现有唯一loadingComplete hook。原dispatch实际模式MASTER/EXTERNAL原样持久化，不引入另一套资源模式枚举。
+- 原排车和附加流水由UNION ALL在同一查询排序分页，History区分eventSource和两个可空版本；原排车事件operations=null、photos=[]，不复制原流水。
+- 四表DML已按根当前lastleg.sql末部字段实现：更新显式写NULL；命令二元唯一且摘要含操作者/action/原版本/请求。源码与直接回归仍在收口，尚未运行任何检查。
+
+### 根集成所需精确门禁触点
+
+- `scripts/synchronous-dependency-baseline.mjs`：新增 `lastleg-service/.../fleet/ownedbusiness/gateway/HttpOwnedBusinessFileGateway.java` → file-service，REQUEST、READ_WRITE、MIXED。元数据和内容只读；上传无File远端幂等键，本域写前持久化意图、未知停写，不能自动重试。
+- `lastleg-service/src/test/resources/architecture/lastleg-slice-dependencies.json`：原baseline不允许宽泛fleet→dispatch-delivery，需要逐类只读边评审。本包实际复用为 Models→DispatchViews；Rows/QueryMapper/Repository仅使用本包Source与CargoRow只读投影，不依赖dispatch实体；Projection→公开DispatchContracts；QueryService→公开DispatchDetailReader/DispatchContracts/DispatchTypes。根hook的DispatchAggregateService→OwnedBusinessOwnershipCapture只依赖窄端口，不回调本页查询。后端不得借此访问或修改派送/库存/Finance持久化。
+- OpenAPI新增文档数、Gateway自动发现Controller及Mapper注册合同均由根统一执行，不在本对话重复门禁；实际通过尚待根。
+- 新附加历史从可信会话保存operatorName到snapshot；原排车历史只有operator_id、缺少姓名权威时operatorName=null，不把内部ID伪装成姓名。
+
+- 根已冻结读取边界：本包不继承DispatchAggregate，不返回DispatchItem，不引用DispatchAggregateService。Source/CargoRow仅描述原SQL所需字段；详情经新公开DispatchDetailReader提供，根唯一维护适配及精确port依赖基线。
+
+### 源码候选完成，等待根统一验证
+
+- 新包生产16文件、独占测试包（夹具与7个测试类）、独立OpenAPI已完成首轮实现，未改主单/派送/财务/库存状态机；原4表DDL及hook根独占。
+- 直接回归包含H2读取根4表基线、真实MyBatis NULL清空/CAS、并发0版本单胜出、原键重放、非法目的地不落记录、照片替换与历史引用、原主历史合并分页、同筛选四统计、归属捕获随父事务回滚、异账号恢复403及未知上传不重发。只是测试源码交付，尚未执行。
+- 根可统一运行test-compile和7个OwnedBusiness*Test，再按影响运行Mapper、Gateway、同步依赖、端口边及OpenAPI门禁；本对话没有启动Maven、任何检查或环境操作。
+
+
+### 交根统一验证的冻结输入
+
+- 25路径：生产16、测试8、OpenAPI1；Ordinal路径排序，各行`path|sha256`，UTF-8/LF且末尾一个LF。
+- 聚合SHA256：`b8d7c7d9108fe0475410f950579879ca5b4e3819d05f08a3b6e90cdc99ac456f`。
+- 当前35个自有业务测试声明已由根实际执行，结果见下方当前验证记录。
+- 根已修正两份DDL的money CHECK；新增真实基线回归覆盖币种NULL/金额非空拒绝、两者NULL合法、明确CNY零金额合法及再次清空。
+- 根已登记5条公开port读取边、同步File客户端依赖，并报告静态无包环；本对话未运行门禁。后续仅按根确切失败定点解冻。
+
+```text
+lastleg-service/src/main/java/com/baiyue/lastleg/fleet/ownedbusiness/controller/OwnedBusinessController.java|913b4df8cf80f21bc42ea59459ef2a04136ab0d563a0145c4c94e3f233d7fe9a
+lastleg-service/src/main/java/com/baiyue/lastleg/fleet/ownedbusiness/gateway/HttpOwnedBusinessFileGateway.java|4e2bbbd5292df8d15cb689eabf57d270f11c177c4503dc44e73387398cf1d3fd
+lastleg-service/src/main/java/com/baiyue/lastleg/fleet/ownedbusiness/gateway/OwnedBusinessFileGateway.java|a6a3baedfa380dde6f0c3e9a39d6a7f5bf2fdf9e2a4e9b47f8d989ee4f546cfc
+lastleg-service/src/main/java/com/baiyue/lastleg/fleet/ownedbusiness/mapper/OwnedBusinessMapper.java|6317c3428f10b2ccb6f3b71135e117e01e3da76ad742e4e1cb37f74caf808c60
+lastleg-service/src/main/java/com/baiyue/lastleg/fleet/ownedbusiness/mapper/OwnedBusinessQueryMapper.java|d36deb1f2840c103e96de1aab867b03aa80bed9e1f755778afa91db564a037d8
+lastleg-service/src/main/java/com/baiyue/lastleg/fleet/ownedbusiness/model/OwnedBusinessModels.java|c2c7a953c9c9cacb57b059daf6134828d160e0351be97d27e231b7c821a32c1e
+lastleg-service/src/main/java/com/baiyue/lastleg/fleet/ownedbusiness/model/OwnedBusinessRows.java|5d31468f7c5f3f177fe7aef4063bc8f5e71b3f37f56e0b49beeb531ffb16277a
+lastleg-service/src/main/java/com/baiyue/lastleg/fleet/ownedbusiness/port/OwnedBusinessOwnershipCapture.java|f354de8142cbab49a7d42ab6837c2ba836b4940560dbabb100b0642cadd05b08
+lastleg-service/src/main/java/com/baiyue/lastleg/fleet/ownedbusiness/repository/OwnedBusinessRepository.java|27c7cf185e65907923bbbf18a05f10bdfa5e091da608e44a798600a061917ad5
+lastleg-service/src/main/java/com/baiyue/lastleg/fleet/ownedbusiness/service/OwnedBusinessCommandService.java|ac507f63245436cb31a2b99001d7c5c7ff9ae2938e7417d795ae17c18cf462e8
+lastleg-service/src/main/java/com/baiyue/lastleg/fleet/ownedbusiness/service/OwnedBusinessOwnershipService.java|e1a6d10ab69d44915bbff958a28df970cbdd26b6bb19c83118877c29d09e8868
+lastleg-service/src/main/java/com/baiyue/lastleg/fleet/ownedbusiness/service/OwnedBusinessPhotoService.java|e951d0314f66e4b9f5ad17fa70e7c413cc5c6a74eee6ece560223fc1b5787658
+lastleg-service/src/main/java/com/baiyue/lastleg/fleet/ownedbusiness/service/OwnedBusinessProjection.java|0a3a2ddb6368add9af5696f119fdbe31a1e807edcfc34a4fb0487b60d11d3cbf
+lastleg-service/src/main/java/com/baiyue/lastleg/fleet/ownedbusiness/service/OwnedBusinessQueryService.java|39512a8321dc15e88080570a138ea8c8b56f8ff834c5bc3ada3db4c173b8a586
+lastleg-service/src/main/java/com/baiyue/lastleg/fleet/ownedbusiness/service/OwnedBusinessRecordService.java|09a6af10f9bd4ecba2eb50ecd7b338c9b01498bf7ac397a785e5f13ca63669b6
+lastleg-service/src/main/java/com/baiyue/lastleg/fleet/ownedbusiness/service/OwnedBusinessSupport.java|e6f71eca2ecb7dd1a1803a5600aa954a7517091c2f1e7c7678b743ee591a20b7
+lastleg-service/src/main/resources/openapi/fleet-owned-business-v1.yaml|34ced2f1cde024701bc9900fd0248de875d2500c47b817aab42d7edc91183364
+lastleg-service/src/test/java/com/baiyue/lastleg/fleet/ownedbusiness/OwnedBusinessCommandTest.java|562ef97a01e96ad8e7e951c9ac01f175caa4ee2e1b2b4dca766b9b24902ff524
+lastleg-service/src/test/java/com/baiyue/lastleg/fleet/ownedbusiness/OwnedBusinessFileGatewayTest.java|df97ee090d18b8f1663715275ee18135a0bc81061edab3dd3042c35ae91a2148
+lastleg-service/src/test/java/com/baiyue/lastleg/fleet/ownedbusiness/OwnedBusinessFixtures.java|dca8eb00914c23e9eec9b776a1800f063e2189e7d3a4b16190d04f35fba8d341
+lastleg-service/src/test/java/com/baiyue/lastleg/fleet/ownedbusiness/OwnedBusinessOwnershipTest.java|6f22c03e61a80b8f238253645510b3f941de6ec11f18e2c5df49c8a78ed14eb2
+lastleg-service/src/test/java/com/baiyue/lastleg/fleet/ownedbusiness/OwnedBusinessPersistenceTest.java|97836b6665b90186e74a17ec26ffbd2d71238ec7a7fc64d3a091e8bfe45ada08
+lastleg-service/src/test/java/com/baiyue/lastleg/fleet/ownedbusiness/OwnedBusinessPhotoTest.java|b4e5f907ce6c56ac7a382788685b24f5989dd018120d0d77739f0af33bb543a2
+lastleg-service/src/test/java/com/baiyue/lastleg/fleet/ownedbusiness/OwnedBusinessProjectionTest.java|412711599c45a9d547397087bf9090f48ff3efa44226af48fe41452f9b732358
+lastleg-service/src/test/java/com/baiyue/lastleg/fleet/ownedbusiness/OwnedBusinessQueryTest.java|12ab10a71a61ca24556238ea2ae9ce7f6321a242b426c7171a67204db03ce3e6
+```
+
+#### 当前验证记录
+
+- Projection仅将DispatchContracts星号import展开为ConfirmedLoad/Resources两条显式import；业务方法未变。逆向还原import后精确得到原45f60872… SHA，根Maven覆盖当前显式import字节。
+- 根报告session24317 BUILD SUCCESS：65项、0失败、0错误、0跳过；其中自有业务35、原DispatchAggregatePersistence24、只读适配1、Mapper2、中文schema3。本对话未执行Maven。
+- 本轮只读YAML/JSON Pointer核对：48个唯一可达引用，读取2份直接相关OpenAPI，未解析引用0个。DispatchDetail对应DispatchViews.Detail的13字段、required集合及四块结构一致。这不代替根的完整公开API/权限门禁，也不代表部署或HTTP通过。
+
+#### 照片历史中文文案定点修正（待根复验）
+
+- 仅OwnedBusinessRecordService和OwnedBusinessPersistenceTest解冻：7个照片槽位保存原因改为准确中文，现有真实Mapper绑定/替换历史断言均核对中文。未改状态、版本、接口或其他源码。
+- 上方65项通过仅覆盖此前候选；本次新两文件输入未由本对话执行检查，待根直接受影响回归，不能扩展旧结果。
+
+#### multipart文档定点修正及计划发车非空核实
+
+- 仅独立OpenAPI解冻：上传idempotencyKey从query移到multipart requestBody，与file共同required，长度8–128保持；Controller、Java DTO、前端及业务逻辑均未改。
+- plannedDepartureAt保留非空string：DispatchAggregateService.loadingComplete在写装车完成及捕获归属前调用verifyReviewResources；该方法明确拒绝row.plannedDepartureAt=null（原方法约602行）。原编辑入口requireEditing仅允许BEFORE_LOADING且零扫码，装车后不能经此清空计划发车。自有视图只纳入有新装车归属快照的三个阶段，因此正常受控写路径已保证非空；不新增业务必填门禁，不要求前端类型改为nullable。缺失/损坏存量不作为兼容依据，原无快照TEST仍不回填。
+- 本次只读核对并修改文档；公开OpenAPI/权限门禁由根安排，未运行检查或环境HTTP。

海外仓业务/自有业务首版开发契约.md

@@ -0,0 +1,71 @@
+# 自有业务首版开发契约
+
+2026-10-20 用户明确先做自有业务，并授权复用既有后端、前端两个独立对话，与当前总控三方并行开发。本契约是本页唯一共同业务边界；实现、检查、部署及真实验收分别记录。排车 HTTP 扩展继续由原排车后端对话独占，不与本页并发操作其样本。
+
+## 已确认规则
+
+2026-10-21 用户确认按实际拼车货物分类：自有业务是未实际接入拼车货物的排车，外配任务是已实际接入拼车货物的排车，与车辆属于自有或外配无关。本契约维护自有视图；外配任务维护在[外配业务首版开发契约](外配业务首版开发契约.md)。两页共用原排车主单及真实履约事实，不另建第二套任务、车次主单、货物、审核、装车、发车或签收状态机。本次最小变更保留原页面、统计项及两页运营表单差异，不新增分类表或分类字段。
+
+1. 自有业务按“无实际拼车货物”筛选，允许自有车辆、档案外配车辆及临时外配车辆；承运货物仍保留各客户真实归属。实际拼车的判定唯一见外配契约，列表、完整统计、详情及运营写入统一使用同一分类；同车多客户本身不代表拼车。
+2. 从排车装车完成后展示，覆盖装车后、派送中、派送完成；不把审核通过或拣货核平本身当作装车完成。
+3. 一张排车单就是一趟车，列表一张排车单一行；多个目的仓、预约号在行内展开，不按客户或目的地重复整车统计。
+4. 后台登记一次整车总金额，单价由系统按整车总金额除以实际托数计算。用明确币种记录，不将该运营金额自动当作客户应收、车队应付、Finance入账或利润；不重复收费。金额未登记与明确零金额区分，实际托数为零时不除零。
+5. 实际托数按真实物理托盘去重，同一实托承载两张换标单仍计一托；不得用逻辑明细数、客户数或标准占用托位冒充实际托数。
+6. 实际到达时间、实际里程和油耗由后台补录；装车及油耗照片按原型上传。多个目的地的实到时间应与对应目的地匹配，不用签收或派送完成时间伪造到达，不自动推进排车或派送状态。
+7. 列表统计、筛选、字段、查看明细和上传照片沿用户新版原型及模块原型核对矩阵；正式外观沿当前Admin高密度规范，操作列在第一列。
+8. 详情为独立页面，三个页签为任务与车辆信息、路线货物与凭证、操作记录；排车详情仍保持其已确认四页签，旧车次附加功能不自动迁入本页。
+9. 上传照片沿760px居中弹框，装车完成、油耗图片两个页签，JPG/PNG逐框处理；上传图片不等于确认装车。真实持久化、权限和版本明确核对后才记录已上传或已保存。
+10. 不写原型的固定日期、默认18.6油耗、预设GPS/ETA、驾驶证状态、占位图片或示例操作历史。缺失显示未登记或—，不借内部ID回退业务编号。
+11. 用户补充确认：按计划发车日期筛选，统计随同一筛选变化，原型“今日排车数”改为“排车数”。日期范围不硬编码示例日期，统计不以当前页行数代替全部筛选结果。
+12. 用户补充确认：新增“登记运营信息”居中弹框，填写整车金额、逐目的地实到时间、实际里程和油耗；照片继续沿原型独立上传弹框。具体尺寸按当前Admin表单密度与字段数量处理，不改为抽屉。
+13. 2026-10-21 字段核对确认：列表总价、单价、预约到达时间、实际到达时间独立成列，仍一车一行且按目的仓标识关联时间；“派送仓库”就是目的仓，复用同一来源展示，不新增独立仓库关系。“最晚装车完成时间”先留空显示“—”，不以计划发车或实际装车时间代替；保留已有计划发车列。图中仓库名称上方误写的“托数”保留正式名称“提货仓库”，物理托数仍只有一项；状态表头统一为“状态”。本项仅调整列表展示，不新增金额、日期写入或履约逻辑。
+
+## 原型与实现差距
+
+直接依据为用户提供 `C:/Users/BY-OY/Documents/WXWork/1688854456873012/Cache/File/2026-10/悦/悦/新版.html`：`page-vehicle-own-business` 8772行，详情8779行，上传弹框8791行；最终照片函数23082行覆盖22842行同名定义。模块 `PROTOTYPE_MATRIX.md` 的“自有业务准备核对”记录逐操作承载及原型错位。
+
+正式源码已接入本页菜单、列表/详情路由及独立权限；共享路由与权限22项检查通过，尚未据此发布或认定真实页面验收。现有TripOperations仅按实际发车查询，并按OWN/EXTERNAL货源筛选，不能通过换标题或套用其筛选实现本页。车辆归属取原装车完成时点的真实OWNED/DISPATCHED证据；原排车事实、实际托数、预约及多目的地读取与附加运营记录按下文冻结接口实现。
+
+原型统计标题和日期口径已由用户按第11项修正，运营补录承载按第12项冻结。历史车辆归属取值时点及真实提供者按下文接口冻结v1，不由浏览器用当前档案推算历史。
+
+## 三方职责及写入边界
+
+| 对话 | 本轮职责 | 唯一写入边界 |
+|---|---|---|
+| 排车派送与费用后端 `01a1524f-56a9-7320-a5fd-8ff76fa4356b` | 自有业务权威查询、附加运营记录及附件代理；先给正式API/数据设计，再实现与直接验证 | 新增Lastleg `fleet/ownedbusiness/`及对应测试、新增`fleet-owned-business-v1.yaml`、`docs/海外仓业务/自有业务后端接口设计.md`。其它生产目录与共享模型默认只读，需要触点先交总控协调 |
+| 排车前端与PDA `01a1524f-52c7-7cc3-9b08-d34ad24c172a` | 列表、独立三页签详情、照片及运营补录操作、前端API/类型与直接回归 | Admin海外通用资料模块中新增OwnedBusiness前缀页面/组件、ownedBusiness前缀API/类型及其测试；共同API冻结前不猜DTO。不得写PDA或其它业务页 |
+| 当前总控 `01a15230-a9d6-7503-a8a9-d70691df49e5` | 业务及接口冻结、共享接线、必要提供者与数据结构、集成及审查 | 本契约、原型矩阵、协作登记、Admin共享导航/路由/权限及测试、IAM和Lastleg初始化基线/必要增量SQL及必要直接File/Gateway接线。执行SQL/部署仍核对当前授权，不由专项自行触发 |
+
+两个专项不修改AGENTS、共享runner、排车HTTP脚本、原排车/派送主链、旧出车记录实现、共享路由导航权限、数据库基线、依赖与锁文件。跨边界触点先交精确文件和原因，总控处理；不新建对话、不再委派、不创建分支/worktree/项目副本、不覆盖其它在途修改。
+
+## 顺序与验收
+
+1. 后端先提出API路径、字段、权限、原始事实来源、分页/统计、版本与幂等、附件归属、保存及历史、必要结构；原型未定义的字段不自动放进公开写模型。前端并行完成纯展示组件与逐操作矩阵，等待冻结API接线。
+2. 总控核对并冻结共同合同，协调共享文件和提供者触点后，两个任务继续实现；技术例行选择不重复请用户批准，改变业务语义才询问。
+3. 只读list权限包含详情、历史和已授权附件读取；保存及上传分别独立权限。所有过滤、所属车辆、阶段、真实单据归属、数量与金额计算由后端保证。
+4. 写操作保存稳定请求键、版本与完整载荷，未知结果不当作失败重建；文件上传失败不重建业务记录。后端Money用明确十进制，单价按两位小数展示；前端不重算权威统计或用当前页行数作总数。
+5. 覆盖自有/外配区分、装车前不显示与三个阶段、多客户多目的仓去重、同托多换标、金额缺失/零值/单价/币种、逐目的地到达、里程油耗及附件、并发版本/幂等/隔离/权限、空态失败及长编号。若存在需澄清字段，标未验证，不填假数据通过。
+6. 所有测试、类型、构建、Maven经local-check串行；默认Node2GB/Java1536MB/CPU2，不继承先前一次性内存例外。先跑受影响检查再统一完成必要门禁，不各自重复全量。
+7. 本轮开发不自动授予提交推送、SQL执行、环境发布、清理或业务写入。部署及本页真实HTTP由总控在匹配版本就绪后统一安排；Admin1920×1080、100%缩放人工截图验收，代码通过不代表页面已验收。
+
+## 接口及技术冻结 v1
+
+共同API结构以 `自有业务后端接口设计.md` 第2、3、4节为基础，并以下列最终规则覆盖草案中的待选项。两任务可据此实施，不再等待重复业务确认。
+
+- API前缀 `/api/platform/v1/last-leg/fleet/owned-business`；公开业务身份dispatchNo。前端路由 `/overseas-master-data/owned-business` 及 `/:dispatchNo`；list/edit/upload权限分别为 `platform:fleet:owned-business:list/edit/upload`，新增查看不授予主排车操作权限。
+- 查询投影仍读取原排车及真实关联表，详情组合原 `DispatchViews.Detail`，不复制履约主模型。附加运营recordVersion与只读dispatchRecordVersion分别返回，初始附加版本0合法；GET不建记录。
+- 油耗按原型单位L/100km，手填字段 `fuelConsumptionLitresPer100Km`；实际里程为mile，字段 `actualDistanceMiles`。不把油耗率变成燃油总升数，不自动推算总油量。
+- 金额币种沿已有CNY/USD，必须明确选择，不预选不换汇。一份整车金额可在同一版本化编辑中更正或清空，并保存历史；“登记一次”表示同车唯一记录，不是一次提交后永久不可编辑。零值、未登记及单价除零按既有条款区分。
+- 照片沿原型七框，逐槽上传后绑定立即保存；只有绑定回执成功才显示已保存。上传成功绑定失败保留原fileId、绑定请求键及载荷，重试只绑定；未知上传保留原命令，不自动重新上传或虚称恢复成功。关闭弹框不另造保存动作。
+- 车辆归属仍按原排车装车完成时点冻结，仅作车辆事实及装车依据一致性校验，不再决定业务分类。两个入口的vehicle.ownership均可为OWNED/DISPATCHED，临时车辆vehicleId可空；按真实快照返回，不能以所在页面改写车辆归属。原loadingComplete捕获点不变，旧已装车TEST无车辆快照不回填、不按当前主档猜测；原排车读取不受影响。
+- 数据表为附加record/command/history及ownership证据，结构由后端提出、根维护基线；文件分类为 `OVERSEAS_DISPATCH_LOADING_PHOTO`/`OVERSEAS_DISPATCH_FUEL_PHOTO`，平台0、businessId=原dispatch内部主键，JPG/PNG、10MiB。没有新的主排车状态机、客户收费或Finance写入。
+- 附加命令唯一键为 `(dispatch_id,idempotency_key)`，记录并验证原operator；异操作者复用原键A0403，不按操作者分组创建第二条命令。同一原操作者只恢复同动作、原版本、原载荷，异载荷A0409；上传和绑定各保留自己的稳定键。
+- 操作记录只读聚合原排车真实历史与本页附加历史，不复制原流水。历史明确 `eventSource=DISPATCH/OPERATIONS`，附加recordVersion和原dispatchRecordVersion可分别为空，不混淆两个版本序列；原排车事件不伪造运营快照或照片，运营事件保留其真实快照。
+
+## 当前集成与验收记录（2026-10-20）
+
+- 前端18文件候选`3deb4b56181d2b323298289cde353d1b0ced1cd75f41160ef28c04cd1f94fb40`已逐字节复算；新增页面/弹窗及API六文件直接测试连同共享路由、菜单、密度合同共113项通过。`pnpm typecheck`与`pnpm build`在默认资源限制下通过，完整Admin453文件4087项全部通过；核对全量运行窗口没有Admin TS/Vue/CSS源码改动，不继承旧批次的内存例外。
+- 后端首轮统一Maven65项全部通过（本域35、原整车持久化24、只读适配1、Mapper架构2、中文基线3），含原装车捕获失败回滚、不改原主单版本、同实托多来源计一次、真实Mapper/CAS清空及并发、照片历史授权。随后只修正照片保存历史中的内部枚举文案及直接断言，受影响持久化/照片15项及IAM种子5项复验通过。最终25路径候选`b8d7c7d9108fe0475410f950579879ca5b4e3819d05f08a3b6e90cdc99ac456f`仅再收敛独立OpenAPI的multipart上传键声明，不改实际调用。装车完成沿原verifyReviewResources守卫要求计划发车非空，本页不新增门禁。
+- File两类平台排车照片及相邻凭证回归21项通过；Mapper扫描406项注册及AGENTS索引1229项通过。新增OpenAPI八路径、39个直接引用可解析，原详情引用保留现行13字段结构。
+- 最后全仓API/依赖联合33项全部通过，含Gateway五项和Lastleg依赖十四项。本域只登记五条公开只读端口引用，不开放fleet→dispatch通用许可，不保留实体或具体Service依赖和包循环。根对共享检查发现的六个现存客户端仅补同步依赖事实分类：四个Feign只读，两个HTTP沿真实背景诊断/请求照片读写分类；没有修改它们的业务实现。图谱保留实际Firstleg→Lastleg请求边及原有最长六跳风险，不提高预算或隐藏粗粒度环。明细证据在根`.codex-temp/owned-business-api-contracts-20261020.xml`。
+- 本轮获用户明确批准后，最小环境SQL已完成：四张空附加表、三权限及仅PLATFORM_ADMIN授权，四subject持久权限版本和会话刷新；File #154已发布且248项CI通过、实际容器healthy。Admin实际#659已包含本域全部23路径，逐文件核对一致，不重复发布。Lastleg固定38路径候选7c6a已独立复核无阻断，CI #381全量检查进行中，尚未部署；真实HTTP和1920×1080、100%人工截图仍未验收。实时环境事实唯一见部署主契约。旧已装车TEST无归属快照不回填，HTTP使用新原生合成测试资料，与人工原单隔离；明确区分正式HTTP真实写入、TEST合成测量输入和现实硬件/实物测量未验收。

海外仓业务/船节点标准化契约.md

@@ -64,6 +64,7 @@
 3. 节点按固定序号单调推进；迟到的较早节点仍保存为历史事实，但不能回退最新实际节点。
 4. 同一供应商事件使用稳定 `providerEventId` 幂等；重复查询不得重复插入。
 5. 一个供应商事件只映射一个最精确的标准节点，不因中间节点缺失而自动补齐整条链路。
+6. 柜级实际到港时间在预约日历、清关提柜列表与详情中统一读取 `ARRIVED_DESTINATION_PORT` 的最新非空实际事实：按 `observedAt` 降序，同观测时间按事实记录顺序降序选一条。后续观测可能修正为更早的实际日期，不得用历史 `actualAt` 最大值覆盖新观测；仅有预计时间的观测不覆盖已取得的实际到港时间。本规则不改变节点序号推进或已保存事实。
 
 ## 4. 异常事实
 
@@ -91,6 +92,16 @@
 - `sourceReference`：不含密钥和敏感参数的可审计来源引用。
 - `rawPayloadHash`：原始响应的 SHA-256；业务表不保存完整网页或敏感原文。
 
+### 5.1 响应审计与事件幂等摘要
+
+`rawPayloadHash` 仍是本次供应商整份原始响应的审计摘要，不作为同一 `providerEventId` 的不可变事件摘要。追加其他节点、调整其他节点的预计时间、改变网页排版或再次查询，均可能改变整份响应摘要；不得因此阻断未变化的旧事件及后续新事件。
+
+Firstleg 对已持久化事实和本次标准化事实采用相同字段顺序计算 SHA-256 事件事实摘要并比较：节点包含柜次、供应商/事件标识、原始节点码、标准节点、预计/实际时间、地点编码/名称和来源引用；异常包含查询任务、供应商/事件标识、原始状态、异常编码、是否生效、地点编码/名称和来源引用。查询观测时间 `observedAt`、本地写入时间与整份响应 `rawPayloadHash` 不参与该稳定事件摘要。字段空值保持空值，不用查询时间或其他字段补齐。
+
+同 ID 同事实重复查询不新增节点、异常、历史或业务事件，保留首次写入的观测时间和原始响应审计哈希；同 ID 变更上述任何事实字段必须冲突，即使供应商沿用了相同原始响应哈希也不能绕过。现有适配器的事件 ID 生成规则保持不变；预计时间变化按原规则形成独立预计事实，不推进实际节点。不得通过每轮换 ID、吞掉事实冲突或新增未知供应商状态/解除映射完成重放。
+
+预计/实际时间参与摘要前统一按现有 `DATETIME(3)` 毫秒精度四舍五入（含跨秒进位），对输入与持久化事实使用同一规则；不采用时间差容忍窗口，仍拒绝不同毫秒事实。
+
 供应商返回空字段时保持空值，不使用 `0`、当前时间、预计时间或其他字段伪造实际事实。
 
 ## 6. 已确认供应商映射

海外仓业务/车辆管理原型梳理与任务规划.md

@@ -0,0 +1,732 @@
+# 车辆管理原型梳理与任务规划
+
+> 文档状态：原型盘点、首版执行确认与开发增量记录；更新时间：2026-10-07。
+> 规划对象：Admin「车辆管理」及其与排车、海外派送、车队报价的衔接能力。
+> 本文用于确定范围、现状和任务依赖，不代表代码已经完成、已经部署或已经通过真实环境验收。
+> 开发已按后续授权推进；当前源码增量与未完成项见第 10 节。文档 Review、局部测试、真实部署和页面验收分别记录，不相互替代。
+> Review 状态：2026-10-02 已完成本次连续 5 轮核对、修订与复查，记录见第 9 节。原型事实、源码现状和候选设计已分别标明；业务决策仍见第 4 节，不等于功能开发或环境验收完成。
+> 后续业务确认：2026-10-02 用户明确“外接”为自有货物未装满时承接顺路外部货物，审核先展示详情并提供通过/打回；司机证照 30 天内到期但仍有效时允许派车并提醒，预计任务结束前过期则禁止。已确认部分与出车/金额建议见第 4.1 节，追加边界 Review 见第 4.4 节；不把建议标为用户已确认。
+
+## 本轮首版执行确认（2026-10-02）
+
+用户明确“按你的建议执行，我们先做一个版本出来，再优化和修改；验证可以宽一些”。本次确认替代下文先前标记为待答的首版选择：外接货先送我方起运仓，运营接洽并在后台登记；调度通过后拣货、理货通过后发车；车次采用独立列表和详情、计划居中弹框、其余操作在详情分区；维修/故障/救援增加“更新处理”。原运费按每票实际覆盖范围引用，另行确认的新增项目才计费；源码说明见第10.9节，当前部署、真实验收与未关闭项目统一见[测试环境单机部署与配置契约](../测试环境单机部署与配置契约.md)及[统一认证与服务通信契约](../统一认证与服务通信契约.md)。
+
+首版驾驶证为必需资质，体检/培训/保险日期先作档案记录。输入校验保留必需业务数据、权限、客户归属、防重复、实际容量及已确认的证照到期规则；普通说明、地址等选填字段宽松处理，常规动作使用标准审计说明，不要求用户重复填写。原型未覆盖的上述操作已有本轮授权，不再重复等待确认。
+
+第 4.7 节保留此前受阻时的核对经过；其“待答”状态已由本次确认解除，原目标恢复实施。实现、部署和真实验收仍分别核对，用户批准方案不代表功能已经完成。
+
+2026-10-03 财务追加确认：用户在“车辆管理｜成本与财务闭环”独立任务明确“请按你的建议来处理先”，确认维修/救援按公司车辆成本登记，不自动形成客户应收；保留CNY/USD原币，按业务月份汇率折算CNY入账。首版允许未付款费用作废重建，已付款费用禁止直接改写或作废，退款冲销后续单独确认。此项解除第4节第6项中维修/救援财务归属的待答状态；保养/加油等其他来源不据此自动扩大。费用登记、入账和付款须分别体现真实状态，不能以运维处理完成替代付款。当前实现仍由专项接入，部署及验收以两份正式主契约为准。
+
+## 2026-10-07 增量：内部拼车需求池与三种交货方式
+
+本功能进入文档审核与开发准备后，首版范围、接口决策、五轮审核和验证门禁统一维护在[内部拼车需求池首版开发契约](内部拼车需求池首版开发契约.md)。以下增量保留需求演变与完整业务方向，不覆盖新契约的统一我仓上车边界。
+
+本节记录本轮需求和接入建议，不代表新功能已经实现或部署。用户先明确三种交货方式，随后提出前期先做“我仓上车”、暂不做顺路直送，以减少工作量；最新首版建议见下段，三种方式保留为完整业务方向。现有车次主链验收不能作为需求池及沿途提货已经跑通的证据。
+
+### 最新首版收敛建议：统一我仓上车
+
+用户提出首期只做我仓上车、顺路直送暂不做。推荐首版交付内部需求池、销售意向与报价、调度确认占位、本土订单关联，以及复用现有真实到仓收货至装车签收的闭环。所有本期实际发运货物须先进入我仓，不增加沿途提货站、非仓库货物来源或行驶途中接货确认，也不修改现有“始发前外接货已实收并关联发运”的门禁。
+
+客户自行送仓与我方提货回仓均可最终进入该流程。为控制首版工作量，建议我方提货回仓暂由运营在线下安排，系统仅记录交货方式、预计到仓及备注，从实际到仓后开始收货；这不代表系统已有提货任务派车、提货交接或提货成本闭环。若要求提货过程也全部在线处理，再纳入下方B阶段。
+
+下方A/B/C顺序为完整方案储备，当前推荐先实施A；B独立提货回仓作业、C沿途直送留待后续范围确认。阶段A仍须验证真实外接货与自有货同车、客户隔离、占位转实载不重复扣减、取消释放及不重复收费；不能以发布余位列表代替完整送仓拼车链。当前仅调整方案，未据此开始代码或环境变更。
+
+### 用户已确认
+
+- 调度已约车并安排自有货后，需将去向、时间和可接余位集中展示给销售。例如去目的地 A 的车有30托位，自有货占18托位，还能寻找12托位的外接货。
+- 首期需求池只面向内部员工，销售查看后自行联系外部客户；不在此范围内建设客户公开运力市场。
+- 完整业务需要逐票选择三种交货方式：客户送到我方起运仓；我方上门提货后回我仓；我方沿途提货后直接送对应目的仓。随后用户提出首版先统一我仓上车，沿途直送暂缓；不再将三种系统执行闭环同时作为推荐首版范围。
+- 本土业务现有下单入口承接成交业务，需求池位于下单前，先让销售知道哪趟车、去哪里、何时出发、能接多少货。
+
+### 建议的业务承载与流程（待按实际交互细化）
+
+建议新增内部「拼车需求池」，由车次提供路线、发车时间和容量事实。调度核对计划后发布可接货需求，销售按起运区域、目的地、时间和交货方式筛选，并登记客户意向；调度确认承运后占位，再关联正式客户订单和该车次，按交货方式履约。询价不占位，已确认预订扣减可接容量，沿用现有外接预订规则；是否提供有时限的临时留位另行定义，不默认新增。
+
+| 交货方式 | 建议履约路径 | 必须保留的实际事实 |
+| --- | --- | --- |
+| 客户送仓 | 客户送到我仓 → 实际收货、测量及入库 → 绑定干线车次 → 拣货、装车 → 目的仓签收 | 到仓实收、库内库存和出库事实 |
+| 我方提货回仓 | 安排提货任务 → 客户地点交接 → 运回我仓 → 实际收货、测量及入库 → 干线装车 → 目的仓签收 | 提货交接与到仓收货分别记录；提货车辆和干线车辆可不同，费用不可重复收取 |
+| 沿途提货直送 | 安排本车提货站 → 到站交接、核量及装车确认 → 按路线送目的仓 → 签收 | 客户地点实收和车上货物事实；不虚构我仓入库、库位、仓库托盘或仓库出库单 |
+
+需求池建议展示：车次号、起运仓/区域、已有途经及卸货站、计划发车与最晚交货时间、整车容量、自有货预计占位、外接已确认占位、可接托位、剩余重量/体积、允许交货方式、调度联系人、接货状态。客户意向需记录销售负责人、客户、提货地址（需要提货时）、目的地、预计托位/重量/体积、交货时间和报价。客户业务单据、预订与车次建立明确关联，销售无需重新录入另一套容量。
+
+### 容量与变更建议
+
+- 30−18=12仅适用于同一运输区间且重量、体积也允许的情况。客户占8托位并确认后，同一区间余4托位；不同销售同时确认时必须由服务端避免超卖。
+- 沿途提货按“提货站至卸货站”逐段预留容量。计划阶段即占用对应未来区间，不能等实提才扣可售余位；实际车上数量则在提货交接后增加、卸货签收后减少。
+- 示例：我仓带18托去 A，途经 B 提12托一起送 A；我仓→B 实载18托，B→A实载30托。若这12托已确认，B→A余位已为0，不能再对该区间承诺12托。
+- 回仓提货独立核对提货任务运力；回仓后的干线预订也需占位，同一批货不能在同一车次被预订和实际装载重复扣减。
+- 自有货、车辆容量或路线变化后重新核对有效余位；容量计划失效时展示“待调度核对”并停止新承运确认，不能把未知显示成有空位。超出原已发布路线的提卸点需调度调整路线并复核承诺。
+- 需求发布、暂停接单、满位、取消及发车后接单规则属于需求池状态，不混同车次运输状态。首期是否允许车辆出发后再接新的沿途订单，尚未确认；已在出发前确认的沿途提货必须正常执行。
+
+### 当前源码与缺口
+
+| 部分 | 当前核对事实 | 本次需补齐 |
+| --- | --- | --- |
+| 车次与容量 | Admin `TripsView.vue`已有车次列表；详情 `capacity-plan` 返回有效计划和扣除外接后的逐段余位，列表没有面向销售的余位发布入口 | 跨车次需求池查询、发布/暂停/关闭、销售意向及责任人；服务端统一返回有效可接运力 |
+| 外接预订 | `TripBookingPanel.vue`及`bookingTypes.ts`已有询价、确认承运、实收、关联发运和取消 | 从需求池带入车次与路线，扩展逐票交货方式、提货站和交接事实 |
+| 容量算法 | `TripCapacityPolicy.Booking`支持提货/卸货站区间；当前`FleetBookingReservations.add`固定从站点0占位 | 将真实提货站接入预订、计划变更和发车/到站复验，不能仅在页面增加选项 |
+| 来货及库存 | `FleetIncomingAdapter.create`固定`CUSTOMER_DELIVERY`并调用仓储转运来货流程，实收证据来自本仓托盘 | 保留客户送仓链；增加提货回仓任务衔接，以及不经仓的沿途提货直送履约来源 |
+| 本土下单关联 | 当前正式菜单名称是「本土卡车」「本土散板」；外接预订的当前来货链是仓储转运，不证明已经关联这两类订单 | 明确每票对应的业务单据及单一收费来源；从需求池转单携带预订和车次关联，禁止重复下单、占位或收费 |
+
+验收应分别覆盖三种交货方式，并验证：30托位/自有18托位/外接12托位、并发确认不超卖、不同提卸区间、不足或超量实收、货物及路线变更、取消释放、回仓两段运输关联、直送不产生虚假仓库库存、签收回传与收费不重复。此前灰度FBA自有货主链通过，不替代这些新增场景。
+
+### 推荐实现方案：沿现有车次接入（设计建议，非已实现）
+
+建议仍在 Lastleg 现有车辆与本土业务内实现，复用统一 Gateway/Auth、客户隔离、File 和 Finance。不新增独立撮合服务，不复制一套车次、库存或财务账。
+
+**页面和职责。** 在「车辆管理」增加「拼车需求池」，销售可直接进入；车次详情增加“发布拼车需求”及关联入口。需求池每条需求关联唯一车次，展示可接运输区间，余位实时来自服务端有效容量与已确认预订，不让销售手填剩余托数。建议车次先待发布，调度确认路线、时间和可承诺容量后发布；自有货或预订变化自动更新余位，计划失效则暂停承诺。多站路线不能只展示一个没有运输区间的“剩余12托”。
+
+销售负责登记客户意向、选择三种交货方式、报价与跟进；调度负责发布、确认路线及承运占位、安排提货和车辆；仓库负责实际过仓货的收货、拣货与出库。销售看运力及自己获授权的客户资料，不因需求池访问而获得同车其他客户货物、成本或全部司机资料。发布、询价登记、确认占位及提货确认采用独立写权限，不把销售统一授为车次管理员。
+
+**单据关联。** 建议采用“车次 → 发布需求 → 客户意向/预订 → 本土业务订单 → 履约任务”的关联。复用外接预订的询价和承运确认；内部销售成交时在同一业务动作中关联或生成本土散板/本土卡车单据，不要求再去两个页面各下一单。已有本土订单也可选符合路线的车次进行匹配，一票可依法分段运输但同一段货物不可重复占位。同一客户委托可以对应提货回仓和干线配送两段任务，仍保持同一业务来源与可追踪费用。
+
+本土单据记录客户委托、交货方式、货物及已确认交易条件；预订记录该订单在哪个车次、哪个提卸区间占多少位；任务记录谁在何时、何处实际接货和交货。报价预算、确认成交价与财务应收/实收分别处理；预订、提货任务和最终派送引用同一已确认费用来源，新增提货费须独立确认，不能因生成新任务再收一次原运费。当前 `LocalLooseboardRequests`/`UsTruckOrderRequests` 没有这套车次关联，须连同平台和客户消费者更新正式合同。
+
+**三种方式如何进入执行。**
+
+1. 客户送仓：关联既有来货流程；PDA 实收、核量确认后，将已确认预订占位转换为实际发运货物占位，不能两份同时扣容量。
+2. 提货回仓：从客户订单派生提货任务，记录地址、预约窗口、联系人、承运车辆、实际提货数量和交接附件；可由另一趟车执行。回我仓须重新完成真实收货事实，再承接原干线预订。提货成功不等于仓库收货成功。
+3. 沿途直送：同车次添加有顺序的提货站和卸货站，增加不依赖仓库托盘的运输货物来源。出发前可保留尚未提取但已确认的后续站货物；当前站必须装车的货物仍需就绪。到提货站后核对实际托位、重量、体积及交接证据，通过下一段容量校验才允许继续；超量、少到、未到和改目的地由调度处理，不能自动超载或将未提货标成已承运。
+
+首版建议由调度在后台维护提货任务并录入实际交接结果及附件，仓库 PDA 继续承载过仓作业；司机专用移动作业入口另定交互，不把仓库 PDA 的仓库绑定权限直接放宽为司机跨地点权限。若需司机现场自行操作，须作为同一履约任务的授权入口接入，而非另一套运输状态。
+
+**必须修改的核心门禁。** `FleetTripExecutionService` 当前从仓库排车明细生成实际装载，并在 `hasConfirmed` 为真时阻止发车（外接货尚未关联实际发运货物）。新增沿途直送后，要按站点区分“此站应装货”和“后续待提货”，分别核对当前装载、未来预留、已发生运输段及未完成交接；不能直接删除既有外接未就绪门禁。全车结案须包含直送货签收结果，不能只检查原仓库派送单。已完成站点和历史实载不可通过修改计划重写。
+
+**建议实施顺序与交付边界。**
+
+| 阶段 | 交付物 | 验收重点 |
+| --- | --- | --- |
+| A：销售可用的需求池 | 车次发布与集中查询、线路/时间/余位筛选、销售意向、确认占位及本土订单关联；沿用送仓履约 | 30托位自有18托位，确认外接8托位后余4；多销售并发确认拒绝超卖；旧容量失效不可继续接单；已有订单匹配不重复下单/收费 |
+| B：提货回仓 | 提货任务、车辆安排、交接与回仓收货、同单两段运输关联 | 提货与入仓分开确认；提货车和干线车不同；货量差异重新核量；预订与实收不重复扣位 |
+| C：沿途提货直送 | 提卸站点、非仓库运输货物、分段装载与提货确认、签收/结案及统一费用来源 | 后续提货不阻断合法始发；沿途每段不超载；未提货/部分提货/改配有处理记录；不生成虚假本仓库存；直送未结束不得整车结案 |
+
+A/B/C 为完整方案依赖顺序，按用户后续提出的收敛方向，当前推荐首版先交付A并用包含自有货和外接货的真实车次验收；这不证明B独立提货任务或C沿途直送已实现。各后续阶段单独确认范围、实施和验收。未实现的交货方式不得在可成交页面提供虚假的成功路径。
+
+待进一步确定的业务选择仅保留会改变执行边界的项目：出发后是否允许新增外接订单、是否允许销售临时留位及有效期、提货操作是否首版由司机本人在移动端完成。以上建议未被标记为用户已确认；本节不改变已确认的内部需求池和三种交货方式。
+
+## 1. 读取范围与事实优先级
+
+本次原型输入是用户提供的外部文件：
+
+`C:\Users\BY-OY\Documents\WXWork\1688854456873012\Cache\File\2026-09\新版.html`
+
+文件读取时间为 2026-09-30。它不属于仓库事实源，文中的示例数据、模拟状态和按钮反馈只用于说明页面意图。新版文件把车辆管理拆成多个页面和弹窗，不能只按“车辆列表”一个页面排任务。
+
+本次连续复核的原型快照 SHA-256：`D12B35F5363ED9B67A33E9D12D542DD902628BC946F75519BC7DDC049D94CD65`。行号只对应这一文件版本；后续原型变更需重新核对交互，不能仅凭同名函数认定行为相同。
+
+实现范围按以下顺序核对：当前对话确认和正式契约，现有 Controller/OpenAPI/权限/SQL，当前 Admin 路由和页面，原型与参考资料。原型出现的功能需要补齐服务端契约和验收证据后才算有效实现。
+
+当前架构使用统一 Gateway、统一 Auth 会话和统一测试环境。后续新增接口应沿“浏览器实际路径 → 统一 Gateway → Controller → OpenAPI → 权限”核对，不按旧资料中的独立海外 Gateway 建立第二套入口。
+
+## 2. 原型实际包含的页面
+
+### 2.1 页面入口总表
+
+| 原型页面/入口 | 原型位置 | 页面职责与主要内容 | 当前原型行为 | 规划判断 |
+| --- | --- | --- | --- | --- |
+| 排车列表 `outbound-vehicle` | 菜单 `新版.html:1452`；页面 `4474-4486` | 装车前/装车中/装车后三阶段；装车前再分车辆信息、调度审核、理货员审核；按排车单号、车牌、车辆状态筛选；展示司机、电话、托车公司、预约号、派送单、托数、装车时间、FBA/车辆预约等 | 以原型数据和已有页面脚本渲染，审核、附件、轨迹等动作主要是页面演示 | 与正式排车模块连接，不能复制出第二套排车状态或车辆快照 |
+| 排车详情 `outbound-vehicle-detail` | 页面 `9433-9445` | 排车单号、状态、车辆/排车信息，以及关联订单明细（订单号、重量、托数、目的 FBA 仓、体积、集装箱号） | 由原型数据渲染关联订单表和详情字段 | 复用现有 `/overseas-warehouse/dispatches/:dispatchNo` 与 `DispatchDetailView.vue`；车辆管理入口只做跳转，不新建排车详情 |
+| 排车编辑/审核/订单选择弹窗 | `modal-outbound-vehicle-edit` `12338+`；`modal-outbound-vehicle-audit` `12396`；`modal-outbound-vehicle-rejected` `12397`；`modal-outbound-vehicle-order-select` `12411+` | 维护车辆、司机、预约和路线；上传附件；调度/理货员审核、驳回原因；选择待派送订单 | 表单、附件和审核结果主要写入原型内存并弹 Toast | 归入 VM-04a：复用现有详情/编辑，审核须补提交、通过、驳回、重提及权限/版本契约；普通编辑不代表已提交审核 |
+| 车辆列表 `vehicle` | 菜单 `1453`；页面 `8819-8886` | 国内/海外区域页签；自有/外派归属页签；按车牌、司机、车型和状态筛选；新增、导出；两类车辆不同表格列；列表下方预留配送进度和运营记录 | 列表数据在 `ownVehiclesData`/`dispatchVehiclesData` 内存数组中；新增、编辑、删除、状态校验和提示均在浏览器内完成；配送进度卡片在页面 CSS 中隐藏，运营卡片在详情时被移动 | 车辆主数据沿用当前真实模块；新增字段和运营记录需先定服务端归属 |
+| 车辆新增/编辑 `modal-vehicle-edit` | `8890-8935` | 归属、车牌、车型、油耗、当前公里码、电话、外派单位、区域、状态、停运原因、FBA 仓、发车时间、预计到达时间；自有车辆编辑时附带保养和加油字段 | 必填校验、派送中/停运中条件校验和本地数组更新；图片字段是字符串或示例文本 | 不直接照搬字段；公里/迈数、司机绑定、运单关联和附件归属需形成正式模型 |
+| 车辆详情 `vehicle-detail` | 页面 `9024-9051` | 车辆概览、保养及加油、维修记录、紧急故障、应急救援、异常管理六个页签；概览含车辆信息和派送订单明细；各扩展页签可新增记录 | 详情由本地数组拼装派送订单；更换历史缺页面容器；维修/故障/救援/异常共用未按车辆隔离的数组，部分保存字段错配 | 当前真实车辆详情只承载车辆主数据，服务端明确不含派送履约/更换历史；扩展页签必须逐项立项 |
+| 司机管理 `driver-management` | 菜单 `1454`；页面 `8798-8805` | 司机总数、即将到期、驾照过期 KPI；“当前可派”卡片在源码中保留但被 CSS 隐藏；资质提醒；按姓名/手机/司机编号、状态、归属、资质筛选；司机档案表；新增、查看、编辑、删除、驾驶证附件查看 | `driverManagementData` 内存数组；根据当前日期计算驾照到期；缺附件或未审核显示待补件；资格阻断只显示提示，未联动排车保存；保存和删除只更新数组并弹 Toast/confirm | 需要独立司机主数据、资质状态机、附件和派车资格接口，不能把司机字段继续塞进车辆表 |
+| 司机详情 `driver-management-detail` | 页面 `8807-8813` | 基础信息、驾驶资质、证照与派车状态；查看驾驶证附件 | 由司机内存数据拼装 | 需要真实详情 API；资格结果必须由服务端返回，页面只展示 |
+| 司机新增/编辑 `modal-driver-edit` | `8815-8816` | 姓名、电话、归属、仓库、车型、语言/区域；驾照类型/编号/签发/到期；体检、培训/安全、保险到期；审核状态；驾驶证和其它附件上传 | 强制上传驾驶证后才允许保存；文件使用 data URL 暂存 | 文件应接经评审的上传与附件归属能力，司机资格审核和附件归属需进入正式契约 |
+| 自有业务 `vehicle-own-business` | 菜单 `1455`；页面 `8757-8762` | 日期范围、排车单号/车牌/FBA 仓、任务状态、仓库筛选；今日排车、装车完成、派送中、派送完成 KPI；任务明细含预约、车辆、司机、提货仓、目的仓、托数、油耗、价格、装车/到达时间 | `vehicleBusinessRecords` 内存数组；KPI 和总价/单价在浏览器计算；可查看详情、上传现场/油耗图片和实际迈数 | 应消费正式排车/派送事实和服务端 KPI；不能把业务履约复制为车辆主数据记录 |
+| 自有业务详情 `vehicle-own-business-detail` | 页面 `8764-8774` | 任务与车辆信息、路线货物与现场凭证、操作记录三页签；显示预设路线、GPS、ETA、油耗、费用预算和证据清单 | 详情字段、时间线、路线和证据状态为脚本拼装；上传仅修改内存对象 | 需要与排车、PDA、派送和文件服务建立稳定关联；GPS/路线告警先确认是否纳入本轮 |
+| 外配业务 `vehicle-outsourced-business` | 菜单 `1456`；页面 `8778-8796` | 待外配托数、今天外配托数、在途车辆 KPI；合作车队/异常任务卡片被 CSS 隐藏；按任务号/车队/车牌/FBA 仓和任务状态筛选；展示总托数、自有成本、自有托数/单价、外接托数/金额/单价、ETA、状态 | 与自有业务共用 `vehicleBusinessRecords`；部分操作调用自有业务详情和上传照片逻辑；示例成本、托数和报价在浏览器渲染 | 用户已明确外接为利用自有货运输的剩余运力承接顺路外部货物；原型名称保留作追溯，后续建议改称外接业务，详见第 4.1 节 |
+| 出车记录 `vehicle-trip-record` | 菜单 `1457`；页面 `8941-8987` | 时间区间统计四张图（托数、派送仓库、价格、托均价）；按车牌/提货仓/派送仓、车辆类型、日期筛选；添加、编辑、导出Excel占位按钮；删除函数未发现页面调用；装车/派送完成时间、用时、托数、价格、托均价、油耗、图片附件 | `vehicleTripRecords` 内存数组；派送用时、托均价和图表汇总由浏览器计算；图片使用 data URL；时间校验只在前端；导出仅弹 Toast | 先定义出车记录来源和唯一性，再决定独立事实表还是由派送单投影；“板/托”“公里/迈”“油耗单位”必须统一 |
+| 派送车队报价 `delivery-fleet-quote` | 通用菜单 `1527`；页面 `8989-9021` | 按发货城市、目的 FBA 仓、车队、提货方式、状态筛选；新增/编辑、启停、删除、导出；CSV 模板下载、预览校验、批量导入 | `deliveryFleetQuoteData` 内存数组；校验必填、非负价格和“城市+仓点+迈数+车队”重复组合；导入只写浏览器数组 | 先按第 4.1 节区分外接销售价与车队采购价，再定客户/供应商关联；CSV 导入需服务端校验和重复处理规则 |
+
+### 2.2 车辆列表和详情的字段与交互
+
+配套弹窗也属于本轮原型范围：车辆运营记录 `modal-vehicle-ops-record`（`8937`）、车辆详情扩展记录 `modal-vehicle-detail-add`（`8938`）、司机证照查看 `modal-driver-license-view`（`8816`）、出车记录 `modal-vehicle-trip`（`8966`）以及车队报价编辑/导入 `modal-delivery-fleet-quote`、`modal-delivery-fleet-quote-import`（`9009`、`9021`）。它们不单独扩成新的业务页面，分别随 VM-02、VM-03、VM-05、VM-06 的正式契约开放。
+
+车辆列表在原型中有两套列：
+
+- 自有车辆：车牌、车型、油耗、当前迈数、联系人、联系电话、状态、操作。
+- 外派车辆：操作、车牌、车型、外派单位、联系电话、托数。
+
+区域页签和归属页签同时存在，形成两个主切换维度；原型还把车辆配送进度、运营属性、保养加油和路线告警放在同一页面结构中。当前代码已按正式接口将区域降为查询条件，只保留自有/外派归属页签，并把操作列固定在第一列；该布局有现有原型矩阵记录的历史确认作为依据；若本轮重新确认布局则更新相应合同，代码现状本身不覆盖新需求。
+
+新增/编辑弹窗的原型校验包括：车牌、车型、油耗、公里码必填；状态为“派送中”时要求 FBA 仓、发车时间和预计到达时间；状态为“停运中”时要求停运原因。上述校验目前只是原型脚本行为，最终规则要由服务端状态机确认。
+
+新版车辆详情实际有“派送订单明细”；更换历史仍保留 `renderVehicleFleetHistory` 函数，但它读取的 `vehicle-detail-history-body` 仅在该函数中出现，未找到页面容器，不能算作当前可见分区。当前真实车辆主数据合同排除派送履约及车辆更换历史：Controller 注释排除前者，OpenAPI 的车辆详情 `GET /{id}` 明确排除两者。现有 Admin 详情仍保留这两块边界提示。若新增真实历史查询，需先确定订单/排车查询与更换历史的归属，不能把旧页面提示当作新版已经提供该功能。
+
+运营扩展也存在未闭合交互：`vehicleDetailExtraRecords` 是按记录类型保存的全局数组，保存/渲染未带车辆标识；`openVehicleDetailAdd` 生成描述和处理人等字段，而维修/救援保存分支读取不存在的 `vda-item`、`vda-place`，会丢失录入信息。救援列表列名为“付款状态”，弹窗却选“待处理/处理中/已完成”。此外，车辆属性和路线告警面板在打开车辆详情时被隐藏，不能把源码内预留字段全部当成当前可操作需求。正式设计应分别确认记录归属、各类型字段、处理状态和付款状态。
+
+### 2.3 原型中明确出现的规则冲突
+
+| 主题 | 原型表现 | 需要冻结的正式口径 |
+| --- | --- | --- |
+| 距离单位 | 车辆列表弹窗使用 km；运营卡片、路线和车队报价使用 miles/迈数 | 车辆里程、路线距离和报价距离分别定义单位；接口禁止以字段名猜单位 |
+| 托数单位 | 出车记录表头初始写“板数”，脚本又改成“托数”；外配业务使用总托数/外接托数 | 统一业务词和字段名；托盘数量与板数不能在前端静默换算 |
+| 油耗单位 | 百公里油耗使用 L/100km，加油记录示例使用 gal，出车记录油耗使用 L | 定义车辆档案、加油事实、出车消耗的单位与换算责任，服务端返回展示单位 |
+| 车辆合作方术语 | 原型混用“外派车辆、外配业务、合作车队、车队渠道、托/拖车公司” | 冻结用户可见词和服务端枚举/字段映射，避免把司机、承运商、车队和拖车供应商当成同一对象 |
+| 车辆与排车关系 | 车辆列表有配送 FBA、发车时间和 ETA；排车列表也维护车牌、司机、预约和状态 | 车辆主档只保存可复用属性；排车/派送保存任务快照和执行事实，避免双写状态 |
+| 删除 | 车辆、司机、车队报价有删除操作；出车删除只有未接入函数 | 分对象确定删除、停用、作废或更正语义；没有合同的动作不开放，不能自动用停用/作废替代 |
+| GPS/路线 | 原型写“GPS 轨迹监控已启用”、路线偏离和 ETA 告警 | 先确认已有设备/轨迹来源和告警服务；没有正式来源时只能展示待接入状态 |
+| 资格阻断 | 页面用日期、附件和审核标识显示资格与阻断提示，未形成排车拦截 | 临近到期规则已确认：30 天内仍有效允许并提醒，预计任务结束前过期禁派；由服务端返回资格和原因。核验时点及时间边界建议见第 4.4 节 |
+
+### 2.4 原型统计与报价口径
+
+原型中的金额和统计还需注意以下差异（均为原型事实，不自动成为正式口径）：
+
+- `renderVehicleBusiness` 的“今日排车数”实际取筛选后的行数，不独立限定今天；外配“今日外配任务”被脚本改名为“今天外配托数”，对应数字仍是静态值。正式 KPI 需明确日期字段、仓库时区、筛选范围、单位及聚合粒度。
+- `renderVehicleTripCharts` 的“派送仓库”总数是去重仓库数，图中各仓的值却是出车记录条数；托均价是总价格除以总托数，并非各行单价的简单平均。正式报表应明确两个指标的名称，混币种不能直接求和；原型同时以列表日期和统计日期过滤，需要确认正式查询与图表是否共用范围。
+- 车队报价 `validateDeliveryFleetQuoteDraft` 允许三种价格仅填一种，空值表示未报价，0 是允许输入的数值；CSV 确认导入会跳过无效/重复行并插入有效行。正式合同须确认沿用部分成功还是整批原子提交，不能把空值转换成免费报价，也不能默认原型为全成功导入。
+
+## 3. 当前代码、接口和数据现状
+
+### 3.1 已具备的车辆主数据能力
+
+当前 Admin 和 Lastleg 已经有一套真实车辆主数据能力，不能按旧缺口文档中的“车辆缺失”处理：
+
+| 层次 | 当前入口 | 已有能力 |
+| --- | --- | --- |
+| Admin 导航 | `apps/admin-web/src/core/navigation/adminNavigation.ts:120-126` | 车辆管理下已有“排车列表”和“车辆列表”；车辆列表路由为 `/overseas-master-data/vehicles` |
+| Admin 页面 | `apps/admin-web/src/modules/overseas-master-data/pages/VehiclesView.vue`、`VehicleDetailView.vue` | 真实分页、关键词/归属/区域/状态筛选、查看详情、新增、编辑、状态变更、CSV 导出；操作列固定在左侧 |
+| Admin 路由/权限 | `apps/admin-web/src/modules/overseas-master-data/routes.ts`、`permissions.ts` | 车辆列表和详情使用 `vehicle:list`；创建、编辑、状态、导出权限独立 |
+| 后端 Controller | `baiyue-firstleg/lastleg-service/src/main/java/com/baiyue/lastleg/masterdata/vehicle/adapter/in/web/PlatformVehicleController.java` | 列表、详情、创建、编辑、状态、导出；编辑和状态使用 `recordVersion` 乐观锁 |
+| OpenAPI | `baiyue-firstleg/lastleg-service/src/main/resources/openapi/overseas-master-data-v1.yaml` | `/api/platform/v1/last-leg/master-data/vehicles` 的 GET/POST、`/export` GET、`/{id}` GET/PUT、`/{id}/status` PATCH |
+| 数据库 | `baiyue-firstleg/lastleg-service/src/main/resources/db/lastleg.sql` | `ll_vehicle`，车牌唯一；保存区域、归属、状态、里程、油耗、司机/外派单位、电话、备注和版本 |
+| IAM | `baiyue-firstleg/iam/src/main/resources/db/lastleg-permissions.sql` | `platform:overseas-master-data:vehicle:{list,create,edit,status,export}` |
+| 测试源码入口 | Lastleg 车辆 Controller/Application/SQL/OpenAPI 合同测试；Admin 车辆 API、挂载、视图和写行为测试 | 已定位到测试文件；本次未运行这些功能测试，文件存在不代表当前全部通过，也不证明部署或整套车辆管理完成 |
+
+当前车辆主数据接口字段包括车牌、车型、百公里油耗、当前里程、司机/外派单位、电话、区域、车辆归属、状态、备注、记录版本和更新时间。本轮已增加最大标准托位、最大载重kg和可用容积m³，三项同填正数或全空待确认；车次分配不接受未知容量。服务端不提供车辆删除端点，当前 Admin 不展示删除动作。
+
+需要保留的已有规则：车辆创建/编辑将车牌去除首尾空格并转大写，数据库对车牌做全表唯一约束；编辑时公里数不得小于原值；编辑和状态操作检查 `recordVersion`。当前状态为 `IN_SERVICE/在役`、`DISPATCHED/外派中`、`MAINTENANCE/维修中`、`INACTIVE/停用`、`RETURNED/已归还`，与原型“空闲/派送中/停运中”并不一一对应。`changeStatus` 只校验枚举与版本，没有按当前派车任务检查状态迁移；不能据此宣称已经实现车辆占用和释放。出处为 `VehicleApplicationService.create/update/changeStatus`、Admin `presentation.ts` 和 `ll_vehicle` 唯一索引。
+
+### 3.2 原型范围与当前实现的差距
+
+| 能力 | 当前状态 | 结论 |
+| --- | --- | --- |
+| 车辆主档列表/详情/新增/编辑/状态/导出 | 已有真实前后端合同 | 作为基线复用；先补字段和状态确认，再决定是否扩表 |
+| 车辆运营属性（初始里程、停放位置、司机绑定、租赁状态） | 原型 `vehicleAttributeData` 和隐藏面板中预留 | 缺正式 DTO、表和权限；不能写入浏览器本地状态后宣称完成 |
+| 保养与加油 | 已有独立车辆运维记录模型、文件归属、版本及历史，Admin 按车辆分页查询并接入新增/编辑和图片读取；实现边界见第 10.1 节 | 本地实现不代表环境已部署；不自动改车辆里程、占用或财务付款 |
+| 维修、紧急故障、应急救援、异常管理 | 已接逐车新增/展示，异常支持编辑；修复原型字段错配并分离处理与付款状态，见第 10.2 节 | 维修/故障/救援后续更新入口仍待承载方式确认；财务闭环及真实环境验收未完成 |
+| 司机主数据与资质 | 已新增司机后端、文件接入、Admin 列表/详情/编辑/审核/证照预览，补齐真实仓库关联与可选资质日期；车次分配、调时和整车 PDA 发车均复核资格；本地验证见第 10 节 | 实际命令的源码已接入，真实部署及 HTTP/PDA 验收尚未完成，不能以独立资格预览代替发车校验 |
+| 自有/外接业务工作台（原型名外配） | 现有正式排车/派送模块存在，但没有原型同名工作台 | 已确认顺路拼载业务；建议按共享行程关联各客户单据，工作台展示自有/外接货物分项，详见第 4.1 节 |
+| 车辆详情中的派送订单/更换历史 | 新版有派送订单展示，更换历史缺容器；车辆详情尚未接入两类记录，页面引导从现有排车/派送管理查看派送事实，明确更换记录未接入 | 车次已有改派历史，但不等于车辆详情已有跨车次履历；后续补真实查询，不以说明文字代替功能 |
+| 出车记录与统计 | 原型本地数组和浏览器图表 | 需要确定事实来源、唯一键、费用归属、油耗证据和统计口径 |
+| 派送车队报价 | 原型内存数组、CSV 解析和浏览器校验 | 先区分外接销售报价与车队采购报价，再决定模型复用和客户/供应商关联，不能将外接收入建成供应商应付 |
+| 车辆管理新增菜单 | 当前源码已注册排车列表、车辆列表和司机管理，司机详情使用独立路由 | 自有业务、外接业务、出车记录等菜单继续随对应正式接口接入；源码注册不表示环境已发布 |
+
+### 3.3 与现有排车和车队能力的边界
+
+现有海外排车正式入口是 `apps/admin-web/src/modules/overseas-warehouse/`，后端入口在 Lastleg `dispatch/`；排车状态、PDA 拣货、发车门禁、转派送和派送完成属于排车/派送链路。目的港码头车队选择属于货柜聚合的码头拖车链路，使用供应商主档和独立权限。车辆主数据只维护车辆档案和可复用属性，不能成为排车状态或码头车队事实的第二个写入口。
+
+### 3.4 已验证的现有执行顺序
+
+本节记录共享车次接入前的执行链，作为继承关系与缺口的对比依据；当前车次增量以第 10 节为准。不表示已经完成真实环境验收，也不把新增原型审核作为既有前置条件。
+
+1. **预排车**：候选列表可跨客户查询，但单次创建排车须选同一客户、同一海外仓的托盘。不能把“跨客户可查看”理解为“一张排车单允许跨客户混装”。依据：`DispatchService.resolveCustomerScopeForPallets`、`requireSingleCustomerScope` 和 `preArrange` 的仓库校验。
+2. **维护本次排车信息**：当前请求保存车牌、司机姓名/电话、承运商名称、预约和预计时间等文本/快照；未形成车辆档案 ID、司机档案 ID 关联及资格门禁。车辆档案状态不等于本次排车状态。
+3. **发车前完成两组条件**：现场 PDA 完成拣货并核平箱数；后台在允许阶段执行“转派送”。转派送可早于拣货完成，但货物必须已收货并绑定实物托盘，且必须早于发车。两组条件不是必须按固定先后完成的串行操作。
+4. **转派送生成单据**：一张排车单对应一张出库单，派送单按目的地分组。FBA 仓是常见分组；当前 `DeliveryTransferService.deliveryGroupKey` 也处理私人地址与邮编，并以目的仓编码或 ID 分组，不能将能力范围仅写成 FBA。此时出库单为 `WAIT_OUTBOUND`，生成派送单本身不表示车辆已出发。
+5. **PDA 发车**：当前 `DispatchPdaWorkflowService.requireVehicle` 只检查车牌非空；还检查绑定仓、拣货任务完成、全部箱数核平、排车为 `READY_TO_DEPART`、出库单为 `WAIT_OUTBOUND`。通过后扣减对应已拣库存，出库单变为 `OUTBOUNDED`，排车变为 `DEPARTED`。没有现成的车辆主档可用性、司机证照或两级审核门禁，不能将“车牌非空”表述为“车辆与司机完整合规”。
+6. **目的地分别签收**：`DeliveryDocumentService.save` 在有效状态下把非空 `RECEIPT` 资料保存进正式快照，才自动完成当前派送单；单纯上传文件不触发完成。一张派送单完成不代表其他目的地同时完成，也不自动证明新增的“整次出车记录”已经结案。
+
+并发与快照边界也有现状差异：车辆主档有 `recordVersion`，但 `DispatchRequests.Update` 没有客户端期望版本，`DispatchService.update` 使用行锁且仅允许 `PENDING_DEPARTURE` 编辑；行锁不等于能识别用户提交的过期表单。转派送会把当时的车牌/司机等信息保存到派送单，后续修改排车是否同步、是否重新审核必须单独规定。排车取消、移除托盘、出库取消是不同命令，不能将其理解为任意阶段一键撤销整条链路。新增审核和改派须同时定义并发版本、审核依据快照和关联单据处理规则。
+
+现有执行链为：**预排车 → 维护车牌等任务信息 →〔PDA 拣货核平 + 发车前转派送〕→ PDA 发车出库 → 各目的地分别签收**。司机资质、两级审核、运维、行程汇总与自有/外配工作台如何接入，属于本次新增设计。
+
+### 3.5 本次排查发现与纠正
+
+以下原型行号均指第 1 节的外部 `新版.html`，通过静态脚本核对，未作浏览器视觉验收。
+
+| 严重程度 | 先前表述的问题 | 本次核对结果与处理 |
+| --- | --- | --- |
+| 高 | 把“调度审核 → 理货员审核”直接接在现有 PDA 流程前，且任务写成只复用现有审核 API | 原型 `18589-18599` 确实演示调度通过转理货审核、理货通过进入装车中；已检查的 dispatch Controller/DTO/Service 没有对应审核命令。普通排车编辑 `18804-18829` 也没有重置审核阶段/驳回状态，只有散板上下文分支写待调度审核。原型本身的提交与驳回重提尚未闭合；需新增审核契约，并确定与 PDA 开工/发车的关系，不能直接复用不存在的 API |
+| 高 | 把司机页面显示“已阻断派车”当成真实业务阻断 | `openDriverDetail`（`22702`）只生成提示文字，且将“即将到期”也显示为阻断，与“30 天提醒”文案不一致；排车保存未联查司机档案，当前服务端也未关联司机资格。资格计算、临近到期是否阻断、提交和发车时是否重新核验需要分别定义 |
+| 高 | 把自有/外配页理解为排车生成后的现成视图，把外接金额直接解释为车队应付 | `vehicleBusinessRecords`（`22627+`）是独立示例数组；排车用另一组 `outboundVehicleData`，出车统计又用 `vehicleTripRecords`。现有脚本没有证明三者自动同步。外配行同时含自有托数/成本、外接托数/金额，且示例混用人民币与美元；只能说明原型要展示这些列，不能据此决定货源、承运关系、应收/应付或财务自动入账 |
+| 中 | 把出车记录的删除函数算成可用按钮，并把导出写成原型未要求的可选扩展 | `8953` 有“导出Excel”按钮，但只弹 Toast；`renderVehicleTripRecords`（`22953`）行操作只渲染编辑；`deleteVehicleTripRecord`（`23057`）仅找到定义，未找到调用入口。更正为：新增/编辑可演示，导出是占位交互，删除存在未接入函数 |
+| 中 | 默认无 DELETE 就提供停用/作废，且一律按车辆主数据合同处理 | 车辆主档当前无 DELETE；排车则有 DELETE 路径承载取消，HTTP 方法不能代表物理删除。新司机、运维、出车记录的停用、作废、删除或更正须各定生命周期，不能凭缺少端点自行增加替代动作 |
+| 中 | 直接描述“司机/车辆资格齐全 → 发车”，并遗漏单客户同仓与私人地址派送 | 当前实际条件和单据关系以第 3.4 节为准。完整资格校验是新增工作；“转派送在发车前”这一结论经代码复核仍成立 |
+
+## 4. 业务决策与剩余边界
+
+以下为决策清单，按受影响工作包分别冻结；已有代码规则不因列入讨论而自动失效。无关问题未定不阻止已确认部分的实现；未定业务不能由页面本地字段代填：
+
+1. 本轮是否一次纳入新版原型的司机管理、自有业务、外配业务、出车记录和派送车队报价，还是先完成车辆主档的第二阶段增强。
+2. 国内车辆和海外车辆是否共用同一车辆主档；区域是否只是查询维度，还是决定所属仓、时区、单位和可派送范围。
+3. 自有车辆、外派车辆和租赁车辆的归属枚举；外派车队、司机和车辆之间是否允许一对多历史绑定。
+4. 车辆状态、排车状态、司机资格状态和派送状态分别由哪个服务维护，哪些状态可以相互阻断；现有五种车辆状态与原型三种状态如何映射。两级审核状态应与拣货/装车/发车的实际执行状态分别定义，不能用审核通过伪造现场开始时间。
+5. 已确认采用 30 天临近到期提醒及第 20 项禁派规则。尚需确定必需资质清单和审核角色：驾驶证之外的体检、培训/安全、保险是否全部必填，不能由原型字段自动推为必需。
+6. 车辆运维记录是否要进入财务费用池；保养、加油、维修和救援费用的币种、汇率、税费、结算单关联和付款状态由谁确认。
+7. GPS/路线/ETA 的设备和数据来源；如果没有正式来源，原型中的轨迹、路线偏离和自动告警是否延期。
+8. 按用户要求已将“一次实际出车对应一个车次，多条货物明细，出车记录自动汇总”写入方案基线，见第 4.1 节；人工历史补录、车次中途换车和取消分支的规则在开发合同中细化。
+9. 已将外接应收/实收、本趟直接成本和自有/外接成本分摊分别展示写入方案。尚需确定成交价按托还是按整单、实际数量变化后的改价、币种/税费和结算引用；计算结果由服务端输出，人工更正保留原因。
+10. 根据已确认外接含义，外接报价是面向委托方的销售报价，应关联客户/委托方，不能强制当作供应商采购价。原型“派送车队报价”是否另用于向外部车队采购运力、是否纳入首期仍需明确；若是采购价才关联供应商。两类报价各定适用路线、计价单位、币种、有效期、版本及导入匹配规则。
+11. 司机证照、车辆运维照片、出车图片和签收凭证分别归属哪个文件业务范围、保留多久、谁有下载权限；允许的大小、MIME 类型、预览和下载规则是什么。
+12. 分别定义车辆、司机、运维和出车记录的停用、作废、删除或更正语义及权限。车辆主档当前无删除端点；不能将这一现状推为所有新对象的永久规则，也不能默认创造作废接口。
+13. 跨区域日期、时区和工作日边界如何计算；车辆、排车、派送和统计接口返回的时间采用什么时区。
+14. 平台客户数据隔离和角色范围：车辆、司机、车队、报价及附件是平台级共享，还是按客户/仓库限制可见和可操作范围。
+15. 司机和车辆是否允许多仓、多司机或多车队绑定；绑定是否保留有效期、历史和并发冲突记录。
+16. 当前车牌在车辆表内全局唯一且编辑里程不能回退；是否调整唯一作用域、如何处理换牌/里程录错需要明确决策。新增状态迁移、占用/释放、冲突与更正审计须显式设计，不能无意取消已有约束。
+17. 车队报价 CSV 模板的当前字段格式、单批上限、失败行处理、重复行策略和导入幂等键；不预设旧模板兼容层。
+18. 出车记录原型已包含导出Excel入口，但尚未生成真实文件；需确认正式导出格式、字段、权限、范围上限及统计口径。
+19. 已确认审核首期只展示详情并提供通过/打回，不预设业务检查清单；建议沿原型保留调度/理货两级并记录人员、时间、意见，打回必填原因。拣货/发车的阻断时点、改派后重审和跨单快照同步仍需在接口设计中明确；通过审核不自动代表开始装车。
+20. 已确认：临近 30 天到期但仍有效时允许派车并提醒，预计任务结束前会过期则禁派；必需资料缺失、未审核、已过期禁派。提交/审核/发车的复核时点、预计结束时间缺失处理和临时换司机规则在接口设计中落实。
+21. 已确认外接是利用承运自有货物的车辆剩余运力，顺路承接别人的货；属于货源/承运任务来源维度，不等于外包给其他车队。当前单客户排车规则是实现现状，新需求需要同车关联不同委托方的货物，推荐的行程与客户单据关系见第 4.1 节。
+22. KPI 的“今日”、统计日期、去重仓库数、出车次数、托均价分别采用什么口径；列表/图表是否共用筛选条件。车队报价空值与零价、导入部分成功与整批失败的规则须同时定清。
+
+### 4.1 本轮业务确认与出车方案建议
+
+**已确认**：本模块管理车辆，同时安排自己的货物运输；车辆存在顺路剩余运力时承接外部货物，称为“外接”。一趟车可同时含自有业务货物和外接货物。原型“外配业务”的名称和外包承运暗示需要据此调整，建议用户可见名称改为“外接业务”；车辆归属（自有/外派/租赁）与货源类型分别记录，不从其中一个自动推导另一个。
+
+**已确认**：审核先以详情展示、审核通过、打回为范围，不做未经确认的逐项业务检查表。建议保留原型两级入口，打回时填写原因，修改后重新提交；记录审核人、时间、意见和本次审核版本。司机资格不能因人工点通过就跳过服务端已确认的禁派规则。
+
+**已确认的司机资格规则**：必需资料缺失、未审核、已过期时禁止派车。对于 30 天内到期但尚有效的证照，用户已明确选择“允许并提醒，任务结束前会过期则禁止”。计划预计结束时间用于派车校验，改派或时间变更后重新计算资格；缺少预计结束时间时不能直接判定满足该规则。具体必需资质清单和时间边界在合同中明确，不自动扩大为原型全部证照。
+
+本次按用户“请写入后继续 Review”的要求，将该确认整理为以下判定表。表内“允许”仅表示通过此项证照校验，仍须满足车辆、审核、装载等其他派车条件：
+
+| 证照与任务情况 | 判定 | 依据 |
+| --- | --- | --- |
+| 仍有效、超过 30 天到期，且有效期覆盖预计司机任务结束 | 通过此项证照校验，无临近到期提醒 | 按已确认的 30 天提醒窗口及任务全程有效要求推导 |
+| 仍有效、30 天内到期，且有效期覆盖预计司机任务结束 | 允许，并展示到期提醒 | 用户明确确认 |
+| 当前仍有效，但预计司机任务结束前会过期，无论是否已进入 30 天提醒期 | 禁止派车，需更换合格司机或更新并审核证照 | 用户明确确认；不能只检查“今天是否过期” |
+| 必需资料缺失、未审核或已过期 | 禁止派车 | 前述已确认资格前提 |
+| 未填写预计司机任务结束时间 | 草稿可保存，正式派车前要求补齐 | 第 4.4 节执行建议；不能默认为证照覆盖任务 |
+
+证照有效截止日、时区及恰好触及截止时刻的处理仍按第 4.4 节明确，不以本表推定法定有效时刻。
+
+下面的“一车次、多明细、分别签收、成本汇总”方案已按用户“写入后继续 Review”的要求纳入文档设计基线；表中明确标为首期建议的范围以及第 4.2 节问题仍待确认。方案写入本身不表示功能已实现，也不将未确认的边界自动定案；后续源码进度见第 10 节。
+
+| 对象 | 建议口径 | 主要原因 |
+| --- | --- | --- |
+| 运输行程/车次 | 一次实际出车对应一个稳定业务编号，记录车辆、司机、起终点、计划/实际发车及完成时间；车次计划创建时即可建记录，发车后继续补齐实际事实，同一趟多目的地不拆成多次出车 | 能按真实运行统计，避免一车送多个仓被重复计次数 |
+| 货物明细 | 行程下关联多条自有/外接承运明细；每条有委托方、来源单据、提卸货点、托数、重量、体积和约定费用。自有业务货物也保留原客户归属 | 同车可拼载，客户订单、库存、附件和费用保持各自归属 |
+| 执行单据 | 在现有客户排车/出库/派送单之上建立共享行程关联，现有单据保持客户/仓库边界；行程只统筹物理车辆、路线和发车，不复制客户库存账 | 不直接解除现有单客户校验，也不把所有货假挂在同一个客户下 |
+| 外接履约来源 | 首期建议人工录入外接委托和承运明细、分配到行程；进入本仓的外接货走真实收货/库存流程，异地提货须有独立交接证据，不虚构已入仓事实 | “接单”和“已收货”是不同事件；是否首期支持沿途提货应明确范围 |
+| 剩余运力 | 先检查托位、限重和容积，预留外接货后立即占用；多点提卸按每一段在车货量核算，不能只看整趟总托数 | 防止同一空位重复出售或沿途超载；可用托数不是唯一条件 |
+| 行程完成 | 所有承运明细均送达签收，或异常已按明确终态处理后，结束本次行程；一个目的地签收不完成整车。车辆是否可再次调度还需检查占用、位置和故障状态 | 支持多目的地、拒收/退回；不将付款完成或必须回原仓作为派送完成条件 |
+| 出车记录 | 从行程及各客户执行单据自动汇总；人工只补充实际里程、油耗、凭证及有权限的更正，保留原因和历史 | 避免再建一张自由填写、与实际运输脱节的出车统计表 |
+| 收入 | 外接货的约定运费属于向委托方收取的运输收入，区分报价、确认应收和实收；自有业务订单的原有运费不能在车辆模块重复计收 | 能分析外接贡献，同时防止重复计费 |
+| 成本 | 行程记录实际燃油、司机本趟费用、通行费、停车及其他直接费用；保养、保险等固定费用后续按明确规则分摊，账务仍走 Finance | 先得到可核对的单趟直接成本，避免把未分摊成本的结果叫完整利润 |
+
+价格展示建议替换笼统“价格”为“外接应收、外接实收、本趟直接成本、自有货分摊成本、外接货分摊成本”。同路线、同规格可先按托数分摊直接成本；距离/占位差异较大时另定按占用空间与里程的规则。分摊值用于运营分析，不等于新增客户应付，也不自动生成正式账单。
+
+示例（统一币种、同路线同规格）：一车容量 30 托，自有货 20 托，外接 10 托，外接确认运费 300，本趟直接成本 600。按托数分摊，自有货成本 400、外接成本 200，外接在该分摊口径下贡献 100；不包含固定费用，不能称为整趟净利润。托均收入只用外接收入除外接托数，整趟托均直接成本用本趟直接成本除全部实运托数，两个指标不得混用。
+
+接入影响：当前“一张排车 → 一张出库 → 多目的地派送”仍是客户执行单据的现状；推荐增加的共享行程可能关联多组此类单据。必须另定按车统一发车的校验、失败重试和各客户状态推进协议；不能因新增行程就假定现有接口支持一次多客户出库。“空位放出去”首期建议由运营登记可接运力和外接预订，公开发布、在线接单或撮合平台需另行明确，不自动扩大本轮范围。
+
+### 4.2 本轮 Review 后仍影响开发范围的问题
+
+无需重新确认第 4.1 节已明确的外接含义、简化审核交互和司机临近到期规则。下面的问题按影响排序，建议均未冒充用户确认：
+
+| 问题 | 为什么影响实现 | 建议首期口径 | 影响任务 |
+| --- | --- | --- | --- |
+| 外接货交到我方起运仓，还是需要司机沿途去别处提货？ | 前者可用现有仓库真实收货和 PDA 出库；后者增加路线站点、提货交接、分段容量及未入本仓的履约来源 | 首期先接送到本起运仓的货，多目的地派送；沿途提货另开范围。若沿途提货是核心业务，则在本轮纳入，不能伪造入库绕过 | VM-05、VM-04a、VM-07b |
+| 外接委托方是否已是系统客户，谁付款？ | 单据、库存和应收需要稳定的客户及付款归属；货物原货主、委托运输的人、付款方可能不同 | 外接单选已有客户/委托企业，联系人独立记录；新委托方先按现有客户建档。是否需要工作台账号按实际需要处理，不强制外接人在线下单 | VM-00、VM-05、VM-06 |
+| 两级审核分别在什么作业时点生效？ | “详情 + 通过/打回”的界面已定，但阻止拣货还是阻止发车会影响 PDA | 建议调度通过后允许开始拣货，理货通过且实际拣货核平后允许发车；审核记录与实际作业状态分开。关键货物/车辆/司机变化重审，但不回滚已经发生的拣货事实 | VM-04a、VM-07b |
+| 外接运费按托数还是整单报价？货到后数量变化怎么办？ | 决定报价明细、成交金额、补差价与取消收费；原型单价和总价不能互相覆盖 | 首期支持按托/整单两种计价，保存成交价快照；实收数量与预订不同先重新核量并确认金额，不静默改价或放行超载。等待费/额外提货费等单独登记原因和确认 | VM-05、VM-06 |
+| 外接预订何时占位、撤单后何时释放？ | 未确认询价不能永久占满车辆，已装车货物也不能通过取消按钮从库存中消失 | 询价不占位，确认承运后占位；发车前未执行的撤单释放，已拣/已装走正式撤回或退仓动作；发车后拒收/退回走异常处理。临时留位的超时和取消费另定 | VM-05、VM-04a |
+| 是否首期承接超规格托盘、散货或特殊货物？ | “空 10 托”只对明确规格有效；现有 Admin 车型为大车 30 托/40000 LB、小车 15 托/10000 LB，不代表任意车辆都适用 | 首期建议标准托盘普通货，至少核验托数/规格、重量和体积；实际车辆容量独立维护，超规格/散货另确认计价与占位方式。重量未确认前不能按可用托数直接承诺承运 | VM-01、VM-05、VM-06 |
+
+其他实现细节由合同设计给出具体方案，不把所有技术选择都退回给业务：同一客户执行单及同一批待发运货物不能重复绑定有效行程；不将这一限制扩大为原始客户订单永远不能按现有规则分批履约。行程与各客户执行单据保留稳定关联；整车发车需先校验所有本次发运明细就绪，保证重试不重复扣库存；客户只可见自己的货物、凭证和费用。车辆/司机的调度占用、变更历史与附件读取权限纳入相应后端门禁。
+
+### 4.3 本轮发现的现有接口差距与修订
+
+1. **转派送强制收费与“不重复收费”冲突**：`DeliveryRequests.Transfer.fees` 非空；`DeliveryTransferService.validateTransferFees` 要求存在正数 `DELIVERY_FEE`，地板/混装还要求装车费，购买预约要求预约费；`transferResolved` 会调用 `feeSources.publishApproved`。因此新行程不能无条件逐客户重放这套新增费用流程。建议新增明确的费用来源/覆盖关系，支持引用已确认费用与登记本次新增费用，Finance 为唯一账务事实；具体字段随 API 合同确定，不用零元或虚构费用绕过现有校验。
+2. **一个平台行程不能等同于一张客户排车单**：现有 `DispatchService` 保留单客户、同仓校验，新行程统筹多个客户执行单据。需要验证某客户准备失败时整车不误发、重试不重复执行、取消只影响指定承运明细，不把平台行程 ID 当成客户归属。
+3. **计划数量、实收数量与占用容量需分开**：接单时的预订不等于已到货；按实际装载检查每段托位、重量和体积。外接临时加货或少到货会改变余位和成交金额，不能让页面自行修改原出库事实。
+4. **行程完成、车辆可派、费用结清为三个状态**：货物签收完成不自动代表已收到运费，也不必等待回到原仓才完成运输；车辆释放还需考虑位置、故障和下一任务时间。一次行程中途换车应保留交接/换车历史，不将原记录直接改成另一车牌而丢失追踪。
+
+追加源码核对：转派送原先在同请求键、已转换排车及唯一键竞争三条重放路径直接返回旧结果，修改金额后可能表现为成功但仍沿用旧费用。本轮已在 `ll_outbound_order.request_hash` 保存首次业务请求摘要；仅请求键不同而业务内容一致可以重放，费用、计划时间、装载等内容不同则拒绝，原单据及已发布费用保持原事实。该修复解决请求重放误报，不代表第 1 项的费用覆盖引用已经实现。现有 Lastleg 费用查询按业务单据返回已登记来源，Finance 事件接收接口也不提供“该费用覆盖本票尾程哪些服务”的证明；后续须按实际承运明细、来源版本和明确服务范围设计引用，不能拿同客户任意已收费记录或总运费金额直接判定派送/装车/预约已包含。
+
+本节区分接口差距与追加修复，实际实现范围和验证结果见第 10 节；未注明已实现的方案不能视作完成。第 9 节五轮 Review 是此前版本的记录，本节是随后业务确认后的追加核对。
+
+### 4.4 司机规则写入后的追加 Review
+
+本节记录 2026-10-02 本轮文档 Review。已确认业务规则保持第 4.1 节原意；下列边界是实现建议，不代表现有接口已经具备，也不把法定证照效力作推定。
+
+**司机资格的执行建议：**
+
+- 草稿可先保存缺失信息；正式分配司机、提交审核、审核通过、发车时由服务端重新计算资格。缺少预计任务结束时间时提示补齐，不允许通过正式派车/发车校验。
+- 提醒按证照配置的有效时区和当地日期计算，剩余有效天数为 0～30 天时提醒。证照只有日期时，建议记录其当地有效截止日；截止日当天计划结束是否允许，取决于明确的有效截止时刻，不能由浏览器时区或固定加 24 小时推算。日期边界、夏令时和恰好到期时刻须覆盖测试。
+- “预计任务结束”应覆盖该司机本次实际承担的驾驶任务；若还需返程、转场，不能仅以最后一票货物的预计签收时间代替。行程派送完成与司机任务结束分别记录。
+- 更换司机、替换必需证照或调整预计结束时间时重新校验；证照关键内容修改后建议重新审核。普通联系人信息修正不应无条件推翻整车审核，重审字段由合同列明。
+- 已在途时发现延误将跨过证照有效期，应提醒调度并登记处置/换司机；不得自动撤销已发车事实、回滚库存或将整趟标为已完成。实际交接保留时间、地点、双方司机和凭证。
+
+**本轮优先澄清的业务问题：**
+
+| 问题 | 当前结论与建议 | 不明确会产生的影响 |
+| --- | --- | --- |
+| 外接货从哪里装车？ | 已确认首版送到我方起运仓；沿途提货留待后续版本优化。对应第 4.2 节首项 | 影响真实收货、交接证据、路线站点及 PDA 范围 |
+| “空位放出去”是否需要客户可见的发布入口？ | 已确认首版运营线下找货、后台登记余位和外接订单；客户工作台在线发布/申请留待后续版本，不以后台登记冒充线上接单 | 仅做后台登记不能被描述为已经完成线上发布或接单 |
+| 两级审核卡在哪个节点？ | 已确认详情、通过/打回交互及首版时点：调度通过后开始拣货，实际核平且理货通过后允许发车 | 影响审核详情中的数量来源，以及 PDA 开工/发车门禁 |
+| 哪些司机证照属于必需资料？ | 首版按驾驶证作为基础必需项执行，体检、培训/安全、保险先记录日期，不自动设为必填；这是本轮产品范围，不推定法定资质结论 | 影响缺件、未审核和过期的禁派范围；不能只确认到期算法而遗漏适用证照清单 |
+
+这四项按本轮用户“按建议执行、先做首版”的确认推进。其余仍按第 4.2 节保留明确建议：已有客户/委托方建档、按托或整单成交快照、确认承运后占位、标准托盘普通货。未经确认不写成最终业务事实；这些问题只约束相关工作包，不重复询问外接含义或 30 天到期规则。已确认部分可继续细化和开发，但不能据此判定外接、审核及司机资格的整条流程已经冻结。
+
+### 4.5 本次追加 Review：装载、占用与异常分支
+
+本节是对本文方案的一致性 Review，不代表新增代码或环境验收。第 4.4 节范围问题继续待答；以下给出合同设计建议，避免重复增加业务确认问题。
+
+| 发现的缺口或歧义 | 建议补齐的规则 | 对应任务与验收 |
+| --- | --- | --- |
+| 按客户货物明细直接累加托数，可能把多客户合托计算成多个实物托盘 | 装载以实物托盘和实际占用的标准托位核算；客户货量、收费托数和物理占位分别记录。同一实物托盘的重量、体积只统计一次，客户货物归属保留；不同卸货站点的货物是否允许同托须明确现场拆托方式，首期建议拆成可独立卸货的实物托盘 | VM-05：两客户同托不重复占位、不重复计重；客户费用仍分别核算 |
+| 一票未到齐或被打回时，其他货已就绪，整车如何继续 | 任一当前发运明细未就绪均阻止整车发车。若要剔除该票，先完成有权限的改计划及必要撤拣/退仓，重新核算容量、费用和审核，再统一发车；不能靠忽略失败的客户单局部推进 | VM-04a、VM-05：一票失败全车不误发；剔除已拣货物不丢失库存与作业事实 |
+| “货送完”与“司机任务结束”不同，过早释放会重复派车 | 货物履约结束、车辆释放和司机释放分别判断；司机仍承担返程或转场时继续占用。允许提前建下一车次计划，但正式分配须检查资源占用；换车/换司机保留交接事实 | VM-02、VM-05：全部签收但司机尚在任务中，不能分配重叠任务；不因费用未结清而无限占用 |
+| 文档“一张客户单不能分配两车”的措辞过宽 | 防重复约束落在客户执行单与实际待发运货量上；原订单如按现有业务规则拆成不同批次，不因共享车次设计一律禁止分批。新增拆单能力不在本条自动承诺 | VM-04a、VM-05：重复发同一批货被阻断，合法独立批次不误拦 |
+
+审核被打回后应展示原因并允许修改重提，已经完成的现场动作保留。装载或费用变化后，应分别确认新的装载依据与成交金额，不能用一次“审核通过”同时代表收货完成、货物发车和客户付款。
+
+### 4.6 本次复核：承运承诺、审核范围与部分拒收
+
+本次按“写入后继续 Review”的要求复核第 4.1 节：司机临近到期判定已经写入，继续按用户明确确认执行，不再次征求相同决定。以下三项是补充方案，尚未获得业务确认，不代表现有功能已实现；它们细化第 4.2、4.5 节，不替代其中仍待确认的范围。
+
+| 需要补齐的边界 | 建议处理方式 | 对应任务与验收场景 |
+| --- | --- | --- |
+| 自有货优先是否允许挤掉已经确认的外接货 | 建议自有货在对外确认承运前优先安排；外接一经确认就占用承诺运力。之后自有货增加导致超量，应由调度协商改期、改车或撤单并留存结果，再释放或调整预留，不能自动取消外接或超载发车。外接预留与实际装载关联替换，不能在到货后把同一票重复计算两次 | VM-04b、VM-05：余位已确认给外接后新增自有货，提示容量冲突；外接从预订转实收时占位不翻倍；撤单按是否已拣/已装分别处理 |
+| 审核通过究竟覆盖哪些单据和数据，修改后哪些审核失效 | 建议客户执行单保留各自调度审核，整车理货确认覆盖本次全部发运明细及装载版本；整车发车同时核对两者。增减货物、换车、换司机、改路线或延长任务后使受影响的通过记录失效，并重新检查资格、装载与容量；历史审核和已发生作业事实保留。联系人或纯备注修正不触发无关重审。审核所属对象仍需与第 4.4 节的审核时点一并确认 | VM-04a、VM-05、VM-07b：客户 A 通过不能代替客户 B 通过；旧页面提交旧版本不能批准新装载；改司机后不能沿用旧司机资格结果 |
+| 多点派送中只有部分货物拒收，是否可以直接结束整车 | 建议已经签收的明细保留完成事实，拒收部分记录数量、位置、责任人和后续处置，保持未结案，直到有真实退回签收或经明确流程确认的交接终态。仅填写异常说明或关闭工单不能代替货物交接；需重派的货物另关联后续任务，不能通过改签收数量消除差异。货物结案之后仍分别判断车辆和司机是否结束任务 | VM-05：两站已签收、一站拒收时不能完成整车；部分退回的数量须与实发和已签收数量核平；异常说明保存不自动释放资源、不重复收取原运输费用 |
+
+需要优先获得业务答复的四项已统一列入第 4.4 节：外接货装车地点、余位是否面向客户在线发布、两级审核生效节点、必需资质清单。“30 天提醒”已经确认，不等于驾驶证以外的体检、培训和保险都成为必填门禁。未决项仅约束相关工作包，不能据此宣布全模块已经具备开发或验收条件。
+
+### 4.7 首版确认前的决策依赖记录（已由本轮确认解除待答状态）
+
+2026-10-02 再次按当前路由、交互矩阵、车次发车服务与费用来源接口核对：核心业务及新增交互选择连续多轮仍未收到答复。已确认规则的实现和本地回归保留；不能用继续修局部缺陷或重复跑测试，代替下面的流程决策。当前未满足整模块交付条件。
+
+| 待答入口 | 直接受影响的工作 | 当前证据与边界 |
+| --- | --- | --- |
+| 第 4.4 节：外接货装车地点、余位发布方式 | VM-04b、VM-05 的外接委托、收货/沿途提货、客户申请和占位流程 | 共同起运仓的客户执行单车次已有后端，但不是完整外接接单能力；不能据此排除沿途提货或 Client 发布需求 |
+| 第 4.4 节：两级审核生效时点、必需资质清单 | VM-02、VM-04a 的正式派车、拣货、发车门禁 | 当前资格校验不代表审核节点已实现，也不能默认驾驶证以外所有证照都不需要校验 |
+| Admin `PROTOTYPE_MATRIX.md`：车次页面承载方式 | VM-07b 的计划、分配、关联排车、装载、结案和资源释放入口 | 当前 `routes.ts` 无车次操作路由；新 PDA 发车已要求车次关联，缺少平台入口时不能按可操作闭环发布整个车辆包 |
+| 同一矩阵：维修/故障/救援更新处理入口 | VM-03 的持续处理流程 | 原型只定义新增；服务端可更正记录，但页面仍未开放未经选择的新增行操作 |
+| 第 4.3 节：原运费的服务覆盖与来源引用 | VM-04a、VM-05、VM-06 的不重复计费和费用展示 | 建议每票明确已含哪些服务并关联原费用来源；只对另行确认的新增项目计收。本节记录初始差距；现已接入按实际货物确认原费用覆盖，源码与验证见第10.9节 |
+
+上述答复到齐或逐项明确后，按对应工作包继续实现；未答部分保持待确认，不代填为“通过”或通过旧行为回退发布。部署授权仍有效，不需要再次申请同范围授权；源码、配套 Schema/权限、操作入口和真实 HTTP 必须一起核对，环境状态继续只以两份正式部署/通信契约为准。
+
+## 5. 任务拆分与依赖顺序
+
+VM-00 的交付不是只列问题：对第 4 节每项记录“已确认现行规则 / 本轮采用方案 / 后置 / 待业务确认”、适用工作包及确认依据。司机资格和审核决策约束 VM-02/VM-04a；已确认的自有/外接含义与已写入的行程/金额设计基线约束 VM-04b/VM-05；第 4.2 节未决范围分别跟进；运维字段和附件约束 VM-03；报价匹配和导入约束 VM-06。未获得用户决策的项保留待确认，不由本轮 Review 代为批准。
+
+以下是候选工作包，不是已批准排期。P0 表示本方案的前置工作，P1 表示后续候选实现，Gate 表示交付门禁；具体纳入范围在 VM-00 冻结。各包只同步实际受影响的前端、后端、OpenAPI、权限、SQL、测试与文档，避免重复安排页面工作。
+
+| 编号 | 优先级 | 工作包与主要交付物 | 建议实现归属 | 依赖 |
+| --- | --- | --- | --- | --- |
+| VM-00 | P0 | 冻结范围、术语、单位、状态机、车辆/司机/排车边界、删除策略、文件和权限模型、各事实的服务归属与模块命名；形成确认版字段表和页面清单 | 产品/业务 + 后端/前端共同评审 | 无 |
+| VM-01 | P0 | 车辆主档对齐：确认现有 `ll_vehicle` 字段；按 VM-00 结果决定是否补齐初始里程、停放位置、司机/车队关系、租赁状态、停运原因等主档字段；FBA、发车时间、ETA 和任务快照不得预设写入车辆表；按影响更新 DTO、OpenAPI、SQL、Mapper 和权限，向 VM-07a 交付字段合同；保留 `recordVersion` | Lastleg masterdata + Admin overseas-master-data | VM-00 |
+| VM-02 | P0 | 司机主数据：司机档案、归属/仓库、驾照和资质日期、审核状态、附件、`canDispatch`/阻断原因；列表、详情、新增/编辑、到期提醒和独立权限；接入现有文件上传与附件归属契约，不把 data URL 当持久化方案 | Lastleg 新司机域 + 现有文件能力/IAM + Admin | VM-00；与 VM-01 并行 |
+| VM-03 | P1 | 车辆运营记录：保养、加油、维修、紧急故障、救援费用、异常；记录版本、操作人、附件、里程阈值、核验/处理状态和费用边界；按车辆标识隔离记录，逐类型定义字段及处理/付款状态，向 VM-07a 交付 API | Lastleg 车辆模块（服务归属由 VM-00 确认） + Admin | VM-00、VM-01、附件/文件归属契约；可先做契约阶段 |
+| VM-04a | P0 | 排车执行扩展：两级审核、驳回重提、车/司机关联与资格校验；定义 PDA 门禁、期望版本、审核后改派、转派送快照及取消联动；处理正数派送费必填与费用引用/不重复入账的差距（第 4.3 节）；复用已有命令并补齐缺失契约 | Lastleg dispatch/delivery；Admin/PDA 为直接消费者 | VM-00 相关决策；车/司机联动依赖 VM-01、VM-02 |
+| VM-04b | P1 | 自有/外接工作台：按已确认顺路拼载含义展示货物明细、余位和预订；推荐按共享行程统计次数，自有货成本与外接应收分别展示。按第 4.1 节行程基线补齐数据关系与查询，GPS/自动财务入账按范围决定 | Lastleg dispatch/delivery；Finance 为账务权威 | VM-00 相关决策；依赖 VM-05 的行程合同；若消费审核/资格字段，再依赖 VM-04a |
+| VM-05 | P0 | 行程与出车记录（已写入方案基线）：以一次实际出车为粒度关联多个客户执行单据，区分自有/外接货源；设计分段运力预留、统一发车与重试、各站点签收和异常终态；出车记录自动汇总并提供授权补充/更正与导出，不以统计页替代行程执行模型 | Lastleg 内的行程模块与既有 dispatch/delivery 协作；不预设新微服务 | VM-00 明确第 4.2 节提货/预订/计价范围；车辆关联依赖 VM-01，资格与审核依赖 VM-02/VM-04a 对应合同 |
+| VM-06 | P1 | 报价：先区分外接销售报价与原型车队采购报价，按确认范围实现；外接关联委托方，采购关联供应商；明确路线、计价单位、币种、生效版本、启停、重复约束及 CSV 导入导出。外接承运明细保留成交价快照，报价后续修改不覆盖已确认成交金额 | Lastleg 业务报价 + 客户/供应商目录，Finance 为账务权威 | VM-00 确认报价用途；不以采购报价完成作为人工外接接单前置条件 |
+| VM-07a | P1 | 现有车辆主档页面收口：按正式字段/状态更新 `VehiclesView.vue`、`VehicleDetailView.vue`、表单和 `routes.ts` 描述；清理“派送订单/更换记录已具备”的陈旧文案；运维/异常页签仅在 VM-03 契约就绪后开放；把排车列表继续指向现有正式排车路由 | Admin overseas-master-data | VM-00、VM-01；开放运维页签时再依赖 VM-03 |
+| VM-07b | P1 | 新页面正式接入：更新 `adminNavigation.ts`、模块 routes、权限守卫、排车审核/司机/业务/出车/报价页面与弹窗，补齐加载/空态/错误态/无权限态；不复制排车页面 | Admin 前端 | VM-00 相关决策；分别依赖 VM-02、VM-04a/VM-04b、VM-05、VM-06 对应合同 |
+| VM-08 | Gate | 质量与验收收口：前端定向测试、后端 Controller/Application/SQL/OpenAPI/IAM 合同、Gateway 路由合同；1920×1080/100% 页面人工验收证据；字段、状态、权限、附件和异常场景回归 | 前后端共同 | 各工作包完成后 |
+
+### 5.1 建议的并行边界
+
+VM-01～VM-06 负责业务合同与服务端实现，页面由 VM-07a/VM-07b 对应承接；表内提及页面是验收范围，不重复建立两份前端任务。
+
+- 后端可以将 VM-02（司机）与 VM-06（车队报价）并行；两者分别定义司机资格和已确认用途的报价，不共享未确认的自由文本字段。
+- VM-03 的记录模型可以先做契约和表设计，但在 VM-01 未冻结车辆主档主键、单位和附件边界前，不应开始页面联调。
+- VM-04a 与 VM-04b 分别估算和验收；工作台只读部分不等待整套审核完成。PDA 若因新审核/资格门禁调整，应沿既有排车执行接口及应用指引修改，作为 VM-04a 直接消费端验证。
+- VM-07a 可在现有车辆主档合同确认后先行收口；VM-07b 按各自 API、权限和错误码就绪情况并行接入。原型页面不能直接复制到 `src/prototype/` 作为正式功能。
+
+## 6. 验收清单
+
+以下是未来实现的验收要求，本次文档 Review 不表示这些功能或测试已经完成。只对本轮实际纳入的工作包执行对应验收。
+
+### 6.1 合同和权限
+
+- 车辆主档的列表、详情、创建、编辑、状态、导出路径与统一 Gateway、Controller、OpenAPI、权限逐项一致。
+- 车辆、司机、运维记录、出车、车队报价分别定义权限资源；每类列表权限包含详情只读，写入与已纳入的导出权限独立，由服务端鉴权。
+- 浏览器长整型 ID 按字符串透传；车辆主档沿用 `recordVersion`。新增审核/改派命令明确期望版本、幂等和错误码；现有排车编辑缺少客户端版本校验，若本轮涉及该命令则同步补合同与受影响调用，不能把这一缺口写成已完成。
+- 页面只开放有正式合同的动作；HTTP DELETE 不等于物理删除，取消、作废、停用、更正各按对象生命周期校验并保留对应审计。
+
+### 6.2 页面和业务
+
+- 车辆列表支持归属、区域、关键词和状态查询，操作列固定在第一列；空态、加载失败、无权限和导出失败可恢复。
+- 排车详情/编辑复用现有路由；新增审核必须验收提交、逐级通过、驳回重提、修改后重审及 PDA 门禁。各客户执行单据的单客户同仓限制、收货后转派送和发车前置条件均由服务端校验；平台行程可关联多客户单据，不能把子单限制直接套在行程上。
+- 车辆详情只展示服务端真实返回的主数据；派送订单、更换历史、运维记录和异常页签只有在对应接口存在时开放。
+- 路由标题、描述和页面实际数据范围一致；未提供派送履约/更换历史时不得用路由描述暗示已具备。
+- 司机过期、待补件、待审核和不可派状态由服务端资格结果驱动；到期提醒不能只由浏览器当前日期计算。
+- 自有/外接业务按顺路拼载口径取数；一车多个客户/目的地不重复统计出车次数。外接报价、应收、实收和车辆成本分别记录，自有业务原有收费不重复计收。按行程方案验证各客户单据与库存隔离、每段容量占用、重复预订/取消和统一发车重试。
+- 出车记录的用时、托均价、油耗和图表总计使用统一单位和服务端统计口径；筛选条件由服务端参与分页和统计。
+- 车队报价导入能展示逐行校验结果、重复组合和失败原因；导入具备幂等或明确的重复处理规则。
+- 报价区分未报价与零价；导入按确认策略检验部分成功/整批失败及重试重复行。统计验证筛选范围、仓库数与出车次数、加权托均价、零托数和多币种分组，页面数值和导出一致。
+- 司机列表/详情的到期提醒与实际命令阻断一致；审核后变更车辆或司机、临近到期、已过期、缺件、未审核分别验证，不能仅验收提示文案。
+- 司机资格补验到期前第 30/31 天、到期当天/次日、计划结束恰好触及有效截止时刻、跨时区/夏令时、缺少预计结束时间及预计结束延后；所用预计结束覆盖司机承担的返程/转场。已在途发生风险只进入告警与处置，不回滚出库事实。
+- 运维记录须验证车辆 A 的新增/编辑不影响车辆 B；维修项目/地点、救援项目/地点等已确认字段保存后能正确回显；处理状态和付款状态分别读写，不以共用弹窗导致字段丢失。
+- 签收上传与资料保存分别验证：上传未保存不得完成派送；多目的地仅完成当前单，出车汇总按确认规则结案。原型装车完成时间与发车时间混写不得直接作为正式用时口径。
+- 保留现有车牌规范化/唯一性、里程不可回退、主档版本冲突规则；新增占用及资格门禁后分别覆盖维修/停用车辆、过期司机、重复派车、审核后改派及取消。尚未确认的新状态不以页面标签代替正式迁移。
+- 费用验收覆盖已收费自有业务、外接新增运费、混装/预约附加费、同车多客户及失败重试；每个真实收费来源只入账一次，不以 0 元占位或额外虚构一笔派送费通过校验。行程分摊只是运营分析，不重复发布客户账务费用。
+- 预订数量与实收数量变化须重新核量和确认金额；已拣/已发运不能通过简单取消释放为未发生业务。拒收、退回、中途换车应保留关联与证据，分别核对行程结束、车辆释放和费用结清。
+
+### 6.3 工程与人工证据
+
+- 前端运行受影响模块定向测试和类型检查；后端运行车辆/司机/运维/报价相关单元与合同测试；跨服务接口变化补跑 Gateway 路由合同。
+- Admin 视觉按 1920×1080、浏览器缩放 100% 检查，至少覆盖列表、详情、弹窗、附件、空态和错误态截图。
+- 真实 HTTP、部署、数据库写入和 Jenkins 不在本规划文档中默认执行；需在对应环境获得明确授权后单独验收。
+
+## 7. 当前不纳入本轮的实现承诺
+
+- 不把外部 `新版.html` 复制进正式 Admin 页面，也不把原型内存数据、data URL 附件或 Toast 成功提示当作实现证据。
+- 不为兼容旧原型同时保留第二套车辆接口、旧字段别名、双写或独立海外 Gateway。
+- 不在未确认 GPS 数据源、路线告警规则和财务归属前实现自动轨迹告警、自动 ETA 或费用结算。
+- 不把司机、保养、加油、出车和车队报价数据塞进 `ll_vehicle` 作为临时扩展；每类事实先确定权威归属和生命周期。
+- 不通过车辆主档页面推进排车、PDA 拣货、发车、派送完成或码头提柜状态。
+
+## 8. 现状证据入口
+
+- Admin 现有车辆实现：`apps/admin-web/src/modules/overseas-master-data/`。
+- Admin 现有原型核对：`apps/admin-web/src/modules/overseas-master-data/PROTOTYPE_MATRIX.md`、`CONTRACT_GAPS.md`。
+- Admin 当前导航：`apps/admin-web/src/core/navigation/adminNavigation.ts`。
+- Lastleg 车辆 Controller、应用层和持久化：`baiyue-firstleg/lastleg-service/src/main/java/com/baiyue/lastleg/masterdata/vehicle/`；详情排除说明见 `adapter/in/web/PlatformVehicleController.java:49-53`。
+- Lastleg OpenAPI：`baiyue-firstleg/lastleg-service/src/main/resources/openapi/overseas-master-data-v1.yaml`；车辆详情排除说明见 `:158-160`。
+- Lastleg 车辆表：`baiyue-firstleg/lastleg-service/src/main/resources/db/lastleg.sql` 中的 `ll_vehicle`。
+- 车辆权限：`baiyue-firstleg/iam/src/main/resources/db/lastleg-permissions.sql`。
+- 文件能力参考：`baiyue-firstleg/file/`（具体业务类型、大小/MIME 和权限仍需在 VM-00 冻结）。
+- 现有排车/派送：`apps/admin-web/src/modules/overseas-warehouse/`、`baiyue-firstleg/lastleg-service/src/main/java/com/baiyue/lastleg/dispatch/` 和 `delivery/`。
+- 海外仓业务页面 ID 与路由索引：`docs/海外仓业务/README.md`（其中架构入口描述以当前统一 Gateway/Auth 正式契约为准）。
+
+## 9. 本次连续 Review 记录
+
+以下轮次从用户要求连续复核后重新计数，每轮在上一轮修订结果上继续；修复对象为本规划文档，原型和业务代码缺陷仅作为事实记录与候选任务。
+
+| 轮次 | 核对范围 | 发现及文档修复 | 复查证据 |
+| --- | --- | --- | --- |
+| 第 1 轮 | 原型页面、可达按钮、记录读写 | 更换历史无容器；运维扩展未按车隔离；维修/救援表单与保存字段错配；处理/付款状态混用；隐藏面板不能算可操作功能。已修订第 2 节及对应范围判断 | 原型 `9024-9051`、`23196-23202`、`23240-23277`；精确搜索历史容器仅命中函数引用，扩展记录读写无车辆键 |
+| 第 2 轮 | 服务端流程、状态与并发边界 | 补齐车牌规范化/全表唯一、里程不可回退；明确五种主档状态不等于原型三状态；纠正“所有编辑已有版本校验”，记录排车编辑缺期望版本；补转派送后快照变更/取消联动决策。已同步第 3、4、6 节 | `VehicleApplicationService.create/update/changeStatus`、`presentation.ts`、`DispatchRequests.Update`、`DispatchService.update/removeItem/cancel`、`DeliveryTransferService.transferResolved`；逐项核对方法体后记录现状，未声称新增约束已实现 |
+| 第 3 轮 | 决策、任务依赖与验收对应 | 拆分 VM-04a 执行扩展和 VM-04b 查询工作台，取消出车统计对整套新审核的无条件依赖；明确 VM-07a/VM-07b 承担 Admin 页面，PDA 门禁变化归 VM-04a；新增逐车运维隔离/字段回显验收；VM-00 按工作包交付决策结果，未决问题不阻断无关部分 | 复查全部 VM 编号引用均有定义，前端与服务端分工可对应；第 1/2 轮发现已落到任务或验收；因仍发现实质依赖问题，扩展为 5 轮 |
+| 第 4 轮 | 指标、报价与证据措辞交叉核对 | 修正“今日”标签与实际取数、仓库数与出车次数混用；补托均价、空报价/零报价、导入部分成功口径；将测试文件存在与测试通过明确区分。已补原型差异、决策 22 和验收 | `renderVehicleBusiness`、`renderVehicleTripCharts`、`validateDeliveryFleetQuoteDraft`、`confirmDeliveryFleetQuoteImport`；定向枚举测试源码，仅记录入口不报告运行通过 |
+| 第 5 轮 | 全文一致性与交付审计 | 将原型统计说明移回原型章节，修正审查记录中未拆分的旧任务简称；逐项核对前四轮修订、命名页面/弹窗、决策编号、任务引用和证据路径。未发现新的阻断性文档问题 | 第 1 节原型哈希复核；页面/弹窗 ID 与原型定义对应；任务定义、依赖与引用检查；第 8 节证据入口存在；Markdown 表列和章节检查。本次不运行功能测试，不宣称原型缺陷或业务功能已修复 |
+
+## 10. 开发增量与后续接入（2026-10-02）
+
+### 独立任务拆分与交接（2026-10-03，已确认四任务协作）
+
+用户已确认创建三个用户可见独立任务，加当前对话共四个一起处理，目标为车辆全流程跑通。三个专项为①车辆成本与财务闭环；②车辆报价与运营统计；③车辆在途异常与改派；当前对话负责车辆总控、集成部署与跨模块验收。稳定task_id及授权边界唯一维护在[测试环境独立任务协作登记](../独立任务协作登记.md)的“车辆管理四任务协作”段。其他旧任务仍不自动恢复。
+
+| 独立任务 | 唯一实现范围 | 交接边界 |
+| --- | --- | --- |
+| 车辆成本与财务闭环 | Lastleg `fleet/trip/FleetTripCost*`、`PlatformFleetTripCostController`及直接测试/合同；后续Finance车辆成本领域与Admin独立成本组件/API | 接续当前未提交草稿：成本登记、更正、按币种汇总、DEPART实物依据及同路线托位分摊。源码test-compile及新增持久化/现有分摊政策定向测试通过；尚需API权限/合同门禁、前端、部署及真实HTTP。未执行SQL、部署或真实成本HTTP。维修救援按公司成本还是客户分摊的问题仍待用户答复，不能擅自把车辆自身费用挂给客户。Finance共享账单/结算入口修改须先列明路径交总控协调 |
+| 车辆报价与运营统计 | 新的Lastleg `fleet/quote/`、`fleet/reporting/`及各自测试/合同；Admin独立报价/出车运营页面、组件/API | 报价区分外接销售与车队采购；统计基于实际车次、发运及原费用来源，一趟多目的地只计一次出车。成本通过上一任务正式契约读取，不复制成本表或估算成财务实付。不得改写车次执行命令 |
+| 车辆在途异常与改派 | Lastleg车次执行/改派/结案、实际调用到的dispatch和资源边界；Admin异常操作组件及海外PDA直接操作页面 | 保留原客户单据、库存、费用和历史；涉及共享FleetTrip模型或PDA入口时先申报精确文件，独占写入后实施；不以发车前换车冒充在途交接完成 |
+
+总控保留共享 `TripDetailView.vue`、路由、导航、权限定义、IAM权限种子、模块/统一SQL和主契约的集成写权限；独立任务提供明确的接入清单，不同时修改这些文件。Maven构建、Jenkins、数据库结构准备及共享真实HTTP/浏览器验收窗口由总控串行安排；工作在当前目录和当前分支，不创建worktree，不提交他人的未完成改动。当前成本草稿涉及的5份SQL/数据库说明文件亦暂由总控持有，不随成本实现自动转交。
+
+成本交接追加：Admin `api/tripCosts.ts`、`components/TripCostPanel.vue`及直接测试已接草稿，`TripDetailView.vue`按页签懒加载，`permissions.ts`增加两项成本写权限；680px登记/更正和1080px历史弹框，编辑先取最新版本，不变内容不写入，未知创建响应保留原幂等键重试。金额与分摊按币种分别显示，未登记/未分摊不补零。模块103项测试通过；未将本地草稿视为已部署或真实页面验收完成。
+
+本节仅记录本功能源码与本地检查，不维护环境部署状态。环境部署、已验证场景和未关闭验收项仍以根指引指定的两份主契约为唯一入口。整体开发目标保持第 5、6 节全范围，以下局部成果不能作为完成依据。
+
+| 工作包 | 当前源码与验证证据 | 尚需完成 |
+| --- | --- | --- |
+| VM-01 车辆容量与占用约束 | `ll_vehicle` 和既有车辆API、列表/详情/编辑/CSV补齐托位、载重kg、容积m³。三项同填或全空；未知容量不能分配到车次。CSV使用车牌作为业务标识。车辆应用层通过 `VehicleAssignmentGuard` 在车辆行锁内检查占用，车次占用时禁止直接改车牌/车型/区域/归属/容量及状态，备注、电话、合法里程修正保留现有能力 | 实际运维故障、中途换车及车辆释放与签收的联动继续接入；车辆页面真实环境视觉验收待执行 |
+| VM-02 司机后端基础 | Lastleg `fleet/driver/` 新增司机与不可变历史表、列表/详情、创建/编辑、启停、审核、打回重提、驾驶证上传/读取、资格预览；写入使用行锁与版本条件，关键身份/证照变化和替换附件重新待审。OpenAPI `fleet-drivers-v1.yaml`；IAM 六项独立权限；模块与统一 SQL 同步。补齐可驾驶车型、语言/服务区域、体检/培训/保险日期；所属仓库引用国内公共有效目录并保存编码/名称快照 | 其他资质是否必需不由原型自动推定；派车命令源码已接入（见 VM-04a），真实环境验收未完成。当前启停与证照审核状态不冒充行程“任务中”状态 |
+| 司机文件 | File 新增 `FLEET_DRIVER_LICENSE`，固定平台 0 与司机复合归属，非空 PDF/JPG/PNG、最大 10MiB、MIME/签名验证；Lastleg仅允许当前或历史已关联附件读取；上传不会通过审核。Admin 居中弹框预览图片/PDF，关闭释放Blob并忽略迟到响应 | 文件服务真实 HTTP、权限负向及1920×1080视觉验收未完成 |
+| VM-03 / VM-07a 车辆运维 | Lastleg `fleet/maintenance/` 提供保养、加油、维修、故障、救援、异常逐车分页、创建、更正和历史；两表为 `ll_fleet_vehicle_record` / `ll_fleet_vehicle_record_history`，接口 `fleet-vehicle-records-v1.yaml`。Admin按原型接入六类记录，保养/加油680px、其他四类620px居中表单；保养加油图片按原型在新标签页查看 | 维修/故障/救援的更新处理行操作已开放，异常编辑已接入。`VehicleCareModels.Incident.reportedCost`只保存申报金额；`VehicleCareService.response`对维修/救援固定返回`UNLINKED`，构造依赖及Controller没有财务关联命令，不能把记录保存或处理完成解释为已入账/付款。财务关联须补真实费用来源和Finance状态读取；删除/作废语义仍未定。环境证据见正式主契约 |
+| 司机 Admin 页面/API | `DriversView.vue`、`DriverDetailView.vue`、编辑与预览弹框已接真实 API，注册导航和路由；统一 HTTP、长整型 ID 字符串、版本透传、multipart、业务错误追踪。列表一次请求包含分页和同筛选统计；后台按各证照时区分组，在只读重复读事务中取数；详情历史按需加载。修改预计结束时间或档案后提示重新校验，不伪造资格结论 | 真实页面请求量、样式/交互、部署验收未完成；客户端与PDA仍随车次/承运流程接入 |
+| VM-04a 派车门禁 | 车次分配/改派与PDA整车发车均调用 `DriverService.requireDispatchable`，在事务内锁司机并复核资格与真实证照文件；延长任务时间同样重新校验。PDA返回整车门禁与30天到期提醒，预计结束前过期阻断 | 本地事务测试已覆盖发车资格，真实HTTP未验收；审核时点已按本轮首版确认落地，见调度/理货审核增量 |
+| VM-05 车次计划与占用 | `fleet/trip/` 新增幂等创建、分页/详情、改计划、车/司机分配与改派、取消、历史接口；OpenAPI `fleet-trips-v1.yaml`，表 `ll_fleet_trip` / `ll_fleet_resource_assignment` / `ll_fleet_trip_history`。创建可先不分配资源；分配锁车辆和司机，唯一资源键防重复占用，失败回滚，取消释放锁行且保留历史 | 客户排车、整车发车和结案接入见下列增量；外接承运明细、正式页面、异常处置及费用闭环继续实施，创建计划不等于已出车 |
+| VM-05 客户排车关联 | 新表 `ll_fleet_trip_dispatch` 以排车单为唯一有效关联；同起运仓可关联多个客户，客户归属取原单。新增带车次版本的关联/解除接口；`FleetDispatchGateway` 由dispatch适配器实现，同事务同步排车与尚未执行派送单的车/司机快照，不覆盖到达时间。关联后子排车禁止独立编辑/移托/取消，转派送禁止另填不同车辆司机；已拣货禁止直接解除或变更路线，发车前允许统一换车/司机或保持路线调整时间，保留全部拣货事实并清除旧装载确认。替换车辆检查已确认载荷，司机重新核验预计任务覆盖，失败整批回滚；取消车次前先解除关联。历史同时保存车次与关联清单 | 关联箱数不冒充实物托位；已拣货后的撤回、在途换车换司机及交接异常仍需补齐，发车前改派不等于完成全部异常处置 |
+| VM-05 实际装载与整车发车 | `FleetTripExecutionService` 新增装载依据读取/确认，按实物托盘去重计量并调用分段容量政策；同托不同目的地要求先拆托，卸货站匹配来源目的键，确认记录来源hash、车次版本、实测值、人员和历史。PDA原发车入口提交车次版本，锁车次/资源及全部客户执行单；事务内逐单执行出库后统一变为IN_TRANSIT，失败整批回滚、同键重放整车结果。PDA显示车次、单数、到期提醒，发车后刷新真实状态 | 当前覆盖共同起运仓、已关联客户执行单；外接询价及预订占位已接入，来货/实际发运关联已接入源码；审核和Admin车次及装载页面已接入源码，结案/释放见下一行。H2使用真实排车/出库Mapper与事务，订单归属服务在此集成测试中隔离，实库及真实库存/费用闭环仍须HTTP验证 |
+| VM-05 货物结案与资源任务结束 | `FleetTripCompletionService` 读取每票派送的签收或真实退回终态，核对数量覆盖本次实发，并冻结结案依据；退回时间读取RETURN_COMPLETED操作事实，不取可变updatedAt。车次COMPLETED只代表货物结案，车辆/司机继续分别占用；带幂等键、版本和实际结束时间/地点的独立命令释放指定资源，车辆同时确认在役/维修/停用/已归还状态。历史失败回滚资源释放及车辆状态，原请求重放不影响下一车次 | 不自动结清运费，也不重写派送/库存。当前处理正常签收及已完成退回；途中换车、货物部分撤回等异常流程继续补足，真实环境未验收 |
+| Admin车次页面/API | `tripTypes.ts`、`api/trips.ts` 接入28个查询/写命令及独立权限；`TripsView.vue`、`TripDetailView.vue` 注册列表/详情路由，1080px `TripPlanDialog` 维护计划；`TripAssignmentPanel`、`TripLoadingPanel` 在详情分区维护资源与实测装载，货物结案、车辆/司机结束任务分别确认。列表一次分页请求，历史/装载/结案检查按需加载；未填写的说明使用标准动作说明 | 已按本轮确认接入首版，车次管理导航由总控集成；调度/理货审核、外接询价和占位已接入详情，外接来货/发运关联已接入，费用覆盖及环境验收仍须完成。真实环境操作与1920×1080视觉验收未完成 |
+| VM-05 装载与成本政策 | `fleet/domain/TripCapacityPolicy`提供分段容量；新增未发布`FleetTripCostService`已调用`TripCostAllocationPolicy`，按不可变DEPART的实测标准托位及外接实收归属分摊。支持燃油、司机、通行、停车和其他直接成本，CNY/USD分别汇总；成本及当时整趟分摊保存历史，零金额与未登记区分，未发车/不同卸货站/归属未核平明确不自动分摊。Java持久化、并发幂等、回滚、权限和合同共13项通过，网关5项、初始化11项通过 | 当前是后端草稿，Admin成本工作台、完整发布门禁、结构准备、真实HTTP及页面验证尚未完成。运营登记不等于Finance入账或已付，不据此算完整利润。多路线分摊、成本统计及财务关联仍需完成；维修救援自身费用归属等待用户选择。环境事实继续见正式主契约 |
+| VM-07a 车辆详情履约关联 | `VehicleDetailView.vue`已接`VehicleFulfillmentTable.vue`的派送与更换记录；Lastleg `VehicleFulfillmentService`/`VehicleFulfillmentMapper`提供车辆范围的分页查询。计划派送归当前车辆，实际发车后归DEPART快照车辆；换车按相邻ASSIGN快照保留原/新车辆、司机和当时排车成员，不按车牌猜归属。派送关联同时核对客户和排车身份 | 源码接通不代表部署或视觉验收完成；真实环境结论见两份正式主契约。没有车次关联的旧单不补猜历史；操作人姓名未写入现有快照时显示“—”，不把内部ID作为姓名展示。当前只读投影不等于完成在途换车命令 |
+
+结案追加边界：原派送已签收后另发起退货，原运输按已有签收事实结案，不把后续退货改写为已完成，也不让原车辆因未及时点结案而被再次挂起；未签收的拒收/退回仍须实际退回完成证据。派送资料首次保存RECEIPT前新增关联出库单OUTBOUNDED校验，未出库时可以准备BOL/装车资料，但不能提前触发签收完成。已有LocalDateTime执行事实按服务端作业时区转换为车次Instant，避免直接当UTC导致完成时间偏移；车次自身存储继续使用UTC。
+
+当前车次资源采用一个车辆/司机同时占用一个未释放车次的规则；其他未来计划可以先建立而不分配资源，不以预计时间已过自动释放仍未结束的任务。已实现计划、分配、客户排车关联、装载确认、整车发车、货物结案及分别结束资源任务；已装货后的取消、途中换车和其他异常处置仍须补足，不能用计划取消接口代替退仓或签收。
+
+载重数据追加修正：`DispatchCandidateMapper` 不再用计费材积重填补毛重，来源不齐全时分摊毛重为空；该值属于计划分摊，实际装载仍须核验。`DispatchService`、出库托盘与出库/派送合计保留未知毛重，任一来源未知不展示部分重量合计。Admin 预排与排车详情显示待确认/空值，不把材积重或缺失值0当作载重。模块和统一SQL相应重量列已改为可空；尚未执行环境SQL。
+
+司机区域复核修正：正式分配原本只接受海外司机，但分配后可以通过司机档案编辑把区域改为国内，原发车门禁只核验证照与姓名。现已在 PDA 发车预览和事务内正式发车共用区域/身份判断；档案变为国内后整车阻断，出库、车次版本及发车流水不推进，纠正档案后可用原失败请求继续。此规则复用已有海外车次范围，不把自由文本“可驾驶车型”自动解释为正式准驾车型匹配规则；车型匹配标准仍需单独明确。
+
+共享派送服务回归修正：Lastleg 全量首次暴露 `ReturnOutboundPdaPersistenceTest` 四项失败，核对发现已有 PDA 契约要求逐退货箱扫码，但服务仍合并全部箱唛且忽略扫码载荷。现改为每个真实退货箱一条明细，详情返回箱码扫码行且不虚构托盘/仓位；扫码与重放严格核对指定箱码，执行前重新核对客户、仓库、来源退货单，日志写入失败时库存和任务同事务回滚。这是退货库存再次出库的既有链路修复，不等同于车辆拒收后退回入仓流程。
+
+本次已运行的本地检查（按增量保留；同一门禁以最后一次明确结果为准）：
+
+- Lastleg 9 个定向测试类累计 45 项通过：三项领域政策、司机服务、文件元数据归属、数据库事务/并发/跨时区统计分页、API/SQL 契约、真实方法权限拦截、公共仓库目录。最近一轮司机相关 7 类 33 项通过；未变化的两项车次政策复用此前结果。
+- File 3 个定向测试类共 27 项通过：新增证照格式与归属，以及现有业务文件存储/服务回归。
+- 数据库行为测试使用 H2 与当前建表定义；仅将 JSON 列替换为 H2 可读的文本用于本地绑定验证，不等于 MySQL 实库验证。已验证历史失败回滚、清空可选字段、同版本并发只有一次成功。
+- Admin 新增 API 6 项、司机交互 9 项通过；覆盖分页/筛选每次单请求、历史按需读取、只读权限、审核版本、上传失败后重试不重复建档、预览释放以及预计时间变化后清除旧资格展示。`pnpm build --logLevel warn`（含类型检查）通过；全量 `pnpm test` 268 个测试文件、2160 项通过。自动测试不替代真实服务或视觉验收。
+- 车辆/车次增量：车次持久化9项、API/SQL2项、权限1项，车辆应用5项、SQL1项、Controller权限1项通过。覆盖重复/并发创建、车辆并发抢占、缺容量/缺证照、改派失败保持旧安排、延期跨证照到期、历史失败全事务回滚、取消释放与车辆主档占用门禁。
+- 客户排车关联增量：车次持久化扩展为15项，使用真实H2/MyBatis及事务代理验证跨客户关联、同仓限制、并发一单抢占、历史失败回滚、派送快照同步与清空、已开工改派整批回滚。连同API/权限、排车、PDA、转派送、SQL中文注释及OpenAPI回归共106项通过。Gateway与初始化合同14项通过，Mapper扫描313个通过；fleet/车辆定向依赖3项通过，完整依赖检查及AGENTS登记旧断言仍未通过。未执行环境SQL或部署，此结果不能证明MySQL并发或真实HTTP行为。
+- 实际装载/整车发车增量：车次持久化扩展为21项，覆盖两客户同托只计一次、重复/缺失测量与超重、目的站不符、装载后来源改变、某票未就绪、第二票失败全事务回滚、发车时证照复核、跨仓/旧版本、并发同键仅一次执行；连同子单PDA、转派送、订单归属及API/权限/SQL定向回归共118项通过。海外PDA全量167项通过；H5与App资源编译通过（不是APK真机验收）。车次验收助手及两个主消费模块、脚本文档合同67项通过；新助手通过正式API创建测试车辆/司机/证照/车次，实测数据明确标为受控测试输入，不用SQL补状态；这些脚本尚未运行真实HTTP。PDA列表门禁按车次复用查询，仍须在真实环境检查请求量与耗时。
+- 结案/资源释放与Admin接口增量：车次持久化扩展为27项，连同结案API/权限、车辆状态、派送资料/Controller/合同及SQL中文注释回归共58项通过；覆盖货物结案不释放资源、任务分别结束、维修状态与释放一起回滚、司机过期仍能结束旧任务、旧重放不释放新占用、退回须有真实终态操作证据、签收后新退货不重开原运输、未出库拒绝签收但允许准备BOL。Admin车次API新增6项通过；全量271文件2172项通过，类型检查及构建通过。Gateway与初始化基线14项、fleet/车辆依赖3项、313个Mapper扫描通过；全局门禁未关闭项仍按下文保留。本轮未运行共享环境SQL、部署或真实HTTP。
+- 载重修正补跑候选SQL、预排/排车服务、转派送、出库/派送SQL及前端实际重量/排车详情检查；SQL计算回归覆盖完全未知、部分未知及完整毛重来源。当前前端全量 `pnpm test --maxWorkers 4` 为269文件、2163项通过；先前默认并发全量出现财务页面单例5秒超时，该单例独立复验通过，随后以4个worker全量通过，未修改超时阈值或财务代码。
+- Gateway 路由合同 5 项、Mapper 扫描合同、统一 SQL 初始化基线 9 项及 fleet 切片定向依赖检查通过。司机 API 复用统一 Gateway 的现有 Lastleg 路由，无新增网关配置。
+- 完整 Lastleg 依赖检查已修复并通过 10 项：退役 `LastlegSecurity*` 投影改为禁止恢复或引用；25 条现有跨域类引用逐条记录理由，不授权同切片其他消费者。`DeliveryDocumentSnapshot` 移到应用服务包，消除 DTO/model 包循环；新增依赖、通配放行、车辆应用层反向引用和新增包循环均有失败测试。钱包 Outbox 的粗粒度切片聚合环仍作为耦合报告保留，不声称切片全图无环；边界说明见 Lastleg 内部模块化基线。快照工具移动后的派送服务、资料、Controller 与长 ID 回归 66 项通过。
+- 车次 HTTP 验收脚本补齐结案和独立资源释放：通过正式分配命令验证结案仍占用、单独结束车辆不释放司机、资源再分配后重放旧结束命令不清除新占用。无货核对计划最终正式取消并保留历史；失败保留原请求和资源，不自动重造。两处测试车辆创建已补必填 `status=IN_SERVICE`，避免仅凭宽松模拟响应误报可运行。助手及两个直接消费模块 70 项、Gateway 5 项通过，脚本文档 4 项与三个脚本语法检查通过；仍未执行真实 HTTP。
+- 车次 HTTP 验收助手追加发车前改派：仅对 `prepareFleetTrip` 本轮创建的车次执行，首次确认装载后新建等容量车辆和合格替班司机，正式改派并回查货物/客户关联、拣货数量、路线及到达时间保持一致，旧装载失效、旧版本请求拒绝且无写入，再确认新装载并返回最终发车版本。原请求、前后快照和替换资源保存在报告 `reassignment` 中；未知结果保留 `CHECKING`，不自动重试。字符串版本按整数比较，覆盖 9→10 边界。留存车次仅按原入口确认装载，不补造或改派其资源。助手 18 项、两个直接消费者及脚本文档合计 85 项离线通过；这不是已执行的真实 HTTP 或页面验收。
+- 脚本文档合同 4 项通过；本次指引更新后的 AGENTS 索引合同失败，5 项均涉及测试独立任务登记必须为空的旧断言。本功能未修改或清空任务登记，也未据此自动派工；该全局检查仍未通过，不计作司机索引已完成整体验收。
+- 发车前改派完整回归：`mvn -pl lastleg-service -am test -q` 成功，Lastleg 报告 1081 项，1079 项通过、2 项跳过、0 失败/错误；跳过的是 `CargoDiscardMysqlAcceptanceTest` 和 `TaillegRealConsumerAcceptanceTest`，不能计作真实环境验证。车次事务测试现为 33 项，新增发车前已拣货改派、同路线延期、容量不足/证照覆盖不足拒绝、历史失败回滚，以及改派与发车并发只能一个成功；验证拣货、到达时间、客户归属保留，旧装载确认失效并可重新确认后发车。Lastleg 依赖 10 项、Gateway 路由 5 项通过；AGENTS 索引仍有前述 5 项登记旧断言失败。本轮未改海外 PDA，不将先前其 21 项定向结果描述为本轮回归；未部署车辆功能，未执行测试环境 SQL、真实 HTTP 或浏览器验收。
+
+- Admin 编辑会话修复：司机与车辆运维编辑器按打开状态和业务对象隔离请求；切换司机/车辆、关闭或卸载后，旧保存/上传结果不得覆盖新表单、触发成功提示或继续上传后续附件。运维不确定创建结果的幂等请求仅供原车辆/原记录范围重试，不带入另一车辆。已发出的保存命令仍以服务端结果为准，不自动回滚档案。两组复现与回归共 22 项通过，Admin 全量 273 文件、2189 项通过，类型检查及构建通过。车辆详情说明改为业务可读提示；本轮无布局或新增操作入口变更，也未进行真实页面验收。
+- 转派送重放修复：三条变更金额的重放路径先复现失败，再修正为摘要校验；另验证只换请求键且内容完全相同不重复创建或发布费用。复用现有请求摘要列，无新增表/列；模块和统一 SQL 仅同步该列的用途注释，未执行环境 DDL。完整 Lastleg 回归更新为 1090 项：1088 通过、2 项环境测试跳过、0 失败/错误；转派送服务 48 项、车次事务 33 项均通过，Gateway/依赖 15 项、初始化合同 10 项通过。该次回归包含当前共享工作区的退货记账增量，退货发布事实仍由正式环境契约维护；不将其算作车辆功能已发布。
+- 首版车次页面接入：模块/密度定向88项通过，新增四项关键页面流程验证分页不逐行请求、只读详情与按需历史、创建不确定结果复用原请求、实物托盘去重及人工测量提交；类型检查与构建通过。首轮Admin全量274文件2193项中2192通过、1项输入提示合同失败，补齐6处提示后该合同与新流程合计5项复验通过；未将此描述为又跑了一次全量全绿。共享导航由总控集成并单独验证14项。AGENTS索引仍有5项旧任务登记断言失败；本轮无环境部署、SQL或真实HTTP/视觉验收。
+
+接续顺序：Admin车次/装载操作入口与自有/外接委托预订 → 审核、逐站签收/异常及资源释放 → 运维/报价/统计与费用闭环 → 按授权部署测试环境、真实 HTTP、指定视口样式/交互及请求量验收。第 4.4 节按本轮首版确认执行；审核源码增量见第10.3节；外接接单和费用覆盖仍须继续实现。当前尚无部署或真实HTTP/浏览器验收完成证据，不以本地测试代替这些交付项。
+
+### 10.1 保养及加油接入的实施边界
+
+本增量沿原型已经定义的车辆详情页签及居中弹框推进 VM-03、VM-07a，未代替仍待答复的车次工作台承载选择。
+
+- 记录固定绑定车辆内部主键，使用独立 `VR-` 业务编号并保留建档时车牌快照；更换其他车辆路径不能读取、修改或下载原车附件。创建按车辆、操作人和请求键去重，更正保留版本、原因及完整历史。
+- 里程明确选择公里或英里；加油量明确选择升、美制加仑或英制加仑，不把原型含义不明的 `gal` 自动按某种加仑入库。上次、记录时、下次保养里程使用同一明确单位；下次里程须大于上次，但可低于记录时里程，以保留已经超过计划保养里程的真实情况。不默认套用每一万迈阈值。
+- 发生时间使用带偏移的实际时间，保存为 UTC，不得填写未来记录；历史记录里程可以低于当前车辆主档里程。运维保存不更新主档公里码、车辆可派状态或财务，核验状态仅记录“待核验/已核验”。维修、救援处理与付款状态仍按原未决项单独设计。
+- 照片类型 `FLEET_VEHICLE_RECORD_PHOTO` 固定平台与记录归属，仅非空 JPG/PNG、每张最大10MiB，每条最多20张。先保存记录再逐张上传；已上传结果保留，失败重试沿用原图片请求键。File校验文件签名，Lastleg核对复合归属，图片内容接口的HTTP200 JSON错误不能作为图片返回。
+- 页面进入“保养及加油”页签才分别请求两类分页；不逐行预读详情或图片。编辑时读取该记录最新版本，保存使用命令返回值更新当前行；创建后刷新当前类型列表。上传失败不重复创建记录，明确的参数错误允许改正，未知创建结果保留原请求内容和键供重试。图片按原型在新标签页查看，关闭或页面卸载释放临时地址。
+- 只读沿用 `vehicle:list`；新建、更正、上传分别为 `vehicle:record-create/record-edit/record-upload`。无新增菜单、Gateway配置或独立服务。部署涉及 Admin、Lastleg、File，以及 IAM三项权限和Lastleg两表的最新初始化定义；本轮没有执行这些环境操作。
+- HTTP编排已接入 `phase4-overseas-master-data.mjs` 的内部 `vehicle-care.mjs` 助手：验证创建重放、版本冲突、不可变历史、单位、照片重放及字节一致，另建本轮车辆验证跨车拒绝并在结束时停用；保留原记录、照片与失败证据，不执行SQL或修复历史造数。离线合同包含故意跨车泄露时必须阻断的反向场景；真实HTTP尚未运行。
+
+本增量验证：Lastleg完整回归1073项（1071通过、2项环境测试跳过），File完整216项通过；新增运维持久化/权限/接口/文件归属10项及File图片策略1项包含在其中。Admin全量273文件、2181项通过，含类型检查的生产构建通过。IAM权限目录补齐原遗漏的司机6项和新增运维3项常量，目录规模68项；IAM相关12项与Lastleg权限/API补验4项通过，不改变既有仓库角色授权。Gateway、初始化、依赖24项及315个Mapper注册检查通过；运维HTTP编排离线7项、脚本文档4项通过。初始化源当前为国内223表、海外143表、385项权限及566条角色授权，未向环境执行。AGENTS索引检查仍有同一组5项任务登记旧断言失败，未修改或清空登记表。
+
+当前交付仍缺维修/故障/救援后续处理入口确认、车次页面及未决外接/审核范围、报价/运营统计/费用闭环，以及实际部署、真实HTTP、指定视口视觉交互与请求量验收；不能以运维局部接入或自动检查通过宣布车辆管理整体完成。
+
+### 10.2 维修、故障、救援及异常增量
+
+2026-10-03 编辑规则补充：服务端采用 NON_NULL 响应，空的里程单位、核验状态及事件选填字段可不返回；Admin `api/vehicleCare.ts` 将这些字段统一初始化为空值，再进入编辑表单，避免将保养默认值提交到维修/救援记录。打开已保存记录后没有修改内容时，保存不产生更正命令或新版本；脏数据比较以同一个表单快照序列化，不受响应字段排列顺序影响。真实环境结论继续只维护在正式部署契约。
+
+运维独立回归已接入 Admin 正式验收入口的可选模块 `fleet-vehicle-care`，复用六类运维助手并创建本轮车辆。覆盖历史、照片、版本、跨车隔离，以及正金额/零金额与付款事实分离；失败保留记录和原始证据，结束停用专用车辆。该回归不表示公司车辆成本已经接入 Finance。
+
+本次继续使用同一记录、权限和历史合同，扩展 `REPAIR/BREAKDOWN/RESCUE/EXCEPTION` 四类，不新建第二套车辆或费用台账。
+
+- 维修及救援项目、地点分别保存；原型弹框读写错配已由明确字段替代。故障/异常保存描述、处理人和处理状态；异常另有轨迹、超时、派送、车辆故障四类分类。保养加油字段与这四类事件字段互斥，不能在共享表单内悄悄串写。
+- 处理状态为待处理、处理中、已完成；处理中或已完成须填写实际处理人，系统操作人另行留痕。更正仍须版本和原因，保留此前字段和金额快照。事件处理不自动改变车辆主档状态、解除车次占用或完成货物履约；这些联动尚不能被宣称已经具备。
+- 维修/救援费用是本条运维申报金额，允许未登记或明确零值；登记金额须有有效币种，运维保存本身不进行汇率换算或自动入财务。当前服务端对维修/救援返回只读 `paymentStatus=UNLINKED`，页面显示“未关联财务”；处理完成不能生成已付款事实。公司车辆成本及入账规则已按文首2026-10-03追加确认实施，正式Finance关联与状态读取尚待接入。
+- 页面按原型新增四个详情页签，只加载当前车辆当前页签；四类新增及异常编辑均用原620px居中弹框。原型没有维修/故障/救援后续行操作，已发出“列表更新处理、复用居中弹框”或“仅登记结果”的选择，等待答复期间不添加新行操作。未给四类事件新增原型未定义的照片预览或删除入口。
+- HTTP验收助手已覆盖四类新增、处理完成、重新读取项目/地点/处理人、分类型列表；补充“处理完成被错误映射为已付款必须失败”的反向测试。该助手只通过正式接口处理本轮测试资源，不把离线模拟结果写成真实HTTP已验收。
+
+本次验证结果：Lastleg全量1076项，1074通过、2项环境测试跳过、0失败/错误；运维持久化扩展为9项。Admin全量273文件2185项通过，类型检查与生产构建通过；新增前端回归验证项目/地点独立提交、异常编辑不提前修改原行、零费用与付款状态分别展示、未确认行操作不开放。IAM相关12项通过；Gateway/初始化/HTTP编排22项及依赖/脚本文档14项通过。无新增表、权限码或Gateway配置，初始化表数和角色授权数不变；更新了六类枚举和权限显示名称。AGENTS索引仍为同组5项任务登记旧断言失败；本次未部署、未执行环境SQL或真实HTTP，也未完成浏览器视觉和请求量验收。
+
+
+
+### 10.3 首版调度与理货审核
+
+排车列表以服务端分页参数 `stage` 展示全部、装车前、装车中、装车后及已取消：装车前对应 `PENDING_DEPARTURE`，装车中对应 `PICKING/READY_TO_DEPART/PARTIAL_READY_TO_DEPART`（含拣货完成待发车），装车后对应 `DEPARTED/PARTIAL_DEPARTED`。阶段与具体状态筛选取交集，不按当前页数据做本地分组。阶段不表示审核通过或实际装载确认。
+
+二级页签为“车辆信息／调度审核／理货员审核”，位于执行阶段与查询区之间。二级页签切换当前阶段下的信息和操作视图，保留筛选、分页及服务端总数，不对当前页记录做审核状态过滤；审核视图集中展示对应审核状态、打回原因、时间和进入审核的操作。三种视图独立保存列设置。
+
+平台列表同一响应批量返回关联车次、每单调度审核及整车理货审核的状态、打回原因和审核时间；未关联显示“未关联车次”，不伪造待审或已通过。具有车次列表权限可从列表进入车次“分配与货物”或“实际装载”，审核仍沿车次独立写权限及版本门禁。列表只读信息沿排车列表权限，前端不逐行查询车次。
+
+
+按本轮确认实现两级简化审核：每张客户排车单独立调度审核，通过后才能产生新的PDA拣货或完成命令；整车实物装载确认后，再做理货审核，通过后才能整车发车。操作只有通过和打回，通过意见选填，打回原因必填；不增加审核清单、提交队列或不同审核人限制。
+
+- 车次详情的客户排车行展示审核状态、原因和时间，支持详情跳转、通过、打回；实际装载分区提供整车理货审核。两个写权限为`platform:fleet:trip:dispatch-review`和`platform:fleet:trip:loading-review`，只读沿用车次列表权限。
+- 调度审核保存于`ll_fleet_trip_dispatch.review_json`，理货审核保存于`ll_fleet_trip.loading_review_json`，为空表示待审；历史保存各次审核快照。新增两列，无新增表。
+- 换车、换司机或改路线/时间后相关调度审核、理货审核和装载确认重新待处理，保留全部已发生的拣货事实；仅修改备注不触发重审。重新确认实载、关联变更或重新审核调度单后理货审核待审。客户A审核通过不能替代客户B。
+- PDA展示当前单`canPick/pickBlockReason`，发车继续由服务端整车门禁决定。已经成功的同键拣货重放返回原结果，不因后续重审而重复扣库存。未知网络结果不得生成新的物理作业事实。
+- HTTP验收助手已接准备阶段调度审核、发车前改派后的重新审核以及最终理货审核；发车使用最终审核返回的新版本。留存场景也须已有合法调度审核，不绕过门禁补写旧单。
+
+统一初始化SQL已同步两列，海外保持144表；IAM模块及头程统一基线已同步5107247/5107248两个按钮权限，并授权平台管理员。当前本地Admin定向94项、类型检查及生产构建通过，新增两条API路径的6项补验通过；海外PDA定向15项及H5构建通过；Gateway/依赖/HTTP助手/脚本文档37项通过。Lastleg全量1093项首次为1089通过、2项环境测试跳过，2项新增字段/权限合同失败在统一SQL同步后已定向补验通过；补验含Fleet API/权限3项及IAM权限4项。初始化合同10项通过，精确计数为387权限、568角色授权。没有重复运行已经通过且输入未变化的行为测试。AGENTS索引仍有原5项任务登记清空旧断言失败，未擅自清空已授权登记。没有将这些本地结果视为部署或实际页面验收完成。
+
+
+### 10.4 外接运力前置与收货链核对
+
+外接货送到我方起运仓，继续使用既有仓储转运的真实收货链；`WarehouseTransferService.createAndSubmit`在未引用旧入仓时建立本次新来货来源，PDA测量/托盘绑定/完成写入真实库存，客户确认后形成可排车来源。当前本土卡车`receivePallets`仅更新其订单托盘业务记录，不能拿该状态当作库存实收完成。外接登记与该链的正式关联仍须实现，不能仅凭此复用判断宣称外接履约已接通。
+
+本轮增加车次“计划容量”页签和`/capacity-plan`读写：在自有货尚未拣货时，按真实托盘输入预计托位、重量、体积及卸货站，服务端按每段核算剩余容量。共享实托只计一次；缺失来源、超容量、旧版本或货物hash变化拒绝提交。计划容量与实际装载的卸货站只允许选择与托盘货物 `destinationKey` 一致的已匹配站点，不以显示名称判定同一目的地。未匹配时明确提示到“分配与货物”执行“按货物匹配卸货站”；同一托盘含不同目的地标识时提示先拆托，保存的旧卸货站索引失配时不继续沿用。保存计划不会生成实载、通过审核、扣库存或发车；发车前继续单独核对实测装载。改车、改司机、计划或关联变化使计划容量待重核，纯备注保留；历史保存当时计划依据。
+
+新增`ll_fleet_trip.planned_load_json`一列，没有新增表、权限或服务。已有trip:list/edit分别承担查询及保存权限。GET的`planValid`只表示当前货物来源与已核对计划一致；无计划或来源变化时不展示过时余位。外接预订尚未占用该余位，后续须在同一车次锁内结合已确认预订计算，不允许把这个单独查询当作已实现防重复出售。
+
+后续接入的直接入口已核对：IAM `/internal/iam/finance-customers`支持按客户ID精确读取有效客户，`/internal/iam/tenants/{tenantId}/order-eligibility`提供下单资格；不以采购历史去重列表代替客户主档。平台代外接客户登记和确认收货仍须建立明确命令及权限，不能要求无工作台账号的委托方假登录操作。费用覆盖和新增项目收费继续按第4.3节完成，不伪造零金额费用绕过现有转派送条件。
+
+本地验证：Admin定向96项、类型检查和生产构建通过；Gateway与Lastleg依赖合同15项通过。Lastleg全量1095项首次为1092通过、2项环境测试跳过、1项统一SQL字段同步合同失败；总控同步统一海外列后Fleet API/Schema两项定向补验通过，初始化合同10项通过，海外保持144表、权限与角色授权数量不变。计划容量行为2项已通过，包括拣货前计划、实托去重、资源变化失效、旧来源拒绝及不覆盖实际装载。AGENTS索引仍为此前5项任务登记清空旧断言失败，未清空登记或放宽断言。真实部署、HTTP及页面验收仍须后续执行。
+
+
+### 10.5 外接登记与承运占位（2026-10-03）
+
+已增加车次内外接询价列表、登记/编辑、只读详情、确认承运与取消入口，后台使用1080px居中表单。登记先填有效客户、既有路线卸货站及箱数；预计托位/重量/体积、价格和联系说明可以后补。首版自送到车次起运仓，联系人不要求特定电话格式。按标准托位或整单记录报价，约定运费仅为商业约定，不自动生成应收、实收或费用入账。
+
+- `ll_fleet_external_booking`保存稳定FB业务号、客户编号/名称快照、货物与报价、版本及请求摘要。DRAFT询价不占位；CONFIRMED在父车次行锁内确认承运并占位；CANCELLED释放尚未执行的预订。历史直接进入既有车次历史的`externalBookings`快照，没有另外建重复台账。
+- 客户候选及精确建档校验读取IAM当前有效客户主档，正式登记与确认承运核对客户下单资格；失败时不创建假客户，也不以采购历史去重列表替代。新增只读Feign使用内部服务身份，不发送浏览器Token。
+- 确认承运核对仍有效的自有货容量计划、全部已确认外接预订及本次申请，每段托位/重量/容积任一超限拒绝。计划容量响应`availableSegments`扣除已确认外接占位；询价与取消不占位。自有货重新测算也不能挤占已确认外接容量，换小车须能容纳两者；同车换司机不要求为此额外先重填容量。
+- 创建、确认、取消按原请求键和内容重放，不重复占位/释放；更新同时核对车次和预订版本。界面保留未知结果的原请求，刷新查到确认/取消事实后解除待重试状态；只读用户可看详情，不能执行写操作。
+- 新增四项写权限为`platform:fleet:trip:booking-create/edit/confirm/cancel`，IAM资源使用总控核对后的5107260..63（5107250..52已被车辆运维占用），父5107240。模块与统一海外基线当前145表，权限391项、角色关联572条，未向环境执行。
+
+本批仍未实现外接来货单创建/关联、实测差异重新确认、外接货与客户排车关系和费用覆盖入账。已确认但未关联实际发运的预订会明确阻止整车发车；不能用“确认承运”冒充已收货或已发运。后续须补齐这条连接后才能作为完整外接版本部署验收。
+
+本地检查：Lastleg全量1099项（1097通过、2项环境测试跳过）；新增外接占位行为含登记重放、确认后扣减/取消恢复、超卖拒绝、自有货增量不得侵占预订和历史快照。客户目录两项验证精确客户与资格、依赖失败关闭。Admin定向原99项中只读测试因将说明文字误当按钮失败，已改为核对真实按钮并补充详情/编辑，四项面板测试通过；最新类型检查及生产构建通过；同车只换司机无需额外容量重填的收尾变更经FleetTripPersistence39项补验通过。Gateway/切片依赖通过；同步依赖已精确登记新IAM只读边及此前遗漏的运维文件HTTP调用，10项合同通过；316个Mapper扫描通过。真实环境、页面视口及请求量验收尚未执行。
+
+
+### 10.6 外接真实来货、实收确认与排车关联（2026-10-03）
+
+本轮把预订连接到已有仓储转运/PDA真实收货流程，未另建库存账：
+
+1. 已确认承运的预订由运营生成来货单，固定预订客户、起运仓、箱数及既有卸货站；首版客户自送。该操作创建并提交、审核原来货流程，只形成待PDA收货，不写实收库存；私人地址必须与原约定卸货键一致。
+2. 仓库通过现有PDA转运测量、托盘绑定及完成流程写入实际库存。车次后台按需查询实托、箱数、重量、体积及receiptHash；尚未完成测量不能确认实收。
+3. 运营明确核对实托占用托位和约定单价；实际数量变化会重新计算约定金额，同时按实际载荷替换原预留并重验余位。原来货确认成功且实测摘要未变后，预订才进入RECEIVED；库存不会重复写入。失败保留原报价/预留，不能先将未完成确认标成成功。
+4. 来货库存经现有预排生成客户排车单，再在车次外接行关联。服务端核对客户、同一起运仓、来货来源、实托、整批实收数量及目的地。通用车次绑定入口也执行该检查，不能将已承诺货物挂到另一车次；同一排车可携带多票合法来源，每票分别核对。
+5. 关联成功后预订进入BOUND，预订容量转由实际关联货物计量；容量计划/实际装载和理货审核重新待核对。后台刷新车次成员及审核状态。后续仍逐客户调度审核、PDA拣货、实际装载及整车理货审核后发车。解除未开工排车关联回到RECEIVED并恢复预留；已拣货沿既有正式撤回边界处理。
+
+取消未执行预订仅释放承运位置，已生成来货单和已入库货物保留，不据此删除库存。预订保存来货号、排车号、实测证据及各命令请求键/摘要；原请求重放返回当前事实，不重复创建来货或关联。四个新增读写接口继续使用现有booking-edit/booking-confirm与trip:list，绑定还需trip:edit。总控已同步原预订表新增字段/索引及RECEIVED/BOUND状态，仍145表、391权限和572角色关联，未执行环境SQL。
+
+实现入口为`FleetBookingIncomingGateway`、`transfer/fleet/FleetIncomingAdapter`和`FleetBookingService`；按精确端口引用接入，没有放宽转运切片对车队实现的依赖。沿实际收货路径移除了把内部客户ID拼成展示名称的回退，未知名称显示“—”。前端承载为`TripBookingFulfillmentDialog`，普通交货说明选填，来货和实收详情只在打开时读取。
+
+验证：Lastleg全量1102项（1100通过、2项环境测试跳过、0失败），后续实收确认必须返回可排车状态的收尾约束已通过42项定向补验；Admin模块及密度103项通过，外接关联后刷新成员/审核的交互补验通过，类型检查及构建通过。Gateway/精确依赖15项、初始化10项通过。仍缺原运费覆盖/新增费用正式接入、其余运营闭环和真实环境全链验收，不能以预订与收货连接宣告完整车辆模块已交付。
+
+### 10.7 外接实收报价接入派送费用（2026-10-03）
+
+外接运费已从报价展示接到正式费用发布：排车转派送打开时读取一次`GET /dispatches/{dispatchNo}/external-freight`，复用dispatch:list只读权限；服务端核对每票真实来货、所属客户、绑定车次、目的地及完整实托箱数，返回报价版本、计价量、原币金额与货物/报价摘要。查询不会创建费用。提交沿原transfer-delivery写权限，并携带externalFreightHash；实收、报价版本或来源改变时重新核对。
+
+- 转派送在现有事务内，按每票外接实际卸货目的地关联对应派送单，发布`OVERSEAS_DELIVERY_FEE`应收及现有费用Outbox，由Finance消费形成账务事实。约定金额、计价量、单价、实际入仓码和预订业务号随费用与操作记录保留。当前仅证明本地调用接通，未证明真实Finance已接收。
+- 全部货物为已确认外接时不再要求手工填派送费，且服务端禁止重复派送应收；混合排车只要求其余货物的派送费，手工派送费归其余货物对应派送单。装车和购买预约仍单独登记。原头程运费是否已覆盖这些服务，尚未接入，不能据此宣布全部不重复收费需求完成。
+- 明确约定零运费保留预订版本与派送操作事实，不伪造零金额财务费用。为与当前正式费用和汇率能力一致，确认承运仅支持CNY/USD；询价可先保存，非支持币种在承运确认时提示调整。USD正式发布仍须业务月份有效汇率。
+- 既有出库唯一约束及请求摘要保证原请求重放只返回原派送单，换操作人重试也不再发布外接费用。外接预订必须先完成真实车次关联，不能从普通转派送绕过实收/承运确认。取消出库后的费用作废/更正及再次安排仍须继续接通，不将取消物流单据视为账务自动撤销。
+
+本地验证：后端5类107项通过，覆盖报价/来源核对、分目的地费用归属、零约定、陈旧摘要/重复派送应收拒绝和换操作人重试；Admin排车交互/API/原型合同45项通过，类型检查与生产构建通过。Gateway 5项、Lastleg精确依赖10项通过，未放宽依赖基线；AGENTS索引仍有原5项登记清空旧断言失败。无新增表、权限码、Gateway配置或Finance事件结构，未执行SQL、部署、真实HTTP或视觉验收。后续优先完成每票原费用来源及服务覆盖、取消账务处理，再继续其他运营闭环与环境验收。
+### 10.8 出库取消与费用撤销确认（2026-10-03）
+
+首版取消顺序明确为：未拣货时先解除车次关联，再取消出库；仍需在原排车列表取消排车以释放该排车占用。取消不代替实物退仓或已执行货物撤回。后端按dispatch→outbound顺序锁定，并核对排车本身未拣货/发车，避免出库快照仍为待出库时误取消正在执行的货物。来源订单从本次转派送历史恢复真实原状态，显式清空已取消的出库/派送关联并递增版本，不统一写成RECEIVED；取消原因完整留在派送操作记录。
+
+费用处理沿用现有Lastleg费用来源与可靠Outbox：
+
+- 取消仅对本派送当前已审核有效的DELIVERY_FEE应收申请作废；装车、买约、供应商成本及其他待核对费用保留。物流取消成功不代表账务已作废。
+- 作废请求先保持原来源ACTIVE，返回PENDING_FINANCE；只有Finance对同一事件ID与载荷摘要返回APPLIED/DUPLICATE，才在投递审计、Outbox完成、来源VOIDED同一事务内落账。拒绝、未知结果或确认落账失败都不能假作废；拒绝/耗尽显示FINANCE_ATTENTION，已确认显示CONFIRMED。
+- VOID投递等待原版本发布成功，未满足前置的撤销在队列LIMIT之前排除，避免前50条未就绪撤销堵住后续正常费用。过期PROCESSING继续沿既有租约恢复。费用调整在来源行锁后按READ_COMMITTED核对未决撤销，不能用旧快照漏过撤销申请。
+- 重新安排发运按客户及实际入仓码核对原派送应收最新版本；原费用未确认作废时不能再次发布。即使原预订已取消，仍保留其真实来货/实收的财务来源关联。新发运以预订和新排车共同形成费用请求键，原出库重放依旧只返回原结果，不重复收费。
+- 派送详情和直接复用该费用接口的货柜费用面板区分待财务确认、待财务处理与已作废；待确认/待处理不开放调整或重复作废。查询批量读取确认状态，不逐行发HTTP请求；财务结算、已出账拒绝和后续人工处理仍以Finance事实为准。
+
+本批没有新增数据库列/表、权限或事件协议；复用现有V1完整快照、严格匹配ACK与原投递审计，不表示海外费用阶段0全部完成。共享初始化基线由总控新增废弃审核权限后为海外145表、392权限、573角色关联，本批未改共享SQL。自有货原运费服务覆盖、其余车辆运营能力与真实环境全链验收仍未完成。
+
+本地验证：最终7类69项通过，其中6项Spring/MyBatis/H2测试验证费用确认与投递审计原子提交/失败回滚、陈旧确认拒绝、原发布等待、队列不饥饿以及原费用最新版本去重；之前费用/派送10类76项已通过。契约严格解析发现智能排车候选的两处重复重量字段，已移除重复定义并通过2项合同补验。Admin派送/出库与货柜费用32项通过，类型检查及生产构建通过；Gateway/依赖15项通过。AGENTS索引原5项登记清空旧断言仍未关闭，未清空登记。没有部署、环境SQL、真实Finance撤销HTTP、指定视口视觉或请求量完成证据。
+
+### 10.9 原运费按本次实际货物确认服务覆盖（2026-10-03）
+
+当前部署及真实环境验收结论统一查阅[测试环境单机部署与配置契约](../测试环境单机部署与配置契约.md)和[统一认证与服务通信契约](../统一认证与服务通信契约.md)，本节保留实现说明与当批本地验证边界。车辆专项编排入口为 `baiyue-firstleg/scripts/fleet-test-env-acceptance.mjs`，按真实自有货与外接来货执行费用覆盖、容量预留、PDA实收、并车、约定运费、逐单拣货、整车发车、逐目的地签收及资源分别释放。库存来源核对采用余额明细、实物位置及不可变流水；实收使用 `receivedPackages`；命令重放对比持久化后的业务记录。失败保留原命令和原样本，只允许显式核对的阶段继续，终态对账仅作只读请求；Finance消费入池与生产者ACK分别取证。具体命令与边界见该仓库 `scripts/admin-test-env-modules/README.md`。
+
+已接通读取、运营确认、转派送校验、快照保存与详情展示。此节更新第4.3节初始差距，不把历史“尚未实现”记录作为当前实现状态。
+
+1. 打开转派送时，并行读取一次外接约定运费和一次原费用覆盖预览，不逐行发请求。`DispatchFeeCargoMapper`按实物库存组成及本次已拣数量逐票还原，同仓/客户/排车隔离，并按计划托盘限制其真实来源；核平每条排车箱数后，使用真实尾程订单冻结的头程入仓ID，避免把合托展示的MIN入仓码当成整托来源。
+2. `FinanceFeeCoverageClient`批量调用Finance内部只读`delivery-fee-coverage/sources`，仅返回该客户、这些原入仓单的FIRSTLEG已审核有效应收最新版本；作废/替代/其他客户/应付不能作为覆盖依据。AVAILABLE和SETTLED均可作为原费用事实，不把AVAILABLE显示为已付款；来源柜号不能伪装成入仓码。无匹配来源为空，调用失败或范围不一致明确报错，不能伪造已包含。
+3. 平台运营在原1120px转派送弹框内，针对各票原费用明确勾选本次已含派送、装车或买约；不按费用名称、总金额或同客户其他费用自动推断。提交原费用ID、版本、hash及当前货物/目的地摘要后重新读取并核对。只有全部相关货物都已覆盖的服务才免新增应收；只覆盖其中一票时，仍须填写其余货物/服务的新费用。外接货仍按已确认实收报价生成对应运费，不能借“引用原费用”抹掉外接价格。
+4. 原费用不复制入账、不做金额抵扣、不伪造零金额费用，也不直接把原全程运费总额算成本车收入。新增应收只对应未覆盖范围；多来源时不把MIN订单或已覆盖票冒充唯一收费来源。客户应收与供应商应付独立，同项目收付使用不同费用请求键；服务已含只免相应新增应收，不消除真实供应商成本。
+5. `ll_outbound_order.fee_coverage_json`保存确认时实际货物、原费用版本与明确服务、操作人和时间；详情只展示当前派送所属货物的引用。原费用后续财务更正不自动改写旧发运确认，也不自动追加收费；业务更正按取消未执行单据后重新确认等正式流程处理。原成功命令重放保持原快照；无引用的null/空数组具有相同业务摘要，客户接口不能自行声明原费用覆盖。
+
+模块和统一海外初始化已同步这一可空JSON列，没有新增表、权限或费用事件协议；普通无引用发运该列为空。发布单元包含Finance、Lastleg与Admin；Gateway沿已有路由，内部Finance入口不公开。当前服务图新增的是Lastleg→Finance只读请求边，接口实际只到Finance本库；已用单独合同约束该查询无下游调用、无账务写入。静态服务级最长链上界因此变为6跳，仍如实记录既有超两跳风险，不把服务级组合图冒充本接口实际链长。
+
+本批只证明费用覆盖源码及本地行为，仍须真实Finance/Lastleg部署与来源引用、旧版本冲突、全覆盖/部分覆盖、取消重排和页面请求量验收。车辆运维财务关联、运营统计/报价及在途异常等未完成工作继续按原工作包推进，不据此缩小车辆管理整体目标。
+
+本地验证：Finance与Lastleg聚合回归构建成功，Finance 223项全部通过；Lastleg 1142项中1140通过、2项环境测试跳过，0失败/错误。Admin费用覆盖相关4文件31项通过，类型检查及生产构建通过；最后的加载提示调整另经类型检查通过。Gateway、切片和同步依赖合同合计26项、初始化合同10项通过，Mapper扫描317项通过。AGENTS索引当前1094项全部通过，前述历史批次记录的5项旧断言失败已不再是当前阻塞。验证日志位于Lastleg的target/fleet-coverage-*本地输出，本批未据此宣称测试环境部署、真实HTTP、页面视觉或请求量验收完成。
+
+### 10.10 报价、运营统计、在途交接与公司车辆成本集成（2026-10-03）
+
+报价库按采购/销售区分供应商与客户，提供版本历史、启停、删除和整批原子CSV导入；未知价格与零价分别保存。通用菜单接入`/overseas-master-data/fleet-quotes`，不复用海外仓仓储报价。外接预订已接入可选销售报价来源，来源版本与本次成交金额分别冻结，不以原报价替代实际约定运费。
+
+报价选用增量：候选提供端按客户、起运城市、目的仓码、币种、计价方式及服务日期筛选启用销售报价；缺价不按零价处理，不自动选择最低价或将整车价当拼载成交价。预订接入按起运仓正式详情的城市/时区和计划出发时刻生成条件，复用Warehouse已有内部详情接口，不从仓名、国家或浏览器时区推断。引用为可选项，私人地址或缺少明确仓资料可继续手填成交价。来源版本及原报价保存于独立`quote_source_json`，与本次成交单价/数量/总金额分开；确认承运前复核所选版本和有效性，承运确认后的实收改价保留原来源。实现沿`FleetBookingService`、`FleetBookingQuoteContext`及Admin `TripBookingPanel.vue`；部署及真实费用闭环仍须以主契约证据判断。
+
+车辆菜单的出车记录`/overseas-master-data/trip-operations`从不可变DEPART汇总，每趟一次；图表与列表使用相同筛选和币种口径。实际里程/油耗只作独立补充更正，不改发车、结案或财务事实。成本通过服务内有界批量Summary读取，没有记录、无权限和未查询分别展示，不把约定外接金额当应收或收款。
+
+实测凭证为选填PDF/JPG/PNG，单文件10MiB、每版最多20份，独立类型`FLEET_TRIP_OPERATION_EVIDENCE`按平台及车次归属。上传只创建不可变文件，保存实测记录才冻结引用；移除当前引用不删除历史，预览按当前或历史版本按需鉴权读取。上传结果未知时停止重传，可先不绑定该附件继续保存；实测内容保存重试仍使用同一请求键、版本及内容。
+
+2026-10-05用户确认首版运营页展示Finance应收/实收：只展示Finance能够明确归属该车次的权威金额，按币种分别核对并可追溯来源；没有明确归属或付款分配的部分显示“待分配”，不能当作零元或已收。既有账单级核销不按未经确认的比例分配给车次，不把整账单金额或外接约定金额当作本车次应收/实收。成本与付款、客户应收与实收分别保持各自财务含义，不重复创建费用或资金流水。
+
+车次详情按需显示在途交接面板，后台确认实际交接；按实际剩余货物核验接替资源，只更新未完成派送，原DEPART、库存和费用不重写。原车辆与司机各自确认实际任务结束后释放；PDA首版只读展示当前履约资源。退回处置沿`exceptionorder/`的开始处理、证据、分批实收和取消命令，真实退回流水生成独立重派凭据；通过`RETURN_RECEIPT`候选和预排进入新PDA发运，不改原实发/签收。逐来源全签才回传国内完成事件，签后退回重送不重复计数。后端可执行不等于Admin处置页面已完整接入，当前页面与环境验收缺口见测试环境主契约。已拣未发撤拣/退仓撤回和余货拆给多辆车的交接不由这条退回重派链代替。
+
+同托退回来源按实际逐订单拣货归属核算；出库托盘明细上的主入仓码不能排除同托其他来源。排车明细与原出库明细使用物理托盘、原入仓码、目的仓和订单引用的冻结快照唯一关联；存在多个匹配时明确拒绝歧义，不能取首条猜测。退回凭据、新拣货和签收仍分别保留原来源、实际数量及时间，审核或异常工单状态不能替代实际实收与签收证据。
+
+派送列表和详情统一返回数据库冻结的实际签收箱数 `signedPackages`：未知返回 `null`，零和正整数保留原值，不以发货箱数代替。签收时间按服务执行时区记录，完成事件转换为同一时刻的 UTC；国内完成记录与事件时刻保持一致，不能把本地时间直接标为 UTC。退回重派核平使用实际签收箱数，并保持原派送签收数量和时间不变。
+
+公司车辆费用沿文首已确认口径进入Finance独立费用、历史和付款表，引用平台财务主体，不写入客户费用池、账单或钱包。CompanyVehicleCostSubmitted完整快照经既有Outbox直接投递Finance，匹配ACK只代表接收，入账/实际付款分别执行。费用和付款使用VC/VP业务号，公司凭证限定平台及费用归属。维修/救援页面已接来源提交、财务状态查询、入账、未付作废及付款凭证；查询、入账、作废、付款和上传独立授权。已付款不能直接作废或改写来源金额，未付款可作废重建；零申报金额可记录但不伪造实际付款。跨服务与受限账号的真实验收仍按两份主契约分别关闭。
+
+源码合同见`fleet-quotes-v1.yaml`、`fleet-operations-v1.yaml`、`fleet-handovers-v1.yaml`、`fleet-trip-costs-v1.yaml`及Finance的`finance-vehicle-costs-v1.yaml`。代码、初始化基线、发布和真实验收分开核对；环境证据仅维护于两份正式主契约。

海外仓业务/采购订单样品履约流程变更需求.md

@@ -0,0 +1,458 @@
+# 采购订单样品履约流程变更需求
+
+日期：2026-10-09
+
+采购订单需要从现有的下单、审核和数量记录，扩展为客户下单、海外购买、到仓装箱、国际快递交寄、国内收货核费及寄客户的完整流程。核心变更是将样品货款与快递费用分开控制：购买完成时扣样品货款，预估快递费先冻结，国内收货后再录入实际国际快递费、关税等费用。
+
+本文是本次采购流程变更的需求维护入口。2026-10-09，用户授权按“首版简单、后续可扩展”的原则确定原第 8 节的 19 项业务规则；本版已将决定同步到操作、资金、权限和验收要求，开发按本版执行。第 2 节仅记录修改前的源码基线，第 3 至第 8 节定义目标行为；本文不表示目标功能已经实现、部署或通过环境验收。
+
+## 1 已确认的目标流程
+
+客户采购下单 → 国外客服购买完成，填写预计到货时间并扣样品货款 → 货物到仓核对，录入每箱箱规、重量及装货清单 → 国内客服根据清单打快递面单，冻结预估快递费 → 上传面单，国外贴单并送快递站点 → 国内收货，录入准确国际快递费、关税等费用 → 寄给客户。
+
+| 节点 | 操作方 | 明确要求 | 需要区分的业务事实 |
+|---|---|---|---|
+| 客户下单 | 客户 | 创建采购订单 | 下单不代表已购买 |
+| 购买完成 | 国外客服 | 填写预计到货时间，执行样品货款扣费 | 购买完成与后台审核通过不是同一节点 |
+| 海外到仓及装箱 | 海外收货作业人员 | 收货核对，录入箱规、重量、每箱装货清单 | 入库总量不能替代逐箱清单 |
+| 制作面单及预估运费 | 国内客服 | 根据清单制作快递面单，锁定预估快递费 | 锁定是冻结，不直接扣款 |
+| 海外交寄 | 国外作业人员 | 获取面单，贴单，送快递站点 | 上传面单、贴单、交寄为不同事实 |
+| 国内收货及核费 | 国内收货人员、国内客服 | 国内收货后录入准确国际快递费、关税等费用 | 预估费用与实际费用必须区分 |
+| 寄客户 | 国内作业人员 | 将货物寄给客户 | 海外交寄与国内寄客户必须区分 |
+
+## 2 当前实现与差距
+
+以下为 2026-10-09 的源码核对基线，不作为测试环境部署或验收状态记录。部署与已验证场景仍以两份环境主契约为准。
+
+| 范围 | 当前已有 | 本次需要变更 |
+|---|---|---|
+| 客户下单 | 正式创建、列表、详情入口；商品、规格、链接、数量、预算、地址和联系人；提交后待审核 | 在已有入口增加后续履约进度与业务明细 |
+| 购买 | 后台审核、预计到达时间维护 | 增加独立购买完成操作及实际样品货款扣费 |
+| 海外收货 | 采购仓库、手工入库数量、签收文件 | 增加收货核对、逐箱尺寸、重量和装货清单 |
+| 快递费用 | 后台登记费用及凭证，发送冻结请求 | 区分样品货款、预估快递费、实际国际快递费及关税；改变结算触发时点 |
+| 面单 | 只有签收文件、费用凭证分类 | 增加面单上传、受控读取、箱关联及贴单交寄事实 |
+| 国内收货 | 未见采购专用国内收货节点 | 增加国内收货事实及实际费用确认 |
+| 寄客户 | 国内外承运商、运单号；通用出库明细及时间 | 明确国内寄客户记录，与海外交寄分开 |
+| 客户详情 | 基础商品信息、数量、预计到达时间、国内外运单、审核备注 | 增加节点进度、逐箱明细及获准展示的费用和文件 |
+
+现有采购展示状态为待审核、已通过、已拒绝、待出库、部分出库、全部出库，不能表达购买完成、装箱、面单、海外交寄、国内收货和寄客户。
+
+当前下单为单商品模型，仅有一份选填收货地址，联系方式允许填写电话、微信或邮箱。已有字段不能直接视为国际段和寄客户段均已具备可用于快递制单的收件资料。
+
+### 现有资金逻辑与目标冲突
+
+采购费用登记后发起冻结。当采购入库量达到采购数量时，系统对已冻结的采购费用发起结算；如果在全部入库后才登记费用，冻结成功回执也会继续触发结算。触发条件是全部入库，不是采购出库。
+
+因此，在货物到仓装箱后登记预估快递费，现有逻辑会继续结算，无法保证只冻结。必须移除采购费用依赖入库数量统一结算的行为，按不同费用用途和业务节点控制。不得仅修改页面文案而保留旧触发逻辑。
+
+## 3 首版履约范围与操作规则
+
+### 3.1 范围与扩展边界
+
+- 一单一个商品及规格、一次购买、一个履约批次、一个海外实际收货仓和一个国内接收地点；数量使用正整数件。一单允许多箱，国际段和寄客户段各一次整批实际交寄，可有对应不同箱的主/子运单。
+- 海外、国内均允许对同一批次分次追加实收记录，例如两箱隔日到达。实收登记不自动完成收货；全部到齐或差异已处理后，由操作人员确认该段收货完成，再推进整批后续节点。
+- 首版不支持多商品、追加或分批购买、分批国际交寄、分批寄客户、跨订单合箱及跨订单共用面单。购买前需要更换商品或数量时，取消原单并重新下单、审核；购买后不修改原购买对象。
+- 海外收货、装箱、贴单和交寄均使用 Admin。采购数量只记履约台账，不接入 PDA，不形成或修改 WMS 可用库存，不绕过既有 PDA 入账边界。
+- 商品、实收明细、箱内明细、两段运送及费用分别保留稳定业务关联；首版在服务端限制商品和履约批次数量，不把可扩展性做成未启用的流程、通用审批引擎或新的资金账本。
+
+### 3.2 节点操作与保存信息
+
+| 操作 | 保存的信息 | 执行与完成条件 |
+|---|---|---|
+| 客户下单 | 单商品、规格、链接、数量、预算单价及币种、最终收件人、联系电话及完整国内地址 | 登录客户隔离；预算非负且必须明确填写，零预算表示仅授权免费样品；提交进入待审核 |
+| 平台审核 | 通过或拒绝、审核人、时间、备注、采购仓 | 保留现有单级审核；采购仓取国内仓库主档中的有效海外收货仓。拒绝结束原单，不新增退回修改流程；审核不是扣款 |
+| 确认购买完成 | 已审核商品与数量快照、实际购买时间、供应商实付金额及币种、凭证、预计到海外仓时间、操作人 | 按第 4.1 节预算上限校验；真实购买事实与资金状态分开保存，触发实际货款扣费。未购买不得点击完成，也不得以预算替代实付 |
+| 登记并确认海外收货 | 实收时间、实际仓库引用及编码/名称快照、逐次实收数量、合格数量、差异和处置 | 对照购买明细累计核对；已到货可先登记，未齐或异常未处理不能确认收货完成 |
+| 保存并确认装箱 | 箱号、外箱长宽高、封箱毛重；箱内商品、规格、数量、实收来源 | 仅使用本单已确认可发的实收明细；各箱数量合计必须等于本批全部可发数量，不能重复分配。草稿可随收货准备；正式确认须海外收货完成、样品货款成功或确认零元 |
+| 外部制单、上传与预估冻结 | 已确认清单版本、箱关联、承运商、运单号、面单文件、两端地址快照、预估国际运费 | 国内客服在外部制单后上传，填写 CNY 预估金额；系统只冻结该金额。制单与上传可先完成，冻结未成功不能交寄 |
+| 确认贴单与海外交寄 | 逐箱贴单确认、实际交寄时间、本批全部箱及货物来源、承运商与运单、操作人 | 贴单与交寄分开留事实；全部有效面单与当前清单一致，预估资金已冻结或明确为零，且无阻断异常，才允许整批交寄 |
+| 登记并确认国内收货 | 原国际交寄箱、逐次实收数量、合格/异常数量、实收时间、差异处理 | 不用总箱数代替逐箱来源；分次到达可以记录，全部收齐或差异已处置后确认该段完成 |
+| 核定实际费用 | 国际运费、关税、国内运费、其他费用的核定情况、实际金额、凭证、业务日期、确认版本 | 国内收货完成后由有核费权限的国内客服确认并发起第 4 节资金处理；不增加客户在线确认或第二级财务审批 |
+| 确认寄客户 | 国内实际交寄时间、全部可寄实收明细及数量、承运商与运单、最终收件快照、操作人 | 第 5 节资金及异常条件通过后整批交寄；生成面单、取得运单号或提交寄件信息不代表已寄出；实际交寄后进入“已寄客户” |
+
+制单固定采用封箱毛重 kg（保留 3 位小数）和外箱长宽高 cm（各保留 2 位小数），数值必须为正。超出精度时提示按精度重新填写，不静默改变实测值；不新增净重、体积重或计费重试算。承运商计费与实测存在差异时，通过实际费用及凭证说明，不覆盖原测量值。
+
+面单首版仅接受 PDF/JPG/PNG，沿用 File 的大小和安全限制；一个文件可覆盖本订单多个箱，但应明确每箱对应的面单页或文件。国际段同一批可有多个箱运单，国内段同样逐箱可追溯；不要求一箱一笔冻结，不新增快递商、轨迹或打印机集成。
+
+### 3.3 修改、重制与历史保护
+
+| 对象 | 首版规则 |
+|---|---|
+| 商品、规格、数量 | 审核后锁定，购买前需要变更则取消重下；购买后仅允许登记事实更正说明及异常处置，不直接改原商品或数量。预算上限调整单独按第 4.1 节处理 |
+| 计划采购仓与实际实收仓 | 首次实收前由采购审核/管理人员选择或修改计划仓；首次实收冻结实际仓。实际仓录错由采购管理人员凭说明、证据更正并保留原记录；已有后续实物操作时不得通过改字段重归属，仅补充更正记录并处理异常。首版不做转仓 |
+| 实收数量 | 按该实收记录本段的下游判断：海外实收已有装箱确认时，先撤回尚未交寄的海外清单再建立受控更正；国内实收在尚未寄客户时可建立受控更正，重核可寄数量、国内面单及费用依据，不回滚原国际交寄。已完成本段实际交寄时仅追加更正说明和异常处置，不改写原实物事实 |
+| 未交寄装箱清单 | 修改形成新版本；箱、数量、尺寸、重量变化立即使旧面单不能用于新版本，需国内客服重新核对清单、面单与预估。旧贴单确认失效，重新贴单后才可交寄 |
+| 未交寄预估金额 | 金额不变且币种为 CNY 时，核对后可由新清单版本引用原有效冻结，不新建占款；金额变化则先释放旧冻结，成功后再申请新金额冻结。释放或新冻结未完成时禁止交寄，失败显示待处理，不保留两笔重复有效占款 |
+| 面单重传 | 同清单同金额只替换文件版本并保留历史，不重复冻结；换承运商、运单或收件信息须重新核对报价和箱关联，并重新确认贴单 |
+| 已交寄记录 | 保留当次清单、货物、面单、运单、地址和时间快照；之后只能追加有权限的更正说明，不覆盖原事实，不以改版本重新增加可发数量 |
+| 已确认费用 | 金额、币种、汇率及资金请求不能原地覆盖；处理中禁止确认更正，已结算后的增减分别走第 4.5 节调整 |
+
+海外交寄时，服务端须按本订单、当前清单、实际箱和货物来源原子校验并保存有效交寄事实。累计有效交寄不得超过本批可交寄装箱数量，本次必须覆盖全部可交寄箱；不同操作人、不同请求、刷新或更换清单版本不能重复发出同一货物。原请求重放返回原结果，其他请求遇到已交寄货物明确提示，不新增交寄数量或国内收货来源。合法更正只修订说明或建立关联更正，不产生第二份有效交寄。
+
+### 3.4 国内货物承接与异常
+
+- 国内实收逐箱关联国际交寄来源，同一收货事实不重复计数，分次实收按原箱累计核对；多到的货物单独记异常，不增加本单可寄数量。
+- 两端短少、破损、多货均先如实记录。未处理差异阻断收货完成及计划性发运，但不阻断继续登记真实到货。采购管理人员在本单记录“等待补齐、确认短少、破损拒收/处置、多货退回”的数量、原因、证据、操作人和时间。
+- 等待补齐不生成第二个购买或发运批次。供应商补发只用于海外整批交寄前补齐本单原采购缺口；国际交寄后，国内等待补齐仅限原交寄范围内的迟到货物。需要重新采购或再次国际发运的另行下单，不在原单追加交寄。客户接受短少、破损后剩余货物继续履约，或停止履约，均由客服留存客户书面/聊天凭证，采购管理人员确认。钱款由财务关联原费用调整，不按短少数量自动退款。
+- 只有已确认可寄的实收明细可继续装箱/寄出；已寄量加本次寄出量不得超过可寄实收量，且本次须覆盖本批全部剩余可寄货物。全损或无可寄货物进入异常关闭，不伪造零数量交寄。
+- 国内允许一原箱对应一新包装的破损换箱，记录原因与新箱规重量，保留原箱业务标识及其来源关系；换箱不改变已经核准可寄的商品、数量。不支持拆成多箱、合并不同箱或重新组合商品；损坏商品的剔除先走差异处置。
+- 购买前可由有取消权限的平台人员取消，客户通过客服提出取消；购买后不提供抹除履约的一键取消。全部实物去向明确、无需继续履约、已收费调整和冻结释放均完成且无未决资金时，采购管理人员可异常关闭。关闭保留原履约和资金事实，不自动退款，也不自动生成退货物流任务。
+- 本节只是采购履约记录及最小异常处置，不产生 WMS 库存流水，不新增通用异常工单、供应商应付或索赔系统。
+
+### 3.5 两段地址、文件与客户展示
+
+| 内容 | 首版处理 |
+|---|---|
+| 国际段收寄资料 | 寄件方取实际海外仓资料，国内接收地址由国内客服每单录入或从已有资料复制；国内收件人、联系电话及完整地址在制单前必填，不新增国内接收地点主档 |
+| 国内寄客户资料 | 客户下单提供最终收件人、电话和完整国内地址；国内客服寄出前核对。客户申请变更由客服凭确认记录修改；已制单须重制面单，实际交寄后不能覆盖原地址或在系统中假作改派 |
+| 资料快照 | 两段分别保存当次使用的收寄姓名、电话、地址及承运商要求的信息，后续主档变更不改历史快照；仅有微信或邮箱不能代替快递电话 |
+| 客户可见 | 本客户订单进度、预计到海外仓时间、装箱结构化明细、两段承运商/运单、预算上限、货款及各费用、冻结/扣款/退款结果、对客异常处理摘要 |
+| 客户不可见 | 面单、供应商采购凭证、费用凭证、预算沟通凭证、内部异常附件、内部备注及原始诊断报错；首版不开放这些文件下载，也不新增客户核费审批页面 |
+
+文件读取、下载和关联均由服务端校验客户、订单、文件分类及操作者权限。平台人员可在其采购业务权限范围内处理不同客户的订单，不强加个人仓绑定；关联的文件必须属于当前订单，不能仅凭同客户或文件标识放行。一个订单多箱共用一份面单允许，跨订单共享首版不开放。文件本体继续由 File 持有。
+
+## 4 费用与资金规则
+
+### 4.1 币种、预算和实际货款
+
+- 原币仅支持 CNY/USD，钱包、资金命令及本次采购实际费用入池统一 CNY。预算单价和原币费用保留 2 位小数；USD 折算复用 Lastleg 现有月度汇率及 OverseasFeeCurrencyConverter：取费用实际发生日所在月的有效正数汇率，汇率 6 位，CNY 金额 2 位，均使用 HALF_UP。CNY 汇率固定 1.000000。
+- 保存原币、原金额、实际业务日、汇率月份、汇率值和折后金额；确认后冻结快照。缺失有效汇率时不得确认资金金额，不能默认 1 或取回执/重试当天汇率；已经发生的购买仍可登记为待核定事实。
+- 预算总上限等于预算单价乘已审核数量，是样品货款上限，不包含运费、关税等服务费用。核对实付时，预算与实付均以本次购买相同汇率快照折算为 CNY 比较；实际货款按供应商实付 1:1 收取，首版不加价。
+- 无预算须先取得客户授权补齐；零预算只授权免费货款。超预算须在购买前取得客户书面/聊天确认，客服登记新的上限、币种与凭证，由现有采购审核人员核验后生效；保留前后上限，不新增客户在线审批或多级流程。
+- 已发生的未授权超预算须记录真实事实并暂停后续确认，取得客户授权后再核定扣费，或按异常终止/退款处理；不得静默超扣、伪造金额或丢失采购事实。买错商品或数量不通过补预算授权改写原购买对象，记录异常后处理退还/关闭，正确需求另单办理。
+
+### 4.2 费用用途与核费范围
+
+| 用途 | 时点与资金行为 |
+|---|---|
+| 样品货款 | 购买完成后按确认的实际 CNY 金额扣费；明确免费时只记核定事实，不发零元资金指令 |
+| 预估国际运费 | 制单阶段只冻结国际段预估 CNY 金额；零预估须记录依据，不发零元冻结。关税、国内运费及其他费用不混入该冻结，冻结不生成实际应收 |
+| 实际国际运费 | 国内收货完成后按实际金额结算唯一有效的国际运费冻结，规则见第 4.3 节 |
+| 关税 | 国内客服依据实际凭证核定，正额单独扣费，不适用或零元需明确确认 |
+| 国内运费 | 国内收货完成后可先外部制单确定价格，核定扣费成功后再交承运方；制单不代表发货，不引入“先发货才能知道金额”的依赖 |
+| 其他费用 | 默认不适用；发生时逐项填写名称、原因、凭证、业务日及金额，正额单独扣费。不得重复计入货款、国际运费、关税或国内运费 |
+
+国内核费由有核费权限的国内客服一次确认本单费用清单，不再增加客户确认或第二级财务审核。国际运费、关税、国内运费和其他费用范围都应有明确核定结果；其他费用可标为“不适用”，不要求创建虚构收费行。
+
+| 核定情况 | 处理 |
+|---|---|
+| 待核定 | 尚无明确结果，空值不视为零元；不能完成本单核费或寄客户 |
+| 确认零元 | 项目适用但无需收费，保存确认人、时间及依据，不发零元扣款、冻结或结算指令 |
+| 不适用 | 明确不适用于本单，保存确认说明，不伪造已付款 |
+| 确认正额 | 保存金额和确认版本，发起资金处理；核费已确认与扣费成功分别展示 |
+
+已有冻结对应的实际费用确认零元时仍须真实释放冻结。费用清单中的多笔正额分别处理，部分扣款成功不回滚已成功扣款，也不能重扣；只跟进其余未完成项，全部完成后才允许国内实际交寄。
+
+### 4.3 扣费、差额与冻结
+
+样品货款、关税、国内运费及其他正额费用复用 Finance 的业务冻结后立即全额结算链路，同一费用号最多一次成功实扣。中间显示扣费处理中，不要求客服手动执行两步；冻结成功不等于扣费成功。该自动结算只用于明确的实际费用用途，预估国际运费不得沿此链路自动结算，更不得由采购入库数量触发。
+
+设预估国际运费冻结额为 E，最终实际国际运费为 A，两者均为 CNY：
+
+| 情况 | 首版资金行为 |
+|---|---|
+| A = E 且 A > 0 | 结清原冻结，实扣 A |
+| 0 < A < E | Finance 在同一事务内实扣 A、释放 E − A，原预估 E 与实际 A 分别保留 |
+| A > E | Finance 在同一事务内校验并补占差额后实扣 A；资金/有效授信不足时整笔失败，保留原冻结和原余额，不先释放原冻结 |
+| A = 0 或国际运费不适用 | 仅释放对应有效冻结；无冻结则只保留核定结果，不生成零元结算 |
+| E = 0、A > 0 | 无原冻结可结算，按一笔实际国际运费执行冻结后立即结算；费用来源仍只记录 A |
+
+按实际金额结算冻结由 Finance 原子执行，Lastleg 不能用“释放旧冻结、再冻实际金额、再结算”的串行操作代替。此规则用于最终实际结算；交寄前重新报价使用第 3.3 节“先释放旧预估、再冻结新预估并阻断交寄”的流程，二者时点不同。
+
+资金可用额、授信期限、扣用顺序和充值归还顺序全部沿用 Finance 当前规则；采购不额外开放透支、不建立授信副本，也不套用信用卡授权有效期。冻结不因到货、时间流逝或订单页面关闭而自动结算/释放，必须关联明确的重估、结算、取消或异常处理动作。
+
+### 4.4 请求幂等、费用版本与入池
+
+- 每个资金请求绑定客户、费用用途、费用确认版本、原币/汇率/CNY 快照和唯一请求标识。每个费用业务事实最多一次成功扣款，不能通过新请求标识绕过该约束。
+- 处理中或结果未知时，可保存更正草稿，但不能确认新版本、发起替代扣款、退款或释放同一待决资金；先查询/重放原请求直至结果明确。网络超时不能当成业务失败。
+- 只有 Finance 已明确失败且确认未发生目标资金动作时，才允许对同一费用版本登记新的重试尝试；保留原尝试结果。冻结已成功但结算失败时只重试结算，不能新冻一遍。
+- 旧版本晚回执只能更新原请求及其费用版本，不覆盖新金额结果，不丢弃真实扣款、冻结或释放事实。未决时尝试确认 V2 应被拒绝，V1 结果明确后才能按第 4.5 节更正。
+- 本次采购的正额费用收到成功扣款回执后，才通过同一费用版本的 Outbox 发布实际应收来源。预估冻结、零元和不适用不发布实际应收；发布失败只重试来源投递，不再次扣款。
+- Finance 以明确的原资金处理引用和实际 CNY 扣款金额核对来源；匹配后直接作为已结算应收入池，不能进入普通待对账候选。来源缺少资金引用、引用跨客户或金额不符时拒绝或待核对，不降级成可再次收费的 AVAILABLE 来源。
+- 延迟、乱序及重放仍须安全：已扣款等待来源入池时显示该关联进度；关联不影响已经发生的资金事实，但正常寄客户前须完成实际费用入池关联，异常关闭前同样须完成关联。
+
+上述规则按[财务费用入池 P0 闭环](../财务管理/财务费用入池P0闭环.md)的防重复结算原则执行；本次采购采用“先实扣、后发布已结算来源”的确定路径，不增加采购赊账出账选项。
+
+### 4.5 更正、追加与退款
+
+- 未发出资金请求的费用草稿可修改；仅处于预估冻结阶段的金额变化按第 3.3 节重估。已发出请求且结果未决时锁定确认动作，不用新费用号避开未决状态。
+- 实际费用的资金请求已明确失败且尚未成功实扣时，先终止旧版本的后续重试；仍有有效冻结的须释放成功，才可更正确认新费用版本并发起关联的新请求。该情形不产生已实扣差额单或退款，旧版本不能因晚回执或人工重试重新生效。
+- 已结算费用增加金额，由具有财务调整权限的人员创建仅含正差额的新调整单、独立费用号，引用原费用和原因凭证；例如原已扣 100，正确总额 120，则新增 20，不重新扣 120，也不复用原冻结号。原实际费用和差额各自关联成功资金结果。
+- 已结算费用减少或应退，由财务人员创建关联原成功扣款的 CNY 退款调整，填写原因、凭证和金额。Finance 锁定原扣款，原子校验本次退款金额不超过“该原扣款金额 − 累计已成功退款”的可退余额；等价地，计入本次后的累计退款不得超过该原扣款。幂等回补客户钱包并保留不可变流水，回补遵循 Finance 现行资金归还顺序，不延长或恢复过期授信；仅冻结未扣款的款项执行释放，不做退款。
+- 退款只回客户资金账户，不走外部支付原路退款，不以普通充值伪装，不发布负数普通费用。原费用保持已结算，财务净额通过原款、正额调整及退款记录计算，不能重新进入待对账池。
+- 对同一原费用链的金额更正沿用原汇率快照，以“原扣款 + 已成功正额调整 − 已成功退款”计算当前净实扣，再与本次修正目标 CNY 总额求差。同一费用链有未决调整或退款时不得确认下一次更正；明确失败的旧调整须先完成，或终止其后续重试并释放仍占用的冻结后，才能按新目标更正，不能留下以后还可重试扣款的旧目标。独立新发生费用才使用新业务日汇率；退货、短少不自动推导退款金额，由财务依据已确认的客户处理方案执行。
+- 已成功退款、调整和原扣款均不得覆盖；同一调整单重放返回原结果，拒绝重复、超额及零元退款。需退多笔实扣时逐笔关联，不能跨客户冲抵。
+- 履约已完成后可以处理有凭证的追加或退款，资金进度单独展示，不把“已寄客户”回退成未发货；异常关闭时要求当时所有已知资金处理结束，后续新增有据调整保留关联记录。
+
+## 5 权限、状态与节点准入
+
+### 5.1 操作权限
+
+沿用平台/客户两级及现有 IAM 角色；不新建国内/海外用户类型或岗位主档。采购列表权限包含详情只读，写操作独立，按下表动作赋予现有岗位，可由同一账号兼任多个动作，首版不强制双人分离。
+
+| 动作范围 | 负责岗位及权限边界 |
+|---|---|
+| 客户下单和查询 | 仅本客户；不能执行后台审核、收货、发运或资金调整 |
+| 采购审核、取消、预算上限核验 | 现有采购审核/管理人员，保存审核或取消事实 |
+| 购买、海外收货装箱、贴单交寄 | 海外业务人员按各动作权限执行；服务端校验有效海外仓及订单冻结的实际仓，不把 Admin 用户绑定到某个 PDA 仓 |
+| 面单、预估、国内实收、核费、寄客户 | 国内业务人员按对应独立动作权限执行；面单上传不同时赋予核费或资金调整权限 |
+| 事实更正、差异确认、异常关闭 | 采购管理权限；资金结果不能通过此权限修改 |
+| 追加收费、退款 | Finance 财务调整权限；采购服务只发起受控业务请求，不直写账户或财务单据 |
+
+权限码、Controller、接口合同、IAM 配置与前端按钮由开发按此动作边界同步落地，不能继续用一个通用编辑权限代替所有新节点权限。平台授权人员可以处理不同客户的采购单；客户隔离及文件范围始终由服务端保证。
+
+### 5.2 状态与准入
+
+履约进度按事实派生：待审核 → 待购买 → 待海外到仓 → 海外收货中 → 待装箱 → 待面单及预估处理 → 待海外交寄 → 国际运输中 → 国内收货中 → 待国内核费 → 待寄客户 → 已寄客户。已拒绝、已取消、异常关闭单独记录；异常处理中作为阻断标记，不抹去最后真实履约阶段。具体枚举命名由技术设计确定，含义不得改变。
+
+| 动作 | 首版前置条件与资金失败处理 |
+|---|---|
+| 正常购买确认 | 已审核，商品及数量一致，预算授权和汇率可用；购买前可查询资金资格但不提前冻结货款。已真实发生的异常购买可登记，扣费失败不回滚购买事实 |
+| 登记收货事实 | 有对应购买/交寄来源即可记录实际到货，即使资金未成功；来源异常仍保留异常记录，不能伪造上游成功来放行正常链路 |
+| 正式装箱确认、预估冻结 | 海外收货完成、差异处理完毕、样品货款扣款成功并完成费用来源关联，或已明确免费；资金未决/不足时可准备草稿，不能完成上述确认 |
+| 海外实际交寄 | 清单、面单及逐箱贴单已确认；样品货款完成；预估国际运费冻结成功或确认零预估；所有可发货物整批一致，无阻断异常 |
+| 国内核费确认 | 国内收货完成，差异处置明确；四类费用均有核定结果，国内运费可以先制单取得确定金额。可以保存草稿，未核定不能确认整单费用 |
+| 国内实际交寄 | 全部可寄货物核平；全部正额货款/费用扣款及费用来源关联完成；零元/不适用已核定；多余冻结已释放；无未决退款/调整及阻断异常 |
+| 异常关闭 | 全部货物有明确去向且无需继续履约；所有已知费用、退款、来源关联和冻结释放完成；采购管理人员填写原因确认 |
+
+首版不允许客服用“继续发货”跳过资金失败或未知结果，也不新增人工透支开关。余额不足通过充值或 Finance 已有授信机制解决后重试。国内实际交寄确认即正常履约终态，不新增客户签收、物流轨迹或自动签收功能。
+
+## 6 代码入口、能力差距与实施边界
+
+| 范围 | 当前入口 | 本次实现重点 |
+|---|---|---|
+| Client | apps/client-web/src/modules/cross-border/routes.ts、views/ProcurementView.vue、components/BusinessOrdersView.vue、api/businessOrders.ts | 单商品下单校验、预算及地址、进度与费用展示；不影响共用组件中的本土卡车、散板 |
+| Admin | apps/admin-web/src/modules/overseas-business/pages/PurchaseOrdersView.vue、PurchaseOrderEditView.vue、PurchaseOrderDetailView.vue；api/platformOverseasBusiness.ts | 节点动作、实收/箱明细、面单、预算凭证、核费及异常权限；通用编辑移除越过节点的写入 |
+| Lastleg | baiyue-firstleg/lastleg-service/src/main/java/com/baiyue/lastleg/procurement/ | 状态和业务明细、用途驱动资金指令、版本回执、原子数量校验及审计 |
+| 费用来源与汇率 | Lastleg financefee/，按采购实际引用进入；OverseasFeeCurrencyConverter | 复用月度 USD/CNY 汇率快照；成功扣款后发布实际来源，预估不入池 |
+| Finance 与 File | 沿采购资金、费用和文件调用进入 | Finance 资金及关联扩展；File 文件归属、分类与授权 |
+
+现有钱包只有全额结算/释放，不能将“按实际金额结算冻结”或“关联原扣款退款”写成已经具备。首版必须补齐以下定向能力：
+1. Finance 在单事务内按实际金额结清预估冻结，并处理少收释放、超额补差、资金不足整笔不动。
+2. Finance 关联原扣款的幂等钱包退款、可退余额校验及财务调整留痕。
+3. Finance/Lastleg 按真实资金处理引用和实际结算金额绑定费用来源，防止预估金额与实际金额不同导致匹配失败或重复出账。
+
+业务费用仍归 Lastleg，账户/冻结/流水/财务事实归 Finance，文件本体归 File。统一 Gateway/Auth 和业务 Outbox 直接投递不变，不新建账本或事件桥。上述定向扩展是满足本版需求的开发内容，不以新增技术平台或跨库写入实现。
+
+开发前需完成本版对应的 DTO、状态/动作、资金命令与回执、表结构及权限合同设计。对外 API、OpenAPI、初始化 SQL、直接消费者、Mock/Fixture 和测试按仓库门禁同步；不为测试存量保留旧流程兼容分支。开发应移除“全部入库统一结算采购费用”的两处旧触发路径。
+
+需求整理阶段仅维护文档；后续用户已授权按本文开发，并部署测试环境、操作测试数据库、执行真实 HTTP 及内置浏览器验收。该授权仅用于本次采购变更的测试环境操作，不扩展到生产环境或无关数据清理。
+
+## 7 首版验收要求
+
+| 场景 | 必须满足的结果 |
+|---|---|
+| 单商品与批次边界 | 多商品、追加购买、分批发运、跨订单合箱请求由服务端拒绝；一单多箱正常完成 |
+| 审核及预算 | 未审核不得购买；无预算不得正常确认；零预算不能扣正额；超预算凭证核验前不能正常扣费；实付不能被预算替代 |
+| 汇率与跨月重试 | CNY/USD 原币与 CNY 折算可还原；缺失月度汇率不伪造金额；跨月回执及重试保持原快照；金额与精度按现行转换器 |
+| 购买事实与货款 | 购买完成发起货款扣费，不等到全部入库；失败保留购买事实，免费不发零元命令；重复请求不重复扣费 |
+| 分次到货 | 同一批次多次实收累计正确；到货可记录，未齐或异常未处理不确认完成；海外交寄前可补原采购缺口，国内迟到只接原国际交寄货物，需要再次国际发运的另单处理 |
+| 分段实收更正 | 海外实收更正撤回本段未交寄清单；国内实收更正不回滚已完成国际交寄，重新核对国内可寄数量、面单及费用；已完成本段交寄只追加说明和异常 |
+| 实际收货仓 | 实收后通用编辑不得改历史仓；受控录错更正保留原记录，修改采购仓不代表实物转仓 |
+| 装箱与测量 | 实收来源与箱内件数核平，不能重复分配；全部可发数量被覆盖；cm/kg 精度和正值校验正确 |
+| 多人海外交寄 | 非本单/无效清单箱拒绝；两人不同请求并发或刷新重提同一箱仅一份有效交寄；换版或更正不重复增加国内来源 |
+| 面单及预估 | 外部面单可按箱读取打印；上传、贴单、交寄分开；冻结成功仅减少可用额；零预估有依据；全部入库及其后新增预估均不触发扣款 |
+| 交寄前重制 | 清单/面单变化后旧贴单失效；同金额重传不重复冻结；变价先释放成功再新冻结，过程及失败阻断交寄 |
+| 国内实收与换包装 | 逐箱来源可追溯，重复实收拒绝；允许一对一换包装但不增加货量；拆箱、合箱及重新组合拒绝 |
+| 收货差异 | 短少/破损/多货如实记录，未经处理不继续；客户接受减量有凭证；无可寄货物不能零数量交寄 |
+| 核费及国内制单 | 四类费用有明确结果；国内运费可先制单再核定扣费，实际交寄在后；未知金额不当零元 |
+| 零元/不适用 | 不发零元资金指令、不发布虚构应收；原冻结仍释放并跟踪实际结果 |
+| 国际运费差额 | 覆盖 E=100、A=100/80/120/0 及 E=0、A>0；少收余款释放，超额不足时原冻结和余额不变，不出现重复占款或扣费 |
+| 未决更正与晚回执 | V1 请求未决时 V2 只能存草稿，确认及替代请求被拒绝；晚回执归属 V1且真实资金事实保留；超时查询/重放不重复执行 |
+| 明确失败后重试 | 原结果已确定且无目标资金动作后才能新尝试；已冻结只重试结算，同费用最多一次实扣 |
+| 扣款与入池 | 扣款成功才发布实际来源；投递失败不再扣款；原资金引用、客户或实际金额不匹配时不进入普通待对账池；乱序重放仍不重复收费 |
+| 追加与退款 | 已扣100连续改120、130、110，依次补20、补10、退款20，净实扣110；单笔原扣100已退30再退50应成功，再退超过20应拒绝；并发退款不能超原实扣；不以充值或负数普通费用替代，原费用不重新可出账 |
+| 节点门禁 | 扣费失败仍可登记真实到货；不能确认装箱或计划发运；国内交寄前全部资金、来源关联、余款释放及异常处理满足要求 |
+| 地址与真实发运 | 两段快照独立，改地址不覆盖旧面单；仅填写运单不显示已寄；实际国内交寄后进入正常终态 |
+| 客户与文件权限 | 客户仅见自己的结构化资料及费用结果，不能下载内部文件；跨客户文件读取/错误订单挂载拒绝；平台已授权跨客户操作不误拦 |
+| 取消与异常关闭 | 购买前可取消；购买后不抹除原事实；实物和资金未收口不能异常关闭；关闭不自动退款 |
+| 权限与前端回归 | 节点动作由服务端独立授权，通用编辑不能越权；采购修改不破坏本土卡车、散板；客户响应无内部附件和诊断信息 |
+
+代码和本地检查通过不代表整体验收完成。真实 HTTP 与环境写入、部署仍按仓库授权执行；Admin/Client 视觉验收按 1920×1080、100% 缩放，由人工操作并提供截图。部署与已验证场景仅维护在现有两份环境主契约。
+
+## 8 原 19 项业务规则的首版决定
+
+本表依据 2026-10-09 用户“按最简单可扩展方式先确认”的明确授权确定，替代原待确认清单。它是本次业务范围与行为选择，不表示实际人员已在业务单上完成审核或核费。开发按本版实施，后续改变范围需先回写本文。
+
+| 编号 | 原决策主题 | 首版决定 |
+|---|---|---|
+| 01 | 多商品、购买与履约批次 | 单商品/规格、一次购买、一个批次；多箱、分次实收；两段各一次整批交寄，见第 3.1 节 |
+| 02 | 购买前审核 | 保留现有单级审核；通过后购买，拒绝结束原单；不新增通用审批 |
+| 03 | 预算与超预算 | 预算为货款上限；超预算先取得客户书面/聊天授权，由现有审核人员核验；不做客户在线审批，见第 4.1 节 |
+| 04 | 币种与汇率 | 原币 CNY/USD，钱包及入池 CNY；复用业务日所属月汇率，快照不重算 |
+| 05 | 面单方式 | 国内客服外部制单、上传 PDF/JPG/PNG；无快递商/轨迹/自动试算集成 |
+| 06 | 箱规重量 | 封箱毛重 kg 3 位、外箱 cm 2 位，正值；不新增计费重试算 |
+| 07 | 重制与冻结 | 同金额核对后沿用冻结；变价先释放旧冻结再新冻，期间禁止交寄；旧面单/贴单按第 3.3 节失效 |
+| 08 | 事实更正 | 购买对象锁定；按本段未发运的下游撤回并受控更正，国内更正不回滚国际交寄；已交寄事实只追加说明/异常，不覆盖或重发 |
+| 09 | 两段收寄资料 | 国际段国内接收资料由国内客服每单录入，最终客户资料由客户下单提供；确认及交寄保留两段快照 |
+| 10 | 作业终端与仓范围 | 海外用 Admin，不接 PDA/WMS；角色复用、动作独立授权；校验有效仓与订单实际仓，不新增 Admin 个人仓绑定 |
+| 11 | 国内部分实收及重装 | 同批允许分次实收，收口后才继续；仅支持一对一换包装，不拆箱/合箱/重组 |
+| 12 | 实际费用确认 | 国内客服按独立核费权限一次确认四类费用；无客户或二级财务审批；未知不当零 |
+| 13 | 预估冻结范围 | 仅国际快递费；关税、国内运费及其他费用实际核定后单独扣费 |
+| 14 | 实际差额结算 | Finance 原子按实际金额结清预估，少退多补，不足原状保留；零实际只释放，见第 4.3 节 |
+| 15 | 未决费用更正 | 只允许准备草稿，原结果明确前不确认新版本或发替代资金请求；已扣增额做正差额单、减额做关联退款 |
+| 16 | 失败与节点准入 | 真实到货可记；正式装箱及计划交寄须满足资金条件；未知/不足不放行，见第 5.2 节 |
+| 17 | 差异、取消与退款 | 单内最小异常处置；客户减量/停止有凭证；购买前取消，购买后收清实物和资金才能异常关闭；退款回钱包，见第 3.4、4.5 节 |
+| 18 | 正常完成条件 | 国内实际交寄确认即“已寄客户”；不新增签收或轨迹。之后财务调整不回退履约事实 |
+| 19 | 客户资料开放 | 展示结构化箱明细、运单和费用结果；内部面单、采购/费用/沟通凭证及异常附件不开放下载 |
+
+### 开发交接结论
+
+原 19 项已转为明确首版规则，正文与验收按同一范围执行，不再以待产品选择的条件场景交付。开发仍需完成 DTO、数据库、权限、资金事件和接口的技术设计，并实现第 6 节的 Finance 定向扩展；这些属于已确定业务规则下的实现工作，不是新的产品待确认项。
+
+本版可交开发开展技术设计、任务拆分及实现。需求评审结论不替代编译、测试、环境或人工视觉验收，不表示当前代码已经满足目标。
+
+## 9 依据与成熟软件参考
+
+### 9.1 当前项目依据
+
+- [海外仓业务入口](README.md)
+- [财务管理入口](../财务管理/README.md)
+- [财务费用入池 P0 闭环](../财务管理/财务费用入池P0闭环.md)
+- [统一认证与服务通信契约](../统一认证与服务通信契约.md)
+- [测试环境单机部署与配置契约](../测试环境单机部署与配置契约.md)
+- [平台客户层级与权限契约](../平台客户层级与权限契约.md)
+- [客户端采购详情实现](../../apps/client-web/src/modules/cross-border/components/BusinessOrdersView.vue)
+- [后台采购详情实现](../../apps/admin-web/src/modules/overseas-business/pages/PurchaseOrderDetailView.vue)
+- [采购服务与现有资金触发逻辑](../../baiyue-firstleg/lastleg-service/src/main/java/com/baiyue/lastleg/procurement/service/OverseasProcurementService.java)
+- [现有海外费用汇率转换](../../baiyue-firstleg/lastleg-service/src/main/java/com/baiyue/lastleg/financefee/service/OverseasFeeCurrencyConverter.java)
+
+### 9.2 官方产品文档对照
+
+参考查询日期：2026-10-09。以下用于验证设计模式可行性，具体 19 项是结合本项目现状作出的首版选择，不是声称这些产品采用完全相同的业务规则。
+
+| 官方资料 | 本次采用的模式及边界 |
+|---|---|
+| [Odoo 19：收发货流程](https://www.odoo.com/documentation/19.0/applications/inventory_and_mrp/inventory/shipping_receiving/daily_operations.html) | 可从较少操作步骤开始，再按质量与仓储需要扩展；本次采用简化采购台账，不引入 Odoo 的库存体系 |
+| [ERPNext：Purchase Receipt](https://docs.frappe.io/erpnext/purchase-receipt) | 订单与实收分开，记录接收/拒收及短收关闭；本次允许同批多次实收和明确差异处置，不照搬其库存过账 |
+| [Shopify：Understanding shipping labels](https://help.shopify.com/en/manual/fulfillment/fulfilling-orders/shipping-labels/understanding-shipping-labels) | 支持在系统外购买面单后补充运单，贴单和交给承运方是不同动作；本次保留外部制单与人工交寄确认 |
+| [Stripe：授权与捕获分离](https://docs.stripe.com/payments/place-a-hold-on-a-payment-method) | 预留与实际扣款分开，部分扣款释放余款；本项目使用自有 Finance 钱包，原子补差是本项目扩展，不接入 Stripe，也不使用信用卡期限或超额捕获规则 |
+| [Stripe：幂等请求](https://docs.stripe.com/api/idempotent_requests) | 重试关联原请求，参数变化不能冒充原请求；本项目另加费用业务级防重复，不照搬外部平台的幂等记录保留期限 |
+
+可行性结论：上述模式能够支持本版采购样品流程；实施重点是本项目的明细关系、权限、资金用途及 Finance 定向扩展，不需要先引入完整 ERP、WMS、第三方支付或通用流程平台。
+
+## 10 技术实施合同
+
+本节将前述业务规则映射到实现边界，不改变业务范围，也不表示对应功能已完成。开发直接在当前工作区及分支实施。
+
+### 10.1 数据与事务边界
+
+| 数据对象 | 归属与核心关系 | 约束 |
+|---|---|---|
+| 采购主单 | Lastleg，保留当前采购单号与客户归属 | 主单版本控制；商品、规格和购买数量审核后冻结；履约阶段与资金状态分开 |
+| 购买事实与预算授权 | 关联采购单、原商品快照、凭证及预算授权版本 | 每单一次实际购买；异常购买事实可以先保存，但未核定金额不能扣费 |
+| 两段实收记录 | 段别为海外/国内；海外关联购买，国内关联国际交寄箱 | 分次追加与更正留痕；不能重复消费实收来源；实收不直接增加 WMS 库存 |
+| 装箱清单与箱内来源 | 清单版本、业务箱号、尺寸重量、实收来源及数量 | 每单唯一当前确认版；数量守恒；失效版本不得交寄；历史版本不能恢复可发数量 |
+| 面单与贴单事实 | 文件归 File，关联关系归 Lastleg；绑定运输段、清单版本及箱号 | 每箱明确文件或页码；面单版本改变后旧贴单资格失效；只允许同订单文件关联 |
+| 国际与国内交寄 | 每单每段唯一有效整批交寄；保存箱/来源数量、地址、运单快照 | 订单行锁内复验全部货物、资金与异常条件；两段交寄各自幂等，跨请求也不能重复发运 |
+| 费用版本 | 费用用途、核定情况、原币/汇率/CNY、版本、原费用链 | 草稿可修改；确认后不可覆盖；预估、实扣及退款分别记录 |
+| 资金请求尝试 | 费用版本、操作、冻结身份、事件 ID、请求幂等键、请求金额、结果 | 结果按 commandEventId 精确落到原尝试；未决时禁止替代请求，明确失败才可受控重试 |
+| 费用来源关联 | 成功实扣对应的来源版本、资金引用、关联结果 | 预估不入池；资金成功与来源关联分别记录；来源投递重试不得重发扣款 |
+| 差异和更正记录 | 来源对象、原事实引用、数量、处置、证据、操作者 | 追加留痕；已交寄事实不覆盖；资金更正受 Finance 独立权限约束 |
+
+数量、费用版本、资金请求和明细关联使用结构化列及唯一约束；JSON 只承载不可变快照、地址或审计补充，不承担全部数量关系。每个节点命令使用订单版本、幂等键和请求摘要；锁定订单后复验来源、可执行动作及最新资金状态，再原子提交事实、审计和业务 Outbox。
+
+通用 `finance-fee-sources` 接口不允许人工创建、提交、审核、调整或作废采购费用来源；采购收费与更正必须从采购节点进入，实扣成功后才由内部已结算发布入口关联来源，防止绕过节点形成第二笔收费。
+
+采购费用记录沿用 `ll_overseas_procurement_fee`，以 `purpose + fee_item_code + fee_version` 在订单内区分确认版本；原币、汇率、实际 CNY、核定情况和资金身份保存在同一不可变费用版本上。`ll_procurement_wallet_attempt` 按 `fee_id + attempt_no` 和唯一 `command_event_id` 保存每次请求。预估与实际国际运费是独立费用事实，实际费用可引用原预估的资金身份；退款用独立费用业务号引用原成功实扣，不能改写原费用。
+
+独立新发生费用通过 `fees/additional` 由 `finance-adjust` 权限登记，必须关联已购买订单、本单费用凭证及真实业务日期，以新业务日汇率和独立费用号处理；不覆盖原费用。费用版本记录 `confirmation_origin`（BUSINESS / FINANCIAL），资金重试沿用该入口权限。普通核费首次成功确认后只能引用已有有效版本，新增费用与失败替代由财务入口处理；未交寄时重新确认完整费用清单，已交寄时不改写原履约终态。
+
+金额在扣款前核对采购台账、钱包和两端费用来源的共同存储边界；费用来源为 DECIMAL(20,6)，单笔原币及 CNY 金额最多 14 位整数、业务输入保留 2 位小数。金额目标快照使用台账范围，正差额仍须满足单笔费用来源范围。购买金额不满足资金链容量时保留真实购买事实并显示待处理，不发起扣款。
+
+
+单批节点事实由 `ll_procurement_flow` 按采购订单唯一保存；`ll_procurement_command` 保存节点请求摘要、幂等键和内部依据；预算上限变化由 `ll_procurement_budget_authorization` 留存前后金额、币种和客户凭证。购买事实与货款核定标记分开，资金结果仍从费用版本读取。节点 API 见 Lastleg `src/main/resources/openapi/procurement-fulfillment-v1.yaml`，下单与审核基础 API 继续维护在 `overseas-business-v1.yaml`。
+
+实物明细由 `ll_procurement_receipt`、`ll_procurement_disposition`、`ll_procurement_manifest`、`ll_procurement_carton` 和 `ll_procurement_carton_source` 保存；更正只停用原实收/处置并追加新记录，历史清单及来源不删除。`ll_procurement_shipment` 以订单及运输段建立唯一约束，`ll_procurement_shipment_item` 保存当次逐箱件数、货物来源、测量、面单和运单快照。
+
+面单版本由 `ll_procurement_label_set` 和 `ll_procurement_label_item` 保存，预估核对通过 `ll_procurement_estimate_review` 显式关联面单版本与有效预估费用。制单不修改资金，贴单不产生发运。每次交寄在订单行锁内复验当前确认清单、全部可寄原箱、实收来源和包装摘要；新面单不继承旧贴单。国内 `ll_procurement_repack` 仅允许原箱的一对一包装新版本，件数仍取原箱有效国内实收；即使新箱尺寸相同，换包装记录也使旧国内面单失效，并清除整单核费确认标记，保留已发生扣款供重新核对。
+
+国际寄件姓名、电话及地址通过 Warehouse 的既有公共海外收货仓和有效仓详情接口读取，须有唯一作业地址及完整联系人，不由浏览器覆盖。两段交寄各自冻结收寄快照；国内寄件资料承接原国际段国内收件资料，最终客户地址变更须关联本单客户确认凭证。面单文件按本单 LABEL 分类校验，图片仅对应第 1 页，PDF 明确逐箱页码。
+
+运输动作权限独立采用 `estimate`、`apply-label`、`ship-overseas` 和 `ship-customer`；`label` 只维护面单，不能同时获得冻结或交寄权限。上述权限均在既有采购权限前缀下，沿用现有平台角色，不引入新岗位类型。
+
+Finance 账户操作统一按“客户账户行 → 原冻结/原扣款行”顺序加锁。结算实际金额保留原冻结金额，实际扣款取关联的 CONSUMPTION 流水；退款用独立 REFUND 流水引用原扣款，不能篡改原结算状态或使用充值类型。退款回补复用现行现金/授信归还计算，不恢复过期授信。
+
+### 10.2 资金指令和来源合同
+
+- `FREEZE` 预留金额；`SETTLE` 结清明确实际费用的全额冻结；`RELEASE` 释放有效冻结。
+- `SETTLE_ACTUAL` 在原冻结业务身份上携带最终正额 CNY 金额，在 Finance 单事务中补差或释放余款。结果 amount 表示实际扣款，不能回传原预估。零实际费用使用 RELEASE。
+- 正额货款、关税、国内运费和其他费用，由采购按费用用途在 FREEZE 成功后自动发送 SETTLE；预估国际运费绝不走该自动分支。
+- 资金成功回执必须能定位原请求、客户、费用版本及实际流水；费用入池引用这笔已成功的资金事实，Finance 同客户校验实际金额后标为已结算。不得仅凭展示单号或预估金额认领资金。
+- 退款业务命令需包含原成功扣款引用、独立退款编号、金额、原因和授权证据。相同退款编号换请求键不得再次回补，累计退款按原扣款串行核验。
+- 已确认费用的资金请求状态与费用来源状态分开。节点准入同时检查资金终态和来源关联，不以 Outbox 已发送或 HTTP 已确认作为全部完成。
+
+国内核费以整单节点命令确认：实际国际运费、关税、国内运费分别选择新核定值或本单已有有效费用版本；其他费用明确为不适用或逐项核定。不适用不创建虚构收费行，重新核对引用原版本不重新扣款，也不能通过省略有效费用隐藏原收费。确认时间与实际资金完成状态分别保存，寄客户仍逐笔校验资金及来源关联。
+
+费用链更正使用 `ll_procurement_fee_correction` 保存正确原币总额、原汇率及月份、目标 CNY、确认前净实扣和差额，`ll_procurement_fee_correction_item` 关联本次产生的每笔追加或退款。输入必须是原实际费用链根；同链存在未决或尚可重试的旧调整时拒绝新目标。正差额建立独立 CNY 费用，差额费用自身汇率为 1，目标原币及原汇率完整保留在更正快照，避免由人民币分差反推原币造成误差；负差额按本链成功消费的可退余额逐笔关联，不把多次扣款合成一笔虚构原扣。退款仍由 Finance 原子校验累计上限。
+
+未实扣费用的替代核定使用独立 `fees/{feeId}/replace-failed` 命令，要求财务调整权限。仅最新实际费用版本已明确失败、终止重试且有效冻结已释放时可替代；未决、已实扣或已有后续版本均拒绝。新费用沿用原币、业务日及汇率快照，以新的资金业务标识扣款，并由更正记录关联前后版本；原购买事实不覆盖，替代货款仍核验客户预算。普通核费不能绕过该入口重建历史费用，财务替代版本的失败重试也使用财务调整权限。
+
+普通核费权限不能追加或退款。明确失败后的重试按原费用用途分别检查购买、预估、核费或财务调整权限；终止失败版本、目标更正及退款统一要求财务调整权限。所有命令明确携带订单版本及幂等键；缺失版本拒绝，原请求重放不能改变金额。履约已寄客户或异常关闭后，有据财务更正保留原终态，不改写历史发运。
+
+### 10.3 服务和接口组织
+
+Lastleg 在现有 `procurement/` 内按购买、实收装箱、运输、费用、文件及异常划分职责；统一订单查询组装详情和动作资格，不新建服务或通用流程引擎。Finance 只处理本服务账务与来源关联；采购不能直接写 Finance 数据表。
+
+采购列表只返回订单基础信息、采购数量和履约状态，不返回旧 `inboundQuantity/outboundQuantity/inventoryQuantity` 库存式统计。删除旧 `outboundDetails` 及订单级两段承运商/运单字段；实际承运商、运单、交寄数量与时间从逐箱面单和不可变交寄记录查询，不由旧 JSON 或静态订单字段推导。初始化结构与模型同步移除这些废弃字段，实际环境结构清理由发布范围单独核对。
+
+沿用现有平台和客户采购 API 根路径。新增操作使用明确节点命令，包含确认购买、登记/完成实收、保存/确认清单、面单维护、预估确认、贴单、两段交寄、核费、预算授权、更正及关闭。通用 PATCH 移除能绕过这些命令修改数量、运单、状态和资金的字段；不保留旧编辑行为回退。
+
+平台详情返回服务端计算的 `actions` 与动作阻断原因，以及采购事实、箱明细、费用版本和历史。客户端使用单独的详情 DTO，仅返回第 3.5 节允许的字段，不透传平台附件、内部备注或原始资金错误。内部 ID 只用于程序关联，用户界面以采购单号、箱号、运单及费用业务编号展示。
+
+Admin 采购保留当前独立列表/详情/编辑路由，具体操作承载按适用原型核对；Client 将采购专有详情和下单逻辑从三类业务共用组件中分离，本土卡车和散板不接受采购新增状态或字段。权限按第 5.1 节逐动作同步 Controller、IAM 种子、API 合同与前端。
+
+异常控制保存在 `ll_procurement_control_note`：更正说明关联本单购买、实际仓、实收或交寄对象及 EXCEPTION 凭证，阻断与解除分别记录，不覆盖原说明。实际仓在已有箱明细前可受控更正当前有效仓，并保留原仓快照及原实收；已有后续实物或已结束时只追加说明和阻断，不能将货物重新归属。真实到货仍可记录，正式装箱、预估、核费和交寄校验未处理阻断。
+
+异常关闭由 `ll_procurement_closure` 与 `ll_procurement_closure_item` 留存客户停止履约凭证、财务结论、对客摘要和每份剩余货物的去向。服务端按购买未达、原国际箱在途未达、有效实收合格/破损/多货计算待处理来源，扣除既有有效差异处置；已国际交寄的海外合格实收不再重复计为剩余货物。提交须逐来源足额覆盖且有证据，全部资金及来源关联处理结束后才能关闭。关闭不改变原购买、收货、交寄或资金事实，不新建退款、退货物流或零数量发运。
+
+平台既有采购详情 GET 返回 `ProcurementQueryService.PlatformView`，聚合客户视图、内部购买事实、实收装箱、运输、费用/更正、异常、文件、操作记录及动作资格，页面无需逐块发起详情请求。交寄按钮的阻断原因复用实际交寄的状态校验；所有写入仍在订单锁内重新校验，详情上的可执行状态不能替代提交门禁。客户既有详情及创建响应使用独立 `CustomerView`，不再从平台详情动态删字段：只输出已确认箱明细、两段实际运单、预算/费用结果和专门填写的对客摘要，不返回内部附件、原始异常说明、审计内容和资金引用/诊断。
+
+平台运输快照分别返回 `overseasCargo` 和 `domesticCargo`：前者为海外清单及原实收分配，后者按国内有效合格实收计算件数并使用最新一对一换包装的箱规、重量和包装记录引用。面单与交寄页面使用该权威结果；不能从海外旧箱规或采购总数推定国内可寄货物。客户 DTO 仍使用独立允许字段，不透传内部来源引用。
+
+### 10.4 开发与验收顺序
+
+1. Finance 原子实际结算、原扣款退款、费用来源资金关联及其事务测试。
+2. 采购数据结构和命令合同，下单、审核、预算授权、购买与货款闭环。
+3. 海外分次实收、差异、装箱版本、面单和预估冻结、贴单与整批交寄。
+4. 国内分次实收、换包装、费用核定、实际结算和寄客户。
+5. 受控更正、追加、退款、取消和异常关闭；客户端全节点和费用展示。
+6. 全链路定向回归、API/权限/Mapper/SQL 合同检查，匹配版本部署后执行真实 HTTP 和两端页面验收。
+
+各节点同时交付服务端行为、Admin 操作、Client 展示及直接受影响测试，不以“接口存在”代替完整操作。资金基础测试应覆盖账户、冻结、流水、审计及幂等记录同事务回滚，以及不同请求并发处理同一冻结/原扣款。
+
+页面验收使用 1920×1080、100% 缩放。列表和详情按实际 Network 记录请求数：检查重复加载、逐行附加请求、重复提交、无限重试和资金处理中无界轮询；以具体页面操作和请求证据判断，不臆定所有页面统一的请求上限。本轮用户已明确授权内置浏览器登录并自动检查样式与交互，适用于本次采购流程验收。
+
+
+### 10.5 客户端页面实施核对矩阵
+
+本次页面依据为本需求第 3、5、10.3 节和现有正式路由。客户端栏目原型 `docs/悦/柏悦物流客户端/柏悦物流客户端-栏目架构图.html:977` 只定义“海外采购”业务入口，未定义新履约字段布局；不能据此宣称已有完整页面原型。按本轮“首版简单、后续可扩展”的开发授权，保留已确认独立页面承载及现有工作台视觉，扩展本次业务分区，不新增客户审批或内部文件入口。
+
+| 页面 | 操作 | 原型/当前确认依据 | 当前实现与承载 | 本次结论 |
+|---|---|---|---|---|
+| 采购列表 | 查询、分页、进入详情 | 栏目原型行 977；`cross-border/routes.ts` 的采购列表及详情路由 | 共用 `BusinessOrdersView.vue` 的 QueryToolbar、DataTable，操作列在左 | 保留表格和查询布局；使用采购履约状态，去除采购库存含义的旧展示；详情通过正式路由打开 |
+| 采购新建 | 新增、提交、取消 | 需求第 3.2、3.5、10.3 节；`cross-border/routes.ts` 的 `cross-border/procurement/create` | 已有独立新建路由，旧共用列表又能切换内部新建模式 | 统一由既有独立新建路由承载；明确单商品、预算和最终收件资料，白底分组表单，桌面短字段三列；取消返回列表 |
+| 采购详情 | 查看、刷新、返回 | 需求第 3.5、5.2、10.3 节；既有 `cross-border/procurement/:orderNo/detail` | 独立页面、返回列表、状态及四列描述网格 | 沿用独立页面及四列资料区；增加节点时间、已确认箱清单、两段实际运单、费用及对客异常摘要；每次加载一个聚合详情请求，不自动轮询 |
+| 采购详情 | 编辑、审核、核费确认、取消订单、文件预览/下载 | 需求第 3.4、3.5、5.1 节 | 客户本次无对应平台操作权限 | 不新增；客户通过客服提出变更或取消，不开放内部面单、采购/费用/沟通凭证 |
+
+新页面按 1920×1080、100% 缩放核对。该矩阵是实施依据，不代表已经完成运行环境视觉或交互验收。
+
+
+### 10.6 平台页面实施核对矩阵
+
+按本轮用户“先修正偏移项”的要求，采购详情首屏只展示当前有权限且可执行的常规履约操作；预算/仓库更正、财务调整、取消及异常处理收纳在“更正、财务及异常处理”分组，费用更正草稿也在该组。其他不可执行的常规节点以可展开的节点及原因列表保留，不铺满首屏禁用按钮。原请求未决提示与原请求恢复入口仍直接显示，不因折叠分组隐藏；服务端资格、权限及业务门禁不变。
+
+平台原型定向入口为 `docs/悦/货代SAAS平台后台/prototype-src/modules/07-overseas-business.html`，其中采购列表及独立编辑页承载保留；旧原型中的数量、运单和费用通用编辑方式按本需求第 3、4、5、10.3 节收敛。新增节点采用现有详情页内分区及独立操作弹框，沿用 Admin 高密度公共样式，不将原型旧字段当作新节点操作的授权。
+
+| 页面 | 操作 | 承载与变更边界 |
+|---|---|---|
+| 采购列表 | 查询、分页、查看、编辑 | 保留列表及独立路由；操作列在左，使用实际履约状态；不将采购台账展示为 WMS 可用库存 |
+| 采购独立编辑 | 维护内部备注、保存、取消 | 保留独立编辑页、三列只读订单摘要及备注区；只提交订单版本和内部备注，保留未保存保护及版本冲突提示；不在此修改购买对象、仓库、数量、箱单或运单 |
+| 采购详情 | 查看、刷新、返回 | 单次聚合详情请求，分区显示订单、履约、费用、文件及内部历史；不自动无界轮询 |
+| 采购详情 | 审核、购买、预算授权、取消 | 各自独立操作弹框；审核通过必须选择有效海外收货仓，真实购买和资金确认分开呈现 |
+| 采购详情 | 分次收货、差异处置、完成收货、装箱、换包装 | 节点弹框配结构化明细表，显示原实收或原箱来源；不使用自由 JSON 输入，不将保存等同节点完成 |
+| 采购详情 | 面单、预估核对、贴单、两段交寄 | 面单逐箱关联；预估冻结、贴单、实际交寄独立提交，展示服务端阻断原因；文件使用受控上传和下载 |
+| 采购详情 | 国内核费、重试、费用更正、退款 | 普通核费和财务调整分别控制权限，逐项展示核定值、冻结、实扣及来源关联；待处理资金不能显示已结清 |
+| 采购详情 | 更正说明、解除阻断、异常关闭 | 保留原事实，以来源、凭证和去向形成结构化记录；关闭前明确实物与资金处理结果 |
+
+以上为页面实施边界，不表示各操作已经开发、部署或通过浏览器验收；运行验收仍按第 10.4 节逐项核对。

海外仓业务/预约工作日历V13变更说明.md

@@ -0,0 +1,203 @@
+# 预约工作日历 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天。
+- 到港优先实际到港，缺实际时采用预计到港。计划到仓默认在该到港当地日期上加两个自然日，跨月和夏令时仍按日期加两天，不补造具体时刻。人工保存的整柜时间优先，已有入库计划的冻结时间保持；尚未人工维护和未建计划的默认日期随到港事实变化。预约日历“计划到仓”与清关提柜列表、详情“预计到仓”共用该日期规则，默认值显示日期并标明“默认/默认推算”，不补零点。默认日期由 Lastleg 统一读取 Firstleg 权威到港来源后解析，清关提柜、日历及生成入库计划共用 plannedDate/isDefault；读取时不写尾程订单，生成入库计划时冻结该日期，不补造零点，也不充当实际到仓；读取失败或已有计划但时间不一致时，不以默认日期掩盖缺失。人工调整复用整柜预计到仓命令、原编辑权限、版本及幂等键；已有入库计划后仍不可改。
+- 排车仅指海外仓送往 FBA/客户仓的真实整车排车主单，一张主单中的多客户只展示一次；已发车按实际起运仓当地日期，未发车按计划日期，取消主单不列入活动安排。日历返回真实排车单号并进入排车详情；独立旧车次不作为日历来源，也不得将内部车次号当排车号拼接路径。读取沿用排车列表权限；从详情可返回原日历日期与月/周视图。港口提柜送海外仓不作为排车类型。
+- 还柜未完成按原业务截止日期提醒，完成后按实际还柜日期展示；日历不独立计算或改写还柜状态，登记进入原货柜业务。
+- 用户随后明确恢复日历顶部“新增预约”：本次先支持FBA，普通客户仓不在本次范围。居中弹框选择已有货物，核对真实来源后复用原预约表单与保存接口；同起运仓、同目的FBA仓可跨客户合约，保留原写权限、版本/幂等、未知结果重试及未保存保护。货物查询栏支持可搜索、可清空的目的FBA仓下拉框；选项来自同权限范围的权威美国FBA目录，不从当前分页推算。提交查询后回到第一页，翻页沿用目的仓条件，重置恢复全部目的仓；跨页已选货物仍保留并执行同起运仓、同目的仓校验。保存成功显示真实预约编号及内容，不自动创建车次，不增加第五类日历或手工编造到港/还柜等事实。
+- 平台新建及重新登记 FBA 送仓预约时填写已取得的外部约号，直接保存正式确认，不再提供“先保存安排，等待对方确认”选项。确认开始、结束时间改为可选；预约列表的新增窗口不再显示这两个输入及其夏令时时差输入，未提供的确认时间保持为空，不从计划日期推造。其他原业务入口补充真实确认时段时仍执行地区时区、夏令时和起止顺序校验；已有取消、替代和只读记录仍展示真实历史状态。货物核对自动展示并带入有效货件号或追踪号：已补录的非空核实值优先，未补录货件时采用同客户原订单资料，只补过箱数的记录不得遮蔽原有编号；原资料确实缺失时仍须补齐。客户、来源版本、目的仓、货物完整性与外部约号唯一性校验继续执行。
+- 入口移除全局工作待办、流程筛选、负责人分派、跟进、复核、责任交接，以及货物核实/分批/共约/共车编排入口；这些原业务在相应模块继续处理。仍由其他业务页面实际使用的精确来源或事项深链可以打开原业务表单，不恢复旧全局待办及筛选协议。
+- 排车日历同时返回各排车单货物快照中的关联集装箱号，以及货物通过同客户真实尾程订单关联的原装柜事件中的柜次短号（如 D1821），分别按单去空、去重；同车多个完整柜号、柜次短号均可在当前日历范围搜索，支持忽略大小写的包含匹配，仍只展示一条排车安排。没有装柜来源时不推测短号，也不依赖当月到港记录拼接短号。柜号只作检索和展示，不改变客户归属、货物数量或排车状态。详情明确展示起运仓时区及当地计划出发时间；北京时间与美国当地日期可能跨日，不把浏览器日期用作日历归属。
+- 缺权限、来源失败或缺时区明确提示数据范围不完整，不能显示为全部完成或完整空日历。未能定位日期的排车提示具体排车单号和原因，避免误认为当前搜索的单据缺资料。未知日期保留未定，不用浏览器当前日期、内部 ID 或假数据补齐。
+
+代码与自动检查、部署、真实 HTTP 及人工视觉验收分别判定；本次 UI 目标仍为1920×1080、100%缩放，用户截图确认后才记录视觉通过。
+
+确认日期：2026-10-16。用户已确认 V13 原型，并要求按现有开发分工继续实施。本文是本轮产品行为、业务约束与验收场景的正式变更依据；确认需求不表示业务代码、部署或真实环境验收已经完成。
+
+接口和唯一文件写者继续由[开发协作契约](预约工作日历开发协作契约.md)维护。本文维护业务规则，不另建开发进度台账；实现进度由“预约”开发总控维护既有检查点，部署与整体验收事实仍归环境主契约。早期[优化方案](美国预约管理统一总览与优化方案.md)及 V11/V12 评审记录用于追溯，冲突时以本次确认和现行正式契约为准。
+
+## 1. 确认范围与原型基线
+
+本轮目标是：船已开后，运营从“预约管理 → 预约列表”进入“预约工作日历”，能看到所有应办事项，包括未预约、未定日期和变化后尚未处理的事项；每条工作直接给出当前可执行的下一步。
+
+- 日历为默认首屏，提柜、接仓卸柜、送仓/FBA、用车、还空五类可勾选；日期格定高，按类型汇总，不随事项数量无限堆叠。点击数量查看并操作明细。
+- 全部待办、今日需跟进、超期、未定日期、需复核不随日历月份、流程或类型筛选而遗漏。不同待办集合允许重叠；同一事项在一个结果集中只出现一次。
+- 支持海外仓中转分批和整柜直送，支持不同客户同起运仓、同目的仓共用真实车次。多客户共车是已有业务能力，本轮重点补齐统一操作、变化后的续办和完整跟进。
+- 不把本轮扩大成完整车队、库存或费用模块重构；不增加自动向仓库/车队发送预约、取消通知的承诺。登记联系结果与对方实际确认是不同动作。
+
+已确认原型：`C:/Users/BY-OY/.codex/visualizations/2026/10/14/01a13a8d-e968-7962-906b-1a514792d921/appointment-calendar-guided.html`，页头 V13。确认时 SHA-256：`61902e410be755aa9cbf9fcfaa9d393bfa49dd8d592cd8773af5396e78c29836`。该文件为交互依据，不是生产 API、状态机或数据库结构；原型中的演示字段名、固定负责人、固定日期及示例数据不得直接当成业务合同。
+
+## 2. 对象、数量与客户归属
+
+| 对象 | 正式规则 |
+| --- | --- |
+| 货物来源 | 每条保留客户、稳定来源键、目的地、业务票号、货件/追踪号、柜次及核实数量/版本。沿用原 `ORDER` / `BOOKING` 来源身份，不因建订单、分批、换车而产生来源别名。 |
+| 送货需求与批次 | 未约、取消安排、日期未知都不消灭仍需送货的需求。批次有稳定身份及版本；移车或重新预约不重新占一次货量。只有真实分批/合并才调整分配，并保留旧批次到当前批次的去向。 |
+| 对外预约 | 预约确认号、有效覆盖范围、确认时段与预约身份分开保存。一个共同预约可覆盖多个客户的批次；不能用相同文本约号代替明确的共同预约关系。 |
+| 运输 | 一个真实车次可承运多个客户、多个批次；各客户的排车/货物归属保留。送仓预约与车辆安排分别确认，不能互相冒充。后送用车待办不等于已经创建实际车次、锁定托盘或承运资源。 |
+| 工作事项 | 关联权威业务对象，承担展示、跟进、复核和下一步引导，不再维护第二本可编辑数量账或另一份预约/实际完成结果。 |
+
+按每个“客户＋稳定来源＋目的地”核对数量，而不是只核对总箱数：
+
+`核实可履约总量 = 尚未分配到批次的数量 + 当前有效批次的分配数量之和`
+
+这里的有效批次包含已经实际完成的履约数量，不能因完成后退出待办而再次变成可选余量；已被替代的历史批次不重复计入。后送批次即使没有日期或预约，其货量仍属于该批次，只能从该批次继续分配，不能再按整票新增一遍。逐来源不超分、不为负、总量不丢；未知数量保持未知，不当成 0，也不能未经核实拆分。
+
+补箱数和各票货件号只保存预约货物核实资料，不覆盖原尾程订单；已分配数量不能被核实为更小。客户库存、托盘、订单、费用及对外可见范围仍按原客户隔离规则执行。
+
+## 3. 两条履约流程
+
+### 3.1 海外仓中转
+
+开船后生成/读取本柜应办工作 → 提柜 → 海外仓接仓卸柜 → 各送货批次分别约仓及安排运输 → 真实备货、装车、发车、签收。提柜、接仓卸柜、还空按柜级稳定身份去重，不随客户数、送货批数或车次数重复生成。
+
+实际卸柜完成后，还空按真实条件独立跟进，不等待所有送货批次完成。一柜可以分多批、多车；不同柜、不同客户的货物在符合原业务资格时也可同仓共车。
+
+### 3.2 整柜直送
+
+开船后 → 提柜安排及目的仓收货预约 → 同一运输链直送目的仓 → 真实卸货 → 还空。不得为了直送生成海外仓接仓/入库事项、库存或假卸柜事实。提柜和直送共用一趟运输时只计算一个真实车次，不重复约车；还空可由原车执行或转交明确接手方。
+
+实际目的仓卸货未完成不能登记还空；交接责任不等于已还空。直接送往客户仓且对方无需预约时，保存明确的收货要求，不伪造 FBA 货件号、外部约号或“预约成功”。路线未知时先提供“确认路线”，确认后幂等生成应办清单。
+
+## 4. 多客户同仓共车
+
+1. “与同仓待排货物一起安排”或“按目的仓统一安排”只展示当前有资格的货物。候选以稳定起运仓/目的仓身份及真实业务资格核对，不只比较仓名；已安排或已分配的量不能重复选入。
+2. 从某个后送批次进入时，只预选该批次的当前可安排量；其他客户由操作人明确加选。每票允许填写本次箱数，客户、来源和货件随货保留。
+3. 共车不等于共用仓库预约。可分别保存各客户的预约结果，也可在仓库明确确认覆盖全部所选客户和数量后使用共同预约；页面必须明确显示采用哪一种方式。
+4. 外部约号按目的仓执行既有唯一性规则。共约成员通过同一预约身份引用这个约号，不各自创建重复主单。其他有效预约已使用的约号不能直接填入，冒充该客户已加入共同预约。
+5. 保存后逐客户显示成功、待补资料、关联失败等真实结果，提供下一步；一辆车在日历工作量中只计一次，各批送仓工作分别计数。
+6. 实际车辆、司机、托盘、容量、审核、装载和发车走原 Fleet/Dispatch 资格与命令。原型中的直接登记执行仅表达流程衔接，不替代这些门槛。
+
+## 5. 分批、缺货与后送
+
+以甲 80、乙 160、丁 40，共 280 箱送 ONT8 为统一验收样例；每条场景独立恢复基准，不能将不同演示的数量相加。
+
+| 变化 | 原车 | 后续需求 | 下一步 |
+| --- | --- | --- | --- |
+| 乙整批移出 | 保留甲 80＋丁 40＝120 箱；其预约不变 | 乙 160 箱保留原来源与需求，另期或未定日期 | 乙重新约仓并安排车辆；原车按剩余货量核对后继续 |
+| 乙 100 箱已齐、60 箱后送 | 甲 80＋乙 100＋丁 40＝220 箱 | 60 箱单独后送；没有目标也保留待办 | 可单送，或选择与同仓待排货物一起安排 |
+| 后送 60 再选 40 安排 | 原车仍为 220 箱 | 40 箱进入新批次，20 箱仍待排；乙 100＋40＋20＝160 | 原车客户卡片同时列出两份当前去向，各可直接继续 |
+| 后送 60 与另一客户 40 共车 | 原车仍为 220 箱 | 新车共 100 箱，客户和来源分别保留 | 分别/共同约仓后确认新车，按各客户实际执行 |
+
+“本次先送量”允许为 0，表示该客户全部移出原车留待后送；不得强迫留一箱。先送量等于全部原数量时，没有后送分配，不额外新建空批次。部分改变已经确认预约的货量，必须取得仓库对保留量和移出量的明确处理结果；剩余货物是否备妥按实际核对，不因仓库同意而自动标记货齐。
+
+后送目标日期可空，但必须保留负责人和跟进入口。原车客户卡片追踪分配/替代关系直到当前批次；全量再分配后直接显示新安排，部分再分配后同时显示仍待排的量和已分配的去向。不能显示失效的“0 箱待办”，不能只在历史文字中记录去向，不能将同一后续批次重复列出。
+
+## 6. 改期、取消与影响范围
+
+普通改期、取消、缺货移出用于尚未实际执行的安排。车辆已经发车或相关货物已经执行时，进入原运输异常处理，不提供普通移车操作来抹掉事实。
+
+### 6.1 仅处理某个客户
+
+- 默认明确展示本客户、原车、货量、其他客户及是否共用预约；操作者选择本客户另期、取消本次安排或本次先送部分数量。
+- 确认前保留原安排。已有有效预约，尤其是共同预约时，须明确仓库同意本次调整范围；未收到回复先记录待确认，不能把沟通中状态当成取消/改期成功。
+- 确认后只移动该客户/该部分货物。其他客户的约号、确认时段和客户归属保持不变；原车对剩余货量及发车时间核对一次。车队已确认原时间可继续时，不无故要求其他客户重新约仓。
+- 待确认变化进入持续待办；涉及当前装载或预约有效性尚未解决时，原车不能直接发车。保存输入与已确认的信息，重新进入直接续办；不能用“关闭复核”跳过未解决的业务条件。
+- 原车无任何有效货物且尚未执行时，经原车辆业务取消/调整处理后关闭相应运输工作并保留历史，不留下空车待办。不能据此取消其他客户或其他仍有效的车次任务。
+
+### 6.2 整份共同预约变更
+
+- 页面明确区分“仅本客户”和“整份共同预约”，展示所有当前覆盖客户、数量、预约和关联车辆。以服务端当前有效成员为准，不能靠外部约号文本相等推断范围。
+- 整份改期：所有覆盖成员更新为同一已确认的新时段；相关车辆核对新收货时段是否可达。无实际变化的再次保存不重复产生复核。
+- 整份取消：旧预约失效，保留旧计划、确认信息、取消原因和历史；当前确认及已经失效的目标日期从活动安排中清除，未重新确定的进入未定日期。全部未完成货物需求保留，各关联车辆列为待核对。
+- 已取消的预约不能选“保留原预约”直接恢复有效。车辆原安排是否仍可执行可单独核对，但发车仍须所有相关收货/备货条件成立。
+- 真实变化只影响直接关联且已经安排的事项；尚未安排的继续待安排。复核动作本身不再触发另一轮复核；处理旧影响版本不得清掉后来产生的新变化。
+
+### 6.3 取消后的占用边界
+
+本轮“取消”指取消本次预约/运输安排，不是取消订单或客户撤销全部运输需求。
+
+失效预约释放其有效预约覆盖和绑定；仍需履约的批次数量分配继续存在，或在同次变更中转到明确的后送批次。不能把同一箱数同时留在原批次并重新作为整票可选余量，也不能先清空需求再等待以后人工补建。已完成数量保持不可再次分配。
+
+取消预约不回退库存，不自动注销整辆车。已有正式排车、托盘或运力占用时，由其权威业务按真实关联调整；工作事项仅读取结果。恢复/重新预约仍重新核对来源、当前分配、版本和唯一性。
+
+## 7. 移出后的重新预约与整组重约
+
+### 7.1 单客户或后送批次续办
+
+结果页直接提供“继续给本客户约仓”和有资格时的“与同仓待排货物一起安排”。从未定日期、搜索或原车客户卡片再次进入，也到达同一份当前需求。
+
+单送路径为：核对货物 → 记录仓库回复/确认 → 继续安排本批车辆 → 核对真实备货条件 → 原业务发车、签收和运输完成。未约成可以保存计划和联系结果，不必编造时间；已取得确认后直接进入车辆安排。确认后的货物不能重新从“待排货物”入口新增一遍；车辆关联沿既有安排继续。
+
+重新预约不会重新生成一份相同货量。完成后退出未完成待办，原批次和运输记录仍能查到；其他尚未完成的后送、原车或还空工作继续保留。
+
+### 7.2 整份取消后的重新预约
+
+1. 提供“重新预约这组货物”，展示本次仍需重新约仓的客户、批次与数量。已退出、已单独另约、已完成或正在处理其他变化的成员不被静默纳入；页面说明其当前去向。
+2. 可以一次填写一个共用的新预约，也可以一次填写各客户独立预约。共同预约必须有仓库明确确认的客户和货量覆盖依据；分别预约不能通过重复填写相同约号绕开共同预约确认。
+3. 沿用现有批次及可继续使用的原车，保存新有效预约关系；不重复分批、不重复占量、不仅为重约再创建一辆车。旧取消关系留历史，新共同预约使用新的有效关联身份。
+4. 退出客户不能直接填写其他客户仍使用的旧约号，生成不同时间的孤立预约。若确需加入已有共同预约，必须经显式范围调整和仓库确认；普通填写约号不完成该操作。
+5. 保存后主要下一步是“核对本车发车安排”。核对全部当前客户的收货时段和车辆条件；不能让车辆先于尚未完成的重约被标记可执行。后续再次整份改期/取消只作用于新的有效覆盖范围。
+
+## 8. 未定日期、跟进与操作简化
+
+- “没有作业日期”和“没有跟进日期”是不同含义。有跟进日仍可属于未定日期；不能把催回复日期填成送货日期。
+- 日期留空时保留需求、负责人、联系记录及下一步，显示在全局未定日期/全部待办；取消、分批、部分失败不能让它消失。缺负责人或下一次跟进安排时明确提示补齐，不假定原型中的固定人员是生产默认值。
+- 日期有目标但未约成时，日历按目标展示并标明未落实；确认时间、目标窗口和实际时间分别保存。实际发生后按权威实际日期展示，改期不移动历史事实。时间、时区、跨日、DST 和缺失原事实的处理沿开发协作契约第三节。
+- 每个结果页优先给一个主要下一步，其他去向为明确次要入口；缺货在车辆执行入口可直接打开对应客户的“调整本次装载/移出本车”，不绕到其他客户或目的仓总列表。
+- 未落实且只涉及本批货物时展示普通计划表，不展示多余的共车变化表单；独立车辆按钮称“继续安排本批车辆”，实际共车才称共用车辆。
+- 返回保留原日期、柜、批次、筛选、分页和原事项上下文。旧批次已全部转入新安排时直接到新安排；历史仍可独立查看。
+
+## 9. 失败、重试与权限
+
+以下是正式实现和集成验收要求，不能用原型浏览器检查代替证明：
+
+- 按原来源核实量、批次、预约范围及车辆关系版本校验。并发编辑、分批或共车成员变化时拒绝过期提交，保留用户输入，重新展示实际范围；服务端保证不超分。
+- 同一用户操作使用持久化幂等身份；同键同内容返回原结果，异内容拒绝。超时/断网导致结果未知时沿原请求查询或重试，不自动当失败新建批次、预约或车辆。
+- 货物已保存但关联车辆失败时，返回成功批次及准确失败步骤；成功货物保持已占用，重试只补失败步骤，不能重新建批/建车，也不能把已退出的客户重新挂回原车。
+- 一次调整中原数量、后送数量、去向和待办必须一致。跨业务步骤未全部成功时明确显示尚未完成的部分和下一步，不宣称全部成功；不得产生既无原需求又无后续需求的窗口。
+- 平台列表权限包含详情只读，写权限由各权威业务核验；多客户管理仅在授权平台范围内进行，客户侧只能看自己的货物。无权限、来源不可用、校验冲突均给明确原因，不能伪造成功或“0 项”。
+- 真实备货、托盘、装载、发车、签收、还空及运输完成仍由原业务事实决定。通知或联系记录不能代替这些事实。
+
+## 10. 开发接口交接与唯一写者
+
+不复制旧接口、不建立前端数量账、不直接照搬原型对象。已有工作事项 v1 继续使用[开发协作契约第三节](预约工作日历开发协作契约.md#3-工作事项-http-接口-v1)；本轮新增语义由真实业务生产者先补 DTO/OpenAPI 与定向测试，再由消费者接入。精确 HTTP 路径、字段与错误码以生产者冻结的真实合同为准，本文不虚构已可用端点。
+
+| 必须交付的语义 | 生产者与消费边界 |
+| --- | --- |
+| 当前批次逐来源分配、剩余量、全部/部分再分配去向、版本 | 预约核心提供权威数据；工作事项只读关联，前端据其显示当前去向，不凭历史文字推断。 |
+| 单客户/整份共约变更的当前范围、旧安排、新安排、受影响客户/车辆、未完成原因 | 预约核心与原预约写者统一业务命令和版本；工作事项返回准确受影响事项与复核版本。 |
+| 整份取消后的待重约成员、已排除成员及原因、共同/独立重约结果和新的有效预约关联 | 预约核心主导合同；保留原批次及运输关系，消费者不能自行造共同预约身份。 |
+| 幂等结果、逐步骤成功/待补/失败、后续目标及可重试动作 | 各命令生产者返回真实结果；前端保留输入并继续失败步骤，工作事项不制造成功兜底。 |
+| 允许动作、唯一主要下一步、缺项/阻塞原因、关联与去向 | 工作事项后端提供白名单动作和稳定目标引用；前端映射既有入口/表单。跨域业务写入不能塞进通用“改状态”命令。 |
+
+现有三任务不增加、不更换工作区、不扩大其他业务写权：
+
+| 现有任务 | V13 继续工作 | 依赖及停止点 |
+| --- | --- | --- |
+| “预约” `01a13df2-c639-7560-a3e2-30bc23a579b3` | 开发总控兼预约核心：核对已实现差异，先冻结数量/去向、预约范围、取消和重约合同；协调原预约写者，统一共享文件、检查点及验证窗口 | `InboundFbaAppointmentService` 及核心预约/分批测试已明确交回总控；工作适配和 Dispatch/Fleet 仍由后端专项独占。后续移交须明确唯一写者，不按同文件不同方法并写。 |
+| “工作事项后端” `01a13e1c-9101-7a43-8445-771685ff315e` | 完整待办、未定日期、准确影响集合、复核版本、下一步、真实车辆/预约同步；负责本批已移交的原域适配与直接测试 | 不另建数量分配账；先完成可独立部分，新增核心合同冻结后接入。共享 DDL、IAM、Firstleg 和公共门禁仍归总控。 |
+| “预约页面前端” `01a13e1c-db36-73e3-a231-d6649c51664b` | 按 V13 完成范围选择、后送续办、当前去向、整组重约、结果与失败续办、未定日期入口和上下文；更新直接测试及操作矩阵 | 不猜后端字段、未交付接口不做假成功；先做现有合同可支持的部分，新增写入按冻结合同接入。保留已有页面和弹框改动。 |
+
+精确文件路径、共享文件归属及串行构建窗口沿协作契约第五节。总控负责收集三个任务的差异、接口准备情况和直接验证证据，不能仅转述“已收到”。本轮用户授权文档同步和继续开发；部署、SQL、测试环境写入等不因本文新增授权，已有另行授权由对应开发总控按原范围核验。
+
+## 11. 最小验收矩阵
+
+HTTP 性能门槛（2026-10-16 用户确认）：本预约链路涉及的每个接口、每次验收请求，从客户端发起到完整响应体读取结束均不得超过 1,000ms；同时独立校验 HTTP 状态、预期业务结果和数量/状态事实。不能以平均值或 P95 代替逐请求门槛，也不能把快速返回的同步中、非预期错误或缺少计时当作通过。预期拒绝场景须核对准确业务码，仍计入耗时。保留首次、超时、失败及重试记录，网络超时结果未知时先回查，不能盲目重放写操作；报告标明场景、方法/路径、耗时、requestId/traceId、运行版本及尚未覆盖项。HTTP 通过不代替页面验收，单轮全部达标也不构成任意负载下的性能保证。
+
+| 编号 | 场景 | 必须结果 |
+| --- | --- | --- |
+| V13-01 | 乙 160 箱取消本次安排后重新约仓、配车、发车、签收、结束运输 | 原车甲丁 120 箱及其预约不变；乙来源和数量唯一；完成后待办退出、记录可查。 |
+| V13-02 | 乙 100 先送、60 后送，后送独立执行完成 | 原车 220 箱；乙始终 160；后送未定日期可反复进入直到完成，不重复创建。 |
+| V13-03 | 从后送入口选本批 60，加另一客户 40 共车 | 初始只选 60；新车 100，客户来源和预约结果分开；约仓、发车、各客户签收及运输完成可衔接，原车仍 220。 |
+| V13-04 | 后送 60 仅选 40，另 20 待排 | 原车卡片各显示 20 待排和 40 新批一次，直接可操作；20 持续留在未定日期并可再次安排，乙各批始终合计 160；不显示失效 0 箱或遗漏已分配去向。 |
+| V13-05 | 全部后送量再分配后从旧入口返回 | 直接找到当前新批次及车辆；重复点击/重试不重复占量，历史可追溯。 |
+| V13-06 | 单客户未收到仓库回复；先记待确认再续办 | 原预约保留，输入可续办，相关未解决变化阻止误发车；确认后仅处理目标客户。 |
+| V13-07 | 单客户从共约退出，填其他客户仍使用的旧约号 | 服务端拒绝孤立重约，不改其他成员；正确新约可继续；校验失败保留输入。 |
+| V13-08 | 整份共约改期 | 当前全部覆盖客户一致更新，影响车辆清楚；核对一次，无变化保存不反复复核。 |
+| V13-09 | 整份共约取消并重新共约 | 清失效目标/确认，保留原批次与原车；一次确认覆盖范围，形成新有效关联；再次整份变更按新范围。 |
+| V13-10 | 整份取消后分别重约，或甲先单独另约再办理剩余组 | 独立约号/时段分别保存；已另约甲排除且不被覆盖；车辆核对所有当前时段后才能执行。 |
+| V13-11 | 货没齐，保留量为 0；原车最终无有效货物 | 全部货量继续待办，不强留一箱；其他客户不被移动；无货原车按原业务取消/调整后正确关闭。 |
+| V13-12 | 未定日期关闭后再进、换月、取消类型勾选、返回分页 | 需求和跟进不丢，送仓/用车各按稳定身份显示；下一步及返回上下文准确。 |
+| V13-13 | 部分成功、关联失败、超时结果未知、重复提交、并发变化 | 复用原成功结果，只重试未完成步骤；不超分、不挂回已退出成员，过期版本不能清除新复核。 |
+| V13-14 | 只读/跨客户权限、来源失败、缺时区、跨日与 DST | 权限及时间按正式合同校验；未知/失败不伪造零值、日期或成功；已有真实事实保留。 |
+| V13-15 | 中转多批、整柜直送、还空转交及已发车异常 | 柜级工作不重复；中转还空不等尾程送完；直送无海外仓入库，实际卸货才可还空；转交新车队须重新明确接手，原车队结果不沿用，未落实继续跟进；发车后不走普通移车取消。 |
+
+V13 本地原型已走过多客户变化、后送单送/共车、部分再分配、整份取消重约、约号冲突与返回续办，相关浏览器检查及原有 24 项原型回归通过。可追溯脚本位于原型同目录：`check-v11.cjs`、`check-v12.cjs`、`review-rebook-v13.cjs`、`review-partial-v13.cjs`、`review-v13-shared-rebooking.cjs`、`check-v13-usability.cjs`。这只是交互证据；尤其 V13-13/14 的真实权限、持久幂等、并发、外部接口和完整时区规则仍须生产代码和集成验证。
+
+交付时分别列出业务代码、定向检查、部署清单和待真实验收项；Admin 人工视觉验收按 1920×1080、100% 缩放。不得把原型确认或本地检查通过写成环境已上线、全链已验收。

海外仓业务/预约工作日历开发协作契约.md

@@ -0,0 +1,221 @@
+# 预约工作日历开发协作契约
+
+建立日期：2026-10-15；V13 确认同步日期：2026-10-16。用户已确认 V13 原型，正式业务变更见[预约工作日历 V13 变更说明](预约工作日历V13变更说明.md)。本文继续维护接口、数据归属和文件边界，不重复维护产品规则或作为已实现说明；当前部署与验收事实只维护环境主契约。
+
+本文承接[预约优化方案](美国预约管理统一总览与优化方案.md)，日历首屏、多客户共车、分批后送、改期取消、重新预约与完整待办的确认行为以 V13 正式变更说明为准；不扩展为拼车、车队或海外仓的全面重构。任务身份与唯一写者见[协作登记](../独立任务协作登记.md)。
+
+当前开发总控为用户明确指定的 `01a13df2-c639-7560-a3e2-30bc23a579b3`，负责开发设计、任务调度、接口对齐、共享集成、开发检查点及验证收口；原型对话 `01a13a8d-e968-7962-906b-1a514792d921` 只负责业务梳理、原型和变更文档。用户再次明确：设计确认后交开发总控安排，不由原型对话继续派工或跟踪开发。本文“总控”均指当前开发总控。两个专项保留原范围，精确触点以第五节为准。
+
+## 1. 输入与共同目标
+
+原型只读入口：`C:/Users/BY-OY/.codex/visualizations/2026/10/14/01a13a8d-e968-7962-906b-1a514792d921/appointment-calendar-guided.html`，当前确认交接为 V13，确认指纹见正式变更说明第一节。它承载交互示例，不作为真实 API、数据总量或权限来源。
+
+- 实际开船后，所有必需工作进入统一事项范围，未预约、未定日期也有记录与负责人跟进；不能等创建预约后才出现。
+- 默认进入“预约工作日历”。月格固定高度，提柜、接仓卸柜、送仓/FBA、用车、还空五类勾选显示数量，点击数量进入明细。到港参考单独开关，不计工作量。
+- 全部待办、今日需跟进、超期、未定日期、需复核独立于月历月份、流程和类型勾选；全局统计由服务端计算。明细明确显示其范围，不能把月历条件偷偷带入全局待办。
+- 目标日期、对方确认时间、实际完成时间分别保存。按作业地点时区落日；无日期进入未定日期区，不伪造日期或 00:00/09:00。
+- 主按钮直接给下一步，返回时保留原柜、批次、日期和筛选；查看当前项与跳到前置事项是两个明确入口。
+
+## 2. 数据归属与两条流程
+
+| 业务 | 本轮约束 | 唯一生产者 |
+| --- | --- | --- |
+| 来源/核实资料/数量分配 | 保留客户、原来源、目的地及核实版本；补箱数和各票货件号只写预约核实资料，不覆盖原订单；并发按原来源加锁，总分配量守恒 | 预约核心任务 |
+| FBA 预约申请、确认、取消、分批合并 | 沿原预约写服务执行；取消预约保留工作需求、历史和后续跟进；分批不能只移除原整票唯一约束 | 预约核心任务 |
+| 工作事项/路线/跟进/复核 | 工作关系、未安排需求、责任和操作入口由工作事项模块维护；已有业务计划和实际事实只关联，不另建第二份可编辑数量或预约结果 | 工作事项后端 |
+| 提柜计划和实际提柜/还空 | 以 Firstleg 原业务命令及事实为准 | 预约核心任务协调原域最小适配 |
+| 实际接仓卸柜 | 以真实海外仓/PDA 收货为准，不能由事项勾选完成代替 | 原海外仓业务；本轮只读消费 |
+| 车辆计划、出车、完成 | 以 Fleet/Dispatch 原业务命令及事实为准 | 工作事项后端维护本轮 Lastleg 原域适配及直接消费者 |
+| 客户仓无需预约、还空责任交接 | 保存明确收货要求、责任及交接历史，不生成假确认号、不改提柜承运历史；实际还空仍走 Firstleg | 工作事项后端保存要求和责任，核心任务适配实际执行入口 |
+
+中转：同柜共用提柜、接仓卸柜、还空；每个送货批次独立关联收货预约与用车，可以一柜多批、多车，也允许同一真实车次覆盖多个批次。批次变更不能重复生成柜级工作。实际卸柜后即可按真实条件还空，不必等待全部尾程送货完成。
+
+直送：没有海外仓接仓卸柜事项；提柜、目的仓收货/卸货、运输、还空形成关联，可同车执行，也可转交独立还空。不得调用会建立海外仓库存的 PDA 入库命令来证明直送卸货。现有 Firstleg 还空若只认可海外仓卸柜，核心任务必须补真实目的仓卸货依据及守卫，未补齐前保持明确阻断，不能把事项状态写成完成。
+
+路线未确认：显示一条“确认路线”需求，确认后事务内幂等生成对应清单，并立即可查询。已执行的路线不能通过切换选项抹掉事实；有安排时必须先评估关联影响。
+
+稳定身份：柜级事项用柜次内部标识与类型去重，送货/用车需求用不可变 requirementKey/batchKey 关联。原来源键沿用 `ORDER:` / `BOOKING:`；不得用柜号文本、目的仓名称或可变预约号作为唯一键。未分批阶段先有送货/运输需求；真正分批后以明确的替代关系衔接，旧需求不和新批次重复计数，也不能消失但未生成后续。批次、预约、车次的内部键仅用于关联，界面展示业务号，缺失显示“—”。
+
+事项完整来源不能直接复用目前仅 FBA 的 cargo 查询或排除完成订单的 containers 查询。新后端负责独立覆盖核对：已开船无海外仓绑定、非 FBA 目的仓、未知路线、货已送完但柜未还空均须保留。不得靠前端翻完所有页拼全局统计；GET 不隐式写库。生成/同步须有可验证的服务端幂等入口，不能依赖用户先打开某个柜。新增 Firstleg 提供端触点先交总控确认精确文件后由核心任务实施。
+
+## 3. 工作事项 HTTP 接口 v1
+
+平台路径前缀：`/api/platform/v1/last-leg/appointment-work`。沿用项目 ApiResponse/PageResult、鉴权与分页约定；平台列表权限包含详情只读。新后端同时维护 `appointment-work-v1.yaml` 与 Controller/DTO，不通过多路径或别名兼容旧草案。
+
+| 方法与路径 | 输入 | 输出与口径 |
+| --- | --- | --- |
+| GET `/calendar` | `from`、`to`（当地日期，均包含）；可选 `flow`、重复 `types` | `CalendarResult`，整个区间的日聚合，不能按明细分页结果算数量；最大 62 天 |
+| GET `/summary` | 无月历筛选参数 | `Summary`，当前权限可见的全部活动事项；跨月份、类型和路线 |
+| GET `/items` | `view=ALL/FOLLOW_TODAY/OVERDUE/UNDATED/REVIEW`，`page`、`size`；明细可显式传 `date/flow/types/containerBookingId/bucket/keyword` | 项目分页结构的 `WorkItem`；全局卡片调用不传月历条件；无 date 的 ALL 为全部未完成事项，有 date 的 ALL 包含当日已完成事项；bucket 对应日历互斥统计桶 |
+| GET `/items/{workItemKey}` | 稳定事项键 | `WorkDetail`，当前项、前置/后续、原业务引用和历史 |
+| POST `/items/{workItemKey}/commands` | `command`、`expectedVersion`、`idempotencyKey`、判别式 `payload` | `{item, affectedWorkItemKeys}`；成功后刷新摘要与当前日历；版本冲突 409，刷新后保留用户输入 |
+
+`flow` 枚举 `TRANSFER/DIRECT/UNKNOWN`，省略为全部。`types` 为 `PICKUP/WAREHOUSE_RECEIPT/DELIVERY/TRANSPORT/EMPTY_RETURN`；未知路线需求为 `ROUTE`，独立保留在全局待办中，不因五类勾选被遗漏。日历无条件命中时返回空聚合，数据源不可用不能返回伪造零值。
+
+DTO 冻结的共同字段：
+
+```text
+WorkItem
+  workItemKey: string, version: integer
+  type, flow: 上述枚举
+  title: string, businessNo: string|null
+  containers: ContainerReference[]
+  requirementKey: string|null, batchKey: string|null, batchNo: string|null
+  originName: string|null, destinationName: string|null
+  planStatus: UNPLANNED|TARGET_SET|AWAITING_REPLY|CONFIRMED|NOT_REQUIRED
+  executionStatus: PENDING|IN_PROGRESS|COMPLETED
+  reviewRequired: boolean
+  target: Slot|null, confirmed: Slot|null
+  actual: Actual|null
+  calendarDate: YYYY-MM-DD|null
+  dateBasis: ACTUAL|CONFIRMED|TARGET|NONE
+  timezone: IANA zone|null
+  owner: {id: string, name: string}|null
+  followupDate: YYYY-MM-DD|null, overdueReasons: string[]
+  allowedActions: Action[], nextAction: Action|null
+  blockReasons: string[], missingFields: string[]
+Actual = {occurredAt: Instant|null, localOccurredAt: LocalDateTime|null, timezone: IANA zone|null}
+Slot = {date: YYYY-MM-DD, startTime: HH:mm|null, endDate: YYYY-MM-DD|null, endTime: HH:mm|null, timezone: IANA zone|null}
+ContainerReference = {containerBookingId: string, bookingNo: string|null, containerNo: string|null}
+SourceReference = {customerId: string, sourceKey: string, destinationKey: string|null}
+Action = {code: ActionCode, label: string, targetWorkItemKey: string|null, target: ActionTarget}
+ActionCode = VIEW_DETAIL|SAVE_PLAN|REQUEST_BOOKING|RECORD_CONFIRMATION|CHANGE_BOOKING|CANCEL_BOOKING|
+             VERIFY_CARGO|EDIT_BATCH|ARRANGE_TRANSPORT|RECORD_EXECUTION|CONFIRM_ROUTE|SAVE_FOLLOWUP|
+             RESOLVE_REVIEW|SAVE_REQUIREMENT|HANDOFF_RETURN|ACCEPT_RETURN|VIEW_HISTORY
+ActionTarget 是按 kind 判别的联合：
+  WORK_COMMAND {command: 工作命令枚举}
+  CARGO_VERIFICATION {source: SourceReference}
+  FBA_APPOINTMENT {appointmentId: string|null, batchKey: string|null, sources: SourceReference[]}
+  FIRSTLEG_CONTAINER {containerBookingId: string}
+  FLEET_TRIP {tripId: string|null, batchKeys: string[]}
+  WAREHOUSE_RECEIPT {inboundPlanId: string|null, containerBookingId: string}
+  READ_ONLY {references: BusinessReference[]}
+WorkDetail = {item: WorkItem, relatedItems: WorkItem[], references: BusinessReference[], history: HistoryEntry[],
+              review: {version: integer, reasons: string[]}|null,
+              requirement: {bookingRequired: boolean, receivingRequirements: string, reason: string|null}|null,
+              returnHandoff: {version: integer, from: Responsibility, to: Responsibility,
+                              status: PENDING_ACCEPTANCE|ACCEPTED, reason: string}|null}
+Responsibility = {kind: USER|SUPPLIER|EXTERNAL, id: string|null, name: string}
+BusinessReference = {kind: string, key: string, businessNo: string|null, label: string}
+HistoryEntry = {occurredAt: ISO instant, operatorName: string|null, action: string, summary: string}
+Summary = {all: integer, followToday: integer, overdue: integer, undated: integer, review: integer}
+CalendarResult = {from: YYYY-MM-DD, to: YYYY-MM-DD, total: integer,
+                 counts: BucketCounts, days: DayAggregate[]}
+DayAggregate = {date: YYYY-MM-DD, total: integer, typeCounts: Map<type,integer>, counts: BucketCounts}
+BucketCounts = {pending: integer, confirmed: integer, noBookingRequired: integer, review: integer, completed: integer}
+```
+
+Slot 的 `date` 为开始日期；`endDate` 与 `endTime` 必须同时有值或同时为空。结束不能没有开始时间：填写结束日期/时间时，`startTime` 必填。完整结束时间必须严格晚于开始时间，不允许相等；跨日必须显式填写结束日期，不能因为结束钟点小于开始钟点就自动推断次日。只有日期、没有开始时间时，结束日期和结束时间都为空；前后端按同一规则校验。例如开始 `2026-10-15 23:00`、结束 `2026-10-16 01:00` 可以明确表达跨日；仅填写结束 `01:00` 而未填结束日期应拒绝。
+
+时间事实扩充合同已冻结：`Actual` 非空时，`occurredAt` 与 `localOccurredAt` 至少一种有值。`occurredAt` 表示绝对时间（Instant），`localOccurredAt` 表示原业务保存的无偏移当地时间（LocalDateTime）。原业务只有 local 实际事实且没有时区时，直接保留其当地日期用于日历，`timezone=null`，并在事项 `missingFields` 中标记 `SOURCE_TIMEZONE`；不得给 local 时间附加 `Z` 或伪装成 UTC，也不得从服务器、浏览器或计划时区推导实际时间。缺少时区不能抹去真实完成事实或让事项回退为待完成；有 local 实际时间时继续按实际日期展示，不能退回目标/确认日期。
+
+跨地点实际先后比较必须基于可确定的绝对时间。原提柜/还空只有无时区 `LocalDateTime` 时，不能直接与有 IANA 时区的直送目的仓当地钟面值比较先后，也不能擅自套用目的仓或其他时区。真实提柜存在、全来源真实卸货完成仍是直送还空的硬门槛；缺少源时区时，跨地点实际先后尚无法证明，不能把时序校验记为已通过，也不能因此跳过真实业务前置条件。
+
+多目的地直送的完成时间选择各目的地真实完成时间中最晚的 `Instant`，不按当地钟面值取最大。72 小时提醒按基准 `Instant` 之后的绝对 72 小时时长计算，跨夏令时（DST）也保持相同时长，不能以当地日期加三天或当地钟面差值替代。
+
+来自原业务的 `Slot.timezone` 允许为 null，并同样标记 `SOURCE_TIMEZONE`；保留原日期与时间，不擅自转换。新 `SAVE_REQUIREMENT` 的用户输入仍要求有效 IANA 时区：只要提交非空 `target`，`target.timezone` 就必填，不能用原业务读取允许空值的规则放宽新录入校验。合同冻结不代表实现、部署或验收已完成。
+
+内部 `ContainerSource` 的时间字段扩充如下（其余既有字段不变）：
+
+```text
+departedAt: Instant|null
+departedLocalAt: LocalDateTime|null
+sailedEvidenceLocalAt: LocalDateTime|null
+```
+
+三种时间至少一种有值。`departedAt` 或 `departedLocalAt` 是确切开船时间；`sailedEvidenceLocalAt` 仅证明存在实际发生且节点序号大于等于开船节点的事实，可用于确认已开船来源资格，不能显示为确切开船时间，也不能复制成 `departedAt`/`departedLocalAt`。仅有后续实际节点证据时，保留证据及其语义，不能把该节点发生时间冒充开船时间。
+
+所有统计按稳定事项键去重；全局五项统计是不同集合，允许重叠，不能相加作为工作量。日历五个 BucketCounts 互斥，依次按已完成、需复核、已确认、无需预约、其余待安排归类，相加等于 total；无需预约单独表达，不能冒充已确认。同一真实车次在一天按一项运输工作计数，关联批次在明细中展示；批次送货工作仍各计一项。containers 保存全部关联柜，按任一关联柜筛选均能命中，共享车次仍只计一个事项。keyword 仅过滤当前明细，匹配业务号、柜号、批次号和地点，不影响全局摘要。`calendarDate` 优先实际、确认、目标；日期已过而未完成进入超期，不能从全局消失。事项无日期但有跟进日期仍属于未定日期；“今日跟进”按该事项作业当地今日判断，无地点时使用明确的业务默认时区并展示口径，不能取服务器默认时区。
+
+Action 的 code/target 是白名单业务动作，不下发任意 URL 或 HTTP 方法。前端映射既有入口或工作命令表单；不能只凭 code 发车/完成，原业务命令仍复核权限、版本及前置事实。缺权限可以看详情和明确原因，不能以禁用按钮替代完整下一步说明。首屏一个主要下一步，其余放详情；若需要先处理其他事项，targetWorkItemKey 指向前置项，关闭后回原上下文。
+
+工作命令只覆盖工作模块自身拥有的数据：
+
+| command | payload 必需语义 | 边界 |
+| --- | --- | --- |
+| `CONFIRM_ROUTE` | `flow=TRANSFER/DIRECT`，`reason` 可选 | 核对业务事实、版本与已有安排，事务幂等生成清单 |
+| `SAVE_FOLLOWUP` | `ownerId`、`followupDate`（可空）、`note` | 只写跟进；不能清除未接手、未预约或未完成需求 |
+| `RESOLVE_REVIEW` | `reviewVersion`、`note` | 对已展示的影响版本复核；若原安排本身需改，先走原业务命令，不能用复核代替改期 |
+| `SAVE_REQUIREMENT` | `target: Slot|null`、`bookingRequired: boolean`、`receivingRequirements`、`reason` | 非空 target 必须填写有效 IANA timezone；仅用于原业务尚无计划实体的接仓需求、客户仓收货要求及还空目标；FBA、提柜、车次计划仍写原模块；无需预约必须有明确收货要求依据 |
+| `HANDOFF_RETURN` | `recipient: Responsibility`、`reason` | 保留原预约、原责任与交接记录；新接手未确认仍待办；重复提交不重复交接 |
+| `ACCEPT_RETURN` | `handoffVersion`、`note` | 服务端核验当前责任与有效转交版本；用户本人可接手，外部承运方由具备写权限的运营记录明确反馈依据，保留真实操作人；只确认责任，不等于实际还空 |
+
+服务端拒绝不支持的 command/payload，不提供通用“改状态/标为完成”。跟进、复核使用 `platform:appointment:followup`；路线、缺失计划要求及责任转交使用新写权限 `platform:appointment:manage-work`，接手操作还需身份约束；读取使用 `platform:appointment:list` 并核验关联来源的读取资格。权限种子/菜单绑定由总控集成，不通过移除鉴权让前端联调。
+
+首次设置目标、首次同日落实和首次配车建立基线，不触发无意义复核。真正改期/货量或执行关系变化仅标记已有相关目标或已落实的下游；未定日期、尚未安排的项继续待安排。复核动作本身不再传播一轮复核；旧影响版本不能覆盖新变化。取消预约不取消工作需求。普通回复、复核、取消不能清除还空转交待接手提醒。
+
+## 4. 预约核心向消费者提供的边界
+
+已落源码的货物核实接口可据此并行消费，但仍须测试通过才能作为完成交付：
+
+- GET `/api/platform/v1/last-leg/appointment-planning/sources/{sourceKey}/cargo-verification`，query 为 `customerId`，可选 `destinationKey`。返回 `Context{source, verification, allocatedPackages, unknownAllocationCount, effectivePackages, availablePackages, sourceChanged, allowedActions, blockReasons}`；可分配数无法确定时为 null，不得显示为 0。
+- POST 同路径，query 为 `customerId`；body：`destinationKey, expectedSourceVersion, expectedVersion, packageCount, shipmentReferences[], remark, idempotencyKey`。返回 `Verification{version, sourceVersion, destinationKey, sourcePackages, packageCount, shipmentReferences[], remark, operatorName, verifiedAt}`。未知原箱数可保存经核实箱数，已知原箱数不能超出，已分配量不能被覆盖到更小；不改原订单。
+- source 字段以 `AppointmentSourceService.Source` 和 `appointment-cargo-verification-v1.yaml` 为准；现有 `VERIFY_CARGO` 只代表核实能力，不代表分批已开放。
+
+分批能力以实际 Controller/DTO/OpenAPI 和直接验证为准，不得以旧整票 preview/create 假定 V13 已全部具备。核心任务核对并冻结本轮新增或调整的合同，必须包含稳定 batchKey/version、每个 customerId/sourceKey/destinationKey 的分配量、核实版本、来源版本、幂等键、取消/替代关系，以及所影响的批次/事项引用；对同仓合并保留逐票来源，不把客户归属抹平。新工作模块通过单向只读适配获得批次身份和覆盖，不能回调形成包循环；原业务命令成功后按相关键重新读取/协调工作项，不建立第二本数量台账。
+
+本轮 V13 接口补充按正式变更说明第十节核对：全部/部分分配去向、当前共同预约范围及版本、待重约和排除成员、失效预约与仍有效数量分配的边界、逐步骤结果及受影响事项。沿既有真实合同补齐，不照搬原型字段名，也不另建同功能端点。具体新增字段、动作和错误码由生产者先冻结并同步消费者。
+
+V13 生产者与消费者使用下列明确边界；这是接口合同，不表示已部署验收：
+
+- 批次上下文沿 `GET /appointment-planning/batches/{batchKey}`，`currentBatches` 返回全部当前去向；`originalSourceRefs` 保留当前和已移出货物的客户、原来源、目的地，仅用于过滤当前去向。可写分配量仍取 `sources` 及服务端资格，不能将历史来源重新作为可用余量。
+- 收货范围命令归 `inboundplan/receiving/`，HTTP 根为 `/api/platform/v1/last-leg/appointment-receiving`；具体七个读写入口、字段与权限以 `appointment-receiving-v1.yaml` 为准。稳定批次、独立收货预约及真实车次是不同身份。共同或独立重约产生新的有效预约关系，旧取消范围保留历史。
+- 待确认变化提交 `ownerId`，平台人员目录校验身份并给出姓名；响应 `Pending.followup` 保存权威姓名及可空跟进日期。后送批次与再次分批由工作域继承负责人和跟进记录，不将自由文本当账号，不将跟进日代替作业日。合批遇到同客户不同跟进安排时须先明确统一，不能猜选覆盖。
+- `FbaAppointmentTransportPort` 负责真实移货；`FbaAppointmentExecutionPort` 按客户、批次及原履约证据给出重约资格。`Book.executionVersion` 绑定涉及批次的执行事实，写入只核对所选客户；同批已完成客户不阻断未完客户重约。锁顺序为车次、排车/执行、批次，取得批次锁后再次读取执行版本防止间隙新增关联。
+- 确认变化同事务核平原量、后送量及运输关系；失败整体回滚。撤回未生效变化不改货量、原确认或车辆，不因运输开始而失去撤回入口，仍校验变化版本及幂等。保存后的独立约仓、配车失败只续办该步骤，不重复创建已成功批次。
+
+新增或调整部分采用阶段门禁：生产者先产出真实合同与直接测试，消费者再接写入；现有已冻结能力及不依赖新增接口的工作继续并行。生产链不得用 Mock、空数组或成功兜底假装未交付能力；缺依赖在开发交接中列明，不向用户呈现不可用的假成功按钮。
+
+- 同批部分客户已正式确认时，其余客户通过 `POST /api/platform/v1/last-leg/appointment-receiving/plans` 保存本客户未确认计划。请求 `Plan` 使用 `member(batchKey,batchVersion,customerId)`、`details`、`executionVersion` 和幂等键；只允许 `PENDING`/`FAILED`，正式确认字段必须为空，目标日期可空，未约成须说明原因。`Context.plans` / `BatchReceiving.plans` 返回权威客户计划，存在但目标为空表示真实清空，不回退其他客户日期。计划不占用新的货量、不形成有效收货确认、不修改其他客户确认。当前计划归核心 `ll_fba_receiving_plan`，工作域仅作投影；批量读取为三条有界查询。
+
+- 整组重约允许明确选择本次客户子集。跨批次组只选部分批次时，通过只读 `POST /api/platform/v1/last-leg/appointment-receiving/execution-scope` 以 `ExecutionQuery.members` 获取实际所选范围的执行资格及版本；该入口使用列表权限，不建立预约。前端重新核对选择，写入继续校验原批次和取消组版本，不能自行合成 token 或静默刷新用户未核对的批次事实。
+
+- 独立核实资料更新后，当前未确认客户通过 `POST /api/platform/v1/last-leg/appointment-receiving/cargo-refresh` 明确采用最新资料。请求 `RefreshCargo` 包含原 `member`、完整逐来源期望版本、`executionVersion` 和幂等键；先展示最新核实量与货件资料供操作者核对。只更新本客户原批次资料快照，不改分配量、客户/来源/目的地身份或其他客户确认。有效确认、待确认变化、已执行、来源身份改变或数量不守恒均拒绝；不以放松Plan/Book版控恢复，不在独立核实保存后自动采用。
+
+## 5. 唯一文件写者与阶段交付
+
+以下代码路径相对工作区 `C:/Users/BY-OY/Desktop/code/chongchong-global`。修改前读适用最近指引，保留已经存在的未提交更改。包级范围只覆盖预约工作本轮直接相关文件，不授权重写整包无关业务。
+
+| 写者 | 独占文件/触点 | 不得写入 |
+| --- | --- | --- |
+| 开发总控兼预约核心 `01a13df2-c639-7560-a3e2-30bc23a579b3` | `baiyue-firstleg/lastleg-service/src/main/java/com/baiyue/lastleg/appointmentplanning/` 来源、核实、覆盖、批次与预约桥接，以及 `inboundplan/` 核心预约和直接消费者，排除下述本批交给后端专项的触点及直接测试；现有预约规划、核实、批次及 FBA OpenAPI；本轮全部 Firstleg 来源接口和直送卸货/还空守卫；既有检查点、共享 DDL/SQL、IAM/权限种子、根路由导航、Gateway/公共门禁集成及验证窗口 | 两个专项独占文件、原型及业务主文档；不能与专项并写 |
+| 工作事项后端 `01a13e1c-9101-7a43-8445-771685ff315e` | 原 `baiyue-firstleg/lastleg-service/src/main/java/com/baiyue/lastleg/appointmentwork/`、同包测试、`src/main/resources/openapi/appointment-work-v1.yaml`、独立 DDL 提案 `src/main/resources/db/appointment-work.sql` 保留；增加下述 Lastleg 原域适配及精确同步触点 | Firstleg；未列入本批适配的预约核心和 PDA 写类；共享 SQL/配置/IAM/权限种子/架构门禁 |
+| 预约页面前端 `01a13e1c-db36-73e3-a231-d6649c51664b` | `apps/admin-web/src/modules/appointment-calendar/` 全部页面、组件、API、直接测试与操作矩阵；共享 `overseas-warehouse/components/FbaAppointmentFields.vue`、`appointmentForm.ts`/直接测试；`api/inboundOrders.ts`/测试仅预约消费段；`index.ts` 仅相关导出；`pages/InboundOrdersView.vue`/测试仅预约弹窗衔接；增加下述跨页面工作流触点 | 后端、根路由/导航、本轮工作流之外的业务功能、原型与业务文档 |
+| 原型与文档支持 `01a13a8d-e968-7962-906b-1a514792d921` | 业务梳理、原型、本文及必要业务正式文档/入口；设计确认后向开发总控交接 | 代码、共享 SQL、构建、开发检查点写入、开发派工及持续进度跟踪；接口对齐和验证安排由开发总控负责 |
+
+模块 `lastleg-service/src/main/resources/db/lastleg.sql`、`deploy/sql/海外区域统一增量-MySQL8.sql` 与 `reset-test-fba-appointments.sql` 统一由当前开发总控 `01a13df2-c639-7560-a3e2-30bc23a579b3` 集成，保留各专项已有改动，新后端仅维护独立 DDL 提案，不并写共享文件；本轮只编辑文件，不执行 SQL。
+
+本批工作事项后端新增写权，以下 Java 路径相对 `baiyue-firstleg/lastleg-service/src/main/java/com/baiyue/lastleg/`：
+
+- 本轮 Lastleg 原业务域与工作事项间的真实读取/同步适配。
+- `inboundplan/work/`：本轮原预约域的工作事项适配。`inboundplan/service/InboundFbaAppointmentService.java` 及核心预约/分批测试已由后端专项明确停止修改并交回开发总控，V13 核心调整由总控唯一写入；本条覆盖早期“专项增加最小同步钩子”的临时移交。
+- `dispatch/service/DispatchService.java`、`dispatch/dto/DispatchRequests.java`、`fleet/trip/FleetTripExecutionService.java`，以及以上适配直接涉及的 Mapper、DTO 和对应测试；只为本轮工作流衔接修改，不扩展为原业务域整体重构。
+
+上述保留给后端专项的触点及其直接测试由专项唯一写入；总控不同时编辑。已交回的预约核心服务及核心测试由总控唯一写入。再次调整写权时须明确移交后再写，不按同文件不同方法安排并写。后端专项仍不能改 Firstleg、共享 SQL/IAM/公共门禁。
+
+本批预约页面前端新增以下最小工作流衔接写权，路径相对 `apps/admin-web/src/modules/`；可同步对应直接测试，不改页面中无关业务：
+
+- `container-loading/pages/ContainerDetailView.vue`、`container-loading/api/terminalDrayages.ts`。
+- `overseas-master-data/pages/TripsView.vue`、`overseas-master-data/pages/TripDetailView.vue`、`overseas-master-data/components/TripPlanDialog.vue`。
+- `overseas-warehouse/pages/DispatchesView.vue`、`overseas-warehouse/components/SmartDispatchDialog.vue`、`overseas-warehouse/api/dispatches.ts`、`overseas-warehouse/pages/InboundOrderDetailView.vue`。
+
+本轮全部 Firstleg 来源接口、直送实际卸货/还空守卫及相应原域事实适配由开发总控负责；工作事项后端消费和提出所需 DTO，不写 Firstleg。提柜后还空责任与原承运历史分离的业务约束不变。Firstleg 无时区 local 实际事实与开船证据按第三节已冻结时间合同衔接，不能把证据时间当作确切开船时间。共享 DDL、IAM、根公共权限常量及门禁仍归总控，不能借上述原域适配授权扩大写权。
+
+1. 核心保持核实与数量分配开发；新后端按 v1 实现工作合同；前端接入已冻结的工作 v1 和核实接口。分批消费者等待真实分批合同，其他部分并行。
+2. 每个任务在自己对话报告实际修改、接口偏差、缺口、测试证据与可集成基线。总控读取，不要求自动跨对话回信；不新增任务或递归派工。
+3. Maven/共享构建输出按总控分配窗口串行；前端只运行本模块直接验证，完整测试/build 先核对其他专项的窗口。当前先开发和准备测试，由总控安排执行时段。
+4. 原型由原型与文档支持对话统一维护；V13 已获用户确认并形成正式变更说明。实现偏差先报当前开发总控，必要时请求文档支持，不能各自改原型或偷偷改变 DTO。开发总控沿本节原分工推进，不新增任务或扩大文件写权。
+
+## 6. 必须保留的验收场景
+
+V13 本批新增及强化场景以[正式变更说明第十一节](预约工作日历V13变更说明.md#11-最小验收矩阵)为准；下列既有场景继续保留，不能用原型通过代替真实合同和实现验收。
+
+- 已开船但未创建预约、未知路线、没有海外仓绑定的直送、非 FBA 客户仓、货已送完但未还空，全部能进入正确待办；跨月份、全关类型、只看单流程不能误清全局数量。
+- 中转一柜分三批、两车运输，柜级不重复；部分取消/改期/合并后数量仍守恒、逐票客户和货件信息未丢失；并发或重复点击不超分、不中断剩余需求。
+- 直送不生成海外仓入库，不伪造卸货事实；同车或转交还空均可追踪原预约、新责任、接手状态及真实完成前置条件。
+- 未定日期仅补货物资料不自动预约；有跟进日仍未定作业日期；首次计划无多余复核，真实变更仅影响相关已安排项，复核不产生复核循环。
+- 日期跨时区、实际发生时间晚于目标、改期/取消后的旧事实仍正确；同一车次多批不重复计车辆工作量；只读用户不能通过通用命令越权执行。
+- 原业务无时区 local 实际事实保留当地日期与完成状态，并标记 `SOURCE_TIMEZONE`；原业务 Slot 可缺时区但新录入不可缺；仅有 `sailedEvidenceLocalAt` 时可证明已开船，不能展示为确切开船时间。
+- 外部来源或权威事实读取失败有明确失败反馈，不能展示“0 项/全部完成”；生产接口不能返回原型 Fixture。
+
+生产代码、离线检查、部署与真实验收分别交付。人工视觉验收仍按 1920×1080、100% 缩放，由用户截图确认；本轮不部署、不运行 SQL、不写测试环境数据、不启动本地后端、不自行提交或创建分支/worktree。

独立任务协作登记.md

@@ -1,7 +1,592 @@
 # 测试环境独立任务协作登记
 
-已按用户要求清空全部任务登记与调度规则（2026-09-09）。当前无登记任务。
+## 2026-10-22 用户反馈18项修复与发布验收
 
-任务由用户手动创建、处理和归档，不根据旧登记、历史消息或历史台账自动派工、恢复任务或回传进度。
+总控为“22号问题总控”`01a16320-fcec-7332-8223-0b51e9c382e9`，目标为 TEST 项目 `c64729ff-6710-43c6-8ef2-d84e9666cc1e`、host `local`、当前工作区 `C:/Users/BY-OY/Desktop/code/chongchong-global`。复用现有任务，不新建聊天、分支或 worktree，不操作开发工作区。
 
-本文件仅保留空登记说明，避免已有文档链接失效。历史需求与验收证据保留在《测试任务盘点与需求台账》，不作为当前调度或授权依据。
+用户明确纠正：`01a16323-8ab4-7a83-be01-df8966f4ac8d` 是由用户直接跟进请求重放问题的对话，不接受本总控新增派工、优先级、冻结或交接要求。此前相关追加要求撤销，总控停止向它发送消息；它不承担本批12–18项。其既有差异保留，由总控只读核对交付和文件边界。
+
+用户已授权全部代码提交、TEST部署、测试数据库操作、真实HTTP调用，以及随后内置浏览器登录验收。Admin/Client按1920×1080，国内/海外PDA按390×848验收。最新目标同时要求验收请求重放机制删除后的行为；该验收由总控负责，不给上述独立对话追加任务。凭据只从用户指定私有配置目录读取，不进入源码、文档或公开报告。实际发布、SQL和HTTP/UI结果只维护在[测试环境主契约](测试环境单机部署与配置契约.md)。
+
+需求梳理已经结束，本批实施1–18；第19项“快递派送”明确暂缓。第12项放舱后仅允许维护预计到港，其他冻结资料不放开；第14项删除“调整已有排车货物”页签及调整能力，错误配货按现有资格取消并重新建单，不迁移调整入口或自动取消。第18项沿现有槽位命名“装车现场、装车清单、发车前检查、驾驶证、回执”。
+
+| task_id | 对话及稳定职责 | 本批交付与边界 |
+| --- | --- | --- |
+| `01a16323-754a-7002-90a6-547545105647` | 22号修复｜订单审核与称重 | 1–3、13、17–18已交付并停止编辑；海外PDA样式和五照片名称在总控只读核实原写者结束后接续完成，69项直接检查通过。 |
+| `01a16323-7a96-7182-a73c-7ffa47b53b72` | 22号修复｜订舱关联与报关 | 4–5、12已交付；Admin和Firstleg预计到港窄维护、柜号规则及预录单展示。数据库规则由总控按本轮授权审阅执行。 |
+| `01a16323-8036-7353-b467-fe3e8465628f` | 22号修复｜排车与车辆资料 | 6–9、11、14–16已交付并停止编辑；删除货物调整入口、1100px审核弹框、真实创建时间；末轮159项相关检查通过。共享样式测试另有4项非本轮页面失败，不据此宣称整套通过。 |
+| `01a16323-8ab4-7a83-be01-df8966f4ac8d` | 22号修复｜PC与PDA请求错误锁定清理 | 用户直接跟进的独立请求重放处理；不接受本总控派工或交接要求。已有源码由总控集成、部署及验收，不改派其职责。 |
+
+共享文件实现已结束，进入总控固定版本、发布及真实验收阶段。执行专项不自行部署、执行SQL或改测试数据。总控保留其他对话已有修改；测试/构建经 `baiyue-firstleg/scripts/local-check.ps1` 两槽门禁，按差异复用有效结果。源码、自动检查、发布健康、真实HTTP、浏览器及扫描设备验收分别记录，未完成项不推定通过。
+
+关键验收口径：确认测量弹框标题“确认测量”，正文“审核通过后，入库单将进入待分柜”；预录单/出口报关仅隐藏可见版本，不移除内部并发语义；预约编号、时间和货件来自正式预约与实际货物，去重不得丢票；三类车辆照片在送审/通过时必填，草稿允许未补齐。四端请求失败后提示错误、释放操作态并保留可编辑输入，允许关闭与重新操作，不强制刷新、查询或重放；在途防连点、服务端权限/状态/版本及幂等校验仍保持。实际失败和结果未知分开记录，不能以界面解锁推定业务未执行或据此伪造成功。
+
+## 2026-10-21 用户验收32项修复与统一发布
+
+总控为 `01a15eae-fd50-7f42-93b5-eb203648b808`。用户本轮指定复用五个既有对话，并在“样式优化”分区新增两个独立对话，合计七个执行专项；目标为 TEST 项目 `c64729ff-6710-43c6-8ef2-d84e9666cc1e`、host `local`、当前工作区 `C:/Users/BY-OY/Desktop/code/chongchong-global`。两个新对话保存项目已核对为 TEST；五个旧对话的项目迁移工具返回成功，但复读仍为 `projectId=null`，按实际空值登记，不声称迁移已落地。五者均为用户本轮精确指定的本地同工作区任务，未发生跨环境调度；不操作开发工作区、不新建分支或 worktree。
+
+用户授权在本批全部修复、必要检查及总控复核完成后，由本总控统一部署受影响 TEST 服务及端侧，并执行真实 HTTP 验收。执行专项只有本地实现与定向检查写权，不自行提交、推送、发布、执行 SQL、造数或调用写接口。根负责精确发布候选、发布窗口及验收数据；删除、重置、SQL 和本批外发布不在授权内。凭据仅从用户指定的 `C:/Users/BY-OY/.codex/env/chongchong-global` 私有目录加载，禁止输出真实值或把值写入源码、文档及报告。部署事实只维护部署主契约，本节维护派工和文件归属。
+
+| task_id | 本批稳定职责 | 问题编号及唯一写入边界 |
+| --- | --- | --- |
+| `01a15dcc-dfe7-7660-98b0-7f9a2384c439` | 订单、测量与审核 | 1–7；Admin `unified-orders`、`first-leg-orders` 及实际复用的入库测量/审核组件和直接测试；纯展示不进入后端。费用明细面板展示归本专项，财务记录调整逻辑归下行。 |
+| `01a15dcc-5645-77b1-984b-f95af08120b7` | 客户应收应付 | 8；Admin `finance`、Finance费用调整的直接后端与测试。确需 Firstleg 费用来源修改先列精确文件，避开订单面板和柜费面板。 |
+| `01a15dcc-7f62-70d1-a016-1410a5ae6b1e` | 货柜、智能装柜与预装清单 | 9–12、16–17、21–22、25；Admin `container-loading`（含本批 SmartLoading）与 `loading-lists`、对应直接测试。历史重复若需后端，仅对应历史生产/读取触点；不得并写 PDA完成链路。 |
+| `01a15dcb-8638-7ca0-9037-b27b2a1ccac2` | 订舱管理 | 13–15；Admin `ocean-bookings` 与直接测试；时间字段缺失时可追踪 Firstleg `oceanbooking` 的直接生产者。货柜中的订舱关联弹框归货柜专项。 |
+| `01a15eb4-8850-7582-8cf0-5ab848427ae7` | 国内PDA装柜完成链路 | 18；国内 PDA `pages/picking`、完成状态/请求辅助和直接测试，Firstleg装柜完成命令/查询的直接链路与测试。先拆分等待来源，不以隐藏处理中代替修复；货柜/清单展示文件不写入。 |
+| `01a15eb4-8c12-7903-844f-a3241adcef3c` | 客户端头程订单与资料 | 19–20；Client `first-leg` 和退税报关资料直接使用组件及测试；“关闭”改“提交”只改文字，不改动作。 |
+| `01a15e2b-3e40-7110-8d2b-88d15e965110` | 海外预约、尾程与入库 | 23–24、26–28；Admin `appointment-calendar` 与实际海外入库/FBA预约页面、Lastleg预约来源/编号/预计到仓传递的直接后端及测试；客户预约号的直接读取消费归本专项，Client源码若需修改须先协调。 |
+
+总控唯一维护本批登记、公共样式/组件、共享导航/根路由/IAM/统一SQL和发布验收接线。实现者先回报入口、精确文件与预计验证，随后在授权范围继续；共享文件需求交总控，不并发改写。各组复用有效定向结果，不各跑全量；所有测试、类型检查、构建经 `scripts/local-check.ps1` 两槽门禁。界面视觉仍以1920×1080、100%人工截图为准；代码检查、部署/HTTP通过、人工视觉确认分别记录。
+
+启动时已有他人差异必须保留：Admin 的 `WorkSharedTripForm.vue`、排车三个组件、`dispatchCommandRecovery.ts`、`DispatchesView.vue`；后端 `DispatchAggregateService/DispatchService` 与直接两测试，以及全量验收脚本专项在 `scripts/` 的现存差异。各专项不接管这些文件；必要交叉由总控确认唯一写者后接续。第1项先按移除“已经确认数据”节点展示定位，不授权删除业务数据；第11项先核重复来源，保留真实有效历史；第26项修复权威编号生成，不前端截短。
+
+定位后的必要扩展：货柜专项追加 `port-schedules/components/CarrierScheduleQueryPanel.vue`、`ContainerPortSchedulePanel.vue` 实际路径与直接测试的展示写权，覆盖货柜人工补录及嵌入船期弹框；海外专项追加 Firstleg 日历柜次号的直接 DTO、查询/组装器和测试，精确类路径由专项回报，不改其他船节点、订舱历史或PDA完成链路。货柜组已冻结并按SHA256释放 `ContainersView.vue`、`ContainerDetailView.vue`，到仓结果映射的写权交海外组；实际类型触点为 `api/containerArrivalTimes.ts`。公共 `adminDensity.test.ts` 仍归总控。
+
+用户后续追加29–32，仍复用上述七个执行对话，不新建聊天：订舱专项接续29–31排车“维护车辆信息”的原型字段补齐、上传操作及调度审核照片回显，PDA专项在18租约返修后接续32海外PDA装车照片样式。29的依据为用户截图 `codex-clipboard-0b236f6d-d66c-4878-8992-52ad04104489.png` 及命中的局部原型；先核字段与直接契约，不将原型示例或计划时间伪装为实际发车事实。新增前端触点以实际资源表单/审核/照片组件为限；现有排车并行写者未冻结前，共享调度文件只读。32仅复用国内上传呈现思路，海外源码留在本应用，保留照片、权限和命令语义。
+
+29–31跨端拆包：`01a15dcc-5645-77b1-984b-f95af08120b7`在财务冻结后接续唯一后端实现，维护 `DispatchCommands.Update.maintenance`、`DispatchViews.VehicleInfo.maintenance`、必要资源快照/存取、Aggregate update/detail、`FleetTripService.dispatchResources`及直接测试/OpenAPI；订舱/车辆专项只写对应前端。八个可空字段为plannedDeliveryDate、deliveryMethod、pickupMethod、loadType、fleetEmail、vehicleType、appointmentAccount、appointmentNo；不新增金额/审核硬门禁，不把本趟预约资料替代正式FBA预约。优先沿已有资源JSON的唯一正式类型保存，不引入无必要表列。取消专项已完成并idle；总控已记录其既有调度文件差异基线，再释放 `DispatchWorkflowDialog.vue` 给前端、Aggregate局部给后端，保留全部在先差异，禁止整体覆盖。18/32已交付12文件并冻结，租约缺口已补实际Mapper/事务回归；财务同毫秒排序返修已通过独立只读复核。26前缀与24范围采用用户后续确认，见本节当前状态。
+
+当前状态：七个实现包均已交付；财务同毫秒历史排序与PDA旧worker租约检查点两项审查缺陷均已返修并经独立复核关闭。订单超限提醒、订舱时间、货柜/预装白底、客户端两项、预约真实确认状态、到仓日期传递、车辆资料保存/照片审核与海外PDA照片均已完成相应定向检查；次数有交叉，不相加为覆盖总数。用户随后明确26采用WC＋日期＋四位流水，24暂不做客户原预约号自动带入；海外专项据此收口编号主契约，不新增客户字段或猜测referenceId映射。车辆后端独立审查无阻断；总控对照用户原型发现MASTER模式承运公司和电话缺少展示，现唯一释放 `DispatchResourceFields.vue` continuous分支及直接测试给订舱/车辆专项补只读可见信息，其他模式和入口保持原语义。
+
+发布准备：Admin及Client生产构建通过，国内PDA的H5和appResource、海外PDA的H5和app资源编译通过；未发布APK/WGT、未在设备验证。MASTER补显34项及日期消费者32项定向检查已通过。客户端专项只在忽略临时目录准备逐项核实的HTTP验收草案，不读取凭据或联网；执行权仍归总控。人工视觉核对仍待1920×1080、100%截图。
+
+固定发布候选：Backend `2c3435adafe48c8e97ef145fa301eaa11ea230be`、Admin `2e26477db523cebf23db8c28f8a4dc39cb0df1bd`、Client `7adb97d145e28e61eb391ff7609aecdb2fda7e62`、国内PDA `5fcc51d73c2ba48f109ca513831f4a5f816dbb92`、海外PDA `9c2f0a54ec1e9147db7cd434455e963e8c4cb22a`，均已推到各自既有分支。共享文件用本轮前快照剥离取消专项增量后写入index提交，保留完整工作树；布局测试亦只提交本批字段/照片用例。远端随后出现未部署的尾程列表需求，正常合并并保留分支源码，但本批发布仍pin上述原提交，不追加Order或该新需求；当前运行版本已核为本批候选祖先。尝试扩展审查后及时撤回该范围，局部草稿不进入发布。发布由总控执行，实际Jenkins、容器及HTTP事实只写部署主契约。
+
+用户随后明确完整验收目标：总控在本批修改完成后，先运行真实HTTP流程，通过后打开内置浏览器登录检查样式、交互和请求量；Admin/Client使用已部署TEST、1920×1080，国内/海外PDA使用本地 `http://localhost:5176/#/`、390×848。该明确授权覆盖本轮默认人工截图限制，并允许TEST部署、真实HTTP及必要测试数据库操作；不据此清空用户数据或操作其他环境。总控继续唯一环境执行，专项只收口本地草案。当前部署与已验证范围见部署主契约，HTTP全链及四端页面未完成前不关闭目标。
+
+## 2026-10-20 排车、自有及外配 HTTP 扩展收尾
+
+2026-10-21 本轮明确的TEST真实HTTP与小于1秒目标已完成：4f交付原PLAN主链及原extra两单后缀全部履约、结案、资源释放和完整库存证明；7b独立复核主链身份/时序/失败闭合通过；根核三单最终事实、真实全响应计时和两客户全部阶段库存一致。具体结果及保留限制只维护部署主契约顶部。56、63实现/审查候选保持冻结；没有新增生产改动、SQL或发布任务，不重复派工或重跑成功链。52此前四图与材料有效校验已纳入证据，若旧turn仍显示active不据此重启或扩大任务。
+
+2026-10-21 原PLAN主链已真实履约完成，具体状态、计时和库存证明见部署主契约顶部。4f保持唯一HTTP执行权，接续已审287cfb35原extra自有/临时外配两单，先刷新两客户完整库存证明及运行版本，不重造样本；7b并行只读复核原PLAN主链的最终证据。56的after-loading两文件及63最终审查已交付冻结，暂无新增生产修改或发布，根继续处理证据整合与实际失败的最小分工。
+
+2026-10-21 原单后缀实际完成装车至AFTER_LOADING/v6，派送安排前的本地字段校验停止，安排POST未发送、无未知写。实际库存balance.inboundOrderNo保存原计划号，而脚本误与订单号相等比较。56仅获新增 `.codex-temp/fleet-plan-after-loading-continuation-20261021.mjs` 及直接 `.test.mjs` 的写权，绑定此次成功装车回执及state/journal，从派送安排继续，不重放装车或前段、不新增通用reconcile；原eb后缀及报告保持冻结。63只读核库存字段写入语义及最终窄差异；4f核对原v6、装车命令成功及完整库存后仍为唯一HTTP执行者。根维护接口关联和实际结果，7b此次#391发布已完成，不重复部署。
+
+2026-10-21 后续接续已完成原柜到港、实收及原预排首拣，当前原单LOADING/v5、2/2核平；只读托盘解析被仓储A0409“已报废”拒绝并在Lastleg误映射为S0503。63沿该resolver与实际生命周期核定必要生产修复，不得为测试恢复或重置报废托盘；4f唯一执行正式只读取证及之后HTTP。56唯一新增 `.codex-temp/fleet-plan-after-pick-continuation-20261021.mjs`、`.test.mjs`、`.plan.md`，绑定已成功fulfill前段state/journal，仅从已拣货断点继续装车/派送/签收/释放，禁止到港、收货、拣货、审核、建单及新的reconcile。已冻结f38b、d9fc、extra及原报告不改；7b继续独立审查和必要发布，根负责合法查询语义与接续范围裁定。实际结果与提供方响应唯一见部署主契约及引用证据。
+
+2026-10-21 原离港预排已实际到 `PC202610210001/LOADING/v4`；#389真实分页通过，未实收装车负例出现S0500并经只读恢复确认原命令未生效、主单和完整库存未变。63唯一修改该生产装车前置校验及直接回归，7b按#389基线独立审查和最小发布。56唯一新增 `.codex-temp/fleet-plan-loading-negative-continuation-20261021.mjs`、`.test.mjs`、`.plan.md`，保留原失败报告、原请求和冻结f38b驱动，形成严格 `PLAN_LOADING_NEGATIVE_RECONCILED_V1` 接续检查点；4f唯一修改 `fleet-plan-arrival-20261021.mjs` 及直接测试消费该检查点、新部署版本和原父封印。4f仍唯一HTTP执行者，当前暂停依赖写入；修复/接续审查与运行状态核验后继续原单，不重建或重审。extra新版287cfb35已完成90项检查及独立审查，主PLAN库存操作完成后再刷新证明执行；52此前材料校验已纳入有效证据，不重复检查。具体运行结果唯一见部署主契约。
+
+2026-10-21 接续：56 的离港分段驱动已冻结为 `f38b81abb42ab825bbc5e07402d7223aa1b93bc7701d4fb8f7123692f07bcd5b`，82 项离线检查通过，7b 已独立复审 GO；4f 的专属正例只停在实际离港且尚未到港/实收，待匹配版本和执行放行。56 已完成 `fleet-extra-stage-continuation-plan-20261021.md` 的只读接线清单，随后获准新增 `fleet-extra-stage-continuation-20261021.mjs` 及直接测试，处理既有两张 extra 单从 AFTER_LOADING 到结案、车/司机分别释放的计时缺口；原冻结脚本/报告和离港驱动不改，不执行 HTTP，不新增生产需求或业务样本。4f 并行准备这两原单只读预览及明确 TEST 费用、收据材料，执行仍由 4f 串行，离港全链优先。63/52 分别交付后端与 Admin 真分页，统一交 7b 审查和匹配发布；分页是否达到小于 1s 仍须发布后由 4f 实测。
+
+分页实施分工更新：63 已明确本轮未修改 Admin 候选分页并释放前端写权；52 接管 `SmartDispatchDialog`、候选 API/类型及直接消费者和测试的分页实施，不能修改 Java/SQL/OpenAPI 或其他组共享样式。63 保留后端分页、离港 PLAN 候选及首拣位置只读解析的唯一写权。7b 接续前后端候选及 56 全链脚本的独立审查、最终串行发布；52 不自审其新增前端实现。56 按正式分页 DTO 接线新离港全链驱动，4f 准备专属素材并唯一执行。原 extra 续跑已完成独立核对，原脚本与报告保持冻结。
+
+用户随后明确增加整链验收：货柜实际出港后先预排车，再衔接到仓及出库全部流程。既有合托、临时外配及性能收尾继续保留。56 负责复用正式编排入口形成离港 PLAN 预排至出库的 HTTP 驱动及直接测试；4f 只读选择可用合成货柜与计划并唯一执行正式接口；52 独立核对未离港、未实收门禁和同原计划/排车关联的连续性；63 核对预排候选业务逻辑及相对实际部署的必要增量；7b 统一审查及串行发布。原库存直接排车不能代替离港预排证据，预留托盘不能代替实收库存，到仓后不得另建现货排车冒充原预排链衔接。当前在途性能发布 #387 保持冻结，新必要生产增量另按最终候选验证和发布。
+
+2026-10-20 本轮最新用户目标覆盖此前本批授权限制：持续授权本总控在 TEST 部署、操作测试数据库并调用真实 HTTP 跑流程，优先完成 HTTP 联调；请求完整返回耗时要求小于 1000ms。凭据仍仅从 `C:/Users/BY-OY/.codex/env/chongchong-global` 私有目录加载，不进入源码、报告或对话输出。复用用户明确提供的五个既有对话，不创建新任务。4f 唯一本批业务造数及流程执行；56 唯一扩展脚本与直接测试修复；52 独立复核脚本、输入、真实证据与耗时口径；`01a15963-16ca-7610-90e3-7afce598a7d8` 保留当前智能排车对齐和候选查询性能修复职责，独占其已修改文件；`01a1597b-17d2-75e3-8429-5024c21b61fd` 保留排车编号修复及在途 Lastleg 发布，统一串行发布本批后端候选。发布窗口与业务写入串行衔接，编号建单验证复用 4f 新单；性能定位可只读，不能并发压测污染流程样本。功能通过与小于 1s 的性能验收分别记录，尚未计时不能推定性能通过。实际部署与 HTTP 结果仍只维护部署主契约。
+
+总控仍为 `01a15230-a9d6-7503-a8a9-d70691df49e5`，范围保持 TEST 项目 `c64729ff-6710-43c6-8ef2-d84e9666cc1e`、host local、当前工作区；复用下述三个既有对话，不新建任务。用户已明确授权自行创建第二个 TEST 平台测试账号，全部凭据仅保存于指定本机私有环境目录。4f 通过正式 IAM/Auth API 创建一个专用自定义角色和账号，仅授予自有、外配的 list/edit/upload 六项权限，验证真实有权异账号重放原成功请求键被拒绝；不授予平台管理员、不改旧角色或其他账号、不执行 SQL。仅本轮账号在测试后正常退出并停用，未知创建或停用保持明确未确认，不换标识重造。
+
+4f `01a1524f-4f11-70c2-8a46-8e06e73a2d86` 保持唯一业务 HTTP 执行人，独占第二账号独立脚本及直接测试；56 `01a1524f-56a9-7320-a5fd-8ff76fa4356b` 只实现临时 EXTERNAL 无车辆主档及同一实托两来源的独立扩展脚本与直接测试，当前不写环境；52 `01a1524f-52c7-7cc3-9b08-d34ad24c172a` 独立只读审查候选及实际证据，不读取新账号私有密码。总控协调、核验与维护主契约，不夺回环境写权。已成功的主流程脚本、原报告和原样本保持封存；实际阶段结果及仍未验范围只维护于[部署主契约](测试环境单机部署与配置契约.md)对应记录。
+
+## 2026-10-20 Admin 蓝白清爽风格推广
+
+本节原由 `01a1587b-196b-7221-8774-933aab521ce9`（整理页面风格）总控维护；2026-10-21 用户明确要求接手，现由 `01a15c55-dbec-78b3-9719-7d01b737679b` 在同一工作区接续。此前用户反馈推广后多处页面、尤其弹框布局不可用，明确提供五个既有对话要求分工修复；这批五组修复已完成自动检查，人工验收仍待截图。原五任务的桌面保存项目绑定均为 TEST `c64729ff-6710-43c6-8ef2-d84e9666cc1e`、host local、实际 cwd `C:/Users/BY-OY/Desktop/code/chongchong-global`，与本登记匹配；不使用同项目保存根中的开发目录。
+
+当前接续范围为原对话最后两张截图提出的主列表状态页签对齐和灰白斑马纹：接续已有公共 CSS 修改，恢复标准表格默认斑马纹，保留业务行色与悬停／选中状态；不重新启动此前五组排查。本轮仅当前对话及内部子代理分工，公共样式与集成验证由当前总控唯一维护，内部子代理只清理列表 stripe 关闭属性及直接断言。既有排车、拖车在途业务改动保留；无部署或环境写入。
+
+2026-10-21 接续新增用户要求：收紧主列表底部分页留白，公共规则采用最小 48px、上下 6px、左右 12px，保留翻页控件尺寸和换行。已清理58个Vue文件中59处标准DataTable关闭斑马纹属性，并启用财务调账明细表斑马纹；页签修复限主列表首项，避免挤压前置返回按钮。自动检查期间，用户另在 `01a15c6a-e715-7172-9d69-4c31cd5e0fb1`（分离搜索区与表格）要求公共搜索区独立、5px圆角及浅蓝表头，该对话仍维护这些增量。双方现有改动均保留，本接续不覆盖对方共享文件，不另启动重复全量。接续全量报告为467文件、4269项通过，但前后快照检测到7个公共文件被该对话更新，故该报告不作为最终统一快照通过证明；对方最新构建与129项公共定向检查已通过。最新整体全量收尾以该对话在途检查及其最终输入为准。本轮证据位于 Admin `.logs/admin-style-handoff-20261021/`；未发布，实际页面仍待人工截图。
+
+此前全量自动检查仅证明当时输入的测试与编译结果，不能证明弹框视觉或交互已验收；此轮优先处理浮层布局、嵌套污染、正文与页脚滚动、表单和按钮可用性，再处理列表与详情的间距。用户已直接确认隐藏的长汇总不恢复，业务与权限变化不夹入本轮。
+
+接续三项样式在搜索区／表头增量合入后，已追加公共组件及样式6文件135项定向确认，全部通过；最新结果与并行输入限制见上述证据目录的 `verification.json`。本接续实现与定向验证收口，整体统一快照及发布不在此处重复宣告完成。
+
+共同视觉合同为[蓝白卡片式工作台风格参考](界面参考/蓝白卡片式工作台风格参考.md)：清爽、少提示，复用公共样式；保留当前业务、权限、数据含义、密度和交互承载。各组覆盖本域正式路由及其关联表单、详情、弹框和抽屉；打印版面保持原尺寸。以下目录均相对 `apps/admin-web/src/modules/`，只授予展示改造及直接验证、最近验收矩阵写权，不接管 API、业务状态、路由接线或其他专项在途逻辑。
+
+| task_id | 当前对话名 | 唯一风格改造职责 |
+| --- | --- | --- |
+| `01a159e5-95a7-7732-a9c8-6dc550f5ca65` | 优化新增船期弹框 | 唯一公共浮层与样式实现者：`src/styles/adminDensity*`、`src/styles/adminWorkbench*`、`src/shared/components/AppDialog*`、`AppDrawer*` 及直接回归；另维护 `sailing-calendar` 的船期弹框。先核实真实 Element 根节点、嵌套与 Teleport 隔离，业务特例不写入公共规则。 |
+| `01a159e7-0159-7ad1-bafe-33ed6b30a32c` | 优化货柜详情样式 | 货柜及物流详情、弹框与相关页面：`container-loading`（排除下行 SmartLoading 专属文件）、`loading-lists`、`ocean-bookings`、`trucking`、`customs`、`outbound-dispatch`、`port-schedules`。重点详情重复内距、子页签、清单嵌入及新增／编辑／预览浮层。 |
+| `01a15933-5343-7e63-9fcc-6dd662f422d3` | 待安排任务-1 | 国内订单、入库与定价：`unified-orders`、其直接使用的 `first-leg-orders`、`inbounds`、`fba-pricing`、`domestic-containers`；另独占 `container-loading` 内 `SmartLoadingDialog`、`SmartLoadingCandidateInbounds`、`SmartLoadingWorkbenchView`、`GlobalSmartLoadingView` 及同名直接测试。本轮不扩大此前跨客户装柜后端修复。 |
+| `01a15933-78e2-7d43-8808-80a82c7b009b` | 待安排任务-2 | 海外业务：`overseas-warehouse`、`overseas-business`、`overseas-master-data`、`appointment-calendar`。在途排车、自有/外配及预约文件先核实是否仍有写者，冲突项只读列出，由总控协调后再改。 |
+| `01a15932-9d23-7013-9546-b609ca824429` | 待安排任务-0 | 客户、财务与基础管理：`customers`、`finance`、`suppliers`、`warehouses`、`warehouse-resources`、`master-data`、`fee-items`、`iam`、`notifications`、`downloads`、`pda-releases`、`audit`、`dimension-config`。 |
+
+本轮以上公共样式及 AppDialog/AppDrawer 写权从总控交给“优化新增船期弹框”，根不并行修改。总控保留其余 `src/styles/`、`src/shared/components/`、应用外壳及导航呈现、`dashboard`、`auth`、`self-operated`、共同规范与本登记表，负责独立审查、全量检查和集成交付；不改变共享路由和权限语义。模块任务不复制公共样式、不修改其他组目录；共享缺口写明具体选择器与消费者，由总控转交唯一写者。已有改动和用户在其他对话确认的业务修复均保留；发现活动写入冲突先跳过该文件继续本域其他页面。
+
+每组先回报实际问题、受影响入口和预计文件，然后继续最小修复，无需等待重复确认；维护本域已有验收矩阵，区分已修、自动检查通过、待人工截图。重点覆盖普通表单、长表单、全屏工作台、详情抽屉、预览以及二级弹框；检查关闭／重开／全屏切换、校验错误、底部操作、横向表格和纵向滚动，不以新增主题类或源码字符串断言当作可用性证据。仅做必要定向检查，公共代码稳定后由总控统一全量检查；不让五组各跑全量。
+
+2026-10-21 本轮五组派工已逐一发送成功，并已核对五个新回合全部 active/inProgress，修复结果尚待回报；先前检查结果不作为本轮完成证明。总控独立只读复核发现 AppDialog 默认并非必然 Teleport，智能装柜内部分配弹框可真实嵌套，公共后代部位选择器存在穿透风险；已分别交公共唯一写者与国内业务组核实并最小修复。workspace 的92vh和独立compact卡14px应保留，不因排查一律清零或压缩。
+
+2026-10-21 第一轮五组已交付，各组定向检查分别116、92、256、123、257项通过（存在范围重叠，不相加为总覆盖数）。总控继续第二轮：公共组处理工具栏后代按钮规则穿透浮层，并获 `DataTable.vue` 与直接测试的唯一附加写权；货柜组处理 `ContainerSimulationCreate` 的工具栏内浮层挂载。其余三组只读交叉审查公共、海外预约、客户通知改动，业务源码冻结。货柜共同核对记录由总控合并，避免两组并写。
+
+第一轮41文件已由另一个用户任务提交为 Admin `0a1968a1`，基线为 `2f9a3330`，该提交不等于本轮最终验收。其完整回归运行期间不启动重复全量；第二轮输入变化后，根以最终源码快照决定必要重验。公共规范新增浮层隔离、单一正文滚动、底部操作与长错误占位约束；用户人工截图仍未收到，本批实际页面可用性不能宣告验收完成。
+
+2026-10-21 第二轮全部执行组已收口冻结：公共浮层／工具栏10文件148项通过，模拟柜4文件75项通过；交叉审查发现的comfortable子表单污染与预约辅助按钮拉满均已修复。内嵌DataTable亦作为工具栏边界排除。总控独立复核comfortable唯一业务消费者的实际表单路径，无遗漏；客户／通知、海外／预约的业务脚本及绑定审查无阻断。本轮代码修复与统一自动检查已收尾，不继续扩范围。
+
+最终验证：当前 Admin 提交 `db3b5f7157c900b885ade2626014f70c61cb0849`，全量466个测试文件、4255项全部通过，0失败／0跳过；应用类型检查与生产构建通过，`git diff --check` 通过。验证前后1127份源码及配置SHA-256完全一致，Admin工作区干净。验证证据统一在 `.logs/admin-style-audit-20261021/verification.json`、`full.json` 与源码快照，完整报告SHA-256为 `E913D8D218C1C018DD272DD9AFBAF543CD0B50B51757BA1F7BD1BB49E65FF3DA`。五个既有执行任务均已完成本轮实现／交叉审查，没有未安排的代码返修项；仍待用户1920×1080、100%截图确认实际页面布局、滚动与操作区。总控本轮未触发部署，不以其他任务提交或发布推定本轮视觉验收完成。
+
+当前授权为本地实施与检查，执行任务不推送、不部署、不执行 SQL 或真实业务写入，不打开浏览器；样板已发布不等于全 Admin 已发布或已完成人工验收。检查统一走 `local-check.ps1` 两槽入口，执行任务只运行必要定向检查，稳定后由总控统一全量检查；截图由用户提供。各执行任务在自身对话交付文件清单、覆盖范围、检查结果和未验项，总控读取结果，不由派工消息额外授予互发消息权限。当前阶段：三个执行任务的模块展示改造及总控公共样式、首页登录、外壳已完成集成；已核对113条正式业务路由、99个页面入口及实际复用组件。随后按用户截图统一12px页边距、移除整页外框、合并同级列表页签与按钮、收紧顶部和筛选区、消除订单嵌入审核重复内距，并修复折叠菜单横向溢出。最终经共享门禁完成464个测试文件／4204项全通过，类型检查与生产构建通过，验证窗口1114份源码摘要一致；证据留在 Admin 本地忽略目录 `.logs/admin-workbench-rollout-20261020/`。公共规范和各域既有矩阵已更新，仍待用户1920×1080、100%截图确认；本批未推送、未部署。
+
+总控随后只读核对预约专项已交付并 idle，原排车前端专项当前只做 driver 来源与账本只读预审；因此将之前保护的预约、排车、自有／外配及关联车次页面的展示写权交回本批海外组。保留其业务差异及 API，逐文件修改前核对无内容漂移；出现新的活动 UI 写者则暂停该文件。此记录不接管上述专项的业务、环境或验收职责。
+
+2026-10-20 19:20 用户再次要求优先安排任务。总控已重新下发并核对三个既有对话均active/inProgress：4f独占热修后只读接口预检及自有LIVE2真实HTTP，同时独占外配driver三项审查缺陷修正；52独立复核修正后封印及Admin消费协议，不改driver；56负责#384发布收尾和受影响持久查询只读预审，联调失败时先交最小根因。外配执行需自有LIVE2成功且新driver独立审查通过。根独立核实际Lastleg c324镜像healthy，仅维护共同契约和交接，不夺回环境写权、不新建任务。
+
+2026-10-20 用户明确要求“不要自己一个人干，优先安排任务”，并批准外配固定 Lastleg9f3755f8/Admin3f4021c0及三权限最小清单。本轮执行权已实际交给三个现有对话：56独占最小外配IAM及Lastleg发布；52独占Admin发布及配置恢复；4f独占匹配版本就绪后的自有/外配真实HTTP。根不再执行SQL、触发发布或业务HTTP写入，只维护共同契约、当地检查、独立核对及环境交接。权限脚本需先由52独立审查，再由根向56发EXECUTE_IAM_GO；56/52交健康与权限回执后根才给4f HTTP_WINDOW_GO。新候选以实际#382/6771和Admin#661/9726为基线保留他人发布，避免回退；固定38路径自有CI#381已SUCCESS，外配联合82、IAM4、API/结构34及前端36/类型/构建通过。完整Admin50失败来自3个其他在途客户选择器测试，不夹入24路径外配发布包，不宣称全量全绿。
+
+2026-10-20 17:50 TEST总控按用户“外配也要继续安排开发”及对三个既有task_id的明确授权，复用56后端、52前端并行实现外配，4f主后端转自有固定候选/HTTP验收；不创建新对话。用户已确认外配整车承运金额÷实托数，逐目的仓到达和五装车照片，省里程、油耗和两油耗照片。唯一规则与精确写权见[外配业务首版开发契约](海外仓业务/外配业务首版开发契约.md)。根继续唯一发布和共享接线，环境执行窗口未交接前各专项不写TEST。自有冻结Git对象7c6a与外配后续工作区改动分开，本次自有候选CI #381进行中、DEPLOY=false，不夹带外配源码。
+
+2026-10-20 自有业务源码与本轮自动验证收口：前端18文件冻结摘要`3deb4b56…f94fb40`，Admin定向113项、默认资源源码typecheck/build及全量453文件4087项通过；全量窗口无Admin TS/Vue/CSS漂移。后端最终25路径`b8d7c7d9…9ac456f`，首轮65项及最后文案修正后的持久化/照片15项、IAM种子5项通过；File相邻21项、Mapper406、AGENTS索引1229、Gateway/同步依赖/Lastleg结构联合33项通过。根只读端口适配和共享SQL/IAM/File接线已落源码，六个现存客户端仅在根同步依赖清单补真实分类、未改其业务。两专项源码冻结，当前未执行本页环境SQL、部署或HTTP，原型页面仍待人工验收；具体共同边界与证据见自有业务首版契约，不把代码/自动检查等同已在TEST可用。
+
+2026-10-20 自有业务已按用户最新解释收敛为原排车装车后的自有车辆运营视图，外配为同一原排车的另一车辆归属视图且本批不实现；共同API v1及金额/油耗单位、照片保存与命令恢复规则见首版契约。两个既有任务均已启动实现。根已补Admin菜单、列表/详情路由与三权限及22项直接回归，IAM三权限与国内统一权限种子、File两类平台排车照片及契约/测试；经local-check的File直接回归21/21通过。根接原loadingComplete同事务车辆归属捕获，维护其唯一直接持久化测试，并同步Lastleg及海外统一空库基线4张附加表（ownership/record/command/history）。后端及页面候选仍在收口，未运行本页环境SQL、部署或业务HTTP，原排车HTTP扩展仍由主后端对话独占；两个专项不得覆盖共享接线或原排车主链。
+
+2026-10-20 用户明确复用排车派送与费用后端`01a1524f-56a9-7320-a5fd-8ff76fa4356b`及排车前端与PDA`01a1524f-52c7-7cc3-9b08-d34ad24c172a`，与当前总控三方并行开发自有业务，不新建对话。共同业务及文件边界唯一见[自有业务首版开发契约](海外仓业务/自有业务首版开发契约.md)。后端独占新增ownedbusiness包、直接测试、独立OpenAPI及设计；前端独占新增OwnedBusiness页面/组件及ownedBusiness API/类型与直接测试，PDA及共享接线不动；根负责业务接口冻结、导航路由权限、基线和提供者触点、集成检查。先交窄接口及页面承载设计，冻结后实现接线，不猜未知业务。专项暂不重型检查，根统一local-check窗口，无HTTP/SQL/发布/推送授权扩张。原排车后端继续独占既有排车HTTP扩展，自己的新marker样本与本页隔离。
+
+2026-10-20 用户明确指定由“排车后端”`01a1524f-4f11-70c2-8a46-8e06e73a2d86`接手真实 HTTP 联调及扩展测试，总控已派工并核对该对话 active/inProgress。该任务为本轮排车扩展 HTTP 唯一执行者，使用新 marker 和独立 TEST 数据；原人工单已完成，仅只读，不重放旧续跑。先核已有673断言的真实覆盖，再补多目的仓、审核重提/零扫码变更、同托换标/取消保留成果、双端竞争/资格隔离及预约BOL分量等缺口，缺前置或未执行的注入不得记作通过。允许的脚本写权为 fleet-cross-customer-fixture及其直接合同、新增dispatch-workflow-extension验收模块及直接合同、dispatch-workflow-extensions-test-env入口和对应最小README登记；生产源码、共享runner、SQL及部署仍不因此解锁。所有检查经local-check串行，未知写保留原键原载荷并停止依赖操作。总控同期只读检查自有业务/外配业务的菜单与页面，避免并发环境写入；未新建对话或接管日历新增预约。
+
+2026-10-20 14:34 当前排车自动检查与本轮修复已收口：原单 HTTP 178请求/673断言通过、派送完成且车司机释放；PDA可拣资格修复48项回归通过，受控仅排车H5候选已独立只读审查、发布healthy及85文件逐SHA核对，未夹带废弃业务。三个既有独立对话本轮均已交付并空闲，不继续重复检查或另建任务。剩余为人工页面/实体扫码验收，不能以自动检查替代；运行指纹、候选输入及限制见[部署主契约](测试环境单机部署与配置契约.md)当前14:34记录。
+
+2026-10-20 14:19 当前排车 HTTP 接续已完成，原人工单 DELIVERED、当前车次完成且车司机分别释放，178 请求/673 断言全部通过，自有会话退出。原“人工样本不自动推进”的保留要求已由用户后续明确继续 HTTP 指令覆盖，本次只接续原单，不重建、不重审、不新建下一空排车。三个既有对话本轮已交付：排车后端一次性 driver、派送费用只读预审、前端 PDA 两文件可拣资格修复；根完成 HTTP 与 48 项直接回归、H5/App 资源构建和85文件核对。14:26发布输入比对发现当前包还含另一项已提交的废弃出库改动，根在准备阶段阻止发布，无远端写入；前端对话仅只读复核这些额外差异及产物，不再写源文件或执行环境操作。运行事实与未验范围以[部署主契约](测试环境单机部署与配置契约.md)当前记录为准，旧节点记录仅表示对应时点，不能覆盖本次接续结果。
+
+2026-10-20 11:31当前人工验收节点为“提交调度审核”：根复用native_fleet_script（Java/直接测试两文件）、native_capacity_consumers（recovery/直接测试两文件）、native_fulfillment_script（弹框/列表/详情/既有预约加货八文件），均已交付冻结，无新对话和跨域扩权。后端24项及前端49+75项直接回归通过；根唯一发布后端#376并以真实只读HTTP核对人工单待调度审核v3、不可再提交、主单未变。Admin完整4012项仅fixture边界1项失败；最小修正后9项复验通过，根已完成十文件精确#654发布、类型/构建、运行healthy及公网5资源逐SHA核对，临时Job配置原文恢复。只待用户刷新人工确认本节点，不等同整条人工验收完成。运行、提交和HTTP证据唯一维护在[部署主契约](测试环境单机部署与配置契约.md)顶部；人工单不自动推进，日历新增预约不接管。
+
+2026-10-20 BOL当前人工节点：用户最终确认保持现有一次PDF下载，内部按目的地＋预约号分BOL、同仓同号跨客户合并、无号留空同仓合并；不新增下载弹框/ZIP/API，不扩大日历。根复用fleet只读设计真实分配数量与BOL投影，capacity独立只读核对，不跑重复检查，fulfillment已只读确认无需UI修改并交下载错误解析建议（另记待办，不并入当前包）。根随后冻结fleet五文件、capacity两文件及根Print两文件/唯一OpenAPI描述，均完成交付；读取13+打印9、网关5通过，Print全模块66中65通过1容量开关专项跳过。根已唯一发布Lastleg#377及Print#107，正式GET确认同仓空号由2页合1页、两票两箱均保留、ISA空白；人工主单LOADING/v5完全未变、自有会话已退出。只待用户重新下载确认，不代扫码或装车。实际环境证据见[部署主契约](测试环境单机部署与配置契约.md)。
+
+2026-10-20 用户明确要求继续HTTP并复用三个既有独立对话加速；总控已重新派工并实际核对三者均active/inProgress。排车后端唯一写根.codex-temp/dispatch-manual-http-continuation-20261020.mjs，准备原人工DS从LOADING/v5到签收及本trip资源结束的一次性driver，不执行；派送费用后端只读预审安排/费用/签收；前端PDA原先只读预审已发现页面以allocated>picked误判可拣；根真实PDA响应确认两行available=1/allocated=0/picked=0后，精确解锁海外PDA dispatch.vue与dispatch-workflow.test.mjs两文件修复，API/store/样式不动，根统一验证与发布；HTTP继续不受页面修正阻断。内部三代理本轮只读交接已结束，不与独立对话并写；根仍唯一环境写者、local-check及执行者。本轮明确接续原单，不重建/重审，也不调用默认结案助手中的新建下一空排车探针；只结束本trip并核当前占用。根当前只读HTTP已确认LOADING/APPROVEDv5、零拣零发、唯一trip TR-9VA7RGXK6K1K17LDZC75O45MC，未推进任何业务。旧MANUAL_HANDOFF报告/intent保留，后续只用新报告、严格实时前置及新seal，未知写停；真实环境事实仍唯一维护在[部署主契约](测试环境单机部署与配置契约.md)。
+
+## 2026-10-19 排车列表统一作业改造
+
+2026-10-20 10:54总控交人工节点：主C后半链HTTP实际455/455及结案释放通过，司机证照三文件修复43项clean回归、TEST #375部署和真实元数据/内容/隔离复验通过；Admin已核#653/f422包含原展示修正，未重复发布。三内部执行者当前均已交付冻结，无新增任务或写权。根以唯一受保护执行准备人工单`DS-E5A85B6D67214315A08135E122213D61`，装车前DRAFT/版本2、双客户双托双箱、车辆司机已配、零扫码；准备85请求157/157，manualReady=true、自有会话已退出。最新环境事实和来源/托盘号只维护在[部署主契约](测试环境单机部署与配置契约.md)顶部。该单交用户从提交调度审核开始逐步验收，根及自动跟踪只读，未经用户新指令不得自动推进或清理，不能把准备检查点误作待修复失败而续跑。
+
+2026-10-20 10:27总控当前安排：用户要求先HTTP全链路再人工走单，停止进一步样式验收。原C已装车后v8，根唯一准备显式AFTER_LOADING续跑，不重建或重做前半程；实际环境节点以[部署主契约](测试环境单机部署与配置契约.md)顶部为准。复用三个既有内部执行者：capacity唯一写跨客户脚本及direct合同2文件，修正测试模型A0403文案并以唯一85488等待共享检查槽；fleet已冻结证照读取Java及测试3文件，现只读检查后半程DTO，不跑环境；fulfillment已交详情展示3文件、16/16通过并冻结。根负责原单HTTP、共享文档、后续精确集成及发布，未新建用户可见任务。下方09:45的80263及LOADING v5属于此前检查点，不是当前状态。
+
+2026-10-20 09:45总控接续：已按用户“测试可删除、不要备份”完成固定旧运输链清理和原生结构匹配；实际环境事实只维护在[测试环境单机部署与配置契约](测试环境单机部署与配置契约.md)。两处仓库字符比较及空单取消已由既有内部执行者交付、根集成135ffa662de10c1af76183ceef73eb37de73899f、45项通过并在TEST #374部署，原样本复验成功；无新建用户可见任务，根仍唯一发布和SQL/HTTP写者。新C两客户样本已到LOADING v5，验收脚本车牌大小写错误两文件经34项通过，单独精确对象689bd219ff015cee62b2e480b7b2a7c0522b4380（未另部署业务服务）。原C显式续跑驱动`.codex-temp/dispatch-cross-c-explicit-continuation-20261020.mjs`已排local-check，执行句柄80263，等待另一Admin全量检查释放共享槽；未启动则不得将其记为后半链已执行。新报告DISPATCH20261020CRESUME、原C报告和原命令全部保留，禁止从头重放。日历新增预约仍排除，页面控制超时单独列未验收，不以CI或静态审查关闭视觉节点。
+
+用户明确当前对话 `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-19 17:56提速交付：用户要求加快，总控已亲自完成四处旧查询及三份直接测试，精确归属见主契约第九节，7文件清单`.codex-temp/dispatch-root-query-manifest.json`SHA`8269869d…9332e2d`；移除共享主单/任务客户头依赖，客户进度使用ACTIVE和真实五阶段/发车时间，原数量、明细/扫码/订单客户过滤保留。仅静态差异检查通过，3类测试交唯一执行者；新H2回仓查询测试将MySQL BINARY转等价VARBINARY，独立探测同值相等、大小写/尾空格不等，未冒称MySQL环境执行。派送接线19路径已正式交付，总控逐项及聚合复算`a1ebcebf…d604fdd7`匹配并交主后端8类直接回归；候选批读/草稿投影不再只是待定接口，运行结果仍待验证。前端版本及外接入口包报告183项/typecheck/build通过，完整26文件候选待总控复核。主后端新报告全量1060生产源码编译通过，452测试源码编译现卡FleetTripPersistenceTest的旧Preparation类；主后端继续主夹具，已将独立ReturnCartonReturnPersistenceTest交派送任务并行适配，保留原业务断言、不恢复旧协议。根7文件独立复核交原前端只读执行，未新增任务。退役smart权限源码/种子已删除，当前统一逐VALUES记录统计为454权限/618关联且静态唯一/外键通过，之前按INSERT行数得到的计数已废止；新5类IAM29/29为主后端报告，根还需核对实际报告和种子哈希。无部署、环境SQL或真实验收。
+
+2026-10-19 18:04收口：总控补齐第五处旧查询`DeliveryOperationMapper.returnReceipts`，只移除共享任务客户头条件，真实明细客户条件保留；根查询清单现为8文件，原7文件独立只读复核无确定缺陷，新查询由归箱6用例覆盖待唯一Maven执行。派送任务已交付并冻结`ReturnCartonReturnPersistenceTest`新模型夹具，原6业务用例保留，SHA`d7e37c99…267d8cdce`。主后端随后展开6个旧测试阻断，已精确将其释放的`DispatchRepairWorkflowTest`交原派送任务单文件适配，主后端处理其余5类，不并写；保留取消回滚、混托来源/费用及退货来源断言。总控已实际核对新IAM五类29/29及源/target种子SHA一致，关闭该离线权限包。主后端仍在全服务测试编译和BOL/旧测试消费者收口；最新前端26文件摘要与交付不符，前端正在只读定位PDA fulfillment.js交付后变化，尚不接受新摘要或宣告原检查覆盖当前输入。既有预约19文件已核对稳定，不再等待新增业务批准；无部署、环境SQL或真实验收。
+
+2026-10-19 18:10提速：最新1062生产源码完整编译通过后，主后端继续Fleet类测试阻断，派送任务并行保留修复工作流断言；总控直接完成两个已授权FBA持久测试13处transport.apply父命令键签名收敛并冻结，19文件包逐项及新聚合`70526153…86ad658`实核匹配，等待主后端唯一完整编译/直接回归。总控同步Fleet实际无客户头响应，删除已退出入口的Prepare/Create/BindingCommand/Review孤立schemas，保留capacity-plan复用的ConfirmLoad；4份OpenAPI651引用/重复键及两份SQL12表静态检查通过。前端摘要差异查明仅PDA货物废弃SKU的quantityUnit合入及行尾变化，其余25文件一致，待静态核定其与排车链隔离后按当前输入更新摘要；未恢复或覆盖他人变更。以上仍非全链通过或部署验收。
+
+2026-10-19 18:11收口：总控完成并冻结`DeliveryTransferService`及直接测试两文件（SHA`126e3852…f57b4a`/`1088520d…15d27e`）：PDA两处解析读取无客户头整车，直接扫码同仓成功/异仓404回归补齐；取消出库删除旧requireUnbound，保留原阶段、真实执行及费用守卫。主后端已修整车取消只阻断有效出库，CANCELLED历史保留且不误阻断，并加入回归；上述新输入均等待唯一完整编译/运行，尚无全链通过结论。派送任务继续原修复工作流native适配，不并写服务；总控此前两个FBA测试已交付，不再是编译等待。
+
+2026-10-19 18:19并包：派送任务最后工作流测试7方法/9场景已交，根实核SHA`9cf2fa9e…d35ec5`，保留混托3+2、排除他客99、运费60、原箱来源、取消重排等当前断言。根费用来源SQL去任务头客户，来源回归改实际FleetAdapter，删除无生产消费者旧Query；直接消费者清单SHA`8e6691d5…95f8b98`。另收敛订单/计划排车状态、原预约影响、库存SHIP来源4查询及4测试（SHA`3ba52b3b…d71b6cf`），均保持真实明细/pick客户、仓和命令身份，不改预约创建。Fleet影响绑定SQL仍归主后端唯一维护；所有根/B输入已冻结交唯一Maven干净编译与直接回归。总控实际日志已核一轮完整454测试源码编译成功，但新输入仍须重编译。前端当前26摘要`8cb5db64…238fda`已根复算，唯一差异为独立废弃SKU字段及行尾，排车函数未变化，原相关检查只按未变化输入复用。无部署或真实验收。
+
+2026-10-19 18:25验证收口：根实际核两份日志，修正/原生查询69项和费用来源/出库/Fleet查询90项均0失败0错误并BUILD SUCCESS；这不是最终联合回归通过。统一438项先前暴露的来源发布、签收并发、取消工作流3类本地原生夹具已由派送任务修复并交回，根逐项核SHA匹配，唯一Maven继续实跑。根审阅依赖基线中两个FBA适配器到公共port的7条精确引用，并补反向合同及当前维护入口；没有增加slice通用许可，旧pickup三处Entity违规仍列既存门禁阻断，不在本批重做取货业务。所有业务范围仍按现行主契约；日历新增预约未接管，无部署、SQL或真实验收。
+
+2026-10-19 最终联合回归收口：当前冻结输入下单次80类501项全部通过，无失败/错误/跳过，日志`dispatch-final-joint-regression.log`SHA`b56da123…b83238`。根独立逐项复核1519份输入与聚合`3ff451e8…594de9`一致，当前无漂移；不再把之前分批组合覆盖作为最终单次证明。Gateway合同5/5通过。依赖13项中10通过、3失败仅由开工前pickup实体边触发，新公共port和反向越界检查通过，没有加宽许可。AGENTS索引唯一新失败为海外PDA指引超8000字符，原前端任务正在单文件精简，完成后唯一执行者复验。车辆预约仍有真实未接通限制：Create无该字段，Update非空关联被拒绝，详情输出null，未定位权威提供者且本批不新建日历/预约权威；不得报为全字段打通。环境SQL、部署、真实HTTP、1920页面及PDA硬件验收均未执行，不把本地代码/离线验证通过等同最终验收。
+
+2026-10-19 用户最新裁定：对排车车辆预约权威来源问题答“那就不要”，总控已确认取消排车车辆预约字段及关联，FBA预约和四页签保持，新增预约日历仍不接管。主后端独占移除公共Update/DispatchInfo字段及相关类型和服务占位；原前端删除直接展示/输入与测试；派送后端只读核直接构造引用，若主后端释放测试再精确移交；总控已同步主契约和OpenAPI。前轮501/501及1519快照只证明裁定前输入，变更后须重做直接受影响编译/检查，不冒称旧结果覆盖新协议。用户询问增加独立对话，总控判断当前共同接口收口不适合继续加写者，复用现有三任务，不新建对话。
+
+2026-10-19 车辆预约取消后复验：后端公共字段/类型及服务占位已移除，全服务test-compile和25项直接回归实际通过；总控按现行Java重生97公开schemas，29平台/7PDA路径及649引用、重复键、版本阶段、两SQL静态检查通过。前端8文件删除和73项定向测试已交，Admin完整构建在vue-tsc触及2GB堆上限退出134，Vite尚未执行，不能记typecheck/build通过。PDA指引长度已合格，但两固定语义索引句还需原写者恢复，后端无须空等，由总控接索引复验。
+
+现行验收脚本仍使用已退役公开调用，按真实直接消费者收敛：原派送任务单写phase4-overseas-dispatch及grouped-dispatch-acceptance各脚本/合同4文件；总控在本对话内用一次性内部并行执行者分别单写phase5-overseas-fulfillment和fleet-trip-fulfillment各脚本/合同4文件，不新增用户可见独立对话。禁止执行真实HTTP/SQL/造数，只有离线合同；保持marker、身份仓和原命令证据，不借旧样本或伪造实载。真实LoadingPreview缺托位等实测时须等本轮真实测量，不能沿旧脚本用常数假定实际载荷。脚本写权不延伸到Java/新日历/其他在途业务；其他直接消费者发现后只报精确触点再分配。
+
+2026-10-19 18:55收尾并行：总控已实际执行Fleet/phase5两个脚本合同共78项全部通过，并独立复核4文件哈希与冻结交付相同；AGENTS索引1181项通过，前一检查点的长度/固定语义句阻断已关闭，主后端无须继续等待。原派送任务报告phase4与grouped两合同共15项通过，待总控核对最终文件及证据。继续复用原两个内部执行者，各自唯一修改phase5-root-fulfillment脚本/合同、fleet-test-env-acceptance入口/直接合同，收敛已发现的直接消费者；不新增用户可见对话或改动已冻结helper。原前端任务仅诊断Admin完整类型检查2GB内存不足，不提高内存限制、不改生产配置、不重复盲跑。总控保留共享集成、实际证据核对和最终报告；后端501项为删车辆预约字段前输入，最新删字段后25项与完整test-compile独立报告，不能相互冒替。真实HTTP、部署和人工页面/PDA验收仍未执行。
+
+2026-10-19 19:05实质复验：用户明确授权本次Admin完整类型检查临时4GB，总控经local-check执行完整vue-tsc（无文件排除、无配置修改）实际退出0，随后正常2GB下Vite构建退出0、5135模块、4.06秒；该授权仅覆盖这一次类型检查，已使用。最新车辆预约删除8文件逐SHA核对无漂移，详情四页签和FBA保留。原生脚本当前离线实跑分别为Fleet/phase5合同79/79、财务/合并合同16/16、phase4/grouped/root合同57/57、保留占位/在途交接合同44/44；这些是各自具体输入的本地脚本证据，不代表真实HTTP。总控修复实际LoadingPallet的Jackson Long箱数字符串读取，保留数量安全边界及长ID/版本。流程合同发现服务端updateDispatchCargo只追加站点、移除最后一托仍留旧目的地，已交原主后端按有效货物/预订和原站序最小修复及真实回归；不是增加业务范围。原派送专项接续费用覆盖与外接同主单加货的4个直接脚本/合同，FULL与PARTIAL保留正向覆盖，必须使用不同本轮实物，不允许已扫码后取消复用。独立Fleet专项入口及其余已发现直接消费者尚未全部接通，不能报脚本全量完成；日历新增预约仍不处理。3项既存pickup依赖失败、环境SQL/部署/真实HTTP和人工页面/PDA验收仍分别保留未通过/未执行状态。
+
+2026-10-19 19:11跟踪：总控实际读取路线修复日志，完整test-compile退出0，5类33项全部通过，含新FleetDispatchRoutePersistenceTest 7项；最终源码/测试快照待原后端交付核对，不把旧501结果扩展到本次新输入。脚本实测Long字符串零箱数在资源准备/两审/装车/空排车取消中的严格零比较已修，实际三合同122/122通过；随后补原生写命令空成功/缺业务体判未知并停写，phase5与root两合同96/96通过，各结果按实际输入分别保留，不拼成单次全套。两个内部执行者接续跨客户一主单共享fixture/验收4文件，以及混柜/换标两个原生留存入口（必要精准合同），仍不改日历新增预约、不执行环境操作；原费用专项4文件及根Fleet专项入口顺序仍待集成。用户询问剩余时长，总控按当前工作量估代码及离线收尾1–2小时，部署与人工验收另算；估计不是验收承诺，不因时间到达标记完成。
+
+2026-10-19 19:28集成检查点：路线修复3源码/4日志逐哈希与交付相符，33项及完整测试编译正式接收；跨客户一主单4文件逐哈希相符、35项实际通过；自有/外接共用主单成本消费者改为原生发车回执与真实实测托位，成本38项通过，主入口成本预期定向1项通过（不是整个入口通过）；费用/外接4文件逐哈希相符、根实跑35项通过；混柜/换标两个留存入口及精准合同3文件逐哈希相符、语法和7项通过，README登记合同4项通过。前述均为各自具体冻结输入的离线证据，不合并冒称单次全套或真实HTTP。
+
+剩余写权继续分离：原派送专项仅改显式return-redispatch原生消费者及合同2文件；内部执行者分别独占Fleet专项入口/直接测试2文件、通用TEST换标生产者/新合同2文件、正式单票海外阶段/直接测试2文件，不创建用户可见任务。容量池和UI4文件已交付冻结，根接灰度组化时间的直接测试，并修复容量脚本同作用域重复声明；四文件组合检查因容量语法及仍在写入的Fleet入口import中断，未执行场景，待上游冻结后重验，不计通过。根只接共享文档、直接灰度测试、成本2文件及证据；检查仍经全局单槽，当前有其他已知任务占用，按实际句柄等待，不抢锁。换标两申请合到同一实托后分别建车的物理冲突已交原后端只读核对，不擅自拆托、放宽占用或改变业务规则。真实测量缺项、既存pickup3项依赖、部署/SQL/HTTP及人工页面/PDA验收仍独立记录。
+
+2026-10-19 19:41集成检查点：全局检查槽释放，容量脚本语法复核实际退出0。Fleet入口、容量池TEST/UI及灰度直接合同、正式单票海外阶段、通用换标生产者与保留来源、显式退回合同九文件组合实际227项，226通过、1项容量编排静态断言仍匹配旧局部变量名；修正该断言后所属21项全部通过，未把两次运行冒称同次227全绿。原退回专项两文件已交付冻结，57项为专项自身结果，根组合已覆盖其合同。正式单票实测文件通道和通用换标生产者均已纳入根此次实际组合；共享实托换标仍待用户业务选择，不推定完整场景支持。
+
+同路线成本入口确认另一个真实接线依赖：其两张WAREHOUSE_TRANSFER货物与同主单外接不属于费用覆盖专用FULL/PARTIAL，不能伪造费用用例满足helper。原派送专项接续仅外接helper及直接合同两文件，最小支持显式普通原生安排模式，真实加货/复审/PDA实拣/实测装车/客户目的地及外接约定报价校验均保留；普通模式与原费用覆盖模式明确二选一，逐组费用有据、不复制猜测金额。内部同路线消费者等待正式签名后接线，两文件写权保持；原后端继续只读定位当前发车真实晚期锁点，为回滚脚本设计提供依据。未新增用户可见任务、未扩展日历或环境权限，未宣称部署或真实页面/PDA完成。
+
+2026-10-19 19:50收口进展：跨客户入口及夹具4文件交付逐SHA匹配，根实际运行入口/fixture/acceptance三合同55/55通过；明确CROSS_CUSTOMER、CAPACITY_POOL、SAME_ROUTE_COST三个当前用途，返回必须为所选本轮注册proof同一对象并匹配marker、dispatchNo、tripNo，严禁不同专项互借成功结果结案。夹具支持Jackson数量字符串并拒绝空值/布尔/非规范及超安全整数，context.checkpoint及HTTP写前fsync/未知结果停写已接入。根已在容量池caller明确CAPACITY_POOL并补主单编号，成本入口由唯一执行者接SAME_ROUTE_COST；这些直接调用点待上游外接helper冻结后组合复核。原79/16项临时证据快照已明确标记历史，新55项和当前输入及TAP哈希追加到原证据文件，不冒称单次全套通过。
+
+根已补正式单票实测文件通道、TEST换标生产者显式来源/合托前置限制/实测证据，以及跨客户和同路线两业务分摊的文档；登记合同实际4/4、三个已冻结生产入口语法退出0，后续文档小修最终门禁统一复核。原后端独占回滚脚本及直接测试2文件，按第二客户转仓晚期UPDATE定位、真实等待事务会话超时和完整数据库前后快照重写，不改生产Java。原派送专项独占外接helper及合同2文件，内部只读审查已从真实DTO/Service确认报价摘要、cargo目的地、费用字段和混合自有/外接同组规则一致，结果限当时暂态候选，冻结后再验证。另一个Admin任务占用全局检查槽，根跨客户两个语法检查已排队，保留原执行句柄等待，不抢锁、不重启其他任务。未部署、未执行环境SQL/HTTP，合托换标业务选择仍待用户。
+
+2026-10-19 19:53用户明确“本批支持整托同车”：两张换标单合到同一实托后共用一张原生排车，托盘/容量只计一次，换标单各自箱数、客户和扫码归属保留。主契约第一、八节已同步，此前待业务选择状态结束，不能把该场景仅前置拒绝当最终交付。主流程后端先完成当前回滚脚本2文件并冻结，再接原有dispatch/fleet来源模型职责，先交精确生产/测试/公共DTO及直接消费者清单供总控冻结；不允许仅解除去重、按第一来源/客户承载或不分来源FIFO凑通过。原派送任务继续当前外接helper2文件，不并改公共port；原前端任务复用为只读准备，定向列同托多逻辑来源的候选选择、容量去重、PDA扫码歧义和必要接口/测试触点，正式合同冻结后再精确解锁。四彩色图标页签、日历排除边界和环境操作门禁保持；未创建新任务、未追加环境权限。
+
+2026-10-19 20:01联合检查：共享槽已释放，原28228/60575两个跨客户语法句柄均终态退出0；外接NATIVE、同路线成本入口及其合同三个语法检查退出0。根逐项匹配外接2文件和成本2文件交付SHA后，实际串行运行16个相关合同文件（含费用覆盖、普通外接、同路线成本、跨客户入口/fixture/验收、容量池TEST/UI及GRAY、Fleet入口/成本/显式退回、正式单票、换标生产者和保留来源），426/426通过、0失败，TAP为后端`.codex-temp/dispatch-native-final-consumers.tap`。该结果覆盖当前已冻结的直接消费者组合，不代表脚本全量、共享实托新模型或环境验收通过。
+
+合托模型只读准备已形成方向：服务端完整来源集合及组成版本；物理占用与逐客户逻辑来源占用分离；逐dispatchItemId精确拣货不新增整托一键多写；LoadingPreview每实托一行。前端精确触点已交主流程，仍冻结待字段级合同。提供者事实已核实：换标专用绑定逐item更新实际position，application/customer/绑定箱数/sourceInbound快照仍保留；实际新旧唛与成功数量须按app+item先聚合，不能把独立application.lastlegOrderId当全部原货源或从箱数推件数。通用混合仓位后续无归属部分移动仅凭余额不能还原应用份额，方案不得退回FIFO推断。B仅只读核对下游守恒：当前物理托数去重、逻辑箱数累加；来源重量体积无证据保持未知，禁止把整托实测复制到每来源。主流程继续字段级DTO/贡献/SQL草案，根等待精确DDL后同步两个初始化基线；未执行环境操作。
+
+2026-10-19 20:07模型边界冻结：根已实际读取回滚脚本/真实Schema对应反例，独立运行rollback+cross外层两个合同63/63通过，2文件SHA为`fdc042d2b8abd5a08b7f99a0221402475bcddaa25d5da071e6c5f972a72b052f`及`73d3992390a8e1dff24d261344215ec42c3eee56fb3d0cc18b885ce20cf03e8b`；原专项83项为其不同命令范围，未混称根同次结果。README已按目标转仓晚期UPDATE、等待会话超时及全字段基线同步；新增合托表后取证表集合必须更新，当前结果不是新模型完成证明。
+
+主流程给出精确SelectionGroup/Source/Pallet与Candidate.selectionGroup、PdaItem/OrderDetail来源业务号草案，根已技术同意并要求立即产出原port公共骨架及其唯一设计记录；核对实际记录后解锁前端并行，不能等主流程全部实现再开始。Pick/CargoSelection形状保持；组版本绑定完整组成、完工轮次、位置及来源版本，草稿动作服务端一次原子处理全组，Create/AddCargo逐来源显式提交并重算完整闭包。本条只冻结公开骨架和分层原则；来源贡献保存/后续移动的生产者精确触点、内部port及DDL仍待主流程字段级方案，总控再按已有写者分配。B的派送只读终稿及仓库提供者事实已交主流程，禁止复制整托实测到逻辑来源或以换标申请生成的尾程单冒充全部原货源。环境权限未变化。
+
+2026-10-19 20:27共享实托实施检查点：三个既有任务均active。总控已逐字段及SHA核对实际SelectionGroup/Candidate/PdaItem/OrderDetail公开记录，前端已据此开始完整组选择、组成版本阻断及PDA同托/同箱唛明确选源；其新输入检查仍排队，旧73项/typecheck/build不扩展为新输入通过。派送专项已交付真实`RelabelDispatchSourcePort`骨架，SHA为`af771fd474faf6c411543b077c646479e6368b98ab3cab875c4cd6c0b3b24978`，总控核对三个方法及全部record参数与冻结合同一致后通知主流程接线；该专项独占新port/service/repository/mapper及持久化测试五文件，主流程不并写。来源提供者实现、完整闭包及锁内真实HOLD聚合仍在进行，不以骨架推定实现完成。
+
+总控已同步模块和海外统一空库基线：新增物理实托占用、不可变换标来源贡献两表，逻辑占用改引用物理占用，PDA归属新增真实来源贡献引用并保持四选一，整车明细按来源键唯一；海外实际表数为227。初始化/容量Schema及两份五表定义一致性合同实际26/26通过，日志为`baiyue-firstleg/.codex-temp/dispatch-physical-schema.tap`；未执行环境SQL。两份公开OpenAPI已据实际Java记录同步100个类型和29平台/7PDA路径，正式文档校验及新模型组合回归尚未完成。回滚脚本两文件已由主流程移交原内部执行者，补齐新两表全字段及零行覆盖、物理owner/link和普通来源四选一取证，当前语法检查仍在原session16553排队；原63项结果属于此前输入。主流程新物理占用10个真实Mapper/事务用例已写入，原Maven session49123等待共享名额；不因排队重建检查或抢占其他任务。当前瓶颈为来源提供者到主流程的真实行为集成及共享检查队列；代码/离线回归估计3–4小时，部署与真实页面/PDA验收另计。四页签、已确认整托同车、日历排除及环境权限边界未变化。
+
+2026-10-19 20:34实质复验：回滚两文件语法检查实际exit0，原内部写者定向合同62/62通过、零跳过；总控逐SHA确认两文件及被测模块DDL匹配，新增两表完整取证已接收，未据此宣称真实故障注入或HTTP通过。总控接口只读校验实际exit0，覆盖86个公开Java记录的568字段、336个可达本地引用及3份关联文档，重复键、来源组必需字段、五阶段和已删除车辆预约字段均检查；平台实际为30路径（29个本批维护路径加既有BOL打印），PDA7路径。首次本地校验将合法BOL遗漏于路径计数，核对真实QueryController后修正校验，生产路径未因计数而删除。该结果是字段/引用合同验证，未安装Swagger依赖、不冒称正式Swagger或运行时验收。
+
+主流程物理占用定向Maven已运行但测试编译失败：新DispatchPhysicalClaimPersistenceTest两处泛型tx.execute结果直接传assertThat导致重载歧义，10用例尚未执行；总控已交唯一写者按明确类型变量最小修复。前端报告新输入Admin7文件140项、PDA履约35项及业务标识4项通过，完整类型/构建仍待，不把旧完整门禁扩大复用。换标提供者Service/Repository/Mapper已落盘，专项继续H2真实持久化/锁测试；原换标producer两文件由原内部作者接续NEW/MERGE同组一次Create及原键重放、每来源归属/一实托实测证据，不扩展该入口到审核装发，也不并写留存consumer。独立只读审查同步检查物理占用基础；所有实现写权保持唯一，不新增用户可见任务或环境权限。
+
+2026-10-19 20:38独立审查发现正常链阻断：来源提供者以任务reviewedAt作为作业轮次，但正式客户确认会重写该时间；PALLET_BIND/SKU_SCAN仍保存确认前的INITIAL或返工作业轮次，造成正常已完工来源箱数归零且组成被判不完整。总控实际核对provider与RelabelApplicationService确认代码后，仅解除来源专项原5文件中的实际实现及直接测试冻结，要求按真实作业历史/返工边界识别并增加客户确认前后回归；port签名保持，原PDA/客户确认生产者不修改。冻结旧5文件哈希已匹配、12个测试仅为源码数量，不能记执行通过。主流程已通知继续按稳定port接线，待修复新候选后统一运行来源测试；物理基础独立只读审查未发现确定问题，草稿完整生命周期、来源集成及MySQL真实锁行为仍未证明。
+
+前端新一轮完整类型检查在默认2GB下达到堆上限退出134，未通过；本批此前一次4GB例外已消耗，未再次提高内存、删测试或排除源码，也不重复同一OOM检查。前端继续Vite/PDA资源构建并交冻结候选，总控待稳定输入统一收口完整类型门禁，不能以定向140项或旧全量结果替代。当前阻断均已明确负责人，不增加日历业务或环境操作。
+
+2026-10-19 20:51联合收口：来源专项已仅修Service及测试，改由真实COMPLETE.roundKey、PALLET_BIND/SKU_SCAN.round及返工归档边界识别作业轮次；新Service SHA `949ea59036d710af0cc0b81848a77e17da0da3de049e44124a36be141ee81fe0`、测试SHA `e745fe1da80ecdd1093fdb875f8e545b147558c0e1d256ee4edce81b2110a648`经根匹配，其余三文件不变。14个测试声明已交唯一Maven写者，尚无运行通过结论。独立前端审查另发现PDA将sourceBusinessNo无条件必填，实际普通入仓/退回来源该展示字段合法为空，导致无法选源；根已核对实际toItem、PDA查询及页面guard并交前端原范围修复，按真实RELABEL_ORDER类型校验换标业务号，其他来源仍要求真实sourceKey。新增普通wire/精确位置提交回归及Admin组字段可空语义一并核对，不能造业务编号或恢复旧别名。
+
+共享换标producer两文件已按完整选择组一次Create和原键重放收敛，NEW/MERGE共用主单并保留各自来源，SPLIT原闭包保留，实测按唯一实托校验；原作者32/32及两次语法exit0，根匹配SHA `3cf7c8bdd6bbad471fc9ab2401895f1ee38cce25d34bd7604861dfa3ab23d450`/`bfbb872c7648abe15ece27dbdd927ad65469e3759baac7ebd4ed364011275a95`，README已同步，不再以所有共享托前置拒绝当交付。既有留存consumer仍只继续SPLIT，真实共享组装发全链没有因此宣告通过。
+
+根完整运行脚本门禁：83个scripts根测试文件加131个Admin模块合同，共214文件，2204 tests、2199 pass、5 fail、0 skipped。首次子进程输出绕过PowerShell重定向，故针对同5项未解决失败再以Node reporter destination捕获，数量一致，完整TAP在`baiyue-firstleg/.codex-temp/dispatch-script-full-contracts-results.tap`。精确失败位置为phase3-producer-chain-contract:698、database-schema-alignment-migrations-contract:113、java-quality-summary:64、synchronous-dependency-contract:106及114；已交内部只读逐项归因，不直接判为既存无关或豁免，不改断言换绿。主流程另已产出SourceOrigin八字段及CargoLine尾字段，根核对Java SHA `5086523d9df7c7d00840d391e9608b1685e4edb71d19154b1608339afe7421e2`后，派送专项接其原delivery/financefee直接消费及测试构造点，前端接原CargoLine类型/wire，根接OpenAPI；公共Java主流程单写，SQL根单写。PDA逐来源位置贡献和草稿完整生命周期仍待主链证明。当前没有部署、环境SQL或真实HTTP。
+
+2026-10-19 21:08新输入检查：根实际读取物理占用修正Maven日志及JUnit XML，10/10、零失败/错误/跳过，源码五文件哈希与主流程报告逐项相符，主生产类时间早于测试编译及报告；该结果仅证明物理基础。来源14项与派送/费用15项组合实际29项，27通过、1失败、1错误；两处经B定位均在测试：移走明细后原实托闭包仍可有效，须另读新实托验证旧绑定失效（不是reviewedAt轮次规则错误）；重设Spy成功桩时when触发旧失败桩，改doAnswer，保留真实CAS/回滚/溯源断言。两测试新SHA `93e662367224e61850b0e57b29eb9e6d68e5ae4edc09e5c109c0bdb9cbc883ce`及`b989d8db720bd10aa4c928297ed387486353a06922d043d298b234bbc3c26b29`经根匹配并已交唯一Maven写者复验，生产未因追绿改动。
+
+SourceOrigin公开文档已按实际Java重新同步101个typed schemas，根本地校验87记录、577字段、337可达引用、3份相关spec实际exit0，29维护平台路径外保留既有BOL，PDA7；不是正式Swagger或真实HTTP验收。根完成本批证据网关REQUEST/READ_WRITE/MIXED同步事实，语法通过，13项依赖合同11过/2失败；剩余明确为另3个预约Feign及2个废弃/领星HTTP未登记，不把已登记本批网关再列缺口。质量文档库存按实际扫描100份同步基线并显式纳入dispatch-evidence/fleet-preparation，3/3通过，未重生或改写旧覆盖率和SpotBugs结果。全214文件旧2199/2204结果保持原范围，未拼接冒称新全量全绿；phase3排版500字符断言、迁移目录版本及上述跨域metadata缺口仍保留未通过。
+
+前端报告修正后Admin8文件147项通过、PDA43项通过，23源码快照及Vite/App资源构建仍待最终交付，完整类型检查仍为2GB OOM未通过。主流程另明确释放新增`DispatchItemSourcePersistenceTest.java`给既有B专项，根已下发并同步主契约；生产四文件与公共port仍A独占，B仅写该一测试，Maven仍A唯一执行。A并行完成来源闭包/草稿/PDA精确额度；目标托向已排车实托追加成员的palletops风险由根只读核对最小修复边界，尚未新增其写权，不把在途假设当已修复。所有环境操作门禁和日历排除范围保持。
+
+2026-10-19 21:19本轮类型门禁：用户明确授权“6G，直接干”，根通过local-check实际使用6144MB执行完整Admin vue-tsc，包含源码和测试、不改项目配置，退出2且未再OOM。诊断仅在SailingCalendarView.test.ts第152、154、185行，共3处字段或MessageBoxData类型不符；不能标记完整门禁通过。执行前1022输入快照与执行后比较发现其他在途业务DomesticContainersView.test.ts、SailingCalendarView.vue，随后同一日历测试文件也变化，证据保留在根`.codex-temp/dispatch-final-typecheck-6gb-result.json`与原始输出；不将其冒称稳定全项目结论。排车23文件逐SHA仍一致，聚合6b31b6c02acfc616c0b5a4d2bfec6e9f11706cb27bc5c18fb8af39cbf7cf018f，Admin147/PDA43及Vite、App资源编译证据已接收，完整类型门禁独立保留未过。
+
+B新增DispatchItemSourcePersistenceTest.java已冻结16用例，SHA 7da5553596458350d8a796421cb15b355306288375cfa8197daa1ba6c09e3e1c经根核对，已交A唯一Maven窗口；受控port的真实Mapper/H2组件测试不能代替完整provider组合。根另安排既有内部代理只读审查该测试，不授生产写权。palletops已确认目标已排车实托仍可被另一申请追加的顺序缺口，空目标/不相交来源并发还需共同串行点；A负责冻结最小port/DDL协议，仓内调用文件在协议冻结前仍只读，不以简单计数或单次重读宣称并发闭合。以上未新增对话、部署、环境SQL、真实HTTP或接管日历新增预约。
+
+2026-10-19 21:22并行收口：A已提出最小共同串行点，总控按主契约冻结`ll_physical_pallet_guard`两字段及`PhysicalPalletSerialPort.lock(List<Long>)`，无第三owner、状态、TTL、HTTP或迁移。B独占inventory port/service/repository/mapper与真实持久化测试五文件；A独占dispatch/draft消费；既有内部native_fleet_script独占PdaPalletOperationService/Mapper、现有ServiceTest、新本域Repository及真实冻结PersistenceTest五文件，三个仓内分支统一门禁及原补偿；总控独占模块/海外统一SQL、初始化合同和说明，新增永久guard后海外空库表数228（国内227不变），六表定义同步校验已排队。原内部回滚脚本写者接续两文件23表完整快照，不改既有relabel生产者冻结包。B已交16用例经独立只读复核无已证实签名/Mapper问题，仍待A运行，受控provider及直接准备pick账本的边界继续保留。未新增用户可见任务或环境操作。
+
+2026-10-19 21:30交付复核：B永久实托串行port/service/repository/mapper及12项真实Mapper/H2事务测试已落盘，根逐SHA匹配并独立只读审查，无确定生产锁或签名缺陷；两项并发测试仅在SQL前释放latch并等待Future超时，尚不能排除线程未进入数据库，已仅解冻该新测试要求真实数据库等待观测，不放宽协议、生产四文件仍冻结，Maven待A统一运行。根自己的结构门禁已实际exit0，TAP 27 tests/27 pass/0 fail/0 skip，覆盖两份SQL的永久两字段guard、六表一致性和容量约束；海外228表、国内227。该证据不表示环境SQL或业务链已通过。草稿完整组仍待接入，根已向A请求明确释放准确草稿文件给原B以继续并行；确认前保持单写者，不重复派工或并写。
+
+2026-10-19 21:34持续复核：回滚脚本两文件已按新永久guard补齐23表，根读取范围、COUNT与全字段快照、普通来源空贡献及四来源XOR断言，逐SHA匹配脚本b71320d1918cea7e63779499ac3c0f2c0eeca4ad8547f47e14fa3ac1946f42d0及测试da00e939817fcc26cf5cf54d104894fe081329c556dc083e0deaa6807039be46；作者报告75/75合同与两语法exit0，根读取共享检查Last result同一精确标签exit0，不重复运行。B共同锁12测试已改为真实H2会话guard写语句与BLOCKER_ID关系，根实际读取关键代码并匹配新SHA 444bd8d361f4d90fbdaf1e4d1d205906b5452096670f57bd3459906716e36c7e，仍待A运行；生产四文件不变。仓内caller五文件已落盘尚未冻结，根发现TransactionTemplate默认隔离级别会使MySQL RR中的组成重读沿用旧快照，已交原唯一写者明确RC并补底层默认RR反例，不以H2默认RC或清Mapper缓存代替该证明。环境门禁及日历排除范围保持。
+
+2026-10-19 21:49本轮检查点：根实际读取`.logs/dispatch-source-serial-persistence.maven.log`及六份JUnit XML，提供者14、派送/费用15、冻结来源16、永久串行12合计57/57，零失败/错误/跳过，实际重新编译1072生产与460测试源码并BUILD SUCCESS；444/7da测试SHA匹配。其后A已增执行时轮次/来源复核，生产发生变化，57不覆盖后续输入。A明确释放草稿Service/Repository/ClaimMapper/PersistenceTest四文件并停止写入，总控补读此前被最后快照遮住的中间交接确认后立即派B；主契约已同步，B另维护原ItemSource测试的真实轮次列。B缺物理占用整托移容器与全token/operator续期Service桥接已精确交A，禁止B跨层绕过。
+
+根同步`relabel_round_key VARCHAR(128) NOT NULL`两SQL、初始化合同及说明后，实际经local-check运行结构/容量/23表回滚三文件，TAP 102/102、0失败/跳过，输入SHA在根证据清单的roundGuardSchemaRollback102。共享public Java仍5086523d9df7c7d00840d391e9608b1685e4edb71d19154b1608339afe7421e2，前端23文件逐SHA仍零漂移，未重复资源构建。新Mapper注册合同正在原session23482等待共享检查位，未启动或记通过。
+
+仓内caller实际表结构复核发现计划托盘不存在warehouse_pallet_id，原写者已改真实pallet_no+父仓+客户/plan分配链，新真实表结构测试补不同仓同码；根已逐SHA匹配。继续逐入口核对又确认普通assemble/disassemble/swap/unbind因relabelMutation为空会跳过共同锁，普通AVAILABLE来源可向已排同目的仓目标追加，故同一五文件包已再次解冻给原唯一写者，需将generic分支也纳入原完整组成/RC重读/运输claim与锁内补偿；不增加页面、接口或资格。此包等待新冻结指纹，不把旧10项未运行用例当修后结论。A其后一次清理编译撞到B草稿在途方法，测试未执行，已要求等输入稳定后统一运行；不把WIP编译失败判为业务回归。环境SQL、真实HTTP、部署及页面/真机验收均仍未执行。
+
+2026-10-19 22:11收口检查点：根实际读取`dispatch-merged-stable-integrated.maven.log`，本轮176项为165通过、2失败、9错误，未判整体通过。数值事实规范化、旧夹具缺列及断言修正后，`dispatch-merged-source-normalization.maven.log`的40项为37通过、3错误；其余3项为H2测试DDL不支持MySQL布尔求和CHECK，改等价CASE并保留四来源唯一约束后，根实际读取`dispatch-merged-main-caller-corrected.maven.log`，新真实提供者整托主链10及仓内caller旧单元20合计30/30，零失败/错误/跳过，BUILD SUCCESS。该主链覆盖同/跨客户合托、各来源扫码与一次SHIP、回滚重试、取消重排和一托容量，不替代真实HTTP、全部五阶段环境验收或页面/设备验收。
+
+草稿20、物理claim/桥接13及仓内caller持久化20在176项批次中实际通过；来源17及主流程11、PDA读取1、整申请2在后续40项批次实际通过，分别保留输入边界，不混加成一次全绿。普通计划真实表结构新用例22:08因H2同schema约束名冲突失败，交A仅修测试DDL等价命名；A明确释放的`DispatchRepairWorkflowTest.java`已交B唯一修正旧装配和旧物理列夹具，原B五文件继续冻结，A保留唯一Maven执行权。
+
+根Mapper门禁原session23482已实际exit0：10个持久化模块、396个Mapper注册通过，不再记排队。用户本次6GB完整Admin类型检查已实际终止exit2且无OOM，三项诊断均在`SailingCalendarView.test.ts`；排车23文件逐SHA未漂移，但检查期间其他域三文件变化，故不能宣称当前全应用门禁通过。排车147项Admin、43项PDA及资源构建证据仍单列；不改日历、不重复使用一次性内存例外，不提交、部署或写环境。
+
+22:14结构事实校正：此前“计划托盘不存在warehouse_pallet_id”只读取了CREATE块，结论不完整；模块lastleg.sql第809行的有效guarded ALTER会补该列，第827行起还会补分配箱数等字段。根已要求A按最终初始化结构和真实收货状态修普通计划用例、保留生产冻结，不以H2缺列夹具反向改业务模型。新增只读复核交既有内部审查者，仅核对四个主链生产Service的完整来源、扫码额度与原货源归属，不并写、不另开Maven。
+
+22:17内部主链只读审查结束，无可确证新生产缺陷；根逐SHA复核四Service与主链测试均匹配，指纹及范围写入根临时证据清单mainSourceReadonlyReview。核对覆盖完整闭包与锁后重读、逐来源客户/原货源和额度、原命令重放、扫码库存与归属同事务、确认装车不再SHIP；外部车队/测量仍受控、测试未由审查者运行，不能据此关闭运行验收。
+
+22:21直接消费者收口：caller原作者已仅修Mapper与持久化测试两文件，以真实warehouse_pallet_id取计划来源，保留父仓/客户/plan/allocation/line隔离；测试改从完整最终初始化提列，原20方法保留并新增1项，覆盖同码异实托/异仓/未绑定排除及展示码不同不漏真实绑定。根实际匹配960bb9/a8ef7e；旧20通过不覆盖新输入，21项待A唯一Maven。B仅修DispatchRepairWorkflowTest的真实provider/Serial、新占用与换标事实，保留9项业务断言，并按最终真实计划写customer101和physical501；根匹配最终4a4d01，已交A，不再等待其他实现写者。其余包冻结；共享检查位当前被另一个Admin检查进程64760占用，根实际Get-Process确认存活，不抢占或绕过限流。
+
+22:32草稿最后锁序包已冻结：B仅两文件，根匹配Service a2682e、Test35b7c4，原20加4参数化真实H2 guard SQL/阻塞会话场景共24；等待后复核租约，旧动作回滚及新owner不释放的断言已读，尚未Maven，A已获最终输入。根确认唯一手工构造器直接消费者已同步，主契约补纯释放/租约锁序边界。普通计划完整最终初始化用例实际1/1、BUILD SUCCESS，日志dispatch-plan-final-initialization.maven.log已核对。
+
+根实际离线全量83根文件加131模块合同共214文件，2218项中2214通过、4失败，Node测试输入未漂移。原shell重定向未保存原生控制台的完整TAP，首次仅采纳实际终止计数，不以不完整文件证明精确失败归属；已用Node reporter-destination排队session8791保存完整报告，不启动其他重复检查。当前共享执行位仍由其他Admin检查47088占用，根实际进程存活；A完整Lastleg模块检查等待最后包/执行位，未判通过。前端补核对确认最新23文件未跑完整Admin Vitest，历史11超时不作当前通过；Client601/type/build仅旧交付文字、暂无独立原始日志。已让原C准备默认资源下必要离线检查，暂不入队，待根通知后运行，避免挤占后端；不重复使用本次6GB例外、不改超时追绿、不动日历新增预约。
+
+2026-10-19 22:57收口检查点：完整Lastleg运行22:44:52已终止，3075项为3056通过、6失败、4错误、9跳过；草稿24、整托主链11、冻结来源17、仓内持久化21/单元20、Repair9、provider14在该输入实际通过，整体未通过。A负责BrowserApiBoundary/DispatchService/ReturnCandidate三个旧测试，内部唯一接四个旧预约/转运直接测试；其中A先前已改的Repartition/Pagination两文件在派工交叉时被内部读到漂移，内部未写即停，A明确释放后才继续，现四文件66071b/b9196d/5fbe3b/787e78已冻并根核对。没有恢复头客户、旧状态或新建预约。
+
+只读证实客户确认前合法作废会真实RELEASE库存但保留旧item/position指针，旧provider再次引入该CANCELLED历史会误挡新排车。B仅Repo+ProviderTest两文件修复，根匹配Repo12b957、Test最终6eb43b（SKU方式NULL，16项待Maven），保留全部真实位置及残余HOLD阻断、不扩修纯SKU完成/HOLD生命周期。Root主契约同步边界。所有本轮修正已冻结，A已获明确通知立即按受影响类入队并编译全部测试源，不再等待未证实疑点，不重复整轮已知旧失败。
+
+独立旧换标出库取消另有真实业务冲突：出库取消要求READY_FOR_OUTBOUND，却调用被申请状态机禁止的CANCELLED；原测试mock掩盖该矛盾。相关ReturnOutboundClosureTest及生产保持冻结，根已发异步业务选择“只取消出库安排、保留换标回待安排（推荐）／本批暂不处理旧入口”，待用户回复，不伪造来源取消通过。该问题与确认前合法作废历史过滤分开。
+
+前端必要补验已终止：Admin418文件3541项中3540通过、1失败（adminDensity对ContainerLastLegFeesPanel缺density-action），这两个外域文件运行中漂移，本批23文件零漂移，故不判当前完整Admin通过；Client629/629、typecheck、build均exit0，三个检查同一661ac51a输入前后不变，原始报告在根`.codex-temp/dispatch-current-full-gates-20261019T144504659Z/report.json`。根已实际读取原始诊断、计数及SHA。完整离线脚本214文件2218中2214通过、4失败，完整TAP已保存并核准失败为phase3正则、历史迁移版本、预约Feign及Lingxing/Discard HTTP元数据；原shell重定向不完整文件不作完整TAP证据。根清单已记录各自边界，原6GB类型检查仍exit2/日历3诊断，不借其他进程标签判通过。环境SQL、提交、部署、真实HTTP和页面/真机验收均未执行。
+
+2026-10-19 用户追加确认及授权：已确认换标、关联出库尚未扫码时，只取消本次出库安排，保留换标成果，退回待安排。内部`native_capacity_consumers`独占`DeliveryTransferService.java`、`DeliveryCancellationRepository.java`、`ReturnOutboundClosureTest.java`，原非TRUCK方式不改成TRUCK、不伪造换标再次确认；真实取消/清关联/回滚验证交A执行。最新65输入定向111项为110通过、1失败；根查明Repartition夹具allocation引用item11/physical12却插入item1/physicalNULL，仅把夹具改为真实11/12，新SHA f2f717，生产联接及原禁止拆分/并发断言不改，待统一复验。用户同时更新目标，明确授权当前排车TEST部署、操作测试数据库、真实HTTP与内置浏览器验收，Admin/Client1920×1080、两PDA390×848。总控统一环境写入和发布；现有独立任务不自行触发。此前“未获环境授权”限制已被本次明确授权替代，实际部署/HTTP/视觉仍待执行，不以授权当完成。日历新增预约不接管，开发/生产环境不操作。
+
+2026-10-20 00:06收尾检查点：换标取消按用户确认保留成果/回待安排已完成，三个生产与直接测试文件冻结；最终定向94/94通过，Lastleg完整3081项为3072通过、0失败/错误、9条件跳过，1706输入核验零漂移。File完整242/242通过，286唯一输入无漂移；海外PDA本轮H5构建及verify-h5退出0，85产物、127输入及23冻结文件无漂移。以上仅各自本地输入证据，真实版本与HTTP仍单列环境主契约。
+
+总控已执行获授权的八张新增空表及File三文件发布，详见环境主契约；未删除旧链。339旧排车、163草稿及关联218出库/269派送的备份废弃重建仍待用户明确处置答复，不能用默认审核/来源/实测补齐旧模型。CI #369单fork1GiB堆OOM，未部署；A只读核对最小生命周期修正，不增加并发或任意扩大内存，根检查真实代理cgroup容量。根依据实际Lastleg a563而非初始SCM e067组装d891候选，B独立核验346路径及已发布修复保留。C交付Client实际运行513b之上的六文件最小移除提案，根已核对并推送ba659固定标签，Client #432已排队；只是发布准备，未判运行成功。共享SQL/环境/根文档仍由根唯一执行，日历新增预约不接管。
+
+2026-10-20 00:17发布检查点：Client #432精确ba659成功、容器健康、五公网资源与容器一致，临时Job配置完整恢复；真实DOM交互/CDP连续超时，仅确认登录和到达列表路由，不判视觉或请求量通过。A只改并冻结Lastleg POM一处reuseForks=false（0f2312），根基于已审d891组装8898、347路径并推固定标签，#370完整测试执行中、DEPLOY=false；代理无残留fork/cgroup OOM，只调整测试生命周期，未增堆/并发。旧链处置问题仍待答复，主版本、Admin与海外PDA保持未切换。
+
+2026-10-20 00:31收尾检查点：本机CI资源/流水线三文件实际31/31通过、exit0，session68393已终止，没有残留本批本机重型检查。CI370的唯一当前断言失败确认为转运旧运行生产与当前在途测试夹具误配；A/B独立逐blob核对后只恢复候选测试到a563 d6823085，保留50用例及原ownership拒绝，当前工作区不动。B对20个差异生产输入和316个已纳入Java/MJS的直接配对未发现第二处同类偏差。根推送d761固定标签（346路径），队列8257待370结束后完整验证、不部署；旧轮继续收集其余失败，不能将局部通过当全量成功。Client新开页DOM读取17条、无创建按钮；尺寸、截图及网络观察工具仍超时，视觉/请求量待验。旧测试运输链处置仍未获答复，没有删除或结构切换。
+
+2026-10-20 00:39 CI检查点：#370已终止FAILURE，496份类结果为依赖134加Lastleg默认3027、合计3161项，1失败/0错误/9跳过，无OOM；默认阶段失败导致后置SQL语义两类未执行，未声称全部断言完成。只有已定位并在下一候选恢复的转运夹具。原队列8257已转为#371并运行，精确d761、完整测试、不部署；134项当前通过不是整轮通过。根继续跟踪该明确运行句柄，不重启/重复派工。浏览器Page.getLayoutMetrics在正确读取本次CDP说明并设置1.5秒命令期限后仍工具超时，真实尺寸/截图/网络仍待验；新问题仅索取两PDA TEST H5入口，现有配置只找到API地址，未借用历史会话或猜域名。旧链处置确认仍未答复，无额外环境写入。
+
+2026-10-20 00:53权限准备检查点：根只读核实当前IAM三个新增动作资源缺失，父列表有效；按既有本轮TEST非破坏性数据库授权及已验证源种子，只新增5107065/66/67三个目录资源，未改岗位关联/账号/安全版本/会话，回查新资源关联授权0。实际回执与切换待办只列环境主契约。CI371当前1176项无失败/错误，根实际从控制台提取确认转运原50项全过，修正候选问题已复验；完整CI及后置SQL语义仍执行中。两项缺失输入保持：旧运输测试链处置答复与两PDA TEST H5地址。
+
+2026-10-20 01:20收口及阻塞审计：#371精确d761已SUCCESS、clean package、完整执行、未部署；JUnit3212=3203通过+9跳过、0失败/错误，Lastleg3027默认+51后置SQL合计3078，依赖134。原夹具50/50已复验，9跳过原因及不同本地输入计数只维护环境主契约，不冒充真实HTTP/四端验收。节点无残留Maven/Surefire、cgroup OOM0，所有本批检查句柄已终止；A200/B157/C120均idle，无新派工。六容器健康且Lastleg/Admin/两PDA仍旧运行版本，Admin源基线未变；海外H5127记录输入/23冻结文件/85产物复算0漂移，未发布。
+
+同一旧运输链备份废弃重建确认已连续至少三轮未答复，01:17主单/草稿仍339/163；PDA TEST H5地址请求亦未答复。根未把通用数据库授权当作该删除/重建确认，未执行旧链处置或匹配主版本切换。可独立推进的候选及验证均已收齐，当前剩余端到端推进依赖用户输入，满足目标blocked审计；完整目标不标complete，收到所需输入后按实际状态继续，不重启已成功CI或接管日历新增预约。
+
+2026-10-20 07:51输入补齐：用户提供两个本地PDA H5入口，根只读打开后确认5175国内、5176海外，两端登录前390×848截图完成。环境与验收证据仅维护环境主契约；未登录、改配置、重启、发布或执行业务写入。发现本地配置指向非TEST代理，已询问是否切换本地服务后继续，未把本地入口当作跨环境授权；旧链备份废弃重建确认仍未答复。三个既有任务不重复唤醒或派工，主版本切换与完整作业验收仍未完成。
+
+2026-10-20 08:05本地PDA接通：按用户明确同意，仅切换两项目未提交本地API配置；HBuilderX自动重启，实际代理日志确认为TEST，两端正常UI登录及只读任务列表入口完成，各首次入口1个业务GET。有效截图及工具缩放限制只维护环境主契约；未领取/扫码或改任务状态。入口与本地环境切换不再待答复；旧链备份废弃重建仍未获确认，未推进主结构/Lastleg/Admin/海外H5匹配发布，不将本轮入口验收视为五阶段验收完成。无新派工或源码写权变化。
+
+同轮海外H5配置输入变化已由根经local-check重建并校验，均退出0，85产物相对原构建不变，未发布。共同冻结文件复查发现两个Admin弹框当前输入变化，后续集成须按新输入复核，未覆盖或自行收回其他写入者文件；完整指纹和适用限制仅维护环境主契约。
+
+2026-10-20 08:26用户明确旧运输TEST数据直接删除、不需要备份，原删除重建授权阻塞已解除。根为唯一SQL/发布执行者；复用内部代理分别只读审核当前Admin两弹框变更、旧运输关系闭包和实际运行发布基线，均不写环境、不改其他会话文件、不创建独立任务。根08:25只读预检主单/草稿等计数未变化，尚未删除/切换。当前阶段转为清理方案闭包与匹配发布准备，后续由根统一执行并验收，不再重复询问是否备份。
+
+## 2026-10-18 预约演示问题交接与原总控退出
+
+用户明确指定既有对话 `01a14f36-9fae-7dc0-90e6-1d3c54d22de6`（Bug 处理-1）处理 D1674 演示中的三个问题：保存预约后页面 A0409、查看原排车单后事项弹窗未关闭、继续安排本批车辆提示操作资格已变化；并明确 `01a13df2-c639-7560-a3e2-30bc23a579b3`（预约）不再担任总控。原对话已将操作指南、四张用户截图路径、已有诊断和保护边界发送给指定对话，停止开发调度、修改与部署。下方历史预约总控身份不再代表当前授权；本次不指定新的全局总控、不新建长期专项。
+
+接收对话 cwd 为 `C:/Users/BY-OY/Desktop/code/chongchong-global`、host local，属于本表 TEST 项目范围。本次交接仅覆盖这三个缺陷的定位、局部修复及离线验证；不自动授权提交发布、SQL、真实 HTTP 或测试环境写入。原两箱样本及用户已操作的领导演示数据保持，禁止重建或重置来绕过故障。涉及本表排车修复任务仍持有的文件时先核对当前写入状态，不覆盖其修改；原对话不再并行处理。接收对话直接向用户交付结果。
+
+## 2026-10-18 排车修复分工
+
+用户先创建三个待分工对话，随后明确由规划对话 `01a14cd6-4647-7b32-b719-f009dec87ae0` 只做文档规划并向以下三个对话分派修复。规划与精确文件边界见[排车流程修复规划](海外仓业务/排车流程修复规划.md)；本轮为有限缺陷修复，不新建长期专项。三个对话均已核对归 TEST 项目 `c64729ff-6710-43c6-8ef2-d84e9666cc1e`、host `local`、cwd `C:/Users/BY-OY/Desktop/code/chongchong-global`。
+
+| task_id | 对话 | 当前职责与写权 |
+| --- | --- | --- |
+| `01a14d16-8631-7de2-acde-67050ce902b9` | 排车修复 | Lastleg后端修复与代码集成唯一写者；取消释放、派送状态、换标全托、合托来源及最小前端能力契约；直接测试与必要OpenAPI/结构定义，唯一后端Maven执行者。 |
+| `01a14d17-02a2-7890-90bb-33067a1eb42f` | 排车修复-2 | Admin/PDA直接消费页面、组件、API/类型与相邻测试；修复动作提示、换标草稿和恢复错误，接入稳定后端契约；不改后端或预约核心页面。 |
+| `01a14d17-17d8-7072-849b-37250083b676` | 排车修复-3 | 独立只读审查与连续场景回归设计；仅独占新增 `lastleg-service/src/test/java/com/baiyue/lastleg/dispatch/service/DispatchRepairWorkflowTest.java`，不改生产实现、已有测试或共享fixture；Maven交后端负责人执行。 |
+
+用户本轮已授权以上修复实施及必要离线验证；规划对话仅写规划、登记和最小路由，不改代码。执行者在自身对话报告，由规划对话读取并转达，不因派工自动获得向其他对话发送消息的授权。保持当前工作区和分支，不提交/推送，不新建对话、worktree或项目副本，不启动服务，不执行SQL、真实HTTP、部署或环境写入。
+
+本批仅覆盖规划中精确缺陷，不接管预约核心或同步性能。既有预约批次分配和工作事项接线必须保留。派工时“预约”对话正在执行固定18文件提交发布；与其活动写入或共享构建重叠时先只读核对并报告，继续无冲突范围。前序任务环境授权不传递；不同任务不得并行写相同文件或运行共享后端Maven。部署与实际验收事实仍只维护两份环境主契约。
+
+2026-10-18 用户在本规划对话追加明确授权“请提交代码，且帮我部署，然后验收”。本轮仅将已独立复审通过的排车修复候选提交、按发布需要推送，并部署到上述 TEST 项目的 Lastleg 与 Admin；覆盖前段针对本批提交、部署及真实 HTTP 的禁止，其他边界保持。后端“排车修复”唯一负责精确候选提交、Lastleg 发布及本批新建合成样本的接口验收；前端“排车修复-2”唯一负责 Admin 精确候选提交及配套发布，等待 Lastleg 就绪后串行发布；“排车修复-3”只读复核候选、部署版本和验收证据，测试文件继续冻结。规划对话维护分工与环境主契约，不接管代码或执行器。
+
+发布前核对当前分支、冻结哈希、实际环境与 Schema，保留其他窗口未提交修改，不全目录暂存、不切分支、不创建 worktree。本轮真实接口的非破坏性业务写入仅用于可识别的新合成样本，不操作既有业务样本、不伪造外部真实凭证。执行 SQL、删除、重置及无关配置发布不包含在上述概括授权内；若实际结构不满足新版本，先交付具体差异、最小 SQL 与影响范围，再落实单独授权。未取得结构前置条件不得发布不匹配的服务。人工页面与 PDA 硬件验收仍按现行规则独立报告，不能由 HTTP 或 Job 成功代替。
+
+用户随后通过本规划对话的确认项明确回答“授权执行这份两表 SQL 并继续”。授权仅限 TEST `baiyue_lastleg` 的 `lastleg-service/target/dispatch-repair-test-schema-20261018.sql`，SHA-256 `0d016752bac700d67de943e82a03db50853986c5dc3efa35f178ca8eb3ab0f6b`：调整 `ll_exception_return_item` 的原箱字段、索引及约束，并新建 `ll_return_carton_stock_receipt`。由后端“排车修复”唯一执行，执行前重新核对实际环境、文件哈希与当前结构，执行后只读核验；不包含其他 SQL、业务数据删除/重置/回填。结构核验通过后沿既有授权继续 Lastleg、Admin 发布与新样本验收，无需重复请求相同授权。
+
+## 2026-10-15 库存历史还原并行只读验收
+
+用户明确授权复用现有“库存分析-1”和“库存分析-2”，总控为“平台销量总控” / `01a13496-1713-7ac3-9981-1ae9ed551571`；TEST 项目 `c64729ff-6710-43c6-8ef2-d84e9666cc1e`、host local、cwd `C:/Users/BY-OY/Desktop/code/chongchong-global` 已核对。仅本轮临时验收，不创建长期任务，不改变原业务代码写权。
+
+| task_id | 对话 | 本轮只读职责与证据写权 |
+| --- | --- | --- |
+| `01a137dd-dc62-7000-88b9-fb1df4a2dd22` | 库存分析-1 | 真实流水归并、日末库存及独立样本对账、UNKNOWN原因；仅写后端 `target/history-review-collection-*`。 |
+| `01a138f8-4b84-7d01-b47a-3caaf160e6f6` | 库存分析-2 | 周转率公式、排序、货主汇总和固定版本导出；仅写后端 `target/history-review-query-*`。 |
+
+允许只读测试SQL和已授权账号的HTTP查询验证；禁止SQL写入、业务代码或配置修改、部署、停止采集、额外领星请求、Git提交及子代理。总控唯一负责运行、发布及主文档收口，主动读取专项结果。原采集与指标两个旧任务无法被当前工具访问，本轮未向其成功派工。
+
+用户随后明确授权让“库存分析-2”直接修改新发现的同秒长唯一余额链误判，覆盖其只读限制。仅移交 `InventoryHistoryCalculator.java`、`InventoryHistoryBuilder.java` 的计算修订签名和对应history直接测试；使用已有流水本地重算，公开日末口径保持，禁止额外领星请求、环境写入、提交或部署。该任务获得一次定向Maven测试窗口，总控暂停并行Maven；总控负责审查、提交、发布及真实复核。
+
+## 2026-10-15 预约工作日历开发分工
+
+用户明确要求保留现有开发任务，并新建“工作事项后端”“预约页面前端”两个独立任务。用户随后在“预约”对话明确指定 `01a13df2-c639-7560-a3e2-30bc23a579b3` 接任开发总控，原总控 `01a13a8d-e968-7962-906b-1a514792d921` 仅保留原型及业务文档支持；本次交接覆盖此前原型对话的开发调度与共享文件写权。三个开发任务均使用 TEST 项目 `c64729ff-6710-43c6-8ef2-d84e9666cc1e`、host `local`、cwd `C:/Users/BY-OY/Desktop/code/chongchong-global`；不切换到另一开发环境目录。以下是本轮预约工作日历的唯一分工，不改变其他业务专项的写权和环境授权。
+
+| task_id | 对话 | 稳定职责及独占边界 |
+| --- | --- | --- |
+| `01a13df2-c639-7560-a3e2-30bc23a579b3` | 预约 | 当前开发总控兼预约核心后端：保留来源、核实、覆盖、批次和预约核心写权，但本批移交后端专项的原域适配触点及其直接测试除外。负责本轮全部 Firstleg 来源接口、直送卸货/还空守卫，开发调度、检查点、共享 DDL/SQL、IAM/公共门禁集成和 Maven/验证窗口；不得与两个专项并写。 |
+| `01a13e1c-9101-7a43-8445-771685ff315e` | 工作事项后端 | 原 `appointmentwork/`、同包测试、独立 OpenAPI/DDL 提案写权保留；新增本轮 Lastleg 原域适配、`inboundplan/work/`、`DispatchService`、`DispatchRequests`、`FleetTripExecutionService` 及其直接 Mapper/DTO/测试写权。V13 首批已明确将 `InboundFbaAppointmentService` 及核心预约/分批测试交回开发总控，专项不再写入。精确路径见开发协作契约；不改 Firstleg、共享 SQL/IAM/公共门禁。 |
+| `01a13e1c-db36-73e3-a231-d6649c51664b` | 预约页面前端 | 原预约页面范围保留；新增货柜详情/码头拖车 API、车次列表/详情/计划弹窗、排车列表/智能排车/API、入仓单详情的工作流衔接最小修改权，精确文件见开发协作契约。对齐真实工作与批次接口，不改后端。 |
+
+当前开发总控 `01a13df2-c639-7560-a3e2-30bc23a579b3` 唯一维护开发检查点、调度两个专项，并负责本轮模块 `lastleg.sql`、统一增量 SQL、重置脚本、权限初始化、根路由/导航、Gateway 和架构门禁的最小集成及共享构建窗口。原型/文档支持对话 `01a13a8d-e968-7962-906b-1a514792d921` 停止代码、共享 SQL、构建和开发调度，仅维护原型及业务正式文档；检查点写权已交回，本次仅更新登记及开发契约。两个专项保留原范围，并按上表增补本批精确集成触点；发生原核心文件重叠时，以本批后端专项写权为准，总控不得同时写同一文件。接口生产者负责对应 OpenAPI/DTO，变更先同步消费者；具体文件和接口以[预约工作日历开发协作契约](海外仓业务/预约工作日历开发协作契约.md)为准。各任务在自己对话报告，由当前开发总控读取，不因收到消息自动跨对话回信或递归创建任务。
+
+用户已授权本轮代码开发和必要离线验证；未授权部署、执行 SQL、环境写入、启动本地后端或真实 HTTP。保持当前工作区和分支，不创建分支、worktree 或项目副本，不提交。两个新任务已完成只读准备，按上述边界解锁实施；每个文件一个写者，Maven/共享构建串行协调，不能把原型通过当作真实业务验收。
+
+2026-10-16 用户再次明确角色：`01a13df2-c639-7560-a3e2-30bc23a579b3` 是开发设计与总控对话，负责安排开发、接口对齐和验证收口；原型/文档对话完成设计与文档后交接，不继续派工、进度跟踪或开发审查。此前一次跟进产生的进度与问题交回开发总控，不改变三个开发任务现有写权，也不新增环境操作授权。
+
+## 2026-10-14 列表优先采集紧急修改接管
+
+用户在 `01a137b9-87ca-7db0-a400-7c48c301ae9b` 指定接续原总控 `01a13496-1713-7ac3-9981-1ae9ed551571` 的本批工作；原总控已明确释放本批代码、文档、共享 Maven 和发布调度权。本批唯一协调与实现写者为接管对话，继续使用 TEST 项目 `c64729ff-6710-43c6-8ef2-d84e9666cc1e`、host local、cwd `C:/Users/BY-OY/Desktop/code/chongchong-global`，不创建新对话、分支、worktree 或内部子代理。
+
+范围为 Integration 列表 SKU/数量 DTO、映射、内部 OpenAPI 与直接测试，以及 Lastleg 列表消费、Discovery/Validation、RoutingManifest、单次执行预算与直接测试。最终口径为列表完整时直接采用列表数量，仅具体订单缺商品行、SKU 或数量时补取既有详情；真实零值有效，正常空订单页不补详情。原开发对话 `01a135d0-f5c7-7422-892f-037b0c9ea00e` 已交回写权。`01a12f38-d28c-75c0-bc1a-dfb27e7a4961` 继续承担只读审查和唯一环境发布执行，接管协调者核对候选、验证与既有授权后安排，不自行并行执行 Maven 或发布。库存周转、发布查询范围修复及其他冻结修改不混入本批。此项交接不新增环境授权，运行及验收事实只维护正式部署契约。
+
+## 2026-10-13 用户指定的数量对照临时验证
+
+用户明确指定已自行创建的 `01a135d0-f5c7-7422-892f-037b0c9ea00e`（开启新对话）处理列表量／预报量／实际量验证，在不影响现有采集的前提下开发。保存项目 TEST `c64729ff-6710-43c6-8ef2-d84e9666cc1e`、host local、cwd `C:/Users/BY-OY/Desktop/code/chongchong-global`；本次只登记既有对话的一次性范围，不创建长期专项或新对话。采集整体协调仍归当前总控 `01a13496-1713-7ac3-9981-1ae9ed551571`。
+
+该对话唯一维护本次 Integration 有界数量对照组件、列表／详情白名单观察触点及直接测试；先核对现有未提交内容，不改其他专项冻结的 Egress/Gate、持续采集、共享 SQL、发布和运行脚本。若触点涉及仍在写入的文件或扩大 DTO/OpenAPI 合同，先列出精确冲突和最小范围，由用户／总控协调后再写，不覆盖他人修改。当前明确授权的是本次开发及只读状态核对，不解除其他对话的暂停，不自动恢复采集、部署或发起新的历史扫描。方案维护对话继续维护文档，详细保护条件和验收见 `自营业务/领星WMS接口联调手册.md` 的“数量对照验证的采集保护与开发交接”。
+
+## 2026-10-13 持续自动采集批次（当前精确写权）
+
+用户指定复用四个既有独立对话，唯一总控为 `01a13496-1713-7ac3-9981-1ae9ed551571`，仅负责调度、协调、验收收口与发布安排；禁止新增内部子代理。保存项目为 TEST `c64729ff-6710-43c6-8ef2-d84e9666cc1e`，cwd 为 `C:/Users/BY-OY/Desktop/code/chongchong-global`，保持当前分支。以下范围覆盖旧内部代理和历史临时写权，所有内部代理已停止；已有修改由对应独立专项接管，不创建新对话、分支或 worktree。
+
+| 执行对话 | 本批唯一写入范围与交付 |
+| --- | --- |
+| 采集专项 `01a12f3f-c971-7b62-a0bb-dbdddb091990` | Lastleg 自营 `sync/`、Planner/TaskService/Execution/Discovery、CollectionPolicy/AnalyticsProperties、BusinessBudget、CoordinationMapper 及直接测试；持久完整日任务池、每日计划、断点续跑与去重 |
+| 接口专项 `01a12f3f-c57a-79e1-9efa-9401f594544c` | Lastleg Egress、Integration EgressProperties/Gate 及直接测试；配对持续 BUSINESS 开关、短 permit 与真实出口保护 |
+| 指标专项 `01a12f3f-ce73-75d2-8fe3-23d709c755d5` | Collection 查询/OpenAPI、StageEstimate/ProgressProjection、Admin 采集展示及直接测试；前端测试由该专项独占执行 |
+| 原总控 `01a12f38-d28c-75c0-bc1a-dfb27e7a4961` | 本批登记、一期方案自动化契约、两服务 application.yml 开关默认 false、target 下新 continuous 发布/配置/验收脚本与脱敏清单；三个专项差异只读审查，代码冻结且编译就绪经总控确认后串行执行共享 Maven |
+
+### 已正式派工的下一批：库存周转
+
+库存周转已派给指标专项 `01a12f3f-ce73-75d2-8fe3-23d709c755d5`，按 `docs/自营业务/库存周转视图设计.md` 在本批持续自动采集收口后实施，不再仅记录为收到方案。该专项唯一维护只读 `inventory-turnover` 接口及 Admin 库存分析默认 TURNOVER/SKU、OWNER 汇总、7/15/30 同屏和原 DETAIL 严格入口及直接测试。采集专项 c971 只读核对每日库存代表和 continuous 库存计划资格，不改写或补造历史样本；原总控维护独立验收清单并安排串行后端回归。库存周转未完成不阻断本批持续采集启用；两批文件输入和验证证据分别冻结，后续改动不覆盖已审持续采集输入。
+
+当前精确阶段门禁：总控已确认本批 Admin 固定候选 `4c4a3db1ebc277b2462a2e93c3e597ea86df36ae`，ce73 获准接续库存周转仅前端实现；周转后端新源码/OpenAPI 暂不写入，待持续版后端集成收口后再解锁。本批 Admin 验证/发布必须绑定该固定提交，不能取已接续下一批的 workspace HEAD。c971 本批覆盖修复将通过 run.scope_snapshot_json 冻结完整区间集合并同步直接查询消费者；其扩大文件范围以总控下一次精确写权与冻结清单为准，原总控重审后再串行回归。
+
+目标为北京时间最近两个月全部完整日（首次 2026-08-13 至 2026-10-12）进入服务端持久任务池，每日 00:05 补前一完整日并优先，历史近到远；跨夜运行不依赖本机队列。运行事实、已验证与未关闭项只维护正式部署契约。现有 cutover/queue/helper 只读，不修改运行脚本、不擅自停止进程；新 continuous 发布须先核对旧 cutover 状态和自然日完成边界。环境操作、SQL、Nacos、部署及提交等总控具体指令；真实只读核验先报范围。本批交付在各自对话回复，由总控读取，不自动跨对话回信。
+
+2026-10-13 用户明确要求接管“平台销售总控”：当前唯一总控改为 `01a13496-1713-7ac3-9981-1ae9ed551571`，接替 `01a12feb-0474-77f1-afe0-a3b491733dca`。继续使用本 TEST 工作区、既有专项与原文件边界；本轮集成及发布由当前总控串行执行，既有专项已停止写入。独立完整日修复包暂不实施，待后续精确派工；不创建新长期对话。运行事实只记入正式部署契约。
+
+2026-10-13 17:22 总控追加12日独立完整日修复包：采集专项c971独占 AnalyticsReadMapper/AnalyticsReadRows、AnalyticsQueryService/AnalyticsSqlRequest/AnalyticsReadSql、SalesBucketPolicy、DashboardSalesPolicy/DashboardQueryService及直接测试与最小共用覆盖值对象；此精确范围临时覆盖原指标查询长期归属。指标专项ce73仍独占本轮采集前端，不写上述后端文件。内部inventory_daily仅审查版本覆盖证明不可变性，owner_query仅维护target下既有发布helper与离线测试；环境、共享文档、Maven、集成提交和发布仍由总控执行。采集保持OFF，不续11日。
+
+2026-10-13 16:43 用户在指标专项窗口补充“单领星账号运行看板”最新页面要求。发现该窗口与内部frontend在采集页面发生并行写入，内部frontend已停止全部写入/测试并交接；采集前端CollectionView、进度组件、相关types/tests和操作矩阵唯一写权转交指标专项ce73，取代下段内部frontend独占安排。总控停止基于混合输入发布，待唯一写者统一新需求、冻结后再测试构建。
+
+2026-10-13 用户再次明确要求复用以下四个窗口推进采集页改版。本批精确写权覆盖旧临时包：指标专项唯一维护 CollectionResponses/CollectionReadRows/CollectionReadMapper/CollectionQueryService、自营 OpenAPI 与直接查询测试；采集专项接管内部代理已停止的 SelfopStageEstimate/SelfopProgressProjection/SelfopDiscoveryService、直接测试及 SelfopEgressMapper 终态摘要触点；接口专项只读核查官方仓库筛选和重复请求/额外等待；原总控只读准备发布及续采清单。内部 frontend 唯一维护采集页及其组件/API类型/测试/操作矩阵；内部 owner_query、inventory_daily 已停止写入并完成交接。共享合同由新总控协调，Maven、提交和发布仍由新总控串行收口，当前运行根不因页面开发被重启中断。
+
+## 2026-10-12 平台销量统计长期开发分工
+
+本轮用户授权复用四个既有对话并行收口 Lastleg 全服务依赖门禁，临时覆盖下文旧修复包：指标专项独占预约来源与入仓包循环涉及的 `appointmentplanning/`、`inboundplan/` 和根 `service/` 直接相关类（排除 `ReturnOrderReferenceResolver`）；采集专项独占 `fleet/` 包循环及车队反向依赖修复、必要的 `delivery/` 适配器；接口专项负责 `export/` 导出组合依赖审查与直接测试；原总控负责 `ReturnRelabelPackingService`、`WarehouseTransferReceiptCoordinator`、`ReturnOrderReferenceResolver` 三处边界及必要本域适配器，并只读核对发布清单。每包包含直接调用测试，跨写权先交新总控协调。新总控唯一维护依赖分析器、架构 JSON 基线、共享文档并串行执行 Maven。不得以通配许可或循环豁免消除失败；不新增长期任务，不授权环境操作。
+
+2026-10-12 用户明确授权总控接管：本节唯一当前总控改为 `01a12feb-0474-77f1-afe0-a3b491733dca`（当前接管对话），原“平台销售总控” `01a12f38-d28c-75c0-bc1a-dfb27e7a4961` 仅保留历史交接记录。以下三个长期专项和方案维护者继续复用，已有文件归属与环境操作限制不变；共享文件集成和 Maven 窗口由新总控协调，不新增用户可见任务。
+
+用户随后明确授权上述三个专项及原总控作为当前总控的下级任务继续派工。本次原总控负责发布清单与配置的只读复核，不再承担调度；指标专项复核查询上下文和隔离，采集专项复核调度/恢复前置，接口专项复核预算与出口安全。当前新增经营查询、日库存代表和前端实现分别由新总控的独占内部工作包维护，四个既有对话在收到精确写入权移交前只读，不沿旧派工并行改写。所有 Maven 和共享文件仍由新总控统一收口。
+
+上述复核后的定向修复写权：接口专项独占 `client/RestLingxingAnalyticsClient.java`、`request/SelfopEgressService.java` 及直接测试；采集专项独占 `sync/SelfopValidationRunner.java`、`SelfopExecutionService.java`、`SelfopTaskService.java`、`SelfopSchedulePlanner.java` 及直接测试。经营查询由内部工作包统一实现，指标专项只读复核，不重复写入；日代表 `inventory/`、`model/SelfopSyncRun.java`、`mapper/SelfopSyncRunMapper.java` 由内部工作包维护。新总控保留 `query/Collection*`、`retention/`、共享 SQL、配置集成和最终门禁。
+
+用户此前明确确认新增以下三个开发对话；创建时所属总控为“平台销售-开发” / `01a12f38-d28c-75c0-bc1a-dfb27e7a4961`，当前归属以上述接管记录为准。保存项目为测试环境 `c64729ff-6710-43c6-8ef2-d84e9666cc1e`，host `local`，cwd `C:/Users/BY-OY/Desktop/code/chongchong-global`；不得跨到开发环境项目。创建阶段仅准备并等待明确开发派工，不因创建自动开始编码、构建、API 调用或环境操作；后续开发授权见下段。
+
+已有文档规划对话“平台销量统计” / `01a12ec3-b0a3-7e81-ab61-fbf9d9a183da` 保留方案及联调依据维护职责。业务输入以 `自营业务/README.md`、`自营业务/领星一件代发数据统计一期方案.md`、`自营业务/领星WMS接口联调手册.md` 和适用项目/模块指引为准；本轮用户经方案对话明确移交开发，一期包含后端任务、事实、统计、平台查询与受控重试 API，以及 Admin 销量分析、库存分析、数据采集三个入口。业务告警与补货另行确认。
+
+用户后续明确授权按最新两份主文档继续开发、集成与离线验收，完成源码、SQL 基线文件、接口和权限合同；这覆盖创建时的等待开发要求。主设计文档继续由原规划对话维护，不并行覆盖。源及业务时区已确认 `Asia/Shanghai`，数量为每个 SKU 的件数 `PCS`，唯一账号、全部授权货主、按仓独立采集；已观测货主数量不成为硬编码上限。正式首采固定两个滚动月，生产独占账号；本轮只实现 `OFF/VALIDATION/BUSINESS`、持久会话预算和隔离，真实出口与发布默认关闭。不执行 SQL、不部署、不触发 Jenkins、不启动真实采集或发布、不读取凭据、不调用真实 HTTP、不自行 Git 提交或创建分支/worktree。总控唯一维护共享 SQL、IAM、Gateway、Admin 导航/根路由和公共门禁；前端模块可交独占内部子代理，不创建额外用户对话。真实启用和人工视觉验收另按现行主方案及工程门禁处理。
+
+| task_id | 对话 | 唯一长期职责及文件边界 |
+| --- | --- | --- |
+| `01a12f3f-c57a-79e1-9efa-9401f594544c` | 平台销量｜领星接口适配 | Integration 领星 WMS 单页/单单接口、DTO、签名和账号配额能力、内部鉴权、本服务 OpenAPI 及直接测试；补仓库目录、出库摘要/详情/按单定位、产品库存。多页采集与完成性判断归采集专项，Lastleg 调用方由采集专项维护。 |
+| `01a12f3f-c971-7b62-a0bb-dbdddb091990` | 平台销量｜采集与数据发布 | Lastleg 自营分析采集和发布写链，账号发现、分仓任务、共享持久化模型及写 Mapper、租约栅栏、暂存事实、修订、库存快照、覆盖证明、候选日事实/profile、版本发布、恢复、调度和人工任务命令及直接测试；SQL 结构需求交总控集成。 |
+| `01a12f3f-ce73-75d2-8fe3-23d709c755d5` | 平台销量｜指标与查询接口 | Lastleg 自营分析只读指标和查询，日销量、7/30 天、Top 100、可售天数、数据质量/时效、固定版本分页，查询 Controller/DTO/只读 Mapper、OpenAPI、权限校验及直接测试；只消费已发布版本，不修改共享持久化模型或写入/发布链。 |
+
+开发前由总控明确包/文件归属和共享 DTO、版本及只读接口合同；两个 Lastleg 专项不得交叉修改共享模型和 Mapper。共享 SQL 基线、权限种子、Gateway、导航/根路由、主契约和集成提交由总控统一协调。文档规划对话的现有来源核验不因本次创建改变授权，开发专项不能自动复用其真实 API 授权。
+
+本轮用户进一步明确要求拆分现有重包并发收口，复用上述三个对话，不新增用户可见任务。临时文件写入权覆盖下表原本轮边界：接口适配对话接管 Lastleg `selfoperated/analytics/request/` 及直接测试，完成出口许可、验证预算和冷却回调；指标查询对话接管 `outbound/OutboundCandidateBuilder.java`、`OutboundCandidateTransaction.java`、`OutboundAggregateMapper.java`、`retention/` 及对应直接测试，完成有界候选构建、覆盖聚合和版本引用保护；采集对话保留 `client/`、`sync/`、中立 `model/`、原持久模型/写 Mapper、`inventory/`，以及 `outbound/OutboundFactService.java`、`OutboundPolicy.java`、`OutboundLockMapper.java` 和直接测试。移交区域原写入者停止修改后才释放新写入者；跨包签名和模型变化交总控协调，Maven 由总控串行执行。该临时收口分工不放开环境操作或 Git 提交，不扩展长期职责和创建授权。
+
+所有专项保持当前分支当前工作区，不创建分支/worktree、不覆盖他人改动、不使用共享 Git 索引自行提交；Maven/全量构建窗口由总控协调。此次创建不授权 SQL、数据库写入、部署、发布或真实 HTTP 验收；正式启用仍按一期方案逐仓核验。专项按精确派工交付，结果由总控只读收取，不自动跨对话回信或创建额外对话/持续目标。
+
+## 2026-10-10 采购、拼车与预约的统一页面验收
+
+2026-10-11用户新增并指定浏览器验收对话 `01a12ae6-c6d8-7331-8f26-4d4009f873bc` 加速本轮验收；已核对 cwd 为本测试工作区，归采购总控 `01a12033-95f3-7073-a74a-ef681e7ac470` 协调。新对话第一包仅采购 Client 页面与请求量，使用自己创建的 Client 标签，1920×1080；采购总控继续 Admin 预约/拼车。此次明确分工覆盖下面原“总控独占全部内置浏览器”的范围，仅放开新对话 Client 标签，不放开其 Admin 登录、共享标签、Cookie/storage 清理或全局视口变化。浏览器独立性须实际核对，未证明前按共享会话管理；PDA 390×848 待单独移交视口窗口。新对话只维护 `baiyue-firstleg/reports/client-parallel-acceptance-20261011/` 证据，不改共享进度、主契约、生产代码或触发发布。原拼车/预约开发对话仍不操作浏览器。
+
+该新验收对话第二包获总控移交 PDA 390×848 视口操作窗口，限本轮关联的国内任务详情及海外转运收货/测量作业页；总控窗口期间不操作浏览器，完成后恢复1920×1080。复用根已确认连接TEST的两条本地H5服务，不接管原HBuilder服务、不新增发布；进入页面若必须推进任务，先交最小合成样本准备要求，不领取无关任务。证据仍写其专用目录下 `pda/`，业务代码和共享主契约保持总控协调。
+
+用户明确授权复用以下三个既有对话，由“采购订单-开发”统一安排页面验收，并向另外两个对话发送协调指令。本节仅约束这三个业务的本轮协作，不创建新对话，不扩大环境授权，不改变其他专项的代码归属。
+
+| task_id | 对话 | 本轮职责 |
+| --- | --- | --- |
+| `01a12033-95f3-7073-a74a-ef681e7ac470` | 采购订单-开发 | 统一页面验收协调；独占内置浏览器，负责三项业务的页面操作、身份切换、请求及截图取证，复核交付并协调发布窗口。 |
+| `01a11999-5e90-75c3-9004-9bda35b92ced` | 拼车需求-开发 | 保留拼车业务实现、定向测试和独立会话HTTP验收；交付剩余页面检查清单、样本和证据，修复统一页面验收发现的本业务问题。 |
+| `01a11b99-6f9e-7a72-9d91-bdbd5cea051f` | 预约列表-开发 | 保留预约业务实现、日历来源接入、定向测试和独立会话HTTP验收；交付页面检查清单、样本及就绪条件，修复本业务问题。 |
+
+- 页面操作权移交时须确认无在途浏览器调用。拼车及预约对话不再开关标签页、登录、退出、切换账号或清理浏览器数据；交接时也不额外退出共享登录。
+- 其他两项可继续不干扰验收样本和账号权限的开发、测试及独立会话HTTP操作。共享文件、构建产物及同一应用/服务的部署仍须协调；部署需求先交统一验收方确认窗口，避免中途改变验收版本。
+- 凭据只引用私有环境变量键名，不在交接消息或证据中复制密码、Token。验收方默认使用新增管理员账号2的专用变量；其他对话不修改其权限或采购验收样本。
+- 交接清单在原对话回复，由统一验收方只读收取；不因收到跨对话消息自行向其他对话回发消息。仅复用已有成果并补齐缺口，运行版本、已验证场景和未关闭项维护在两份正式主契约中。
+
+## 2026-10-04 用户确认的三个独立执行对话（当前派工）
+
+用户明确选择“按这 3 个独立对话创建”。所属唯一总控仍为 `退税报关` / `01a0d0da-130f-7d43-97b5-9c76abc1b5f1`；本次三个对话不各自建立持续目标。已核对保存项目 `c64729ff-6710-43c6-8ef2-d84e9666cc1e`、host `local` 与 cwd `C:/Users/BY-OY/Desktop/code/chongchong-global` 一致。旧对话保持原状态，不恢复或唤醒。下表为本轮分阶段执行分工，不新增永久专项。
+
+| task_id | 对话 | 职责与文件边界 |
+| --- | --- | --- |
+| `01a10686-c55c-75a3-9639-655b50cbce6c` | 全流程收口｜头程装柜与报关 | Firstleg 装柜/报关实装口径、部分装柜结算、完成预检及直接测试。总控现有内部写入者释放之前，对完成预检/标签文件只读；之后由本对话接管。SQL 基线、受控 SQL、公共文档和发布归总控，不改 Lastleg/Order 或前端。 |
+| `01a10686-cae9-7943-b976-27e78ad92723` | 全流程收口｜FBA 接口与节点验收 | F01–F40 剩余接口/节点证据审计，优先 F23.2/F25/F27/F33；维护本轮专用 `scripts/fba-remaining-nodes-acceptance*` 和对应测试、`reports/fba-remaining-nodes-20261004/`。经总控复核后追加唯一维护 Lastleg 已有库存转运的本票关联换标：`transfer/service/WarehouseTransferService`、确需的直接 transfer Mapper/DTO/Controller/测试/OpenAPI，以及 `relabel/service/RelabelApplicationService` 和直接测试/调用链。正常库存选择、作业复核及客户确认需能继续至合法转运，实际出库守住换标前置；共享 SQL/权限/主契约和发布仍归总控，其他业务缺陷先交精确复现，不执行废弃批准或扣库存时点选择。 总控另授海外 PDA 主动退出修复：独占 `apps/pda-overseas-uniapp/src/api/auth.js`、`src/pages/profile/profile.vue`、必要会话辅助及对应测试，不改业务换标组件；业务前端仍由页面任务维护。 |
+| `01a10686-cfdd-7f50-8500-7704e6fbc768` | 全流程收口｜车辆与 PDA 页面验收 | 剩余车辆/司机/PDA 功能页面证据与直接前端修复，报告 `reports/fleet-pda-remaining-20261004/`；另经总控下发精确柜次承担海外 PDA 前置 F27 的正式页面失败恢复，报告 `reports/f27-conversion-recovery-ui-20261004-r1/`，仅指定预计到仓与转换命令，不改共享生产文件。可维护 Admin 车辆/司机与海外 PDA 直接涉及文件及测试；总控追加授权 F33 已有库存转运的本票关联换标前端接入，仅直接转运/尾程 API、组件/测试及确需的海外 PDA 换标显示，后端唯一归 FBA 任务。共享路由/导航/权限、auth/http、其他海外仓主页面及后端仍归总控协调。不得重做已关闭下载和成本场景。 |
+
+总控于2026-10-05追加 F23.2 文件边界：头程装柜与报关对话负责客户实际进港展示缺口，只沿现有客户订单详情的实际 API 链维护 Firstleg 运输事实读取、必要 Order 客户详情投影及 Client 订单详情和直接测试；不改 Admin、PDA、Lastleg、共享认证、权限/SQL或导航。新接口或 DTO 变更须列出生产者/消费者与合同门禁，发布仍由总控串行处理。此项只实现正式交互矩阵要求的本客户已实装货物运输事实展示，不创建第二套客户状态。
+
+三个对话先接受精确交接再工作；禁止覆盖他人改动或使用共享 Git 索引提交。数据库写入、SQL、Jenkins、部署、共享契约、集成提交由总控串行处理；真实 HTTP 每任务单请求流、独立会话，仅在交接明确样本范围操作，退出自己的会话。不得重置、删除数据或伪造业务事件。Maven/全量构建不得并发；总控发放窗口，其他任务可做不争用产物的轻量定向检查。环境文件沿既有授权读取，凭据不输出。
+
+总控追加 F33 收货资源接入文件边界：FBA接口与节点对话可维护 `lastleg-service` 的 `transfer/` 直接收货服务、确需的局部DTO/Entity/Mapper及测试，并唯一接管 `inboundplan/pda/gateway/HttpWarehouseResourceGateway.java` 和对应测试，核对权威收货仓/托盘/库位、现有资源占用、原请求恢复及多来源收货。优先复用既有内部资源合同，不擅改PDA共享作业服务或Warehouse Overseas生产实现。SQL基线、统一SQL、实际数据库与发布仍由总控处理；必要结构先交精确字段/约束。本轮故障代理及F27资源恢复由总控维护，避免重叠。
+
+沟通只保留初始派工、必要的文件释放/环境就绪、最终交付或明确阻塞；禁止“收到/等待/进度”跨对话互回。每个阶段交付一次后停止自主扩展，最终结果由总控只读收取；不自动发送消息、创建额外对话或子代理。部署与验收进度仅更新两份正式主契约，不在登记表复制。
+
+用户于2026-10-05明确调整协作方式：大工作包由现有独立对话承担，具体项目出现阻塞时由总控接手未完成项，并继续推进不依赖该阻塞的工作。接手前明确原任务释放的文件、样本与浏览器操作权；复用其已验证成果，仅处理缺口，不重复整条流程。总控不以等待专项回复为停止其他可执行工作的理由；确属工具或外部条件限制时保留未验证边界，不虚报完成。
+
+总控追加F27原操作恢复边界：头程装柜与报关对话唯一维护Lastleg `inboundplan/service` 的转换预览/恢复状态、直接Mapper/DTO/测试，以及 `mapper/LastlegOrderMapper.java` 的柜级待资源计数和直接测试；仅沿确切消费者核对入仓/PDA资源确认门禁，不接管转运/换标。车辆与PDA页面对话唯一维护Admin `LastMileOrdersView.vue` 及直接测试的原资源恢复入口和门禁。FBA接口对话继续独占原F33转运执行；三个样本范围互不混用。总控负责共同合同、编译、发布和现场故障运行窗口；工具或只读审计脚本的临时文件以精确派工为准，不由专项自行执行共享环境变更。
+
+## 2026-10-04 全流程唯一持续目标与车辆交接（当前）
+
+总控追加F33页面入口最小实现边界：FBA接口与节点对话独占 Admin `api/warehouseTransfers.ts`、`components/WarehouseTransferFulfillmentPanel.vue` 及直接局部组件/测试，承载既有库存转运正式出库与逐来源目标仓实收。车辆与PDA页面对话释放上述转运文件，仅继续F27恢复页面；`LastMileOrdersView.vue`不交叉写入。共享路由、权限、SQL、集成和部署仍由总控处理；实现任务先本地定向检查，不自行重跑已通过HTTP链或改变共享环境。
+
+本包后端持久实收查询由头程装柜与报关对话唯一接管 `WarehouseTransferResponses`、`WarehouseTransferService.detail`、`WarehouseTransferReceiptCoordinator`、确需的 `WarehouseTransferReceiptCommandMapper` 及直接测试/OpenAPI；仅向既有详情提供本客户本票的原实收请求、状态和权威目标，保证跨浏览器续作及完成响应一致。FBA接口任务本包不写后端；不新增出库命令表、不改SQL或转运写入规则。编译、运行验证和发布仍归总控。
+
+总控核对F33主/子状态后，本批后端边界进一步包含 `WarehouseTransferService.outbound/receiveReserved` 和 `RelabelApplicationService` 的既有库存转运完成回调及直接测试：保持本票已经成立的INBOUND_COMPLETED，仅推进转运子单与子状态。原来源订单、来货转运另一履约链及真实派送主链不得误改，不回填旧记录、不执行SQL；任务2仍只维护本批Admin入口。
+
+总控追加F33预留所有者保护包：头程装柜与报关对话唯一维护必要的转运预留查询/守卫、`InventoryCommandService` 直接调用及测试、`DispatchCandidateMapper` 的候选/锁定归属校验、`PdaPalletOperationService` 拆合托入口及直接测试。禁止凭可由外部伪造的业务号/幂等前缀绕过预留，只允许服务端核对后的本转运消费者使用；保持独立逻辑预留模型，不改HOLD模型或泛化封禁保留身份的整托移库。该任务获得空闲本地Maven窗口，仅串行受限最小红/绿回归；总控此时不另起Maven或全量前端构建。真实环境样本及页面由总控和页面任务独占，专项不HTTP/SQL/部署。
+
+总控追加废弃确认重放最小边界：FBA接口与节点对话唯一维护Lastleg `PdaCargoDiscardService.confirm`及直接测试，只修复已完成单/托的相同完整载荷恢复及异载荷/越权拒绝，不改变首次扣减时点、审批状态设计、SQL/API/权限。业务时点等待用户明确选择，专项不批准或实际废弃测试货物；独占本地串行受限Maven窗口。头程装柜与报关对话同期只在`reports/wallet-mid-transaction-20261005-r1/`准备单一合成资金指令中途故障工具，不修改生产或运行构建，不执行HTTP/SQL/部署。最终集成、共享主契约和环境操作仍归总控。
+
+总控另授车辆与PDA页面对话仅在`reports/auth-validate-timeout-20261005-r1/`准备指定合成PDA账号/会话的Gateway→Auth权威会话校验超时工具及离线测试。只沿直接认证协议和已有依赖故障工具复用，不能写生产代码/共享脚本，不能关闭校验或影响其他账号。该任务不执行HTTP/SQL、运行配置切换或部署，不占Maven窗口；无法精确匹配或恢复时交源码依据，不扩大故障范围。实际故障窗口与恢复仍由总控独占执行。
+
+用户在车辆对话明确要求：“当前的目标先停掉，只有总控一个目标”。已核对该对话的用户原文；当前唯一持续目标属于 `退税报关` / `01a0d0da-130f-7d43-97b5-9c76abc1b5f1`，保留F01–F40全范围，并统一收口下述车辆首版完整闭环。车辆对话 `01a0f19d-3f0b-7ae0-a860-c0d1d2e84475` 和三个既有专项停止自主全目标循环，仅保留原task_id、代码归属与交接证据；不得自行继续环境写入、发布或故障注入。没有创建新任务、恢复归档任务或标记车辆已完成。
+
+唯一总控负责共享环境发布、串行Maven、数据库/故障窗口与最终验收。专项若获明确后续派工，只执行所分配阶段和文件边界；不各自建立持续总目标。当前对话仍遵循不自动回信的约束，交接与必要现场核对采用只读方式，不能凭另一任务来信自动授权消息回复。目标工具不支持修改一个活动目标的objective正文，不能把未完成原目标标complete来替换；车辆范围按本次确认纳入同一执行范围，原FBA目标保持active。
+
+原车辆总控冻结的异常实收/重派关联10文件交给唯一总控集成，保留原冻结SHA和编译失败。总控只修复已交接的测试编译歧义、验证该冻结批次并按后端先于Admin安排发布；不将其他共享未提交修改一并暂存。两份正式主契约仍是部署、已验场景和未关闭项的唯一事实入口，本登记不复制进度。
+
+### 原2026-10-03车辆四任务职责（保留文件边界，停止自主目标）
+
+用户本轮明确确认：“确认创建三个任务，我们当前目标调整一下，加上自己，一共4个任务，一起处理，尽量把车辆的跑通”。本次车辆协作覆盖下方旧车辆专项归档状态，其他旧任务仍保持归档，不自动恢复。
+
+- 原车辆总控：`01a0f19d-3f0b-7ae0-a860-c0d1d2e84475`，host `local`；当前转为交接入口，原车辆/司机、共享入口/权限/SQL、构建发布及最终验收职责由上述唯一总控接管。以下专项文件边界保留，未经新派工不自主继续。
+- 项目固定为测试环境 `c64729ff-6710-43c6-8ef2-d84e9666cc1e`，工作目录 `C:/Users/BY-OY/Desktop/code/chongchong-global`。所有任务在当前分支当前工作区操作，不创建分支/worktree，不混入开发环境。
+- 车辆原目标保持完整：以原型梳理与当前正式合同为准，完成车辆/司机、车次、自有及外接、成本财务、报价统计、异常、页面和PDA闭环；不能以单模块绿灯认定全部完成。
+
+| task_id | 独立任务 | 稳定职责及写入边界 |
+| --- | --- | --- |
+| `01a0ffcf-7150-7db3-9d8c-108e568c12b1` | 车辆管理｜成本与财务闭环 | 独占FleetTripCost系列后端、直接测试/OpenAPI、Admin tripCosts API和TripCostPanel及其测试；负责后续维修救援成本与Finance衔接。共有表结构、权限和车次页签由总控集成，Finance共享入口变更先列明路径。 |
+| `01a0ffcf-eea3-7111-b30b-4be63547ac33` | 车辆管理｜报价与运营统计 | 独占新增Lastleg fleet/quote、fleet/reporting及各自测试/OpenAPI、Admin独立报价/运营页面和API；不修改成本写入和车次执行。共享导航、路由、权限、表结构与导出注册交总控集成。 |
+| `01a0ffd0-2a4d-7210-bad8-a790cd965e8a` | 车辆管理｜在途异常与改派 | 独占新增fleet/exception及在途相关组件、API；按正式派工接管FleetTripService/Execution/Completion、资源及实际dispatch/PDA调用链。共享FleetTrip模型、接口和PDA入口先交总控协调；不改成本、报价统计及其草稿。 |
+
+本轮已释放给在途专项的共享接入：`lastleg-service/src/main/java/com/baiyue/lastleg/fleet/trip/FleetDispatchGateway.java`、`lastleg-service/src/main/java/com/baiyue/lastleg/dispatch/fleet/DispatchFleetAdapter.java`及对应专属测试。限定在途交接的目的地/实物托盘/派送终态只读依据，不改库存数量或重写原DEPART。已有`FleetTripPersistenceTest.java`、`FleetTripApiContractTest.java`、`FleetTripAuthorizationTest.java`归在途专项直接消费者维护；新`FleetTripCost*Test`仍由成本专项独占。
+
+总控统一管理 `TripDetailView.vue`、模块路由/导航/权限、共享FleetTrip模型接入、IAM权限种子、模块与统一SQL、主契约和公共验收入口。独立任务不得部署或执行SQL，不同时启动Maven/全量前端构建；定向检查可自行执行，Git提交由总控统一选择，避免共享索引冲突。真实环境沿用户授权使用 `C:/Users/BY-OY/.codex/env/chongchong-global`，凭据不输出。共享未提交改动不得覆盖、暂存整库或回退。
+
+2026-10-03 用户再次明确要求提高四任务并行效率，解除“所有验收均等总控亲自操作”的瓶颈。总控发出匹配版本就绪通知后，三个专项分别承担自身TEST真实HTTP、页面验收与修复；每任务仅一个串行请求流，独立登录会话及新建样本，不争用对方记录，不并发操作同一车次/库存或凭证。成本范围标记`FLEET-COST-20261003`、报告`reports/fleet-cost-live-20261003`；报价范围标记`FLEET-QUOTE-20261003`、报告`reports/fleet-quote-live-20261003`，不操作库存；在途范围`fleet-handover-20261003`、报告`reports/fleet-handover-live-20261003`，独占本轮客户、货物、车次和PDA作业员。各自保留失败与原请求，结束退出自身会话并恢复自己的测试资源，禁止删除或重置数据。运营统计只读消费在途任务已验证且冻结的当前轮DEPART事实；由总控转发，不复用历史样本冒充新链路。用户授权的测试环境范围不扩大到开发或生产。
+
+在途专项追加独占`scripts/fleet-test-env-acceptance.mjs`及直接测试，负责将新交接验收挂在实际DEPART后、签收前；新`fleet-handover-acceptance`模块归在途专项，`fleet-company-cost-acceptance`归成本专项，`fleet-quotes-operations`归报价专项。总控保留公共Admin入口注册、权限、SQL及发布。
+
+为消除发布串行瓶颈，在途专项另获海外PDA H5独立发布单元：仅测试`pda-overseas-h5-test`容器及既有Compose项目/网络，使用已固定源码与编译资产，核对健康和首页摘要；不得操作国内PDA、原生APK、后端或网关。三后端与Admin发布、共享SQL仍由总控收口。
+
+混合履约后续接线继续复用三任务：成本专项唯一维护新增`SourceDeliveryCompletionPolicy/Query`、`DeliverySourceEvidenceMapper`及直接测试，并接管`DeliveryDocumentService`、`DeliveryCompletedOutboxService`和直接测试，按真实来源签收证明接既有完整签收事件；在途专项唯一维护退回入库来源及dispatch候选/预排/PDA拣货重派链和Admin海外仓对应直接调用文件；报价专项负责独立运营验收和只读交叉复核，不修改被复核者文件。共有SQL、权限/导航、发布仍由总控处理。新结构本地准备不等于已执行TEST，国内异常结案业务选择不由专项自行决定。
+
+车辆总控进一步释放报价接线：报价专项唯一维护`FleetBookingService/Models/Entity/Reservations`及其直接测试/外接预订OpenAPI、Admin `bookingTypes.ts`、`api/tripBookings.ts`、`TripBookingPanel.vue`及直接测试，接入可选销售报价来源版本；保留`3440f9d`详情关闭后编辑修复。总控保留`FleetBookingQuoteContext`、`FleetWarehouseClient`及直接测试、全部SQL/权限及共有装配。异常专项继续独占车辆验收主入口，接入成本专项的`fleet-trip-cost-acceptance`助手和两类独立权限会话；异常退回缺陷仅沿实际调用链扩展局部实现，新增结构/权限由总控集成，不改其他任务的普通签收/F40流程。
+
+本轮车辆总控追加释放：成本专项唯一维护Lastleg `fleet/maintenance/`及直接测试/`fleet-vehicle-records-v1.yaml`、Admin `VehicleCareTable.vue`、`VehicleCareEditor.vue`、`api/vehicleCare.ts`及直接测试，负责维修/救援公司成本命令和状态接入。保留#493空字段初始化与无变化不写入修复；公共事件配置、File类型、编号、SQL/权限仍由车辆总控集成。此为上方当前四任务的文件分工，不恢复下方历史任务。
+
+## 2026-10-03 归档与重新规划
+
+用户要求归档此前分配的对话并改为分阶段处理。下表四个独立任务及此前车辆专项 `01a0f19d-3f0b-7ae0-a860-c0d1d2e84475` 均已确认归档；下文职责与授权仅保留为交接历史，不再据此唤醒、派工或自动恢复。当前对话保留为汇总与规划入口，新对话数量及职责待用户确认后建立。
+
+归档不删除工作区代码或报告。用户随后明确要求当前对话继续处理不依赖车辆的逻辑；本对话直接接续非车辆工作，不唤醒以上旧任务。F23原柜改船已接续提交、部署并完成既有船期编辑的双端验证，具体版本、证据与未覆盖项唯一见[测试环境单机部署与配置契约](测试环境单机部署与配置契约.md)。车辆后续独立授权与职责以上方当前登记为准；归档本身不代表功能完成。
+
+2026-09-09 的旧登记保持作废。下列任务根据用户 2026-09-30 的明确请求重新创建：用户要求“使用多个独立任务处理（不是子智能体）”，并确认“按4个创建，你直接负责汇总”。不根据旧台账恢复或派工。
+
+## 所属总控与项目
+
+- 总控：`退税报关`，`task_id=01a0d0da-130f-7d43-97b5-9c76abc1b5f1`，host `local`。
+- 项目：测试环境，`projectId=c64729ff-6710-43c6-8ef2-d84e9666cc1e`。
+- 唯一工作目录：`C:/Users/BY-OY/Desktop/code/chongchong-global`。不操作开发或生产环境，不创建分支、worktree、项目副本或内部子代理。
+- 目标：按当前正式文档完成 F01–F40 逐节点验收。实现、服务测试、部署、真实 HTTP、页面验证分别记录，不能用局部绿灯代替全流程完成。
+
+## 稳定职责与文件归属
+
+| task_id | 独立任务 | 稳定职责及写入边界 |
+|---|---|---|
+| `01a0f14c-9262-7b43-990a-0e3beddcdd8a` | 全流程节点验收｜头程与海运 F01–F24 | 头程与海运未闭环完成条件；只改对应头程/海运验收模块及其合同。国内 Firstleg 报关/船节点实现如需修改，先向总控列明精确文件，避开完成回写任务负责的消费者。Order 实现由完成回写任务维护。 |
+| `01a0f14c-962f-73c3-b1aa-9df555b91586` | 全流程节点验收｜海外收货库存与出库 F25–F37 | 接柜、收货、库存、出库及完整库存重放取证；维护 Phase4 收货脚本/合同、只读收货取证器，以及 Lastleg 后端实现与直接测试。跨到派送的 Lastleg 修改统一由本任务落地，避免后端多人写入。 |
+| `01a0f14c-9a66-7f61-bc2b-6ad17a6c940a` | 全流程节点验收｜签收余量与完成回写 F38–F40 | 双片真实签收、合法末票余量取消、根订单完成和反向回写；维护 F40/Phase5 专项脚本及合同、Order 完成聚合、Firstleg 完成消费者。涉及 Lastleg 实现的缺陷经总控转交海外库存任务。 |
+| `01a0f14c-9e33-7a01-903d-a5febd50774b` | 全流程节点验收｜平台客户页面与下载 | Admin/Client 真实页面操作、状态、文件上传下载和隔离；维护直接涉及的前端业务代码/合同。已有排车样式任务的文件不在本任务写入范围，遇重叠由总控协调。 |
+
+## 调度与环境约束
+
+- 用户已授权本轮测试数据库、真实 HTTP、页面及测试环境部署操作；具体环境文件只从用户指定的 `C:/Users/BY-OY/.codex/env/chongchong-global` 定向读取，凭据及 Token 不写入代码、文档或报告。
+- 独立任务先由总控发送精确交接，再开展所属职责。当前文件尚有前序写入者时先只读，收到明确释放后才能写入。禁止覆盖、提交或回滚他人修改。
+- 总控负责共享部署、Jenkins、SQL 执行、Maven 构建串行调度、共享入口/权限/初始化 SQL 和主流程文档汇总。独立任务不得自行部署、执行 SQL 写入、重置或删除数据/文件；需要这些操作时交付具体内容由总控处理。
+- 独立任务可在正式派工指定范围内执行测试 HTTP；每个任务使用独立标记及新造测试客户/订单，只操作自己创建的数据。共享托盘、库位等资源变更须先协调，不能触碰其他任务的原验收样本。
+- 必要派工及汇报仅围绕这四个任务与所属总控开展；独立任务把当前事实、文件、检查结果和阻断交给总控汇总，不扩大到其他聊天或新任务。
+- 不改变统一架构专项及其他已在进行任务的范围。当前事实依据正式维护入口；历史报告仅证明对应版本和范围。