chore: 入库 9 月积压成果（滇中好运原型评估、小象开票需求与原型、工具配置）

- 原型评估_滇中好运物流云_20260917/：物流云原型评估产物（含核对表与字段对比表）
- requirements/小象开票收款方创建需求.md + prototypes/小象开票原型.html：小象开票建司机/车辆/收款信息需求
- requirements.txt：Execute 战区依赖调整（移除 pytest/allure-pytest/requests，改用 pytest-html，Appium 默认注释）
- .claude/launch.json：新增物流公司管理原型预览服务（wuliu-proto:8138）
- .agents/skills：agent 技能定义

原型评估_滇中好运物流云_20260917/03_与运八契合度对比.md

@@ -0,0 +1,53 @@
+# 03 与运八项目契合度对比
+
+> 运八侧事实来源：`output/菜单清单.md`（运八管理后台 423 个可见菜单，ntocc.sys_resource 导出）、`tests/api/test_yun8_transport_flow.py`（24 步全链路：货源→接单→装货→卸货→核算→审核→油卡充值→司机打款→货主打款→回单→ETC 发票）。
+
+## 1. 两个系统的定位差
+
+| 维度 | 运八（网络货运平台） | 原型·物流云（统一调度协同平台） |
+|---|---|---|
+| 法律角色 | 网络货运承运人（承担承运责任、开票、资金、监管上报） | 调度协同中枢（不对托运人承担承运责任） |
+| 核心资产 | 合规链路：监管上报（司机/车辆/路单/资金）、多渠道发票（浙样红/满货达/滇运通/三十六匠/小象/ETC）、税务管理、真实资金（光大/快钱/分账/提现） | 业务链路：计划→配载→运单→履约→凭证→核算→结算的协同与管控 |
+| 运力来源 | 社会运力为主（司机/车队注册、审核、评价、投诉） | 中闽自营车队 + 准入承运商（含运八） |
+| 货源组织 | 货源大厅、发布货源、项目货源 | 呈钢 ERP 计划、货主发货计划、客户自提 |
+| 强项 | 四流合一（合同/货物/资金/票据）、监管口径 | 计划调度颗粒度（拆分/合并/配载/资质门禁）、三方协同流程、权责划分 |
+
+**结论：互补大于竞争。** 原型自己也是这么设计的——运八在原型中不是被替代的对象，而是运力池里的承运商租户和"授权代录"数据来源。
+
+## 2. 原型已为运八预留的契合点
+
+1. **承运商租户位**：运力池/资质管理按"准入承运商"设计，`carrier-yunba 云南运八物流科技有限公司` 已在演示数据中。
+2. **代录通道**：发货计划来源类型支持"运八调度→运八授权代录"（与"中闽人工代录""平台人工代录"并列），说明产品规划中运八是上游计划的一个合法来源。
+3. **核算规则复用**：核算管理声明"仅复用运八已评审核算规则，并适配呈钢、昆铁和中闽现有业务对象"——两边的运费核算口径同源，结算对账有共同语言。
+4. **接口中心已就位**：接口配置/接口任务模块（发送/回执/失败重试/补偿记录）就是为外部系统接入准备的，目前仅接了呈钢 ERP，接入运八只是配置层面的事（产品上已留好位置）。
+5. **凭证中心**：按运单节点管理回单文件+版本+审核链，与运八的回单签收/电子回单可以一一映射。
+
+## 3. 功能重叠与双轨风险（需要明确归属）
+
+| 领域 | 运八已有 | 原型也有 | 风险 | 建议归属 |
+|---|---|---|---|---|
+| 运单 | 运单管理/跟踪/轨迹/补录，是监管上报的路单来源 | driverTasks 全生命周期+waybill-center | **双轨运单**：同一票货两边各生成运单号，监管口径以运八路单为准，金额/里程不一致即监测系统异常 | 运单主数据放物流云（调度视角），**合规运单以运八为准**；物流云运单向运八推送生成路单，回传路单号绑定 |
+| 司机/车辆资质 | 司机审核/车辆审核/核验审核+**监管上报**（司机上报/车辆上报） | 单人+单车资质组合、OCR 机审、装车门禁 | 双重审核、口径不一（如从业资格证字段、4.5 吨以下豁免） | 物流云做**准入门禁**（可派判断），运八做**合规审查与上报**；资质结果双向同步，避免司机重复提交 |
+| 轨迹 | 运单轨迹、轨迹导出、（对接监测系统的驾驶员位置上传） | 高德 Mock 轨迹+装卸打卡 | 原型无真实轨迹源 | 轨迹一律取运八/北斗侧，物流云只消费展示 |
+| 回单 | 回单签收/电子回单 | 凭证中心（版本链/审核退回/补传） | 双侧上传、重复归档 | 司机 App 上传入口收敛为一处，另一方同步镜像 |
+| 结算/资金 | 运费核算→审核→油卡充值→司机打款→货主打款→分账/提现（真实资金） | 核算→结算申请→结算→付款批次（**线下登记，不执行真实资金**） | 原型已声明不动资金，天然无冲突，但要防业务员误以为走了系统=付了钱 | 金额口径在物流云核对，**支付指令全部走运八**；物流云付款批次仅做台账并与运八流水勾稽 |
+| 发票 | 多渠道代开（专票/普票/ETC/红冲）+税务管理 | 进/销项线下登记（Mock，不连税务） | 原型发票模块定位是"线下结果登记"，与运八开票是上下游而非竞争 | 运八开票，物流云登记勾稽（原型已有"发票分配到付款批次"的勾稽设计，方向正确） |
+| 油卡/能源 | 加油管理、能源卡、万金油、油费预付 | 中闽油卡管理（自营资产）、在途费用（电费/ETC 等 6 类报销） | 两种语义（资产卡 vs 平台代购燃料）。注意新办法第十二条：平台自购燃料交付需承运人同意；第十八条要求燃料全流程留痕 | 平台代购燃料（若有）必须在运八侧做全流程留痕；物流云油卡仅限中闽自有 |
+| 异常 | 客服运维（运输异常/投诉/评价/预警/撤单） | 异常管理（责任岗位/复核闭环）+履约预警 | 处置口径分叉 | 运营异常协同在物流云，**投诉举报类按新办法第十七条必须建在承运平台（运八）并对外公示** |
+
+## 4. 契合度总评
+
+- **业务流程契合：高**。原型的发货计划→装车计划→运单→回单→核算→结算链条与运八 24 步链路几乎同构（接单/装卸/核算/打款/回单/ETC 发票都能对上），且核算规则同源。
+- **角色契合：中高**。原型把货主、承运商、调度、财务分系统分角色投影，运八作为承运商/调度来源都有位；但运八没有像中闽那样的独立工作系统，若运八要在物流云上做调度协同，目前只能用"运输公司调度"泛化角色，颗粒度不够。
+- **数据契合：中**。租户/主体/凭证/导出等主数据模型齐备，但运单、资质、结算三个核心对象双方都要"最终裁定权"，必须提前定归属，否则监测系统（运八上报）与协同平台（物流云）数据打架。
+- **合规契合：天然的上下游**。物流云缺的监管能力恰好是运八的长项（监管上报/发票/资金），运八弱的调度协同恰好是物流云的长项。**"物流云管业务，运八管合规"是阻力最小的组合。**
+
+## 5. 落地建议（给评审/立项用）
+
+1. **明确一句话定位**：物流云 = 计划调度与协同管控；运八 = 合规承运与资金票据通道。中闽 = 自营运力执行方（原型已按此设计，保持）。
+2. **接口清单**（在原型"接口配置"模块中立项，本期已排除、后续应纳入）：
+   - 下行：物流云装车计划/运单 → 运八生成合规运单（路单）；
+   - 上行：运八回传路单号、轨迹、回单、打款流水、发票状态 → 物流云履约监控/凭证中心/付款批次勾稽；
+   - 资质：运八审核结果 ↔ 物流云门禁状态同步。
+3. **三个"唯一"原则**：运单号以运八路单为准、支付以运八通道为准、开票以运八为准；物流云所有对应模块降级为"登记+勾稽"，这与原型现有声明（不动真实资金、不连税务）完全一致，改造成本最低。
+4. **测试关注点**（本仓库视角）：若立项对接，建议在 `tests/api/` 增加"物流云↔运八"接口造数用例，复用现有 24 步链路的 yun8_pipeline，把物流云侧计划/运单造数串进来，重点验证运单号绑定、资质状态同步、结算金额对平三条断言。