aps-agent/docs/round-84-cp-direct-material...

83 lines
5.7 KiB
Markdown
Raw Permalink Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# 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 正向链失败,而是两个累积兼容问题:
1. Round 80/81 固定日期测试继续请求 2026-08-03,但动态 demo seed 的 shiftCalendar 已随当前日期生成;Round 83/82 的日历覆盖 fail-closed 因此正确拒绝。测试夹具只平移 calendar date,保留行、班次和资源拓扑。
2. 新父校验器按生产约束检查诊断结果,误拒 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/干净离线机。它们分别需要外部环境、凭据、业务确认或发布授权。