D7 One Episode Wrapped: Stringing Six Stages Into an End-to-End Pipeline and Tallying the First Bill

Today's Goals

Produce one complete episode from a single sentence with one command, and know exactly where it's stuck if any step fails
Measure the time and cost of each stage, and point out where the bottleneck is
List the pipeline's three fragile points right now, and say which day of week two fixes each one

Over six days you got six stages running individually, but your hands still sit between them: after the script you copy the JSON into the next script by hand; after dubbing you check by hand that the files exist. Today, take your hands off. When you finish, scroll back up and tick the three goals off.

Plain-Language Walkthrough

The day an episode wraps is when the problems start

Film crews call the last shot the wrap, and everyone applauds. Anyone who has done post knows the problems start at that moment: material scattered across three drives with different naming, the sound recordist's timecode two frames off from camera, an NG take whose filename differs from the good one by a single letter.

String six stages together and you hit exactly those things. None of them existed while you debugged each stage alone, because your brain was doing the handoffs: you knew where the last script wrote its files, you knew which JSON to feed the next step. Connected up, that knowledge has to move out of your head and into the code.

The first thing to bite is artifact paths. Running the image script alone, output/first-frame.png is perfectly fine. Connected up, the second run overwrites the first one's output; a mid-run failure leaves you unable to tell which files on disk belong to this attempt; and comparing "did changing the sentence make it better" is impossible because both runs' artifacts are mixed together.

There is one fix, and the rule has to be laid down from the start: allocate a run identifier per run and hang every artifact under it.

TextText

work/
└── runs/run-20260907-001/
    ├── run.json              this run's metadata and cost ledger
    ├── script/               script, character cards
    ├── assets/               character look tests
    ├── shots/<shotId>/       first frame, shot video, voice
    ├── timeline/             the timeline table
    └── output/               cut, subtitles, cover

The layout looks plain, but it settles three problems at once: two runs never overwrite each other; leftovers from a failure are obvious; and reproducing a result is a matter of zipping one directory and sending it to a colleague.

run.js

// One run's directory layout. The whole pipeline gets paths through this object;
// any place that concatenates a path string directly is a latent bug.
export class Run {
  constructor(id) {
    this.id = id
    this.dir = `work/runs/${id}`
    this.costs = []
  }
 
  path(...parts) {
    return [this.dir, ...parts].join('/')
  }
 
  // Record spend the moment it happens, not by tallying after the run finishes -
  // a tally done afterwards is always wrong when the run failed.
  record(entry) {
    this.costs.push({ ...entry, runId: this.id, at: new Date().toISOString() })
  }
}
 
export function newRunId(now = new Date()) {
  const p = (n, w = 2) => String(n).padStart(w, '0')
  const stamp = `${now.getFullYear()}${p(now.getMonth() + 1)}${p(now.getDate())}`
  return `run-${stamp}-${p(Math.floor((now.getHours() * 60 + now.getMinutes()) % 1000), 3)}`
}

run.py

# One run's directory layout. The whole pipeline gets paths through this object;
# any place that concatenates a path string directly is a latent bug.
from datetime import datetime
 
 
class Run:
    def __init__(self, run_id: str):
        self.id = run_id
        self.dir = f"work/runs/{run_id}"
        self.costs: list[dict] = []
 
    def path(self, *parts: str) -> str:
        return "/".join([self.dir, *parts])
 
    # Record spend the moment it happens, not by tallying after the run finishes -
    # a tally done afterwards is always wrong when the run failed.
    def record(self, entry: dict) -> None:
        self.costs.append({**entry, "runId": self.id, "at": datetime.now().isoformat()})
 
 
def new_run_id(now: datetime | None = None) -> str:
    now = now or datetime.now()
    seq = (now.hour * 60 + now.minute) % 1000
    return f"run-{now:%Y%m%d}-{seq:03d}"

The second problem is log flooding. Six stages each print their own logs, one command scrolls hundreds of lines past, and when something breaks you cannot tell which stage broke it. Today's logging rule is simple too: each stage prints one line on start and one line on finish with its elapsed time and artifact count, and pushes the rest into files. What stays on the terminal should be a progress table you can scan at a glance, not a running diary.

So what most deserves measuring once things are connected? Not "did it run," but how much time and how much money each step took. Those two numbers decide what you fix first next week — and they will most likely overturn your intuition.

