Gerenciamento de Canais do YouTube com IA: O Caso do RFD_YT_Engine

Às 23:40, perguntei à minha IA o que estava no meu calendário do YouTube para agosto.

Ela me disse que eu tinha oito vídeos programados para publicar no exato mesmo horário nas mesmas datas. Dois Shorts, um slot. Oito vezes.

Ela também me disse a solução, propôs as mudanças e esperou minha confirmação antes de tocar em qualquer coisa.

Eu não abri o YouTube Studio uma vez.

Essa é a versão curta do que é o RFD_YT_Engine. A versão longa começa cerca de dois meses antes, quando eu estava executando um pipeline chamado ContentEngine que deveria gerar Shorts do YouTube a partir de análises de jogos escritas por IA. Ele tinha nove etapas, um gerador de roteiros, um gerador de resumos, uma camada de síntese de voz e um fallback do Pollinations.ai para quando nada mais produzia uma imagem utilizável. Era elaborado.

Ele também produzia vídeos que ninguém assistia, incluindo eu.

A mudança foi simples: parar de roteirizar. Usar filmagens reais de gameplay. Filmar o que realmente acontece quando você joga um jogo pela primeira vez, cortar o momento que fez você reagir e colocar online. Sem narração. Sem resumo. Sem gancho escrito por IA. Apenas o momento.

O pipeline que veio com o ContentEngine não se encaixava nesse modelo. Então eu construí um novo do zero.

O que é realmente o RFD_YT_Engine

Um sistema Python de 8 domínios que gerencia todo o ciclo de vida de um canal do YouTube — desde a gravação de sessão bruta até o vídeo publicado — com um servidor MCP de 24 ferramentas que expõe tudo isso ao Claude Desktop.

Os oito domínios:

• Captura — integração com OBS, monitoramento de sessão, detecção de jogos
• Ingestão — transcrição do Whisper, extração de batidas, marcação de sessão
• Produção — montagem de Shorts via FFmpeg, montagem de destaques com bridge TTS, mapeamento de batida para clipe
• Distribuição — uploads da API de Dados do YouTube v3, resolução de metadados, publicação agendada
• Catálogo — espelho completo do canal em SQLite local, 167 vídeos com todas as 11 colunas de detalhes preenchidas
• Agendamento — gerenciamento de calendário, detecção de colisões, reestruturação round-robin
• Streaming — controle do WebSocket do OBS, gerenciamento de sessão de stream
• Interface — O servidor MCP. O único domínio permitido a chamar através das fronteiras de domínio.

A regra de arquitetura que se manteve em todas as fases: dependência unidirecional. Nenhum domínio importa os módulos de outro. Tudo flui através da infraestrutura compartilhada ou da camada de Interface. Onze fases de desenvolvimento, zero violações de ADR.

A superfície da API do YouTube

Eu construí a superfície completa da API de Dados do YouTube v3 e da API de Análise v2 do zero porque as bibliotecas existentes eram ou muito finas ou muito opinativas sobre o que você poderia fazer com elas.

O que isso significa concretamente:

A primeira tentativa de sincronização usando search().list() retornou 64 vídeos. O número correto era 167. A diferença: a busca só retorna vídeos públicos. Privados, agendados e não listados são invisíveis para ela. Mudar para a playlist de uploads resolveu. 167 vídeos, todas as colunas de detalhes preenchidas, em 4 chamadas de API.

update_video_metadata() tinha um bug de corrupção de dados silencioso. O YouTube substitui todo o objeto de snippet na atualização. Enviar apenas os campos que você deseja alterar apaga o resto — tags desaparecem, categoria redefinida. A solução: buscar o snippet atual primeiro, mesclar as mudanças, enviar o objeto completo.

Fontes de tráfego e retenção de audiência agora são consultáveis a partir da conversa. Como os espectadores encontraram cada vídeo. Onde pararam de assistir. Chamadas diretas de ferramentas, sem painel.

Detecção de colisões

O canal tem 89 vídeos programados para publicação futura. Os conflitos de mesmo horário não eram óbvios no YouTube Studio — ele mostra datas, não horários exatos, e dois vídeos em 2026-08-29T02:00:00Z parecem idênticos até que um deles falhe ao publicar.

Duas funções de detecção:

detect_collisions() encontra sequências de mesmo jogo que excedem um limite em dias consecutivos. A corrida de Hotline Miami que se estendeu por seis dias sem interrupção — esse é o alvo. A solução foi entrelaçar 8 Shorts deslocados na janela da sequência enquanto preenchia o calendário vazio de setembro.

detect_same_day_collisions() classifica cada data com múltiplos vídeos como true_conflict (mesmo horário exato, problema real) ou multi_slot (horários diferentes, intencional). Um Short às 2AM e uma sessão longa às 10PM no mesmo domingo é o padrão correto. Dois Shorts ambos às 2AM é um conflito. A função nomeia os vídeos em ambas as direções e sinaliza o tipo de conteúdo — short, destaques ou long_form — derivado da duração e do sinal do título.

Os oito conflitos verdadeiros foram resolvidos com uma chamada apply_batch_reschedule após revisar a prévia. Dez datas de vídeo mudaram. Sem YouTube Studio.

O que foi necessário

Mais de 190 testes certificados. Desenvolvimento com fases controladas com andares verificados — nenhuma fase começa até que a anterior passe exatamente na contagem declarada. Cada decisão arquitetônica registrada em um ADR. A metodologia Diretor → Pipeline → Agente ao longo de tudo: eu escrevi as diretrizes, o agente implementou, eu verifiquei contra a saída bruta do pytest. Nenhuma contagem de resumo de agente conta como prova.

Os bugs mais caros foram aqueles que pareciam sucesso. 64 vídeos que na verdade eram 167. Uma atualização de metadados que silenciosamente apagou tags. Um calendário que mostrava vazio porque scheduled_at nunca estava sendo escrito, mesmo que a API retornasse os dados. Cada um encontrado consultando o que o sistema realmente sabia versus o que deveria saber.

O resultado

167 vídeos em um banco de dados SQLite local. Todas as colunas de detalhes preenchidas. Todas as datas programadas corretas. Detecção de colisões ao vivo. Gerenciamento de calendário, atualizações de metadados, reprogramações em lote — a partir da conversa.

A camada de infraestrutura para um canal que produz 1–2 Shorts por dia e uma sessão longa todo domingo. Tudo acima da infraestrutura — gravação, jogando, escolhendo o momento — ainda é manual. Essa é a parte que deve ser.

Pilha: Python · SQLite · API de Dados do YouTube v3 · API de Análise do YouTube v2 · FFmpeg · Controle do WebSocket do OBS · MCP

Metodologia: Desenvolvimento Orientado a Especificações · Diretor → Pipeline → Agente · andares de teste controlados por fase · decisões documentadas em ADR