docs: define opening and rehearsal presentation slices

docs/current_roadmap.md

@@ -187,8 +187,11 @@ Presentation visual audit, July 11:
 
 - Baseline-good: Scenes 3, 4, and 5 are good enough for now. Do not churn them
   unless a later rehearsal exposes a concrete problem.
-- Completed: Scenes 1, 2, 6, and 7 now have concrete focal artifacts, and
+- Partially complete: Scenes 2, 6, and 7 have concrete focal artifacts, and
-  Scenes 8-10 share a prepared authoring/run spine.
+  Scenes 8-10 share a prepared authoring/run spine. Scene 1 still needs a
+  title-composition repair so it introduces the agent-shaped product goal
+  before Scene 2 explains the automation problem. Design:
+  [`presentation opening title`](superpowers/specs/2026-07-11-presentation-opening-title-design.md).
 - Completed: Scenes 11-12 now use decision-led approval, continuation-led
   resume/output, and compact factual trace rows so approval, resume, output,
   and trace remain factual without competing panels or repeated low-signal
@@ -240,6 +243,15 @@ Recommended next visual slices:
     authentic external-agent handoff and factual prepared-authoring proof.
     Implementation:
     [`presentation agent authoring story plan`](historical/superpowers/plans/2026-07-11-presentation-agent-authoring-story.md).
+7. Next: rebuild Scene 1 as an agent-shaped title composition: `Planner ->
+   Tool surface -> Runner / platform`, with the last role labelled
+   `Implemented contribution`. Keep Scene 2 responsible for the automation
+   problem. Design:
+   [`presentation opening title`](superpowers/specs/2026-07-11-presentation-opening-title-design.md).
+8. Next: harden the live/replay defense rehearsal path, including submitted and
+   revision-requested same-run resumes, replay fallback, exact deep links, and
+   reset instructions. Design:
+   [`defense presentation rehearsal`](superpowers/specs/2026-07-11-defense-presentation-rehearsal-design.md).
 
 Presentation wishlist / defense readiness:
 

docs/superpowers/specs/2026-07-11-defense-presentation-rehearsal-design.md

@@ -0,0 +1,76 @@
+# Defense Presentation Rehearsal Design
+
+## Status
+
+Proposed implementation slice for the operational path of the React defense
+presentation.
+
+## Purpose
+
+The presentation must be rehearsable as a deterministic defense artifact. The
+presenter needs one documented live path, one documented replay path, and clear
+expected evidence for both submitted and revision-requested decisions.
+
+## Scope
+
+This slice hardens documentation and repeatable verification. It does not add a
+real LLM, a remote presenter companion, a new workflow server transport, or new
+presentation story content.
+
+## Live Path
+
+With `wf-rpc-server` running against `examples/lda_report_workflow/wf.config.json`
+and the presentation target set to `http://127.0.0.1:8765/rpc`, the rehearsal
+path is:
+
+1. Open Scene 8 at `#scene/agent-handoff/request`.
+2. Use the visible `Run prepared workflow` action.
+3. Advance through the prepared lifecycle and run scenes to the typed approval.
+4. Choose all issue rows or a deliberate subset, add a comment, and submit.
+5. Confirm the same run continues into output and trace proof.
+
+The expected submitted branch has a completed run, generated report output,
+created issues for the chosen rows, and trace frames for the completed path.
+
+## Revision-Requested Path
+
+`Request revision` is a valid resume decision, not a terminal cancellation. It
+must call `workflow.runs.resume` on the same run with `approved: false`, then
+continue to its negative output and trace branch. Its expected evidence is:
+
+- protocol outcome `cancelled`;
+- presentation wording `Revision requested`;
+- no created issues;
+- output headed `Revision Requested`;
+- trace records that include `revision_requested` and `end_cancelled`.
+
+## Replay And Failure Path
+
+The committed replay remains the fallback when the health probe or live RPC
+operation fails. The runbook must state how to choose replay before a defense,
+how to recognize the replay truth badge, and that no time should be spent
+debugging a port during the defense.
+
+## Verification Contract
+
+Automated route-level coverage must exercise:
+
+- live target readiness and visible start affordance;
+- a submitted approval that advances to same-run output/trace;
+- a revision-requested approval that also advances to same-run negative
+  output/trace;
+- replay fallback when the target fails health checking.
+
+The runbook must add an operator checklist that names the exact startup
+commands, deep links, expected screen states, reset procedure, and fallback
+statement.
+
+## Acceptance Criteria
+
+1. A new operator can rehearse both decision branches without reconstructing
+   the intended state from source code.
+2. Documentation distinguishes the product-visible revision request from the
+   protocol-level `cancelled` outcome.
+3. Browser-level or route-level tests guard both branches and replay fallback.
+4. The live path remains optional; a failed target cannot block a replay-based
+   defense.

