1. Fork or branch off main.
2. Open a PR with a clear summary + test plan.
3. CI must pass — main is protected.
4. Merge via squash; release commits live in their own follow-up PR.

Issue references in the suffix help (feat/issue-138-pipe-polylines).

feat(area): one-line summary (#issue)

Optional body — explain WHY, not WHAT. The diff shows WHAT.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

Areas: planner, save, persistence, scheduler, web, api, infra, build, docs, …

Every PR runs:

• Detect change scope — figures out which downstream jobs are relevant.
• Lint — dotnet format --verify-no-changes.
• Build & Test — xUnit + Playwright UI tests.
• Migration drift (SQLite + Postgres) — fails if you changed the model without migrations add for both providers.
• Postgres migration smoke — applies the Postgres migration against postgres:16.

main is protected — all four matrix checks must pass before merging.

Pushes to main additionally trigger the Release workflow, which tags a GitHub Release using the NB.GV-computed version.

Architecturally significant decisions go in docs/adr/. Use 0000-template.md.

ADRs are immutable once accepted — if the decision changes, write a new ADR that supersedes the old one. Don't rewrite history.

• /ultrareview — multi-agent cloud review of the current branch (or /ultrareview <PR#> for a GitHub PR). User-triggered, billed. Useful for a second opinion on architectural changes.
• Standard PR review for everything else.

• Don't skip hooks (--no-verify) without explicit reason.
• Don't git push --force to main — it's protected and you'll be sad.
• Don't add features beyond what the issue asks — the bug fix shouldn't carry surrounding refactors. Three similar lines is better than a premature abstraction.
• Don't commit secrets — .env, credentials. The repo has a .gitignore that should catch most of it.