Add feature roadmap and implementation plan for downstream consumer wishlist items

docs/roadmap/future.md

@@ -33,25 +33,9 @@ consumers.
 
 ## Ideas
 
-### Executable preparation handles
-
-Allow a consumer to prepare one exact execution, inspect and retain its
-caller-owned preparation details, and later execute that already-prepared work
-without reloading or rerendering prompt, profile, schema, or input sources.
-This would remove the duplicate `Prepare`-then-`Run` workaround reported by
-[Notarius](notarius-promptkit-wishlist.md#priority-1-atomic-execution-with-prepared-details)
-and
-[Weatherreporter](weatherreporter-promptkit-wishlist.md#priority-1-executable-preparation-handles).
-
-- Keep the handle opaque, engine-bound, non-serializable, and initially
-  one-shot.
-- Keep existing `Prepare` and `Run` workflows available.
-- Return public preparation details under existing caller-ownership and
-  credential-redaction rules.
-- Perform backend admission when execution begins rather than reserving
-  capacity while a consumer retains the prepared handle.
-- Treat a separate atomic detailed-run method as possible later convenience
-  rather than a second initial execution model.
+Executable preparation handles have been selected for active planning in the
+[focused feature roadmap](prepared-execution.md). The remaining ideas are
+still available for future selection.
 
 ### Prompt-independent profile inspection