[红队测试] 治理体系流程演练问题报告 - 多代理模拟发现33个治理缺陷

[randypanding]

红队测试报告：治理体系流程演练问题清单

测试方法: 多代理红队演练（6 个流程断点场景 + 7 个角色触发/认领场景 + 8 个反馈死循环/极端场景 + 10 个跨系统一致性维度）
数据源: 全量扫描 .github、agent-registry、template-service、Cl-Workflows 四仓治理声明
分析日期: 2026-08-19
问题分类: 仅陈述客观问题，不提供解决方案

---

P0 级问题（系统级阻断）

P0-1: Owner 不可用时同步阻塞点无降级路径

位置: standards/attention-ledger.yaml + standards/flows.yaml#intent_ratification
问题: intent_ratification 和 sev1_forward_fix_authorization 是仅有的两个 synchronous 阻塞点，且无默认动作。当 owner 长时间不可用时：

• 波次卡在 plan 相位无法推进（无验收示例批准，cards.ratified 永远不触发）
• 事故无法前进修复（sev1 需 owner 在场）
• 整个交付系统停摆，无任何自动降级或超时转移机制
• 与设计原则"无默认动作的人在环点禁止存在"（team-collaboration.yaml PART 4）形成规范矛盾

P0-2: Incident Cell 销毁条件 followup_cards_created 无豁免路径

位置: registry/teams/incident-cell.yaml lifecycle.destroy_condition + team-collaboration.yaml#teams.incident_cell.exit_criteria
问题: exit_criteria 硬性要求 followup_cards_created。若 responder 因任何原因无法创建 follow-up cards（如 backlog 已满、curator 不可用、路由失败），incident cell 将永久存活，TTL 延长也无法解除，消耗预算与资源。当前规范未定义此条件不满足时的降级路径。

P0-3: Trivial 路径可被利用绕过 Owner 审批

位置: standards/intent-routing.yaml#intents.fix + standards/change-classes.yaml#classes.trivial.promote_if
问题: Trivial/fix 变更的 promote_if 规则仅基于文件路径判断是否升级。存在语义复杂度无法通过路径检测的情况：

• 关键业务逻辑变更可能落在非 dep/schema/tests/acceptance/ 路径
• 跨模块隐式依赖未在路径中体现
• diff 面积 检测可被拆解为多次小 diff 绕过
• 用户/调用方可构造"trivial"意图绕过 owner 审批覆盖

P0-4: Responder 缺少 datastore_write 权限，事故 follow-up 断裂

位置: registry/agents/responder.yaml capabilities.allow + registry/teams/incident-cell.yaml handoff.team_side
问题: Responder 的 allow 列表为 [fs_read, vcs_read, deploy_reverse, feature_flag, failover, scale, data_freeze, ci_trigger, datastore_read]，无 datastore_write。但 incident handoff 要求 responder 执行 incident_report 和 memory-export（需写入数据层）。这导致 responder 无法独立完成 handoff 环节，事故处置链断裂。

P0-5: Curator 单点故障导致维护回路断裂

位置: registry/teams/stewardship.yaml + standards/flows.yaml#maintain_loop
问题: Curator 是 backlog 归并、维护回路、归档审核的单点执行者。若 curator 不可用：

• drift 报告无人消费
• backlog 提案无人归并
• 归档资产无人审核
• 全治理回路冻结，无降级或备份路径

---

P1 级问题（严重降级但可恢复）

P1-1: Judge 激活计数器依赖链断裂风险

位置: standards/team-collaboration.yaml#services.judge.activation_counter
问题: Judge 激活依赖 metrics-aggregator 计数 verdict_stalemate 事件（需累计 ≥2）。但：

• 计数器持久化机制未定义（重启/重建后是否归零？）
• 计数值准确性依赖 scheduler 的正确触发
• 无计数器的校验或补偿机制
• 计数器永远不触发时，所有争议直达 owner，造成过载

P1-2: Red Cell 激活条件依赖未定义事件

位置: standards/team-collaboration.yaml#services.red_cell.invoke_on + PART 5 activation.on_trigger
问题: Red Cell 激活条件 首次上线后 OR 首个 sev1 后 缺乏精确定义：

• "首次上线" 的触发事件未声明（无对应 event_producer）
• 无 fallback 机制确保 control tests 最终被执行
• 若激活条件永远不满足，adversary 永远不会运行，控制测试成空文

P1-3: Backlog 消费路径不充分

