Engineering
Code review & PR standards
What good pull requests look like at E-FACTS
Code review & PR standards
Before you open a PR
- Problem and surface owner are clear (Product surfaces)
- Secrets are not in the diff
- Tests or a manual test plan exist for behavior changes
- Docs updated when behavior becomes company-canonical
-
npm run build(web) / relevant iOS or backend checks pass locally
PR description
Include:
- Why — job / bug / risk
- What — concise summary (not a file dump)
- How to test — checklist
- Risk — auth, data, migrations, flags
Review focus
| Prefer catching… | De-emphasize… |
|---|---|
| Auth / privacy mistakes | Pure style nits already covered by formatters |
| Wrong surface / leaky abstractions | Drive-by refactors unrelated to the PR |
| Money / schema regressions | Rewriting working names for taste |
| Missing failure paths | Expanding scope mid-review |
Size
Prefer small, reviewable PRs. Split mechanical refactors from behavior changes.