The content pipeline problem is never the content. It's the clock.
I spent a week building original content feeders: GitHub trending repos for AI and dev topics scraped via pure stdlib (no API key, no rate limit drama), creator pool theme aggregation that pulls recurring signals from the accounts I already track, and a blended candidate queue that interleaves grounded Obsidian session drafts with ungrounded signal candidates. The generator knows which is which and picks the right prompt accordingly. Solid engineering all the way down.
All of it quietly failed because the launchd plist that fires the posting job used StartCalendarInterval times that no longer lined up with config.SLOTS. now_due_slot() returned None on nearly every tick. The queue filled up with perfectly good drafts. Zero posted.
The fix was not clever. Switch to StartInterval 600 so the job fires every 10 minutes regardless of calendar math. Add per slot idempotency so each posting window can fire at most once per local day. Add a POSTS_DAILY_FLOOR backstop that detects when you're behind daily pace and fires a floor catchup post even when no specific slot is technically due, with its own quiet hours guard and a capped jitter so it doesn't block the next normal tick.
That's it. The feeders were fine. The scheduler was lying.
This is the failure mode nobody writes about. Everyone documents the fun part: the clever idea sources, the quality gates, the prompt engineering. Nobody documents the part where your infrastructure level clock assumptions silently rot and the whole pipeline becomes a very sophisticated queue that never empties. The misalignment between StartCalendarInterval and the slot config is the kind of bug that looks like a content quality problem for days. You're auditing prompts, checking grounding, re reading voice profiles. The queue is full and the problem is a number in a plist file.
Time gated jobs that check "is it now?" are fragile by design. The question they're really asking is "does now match some assumption we hardcoded weeks ago?" That assumption drifts. The slot schedule changes. The plist stays stale. The checker keeps returning None and you keep wondering why output dropped.
The right model is polling plus idempotency. Fire frequently, check cheaply, record what you've already done, skip duplicates. StartInterval 600 plus a slot key in state is more robust than any StartCalendarInterval configuration you'll ever write, because it doesn't assume the cron adjacent firing time is meaningful. The slot check becomes stateful and the infrastructure becomes dumb.
I now need to audit every other launchd gated job in the stack for the same class of bug. Misaligned clock assumptions don't self report. They just quietly fail for days while you're debugging the wrong layer.