System Requirements Document for anime-video

1. Introduction

This document specifies LAXMAN AI, an end-to-end AI anime production platform delivered as the project anime-video for Kommu Laxman. The product intent is to upgrade the existing LAXMAN AI application in place — without creating a new project and without removing working features — into a genuine anime production workspace that accepts a complete story, screenplay, characters, dialogue, scene descriptions, reference images, voices and production instructions, generates real anime scenes through configured AI providers, assembles them in screenplay order, and delivers a verified, downloadable final MP4 episode.

The audience is solo creators, indie animation teams and Telugu-language storytellers working on Windows laptops and Android phones. A prompt generator or static UI is explicitly not an acceptable final product: every visible button must perform its actual intended action or clearly state that its integration is not yet configured, and no fake video previews, fake progress, fake statistics, fake credit balances or false export-success messages may appear anywhere.

The product must never claim unlimited free AI generation; provider quotas, duration limits, costs and unavailable capabilities are disclosed plainly. Features carry an honest status system — COMPLETE AND TESTED, IMPLEMENTED, PROVIDER REQUIRED, IN PROGRESS, BLOCKED — and missing integrations are never hidden.

Success Criteria and KPIs

• A producer can submit a complete story package once and receive a real, playable, downloadable MP4 episode assembled from provider-generated clips.
• Every scene in the Scene-by-Scene workflow exposes all twelve required scene fields and functional Generate, Preview, Approve, Regenerate, Retry and Delete actions.
• No video, export, credit transaction or statistic is ever displayed as successful without a verified server-side artifact or ledger entry.
• Continuity conflicts are surfaced as warnings requiring explicit approval; established character appearance and story facts are never silently changed.
• Credit ledger integrity: exactly 1 credit per eligible successful generation job, refunds on failure, no charge for pre-processing cancellation, and no duplicate deductions on duplicate requests.
• Automated tests cover authentication, project creation, autosave, character persistence, upload validation, scene generation submission, job status updates, retry and cancellation, credit deduction and refund, episode assembly, export validation, mobile responsiveness, and authorization and private media access.

2. System Overview

LAXMAN AI is a full-stack anime production workspace. A React frontend provides the studio workspace; a shared FastAPI backend owns application APIs, domain modules, provider orchestration, media assembly and the credit ledger; MariaDB holds application-owned persistent data; object storage holds uploaded and generated media; Redis supports background job coordination and shared state; and a LiteLLM gateway (backed by its own PostgreSQL instance) brokers the backend's model-provider calls. Provider API keys live only on the server.

The current delivery covers two complete production workflows (One-Click Complete Episode and Scene-by-Scene Production), a per-project continuity engine, provider-independent real AI video generation, a real voice and audio pipeline, FFmpeg-based episode assembly with verified MP4 export, the full named project workspace, persistent backend data with authentication and project ownership, a server-authoritative credit ledger, security and privacy controls, performance targets for Windows laptops and Android phones, and automated testing with strict completion rules.

Removed from scope

• Prompt-generator-only or static-UI-only delivery as the final product.
• Mock or fake generated media, fake video previews, fake progress percentages, fake statistics and fake credit balances.
• Fake download buttons and false export-success messages.
• Simulated successful credit transactions.
• Automatic activation of paid services.
• Storing important project data only in temporary browser state.
• Creating a new project in place of upgrading the existing LAXMAN AI application.
• Removing working features of the existing application.

2a. Product Interpretation and Delivery Boundary

LAXMAN AI is delivered as a first-party application with application-owned identity. Because projects, jobs, credits and exports are private durable state that must remain bound to the correct producer, the platform provides self-service enrollment (Sign Up) and returning verification (Login) as anonymous entry surfaces; all workspace destinations require login. Projects are private by default and access to private project media is restricted server-side.

Real generation is provider-owned work: the platform integrates only real, documented AI video-generation APIs and real supported audio integrations, keeps all provider API keys on the server, and submits long-running work as background jobs. When no video provider is connected, the product clearly explains how to configure one and never substitutes fake previews. Provider quotas, duration limits, costs and unavailable capabilities are disclosed. Paid services are never activated automatically.

The current horizon covers the complete production pipeline: STORY INPUT → SCREENPLAY ANALYSIS → SCENE BREAKDOWN → CHARACTER CONTINUITY → REAL AI VIDEO GENERATION → VOICE AND AUDIO → SCENE REVIEW → EPISODE ASSEMBLY → FINAL MP4 EXPORT. Work continues on the existing project until the available environment's implementation and testing work is complete; the build does not stop after designing the dashboard.

2c. Page Content and Component Coverage

Landing

• Information/state: Anonymous public entry explaining the anime production platform, its audience (solo creators, indie teams, Telugu-language storytellers) and the end-to-end episode outcome; honest disclosure that real generation requires a configured provider.
• Primary actions: Start a new episode (routes to Sign Up); Open a project (routes to Login).
• Supporting actions: Navigate to Sign Up and Login.
• Domain entities: None persisted; product description only.
• Component responsibilities: Horizontal hero band with oversized flush-left headline "Your episode starts with a story." (word "story" in sunflower), one supporting line, sunflower pill and ghost pill; right-side composed flat vector stage of three rotated paper-like cards (screenplay sheet, character portrait card, scene thumbnail) with a tomato status chip "3 scenes awaiting render"; modular vector illustration system.
• States: Static content; no loading, empty or error states beyond standard route fallback.

Sign Up

• Information/state: Self-service enrollment form for a new producer establishing application-owned identity.
• Primary actions: Create account.
• Supporting actions: Navigate to Login for returning users.
• Domain entities: Account identity.
• Component responsibilities: Form with validation feedback; server-side identity creation; on success route into the protected workspace.
• States: Loading during submission; validation errors shown accessibly; success routes to Dashboard; failure shows a clear, non-secret error with retry.

Login

• Information/state: Returning verification form for producers and collaborators accessing private projects, jobs, credits and exports.
• Primary actions: Sign in.
• Supporting actions: Navigate to Sign Up.
• Domain entities: Account identity, session.
• Component responsibilities: Credential form; server-side verification; session establishment.
• States: Loading; invalid-credential error; success routes to Dashboard; failure recovery without exposing secrets.

Dashboard

• Information/state: Workspace summary of the producer's projects, feature status system (COMPLETE AND TESTED, IMPLEMENTED, PROVIDER REQUIRED, IN PROGRESS, BLOCKED), recent jobs and routes into production work; credit balance summary.
• Primary actions: Start a new episode; open a project.
• Supporting actions: Navigate to any workspace destination via left rail (desktop) or bottom tab bar plus More sheet (mobile).
• Domain entities: Project, generation job, credit balance, feature status.
• Component responsibilities: Hero band with headline and rotated card stack; project summary cards; status chips drawn from palette logic; left rail navigation.
• States: Loading skeletons; meaningful illustrated empty state when no projects exist with one plain-language next action; error state with accessible message and retry.

