System Requirements Document for ai-agnet-trading

1. Introduction

ai-agnet-trading is a web application in which a self-directed retail trader configures an AI agent that trades on their behalf, and then watches that agent's trading activity unfold inside a Roblox-style animated 3D world. The product's defining, explicitly requested feature is the animation: the agent's trading behaviour is not presented as a spreadsheet or a chart wall, but as a playable low-poly world where a blocky robot-trader avatar walks between market islands, plants a coral flag on each completed trade, and drops coins into an inventory counter as fills arrive.

The audience is the retail trader who is comfortable with — and actively wants — game-like, toy-box systems. The emotional register is discovery and mastery, not sober fintech trust. The animation is the product's soul, so the visual language is a playable 3D world rather than a dashboard skin.

The product intent, derived from the authoritative requirement thread, is threefold:

1. An AI agent that performs trading on behalf of the user.
2. Roblox-style animation that visualizes the agent's activity.
3. A durable, revisitable record of that agent's configuration, trading activity, and results — so the trader can return, verify who they are, and pick up where they left off.

2. System Overview

ai-agnet-trading is delivered as a first-party web application with custom UI, application-owned identity, and background automation. A single accepted human persona — the Trader — enrolls, verifies on return, configures and starts an AI trading agent, watches that agent's activity in a Roblox-style animated world, and reviews the same activity as readable records.

The current delivery shape is:

• Custom UI — all six accepted pages are first-party application surfaces.
• Application-owned identity — the Trader privately owns durable, resumable agent state, so first-use enrollment and returning verification are part of the accepted journey.
• Background automation — the AI agent performs trading on the Trader's behalf and produces activity and results that persist across sessions.

The accepted page contract is closed and ordered: Landing, Sign Up, Login, Configure Agent, Activity, Animation. Landing, Sign Up, and Login are anonymously reachable; Configure Agent, Activity, and Animation require the Trader to be logged in.

2a. Product Interpretation and Delivery Boundary

Delivery ownership. The application owns the entire accepted experience: the public entry, the identity surfaces, the agent configuration workspace, the readable activity record, and the animated world. There is no provider-owned or external-only surface in the accepted contract, and no headless-only delivery. The AI trading agent runs as application-owned background automation; the Trader initiates, configures, and observes it through first-party pages.

Access ownership. Identity is application-owned because the Trader must privately own and resume durable actor-specific state: a configured agent, its trading activity, and its results must remain bound to the correct participant across sessions. First-use identity establishment is self-service enrollment (Sign Up), and returning verification is Login. Both are anonymously reachable entry interactions; the protected destinations (Configure Agent, Activity, Animation) never own the interaction that establishes access to themselves.

Current boundary. Current scope is exactly the six accepted pages and the accepted capabilities: configure and start an AI trading agent; have that agent trade on the Trader's behalf; visualize the agent's activity through Roblox-style animation; and view the agent's trading activity and results as a revisitable record.

Future boundary. No future-horizon requirements were accepted in the authoritative thread. Anything not listed under current scope — additional personas, additional destinations, social or sharing features, multi-agent portfolios, provider integrations, or account-management capabilities beyond enrollment and verification — is out of current scope and is not implemented.

2b. Source Content Inventory

No reference directive in this project declares content_source authority, so no source content inventory is included.

2c. Page Content and Component Coverage

Landing

• Information and state. Anonymous public entry. Presents the product as an AI trading agent whose activity runs live in a playable low-poly world. Split composition: left 45% dark ink-navy column carrying the headline block; right 55% full-bleed Three.js viewport showing the low-poly agent avatar walking between two market islands with floating coral coin props and a soft-shadow ground plane.
• Primary action. Coral capsule CTA "Start your agent" pinned directly beneath the third headline line, routing to Sign Up.
• Supporting actions. A text link to Login for a returning Trader; a one-line mint live-status ticker under the CTA.
• Domain entities. Agent (conceptual), market island, coin prop, live-status signal.
• Component responsibilities.
  • Headline block — Fredoka display type set flush-left in three stacked lines ("YOUR AI AGENT", "TRADES THE MARKET", "LIVE IN A PLAYABLE WORLD"), 48px mobile → 96px desktop via clamp.
  • Primary CTA — coral capsule, routes to Sign Up.
  • Live-status ticker — single mint line under the CTA, static text under reduced motion.
  • Hero 3D viewport — full-bleed low-poly scene, scroll-linked slow orbit, static frame under reduced motion.
