多 Agent 体系 · 待处置清单 v1
来源：《多 Agent 体系可行性验证报告（整合版）》（元宝沙盒，2026-09-18 晚）
基线：手册 v0.2.1 ／ 流程文档 v2.4.3（已归档）→ v2.4.4（当前锁定候选）
说明：本清单不含《Sol 复核处置分诊表》内容（该文档尚未获取）。
本清单只列"还没改的"，已改的三处见文末。

==================================================
一、A 类：阻断项（不修不能启动）
==================================================

A7 高危域清单不一致【安全相关，最高优先级】
  位置：手册 3.1.2 列 10 项 / 6.2 rules.json high_risk_domains 只列 5 项
  漏掉：密钥管理、审计日志、回滚脚本、隐私数据处理、安全中间件
  危害：插件按 rules.json 判高危域 → 这 5 类不被识别 → 可默认落妥协模式
        且绕过 fail-closed（规则文件存在、解析成功，只是清单不全 → 静默 approve）
  建议：以 3.1.2 的 10 项为权威源对齐 rules.json；6.8.2 回归断言新增
        "3.1.2 全量 10 项命中时均判高危"

A8 max_workers 权威值不统一【部分已修】
  位置：手册 0.3 写"硬上限 ≤2"；流程文档三处按 3 设计
        （L144 起步期 max_workers=3、L453 开放问题 4、L466 修订记录 ⑨）
  本机已修：手册 6.2 rules.json 示例 "max_workers": 3 → 2
  待处置：① 流程文档全文按 2 重排示例与开放问题（或反过来确认 3 可用并改 0.3）
          ② 明确 max_workers 上限的"唯一权威位置"
  后果：附录 B 批 2 三路并行在目标环境不成立；开放问题 4 要标定的配置不可用

A1 重活去向需分档
  位置：手册 0.3 / 流程文档附录 B / 12.1
  现状：2.1.4 已把"串行队列"与 CI 并列为合规路径（非死锁），但
        附录 B 主示例（80+ 文件迁移、Phase 6 全量 199 测试）在 600MB 下大概率 OOM
        → 12.1 标定要用的正是这类任务 = 标定样例本身不可执行
  建议：低资源档定义测试分档（只跑变更影响子集）；附录 B 增补"轻量档演算变体"

A2 状态机枚举缺项
  缺：running、needs_recovery、paused
  另有：escape_bypass 零入边零出边；escape_compromise / escape_advisor 只有入边
  后果：1.0 强制要求 6（子代理丢失置 paused/needs_recovery/blocked）写不进状态机
  建议：补齐枚举与出入边，迁移表同步

A3 Checkpoint 键名与状态落点未对齐
  键名：6.1 写 checkpoint_timeout_actions，6.2 实际是 timeout_high_risk_action
  落点：枚举里没有 checkpoint_timeout / hold 状态，超时后写不进状态机

A4 版本绑定【值已修，机制待改】
  本机已修：手册 1.5.1 engineering_manual_version → v0.2.1；头部声明与当前锁定版一致
  待处置：按报告建议改为"运行时从 rule_versions 表读取"，文档只写字段名与取值来源

A5 指纹标定冷启动不可达 + 数字冲突
  冲突：手册 2.7.1（历史真实失败 50%）/2.7.2（每故障类别 ≥20）vs 流程 12.1（30 样本、每类 10）
  问题：冷启动时"历史真实失败"= 0；样本不足会系统性偏向 L2 逃生舱 → 提前堆技术债
  建议：把阶梯已有的冷启动模式（首次计入仅登记不判级）复用到 12.1

A6 全量类型检查与 Stress test 未纳入重活
  问题：0.3 重活清单只有"编译"、无"类型检查"；且措辞是"不得本地并行"，未禁止本地执行
        12.3 Stress test 是故意的资源炸弹，可能打挂编排器自身
  建议：把全量 tsc/lint 列入重活、轻量档改增量；Stress test 放进带内存上限的独立 cgroup

==================================================
二、B 类：定义缺口（不阻断启动，但会导致不可测试或运行时冲突）
==================================================

B1  SQLite 并发配置缺失：默认 journal_mode=DELETE + busy_timeout=0 → 并发写立即 SQLITE_BUSY
    建议写死：WAL、busy_timeout≥5000ms、短事务
B2  reviewer 是否占 max_workers 配额未定义（上限 2 而 builder+双 reviewer = 3，直接超限）
B3  浏览器实例与双 Reviewer 冲突（只允许单实例 headless，双 Reviewer 要独立取证 → UI 验收互斥）
B4  environment_image 在无容器档无意义（轻量档应可空，降级为独立目录+端口+env 文件）
B5  deployer 类型在目标环境无实现路径（0.3 禁容器构建 → 派发即失败，应在类型注册表标注禁用）
B6  test-runner 例外计费无上限口径（无公式，未说明记 Phase 池还是全局池）
B7  幂等键中 attempt 无定义（未定义递增主体与重置条件 → 重放保护失效）
B8  "长期 100% 一致必须抽检"无阈值（多少轮算长期、抽检比例都没写）
B9  锁等待 300s 降级串行在当前环境无效果（上限 2 本来就是串行）
B10 灰轨"旧实现 100% 绿"前提不可达（依赖完整测试套件；旧实现带 flaky 则永不满足）
B11 code-reviewer / debugger 返回 schema 未定义（附录 A 六类 schema 未说明复用 reviewer）
B12 开放问题未标注环境适用性（开放问题 4/5/7 与目标环境冲突，未注明需重设）

小不一致（建议顺手修）：
  · 4.5.2 记账事件用 timestamp，附录 C 表用 created_at
  · 4.6.1 manifest 只有 2 个版本字段，1.5.1 要求绑定 6 个
  · 附录 D approve 分支缺 rule_id（另两个分支都有）

==================================================
三、本次已修（手册 v0.2 → v0.2.1）
==================================================
1. 1.0 的 OOMPolicy 归因修正：不是"249 不支持"，而是 OOMPolicy 属 service unit 属性、
   写在 scope 上才报错（本机实测双向验证）；并补回 OOM 自保（OOMPolicy=stop / OOMScoreAdjust=-500）
2. 6.2 rules.json 示例 "max_workers": 3 → 2（与 0.3 硬上限一致）
3. 1.5.1 版本字段对齐（engineering_manual_version v0.1 → v0.2.1），头部版本声明同步
   附注：手册头部"配套流程文档 v2.4.4"保持不变——流程文档已锁到 v2.4.4

==================================================
四、事实核查（外部技术判断）
==================================================
· OOMPolicy：报告结论正确（service 支持 / scope 不支持），本机 systemd 249 实测已确认
· SQLite：WAL 只做到读写不互阻，任何时刻仍只有一个写者；
  busy_timeout=0 意味着拿锁失败立即返回 SQLITE_BUSY；生产建议 5–10s + 短事务
· 本报告未发现"两处需修正"之外的其他外部技术判断错误