Check failed, exit 0
This is a line from a deliberate reproduction, run in an isolated copy of the Pipedia repository. Both layout checks were made to fail, and the real wrapper that runs them was called:
Actual dry_all wrapper, mocked failed check+fit: 0 'Check failed\nCUT: overflow\n'
The 0 is the exit code. The wrapper printed “Check failed”, and then told whatever ran next that everything had succeeded. The warning existed. The stop sign did not.
That wrapper had already made 4 complete Pipedia series, 40 episodes in 2 formats each. Before making a fifth, the human asked Codex with Astra to stop looking at the next video and inspect the machine making them.
Two presenters, and a cursor
The episode is presented by Pip and Bo, who also present Pipedia. The scripts, voices and pictures are made with AI. A human directs and reviews the work, and appears in the video only as the cursor.
The request this time was not a feature. It was to fix the problems that kept recurring, before making another series.
What exists: a series of 20 videos
The result is Work, a Pipedia series of 10 episodes about jobs and pay, each made as a Short and a full version:
| Work | |
|---|---|
| episodes | 10 |
| finished videos | 20 |
| verified voice takes | 770 |
| scheduled | 14–25 Dec 2026, weekdays |
That is a production result, not an audience result. Nothing is known yet about how the videos do.
It was not 20 perfect first attempts, either. The first episode needed 2 visual corrections. What matters is what happened next: those corrections changed the workflow before the remaining videos were completed. The human then reviewed the other 18 without asking for a single follow-up edit, and called it the best workflow yet.
Fix the process, not the next video
An agent can fix the thing you are building. It can also fix the process that keeps breaking it.
The Pipedia repository had a growing list of rules that began “never do this”. Each one documented an obligation; none of them removed it. If every lesson becomes another instruction to remember, the next run still depends on someone remembering it.
So the repeatable parts moved into code: what counts as current, what must be checked, and what stops the next step. The creative questions stayed creative. A correct file cannot tell you whether a child understands the picture.
Start with the failures, and reproduce them
The review began with the making-of log, which records every failure across the 4 series:
| Series | Representative failures in MAKING-OF | Underlying workflow weakness |
|---|---|---|
| Money | Shared end cards broken in landscape; generated files later diverged from their builders | One ratio treated as sufficient; published output and current source have no stable release relationship |
| Business | Recaps and ledgers failed across many episodes; repeated empty stages; shared CSS collisions | Shared changes lack systematic regression coverage; creative timing is not captured as reviewable data |
| Shopping | Off-frame Shorts, wrong thumbnail fonts, incorrect changing numbers, stale listings | Secondary outputs missed; registration and asset dependencies are manual |
| Detectives | Captions and dialogue order diverged after a deletion; repeated duplicate IDs; 36.8-second static frame | Multiple copies of dialogue identity and ordering; component safety remains the author's responsibility |
Then it tried to make the checks fail on purpose. Every reproduction ran in a disposable copy, with the voice API and rendering mocked, so nothing was paid for and nothing real was touched:
check-all with deliberately stale Shopping TSV: 0
Explicit Shopping check with same drift: 1 ' FAIL round-trip differs: ep-06-why-the-till-says-more/short\n'
Caption checker with all captions missing: []
Caption checker with wrong number: []
Actual gen_vo with mocked API failure: 0 ' voices: pip @ 0.92, bo @ 1.08\n FAIL p1: {"detail":"simulated failure"}\n'Read the first 2 rows together. The transcript check that ran across every series stopped after the first one it was allowed to check, because a library function called sys.exit() even on success. A broken transcript in a later series went completely unchecked, and the check still exited 0. Checked on its own, the same series failed.
The caption check accepted a page with no captions at all, and it accepted the wrong amount of money, because it compared sets of words and left digits out of the comparison. The review’s own words:
An HTML file with no captions returns no faults. Its word-set similarity also accepts “You have twenty dollars” for “You have fifty dollars”; I reproduced both cases.
The voice generator printed FAIL and exited 0.
The question had been “did the command finish?” The question that mattered was “would the known mistake stop it?”
5 workstreams
The repair was organised into 5 workstreams:
| Change set |
|---|
| Repair check reliability |
| Introduce the episode model and audio manifest |
| Add the series manifest and stage runner |
| Repair shared timing and component contracts |
| Seal release packages |
In practice that meant 3 changes in what the workflow treats as true.
Dialogue has stable identities. Each line in a script now carries a persistent ID, a speaker and a scene. The transcript, the captions and the playback order are all derived from that one source, instead of being kept in separate handwritten tables that could drift apart.
A recording is reused only when it is current. The old rule was that an existing, non-empty audio file meant “skip it”, even when the sentence had changed. The voice manifest now records a hash of each request (text, speaker, voice, model and settings) and of the audio that came back. A take is reused only when both match.
Every stage records what it checked. Preparing, rehearsing, verifying, rendering and reviewing each leave a receipt tied to their actual inputs. Change an input, and the old success can no longer quietly authorise a new output.
The episode-specific pictures were kept on purpose. The aim was to remove coordination work, not to make every story use the same picture.
Test it on an episode that already exists
Before trusting a new series to the new workflow, it updated one existing Shopping episode, Why the till says more, in both formats.
One line of the Short changed, from “Ten dollars.” to “Exactly ten dollars.” The project’s making-of records the result:
One take changed, the other twelve did not, and the repeat run made zero requests. The full's thirty-three takes stayed original.
That small experiment answered a real question: can you change one thing without paying for, and disturbing, everything around it?
It also exposed a caption that ran below the frame in the full cut. The renderer’s own check passed; looking at the frames found the clipping. That became a bounds probe that measures every caption, including pages not yet on screen, and long captions now turn over in timed pages. Passing the first tests was the start of the trial, not its conclusion.
The stack
| Tool | Job |
|---|---|
| Codex with Astra | reviewed and edited the code |
| Python | kept dialogue, timing and production records connected |
| HyperFrames | rendered the HTML and animation |
| ElevenLabs | the voices |
| Metricool | scheduled the approved videos |
The list matters less than the boundary between the tools. Each step needs evidence it can trust from the previous one.
Lesson 1: test the stop sign
The cost. A wrapper that could print a failure and still return success, which made every reassuring summary after it misleading.
The evidence. The review named the line:
dry_all.sh:15 pipes the HyperFrames check through
grep … || true. The fit checker is piped throughhead -3, withoutpipefail.set -edoes not preserve the upstream failures.
The fix carries each check’s real failure through to the caller: capture the logs first, then show a summary, so that filtering the output can never decide whether the run succeeded. A test breaks the check deliberately and expects the workflow to stop.
There is a passing case too. Rejecting everything is easy, and it looks like safety. A useful check has to tell the two apart.
The rule. This works on a deployment, a report or an import. Put a known bad input through the real entry point. If it reaches the finish line, the checklist is decoration, and that needs fixing before another item is added to it.
Lesson 2: review one before making ten
The evidence. In the first full episode of Work, a cart was supposed to wait behind some boxes until the path was cleared. It appeared beside them instead, from the start of the shot.
The movement was scheduled for later. But the animation was written as a fromTo tween, and its starting offset was applied immediately, before the movement began:
A later GSAP fromTo tween applied its negative starting offset immediately. The cart now starts at its centred SVG position and uses a to tween when the dialogue calls for movement.
A browser test now recreates that exact mistake, including jumping backwards in the timeline, and verification rejects any delayed positional fromTo tween before a voice is bought.
The second correction was a board labelled “Needs doing, in progress, ready”. It flashed up near the 1:31 mark of the full cut without anything explaining it.
The rule. Make one, review it properly, turn what the review found into the workflow, then make the rest.
What a check cannot decide
The board fitted inside the frame. That was not the problem. The picture introduced an idea the dialogue had not earned.
The shot was removed, and the same board was then found in 2 later episodes before those versions were finished.
The workflow now captures the beginning, middle and end of every shot, with the dialogue and the visible labels beside it, and flags brief shots for review. A person still decides whether the words belong there and whether there is time to read them. The making-of says so directly:
A human or agent still judges meaning and reading time; the checker does not pretend that a label appearing in a frame proves it belongs in the story.
Some lessons become automatic failures. Others become better evidence for a judgement. Confusing the two would create another bad check.
Lesson 3: keep the good work still
The cost. New voice takes change the timing. Regenerating an untouched sentence can disturb pictures that were already right, and every regenerated take is paid for again.
The evidence. During Work, 16 caption-page boundaries were refined using measured word timing, and the narration stayed cached. The recording did not need to change because the page turn did, and the workflow knew which input had changed.
At the end, the release was sealed: source, audio, videos and checksums, in a release folder of its own. The approved bytes became a specific package.
The rule. That gives a later update a fixed starting point. “The latest file in this folder” is a much weaker promise.
What was actually fixed, and what was not
The 5 main workstreams were implemented, and the 5 immediate bugs from the review were fixed, each with a regression test.
The 4 older series were not migrated. They still run on their original builders, with their recorded exceptions. Off-device archiving and restoring were not finished either: that is future work, not a feature hidden inside a checksum.
Even the final handoff found a bug. The composition checker walked into the sealed release folder, tried to rebuild what it found there, and left Python cache files inside a package that was meant to be immutable:
The checker now excludes .production at every depth, with a regression test covering previews, releases and nested cut receipts. Only the extra bytecode was removed; the sealed release's original manifest and all file hashes verified again.
So the evidence is less rework on one complete new series. There is no measured percentage of hours saved, and none is claimed.
What is not known yet
The next question is whether this holds when a series needs very different visuals. Work is one successful run, and one run is evidence of improvement, not proof that the workflow is finished.
The habit is already clear: prove one episode, improve the shared process, then produce the rest.
Let the agent help you build the next thing. Give it the failure log for the way you build things, too.
The Pipedia repository is private, so there is nothing here to link to except the result: Pipedia on YouTube, where Work is scheduled to run in December.