docs(dispatch): 明确排车发布余位与直接装车确认规则

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

@@ -6,9 +6,13 @@
 
 ### 当前页面范围（2026-10-21）
 
-用户确认「海外业务 → 散板需求」当前仅作为内部车次余位需求池，供内部人员查看已发布排车的线路、起运仓、目的站、时间、分段余位及调度联系方式，人工联系、下单。列表统一默认进入可拼车次，详情仅展示运输和余位信息；直接隐藏待匹配散板、我的登记、待我处理、登记客户货物、确认承运及后续来货/核量/排入本车等入口，旧登记深链也不打开登记窗口。不增加功能开关，不删除既有组件、业务处理代码、接口或数据；后续功能待另行确认再开放。当前仍复用调度显式发布的余位来源，不扩展为所有未装满排车的自动汇总。需求池隐藏“选择车次发布余位”，详情车次号仅作纯文本展示，不再跳转已退出日常使用的旧车次列表或详情；原入口代码保留。
+用户确认「海外业务 → 散板需求」当前仅作为平台内部的排车余位需求池，人工联系、下单，不向客户公开运力市场。日常派送排车增加“发布公共散板需求”，新建默认勾选，每车独立保存；维护车辆信息时可取消或恢复勾选。选项与原新建/编辑命令同事务保存，沿用原权限、公共版本和幂等键；只切换发布选项不作废已有调度/理货审核依据。
 
-以下完整拼车流程记录已保留实现及后续能力，不能据此认为当前需求池页面仍开放登记与履约。客户原有本土散板下单入口保持独立，不在内部需求池新增客户提交入口。本次仅调整 Admin 展示，不修改服务端权限、状态或接口，也不代表已部署或完成真实环境验收。
+数据源直接来自当前排车主单，不再依赖旧车次的人工余位发布记录，也不创建另一份车次、发布单或占位。仅勾选发布、ACTIVE、DELIVERY、未实际发车且处于装车前/装车中/装车后的排车进入列表；取消勾选、取消排车、实际发车/进入派送中或任一已知容量维度满载时自动退出。取货和本土卡车排车不参与。查询复用实时排车快照，按本车业务号一行展示，不返回客户货物、司机私人信息或内部ID。
+
+车辆容量与已排实托数分别展示，不将实托数等同标准托位。可靠装载确认存在时，用去重实托的标准托位、重量和体积计算起运段可再接的余量；首版均从我仓上车，沿途只卸货。任一已知维度已满即退出；缺少可靠装载/容量资料时保留需求并明确“余位待确认”，不填零、不按车型名称或默认30托推算。不存在可公开的调度联系方式时，不以司机电话替代。新列表仅读取运输和容量摘要，不开放详情跳入旧车次、登记、确认承运、来货、核量或排入本车等操作。
+
+原需求池与后续拼车实现保留，不增加开放登记的功能开关、不删除组件或业务处理代码。客户本土散板下单入口保持独立；下文完整拼车流程描述保留能力，不能据此认为当前页面已开放。新增发布字段、读接口与页面的代码完成不等于已执行SQL、已部署或已通过真实环境验收。
 
 ### 2026年10月9日操作简化开发定稿与预约交接
 

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

@@ -6,6 +6,8 @@
 
 ## 一 用户已确认的业务目标
 
