System Requirements Document for 8080-ai-platform

1. Introduction

8080-ai-platform is a clone of the public 8080.ai platform: an agentic AI software factory in which a team of AI engineering agents builds, tests, documents, and debugs production-grade software. The product intent is to reproduce the referenced platform's public experience, its core workflows, and its output — not to invent a divergent product. The audience is technical: developers, founders, and operations leads who want production-grade applications built by AI agents and who expect to observe, review, and approve the work as it happens.

The platform's promise, carried verbatim from the source: "A team of AI engineers that build, test, document, and debug production-grade software — so you ship what matters."

2. System Overview

8080-ai-platform is delivered as a first-party web application with an application-owned identity boundary. Anonymous visitors reach the public Landing experience, which explains the platform and routes them into its core workflows. Self-starting users enroll through Sign Up and return through Login. Authenticated Platform Users work inside a protected Workspace that owns the platform's core agentic build workflows and persists project memory across sessions. A restricted Admin surface is owned by the Platform Builder/Operator, who configures and maintains the platform so its behavior and output match 8080.ai.

Current actors are the Platform Visitor (anonymous), the Platform User (authenticated), and the Platform Builder/Operator (authenticated, role-restricted). The platform's AI agents — Tech Lead, System Architect, Project Manager, Frontend, Backend, DevOps, Designer, QA, and the dedicated AI Engineer — are system actors, not human personas; they act on behalf of the Platform User and surface their work for human review.

Narrow exclusions: the clone reproduces only the referenced platform's public experience, stated facts, and workflows. It does not copy 8080.ai private data, credentials, or non-public assets. No adjacent account-management capabilities (password reset flows beyond returning verification, billing self-service beyond the stated pricing display, social features) are introduced beyond what the accepted workflows require.

Full-scope clone intent: the clone must reproduce the same UI interface, user flows, workflows, backend systems, database schema, sandbox, LLM and API layer, AI agents, and AI swarms as 8080.ai. Because 8080.ai's private internals are not publicly documented, the backend systems, database schema, sandbox, LLM/API layer, and agent/swarm runtime are specified from observable public product behavior and must be functionally equivalent to it. The planning agents derive requirements, user flows, architecture, tasks, and designs from this document; build cost is calculated only once tasks exist.

Delivery phasing: the full stack (auth, workspaces, sandboxes, billing, agent runtime) is planned in phases — (1) core platform shell, (2) agent runtime and sandbox, (3) billing and admin. All phases are in the current delivery horizon; phasing orders the work and does not defer or remove any requirement.

2a. Product Interpretation and Delivery Boundary

The product is a working agentic software factory, not a marketing shell. Its public entry (Landing) is anonymously reachable and carries the platform's stated facts, principles, deliverables, trust posture, and pricing. Its protected working surface (Workspace) is where a Platform User initiates builds, watches agents execute in parallel across branches, reviews and approves work through the To Do → AI In Progress → Human In Progress → Review → Done flow, edits code in the browser-based VS Code editor, and receives the platform's deliverables. Its restricted surface (Admin) is where the Platform Builder/Operator maintains platform configuration so behavior and output remain equivalent to 8080.ai.

Identity is application-owned: enrollment is self-service via Sign Up, returning access is via Login, and Admin access is role-restricted and provisioned by the builder/operator rather than self-selected. All current behavior is in the current delivery horizon; no future-horizon capabilities are claimed.

2b. Source Content Inventory

The following facts are preserved from the authoritative content source (8080.ai public experience) and must appear as stated:

• Tagline: "A team of AI engineers that build, test, document, and debug production-grade software — so you ship what matters."
• Scale capabilities: Kubernetes-Native; 100M Token Context; Production architecture from day one; 24+ hours continuous; 0 babysitting needed; ∞ scalability.
• Principles: Opinionated, Not Rigid; Observable by Default; Fail Loudly; Human-First Architecture.
• Deliverables:
  • Complete Codebase: Frontend, backend, database layer, API routes, auth — all wired together and working.
  • Test Suite: Unit and integration tests with 80%+ coverage.
  • Docker & Kubernetes artifacts: Dockerfiles, docker-compose, Helm charts, health checks.
  • Documentation: API docs, README, architecture overview.
  • CI/CD Pipeline: GitHub Actions workflows for build, test, lint, deploy.
• Company background: Built by F(x) Data Labs, Inc, founded in 2016; 10+ years in AI.
• Trust and certifications: ISO 9001, ISO 27001, SOC 2, GDPR-ready, HIPAA-ready.
• Stats: 328,260 Screens generated; 1.310T Tokens processed; 183 Countries served.
• Pricing: Freemium; starting at $4.99/month (flat-cost models).
• Public navigation: Explore, Skill Store, Models, Pricing, About, Log in, Sign up for free; and page sections Home, Public projects, Who it's for, Features, How it works, Humans + AI, Why 8080, Trust, Reviews, Contact.

