adr-writinglisted

An ADR records a decision at the moment it was made, with the reasoning that was available then. It is not documentation of the system (that changes) and not a design document (that precedes the decision). Its reader is an engineer two years from now asking "why is it like this, and can I change it?" ## When to write one Write an ADR when a decision is: - **hard to reverse** (a database, a framework, a public API shape, a data format), or - **cross-cutting** (affects how most code is written: error handling convention, module boundaries, auth model), or - **surprising** (a reader would assume the other option), or - **contested** (people disagreed, and the losing option will come up again). Do not write one for choices that are local, obvious, or cheaply reversible; a comment or a commit message serves those. A repository with 200 ADRs has stopped recording decisions and started recording activity. ## Format ```markdown # 0007. Use PostgreSQL row-level security for tenant isolation Date: 2026-09-21 Status: accepted Supersedes: 0003 Deciders: (names or roles) ## Context What situation forces a decision. The constraints (scale, team, deadline, compliance), the problem observed, and what happens if nothing is decided. Facts, with numbers where they exist. No solutions yet. ## Options considered ### A. Application-level filtering (current) How it works in one or two sentences. Pros. Cons. What it costs to stay. ### B. Row-level security in PostgreSQL Same. ### C. Sch