RFD_YT_Engine

RFD_YT_Engine is the content-pipeline system behind the channel. It does not treat “content” as a single layer — it splits the work into eight domains and keeps their boundaries explicit so that Streaming imports infra.obs, not pipeline.capture, and nobody accidentally couples a schedule change to a catalog sync.

The Problem

Running a YouTube channel at scale means keeping track of: what videos exist, which are scheduled, what playlists they belong to, whether a live stream is set up, whether the OBS scene will switch correctly, what the analytics trend looks like, and whether the title/duration signals suggest the right content type. These are not one big workflow. They are separate concerns that happen to share a channel.

Without hard boundaries, a small change in scheduling pulls in capture logic, a catalog sync accidentally mutates stream settings, and tests become integration tests for the whole system rather than unit tests for the part you changed.

The Architecture

Eight domains, explicit boundaries:

  • Ingest: Pulling in raw video, stats, and metadata.
  • Production: Editing, generation, and asset management.
  • Distribution: Publishing, playlist placement, and syndication.
  • Catalog: The canonical record of what the channel contains.
  • Scheduling: When content goes live and what it conflicts with.
  • Capture: Recording and sourcing raw material.
  • Streaming: Live operations and OBS integration.
  • Interface: The MCP surface that the rest of the tooling talks through.

Two-store data design:

  • channel_library is an upsert-in-place mirror of the channel state. It answers “what is on the channel right now?”
  • video_stats_cache is append-only. It answers “how is this metric trending over time?”

Splitting the two means the catalog can be rebuilt without destroying historical trend data, and stat imports can run independently of catalog syncs.

The MCP Interface

The engine exposes 24 MCP tools across Catalog, Scheduling, Distribution, Capture, Streaming, and Interface domains. Recent additions include preview_batch_reschedule for read-only schedule impact checks and apply_batch_reschedule for the write path, which logs every change before applying it. The playlist sync fix and content-type classification from title/duration signals are also part of the current surface.

The Discipline

Every structural decision is captured in an ADR. Domain imports are enforced by structural tests. The goal is not to prevent change — it is to make the cost of coupling visible before it becomes expensive.

GitHub: RFD_YT_Engine

Built with Python, MCP, and SQLite. 199 tests, 0 failures, 11 ADRs.