lda.chat/lda-wf
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs: plan simpler defense speech and Scene 8 evidence

Browse Source
This commit is contained in:
lda
2026-07-13 20:58:10 +07:00 Verified
parent 4f399445d7
commit 29268ddcad
4 changed files with 705 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/current_roadmap.md
+14
View File
@@ -353,6 +353,20 @@ separate activity after these surfaces are stable.
Presentation wishlist / defense readiness:
### Next: Simpler Speech And Factual Scene 8 Evidence
1. Planned: simplify the timed presenter path through Scenes 1-8 to one spoken
idea per beat. Move terminology such as typed contracts, source resolution,
provider neutrality, and explicit resume boundaries into optional notes or
Q&A where it is easier to explain without rushing.
2. Planned: replace Scene 8's inaccurate missing-output diagnostic and sparse
visuals with compact product-result views based on reviewed `wf` output:
`missing_outcome_edge` at `nodes[analyze]`, an exact `set-route` repair, and
a valid follow-up result with no diagnostics.
Design:
[`defense speech and Scene 8 product evidence`](superpowers/specs/2026-07-13-defense-speech-and-scene-8-evidence-design.md).
- Completed: visual pass for Scenes 6, 7, and 10 fixed architecture figure
scale, authoring-loop clarity, interrupt/evidence emphasis, and presenter-note
treatment. Implementation:
docs/superpowers/plans/2026-07-13-defense-speech-simplification.md
+220
View File
@@ -0,0 +1,220 @@
# Defense Speech Simplification Implementation Plan
> **For agentic workers:** REQUIRED SUB-SKILL: Use superpowers:subagent-driven-development (recommended) or superpowers:executing-plans to implement this plan task-by-task. Steps use checkbox (`- [ ]`) syntax for tracking.
**Goal:** Replace the terminology-heavy timed narration for Scenes 1-8 with short spoken English that carries one idea per beat.
**Architecture:** Keep `presenter-notes.ts` as the typed source of truth and keep the readable runbook synchronized through its existing test. Only `mustSay` text and timing change; evidence pointers, warnings, fallbacks, and Q&A links remain available to the presenter.
**Tech Stack:** TypeScript, Vitest, Markdown runbooks, React presenter route.
## Global Constraints
- The audience-facing storyboard remains unchanged in this slice.
- Do not remove evidence warnings, replay disclosures, or Q&A links.
- Scenes 1-8 must use one mandatory spoken idea per beat and avoid lists of unexplained system nouns.
- Provider neutrality, typed contracts, source resolution, resume boundaries, and NodeUse remain optional-detail or Q&A material unless a beat visually demonstrates them.
- The timed Scenes 1-8 path must total 257 seconds or less.
- The complete must-say catalog must contain 500-700 words.
---
### Task 1: Pin The Simpler Speech And Timing Contract
**Files:**
- Modify: `web/apps/console/src/presentation/presenter/presenter-notes.test.ts`
- Test: `web/apps/console/src/presentation/presenter/presenter-notes.test.ts`
**Interfaces:**
- Consumes: `presenterNotes`, `presenterSceneNotes()`, `mainSpeechWordCount()`.
- Produces: regression constraints for the rewritten catalog.
- [ ] **Step 1: Replace the old timing and word-budget expectations**
Assert scene totals of `[30, 30, 35, 40, 36, 32, 12, 42, 35, 30, 50, 120, 75]`, a complete-deck target of `642` including the existing 75-second navigation buffer, and a `500-700` word budget. Add a loop over Scenes 1-8 that strips Markdown emphasis, splits on whitespace, and asserts no `mustSay` value exceeds 28 words.
```ts
const openingSceneIds = new Set([
"thesis",
"problem",
"positioning",
"planner-runtime",
"lifecycle",
"architecture",
"agent-handoff",
"prepared-lifecycle",
]);
for (const note of presenterNotes.filter((item) => openingSceneIds.has(item.sceneId))) {
const words = note.mustSay.replaceAll("**", "").trim().split(/\s+/);
expect(words.length, `${note.sceneId}/${note.beatId}`).toBeLessThanOrEqual(28);
}
```
- [ ] **Step 2: Replace the obsolete diagnostic assertions**
```ts
expect(presenterBeatNoteFor("prepared-lifecycle", "diagnose")?.mustSay)
.toMatch(/missing.*route/i);
expect(presenterBeatNoteFor("prepared-lifecycle", "repair")?.mustSay)
.toMatch(/adds.*route|route.*validation passes/i);
expect(presenterBeatNoteFor("prepared-lifecycle", "diagnose")?.mustSay)
.not.toMatch(/output projection/i);
```
- [ ] **Step 3: Run the focused test and verify RED**
Run:
```powershell
pnpm --dir web --filter @lda/console test -- src/presentation/presenter/presenter-notes.test.ts
```
Expected: failures for timing, word budget, maximum beat length, and the obsolete diagnostic text.
- [ ] **Step 4: Commit the failing contract**
```powershell
git add web/apps/console/src/presentation/presenter/presenter-notes.test.ts
git commit -m "test: define simpler defense speech contract"
```
### Task 2: Rewrite Scenes 1-8 Must-Say Notes
**Files:**
- Modify: `web/apps/console/src/presentation/presenter/presenter-notes.ts`
- Test: `web/apps/console/src/presentation/presenter/presenter-notes.test.ts`
**Interfaces:**
- Consumes: `beatNote()` and the existing note metadata.
- Produces: the exact presenter speech rendered by `/presenter`.
- [ ] **Step 1: Set the new target seconds**
Use these per-beat values:
```ts
// Scene 1: 15, 15
// Scene 2: 15, 15
// Scene 3: 18, 17
// Scene 4: 12, 16, 12
// Scene 5: 9, 9, 9, 9
// Scene 6: 6, 8, 9, 9
// Scene 7: 12
// Scene 8: 7, 7, 7, 7, 7, 7
```
- [ ] **Step 2: Replace the exact `mustSay` values for Scenes 1-8**
Use these sentences in storyboard order:
```text
The title describes the original goal: an AI agent for workspace automation. My contribution is the platform underneath that agent.
It lets agents and humans build workflows, run them, and inspect what happened.
Like the chat example, an agent can call tools and finish one task. But that conversation is not yet a reusable workflow.
Reusable automation needs a saved definition, validation, execution records, and a clear way to pause and continue.
Existing systems solve different parts of this problem: Python scripts, n8n, Zapier, LangGraph, and MCP.
My platform does not replace them. It provides a provider-neutral workflow layer that agents and humans can operate.
A human or AI planner decides what workflow to build.
The runtime validates the graph, executes it step by step, records state and traces, and pauses at declared boundaries.
Both sides communicate through the Workflow API. Today, clients reach it through the CLI or JSON-RPC without accessing runtime internals directly.
A workflow moves through four lifecycle stages. Draft means the workflow is still being built.
Artifact is a saved, immutable version.
Deployment connects that version to the sources it needs and checks whether it is ready.
Run is one recorded execution, including its status, output, and trace.
This is how those concepts are organized in the implementation.
Humans and agents use the same public workflow operations.
The Workflow API is the front door. It exposes lifecycle operations without exposing runtime internals.
Behind it, the workflow server brings together stored records, available capabilities, and the execution core.
This is a prepared example, not a live autonomous AI agent. It shows how an agent could use the platform to build and run a workflow.
First, the agent checks which sources and operations are available.
Then it builds an editable workflow draft.
Validation finds that the analyze step has no route for its ok outcome.
The agent adds that route, and validation passes.
The valid workflow is saved as an immutable artifact.
Finally, a deployment connects it to the three local sources it needs.
```
Preserve the existing warnings, fallbacks, evidence pointers, and Q&A branch IDs. Move the existing qualification about fixed definitions/provider variability into `optionalDetail` on `planner-runtime/runtime` if it is not already represented by `warning`.
- [ ] **Step 3: Run the focused test and verify only runbook synchronization remains RED**
Run the focused presenter-note test. Expected: catalog/timing/word constraints pass; synchronization fails because the readable runbook still contains the old speech.
- [ ] **Step 4: Commit the typed catalog rewrite**
```powershell
git add web/apps/console/src/presentation/presenter/presenter-notes.ts web/apps/console/src/presentation/presenter/presenter-notes.test.ts
git commit -m "docs: simplify opening defense speech"
```
### Task 3: Synchronize The Readable Speech Runbook
**Files:**
- Modify: `docs/runbooks/defense-speech-and-claim-audit.md`
- Test: `web/apps/console/src/presentation/presenter/presenter-notes.test.ts`
**Interfaces:**
- Consumes: exact `mustSay` strings from Task 2.
- Produces: a readable rehearsal document synchronized with `/presenter`.
- [ ] **Step 1: Update timing prose and table**
Change the must-say target from `11:00` to `9:27`, retain a `1:15` navigation buffer, and set the complete-deck target to `10:42`. Update the Scenes 1-8 segment times to match Task 2; leave Scenes 9-13 targets unchanged.
- [ ] **Step 2: Replace the Scene 1-8 `Say:` blocks verbatim**
Use the exact plain-text versions of Task 2's sentences. Keep claim qualifications below each block; do not require the presenter to speak them.
- [ ] **Step 3: Run verification**
```powershell
pnpm --dir web --filter @lda/console test -- src/presentation/presenter/presenter-notes.test.ts
pnpm --dir web --filter @lda/console typecheck
git diff --check
```
Expected: all presenter tests pass, typecheck is clean, and no whitespace errors are reported.
- [ ] **Step 4: Verify `/presenter` at desktop and mobile widths**
Open `/presenter#scene/planner-runtime/boundary` and `/presenter#scene/architecture/api` at `1280x720` and `390x844`. Confirm bold phrases remain readable, Previous/Next controls stay stable, and the simplified `mustSay` text does not overflow.
- [ ] **Step 5: Commit the synchronized runbook**
```powershell
git add docs/runbooks/defense-speech-and-claim-audit.md
git commit -m "docs: synchronize simplified defense runbook"
```
### Task 4: Close The Speech Slice
**Files:**
- Modify: `docs/current_roadmap.md`
- Move after completion: `docs/superpowers/plans/2026-07-13-defense-speech-simplification.md` to `docs/historical/superpowers/plans/2026-07-13-defense-speech-simplification.md`
**Interfaces:**
- Consumes: verified implementation from Tasks 1-3.
- Produces: accurate live roadmap status and historical implementation record.
- [ ] **Step 1: Mark only the speech item completed**
Leave the Scene 8 evidence item planned until its separate plan is implemented.
- [ ] **Step 2: Move this completed plan and verify links**
Update the roadmap link to the historical path, run `git diff --check`, and confirm no live document points to the old active-plan path.
- [ ] **Step 3: Commit docs closure**
```powershell
git add docs/current_roadmap.md docs/superpowers/plans/2026-07-13-defense-speech-simplification.md docs/historical/superpowers/plans/2026-07-13-defense-speech-simplification.md
git commit -m "docs: complete defense speech simplification"
```
docs/superpowers/plans/2026-07-13-scene-8-product-evidence.md
+329
View File
@@ -0,0 +1,329 @@
# Scene 8 Product Evidence Implementation Plan
> **For agentic workers:** REQUIRED SUB-SKILL: Use superpowers:subagent-driven-development (recommended) or superpowers:executing-plans to implement this plan task-by-task. Steps use checkbox (`- [ ]`) syntax for tracking.
**Goal:** Replace Scene 8's inaccurate missing-output story and sparse prepared visuals with compact product-result views derived from reviewed `wf` output.
**Architecture:** Store reviewed deterministic evidence in one source-owned TypeScript catalog, project it through the existing prepared-authoring boundary, and render one dominant result per lifecycle beat. Presentation navigation remains replay-only; no authoring RPC call occurs when the audience opens Scene 8.
**Tech Stack:** React 19, TypeScript, Vitest, Testing Library, Lucide icons, existing editorial presentation CSS.
## Global Constraints
- Use reviewed CLI evidence, not invented JSON and not runtime authoring calls.
- Diagnose must show `missing_outcome_edge`, `nodes[analyze]`, revision `3`, and the reviewed message.
- Repair must show `wf draft set-route lda_report_workflow --revision 3 --step analyze --outcome ok --to __end__`, then revision `4`, `status: valid`, and zero diagnostics.
- Do not display disposable probe workspace IDs.
- Do not claim automatic repair or live authoring.
- Preserve the left prepared-assistant pane, six lifecycle beats, discussion rail, internal chat scrolling, and the full-height 4:3/16:9 layout.
- Use product vocabulary and restrained editorial styling; do not create nested generic cards.
---
### Task 1: Create The Reviewed Authoring Evidence Catalog
**Files:**
- Create: `web/apps/console/src/presentation/authoring/reviewed-authoring-evidence.ts`
- Create: `web/apps/console/src/presentation/authoring/reviewed-authoring-evidence.test.ts`
**Interfaces:**
- Produces: `ReviewedAuthoringEvidence`, `ReviewedAuthoringStep`, and `reviewedAuthoringEvidenceFor(step)`.
- Consumed by: authoring recording/projection and Scene 8 visual components.
- [ ] **Step 1: Write failing catalog tests**
Test all six step IDs and pin the reviewed diagnostic/repair facts:
```ts
expect(reviewedAuthoringEvidenceFor("diagnose")).toMatchObject({
kind: "diagnostic",
workspaceId: "lda_report_workflow",
revision: 3,
status: "invalid",
diagnostic: {
code: "missing_outcome_edge",
path: "nodes[analyze]",
message: "reachable node is missing edges for outcomes ['ok']",
},
});
expect(reviewedAuthoringEvidenceFor("repair")).toMatchObject({
kind: "repair",
fromRevision: 3,
toRevision: 4,
command: "wf draft set-route lda_report_workflow --revision 3 --step analyze --outcome ok --to __end__",
status: "valid",
diagnosticCount: 0,
});
```
Also assert that the serialized catalog does not contain `presentation_diag_probe`, `missing output projection`, or `no state projection`.
- [ ] **Step 2: Run the catalog test and verify RED**
Run the new test directly. Expected: module-not-found failure.
- [ ] **Step 3: Implement the discriminated union and catalog**
Define these variants:
```ts
export type ReviewedAuthoringEvidence =
| { readonly kind: "inventory"; readonly sourceCount: 6; readonly sources: readonly string[]; readonly capability: { readonly name: string; readonly inputs: readonly string[]; readonly outputs: readonly string[]; readonly outcomes: readonly string[] } }
| { readonly kind: "draft"; readonly workspaceId: "lda_report_workflow"; readonly revision: 2; readonly status: "valid"; readonly stepCount: 2; readonly routeCount: 2; readonly steps: readonly string[]; readonly routes: readonly string[] }
| { readonly kind: "diagnostic"; readonly workspaceId: "lda_report_workflow"; readonly revision: 3; readonly status: "invalid"; readonly diagnostic: { readonly code: "missing_outcome_edge"; readonly path: "nodes[analyze]"; readonly message: string; readonly explanation: string } }
| { readonly kind: "repair"; readonly fromRevision: 3; readonly toRevision: 4; readonly command: string; readonly status: "valid"; readonly diagnosticCount: 0 }
| { readonly kind: "artifact"; readonly artifactId: "lda_report_case_study"; readonly version: 1; readonly immutable: true; readonly requiredSources: readonly string[] }
| { readonly kind: "deployment"; readonly deploymentId: "lda_report_case_study.default"; readonly status: "runnable"; readonly bindings: readonly { readonly requirement: string; readonly source: string }[] };
```
Use the three local source IDs and `local.lda_report.analyze_documents` with input `documents`, output `analysis`, and outcome `ok`.
- [ ] **Step 4: Run tests and commit**
```powershell
pnpm --dir web --filter @lda/console test -- src/presentation/authoring/reviewed-authoring-evidence.test.ts
git add web/apps/console/src/presentation/authoring/reviewed-authoring-evidence.ts web/apps/console/src/presentation/authoring/reviewed-authoring-evidence.test.ts
git commit -m "feat: capture reviewed authoring evidence"
```
### Task 2: Correct The Prepared Recording And Storyboard
**Files:**
- Modify: `web/apps/console/src/presentation/authoring/authoring-recording.ts`
- Modify: `web/apps/console/src/presentation/authoring/authoring-recording.test.ts`
- Modify: `web/apps/console/src/presentation/authoring/authoring-projection.ts`
- Modify: `web/apps/console/src/presentation/authoring/authoring-projection.test.ts`
- Modify: `web/apps/console/src/presentation/storyboard.ts`
- Modify: `web/apps/console/src/presentation/storyboard.test.ts`
**Interfaces:**
- Consumes: `reviewedAuthoringEvidenceFor()` from Task 1.
- Produces: factual command transcript and `PreparedLifecycleStepProjection.evidence`.
- [ ] **Step 1: Write failing factual tests**
Replace obsolete assertions with:
```ts
expect(diagnose.primaryCommand.title).toBe("workflow.draft_workspaces.validate");
expect(diagnose.primaryCommand.detail).toContain("missing_outcome_edge");
expect(repair.primaryCommand.title).toBe("workflow.draft_workspaces.set_route");
expect(repair.primaryCommand.command).toContain("--revision 3 --step analyze --outcome ok --to __end__");
expect(diagnose.evidence.kind).toBe("diagnostic");
expect(repair.evidence.kind).toBe("repair");
```
Assert storyboard captions mention a missing `ok` route and a route repair, and do not mention a missing output projection.
- [ ] **Step 2: Run focused tests and verify RED**
Run the authoring recording, projection, and storyboard tests.
- [ ] **Step 3: Update the validate recording**
Use:
```ts
{
title: "workflow.draft_workspaces.validate",
command: "wf draft validate lda_report_workflow",
summary: "Validate the workflow draft",
result: "diagnostic",
detail: "missing_outcome_edge at nodes[analyze]: reachable node is missing edges for outcomes ['ok']",
}
```
and:
```ts
{
title: "workflow.draft_workspaces.set_route",
command: "wf draft set-route lda_report_workflow --revision 3 --step analyze --outcome ok --to __end__",
summary: "Restore the missing terminal route",
result: "success",
detail: "Revision 4 validates with status valid and diagnostics [].",
}
```
Change proof strings to `missing_outcome_edge`, `analyze.ok -> __end__`, and `revision 4: valid`.
- [ ] **Step 4: Project reviewed evidence per presentation step**
Add `readonly evidence: ReviewedAuthoringEvidence` to `PreparedLifecycleStepProjection` and populate it with `reviewedAuthoringEvidenceFor(step)`. Stop constructing the obsolete `repair` visual with hardcoded output-map text; either replace `visual` with the evidence union or derive the visual from `evidence` in one place.
- [ ] **Step 5: Update storyboard captions**
Use:
```text
Validation returns a structured diagnostic because analyze has no route for its ok outcome.
One route edit sends analyze.ok to __end__; the follow-up validation is valid.
```
- [ ] **Step 6: Run focused tests and commit**
```powershell
pnpm --dir web --filter @lda/console test -- src/presentation/authoring/authoring-recording.test.ts src/presentation/authoring/authoring-projection.test.ts src/presentation/storyboard.test.ts
git add web/apps/console/src/presentation/authoring web/apps/console/src/presentation/storyboard.ts web/apps/console/src/presentation/storyboard.test.ts
git commit -m "fix: use factual prepared validation evidence"
```
### Task 3: Render Product-Like Scene 8 Results
**Files:**
- Modify: `web/apps/console/src/presentation/authoring/AuthoringPhaseVisual.tsx`
- Modify: `web/apps/console/src/presentation/authoring/AuthoringPhaseVisual.test.tsx`
- Modify: `web/apps/console/src/presentation/authoring/PreparedAuthoringLifecycleScene.tsx`
- Modify: `web/apps/console/src/presentation/authoring/PreparedAuthoringLifecycleScene.test.tsx`
**Interfaces:**
- Consumes: `PreparedLifecycleStepProjection.evidence`.
- Produces: accessible phase result regions with `data-authoring-result` values matching each evidence kind.
- [ ] **Step 1: Write failing component tests**
Pin the following audience-visible facts:
```ts
expect(screen.getByRole("region", { name: /draft validation diagnostic/i }))
.toHaveAttribute("data-authoring-result", "diagnostic");
expect(screen.getByText("missing_outcome_edge")).toBeInTheDocument();
expect(screen.getByText("nodes[analyze]")).toBeInTheDocument();
expect(screen.getByText(/missing edges for outcomes.*ok/i)).toBeInTheDocument();
```
For Repair, assert the full command is visible, the status reads `Valid`, revision `4` is visible, diagnostic count is `0`, and the invalid message is present only as compact prior context rather than the primary result.
Add one test per remaining phase for source count/capability contract, draft revision/steps/routes, immutable artifact identity, and runnable deployment bindings.
- [ ] **Step 2: Run component tests and verify RED**
Run `AuthoringPhaseVisual.test.tsx` and `PreparedAuthoringLifecycleScene.test.tsx`.
- [ ] **Step 3: Implement a shared result header and six evidence renderers**
Use one local `ResultHeader` component with icon, label, status, and optional revision. Render semantic `dl` rows for identifiers and counts, a plain list for sources/bindings, and `code` for commands/paths. Keep icons from the existing Lucide dependency: `Database`, `Workflow`, `AlertTriangle`, `Route`, `CheckCircle2`, `LockKeyhole`, and `Link2`.
Diagnose hierarchy:
```text
INVALID DRAFT · REVISION 3
missing_outcome_edge
nodes[analyze]
reachable node is missing edges for outcomes ['ok']
The workflow cannot prove where execution goes next.
```
Repair hierarchy:
```text
ROUTE REPAIR
missing_outcome_edge · nodes[analyze]
wf draft set-route ... --to __end__
VALID · REVISION 4 · 0 DIAGNOSTICS
```
- [ ] **Step 4: Preserve the phase boundary in the scene wrapper**
Pass the full step projection to `AuthoringPhaseVisual`; do not make the visual infer Diagnose versus Repair from CSS alone. Retain `data-authoring-step`, `data-recording-phase`, and the stable assistant/frame sibling structure.
- [ ] **Step 5: Run focused tests and commit**
```powershell
pnpm --dir web --filter @lda/console test -- src/presentation/authoring/AuthoringPhaseVisual.test.tsx src/presentation/authoring/PreparedAuthoringLifecycleScene.test.tsx
git add web/apps/console/src/presentation/authoring
git commit -m "feat: render Scene 8 product evidence"
```
### Task 4: Style The Product Results Without Reintroducing Overflow
**Files:**
- Modify: `web/apps/console/src/presentation/presentation.css`
- Modify: `web/apps/console/src/presentation/presentation-css.test.ts`
**Interfaces:**
- Consumes: `data-authoring-result` hooks from Task 3.
- Produces: responsive editorial result layouts within the existing full-height frame.
- [ ] **Step 1: Add failing CSS contract tests**
Assert that:
- the result root uses `min-height: 0` and `overflow: auto`;
- Diagnose uses a single primary diagnostic column rather than hidden sibling cards;
- Repair uses a command band followed by a valid-result row;
- status is not communicated by color alone;
- no wide `56vh` cap or content-sized scene row returns; and
- the discussion rail remains transparent and borderless.
- [ ] **Step 2: Run CSS tests and verify RED**
Run `presentation-css.test.ts` directly.
- [ ] **Step 3: Implement restrained result styling**
Use the existing editorial paper, ink, muted, rule, success, and amber tokens. Use one structural rule between result sections, no wide shadow, no nested rounded cards, and `font-mono` only for commands, codes, paths, IDs, and revisions. Give Diagnose and Repair enough scale to fill the right frame without stretching single lines across the full width.
At narrow canvas widths, stack result metadata above the main evidence while preserving internal scrolling. Do not change the outer Scene 8 grid or assistant width in this task.
- [ ] **Step 4: Run tests and commit**
```powershell
pnpm --dir web --filter @lda/console test -- src/presentation/presentation-css.test.ts src/presentation/authoring/AuthoringPhaseVisual.test.tsx
git add web/apps/console/src/presentation/presentation.css web/apps/console/src/presentation/presentation-css.test.ts
git commit -m "style: compose Scene 8 product results"
```
### Task 5: Route Smoke, Full Verification, And Docs Closure
**Files:**
- Modify if assertions need factual correction: `web/apps/console/src/presentation/PresentationRoute.test.tsx`
- Modify: `docs/current_roadmap.md`
- Move after completion: `docs/superpowers/plans/2026-07-13-scene-8-product-evidence.md` to `docs/historical/superpowers/plans/2026-07-13-scene-8-product-evidence.md`
**Interfaces:**
- Consumes: completed Scene 8 evidence implementation.
- Produces: route-level regression coverage and accurate roadmap state.
- [ ] **Step 1: Add direct-hash route assertions**
For `#scene/prepared-lifecycle/diagnose`, assert `missing_outcome_edge`, `nodes[analyze]`, and no `missing output projection`. For Repair, assert the exact set-route command and `Valid` revision `4` result.
- [ ] **Step 2: Run the complete presentation test set**
```powershell
pnpm --dir web --filter @lda/console test -- src/presentation
pnpm --dir web --filter @lda/console typecheck
pnpm --dir web --filter @lda/console build
npx react-doctor@latest --verbose --scope changed
git diff --check
```
Expected: all tests pass, typecheck/build succeed, React Doctor reports no regression, and diff check is clean.
- [ ] **Step 3: Perform browser smoke at three viewport sizes**
Capture all six routes at `1280x720`, `1024x768`, and `1920x1080`:
```text
#scene/prepared-lifecycle/discover
#scene/prepared-lifecycle/draft
#scene/prepared-lifecycle/diagnose
#scene/prepared-lifecycle/repair
#scene/prepared-lifecycle/artifact
#scene/prepared-lifecycle/deployment
```
For each viewport, confirm the scene and document do not overflow, the right result fills the available stage, the chat transcript scrolls internally, the composer remains anchored, and the discussion rail has no enclosing panel background/border.
- [ ] **Step 4: Mark the roadmap item completed and archive the plan**
Record the reviewed diagnostic code and route repair in the completion note. Update links to the historical plan path.
- [ ] **Step 5: Commit closure**
```powershell
git add web/apps/console/src/presentation docs/current_roadmap.md docs/superpowers/plans/2026-07-13-scene-8-product-evidence.md docs/historical/superpowers/plans/2026-07-13-scene-8-product-evidence.md
git commit -m "docs: complete Scene 8 product evidence"
```
docs/superpowers/specs/2026-07-13-defense-speech-and-scene-8-evidence-design.md
+142
View File
@@ -0,0 +1,142 @@
# Defense Speech And Scene 8 Product Evidence Design
## Purpose
The defense must be easy to say under time pressure and easy to understand for
an audience that has not read the thesis. The current opening script introduces
too many technical nouns before the demonstration gives them concrete meaning.
Scene 8 also presents a prepared validation failure that does not reproduce in
the current product.
This design separates two independently shippable changes:
1. simplify the spoken path through Scenes 1-8; and
2. replace Scene 8's sparse prepared visuals with compact product-result views
based on reviewed `wf` output.
## Speech Contract
Each beat has one spoken idea. The presenter may use optional notes during Q&A,
but the timed path does not require lists of architecture terms.
The simplified story is:
1. The title is the product ambition; the contribution is the platform below
the agent.
2. A chat/tool transcript can finish a task, but it is not a reusable workflow.
3. Existing systems solve adjacent problems; this work does not replace them.
4. A planner decides; the runtime executes; the Workflow API is their public
boundary.
5. A workflow moves through Draft, Artifact, Deployment, and Run.
6. Clients enter through Workflow API; WorkflowServer composes records,
capabilities, and execution.
7. The demonstration is a prepared example, not a live autonomous planner.
8. The example discovers capabilities, authors a draft, diagnoses a missing
route, repairs it, saves an artifact, and creates a deployment.
Terms such as provider neutrality, typed contracts, source resolution, explicit
resume boundaries, and NodeUse remain available in visuals, optional notes, and
Q&A. They are not mandatory opening narration.
The target for Scenes 1-8 is approximately four minutes, including navigation.
The complete must-say path should remain comfortably below the previous 11-minute
target so the presenter can pause and recover without rushing.
## Reviewed Product Evidence
The prepared evidence remains deterministic. It does not call authoring RPCs
while the presentation is running. Its data is hardcoded from a reviewed live
CLI probe against:
```text
uv run wf-rpc-server \
--config examples/lda_report_workflow/wf.config.json \
--host 127.0.0.1 \
--port 8765
```
The reviewed invalid result was produced by removing the `ok` route from the
`analyze` step and running:
```text
uv run wf --url http://127.0.0.1:8765/rpc \
draft validate presentation_diag_probe2
```
The relevant result is:
```json
{
"status": "invalid",
"revision": 3,
"diagnostics": [
{
"code": "missing_outcome_edge",
"path": "nodes[analyze]",
"message": "reachable node is missing edges for outcomes ['ok']",
"details": {}
}
]
}
```
`wf explain missing_outcome_edge` reports that the workflow cannot prove where
execution goes next and recommends routing each missing outcome, using
`__end__` for terminal outcomes.
The reviewed repair is:
```text
wf draft set-route lda_report_workflow \
--revision 3 \
--step analyze \
--outcome ok \
--to __end__
```
The follow-up validation result is `status: valid`, `revision: 4`, and
`diagnostics: []`.
The disposable probe workspace was deleted after capture.
## Scene 8 Visual Contract
Scene 8 remains a two-column prepared lifecycle surface with supporting chat on
the left and one dominant product result on the right. It does not copy the
full `/console` UI, but it uses the same evidence vocabulary: status, revision,
method, command, records, diagnostics, and bindings.
- Discover shows configured source IDs and one inspected capability contract.
- Draft shows workspace identity, revision, status, step count, route count,
and the two-step graph.
- Diagnose shows an invalid status, diagnostic code, path, message, and compact
explanation.
- Repair shows the exact route mutation, why it fixes the graph, and the valid
follow-up result.
- Artifact shows immutable artifact ID, version, and required sources.
- Deployment shows deployment ID, source bindings, and runnable status.
Diagnose and Repair are two views of one factual validation sequence. Diagnose
does not reveal the successful result early. Repair retains enough diagnostic
context to make the transition understandable.
## Truth Boundaries
- Do not label the prepared authoring sequence as live execution.
- Do not claim that diagnostics automatically repair workflows.
- Do not claim that a missing output projection invalidates this draft; it did
not reproduce in the current product.
- Do not expose the disposable probe workspace ID in the audience UI.
- The broader root-config server is useful for product exploration but is not
the evidence source for the deterministic report-workflow scene.
## Verification
- Presenter tests enforce one note per beat, the reduced word budget, and
synchronization with the readable runbook.
- Projection tests pin the reviewed diagnostic code, path, message, revision,
exact public repair command, and valid follow-up state.
- Component tests verify each phase's dominant product-result surface and the
Diagnose-to-Repair information boundary.
- Browser smoke covers all six Scene 8 beats at `1280x720`, `1024x768`, and
`1920x1080`, including internal chat scrolling and no document overflow.