5.7 KiB

Raw Blame History

Round 84 经父进程验证的 CP 时间直接物化验收记录

1. 目标与结论

Round 84 关闭 Round 83 留下的最高本地优先项：让固定轨 CP/HYBRID 的最终业务工单直接消费经父进程验证的 CP 工序时间和班次分段，而不是由 Rule 占槽器重新计算。

结论：本地实现、父进程失败关闭、黄金回归、隔离浏览器和主服务验证均通过。真实 MySQL、MES/WMS/SAP、现场费率/罚则和发布环境仍属于外部验收，不因本轮本地通过翻转为生产就绪。

2. 实现契约

2.1 写入前父进程校验

server/engines/solver_process.py::_validate_operation_slots 在任何版本、PO 或 WO 写入前校验：

请求/响应稳定 salesOrderId + salesOrderItemId 身份完整且唯一；
每个订单项与默认工艺路线步骤严格双射，line/workstation/team/tooling 与主数据一致；
segment 有序、互不重叠，processing/elapsed/pause/count 与包络一致；
C1 前后序和 transfer/wait gap；
C2 工位独占、C12 班组/工装累计容量与父进程世界快照；
C3 calendar digest、anchor、horizon、窗口身份和 segment topology；
C12 RHS 只按请求绑定的基础容量 + 正增量生效，容量回显漂移拒绝。

诊断 operation 与生产 operation 继续隔离。移除 C2/C12 时，父校验器只跳过被明确绑定的对应反事实约束；未授权松弛仍失败关闭。

2.2 直接 timing 绑定与持久化

server/engines/cp_engine.py::_prepare_cp_operation_timing 重验可行 slots，绑定 normalized calendar digest，将分钟偏移转换为绝对 plannedStart/End 和 plannedSegments，并按稳定订单项身份附加 _cpOperationTiming。

server/engines/rule_engine.py::materialize_schedule 在 direct timing 模式先完成全量预检，再创建业务对象。RuleEngine 仅作为持久化外壳，WO 精确保存 CP 的时间、segments、processing/elapsed/pause/count、route/logic key、line/workstation/team/tooling、setup/changeover；不调用自身占槽逻辑重算时间。

成功元数据：

placement=cp-calendar-segmented-direct
materializedBy=RuleEngine.validated-cp-timing
directlyConsumedByMaterializer=true
operationTimingValidation.passed=true
materializedC3Validation.cpTimingApplied=true
materializedC7Validation.passed=true

3. 回归发现与修复

第一次全量黄金结果为 13 failed / 1527 passed / 5 warnings。13 项不是 Round 84 正向链失败，而是两个累积兼容问题：

Round 80/81 固定日期测试继续请求 2026-08-03，但动态 demo seed 的 shiftCalendar 已随当前日期生成；Round 83/82 的日历覆盖 fail-closed 因此正确拒绝。测试夹具只平移 calendar date，保留行、班次和资源拓扑。
新父校验器按生产约束检查诊断结果，误拒 C2 removal 的合法工位重叠和 C12 RHS 增量后的合法并行。校验器改为只按已绑定 relaxedConstraintIds / rhsPerturbation 调整对应资源语义，并校验 cumulative capacity 回显等于父快照有效容量。

GitNexus 预改影响：_validate_operation_slots HIGH（2 个直接调用点、2 条求解流程、3 个模块）；_tight_two_order_world HIGH（26 个测试直接调用点）。按该影响面执行 CP/子进程/C3/C7 扩展回归。

4. 自动化验证

原失败文件：81 passed / 1 warning
CP/子进程/C3/C7 扩展：171 passed / 1 warning
Round 84 既有聚焦：142 passed / 1 warning
全量黄金：1540 passed / 5 warnings
Node：60 passed
Web build：4853 modules，PASS；仅既有大 chunk 提示
py_compile：PASS
git diff --check：PASS；仅既有 LF/CRLF 提示

5. 隔离浏览器真实运行

临时根目录 %TEMP%\aps-round84-live2-20260820，所有 APS_*_PATH 显式指向隔离目录，避免仓库 .env 的 world 路径污染。隔离后端/前端为 18184/15184。

引擎	版本	Solve	PO	WO	slots	C3 exact	C3 violations	C7
CP	V20260820-001	FEASIBLE	7	30	30	30	0	passed
HYBRID	V20260820-002	FEASIBLE	7	30	30	30	0	passed

两版均满足 runtime safe、OR-Tools 9.15.6755、Python isolated/user-site disabled、direct materialization 和 operation timing validation。每个 WO plannedSegments 与对应 CP slot 逐段一致；无 CALENDAR、CAPACITY 或 ENGINE_UNAVAILABLE 硬阻断。浏览器页面可见两版排产和 30 条甘特工单，console 只有 Vite debug 与 React DevTools info，无 warning/error。

主项目链路另生成 V20260820-006，但当前标准排产条目为 0，状态 TRIVIAL。该版本只证明 5173 已代理正确的 8003，不作为 CP 正向验收。

6. 服务、数据与边界

8003 /api/health、5173 页面、5173 /api/health 均 HTTP 200。
5173 显式使用 VITE_API_TARGET=http://127.0.0.1:8003；旧 8000 链不再作为验收证据。
sap_mirror.json、approvals.json、world.json、world-proj_712276ba.json SHA-256 与既有保护基线一致。
GitNexus compare main 最终门禁为 82 files / 727 changed symbols / 109 affected processes / CRITICAL；该结果覆盖共享累积脏工作区，未降级风险。
成功 solverMeta 为内部运行时审计保留 executable/package origin 等绝对路径；当前标准世界投影不返回 solverMeta。未来新增公共 solverMeta 接口时必须先定义脱敏投影。
未提交、推送、合并或发布。

外部阻断保持：真实 MySQL 多主机/HA、旧节点停写编排、MES/WMS/SAP 厂商联调、现场资源费率与罚则、签名/Defender/干净离线机。它们分别需要外部环境、凭据、业务确认或发布授权。

5.7 KiB Raw Blame History Unescape Escape