Plan the ConfigKit v1 resource migration

docs/roadmap/configkit.md

@@ -3,6 +3,9 @@
 Status: accepted direction; implementation pending. This roadmap describes
 future behavior, not the currently supported configuration format.
 
+The companion [implementation plan](implementation.md) owns the ordered sprint
+steps and validation assignments.
+
 ## Purpose
 
 Adopt `go.maximumdirect.net/configkit` v1.0.0 and simplify authoring by using
@@ -234,88 +237,40 @@ same item-import pattern with `destination: [backends]` and can define backend
 variants using sibling `extends`. Inline resource lists are equally valid;
 one-file-per-item and directory layout are conveniences, not requirements.
 
-## Work And Sequencing
+## Acceptance And Compatibility
 
-### 1. Establish The ConfigKit v1 Baseline
+The integrated target supports inline lists and imported items at the root and
+in arbitrarily named collections. Equal local IDs in separate namespaces remain
+independent. Registered identities govern strict composition, inheritance,
+layering, and final typed values through ConfigKit. PromptKit retains its domain
+validation, presence-aware settings, partial profiles, and exact runtime lookup.
 
-Migrate the module, toolchain, affected APIs, and source controls while temporarily
-retaining resource mappings. Update fixtures and examples and validate that
-configuration loading, presence, inheritance, inspection, and execution retain
-their intended behavior. This isolates dependency migration failures from the
-later shape change; the intermediate state need not be separately released.
+Inherited and replaced prompt fields retain their contributing resource context.
+Sensitive provider values remain protected in inspection at index-based paths.
+Source builders preserve supplied record order and duplicate IDs for loading.
+Namespaces, discovery, inspection, preparation, concrete-request validation,
+smoke diagnostics, and execution consume the same captured resource indexes.
+These behaviors have focused offline coverage without duplicating ConfigKit's
+generic suite or promising incidental history formatting or list positions.
 
-Review module sums and the resolved dependency graph, and update
-[attribution](../oss/attribution.md) to the selected upstream revision and notices.
-ConfigKit's own release-tooling migration does not by itself require changing
+The [format reference](../formats.md), [consumer migration guide](../consumers/configuration-migration.md),
+[Go consumer guide](../consumers/pkg-promptkit.md), source-adapter documentation,
+GoDoc, and maintained examples describe the integrated target when it lands.
+Migration guidance covers the new module/types, Go minimum, controls, import
+requiredness, identified lists, explicit-ID source builders, sibling inheritance,
+removed prompt labels, specification headers, and index-based inspection paths.
+Attribution identifies the selected ConfigKit revision and applicable notices.
+
+Deliver this as one coordinated breaking pre-v1 minor upgrade under the existing
+[release policy](../policy/release.md), so applications and collection authors
+migrate once. Historical release notes remain intact. Scriptorium coordination
+does not make its release or internal implementation a PromptKit dependency.
+ConfigKit's own release-tooling migration does not require a change to
 PromptKit's release tooling or publication workflow.
 
-### 2. Convert The Configuration Adapter And Public Values
-
-Change root and collection resource decoding to identified records, register all
-six root/dynamic identity rules, and advance the optional specification checker.
-Adapt validation and runtime indexing to read IDs from records. Remove prompt
-version metadata throughout the relevant public and internal values.
-
-Review every path-dependent operation as mapping keys become list indexes:
-presence capture, profile/backend defaults, prompt input metadata, sensitive
-provider fields, errors, and effective resource lookup. Resolve `content_file`
-against the effective field's contributing source after inheritance and upsert.
-Retain one ConfigKit load and the existing effective-value handoff; source history
-must not become a second resolver.
-
-Update `BackendSource`, `ProfileSource`, and their public configuration values to
-use explicit-ID slices and encode profile inheritance as an identity reference.
-Update namespace views, listing, inspection, prepared execution, and smoke-test
-selection as needed to consume the same captured runtime indexes. Do not change
-their selection or execution semantics merely to mirror the new configuration
-representation.
-
-### 3. Exercise The Integrated Target
-
-Use focused behavioral coverage for the changed boundaries:
-
-- Root and arbitrarily named collections load inline lists and imported items;
-  equal local IDs in separate namespaces remain independent.
-- Duplicate IDs within a resource list fail, including final values introduced
-  through supported application resolution. Exercise the registrations through
-  PromptKit without duplicating ConfigKit's complete generic test suite.
-- Profile and backend variants inherit settings while preserving child identity,
-  explicit zero/false/null behavior, and ordinary domain validation.
-- Layered upsert replaces a whole record; explicit list replacement and empty
-  contributions follow ConfigKit semantics.
-- Inherited and replaced prompt resources retain the correct source context;
-  provider credentials remain redacted at the new effective paths.
-- Optional version-2 headers and headerless fragments load; unsupported declared
-  versions and obsolete resource shapes fail through their owning validators.
-- Public source builders, namespace lookup, inspection, preparation, validation,
-  smoke tests, and execution still work with the converted catalogs.
-- Source builders preserve supplied record order and duplicate IDs for loading;
-  profile parent-ID strings produce the expected sibling inheritance references.
-
-Run the existing suite, relevant vet checks, and maintained offline consumer
-examples under Go 1.27. Tests require no live provider calls. Reuse existing
-coverage where it already proves the behavior; do not turn incidental history
-formatting or list positions into stronger guarantees.
-
-### 4. Publish One Coherent Migration
-
-Update the [format reference](../formats.md), [consumer migration guide](../consumers/configuration-migration.md),
-[Go consumer guide](../consumers/pkg-promptkit.md), source-adapter documentation,
-GoDoc, and maintained examples as implementation lands. Explain the module/type
-change, Go minimum, `config:` controls, import requiredness, resource lists,
-the source builders' map-to-slice conversion and explicit `ID` fields,
-mapping-to-record `extends` conversion, removed prompt labels, specification
-headers, and index-based inspection paths together.
-
-Plan a breaking pre-v1 minor release under the existing
-[release policy](../policy/release.md). Prefer delivering both implementation
-stages together so downstream applications and collection authors migrate once.
-Keep historical release notes intact. Coordinate Scriptorium's dependency and
-configuration updates without making its release or internal implementation a
-PromptKit dependency.
-
-The target format replaces the old resource mappings; this scope does not add
-dual-format decoding, source rewriting, catalog discovery conventions, or a
-compatibility module. Preserve operator choices already supplied by ConfigKit.
-Once implementation is complete, move durable behavior into its canonical
-owners and retire this temporary roadmap under repository practice.
+The target replaces the old resource mappings without adding dual-format
+decoding, source rewriting, catalog discovery conventions, or a compatibility
+module. Intermediate implementation states need not compile or be coherent;
+the companion plan targets one end-to-end sprint without intermediate human
+review or external publication gates. Durable behavior belongs in its canonical
+owners when complete; this roadmap remains temporary coordination material.