My Projects

• Information/state: Paginated list of the producer's anime projects with metadata.
• Primary actions: Open a project.
• Supporting actions: Create project; delete project with confirmation; paginate.
• Domain entities: Project, ownership.
• Component responsibilities: Paginated project list; confirmation dialog before destructive deletion; safe deletion.
• States: Loading; empty state with illustrated next action; pagination controls; deletion error recovery; authorization failure message.

Story Studio

• Information/state: Submission surface for the complete story, characters, dialogue, scene descriptions, reference images, voices and production instructions.
• Primary actions: Submit production details; save.
• Supporting actions: Upload reference images and voices; autosave.
• Domain entities: Project, story input, character, upload asset, voice asset, production instruction.
• Component responsibilities: Structured input forms; validated uploads; autosave with recovery; persistence to backend.
• States: Autosaving indicator; saved confirmation; validation errors; upload rejection messages; recovery after interruption.

Screenplay Writer

• Information/state: Screenplay editing surface presented as a crisp white paper sheet on cream ground, with live scene-count and shot-count in tabular Bricolage numerals pinned top-right; episode production plan with scenes and shots.
• Primary actions: Write and organize screenplay; parse into scenes and shots.
• Supporting actions: Autosave; view production plan.
• Domain entities: Screenplay, episode production plan, scene, shot.
• Component responsibilities: Screenplay editor (Manrope 16px/1.8, 24px paragraph spacing, 68ch measure); live counts updating as the screenplay is parsed; persistence.
• States: Autosave status; parse-in-progress; parse error with recovery; empty state prompting first screenplay entry.

One-Click Episode Generator

• Information/state: Validation results for the submitted project and the full one-click pipeline progress: screenplay organization, production plan, scene/shot breakdown, continuity bible, visual and animation instructions, reference images, provider job submission, job tracking, clip storage, failed-scene detection, retry, screenplay-order assembly, audio synchronization, subtitles when requested, final validation and downloadable MP4.
• Primary actions: Generate Complete Episode.
• Supporting actions: Retry failed scenes; open Provider Configuration when no provider is connected; download verified MP4.
• Domain entities: Project, episode production plan, scene, shot, continuity bible, generation job, clip, export.
• Component responsibilities: Pre-flight validation panel; pipeline stage tracker with clear progress indicators; failed-scene list with retry; honest provider-required guidance; verified download control only when a valid output exists.
• States: Validation failure with specific reasons; provider-not-configured guidance; queued/processing/completed/failed/cancelled job states; partial failure with retry; success only with verified playable output; error log without secrets.

Scene-by-Scene Generator

• Information/state: Individual scene cards each carrying scene description, script and dialogue, character references, character actions and expressions, location and background, camera angles and movements, lighting and color direction, animation style, voice and audio instructions, duration and aspect ratio, visual prompt and negative prompt, and continuity information.
• Primary actions: Generate, Preview, Approve, Regenerate, Retry, Delete.
• Supporting actions: Save prompts to Saved Prompts; open continuity conflict warning.
• Domain entities: Scene, shot, character reference, continuity record, generation job, clip.
• Component responsibilities: Scene card grid reflowing 3 → 2 → 1 column; pill status chips (sunflower queued, teal completed, tomato failed, lilac approved); confirmation before Delete; continuity conflict warning requiring approval.
• States: Loading; empty state with illustrated next action; generation in progress; preview available; approved; failed with retry; deletion confirmation and recovery.

Anime Image Generator

• Information/state: Reference image generation surface for required reference images when supported.
• Primary actions: Generate reference image.
• Supporting actions: Save to Upload Library; reuse prompts.
• Domain entities: Reference image, generation job, prompt.
• Component responsibilities: Prompt and negative prompt inputs; provider capability disclosure; job submission and status.
• States: Provider-required guidance when unsupported; queued/processing/completed/failed; error recovery; no fake previews.

Anime Video Generator

• Information/state: Submission surface for actual video-generation jobs to configured providers, with provider-specific capabilities and limits shown.
• Primary actions: Submit video-generation job.
• Supporting actions: View job status; retry; cancel before processing.
• Domain entities: Generation job, provider job ID, clip, metadata.
• Component responsibilities: Prompt, input media and output format validation; duplicate-job prevention; server-side key handling; status tracking.
• States: Provider-not-configured explanation; validation errors; queued/processing/completed/failed/cancelled; timeout and quota error messages; recovery.

Character Library

• Information/state: Per-project continuity bible: exact character appearance, face and hairstyle references, costume and accessories, character height and proportions, character relationships, voice identity, emotional state, location and environment, time of day and weather, props and important objects, scene order and story chronology, screen direction and camera continuity, and previous-scene context.
• Primary actions: Create and edit character records; approve continuity conflicts.
• Supporting actions: Attach face and hairstyle references; link voice identity.
• Domain entities: Character, continuity record, relationship, prop, location, chronology entry.
• Component responsibilities: Character card grid with flat modular vector portrait on pastel field and chip row for voice, costume and continuity lock; conflict sticker flipping to tomato on mismatch; approval dialog.
• States: Loading; empty state; conflict warning requiring approval; save confirmation; error recovery.

Upload Library

• Information/state: Validated uploads and stored generated clips with metadata.
• Primary actions: Upload files.
• Supporting actions: Browse, preview stored clips, delete with confirmation.
• Domain entities: Upload asset, generated clip, metadata.
• Component responsibilities: Upload validation (type, size, format); secure media access; metadata display; confirmation before deletion.
• States: Upload progress; validation rejection; empty state; loading; error recovery.

Voice Studio

• Information/state: Telugu dialogue generation, character-specific voices, voice uploads, emotion-aware delivery where supported, dialogue timing, dubbing, lip-sync, and audio task tracking (completed, unavailable, failed).
• Primary actions: Generate Telugu dialogue; assign character voices; upload voices.
• Supporting actions: Configure dubbing and lip-sync; view audio task status.
• Domain entities: Voice asset, dialogue line, audio task, character voice identity.
• Component responsibilities: Voice assignment per character; emotion controls where supported; task status chips; honest unavailable-capability disclosure.
• States: Provider-required guidance; queued/processing/completed/unavailable/failed; error recovery.

Music and SFX Studio

• Information/state: Background music, ambient audio, sound effects and audio mixing controls with task status.
• Primary actions: Add BGM, ambient audio and SFX; mix audio.
• Supporting actions: Track completed, unavailable and failed audio tasks.
• Domain entities: Audio asset, mix configuration, audio task.
• Component responsibilities: Audio asset assignment; mixing controls; status chips.
• States: Empty state; loading; unavailable-capability disclosure; failure with retry.

Video Editor

• Information/state: Scene clips available for editing before episode assembly.
• Primary actions: Edit scene clips.
• Supporting actions: Preview clips; save edits.
• Domain entities: Clip, scene, edit record.
• Component responsibilities: Clip selection and arrangement; preview; persistence of edits.
• States: Loading; empty state; save confirmation; error recovery.

