107 lines
6.2 KiB
Markdown
107 lines
6.2 KiB
Markdown
|
|
# 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.
|