System Requirements Document for intelig-ncia-artificial

1. Introduction

intelig-ncia-artificial is a generative artificial intelligence product that produces video, produces images, and answers questions. The product intent is stated directly by the user: "Desenvolva uma INTELIGÊNCIA ARTIFICIAL QUE CONSEGUE FAZER VÍDEO imagens e RESPONDER perguntas" — build an AI that can make video, make images, and answer questions.

The audience is twofold, matching the two accepted personas:

• Criador de Conteúdo Multimídia — a creator who wants to produce visual material (video and images) from their own instructions and receive the generated files as output, repeating the flow for each new piece of content.
• Usuário que Faz Perguntas — a user who wants to ask the AI questions and receive text answers, chaining new questions from the answers received.

The product is delivered as a first-party custom web application with a backend integration to the generative AI capability. It is a creative, deep-tech tool: the emotional register is awe and creative power, not productivity calm. The interface is dark, cinematic, and motion-led, and the imagery shown is the product's own generated output.

2. System Overview

The system exposes three generative capabilities — video generation, image generation, and question answering — through a first-party custom web application.

Actors

• Criador de Conteúdo Multimídia (human persona) — submits generation instructions for video and images and receives the generated media.
• Usuário que Faz Perguntas (human persona) — submits questions and receives text answers.
• Generative AI backend (non-persona system actor) — the model/service that performs video generation, image generation, and question answering on behalf of the application.

Accepted behavior

• The AI generates video from user instructions.
• The AI generates images from user instructions.
• The AI answers questions with text responses.

Ownership and delivery

• All four destinations are first-party application pages: Landing, Video, Images, Questions.
• The generative work itself is performed by the backend integration; the human-facing interaction (instruction entry, submission, viewing results, retrying) is owned by the first-party pages.
• No account, login, or identity flow is part of the accepted scope. All four pages are reachable without authentication (access_requirement: none for every surface).

Narrow exclusions

• No adjacent capabilities are included: no social feed, no team collaboration, no billing, no asset marketplace, no model-training UI, no account management.
• No stock photography or illustration is used as product imagery; the imagery is the product's own generated output.

2a. Product Interpretation and Delivery Boundary

The product is a generative AI studio. A visitor arrives at the Landing page, which explains in one screen that the AI generates video, generates images, and answers questions, and which offers the same prompt console used everywhere in the product. From there the visitor moves into one of three workspaces — Video, Images, or Questions — each dedicated to one capability.

Delivery is first-party and headless-backed: the application owns the interface, the instruction input, the output well, the history of generations, and the error/recovery states; the generative model is reached through a backend integration. The application does not own the model itself.

Current vs. future boundary. Only the three stated capabilities are current: video generation, image generation, and question answering. Nothing beyond these is committed. There is no accepted future roadmap item in the source; the future section of this document is therefore empty of product commitments.

Access boundary. The source states no login, no account, and no private ownership of state. Every page is anonymously reachable. Session continuity is limited to what the browser session holds; no application-owned identity is established, and no permission differentiation exists between users.

2b. Source Content Inventory

Not applicable — no reference directive in this project declares content_source.

2c. Page Content and Component Coverage

Landing

• Information / state: The product's proposition — an AI that generates video, generates images, and answers questions. A full-viewport generative canvas forms the environment; an oversized headline sits directly on it; a thin top navigation carries the wordmark and the three mode links.
• Primary action: Enter a mode — Vídeo, Imagem, or Pergunta — either from the top navigation or from the mode tabs on the prompt console.
• Supporting actions: Type an instruction into the prompt console; switch the console's mode tab; submit with the Generate button.
• Domain entities: Instruction (prompt text), Mode (Vídeo / Imagem / Pergunta), Generation (the resulting video, image, or answer).
• Component responsibilities:
  • Generative hero canvas — full-viewport real-time particle/fluid field on #05060A, cyan and magenta, slow continuous drift; dims locally under the headline via a soft radial mask so text contrast stays above 4.5:1.
  • Top navigation — single hairline row: wordmark left, three mode links right, separated by hairline rules.
  • Hero headline — Space Grotesk, clamp(44px, 9vw, 120px), #F2F4F8, bottom-left anchored, spanning roughly 9 columns, no card behind it.
  • Prompt console — bottom-anchored pill-shaped bar with mode tabs (Vídeo / Imagem / Pergunta), a wide instruction input, and a #FF4D8D Generate button.
  • Gallery wall — below the fold, generated media as unevenly-spaced museum-wall tiles with hairline cyan inner strokes and monospace metadata captions.