• States.
  • Loading — dark ground with the headline block rendered immediately; the 3D viewport shows the ground plane and a soft-shadow placeholder until the scene is ready.
  • Empty — not applicable; the Landing page has no user-owned collection.
  • Success — headline, CTA, ticker, and animated world all render; CTA routes to Sign Up.

• Error — if the 3D scene fails to initialize, the left column remains fully readable and the CTA remains functional; the viewport falls back to a static low-poly frame.
• Recovery — the Trader can still proceed to Sign Up or Login with the scene unavailable.

Sign Up

• Information and state. Anonymous self-service enrollment surface. Establishes the Trader's application-owned identity so a configured agent and its activity can be privately owned and resumed.
• Primary action. Create the Trader's account and enter the application.
• Supporting actions. Navigate to Login for an existing Trader; return to Landing.
• Domain entities. Trader identity, credentials.
• Component responsibilities.
  • Enrollment form — label-above-input pairs on the 8pt grid, dark panel with a 1px lighter rim.
  • Submit control — coral capsule.
  • Cross-link — "Already have an account?" to Login.
• States.
  • Loading — submit control shows a pending state; inputs remain visible.
  • Empty — all fields blank on first arrival.
  • Success — identity established; the Trader is taken into the application to Configure Agent.
  • Error — validation and submission errors render instantly and clearly, with no playful bounce; the form retains entered values.
  • Recovery — the Trader corrects the flagged field and resubmits, or switches to Login.

Login

• Information and state. Anonymous returning-verification surface. Regains access to the Trader's configured agent and its durable activity.
• Primary action. Verify the returning Trader and enter the application.
• Supporting actions. Navigate to Sign Up for a new Trader; return to Landing.
• Domain entities. Trader identity, credentials.
• Component responsibilities.
  • Verification form — label-above-input pairs on the 8pt grid, dark panel with a 1px lighter rim.
  • Submit control — coral capsule.
  • Cross-link — "Need an account?" to Sign Up.
• States.
  • Loading — submit control shows a pending state.
  • Empty — all fields blank on first arrival.
  • Success — verification succeeds; the Trader reaches Configure Agent, Activity, and Animation.
  • Error — failed verification renders instantly and clearly, with no playful bounce; the form retains the entered identifier.
  • Recovery — the Trader retries, or switches to Sign Up.

Configure Agent

• Information and state. Protected workspace for the Trader to configure and start the AI trading agent. Dark panel layout on an 8pt grid: a 2-column form with label-above-input pairs on the left and a live mini-preview of the agent on the right.
• Primary action. Start the AI trading agent with the configured settings.
• Supporting actions. Adjust configuration values; observe the live mini-preview reflecting the current configuration; navigate to Activity and Animation.
• Domain entities. Agent configuration, agent run state, mini-preview scene.
• Component responsibilities.
  • Configuration form — label-above-input pairs, dark panels with 1px lighter rims, chunky 16–24px radii.
  • Start control — coral capsule; the agent/action colour.
  • Live mini-preview — small low-poly scene of the agent reflecting the current configuration.
  • Status chip — HUD-style chip (Fredoka 700, 11px uppercase, +0.08em tracking) showing the agent's current run state.
• States.
  • Loading — the form and mini-preview render with a pending indicator while the saved configuration is retrieved.
  • Empty — no configuration saved yet; the form shows its default field state and the mini-preview shows the idle agent.
  • Success — configuration is saved and the agent starts; the status chip reflects the running agent and the Trader can move to Activity or Animation.
  • Error — invalid or incomplete configuration renders instantly and clearly, with no playful bounce; the form retains entered values.
  • Recovery — the Trader corrects the flagged input and restarts the agent.

Activity

