Lane 工作流
从 PR 进入到生产回滚的完整链路
- 配置 Lane
定义阶段、源规则（feature/*、fix/*）、合并路由与汇聚闸门
- GitHub App 安装
按仓库授权，颁发短期安装令牌
- PR 流入
Webhook 实时更新 Lane 看板
- 闸门决策
domain.ts 按 GitHub 事实评估评审/检查/可合并性
- 阶段推进
依赖阶段需前置合并与后置闸门全部成功
- 部署追踪
部署记录、环境状态与健康检查
- AI PR 草稿
24 小时草稿与流式生成，密钥仅会话
- Web Push
关闭标签页也能收到状态送达
- 确认回滚
显式用户操作，调度并记录审计事件
为什么是 PR Helper
不是看板，不是合并队列，而是对完整发布流程负责
GitHub 是权威
GitHub 始终是分支保护、评审、检查、可合并性、Actions 与环境保护的权威。PR Helper 永不在 UI 状态中绕过 GitHub 的拒绝。
Lane 编排
一个 Lane 包含线性阶段、独立合并路由、动态源规则与汇聚闸门。依赖阶段需前置合并与后置闸门全部成功；独立路由可不等更早的线性阶段。
真实事实链
闸门决策基于真实的 GitHub Checks、Reviews、Mergeability、部署记录与健康检查，而非 Agent 或 UI 的自述。未执行的验证不得标记为通过。
显式生产操作
生产合并与回滚都是显式用户操作。无单独获批的设计前，不添加自动生产合并或回滚。回滚调度记录完整审计事件。
实时 + 对账
Webhook 提供实时速度，定时对账保证正确性。Supabase 持久化工作流与监控状态，有序迁移是 schema 唯一事实来源。
凭据安全
GitHub App 密钥与短期安装令牌保留在服务端模块 api/_lib/ 下，永不暴露给浏览器。AI 密钥仅会话级，未设计加密前不持久化。
与相邻产品对比
PR Helper 不与任务看板工具比任务管理，也不与部署托管平台比部署速度
| 维度 | PR Helper | 任务看板工具 | 合并队列工具 | 部署托管平台 | 人工协调 |
|---|---|---|---|---|---|
| 管理单位 | 跨仓库发布工作流 | 任务/issue | PR 合并顺序 | 部署托管 | 电子表格/IM |
| 平台原生 | 是，原生 App + Webhook | 是 | 是 | 部分 | 否 |
| 跨仓库 Lane | 是，线性/独立/汇聚 | 有限 | 否 | 否 | 临时拼凑 |
| 汇聚闸门 | 是 | 否 | 否 | 否 | 人工核对 |
| 闸门决策来源 | 仓库事实链 | issue 状态 | 合并队列状态 | 部署状态 | 人工判断 |
| Web Push 送达 | 是，关闭标签页 | 有限 | 否 | 有限 | 否 |
| 确认回滚 | 显式用户操作 + 审计 | 否 | 否 | 即时回滚 | 人工回滚 |
| AI PR 草稿 | 是，24h + 流式 | 否 | 否 | 否 | 否 |
责任边界
透明划分 GitHub 权威与编排层职责，建立信任
GitHub 权威
- →分支保护规则与 Rulesets（事实来源）
- →评审指派与审批决策
- →Actions、Checks 与环境保护
- →可合并性与合并方式
- →仓库与 GitHub App 安装范围
- →生产合并与回滚的最终决策
PR Helper 负责
- →跨仓库的 Lane 状态编排与推进
- →从 GitHub 事实评估闸门决策
- →实时 Webhook 摄入与定时对账
- →关闭标签页的 Web Push 送达
- →AI 生成的 PR 草稿（密钥仅会话）
- →部署追踪、健康检查与审计事件
- →仅在用户明确确认后调度回滚
PR Helper 可以保证流程与证据完整，不能替代 GitHub 的分支保护与人工审批。
产品宪法摘录
约束平台行为的核心原则
GitHub 是权威
GitHub 始终是分支保护、评审、检查、可合并性、Actions 与环境保护的权威。永远不在 UI 状态中绕过 GitHub 的拒绝。
显式生产操作
生产合并与回滚都是显式用户操作。无单独获批的产品与安全设计前，不添加自动生产合并或回滚。
外部事实高于自述
闸门决策基于真实的 GitHub Checks、Reviews、Mergeability、部署记录与健康检查，而非 Agent 或 UI 的自然语言总结。
实时 + 对账
Webhook 提供实时速度，定时对账保证正确性。两者并存，缺一不可。
凭据不落浏览器
GitHub App 密钥与安装令牌保留在服务端模块 api/_lib/ 下。AI 密钥仅会话级，未设计加密前不持久化。
迁移即事实
数据库变更只能新增有序迁移文件，不在运行时执行 DDL，不编辑已应用的迁移。
常见问题
关于 GitHub 权威、回滚安全与自动化边界的关键问题
PR Helper 是什么？
PR Helper 是 GitHub 优先的 PR / Release 控制塔，跨仓库协调真实的 Pull Request 与部署工作流。一个 Lane 可包含线性阶段、独立合并路由、动态源规则与汇聚闸门，例如 feature/* + fix/* → dev → main。它不是看板，也不是合并队列，管理的最小单位是发布工作流。
PR Helper 会绕过 GitHub 分支保护吗？
不会。GitHub 始终是分支保护、评审、检查、可合并性、Actions 与环境保护的权威。PR Helper 永远不在 UI 状态中绕过 GitHub 的拒绝。闸门决策基于真实的 GitHub Checks、Reviews 与 Mergeability，而非自述。
生产合并与回滚是自动的吗？
不是。生产合并与回滚都是显式用户操作。在没有单独获批的产品与安全设计之前，不会添加自动生产合并或自动回滚。回滚调度只在用户明确确认后执行，并记录完整审计事件。
GitHub 凭据与安装令牌存在哪里？
GitHub App 密钥与短期安装令牌保留在服务端模块 api/_lib/ 下，永不暴露给浏览器代码。AI API 密钥仅存于会话，在显式设计加密与密钥管理之前不会持久化到服务端。
工作流与监控状态如何持久化？
工作流与监控状态持久化到 Supabase Postgres（通过 DATABASE_URL），有序迁移位于 db/migrations/，是数据库 schema 的唯一事实来源。Webhook 加上定时对账保证实时性与正确性；Web Push 需要 Service Worker、VAPID、订阅与服务端对账同时就绪。
什么是 Lane？独立路由可以不等前面的阶段吗？
Lane 是一个项目编排单元，包含线性阶段、独立合并路由、动态源规则与汇聚闸门。依赖阶段必须等所有前置阶段合并且其后置检查/部署闸门成功后才能推进；独立路由无需等待更早的线性阶段即可推进。
PR Helper 与任务看板工具、合并队列工具、部署托管平台有什么区别？
任务看板工具管任务，合并队列工具管 PR 合并顺序，部署托管平台管部署。PR Helper 管理跨仓库的完整发布工作流：用 Lane 编排 PR 流入、闸门决策、阶段推进、部署追踪、健康检查与确认回滚，并以仓库事实为唯一依据。