• States:
  • Loading: hero canvas initializes; a static generative frame is shown until the field is live.
  • Empty: gallery wall shows no tiles; the console is the only active element.
  • Success: a submitted instruction routes to the matching workspace and the result appears there.
  • Error: if the backend is unreachable, an inline message appears at the console and the instruction text is preserved for retry.
  • Recovery: the user can resubmit the preserved instruction or switch mode.

Video

• Information / state: The video workspace. The generative canvas or the current video output is the dominant surface; the prompt console is pinned to the bottom; generation parameters sit in a collapsible left rail.
• Primary action: Submit a video instruction and receive a generated video.
• Supporting actions: Edit the instruction; open/close the parameter rail; play, pause, and replay the generated video; start a new generation; retry a failed generation.
• Domain entities: Instruction, Video generation (media file, duration, model, seed), Generation status.
• Component responsibilities:
  • Output well — near-black rectangle, 20–28px radius, 1px inner stroke rgba(110,231,249,0.18), holding the generated video (looping, muted by default) or the in-progress state.
  • Prompt console — the same shared component as on every workspace, with the Vídeo tab active.
  • Parameter rail — collapsible left rail for generation parameters.
  • Metadata caption — monospace, muted #8A93A6: model, seed, duration.
  • History strip — previously generated videos for the session, as museum-wall tiles.
• States:
  • Loading: prompt submission triggers the bloom — canvas brightens, particles converge toward the output well; the result fades in from the convergence point. No spinner.
  • Empty: output well shows an invitation to describe the video to generate.
  • Success: the generated video plays in the output well with its metadata caption.
  • Error: the output well shows a failure message with the original instruction intact and a retry action.
  • Recovery: retry re-submits the preserved instruction; the user may also edit it before retrying.

Images

• Information / state: The image workspace. The generative canvas or the current image output is the dominant surface; the prompt console is pinned to the bottom; generation parameters sit in a collapsible left rail.
• Primary action: Submit an image instruction and receive a generated image.
• Supporting actions: Edit the instruction; open/close the parameter rail; view the generated image at full size; start a new generation; retry a failed generation.
• Domain entities: Instruction, Image generation (media file, model, seed), Generation status.
• Component responsibilities:
  • Output well — near-black rectangle, 20–28px radius, 1px inner stroke rgba(110,231,249,0.18), holding the generated image or the in-progress state.
  • Prompt console — the same shared component, with the Imagem tab active.
  • Parameter rail — collapsible left rail for generation parameters.
  • Metadata caption — monospace, muted #8A93A6: model, seed.
  • History wall — previously generated images for the session, as unevenly-spaced museum-wall tiles.
• States:
  • Loading: bloom feedback as on Video — canvas brightens, particles converge, result fades in.
  • Empty: output well shows an invitation to describe the image to generate.
  • Success: the generated image appears in the output well with its metadata caption.
  • Error: failure message in the output well with the instruction preserved and a retry action.
  • Recovery: retry or edit-and-resubmit.

Questions

• Information / state: The question-answering workspace. The conversation thread is the dominant surface; the prompt console is pinned to the bottom; parameters sit in a collapsible left rail.
• Primary action: Ask a question and receive a text answer.
• Supporting actions: Continue the thread with a follow-up question; scroll the thread; start a new thread; retry a failed question.
• Domain entities: Question (text), Answer (text), Thread (ordered sequence of question/answer turns).
• Component responsibilities:
  • Thread surface — the ordered question/answer turns, set in IBM Plex Sans at 16–18px with 1.6 line-height for long-answer readability.
  • Prompt console — the same shared component, with the Pergunta tab active.
  • Parameter rail — collapsible left rail.
  • Turn metadata — monospace, muted #8A93A6: model, timestamp.
• States:
  • Loading: the answer area shows the AI's "voice" — an electric cyan #6EE7F9 cursor/active state — while the answer is produced.
  • Empty: the thread shows an invitation to ask the first question.
  • Success: the answer appears as the next turn in the thread.
  • Error: the failed turn shows a failure message with the question preserved and a retry action.
  • Recovery: retry the question, or rephrase it as a new turn.

3. Functional Requirements

