One file per decision that shapes the system and would be expensive to reverse. An ADR explains why a choice was made, so a later reader (human or agent) can tell a deliberate constraint from an accident.
Naming: NNNN-kebab-case-title.md, numbered in the order decisions are
accepted. Numbers are never reused, and an ADR is never edited to say
something different — a decision that changes gets a new ADR that supersedes
the old one, and the old one's Status is updated to point at it.
Status values:
- Proposed — under discussion, not binding.
- Accepted — binding. Code that contradicts it is a bug.
- Accepted — not yet implemented — binding as a target. The docs describe the decided end state; the code has not caught up. Anyone implementing toward it should treat the documentation as the specification.
- Superseded by NNNN — no longer binding; read the replacement.
An ADR's status follows the feature that produced it, per
agent-rules/delivery.md: it is Proposed
while the feature is still feature:spec, becomes Accepted — not yet
implemented when the feature leaves that state, and becomes Accepted
when the feature closes. An ADR that is Accepted — not yet implemented
with no open feature behind it is a gap: either the feature is missing or
the status is stale.
| ADR | Title | Status |
|---|---|---|
| 0001 | Simlock-owned device roots | Accepted |
| 0002 | Opt-in slim iOS simulators | Accepted |
| 0003 | One typed daemon contract behind every frontend | Accepted |
| 0004 | TTL-first leases on every transport | Accepted — not yet implemented |
| 0005 | Gateway and worker modes | Accepted — not yet implemented |