System Requirements Document for discord-rpg

1. Introduction

Product intent. discord-rpg is a Discord RPG server bot built from scratch that turns a roleplay community's creative output — original characters, faction and guild applications, and server lore — into a durable, staff-governed archive. It is configurable by server admins, and it delivers an inviting, polished interactive experience through Discord slash commands, embeds, buttons, select menus, and modals where appropriate.

Audience. The bot serves four accepted human roles inside a Discord roleplay server: Server Admin (owns configuration and the lore source), Staff Reviewer (reviews original character submissions and runs roleplay support), Faction/Guild Leader (decides applications for their own group), and Player (submits characters, applies to factions and guilds, discovers lore, and uses roleplay support). A companion first-party web surface presents the archive, the faction route map, the lore provenance view, and the review queue with the ceremonial, museum-grade identity described in the creative direction.

Scope of this document. This SRD specifies the current, accepted product: the four core feature areas, secure token configuration, persistence, permission checks, error handling, and setup documentation. It also specifies the identity and access boundaries required to make those journeys executable, and it records the explicit constraint that no code is reused or migrated from the existing Discord Chatbot project.

2. System Overview

discord-rpg is delivered as a Discord bot (slash commands, embeds, buttons, select menus, modals) backed by a persistent service, plus a first-party web surface that renders the archive, faction route map, lore provenance, and review queue. The bot is the invisible archivist of a shared world: it receives player submissions and applications, routes them privately to the correct reviewers, records decisions, and communicates outcomes back to applicants.

Actors.

• Server Admin — configures the bot for the server: sets the OC review channel, configures each faction/guild application workflow independently, manages the editable staff-managed lore source, and handles the Discord bot token securely.
• Staff Reviewer — reviews OC submissions in the configured review channel, accepts, declines, or comments, and uses roleplay support utilities.
• Faction/Guild Leader — reviews and decides applications for their own faction or guild under that group's configuration.
• Player — submits an original character, applies to a faction or guild, receives outcomes and comments, discovers lore, and uses roleplay support.

Accepted behavior. (1) OC submissions via an interactive form, posted to an admin-configurable review channel, with accept/decline/comment and applicant communication. (2) Faction and guild applications with an interactive picker offering exactly the seven configured choices, decided by the relevant leaders, with per-group configurable workflow. (3) An RPG lore assistant drawing on an editable, staff-managed source that clearly distinguishes official lore from generated suggestions and never invents canon. (4) Roleplay support for staff and players: scene prompts, character hooks, event ideas, and staff utilities.

Ownership and privacy. Review actions are restricted; private submissions are never exposed publicly beyond the configured review channel and applicant communications. The Discord bot token is configured securely and never appears in public application content.

Narrow exclusions. No code is reused or migrated from the existing Discord Chatbot project. No photographic or illustrated character art is used in the web surface; the generative canvas is the only imagery. No blue, indigo, or violet appears in UI chrome.

2a. Product Interpretation and Delivery Boundary

Delivery ownership. The product is delivered as a Discord bot that owns the interactive workflows inside Discord (slash commands, embeds, buttons, select menus, modals) and a first-party web surface that owns the archive, faction route map, lore provenance view, and review queue. The bot's token is a deployment secret owned by the Server Admin and the deployment environment; it is never rendered as public application content.

Identity and access. The web surface establishes application-owned identity so that a Player's submissions and applications, a Staff Reviewer's review history, a Faction/Guild Leader's group decisions, and a Server Admin's configuration remain bound to the correct participant and resumable across visits. First use is anonymous: the Landing page is reachable without identity, and Sign Up establishes identity; Login verifies returning participants. Protected destinations (OC Submission, OC Review, OC Outcomes, Faction Apply, Faction Review, Bot Configuration, Lore Management, Lore Assistant, Roleplay Tools) require established identity. Inside Discord, the bot enforces permission checks so that only the correct reviewers can act on a given record.

Current vs. future. Everything specified in this document is current. No future-horizon features are accepted; nothing in this document should be read as committing to adjacent account-management, moderation, or analytics capabilities.

2b. Source Content Inventory

No reference directive in this project declares content_source; therefore no source content inventory is included.

2c. Page Content and Component Coverage

Landing

• Information/state. Anonymous public entry. Wordmark DISCORD·RPG in Instrument Serif, flush left on the canvas baseline. A single line of Space Grotesk in muted slate reading live archive counts (1,204 characters · 318 applications · 96 lore entries), numbers in bone, labels in muted. A thin aquamarine rule runs the full viewport width at the height where the particle field is densest — the only horizontal line on the screen.
• Primary action. One ember-outlined pill, Begin your character, pinned to the left margin.
• Supporting actions. Ghost link Read the lore to the right of the primary pill; navigation into Sign Up and Login.
• Domain entities. Archive counts (characters, applications, lore entries); faction bands; provenance legend.
• Component responsibilities. Full-bleed generative particle canvas (first 78vh) whose density is driven by real submission, application, and lore-entry counts; section rule that the particle field collapses into on scroll; numbered section labels (01 ARCHIVE, 02 FACTIONS, 03 LORE, 04 REVIEW); seven full-width colour-coded faction bands, each with sigil, name, and current applicant count; sticky context rail (current faction, active review queue count, provenance legend).
• States. Loading: canvas initializes with a single static frame until counts resolve. Empty: counts render as 0 characters · 0 applications · 0 lore entries with the same typographic treatment. Success: counts render live and the canvas drifts continuously. Error: if counts cannot be fetched, the count line renders a muted archive unavailable label and the canvas renders one static frame; the primary action remains available. Recovery: counts retry on next visit; no user action required.

Login

• Information/state. Returning-verification surface for Players, Server Admins, Staff Reviewers, and Faction/Guild Leaders. Anonymous entry; establishes the session that unlocks protected destinations.
• Primary action. Verify returning identity.
• Supporting actions. Link to Sign Up for participants without an established identity.
• Domain entities. Participant identity; session.
• Component responsibilities. Credential entry; verification submission; error surface; redirect to the participant's last protected context.
• States. Loading: submission control disabled with a restrained progress indicator. Empty: not applicable. Success: session established; participant continues to the destination they intended. Error: invalid credentials render an inline message and keep the form intact. Recovery: retry in place; no data loss.

Sign Up

