aps-agent/docs/round-65-aps-end-to-end-parallel-implementation-plan.md

# 第 65 轮多 agent 并行实施方案：端到端闭环 APS 排产内核

更新日期：2026-08-02

## 1. 并行实施总览

本轮任务重量：重型。

规模依据：同时涉及 MRP/库存净算、制造需求图、求解器原子性、DTO/Validator、工作流/API、P2/P3 门禁、MES、前端和真实数据验证；核心影响面为 CRITICAL。

确认来源：用户已明确回复“确认 Round 65 推荐方案”。

本轮使用 3 个第一波 worker、1 个第二波前端 worker和 1 个独立审计 worker。主 agent 负责 GitNexus 门禁、计划审计修复、接线集成、真实运行、浏览器验收和最终判断。

因用户明确禁止提交/推送/合并，且当前 289 项工作区变更是权威基线，本轮采用无提交适配：内部 worker 在 forked workspace 修改互斥文件，回传精确 diff/文件清单；主 agent 仅接收经过审查的改动，不创建或推进目标分支。

```text
W1：制造需求 / 供应事件 / 全局净算内核（新文件为主）
W2：原子柔性排产 + 发布/MES 安全门禁
W3：SchedulingProblemV2 + 独立 Validator + 外部 Skill 验证边界
主 agent：API/工作流接线、兼容层、数据迁移、集成验证
W4（第二波）：前端阶段状态、阻断与真实浏览器流程
Audit：只读集成审计
```

## 2. 依赖图

```text
计划审计 PASS
├─ W1 制造需求与供应图
├─ W2 原子排产 / MES fail-closed
└─ W3 V2 契约 / Validator
        ↓
主 agent 接线：prepare → solve → validate → materialize → publish → dispatch
        ↓
Focused backend tests PASS
        ↓
W4 前端阶段状态与 API 消费
        ↓
MOM 负向 + 康尼/fixture 正向 + 浏览器验收
        ↓
全量黄金 / Node / Web build / diff / GitNexus detect_changes
        ↓
独立审计 → 修复 → 复验 → 收口
```

## 3. Worktree / 工作区规划

### 已确认的无提交适配

标准 round 协议通常从目标分支创建 round/worktree 并提交 worker 成果。本项目当前不能照搬：

- `main` HEAD 不包含现有 289 项权威成果；
- 用户禁止提交、推送、合并；
- 从旧 HEAD 创建干净 worktree 会得到错误基线。

因此采用：

- 主工作区 `D:\ItemSpace\14.工业智核\aps-agent`：受保护集成区。
- multi-agent forked workspace：继承当前会话上下文，worker 只写指定文件。
- 禁止任何 worker 使用 `git checkout/reset/clean/stash/commit/push/merge`。
- worker 回传修改路径、focused tests、diff 范围和残余风险。
- 主 agent 接收前运行 `git diff -- <paths>`，发现越界立即拒收。
- 现场数据 `server/data/**`、`.env`、数据库、release 产物和日志全部只读保护。

## 4. Worker 划分

### W1：制造需求与供应事件内核

目标：把商务订单、多层 BOM、库存/在途、采购/委外和 MAKE 子件转换为唯一、可守恒的制造需求图。

写入范围（互斥）：

- `server/aps_domain/closed_loop_problem.py`（新）
- `server/aps_domain/supply_netting.py`（新）
- `tests/golden/test_closed_loop_scheduling.py`（新）

禁止修改：

- `mrp.py`、`flex.py`、`pool_engine.py`、`workflow.py`、`gateway/app.py`
- 现场数据和现有测试

验收：

- 跨订单共享库存只分配一次。
- MAKE/BUY/SUBCONTRACT 数量与 pegging 守恒。
- 时间分段在途/采购/委外供应事件生效。
- BOM 环、缺失路线和不可信供应显式阻断。
- 当前 MOM 数据只产生需求/阻断，不产生生产订单或工单。

### W2：原子排产与发布/MES 安全门禁

目标：修复部分工单写入并统一柔性发布/下发失败关闭。

写入范围（互斥）：

- `server/engines/pool_engine.py`
- `server/aps_domain/mes.py`
- `tests/golden/test_flex_atomic_schedule.py`（新）
- `tests/golden/test_flex_publish_mes_gate.py`（新）

禁止修改：

- MRP/需求图、DTO/Validator、API、前端、现场数据

验收：

