Plan configuration input destination implementation

docs/roadmap/input-destinations.md

@@ -1,10 +1,10 @@
 # Configuration Input Destinations Roadmap
 
-Status: design decisions approved; implementation has not started. Execute the
-stages below in order. This roadmap responds to the
-[PromptKit feature request](promptkit-feature-request.md) and owns the target
-state, delivery sequence, and selected design decisions. Public API spelling and
-diagnostic details remain to be finalized during implementation planning.
+Status: design decisions approved; implementation has not started. This roadmap
+responds to the [PromptKit feature request](promptkit-feature-request.md) and owns
+the target state and selected design decisions. The
+[implementation plan](implementation.md) owns sequencing, implementation details,
+and completion evidence.
 
 ## Targeted end state
 
@@ -20,9 +20,9 @@ For example, a fragment defining `summarize.alerts` can contribute beneath
 local key can contribute beneath another collection without conflict. Collection
 and prompt names remain ordinary application keys, not ConfigKit namespaces.
 
-The intended public surface is per-input placement, illustratively an optional
-`Destination Path` field on `Input`, not a new loading entry point or an operation
-on completed results. Content-bearing main inputs and underlay inputs support
+The public surface adds an optional `Destination Path` field on `Input`, not a
+new loading entry point or an operation on completed results. Content-bearing
+main inputs and underlay inputs support
 the same destination model; root placement remains the default.
 
 The following behavior defines the target:
@@ -120,119 +120,6 @@ or a second configuration model. The
 consistency constraints; [deferred scope](deferred.md) continues to govern the
 unrequested features above.
 
-## Ordered implementation plan
-
-### 1. Settle placement semantics and the public contract
-
-Finalize public API spelling using the Selected Design Decisions below for
-main/NoSource behavior, placement inspection, reserved-key handling, and
-empty-contribution semantics. Define destination validation and
-structured errors, including when validation occurs relative to source access.
-Use existing error categories where suitable rather than inventing a parallel
-error system.
-
-Record the significant assembly decision in an ADR. Review compatibility under
-the release policy, including exported struct changes and unchanged zero-value
-behavior. Keep unimplemented claims in the roadmap; update canonical contracts
-when implementation lands. Do not turn unrelated deferred features into work.
-
-Completion: selected semantics cover the request's public acceptance scenarios
-and a simple consumer as well as PromptKit's multi-collection workflow.
-
-### 2. Carry destinations through acquisition and imports
-
-Thread the selected destination through root-to-engine conversion and private
-load requests. Preserve its ownership and semantic key representation. Separate
-source-local directive processing from application placement: extract directives
-at their original root, inherit placement through traversal, and place application
-content before checks and composition that require effective paths.
-
-Make version protection destination-aware for underlay roots and imported
-fragments, preserving the main check's lifecycle position. Ensure diagnostics
-produced before final composition identify effective application paths where
-available while preserving actual source coordinates. Structural directive
-errors still need their genuine source-local declaration locations.
-
-Retain repeated-source detection across the whole strict group, independent of
-destination. Preserve filesystem namespace, resource contexts, and traversal
-ordering. Account for destination depth and introduced nodes using existing
-budgets; distinguish them from acquired source bytes and physical source count.
-
-Completion: all content-bearing source kinds and transitive imports contribute
-at the intended destination, with correct version protection and source identity.
-
-### 3. Integrate composition, provenance, and the final lifecycle
-
-Apply ordinary composition to placed contributions and ordinary overlay between
-tiers. Retain each source application at its effective placement for history;
-carry real source attribution and the selected synthetic-container convention
-through origin construction. Avoid a separate merge algorithm or a mount registry.
-
-Exercise overlapping destinations, empty mappings, and a version-only domain
-override. Resolve sibling inheritance after the full precedence assembly, then
-use existing defaults, typed decoding, resolution, secrets, and validation.
-Check protection of the specification path through inheritance, selected
-overlays, and CLI overrides as well as direct contributions.
-
-Completion: mounted and explicitly wrapped equivalents agree on values,
-conflicts, presence, and lifecycle results; physical locations remain accurate.
-
-### 4. Complete inspection and public consumer workflows
-
-Expose placement through the selected existing inspection surface, with detached
-records. Verify effective paths throughout metadata, explanation replay, history,
-rendering, and diffs. Apply the existing sensitivity rules to mounted and inherited
-fields, including superseded values. Do not fabricate coordinates for wrappers
-that were never written in a source file.
-
-Demonstrate source-relative resource lookup from both resolution and completed
-results, including inherited fields and lower-tier fields surviving an override.
-Add executable public examples for one mounted fragment and a representative
-multi-collection assembly with peer composition and an intentional override.
-Applications select sources and destinations; the examples should require no
-consumer-side parsing, generic merging, or provenance reconstruction.
-
-Completion: the supported root API is sufficient for the requested end-to-end
-workflow, including accurate placement and source-relative resource inspection.
-
-### 5. Validate the full feature and update owning documentation
-
-Use engine tests for placement mechanics and public tests for observable loading
-and inspection. Map every scenario in the request's acceptance table to a test
-or executable example, reusing existing coverage where it proves the same
-behavior. Include focused cases for:
-
-- omitted/empty destinations, literal escaped and numeric keys, invalid index
-  destinations, and the approved reserved-key and main-input rules;
-- different destinations, shared destinations, ancestor overlaps, equal and
-  unequal conflicts, explicit null, omitted fields, and empty contributions;
-- recursive precedence, atomic sequences, and domain-version-only overrides;
-- inherited import destinations, source-root directives, repeated physical
-  sources at different destinations, and unchanged cycle/containment behavior;
-- nested ordinary version fields versus actual protected-path and ancestor
-  claims, including mounted imported content;
-- local inheritance across peers and source contexts after inheritance/overlay;
-- effective diagnostic paths with real locations, callback paths, history,
-  rendering, diffs, and classified values protected with disposable canaries;
-- equivalent content across every supported source kind, invalid loads with no
-  usable result, introduced depth/node limits, and detached inspection ownership.
-
-Follow the [testing policy](../policy/testing.md): protect observable contracts
-without fixing incidental wrapper allocation or helper-call sequences. Run
-focused tests, then the everyday check and ownership race validation in the
-[development guide](../development.md). Validate local documentation links.
-No independent performance benchmark runs are required for this roadmap.
-
-Update declaration documentation, the configuration contract, consumer guidance,
-and the component overview as their behavior lands. Document how source-local
-coordinates relate to effective paths and how placement is inspected. Review
-release compatibility separately from publication; feature completion does not
-authorize a release.
-
-Completion: all requested public scenarios pass, owning documentation describes
-implemented behavior, and consumers can perform one complete layered load with
-no compensating source-rewriting or post-load structural pass.
-
 ## Selected Design Decisions
 
 ### Main-input destinations and absent inputs
@@ -246,8 +133,8 @@ across its roles and preserves absence without per-fragment version checks.
 
 ### Public placement inspection and synthetic ancestors
 
-Expose effective placement on existing source records,
-illustratively `SourceInfo.Destination`, including inherited import placement.
+Expose effective placement as `SourceInfo.Destination Path` on existing source
+records, including inherited import placement.
 Use original source identity for introduced ancestor mappings, documenting that
 any root-location fallback identifies the contributing document rather than a
 physically authored wrapper. Actual content keeps its real coordinates. This