143 lines
4.7 KiB
Markdown
143 lines
4.7 KiB
Markdown
# 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.
|
|
|