Define inspection around resolved resource configuration

docs/roadmap/inspect-backend.md

@@ -2,128 +2,133 @@
 
 ## Purpose And Status
 
-Help operators using CommandKit-based applications understand Promptkit's
-captured prompt, profile, and backend configuration and the settings applicable
-to a concrete request. CommandKit owns operator-facing commands and presentation;
-Promptkit supplies facts from its existing configuration and execution paths.
+Help operators using CommandKit-based applications inspect the configured
+prompt, profile, or backend selected by ID. CommandKit owns commands and report
+presentation; Promptkit exposes the selected resource's resolved configuration.
 
 The direction is accepted for planning; implementation has not begun. Selected
-work includes expanded prompt inspection, presence-aware profile/prepared
-inspection, backend inspection with effective diagnostic destinations, and
-`BackendConfig.Extends`. Open decisions below cover unresolved scope and public
-representation choices. They are not implicit implementation requirements.
+work includes fuller prompt inspection, profile inspection of the resolved
+profile itself, a new `InspectBackend`, and `BackendConfig.Extends`. Execution-
+policy reporting and prepared-request enhancements have been removed from this
+roadmap. Decisions below record the accepted boundary and remaining choices.
 
-## Design Balance
+## Resource-Inspection Boundary
 
-Provide useful information already captured or cheaply derived. Prefer exposing
-existing values and small shared helpers over introducing new resolution paths,
-parallel report models, provenance tracking, or retained snapshots solely for
-inspection. This is a design preference, not a prohibition on a small adapter
-or additional field when it serves a demonstrated consumer need.
+“Fully resolved” means that ConfigKit has applied source composition and
+inheritance to the selected resource. A child profile should show its resulting
+keys and values, not an unresolved `extends` directive. It does not mean that
+inspection assembles everything affecting execution.
 
-“Fully resolved” describes the applicable resolution stage. It is not a promise
-that inspection can reconstruct the entire authored source, report every future
-configuration field automatically, predict provider defaults, or reproduce a
-future invocation independently of its request and external state.
-
-| View | Information available |
+| API | Resource shown |
 | --- | --- |
-| Resource inspection | Captured values after composition, inheritance, normalization, and applicable Promptkit defaults. |
-| Concrete request preparation | Selected profile, request overrides, rendered messages, input metadata, session ID, and loaded schema for supplied request data. |
-| Execution | Provider responses, actual usage, and other observed runtime facts. |
+| `InspectPrompt` | Resolved prompt definition, including captured imported message content. |
+| `InspectProfile` | Resolved profile definition, before backend-to-profile execution completion. |
+| Proposed `InspectBackend` | Resolved backend definition, including configured diagnostic metadata. |
 
-The planned fields below define the initial additions. Additional cheap,
-useful fields can be considered during implementation without building a
-uniform resource framework or promising exhaustive future coverage. If a field
-requires substantial new machinery, record the tradeoff before expanding scope.
+For example, given:
 
-### Review Findings And Existing Boundaries
+```yaml
+profiles:
+  - id: base
+    backend: openrouter
+    model: example-model
+    temperature: 0.5
+  - id: precise
+    extends: {id: base}
+    temperature: 0
+```
 
-The current implementation provides a relatively small path to the core work:
+The resource settings shown for `precise` are:
 
-- Captured prompt definitions already retain description, session template,
-  message text, roles, and cache-control metadata alongside compiled templates.
-  Inspection can expose that data without reconstructing source files or ASTs.
-- Internal prepared results already retain `TargetPresence`; the root API has
-  an `ExecutionTargetPresence` type. Presence-aware output need not introduce
-  a second interpretation of configuration or provider-value conversion.
-- Smoke selection already has endpoint derivation, including the OpenRouter
-  key URL helper. Reusing or factoring that logic need not create an adapter
-  capability registry or provider metadata service.
-- Transport timeout and retry policy live in different components and are not
-  all carried by prepared results. Their reporting scope and cost need a
-  decision; they are no longer an unconditional completion requirement.
+```yaml
+id: precise
+backend: openrouter
+model: example-model
+temperature: 0
+```
 
