# guardrails/gate-flow.yaml
# GATE 流程门控铁律 — 最高频纠正（33+ 次），违反后果最严重
name: gate-flow
severity: high
trigger: "非平凡任务启动、bug 修复、新功能设计、代码改动"
rule: |
  需求不清不动手 — 列出假设让用户确认
  根因不明不修复（修bug时）— 先查清再改
  方案未定不实现（新功能/L3时）— 先出方案等确认
  评估过影响范围才动手
  涉及代码改动或调研分析的非平凡任务，使用 plan-act-verify skill
  L1 小改动（单文件 <50 行，做错代价低）可跳过 GATE
evidence:
  - "批次1卡片14：33 次纠正都涉及流程问题，是最频繁的纠正类别"
  - "批次1卡片1：用户多次说"先不要改"，Agent 必须立即停下"
  - "批次1卡片8：6 次因"先确认再改"被纠正"
  - "批次2卡片1：评审必须验证最终代码，不能只审方案（5+次）"
  - "批次2卡片4：设计文档-代码一致性审查不可省（4次）"
anti-patterns:
  - "找到根因后直接给出改动点，不等评审"
  - "一次性提多个修复方案不等评审通过"
  - "收到评审意见后直接改，不先确认"
  - "bug 还没查清就开始写修复代码"
  - "需求还不清楚就开始编码"
  - "改了一个文件但没有检查关联影响"
---

## 典型违规场景

### 场景1：跳过根因确认
Agent 看到问题后立刻写修复代码，没有先查清根因。
- 用户："先不要改，你去检查下什么原因"
- 正确：先查清根因 → 汇报发现 → 等确认 → 再改

### 场景2：跳过方案评审
Agent 找到根因后直接给出了 4 个改动点，但应该先发给评审再改。
- 正确：汇报根因 → 提出方案 → 等评审通过 → 再改代码

### 场景3：跳过影响范围评估
Agent 改了状态枚举值但没有检查所有引用点。
- 正确：grep 所有引用点 → 评估影响 → 提出方案 → 确认后改