Plan resource inspection and typed configuration sources

This commit is contained in:
2026-11-06 15:03:30 +00:00
parent 951739eda0
commit 8563379216
2 changed files with 592 additions and 63 deletions

View File

@@ -459,69 +459,30 @@ 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
## Acceptance Criteria
1. Define typed results, serialization names/nesting, and consumer migration
selected in decision 4. Account for presence across prompt, profile, and
backend results. Source-input helpers, inspection results, and execution
values have distinct purposes; reuse types only where their semantics fit.
2. Implement and verify the post-handoff null change as a focused unit, separate
from inspection projection. Remove presence machinery made unnecessary by
that change while retaining omission versus explicit-value information.
Verify the changed execution behavior and document its migration example.
3. Expose expanded prompt content and resolved profile fields through existing
capture/lookup paths, before execution completion, without another composition
pass or changes to ConfigKit's retained result. Support generic encoding with
the selected omission rules and preserve explicit values.
4. Add backend inspection and the accepted public missing-backend error,
returning configured diagnostic metadata without endpoint derivation.
5. Add typed backend inheritance and the prompt source/helper types, delegating
both to the ordinary ConfigKit mapping and loading path.
6. Update GoDoc, formats, consumer/internal guidance, and release notes for the
selected behavior, inspection-result migrations, and null compatibility
change. Coordinate CommandKit's generic reporting adoption.
The companion [implementation plan](implementation.md) owns the staged work
and verification sequence. The target is complete when:
Use focused offline tests for actual boundary risks:
- Prompt, profile, and backend inspection expose the selected resolved resource
with the boundary and presence semantics above, using ordinary JSON/YAML
encoding without per-field consumer adapters.
- Inherited values, explicit zero/false/empty settings, and provider-data nulls
are represented accurately; nullable resource nulls and omission are absent.
- Profile inspection excludes backend-completed execution values, and backend
inspection reports configured diagnostics without synthesizing destinations
or requiring diagnostic readiness.
- Prompt inspection includes captured inline/imported message content and
metadata without rendering or loading related resources.
- Execution applies the selected post-handoff null behavior while preserving
explicit clearing, map overlay, and ConfigKit's retained result and provenance.
- Selection, errors, captured-state isolation, and credential handling follow
the selected contracts. Requirement discovery retains its lightweight path.
- All three resource kinds have typed source helpers, including inheritance,
using ordinary ConfigKit composition, context, and snapshot behavior.
- Canonical guidance and the next minor release note explain changed Go
inspection types, generic rendering, source helpers, and null migration.
- Directly encode each inspection result with ordinary JSON and YAML encoders,
without consumer-specific report structures. Verify semantic field names,
nesting, omitted settings, explicit zero/false/empty values, and nested
provider data. Include prompt input/output and backend capacity presence,
rather than testing only profile fields. Assert semantic output, not incidental
whitespace or mapping-key order.
- Child resources show the resolved inherited fields and overrides, not an
unresolved `extends` directive; explicit zero survives. Omitted/null nullable
settings use the same absent representation; provider-data nulls retain their
literal meaning.
- Null and omitted profile endpoint, credential-source, and provider-map fields
permit the same backend fallback. Explicit empty-string clearing and empty-map
overlay behavior remain intact. Include a ConfigKit inheritance case where
null clears a parent value before Promptkit applies backend defaults, and
verify that resource inspection does not rewrite the retained ConfigKit tree.
- 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 and prompt inheritance work through real ConfigKit composition.
Prompt sources preserve nested message/input/output settings, omission and
explicit values, ordering, and source snapshot behavior. Include a representative
relative content-file case using ordinary source context. Reuse generic loading,
validation, and inheritance coverage rather than duplicating it for each helper.
Promptkit owns the inspection serialization checks; CommandKit owns presentation
and delivery 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 operators can inspect the resolved selected prompt, profile,
or backend accurately through generic rendering, without per-field consumer
adapters, assembling execution settings, or navigating raw configuration paths.
All three resource kinds have typed source helpers, including inheritance
support, and consumers have migration guidance for changed inspection results
and post-handoff null semantics.
No engine-policy or prepared-request additions are part of completion.
Promptkit owns resource serialization checks; CommandKit owns presentation and
delivery. No engine-policy or prepared-request additions, benchmark threshold,
or new release gate is part of this feature.