docs: define opening and rehearsal presentation slices
This commit is contained in:
@@ -0,0 +1,76 @@
|
||||
# Defense Presentation Rehearsal Design
|
||||
|
||||
## Status
|
||||
|
||||
Proposed implementation slice for the operational path of the React defense
|
||||
presentation.
|
||||
|
||||
## Purpose
|
||||
|
||||
The presentation must be rehearsable as a deterministic defense artifact. The
|
||||
presenter needs one documented live path, one documented replay path, and clear
|
||||
expected evidence for both submitted and revision-requested decisions.
|
||||
|
||||
## Scope
|
||||
|
||||
This slice hardens documentation and repeatable verification. It does not add a
|
||||
real LLM, a remote presenter companion, a new workflow server transport, or new
|
||||
presentation story content.
|
||||
|
||||
## Live Path
|
||||
|
||||
With `wf-rpc-server` running against `examples/lda_report_workflow/wf.config.json`
|
||||
and the presentation target set to `http://127.0.0.1:8765/rpc`, the rehearsal
|
||||
path is:
|
||||
|
||||
1. Open Scene 8 at `#scene/agent-handoff/request`.
|
||||
2. Use the visible `Run prepared workflow` action.
|
||||
3. Advance through the prepared lifecycle and run scenes to the typed approval.
|
||||
4. Choose all issue rows or a deliberate subset, add a comment, and submit.
|
||||
5. Confirm the same run continues into output and trace proof.
|
||||
|
||||
The expected submitted branch has a completed run, generated report output,
|
||||
created issues for the chosen rows, and trace frames for the completed path.
|
||||
|
||||
## Revision-Requested Path
|
||||
|
||||
`Request revision` is a valid resume decision, not a terminal cancellation. It
|
||||
must call `workflow.runs.resume` on the same run with `approved: false`, then
|
||||
continue to its negative output and trace branch. Its expected evidence is:
|
||||
|
||||
- protocol outcome `cancelled`;
|
||||
- presentation wording `Revision requested`;
|
||||
- no created issues;
|
||||
- output headed `Revision Requested`;
|
||||
- trace records that include `revision_requested` and `end_cancelled`.
|
||||
|
||||
## Replay And Failure Path
|
||||
|
||||
The committed replay remains the fallback when the health probe or live RPC
|
||||
operation fails. The runbook must state how to choose replay before a defense,
|
||||
how to recognize the replay truth badge, and that no time should be spent
|
||||
debugging a port during the defense.
|
||||
|
||||
## Verification Contract
|
||||
|
||||
Automated route-level coverage must exercise:
|
||||
|
||||
- live target readiness and visible start affordance;
|
||||
- a submitted approval that advances to same-run output/trace;
|
||||
- a revision-requested approval that also advances to same-run negative
|
||||
output/trace;
|
||||
- replay fallback when the target fails health checking.
|
||||
|
||||
The runbook must add an operator checklist that names the exact startup
|
||||
commands, deep links, expected screen states, reset procedure, and fallback
|
||||
statement.
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
1. A new operator can rehearse both decision branches without reconstructing
|
||||
the intended state from source code.
|
||||
2. Documentation distinguishes the product-visible revision request from the
|
||||
protocol-level `cancelled` outcome.
|
||||
3. Browser-level or route-level tests guard both branches and replay fallback.
|
||||
4. The live path remains optional; a failed target cannot block a replay-based
|
||||
defense.
|
||||
@@ -0,0 +1,77 @@
|
||||
# Presentation Opening Title Design
|
||||
|
||||
## Status
|
||||
|
||||
Proposed implementation slice. This document replaces the earlier Scene 1
|
||||
assumption that its opening visual pass is complete.
|
||||
|
||||
## Purpose
|
||||
|
||||
Scene 1 must introduce the thesis as an agent-shaped product goal without
|
||||
trying to explain the automation problem before Scene 2. It should tell the
|
||||
audience what the title means and precisely identify the implemented part.
|
||||
|
||||
## Narrative Boundary
|
||||
|
||||
- Scene 1 answers: What is the product goal, and which part is implemented?
|
||||
- Scene 2 answers: Why are direct agent actions not reusable automation?
|
||||
- Scene 1 must not use a generic label such as `Thesis` or `Decomposed` as its
|
||||
dominant display copy.
|
||||
- Scene 1 must not lead with the workflow substrate's detailed benefits. Those
|
||||
belong to Scene 2 and later lifecycle/architecture scenes.
|
||||
|
||||
## Composition
|
||||
|
||||
The scene retains the compact formal title `Design and Implementation of
|
||||
lda.chat` in the stage caption. Its main focal copy is:
|
||||
|
||||
> An AI Agent for Workspace Workflows
|
||||
|
||||
Under it, one connected horizontal system shows three roles in sequence:
|
||||
|
||||
```text
|
||||
Planner -> Tool surface -> Runner / platform
|
||||
```
|
||||
|
||||
The roles are structural parts of one agent-shaped product, not independent
|
||||
feature cards. Their labels and supporting examples are:
|
||||
|
||||
| Role | Supporting label |
|
||||
|---|---|
|
||||
| Planner | Codex, Claude, OpenCode |
|
||||
| Tool surface | CLI, MCP, JSON-RPC |
|
||||
| Runner / platform | workflow lifecycle and deterministic execution |
|
||||
|
||||
The first beat keeps the three roles equally legible. The second beat enlarges
|
||||
and visually selects `Runner / platform`, retains the other two roles as
|
||||
connected context, and adds the exact label `Implemented contribution`.
|
||||
|
||||
The selected role may expose a short, factual scope line: `Lifecycle,
|
||||
validation, records, traces, and interrupt/resume`. It must remain supporting
|
||||
copy, not a second oversized headline.
|
||||
|
||||
## Visual Direction
|
||||
|
||||
- Use the existing editorial canvas, presentation type, and one cyan active
|
||||
accent. Do not introduce a new theme or blue decorative treatment.
|
||||
- Use the existing concept icon vocabulary only when it reinforces each role;
|
||||
the connection line and role hierarchy are the primary visual structure.
|
||||
- Avoid three same-weight card panels. The system must visibly read left to
|
||||
right, with a meaningful destination at `Runner / platform`.
|
||||
- At 1280x720, the main title and all three role names must be readable without
|
||||
competing with the stage caption, discussion rail, or footer.
|
||||
- Motion is limited to a short role-focus transition between beats. Reduced
|
||||
motion uses the final static state.
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
1. The first beat's largest text is `An AI Agent for Workspace Workflows`.
|
||||
2. Neither `Thesis` nor `Decomposed` is rendered as a display heading.
|
||||
3. The role sequence renders as connected agent context, not three detached
|
||||
cards.
|
||||
4. The second beat labels only `Runner / platform` as `Implemented
|
||||
contribution` and keeps planner/tool surface visible as context.
|
||||
5. Scene 2 remains responsible for the direct-actions-versus-reusable-
|
||||
automation argument.
|
||||
6. Unit tests cover both beats' focus and display copy; browser screenshots at
|
||||
1280x720 cover both beats without clipping.
|
||||
Reference in New Issue
Block a user