AI Video Content Studio — Master Build Report

Build Steps

1. 1
   Initialize Next.js 15 projectRun npx create-next-app with TypeScript, Tailwind CSS, and App Router. This creates the folder structure, config files, and a dev server.

   📌 What this solves: Gives you a working website you can open in a browser at localhost:3000. Every page, button, and form in the app will live inside this project.
2. 2
   Install + configure ConvexRun npx convex dev to connect your project to a Convex backend. This creates the convex/ folder where your database schema and backend logic will live.

   📌 What this solves: Convex is your database AND your background job runner. Without it, there's nowhere to store data (characters, videos, etc.) and no way to run long-running tasks like polling RunningHub jobs.
3. 3
   Install + configure ClerkAdd Clerk for login/signup. Configure the Clerk → Convex integration so each user's Convex data is tied to their Clerk account.

   📌 What this solves: Without auth, anyone could see anyone's characters and videos. Clerk gives each user a unique ID. Every database query filters by userId so users only see their own data.
4. 4
   Create the complete Convex schemaconvex/schema.ts — Define ALL 12 tables with their columns and data types. Even tables not used until Phase 8.

   📌 What this solves: The schema is the blueprint for your entire data model. Defining it all upfront means you never have to restructure the database mid-build. Each table has typed columns (string, number, arrays, optional fields) and indexes for fast queries.
5. 5
   Install shadcn/ui base componentsRun the shadcn CLI to add: Button, Card, Input, Select, Dialog, Tabs, Badge, Table.

   📌 What this solves: Pre-built, accessible UI components. Instead of building a dropdown menu from scratch (hundreds of lines), you get a ready-made <Select> component that works with keyboard, screen readers, and looks good.
6. 6
   Create dashboard layout with sidebar/dashboard/layout.tsx — The sidebar navigation that appears on every page inside /dashboard.

   📌 What this solves: The sidebar is the main navigation. Every feature page (Characters, Videos, Conversations, etc.) is accessible from here. It's a "layout" component — it wraps around all dashboard pages automatically.
7. 7
   Create placeholder pages for all routesEmpty pages for: Characters, Videos, Conversations, Products, Spend, Settings, Models. Just the page title and "coming soon."

   📌 What this solves: Every URL exists from day one. When you click "Characters" in the sidebar, it goes to /dashboard/characters and shows a page (even if empty). This prevents broken links and lets you test navigation immediately.
8. 8
   Create .env.local.exampleA template file listing every environment variable the app needs (Clerk keys, Convex URL, RunningHub key, R2 credentials, OpenAI key).

   📌 What this solves: Environment variables are secret values (API keys, passwords) that the app needs but shouldn't be in the code. The .example file shows what's needed without exposing real values. You copy it to .env.local and fill in real values.
9. 9
   Deploy to VercelPush to GitHub, connect to Vercel, deploy. Even if it's just empty shells.

   📌 What this solves: Gets the app on the internet from day one. Every future change auto-deploys when you push to GitHub. You can share the URL and test from any device.

Questions You Might Have

Done When

• npm run dev starts without errors
• Can sign in with Clerk
• Dashboard layout renders with sidebar navigation
• All placeholder pages load without errors
• Convex schema deploys successfully
• App deploys to Vercel and loads in browser
• All tables exist in Convex dashboard (even if empty)

Do NOT

• Add any AI functionality yet
• Add R2 integration (Phase 2)
• Add RunningHub API calls (Phase 2)
• Build forms that submit data — just shells
• Add any provider code
• Spend time on landing page — redirect / to /dashboard

Build Steps

