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

Adopt shared policies and record CommandKit architecture

Browse Source
This commit is contained in:
Eric Rakestraw
2026-10-06 16:32:59 +00:00
parent 42d9b361cb
commit 88fb3f19b0
21 changed files with 3116 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

106
docs/roadmap/policy.md Normal file
View File

@@ -0,0 +1,106 @@
# CommandKit policy adoption and follow-up
Status: initial adoption and decision alignment complete; implementation-specific
follow-up pending.
Date: 2026-10-06.
This document records completion of the initial adoption and retains work tied to
future library implementation. Local policies are authoritative. Architectural
rationale now belongs in ADRs, and the implementation roadmaps retain pending
work. The CLI proposal keeps its accepted choices and remaining recommendations.
## 1. Adopted baseline
The seven policies were adapted from Standard Repository Policies at:
`d84a38ebab26f048cafbe59a2246700c35d29843`
The selected commit is available in the local upstream checkout and is the
baseline used by PromptKit, ConfigKit, and ReleaseKit. Adoption used that fixed
revision rather than relying on remote freshness. Each local policy preserves its
base version, records the actual adoption date, and links to its source file at
that commit. Updates require deliberate review under
[policy provenance](../policy/meta.md) and the upstream adoption guide.
| Adopted policy | Base version | Adaptation |
| --- | --- | --- |
| [Meta](../policy/meta.md) | 1.0 | Local authority, provenance, and upstream navigation. |
| [Agents](../policy/agents.md) | 1.3 | Proportionate implementation, explicit contract authority, and local commits. |
| [Architecture](../policy/architecture.md) | 1.3 | Dispatcher, registry, typed inputs, root facade, adapter, and ownership constraints. |
| [Testing](../policy/testing.md) | 1.3 | Offline behavioral evidence and CommandKit-specific risk priorities. |
| [Documentation](../policy/documentation.md) | 1.11 | Go API and CLI owners, ADR rationale, and roadmap implementation status. |
| [Release](../policy/release.md) | 1.4 | Source-only module publication and Go/CLI compatibility. |
| [OSS](../policy/oss.md) | 1.8 | Library grant, policy-document license scope, and factual attribution. |
Template adoption sections were removed. Reference examples remain upstream;
source and example links are pinned, while discovery links may track upstream
main. No automatic synchronization, recurring synchronization gate, or separate
license approval flow was added.
## 2. Initial adoption outcomes
- Root [AGENTS.md](../../AGENTS.md) preserves the supplied knowledge-graph
instructions and adds adopted contributor orientation.
- The [developer guide](../development.md) routes tasks to relevant policies and
gives proportionate current documentation validation guidance.
- [COPYRIGHT](../../COPYRIGHT) records the `LGPL-3.0-or-later` library grant and
separate CC-BY-SA-4.0 scope for adopted policies and copied orientation/reading
guidance. Existing independently supplied instructions remain outside that
copied-material scope.
- Root [LICENSE](../../LICENSE) retains the existing complete LGPL/GPL texts.
- [Attribution](../oss/attribution.md) identifies the exact adapted material and
commit-specific source/notices, with the standard CC-BY-SA text copied locally.
- The [README](../../README.md) gives truthful current status, navigation, and
grant/attribution links. No public API, executable, or release tooling is claimed.
The adopted agents policy authorizes local commits for completed units by default,
subject to explicit user instructions. It does not authorize pushing, publishing,
or history rewriting. Review and preserve unrelated work before committing.
## 3. Decision alignment
| Accepted decision | Durable owner | Pending implementation |
| --- | --- | --- |
| Dispatcher ownership, explicit per-instance registry, namespace boundary, and typed inputs | [ADR 0001](../adr/0001-command-dispatch-and-inputs.md) | [Dispatcher roadmap](02-dispatch.md) |
| Cobra/pflag as the sole initial backend | [ADR 0002](../adr/0002-cobra-backend.md) | [Backend roadmap](03-backend.md) |
| Root-owned public contracts and an internal Cobra adapter | [ADR 0003](../adr/0003-public-facade.md) | [Facade roadmap](04-facade.md) |
The architecture policy owns normative boundaries. Accepted ADRs preserve context,
choices, alternatives, and consequences without asserting that implementation
exists. The three implementation roadmaps now link to those records instead of
maintaining duplicate architectural rationale.
The [CLI proposal](01-cli-plan.md) remains the owner of future operator-contract
proposals and their individual approval status. Adoption did not approve the
remaining command inventory, grammar, exit statuses, or illustrative APIs.
## 4. Follow-up with implementation
| Work | Introduce when |
| --- | --- |
| Exact API declarations and GoDoc | Public registration, binding, provider, and invocation operations are implemented. |
| Task-oriented consumer guides and maintained examples | There are substantive supported consumer workflows. |
| `docs/cli.md` | Standard commands and operator contracts are implemented. |
| Internal inventory and subsystem documentation | Actual packages and mechanisms exist. |
| Cobra/pflag versions, notices, and license texts | Dependencies are incorporated; selection alone is not incorporation. |
| Proportionate boundary and consumer checks | Code introduces the public facade and backend adapter. |
| `docs/release.md`, publication tooling, and release notes | A releasable source module and working publication workflow exist. |
ConfigKit and PromptKit keep ownership of configuration and prompt semantics.
CommandKit documents their CLI exposure and links to their canonical contracts.
Select meaningful checks for actual CommandKit risks; do not inherit another
library's platform matrix, scanners, or validation gates automatically.
ReleaseKit remains a candidate for publication mechanics, not a selected
integration. Source-only releases are sufficient. Compatibility covers published
Go and CLI contracts, including parser behavior and YAML reports, even when Go
signatures are unchanged.
## 5. Completion boundary
Initial adoption comprises the customized policy set, supporting notices,
contributor navigation, and alignment of already accepted decisions. That work is
complete. The follow-up above remains future implementation scope; empty CLI/API
references, checker code, release scripts, and speculative dependency entries are
not prerequisites to policy adoption.