feat: software-engineering skill GitHub guarantees

- G0/G0.5: repo freeze items (new vs existing, owner/repo, default branch,
  visibility); new-repo creation and first commit are G1 prerequisites.
- One branch per thread (feat/swe/<phase>-<role>-<short>), never push main
  directly, never force-push main; sync main before PR, coordinator
  resolves conflicts, never silently.
- Delivery requires a PR with scope, contract version, test evidence,
  known issues and linked todos/PRD items; no PR number means not done.
- Merge gate: Checks green, directory ownership pass, frozen contract
  version, coordinator approval, no unresolved review comments.
  Branch protection (require PR, require Checks, block direct push) is a
  GitHub repo setting; if unset, coordinator records it as risk and
  enables it, never pretends it is protected. GET /tasks/{id}/pr/checks
  is read-only diagnostics, never reruns or approves.
- Merge commit by default; merge record holds PR number, merge commit
  hash, CI run link and executor; delete remote branch after merge.
- Per-client release tags (e.g. v0.1.0) from merged PRs; rollback is
  revert or redeploy previous tag, never force-push rollback.
- Security: tokens/keys never in code, commits or command lines;
  token only into subprocess env (cloud/pr.py GIT_TOKEN pattern);
  .gitignore covers secrets and local config.
- Main text and appendix (coordinator, client, acceptance) updated in
  sync; appendix travels inside SKILL.md for seeding.
This commit is contained in:
openqj committed 2026-10-30 06:33:25 +00:00
1 parent 878f8de7da
commit 5c1069334a
2 files changed
+158 -1

No files matched your search