FR-1 — Generate video from an instruction

As a Criador de Conteúdo Multimídia I should submit an instruction describing a video and receive a generated video so that I can produce visual material from my own direction.

• Provenance: explicit
• Trigger / input: The creator enters a video instruction in the prompt console on the Video page (or selects the Vídeo tab on the Landing console and submits).
• Observable result / state change: The output well enters the generating state (bloom feedback: canvas brightens, particles converge toward the output well), then the generated video fades in and plays in the output well, accompanied by a monospace metadata caption (model, seed, duration).
• Access state: No authentication required; the page is anonymously reachable.
• Material failure / recovery: If generation fails, the output well shows a failure message with the original instruction preserved and a retry action; retrying re-submits the preserved instruction, and the creator may edit it first.
• Continuation: The creator can start a new generation, and the completed video joins the session history strip as a museum-wall tile.

FR-2 — Generate images from an instruction

As a Criador de Conteúdo Multimídia I should submit an instruction describing an image and receive a generated image so that I can produce visual material from my own direction.

• Provenance: explicit
• Trigger / input: The creator enters an image instruction in the prompt console on the Images page (or selects the Imagem tab on the Landing console and submits).
• Observable result / state change: The output well enters the generating state (bloom feedback), then the generated image appears in the output well with its monospace metadata caption (model, seed).
• Access state: No authentication required; the page is anonymously reachable.
• Material failure / recovery: If generation fails, the output well shows a failure message with the original instruction preserved and a retry action; retrying re-submits the preserved instruction, and the creator may edit it first.
• Continuation: The creator can start a new generation, and the completed image joins the session history wall as a museum-wall tile.

FR-3 — Answer questions

As a Usuário que Faz Perguntas I should ask a question and receive a text answer so that I can resolve my doubt.

• Provenance: explicit
• Trigger / input: The user types a question in the prompt console on the Questions page (or selects the Pergunta tab on the Landing console and submits).
• Observable result / state change: The answer area shows the AI's active state (electric cyan #6EE7F9 cursor), then the answer appears as the next turn in the thread, with monospace turn metadata (model, timestamp).
• Access state: No authentication required; the page is anonymously reachable.
• Material failure / recovery: If the answer fails, the failed turn shows a failure message with the question preserved and a retry action; retrying re-submits the question, and the user may rephrase it as a new turn.
• Continuation: The user can chain a new question from the answer received, continuing the thread.

FR-4 — Choose the generation mode from a single console

As a Criador de Conteúdo Multimídia and as a Usuário que Faz Perguntas I should switch between the Vídeo, Imagem, and Pergunta modes from the same prompt console so that I can reach the capability I need without hunting for a different interface.

• Provenance: required_inference (the shared console is the accepted interaction surface across the three workspaces; the mode tabs are the mechanism that makes the three accepted capabilities reachable from one entry point)
• Trigger / input: The user selects a mode tab on the prompt console, or a mode link in the top navigation.
• Observable result / state change: The active tab changes, the console's output well context changes to match the selected mode, and the corresponding workspace becomes the working surface.
• Access state: No authentication required.
• Material failure / recovery: Not applicable — mode switching is a local interface state.
• Continuation: The user submits an instruction in the selected mode.

FR-5 — Review previously generated media in the session

As a Criador de Conteúdo Multimídia I should see the videos and images I have already generated in this session so that I can compare results and reuse a direction.

• Provenance: required_inference (the accepted lifecycle of repeated generation — "repetindo o fluxo para cada novo conteúdo" — requires the produced results to remain observable after the output well moves on)
• Trigger / input: The creator completes one or more generations.
• Observable result / state change: Completed generations appear as museum-wall tiles with uneven spacing, hairline cyan inner strokes, and monospace metadata captions; videos loop muted.
• Access state: No authentication required; the history is session-scoped.
• Material failure / recovery: If a tile's media fails to load, the tile shows a placeholder with its metadata caption intact.
• Continuation: The creator can start a new generation from the console at any time.

FR-6 — Recover from a failed generation or answer

As a Criador de Conteúdo Multimídia and as a Usuário que Faz Perguntas I should be able to retry a failed generation or question without retyping it so that a transient failure does not cost me my work.

