Load-bearing engineering decisions live here in Michael Nygard format. See ADR 000 for the format, lifecycle, and template.
| # | Title | Status |
|---|---|---|
| 000 | Architecture Decision Record Process | Accepted |
| 001 | Store Hashed Phone Numbers Instead Of Raw Numbers | Accepted |
| 002 | USDC Prize-Pool Escrow on Stellar Soroban | Accepted |
| 003 | Hand-Rolled SQL Migrations over an ORM | Accepted |
| 004 | Vitest over Jest for Unit Tests | Accepted |
| 005 | Sentry for Errors, OpenTelemetry for Traces / Metrics | Accepted |
- The decision affects more than one module or team.
- It is hard to reverse (migrations, public API, on-chain shape).
- A reasonable reviewer would ask "why didn't we do X instead?".
- The reason isn't obvious from the code (compliance, third-party constraint, prior incident).
Routine choices (naming a function, picking a library version) do not need an ADR.