fix: address presentation review findings

This commit is contained in:
lda
2026-07-13 07:12:45 +07:00 Verified
parent a16e0933e2
commit ab943deed5
25 changed files with 339 additions and 92 deletions
+14 -11
View File
@@ -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 1012 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 812, while Scenes 1012 own run, decision, resume, output, and
trace evidence.
3. **Completed: Live/replay truth and run activation:** the compact footer rail
across Scenes 812 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` |
+1 -1
View File
@@ -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