@aicopycoders/exodus 2026.9.2000-beta.8 → 2026.9.2000

package/assets/docs/CLAUDE.md

@@ -83,6 +83,7 @@ These are not pipelines. They are Luke's methods written as skills, so the think
 | `find-competitors` | Who is actually strong in a niche, on Meta first and Amazon second. Ranked competitor sheet and a watch list. Optional scripts for Atria and the Meta Ad Library via Apify (each needs its own key; they bill per result and say the plan back before spending). |
 | `patterns-and-gaps` | What repeats and matters across own ads, competitor ads, organic content, and research, read layer by layer, and the three kinds of gap. |
 | `anatomy-of-ads` | The parts list of an ad (Messaging × Creative). Write a brief, dissect any ad into the same parts, tag a batch so patterns can be counted. Also the vocabulary the other skills use. |
+| `swipe` | Swipe a winning ad for the active brand at one of three closeness levels (1 same scene, 2 new scene same beats, 3 same bones new drama). Gathers the ad, product, and level, then calls the `swipe-narrative-agent` Genesis bot (needs `GENESIS_API_KEY` plus a provider key). |
 | `copy-instincts` | See, Attract, Make. Run on a draft that already exists (hook, ad, mechanism paragraph) to take it from good to great. |
 | `bot-builder` | Build a custom bot the way Luke and Mario build the Genesis bots (SEAK), and put it where it runs: an Exodus workflow Prompt node, a Genesis bot, or a skill. |
 | `remember-that` | Bank one reaction mid-session ("remember that", "never do X") into `STANDARDS.md`, and push approved winning lines to the matching Exodus bank. |

package/assets/skills/exodus-primer/SKILL.md

@@ -52,7 +52,7 @@ Cheap, one query. It tells you whether this brand already has a primer.
 - **✗ Not ready** — no primer yet. Proceed to Step 1.
 - **✓ Ready** — a primer is already saved. **Don't rebuild blind.** Surface it and offer the lighter moves first:
   - `npx @aicopycoders/exodus primer show` — print the saved primer so the user can see what's there.
