模块单测和页面构建全部通过，并不等于一条业务流程能够从开始走到正确的最终状态。物流平台的一个流程可能跨越主数据、仓储、运输、承运商、计费、园区和 OpenAPI。任何一个事务边界、状态映射或事件消费遗漏，都会让单个模块看似正常而全链路失败。

这次验收要建立覆盖全部业务域的冒烟测试（smoke test），并逐步核对数据库结果；重复已有测试无法覆盖这个目标。

先备份并限定范围，再写入测试数据

测试前对当前数据库做完整备份并记录校验信息。所有新增业务编码使用统一运行前缀，更新和删除只作用于本轮创建的数据。

测试数据按要求保留，以便复核失败现场；工具同时生成可选清理 SQL，但不会自动执行。另建临时 …

在物流系统中，公司、经营组织、项目和仓库经常同时出现在登录上下文、业务单据和查询条件里。它们看起来都像“数据归属”，但不能互相替代。

这次我没有按字段名称猜测，而是从主数据表、典型关联 SQL 和用户会话中检查它们的真实用法。

公司：最外层的数据范围

公司或分公司是平台的数据隔离边界，业务表中的 org_id 通常保存公司主数据的内部 ID，而不是公司编码。

大量订单、库存和配置查询都先按 org_id 过滤。它决定当前用户能进入哪一个公司范围，也是项目、仓库和经营组织共同的上级归属。

项目：业务合同或运营项目

project_id 指向项目主数据。一个项目属于某家公司，并通常绑定默认仓库或仓 …

物流系统中的小 Bug 经常反复出现，不一定是规则没有写，而是规则只写在某个按钮、页面或异常分支里，没有覆盖真正改变业务状态和数据的入口。

下面四类缺陷来自不同功能，但中心问题相同：业务规则必须放到真正改变状态或数据的共同操作中，并让所有入口返回一致的处理结果。

编辑权限必须约束动作，而不只是按钮

费用详情只允许在 NEW 或 REJECTED 状态编辑。页面隐藏了部分按钮，但表格事件仍能打开编辑框，导致已经进入财务流程的数据存在被修改的风险。

修复不能停在视觉层。编辑动作的统一入口必须先检查状态，后端也需要拒绝越权更新。验证时不仅点击可见按钮，还要覆盖行事件、快捷操作和直接请求。

这说明权限 …