base-layer/promptkit
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 7 Wiki Activity

Define inspection around resolved resource configuration

Browse Source
This commit is contained in:
Eric Rakestraw
2026-11-06 03:43:00 +00:00
parent c669f14610
commit 06315062b3
1 changed files with 220 additions and 261 deletions
Download Patch File Download Diff File Expand all files Collapse all files

481
docs/roadmap/inspect-backend.md
View File

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