Skip to content

[红队演练报告] 治理体系流程断点与健壮性问题清单 #70

Closed
Closed
[红队演练报告] 治理体系流程断点与健壮性问题清单#70
Labels
governance治理体系相关processred-team红队演练发现

Description

@randypanding
randypanding
opened on Aug 19, 2026

执行摘要

对 Cloudbird-Software 三仓治理体系（.github / agent-registry / template-service）进行了三轮红队流程演练，覆盖 20+ 核心治理文件、9 个 LLM 原型、6 个机制原型、3 个团队原型、8 类意图、7 类变更分级、12 项防线、25+ 控制测试。

总计发现 56 个问题点：P0×8, P1×25, P2×23，以及 7 个系统性模式。

P0 级问题（系统不可运作或安全防线失效）

P0-1: owner 单点阻塞——无降级路径

  • 位置: intent-routing.yaml#intents.deliver / flows.yaml#intent_ratification / attention-ledger.yaml
  • 问题: owner 是 deliver 意图的唯一验收批准人（intent.ratification 必须由 owner 签名）。当 owner 缺席时，所有 deliver 卡无法通过 card_gate，整个交付流水线完全阻塞。系统未声明 owner 缺席时的任何降级路径。
  • 影响: 所有正在进行的交付波次永久挂起，预算持续消耗直至耗尽，无恢复机制。

P0-2: overhead_pool 耗尽时升级通道死锁

  • 位置: team-collaboration.yaml#budget.invariants / team-collaboration.yaml#paradigms.handoff.escalation
  • 问题: escalation（含 judge 激活、跨队协调）的预算来源是发起方 overhead_pool。当 overhead_pool 耗尽时，升级通道理论上"永不冻结"（budget.invariants），但实际无资金执行升级动作。声明与执行之间存在矛盾。
  • 影响: builder/test-author 僵持无法升级、judge 无法激活、跨队请求无法发出——系统进入永久僵局。

