Record PromptKit adoption scope and completion criteria

docs/roadmap/future.md

@@ -24,13 +24,21 @@ an idea here does not select its syntax, API, priority, or delivery date.
 ### ckprompt dependency migration and workspace alignment
 
 The [PromptKit v0.18.0 adoption roadmap](promptkit-v0.18.0.md) owns the proposed
-dependency set, API/report and fixture migration, workspace alignment, and open
-release, example, and capability scope choices. The current ckprompt v0.2.0 still
+dependency set, API/report and fixture migration, workspace alignment, scope
+decisions, and completion evidence. The current ckprompt v0.2.0 still
 uses published ckconfig v0.2.0 and old-path ConfigKit v0.8.0; it does not compose
 with local ckconfig v0.3.0. See the
 [consumer guide](../consumers/guide.md#module-selection) and
 [development guide](../development.md) for current module and workspace use.
 
+### Later PromptKit release review
+
+The current adoption develops only against PromptKit v0.18.0 as released.
+Review v0.19.0 separately once it is published; do not inspect or monitor
+unreleased upstream work in anticipation of that review. A later released
+version requires its own contract and compatibility assessment before selection
+and does not delay completion of the v0.18.0 adoption.
+
 ## Future capability targets
 
 ### Comparison extensions
@@ -58,7 +66,11 @@ ConfigKit's public APIs own the evidence and its semantics.
   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.
+  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
@@ -84,6 +96,52 @@ recording remain available through application loaders. Standard inspection of
 resource contexts or secrets-directory bootstrap has no immediate proposal;
 those capabilities primarily serve application loading and startup.
 
+### PromptKit inspection and selection extensions
+
+The [PromptKit adoption scope](promptkit-v0.18.0.md#scope-decisions) defers 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.
+
+- **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).** Begin with the
+  adoption's consumer guidance for 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.
+
 ### Alias completion and discovery
 
 The delivered [shell completion feature](../cli.md#shell-completion) provides
@@ -139,7 +197,7 @@ operator or consumer need and an appropriate ownership/behavior decision:
   injection, and concurrent-dispatch guarantees.
 
 Execution, rendering, serving, and session operations remain application-owned.
-The [prepared-request inspection proposal](promptkit-v0.18.0.md#od-4-add-prepared-request-inspection-to-the-standard-suite)
+The [prepared-request inspection proposal](#promptkit-inspection-and-selection-extensions)
 would extend standard inspection into rendering and remains an open scope choice.
 Shared vocabulary is guidance under [ADR 0006](../adr/0006-command-grammar.md).
 Backend replacement remains possible behind the accepted facade, subject to the