Episode Assembly

• Information/state: Assembly configuration for approved scenes in screenplay order with synchronized dialogue, voice, music and sound effects, subtitles when requested, transitions where supported, normalized dimensions and frame rates where possible, and different clip durations handled.
• Primary actions: Assemble episode.
• Supporting actions: Toggle subtitles; select transitions where supported; view export status.
• Domain entities: Assembly job, scene order, subtitle track, transition, export record.
• Component responsibilities: FFmpeg-backed assembly submission; progress indicators; export status and error recording; verification that output exists and is playable.
• States: Pre-assembly validation (unapproved or failed scenes flagged); processing; success with verified output; failure with recorded error and recovery; no false success.

Export History

• Information/state: Export records with status, errors and validated final MP4 downloads.
• Primary actions: Download verified MP4.
• Supporting actions: View export status and error details.
• Domain entities: Export record, final MP4.
• Component responsibilities: Dense friendly table with pill status chips and 12px metadata rows; download control only for verified playable files.
• States: Loading; empty state; failed export with error detail; no fake download button.

Saved Prompts

• Information/state: Saved visual and negative prompts for reuse.
• Primary actions: Save prompt.
• Supporting actions: Reuse, edit, delete with confirmation.
• Domain entities: Prompt, negative prompt.
• Component responsibilities: Prompt list; reuse action; confirmation before deletion.
• States: Empty state; save confirmation; error recovery.

Generation Job Monitor

• Information/state: Job states (queued, processing, completed, failed, cancelled), provider job IDs, duplicate prevention, retries and safe recovery.
• Primary actions: Retry job; cancel job before processing.
• Supporting actions: Inspect job detail and error logs without secrets.
• Domain entities: Generation job, provider job ID, credit transaction reference.
• Component responsibilities: Dense friendly table with pill status chips; single soft tomato pulse while processing; retry and cancel controls.
• States: Loading; empty state; processing pulse (static dot under reduced motion); failure with retry; cancellation confirmation.

Provider Configuration

• Information/state: Server-side provider API key configuration, provider-specific capabilities and limits, and configuration guidance when no provider is connected.
• Primary actions: Save provider configuration.
• Supporting actions: View capability and limit disclosures; view quota, duration and cost information.
• Domain entities: Provider configuration, capability record, limit record.
• Component responsibilities: Key entry that never exposes keys in frontend code; capability and limit display; guidance panel.
• States: Not-configured guidance; save confirmation; validation error; connection verification result.

Settings

• Information/state: Account and project settings including credit balance and transaction history.
• Primary actions: Update settings.
• Supporting actions: View credit balance and transaction history.
• Domain entities: Account settings, credit balance, credit transaction.
• Component responsibilities: Settings forms; credit balance display in tabular Bricolage numerals; transaction history table.
• States: Loading; save confirmation; error recovery; empty transaction history.

3. Functional Requirements

FR-1 — Upgrade in place. As an Anime Producer I should have the existing LAXMAN AI project upgraded in place, with all working functionality preserved and improved, so that no new project is created and no working feature is removed. Provenance: explicit. Lifecycle: trigger — upgrade execution; result — existing features preserved, incomplete features, bugs, broken workflows, missing backend integrations and architectural weaknesses identified and improved; failure — any regression is fixed before completion.

FR-2 — Submit complete production package. As an Anime Producer I should submit a complete anime story, screenplay, characters, dialogue, scene descriptions, reference images, voices and production instructions, so that the platform has everything needed to produce an episode. Provenance: explicit. Lifecycle: input — story, screenplay, characters, dialogue, scene descriptions, reference images, voices, production instructions; result — persisted project package; failure — validation errors shown; continuation — proceed to production.

FR-3 — One-Click Complete Episode. As an Anime Producer I should enter all production details once and select Generate Complete Episode, so that the system runs the complete pipeline. Provenance: explicit. Lifecycle: trigger — Generate Complete Episode; result — pipeline executes steps FR-4 through FR-20; failure — failed scenes detected and retryable; continuation — verified MP4 download.

FR-4 — Validate submitted project. As an Anime Producer I should have the submitted project validated before generation, so that incomplete input is caught early. Provenance: explicit. Lifecycle: input — project package; result — validation pass or specific failure reasons; failure — generation blocked with accessible error messages.

FR-5 — Understand and organize screenplay. As an Anime Producer I should have the screenplay understood and organized, so that production structure is derived from my story. Provenance: explicit. Result — organized screenplay persisted.

FR-6 — Create episode production plan. As an Anime Producer I should receive an episode production plan, so that the episode has a structured plan. Provenance: explicit. Result — persisted production plan.

FR-7 — Break screenplay into scenes and shots. As an Anime Producer I should have the screenplay broken into scenes and shots, so that each unit can be produced. Provenance: explicit. Result — persisted scenes and shots in screenplay order.

FR-8 — Build character continuity bible. As an Anime Producer I should have a character continuity bible built, so that characters remain consistent. Provenance: explicit. Result — persisted continuity bible.

FR-9 — Prepare visual and animation instructions. As an Anime Producer I should have visual and animation instructions prepared, so that generation prompts are grounded. Provenance: explicit. Result — persisted instructions per scene/shot.

FR-10 — Generate required reference images when supported. As a Continuity and Asset Manager I should have required reference images generated when supported, so that visual continuity has references. Provenance: explicit. Lifecycle: trigger — pipeline stage; result — reference images stored; failure — unsupported capability disclosed honestly.

FR-11 — Submit actual video-generation jobs. As an Anime Producer I should have actual video-generation jobs submitted to configured providers, so that real clips are produced. Provenance: explicit. Lifecycle: input — validated prompts and media; result — provider job submitted with saved provider job ID; failure — provider-not-configured guidance, quota or timeout errors; continuation — job tracking.

FR-12 — Track each job and its status. As an Anime Producer I should see each job and its status, so that I know production progress. Provenance: explicit. States — queued, processing, completed, failed, cancelled.

FR-13 — Store completed video clips. As an Anime Producer I should have completed video clips stored with metadata, so that they are available for review and assembly. Provenance: explicit. Result — clips and metadata persisted in object storage.

FR-14 — Detect failed or incomplete scenes. As an Anime Producer I should have failed or incomplete scenes detected, so that I can act on them. Provenance: explicit. Result — failed/incomplete scenes flagged.

FR-15 — Retry failed scenes. As an Anime Producer I should retry failed scenes, so that the episode can complete. Provenance: explicit. Lifecycle: trigger — retry action; result — new job submitted without duplicate jobs; failure — error shown with recovery.

FR-16 — Assemble approved scenes in screenplay order. As an Anime Producer I should have approved scenes assembled in screenplay order, so that the episode follows my story. Provenance: explicit. Result — ordered assembly.

