|
| 1 | +# Architecture Decision Records |
| 2 | + |
| 3 | +## Title |
| 4 | + |
| 5 | +Architecture Decision Records |
| 6 | + |
| 7 | +## Status |
| 8 | + |
| 9 | +Accepted |
| 10 | + |
| 11 | +## Context |
| 12 | + |
| 13 | +Counterfact is growing in complexity. Significant technical and process decisions are being made regularly — about code generation, server design, developer experience, and the development workflow itself. Without a structured record of these decisions, the reasoning behind choices becomes lost over time, making it hard for contributors (human or AI) to understand why things are the way they are, or to make consistent future decisions. |
| 14 | + |
| 15 | +Copilot is increasingly involved in implementing features. For Copilot to make good decisions, it needs clear architectural context. An ADR process creates a durable, reviewable record of that context. |
| 16 | + |
| 17 | +There are many ADR formats. Andrew Harmel-Law's "Architecture Advice" template, described in _Facilitating Software Architecture_, was chosen because it emphasises advice and consequences rather than just recording what was decided — making it actionable for future contributors. |
| 18 | + |
| 19 | +## Decision |
| 20 | + |
| 21 | +Introduce an ADR process for Counterfact using Andrew Harmel-Law's "Architecture Advice" template. ADRs live under `docs/adr/`. A CI automation assigns sequential numbers to new ADRs when they are merged. |
| 22 | + |
| 23 | +## Options |
| 24 | + |
| 25 | +### Option A: No ADR process (status quo) |
| 26 | + |
| 27 | +Decisions are captured in issue comments, PR descriptions, and commit messages. |
| 28 | + |
| 29 | +- **Pro:** No extra overhead. |
| 30 | +- **Con:** Reasoning is scattered and hard to locate. Context is lost over time. |
| 31 | + |
| 32 | +### Option B: Lightweight ADRs in `docs/adr/` (chosen) |
| 33 | + |
| 34 | +A simple Markdown file per decision, reviewed in PRs, auto-numbered on merge. |
| 35 | + |
| 36 | +- **Pro:** Low overhead. Decisions are easy to find and link to. Reviewable before being finalised. |
| 37 | +- **Con:** Requires discipline to write ADRs for all significant decisions. Auto-numbering adds a small CI step. |
| 38 | + |
| 39 | +### Option C: Third-party ADR tooling (e.g. `adr-tools`) |
| 40 | + |
| 41 | +Use an existing CLI tool to manage ADRs. |
| 42 | + |
| 43 | +- **Pro:** Tooling handles numbering and cross-references automatically. |
| 44 | +- **Con:** Adds a dependency. Less flexible for custom workflows. Doesn't integrate naturally with GitHub PR review. |
| 45 | + |
| 46 | +## Consequences |
| 47 | + |
| 48 | +- All significant architectural decisions for Counterfact will be documented in `docs/adr/`. |
| 49 | +- Contributors (including Copilot) can consult ADRs to understand the reasoning behind design choices. |
| 50 | +- A CI workflow must be created and maintained to auto-number ADR files on merge. |
| 51 | +- Discipline is required: not every change needs an ADR, but anything affecting the architecture, developer workflow, or external contracts should have one. |
| 52 | +- Future decisions may supersede existing ADRs; superseded ADRs are updated with a `Superseded by [NNN]` status rather than deleted. |
| 53 | + |
| 54 | +## Advice |
| 55 | + |
| 56 | +- Draft ADRs early — even a partially filled-in ADR creates useful discussion. (Copilot/Claude) |
| 57 | +- Keep ADRs concise. They should capture context and reasoning, not replace implementation documentation. (Copilot/Claude) |
| 58 | +- When implementing a decision, link the relevant ADR in commit messages and PR descriptions. (Copilot/Claude) |
| 59 | +- When asking Copilot to implement a decision, reference the ADR so it has the necessary context. (Copilot/Claude) |
| 60 | +- When a decision is revisited or reversed, update the old ADR's status to `Superseded by [NNN]` and create a new ADR explaining the change. (Copilot/Claude) |
| 61 | +- The three-stage workflow for acting on a decision is: ADR → plan → implementation, with a human review at each stage. (Copilot/Claude) |
0 commit comments