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

92 lines
14 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# 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 动作单独登记)?给出取舍。
## 协同留言板
(格式:`[角色] 时间 — 结论/交接物/给下一位的话`)
[Agent-L 设计员] 2026-09-03 — P3 文件级详细设计完成,交接物:`poc/pi-fallback/P3-DESIGN.md`(11 节 + 附录,§0 现状事实 15 条全部源码核实、§8 测试矩阵 21 例、§9 双冒烟脚本规格、§10 爆炸半径 rg 实测无 HIGH)。
**4 个前置问题的答案**(详见设计 §4.1/§5.1/§6.5/§2.3):
1. **角色体系**:server/auth 现有粒度足够——roles 是自由字符串元组(JMS 透传),审批角色有 action/power/全局三层 env 解析(APS_APPROVAL_ROLE_POLICIES 既有机制);「运维」= 角色字符串 `ops`,最小扩展 = 纯配置零代码,server/auth 一行不改;「非运维物理不可见」落在 propose 闸 1.5(身份不符 → return None,与原话术同形态)。
2. **S4 与既有沙盒**:兜底不建试排引擎——S4 = Pi 编排既有沙盒意图(flex.simulate_due/flex.compare/scenario.compare/scenario.sensitivity,全 P0/P1 深拷贝沙盒),增量价值 = 意图自动组合 + 参数探索(临时脚本只作产物不执行,围墙无代码执行面)+ 草稿叙事;验证器用 world_fingerprint 前后相等(auditEvents 等 append-only 键已被指纹排除)+ 零 WORLD_WRITE 审计断言「草稿不碰主干」。
3. **S6 恢复语义**:人工触发,不是事件——用户明示后编排器 probe readiness,connected 才进对账协议(不轮询、不后台监听,现状无告警子系统也不造);证据链三层冻结 = 外部响应原文落盘 sha256 → manifest 汇总指纹 → 指纹进 ALGO_RUN 审计 rationale,对账纯读 P0,差异处置回到逐笔卡。
4. **白名单粒度**:意图级为骨架 + 场景级为聚合开关 + 角色级第三维,三层同文件——纯场景级会把 S7 里不同权力动作一勺烩,纯意图级丢失场景归属会让意图被全局放行悄悄扩面。
**关键设计决策**(M 轮照此施工):① 白名单 fail-closed 到「未知键即全文件判损坏」的强度(与 features.json 的 unknown 忽略相反,两文件两加载器语义隔离,互不 import);② 白名单出卡/执行双端 sha256 比对,审批窗口内白名单变更 → 执行拒绝;③ P3 三场景只开放 frozen 步 + params 内联(吸收 K 轮教训:ASSISTED 真实模型未端到端验证、artifactRef 对真实 Pi 物理不可用);④ S6 逐笔出卡 = 每项 backlog 一张独立 P2 卡(卡间无事务关联,符合补录语义),单轮上限白名单 maxItemsPerRun;⑤ 改白名单 = `agent.fallback.policy.update` P2 管理动作(Pi 只产 diff 声明,完整文档由编排器再生成),改配置 = `agent.fallback.ops.config.apply` P3(继承既有 requiredApprovals=2 + SOD + executionGrant 双人链,一行新机制不造);⑥ S7 只读诊断不登记任何新工具——日志/配置脱敏后经 inbox 注入,Pi 仍只有 fs_read。
**风险最高点**:§10.1/10.2 双 MED——fallback_lane 计划锁闸口改造(validate_plan/check_step_request 硬拒改白名单裁决)与 execute_confirmed 两个写文件新分支(热路径);均已给降级方案(frozen 直执 + checkpoint 前置保证最坏退化为一次显式失败且已回滚的确认;原子写 tmp+replace 无中间态),且 H-8 专项守护「白名单缺失时 P2 存量路径零影响」。
给 Agent-M 的话:照 §1 变更清单 12 项施工,§2.1 裁决表与 §8 测试矩阵是硬契约;三处易踩坑已在设计写明——新出卡路径必须照做指纹对齐(refresh_confirmation_world_fingerprint)与 contextPolicies setdefault(§0.14①②);S6 多卡循环 stage 时每张卡都要独立走这套;脱敏函数失败归并不阻断(export_snapshot:791 先例)。施工前先复跑 P2 三目标文件 41 例确认基线绿。未 git commit,等统一授权。
[Agent-M 实施员] 2026-09-04 — P3 产品代码 + 黄金测试施工完成,交接物:`poc/pi-fallback/P3-IMPL-NOTES.md`(改动清单 11 文件、自验数字、9 条偏差如实登记、遗留清单)。
**自验数字**:新建 `test_fallback_highrisk.py` 21 例(H-1..H-21,§8 矩阵全覆写)**21 passed**;四文件联合(highrisk+execute+lane+feature_flags)**65 passed**(P2 存量 44 例零回归);爆炸半径 19 文件 **195 passed**;ruff 与 HEAD 基线多重集比对 **59=59 零新增**(施工中的 9 条新增违规已全部修净复核)。文档三处同步(harness.md 矩阵+2 行+变更记录 / fallback.md P3 章节 / CHANGELOG FB-03 条目)。
**两条设计外增量(已在 IMPL-NOTES/CHANGELOG 登记,请 N 重点复证)**:⑦ harness `refresh_confirmation_world_fingerprint` 原实现推进指纹不重算信封哈希——S6 第二张及以后确认卡必现「完整性校验失败」,已修(P2 单卡未暴露是因为无身份绑定时指纹为空 refresh 空转);⑧ S6 兄弟卡世界指纹重锚——首笔落账后同 run 其余待批卡冻结指纹推进+信封重算,否则漂移检测误杀,§6.3「逐笔互不影响」语义的落地必需。
**遗留(诚实标注)**:① S6/S7 两个冒烟脚本本轮未写,§9.1/§9.2 验收点 + smoke_s3_execute.py 手法可直接照做,CHANGELOG 数字已留「待 Agent-N 补实测」;② 分批全量黄金未复跑(只到爆炸半径切片 195 例);③ MockMesClient 无 fetch_work_order/readiness,stub 下对账按 MISSING 如实呈现,真实 MES 链路待冒烟。
给 Agent-N 的话:除设计 §8 矩阵外,建议专项复证偏差⑦⑧的攻击面——伪造/篡改同 run 待批卡后重锚是否仍 fail-closed、非同 run 的世界改动在第二笔审批时是否仍被漂移检测拦下(H-8/H-20 已覆盖基础形态)。未 git commit,等统一授权。
[Agent-N 验证员] 2026-09-04 — 终验完成,交接物:`poc/pi-fallback/P3-VALIDATION.md`(全量回归/专项复证/双冒烟逐步证据/出口标准 8 项逐条/未验证清单)+ `tests/golden/test_fallback_p3_attack.py`(7 例攻击专项)+ `smoke/smoke_s6_reconcile.py` / `smoke/smoke_s7_ops.py`(五/四阶段可复跑)+ `regression_driver.py` 与两份回归结果 JSONL。**判定:P3 条件 NO-GO。**
**核心数字**:全量 golden 191 文件 **1501 passed / 18 failed / 10 errors**(stash 基线 9 文件逐例一致,全为既有失败:native sidecar 环境依赖 11 例 + folder_schedule 系列 6 例 + MES/HTTP fixture 8+2+4+2——与 P3 零相关);文档门禁 **25 passed**;ruff M 的 8 文件 **59=59 零新增**复算一致;四文件联合 **65 passed**、含攻击专项五文件 **72 passed**。
**偏差⑦⑧专项 7/7 全过**:第二张卡信封完整+乱序双批、旧卡伪造/参数篡改/重放三态全拒、跨 run 卡不被重锚(漂移检测拦)、非兄弟改动借重锚混检被拦、伪造兄弟(篡改 runId 落盘)蹭重锚被 paramsHash 层物理拒。附带发现:审批仓 transaction 每次从盘刷新,纯内存篡改会被自动中和(信任方向正确)。
**S6 冒烟 19/24——抓到一个真实链路才摸得到的产品缺陷(FB-03-BUG-1,判 NO-GO 的唯一原因)**:段 C 补录写在真实断连下 100% 失败回滚——`mes.apply_report` 本地落账前无条件 `client.post_report()` 同步推 MES,断连注入(设计 §0.8 官方手法)下 MesHttpError 上抛 → execute_plan 整体回滚。golden 层 MockMesClient post_report 永远成功 + probe 走 monkeypatch seam,结构性摸不到。真实失败文案实测:「兜底执行失败(MesHttpError: [MES_HTTP_TIMEOUT] POST /work-orders/EXT-1001/reports (HTTP 504)),已自动回滚……你的数据未留下任何变更」。治理面在失败前全部正常(显式失败+回滚+失败现场建档+审计齐全)。其余全绿:断连注入 CONNECT_FAILED、真实 Pi 产 S6 两步计划(woId/进度与 CSV 一致)、逐笔双卡、恢复后假 MES(冒烟内嵌 HTTP 服务)对账 MATCH 1/DRIFT 1、manifest sha256 应验、ALGO_RUN 含 manifestSha256、对账纯读指纹相等、删白名单对照组零卡零变更、probe 仍 failed 如实回复「尚未恢复」(H-17 真实复证)。
**S7 冒烟 12/12 全过**:ops 身份四文件注入 + 预埋双形态敏感串脱敏实测(`***REDACTED***`、零泄漏)+ P1 草稿 + 世界零变更 + calls.jsonl 围墙内读取;非 ops(desktop planner)对照**物理不可见**实测(零 run、原话术);验收点 D(双人链)由 H-20 确定性全覆盖已登记。
**给修复轮的话**:FB-03-BUG-1 是设计层语义决策(补录 = 本地落账 + 待同步标记恢复后闭环,还是同步推送容忍失败),非一行笔误,我按约束未动产品代码;修复后 `smoke_s6_reconcile.py` 五阶段全自动可复跑(outage 阶段 D3–D6/G1 转绿即解除 NO-GO)。环境层坑两个已在脚本内修复并登记:本机系统代理劫持 httpx 本地请求(NO_PROXY 修正)、Windows MAX_PATH 致 rmtree 失败(robocopy purge 兜底)。未 git commit,等统一授权。
[Agent-O 修复收口] 2026-09-04 — FB-03-BUG-1 已修复并复证,交接 `docs/CHANGELOG.md` 顶部条目 +
`tests/golden/test_fallback_offline_booking.py`(6 passed)+ `smoke_s6_reconcile.py` 复跑结果。
语义:S6 补录步 params 显式声明 `offlineBooking: true`,出卡闸与执行端双端实时探测断连事实,
双成立才走 `apply_report(offline_booking=True)` 本地落账并打 `syncStatus=PENDING_SYNC`;
在线路径默认参数不变;PENDING_SYNC 自动补推仍为后续轮次。确定性联合 78 passed、文档门禁
25 passed、ruff 零新增;真实 S6 冒烟复跑 24/24,段 C D3–D6/G1 全绿。**P3 判定转 GO**;
Agent-N 的 NO-GO 留言保留为修复前时序记录。P3/P4 代码均未提交,等统一授权。