security-invariantslisted

# What an invariant is A rule that holds for the life of the project, with a named place in the code that enforces it. "Users can only see their own data" is a wish. "All tenant data access goes through `withAuthedDb()`, which runs queries inside an RLS-scoped transaction" is an invariant — it says what must always be true and exactly where that truth is checked. If a rule can't be pointed at a file or a function, it isn't ready to go in `AGENTS.md` yet. ## The shape Numbered, imperative, and each one names its `enforced_by` — the file, function, or mechanism that actually makes the rule true, not the intention behind it. The list closes with one fixed sentence: **"If a change would bypass any of the above, stop and flag it instead of shipping it."** That sentence scopes the list — it tells an agent what to do when an invariant and a requested change collide — and nothing about the shape requires it to be the last line of the file; sections that need to exist outside the numbered contract (cross-tenant admin access, logging hygiene) can and should follow it. ## Families worth considering These aren't a checklist to fill regardless of the project — each is named here because Kintwadi's `AGENTS.md` proves it is a real, load-bearing rule in a winning project, not a theoretical one. See `references/invariants-corpus.md` for the full quoted text and anchors. - **Protected-by-default routing** — an entire route group is gated by a layout that runs once, so new pages are s