System Requirements Document for minecraft-clubnetwork

1. Introduction

minecraft-clubnetwork is a Minecraft server store website named Clubnetwork. It exists so that Minecraft players can browse and buy two kinds of store items — GEMS (in-game currency) and ranks — and sign in with nothing but their Minecraft username.

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

• A store website for the Clubnetwork Minecraft server.
• Green is the required theme colour; other colours are permitted as long as green is present.
• The store offers GEMS and ranks.
• A login modal exists that uses only a Minecraft username — no password.
• For the Bedrock section, the username is prefixed with a period (.).

The audience is Minecraft players on both Java Edition and Bedrock Edition, who arrive at the store to see what GEMS and ranks are available and to complete a purchase for their own Minecraft account.

2. System Overview

Clubnetwork is a first-party web store with a public, anonymous entry surface and a small set of catalogue and purchase surfaces. Visitors can read the store without identifying themselves; identifying themselves is required only to complete a purchase.

Current delivery

• A public Landing surface that introduces the Clubnetwork store and routes visitors to the GEMS catalogue or the Ranks catalogue.
• Two separate catalogue surfaces, GEMS and Ranks, each browsable without login.
• A Login modal that verifies a player using only their Minecraft username, with a Java/Bedrock distinction where Bedrock usernames carry a leading ..
• A Checkout surface where a logged-in player completes the purchase of the selected GEMS or rank.

Actors

• Minecraft Player (Java Edition) — browses GEMS and ranks, logs in with a plain Minecraft username, and buys for a Java account.
• Minecraft Player (Bedrock Edition) — does the same, but their username is prefixed with . to mark a Bedrock account.

Ownership and access

• The Landing, GEMS, and Ranks surfaces are openly reachable; no identity is needed to read the catalogue.
• The Login modal is the first-party identity surface. It is reachable anonymously because it is the interaction that establishes access; it does not itself require prior access.
• Checkout requires a logged-in player, because a purchase must be bound to the correct Minecraft account.

Narrow exclusions

• No password field, no email field, and no social-login buttons exist in the login modal. Login is username-only.
• No account-management capabilities beyond establishing and re-establishing the username identity needed to complete a purchase are in scope.

2a. Product Interpretation and Delivery Boundary

Clubnetwork is delivered as a first-party web store owned and operated by the Clubnetwork server. The store's own surfaces carry the catalogue, the login modal, and the checkout completion. There is no provider-owned storefront and no external marketplace in the accepted scope.

Access is deliberately asymmetric. Reading the store — the Landing page, the GEMS catalogue, the Ranks catalogue — is open to anyone. Buying is not: a purchase must be attached to a real Minecraft account, so the player identifies themselves through the username-only login modal before Checkout can complete. That identity is application-owned and persists so a returning player can resume and complete a purchase under the same Minecraft username.

The Java/Bedrock distinction is a first-class part of the store, not a footnote. Bedrock usernames are written with a leading . so the store can tell a Bedrock account from a Java account at a glance, and the store enforces that prefix in the Bedrock section.

Everything described in this document is current. No future-horizon features are accepted in the authoritative requirement thread, so none are specified here.

2c. Page Content and Component Coverage

Landing

• Information and state: Clubnetwork wordmark and store identity; a short plain-language statement that this is the Clubnetwork Minecraft store selling GEMS and ranks for Java and Bedrock players; the two catalogue entry points; the current login state (anonymous or logged in as a given Minecraft username).
• Primary actions: Go to the GEMS catalogue; go to the Ranks catalogue; open the Login modal.
• Supporting actions: Switch the Java/Bedrock context so the store knows which edition the visitor plays on; view the current cart count.
• Domain entities: Store identity (Clubnetwork), catalogue category (GEMS, Ranks), edition (Java, Bedrock), player session (anonymous or identified by Minecraft username).
• Component responsibilities: A viewport-spanning slab wordmark; a badge cluster representing GEMS, a rank tier, and the Bedrock . chip; a ruled strip reading the store's offering; two rectangular CTA plates routing to GEMS and Ranks; a Java/Bedrock segmented switch; a persistent left rail carrying the Clubnetwork badge, the Java/Bedrock toggle, and the cart count; a marquee of example usernames along the bottom rule.
• States:
  • Loading: the wordmark, ruled strip, and CTA plates render immediately as static structure; no catalogue data is required for the Landing surface to be usable.
  • Empty: not applicable — the Landing surface has no collection to be empty.
  • Success: the visitor reaches Landing, understands that Clubnetwork sells GEMS and ranks for Java and Bedrock, and can move to either catalogue or open Login.
  • Error: if a catalogue entry point cannot be reached, the Landing surface keeps the visitor in place and shows a plain message that the catalogue is unavailable, with a retry.
  • Recovery: the visitor can retry the catalogue entry, or open Login directly, without losing their place on Landing.

