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

# 排车列表统一作业改造契约

本契约规定排车列表作业阶段、整车与客户货物归属、派送安排及 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份，仅填充空类别，来源未变化时保留已有现场照片及替换结果，重复审核不重复复制；退回后保存车辆身份、司机身份或对应证照附件变更时，对应类别的旧资料（含手工上传）与资源修改同事务失效，保留文件和历史，其他类别保持不变；再次理货通过后按新来源带入，未带入前不计入资料齐全。后续主档换图不改本趟附件。司机人像不放入驾驶证类别，其余三类由现场上传。驾驶证支持PDF原件（计一份）并可在两端查看；其他类别只接受JPG/PNG。复制失败时本次审核与资料绑定同事务回滚；GET保持只读，不执行测试存量补写。

5. 装车已完成时，第五张装车照片绑定与按客户和目的地生成出库／派送单、记录实际发车并进入派送中在同一事务完成；照片先齐时，这些动作随装车确认在同一事务完成，仍无人工安排派送及确认发车入口。上传和绑定各保留稳定原请求键；第五张绑定或派送失败时保留装车后、前四张及原上传文件，原请求可恢复，不能留下半车或重复派送。PDA每次按Token绑定仓校验，Admin沿排车list只读、edit上传保存。照片使用原整车附加记录及文件归属，不新增存储表；五个既有技术槽位按顺序映射上述五类资料，不替代司机审核或真实签收。真实外接报价沿原费用路径发布，未知派送补充资料与费用保持未确认，不猜测金额或原费用覆盖、不填写零费；后续由既有后台资料／费用管理维护。装车中上传齐资料不会提前发车；照片先齐时派送失败回滚本次装车确认、保留已保存照片，原请求可重试。装车完成原键恢复本次事务原最终阶段（AFTER_LOADING或DELIVERING），资料保存原键恢复原保存结果，当前阶段须另读；不重复扣库存。
6. 实际发车后为派送中；全部正常签收完成后自动进入配送完成。派送中可以“标记异常”：类型必填（拒收、部分签收、车辆异常），退货去向选填（退回海外仓、其他），说明和图片选填。登记沿排车维护权限，按本车版本及原请求键防重，异常记录和图片保存在主单并于现有“排车信息”详情回看；阶段仍为派送中，不自动创建退货、恢复库存或确认签收。异常后续处置由人工处理，本轮不新增线上异常闭环。
   2026-10-21 资料入口确认：装车中、装车后从“管理资料”打开整车五类资料；有效排车在派送中、配送完成统一从“管理资料”居中弹框进入，签收文件、装车资料两个页签；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预约可先保存、后关联真实货物和排车，以及车辆可先独立预约、后关联排车的答复仅保留为日历需求输入，其后续规则和实现由用户指定对话处理；此处不继续整理日历方案、不创建新任务、不跨对话转派，也不删除已经存在的预约功能或关联。