Files
rdbms-playground/docs/adr/0000-record-architecture-decisions.md
T
claude@clouddev1 3a0c03d781 Initial planning docs: CLAUDE.md and ADRs 0000-0008
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.
2026-05-07 09:27:31 +00:00

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.md stays trustworthy because keeping it current is part of every ADR change, not an afterthought.