• Provenance: required_inference (indispensable recovery mechanics for the accepted generation and answering lifecycles)
• Trigger / input: A generation or answer fails.
• Observable result / state change: The failure is shown in the output well or thread turn, the original instruction or question remains in place, and a retry action is offered.
• Access state: No authentication required.
• Material failure / recovery: This requirement is the recovery path; if retry also fails, the same preserved instruction and retry action remain available.
• Continuation: On success, the result appears normally and the user continues with a new instruction or question.

4. User Personas

Criador de Conteúdo Multimídia

Product context. This persona comes to the product to make things: video and images. They are digitally native, comfortable with a dark, motion-rich interface, and they treat the product as a creative instrument rather than a form to fill in. Their work is iterative — one instruction produces one artifact, and the next artifact starts from a new instruction.

Primary goal. Produce visual material — video and images — from their own instructions and obtain the generated files as results.

Distinct accepted responsibilities.

• Compose and submit video instructions on the Video page.
• Compose and submit image instructions on the Images page.
• Judge the generated result and decide whether to accept it, retry it, or issue a new instruction.
• Repeat the flow for each new piece of content.

Relevant inputs and decisions. The instruction text; the mode tab (Vídeo or Imagem); the generation parameters in the collapsible left rail; the decision to retry versus re-instruct after a failure.

Interactions with other accepted participants. This persona does not interact with the Usuário que Faz Perguntas. Their counterpart is the generative AI backend, which receives the instruction and returns the media. The backend's response is what the creator observes in the output well.

Observable success. A generated video or image appears in the output well, plays or displays correctly, carries its metadata caption, and joins the session history wall. Failure is observable as a preserved instruction plus a retry action, never as a lost instruction.

What makes this role different. The creator's unit of work is a media artifact and their feedback loop is visual and iterative — they evaluate an image or a video, not a sentence. Their success criterion is the quality and existence of a file, and their natural rhythm is generate → look → generate again.

Usuário que Faz Perguntas

Product context. This persona comes to the product to find out something. They may arrive with a single doubt or with a line of inquiry they want to pursue. They read more than they look, and the quality of the answer's prose matters to them.

Primary goal. Ask the AI questions and receive text answers to their doubts.

Distinct accepted responsibilities.

• Compose and submit a question on the Questions page.
• Read the answer and decide whether it resolves the doubt.
• Chain a new question from the answer received, continuing the thread.
• Retry or rephrase a question that failed or did not satisfy them.

Relevant inputs and decisions. The question text; the decision to continue the thread versus start a new one; the decision to rephrase after an unsatisfactory answer.

Interactions with other accepted participants. This persona does not interact with the Criador de Conteúdo Multimídia. Their counterpart is the generative AI backend, which receives the question and returns the text answer. The answer's arrival is what the user observes in the thread.

Observable success. The answer appears as the next turn in the thread, set in readable body type, with turn metadata. Failure is observable as a preserved question plus a retry action.

What makes this role different. The questioner's unit of work is a conversational turn, and their feedback loop is textual and cumulative — each answer becomes the context for the next question. Their success criterion is comprehension, not a file, and their natural rhythm is ask → read → ask again.

5. Core User Flows

Flow A — Criador de Conteúdo Multimídia generates a video

1. The creator opens the Landing page. The full-viewport generative canvas is drifting; the headline "A IA que gera vídeo, imagem e resposta." sits on it, bottom-left, with the particle field dimmed locally beneath it for contrast.
2. The creator selects the Vídeo mode — either from the top navigation's mode links or from the mode tabs on the bottom-anchored prompt console.
3. The Video workspace opens: the output well is the dominant surface, the prompt console is pinned to the bottom with the Vídeo tab active, and the parameter rail is available on the left.
4. The creator types an instruction describing the video they want into the console's input.
5. The creator presses the #FF4D8D Generate button.
6. Observable result: the bloom fires — the canvas brightens, particles converge toward the output well, and the generated video fades in from the convergence point. No spinner is shown.
7. The generated video plays in the output well, looping and muted by default, with a monospace metadata caption reading model, seed, and duration.
8. Continuation: the creator starts a new generation, and the completed video joins the session history strip as a museum-wall tile with a hairline cyan inner stroke.
9. Failure / recovery: if generation fails, the output well shows a failure message, the instruction remains in place, and a retry action is offered. The creator retries the preserved instruction, or edits it and submits again. On success, the flow resumes at step 7.

Flow B — Criador de Conteúdo Multimídia generates an image

