docs: plan audited defense presentation follow-ups

docs/current_roadmap.md

@@ -82,15 +82,16 @@ Implementation order:
    Implementation:
    [`React presentation mode plan`](historical/superpowers/plans/2026-07-03-react-presentation-mode.md).
 8. Completed: constrained demo agent that invokes one prepared recipe macro.
-   Live mode is deferred to a future slice; the prepared driver is replay-only
+   This agent driver remains replay-only. A separate presentation runtime added
-   for now.
+   live prepared-run activation in a later slice.
    Design:
    [`constrained demo agent`](superpowers/specs/2026-07-03-constrained-demo-agent-design.md).
    Implementation:
    [`constrained demo agent plan`](historical/superpowers/plans/2026-07-03-constrained-demo-agent.md).
-9. Completed: implement the approved 12-scene defense storyboard as a no-scroll
+9. Completed: implement the original 12-scene defense storyboard as a no-scroll
-   720p compositor. Content and evidence freeze before chat replacement, visual
+   720p compositor. Later slices expanded the current deck to 14 scenes. Content
-   polish, or motion tuning. Design:
+   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).
    Implementation:
    [`defense storyboard compositor plan`](historical/superpowers/plans/2026-07-04-defense-storyboard-compositor.md).
@@ -406,6 +407,13 @@ Presentation wishlist / defense readiness:
   [`defense presentation runbook`](runbooks/defense-presentation.md) covers
   exact URLs, keyboard controls, live RPC/demo fallback steps, story spine,
   timing, and short speaker notes for what to say if the live demo fails.
+  [`defense speech and claim audit`](runbooks/defense-speech-and-claim-audit.md)
+  provides the current 13-minute speech, evidence qualifications, and
+  prioritized 12-minute Q&A.
+  Planned follow-ups, in dependency order:
+  [`defense story reweighting`](superpowers/plans/2026-07-13-defense-story-reweighting.md),
+  [`Scenes 3-6 kernel choreography`](superpowers/plans/2026-07-13-scenes-3-6-kernel-choreography.md),
+  and [`read-only presenter route`](superpowers/plans/2026-07-13-read-only-presenter-route.md).
 - Defense Q&A branch set:
   [`defense Q&A runbook`](runbooks/defense-qna.md) collects answers for
   "Where is the AI agent?", evaluation validity, security boundaries, demo

docs/runbooks/defense-presentation.md

@@ -241,22 +241,22 @@ Say:
 > can represent, validate, execute, interrupt, resume, and inspect a reusable
 > workflow.
 
-## Fifteen-Minute Timing
+## Twenty-Five-Minute Timing
 
-Target a 12-minute main path, leaving three minutes for questions.
+Target a 13-minute main path, leaving 12 minutes for questions.
 
 | Time | Segment | Notes |
 |---:|---|---|
-| 0:00-1:00 | Title and framing | AI-agent goal -> workflow substrate contribution |
+| 0:00-1:30 | Title and problem | AI-agent goal becomes a workflow substrate contribution |
-| 1:00-2:30 | Problem and positioning | Automation is hard; AI needs durable workflow contracts |
+| 1:30-5:20 | Positioning and architecture | Planner/runtime boundary, lifecycle, implementation, authoring |
-| 2:30-4:00 | Planner/runtime boundary | External planner proposes; platform owns execution |
+| 5:20-9:45 | Prepared demonstration | Request, deployment, start, interrupt, resume, output, trace |
-| 4:00-5:30 | Lifecycle | Draft, artifact, deployment, run |
+| 9:45-11:00 | Evaluation | 36 audited trials as bounded engineering evidence |
-| 5:30-7:00 | Architecture zoom | Client/API/runtime/NodeUse |
+| 11:00-12:30 | Limits and conclusion | Security, scheduling, evaluation, and agent-layer boundaries |
-| 7:00-8:30 | Authoring and repair | Discovery, schemas, diagnostics, repair hints |
+| 12:30-13:00 | Transition buffer | Finish navigation and hand over to questions |
-| 8:30-10:30 | Demo | Start, interrupt, approval/resume, trace |
+| 13:00-25:00 | Questions | Use prepared Q&A branches when available |
-| 10:30-11:30 | Evaluation | 36 audited trials as bounded engineering evidence |
+
-| 11:30-12:00 | Limits and future work | Agent wrapper, security, scheduling, comparative studies |
+Use [`defense-speech-and-claim-audit.md`](defense-speech-and-claim-audit.md)
-| 12:00-15:00 | Questions | Use prepared Q&A branches when available |
+for the rehearsed speech, evidence qualifications, and prioritized Q&A.
 
 ## Expected Hard Questions
 
@@ -301,8 +301,9 @@ Answer:
 
 ## Pre-Defense Checklist
 
-1. Start `/present` with the intended target and verify the Scene 8 `Run
+1. Start `/present` with the intended target. Verify Scene 8 submits the prepared
-   prepared workflow` action is enabled when the live badge is ready.
+   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
    trace.
 3. Reload, complete one revision-requested branch, and confirm no issues plus

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

