Add configuration scope suite registration
This commit is contained in:
19
docs/cli.md
19
docs/cli.md
@@ -83,6 +83,25 @@ Typed inputs keep supplied state separate from defaults. An explicit empty,
|
||||
false, or zero value is supplied. Help and version are available without
|
||||
constructing application command inputs.
|
||||
|
||||
## Configuration scopes
|
||||
|
||||
An application installs one configuration suite with `RegisterConfig`. Its
|
||||
`config scopes` command lists scope names and the configuration operations
|
||||
currently installed for those scopes:
|
||||
|
||||
```text
|
||||
example config scopes
|
||||
example config scopes --format yaml
|
||||
```
|
||||
|
||||
Text output uses one `scope: operation, operation` line per scope. YAML uses a
|
||||
`scopes` sequence with explicit `name` and `operations` fields. Scope order is
|
||||
`app`, then `promptkit`, then other names alphabetically. A metadata-only scope
|
||||
can be listed without an acquisition callback. Discovery does not construct a
|
||||
runtime context or acquire configuration. It reports the intersection between
|
||||
declared scope capabilities and installed handlers, so an operation is listed
|
||||
only when the corresponding command is available.
|
||||
|
||||
## Outcome status
|
||||
|
||||
CommandKit usage failures use status `2`; operational failures use status `1`.
|
||||
|
||||
@@ -4,7 +4,8 @@ CommandKit currently contains adopted repository policies, accepted architectura
|
||||
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.
|
||||
Standard command families remain pending. The
|
||||
Configuration suite registration and scope discovery are implemented; the
|
||||
configuration operations remain pending. The
|
||||
[README](../README.md) provides project orientation; the
|
||||
[documentation policy](policy/documentation.md#canonical-ownership) assigns
|
||||
canonical documentation owners.
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# Initial CommandKit implementation plan
|
||||
|
||||
Status: implementation underway; Stages 1-6 complete and Stages 7-14 pending.
|
||||
Status: implementation underway; Stages 1-7 complete and Stages 8-14 pending.
|
||||
|
||||
Date: 2026-10-07.
|
||||
|
||||
@@ -448,7 +448,7 @@ implemented boundary.
|
||||
|
||||
## Stage 7: implement configuration suites, scopes, and selector preflight
|
||||
|
||||
**Status:** pending. **Prerequisite:** Stage 6.
|
||||
**Status:** complete. **Prerequisite:** Stage 6.
|
||||
|
||||
Add the following root contracts in `config.go`/`selectors.go`:
|
||||
|
||||
@@ -539,6 +539,16 @@ unsupported all before callbacks, explicit/omitted selector applicability,
|
||||
typed empty/false/zero context selectors, and factories uninvoked on help/usage.
|
||||
Use a small custom scope fixture; owning library helpers arrive next.
|
||||
|
||||
**Completion evidence:** added typed configuration suite, scope, selector, view,
|
||||
and request contracts; validates scope IDs, capability metadata, selector
|
||||
bindings, and family collisions. `config scopes` reports installed capability
|
||||
intersections in stable text/YAML inventories without creating a runtime context
|
||||
or acquiring configuration. Added selector preflight and per-scope context
|
||||
projection for later operation handlers, including explicit empty/false/zero
|
||||
values and clearing inapplicable bound fields. `go test ./...` passes; the CLI
|
||||
reference describes scope discovery. Configuration operation handlers remain
|
||||
sequenced in Stages 8-11.
|
||||
|
||||
## Stage 8: integrate ConfigKit and implement validation
|
||||
|
||||
**Status:** pending. **Prerequisite:** Stage 7.
|
||||
|
||||
Reference in New Issue
Block a user