1. 1
   R2 presigned URL utilitysrc/lib/r2.ts — Three functions: getUploadUrl() (get a URL to upload a file), getDownloadUrl() (get a URL to view/download a file), deleteObject() (delete a file).

   📌 What is R2? Cloudflare R2 is like Google Drive or Dropbox, but for apps. It stores files (images, videos, audio) in the cloud. You access files via URLs.
   
   📌 What is a presigned URL? A temporary, secure link that lets someone upload or download a file without needing your API passwords. Like giving someone a one-time key to a storage locker — it expires after a few minutes.
   
   📌 Why not store files in Convex? Convex is a database — great for structured data (text, numbers, IDs), but terrible for large binary files (images, videos). R2 is built specifically for file storage. It's also much cheaper — pennies per GB.
   
   📌 What this solves: Every image, video, and audio file in the app goes through R2. Character portraits, talking head videos, TTS audio — all stored here. The file naming pattern ({userId}/{type}/{timestamp}-{random}.{ext}) keeps files organized and prevents collisions.
2. 2
   Convex media helpersconvex/media.ts — Functions that Convex can call to generate upload/download URLs. Bridges the gap between the frontend and R2.

   📌 What this solves: The frontend can't call R2 directly (it doesn't have the API keys). It asks Convex "give me an upload URL" → Convex generates a presigned URL → frontend uses that URL to upload directly to R2. This keeps your secret keys safe on the server.
3. 3
   Provider type definitionssrc/lib/providers/types.ts — TypeScript interfaces that define what every provider must do.

   📌 What is a "provider"? A provider is a standardized wrapper around an external API. Instead of calling RunningHub's API directly in 10 different places, you create one RunningHubProvider class that implements a standard interface (submitJob, getStatus, getResult). Every feature calls the same interface — doesn't matter if it's RunningHub or a different service.
   
   📌 What is a TypeScript interface? A contract that says "any class that implements this must have these methods with these inputs and outputs." Like a job description — "Video providers must be able to submit jobs, check status, get results, and cancel."
   
   📌 What this solves: Three interfaces: VideoProvider (for video generation), ImageProvider (for image generation), TTSProvider (for text-to-speech). Every AI service in the app implements one of these. If you swap RunningHub for a different service later, you only change the provider — no feature code changes.
4. 4
   Base provider with spend trackingsrc/lib/providers/base.ts — An abstract base class that wraps every external API call with automatic cost recording.

   📌 What is a "base class"? A template that other classes inherit from. The base provider has one key method: whenever any provider calls an external API, the base class automatically records how much it cost. Subclasses (RunningHub, OpenAI TTS) inherit this for free — they never need to write spend tracking code.
   
   📌 What this solves: Without this, you'd have to manually add spend tracking to every single API call in every feature. With the base class, it happens automatically. Feature code just calls provider.submitJob() and the spend is recorded behind the scenes.
