Architecture Decision Records¶
Short, dated notes on design decisions that are not self-evident from the code. Each ADR follows the format:
- Status —
proposed,accepted,deprecated, orsuperseded by ADR-NNN - Context — what forces are at play
- Decision — what we chose
- Consequences — trade-offs the decision accepts
New ADRs get the next available number. Once accepted, ADRs are immutable except for status updates; to change direction, write a new ADR that supersedes the old one.
Index¶
| ID | Status | Title |
|---|---|---|
| ADR-001 | accepted | Handler dispatch: registry over mixin inheritance |
| ADR-002 | accepted | Advanced upload payload integrity: XOR + HMAC baseline |
| ADR-003 | accepted | Runtime crypto and ACME dependencies |
| ADR-004 | accepted | Uploads-only enforcement via Path.relative_to |
| ADR-005 | accepted | Concurrency model: ThreadPoolExecutor, not asyncio |
| ADR-006 | superseded by ADR-011 | Historical profile default and exposure policy |
| ADR-007 | accepted | Published artifact surfaces and operator-owned deployment boundary |
| ADR-008 | accepted | Direct-peer client identity and trusted-proxy prerequisites |
| ADR-009 | accepted | Secure Notepad durable-recovery boundary |
| ADR-010 | accepted | Legacy v0 client boundary and API v1 entry criteria |
| ADR-011 | accepted | Always-on method surface and launch presets |