FR-17 — Synchronize dialogue, voice, music and sound effects. As an Anime Producer I should have dialogue, voice, music and sound effects synchronized, so that the episode audio is coherent. Provenance: explicit. Result — synchronized audio track.

FR-18 — Generate subtitles when requested. As an Anime Producer I should have subtitles generated when requested, so that the episode is accessible. Provenance: explicit. Result — subtitle track included when requested.

FR-19 — Validate the final video. As an Anime Producer I should have the final video validated, so that only a real playable output is presented. Provenance: explicit. Result — output file existence and playability verified; failure — export error recorded, no false success.

FR-20 — Provide a real downloadable MP4. As an Anime Producer I should receive a real downloadable MP4 file, so that I have my finished episode. Provenance: explicit. Result — verified MP4 download; failure — no fake download button.

FR-21 — Scene-by-Scene Production. As a Scene Director I should generate and review individual scenes before assembling the episode, so that I can control each scene. Provenance: explicit. Lifecycle: trigger — scene generation; result — scene ready for review; continuation — approve then assemble.

FR-22 — Complete scene fields. As a Scene Director I should see every scene with scene description, script and dialogue, character references, character actions and expressions, location and background, camera angles and movements, lighting and color direction, animation style, voice and audio instructions, duration and aspect ratio, visual prompt and negative prompt, and continuity information, so that each scene is fully specified. Provenance: explicit.

FR-23 — Scene actions. As a Scene Director I should use functional Generate, Preview, Approve, Regenerate, Retry and Delete actions on scenes, so that I can control scene production. Provenance: explicit. Lifecycle: Generate — submits job; Preview — shows real clip only when it exists; Approve — marks scene approved; Regenerate — new job without duplicates; Retry — retries failed job; Delete — requires confirmation before destructive deletion.

FR-24 — Reusable production bible. As a Continuity and Asset Manager I should maintain a reusable production bible per project, so that established facts persist across scenes. Provenance: explicit. Result — persisted bible per project.

FR-25 — Production bible contents. As a Continuity and Asset Manager I should maintain exact character appearance, face and hairstyle references, costume and accessories, character height and proportions, character relationships, voice identity, emotional state, location and environment, time of day and weather, props and important objects, scene order and story chronology, screen direction and camera continuity, and previous-scene context, so that continuity is complete. Provenance: explicit.

FR-26 — Continuity conflict warning and approval. As a Continuity and Asset Manager I should never have established character appearance or story facts silently changed, and when a continuity conflict is detected I should see a warning and be asked for approval, so that continuity is protected. Provenance: explicit. Lifecycle: trigger — conflict detected; result — warning shown, approval required; failure — change blocked until approved.

FR-27 — Provider-independent video architecture. As an Anime Producer I should have a provider-independent video generation architecture integrating only real, documented AI video-generation APIs, so that providers can be swapped without faking output. Provenance: explicit.

FR-28 — Server-side API keys. As an Anime Producer I should have all provider API keys kept on the server and never exposed in frontend code, so that credentials are safe. Provenance: explicit.

FR-29 — Provider-specific capabilities and limits. As an Anime Producer I should see provider-specific capabilities and limits supported and disclosed, so that I understand what each provider can do. Provenance: explicit.

FR-30 — Validate prompts, input media and output formats. As an Anime Producer I should have prompts, input media and output formats validated, so that invalid submissions are rejected before jobs run. Provenance: explicit.

FR-31 — Background jobs. As an Anime Producer I should have long-running generation run as background jobs, so that the workspace stays responsive. Provenance: explicit.

FR-32 — Job states. As an Anime Producer I should have queued, processing, completed, failed and cancelled states tracked, so that job status is legible. Provenance: explicit.

FR-33 — Save provider job IDs. As an Anime Producer I should have provider job IDs saved, so that jobs can be tracked and recovered. Provenance: explicit.

FR-34 — Retries and safe recovery. As an Anime Producer I should have retries and safe recovery supported, so that transient failures do not lose work. Provenance: explicit.

FR-35 — Prevent duplicate jobs. As an Anime Producer I should have duplicate jobs prevented, so that the same work is not submitted twice. Provenance: explicit.

FR-36 — Store clips and metadata. As an Anime Producer I should have generated clips and metadata stored, so that they are durable and reviewable. Provenance: explicit.

FR-37 — Handle timeouts and quota errors. As an Anime Producer I should have timeouts and provider quota errors handled, so that failures are explained and recoverable. Provenance: explicit.

FR-38 — Never claim ungenerated video. As an Anime Producer I should never be told a video was generated when no valid output exists, so that I can trust the workspace. Provenance: explicit.

FR-39 — Provider configuration guidance. As an Anime Producer I should see a clear explanation of how to configure a video provider when none is connected, with no fake video previews substituted, so that I can enable real generation. Provenance: explicit.

FR-40 — Real voice and audio integrations. As a Continuity and Asset Manager I should use real supported integrations for Telugu dialogue generation, character-specific voices, voice uploads, emotion-aware delivery where supported, dialogue timing, dubbing, lip-sync, background music, ambient audio, sound effects and audio mixing, so that the episode has real audio. Provenance: explicit.

FR-41 — Audio task tracking. As a Continuity and Asset Manager I should see which audio tasks are completed, unavailable or failed, so that audio gaps are visible. Provenance: explicit.

FR-42 — Real media assembly backend. As an Anime Producer I should have a real media assembly backend using FFmpeg or another suitable server-side media-processing solution, so that assembly is genuine. Provenance: explicit.

FR-43 — Assembly operations. As an Anime Producer I should have assembly combine scenes in the correct order, handle different clip durations, normalize video dimensions and frame rates where possible, synchronize audio, add subtitles when requested, mix BGM and SFX, add transitions where supported, generate a final MP4, verify that the output file exists and is playable, and record export status and errors, so that the final episode is real and verified. Provenance: explicit.

FR-44 — No fake download or false success. As an Anime Producer I should never see a fake download button or a false export-success message, so that exports are trustworthy. Provenance: explicit.

FR-45 — Full project workspace. As an Anime Producer I should have a fully implemented workspace including Dashboard, Story Studio, Screenplay Writer, One-Click Episode Generator, Scene-by-Scene Generator, Anime Image Generator, Anime Video Generator, Character Library, Upload Library, Voice Studio, Music and SFX Studio, Video Editor, Episode Assembly, My Projects, Saved Prompts, Export History, Settings, Provider Configuration and Generation Job Monitor, so that every production responsibility has a home. Provenance: explicit.

FR-46 — Every button works or discloses. As an Anime Producer I should have every visible button perform its actual intended action or clearly show that its integration is not yet configured, so that nothing is a dead control. Provenance: explicit.

FR-47 — Persistent database and object storage. As an Anime Producer I should have a suitable persistent database and object storage, so that project data and media survive sessions. Provenance: explicit.

