docs: plan presentation lifecycle story expansion
This commit is contained in:
+16
-8
@@ -40,6 +40,7 @@ Design contracts:
|
||||
- [`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)
|
||||
|
||||
Implementation order:
|
||||
|
||||
@@ -152,9 +153,16 @@ Implementation order:
|
||||
Cancel is terminal in presentation mode and does not advance into submitted
|
||||
evidence. Implementation:
|
||||
[`Scene 10 factual run state`](historical/superpowers/plans/2026-07-09-scene-10-factual-run-state.md).
|
||||
21. Future: presenter companion, Scene 10 product graph, final scene visuals,
|
||||
evidence assets, and rehearsal timing.
|
||||
22. Add a static slide/appendix shell only after presentation mode is clear.
|
||||
21. Next: presentation lifecycle story expansion splits the current crowded run
|
||||
proof into prepared lifecycle, run start, typed human boundary, and
|
||||
resume/output/evidence scenes. Draft -> Artifact -> Deployment -> Run must
|
||||
be visible before the run inspector details. Design:
|
||||
[`presentation lifecycle story expansion`](superpowers/specs/2026-07-09-presentation-lifecycle-story-expansion-design.md).
|
||||
Plan:
|
||||
[`presentation lifecycle story expansion plan`](superpowers/plans/2026-07-09-presentation-lifecycle-story-expansion.md).
|
||||
22. Future: presenter companion, final scene visuals, evidence assets, and
|
||||
rehearsal timing.
|
||||
23. Add a static slide/appendix shell only after presentation mode is clear.
|
||||
Astro remains an option, not the default next surface.
|
||||
|
||||
Presentation wishlist / defense readiness:
|
||||
@@ -234,12 +242,12 @@ Presentation wishlist / defense readiness:
|
||||
[`Scene 10 guided product moment`](superpowers/specs/2026-07-09-scene-10-guided-product-moment-design.md).
|
||||
Implementation:
|
||||
[`Scene 10 guided product moment plan`](historical/superpowers/plans/2026-07-09-scene-10-guided-product-moment.md).
|
||||
- Active: presentation live/replay truth distinguishes reviewed replay evidence,
|
||||
live target readiness, live active run state, and replay fallback so the demo
|
||||
can look credible without implying fake live execution. Design:
|
||||
[`presentation live/replay truth`](superpowers/specs/2026-07-09-presentation-live-replay-truth-design.md).
|
||||
- Next: 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).
|
||||
Plan:
|
||||
[`presentation live/replay truth plan`](superpowers/plans/2026-07-09-presentation-live-replay-truth.md).
|
||||
[`presentation lifecycle story expansion plan`](superpowers/plans/2026-07-09-presentation-lifecycle-story-expansion.md).
|
||||
- Evidence assets and rehearsal timing: prepare fallback screenshots/recordings,
|
||||
expected run states, and a timed walkthrough checklist for a 15-minute defense.
|
||||
- Presenter companion feasibility: decide whether phone/laptop control is local
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
@@ -0,0 +1,142 @@
|
||||
# Presentation Lifecycle Story Expansion Design
|
||||
|
||||
## Purpose
|
||||
|
||||
The defense presentation currently proves run and interrupt behavior, but it
|
||||
does not give enough screen time to the rest of the thesis contribution. The
|
||||
result feels dense and narrow: too much run-state detail in one scene, but too
|
||||
little lifecycle context around draft, artifact, deployment, source bindings,
|
||||
and evidence ownership.
|
||||
|
||||
The next presentation slice should expand the demo climax into more scenes. It
|
||||
should first show the product lifecycle as durable substrate state, then zoom
|
||||
into run start, typed interrupt, resume, output, and trace.
|
||||
|
||||
## Problem
|
||||
|
||||
The current Scenes 9 and 10 try to cover too many jobs:
|
||||
|
||||
- agent handoff into a workflow operation
|
||||
- reusable workflow graph
|
||||
- prepared deployment
|
||||
- run input
|
||||
- interrupt payload
|
||||
- operator resume form
|
||||
- resume operation
|
||||
- output artifacts
|
||||
- trace frames
|
||||
- live/replay truth
|
||||
|
||||
This creates the wrong hierarchy. The run inspector becomes visually dominant
|
||||
before the viewer understands what larger lifecycle it belongs to. It also
|
||||
makes chat feel detached: the chat says "run prepared workflow", while the
|
||||
screen jumps straight into run evidence instead of showing what already exists
|
||||
as draft, artifact, deployment, and configured sources.
|
||||
|
||||
## Design Goal
|
||||
|
||||
Make the product story read as:
|
||||
|
||||
```text
|
||||
External agent or operator request
|
||||
-> draft-like authoring surface
|
||||
-> saved artifact
|
||||
-> deployment with source bindings
|
||||
-> run from deployment
|
||||
-> typed interrupt
|
||||
-> resume payload
|
||||
-> output and trace evidence
|
||||
```
|
||||
|
||||
The presentation may still use a prepared replay, but the viewer should see
|
||||
which parts are durable product state and which part is the active run moment.
|
||||
|
||||
## Scene Structure
|
||||
|
||||
Replace the current two-scene climax with four product scenes.
|
||||
|
||||
### Scene 9: Prepared Workflow Lifecycle
|
||||
|
||||
Purpose: show that the prepared report workflow is not just a chat transcript.
|
||||
|
||||
Beats:
|
||||
|
||||
- `draft`: show authoring/draft intent and focused operations.
|
||||
- `artifact`: show immutable artifact identity/version.
|
||||
- `deployment`: show source bindings and drift policy.
|
||||
- `ready-run`: show the deployment is ready to start a run.
|
||||
|
||||
Dominant visual: lifecycle rail with one large factual panel per beat.
|
||||
|
||||
### Scene 10: Run Starts From Deployment
|
||||
|
||||
Purpose: show the run begins from the deployment and receives workflow input.
|
||||
|
||||
Beats:
|
||||
|
||||
- `input`: selected documents and issue-board path.
|
||||
- `operation`: `workflow.runs.start` operation proof.
|
||||
- `graph`: reusable graph with run id and current node context.
|
||||
|
||||
Dominant visual: operation and graph. Chat may narrate, but should not own the
|
||||
screen.
|
||||
|
||||
### Scene 11: Typed Human Boundary
|
||||
|
||||
Purpose: show the interrupt as a typed product boundary.
|
||||
|
||||
Beats:
|
||||
|
||||
- `interrupt`: interrupt payload and resume contract.
|
||||
- `approval`: operator decision form with large report preview.
|
||||
- `cancel`: honest replay cancellation state.
|
||||
|
||||
Dominant visual: interrupt payload and operator decision. The output panel is
|
||||
not shown before resume.
|
||||
|
||||
### Scene 12: Resume, Output, Evidence
|
||||
|
||||
Purpose: show the same run resumes and leaves product evidence.
|
||||
|
||||
Beats:
|
||||
|
||||
- `resume`: `workflow.runs.resume` operation proof.
|
||||
- `output`: report and issue-board output.
|
||||
- `trace`: trace frames and protocol evidence.
|
||||
|
||||
Dominant visual: output/report/trace. Evidence receipt remains inspectable.
|
||||
|
||||
Existing evaluation and conclusion scenes move after these scenes.
|
||||
|
||||
## Data Rules
|
||||
|
||||
- Do not invent lifecycle facts. If draft data is not in the recording, label it
|
||||
as prepared authoring context and point to `examples/lda_report_workflow`.
|
||||
- Artifact and deployment facts should be derived from the recorded deployment
|
||||
inspect event where possible.
|
||||
- Run input, interrupt payload, resume payload, output, and trace should be
|
||||
derived from the canonical recording or live run state.
|
||||
- Replay cancellation remains an honest presentation branch. Do not show
|
||||
submitted resume evidence after cancel.
|
||||
- Live/replay truth badge remains visible but should not dominate the story.
|
||||
|
||||
## Interaction Rules
|
||||
|
||||
- Hash deep links must prime replay state for the scene beat being opened.
|
||||
- Content panes may scroll internally. The whole presentation viewport must not
|
||||
scroll.
|
||||
- Scrollbars may be visually hidden in presentation mode, but native wheel and
|
||||
trackpad scrolling must still work.
|
||||
- Chat is secondary. It can introduce a scene or run the prepared workflow, but
|
||||
it should not crowd graph/evidence scenes.
|
||||
|
||||
## Success Criteria
|
||||
|
||||
- The viewer can answer where draft, artifact, deployment, run, interrupt, and
|
||||
trace fit.
|
||||
- Scene 11 approval no longer wastes space on pre-resume output.
|
||||
- Scene 12 output and trace can scroll and remain readable at 1280x720.
|
||||
- The run story is still factual and replay-backed.
|
||||
- The route count may grow past 12 scenes; clarity wins over forcing everything
|
||||
into the old scene count.
|
||||
|
||||
Reference in New Issue
Block a user