Accept the ConfigKit configuration boundary and align the implementation plan

docs/adr/0001-configuration-boundary.md

@@ -0,0 +1,60 @@
+# 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.