commandkit/docs/roadmap/future.md

Future work

Status: pending release and integration work, plus future capability proposals. No delivery dates are selected here.

Purpose and authority

Completed roadmaps, implementation plans, and review findings have been retired. This document preserves unfinished work and unselected ideas under the release policy. The completed ConfigKit adoption, reporting, dependency alignment, release-tooling, and remediation records remain available at the retirement snapshot. Earlier retired records also remain in Git history. Completed records are not assignments to restart work.

Accepted ADRs and the architecture policy govern any future implementation. The CLI reference, public GoDoc, and consumer guide own implemented behavior. Retaining an idea here does not select its syntax, API, priority, or delivery date.

Pending release and integration work

ckconfig release and hosted delivery

The ckconfig v0.3.0 candidate adopts ConfigKit v1.1.0 and Go 1.27.0; its implementation and audits are complete. Its candidate release note is prepared, but source publication and hosted delivery remain pending. Complete those operations when requested through the release procedure, using the existing fresh-version guards and reporting source publication and hosted Gitea delivery separately. Publishing this roadmap cleanup does not publish a module version tag or deliver a release page.

ckprompt dependency migration and workspace alignment

Review the upstream PromptKit vanity release and select compatible ConfigKit and PromptKit dependencies before migrating ckprompt's adapters and maintained composed consumer. The new ckconfig uses vanity ConfigKit types; ckprompt v0.2.0 still uses published ckconfig v0.2.0 and old-path ConfigKit v0.8.0. Their local sources do not currently compose in the three-module workspace. See the consumer guide for the current module relationship.

The follow-up includes migrating affected imports and public type boundaries, selecting real released dependency versions and the required Go minimum, updating notices and migration guidance, and validating both ckprompt's independent graph and the aligned composed consumer. Restore three-module workspace guidance when those dependencies align, updating the ignored workspace Go version as needed. Until then, preserve local workspace files and validate with workspace discovery off as described in the development guide. No unreviewed PromptKit version or new compatibility bridge is selected here.

Future capability targets

Comparison extensions

Independent per-side domain selectors and an optional assertion mode remain unselected extensions to the delivered ConfigKit comparison. Consider them only for a concrete consumer need and a deliberate API/behavior decision under the relevant ADRs.

Configuration inspection extensions

The completed ConfigKit v1.1.0 adoption review retained the following work after dependency and source-report adoption. Metadata inspection is the recommended next functional sprint; the other features have no selected sequence or delivery date. These proposals do not establish command grammar, report schemas, or new provider requirements. ConfigKit's public APIs own the evidence and its semantics.

• Optional field metadata, path discovery, and history (OD-3). Expose native Metadata.Lookup, IsExplicit, HistoricalPaths, and History through an optional provider capability. Design field and history reports together, keeping existing providers usable. Distinguish effective paths from removed historical paths: a failed Lookup must not suppress available History. Validate that distinction and faithful projection of returned field/change records without recreating upstream provenance logic. Historical enumeration is not an exhaustive inventory of possible schema fields. This gives the earlier field-origin inventory proposal a concrete, upstream-backed scope; command names, selectors, and report shapes remain to be designed.
• Failed-load source inventory (OD-4). Present acquired source evidence from LoadError.Sources() while retaining the failed outcome and diagnostics. Design how an adapter returns its source facet on error and how result output precedes terminal failure presentation. Cover acquisition and report-delivery failures together; current diagnostic context remains available meanwhile.
• Detailed comparison (OD-5). Consider an additional form projecting native Difference paths, both snapshots, presence/redaction fields, and HiddenChanged. The current comparison retains the reduced additions/changes/deletions report. Decide later whether a detailed form complements it or replaces it through a deliberate compatibility change.
• Structured diagnostics (OD-6). Consider machine-readable native codes, paths, severities, and locations alongside CommandKit's shared reporting design. Define result/diagnostic channels, warning and terminal-failure interaction, and delivery outcomes. A ckconfig-specific report remains an alternative, with its cross-family alignment considered explicitly.
• Source-ID filtering. Consider selecting a record already available in the source inventory. Native Source(id) lookup is a convenience; this proposal need not introduce another command or require a lookup method from every custom source provider.

Discovery, import defaults, collection identities, and field-level resolution recording remain available through application loaders. Standard inspection of resource contexts or secrets-directory bootstrap has no immediate proposal; those capabilities primarily serve application loading and startup.

Alias completion and discovery

The delivered shell completion feature provides canonical suggestions and alias-aware interpretation. Potential future work includes suggesting command and flag alias spellings and valid continuations of alias-only prefixes. For example, completion could suggest inspect after app legacy when legacy inspect is an installed alias.

Alias discovery is outside the initial scope. This deferral does not establish a permanent canonical-only completion contract or prohibit future alias discovery. A later design should determine how alias suggestions are presented alongside canonical suggestions while ensuring inserted continuations form valid next steps. No delivery date or final API is selected here.

Reporting extensions

Error-conversion helpers such as WarnError remain deferred pending demonstrated value; applications can already use report.Warn(err.Error()). Terminal redraw and progress-bar presentation were outside the completed reporting scope and remain unselected. Whole-run buffering to make failed runs show only errors was also outside that scope. Any later extension needs a deliberate API and presentation decision rather than assuming those behaviors are already provided.

Release workflow extensions

Historical hosted-page backfilling and automated CI delivery remain separate future choices. The current local page-only delivery workflow is implemented; these extensions are not prerequisites for using it. The release procedure owns delivery, immutable content, and recovery behavior.

Additional validation options, including race testing, full vet, compilation matrices, size limits, and more forbidden-file paths, can be considered for demonstrated needs. None is selected by retaining it here, and the existing candidate checks do not become general prohibitions on development workspaces.

Other future proposals

These capabilities remain outside the delivered scope and require a concrete operator or consumer need and an appropriate ownership/behavior decision:

• JSON reports and output-file management or reloadable export.
• Shell completion extensions, including alias discovery described above and dynamic discovery of configured or remote values.
• Configuration mutation and generic value assignment. Field metadata and provenance inspection are scoped under configuration inspection extensions.
• Credential diagnostics beyond PromptKit's native smoke checks and additional live provider probes.
• Additional component identity registration and domain artifact catalogs.
• Additional library families, including possible FeedKit integration; families can define suitable verbs without requiring comparison or configuration scopes.
• Backend selection or replacement, a plugin framework, general dependency injection, and concurrent-dispatch guarantees.

Execution, rendering, serving, and session operations remain application-owned. Shared vocabulary is guidance under ADR 0006. Backend replacement remains possible behind the accepted facade, subject to the published API/CLI contracts and deliberate compatibility decisions.

Possible further efficiency work

Selected-scope memoization and selector-membership indexes were deferred pending measurements that justify their bookkeeping. Mutable backend reuse across invocations, segmented aggregate YAML delivery, provider caching, consumer-loader redesign, and a replacement backend were outside the completed performance target. Reconsider them only with concrete motivation and review of ownership, invocation state, native reports, and the affected contracts. Retained measurement records are historical evidence, not performance guarantees or release gates.

Consumer adoption

Consumer migrations remain separate from library delivery. Applications can replace duplicated standard handlers and routing, then update their CLI docs and subprocess consumers for intentional changes while retaining domain commands. No migration order or claim about individual applications' adoption is recorded here; the consumer guide and maintained examples provide integration guidance.