- 第 N 道硬失败时，本订单 0 VL、0 WO、0 资源/模具/计数残留。
- 每个 WO 都有唯一 VL；`woCount` 等于实际工单数。
- DRAFT、孤儿、不完整、硬阻断或证据漂移的柔性版本不能进入 MES 预览/确认/执行。
- 现有幂等、补偿和固定轨行为保持兼容。

### W3：V2 契约与独立 Validator

目标：建立所有本地/外部算法共享的完整输入输出和失败关闭验证器。

写入范围（互斥）：

- `server/aps_domain/scheduling_problem_v2.py`（新）
- `server/aps_domain/scheduling_validator.py`（新）
- `tests/golden/test_scheduling_validator_v2.py`（新）

禁止修改：

- 现有 `scheduling_dto.py`、引擎、API、前端和现场数据

验收：

- V2 包含 Requirement、SupplyEvent、OperationActivity、Resource、ObjectivePolicy、ConstraintPolicy。
- Solution 包含 activity identity、时间、资源、未排需求、硬违反、assumptions 和 provenance。
- Validator 拒绝重叠、错序、越日历/维保、错能力、物料未齐套、孤儿、重复 activity、证据哈希漂移。
- 可把合法 solution 转为待物化活动，但本 worker 不直接写 world。

### 主 agent：接线与兼容层

写入范围：

- `server/aps_domain/flex.py`
- `server/aps_domain/orders.py`
- `server/aps_domain/mrp.py`（仅必要接线/全局净算兼容）
- `server/aps_domain/workflow.py`
- `server/gateway/app.py`
- `server/contracts.py`、`shared/schemas/**`（如新增 HTTP 契约）
- `apps/web/src/api/types.ts`、`apps/web/src/api/client.ts`（契约阶段）
- 迁移/初始化和集成测试

责任：

- 修改前逐符号 impact，API handler 修改前 `api_impact`。
- 收敛为唯一 `prepare → solve → validate → materialize` 事务边界。
- 建立 P2 `flex.schedule.publish`，保留固定轨兼容。
- 提供制造准入/阶段/阻断/负荷/未排需求 API。
- 不在接线中伪造 ASM、班组、模具或到货。

### W4：前端阶段化业务流程（第二波）

依赖：后端契约和 focused tests 稳定后开始。

写入范围（互斥）：

- `apps/web/src/orders/OrderPanel.tsx`
- 新增 `apps/web/src/orders/*` 阶段/阻断组件
- `apps/web/e2e/closed-loop-scheduling.spec.ts`（新）
- 必要样式仅限闭环排产命名空间

禁止修改：

- 后端、通用认证、全局布局、现场数据

验收：

- UI 区分“已分解 / 准入通过或阻断 / 排产草案 / 已发布 / 已排生产 / MES 可下发”。
- MAKE 建议不得冒充生产订单。
- 显示 39 缺路线、67 模板/缺能力等聚合和逐项原因。
- 硬阻断时不展示绿色“排产完成”；提供数据维护/候选确认入口。
- Playwright 覆盖 MOM 负向与完整 fixture 正向阶段。

### Audit worker：独立集成审计

只读范围：本轮计划、全部 diff、测试输出、真实运行与浏览器证据。

验收：严格按 `AUDIT: PASS|FAIL` 输出；无 blocking finding 才可收口。

## 5. 主 agent 先行门禁

实施前必须完成：

1. `impact(run_flex_schedule)`、`impact(sync_flex_orders_to_sales)`、`impact(PoolEngine.solve)` 已有结果复核；CRITICAL 已向用户报告。
2. 对 `preview_dispatch`、`stage_dispatch`、`apply_dispatch`、发布执行函数运行 impact。
3. 若修改 `/api/flex/schedule`、MRP、发布或 MES 路由，先运行 `api_impact`。
4. 保存现场 world/master.db 和关键源文件 SHA 清单。
5. 记录当前 8003/5173 健康和浏览器基线。

## 6. 分阶段集成顺序

1. 集成 W1 新模型和测试；不接生产路径，先证明需求/供应守恒。
2. 集成 W3 Validator；用 fixtures 验证非法 solution 全部失败关闭。
3. 集成 W2 原子性与 MES 门禁；优先消除 P0 执行风险。
4. 主 agent 接线到 `run_flex_schedule` 和 P2 发布；运行后端 focused tests。
5. 接入 W4 前端；运行 Web build 与 Playwright。
6. 执行真实数据、全量回归、detect_changes 和独立审计。

## 7. Worker 回传格式

