150 lines
6.5 KiB
Markdown
150 lines
6.5 KiB
Markdown
# Presentation Demo Chrome Ownership
|
||
|
||
## Status
|
||
|
||
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 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
|
||
stale labels, layout shifts, and visible flicker when the presenter backtracks.
|
||
|
||
The input file browser has a separate honesty problem: it displays `selected /
|
||
read`, but the rows are not interactive and the recording only contains input
|
||
paths, not file contents or a read operation.
|
||
|
||
## Goals
|
||
|
||
1. Show live-target truth only where the prepared workflow demo is active.
|
||
2. Move prepared-run and retry actions into the persistent presentation footer.
|
||
3. Make footer content derive from the current scene and beat, so backtracking
|
||
cannot retain a previous beat's status or copy.
|
||
4. Separate target health from demo playback mode.
|
||
5. Keep the footer slot geometrically stable while target health is checking or
|
||
the run changes phase.
|
||
6. Make the prepared-run control available throughout the demo arc without
|
||
repeating large buttons inside individual scenes.
|
||
7. Replace unsupported file claims with factual input-manifest language.
|
||
|
||
## Non-goals
|
||
|
||
- Do not implement file selection, file reading, or file-content preview in this
|
||
slice. Those require content-backed fixtures or a source-read operation.
|
||
- Do not change the workflow graph, trace facts, approval form, or live RPC
|
||
protocol.
|
||
- Do not make the presentation footer a second application navigation system.
|
||
|
||
## Demo scope
|
||
|
||
The demo control rail is visible only for the prepared workflow arc:
|
||
|
||
- Scene 7: `agent-handoff`
|
||
- Scene 8: `prepared-lifecycle`
|
||
- Scene 9: `run-from-deployment`
|
||
- Scene 10: `typed-human-boundary`
|
||
- Scene 11: `resume-output-evidence`
|
||
|
||
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
|
||
badge and demo actions.
|
||
|
||
## State model
|
||
|
||
The presentation uses two independent concepts:
|
||
|
||
### Target health
|
||
|
||
`PresentationTargetHealth` describes the external service:
|
||
|
||
- `checking`: the configured target is being probed
|
||
- `ready`: the target responded successfully and no run is active
|
||
- `active`: a live run is in progress
|
||
- `failed`: the target is unavailable and replay is the fallback
|
||
- `replay`: no live target is configured
|
||
|
||
When the target is healthy, the status remains `ready` even if the current
|
||
timeline is showing a reviewed replay. `Replay evidence` is not a substitute
|
||
for `Live target ready`; playback mode is separate state.
|
||
|
||
### Playback mode
|
||
|
||
The demo timeline continues to own whether the current walkthrough is `live` or
|
||
`replay`. This value controls action labels and execution behavior, not the
|
||
target-health badge.
|
||
|
||
## Footer composition
|
||
|
||
`PresentationFooter` owns one stable demo slot between scene progress and the
|
||
evidence receipt. The slot is reserved for every Scene 7–11 location and is
|
||
empty elsewhere.
|
||
|
||
For non-demo scenes, the slot is absent and no target-health copy is rendered.
|
||
For the demo arc, the slot is always present with a stable minimum width and
|
||
height. It shows exactly one of these states:
|
||
|
||
- Before execution: a compact primary action, `Run prepared workflow` when the
|
||
live target is healthy or `Play replay walkthrough` when it is unavailable.
|
||
- While checking: a compact `Checking live service` state with the same
|
||
footprint.
|
||
- While running: a non-interactive `Running workflow...` information label,
|
||
not a disabled button.
|
||
- 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`.
|
||
- After Submit or Deny/Revision is clicked, remove the paused label immediately;
|
||
the rail may show a short `Resuming workflow...` state while the operation is
|
||
in flight before returning to the next factual state.
|
||
- When retry is meaningful: a compact secondary `Retry live service` action may
|
||
sit beside the primary action without changing the slot's size.
|
||
|
||
The large `DemoRunLaunchControl` section is removed from scene content layouts.
|
||
Its behavior is preserved through this footer rail. There is only one actual
|
||
prepared-run action; chat remains explanatory and does not gain a duplicate
|
||
run button.
|
||
|
||
## Input manifest language
|
||
|
||
Until source content is available, each input row says `included in prepared
|
||
run`. The row is not a button and does not claim that the presenter can open or
|
||
read the file. The output destination remains a factual manifest field.
|
||
|
||
A later slice may introduce a `RunInputFilePreview` backed by bundled fixture
|
||
content or a real source-read operation. That slice must add an actual click
|
||
target, preview content, and tests for the read path rather than relabeling the
|
||
current static rows.
|
||
|
||
## Verification contract
|
||
|
||
The implementation must test:
|
||
|
||
- title and non-demo scenes render no target badge or demo controls;
|
||
- 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 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 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;
|
||
- input rows use `included in prepared run` and expose no unsupported button or
|
||
preview affordance.
|
||
|
||
## Deferred follow-up
|
||
|
||
Build a real input-file preview surface with content-backed fixtures or a
|
||
source-read RPC. Keep it separate from this chrome ownership slice so target
|
||
truth and file-content evidence do not become another mixed state machine.
|