From 085302d78a1a6dfe45ceebcaeb6507008af436ff Mon Sep 17 00:00:00 2001 From: Eric Rakestraw Date: Fri, 9 Oct 2026 13:03:07 +0000 Subject: [PATCH] Clarify ConfigKit integration scope and module naming options --- docs/roadmap/modules.md | 37 +++++++++++++++++-------------------- 1 file changed, 17 insertions(+), 20 deletions(-) diff --git a/docs/roadmap/modules.md b/docs/roadmap/modules.md index 723be6c..1fffbd3 100644 --- a/docs/roadmap/modules.md +++ b/docs/roadmap/modules.md @@ -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