Accept the ConfigKit configuration boundary and align the implementation plan

docs/roadmap/configkit.md

@@ -1,9 +1,10 @@
 # ConfigKit Adoption
 
 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.
+capabilities. The [implementation plan](implementation.md) owns execution steps.
+The [configuration-boundary ADR](../adr/0001-configuration-boundary.md) records
+the handoff decision. This document owns the intended end state, not
+implementation authorization.
 
 ## Purpose
 
@@ -70,18 +71,23 @@ exist. Domain validation must not probe provider/model availability.
 
 ### One Shared Loading Lifecycle
 
-Construction acquires configuration contributions, uses ConfigKit to compose and
-overlay them, expands sibling inheritance, decodes the effective configuration,
-performs recorded domain resolution and validation, and produces execution-ready
-definitions. Publish no partially initialized engine on failure.
+Construction supplies selected configuration inputs to ConfigKit, which composes,
+overlays, expands inheritance, and decodes them. PromptKit interprets and validates
+the final effective configuration at the ConfigKit handoff and produces
+execution-ready definitions. ConfigKit's effective-value resolution and validation
+hooks may implement that handoff. Publish no partially initialized engine on failure.
 
 ConfigKit owns generic parsing, combination, presence, origins, and inheritance.
-PromptKit owns source selection/discovery, definition indexing, backend policy,
-LLM-specific rules, and translation into runtime values. Runtime clients and
-callbacks remain normal Go dependencies, not YAML configuration types.
+PromptKit owns input selection/discovery, definition indexing, LLM-specific rules,
+and translation of final values into runtime settings. Input adapters select or
+encode contributions; they do not inspect or validate raw source contents.
+Effective presence/null information and resource context supplied by ConfigKit
+support interpretation at handoff. Historical inspection remains an explicitly
+invoked operator capability, separate from domain enforcement.
+Runtime clients and callbacks remain normal Go dependencies, not YAML types.
 
-Use `profiles.<id>` and `prompts.<id>.<version>` keyed mappings assembled before
-typed decoding rather than independently decoding definitions and combining them
+Use `backends.<id>`, `profiles.<id>`, and `prompts.<id>.<version>` keyed mappings
+assembled before typed decoding rather than independently decoding definitions and combining them
 afterward. Keys own identity; do not duplicate `id`/`version` fields. These paths
 describe mapping levels, not dot-splitting of literal IDs or version keys.
 Multiple files can contribute to a collection; a monolithic file is not required.
@@ -96,7 +102,11 @@ Accept ConfigKit's labeled mapping sources for programmatic configuration. Add
 only small typed conveniences justified by the minimal local-backend and
 application-profile workflows. Helpers encode explicit presence and feed the same
 loading lifecycle; they neither merge configurations nor infer omission from zeros.
-HTTP/model clients and other runtime collaborators remain outside typed configuration.
+Backend helpers also produce inputs to this lifecycle. Backend definitions,
+including catalog connection and capacity settings, cross the same ConfigKit
+handoff as prompts and profiles. The immutable runtime registry is built from
+effective backend values. HTTP/model clients and other runtime collaborators
+remain outside typed configuration.
 
 Keep the public package a deliberate facade and implementation private. Do not
 expose internal engine/domain types or introduce a parallel generic loader merely
@@ -110,12 +120,15 @@ programmatic definitions. Explicitly selected directories may be discovered by
 PromptKit; ConfigKit handles their configuration contributions. Do not infer
 priority from traversal order.
 
-Retain the useful profile priority categories, lowest to highest: external
+Retain the useful priority categories, lowest to highest: external
 catalogs, PromptKit-owned profiles, application fallback, operator configuration,
 and programmatic configuration. Express intentional priority as ordered tiers.
 Within each tier, independent contributions compose strictly; overlapping
 non-mapping values conflict, even when equal. Disjoint fields under the same
 identity can combine. Across tiers, mappings recursively overlay.