• Information and state. Protected, revisitable view of the agent's trading activity and results, presented as readable text rows. Dark panel layout on an 8pt grid with a live mini-preview of the agent on the right. This page carries the same data as the Animation page in readable form, so motion is never the only way to read the trade log.
• Primary action. Review the agent's trading activity and results.
• Supporting actions. Scan the trade log rows; read result values; observe the live mini-preview; navigate to Configure Agent and Animation.
• Domain entities. Trade event, trade result, timestamp, agent run state.
• Component responsibilities.
  • Trade log — readable text rows with metadata in muted slate and profit/live signals in mint.
  • Result values — HUD-style numerals in Fredoka 700.
  • Live mini-preview — small low-poly scene of the agent reflecting current activity.
  • Status chip — HUD-style chip showing the agent's current run state.
• States.
  • Loading — rows render with a pending indicator while activity is retrieved.
  • Empty — the agent has produced no trades yet; the log shows an explicit empty state and the mini-preview shows the idle agent.
  • Success — trade rows and results render as readable text; the Trader can read the full log without any motion.
  • Error — a retrieval failure renders instantly and clearly with a retry affordance; no playful bounce.
  • Recovery — the Trader retries retrieval; previously loaded rows remain readable.

Animation

• Information and state. Protected, full-bleed 3D viewport in which the Roblox-style animated view of the AI agent's trading activity plays. The animation is the page: the agent avatar physically walks between low-poly market islands and plants a coral flag on each completed trade, so the trade log is the world. A minimal HUD floats over the viewport: a top-left agent status chip, a bottom bar of trade ticker items, and a right-side dock of small stat tiles.
• Primary action. Watch the agent's trading activity as an animated world.
• Supporting actions. Hover a trade marker to pop it up 8px with a spring; hover the ticker to pause it; read the HUD stat tiles; navigate to Configure Agent and Activity.
• Domain entities. Agent avatar, market island, trade marker/flag, coin prop, trade event, stat value.
• Component responsibilities.
  • 3D viewport — full-bleed low-poly world with flat-shaded primitives and soft contact shadows; camera follows the agent as it moves between trades.
  • Agent avatar — blocky robot-trader in coral, walking with a bouncy ease.
  • Trade markers — coral flags planted on completed trades; hover pops the marker 8px with a spring.
  • Coin-drop micro-interaction — on a new fill, a low-poly coin falls from the top of the viewport, squashes on the ground plane, and bounces into the agent's inventory counter, with the counter number rolling up.
  • Status chip — top-left HUD chip, Fredoka 700, 11px uppercase, +0.08em tracking, never covering readable content.
  • Trade ticker — continuous marquee at the bottom of the viewport scrolling real trade events in mint text on the dark ground; pauses on hover.

• Stat tile dock — right-side dock of small stat tiles.
• States.
  • Loading — the viewport shows the ground plane and a soft-shadow placeholder while the world and activity load.
  • Empty — the agent has produced no trades yet; the world renders with the idle agent and the ticker shows no events.
  • Success — the agent walks between islands, plants flags on completed trades, coins drop and settle, and the ticker scrolls real events.
  • Error — if the 3D scene fails, the page falls back to a static low-poly frame and the HUD stat tiles and ticker remain readable; the Trader is directed to Activity for the readable log.
  • Recovery — the Trader can reload the scene or continue reading the same data on Activity.
  • Reduced motion — the 3D scene renders a static frame, the ticker becomes a horizontally scrollable row, and the stat tiles stack in a single column.

3. Functional Requirements

FR-1 — Configure and start an AI trading agent (explicit) As a Trader, I should configure an AI trading agent and start it so that it performs trading on my behalf.

• Trigger/input: The Trader, logged in, opens Configure Agent and supplies the agent's configuration values.
• Observable result: The configuration is saved and the agent starts; the status chip reflects the running agent.
• Access state: Requires login.
• Failure/recovery: Invalid or incomplete configuration renders instantly and clearly with no playful bounce; the form retains entered values and the Trader corrects and restarts.
• Continuation: The Trader moves to Activity to read results or to Animation to watch the agent work.