FR-48 — Backend capabilities. As an Anime Producer I should have authentication, project ownership, secure media access, autosave, recovery, generation job records, export records, error logs, backup and restore, safe deletion and data validation implemented, so that the backend is reliable. Provenance: explicit.

FR-49 — No browser-only project data. As an Anime Producer I should never have important project data stored only in temporary browser state, so that work is not lost. Provenance: explicit.

FR-50 — Server-authoritative credit ledger. As an Anime Producer I should have a server-authoritative credit ledger implementing the requested credit policy, so that credits are honest. Provenance: explicit.

FR-51 — 100,000 daily credits. As an Anime Producer I should receive 100,000 daily credits, so that I have a daily generation allowance. Provenance: explicit.

FR-52 — Indefinite carry-forward. As an Anime Producer I should have unused credits carry forward indefinitely, so that unused allowance is not lost. Provenance: explicit.

FR-53 — Exactly 1 credit per eligible successful job. As an Anime Producer I should be charged exactly 1 credit per eligible successful generation job, so that charging is predictable. Provenance: explicit.

FR-54 — Refund failed jobs. As an Anime Producer I should receive a refund for failed jobs, so that failures do not cost credits. Provenance: explicit.

FR-55 — No charge for pre-processing cancellation. As an Anime Producer I should not be charged for jobs cancelled before processing, so that cancellation is fair. Provenance: explicit.

FR-56 — Unique job IDs. As an Anime Producer I should have each job carry a unique ID, so that jobs are identifiable. Provenance: explicit.

FR-57 — No duplicate deductions. As an Anime Producer I should have duplicate requests not cause duplicate deductions, so that retries and double-clicks are safe. Provenance: explicit.

FR-58 — Display balance and transaction history. As an Anime Producer I should see my balance and transaction history, so that I can audit credits. Provenance: explicit.

FR-59 — Never simulate credit transactions. As an Anime Producer I should never see simulated successful credit transactions, so that the ledger is truthful. Provenance: explicit.

FR-60 — Private projects by default. As an Anime Producer I should have my projects private by default, so that my work is not exposed. Provenance: explicit.

FR-61 — No frontend API keys. As an Anime Producer I should never have API keys exposed in frontend code, so that credentials are protected. Provenance: explicit.

FR-62 — Secure server-side authorization. As an Anime Producer I should have secure server-side authorization, so that only authorized access occurs. Provenance: explicit.

FR-63 — Validate file uploads. As an Anime Producer I should have file uploads validated, so that unsafe files are rejected. Provenance: explicit.

FR-64 — Restrict private media access. As an Anime Producer I should have access to private project media restricted, so that media stays private. Provenance: explicit.

FR-65 — Protect against duplicate and unauthorized actions. As an Anime Producer I should have duplicate and unauthorized actions protected against, so that state stays correct. Provenance: explicit.

FR-66 — Confirmation before destructive operations. As an Anime Producer I should confirm before destructive operations, so that I do not lose work accidentally. Provenance: explicit.

FR-67 — Error logs without secrets. As an Anime Producer I should have error logs provided without exposing secrets, so that I can diagnose issues safely. Provenance: explicit.

FR-68 — No automatic paid activation. As an Anime Producer I should never have paid services automatically activated, so that I control spending. Provenance: explicit.

FR-69 — Windows laptop and Android phone optimization. As an Anime Producer I should have the application optimized for Windows laptops and Android phones, so that it works on my devices. Provenance: explicit.

FR-70 — Performance and quality requirements. As an Anime Producer I should have responsive layouts, smooth navigation, efficient media loading, pagination for large project lists, background processing, retry and recovery mechanisms, clear progress indicators, meaningful empty states and accessible error messages, so that the workspace is usable. Provenance: explicit.

FR-71 — No broken routes or placeholders. As an Anime Producer I should encounter no broken routes, no silent failures, no incomplete placeholder screens, and no fake statistics or fake generated media, so that the product is complete. Provenance: explicit.

FR-72 — Automated testing. As an Anime Producer I should have automated tests covering authentication, project creation, autosave, character persistence, upload validation, scene generation submission, job status updates, retry and cancellation, credit deduction and refund, episode assembly, export validation, mobile responsiveness, and authorization and private media access, so that quality is verified. Provenance: explicit.

FR-73 — Fix bugs before completion. As an Anime Producer I should have discovered bugs fixed before a feature is marked complete, so that completion is meaningful. Provenance: explicit.

FR-74 — Strict completion criteria. As an Anime Producer I should have a feature marked COMPLETE only when its frontend works, its backend works, its data persists, its errors are handled, its important workflows are tested, and its external integrations are actually configured and verified, so that status is honest. Provenance: explicit.

FR-75 — Feature status system. As an Anime Producer I should see a maintained feature status system with COMPLETE AND TESTED, IMPLEMENTED, PROVIDER REQUIRED, IN PROGRESS and BLOCKED, so that I know what is real. Provenance: explicit.

FR-76 — Do not hide missing integrations. As an Anime Producer I should never have missing integrations hidden, so that I can act on gaps. Provenance: explicit.

FR-77 — Implementation audit first, then phased build. As an Anime Producer I should have an implementation audit of the current project produced first, then highest-priority issues fixed and the application implemented in phases, so that the upgrade is grounded. Provenance: explicit.

FR-78 — Prioritized production pipeline. As an Anime Producer I should have the real production pipeline prioritized as STORY INPUT → SCREENPLAY ANALYSIS → SCENE BREAKDOWN → CHARACTER CONTINUITY → REAL AI VIDEO GENERATION → VOICE AND AUDIO → SCENE REVIEW → EPISODE ASSEMBLY → FINAL MP4 EXPORT, so that the highest-value path works first. Provenance: explicit.

FR-79 — Continue until implementation and testing complete. As an Anime Producer I should have work continue on the existing project until the available environment's implementation and testing work is complete, so that the build is not abandoned mid-way. Provenance: explicit.

FR-80 — Do not stop at the dashboard. As an Anime Producer I should not receive a build that stops after designing the dashboard, so that the product is functional. Provenance: explicit.

FR-81 — No mock generation. As an Anime Producer I should never have actual generation replaced with mock data, so that outputs are real. Provenance: explicit.

FR-82 — Disclose quotas, limits, costs and unavailable capabilities. As an Anime Producer I should see provider quotas, duration limits, costs and unavailable capabilities clearly disclosed, with no claim of unlimited free AI generation, so that expectations are honest. Provenance: explicit.

FR-83 — Self-service enrollment. As an Anime Producer I should create my own account before creating private projects, so that my durable work is bound to me. Provenance: required_inference. Lifecycle: trigger — first use; result — account created and session established; failure — validation error with recovery.

FR-84 — Returning verification. As an Anime Producer I should verify my identity when returning before accessing protected projects, jobs, credits and exports, so that private state stays mine. Provenance: required_inference. Lifecycle: trigger — return visit; result — session established; failure — invalid-credential error with recovery.

