Capstone: The Seven-Day Autonomous Cycle
Every component this track built runs alone in its own lesson. This capstone wires all of them into one function that plans, generates, gates, grades, schedules, publishes, mines, and reports for a full week -- and fails closed the moment any GO gate is bypassed.
Everything this track built, in one function
Eleven lessons back, this track started with a single claim: the Pro track's Instagram doctrine can run as a machine, not just a person's weekly discipline. Every lesson since has built one piece of that machine -- the vault that's the operation's source of truth, the quadrant gate that enforces coverage, the generation lane that turns demand into a brief, the grader that scores a draft against a rubric, the publisher that sends it live behind a human GO token, the upcycle scheduler that re-queues evergreen winners, the comment miner that turns an audience's own words into topic signal, the engagement agent that reaches outward on qualified lanes, the mutator that lets performance data reweight the strategy within clamped bounds, and the failure-mode discipline that assumes silent breakage is the normal case, not the exception.
None of those pieces, built alone, is the operation. The operation is what happens when they're composed into one function that runs for a week without a human touching it between days -- except at the one point that was never optional.
One day, traced end to end
Trace a single day through the composed system and every earlier lesson shows up as one step. The quadrant gate names which quadrant needs coverage today. The generation lane turns that into a draft brief, informed by whatever the comment miner has surfaced from the audience's own words. The gate gets asked a second time -- not "what's needed" but "is this specific draft admissible" -- before anything gets registered into the vault, because a quadrant can drift into overfed between the demand call and the finished draft. The grader scores what got generated and returns a band: auto-queue, revise, or kill. Only auto-queue continues.
Then the one step that was never automated away: a real human GO token has to exist for this specific asset, or the day stops there. Not a fabricated token, not an assumption that approval is implied by everything upstream having gone well -- an actual token, checked, present or absent. Present, the publisher runs (simulated, in this capstone) and the day's ledger records a publish. Absent, the day's ledger records exactly that: blocked, not published, not silently dropped.
Meanwhile the mutator and the upcycle scheduler aren't waiting for the publish step to finish -- they're reading the accumulating performance data from earlier days and adjusting what tomorrow's plan step will ask for, with the off-axis guardrail from the previous lesson still fully wired in. Nothing in this capstone relaxes any constraint an earlier lesson established. It just proves they all hold at once, for seven consecutive days, without a human re-checking each one by hand.
That's the actual test this capstone runs, and it's worth stating precisely, because it's easy to read "composes every component" as a checklist exercise -- wire up eight function calls and call it done. The harder requirement is that every constraint each of those eight lessons established has to survive being composed with the other seven, under conditions none of the individual lessons tested alone. The quadrant gate was built and verified against a single admission check; here it has to hold up across seven consecutive calls where its own state is shifting underneath it, day after day, based on what the mutator is doing with the previous days' results. The publisher's GO-gate check was built and verified against one publish call; here it has to refuse correctly on a day when everything upstream went perfectly, because the one thing it actually checks -- a real token, present or absent -- has nothing to do with how well the rest of the pipeline performed that day.
Why ops safety governs the whole loop, not just publishing
The failure-mode discipline from the previous lesson isn't a separate concern bolted onto this capstone -- it's the reason the loop can run for seven days without a human watching every step. A day that throws an exception mid-generation has to be caught and logged, not allowed to take the rest of the week down with it, exactly the same silent-failure logic that governs a publish call returning a 200 that didn't actually land. The composed system is only as trustworthy as its weakest untested seam, and the seams between components are exactly where a lesson built and verified in isolation can still hide a gap that only shows up once something else is running alongside it.
The ledger is the point
A seven-day cycle that only reported its successes would be worse than useless -- it would look identical to a healthy week whether three days quietly failed to publish or all seven genuinely went well. The ledger this function returns records every day's actual outcome: published, skipped for a low grade, blocked because the quadrant gate rejected the draft, blocked because no GO token existed, or caught as an error that didn't take down the rest of the week. A blocked-no-go row isn't a bug in the ledger -- it's the ledger doing exactly its job, proving the gate held on the one day it mattered.
Building the cycle runner
The version you're about to fix runs top to bottom without an obvious error anywhere -- it calls every helper in a reasonable-looking order, awaits the right things, and returns something. What it gets wrong is exactly the shape of bug this whole track has been warning about: a fabricated token where a real one should be checked, gates that get skipped instead of consulted, and a single unhandled exception that would take the rest of the week down with it. Fixing it is the same discipline as every lesson before this one, applied all at once: check first, log what happened, never let one failure hide another, and never let anything substitute for a human saying go.