Architecture decisions
Architecture Decision Records (ADRs) preserve the context, choice, and consequences behind a durable design constraint. They complement the PRD: product scope remains in the PRD, while the reason a technical boundary exists belongs here.
Decision index
| ADR | Decision | Status |
|---|---|---|
| ADR-0001 | Use the CLI as the only complete MVP product interface | Proposed |
| ADR-0002 | Separate private file bytes from the SQL catalog | Proposed |
| ADR-0003 | Keep content versions, metadata revisions, and audit history immutable | Proposed |
| ADR-0004 | Distribute signed standalone artifacts with atomic update and rollback | Proposed |
| ADR-0005 | Store the device token in a verified private configuration file | Accepted |
| ADR-0006 | Implement ICM as a plugin over Vault Root Folders and immutable files | Accepted |
Lifecycle
Statuses are proposed, accepted, superseded, or rejected. Once accepted, an ADR is not rewritten to hide a changed direction. Add a superseding ADR and link both records.
An ADR may be accepted only after its assumptions are supported by implementation evidence or an explicit architecture approval. ADR-0005 is accepted for the implemented development credential boundary. ADR-0006 is accepted by explicit architecture approval; its implementation evidence remains owned by the dependent ICM cards. ADR-0001 through ADR-0004 remain proposed while their broader product or infrastructure proof is incomplete.