Add ConfigKit validation and diagnostics
This commit is contained in:
23
docs/cli.md
23
docs/cli.md
@@ -102,6 +102,29 @@ 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.
|
||||
|
||||
### Validate configuration
|
||||
|
||||
`config validate` loads and validates the selected scope. The default scope is
|
||||
`app`; `--scope all` validates every registered scope and is available when each
|
||||
scope declares validation. The command checks all selected capabilities before
|
||||
calling scope providers.
|
||||
Its default format is text; `--format yaml` emits a `scopes` sequence with
|
||||
`name` and `valid: true` for each scope that completed successfully.
|
||||
|
||||
```text
|
||||
example config validate
|
||||
example config validate --scope promptkit --format yaml
|
||||
example config validate --scope all
|
||||
```
|
||||
|
||||
Each successful scope is reported as `SCOPE: valid`. Aggregate validation stops
|
||||
at the first load or output failure; records from earlier successful scopes may
|
||||
already have been written. Provider warnings go to the diagnostic stream and do
|
||||
not alone make validation fail. `--config` and `--overlay` preserve whether an
|
||||
empty value was explicitly supplied, so a scope callback can map those inputs to
|
||||
its own ConfigKit load policy. Help and invalid syntax do not call scope
|
||||
providers.
|
||||
|
||||
## Outcome status
|
||||
|
||||
CommandKit usage failures use status `2`; operational failures use status `1`.
|
||||
|
||||
Reference in New Issue
Block a user