fix: address presentation review findings
This commit is contained in:
+14
-11
@@ -204,8 +204,8 @@ Presentation visual audit, July 11:
|
||||
|
||||
## Completed: Presentation Recomposition And Authoring Story
|
||||
|
||||
Scenes 8 and 9 are now implemented as authentic external-agent request and
|
||||
factual prepared-authoring proof. Scene 8 is one local request-to-first-turn
|
||||
Scenes 8 and 9 now present an external-agent request through a scripted
|
||||
presentation surface and factual prepared-authoring proof. Scene 8 is one local request-to-first-turn
|
||||
beat; its obsolete `/handoff` route fails closed. Scene 9 keeps a persistent
|
||||
prepared assistant pane beside five factual phase visuals in an adaptive
|
||||
approximately 35/65 split. The obsolete receipt/trace modal and lower chat dock
|
||||
@@ -244,8 +244,9 @@ Recommended next visual slices:
|
||||
[`presentation evaluation and closing`](superpowers/specs/2026-07-10-presentation-evaluation-closing-design.md).
|
||||
Implementation:
|
||||
[`presentation evaluation and closing plan`](historical/superpowers/plans/2026-07-10-presentation-evaluation-closing.md).
|
||||
6. Completed: Presentation agent authoring story rebuilds Scenes 8 and 9 as
|
||||
authentic external-agent handoff and factual prepared-authoring proof.
|
||||
6. Completed: Presentation agent authoring story rebuilds Scenes 8 and 9 as a
|
||||
scripted surface representing an external-agent handoff and factual
|
||||
prepared-authoring proof.
|
||||
Implementation:
|
||||
[`presentation agent authoring story plan`](historical/superpowers/plans/2026-07-11-presentation-agent-authoring-story.md).
|
||||
7. Completed: Scene 1 now introduces the agent-shaped product goal through
|
||||
@@ -261,7 +262,7 @@ Recommended next visual slices:
|
||||
Implementation:
|
||||
[`defense presentation rehearsal`](historical/superpowers/plans/2026-07-12-defense-presentation-rehearsal.md).
|
||||
9. Completed: Scenes 7-9 now use one dominant factual artifact per beat on the
|
||||
Editorial Canvas: authoring/repair evidence, an authentic light agent chat,
|
||||
Editorial Canvas: authoring/repair evidence, a scripted light agent chat,
|
||||
and a light prepared lifecycle canvas with synchronized secondary chat.
|
||||
Implementation:
|
||||
[`Scenes 7-9 editorial focal proof`](historical/superpowers/plans/2026-07-12-scenes-7-9-editorial-focal-proof.md).
|
||||
@@ -287,12 +288,14 @@ separate activity after these surfaces are stable.
|
||||
turns, and Deployment Send records a truthful local run request without
|
||||
execution or RPC. Implementation:
|
||||
[`Scene 9 staged message box`](historical/superpowers/plans/2026-07-12-scene-9-staged-message-box.md).
|
||||
The boundary is explicit: Scenes 10–12 own run activation, approval,
|
||||
resume, output, and trace evidence.
|
||||
3. **Completed: Live/replay truth and run activation:** Scene 10 exposes the
|
||||
prepared-run action outside the hidden chat, retries the existing health
|
||||
probe, starts live execution explicitly, and keeps direct links and failed
|
||||
services on truthful replay evidence. Implementation:
|
||||
The boundary is explicit: the compact demo footer may start the prepared run
|
||||
from Scenes 8–12, while Scenes 10–12 own run, decision, resume, output, and
|
||||
trace evidence.
|
||||
3. **Completed: Live/replay truth and run activation:** the compact footer rail
|
||||
across Scenes 8–12 exposes the prepared-run action, retries the existing
|
||||
health probe, starts live execution explicitly, and keeps direct links and
|
||||
failed services on truthful replay evidence. Scene 10 remains the semantic
|
||||
start of execution evidence. Implementation:
|
||||
[`presentation live/replay activation`](historical/superpowers/plans/2026-07-12-presentation-live-replay-activation.md).
|
||||
4. **Completed: Scene 11 compression:** reduce the typed-human-boundary scene to two
|
||||
beats: interrupt context and approval decision. Cancellation remains a
|
||||
|
||||
@@ -20,7 +20,7 @@ can be shown after selecting replay with the runbook's session-storage switch.
|
||||
| `positioning/landscape` | Related systems solve different parts of the tool, script, workflow, and agent problem. | Related-systems landscape | Problem contracts | hidden | replay-only; Thesis Positioning and Related Systems | `positioning/landscape` |
|
||||
| `positioning/lda-position` | lda.chat occupies the typed, provider-neutral workflow substrate niche for external agents. | lda.chat position map | Related-systems landscape | hidden | replay-only; Thesis Positioning and Related Systems | `positioning/lda-position` |
|
||||
| `planner-runtime/planner` | An external planner proposes and revises workflow structure. | Planner side of boundary | Typed operations | hidden | replay-only; Thesis Architecture Overview | `planner-runtime/planner` |
|
||||
| `planner-runtime/runtime` | The runtime validates, executes, records, and resumes the proposal deterministically. | Runtime side of boundary | Lifecycle records | hidden | replay-only; Thesis Architecture Overview | `planner-runtime/runtime` |
|
||||
| `planner-runtime/runtime` | For fixed handler results, the core validates, executes, records, and resumes the proposal deterministically. | Runtime side of boundary | Lifecycle records | hidden | replay-only; Thesis Architecture Overview | `planner-runtime/runtime` |
|
||||
| `planner-runtime/boundary` | Typed CLI and JSON-RPC operations make the planner/runtime boundary explicit. | Boundary diagram | CLI and RPC surface | hidden | replay-only; Thesis Architecture Overview | `planner-runtime/boundary` |
|
||||
| `lifecycle/draft` | Draft is mutable iterative authoring state. | Lifecycle stage: Draft | State transition strip | hidden | replay-only; Thesis Workflow Lifecycle | `lifecycle/draft` |
|
||||
| `lifecycle/artifact` | Artifact is the immutable saved workflow definition. | Lifecycle stage: Artifact | State transition strip | hidden | replay-only; Thesis Workflow Lifecycle | `lifecycle/artifact` |
|
||||
|
||||
@@ -51,7 +51,7 @@ pnpm --filter @lda/console build
|
||||
3. 1280x720 uses a 1280x720 logical canvas
|
||||
4. Ratios outside 4:3 through 16:9 letterbox at the nearest supported ratio
|
||||
5. Warm Editorial Canvas unchanged across Scene 1 and Scene 6
|
||||
6. No scene rail, replay label, discussion button, or presenter controls
|
||||
6. Non-demo routes have no demo rail, replay label, discussion button, or presenter controls; Scenes 8-12 retain the approved compact demo footer rail
|
||||
7. Scene 6 root has one primary figure and no competing card grid
|
||||
8. Runtime & providers expands in place with breadcrumb
|
||||
9. Configured providers expands second level
|
||||
|
||||
@@ -26,9 +26,10 @@ when `wf-rpc-server` is running.
|
||||
|
||||
### Launch surface
|
||||
|
||||
Expose a compact prepared-run control on Scene 10's `operation` beat. It is a
|
||||
scene-owned control, not a reintroduced chat rail. It must remain visible while
|
||||
the target is checking, ready, failed, or the live run is active.
|
||||
Expose one compact prepared-run control in `PresentationFooter` throughout
|
||||
Scenes 8-12. It is demo chrome, not a reintroduced chat rail or a scene-owned
|
||||
launch panel. Scene 10 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:
|
||||
|
||||
@@ -83,8 +84,8 @@ discussion views should not gain a persistent live-service badge or run action.
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
1. With `wf-rpc-server` and the web server running, Scene 10's operation beat
|
||||
visibly exposes `Run prepared workflow` and starts a live timeline.
|
||||
1. With `wf-rpc-server` and the web server running, the compact footer rail on
|
||||
Scenes 8-12 exposes `Run prepared workflow` and starts a live timeline.
|
||||
2. A live run records deployment inspection, run start, interrupt, resume, and
|
||||
trace evidence using the existing `callOperation` path.
|
||||
3. The typed approval form remains the only way to provide the resume decision;
|
||||
@@ -97,8 +98,9 @@ discussion views should not gain a persistent live-service badge or run action.
|
||||
recovered with retry, without reloading the page or reconnecting manually.
|
||||
7. The launch control cannot issue duplicate starts while an operation is in
|
||||
flight or a live run is already active.
|
||||
8. Scene 8 and Scene 9 remain deterministic authoring replay and do not call
|
||||
workflow authoring RPC operations.
|
||||
8. Scene 8 chat Send and Scene 9 staged messages remain deterministic authoring
|
||||
replay and do not call workflow authoring RPC operations. Their separate
|
||||
footer control may start the prepared run.
|
||||
|
||||
## Verification
|
||||
|
||||
|
||||
@@ -44,8 +44,10 @@ 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 `Run prepared workflow` action is removed from Scene 8. The
|
||||
workflow-run action belongs to Slice 3 and will be exposed in Scene 10.
|
||||
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
|
||||
|
||||
@@ -77,7 +79,8 @@ On the Scene 8 request beat, render:
|
||||
- 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.
|
||||
- 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.
|
||||
@@ -110,8 +113,9 @@ 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 must work with no workflow server and must not change the live/replay
|
||||
target badge. The target badge remains scoped by the later demo truth slice.
|
||||
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
|
||||
|
||||
|
||||
Reference in New Issue
Block a user