Plan each segment against the video as it is now

The decision

A cut can move later timestamps; splitting a clip creates new IDs. Planning every segment from one copy of the timeline would let earlier edits invalidate later instructions. I chose to plan one segment at a time against the current document, with the film-wide choices made first.

The server controls the sequence. Each model call proposes edits within it, and targeted segment tools remain available for follow-up work. The cost is lower planning throughput, in exchange for current references, an inspectable order and shared direction across the film.

From the source

Orchestration specification. The decision is recorded as locked:

LOCKED by the owner 3 September 2026, on the recommendations as written. D9's value is locked as a target that Phase 1's measurements may lower with a written reason, never raise past 600 without a new decision.

The sequence, step by step:

1. Build the segment map and make the global planning call.
2. Carry global choices forward to each local planner.
3. Refresh the document, its timing and its clip references.
4. Plan and apply the next segment; repeat in order.
5. Record removals, refusals and applied work in the pass receipt.

The same specification records the code-controlled loop, the global-first policy and the rule that global operations proposed locally are stripped and logged. The excerpts below show the input construction behind the current-state requirement.

Local-pass implementation. The context is re-read before planning each segment, including the ten-second seams:

    // FRESH context per part: the previous part moved the document (D4).
    const ctx = await deps.segmentContext();
    const current = ctx.segments.find((s) => s.index === seg.index) ?? seg;
    version = ctx.version;

    const window = sourceWindowFor(current, ctx.doc);
    const seamed = clipsIn(
      ctx.clips,
      current.startMs - 10_000,
      current.endMs + 10_000,
    );

Local-pass implementation. Current clip IDs, global decisions and prior-pass context travel together:

    const segmentInput: PlannerSegmentInput = {
      index: current.index,
      count: allSegments.length,
      startMs: current.startMs,
      endMs: current.endMs,
      sourceFromMs: window.fromMs,
      sourceToMs: window.toMs,
      slice: sliceComprehension(comprehension, window.fromMs, window.toMs),
      clipIds: seamed.map((c) => c.id),
      seams: seamsFor(current, ctx.words, ctx.clips, ctx.durationMs),
      segmentTitles: allSegments.map((s) => s.title),
      globalDecisions: decisions,
      passSoFar: passSoFarLine(receipt.segments),
    };

What this shows

The specification fixes the execution order, and the code shows the fresh context read and the exact fields each planner receives. That is a direct defense against stale references, independent of how many edits a run happens to apply.