docs: reconcile consolidated defense story
This commit is contained in:
+31
-32
@@ -169,9 +169,8 @@ both modes. Replay is visibly labeled and does not create real issues.
|
||||
### Presentation Mode
|
||||
|
||||
The console exposes `/present`, a 720p no-scroll defense compositor for the
|
||||
prepared `lda_report_workflow` story. It renders a 14-scene, multi-beat
|
||||
storyboard (expanded from the original 12-scene defense plan; items 13 and 14
|
||||
now cover evaluation and closing) with an adaptive aspect-ratio canvas, stable
|
||||
prepared `lda_report_workflow` story. It renders a 13-scene, multi-beat
|
||||
storyboard with an adaptive aspect-ratio canvas, stable
|
||||
stage regions, discussion branches, one editorial canvas, persistent scene-aware
|
||||
assistant surfaces, and keyboard navigation.
|
||||
|
||||
@@ -188,23 +187,23 @@ The final presentation beats frame the evaluation as bounded evidence, make
|
||||
claim boundaries and future work explicit, and end on the canonical defense
|
||||
discussion index rather than a benchmark or generic conclusion.
|
||||
|
||||
Scenes 8 and 9 use the canonical prepared-authoring recording as their only
|
||||
execution evidence. Scene 8 is a single full-screen chat-entry beat: its
|
||||
Scenes 7 and 8 use the canonical prepared-authoring recording as their only
|
||||
execution evidence. Scene 7 is a single full-screen chat-entry beat: its
|
||||
prefilled request is submitted locally, then reveals the first deterministic
|
||||
user, assistant, and Discover tool group. It is deterministic replay, not a live
|
||||
LLM chat, and does not start a workflow run. Scene 9 breaks the prepared
|
||||
authoring into five phases with a persistent prepared-agent assistant pane on
|
||||
LLM chat, and does not start a workflow run. Scene 8 breaks the prepared
|
||||
authoring into six beats with a persistent prepared-agent assistant pane on
|
||||
the left and a dominant phase canvas on the right. The adaptive split starts
|
||||
near 35/65 and keeps the matching prepared tool group synchronized with each
|
||||
factual source, graph, repair, artifact, or deployment view. Neither scene calls
|
||||
workflow authoring RPC operations — they consume deterministic prepared data. Scenes 10 through
|
||||
12 use the canonical replay by default when no live target is available. When
|
||||
workflow authoring RPC operations — they consume deterministic prepared data. Scenes 9 through
|
||||
11 use the canonical replay by default when no live target is available. When
|
||||
the resolved target is healthy, the same prepared run flow can execute through
|
||||
the public JSON-RPC operations and record live evidence using the same
|
||||
DemoRunFacts projection. Raw protocol payloads are available through the
|
||||
evidence receipt and inspector.
|
||||
|
||||
Scenes 8–12 share one compact footer demo rail. Scene 8 remains a local scripted conversation, with its chat composer as the main surface, while the rail owns `Run prepared workflow`, replay fallback, retry, running, paused, resuming, and completed labels.
|
||||
Scenes 7–11 share one compact footer demo rail. Scene 7 remains a local scripted conversation, with its chat composer as the main surface, while the rail owns `Run prepared workflow`, replay fallback, retry, running, paused, resuming, and completed labels.
|
||||
With a healthy target, the rail starts the live chain through the existing
|
||||
`/api/rpc` proxy; when health fails, it keeps `Play replay walkthrough` as an
|
||||
explicit fallback. The presentation does not silently replace a live failure
|
||||
@@ -228,19 +227,19 @@ presentation timeline.
|
||||
|
||||
The key deep-link-addressable defense states include:
|
||||
|
||||
- `/present#scene/agent-handoff/request` — Scene 8, prepared authoring request
|
||||
- `/present#scene/prepared-lifecycle/discover` — Scene 9, discover phase
|
||||
- `/present#scene/prepared-lifecycle/draft` — Scene 9, draft phase
|
||||
- `/present#scene/prepared-lifecycle/deployment` — Scene 9, deployment phase
|
||||
- `/present#scene/run-from-deployment/operation` — Scene 10, run operation
|
||||
- `/present#scene/run-from-deployment/graph` — Scene 10, workflow graph
|
||||
- `/present#scene/typed-human-boundary/approval` — Scene 11, typed approval
|
||||
- `/present#scene/resume-output-evidence/resume` — Scene 12, resume proof
|
||||
- `/present#scene/agent-handoff/request` — Scene 7, prepared authoring request
|
||||
- `/present#scene/prepared-lifecycle/discover` — Scene 8, discover phase
|
||||
- `/present#scene/prepared-lifecycle/draft` — Scene 8, draft phase
|
||||
- `/present#scene/prepared-lifecycle/deployment` — Scene 8, deployment phase
|
||||
- `/present#scene/run-from-deployment/operation` — Scene 9, run operation
|
||||
- `/present#scene/run-from-deployment/graph` — Scene 9, workflow graph
|
||||
- `/present#scene/typed-human-boundary/approval` — Scene 10, typed approval
|
||||
- `/present#scene/resume-output-evidence/resume` — Scene 11, resume proof
|
||||
|
||||
Legacy aliases from the earlier 12-scene plan (such as `workflow-demo` and
|
||||
`interrupt-evidence`) are replaced by the IDs above and no longer resolve.
|
||||
|
||||
Scene 12 is factual by design. It projects the reviewed/live run into visible
|
||||
Scene 11 is factual by design. It projects the reviewed/live run into visible
|
||||
workflow input, interrupt payload, resume decision, output, and trace facts.
|
||||
Empty trace frame objects are shown as captured empty objects; absent fields are
|
||||
called out as not captured rather than replaced by generic placeholders.
|
||||
@@ -351,39 +350,39 @@ The current prepared recipe can:
|
||||
This is intentionally not a general autonomous planner. A future server-side
|
||||
Vercel AI SDK driver can feed the same message-part interface.
|
||||
|
||||
### Authoring Story (Scenes 8 and 9)
|
||||
### Authoring Story (Scenes 7 and 8)
|
||||
|
||||
Scenes 8 and 9 are the prepared authoring story. They use deterministic data
|
||||
Scenes 7 and 8 are the prepared authoring story. They use deterministic data
|
||||
from the committed `projectPreparedAuthoring()` recording and never call
|
||||
workflow authoring RPC operations.
|
||||
|
||||
- **Scene 8 (Agent Request)**: a single full-screen deterministic chat entry that
|
||||
- **Scene 7 (Agent Request)**: a single full-screen deterministic chat entry that
|
||||
pre-fills the report-authoring request. Send is local presentation state and
|
||||
reveals the first prepared Discover tool group. This is not a live LLM chat
|
||||
or workflow run.
|
||||
- **Scene 9 (Prepared Workflow Lifecycle)**: a five-phase lifecycle
|
||||
(discover, draft, validate, artifact, deployment) with a compact phase rail
|
||||
- **Scene 8 (Prepared Workflow Lifecycle)**: a six-beat lifecycle
|
||||
(discover, draft, diagnose, repair, artifact, deployment) with a compact phase rail
|
||||
and one dominant factual product projection per beat. A persistent prepared
|
||||
assistant pane stays visible on the left while the phase canvas remains
|
||||
dominant on the right; the starting split is approximately 35/65 and adapts
|
||||
to the available width. Its active tool group follows the current beat. There
|
||||
is no lower chat dock, detached trace modal, or second transcript.
|
||||
|
||||
One staged message box remains visible in every phase. Discover and Validate
|
||||
start empty with useful placeholders; Draft and Artifact use the exact next
|
||||
authoring prompts. Sending an edited Draft advances to Validate and preserves
|
||||
One staged message box remains visible in every phase. Discover starts empty
|
||||
with useful placeholders; Draft and Artifact use the exact next authoring
|
||||
prompts. Sending an edited Draft advances through Diagnose and Repair and preserves
|
||||
that text as the projected user turn; sending an edited Artifact does the
|
||||
same for Deployment. Deployment Send records only `Run request prepared for
|
||||
the next execution slice.` and makes no run or RPC request.
|
||||
|
||||
The authoring scenes consume deterministic prepared data and never call
|
||||
workflow authoring RPCs. Scene 9 ends at the truthful run-request
|
||||
handoff; Scenes 10–12 own run activation, typed approval, resume, output, and
|
||||
trace evidence. No Scene 9 message submission starts a workflow run.
|
||||
workflow authoring RPCs. Scene 8 ends at the truthful run-request handoff;
|
||||
Scenes 9–11 own run activation, typed approval, resume, output, and trace
|
||||
evidence. No Scene 8 message submission starts a workflow run.
|
||||
|
||||
### Demo Climax (Scenes 8–12)
|
||||
### Demo Climax (Scenes 7–11)
|
||||
|
||||
Scenes 8 through 12 are the demo climax. They keep a continuity rail visible
|
||||
Scenes 7 through 11 are the demo climax. They keep a continuity rail visible
|
||||
while the prepared replay moves from persisted workflow run, to typed human
|
||||
interrupt, to resume/output/evidence. The rail and outcome panel are
|
||||
presentation-only projections over the committed replay; they do not add live
|
||||
|
||||
@@ -15,7 +15,7 @@ describe("PresenterRoute", () => {
|
||||
expect(screen.getByRole("main", { name: /lda.chat presenter notes/i })).toBeInTheDocument();
|
||||
expect(screen.getByText(/This project began with the goal/i)).toBeInTheDocument();
|
||||
expect(screen.getByText("the system underneath the chat").tagName).toBe("STRONG");
|
||||
expect(screen.getByRole("navigation", { name: /presenter note navigation/i })).toHaveTextContent("1 / 43");
|
||||
expect(screen.getByRole("navigation", { name: /presenter note navigation/i })).toHaveTextContent("1 / 39");
|
||||
expect(screen.getByRole("link", { name: "Next →" })).toHaveAttribute("href", "#scene/thesis/substrate");
|
||||
expect(screen.getByRole("link", { name: /open audience slide/i })).toHaveAttribute("href", "/present#scene/thesis/title");
|
||||
expect(screen.queryByText(/live target/i)).not.toBeInTheDocument();
|
||||
|
||||
@@ -14,8 +14,10 @@ import {
|
||||
describe("presenter note catalog", () => {
|
||||
it("has exactly one note for every current storyboard beat", () => {
|
||||
const noteKeys = presenterNotes.map((note) => `${note.sceneId}/${note.beatId}`);
|
||||
const canonicalKeys = mainScenes.flatMap((scene) => scene.beats.map((beat) => `${scene.id}/${beat.id}`));
|
||||
|
||||
expect(new Set(noteKeys).size).toBe(noteKeys.length);
|
||||
expect([...noteKeys].sort()).toEqual([...canonicalKeys].sort());
|
||||
for (const scene of mainScenes) {
|
||||
for (const beat of scene.beats) {
|
||||
const note = presenterBeatNoteFor(scene.id, beat.id);
|
||||
@@ -24,7 +26,7 @@ describe("presenter note catalog", () => {
|
||||
}
|
||||
}
|
||||
|
||||
expect(noteKeys).toHaveLength(mainScenes.flatMap((scene) => scene.beats).length);
|
||||
expect(noteKeys).toHaveLength(canonicalKeys.length);
|
||||
});
|
||||
|
||||
it("keeps the planned scene timing and complete-deck cap", () => {
|
||||
@@ -44,18 +46,33 @@ describe("presenter note catalog", () => {
|
||||
75,
|
||||
]);
|
||||
expect(completeDeckTargetSeconds()).toBe(735);
|
||||
expect(completeDeckTargetSeconds()).toBeLessThanOrEqual(780);
|
||||
expect(completeDeckTargetSeconds()).toBeLessThanOrEqual(900);
|
||||
expect(presenterSceneNotes("prepared-lifecycle")).toHaveLength(6);
|
||||
for (const note of presenterSceneNotes("prepared-lifecycle")) {
|
||||
expect(note.targetSeconds).toBeGreaterThanOrEqual(8);
|
||||
expect(note.targetSeconds).toBeLessThanOrEqual(10);
|
||||
}
|
||||
});
|
||||
|
||||
it("keeps removed scene and beat IDs out of timed notes", () => {
|
||||
expect(presenterNotes.some((note) => note.sceneId === ("authoring" as typeof mainScenes[number]["id"]))).toBe(false);
|
||||
expect(presenterBeatNoteFor("prepared-lifecycle", "validate")).toBeUndefined();
|
||||
expect(presenterBeatNoteFor("architecture", "node-use")).toBeUndefined();
|
||||
});
|
||||
|
||||
it("describes structured diagnosis and the focused output-map repair", () => {
|
||||
expect(presenterBeatNoteFor("prepared-lifecycle", "diagnose")?.mustSay).toMatch(/structured diagnostics/i);
|
||||
expect(presenterBeatNoteFor("prepared-lifecycle", "repair")?.mustSay).toMatch(/focused output-map edit/i);
|
||||
});
|
||||
|
||||
it("keeps NodeUse out of timed notes while retaining the architecture spine", () => {
|
||||
expect(presenterBeatNoteFor("architecture", "node-use")).toBeUndefined();
|
||||
expect(presenterBeatNoteFor("architecture", "overview")).toBeDefined();
|
||||
expect(presenterBeatNoteFor("architecture", "api")).toBeDefined();
|
||||
expect(presenterBeatNoteFor("architecture", "runtime")).toBeDefined();
|
||||
});
|
||||
|
||||
it("keeps the must-say speech within the defense word budget", () => {
|
||||
expect(mainSpeechWordCount()).toBeGreaterThanOrEqual(750);
|
||||
expect(mainSpeechWordCount()).toBeGreaterThanOrEqual(650);
|
||||
expect(mainSpeechWordCount()).toBeLessThanOrEqual(850);
|
||||
});
|
||||
|
||||
|
||||
@@ -199,7 +199,7 @@ export const presenterNotes = [
|
||||
"prepared-lifecycle",
|
||||
"discover",
|
||||
9,
|
||||
"The later issue-review example first inspects configured local.lda_docs, report, and issue-board capabilities.",
|
||||
"It inspects sources, capabilities, and schemas rather than guessing at hidden interfaces.",
|
||||
["examples/lda_report_workflow", "deployment inspect replay evidence"],
|
||||
{ qnaBranchIds: ["prepared-replay-boundary", "why-schemas", "validation-diagnostics"] },
|
||||
),
|
||||
@@ -207,7 +207,7 @@ export const presenterNotes = [
|
||||
"prepared-lifecycle",
|
||||
"draft",
|
||||
9,
|
||||
"It creates and edits a Draft for report generation, making the proposal visible before execution.",
|
||||
"Focused operations modify mutable authoring state before execution.",
|
||||
["examples/lda_report_workflow", "deployment inspect replay evidence", "CLI documentation", "Draft authoring API"],
|
||||
{ qnaBranchIds: ["raw-plan-import"] },
|
||||
),
|
||||
@@ -215,7 +215,7 @@ export const presenterNotes = [
|
||||
"prepared-lifecycle",
|
||||
"diagnose",
|
||||
9,
|
||||
"Validation returns structured diagnostics, affected paths, repair hints, and suggested next actions.",
|
||||
"Structured diagnostics identify the missing output projection.",
|
||||
["examples/lda_report_workflow", "deployment inspect replay evidence"],
|
||||
{ qnaBranchIds: ["validation-diagnostics"] },
|
||||
),
|
||||
@@ -223,7 +223,7 @@ export const presenterNotes = [
|
||||
"prepared-lifecycle",
|
||||
"repair",
|
||||
9,
|
||||
"These surfaces make invalid intermediate drafts repairable; they support a loop, but no hint guarantees success.",
|
||||
"One focused output-map edit resolves it; hints do not guarantee automatic repair.",
|
||||
["Validation and diagnostics", "Challenge UX findings"],
|
||||
{ warning: "Do not promise that diagnostics automatically repair every workflow.", qnaBranchIds: ["validation-diagnostics"] },
|
||||
),
|
||||
@@ -238,9 +238,9 @@ export const presenterNotes = [
|
||||
"prepared-lifecycle",
|
||||
"deployment",
|
||||
9,
|
||||
"This later issue-review example is richer than the thesis three-node deterministic report case study: it is an implementation extension built on the same platform. Deployment binds and validates a ready configuration but does not run the workflow.",
|
||||
"Deployment binds and validates three local sources; execution starts in the next scene.",
|
||||
["examples/lda_report_workflow", "deployment inspect replay evidence", "Thesis deterministic report case study"],
|
||||
{ warning: "Do not present issue-board output from this later example as the thesis case study.", qnaBranchIds: ["prepared-replay-boundary"] },
|
||||
{ warning: "This later issue-review example is richer than the thesis case study; do not present its issue-board output as thesis output.", qnaBranchIds: ["prepared-replay-boundary"] },
|
||||
),
|
||||
beatNote(
|
||||
"run-from-deployment",
|
||||
|
||||
Reference in New Issue
Block a user