Plan staged implementation of reliable execution

docs/roadmap/reliable-execution.md

@@ -1,10 +1,9 @@
 # Reliable And Observable Execution
 
-**Status:** Feature roadmap; not implemented. This document defines the target
-end state. A separate implementation plan will supply sequential stages and
-prompt-level steps. The four policy decisions reviewed with the maintainer are
-settled below; exact API spelling, event field layout, and backoff timing values
-remain implementation-plan details.
+**Status:** Accepted feature scope; not implemented. This document owns the
+target end state and approved policy choices. The companion
+[implementation plan](implementation.md) owns implementation steps and concrete
+API and algorithm decisions.
 
 ## Purpose
 
@@ -48,8 +47,7 @@ Configure an engine default with a request-scoped retry-count override, using
 presence to distinguish omission from zero. Keep retry policy out of profile
 YAML initially. Per-request control supports mixed workflows without requiring
 separate engines and splitting their capacity pools. Use a modest fixed backoff
-policy; concrete timing values belong in the implementation plan, not a new
-public timing-configuration surface.
+policy without a new public timing-configuration surface.
 
 - Retry delays use exponential backoff with jitter and honor valid provider
   `Retry-After` timing as a minimum delay, subject to cancellation, rather than
@@ -193,7 +191,6 @@ Keep execution machinery under `internal/`; the root package remains a facade
 for intentional consumer contracts. Maintain one retry-policy owner and one
 capacity manager. Keep provider wire decoding in its adapter, lifecycle
 coordination in the execution layer, and application reporting downstream.
-Exact internal package arrangement belongs in the implementation plan.
 
 Do not add a second run API solely for diagnostics. Preserve existing operation
 signatures and optional-observation behavior for callers that do not use it.