GEMS

• Information and state: The GEMS catalogue for Clubnetwork; each GEMS offering with its name, its GEMS amount, and its price; the current edition context (Java or Bedrock); the current login state; the cart contents and count.
• Primary actions: Add a GEMS offering to the cart; open the Login modal; proceed toward Checkout.
• Supporting actions: Switch the Java/Bedrock context; remove an item from the cart; return to Landing; move to the Ranks catalogue.
• Domain entities: GEMS offering (name, GEMS amount, price), cart, cart line, edition, player session.
• Component responsibilities: A badge-header identifying the GEMS catalogue; a ruled product grid of stamped badge cards, each with an all-caps title bar, a circular GEMS token, the GEMS amount, the price, and an add-to-cart plate; the Java/Bedrock segmented switch; the persistent left rail with badge, toggle, and cart count; numbered ruled section dividers.
• States:
  • Loading: the badge-header and grid frame render first; each card shows a placeholder in the shape of its title bar, token, amount, and price until the offering data arrives.
  • Empty: if no GEMS offerings are available, the catalogue shows a plain message that no GEMS are currently on offer, with a route back to Landing and across to Ranks.
  • Success: the player sees the available GEMS offerings with their amounts and prices, and an added offering appears in the cart with the cart count incremented.
  • Error: if the GEMS catalogue cannot be loaded, the surface shows a plain failure message and a retry; if adding an offering fails, the card returns to its resting state and the player is told the item was not added.
  • Recovery: retry the catalogue load; retry the add; the player's edition context and cart are preserved across the retry.

Ranks

• Information and state: The ranks catalogue for Clubnetwork; each rank with its name, its tier, and its price; the current edition context (Java or Bedrock); the current login state; the cart contents and count.
• Primary actions: Add a rank to the cart; open the Login modal; proceed toward Checkout.
• Supporting actions: Switch the Java/Bedrock context; remove an item from the cart; return to Landing; move to the GEMS catalogue.
• Domain entities: Rank (name, tier, price), cart, cart line, edition, player session.
• Component responsibilities: A badge-header identifying the Ranks catalogue; a ruled product grid of stamped badge cards, each with an all-caps title bar, an illustrated chevron shield for the tier, the price, and an add-to-cart plate; the Java/Bedrock segmented switch; the persistent left rail with badge, toggle, and cart count; numbered ruled section dividers.
• States:
  • Loading: the badge-header and grid frame render first; each card shows a placeholder in the shape of its title bar, shield, and price until the rank data arrives.
  • Empty: if no ranks are available, the catalogue shows a plain message that no ranks are currently on offer, with a route back to Landing and across to GEMS.
  • Success: the player sees the available ranks with their tiers and prices, and an added rank appears in the cart with the cart count incremented.
  • Error: if the ranks catalogue cannot be loaded, the surface shows a plain failure message and a retry; if adding a rank fails, the card returns to its resting state and the player is told the rank was not added.
  • Recovery: retry the catalogue load; retry the add; the player's edition context and cart are preserved across the retry.

Login

• Information and state: The login modal presented as a kraft-paper insert on a moss panel; a Java/Bedrock segmented switch at the top; a single Minecraft username field; the current edition context; the current login state; validation state for the username.
• Primary actions: Submit the Minecraft username to log in; switch between Java and Bedrock.
• Supporting actions: Close the modal and return to the surface that opened it; correct the username after a validation or verification failure.
• Domain entities: Minecraft username, edition (Java, Bedrock), Bedrock . prefix, player session.
• Component responsibilities: A torn-edge cream strip stamped with the login heading; the Java/Bedrock segmented switch; one username field with no password field, no email field, and no social buttons; an amber . prefix chip that appears on the Bedrock plate and auto-prefixes the field with a visible lock chip; a lime submit plate; inline validation messaging.
• States:
  • Loading: the modal opens immediately with its frame, switch, and field; the submit plate shows a pending state while the username is being verified.
  • Empty: the username field starts empty with the edition-appropriate placeholder; submitting an empty field is rejected inline without leaving the modal.
  • Success: the username is accepted, the modal closes, and the store shows the player as logged in under that Minecraft username; the player returns to the surface they came from with their cart intact.
  • Error: an empty or malformed username is rejected inline; a username that cannot be verified is rejected with a plain message and the field stays editable; on the Bedrock plate, a username missing the leading . is rejected with a message naming the required prefix.
  • Recovery: the player edits the username and resubmits without reopening the modal; switching the Java/Bedrock switch re-applies the correct prefix rule and placeholder so the player can correct an edition mistake.

Checkout