FR-85 — Configured video provider prerequisite. As an Anime Producer I should have a configured, documented video-generation provider before real video jobs can run, and otherwise see configuration guidance, so that real generation is possible. Provenance: required_inference.

FR-86 — Server-side provider keys and configured audio integrations. As an Anime Producer I should have server-side provider API keys and configured audio integrations before real voice and audio tasks can run, so that audio is real. Provenance: required_inference.

FR-87 — Credit ledger initialization. As an Anime Producer I should have my server-authoritative credit ledger initialized with 100,000 daily credits and indefinite carry-forward, so that the credit policy is executable. Provenance: required_inference.

FR-88 — Persistent storage availability. As an Anime Producer I should have persistent database and object storage available for projects, jobs, clips and exports, so that durable state exists. Provenance: required_inference.

4. User Personas

Anime Producer

The Anime Producer is the primary owner of an anime project. They arrive with a complete creative package — story, screenplay, characters, dialogue, scene descriptions, reference images, voices and production instructions — and their defining responsibility is to run the One-Click Complete Episode workflow: validate the project, let the system organize the screenplay, create the production plan, break it into scenes and shots, build the continuity bible, prepare visual and animation instructions, generate reference images when supported, submit real video-generation jobs, track them, store clips, detect failed scenes, retry them, assemble approved scenes in screenplay order, synchronize dialogue, voice, music and sound effects, generate subtitles when requested, validate the final video and download a real MP4. They also configure providers, monitor jobs, manage exports and watch their credit balance and transaction history. Their decisions are about whether the package is complete, whether to retry a failed scene, and whether to accept a continuity conflict. They interact with the Scene Director (whose approved scenes feed assembly) and the Continuity and Asset Manager (whose bible and assets ground generation). Observable success: a verified, playable, downloadable MP4 episode exists and every job, credit and export record is truthful.

Scene Director

The Scene Director works scene by scene rather than episode-wide. Their defining responsibility is the Scene-by-Scene Production workflow: reviewing each scene's description, script and dialogue, character references, character actions and expressions, location and background, camera angles and movements, lighting and color direction, animation style, voice and audio instructions, duration and aspect ratio, visual prompt and negative prompt, and continuity information, then using Generate, Preview, Approve, Regenerate, Retry and Delete. They also edit scene clips in the Video Editor and save and reuse visual and negative prompts in Saved Prompts. Their key decisions are approval (which scenes are ready for assembly), regeneration (when a clip does not match the scene), and deletion (with confirmation). They interact with the Anime Producer, who assembles the episode, and the Continuity and Asset Manager, whose bible constrains each scene. Observable success: approved scenes are ready for assembly in screenplay order, with no unapproved or failed scene silently included.

Continuity and Asset Manager

The Continuity and Asset Manager owns the project's reusable production bible and the assets that feed generation. Their defining responsibility is maintaining exact character appearance, face and hairstyle references, costume and accessories, character height and proportions, character relationships, voice identity, emotional state, location and environment, time of day and weather, props and important objects, scene order and story chronology, screen direction and camera continuity, and previous-scene context. They resolve detected continuity conflicts through explicit approval, ensuring established character appearance and story facts are never silently changed. They manage the Character Library, Upload Library, Voice Studio (Telugu dialogue, character-specific voices, voice uploads, emotion-aware delivery where supported, dialogue timing, dubbing, lip-sync) and Music and SFX Studio (background music, ambient audio, sound effects, audio mixing), tracking which audio tasks are completed, unavailable or failed. They also generate required reference images when supported. Their decisions are about approving or rejecting continuity changes and about which voice and audio assets belong to which character and scene. Observable success: the bible is complete and consistent, conflicts are resolved with recorded approval, and audio task status is fully visible.

5. Core User Flows

Flow 1 — Anime Producer: One-Click Complete Episode

1. The Anime Producer opens Landing anonymously and selects "Start a new episode", routing to Sign Up.
2. On Sign Up, they create an account; the server establishes identity and routes them to Dashboard.
3. From Dashboard, they open My Projects and create a project, or open an existing one.
4. In Story Studio, they submit the complete story, screenplay, characters, dialogue, scene descriptions, reference images, voices and production instructions; autosave persists each change and confirms recovery after interruption.
5. In Screenplay Writer, they refine the screenplay; the live scene-count and shot-count update as it is parsed, and the episode production plan with scenes and shots is persisted.
6. In Provider Configuration, if no video provider is connected, they see clear configuration guidance and save server-side provider keys; capabilities, limits, quotas, duration limits and costs are disclosed. If they skip this, One-Click Episode Generator shows provider-required guidance instead of fake previews.
7. In One-Click Episode Generator, they select Generate Complete Episode. The system validates the project; on failure it lists specific reasons and blocks generation.
8. On validation success, the system understands and organizes the screenplay, creates the episode production plan, breaks it into scenes and shots, builds the character continuity bible, prepares visual and animation instructions, and generates required reference images when supported.
9. The system submits actual video-generation jobs to configured providers, saving each provider job ID and preventing duplicate jobs; the credit ledger charges exactly 1 credit per eligible successful job.

10. The Anime Producer watches progress in Generation Job Monitor: queued, processing, completed, failed and cancelled states with pill status chips; a single soft tomato pulse marks processing.
11. Completed clips are stored with metadata in Upload Library. Failed or incomplete scenes are detected and listed in One-Click Episode Generator; the producer retries them, and failed jobs are refunded.
12. Once scenes are approved, the system assembles them in screenplay order, synchronizes dialogue, voice, music and sound effects, generates subtitles when requested, and validates the final video.
13. On success, Export History shows the export record and a real download control for the verified playable MP4; the producer downloads the final episode. On failure, the export record shows the recorded error and no download button appears.
14. Continuation: the producer can revisit My Projects, Settings (balance and transaction history) and Export History at any time.

Flow 2 — Scene Director: Scene-by-Scene Production

1. The Scene Director signs in on Login and lands on Dashboard.
2. They open Scene-by-Scene Generator and review scene cards, each showing all twelve required scene fields and continuity information.
3. They select Generate on a scene; the job is submitted to a configured provider and appears in Generation Job Monitor as queued, then processing.
4. When the job completes, they select Preview and see the real stored clip; if no valid output exists, no preview is shown and the failure is explained.
5. If the clip does not match the scene, they select Regenerate (a new job without duplicates) or Retry for a failed job.
6. If a continuity conflict is detected, a warning appears and approval is required before the change proceeds; the Scene Director coordinates with the Continuity and Asset Manager.
7. When satisfied, they select Approve; the scene card shows the lilac approved chip.
8. They may open Video Editor to edit scene clips and Saved Prompts to save and reuse visual and negative prompts.
9. To remove a scene, they select Delete and confirm in the destructive-operation dialog.
10. Observable result: approved scenes are ready for assembly in screenplay order. Failure/recovery: failed jobs show tomato chips with retry; cancellation before processing incurs no charge.