1. The creator opens the Landing page and selects the Imagem mode from the top navigation or the console's mode tabs.
2. The Images workspace opens: the output well is the dominant surface, the prompt console is pinned to the bottom with the Imagem tab active, and the parameter rail is available on the left.
3. The creator types an instruction describing the image they want.
4. The creator presses Generate.
5. Observable result: the bloom fires and the generated image fades in from the convergence point in the output well.
6. The generated image displays with its monospace metadata caption (model, seed).
7. Continuation: the creator starts a new generation, and the completed image joins the session history wall as a museum-wall tile.
8. Failure / recovery: if generation fails, the output well shows a failure message with the instruction preserved and a retry action. The creator retries or edits and resubmits. On success, the flow resumes at step 6.

Flow C — Usuário que Faz Perguntas asks a question and chains a follow-up

1. The user opens the Landing page and selects the Pergunta mode from the top navigation or the console's mode tabs.
2. The Questions workspace opens: the thread is the dominant surface, the prompt console is pinned to the bottom with the Pergunta tab active.
3. The user types a question into the console's input.
4. The user presses Generate.
5. Observable result: the answer area shows the AI's active state — an electric cyan #6EE7F9 cursor — while the answer is produced.
6. The answer appears as the next turn in the thread, set in IBM Plex Sans at 16–18px with 1.6 line-height, with monospace turn metadata (model, timestamp).
7. Continuation: the user reads the answer and chains a new question from it, continuing the thread. The new question is submitted the same way and its answer becomes the following turn.
8. Failure / recovery: if the answer fails, the failed turn shows a failure message with the question preserved and a retry action. The user retries the question, or rephrases it as a new turn. On success, the flow resumes at step 6.

Flow D — Either persona reaches the right capability from the shared console

1. The user is on any of the four pages.
2. The user selects a different mode tab on the prompt console — Vídeo, Imagem, or Pergunta — or a mode link in the top navigation.
3. Observable result: the active tab changes and the corresponding workspace becomes the working surface, with the console's output well context matching the selected mode.
4. Continuation: the user submits an instruction or question in the newly selected mode, entering Flow A, B, or C at its submission step.

6. Visuals Colors and Theme

Muse and headline. The muse is Refik Anadol — data made physical, a generative AI studio where pixels become weather. The headline idea: the product's own generative output is the interface's material, and the interface is a dark museum for it.

Mode. Dark mode only. There is no light theme.

Colour tokens (exact hex, by role)

The two hues never appear as a gradient blob; they appear as luminous particles and thin strokes inside the generative canvas. The primary cyan is also used for the 1px inner stroke on output wells and prompt panels at rgba(110,231,249,0.18).

Typography

• Headings: Space Grotesk, weights 300–500, very large display sizes with tight tracking -0.02em, sentence case for headlines; uppercase for micro-labels at 11–12px with 0.18em tracking.
• Body: IBM Plex Sans, weights 400/500, 16–18px, line-height 1.6.
• Type scale (1.25 modular): 12 / 14 / 16 / 20 / 25 / 31 / 39 / 49 / 61 / 76 / 96 / 120.
• Display clamp: hero headline clamp(44px, 9vw, 120px); section headlines clamp(28px, 4.5vw, 56px).
• Metadata: monospace captions for model, seed, duration, timestamp.

Shape language. Soft-void geometry: output wells and prompt panels are near-black rectangles with 20–28px radii and a 1px inner stroke of rgba(110,231,249,0.18) that reads as a faintly luminous edge — never a glass blur. Buttons are pills. The generative canvas has no border; it bleeds to the viewport edge and dissolves into the background via a radial mask. No drop shadows — depth comes from luminance, not elevation.

Layout rhythm. Full-bleed generative canvas as the top-of-page environment with UI floating inside it: left-aligned oversized headline over the canvas, bottom-anchored prompt console, thin top navigation with wordmark left and three mode links right separated by hairline rules. Below the fold, output history appears as a museum wall — large, unevenly-spaced tiles with generous negative space, not a uniform card grid. The three workspaces share one skeleton: canvas or thread as the dominant surface, prompt console pinned to the bottom, parameters in a collapsible left rail.

Spacing rhythm. Generous negative space around the museum wall; hairline rules as the only separators; no card chrome around the headline.