• Information and state: The selected GEMS or rank items with their names, amounts or tiers, and prices; the total; the Minecraft username the purchase will be applied to; the edition (Java or Bedrock); the current login state.
• Primary actions: Confirm and complete the purchase of the selected GEMS or rank for the identified Minecraft username.
• Supporting actions: Return to the catalogue to change the selection; remove an item; open the Login modal if the session is not established.
• Domain entities: Cart, cart line, order, total, Minecraft username, edition, player session.
• Component responsibilities: A ruled order panel listing each selected item with its amount or tier and price; a kraft-paper receipt strip showing the total and the target Minecraft username with its edition marker; a lime confirm plate; a route back to the catalogue.
• States:
  • Loading: the order panel renders from the cart immediately; the confirm plate shows a pending state while the purchase is being completed.
  • Empty: if the cart is empty, Checkout shows a plain message that there is nothing to buy yet, with routes to the GEMS and Ranks catalogues.
  • Success: the purchase completes, the order is recorded against the identified Minecraft username, and the player sees a confirmation naming the items bought and the account they were applied to.
  • Error: if the player is not logged in, Checkout does not complete and directs them to the Login modal; if the purchase fails, the order panel is preserved, the player is told the purchase did not go through, and they can retry.
  • Recovery: after a failed purchase the player can retry the same order, return to the catalogue to change it, or re-open Login if the session was lost — in every case the cart contents are preserved.

3. Functional Requirements

Each requirement below is a distinct story point. Provenance is marked explicit (stated by the user), basic_default (accepted default), or required_inference (indispensable mechanics needed to make an accepted outcome usable).

FR-1 — Clubnetwork store identity As a Minecraft Player (Java Edition) or Minecraft Player (Bedrock Edition), I should arrive at a store website named Clubnetwork so that I know I am in the Clubnetwork server's store.

• Provenance: explicit
• Trigger/input: the player opens the Clubnetwork store.
• Observable result: the store presents itself as Clubnetwork.
• Access state: anonymous.
• Failure/recovery: if the store cannot be reached, the player can retry.
• Continuation: the player proceeds to browse GEMS or ranks.

FR-2 — Green theme with green present As a Minecraft Player (Java Edition) or Minecraft Player (Bedrock Edition), I should see a store themed in green so that the store reads as Clubnetwork's green-themed store.

• Provenance: explicit
• Trigger/input: any store surface is rendered.
• Observable result: green is present in the store's theme; other colours may also appear.
• Access state: any.
• Failure/recovery: not applicable to a presentation constraint.
• Continuation: the player continues browsing.

FR-3 — GEMS available in the store As a Minecraft Player (Java Edition) or Minecraft Player (Bedrock Edition), I should see the GEMS available in the Clubnetwork store so that I can choose which GEMS to buy.

• Provenance: explicit
• Trigger/input: the player opens the GEMS catalogue.
• Observable result: the available GEMS offerings are listed with their amounts and prices.
• Access state: anonymous browsing is sufficient to view GEMS.
• Failure/recovery: if the GEMS catalogue fails to load, the player sees a plain failure message and can retry.
• Continuation: the player adds a GEMS offering to the cart or returns to Landing.

FR-4 — Ranks available in the store As a Minecraft Player (Java Edition) or Minecraft Player (Bedrock Edition), I should see the ranks available in the Clubnetwork store so that I can choose which rank to buy.

• Provenance: explicit
• Trigger/input: the player opens the Ranks catalogue.
• Observable result: the available ranks are listed with their tiers and prices.
• Access state: anonymous browsing is sufficient to view ranks.
• Failure/recovery: if the ranks catalogue fails to load, the player sees a plain failure message and can retry.
• Continuation: the player adds a rank to the cart or returns to Landing.

FR-5 — Login modal using only a Minecraft username As a Minecraft Player (Java Edition) or Minecraft Player (Bedrock Edition), I should log in through a modal that asks only for my Minecraft username so that I can identify myself without a password.

• Provenance: explicit
• Trigger/input: the player opens the Login modal and submits their Minecraft username.
• Observable result: the modal accepts a Minecraft username and no password; on success the player is logged in under that username.
• Access state: the modal is reachable anonymously because it is the interaction that establishes access.
• Failure/recovery: an empty or unverifiable username is rejected inline with a plain message, and the player can correct and resubmit without reopening the modal.
• Continuation: the player returns to the surface they came from with their cart intact.

FR-6 — No password, email, or social login As a Minecraft Player (Java Edition) or Minecraft Player (Bedrock Edition), I should not be asked for a password, an email address, or a social account so that logging in stays username-only.

