Record integration module paths and package names

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,
+This roadmap records the targeted end state, selected module layout, and
-repository layout, and other recommendations under [Open Decisions](#open-decisions)
+migration work. Recommendations under [Open Decisions](#open-decisions) remain
-remain proposals. It does not supersede accepted ADRs or describe these changes
+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.
+Provide three consumer modules in this repository with dependencies directed
-Names below identify responsibilities rather than final import paths.
+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
+- Resolve the remaining choices under Open Decisions before moving public
-  and package names before moving public symbols.
+  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
+- Establish the selected module layout, preserving the existing root import
-  the core under the recommended layout.
+  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