治理体系红队测试问题总报告（客观证据，79 项，不含处置建议）

[randypanding]

Cloudbird-Software 组织治理体系红队测试问题总报告（客观证据）

演练日期：2026-08-19
演练范围：三个治理仓（L0: .github + CI-Workflows；L1: agent-registry；L2: template-service 及业务仓）
演练轮次：3 轮（白盒正常流程 / 边界异常场景 / 红队压力渗透）
参与测试场景数：22 个主场景 + 55+ case
累计发现问题数：79 项（P0 级 22 项 / P1 级 31 项 / P2 级 16 项 / P3 级 10 项）

本 issue 仅陈述演练中发现的问题与可客观证明的证据位置（仓库文件、行号、线上 GitHub API 状态）。不含处置建议。

---

一、演练方法（客观事实）

轮次	名称	测试视角	场景数	发现问题数
第一轮	正常流程白盒走查	模拟 4 个标准开发流程（建新仓/C1 变更/团队生命周期/普通 PR），逐步骤核对触发点、门禁、衔接点	4 大场景 / 24 子步骤	47 项
第二轮	边界与异常场景	8 大类边界 case（REPOS/分级生命周期/身份权限/破玻璃/Actions/语言/测试）	8 大类 / 30 case	30 项
第三轮	红队压力渗透测试	5 类攻击（绕硬防线/死锁无人认领/反馈循环耗尽/agent 运行时/结构性缺陷）	5 大类 / 12 攻击路径	新增 17 项关联问题

二、问题分布总览

严重度	定义	数量
P0	阻塞流程 / 治理核心防线洞开 / 死锁 / 供应链攻击可实际落地	22
P1	关键校验缺失 / 流程断点 / 长期漏洞 / 无人跟进窗口	31
P2	语义歧义 / 边界不清 / 灰区真空 / 格式不统一	16
P3	效率改进 / 最佳实践 / 体验优化	10
合计		79

三、3 大结构性缺陷（跨类别叠加）

