base-layer/commandkit
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Clarify the scope of architectural decision records

Browse Source
This commit is contained in:
Eric Rakestraw
2026-10-11 20:26:11 +00:00
parent 92727ecf2b
commit f8bb78924e
1 changed files with 10 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files

11
docs/policy/documentation.md
View File

@@ -2,7 +2,7 @@
**Base Policy Version:** 1.11 **Base Policy Version:** 1.11
**Last Updated**: 2026-10-06 **Last Updated**: 2026-10-10
**Upstream Source:** [documentation.md](https://gitea.maximumdirect.net/eric/policy/src/commit/d84a38ebab26f048cafbe59a2246700c35d29843/docs/policy/documentation.md) **Upstream Source:** [documentation.md](https://gitea.maximumdirect.net/eric/policy/src/commit/d84a38ebab26f048cafbe59a2246700c35d29843/docs/policy/documentation.md)
@@ -147,6 +147,15 @@ mechanisms only.
## Architecture Decision Records ## Architecture Decision Records
ADRs record durable architectural decisions: responsibility boundaries,
ownership, significant constraints, and the reasons for choosing them. A settled
implementation or presentation choice does not automatically belong in an ADR.
Ask whether changing the detail would alter the architecture or represent
reasonable evolution within it. Details that can evolve within the chosen
architecture belong in API or CLI contracts, implementation documentation, or
roadmaps. Describe upstream behavior as context without turning it into an
independent project guarantee.
Use sequentially numbered ADR filenames such as Use sequentially numbered ADR filenames such as
`0001-record-architecture-decisions.md`. Follow the lightweight Nygard format: `0001-record-architecture-decisions.md`. Follow the lightweight Nygard format: