目标
通过对组织的治理改造，让 AI agent 的开发真正做到自动合并——人不再是瓶颈。自动合并不是"把人从 review 里删掉"，而是三次替换：逐 PR 审 diff → 机器判据 + 抽样审计；人按 merge 按钮 → auto-merge + merge queue；事前拦坏改动 → 事后快速回滚。
风险模型：一人公司的自动合并风险不是"坏代码进了 main"，而是"坏代码进了 main 而我三天后才知道"。
执行结构
全部工作拆为 17 张 sub-issue 工作卡，每张卡含：目标、背景、涉及文件、执行步骤、验收标准、预先指定的测试方法（含负向注入测试）、依赖关系。
Phase 1 —— 让合并能发生（约 1 天）
Phase 2 —— 让自动合并变安全（约 1 周）
Phase 3 —— 让治理不再堵人（约 2 周）
优先级与关键依赖
一句话：§3.3（gate 不可被 PR 自我削弱 → #95）→ §6.6（自动 revert → #91）→ §4.1（测试篡改与抑制配额 → #86/#87）→ §2.2（拆死锁 → #83）。前两个是"敢不敢开"的前提，后两个是"开了不炸"的前提。
关键依赖链：
完成定义（DoD）
原始分析（保留存档，点击展开）
我先核实几个平台机制的当前状态（这些直接决定"能不能真的无人合并"），然后给你结论。先给结论：你的门禁已经做对了"防篡改"（身份最小化、ruleset 机器执法、fail-closed、漂移对账），但离"人类不成为瓶颈"还差三类东西——缺一个合并执行器、gate 存在可 fail-open 与自我削弱的缝、以及缺少"事后兜底"来替代"事前人审"。下面按这三类展开，最后给落地顺序。
一、结构性判断：先想清楚要替换的是什么
自动合并不是"把人从 review 里删掉"，而是三次替换：
现在靠人 替换物 门禁需要新增的能力
逐 PR 审 diff 机器判据 + 抽样审计 语义门（测试篡改、diff 覆盖率、抑制标记预算、契约兼容）
人按 merge 按钮 auto-merge + merge queue 合并执行器、死锁消除、卡死侦测
事前拦住坏改动 事后快速回滚 post-merge 验证 + 自动 revert + 熔断
只要缺第三行，前两行就不敢开。一人公司的自动合并风险模型不是"坏代码进了 main"，而是"坏代码进了 main 而我三天后才知道"。
二、合并执行器缺位（最快见效，也最容易踩死锁）
2.1 没人按按钮
你有 required check、有 ruleset，但没有"谁触发 merge"。需要：
仓库级allow_auto_merge = true。注意这是 repo setting 而非 ruleset，最容易漂移，必须进expected-state.json并由 drift-check 对账（你现在对的是 ruleset/required checks/bypass actors，没覆盖 repo settings）。
Agent 开 PR 后立刻gh pr merge --auto --squash。
用 AG-1 的 App token 实测能否 enable auto-merge——这条路径历史上有权限坑，contents+PRs:write通常够，但必须实测而不是假设。
2.2 你的 main-protection 里埋了一个必然死锁
"所有 review thread 必须 resolved"
这条在有人的团队是好规则，在无人值守下是永久 pending 的定时炸弹：CodeQL、任何 review bot、你自己随手留的一条 comment，只要 unresolved，auto-merge 就永远不触发，而没有人会去点 resolve。三选一：
从 required 条件里去掉（推荐，你本来没有第二个人）；
保留，但禁止 bot 使用 review comment 通道——机器意见只走 check run annotation / PR comment，不产生 review thread；
保留，并让 agent 用 GraphQLresolveReviewThread自动清理——但这等于让被审者关闭审计意见，语义上不可接受，不要选这个。
2.3 顺带说明：将来若加 required approvals，approve 必须换身份
GitHub 不允许对自己创建的 PR approve（App 同理）。所以 reviewer 必须是第二个 App 身份，不能是 AG-1。这也顺带带来一个好处（见 §4.2）。
三、gate 的"绿"目前不等于"检查过"（这是无人值守下最危险的部分）
有人 review 时，gate 假绿不致命；无人时，gate 是唯一判据。你有三个 fail-open 面：
3.1 skipped = success（官方行为）
官方文档明确：skipped的 job 上报状态为 Success，即使是 required check 也不阻止合并；neutral/skipped在依赖图中都被当作成功。
你的gatejobneeds: hygiene。任何路径过滤、if:条件、或上游被 skip 的传导，都可能让gate变成"绿但没跑"。修法：
gate 必须是一个aggregator job，带if: always()，并显式断言每个 needs 的result == 'success'（不是靠needs的隐式传导）；
任何paths:/paths-ignore:过滤不要放在 workflow 级（会导致 check 完全不产生 → 永久 pending），要放在 job 级并配 aggregator 显式判定。
3.2 required check 名称是字符串精确匹配
gate是你唯一的 required check。一旦 job 名被改（或 workflow 重构），ruleset 静默匹配不到任何东西 → 变成"零 required check" → PR 可以裸奔合并。而你的 drift-check 现在对账的是 ruleset JSON 文本，JSON 完全正确的同时实际匹配为空。
需要加一节"活体验证"：拉最近 N 个 PR 的 check runs，断言存在名为gate的 check run 且 conclusion 非空。文本对账 ≠ 生效验证。
3.3 最关键：PR 可以在同一个 PR 里削弱审判自己的 gate
pull_request事件使用的是包含 PR 变更的 workflow 定义。所以一个 PR 可以把gate.yml里的 adr-required、gitleaks、断言逻辑掏空，保留 job 名叫gate，然后 required check 照样绿。
你现在唯一的防线是.github/属于 C1 → owner-merge（人）。这正是你想去掉的那个人。所以想要自动合并，必须把审判逻辑移到 PR 改不动的地方，二选一：
A（推荐）：用 org ruleset 的 required workflows 规则，把 gate 指向中心仓（CI-Workflows）的固定 ref。审判逻辑的来源不再是被审仓库自身，PR 无法修改。你已经在"钉 commit hash 复用 hygiene"，把整个 gate 上移是同一思路的完成态。
B：本地gate.yml只做一件事——调用中心仓的 reusable workflow，并由中心仓侧校验"调用者的 gate.yml 哈希 ∈ 允许集合"，不匹配即 fail。
不做这一步，C1 的 owner-merge 就不能取消，人类瓶颈就还在。这是整件事的枢轴。
3.4 顺带：确认 AG-1 权限里没有制造绿灯的能力
contents/issues/PRs:write是对的。额外确认没有checks:write、actions:write——否则 agent 能自建 check run 冒充 gate、或 rerun/删除 run 洗掉红灯。也要在规范里禁止 agent 调用 rerun 类 API。
四、语义门：把"没坏"升级为"做对了"
无人 review 时，agent 最经济的通过策略是改判据而不是改代码。你现在的 gate 几乎不设防这一类：
4.1 必须新增的四道（按性价比排序）
测试篡改检测（我认为这是自动合并的第一必需门）：测试文件删除、断言数量净下降、新增skip/xfail/only/t.Skip、期望值被改写 → 直接红，或强制升级为需 ADR。这是 agent 最经典的作弊路径。
抑制标记预算：# noqa、eslint-disable、type: ignore、.gitleaksignore、coverage exclude、arch-lint allowlist 的净增量计数设硬阈值（比如 ≤3/PR，且累计总量不得上升）。把"逐条人审"换成"配额+越界才叫人"。
diff coverage 门槛（而非全局覆盖率）：本次变更行的覆盖率阈值。全局覆盖率会被大 PR 稀释掉。
契约兼容性：OpenAPI/proto breaking change 检测、DB migration 必须前后兼容且无 destructive DDL（destructive 需 ADR + 回滚脚本）。这类破坏在无人 review 下只能靠机器发现。
补充建议：性能/体积预算（bundle size、依赖数、启动时间）也应设硬阈值——这些是 agent 长期熵增最明显的方向。
4.2 Reviewer agent 只能否决，不能授权
可以加一个独立身份（第二个 App）的 reviewer agent 作为独立 required check，但必须设计成 veto-only：它只能把绿变红，永远不能把红变绿、不能替代任何确定性检查。原因是 LLM reviewer 可被 diff 里的内容 prompt-inject / 自我说服，它的"通过"不构成凭据，但它的"发现问题"是有价值的额外信号。这个不对称性要写进设计约束里。
五、供应链：agent 加依赖的成本你现在没门禁
dep-review有了，但需要具体 policy 而非仅"跑了"：
许可证白名单（拒绝式）；
新依赖最小存在期（如 ≥ 90 天）+ 下载量/维护者阈值——防 typosquat 和 LLM 幻觉包名（agent 幻觉出一个不存在的包名，攻击者抢注，这是真实攻击面）；
新增postinstall/构建期脚本 → 需 ADR；
lockfile 与 manifest 一致性：CI 用 frozen/immutable 模式重现，lockfile 手改即红；
合并后到发布：artifact attestation（provenance 由指定 reusable workflow 签发）+ 部署侧gh attestation verify强制。这样即使 PR 门禁被绕过，发布环节还有第二道独立的门——无人值守下"纵深"比"严格"更重要。
六、无人值守的运行时属性（这部分才是"人不成为瓶颈"的本体）
门禁再严，如果每周有五个 PR 卡住等你手动捞，人还是瓶颈。需要补：
Merge queue：多 agent 并发时会出现"各自对 main 绿、合起来红"。开 merge queue 串行化验证。硬性前提：gate 必须订阅merge_group事件，否则 required check 永不上报、合并直接失败。同时 merge queue 也顺带解决了"分支需 up-to-date"导致的反复手动 update branch。
PR liveness 侦测（加进 drift-check）：auto-merge 已开但 >N 小时未合并 / check pending 超时 / 应有而无 check run → 自动开 issue。你的 drift-check 现在只看治理漂移，不看"流水线卡死"。
auto-fix 尝试上限：agent 修红的循环必须有 N 次上限，超过则关 PR + 开 issue，否则一个坏循环能烧掉你整月 Actions 额度。
额度/成本熔断：Actions 分钟数、token 预算的阈值告警与硬停。一人公司这条是生存问题。
Flaky 治理：假红会逼你手动 rerun——这是最隐形的人类瓶颈。需要 flaky 识别、隔离清单（带过期时间）、有上限的自动重试（且重试次数入账，不允许无声重试到绿）。
post-merge 验证 + 自动 revert：合并后 smoke/canary 失败 → 自动生成 revert PR 并 auto-merge。这是把"事前 review"换成"事后回滚"的核心装置，没有它自动合并不成立。
合并与发布解耦：merge to main 全自动；deploy to prod 用 environment protection / 渐进发布 + 自动回滚。让"无人化"落在 merge，不必强求落在 deploy——这大幅降低你需要承担的风险。
七、治理层：C1 的 owner-merge 是你最大的人类瓶颈
讽刺的是，agent 高频改动的恰恰是scripts/、standards/、.github/——全在 C1，全需 owner-merge。要拆：
拆分判据只有一条：这个变更能否削弱门禁自身？
C1-core（永远人审）：ruleset 本体、bypass actors、CODEOWNERS、App 权限与私钥、secrets/OIDC 信任策略、expected-state.jsonbaseline、门禁豁免路径清单、environment 保护规则、billing 上限。这是你的信任根，显式列成清单，永不自动化。
C1-rest（降级为机器审 + 事后抽检）：scripts/实现细节、standards/措辞、模板。前提是 §3.3 已完成（gate 来源不可被 PR 修改），否则scripts/也能削弱门禁。
配三个软化装置，把人类介入频率从 O(PR) 降到 O(异常)：
ADR 实质化：现在 adr-required 只校验"引用存在且 ADR 实体存在"——这是形式校验，agent 可以引用一个无关 ADR 借壳过关。加机器可解析 front-matter（scope:路径 glob、影响的 control ID、回滚方式），并校验ADR 声明的 scope 必须覆盖 PR 实际 diff 路径。这一步做了，部分 C1 才敢自动合并。
配额制：如"standards 变更 ≤ N 次/周自动合并，超出排队等人"。
Soak / 影子模式：治理规则变更自动合并，但先 warn-only 运行 7 天再 enforce。用"观测期"替代"审批"。
破玻璃那条建议加强：24h 未回填 → 不只是 drift-check 开 issue，而是自动 revert。否则"事后补票"会退化成"永久欠账"。
八、怎么知道自己成功了（门禁自身的 SLI）
自动化程度不能凭感觉，定义并每周看：
自动合并率= auto-merged / total PR（目标 → 高）
人类触碰数 / merged PR（目标 → 0）
门禁逃逸率= (被 revert + 事后由 drift-check/生产发现的问题) / 周（这是你真正的风险指标，必须有分母）
卡死 PR 数、PR 停留 P95
gate 假红率（flaky 逼你介入的次数）
熵增指标：抑制标记净增、覆盖率趋势、新增依赖数
外加一个固定成本的人类环节：每周随机抽样 3 个已自动合并的 PR 做审计。把 review 从 100% 覆盖降为统计抽样，是"人类不成为瓶颈"的正确形态——不是消灭人类判断，而是让它的成本与 PR 数量脱钩。
九、落地顺序
Phase 1（1 天，让合并能发生）
allow_auto_merge开启并进 expected-state + drift-check
拆掉 review-thread-resolved 死锁；实测 App 能 enable auto-merge
gate 改 aggregator +if: always()+ 显式断言 needs（消灭 skipped=success）
drift-check 加：required check 活体存在性验证、PR liveness
Phase 2（1 周，让自动合并变安全）
测试篡改检测 + diff coverage + 抑制标记预算
dep policy（许可证/包龄/postinstall/lockfile frozen）
post-merge 验证 + 自动 revert；auto-fix 上限；额度熔断
merge queue +merge_group触发
Phase 3（2 周，让治理不再堵人）
gate 定义上移到 org required workflows（枢轴，先做这个再谈取消 owner-merge）
C1 拆 core / rest；ADR front-matter + scope 覆盖校验
reviewer agent（独立身份、veto-only）
SLI 面板 + 每周抽样审计
一句话总结：你现在的门禁是"防篡改"做得很好、"防敷衍"几乎没做、"事后兜底"完全没有。想去掉人类，优先级是§3.3（gate 不可被 PR 自我削弱）→ §6.6（自动 revert）→ §4.1（测试篡改与抑制配额）→ §2.2（拆死锁）。前两个是"敢不敢开"的前提，后两个是"开了不炸"的前提。
目标
通过对组织的治理改造，让 AI agent 的开发真正做到自动合并——人不再是瓶颈。自动合并不是"把人从 review 里删掉"，而是三次替换：逐 PR 审 diff → 机器判据 + 抽样审计；人按 merge 按钮 → auto-merge + merge queue；事前拦坏改动 → 事后快速回滚。
风险模型：一人公司的自动合并风险不是"坏代码进了 main"，而是"坏代码进了 main 而我三天后才知道"。
执行结构
全部工作拆为 17 张 sub-issue 工作卡，每张卡含：目标、背景、涉及文件、执行步骤、验收标准、预先指定的测试方法（含负向注入测试）、依赖关系。
Phase 1 —— 让合并能发生（约 1 天）
Phase 2 —— 让自动合并变安全（约 1 周）
Phase 3 —— 让治理不再堵人（约 2 周）
优先级与关键依赖
一句话：§3.3（gate 不可被 PR 自我削弱 → #95）→ §6.6（自动 revert → #91）→ §4.1（测试篡改与抑制配额 → #86/#87）→ §2.2（拆死锁 → #83）。前两个是"敢不敢开"的前提，后两个是"开了不炸"的前提。
关键依赖链：
完成定义（DoD）
原始分析（保留存档，点击展开）
我先核实几个平台机制的当前状态（这些直接决定"能不能真的无人合并"），然后给你结论。先给结论：你的门禁已经做对了"防篡改"（身份最小化、ruleset 机器执法、fail-closed、漂移对账），但离"人类不成为瓶颈"还差三类东西——缺一个合并执行器、gate 存在可 fail-open 与自我削弱的缝、以及缺少"事后兜底"来替代"事前人审"。下面按这三类展开，最后给落地顺序。
一、结构性判断：先想清楚要替换的是什么
自动合并不是"把人从 review 里删掉"，而是三次替换：
现在靠人 替换物 门禁需要新增的能力
逐 PR 审 diff 机器判据 + 抽样审计 语义门（测试篡改、diff 覆盖率、抑制标记预算、契约兼容）
人按 merge 按钮 auto-merge + merge queue 合并执行器、死锁消除、卡死侦测
事前拦住坏改动 事后快速回滚 post-merge 验证 + 自动 revert + 熔断
只要缺第三行，前两行就不敢开。一人公司的自动合并风险模型不是"坏代码进了 main"，而是"坏代码进了 main 而我三天后才知道"。
二、合并执行器缺位（最快见效，也最容易踩死锁）
2.1 没人按按钮
你有 required check、有 ruleset，但没有"谁触发 merge"。需要：
仓库级allow_auto_merge = true。注意这是 repo setting 而非 ruleset，最容易漂移，必须进expected-state.json并由 drift-check 对账（你现在对的是 ruleset/required checks/bypass actors，没覆盖 repo settings）。
Agent 开 PR 后立刻gh pr merge --auto --squash。
用 AG-1 的 App token 实测能否 enable auto-merge——这条路径历史上有权限坑，contents+PRs:write通常够，但必须实测而不是假设。
2.2 你的 main-protection 里埋了一个必然死锁
"所有 review thread 必须 resolved"
这条在有人的团队是好规则，在无人值守下是永久 pending 的定时炸弹：CodeQL、任何 review bot、你自己随手留的一条 comment，只要 unresolved，auto-merge 就永远不触发，而没有人会去点 resolve。三选一：
从 required 条件里去掉（推荐，你本来没有第二个人）；
保留，但禁止 bot 使用 review comment 通道——机器意见只走 check run annotation / PR comment，不产生 review thread；
保留，并让 agent 用 GraphQLresolveReviewThread自动清理——但这等于让被审者关闭审计意见，语义上不可接受，不要选这个。
2.3 顺带说明：将来若加 required approvals，approve 必须换身份
GitHub 不允许对自己创建的 PR approve（App 同理）。所以 reviewer 必须是第二个 App 身份，不能是 AG-1。这也顺带带来一个好处（见 §4.2）。
三、gate 的"绿"目前不等于"检查过"（这是无人值守下最危险的部分）
有人 review 时，gate 假绿不致命；无人时，gate 是唯一判据。你有三个 fail-open 面：
3.1 skipped = success（官方行为）
官方文档明确：skipped的 job 上报状态为 Success，即使是 required check 也不阻止合并；neutral/skipped在依赖图中都被当作成功。
你的gatejobneeds: hygiene。任何路径过滤、if:条件、或上游被 skip 的传导，都可能让gate变成"绿但没跑"。修法：
gate 必须是一个aggregator job，带if: always()，并显式断言每个 needs 的result == 'success'（不是靠needs的隐式传导）；
任何paths:/paths-ignore:过滤不要放在 workflow 级（会导致 check 完全不产生 → 永久 pending），要放在 job 级并配 aggregator 显式判定。
3.2 required check 名称是字符串精确匹配
gate是你唯一的 required check。一旦 job 名被改（或 workflow 重构），ruleset 静默匹配不到任何东西 → 变成"零 required check" → PR 可以裸奔合并。而你的 drift-check 现在对账的是 ruleset JSON 文本，JSON 完全正确的同时实际匹配为空。
需要加一节"活体验证"：拉最近 N 个 PR 的 check runs，断言存在名为gate的 check run 且 conclusion 非空。文本对账 ≠ 生效验证。
3.3 最关键：PR 可以在同一个 PR 里削弱审判自己的 gate
pull_request事件使用的是包含 PR 变更的 workflow 定义。所以一个 PR 可以把gate.yml里的 adr-required、gitleaks、断言逻辑掏空，保留 job 名叫gate，然后 required check 照样绿。
你现在唯一的防线是.github/属于 C1 → owner-merge（人）。这正是你想去掉的那个人。所以想要自动合并，必须把审判逻辑移到 PR 改不动的地方，二选一：
A（推荐）：用 org ruleset 的 required workflows 规则，把 gate 指向中心仓（CI-Workflows）的固定 ref。审判逻辑的来源不再是被审仓库自身，PR 无法修改。你已经在"钉 commit hash 复用 hygiene"，把整个 gate 上移是同一思路的完成态。
B：本地gate.yml只做一件事——调用中心仓的 reusable workflow，并由中心仓侧校验"调用者的 gate.yml 哈希 ∈ 允许集合"，不匹配即 fail。
不做这一步，C1 的 owner-merge 就不能取消，人类瓶颈就还在。这是整件事的枢轴。
3.4 顺带：确认 AG-1 权限里没有制造绿灯的能力
contents/issues/PRs:write是对的。额外确认没有checks:write、actions:write——否则 agent 能自建 check run 冒充 gate、或 rerun/删除 run 洗掉红灯。也要在规范里禁止 agent 调用 rerun 类 API。
四、语义门：把"没坏"升级为"做对了"
无人 review 时，agent 最经济的通过策略是改判据而不是改代码。你现在的 gate 几乎不设防这一类：
4.1 必须新增的四道（按性价比排序）
测试篡改检测（我认为这是自动合并的第一必需门）：测试文件删除、断言数量净下降、新增skip/xfail/only/t.Skip、期望值被改写 → 直接红，或强制升级为需 ADR。这是 agent 最经典的作弊路径。
抑制标记预算：# noqa、eslint-disable、type: ignore、.gitleaksignore、coverage exclude、arch-lint allowlist 的净增量计数设硬阈值（比如 ≤3/PR，且累计总量不得上升）。把"逐条人审"换成"配额+越界才叫人"。
diff coverage 门槛（而非全局覆盖率）：本次变更行的覆盖率阈值。全局覆盖率会被大 PR 稀释掉。
契约兼容性：OpenAPI/proto breaking change 检测、DB migration 必须前后兼容且无 destructive DDL（destructive 需 ADR + 回滚脚本）。这类破坏在无人 review 下只能靠机器发现。
补充建议：性能/体积预算（bundle size、依赖数、启动时间）也应设硬阈值——这些是 agent 长期熵增最明显的方向。
4.2 Reviewer agent 只能否决，不能授权
可以加一个独立身份（第二个 App）的 reviewer agent 作为独立 required check，但必须设计成 veto-only：它只能把绿变红，永远不能把红变绿、不能替代任何确定性检查。原因是 LLM reviewer 可被 diff 里的内容 prompt-inject / 自我说服，它的"通过"不构成凭据，但它的"发现问题"是有价值的额外信号。这个不对称性要写进设计约束里。
五、供应链：agent 加依赖的成本你现在没门禁
dep-review有了，但需要具体 policy 而非仅"跑了"：
许可证白名单（拒绝式）；
新依赖最小存在期（如 ≥ 90 天）+ 下载量/维护者阈值——防 typosquat 和 LLM 幻觉包名（agent 幻觉出一个不存在的包名，攻击者抢注，这是真实攻击面）；
新增postinstall/构建期脚本 → 需 ADR；
lockfile 与 manifest 一致性：CI 用 frozen/immutable 模式重现，lockfile 手改即红；
合并后到发布：artifact attestation（provenance 由指定 reusable workflow 签发）+ 部署侧gh attestation verify强制。这样即使 PR 门禁被绕过，发布环节还有第二道独立的门——无人值守下"纵深"比"严格"更重要。
六、无人值守的运行时属性（这部分才是"人不成为瓶颈"的本体）
门禁再严，如果每周有五个 PR 卡住等你手动捞，人还是瓶颈。需要补：
Merge queue：多 agent 并发时会出现"各自对 main 绿、合起来红"。开 merge queue 串行化验证。硬性前提：gate 必须订阅merge_group事件，否则 required check 永不上报、合并直接失败。同时 merge queue 也顺带解决了"分支需 up-to-date"导致的反复手动 update branch。
PR liveness 侦测（加进 drift-check）：auto-merge 已开但 >N 小时未合并 / check pending 超时 / 应有而无 check run → 自动开 issue。你的 drift-check 现在只看治理漂移，不看"流水线卡死"。
auto-fix 尝试上限：agent 修红的循环必须有 N 次上限，超过则关 PR + 开 issue，否则一个坏循环能烧掉你整月 Actions 额度。
额度/成本熔断：Actions 分钟数、token 预算的阈值告警与硬停。一人公司这条是生存问题。
Flaky 治理：假红会逼你手动 rerun——这是最隐形的人类瓶颈。需要 flaky 识别、隔离清单（带过期时间）、有上限的自动重试（且重试次数入账，不允许无声重试到绿）。
post-merge 验证 + 自动 revert：合并后 smoke/canary 失败 → 自动生成 revert PR 并 auto-merge。这是把"事前 review"换成"事后回滚"的核心装置，没有它自动合并不成立。
合并与发布解耦：merge to main 全自动；deploy to prod 用 environment protection / 渐进发布 + 自动回滚。让"无人化"落在 merge，不必强求落在 deploy——这大幅降低你需要承担的风险。
七、治理层：C1 的 owner-merge 是你最大的人类瓶颈
讽刺的是，agent 高频改动的恰恰是scripts/、standards/、.github/——全在 C1，全需 owner-merge。要拆：
拆分判据只有一条：这个变更能否削弱门禁自身？
C1-core（永远人审）：ruleset 本体、bypass actors、CODEOWNERS、App 权限与私钥、secrets/OIDC 信任策略、expected-state.jsonbaseline、门禁豁免路径清单、environment 保护规则、billing 上限。这是你的信任根，显式列成清单，永不自动化。
C1-rest（降级为机器审 + 事后抽检）：scripts/实现细节、standards/措辞、模板。前提是 §3.3 已完成（gate 来源不可被 PR 修改），否则scripts/也能削弱门禁。
配三个软化装置，把人类介入频率从 O(PR) 降到 O(异常)：
ADR 实质化：现在 adr-required 只校验"引用存在且 ADR 实体存在"——这是形式校验，agent 可以引用一个无关 ADR 借壳过关。加机器可解析 front-matter（scope:路径 glob、影响的 control ID、回滚方式），并校验ADR 声明的 scope 必须覆盖 PR 实际 diff 路径。这一步做了，部分 C1 才敢自动合并。
配额制：如"standards 变更 ≤ N 次/周自动合并，超出排队等人"。
Soak / 影子模式：治理规则变更自动合并，但先 warn-only 运行 7 天再 enforce。用"观测期"替代"审批"。
破玻璃那条建议加强：24h 未回填 → 不只是 drift-check 开 issue，而是自动 revert。否则"事后补票"会退化成"永久欠账"。
八、怎么知道自己成功了（门禁自身的 SLI）
自动化程度不能凭感觉，定义并每周看：
自动合并率= auto-merged / total PR（目标 → 高）
人类触碰数 / merged PR（目标 → 0）
门禁逃逸率= (被 revert + 事后由 drift-check/生产发现的问题) / 周（这是你真正的风险指标，必须有分母）
卡死 PR 数、PR 停留 P95
gate 假红率（flaky 逼你介入的次数）
熵增指标：抑制标记净增、覆盖率趋势、新增依赖数
外加一个固定成本的人类环节：每周随机抽样 3 个已自动合并的 PR 做审计。把 review 从 100% 覆盖降为统计抽样，是"人类不成为瓶颈"的正确形态——不是消灭人类判断，而是让它的成本与 PR 数量脱钩。
九、落地顺序
Phase 1（1 天，让合并能发生）
allow_auto_merge开启并进 expected-state + drift-check
拆掉 review-thread-resolved 死锁；实测 App 能 enable auto-merge
gate 改 aggregator +if: always()+ 显式断言 needs（消灭 skipped=success）
drift-check 加：required check 活体存在性验证、PR liveness
Phase 2（1 周，让自动合并变安全）
测试篡改检测 + diff coverage + 抑制标记预算
dep policy（许可证/包龄/postinstall/lockfile frozen）
post-merge 验证 + 自动 revert；auto-fix 上限；额度熔断
merge queue +merge_group触发
Phase 3（2 周，让治理不再堵人）
gate 定义上移到 org required workflows（枢轴，先做这个再谈取消 owner-merge）
C1 拆 core / rest；ADR front-matter + scope 覆盖校验
reviewer agent（独立身份、veto-only）
SLI 面板 + 每周抽样审计
一句话总结：你现在的门禁是"防篡改"做得很好、"防敷衍"几乎没做、"事后兜底"完全没有。想去掉人类，优先级是§3.3（gate 不可被 PR 自我削弱）→ §6.6（自动 revert）→ §4.1（测试篡改与抑制配额）→ §2.2（拆死锁）。前两个是"敢不敢开"的前提，后两个是"开了不炸"的前提。