GOWORK=off GOTOOLCHAIN=local go test -mod=readonly ./...
(cd integrations/ckconfig &&GOWORK=off GOTOOLCHAIN=local go test -mod=readonly ./...)
(cd integrations/ckprompt &&GOWORK=off GOTOOLCHAIN=local go test -mod=readonly ./...)
```
### Release preparation
The unchanged ckprompt suite and composed example then use published ckconfig
v0.2.0 and their existing upstream dependencies. Their success does not validate
composition with the migrated local ckconfig. Keep local replacements and
workspace files out of the adoption commit. Resume three-module workspace and
composed-consumer validation after ckprompt's migration; update the ignored
workspace's Go version as needed for its member modules at that point.
The target candidate is ckconfig v0.3.0, with full tag
`integrations/ckconfig/v0.3.0`, subject to the existing fresh-version guards.
A pre-v1 minor fits the intentional ConfigKit type-identity, consumer-minimum,
and report-schema changes. Its checked-in note explains these changes and
consumer migration, with the usual immutable licensing footer. Current module
notices describe the selected graph and pinned upstream source.
When the dependency change lands, update the development guide's workspace
instructions to explain this interval. Restore the aligned-workspace guidance
when ckprompt adopts the new dependencies. Until implementation, the existing
development instructions describe the current compatible baseline.
## Work from the baseline
1.**Prepare module metadata for the recommended scope.** Follow OD-1 and
OD-2; OD-3 through OD-6 remain deferred. Select the
Go 1.27 maintainer toolchain, update ckconfig's requirement,
imports, and minimum, and regenerate authentic sums with workspace discovery
off. Inspect the resulting dependency graph; do not commit local replacements
or environment files as an adoption mechanism.
2.**Adapt APIs and source reports.** Update the native source field accesses,
DTOs, text/YAML output, affected tests, and example code. Add empty-import
evidence, including empty lists and record order. Preserve
current coordination and outcomes. Adapt upstream results rather than
adding domain validation.
3.**Update canonical documentation and notices.** Revise the ckconfig README
and GoDoc, [CLI source-report reference](../cli.md#list-configuration-sources),
consumer guide, release toolchain instructions, and development workspace
guidance with the implemented changes. Review the selected graph and
upstream notices, then update ckconfig attribution with the vanity identity,
selected versions, and pinned source links. Update other module notices only when their actual selections
change. Preserve published release history.
4.**Validate the selected end state.** Run the ckconfig suite, including its
maintained example, independently with `GOWORK=off` and read-only module
metadata on the selected Go 1.27 toolchain. Update focused adapter/report
assertions for the new vocabulary and faithful projection of returned
evidence. Preserve coverage of request forwarding, diagnostics, cancellation,
output failures, and supported error identity. Assertions establish
CommandKit adaptation; ConfigKit owns tests of its domain correctness.
Review changed Markdown links, fragments, and examples. Use the interim
workspace guidance for unchanged modules; record that their independent
checks do not establish compatibility with the migrated ckconfig. Full
composed-workspace validation belongs to the later ckprompt migration.
5.**Prepare the integration release.** Propose ckconfig v0.3.0, subject to the
existing fresh-version guards, with tag `integrations/ckconfig/v0.3.0`.
Explain changed ConfigKit type identity, Go minimum, report fields, and
consumer migration in its checked-in note with the usual licensing footer.
A pre-v1 minor fits these intentional compatibility changes. Use the existing
selected-module release procedure when publication is requested; this plan
adds no release gate. Source publication and hosted Gitea delivery retain
their separate outcomes.
Adoption includes release preparation, not source publication or hosted
delivery. The existing [release procedure](../release.md) owns those operations
and their separate outcomes when requested; this target adds no release gate.
## Completion evidence
@@ -252,34 +213,33 @@ Implementation is complete when ckconfig's actual module metadata and imports
select the new dependency, the selected report changes faithfully expose its
returned evidence, the module suite and maintained consumer pass independently,
and current documentation, notices, and release preparation describe that state.
Record final validation evidence and the temporary workspace composition
status. OD-3 through OD-6 remain in deferred work; their implementation is not
a completion condition for this sprint. A future source release is reported
separately from implementation completion; preparing this roadmap does not publish a version
or migrate external applications.
Completion evidence distinguishes independent module validation from the
temporary workspace composition mismatch. OD-3 through OD-6 remain in deferred
work; their implementation is not a completion condition for adoption. A future
source release is reported separately from implementation completion.
## Recommended scope decisions
## Selected scope decisions
These dispositions record the review recommendations for the adoption sprint.
They define its planned scope, not implemented contracts or authorization to
These dispositions record the user's selected adoption scope.
They define the target, not implemented contracts or authorization to
publish. Deferred features still need focused API and CLI design.
| Decision | Recommended disposition | Reason |
| Decision | Selected disposition | Reason |
| --- | --- | --- |
| OD-1: Integration sequencing | Implement and prepare ckconfig independently first; review ckprompt next. | Independent releases keep this sprint focused. Document the temporary workspace mismatch and lack of a newly aligned release pair. |
| OD-1: Integration sequencing | Implement and prepare ckconfig independently first; review ckprompt next. | Independent releases keep adoption focused. Document the temporary workspace mismatch and lack of a newly aligned release pair. |
| OD-2: Empty-import evidence | Include `empty_import_selections`, with `[]` when empty, in text and YAML source reports. | Exposes existing upstream evidence alongside the other report-schema changes. |
| OD-3: Metadata and path discovery | Defer to the next functional sprint after adoption. | A coherent optional capability needs its own field/history report and command design. |
| OD-3: Metadata and path discovery | Defer to the next functional work after adoption. | A coherent optional capability needs its own field/history report and command design. |
| OD-4: Failed-load source inventory | Defer to a separate source-inspection enhancement. | Requires source evidence on error and deliberate report/failure coordination. |
| OD-5: Detailed comparison | Defer; retain the existing reduced report in this sprint. | A richer form needs a report-selection and compatibility decision. |
| OD-6: Structured diagnostics | Defer; retain native diagnostic rendering in this sprint. | Coordinate machine-readable records with shared reporting and outcome delivery. |
| OD-5: Detailed comparison | Defer; retain the existing reduced report during adoption. | A richer form needs a report-selection and compatibility decision. |
| OD-6: Structured diagnostics | Defer; retain native diagnostic rendering during adoption. | Coordinate machine-readable records with shared reporting and outcome delivery. |
The first sprint therefore covers dependency and API migration, source-report
Adoption therefore covers dependency and API migration, source-report
terminology and empty-import evidence, documentation and notices, independent
module validation, and ckconfig release preparation. Core retains its own Go
minimum. Application loaders continue to own discovery and loading policy.
Coordinating both integrations before release remains an alternative if a
matched adoption path becomes necessary. It would expand the sprint to include
matched adoption path becomes necessary. It would expand the scope to include
PromptKit review and ckprompt migration; publication would still proceed in
dependency order. The [deferred feature record](deferred.md#configuration-inspection-extensions)
retains the capability proposals and unresolved design choices for OD-3 through
[release](../policy/release.md), and [OSS](../policy/oss.md) policies for the work
they govern. Use the repository's codebase-memory tools for code discovery.
The completed [vanity migration plan and publication evidence](https://forge.maximumdirect.net/base-layer/commandkit/src/commit/16584084b1b8a87dac959334ede8a47a8cfb8c0b/docs/roadmap/implementation.md)
remain in Git history; do not restart that work or the completed ReleaseKit
adoption/remediation.
The previous plan's [completed ReleaseKit v0.9.0 stages and evidence](https://forge.maximumdirect.net/base-layer/commandkit/src/commit/c8d659dfe5ae3e834b3aeabdfd0fe29b736dc05a/docs/roadmap/implementation.md)
remain in Git history. R1/R2 in [remediation.md](remediation.md) and the ReleaseKit
adoption are complete; do not restart them or rewrite their historical evidence.
3. Require the real selected-module suite and file checks to pass. Fix actual
failures in scope and commit the corrected candidate before retrying. On a
failed/ambiguous push, use the existing publication evidence and recovery
procedure. Do not force refs, bypass guards, or treat a local tag as publication.
4. Record the candidate commit, module path, full tag, validation outcome, and
confirmed source outcome here. A successful tag push completes this source
release; move to dependent preparation without waiting for hosted pages.
This includes ckconfig's maintained example tests. Record the unchanged
modules' results as validation of their own published dependency graphs,
not composition with local migrated ckconfig. Do not add a workspace shim
or change ckprompt to obtain a green three-module workspace.
3. Exercise the simple example's `config sources` text/YAML reports and its
existing fixture comparison with workspace discovery off. Use a controlled
native source fixture from Stage 3 for nonempty import evidence; a new
application import system or live service is unnecessary. Confirm only the
selected presentation and wiring behavior, not upstream domain correctness.
4. Check affected current documentation, local links/fragments, whitespace,
candidate note paths, attribution entries, and pinned-source provenance.
Ensure future behavior is not described as implemented, and distinguish
prepared v0.3.0 from a published release. Run `git diff --check` and the
staged counterpart, including intended new files in the review.
5. Record stage completion, final validation evidence, and the temporary
workspace mismatch in this plan. Mark the feature roadmap's implementation
status accordingly while leaving publication and external adoption pending.
Keep deferred capabilities in their owning record without starting them.
6. Review the worktree and staged changes, commit completed units under the
agent policy with concise messages, and finish with a clean worktree apart
from explicitly preserved unrelated work. Summarize the module/dependency
changes, report migration, tests, commits, and remaining ckprompt follow-up.
Do not publish; the normal selected-module release workflow remains the
owner of future candidate validation, guards, and publication outcomes.
**Stage result:** core v0.3.0 is source-published with
`module go.maximumdirect.net/commandkit`. Actual download of this version and its
sums is part of Stage 3, not a new completion gate for core publication.
**Stage result:** the selected ckconfig adoption is implemented, documented,
validated, committed, and prepared for a later release request. Intermediate
compile failures and deferred work are not substitutes for this final result.
## Stage 3: Migrate ckconfig and prepare its independent candidate
**Completed.** Ckconfig declares `go.maximumdirect.net/ckconfig`, imports the
new core identity, and downloaded `go.maximumdirect.net/commandkit v0.3.0`
with authentic sums. The resolved graph retains ConfigKit v0.8.0 and selects
both the older ReleaseKit v0.4.1 and vanity ReleaseKit v0.9.0 tool modules;
module-local attribution and current guidance reflect those selections. The
v0.2.0 release note is prepared; independent suite validation follows.
1. In `integrations/ckconfig`, migrate the module declaration to
`go.maximumdirect.net/ckconfig`. Update all owned imports, tests, and the
maintained simple example to that self-path and the new core path. Keep
package names and existing adapter behavior.
2. Replace its old core dependency key with the published new-path version.
From the ckconfig module directory, use:
```sh
GOWORK=off GOTOOLCHAIN=local go mod edit -module=go.maximumdirect.net/ckconfig -droprequire=gitea.maximumdirect.net/eric/CommandKit -require=go.maximumdirect.net/commandkit@v0.3.0
GOWORK=off GOTOOLCHAIN=local go mod download go.maximumdirect.net/commandkit@v0.3.0
GOWORK=off GOTOOLCHAIN=local go mod tidy
```
Perform source import migration before tidy to avoid resolving old imports.
Keep real downloaded sums. If retrieval is unavailable, resolve dependency
preparation before proceeding; do not fabricate metadata or substitute a
local replacement as final release evidence.
3. Inspect the actual direct and indirect graph, including tool requirements.
Preserve ConfigKit v0.8.0 and unrelated versions. Update affected notices in
`integrations/ckconfig/docs/oss/attribution.md` under the OSS policy using the
actual selected source revisions; add/retain applicable license texts. Do
not assume similarly named old/new upstream modules are interchangeable.
4. Prepare `integrations/ckconfig/docs/releases/v0.2.0.md` with product
`CommandKit ckconfig`, the new module/core paths, compatible dependency set,
and relevant reporting/completion migration. Immutable footer/source URLs
use the full tag `integrations/ckconfig/v0.2.0` and correct physical files.
5. Update README's ckconfig row, consumer module/import examples, the simple
example guidance, affected GoDoc, and relevant current release/development
references. Explain that applications moving to the new core identity also
use the matched new integration identity.
6. Format changed Go files. Review for stale owned imports/direct requirement
keys, accidental replacements/workspace files, and unexplained graph churn.
Check current links and whitespace. The owning complete suite runs in
Stage 4; a local workspace pass is not a substitute.
**Stage result:** a ckconfig v0.2.0 candidate whose actual dependency is
downloaded `go.maximumdirect.net/commandkit v0.3.0`, with authentic metadata and
aligned current documentation/attribution.
## Stage 4: Validate and publish ckconfig v0.2.0
**Completed.** `go.maximumdirect.net/ckconfig v0.2.0` was published as
`integrations/ckconfig/v0.2.0` at candidate
`92a327db9752e7a898d14f56e86fbdee027b3126`. The ordinary Go 1.26.8 release
workflow passed the independent suite, maintained example, and selected file
checks before the successful source-tag push.
Review and commit the complete ckconfig candidate. From the repository root,
use the same authoritative-branch protocol as Stage 2:
```sh
git push origin HEAD:refs/heads/main
./scripts/release ckconfig v0.2.0
```
The normal release command must pass the independent ckconfig suite, including
its maintained example, with workspace discovery off and without dependency
redirection. It must also pass selected committed-file checks and publication
guards. Do not insert the earlier temporary Go shim or weaken a selected check.
Apply the existing failed/ambiguous-publication procedure if needed.
Record the candidate, path, version, full tag, validation, and source outcome.
The intended tag is `integrations/ckconfig/v0.2.0`; the physical directory remains
`integrations/ckconfig` despite the short vanity module path.
**Stage result:** compatible ckconfig v0.2.0 is source-published under its vanity
identity. Downloading it for ckprompt is the next module's preparation.
## Stage 5: Migrate ckprompt and prepare its independent candidate
**Completed.** Ckprompt declares `go.maximumdirect.net/ckprompt`, uses the
new core and ckconfig imports, and downloaded their v0.3.0 and v0.2.0 releases
with authentic sums. ConfigKit v0.8.0 and PromptKit v0.16.0 remain selected;
attribution records both distinct ReleaseKit tool modules in the resolved
graph. The v0.2.0 note and current consumer guidance are prepared; independent
suite validation follows.
1. Migrate `integrations/ckprompt` to `go.maximumdirect.net/ckprompt`. Update its
owned source/tests and composed example to import the new core, ckconfig,
and ckprompt paths. Preserve PromptKit adaptation and reporting behavior.
2. From that module directory, replace both old CommandKit dependency keys:
```sh
GOWORK=off GOTOOLCHAIN=local go mod edit -module=go.maximumdirect.net/ckprompt -droprequire=gitea.maximumdirect.net/eric/CommandKit -droprequire=gitea.maximumdirect.net/eric/CommandKit/integrations/ckconfig -require=go.maximumdirect.net/commandkit@v0.3.0 -require=go.maximumdirect.net/ckconfig@v0.2.0
GOWORK=off GOTOOLCHAIN=local go mod download go.maximumdirect.net/commandkit@v0.3.0 go.maximumdirect.net/ckconfig@v0.2.0
GOWORK=off GOTOOLCHAIN=local go mod tidy
```
Migrate imports before tidy. Retain actual downloaded sums; resolve fetch
failures as preparation rather than masking them with local source. A new
core with old ckconfig v0.1.0 is the known incompatible combination.
3. Review graph changes while retaining ConfigKit v0.8.0 and PromptKit v0.16.0.
Update affected module-local attribution and immutable notice links based on
the resolved graph, including transitive tools. Keep actual upstream module
identities distinct from the three CommandKit identities being migrated.
4. Prepare `integrations/ckprompt/docs/releases/v0.2.0.md` with product
`CommandKit ckprompt`, new imports/dependencies, and consumer migration.
Footer/source links use full tag `integrations/ckprompt/v0.2.0` and physical
module-local files. Preserve the published v0.1.0 record.
# Integration dependency alignment and vanity-path migration
Status: the vanity migration and matched source releases are complete. The
[implementation plan](implementation.md) records candidate commits, validation,
[completed implementation record](https://forge.maximumdirect.net/base-layer/commandkit/src/commit/16584084b1b8a87dac959334ede8a47a8cfb8c0b/docs/roadmap/implementation.md) records candidate commits, validation,
and publication outcomes; this roadmap retains the target and review history.
## Purpose and authority
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