• Information/state. Self-service enrollment for actors independently beginning use of the bot's protected workflows. Anonymous entry.
• Primary action. Establish identity.
• Supporting actions. Link to Login for participants who already have identity.
• Domain entities. Participant identity; Discord account association.
• Component responsibilities. Enrollment form; identity creation; handoff to the participant's first protected destination.
• States. Loading: submission control disabled. Empty: not applicable. Success: identity established; participant proceeds to OC Submission, Faction Apply, or the destination they intended. Error: duplicate or invalid enrollment renders an inline message. Recovery: retry in place.

OC Submission

• Information/state. Interactive original-character form for Players. Protected. Shows the participant's draft state and prior submissions with their current status.
• Primary action. Submit the original character.
• Supporting actions. Save draft; edit draft; view prior submission status; open OC Outcomes.
• Domain entities. Original character submission (fields captured by the interactive form); submission status; applicant identity; configured review channel.
• Component responsibilities. Interactive form (modal-style field capture); validation; submission posting to the admin-configurable review channel; confirmation with the submission's archive ID.
• States. Loading: form fields render with a restrained skeleton. Empty: no prior submissions — the form is presented alone with a short prompt. Success: submission posted to the configured review channel; the applicant sees a confirmation carrying the archive ID and a link to OC Outcomes. Error: validation failure keeps entered content and marks the offending fields; posting failure preserves the draft and offers retry. Recovery: retry re-posts the same draft without duplicating the record.

OC Review

• Information/state. Private review workspace for Staff Reviewers. Shows the queue of OC submissions posted to the configured review channel, each card carrying a numbered archive ID in tabular numerals at its top-right.
• Primary action. Accept or decline a submission.
• Supporting actions. Comment on a submission; open the full submission; filter the queue.
• Domain entities. OC submission; archive ID; reviewer identity; decision; comment; timestamp.
• Component responsibilities. Review queue; per-card decision controls; comment composer; a 400ms ember pulse along the card's top edge on accept or decline; private routing of the decision and comments to the applicant.
• States. Loading: queue renders with restrained skeletons. Empty: No submissions awaiting review in muted slate. Success: the card's top edge pulses ember for 400ms and the record is sealed with the decision and reviewer identity. Error: a failed decision leaves the card unchanged and surfaces an inline retry. Recovery: retry re-applies the same decision without duplicating the record.

OC Outcomes

• Information/state. Applicant-facing continuation. Shows the decision (accepted or declined) and the reviewer's comments for each of the participant's submissions, privately.
• Primary action. Read the decision and comments.
• Supporting actions. Open the associated submission; start a new submission.
• Domain entities. Submission; decision; comment; reviewer identity; timestamp.
• Component responsibilities. Outcome list; decision and comment rendering; private visibility scoped to the applicant and the configured review channel.
• States. Loading: outcome list renders with restrained skeletons. Empty: No decisions yet with a link to OC Submission. Success: decision and comments render with the archive ID and timestamp. Error: unavailable outcomes render an inline retry. Recovery: retry reloads the outcome list.

Faction Apply

