System Requirements Document for discord-v2

1. Introduction

discord-v2 is a Discord-like community communication application: a place where friend groups, fandoms, students and gaming communities gather to talk in real time. The product intent, taken directly from the authoritative requirement thread, is to build an application like Discord whose feature set is at least as complete as Discord's, and whose login flow carries an animation of a Teddy character delivered as a Rive (.riv) file, with that file being one selected from files discovered on a website.

The audience is the everyday social community participant — the person who hangs out in a clubhouse of channels rather than operates an enterprise dashboard. The product therefore treats the community space as a playable world: a night-time playroom where the Teddy bear is the doorman, the server rail is a stack of toy drawers, and the message surface stays fast and legible for long sessions.

This document specifies the current delivery: the public entry, the animated identity access surface, and the community working surfaces (servers, messages, voice & video, server settings, members, moderation), together with the exact Teddy Rive login constraint and the boundaries of what is not being built now.

2. System Overview

discord-v2 is a first-party web application with an application-owned identity layer and custom UI. A visitor arrives anonymously at a public entry surface, learns what the community space is, and moves into a shared identity access surface where the Teddy Rive animation plays. Once identity is established, the person becomes a Community Member inside the clubhouse: a 72px squircle server rail, a 240px channel rail of coloured category drawers, and a message stage. Voice and video open as a right-hand panel of mint-ringed speaking tiles. Community owners and moderators work in the same rail skeleton, but with a left settings navigation instead of channels, to configure servers, channels and roles, invite and manage members, and review and moderate content.

Actors. The accepted active-human catalog is closed and consists of exactly three personas: Community Member, Community Owner / Moderator, and New / Returning User. No other human roles are introduced. The Rive runtime, the media transport for voice/video, and the persistence layer are non-persona system actors.

Accepted behavior. The application must cover Discord-class community functionality: server and channel organization, recurring text messaging, real-time voice and video participation, server configuration of channels and roles, member invitation and management, and moderation of members and messages. The login flow must include an animation, that animation must be a Teddy character in Rive .riv format, and the file must be one selected from files found on a website.

Ownership. All eight surfaces are application-owned custom pages. Identity is application-owned: a new user self-enrolls, a returning user verifies identity, and an invited member accepts an invitation before joining the relevant community. The Rive animation asset is an external content artifact selected from a website and rendered by the application's Rive runtime; the website is a source of the asset, not a product surface.

Narrow exclusions. This document does not add adjacent account-management capabilities (password reset flows, billing, subscription tiers, device management, or profile-marketplace features) beyond the identity establishment and verification needed to make the accepted journeys executable. It does not introduce a second character asset: the Teddy .riv file is the only mascot, used from one state machine. It does not introduce enterprise administration, analytics dashboards, or any destination outside the eight-page contract.

2a. Product Interpretation and Delivery Boundary

Delivery. discord-v2 is delivered as a first-party web application with custom UI and a backend integration layer for identity, community state, message history, and real-time voice/video signaling. The community surfaces are protected: they require an established identity. The public entry and the identity access surface are anonymously reachable, because a protected destination cannot own the interaction that establishes access to itself.

Access ownership. Identity is application-owned. A new user establishes identity on first use; a returning user verifies identity on return; an invited member accepts an invitation before joining the relevant community. Application identity and session continuity establish who you are and let you resume your own community state — they do not establish differentiated permissions by themselves. Differentiated control over shared community state (server configuration, member management, moderation) comes from the community role a person holds within a server, which is accepted behavior owned by the Server Settings, Members and Moderation surfaces.

Current vs. future. Everything specified in Sections 3 through 5 is current. The Teddy Rive login animation, the full Discord-class feature coverage, and the eight-page information architecture are all current commitments. No future-horizon features are claimed in this document; anything not listed in Section 3 is out of current scope.

Asset boundary. The Teddy animation is a Rive .riv file selected from files discovered on a website. The application consumes that file through a Rive runtime and drives it with a single state machine. The application does not author, generate, or substitute a different character asset, and it does not host a Rive marketplace or file browser.

2b. Source Content Inventory

The reference directive for the Teddy Rive animation file declares content_source authority, so the verified source observations are recorded here exactly as verified, including the negative finding.

Verified finding — Teddy Rive (.riv) file search:

• Status: Unverified / not located. A search was performed for a Teddy-themed Rive (.riv) animation file to use as a login animation. No such file was identified hosted publicly under that specific name or character.
• Result: There is no publicly discovered "Teddy.riv" or similar Rive animation matching the description confirmed.
• Consequence for structured content: No structured content_source details (file path, description, file size, preview link) can be provided, because no confirmed Teddy .riv file was located.
• Consequence for visual notes: No legitimate visual_inspiration notes on layout, motion, or style can be derived from observed content, because no actual observed content is available.

Recommendations recorded by the source (non-authoritative guidance, not product scope):

• Look through the Rive community or marketplace for an avatar or character named "Teddy," then use the Preview and Remix features to inspect and export the .riv file (export as runtime .riv). Reference cited: https://www.reddit.com/r/Rive_app/comments/1eznyko
• Alternatively, create a custom Teddy character using Rive tools, or adapt an existing community mascot as a base and modify the character to resemble a Teddy bear. Reference cited: https://github.com/bryllim/kabi-mascot

Binding interpretation. The user's requirement that the login animation be a Teddy character in Rive format, and that one file be selected from files found on a website, remains a current hard constraint. The verified search did not locate such a file. The selection step therefore remains an open, explicitly required action: a Teddy .riv file must be discovered on a website and selected before the login animation can be considered satisfied. No dummy, invented, or substitute asset may be presented as the selected Teddy file, and no unverified file path, size, or preview link may be fabricated.

2c. Page Content and Component Coverage

The page inventory below is the closed, ordered page contract. Each page appears exactly once.

Landing

• Information / state: Anonymous public entry. Explains the Discord-like community application and its chat, voice, and video purpose. No identity required; no protected community state is visible.
• Primary action: Move into the identity access surface ("Open the door").
• Supporting actions: Read the value proposition; scan the community marquee of server names and member counts; follow the secondary path into the identity access surface for returning users.
• Domain entities: Community server (name, member count), channel category, voice/video channel, community role tag.
• Component responsibilities:
  • Full-bleed night-playroom hero scene: low-poly clubhouse island (rounded building, tree, satellite dish, bridge) in flat-shaded coral/mint/lemon/sky, floating over the #141021 ground, off-centre right, slow 24s orbit, soft coral rim light, mint window glow.
  • Left-aligned, bottom-anchored oversized headline "Your people are already in here." in Fredoka at clamp(40px, 9vw, 96px), breaking across three lines into the island's negative space.
  • Single coral pill primary action directly above the marquee.
  • Auto-scrolling horizontal marquee of server-name and member-count chips on surface chips, crossing the viewport edge by design.
  • Channel and role pictograms in the toy palette.
• States:
  • Loading: hero scene initializes; a surface-toned placeholder holds the headline and action so no readable text or control is ever covered.
  • Empty: not applicable — the landing always presents its headline, action, and marquee content.
  • Success: visitor understands the product and enters the identity access surface.
  • Error / recovery: if the WebGL hero scene fails to initialize, the page renders a static flat-shaded composition of the same island in the same palette and layout, with the headline, action, and marquee fully intact and readable.
  • Reduced motion: the island orbit stops; the marquee stops and becomes a horizontally scrollable row (overflow-x: auto) in which every item is fully readable.

