docs: reconcile consolidated defense story
This commit is contained in:
+29
-24
@@ -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
|
||||
conversation, and Scene 9 as a 5-phase lifecycle with route-level coverage
|
||||
that never calls workflow authoring RPC operations during Scene 9
|
||||
authoring recording, Scene 7 as an authentic single-beat full-screen
|
||||
conversation, and Scene 8 as a 6-beat lifecycle with route-level coverage
|
||||
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
|
||||
dominant artifact, made the Scene 10 graph easier to present, and densified
|
||||
and the lifecycle-to-authoring narrative, gave Scenes 7 and 8 a stronger
|
||||
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).
|
||||
[`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,
|
||||
|
||||
@@ -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
|
||||
local replay behavior; start the live path from the Scene 10 run operation.
|
||||
if the loopback health probe succeeds. Scene 7's request and Send action remain
|
||||
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 |
|
||||
| 5:30-8:30 | Prepared demonstration | Request, deployment, start, interrupt, resume, output, trace |
|
||||
| 8:30-10:30 | Evaluation | 36 audited trials as bounded engineering evidence |
|
||||
| 10:30-11:45 | Limits and conclusion | Security, scheduling, evaluation, and agent-layer boundaries |
|
||||
| 11:45-13:00 | Transition buffer | Navigation, interaction, and demo delay |
|
||||
| 13:00-25:00 | Questions | Use prepared Q&A branches when available |
|
||||
| 2:15-4:36 | Architecture and lifecycle | Planner/runtime boundary, lifecycle, and architecture |
|
||||
| 4:36-7:45 | Prepared demonstration | Request, authoring, deployment, start, interrupt, resume, output, trace |
|
||||
| 7:45-9:45 | Evaluation | 36 audited trials as bounded engineering evidence |
|
||||
| 9:45-11:00 | Limits and conclusion | Security, scheduling, evaluation, and agent-layer boundaries |
|
||||
| 11:00-12:15 | Transition buffer | Navigation, interaction, and demo delay |
|
||||
| 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
|
||||
|
||||
@@ -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 8-12: prepared demonstration | 3:00 |
|
||||
| Scene 13: evaluation | 2:00 |
|
||||
| Scene 14: limits and conclusion | 1:15 |
|
||||
| Must-say speech | 11:45 |
|
||||
| Scenes 3-6: positioning, model, and architecture | 3:06 |
|
||||
| Scenes 7-11: prepared demonstration | 3:09 |
|
||||
| Scene 12: evaluation | 2:00 |
|
||||
| Scene 13: limits and conclusion | 1:15 |
|
||||
| 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>
|
||||
**Time:** 3:55-4:50
|
||||
**Route:** `architecture/overview`, `architecture/client`, `architecture/api`, then `architecture/runtime`<br>
|
||||
**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
|
||||
|
||||
**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
|
||||
### Scene 7: 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
|
||||
**Time:** 5:50-6:35
|
||||
**Evidence:** Implementation extension
|
||||
**Route:** all six `prepared-lifecycle/*` beats
|
||||
**Time:** 4:56-5:50
|
||||
**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.
|
||||
|
||||
@@ -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 13 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 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 12 findings | Six findings use a readable 3x2 layout with icons, campaign size, outcome counts, and the bounded-evidence statement visible together. |
|
||||
| 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
|
||||
|
||||
@@ -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/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 | 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. |
|
||||
| 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. |
|
||||
| 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 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 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 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
|
||||
|
||||
@@ -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/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/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/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/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` | 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` | 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` | 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` |
|
||||
|
||||
@@ -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.
|
||||
- Visible proof: Client, API, runtime, and NodeUse 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.
|
||||
- Audience takeaway: The same public surface reaches API, runtime/providers, stores, and the execution kernel.
|
||||
- Visible proof: Client, API, and runtime focus beats provide a semantic zoom with package and operation evidence.
|
||||
- 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
|
||||
- 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
|
||||
### Scene 7 — 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
|
||||
- Audience takeaway: The request is translated into Discover, Draft, Validate, Artifact, and Deployment stages.
|
||||
- Visible proof: The phase rail, staged messages, and changing factual evidence advance across all five beats.
|
||||
- Missing or confusing: Deployment records a local run request but does not execute; that boundary needs an explicit spoken pause.
|
||||
### Scene 8 — Prepared Workflow Lifecycle
|
||||
- Audience takeaway: The request becomes six concise authoring stages: Discover, Draft, Diagnose, Repair, Artifact, and Deployment.
|
||||
- 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 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 8 -> 9 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 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 13 -> 14 works: evaluation limits become the contribution and future-work close.
|
||||
- Scene 6 -> 7 works: architecture hands off to a bounded prepared request surface.
|
||||
- Scene 7 -> 8 works and is not a duplicate: request/discovery becomes staged lifecycle evidence.
|
||||
- Scene 8 -> 9 is the critical boundary: Deployment prepares; Scene 9 alone starts execution. Keep the explicit no-run wording.
|
||||
- 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 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,
|
||||
architecture, authoring, then demo proof, evaluation, and limits. No duplicated
|
||||
demo beat was found. Scene 8 introduces the request, Scene 9 owns authoring and
|
||||
deployment, Scene 10 owns run activation, Scene 11 owns the decision, and Scene
|
||||
12 owns resume/output/trace. The Q&A branch belongs after Scene 14's Questions
|
||||
The 13-scene order is coherent: motivation, positioning, boundary, vocabulary,
|
||||
architecture, request, authoring, then demo proof, evaluation, and limits. No duplicated
|
||||
demo beat was found. Scene 7 introduces the request, Scene 8 owns authoring and
|
||||
deployment, Scene 9 owns run activation, Scene 10 owns the decision, and Scene
|
||||
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`.
|
||||
|
||||
@@ -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
|
||||
turn. Repeat from Artifact to Deployment. On Deployment, Send must show only
|
||||
Edit and Send in Draft, then verify Diagnose and Repair contain that exact edited
|
||||
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
|
||||
Scene 9 to claim a run has started.
|
||||
9–11 own the subsequent run activation and live execution path; do not use
|
||||
Scene 8 to claim a run has started.
|
||||
|
||||
@@ -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.
|
||||
|
||||
|
||||
@@ -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;
|
||||
|
||||
@@ -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 9: `prepared-lifecycle`
|
||||
- Scene 10: `run-from-deployment`
|
||||
- Scene 11: `typed-human-boundary`
|
||||
- Scene 12: `resume-output-evidence`
|
||||
- Scene 7: `agent-handoff`
|
||||
- Scene 8: `prepared-lifecycle`
|
||||
- Scene 9: `run-from-deployment`
|
||||
- Scene 10: `typed-human-boundary`
|
||||
- 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;
|
||||
|
||||
@@ -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
|
||||
launch panel. Scene 10 remains the semantic execution start even when the
|
||||
Scenes 7-11. It is demo chrome, not a reintroduced chat rail or a scene-owned
|
||||
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 10 direct hash with server unavailable -> explicit replay
|
||||
Scene 9 operation -> live start -> interrupt -> approval -> resume -> trace
|
||||
Scene 9 direct hash with server unavailable -> explicit replay
|
||||
server started after page load -> retry -> live-ready action
|
||||
```
|
||||
|
||||
|
||||
Reference in New Issue
Block a user