一句话

给每次变更配一条不可跳过的质量门禁流水线，并把 CI 失败反馈回 agent；附带部署策略与周边自动化。

何时用

• 适合：新建或改动构建/部署流水线；把 lint、类型、测试、构建做成 CI 门禁；配置部署策略。
• 不适合：本地一次性脚本；项目还没有可自动化的检查时先补测试。

怎么用

给这个仓库配 CI：PR 上跑 lint、类型检查、单测和构建，失败要拦住合并

1. 按质量门禁排流水线：lint、type check、unit tests、build、integration、E2E（可选）、security audit、bundle size。
2. 用 GitHub Actions 模板起步；含数据库集成测试和 E2E 的写法都有示例。
3. 把 CI 失败输出喂回 agent，让失败可自动定位和修复。
4. 选部署策略：preview deployment、feature flag、staged rollout，并写回滚方案。
5. 按需加 Dependabot/Renovate、build cop 角色、PR checks；再做缓存与矩阵等 CI 优化。

产出

• .github/workflows/ 下的流水线配置、部署与回滚流程、依赖更新自动化。

要点与坑

• 硬规则：任何门禁不许跳过。lint 挂就修代码，不许关规则、不许 skip 测试。
• 便宜的检查前置跑，贵的放后面；CI 优化一节讲缓存和并发上限。
• 与 addy-shipping-and-launch 分工：这里管常设流水线，那里管单次发布的检查单。

关联

• 上游：addy-test-driven-development · 下游：addy-shipping-and-launch · 搭配：addy-observability-and-instrumentation
• 所属：00-addy-概览 · 工作流：W7-交付与运维循环