When The AI Approval Badge Was A Lie — spoolcast dev log 12

A bright green ”Approved” badge flashed on the screen, but the software underneath had completely crashed, leaving the user staring at a blank void. The interface confidently pretended the job was finished, while the actual code had silently failed. I am building Spoolcast, the system generating this very video. Instead of manually editing clips on a traditional timeline, Spoolcast automates video production. Software agents read your notes, draft scripts, plan shots, and render the final cut, pausing only for your strict human approval at each stage. By the end of this episode, you'll see how faking task completion in a user interface breaks complex automation. You'll also learn how swapping that guesswork for strict, verifiable checkpoints makes automated tasks safe and predictable. To understand this failure, we need to look at how the video gets made. First, an agent reads your notes. Second, it drafts the script structure. Third, it plans the visual pacing. Finally, it renders the video. At any of these steps, you might need to manually change a draft. The problem started with a simple question: how do we know if a user has made one of those manual changes? We tried to track this by adding a tiny status flag inside a single, massive file containing over five thousand lines of interface code. But passing that custom status tracker down through multiple layers of the application caused type-checking errors. To silence those errors, we bypassed the checker entirely. The hidden flaw was that our type checker—the tool that verifies code matches its intended data structures—was configured with an empty list of files to check. It was validating absolutely nothing. This clumsy workaround let broken code ship to production, blanking the entire page for the user. The deeper truth was that keeping all the project information in one massive file and forcing every piece of the interface to read from it meant every single change required matching paperwork at every hand-off. That bureaucratic friction made improvisation inevitable, and the interface just guessed the state instead of knowing it. We had to tear it down. We slashed that massive interface file to under five hundred lines, reducing it to a simple routing shell. In its place, we built a centralized state manager. This is a single source of truth that owns the status of every step. It tracks changes individually for each engine node, which is the specific processing step doing the actual work. This made the frontend guessing bug structurally impossible. It also solved a related backend deadlock. Previously, the system would block a stage because its output file was missing. At the exact same time, it would refuse to run the action that actually creates that file. Why? Because the state manager did not know the action was allowed to run. By tying the state manager directly to the engine, we ensured actions for the current stage are always correctly flagged as runnable. Now, the rules are strict and predictable. The moment you start typing, the step flips to in progress. If you try to edit a step that was already approved, the system immediately flags it as invalid. Downstream blockers are now scoped strictly to incomplete steps, so the whole system does not freeze over a minor delay. This brings us to an engine-first reality, where the user interface is no longer allowed to lie. In the new save flow, the interface sends your typed input to the core engine first, using only pre-approved actions. The interface only advances if the engine explicitly accepts that change and writes it to disk. This enforces a strict separation of powers. Drafting writes content, but it never approves it. Approving records your human approval gate—a deliberate human check—but it never overwrites the content you just reviewed. Because of this strict separation, we finally broke through the bottleneck at the fourth stage: rendering. Previously, the renderer had to wait for or reconstruct context from temporary, unverified memory. Now, the earlier stages, like script structure and visual pacing, have draft editors that prefill directly from real, on-disk files. The renderer simply reads these verified files, eliminating the performance lag of guessing what state the project was in. This technical fix solidifies a broader philosophy for the future: metered, auditable automation. Agent drafting is now metered from day one. A real engine script calls a model, writes the output to disk, and logs the exact token cost to a usage ledger, so you know exactly what you are paying for. The methodology is clear. Expensive, capable models are used to diagnose and architect the work, while cheaper, faster models execute the mechanical tasks. But every single step, regardless of the model used, remains bound by the same strict human approval gates. True automation is not about letting the agent improvise in the dark. It is about building strict, visible checkpoints that force the system to earn your approval at every single step.