Eight Shorts, Same Timeslot. The Engine Found Them.

A developer built RFD_YT_Engine, an 8-domain Python system that manages the full lifecycle of a YouTube channel, including collision detection that found eight videos scheduled at the same timestamp. The system exposes a 24-tool MCP server to Claude Desktop and includes a custom YouTube Data API v3 and Analytics API v2 surface built from scratch. The engine resolved the conflicts with a single API call, eliminating the need to open YouTube Studio.

At 11:40 PM I asked my AI what was on my YouTube calendar for August. It told me I had eight videos scheduled to publish at the exact same timestamp on the same dates. Two Shorts, one slot. Eight times over. It also told me the fix, proposed the moves, and waited for my confirmation before touching anything. I didn't open YouTube Studio once. That's the short version of what RFD YT Engine is. The longer version starts about two months earlier, when I was running a pipeline called ContentEngine that was supposed to generate YouTube Shorts from AI-written game reviews. It had nine stages, a script generator, a brief generator, a voice synthesis layer, and a Pollinations.ai fallback for when nothing else produced a usable image. It was elaborate. It also produced videos nobody watched, including me. The pivot was simple: stop scripting. Use real gameplay footage. Film what actually happens when you play a game for the first time, cut out the moment that made you react, and put it online. No narration. No brief. No AI-written hook. Just the moment. The pipeline that came with ContentEngine didn't fit that model. So I built a new one from scratch. What RFD YT Engine actually is An 8-domain Python system that manages the full lifecycle of a YouTube channel — from raw session recording through to published video — with a 24-tool MCP server that exposes the entire thing to Claude Desktop. The eight domains: The architecture rule that held through every phase: one-directional dependency. No domain imports another's modules. Everything flows through shared infrastructure or the Interface layer. Eleven phases of development, zero ADR violations. The YouTube API surface I built the full YouTube Data API v3 and Analytics API v2 surface from scratch because the existing libraries were either too thin or too opinionated about what you could do with them. What that means concretely: The first sync attempt using search .list returned 64 videos. The correct number was 167. The difference: search only returns public videos. Private, scheduled, and unlisted are invisible to it. Switching to the uploads playlist fixed it. 167 videos, all detail columns hydrated, in 4 API calls. update video metadata had a silent data corruption bug. YouTube replaces the entire snippet object on update. Sending only the fields you want to change wipes the rest — tags gone, category reset. The fix: fetch the current snippet first, merge the changes, send the complete object. Traffic sources and audience retention are now queryable from conversation. How viewers found each video. Where they stopped watching. Direct tool calls, no dashboard. Collision detection The channel has 89 videos scheduled for future publication. The same-timestamp conflicts weren't obvious in YouTube Studio — it shows dates, not exact times, and two videos at 2026-08-29T02:00:00Z look identical until one of them fails to publish. Two detection functions: detect collisions finds same-game streaks exceeding a threshold across consecutive days. The Hotline Miami run that stretched six days without interruption — that's the target. The fix was interweaving 8 displaced Shorts into the streak window while filling the empty September calendar. detect same day collisions classifies each date with multiple videos as either true conflict same exact timestamp, real problem or multi slot different times, intentional . A Short at 2AM and a long-form session at 10PM on the same Sunday is the correct pattern. Two Shorts both at 2AM is a conflict. The function names the videos in both directions, and flags the content type — short, highlights, or long form — derived from duration and title signal. The eight true conflicts were resolved with one apply batch reschedule call after reviewing the preview. Ten video dates changed. No YouTube Studio. What it took 190+ certified tests. Phase-gated development with verified floors — no phase starts until the previous one passes at exactly the stated count. Every architectural decision locked in an ADR. The Director → Pipeline → Agent methodology throughout: I wrote the directives, the agent implemented, I verified against raw pytest output. No agent summary counts as proof. The most expensive bugs were the ones that looked like success. 64 videos that were actually 167. A metadata update that silently wiped tags. A calendar that showed empty because scheduled at was never being written even though the API returned the data. Each one found by querying what the system actually knew versus what it should have known. The outcome 167 videos in a local SQLite database. All detail columns hydrated. All scheduled dates correct. Collision detection live. Calendar management, metadata updates, batch reschedules — from conversation. The infrastructure layer for a channel that produces 1–2 Shorts per day and a long-form session every Sunday. Everything above the infrastructure — recording, playing, picking the moment — is still manual. That's the part that should be. Stack: Python · SQLite · YouTube Data API v3 · YouTube Analytics API v2 · FFmpeg · OBS WebSocket · MCP Methodology: Spec-Driven Development · Director → Pipeline → Agent · phase-gated test floors · ADR-documented decisions