FR-2 — Agent performs trading on the Trader's behalf (explicit) As a Trader, I should have the AI agent perform trading on my behalf so that trading activity happens without me placing each trade.

• Trigger/input: The agent is running after being started from Configure Agent.
• Observable result: Trade events and their results are produced and persisted as the agent's trading activity.
• Access state: Background automation owned by the application; the Trader observes it through protected pages.
• Failure/recovery: If activity retrieval fails, the affected page renders an instant, clear error with a retry affordance and no playful bounce.
• Continuation: Produced activity feeds both the readable Activity log and the animated Animation world.

FR-3 — Roblox-style animation visualizing the agent's activity (explicit) As a Trader, I should see the agent's activity visualized as Roblox-style animation so that I can understand what the agent is doing as a playable world.

• Trigger/input: The Trader, logged in, opens Animation while the agent has activity.
• Observable result: The agent avatar walks between low-poly market islands and plants a coral flag on each completed trade; a coin drops, squashes, and bounces into the inventory counter with the number rolling up; the ticker scrolls real trade events in mint text.
• Access state: Requires login.
• Failure/recovery: If the 3D scene fails, a static low-poly frame renders and the HUD stat tiles and ticker remain readable; the Trader is directed to Activity for the readable log.
• Continuation: The Trader continues watching, hovers a trade marker to inspect it, or moves to Activity for the readable record.

FR-4 — Review the agent's trading activity and results as readable records (explicit) As a Trader, I should review the agent's trading activity and results as readable text rows so that I can read the trade log without relying on motion.

• Trigger/input: The Trader, logged in, opens Activity.
• Observable result: Trade rows with timestamps, results, and profit/live signals render as readable text; the same data shown in the animation is available here in readable form.
• Access state: Requires login.
• Failure/recovery: A retrieval failure renders instantly and clearly with a retry affordance and no playful bounce; previously loaded rows remain readable.
• Continuation: The Trader returns to Configure Agent to adjust the agent or to Animation to watch it.

FR-5 — Self-service enrollment for the Trader (required_inference) As a Trader, I should be able to enroll myself so that I can privately own and resume my configured agent and its activity.

• Trigger/input: An anonymous visitor on Landing selects "Start your agent" and completes the Sign Up form.
• Observable result: The Trader's application-owned identity is established and the Trader enters the application.
• Access state: Anonymous entry; the protected destinations remain unavailable until identity is established.
• Failure/recovery: Validation and submission errors render instantly and clearly with no playful bounce; entered values are retained and the Trader resubmits or switches to Login.
• Continuation: The Trader proceeds to Configure Agent.

FR-6 — Returning verification for the Trader (required_inference) As a Trader, I should be able to verify myself on return so that I regain access to my configured agent and its durable activity.

• Trigger/input: A returning Trader opens Login and submits their credentials.
• Observable result: Verification succeeds and the Trader regains access to Configure Agent, Activity, and Animation.
• Access state: Anonymous entry; protected state remains unavailable until verification succeeds.
• Failure/recovery: Failed verification renders instantly and clearly with no playful bounce; the entered identifier is retained and the Trader retries or switches to Sign Up.
• Continuation: The Trader resumes at Configure Agent, Activity, or Animation.

FR-7 — Persistent storage of the configured agent and its trading activity and results (required_inference) As a Trader, I should have my configured agent and its trading activity and results persist so that I can leave and return without losing them.

• Trigger/input: The Trader saves a configuration, starts the agent, or the agent produces trade events.
• Observable result: The configuration, activity, and results remain bound to the Trader's identity and are retrievable on a later visit.
• Access state: Bound to the verified Trader's identity; requires login to read.
• Failure/recovery: If retrieval fails, the affected page renders an instant, clear error with a retry affordance and no playful bounce.
• Continuation: The Trader resumes from the persisted state on Configure Agent, Activity, or Animation.

4. User Personas

Trader

