239 lines
14 KiB
Markdown
239 lines
14 KiB
Markdown
# 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,
|
|
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](promptkit-v0.19.0.md#additional-configkit-operator-workflows).
|
|
Roadmap OD-9 selects explicit application-declared right-side bindings with
|
|
inheritance and collection replacement; empty-collection grammar remains open.
|
|
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](promptkit-v0.19.0.md#od-5-detailed-comparison-selection-and-shape)
|
|
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](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. 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](promptkit-v0.19.0.md#od-6-failure-evidence-and-structured-diagnostic-delivery)
|
|
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, default preferences, and filter spellings are selected
|
|
in the roadmap; core owns universal 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](promptkit-v0.19.0.md#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](promptkit-v0.19.0.md#od-11-transient-configuration-overrides).
|
|
Loader composition, numeric conversion, unusual path syntax, and comparison-side
|
|
clearing 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](promptkit-v0.19.0.md#targeted-end-state)
|
|
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](promptkit-v0.19.0.md#od-2-request-controls-and-provider-parameter-grammar)
|
|
records the agreed canonical naming, scoped convenience aliases, integration
|
|
installation collection, and selected text/file input forms; 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.
|
|
|
|
- **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](promptkit-v0.19.0.md#od-2-request-controls-and-provider-parameter-grammar)
|
|
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](../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
|
|
|
|
The [shared core report output prerequisite](promptkit-v0.19.0.md#shared-core-report-output-prerequisite)
|
|
is now part of the working adoption roadmap. It records application-owned
|
|
content selection, core-owned rendering, a text fallback with optional templates,
|
|
universal format availability, and optional command defaults that otherwise
|
|
defer to core policy. Plain text, YAML, and JSON are the target formats;
|
|
representation, template, native-document, and delivery-staging details remain
|
|
there. 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](#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](#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.
|