治理体系 Red-Team 演练问题报告（声明完备/运行设施断点、流程僵死与守卫矛盾）

[randypanding]

治理体系 Red-Team 演练问题报告

演练方法与范围

本报告来自对组织治理体系（Cloudbird-Software/.github、Cloudbird-Software/agent-registry、Cloudbird-Software/CI-Workflows、Cloudbird-Software/template-service）的一次红队流程演练：多个子代理各自扮演交付波次/评审/事故/治理 spawn 四类真实流程，逐步推演相位状态机，并构造极端情形（owner 失联、僵持死循环、并发冲突、预算耗尽、供应链引导）挑战流程健壮性。

前置基线：仓库内置校验器 scripts/validate.py 与场景模拟器 scripts/simulate-wave.py（20 场景）在当前 head 上全部通过——即"声明的世界"在声明层自洽。以下问题全部来自上面的自洽声明与实际可运行设施之间的客观断点，均附精确证据（仿真走查 + 仓库实现审计），不含解决方案。

---

A. 交付流水线"声明即生效"，但运行机制无实现（机制层空转）

A-1　交付链的全部推进机制无实现代码，端到端不可运行

• standards/team-collaboration.yaml activation.now 声明 scheduler / verifier / integrator / evidence-pack / interface-gateway / metrics-aggregator / card-gate / release-bot / knowledge-retrieval / drift-check"代码实现即生效，被依赖即工作，机制无待触发状态"。
• 实际审计：agent-registry/scripts/ 仅 validate.py + simulate-wave.py（声明校验 + 流程彩排，其文档串自述"不是单测，是流程彩排"）；CI-Workflows 仅提供 check/hygiene/dep-review/release 四类 CI；template-service/src/index.ts 是 greet("Hello") 模板。这些机制名在各仓实现代码中 0 命中。
• CI-Workflows/README.md 第 43 行明示：mechanism:verifier 判卷 workflow 尚未实装，属 ADR-0010 二期。
• 后果：owner 下达意图→destroy 的整条链在运行层无推进体（scheduler 开卡/verifier 判卷/integrator 合并/release_bot 发布均无实现），唯一被 CI 验证的 simulate-wave.py 只证明"声明可执行"，不能运行真实开发流程。交付流水线整体为"声明完备、运行缺失"。

A-2　checks.yaml 多条 status: active，宿主机制未实装

• test-tree-freeze(active) 宿主为 verifier，而 README 明示 verifier 未实装——"active" 与宿主缺失直接矛盾；intent-ratified(active) 宿主为不存在的 scheduler；retro-debt-aging(active) 宿主 metrics-aggregator 无实现；spawn-manifest-conformance(active) 其 where 自述"声明层先行、平台侧随模板仓落地"。
• drift-check.sh §1–§11 逐段覆盖 ruleset/repo/actions/app/ADR/CI 指针等平台机制，没有任何一节校验"声明的 agent 交付流水线机制（scheduler/verifier/权限引擎/Gateway/metrics/数据层）是否落地"；AR-9/AR-5 标 strength: enforced，其 verify 只有 PR 时点的 validate.py（校验声明形态合规），无运行期存在性验证。

---

B. 角色无法被触发 / 任务无人认领

B-1　owner 失联时，intent_ratification 无限期等待，ephemeral 交付队永不销毁

• intent_ratification 为 synchronous 账本项，notes 声明"此项无默认动作=只能等待"(attention-ledger.yaml L16-17)；溢流链无任何 TTL/升级兜底（对比 incident_cell 有 ttl: 72h + on_ttl_expiry: escalate_to_owner）。
• owner 不批准 → cards.ratified 永不产生 → plan→build 边不可达 → released_behind_flag OR reverted 永不满足 → delivery_squad.destroy_condition(dev-wave.yaml L77) 永不达成。owner_control.abort 需 owner 主动落事件，owner 失联时无人触发 → ephemeral 队伍长期滞留 plan 相位，既不停工归档也不销毁（空间/凭据泄漏且状态机无出口）。

B-2　意图分类器对"八类之外"输入无路由行为（无 fail-closed 出口）