Flow 3 — Continuity and Asset Manager: Production Bible and Assets

1. The Continuity and Asset Manager signs in on Login and opens Character Library.
2. They create and edit character records covering exact appearance, face and hairstyle references, costume and accessories, height and proportions, relationships, voice identity, emotional state, location and environment, time of day and weather, props and important objects, scene order and story chronology, screen direction and camera continuity, and previous-scene context.
3. When the continuity engine detects a conflict, the character card's conflict sticker flips to tomato and a warning appears; the manager reviews and explicitly approves or rejects the change. Established facts are never silently changed.
4. In Anime Image Generator, they generate required reference images when supported and save them to Upload Library.
5. In Voice Studio, they generate Telugu dialogue, assign character-specific voices, upload voices, and configure emotion-aware delivery where supported, dialogue timing, dubbing and lip-sync; each audio task shows completed, unavailable or failed.
6. In Music and SFX Studio, they add background music, ambient audio and sound effects and mix audio, tracking task status.
7. Observable result: the bible is complete and consistent, conflicts are resolved with recorded approval, and audio task status is fully visible. Failure/recovery: unavailable capabilities are disclosed honestly; failed audio tasks show retry.

Flow 4 — Anime Producer: Episode Assembly and Verified Export

1. The Anime Producer opens Episode Assembly after scenes are approved.
2. They review pre-assembly validation; unapproved or failed scenes are flagged rather than silently included.
3. They toggle subtitles when requested and select transitions where supported.
4. They select Assemble episode; the FFmpeg-backed backend combines scenes in screenplay order, handles different clip durations, normalizes dimensions and frame rates where possible, synchronizes audio, mixes BGM and SFX, and generates the final MP4.
5. The backend verifies the output file exists and is playable and records export status and errors.
6. On success, Export History shows the export record with a real download control; the producer downloads the verified MP4.
7. On failure, the export record shows the error and no download button or success message appears; the producer retries after correcting the cause.

Flow 5 — Anime Producer: Credits and Provider Setup

1. The Anime Producer opens Settings and sees the credit balance in tabular Bricolage numerals and the transaction history.
2. The ledger shows 100,000 daily credits with unused credits carried forward indefinitely; each eligible successful job deducts exactly 1 credit; failed jobs show refunds; jobs cancelled before processing show no charge; duplicate requests show no duplicate deductions.
3. In Provider Configuration, they save server-side provider API keys (never exposed in frontend code) and review capabilities, limits, quotas, duration limits and costs. Paid services are never activated automatically.
4. Observable result: the balance and history are truthful and provider readiness is explicit.

6. Visuals Colors and Theme

The muse is Pablo Stanley, and the headline is "Your episode starts with a story." The register is warm modular craft: a friendly production studio, not an enterprise console.

Light mode tokens

Status colours follow palette logic, never traffic-light red/amber/green.

Typography

• Headings: Bricolage Grotesque 700–800, optical-size axis pushed large, tracking −0.02em, sentence case (never all-caps), occasional single word in accent colour. Page titles clamp(40px, 7vw, 92px); section titles clamp(28px, 4vw, 48px). Scene numbers and credit balances use Bricolage tabular figures at 36–48px, weight 800.
• Body: Manrope 400–500 at 16px/1.65; UI labels 14px Manrope 600; micro-labels (provider names, job IDs, status chips) 12px Manrope 700 with 0.06em tracking.
• Scale: 1.333 modular on a 4pt baseline — 92/68/48/36/27/20/16/14.
• Screenplay text: Manrope 16px/1.8, 24px paragraph spacing, max measure 68ch.

Shape language

• Cards 24px radius; buttons and status chips full pills; inputs 16px; modals 28px.
• Cards carry a soft offset shadow 0 6px 0 rgba(36,27,58,0.08) plus a 1px #241B3A border at 6% opacity — paper stickers, not floating glass.
• Blob and sticker shapes only as flat decoration behind empty states and section openers, never behind text.
• Icons: 2.5px-stroke rounded vectors in ink with one accent fill.
• No sharp corners except the screenplay page, which keeps a crisp white sheet edge.

Layout

• Desktop left rail 280px listing Dashboard, Story Studio, Screenplay, One-Click Episode, Scene-by-Scene, Characters, Uploads, Voice Studio, Music & SFX, Editor, Assembly, Jobs, Exports, Settings; at 375px a bottom tab bar of five items plus a More sheet.
• Content: 12-column grid, 24px gutters, max 1280px centred, 48px section spacing.
• Scene lists reflow 3 → 2 → 1 column; character library is a card grid with chip rows; job monitor and export history are dense friendly tables with pill chips and 12px metadata rows.
• Empty states use a modular character holding the relevant object plus one plain-text next action, and a "Configure provider" pill where a provider is required.
• Readable text and controls stay whole inside the viewport and container at 375px, 768px and 1280px; imagery and decoration may bleed, rotate or overlap but never cover text or controls.

Imagery

Modular vector illustration in the Humaaans/Open Peeps spirit — interchangeable heads, hair, costumes and poses. Character cards show flat vector portraits on pastel fields; scene cards show 16:9 flat vector thumbnails with location plates. No photographic hero, no gradient blobs, no 3D renders. Real generated video is the only photographic media, framed in a white 24px-radius card with a "verified clip" pill.

7. Signature Design Concept

The public entry is a horizontal band, not a centred SaaS stack. On the left seven columns, on cream ground, sits the oversized flush-left Bricolage headline "Your episode starts with a story." at clamp(40px, 7vw, 92px), with the word "story" set in sunflower #F4A62A, above a single 16px Manrope line and a sunflower pill "Start a new episode" beside a ghost pill "Open a project". On the right five columns sits a composed flat vector stage: three overlapping rounded cards at slight rotations — a screenplay sheet, a character portrait card and a scene thumbnail — each with its own soft offset shadow, arranged like papers on a director's desk, with a small tomato status chip "3 scenes awaiting render" pinned to the top card. There is no gradient, no glow and no centred alignment; the type mass on the left dominates, and the illustration cluster bleeds slightly past the right gutter at 1280px while staying fully inside the container at 375px. The concept recomposes only accepted content and controls: the two entry actions route to Sign Up and Login, and the status chip reflects the honest production-state vocabulary used throughout the workspace.

8. Interaction Model & Motion Direction

Interaction Model: Animated Motion Tempo: expressive Hero Dimensionality: layered_2d

Landing Hero Motion Brief