• Information/state. Interactive application flow for Players. Presents the faction picker as a full-width colour-coded band list — seven bands, each with its sigil, name, and current applicant count — not a card grid or a dropdown. The exact choices are:\x20\xf0\x9f\x93\x9a The Eternal Archive;\x20\xf0\x9f\x8c\x91 The Umbral Covenant;\x20\xf0\x9f\x97\xa1️ The Iron Vanguard;\x20\xf0\x9f\x94\xae The Arcane Conclave;\x20\xf0\x9f\x8f\xb9 The Verdant Wardens;\x20\xf0\x9f\xa7\xaa The Alchemical Circle; and the Adventurers Guild.
• Primary action. Submit an application to the selected faction or guild.
• Supporting actions. Choose a faction band (which scrolls into that band's application form inline); view prior applications and their status.
• Domain entities. Faction/guild (the seven configured choices); application; applicant identity; per-group workflow configuration; application status.
• Component responsibilities. Seven-band route map; inline per-band application form; submission routing to the relevant group's reviewers; confirmation with the application's archive ID.
• States. Loading: bands render with restrained skeletons. Empty: no prior applications — the route map is presented alone. Success: application submitted under the selected group's configuration; the applicant sees a confirmation with the archive ID. Error: validation failure keeps entered content; routing failure preserves the draft and offers retry. Recovery: retry re-submits the same draft without duplicating the record.

Faction Review

• Information/state. Restricted workspace for Faction/Guild Leaders. Shows only applications belonging to the leader's own faction or guild, under that group's configured workflow.
• Primary action. Accept or decline an application.
• Supporting actions. Comment on an application; open the full application; filter the group's queue.
• Domain entities. Application; archive ID; group; leader identity; decision; comment; per-group workflow configuration.
• Component responsibilities. Group-scoped queue; per-card decision controls; comment composer; ember pulse on decision; private routing of the decision and comments to the applicant.
• States. Loading: queue renders with restrained skeletons. Empty: No applications awaiting your decision in muted slate. Success: the card's top edge pulses ember for 400ms and the record is sealed with the decision and leader identity. Error: a failed decision leaves the card unchanged and surfaces an inline retry. Recovery: retry re-applies the same decision without duplicating the record.

Bot Configuration

• Information/state. Server-admin workspace. Shows the current OC review channel, the per-group faction/guild application workflow settings, and the secure token configuration status (configured / not configured — never the token value).
• Primary action. Save configuration changes.
• Supporting actions. Set the OC review channel; configure each faction/guild workflow independently; update the bot token through secure handling; review current settings.
• Domain entities. Server configuration; review channel; per-group workflow configuration; bot token (secret, never rendered).
• Component responsibilities. Review-channel selector; per-group workflow editors; secure token entry that never echoes the value; save and confirmation surface.
• States. Loading: configuration renders with restrained skeletons. Empty: unconfigured server shows defaults with prompts to set the review channel and each group's workflow. Success: saved settings render with a confirmation and the token status shows configured. Error: invalid channel or workflow settings render inline messages and preserve prior values; token errors never echo the value. Recovery: correct and re-save; prior configuration remains in effect until a successful save.

Lore Management

• Information/state. Staff-managed editor for the persisted official lore source used by the assistant. Shows the current official entries and their provenance metadata.
• Primary action. Save an official lore entry.
• Supporting actions. Create, edit, and remove official lore entries; review the current source.
• Domain entities. Official lore entry; source; excerpt; editor identity; timestamp.
• Component responsibilities. Entry editor; source list; save and confirmation surface; persistence of the official source.
• States. Loading: entry list renders with restrained skeletons. Empty: No official lore yet with a prompt to create the first entry. Success: the entry persists and appears in the official source used by the assistant. Error: save failure preserves the draft and surfaces an inline retry. Recovery: retry saves the same draft.

Lore Assistant

• Information/state. Interactive lore discovery for Players and Staff Reviewers. Answers render as a two-column provenance block: left column is the verbatim official excerpt in Instrument Serif on a lighter surface, right column is the assistant's restatement in Space Grotesk on the dark ground, separated by a hard vertical rule and labelled OFFICIAL / GENERATED. Nothing generated is ever shown without its official source beside it.
• Primary action. Ask a lore question.
• Supporting actions. Open the cited official entry; refine the question.
• Domain entities. Official lore entry; excerpt; generated restatement; provenance diagram (Source → Excerpt → Assistant restatement).
• Component responsibilities. Question input; retrieval from the staff-managed official source; two-column provenance rendering; explicit labelling that generated content is a suggestion and does not establish canon.
• States. Loading: the provenance block renders with restrained skeletons. Empty: No official lore matches that question with a link to the official source. Success: the official excerpt and the labelled generated restatement render side by side with the provenance diagram. Error: retrieval failure renders an inline retry and never substitutes generated content for official lore. Recovery: retry the question; the official source remains authoritative.

Roleplay Tools

• Information/state. Interactive support destination for Players and Staff Reviewers: scene prompts, character hooks, event ideas, and staff utilities.
• Primary action. Generate or draw a scene prompt, character hook, or event idea.
• Supporting actions. Browse prior prompts and hooks; open staff utilities.
• Domain entities. Scene prompt; character hook; event idea; staff utility; author identity; timestamp.
• Component responsibilities. Prompt/hook/event generator; staff utility panel; history of prior outputs.
• States. Loading: output area renders with restrained skeletons. Empty: Nothing drawn yet with a prompt to generate. Success: the prompt, hook, or event idea renders with its author and timestamp. Error: generation failure renders an inline retry. Recovery: retry regenerates without losing prior outputs.

3. Functional Requirements

Each requirement is stated as a story point with provenance, lifecycle facts, and observable acceptance.

FR-1 — Build from scratch. As a Server Admin, I should run a Discord RPG server bot built from scratch, so that the server's roleplay archive is owned by this product alone.

• Provenance: explicit.
• Lifecycle: initiator — Server Admin; trigger — deployment; observable result — the bot runs as an independent product; failure/recovery — deployment failure surfaces in setup documentation guidance; continuation — configuration proceeds.
• Acceptance: no code is reused or migrated from the existing Discord Chatbot project, and no claim of reuse or migration is made.

FR-2 — Admin configurability. As a Server Admin, I should configure the bot for my server, so that its workflows match how my community runs.

• Provenance: explicit.
• Lifecycle: initiator — Server Admin; trigger — opening Bot Configuration; observable result — saved settings take effect for the server; failure/recovery — invalid settings are rejected with prior values preserved; continuation — the server runs under the saved configuration.
• Acceptance: the OC review channel and each faction/guild application workflow are independently configurable and persist.

FR-3 — Polished interactive experience. As a Player, I should interact with the bot through slash commands, embeds, buttons, select menus, and modals, so that submissions, applications, lore, and roleplay support feel inviting and polished.

• Provenance: explicit.
• Lifecycle: initiator — any accepted participant; trigger — invoking a bot interaction; observable result — a coherent embed/button/select/modal response; failure/recovery — sensible error handling with a clear retry; continuation — the participant completes the interaction.
• Acceptance: each core feature is reachable through Discord slash commands with embeds, buttons, select menus, and modals where appropriate.

FR-4 — OC submission form. As a Player, I should submit an original character through an interactive form, so that my character enters the server's archive.

• Provenance: explicit.
• Lifecycle: initiator — Player; trigger — opening OC Submission; observable result — the submission is persisted and posted to the configured review channel with an archive ID; failure/recovery — validation or posting failure preserves the draft and offers retry; continuation — the Player tracks the submission in OC Outcomes.
• Acceptance: the interactive form captures the character and the submission appears in the admin-configurable review channel.

FR-5 — Review-channel routing. As a Server Admin, I should set the review channel where OC submissions are posted, so that review happens where my staff work.

• Provenance: explicit.
• Lifecycle: initiator — Server Admin; trigger — setting the review channel in Bot Configuration; observable result — subsequent OC submissions post to that channel; failure/recovery — an invalid channel is rejected and the prior channel remains; continuation — staff review in the configured channel.
• Acceptance: the review channel is admin-configurable and persists.

FR-6 — Staff decisions on OC submissions. As a Staff Reviewer, I should accept, decline, or comment on an OC submission, so that the applicant receives a clear decision and feedback.

• Provenance: explicit.
• Lifecycle: initiator — Staff Reviewer; trigger — opening a submission in OC Review; observable result — the decision and comments are recorded and privately communicated to the applicant; failure/recovery — a failed decision leaves the record unchanged and offers retry; continuation — the applicant reads the outcome in OC Outcomes.
• Acceptance: accept, decline, and comment are all available, and the outcome and comments reach the applicant.

FR-7 — Applicant receipt of outcomes. As a Player, I should receive the outcome and comments on my OC submission privately, so that I know the decision and what to improve.

• Provenance: explicit.
• Lifecycle: initiator — Player; trigger — opening OC Outcomes; observable result — the decision and reviewer comments render with the archive ID; failure/recovery — unavailable outcomes offer retry; continuation — the Player starts a new submission or revises.
• Acceptance: decisions and comments are visible to the applicant and are not exposed publicly beyond the configured review channel and applicant communications.

FR-8 — Faction and guild application requirement. As a Player, I should apply to a faction or guild through the bot, so that joining requires an application.

• Provenance: explicit.
• Lifecycle: initiator — Player; trigger — opening Faction Apply; observable result — the application is persisted and routed to the relevant group's reviewers; failure/recovery — validation or routing failure preserves the draft and offers retry; continuation — the Player awaits the group's decision.
• Acceptance: joining a faction or guild requires an application submitted through the bot.

FR-9 — Exact faction picker choices. As a Player, I should choose from exactly the configured faction and guild choices, so that I apply to the right group.

• Provenance: explicit.
• Lifecycle: initiator — Player; trigger — opening the faction picker; observable result — the picker presents exactly:\x20\xf0\x9f\x93\x9a The Eternal Archive;\x20\xf0\x9f\x8c\x91 The Umbral Covenant;\x20\xf0\x9f\x97\xa1️ The Iron Vanguard;\x20\xf0\x9f\x94\xae The Arcane Conclave;\x20\xf0\x9f\x8f\xb9 The Verdant Wardens;\x20\xf0\x9f\xa7\xaa The Alchemical Circle; and the Adventurers Guild; failure/recovery — an unavailable group is shown as unavailable rather than silently removed; continuation — the Player selects a band and continues into that group's form.
• Acceptance: the picker offers exactly those seven choices and no others.

FR-10 — Leader decisions on applications. As a Faction/Guild Leader, I should accept or decline applications for my own faction or guild, so that my group's applicants receive decisions.

• Provenance: explicit.
• Lifecycle: initiator — Faction/Guild Leader; trigger — opening Faction Review; observable result — the decision is recorded and privately communicated to the applicant; failure/recovery — a failed decision leaves the record unchanged and offers retry; continuation — the applicant receives the outcome.
• Acceptance: the relevant leader can accept or decline, and only applications belonging to that leader's group are presented.

FR-11 — Per-group workflow configuration. As a Server Admin, I should configure the faction/guild application workflow per group, so that each group runs its own process.

• Provenance: explicit.
• Lifecycle: initiator — Server Admin; trigger — editing a group's workflow in Bot Configuration; observable result — that group's applications follow its own configuration; failure/recovery — invalid settings are rejected and prior values remain; continuation — the group's leaders review under the saved configuration.
• Acceptance: each of the seven groups has an independently configurable workflow.

FR-12 — Editable staff-managed lore source. As a Server Admin, I should manage the official lore source, so that the assistant answers from lore my staff control.

• Provenance: explicit.
• Lifecycle: initiator — Server Admin or Staff Reviewer; trigger — editing in Lore Management; observable result — the official source persists and is used by the assistant; failure/recovery — save failure preserves the draft and offers retry; continuation — the assistant answers from the updated source.
• Acceptance: the lore source is editable, staff-managed, and persisted.

FR-13 — Lore discovery. As a Player, I should ask the lore assistant about server lore, so that I can discover what is established.

• Provenance: explicit.
• Lifecycle: initiator — Player; trigger — asking a question in Lore Assistant; observable result — the answer renders with the official excerpt and a labelled generated restatement; failure/recovery — retrieval failure offers retry and never substitutes generated content for official lore; continuation — the Player opens the cited official entry or refines the question.
• Acceptance: the assistant answers from the staff-managed source and cites it.

FR-14 — Official vs. generated distinction. As a Player, I should see official lore clearly distinguished from generated suggestions, so that I never mistake a suggestion for canon.

• Provenance: explicit.
• Lifecycle: initiator — Player; trigger — reading a lore answer; observable result — the official excerpt and the generated restatement render in separate labelled columns (OFFICIAL / GENERATED) with a provenance diagram; failure/recovery — if no official source matches, the assistant says so rather than generating canon; continuation — the Player relies on the official excerpt.
• Acceptance: nothing generated is shown without its official source beside it, and the assistant does not invent canon.

FR-15 — Roleplay support. As a Player, I should draw scene prompts, character hooks, and event ideas, so that I can start and sustain scenes.

• Provenance: explicit.
• Lifecycle: initiator — Player; trigger — opening Roleplay Tools; observable result — a prompt, hook, or event idea renders with author and timestamp; failure/recovery — generation failure offers retry without losing prior outputs; continuation — the Player uses the output in play or draws another.
• Acceptance: scene prompts, character hooks, and event ideas are available to players.

FR-16 — Staff roleplay utilities. As a Staff Reviewer, I should use staff utilities alongside roleplay support, so that I can run scenes and events for the server.

• Provenance: explicit.
• Lifecycle: initiator — Staff Reviewer; trigger — opening Roleplay Tools; observable result — staff utilities render alongside prompts, hooks, and event ideas; failure/recovery — utility failure offers retry; continuation — the staff member runs the scene or event.
• Acceptance: staff utilities are available to staff within roleplay support.

FR-17 — Secure bot token configuration. As a Server Admin, I should configure the Discord bot token securely, so that the credential is never exposed.

• Provenance: explicit.
• Lifecycle: initiator — Server Admin; trigger — entering the token in Bot Configuration; observable result — the token is stored securely and only its configured/not-configured status is shown; failure/recovery — an invalid token is rejected without echoing the value; continuation — the bot runs with the configured token.
• Acceptance: the token is never rendered as public application content and is never echoed back.

FR-18 — Persistence. As a Server Admin, I should have submissions, applications, and configuration persisted, so that the archive survives restarts.

• Provenance: explicit.
• Lifecycle: initiator — system; trigger — any accepted write; observable result — submissions, applications, comments, decisions, configuration, and lore source data persist; failure/recovery — a failed write surfaces an error and preserves the participant's draft; continuation — the record is available on the next visit.
• Acceptance: submissions, applications, and configuration survive restarts and are retrievable.

FR-19 — Permission checks. As a Server Admin, I should have permission checks enforced, so that only the right people act on the right records.

• Provenance: explicit.
• Lifecycle: initiator — system; trigger — any restricted action; observable result — only authorized participants can act; failure/recovery — an unauthorized attempt is refused with a clear message and no state change; continuation — the authorized participant proceeds.
• Acceptance: review actions are restricted; server-admin configuration requires server-admin permission; faction/guild decisions are limited to the relevant group's leaders.

FR-20 — Sensible error handling. As a Player, I should see sensible errors when something fails, so that I can recover without losing work.

• Provenance: explicit.
• Lifecycle: initiator — any accepted participant; trigger — a failed interaction; observable result — a clear, non-technical error with a retry path; failure/recovery — the participant's draft or prior state is preserved; continuation — the participant retries successfully.
• Acceptance: failures never silently discard a submission, application, comment, decision, or configuration change.

FR-21 — Setup documentation. As a Server Admin, I should follow setup documentation, so that I can install, configure, and run the bot.

• Provenance: explicit.
• Lifecycle: initiator — Server Admin; trigger — reading the documentation; observable result — the bot is installed, permissions are set, and configuration is completed; failure/recovery — the documentation covers common setup failures; continuation — the server runs the bot.
• Acceptance: setup documentation covers installation, permissions, configuration, and workflow continuity.

FR-22 — Privacy of review and applicant communication. As a Player, I should have my submissions kept private, so that they are not exposed publicly.

• Provenance: explicit.
• Lifecycle: initiator — system; trigger — any submission, application, comment, or decision; observable result — content is visible only in the configured review channel and to the applicant; failure/recovery — an attempted public exposure is refused; continuation — review proceeds privately.
• Acceptance: private submissions are not exposed publicly beyond the configured review channel and applicant communications.

FR-23 — Self-service enrollment. As a Player, I should establish my own identity, so that I can begin using the bot's protected workflows.

• Provenance: required_inference.
• Lifecycle: initiator — Player, Server Admin, Staff Reviewer, or Faction/Guild Leader; trigger — first use of a protected destination; observable result — identity is established and the participant proceeds; failure/recovery — invalid or duplicate enrollment renders an inline message; continuation — the participant reaches the intended protected destination.
• Acceptance: an anonymous visitor can establish identity from Sign Up and then reach a protected destination.

FR-24 — Returning verification. As a returning participant, I should verify my identity, so that my submissions, applications, reviews, and configuration remain bound to me.

• Provenance: required_inference.
• Lifecycle: initiator — any accepted participant; trigger — returning to a protected destination; observable result — the session is established and the participant's own state is shown; failure/recovery — invalid credentials render an inline message and keep the form intact; continuation — the participant resumes their work.
• Acceptance: protected destinations require established identity, and each participant sees only their own state.

FR-25 — Server-admin permission for configuration and token. As a Server Admin, I should be the only one who can change configuration and the bot token, so that server settings stay under my control.

• Provenance: required_inference.
• Lifecycle: initiator — Server Admin; trigger — opening Bot Configuration; observable result — only server admins can save configuration or token changes; failure/recovery — a non-admin attempt is refused with no state change; continuation — the admin saves successfully.
• Acceptance: configuration and token changes require server-admin permission.

FR-26 — Reviewer permission for restricted actions. As a Staff Reviewer or Faction/Guild Leader, I should act only on records I am responsible for, so that review stays private and correct.

• Provenance: required_inference.
• Lifecycle: initiator — Staff Reviewer or Faction/Guild Leader; trigger — opening a review queue; observable result — only the records that participant is responsible for are presented and actionable; failure/recovery — an out-of-scope attempt is refused with no state change; continuation — the reviewer decides the in-scope record.
• Acceptance: OC review actions require staff permission; faction/guild decisions are limited to the relevant group's leaders.

4. User Personas

Server Admin

Product context. The Server Admin owns the bot's configuration for one Discord server. They are the person who decides where OC submissions land, how each faction and guild runs its own application workflow, what counts as official lore, and how the bot token is handled. They are accountable for the server's privacy posture.

Primary goal. The server's submission, application, and lore workflows run with the settings they chose, and the bot token stays secret.

Distinct accepted responsibilities. Setting the OC review channel (FR-5); configuring each of the seven faction/guild application workflows independently (FR-11); managing the editable staff-managed lore source (FR-12); configuring the Discord bot token securely (FR-17); relying on persistence for submissions, applications, and configuration (FR-18); enforcing permission checks (FR-19); following setup documentation (FR-21).

Relevant inputs and decisions. Which channel receives OC submissions; what each group's workflow requires; which lore entries are official; the bot token value, entered once and never echoed.

Interactions with other participants. The Server Admin's configuration determines what Staff Reviewers see in OC Review and what Faction/Guild Leaders see in Faction Review. The lore source they manage is what the Lore Assistant answers from, so their editorial decisions directly shape what Players read as official.

Observable success. Saved settings take effect for the server; the token status reads configured without the value ever being shown; the lore source the assistant cites is the one the admin last saved.

Staff Reviewer

Product context. The Staff Reviewer works the OC queue in the configured review channel and also runs roleplay support for the server. They are the server's editorial gate for original characters and a source of scene and event material.

Primary goal. Applicants receive clear decisions and feedback, and review actions stay private to the review channel and applicant communications.

Distinct accepted responsibilities. Accepting, declining, or commenting on OC submissions (FR-6); using staff roleplay utilities (FR-16); contributing to the staff-managed lore source (FR-12); acting only on records they are responsible for (FR-26).

Relevant inputs and decisions. The submission content and its archive ID; whether the character fits the server; what comment to send the applicant; which scene prompt, hook, or event idea to draw.

Interactions with other participants. The Staff Reviewer acts on what Players submitted and what the Server Admin routed to the review channel. Their decision and comments are what the Player reads in OC Outcomes. Their lore edits change what the Lore Assistant presents as official.

Observable success. Each reviewed card is sealed with a decision and reviewer identity, the applicant receives the decision and comments privately, and no submission content appears outside the configured review channel and applicant communications.

Faction/Guild Leader

Product context. The Faction/Guild Leader handles applications for one of the seven groups —\x20\xf0\x9f\x93\x9a The Eternal Archive,\x20\xf0\x9f\x8c\x91 The Umbral Covenant,\x20\xf0\x9f\x97\xa1️ The Iron Vanguard,\x20\xf0\x9f\x94\xae The Arcane Conclave,\x20\xf0\x9f\x8f\xb9 The Verdant Wardens,\x20\xf0\x9f\xa7\xaa The Alchemical Circle, or the Adventurers Guild — under the workflow the Server Admin configured for that group.

Primary goal. Their group's applicants get decisions under the group's own configuration.

Distinct accepted responsibilities. Accepting or declining applications for their own group (FR-10); acting only on records belonging to their group (FR-26).

Relevant inputs and decisions. The application content and its archive ID; the group's configured workflow; whether the applicant fits the group; what comment to send.

Interactions with other participants. The leader receives what Players submitted through Faction Apply and decides under the Server Admin's per-group configuration. Their decision and comments reach the applicant privately.

Observable success. Only their group's applications appear in their queue, each decision is sealed with their identity, and the applicant receives the outcome.

Player

Product context. The Player is the creative participant: they submit original characters, apply to factions and guilds, ask the lore assistant about the world, and draw scene prompts and character hooks for play.

Primary goal. Their submissions and applications are resolved with feedback, and they can find lore while official lore stays clearly distinguished from generated suggestions.

Distinct accepted responsibilities. Submitting an original character through the interactive form (FR-4); receiving outcomes and comments privately (FR-7); applying to a faction or guild through the bot (FR-8); choosing from exactly the seven configured groups (FR-9); asking the lore assistant (FR-13); seeing official lore distinguished from generated suggestions (FR-14); drawing scene prompts, character hooks, and event ideas (FR-15); establishing identity (FR-23) and verifying on return (FR-24).

Relevant inputs and decisions. The character's details; which faction or guild to apply to; what to ask the lore assistant; which prompt or hook to use.

Interactions with other participants. The Player's submission is what the Staff Reviewer decides on; their application is what the Faction/Guild Leader decides on; the lore they read is what the Server Admin and Staff Reviewer published as official.

Observable success. Each submission and application carries an archive ID and a private outcome; lore answers show the official excerpt beside the labelled generated restatement; nothing they submitted appears publicly outside the configured review channel and their own communications.

5. Core User Flows

Flow A — Server Admin configures the bot

1. The Server Admin opens the Landing page and reads the archive counts and the seven faction bands.
2. They choose Login (or Sign Up if they have no identity yet) and establish a session.
3. They open Bot Configuration. The page shows the current OC review channel, the per-group workflow settings, and the token status.
4. They set the OC review channel. The setting is validated and saved; subsequent OC submissions will post there.
5. They configure each faction/guild workflow independently — for example, requiring different fields for\x20\xf0\x9f\x93\x9a The Eternal Archive than for\x20\xf0\x9f\xa7\xaa The Alchemical Circle. Each group's settings save separately.
6. They enter the Discord bot token through secure handling. The value is never echoed; the status changes to configured.
7. Failure/recovery: if a channel or workflow setting is invalid, an inline message appears and the prior values remain in effect. If the token is rejected, the error never echoes the value and the previous token remains.
8. Continuation: the Server Admin opens Lore Management and creates or edits official lore entries, which persist as the source the assistant will cite.

Flow B — Player submits an original character

1. The Player opens the Landing page and selects Begin your character.
2. They establish identity through Sign Up (or verify through Login if returning).
3. They open OC Submission. The interactive form renders; any prior submissions appear with their current status.
4. They complete the form and submit. The submission is persisted and posted to the admin-configurable review channel with an archive ID.
5. Failure/recovery: if validation fails, the entered content is kept and the offending fields are marked. If posting fails, the draft is preserved and a retry re-posts the same draft without duplicating the record.
6. Continuation: the Player sees a confirmation carrying the archive ID and a link to OC Outcomes, where they will read the decision.

Flow C — Staff Reviewer decides an OC submission

1. The Staff Reviewer opens OC Review. The queue shows submissions posted to the configured review channel, each card carrying a numbered archive ID in tabular numerals at its top-right.
2. They open a submission and read it.
3. They choose Accept or Decline. A 400ms ember pulse sweeps the card's top edge and the record is sealed with the decision and their identity.
4. They add a comment. The comment is recorded and routed privately to the applicant.
5. Failure/recovery: if the decision fails, the card is unchanged and an inline retry is offered; retrying re-applies the same decision without duplicating the record.
6. Continuation: the applicant receives the decision and comments privately in OC Outcomes. Nothing about the submission appears outside the configured review channel and applicant communications.

Flow D — Player receives an OC outcome

1. The Player opens OC Outcomes.
2. The decision (accepted or declined) and the reviewer's comments render with the archive ID and timestamp.
3. Failure/recovery: if outcomes are unavailable, an inline retry is offered.
4. Continuation: the Player starts a new submission from OC Submission or revises the character.

Flow E — Player applies to a faction or guild

1. The Player opens Faction Apply. The picker renders as seven full-width colour-coded bands, each with its sigil, name, and current applicant count:\x20\xf0\x9f\x93\x9a The Eternal Archive;\x20\xf0\x9f\x8c\x91 The Umbral Covenant;\x20\xf0\x9f\x97\xa1️ The Iron Vanguard;\x20\xf0\x9f\x94\xae The Arcane Conclave;\x20\xf0\x9f\x8f\xb9 The Verdant Wardens;\x20\xf0\x9f\xa7\xaa The Alchemical Circle; and the Adventurers Guild.
2. They choose a band. The page scrolls into that band's application form inline.
3. They complete the form under that group's configured workflow and submit. The application is persisted and routed to the relevant group's reviewers with an archive ID.
4. Failure/recovery: validation failure keeps the entered content; routing failure preserves the draft and offers retry without duplicating the record.
5. Continuation: the Player awaits the group's decision and can view prior applications and their status.

Flow F — Faction/Guild Leader decides an application

1. The Faction/Guild Leader opens Faction Review. Only applications belonging to their own group appear, under that group's configured workflow.
2. They open an application and read it.
3. They choose Accept or Decline. The card's top edge pulses ember for 400ms and the record is sealed with the decision and their identity.
4. They add a comment, which is routed privately to the applicant.
5. Failure/recovery: a failed decision leaves the record unchanged and offers an inline retry.
6. Continuation: the applicant receives the outcome privately. Applications for other groups never appear in this leader's queue.

Flow G — Player discovers lore

1. The Player opens Lore Assistant and asks a question about the server's lore.
2. The assistant retrieves from the staff-managed official source and renders a two-column provenance block: the verbatim official excerpt in Instrument Serif on a lighter surface on the left, labelled OFFICIAL, and the assistant's restatement in Space Grotesk on the dark ground on the right, labelled GENERATED, separated by a hard vertical rule. A thin-line provenance diagram shows Source → Excerpt → Assistant restatement.
3. Failure/recovery: if no official lore matches, the assistant says so and links to the official source rather than generating canon. If retrieval fails, an inline retry is offered and generated content is never substituted for official lore.
4. Continuation: the Player opens the cited official entry or refines the question.

Flow H — Staff manages the official lore source

1. The Server Admin or Staff Reviewer opens Lore Management.
2. They create or edit an official lore entry and save it. The entry persists as part of the official source.
3. Failure/recovery: a failed save preserves the draft and offers an inline retry.
4. Continuation: the Lore Assistant answers from the updated source, and the new entry appears as the OFFICIAL column in future answers.

Flow I — Player and staff use roleplay support

1. The Player or Staff Reviewer opens Roleplay Tools.
2. They draw a scene prompt, character hook, or event idea. The output renders with its author and timestamp.
3. Staff additionally open the staff utilities panel for server-side scene and event support.
4. Failure/recovery: a failed generation offers an inline retry without losing prior outputs.
5. Continuation: the participant uses the output in play or draws another.

6. Visuals, Colors and Theme

The creative direction is authoritative for this section. Muse: Refik Anadol. Headline idea: data made physical — the bot's own submissions rendered as a living archive.

Mode. Dark mode only.

Colour tokens (exact hex by role).

Colour rules. Never use blue or indigo anywhere. The only cool hue is the aquamarine primary, and it must always read as light, not as UI chrome colour. The generic indigo/blue-on-white SaaS template is forbidden.

Typography. Headings: Instrument Serif, weight 400 only, tight tracking -0.02em, sentence case for editorial headers, all-caps for micro-labels at 11px with +0.18em tracking. The serif never appears below 28px. Body and UI: Space Grotesk at 15–16px with +0.01em tracking, tabular numerals for counters, IDs, timestamps, and vote tallies.

Type scale. 1.333 modular: 96 / 72 / 54 / 40 / 30 / 22 / 16 / 14 / 12. Display sizes clamp: hero headline clamp(40px, 9vw, 128px); section headlines clamp(28px, 4.5vw, 54px); card titles 22px; body 16px; micro-labels 11px.

Shape language. Full-bleed canvases with soft, organic boundaries; section transitions are long horizontal sweeps rather than hard rules. Cards use 20px radii with a 1px inner hairline at rgba(242,240,234,0.08) and no drop shadow — depth comes from a faint inner glow at the top edge. Status chips are pill-shaped; data rows are ruled with 1px slate lines. Nothing is sharp-cornered except the vertical rule separating Official from Generated columns.

Spacing rhythm. A single wide column dominated by the generative canvas in the hero, then a two-column asymmetric grid: 8 of 12 columns for the archive stream, 4 columns for a sticky context rail showing the current faction, the active review queue count, and the provenance legend. Section boundaries are marked by a 1px full-bleed rule with a small numbered label at the left margin (01 ARCHIVE, 02 FACTIONS, 03 LORE, 04 REVIEW). The seven factions each get a colour-coded, full-width horizontal band rather than a card grid, so the picker reads as a route map, not a menu.

Imagery style. The generative canvas is the imagery. No stock photography, no clip art, no character illustrations. Secondary imagery is schematic: a thin-line provenance diagram (Source → Excerpt → Assistant restatement) and faction sigils drawn as pure geometric marks in each faction's band colour — never emoji-as-art. The seven faction emoji exist only inside Discord-side copy.

Readable text and controls. Headlines, wordmarks, labels, numbers, cards' text, and controls stay entirely inside the viewport and their container at 375px, 768px, and 1280px, wrapping or scaling (for example font-size: clamp(...) with its mobile size) to fit, and no other element covers any part of them. Imagery, decoration, and motion may be cropped, bled off an edge, rotated, overlapped, or cut as the direction asks, as long as it covers no readable text or control. Moving and scrollable content may cross the viewport or container edge by design; with prefers-reduced-motion it stops and shows whole items, wrapping into rows or sitting in a horizontally scrollable row (overflow-x: auto).

7. Signature Design Concept

The archive renders itself.

The public entry is a full-bleed near-black canvas occupying the first 78vh. A slow-drifting particle field condenses visibly toward the lower third; its density is driven by the real count of submissions, applications, and lore entries in the database. The wordmark DISCORD·RPG is set in Instrument Serif at clamp(40px, 9vw, 128px), flush left, sitting on the canvas baseline — not centred, not boxed. Directly beneath it, a single line of Space Grotesk at 16px in muted slate reads the live archive counts (1,204 characters · 318 applications · 96 lore entries), with the numbers in bone and the labels in muted. The primary action is one ember-outlined pill, Begin your character, pinned to the left margin, with a secondary ghost link Read the lore to its right. A thin aquamarine rule runs the full viewport width at the exact height where the particle field is densest, and it is the only horizontal line on the screen.

On scroll, the particle field collapses into a single 1px horizontal rule that becomes the section divider, so the hero's motion resolves into the page's structure. Faction selection is a full-width colour-coded band list — seven bands, each with its sigil, name, and current applicant count — and choosing a faction scrolls into that band's application form inline. Lore answers render as a two-column provenance block: the verbatim official excerpt in Instrument Serif on a lighter surface on the left, the assistant's restatement in Space Grotesk on the dark ground on the right, separated by a hard vertical rule and labelled OFFICIAL / GENERATED. Nothing generated is ever shown without its official source beside it. Every review card in the staff queue carries a numbered archive ID in tabular numerals at its top-right, and a 400ms ember pulse sweeps its top edge on accept or decline — a small ceremonial mark that the record has been sealed.

No gradient blob, no centred stack, no blue button, no hover-lift cards, no rounded-corner glass panels with backdrop blur.

8. Interaction Model & Motion Direction

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

Landing Hero Motion Brief

Focal subject. A real-time particle field derived from the live count of submissions, applications, and lore entries — the archive rendering itself.

Input → transformation → outcome thesis. As the participant scrolls from the hero into the archive, the particle field collapses into a single 1px horizontal rule that becomes the section divider; the hero's motion resolves into the page's structure. The field's density is driven by real archive counts, never random noise.

Motion vocabulary. Continuous slow generative drift in the hero canvas; scroll-linked morph from particle field to section rule; a single 400ms ember pulse along a review card's top edge on accept or decline. No bounce, no spring, no hover-lift.

Composed first frame. Near-black canvas, particle field condensing toward the lower third, DISCORD·RPG flush left on the baseline, the live count line beneath it, the ember-outlined Begin your character pill pinned to the left margin, the ghost Read the lore link to its right, and one thin aquamarine rule at the field's densest height.

Reduced-motion state. With prefers-reduced-motion, the canvas renders one static frame and all reveals become instant; the section rule is present without the collapse animation, and the ember pulse is replaced by an immediate state change.

Landing Hero 3D Scene Brief — DIRECTION-DERIVED

A single crafted real-time object: a luminous particle field whose density and condensation are driven by the live archive counts (characters, applications, lore entries). The scene shows the product's defining state — a growing, searchable archive — as a slow-drifting volume that condenses toward the lower third of the frame and, on scroll, collapses into the 1px section rule. The scene uses only the palette tokens (#07070C ground, #7CE3D4 flow lines, #FF6B3D attention, #F2F0EA bone, #7A7F93 muted) and renders one static frame under prefers-reduced-motion.

9. Non-Functional Requirements

NFR-1 — Secure token handling. The Discord bot token is configured securely and never rendered as public application content or echoed back to any participant. Provenance: explicit. Rationale: the token is a deployment credential; exposing it would compromise the bot.

NFR-2 — Privacy of submissions and review. Review actions are restricted, and private submissions are not exposed publicly beyond the configured review channel and applicant communications. Provenance: explicit. Rationale: the server's creative work is private until its owner chooses otherwise.

NFR-3 — Persistence durability. Submissions, applications, comments, decisions, configuration, and lore source data persist across restarts. Provenance: explicit. Rationale: the archive is the product's core value.

NFR-4 — Permission enforcement. Permission checks are enforced on every restricted action: server-admin configuration and token changes require server-admin permission; OC review requires staff permission; faction/guild decisions are limited to the relevant group's leaders. Provenance: explicit (permission checks) and required_inference (the specific boundaries). Rationale: privacy and correctness depend on the right participant acting on the right record.

NFR-5 — Error handling. Failures produce clear, non-technical messages with a retry path and never silently discard a submission, application, comment, decision, or configuration change. Provenance: explicit.

NFR-6 — Setup documentation. Setup documentation covers installation, permissions, configuration, and workflow continuity. Provenance: explicit.

NFR-7 — No code reuse. No code is reused or migrated from the existing Discord Chatbot project, and no such claim is made. Provenance: explicit.

NFR-8 — Faction picker exactness. The faction picker offers exactly the seven configured choices and no others. Provenance: explicit.

NFR-9 — Lore provenance integrity. The lore assistant clearly distinguishes official lore from generated suggestions and never invents canon; nothing generated is shown without its official source beside it. Provenance: explicit.

NFR-10 — Readable text and controls. Headlines, wordmarks, labels, numbers, cards' text, and controls stay entirely inside the viewport and their container at 375px, 768px, and 1280px, and no other element covers any part of them. Provenance: explicit (creative direction). Rationale: legibility is a hard constraint of the direction.

NFR-11 — Reduced motion. With prefers-reduced-motion, the canvas renders one static frame and all reveals become instant. Provenance: explicit (creative direction).

NFR-12 — Palette restriction. No blue, indigo, or violet appears in UI chrome, including focus rings and link colours. Provenance: explicit (creative direction).

10. Tech Stack

• Bot runtime: Python with discord.py (or an equivalent Python Discord library) implementing slash commands, embeds, buttons, select menus, and modals. [Default — not specified by user]
• Backend service: Python / FastAPI serving the first-party web surface and the persistence API. [Default — not specified by user]
• Persistence: a relational database (PostgreSQL) for submissions, applications, comments, decisions, configuration, and the official lore source. [Default — not specified by user]
• Web surface: React with a WebGL/R3F hero canvas for the generative particle field. [Default — not specified by user]
• Containerization: Docker and docker-compose for local and single-host deployment. [Default — not specified by user]
• Orchestration: Kubernetes only if the deployment requires it; not required by any accepted requirement. [Default — not specified by user]

No source-specified technology choices exist beyond the Discord platform itself; the items above are labeled defaults and do not constitute product behavior.

11. Assumptions and Constraints

Constraints (binding).

• Do not claim to reuse or migrate code from the existing Discord Chatbot project.
• The faction picker choices are exactly:\x20\xf0\x9f\x93\x9a The Eternal Archive;\x20\xf0\x9f\x8c\x91 The Umbral Covenant;\x20\xf0\x9f\x97\xa1️ The Iron Vanguard;\x20\xf0\x9f\x94\xae The Arcane Conclave;\x20\xf0\x9f\x8f\xb9 The Verdant Wardens;\x20\xf0\x9f\xa7\xaa The Alchemical Circle; and the Adventurers Guild.
• Preserve privacy by restricting review actions and avoid exposing private submissions publicly beyond the configured review channel and applicant communications.
• The lore assistant must clearly distinguish official lore from generated suggestions and must avoid inventing canon.
• The Discord bot token must be configured securely.
• The faction/guild application workflow is configurable per group.

Assumptions (narrow, labeled).

• [Assumption] The bot operates inside Discord servers where the Server Admin has the permissions needed to install and configure it.
• [Assumption] Application-owned identity is required so that a participant's submissions, applications, reviews, and configuration remain bound to them and resumable; this is a required_inference from the accepted durable workflows.
• [Assumption] The web surface and the Discord bot share the same persistence so that a submission made in Discord is visible in the web review queue and vice versa.
• [Assumption] Generated lore restatements are produced by a language model grounded strictly in the staff-managed official source; the source remains authoritative.
• [Assumption] The seven faction emoji are used only inside Discord-side copy and never as visual marks in the web interface.

Explicit exclusions.

• No reuse or migration of code from the existing Discord Chatbot project.
• No photographic or illustrated character art in the web surface.
• No blue, indigo, or violet in UI chrome.
• No future-horizon features are accepted; nothing in this document commits to adjacent account-management, moderation, or analytics capabilities.

12. Glossary

• OC (Original Character): A player-authored character submitted to the server through the interactive form and reviewed by staff.
• Archive ID: The numbered identifier assigned to each submission or application, rendered in tabular numerals at the top-right of its review card.
• Review channel: The admin-configurable Discord channel where OC submissions are posted for staff review.
• Faction/Guild: One of the seven configured groups:\x20\xf0\x9f\x93\x9a The Eternal Archive;\x20\xf0\x9f\x8c\x91 The Umbral Covenant;\x20\xf0\x9f\x97\xa1️ The Iron Vanguard;\x20\xf0\x9f\x94\xae The Arcane Conclave;\x20\xf0\x9f\x8f\xb9 The Verdant Wardens;\x20\xf0\x9f\xa7\xaa The Alchemical Circle; and the Adventurers Guild.
• Per-group workflow: The independently configurable application process for each faction or guild.
• Official lore: Lore entries managed by staff in the editable source; the authoritative basis for assistant answers.
• Generated suggestion: An assistant restatement derived from official lore; labelled GENERATED and never presented as canon.
• Provenance diagram: The thin-line schematic showing Source → Excerpt → Assistant restatement.
• Sealed record: A submission or application that has received a decision, marked by the 400ms ember pulse along its card's top edge.
• Server Admin: The participant who configures the bot for a Discord server, including the review channel, per-group workflows, lore source, and bot token.
• Staff Reviewer: The participant who reviews OC submissions and uses roleplay support utilities.
• Faction/Guild Leader: The participant who decides applications for their own faction or guild.
• Player: The participant who submits characters, applies to factions and guilds, discovers lore, and uses roleplay support.