Part 3: A Loop Whose Job Is to Do Nothing

TL;DR This loop runs on a schedule and succeeds by doing nothing almost every night. The pass/fail check is plain deterministic code, with no AI in the decision. It can run entirely free on your own machine. Only the cloud/CI version needs a paid API key. Plus the one bug that broke all three loops. The first two loops in this series work the same way from your side: you start them and watch. This last one runs on a schedule, like a nightly job, while you are not looking. That changes what success even means. A scheduled maintenance loop is doing its job when it does nothing. It should run every night, find nothing wrong, cost almost nothing, and still be there on the night something actually breaks. This part covers that loop, the hook mechanism that the whole series relies on, and a bug that broke all three loops in the least convenient place possible. The definition one more time, since this is Part 3 of 3: a loop is a trigger that runs the agent, a check the agent cannot edit that decides pass or fail, and a repeat, or here a wait until the next run. The only new thing this time is the trigger. A timer starts it instead of you. The problem this loop solves The browser's poster data is baked ahead of time into JSON files and images. In a real deployment that data goes stale as films are added and metadata changes, so you want to regenerate it every so often and confirm it is still valid before it ships: on a timer -> regenerate the data -> validate it -> green ships, red shouts The gate: a plain check with no model in it The check is a Node script. For every region file it confirms three things and exits non-zero if any of them fail: it matches the expected JSON schema, it has at least the minimum film count, and every poster file it points to actually exists on disk. There is no language model in that list. The regeneration step might use Claude, but the decision about whether the data is good is plain, deterministic code. That is on purpose. You do not want the