1. 治理监控机制本身不可信：drift-check 漂移检测的幂等逻辑（标题模糊搜索"治理漂移"）、§8 直推正则（可伪造 PR 号结尾）、9 段检测对仓内容零校验——上述缺陷叠加后，攻击者可一次性使所有治理自动监控失明，后续任何攻击都永不被发现。
2. owner 单点 + 治理仓无灾备：admin==1 唯一人 + CODEOWNERS 全路径 @randypanding + .github / CI-Workflows / agent-registry 三仓无 deletion_protection + 无镜像/冷备/DR runbook。owner 休假=全组织开发活动死锁；owner 账号被盗=三仓被删=组织工程体系崩溃。
3. 供应链绿色误判三层通道：CI-Workflows v1 tag 可被 admin 通过 release-tags ruleset 的 bypass 覆盖 + dependabot minor/patch auto-merge 无 hash pin + Actions 白名单 Cloudbird-Software/* 粗粒度放行内部 action——三层组合形成一条完整投毒通道：修改 CI-Workflows gate 实现 → 所有业务仓 gate 全绿但执行任意代码。

---

四、P0 级问题（22 项）

P0-01：gh repo create 脱机零门禁，建仓流程完全失控

• 来源：第一轮场景 1-S1-01
• 位置：flows.new_repo 步骤 1
• 问题：gh repo create 是本地命令，任何有组织写权限的成员都可创建任意模板、任意 visibility 的仓；模板选错、非 owner 创建、visibility 错配等只能在事后 REPOS.yaml 申报时被发现，此时仓已真实存在，已构成 GM-4 漂移。
• 后果：非 owner 成员可创建任意 private 仓；绕过治理基线的"野仓"可存活到下周一 drift-check（最长 7 天）。

P0-02：CodeQL Default Setup 未自动启用 → 首次功能 PR 永久死锁

• 来源：第一轮场景 1-S1-02
• 位置：flows.new_repo 步骤 5 + codeql-gate ruleset
• 问题：codeql-gate ruleset 要求 CodeQL 扫描结果作为 required status check；template-service 默认未预置 CodeQL enablement，new-repo-init.sh 中也未包含启用步骤。业务仓首个功能 PR 的 required check 永远 pending，PR 无法合并。
• 后果：所有新业务仓第一次提交功能代码即死锁，开发活动停滞。

P0-03：C1 跨 L0+L1 双仓变更无原子性保证

• 来源：第一轮场景 2-S2-01
• 位置：flows.governance_change C1 scope
• 问题：C1 级变更（如新增 archetype）需同时改 .github 仓（GOVERNANCE.yaml）和 agent-registry 仓（schema/validate.py），两个仓是独立 PR，无法原子合并。中间窗口期（如 agent.schema.yaml 已合并、GOVERNANCE.yaml AR-8 未合并）产生"合法但不合规"的状态，validate.py 校验不完整。
• 后果：可先合 schema（放宽约束），利用"owner 忙"的时间窗口让 GOVERNANCE 延迟合并，窗口内注册违规 agent。

P0-04：apply.sh 无 merge 后自动触发机制

• 来源：第一轮场景 2-S2-02
• 位置：governance/apply.sh + governance-drift workflow
• 问题：apply.sh（把治理落盘写到 GitHub 平台：rulesets/App 权限/Actions 白名单）完全靠 owner 手动执行。PR 合并后若 owner 未执行，治理规则在平台层悬空最长 7 天（下周一 drift-check 才发现）。
• 后果：7 天窗口期内新增 ruleset 不生效，攻击者可利用旧 ruleset 漏洞；App 权限变更不生效 = agent 凭据错误。

P0-05：AR-8 族级独立（不同 model family）自动化校验缺失

• 来源：第一轮场景 3-S3-01 + 第二轮 C4
• 位置：agent-registry validate.py AR-8 校验分支
• 问题：AR-8 要求 test-author 与 judge 必须族级独立（不同 model family，防止自出卷自判卷）。validate.py 只实现了"同声明不同 archetype"的本地检查（builder≠test-author 不同声明文件），未实现跨声明的 models.yaml family 比对。
• 后果：builder 与 judge 用同 family 模型=自证自、自出卷自判卷，"可信交付"AR-9 链条第一环断裂。

P0-06：Ephemeral 团队销毁无自动触发 Workflow

• 来源：第一轮场景 3-S3-02
• 位置：flows.agent_team_lifecycle §4 + team schema AR-6
• 问题：ephemeral 团队完成 6 项 handoff、handoff_done=true 后，没有任何自动化机制销毁团队的 runtime 资源（临时 App token、团队命名空间 OIDC、短期密钥、事件流上下文、临时存储）。销毁完全依赖"人记得手动删"。
• 后果：密钥/token 永久残留，违反短暂性语义；注册表里僵尸 team 堆积，资源泄漏。

P0-07：verdict_by=mechanism:verifier 机制完全未定义

• 来源：第一轮场景 3-S3-03
• 位置：team.schema.yaml L46 + GOVERNANCE.yaml AR-9
• 问题：verification 链中"判卷"是 AR-9 可信交付最关键的一环，但 mechanism:verifier 到底是什么没有任何定义——是 judge archetype agent？是 CI job？是 human reviewer？需要什么配置？输出什么验真凭证？全未定义。
• 后果：verification 声明存在但实际无执行者，所有团队的"可信交付验证链"形同虚设。

P0-08：CODEOWNERS * @randypanding → 所有业务 PR 全死锁

• 来源：第一轮场景 4-S4-01 + 第三轮 B1 攻击
• 位置：CODEOWNERS + main-protection ruleset（require_code_owner_review=true）
• 问题：.github 仓 CODEOWNERS 是 * @randypanding（所有路径），加上 ruleset 中 require_code_owner_review=true：任何 PR（业务代码一行变更/dependabot patch 升级/documentation typo）都必须唯一 owner @randypanding 审批。dependabot BP-4 auto-merge 的前提是 review requirement 被满足，但 dependabot PR 永远缺 owner approved comment → auto-merge 100% 死锁。
• 后果：每天 10+ PR → owner 工作量物理超限；dependabot auto-merge 功能死锁。

P0-09：MOD-3 模块≤3000 行 = 定义不明 + 无拦截脚本

• 来源：第一轮场景 4-S4-02
• 位置：policy/languages.yaml MOD-3
• 问题：MOD-3 写的是"模块≤3000 行，超限拆分"，但："模块"定义模糊（是 Go module？业务边界目录？包？）；测试文件（_test.go）计不计入未定义；CI gate 中完全没有行数统计脚本。3500 行的大模块 PR 不会被拦截，直接合入。
• 后果：MOD-3 治理完全空心化，大模块持续膨胀。

P0-10：agent-tools planned 状态仓已创建但所有检测全 skip

• 来源：第二轮场景 A-A4
• 位置：REPOS.yaml GM-4 + drift-check §7 + repo_baseline gate
• 问题：REPOS.yaml 中 agent-tools 是 status=planned（GM-4：planned 不参与检测）。若该仓实际上被创建并在使用：drift-check §7a/7b 全跳（已申报 + planned 不要求存在/一致）；repo_baseline gate：planned → 全跳；Actions 白名单：planned → 全跳。
• 后果：agent-tools 作为真实在用的仓，所有治理门禁零检查，完全不受控。

P0-11：C1 scope 漏列 policy/ 等高影响路径 → 重大变更可绕过治理

• 来源：第二轮场景 B-B2+B3+B4
• 位置：GOVERNANCE.yaml flows.governance_change.classes[].scope
• 问题：C1 scope 白名单枚举为 [GOVERNANCE.yaml, rulesets/, expected-state.json, standards/, models.yaml, decisions/]，缺三个高影响路径：governance/policy/*.yaml（testing.yaml/languages.yaml）；.github/CODEOWNERS 和 .github/settings.*；.github/workflows/*.yml 的 gate 逻辑修改。
• 后果：修改 languages.yaml 把 rust 从 forbidden 移到 allowed → 不需要 ADR、不需要 owner-merge → 任何 approve 即过 → rust 工具链 + 不受控二进制产物引入组织。

P0-12：CODEOWNERS 改 owner → 可悄悄转移治理权

• 来源：第二轮 B4
• 位置：.github/CODEOWNERS + C1 scope
• 问题：无任何机制强制"CODEOWNERS 变更必须走 C1+ADR"。PR 修改 .github/CODEOWNERS，最后一行从 * @randypanding 改为 * @Cloudbird-Software/xx-team，命中不到 C1 scope（见 P0-11），走普通 PR。PR 一旦 merge，新 CODEOWNERS 立即生效，之后所有治理仓 PR（包括 C1 级 GOVERNANCE.yaml 变更）都不再需要 randypanding。
• 后果：只要 randypanding 有一次误点 approve，权限可被永久转移。

P0-13：verification.test_authors 引用 builder archetype = 可自证自

• 来源：第二轮 C3
• 位置：agent-registry validate.py + team schema verification 段
• 问题：team schema 声明"含 builder 的团队必须 verification.test_authors"，但 validate.py 只校验 test_authors 是字符串数组，不做两件事：cross-ref 到 agent 声明文件查 archetype 是不是 test-author；检查 test_authors 与 builder 成员是否来自不同声明。
• 后果：team.yaml 写 verification.test_authors: [agent:my-builder@1.0.0] → validate.py 通过 → builder 自己验证自己的代码 → verification 链失效。

P0-14：§8 直推检测正则可伪造——破玻璃监控洞穿

• 来源：第二轮 E1 + 第三轮 A 类攻击变种
• 位置：drift-check.sh L151
• 问题：§8 判定非 PR commit 的正则是 select(.commit.message | test("[(]#[0-9]+[)]$") | not)，意为"commit message 末尾不含 (#数字) = 直推"。攻击者只需在 commit message 末尾手动加一个假 PR 号即可绕开（如 fix: 后门植入 (#99999)）——PR #99999 实际不存在、未被 merge，drift-check 不做二次校验。
• 后果：破玻璃监控完全洞穿，可无限直推 main 无报警；配合 admin 直推权限可永久无痕迹写入恶意代码。

P0-15：Actions 白名单只控来源不控内部行为 → org 自有 action 投毒

• 来源：第二轮 F2 + 第三轮 A1+A3 关联
• 位置：expected-state.json actions_policy.patterns_allowed + CI-2
• 问题：白名单包含 Cloudbird-Software/*，意味着 org 下任何仓作为 action 被引用都被允许。但 CI-2 只检查 "uses" 的 action 路径是否在白名单，不检查该 action 内部实际运行了什么。
• 后果：攻陷 Cloudbird-Software 内部 action 仓（contributor 提交恶意 PR、reviewer 误批合入），在 action.yml 新增 run: curl ... | bash → 发布新版本并移动 major tag → 所有引用 @v1 的业务仓自动执行恶意代码，CI/CD 环境被攻陷。

P0-16：heavy_orm 禁止用字符串匹配 → gorm-auto-migrate 完全漏

• 来源：第二轮 G2
• 位置：policy/languages.yaml heavy_orm_forbidden + gate dep-review 子项
• 问题：heavy_orm_forbidden 列表是 [prisma, hibernate, gorm-auto-migrate]。dep-review 扫描 go.mod 时：prisma/hibernate 能按包名命中；gorm-auto-migrate 不是包名（没人 go get gorm-auto-migrate），它是 gorm.io/gorm 库的一个使用模式（调用 db.AutoMigrate(&Model{})）。gorm 引入完全正常通过，代码中写了 db.AutoMigrate 也无任何 CI gate 拦截。
• 后果："禁 heavy_orm" 对 gorm 完全无效，gorm 大规模使用 → 数据库迁移不可控。

P0-17：T-08 flaky test 治理 = 仅有文档，无执行引擎

• 来源：第二轮 H1
• 位置：policy/testing.yaml T-08
• 问题：T-08 规则是"重跑一次过≠通过；同测试两次飘→隔离+issue"。但：CI（Actions）的 rerun 是 job 级重跑，不是 test case 级 trace；没有系统收集"同一个 test case 最近 7 天 FAILED 次数"；"两次飘→自动开 issue + 自动 skip 隔离"的自动化 action 完全不存在。
• 后果：实际操作是 test 第一次失败→点 rerun→过了→PR 绿色→合并；flaky test 永远在 CI 里随机爆炸，永远没人跟进。

P0-18：triggered 测试（G-01~G-08）= 全部形同虚设

• 来源：第二轮 H2
• 位置：policy/testing.yaml triggered 段
• 问题：G-01 到 G-08 都带 trigger=xxx 字段（first_public_api/sql_layer_landed 等），但完全没有 trigger 引擎。谁来检测"第一次出现 public API 声明"？谁来检测"SQL 层第一次落地"？trigger 条件怎么激活？全是 declarative intent，没有 executable engine。
• 后果：触发式测试项的治理成本=0，因为永远不跑；公共 API 契约漂移、性能回退等风险敞口。

P0-19：漂移检测幂等逻辑漏洞 → 假 issue 可永久淹没真实漂移

• 来源：第三轮 C1 攻击（STRUCT-01 核心环节）
• 位置：.github/workflows/governance-drift.yml L36
• 问题：幂等逻辑 EXISTING=$(gh issue list --state open --search "in:title 治理漂移" --json number --jq 'length')，漏洞有三：搜索关键词"in:title 治理漂移"是模糊匹配，任何标题含这四个字的 issue 都会被当成"漂移 issue 已存在"；不过滤 label/author/特定模板；默认分页 30 条，>30 个假 issue 时会漏真实漂移的精确匹配。
• 后果：任何人（public 仓=任何人）可手动创建一个标题含"治理漂移"的假 issue → 后续真实漂移只在假 issue 里 comment → 被淹没不被注意；创建 100 个假 issue → 真实漂移统计性命中，每 3 周才有 1 次能开正确 issue。

P0-20：CI-Workflows v1 tag 可覆盖 → 全组织 gate 投毒通道

• 来源：第三轮 A1 攻击（STRUCT-03 核心环节）
• 位置：release-tags ruleset + CI-1（所有业务仓 gate 引用 CI-Workflows@v1）
• 问题：CI-1 规定所有业务仓的 gate 引用 CI-Workflows@v1，v1 是浮动 tag。release-tags ruleset 禁止 tag 删除/force push/更新，但是 bypass_actors 中包含 OrganizationAdmin（always），admin（唯一 owner randypanding）可以 bypass ruleset：删除 v1 tag → 把 v1 tag 重新指到恶意 commit → 所有业务仓的 gate workflow 下次运行时跑的是恶意代码。
• 后果：若配合 P0-19 漂移 issue 淹没 + P0-14 §8 直推检测被绕，admin 覆盖 v1 tag 的操作不产生漂移报警 → 全组织 gate 投毒无痕迹。

P0-21：CodeQL 排除 .github 仓 → 治理仓脚本后门洞

• 来源：第三轮 A2 攻击
• 位置：rulesets/codeql-gate.json L7 repository_name.exclude = ["AI_Web_School", ".github"]
• 问题：codeql-gate ruleset 明确排除了 .github 仓。.github 仓里有：governance/apply.sh（写 GitHub API 的 bash 脚本，用 org admin token 执行）、governance/drift-check.sh（读 GitHub API）、scripts/gh-app-token.sh（用 App 私钥换 token，掌握 AGENT_APP_SECRET）、scripts/new-repo-init.sh（初始化新仓）。这些全是高权限高价值攻击目标。
• 后果：向 .github 仓的 apply.sh 注入后门（如 curl | bash 窃取 GH_TOKEN）→ CodeQL 不扫 .github 仓 → 不会扫出后门 → owner 下次执行 apply.sh 时 admin 级令牌被窃取。

P0-22：治理仓三大核心仓无灾备 → 单点故障等于组织级灾难

• 来源：第三轮 E1（STRUCT-02）
• 位置：跨三个仓（.github / CI-Workflows / agent-registry）的体系级缺失
• 问题：三个治理仓是整个组织工程体系的"根"，但：无 deletion_protection 设置（apply.sh 未包含）；无冷备镜像仓（跨 org 备份）；无 DR runbook（灾难恢复文档）；无定期恢复演练。
• 后果：删除 CI-Workflows → 所有业务仓 gate workflow 404 → 所有 PR 的 required check 永远 pending → 全组织开发停滞；清空 agent-registry → 所有 agent/team/ADR 消失 → 所有 validate.py 全红、所有 agent 无法启动。

---

五、P1 级问题（31 项）

ID	来源	问题（客观事实）
P1-01	S1-03	new-repo-init.sh 无幂等性 + 无基线锚点产物，后续无法证明仓是否合规初始化
P1-02	S1-04	REPOS.yaml 申报时 gate 不调用 GitHub API 回查实际 visibility/existence
P1-03	S1-05	业务仓 AGENTS.md 中 agent 引用无 AR-2 跨仓校验（validate.py 只在 agent-registry 仓跑）
P1-04	S2-03	ADR status 流转（proposed→accepted）与 PR merge 无绑定
P1-05	S2-04	C1 新增 archetype 时未强制同步更新 expected-state.json capabilities 白名单
P1-06	S2-05	drift-check 9 段缺少"治理仓内部一致性校验"（schema ↔ GOVERNANCE.yaml ↔ validate.py 三方一致）
P1-07	S3-04	事件流存储类型/位置/append-only 保证/AR-5 拦截平台端强制执行均未定义
P1-08	S3-05	6 项 handoff 动作的完成凭证仅靠 retrospective 自述，无每项的 signed hash 收集
P1-09	S3-06	teams/*.yaml 的 status 变更/销毁标记写入权限未限定 governance-core 专用
P1-10	S3-07	AR-5 no-force-push 仅保护 main 分支；feature 分支 force push 无人管
P1-11	S4-03	依赖审批流程仅黑（forbidden）白（允许名单）两态，中间灰区 MIT/BSD 宽松 License 无人审
P1-12	S4-04	testing.yaml 激活项无具体阈值（coverage≥75%? mutation≥60%? race?），CI gate 无法判定 pass/fail
P1-13	S4-05	squash 后 commit message 格式无 CI 校验，合入后脏消息进 main
P1-14	S4-06	CodeQL 扫描结果 dismiss 机制未锁 owner-only，cloudbrid-agent 理论可消告警
P1-15	S4-07	template-service 默认仓设置 "Automatically delete head branches" 开关是否开启未知
P1-16	A1	drift-check §7b 的"线上仓未申报"只做单向（REPOS→GitHub）不做双向差分（GitHub-REPOS）
P1-17	A3	REPOS.yaml exempt 语义与 expected-state.exclude_repos 语义不对齐
P1-18	B1	C1 级 ruleset 变更的 drift-check-local 预检缺 ruleset 语义合法性校验
P1-19	B5	agent status 从 proposed→approved 可自升，validate.py 不校验状态迁移权限
P1-20	C1	ephemeral team.archive_to 指向的 persistent team 无存在性+type+status 校验
P1-21	C2	handoff 数组只有"每项值是 6 枚举之一"校验，无"6 项必须全包含"完整性校验
P1-22	C5	persistent team 被删/归档时，无反向引用保护检查 ephemeral 引用它
P1-23	D1	App 权限形状变更的检测仅 drift-check 周检，无实时 webhook
P1-24	E2	破玻璃回填三件套（PR+ADR+drift issue comment）无自动化关联校验
P1-25	E3	admin 唯一性漂移（§9）会导致所有依赖唯一 admin=owner 的规则归因混乱
P1-26	F1	Actions 白名单（CI-2）只控来源允许，不控是否 pin commit hash（浮 tag 引用 action）
P1-27	G1	typescript when=frontend-isomorphic 的条件无自动化判定 + enforcement 级别未明
P1-28	H3	T-10 mutation weekly 测试分数<60% 时无自动开 issue+指派责任人
P1-29	第三轮 D1	builder 与 test-author 表面不同声明但 prompt 由同一人写，测试放水
P1-30	第三轮 D2	ephemeral handoff 数组只声明 [artifacts-pr] 就可过 validate.py，故意不写 retrospective/adr-write
P1-31	第三轮 E2	agent/skill 引用无固定版本号（@latest / skill:xxx 不带 version）

六、P2 级问题（16 项）

ID	来源	问题（客观事实）
P2-01	S1-06	flows.new_repo 定义的 4 步不完整，步骤 5（首功能 PR）和 6（首版发布）是流程外延伸，无明确门禁
P2-02	S1-07	RL1 只有编号，无具体 release 门禁明细（CHANGELOG/tag 签名/deployment 审批链等）
P2-03	S2-06	C1 评审人数未定义，CODEOWNERS 隐式推导=owner 一人说了算，无副审
P2-04	S2-07	ADR 创建无编号冲突检测，多人同时创建 ADR 编号冲突
P2-05	S3-08	skill-extract 产出的新 skill 初始 status 值未规范（draft/submitted/proposed?）
P2-06	S3-09	handoff 的 artifacts-pr 合并时序不明确（§4 审核前合并=不合格代码进 main）
P2-07	C4	族级独立（不同 model family）是软约束，validate.py 默认不查 models.yaml family
P2-08	D2	credential.github_app 字段不是 enum，可写任意非 cloudbrid-agent 名→运行时才失败
P2-09	D3	capabilities.allow 引用未定义副作用值 fail-closed 的 enforcement 可能是 warning 而非 fail
P2-10	D4	judge archetype 的 as_tool=true（违反 allOf if/then）需回归测试 case 防手写校验漏写
P2-11	G3	license policy 缺少 review-required 灰区层级（LGPL/MPL 等边界 copyleft）
P2-12	S4-08	Hotfix 破玻璃流程步骤/授权时长/回填审计链均未定义，紧急卡死在等 owner
P2-13	S4-09	dependabot auto-merge 对 major/minor/patch 不区分，可能 major 被自动合
P2-14	S3 步骤 B	decision_made 事件的 rationale 摘要格式/长度/结构化要求均未定义
P2-15	第三轮 C3	ADR 与 schema 修改在同一 C1 PR 的鸡生蛋问题，评审流程无变更顺序指导
P2-16	第三轮 F3	Actions 白名单拒绝的错误消息不直接打到 PR review comment

七、P3 级问题（10 项）

ID	来源	问题（客观事实）
P3-01	S1-08	业务路径 CODEOWNERS 无分层、无副审团队
P3-02	S2-08	C1 级变更未明确禁止 auto-merge
P3-03	S2-09	apply.sh 无 plan/apply/state 回滚能力
P3-04	S3-10	decision_made.rationale 无结构化强制（≥2 选项+选择+推理）
P3-05	S3-11	team 声明 count>1 时，事件流无 instance_id 区分实例
P3-06	S4-10	普通业务 PR 的 builder/test-author 独立性适用范围（≥500LOC 阈值）未定义
P3-07	S4-11	PR body 的 agent 声明无模板化格式（agent_id/team_id/risk_level/change_scope）
P3-08	A2	drift-check 不区分 403/404，403 私有仓"无法验证"被当作不存在误报
P3-09	CodeQL	gate 无 CodeQL 超时设置，扫描可致 gate 长时间 pending
P3-10	第三轮	无治理仓定期（如 weekly read-only 审计例会）机制

---

八、三轮演练原始场景索引

轮次	场景编号	场景名称	发现问题数
第一轮	S1	新业务仓创建流程（flows.new_repo 6 步）	8
第一轮	S2	C1 级治理变更（新增 documenter archetype，6 步）	9
第一轮	S3	agent 团队 ephemeral 生命周期（订单重写，5 步）	11
第一轮	S4	普通业务 PR 流程（3500 行 Go 模块+新依赖，7 步）	11
第二轮	A	REPOS.yaml 边界状态（A1~A4，4 case）	4
第二轮	B	治理变更分级边界（B1~B5，5 case）	5
第二轮	C	团队生命周期边界（C1~C5，5 case）	5
第二轮	D	agent 身份与权限边界（D1~D4，4 case）	4
第二轮	E	破玻璃与直推边界（E1~E3，3 case）	3
第二轮	F	Actions 白名单边界（F1~F3，3 case）	3
第二轮	G	语言政策边界（G1~G3，3 case）	3
第二轮	H	测试政策边界（H1~H3，3 case）	3
第三轮	A 类	绕过治理硬防线（CI tag 投毒 / .github 后门 / exempt 扩大化）	3
第三轮	B 类	制造流程死锁（owner 单点 / governance-core 解散归档雪崩 / registry 状态卡死）	3
第三轮	C 类	反馈循环与资源耗尽（漂移 issue 淹没 / dependabot 循环 / PR 乒乓死循环）	3
第三轮	D 类	agent 运行时攻击（builder 自测自建串通 / handoff 选择性遗忘）	2
第三轮	E 类	结构性缺陷（三仓单点灾备缺失 / 版本化真空）	2

[randypanding]

红队二批处置总览（ADR-0016）

79 项报告已逐类独立复核（红队证据≠事实）。处置分四类，伞决策与逐项证据见 ADR-0016：

一、属实——本批已修复（ADR-0016，全部合并）

项	修复
P0-20 / 三大结构性缺陷 3（v1 tag 投毒通道）	drift-check §11 指针完整性（每日校验 vN==最高 vN.x.y，分页聚合 fail-closed，强移 24h 报警）+ CI-Workflows README 发布四步流程（#49/#9）
RB-D5（§10 幽灵 ADR 仅查文件名）	§10 实体性校验升级为内容结构四要素（H1 编号/status/背景/决策节+决策正文，pad 字节绕不过，#50）
RB-B2（漂移评论无限膨胀）	漂移指纹去重（稳定漂移集合哈希，动态字段规范化，#51）
CI-Workflows #6-B（zizmor 死配置）	豁免删除（CIW#7）
声执不一致实例（CIW README 声明 adr-required 无实现）	ci.yml gate 实装 + 三防线（edited 重触发/rename 溯源/3000 上限 fail-closed，CIW#8）+ 三仓同款加固（#53/AR#22）
event.schema 5 类事件覆盖不足（AR#7 审计支柱）	v1.1 扩至 11 类（handoff/approval/credential/budget/team_lifecycle/judge，#47）
AR-6 handoff 措辞与真源不一致	对齐 team-collaboration 单一真源（#48）

二、不属实——证据驳回（红队扫旧树/误读）

• P0-05（族级独立未实现）：validate.py L272-287 已有全局族级比对（含服务型座位逃逸 team 级检查的场景）
• P0-08（CODEOWNERS 全路径→业务 PR 死锁）：误读作用域——.github 仓的 owner-only 是治理仓有意设计（治理之治理 v3 平台锁）；业务仓各有自己的 CODEOWNERS（template-service 模板派生），互不影响
• P0-11（C1 漏列 policy/）：C1 scope = governance/ 整目录（GOVERNANCE.yaml L193 显式含 policy/rulesets/expected-state/脚本）
• P0-13（test_authors 可引 builder 自证自）：validate.py L363-364 已拦"出题者非 test-author 原型"
• P0-14（§8 正则可伪造）：§8 已改唯一权威判据=关联 PR API（注释显式声明"后缀可伪造，不做消息预筛"）
• P0-19（标题模糊搜索）：已改专属 label auto-drift-report 归属判定
• CI-Workflows feat: agent 声明标准与 agent_runtime 治理域 #6-C/D（timeout/CodeQL）：全 workflow 有 timeout-minutes；CodeQL default setup 平台侧 configured（静态 grep 看不见≠缺失）

三、结构性观察——登记为路线图（不属"缺陷修复"scope）

P0-01（建仓前置门禁——§7b 每日未申报检测已兜底 24h）、P0-04（apply 自动触发——org secret 注入 PR 上下文的权衡需单独决策）、P0-06/07（团队运行时销毁/verifier 机制——L2 实现层落地项）、P0-09/16/17/18（advisory 政策的执行引擎——政策分级本就声明 advisory）、P0-22（灾备/多 owner——一人公司现状的结构性上限，GM 体系已知边界）。这些随 L2/L3 层建设分阶段闭环，不在本批治理仓 scope 内强行开洞。

结论

属实项全部修复合并、不属实项证据驳回、结构性项登记。红队两批（ADR-0013/ADR-0016）后，三治仓声执一致性缺口已闭环。关闭本 issue；单项跟进在新 issue 中引用本表。

ADR: ADR-0016