One itemized bill beats ten pieces of advice

Here is a real run's bill, four shots, a twenty-one-second episode:

TextText

Bill (share of elapsed time / estimated spend)
  stage          elapsed   share                  calls  artifacts  estimated
  script           32ms                         1%    1     2  CNY 0.0000
  assets           93ms                         2%    2     2  CNY 0.0500
  first-frame     120ms                         2%    3     3  CNY 0.0750
  clip           2518ms  █████████             47%    3     3  CNY 10.4950
  voice           236ms  █                      4%    5     7  CNY 0.0193
  compose        2403ms  █████████             44%    0     2  CNY 0.0000
  total       5402ms                                 CNY 10.6393

How should this be read? One thing must be said first: those spend figures are estimates. In offline mode every real amount is 0, so the program converts usage using the official pay-as-you-go rates — 0.025 per image, 0.50 per second of 768P video. For speech the vendor publishes only resource-package pricing, so that figure is an approximation derived from a package, not a listed rate. A bill may be an estimate, but it must say that it is one — that is the piece of professionalism most often skipped when building cost observability.

The first conclusion is glaring: more than ninety-eight percent of this episode's money went to video. The script is nearly free, voice is under two cents, five images together are twelve and a half cents, and three shots of video are ten and a half. That ratio is not specific to this course; it is the basic shape of AI video production.

A great deal follows from it, enough to state on its own line: every engineering decision on this pipeline orbits the question of how to call the video API one fewer time. Idempotency, caching, reference-image reuse, draft tier before final tier, budget circuit breakers — every one of next week's topics traces back to this.

Read the elapsed column carefully. In offline mode compose looks slowest, because the video API is stubbed and local ffmpeg becomes the bulk of the work. In real mode a clip queues for minutes and that column is completely rewritten. So you must know which of the bill's numbers mean anything offline and which do not, or you will optimize against a fake picture. And one more layer: those millisecond figures came from one particular machine and yours will differ. What is reproducible in this table is the call counts, the artifact counts and the estimated spend (the same input always computes the same result); what is not reproducible is the elapsed time — use it only for the relative relationship between stages, never as a benchmark to copy.

The aggregation code is simple; only one thing deserves attention — keep the estimation separate from real amounts.

billing.js

// Unit prices from the official pay-as-you-go page, in CNY. The speech figure is an
// approximation derived from a resource package, not a listed rate.
const PRICE = { imagePerItem: 0.025, videoPerSecond: 0.5, ttsPerCharacter: 0.00035 }
 
// Use the real amount if the call really ran; only estimate offline. Never mix the two,
// or the books will never balance.
export function estimateCny(entry) {
  if (entry.costCny > 0) return entry.costCny
  if (entry.kind === 'image') return entry.units * PRICE.imagePerItem
  if (entry.kind === 'video') return entry.units * PRICE.videoPerSecond
  if (entry.kind === 'tts') return entry.units * PRICE.ttsPerCharacter
  return 0
}
 
export function buildBill(reports, costs) {
  return reports.map((r) => {
    const mine = costs.filter((c) => c.nodeId === r.id)
    return {
      nodeId: r.id,
      ms: r.ms,
      calls: mine.length,
      artifacts: r.artifacts.length,
      estimatedCny: Number(mine.reduce((s, c) => s + estimateCny(c), 0).toFixed(4)),
    }
  })
}

billing.py

# Unit prices from the official pay-as-you-go page, in CNY. The speech figure is an
# approximation derived from a resource package, not a listed rate.
PRICE = {"image_per_item": 0.025, "video_per_second": 0.5, "tts_per_character": 0.00035}
 
 
# Use the real amount if the call really ran; only estimate offline. Never mix the two.
def estimate_cny(entry: dict) -> float:
    if entry["costCny"] > 0:
        return entry["costCny"]
    key = {"image": "image_per_item", "video": "video_per_second", "tts": "tts_per_character"}.get(entry["kind"])
    return entry["units"] * PRICE[key] if key else 0.0
 
 
def build_bill(reports: list[dict], costs: list[dict]) -> list[dict]:
    bill = []
    for r in reports:
        mine = [c for c in costs if c["nodeId"] == r["id"]]
        bill.append({
            "nodeId": r["id"],
            "ms": r["ms"],
            "calls": len(mine),
            "artifacts": len(r["artifacts"]),
            "estimatedCny": round(sum(estimate_cny(c) for c in mine), 4),
        })
    return bill