• Public experience flow: Landing / input prompt → Explore All public projects → trigger one-sentence project creation → series of gate-approval steps: Requirements → User flows → Designs → Architecture & Tasks → Build → Deploy.
• Four-step agent workflow: Describe (user input) → Plan (AI agents decompose the idea into architecture, tasks, milestones) → Build (parallel multi-agent execution: frontend, backend, infra, tests) → Ship (dockerized, tested, documented, production-ready deployment).
• Named AI agents: Tech Lead Agent, Frontend Agent, Backend Agent, System Architect Agent, Designer Agent, Docker Agent, Testing Agents (Unit test, Integration test, Visual testing, Replay), Project Manager Agent, Automatic Retry Agent, Custom Agent.
• Infrastructure capabilities: Kubernetes-native staging and production deployments; Helm charts; Dockerfiles and docker-compose; CI/CD (GitHub Actions workflows); auto-scaling infrastructure; browser-based full VS Code editor; visual testing and replay tools; persistent memory over 100M token context.
• Credit and billing — Free plan: 10 credits on sign-up; top-up cost per credit $0.34; usage components: AI Chat & Planning (0.1 credits/message), Document processing (0.1/page), Design generation (0.8/section), Canvas edits (0.5/edit plus chat cost), Deployments (10 credits), Developer mode (0.1 per 1M input tokens, 0.5 per 1M output tokens), Code editor runtime (0.0001 credits/hour).
• Credit and billing — Paid plans: Standard — $4.49/month, 50 credits/month, 1.5/day daily bonus, $0.34 top-up rate; Plus — $25/month, 350 credits/month, 10.5/day daily bonus, $0.24 top-up rate; Pro — $250/month, 2,500 credits/month, 75/day daily bonus, $0.19 top-up rate, with Auto Scaling and Custom Agent; Enterprise — custom pricing with custom onboarding, security & compliance review, dedicated enterprise support, and custom agents & governance.

• Additional stated claims: 100M Token Context — navigate sprawling codebases without hallucination, more context than any other tool; System Architect Agent designs scalable architecture automatically before code is written; multi-agentic specialization — separate specialized AI agents collaborate (Tech Lead, Frontend, Backend, DevOps, QA, etc.); flat-cost routed attention model makes reading large codebases affordable by reducing quadratic cost; live projects and public project gallery — 5,900+ projects built, 2,800+ public projects with designs.
• Publication dates: Medium article on the System Architect Agent — April 7, 2026; WeekHack launch entry — May 18, 2026; technical deep dive article — February 27, 2026.
• Unverified: internal implementation details and proprietary backend logic are not publicly documented and are therefore not asserted as source facts; they are reproduced functionally from observable behavior.

2c. Page Content and Component Coverage

Landing

• Information/state: Anonymous public entry. Full-bleed hero carrying the eyebrow "F(X) DATA LABS · AGENTIC AI FACTORY", the tagline with "production-grade software" emphasized, and a live data readout of 328,260 screens generated / 1.310T tokens processed / 183 countries served. Below the hero, full-width bands: capability marquee (Kubernetes-Native, 100M Token Context, Production architecture from day one, 24+ hours continuous, 0 babysitting needed, ∞ scalability); three-agent branch diagram (Tech Lead, Architect, QA converging into a pull-request node); Kanban flow strip (To Do → AI In Progress → Human In Progress → Review → Done); deliverables grid; trust/certification row (ISO 9001, ISO 27001, SOC 2, GDPR-ready, HIPAA-ready); stats band; pricing band (Freemium; starting at $4.99/month, flat-cost models); principles; company background; reviews; contact.
• Primary actions: "Sign up for free" (routes to Sign Up); "Explore public projects" (routes to public project exploration); "Log in" (routes to Login).
• Supporting actions: Navigate to Skill Store, Models, Pricing, About, Who it's for, Features, How it works, Humans + AI, Why 8080, Trust, Reviews, Contact sections.
• Domain entities: Platform stats, scale capabilities, principles, deliverables, certifications, pricing tier, public projects.
• Component responsibilities: WebGL particle data sculpture hero (density/hue driven by platform stats); fixed mono readout HUD; capability marquee; agent branch schematic; Kanban flow strip; deliverables grid; trust row; stats band; pricing band; footer.
• States: Loading — hero canvas initializes with a still frame fallback; empty — not applicable (static marketing content); success — all bands render with source facts; error — if the live stats feed is unavailable, the readout shows the last known source values; recovery — retry on next load; reduced-motion — particle field freezes to a still frame and counters show final values.