-  - Rebuild only if the user explicitly wants to replace it (they've got better winning ads, the product changed). A rebuild *replaces* the existing primer.
+  - Rebuild only if the user explicitly wants a newer one (they've got better winning ads, the product changed). A rebuild adds a new primer and makes it your default; the old one stays in your list.
 
 This follows the same "check first, don't re-ask" discipline as the `exodus-foundation` skill. Use the status result to decide what to do — don't open by asking the user where they want to start.
 
@@ -67,11 +67,16 @@ WHO IT'S FOR:
 OFFER / PRICE (optional):
 PROOF / NUMBERS (optional):
 
-WINNING ADS (paste 10, full copy; fewer is OK — tell me if you have none):
---- Ad 1: …
---- Ad 2: …
+WINNING ADS (paste 10, full copy; fewer is OK — tell me if you have none).
+Paste each ad on the lines under its "--- Ad N:" line, and leave that line as it is:
+--- Ad 1:
+(ad 1, full copy)
+--- Ad 2:
+(ad 2, full copy)
 ```
 
+Leave nothing after "Ad 1:" — no name or title. The builder names every ad itself, and text on that line would have to be guessed as either a name or the ad's first line.
+
 State plainly that the product facts matter as much as the ads — the winning ads frequently don't name the product, and you will **not** invent it. If the user says they have *no* winning ads, stop here and jump to the **No-Ads Branch** below; don't push them to manufacture examples.
 
 ### Step 2 — Assemble the submission
@@ -86,7 +91,7 @@ npx @aicopycoders/exodus primer --file state/primer-submission.md --yes
 
 The build reads every ad and writes the full module taxonomy. **The `--yes` is load-bearing in Claude Code:** without it, the final "accept & save" prompt silently no-ops in the non-TTY shell and the primer is never saved (the symptom that forced a `printf 'a\n' |` hack before this flag existed). With `--yes`, the command builds and saves in one shot and prints the same `✓ saved` / `✓ ready` output.
 
-If a primer already exists, `--yes` rebuilds in place (replaces it) rather than prompting — which is what you want when the user has explicitly asked to rebuild.
+If a primer already exists, `--yes` builds and saves without prompting — which is what you want when the user has explicitly asked to rebuild. It adds a new primer and makes it your default; the old one stays in your list.
 
 ### Step 4 — Verify
 

package/assets/skills/exodus-video/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: exodus-video
-description: Make a video ad with Exodus from the terminal. The main path is script-first: run a saved video workflow with `npx @aicopycoders/exodus workflow run`. You read and approve the storyboard, pull every finished piece (per-scene clips, the narration track and per-scene voice, keyframes, cast identity stills, word timings, the music bed) into a folder with `exodus video pull`, and upload a finished cut for approval. Exodus makes the pieces; the cut is made outside it, in whatever editor the user wants — this skill hands over the pieces and the facts about them, it does not prescribe an editor. Use it whenever the user has invoked Exodus and wants anything to do with a video ad, an ad run's clips or storyboard, "pull the pieces", "stitch it together", "make the cut", "upload my cut", or checking on a video run ("exodus, make a video ad from this script", "exodus, is my video run done", "exodus, pull the clips for run X and cut them", "exodus, what's wrong with scene 3", "exodus video status"). Also use it when the user ran an `npx @aicopycoders/exodus video` command or the `exodus` hub skill routed here. Video is admin-only: "video isn't enabled for this key" means either the dashboard user lacks the admin role or the run id is wrong, so check the id and then say so; do not retry. Never claim generic video-editing asks ("edit this mp4", "add captions to my reel") without Exodus context; in shared folders those belong to the user's other tools. Running or authoring workflows generally is `exodus-workflow`; static image ads are `exodus-image`; copy is `exodus-write`.
+description: Make a video ad with Exodus from the terminal. The main path is script-first: run a saved video workflow with `npx @aicopycoders/exodus workflow run`. You read and approve the storyboard, pull every finished piece (per-scene clips, the narration track and per-scene voice, keyframes, cast identity stills, word timings, the music bed) into a folder with `exodus video pull`, and upload a finished cut for approval. Exodus makes the pieces; the cut is made outside it, in whatever editor the user wants — this skill hands over the pieces and the facts about them, it does not prescribe an editor. Use it whenever the user has invoked Exodus and wants anything to do with a video ad, an ad run's clips or storyboard, "pull the pieces", "stitch it together", "make the cut", "upload my cut", or checking on a video run ("exodus, make a video ad from this script", "exodus, is my video run done", "exodus, pull the clips for run X and cut them", "exodus, what's wrong with scene 3", "exodus video status"). Also use it when the user ran an `npx @aicopycoders/exodus video` command or the `exodus` hub skill routed here. Admins get every video command; beta testers with video switched on get start, status, storyboard, approve, voices, retry-frame, pull and upload on their own brands (see "Beta testers"). "video isn't enabled for this key" means the run id is wrong, the command is admin-only, or video isn't switched on for that dashboard user, so check the id and then say so; do not retry. Never claim generic video-editing asks ("edit this mp4", "add captions to my reel") without Exodus context; in shared folders those belong to the user's other tools. Running or authoring workflows generally is `exodus-workflow`; static image ads are `exodus-image`; copy is `exodus-write`.
 ---
 
 # Video: make the pieces, cut the ad, hand it back
@@ -21,26 +21,82 @@ Your job in this skill is to drive that loop, hand over the pieces with the
 facts about them, and make whatever cut the user asked for. **How to edit is the
 user's call, not this skill's** — see "Cutting the ad".
 
+This file ships on the member's machine. It holds commands, the manifest's
+shape, and recipes for the cut. It does not hold prompt text, house primers,
+judge wording, or model instructions.
+
 ## How a run starts
 
 The ad is a saved workflow in the brand, started script-first with `exodus
 workflow run`. From there the same nodes render, `video status` reads the run,
 `video pull` writes the folder, and `video upload` and `approve` finish it.
 
+A Show is no longer required. `exodus video start` starts from a script, a
+conceit, and a style. The same parks follow, except that the app approves the
+storyboard itself when its checks pass (see "What costs money"). The full line is under
+"Starting a run". An optional `--direction` note is whole-ad rules, and that
+note cannot contain a colon. "The script file" shows the right form and the
+wrong one.
+
+The Rig box on that workflow is where the run's Conceit and Style come from.
+Conceit is the family plus Wrapper, Narrator Person, and Delivery. Style is the
+look. Narrated Story is the voice-over family and Acted Story is the dialogue
+family (`familyTree.ts`). Those family names stay the code's names.
+
 ## Before anything
 
 - `npx @aicopycoders/exodus video --help` and `workflow --help` are the
-  authoritative flag lists. The `video` verb is admin-only and hidden from the
-  top-level `--help`; that is expected, not a broken install.
-- **Video is admin-only**, and says so two different ways.
-  - "video isn't enabled for this key", from a `video` verb, has two causes the
-    CLI cannot tell apart: the user is not an admin on this brand, or the run id
-    does not exist. Check the id first; if it is right, they need the admin role.
+  authoritative flag lists. The `video` verb is hidden from the top-level
+  `--help` because most members can't use it; that is expected, not a broken
+  install.
+- **Who can use video.** Admins get everything in this file. A beta tester
+  (video switched on for their dashboard user) gets a smaller set on their own
+  brands, listed under "Beta testers" below. Two refusals:
+  - "video isn't enabled for this key", from a `video` verb, has three causes
+    the CLI cannot tell apart: the run id does not exist on this brand, the
+    command is admin-only, or video isn't switched on for this user. Check the
+    id first, then check the command against "Beta testers".
   - "Video workflows aren't available on your account. Ask an admin if you need
-    video.", from `workflow run`, is unambiguous — `startRun` refuses any graph
-    containing a video node for a non-admin (`convex/workflows.ts:6471`).
+    video.", from `workflow run`, is unambiguous. `startRun` refuses any graph
+    containing a video node for a non-admin, beta testers included. A beta
+    tester starts with `exodus video start` instead.
 
   No flag or retry fixes either one.
+
+## Beta testers
+
+A beta tester's key gets the same video the dashboard's Video page makes, and
+never how it is made. Every answer to them says `"view": "customer"`, and the
+CLI words it the way the run page does. On their own brands they can:
+
+- `video start --script <file> --conceit <key> --style <slug>` with
+  `--direction`, `--music`, `--review-storyboard` and `--wait`. Any other start
+  flag is refused with one sentence naming it. The answer is the run id and the
+  link to the video's page.
+- `video status <runId>`: where the video is, in plain words (waiting in line,
+  planning, drawing, storyboard ready for review, filming, ready with its link,
+  or stopped and why). `--json` prints the server's answer as it came.
+- `video storyboard <runId>`: each scene's line and picture, while the
+  storyboard waits for review.
+- `video approve <runId>`: approves the storyboard. Nothing else.
+- `video voices <runId>`: who speaks, their current voice, and the voices on
+  the tester's own ElevenLabs account. `--set <character>=<voiceId>` picks one,
+  until the storyboard is approved.
+- `video retry-frame <runId> --scene <n>`: redraws one scene's picture while
+  the storyboard waits. No `--node`; the server finds the step.
+- `video pull <runId> --out <dir>`: the finished video (`video.<ext>`), each
+  scene's clip (`scene-NN.<ext>`) and voice (`scene-NN.voice.<ext>`), and the
+  music (`music.<ext>`), with a `manifest.json` holding only `runId`,
+  `pulledAt`, `dashboardUrl`, `scenes` (`index`, `clip`, `voice`), `music` and
+  `video`. A file that did not download is `null` there. Nothing else in "The
+  handover" below applies to them.
+- `video upload <runId> --file <cut>`: attaches their cut and prints the page
+  to watch it on.
+
+Admin-only, answered "video isn't enabled for this key" (or, for retry-clip and
+revoice, a sentence saying they are for admins): `director`,
+`status --rejected-draft`, `retry-clip`, `revoice`, and the start flags
+`--video-model`, `--voice`, `--voice-path` and `--director`.
 - Other failures: `npx @aicopycoders/exodus doctor` first, then follow what it prints.
 - `ffprobe` on the PATH lets `upload` read the cut's length by itself. Without
   it, `upload` falls back to parsing an MP4's own header, and for anything else
@@ -69,6 +125,20 @@ exodus workflow run <workflowId|name> --input <field>=@script.txt --voices @voic
 exodus workflow run <workflowId|name> --input <field>=@script.txt --voice-treatment @voice-treatment.json --wait
                                                           same, with the video model speaking voices you WROTE
 exodus video status <runId>                               where it is, per scene
+exodus video start --script <file> --conceit <podcast|ugc|stage|street|personification> --style <slug> [--direction "…"] [--voice-path <path>] [--video-model <id>] [--voice native] [--music] [--review-storyboard] [--director] [--wait]
+                                                          start from a script, a conceit and a look.
+                                                          No music bed unless you pass --music.
+                                                          The app approves its own storyboard when its
+                                                          checks pass and goes straight on to the clips,
+                                                          which is the part that costs. It stops at the
+                                                          gate only when a check finds a problem, and says
+                                                          why. --review-storyboard always stops there.
+                                                          Each conceit has its own video model and voice;
+                                                          --video-model / --voice override them for one run.
+                                                          --director turns the trial director on (admins only)
+exodus video director <runId> on|off|follow               the trial director for one run (admins only);
+                                                          follow = the brand's own setting. status shows
+                                                          what it is doing and its last three notes
 ```
 
 **From the storyboard on.**
@@ -79,9 +149,10 @@ exodus video voices <runId>                               who speaks and with wh
 exodus video voices <runId> --set <character>=<voiceId>   give a character a voice
 exodus video approve <runId>                              keep going
 exodus video retry-frame <runId> --node <nodeId> --scene <n>  redo one still at the pixel gate
+                                                          (a beta tester leaves --node off)
 exodus video status <runId>                               where it is, per scene
 exodus video pull <runId> --out ./ad-<runId>              every piece + manifest.json
-exodus video retry-clip <runId> --scene <n> [--node <nodeId>] [--note "…"]
+exodus video retry-clip <runId> --scene <n> [--node <nodeId>] [--note "…"] [--voice-first]
                                                           redo one clip at the final watch
 exodus video revoice <runId> --all | --scene <n>          redo only the voice; no new video
                                                           … make the cut (your choice of tool)
@@ -98,7 +169,15 @@ already printed the same stop block, and `workflow inbox` lists a parked video
 run, but neither shows the per-scene detail, and the checkpoint verbs cannot
 resolve a video park — see "What the CLI can and cannot do".
 
-**Where a run can stop.** Five stops, each with the exact next command printed
+**Where a run can stop.** The two video parks come in order when the run has
+both. The storyboard gate is first. You read the cards there and you set the
+voices there. Approving that gate releases the voices and the clips. That is the
+expensive part. The final watch is next, after the pieces exist, and only when
+the video node sets `finalWatch: true`. That park is for the cut. You pull, you
+cut, and you upload. Approving the upload makes it the ad. A node with
+`finalWatch` off skips the second park and the run finishes.
+
+Five stops, each with the exact next command printed
 under it:
 
 - storyboard gate: needs `approve`. When the stop block prints a `Redo one
@@ -110,7 +189,11 @@ under it:
   lines under `guidance`). It is also
   the one park where a finished clip can be redone, with `retry-clip`. A run
   only reaches this park if its video node sets `finalWatch: true` — otherwise
-  it skips straight to finished.
+  it skips straight to finished. If a scene has no clip, the stop block names
+  it instead (`stop.missingScenes` in `--json`) and approval is refused until
+  it has one. A scene whose picture the video service refused needs
+  `retry-frame --note` before `retry-clip`; the clip redo alone resends the
+  refused picture.
 - paused: a builder checkpoint neither video verb resolves —
   `exodus workflow checkpoint <runId>` is the verb for that one.
 - failed: `status` shows how far it got, and a `--wait` that was running exits
@@ -137,18 +220,31 @@ minutes with "Still running after 60 minutes" and exit 0; that is not done, so
 check `status` before treating it as finished. Do not poll `status` in a tight
 loop; a full run is several minutes.
 
-**What costs money.** Starting the run writes the storyboard and then draws the
-reference, cast and scene pictures, and only then pauses. Each picture is a few
-cents and each scene draws a few to choose from: about 25 cents on a small test,
-and it can approach a dollar on a longer ad. Approving releases the expensive
-part: the voices and the clips. So a run that has not paused yet is already
-spending a little, and a run still drawing pictures is healthy. `exodus workflow
-status` and `exodus video status` both print "This run will pause for your
-approval once the frames are ready" on a run that is headed for the gate. Do not
-cancel it because the pause has not arrived. `workflow list`, `workflow describe`, `video status`,
-`storyboard` and `pull` are free reads; run them as often as you like. Never
-start a second run to "retry" without the user asking; tell them what failed
-instead.
+**What costs money.** Every run writes the storyboard first and then draws the
+reference, cast and scene pictures. Each picture is a few cents and each scene
+draws a few to choose from: about 25 cents on a small test, and it can approach
+a dollar on a longer ad. The expensive part comes after the storyboard: the
+voices and the clips. What happens at that point depends on how the run
+started.
+
+- A paste-a-script run (`exodus video start --conceit …`) checks its own
+  storyboard once the pictures are drawn. When every check passes, the app
+  approves the storyboard itself and goes straight on to the voices and the
+  clips, with no stop. It stops for the user only when a check finds a problem,
+  and the stop block says why in plain words. Started with
+  `--review-storyboard`, it always stops at the storyboard instead. `status`
+  prints "the app checks the storyboard and approves it itself if the checks
+  pass" on a run headed that way.
+- A Show run (`video start --show`) and a saved workflow run (`workflow run`)
+  still pause at the storyboard for approval. Approving is what releases the
+  voices and the clips. `status` prints "This run will pause for your approval
+  once the frames are ready" on a run headed for that pause.
+
+Either way, a run still drawing pictures is healthy and already spending a
+little. Do not cancel it because nothing has happened yet. `workflow list`,
+`workflow describe`, `video status`, `storyboard` and `pull` are free reads; run
+them as often as you like. Never start a second run to "retry" without the user
+asking; tell them what failed instead.
 
 **`--auto-approve` does not cover either video gate.** It releases Checkpoint
 boxes only (`convex/workflows.ts:7266` keys on `pauseReason === "checkpoint"`),
@@ -160,8 +256,8 @@ on its own.
 ## What the CLI can and cannot do
 
 Verified against the CLI and the server, not assumed. Everything here is
-admin-gated on top. Five things worth knowing before you promise a user
-anything:
+about the admin tools; a beta tester has only what "Beta testers" lists. Five
+things worth knowing before you promise a user anything:
 
 - **A workflow only stops for your cut if its video node asks to.** `finalWatch`
   defaults to `false` (`convex/lib/workflow/catalog.ts:780`), and the run only
@@ -211,11 +307,42 @@ anything:
 
 ## The script file
 
-Plain text. A `CAST:` block naming the speakers, one line per turn, then a
-`CTA:` block. The planner sizes every line at
-2.5 words per second (`WORD_LADDER_WPS`), so a turn near 14 words plans a clip
-near 6 seconds. If a line does get truncated in its clip, the manifest says so
-(`speech-cutoff`).
+Plain text. An optional `DIRECTION:` block may open the file, before `CAST:` or
+the first spoken line. Then a `CAST:` block naming the speakers, one line per
+turn, then a `CTA:` block.
+
+`DIRECTION:` carries whole-ad rules and no spoken words. The header is its own
+line. The lines under it are the rules. The block ends at a blank line, at
+`CAST:`, at `CTA:`, or at the first line that names a speaker. A second
+`DIRECTION:` block is refused. So is a `DIRECTION:` after the first spoken line.
+An empty block is refused too. The error code is `malformed-direction`.
+
+Do not put a colon inside direction prose. The reader splits a line at its first
+colon to find a speaker, so a colon in that prose is read as a name.
+
+Right.
+
+```
+DIRECTION:
+Nobody looks at the camera. The product stays on the table until the last line.
+```
+
+Wrong.
+
+```
+DIRECTION:
+Rule: nobody looks at the camera.
+```
+
+The wrong line is not direction. `Rule` is read as the speaker, and the
+block above it is empty, so the file is refused.
+
+The planner sizes every line at 2.5 words per second (`WORD_LADDER_WPS`), so a
+turn near 14 words plans a clip near 6 seconds. If a line does get truncated in
+its clip, the manifest says so (`speech-cutoff`). That finding means the clip
+cut the words off. Redo the clip. Do not speed the speech or cut it short to
+hide the finding. The product rule is under "What the product actually
+requires".
 
 ```
 CAST:
@@ -229,6 +356,15 @@ CTA:
 THE SOFTGEL: Tap below and give your eyes ClearBlink.
 ```
 
+The dash in a `CAST:` line is the parser's own separator. The example above
+already shows that dash. A cast line may separate the name from the description
+with an em dash, an en dash, or a hyphen with a space on each side. Keep that
+dash on cast lines. A reader who strips it makes the line fail.
+
+Do not use a long dash in words a character says, or in words shown on screen.
+Synthesised speech reads a long dash oddly, and so does burned-in text. A spoken
+line stays `NAME: what they say`.
+
 **How many speakers you may have depends on the rig.** Three by default. A rig
 that carries saved format rules sets its own number: an ensemble rig seats more,
 a talking-head rig seats one. Over the number, the launch refuses before
@@ -261,9 +397,13 @@ unattended.
 By default a workflow run's characters have no voice of their own. A character
 without one gets the run's default voice (the workflow's narrator voice) when the
 run has one; with no default either, the clip keeps the voice the video model
-invents. `exodus video voices` shows which of the three applies and is where it
-gets fixed, and it only works **before** the storyboard is approved — once clips start
-it refuses.
+invents. `exodus video voices` shows which of the three applies, and it is where you
+fix the mapping. Fix it before you approve the storyboard gate. Approving that
+gate locks the mapping, and `exodus video voices` refuses afterwards. On a
+finished clip whose voice was never applied, the later command is `exodus video
+revoice`, and that pass bills again. A clip that already went through the voice
+pass is refused there. Use `retry-clip` for that one. See "Redoing only the
+voice on finished clips".
 
 ```
 exodus video voices <runId>
@@ -337,7 +477,7 @@ nobody knows the speaker names yet. When the storyboard arrives, the voices are
 already set and `exodus video voices <runId>` shows them.
 
 **Choosing how the voices are made.** `--voice-treatment` on `workflow run` says
-HOW a run makes its voices, and it is the only door. Two
+HOW a run makes its voices, and it is the only way. Two
 kinds of answer.
 
 A name on its own picks a way of working that plays a voice you already have,
@@ -410,7 +550,8 @@ person made at a keyboard for one run, and nobody made it for the sub-workflow.
 **Written voices cannot be changed at the review.** They are chosen when the run
 starts. `exodus video voices <runId>` on a described run names the treatment and
 prints each written voice, and says plainly that `--voice-treatment` at launch is
-what changes them. Do not set a voice path in node config — it is not a door.
+what changes them. Do not set a voice path in node config. Node config does
+not set the treatment.
 
 **Where it shows up afterwards.** The launch receipt and `exodus workflow status`
 both print one line naming the treatment and the speakers who got a written
@@ -488,6 +629,20 @@ manifest.json            the index below
 runId, pulledAt, dashboardUrl        the run and the page that opens it:
                                      /workflows/<workflowId>/runs/<runId>
 storyboard, reference, music         filenames, or null when not delivered
+musicBed                             on | off | unknown — whether the RUN has a
+                                     music bed, which is not the same question
+                                     as the `music` filename above. "unknown" is
+                                     a run made before the run carried the
+                                     answer; it is not "off"
+musicHeardScenes[]                   scene numbers whose clip came back with
+                                     music the video model baked in. A run with
+                                     the bed off can still list scenes here, and
+                                     those are the ones to listen to
+pendingRedo[]                        scene numbers the app is redoing right
+                                     now. Their clip and words are left out,
+                                     because the file on the run is the take
+                                     being replaced: run `exodus video wait`,
+                                     then pull again
 narration                            { file, timing }, or null on a per-scene run
 cast[]                               one per identity still
   characterId, name                  from the run's cast lock; null for an
@@ -520,6 +675,9 @@ scenes[]                             one per scene, in order
                                      on record when the voice pass replaced the
                                      clip with a new file; null when the clip IS
                                      that file, or there is no clip
+  voiceMode                          "voice-first" when the clip was redone voice
+                                     first (its line recorded, then the clip made
+                                     to match it); null otherwise
 provenance                           which saved rulebook this run followed:
                                      {format: {via, nodeId, rigId, rigName,
                                      rulesFrom, specVersion}}. Absent when the
@@ -542,15 +700,19 @@ depends on the scene; see "Which scenes carry their voice where" below.
 terms. `script[]` is the ad's spoken words in order — `{lineId, speakerId, text}`,
 with `speakerId: null` meaning narrator VO. Each scene carries `sceneIndex`,
 `durationSec`, `dialogue[]`, `voText`, `notes`, and `lineIds` (the script lines
-that scene renders). A scene with `kind: "cutaway"` carries `cueLineId` instead:
-it is a picture-only takeover of the frame while the spoken track underneath
-keeps running, so it adds no audio and takes no place in the running order. The
+that scene renders). A scene with `kind: "cutaway"` carries `cueLineId` and a
+`cutawayType` instead. Most cutaways are a picture-only takeover of the frame
+while the spoken track underneath keeps running, so they add no audio and take
+no place in the running order. A `cutawayType: "reaction"` cutaway is the room
+reacting out loud to its cue line: it is its own short beat after that line,
+heard with its own sound while the speaker is silent. The
 envelope also carries `overlays[]` (each with a `cueLineId` and a `placement`)
 and `audio` (`roomTone`, `music`, `sfxCues[]`) — the planner's notes on what
 should sit on top. The image and motion prompts (`framePrompt`, `videoPrompt`,
 `referencePrompt`) reach an admin key in full. A caller who cannot use video on
-this brand gets them stripped before the file arrives — they are style-pack IP
-(`redactVideoIp` in `convex/workflows.ts`).
+this brand gets them stripped before the file arrives. They are private Style
+fragment IP (`redactVideoIp` in `convex/workflows.ts`). Style pack is the
+retired name.
 
 **The narration track** (`narration.mp3` + `narration.json`). Present when the
 run recorded continuously: every narrated scene's `voText` joined into one
@@ -577,9 +739,9 @@ speech inside the clip — under the default voice treatment the video model's
 invented voice is then replaced, in place, with the cast member's pinned
 ElevenLabs voice (that is `revoiced: true`). Other treatments leave the render
 owning its own audio, e.g. lip-sync retargeting a VO track onto the video. The
-treatment is frozen on the run when it starts, and there is exactly one door
+treatment is frozen on the run when it starts, and there is exactly one flag
 that sets it: `--voice-treatment` on `workflow run` (see **Choosing how the
-voices are made**). Node config is never a door — nothing on the canvas sets a
+voices are made**). Node config never sets it. Nothing on the canvas sets a
 voice treatment, and a run that was given none renders the default. Read
 `wordsFrom` and `revoiced` per scene rather than assuming.
 
