Architecture Decision Records

ADRs capture the reasoning behind the chart’s load-bearing design choices — the things that would be hard to reverse and the things a new contributor would otherwise have to reverse-engineer from values.yaml. For working configurations rather than rationale, see ../02-examples/.

Numbering convention

Numbers encode importance, not chronology:

• 001 is the most foundational decision — everything else assumes it.
• The tail (015–018) covers narrower refinements.
• New ADRs append at the next free number; if a new decision belongs higher in the stack, don’t renumber existing ADRs — link to it from the relevant ADR(s) and update this index.

Three-digit prefix; one decision per file.

Index

Template

# NNN — Title

- **Status:** Accepted | Superseded by NNN | Deprecated
- **Date:** YYYY-MM-DD

## Context
What forces are at play. Constraints from Kubernetes, GitOps tools, the chart's universal scope, prior incidents.

## Decision
The choice we made, in one paragraph.

## Consequences
What this enables, what it costs, what it forecloses. Migration notes if it replaced a previous approach.

## Alternatives considered
Brief — one or two lines each.

## References
Value paths (e.g. `integrations.monitoring.defaults.exposeService`), helper names, named blocks in `values.yaml`, related ADRs. **Avoid line numbers** in any file reference — they rot the moment someone reformats the file. Avoid commit SHAs for the same reason — git history is the authoritative timeline.