每个 worker 必须报告：

- 完成状态；
- 修改文件；
- focused 测试命令和结果；
- 验收标准逐项结果；
- `git diff -- <write scope>` 范围检查；
- 关键问题、解决方案、残余风险；
- 明确声明未提交、未推送、未合并、未触碰现场数据。

发现跨边界依赖时先 `send_input` 通知主 agent 或相关 worker，不得自行修改对方文件。

## 8. 测试与证据资产

本轮必须保留可重放资产：

- 跨订单共享库存 fixture；
- MAKE/BUY/SUBCONTRACT 多层 BOM fixture；
- 第五工序缺能力的原子性 fixture；
- 合法/恶意外部 Skill solution fixtures；
- MOM--00280 隔离负向验收脚本/断言；
- 康尼或完整隔离 fixture 正向验收；
- Playwright 闭环阶段测试。

## 9. 审计与修复

- Worker 自检后，主 agent 运行 focused + 集成 + 全量验证。
- 独立 audit worker 检查目标覆盖、集成风险、验证充分性、越界改动和文档证据。
- 仅 blocking findings 触发修复；优先回给原 worker，最多三轮同类修复。
- 修复后重跑直接测试、受影响测试和全量门禁。

## 10. 用户进度事件

需要报告：

- 计划审计通过并开始实施；
- worker 完成或出现阻断；
- P0 MES 风险修复完成；
- 制造需求/Validator 接线完成；
- 真实数据和浏览器验收完成；
- 独立审计结果与修复；
- 最终收口或外部阻断。

## 11. 清理与保护

- 不删除、移动或重置用户/未知变更。
- 不清理 `server/data/**` 现场状态，不执行 `git clean/reset/checkout`。
- 关闭完成/失效 agent，清理仅由本轮产生且已确认无用的临时文件。
- 不提交、不推送、不合并、不发布。
- 结束时复核 8003/5173、git status、world/master.db 摘要和 agent 状态。

## 12. Worker focused 验证命令

- W1：`.venv\Scripts\python.exe -X utf8 -m pytest tests/golden/test_closed_loop_scheduling.py -q`
- W2：`.venv\Scripts\python.exe -X utf8 -m pytest tests/golden/test_flex_atomic_schedule.py tests/golden/test_flex_publish_mes_gate.py -q`
- W3：`.venv\Scripts\python.exe -X utf8 -m pytest tests/golden/test_scheduling_validator_v2.py -q`
- W4：`npm run build --prefix apps/web`；`npx playwright test e2e/closed-loop-scheduling.spec.ts --project=chromium`（在 `apps/web` 下，隔离后端）
- 主 agent 接线：上述 focused 集合 + `tests/golden/test_contract_sync.py` + 受影响 MES/MRP/审批测试。

## 13. Pre-target-merge 停止点

全量验证和独立审计通过后，主 agent 必须先形成 pre-target-merge 总体报告，自问并说明：哪些结论依赖 fixture、哪些真实数据仍阻断、是否存在未覆盖的外部系统/硬件/权限风险、当前 dirty 基线是否出现无关变化。本轮默认保持未提交、未合并；没有新的用户明确授权，不执行 commit/merge/push/publish。

## 14. 执行结果（2026-08-03）

- 第一波 W1/W2/W3、第二波 W4 与首轮 Audit 已结束；Audit 返回 7 个 blocking finding。
- 审计修复按互斥边界追加 W-EVIDENCE、W-V2RES、W-PROVENANCE、W-E2E；主 agent 独立完成 WMS 精确版本、订单读幂等、API/UI 集成与全量验证。
- W-EVIDENCE：完整 V2/资源快照 evidence，TEAM/TOOLING/层级/寿命漂移失败关闭。
- W-V2RES：多资源契约、组织层级容量、班组并发与模具寿命。
- W-PROVENANCE：稳定 sourceHash/problemId 与外部 Skill 业务日期。
- W-E2E：生产 `create_app()` + 内存 world 的隔离服务，真实浏览器正负闭环 2 passed。
- 主 agent：WMS Saga 不沿用旧 DRAFT；`/api/orders` 恢复真实状态；订单 GET 不再无条件写现场 world。
- 全量门禁：黄金 979 passed、Node 60 passed、Web build passed、Playwright 2 passed。
- 所有 worker 已关闭；最终独立复审 `AUDIT: PASS`。未提交、未推送、未合并、未发布，保留 pre-target-merge 状态。