Login

• Information/state: Anonymous access surface for returning Platform Users and the Platform Builder/Operator. Email and password fields; error region.
• Primary actions: Submit credentials to authenticate; route to Workspace (Platform User) or Admin (Builder/Operator) based on role.
• Supporting actions: Link to Sign Up for new users; link back to Landing.
• Domain entities: User identity, role.
• Component responsibilities: Credential form, validation, error messaging, post-auth routing.
• States: Loading — submit disabled with progress indicator; empty — fields blank with inline guidance; success — redirect to the role-appropriate protected surface; error — invalid credentials message with retry; recovery — re-submit.

Sign Up

• Information/state: Anonymous self-service enrollment for a new Platform User. Fields for account creation; terms acknowledgment.
• Primary actions: Create account and establish an authenticated session; route to Workspace.
• Supporting actions: Link to Login for existing users; link back to Landing.
• Domain entities: User identity, role (default member).
• Component responsibilities: Enrollment form, validation, duplicate-account handling, post-enrollment routing.
• States: Loading — submit disabled with progress; empty — blank form with guidance; success — authenticated session and redirect to Workspace; error — validation or duplicate-email message with retry; recovery — correct and resubmit.

Workspace

• Information/state: Protected, role-restricted working surface for the Platform User. Project list with persistent project memory; per-project Kanban board (To Do → AI In Progress → Human In Progress → Review → Done); agent activity across three parallel branches; architecture artifacts (system requirements document, microservice design, database schemas, API contracts, evolving component diagrams); browser-based VS Code editor with syntax highlighting, IntelliSense, live preview, and integrated terminal; security scan results per task; deployment status for Kubernetes staging/production; deliverables panel.
• Primary actions: Create a project by choosing a build type (Website, SaaS App, Chat, Loop); add tasks to To Do; trigger agent execution; review and approve work at approval gates; merge agent branches via pull request; edit code in the editor; deploy to staging/production; view deliverables.
• Supporting actions: Open the dedicated AI Engineer agent to wire model endpoints, APIs, and data stores; view security scans; view test and QA results; view architecture diagrams; resume a project across sessions.
• Domain entities: Project, task, branch, pull request, agent, architecture artifact, security scan, deployment, deliverable, project memory.
• Component responsibilities: Project list, Kanban board, agent activity view, branch/PR view, code editor, architecture viewer, security scan panel, deployment panel, deliverables panel, AI Engineer panel.
• States: Loading — skeleton for project list and board; empty — no projects yet with a create-project prompt; success — board and artifacts populated; error — agent failure or scan failure surfaced loudly with retry; recovery — retry task, re-run scan, or re-trigger agent; reduced-motion — static board and editor.

Admin

• Information/state: Role-restricted surface for the Platform Builder/Operator. Platform configuration, model gateway settings, org roles (owners, admins, members), compliance controls, and platform health.
• Primary actions: Configure platform behavior to match 8080.ai; manage org roles; review platform health and compliance posture.
• Supporting actions: View audit of platform configuration changes; return to Workspace.
• Domain entities: Platform configuration, model gateway, org, role, compliance control.
• Component responsibilities: Configuration forms, role management, health/compliance panels.
• States: Loading — configuration skeleton; empty — defaults shown; success — saved configuration confirmed; error — validation or save failure with retry; recovery — correct and resubmit.

3. Functional Requirements

FR-1 — Clone the public experience. As a Platform Visitor, I should reach the Landing page anonymously and see the platform's public experience — hero, tagline, scale capabilities, principles, deliverables, trust and certifications, stats, pricing, and navigation — so that I understand what the platform offers before creating an account. (explicit; lifecycle: anonymous entry → Landing renders source facts → visitor chooses Sign up, Log in, or Explore public projects; failure: stats feed unavailable → last known values shown; continuation: route into Sign Up, Login, or public projects.)

FR-2 — Self-service enrollment. As a Platform Visitor, I should sign up for a free account from Landing or Sign Up so that I can reach the protected Workspace. (required_inference; lifecycle: visitor submits enrollment → account created with member role → authenticated session → Workspace; failure: validation or duplicate email → inline error → correct and resubmit; continuation: Workspace.)

FR-3 — Returning verification. As a Platform User or Platform Builder/Operator, I should log in from Login so that I can resume my protected work. (required_inference; lifecycle: submit credentials → authenticated session → role-appropriate surface (Workspace or Admin); failure: invalid credentials → error → retry; continuation: resume prior project or admin configuration.)

