Organize downstream feature requests in the future roadmap

docs/roadmap/notarius-promptkit-wishlist.md

@@ -17,6 +17,12 @@ not prescriptive names or finalized Go contracts.
 
 ## Priority 1: Atomic Execution With Prepared Details
 
+**Disposition:** Covered by the accepted
+[executable preparation handles](future.md#executable-preparation-handles)
+catalog entry. The shared two-phase capability should provide the required
+single-preparation consistency; a separate `RunDetailed` method is not
+cataloged initially.
+
 ### Downstream need
 
 Notarius needs both:
@@ -83,6 +89,9 @@ corresponds atomically to the actual execution.
 
 ## Priority 2: Prompt-Independent Profile Inspection
 
+**Disposition:** Accepted into the
+[future catalog](future.md#prompt-independent-profile-inspection).
+
 ### Downstream need
 
 Notarius validates configured pipeline profile IDs before beginning a run. It
@@ -150,6 +159,9 @@ validation.
 
 ## Priority 3: Semantic Execution-Target Fingerprints
 
+**Disposition:** Deferred until prompt-independent profile inspection defines
+the resolved target whose configuration identity would be fingerprinted.
+
 ### Downstream need
 
 Notarius checkpoints model-backed pipeline stages. A checkpoint must not be
@@ -233,6 +245,9 @@ resolution.
 
 ## Priority 4: Structured Capacity Errors
 
+**Disposition:** Accepted into the
+[future catalog](future.md#structured-capacity-errors).
+
 ### Downstream need
 
 Notarius translates PromptKit backend-capacity rejection into a
@@ -342,4 +357,3 @@ Notarius would be:
 The first two address concrete workarounds in current Notarius code. The third
 would improve checkpoint correctness and reduce coupling. The fourth is
 operational polish.
-