Imagery style. The product's own generated media is the imagery — no stock photography, no illustration. The hero canvas is a real-time WebGL particle/fluid field seeded from the product's data. Gallery tiles show actual generated videos (looping muted) and images, framed by the same dark ground. Occasional thin topographic line overlays (Anadol-style data scrims) sit at 8% opacity behind section headers.

Accessibility. Readable text and controls stay whole at 375px, 768px, and 1280px — headlines, wordmarks, labels, numbers, and controls stay entirely inside the viewport and their container, wrapping or scaling to fit, with no other element covering them. The hero headline's local radial dim keeps contrast above 4.5:1 against the particle field.

7. Signature Design Concept

The thinking field. The public entry is a full-viewport WebGL generative canvas on #05060A: a slow luminous particle field in cyan and magenta that reads as the AI thinking. It never repeats exactly — it is driven by a seeded noise field.

Over it, bottom-left anchored, sits an oversized Space Grotesk headline at clamp(44px, 9vw, 120px) in #F2F4F8: "A IA que gera vídeo, imagem e resposta." It spans roughly 9 columns of the viewport and sits directly on the canvas with no card behind it. The particle field dims locally under the text via a soft radial mask so contrast stays above 4.5:1.

Bottom-right of the same screen is the pill-shaped prompt console with mode tabs (Vídeo / Imagem / Pergunta) and a #FF4D8D Generate button. The top navigation is a single hairline row: wordmark left, three mode links right.

Nothing is centered. Nothing is a blue button on white. The headline is not a stack of headline + subtext + button over a gradient blob — it is text living inside a moving field, with the product's single "mouth" at the base of the screen.

8. Interaction Model & Motion Direction

Interaction Model: Animated Motion Tempo: cinematic Hero Dimensionality: webgl

Landing Hero Motion Brief

• Focal subject: A real-time WebGL particle/fluid field on #05060A — luminous cyan and magenta particles in slow, non-repeating drift, seeded from a noise field. It is the visual form of the AI thinking.
• Input → transformation → outcome thesis: The user's instruction enters the bottom-anchored prompt console → on submission the canvas brightens and the particles converge toward the output well (the bloom) → the generated video, image, or answer fades in from the convergence point. Motion is the feedback; there is no spinner.
• Motion vocabulary: Continuous slow generative drift; bloom on submission; scroll-linked morph where the hero particle field compresses into the first gallery tile so the transition from "asking" to "result" is one continuous gesture rather than a page change. All transitions 400–900ms with cubic-bezier(0.22, 1, 0.36, 1). No bouncy or springy easing.
• Composed first frame: Full-viewport particle field at rest-drift; oversized headline bottom-left on the field with a local radial dim beneath it; pill prompt console bottom-right with mode tabs and the magenta Generate button; hairline top nav with wordmark left and three mode links right.
• Reduced-motion state: With prefers-reduced-motion, the canvas freezes on a single static frame — a still generative render — and output appears with a simple 200ms fade. The scroll-linked morph is disabled and the gallery wall is presented as a static arrangement.

Landing Hero 3D Scene Brief — DIRECTION-DERIVED

A single crafted real-time object: a seeded particle field rendered in WebGL/R3F on a #05060A ground. The field is the product's defining state made visible — an AI that is continuously generating. Particles carry the two product hues (cyan #6EE7F9 and magenta #FF4D8D) as luminous points and thin strokes, never as a gradient blob. The field drifts on a slow noise-driven flow, dims locally under the headline via a radial mask, and on prompt submission converges toward the output well before the result fades in. Under prefers-reduced-motion the scene renders one static frame and holds it.

9. Non-Functional Requirements

