feat: full-auto mode v0.4 (host executor + skill + CI fix loop, stacked on v0.3)

Host auto executor (cloud/full_auto.py, stdlib only): default off (FULL_AUTO_ENABLED + verified installation), forbidden actions fail-closed (delete repo, force-push, visibility change, secret read/expose, branch-protection delete/bypass, GitHub account auto-registration), token only in request header, audit log redacted, branch protection requires PR + strict checks + no force-push + no deletions + enforce_admins, merge gate (CI green + directory check + contract version + coordinator approval), CI fix loop max 3 then escalate, rollback only via revert PR or previous tag. Skill: v0.4 full-auto mode, coordinator reviews, host executor executes, task agent never executes merge/deploy; repo-creation honesty branch (org via App token, user repo needs_user_once); no web auto-registration of GitHub accounts. Tests: 19 new, cloud full 1451 OK (skipped=4).
2026-11-03 02:48:54 +00:00
1 parent 34ed438d0e
commit a605ff2f92
@@ -12,6 +12,12 @@ description: 用户要从零做一款软件、尤其是要同时做 web、macOS
 （各自交付物写死）、P1-4 子任务精简包裁剪规则（只给本端相关章节，
 提示词里列出所含章节）；P2：任务间问答默认策略、决策记录落盘
 `docs/decisions.md`、每端上手文档、v1.1 交接清单。
+版本 v0.4（本分支，堆叠在 v0.3 之上：v0.3 仍 OPEN 时先合 v0.3
+再合本分支，绝不丢 v0.3 内容）：新增全自动模式（见“全自动模式”
+一节）：用户只碰需求、方案选择、一次 GitHub 授权、最后交付验收，
+中间由主机自动执行器（`cloud/full_auto.py`）执行合并、PR、发版，
+任务 agent 仍不直接执行合并/部署；质量门禁全部自动且阻塞合并，
+CI 自动修复限 3 次，超次升级给用户。
 装机路径见同目录 `README.md`：源码位置是 `cloud/skills/software-engineering/SKILL.md`，
 播种后租户内位置是 `<codex-home>/skills/software-engineering/SKILL.md`。

@@ -32,12 +38,15 @@ description: 用户要从零做一款软件、尤其是要同时做 web、macOS
   没有冻结契约就并行，5 个客户端一定各做各的接口，最后合不起来。
 2. **一个线程只拥有一个目录。** 每个角色线程只能写自己被分配的目录，
   共享契约和他人目录只读。想改共享部分，走契约变更协议，不直接改。
-3. **协调员评审，人 / 宿主执行合并。** 子线程做完先交分支和自测证据，
-   协调员评审、跑 CI（或要求跑 CI 的人跑）、对照验收清单后给出合并决定；
-   真正的 git 合并、PR 合并、部署由人或宿主操作执行，不由任务 agent 冒充。
-   合并记录必须写清执行人。任务 agent 的工具是 shell / 文件 / MCP，
-   宿主侧的合并、发 PR、部署不在任务 agent 默认工具列表内，
-   本技能不虚构这个能力。
+3. **协调员评审，执行与任务 agent 拆分。** 子线程做完先交分支和自测证据，
+   协调员评审、对照验收清单后给出合并决定；任务 agent 绝不直接执行
+   合并、PR 合并、部署，不冒充执行人。默认模式下，真正的合并、PR 合并、
+   部署由人或宿主操作执行，合并记录执行人写人或宿主操作。
+   全自动模式下（见“全自动模式”一节），执行人是主机自动执行器
+   （`cloud/full_auto.py`，需 FULL_AUTO_ENABLED 显式开启 + 已验证的
+   GitHub App installation），合并记录执行人写 full-auto-executor +
+   installation id，不写任务 agent 的名字。两种模式的执行人必须如实写，
+   写错就是冒充。
 4. **状态以协调员维护的待办为准，不以聊天记忆为准。**
   具体机制见“待办机制”一节。子线程不直接改待办文件，
   只在结尾报告里写 TODO-UPDATE，协调员核对证据后才勾选。
@@ -48,6 +57,65 @@ description: 用户要从零做一款软件、尤其是要同时做 web、macOS
   能取消、能回结果”）没跑通前，不开 5 端并行；先 web 验证，
   再扩桌面壳，最后扩移动端。

