# 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/干净离线机。它们分别需要外部环境、凭据、业务确认或发布授权。