System Requirements Document for multi-bot-ai

1. Introduction

multi-bot-ai is a multi-bot AI SaaS application for building and running always-on agents. A user defines a bot's job, writes its operating instructions, and builds the skills it uses; workflow composition is available as an optional layer, and the plugin feature is the most important feature of the app. Bots are always on: once configured, they keep running their defined jobs without manual intervention.

The audience is developers, operations leads, and automation builders who want a fleet of persistent agents they can shape precisely — job, instructions, skills, optional workflow, and plugins — and then leave running. The product intent is futuristic control: orchestration of many continuous agents, engineered and premium rather than playful or corporate-neutral.

2. System Overview

multi-bot-ai is delivered as a first-party web application with a custom UI and a persistent backend that keeps configured bots running. Two accepted human roles use it: the Bot Builder, who creates and configures bots, and the Bot Operator, who runs and monitors them after configuration.

Current accepted behavior:

• Bots/agents are always on.
• A user can define a bot's job.
• A user can provide instructions for a bot.
• A user can build a bot's skills.
• Workflow configuration for a bot is optional.
• The plugin feature is the most important feature of the app.
• Self-service enrollment and returning verification gate durable bot configuration and always-on operation.
• A persistent backend executes configured bots so they remain always on and run their defined jobs.

Narrow exclusions: workflow configuration is optional and must never be required to create or run a bot. No adjacent capabilities — billing, marketplaces, team administration, analytics suites, or third-party bot distribution — are part of this scope.

2a. Product Interpretation and Delivery Boundary

The application owns its own identity: a new Bot Builder or Bot Operator enrolls through self-service, and a returning user verifies identity before reaching durable bot configuration or always-on operation. The Landing page is anonymously reachable and explains the product before access is established; Sign Up and Login are the anonymous entry boundaries that establish and verify identity. Everything that touches durable bot configuration or live operation — Dashboard, Bots, New Bot, Job Setup, Instructions, Skills, Workflows, Plugins, Operations — sits behind that identity boundary.

Bot execution itself is application-owned backend work: the platform keeps configured bots running continuously against their defined jobs. The human-facing side of that work — configuring, attaching plugins, and monitoring — is first-party UI. No provider-owned or external surface is accepted for any current capability.

Current horizon: everything described in this document. Future horizon: nothing beyond the accepted thread is committed; any later expansion is out of scope for this generation.

2b. Source Content Inventory

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

2c. Page Content and Component Coverage

Landing

• Information/state: Anonymous first impression of the multi-bot AI SaaS app: that bots are always on, that a user defines a bot's job, writes its instructions, builds its skills, optionally composes a workflow, and attaches the most important plugin feature. Headline "Always on. Always yours to define." with micro-label "PLUGINS INCLUDED" and gold capsule CTA "Build your first bot".
• Primary actions: Enter self-service enrollment; enter returning verification.
• Supporting actions: Read the explanation of always-on bots and the plugin feature.
• Domain entities: Bot (conceptual), plugin (conceptual), always-on operation (conceptual).
• Component responsibilities: Full-viewport parametric ribbon stage; oversized display headline in the lower-left third beneath the ribbon's arc; gold capsule CTA; micro-label; curved section boundaries separating explanation sections.
• States: Loading (ribbon composition renders first frame); empty (not applicable — static explanatory content); success (visitor proceeds to Sign Up or Login); error (not applicable); recovery (reduced-motion renders the ribbon as a static composition).

Sign Up

• Information/state: Self-service enrollment form for a new Bot Builder or Bot Operator; no invitation, provisioning, or pre-existing-account boundary exists.
• Primary actions: Submit enrollment to establish identity.
• Supporting actions: Move to Login if already enrolled.
• Domain entities: Account identity for the enrolling human.
• Component responsibilities: Enrollment form; validation messaging; link to Login.
• States: Loading (submission in progress); empty (blank form); success (identity established, routed into the protected app); error (invalid or incomplete submission with inline correction); recovery (retry submission without losing entered values).

