Files
lda-wf/docs/superpowers/specs/2026-07-12-scene-8-chat-entry-design.md
T

220 lines
8.2 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# Scene 8 Chat Entry Design
## Status
Approved design for the first slice of the Scene 814 defense recomposition.
## Goal
Turn Scene 8 into a convincing full-screen assistant entry surface: the
audience sees the presentation title, a familiar empty chat state, and a
composer containing the report-workflow request. Sending that request reveals
the first prepared authoring turn without starting the workflow run.
## Context
Scene 8 currently renders a prepared authoring transcript inside a custom stage
layout with a phase rail and a separate `Run prepared workflow` button. That
mixes two different stories:
- authoring begins as an external-agent conversation;
- workflow execution begins later in the Run From Deployment scene.
The revised scene must make that distinction visible. The chat entry is a
presentation interaction backed by the deterministic authoring recording. It is
not an LLM call and it is not the live workflow start operation.
## Design
### Scene Composition
Scene 8 retains the existing `StageCaption` title and caption. Below it, the
primary region becomes one full-height chat surface:
```text
Stage title and framing
|
assistant-style thread
welcome / turns / tools
|
composer + Send
```
The old five-step phase rail is removed from Scene 8. The lifecycle sequence is
shown by Scene 9, where the authoring canvas is the primary artifact and the
conversation becomes a secondary modal.
The standalone in-scene `Run prepared workflow` action is removed from Scene 8.
The later demo-chrome slice owns one compact footer rail across Scenes 8-12.
That separate footer may expose the prepared-run action, while chat Send remains
local and never starts a workflow.
### Chat Surface Boundary
Use the assistant-ui Thread/Composer template and shadcn-owned primitives for
the visual vocabulary: message spacing, composer shell, send affordance,
empty-state layout, focus treatment, and tool-group treatment.
Do not introduce an assistant-ui runtime in this slice. The presentation keeps
`AgentMessage`, `projectPreparedAuthoringThread`, and the existing deterministic
recording as the source of truth. The Scene 8 adapter owns only the local
entry-state transition and delegates the rendered turns to the existing
projection path.
This boundary is deliberate:
- it avoids a second chat state store;
- it avoids reintroducing the duplicate-message/runtime problem previously
found with an external assistant runtime;
- it keeps replay deterministic and inspectable;
- it leaves a future live AI SDK driver compatible with the same visual shell.
### Entry State
On the Scene 8 request beat, render:
- the Scene 8 title and caption;
- an assistant-style welcome heading or short framing line;
- an empty conversation viewport;
- a composer with the request text prefilled:
`We need to author a report workflow for the lda_report scenario. What sources and capabilities are available?`;
- an enabled Send button;
- no workflow operation, run ID, deployment ID, or live target action inside
the chat surface. The separate demo footer rail may show target and run state.
The prefilled text is editable. The scene does not require the presenter to
retype the request during the defense.
### Send Transition
When Send is activated with non-empty text:
1. prevent the native form submission;
2. record the local submitted request in the Scene 8 controller state;
3. replace the empty state with the first prepared authoring conversation turn;
4. reveal the first assistant response and the Discover tool group from the
canonical recording;
5. clear the composer or replace it with a read-only continuation state;
6. keep the current location at `#scene/agent-handoff/request`.
The send action must not call `workflow.runs.start`, `workflow.runs.resume`, or
any other workflow RPC. It is a scripted presentation entry event.
Scene 8 has no second handoff beat. Advancing with `ArrowRight` moves directly
to Scene 9's first lifecycle beat, where the full prepared authoring
conversation becomes visible through the existing phase projection.
If the composer is empty or contains only whitespace, Send is disabled and no
state transition occurs.
### Replay and Reload Behavior
The Scene 8 entry state is local presentation state. Reloading the request beat
returns to the empty composer. The canonical authoring recording remains the
source for all revealed turns.
Scene 8 chat must work with no workflow server and must not change live/replay
state. The later demo truth slice owns the separate footer badge and launch
control across the demo arc.
### Responsive Behavior
The surface must remain readable at the reviewed `16:9` and `4:3` canvases:
- the composer remains visible without scrolling at `1280x720`;
- the composer remains reachable at `1024x768`;
- the conversation viewport may scroll internally once the prepared turns are
taller than the available stage;
- long request text wraps inside the composer and never causes horizontal
overflow;
- the assistant-ui shell must not inherit the old dark-stage palette in Scene
8's editorial surface;
- reduced-motion users receive an immediate state transition or a short
opacity-only transition.
## Data Flow
```text
prefilled request
|
v
Scene8ChatEntry local reducer
|
+--> submitted request / entry state
|
+--> projectPreparedAuthoringThread("discover")
|
v
assistant-ui visual shell
```
The local state should be a small discriminated union, for example:
```ts
type Scene8EntryState =
| { readonly phase: "empty"; readonly draft: string }
| { readonly phase: "submitted"; readonly draft: string; readonly request: string };
```
The exact reducer location may follow the existing presentation module
conventions, but the state must not be added to the global presentation
reducer. Scene 8 entry state is not navigation state and does not need to be
encoded in the URL hash.
## Accessibility
- The composer is a labelled form control with an accessible name such as
`Message input`.
- Send is a real button and exposes disabled state when the draft is blank.
- Enter submits the request; Shift+Enter inserts a newline if the chosen
assistant-ui composer supports multiline input.
- The conversation is exposed as a log with a useful accessible label.
- Focus moves to the first revealed assistant content after send without
stealing focus from the composer while the user is editing.
- Keyboard scene navigation remains owned by the existing presentation route;
text input events must not advance the scene.
## Failure and Boundary States
- Blank draft: Send disabled; no message is revealed.
- Whitespace-only draft: treated as blank.
- Send while already submitted: disabled or ignored; it must not duplicate the
prepared conversation.
- Missing recording data: preserve the existing bounded presentation fallback
and render an explicit unavailable state rather than inventing a live result.
## Testing Contract
Add or update tests for:
1. request beat renders the title, empty conversation state, prefilled composer,
and enabled Send button;
2. blank and whitespace-only drafts keep Send disabled;
3. sending reveals the prepared request/assistant/Discover content and does not
call workflow RPC operations;
4. sending twice does not duplicate the first conversation;
5. Scene 8 no longer renders the standalone `Run prepared workflow` button or
the old phase rail;
6. 1280x720 and 1024x768 browser smoke captures show the composer without
clipping or horizontal overflow;
7. reduced-motion mode does not hide the submitted conversation.
## Out Of Scope
- Real LLM or AI SDK execution;
- workflow run start or resume;
- Scene 9 persistent prepared-agent assistant pane;
- truth-badge scoping;
- Scene 11 beat compression;
- changes to the overall story order;
- live authoring RPC calls;
- a persistent chat transcript across reloads.
## Acceptance Criteria
The slice is complete when the presenter can open
`#scene/agent-handoff/request`, see a credible full-screen chat entry, press
Send, see the first prepared authoring turn, and continue directly into Scene 9
without a standalone run button or a second chat state runtime. The behavior is
covered by focused tests and 16:9/4:3 browser smoke.