Presentation Live/Replay Activation Design

Status: Implemented

Goal

Make the prepared workflow demo's live/replay boundary explicit and usable. A presenter must be able to see the live-run action, start the real workflow through the existing browser-to-console-to-RPC path, and fall back to the 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 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 9–11 currently hide that chat, so a prepared run can be implemented without a visible way to start it. Direct 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.

Design

Launch surface

Expose one compact prepared-run control in PresentationFooter throughout 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:

Target/timeline state	Visible action
Checking	`Checking live service` and a retry action when the check settles
Healthy, not started	`Run prepared workflow`
Live run active	Current operation/`Running live workflow`; duplicate start disabled
Health failed	`Play replay walkthrough` plus the failure reason
Replay active	`Replay walkthrough active`

Only an explicit launch action changes the timeline from ready to running. A direct deep link remains replay-backed when it has no active run context.

Target status and retry

Reuse resolvePresentationTarget() and usePresentationTargetStatus(). Add a retry mechanism at the presentation boundary rather than duplicating target configuration or connection logic. Retrying must re-run workflow.health against the same resolved target and update the visible status without a full page reload.

The two local servers remain separate and documented:

browser :5173 -> console server :8787 -> wf-rpc-server :8765/rpc

The browser never calls wf-rpc-server directly; all operation evidence still comes from the existing /api/rpc proxy.

Live execution

The launch action calls the existing DemoTimelineController.start("live"). The existing live executor remains the source of truth for:

deployment inspection;
run start and typed interrupt payload;
submitted or revision-requested resume;
final trace read.

After the first live operation succeeds, the timeline must not be replaced by canonical replay data. A live failure is shown as a failed live event with its operation and error; it may offer an explicit Play replay walkthrough action, but fallback must not happen silently.

Scope of truth indicators

The live/replay status and live launch control belong to the prepared demo surface. Non-demo narrative, architecture, evaluation, conclusion, and discussion views should not gain a persistent live-service badge or run action.

Acceptance Criteria

With wf-rpc-server and the web server running, the compact footer rail on Scenes 7-11 exposes Run prepared workflow and starts a live timeline.
A live run records deployment inspection, run start, interrupt, resume, and trace evidence using the existing callOperation path.
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.
A direct Scene 9–11 hash without an active run still shows the reviewed replay, not a fabricated live state.
When health fails, the presenter sees the reason and an explicit replay action; no live operation is silently represented as replay evidence.
Starting the live server after the presentation is already open can be recovered with retry, without reloading the page or reconnecting manually.
The launch control cannot issue duplicate starts while an operation is in flight or a live run is already active.
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.

Verification

Unit and component tests must cover target retry/status transitions, launch visibility, duplicate-start protection, explicit replay fallback, and live versus replay operation calls. A browser smoke run must verify:

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

The final verification must include the existing scoped console tests, typecheck, build, and git diff --check. The unrelated user edit in web/apps/console/src/presentation/authoring/Scene8ChatEntry.tsx must remain unstaged.

5.1 KiB Raw Blame History Unescape Escape