@@ -641,6 +803,11 @@ blocking the run.
   A `speech-cutoff` on the CTA scene is the one to worry about; the ad's last
   words are missing. `status` shows the checker's own wording behind each
   finding; the manifest carries only the verdict.
+- A `pass` verdict is not a review. The checks are often optimistic. Watch the
+  frames and listen to the audio before you call the run good. Two checks fail
+  the wrong way. A cast-count check can reject a silent
+  listener who belongs in the shot. A clip check can flag a clip that is fine.
+  Read the finding, then watch the scene.
 - `clipStatus: "failed"` or `"missing"` with a `keyframe`: `durationSec` is null
   (it comes from the clip), but the scene can still hold its place as a still —
   for the length of its voice track, or the storyboard's planned duration when
@@ -658,6 +825,7 @@ is no second run, no new storyboard and no re-render of anything else.
 exodus video retry-clip <runId> --scene 3
 exodus video retry-clip <runId> --scene 3 --note "keep both hands in frame on the handshake"
 exodus video retry-clip <runId> --scene 3 --node video-2
+exodus video retry-clip <runId> --scene 3 --voice-first
 ```
 
 `--node` is only needed when a run has clips for that scene on two video steps;
@@ -680,7 +848,17 @@ revoiced and trimmed the same way, with fresh findings and fresh word timings.
 scene's motion prompt only (`withRedoDirection`,
 `scout/src/trigger/workflow-scene-retry.ts`); the spoken line still comes from
 the approved storyboard. Asking for different words in a note will not change
-them. If the words are wrong, that is a new run.
+them. If the script's words are wrong, that is a new run.
+
+**`--voice-first` fixes a clip that said its line wrong** (#2299). It is for a
+clip whose findings include `speech-mismatch`, `speech-repeat`,
+`speech-after-line`, `speech-extra-words` or `speech-long-pause`. The scene's line is recorded in each
+speaker's pinned ElevenLabs voice, and MiniMax (`minimax-h3/reference-to-video`)
+makes the clip to match the recording. Only that clip changes; the word check
+and the other checks still run on it. It needs an ElevenLabs key and a voice for
+every speaker in the scene, and it is refused for a scene with no spoken line.
+The clip then reads `clip: redone voice first` in `status`, carries
+`voiceMode: "voice-first"` in the manifest, and is listed in the `pull` summary.
 
 **A redo whose take fails the checks keeps the original clip.** On a finished
 clip the row stays `done` with the ORIGINAL take and only its findings are
@@ -767,7 +945,10 @@ they want; if they have not said and are not around, say which you used and why.
 - **HyperFrames** — HTML/CSS compositions rendered to video. Suits an ad that
   needs captions, title cards, overlays or motion graphics laid over the clips.
   It is a separate skill pack; check that a `hyperframes` skill is installed
-  before offering it.
+  before offering it. The cut is made outside Exodus. `exodus video pull` is the
+  handover. The folder it writes is what the next tool reads. When a HyperFrames
+  skill pack is installed, that pack is the route for an HTML and CSS
+  composition. Do not look for a stitch inside Exodus.
 - **An NLE over MCP** — DaVinci Resolve publishes an MCP server, so a timeline
   can be built in a real editor and the user can carry on by hand afterwards.
   Suits a user who wants to keep editing after you stop. Check what MCP servers
@@ -789,6 +970,13 @@ Read these out of `storyboard.json` before you build anything, in any tool:
   running order. To find the moment, locate the A-roll scene whose `lineIds`
   contain the cue line, then read the start time of the first word of that line
   out of that scene's `words.json`.
+- **Reactions.** A cutaway with `cutawayType: "reaction"` is the exception. Do
+  not lay it over the speech. Put it into the running order as its own beat
+  right after its cue line ends, play its own sound (the audience laughing),
+  keep it to about 1.5 s, then carry on with the speaker. Nobody talks during
+  it. When more lines follow the cue line in the same scene, cut that scene
+  where the cue line's last word ends in its `words.json` and put the reaction
+  between the two halves.
 - **Overlays and SFX.** `overlays[]` and `audio.sfxCues[]` are cued the same
   way, by `cueLineId`. Nothing renders them for you.
 - **Captions.** Nothing is burned into any clip. Captions belong in post; the
@@ -805,31 +993,52 @@ the pieces:
   holds its last frame for the difference. The narration is never sped up,
   slowed down or cut short, so every scene plays at the speed it was recorded,
   and the word times are handed on as they were measured.
+- **It closes the dead air at the joins.** A clip that plays its own dialogue
+  keeps about 0.15 s after its last word and about 0.1 s before its first (0.25 s
+  when a different speaker answers), read from its `words.json`, so one clip
+  runs into the next like one conversation. It only ever shortens a clip's
+  silence and never cuts into a word. The ad's first clip also opens about 0.1 s
+  before its first word, so a hum a clip makes before anyone speaks is not the
+  first thing heard. The ad's last tail, a narrated scene, a still and a
+  reaction beat keep their length.
+- **It fades the audience reaction in and out.** A reaction beat fades in
+  across any quiet start before its laugh (a generated laugh clip can hum
+  there). When a line follows, the picture moves on early and the laugh's own
+  remaining sound plays on under that line, quieter and fading out: up to
+  0.75 s, and the beat keeps at least 1 s of picture (a 1.5 s clip shows 1 s
+  and carries its last 0.5 s). A beat that ends the ad, or has under 0.4 s to
+  carry, fades out over its last 0.4 s instead.
 - **It ignores the continuous master.** It reads only `scene-NN.voice` files;
   it never opens `narration.mp3` or `manifest.narration`. A tool that lays the
   master down whole and cuts the pictures to it keeps the read intact.
-- Otherwise: A-roll in manifest order as the spine, each cutaway laid over the
-  spine at its cued word (falling back to a proportional estimate when the scene
-  has no word times, and saying which method it used), a narrated scene's voice
+- Otherwise: A-roll in manifest order as the spine, each reaction put in as its
+  own beat of at most 1.5 s right after its cue line with its own sound, each
+  other cutaway laid over the spine at its cued word (falling back to a
+  proportional estimate when the scene has no word times, and saying which
+  method it used), a narrated scene's voice
   replacing whatever the clip recorded, a dialogue scene keeping its performed
   line, a clip-less scene becoming a still, everything normalized to 1080×1920
   at 24 fps and −16 LUFS per segment, a generated room-tone bed under the whole
   ad, and the music bed underneath at low level. Output is H.264 + AAC in an MP4
   with `-movflags +faststart`.
 - Flags: `--out <file>`, `--skip 2,5`, `--no-music`. It prints what went in,
-  what was left out and why, and the upload command.
+  what was left out and why, and the upload command. When a clip hums or
+  clicks where nobody speaks at an edge the cut plays, it lists each one under
+  "Sound at the edges" with its time in the cut. That is a warning to listen
+  there; the cut is made anyway.
 - Beside the MP4 it writes `cut.words.json` (every spoken word of the finished
   ad with its start and end) and `cut.srt` (the same words grouped into subtitle
   lines), named from the `--out` basename. Those times are on the finished ad's
   timeline, each scene's own word times offset by where that scene starts in the
-  cut and otherwise unaltered. Scenes with no word times leave
+  cut, less any lead-in trimmed at the join, and otherwise unaltered. Scenes with no word times leave
   gaps and are named in the report; when no scene delivered any, neither file is
   written. These sidecars are the script's own output — another tool will not
   produce them.
 
 Before uploading anything, from any tool, check what you made:
 `ffprobe -v error -show_entries format=duration -of default=nw=1:nk=1 cut.mp4`
-should be close to the sum of the scene durations you kept. A cut that is a few
+should be close to the sum of the scene durations you kept (the bundled
+script's cut runs somewhat shorter, by the silence it trimmed at the joins). A cut that is a few
 seconds long when five clips went in means a filter dropped inputs; do not
 upload it.
 
@@ -864,6 +1073,11 @@ lines, re-recording narration, or cutting words out of the CTA will ship,
 silently. Cut the pictures to the words, not the words to the pictures. If the
 words are wrong, that is a new run, not an edit.
 
+Never stretch speech, speed it up, slow it down, or cut it short so it fits a
+clip. That is a product rule, and it holds for every tool that makes the cut,
+including the bundled script. If the audio does not fit, redo the clip with
+`exodus video retry-clip`. Do not repair the fit in the editor.
+
 ## Reporting to the user
 
 Lead with where the run is and what it needs from them. Then, when you pulled

package/assets/skills/exodus-video/scripts/first-cut.d.mts

@@ -0,0 +1,27 @@
+// #2988: the types of the one export the Trigger worker calls. The script is
+// plain JS so the CLI can run it with `node` and no build.
+
+export class FirstCutError extends Error {
+  constructor(code: 1 | 2, message: string);
+  readonly code: 1 | 2;
+}
+
+export interface FirstCutOptions {
+  /** A folder written by `exodus video pull`. */
+  dir: string;
+  /** Defaults to <dir>/cut.mp4. */
+  out?: string;
+  skip?: Set<number>;
+  /** The music bed, when the pull has one. Defaults to on, as the CLI does. */
+  music?: boolean;
+}
+
+export interface FirstCut {
+  out: string;
+  durationSec: number;
+  /** The music file the cut used, or null. */
+  music: string | null;
+  timeline: { spine: Array<{ sceneIndex: number }>; left: string[] };
+}
+
+export function firstCut(options: FirstCutOptions): FirstCut;