| id | DEV-320 | |
|---|---|---|
| title | Scope a PR to a Few Hours | |
| status | active | |
| enforcement | manual | |
| severity | error | |
| depends_on |
|
A large PR is slow to review, hard to revert, and prone to stalling. The bigger the change, the longer it sits and the more risk it carries into production.
Keep each PR small. The time budget is a proxy for diff size, not a target for effort: with AI assistance the same hours produce far more code, so a loose budget quietly lets PRs grow into the slow, risky reviews this rule exists to prevent.
- Scope the work so you can complete the PR within 1 to 2 hours.
- If the solution needs more, decompose it into smaller independent PRs.
- When a smaller PR cannot ship to production on its own, put it behind a feature flag.
- Keep the PR moving. A PR with no activity for 24 hours is closed unless a comment explains the delay.
- The PR is scoped to complete within 1 to 2 hours
- Larger work is split into independent PRs, feature-flagged where needed
- Any delay beyond 24 hours is explained in a comment