Step four blows up: today we use the dumbest possible approach

Now do something counterintuitive: make the pipeline fail on purpose. Break the video stage — the fourth one — deliberately, and see how this line behaves today.

TextText

  > script: script and character cards ... 32ms, 2 artifacts
  > assets: character look tests ... 80ms, 2 artifacts
  > frames: first frame per shot ... 158ms, 4 artifacts
  > clips: shot videos ... 625ms FAILED
 
  clip failed: (injected failnode4) the clip stage failed: the vendor returned a non-retryable error
 
Pain report
  failed stage: clip
  artifacts already produced: 7, sitting safely in work/runs/run-20260907-741
  money already spent, estimated: CNY 3.1250
  the only option now: run the whole command again from the top.
  Which means that CNY 3.1250 gets spent a second time, inevitably, not by bad luck.

Three details deserve staring at.

First, eight artifacts are still on disk and none of them help. The script, the character cards, two look tests, four first frames — all intact, all directly reusable files. But this pipeline does not know they are reusable, so a re-run regenerates every one of them.

Second, the failing stage spent money too. Video is called shot by shot, and the first shot had already gone out when it blew up; those three yuan were genuinely paid. If the bill only counted successful stages, that money would vanish from the post-mortem — so this course's bill records failed nodes too, with an artifact count of 0 and a spend that is not 0. In real incident reviews this matters enormously: you must be able to answer "how much did this outage burn."

Third, the program can do nothing about it. All it can do is record what finished, print a report, and exit. No retry, no cache, no resume.

That is deliberate. Add retries and caching casually today and you never feel how much their absence hurts, and tomorrow's workflow engine becomes a thing you learn without knowing why. So today's failure policy has exactly three actions: record, report, exit.

One thing must be right already, though: a failure must not discard the elapsed time and spend of the stages that did finish. That is what decides whether your pain report has numbers in it.

sequential.js

// The dumbest sequential runner: record as you go, stop on error.
// The point is not "how it runs" but "what you still hold when it breaks" - an
// implementation that rejects all the way out throws away the earlier stages' elapsed
// time and spend, which is exactly what you most need on a failure.
export async function runSequential(stages) {
  const reports = []
  for (const node of topoSort(stages)) {
    const started = Date.now()
    try {
      const result = await node.run()
      reports.push({ id: node.id, ms: Date.now() - started, artifacts: result.artifacts })
    } catch (err) {
      // The failing stage goes into the bill too: it has usually already made a paid call.
      reports.push({ id: node.id, ms: Date.now() - started, artifacts: [], note: 'failed, artifacts void' })
      return { reports, failedAt: node.id, error: err }
    }
  }
  return { reports }
}

sequential.py

# The dumbest sequential runner: record as you go, stop on error.
# The point is not "how it runs" but "what you still hold when it breaks" - an
# implementation that re-raises straight out throws away the earlier stages' elapsed
# time and spend, which is exactly what you most need on a failure.
import time
 
 
def run_sequential(stages: list) -> dict:
    reports = []
    for node in topo_sort(stages):
        started = time.time()
        try:
            result = node.run()
            reports.append({"id": node.id, "ms": int((time.time() - started) * 1000), "artifacts": result["artifacts"]})
        except Exception as err:
            # The failing stage goes into the bill too: it has usually already paid for a call.
            reports.append({"id": node.id, "ms": int((time.time() - started) * 1000), "artifacts": [], "note": "failed"})
            return {"reports": reports, "failedAt": node.id, "error": err}
    return {"reports": reports}

The first screening: where to point your eyes

It runs, the books are done, and now comes the least technical and most often skipped step of the day: watch the cut from start to finish.

The most dangerous state for an automated pipeline is not an error; it is producing garbage with every light green. Every stage returned success, every file is present, and the episode is unwatchable. So this step cannot be skipped, and it needs a checklist rather than a vibe.

Pass one, continuity: is the same character the same face across four shots? This is where AI short drama collapses most easily, and it is what D3's reference-image techniques exist to solve. Pass two, sync: does the picture cut away before a line finishes? Do subtitle and sound start at the same instant? Pass three, picture quality: is any shot obviously darker, softer or off in color compared to the others? Pass four, the cover: can you tell from that frame what the episode is about?