5. 5
   RunningHub providersrc/lib/providers/runninghub.ts — Implements both VideoProvider and ImageProvider. Talks to RunningHub's API: submit a job, check its status, get the result.

   📌 How RunningHub works: You send a POST request with a workflow ID + inputs (image URLs, prompts, settings). RunningHub assigns a GPU, runs the ComfyUI workflow, and returns a job ID. You then poll (check every 10 seconds) "is job X done?" When done, you get the output URLs (images or videos stored on RunningHub's servers). You download them and upload to your own R2 for permanent storage.
   
   📌 What this solves: Every image generation (character portraits) and video generation (talking heads) goes through this provider. It's the bridge between your app and the GPU cloud.
6. 6
   OpenAI TTS providersrc/lib/providers/openai-tts.ts — Implements TTSProvider. Sends text to OpenAI's API, gets back audio, uploads to R2.

   📌 What is TTS? Text-to-Speech — converts written text into spoken audio. OpenAI's TTS API has 6 voices (alloy, echo, fable, onyx, nova, shimmer). You send text + voice name, it returns an audio file.
   
   📌 What this solves: Every video needs a voice. Whether it's a character talking, a narration, or a conversation — the script text goes through this provider to become audio. The audio is then fed to the talking head models (Hallo2, etc.) to animate the character's mouth.
7. 7
   Provider registrysrc/lib/providers/registry.ts — A lookup table: give it a provider name ("runninghub"), it returns the right provider instance.

   📌 What this solves: When the job queue processes a job, it needs to know which provider to use. The registry maps names to instances: getVideoProvider("runninghub") → returns the RunningHub provider. This is the "dependency injection" pattern — features don't import providers directly, they ask the registry.
8. 8
   Generic job queueconvex/jobs.ts — Two key functions: submitWorkflow (send a job to RunningHub, save a record) and pollJob (check if the job is done, process the result).

   📌 Why can't you just await the result? AI generation takes 1-10 minutes. If you await it, your server would hang for minutes waiting. Instead: submit the job → save a renderJobs record with status "submitted" → schedule a check in 10 seconds → check again → when done, update the record and process results.
   
   📌 What is "polling"? Checking repeatedly: "Is it done yet? Is it done yet?" Every 10 seconds, the job queue asks RunningHub "what's the status of job X?" When it says "completed," the queue downloads the output, uploads to R2, updates the database, and notifies the user.
   
   📌 What this solves: Every AI generation in the app (images, videos, audio) goes through this queue. It's the universal "submit and wait" mechanism. Features just submit a job and subscribe to status updates — they don't manage the polling themselves.
9. 9
   Spend trackingconvex/spend.ts — recordSpend (insert a cost record) + queries for recent spend, spend by date/provider/category, spend per entity.

   📌 What this solves: Every API call that costs money (RunningHub GPU time, OpenAI TTS characters, LLM tokens) creates a spendEvents record. The spend page shows: how much today, this week, this month. Per-provider breakdown. Per-category breakdown. Per-video cost. This is operational visibility — you always know what you're spending.
10. 10
    Workflow config seed dataconvex/workflowConfigs.ts — Inserts initial rows: Flux Dev, Hallo2, MuseTalk, OpenAI TTS, InstantID, GFPGAN.

    📌 What is "seed data"? Pre-populated database records that the app needs to function. Like pre-installing apps on a new phone. The workflowConfigs table is the "model registry" — each row is an AI model with its name, provider, category, cost estimate, and enabled flag. New models are added by inserting rows, not editing code.
11. 11
    Basic spend page/dashboard/spend/page.tsx — Table of recent spend events + totals. No charts yet.

    📌 What this solves: The first page that shows real data. After this phase, every time an API call is made (TTS, image gen, video gen), a spend event appears here. This is how you verify the spend tracking is working.

Questions You Might Have

Done When

• Can generate presigned R2 upload URL from Convex
• Can upload test file to R2 and retrieve via download URL
• RunningHub provider class exists and compiles
• OpenAI TTS provider can generate audio from text
• Job queue can submit, poll, and complete a mock job
• Spend event auto-created when TTS generates audio
• /dashboard/spend shows recent spend events
• Workflow config seed data loads into Convex
• All provider interfaces defined and implemented (at least stubs)

Do NOT

• Build UI forms for characters or videos (Phase 3+)
• Call RunningHub with real workflow IDs yet
• Add ElevenLabs (just OpenAI TTS)
• Build model picker UI (just data layer)
• Process/generate images or videos in this phase

The Flow

Build Steps

1. 1
   LLM prompt expansionsrc/lib/prompts.ts — Takes a short description and expands it into a detailed portrait prompt using GPT-4o-mini.

   📌 What this solves: AI image models work better with detailed prompts. "Young woman" gives generic results. "Portrait photo of a young woman in her late 20s, dark curly shoulder-length hair, warm medium-brown skin with natural pores and subtle freckles, oval face, soft jawline, dark brown eyes, cream knit sweater, soft natural lighting, clean background, editorial portrait style, photorealistic, 8k detail" gives much better results. The LLM bridges the gap between casual description and AI-optimized prompt.
2. 2
   Character creation form/dashboard/characters/create/page.tsx — Text area + 3 optional dropdowns + "Generate Candidates" button.

   📌 What this solves: The user interface for creating characters. The text area is the main input (free-form description). The dropdowns (gender, age range, style) help the LLM generate better prompts. The button triggers the whole pipeline.
3. 3
   Character CRUDconvex/characters.ts — Create, read, update, delete operations for characters + the generation action.

   📌 What is CRUD? Create, Read, Update, Delete — the four basic database operations. createCharacter inserts a new row. listCharacters reads all characters for the current user. generateCandidates is the action that calls the LLM + RunningHub.
   
   📌 What this solves: The backend logic for the entire character feature. The frontend form calls these functions — it doesn't talk to RunningHub or the LLM directly.
4. 4
   Candidate gridsrc/components/candidate-grid.tsx — Displays 4-8 generated portraits in a grid with Select buttons.

   📌 What this solves: After generation, the user needs to see all candidates and pick one. The grid shows them side by side. Each has a "Select" button and a visual highlight when selected. "Regenerate" button generates a fresh batch if none are good enough.
5. 5
   Character selectionconvex/characterVersions.ts — Marks one version as "selected", updates the character's identity.

   📌 What this solves: When you generate 4-8 portraits, each is a "characterVersion." Selecting one marks it as the character's identity — this is the portrait that will be used in all future videos. The seed and settings are saved so you can reproduce the exact same portrait later.
6. 6
   Character detail page/dashboard/characters/[id]/page.tsx — Shows the selected portrait, metadata, all versions, generation settings, and a link to create a video.

   📌 What this solves: The character's home page. Shows everything about the character: portrait, name, description, all generated versions (selected, rejected, generating), and the technical settings (seed, prompt, model) used to create the selected portrait. The "Create Video" button links to Phase 4.
7. 7
   Character gallery/dashboard/characters/page.tsx — Grid of all characters with status badges.

   📌 What this solves: Overview of all characters. Each card shows the portrait thumbnail, name, and status (draft, generating, ready, error). Click to go to detail page. "Create Character" button goes to the creation form.
8. 8
   Verify spend trackingAfter creating a character, check the spend page — you should see events for both the LLM expansion and the image generation.

   📌 What this solves: This is a verification step, not a build step. It confirms that the spend tracking from Phase 2 actually works with real API calls.

Questions You Might Have

Done When

• User can type description and click "Generate Candidates"
• 4-8 candidate portraits appear in grid (from RunningHub)
• User can select one candidate as character identity
• Selected character appears in gallery
• Detail page shows portrait, metadata, generation settings
• Seed, prompt, model, settings stored and visible
• Spend events appear for LLM expansion + image gen
• Second character doesn't interfere with first
• Character status updates real-time during generation

Do NOT

• Build reference pack generator (Phase 5)
• Build refinement pass (Phase 5)
• Build face embedding extraction (Phase 5)
• Add photo upload — synthetic only
• Generate video from character (Phase 4)

The Flow

Build Steps

1. 1
   Script editorsrc/components/script-editor.tsx — Text area for the script with character count, estimated duration, voice selector dropdown, "Generate Audio" button, and audio preview player.

   📌 What this solves: The script is the text the character will "say." The character count estimates duration (roughly: characters ÷ 15 = seconds). The voice selector lets you choose from 6 OpenAI voices. The audio preview lets you listen before committing to video generation.
2. 2
   Video creation page/dashboard/videos/create/page.tsx — 4-step wizard: (1) select character, (2) write script + generate audio, (3) pick style, (4) pick resolution.

   📌 What this solves: Breaks the complex video creation process into manageable steps. Each step has clear inputs and outputs. The user can't proceed to the next step until the current one is complete.
3. 3
   TTS integrationconvex/videos.ts — generateAudio action: calls OpenAI TTS → uploads audio blob to R2 → saves audioUrl on the video record.

   📌 What this solves: Connects the script text to actual spoken audio. The audio file is stored in R2 and its URL is saved on the video record. This URL is later passed to the talking head model so it knows what audio to animate to.
4. 4
   Video generation orchestrationconvex/videos.ts — generateVideo action: loads character portrait → submits to RunningHub → creates renderJob → starts polling.

   📌 What this solves: This is where the magic happens. The character's portrait URL + the audio URL are sent to RunningHub. RunningHub runs two workflows: (1) InstantID puts the character in a yap pose, (2) Hallo2 animates that pose with the audio. The polling loop checks every 10 seconds until done.
5. 5
   Video playersrc/components/video-player.tsx — HTML5 video element with play/pause, download button, duration display.

   📌 What this solves: Displays the finished video. Uses a standard HTML5 <video> tag with the R2 URL as the source. No special library needed — browsers know how to play videos.
6. 6
   Video detail page/dashboard/videos/[id]/page.tsx — Video player, job status, script text, character used, style, resolution, cost breakdown, download button.

   📌 What this solves: The video's home page. Shows everything: the video itself, what character was used, what script was spoken, how much it cost, and a download button. If still generating, shows a real-time progress indicator.
7. 7
   Video list page/dashboard/videos/page.tsx — Grid of all videos with thumbnails, status badges, duration, date.

   📌 What this solves: Overview of all generated videos. Each card shows a thumbnail (or placeholder if still generating), the title, status (generating, ready, error), and duration. Click to go to the detail page.
8. 8
   Job status componentsrc/components/job-status.tsx — Real-time progress display using Convex subscription: Queued → Submitted → Running → Completed (or Failed).

   📌 What is a Convex subscription? Instead of the page refreshing every few seconds, Convex pushes updates to the browser via WebSocket. When the renderJob's status changes in the database, the UI updates instantly. This is why Convex was chosen — real-time updates without writing any polling code on the frontend.
   
   📌 What this solves: AI generation takes minutes. Users need to see progress. This component shows: current state, progress percentage (if available), estimated time remaining, and error messages if something fails.

Questions You Might Have

Done When

• Can select character and write script
• Can generate TTS audio and preview it
• Can generate video (or mock if RH workflow not ready)
• Job status updates real-time during generation
• Completed video plays in player
• Video can be downloaded
• Video list shows all generated videos
• Detail page shows cost breakdown (TTS + video gen)
• Spend page reflects TTS and video gen costs
• Failed jobs show error message

Do NOT

• Build multiple styles — only Yap/Casual
• Build conversation/multi-speaker (Phase 6)
• Build UGC or product video (Phase 8+)
• Build model picker UI — hardcode default config
• Skip job polling — critical infrastructure
• Store video files in Convex — they go to R2

Build Steps

1. 1
   Character refinementconvex/characters.ts — refineCharacter action: takes selected portrait → submits to RunningHub with a refinement prompt → creates a new "refined" version.

   📌 What this solves: The initial Flux Dev portrait might have minor issues (slightly blurry hair, flat lighting). Refinement is a targeted enhancement that says "preserve the exact identity but improve the photorealistic detail." The refined version becomes the new default.
2. 2
   Reference pack generationOptional. Generate the same character from different angles: front smile, three-quarter, profile, speaking expression. Uses InstantID for identity injection.

   📌 What this solves: Different video styles need different poses. A "podcast" style needs a front-facing upper body. A "walking" style needs a full body. Reference packs give the AI more information about what the character looks like from different angles, improving consistency.
3. 3
   Multiple video stylesAdd 5 new styles to the video creation page: Podcaster, In the Car, Office/Business, Walking, Street Interview. Each maps to a different RunningHub workflow or prompt.

   📌 What this solves: Phase 4 only had "Yap/Casual." Now users can create videos in different settings — a podcast studio, a car interior, an office, walking down a street. Each style has a different RunningHub workflow that puts the character in the appropriate setting/pose.
4. 4
   Model picker componentsrc/components/model-picker.tsx — Dropdown that lists enabled workflow configs for the current category.

   📌 What this solves: Lets users choose which AI model to use. For image generation: Flux Dev (best quality) vs a faster alternative. For video: Hallo2 (best quality) vs MuseTalk (faster). The dropdown reads from the workflowConfigs table — adding a new model is just adding a row.
5. 5
   Settings > Models page/dashboard/settings/models/page.tsx — Table of all workflow configs with edit capabilities.

   📌 What this solves: The admin interface for managing AI models. See all models, enable/disable them, update cost estimates, fill in workflow IDs. This is where you'd add a brand new model — insert a row, and it becomes available in the model picker everywhere.

Done When

• Character detail page has "Refine" button
• Refined portrait is noticeably more detailed
• Refined portrait preserves identity (same person)
• Video creation shows multiple style options
• At least 2 styles produce different-looking videos
• Model picker appears on video creation page
• Settings > Models lists all workflow configs
• Configs can be enabled/disabled from settings

Do NOT

• Train any LoRAs — use reference images + InstantID
• Build face embedding extraction unless InstantID requires it
• Over-engineer model picker — dropdown is enough
• Add styles without a corresponding RH workflow

The Flow

Build Steps

1. 1
   Conversation script editor/dashboard/conversations/create/page.tsx — Two-column layout: Speaker A | Speaker B. Each column has a character selector, voice selector, and text inputs for lines.

   📌 What this solves: The UI for writing multi-speaker scripts. Each line is assigned to a speaker. Lines can be reordered by dragging. The preview shows the alternating dialogue.
2. 2
   Conversation generation orchestrationconvex/conversations.ts — Submits all clip jobs in parallel, polls each independently, assembles when ALL are complete.

   📌 Why parallel? If you have 10 lines and generate them one at a time (2 min each), that's 20 minutes. In parallel, it's 2 minutes (limited by the slowest clip). Each clip is an independent job — they don't depend on each other.
   
   📌 What this solves: The most complex orchestration so far. Manages N independent jobs, tracks each one's status, and only assembles when all are done. Assembly concatenates the clips with brief crossfade transitions between speakers.
3. 3
   Video assemblyConcatenate clips with 0.3-0.5s crossfade transitions. Merge audio into one continuous track.

   📌 What this solves: The final step — stitching individual clips into one coherent video. Crossfades make the cuts smooth (not jarring hard cuts). Audio is merged so there are no gaps or overlaps between lines.

Done When

• Can create a 2-speaker conversation script
• Each speaker assigned to different character with distinct voice
• All clips generate independently (per-clip progress visible)
• Final assembled video plays as coherent conversation
• Cuts are smooth (crossfade), audio is continuous
• Spend page shows itemized costs per clip + assembly

Do NOT

• Generate shared scene with both characters (Phase 7)
• Support more than 2 speakers
• Allow overlapping dialogue — speakers take turns
• Assemble clips until ALL are confirmed complete

Quality Gate Criteria (ALL must pass)

• Person A's mouth moves during Person A's audio
• Person B's mouth moves during Person B's audio
• The silent person does NOT visibly speak
• Both faces remain stable (no identity drift/morphing)
• Characters don't swap identities
• Background consistent (no flickering/warping)
• Result looks like conversation, not two stitched animations
• No extreme visual artifacts

Done When

• Tested with at least 3 different character pairs
• Results documented (pass/fail per criterion per test)
• If passed: "Shared Scene" option available in conversation creation
• If failed: phase marked complete with failure documented, Phase 6 cut-based remains only mode

The Flow

Build Steps

1. 1
   Product image upload + segmentationUpload product photo → SAM2 removes background → clean transparent PNG stored in R2.

   📌 What is SAM2? Segment Anything Model 2 — an AI that can identify and separate objects from their backgrounds. It takes a product photo and outputs a clean cutout with a transparent background. This is needed so the product can be composited into a new scene.
2. 2
   UGC generation pipelineconvex/ugc.ts — 4-stage pipeline: segment → pose → composite → animate. Each stage is a separate renderJob.

   📌 What this solves: UGC is the most complex pipeline — 4 sequential AI steps. Each step is tracked independently so the user can see exactly where the process is ("Currently compositing product into scene..."). If any step fails, the error is specific and actionable.

Done When

• Can upload product image and get clean background-removed version
• Can generate UGC video with character holding product
• Sub-task progress visible during generation
• Final video shows character naturally interacting with product
• Spend page shows per-sub-task costs

Build Steps

1. 1
   Product scrapersrc/lib/scraper.ts — Jina Reader for clean text → LLM parses out title, price, features, image URLs → downloads images to R2.

   📌 What this solves: Automates the boring part — manually copying product info. Paste a URL, get structured data. The LLM is smart enough to parse messy HTML into clean fields.
2. 2
   Auto-script generationLLM generates a 30-second video script from product data. User can edit before generating.

   📌 What this solves: The script is the voiceover for the product video. The LLM knows how to write compelling product descriptions. User reviews and edits before committing to video generation.
3. 3
   Multi-resolution outputGenerate in 3 aspect ratios: 16:9, 9:16, 1:1. Store all three.

   📌 What this solves: Different platforms need different formats. YouTube = 16:9 landscape. TikTok/Reels = 9:16 portrait. Instagram feed = 1:1 square. Generating all three at once means the user has content ready for every platform.

Done When

• Can paste Amazon URL and see extracted product data
• Product data can be edited and saved
• Video script auto-generated from product data
• At least one video style generates watchable product video
• Multi-resolution works (at least 2 of 3 ratios)
• Products saved and reusable

Build Steps

1. 1
   Keyframe generationLLM expands description → 3 scene prompts (start → middle → end). Flux generates 3 keyframe images. User can preview and regenerate individual keyframes.
2. 2
   Video interpolationH3 FL2VA or Wan 2.1 generates smooth transitions between the 3 keyframes. NOTE: H3 workflow has a resolution mismatch bug that must be fixed.
3. 3
   Post-processingSpeed ramp for timelapse feel, optional text overlay, merge with music track if provided.

Done When

• Can write description and see 3 generated keyframes
• Keyframes can be individually regenerated
• Smooth timelapse video generated from keyframes
• Video duration controllable
• Spend page shows all generation costs

Build Steps

1. 1
   Dashboard overview/dashboard/page.tsx — Recent activity feed, quick stats (characters, videos, monthly spend), quick action buttons.
2. 2
   Spend analyticsBar chart (daily 30d), pie charts (category + provider), most expensive jobs table, cost trend over time.
3. 3
   Daily spend aggregationConvex cron job at midnight: sum all spendEvents by provider + category for the day → insert into spendSummaries.
4. 4
   General polishLoading states, error states, empty states on all pages. Responsive layout (tablet minimum). Consistent status badges. Toast notifications for job completion and errors.
5. 5
   Settings pageView connected accounts, environment status, link to Models page.

Done When

• Dashboard overview shows meaningful recent activity
• Spend page has at least 2 charts
• Daily aggregation job runs and populates spendSummaries
• All pages have proper loading, error, and empty states
• Full end-to-end flow: create char → create video → watch → see cost
• No console errors in normal usage

1. 1
   No local ML inferenceAll AI runs on RunningHub's cloud GPUs — you don't install or run AI models locally.
2. 2
   No video editorThis app generates videos from scratch. Editing existing videos is a different product.
3. 3
   No mobile appsWeb only. The responsive layout works on tablets.
4. 4
   No team featuresSingle user. No sharing, collaboration, or permissions.
5. 5
   No payments / billing / creditsThis is an internal tool. Spend tracking is for visibility, not billing.
6. 6
   No LoRA trainingUse reference images + InstantID for character consistency. No model training.
7. 7
   No public sharing / social / publishingGenerated content stays in the dashboard.
8. 8
   No landing page or marketing siteInternal tool — no public-facing website.
9. 9
   No Supabase, Firebase, n8n, or external job queuesConvex replaces all of these.
10. 10
    No wrangler.toml or Cloudflare Pages deploymentThe app deploys to Vercel, not Cloudflare Pages.
11. 11
    No Redux, Zustand, React Query, or SWRConvex subscriptions handle all state management and data fetching.