Repository navigation
贡献规范落地:CONTRIBUTING.md + Docs Gate 门禁 + PR 模板(工程文档不入仓这条目前无机械约束) #137
Description
问题
《GitHub 过程管理规范》里「工程文档不入仓」这一条,目前没有任何机械约束,而且已经在真实发生:
- PR docs: remove migrated module split doc #128 于 2026-08-06 02:35 合并,删掉
docs/module-split.md,说明「内容已迁到 Issue」——做的是对的事。 - PR feat: integrate verified Windup source snapshot #126(源码快照整合,271 文件)把
docs/module-split.md又改了回来,并新增docs/module-split-plan.md、docs/sse-generation-flow.md、docs/superpowers/plans/2026-08-05-*.md(2 份)、docs/superpowers/specs/2026-08-05-*.md(2 份)、根目录api-reference.md。
这不是谁不小心。 改动一大,md 就藏在两百多个文件里,评审时没人会专门去看。规范只写在群消息和营规范原文里,新加入的人和各种 AI agent 都读不到——规范没有落点,就只能靠记性。
提议
三个文件,都在 .github/ 与仓库元文件范围内,不含任何设计或架构内容:
| 文件 | 作用 |
|---|---|
CONTRIBUTING.md |
贡献规范全文,按「CI 自动拦 / 只能靠自觉 / 需要人判断」三层组织 |
.github/workflows/docs-gate.yml |
把「工程文档不入仓」变成 CI 门禁 |
.github/pull_request_template.md |
新开 PR 自动带出的自检清单,各项指向 CONTRIBUTING.md 的小节 |
外加一个新 label user-doc,作为门禁的豁免开关。
为什么规范放 CONTRIBUTING.md 而不是 Issue
「工程文档不入仓」针对的是会分叉的设计描述:文档 commit 进仓后代码继续演进而 md 不动,半年后没人知道哪份算数。贡献规范正好相反——它必须和 CI 配置、目录结构一起演进才有意义。改了 naming.yml 的正则却没同步规范,这个不一致应该在同一个 PR 的 diff 里被看见;放进 Issue 反而制造分叉。
另外它面向的是仓库使用者,CONTRIBUTING.md 是 GitHub 原生识别的文件(开 Issue / PR 时会自动提示),这是它的标准位置。
门禁的设计原则:宁可漏拦,不可误拦
误伤别人正常工作的门禁会被直接关掉,所以它只管两个最明确的位置:
- 拦:
docs/**下的新增与修改、仓库根目录的新增 md - 不拦:删除(把文档搬走正是我们想要的)、子目录里的 README / MODULES.md、允许清单里的路径、打了
user-doc的 PR
子目录 md 故意不拦,因为团队实际约定是「未对齐点显式落 README / MODULES.md,不留聊天记录」。这条和「工程文档不入仓」确有张力,CONTRIBUTING.md 2.1 里把当前口径写成了「记录结论可以入仓,记录论证过程进 Issue」——这个口径是提议的,不是既有规范里的,请评审时确认或修正。
拿全部 15 个 open PR 实测过
不是纸上推演,是把每个 open PR 的真实文件清单喂给门禁逻辑跑了一遍:
| 结果 | PR | 说明 |
|---|---|---|
| PASS | #131 #133 #115 #107 #105 #97 #96 #95 #86 #75 | 零误伤,主力工作全部放行 |
| FAIL | #126 | 拦下 8 项,正是目标 |
| FAIL | #110 #111 | 两个 PR 都把 _PR说明.md 加到了仓库根目录——此前没人注意到 |
| FAIL | #74 #72 | 假警报,见下 |
#74 / #72 那类假警报值得单说:它们「新增」frontend-architecture-v3.md,但那文件 main 上早就有——是分支落后导致 merge-base 把老文件算成新增,rebase 后自动消失。门禁的报错信息里已经写明这一点并给出 rebase 命令,让假警报变成「你该 rebase 了」的有用信号。
建议的推进方式
- 先不要设成 required check。 跑两周看误伤率再谈。现在设 required,feat(quick-start): add workflow-backed creation flow #74 / feat(workflow-run): add frontend execution foundation #72 那种陈旧 base 的 PR 会直接被卡死。
user-doclabel 已建好(区别于 Issue 上的Documented状态标签——一个是 PR 门禁开关,一个是 Issue 生命周期,语义不同不要互相代用)。- 存量问题不在本次处理:根目录
frontend-architecture-v3.md属同类,处理它要单独开 PR。feat(generation): align validated SSE adapter with backend tasks #110 / feat(media): add validated upload adapter #111 的_PR说明.md也请各自作者自行决定。
验收
- 门禁对本 PR 自身放行(
CONTRIBUTING.md与.github/**在允许清单内) - 构造一个含
docs/design.md的 PR 会被拦下,打上user-doc后放行 - 新开 PR 时自动带出模板
Activity
johnnyzhang-eng commentedon Aug 6, 2026
#138 的实现被否,已关闭。评审的四点都成立:
CONTRIBUTING.md混装人读文档与 agent 指令、只加.claude/未覆盖其他 agent、CI 门禁没必要、PR 模板过长且不普适。采纳的替代方向:
.agents目录,claude 这类特例用软链接本 Issue 保持 open,是否按新方向重做待定。
johnnyzhang-eng commentedon Aug 6, 2026
关闭。同 #138:贡献规范、PR 模板、CI 门禁都属于流程工具,不是产品需要,不该占主仓的评审带宽。
规范以营规范原文和评审者意见为准,不另立文档。