• Provenance: explicit
• Trigger/input: the Login modal is opened.
• Observable result: the modal contains a username field and no password field, no email field, and no social-login buttons.
• Access state: anonymous.
• Failure/recovery: not applicable — this is a constraint on the modal's contents.
• Continuation: the player submits their username.

FR-7 — Bedrock usernames are prefixed with a period As a Minecraft Player (Bedrock Edition), I should have my username written with a leading period (.) in the Bedrock section so that my Bedrock account is distinguished from a Java account.

• Provenance: explicit
• Trigger/input: the player is in the Bedrock section and enters or views a username.
• Observable result: the username carries a leading .; the Bedrock plate shows the . prefix chip and the field auto-prefixes . with a visible lock chip.
• Access state: anonymous.
• Failure/recovery: a Bedrock username submitted without the leading . is rejected with a message naming the required prefix, and the player can correct it.
• Continuation: the corrected username is submitted and the player is logged in.

FR-8 — Java/Bedrock edition selection As a Minecraft Player (Java Edition) or Minecraft Player (Bedrock Edition), I should be able to indicate whether I play Java or Bedrock so that the store applies the right username rule and records my purchase against the right account.

• Provenance: required_inference
• Trigger/input: the player uses the Java/Bedrock segmented switch on the header, in the Login modal, or on a catalogue page.
• Observable result: the store's edition context changes; on Bedrock the . prefix rule and chip apply, on Java they do not.
• Access state: anonymous.
• Failure/recovery: switching the edition re-applies the correct prefix rule and placeholder so an edition mistake can be corrected.
• Continuation: the player continues browsing or submits their username under the corrected edition.

FR-9 — Browsing the catalogue without logging in As a Minecraft Player (Java Edition) or Minecraft Player (Bedrock Edition), I should be able to read the GEMS and ranks catalogues before logging in so that I can decide what to buy first.

• Provenance: required_inference
• Trigger/input: the player opens Landing, GEMS, or Ranks without a session.
• Observable result: the catalogues are readable and their items and prices are visible.
• Access state: anonymous.
• Failure/recovery: if a catalogue fails to load, the player sees a plain failure message and can retry.
• Continuation: the player opens the Login modal when ready to buy.

FR-10 — Adding GEMS or a rank to the cart As a Minecraft Player (Java Edition) or Minecraft Player (Bedrock Edition), I should be able to add a GEMS offering or a rank to my cart so that I can assemble the purchase I want.

• Provenance: required_inference
• Trigger/input: the player activates the add-to-cart plate on a GEMS or rank card.
• Observable result: the item appears in the cart and the cart count increments.
• Access state: anonymous.
• Failure/recovery: if the add fails, the card returns to its resting state and the player is told the item was not added; the player can retry.
• Continuation: the player adds more items or proceeds toward Checkout.

FR-11 — Purchase requires login As a Minecraft Player (Java Edition) or Minecraft Player (Bedrock Edition), I should be required to log in before a purchase can be completed so that the GEMS or rank is applied to the correct Minecraft account.

• Provenance: required_inference
• Trigger/input: the player attempts to complete a purchase without an established session.
• Observable result: Checkout does not complete and the player is directed to the Login modal.
• Access state: Checkout requires login; the Login modal itself remains anonymously reachable.
• Failure/recovery: after logging in, the player returns to Checkout with the cart preserved.
• Continuation: the player completes the purchase.

FR-12 — Completing the purchase of GEMS or a rank As a Minecraft Player (Java Edition) or Minecraft Player (Bedrock Edition), I should complete the purchase of my selected GEMS or rank for my Minecraft username so that I receive what I bought on my account.

• Provenance: required_inference
• Trigger/input: the logged-in player confirms the order on Checkout.
• Observable result: the purchase completes, the order is recorded against the identified Minecraft username and edition, and the player sees a confirmation naming the items bought and the account they were applied to.
• Access state: login required.
• Failure/recovery: if the purchase fails, the order panel is preserved, the player is told the purchase did not go through, and they can retry, change the selection, or re-open Login if the session was lost.
• Continuation: the player sees the confirmation and can return to the catalogue.

FR-13 — Returning player resumes under the same username As a Minecraft Player (Java Edition) or Minecraft Player (Bedrock Edition), I should be able to log in again with the same Minecraft username so that my cart and purchase continue under the same account.

• Provenance: required_inference
• Trigger/input: a returning player opens the Login modal and submits their Minecraft username.
• Observable result: the player is logged in under that username and their cart is intact.
• Access state: the modal is anonymously reachable; the resumed state is the player's own.
• Failure/recovery: an unverifiable username is rejected inline and the player can correct and resubmit.
• Continuation: the player proceeds to Checkout.

4. User Personas

Minecraft Player (Java Edition)