P0-3: test-tree-freeze 缺乏运行时强制

  • 位置: checks.yaml#test-tree-freeze / archetype-profiles.yaml#test-author.duty_assurance.claims
  • 问题: test-author 冻结测试树（test_tree_sha）后，builder 在 verify 阶段仍可修改 tests/acceptance/**。当前只有 token-path-scope 声明层约束，check:pr-identity-path-matrix 状态为 planned（未激活）。verifier 对冻结树判卷的前置条件在运行时无法被强制。
  • 影响: builder 可在判卷前篡改测试，使验收失效。builder 可能无意中（重构/格式化）或有意修改测试树。

P0-4: adversary 告警无直接通知路径

  • 位置: archetype-profiles.yaml#adversary / control-tests.yaml / team-collaboration.yaml#services.red_cell
  • 问题: adversary 的 findings 只写入数据层 findings/，不直接开 PR 或改事件。findings 经 curator 审核后才能入库。当 adversary 发现 P0 级控制测试失败（如 builder 成功写入 tests/acceptance/），关键安全告警可能因 curator 未及时审核而延迟数天甚至数周。
  • 影响: 严重安全漏洞可能长时间不被发现。CT 失败（on_success=P0 冻结）的响应机制依赖 curator 的审核节奏。

P0-5: judge 激活计数器依赖 metrics-aggregator 实时精度

  • 位置: team-collaboration.yaml#services.judge.activation_counter / archetype-profiles.yaml#services.judge
  • 问题: judge 激活条件为"僵持累计 >= 2"，由 metrics-aggregator 计数 verdict_stalemate 事件。若 metrics-aggregator 数据延迟或计数错误，judge 可能过早或过晚激活。同时，激活本身的执行者（谁实例化 judge）未在声明中明确——是 scheduler 还是 interface-gateway？
  • 影响: 争议解决机制的核心触发条件不可靠，可能导致该仲裁时无仲裁，不该仲裁时浪费资源。

P0-6: 令牌泄露后的无自我熔断

  • 位置: archetype-profiles.yaml / agent.schema.yaml#credential
  • 问题: agent 凭据（cloudbrid-agent App token）泄露后，攻击者可以：(1) 以 builder 身份写 tests/acceptance/** (2) 以 planner 身份开未批准的卡 (3) 以 deployer 身份触发前进变更。系统未声明凭据泄露的检测与自动熔断机制。drift-check 只能检测非 PR 直推，无法检测令牌滥用。
  • 影响: 完整的治理防线可被绕过，攻击者能获得代码写入、未批准卡创建、生产部署等权限。

P0-7: escape_review 归因死循环——原队已销毁

  • 位置: flows.yaml#escape_review / team-collaboration.yaml#teams.delivery_squad.lifecycle
  • 问题: escape_review 需要对"通过全部 gate 的缺陷"做四选一归因（spec_gap/test_gap/impl_gap/env_gap）。但 ephemeral 团队在交付完成后即销毁，builder/test_author/planner 均已释放。当 escape 被发现时（可能在发布数天后），原实施者已不可用，归因只能由 curator/owner 完成，缺乏实施细节的第一手信息。
  • 影响: 归因质量下降，root cause analysis 不准确，同类缺陷可能重复出现。

P0-8: 同步 owner 决策拥塞——注意力账本无限流

  • 位置: attention-ledger.yaml / flows.yaml#intent_ratification
  • 问题: attention-ledger 声明 max_synchronous_per_week=2（不可委派的同步决策）。当多个 deliver 意图同时到达或维护波次集中到期，owner 需要同时批准多个验收示例（每项 5-15 条×30 秒）。账本未声明多意图同时到达时的排队或降级机制。
  • 影响: owner 成为系统瓶颈，决策延迟导致交付周期拉长，预算被等待消耗。

P1 级问题（显著退化或安全防线显著削弱）

P1-1: release_bot stall_escalation 目标未声明

  • 位置: archetype-profiles.yaml#release-bot / team-collaboration.yaml#services.release_bot
  • 问题: release_bot 流水线停滞超时后需 escalation，但 escalation 的具体目标（通知谁、升级到哪里、默认动作是什么）未在声明中明确。stewardship 还是 owner？是告警还是阻塞？
  • 影响: 发布流水线卡住时无明确的通知与恢复路径。

P1-2: respond 意图 sev1 前进修复路径不明确

  • 位置: intent-routing.yaml#intents.respond / change-classes.yaml#classes.prod / incident-cell.yaml
  • 问题: sev1 响应中涉及前进修复（deploy forward），但 incident_cell 的 deployer 角色声明为"仅 incident_cell 场景：sev1 且回滚不可行的前进修复"。"回滚不可行"的判定标准未声明。deployer 需要逐动作人签（RL-1），但响应类动作通常要求快速，人签会显著延长 MTTR。
  • 影响: 严重事故恢复时间被人为拉长；在需要秒级响应的场景中无法满足。

P1-3: per-card 预算与团队 envelope 预算的交叉依赖

  • 位置: flows.yaml#budget / team-collaboration.yaml#budget / dev-wave.yaml#budget
  • 问题: per-card retries 上限（默认 1，high 可至 2）在机制声明中，但实际 retries 消耗的是团队 envelope 预算。当团队预算耗尽时，即使单卡预算未用完，重试也会失败。
  • 影响: 单卡预算与团队预算的隔离声明在执行中不成立。

P1-4: 并发 incident-cell 实例的 resource 争用

  • 位置: team-collaboration.yaml#teams.incident_cell / incident-cell.yaml
  • 问题: incident-cell 是单 seat（responder count=1, deployer count=1）。多个同时发生的事故需要排队处理，TTL 72h 从先到先得。但没有声明：(1) 事故优先级排序机制 (2) 同时实例化的最大数量 (3) 多 incident-cell 间的协调（如共享部署状态）。
  • 影响: 多个事故同时发生时处理能力受限，可能导致次生事故。

P1-5: judge degraded_mode 行为未声明

  • 位置: models.yaml / archetype-profiles.yaml#judge
  • 问题: models.yaml 声明 judge-deep（sovereign-family）不可用时"degraded_mode 触发"，但 degraded_mode 下的行为（谁替代 judge、判卷标准如何调整、是否继续接受争议）未在任何文档中声明。
  • 影响: 关键仲裁角色不可用时系统无明确降级方案。

P1-6: trivial→logic 升级后的 partial completion 状态

  • 位置: change-classes.yaml#classes.trivial.promote_if / intent-routing.yaml#intents.fix.note
  • 问题: trivial 卡执行中被发现应升级为 logic（如触及 tests/acceptance/**）。此时可能已经完成部分工作（代码已写、部分测试已通过）。升级后的处理流程（回滚已做的工作？保留已完成部分？）未声明。
  • 影响: 已完成工作的处理成为灰色地带，可能导致重复劳动或不一致状态。

P1-7: supply-audit 未激活——供应链防线存在漏洞

  • 位置: checks.yaml#supply-audit (status: planned) / registry/projects.yaml
  • 问题: supply-audit 检查处于 planned 状态（未激活）。这意味着新引入的依赖是否在 projects.yaml 登记、是否通过许可证审计、是否 pin 版本等要求目前无 CI 强制。
  • 影响: 供应链风险无法被自动检测。"治理体系自食其粮"的审计原则在当前无法满足。

P1-8: planner 写路径权限与实际任务需求可能不匹配

  • 位置: archetype-profiles.yaml#planner.capabilities / wave-planner.yaml
  • 问题: planner 权限限制为 plans/|cards/|specs/|contracts/，但 planner 需要引用 knowledge_candidates（ADR/skill 检索候选）。这些候选在 knowledge_retrieval 机制中生成，planner 是否需要 datastore_read 来检索候选存在歧义。wave-planner.yaml 的 allow 包含 datastore_read，但 archetype-profiles.yaml 的 capabilities 未明确包含。
  • 影响: planner 可能在实际工作中因权限不足无法读取必要的知识候选。

P1-9: verifier 与 integrator 之间的原子性保证缺失

  • 位置: archetype-profiles.yaml#verifier / archetype-profiles.yaml#integrator / checks.yaml#gate
  • 问题: verifier 运行冻结测试树并产 verdict，integrator 检查 gate.pass AND review.approve 后自动合并。两个步骤之间不是原子的：(1) verifier 通过后有人手动绕过 gate 直接推 main (2) verifier 通过后、integrator 合并前，测试树被篡改。
  • 影响: 合并流程的原子性依赖 GitHub ruleset 强制，但 ruleset 本身的有效性通过 drift-check 每日检测，存在时间窗口。

P1-10: researcher 的 untrusted_ingest 信任边界执行不明确

  • 位置: archetype-profiles.yaml#researcher.trust_zone / researcher-code.yaml / CT-RES-001~003
  • 问题: researcher 是唯一 untrusted_ingest 节点（可触外部文本），其输出必须 schema+provenance（findings.json 含 sources+source_class）。但 researcher 输出的 schema 校验在 agent 侧还是在 CI 侧执行未明确。若在 agent 侧执行，存在自校验风险。
  • 影响: 不可信输入的输出可能绕过校验，污染决策依据。

P1-11: backlog producer_gate 的强制执行未声明

  • 位置: team-collaboration.yaml#interfaces.backlog.producer_gate / flows.yaml#maintain_loop.issue_lifecycle
  • 问题: maintain_loop 声明"issue 不可能躺在列表里"——必须三选一（consumed/rejected/deferred）。但 producer_gate 强制处置的执行者（谁检查、何时检查、不处置的后果）未明确声明。当前只有抽象的"curator 周审转 backlog.proposals → planner 组波次必处置"。
  • 影响: backlog 可能在实际上"躺在列表里"，违反声明。

P1-12: 事件流哈希链验证的运行时实现缺失

  • 位置: flows.yaml#event_integrity / observability.yaml
  • 问题: event_integrity 声明"存储 append-only（对象锁）+ 哈希链（prev_hash）"，但运行时如何验证哈希链完整性（何时验证、谁验证、验证失败的处置）未声明。
  • 影响: 如果事件流被篡改或损坏，无检测与恢复机制。

P1-13: memory_digest schema 与内容的完整性检查缺失

  • 位置: context-assembly.yaml#memory.digest / team-collaboration.yaml#artifacts.memory_digest
  • 问题: memory_digest 有 schema（schemas/memory-digest.json），但导出后的完整性检查（谁检查、检查什么、不完整的后果）未声明。handoff 相位在场座位导出，但导出质量如何保证未知。
  • 影响: 蒸馏素材可能不完整，影响后续 ADR 质量。

P1-14: ADR 写作的质量与时效性无强制

  • 位置: team-collaboration.yaml#stewardship_side.adr-write / stewardship.yaml
  • 问题: curator 负责将关键决策提炼为 ADR，但：(1) 哪些决策算"关键"无量化标准 (2) ADR 写作时效无 SLA (3) ADR 质量无 review 机制 (4) ADR 引用正确性由 adr-required 检查，但 ADR 本身的正确性无法检查。
  • 影响: ADR 可能积压或质量不足，治理决策的可追溯性下降。

P1-15: incident-cell 72h TTL 到期的 escalation 路径不完整

  • 位置: incident-cell.yaml#lifecycle / team-collaboration.yaml#teams.incident_cell
  • 问题: incident-cell TTL 72h，到期时"escalate_to_owner + extension_requires_owner（绝不 auto-destroy）"。但 escalation 后若 owner 无响应，incident-cell 处于什么状态？持续消耗预算？还是进入冻结？未声明。
  • 影响: 事故处理可能无限期挂起，预算持续消耗。

P1-16: reviewer/test-author 双身份在不同角色间的模型族隔离边界

  • 位置: archetype-profiles.yaml#test-author.independence / reviewer.yaml / models.yaml
  • 问题: reviewer（test-author 实例）模型族为 flagship，builder 为 flash。但 reviewer 同时是 as_tool=true（leader/scheduler 可按需调用），这意味着其他 agent 可以调用 reviewer 生成测试。如果 reviewer 被错误地在 builder 之前或之后调用，可能导致工作流混乱。
  • 影响: 工作流的严格顺序可能被绕过。

P1-17: handoff 状态完整性验证缺失

  • 位置: team-collaboration.yaml#teams.delivery_squad.lifecycle.handoff
  • 问题: handoff 有 4 项（artifacts-pr, trace-archive, memory-export, retrospective）+ stewardship_side（memory-distill, adr-write）。但 handoff 的完整性验证（所有项是否完成、部分完成如何处理、超时如何处理）未声明。
  • 影响: 团队可能在 handoff 未完成时就被销毁，导致资产丢失。

P1-18: curator 的周审时间窗与 backlog 老化检测的 race condition

  • 位置: attention-ledger.yaml#asynchronous.weekly_review / flows.yaml#maintain_loop.issue_lifecycle.deferred
  • 问题: curator 周审时间窗为 <=60min 固定时窗，但 backlog 老化检测是持续的。如果 backlog 中 deferred 条目到期时 curator 正在周审，新的延期决策和旧的到期重排可能发生冲突。
  • 影响: backlog 维护回路可能出现状态不一致。

P1-19: adversary 沙箱销毁审计的执行主体未声明

  • 位置: archetype-profiles.yaml#adversary / CT-ADV-001
  • 问题: adversary 沙箱一次性使用后销毁，CT-ADV-001 要求"沙箱销毁日志+凭据零残留"。但销毁动作的执行者（谁触发销毁、谁审计销毁结果）未声明。
  • 影响: adversary 可能留下残留凭据或沙箱环境，影响安全。

P1-20: knowledge_retrieval 版本陈旧检测缺失

  • 位置: archetype-profiles.yaml#knowledge-retrieval / team-collaboration.yaml#interfaces
  • 问题: knowledge_retrieval 按 capability_tags 检索 ADR/skill 候选，但检索结果带 version_read（陈读不得作判决依据）。然而知识的"新鲜度"如何自动检测（如 ADR 已过期、skill 已废弃）未声明。
  • 影响: planner/judge 可能基于过时知识做决策。

P1-21: deployer 的 ask_per_action 在 automation 场景中的矛盾

  • 位置: archetype-profiles.yaml#deployer / deployer.yaml
  • 问题: deployer 审批模式为 ask_per_action（逐动作人签），但其 role 描述为"逐动作人签"。在 incident 场景下，快速响应要求（MTTR）与逐动作人签的慢流程存在矛盾。系统未声明"快速响应"与"逐动作人签"之间的优先级裁决机制。
  • 影响: 事故响应时间不可控，MTTR 无法保证。

P1-22: judge arbitration scope 声明与实际执行的 gap

  • 位置: archetype-profiles.yaml#judge.internal_flow / arbiter.yaml
  • 问题: judge 的管辖域枚举在声明中存在（"越域 → 判上升人类"），但管辖域的具体条目（哪些属于 judge 管辖）未在任何文档中枚举。arbiter.yaml 也没有声明具体的管辖域列表。
  • 影响: judge 可能在越域时无法正确识别管辖边界，错误地受理或拒绝争议。

P1-23: 变更分级 promote_if 规则的自动执行主体缺失

  • 位置: change-classes.yaml#classes.trivial.promote_if / intent-routing.yaml#routing.classifier
  • 问题: trivial 卡执行中发现应升级（promote_if 规则），变更分级的升级由"路径规则（机制判定）"执行。但执行主体（是 interface-gateway 机制？scheduler？还是 verifier？）未明确。
  • 影响: 升级判定可能执行不一致，导致部分 trivial 卡正确升级、部分遗漏。

P1-24: backlog 多写者归并的冲突解决机制缺失

  • 位置: team-collaboration.yaml#interfaces.backlog / backlog_role
  • 问题: backlog.proposals 允许多写者（curator/responder/owner/planner），但冲突解决机制（多个写者同时修改同一 backlog 条目）仅声明"optimistic_cas"和"CAS 连续失败 2 次 → escalation"。escalation 的目标和处置未声明。
  • 影响: backlog 归并可能在高并发下失败。

P1-25: 团队 workspace 挂载点的权限控制不明确

  • 位置: dev-wave.yaml#workspace / context-assembly.yaml#components.environment
  • 问题: 团队 workspace 有 shared root 和 inbox/artifacts/decisions/contracts 子目录。但不同角色对 workspace 不同子目录的读写权限未在声明中逐一列出。planner、builder、test_author 对 workspace 的访问控制不明确。
  • 影响: agent 可能读到或写入不该访问的 workspace 路径。

P2 级问题（潜在风险或可接受但需关注）

P2-1: judge 判例的"同类争议 ≥3 次 → 产 policy_gap findings"的计数逻辑

  • 位置: archetype-profiles.yaml#judge.internal_flow.5
  • 问题: 同类争议的"同类"如何定义？是按 capability_tags 还是按争议描述的语义相似度？计数由谁维护？
  • 影响: 判例累积的 policy gap 检测可能不准确。

P2-2: researcher 单次往返契约的 follow-up 机制缺失

  • 位置: archetype-profiles.yaml#researcher / CT-RES-003
  • 问题: researcher as_tool 为单次往返，不接受后续追加指令。但实际工作中，调用方可能需要追加问题。当前声明只说"输出封板不可二次加工"，未提供 follow-up 路径。
  • 影响: researcher 的实用性受限，可能需要多次调用才能完整回答一个复杂问题。

P2-3: budget 熔断后的自动恢复机制缺失

  • 位置: flows.yaml#budget.enforcement
  • 问题: 预算熔断（fail-closed）后，需要 owner 手动增加预算或调整配置才能恢复。系统未声明自动恢复的触发条件（如定期检查预算余量、按 usage pattern 自动调整）。
  • 影响: 熔断后的恢复依赖人工发现，可能延长停机时间。

P2-4: agent 的 a2a_card 发布的版本管理缺失

  • 位置: agent.schema.yaml#expose.a2a_card / agent definitions
  • 问题: 多个 agent 声明 a2a_card: auto，但未声明 A2A Card 的版本管理（旧版本兼容、版本升级通知）。
  • 影响: A2A 调用方可能使用过期的 agent card，导致协议不兼容。

P2-5: wave_contracts 的 single_writer 约束在 planner 重入时的竞态

  • 位置: team-collaboration.yaml#interfaces / dev-wave.yaml#wave_consistency
  • 问题: planner 重入（amendment）期间 builder 必须 frozen。但 wave_contracts 的 single_writer 是 planner，当 planner 重入时如果旧的 builder 还在写 contracts，可能发生竞态。
  • 影响: 波次契约可能在重入期间出现不一致。

P2-6: 记忆蒸馏的 quality check 机制缺失

  • 位置: context-assembly.yaml#memory.digest / team-collaboration.yaml#stewardship_side.memory-distill
  • 问题: curator 从 memory_digest 蒸馏知识时，蒸馏质量的检查（事实是否正确、经验是否可复用）未声明。蒸馏产物直接进入 curator 的持久记忆。
  • 影响: 错误的记忆可能被蒸馏入库，影响后续决策。

P2-7: ADR 引用与 ADR 实际内容的一致性检查缺失

  • 位置: checks.yaml#adr-required
  • 问题: adr-required 只检查 PR 是否引用了 ADR-NNNN，以及被引 ADR 是否在 PR head 的 decisions/ 中。但不检查引用的 ADR 是否实际支持 PR 中的结论。
  • 影响: 可能存在"挂羊头卖狗肉"的 ADR 引用——引用了 ADR 但结论与 ADR 无关。

P2-8: 团队间 shared workspace 的数据隔离边界

  • 位置: dev-wave.yaml#workspace / stewardship.yaml#workspace
  • 问题: 不同团队（delivery_squad, stewardship, incident_cell）各有独立 workspace（不同的 DSN），但 workspace 间的数据隔离边界和跨团队访问路径未明确。
  • 影响: 团队间数据可能意外泄露。

P2-9: 维护回路中 issue 关闭的"复绿证据"的验证深度

  • 位置: flows.yaml#maintain_loop.issue_lifecycle.closed
  • 问题: issue 关闭需要"复绿证据"（check 复跑通过）。但复跑的深度（是全量 gate 还是局部检查）未声明。对于 complex issue，局部复绿可能不足以证明问题已解决。
  • 影响: issue 可能在问题未完全解决时就被关闭。

P2-10: 同步与异步 owner 阻塞点的边界定义模糊

  • 位置: attention-ledger.yaml
  • 问题: synchronous 项（必须人在场）与 asynchronous 项（可延迟、有默认动作）的分类边界不总是清晰。例如"依赖审批"被归为 asynchronous，但某些安全关键依赖的审批可能应该是 synchronous。
  • 影响: 关键决策可能被默认动作处理，未获得应有级别的 owner 审核。

P2-11: agent 模型变更（模型升级/替换）的影响范围评估

  • 位置: models.yaml / intent-routing.yaml#intents.deliver
  • 问题: 模型注册表中的模型升级或替换，其对 agent behavior 的影响评估流程未声明。模型变更直接影响所有引用该 alias 的 agent。
  • 影响: 模型变更可能引入未检测的行为漂移。

P2-12: skill 版本升级的兼容性检查缺失

  • 位置: skill.schema.yaml / registry/skills
  • 问题: skill 有版本号但未声明兼容性要求。skill 升级（如 skill:tdd-loop 从 v1 到 v2）是否需要向下兼容旧版 agent 未声明。
  • 影响: skill 升级可能破坏旧 agent 的工作流。

P2-13: control test (CT) 的"红队悖论"

  • 位置: control-tests.yaml / archetype-profiles.yaml#adversary
  • 问题: adversary 执行控制测试需要使用目标 agent 的真实凭据。但 adversary 自己的凭据权限被严格限制（datastore_write 限 findings/）。如果 adversary 需要使用 builder 的完整权限（如 access certain test paths）来验证 builder 不能写 tests/acceptance/，adversary 的权限模型是否支持这种"以他人身份尝试越权"的操作？
  • 影响: 控制测试的实际执行能力可能受限于 adversary 自身的权限。

P2-14: 团队 scope 切换的约束未声明

  • 位置: team-collaboration.yaml#scopes / team.schema.yaml
  • 问题: 团队创建时绑定一个 scope（delivery/knowledge/adversarial/operational）。团队是否可以在生命周期中切换 scope？如果可以，需要什么条件？
  • 影响: scope 变更可能导致权限混乱。

P2-15: ephemeral 团队销毁后的 artifacts 清理时序

  • 位置: team-collaboration.yaml#teams.delivery_squad.lifecycle.destroy / context-assembly.yaml#memory.digest.ordering_invariant
  • 问题: 团队销毁后，其 artifacts（PR、事件、memory_digest）应已被 stewardship 消费。但"销毁→消费"之间的时序窗口中，artifacts 处于什么状态？如果 curator 在消费前检查 artifacts，是否能看到完整内容？
  • 影响: 时序窗口内的 artifacts 可能处于不确定状态。

P2-16: schema 迁移的 dry-run 在 CI 中的有效性

  • 位置: change-classes.yaml#classes.schema / checks.yaml#rollback-plan-required
  • 问题: schema 变更要求 migration-dry-run 和 backup-verified。但 dry-run 在 CI 中的执行环境（是否使用生产数据快照、是否能完整模拟真实迁移）未声明。
  • 影响: dry-run 可能无法充分暴露 schema 迁移的问题。

P2-17: researcher 对外部网络的访问控制粒度

  • 位置: archetype-profiles.yaml#researcher.capabilities.allow
  • 问题: researcher 有 net_read 权限（读外部网络），但未声明 URL 白名单、访问频率限制或内容过滤规则。
  • 影响: researcher 可能被滥用访问不合规内容。

P2-18: 注意力账本的动态调整机制缺失

  • 位置: attention-ledger.yaml#max_synchronous_per_week
  • 问题: max_synchronous_per_week=2 是硬断言，但当业务量增长时无法动态调整。系统未声明增加同步阻塞点的流程。
  • 影响: 固定的注意力预算可能限制业务增长。

P2-19: CODEOWNERS 的 owner-only 路径覆盖率

  • 位置: .github/CODEOWNERS / checks.yaml#adr-required
  • 问题: CODEOWNERS 声明了 owner-only 路径（standards/, decisions/, scripts/、.github/、CODEOWNERS、tests/），但未声明其在 agent-registry 仓的完整覆盖情况。
  • 影响: 可能存在未被 CODEOWNERS 覆盖的敏感路径。

P2-20: governance change 的 C1/C2/C3 分级执行细节

  • 位置: GOVERNANCE.yaml#flows.governance_change / change-classes.yaml
  • 问题: govern 意图的载体为 C1/C2/C3 分级，但每一级的具体评审人、审核流程、时效要求未在 intent-routing.yaml 中展开。
  • 影响: 治理变更的执行可能不一致。

P2-21: planner 的 acceptance_source 与 deliver intent 的同步交互

  • 位置: intent-routing.yaml#intents.deliver / attention-ledger.yaml#intent_ratification
  • 问题: deliver 意图需要 owner 同步批准验收示例（5-15 条×30 秒）。当 wave 包含多卡时，每张卡的验收示例是否需要逐一批准还是批量批准未声明。
  • 影响: 批量批准可能导致注意力经济失效（owner 不逐条阅读）。

P2-22: incident retro 的 quality gate 缺失

  • 位置: flows.yaml#incident / CT-RSP-002
  • 问题: responder 24h 内补 retro（事故报告），curator 追踪逾期债。但 retro 本身的质量（是否包含 root cause、是否有 action items）无检查。
  • 影响: retro 可能流于形式，无法改进系统。

P2-23: 机制原型（scheduler/verifier/integrator）的故障检测

  • 位置: archetype-profiles.yaml (机制原型段)
  • 问题: 机制原型（非 LLM 主体）的故障检测与恢复路径未声明。如果 scheduler 状态机异常或 verifier 无法运行，检测机制是什么？
  • 影响: 机制故障可能导致系统级中断，且无检测与告警。

系统性模式

SP-1: 声明层 vs 运行时鸿沟

大量问题的根源是"声明了流程但未声明运行时强制"。test-tree-freeze、event_integrity、adversary 告警通知等在声明中存在，但运行时如何强制执行不明确。这是最普遍的模式，约占问题的 50%。

SP-2: owner 单点依赖几乎无解

owner 同时承担：vcs_admin（唯一）、intent ratification（唯一）、judge 管辖域修改（唯一）、C1/C2 merge（唯一）、prod flag 开启（唯一）、judge verdict 推翻（唯一）、sev1 forward fix（唯一）。任何一个 owner 不可用的场景都会导致多个子系统同时阻塞。系统未声明 owner 的副本、代理或委派机制。

SP-3: 预算模型交叉依赖

per-card 预算、team envelope、overhead pool 之间的关系在声明层清晰，但执行时存在交叉依赖：per-card retries 消耗 team envelope、overhead pool 耗尽影响 escalation、team envelope 耗尽影响 per-card 执行。预算模型的隔离性不足。

SP-4: "机器可判定"的可验证性缺失

多处声明标注"机器可判定"（如 backlog deferred 条件、maintenance wave trigger、judge 激活计数器），但这些条件的具体判定逻辑和验证方法未在声明中给出。"机器可判定"变成了一个标签而非可执行规范。

SP-5: handoff 状态完整性假设

多处流程假设 handoff 完成，但 handoff 的完整性验证（所有 4+2 项是否完成、部分完成如何处理、超时如何处理）未声明。handoff 状态的完整性依赖各执行方（mechanism:git、mechanism:metrics-aggregator、seat:planner 等）正确执行，但无汇总检查点。

SP-6: 控制测试的"红队悖论"

adversary 需要"使用目标原型真实凭据尝试越权"来执行控制测试，但 adversary 自身的权限被严格限制。这导致控制测试的实际执行能力取决于 adversary 能否获取到目标原型的凭据——而这本身就是一个权限问题。CT 的 runtime 字段（adversary-executed vs manual_only vs validate-executed）暗示了这个能力边界，但边界本身未明确定义。

测试方法论说明

本报告基于以下方法论：

  1. 声明一致性走查: 交叉引用 agent 声明、team 声明、标准文件（archetype-profiles/team-collaboration/intent-routing/flows/change-classes/checks/control-tests/context-assembly/side-effects/attention-ledger/observability），寻找声明间的不一致、矛盾和缺口。
  2. 流程断点模拟: 模拟 happy path、owner 缺席、预算耗尽、并发事故、角色不可用等场景，追踪每个流程步骤的完整性。
  3. 反馈回路完整性分析: 对 escape_review、maintain_loop、judge 激活、amendment、memory distill 等反馈回路进行闭合性分析。
  4. 极端场景压力测试: 零预算、同步决策拥塞、令牌泄露、model family 不可用、ancient backlog、credential leak 等极端场景。
  5. 控制测试覆盖度分析: 交叉对照 control-tests.yaml 与 archetype-profiles.yaml.structural.claim，检查覆盖率与 runtime 可行性。

涉及文件（共 20+）:

  • .github/governance/GOVERNANCE.yaml
  • .github/governance/REPOS.yaml
  • .github/governance/expected-state.json
  • .github/standards/agent/{agent,team,skill,tool,event}.schema.yaml
  • agent-registry/standards/{archetype-profiles,team-collaboration,intent-routing,flows,change-classes,checks,control-tests,context-assembly,side-effects,attention-ledger,observability,scenarios}.yaml
  • agent-registry/registry/agents/{wave-planner,backend-dev,reviewer,researcher-code,curator-main,deployer,responder,red-adversary,arbiter}.yaml
  • agent-registry/registry/teams/{dev-wave,incident-cell,stewardship}.yaml
  • agent-registry/registry/models.yaml
  • template-service/AGENTS.md
  • template-service/docs/ARCHITECTURE.md

严重度分布

级别 数量 说明
P0 8 系统不可运作或安全防线失效
P1 25 显著退化或安全防线显著削弱
P2 23 潜在风险或可接受但需关注
总计 56

报告完成于 2026-08-19。

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    governance治理体系相关processred-team红队演练发现

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions