61 lines
2.6 KiB
Markdown
61 lines
2.6 KiB
Markdown
# 0001: Configuration Ownership At The ConfigKit Handoff
|
|
|
|
## Status
|
|
|
|
Accepted.
|
|
|
|
## Date
|
|
|
|
2026-09-30
|
|
|
|
## Context
|
|
|
|
PromptKit is adopting ConfigKit to standardize configuration semantics and
|
|
simplify its loading machinery. Configuration includes prompts, profiles, and
|
|
backend definitions contributed by maintained catalogs and consuming applications.
|
|
ConfigKit supplies loading, composition, precedence, inheritance, and inspection
|
|
capabilities. PromptKit supplies LLM-specific interpretation and execution.
|
|
|
|
A clear handoff assigns each library responsibility for the configuration it
|
|
owns and keeps validation aligned with the values an application actually uses.
|
|
|
|
## Decision
|
|
|
|
ConfigKit owns configuration processing up to the handoff of the final effective
|
|
configuration. PromptKit takes ownership at that handoff and applies its domain
|
|
interpretation and validation to the final configuration.
|
|
|
|
The handoff includes effective presence/null information and resource context
|
|
supplied by ConfigKit. PromptKit uses this information to interpret effective
|
|
settings and resolve referenced resources.
|
|
|
|
PromptKit passes through ConfigKit's inspection capabilities for explicit
|
|
operator use. Configuration history and source explanations serve that
|
|
inspection purpose; domain validation operates on the final effective values.
|
|
|
|
This boundary applies uniformly to application configuration and maintained
|
|
catalog configuration, including backend definitions.
|
|
|
|
## Alternatives Considered
|
|
|
|
- **Independent source or catalog preflight validation:** preserves checks on
|
|
individual contributions, but duplicates configuration processing and evaluates
|
|
values that may be replaced before handoff. Raw-source and intermediate-state
|
|
validation are outside PromptKit's scope, including equivalent test-only checks.
|
|
- **History-based source auditing:** can identify overwritten contributions, but
|
|
couples domain enforcement to configuration history. Historical inspection is
|
|
an operator capability rather than a validation mechanism.
|
|
|
|
## Consequences
|
|
|
|
PromptKit's configuration logic and tests focus on the final effective values,
|
|
their domain meaning, and resulting execution behavior. ConfigKit owns failures
|
|
arising during its processing, which PromptKit preserves through its error
|
|
boundary. Catalog maintainers own their repositories' publishing checks.
|
|
|
|
The adoption work routes backend configuration through the same handoff and
|
|
retires PromptKit's source-level and intermediate-configuration validation.
|
|
Effective resource interpretation and explicit operator inspection remain
|
|
supported. This concentrates configuration semantics in ConfigKit and reduces
|
|
duplicated machinery and maintenance in PromptKit.
|