Product context. This player plays on the Clubnetwork Minecraft server through Java Edition. They arrive at the Clubnetwork store from the server community — a link, a chat mention, a Discord post — already knowing what GEMS and ranks are, and they read the store as part of the server's world rather than as a generic shop.

Primary goal. To see what GEMS and ranks Clubnetwork offers, log in with nothing but their Minecraft username, and complete a purchase that lands on their Java account.

Distinct accepted responsibilities. This player browses the GEMS catalogue and the Ranks catalogue, chooses offerings, adds them to a cart, identifies themselves through the username-only login modal, and confirms the purchase on Checkout. Their distinguishing responsibility is the Java side of the edition split: their username is written plainly, with no leading period, and the store must not apply the Bedrock prefix rule to them.

Relevant inputs and decisions. Their Minecraft username; which catalogue to browse (GEMS or Ranks); which offerings to add; whether to log in now or keep browsing; whether to confirm or change the order at Checkout.

Interactions with other accepted participants. They share the store with Minecraft Player (Bedrock Edition). Both use the same Landing, GEMS, Ranks, Login, and Checkout surfaces; the edition switch is what keeps their identities apart. Neither player sees or acts on the other's session, cart, or order.

Observable success. The player is logged in under their Java Minecraft username without ever entering a password, and sees a confirmation that their GEMS or rank purchase was applied to that account.

Minecraft Player (Bedrock Edition)

Product context. This player plays on the Clubnetwork Minecraft server through Bedrock Edition — on a phone, a console, or Windows. They use the same store as Java players but their account is a Bedrock account, which the store marks with a leading period on the username.

Primary goal. To browse GEMS and ranks, log in with their Bedrock username written with the leading ., and complete a purchase that lands on their Bedrock account.

Distinct accepted responsibilities. This player browses both catalogues, adds offerings to a cart, and identifies themselves through the same username-only login modal — but on the Bedrock plate, where the . prefix chip is shown, the field auto-prefixes . with a visible lock chip, and a username submitted without the leading . is rejected. Their distinguishing responsibility is getting the Bedrock prefix right so the purchase is bound to the correct account.

Relevant inputs and decisions. Their Bedrock Minecraft username including the leading .; which catalogue to browse; which offerings to add; whether to log in now or keep browsing; whether to confirm or change the order at Checkout.

Interactions with other accepted participants. They share every store surface with Minecraft Player (Java Edition). The Java/Bedrock segmented switch is the shared control that separates the two, and it appears in the header, in the login modal, and on each catalogue page so a Bedrock player is never left guessing which rule applies.

Observable success. The player is logged in under their Bedrock username with its leading . intact, without a password, and sees a confirmation that their GEMS or rank purchase was applied to that Bedrock account.

5. Core User Flows

Flow A — Java player browses GEMS and buys

1. The Minecraft Player (Java Edition) opens the Clubnetwork store and lands on Landing. They see the Clubnetwork wordmark, the ruled strip naming GEMS, ranks, and Java & Bedrock, and the two CTA plates.
2. They confirm the Java/Bedrock segmented switch is set to Java, so no . prefix rule applies to them.
3. They activate the GEMS CTA plate and arrive on the GEMS catalogue. The badge-header and ruled product grid render; each card shows a GEMS token, an amount, and a price.
4. They choose a GEMS offering and activate its add-to-cart plate. The card presses in and back out, the item appears in the cart, and the cart count in the left rail increments.
5. They activate the Login entry point. The Login modal opens as a kraft-paper insert on a moss panel, with the Java/Bedrock switch at the top and a single username field — no password field, no email field, no social buttons.
6. They type their Minecraft username and submit. The submit plate shows a pending state while the username is verified.
7. Success: the username is accepted, the modal closes, and the store shows them logged in under that Java username. They return to the GEMS catalogue with their cart intact.
8. They proceed to Checkout. The order panel lists the GEMS offering with its amount and price, and the kraft-paper receipt strip shows the total and the target Minecraft username with its Java edition marker.
9. They confirm the purchase. The confirm plate shows a pending state, then the purchase completes and they see a confirmation naming the GEMS bought and the Java account they were applied to.
10. Continuation: they return to the catalogue to buy more, or leave the store.

Failure and recovery in this flow. If the GEMS catalogue fails to load at step 3, they see a plain failure message and a retry, and their edition context is preserved. If the add at step 4 fails, the card returns to rest and they are told the item was not added; they can retry. If their username cannot be verified at step 6, the modal keeps the field editable and shows a plain message, and they correct and resubmit without reopening the modal. If the purchase fails at step 9, the order panel is preserved, they are told it did not go through, and they can retry the same order or return to the catalogue to change it.

Flow B — Bedrock player browses ranks and buys

