# Round 89: optimize 原生 CP-SAT 求解器接入

更新时间：2026-09-16

## 1. 本轮目标

把 `OptimizeEngine` 从「选规则 + 复用 PoolEngine 物化」推进到真正的 V2 原生求解：
输入 `SchedulingProblemV2`，由 OR-Tools CP-SAT 决定资源分配与时序，输出
`SchedulingSolutionV2`，并且必须通过 APS 独立的 `SchedulingValidator`。

上游依据：`docs/round-85-optimize-integration-shape-plan.md` 第 14 节明确记着
「CP-SAT 的 V2 原生求解器仍应作为后续轮次接入，本轮不把 PoolEngine 适配器冒充为
CP-SAT 最优证明」。本轮就是那一轮。

## 2. 现状（本轮开始时的事实）

- `OptimizeEngine.solve_flex()` 只做算法选择 + provenance 标注，实际物化交给
  `PoolEngine`（贪心占槽）。七种派工规则已跑通，但它们不是 CP-SAT。
- `server/engines/cp_engine.py` 是**经典轨**（operations/routings/workstations）
  的 CP-SAT，不是 flex 闭环 V2 原生；`solver_process.py` 是它的子进程安全边界。
- 集成环境限制：项目 `.venv` 里的 NumPy 以 X86_V2 为基线构建，而本机 CPU
  （sd-server，Family 6 Model 15）不支持该指令集，`ortools.sat.python.cp_model`
  导入即失败。这与 `round-85` 记录的全量 CP/Excel 测试受限是同一个原因。

## 3. 本轮范围

### Slice 1（本轮完成）

- 新增 `server/engines/optimize_cpsat.py`：`SchedulingProblemV2 -> CpsatOutcome`，
  内含解与可审计元数据（solverId/solverVersion/OR-Tools 状态/耗时/种子/规模）。
- 模型：每道工序在合格设备中选一台（`AddExactlyOne` + 可选定长区间），同设备
  `AddNoOverlap`，设备日历与维保之外的时间作为阻塞区间一并进入 NoOverlap，工序链按
  `predecessorActivityIds` 串行，目标为最小化总拖期。
- provenance 与 problem hash 绑定，与 `flex_version_to_solution_v2` 同一套口径。
- 新增 `tests/golden/test_optimize_cpsat_native.py`：解通过独立 V2 校验；总拖期不劣于
  同口径 EDD 基线。

### Slice 2（下一轮）

- `OptimizeEngine.solve_flex` 增加 CP-SAT 算法路径（`algorithmId=optimize.cpsat`），
  物化到 flex* 行，落版本、证据链，走 `/api/flex/schedule` 端到端。
- 目标函数与 PoolEngine `totalTardiness` 口径对齐（当前两者定义不同，不能直接比较）。
- 时间离散化（分钟 -> 5/15 分钟桶）、派工解热启动、缩短求解时间。
- 冻结/在制/模具寿命/班组与工装累计容量接入模型。

### 明确不做

- 不改 WorldStore 权威语义、审批门禁和审计链。
- 不新建第二套订单/资源/版本模型。
- 不声称 PoolEngine 适配器结果是 CP-SAT 最优证明。

## 4. 验收

- `pytest tests/golden/test_optimize_cpsat_native.py`：在具备可用 OR-Tools 的环境
  通过；在 NumPy/OR-Tools 不可用的环境按既有策略 skip，不得 error。
- 解必须 `validate_solution(...).valid is True` 且无 hard violation。
- 现有回归不受影响：`tests/golden/test_optimize_simulation_world_pack.py`、
  `tests/golden/test_optimize_engine.py`。
- 报告必须区分证据等级：代码、测试、真实运行；环境性跳过要写清原因。

## 5. 停止条件

- V2 契约无法表达所需约束，且无法通过局部兼容字段解决。
- 需要放宽校验才能让测试通过。
- 需要新增生产依赖或许可而没有明确运行环境。

## 6. Slice 1 证据（2026-09-16）

- 隔离解释器（CPython 3.11.15 + NumPy 1.26.4 + OR-Tools 9.11.4210）：
  `2 passed`；模拟数据包 72/72 工序全部排入、`validate_solution` valid、
  总拖期 1,782,876 分钟不劣于同口径 EDD 基线。
- 项目 `.venv`：`1 skipped`（OR-Tools 因 NumPy 基线与 CPU 不兼容不可用）。
- 已知限制：`INFEASIBLE` 曾因拖期变量上界未包含「历史欠交」而误判，已修（
  交期早于计划起点的部分必须计入上界）；当前只做到 FEASIBLE，未证明最优。