Login

• Information / state: Anonymous identity access surface. Shared entry for new users creating identity and returning users verifying identity. Contains the accepted Teddy Rive login animation.
• Primary action: Establish identity (new user) or verify identity (returning user).
• Supporting actions: Accept an invitation carried into this surface; switch between the new-user and returning-user paths.
• Domain entities: Identity credential (email, password), invitation token, session.
• Component responsibilities:
  • Auth card: a 420px chunky rounded panel (20px radius) sitting on the night-playroom ground.
  • Teddy Rive canvas: renders the selected Teddy .riv file through the Rive runtime, 220px tall on desktop and 160px on mobile, always fully inside the panel and never overlapping the inputs. One state machine drives all states.
  • Email field and password field, each with focus behavior wired to the Rive state machine.
  • Primary submit control as a coral pill with a solid 4px darker bottom edge (box-shadow: 0 4px 0 #C2432F) that compresses on press.
  • Invitation acceptance affordance for invited members arriving with an invitation.
• States:
  • Loading: the Rive canvas shows the Teddy idle rest frame while the .riv file loads; inputs remain usable and readable.
  • Empty: fields empty, Teddy in idle breathing.
  • Focus — email: Teddy looks up.
  • Focus — password: Teddy covers its eyes.
  • Success: Teddy celebrates with a hop; the person lands inside the application.
  • Failure: Teddy slumps with a small "hmm" shake; a readable error message appears and the person can retry without losing entered values.
  • Invitation: an invited member accepts the invitation here and proceeds into the relevant community.
  • Reduced motion: the Teddy Rive renders at its idle rest frame with the state machine paused; all state changes are conveyed by readable text and control state instead.

Servers

• Information / state: Signed-in community member's server and channel browsing context. Shows the servers the member belongs to and the channels available within the selected server.
• Primary action: Select a server and enter a channel.
• Supporting actions: Browse and join additional community servers; scroll the server rail; collapse and expand channel categories.
• Domain entities: Server (name, icon, membership), channel category, text channel, voice/video channel, role tag.
• Component responsibilities:
  • 72px vertical squircle server rail: icon-only, scrollable, rounded-square tiles that morph to circles on hover and rotate 6°, with a coral left-edge pill marking the active server.
  • 240px channel rail in surface #221B36 with collapsible category blocks, each carrying a 4px lemon/sky/mint left rule and an uppercase Nunito Sans 700 13px label with +0.08em tracking.
  • Channel entries with thick-line pictograms in the toy palette.
  • Mobile: the server rail becomes a horizontally scrollable squircle strip at the top of the viewport; the channel rail becomes a full-screen list.
• States:
  • Loading: rail and channel skeletons in surface tone; no readable label is covered.
  • Empty: a member with no servers sees an empty-state greeter using the Teddy .riv file from the same state machine, plus a readable prompt to join or create a server.
  • Success: the selected server's channels are listed and a channel can be entered.
  • Error / recovery: if the server list fails to load, a readable retry control appears in place of the rail content.
  • Reduced motion: rail morphs become instant state changes; no rotation or scale animation.

Messages

• Information / state: The recurring text-channel reading and message-sending workspace. Owns message history for the selected text channel.
• Primary action: Send a message to the current text channel.
• Supporting actions: Read message history; scroll back through older messages; read author, timestamp, and role metadata; open the voice/video panel for the current server.
• Domain entities: Message (author, body, timestamp), channel, member, role tag, attachment reference.
• Component responsibilities:
  • Message stage: the primary column, cross-fading on server switch.
  • Message cards at 14px radius on surface #221B36, with message body in Nunito Sans at 15.5px / 1.55 line-height and metadata in muted #9A90B8 at 12.5px.
  • Composer: a pinned pill at the bottom that never leaves the viewport, including at 375px.
  • New-message entrance: 12px rise and 160ms fade, never more.
  • Server-name header at 20px in Fredoka.
• States:
  • Loading: message skeleton rows in surface tone.
  • Empty: an empty channel shows the Teddy .riv greeter from the same state machine plus a readable prompt to start the conversation.
  • Success: the sent message appears in the stage with the 12px rise / 160ms fade and is visible to other members in the channel.
  • Error / recovery: a failed send keeps the composed text in the composer, marks the message as unsent, and offers a readable retry.
  • Reduced motion: new messages appear instantly with no rise or fade.

Voice & Video

• Information / state: Participation state for voice and video channels. Shows who is connected and who is currently speaking.
• Primary action: Join a voice or video channel and participate.
• Supporting actions: Leave the channel; mute and unmute; enable and disable video; drag the panel wider; observe the active speaker.
• Domain entities: Voice/video channel, participant, speaking state, connection state.
• Component responsibilities:
  • Right-hand 320px panel, draggable wider on desktop.
  • Participant tiles as large rounded-square tiles with a mint #7BE0C4 ring that pulses only on the active speaker; the tile scales 1.03 while speaking.
  • Speaking-ring pulse at 1.2s.
  • Grid reflow: 2-up at 375px, 4-up at 1280px.
  • Mobile: the panel becomes a bottom sheet.
• States:
  • Loading: tiles appear in surface tone with connection bars in muted #9A90B8.
  • Empty: a channel with no other participants shows the member's own tile plus a readable "waiting for others" state.
  • Success: the member is connected, hears and is heard, and the active speaker's ring pulses.
  • Error / recovery: if microphone or camera permission is denied or the connection drops, a readable message explains the condition and offers a retry or a listen-only fallback.
  • Reduced motion: speaking rings do not pulse; the active speaker is indicated by a static mint ring and a readable label.

Server Settings

• Information / state: Configuration state for a server the person owns or moderates. Owns server creation and the configuration of channels and roles.
• Primary action: Create a server, or save changes to an existing server's channels and roles.
• Supporting actions: Create, rename, reorder, and remove channels; create and edit roles; assign role tags; navigate between settings sections using a left settings nav.
• Domain entities: Server, channel (name, type, category, order), role (name, colour tag, permissions), category.
• Component responsibilities:
  • Same rail skeleton as the community surfaces, with a left settings nav instead of the channel rail, so the app reads as one world.
  • Channel management list with category grouping.
  • Role management list with lemon/sky/mint tag colours.
  • Coral pill save control with the hard-offset toy button treatment.
• States:
  • Loading: settings sections in surface tone.
  • Empty: a person with no owned server sees a readable prompt to create one.
  • Success: changes are saved and are immediately reflected in the channel rail and role tags.
  • Error / recovery: a failed save preserves the edited values in the form and shows a readable error with retry.
  • Reduced motion: no rail morph animation; state changes are instant.

Members

• Information / state: Membership state for a community. Owns inviting and managing members within a community.
• Primary action: Invite a member to the server.
• Supporting actions: View the member list; assign or change a member's role; remove a member.
• Domain entities: Member, invitation, role assignment, join date.
• Component responsibilities:
  • Member list with avatar pills (999px radius) and role tags.
  • Invitation control producing an invitation that an invited member can accept on the identity access surface.
  • Role assignment control.
• States:
  • Loading: member rows in surface tone.
  • Empty: a server with only its owner shows a readable prompt to invite the first member.
  • Success: the invitation is issued and the invited member appears in the list after accepting; role changes take effect immediately.
  • Error / recovery: a failed invitation or role change shows a readable error and leaves the previous state intact.
  • Reduced motion: no animated transitions.

Moderation

• Information / state: Review state for community members and messages. Owns review and moderation of community members and messages.
• Primary action: Take a moderation action on a reported or selected member or message.
• Supporting actions: Review flagged content; review member behavior history; apply a moderation outcome; reverse a moderation outcome.
• Domain entities: Report, flagged message, flagged member, moderation action, moderation outcome.
• Component responsibilities:
  • Review queue of flagged messages and members.
  • Moderation action controls as coral pills with the hard-offset toy button treatment.
  • Outcome record showing what was applied and to whom.
• States:
  • Loading: queue rows in surface tone.
  • Empty: a queue with nothing to review shows a readable "nothing to review" state.
  • Success: the moderation outcome is applied and recorded, and the affected member or message reflects it.
  • Error / recovery: a failed moderation action shows a readable error and leaves the item in the queue.
  • Reduced motion: no animated transitions.

3. Functional Requirements

Identity and Access

FR-1 — Anonymous public entry (explicit) As a New / Returning User, I should arrive at an anonymously reachable public entry surface that explains the Discord-like community application and its chat, voice, and video purpose, so that I understand what the product is before I identify myself.

• Trigger: the visitor opens the application without an established session.
• Observable result: the Landing surface renders with its headline, primary action, and community marquee; no protected community state is visible.
• Access state: anonymous; no identity required.
• Failure / recovery: if the WebGL hero scene cannot initialize, a static composition of the same island in the same palette and layout renders with all readable text and controls intact.
• Continuation: the visitor proceeds to the identity access surface.

FR-2 — New user self-enrollment (required_inference) As a New / Returning User, I should be able to establish my own identity on first use, so that I can enter protected community functionality.

• Trigger: the visitor chooses the new-user path on the identity access surface.
• Observable result: identity is established and the person lands inside the application.
• Access state: anonymous entry; protected state becomes available only after identity is established.
• Failure / recovery: on failure, a readable error appears, entered values are preserved, and the person can retry.
• Continuation: the person enters the community surfaces as a Community Member.

FR-3 — Returning user identity verification (required_inference) As a New / Returning User, I should be able to verify my identity on return, so that I can resume my community activity.

• Trigger: the returning visitor submits their credentials on the identity access surface.
• Observable result: identity is verified and the person resumes inside the application.
• Access state: anonymous entry; protected state becomes available only after verification.
• Failure / recovery: on failure, a readable error appears, entered values are preserved, and the person can retry.
• Continuation: the person resumes their community surfaces.

FR-4 — Invited member accepts an invitation (required_inference) As a New / Returning User, I should be able to accept an invitation before joining the relevant community, so that I become a member of the server I was invited to.

• Trigger: an invited person arrives with an invitation and accepts it on the identity access surface.
• Observable result: the invitation is accepted and the person joins the relevant community.
• Access state: anonymous entry; the invitation is bound to the correct recipient.
• Failure / recovery: an invalid or expired invitation produces a readable message and the person can still establish identity and proceed.
• Continuation: the person enters the invited server's channels.

FR-5 — Login animation is a Teddy character in Rive format (explicit) As a New / Returning User, I should see a Teddy character animation play during login, delivered as a Rive (.riv) file, so that the login experience is animated as requested.

• Trigger: the identity access surface renders.
• Observable result: the Teddy Rive canvas renders inside the auth panel at 220px tall on desktop and 160px on mobile, never overlapping the inputs.
• Access state: anonymous.
• Failure / recovery: if the .riv file fails to load, the canvas shows a readable fallback state and the inputs remain fully usable.
• Continuation: the animation responds to field focus and to authentication outcome.

FR-6 — Teddy Rive file is selected from files found on a website (explicit) As a New / Returning User, I should have the login animation driven by one Rive file that was selected from files discovered on a website, so that the animation asset requirement is satisfied exactly as specified.

• Trigger: asset provisioning for the login experience.
• Observable result: exactly one Teddy .riv file, discovered on a website, is loaded by the Rive runtime and drives the login animation from a single state machine.
• Access state: not applicable to the visitor; this is an asset-provisioning requirement.
• Failure / recovery: the verified search did not locate a publicly available Teddy .riv file; the selection step therefore remains open and must be completed before this requirement is satisfied. No substitute, invented, or unverified asset may be presented as the selected file.
• Continuation: once selected, the file is used for the login animation and for the other accepted Teddy appearances from the same state machine.

FR-7 — Teddy Rive state machine responds to login interaction (explicit) As a New / Returning User, I should see the Teddy animation react to what I do on the login surface, so that the login feels like a stage rather than a form.

• Trigger: field focus and authentication outcome.
• Observable result: idle breathing at rest; the Teddy looks up when the email field focuses; covers its eyes when the password field focuses; celebrates with a hop when authentication succeeds; slumps with a small "hmm" shake on failure.
• Access state: anonymous.
• Failure / recovery: under reduced motion the Teddy renders at its idle rest frame with the state machine paused, and every state is conveyed by readable text and control state instead.
• Continuation: on success the person lands inside the application.

Community Organization

FR-8 — Browse and join community servers (explicit) As a Community Member, I should be able to browse and join community servers, so that I can take part in the communities I care about.

• Trigger: the member opens the Servers surface.
• Observable result: the member's servers appear in the 72px squircle server rail, and additional servers can be joined.
• Access state: protected; requires an established identity.
• Failure / recovery: if the server list fails to load, a readable retry control appears in place of the rail content.
• Continuation: the member selects a server and enters a channel.

FR-9 — Enter a channel within a server (explicit) As a Community Member, I should be able to select a server and enter one of its channels, so that I reach the conversation I want.

• Trigger: the member selects a server tile and then a channel.
• Observable result: the channel rail slides in with a 180ms spring and the message stage cross-fades to the selected channel.
• Access state: protected; requires an established identity and membership in the server.
• Failure / recovery: if the channel cannot be opened, a readable message appears and the member can select another channel.
• Continuation: the member reads and sends messages, or joins voice/video.

FR-10 — Channel categories read as stacked drawers (explicit) As a Community Member, I should see channel categories as collapsible blocks with a coloured left rule and uppercase labels, so that the sidebar stays scannable under a playful surface.

• Trigger: the member views the channel rail.
• Observable result: categories render as collapsible blocks with a 4px lemon/sky/mint left rule and uppercase Nunito Sans 700 13px labels with +0.08em tracking.
• Access state: protected.
• Failure / recovery: if category data is unavailable, channels render in a single ungrouped list with readable labels.
• Continuation: the member collapses or expands categories and selects a channel.

Text Communication

FR-11 — Read text-channel message history (explicit) As a Community Member, I should be able to read the message history of a text channel, so that I can follow the conversation.

• Trigger: the member enters a text channel.
• Observable result: message cards render at 14px radius on surface #221B36, with body text in Nunito Sans at 15.5px / 1.55 line-height and metadata in muted #9A90B8 at 12.5px.
• Access state: protected.
• Failure / recovery: if history fails to load, a readable error with retry appears in the message stage.
• Continuation: the member scrolls back through older messages or sends a message.

FR-12 — Send a message to a text channel (explicit) As a Community Member, I should be able to send a message to the current text channel, so that I participate in the conversation.

• Trigger: the member composes text in the pinned composer pill and submits.
• Observable result: the message appears in the stage with a 12px rise and 160ms fade, and is visible to other members in the channel.
• Access state: protected.
• Failure / recovery: a failed send keeps the composed text in the composer, marks the message as unsent, and offers a readable retry.
• Continuation: the member continues the conversation.
• Reduced motion: the message appears instantly with no rise or fade.

FR-13 — Composer stays reachable at every viewport (explicit) As a Community Member, I should have the message composer pinned at the bottom of the viewport, so that I can always write without hunting for the input.

• Trigger: the member views a text channel at any viewport width.
• Observable result: the composer pill remains pinned at the bottom and never leaves the viewport, including at 375px.
• Access state: protected.
• Failure / recovery: not applicable; the composer is always present in a text channel.
• Continuation: the member sends a message.

Voice and Video

FR-14 — Join a voice or video channel (explicit) As a Community Member, I should be able to join a voice or video channel and participate, so that I can talk with my community in real time.

• Trigger: the member selects a voice/video channel.
• Observable result: the right-hand 320px panel opens (bottom sheet on mobile), the member's tile appears, and the grid reflows from 2-up at 375px to 4-up at 1280px.
• Access state: protected.
• Failure / recovery: if microphone or camera permission is denied or the connection drops, a readable message explains the condition and offers a retry or a listen-only fallback.
• Continuation: the member speaks, listens, or leaves the channel.

FR-15 — Active speaker is visibly indicated (explicit) As a Community Member, I should see who is currently speaking, so that I can follow the conversation.

• Trigger: a participant speaks in the voice/video channel.
• Observable result: that participant's tile shows a mint #7BE0C4 ring that pulses at 1.2s and the tile scales 1.03 while speaking.
• Access state: protected.
• Failure / recovery: under reduced motion the ring does not pulse; the active speaker is indicated by a static mint ring and a readable label.
• Continuation: the member responds or continues listening.

FR-16 — Voice/video panel is resizable and adapts (explicit) As a Community Member, I should be able to drag the voice/video panel wider on desktop, so that I can see more participants at once.

• Trigger: the member drags the panel edge.
• Observable result: the panel widens beyond its 320px default; at 768px it becomes a bottom sheet.
• Access state: protected.
• Failure / recovery: if the drag is not supported, the panel keeps its default width and remains fully usable.
• Continuation: the member continues participating.

Server Configuration

FR-17 — Create a server (explicit) As a Community Owner / Moderator, I should be able to create a server, so that I have a community space to run.

• Trigger: the owner opens the Server Settings surface with no owned server.
• Observable result: a new server is created and appears in the server rail.
• Access state: protected; requires an established identity.
• Failure / recovery: a failed creation shows a readable error and preserves the entered values.
• Continuation: the owner configures channels and roles.

FR-18 — Configure channels (explicit) As a Community Owner / Moderator, I should be able to create, rename, reorder, and remove channels and categories, so that the server is organized the way my community needs.

• Trigger: the owner works in the channel management section of Server Settings.
• Observable result: changes are saved and immediately reflected in the channel rail.
• Access state: protected; requires ownership or moderation control over the server.
• Failure / recovery: a failed save preserves the edited values in the form and shows a readable error with retry.
• Continuation: the owner continues configuring or returns to the community surfaces.

FR-19 — Configure roles (explicit) As a Community Owner / Moderator, I should be able to create and edit roles and assign role tags, so that members have the standing and access my community intends.

• Trigger: the owner works in the role management section of Server Settings.
• Observable result: roles are saved with their lemon/sky/mint tag colours and take effect for assigned members.
• Access state: protected; requires ownership or moderation control over the server.
• Failure / recovery: a failed save preserves the edited values and shows a readable error with retry.
• Continuation: the owner assigns roles to members on the Members surface.

FR-20 — Settings reuse the same rail skeleton (explicit) As a Community Owner / Moderator, I should navigate Server Settings, Members and Moderation through the same rail skeleton with a left settings nav instead of channels, so that the app feels like one world.

• Trigger: the owner opens any of the three administrative surfaces.
• Observable result: the rail skeleton is preserved and a left settings nav replaces the channel rail.
• Access state: protected.
• Failure / recovery: if the settings nav fails to render, the sections remain reachable through readable links.
• Continuation: the owner moves between settings sections.

Membership Management

FR-21 — Invite a member to a server (explicit) As a Community Owner / Moderator, I should be able to invite a member to my server, so that my community grows.

• Trigger: the owner issues an invitation from the Members surface.
• Observable result: an invitation is produced that an invited person can accept on the identity access surface, and the invited member appears in the member list after accepting.
• Access state: protected; requires ownership or moderation control over the server.
• Failure / recovery: a failed invitation shows a readable error and leaves the previous state intact.
• Continuation: the owner manages the member once they join.

FR-22 — Manage members and their roles (explicit) As a Community Owner / Moderator, I should be able to view the member list, assign or change a member's role, and remove a member, so that membership stays correct.

• Trigger: the owner works in the Members surface.
• Observable result: role changes take effect immediately and removals update the member list.
• Access state: protected; requires ownership or moderation control over the server.
• Failure / recovery: a failed role change or removal shows a readable error and leaves the previous state intact.
• Continuation: the owner continues managing membership or moves to moderation.

Moderation

FR-23 — Review flagged members and messages (explicit) As a Community Owner / Moderator, I should be able to review flagged community members and messages, so that I can judge what needs action.

• Trigger: the owner opens the Moderation surface.
• Observable result: a review queue of flagged messages and members renders with readable context.
• Access state: protected; requires ownership or moderation control over the server.
• Failure / recovery: if the queue fails to load, a readable error with retry appears.
• Continuation: the owner applies a moderation outcome.

FR-24 — Apply and reverse moderation outcomes (explicit) As a Community Owner / Moderator, I should be able to apply a moderation action to a member or message and reverse it if needed, so that I can enforce my community's rules.

• Trigger: the owner selects a moderation action on a queued item.
• Observable result: the outcome is applied and recorded, and the affected member or message reflects it.
• Access state: protected; requires ownership or moderation control over the server.
• Failure / recovery: a failed moderation action shows a readable error and leaves the item in the queue.
• Continuation: the owner continues reviewing or returns to the community surfaces.

Cross-Cutting

FR-25 — Readable text and controls stay whole at every viewport (explicit) As any accepted persona, I should have headlines, wordmarks, labels, numbers, card text and controls stay entirely inside the viewport and their container at 375px, 768px and 1280px, so that nothing I need to read or press is ever cut off or covered.

• Trigger: any surface is viewed at any supported viewport width.
• Observable result: readable text and controls wrap or scale to fit and are never covered by another element; imagery, decoration and motion may be cropped, bled, rotated, overlapped or cut as the creative direction asks, as long as they cover no readable text or control.
• Access state: applies to anonymous and protected surfaces alike.
• Failure / recovery: not applicable; this is a standing constraint.
• Continuation: moving and scrollable content may cross the viewport or container edge by design, and every item becomes fully readable as it passes.

FR-26 — Reduced-motion support (explicit) As any accepted persona, I should have motion reduced when I prefer reduced motion, so that the app stays usable and comfortable.

• Trigger: the person's system requests reduced motion.
• Observable result: the island orbit stops; rail morphs become instant state changes; the Teddy Rive renders at its idle rest frame with the state machine paused; the landing marquee stops and becomes a horizontally scrollable row in which every item is fully readable.
• Access state: applies to anonymous and protected surfaces alike.
• Failure / recovery: not applicable; this is a standing constraint.
• Continuation: all functionality remains reachable without motion.

4. User Personas

Community Member

Product context. The Community Member is the everyday participant in a Discord-like chat application. They arrive already identified and spend long, frequent sessions inside the clubhouse: reading channels, sending messages, and dropping into voice or video with the people they hang out with. Their relationship to the product is habitual and social rather than task-driven — they are not "completing a workflow," they are hanging out.

Primary goal. Stay connected with their communities and reach the outcome of active, real-time participation in text and voice channels.

Distinct accepted responsibilities. The Community Member browses and joins community servers, selects a server and enters its channels, reads text-channel history, sends messages, joins voice and video channels, and follows who is speaking. They also accept an invitation when they are invited into a community they do not yet belong to. Their work is characterized by recurring, high-frequency, low-ceremony interaction: the composer must always be reachable, new messages must appear without fanfare, and the sidebar must stay scannable under a playful surface.

Relevant inputs and decisions. They decide which server to enter, which channel to open, what to write, and whether to join voice or video. They read author, timestamp, and role metadata to understand who is speaking and with what standing.

Interactions with other accepted participants. The Community Member is the counterparty of the Community Owner / Moderator: they receive invitations, are assigned roles, and are subject to moderation outcomes. Their messages and their voice/video presence are what the moderator reviews. They share the identity access surface with the New / Returning User, since every member was once one.

Observable success. Their message appears in the channel and is seen by others; their tile appears in the voice/video grid and their speaking ring pulses when they talk; they can move between servers and channels without losing their place.

Community Owner / Moderator

Product context. The Community Owner / Moderator creates and runs a server or community space. They are the same kind of person as a Community Member but with a different working context: instead of the channel rail, they work through a left settings navigation in the same rail skeleton, configuring the space and enforcing its rules.

Primary goal. A healthy, well-organized community, achieved by configuring the space and enforcing rules over members and messages.

Distinct accepted responsibilities. They create a server; create, rename, reorder, and remove channels and categories; create and edit roles and assign role tags; invite members; view the member list, assign or change roles, and remove members; review flagged members and messages; and apply or reverse moderation outcomes. Their work is deliberate and structural rather than conversational: it changes the shape of the community rather than participating in it, and its results are immediately visible to every member.

Relevant inputs and decisions. They decide the channel structure, the role structure and its tag colours, who to invite, which role a member should hold, and what moderation outcome a flagged item deserves. They read the member list and the review queue as their working state.

Interactions with other accepted participants. The Community Owner / Moderator acts on Community Members: they invite them, assign their roles, remove them, and moderate their messages and behavior. Their configuration work is what the Community Member experiences as the channel rail and role tags. They share the identity access surface with the New / Returning User.

Observable success. Saved channel and role changes appear immediately in the channel rail and role tags; an invited member appears in the member list after accepting; a moderation outcome is applied, recorded, and reflected on the affected member or message.

New / Returning User

Product context. A person arriving at the app who must sign in or create an account before reaching any community content. They meet the product at its most theatrical moment: the login stage, where the Teddy bear is the doorman.

Primary goal. Authenticate and enter the app, with the successful outcome of landing inside the application after the animated Teddy (Rive) login experience completes.

Distinct accepted responsibilities. They establish identity on first use, verify identity on return, and accept an invitation when they arrive as an invited member. They are the only persona who interacts with the anonymous public entry and the identity access surface, and the only persona who sees the Teddy Rive animation in its full state machine.

Relevant inputs and decisions. They enter an email and a password, choose between the new-user and returning-user paths, and decide whether to accept an invitation. Their focus on the email field and on the password field is itself an input: it drives the Teddy's behavior.

Interactions with other accepted participants. They are the entry point for both other personas — every Community Member and every Community Owner / Moderator passes through this role first. An invited member's acceptance is initiated by a Community Owner / Moderator's invitation, so this role is the receiving counterparty of the invitation capability.

Observable success. The Teddy celebrates with a hop and the person lands inside the application; on failure the Teddy slumps with a small "hmm" shake and a readable error lets them retry without losing what they typed.

5. Core User Flows

Flow 1 — A new user arrives, enrolls, and enters the clubhouse

1. Starting context: A person with no established session opens discord-v2.
2. Landing (anonymous): The Landing surface renders the full-bleed night-playroom scene — the low-poly clubhouse island floating off-centre right over the #141021 ground, slowly orbiting on a 24s loop, with a soft coral rim light and mint window glow. The headline "Your people are already in here." sits left-aligned and bottom-anchored in Fredoka at clamp(40px, 9vw, 96px), breaking across three lines into the island's negative space.
3. Reading the community: Beneath the headline, a single coral pill sits directly above an auto-scrolling marquee of server-name and member-count chips that crosses the viewport edge by design. The visitor reads real-looking community names and member counts.
4. Decision: The visitor presses the coral pill. The button squashes to 0.96 and springs back over 220ms.
5. Handoff to identity access: The Login surface opens. The auth card is a 420px chunky rounded panel on the night-playroom ground, with the Teddy Rive canvas 220px tall (160px on mobile) fully inside the panel and never overlapping the inputs.
6. Teddy at rest: The Teddy plays its idle breathing from the single state machine.
7. Actor action — email: The visitor focuses the email field. The Teddy looks up.
8. Actor action — password: The visitor focuses the password field. The Teddy covers its eyes.
9. Commitment: The visitor submits the new-user path. The coral submit pill compresses on press.
10. Observable result — success: The Teddy celebrates with a hop, and the person lands inside the application as a Community Member.
11. Failure and recovery: If enrollment fails, the Teddy slumps with a small "hmm" shake, a readable error appears, the entered values are preserved, and the visitor can retry from step 9.
12. Continuation: The person arrives on the Servers surface with the 72px squircle server rail and the 240px channel rail of coloured category drawers.

Flow 2 — A returning user verifies identity and resumes

1. Starting context: A person who has previously established identity opens discord-v2 without an active session.
2. Landing (anonymous): The Landing surface renders as in Flow 1, steps 2–3.
3. Handoff to identity access: The returning visitor moves to the Login surface and takes the returning-user path.
4. Actor action: They enter their credentials. Focusing the email field makes the Teddy look up; focusing the password field makes the Teddy cover its eyes.
5. Commitment: They submit.
6. Observable result — success: The Teddy celebrates with a hop and the person resumes inside the application, returning to their community surfaces.
7. Failure and recovery: On failure the Teddy slumps with a small "hmm" shake, a readable error appears, entered values are preserved, and they can retry from step 5.
8. Continuation: They return to the Servers surface and re-enter the channel they were last in.

Flow 3 — An invited member accepts an invitation and joins the community

1. Starting context: A Community Owner / Moderator has issued an invitation (Flow 6, steps 5–6). The invited person arrives at discord-v2 with that invitation.
2. Landing (anonymous): The Landing surface renders as in Flow 1, steps 2–3.
3. Handoff to identity access: The invited person moves to the Login surface. The invitation is bound to the correct recipient.
4. Actor action: They accept the invitation on the identity access surface. If they do not yet have identity, they establish it in the same surface; if they do, they verify it.
5. Observable result: The invitation is accepted and the person joins the relevant community. The Teddy appears in the invite-accepted confirmation, rendered from the same .riv file and state machine.
6. Failure and recovery: If the invitation is invalid or expired, a readable message explains the condition and the person can still establish identity and proceed.
7. Continuation: The person enters the invited server's channels as a Community Member.

Flow 4 — A Community Member reads and sends messages

1. Starting context: An identified Community Member is inside the application.
2. Server selection: On the Servers surface, they select a server tile in the 72px squircle rail. The tile morphs from rounded-square to circle on hover and rotates 6°; the coral left-edge pill marks the active server. The channel rail slides in from the left with a 180ms spring and the message stage cross-fades.
3. Channel selection: They expand a channel category — a collapsible block with a 4px lemon/sky/mint left rule and an uppercase Nunito Sans 700 13px label with +0.08em tracking — and select a text channel.
4. Reading: The Messages surface renders the channel's history as message cards at 14px radius on surface #221B36, with body text in Nunito Sans at 15.5px / 1.55 line-height and metadata in muted #9A90B8 at 12.5px. They scroll back through older messages.
5. Actor action — compose: They write in the composer pill, which is pinned at the bottom of the viewport and never leaves it, including at 375px.
6. Commitment: They submit the message.
7. Observable result: The message appears in the stage with a 12px rise and 160ms fade — never more — and is visible to other members in the channel.
8. Failure and recovery: If the send fails, the composed text stays in the composer, the message is marked unsent, and a readable retry is offered.
9. Continuation: They continue the conversation, or open the voice/video panel for the current server.

Flow 5 — A Community Member joins voice and follows the speaker

1. Starting context: An identified Community Member is inside a server.
2. Actor action: On the Voice & Video surface, they select a voice or video channel.
3. Observable result — connection: The right-hand 320px panel opens (a bottom sheet at 768px and below), their tile appears, and the grid reflows from 2-up at 375px to 4-up at 1280px.
4. Participant response: Another member speaks. That member's tile shows a mint #7BE0C4 ring that pulses at 1.2s and the tile scales 1.03 while speaking.
5. Actor action: The member speaks, listens, mutes or unmutes, enables or disables video, or drags the panel wider on desktop.
6. Failure and recovery: If microphone or camera permission is denied or the connection drops, a readable message explains the condition and offers a retry or a listen-only fallback.
7. Continuation: They leave the channel and return to the message stage, or stay and keep participating.

Flow 6 — A Community Owner creates a server, configures it, and invites members

1. Starting context: An identified person who owns or moderates a community opens the Server Settings surface, which reuses the same rail skeleton with a left settings nav instead of the channel rail.
2. Actor action — create: With no owned server, they create one. The new server appears in the server rail.
3. Actor action — channels: They create, rename, reorder, and remove channels and categories. They save with the coral pill control, which carries the hard-offset toy button treatment (box-shadow: 0 4px 0 #C2432F) and compresses on press.
4. Observable result — channels: The saved changes are immediately reflected in the channel rail.
5. Actor action — roles: They create and edit roles and assign role tags in lemon/sky/mint. They save.
6. Observable result — roles: The roles take effect for assigned members and their tags appear in the member list.
7. Actor action — invite: On the Members surface, they issue an invitation. The member list shows avatar pills at 999px radius with role tags.
8. Participant response: The invited person accepts the invitation (Flow 3) and appears in the member list.
9. Actor action — manage: They assign or change a member's role, or remove a member. Role changes take effect immediately.
10. Failure and recovery: A failed save preserves the edited values in the form and shows a readable error with retry; a failed invitation or role change shows a readable error and leaves the previous state intact.
11. Continuation: They move to the Moderation surface, or return to the community surfaces.

Flow 7 — A Community Owner / Moderator reviews and moderates

1. Starting context: An identified Community Owner / Moderator opens the Moderation surface through the shared rail skeleton with the left settings nav.
2. Actor action — review: They open the review queue of flagged messages and members and read the context of each item.
3. Decision: They choose a moderation action for a flagged member or message.
4. Commitment: They apply the action using a coral pill control with the hard-offset toy button treatment.
5. Observable result: The moderation outcome is applied and recorded, and the affected member or message reflects it.
6. Participant response: The affected Community Member experiences the outcome on their side — their standing or their message reflects the moderation.
7. Failure and recovery: If the moderation action fails, a readable error appears and the item remains in the queue.
8. Continuation: They continue reviewing, reverse an outcome if needed, or return to the community surfaces.

Flow 8 — Any persona uses the app under reduced motion

1. Starting context: A person whose system requests reduced motion opens discord-v2.
2. Landing: The island orbit stops and the marquee stops, becoming a horizontally scrollable row (overflow-x: auto) in which every item is fully readable. The headline, the coral pill, and every chip remain whole and uncovered.
3. Identity access: The Teddy Rive renders at its idle rest frame with the state machine paused. Every state — email focus, password focus, success, failure — is conveyed by readable text and control state instead of animation.
4. Community surfaces: Rail morphs become instant state changes with no rotation or scale; new messages appear instantly with no rise or fade; speaking rings do not pulse and the active speaker is indicated by a static mint ring and a readable label.
5. Observable result: All functionality remains reachable and every readable text and control stays whole at 375px, 768px and 1280px.
6. Continuation: The person uses the app exactly as in Flows 1–7, without motion.

6. Visuals Colors and Theme

Muse: Bruno Simon. Headline direction: Playable worlds — a chat app you can poke, with a teddy bear as the doorman.

The register is playful belonging: a clubhouse you hang out in, not a dashboard you operate. The toy energy lives in the frame, the hero and the login; the message surface stays legible and fast for long sessions.

Colour tokens — dark mode

Never a blue-indigo primary on white. The generic indigo/blue-on-white SaaS template is forbidden for this project.

Typography

• Headings: Fredoka — SemiBold/Bold for display and server names. Rounded, chunky, slightly toy-like terminals, set tight at letter-spacing -0.02em and in sentence case so it reads friendly, not shouty.
• Body: Nunito Sans 400/600/700 for all message text, member lists and settings at 15–16px with 1.55 line-height.
• Channel names and category labels: Nunito Sans 700 at 13px uppercase with +0.08em tracking, so the sidebar stays scannable under a playful surface.
• Type scale (1.333 modular): 14 / 16 / 21 / 28 / 40 / 56 / 76.
• Applied sizes: display headline clamp(40px, 9vw, 96px); server-name header 20px; channel label 13px; message body 15.5px; metadata 12.5px.

Shape language

Chunky rounded solids: 20px radius on panels and modals, 14px on message cards, 999px pills on every button, avatar and tag. Soft drop shadows — a hard offset 0 8px 0 rgba(0,0,0,0.35) style for buttons and a blurred 0 18px 40px for floating cards — so elements feel like physical toy pieces stacked on the room floor. Server rail icons are squircle tiles that morph from rounded-square to circle on hover: the one shape move that repeats app-wide.

Layout

Three-rail clubhouse on desktop: a 72px squircle server rail (icon-only, vertical, scrollable), a 240px channel rail in surface #221B36 with category groups, then the message stage. Voice/video opens as a right-hand 320px panel that can be dragged wider, with speaking members as glowing mint-ringed avatars in a grid. At 768px the channel rail collapses to a slide-over drawer and the voice panel becomes a bottom sheet. At 375px it is a single column: the server rail becomes a horizontal scrollable squircle strip at the top, the channel list is a full-screen list, the message stage is the page, and the composer is a pinned pill at the bottom that never leaves the viewport. Server Settings, Members and Moderation reuse the same rail skeleton with a left settings nav instead of channels, so the app feels like one world.

Imagery

Low-poly 3D as the visual world: a small floating clubhouse island (a rounded building, a tree, a satellite dish, a bridge) rendered in flat-shaded coral/mint/lemon/sky, used on the landing hero and as a subtle parallax band behind empty states. Channel and role icons are thick-line pictograms in the same toy palette. No stock photography, no glassmorphism, no gradient blobs. The Teddy Rive character is the only character asset and appears at login, in the invite-accepted confirmation, and as an empty-state greeter in an empty channel — always from the same .riv file and state machine.

7. Signature Design Concept

"The night playroom door."

The public entry is not a centred headline with a blue button. It is a full-bleed night-playroom scene. The low-poly clubhouse island — a rounded building with a tree, a satellite dish and a bridge, flat-shaded in coral, mint, lemon and sky — sits large and off-centre right, floating over the #141021 ground, slowly orbiting on a 24s loop under a soft coral rim light with a mint window glow.

The headline is left-aligned, bottom-anchored and oversized: "Your people are already in here." set in Fredoka at clamp(40px, 9vw, 96px), breaking across three lines and running into the island's negative space. Beneath it, a single coral pill — "Open the door" — sits directly above a horizontal, auto-scrolling marquee of real-looking server names and member counts rendered on surface chips. The marquee crosses the viewport edge by design and pauses to a scrollable row under reduced motion. There is no centred stack, no gradient blob, and no subtext paragraph above the fold.

The concept carries through to the login, which is a stage, not a form: the auth card is a 420px chunky rounded panel sitting on the night-playroom ground, and the Teddy .riv plays its full state machine inside it — idle breathing, looking up when the email field focuses, covering its eyes when the password field focuses, celebrating with a hop when auth succeeds, slumping with a small "hmm" shake on failure. The Rive canvas is 220px tall on desktop and 160px on mobile, always fully inside the panel and never overlapping the inputs.

Every primary button is a coral pill with a solid 4px darker bottom edge (box-shadow: 0 4px 0 #C2432F) that compresses on press — a physical, clickable-object feel. The server rail is a 72px vertical stack of squircle tiles that morph to circles and rotate 6° on hover, with a coral left-edge pill marking the active server. Channel categories are collapsible blocks with a 4px lemon/sky/mint left rule and uppercase Nunito labels, so the sidebar reads as stacked toy drawers rather than a flat list.

This concept recomposes only accepted content, states and controls. It introduces no new behaviour, page, or destination.

8. Interaction Model & Motion Direction

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

Landing Hero Motion Brief

• Focal subject: The low-poly clubhouse island — a rounded building with a tree, a satellite dish and a bridge, flat-shaded in coral/mint/lemon/sky — floating over the #141021 night-playroom ground, off-centre right, under a soft coral rim light with a mint window glow.
• Input → transformation → outcome thesis: The visitor's arrival sets the island drifting on a continuous 24s orbit; as the visitor reads the left-aligned, bottom-anchored headline and the marquee of server names and member counts, the island's slow rotation reveals its negative space so the headline runs into it; the visitor presses the coral "Open the door" pill, which squashes to 0.96 and springs back over 220ms, and the scene hands off to the login stage where the Teddy takes over as the character.
• Motion vocabulary: One continuous low-poly drift (a slow orbit of the 3D clubhouse island); a horizontal auto-scrolling marquee that crosses the viewport edge by design; button squash to 0.96 with a 220ms cubic-bezier(0.34, 1.56, 0.64, 1) spring-back; server rail icons rotating 6° and scaling 1.08 on hover; a 180ms spring slide for the channel rail and a cross-fade for the message stage; new messages popping in with a 12px rise and 160ms fade, never more; voice speaking rings pulsing at 1.2s.
• Composed first frame: The island sits large and off-centre right, mid-orbit, coral rim light catching its left face and mint light in its windows. The headline occupies the lower-left, breaking across three lines into the island's negative space. The coral pill sits directly beneath it, and the marquee of server chips runs across the bottom, already crossing the right viewport edge. No centred stack, no gradient blob, no subtext paragraph.
• Reduced-motion state: The island orbit stops and the scene holds a static flat-shaded composition in the same palette and layout. The marquee stops and becomes a horizontally scrollable row (overflow-x: auto) in which every item is fully readable. The headline, the coral pill and every chip remain whole and uncovered. The Teddy Rive renders at its idle rest frame with the state machine paused, and every login state is conveyed by readable text and control state instead.

Landing Hero 3D Scene Brief — DIRECTION-DERIVED

The direction's hero dimensionality is webgl, so a real-time WebGL/R3F hero subject is part of this direction.

• Crafted object: One compact real-time scene — the floating clubhouse island: a rounded low-poly building with a tree, a satellite dish and a bridge, flat-shaded in coral, mint, lemon and sky, floating over the #141021 ground.
• Defining state it shows: A community space that is alive and inhabited — the island drifts on a 24s orbit, its mint windows glow, and its coral rim light shifts as it turns, showing that the clubhouse is a place with people in it rather than a static illustration.
• Composition: Off-centre right, large, with deliberate negative space on the left and lower-left for the headline and the coral pill. The marquee of server chips runs across the bottom and crosses the viewport edge by design.
• Reduced motion: The orbit stops and the scene renders as a static flat-shaded composition in the same palette and layout, with all readable text and controls whole and uncovered.

9. Non-Functional Requirements

NFR-1 — Rive runtime for the login animation (explicit) The login animation must be rendered from a Rive (.riv) file through a Rive runtime, driven by a single state machine. Rationale: the user explicitly required the login animation to be a Teddy character in Rive format.

NFR-2 — Single selected Rive asset (explicit) Exactly one Teddy .riv file, selected from files discovered on a website, must drive the login animation and the other accepted Teddy appearances (invite-accepted confirmation, empty-channel greeter). Rationale: the user explicitly required one file to be selected from files found on a website, and the direction forbids any second character asset.

NFR-3 — Asset provenance integrity (explicit) No dummy, invented, or unverified asset may be presented as the selected Teddy file, and no unverified file path, size, or preview link may be fabricated. The verified search did not locate a publicly available Teddy .riv file, so the selection step remains open. Rationale: the reference directive declares content_source authority and its verified observation is a negative finding.

NFR-4 — Readable text and controls stay whole (explicit) Headlines, wordmarks, labels, numbers, card text and controls must 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 may cover 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 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. Rationale: explicit direction constraint.

NFR-5 — Reduced-motion support (explicit) With prefers-reduced-motion, the island orbit stops, rail morphs become instant state changes, the Teddy Rive renders at its idle rest frame with the state machine paused, and the landing marquee stops and shows whole items in a horizontally scrollable row. Rationale: explicit direction constraint.

NFR-6 — Message surface legibility under long sessions (explicit) The message surface must remain legible and fast: message body at 15.5px with 1.55 line-height, metadata at 12.5px in muted #9A90B8 on surface #221B36 (~5.4:1), and primary text #F4F1FA on #141021 (~15:1). Rationale: the direction requires the toy energy to live in the frame, hero and login while the message surface stays legible and fast.

NFR-7 — Real-time voice and video participation (explicit) Voice and video channels must support real-time participation with an observable active-speaker indication. Rationale: the accepted feature coverage includes voice and video channels, and the direction specifies a speaking-ring voice grid.

NFR-8 — Responsive rail behavior (explicit) The three-rail clubhouse layout must adapt: 72px server rail + 240px channel rail + message stage on desktop; channel rail as a slide-over drawer and voice panel as a bottom sheet at 768px; single column with a horizontal squircle server strip, full-screen channel list, and a pinned composer pill at 375px. Rationale: explicit direction layout constraint.

NFR-9 — Backend integration for identity and community state (required_inference) The application requires backend integration for identity establishment and verification, community state (servers, channels, roles, membership), message history, and real-time voice/video signaling. Rationale: indispensable to make the accepted journeys executable; the planning scope records requires_backend_integration: true.

NFR-10 — No second character asset (explicit) The Teddy .riv file is the only mascot, used from one state machine. No other character asset may be introduced. Rationale: explicit direction constraint.

10. Tech Stack

• Frontend: React (web application with custom UI).
• Backend: Python / FastAPI for identity, community state, message history, and real-time voice/video signaling.
• Real-time transport: WebSocket-based signaling for voice and video channels and for live message delivery.
• Animation runtime: Rive runtime for web, loading the single selected Teddy .riv file and driving it from one state machine.
• 3D hero: WebGL / React Three Fiber for the landing hero's low-poly clubhouse island, per the direction's webgl hero dimensionality.
• Storage: Relational storage for identity, servers, channels, roles, membership, messages, invitations, and moderation records; object storage for uploaded media referenced by messages.
• Containerization: Docker and docker-compose for local and single-host deployment.
• Orchestration: Kubernetes only if deployment scale requires it; not required by the current scope.

11. Assumptions and Constraints

Assumptions

• A-1 (required_inference) — Identity is application-owned: a new user self-enrolls, a returning user verifies identity, and an invited member accepts an invitation before joining the relevant community. This is the minimum identity continuity needed to make the accepted journeys executable.
• A-2 (required_inference) — The Landing and Login surfaces are anonymously reachable, because a protected destination cannot own the interaction that establishes access to itself.
• A-3 (required_inference) — The Servers, Messages, Voice & Video, Server Settings, Members and Moderation surfaces are protected and require an established identity.
• A-4 (required_inference) — Differentiated control over shared community state (server configuration, member management, moderation) comes from the community role a person holds within a server, not from application identity alone.
• A-5 (required_inference) — The Teddy .riv file is provisioned as an external content artifact selected from a website and consumed by the application's Rive runtime; the application does not host a Rive marketplace or file browser.
• A-6 (explicit) — The verified search did not locate a publicly available Teddy .riv file. The selection step remains open and must be completed before the login animation requirement is satisfied.

Constraints

• C-1 (explicit) — The login animation must use a Teddy character asset in Rive format (.riv).
• C-2 (explicit) — The Rive animation file must be one selected from files discovered on a website.
• C-3 (explicit) — The application must be Discord-like with a feature set at least as complete as Discord's.
• C-4 (explicit) — The login flow must include an animation.
• C-5 (explicit) — The Teddy .riv file is the only character asset, used from one state machine.
• C-6 (explicit) — The generic indigo/blue-on-white SaaS template is forbidden for this project.
• C-7 (explicit) — Readable text and controls stay whole at every viewport; where a direction, requirement, brief or finding asks readable text or a control to be cropped, clipped, covered or run off an edge, keep it whole and carry the gesture with imagery or decoration instead.
• C-8 (explicit) — The current scope does not include adjacent account-management capabilities (password reset flows, billing, subscription tiers, device management, or profile-marketplace features) beyond the identity establishment and verification needed to make the accepted journeys executable.

Defaults — not specified by user

• [Default — not specified by user] — React for the frontend, Python/FastAPI for the backend, Docker/docker-compose for containerization, and Kubernetes only when deployment requires it.
• [Default — not specified by user] — Relational storage for community state and message history, with object storage for uploaded media.
• [Default — not specified by user] — WebSocket-based signaling for real-time voice, video, and live message delivery.

12. Glossary

• Server — A community space within discord-v2, containing channels, roles, and members. Represented in the 72px squircle server rail.
• Channel — A named conversation space inside a server, either a text channel or a voice/video channel, grouped under a category.
• Category — A collapsible grouping of channels in the channel rail, marked by a 4px lemon/sky/mint left rule and an uppercase label.
• Role — A named standing within a server, carrying a lemon/sky/mint tag colour and governing what a member can do in that server.
• Community Member — The accepted persona who participates in servers and channels, reads and sends messages, and joins voice and video.
• Community Owner / Moderator — The accepted persona who creates and configures a server, invites and manages members, and moderates content and behavior.
• New / Returning User — The accepted persona who establishes or verifies identity on the identity access surface before entering community content.
• Teddy Rive file — The single Rive (.riv) animation file of a Teddy character, selected from files discovered on a website, that drives the login animation and the other accepted Teddy appearances from one state machine.
• Rive state machine — The single animation state machine inside the Teddy .riv file that drives idle breathing, looking up on email focus, covering eyes on password focus, celebrating on success, and slumping on failure.
• Squircle rail — The 72px vertical server rail of rounded-square tiles that morph to circles on hover and rotate 6°, with a coral left-edge pill marking the active server.
• Night playroom — The visual world of the product: a #141021 ground on which the low-poly clubhouse island floats and the Teddy acts as doorman.
• Clubhouse island — The low-poly 3D hero subject: a rounded building with a tree, a satellite dish and a bridge, flat-shaded in coral/mint/lemon/sky, floating over the night-playroom ground.
• Invitation — The mechanism by which a Community Owner / Moderator invites a person into a server, accepted by the invited person on the identity access surface.
• Moderation outcome — The recorded result of a moderation action applied to a flagged member or message, reversible by a Community Owner / Moderator.