1. The Minecraft Player (Bedrock Edition) opens the Clubnetwork store and lands on Landing.
2. They set the Java/Bedrock segmented switch to Bedrock. The Bedrock plate now shows the amber . prefix chip.
3. They activate the Ranks CTA plate and arrive on the Ranks catalogue. The badge-header and ruled product grid render; each card shows an illustrated chevron shield for its tier and a price.
4. They choose a rank and activate its add-to-cart plate. The card presses in and back out, the rank appears in the cart, and the cart count increments.
5. They activate the Login entry point. The Login modal opens with the Java/Bedrock switch already on Bedrock; the username field auto-prefixes . and shows the visible lock chip.
6. They type their Bedrock username. If they type it without the leading ., the field rejects it with a message naming the required prefix; they correct it and the . is present.
7. They submit. The submit plate shows a pending state while the username is verified.
8. Success: the username is accepted with its leading . intact, the modal closes, and the store shows them logged in under that Bedrock username. They return to the Ranks catalogue with their cart intact.
9. They proceed to Checkout. The order panel lists the rank with its tier and price, and the receipt strip shows the total and the target Bedrock username with its . marker.
10. They confirm the purchase. The purchase completes and they see a confirmation naming the rank bought and the Bedrock account it was applied to.
11. Continuation: they return to the catalogue to buy more, or leave the store.

Failure and recovery in this flow. If they set the switch to Bedrock but then submit a Java-style username at step 6, the prefix rejection tells them exactly what is missing and they correct it in place. If the ranks catalogue fails to load at step 3, they see a plain failure message and a retry. If the purchase fails at step 10, the order panel is preserved and they can retry, change the selection, or re-open Login if the session was lost — the cart survives in every case.

Flow C — Player browses without logging in, then decides to buy

1. A Minecraft Player (Java Edition) or Minecraft Player (Bedrock Edition) opens Landing and reads the store without identifying themselves.
2. They move between the GEMS and Ranks catalogues freely, comparing amounts, tiers, and prices. No login is required to read either catalogue.
3. They add one or more offerings to the cart. The cart count in the left rail tracks their selection.
4. They attempt to proceed to Checkout. Because no session is established, Checkout does not complete and directs them to the Login modal.
5. They log in with their Minecraft username under the correct edition — plain for Java, leading . for Bedrock.
6. Success: they return to Checkout with their cart preserved and complete the purchase as in Flow A or Flow B.
7. Continuation: they see the confirmation and can return to the catalogue.

Failure and recovery in this flow. If they abandon the login at step 5, the cart is preserved and they can resume later by logging in with the same Minecraft username. If the session is lost before step 6, Checkout again directs them to Login and the cart is still intact.

Flow D — Returning player resumes under the same username

1. A Minecraft Player (Java Edition) or Minecraft Player (Bedrock Edition) who has bought before returns to the Clubnetwork store.
2. They open the Login modal from the header or from a catalogue page.
3. They submit the same Minecraft username they used before, under the same edition.
4. Success: they are logged in under that username and their cart is intact.
5. Continuation: they proceed to Checkout to complete a purchase, or browse the catalogues first.

Failure and recovery in this flow. If the username cannot be verified, the modal keeps the field editable and shows a plain message; they correct it and resubmit. If they submit under the wrong edition — a Bedrock username without the leading ., or a Java username on the Bedrock plate — the prefix rule rejects it and tells them what is required.

6. Visuals, Colors and Theme

Muse and headline. The visual direction is Aaron Draplin — bold, honest, hand-built. The headline idea: a Minecraft store that reads like a stamped field-notes catalogue, not a SaaS checkout. Green is the explicit theme, so the palette is built from Minecraft's own biomes: deep forest ground, moss surfaces, and a hot lime signal for currency and CTAs.

Colour tokens (dark mode)

Hot lime is used as flat fills and 2–3px outlines, never as a gradient. Lime text is never placed on the moss surface below 18px — off-white is used there instead.

Typography

• Headings: Alfa Slab One, all-caps, tight tracking (−0.01em) — badges, section titles, the hero wordmark.
• Eyebrows and labels: Barlow Condensed 700, all-caps, 0.14em letterspacing.
• Body: Barlow 400/500, 17px base, 1.6 line-height, sentence case, plain talk.
• Prices and GEMS amounts: Barlow Condensed 700, tabular numerals, display size.
• Scale: 1.333 modular, fluid — hero clamp(44px, 9vw, 128px); section title clamp(30px, 4.5vw, 56px); card title 22px; eyebrow/label 12px all-caps; body 17px; meta 14px.