Login

• Information/state: Returning verification for continued access to durable bot configurations and always-on operations.
• Primary actions: Submit credentials to verify identity.
• Supporting actions: Move to Sign Up if not yet enrolled.
• Domain entities: Account identity for the returning human.
• Component responsibilities: Verification form; validation messaging; link to Sign Up.
• States: Loading (verification in progress); empty (blank form); success (verified, routed to Dashboard); error (failed verification with retry); recovery (re-enter and resubmit).

Dashboard

• Information/state: Protected summary and routing hub for configured bots, plugin activity, and ongoing operation.
• Primary actions: Route into Bots, New Bot, and Operations.
• Supporting actions: Read the current fleet summary and plugin activity.
• Domain entities: Bot, plugin attachment, always-on status.
• Component responsibilities: Fleet summary surface; plugin activity surface; routing controls; live status indicator pulsing gold on a slow cadence.
• States: Loading (summary fetching); empty (no bots yet, with a route into New Bot); success (fleet and plugin activity shown); error (summary unavailable with retry); recovery (retry restores the summary).

Bots

• Information/state: Revisitable overview of the durable bots managed in the app, arranged along an orbital arc with the selected bot pulled forward into an oversized curved panel while the rest recede in scale and opacity.
• Primary actions: Select a bot to bring it forward; open a bot's configuration destinations.
• Supporting actions: Scan the fleet; read each bot's job and always-on status.
• Domain entities: Bot, job, always-on status.
• Component responsibilities: Orbital arc layout; forward curved panel with asymmetric radius; per-bot status indicator; route into New Bot.
• States: Loading (fleet fetching); empty (no bots, with a route into New Bot); success (fleet arranged and selectable); error (fleet unavailable with retry); recovery (retry restores the arc).

New Bot

• Information/state: Focused creation destination for creating a bot or agent.
• Primary actions: Create the bot.
• Supporting actions: Continue into Job Setup after creation.
• Domain entities: Bot.
• Component responsibilities: Creation form; left vertical curved rail of configuration steps; wide right canvas; validation messaging.
• States: Loading (creation in progress); empty (blank creation form); success (bot created, routed to Job Setup); error (creation failed with inline correction); recovery (retry creation without losing entered values).

Job Setup

• Information/state: Focused configuration destination for defining the job assigned to a created bot.
• Primary actions: Define and save the bot's job.
• Supporting actions: Continue to Instructions.
• Domain entities: Bot, job.
• Component responsibilities: Job definition canvas; left vertical curved rail of steps; save control; validation messaging.
• States: Loading (existing job loading); empty (no job defined yet); success (job saved and reflected on the bot); error (save failed with retry); recovery (retry preserves the drafted job).

Instructions

• Information/state: Focused configuration destination for providing a bot's operating instructions.
• Primary actions: Write and save the bot's instructions.
• Supporting actions: Continue to Skills.
• Domain entities: Bot, instructions.
• Component responsibilities: Instruction authoring canvas; left vertical curved rail of steps; save control; validation messaging.
• States: Loading (existing instructions loading); empty (no instructions written yet); success (instructions saved and bound to the bot); error (save failed with retry); recovery (retry preserves the drafted instructions).

Skills

• Information/state: Focused configuration destination for building the skills a bot uses.
• Primary actions: Build and save skills for the bot.
• Supporting actions: Continue to Workflows (optional) or Plugins.
• Domain entities: Bot, skill.
• Component responsibilities: Skill building canvas; left vertical curved rail of steps; save control; validation messaging.
• States: Loading (existing skills loading); empty (no skills built yet); success (skills saved and available to the bot); error (save failed with retry); recovery (retry preserves the drafted skills).

Workflows