FR-4 — Agentic AI factory build types. As a Platform User, I should choose a build type — Website, SaaS App, Chat, or Loop — when creating a project so that the AI factory produces the right kind of software. (explicit; lifecycle: select build type → project created → agents begin architecture-first work; failure: invalid selection → guidance; continuation: project board.)

FR-5 — Architecture-first design. As a Platform User, I should receive a system requirements document, microservice design, database schemas, API contracts, and evolving component diagrams before code is produced so that the build is production-architecture from day one. (explicit; lifecycle: project created → agents produce architecture artifacts → user reviews → approval gate; failure: artifact generation failure → surfaced loudly → retry; continuation: code generation.)

FR-6 — Multi-agent parallel execution. As a Platform User, I should see the multi-agent system — Tech Lead, System Architect, Project Manager, Frontend, Backend, DevOps, Designer, QA — execute in parallel across three branches from architecture to code to deployment so that work proceeds without babysitting. (explicit; lifecycle: architecture approved → agents execute in parallel on three branches → activity visible → branches converge; failure: agent failure → surfaced loudly → retry; continuation: pull request.)

FR-7 — Branch-per-task with PR merging. As a Platform User, I should have each task executed on its own branch and merged by pull request so that changes are reviewable and traceable. (explicit; lifecycle: task assigned → branch created → agent commits → PR opened → user reviews and merges; failure: merge conflict → surfaced → resolve; continuation: merged into project.)

FR-8 — Approval gates and human review. As a Platform User, I should review and approve work at approval gates through the To Do → AI In Progress → Human In Progress → Review → Done flow so that human control is preserved. (explicit; lifecycle: task moves To Do → AI In Progress → Human In Progress → Review → Done with user decisions at gates; failure: rejection → task returns to prior state with feedback; continuation: Done.)

FR-9 — Security scan per task. As a Platform User, I should see a security scan run per task and before staging deployments so that insecure work is caught before it ships. (explicit; lifecycle: task completes → scan runs → results shown → blocking issues halt deployment; failure: scan failure → surfaced loudly → re-run; continuation: deployment or fix.)

FR-10 — Browser-based VS Code editor. As a Platform User, I should edit code in a full browser-based VS Code editor with syntax highlighting, IntelliSense, live preview, and an integrated terminal (or via the 8080 desktop extension) so that I can inspect and adjust agent output directly. (explicit; lifecycle: open editor → edit → live preview → save; failure: editor error → surfaced → reload; continuation: commit or deploy.)

FR-11 — Dedicated AI Engineer agent. As a Platform User, I should use a dedicated AI Engineer agent to wire model endpoints, APIs, and data stores so that integrations are handled by the factory. (explicit; lifecycle: invoke AI Engineer → configure endpoints/APIs/data stores → wired into project; failure: wiring error → surfaced → retry; continuation: build proceeds.)

FR-12 — Multi-model gateway. As a Platform User, I should have my project's model calls routed through a multi-model gateway so that model choice is managed by the platform. (explicit; lifecycle: project uses models → gateway routes → results returned; failure: gateway error → surfaced → retry; continuation: build proceeds.)

FR-13 — Isolated workspaces and Kubernetes namespace per project. As a Platform User, I should have my project run in an isolated workspace with its own Kubernetes namespace so that projects do not interfere. (explicit; lifecycle: project created → namespace provisioned → isolated runtime; failure: provisioning failure → surfaced → retry; continuation: build proceeds.)

FR-14 — Managed backend on Kubernetes with auto-scaling. As a Platform User, I should have my project's backend managed on Kubernetes with auto-scaling so that it scales with demand. (explicit; lifecycle: deploy → managed backend runs → scales; failure: deployment failure → surfaced → retry; continuation: running service.)

FR-15 — Visual testing and continuous QA. As a Platform User, I should have visual testing, continuous QA, and tests run against my project so that quality is verified continuously. (explicit; lifecycle: build → tests run → results shown; failure: test failure → surfaced → fix; continuation: deployment.)

FR-16 — Deployment to Kubernetes staging/production. As a Platform User, I should deploy to Kubernetes staging and production after security scans pass so that my software ships. (explicit; lifecycle: scan passes → deploy to staging → verify → deploy to production; failure: scan or deploy failure → surfaced → retry; continuation: running production service.)

FR-17 — Deliverables. As a Platform User, I should receive the platform's deliverables — complete codebase, test suite with 80%+ coverage, Docker & Kubernetes artifacts, documentation, and CI/CD pipeline — so that I have production-grade output. (explicit; lifecycle: build completes → deliverables assembled → user downloads/views; failure: missing deliverable → surfaced → regenerate; continuation: handoff.)