• intent-routing.yaml routing.classifier 只描述"语义匹配+变更面探测自动归类"与歧义（示例 fix↔deliver 两类，ambiguity_rule）；表内 8 类（deliver/fix/respond/investigate/maintain/govern/spawn/ask）之外或跨多类的输入如何处置未定义，无拒单/升级默认动作；对照 default_action 原则"无法判定→先拆到可判定"在路由层未落地。

B-3　ask 意图（researcher as_tool）无预算归属

• ask 载体为"无卡无队单次往返"的 researcher(intent-routing.yaml L85-91)；overhead_pool 定义在团队级 budget(team-collaboration.yaml L397、dev-wave.yaml L60-62)；budget.invariants 只豁免 escalation 与 judge 调用，不含 researcher。裸 ask（无队无卡）发生时，单次往返无池可归属，对应"预算有归属"断言(A4)不成立。simulate-wave.py S1⑦ 仅在 dev-wave 团队分支内校验 overhead_pool，不覆盖独立 ask。

B-4　judge 激活依赖"僵持累计>=2"，而计数机制无实现 → judge 永不激活

• verdict_stalemate 的 producer=scheduler(team-collaboration.yaml L271)、计数=metrics-aggregator(L138-139)、激活条件="僵持累计>=2"(L436)。三者皆以声明存在，但 scheduler/metrics-aggregator 无实现代码 → 僵持累计无法达到 2 → judge_service 永远不激活，所有僵持停留在"直达 owner"回退路径。
• simulate-wave.py S5(hook L422-445)只断言路由字符串、成员 approved、族独立、无写路径，从不校验是否存在能真正 verdict_stalemate += 1 的计数器。注意力账本的 judge_deferral_queue/dispute_escalation_before_judge 也因此永远不会迁到 judge 动作。

---

C. 反馈死循环 / 死锁

C-1　verify→build 返工回边无上限，"重规划逃生"无相位边/事件承接

• 相位图存在 verify→build when review.changes_requested 返工回边(team-collaboration.yaml L254)，图上无任何"循环次数≥N 离开"的条件。
• 唯一重试上限写在 budget.per_card.retries(flows.yaml L52/L55，默认1、high≤2)，并承诺"再失败必须回 planner 重新规划"。但相位图中唯一的入 plan 边是 any→plan when amendment.normative.accepted（producer=owner），没有承接"retries 耗尽/重规划"的事件键（flow.event_producers 无对应项）。
• 后果：review.changes_requested 可无限重发 → 要么无限返工烧预算，要么停在"等不存在的 scheduler 触发重规划"死锁/僵尸卡。

C-2　卡回炉后仍由同一 planner 重产同规格，回路未打破

• escalate_when：同卡 normative>=2 →"卡有问题回炉"；同波>3 →"冻结新开卡+escalate owner（由 owner 裁，不自动）"(team-collaboration.yaml L322)。回炉卡经 backlog→下一波次 producer_gate 重新入队；planner 座位 reentry: on_normative_amendment。
• amendment.classify.normative 默认动作是"卡冻结+退回 backlog+波次继续其余卡"——没有任何"撤换规划产出者 / 同规格再产即拒绝"的机制。回炉→同一 planner 重产同规格→再歧义→再回炉的环路在机制层无出口，全部收敛到 owner 注意力（amendment_rate 只归因不纠偏）。

C-3　test_fix 减弱护栏 × 冻结测试树互相锁死，"测试写错了"无 owner 时无修复路径

