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

Record integration module paths and package names

Browse Source
This commit is contained in:
Eric Rakestraw
2026-10-09 13:28:45 +00:00
parent 085302d78a
commit 9456bef1c1
1 changed files with 25 additions and 33 deletions
Download Patch File Download Diff File Expand all files Collapse all files

58
docs/roadmap/modules.md
View File

@@ -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