+These rules also govern backend configuration; consumers can add backend IDs or
+overlay existing definitions through their selected tiers. Registry construction
+validates the resulting values, not the identity of their contributors.
 
 Use ConfigKit's source roles honestly: underlay groups are ordered defaults,
 main input overlays underlays, and optional named overlay/CLI facilities retain
@@ -155,11 +168,14 @@ Document and test this distinction, including any affected maintained payloads.
 
 ### Validation And Errors
 
-Source acquisition, syntax, and strict-composition failures cannot be masked by
-higher tiers. Typed and semantic validation apply to effective values rather than
-every intermediate layer. An unused invalid effective definition fails construction.
-Separate catalog ownership/reserved-name/secret-safety checks remain source-policy
-responsibilities, not justification for duplicate generic decoding.
+ConfigKit owns acquisition, syntax, composition, inheritance, and typed-decoding
+failures. PromptKit preserves those errors and validates final effective domain
+values. An unused invalid effective definition fails construction; a lower-layer
+value legitimately replaced by ConfigKit is not a separate validation target.
+This boundary applies equally to application and maintained catalog configuration.
+PromptKit does not perform catalog preflight, raw-source or intermediate-state
+validation, or history-based enforcement, including equivalent test-only checks.
+Catalog maintainers own publishing checks in their respective repositories.
 
 Domain validators remain shared with runtime request validation where appropriate.
 Allow schema-valid partial profiles without an `abstract` flag. Validate supplied
@@ -246,13 +262,18 @@ or configuration content safe to publish.
 - Remove the custom profile inheritance resolver and error-driven repository
   overlay stack. Do not retain an old-format compatibility engine alongside the
   new semantics.
+- Route catalog and programmatic backend definitions through ConfigKit; retire
+  the separate backend-manifest decoder and pre-handoff registration validation.
+  Retain backend endpoint, capacity, and provider-parameter domain validation on
+  the final effective values.
 - Retain only needed discovery and message-resource adapters; remove direct YAML
   dependency usage once no remaining owner needs it. Preserve JSON Schema,
   runtime JSON-value ownership, domain validation, and execution collaborators.
 - Adapt maintained catalogs and PromptKit-owned definitions to the agreed keyed
-  format and released inheritance semantics. Preserve maintained name commitments,
-  backend ownership, and catalog namespace rules without upstream availability
-  checks. Coordinate necessary catalog releases before consuming their new format.
+  format and released inheritance semantics, including keyed backend assets.
+  Preserve maintained name commitments and the intended shipped backend settings.
+  Catalog source-policy enforcement belongs to catalog maintainers. Coordinate
+  compatible catalog releases before consuming the changed asset format.
   Publish new keyed assets directly in the existing data-only catalog projects,
   recording the format transition rather than maintaining duplicate legacy assets
   or a permanent conversion adapter. Catalog maintainers select release/version
@@ -282,7 +303,9 @@ the requested report; that work remains off the execution path.
 Tests should use real ConfigKit with offline sources and synthetic provider
 collaborators. PromptKit owns its adapter, domain, lifecycle, and execution tests,
 not a duplicate ConfigKit parser/graph suite. Retire tests whose only purpose was
-the removed loading machinery. Preserve meaningful execution regressions.
+the removed loading machinery or source-policy enforcement. Exercise catalog
+integration through the final assembled configuration and resulting behavior.
+Preserve meaningful execution regressions.
 
 Representative acceptance evidence must cover:
 
@@ -305,7 +328,8 @@ release gates or provider-network tests.
 Ship as an intentionally incompatible minor release with concrete migration
 guidance. Cover keyed files, `base_profile` to `extends`, reserved-key behavior,
 recursive maps, explicit null versus omission, changed error timing, programmatic
-construction, and explicit engine replacement. Explain that overriding a model
+construction, backend layering in place of registration-only restrictions, and
+explicit engine replacement. Explain that overriding a model
 does not discard lower endpoint, reasoning, provider, or inheritance settings.
 
 The end state is one shared configuration model with the old loading/resolution