@@ -0,0 +1,348 @@
+# Defense speech and claim audit
+
+This runbook gives you a near-complete 13-minute defense speech 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.
+
+## Timing and evidence rules
+
+Use these evidence labels while rehearsing. Do not read the labels aloud.
+
+- **Supported**: stated in the thesis and backed by repository evidence
+- **Implementation extension**: implemented after or beyond the thesis case study; identify it as a separate demonstration
+- **Qualify**: accurate only within an explicit boundary
+- **Do not claim**: unsupported, untested, or excluded from scope
+
+Target 12:30 for the rehearsed speech. Keep 30 seconds for navigation or demo delay. The question period then has 12 minutes.
+
+| Segment | Target |
+| --- | ---: |
+| Scenes 1-2: goal and problem | 1:30 |
+| Scenes 3-7: positioning, model, and implementation | 4:00 |
+| Scenes 8-12: prepared demonstration | 4:30 |
+| Scene 13: evaluation | 1:15 |
+| Scene 14: limits and conclusion | 1:15 |
+
+## Main speech
+
+### Scene 1: State the ambition and the submitted contribution
+
+**Route:** `thesis/title` then `thesis/substrate`  
+**Time:** 0:00-0:45  
+**Evidence:** Supported
+
+Say:
+
+> My project began with the goal in the title: an AI agent for creating and automating workspace workflows. While developing it, I found that the difficult engineering problem was not another chat interface or planning loop. It was the system underneath one.
+>
+> The submitted contribution is `lda.chat` as a typed workflow substrate. An external agent can propose work, but the platform owns workflow definitions, validation, deployment bindings, execution records, traces, and explicit resume boundaries. The thesis therefore studies the infrastructure an agent needs, not a new autonomous planning algorithm.
+
+Keep the boundary explicit. The thesis states this distinction in the Abstract and Introduction ([thesis lines 109-121](../thesis/system-design-implementation.md#abstract) and [lines 145-181](../thesis/system-design-implementation.md#introduction)).
+
+### Scene 2: Explain why direct tool use is insufficient
+
+**Route:** `problem/direct-actions` then `problem/missing-contracts`  
+**Time:** 0:45-1:30  
+**Evidence:** Supported
+
+Say:
+
+> A model can already call tools and complete a task. The problem appears when that task must become reusable automation. A tool transcript does not automatically give us a versioned definition, source bindings, validation, persisted execution, trace inspection, or a safe place to resume after an interruption.
+>
+> My research question became: how can an AI-agent-facing workflow platform represent, validate, execute, and persist reusable workspace automation while keeping planning separate from execution? The platform owns those durable contracts so the planner does not have to recreate them on every run.
+
+Do not claim that direct tool use or generated scripts are inherently bad. The thesis argues that reusable operation needs additional lifecycle contracts ([lines 214-277](../thesis/system-design-implementation.md#problem-statement-and-requirements)).
+
+### Scene 3: Position the work without claiming superiority
+
+**Route:** `positioning/landscape` then `positioning/lda-position`  
+**Time:** 1:30-2:10  
+**Evidence:** Supported, with qualification
+
+Say:
+
+> Related systems have different centers of gravity. Direct tool loops optimize immediate action. Generated scripts package code. Hosted automation platforms provide mature operations. Agent graph frameworks organize planner behavior. Model Context Protocol exposes capabilities.
+>
+> `lda.chat` does not claim to replace those systems or outperform them. Its narrower position is a typed, provider-neutral lifecycle for workflows authored or operated by external agents. MCP, Python sources, and built-in capabilities can enter the same workflow model, while the core runtime remains independent of provider-specific behavior.
+
+Qualify provider neutrality as demonstrated for the three implemented source families. Do not present compatibility with arbitrary future providers as measured evidence ([lines 460-521](../thesis/system-design-implementation.md#source-model)).
+
+### Scene 4: Draw the planner and runtime boundary
+
+**Route:** `planner-runtime/planner`, `planner-runtime/runtime`, then `planner-runtime/boundary`  
+**Time:** 2:10-2:55  
+**Evidence:** Supported, with qualification
+
+Say:
+
+> The central architectural decision is the planner-runtime split. An external model or human proposes and revises workflow structure. The runtime validates the graph, resolves sources, executes steps, records state and traces, and resumes only through declared boundaries.
+>
+> Clients cross this boundary through typed CLI and JSON-RPC operations. Both reach the same workflow API instead of importing runtime internals. This is what makes the system agent-operable: the public surface exposes schemas, diagnostics, and lifecycle operations in machine-readable form.
+
+Say “deterministic core semantics for fixed definitions and handler results,” not “all execution is deterministic.” Remote calls, provider code, resource reads, and external side effects may be nondeterministic ([lines 808-821](../thesis/system-design-implementation.md#workflow-core)).
+
+### Scene 5: Define the lifecycle vocabulary
+
+**Route:** `lifecycle/draft`, `lifecycle/artifact`, `lifecycle/deployment`, then `lifecycle/run`  
+**Time:** 2:55-3:35  
+**Evidence:** Supported
+
+Say:
+
+> Four records separate concerns that are often collapsed together. A Draft is mutable authoring state. An Artifact is an immutable workflow definition. A Deployment binds an artifact version to concrete sources and runtime context. A Run records one execution, including status, diagnostics, output, trace, and an explicit stopped or interrupted state.
+>
+> This separation lets the same artifact be deployed against different source environments, and it preserves what was defined separately from what was executed.
+
+Keep Scene 5 conceptual. Scene 9 applies this vocabulary to the prepared example. Also note that raw plans can create artifacts without passing through Draft ([lines 629-660](../thesis/system-design-implementation.md#workflow-lifecycle)).
+
+### Scene 6: Zoom through the implemented architecture
+
+**Route:** `architecture/client`, `architecture/api`, `architecture/runtime`, then `architecture/node-use`  
+**Time:** 3:35-4:35  
+**Evidence:** Supported
+
+Say:
+
+> From the outside, human and agent clients use the same lifecycle operations. JSON-RPC handles transport concerns and delegates to the workflow API. Server composition supplies stores, source providers, and the runtime. The core owns workflow semantics without importing MCP or Python provider behavior.
+>
+> At the execution level, a NodeUse resolves and validates its input, invokes a projected capability, verifies the declared outcome, reduces output into workflow state, appends a trace frame, and routes through the corresponding edge. Each zoom level answers a different responsibility rather than exposing one large service.
+
+The NodeUse sequence is documented in the thesis runtime diagram and narrative ([lines 706-750](../thesis/system-design-implementation.md#workflow-core-model)).
+
+### Scene 7: Explain agent-operable authoring
+
+**Route:** `authoring/discover`, `authoring/author`, `authoring/diagnose`, then `authoring/repair`  
+**Time:** 4:35-5:20  
+**Evidence:** Supported, with qualification
+
+Say:
+
+> Agent operation needs more than command availability. Before authoring, a client can discover sources, capabilities, and schemas. It can then change a mutable draft through focused operations. Validation returns structured diagnostics, affected paths, repair hints, and suggested next actions.
+>
+> These surfaces reduce guessing and make invalid intermediate drafts repairable. The evaluation showed why this mattered: agents inspected source code when the public surface omitted schemas or import operations, and those failures directly motivated product changes.
+
+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:20-5:50  
+**Evidence:** Implementation extension
+
+Say:
+
+> I will now show a prepared demonstration built on the platform. The chat is a presentation interface, not the autonomous planner evaluated by the thesis. It translates a report request into the same public lifecycle operations an external agent could call.
+>
+> The prepared path keeps the defense deterministic. It demonstrates product behavior and recorded evidence; it is not a fresh model-performance result.
+
+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
+
+**Route:** all five `prepared-lifecycle/*` beats  
+**Time:** 5:50-6:55  
+**Evidence:** Implementation extension
+
+Say:
+
+> The prepared workflow first discovers the configured `local.lda_docs`, report, and issue-board capabilities. It creates and edits a draft, validates incomplete state, applies the repair, saves an immutable artifact, then binds and validates a deployment.
+>
+> Notice the lifecycle boundary: deployment records a ready configuration, but it does not execute the workflow. The run begins only 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.
+
+### Scene 10: Start the prepared workflow
+
+**Route:** `run-from-deployment/input`, `run-from-deployment/operation`, then `run-from-deployment/graph`  
+**Time:** 6:55-7:50  
+**Evidence:** Implementation extension; live-capable
+
+Say:
+
+> The deployment receives selected local documents and an issue-board path. The public `workflow.runs.start` operation validates the input and deployment, creates a persisted run record, and begins the reusable graph.
+>
+> The graph reads documents, analyzes them, builds a report, drafts proposed issues, and reaches a declared review interrupt before applying issue-board changes. The graph is the reusable artifact; the chat only initiated the lifecycle operations.
+
+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
+
+**Route:** `typed-human-boundary/interrupt` then `typed-human-boundary/approval`  
+**Time:** 7:50-8:35  
+**Evidence:** Implementation extension; qualify
+
+Say:
+
+> Execution pauses at a typed `issue_review` interrupt. The interrupt record exposes the request payload, allowed outcomes, request schema, and resume schema. The interface can therefore render the decision from an explicit contract instead of relying on hidden application knowledge.
+>
+> In this example, submitting continues to issue creation. Requesting revision selects the workflow’s `cancelled` outcome and follows the revision branch. This is a typed interrupt and resume mechanism, not a production approval, role, or policy system.
+
+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
+
+**Route:** `resume-output-evidence/resume`, `resume-output-evidence/output`, then `resume-output-evidence/trace`  
+**Time:** 8:35-9: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, records terminal output, and preserves trace frames and protocol evidence for inspection.
+>
+> The important claim is inspectability at a declared boundary. It is not arbitrary mid-node crash recovery, exactly-once execution, or time-travel debugging.
+
+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.
+
+### Scene 13: Explain what the evaluation proves
+
+**Route:** `evaluation/cohort`, `evaluation/validity`, then `evaluation/findings`  
+**Time:** 9:45-11:00  
+**Evidence:** Supported, with strict qualification
+
+Say:
+
+> The evaluation combines automated conformance tests, deterministic case studies, and a manually audited external-agent campaign. The campaign contains 36 trials across two challenges, two hosted models, three instruction profiles, and three longitudinal waves, with three attempts per cell.
+>
+> Manual audit classified 27 as clean product-path passes, eight as invalid samples, and one as a failure. Invalid samples included contamination such as reading implementation files, prior artifacts, adjacent attempts, or evaluator state. That distinction matters because apparent task completion is not enough when an agent bypasses the intended product surface.
+>
+> These results support feasibility and expose authoring and diagnostic gaps. They do not estimate general model success, compare models under stable conditions, or demonstrate token reduction, retry reduction, or superiority over other orchestration systems.
+
+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
+
+**Route:** `conclusion/limits`, `conclusion/future`, `conclusion/conclusion`, then `conclusion/questions`  
+**Time:** 11:00-12:30  
+**Evidence:** Supported
+
+Say:
+
+> The prototype has clear limits. Python sources are trusted in-process code. Stores are file-backed. Provider lifecycle management is incomplete. The system does not provide production authentication, role-based access control, sandboxing, scheduling, general fork-and-gather execution, arbitrary crash recovery, or a bundled autonomous planner.
+>
+> Future work can add those operational layers, a live agent interface, transactional storage, richer debugging, and a controlled comparative evaluation. Those additions can build on the lifecycle and provider boundaries instead of moving planning logic into the runtime.
+>
+> The contribution is therefore architectural and implemented: external planners can propose workflows; a typed platform can validate, bind, execute, persist, interrupt, resume, and inspect them through public operations. The prototype shows that this separation works across controlled built-in, MCP, and Python source examples.
+>
+> Thank you. I welcome your questions.
+
+## Live and replay fallback wording
+
+Use one sentence and continue. Do not apologize or debug during the timed defense.
+
+- **Replay selected:** “This is the reviewed recording of the deterministic path, not a fresh model or live-server result.”
+- **Live target unavailable:** “The live target is unavailable, so I am switching to the recorded operation evidence used for rehearsal.”
+- **Run state is unexpected:** “I will use the recorded branch so the lifecycle and evidence remain inspectable.”
+- **Trace is unavailable:** “The live trace did not load. The prepared trace route shows the reviewed frames; automated tests separately verify trace retrieval.”
+- **Revision branch shown:** “This is a separate prepared branch recording, so I am not claiming run-ID continuity with the submitted recording.”
+
+## Prioritized 12-minute Q&A
+
+Start with the short answer. Expand only when the examiner continues.
+
+### 1. Where is the AI agent, and does the title overclaim?
+
+**Short answer:** The autonomous planner is external. The submitted contribution is the typed workflow substrate that an agent operates.
+
+**Expanded answer:** The original product ambition was an AI agent for workspace automation. The thesis narrowed the technical contribution to the infrastructure beneath that agent: schemas, lifecycle records, source bindings, validation, execution, traces, and explicit resume contracts. A chat or planner graph can use the `wf` operations as tools, but the thesis does not claim a new planning algorithm.
+
+### 2. What is novel about the work?
+
+**Short answer:** The contribution is the combination of an agent-operable lifecycle, provider-neutral capabilities, structured repair surfaces, and persisted execution boundaries.
+
+**Expanded answer:** Individual concepts exist elsewhere. The thesis contribution is their integration around external agents as workflow authors and operators: Draft, Artifact, Deployment, and Run records; provider projection outside the core; diagnostics and next actions; and CLI/JSON-RPC access without runtime imports. The thesis claims architectural feasibility, not invention of workflow graphs.
+
+### 3. Why not use scripts, LangGraph, n8n, Zapier, Temporal, or MCP?
+
+**Short answer:** They solve adjacent problems. The thesis does not claim global superiority.
+
+**Expanded answer:** Scripts package code but leave lifecycle and inspection to custom conventions. LangGraph focuses on agent graphs. Temporal emphasizes durable distributed execution. n8n and Zapier provide mature hosted automation. MCP exposes capabilities. `lda.chat` focuses on typed workflow lifecycle and repair surfaces designed for external-agent operation, with MCP and Python behind one provider boundary.
+
+### 4. What do the 36 trials prove?
+
+**Short answer:** They provide bounded engineering evidence about operability and failure modes, not a model benchmark.
+
+**Expanded answer:** The campaign used two challenges, two hosted models, three profiles, three waves, and three attempts per cell. The author manually audited product-path validity. Because prompts, product snapshots, and hosted conditions changed, the results support feasibility and longitudinal product learning, not stable model comparison or general success rates.
+
+### 5. Is the prepared replay honest?
+
+**Short answer:** Yes, if it is labeled as recorded presentation evidence rather than fresh live planning.
+
+**Expanded answer:** Replay demonstrates the same prepared operation sequence without depending on network or model latency. Automated tests and repository examples verify underlying behavior separately. It would be misleading only if presented as a new autonomous-agent result or as proof that the full live path was rehearsed.
+
+### 6. Is the system production-ready or secure?
+
+**Short answer:** No. It is a systems prototype with explicit non-goals.
+
+**Expanded answer:** Python sources are trusted and unsandboxed. Stores are file-backed. Production credentials, role-based authorization, tenant isolation, secret management, policy enforcement, and operational monitoring remain future work. Provider and deployment boundaries create places for those controls, but they do not implement them.
+
+### 7. Why separate Artifact and Deployment?
+
+**Short answer:** An Artifact preserves what the workflow is; a Deployment records where and with which sources it can run.
+
+**Expanded answer:** The separation keeps a workflow definition immutable while allowing environment-specific bindings and validation. Deployment validation can detect missing capabilities or source drift without rewriting the artifact.
+
+### 8. What does resumability mean here?
+
+**Short answer:** The runtime persists and resumes explicit stopped or interrupted boundaries.
+
+**Expanded answer:** Resume validates a declared payload and outcome, restores persisted state, and follows the selected route. The thesis does not claim arbitrary mid-node checkpointing, exactly-once side effects, or general crash recovery.
+
+### 9. Does the typed decision implement human approval?
+
+**Short answer:** It implements a typed interrupt and decision contract, not a production approval system.
+
+**Expanded answer:** The workflow declares request and resume schemas plus allowed outcomes. The demo renders an operator decision from that contract. Roles, authorization, policy, multi-user review, and approval governance are not implemented.
+
+### 10. Why use JSON-RPC?
+
+**Short answer:** It exposes the same workflow API to long-lived external clients without moving domain behavior into transport code.
+
+**Expanded answer:** The CLI can target the JSON-RPC server, and the web console uses the same protocol boundary. JSON-RPC is an implementation choice, not the thesis contribution; the protocol-neutral workflow API is the architectural seam.
+
+### 11. What is the strongest evidence in the thesis?
+
+**Short answer:** The strongest evidence is the combination of conformance tests, deterministic case studies, and bounded audited agent trials.
+
+**Expanded answer:** Tests verify lifecycle operations, deployment validation, source providers, interrupt/resume, and transport behavior. Case studies demonstrate controlled end-to-end paths. The agent campaign then exposes whether external clients can use the public surface without bypassing it.
+
+### 12. What would you do next?
+
+**Short answer:** First harden operations and evaluation, then add the surrounding live agent interface.
+
+**Expanded answer:** Priorities are transactional storage, provider lifecycle management, production auth and secret handling, sandboxing, richer run debugging, and stable controlled evaluation. A live chat or planner loop can then call the existing operations without changing the core runtime boundary.
+
+## Claim audit summary
+
+| Presentation claim | Status | Safe wording |
+| --- | --- | --- |
+| `lda.chat` is an autonomous AI agent | Do not claim | It is the workflow substrate operated by an external planner |
+| Runtime execution is deterministic | Qualify | Core routing and state transitions are deterministic for fixed handler results |
+| Draft, Artifact, Deployment, and Run are distinct records | Supported | State the four responsibilities directly |
+| Built-in, MCP, and Python prove provider neutrality | Qualify | Demonstrated across these three controlled source families |
+| Repair hints make workflows valid | Qualify | Diagnostics and hints support repair; they do not guarantee success |
+| The demo is the thesis case study | Do not claim | It is a later issue-review demonstration built on the same platform |
+| Issue-board changes are thesis case-study output | Do not claim | They belong to the later prepared example implementation |
+| The decision surface is a production approval gate | Do not claim | It is a typed interrupt and resume contract |
+| Submitted replay resumes the same run | Supported | Valid for the submitted recording |
+| Revision replay uses the same run | Do not claim | It is a separate prepared branch recording |
+| Resume provides arbitrary crash recovery | Do not claim | Resume works at explicit stopped or interrupted boundaries |
+| The 36 trials estimate model success | Do not claim | They are bounded longitudinal engineering evidence |
+| The campaign measured token or retry reduction | Do not claim | These remain unmeasured design hypotheses |
+| The system is production-secure or scheduled | Do not claim | Security hardening and scheduling remain future work |
+
+## Evidence anchors
+
+- Thesis framing and contributions: [Abstract](../thesis/system-design-implementation.md#abstract), [Introduction](../thesis/system-design-implementation.md#introduction), and [Contributions](../thesis/system-design-implementation.md#contributions)
+- Lifecycle definitions: [Lifecycle objects](../thesis/system-design-implementation.md#lifecycle-objects)
+- Architecture and NodeUse: [System architecture](../thesis/system-design-implementation.md#system-architecture) and [Workflow core model](../thesis/system-design-implementation.md#workflow-core-model)
+- Validation and repair: [Validation and diagnostics](../thesis/system-design-implementation.md#validation-and-diagnostics)
+- Evaluation scope: [Evaluation](../thesis/system-design-implementation.md#evaluation) and [Agent challenge harness](../thesis/system-design-implementation.md#agent-challenge-harness)
+- Limitations and future work: [Limitations](../thesis/system-design-implementation.md#limitations) and [Future work](../thesis/system-design-implementation.md#future-work)
+- Prepared example implementation: `examples/lda_report_workflow/`
+- Presentation replay evidence: `web/apps/console/src/demo/recordings/lda-report-success.v1.json`
+- Revision replay identity: `web/apps/console/src/demo/timeline/replay.ts`
+
+## Presentation defects to resolve or avoid
+
+- The prepared authoring recording labels several actions with `workflow.draft_workspaces.*`, while the current JSON-RPC namespace is `workflow.drafts.*`. Until the recording is corrected, describe the visible entries as prepared lifecycle actions or CLI commands, not exact JSON-RPC method names.
+- 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 revision replay has a separate run ID. Never use the submitted branch’s “same persisted run” wording for that branch.

docs/superpowers/plans/2026-07-13-defense-story-reweighting.md

@@ -0,0 +1,79 @@
+# Defense story reweighting implementation plan
+
+> **For agentic workers:** Use subagent-driven development or execute this plan task by task. Follow TDD and request an independent review before completion.
+
+**Goal:** Reweight the 14-scene defense around the thesis contribution, reduce the must-say speech to 750-850 words, and create one structured source for future presenter notes.
+
+**Architecture:** Keep `storyboard.ts` as the audience route and visual catalog. Add a separate typed presenter-note catalog keyed by scene and beat. The catalog owns speech, timing, evidence, warnings, fallback wording, and Q&A links. Audience components must not render presenter-only content.
+
+**Tech stack:** React 19, TypeScript, Vitest, existing presentation state and storyboard models.
+
+## Constraints
+
+- Preserve 14 scenes and current route order.
+- Do not add another demo scene.
+- Treat Scene 5 as vocabulary and Scene 9 as evidence.
+- Describe the later issue-review workflow as an implementation extension, not the thesis's three-node report case study.
+- Do not claim production approval, scheduling, broad model performance, arbitrary crash recovery, or live Scene 10-12 rehearsal.
+- Submitted replay may use same-run wording. Revision replay must be labeled as a separate prepared recording.
+- Keep the main speech between 750 and 850 words, excluding optional notes and Q&A.
+
+## Task 1: Define the presenter-note contract
+
+**Files:**
+- Create: `web/apps/console/src/presentation/presenter/presenter-notes.ts`
+- Create: `web/apps/console/src/presentation/presenter/presenter-notes.test.ts`
+- Read: `docs/runbooks/defense-speech-and-claim-audit.md`
+
+- [ ] Define `PresenterBeatNote` with `sceneId`, `beatId`, `targetSeconds`, `mustSay`, `optionalDetail`, `warning`, `fallback`, `evidencePointers`, and `qnaBranchIds`.
+- [ ] Use explicit nullable fields rather than empty placeholder strings.
+- [ ] Add helpers for route lookup, scene totals, complete-deck totals, and main-speech word count.
+- [ ] Test that every storyboard beat has exactly one note, no stale note exists, total target time is at most 780 seconds, and must-say text is 750-850 words.
+- [ ] Test that every evidence pointer is non-empty and every Q&A ID resolves through `discussionBranchForId`.
+
+Troubleshooting: derive route completeness from `mainScenes`; do not maintain a second route array.
+
+## Task 2: Reweight the speech and scene transitions
+
+**Files:**
+- Modify: `web/apps/console/src/presentation/presenter/presenter-notes.ts`
+- Modify: `web/apps/console/src/presentation/storyboard.ts`
+- Modify: `docs/runbooks/defense-speech-and-claim-audit.md`
+- Modify: `docs/runbooks/presentation-rehearsal-matrix.md`
+- Test: `web/apps/console/src/presentation/storyboard.test.ts`
+- Test: `web/apps/console/src/presentation/presenter/presenter-notes.test.ts`
+
+- [ ] Allocate the target time as: Scenes 1-2 90s, Scene 3 45s, Scenes 4-7 195s, Scenes 8-12 180s, Scene 13 120s, Scene 14 75s, and 75s navigation buffer.
+- [ ] Keep one must-say paragraph per scene. Beat notes after the first should contain only the sentence needed for the visual change.
+- [ ] Compress Scene 5 to definitions; move the applied lifecycle explanation to Scene 9.
+- [ ] Give Scene 13 two minutes and include 27 pass, 8 invalid, 1 fail, author audit, changing snapshots, and non-benchmark wording.
+- [ ] Name the five thesis contributions across Scenes 1, 4, 5, 7, and 13 without reading a five-item list.
+- [ ] Keep stateful MCP session reuse and the operation/repair/instruction-layer distinction as optional notes or Q&A, not main-path additions.
+- [ ] Update the Markdown speech so its must-say version matches the typed catalog.
+
+## Task 3: Correct known factual presentation defects
+
+**Files:**
+- Modify: `web/apps/console/src/presentation/authoring/authoring-recording.ts`
+- Modify: affected authoring tests
+- Modify: `web/apps/console/src/presentation/GuidedProductMoment.tsx`
+- Modify: affected guided-moment tests
+- Modify: `docs/runbooks/defense-presentation.md`
+- Modify: `docs/runbooks/defense-qna.md`
+
+- [ ] Replace stale `workflow.draft_workspaces.*` labels with the actual `workflow.drafts.*` namespace, or label composite CLI actions without pretending they map to one JSON-RPC method.
+- [ ] Preserve the factual configured source ID `local.lda_docs`.
+- [ ] Remove unconditional same-run wording from any revision-requested presentation state.
+- [ ] State that the decision is a typed interrupt/resume contract, not a production approval gate.
+- [ ] Update replay fallback answers so they distinguish recorded product evidence from rehearsed live evidence.
+- [ ] Replace stale future-work answers that list already-built presentation UI as the next product priority.
+
+## Task 4: Verify and document
+
+- [ ] Run focused storyboard, presenter-note, authoring, guided-moment, and Q&A tests.
+- [ ] Run `pnpm --dir web typecheck` and `pnpm --dir web build`.
+- [ ] Run `uv run pytest tests/docs -q`.
+- [ ] Review the 14-scene route matrix against the final note catalog.
+- [ ] Update `docs/current_roadmap.md`, archive this plan, and commit the slice.
+
+**Completion gate:** A presenter can read only `mustSay` fields and deliver the argument in under 13 minutes without unsupported claims.

docs/superpowers/plans/2026-07-13-read-only-presenter-route.md

@@ -0,0 +1,75 @@
+# Read-only presenter route implementation plan
+
+> **Dependency:** Execute after the story reweighting and Scenes 3-6 choreography plans.
+
+**Goal:** Add a calm, readable `/presenter` route containing the current speech, evidence, warnings, fallbacks, and Q&A without controlling or synchronizing `/present`.
+
+**Architecture:** `/presenter` reads the typed presenter-note catalog and existing storyboard/Q&A definitions. It owns no presentation state, RPC calls, replay state, BroadcastChannel, or remote-control behavior. Hash navigation selects a note inside `/presenter`; links may open the matching `/present` route in another tab.
+
+## Constraints
+
+- Read-only first. No cross-window or cross-machine synchronization.
+- Do not duplicate speech or Q&A strings in React components.
+- Remove presenter-only comments and dead markup from audience components.
+- Optimize for a tired presenter on a 1080p laptop: large type, short lines, stable regions, minimal chrome.
+- Preserve `/`, `/console`, and `/present` behavior.
+
+## Task 1: Add route and presenter navigation model
+
+**Files:**
+- Create: `web/apps/console/src/presentation/presenter/presenter-navigation.ts`
+- Create: associated tests
+- Create: `web/apps/console/src/presentation/presenter/PresenterRoute.tsx`
+- Modify: `web/apps/console/src/app/AppRoutes.tsx`
+- Modify: route tests
+
+- [ ] Add `/presenter` without redirecting existing routes.
+- [ ] Support `#scene/<scene>/<beat>` and `#discuss/<branch>` inside the presenter route using the existing route vocabulary.
+- [ ] Invalid hashes fail closed to the first presenter note.
+- [ ] Expose previous, current, and next note metadata without mutating `/present`.
+- [ ] Provide an “Open audience slide” link targeting the corresponding `/present#scene/...` route.
+
+## Task 2: Build the reading layout
+
+**Files:**
+- Create: `PresenterShell.tsx`, `PresenterNote.tsx`, `PresenterSidebar.tsx`, and `presenter.css`
+- Create component tests
+
+- [ ] Use a restrained two-column layout: compact scene index and a 60-72 character reading column.
+- [ ] Show scene/beat, elapsed target, current must-say text, optional detail, claim warning, fallback, evidence pointers, and linked Q&A.
+- [ ] Place the next beat preview below the current note, not beside it.
+- [ ] Collapse optional detail, evidence, and Q&A by default using accessible disclosure controls.
+- [ ] Typeset must-say text at 20-24px with at least 1.5 line height.
+- [ ] Use distinct but quiet treatments for `Say`, `Optional`, `Warning`, `Fallback`, and `Evidence`; avoid dashboard cards around every paragraph.
+- [ ] Add a print stylesheet that produces a readable speech outline.
+
+## Task 3: Move presenter-only discussion content out of the audience panel
+
+**Files:**
+- Modify: `web/apps/console/src/presentation/DiscussionPanel.tsx`
+- Modify: `web/apps/console/src/presentation/DiscussionPanel.test.tsx`
+- Modify: presenter Q&A components and tests
+
+- [ ] Delete the commented `speakerHint` block from `DiscussionPanel.tsx`.
+- [ ] Render `speakerHint` only in `/presenter` as presenter guidance.
+- [ ] Keep the audience discussion panel limited to question, answer, context, and evidence.
+- [ ] Verify every prioritized Q&A branch has a short answer and evidence pointer; show missing expanded answers as absent, not placeholders.
+
+## Task 4: Add static timing and rehearsal affordances
+
+- [ ] Show target time per note and cumulative target time.
+- [ ] Add a local-only manual “mark covered” checkbox state if it can remain component-local; do not persist or synchronize it in this slice.
+- [ ] Add keyboard navigation within `/presenter` only, with a visible help summary.
+- [ ] Do not add an automatic timer until presenter behavior is rehearsed.
+
+## Task 5: Verification and documentation
+
+- [ ] Test route isolation, hash parsing, note completeness, Q&A rendering, keyboard navigation, and audience links.
+- [ ] Run React Doctor after focused tests.
+- [ ] Run full console tests, typecheck, and build.
+- [ ] Capture `/presenter` at `1920x1080`, `1280x720`, and `1024x768`.
+- [ ] Confirm no audience-only RPC or replay effects run on `/presenter`.
+- [ ] Update `web/README.md`, `docs/runbooks/defense-presentation.md`, and `docs/current_roadmap.md`.
+- [ ] Archive this plan and commit.
+
+**Completion gate:** `/presenter` is usable as a standalone rehearsal and defense aid, while `/present` remains unchanged and audience-clean.

docs/superpowers/plans/2026-07-13-scenes-3-6-kernel-choreography.md

@@ -0,0 +1,135 @@
+# Interactive graphs and Scenes 3-6 choreography implementation plan
+
+> **Dependency:** Execute after `2026-07-13-defense-story-reweighting.md`.
+
+**Goal:** Give Scenes 3-5 restrained beat-to-beat motion, rebuild Scene 6 as a readable interactive architecture explorer, and improve the long prepared-run graph and its node inspector without adding unsupported evidence.
+
+**Architecture:** Reuse the editorial canvas, Motion dependency, and React Flow figure system. Scene 6 keeps semantic zoom, but each subsystem uses the topology that explains it: layered overview, fan-in client surface, branched core loop, provider grouping, or NodeUse sequence. The prepared-run graph remains visible when its node inspector opens. Do not force every relationship into a horizontal chain.
+
+## Constraints
+
+- Keep one editorial light theme and remove non-demo blue dominance.
+- Preserve simultaneous visibility for comparisons that require it.
+- Use existing CSS tokens and icons.
+- Respect `prefers-reduced-motion` and the presentation motion-disabled state.
+- Do not add hand-positioned connectors or a second graph renderer.
+- Use React Flow pan, zoom, fit-view, and layout inputs rather than CSS scaling around the graph.
+- Use icons and conventional state/flow shapes where they improve scanning; do not render every node as the same rounded rectangle.
+- Keep graph labels at least 18px at `1280x720`; prefer 20-22px for active nodes.
+- Keep the current scene IDs and deep-link behavior unless a migration updates every live reference and test.
+
+## Task 1: Pin visual contracts before restyling
+
+**Files:**
+- Modify tests for `PositioningScene`, `BoundaryScene`, `LifecycleScene`, and `ArchitectureScene`
+- Modify route tests for Scenes 3-6
+
+- [ ] Assert one primary visual region per beat through `data-visual-role="primary"`.
+- [ ] Assert reduced-motion behavior and stable accessible headings.
+- [ ] Assert Scene 6 exposes public surface, kernel loop, state/trace/routing, and provider boundary concepts across its four beats.
+- [ ] Assert architecture figures declare a topology appropriate to their subject rather than four repeated linear flows.
+- [ ] Assert the prepared-run graph preserves ten displayed action/boundary/outcome nodes, readable labels, pan/zoom, and a factual node inspector.
+- [ ] Capture baseline screenshots at `1280x720` and `1024x768` before implementation.
+
+## Task 2: Add restrained motion to Scene 3 positioning
+
+**Files:**
+- Modify: positioning scene component in `SceneBody.tsx` or extract a focused module
+- Modify: `presentation.css`
+- Modify: focused tests
+
+- [ ] Keep the existing information architecture and add one shared layout transition between the two beats.
+- [ ] On `landscape`, keep the related-system map as the complete comparison.
+- [ ] On `lda-position`, enlarge the typed-substrate position and shift the surrounding systems enough to make the focus obvious without hiding the comparison axis.
+- [ ] Use position and scale before opacity; one clear transform is enough.
+- [ ] Keep titles, category labels, and evidence readable at both target viewports.
+
+## Task 3: Add restrained motion to Scene 4 planner/runtime ownership
+
+- [ ] Preserve the current three-pane comparison.
+- [ ] On `planner`, enlarge the planner pane while retaining runtime destination context.
+- [ ] On `runtime`, let the runtime pane grow into the released space.
+- [ ] On `boundary`, restore both sides and enlarge the typed CLI/JSON-RPC seam.
+- [ ] Animate position and width between states; do not change color theme between beats.
+- [ ] Keep the spoken claim exact: planner proposes; runtime owns validation, state, execution, trace, and explicit resume.
+
+## Task 4: Add restrained motion to Scene 5 lifecycle vocabulary
+
+- [ ] Preserve the four-record lifecycle rail and its order.
+- [ ] For each beat, grow the active record into the available space while the other records compress but remain readable.
+- [ ] Keep arrows and order visible so the audience does not mistake the records for independent cards.
+- [ ] Show raw-plan-to-artifact as optional visual evidence without implying Draft is mandatory.
+- [ ] Avoid replaying the prepared example; Scene 9 owns applied evidence.
+
+## Task 5: Rebuild Scene 6 as an interactive semantic zoom
+
+**Files:**
+- Modify: `web/apps/console/src/presentation/scenes/ArchitectureScene.tsx`
+- Modify: `web/apps/console/src/presentation/figures/architecture-catalog.ts`
+- Modify: `web/apps/console/src/presentation/figures/model.ts`
+- Modify: `web/apps/console/src/presentation/figures/layout.ts`
+- Modify: `web/apps/console/src/presentation/figures/InteractiveFigure.tsx` only if required by an existing figure contract
+- Modify: associated tests and CSS
+
+- [ ] Base the root figure on the thesis Architecture Spine, not an invented package map: workflow owner and external agent enter through CLI/JSON-RPC, `WorkflowServer` composes the API, records, inventory, and `wf_core`, then status/output/trace return through the public surface.
+- [ ] Keep providers as one compact input into capability inventory at the root. Provider-family detail is optional drill-down, not one quarter of the main architecture story.
+- [ ] Keep click-to-focus and breadcrumb navigation. A node with `childFigureId` zooms into its subsystem; a leaf node opens evidence/details without replacing the whole figure.
+- [ ] Give the client surface a fan-in topology, with human/external agent clients and the web console converging on CLI or JSON-RPC and then WorkflowApi.
+- [ ] Give the WorkflowApi zoom a lifecycle-operation surface: capabilities, drafts, artifacts, deployments, and runs surrounding the API boundary. Use compact HTML operation receipts or method groups inside graph nodes when they communicate more than another label box.
+- [ ] Add a core-runtime child figure based on the thesis flowchart at `system-design-implementation.md:626`: select frame, branch by step kind, trace and route loop, interrupt/resume branch, and terminal output.
+- [ ] Represent node, condition, foreach, join, subgraph, interrupt, and end with icons or conventional shapes. Explicitly exclude general fork/gather.
+- [ ] Make `NodeUse` inside the core loop clickable. Its child figure follows the thesis sequence diagram: Runtime, Binding Resolver, NodeDef Handler, State Reducers, and Trace Store. Use participant lanes, message arrows, and small factual state/result panels instead of six identical nodes.
+- [ ] Allow further click-through from important core nodes where useful: interrupt opens request/resume contract evidence; trace opens a representative trace frame; step dispatch opens the supported-step palette. Do not create drill-down merely because a node exists.
+- [ ] Group built-in, MCP, and Python providers around the provider-neutral capability boundary; do not connect source families as an arbitrary adjacency chain.
+- [ ] Use larger labels and summaries, and allow user pan/zoom instead of shrinking the full graph until it fits.
+- [ ] Qualify determinism in visible copy: core semantics are deterministic for fixed definitions and handler results.
+- [ ] Keep React Flow as the one interactive graph system. Extend its layout model with named topologies or rank/position hints instead of manually drawing edge coordinates.
+
+### Scene 6 figure hierarchy
+
+Implement and test this hierarchy before polishing individual nodes:
+
+```text
+Architecture spine
+├─ Front door and transport
+├─ Workflow API operations
+├─ WorkflowServer composition
+├─ wf_core execution loop
+│  ├─ Supported step kinds
+│  ├─ NodeUse sequence
+│  ├─ Typed interrupt contract
+│  └─ Trace frame evidence
+├─ Lifecycle records
+└─ Capability inventory
+   └─ Built-in / MCP / Python providers
+```
+
+The four scripted beats need not visit every child. The audience path should be root architecture, public/API boundary, `wf_core` loop, then NodeUse execution. The remaining children exist for interaction and Q&A.
+
+## Task 6: Improve the prepared-run graph and node inspector
+
+**Files:**
+- Modify: `web/apps/console/src/presentation/WorkflowGraphStage.tsx`
+- Modify: `web/apps/console/src/presentation/NodeSpotlight.tsx`
+- Modify: `web/apps/console/src/presentation/OperationBlock.tsx`
+- Modify: `web/apps/console/src/presentation/styles/demo-workflow.css`
+- Modify: associated tests
+
+- [ ] Re-layout the long run graph into a readable two-dimensional flow with the submitted and revision branches separated vertically. Do not shrink ten displayed nodes into one horizontal strip.
+- [ ] Keep pan, drag, and zoom enabled. Use fit-view as the initial state, not the only readable state.
+- [ ] Remove selected/current-node treatment from the static graph beat unless a real execution state supports it.
+- [ ] Replace the generic `NodeSpotlight` paragraph with a reusable node inspector showing node kind, capability or boundary, factual input/output or schema summary, outcomes, and code/evidence pointer.
+- [ ] Keep the run graph visible behind or beside its inspector so selection retains context.
+- [ ] Replace “View raw evidence ->” with a precise action label such as “Inspect protocol receipt”. Open the existing evidence inspector at the relevant event rather than a generic drawer.
+- [ ] Test the interrupt and issue-creation nodes as distinct inspector examples, plus the fallback for ordinary nodes.
+
+## Task 7: Visual verification
+
+- [ ] Run focused scene and figure tests, full presentation tests, typecheck, and build.
+- [ ] Capture every Scene 3-6 beat and the Scene 10 graph at both rehearsal viewports.
+- [ ] Capture architecture root, client surface, core runtime, NodeUse, provider detail, and the open run-node inspector.
+- [ ] Verify no page scroll, no clipped captions, no detached connectors, and no text below 18px at `1280x720`.
+- [ ] Run the Impeccable detector and review screenshots manually.
+- [ ] Update roadmap, archive this plan, and commit.
+
+**Completion gate:** Scenes 3-5 gain clear motion without redesign churn. Scene 6 remains interactive but every zoom level uses a readable, subject-appropriate diagram. The prepared-run graph is readable without fitting ten nodes into one thin row, and node selection reveals factual details rather than a generic paragraph.