-These observations are implementation evidence, not promises to retain those
-private types or helper arrangements. See the current
-[source/capture](../internal/sources.md), [runner](../internal/runner.md), and
-[model-client](../internal/llm.md) descriptions.
+ConfigKit inheritance contributes the parent's model and backend reference.
+Promptkit's execution-time completion would obtain settings from that backend,
+but those settings do not become fields of the inspected profile. The operator
+can inspect the referenced backend separately. Likewise, prompt inspection
+reports a default profile reference without incorporating that profile's values.
 
-Retain established public ownership, credential handling, captured-state, and
-namespace behavior unless a change is deliberately selected. Independent
-mutable results prevent callers from changing engine state; they do not require
-fresh copies of immutable strings or repeated deep copies between private layers.
-Existing `Inspect*` APIs avoid provider work and request preparation. Extending
-their returned data should not silently change those behaviors. These boundaries
-follow the existing API and the selected operator use case, rather than a new
-requirement that all future inspection APIs have identical behavior.
+Use the captured, resolved configuration, including normalizations/defaults
+already recorded in that configuration. Do not add framework execution defaults,
+request overrides, credential values, or provider-derived defaults to fill
+absent resource fields. For example, an absent profile timeout is not populated
+from the framework generation timeout, while a queue default already recorded
+in the resolved backend remains visible. See the
+[format reference](../formats.md#source-headers-collections-and-resource-ids).
 
-## Reporting Semantics
+## Design Balance And Reporting
 
-**Selected presentation:** Omit unset optional settings from operator reports.
-Preserve explicit values, including zero, and applicable Promptkit defaults.
-Suppressed provider controls are also absent from an effective-settings report.
-Neither zero nor `unspecified` should stand in for an omitted control.
+Provide useful resource information already captured or available with modest
+projection. Reuse ConfigKit's resolved handoff and existing resource capture;
+avoid another composition pass, execution resolver, parallel provenance system,
+or duplicate retained graphs solely for inspection. These are proportionality
+guidelines, not prohibitions on a small helper or type when it serves the API.
 
-This concerns the effective setting, not an explanation of every reason it was
-omitted. ConfigKit inspection remains useful for authored values and history.
-Promptkit supplies sufficient presence information; CommandKit chooses report
-layout. Representation and serialization choices remain open in decision 4.
+**Selected presentation:** Omit absent optional settings. Preserve explicit
+values, including zero. Absence is not displayed as zero or `unspecified`.
+An explicit null retained in the resolved resource is a configured value, not
+an absent key; preserve that distinction where it affects resource semantics.
+The previous draft's rule to omit suppressed outbound controls belonged to an
+execution report and does not define resource inspection. Representation of
+presence/null in public results is open decision 4.
 
-Do not infer provider defaults from absent controls. Likewise, a configured
-model alias is the alias, not a prediction of the model it will select later.
-Credential source names and requirements are useful inspection facts; resolved
-credential values remain excluded under existing contracts. Templates and
-arbitrary provider parameters are application data, not automatically safe
-for disclosure. No new general-purpose sanitization guarantee is selected.
+Inspection reports effective resource values rather than original YAML layout,
+comments, or the history of each inherited field. `InspectConfiguration` remains
+available for provenance. Existing opaque prompt identity/hash information can
+remain alongside the resource view; it does not turn inspection into a source
+round-trip API.
+
+Retain existing captured-state, namespace, ownership, and credential-handling
+contracts unless a change is deliberately selected. Mutable results should not
+let a consumer change retained engine state; that does not require repeated
+copies between private helpers or copying immutable strings. Ordinary resource
+inspection needs no rendering, provider calls, or credential availability checks.
+Templates and arbitrary provider settings remain application data whose
+presentation and disclosure are controlled by the consuming application.
 
 ## Expanded Prompt Inspection
 
-Expand `PromptInspection` to include description, ordered message templates
-with roles and cache-control metadata, and the session-ID template. Retain the
-existing identity, opaque hash, default profile reference, input declarations,
-and output contract, including schema reference and repair settings.
+Expose description, ordered message templates with roles and cache-control
+metadata, and the session-ID template, alongside the existing identity, hash,
+default profile reference, input declarations, and output contract. Include
+schema references and repair settings as part of the prompt definition.
 
-Expose effective content captured from imported text or Markdown files, as well
-as inline content. Return the template text available in the captured definition;
-source-layout reconstruction, original YAML formatting, and parsed-template
-objects are unnecessary for this use case. There is no new byte-for-byte source
-round-trip requirement. Message order and text should reflect what rendering
-consumes. Inspection continues to use captured state without rendering or
-reopening files; the schema stays a reference until ordinary preparation loads it.
+Captured prompt definitions already retain the effective content of inline and
+imported text/Markdown messages. Return that text without rendering or reopening
+files. Original source layout and parsed-template objects are unnecessary.
+The schema remains a reference; inspecting the prompt does not load it.
 
-Prompt inspection remains useful without a supplied request or a resolvable
-default profile. The existing independent lookup permits CommandKit to show a
-prompt even when related execution settings need attention.
+Keep prompt inspection independent of request readiness and default-profile
+lookup. A captured prompt remains inspectable without a runnable default profile.
 
-## Presence-Aware Profile And Prepared Inspection
+## Resolved Profile Inspection
 
-`ProfileInspection` exposes effective settings without the presence information
-that execution uses for explicit-zero controls. `PreparedRun` has the same
-public reporting gap, including values returned by `PreparedExecution.Details`.
-Expose enough existing resolved presence information to distinguish omission
-from explicit settings in each of those results.
+This is a deliberate change to existing `InspectProfile` behavior. It currently
+returns backend-completed `EffectiveModelParams`; the new resource boundary
+requires the resolved profile's own fields instead.
 
-For example, an unset temperature produces no temperature entry in the report;
-an explicit zero produces `temperature: 0`. A concrete request's override appears
-in its prepared view. Backend completion, inheritance, and request precedence
-remain the execution path's responsibility. Inspectors need not reconstruct
-that history or distinguish all historical reasons for an absent setting.
+Report fields supplied by the profile or inherited through ConfigKit, including
+backend reference, endpoint/model where present, generation controls, credential
+metadata, and provider parameters. Do not merge in backend provider defaults or
+resolve an environment variable. Profiles may be partial, and their references
+remain references. Distinguish omitted values, explicit zero, and meaningful
+explicit null using the resolved resource's information, rather than inferring
+presence from an execution target.
 
-Reuse the captured target and presence semantics, including existing handling
-of nonzero values. Decision 4 weighs exposing the current presence type against
-another public representation; it does not reopen the omission-reporting decision.
-See [defaults and overrides](../formats.md#defaults-and-overrides).
+Execution target presence and prepared metadata describe a later resolution
+stage and are not substitutes for profile configuration presence. Use the
+existing configuration capture path to expose the needed information without
+introducing a second configuration interpreter. The precise result shape and
+migration from `EffectiveModelParams` are open decision 4.
+
+This roadmap changes no `Prepare`, `PreparedRun`, `PrepareExecution`, or
+`PreparedExecution.Details` contract. Execution continues to apply backend
+completion, framework defaults, and request overrides through its existing path.
 
 ## Backend Inspection
 
@@ -136,107 +141,73 @@ func (e *Engine) InspectBackend(
 ) (*BackendInspection, error)
 ```
 
-The result should expose the full backend identity, base endpoint, credential
-environment-variable name, provider defaults, effective concurrency/queue
-settings, and diagnostic settings and destinations. These are backend defaults,
-not settings after a particular profile or request overrides them. Capacity
-values describe policy, not current occupancy.
+Expose the full backend identity and its resolved fields: base endpoint,
+credential environment-variable name, provider defaults, concurrency/queue
+settings, and configured `smoke_tests` metadata. Reuse suitable public nested
+values where their semantics match; exact names and nesting follow decision 4.
 
-A dedicated top-level inspection result is recommended because `BackendConfig`
-is a presence-aware source input. This does not require a new type for every
-nested value: reuse suitable public values where their semantics match. Exact
-field names and nesting can be selected during implementation within the public
-representation decisions below; internal types remain behind the facade.
+Diagnostic metadata includes the configured authentication kind, profile
+reference, and endpoint overrides after ConfigKit composition/inheritance.
+An inherited endpoint override is a resolved configured value. An endpoint
+computed later by a smoke-test adapter is not. Do not synthesize `/key` URLs,
+reachability fallbacks, or a `smoke_tests` block that is absent from the resolved
+backend. No shared diagnostic URL derivation work is required for this feature.
 
-Follow existing namespace-view selection: qualify slashless caller IDs with the
-backend scope, pass qualified IDs through, and report the selected full ID.
-Use the same identity rules for bundled and caller-supplied backends. The new
-operation should follow existing inspection conventions for invalid engines,
-invalid selections, and context cancellation, without adding cross-error
-precedence guarantees. Missing-backend classification follows accepted decision 1
-below.
+Inspecting a backend does not resolve its smoke-test default profile or contact
+an endpoint. Report the configured reference even if that profile cannot be
+selected. Capacity values describe configured policy, not current occupancy.
 
-### Effective Diagnostic Destinations
+Follow the existing namespace-view selection rules: qualify slashless caller
+IDs with the backend scope, pass qualified IDs through, and return the selected
+full ID. Bundled and caller-defined resources use the same lookup rules.
+Follow existing inspection conventions for invalid engines, invalid selections,
+and cancellation. Missing-backend classification follows accepted decision 1.
 
-Include effective reachability and applicable authentication destinations,
-using explicit overrides or existing backend-relative defaults. Share the
-existing derivation logic where practical; neither CommandKit nor a new
-inspection-specific resolver should maintain a competing set of provider rules.
-A small helper extraction is sufficient if that is all the current adapters need.
+## Consumer Integration And Compatibility
 
-Default reachability applies even without authored `smoke_tests` metadata.
-Report the configured authentication kind and optional inference-default profile
-reference without fabricating authored settings. An authentication kind of
-`none` has no active authentication destination. Decision 5 covers whether the
-result also needs separate declared endpoint fields.
+CommandKit can offer navigation between prompt, profile, and backend references
+without combining their settings into the inspected resource. Stored references
+retain their exact meaning; caller namespace defaults do not rewrite them.
+A particular connected layout is a consumer choice, not a new Promptkit API.
 
-Destinations describe captured backend settings, not provider reachability or
-HTTP diagnostic support in an injected client. Retain the inference-default
-profile as a reference; backend inspection need not resolve it or establish
-inference readiness. Ordinary inspection is expected to return a result or an
-error, following existing methods. If derivation reveals a meaningful case where
-useful captured settings would be lost, bring that case back for a decision
-rather than automatically adding partial-result and warning machinery.
+Coordinate CommandKit adoption of the changed profile result and richer prompt
+and backend views. In particular, migrate any formatter that currently expects
+`EffectiveModelParams`. The profile semantic change must be documented as such,
+not presented as merely adding more fields. Select the Go/serialization migration
+in decision 4 and follow the existing release policy for compatibility changes.
 
-## Connected Views And Concrete Requests
-
-CommandKit can follow prompt default-profile and selected-backend references
-through the existing inspections to build a connected view. This is a suggested
-consumer workflow, not a required report format or a restriction on future
-convenience APIs. Use stored references exactly; namespace defaults apply to
-caller selections, not to reinterpreting captured references. Endpoint-only
-profiles need no backend node. A consumer can retain successful lookups while
-showing a failure for a related resource.
-
-Use existing `Prepare` for concrete variables, inputs, profile selection, and
-request overrides. It performs artifact/schema reads, rendering, and applicable
-credential checks without inference. `PrepareExecution` and its details serve
-callers that want later execution tied to the same preparation, subject to that
-API's existing contract. This roadmap adds no stronger replay guarantee and
-selects no second preparation workflow.
-
-Model parameters are not all execution policy. Per-generation timeout, transport
-cap, retry settings, backend capacity, and caller deadlines are different facts.
-When reported, keep their meanings distinct. Decision 2 determines whether and
-how this round should expose additional engine-policy information. Report known
-settings without claiming knowledge of an injected client's internal behavior.
-
-CommandKit owns CLI commands, formatting, and disclosure. Coordinate downstream
-adoption when the Promptkit additions land; this roadmap does not prescribe
-CommandKit's internal adapter design or require a new stable CLI serialization
-contract in Promptkit.
+Existing preparation APIs remain available for separate concrete-request uses;
+this roadmap adds neither preview commands nor execution-policy report fields.
+Transport timeouts, engine retry settings, caller deadlines, and injected-client
+policy are outside the inspected resource unless they are actual fields of its
+resolved definition. This is the scope of these APIs, not a pending engine-policy
+feature decision.
 
 ## Typed Backend Inheritance
 
 Add `Extends *string` to `BackendConfig`, matching `ProfileConfig.Extends`.
-`BackendSource` should encode a non-nil value as `extends: {id: value}` and omit
-the field when nil. ConfigKit owns inheritance resolution and its diagnostics.
-The helper exposes existing sibling inheritance, rather than performing parent
-lookup or filling inherited fields itself.
+`BackendSource` encodes a non-nil value as `extends: {id: value}` and omits it
+when nil. ConfigKit owns sibling inheritance and its diagnostics. The source
+helper does not look up parents or populate inherited fields itself.
 
 Keep existing root/collection identity, replacement, and null semantics. Raw
-mappings remain available for explicit null and other generic controls outside
-the helper's convenience surface. See the
-[inheritance reference](../formats.md#resource-inheritance) and
+mappings remain available for generic controls outside the convenience helper.
+See [resource inheritance](../formats.md#resource-inheritance) and the existing
 [profile helper](../../profiles.go).
 
-## Related Work And Scope
+## Related Work
 
-Typed prompt construction is open decision 3. Listing return types remain a
-possible later cleanup: `ListPrompts` returns an ID-only `PromptIdentity` wrapper,
-while backend/profile listings return strings. Standardizing on strings may be
-useful at a breaking-change window, but is not required for these inspections.
-
-Collections, schemas, and engine options have different roles; symmetry does
-not require identical APIs for them. The
-[deferred fingerprint proposal](deferred.md#semantic-execution-target-fingerprints)
+Typed prompt construction remains open decision 3. Listing return-type
+consistency is a possible later cleanup, not required here. Collections,
+schemas, and engine options do not need identical APIs merely for symmetry.
+The [deferred fingerprint proposal](deferred.md#semantic-execution-target-fingerprints)
 remains separate. Live capacity monitoring, provider health guarantees, and
-source round-tripping are not selected deliverables, rather than permanent
-prohibitions on future work.
+source round-tripping are not selected deliverables.
 
 ## Decisions
 
-Decision 1 is accepted; decisions 2–5 remain open. Implementation is pending.
+Decisions 1, 2, and 5 are accepted. Decisions 3 and 4 remain open. Numbering is
+retained for continuity with the discussion; implementation is pending.
 
 ### 1. How Should An Unknown Backend Be Classified?
 
@@ -266,26 +237,18 @@ resource-not-found error could carry resource kind and ID, but adds a broader
 contract and integration questions for existing sentinels. Neither is selected;
 the caller already knows the operation and requested ID.
 
-### 2. How Much Engine-Policy Reporting Belongs In This Round?
+### 2. Resource Inspection Does Not Include Execution-Policy Reporting
 
-The previous draft made a comprehensive execution-policy section a completion
-requirement before assessing the cost of carrying transport and retry facts
-through preparation. That commitment is now open, including the option to defer.
+**Status:** Resolved; the former engine-policy proposal is removed from scope.
 
-**Recommendation:** Start with facts already held by the relevant owner and add
-small fields to an existing prepared view where they are inexpensive to carry
-accurately. Evaluate transport cap and effective retry settings individually.
-Avoid a normalized policy model covering every client, invocation, and deadline.
-If a useful fact requires substantial new plumbing, explicitly defer that fact
-and document the report's boundary instead of inventing a default or guarantee.
-The field set and location need agreement before implementation.
+**Decision:** Inspect the selected resolved resource, not all settings that may
+affect its execution. ConfigKit composition and inheritance are included;
+backend-to-profile execution completion, framework execution defaults, request
+overrides, and engine transport/retry reporting are not.
 
-**Alternative:** Add a dedicated engine-settings view for captured defaults,
-paired with prepared results for request-specific settings. This is useful to
-operators without a concrete request, but adds an API and requires distinguishing
-defaults from overrides. A third option is to defer engine-policy reporting
-entirely for this round, delivering the resource/presence improvements first;
-that has the lowest cost but leaves transport/retry reporting to later work.
+Remove the proposed engine-settings API, prepared-result policy fields, and
+prepared-result presence enhancements from this roadmap. No decision about
+where to place those additions remains necessary for resource inspection.
 
 ### 3. Should Typed Prompt Construction Be Added In This Round?
 
@@ -298,83 +261,79 @@ It would need useful message/input/output and omission semantics, inheritance,
 and source context for relative content files. Its maintenance cost is larger
 than adding backend `Extends`; composition can still delegate to ConfigKit.
 
-### 4. How Should Presence And Public Result Values Be Represented?
+### 4. How Should Resolved Resource Results And Presence Be Represented?
 
-The operator requirement is accurate omission, not a particular Go structure,
-new parallel report schema, or fixed JSON policy.
+The chosen meaning of inspection is settled; the public Go shape and migration
+from the existing backend-completed profile result are not.
 
-**Recommendation:** Reuse existing public nested values and expose the existing
-`ExecutionTargetPresence` semantics alongside effective profile/prepared targets
-where practical. This takes advantage of data already used by execution and
-limits new translation. CommandKit can omit absent fields in its own output.
-Document how values and presence interact rather than introducing an independent
-presence/default/provenance system. Prefer additive changes when straightforward.
+**Recommendation:** Use a resource-oriented typed profile result, reusing suitable
+public nested values and representing absent/explicit-zero/explicit-null values
+where needed. Prefer a deliberate, documented change to `ProfileInspection` over
+retaining a second execution-settings view just for compatibility. Choose the
+smallest presence representation supported by captured configuration; do not
+reuse `ExecutionTargetPresence` as if it represented the uncompleted profile.
+Apply the same resource semantics to prompt/backend result additions without
+requiring a generic resource framework.
 
-**Alternative:** Use optional-valued fields in an inspection-specific settings
-result, making absence directly expressible to consumers. That can simplify
-reporting, but duplicates an execution-settings surface and needs conversion
-and maintenance as fields evolve. Choose it only if the consumer simplification
-outweighs that cost. Ordinary JSON tags or a deliberate serialization change can
-also be considered; neither mandatory JSON stability for new results nor a ban
-on useful serialization is selected. Existing documented JSON contracts still
-need an explicit compatibility decision before changing.
+**Alternative:** Expose resolved resource fields as a caller-owned mapping,
+possibly alongside typed identity and prompt metadata. That naturally represents
+missing keys and null and can reduce per-field projection work, but gives up Go
+field discoverability and requires careful definition of the mapping's values
+and compatibility. Compare that cost with the typed representation rather than
+assuming another complete family of public configuration types is necessary.
 
-### 5. Are Both Declared And Effective Diagnostic Endpoints Needed?
+Decide the migration for existing `EffectiveModelParams` consumers and any
+serialization changes explicitly. CommandKit can own its report formatting;
+new JSON contracts or custom serializers are not automatically required. Neither
+option authorizes leaking internal package types or mutable captured state.
 
-Effective destinations are selected scope. The previous draft also suggested
-keeping declared overrides separately, which could create two representations
-and unnecessary origin metadata without a demonstrated reporting need.
+### 5. Backend Diagnostics Show Configured Values, Not Derived Destinations
 
-**Recommendation:** Report the effective destination, authentication kind, and
-default profile reference. Use `InspectConfiguration` for authored values and
-provenance. Reuse existing optional values where helpful; no duplicate declared
-endpoint or derived-status flag is required merely for symmetry.
+**Status:** Resolved by the resource-inspection boundary.
 
-**Alternative:** Include declared overrides alongside effective destinations when
-operators need that distinction in one backend view. Existing metadata may make
-this cheap, but the result then needs clear field meanings and consumer handling
-for both. Prefer directly available fields over a new provenance subsystem.
+**Decision:** Return diagnostic settings present in the resolved backend,
+including inherited endpoint overrides. Leave omitted endpoint settings absent;
+deriving a default destination belongs to diagnostic execution. The earlier
+proposal to expose both declared and computed destinations is removed. This
+avoids an additional representation and provider-specific derivation machinery
+in resource inspection.
 
 ## Implementation And Verification
 
-1. Resolve open public-contract choices relevant to selected work. Agree on any
-   engine-policy additions separately so an unresolved optional expansion does
-   not silently become a prerequisite for the resource APIs.
-2. Expand prompt inspection from captured data and expose existing presence in
-   profile/prepared results. Reuse or modestly extend current lookup/projection
-   paths; choose private interface layouts during implementation.
-3. Add namespace-aware backend inspection and effective destination derivation,
-   following the selected public error and result representation decisions.
-4. Add typed backend inheritance. Implement any separately selected engine-policy
-   reporting using the owning components' effective values.
-5. Update GoDoc, consumer/internal guidance, and release notes with implemented
-   behavior and any deliberate compatibility changes. Coordinate CommandKit's
-   richer reports and omission handling without prescribing a new CLI framework.
+1. Resolve result representation/migration in decision 4. Decide typed prompt
+   construction separately; it is not a prerequisite for the selected work.
+2. Expose expanded prompt content and resolved profile fields through existing
+   capture/lookup paths, before execution completion. Preserve configured
+   presence/null distinctions without another composition pass.
+3. Add backend inspection and the accepted public missing-backend error,
+   returning configured diagnostic metadata without endpoint derivation.
+4. Add typed backend inheritance through the existing ConfigKit source helper.
+5. Update GoDoc, consumer/internal guidance, and release notes for the selected
+   behavior and profile compatibility change. Coordinate CommandKit reporting.
 
-Select focused offline tests for actual behavior and boundary risks:
+Use focused offline tests for actual boundary risks:
 
-- Newly exposed prompt fields reflect captured inline/imported content and
-  order, without introducing rendering or related-resource dependencies.
-- Profile and prepared output preserve explicit zero and distinguish controls
-  that execution omits, including relevant inheritance and override cases.
-- Backend results cover effective defaults/destinations, namespace selection,
-  and applicable error behavior. Use cases with missing optional credentials or
-  unresolved diagnostic profile references protect independent inspection.
-- Returned mutable values cannot alter retained state. Reuse existing ownership
-  tests and copy helpers rather than prescribing extra snapshots or allocations.
-- Typed backend inheritance works through real ConfigKit composition; its
-  generic composition rules do not need another full test matrix.
-- Any selected policy-reporting fields reflect their owners' effective settings.
+- Child resources show the resolved inherited fields and overrides, not an
+  unresolved `extends` directive; explicit zero survives and absent fields
+  remain distinguishable from configured null where meaningful.
+- Profile inspection excludes settings supplied only by a referenced backend,
+  framework execution defaults, or a request. Existing execution still applies
+  those settings through its ordinary resolution path.
+- Prompt inspection exposes captured inline/imported content, metadata, and
+  order without rendering or adding related-resource lookup dependencies.
+- Backend inspection reports configured/inherited diagnostic overrides while
+  leaving omitted overrides absent. It does not require diagnostic readiness.
+- Resource selection, error classification, and mutable-result ownership follow
+  the selected contract; reuse existing namespace and ownership coverage.
+- Typed backend inheritance works through real ConfigKit composition without
+  retesting ConfigKit's entire generic inheritance feature set.
 
-CommandKit can test its own output omission and explicit-zero presentation.
-Follow the [testing policy](../policy/testing.md); combine cases where useful,
-reuse existing coverage, and do not turn this list into a test-per-field mandate.
-No new benchmark threshold or release gate follows from this roadmap.
+CommandKit owns presentation tests for the migrated resource view. Follow the
+[testing policy](../policy/testing.md), combine cases where useful, and reuse
+existing coverage. No new benchmark threshold or release gate is selected.
 
-Completion means the selected fields give operators a materially fuller and
-accurate resource view, omission-aware settings are available to report builders,
-and existing preparation remains usable for a concrete request. Backend source
-inheritance is exposed. The resolved decisions define additional policy fields,
-public representations, and compatibility changes; exhaustive execution-policy
-coverage, typed prompt construction, listing changes, and speculative future
-adapters are not implicit completion conditions.
+Completion means operators can inspect the resolved selected prompt, profile,
+or backend accurately without assembling execution settings or navigating raw
+configuration paths. Backend inheritance is available through the typed source
+helper, and consumers have migration guidance for changed profile inspection.
+No engine-policy or prepared-request additions are part of completion.