/open-edit

name: open-edit
description: Orchestrate a video run rendered by VEED's engine — stylized captions over footage, edits and reframes, layered motion graphics, or graphics with no footage at all. Takes any number of source videos, including none. Use when the user wants video made, edited, or captioned by an agent.

open-edit — video orchestrator

Renders video with `veed-engine-cli` (the veed render engine). Stylized captions over real footage — subtitles across every spoken beat — is the best-travelled path and most of what follows details it, but captions are one capability, not the boundary: edits, reframes, layered motion graphics, and compositions with no footage at all are the same engine and the same gates.

The engine renders a `.wv` document, which **is an extension of CSS and can be treated as such**: an HTML fragment plus a `<style>` block, standard CSS throughout, no JavaScript and no proprietary timeline — `@keyframes` and `animation-delay` ARE the timeline. Your CSS knowledge transfers directly; only the engine's unimplemented parts have to be learned (`pipeline/director-brief.md` § ENGINE LIMITS).

**INPUTS — any number of videos, INCLUDING NONE.** Footage is a layer inside that document — an optional one. What the input count changes is **how much of the work arrives already scripted, never whether the work is supported.**

• **One video** — recommended, and the best-travelled path. The transcript, the canvas (dims + fps) and

the base frames are all derived from the file, which is what lets a compiled recipe run at zero tokens.

• **Several videos** — ONE batch, not one run each. `prep/transcribe.ts`, `veed/go.ts` and `prep/prep.ts`

all take `<video.mp4> [...]` and write one `runs/<key>` per video, so the provider question, the sign-in and any install happen once; steps 3-5 then run per `runs/<key>`.

• **No video — FULLY SUPPORTED, not a degraded mode.** Motion graphics, stills, slides, generated

imagery, audio-only sources. Author the `.wv` INLINE per `pipeline/director-brief.md` and run the SAME gates as every other run: `lint-template.ts` → `veed-engine-cli <dir> --verify` → `--record` (step 4's RENDER + VERIFY block — none of it reads `meta.json`). Choose `<key>` from the ask, take the canvas and duration from the ask rather than from ffprobe, and drop only the steps that have no subject: the recipe draw (no footage to derive facets from), `probe-qa` (it diffs frames against source footage) and mux-audio (no audio track). `generate-recipe.ts` is the scripted convenience for 1+ videos, NOT the definition of a supported run — its absence costs you the shortcut, nothing else.

The captioned run is **fully scripted end to end**: recipes are COMPILED CODE (`refs/html/<id>/recipe.ts`), so a recipe-backed pick generates, verifies, and renders with zero tokens. The only spawned agent left is the OPT-IN vision-analysis pass (style-refine requests); the CREATIVE path face-1 (the user brought their OWN reference/brand/concept — their materials are the design authority) is authored INLINE by the orchestrator, and creative iteration on a delivered result is REMIXED inline (no subagent). There are **no per-shot intermediates and no user-approval gate**. Read `docs/FLOW.md` for the map.

Default run (the FAST PATH) = steps 0 → 1 → 3 → 4 → 5 (step 2 is SKIPPED). Vibe/genre/energy come from the transcript; placement comes from the brief's safe margins; the style is SAMPLED by script; word reveal timings are precomputed (`word-timings.json`). The runtime index is recipes-only, so a default run's step 4 is always `pipeline/scripts/generate-recipe.ts` — a SCRIPT, no model, no subagent: the recipe already did the design thinking, offline, and the code does the assembly + the full gate chain (lint → verify → record → probe). Creative face-1 is authored INLINE by the orchestrator; the only spawned agent is the opt-in analyse pass. REFINEMENT is declared by `analysis.json` existing (step 2 ran on user request) — placement then composes from it instead of the safe margins.

User-facing output — talk like a product, not a pipeline

The user asked for a video, not a pipeline tour. Internals are NEVER surfaced: run keys, ref/style ids (`hook-…`), "recipe"/"recipe-backed", seeds, facets, energy scores, beat counts, frame counts, gate names (lint / `--verify` / probe-qa), engine details. A fresh user has no idea what any of that means. The CLASSIC POOL is equally internal: never say "classic", "preset", "route", or a preset id (`simple`, `glass`, …) — "Classic route, 'simple' preset" is exactly the leak this section bars. The user asked for clean captions; say you're on it, then deliver.

• **Never name the style — and never expose the mechanics of choosing it.** The ref id, its metadata,

and the sampling machinery ("the sampled pick", "the draw", seeds, alternates) are all internal. Talk about "the style" as an abstract thing that exists for this video: "the style centres text mid-frame, so I'm switching to one that anchors low" — not "the sampled pick is…". Describe a delivered look only in plain visual terms (colour, size, placement).

• **No step-by-step progress.** Don't announce transcript/prep/sampling/verify/probe/mux as they

happen. One line when starting, then the deliverable with the preview URL. Silence in between is fine.

• **"Render complete" = audio muxed.** Muxing is not a separate user-visible step; say the render is

done only once `final/out.mp4` exists.

• **No recap.** The delivery message is the `out.mp4` path plus at most a sentence or two about the

result (on creative runs, the look you committed). Never a "What happened" list of stages, gates, counts, or QA results.

• **Failures are the exception.** When a gate fails and you must stop, explain in plain terms what is

wrong on screen and the options; quote raw FAIL lines only if the user asks.

• Questions you must ask (renderer update consent, coverage gaps, probe failures) also