Product context. The Trader is a self-directed retail trader who wants an AI agent to trade on their behalf and who is comfortable with — and actively wants — game-like, toy-box systems. They are not looking for a sober fintech dashboard; they chose this product because its defining feature is a Roblox-style animated view of the agent's activity. They work in short, repeat visits: set the agent up, watch it run, come back to read what it did.

Primary goal. A working AI agent that trades on their behalf and shows its activity through the animation, with a durable record they can return to and read.

Distinct accepted responsibilities.

• Enroll themselves and verify on return so their agent and its activity stay privately theirs.
• Configure the AI trading agent and start it.
• Watch the agent's trading activity as a Roblox-style animated world.
• Review the same trading activity and results as readable text rows.

Relevant inputs and decisions. The agent's configuration values on Configure Agent; the decision to start the agent; the decision to inspect a specific trade marker in the animation or read the corresponding row on Activity.

Interactions with other accepted participants. The Trader is the only accepted human persona. The AI trading agent is application-owned background automation that acts on the Trader's behalf and produces the activity the Trader observes; it is not a persona and has no independent goals.

Observable success. The agent is running with the Trader's configuration; the animation shows the agent avatar walking between market islands and planting flags on completed trades; the Activity page shows the same trades as readable rows; and all of it is still there when the Trader returns and verifies.

What makes this role's work different. The Trader's work is split between delegation (configuring and starting an agent that acts without them) and comprehension (understanding what that agent did). The animation is not decoration for this role — it is the primary way they read the agent's behaviour, with the readable Activity log as the parallel, motion-independent record.

5. Core User Flows

Flow A — First-time enrollment and first agent run (Trader)

1. The Trader arrives anonymously on Landing. The left column shows the three-line Fredoka headline and the coral "Start your agent" capsule; the right 55% shows the low-poly agent avatar walking between two market islands with floating coral coins.
2. The Trader selects "Start your agent" and is taken to Sign Up.
3. On Sign Up, the Trader completes the enrollment form and submits. If a field is flagged, the error renders instantly and clearly with no playful bounce, the entered values are retained, and the Trader corrects and resubmits.
4. On success, the Trader's application-owned identity is established and they enter the application at Configure Agent.
5. On Configure Agent, the Trader supplies the agent's configuration values in the 2-column form while the live mini-preview on the right reflects the current configuration.
6. The Trader selects the coral Start control. The configuration is saved, the agent starts, and the status chip reflects the running agent.
7. The Trader continues to Animation to watch the agent work, or to Activity to read results.

Flow B — Returning verification and resuming the agent (Trader)

1. The returning Trader opens Login (from Landing or from the Sign Up cross-link).
2. The Trader submits their credentials. If verification fails, the error renders instantly and clearly with no playful bounce, the entered identifier is retained, and the Trader retries or switches to Sign Up.
3. On success, the Trader regains access to Configure Agent, Activity, and Animation.
4. The Trader resumes at whichever of those pages they need; the previously configured agent and its persisted activity are available.

Flow C — Watching the agent trade in the animated world (Trader)

1. The logged-in Trader opens Animation. The full-bleed 3D viewport loads with the ground plane and a soft-shadow placeholder, then the low-poly world.
2. The agent avatar walks between low-poly market islands with a bouncy ease; the camera follows it as it moves between trades.
3. When a trade completes, the agent plants a coral flag on that market island. The Trader hovers the trade marker and it pops up 8px with a spring.
4. When a new trade fills, a low-poly coin falls from the top of the viewport, squashes on the ground plane, and bounces into the agent's inventory counter, with the counter number rolling up.
5. The bottom-of-viewport trade ticker scrolls real trade events in mint text on the dark ground; the Trader hovers it and it pauses.
6. The Trader reads the top-left status chip and the right-side dock of stat tiles without either covering readable content.
7. If the 3D scene fails, a static low-poly frame renders, the HUD stat tiles and ticker remain readable, and the Trader is directed to Activity for the readable log.
8. Under reduced motion, the scene renders a static frame, the ticker becomes a horizontally scrollable row, and the stat tiles stack in a single column — the Trader can still read every event.
9. The Trader continues watching, or moves to Activity for the readable record.

Flow D — Reading the agent's trading activity and results (Trader)

