# 后续 PR 推进计划

> 用户偏好：每个 PR 多做一些，10 天工作量打包到一个 PR 也 OK。
> 但 CLAUDE.md 红线：架构级 / API 契约面 / DB schema 必须**单独 PR**。

## 推荐的 PR 编排

### **PR-2 — "测试 + 验证 + RBAC 大包"**（~7-8 天）
**Bundle**：A（深度 L2 验证）+ B（L1 集成测试基线）+ C（多审批人流程）+ F（实例 RBAC 细化）

为什么打包：
- 都是测试/验证/权限相关，主题一致
- A 跑出的小 bug 可以在 PR 内即时修
- B 搭好测试基线后，C 的验证可以在 L1 + L2 双层做（更稳）
- F 的权限改动正好用 B 的测试套件验证

不在本 PR：
- D（bullmq）— 架构级单独 PR
- E（通知 UAT）— 依赖 infra，独立做
- G/H/I/J/K — 各自小功能，可以单独成 PR 或合并

**风险**：PR 体量大（30+ 文件、~1500 LOC），review 难度高。
**缓解**：清晰分组 commit，每个 bucket 一组 commit。

---

### **PR-3 — "Webhook bullmq"**（~2 天，必须独立）
**Bucket D**：bullmq 接入是首次，需要单独 review。

---

### **PR-4 — "通知 UAT + 杂项功能"**（~3-4 天）
**Bundle**：E（通知 UAT）+ G1+G2（表单复制/保存关闭）+ H（概览卡片）+ K1（翻译导出）

打包逻辑：都是用户可见的"小功能 + 验证"，体量小，攒一波合理。

不在本 PR：
- G3（条件显示）/ G4（计算字段）/ G5（流程模拟）— schema 级变更，独立
- I（审批引擎补遗）— 业务驱动决策

---

### **PR-5+ — 业务驱动**

按真实需求决定：
- 有人催批量审批 → I1 单独 PR
- 有钉钉接入需求 → 加进 E 或后续 PR
- 有人催条件显示 → G3 独立 PR（schema 变更高风险）
- J/K2 等持续延后

---

## 当前推荐起跑点

**PR-2（测试 + 验证 + RBAC 大包）**

理由：
1. 当前 PR #208 合后状态 🟢，但很多功能"实现 + 浅验"，PR-2 把它们提升到"实现 + 深测 + 集成测试兜底"
2. L1 测试基线越早搭越好，每多一周改动累积，越难补回去
3. RBAC 是合规风险，需要早确认
4. 多审批人流程是"业务核心场景"，不验证就上生产风险高

工时估算 7-8 天，符合"打包多个 bucket 进一个 PR"的偏好。