docs: reconcile consolidated defense story
This commit is contained in:
@@ -148,8 +148,8 @@ location.reload();
|
||||
|
||||
When a stateful demo deep link is opened before this browser session has started
|
||||
a live run, the presentation selects the reviewed recording for that beat even
|
||||
if the loopback health probe succeeds. Scene 8's request and Send action remain
|
||||
local replay behavior; start the live path from the Scene 10 run operation.
|
||||
if the loopback health probe succeeds. Scene 7's request and Send action remain
|
||||
local replay behavior; start the live path from the Scene 9 run operation.
|
||||
Otherwise the typed interrupt, output, and trace links remain useful
|
||||
replay-backed entry points.
|
||||
|
||||
@@ -256,19 +256,19 @@ Say:
|
||||
|
||||
## Twenty-Five-Minute Timing
|
||||
|
||||
Target an 11:45 must-say path plus 1:15 for navigation and demo transitions,
|
||||
Target an 11:00 must-say path plus 1:15 for navigation and demo transitions,
|
||||
leaving 12 minutes for questions.
|
||||
|
||||
| Time | Segment | Notes |
|
||||
|---:|---|---|
|
||||
| 0:00-1:30 | Title and problem | AI-agent goal becomes a workflow substrate contribution |
|
||||
| 1:30-2:15 | Positioning | Adjacent systems and the prototype's narrower position |
|
||||
| 2:15-5:30 | Architecture and authoring | Planner/runtime boundary, lifecycle, implementation, authoring |
|
||||
| 5:30-8:30 | Prepared demonstration | Request, deployment, start, interrupt, resume, output, trace |
|
||||
| 8:30-10:30 | Evaluation | 36 audited trials as bounded engineering evidence |
|
||||
| 10:30-11:45 | Limits and conclusion | Security, scheduling, evaluation, and agent-layer boundaries |
|
||||
| 11:45-13:00 | Transition buffer | Navigation, interaction, and demo delay |
|
||||
| 13:00-25:00 | Questions | Use prepared Q&A branches when available |
|
||||
| 2:15-4:36 | Architecture and lifecycle | Planner/runtime boundary, lifecycle, and architecture |
|
||||
| 4:36-7:45 | Prepared demonstration | Request, authoring, deployment, start, interrupt, resume, output, trace |
|
||||
| 7:45-9:45 | Evaluation | 36 audited trials as bounded engineering evidence |
|
||||
| 9:45-11:00 | Limits and conclusion | Security, scheduling, evaluation, and agent-layer boundaries |
|
||||
| 11:00-12:15 | Transition buffer | Navigation, interaction, and demo delay |
|
||||
| 12:15-24:15 | Questions | Use prepared Q&A branches when available |
|
||||
|
||||
Use [`defense-speech-and-claim-audit.md`](defense-speech-and-claim-audit.md)
|
||||
for the rehearsed speech, evidence qualifications, and prioritized Q&A.
|
||||
@@ -316,7 +316,7 @@ Answer:
|
||||
|
||||
## Pre-Defense Checklist
|
||||
|
||||
1. Start `/present` with the intended target. Verify Scene 8 submits the prepared
|
||||
1. Start `/present` with the intended target. Verify Scene 7 submits the prepared
|
||||
request, and verify the prepared-run action appears on the demo scenes when
|
||||
the live badge is ready.
|
||||
2. Complete one submitted branch and confirm the same run reaches output and
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# Defense speech and claim audit
|
||||
|
||||
This runbook gives you the must-say 11:45 defense speech, a 1:15 navigation buffer, and a prioritized 12-minute question period. It also marks claims that require qualification so the presentation stays aligned with the thesis and current implementation. The typed catalog at `web/apps/console/src/presentation/presenter/presenter-notes.ts` is the source for the must-say text.
|
||||
This runbook gives you the must-say 11:00 defense speech, a 1:15 navigation buffer, and a prioritized 12-minute question period. It also marks claims that require qualification so the presentation stays aligned with the thesis and current implementation. The typed catalog at `web/apps/console/src/presentation/presenter/presenter-notes.ts` is the source for the must-say text.
|
||||
|
||||
## Timing and evidence rules
|
||||
|
||||
@@ -11,18 +11,18 @@ Use these evidence labels while rehearsing. Do not read the labels aloud.
|
||||
- **Qualify**: accurate only within an explicit boundary
|
||||
- **Do not claim**: unsupported, untested, or excluded from scope
|
||||
|
||||
Target 11:45 for the must-say speech. Keep 1:15 for navigation or demo delay; the complete deck target is 13:00. The question period then has 12 minutes.
|
||||
Target 11:00 for the must-say speech. Keep 1:15 for navigation or demo delay; the complete deck target is 12:15. The question period then has 12 minutes.
|
||||
|
||||
| Segment | Target |
|
||||
| --- | ---: |
|
||||
| Scenes 1-2: goal and problem | 1:30 |
|
||||
| Scenes 3-7: positioning, model, and implementation | 3:15 |
|
||||
| Scenes 8-12: prepared demonstration | 3:00 |
|
||||
| Scene 13: evaluation | 2:00 |
|
||||
| Scene 14: limits and conclusion | 1:15 |
|
||||
| Must-say speech | 11:45 |
|
||||
| Scenes 3-6: positioning, model, and architecture | 3:06 |
|
||||
| Scenes 7-11: prepared demonstration | 3:09 |
|
||||
| Scene 12: evaluation | 2:00 |
|
||||
| Scene 13: limits and conclusion | 1:15 |
|
||||
| Must-say speech | 11:00 |
|
||||
| Navigation buffer | 1:15 |
|
||||
| Complete deck target | 13:00 |
|
||||
| Complete deck target | 12:15 |
|
||||
|
||||
## Main speech
|
||||
|
||||
@@ -92,32 +92,20 @@ Keep Scene 5 conceptual. Scene 9 applies this vocabulary to the prepared example
|
||||
|
||||
### Scene 6: Zoom through the implemented architecture
|
||||
|
||||
**Route:** `architecture/overview`, `architecture/client`, `architecture/api`, `architecture/runtime`, then `architecture/node-use`<br>
|
||||
**Time:** 3:55-4:50
|
||||
**Route:** `architecture/overview`, `architecture/client`, `architecture/api`, then `architecture/runtime`<br>
|
||||
**Time:** 3:55-4:36
|
||||
**Evidence:** Supported
|
||||
|
||||
Say:
|
||||
|
||||
> First, the implemented architecture spine and its ownership boundaries. Humans and agents share one public lifecycle surface. WorkflowApi owns lifecycle operations; JSON-RPC only adapts transport. WorkflowServer composes records, capabilities, API, and kernel; providers remain outside the core. NodeUse invokes a NodeDef handler, reduces state, records trace, and routes the declared outcome.
|
||||
> First, the implemented architecture spine and its ownership boundaries. Humans and agents share one public lifecycle surface. WorkflowApi owns lifecycle operations; JSON-RPC only adapts transport. WorkflowServer composes records, capabilities, API, and kernel; providers remain outside the core.
|
||||
|
||||
The NodeUse sequence is documented in the thesis runtime diagram and narrative ([lines 706-750](../thesis/system-design-implementation.md#workflow-core-model)).
|
||||
The optional NodeUse deep dive remains available through the architecture focus route and Q&A; it is not part of the timed forward sequence.
|
||||
|
||||
### Scene 7: Explain agent-operable authoring
|
||||
|
||||
**Route:** `authoring/discover`, `authoring/author`, `authoring/diagnose`, then `authoring/repair`
|
||||
**Time:** 4:50-5:30
|
||||
**Evidence:** Supported, with qualification
|
||||
|
||||
Say:
|
||||
|
||||
> Before authoring, a client can discover sources, capabilities, and schemas instead of guessing at hidden interfaces. Focused operations let an external agent change a mutable Draft while preserving a clear lifecycle boundary. Validation returns structured diagnostics, affected paths, repair hints, and suggested next actions. These surfaces make invalid intermediate drafts repairable; they support a loop, but no hint guarantees success.
|
||||
|
||||
Do not say that every repair hint guarantees a valid workflow. Say that diagnostics are designed to support repair loops and that targeted tests cover the implemented paths ([lines 909-962](../thesis/system-design-implementation.md#validation-and-diagnostics)). Mention the instruction layer if asked: skills and runbooks also affected operability ([lines 1505-1531](../thesis/system-design-implementation.md#agent-instruction-layer)).
|
||||
|
||||
### Scene 8: Introduce the prepared demonstration honestly
|
||||
### Scene 7: Introduce the prepared demonstration honestly
|
||||
|
||||
**Route:** `agent-handoff/request`
|
||||
**Time:** 5:30-5:50
|
||||
**Time:** 4:36-4:56
|
||||
**Evidence:** Implementation extension
|
||||
|
||||
Say:
|
||||
@@ -126,22 +114,22 @@ Say:
|
||||
|
||||
If replay is active, say: “This is the reviewed recording, not a live model planning this workflow.”
|
||||
|
||||
### Scene 9: Show authoring and deployment without starting a run
|
||||
### Scene 8: Show the prepared lifecycle
|
||||
|
||||
**Route:** all five `prepared-lifecycle/*` beats
|
||||
**Time:** 5:50-6:35
|
||||
**Evidence:** Implementation extension
|
||||
**Route:** all six `prepared-lifecycle/*` beats
|
||||
**Time:** 4:56-5:50
|
||||
**Evidence:** Implementation extension; supported with qualification
|
||||
|
||||
Say:
|
||||
|
||||
> The later issue-review example first inspects configured local.lda_docs, report, and issue-board capabilities. It creates and edits a Draft for report generation, making the proposal visible before execution. It validates incomplete state, exposes a missing output binding, and applies a targeted repair. It saves the validated plan as immutable artifact lda_report_case_study version 1. 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.
|
||||
> It inspects sources, capabilities, and schemas rather than guessing at hidden interfaces. Focused operations modify mutable authoring state before execution. Structured diagnostics identify the missing output projection. One focused output-map edit resolves it; hints do not guarantee automatic repair. It saves the validated plan as immutable artifact lda_report_case_study version 1. Deployment binds and validates three local sources; execution starts in the next scene.
|
||||
|
||||
This issue-review workflow is repository code under `examples/lda_report_workflow`. It is richer than the thesis’s documented three-node deterministic report case study. Call it a later demonstration built on the same platform, not the exact thesis case study.
|
||||
This later issue-review example is richer than the thesis case study; do not present its issue-board output as thesis output. Diagnostics support a repair loop but do not guarantee automatic repair.
|
||||
|
||||
### Scene 10: Start the prepared workflow
|
||||
### Scene 9: Start the prepared workflow
|
||||
|
||||
**Route:** `run-from-deployment/input`, `run-from-deployment/operation`, then `run-from-deployment/graph`
|
||||
**Time:** 6:35-7:10
|
||||
**Time:** 5:50-6:25
|
||||
**Evidence:** Implementation extension; live-capable
|
||||
|
||||
Say:
|
||||
@@ -150,10 +138,10 @@ Say:
|
||||
|
||||
If live execution has not been completed during rehearsal, say: “The operation view is replay-backed evidence of the prepared path. I am not presenting this as a newly completed live run.”
|
||||
|
||||
### Scene 11: Present a typed interrupt, not a production approval system
|
||||
### Scene 10: Present a typed interrupt, not a production approval system
|
||||
|
||||
**Route:** `typed-human-boundary/interrupt` then `typed-human-boundary/approval`
|
||||
**Time:** 7:10-7:40
|
||||
**Time:** 6:25-6:55
|
||||
**Evidence:** Implementation extension; qualify
|
||||
|
||||
Say:
|
||||
@@ -162,22 +150,22 @@ Say:
|
||||
|
||||
Do not call the negative path “deny without resuming.” Both outcomes resume execution through different workflow branches. Do not imply that the prepared revision recording preserves the submitted branch’s run identity.
|
||||
|
||||
### Scene 12: Show output and inspectable evidence
|
||||
### Scene 11: Show output and inspectable evidence
|
||||
|
||||
**Route:** `resume-output-evidence/resume`, `resume-output-evidence/output`, then `resume-output-evidence/trace`
|
||||
**Time:** 7:40-8:30
|
||||
**Time:** 6:55-7:45
|
||||
**Evidence:** Implementation extension; replay continuity differs by branch
|
||||
|
||||
Say:
|
||||
|
||||
> On the submitted path, workflow.runs.resume continues the recorded interrupted Run. The workflow creates the report and issue-board changes, then records terminal output. Trace frames and protocol evidence remain inspectable; this is declared-boundary resumability, not arbitrary crash recovery or exactly-once execution. The revision replay is a separate prepared recording.
|
||||
|
||||
For the submitted replay, the same run ID is demonstrated. The prepared revision replay currently uses `run_recorded_lda_report_revision`; describe it as a separate prepared branch recording. The thesis itself documents a separate three-node report case study without issue-board mutation, so identify these issue-board results as evidence from the later example implementation.
|
||||
For the submitted replay, the same run ID is demonstrated. The prepared revision replay currently uses `run_recorded_lda_report_revision`; describe it as a separate prepared branch recording.
|
||||
|
||||
### Scene 13: Explain what the evaluation proves
|
||||
### Scene 12: Explain what the evaluation proves
|
||||
|
||||
**Route:** `evaluation/cohort`, `evaluation/validity`, then `evaluation/findings`
|
||||
**Time:** 8:30-10:30
|
||||
**Time:** 7:45-9:45
|
||||
**Evidence:** Supported, with strict qualification
|
||||
|
||||
Say:
|
||||
@@ -186,10 +174,10 @@ Say:
|
||||
|
||||
The product and prompts evolved across waves. Call this longitudinal engineering evidence, not a controlled benchmark ([lines 1287-1339](../thesis/system-design-implementation.md#formative-agent-trial-findings)).
|
||||
|
||||
### Scene 14: Close on the bounded contribution
|
||||
### Scene 13: Close on the bounded contribution
|
||||
|
||||
**Route:** `conclusion/limits`, `conclusion/future`, `conclusion/conclusion`, then `conclusion/questions`
|
||||
**Time:** 10:30-11:45
|
||||
**Time:** 9:45-11:00
|
||||
**Evidence:** Supported
|
||||
|
||||
Say:
|
||||
@@ -316,5 +304,5 @@ Start with the short answer. Expand only when the examiner continues.
|
||||
## Presentation defects to resolve or avoid
|
||||
|
||||
- The thesis’s deterministic report case study has three workflow nodes. The later presentation example has eleven plan nodes, while its simplified graph intentionally omits the terminal `end_cancelled` marker. Avoid quoting a graph-node count unless the distinction is relevant.
|
||||
- The live health probe does not establish a completed live Scene 10-12 rehearsal. Label replay-backed output and trace evidence as recorded.
|
||||
- The live health probe does not establish a completed live Scene 9-11 rehearsal. Label replay-backed output and trace evidence as recorded.
|
||||
- The revision replay has a separate run ID. Never use the submitted branch’s “same persisted run” wording for that branch.
|
||||
|
||||
@@ -32,9 +32,9 @@ factual or product follow-up rather than silently treating it as solved.
|
||||
| Scene 1 opening | Product goal, implementation boundary, and planner/tool-surface/runner decomposition are distinct. The opening caption remains editorial and borderless; its row sizes to content instead of clipping the lower padding. |
|
||||
| Scene 5 to 7 story | Lifecycle vocabulary now leads into authoring and repair rather than presenting authoring as an isolated diagnostic screen. |
|
||||
| Scenes 7 and 9 | Authoring and prepared-lifecycle evidence use a dominant artifact with secondary assistant/support surfaces. |
|
||||
| Scene 10 graph | The graph is horizontal, factual, selectable, draggable/zoomable, and fit to the initialized React Flow viewport. Outcome shapes and edge labels remain visible. |
|
||||
| Scene 13 findings | Six findings use a readable 3x2 layout with icons, campaign size, outcome counts, and the bounded-evidence statement visible together. |
|
||||
| Scene 14 conclusion | The typed substrate and closing boundary are dominant; non-claims and future-work layers recede without being removed from their own beats. |
|
||||
| Scene 9 graph | The graph is horizontal, factual, selectable, draggable/zoomable, and fit to the initialized React Flow viewport. Outcome shapes and edge labels remain visible. |
|
||||
| Scene 12 findings | Six findings use a readable 3x2 layout with icons, campaign size, outcome counts, and the bounded-evidence statement visible together. |
|
||||
| Scene 13 conclusion | The typed substrate and closing boundary are dominant; non-claims and future-work layers recede without being removed from their own beats. |
|
||||
|
||||
## Remaining Findings
|
||||
|
||||
@@ -50,7 +50,7 @@ factual or product follow-up rather than silently treating it as solved.
|
||||
|
||||
### PRODUCT
|
||||
|
||||
- Live Scene 10-12 execution is health-checked and connectable, but still needs
|
||||
- Live Scene 9-11 execution is health-checked and connectable, but still needs
|
||||
a complete rehearsed start -> interrupt -> resume -> output -> trace path on
|
||||
the running workflow server.
|
||||
- The presentation chat remains a scripted/replay product surface. A live LLM
|
||||
|
||||
@@ -21,15 +21,15 @@ rehearsal pass.
|
||||
|---|---|---|---|---|---|
|
||||
| PASS | 1280x720 | replay | `/present#scene/agent-handoff/request` | Open the request route and click `Send`. | The prepared conversation appears with the user request, assistant narration, and four discovery tool calls; no run is claimed. |
|
||||
| PASS | 1280x720, 1024x768 | replay | `/present#scene/typed-human-boundary/approval` | Open the approval route. | The input files, typed interrupt payload, proposed issue, resume comment, `Submit`, and `Request revision` controls are visible. The footer reports `Run paused - review required`. |
|
||||
| PASS | 1280x720 | replay | `/present#scene/prepared-lifecycle/{discover,draft,validate,artifact,deployment}` | Open each Scene 9 beat directly. | The phase rail advances through Discover, Draft, Validate, Artifact, and Deployment; staged chat groups and factual evidence change with each beat. |
|
||||
| PASS | 1280x720 | replay | `/present#scene/run-from-deployment/operation` | Open the Scene 10 operation beat. | `workflow.runs.start` is shown as interrupted with deployment, run ID, and `issue_review` boundary; the prepared-workflow action is available in the footer. |
|
||||
| PASS | 1280x720 | replay | Scene 11 -> Scene 12 | Click `Submit`. | The route changes to `resume`; the output shows `submitted`, `approved: true`, selected issue `risk-1`, and a created issue. |
|
||||
| FACTUAL | 1280x720 | replay | Scene 11 -> Scene 12 | Reload approval and click `Request revision`. | The route changes to `resume` and shows `cancelled`, `approved: false`, no selected issues, and a revision report. The replay uses `run_recorded_lda_report_revision`, so it does not preserve the submitted branch's run ID despite the same-run wording. |
|
||||
| PASS | 1280x720 | replay | `/present#scene/prepared-lifecycle/{discover,draft,diagnose,repair,artifact,deployment}` | Open each Scene 8 beat directly. | The phase rail advances through Discover, Draft, Diagnose, Repair, Artifact, and Deployment; staged chat groups and factual evidence change with each beat. |
|
||||
| PASS | 1280x720 | replay | `/present#scene/run-from-deployment/operation` | Open the Scene 9 operation beat. | `workflow.runs.start` is shown as interrupted with deployment, run ID, and `issue_review` boundary; the prepared-workflow action is available in the footer. |
|
||||
| PASS | 1280x720 | replay | Scene 10 -> Scene 11 | Click `Submit`. | The route changes to `resume`; the output shows `submitted`, `approved: true`, selected issue `risk-1`, and a created issue. |
|
||||
| FACTUAL | 1280x720 | replay | Scene 10 -> Scene 11 | Reload approval and click `Request revision`. | The route changes to `resume` and shows `cancelled`, `approved: false`, no selected issues, and a revision report. The replay uses `run_recorded_lda_report_revision`, so it does not preserve the submitted branch's run ID despite the same-run wording. |
|
||||
| PASS | 1280x720, 1024x768 | replay | `/present#scene/resume-output-evidence/trace` | Open the trace beat after the decision branches. | Recorded execution frames render, including `review_issues` interrupt/continuation and `end_cancelled`; the UI exposes the evidence inspector. |
|
||||
| PASS | 1024x768 | fallback | `/present#scene/typed-human-boundary/approval` | Set the presentation target to `http://127.0.0.1:1/rpc` and reload. | The approval route remains usable with the replay-backed payload and decision form; no live-ready badge is shown. The browser session target was restored afterward. |
|
||||
| PASS | command line | live health | `/api/health` | Request the web-server health endpoint. | `200` with `{"ok":true,"status":"ok"}`. |
|
||||
| PASS | command line | live health | `/api/connect` -> `http://127.0.0.1:8765/rpc` | POST the configured RPC target to the web server. | `workflow.health` returned `status: ok`, a store root, and equivalent CLI `uv run wf status`. |
|
||||
| BLOCKED | 1280x720 | live end-to-end | Scene 10 -> Scene 12 | Start the prepared run, submit the approval form, and inspect output/trace against the live server. | Live health is verified, but a complete stateful live browser path was not completed in this rehearsal. Do not claim live output or trace success. |
|
||||
| BLOCKED | 1280x720 | live end-to-end | Scene 9 -> Scene 11 | Start the prepared run, submit the approval form, and inspect output/trace against the live server. | Live health is verified, but a complete stateful live browser path was not completed in this rehearsal. Do not claim live output or trace success. |
|
||||
|
||||
### Operator Interpretation
|
||||
|
||||
@@ -45,7 +45,7 @@ the defense unless the full stateful live path is rehearsed separately.
|
||||
|
||||
1. Decide whether the revision branch should preserve the submitted branch's
|
||||
run identity or be presented as a separate prepared recording.
|
||||
2. With the example server running, start from the Scene 10 footer action and
|
||||
2. With the example server running, start from the Scene 9 footer action and
|
||||
record the live run ID, approval payload, submitted/revision-requested
|
||||
outcome, output, and trace frames.
|
||||
3. Keep the unavailable-target fallback check in the pre-defense checklist so
|
||||
|
||||
@@ -32,12 +32,12 @@ can be shown after selecting replay with the runbook's session-storage switch.
|
||||
| `architecture/api` | JSON-RPC handles transport concerns and delegates to WorkflowApi rather than owning domain behavior. | Architecture API node | Client operations | hidden | replay-only; Thesis System Architecture; `docs/project_map.md`; `docs/source_architecture.md` | `architecture/api` |
|
||||
| `architecture/runtime` | Server composition supplies stores, provider projections, and the runtime while the core remains independent of MCP and Python behavior. | Runtime/providers focus | Architecture overview | hidden | replay-only; Thesis System Architecture; `docs/project_map.md`; `docs/source_architecture.md` | `architecture/runtime` |
|
||||
| `agent-handoff/request` | I will now show a prepared demonstration built on this platform. The chat is a presentation interface, not the autonomous planner evaluated by the thesis. The chat translates a report request into the same public lifecycle operations an external agent could call. This prepared path demonstrates product behavior and recorded evidence, not a fresh model-performance result. | Agent request surface | Workflow substrate framing | hidden | replay-only; Constrained demo agent and prepared replay recipe | `agent-handoff/request` |
|
||||
| `prepared-lifecycle/discover` | The later issue-review example first inspects configured local.lda_docs, report, and issue-board capabilities. | Prepared lifecycle: discovery | Capability/schema evidence | hidden | replay-only; `examples/lda_report_workflow`; deployment inspect replay evidence | `prepared-lifecycle/discover` |
|
||||
| `prepared-lifecycle/draft` | It creates and edits a Draft for report generation, making the proposal visible before execution. | Prepared lifecycle: draft | Workflow definition | hidden | replay-only; `examples/lda_report_workflow`; deployment inspect replay evidence | `prepared-lifecycle/draft` |
|
||||
| `prepared-lifecycle/diagnose` | Validation returns structured diagnostics, affected paths, repair hints, and suggested next actions. | Diagnostic receipt | Draft authoring surface | hidden | replay-only; `examples/lda_report_workflow`; deployment inspect replay evidence | `prepared-lifecycle/diagnose` |
|
||||
| `prepared-lifecycle/repair` | These surfaces make invalid intermediate drafts repairable; they support a loop, but no hint guarantees success. | Repair guidance | Diagnostic receipt | hidden | replay-only; `examples/lda_report_workflow`; deployment inspect replay evidence | `prepared-lifecycle/repair` |
|
||||
| `prepared-lifecycle/discover` | It inspects sources, capabilities, and schemas rather than guessing at hidden interfaces. | Prepared lifecycle: discovery | Capability/schema evidence | hidden | replay-only; `examples/lda_report_workflow`; deployment inspect replay evidence | `prepared-lifecycle/discover` |
|
||||
| `prepared-lifecycle/draft` | Focused operations modify mutable authoring state before execution. | Prepared lifecycle: draft | Workflow definition | hidden | replay-only; `examples/lda_report_workflow`; deployment inspect replay evidence | `prepared-lifecycle/draft` |
|
||||
| `prepared-lifecycle/diagnose` | Structured diagnostics identify the missing output projection. | Diagnostic receipt | Draft authoring surface | hidden | replay-only; `examples/lda_report_workflow`; deployment inspect replay evidence | `prepared-lifecycle/diagnose` |
|
||||
| `prepared-lifecycle/repair` | One focused output-map edit resolves it; hints do not guarantee automatic repair. | Repair guidance | Diagnostic receipt | hidden | replay-only; `examples/lda_report_workflow`; deployment inspect replay evidence | `prepared-lifecycle/repair` |
|
||||
| `prepared-lifecycle/artifact` | It saves the validated plan as immutable artifact lda_report_case_study version 1. | Prepared lifecycle: artifact | Lifecycle state | hidden | replay-only; `examples/lda_report_workflow`; deployment inspect replay evidence | `prepared-lifecycle/artifact` |
|
||||
| `prepared-lifecycle/deployment` | 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. | Prepared lifecycle: deployment | Binding/readiness evidence | hidden | replay-only; `examples/lda_report_workflow`; deployment inspect replay evidence | `prepared-lifecycle/deployment` |
|
||||
| `prepared-lifecycle/deployment` | Deployment binds and validates three local sources; execution starts in the next scene. | Prepared lifecycle: deployment | Binding/readiness evidence | hidden | replay-only; `examples/lda_report_workflow`; deployment inspect replay evidence | `prepared-lifecycle/deployment` |
|
||||
| `run-from-deployment/input` | The deployment receives selected local documents and an issue-board path. | Workflow input panel | Prepared deployment | hidden | live-capable; `workflow.runs.start` replay evidence | `prepared-lifecycle/deployment` |
|
||||
| `run-from-deployment/operation` | The public workflow.runs.start operation validates the deployment and input, creates a persisted Run, and begins the reusable graph. | Start operation | Workflow graph | hidden | explicit run; `workflow.runs.start` replay evidence | `run-from-deployment/operation` |
|
||||
| `run-from-deployment/graph` | The graph reads documents, analyzes them, builds a report, drafts proposed issues, and pauses at a declared review interrupt before issue-board changes. | Workflow graph | Run operation receipt | hidden | live-capable; `workflow.runs.start` replay evidence | `run-from-deployment/operation` |
|
||||
|
||||
@@ -5,7 +5,7 @@ Audit date: 2026-07-13. This review uses the complete
|
||||
[rehearsal log](presentation-rehearsal-log.md), the
|
||||
[presentation runbook](defense-presentation.md), the
|
||||
[Q&A runbook](defense-qna.md), and the locally available private narrative
|
||||
notes in `random shit/`. The matrix covers all 14 scenes; the log records
|
||||
notes in `random shit/`. The matrix covers all 13 scenes; the log records
|
||||
targeted replay/fallback checks and does not establish a completed live
|
||||
end-to-end run.
|
||||
|
||||
@@ -42,54 +42,48 @@ end-to-end run.
|
||||
- Next action: keep
|
||||
|
||||
### Scene 6 — Architecture Zoom
|
||||
- Audience takeaway: The same public surface reaches API, runtime/providers, stores, and a typed NodeUse execution.
|
||||
- Visible proof: Client, API, runtime, and NodeUse focus beats provide a semantic zoom with package and operation evidence.
|
||||
- Missing or confusing: Four nested levels risk becoming a component tour unless each level answers what responsibility moves inward.
|
||||
- Audience takeaway: The same public surface reaches API, runtime/providers, stores, and the execution kernel.
|
||||
- Visible proof: Client, API, and runtime focus beats provide a semantic zoom with package and operation evidence.
|
||||
- Missing or confusing: Three nested levels risk becoming a component tour unless each level answers what responsibility moves inward. NodeUse remains an optional deep dive.
|
||||
- Next action: keep
|
||||
|
||||
### Scene 7 — Author, Validate, Repair
|
||||
- Audience takeaway: Discovery and structured diagnostics reduce agent guessing during workflow authoring.
|
||||
- Visible proof: Discover, author, diagnose, and repair beats show the operation loop and repair guidance.
|
||||
- Missing or confusing: The repair result should be verbally connected to the valid artifact, not treated as another isolated tool call.
|
||||
- Next action: keep
|
||||
|
||||
### Scene 8 — Agent Request
|
||||
### Scene 7 — Agent Request
|
||||
- Audience takeaway: A thin external-agent surface can request work without pretending to execute it.
|
||||
- Visible proof: Send reveals the prepared conversation and four discovery tool calls with no run claim.
|
||||
- Visible proof: Send reveals the prepared conversation and discovery tool calls with no run claim.
|
||||
- Missing or confusing: The chat surface could be mistaken for the thesis product unless the substrate remains the stated center.
|
||||
- Next action: keep
|
||||
|
||||
### Scene 9 — Prepared Workflow Lifecycle
|
||||
- Audience takeaway: The request is translated into Discover, Draft, Validate, Artifact, and Deployment stages.
|
||||
- Visible proof: The phase rail, staged messages, and changing factual evidence advance across all five beats.
|
||||
- Missing or confusing: Deployment records a local run request but does not execute; that boundary needs an explicit spoken pause.
|
||||
### Scene 8 — Prepared Workflow Lifecycle
|
||||
- Audience takeaway: The request becomes six concise authoring stages: Discover, Draft, Diagnose, Repair, Artifact, and Deployment.
|
||||
- Visible proof: The phase rail, staged messages, structured diagnostic, focused output-map edit, and changing factual evidence advance across all six beats.
|
||||
- Missing or confusing: Deployment binds and validates three local sources but does not execute; that boundary needs an explicit spoken pause.
|
||||
- Next action: keep
|
||||
|
||||
### Scene 10 — Run From Deployment
|
||||
### Scene 9 — Run From Deployment
|
||||
- Audience takeaway: Execution starts from a ready deployment through a public run operation.
|
||||
- Visible proof: Input, operation, and graph beats show selected inputs, `workflow.runs.start`, a run ID, and the typed boundary.
|
||||
- Missing or confusing: The live end-to-end path was blocked, so live output must not be implied from the replay-backed operation view.
|
||||
- Next action: factual fix
|
||||
- Next action: keep
|
||||
|
||||
### Scene 11 — Typed Human Boundary
|
||||
### Scene 10 — Typed Human Boundary
|
||||
- Audience takeaway: A persisted run pauses at a typed issue-review decision with explicit submitted and revision-requested outcomes.
|
||||
- Visible proof: Interrupt payload, selected issue, comment field, and both decision controls are visible in replay.
|
||||
- Missing or confusing: The revision replay uses `run_recorded_lda_report_revision`, so “same run” wording is false for that branch.
|
||||
- Next action: factual fix
|
||||
|
||||
### Scene 12 — Resume, Output, Evidence
|
||||
### Scene 11 — Resume, Output, Evidence
|
||||
- Audience takeaway: A decision leads to inspectable output and trace evidence for the workflow run.
|
||||
- Visible proof: Resume, output, and trace beats show status, report/issue result, interrupt continuation, and terminal frames.
|
||||
- Missing or confusing: Submitted replay continuity is demonstrated; live continuity and revision same-run continuity are not yet established.
|
||||
- Next action: factual fix
|
||||
|
||||
### Scene 13 — Evaluation
|
||||
### Scene 12 — Evaluation
|
||||
- Audience takeaway: The 36 trials are bounded engineering evidence about operability and UX failure modes.
|
||||
- Visible proof: Cohort, validity, and findings beats separate audited evidence from benchmark-style claims.
|
||||
- Missing or confusing: The evaluation arrives after demo evidence, so the presenter must state that failures motivate the product-surface argument.
|
||||
- Next action: keep
|
||||
|
||||
### Scene 14 — Limits and Conclusion
|
||||
### Scene 13 — Limits and Conclusion
|
||||
- Audience takeaway: The contribution is a useful substrate, not a production agent, scheduler, or broad benchmark.
|
||||
- Visible proof: Limits, future, conclusion, and questions beats distinguish implemented core from future layers.
|
||||
- Missing or confusing: Q&A must not begin before the contribution sentence and limitations have landed.
|
||||
@@ -101,19 +95,19 @@ end-to-end run.
|
||||
|
||||
- Scene 1 -> 2 works: the goal becomes the missing reusable-automation contracts.
|
||||
- Scene 5 -> 6 works if Deployment is the handoff: lifecycle vocabulary becomes the architecture that owns it.
|
||||
- Scene 7 -> 8 works: authoring/repair operations become a thin external-agent request surface.
|
||||
- Scene 8 -> 9 works and is not a duplicate: request/discovery becomes staged lifecycle evidence.
|
||||
- Scene 9 -> 10 is the critical boundary: Deployment prepares; Scene 10 alone starts execution. Keep the explicit no-run wording.
|
||||
- Scene 10 -> 11 -> 12 works as one climax in replay, but the revision branch has a factual run-identity defect and the live path is blocked.
|
||||
- Scene 13 -> 14 works: evaluation limits become the contribution and future-work close.
|
||||
- Scene 6 -> 7 works: architecture hands off to a bounded prepared request surface.
|
||||
- Scene 7 -> 8 works and is not a duplicate: request/discovery becomes staged lifecycle evidence.
|
||||
- Scene 8 -> 9 is the critical boundary: Deployment prepares; Scene 9 alone starts execution. Keep the explicit no-run wording.
|
||||
- Scene 9 -> 10 -> 11 works as one climax in replay, but the revision branch has a factual run-identity defect and the live path is blocked.
|
||||
- Scene 12 -> 13 works: evaluation limits become the contribution and future-work close.
|
||||
|
||||
### Order, Duplicated Beats, And Q&A
|
||||
|
||||
The 14-scene order is coherent: motivation, positioning, boundary, vocabulary,
|
||||
architecture, authoring, then demo proof, evaluation, and limits. No duplicated
|
||||
demo beat was found. Scene 8 introduces the request, Scene 9 owns authoring and
|
||||
deployment, Scene 10 owns run activation, Scene 11 owns the decision, and Scene
|
||||
12 owns resume/output/trace. The Q&A branch belongs after Scene 14's Questions
|
||||
The 13-scene order is coherent: motivation, positioning, boundary, vocabulary,
|
||||
architecture, request, authoring, then demo proof, evaluation, and limits. No duplicated
|
||||
demo beat was found. Scene 7 introduces the request, Scene 8 owns authoring and
|
||||
deployment, Scene 9 owns run activation, Scene 10 owns the decision, and Scene
|
||||
11 owns resume/output/trace. The Q&A branch belongs after Scene 13's Questions
|
||||
beat; opening a prepared branch earlier would interrupt the argument and make a
|
||||
discussion answer look like core evidence.
|
||||
|
||||
@@ -122,7 +116,7 @@ discussion answer look like core evidence.
|
||||
- **Factual:** The revision-requested replay has a separate run ID while the
|
||||
surrounding same-run wording suggests continuity. Correct the recording or
|
||||
label that branch explicitly as a separate prepared recording.
|
||||
- **Factual:** The live health boundary passed, but live Scene 10 -> 12 was
|
||||
- **Factual:** The live health boundary passed, but live Scene 9 -> 11 was
|
||||
blocked. Do not present live output or trace as rehearsed evidence.
|
||||
- **Visual:** No visual defect was recorded in the available rehearsal log. The
|
||||
matrix remains the acceptance checklist for both `1280x720` and `1024x768`.
|
||||
|
||||
@@ -69,27 +69,28 @@ pnpm --filter @lda/console build
|
||||
|
||||
Screenshots require human approval and are not pixel-diff tests.
|
||||
|
||||
## Scene 9 Staged Message Review
|
||||
## Scene 8 Staged Message Review
|
||||
|
||||
Review these five deep links at `1280x720` and `1024x768`, at 100% zoom:
|
||||
Review these six deep links at `1280x720` and `1024x768`, at 100% zoom:
|
||||
|
||||
- `/present#scene/prepared-lifecycle/discover`
|
||||
- `/present#scene/prepared-lifecycle/draft`
|
||||
- `/present#scene/prepared-lifecycle/validate`
|
||||
- `/present#scene/prepared-lifecycle/diagnose`
|
||||
- `/present#scene/prepared-lifecycle/repair`
|
||||
- `/present#scene/prepared-lifecycle/artifact`
|
||||
- `/present#scene/prepared-lifecycle/deployment`
|
||||
|
||||
Confirm that one labelled textarea remains visible in every phase, is empty in
|
||||
Discover and Validate, and contains the exact prepared prompt in Draft,
|
||||
Discover, and contains the exact prepared prompt in Draft, Diagnose, Repair,
|
||||
Artifact, and Deployment. Confirm the right phase projection remains dominant,
|
||||
the panes do not overlap, and `document.documentElement.scrollHeight` equals
|
||||
`clientHeight`. Reload direct hashes before capture: in dev mode, immediate
|
||||
screenshots during an in-place hash transition can catch the presentation
|
||||
animation between surfaces even though the settled/reloaded route is correct.
|
||||
|
||||
Edit and Send in Draft, then verify Validate contains that exact edited user
|
||||
turn. Repeat from Artifact to Deployment. On Deployment, Send must show only
|
||||
Edit and Send in Draft, then verify Diagnose and Repair contain that exact edited
|
||||
user turn. Repeat from Artifact to Deployment. On Deployment, Send must show only
|
||||
`Run request prepared for the next execution slice.`; compare `/api/rpc`
|
||||
request counts before and after to confirm no execution call was made. Scenes
|
||||
10–12 own the subsequent run activation and live execution path; do not use
|
||||
Scene 9 to claim a run has started.
|
||||
9–11 own the subsequent run activation and live execution path; do not use
|
||||
Scene 8 to claim a run has started.
|
||||
|
||||
Reference in New Issue
Block a user