docs: define phase 1 technical decision process
This commit is contained in:
@ -11,6 +11,8 @@ Create an ADR when a decision:
|
||||
- changes implementation constraints for future work
|
||||
- needs durable reviewable documentation in the repository
|
||||
|
||||
Before an ADR is accepted, compare alternatives using the technical decision process in `docs/DECISION_PROCESS.md`.
|
||||
|
||||
## Minimum ADR Template
|
||||
|
||||
Each ADR should include at least:
|
||||
@ -18,6 +20,7 @@ Each ADR should include at least:
|
||||
- status
|
||||
- date
|
||||
- context
|
||||
- options considered
|
||||
- decision
|
||||
- consequences
|
||||
|
||||
@ -33,6 +36,10 @@ Minimal example:
|
||||
|
||||
What problem or uncertainty is being resolved?
|
||||
|
||||
## Options Considered
|
||||
|
||||
What meaningful alternatives were compared and why?
|
||||
|
||||
## Decision
|
||||
|
||||
What was chosen?
|
||||
@ -61,4 +68,4 @@ ADR-0002-another-decision.md
|
||||
|
||||
## Relationship to Implementation Tasks
|
||||
|
||||
Implementation tasks should follow documented ADRs when they depend on architecture decisions. If an implementation task exposes a new major technical decision, record the decision first or explicitly resolve it as part of the task before implementation proceeds.
|
||||
Implementation tasks should follow documented ADRs when they depend on architecture decisions. If an implementation task exposes a new major technical decision, evaluate the options first, then record the accepted outcome in an ADR before implementation proceeds.
|
||||
|
||||
Reference in New Issue
Block a user