docs(adr): add Starlight frontmatter to ADR template
Add required `title`/`description` frontmatter and remove the redundant H1 heading so new ADRs created from this template conform to Starlight's content collection schema by default.
This commit is contained in:
@@ -0,0 +1,120 @@
|
||||
---
|
||||
title: "ADR-XXXXXX: Title"
|
||||
description: "One-sentence summary of the decision."
|
||||
---
|
||||
|
||||
* **Status:** Proposed
|
||||
* **Date:** YYYY-MM-DD
|
||||
* **Decision Makers:** LUNA Charts Maintainers
|
||||
|
||||
---
|
||||
|
||||
## Context
|
||||
|
||||
Describe the background that led to this decision.
|
||||
|
||||
Questions that should be answered:
|
||||
|
||||
* What problem needs to be solved?
|
||||
* Which architectural constraints exist?
|
||||
* Which project goals influence the decision?
|
||||
* Which stakeholders are affected?
|
||||
|
||||
---
|
||||
|
||||
## Decision Drivers
|
||||
|
||||
List the primary factors that influenced the decision.
|
||||
|
||||
Typical examples:
|
||||
|
||||
* Accessibility
|
||||
* Performance
|
||||
* Developer Experience
|
||||
* Maintainability
|
||||
* Framework Agnosticism
|
||||
* Type Safety
|
||||
* Simplicity
|
||||
* Scalability
|
||||
|
||||
---
|
||||
|
||||
## Considered Alternatives
|
||||
|
||||
Document all relevant alternatives.
|
||||
|
||||
| Alternative | Description |
|
||||
| ----------- | ----------- |
|
||||
| Option A | Description |
|
||||
| Option B | Description |
|
||||
| Option C | Description |
|
||||
|
||||
Briefly explain why the alternatives were not selected.
|
||||
|
||||
---
|
||||
|
||||
## Decision
|
||||
|
||||
Describe the selected solution.
|
||||
|
||||
This section should clearly answer:
|
||||
|
||||
> What has been decided?
|
||||
|
||||
---
|
||||
|
||||
## Rationale
|
||||
|
||||
Explain why the selected solution best satisfies the decision drivers.
|
||||
|
||||
This section should justify the decision from an architectural perspective.
|
||||
|
||||
---
|
||||
|
||||
## Consequences
|
||||
|
||||
### Positive
|
||||
|
||||
Describe the expected benefits.
|
||||
|
||||
Examples:
|
||||
|
||||
* Improved maintainability
|
||||
* Better accessibility
|
||||
* Easier onboarding
|
||||
* Reduced complexity
|
||||
|
||||
### Negative
|
||||
|
||||
Describe possible drawbacks.
|
||||
|
||||
Examples:
|
||||
|
||||
* Increased implementation effort
|
||||
* Additional maintenance
|
||||
* Performance trade-offs
|
||||
|
||||
---
|
||||
|
||||
## Related TOGAF Phases
|
||||
|
||||
List all architecture phases that influenced this decision.
|
||||
|
||||
Examples:
|
||||
|
||||
* Architecture Vision (Phase A)
|
||||
* Technology Architecture (Phase D)
|
||||
* Implementation Governance (Phase G)
|
||||
|
||||
---
|
||||
|
||||
## References
|
||||
|
||||
Provide references to related documentation.
|
||||
|
||||
Examples:
|
||||
|
||||
* Architecture Wiki
|
||||
* Other ADRs
|
||||
* External standards
|
||||
* Specifications
|
||||
Reference in New Issue
Block a user