# Round 66 求解器进程隔离可恢复状态快照

更新日期：2026-08-03

- Goal：Windows 求解器进程隔离与 Fail-Closed | Round 66 本地完成（最终独立复审 `AUDIT: PASS`）；APS 总目标继续推进下一 P0
- 目标分支：`main`（不提交、不推送、不合并、不发布）
- 主工作区：`<repo-root>` | 权威 dirty 工作区
- 协议：`aps.solver-process.v1`
- 服务：8003 PID `21576`、5173 PID `9808`，均 healthy

## 已落地能力

- CP/HYBRID 的 native 求解被隔离到受控子进程；父进程只在退出码、fatal marker、协议、请求身份与运行时身份全部通过后物化排产结果。
- fatal、非零退出、超时、非法/截断响应、缺 success marker、协议或 request mismatch 均结构化 fail-closed。
- 成功响应必须通过 `responseDigest`、请求/响应条目完整排列与关键业务字段守恒、pipeline/status、可行解 objective/gap 与 operationSlots 全覆盖校验；任何不一致统一 `SOLVER_RESPONSE_INVALID`。
- CP 与 HYBRID 失败都返回 `UNAVAILABLE`，不生成 PO/WO，不产生可发布版本；HYBRID 不静默降级成 RULE 假成功。
- timeout 会回收完整进程树；子进程及 grandchild 不残留，父进程和 8003 保持存活。
- 默认 PATH Anaconda 运行时被稳定拒绝；`.venv` 与 `.sidecar-venv` 各连续 5 次探针通过。
- Sidecar 支持 `--solver-child`；桌面 child env 清理 Conda/Python 污染变量，并强制关闭 user-site。

## 源码 Sidecar `-I` 真实发现与修复

- 首次真实执行源码 `server/sidecar.py --solver-child` 且启用 Python `-I` 时失败：隔离模式移除了源码 checkout 的 import root，导致 worker 无法导入。
- 在 GitNexus LOW impact 门禁后，`server/sidecar.py` 仅 bootstrap 已解析、已校验的 trusted source root，再委托 `solver_worker`；未恢复任意外部 `PYTHONPATH`。
- 新增黄金测试 `test_source_solver_child_entry_runs_under_isolated_python`。
- 修复后的真实源码 Sidecar child：CP `OPTIMAL`，1 PO / 10 WO / 10 operationSlots，协议 `aps.solver-process.v1`，`runtimeSafe=true`。

## 回归与质量门禁

- 最新 post-fix focused：`80 passed`，包含源码 Sidecar `-I` 与协议摘要/语义假绿负向回归。
- 最终全量黄金：`1029 passed, 2 warnings`（最新源码复跑，300.23 秒）。
- Node：`60 passed`；Web build：passed。
- ruff、Python compile、Node syntax check、`git diff --check`：passed。
- 浏览器：title=`APS 智能排产工作台`，root=true，console warning/error 均为 0。

## 真实运行证据

### 复制 `world.json` 正向路径

- CP：`OPTIMAL`，1 PO / 10 WO / 10 operationSlots，协议 v1，`runtimeSafe=true`。
- HYBRID：`OPTIMAL`，1 PO / 10 WO / 10 operationSlots，协议 v1，`runtimeSafe=true`。
- 来源文件 SHA-256 前后均为 `C6E7FF090719DB505AF5C3B0D8ADD376CBA7843D6E6982A68C1BA02C342052FA`。

### 复制 MOM 数据边界

- CP/HYBRID 求解器均返回 `OPTIMAL`，但现有业务主数据阻断导致 0 PO / 0 WO、1 operationSlot / 1 conflict，且不可发布。
- 该结果证明进程边界可运行，不证明 MOM/工厂现场主数据已补齐，更不得宣称现场完整排产闭环完成。
- MOM 来源文件 SHA-256 前后均为 `6B64ADF6F29A43A518D89718610EE71FAD60E86D3F38CD5CFF26F1740CC53F7D`。

### 故障注入

- fatal：CP/HYBRID 均 `UNAVAILABLE`，0 PO / 0 WO、不可发布；父进程存活、业务世界原子、无 RULE 静默降级。
- timeout：15.633 秒后失败关闭，grandchild 随进程树回收；同样 0 PO / 0 WO、不可发布，父进程存活且业务世界原子。

## 首轮独立审计与修复

- 首轮独立审计结论为 `AUDIT: FAIL`：发现合法 JSON 可携带错误/缺失摘要，或自行重算摘要后把非空请求伪造成 `OPTIMAL + entries=[]`。
- 已修复：父进程强制重算 `responseDigest`，校验请求/响应条目基数、重复语义与关键字段完整排列，校验 pipeline/status 以及可行解 objective/gap/operationSlots 覆盖；新增 8 个负向用例，原假绿复现现返回 `SOLVER_RESPONSE_INVALID`。
- 冻结链路源码已增加 `sys.frozen -> sys.executable --solver-child` 自举；当前旧冻结 EXE 未重建，因此仍只列构建后验收，不冒充发布制品通过。
- 后续复审又发现“大请求 + 子进程不读 stdin”会让 Windows pipe 写入绕过 deadline，以及 `operationSlots` 可带越界索引；现改为临时文件 stdin，严格拒绝越界索引并校验 orderNo/productId 绑定，同时补 wrong pipeline/status 负向用例。
- 最终独立只读复审：`AUDIT: PASS`；2 MiB 请求且 child 永不读取 stdin 的真实复现 0.736 秒内 `SOLVER_PROCESS_TIMEOUT`，focused 80 passed。

## 数据保护口径

- `server/data/world.json` 与 MOM world 的 JSON 业务源验收前后 hash 不变。
- `server/data/**` 与 `.env` 无 Git 状态变化；未用现场目录承载测试输出。
- `master.db` 会因运行时 license `last_seen` 等操作元数据更新；不得用文件级 hash 冒充“数据库完全不变”。业务数据保护以隔离目录、业务表/对象核对和 JSON 业务源 hash 为准。

## 外部/构建后边界

- 现有冻结 Sidecar EXE 仅旧 `--probe-child` 通过；本轮未重建冻结产物，不能宣称新 `--solver-child` 已被打包验证。
- 需要在重建后对冻结 `--solver-child` 做真实冒烟，并继续完成干净 Win10/11、签名、Defender for Endpoint、真实 CI 与客户 DLL/运行时验收。
- MOM 仍受现有工艺、能力、班组/模具、采购/委外承诺等主数据边界约束；正式现场数据需工厂/SAP/WMS 补齐。
- 真实 MES/WMS/SAP 凭据、网络和白名单仍是外部输入。

## 下一优先级

- P0 下一本地项调整为：**全量 P2/P3 evidence 封套**与**审批迁移可靠性**。
- 审批迁移可靠性需覆盖 token 摘要一致性、损坏源 fail-closed、数据库时钟/TTL 与 CAS 并发语义；不得因已有首切片提前标记完成。
- 未经用户授权，不执行 commit/merge/push/publish。

运行证据：`docs/round-66-solver-isolation-runtime.json`。