FR-18 — Persistent project memory. As a Platform User, I should have persistent project memory across sessions so that I can resume work where I left off. (explicit; lifecycle: session ends → memory persisted → return → state restored; failure: memory load failure → surfaced → retry; continuation: resume.)

FR-19 — Org management with roles. As a Platform Builder/Operator, I should manage organizations with roles (owners, admins, members) so that access is controlled. (explicit; lifecycle: open Admin → manage roles → saved; failure: validation → retry; continuation: roles applied.)

FR-20 — Compliance and trust posture. As a Platform Builder/Operator, I should maintain ISO 9001, ISO 27001, SOC 2, GDPR-ready, and HIPAA-ready workspace isolation and compliance controls so that the platform's trust posture matches 8080.ai. (explicit; lifecycle: configure controls → verified → displayed on Landing; failure: control gap → surfaced; continuation: compliance maintained.)

FR-21 — Flat-cost models and pricing. As a Platform Visitor or Platform User, I should see freemium pricing starting at $4.99/month with flat-cost models so that cost is predictable. (explicit; lifecycle: view pricing on Landing → understand tier; continuation: sign up.)

FR-22 — Public projects exploration. As a Platform Visitor, I should explore public projects from Landing so that I can see what the platform produces before signing up. (explicit; lifecycle: click Explore public projects → browse → optionally sign up; continuation: Sign Up.)

FR-23 — Skill Store, Models, About, and supporting sections. As a Platform Visitor, I should navigate to Skill Store, Models, Pricing, About, Who it's for, Features, How it works, Humans + AI, Why 8080, Trust, Reviews, and Contact so that I can learn about the platform. (explicit; lifecycle: navigate → read → continue; continuation: Sign Up or Log in.)

FR-24 — Admin configuration. As a Platform Builder/Operator, I should configure and maintain the platform from Admin so that its behavior and output match 8080.ai. (required_inference; lifecycle: log in → Admin → configure → save → verified; failure: validation → retry; continuation: platform behavior updated.)

4. User Personas

Platform Visitor

The Platform Visitor arrives at the public entry of the cloned 8080.ai-style platform without an account. Their context is evaluation: they want to understand what the platform offers — the agentic AI factory, the multi-agent team, the deliverables, the trust posture, and the pricing — and to reach the platform's primary workflows. Their primary goal is to navigate the public-facing experience to the platform's core entry points without needing an account first. Their distinct responsibilities are reading the Landing experience, exploring public projects, and choosing to sign up or log in. Their inputs are the public content (tagline, scale capabilities, principles, deliverables, certifications, stats, pricing) and navigation. They interact with the Platform User only indirectly (through public projects) and with the platform through Landing. Observable success: they reach Sign Up, Login, or public project exploration from Landing.

Platform User

The Platform User is an authenticated builder who uses the cloned platform's core workflows to accomplish the same tasks the original 8080.ai platform supports, returning across sessions to continue their work. Their context is a protected Workspace with persistent project memory. Their primary goal is completing those workflows with the same output the original platform produces. Their distinct responsibilities are creating projects by build type, reviewing architecture-first artifacts, watching multi-agent parallel execution across three branches, reviewing and approving at gates through the To Do → AI In Progress → Human In Progress → Review → Done flow, merging via pull request, editing in the browser-based VS Code editor, invoking the dedicated AI Engineer agent, reviewing security scans, running visual testing and continuous QA, deploying to Kubernetes staging/production, and receiving deliverables. Their inputs are build-type selection, task definitions, review decisions, code edits, and integration configuration. They interact with the AI agents (system actors acting on their behalf) and with the Platform Builder/Operator through the platform's configuration. Observable success: a deployed project with the platform's deliverables and persistent memory.

Platform Builder/Operator

The Platform Builder/Operator owns the system design and development of the cloned platform, configuring and maintaining it so that its workflows and outputs match the original 8080.ai platform. Their context is the role-restricted Admin surface. Their primary goal is that the delivered system reproduces the original platform's behavior and output. Their distinct responsibilities are configuring platform behavior, managing org roles (owners, admins, members), maintaining compliance controls (ISO 9001, ISO 27001, SOC 2, GDPR-ready, HIPAA-ready), and reviewing platform health. Their inputs are configuration changes and role assignments. They interact with Platform Users through the platform's configuration and with the platform's system actors through the model gateway and infrastructure settings. Observable success: platform behavior and output remain equivalent to 8080.ai.

5. Core User Flows

Flow A — Platform Visitor reaches the platform

