track

Files

duxingchen d729a19b86 feat: MOM 撤回出库强制回滚通道

MOM 把误点出库的设备物理回滚到仓库时，Track 被动跟随 MOM 的权威物理状态。

【撤回信号识别】
- action / event 里的 revoke / rollback / revert / cancel 子串匹配
  （MOM 侧字段命名尚未冻结，刻意宽松，避免对方改词就整条链路失联）
- 无显式标记但产品正处于「已出库」时，按"已发货设备收到入库回调 = 货回来了"
  隐式判定

【匹配放宽】
- 常规入库仍严格要求 current_location_id == virtual_warehouse
- 撤回信号、或 payload 带 serial 时才放行「已出库」产品 —— 出库回调已把
  location 置为 None，不放宽则撤回必然失配、静默返回 matched=False
- 刻意不给 sku 兜底也无条件放宽：同型号可能多台，放宽会误标到别的设备

【特权通道】
- 强制覆写 overall_status=已入库 + 位置回滚 virtual_warehouse，优先级高于
  task_service 的【绝对物理终态保护】。两者方向刻意相反：那套约束的是
  "车间内部流转不许用工序名抹掉物理终态"，而本接口是物理事实的权威来源。
  代码内已留醒目注释，防止后续维护者误加状态互斥校验
- 改用 sync_product_status 统一双字段同步（原先硬编码 status="ARCHIVED"
  绕过了 lifecycle.py 的约定），并把 status 变化一并计入 changed，
  避免"状态与位置本就正确时纠偏不提交"

【撤回留痕】
- 追加「撤回出库(重新入库)」主线节点。名称里的「入库」二字是必须保留的契约：
  product_service._has_warehouse_task 用子串判定仓库节点，若只有"出库"会让
  location==virtual_warehouse 的产品被注入假的「待仓库收货」虚拟节点，
  出现"已入库却在等收货"的自相矛盾

【重构】
- 抽出 _pick_warehouse_log_task / _match_inbound_product 复用，出库回调同步简化

2026-09-17 17:42:06 +08:00