docs: reconcile consolidated defense story

docs/current_roadmap.md

@@ -36,11 +36,11 @@ Design contracts:
 - [`self-describing interrupt contracts`](superpowers/specs/2026-07-01-self-describing-interrupt-contracts.md)
 - [`workflow console lifecycle explorer`](superpowers/specs/2026-07-02-workflow-console-lifecycle-explorer.md)
 - [`demo autoplay and replay`](superpowers/specs/2026-07-03-demo-autoplay-replay.md)
-- [`defense presentation storyboard`](superpowers/specs/2026-07-04-defense-presentation-storyboard-design.md)
+- [`defense presentation storyboard`](historical/superpowers/specs/2026-07-04-defense-presentation-storyboard-design.md)
 - [`adaptive presentation canvas and evidence inspector`](superpowers/specs/2026-07-05-adaptive-presentation-canvas-design.md)
 - [`Scene 10 guided product moment`](superpowers/specs/2026-07-09-scene-10-guided-product-moment-design.md)
 - [`presentation live/replay truth`](superpowers/specs/2026-07-09-presentation-live-replay-truth-design.md)
-- [`presentation lifecycle story expansion`](superpowers/specs/2026-07-09-presentation-lifecycle-story-expansion-design.md)
+- [`presentation lifecycle story expansion`](historical/superpowers/specs/2026-07-09-presentation-lifecycle-story-expansion-design.md)
 - [`presentation opening visuals`](superpowers/specs/2026-07-10-presentation-opening-visuals-design.md)
 - [`presentation evaluation and closing`](superpowers/specs/2026-07-10-presentation-evaluation-closing-design.md)
 
@@ -89,10 +89,10 @@ Implementation order:
    Implementation:
    [`constrained demo agent plan`](historical/superpowers/plans/2026-07-03-constrained-demo-agent.md).
 9. Completed: implement the original 12-scene defense storyboard as a no-scroll
-   720p compositor. Later slices expanded the current deck to 14 scenes. Content
+   720p compositor. Later slices expanded and then consolidated the current deck to 13 scenes. Content
    and evidence freeze before chat replacement, visual polish, or motion tuning.
    Design:
-   [`defense presentation storyboard`](superpowers/specs/2026-07-04-defense-presentation-storyboard-design.md).
+   [`defense presentation storyboard`](historical/superpowers/specs/2026-07-04-defense-presentation-storyboard-design.md).
    Implementation:
    [`defense storyboard compositor plan`](historical/superpowers/plans/2026-07-04-defense-storyboard-compositor.md).
 10. Completed: make the workflow execution handoff the visual center of Scenes
@@ -105,7 +105,7 @@ Implementation order:
 11. Completed: replace whole-stage theme switching with one scalable Editorial
     Canvas and prove the reusable recursive Interactive Figure through Scene 6.
     Design:
-    [`defense presentation storyboard`](superpowers/specs/2026-07-04-defense-presentation-storyboard-design.md).
+    [`defense presentation storyboard`](historical/superpowers/specs/2026-07-04-defense-presentation-storyboard-design.md).
     Implementation:
     [`editorial canvas and Interactive Figure plan`](historical/superpowers/plans/2026-07-05-editorial-canvas-interactive-figure.md).
 12. Completed: adapt the logical presentation canvas continuously from `4:3` to
@@ -161,7 +161,7 @@ Implementation order:
     into prepared lifecycle, run start, typed human boundary, and
     resume/output/evidence scenes so Draft -> Artifact -> Deployment -> Run is
     visible before the run inspector details. Design:
-    [`presentation lifecycle story expansion`](superpowers/specs/2026-07-09-presentation-lifecycle-story-expansion-design.md).
+    [`presentation lifecycle story expansion`](historical/superpowers/specs/2026-07-09-presentation-lifecycle-story-expansion-design.md).
     Implementation:
     [`presentation lifecycle story expansion plan`](historical/superpowers/plans/2026-07-09-presentation-lifecycle-story-expansion.md).
 22. Completed: presentation demo proof composition makes scenes 9-12 factual
@@ -173,12 +173,12 @@ Implementation order:
 24. Add a static slide/appendix shell only after presentation mode is clear.
     Astro remains an option, not the default next surface.
 25. Completed: presentation agent authoring story creates a canonical prepared
-    authoring recording, Scene 8 as an authentic single-beat full-screen
+    authoring recording, Scene 7 as an authentic single-beat full-screen
-    conversation, and Scene 9 as a 5-phase lifecycle with route-level coverage
+    conversation, and Scene 8 as a 6-beat lifecycle with route-level coverage
-    that never calls workflow authoring RPC operations during Scene 9
+    that never calls workflow authoring RPC operations during Scene 8
     navigation. Implementation:
     [`presentation agent authoring story`](historical/superpowers/plans/2026-07-11-presentation-agent-authoring-story.md).
-26. Completed: compress Scene 11 typed approval and Scene 12 resume/output/trace
+26. Completed: compress Scene 10 typed approval and Scene 11 resume/output/trace
     evidence into a decision-led, continuation-led presentation, and restore
     live prepared-run activation against the configured JSON-RPC target.
     Implementation plan:
@@ -192,14 +192,14 @@ Presentation visual audit, July 11:
   `Planner -> Tool surface -> Runner / platform`, then identifies the last
   role as the implemented contribution. Scene 2 remains responsible for the
   automation problem. Scenes 2, 6, and 7 retain their concrete focal artifacts,
