Plan sequence placement and composition

docs/roadmap/sequence-composition.md

@@ -1,8 +1,8 @@
 # Sequence-Item Placement and Identity-Based Composition
 
-Status: design decisions settled; not implemented. This roadmap records the
-agreed scope and behavior for final review. A separate staged implementation
-plan will be prepared after that review.
+Status: design decisions settled; not implemented. This roadmap owns the target
+state and accepted behavior. The [implementation plan](implementation.md) owns
+concrete API/syntax choices, execution order, validation, and progress.
 
 ## Goal and current baseline
 
@@ -147,7 +147,8 @@ contracts, not a new promise of persistent identity-based paths across loads.
 
 ## Work needed
 
-After final roadmap review, the staged plan will sequence these areas:
+The target state requires changes in these areas; execution order belongs to the
+[implementation plan](implementation.md):
 
 - **Public API and import syntax:** introduce the selected composition
   registration and placement controls at the existing root-owned boundaries;
@@ -177,21 +178,19 @@ After final roadmap review, the staged plan will sequence these areas:
 - **Documentation and adoption:** provide a maintained PromptKit-shaped example
   and update public declaration comments, configuration/inspection contracts,
   consumer guidance, and relevant internal documentation when behavior lands.
-  Record the significant design decision under the architecture policy during
-  implementation; no ADR is created by this roadmap update. Keep the broader
-  candidate in `future.md` distinct from the implemented subset.
+  Record the significant design decision under the architecture policy and keep
+  the broader candidate in `future.md` distinct from the implemented subset.
 
 Completion means the PromptKit example works through public inputs and imports,
 composition and replacement behave as agreed, and configuration values agree
 with their inspection evidence. Validation follows the
-[development guide](../development.md#baseline-validation). This documentation
-pass neither implements the feature nor runs performance benchmarks.
+[development guide](../development.md#baseline-validation).
 
 ## Settled Decisions
 
 The following choices are accepted for this feature. No substantive design
-choices remain open in this roadmap. Exact public names, YAML option names,
-and error-code spellings will be selected during API design in the staged plan.
+choices remain open in this roadmap. The implementation plan selects exact
+public names, YAML option names, and existing diagnostic-code mappings.
 Internal representations remain implementation choices, subject to the existing
 contracts and the behavior recorded here.