• 仲裁路由：builder 主张"测试写错了"先走 amendment.test_fix 修复路径(team-collaboration.yaml L285-286)。
• test_fix 弱减型（删测试/删断言/放宽阈值/加 skip）不走此类→降级特权变更：新卡+owner 批+test_weakening 事件(L315-316)；test_weakening_approval 默认动作是 24h 拒绝(attention-ledger.yaml L29-30)；而 CT-TA-003 冻结树要求实现开始后 tests/acceptance/** 任何改动失败(control-tests.yaml L26-33)，reviewer 自身纪律也"修改测试须新卡+owner 批+重新冻结"。
• 真实"测试断言判错"的纠错几乎必然构成减弱型 → 走 owner 默认拒绝；非减弱改动又违反冻结树纪律 → 三条路径全部被堵，无 owner 时未减弱型可修复路径 = 0，builder 反复被打回并叠加 C-1 无界回边。

C-4　僵持"直达 owner"的默认动作止于留痕，无下家

• dispute_escalation_before_judge 默认 24h："卡冻结+双方主张入 evidence-pack 留痕（绝不默认合并）"(attention-ledger.yaml L26-27)。留痕之后不自动升级 judge、不自动归档、不依据证据仲裁；during_dispute.run=frozen, budget_clock=paused 使卡冻结无终止。owner 失联时永久悬挂。

---

D. 事故 / 运行极端

D-1　sev1 + rollback_safe=false + owner 失联：入口出口全闭，永久悬挂

• responder 仅可 actions_else=[feature_flag, failover, scale, data_freeze](L219)，无法恢复服务；forward_fix: owner_required(L220)；sev1_forward_fix_authorization 账本项"无默认动作=只能等待"(attention-ledger L16-17)；on_ttl_expiry = escalate_to_owner + extension_requires_owner(L232)；exit_criteria.declared_by=owner, responder+owner_ack。
• owner 失联时，"升级给失联者"不产生第二个处置者，"绝不 auto-destroy" 与 "require owner" 叠加 → 唯一稳态是永久悬挂，流出/归档/降级过渡态均不存在。sev1 无 ack 超时默认动作，正是 default_action"人在环点必有默认动作"原则的最高危例外。

D-2　severity 定级方缺位，保守默认会把真实 sev1 压成 sev2

• severity_classified_by："告警源标签或 owner 指定；皆无→sev2(保守)"，responder 无权定级(L213)。owner 呼叫但未贴标签、且无外部告警源标签时，机制落 sev2 → 预授权收窄为 [feature_flag, scale]，data_freeze 等 sev1 兜底被剥夺；incident-in.json 校验只含"不含 sev3"，不校验 owner 呼叫时 severity 必填；responder 无法升档。真实 sev1 被压档后停留 sev2，sev2.deploy_reverse 仅在 rollback_safe 时预授权，否则 data_freeze 同样无法恢复服务。

D-3　并发既有相交判定无执行者，写锁 runtime 无载体

• cross_squad："并发 squad 的 owned_paths 必须不相交，相交 → 拒组建或串行"(L179)，但未指派任何机制执行该判定（services 无对应项、无对应事件，validate/simulate 均不覆盖路径冲突）；注释自认"CAS 是检测不是预防"(L178)——相交只能事后经 CAS 连续失败检测，先写一方已污染。
• write_exclusion "enforced_by: runtime" 的 runtime 无实现载体（无机制原型/服务，S1–S12 无一场景验证并发写锁）。

D-4　预算"升级永不受限"不变式与 fail-closed 硬顶冲突，且无豁免分支

• budget.invariants："escalation 与 judge 永不受任何预算约束"；但执行层 flows.yaml#budget.enforcement 是全局硬顶（gateway per-run 限额、scheduler wall_clock、并发上限，on_exceed: fail-closed），无"escalation 类调用豁免配额"实现；simulate-wave.py S4 对该不变式只做字符串包含断言（L403）——纸面不变式，执行层未落地。

---

E. 治理跨仓一致性 / 新仓 spawn 通道

E-1　AGENTS.md 引导的未 pin curl|bash 令牌获取，与组织供应链硬规则自相矛盾

• template-service/AGENTS.md L9-10 教 agent 执行 GH_TOKEN=$(REPO=template-service bash <(curl -sS https://raw.githubusercontent.com/Cloudbird-Software/.github/main/scripts/gh-app-token.sh))：从 .github main 可变指针拉脚本、bash <(curl) 远程执行（无法先校验哈希）、且该脚本现场铸造具备 contents/issues/PRs:write 的 App 安装令牌（gh-app-token.sh L20/L67-74）。
• 同一组织在 CI-Workflows/ci.yml L50-58 把同类风险显式作 ADR-0011 遗留项整改——gitleaks 以 GL_SHA256 双锚定、uv 用 sha 锚定 action（"downloadThenRun not pinned by hash"）。token 脚本自身也不 pin（同仓 new-repo-init.sh 注释却要求 init 脚本"pin 到审阅过的合并提交"）。获取凭据的唯一引导通道比"未 pin 的二进制下载"高一个风险档（产出令牌），且位于新仓派生源头（GOVERNANCE.yaml 将 template-service 列为 C1 P0 供应链入口）。

E-2　治理声明中的调度密度与实现不一致

• GOVERNANCE.yaml GM-1 声明工作流 cron 为 daily 03:00 UTC；实际 .github/workflows/governance-drift.yml L4 为 0 * * * *（每小时），GM-4 亦声明 hourly。声明(GM-1)与实现/自我引用(GM-4)的频率口径不一致——检测实体为小时级，但治理总声明仍残留"日跑 03:00"描述。

E-3　新仓 spawn 被唯一 owner 串行门控，owner 缺位时产物以"未申报漂移态"停留

• flows.new_repo：①gh repo create --public；②new-repo-init.sh（需组织 admin）；③申报入 REPOS.yaml——属 C1 路径（GOVERNANCE L193-195，要求 owner-merge + ADR）；④首 PR。spawn 的 admin 操作与 C1 owner-merge 均系于唯一 owner（ADR-0010 admin 全系统唯一），owner 缺位时仓库已 public 上线但停在"未申报=漂移"及 C1 待 owner 态；例行"建仓"被并入治理意图变更通道（强制 ADR 起草），产物通道与治理通道耦合。

---

汇总

问题集中在四个同向根因（仅陈述，不扩展方案）：

1. "声明的世界"与"可运行设施"脱节：交付流水线全部推进机制（scheduler/card_gate/verifier/integrator/release_bot/interface-gateway/metrics/evidence-pack/knowledge-retrieval）及 checks.yaml 多条 active check 的宿主无实现代码，且 drift 检测不覆盖该层（A-1/A-2/A-3/B-4/C-1）。
2. owner 是绝大多数阻塞点与仲裁出口的唯一人类，其"失联"未被建模为可触发旁路的状态：intent 不批则队永不销毁、事故 TTL 升级自身、僵持直达 owner 无出口、spawn 卡 owner（B-1/C-4/D-1/D-2/E-3）。
3. 若干逃生路径只写在声明/prose 层，未落成相位边、事件或执行体：重规划承诺、撤换产出者、预算豁免、cross_squad 判定、write_exclusion runtime（A-3/C-2/D-3/D-4）。
4. 引导通道与规则自相矛盾：令牌获取唯一通道未 pin 且产令牌，与组织已在 CI 严格执行的 hash 双锚定规则冲突（E-1），并含声明与实现的频率口径漂移（E-2）。

[randypanding]

定性：部分真实——声明层与 CI 层问题已修复，运行时断言属 ADR-0010 二期既有定性

已修复（ADR-0021，agent-registry#29/#30 + .github#73/#75 + template-service#12）：

• GM-1 cron 声明 daily 03:00 vs 实现 hourly → GOVERNANCE.yaml 已对齐（.github#73）
• AGENTS.md 未 pin 的 curl|bash → pin 到已审阅合并提交（template-service#12）
• synchronous 无默认动作（违反"无默认动作的人在环点禁止存在"）→ intent_ratification 7d/sev1 前进修复 24h/amendment 24h/incident TTL+72h 四类默认动作，全部取更可逆一侧（ADR-0021 决策3）
• planner 退场后 handoff 死人执行者、ephemeral 队永不销毁 → 决策1/2（memory-export=在场座位 + no_release_face 出口）
• retries 耗尽无回 plan 边、争议期 budget_clock 绕过 → 决策4；judge 激活判据只计"结论相反" → 决策5；test_fix 无 builder 落点 → 决策5
• 新建仓 owner 串行门控滞留"未申报=漂移" → .github#75 已补申报+bootstrap 豁免，drift-check 实测无漂移

不修复（显式定性，ADR-0021"不做的事"）：

• 交付链机制"代码实现即生效"在运行层不成立——运行时实装按 ADR-0010 二期路线，本批以决策8（validate.py 机制引用必须解析到原型/services 块，ghost 引用 PR 即拒）+ 治理测试回路（agent-registry#30：回归/差分/canary 周期 Action）钉住声明↔实体对应，防"纸面语义"无界扩散。