Plan conversation continuation and execution groups

docs/roadmap/conversation-continuation.md

@@ -1,8 +1,9 @@
 # Conversation Continuation And Execution Groups
 
-Status: target behavior accepted; ready for API and staged implementation planning.
-No implementation is authorized by this document. Exact public types and
-signatures remain to be designed. Execution groups are independently deliverable.
+Status: target behavior accepted; concrete API choices and implementation steps
+are recorded in the [implementation plan](implementation.md). This document
+defines the target behavior and responsibility boundaries. Execution groups are
+independently usable.
 
 ## Purpose And Responsibility Boundary
 
@@ -390,44 +391,13 @@ Applications retain their received results; the coordinator's termination value
 is not an archive. These examples should remain usable through the same generic
 API without manual history assembly or per-turn lifecycle bookkeeping.
 
-## API Planning And Delivery
+## API And Implementation Ownership
 
-No product-level decisions remain open. The companion implementation plan should
-settle exact public types and signatures before implementation, within the
-accepted behavior above:
-
-- Capture opt-in syntax and exchange representation. Prefer a request option;
-  separate capture methods remain viable. Prefer a details accessor, while a
-  public value is viable if it preserves ownership and generic rendering.
-- Continuation request shape and placement of immediate-parent metadata, using
-  the message assembly order defined above.
-- Callback state, next-action types, normal outcomes, and the optional
-  undelivered-response result.
-- Collector attachment, observer composition, and summary field representation.
-  Start with the observer-compatible API. Explicit group fields remain a fallback
-  only if concrete ordinary/prepared/coordinator/callback usage sketches expose
-  awkwardness; either approach uses existing observation machinery.
-
-Check the concrete API against both consumer sketches and ordinary and prepared
-execution, including capture selection, exchange access, coordinator actions and
-results, and observer composition. Keep these choices consistent across the
-staged plan rather than leaving each implementation stage to choose its own
-public contract.
-
-Deliver in separable stages:
-
-1. **Capture and independent continuation:** expose execution-derived exchanges,
-   reusable branches, fresh follow-up settings, parent metadata, and details.
-   This lets consumers remove reconstruction and prefix-verification machinery.
-2. **Optional sequential coordinator:** build on continuation and ordinary
-   execution, validation, capacity, and observations. Refine both consumer
-   sketches against the concrete API.
-3. **Optional execution groups, on an independent track:** provide collection,
-   composition, snapshots, and aggregation. This can ship separately and need
-   not wait for or delay continuation or coordination.
-
-These stages guide a subsequent implementation plan; they do not authorize code
-changes or impose an ordering dependency on execution groups.
+The [implementation plan](implementation.md) selects the concrete API and steps
+for reaching this target. Both consumer sketches must remain expressible without
+manual history assembly or per-turn lifecycle bookkeeping. Execution groups
+remain independent of capture and coordination; the plan's ordering does not
+introduce a product dependency between them.
 
 ## Acceptance Scenarios