• Focal subject: the rotated stack of three paper-like cards (screenplay sheet, character portrait card, scene thumbnail) beside the oversized headline, with the tomato "3 scenes awaiting render" chip pinned to the top card.
• Input → transformation → outcome thesis: as the pointer moves across the hero, the three cards shift by a few pixels of parallax depth in layered 2D, settling into a composed director's-desk arrangement; the headline stays fixed and dominant, and the entry pills respond with a springy press. No new behavior is introduced — the cards represent the accepted screenplay, character and scene objects, and the chip reflects accepted job state.
• Motion vocabulary: springy but brief — cards and buttons scale to 0.97 on press and 1.02 on hover over 160ms with cubic-bezier(0.34, 1.56, 0.64, 1); scene cards enter with a 40ms stagger on first paint only; job status chips cross-fade between states with a single soft pulse on the tomato accent while processing; progress bars fill linearly and never bounce; empty-state illustrations do one small nod (translateY 4px) on hover, never on loop.
• Composed first frame: headline flush left with "story" in sunflower, supporting line beneath, sunflower and ghost pills aligned on one baseline, and the three-card cluster already composed at its resting rotation with the tomato chip visible.
• Reduced-motion state: all transforms removed, staggers collapse to instant, the processing pulse becomes a static dot, and the hero renders as a static composed arrangement with every card and label fully readable.

9. Non-Functional Requirements

• NFR-1 — Device optimization. The application is optimized for Windows laptops and Android phones, with responsive layouts that keep text and controls whole at 375px, 768px and 1280px. Provenance: explicit.
• NFR-2 — Performance and quality. Smooth navigation, efficient media loading, pagination for large project lists, background processing, retry and recovery mechanisms, clear progress indicators, meaningful empty states and accessible error messages. Provenance: explicit.
• NFR-3 — No broken routes or placeholders. No broken routes, no silent failures, no incomplete placeholder screens, no fake statistics and no fake generated media. Provenance: explicit.
• NFR-4 — Security and privacy. Projects private by default; API keys never in frontend code; secure server-side authorization; validated file uploads; restricted access to private project media; protection against duplicate and unauthorized actions; confirmation before destructive operations; error logs without secrets; no automatic activation of paid services. Provenance: explicit.
• NFR-5 — Data durability. Persistent database and object storage; important project data never stored only in temporary browser state; autosave, recovery, backup and restore, safe deletion and data validation. Provenance: explicit.
• NFR-6 — Honest generation and export. Never claim a video was generated without a valid output; never display a fake download button or false export-success message; verify the final MP4 exists and is playable. Provenance: explicit.
• NFR-7 — Credit integrity. Server-authoritative ledger; exactly 1 credit per eligible successful job; refunds on failure; no charge for pre-processing cancellation; unique job IDs; no duplicate deductions; never simulate successful transactions. Provenance: explicit.

• NFR-8 — Provider honesty. Integrate only real, documented AI video-generation APIs; disclose provider quotas, duration limits, costs and unavailable capabilities; never claim unlimited free AI generation. Provenance: explicit.
• NFR-9 — Completion discipline. A feature is COMPLETE only when frontend works, backend works, data persists, errors are handled, important workflows are tested, and external integrations are configured and verified; status system maintained; missing integrations never hidden. Provenance: explicit.
• NFR-10 — Automated testing. Tests cover authentication, project creation, autosave, character persistence, upload validation, scene generation submission, job status updates, retry and cancellation, credit deduction and refund, episode assembly, export validation, mobile responsiveness, and authorization and private media access; discovered bugs fixed before completion. Provenance: explicit.
• NFR-11 — Accessibility of motion. Under prefers-reduced-motion, transforms are removed, staggers collapse to instant, and the processing pulse becomes a static dot. Provenance: explicit (creative direction).

10. Tech Stack

• Frontend: React application UI.
• Backend: shared FastAPI process for application APIs and domain modules, including provider orchestration, media assembly and the credit ledger.
• Database: MariaDB for application-owned persistent data.
• Object storage: for uploaded and generated media (clips, reference images, voices, audio, final MP4).
• Redis: for background job coordination and shared state.
• LiteLLM: gateway for the backend's model-provider calls.
• PostgreSQL: supports LiteLLM; separate from application-owned storage.
• Media processing: FFmpeg (or another suitable server-side media-processing solution) for episode assembly.
• Provider integrations: only real, documented AI video-generation APIs and real supported audio integrations, with all API keys held server-side.

11. Assumptions and Constraints

• A-1: The existing LAXMAN AI project is upgraded in place; no new project is created and no working feature is removed. Provenance: explicit.
• A-2: A prompt generator or static UI is not an acceptable final product. Provenance: explicit.
• A-3: Real generation requires a configured, documented video provider; without one, configuration guidance is shown and no fake previews are substituted. Provenance: explicit / required_inference.
• A-4: Real voice and audio tasks require configured audio integrations and server-side provider keys. Provenance: required_inference.
• A-5: Application-owned identity is required because projects, jobs, credits and exports are private durable state bound to the correct producer; Sign Up and Login are anonymous entry surfaces and all workspace destinations require login. Provenance: required_inference.
• A-6: The credit ledger initializes with 100,000 daily credits and indefinite carry-forward. Provenance: explicit / required_inference.
• A-7: Persistent database and object storage are available for projects, jobs, clips and exports. Provenance: required_inference.
• A-8: Provider quotas, duration limits, costs and unavailable capabilities are disclosed; paid services are never activated automatically. Provenance: explicit.
• A-9: Work continues on the existing project until the available environment's implementation and testing work is complete; the build does not stop after designing the dashboard. Provenance: explicit.
• A-10: Visual tokens, typography, shape language, layout and motion follow the supplied creative direction; unspecified details are filled by the catalogue only. Provenance: explicit (creative direction).

12. Glossary

• One-Click Complete Episode: The workflow in which the producer enters all production details once and selects Generate Complete Episode to run the full pipeline.
• Scene-by-Scene Production: The workflow for generating and reviewing individual scenes before episode assembly.
• Production bible / continuity bible: The reusable per-project record of character appearance, references, costume, proportions, relationships, voice identity, emotional state, locations, time of day and weather, props, chronology, screen direction, camera continuity and previous-scene context.
• Continuity conflict: A detected mismatch against established character appearance or story facts that requires a warning and explicit approval.
• Provider job ID: The identifier returned by a configured AI video-generation provider and saved for tracking and recovery.
• Credit ledger: The server-authoritative record of 100,000 daily credits, indefinite carry-forward, 1 credit per eligible successful job, refunds on failure, no charge for pre-processing cancellation, and no duplicate deductions.
• Episode assembly: The FFmpeg-backed process that combines approved scenes in screenplay order, normalizes dimensions and frame rates where possible, synchronizes audio, adds subtitles when requested, mixes BGM and SFX, adds transitions where supported, and generates a verified final MP4.
• Export record: The persisted record of an assembly export's status and errors, with a download control only for a verified playable file.
• Feature status system: The maintained statuses COMPLETE AND TESTED, IMPLEMENTED, PROVIDER REQUIRED, IN PROGRESS and BLOCKED.
• Verified clip: A stored generated clip with metadata that actually exists and is playable; the only photographic media shown on screen.