1. The Platform Visitor opens the platform and lands on Landing anonymously.
2. Landing renders the hero with the eyebrow "F(X) DATA LABS · AGENTIC AI FACTORY", the tagline, and the live data readout (328,260 screens generated / 1.310T tokens processed / 183 countries served).
3. The visitor scrolls through the capability marquee, three-agent branch diagram, Kanban flow strip, deliverables grid, trust row, stats band, and pricing band.
4. The visitor chooses one of: "Sign up for free" → Sign Up; "Log in" → Login; "Explore public projects" → public project exploration.
5. If the live stats feed is unavailable, the readout shows the last known source values and the visitor continues.
6. Continuation: the visitor proceeds to Sign Up, Login, or public projects.

Flow B — Platform Visitor enrolls and reaches Workspace

1. From Landing, the visitor selects "Sign up for free" and arrives at Sign Up.
2. The visitor enters account details and submits.
3. On validation or duplicate-email error, an inline message appears; the visitor corrects and resubmits.
4. On success, an authenticated session is established with the member role and the visitor is routed to Workspace.
5. Continuation: the new Platform User begins Flow C.

Flow C — Platform User creates a project and receives architecture

1. In Workspace, the Platform User creates a project and selects a build type — Website, SaaS App, Chat, or Loop.
2. The platform provisions an isolated workspace with its own Kubernetes namespace.
3. The multi-agent system (Tech Lead, System Architect, Project Manager, Frontend, Backend, DevOps, Designer, QA) produces architecture-first artifacts: system requirements document, microservice design, database schemas, API contracts, and evolving component diagrams.
4. The Platform User reviews the artifacts at an approval gate.
5. On artifact generation failure, the failure is surfaced loudly and the user retries.
6. Continuation: the user approves and proceeds to Flow D.

Flow D — Platform User runs parallel agent execution and merges via PR

1. From the approved architecture, agents execute in parallel across three branches from architecture to code to deployment.
2. Each task runs on its own branch; the Platform User watches activity in Workspace.
3. A security scan runs per task; results are shown.
4. The Platform User reviews the pull request and merges the branches.
5. On agent failure or merge conflict, the failure is surfaced and the user retries or resolves.
6. Continuation: merged work moves through the Kanban flow.

Flow E — Platform User reviews and approves through the Kanban flow

1. In Workspace, the Platform User sees tasks in To Do.
2. The user moves a task to AI In Progress; agents execute.
3. The task moves to Human In Progress; the user reviews.
4. The task moves to Review; the user approves or rejects.
5. On rejection, the task returns to the prior state with feedback.
6. On approval, the task moves to Done.
7. Continuation: the next task or deployment.

Flow F — Platform User edits code and wires integrations

1. In Workspace, the Platform User opens the browser-based VS Code editor with syntax highlighting, IntelliSense, live preview, and integrated terminal (or the 8080 desktop extension).
2. The user edits code and previews changes live.
3. The user invokes the dedicated AI Engineer agent to wire model endpoints, APIs, and data stores.
4. Model calls route through the multi-model gateway.
5. On editor or wiring error, the failure is surfaced and the user retries.
6. Continuation: commit or deploy.

Flow G — Platform User tests and deploys

1. In Workspace, visual testing, continuous QA, and tests run against the project.
2. On test failure, the failure is surfaced and the user fixes.
3. A security scan runs before staging deployment.
4. On scan pass, the user deploys to Kubernetes staging, verifies, and deploys to production.
5. On scan or deployment failure, the failure is surfaced and the user retries.
6. Continuation: running production service.

Flow H — Platform User receives deliverables and resumes

1. On build completion, Workspace assembles the deliverables: complete codebase, test suite with 80%+ coverage, Docker & Kubernetes artifacts, documentation, and CI/CD pipeline.
2. The Platform User views or downloads the deliverables.
3. On a missing deliverable, the failure is surfaced and the user regenerates.
4. The user ends the session; persistent project memory is saved.
5. On return, the user logs in via Login and Workspace restores state.
6. Continuation: resume work.

Flow I — Platform Builder/Operator configures the platform

1. The Platform Builder/Operator logs in via Login and is routed to Admin based on role.
2. The operator configures platform behavior, model gateway settings, org roles (owners, admins, members), and compliance controls (ISO 9001, ISO 27001, SOC 2, GDPR-ready, HIPAA-ready).
3. On validation or save failure, an error appears and the operator retries.
4. On success, the configuration is confirmed and platform behavior updates.
5. Continuation: the operator returns to Workspace or reviews platform health.

6. Visuals Colors and Theme

Muse: Refik Anadol. Headline: Data made physical — a machine-learning data sculpture for an AI engineering factory.

Mode: Dark.

Color tokens (exact hex by role):

