Architecture Decision Records (ADRs)
Manage architectural decisions as structured markdown documents in docs/adr/.
Directory Structure
docs/adr/
├── INDEX.md # Index with TOC (read this first)
├── ADR-001-nats-jetstream-instead-of-kafka.md # Individual ADR
├── ADR-002-embedded-nats-server.md
└── ...
Workflow
Before doing anything
- Read
docs/adr/INDEX.mdto see the current index of all ADRs - Only read individual ADR files if their content is relevant to the current task
Creating a new ADR
- Read
docs/adr/INDEX.mdto determine the next available number - Create the ADR file using the template below
- Update
docs/adr/INDEX.mdto add the new entry to the TOC - FDR sweep: after writing, scan
docs/fdr/INDEX.mdfor features whose design now relates to this ADR. Update those FDRs to cite the new ADR in theirRelated → ADRsline. (ADRs themselves don't carry aRelated FDRssection — citations flow FDR → ADR only.)
Updating an ADR
- Read
docs/adr/INDEX.mdto find the ADR - Read the specific ADR file
- Make changes (typically amending the consequences or adding context)
- Update the TOC in
docs/adr/INDEX.mdif the title changed
Superseding an ADR
- Create a new ADR that references the old one
- Add a note to the old ADR's Context or Decision section pointing to the replacement
- Update the TOC to include the new entry
File Naming
ADR-{NNN}-{kebab-case-slug}.md
NNN: Zero-padded three-digit number, sequential- Slug: Short kebab-case summary of the decision (not the full title)
ADR Template
# ADR-{NNN}: {Title}
**Date:** {YYYY-MM-DD}
## Context
What is the issue that we're seeing that is motivating this decision or change?
## Decision
What is the change that we're proposing and/or doing?
## Consequences
What becomes easier or more difficult to do because of this change?
TOC Format (in INDEX.md)
Each entry in the TOC should be a markdown table row:
| # | Decision | Date |
|---|----------|------|
| [ADR-001](ADR-001-slug.md) | Title of the decision | 2026-03-01 |