+128 -1
View File
@@ -81,7 +81,8 @@ G4 分阶段不是“慢”,是止损:web 先行验证核心链路和契约
| 门 | 名称 | 通过标准 | 没通过怎么办 |
|----|------|----------|--------------|
| G0 | 接单选型冻结 | 客户端清单、目标用户、核心能力、MVP 范围、路线(真原生 / 跨平台壳 + Web 核心)都已由用户确认;**且 agent 类产品必须同时确认执行模型、权限边界、审批模型**(见下) | 不开任何开发线程,继续问 |
| G0 | 接单选型冻结 | 客户端清单、目标用户、核心能力、MVP 范围、路线(真原生 / 跨平台壳 + Web 核心)都已由用户确认;**且 agent 类产品必须同时确认执行模型、权限边界、审批模型**(见下);**且仓库冻结项已确认:仓库是新建还是已有、GitHub owner/repo、默认分支、可见性** | 不开任何开发线程,继续问 |
| G0.5 | 建仓完成 | 新产品已建仓且首 commit 已落默认分支(首 commit 只含仓库骨架,不含业务代码);已有仓库已核对 owner/repo、默认分支、可见性与 PRD 一致 | G1 不开始,先建仓或先改 PRD |
| G1 | PRD 冻结 | PRD 按 `templates/artifacts/prd-outline.md` 写完,用户故事有验收标准,不做清单已写明;**agent 类产品必须有能力边界、失败故事、成本故事三节** | 回产品线程改,不进入设计 |
| G2 | 契约冻结 | API 契约、数据模型、agent 协议、错误码、鉴权方式已定稿,版本号为 v1;**且必须有任务状态机、错误 taxonomy、技术栈表、每端能力矩阵四份冻结物** | 客户端线程不准开工 |
| G3 | 共享核心完成 | 共享类型、API SDK、鉴权与同步逻辑可被客户端引用,有单测;**且有可跑的 mock 服务和契约测试** | 客户端线程等共享线程,不自己各写一套 |
@@ -112,6 +113,12 @@ G4 分阶段不是“慢”,是止损:web 先行验证核心链路和契约
G0 的六问缺一问,G0 就不算过。用户没回复时,协调员等,不按假设推进,
状态保存在待办里。
建仓是 G0 之后、G1 之前的前置任务,不是 G1 里的顺带事:
新产品先建仓,首 commit 只含仓库骨架(README、.gitignore、目录骨架),
不含业务代码,首 commit 落到默认分支后,后续业务工作一律走分支加 PR;
已有仓库先核对 owner/repo、默认分支(以仓库实际 default_branch 为准,不猜)、
可见性与 PRD 一致,不一致先改 PRD 或换仓库,不要边开发边改仓库地址。
## 角色线程矩阵
| 角色 | 线程数 | 负责目录 | 产出 |
@@ -221,6 +228,69 @@ tests/ # QA 线程专属,含跨端一致性用例
检查,确认本分支只改了拥有目录(契约变更经批准的除外)。
在 Docker 任务共享工作目录的环境里,这一步尤其不能省。
## GitHub 保证(每线程一分支、一 PR、一合并门)
本节是 GitHub 层面的硬规则,与上面的目录隔离、协调员评审并行生效,
两者缺一不可。下面的规则同样写进了附录的协调员、客户端、验收章节,
正文与附录不一致就是不合格,发布前必须核对。
### 分支:每线程一分支,绝不直接推默认分支
- 命名沿用 `feat/swe/<阶段>-<角色>-<简称>`,例如 `feat/swe/client-web`。
分支名即任务归属,禁止两个线程共用一个分支改同一目录。
- 绝不直接推默认分支,绝不对默认分支 force-push。
本地落后主线时,先同步主线到自己的分支(fetch 后 rebase 或 merge,
以仓库约定为准,协调员派生时写清用哪一种),再推分支提 PR;
冲突由协调员判定,不静默解决后推。
### PR 交付:没有 PR 号不算完成
- 每线程交付必须含 PR:推分支、建 PR、请协调员评审。
PR 正文必须写清:范围(改了哪个拥有目录)、契约版本、
测试证据(命令与结果)、已知问题、关联的待办项或 PRD 项。
- 没有 PR 号的交付不算完成。协调员收到“做完了但没 PR”时打回补 PR,
不先评审代码。PR 里的评审意见必须逐条处理或明确回复,
未解决的评审意见不能合并。
### 合并门:缺一不可,与主分支保护
- 合并前四项全过:① GitHub Checks 全绿;② 目录归属检查通过
(只改拥有目录,契约变更经批准除外);③ 契约版本是冻结版;
④ 协调员评审通过,且无未解决评审意见。有一项不过就不合并。
- CI 怎么查:用只读方式查,例如本平台的 GET /tasks/{id}/pr/checks。
它是只读诊断,绝不重跑检查、不批准、不合并;还没建 PR 时它会 409
(查无可查),这时先补 PR,不要把它当成 CI 通过。
- 主分支保护(GitHub 仓库设置,不是本平台代码能替你开的):
要求 PR、要求 CI 通过、禁止直接推。目标仓库没开保护时,
协调员要在决策记录里写明风险并去开通,不能假装已保护,
不能靠“大家自觉”代替保护。
### 合并方式与合并记录
- 默认 merge commit,不用 squash 或 rebase 改写分支历史口径
(仓库另有约定且协调员记录在案时除外)。
- 合并记录必须含:PR 号、合并提交 hash、CI 运行链接、执行人。
执行人是人或宿主操作,不是“协调员任务自己合”。
- 合并后删远程分支(本地分支同步清理),避免旧分支被误复用;
删分支前确认合并提交已在主线。
### 发布与回滚:按端打 tag,绝不 force-push 回退
- 按端发布时打 tag,例如 v0.1.0;发布说明从已合 PR 汇总,不凭记忆重写。
- 回滚是 revert 对应 PR,或重部署上一个 tag;绝不是 force-push 回退主线。
回滚后要重新走合并门(CI、评审)才能再发布,不要回滚完直接推。
### 安全:密钥绝不进代码、commit、命令行
- 密钥、口令、token 绝不进代码、commit、命令行、PR 正文、日志。
需要调用 GitHub 时,token 只进子进程环境(本仓库 cloud/pr.py 的做法
就是 token 只进子进程环境变量 GIT_TOKEN,不进命令行参数、不进远端 URL),
不要把 token 写进示例命令。
- 新产品仓库的 .gitignore 必须覆盖密钥文件与本地配置文件
(例如 .env、本地凭据、本地配置),首 commit 前由协调员检查 .gitignore 在位;
已发现密钥进了 commit 时,按仓库的密钥轮换流程处理并记录,
不靠改写历史掩盖(已公开的历史不能靠改写抹掉)。
## 测试与验收
- 每个客户端线程交付前必须自测:单元测试 + 对接契约的集成测试
@@ -271,6 +341,11 @@ tests/ # QA 线程专属,含跨端一致性用例
- 每个客户端的交付物里,有没有把“未验证”写成“已完成”?
- 待办文件是不是协调员唯一维护的最新状态?有没有子线程直接改了待办?
- 合并记录里执行人写了吗?是协调员评审 + 人 / 宿主执行,还是冒充成协调员自己合的?
- GitHub 门全过了吗?每线程交付有 PR 号吗?Checks 全绿吗?目录归属过了吗?
主分支保护开了吗,没开有没有记为风险?合并是 merge commit 吗?
合并记录里 PR 号、合并提交 hash、CI 运行链接齐了吗?合并后删远程分支了吗?
发布打 tag 了吗,回滚方案是 revert 或重部署上一 tag、而不是 force-push 吗?
密钥进代码、commit、命令行了吗?.gitignore 在首 commit 前检查了吗?
- 验收清单是不是用户亲手确认的?有没有一项是协调员替用户勾的?
- 分阶段走了吗?G3.5 没过就开了 G4b / G4c 吗?
有一项为否,就停在当前门禁,不进入下一阶段。
@@ -353,6 +428,35 @@ tests/ # QA 线程专属,含跨端一致性用例
---
## GitHub 保证(协调员)
- 建仓:G0 之后、G1 之前做。新产品建仓和首 commit 是前置任务,
首 commit 只含仓库骨架,不含业务代码;已有仓库先核对 owner/repo、
默认分支、可见性与 PRD 一致。仓库冻结项(新建还是已有、owner/repo、
默认分支、可见性)缺一项,G0 不算过。
- 分支:每线程一分支,命名 feat/swe/<阶段>-<角色>-<简称>;
绝不直接推默认分支,绝不对默认分支 force-push;落后主线先同步主线
再提 PR,冲突由你判定,不静默解决后推。
- PR 交付:没有 PR 号不算完成。PR 正文必须有范围、契约版本、
测试证据、已知问题、关联待办或 PRD 项;评审意见逐条处理,
未解决的评审意见不能合并。
- 合并门:GitHub Checks 全绿、目录归属检查通过、契约版本是冻结版、
你评审通过且无未解决评审意见,四项缺一不可。
CI 用只读方式查,例如 GET /tasks/{id}/pr/checks,它绝不重跑检查、
不批准、不合并;无 PR 时它会 409,先补 PR。
- 主分支保护:要求 PR、要求 CI 通过、禁止直接推,这是 GitHub 仓库设置,
不是本平台代码能替你开的。没开保护时记为风险并去开通,不假装已保护。
- 合并记录:默认 merge commit;记录必须含 PR 号、合并提交 hash、
CI 运行链接、执行人(人或宿主操作,不是你自己合);
合并后删远程分支,删前确认合并提交已在主线。
- 发布与回滚:按端打 tag,例如 v0.1.0,发布说明从已合 PR 汇总;
回滚是 revert 对应 PR 或重部署上一个 tag,绝不是 force-push 回退。
- 安全:密钥、口令、token 绝不进代码、commit、命令行、PR 正文、日志;
token 只进子进程环境(cloud/pr.py 的做法:只进子进程环境变量 GIT_TOKEN,
不进命令行参数、不进远端 URL);新仓库首 commit 前检查 .gitignore
覆盖密钥文件与本地配置文件。
## 附录角色:01-product-manager(来源 templates/roles/01-product-manager.md)
# 角色模板:产品经理(1 个线程)
@@ -542,6 +646,19 @@ tests/ # QA 线程专属,含跨端一致性用例
---
## GitHub 交付(客户端)
- 你的工作只在自己的分支上做,分支名由协调员给定,
格式 feat/swe/<阶段>-<角色>-<简称>;绝不直接推默认分支,
绝不对默认分支 force-push;落后主线先按协调员写清的方式同步主线再提 PR。
- 交付必须含 PR 号:推分支、建 PR,正文写清范围(你的拥有目录)、
契约版本、测试证据、已知问题、关联待办或 PRD 项。没有 PR 号不算完成。
- 合并门由协调员判定:Checks 全绿、目录归属通过、契约版本是冻结版、
评审通过且无未解决意见;你不自己合并、不绕过评审推主线。
- 安全:密钥、口令、token 绝不进代码、commit、命令行、PR 正文;
需要调用 GitHub 时 token 只进子进程环境,不写进示例命令。
## 附录角色:05-backend(来源 templates/roles/05-backend.md)
# 角色模板:后端 / API(可选,1 个线程)
@@ -651,6 +768,16 @@ iOS / Android / Mac 在 Linux 主机上编不出来时,你的结论写
---
## 按端发布与回滚(验收)
- 发布按端分别做:每端发布时打 tag,例如 v0.1.0;
发布说明从已合 PR 汇总,不凭记忆重写;发布记录里写清端、tag、PR 号、执行人。
- 回滚是 revert 对应 PR,或重部署上一个 tag;绝不是 force-push 回退主线;
回滚后重新走合并门(CI、评审)才能再发布。
- 合并记录复核:PR 号、合并提交 hash、CI 运行链接、执行人缺一项,
验收就不算完成;已删远程分支的要确认合并提交已在主线。
## 附录角色:08-shared-core(来源 templates/roles/08-shared-core.md)
# 角色模板:共享核心(G3,1 个线程)