aps-agent/poc/pi-fallback/GOAL-P3.md

GOAL：Pi Agent 兜底能力 · P3 高风险场景与运维（多 agent 协同 · 第四轮）

本文件是本轮协同的唯一权威协调板。每位 agent 开工前必读；完成后在文末留言板交接。 已提交基线：3543208（P1）+ 967ae37（P2）+ poc 设施两轮。P2 S3 冒烟 16/16、注入攻击 21/21。

本轮目标（P3 出口标准）

按根目录《Pi-Agent兜底能力详细方案》§6 P3：S4（缺算法/策略的沙盒试排）/S6（外部集成故障补录与对账）/S7（现场运维诊断）三个高风险场景 + agent.fallback.execute.highrisk=P3 的白名单治理机制。

具体交付：

1. P3 白名单机制：agent.fallback.execute.highrisk 从"默认拒绝"升级为"白名单放行"——配置化的场景级白名单（文件化，类似 features.json 语义；文件缺失/损坏 → 默认全拒 fail-closed，与 fallback 开关的默认关语义对齐），每项放行本身登记为 P2 管理动作（改白名单要确认卡）；
2. S4 缺算法沙盒试排：Pi 在沙盒内生成/执行临时分析或试排脚本，产物为草稿版本（P1 语义，不写主干）；与既有 flex.schedule / scenario.compare 沙盒语义对齐；收益与风险边界在文档写明；
3. S6 集成故障补录：MES/WMS 接口故障时，Pi 辅助生成待补录清单/对账文件；补录写操作逐笔过确认卡（P2 既有机制）；外部系统恢复后的对账流程（读侧对账 P0 + 差异报告）；
4. S7 运维诊断入口：运维角色专属入口（与 auth 角色体系对齐；非运维角色物理不可见/不可用）；Pi 可读日志/配置诊断（只读 P1），改配置类动作走 highrisk 白名单 + 确认卡；全程审计可回放；
5. 角色门禁：fallback 触发增加角色维度（设计员评估现状 auth/角色能力的复用面；普通用户/运维/管理员对 S4/S6/S7 的可见性矩阵）；
6. 黄金测试：白名单 fail-closed（缺失/损坏/越权场景）、S4 草稿不碰主干断言、S6 补录确认卡链路、S7 角色越权拒绝、P3 动作未入白名单默认拒绝——全部确定性；
7. 真实冒烟：S6 场景（模拟 MES 断连 → Pi 生成补录清单 → 确认卡 → 补录 → 恢复后对账报告）；S7 诊断场景只读部分；
8. 文档同轮：fallback.md P3 章节、harness.md 权力矩阵、CHANGELOG（FB-03 条目）。

硬约束（GOAL-P2 全部继承，追加）

• 不 git commit/push；改动最小化；Python 用 .venv\Scripts\python.exe；
• P3 白名单语义必须 fail-closed：任何配置问题 → 拒绝而非放行（与 features 的 fail-open 相反，与 fallback 默认关同理，要在设计里写清楚语义不混淆）；
• S4 产物只允许草稿语义：验证器要断言沙盒试排不产生主干写事件；
• S7 运维入口：角色判定复用 server/auth 既有身份体系，不新造权限模型；
• 黄金测试确定性（fake runner）；真实冒烟用临时 APS_HOME；
• 每轮结束统一等提交授权。

角色分工

角色	任务	输出
Agent-L 设计员	P3 文件级详细设计（白名单 schema/角色矩阵/三场景接线/测试矩阵/爆炸半径）	poc/pi-fallback/P3-DESIGN.md
Agent-M 实施员	按设计施工产品代码 + 黄金测试	代码 + P3-IMPL-NOTES.md
Agent-N 验证员	全量回归 + S6/S7 真实冒烟 + 白名单攻击复证	P3-VALIDATION.md

已知前置问题（设计中必须回答）

1. 角色体系现状：server/auth 现有角色粒度是否足以表达"运维"？若无，最小扩展方案是什么（不新造权限模型）；
2. S4 与既有沙盒的关系：flex.simulate_due / scenario.compare 已是沙盒试排，Pi 兜底 S4 的增量价值边界在哪（避免重复造轮子——兜底应编排既有沙盒意图，而非自建试排引擎）；
3. S6 对账的"恢复后"语义：外部系统恢复是事件还是人工触发？对账报告的证据链怎么冻结；
4. 白名单粒度：场景级（S4/S6/S7 整体开关）还是意图级（每个 highrisk 动作单独登记）？给出取舍。

协同留言板

（格式：[角色] 时间 — 结论/交接物/给下一位的话）