---
date: 2026-05-11
tags: [workflow, pr-management, deployment, follow-up, saga-issue]
severity: medium
---

# 触碰部署/CI 的 PR 完工三层：合并 ≠ 部署实测 ≠ follow-up 收口

## 背景

工单 #273（部署 SOP saga）演化成 16 项待办的 tracker，用户提出两个观察：

1. **代码合并** 和 **生产实测落地** 是两个不同时间点的事件，混在同一个 issue 里跟会失焦——出问题时不知道是 "代码错" 还是 "部署时撞了别的事"
2. **follow-up 写在已关闭 issue 评论里** 会随 issue close 而 stale——失去追踪意义

## 三层完工模型

任何触碰**部署 / CI / 服务器配置**的 PR，完工分三层：

| 层 | 闭环依据 | 谁能保证 | 失败时谁修 |
|---|---|---|---|
| L1 合并 | PR review + CI 全绿 + merge develop | reviewer + AI Review + CI workflow | PR 作者 |
| L2 部署实测 | test → UAT → prod 三阶段实跑 + 实际依赖（PG/Redis/Temporal/Nginx）真生效 | 部署阶段触发的人 + 看监控的人 | hotfix / 紧急 PR |
| L3 follow-up 收口 | 衍生工单 / TODO 全部 closed | follow-up 工单 owner | 各 owner 自己 |

L1 不等于 L2 不等于 L3。**纯代码 PR 只走 L1**；**部署/CI PR 必须独立追 L2**；**任何 PR 都可能产生 L3**。

## 工作方式：部署/CI PR 的开工单约定

### 主 PR 提交后立刻开一个"部署后实测"工单

**触发条件**（满足其一即开）：
- 改 `scripts/deploy/`、`scripts/ops/`、`.gitea/workflows/deploy-*.yml`
- 改 `setup-production.sh` 或新机器初始化逻辑
- 改 Nginx / PM2 / Docker compose 生产配置面
- 任何"新机器/新容器首次跑"才能验证的兜底逻辑（citext / temporal namespace bootstrap / ssl-cert 等）

工单 body 模板：

```md
跟踪 PR #N 上线后实测：
- [ ] develop merge → test 自动部署，PM2/容器/Nginx 健康
- [ ] develop → staging → UAT 部署，回归 ok
- [ ] staging → production 部署，关键路径 smoke 通过
- [ ] [PR 特定的核心行为] 实际生效（例：cmd_up 后 citext 自动建出）

实测通过 → 关本工单 + （如果主 issue 因此能闭环）关主 issue。
```

### follow-up 分级，不一刀切

不是所有 follow-up 都值得独立工单。按"价值 × 跟踪频率"分四档：

| 类型 | 处理 | 例子 |
|---|---|---|
| 真实质 follow-up（有具体动作 + 长期重要） | **独立工单** | "抽共享 pg-bootstrap.sh helper"、"Gitea 备份 cron 实施"、"加 OOM 监控告警" |
| 时间锚定（自然到期） | 主 issue 评论 + 日历 | "2026-06-09 删兼容别名" |
| 轻量 UI / IT 操作（独立工单太重） | 主 issue 评论 + ping owner | "Gitea web 改 secret 名"、"IT 加云实例内存" |
| 缓议 / 可能根本不做 | 放掉，不开 | "Gitea 1.26 deprecation"（warn 不阻断） |

判断规则：开工单 = 给自己一个长期 backlog 项；如果一周内不会有人 assign / 排期 / 做，就别开。

### saga issue 主体收尾时直接 close，不死等所有小项

像 #273 这样的 tracker issue：

- 主体 PR 落地后 → saga 体已完成 → 用 `Closes #saga-number` **直接关**
- 剩余项重新分配：真实质 follow-up → 独立工单；时间锚定 → 独立小工单 with due_date；轻量协调 / 缓议 → 放掉

**不要**死规则"保持 open 等所有小项闭环"——剩余项往往是弱跟踪需求（IT 协调、Gitea web 操作、时间到期清理），死等只会让 saga issue longtail 几个月变 stale tracker，反而失去追踪意义。

判断："如果不剪掉这些小项 saga 也能关吗？" 能 → 关，剩下小项独立追。

### 修正记录

本节是对本 learning 初版的修正。初版（同一 commit 里）写"saga 保持 open 直到全部小项闭环"，用户在 #273 收尾时质疑"PR merge 后 saga 该自动关吧？"，复盘后认同——主体已完成 + 剩余项可分配 = saga 该关。死规则保持 open 是过度工程。

## 跟现有规范的关系

- `docs/standards/12-five-meta-rules.md` 规则 4「实测完工」：L2 是规则 4 在 PR 层的具体载体
- `docs/standards/13-pr-description-spec.md`「后续跟进」段：列 L3 follow-up + 链接独立工单
- `CLAUDE.md` PR 批量节奏「高风险路径单独 PR」：本方法论里 L1 已自然单 PR；L2 不变 PR 形态，只是开追踪工单

## 行动项（独立 PR 跟）

把本方法论升级到 `docs/standards/05-development-workflow.md` 作为正式工作流——是 docs/standards 改动，按 CLAUDE.md 规则**单独高风险路径 PR**。本 learning 是 sketch + 实证。

## 来源

工单 [#273](http://43.130.59.228/FFAIWorkspace/workspace/issues/273) saga 收口 PR 讨论（2026-05-11）。