Decision records
Significant technical decisions are captured as Architecture Decision Records
in docs/ADR/.
Each records the context, the decision, and its consequences.
| # | Decision |
|---|---|
| 001 | Monorepo structure (Turborepo + pnpm workspaces) |
| 002 | Supabase multi-tenant model (RLS-based isolation) |
| 003 | Event-driven gamification (rule engine over the event stream) |
| 004 | TypeScript monorepo config (relative tsconfig extends, no app declarations) |
| 005 | Nextra v3 docs setup |
| 006 | Journey automation engine |
| 007 | Message editors (per-channel) |
| 008 | Self-hosted push & in-app (VAPID, no vendor) |
| 009 | Player auth (Supabase auth for the portal) |
| 010 | Per-brand player identity |
| 011 | Localization: currency, timezone, language |
| 012 | ML player scoring |
| 013 | PAM integration — brand-scoped keys & per-brand configurable mapping |
When to write one
Write an ADR when a decision is hard to reverse, affects multiple parts of the system, or a future reader would ask “why is it done this way?” — e.g. a new external dependency, a security model change, a schema pattern, or a build-tooling choice.
Keep the format simple: Context → Decision → Consequences (plus alternatives considered where useful). See ADR-013 for a recent example covering the PAM integration.