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 PromptKit v0.18.0 adoption roadmap and implementation plan remain available in the PromptKit retirement snapshot. 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

ckprompt release

The PromptKit v0.18.0 migration is complete. The ckprompt v0.3.0 candidate remains unpublished. Publication and hosted delivery remain separate operations under the release procedure. The published ckprompt v0.2.0 retains its earlier dependencies; see the consumer guide for module selection.

PromptKit v0.19.0 adoption

The PromptKit v0.19.0 roadmap owns the proposed adoption, the agreed shared core report output prerequisite, operator CLI additions for PromptKit and ConfigKit, open decisions, and completion checklist. Scope is agreed in principle and remains subject to roadmap review. Implementation has not started. Use released upstream contracts only; do not inspect or monitor unreleased work in anticipation of adoption.

Future capability targets

Comparison extensions

Independent per-side domain selectors and opt-in comparison assertions are now included in the working roadmap. Roadmap OD-9 selects independent ordinary defaults for both sides and explicit application-declared right-side bindings. Configuration selections and overrides apply only to their own side; omission never inherits from the opposite side. Whether to standardize empty collections overriding nonempty application defaults remains open; clearing inherited comparison values is no longer needed. OD-10 selects an optional assertion outcome with a distinct difference status. These accepted plans do not change the currently implemented behavior.

Roadmap OD-5 selects an optional detailed report while retaining the concise default for human operators. Both presentations reuse the existing native comparison data; the accepted initial layout is recorded there for implementation and later beta feedback.

Configuration inspection extensions

The PromptKit v0.19.0 roadmap now includes the shared operator tasks previously retained here: metadata/path discovery and explicitness, failed-load source inventory, detailed comparison, and structured diagnostics. Path discovery is a mode of config explain, and structured diagnostics belong to config validate; the suite retains six subcommands. The roadmap records the agreed explanation modes and help behavior; OD-6 selects optional validation details, a concise default, and available evidence on failure. OD-8 selects focused display, source selection, and report filters. Initial report content, text templates, and filter spellings are selected in the roadmap; core owns universal and automatic format selection. The remaining layout details will be evaluated through implementation and beta use. It also includes focused effective display, source-ID selection, metadata/diagnostic filters, independent comparison selectors, and assertion mode. The original four shared proposals had ConfigKit adoption identifiers OD-3 through OD-6; the new roadmap has its own decision numbering. Implementation belongs in ckconfig, with PromptKit exposing native evidence through its configuration scope. The initial report implementation approach uses the shared core reporting prerequisite, direct serialization, and thin projections. Further presentation refinements should follow practical feedback.

Transient acquisition overrides are included as an opt-in loader capability in roadmap OD-11. Comparison overrides follow OD-9's independent-side model. Loader composition, numeric conversion, and unusual path syntax remain design tasks. Persistent configuration editing remains deferred.

Discovery, import defaults, collection identities, and field-level resolution recording remain available through application loaders. Discovery tracing, resource-context inspection, and secrets-directory bootstrap commands remain deferred. Acquired source records do not provide a complete trace of rejected discovery candidates; bootstrap and resource contexts primarily serve application loading and startup.

PromptKit inspection and selection extensions

The PromptKit v0.19.0 roadmap now owns concrete request preview, applicable request flags, namespace selection, and the shared configuration inspection extensions. Its execution flags will be public reusable ckprompt collections for standard and application-owned CLI commands, composed through existing core bindings. Roadmap OD-2 records the agreed canonical naming, scoped convenience aliases, integration installation collection, selected text/file input forms, and CLI JSON number policy. Numeric conversion uses ordinary Go types and a small internal helper with policy comments. Those flag and alias features need no core extension. Output-contract overrides and appended-message flags are deferred below. These are CLI features; general-purpose helpers for application-internal PromptKit use are outside CommandKit's ownership boundary.

Roadmap OD-3 records the agreed namespace-selector applicability, including the limited role of profile selection in requirements inspection. That selection follows the released upstream identity requirement; it does not change prompt dependencies.

• Focused backend inspection. Defer a standard backend detail command until a released PromptKit version provides a suitable public backend inspection capability. The operator task is to inspect one backend's endpoint, credential environment reference, concurrency and queue settings, provider defaults, and smoke-probe configuration without running a probe. PromptKit v0.19.0 has no dedicated backend inspection API. Do not implement this proposal by reconstructing backend selection from captured configuration. Review the released upstream capability before selecting command syntax and report fields; this feature is outside the v0.19.0 adoption scope.

• Output-contract override flags. Deferred from the current adoption. A possible future operator task is validating or previewing one prompt with a replacement output contract without editing its definition. PromptKit uses whole-contract replacement; a complete-contract file option was discussed, but no flag spelling or file format is selected. Existing configuration and application builders remain available. Revisit when the standard promptkit commands have a demonstrated need for this workflow.

• Appended-message flags. Deferred from the current adoption. The potential operator task is reproducing a single request with application-added messages through promptkit show prepared or promptkit requirements validate, to inspect roles, ordering, and content or check preparation. These commands do not test model responses or application workflows. Appended messages follow definition messages in supplied order; they are already rendered and do not satisfy missing named prompt inputs. Revisit when request reproduction is a demonstrated operator requirement. An ordered message-list file is a candidate, but no flag syntax, file format, or supported-role selection is decided. Deferring flags does not remove native appended messages from preview reports when an application builder supplies them.

Roadmap OD-2 selects inline text and explicit file input for single-prompt validation and preview. Native API availability alone does not select further CLI syntax or require a convenience API for application execution.

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

The shared core report output prerequisite is now part of the working adoption roadmap. It records application-owned content selection, core-owned rendering, text output with optional templates, and universal format availability. Explicit operator selection wins; otherwise core selects text for a supplied template or chooses from the logical report shape. Command-specific format defaults are omitted from the initial API. Plain text, YAML, and JSON land together. The roadmap selects standard Go JSON serialization conventions for core-serialized report values. Core explicitly converts safe inspection YAML into ordinary report values, preserving data meaning and redaction without a separate native-YAML preservation path. Text templates use Go's text/template with the original Go report value. Without a template, structured text output reuses the YAML renderer; template errors never trigger fallback. Aggregate configuration display uses an ordinary scope-keyed mapping through the same renderers, with no scope-order guarantee or separate-document machinery. XML is removed from current consideration. Markdown and other potential formats are not selected for this adoption; new core formats will work with existing commands without per-command adoption.

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:

• Additional report renderers as described under reporting extensions, and output-file management or reloadable export.
• Shell completion extensions, including alias discovery described above and dynamic discovery of configured or remote values.
• Persistent configuration mutation. Transient CLI overrides are selected under roadmap OD-11; 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, serving, and session operations remain application-owned. The request preview proposal would expose native preparation and rendering as an operator inspection command; it remains subject to roadmap review. 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.