fix: address presentation review findings

docs/superpowers/specs/2026-07-12-presentation-live-replay-activation-design.md

@@ -26,9 +26,10 @@ when `wf-rpc-server` is running.
 
 ### Launch surface
 
-Expose a compact prepared-run control on Scene 10's `operation` beat. It is a
-scene-owned control, not a reintroduced chat rail. It must remain visible while
-the target is checking, ready, failed, or the live run is active.
+Expose one compact prepared-run control in `PresentationFooter` throughout
+Scenes 8-12. It is demo chrome, not a reintroduced chat rail or a scene-owned
+launch panel. Scene 10 remains the semantic execution start even when the
+presenter starts or prepares the run from an earlier demo scene.
 
 The control communicates the current action:
 
@@ -83,8 +84,8 @@ discussion views should not gain a persistent live-service badge or run action.
 
 ## Acceptance Criteria
 
-1. With `wf-rpc-server` and the web server running, Scene 10's operation beat
-   visibly exposes `Run prepared workflow` and starts a live timeline.
+1. With `wf-rpc-server` and the web server running, the compact footer rail on
+   Scenes 8-12 exposes `Run prepared workflow` and starts a live timeline.
 2. A live run records deployment inspection, run start, interrupt, resume, and
    trace evidence using the existing `callOperation` path.
 3. The typed approval form remains the only way to provide the resume decision;
@@ -97,8 +98,9 @@ discussion views should not gain a persistent live-service badge or run action.
    recovered with retry, without reloading the page or reconnecting manually.
 7. The launch control cannot issue duplicate starts while an operation is in
    flight or a live run is already active.
-8. Scene 8 and Scene 9 remain deterministic authoring replay and do not call
-   workflow authoring RPC operations.
+8. Scene 8 chat Send and Scene 9 staged messages remain deterministic authoring
+   replay and do not call workflow authoring RPC operations. Their separate
+   footer control may start the prepared run.
 
 ## Verification
 

docs/superpowers/specs/2026-07-12-scene-8-chat-entry-design.md

@@ -44,8 +44,10 @@ The old five-step phase rail is removed from Scene 8. The lifecycle sequence is
 shown by Scene 9, where the authoring canvas is the primary artifact and the
 conversation becomes a secondary modal.
 
-The standalone `Run prepared workflow` action is removed from Scene 8. The
-workflow-run action belongs to Slice 3 and will be exposed in Scene 10.
+The standalone in-scene `Run prepared workflow` action is removed from Scene 8.
+The later demo-chrome slice owns one compact footer rail across Scenes 8-12.
+That separate footer may expose the prepared-run action, while chat Send remains
+local and never starts a workflow.
 
 ### Chat Surface Boundary
 
@@ -77,7 +79,8 @@ On the Scene 8 request beat, render:
 - a composer with the request text prefilled:
   `We need to author a report workflow for the lda_report scenario. What sources and capabilities are available?`;
 - an enabled Send button;
-- no workflow operation, run ID, deployment ID, or live target action.
+- no workflow operation, run ID, deployment ID, or live target action inside
+  the chat surface. The separate demo footer rail may show target and run state.
 
 The prefilled text is editable. The scene does not require the presenter to
 retype the request during the defense.
@@ -110,8 +113,9 @@ The Scene 8 entry state is local presentation state. Reloading the request beat
 returns to the empty composer. The canonical authoring recording remains the
 source for all revealed turns.
 
-Scene 8 must work with no workflow server and must not change the live/replay
-target badge. The target badge remains scoped by the later demo truth slice.
+Scene 8 chat must work with no workflow server and must not change live/replay
+state. The later demo truth slice owns the separate footer badge and launch
+control across the demo arc.
 
 ### Responsive Behavior