From script to system: the three pieces next week fills

This line runs, but it is a script, not a system. What is missing? Sort today's problems by nature and they fall into exactly three groups.

One: reliability. Any failed step means starting over, and artifacts you already paid for are thrown away. The CNY 3.1250 on that pain report is the price, against CNY 10.6393 for a whole episode — and in real work you hit this several times a day. D8's workflow engine fills it: an idempotency key per node, content-addressed artifacts on disk, re-runs reduced to a set difference, and a second run whose paid-call count should be 0.

Two: throughput. Six stages in a straight line means one episode costs the sum of six segments, and multiple episodes just queue. But you cannot simply crank concurrency to the maximum, because the vendor has quotas — the speech API allows twenty requests per minute for topped-up accounts, and one episode with forty storyboard entries means forty syntheses, so without a gate you will hit the limit. D9 fills it: per-vendor concurrency gates, token buckets, priority queues.

Three: control. Right now the cut's quality depends on human eyes, with nowhere to record the findings, and cost can only be tallied after the fact rather than intercepted before it. D10's review desk, D11's QC and compliance, and D12's cost routing and budget circuit breakers fill it.

Source Reading

Hands-On Lab

🧪 D7 lab: an end-to-end script that turns one sentence into an episode, plus a run bill

Code location: labs/ai-drama-pipeline/day-07-end-to-end

Acceptance criteria:

One command runs all six stages, and the run's directory holds the cut, the subtitles and the cover.
The bill lists elapsed time, share of elapsed time, call count, artifact count and estimated spend per stage, and names which stage is slowest and which is most expensive.
Change the sentence and run again: all six stages' inputs change with it, proving the business logic is really running rather than replaying a recording.
After deliberately failing the fourth stage: the process exits non-zero, that row of the bill has spend but 0 artifacts, and the pain report prints the money already spent plus "the only option is to run it all again."
The terminal ends with the screening checklist and the three fragile points, each naming the day of week two that solves it.

Before starting, confirm all six earlier labs still run individually, especially the ffmpeg one — once connected, an error is buried in hundreds of log lines, and checking separately saves a lot of time. Today's lab needs no API key; offline, all six stages execute for real and only the four network egress points are stubbed.

Run the full flow once, confirm the six stages complete in order, and open the cut in this run's directory.
Read the bill, name the most expensive stage and its percentage of total spend, then explain why the elapsed column is untrustworthy offline.
Change the sentence and run again, compare the two run directories, and confirm they neither overwrite nor contaminate each other.
Fail the fourth stage deliberately, read the pain report, and write down the "money already spent" figure — tomorrow you turn it into 0.
Watch the whole cut against the screening checklist, write down every quality problem you find, and tag each with the stage responsible for it.

Interview Questions

Today's 3 questions are in the question bank below, focused on the engineering problems that only appear after connecting stages, measuring time and cost per stage, and identifying and ranking fragile points. Read the analysis before the key points — practicing the derivation beats memorizing them. The cn / global labels let you pick by target market.

Checklist and Tomorrow

I can produce one complete episode from a single sentence with one command, and know exactly where it's stuck if any step fails
I can measure the time and cost of each stage, and point out where the bottleneck is
I can list the pipeline's three fragile points right now, and say which day of week two fixes each one
I can explain why every artifact must hang under a run identifier
I can say which of the bill's numbers are untrustworthy offline, and why
All 5 lab acceptance criteria pass
I can answer at least 2 of the 3 interview questions without looking at the key points

Tomorrow (D8) we swap this sequential script for a stateful workflow engine: an idempotency key per node, content-addressed artifacts on disk, and a re-run after failure that only completes the unfinished part. Why is it first in week two? Because the number on today's pain report is directly quantifiable waste, and video is ninety-eight percent of cost — fix the piece a number can prove is the least error-prone principle in engineering prioritization.

One Episode Wrapped: Stringing Six Stages Into an End-to-End Pipeline and Tallying the First Bill

Today's Goals

Plain-Language Walkthrough

The day an episode wraps is when the problems start

One itemized bill beats ten pieces of advice

Step four blows up: today we use the dumbest possible approach

The first screening: where to point your eyes

From script to system: the three pieces next week fills

Source Reading

Hands-On Lab

Interview Questions

Checklist and Tomorrow

Interview questions

Comments