1. The logged-in Trader opens Activity. Rows render with a pending indicator while activity is retrieved.
2. The Trader reads the trade log as readable text rows: timestamps and metadata in muted slate, profit and live signals in mint, result values as Fredoka 700 numerals.
3. If the agent has produced no trades yet, the log shows an explicit empty state and the mini-preview shows the idle agent.
4. If retrieval fails, an instant, clear error with a retry affordance renders with no playful bounce; previously loaded rows remain readable and the Trader retries.
5. The Trader observes the live mini-preview of the agent on the right, then continues to Configure Agent to adjust the agent or to Animation to watch it.

Flow E — Adjusting and restarting the agent (Trader)

1. The logged-in Trader opens Configure Agent; the saved configuration and the live mini-preview load.
2. The Trader changes configuration values and observes the mini-preview update.
3. The Trader selects Start. If the configuration is invalid or incomplete, the error renders instantly and clearly with no playful bounce, entered values are retained, and the Trader corrects and restarts.
4. On success, the agent restarts with the new configuration and the status chip reflects the running agent.
5. The Trader continues to Activity or Animation to observe the effect.

6. Visuals Colors and Theme

Muse and headline. Bruno Simon — Playable worlds: an AI trading agent you can watch run like a Roblox server. The animation is the page; the visual language is a playable 3D world, not a dashboard skin.

Mode. Dark mode only. No white-first surfaces anywhere; every card is a dark panel with a 1px lighter rim.

Colour tokens (dark mode).

Cream accents account for roughly 2%. No blue or indigo primary in the #0057FF–#7C3AED band on a white or near-white ground; this project is dark-ground with coral and mint only.

Typography.

• Headings: Fredoka — SemiBold at 600–700, slightly negative tracking (-0.01em) for headlines; 700 for HUD numbers. Sentence case for marketing copy; ALL-CAPS only for tiny HUD labels.
• Body: Nunito.
• Scale: 1.25 modular, 1.333 for display. Display 48px mobile → 96px desktop (clamp); h1 32→56; h2 24→36; h3 20→24; body 17→18; HUD label 11→12 uppercase, tracked +0.08em.
• Inter, Roboto, Arial, Helvetica, Open Sans, Lato, Poppins, and system-ui are forbidden for headings and body.

Shape language. Low-poly and toy-like: chunky rounded rectangles (radius 16–24px) for panels, capsule and pill buttons, faceted 3D primitives (cubes, coins, low-poly islands) with flat-shaded faces and soft contact shadows. No glassmorphism, no blur, no gradient blobs. Every shape reads as a physical object you could pick up.

Layout. The animation is the page. The Animation surface is a full-bleed 3D viewport with a minimal HUD: top-left agent status chip, bottom bar of trade ticker items, right-side dock of small stat tiles. Landing uses a split composition: live 3D world on the right 55% edge-to-edge, headline and CTA on the left 45% on the dark ground. Configure Agent and Activity are dark panel layouts on an 8pt grid: 2-column form with label-above-input pairs on the left and a live mini-preview of the agent on the right. No centred hero, no identical card grid.

Imagery. Low-poly 3D only: a small blocky robot-trader agent avatar, market islands as low-poly terrain, floating coin and candlestick props, and a soft-shadow toy lighting setup. Every visual is a buildable Three.js primitive — boxes, cylinders, cones, flat-shaded materials. No stock photography, no abstract gradient blobs, no clip art.

Readable text and controls. Headlines, wordmarks, labels, numbers, card text, and controls stay entirely inside the viewport and their container at 375px, 768px, and 1280px, wrapping or scaling (for example font-size: clamp(...) with its mobile size) to fit, and no other element covers any part of them. Imagery, decoration, and motion may be cropped, bled off an edge, rotated, overlapped, or cut as the direction asks, as long as they cover no readable text or control. Moving and scrollable content (the ticker, horizontally scrollable rows) may cross the viewport or container edge by design; every item becomes fully readable as it passes. Under reduced motion, items wrap into rows or scroll horizontally so each can be brought fully into view.