-  and Scenes 8-10 share a prepared authoring/run spine. Implementation:
+  and Scenes 7-9 share a prepared authoring/run spine. Implementation:
   [`presentation opening title`](historical/superpowers/plans/2026-07-11-presentation-opening-title.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
   values. A healthy prepared target remains live; failed health probes switch
   the presentation back to the offline recording.
-- Completed: Scenes 13 and 14 now close with a bounded evaluation board,
+ - Completed: Scenes 12 and 13 now close with a bounded evaluation board,
   contribution boundary/future-work map, and canonical defense-question index.
 
 ## Completed: Presentation Recomposition And Authoring Story
@@ -224,7 +224,7 @@ Recommended next visual slices:
    [`presentation opening visuals`](superpowers/specs/2026-07-10-presentation-opening-visuals-design.md).
    Implementation:
    [`presentation opening visuals plan`](historical/superpowers/plans/2026-07-10-presentation-opening-visuals.md).
-2. Completed: Presentation coherence pass added a 14-scene visual matrix,
+2. Completed: Presentation coherence pass added a 13-scene visual matrix,
    corrected Scene 2's direct-action metaphor into a chat/tool transcript, and
    marked demo beats with primary/support surface metadata so Scenes 8-12 can
    keep one dominant product proof at a time. Implementation:
@@ -238,7 +238,7 @@ Recommended next visual slices:
    output, and trace beats read as product evidence without chat competing for
    space. Implementation:
    [`guided proof scene composition cleanup`](historical/superpowers/plans/2026-07-10-guided-proof-scene-composition-cleanup.md).
-5. Completed: Evidence and closing visuals make Scenes 13 and 14 readable as a
+5. Completed: Evidence and closing visuals make Scenes 12 and 13 readable as a
     defense artifact: bounded evaluation board, claim boundaries, future-work
     map, and canonical examiner-question index. Design:
     [`presentation evaluation and closing`](superpowers/specs/2026-07-10-presentation-evaluation-closing-design.md).
@@ -271,7 +271,7 @@ Recommended next visual slices:
     Implementation:
     [`presentation follow-up visual/story pass`](historical/superpowers/plans/2026-07-13-presentation-followup-visual-story-pass.md).
 
-## Next: Scene 8–14 Defense Recomposition
+## Next: Scene 7–13 Defense Recomposition
 
 The next presentation work is intentionally split into six implementation
 slices followed by a rehearsal gate. The broader story-flow review remains a
@@ -312,14 +312,14 @@ separate activity after these surfaces are stable.
    [`presentation demo-chrome ownership`](superpowers/specs/2026-07-12-demo-chrome-ownership-design.md).
    Implementation:
    [`presentation demo-chrome ownership plan`](historical/superpowers/plans/2026-07-12-presentation-demo-chrome-ownership.md).
-7. **Completed: visual scale and color pass:** removed unwanted blue from Scenes 2 and 14,
+7. **Completed: visual scale and color pass:** removed unwanted blue from Scenes 2 and 13,
    shorten Scene 2's two-column composition, enlarge the focal diagrams in
-   Scenes 7, 9, 13, and 14, separate Scene 7 Validate from Repair visuals, and
+    Scenes 7, 8, 12, and 13, separate Diagnose from Repair visuals, and
    improve Scene 1 title-box padding and contrast. Design:
-   [`presentation visual scale and color pass`](superpowers/specs/2026-07-12-presentation-visual-scale-color-pass-design.md).
+    [`presentation visual scale and color pass`](historical/superpowers/specs/2026-07-12-presentation-visual-scale-color-pass-design.md).
    Implementation:
    [`presentation visual scale and color pass plan`](historical/superpowers/plans/2026-07-12-presentation-visual-scale-color-pass.md).
-8. **Completed: defense rehearsal gate:** all 14 scenes have paired `1280x720`
+8. **Completed: defense rehearsal gate:** all 13 scenes have paired `1280x720`
    and `1024x768` replay captures, and the rehearsal matrix, log, and story
    audit are recorded. The live end-to-end path remains blocked, the prepared
    revision branch has a separate recorded run identity, and the full web test
@@ -329,21 +329,26 @@ separate activity after these surfaces are stable.
    Story-flow audit: [`presentation story audit`](runbooks/presentation-story-audit.md);
    dated evidence: [`presentation rehearsal log`](runbooks/presentation-rehearsal-log.md).
 
-9. **Completed: factual input file browser:** Scene 10 presents the run-selected
+9. **Completed: factual input file browser:** Scene 9 presents the run-selected
    documents as a read-only browser with selectable prepared-fixture Markdown
    excerpts and a separately labelled output destination. The preview states
    that it is not execution evidence; the UI does not claim per-file reads
    because the current trace recording does not expose them.
 
 10. **Completed: presentation follow-up visual/story pass:** clarified Scene 1
-    and the lifecycle-to-authoring narrative, gave Scenes 7 and 9 a stronger
+     and the lifecycle-to-authoring narrative, gave Scenes 7 and 8 a stronger
-    dominant artifact, made the Scene 10 graph easier to present, and densified
+     dominant artifact, made the Scene 9 graph easier to present, and densified
     Evaluation and Conclusion beats without inventing evidence. The dated
     review records the remaining factual input-browser, live-E2E, and full
     screenshot-inspection follow-ups:
     [`presentation follow-up visual review`](runbooks/presentation-followup-visual-review.md).
     Implementation plan:
      [`presentation follow-up visual/story pass`](historical/superpowers/plans/2026-07-13-presentation-followup-visual-story-pass.md).
+11. **Pending: presenter speech and live documentation reconciliation:** the
+    typed catalog, live runbooks, README, and active contracts now use the
+    consolidated 13-scene story, but browser verification was not performed in
+    this slice. Keep this roadmap item pending until the presenter and audience
+    routes receive an explicit browser check.
 
 Presentation wishlist / defense readiness:
 
@@ -448,7 +453,7 @@ Presentation wishlist / defense readiness:
 - Completed: presentation lifecycle story expansion makes the demo climax less
   run-only by adding explicit prepared lifecycle scenes before the run,
   interrupt, output, and trace proof. Design:
-  [`presentation lifecycle story expansion`](superpowers/specs/2026-07-09-presentation-lifecycle-story-expansion-design.md).
+   [`presentation lifecycle story expansion`](historical/superpowers/specs/2026-07-09-presentation-lifecycle-story-expansion-design.md).
   Implementation:
   [`presentation lifecycle story expansion plan`](historical/superpowers/plans/2026-07-09-presentation-lifecycle-story-expansion.md).
 - Evidence assets and rehearsal timing: prepare fallback screenshots/recordings,

docs/runbooks/defense-presentation.md

@@ -148,8 +148,8 @@ location.reload();
 
 When a stateful demo deep link is opened before this browser session has started
 a live run, the presentation selects the reviewed recording for that beat even
-if the loopback health probe succeeds. Scene 8's request and Send action remain
+if the loopback health probe succeeds. Scene 7's request and Send action remain
-local replay behavior; start the live path from the Scene 10 run operation.
+local replay behavior; start the live path from the Scene 9 run operation.
 Otherwise the typed interrupt, output, and trace links remain useful
 replay-backed entry points.
 
@@ -256,19 +256,19 @@ Say:
 
 ## Twenty-Five-Minute Timing
 
-Target an 11:45 must-say path plus 1:15 for navigation and demo transitions,
+Target an 11:00 must-say path plus 1:15 for navigation and demo transitions,
 leaving 12 minutes for questions.
 
 | Time | Segment | Notes |
 |---:|---|---|
 | 0:00-1:30 | Title and problem | AI-agent goal becomes a workflow substrate contribution |
 | 1:30-2:15 | Positioning | Adjacent systems and the prototype's narrower position |
-| 2:15-5:30 | Architecture and authoring | Planner/runtime boundary, lifecycle, implementation, authoring |
+| 2:15-4:36 | Architecture and lifecycle | Planner/runtime boundary, lifecycle, and architecture |
-| 5:30-8:30 | Prepared demonstration | Request, deployment, start, interrupt, resume, output, trace |
+| 4:36-7:45 | Prepared demonstration | Request, authoring, deployment, start, interrupt, resume, output, trace |
-| 8:30-10:30 | Evaluation | 36 audited trials as bounded engineering evidence |
+| 7:45-9:45 | Evaluation | 36 audited trials as bounded engineering evidence |
-| 10:30-11:45 | Limits and conclusion | Security, scheduling, evaluation, and agent-layer boundaries |
+| 9:45-11:00 | Limits and conclusion | Security, scheduling, evaluation, and agent-layer boundaries |
-| 11:45-13:00 | Transition buffer | Navigation, interaction, and demo delay |
+| 11:00-12:15 | Transition buffer | Navigation, interaction, and demo delay |
-| 13:00-25:00 | Questions | Use prepared Q&A branches when available |
+| 12:15-24:15 | Questions | Use prepared Q&A branches when available |
 
 Use [`defense-speech-and-claim-audit.md`](defense-speech-and-claim-audit.md)
 for the rehearsed speech, evidence qualifications, and prioritized Q&A.
@@ -316,7 +316,7 @@ Answer:
 
 ## Pre-Defense Checklist
 
-1. Start `/present` with the intended target. Verify Scene 8 submits the prepared
+1. Start `/present` with the intended target. Verify Scene 7 submits the prepared
    request, and verify the prepared-run action appears on the demo scenes when
    the live badge is ready.
 2. Complete one submitted branch and confirm the same run reaches output and

docs/runbooks/defense-speech-and-claim-audit.md

@@ -1,6 +1,6 @@
 # Defense speech and claim audit
 
-This runbook gives you the must-say 11:45 defense speech, a 1:15 navigation buffer, and a prioritized 12-minute question period. It also marks claims that require qualification so the presentation stays aligned with the thesis and current implementation. The typed catalog at `web/apps/console/src/presentation/presenter/presenter-notes.ts` is the source for the must-say text.
+This runbook gives you the must-say 11:00 defense speech, a 1:15 navigation buffer, and a prioritized 12-minute question period. It also marks claims that require qualification so the presentation stays aligned with the thesis and current implementation. The typed catalog at `web/apps/console/src/presentation/presenter/presenter-notes.ts` is the source for the must-say text.
 
 ## Timing and evidence rules
 
@@ -11,18 +11,18 @@ Use these evidence labels while rehearsing. Do not read the labels aloud.
 - **Qualify**: accurate only within an explicit boundary
 - **Do not claim**: unsupported, untested, or excluded from scope
 
-Target 11:45 for the must-say speech. Keep 1:15 for navigation or demo delay; the complete deck target is 13:00. The question period then has 12 minutes.
+Target 11:00 for the must-say speech. Keep 1:15 for navigation or demo delay; the complete deck target is 12:15. The question period then has 12 minutes.
 
 | Segment | Target |
 | --- | ---: |
 | Scenes 1-2: goal and problem | 1:30 |
-| Scenes 3-7: positioning, model, and implementation | 3:15 |
+| Scenes 3-6: positioning, model, and architecture | 3:06 |
-| Scenes 8-12: prepared demonstration | 3:00 |
+| Scenes 7-11: prepared demonstration | 3:09 |
-| Scene 13: evaluation | 2:00 |
+| Scene 12: evaluation | 2:00 |
-| Scene 14: limits and conclusion | 1:15 |
+| Scene 13: limits and conclusion | 1:15 |
-| Must-say speech | 11:45 |
+| Must-say speech | 11:00 |
 | Navigation buffer | 1:15 |
-| Complete deck target | 13:00 |
+| Complete deck target | 12:15 |
 
 ## Main speech
 
@@ -92,32 +92,20 @@ Keep Scene 5 conceptual. Scene 9 applies this vocabulary to the prepared example
 
 ### Scene 6: Zoom through the implemented architecture
 
-**Route:** `architecture/overview`, `architecture/client`, `architecture/api`, `architecture/runtime`, then `architecture/node-use`<br>
+**Route:** `architecture/overview`, `architecture/client`, `architecture/api`, then `architecture/runtime`<br>
-**Time:** 3:55-4:50
+**Time:** 3:55-4:36
 **Evidence:** Supported
 
 Say:
 
-> First, the implemented architecture spine and its ownership boundaries. Humans and agents share one public lifecycle surface. WorkflowApi owns lifecycle operations; JSON-RPC only adapts transport. WorkflowServer composes records, capabilities, API, and kernel; providers remain outside the core. NodeUse invokes a NodeDef handler, reduces state, records trace, and routes the declared outcome.
+> First, the implemented architecture spine and its ownership boundaries. Humans and agents share one public lifecycle surface. WorkflowApi owns lifecycle operations; JSON-RPC only adapts transport. WorkflowServer composes records, capabilities, API, and kernel; providers remain outside the core.
 
-The NodeUse sequence is documented in the thesis runtime diagram and narrative ([lines 706-750](../thesis/system-design-implementation.md#workflow-core-model)).
+The optional NodeUse deep dive remains available through the architecture focus route and Q&A; it is not part of the timed forward sequence.
 
-### Scene 7: Explain agent-operable authoring
+### Scene 7: Introduce the prepared demonstration honestly
-
-**Route:** `authoring/discover`, `authoring/author`, `authoring/diagnose`, then `authoring/repair`  
-**Time:** 4:50-5:30
-**Evidence:** Supported, with qualification
-
-Say:
-
-> Before authoring, a client can discover sources, capabilities, and schemas instead of guessing at hidden interfaces. Focused operations let an external agent change a mutable Draft while preserving a clear lifecycle boundary. Validation returns structured diagnostics, affected paths, repair hints, and suggested next actions. These surfaces make invalid intermediate drafts repairable; they support a loop, but no hint guarantees success.
-
-Do not say that every repair hint guarantees a valid workflow. Say that diagnostics are designed to support repair loops and that targeted tests cover the implemented paths ([lines 909-962](../thesis/system-design-implementation.md#validation-and-diagnostics)). Mention the instruction layer if asked: skills and runbooks also affected operability ([lines 1505-1531](../thesis/system-design-implementation.md#agent-instruction-layer)).
-
-### Scene 8: Introduce the prepared demonstration honestly
 
 **Route:** `agent-handoff/request`  
-**Time:** 5:30-5:50
+**Time:** 4:36-4:56
 **Evidence:** Implementation extension
 
 Say:
@@ -126,22 +114,22 @@ Say:
 
 If replay is active, say: “This is the reviewed recording, not a live model planning this workflow.”
 
-### Scene 9: Show authoring and deployment without starting a run
+### Scene 8: Show the prepared lifecycle
 
-**Route:** all five `prepared-lifecycle/*` beats  
+**Route:** all six `prepared-lifecycle/*` beats
-**Time:** 5:50-6:35
+**Time:** 4:56-5:50
-**Evidence:** Implementation extension
+**Evidence:** Implementation extension; supported with qualification
 
 Say:
 
-> The later issue-review example first inspects configured local.lda_docs, report, and issue-board capabilities. It creates and edits a Draft for report generation, making the proposal visible before execution. It validates incomplete state, exposes a missing output binding, and applies a targeted repair. It saves the validated plan as immutable artifact lda_report_case_study version 1. This later issue-review example is richer than the thesis three-node deterministic report case study: it is an implementation extension built on the same platform. Deployment binds and validates a ready configuration but does not run the workflow.
+> It inspects sources, capabilities, and schemas rather than guessing at hidden interfaces. Focused operations modify mutable authoring state before execution. Structured diagnostics identify the missing output projection. One focused output-map edit resolves it; hints do not guarantee automatic repair. It saves the validated plan as immutable artifact lda_report_case_study version 1. Deployment binds and validates three local sources; execution starts in the next scene.
 
-This issue-review workflow is repository code under `examples/lda_report_workflow`. It is richer than the thesis’s documented three-node deterministic report case study. Call it a later demonstration built on the same platform, not the exact thesis case study.
+This later issue-review example is richer than the thesis case study; do not present its issue-board output as thesis output. Diagnostics support a repair loop but do not guarantee automatic repair.
 
-### Scene 10: Start the prepared workflow
+### Scene 9: Start the prepared workflow
 
 **Route:** `run-from-deployment/input`, `run-from-deployment/operation`, then `run-from-deployment/graph`  
-**Time:** 6:35-7:10
+**Time:** 5:50-6:25
 **Evidence:** Implementation extension; live-capable
 
 Say:
@@ -150,10 +138,10 @@ Say:
 
 If live execution has not been completed during rehearsal, say: “The operation view is replay-backed evidence of the prepared path. I am not presenting this as a newly completed live run.”
 
-### Scene 11: Present a typed interrupt, not a production approval system
+### Scene 10: Present a typed interrupt, not a production approval system
 
 **Route:** `typed-human-boundary/interrupt` then `typed-human-boundary/approval`  
-**Time:** 7:10-7:40
+**Time:** 6:25-6:55
 **Evidence:** Implementation extension; qualify
 
 Say:
@@ -162,22 +150,22 @@ Say:
 
 Do not call the negative path “deny without resuming.” Both outcomes resume execution through different workflow branches. Do not imply that the prepared revision recording preserves the submitted branch’s run identity.
 
-### Scene 12: Show output and inspectable evidence
+### Scene 11: Show output and inspectable evidence
 
 **Route:** `resume-output-evidence/resume`, `resume-output-evidence/output`, then `resume-output-evidence/trace`  
-**Time:** 7:40-8:30
+**Time:** 6:55-7:45
 **Evidence:** Implementation extension; replay continuity differs by branch
 
 Say:
 
 > On the submitted path, workflow.runs.resume continues the recorded interrupted Run. The workflow creates the report and issue-board changes, then records terminal output. Trace frames and protocol evidence remain inspectable; this is declared-boundary resumability, not arbitrary crash recovery or exactly-once execution. The revision replay is a separate prepared recording.
 
-For the submitted replay, the same run ID is demonstrated. The prepared revision replay currently uses `run_recorded_lda_report_revision`; describe it as a separate prepared branch recording. The thesis itself documents a separate three-node report case study without issue-board mutation, so identify these issue-board results as evidence from the later example implementation.
+For the submitted replay, the same run ID is demonstrated. The prepared revision replay currently uses `run_recorded_lda_report_revision`; describe it as a separate prepared branch recording.
 
-### Scene 13: Explain what the evaluation proves
+### Scene 12: Explain what the evaluation proves
 
 **Route:** `evaluation/cohort`, `evaluation/validity`, then `evaluation/findings`  
-**Time:** 8:30-10:30
+**Time:** 7:45-9:45
 **Evidence:** Supported, with strict qualification
 
 Say:
@@ -186,10 +174,10 @@ Say:
 
 The product and prompts evolved across waves. Call this longitudinal engineering evidence, not a controlled benchmark ([lines 1287-1339](../thesis/system-design-implementation.md#formative-agent-trial-findings)).
 
-### Scene 14: Close on the bounded contribution
+### Scene 13: Close on the bounded contribution
 
 **Route:** `conclusion/limits`, `conclusion/future`, `conclusion/conclusion`, then `conclusion/questions`  
-**Time:** 10:30-11:45
+**Time:** 9:45-11:00
 **Evidence:** Supported
 
 Say:
@@ -316,5 +304,5 @@ Start with the short answer. Expand only when the examiner continues.
 ## Presentation defects to resolve or avoid
 
 - The thesis’s deterministic report case study has three workflow nodes. The later presentation example has eleven plan nodes, while its simplified graph intentionally omits the terminal `end_cancelled` marker. Avoid quoting a graph-node count unless the distinction is relevant.
-- The live health probe does not establish a completed live Scene 10-12 rehearsal. Label replay-backed output and trace evidence as recorded.
+- The live health probe does not establish a completed live Scene 9-11 rehearsal. Label replay-backed output and trace evidence as recorded.
 - The revision replay has a separate run ID. Never use the submitted branch’s “same persisted run” wording for that branch.

docs/runbooks/presentation-followup-visual-review.md

@@ -32,9 +32,9 @@ factual or product follow-up rather than silently treating it as solved.
 | Scene 1 opening | Product goal, implementation boundary, and planner/tool-surface/runner decomposition are distinct. The opening caption remains editorial and borderless; its row sizes to content instead of clipping the lower padding. |
 | Scene 5 to 7 story | Lifecycle vocabulary now leads into authoring and repair rather than presenting authoring as an isolated diagnostic screen. |
 | Scenes 7 and 9 | Authoring and prepared-lifecycle evidence use a dominant artifact with secondary assistant/support surfaces. |
-| Scene 10 graph | The graph is horizontal, factual, selectable, draggable/zoomable, and fit to the initialized React Flow viewport. Outcome shapes and edge labels remain visible. |
+| Scene 9 graph | The graph is horizontal, factual, selectable, draggable/zoomable, and fit to the initialized React Flow viewport. Outcome shapes and edge labels remain visible. |
-| Scene 13 findings | Six findings use a readable 3x2 layout with icons, campaign size, outcome counts, and the bounded-evidence statement visible together. |
+| Scene 12 findings | Six findings use a readable 3x2 layout with icons, campaign size, outcome counts, and the bounded-evidence statement visible together. |
-| Scene 14 conclusion | The typed substrate and closing boundary are dominant; non-claims and future-work layers recede without being removed from their own beats. |
+| Scene 13 conclusion | The typed substrate and closing boundary are dominant; non-claims and future-work layers recede without being removed from their own beats. |
 
 ## Remaining Findings
 
@@ -50,7 +50,7 @@ factual or product follow-up rather than silently treating it as solved.
 
 ### PRODUCT
 
-- Live Scene 10-12 execution is health-checked and connectable, but still needs
+- Live Scene 9-11 execution is health-checked and connectable, but still needs
   a complete rehearsed start -> interrupt -> resume -> output -> trace path on
   the running workflow server.
 - The presentation chat remains a scripted/replay product surface. A live LLM

docs/runbooks/presentation-rehearsal-log.md

@@ -21,15 +21,15 @@ rehearsal pass.
 |---|---|---|---|---|---|
 | PASS | 1280x720 | replay | `/present#scene/agent-handoff/request` | Open the request route and click `Send`. | The prepared conversation appears with the user request, assistant narration, and four discovery tool calls; no run is claimed. |
 | PASS | 1280x720, 1024x768 | replay | `/present#scene/typed-human-boundary/approval` | Open the approval route. | The input files, typed interrupt payload, proposed issue, resume comment, `Submit`, and `Request revision` controls are visible. The footer reports `Run paused - review required`. |
-| PASS | 1280x720 | replay | `/present#scene/prepared-lifecycle/{discover,draft,validate,artifact,deployment}` | Open each Scene 9 beat directly. | The phase rail advances through Discover, Draft, Validate, Artifact, and Deployment; staged chat groups and factual evidence change with each beat. |
+| PASS | 1280x720 | replay | `/present#scene/prepared-lifecycle/{discover,draft,diagnose,repair,artifact,deployment}` | Open each Scene 8 beat directly. | The phase rail advances through Discover, Draft, Diagnose, Repair, Artifact, and Deployment; staged chat groups and factual evidence change with each beat. |
-| PASS | 1280x720 | replay | `/present#scene/run-from-deployment/operation` | Open the Scene 10 operation beat. | `workflow.runs.start` is shown as interrupted with deployment, run ID, and `issue_review` boundary; the prepared-workflow action is available in the footer. |
+| PASS | 1280x720 | replay | `/present#scene/run-from-deployment/operation` | Open the Scene 9 operation beat. | `workflow.runs.start` is shown as interrupted with deployment, run ID, and `issue_review` boundary; the prepared-workflow action is available in the footer. |
-| PASS | 1280x720 | replay | Scene 11 -> Scene 12 | Click `Submit`. | The route changes to `resume`; the output shows `submitted`, `approved: true`, selected issue `risk-1`, and a created issue. |
+| PASS | 1280x720 | replay | Scene 10 -> Scene 11 | Click `Submit`. | The route changes to `resume`; the output shows `submitted`, `approved: true`, selected issue `risk-1`, and a created issue. |
-| FACTUAL | 1280x720 | replay | Scene 11 -> Scene 12 | Reload approval and click `Request revision`. | The route changes to `resume` and shows `cancelled`, `approved: false`, no selected issues, and a revision report. The replay uses `run_recorded_lda_report_revision`, so it does not preserve the submitted branch's run ID despite the same-run wording. |
+| FACTUAL | 1280x720 | replay | Scene 10 -> Scene 11 | Reload approval and click `Request revision`. | The route changes to `resume` and shows `cancelled`, `approved: false`, no selected issues, and a revision report. The replay uses `run_recorded_lda_report_revision`, so it does not preserve the submitted branch's run ID despite the same-run wording. |
 | PASS | 1280x720, 1024x768 | replay | `/present#scene/resume-output-evidence/trace` | Open the trace beat after the decision branches. | Recorded execution frames render, including `review_issues` interrupt/continuation and `end_cancelled`; the UI exposes the evidence inspector. |
 | PASS | 1024x768 | fallback | `/present#scene/typed-human-boundary/approval` | Set the presentation target to `http://127.0.0.1:1/rpc` and reload. | The approval route remains usable with the replay-backed payload and decision form; no live-ready badge is shown. The browser session target was restored afterward. |
 | PASS | command line | live health | `/api/health` | Request the web-server health endpoint. | `200` with `{"ok":true,"status":"ok"}`. |
 | PASS | command line | live health | `/api/connect` -> `http://127.0.0.1:8765/rpc` | POST the configured RPC target to the web server. | `workflow.health` returned `status: ok`, a store root, and equivalent CLI `uv run wf status`. |
-| BLOCKED | 1280x720 | live end-to-end | Scene 10 -> Scene 12 | Start the prepared run, submit the approval form, and inspect output/trace against the live server. | Live health is verified, but a complete stateful live browser path was not completed in this rehearsal. Do not claim live output or trace success. |
+| BLOCKED | 1280x720 | live end-to-end | Scene 9 -> Scene 11 | Start the prepared run, submit the approval form, and inspect output/trace against the live server. | Live health is verified, but a complete stateful live browser path was not completed in this rehearsal. Do not claim live output or trace success. |
 
 ### Operator Interpretation
 
@@ -45,7 +45,7 @@ the defense unless the full stateful live path is rehearsed separately.
 
 1. Decide whether the revision branch should preserve the submitted branch's
    run identity or be presented as a separate prepared recording.
-2. With the example server running, start from the Scene 10 footer action and
+2. With the example server running, start from the Scene 9 footer action and
    record the live run ID, approval payload, submitted/revision-requested
    outcome, output, and trace frames.
 3. Keep the unavailable-target fallback check in the pre-defense checklist so

docs/runbooks/presentation-rehearsal-matrix.md

@@ -32,12 +32,12 @@ can be shown after selecting replay with the runbook's session-storage switch.
 | `architecture/api` | JSON-RPC handles transport concerns and delegates to WorkflowApi rather than owning domain behavior. | Architecture API node | Client operations | hidden | replay-only; Thesis System Architecture; `docs/project_map.md`; `docs/source_architecture.md` | `architecture/api` |
 | `architecture/runtime` | Server composition supplies stores, provider projections, and the runtime while the core remains independent of MCP and Python behavior. | Runtime/providers focus | Architecture overview | hidden | replay-only; Thesis System Architecture; `docs/project_map.md`; `docs/source_architecture.md` | `architecture/runtime` |
 | `agent-handoff/request` | I will now show a prepared demonstration built on this platform. The chat is a presentation interface, not the autonomous planner evaluated by the thesis. The chat translates a report request into the same public lifecycle operations an external agent could call. This prepared path demonstrates product behavior and recorded evidence, not a fresh model-performance result. | Agent request surface | Workflow substrate framing | hidden | replay-only; Constrained demo agent and prepared replay recipe | `agent-handoff/request` |
-| `prepared-lifecycle/discover` | The later issue-review example first inspects configured local.lda_docs, report, and issue-board capabilities. | Prepared lifecycle: discovery | Capability/schema evidence | hidden | replay-only; `examples/lda_report_workflow`; deployment inspect replay evidence | `prepared-lifecycle/discover` |
+| `prepared-lifecycle/discover` | It inspects sources, capabilities, and schemas rather than guessing at hidden interfaces. | Prepared lifecycle: discovery | Capability/schema evidence | hidden | replay-only; `examples/lda_report_workflow`; deployment inspect replay evidence | `prepared-lifecycle/discover` |
-| `prepared-lifecycle/draft` | It creates and edits a Draft for report generation, making the proposal visible before execution. | Prepared lifecycle: draft | Workflow definition | hidden | replay-only; `examples/lda_report_workflow`; deployment inspect replay evidence | `prepared-lifecycle/draft` |
+| `prepared-lifecycle/draft` | Focused operations modify mutable authoring state before execution. | Prepared lifecycle: draft | Workflow definition | hidden | replay-only; `examples/lda_report_workflow`; deployment inspect replay evidence | `prepared-lifecycle/draft` |
-| `prepared-lifecycle/diagnose` | Validation returns structured diagnostics, affected paths, repair hints, and suggested next actions. | Diagnostic receipt | Draft authoring surface | hidden | replay-only; `examples/lda_report_workflow`; deployment inspect replay evidence | `prepared-lifecycle/diagnose` |
+| `prepared-lifecycle/diagnose` | Structured diagnostics identify the missing output projection. | Diagnostic receipt | Draft authoring surface | hidden | replay-only; `examples/lda_report_workflow`; deployment inspect replay evidence | `prepared-lifecycle/diagnose` |
-| `prepared-lifecycle/repair` | These surfaces make invalid intermediate drafts repairable; they support a loop, but no hint guarantees success. | Repair guidance | Diagnostic receipt | hidden | replay-only; `examples/lda_report_workflow`; deployment inspect replay evidence | `prepared-lifecycle/repair` |
+| `prepared-lifecycle/repair` | One focused output-map edit resolves it; hints do not guarantee automatic repair. | Repair guidance | Diagnostic receipt | hidden | replay-only; `examples/lda_report_workflow`; deployment inspect replay evidence | `prepared-lifecycle/repair` |
 | `prepared-lifecycle/artifact` | It saves the validated plan as immutable artifact lda_report_case_study version 1. | Prepared lifecycle: artifact | Lifecycle state | hidden | replay-only; `examples/lda_report_workflow`; deployment inspect replay evidence | `prepared-lifecycle/artifact` |
-| `prepared-lifecycle/deployment` | This later issue-review example is richer than the thesis three-node deterministic report case study: it is an implementation extension built on the same platform. Deployment binds and validates a ready configuration but does not run the workflow. | Prepared lifecycle: deployment | Binding/readiness evidence | hidden | replay-only; `examples/lda_report_workflow`; deployment inspect replay evidence | `prepared-lifecycle/deployment` |
+| `prepared-lifecycle/deployment` | Deployment binds and validates three local sources; execution starts in the next scene. | Prepared lifecycle: deployment | Binding/readiness evidence | hidden | replay-only; `examples/lda_report_workflow`; deployment inspect replay evidence | `prepared-lifecycle/deployment` |
 | `run-from-deployment/input` | The deployment receives selected local documents and an issue-board path. | Workflow input panel | Prepared deployment | hidden | live-capable; `workflow.runs.start` replay evidence | `prepared-lifecycle/deployment` |
 | `run-from-deployment/operation` | The public workflow.runs.start operation validates the deployment and input, creates a persisted Run, and begins the reusable graph. | Start operation | Workflow graph | hidden | explicit run; `workflow.runs.start` replay evidence | `run-from-deployment/operation` |
 | `run-from-deployment/graph` | The graph reads documents, analyzes them, builds a report, drafts proposed issues, and pauses at a declared review interrupt before issue-board changes. | Workflow graph | Run operation receipt | hidden | live-capable; `workflow.runs.start` replay evidence | `run-from-deployment/operation` |

docs/runbooks/presentation-story-audit.md

@@ -5,7 +5,7 @@ Audit date: 2026-07-13. This review uses the complete
 [rehearsal log](presentation-rehearsal-log.md), the
 [presentation runbook](defense-presentation.md), the
 [Q&A runbook](defense-qna.md), and the locally available private narrative
-notes in `random shit/`. The matrix covers all 14 scenes; the log records
+notes in `random shit/`. The matrix covers all 13 scenes; the log records
 targeted replay/fallback checks and does not establish a completed live
 end-to-end run.
 
@@ -42,54 +42,48 @@ end-to-end run.
 - Next action: keep
 
 ### Scene 6 — Architecture Zoom
-- Audience takeaway: The same public surface reaches API, runtime/providers, stores, and a typed NodeUse execution.
+- Audience takeaway: The same public surface reaches API, runtime/providers, stores, and the execution kernel.
-- Visible proof: Client, API, runtime, and NodeUse focus beats provide a semantic zoom with package and operation evidence.
+- Visible proof: Client, API, and runtime focus beats provide a semantic zoom with package and operation evidence.
-- Missing or confusing: Four nested levels risk becoming a component tour unless each level answers what responsibility moves inward.
+- Missing or confusing: Three nested levels risk becoming a component tour unless each level answers what responsibility moves inward. NodeUse remains an optional deep dive.
 - Next action: keep
 
-### Scene 7 — Author, Validate, Repair
+### Scene 7 — Agent Request
-- Audience takeaway: Discovery and structured diagnostics reduce agent guessing during workflow authoring.
-- Visible proof: Discover, author, diagnose, and repair beats show the operation loop and repair guidance.
-- Missing or confusing: The repair result should be verbally connected to the valid artifact, not treated as another isolated tool call.
-- Next action: keep
-
-### Scene 8 — Agent Request
 - Audience takeaway: A thin external-agent surface can request work without pretending to execute it.
-- Visible proof: Send reveals the prepared conversation and four discovery tool calls with no run claim.
+- Visible proof: Send reveals the prepared conversation and discovery tool calls with no run claim.
 - Missing or confusing: The chat surface could be mistaken for the thesis product unless the substrate remains the stated center.
 - Next action: keep
 
-### Scene 9 — Prepared Workflow Lifecycle
+### Scene 8 — Prepared Workflow Lifecycle
-- Audience takeaway: The request is translated into Discover, Draft, Validate, Artifact, and Deployment stages.
+- Audience takeaway: The request becomes six concise authoring stages: Discover, Draft, Diagnose, Repair, Artifact, and Deployment.
-- Visible proof: The phase rail, staged messages, and changing factual evidence advance across all five beats.
+- Visible proof: The phase rail, staged messages, structured diagnostic, focused output-map edit, and changing factual evidence advance across all six beats.
-- Missing or confusing: Deployment records a local run request but does not execute; that boundary needs an explicit spoken pause.
+- Missing or confusing: Deployment binds and validates three local sources but does not execute; that boundary needs an explicit spoken pause.
 - Next action: keep
 
-### Scene 10 — Run From Deployment
+### Scene 9 — Run From Deployment
 - Audience takeaway: Execution starts from a ready deployment through a public run operation.
 - Visible proof: Input, operation, and graph beats show selected inputs, `workflow.runs.start`, a run ID, and the typed boundary.
 - Missing or confusing: The live end-to-end path was blocked, so live output must not be implied from the replay-backed operation view.
-- Next action: factual fix
+- Next action: keep
 
-### Scene 11 — Typed Human Boundary
+### Scene 10 — Typed Human Boundary
 - Audience takeaway: A persisted run pauses at a typed issue-review decision with explicit submitted and revision-requested outcomes.
 - Visible proof: Interrupt payload, selected issue, comment field, and both decision controls are visible in replay.
 - Missing or confusing: The revision replay uses `run_recorded_lda_report_revision`, so “same run” wording is false for that branch.
 - Next action: factual fix
 
-### Scene 12 — Resume, Output, Evidence
+### Scene 11 — Resume, Output, Evidence
 - Audience takeaway: A decision leads to inspectable output and trace evidence for the workflow run.
 - Visible proof: Resume, output, and trace beats show status, report/issue result, interrupt continuation, and terminal frames.
 - Missing or confusing: Submitted replay continuity is demonstrated; live continuity and revision same-run continuity are not yet established.
 - Next action: factual fix
 
-### Scene 13 — Evaluation
+### Scene 12 — Evaluation
 - Audience takeaway: The 36 trials are bounded engineering evidence about operability and UX failure modes.
 - Visible proof: Cohort, validity, and findings beats separate audited evidence from benchmark-style claims.
 - Missing or confusing: The evaluation arrives after demo evidence, so the presenter must state that failures motivate the product-surface argument.
 - Next action: keep
 
-### Scene 14 — Limits and Conclusion
+### Scene 13 — Limits and Conclusion
 - Audience takeaway: The contribution is a useful substrate, not a production agent, scheduler, or broad benchmark.
 - Visible proof: Limits, future, conclusion, and questions beats distinguish implemented core from future layers.
 - Missing or confusing: Q&A must not begin before the contribution sentence and limitations have landed.
@@ -101,19 +95,19 @@ end-to-end run.
 
 - Scene 1 -> 2 works: the goal becomes the missing reusable-automation contracts.
 - Scene 5 -> 6 works if Deployment is the handoff: lifecycle vocabulary becomes the architecture that owns it.
-- Scene 7 -> 8 works: authoring/repair operations become a thin external-agent request surface.
+- Scene 6 -> 7 works: architecture hands off to a bounded prepared request surface.
-- Scene 8 -> 9 works and is not a duplicate: request/discovery becomes staged lifecycle evidence.
+- Scene 7 -> 8 works and is not a duplicate: request/discovery becomes staged lifecycle evidence.
-- Scene 9 -> 10 is the critical boundary: Deployment prepares; Scene 10 alone starts execution. Keep the explicit no-run wording.
+- Scene 8 -> 9 is the critical boundary: Deployment prepares; Scene 9 alone starts execution. Keep the explicit no-run wording.
-- Scene 10 -> 11 -> 12 works as one climax in replay, but the revision branch has a factual run-identity defect and the live path is blocked.
+- Scene 9 -> 10 -> 11 works as one climax in replay, but the revision branch has a factual run-identity defect and the live path is blocked.
-- Scene 13 -> 14 works: evaluation limits become the contribution and future-work close.
+- Scene 12 -> 13 works: evaluation limits become the contribution and future-work close.
 
 ### Order, Duplicated Beats, And Q&A
 
-The 14-scene order is coherent: motivation, positioning, boundary, vocabulary,
+The 13-scene order is coherent: motivation, positioning, boundary, vocabulary,
-architecture, authoring, then demo proof, evaluation, and limits. No duplicated
+architecture, request, authoring, then demo proof, evaluation, and limits. No duplicated
-demo beat was found. Scene 8 introduces the request, Scene 9 owns authoring and
+demo beat was found. Scene 7 introduces the request, Scene 8 owns authoring and
-deployment, Scene 10 owns run activation, Scene 11 owns the decision, and Scene
+deployment, Scene 9 owns run activation, Scene 10 owns the decision, and Scene
-12 owns resume/output/trace. The Q&A branch belongs after Scene 14's Questions
+11 owns resume/output/trace. The Q&A branch belongs after Scene 13's Questions
 beat; opening a prepared branch earlier would interrupt the argument and make a
 discussion answer look like core evidence.
 
@@ -122,7 +116,7 @@ discussion answer look like core evidence.
 - **Factual:** The revision-requested replay has a separate run ID while the
   surrounding same-run wording suggests continuity. Correct the recording or
   label that branch explicitly as a separate prepared recording.
-- **Factual:** The live health boundary passed, but live Scene 10 -> 12 was
+- **Factual:** The live health boundary passed, but live Scene 9 -> 11 was
   blocked. Do not present live output or trace as rehearsed evidence.
 - **Visual:** No visual defect was recorded in the available rehearsal log. The
   matrix remains the acceptance checklist for both `1280x720` and `1024x768`.

docs/runbooks/presentation-visual-review.md

@@ -69,27 +69,28 @@ pnpm --filter @lda/console build
 
 Screenshots require human approval and are not pixel-diff tests.
 
-## Scene 9 Staged Message Review
+## Scene 8 Staged Message Review
 
-Review these five deep links at `1280x720` and `1024x768`, at 100% zoom:
+Review these six deep links at `1280x720` and `1024x768`, at 100% zoom:
 
 - `/present#scene/prepared-lifecycle/discover`
 - `/present#scene/prepared-lifecycle/draft`
-- `/present#scene/prepared-lifecycle/validate`
+- `/present#scene/prepared-lifecycle/diagnose`
+- `/present#scene/prepared-lifecycle/repair`
 - `/present#scene/prepared-lifecycle/artifact`
 - `/present#scene/prepared-lifecycle/deployment`
 
 Confirm that one labelled textarea remains visible in every phase, is empty in
-Discover and Validate, and contains the exact prepared prompt in Draft,
+Discover, and contains the exact prepared prompt in Draft, Diagnose, Repair,
 Artifact, and Deployment. Confirm the right phase projection remains dominant,
 the panes do not overlap, and `document.documentElement.scrollHeight` equals
 `clientHeight`. Reload direct hashes before capture: in dev mode, immediate
 screenshots during an in-place hash transition can catch the presentation
 animation between surfaces even though the settled/reloaded route is correct.
 
-Edit and Send in Draft, then verify Validate contains that exact edited user
+Edit and Send in Draft, then verify Diagnose and Repair contain that exact edited
-turn. Repeat from Artifact to Deployment. On Deployment, Send must show only
+user turn. Repeat from Artifact to Deployment. On Deployment, Send must show only
 `Run request prepared for the next execution slice.`; compare `/api/rpc`
 request counts before and after to confirm no execution call was made. Scenes
-10–12 own the subsequent run activation and live execution path; do not use
+9–11 own the subsequent run activation and live execution path; do not use
-Scene 9 to claim a run has started.
+Scene 8 to claim a run has started.

docs/superpowers/specs/2026-07-05-adaptive-presentation-canvas-design.md

@@ -6,7 +6,7 @@ Approved design contract for adapting the thesis presentation between `4:3`
 and `16:9` displays and replacing the persistent evidence drawer.
 
 This specification narrows and updates the geometry and evidence behavior in
-the [defense presentation storyboard](2026-07-04-defense-presentation-storyboard-design.md).
+the [historical defense presentation storyboard](../../historical/superpowers/specs/2026-07-04-defense-presentation-storyboard-design.md).
 The storyboard remains authoritative for narrative order, claims, and scene
 content.
 

docs/superpowers/specs/2026-07-10-presentation-evaluation-closing-design.md

@@ -2,7 +2,7 @@
 
 ## Purpose
 
-Scenes 13 and 14 close the defense with evidence, claim boundaries, and a clear
+Scenes 12 and 13 close the defense with evidence, claim boundaries, and a clear
 statement of the thesis contribution. They must not read as a model leaderboard
 or as a generic list of limitations. The ending should move from bounded
 evaluation evidence, through supported future work, back to the stable
@@ -92,9 +92,9 @@ The scene keeps the existing evidence pointer to the thesis Evaluation and
 Appendix C. The existing `evaluation-validity` discussion branch remains
 available from the scene discussion rail.
 
-## Scene 14: Boundary, Future Layers, And Questions
+## Scene 13: Boundary, Future Layers, And Questions
 
-Scene 14 uses a stable contribution line as its central visual:
+Scene 13 uses a stable contribution line as its central visual:
 
 ```text
 External planner -> typed workflow substrate -> deterministic runtime
@@ -165,7 +165,7 @@ canonical discussion-branch catalog; it must not duplicate branch titles or
 answers in a second data structure.
 
 The Questions beat is a reusable presentation component but is only exposed as
-the final Scene 14 beat in this slice. A future presenter shortcut may open it
+the final Scene 13 beat in this slice. A future presenter shortcut may open it
 globally without changing the component.
 
 ## Component Boundaries
@@ -239,11 +239,11 @@ Implementation follows test-driven development.
 
 Automated coverage must include:
 
-- exact Scene 13 cohort and outcome counts;
+- exact Scene 12 cohort and outcome counts;
 - absence of percentages and model-ranking language;
 - validity reconciliation counts and claim-boundary wording;
 - all six observed UX findings;
-- all three Scene 14 non-claims;
+- all three Scene 13 non-claims;
 - all five supported future-work branches;
 - stable closing contribution wording;
 - the fourth `questions` beat and direct hash route;

docs/superpowers/specs/2026-07-12-demo-chrome-ownership-design.md

@@ -7,7 +7,7 @@ Approved design direction for the next presentation slice.
 ## Problem
 
 The presentation currently renders the live-target truth badge in the footer of
-every main scene. It also renders launch controls inside the Scene 10 operation
+every main scene. It also renders launch controls inside the Scene 9 operation
 content. The target-health model mixes service availability with replay/live
 playback, so a healthy live service can appear as `Replay evidence` while a
 direct replay route is being primed. These independent state changes produce
@@ -42,13 +42,13 @@ paths, not file contents or a read operation.
 
 The demo control rail is visible only for the prepared workflow arc:
 
-- Scene 8: `agent-handoff`
+- Scene 7: `agent-handoff`
-- Scene 9: `prepared-lifecycle`
+- Scene 8: `prepared-lifecycle`
-- Scene 10: `run-from-deployment`
+- Scene 9: `run-from-deployment`
-- Scene 11: `typed-human-boundary`
+- Scene 10: `typed-human-boundary`
-- Scene 12: `resume-output-evidence`
+- Scene 11: `resume-output-evidence`
 
-Scene 8 (`agent-handoff`) remains a scripted conversation, but gains the same
+Scene 7 (`agent-handoff`) remains a scripted conversation, but gains the same
 small footer control rail so the presenter can start the prepared run without
 adding another large button to the chat composition. All narrative,
 architecture, evaluation, conclusion, and discussion locations hide the target
@@ -94,7 +94,7 @@ height. It shows exactly one of these states:
   footprint.
 - While running: a non-interactive `Running workflow...` information label,
   not a disabled button.
-- While `demo.state.phase === "review"` on Scene 11
+- While `demo.state.phase === "review"` on Scene 10
   (`typed-human-boundary`): `Run paused - review required`. This is the only
   scene that exposes the paused label.
 - After completion: `Run complete`.
@@ -125,17 +125,17 @@ current static rows.
 The implementation must test:
 
 - title and non-demo scenes render no target badge or demo controls;
-- every Scene 8–12 beat renders exactly one compact demo rail;
+- every Scene 7–11 beat renders exactly one compact demo rail;
 - the pre-run demo rail renders the run action without an in-scene launch panel;
 - a running demo renders an information label instead of a disabled run button;
-- Scene 11 alone renders the review-required information label while the
+- Scene 10 alone renders the review-required information label while the
   decision form is waiting;
 - submitting or denying/revising the decision removes the paused label before
   the next scene is shown;
 - a completed demo renders the terminal information label;
 - a healthy target remains `Live target ready` while the timeline is replaying;
 - failed health renders replay fallback only inside demo scope;
-- backtracking between Scene 8–12 updates the rail from current state without
+- backtracking between Scene 7–11 updates the rail from current state without
   retaining stale copy;
 - backtracking from the demo arc to title removes the rail immediately;
 - checking does not change footer dimensions or mount a stale replay label;

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

@@ -11,14 +11,14 @@ reviewed recording only through an explicit replay action or an unavailable
 service.
 
 This slice does not change the Scene 1/2 story, fact-check storyboard content,
-Scene 8/9 authoring recording, chat framework, or visual theme system.
+Scene 7/8 authoring recording, chat framework, or visual theme system.
 
 ## Current Problem
 
 The live timeline controller and RPC executor already exist, but the visible
-action is owned by `OperatorChat`. Scenes 10–12 currently hide that chat, so a
+action is owned by `OperatorChat`. Scenes 9–11 currently hide that chat, so a
 prepared run can be implemented without a visible way to start it. Direct
-Scene 10–12 hashes also prime replay state by design, while the target health
+Scene 9–11 hashes also prime replay state by design, while the target health
 status is only probed on mount. This makes the system look disconnected even
 when `wf-rpc-server` is running.
 
@@ -27,8 +27,8 @@ when `wf-rpc-server` is running.
 ### Launch surface
 
 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
+Scenes 7-11. 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
+launch panel. Scene 9 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:
@@ -85,12 +85,12 @@ 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, the compact footer rail on
-   Scenes 8-12 exposes `Run prepared workflow` and starts a live timeline.
+   Scenes 7-11 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;
    both submitted and revision-requested outcomes are sent to the live server.
-4. A direct Scene 10–12 hash without an active run still shows the reviewed
+4. A direct Scene 9–11 hash without an active run still shows the reviewed
    replay, not a fabricated live state.
 5. When health fails, the presenter sees the reason and an explicit replay
    action; no live operation is silently represented as replay evidence.
@@ -98,7 +98,7 @@ 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 chat Send and Scene 9 staged messages remain deterministic authoring
+8. Scene 7 chat Send and Scene 8 staged messages remain deterministic authoring
    replay and do not call workflow authoring RPC operations. Their separate
    footer control may start the prepared run.
 
@@ -109,8 +109,8 @@ visibility, duplicate-start protection, explicit replay fallback, and live
 versus replay operation calls. A browser smoke run must verify:
 
 ```text
-Scene 10 operation -> live start -> interrupt -> approval -> resume -> trace
+Scene 9 operation -> live start -> interrupt -> approval -> resume -> trace
-Scene 10 direct hash with server unavailable -> explicit replay
+Scene 9 direct hash with server unavailable -> explicit replay
 server started after page load -> retry -> live-ready action
 ```
 

web/README.md

@@ -169,9 +169,8 @@ both modes. Replay is visibly labeled and does not create real issues.
 ### Presentation Mode
 
 The console exposes `/present`, a 720p no-scroll defense compositor for the
-prepared `lda_report_workflow` story. It renders a 14-scene, multi-beat
+  prepared `lda_report_workflow` story. It renders a 13-scene, multi-beat
-storyboard (expanded from the original 12-scene defense plan; items 13 and 14
+  storyboard with an adaptive aspect-ratio canvas, stable
-now cover evaluation and closing) with an adaptive aspect-ratio canvas, stable
 stage regions, discussion branches, one editorial canvas, persistent scene-aware
 assistant surfaces, and keyboard navigation.
 
@@ -188,23 +187,23 @@ The final presentation beats frame the evaluation as bounded evidence, make
 claim boundaries and future work explicit, and end on the canonical defense
 discussion index rather than a benchmark or generic conclusion.
 
-Scenes 8 and 9 use the canonical prepared-authoring recording as their only
+Scenes 7 and 8 use the canonical prepared-authoring recording as their only
-execution evidence. Scene 8 is a single full-screen chat-entry beat: its
+execution evidence. Scene 7 is a single full-screen chat-entry beat: its
 prefilled request is submitted locally, then reveals the first deterministic
 user, assistant, and Discover tool group. It is deterministic replay, not a live
-LLM chat, and does not start a workflow run. Scene 9 breaks the prepared
+LLM chat, and does not start a workflow run. Scene 8 breaks the prepared
-authoring into five phases with a persistent prepared-agent assistant pane on
+authoring into six beats with a persistent prepared-agent assistant pane on
 the left and a dominant phase canvas on the right. The adaptive split starts
 near 35/65 and keeps the matching prepared tool group synchronized with each
 factual source, graph, repair, artifact, or deployment view. Neither scene calls
-workflow authoring RPC operations — they consume deterministic prepared data. Scenes 10 through
+workflow authoring RPC operations — they consume deterministic prepared data. Scenes 9 through
-12 use the canonical replay by default when no live target is available. When
+11 use the canonical replay by default when no live target is available. When
 the resolved target is healthy, the same prepared run flow can execute through
 the public JSON-RPC operations and record live evidence using the same
 DemoRunFacts projection. Raw protocol payloads are available through the
 evidence receipt and inspector.
 
-Scenes 8–12 share one compact footer demo rail. Scene 8 remains a local scripted conversation, with its chat composer as the main surface, while the rail owns `Run prepared workflow`, replay fallback, retry, running, paused, resuming, and completed labels.
+Scenes 7–11 share one compact footer demo rail. Scene 7 remains a local scripted conversation, with its chat composer as the main surface, while the rail owns `Run prepared workflow`, replay fallback, retry, running, paused, resuming, and completed labels.
 With a healthy target, the rail starts the live chain through the existing
 `/api/rpc` proxy; when health fails, it keeps `Play replay walkthrough` as an
 explicit fallback. The presentation does not silently replace a live failure
@@ -228,19 +227,19 @@ presentation timeline.
 
 The key deep-link-addressable defense states include:
 
-- `/present#scene/agent-handoff/request` — Scene 8, prepared authoring request
+- `/present#scene/agent-handoff/request` — Scene 7, prepared authoring request
-- `/present#scene/prepared-lifecycle/discover` — Scene 9, discover phase
+- `/present#scene/prepared-lifecycle/discover` — Scene 8, discover phase
-- `/present#scene/prepared-lifecycle/draft` — Scene 9, draft phase
+- `/present#scene/prepared-lifecycle/draft` — Scene 8, draft phase
-- `/present#scene/prepared-lifecycle/deployment` — Scene 9, deployment phase
+- `/present#scene/prepared-lifecycle/deployment` — Scene 8, deployment phase
-- `/present#scene/run-from-deployment/operation` — Scene 10, run operation
+- `/present#scene/run-from-deployment/operation` — Scene 9, run operation
-- `/present#scene/run-from-deployment/graph` — Scene 10, workflow graph
+- `/present#scene/run-from-deployment/graph` — Scene 9, workflow graph
-- `/present#scene/typed-human-boundary/approval` — Scene 11, typed approval
+- `/present#scene/typed-human-boundary/approval` — Scene 10, typed approval
-- `/present#scene/resume-output-evidence/resume` — Scene 12, resume proof
+- `/present#scene/resume-output-evidence/resume` — Scene 11, resume proof
 
 Legacy aliases from the earlier 12-scene plan (such as `workflow-demo` and
 `interrupt-evidence`) are replaced by the IDs above and no longer resolve.
 
-Scene 12 is factual by design. It projects the reviewed/live run into visible
+Scene 11 is factual by design. It projects the reviewed/live run into visible
 workflow input, interrupt payload, resume decision, output, and trace facts.
 Empty trace frame objects are shown as captured empty objects; absent fields are
 called out as not captured rather than replaced by generic placeholders.
@@ -351,39 +350,39 @@ The current prepared recipe can:
 This is intentionally not a general autonomous planner. A future server-side
 Vercel AI SDK driver can feed the same message-part interface.
 
-### Authoring Story (Scenes 8 and 9)
+### Authoring Story (Scenes 7 and 8)
 
-Scenes 8 and 9 are the prepared authoring story. They use deterministic data
+Scenes 7 and 8 are the prepared authoring story. They use deterministic data
 from the committed `projectPreparedAuthoring()` recording and never call
 workflow authoring RPC operations.
 
-- **Scene 8 (Agent Request)**: a single full-screen deterministic chat entry that
+- **Scene 7 (Agent Request)**: a single full-screen deterministic chat entry that
   pre-fills the report-authoring request. Send is local presentation state and
   reveals the first prepared Discover tool group. This is not a live LLM chat
   or workflow run.
-- **Scene 9 (Prepared Workflow Lifecycle)**: a five-phase lifecycle
+- **Scene 8 (Prepared Workflow Lifecycle)**: a six-beat lifecycle
-  (discover, draft, validate, artifact, deployment) with a compact phase rail
+  (discover, draft, diagnose, repair, artifact, deployment) with a compact phase rail
   and one dominant factual product projection per beat. A persistent prepared
   assistant pane stays visible on the left while the phase canvas remains
   dominant on the right; the starting split is approximately 35/65 and adapts
   to the available width. Its active tool group follows the current beat. There
   is no lower chat dock, detached trace modal, or second transcript.
 
-  One staged message box remains visible in every phase. Discover and Validate
+  One staged message box remains visible in every phase. Discover starts empty
-  start empty with useful placeholders; Draft and Artifact use the exact next
+  with useful placeholders; Draft and Artifact use the exact next authoring
-  authoring prompts. Sending an edited Draft advances to Validate and preserves
+  prompts. Sending an edited Draft advances through Diagnose and Repair and preserves
   that text as the projected user turn; sending an edited Artifact does the
   same for Deployment. Deployment Send records only `Run request prepared for
   the next execution slice.` and makes no run or RPC request.
 
 The authoring scenes consume deterministic prepared data and never call
-workflow authoring RPCs. Scene 9 ends at the truthful run-request
+workflow authoring RPCs. Scene 8 ends at the truthful run-request handoff;
-handoff; Scenes 10–12 own run activation, typed approval, resume, output, and
+Scenes 9–11 own run activation, typed approval, resume, output, and trace
-trace evidence. No Scene 9 message submission starts a workflow run.
+evidence. No Scene 8 message submission starts a workflow run.
 
-### Demo Climax (Scenes 8–12)
+### Demo Climax (Scenes 7–11)
 
-Scenes 8 through 12 are the demo climax. They keep a continuity rail visible
+Scenes 7 through 11 are the demo climax. They keep a continuity rail visible
 while the prepared replay moves from persisted workflow run, to typed human
 interrupt, to resume/output/evidence. The rail and outcome panel are
 presentation-only projections over the committed replay; they do not add live

web/apps/console/src/presentation/presenter/PresenterRoute.test.tsx

@@ -15,7 +15,7 @@ describe("PresenterRoute", () => {
     expect(screen.getByRole("main", { name: /lda.chat presenter notes/i })).toBeInTheDocument();
     expect(screen.getByText(/This project began with the goal/i)).toBeInTheDocument();
     expect(screen.getByText("the system underneath the chat").tagName).toBe("STRONG");
-    expect(screen.getByRole("navigation", { name: /presenter note navigation/i })).toHaveTextContent("1 / 43");
+    expect(screen.getByRole("navigation", { name: /presenter note navigation/i })).toHaveTextContent("1 / 39");
     expect(screen.getByRole("link", { name: "Next →" })).toHaveAttribute("href", "#scene/thesis/substrate");
     expect(screen.getByRole("link", { name: /open audience slide/i })).toHaveAttribute("href", "/present#scene/thesis/title");
     expect(screen.queryByText(/live target/i)).not.toBeInTheDocument();

web/apps/console/src/presentation/presenter/presenter-notes.test.ts

@@ -14,8 +14,10 @@ import {
 describe("presenter note catalog", () => {
   it("has exactly one note for every current storyboard beat", () => {
     const noteKeys = presenterNotes.map((note) => `${note.sceneId}/${note.beatId}`);
+    const canonicalKeys = mainScenes.flatMap((scene) => scene.beats.map((beat) => `${scene.id}/${beat.id}`));
 
     expect(new Set(noteKeys).size).toBe(noteKeys.length);
+    expect([...noteKeys].sort()).toEqual([...canonicalKeys].sort());
     for (const scene of mainScenes) {
       for (const beat of scene.beats) {
         const note = presenterBeatNoteFor(scene.id, beat.id);
@@ -24,7 +26,7 @@ describe("presenter note catalog", () => {
       }
     }
 
-    expect(noteKeys).toHaveLength(mainScenes.flatMap((scene) => scene.beats).length);
+    expect(noteKeys).toHaveLength(canonicalKeys.length);
   });
 
   it("keeps the planned scene timing and complete-deck cap", () => {
@@ -44,18 +46,33 @@ describe("presenter note catalog", () => {
       75,
     ]);
     expect(completeDeckTargetSeconds()).toBe(735);
-    expect(completeDeckTargetSeconds()).toBeLessThanOrEqual(780);
+    expect(completeDeckTargetSeconds()).toBeLessThanOrEqual(900);
+    expect(presenterSceneNotes("prepared-lifecycle")).toHaveLength(6);
+    for (const note of presenterSceneNotes("prepared-lifecycle")) {
+      expect(note.targetSeconds).toBeGreaterThanOrEqual(8);
+      expect(note.targetSeconds).toBeLessThanOrEqual(10);
+    }
+  });
+
+  it("keeps removed scene and beat IDs out of timed notes", () => {
+    expect(presenterNotes.some((note) => note.sceneId === ("authoring" as typeof mainScenes[number]["id"]))).toBe(false);
+    expect(presenterBeatNoteFor("prepared-lifecycle", "validate")).toBeUndefined();
+    expect(presenterBeatNoteFor("architecture", "node-use")).toBeUndefined();
+  });
+
+  it("describes structured diagnosis and the focused output-map repair", () => {
+    expect(presenterBeatNoteFor("prepared-lifecycle", "diagnose")?.mustSay).toMatch(/structured diagnostics/i);
+    expect(presenterBeatNoteFor("prepared-lifecycle", "repair")?.mustSay).toMatch(/focused output-map edit/i);
   });
 
   it("keeps NodeUse out of timed notes while retaining the architecture spine", () => {
-    expect(presenterBeatNoteFor("architecture", "node-use")).toBeUndefined();
     expect(presenterBeatNoteFor("architecture", "overview")).toBeDefined();
     expect(presenterBeatNoteFor("architecture", "api")).toBeDefined();
     expect(presenterBeatNoteFor("architecture", "runtime")).toBeDefined();
   });
 
   it("keeps the must-say speech within the defense word budget", () => {
-    expect(mainSpeechWordCount()).toBeGreaterThanOrEqual(750);
+    expect(mainSpeechWordCount()).toBeGreaterThanOrEqual(650);
     expect(mainSpeechWordCount()).toBeLessThanOrEqual(850);
   });
 

web/apps/console/src/presentation/presenter/presenter-notes.ts

@@ -199,7 +199,7 @@ export const presenterNotes = [
     "prepared-lifecycle",
     "discover",
     9,
-    "The later issue-review example first inspects configured local.lda_docs, report, and issue-board capabilities.",
+    "It inspects sources, capabilities, and schemas rather than guessing at hidden interfaces.",
     ["examples/lda_report_workflow", "deployment inspect replay evidence"],
     { qnaBranchIds: ["prepared-replay-boundary", "why-schemas", "validation-diagnostics"] },
   ),
@@ -207,7 +207,7 @@ export const presenterNotes = [
     "prepared-lifecycle",
     "draft",
     9,
-    "It creates and edits a Draft for report generation, making the proposal visible before execution.",
+    "Focused operations modify mutable authoring state before execution.",
     ["examples/lda_report_workflow", "deployment inspect replay evidence", "CLI documentation", "Draft authoring API"],
     { qnaBranchIds: ["raw-plan-import"] },
   ),
@@ -215,7 +215,7 @@ export const presenterNotes = [
     "prepared-lifecycle",
     "diagnose",
     9,
-    "Validation returns structured diagnostics, affected paths, repair hints, and suggested next actions.",
+    "Structured diagnostics identify the missing output projection.",
     ["examples/lda_report_workflow", "deployment inspect replay evidence"],
     { qnaBranchIds: ["validation-diagnostics"] },
   ),
@@ -223,7 +223,7 @@ export const presenterNotes = [
     "prepared-lifecycle",
     "repair",
     9,
-    "These surfaces make invalid intermediate drafts repairable; they support a loop, but no hint guarantees success.",
+    "One focused output-map edit resolves it; hints do not guarantee automatic repair.",
     ["Validation and diagnostics", "Challenge UX findings"],
     { warning: "Do not promise that diagnostics automatically repair every workflow.", qnaBranchIds: ["validation-diagnostics"] },
   ),
@@ -238,9 +238,9 @@ export const presenterNotes = [
     "prepared-lifecycle",
     "deployment",
     9,
-    "This later issue-review example is richer than the thesis three-node deterministic report case study: it is an implementation extension built on the same platform. Deployment binds and validates a ready configuration but does not run the workflow.",
+    "Deployment binds and validates three local sources; execution starts in the next scene.",
     ["examples/lda_report_workflow", "deployment inspect replay evidence", "Thesis deterministic report case study"],
-    { warning: "Do not present issue-board output from this later example as the thesis case study.", qnaBranchIds: ["prepared-replay-boundary"] },
+    { warning: "This later issue-review example is richer than the thesis case study; do not present its issue-board output as thesis output.", qnaBranchIds: ["prepared-replay-boundary"] },
   ),
   beatNote(
     "run-from-deployment",