From 06315062b320890a208bce1480b96a2dd6ec69b6 Mon Sep 17 00:00:00 2001 From: Eric Rakestraw Date: Fri, 6 Nov 2026 03:43:00 +0000 Subject: [PATCH] Define inspection around resolved resource configuration --- docs/roadmap/inspect-backend.md | 481 +++++++++++++++----------------- 1 file changed, 220 insertions(+), 261 deletions(-) diff --git a/docs/roadmap/inspect-backend.md b/docs/roadmap/inspect-backend.md index 1cd7f84..b78ff52 100644 --- a/docs/roadmap/inspect-backend.md +++ b/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.