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

Clarify ConfigKit integration scope and module naming options

Browse Source
This commit is contained in:
Eric Rakestraw
2026-10-09 13:03:07 +00:00
parent 06859b1b09
commit 085302d78a
1 changed files with 17 additions and 20 deletions
Download Patch File Download Diff File Expand all files Collapse all files

37
docs/roadmap/modules.md
View File

@@ -55,8 +55,8 @@ Names below identify responsibilities rather than final import paths.
| Module | Responsibility | Integration dependencies | | Module | Responsibility | Integration dependencies |
| --- | --- | --- | | --- | --- | --- |
| Core | Application construction, command/group registration, typed bindings, dispatch, help/version, common grammar, outcomes, and diagnostics | Neither ConfigKit nor PromptKit | | Core | Application construction, command/group registration, typed bindings, dispatch, help/version, common grammar, outcomes, and diagnostics | Neither ConfigKit nor PromptKit |
| Configuration integration | Standard configuration family, scope composition, reports, and ConfigKit adapters | Core and ConfigKit; no PromptKit | | ConfigKit integration | Standard configuration family, scope composition, reports, and ConfigKit adapters | Core and ConfigKit; no PromptKit |
| PromptKit integration | Named prompt/profile inspection and the PromptKit configuration-scope adapter | Core, PromptKit, and the configuration integration where needed for scope composition | | PromptKit integration | Named prompt/profile inspection and the PromptKit configuration-scope adapter | Core, PromptKit, and the ConfigKit integration |
The core remains an opinionated command library with its existing internal The core remains an opinionated command library with its existing internal
Cobra boundary. The dependency goal is independence from ConfigKit and PromptKit, Cobra boundary. The dependency goal is independence from ConfigKit and PromptKit,
@@ -67,8 +67,14 @@ the same application through supported public core operations and follow its
grammar, help, invocation, and outcome conventions. Applications retain domain grammar, help, invocation, and outcome conventions. Applications retain domain
commands, acquisition, runtime construction, streams, and process exit. commands, acquisition, runtime construction, streams, and process exit.
The recommended configuration boundary moves the existing ConfigKit-shaped The selected configuration boundary moves the existing ConfigKit-shaped
contracts with their handlers. It preserves one configuration suite into which contracts with their handlers into the ConfigKit integration. Only ConfigKit
support is needed for now; a generic configuration interface is outside this
migration. The PromptKit integration may depend on the ConfigKit integration,
consistent with PromptKit's own ConfigKit dependency. Document that relationship
in consumer guidance regardless of the final module names.
This boundary preserves one configuration suite into which
applications compose `app`, `promptkit`, and other supported scopes. PromptKit applications compose `app`, `promptkit`, and other supported scopes. PromptKit
configuration inspection and named-definition inspection remain independently configuration inspection and named-definition inspection remain independently
selectable. A module dependency does not automatically install a command family. selectable. A module dependency does not automatically install a command family.
@@ -212,22 +218,13 @@ viable if ReleaseKit or maintainer preferences make nested-module publication
awkward, but coordinated changes, examples, and documentation require more awkward, but coordinated changes, examples, and documentation require more
cross-repository work. Settle this before publishing integration import paths. cross-repository work. Settle this before publishing integration import paths.
### Ownership of the configuration family **Naming alternative:** use `mod-configkit` and `mod-promptkit` as the integration
module directories. This is a viable, compact convention that emphasizes optional
**Recommendation:** place the existing configuration family and its modules. The `integrations/` layout more directly describes their relationship
ConfigKit-shaped provider contracts in the configuration integration. Let the to the core and groups them together. Either convention provides the same
PromptKit integration depend on it to supply a compatible scope. This follows dependency isolation with separate `go.mod` files; neither naming scheme implies
the current code and avoids a speculative common data model. The tradeoff is runtime plugin loading. Final names remain open, and the PromptKit-to-ConfigKit
that non-ConfigKit providers using that suite still depend on ConfigKit contracts; integration dependency will be documented under either convention.
core-only custom commands remain available without them.
**Alternative:** define library-independent configuration reports and provider
contracts in core or a separate configuration module, then adapt both owning
libraries. This could benefit consumers wanting standard configuration commands
over unrelated libraries. It adds conversion, public contract ownership, and
possibly another module before such a consumer has demonstrated the need.
Select it only if representative usage justifies those costs and preserves native
inspection semantics.
### Registration across the new public boundary ### Registration across the new public boundary