Captures up-front design decisions for RDBMS Playground: stack (Rust + Ratatui + SQLite), input modes, project file format, type vocabulary, undo snapshots and replay log, sharing/export, and testing approach. ADR-0000 establishes the ADR practice itself and mandates index upkeep alongside any ADR change.
1.7 KiB
ADR-0000: Record architecture decisions
Status
Accepted
Context
The RDBMS Playground project will accumulate design decisions as it grows. We want those decisions to be traceable, reviewable, and easy to challenge later when context has changed.
Decision
Record significant architecture and product decisions as Architecture
Decision Records (ADRs) in docs/adr/, using the Michael Nygard
format (Status, Context, Decision, Consequences). Files are numbered
sequentially with a four-digit prefix and a kebab-case slug, e.g.
0001-language-and-tui-framework.md.
Each ADR captures one decision. Superseding a decision means adding a new ADR that references the old one and marking the old one as "Superseded by ADR-NNNN".
ADRs document decisions, not speculation. An idea under discussion belongs in conversation, an issue, or a design note — not an ADR. An ADR is written once a decision has actually been made.
Index discipline
docs/adr/README.md contains the canonical index of all ADRs.
Whenever an ADR is added, renamed, or has its status changed (e.g.
"Superseded by ADR-NNNN"), the index MUST be updated in the same
change. An ADR change without a corresponding index update is
incomplete.
The index lists ADRs in numerical order. Each entry shows the number, title, and — where relevant — status annotations such as "Superseded by ADR-NNNN" or "Deprecated".
Consequences
- New significant decisions require an ADR before or alongside the implementation that depends on them.
- Old decisions remain visible even after they are superseded.
- Reviewers can audit the rationale chain by reading
docs/adr/in order. - The index in
README.mdstays trustworthy because keeping it current is part of every ADR change, not an afterthought.