# Developing CommandKit

CommandKit currently contains adopted repository policies, accepted architectural
decisions, implementation plans, identity and outcome primitives, typed command
declarations, an instance-owned registry, a Cobra-backed routing and parsing
adapter, public `App.Execute` coordination, and generated help/version commands.
Configuration suite registration, scope discovery, ConfigKit validation and
reports, PromptKit engine configuration inspection, and optional PromptKit
prompt/profile inspection commands are implemented. The maintained
[consumer guide](consumers/guide.md) links to maintained examples. The
[README](../README.md) provides project orientation; the
[documentation policy](policy/documentation.md#canonical-ownership) assigns
canonical documentation owners.

## Initial orientation

1. Inspect the worktree and preserve unrelated staged and unstaged changes.
2. Read the [agent policy](policy/agents.md) and select other applicable policies
   using the guide below.
3. Read the owning roadmap for proposals and implementation status, and the
   applicable ADR for accepted decisions and rationale.
4. Inspect implementation and relevant consumer contracts when they exist.

## Policy Reading Guide

| Policy | Read before… |
| --- | --- |
| [Policy set provenance](policy/meta.md) | Adopting policies, checking upstream revisions, or updating the adopted policy set. |
| [Agents](policy/agents.md) | Recommending, planning, or implementing repository changes. |
| [Architecture](policy/architecture.md) | Planning or changing Go library code or its structure. |
| [Testing](policy/testing.md) | Selecting validation for code changes, or adding, changing, removing, or evaluating tests. |
| [Documentation](policy/documentation.md) | Writing, revising, or reorganizing documentation. |
| [OSS](policy/oss.md) | Adding or updating dependencies or incorporated third-party material, or changing licensing or attribution. |
| [Release](policy/release.md) | Preparing or publishing a release, changing release procedures, or making versioning and compatibility decisions. |

- Read applicable policies before making decisions they govern; multiple policies
  may apply.
- Select policies using the task triggers above. Follow cross-references to
  relevant sections when needed to resolve a concrete question.
- Reuse policies already available in context; reread when changed or no longer
  available.
- Expand reading when the task's scope expands.
- When revising a policy itself, read that policy and any provisions elsewhere
  affected by the revision.

## Task-specific reading guide

| Task | Read |
| --- | --- |
| Implemented CLI behavior | [CLI reference](cli.md) |
| Public API usage and standard-suite wiring | [Consumer guide](consumers/guide.md), [configuration declarations](../config.go), [PromptKit declarations](../promptkit.go), and applicable ADRs |
| Dispatcher, registration, or typed inputs | [Command declarations](../command.go), [bindings](../binding.go), [invocation](../execute.go), and [ADR 0001](adr/0001-command-dispatch-and-inputs.md) |
| Backend integration | [Internal overview](internal/overview.md), [adapter implementation](../internal/cobra/parse.go), and [ADR 0002](adr/0002-cobra-backend.md) |
| Public facade or adapter boundaries | [Internal overview](internal/overview.md), [ADR 0003](adr/0003-public-facade.md), and the architecture policy |
| Deferred capabilities and delivery scope | [Initial feature target](roadmap/initial.md#deferred-capability-targets) and [explicit deferrals](roadmap/initial.md#explicit-deferrals) |
| Initial planning history | [CLI](roadmap/01-cli-plan.md), [dispatcher](roadmap/02-dispatch.md), [backend](roadmap/03-backend.md), [facade](roadmap/04-facade.md), and [completed initial implementation record](https://gitea.maximumdirect.net/eric/CommandKit/src/commit/3871d837489b9955998b362587a52b47282dc021/docs/roadmap/implementation.md) |
| Release tooling | [Maintainer release procedure](release.md) and [ReleaseKit upgrade roadmap](roadmap/releasekit.md) |
| Performance work | [Computational efficiency roadmap](roadmap/performance.md) and [performance implementation record](roadmap/implementation.md) |
| Licensing or incorporated material | [Project grant](../COPYRIGHT), [license texts](../LICENSE), and [attribution](oss/attribution.md) |
| Policy provenance | [Policy provenance](policy/meta.md) |

Read all applicable rows for cross-cutting work. Go declarations and GoDoc own
current exported contracts; the CLI reference owns operator behavior. The
initial numbered roadmaps are completed planning records. The
[maintainer release procedure](release.md) owns current release operations.
The completed ReleaseKit adoption records remain available in Git history. The
[performance roadmap](roadmap/performance.md) and its implementation record
own the efficiency target and evidence. Retained illustrations and historical
staged instructions are not current API references or assignments to restart
implementation. Future capabilities remain explicitly identified in their
feature roadmaps.

## Documentation validation

For current prose work, inspect relevant diffs, check local links and fragment
destinations, check provenance and template residue, and confirm that statements
about current behavior match the repository. Include intended new files in that
review. Preserve supplied license-text formatting and compare copied texts with
their pinned source.

For tracked and staged prose, run from the repository root:

```sh
git diff --check -- '*.md' COPYRIGHT
git diff --cached --check -- '*.md' COPYRIGHT
```

These commands do not cover untracked files. Review their contents and whitespace
before staging, or use the staged check after staging only the intended files.
Sibling-checkout evidence links in the CLI planning record are historical review
references, not build dependencies. Implemented contracts belong in CommandKit
under their canonical owners.

Run `go test ./...` from the repository root to compile the module and run its
deterministic tests. Format changed Go files with `gofmt`. The
[maintainer release procedure](release.md) owns candidate preparation and
publication commands.

## Release tooling development

The local publication exercise is opt-in and uses disposable Git repositories.
Prepare the module cache before running it; ordinary tests do not bootstrap or
publish a release:

```sh
GOWORK=off GOTOOLCHAIN=local go mod download
COMMANDKIT_RELEASE_INTEGRATION=1 GOWORK=off GOTOOLCHAIN=local GOPROXY=off GONOPROXY=none GOSUMDB=off go test -mod=readonly -count=1 ./scripts -run '^TestReleaseIntegration$'
```

Follow the [local commit policy](policy/agents.md#git-commit-policy). Completed
units receive local commits by default, subject to explicit user instructions.
Preserve unrelated work; default commit authorization does not authorize pushing
or publishing.

## Current public examples

The maintained consumers under `examples/` compile with the module suite and
run without external services:

```sh
go run ./examples/simple config show
go run ./examples/simple greet --count=0 --tag=first --tag second
go run ./examples/composed config validate --scope all --campaign spring
go run ./examples/composed promptkit show prompt briefing --campaign spring --format yaml
go run ./examples/composed session restore session-42 --campaign spring
```

The [consumer guide](consumers/guide.md) explains how their public API usage
fits together.