4.8 KiB
Deferred work
Status: retained future work and unselected proposals; no implementation schedule.
Purpose and authority
Completed initial delivery, performance, ReleaseKit upgrade, and remediation records have been retired. This document preserves their unfinished capability targets and deferred ideas under the release policy. The original records remain available in Git history.
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.
Deferred capability targets
DIFF-01: semantic configuration comparison
Expose comparison of two independently resolved selections of one scope using owning-library public comparison APIs. ADR 0008 owns native comparison, paired safe disclosure, and the reduced default report. The target includes a YAML-only report of safe changed regions; completed comparisons succeed whether or not they find differences.
The initial review of ConfigKit v0.5.0 and PromptKit v0.12.0 did not find the
public comparison support needed for that target. ConfigKit v0.7.0 introduced
configkit.Diff, retained in v0.7.1, which supplies native comparison and paired
safe changed-region snapshots. CommandKit still uses ConfigKit v0.5.0; dependency
adoption and comparison delivery are targeted by the
ConfigKit roadmap. Assess PromptKit's supported
public comparison capabilities separately. Rendered YAML and sibling internals
are not substitutes for the owning library's public comparison contract.
The ConfigKit roadmap records accepted selection syntax and the paired provider API, with lifecycle recorded in ADR 0012. The selected report shape is recorded in that roadmap. Independent per-side domain selectors and an optional assertion mode remain outside that delivery. Add public types and handlers with their implementation rather than exposing placeholders.
CAT-01: PromptKit catalogs
List captured prompt/version entries and named profiles through owning public catalog APIs, with deterministic reports of loaded definitions. Resource names, enumeration details, and report shapes remain future design work.
The initial PromptKit v0.12.0 review did not find public enumeration APIs. Reassess current released capabilities before planning delivery. Do not infer catalogs by reparsing configuration YAML or inspecting sibling internals.
Other deferred proposals
These capabilities remain outside the delivered scope and require a concrete operator or consumer need and an appropriate ownership/behavior decision:
- JSON reports, shell completion, and output-file management or reloadable export.
- Configuration mutation, generic value assignment, and exhaustive field-origin inventories.
- Credential diagnostics and 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.