安全边界和保护等级
Section titled “安全边界和保护等级”代码平台和项目平台
Section titled “代码平台和项目平台”| 代码平台（GitHub） | 项目平台（Multica） | |
|---|---|---|
| 负责 | 合并规则、自动检查、部署 | 任务状态、角色配置、触发和定时 |
| 谁能改 | 只有人 | agent 和人 |
能不能合并只由代码平台判断，项目平台的状态只用来调度，因为 agent 能改的状态拦不住 agent。
哪些是硬约束
Section titled “哪些是硬约束”| 约束 | 由什么保证 | agent 能绕过吗 |
|---|---|---|
| 写代码的不能评审自己 | Implementer、Reviewer 用两个不同的 GitHub App；GitHub 不允许作者批准自己的 PR | 不能（前提是两个 App 不同） |
| 不过检查不能合并 | 规则集的必需检查 check，只认 GitHub Actions 上报的结果（integration_id 15368），防止用 API 伪造状态 |
不能 |
| 新提交会作废旧批准 | 规则集：dismiss stale reviews、require approval of the most recent push | 不能 |
| 规则文件只能由人批准（Implementer 仅在任务要求时才提 PR，前提是开启 Require review from Code Owners） | CODEOWNERS 保护 .github/、.autoteam/、Makefile、.jscpd.json，规则集要求 Code Owner 审批 |
不能 |
| 任何人都不能豁免 | 规则集的 bypass list 留空，管理员也不例外 | 不能 |
| 强推、删主干 | 规则集：restrict deletions、block force pushes | 不能 |
| PR 不超过 400 行、重复代码不超标 | gate.yml 里的检查（阈值在受保护的文件里） | 不能 |
哪些只是指令约束
Section titled “哪些只是指令约束”| 约束 | 风险 | 怎么发现 |
|---|---|---|
放行（backlog 改成 todo）分级：AUTOTEAM_AUTO_APPROVE=on 时，Planner 只能自主放行不碰受保护路径、不涉及凭据/权限/部署/回滚/删数据/对外发布、改动小、不是新功能或方向调整的任务，每天不超过 AUTOTEAM_AUTO_APPROVE_MAX_PER_DAY 个，并留 【自主放行】 评论；其余只有人能放行 |
agent 也有改状态的权限；Planner 可能把不满足条件的任务判成满足 | 每日摘要里的批准核对：没有 【自主放行】 评论却被 agent 放行的、或自主放行了受保护路径的，单独列出 |
| Planner 不写代码 | 它的机器上有代码 | Planner 用只读 + Actions 的 token（planner 账号） |
| 验收要看线上真实结果 | Planner 可能偷懒只看代码 | 评论里必须贴证据；人每周抽查 |
| 打回、验收失败到上限就升级 | agent 可能忘记 | loop-guard.sh 从记录里算，巡检重新计算 |
autoteam github 会按仓库的归属和套餐判断能做到哪一级：
| 等级 | 仓库 | 规则集 | 自动合并 | 合并队列 | 谁来合并 |
|---|---|---|---|---|---|
| full | 组织的公开仓库；组织私有仓库 + Enterprise Cloud | 有 | 有 | 有 | 平台：检查通过后自动合并，合并队列保证合并前在最新主干上重跑检查 |
| standard | 个人公开仓库；个人 Pro、组织 Team 的私有仓库 | 有 | 有 | 没有 | 平台：检查通过后自动合并 |
| none | GitHub Free 的私有仓库 | 没有 | 没有 | 没有 | Reviewer 批准后，等检查全绿自己合并（降级模式） |
- standard 没有合并队列：两个 PR 各自检查通过、先后合并后，主干上的组合可能是坏的。靠合并后的部署、Planner 验收和巡检兜底。
- none 是降级模式：所有“硬约束”都退化成指令约束，
autoteam doctor会一直标黄提醒。适合先试用，正式用请把仓库改公开、升级 Pro，或迁到 Team 套餐的组织，再运行一次autoteam github --apply。
谁来合并：三种模式
Section titled “谁来合并：三种模式”保护等级说的是平台能提供什么，合并模式说的是在这个前提下 Implementer 和 Reviewer 各做什么。.autoteam/scripts/merge-mode.sh 每次开 PR 和批准前当场判断，依据是这个分支上实际生效的规则（repos/{repo}/rules/branches/{branch}，规则集和老的分支保护合并后的结果）加上仓库有没有开自动合并：
| 输出 | 触发条件 | Implementer | Reviewer | 检查能绕过吗 |
|---|---|---|---|---|
platform |
有必需检查，且规则集要求至少 1 个审批 | 正常开 PR + gh pr merge --auto --squash，并用 merge-status.sh 核对确实开了 |
gh pr review --approve，然后什么都不用做 |
不能 |
staged |
有必需检查，但不要求审批（单身份只能这样） | 开 draft PR，不开自动合并 | 批准后 gh pr ready 再 gh pr merge --auto --squash |
不能 |
reviewer |
没有必需检查，或仓库没开自动合并 | 不执行任何 gh pr merge |
等检查全绿后 gh pr merge --squash --delete-branch |
能（只剩指令约束） |
Implementer 这一列不用手工照着做：交付时跑 .autoteam/scripts/open-pr.sh，它先跑 merge-mode.sh，按上表开 PR；platform 下开自动合并后用 merge-status.sh 核对，none 就重试一次，仍不行返回非 0 并打印原因。返工时 open-pr.sh <PR> 只核对、补开。漏开的兜底只有一处：巡检发现已批准、检查通过但 merge-status.sh 输出 none，提及 Implementer 重跑这个脚本。
两个容易踩的坑：
- 没有平台闸门时
gh pr merge --auto不报错，而是立即合并，绕过评审和检查。端到端验证时真的发生过：PR 创建 7 秒后就被合并了。所以reviewer模式下 Implementer 绝对不碰 merge 命令。 - 只有必需检查、不要求审批，等于 Reviewer 没有闸门。这是单身份的必然处境：GitHub 不允许作者批准自己的 PR，审批数只能设 0，于是检查一绿平台就合并，Reviewer 来不及看。
staged模式用 draft PR 补上这一环——draft 本来就不能开自动合并，Reviewer 不gh pr ready，谁都合不了，而检查仍然由平台强制。它不是硬约束（Implementer 理论上可以自己 ready），但比“一绿就合”强得多。
单账号试用模式
Section titled “单账号试用模式”还没建好 GitHub App 时，Implementer 和 Reviewer 只能用同一个身份，GitHub 不允许它批准自己的 PR。autoteam github --apply --trial 会把规则集改成不要求审批（也不要求 Code Owner 审批和最后一次推送审批），其余规则不变：
- Reviewer 的
gh pr review --approve会失败，指令里要求它改用评论评审，并以【批准】或【阻塞】开头，打回次数照样能统计； - 合并模式落到
staged：Implementer 开 draft PR，Reviewer 批准后才gh pr ready放行。检查依然是硬闸门，但“评审过了才能合”这一条退化成指令约束； - 评审独立性不再由平台保证，
autoteam doctor会标黄； - 建好 App 后：App ID 写进 autoteam.conf 的
AUTOTEAM_IMPLEMENTER_APP_ID/AUTOTEAM_REVIEWER_APP_ID，私钥放到各自机器，然后不加--trial重新运行autoteam github --apply。模式会自动变成platform，不需要改任何指令。
规则由包版本固定（指令不落盘）
Section titled “规则由包版本固定（指令不落盘）”四个角色指令、autopilot 的 runbook、planner-mcp.json 不写进你的仓库：autoteam multica --apply 直接读 autoteam 包内的版本。这样做的结果：
- 改规则只有两条路，都要人批准：一是
autoteam eject把某一份落到.autoteam/instructions/，它在 CODEOWNERS 保护的目录里，改动走 PR 由人批准；二是升级 autoteam 版本，.autoteam/.lock.json中的版本号变更本身受 CODEOWNERS 保护，也要人批准。agent 没有第三条路：仓库里没有一份“指令文件”可以顺手改。 - 不会漂移：仓库里不再有一份可能和 Multica 不一致的指令副本，能漂移的只剩 eject 出来的那几份，
autoteam doctor会拿 Multica 里的文本和生效文本比对。 - 代价：升级版本时，指令文本的变化不再出现在 PR 的 diff 里，只剩版本号。缓解：升级 PR 的描述里贴上两个版本之间指令文本的差异（在 autoteam 仓库里
git diff <先前 tag> <当前 tag> -- skills/autoteam/instructions）再让人批准；已 eject 的那几份用autoteam eject --diff <名字>对比包内的新版本；autoteam doctor在同步后核对 Multica 里的文本和生效文本一致。autoteam upgrade不打印指令的差异——包里只带当前版本，没有先前版本可比。
- 每个 App 只装本仓库、权限给到最小（见第 1–3 步 GitHub）。注意 Reviewer App 必须有 Contents 写权限，否则它的批准不计入必需审批数；「评审者不能推代码」因此只是指令约束。
- App 私钥是长期凭据，只放需要它的那台机器上；不同角色跑在不同机器（至少不同系统用户或容器），避免互相读到私钥。泄露了到 App 设置里删掉那把 key 重新生成，已铸出的 token 最多 1 小时后失效。
- Multica agent 的
custom_env（registry 的env_file）以明文存在 Multica 服务端，不要放生产数据库密码这类高价值的长期凭据。 - 部署 webhook 地址里带凭据，只存在 GitHub secret
MULTICA_DEPLOY_HOOK里，autoteam 不会打印它；泄露了就autoteam multica --apply --rotate-webhook重新生成。