docs(contributing): add lightweight PR flow and CODEOWNERS review gate

.github/CODEOWNERS

@@ -0,0 +1,30 @@
+# CODEOWNERS — gates review by risk. Branch protection runs with 0 baseline
+# approvals and "Require review from Code Owners" ON: a PR that touches any path
+# below needs an owner's approval to merge; a PR that touches none can be
+# self-merged once CI is green. Keeps trivial work moving while schema, secrets
+# surface, auth, shared contracts, CI, and deploy still get a second set of eyes.
+
+# --- Governance: the review rules themselves ---
+/.github/CODEOWNERS              @dzhhem @BODMAT
+
+# --- Database schema & migrations (data-shape / breaking risk) ---
+/apps/api/prisma/schema.prisma   @dzhhem @BODMAT
+/apps/api/prisma/migrations/     @dzhhem @BODMAT
+
+# --- Secrets surface: every env example documents required/secret vars ---
+.env*.example                    @dzhhem @BODMAT
+
+# --- Auth & security-sensitive code ---
+/apps/api/src/modules/auth/      @dzhhem @BODMAT
+/apps/api/src/middleware/        @dzhhem @BODMAT
+
+# --- Shared API contract: both API and web import from here ---
+/packages/types/                 @dzhhem @BODMAT
+
+# --- CI / release automation ---
+/.github/workflows/              @dzhhem @BODMAT
+
+# --- Deploy & infra config ---
+/render.yaml                     @dzhhem @BODMAT
+/**/Dockerfile                   @dzhhem @BODMAT
+/compose*.yaml                   @dzhhem @BODMAT

.github/PULL_REQUEST_TEMPLATE.md

@@ -1,3 +1,23 @@
+<!--
+Small, low-risk change (docs, config, chore, one-file fix)? No tracking issue
+needed — delete the full template below and use this short form instead (copy
+it out of this comment). See "Lightweight Changes" in CONTRIBUTING.md for when
+this applies. For a full PR, leave this comment as-is — it stays hidden — and
+fill every section below.
+
+## What
+
+<one-line summary — the headline, not a play-by-play of the diff>
+
+## Why
+
+<the reason / context — the part the diff can't show>
+
+## Testing
+
+<how you verified, or "n/a" — best add one-two words why>
+-->
+
 ## Description
 
 Please include a summary of the changes and which issue is fixed. List any dependencies that are required for this change.

CONTRIBUTING.md

@@ -41,6 +41,7 @@ Please read our [Code of Conduct](./CODE_OF_CONDUCT.md) before contributing. To
   - [Database Changes](#database-changes)
 - [Pull Request Process](#pull-request-process)
   - [Contribution Flow](#contribution-flow)
+  - [Lightweight Changes](#lightweight-changes)
   - [Merge Strategy](#merge-strategy)
 - [Troubleshooting](#troubleshooting)
   - [Database is in a broken state / migrations fail](#database-is-in-a-broken-state--migrations-fail)
@@ -711,7 +712,7 @@ Prisma prepends a timestamp automatically — the name you provide becomes the h
 
 ### Contribution Flow
 
-The standard cycle for any change — bug fix, feature, or chore:
+The standard cycle for any change — bug fix, feature, or chore. Small, low-risk changes can take a shorter path — see [Lightweight Changes](#lightweight-changes).
 
 1. **Open an issue** using one of the templates in [`.github/ISSUE_TEMPLATE/`](./.github/ISSUE_TEMPLATE/) — [`fix_request.md`](./.github/ISSUE_TEMPLATE/fix_request.md), [`feat_request.md`](./.github/ISSUE_TEMPLATE/feat_request.md), or [`chore_request.md`](./.github/ISSUE_TEMPLATE/chore_request.md). Keep the prefilled title prefix (`fix: `, `feat: `, `chore: `) and fill every section before writing any code.
 2. **Create a branch** from `master` following the [Branch Naming](#branch-naming) convention. Optionally prefix with the issue number for traceability: `feat/42-csv-export`, `fix/17-refresh-token`.
@@ -720,6 +721,36 @@ The standard cycle for any change — bug fix, feature, or chore:
 5. **Open a PR** targeting `master` — GitHub auto-loads [`.github/PULL_REQUEST_TEMPLATE.md`](./.github/PULL_REQUEST_TEMPLATE.md). Reuse the issue title verbatim, fill every section (Description, Type of change, How Has This Been Tested?, Checklist), and link the issue with `Closes #N` so GitHub auto-closes it on merge.
 6. **After merge** — delete the branch.
 
+### Lightweight Changes
+
+The contribution flow scales to the **size and risk** of the change. Small, low-risk changes do not need a tracking issue, the full PR template, or a blocking approval — they are still opened as a PR and still run through CI; only the tracking issue, the long template, and the required review are dropped.
+
+**Lightweight flow** (no issue, short PR description) — use it when _all_ of these hold:
+
+- the change is self-contained and reviewable at a glance
+- it does not change behavior in a non-obvious way
+- it does not touch the database schema / migrations, a public API contract, or security-sensitive code
+- it is a fix, docs, config, or chore — not a new feature or module
+
+Examples: a typo or docs edit, a config tweak, a dependency bump, a one-file bug fix.
+
+**Merging a lightweight PR** — once CI is green, the author may merge their own PR without waiting for an approval. Review is welcome but not blocking: a reviewer can comment before or after merge, and anything they flag is fixed in a follow-up. This keeps trivial work from stalling on a second pair of eyes it does not need. A **full-flow** PR still needs a reviewer's approval before merge.
+
+**Full flow** (issue + full [`PULL_REQUEST_TEMPLATE.md`](./.github/PULL_REQUEST_TEMPLATE.md)) — use it when _any_ of these hold:
+
+- a new feature or module
+- a behavior or contract change, a database migration, or anything security-related
+- a breaking change
+- anything that benefits from design discussion before coding
+
+> Commit count is a rough hint, not the rule — branches are squash-merged, so they collapse to a single commit in `master` regardless of how many you made. Gate on **scope and risk**, not on commit count. **When in doubt, use the full flow**, and a reviewer can always ask to promote a lightweight PR to the full process.
+
+Which path applies is enforced automatically by [`.github/CODEOWNERS`](./.github/CODEOWNERS): it lists the sensitive paths — database schema and migrations, any `.env*.example`, auth and middleware code, `packages/types`, CI workflows, and deploy config. A PR that touches any of them needs an owner's approval before it can merge; a PR that touches none can be self-merged once CI is green. (Branch protection: `0` baseline approvals + **Require review from Code Owners**.)
+
+The PR template carries this short form in a comment at the top — for a
+lightweight PR, delete the full template and use that **What / Why / Testing**
+form instead.
+
 ### Merge Strategy
 
 **PRs into `master`** are merged via **squash commit** — all branch commits collapse into one, keeping the main history clean and linear.