• Information/state: Optional focused configuration destination for composing a bot workflow. Optionality is explicit: a bot is complete and runnable without a workflow.
• Primary actions: Compose and save a workflow for the bot.
• Supporting actions: Skip workflow composition entirely and proceed to Plugins.
• Domain entities: Bot, workflow.
• Component responsibilities: Workflow composition canvas with curved node graphs; left vertical curved rail of steps; save control; explicit skip affordance; validation messaging.
• States: Loading (existing workflow loading); empty (no workflow composed, with the skip path clearly available); success (workflow saved and bound to the bot); error (save failed with retry); recovery (retry preserves the drafted workflow).

Plugins

• Information/state: Focused destination for attaching and using the app's most important plugin feature for a bot. Plugin slots render as luminous gold-cored capsules docked to a curved rail, each with a hairline stroke and a 2s pulse when the plugin is active.
• Primary actions: Attach a plugin to the bot; activate it.
• Supporting actions: Inspect attached plugins and their active state.
• Domain entities: Bot, plugin, plugin attachment, active state.
• Component responsibilities: Curved plugin rail; luminous capsule slots; attach and activate controls; active-state pulse.
• States: Loading (plugin catalog and attachments loading); empty (no plugins attached yet); success (plugin attached and active, pulsing gold); error (attach or activation failed with retry); recovery (retry re-attaches without losing the bot's other configuration).

Operations

• Information/state: Protected monitoring and continuation destination for keeping configured bots always on and running their defined jobs.
• Primary actions: Monitor the always-on state of configured bots; continue operation after an interruption.
• Supporting actions: Inspect which bots are running their defined jobs.
• Domain entities: Bot, always-on status, job execution.
• Component responsibilities: Fleet operation monitor; per-bot running state; continuation controls; live status indicator pulsing gold on a slow cadence.
• States: Loading (operation state fetching); empty (no bots configured to run yet); success (bots shown running their defined jobs); error (operation state unavailable with retry); recovery (retry restores monitoring and continuation).

3. Functional Requirements

FR-1 — Multi-bot AI SaaS app (explicit) As a Bot Builder, I should use a multi-bot AI SaaS application, so that I can manage more than one AI bot in one place.

• Trigger/input: the Bot Builder enters the application.
• Observable result: the application presents the bot fleet and its configuration destinations.
• Access state: protected destinations require established identity.
• Failure/recovery: if the fleet cannot be loaded, the Bot Builder retries.
• Continuation: the Bot Builder proceeds to create or select a bot.

FR-2 — Always-on bots (explicit) As a Bot Operator, I should have bots that are always on, so that their defined jobs keep running without manual intervention.

• Trigger/input: a bot has been configured and is running.
• Observable result: the bot continues operating against its defined job; its live status is visible.
• Access state: protected; requires established identity.
• Failure/recovery: if operation is interrupted, the Bot Operator continues operation from Operations.
• Continuation: the Bot Operator keeps monitoring the running fleet.

FR-3 — Define a bot's job (explicit) As a Bot Builder, I should define a bot's job, so that the bot knows what work it is responsible for.

• Trigger/input: the Bot Builder opens Job Setup for a created bot and enters the job definition.
• Observable result: the job is saved and bound to that bot.
• Access state: protected; requires established identity.
• Failure/recovery: if the save fails, the Bot Builder retries without losing the drafted job.
• Continuation: the Bot Builder proceeds to Instructions.

FR-4 — Provide instructions for a bot (explicit) As a Bot Builder, I should provide instructions for a bot, so that the bot operates the way I intend.

• Trigger/input: the Bot Builder opens Instructions for a bot and writes the operating instructions.
• Observable result: the instructions are saved and bound to that bot.
• Access state: protected; requires established identity.
• Failure/recovery: if the save fails, the Bot Builder retries without losing the drafted instructions.
• Continuation: the Bot Builder proceeds to Skills.

FR-5 — Build a bot's skills (explicit) As a Bot Builder, I should build a bot's skills, so that the bot can perform the capabilities its job requires.

• Trigger/input: the Bot Builder opens Skills for a bot and builds its skills.
• Observable result: the skills are saved and available to that bot.
• Access state: protected; requires established identity.
• Failure/recovery: if the save fails, the Bot Builder retries without losing the drafted skills.
• Continuation: the Bot Builder proceeds to Workflows (optional) or Plugins.

FR-6 — Optional workflow configuration (explicit) As a Bot Builder, I should be able to compose a workflow for a bot as an optional step, so that I can add workflow structure when I want it and skip it when I do not.

• Trigger/input: the Bot Builder opens Workflows for a bot, or deliberately skips it.
• Observable result: a composed workflow is saved and bound to the bot, or the bot remains complete and runnable without one.
• Access state: protected; requires established identity.
• Failure/recovery: if the save fails, the Bot Builder retries without losing the drafted workflow.
• Continuation: the Bot Builder proceeds to Plugins either way.
• Constraint: workflow configuration is optional, not required.

FR-7 — Plugin feature (explicit) As a Bot Builder, I should attach and use plugins for a bot, so that the app's most important feature extends what the bot can do.

• Trigger/input: the Bot Builder opens Plugins for a bot and attaches a plugin.
• Observable result: the plugin is attached to the bot and shows an active state.
• Access state: protected; requires established identity.
• Failure/recovery: if attaching or activating fails, the Bot Builder retries without losing the bot's other configuration.
• Continuation: the Bot Builder returns to the bot or the fleet.
• Constraint: the plugin feature is the most important feature of the app.

FR-8 — Self-service enrollment (required_inference) As a new Bot Builder or Bot Operator, I should enroll myself, so that I can reach durable bot configuration and always-on operation.

• Trigger/input: an unenrolled visitor submits the enrollment form on Sign Up.
• Observable result: identity is established and the user reaches the protected app.
• Access state: anonymous entry; protected state remains unavailable until identity is established.
• Failure/recovery: invalid or incomplete submission is corrected inline and resubmitted.
• Continuation: the user proceeds to Dashboard.

FR-9 — Returning verification (required_inference) As a returning Bot Builder or Bot Operator, I should verify my identity, so that I can resume access to my durable bot configurations and always-on operations.

• Trigger/input: a returning user submits the verification form on Login.
• Observable result: identity is verified and the user reaches the protected app.
• Access state: anonymous entry; protected state remains unavailable until identity is verified.
• Failure/recovery: failed verification is retried.
• Continuation: the user proceeds to Dashboard.

FR-10 — Persistent always-on execution (required_inference) As a Bot Operator, I should rely on persistent backend execution, so that configured bots remain always on and run their defined jobs.

• Trigger/input: a bot has a defined job and is running.
• Observable result: the bot continues executing its defined job; its running state is observable in Operations.
• Access state: backend execution is application-owned; observation requires established identity.
• Failure/recovery: if execution is interrupted, the Bot Operator continues operation from Operations.
• Continuation: the Bot Operator keeps the fleet running.

FR-11 — Fleet overview and selection (required_inference) As a Bot Builder or Bot Operator, I should browse and select from my durable bots, so that I can revisit and work with any bot in the fleet.

• Trigger/input: the user opens Bots.
• Observable result: the fleet is presented and a selected bot is brought forward.
• Access state: protected; requires established identity.
• Failure/recovery: if the fleet cannot be loaded, the user retries.
• Continuation: the user opens a bot's configuration destinations or creates a new bot.

FR-12 — Bot creation (required_inference) As a Bot Builder, I should create a bot or agent, so that I have a durable bot to configure.

• Trigger/input: the Bot Builder submits the creation form on New Bot.
• Observable result: the bot exists and is bound to the Bot Builder's account.
• Access state: protected; requires established identity.
• Failure/recovery: if creation fails, the Bot Builder retries without losing entered values.
• Continuation: the Bot Builder proceeds to Job Setup.

FR-13 — Protected summary and routing (required_inference) As a Bot Builder or Bot Operator, I should see a protected summary of my bots, plugin activity, and ongoing operation, so that I can route to the work that needs me.

• Trigger/input: the user reaches Dashboard after verification.
• Observable result: the summary and routing controls are shown.
• Access state: protected; requires established identity.
• Failure/recovery: if the summary is unavailable, the user retries.
• Continuation: the user routes into Bots, New Bot, or Operations.

FR-14 — Operation monitoring and continuation (required_inference) As a Bot Operator, I should monitor and continue the always-on operation of configured bots, so that they keep working against their assigned jobs.

• Trigger/input: the Bot Operator opens Operations.
• Observable result: each bot's running state against its defined job is visible, and operation can be continued after an interruption.
• Access state: protected; requires established identity.
• Failure/recovery: if operation state is unavailable, the Bot Operator retries.
• Continuation: the Bot Operator keeps monitoring the running fleet.

4. User Personas

Bot Builder

The Bot Builder is the core actor who creates an always-on AI bot/agent in the multi-bot SaaS app. Their work is definitional: they decide what a bot is for and how it behaves. They define the bot's job, write its operating instructions, and build the skills it uses. They may optionally compose the bot's workflow — and may deliberately skip it, because a bot is complete without one. They attach the app's most important feature, plugins, to extend what the bot can do.

• Product context: Works inside the protected app across New Bot, Job Setup, Instructions, Skills, Workflows, and Plugins, with the fleet visible in Bots and Dashboard.
• Primary goal: A configured, always-on bot that performs the defined job.
• Distinct accepted responsibilities: Creating bots; defining jobs; writing instructions; building skills; optionally composing workflows; attaching and activating plugins.
• Relevant inputs or decisions: The job definition, the instruction text, the skills to build, whether to compose a workflow or skip it, and which plugins to attach.
• Interactions with other accepted participants: Hands configured bots to the Bot Operator, who runs and monitors them; shares the fleet view with the Bot Operator.
• Observable success: The bot exists, carries its job, instructions, skills, optional workflow, and attached plugins, and is running.

Bot Operator

The Bot Operator runs and monitors the always-on bots after configuration. Their work is operational rather than definitional: they rely on bots continuing to operate without manual intervention, and their recurring responsibility is keeping the defined bots working against their assigned jobs.

• Product context: Works inside the protected app in Operations, with the fleet visible in Bots and Dashboard.
• Primary goal: Uninterrupted always-on operation of the bots they oversee.
• Distinct accepted responsibilities: Monitoring the running state of configured bots; continuing operation after an interruption.
• Relevant inputs or decisions: Which bots are running, whether a bot is still working against its defined job, and when to continue operation.
• Interactions with other accepted participants: Receives configured bots from the Bot Builder; shares the fleet view with the Bot Builder.
• Observable success: The bots they oversee remain always on and keep running their defined jobs.

5. Core User Flows

Flow A — Bot Builder enrolls and creates a bot

1. The Bot Builder arrives at Landing anonymously and reads that bots are always on and that the user defines the job, instructions, skills, optional workflow, and plugins.
2. The Bot Builder selects the gold capsule CTA "Build your first bot" and reaches Sign Up.
3. The Bot Builder submits the enrollment form. Identity is established and the Bot Builder reaches Dashboard.
4. On Dashboard, the Bot Builder sees the empty fleet state and routes into New Bot.
5. The Bot Builder submits the creation form. The bot is created and bound to the account, and the Bot Builder is routed to Job Setup.
6. If creation fails, the Bot Builder corrects the form and retries without losing entered values.

Flow B — Bot Builder defines the job

1. From New Bot, the Bot Builder lands on Job Setup with the left vertical curved rail of steps visible.
2. The Bot Builder enters the job definition on the wide right canvas and saves it.
3. The job is saved and bound to the bot.
4. If the save fails, the Bot Builder retries and the drafted job is preserved.
5. The Bot Builder continues to Instructions.

Flow C — Bot Builder writes instructions

1. On Instructions, the Bot Builder writes the bot's operating instructions.
2. The Bot Builder saves. The instructions are saved and bound to the bot.
3. If the save fails, the Bot Builder retries and the drafted instructions are preserved.
4. The Bot Builder continues to Skills.

Flow D — Bot Builder builds skills

1. On Skills, the Bot Builder builds the skills the bot uses.
2. The Bot Builder saves. The skills are saved and available to the bot.
3. If the save fails, the Bot Builder retries and the drafted skills are preserved.
4. The Bot Builder continues to Workflows or directly to Plugins.

Flow E — Bot Builder composes an optional workflow

1. On Workflows, the Bot Builder composes a workflow on the curved node canvas.
2. The Bot Builder saves. The workflow is saved and bound to the bot.
3. If the save fails, the Bot Builder retries and the drafted workflow is preserved.
4. The Bot Builder continues to Plugins.
5. Alternatively, the Bot Builder skips workflow composition entirely — the bot remains complete and runnable — and proceeds to Plugins.

Flow F — Bot Builder attaches the plugin feature

1. On Plugins, the Bot Builder sees the curved plugin rail with luminous capsule slots.
2. The Bot Builder attaches a plugin to the bot and activates it.
3. The plugin shows an active state, pulsing gold on the slow cadence.
4. If attaching or activating fails, the Bot Builder retries without losing the bot's other configuration.
5. The Bot Builder returns to the bot or the fleet. The bot is now configured and running.

Flow G — Bot Builder revisits the fleet

1. The Bot Builder opens Bots and sees the fleet arranged along the orbital arc.
2. The Bot Builder selects a bot, which is pulled forward into the oversized curved panel while the rest recede.
3. The Bot Builder opens the bot's configuration destinations to adjust its job, instructions, skills, optional workflow, or plugins.
4. If the fleet cannot be loaded, the Bot Builder retries.

Flow H — Bot Operator monitors always-on operation

1. The Bot Operator verifies identity on Login and reaches Dashboard.
2. The Bot Operator routes into Operations and sees each configured bot's running state against its defined job.
3. The Bot Operator confirms the bots are always on and working their assigned jobs.
4. If operation state is unavailable, the Bot Operator retries and monitoring is restored.

Flow I — Bot Operator continues operation after an interruption

1. On Operations, the Bot Operator observes that a bot's operation has been interrupted.
2. The Bot Operator continues operation for that bot.
3. The bot resumes running its defined job, and its running state is observable again.
4. The Bot Operator returns to monitoring the fleet.

Flow J — Returning user resumes work

1. A returning Bot Builder or Bot Operator reaches Login anonymously.
2. They submit the verification form. Identity is verified and they reach Dashboard.
3. If verification fails, they retry.
4. From Dashboard they route into Bots, New Bot, or Operations and resume their work.

6. Visuals Colors and Theme

Muse: Zaha Hadid. Headline: Fluid parametric grandeur for a fleet of always-on minds.

Color tokens (dark mode)

Deep charcoal-pearl ground with a slightly lifted panel surface for cards and config panels. Text is near-white pearl. Primary is architectural silver for large forms, hairline strokes, and inactive states. A single gold accent marks live/always-on status, active plugin slots, and the primary CTA — used on under 5% of the surface. Muted silver-grey carries metadata and secondary labels. Luminous gradient washes (silver → faint gold) appear only on curved surfaces and the hero ribbon, never as a blob behind text.

Typography

• Headings: Josefin Sans, Light (300) to Regular (400), wide-set with generous letter-spacing. Sentence or lowercase for display; uppercase only for micro-labels and status chips at 11–12px with 0.18em tracking.
• Body: Jost.
• Scale: 1.414 modular, mobile → desktop — display 44 → 112px, h1 32 → 64px, h2 24 → 40px, h3 18 → 24px, body 16 → 17px, micro-label 11px uppercase.
• Line-height: 1.05 for display, 1.6 for body.

Shape language

Continuous sweeping curves as the structural motif. Section boundaries are curved, not straight — a single large arc separates hero from the fleet view. Cards use 24–32px radii on one axis with a subtle asymmetric curve on the opposing corner (border-radius: 32px 8px 32px 8px) so panels feel carved rather than boxed. Buttons are pill or capsule. Hairline 1px strokes in #2A2E38 define panels on the dark ground; no drop shadows — depth comes from layered surfaces and gradient light.

Layout

Asymmetric editorial grid on a 12-column field with a pronounced diagonal flow: content drifts left-to-right down the page on a subtle curve. Hero occupies the full viewport with the headline in the left 7 columns and the parametric ribbon sweeping through the right. Fleet/dashboard views use a curved orbit arrangement — bots along an arc with the active bot pulled forward into a larger curved panel. Config pages (Job, Instructions, Skills, Workflows, Plugins) use a left vertical curved rail of steps and a wide right canvas. Section padding: 96–160px desktop, 48–64px mobile.

Imagery

No stock photography, no 3D clip art. Imagery is generated from the product itself: a parametric ribbon of light built from thin SVG/CSS strokes and gradient fills representing the bot fleet, plus architectural-style line diagrams of workflows (curved node graphs) and plugin slots rendered as luminous capsules. Macro textures of brushed pearl and faint topographical contour lines may appear as background decoration at low opacity.

Avoid: blue/indigo primary or accent (no #2563EB, #4F46E5, #6366F1 family); white or near-white page ground; Inter, Roboto, Poppins, Montserrat, Arial, Helvetica, or system-ui for headings or body; gradient-blob heroes, centred headline + subtext + button stacks, or identical hover-lift card grids; straight-edged section dividers; photographic stock imagery of people or offices; neon cyan/violet/magenta glows; playful bounces, springy easing, or confetti-style micro-interactions.

7. Signature Design Concept

The Landing page is a full-viewport dark pearl stage (#0B0C10). A single enormous parametric ribbon — a stack of 40–60 thin luminous strokes in silver #D8DDE6 with a faint gold #C9A227 core — sweeps from the bottom-left corner across and off the top-right edge, dominating the composition. The headline "Always on. Always yours to define." is set in Josefin Sans Light at 44px mobile → 112px desktop, flush-left in the lower-left third, sitting beneath the ribbon's arc and never overlapped by it. A single gold capsule CTA "Build your first bot" sits directly under the headline with the small uppercase micro-label "PLUGINS INCLUDED". No centred stack, no gradient blob, no blue button.

The ribbon is the product's defining state made visible: many continuous agents sweeping through work in parallel. Every major section below the hero is separated by a large SVG arc rather than a straight rule, so the page reads as one continuous flowing surface. The fleet view carries the same language into the app: bots arranged along an orbital arc with the selected bot pulled forward into an oversized curved panel (border-radius: 32px 8px 32px 8px) while the rest recede in scale and opacity, and plugin slots rendered as luminous gold-cored capsules docked to a curved rail, each with a hairline stroke and a 2s pulse when the plugin is active.

8. Interaction Model & Motion Direction

Interaction Model: Parallax Motion Tempo: cinematic Hero Dimensionality: layered_2d

Landing Hero Motion Brief

• Focal subject: the parametric ribbon of 40–60 thin silver strokes with a faint gold core, sweeping from the bottom-left corner across and off the top-right edge.
• Input → transformation → outcome thesis: as the visitor scrolls, the ribbon layer and the headline layer move at different rates; the ribbon sweeps continuously on a 20–30s loop while the headline holds its position in the lower-left third beneath the arc — the visitor's motion reveals depth between the fleet in motion and the promise that it is always on and always theirs to define.
• Motion vocabulary: continuous slow sweep of the ribbon; scroll-linked parallax between the ribbon layer and the headline; curved section boundaries that morph subtly as you scroll; panels entering with a soft upward drift and 600ms ease-out; live bot status pulsing in gold on a slow 2s cadence.
• Composed first frame: dark pearl stage; the ribbon entering from the bottom-left and exiting the top-right; the headline set flush-left in the lower-left third beneath the ribbon's arc, never overlapped; the gold capsule CTA and the "PLUGINS INCLUDED" micro-label directly beneath it.
• Reduced-motion state: the ribbon holds still as a static composition and all entrances become instant.

9. Non-Functional Requirements

• Always-on execution (explicit): bots must remain running against their defined jobs without manual intervention; the backend executes them persistently. Rationale: "always on" is a core product commitment.
• Optional workflow (explicit): workflow configuration must never be required to create, save, or run a bot. Rationale: the source states workflow configuration is optional.
• Plugin prominence (explicit): the plugin feature is the most important feature of the app and must be treated as such in the product's information architecture and visual emphasis. Rationale: explicit source constraint.
• Identity continuity (required_inference): durable bot configurations and always-on operations must remain bound to the correct account, so protected destinations require established identity. Rationale: durable, account-bound state cannot be safely shared.
• Readable text and controls (explicit): headlines, wordmarks, labels, numbers, cards' 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 creative direction asks, as long as they cover no readable text or control. Moving and scrollable content may cross the viewport or container edge by design and is judged by whether it actually moves or scrolls and whether every item becomes fully readable as it passes; with prefers-reduced-motion it stops and shows whole items, wrapping into rows or sitting in a horizontally scrollable row (overflow-x: auto).
• Reduced motion (explicit): with prefers-reduced-motion, the hero ribbon holds still as a static composition and all entrances become instant.
• Dark-mode-only presentation (explicit): the product is a dark pearl-charcoal system; no white or near-white page ground.

10. Tech Stack

• Frontend: React with a custom UI (no component-library look), implementing the dark pearl-charcoal system, Josefin Sans headings, and Jost body type.
• Backend: Python / FastAPI, providing the persistent execution that keeps configured bots always on and running their defined jobs.
• Storage: appropriate persistent storage for accounts, bots, jobs, instructions, skills, optional workflows, and plugin attachments.
• Containerization: Docker / docker-compose for local and deployment packaging.
• Kubernetes: only if deployment requires it for continuous always-on execution at scale.

11. Assumptions and Constraints

• Assumption (narrow): the application owns its own identity, so self-service enrollment and returning verification are the entry boundaries; no invitation, provisioning, or provider-owned identity boundary is established by the source.
• Assumption (narrow): a bot belongs to the account that created it, and its configuration and operation remain bound to that account.
• Constraint (explicit): workflow configuration for a bot is optional, not required.
• Constraint (explicit): the plugin feature is the most important feature of the app.
• Constraint (explicit): bots/agents are always on.
• Constraint (explicit): the generic indigo/blue-on-white SaaS template is forbidden for this project.
• Constraint (explicit): no stock photography of people or offices; imagery is generated from the product itself.
• Boundary: no billing, marketplace, team administration, analytics suite, or third-party bot distribution is in scope.
• Boundary: nothing beyond the accepted thread is committed for a future horizon.

12. Glossary

• Bot / Agent: an always-on AI worker created in the app, with a defined job, instructions, skills, an optional workflow, and attached plugins.
• Job: the work a bot is responsible for, defined by the Bot Builder in Job Setup.
• Instructions: the operating guidance a Bot Builder writes for a bot.
• Skill: a capability a Bot Builder builds for a bot to perform its job.
• Workflow: an optional composition of steps for a bot; a bot is complete and runnable without one.
• Plugin: the app's most important feature; an attachable extension for a bot, rendered as a luminous gold-cored capsule on a curved rail and pulsing when active.
• Always on: the property that a configured bot keeps running its defined job without manual intervention.
• Fleet: the set of durable bots managed in the app, presented along an orbital arc.
• Bot Builder: the accepted persona who creates and configures bots.
• Bot Operator: the accepted persona who runs and monitors always-on bots after configuration.
• Parametric ribbon: the hero's stack of 40–60 thin luminous silver strokes with a gold core, representing the bot fleet in motion.