• Background (void): #07080B — dominates ~70%.
• Surface (panels, code inserts, pricing cards): #101319 — ~20%.
• Text: #F2F4F7 — ~18:1 contrast on #07080B.
• Primary (single hot UI accent — CTAs, active states, live counters): #E8FF5A.
• Accent (reserved for "AI In Progress" status and alerts): #FF6A3D.
• Muted (metadata, micro-labels): #8A93A6.
• Particle gradient: acid-lime #E8FF5A → teal #3DE0C8 → hot coral #FF6A3D.

Typography:

• Headings: Space Grotesk, 300–500 weight, tight -0.03em tracking, sentence case.
• Body: Space Grotesk, 17px / 1.6.
• Micro-labels: JetBrains Mono, 11–12px, uppercase, 0.18em letterspacing.
• Scale (1.5 modular): display 96/64/40/28/18/16 with clamp; hero clamp(44px, 7.2vw, 112px); section heads clamp(32px, 4vw, 56px).
• Numerals: tabular in Space Grotesk for all stat counters.

Shape language: Rectilinear and museum-calm; sharp 2px radius on panels; hairline 1px borders at rgba(242,244,247,0.10); no pills except status chips; the only curves are the generative particle flows. Section boundaries are full-bleed black voids separated by single hairline rules.

Spacing rhythm: Asymmetric 12-column grid with 96px gutters at 1280px; single column at 375px with 20px margins; slim fixed top bar with hairline underline.

Imagery style: Generative particle/fluid renders derived from the product's own metrics (1.310T tokens processed, 328,260 screens generated, 183 countries); schematic architecture diagrams as thin luminous strokes on black; code-panel inserts in JetBrains Mono on #101319. No stock photography, no people, no gradient blobs, no device mockups.

7. Signature Design Concept

