A YouTube Pipeline in Eight Enforced Domains

Context

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. It replaced the earlier GameReviewAgent/content-engine, which was retired and archived on 2026-09-13 (ADR-001).

The problem it solves

Running a YouTube channel 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.

What I built

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.

All eight domains are certified (ADR-002), and domain imports are enforced by structural tests — a coupling that violates the boundaries fails the suite, it doesn’t just get noticed someday.

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?” — with pruning that keeps each video’s newest row.

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 surface, 27 tools: across Catalog, Scheduling, Distribution, Capture, Streaming and Interface — including the write-capable apply_reweave, publish_product, update_video, apply_batch_reschedule and redate_private_shorts. Destructive batch actions come in a read-only preview paired with an audited write: preview_batch_reschedule checks schedule impact without touching anything, and apply_batch_reschedule logs every change before applying it. The playlist sync fix and content-type classification from title/duration signals are part of the same surface.

It ships video, not just metadata. Beat-YAML Short production works end to end, including an ffprobe-verified render.

First-time setup is three commands and a checkup. Added 2026-09-22: setup desktop registers the MCP server in Claude Desktop (backing up the config first), setup auth does the one-time YouTube OAuth and verifies it with a read-only call, and setup sync wires the scheduled sync. doctor reports which setup steps are still missing. A sync-library command — incremental by default, --full weekly — lets a scheduled task keep the channel library fresh.

Every structural decision is an ADR. Eleven of them govern the design. The goal is not to prevent change — it is to make the cost of coupling visible before it becomes expensive.

Result

420 tests pass, 0 failed, 0 skipped (7 deselected) across the eight domains. Work on the engine is dispatched through AgentFlow as directives and verified before merge.

Tech notes

Python, MCP and SQLite in the two-store design, the YouTube API for channel state, and 11 architecture decision records. Source: RFD_YT_Engine.