• NFR-1 — Dark-mode-only presentation. The product is presented exclusively on the dark ground #05060A; no white or near-white background appears anywhere. Provenance: explicit (creative direction).
• NFR-2 — Readable text and controls at every viewport. Headlines, wordmarks, labels, numbers, and controls remain entirely inside the viewport and their container at 375px, 768px, and 1280px, wrapping or scaling to fit, with no other element covering any part of them. Provenance: explicit (creative direction).
• NFR-3 — Hero contrast. The hero headline maintains a contrast ratio above 4.5:1 against the particle field via the local radial dim. Provenance: explicit (creative direction).
• NFR-4 — Reduced-motion support. With prefers-reduced-motion, the generative canvas freezes on a single static frame and output appears with a 200ms fade; the scroll-linked morph is disabled and the gallery wall remains usable as a static arrangement. Provenance: explicit (creative direction).
• NFR-5 — Motion timing. All transitions run 400–900ms with cubic-bezier(0.22, 1, 0.36, 1); no bouncy or springy easing. Provenance: explicit (creative direction).
• NFR-6 — Backend integration for generative work. Video generation, image generation, and question answering are performed through a backend integration; the application owns the interface and the interaction lifecycle. Provenance: explicit (planning scope: requires_backend_integration: true).
• NFR-7 — Anonymous access. No page requires authentication; no account, login, or identity flow is part of the product. Provenance: explicit (planning scope: access_requirement: none on all four surfaces).
• NFR-8 — No stock imagery. No stock photography or illustration is used; all imagery is the product's own generated output. Provenance: explicit (creative direction).
• NFR-9 — Forbidden typography. Inter, Roboto, Arial, Helvetica, Open Sans, Lato, Poppins, and system-ui are not used for headings or body. Provenance: explicit (creative direction).
• NFR-10 — Forbidden colour. Blue–indigo primaries (#0057FF, #2563EB, #4F46E5, #6366F1) and any bootstrap-blue accent are not used. Provenance: explicit (creative direction).
• NFR-11 — No glassmorphism. Frosted translucency and blur panels are not used; depth comes from luminance. Provenance: explicit (creative direction).

10. Tech Stack

• Frontend: React (custom first-party web application, custom_ui: true).
• 3D / generative hero: WebGL via React Three Fiber (the creative direction specifies hero dimensionality: webgl and a real-time WebGL/R3F hero subject).
• Backend: Python / FastAPI, providing the integration to the generative AI capability for video generation, image generation, and question answering.
• Storage: Object storage for generated video and image files, plus a lightweight record store for generation metadata (model, seed, duration, timestamp) and question/answer turns.
• Containerization: Docker with docker-compose for local and single-host deployment.
• Orchestration: Kubernetes only if the deployment requires it; not otherwise specified by the source.

11. Assumptions and Constraints

• A-1 — Session-scoped history. Generated media and question threads persist for the browser session. No application-owned identity is established, so no cross-session or cross-device continuity is assumed. Label: required_inference, consistent with access_requirement: none on all surfaces.
• A-2 — Backend owns the model. The generative model itself is external to the application; the application owns the interface, the instruction input, the output well, the history, and the error/recovery states. Label: explicit (planning scope).
• A-3 — No permission differentiation. Because no identity is established, there is no role-based visibility or permission control over shared product state. Label: required_inference from the anonymous access contract.
• A-4 — Parameter rail contents. The collapsible left rail exposes generation parameters; the specific parameter set is not named in the source and is filled by the implementation. Label: [Default — not specified by user].
• A-5 — No future commitments. The source states no roadmap items; nothing beyond video generation, image generation, and question answering is committed. Label: explicit.
• C-1 — No adjacent capabilities. Social features, collaboration, billing, marketplaces, model-training UI, and account management are outside the accepted scope. Label: explicit boundary.
• C-2 — Dark-only, motion-led presentation. The product is dark-mode only and motion-led; a light theme or a static, motion-free presentation is not an accepted variant. Label: explicit (creative direction).

12. Glossary

• Instruction — the text a user submits to the AI describing the video or image they want generated.
• Question — the text a user submits to the AI in the Pergunta mode, expecting a text answer.
• Answer — the AI's text response to a question, rendered as a turn in the thread.
• Generation — one completed act of producing a video or an image from an instruction.
• Output well — the near-black, 20–28px-radius surface with a 1px cyan inner stroke where a generated video or image appears.
• Prompt console — the bottom-anchored pill-shaped input bar shared across all workspaces, carrying the mode tabs (Vídeo / Imagem / Pergunta) and the Generate button.
• Mode — one of the three capabilities selectable from the console: Vídeo, Imagem, or Pergunta.
• Bloom — the submission feedback: the canvas brightens, particles converge toward the output well, and the result fades in from the convergence point.
• Museum wall — the gallery layout of generated media: unevenly-spaced tiles with generous negative space, hairline cyan inner strokes, and monospace metadata captions.
• Thread — the ordered sequence of question/answer turns in the Questions workspace.
• Thinking field — the full-viewport WebGL particle field on the Landing page that reads as the AI thinking.
• Metadata caption — the monospace, muted #8A93A6 caption on a generation carrying model, seed, and duration (or timestamp for answers).