DemoForge — the video pipeline that already exists
Not a plan: a built, agent-native video production system inside the FlexMesh repo. It takes the app's E2E (end-to-end) test screen recordings and produces polished per-feature demo videos. 15 episodes are rendered and on disk (ep01–ep15, dated Mar–Jul 2026); 24 E2E integration tests (journeys j01–j23) map to the 15 feature demos.
The architecture (the theorized loop, already implemented)
The production line the awareness column derives in theory (video-production-pipeline; context-derives-from-the-sop) is here in code, with Claude Code as the loop for the two judgment phases:
- Recording analysis (agent) — read the test
.logfor[E2E]step markers + timestamps;ffmpegextracts key frames at step boundaries; multimodal vision reads each frame to understand the screen; writesanalysis.json(steps, time ranges, screen descriptions). The E2E log's own markers are the segmentation ground truth — the test instruments double as the video's edit list. - Script writing (agent) — narration per step, pacing assigned (speed 0.5×–3× / freeze frames / holds / skips), captions split 5–10 words. Output
script.json. - Voice (local, free) — Chatterbox TTS (text-to-speech) via
mlx-audio+mlx-whisperfor word-level timestamps: runs on Apple Silicon, zero per-render API cost (beats the ElevenLabs-class $22/mo the generic Route-B stack assumes). - Assembly —
cut-segments.pycuts the recording into speed-adjusted segments;build-props.mjsassemblesremotion-props.jsonfrom every intermediate. - Render —
npx remotion render FeatureDemo --props …→output/{episode}.mp4.
File flow: recording.mp4 + .log → analysis.json → script.json → voice.wav → word-timestamps.json → segments/*.mp4 → remotion-props.json → FeatureDemo render.
The polish is coded, not clicked (the "small details" resolution, built)
The DESIGN.md design system encodes as Remotion primitives exactly the polish that raw E2E recordings lack — the choice the awareness note left as an open engineering call (video-editor-selection, resolution (b)) is here decided and implemented: iPhone-15-style device frame, karaoke-style (KTV) word-highlighted captions, zoom highlight (smooth scale + border glow) on UI elements, tap ripple at coordinates, segment progress bar, brand palette, Inter type scale, pacing primitives (slow-mo for key interactions, fast-forward for loading, freeze for narration). The cursor/zoom-emphasis polish is authored once in the composition, then every episode inherits it.
The load-bearing gap for the awareness use
Output is 1920×1080 landscape (16:9). That fits a website hero, an App-Store preview, a YouTube feature walkthrough, in-app onboarding — not the short-video arena, which is vertical 9:16 (short-video-sop). So DemoForge as built serves the considered-tool / long-ish demo need, and is not yet the day-1 short-video probe cell it looks like: reaching the short-video arena needs a 9:16 variant of the FeatureDemo composition (a layout swap in Remotion, not a new pipeline — the segments, voice, and script layers are aspect-agnostic). This is the single concrete build step between "the pipeline exists" and "the short-video cell can run."
Status honesty
Two git commits (initial + a setup fix), built Feb–Apr 2026, rendered through July — a personal utility tool, not a maintained product surface. The asset is real and the architecture is sound; it has not been pointed at distribution yet.
Interview archetype: "show me something you built that surprised you in scope" — an agent-in-the-loop video pipeline where the E2E test suite doubles as the footage source and the edit list, local models zero the voice/transcription cost, and the visual polish lives as code.
Kin: measurement-stack (the E2E-tested instrumentation whose recordings feed this) · video-production-pipeline (the awareness column's theory of exactly this) · cal-ai-the-screen-is-the-ad (the screen-is-the-footage doctrine, here mechanized).