From 9456bef1c10b2ce4bc0b738e9e2cd19d4eccce24 Mon Sep 17 00:00:00 2001 From: Eric Rakestraw Date: Fri, 9 Oct 2026 13:28:45 +0000 Subject: [PATCH] Record integration module paths and package names --- docs/roadmap/modules.md | 58 ++++++++++++++++++----------------------- 1 file changed, 25 insertions(+), 33 deletions(-) diff --git a/docs/roadmap/modules.md b/docs/roadmap/modules.md index 1fffbd3..e5cdd85 100644 --- a/docs/roadmap/modules.md +++ b/docs/roadmap/modules.md @@ -9,9 +9,9 @@ ConfigKit alone, or neither library. Consumers using only CommandKit's core should acquire neither ConfigKit nor PromptKit through CommandKit's package or module dependencies. ConfigKit-only consumers should not acquire PromptKit. -This roadmap records the targeted end state and migration work. Module names, -repository layout, and other recommendations under [Open Decisions](#open-decisions) -remain proposals. It does not supersede accepted ADRs or describe these changes +This roadmap records the targeted end state, selected module layout, and +migration work. Recommendations under [Open Decisions](#open-decisions) remain +proposals. It does not supersede accepted ADRs or describe these changes as implemented. The [architecture policy](../policy/architecture.md) and [ADR 0003](../adr/0003-public-facade.md) govern the current boundary; an accepted successor decision is needed before changing it. Current contracts remain in @@ -49,8 +49,23 @@ that distinction. ## Targeted end state -Provide three consumer modules with dependencies directed toward the core. -Names below identify responsibilities rather than final import paths. +Provide three consumer modules in this repository with dependencies directed +toward the core. Keep the core at `gitea.maximumdirect.net/eric/CommandKit` and +give each integration its own `go.mod`: + +| Directory | Module path | Package name | +| --- | --- | --- | +| Repository root | `gitea.maximumdirect.net/eric/CommandKit` | `commandkit` | +| `integrations/ckconfig` | `gitea.maximumdirect.net/eric/CommandKit/integrations/ckconfig` | `ckconfig` | +| `integrations/ckprompt` | `gitea.maximumdirect.net/eric/CommandKit/integrations/ckprompt` | `ckprompt` | + +The `integrations/` grouping keeps optional modules together as their number +grows; the anticipated three to ten integrations are planning context, not a +limit or delivery commitment. Distinct package names avoid requiring local +aliases when these integrations are imported alongside ConfigKit and PromptKit. +Separate module files establish dependency isolation; directory naming alone +does not. The shared repository requires explicit multi-module testing and +publication orchestration. | Module | Responsibility | Integration dependencies | | --- | --- | --- | @@ -72,7 +87,7 @@ 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. +in consumer guidance: `ckprompt` depends on `ckconfig`. This boundary preserves one configuration suite into which applications compose `app`, `promptkit`, and other supported scopes. PromptKit @@ -95,8 +110,8 @@ is an intentional consumer migration. ### 1. Settle boundaries and record the decision -- Resolve the significant choices under Open Decisions and select module paths - and package names before moving public symbols. +- Resolve the remaining choices under Open Decisions before moving public + symbols, using the selected module paths and package names above. - Create a successor ADR for the changed facade/module boundary and mark ADR 0003 superseded according to the [documentation policy](../policy/documentation.md#architecture-decision-records). @@ -114,8 +129,8 @@ are concrete enough to implement without inventing a general plugin framework. ### 2. Extract the integrations and isolate the core -- Establish the selected module layout. Keep the existing root import path for - the core under the recommended layout. +- Establish the selected module layout, preserving the existing root import + path for the core. - Move configuration declarations, registration, handlers, reports, and ConfigKit adapters together. Move PromptKit declarations, handlers, reports, and its configuration-scope adapter into the PromptKit integration. @@ -203,29 +218,6 @@ Semantic comparison retains the upstream-contract dependency recorded in ## Open Decisions -### Repository layout and module paths - -**Recommendation:** keep the core at the existing repository root and create -nested integration modules in this repository, for example under -`integrations/configkit` and `integrations/promptkit`. These paths are proposals. -One repository makes coordinated API changes and shared maintenance convenient -while separate `go.mod` files provide consumer dependency isolation. The cost is -explicit multi-module testing, prefixed tags, and release orchestration. - -**Alternative:** publish the integrations from separate repositories. Each can -use a simpler single-module release procedure and evolve independently. This is -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. - -**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 **Recommendation:** first reuse public command/group registration and duplicate