+2026-10-21 新增内部散板需求发布选项：新建排车默认勾选“发布公共散板需求”，可在维护车辆信息时修改；按车与新建/编辑命令同事务持久化。对派送排车的候选、满载退出及未知容量口径统一见[内部散板需求池当前范围](内部拼车需求池首版开发契约.md#当前页面范围2026-10-21)，不改变排车审核、实际拣货、装车照片或发车流程。
+
 1. 2026-10-21 用户最新确认：排车列表恢复装车前、装车中、装车后、派送中、派送完成五个作业阶段。装车中可同步上传资料；确认装车完成且资料齐全才进入派送中。装完但资料未齐留在装车后，资料先齐则确认装车时直接派送；此规则替代同日此前“装完即发车”的确认。
 2. 一张排车单就是一趟车，允许同车多个客户、多个目的仓；各票货物、库存、单据和费用必须保留真实客户归属。
 3. 装车前包含车辆信息、调度审核、理货员审核；维护车辆信息后提交调度审核，再经理货员审核进入装车中。2026-10-21 用户确认审核链：客服在最初的车辆信息入口维护并提交，不新增独立客服审批级别；调度或理货员任一环节驳回均须填写原因，并统一回车辆信息／客服处理分区，离开待审队列。客服处理期间保留驳回环节、原因和原审核记录，编辑不抹除原因；重新提交开启新轮次，必须重新经过调度及理货审核，不复用旧批准。理货审核允许 Admin 或绑定仓 PDA 操作，两端共用版本、幂等和审核依据；通过前不得真实拣货，通过后才进入装车中。
@@ -127,7 +129,7 @@
 | 事项 | 确定规则 | 决策影响 |
 | --- | --- | --- |
 | 临时外配取证 | 建单人补齐本趟车辆容量、司机证照和预计任务结束，由调度审核核实；空单可先保存，审核前补齐 | 临时输入、证据上传、资格快照及审核必填；不自动建车辆或司机主档 |
-| 实际装载核对 | 在确认装车弹框接入既有实载核对，有依据的实际数据自动带出，缺项再确认；保持PDA真实拣货核平前置 | 实载来源/字段/弹框及双端核验；不新增第五个详情页签，不代填拣货箱数 |
+| 实际装载核对 | 确认弹框仅展示已扫托数、箱数并整车一次确认，不要求操作员逐托填写托位、重量、体积；已有实测由服务端带出，未知保留空值且不阻塞装车，保持PDA真实拣货核平前置 | 实载来源/字段/弹框及双端核验；不新增第五个详情页签，不代填拣货箱数 |
 | 零扫码变更 | 保留原排车单号，显式退回装车前，修改后两级审核重提 | 新审核轮次、权限和历史；已经扫码的退装/回库不在本批新增 |
 | 客户直接创建派送 | 本批整车安排仅由平台执行，客户继续查看自己的派送单，移除旧客户直接创建这类派送入口 | 派送后端移除对应Merchant创建写入口；前端任务按第九节更新Client直接消费者，保留本客户读取及合法资料操作 |
 | 换标合托同车 | 同一实托可承载两张换标单的逻辑运输来源并整托同车；各来源真实箱数、客户及扫码归属保留，托盘和实际容量只计一次 | 同车内物理占用共享、跨车排他；候选、整托完整性、扫码归属、实际装载及派送/来源状态的直接契约须一致，不能只放开重复托盘校验 |
@@ -172,7 +174,7 @@
 
 候选由服务端返回完整选择组及组成版本，使用未被页面筛选截断的事实闭包，兼顾既有整申请规则；前端不按当前可见相同托盘码自行拼组。正式Create/AddCargo保留显式逐来源选择并在服务端复核全组；草稿单来源动作须服务端一次命令原子处理完整组，不能用前端循环多个写请求代替整组一致性。PDA保留逐明细精确扫码，展示明确换标业务号及该来源可拣位置/额度，全部逻辑来源核平后才允许装车；不新增整托一键多次扫码或自动补拣数量。
 
-LoadingPreview及实际容量按每实托一行，逻辑箱数、来源状态与费用分别按真实归属保留。整托实测重量/体积不复制到每逻辑来源；业务份额只使用实际来源证据，缺少证据保持未知，不按箱数推件数或平均分摊重量。主流程先产出字段级公共骨架及唯一接口设计，前端以实际Java记录对齐；来源贡献的仓库生产者/移动触点及精确DDL由主流程提出，总控核对现有写者后逐文件分配。共享SQL/OpenAPI仍由总控集成，Maven仍由主流程唯一执行；此前普通流程通过结果不覆盖本次新增模型。
+装车确认仅传当前版本、清单摘要与幂等键，服务端按已扫实托去重计算托数（每实托一托），沿已有路线确定卸货站。已有重量、体积保留原实测依据，未知不要求现场重复测量、不填零、不推算；已知货量超出容量仍拦截，未知重量体积不作为可售余量。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仍只由主流程执行。