Shape language. Hard-edged and stamped: 3px solid borders, 6px corner radius maximum, chunky 2px inner rules. Badge shapes are a rounded-rectangle plate with a punched-out circle or chevron. No soft pill buttons — buttons are rectangular plates with a 3px border and a 4px offset hard shadow with no blur. Sticker-like circular GEMS tokens and rank chevrons. Kraft-paper inserts with a torn top edge. Diagonal hazard bands appear only as section dividers, never behind readable text.

Layout. Poster-like single column at 375px, expanding to a 12-column ruled grid at 1280px with visible 1px column rules and a persistent left rail carrying the Clubnetwork badge, the Java/Bedrock toggle, and the cart count. Sections are separated by thick 3px rules and all-caps numbered eyebrows (01 CATALOGUE, 02 GEMS, 03 RANKS, 04 LOGIN). GEMS and Ranks are separate pages with their own badge-header. Product grids are 1-up mobile / 2-up tablet / 3-up desktop with 24–32px gutters; every card is a ruled panel with an all-caps title bar, not a floating rounded card. Login is a modal, not a page: a moss panel with a heavy border, a Java/Bedrock segmented switch at the top, and a single username field.

Imagery. Thick-line vector badges and pictograms drawn in 3–4px strokes, halftone-dotted Minecraft-style block textures, isometric cubes and pickaxe/diamond/emerald glyphs, and a single big blocky hero illustration built from flat colour planes. No screenshots of a UI, no stock photography, no glossy 3D renders, no soft gradient blobs. Rank tiers get illustrated chevron shields; GEMS get a circular token with a cut diamond mark.

Readable text and controls. Headlines, wordmarks, labels, numbers, card text, and controls stay entirely inside the viewport and their container at 375px, 768px, and 1280px, wrapping or scaling to fit, and no other element covers any part of them. Imagery, decoration, and motion may be cropped, bled off an edge, rotated, overlapped, or cut as the direction asks, as long as they cover no readable text or control. Moving content may cross the viewport edge by design and is judged by whether it actually moves and whether every item becomes fully readable as it passes.

7. Signature Design Concept

