Plan ConfigKit overlays for testing with cheaper models

docs/roadmap/library-boundary-findings.md

@@ -4,6 +4,12 @@
 production migration target; not the current Audita configuration contract.
 The [bounded roadmap](library-boundary.md) owns scope and completion criteria.
 
+**Subsequent scope decision:** The [ConfigKit overlay plan](configkit.md#selected-overlays-for-testing)
+adds optional selected overlays, with v0.4.0 as the migration baseline. It supersedes
+the original no-overlay decision and adds an input layer between the main file and
+explicit setting overrides. The v0.3.1 prototype results below remain historical
+evidence; they do not establish overlay integration.
+
 ## Selected Boundary
 
 The prototype lives in [examples/library-adoption](../../examples/library-adoption/README.md),
@@ -87,8 +93,10 @@ Selected for the prototype and recommended for production:
   credentials and the future optional section target accept null. Explicit empty
   module lists will mean an empty correction pipeline, not “restore defaults.”
   Repeated modules retain their existing ordered meaning.
-- Do not enable ConfigKit imports, configuration profiles, or secret-directory
-  bootstrap. These are distinct from PromptKit execution profiles.
+- The original prototype disabled ConfigKit imports, selected configuration layers
+  (then called configuration profiles), and secret-directory bootstrap. Selected
+  overlays are now planned under the linked overlay decision; the other two
+  features remain disabled. PromptKit execution profiles retain their meaning.
 
 Configuration validation/inspection must assemble and inspect both selected profiles
 without provider calls. ConfigKit's effective YAML describes only its loaded state;