DevContainer UserArchitecture Decision Records
What is an ADR?
An Architecture Decision Record (ADR) captures an important architectural decision made along with its context and consequences. ADRs are a lightweight way to document the "why" behind technical choices, ensuring that future contributors understand the reasoning behind the current architecture.
Format
This project uses the Nygard-style ADR format:
- Title: Short noun phrase describing the decision
- Status: Proposed | Accepted | Deprecated | Superseded
- Date: When the decision was made
- Context: What is the issue that we're seeing that motivates this decision?
- Decision: What is the change that we're proposing and/or doing?
- Consequences: What becomes easier or more difficult to do because of this change?
- Alternatives Considered: What other options were evaluated?
Index
| ADR | Title | Status | Date |
|---|---|---|---|
| 001 | React Context for Shared CSI Driver State | Accepted | 2026-03-05 |
| 002 | Read-Only Plugin with Benchmark Exception | Accepted | 2026-03-05 |
| 003 | Graceful Degradation for Optional CRDs | Accepted | 2026-03-05 |
| 004 | URL Hash-Based Detail Panel State | Accepted | 2026-03-05 |
| 005 | Prometheus Metrics via Pod Proxy | Accepted | 2026-03-05 |
Creating New ADRs
- Copy an existing ADR as a template
- Assign the next sequential number (e.g.,
006-your-title.md) - Fill in all sections: Status, Date, Context, Decision, Consequences, Alternatives
- Set the status to
Proposeduntil reviewed - Update this README index table
- Submit as part of a pull request for review
ADRs should not be deleted. If a decision is reversed, create a new ADR that supersedes the old one and update the old ADR's status to Superseded by [ADR NNN](NNN-title.md).