Not every improvement should become a gate. Gates add friction. The question is whether the friction is worth the protection.
The goal is to find the sweet spot: enough enforcement to prevent repeated mistakes, not so much that it slows down legitimate work.
The Rubric
Use this rubric to evaluate whether an improvement should tighten from guidance to enforcement.
Should this become a gate?
Check the criteria that apply to this improvement.
Keep as improvement task
Address it, but enforcement overhead may not be worth it yet.
Types of Gates
Advisory gates
Warn but don't block. Good for new rules where you're still calibrating the threshold. The agent sees the warning, humans see it in logs, but work continues.
Blocking gates
Fail the build, commit, or deploy. Use for high-confidence rules with clear remediation. The failure message should tell you exactly what to fix.
Human-in-the-loop gates
Require explicit approval to proceed. Good for high-stakes changes where automation can flag but shouldn't decide. Examples: schema migrations, permission changes, dependency updates.
Implementation Patterns
Pre-commit hooks
Fastest feedback loop. Run linters, formatters, and quick checks before the commit is created. Keep these fast (<5s) or developers will bypass them.
CI checks
More thorough validation. Run tests, build verification, and slower checks. Can block merge but not local commits.
Deploy gates
Final validation before production. Health checks, smoke tests, and approval workflows. Most important for high-stakes environments.