The Clubnetwork poster. The public entry is a full-width forest-green field (#12241A) ruled by a 3px off-white line at the top and bottom. The wordmark CLUBNETWORK is set in Alfa Slab One at clamp(44px, 9vw, 128px), spanning the entire viewport width edge-to-edge, broken across two lines so the slab letters bleed into the left and right margins. To its right, a stacked amber-and-lime badge cluster — a circular GEMS token, a VIP chevron shield, and a .bedrock chip — sits on a moss panel (#1C3325) with a 3px border and a 6px hard shadow, overlapping the final letter of the wordmark by one grid column.

Beneath the wordmark, a ruled strip reads GEMS · RANKS · JAVA & BEDROCK in all-caps Barlow Condensed with 0.14em tracking. Two rectangular CTA plates sit flush left on the grid, not centred: BELI BELI GEMS filled lime with forest text, and LIHAT RANKS outlined off-white. A slow marquee of .Steve_Bedrock · AlexJava · .Notch_BE runs along the bottom rule.

Nothing is centred, nothing floats, and no gradient exists anywhere in the first screen. The hero is a poster, not a centred headline stack. Every element in it is composed from accepted content only — the store name, the two catalogue categories, the Java/Bedrock distinction, and the routes into GEMS, Ranks, and Login.

8. Interaction Model & Motion Direction

Interaction Model: Animated Motion Tempo: restrained Hero Dimensionality: flat

Landing Hero Motion Brief

• Focal subject: the viewport-spanning CLUBNETWORK slab wordmark and the overlapping badge cluster (GEMS token, VIP shield, .bedrock chip) on its moss panel.
• Input → transformation → outcome thesis: as the visitor arrives, the ruled top and bottom lines draw in and the slab wordmark settles into place; the badge cluster presses onto the moss panel and its hard shadow seats; the marquee of example usernames begins its slow horizontal pass along the bottom rule. The outcome is a composed poster that reads as stamped and finished, with the two CTA plates — BELI BELI GEMS and LIHAT RANKS — flush left and ready.
• Motion vocabulary: snap-in section reveals (translateY 16px, 240ms, cubic-bezier(0.2,0.8,0.2,1)) with no bounce; stamp-press on add-to-cart (scale 1 → 0.97 → 1 over 160ms) plus a hard-shadow shift; a slow horizontal marquee of the Clubnetwork wordmark and .username Bedrock examples along the top rule; hover on a badge lifts its hard shadow by 2px and shifts the border colour to lime. No parallax, no particles, no gradient drift.
• Composed first frame: forest-green field, 3px off-white rules top and bottom, the two-line slab wordmark bleeding into both margins, the badge cluster overlapping the final letter, the ruled offering strip beneath, the two CTA plates flush left, and the username marquee already moving along the bottom rule.
• Reduced-motion state: under prefers-reduced-motion all marquees stop and their items wrap into static rows; snap-in reveals resolve immediately to their final position; the stamp-press on add-to-cart resolves to a plain state change with no scale animation.

9. Non-Functional Requirements

NFR-1 — Green theme is mandatory The store's theme must contain green. Other colours are permitted alongside it. Provenance: explicit. Rationale: the user stated the store is green-themed and that green must be present.

NFR-2 — Username-only authentication The login modal must accept only a Minecraft username. No password field, no email field, and no social-login buttons may be present. Provenance: explicit. Rationale: the user stated the login modal uses only a Minecraft username.

NFR-3 — Bedrock prefix rule In the Bedrock section, usernames must be prefixed with a period (.). Provenance: explicit. Rationale: the user stated that for the Bedrock section the username has a . in front.

NFR-4 — Readable text and controls stay whole 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 to fit, with no other element covering any part of them. Provenance: basic_default (creative direction). Rationale: the store must be usable on the phones and consoles Bedrock players commonly use.

NFR-5 — Reduced-motion support Under prefers-reduced-motion, marquees must stop and their items must wrap into static rows or sit in a horizontally scrollable row whose further items are reached by scrolling. Provenance: basic_default (creative direction). Rationale: motion must not be a barrier to reading the store.

NFR-6 — Purchase bound to the correct account A completed purchase must be recorded against the Minecraft username and edition the player logged in with, so GEMS and ranks land on the right account. Provenance: required_inference. Rationale: a purchase that cannot be attributed to the correct Minecraft account does not deliver the accepted outcome.

NFR-7 — Cart and session continuity A player's cart must survive login, a failed purchase, and a lost session, so the player can resume and complete the purchase under the same Minecraft username. Provenance: required_inference. Rationale: without continuity, the accepted purchase journey cannot be completed after any interruption.

10. Tech Stack

• Frontend: React — a first-party web store with a public entry, two catalogue surfaces, a login modal, and a checkout surface.
• Backend: Python / FastAPI — serves the catalogue, verifies the Minecraft username, and records orders against the identified account.
• Storage: a persistent store for catalogue items (GEMS offerings, ranks), player sessions keyed by Minecraft username and edition, carts, and completed orders.
• Containerisation: Docker / docker-compose for local and single-host deployment.

Kubernetes is not required by any accepted requirement and is therefore not specified.

11. Assumptions and Constraints

Assumptions

• A1 — The store is a first-party Clubnetwork web store; no provider-owned storefront or external marketplace is in scope. [Assumption — required_inference]
• A2 — A player's Minecraft username is sufficient to identify them for the purpose of completing a purchase, because the user explicitly required username-only login. [Assumption — explicit]
• A3 — The Java/Bedrock distinction is carried by the leading . on Bedrock usernames, as the user specified. [Assumption — explicit]
• A4 — The store's catalogue content (which GEMS and which ranks exist, their amounts, tiers, and prices) is supplied by the Clubnetwork server and is not fixed by the requirement thread. [Assumption — required_inference]
• A5 — The store's interface language follows the user's own phrasing, which is Indonesian; labels such as the CTA plates are written in that register. [Assumption — basic_default]

Constraints

• C1 — Login uses only a Minecraft username; there is no password. [explicit]
• C2 — In the Bedrock section, the username must be prefixed with a period (.). [explicit]
• C3 — The theme must contain green; other colours are free. [explicit]
• C4 — The store is named Clubnetwork. [explicit]
• C5 — The store offers GEMS and ranks. [explicit]
• C6 — A purchase cannot be completed without logging in. [required_inference]
• C7 — No account-management capabilities beyond establishing and re-establishing the username identity needed to complete a purchase are in scope. [required_inference]
• C8 — No future-horizon features are accepted; everything specified here is current. [explicit]

12. Glossary

• Clubnetwork — the Minecraft server whose store this website is.
• GEMS — the in-game currency sold in the Clubnetwork store.
• Rank — a purchasable status tier in the Clubnetwork store, distinguished by tier (for example VIP, ELITE, LEGEND).
• Java Edition — the Minecraft edition whose usernames are written plainly, with no leading period.
• Bedrock Edition — the Minecraft edition whose usernames are written with a leading period (.) in the Bedrock section.
• Bedrock prefix — the leading . that marks a Bedrock username, shown as an amber chip and auto-applied to the username field with a visible lock chip.
• Login modal — the first-party modal that identifies a player using only their Minecraft username, with no password.
• Edition switch — the Java/Bedrock segmented switch present in the header, in the login modal, and on each catalogue page.
• Cart — the player's current selection of GEMS and ranks awaiting purchase.
• Checkout — the surface where a logged-in player confirms and completes the purchase of their selected GEMS or rank.