docs/superpowers/specs/2026-07-11-presentation-opening-title-design.md

@@ -0,0 +1,77 @@
+# Presentation Opening Title Design
+
+## Status
+
+Proposed implementation slice. This document replaces the earlier Scene 1
+assumption that its opening visual pass is complete.
+
+## Purpose
+
+Scene 1 must introduce the thesis as an agent-shaped product goal without
+trying to explain the automation problem before Scene 2. It should tell the
+audience what the title means and precisely identify the implemented part.
+
+## Narrative Boundary
+
+- Scene 1 answers: What is the product goal, and which part is implemented?
+- Scene 2 answers: Why are direct agent actions not reusable automation?
+- Scene 1 must not use a generic label such as `Thesis` or `Decomposed` as its
+  dominant display copy.
+- Scene 1 must not lead with the workflow substrate's detailed benefits. Those
+  belong to Scene 2 and later lifecycle/architecture scenes.
+
+## Composition
+
+The scene retains the compact formal title `Design and Implementation of
+lda.chat` in the stage caption. Its main focal copy is:
+
+> An AI Agent for Workspace Workflows
+
+Under it, one connected horizontal system shows three roles in sequence:
+
+```text
+Planner  ->  Tool surface  ->  Runner / platform
+```
+
+The roles are structural parts of one agent-shaped product, not independent
+feature cards. Their labels and supporting examples are:
+
+| Role | Supporting label |
+|---|---|
+| Planner | Codex, Claude, OpenCode |
+| Tool surface | CLI, MCP, JSON-RPC |
+| Runner / platform | workflow lifecycle and deterministic execution |
+
+The first beat keeps the three roles equally legible. The second beat enlarges
+and visually selects `Runner / platform`, retains the other two roles as
+connected context, and adds the exact label `Implemented contribution`.
+
+The selected role may expose a short, factual scope line: `Lifecycle,
+validation, records, traces, and interrupt/resume`. It must remain supporting
+copy, not a second oversized headline.
+
+## Visual Direction
+
+- Use the existing editorial canvas, presentation type, and one cyan active
+  accent. Do not introduce a new theme or blue decorative treatment.
+- Use the existing concept icon vocabulary only when it reinforces each role;
+  the connection line and role hierarchy are the primary visual structure.
+- Avoid three same-weight card panels. The system must visibly read left to
+  right, with a meaningful destination at `Runner / platform`.
+- At 1280x720, the main title and all three role names must be readable without
+  competing with the stage caption, discussion rail, or footer.
+- Motion is limited to a short role-focus transition between beats. Reduced
+  motion uses the final static state.
+
+## Acceptance Criteria
+
+1. The first beat's largest text is `An AI Agent for Workspace Workflows`.
+2. Neither `Thesis` nor `Decomposed` is rendered as a display heading.
+3. The role sequence renders as connected agent context, not three detached
+   cards.
+4. The second beat labels only `Runner / platform` as `Implemented
+   contribution` and keeps planner/tool surface visible as context.
+5. Scene 2 remains responsible for the direct-actions-versus-reusable-
+   automation argument.
+6. Unit tests cover both beats' focus and display copy; browser screenshots at
+   1280x720 cover both beats without clipping.