7. Signature Design Concept

The Landing hero is a game title screen with a live world beside it.

The public entry is a split composition, not a centred hero. The left 45% is a dark ink-navy column carrying a three-line Fredoka display block set flush-left — "YOUR AI AGENT" / "TRADES THE MARKET" / "LIVE IN A PLAYABLE WORLD" — scaling from 48px on mobile to 96px on desktop. Directly beneath the third line sits a coral capsule CTA, "Start your agent", and under that a single mint live-status line. There is no subtext paragraph, no blue button, and no gradient blob.

The right 55% is a full-bleed Three.js viewport: a low-poly agent avatar walking between two market islands, floating coral coin props, and a soft-shadow ground plane. The dominant element is the animated world; the type is the frame around it. As the Trader scrolls, the camera makes a slow scroll-linked orbit around the world, so the page reads as a title screen you can look around inside.

The concept recomposes only accepted content and controls: the headline, the CTA that routes to Sign Up, the Login link, the live-status line, and the animated low-poly world that the Animation page owns at full strength.

8. Interaction Model & Motion Direction

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

Landing Hero Motion Brief

• Focal subject: The low-poly agent avatar — a blocky robot-trader in coral — walking between two market islands on a soft-shadow ground plane, with floating coral coin props.
• Input → transformation → outcome thesis: As the Trader scrolls the Landing page, the camera makes a slow scroll-linked orbit around the low-poly world; the agent avatar continues its bouncy walk between the islands and coins drift and settle. The outcome is that the Trader sees, before enrolling, exactly what the product is: an agent whose trading activity lives in a playable world.
• Motion vocabulary: Cinematic but toy-physical — bouncy ease on the avatar's walk, squash-and-stretch on coins as they pop and settle, soft contact shadows, a slow scroll-linked camera orbit. No motion is required to read any text.
• Composed first frame: Left column fully rendered with the three-line Fredoka headline, coral capsule CTA, and mint live-status line; right viewport showing the agent avatar mid-stride between the two market islands with coins floating above the ground plane.
• Reduced-motion state: The 3D scene renders a single static frame of the same composition; the scroll-linked orbit does not run; the live-status line remains static text; all headline, CTA, and link content stays fully readable and operable.

Landing Hero 3D Scene Brief — DIRECTION-DERIVED

A single crafted real-time scene: a low-poly ground plane with two market islands built from flat-shaded boxes, cylinders, and cones; a blocky robot-trader avatar in coral walking a looping path between them with a bouncy ease; floating coral coin props that drift and settle with squash-and-stretch; a soft-shadow toy lighting setup. The scene shows the product's defining state — an AI agent at work in a playable world — and is built entirely from Three.js primitives with flat-shaded materials. Under reduced motion it renders one static frame of the same composition.

9. Non-Functional Requirements

NFR-1 — Motion is never the only way to read the trade log (explicit) The Activity page must present the same trading data as readable text rows that the Trader can read without any motion. Rationale: the animation is the product's soul, but the trade record must remain accessible.

NFR-2 — Reduced-motion support (explicit) With prefers-reduced-motion, the 3D scene renders a static frame, the trade ticker becomes a horizontally scrollable row, and the stat tiles stack in a single column. Every ticker item must become fully readable as it passes or be brought fully into view by scrolling.

NFR-3 — Readable text and controls stay whole at every viewport (explicit) Headlines, wordmarks, labels, numbers, card text, and controls stay entirely inside the viewport and their container at 375px, 768px, and 1280px, wrapping or scaling to fit. No HUD chip or ticker may overlay readable headline text at any viewport.

NFR-4 — Instant, clear form and destructive feedback (explicit) Form validation errors and destructive actions stay instant and clear; no playful bounce is applied to them.

NFR-5 — Durable, identity-bound persistence (required_inference) The configured agent, its trading activity, and its results persist and remain bound to the Trader's identity across sessions, so a returning Trader resumes the same state. Rationale: required to make the accepted returning-verification and review journeys executable.

