17AI agentsPer-agent model + temperature
86Use-casesApplication layer, Result-typed
210Test files55 property-based suites
60Animation themesStudio to Neo-Brutalist
A / Architecture
Four layers.
One protected workflow.
01Presentation
HTTP, SSE, UI, controllersNext.js feature modules and Express controllers translate product actions into use-case requests. Server-sent events stream progress with sequence ids and 15-second heartbeats, and interactive MCP Apps render the same state inside an agent's chat.
presentation/controllers · SSE helpers · MCP routes 02Application
Use cases and orchestration86 use-cases coordinate repositories, queues, model ports, storage and streaming, returning explicit Result values instead of using exceptions for control flow.
application/use-cases · Result<T, E> everywhere 03Domain
Rules, state, invariantsPipelineJob owns legal stage transitions, stage-guarded artifact setters, progress state and failure state. Infrastructure cannot redefine the workflow's business rules.
PipelineJob.transitionTo() · setGeneratedCode() guards 04Infrastructure
Providers and persistencePrisma, 14 BullMQ workers, Redis, five routable model providers, two TTS backends, object storage, Remotion and FFmpeg sit behind interfaces, wired at explicit composition roots. Rendering itself is a swappable provider: in-process, or a separate HTTP render service.
repositories · workers · service adapters · ModelRegistry B / Reliability
Failure is bounded,
not denied.
R1Checkpoint the work, not just the status
One Postgres row per job stores the script, fact-check report, audio path, transcript, scene directions, generated code and rendered asset paths. Every worker saves immediately after each legal transition, so the database advances in lockstep with the state machine and any job can be understood from durable state alone.
PostgreSQL · Prisma upsert R2Retry according to stage economics
Per-stage BullMQ policy: three attempts with exponential backoff where models are flaky, exactly one where output is expensive or billable. Failed jobs are cleared and resumed from their checkpointed stage rather than restarted.
BullMQ · per-stage policy R3Replay progress after a disconnect
Progress events publish live over Redis and append to a durable list. A reconnecting browser replays the buffer in order, then rejoins the live channel; buffers expire an hour after completion. Once a stage is durable, Postgres, not the buffer, is the source of truth, so a refresh can never resurrect pre-edit content.
SSE · Redis buffer · seq ids R4Never leave the interface spinning
A worker-level failure listener catches even out-of-memory kills, persists the failure and emits a terminal progress event. Locks run ten minutes with five-minute stall checks, and long stages extend their lock mid-flight.
Failure listener · 10-min lock R5Treat generated code as untrusted input
Every scene faces eight numbered checks, learned from real failures and beginning with an esbuild compile: lowercase img tags, dead logo CDNs, frame arithmetic bugs, unknown icon names, hallucinated identifiers and more. Errors return to the model as targeted repair hints; in preview, an agentic autofixer isolates the crashing scene and patches it surgically.
esbuild · 8 static gates · autofixer R6Bound runtime validation
Client-submitted scenes additionally render three frames inside an isolated worker thread with mocked Remotion globals and a five-second timeout, then pass a layout audit for unclamped animations and under-built scenes.
worker_threads · 5s ceiling C / Decision record
Explicit choices.
Visible tradeoffs.
D-01A state machine over a giant request
- Context
- Video generation crosses slow model calls, speech services, asset storage, code execution and headless rendering.
- Decision
- Model the product as durable stages owned by a domain entity and execute processing stages through a queue.
- Tradeoff
- More operational machinery and transition rules, in exchange for resumability, visibility and isolated failure.
D-02Human review before expensive production
- Context
- A fluent script can still be wrong, off-brand, or simply not what the creator wants. Downstream audio and rendering amplify that mistake.
- Decision
- Fact-check generated claims, then pause for script approval; pause again at browser preview before export.
- Tradeoff
- The flow is not fully autonomous, but user judgment is applied at the two points where it prevents the most wasted work.
D-03Provider routing per responsibility
- Context
- Seventeen agent roles, from script writing to thumbnail generation, have different model needs and cost profiles.
- Decision
- Resolve models by named agent through a ModelRegistry defaulting to the Vercel AI Gateway, with TTS, transcription, storage and image lookup behind ports; creators supply their own voice key, and a local GPU sidecar can replace paid TTS with an identical contract.
- Tradeoff
- Configuration becomes a system of its own, but provider changes never require rewriting the workflow or domain.
D-04Share contracts with client-driven AI
- Context
- An MCP client can provide its own reasoning model, but bypassing server constraints would create a second, lower-quality pipeline.
- Decision
- Let client-driven jobs submit scripts, directions and scene code through the same schemas, validation gates, composition logic and persisted state, across 26 MCP tools with OAuth 2.1.
- Tradeoff
- The protocol is more involved, but the server keeps product invariants while the client supplies the intelligence.
D-05Move rendering off the API box
- Context
- Headless Chromium and FFmpeg are the memory-hungriest things in the system, and they were OOM-killing the process that also had to answer HTTP.
- Decision
- Put rendering behind a RENDER_PROVIDER factory: in-process by default, or a separate render service reached over HTTP with cold-start retry and a mid-render heartbeat.
- Tradeoff
- One more deployable and a network hop on every export, in exchange for an API that stays responsive and export tiers that can scale on their own hardware.
D / Evidence boundary
Credibility includes
what is not claimed.
Repository demonstrates
- A real multi-application product with domain boundaries and explicit composition roots
- Persistent workflow state, queued execution, replayable progress and stage-aware recovery
- Generated-code validation built from observed failure modes rather than a generic AI wrapper
- Continuous evolution across UI, media infrastructure, AI providers, auth, billing, observability and deployment
Not claimed without product data
- Production throughput, uptime, revenue or user adoption
- A universal success-rate or quality benchmark
- Independent source inspection while the application repository remains private
- That every workflow follows one fixed number of stages