Plan staged implementation of the testing overlay prototype

docs/roadmap/library-boundary.md

@@ -1,17 +1,67 @@
 # Library Adoption: Shared Boundary and Prototype
 
-**Last updated:** 2026-09-23
+**Last updated:** 2026-09-24
 
-**Status:** Completed bounded boundary-design and offline-prototype unit.
+**Status:** Original boundary-design and offline-prototype unit completed;
+overlay extension and production-planning handoff planned.
 Production migration has not started. The work packages below retain the original
 scope; [decisions, evidence, limitations, and handoff](library-boundary-findings.md)
 record the outcome. The [executable prototype](../../examples/library-adoption/README.md)
 is isolated from production. No publication or upstream changes were made.
 
-**Subsequent scope decision:** Enable ConfigKit v0.4.0 selected overlays for testing
-in the next configuration unit. The [overlay plan](configkit.md#selected-overlays-for-testing)
-supersedes the original optional-feature exclusion below; the completed prototype
-has not yet exercised overlays.
+## Next Unit: Testing Overlays and Production Migration Plan
+
+**Status:** Planned; not implemented. Execute the ordered stages in
+[implementation.md](implementation.md). The original work packages below remain
+historical scope for the completed first unit.
+
+Extend the existing prototype to prove the [selected-overlay contract](configkit.md#selected-overlays-for-testing)
+with ConfigKit v0.4.0, then turn the verified findings into a detailed production
+ConfigKit migration plan. Do not repeat the original inventory or redesign the
+established library boundary without new evidence.
+
+Required work:
+
+- Upgrade only the nested prototype module from ConfigKit v0.3.1 to v0.4.0.
+- Pass an explicit overlay selection through ConfigKit and add `overlays/testing.yml`
+  plus two PromptKit testing profiles. Select both roles and retain one shared
+  finite backend. Synthetic model names demonstrate routing; they do not benchmark
+  real model cost, speed, or quality.
+- Make the offline executable accept overlay and explicit role-profile selections,
+  and show the selected models alongside domain outcomes and retry/repair counts.
+- Verify base/overlay/CLI precedence, role inheritance, invalid selections,
+  surviving credential references, safe inspection, and overlay provenance.
+  Prove the actual HTTP request models for both roles; loading changed strings
+  alone is insufficient evidence.
+- Record new results separately from the historical v0.3.1 findings. Expand the
+  existing ConfigKit roadmap into a concrete production implementation handoff,
+  including the interim runtime boundary and removal of legacy configuration.
+
+Target end state: reviewers can run the prototype with and without the testing
+selection and see both LLM roles switch models. The offline test suite establishes
+that selection, inspection, and execution agree, and the production ConfigKit work
+has bounded tasks with explicit acceptance criteria.
+
+Acceptance criteria:
+
+- The published v0.4.0 dependency is pinned without local replacements; the original
+  no-overlay path and existing integration tests continue to pass.
+- `testing` switches both roles, explicit profile flags override its selections,
+  and omission/empty/`default` retains base selection according to ConfigKit.
+- Invalid overlays fail clearly; inheritance and secret resolution use surviving
+  effective settings. Inspection records overlay origin without disclosing keys.
+- Both selected testing models reach the controlled HTTP transport; structural
+  repair, shared capacity, observations, and Audita domain checks remain active.
+- Updated examples, executable instructions, findings, and a detailed production
+  migration plan are reviewable. Exact verification commands and limitations are
+  recorded, including the fact that root tests do not cover the nested module.
+- Production code, root dependencies, and upstream libraries remain unchanged.
+  No release or live provider call is part of this unit.
+
+This unit ends with a production migration **plan**, not production implementation.
+The ConfigKit → PromptKit → combined release sequence remains unchanged. Imports
+and secret-directory bootstrap remain disabled; PromptKit execution profiles keep
+their existing names and meaning.
 
 ## Objective