# 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](../policy/release.md#release-documentation-and-preparation).
The completed PromptKit v0.18.0 adoption roadmap and implementation plan remain
available in the
[PromptKit retirement snapshot](https://forge.maximumdirect.net/base-layer/commandkit/src/commit/540e2359d66d604a563df0be1c9fc961588f5b9c/docs/roadmap).
The completed ConfigKit adoption, reporting, dependency alignment, release-tooling,
and remediation records remain available at the
[retirement snapshot](https://forge.maximumdirect.net/base-layer/commandkit/src/commit/260256d722f52bc947103d078cb67a129f4cc9f1/docs/roadmap).
[Earlier retired records](https://gitea.maximumdirect.net/eric/CommandKit/src/commit/6bc37e7ba64ca0920b4d0cc77039a18d4006b24e/docs/roadmap)
also remain in Git history. Completed records are not assignments to restart work.

Accepted [ADRs](../adr/) and the [architecture policy](../policy/architecture.md)
govern any future implementation. The [CLI reference](../cli.md), public GoDoc,
and [consumer guide](../consumers/guide.md) 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](../../integrations/ckprompt/docs/releases/v0.3.0.md)
remains unpublished. Publication and hosted delivery remain separate operations
under the [release procedure](../release.md).
The published ckprompt v0.2.0 retains its earlier dependencies; see the
[consumer guide](../consumers/guide.md#module-selection) for module selection.

### PromptKit v0.19.0 adoption

The [PromptKit v0.19.0 roadmap](promptkit-v0.19.0.md) owns the proposed adoption,
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](promptkit-v0.19.0.md#additional-configkit-operator-workflows).
Their binding and outcome contracts remain open under roadmap OD-9 and OD-10;
retaining those proposals does not change current comparison behavior.

### Configuration inspection extensions

The [PromptKit v0.19.0 roadmap](promptkit-v0.19.0.md#shared-configuration-capabilities)
now includes the shared operator tasks previously retained here: metadata/path
discovery and explicitness, failed-load source inventory, detailed comparison,
and structured diagnostics. 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. CLI syntax and report contracts remain subject to review.

Transient acquisition overrides are an explicit open scope decision in
[roadmap OD-11](promptkit-v0.19.0.md#od-11-transient-configuration-overrides),
with a recommendation for opt-in CLI support and alternatives using
application-specific flags or a structured override document. 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](promptkit-v0.19.0.md#targeted-end-state)
now owns concrete request preview, applicable request flags, namespace selection,
and the shared configuration inspection extensions. These are CLI features;
general-purpose helpers for application-internal PromptKit use are outside
CommandKit's ownership boundary.

- **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.

Additional request controls, including output-contract, inline-input, and
appended-message flags, remain scope choices under
[roadmap OD-2](promptkit-v0.19.0.md#od-2-request-controls-and-provider-parameter-grammar).
Their native API availability alone does not select CLI syntax or require a
convenience API for application execution.

### Alias completion and discovery

The delivered [shell completion feature](../cli.md#shell-completion) 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.
- Persistent configuration mutation. Transient CLI override scope is owned by
  roadmap OD-11; field metadata and provenance inspection are scoped under
  [configuration inspection extensions](#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](promptkit-v0.19.0.md#preview-and-request-flags)
would expose native preparation and rendering as an operator inspection command;
it remains subject to roadmap review.
Shared vocabulary is guidance under [ADR 0006](../adr/0006-command-grammar.md).
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](../consumers/guide.md) and maintained examples provide
integration guidance.