NFR-6 — Background automation continuity (required_inference) The AI trading agent runs as application-owned background automation that continues producing activity independently of whether the Trader currently has a page open. Rationale: required for the accepted "agent performs trading on the Trader's behalf" capability to be meaningful.

NFR-7 — Dark-ground contrast (explicit) Cream text (#F4F1EA) carries all readable text at 15:1 on the ink-navy ground (#12141C). Muted slate (#8A8FA3) is reserved for metadata, timestamps, and disabled states.

10. Tech Stack

• Frontend: React (web), with Three.js / React Three Fiber for the low-poly 3D world on Landing and Animation and the live mini-preview on Configure Agent and Activity.
• Backend: Python / FastAPI, providing the application-owned identity endpoints (enrollment and returning verification), agent configuration, agent start, and the trading activity and results read endpoints.
• Storage: A persistent datastore for Trader identity, agent configuration, and the agent's trading activity and results.
• Background automation: An application-owned worker process that runs the AI trading agent and writes trade events and results to storage.
• Packaging: Docker / docker-compose for local and single-host deployment.

Kubernetes is not required by any accepted requirement and is not included.

11. Assumptions and Constraints

• A-1 (assumption) — The AI trading agent's trading logic and any market data it consumes are treated as application-owned background automation; no specific market, broker, exchange, or data provider was named in the authoritative thread, so none is assumed.
• A-2 (assumption) — The Trader is the only accepted human persona; the AI trading agent is application-owned automation, not a persona.
• A-3 (constraint) — The accepted page contract is closed and ordered: Landing, Sign Up, Login, Configure Agent, Activity, Animation. No pages are added, removed, merged, split, renamed, or reordered.
• A-4 (constraint) — Landing, Sign Up, and Login are anonymously reachable; Configure Agent, Activity, and Animation require login.
• A-5 (constraint) — Identity is application-owned and established by self-service enrollment, with returning verification by Login. No adjacent account-management capabilities (password reset, profile editing, social sign-in, role management) are in scope.
• A-6 (constraint) — No differentiated permissions, RBAC, or role-based visibility exists; the Trader owns their own agent and activity, and no shared product state is governed by roles.
• A-7 (constraint) — Dark mode only. No white-first surfaces, no blue or indigo primary in the #0057FF–#7C3AED band on a white or near-white ground, no glassmorphism, no gradient blobs, no stock photography.
• A-8 (constraint) — Fredoka and Nunito are mandatory for headings and body respectively; the forbidden heading/body families are Inter, Roboto, Arial, Helvetica, Open Sans, Lato, Poppins, and system-ui.
• A-9 (constraint) — No future-horizon requirements were accepted; anything beyond the current scope listed in Section 2a is out of scope.

12. Glossary

• Trader — The single accepted human persona: the person who owns the AI trading agent, configures and starts it, watches its activity in the animated world, and reviews its results.
• AI trading agent — The application-owned background automation that performs trading on the Trader's behalf and produces the trading activity and results the Trader observes. Not a persona.
• Agent configuration — The values the Trader supplies on Configure Agent that determine how the agent runs.
• Trade event — A single completed trade produced by the agent, carrying a timestamp, a result, and a profit/live signal.
• Trade marker / flag — The coral flag the agent avatar plants on a market island in the Animation world for each completed trade.
• Market island — A low-poly terrain primitive in the Animation world that the agent avatar walks between.
• Trade ticker — The continuous marquee at the bottom of the Animation viewport that scrolls real trade events in mint text on the dark ground; pauses on hover and becomes a horizontally scrollable row under reduced motion.
• HUD chip — A small floating overlay element (Fredoka 700, 11px uppercase, +0.08em tracking) such as the agent status chip, styled like a game overlay and never covering readable content.
• Coin drop — The micro-interaction in which a low-poly coin falls from the top of the viewport, squashes on the ground plane, and bounces into the agent's inventory counter, with the counter number rolling up.
• Mini-preview — The small live low-poly scene of the agent shown on Configure Agent and Activity.
• Reduced motion — The prefers-reduced-motion state in which the 3D scene renders a static frame, the ticker becomes a horizontally scrollable row, and the stat tiles stack in a single column.