# 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.