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

Update documentation policy from upstream

Browse Source
This commit is contained in:
Eric Rakestraw
2026-11-07 02:27:07 +00:00
parent 9b85c7cf60
commit 76c00e32d0
2 changed files with 23 additions and 16 deletions
Download Patch File Download Diff File Expand all files Collapse all files

28
docs/policy/documentation.md
View File

@@ -2,9 +2,9 @@
**Base Policy Version:** 1.11
**Last Updated**: 2026-10-10
**Last Updated**: 2026-11-07
**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/beb5f191470a9daef2383981a6bfd02232490ab4/docs/policy/documentation.md)
## Purpose
@@ -86,7 +86,7 @@ secret values.
| Inventory of implemented internal packages | `docs/internal/overview.md` | Implemented packages and components, responsibilities, and links to focused internal docs. | Normative architecture, contributor reading policy, external contracts. |
| Behavior and architecture of internal packages | Other files under `docs/internal/` | Implementation flow, collaborators, state transitions, package-local guarantees and failures, and relevant tests. | Global architecture invariants, configuration definitions and defaults, external schemas, operator procedures. |
| Architectural decision records | `docs/adr/` | Significant decisions, context, alternatives, rationale, consequences, and supersession history. | Current behavior reference, implementation status, task sequencing. |
| Future work and implementation status | `docs/roadmap/` | Proposed, accepted, deferred, or rejected work; implementation status, sequencing, and task breakdowns. | Implemented behavior reference and architectural decision rationale. |
| Future work and implementation status | `docs/roadmap/` | Proposed, accepted, or deferred work; implementation status, sequencing, and task breakdowns. | Implemented behavior reference and architectural decision rationale. |
| Release-note history | `docs/releases/` | One checked-in summary per source release under the procedure; the note at its immutable tag is the release record. | Current commands, behavior, contracts, and compatibility definitions. |
| Complete copyable artifacts | `examples/` | Maintained configuration, inputs, and other copyable or runnable files. | Field-by-field reference, command reference, prose explanation. |
@@ -147,14 +147,16 @@ mechanisms only.
## 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.
ADRs record major architectural decisions, such as responsibility and ownership
boundaries, large-scale architectural features, or significant architectural
invariants, and the reasons for choosing them. Routine choices, implementation
or presentation decisions, and rejected suggestions do not warrant an ADR
unless they otherwise represent a significant architectural decision. 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
`0001-record-architecture-decisions.md`. Follow the lightweight Nygard format:
@@ -169,8 +171,8 @@ Use sequentially numbered ADR filenames such as
Treat the decision content of an accepted ADR as immutable. When a decision
changes, create a new ADR and update the earlier ADR's status to superseded.
Rejected architectural alternatives belong in the ADR; rejected product ideas
belong in the roadmap.
Roadmaps should preserve plausible future work, not rejected product ideas.
## Maintenance