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 |
| --- | --- | --- |
| 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 |
| PromptKit integration | Named prompt/profile inspection and the PromptKit configuration-scope adapter | Core, PromptKit, and the configuration integration where needed for scope composition |
| 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 ConfigKit integration |
The core remains an opinionated command library with its existing internal
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
commands, acquisition, runtime construction, streams, and process exit.
The recommended configuration boundary moves the existing ConfigKit-shaped
contracts with their handlers. It preserves one configuration suite into which
The selected configuration boundary moves the existing ConfigKit-shaped
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
configuration inspection and named-definition inspection remain independently
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
cross-repository work. Settle this before publishing integration import paths.
### Ownership of the configuration family
**Recommendation:** place the existing configuration family and its
ConfigKit-shaped provider contracts in the configuration integration. Let the
PromptKit integration depend on it to supply a compatible scope. This follows
the current code and avoids a speculative common data model. The tradeoff is
that non-ConfigKit providers using that suite still depend on ConfigKit contracts;
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.
**Naming alternative:** use `mod-configkit` and `mod-promptkit` as the integration
module directories. This is a viable, compact convention that emphasizes optional
modules. The `integrations/` layout more directly describes their relationship
to the core and groups them together. Either convention provides the same
dependency isolation with separate `go.mod` files; neither naming scheme implies
runtime plugin loading. Final names remain open, and the PromptKit-to-ConfigKit
integration dependency will be documented under either convention.
### Registration across the new public boundary