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.
This commit is contained in:
@@ -0,0 +1,49 @@
|
||||
# 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.
|
||||
Reference in New Issue
Block a user