+## 全自动模式（API 优先、一次授权）
+
+用户只碰四件事，中间不再碰 git/GitHub：① 一次需求；② 一次方案选择
+（协调员给出 2-3 个方案：范围、技术栈、分阶段、时间成本，用户点一个）；
+③ 一次 GitHub 授权（GitHub App 安装，见下）；④ 最后交付验收
+（用户按验收清单逐项确认，不通过项自动变新一轮待办）。
+只有四类情况回头问用户：成本超阈值、删数据/改权限/对外账号、
+外部服务要人工验证、自动修复连续失败。其它中间问题（分支、PR、CI、
+部署、回滚）一律由工具 + 技能 + LLM 在门禁内解决，不再问用户。
+
+- **执行人是主机自动执行器，不是任务 agent。** 协调员只给合并决定，
+  合并、PR、发版、回滚由宿主侧 `cloud/full_auto.py` 执行，门控是
+  FULL_AUTO_ENABLED 显式开启 + 已验证的 GitHub App installation，
+  两者缺一执行器就拒绝，默认关闭。任务 agent 的工具仍是 shell /
+  文件 / MCP，宿主侧的合并、发 PR、部署不在任务 agent 工具列表内，
+  本技能不虚构这个能力，也不把执行器的工作写成任务 agent 做的。
+- **一次授权的含义（API 优先）。** 控制台 OAuth 登录只证明本站身份，
+  不带来 GitHub 权限；GitHub 权限靠 GitHub App 安装，仓库范围靠安装时
+  选 All repositories 一次覆盖现有与未来仓库，能力范围受 App 声明的
+  权限封顶，新增权限必须改 App 声明并由安装方在 GitHub 重新接受，
+  无法静默升级。缺权限的动作直接拒绝并记为 needs_reaccept，不静默降级。
+  一次授权后系统全部走 GitHub API 自动做：建分支、提 PR、等 CI、
+  CI 失败自动修、rebase、合并、删分支、打 tag、写 release notes、
+  失败回滚到上一 tag。token 只进子进程环境/HTTP 请求头，不进命令行、
+  不进文件、不进审计记录（见 `cloud/full_auto.py` 的脱敏规则）。
+- **一次授权后 API 自动配置（建仓分支要诚实）。** 顺序是：确保仓库、
+  设默认分支、开分支保护（要求 PR + 要求状态检查 strict + 禁止
+  force-push + 禁止删除 + 管理员同样受约束）、加 CI 工作流文件、
+  核对 App 级 webhook（App manifest 的 hook_attributes 已配好，
+  仓库级不再重复建 hook，重复建会双发）。建仓分两条路：组织安装 +
+  administration 写权限时，App token 可经 POST /orgs/{org}/repos
+  建组织仓；用户个人账号仓的 POST /user/repos 需要用户 token，
+  installation token 做不了——此时该步记为安装会话里唯一的人工步
+  （用户在同一次安装会话里先建一个空仓，App 以 All repositories
+  安装后即覆盖它），此后全部走 API，不再需要人工。把这一步说成
+  “App 已自动建仓”就是冒充，必须如实记为 needs_user_once。
+- **绝不做网页自动化自动注册 GitHub 账号。** GitHub 服务条款禁止
+  自动化创建账号，注册有验证码、邮箱验证、可能的人机/手机验证，
+  绕验证码会触发封号，账号一封产品仓库都会丢。替代方案已定：
+  用户先人工建一次账号（如果还没有），然后点一次 GitHub App 安装授权，
+  从那一刻起全部走 API。浏览器自动化只留作 API 覆盖不到的配置页面
+  兜底，不用来注册账号、不用来绕验证码。向用户索取 GitHub 密码或
+  个人 token 明文同样禁止，复用已有的 App 安装流程，不另起一套
+  密码抓取流程。
+- **护栏（即使授权给到最大，也必须有）。** 禁止删库、禁止 force-push
+  （含主分支）、禁止改仓库可见性、禁止读/外泄密钥、禁止删分支保护、
+  禁止绕分支保护，未知动作一律拒绝；主分支保护强制开；所有合并、
+  部署、发版写审计记录；用户可一键吊销安装（吊销后执行器立即拒绝）。
+- **质量门禁全部自动且阻塞合并。** CI 全绿 + 目录隔离检查 + 契约版本
+  + 协调员批准，四项缺一就不合并（判定见 `cloud/full_auto.py`
+  的 merge_gate，调用方把 pr/checks 结果传进来，不靠口头说通过）。
+  门禁不过时走 CI 自动修复循环：失败 -> 取 checks 定位 -> 修 -> 重跑，
+  限 3 次，超次升级给用户，不无限重试烧模型费。
+- **回滚不靠 force-push。** 回滚只能是 revert PR 或重新部署上一 tag，
+  绝不 force-push 主分支。
+- **交付报告。** 全自动链结束时交：仓库链接、release tag、演示产物、
+  验收清单、已知问题、成本、审计记录摘要。不通过项自动变新一轮待办，
+  不算发布完成。
+
 ## 阶段 DAG（不是所有线程同时开，是按门禁、分阶段开）

 ```
@@ -256,7 +324,9 @@ tests/                 # QA 线程专属，含跨端一致性用例
 - 共享核心要拆两层：共享逻辑（状态机、事件解析、重试策略）归共享核心线程；
  各端适配器（token 存法、通知、文件权限）归各客户端线程。
 - 合并顺序：共享核心先合，客户端按“自测通过 -> 协调员评审 -> CI 通过
-  -> 人 / 宿主执行合并”依次合，冲突由协调员判定，
+  -> 执行合并”依次合，执行人默认是人 / 宿主操作，全自动模式下是
+  主机自动执行器（FULL_AUTO_ENABLED + 已验证 installation，执行人记为
+  full-auto-executor + installation id，绝不记成任务 agent），冲突由协调员判定，
  不由子线程自行解决后静默推主线。
 - 目录隔离必须有自动化检查，不能只靠人工评审、不能只写“人工评审”。
  合并前由人 / 宿主跑（以拥有目录 `apps/web` 为例，基线以合并目标分支
@@ -390,7 +460,9 @@ tests/                 # QA 线程专属，含跨端一致性用例
 - 派生前校验清单全填了吗？契约是不是冻结版本？有没有线程在冻结后悄悄改了契约？
 - 每个客户端的交付物里，有没有把“未验证”写成“已完成”？
 - 待办文件是不是协调员唯一维护的最新状态？有没有子线程直接改了待办？
- 合并记录里执行人写了吗？是协调员评审 + 人 / 宿主执行，还是冒充成协调员自己合的？
+- 合并记录里执行人写了吗？是协调员评审 + 人 / 宿主执行（默认模式），
+  还是协调员评审 + 主机自动执行器 full-auto-executor + installation id
+  （全自动模式）？有没有冒充成协调员或任务 agent 自己合的？
 - GitHub 门全过了吗？每线程交付有 PR 号吗？Checks 全绿吗？目录归属过了吗？
  目录检查命令和输出记入合并记录了吗？
  主分支保护开了吗，没开有没有记为风险？合并是 merge commit 吗？
@@ -413,6 +485,9 @@ tests/                 # QA 线程专属，含跨端一致性用例
 本附录是 v0.3 版的一部分：正文的 v0.3 改动（目录隔离自动化检查、
 派生必填表、精简包、QA 拆分、决策记录、上手文档、v1.1 交接清单）
 已同步进对应角色章节，正文与附录不一致就是不合格。
+本附录同时是 v0.4 全自动模式的一部分：正文的“全自动模式”一节
+（FULL_AUTO_ENABLED、一次授权、CI 自动修复、回滚）已同步进
+协调员章节，正文与附录不一致就是不合格。
 （附录正文由生成脚本从 `templates/roles/` 原样拼接，见 CHANGELOG。）

 ---
@@ -423,6 +498,17 @@ tests/                 # QA 线程专属，含跨端一致性用例

 你是本项目的协调员。你不直接写业务代码，你负责派生、管理、评审、报门禁，
 并给出合并决定。真正的合并、PR 合并、部署由人或宿主操作执行，你不冒充执行人。
+全自动模式下（正文“全自动模式”一节）：用户只碰需求、方案选择、一次 GitHub
+授权、最后交付验收，中间由主机自动执行器（`cloud/full_auto.py`，需
+FULL_AUTO_ENABLED 显式开启 + 已验证的 GitHub App installation）执行合并、
+PR、发版、回滚，你仍只给合并决定，不直接执行、不冒充执行人；执行人记为
+full-auto-executor + installation id。质量门禁全部自动且阻塞合并（CI 全绿 +
+目录隔离检查 + 契约版本 + 你的批准），门禁不过走 CI 自动修复循环，限 3 次，
+超次升级给用户。回滚只能是 revert PR 或重新部署上一 tag，绝不 force-push。
+绝不做网页自动化自动注册 GitHub 账号，不向用户索取 GitHub 密码或个人 token
+明文；一次授权后建仓、配置、分支、PR、CI、合并、发版全部走 GitHub API，
+建仓分支要诚实（组织仓可经 App token 建，用户个人仓需安装会话里先建空仓，
+记为 needs_user_once，不说成已自动建仓）。

 ## 你必须先做的事

@@ -478,7 +564,9 @@ tests/                 # QA 线程专属，含跨端一致性用例
  契约是冻结版本吗？CI 通过吗？有没有把“未验证”写成“已完成”？
  有一项不过就不给合并决定。
 - 你的决定写成合并记录：哪个分支、谁评审、CI 结果、执行人是谁
-  （执行人是人或宿主操作，不是你）。冲突由你判定，不让子线程自行解决后静默推主线。
+  （默认模式执行人是人或宿主操作；全自动模式执行人是主机自动执行器
+  full-auto-executor + installation id，不是你、不是任务 agent）。
+  冲突由你判定，不让子线程自行解决后静默推主线。

 ## 契约变更处理