βοΈ Architecture Decision Records
3 / 3
| Title | Author | Status | Date βΌ |
|---|---|---|---|
| ADR-003: Design docs stay in-repo markdown; the PR is the conversation surface | relbns | accepted | 2026-06-08 |
| ADR-002: Agent decomposition β vertical implementers x horizontal specialists | relbns | accepted | 2026-06-01 |
| ADR-001: Deploy on AWS ECS Fargate | cto, eng-lead | accepted | 2024-08-01 |
What lives here: durable records of significant technical / architectural decisions β what was decided, why, and what alternatives were considered.
Use vs. siblings: an RFC is the discussion before a decision; an ADR is the record after. A decisions log entry is for product/business decisions, not technical ones.
Template: ADR Β· filename:
docs/adrs/adr-<NNN>-<slug>.md
An ADR (Architecture Decision Record) captures a significant technical decision: what was decided, why, and what alternatives were considered.
Why we write ADRsβ
- New engineers understand why the codebase is the way it is
- We avoid relitigating decided questions
- Future decisions are made with full context
Status lifecycleβ
Proposed β Accepted β Deprecated β Superseded by ADR-XXX
Indexβ
| # | Title | Scope | Status | Date |
|---|---|---|---|---|
| ADR-001 | Deploy on AWS ECS Fargate | product | Accepted | 2024-08-01 |
| ADR-002 | Agent decomposition β vertical implementers Γ horizontal specialists | platform | Accepted | 2026-06-01 |
| ADR-003 | Design docs stay in-repo markdown; the PR is the conversation surface | methodology | Accepted | 2026-06-08 |
tip
Use the ADR template for new decisions. Link to the Jira ticket or RFC that prompted the decision.