# 平台准入的所有者操作

状态：待所有者执行；本次仅准备，不修改远端分支保护。
依据：根 AGENTS.md「高后果操作双钥匙」要求分支保护变更由用户确认并亲手执行。

## 已核实的差距

2026-10-05 读取 Dev 的 main 分支保护 API，观察到禁直推与陈旧分支拦截开启，
必需状态检查关闭、批准数为 0。读取历史 PR head 的状态 API，实际检查名为
`ci / test (pull_request)`。完整命令与输出由 evidence 工具记录在
`.task/feature-governance-reliability.md`，来源 SELF（只读配置观察，不是门禁负例）。
执行以下步骤前再次读取配置，不能把本记录当长期有效的平台事实。

## 所有者执行

1. 在 Gitea 的 Agent-System-Dev 仓库设置中打开 main 的分支保护，先保留当前配置截图或导出。
2. 确认本次修复 PR 的固定 head 已实际运行 CI，并在提交状态中核对完整检查名。
3. 启用必需状态检查，选择实际的 `ci / test (pull_request)`；保持禁直推及陈旧分支拦截。
   不用仅在合入后运行的 `ci / test (push)` 替代 PR 检查。
4. 批准数暂不随此修复自动调整。若另行启用非作者批准，先确认有可用且符合权限要求的
   独立审核账号；不能把切换 Agent 角色当独立账号，也不能盲设阈值使单账号仓库无法交付。
5. 在隔离的测试 PR 上验证：无检查、检查失败和陈旧候选均不可合入；合法且检查通过的
   PR 可进入所有者审核。记录 head/base、运行链接及实际拒绝结果，标 GATE/REPLAY。

任一判据未满足时暂停合入并保留测试对象。配置调整失败由所有者对照保存的配置恢复；
不把“配置 API 返回成功”写成“门禁已有效”。其他组合仓分别核验，不外推 Dev 的结果。

## CI 信任前提

本次 workflow 修复减少 checkout token 对候选代码的暴露；仍须由平台维护者核验
workflow 来源策略、runner 隔离/销毁及 token 最小权限。仅要求一个可由候选自行修改的
绿色检查，不能证明测试定义或执行身份可信。平台验证结果回填任务主记录与能力矩阵。