Plan PromptKit v0.19.0 adoption and operator CLI additions

docs/roadmap/future.md

@@ -33,33 +33,13 @@ 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 roadmap preparation
+### PromptKit v0.19.0 adoption
 
-The completed adoption used PromptKit v0.18.0 as released. PromptKit v0.19.0
-has now been released and reviewed. The working adoption scope includes the
-dependency, checksum, attribution, and unpublished candidate-note updates;
-consumer compatibility guidance and corrected credential-report wording;
-focused authentication-reason and smoke preparation-error coverage; and final
-independent-module and aligned-workspace validation.
-
-The proposed additional CLI scope is agreed in principle, subject to review of
-the adoption roadmap: concrete request preview, applicable request-override
-flags, namespace selection, configuration path discovery and explicitness,
-and detailed configuration comparison. Configuration failure investigation is
-also proposed for this roadmap, combining failed-load source inventory and
-structured diagnostics under
-[configuration inspection extensions](#configuration-inspection-extensions).
-Successful evidence reporting must retain the failed configuration outcome;
-report-delivery failures remain separately observable.
-
-These proposals concern standard operator commands, flags, and reports, not
-general-purpose helpers for application-internal PromptKit use. Exact CLI/API
-contracts and implementation sequencing remain for roadmap review. Focused
-backend inspection remains deferred pending released upstream support, as
-recorded under
-[PromptKit inspection and selection extensions](#promptkit-inspection-and-selection-extensions).
-Use released upstream contracts only; do not inspect or monitor unreleased
-upstream work in anticipation of future adoption.
+The [PromptKit v0.19.0 roadmap](promptkit-v0.19.0.md) owns the proposed adoption,
+operator CLI additions, shared configuration inspection work, 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
 
@@ -72,42 +52,16 @@ relevant ADRs.
 
 ### Configuration inspection extensions
 
-The [completed ConfigKit v1.1.0 adoption review](https://forge.maximumdirect.net/base-layer/commandkit/src/commit/260256d722f52bc947103d078cb67a129f4cc9f1/docs/roadmap/configkit-v1.1.0.md#selected-scope-decisions)
-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.
+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. Their earlier ConfigKit adoption identifiers were
+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.
+
+Additional unselected work:
 
-- **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. For
-  PromptKit, design this shared optional ckconfig capability first, then wire
-  `ConfigurationInspection.Metadata()` through `ckprompt.ConfigScope`. This is
-  PromptKit adoption OD-3; it does not require a separate provenance model or a
-  new core API.
-- **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
@@ -120,12 +74,11 @@ those capabilities primarily serve application loading and startup.
 
 ### PromptKit inspection and selection extensions
 
-The [completed PromptKit adoption scope](https://forge.maximumdirect.net/base-layer/commandkit/src/commit/540e2359d66d604a563df0be1c9fc961588f5b9c/docs/roadmap/promptkit-v0.18.0.md#scope-decisions) deferred these
-capabilities beyond the v0.18.0 compatibility migration. Shared configuration
-metadata remains the recommended next functional sprint, under
-[configuration inspection extensions](#configuration-inspection-extensions).
-The OD identifiers below belong to the PromptKit adoption roadmap, separately
-from the ConfigKit review identifiers above.
+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
@@ -137,43 +90,12 @@ from the ConfigKit review identifiers above.
   configuration. Review the released upstream capability before selecting
   command syntax and report fields; this feature is outside the v0.19.0
   adoption scope.
-- **Prepared-request inspection (PromptKit OD-4).** Consider an optional provider
-  and report based on the released native `Engine.Prepare` and `PreparedRun`,
-  reusing the concrete request-builder pattern. This would extend standard
-  inspection into rendering and needs an explicit scope decision. The snapshot
-  offers selected resource IDs, effective settings, output/schema metadata,
-  messages, session ID, hashes, and timing without a model call. Its `Messages`
-  contain complete rendered and appended messages; its effective execution
-  settings exclude resolved API-key values. Select report content and document
-  those upstream semantics rather than treating the complete snapshot as an
-  existing inspection report. Command grammar, callback shape, formats, and the
-  relationship to request validation remain open. Validate capability
-  availability, forwarding, projection, and report delivery at CommandKit's
-  boundary. PromptKit retains preparation and rendering semantics. Keeping this
-  operation application-owned remains an alternative; model execution and
-  prepared-handle lifecycle are outside this proposal.
-- **Namespace helpers or standard selectors (PromptKit OD-5).** The
-  [consumer guidance](../consumers/guide.md#namespace-views) covers loaders
-  returning `Engine.WithNamespaces`.
-  Consider reusable bindings or helpers when consumers demonstrate repeated
-  wiring. Design independent prompt/profile/backend defaults, applicable
-  operations, and their interaction with existing catalog filters together.
-  Namespace views resolve unqualified caller selections; they do not rewrite
-  captured configuration references or global configuration inspection, and
-  namespace/collection inventories remain global. Preserve the distinction
-  between name resolution and catalog filtering. No flag names or changed
-  filtering meanings are selected.
-- **Other reusable request bindings.** Consider helpers for native request
-  options only where consumers repeat wiring. Execution/output-validation
-  overrides, session IDs, appended messages, and retry settings are already
-  reachable through application request builders; engine options remain
-  available through loaders. API availability alone does not select a standard
-  flag or a new core abstraction.
 
-The released [prepared snapshot](https://forge.maximumdirect.net/base-layer/promptkit/src/commit/d9f6aad30509e538fc73ea16710df3a3ec084502/types.go)
-and [namespace API](https://forge.maximumdirect.net/base-layer/promptkit/src/commit/d9f6aad30509e538fc73ea16710df3a3ec084502/namespaces.go)
-provide the reviewed upstream contracts. These proposals establish no new
-provider requirement, delivery date, or adoption completion condition.
+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
 
@@ -229,9 +151,10 @@ operator or consumer need and an appropriate ownership/behavior decision:
 - Backend selection or replacement, a plugin framework, general dependency
   injection, and concurrent-dispatch guarantees.
 
-Execution, rendering, serving, and session operations remain application-owned.
-The [prepared-request inspection proposal](#promptkit-inspection-and-selection-extensions)
-would extend standard inspection into rendering and remains an open scope choice.
+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.