Plan ConfigKit adoption and configuration migration

This commit is contained in:
2026-09-30 00:50:46 +00:00
parent 521291d80f
commit 80131fa160
2 changed files with 577 additions and 11 deletions

View File

@@ -1,8 +1,9 @@
# ConfigKit Adoption
Status: agreed feature roadmap. ConfigKit v0.5.0 supplies the
required upstream capabilities. A separate implementation plan will define stages,
signatures, and execution details. No implementation is authorized by this document.
Status: agreed feature roadmap. ConfigKit v0.5.0 supplies the required upstream
capabilities. The [implementation plan](implementation.md) owns execution steps
and identifies one remaining catalog-validation placement decision. This document
owns the intended end state, not implementation authorization.
## Purpose
@@ -171,8 +172,8 @@ provider setting deliberately suppresses it; it must not restore the same settin
from backend defaults. A null provider map suppresses the configured lower map,
while null entries inside a provider map remain literal JSON null values. This
supports reusable bases and deliberate removal of stale settings without changing
ConfigKit's merge rules. Framework-required settings such as timeouts need explicit
field-by-field rules in the implementation plan rather than blanket nil defaulting.
ConfigKit's merge rules. Framework-required settings such as timeouts have explicit
field-specific null semantics rather than blanket nil defaulting.
Preserve ConfigKit public loading errors through wrapping for `errors.As`, with a
PromptKit configuration category. Use source-aware domain/resource failures where
@@ -231,9 +232,8 @@ Expose a read-only inspection view backed by retained ConfigKit state, with
targeted path queries, source/history information, and explicit redacted effective
and explanation output. Reuse suitable public ConfigKit inspection values rather
than mirroring them. Do not expose mutable runtime definitions, resource capabilities
merely for diagnostics, or request credentials. Exact Go signatures belong in the
implementation plan; the scope is generic targeted inspection, not just narrow
profile/prompt origin summaries.
merely for diagnostics, or request credentials. The scope is generic targeted
inspection, not just narrow profile/prompt origin summaries.
PromptKit ships no CLI and emits no automatic debug reports. Applications own
presentation, access control, and disclosure; redaction does not make all prompt
@@ -311,6 +311,5 @@ does not discard lower endpoint, reasoning, provider, or inheritance settings.
The end state is one shared configuration model with the old loading/resolution
machinery removed, useful operator inspection, and all substantive execution
workflows still available. The six previously open design choices have been
approved and incorporated into the owning sections above. Field-level details and signatures
belong in the decision-complete implementation plan, not a compatibility-preserving
reinterpretation of this roadmap.
approved and incorporated into the owning sections above. This is not a
compatibility-preserving reinterpretation of the existing configuration engine.