位置: standards/flows.yaml#maintain_loop.issue_lifecycle + interfaces.backlog.producer_gate
问题: issue_lifecycle 强制"三选一"（消费/驳回/延期），但：

• 若无新波次消费 backlog，延期条目可能到期后无人处理
• deferred 到期后的自动重排机制由 curator 执行，curator 不可用时失效
• 30d aging 后的 maintenance wave 同样依赖 curator 提请，形成依赖环

P1-4: Amendment 死亡循环无强制退出阈值

位置: standards/team-collaboration.yaml#artifacts.card.amendment
问题: Normative amendment 的 escalate_when 规则为：单卡 ≥2 次 → 冻结新开卡+escalate owner。但若 owner 反复批准（或反复超时），同一卡可无限次走 amendment→backlog→重新规划 循环。无"整条波次终止"的硬性阈值。

P1-5: Escape Review 无法检测重复逃逸

位置: standards/flows.yaml#escape_review
问题: escape review 流程 归因→backlog 提案→下一 wave fix 缺少同一缺陷的复发检测机制。相同根因的 escape 可能反复发生而未被识别为系统性问题。

P1-6: Verification 循环无强制终止阈值

位置: standards/team-collaboration.yaml#flow.phases.graph verify↔build 回边
问题: verify↔build 回边可无限次循环（review.changes_requested → build → verify）。未定义最大重试次数或"争议不可解"的强制升级触发条件（如 verification 循环 > N 次自动 escalation）。

P1-7: Budget Death Spiral

位置: standards/team-collaboration.yaml#budget.layers
问题: 预算耗尽后回退到 planner 重规划，但：

• overhead_pool 耗尽时，升级/仲裁本身的成本来源不明确
• budget.invariants 声明"升级永不受预算约束"，但未指定资金从哪来
• 实际运行中可能出现"没钱升级 → 没钱修复 → 团队永久冻结"的死锁

P1-8: Adversary 有效性不可独立验证

位置: standards/team-collaboration.yaml#services.red_cell.audit_of_auditor
问题: 连续3次调用零有效findings → 暂停 的信号无法独立验证：

• Adversary 可能生成"有效"但无实际价值的 findings 规避暂停
• forced_ranking_top: 5 的质量评估依赖主观判断
• 控制测试结果的正确性缺少独立复核

P1-9: Researcher 内容注入风险

位置: standards/archetype-profiles.yaml#trust_zones + researcher profile
问题: Researcher 是唯一可触外部文本（net_read）的节点。虽然规范要求"外部结论不得作规范性依据"，但：

• 通过 agent_as_tool 返回的 findings 可能被 planner/builder 引用为"背景信息"
• source_class 标记可被绕过
• 无运行时强制检查消费方是否正确隔离了外部来源

P1-10: Cross-Squad 路径冲突检测依赖声明完整性

位置: standards/team-collaboration.yaml#teams.delivery_squad.cross_squad
问题: Cross-squad 要求 owned_paths 不相交，但：

• 路径声明是静态的，动态创建的文件可能落入他人路径
• 冲突检测仅在组队时执行，运行时无持续监控
• 共享依赖（库、服务）不在路径冲突检测范围内

P1-11: Channel ACL 交叉校验缺失

位置: standards/team-collaboration.yaml#channels.pub_sub.acl
问题: Channel ACL 声明了读写权限，但 validate.py 未执行 ACL 交叉校验：

• 未检查所有 agent 是否有合理的 read/write 权限组合
• backlog.proposals.* 声明多写者（curator/responder/owner/planner）但未验证冲突解决机制
• decisions.* 仅 judge 和 owner 可写，但 judge 实例为 per_dispute 一次性——写入后无法追加

P1-12: Schema 引用完整性未在 validate.py 中全量覆盖

