stage-plan

stage-plan

How to turn "here is my material + here's the video I want" into a single, inspectable plan spanning reference images/videos, deterministic or semantic editing, generation, and composition. The output is project/plan.json—a cross-modal EDL that the assembler walks. Ingest with the public ovs analysis commands, validate with ovs plan, and execute through the compose/generate/edit lines.

Use this line when the deliverable is NOT cleanly one axis — e.g. "trim my clip, add a title card and captions, and a voiceover", or "my footage for the middle, generate an opener, compose the stats". For a pure single-axis job, route to that single line instead (see video-router).

Step 1 — Ingest from evidence, never from assumption

You cannot plan against material you have not looked at. For EVERY supplied clip, before writing any segment:

1. Probe it (ovs edit probe) for real duration / resolution / fps / audio presence. A plan that cuts past the real duration breaks.
2. Read its content the cheapest way that fits:
   • spoken audio → ovs transcribe raw/clip.mp4 --out project/transcripts/clip.json (pass --model large-v3 for non-English) → you now have timecoded words to cut on and a reusable transcript file for edit ops.
   • silent / screen-recording / slideshow → prefer ovs ocr → per-timecode on-screen text. The audio being empty does NOT mean the screen is. If local OCR reports a runtime/install/recognition failure, extract representative frames with ovs edit extract-frame and read them yourself; if you cannot inspect images, ask the user for the on-screen beats. Never infer slide/screen content from the topic alone.
   • need to judge what a moment LOOKS like (is the hero shot usable? is the product right-side up?) → read frames: ovs edit extract-frame then look at them. If you are multimodal you read them directly; if you cannot see images, say so and plan on probe/transcript/OCR evidence alone — mark those judgments unverified, do not invent them.
3. Record what each input is good for in project/ingest.json: {input_id, duration, has_audio, content_summary, quality_risks:[...], usable_for:[...], planning_implications:[...]}. This is the factual basis the plan cites — segments reference input_ids from here. Rules:
   • content_summary is specific and from observation: "45 s of interview, no b-roll, mono audio" — never "user provided footage". An entry is only "reviewed" if a real probe/transcript/OCR actually ran; never claim you looked at a clip you did not.
   • Usability heuristics: video > 10 s → hero footage; > 3 s → b-roll; has speech → dialogue source; audio-only → narration/music source, production must supply the visuals; image-only → motion must come from animation or generation.
   • Quality risks to flag: width < 720 / height < 480 (will look soft), clip < 3 s (limited use), mono audio, a still where the brief wants motion. A flagged risk the plan ignores is a planning bug — resolve it during direction confirmation.