The public entry is a full-bleed 100vh black void (#07080B) carrying a real-time WebGL particle field — a slow luminous data sculpture in acid-lime, teal, and coral drifting like a fluid topographic cloud, densest at upper right and dissolving toward lower left. Overlaid bottom-left: the eyebrow "F(X) DATA LABS · AGENTIC AI FACTORY" in 12px JetBrains Mono uppercase, then the tagline set in Space Grotesk 300 at clamp(44px, 7.2vw, 112px) with "production-grade software" in acid-lime, and beneath it two text-links: "Sign up for free" (lime, underlined) and "Explore public projects" (white). Bottom-right: a fixed mono readout panel on hairline-ruled black — "328,260 SCREENS GENERATED / 1.310T TOKENS PROCESSED / 183 COUNTRIES SERVED" with tabular numerals. No centred headline, no gradient blob, no blue button — the data sculpture and the oversized left-aligned statement are the whole first screen. The particle density and hue are driven by the platform's real stat numbers, and the field scroll-morphs as the page descends into the capability marquee, three-agent branch diagram, Kanban flow strip, deliverables grid, trust row, stats band, and pricing band.

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 field — a slow luminous data sculpture in acid-lime, teal, and coral, densest at upper right and dissolving toward lower left, driven by the platform's stat numbers (328,260 screens generated, 1.310T tokens processed, 183 countries served).
• Input → transformation → outcome thesis: Cursor movement and scroll subtly perturb the particle field; as the visitor descends, the field scroll-morphs, revealing the capability marquee, agent branch diagram, and Kanban flow strip — the platform's own data becoming the proof of its scale.
• Motion vocabulary: One continuous slow generative particle flow; stat numbers count up once on reveal; section content fades up 12px over 500ms with cubic-bezier(0.16,1,0.3,1); no bounces, no hover-lift cards; hover is a hairline brightening and a lime underline sweep.
• Composed first frame: Full-bleed #07080B void; particle field densest upper right; bottom-left type block with eyebrow, tagline (with "production-grade software" in #E8FF5A), and two text-links; bottom-right fixed mono readout panel with hairline dividers and tabular numerals.
• Reduced-motion state: The particle field freezes to a still frame; counters show final values; section content appears without fade-up.

Landing Hero 3D Scene Brief — DIRECTION-DERIVED

A single crafted real-time particle sculpture: a fluid topographic cloud of ~100k points in acid-lime, teal, and coral, with density and hue driven by the platform's stat numbers, drifting slowly and reacting subtly to cursor and scroll. The scene shows the product's defining state — machine scale made visible — against the #07080B void, with the bottom-right mono readout pinned as a HUD.

9. Non-Functional Requirements

• NFR-1 — Clone fidelity. The product must be a clone of the 8080.ai platform, matching its behavior and output rather than a new or divergent product. (explicit; rationale: hard constraint in the authoritative user evidence.)
• NFR-2 — Kubernetes-native delivery. The platform's managed backend runs on Kubernetes with auto-scaling, an isolated namespace per project, and isolated workspaces. (explicit; rationale: source-stated infrastructure.)
• NFR-3 — Security scans. Security scans run per task and before staging deployments. (explicit; rationale: source-stated control.)
• NFR-4 — Compliance posture. ISO 9001, ISO 27001, SOC 2, GDPR-ready, and HIPAA-ready workspace isolation and compliance controls are maintained. (explicit; rationale: source-stated trust posture.)
• NFR-5 — Persistent project memory. Project memory persists across sessions. (explicit; rationale: source-stated capability.)
• NFR-6 — Scale capabilities. Kubernetes-Native, 100M Token Context, production architecture from day one, 24+ hours continuous, 0 babysitting needed, and ∞ scalability are supported. (explicit; rationale: source-stated scale capabilities.)
• NFR-7 — Principles. Opinionated, Not Rigid; Observable by Default; Fail Loudly; Human-First Architecture. (explicit; rationale: source-stated principles.)
• NFR-8 — Readable text and controls. Headlines, wordmarks, labels, numbers, cards' text, and controls stay entirely inside the viewport and their container at 375px, 768px, and 1280px, wrapping or scaling to fit; no other element covers any part of them. (explicit; rationale: creative direction constraint.)
• NFR-9 — Reduced motion. With prefers-reduced-motion, the particle field freezes to a still frame and counters show final values. (explicit; rationale: creative direction constraint.)

• NFR-10 — No private asset copying. Only the public experience and stated facts are reproduced; no 8080.ai private data, credentials, or non-public assets are copied. (explicit; rationale: creative direction constraint.)

10. Tech Stack

• Frontend: React with a WebGL/R3F hero (particle data sculpture), Space Grotesk and JetBrains Mono fonts, browser-based VS Code editor integration.
• Backend: Python/FastAPI for the platform API, agent orchestration, project memory, and admin configuration.
• Storage: Persistent storage for projects, tasks, branches, pull requests, architecture artifacts, security scans, deployments, deliverables, and project memory.
• Infrastructure: Docker and docker-compose for local development; Kubernetes for managed backend, per-project namespaces, isolated workspaces, and auto-scaling.
• Model access: Multi-model gateway routing model calls.
• CI/CD: GitHub Actions workflows for build, test, lint, deploy.

11. Assumptions and Constraints

• Constraint: The product must be a clone of the 8080.ai platform, matching its behavior and output rather than a new or divergent product. (explicit)
• Assumption: Application-owned identity is required for durable, actor-specific project state and role-restricted Admin access. (required_inference)
• Assumption: Self-service enrollment via Sign Up is the entry path for new Platform Users; Admin access is provisioned by the Platform Builder/Operator rather than self-selected. (required_inference)
• Assumption: The AI agents (Tech Lead, System Architect, Project Manager, Frontend, Backend, DevOps, Designer, QA, AI Engineer) are system actors acting on behalf of the Platform User, not human personas. (required_inference)
• Assumption: The platform's public content (tagline, scale capabilities, principles, deliverables, company background, trust and certifications, stats, pricing) is reproduced as stated from the authoritative content source. (explicit)
• Constraint: No 8080.ai private data, credentials, or non-public assets are copied. (explicit)

12. Glossary

• Agentic AI factory: The platform's core capability — a team of AI engineering agents that build, test, document, and debug production-grade software.
• Build type: The kind of software a project produces — Website, SaaS App, Chat, or Loop.
• Multi-agent system: The set of AI agents — Tech Lead, System Architect, Project Manager, Frontend, Backend, DevOps, Designer, QA — that execute in parallel.
• AI Engineer agent: A dedicated agent that wires model endpoints, APIs, and data stores.
• Branch-per-task: Each task executes on its own branch, merged by pull request.
• Approval gate: A human review control in the To Do → AI In Progress → Human In Progress → Review → Done flow.
• Kanban flow: The five-column task flow — To Do, AI In Progress, Human In Progress, Review, Done.
• Multi-model gateway: The platform component that routes model calls across models.
• Isolated workspace: A per-project runtime isolated from other projects, with its own Kubernetes namespace.
• Project memory: Persistent state that lets a Platform User resume work across sessions.
• Deliverables: The platform's output — complete codebase, test suite with 80%+ coverage, Docker & Kubernetes artifacts, documentation, and CI/CD pipeline.
• Flat-cost models: Predictable pricing starting at $4.99/month under a freemium tier.
• Platform Visitor: An anonymous actor who reaches Landing before identity establishment.

• Platform User: An authenticated actor who uses the Workspace's core workflows.
• Platform Builder/Operator: An authenticated, role-restricted actor who configures and maintains the platform from Admin.