位置: registry/agents/*.yaml io_contract → registry/schemas/*.json
问题: validate.py 检查 schema 文件存在性，但未全量校验：

• schema 文件内容是否与 io_contract 约束匹配
• schema sources 非空等运行时规则是否在 schema 文件中实际定义
• schema 间引用的完整性

---

P2 级问题（轻度摩擦）

P2-1: Memory 生命周期与 Amendment 时序冲突

位置: standards/context-assembly.yaml#memory.per_archetype + amendment lifecycle
问题: Builder 记忆 30d、Planner 记忆 90d。若 amendment 在 memory 过期后到达，历史上下文可能不可用，导致重复判断。

P2-2: Model Family 零配额无降级策略定义

位置: registry/models.yaml + team-collaboration.yaml#activation degraded_mode
问题: degraded_mode 定义为"可用族数 < 激活中的独立性需求"，但未定义：

• 降级后具体如何执行
• 哪些原型的独立性要求可以临时放宽
• 降级时长与恢复条件

P2-3: Amendment 分类无申诉路径

位置: standards/team-collaboration.yaml#artifacts.card.amendment.classify
问题: card_gate 自动分类 amendment 类型（non_normative/test_fix/normative）。若分类错误，无明确的申诉路径。builder/test_author 需通过 normative amendment 间接纠正，增加流程摩擦。

P2-4: Contract 执行缺少并发保护

位置: standards/team-collaboration.yaml#teams.delivery_squad.wave_consistency
问题: contracts/<wave_id>.yaml 由 planner 写、builder 改需 normative amendment。但未定义：

• 当 builder 提交 amendment 期间，planner 重新规划产生新 contract 的冲突解决
• 多 builder 同时修改不同 contract 文件的并发控制

P2-5: Maintenance Wave 触发频率无上限

位置: standards/flows.yaml#maintain_loop.maintenance_wave
问题: Maintenance wave 触发条件为 security 级条目 OR aging > 30d。若 backlog 持续有 security 条目，可能频繁触发维护波次，与交付波次竞争资源。无频率上限或资源隔离机制。

P2-6: Ratio Metrics 低样本静默

位置: standards/team-collaboration.yaml#metrics.ratio_metrics
问题: validity.min_sample: 10 以下的比率指标只累积不触发动作。低流量的一人公司场景下，关键指标（如 escape_rate、amendment_rate）可能长期处于"静默"状态，无法及时暴露问题。

P2-7: Backlog Item Aging 无明确 SLA 定义

位置: standards/flows.yaml#maintain_loop.issue_lifecycle
问题: 虽然定义了 aging p50/p95 指标和 30d 触发条件，但未定义：

• 单个 backlog item 的最大等待时间
• 超过等待时间后的强制处置路径
• SLA 违约的升级机制

P2-8: Intent 分类歧义的确认成本无预算

位置: standards/intent-routing.yaml#routing.ambiguity_rule
问题: 歧义路由规则为"宁可多问一次，不可猜错分类"，但未将此交互预算分配到 attention-ledger 或任何预算池。频繁歧义可能造成 owner 注意力预算隐性溢出。

P2-9: precedent-non-normative Check 依赖 Case Law 激活

位置: standards/checks.yaml#precedent-non-normative (status: planned)
问题: 该 check 状态为 planned，依赖 case_law 激活（judge 争议累计 ≥5）。在 case_law 激活前，判例规范性检查不存在，存在判例被误用为规范的风险。

P2-10: Judge verdict_stalemate 事件定义不完整

位置: standards/team-collaboration.yaml#flow.event_producers
问题: verdict_stalemate 由 mechanism:scheduler 产生，判据为"同一 PR 的 gate 与 review 结论相反且双方主张已结构化提交"。但"结构化提交"的具体格式和校验规则未在 schema 或标准中定义。

P2-11: Multiple Concurrent Incidents 的资源竞争

位置: registry/teams/incident-cell.yaml
问题: Incident cell 为 ephemeral（每事故一实例）。多事故同时发生时：

• Responder 可能被多实例争用（responder count: 1）
• overhead_pool 共享预算可能被耗尽
• 无事故优先级判定机制（sev 分级已做，但实例间无抢占/排队）

P2-12: Drift Check 执行频率与维护回路的联动缺失

位置: standards/team-collaboration.yaml#services.drift_check + flows.yaml#maintain_loop
问题: drift_check 产出报告 → 周审 → backlog。但：

• drift_check 的执行频率（daily）与 backlog 的消费节奏（波次级）不匹配
• 未定义 drift 报告的优先级排序规则
• 多个 drift 问题可能积压在 backlog 中无法快速处置

---

跨切系统性问题

SC-1: 验证层（validate.py）校验盲区

validate.py 当前校验：

• ✅ 工具副作用 ⊆ 词表
• ✅ Agent 工具副作用 ⊆ allow
• ✅ 原型-实例 profile 一致性
• ✅ CT 覆盖率
• ✅ 意图路由/变更类引用完整性
• ✅ check:* 悬空防线
• ❌ Channel ACL 交叉校验（缺失）
• ❌ Schema 内容与 io_contract 匹配（缺失）
• ❌ 事件生产者-消费者完整性（仅部分）
• ❌ 模型 family 配额充足性（缺失）
• ❌ 记忆生命周期与时序冲突（缺失）

SC-2: 降级模式声明与实际实现脱节

activation.on_trigger 声明了 degraded_mode、judge_service、case_law、holdout_suite 等按需激活机制，但：

• 降级模式的具体行为未在任何标准中定义
• 触发后的恢复条件未声明
• 降级状态对已有流程的影响未评估

SC-3: 注意力账本守恒的执行盲区

attention-ledger.yaml 声明"新增 owner-blocking 点必须同时移除一个"，但：

• 未校验现有 blocking point 是否仍然必要
• asynchronous 条目的 default 执行结果是否被追踪
• sampled 抽检的覆盖率和执行频率未在 validate.py 中校验

SC-4: 预算不变式的实际资金来源不透明

Budget invariants 声明"升级/仲裁永不冻结"，但：

• overhead_pool 资金来源为 env:TEAM_OVERHEAD_USD（环境变量）
• 未验证 overhead_pool 是否充足覆盖升级需求
• 升级通道的实际成本未被追踪或限制

---

测试场景覆盖度分析

当前 scenarios.yaml 包含 20 个场景（19 regression + 1 control），覆盖率评估：

• ✅ 主流程 happy path
• ✅ Amendment timeout
• ✅ Incident unsafe rollback
• ✅ Escalation budget
• ✅ Judge activation
• ✅ Incident instantiation
• ✅ Backlog loop
• ✅ Gaming detection
• ✅ Test fix path
• ✅ Event completeness
• ✅ Trust chain
• ✅ Cross lifecycle
• ✅ Trivial fastpath
• ✅ Maintain loop
• ✅ Maintenance wave
• ✅ Owner control
• ✅ Unratified intent blocked
• ✅ Spawn manifest
• ✅ Memory distill before destroy
• ✅ Supply inventory

未覆盖的场景（本次红队发现）:

• ❌ Owner 长时间不可用（同步阻塞点失效）
• ❌ Planner 永久卡住（意图产出超时）
• ❌ Backlog 永久积压（无消费路径）
• ❌ Amendment 无限循环（同一卡反复修改）
• ❌ Verification 无限循环（verify↔build 回边无阈值）
• ❌ Multiple concurrent incidents
• ❌ Curator 不可用导致治理冻结
• ❌ Trivial 路径语义绕过
• ❌ Judge activation counter race condition
• ❌ Red cell 永久不激活
• ❌ Budget death spiral (overhead_pool exhausted)
• ❌ Responder 无法完成 handoff

---

问题总结统计

严重等级	数量	典型特征
P0	5	系统级阻断、永久冻结、安全失效
P1	12	严重降级但可恢复、维护依赖断裂
P2	12	轻度摩擦、语义粒度不足、验证缺失
SC	4	跨切系统性问题
总计	33

---

本报告仅陈述客观发现，不提供解决方案。所有问题编号为本次分析临时编号，待治理团队认领后重编。

[randypanding]

定性：真实——P0 全部处置；其"未覆盖场景清单"直接转化为本批回归防线

P0 处置：

• P0-1 两个 synchronous 项无默认动作 → ADR-0021 决策3（4 类默认动作，全部更可逆一侧，绝不默认放行）
• P0-2 incident cell followup_cards_created 无豁免 → 决策3 parked 出口（TTL+72h owner 不可达→保守稳态交接 maintenance wave）
• P0-3 trivial 路径语义绕过 → 已知边界：promote_if 路径判定是声明层可机器判定的最大诚实面，语义复杂度检测无可靠执行者（强推=伪自动）；防线=owner review + drift-check §10 后验
• P0-4 responder 无 datastore_write 致 handoff 断裂 → handoff 承接与 memory-export 执行者修正（决策1），事故报告制品路径对齐
• P0-5 curator 单点 → 一人公司结构边界（显式不修）；其义务的 manual_only 属性已入 attention-ledger 登记

场景清单转化：报告末尾 12 个未覆盖场景中 4 个核心死锁（owner 长期不可用/planner 永久卡住/无发布面滞留/重试耗尽）已成为 S21-S24 正式场景入 CI required 门禁（#29 决策8），负向注入由 5 个 pytest 元测试承担；治理测试回路（#30）承担周期回归。

P1/P2 运行时项（judge 持久化、预算死亡螺旋动态、并发保护）按 ADR-0010 二期路线。