System Requirements Document for mod-minecraft

1. Introduction

mod-minecraft is a web platform for sharing Minecraft mods. It exists so that players and creators can post mod files on a public wall and pull them back down again: a creator uploads a mod file with its information, and any visitor can browse, inspect, and download that mod.

The product intent is deliberately narrow and comes directly from the request: "Buatkan saya web upload dan donlowad mod minecraft" — build a web for uploading and downloading Minecraft mods. Everything in this document serves those two verbs. The platform is not a launcher, not a mod loader, not a hosting panel for servers, and not a social network; it is the wall where mod files are posted and the shelf where they are taken from.

The audience is the Minecraft modding community: young, technical, irreverent, and tribal. They arrive with a .jar in hand wanting to share it, or with a search term in mind wanting a file. The interface is built for that audience — loud, poster-like, high-contrast, and fast to read — rather than for a generic enterprise file list.

2. System Overview

mod-minecraft is a first-party web application with a custom interface and application-owned identity. It has two active human participants: the Pengunggah Mod (Mod Uploader), who posts mod files, and the Pengundur Mod (Mod Downloader), who finds and takes them. Both are served by the same public catalogue; only the upload workspace is restricted to a verified uploader.

The current delivery consists of six pages in a fixed order and with fixed access:

Browsing, searching, viewing mod details, and downloading a mod file require no account at all. Identity exists only because an uploader must privately own, resume, and manage the mods they have posted, and because a posted mod must remain bound to the correct creator. A backend stores the mod file and its information so that it is available for browsing and downloading.

Narrow exclusions. This document does not add mod installation, mod loading, game launching, server hosting, comments, ratings, following, messaging, payments, or moderation workflows. None of these were requested, and none are implied by uploading and downloading a file.

2a. Product Interpretation and Delivery Boundary

The whole product is delivered as a first-party web application with custom UI. There is no provider-owned surface, no external destination, and no headless-only delivery in the current scope.

Access ownership. The Landing, Mods, and Mod Details pages are public and anonymous: a visitor can read the catalogue and download a file without ever identifying themselves. Login and Sign Up are the anonymous entry boundaries for identity — they are reachable without being signed in, because a page cannot own the interaction that grants access to itself. Upload Mod is the only protected destination, and it is protected because the work there is durable, creator-specific, and must remain bound to the right person.

Identity boundary. Identity is application-owned and established by self-service registration, because no provisioning or invitation boundary was specified for someone who wants to start uploading. Returning uploaders verify themselves through Login. Identity here is continuity, not permission tiers: there is no role-based visibility, no differentiated control over shared catalogue state, and no administrative layer. Every verified uploader has exactly the same standing.

Current vs. future. Everything described in Sections 3 through 5 is current. No future-horizon requirements were stated by the user; Section 11 records the boundaries that keep the current scope from drifting.

2b. Source Content Inventory

Not applicable. No reference directive in this project declares content_source authority, so no verified factual inventory is carried into this document.

2c. Page Content and Component Coverage

Landing

• Information and state. The public entry surface. It explains, in one screen, that this is a web for uploading, finding, and downloading Minecraft mods. It carries no user-specific state and no data fetched on behalf of an identity.
• Primary action. BROWSE MODS — a red slab that takes the visitor to the Mods catalogue.
• Supporting actions. UPLOAD A MOD — a slab that routes an anonymous visitor to Sign Up and a verified uploader to Upload Mod. LOG IN — a text link in the top bar for a returning uploader.
• Domain entities. None owned here; the page presents the product, not catalogue records.
• Component responsibilities. Top navigation bar (wordmark at left, three all-caps links, red upload slab at right). Full-bleed three-block type hero: UPLOAD on red, DOWNLOAD on black, MODS on yellow, each block filling the viewport width. A reversed-out supporting line, "Share your builds. Grab your files." A teaser mod card peeking in at the bottom edge.
• States. Loading: none — the page is static. Empty: not applicable. Success: the visitor reads the hero and chooses a slab. Error: not applicable. Recovery: not applicable.

Login

• Information and state. The anonymous verification surface for a returning Mod Uploader. It holds no catalogue data and reveals nothing about any account before verification succeeds.
• Primary action. Submit credentials to verify identity and continue to Upload Mod.
• Supporting actions. Navigate to Sign Up for a visitor who has no account yet. Return to Landing.
• Domain entities. Uploader identity (email and password).
• Component responsibilities. Single-column form framed by a thick red rule, with a reversed-out all-caps label column at left and inputs on black at right, separated by a 3px rule. Submit slab. Inline error region. Link to Sign Up.
• States. Loading: submit slab shows a pending state and the form is not double-submittable. Empty: fields start blank. Success: identity verified, the uploader lands on Upload Mod. Error: unrecognised credentials or a failed request show an inline message in the error region and the entered email is preserved. Recovery: the uploader can correct the entry and resubmit, or go to Sign Up.

Sign Up

• Information and state. The anonymous self-service registration surface for someone who wants to become a Mod Uploader. No invitation or provisioning step exists.
• Primary action. Create the uploader identity and continue to Upload Mod.
• Supporting actions. Navigate to Login for someone who already has an account. Return to Landing.
• Domain entities. Uploader identity (email and password).
• Component responsibilities. Single-column form in the same poster treatment as Login: red rule, reversed-out label column, black input column, 3px separator. Submit slab. Inline validation and error region. Link to Login.
• States. Loading: submit slab shows a pending state and the form is not double-submittable. Empty: fields start blank. Success: identity created and verified, the uploader lands on Upload Mod. Error: an already-registered email or a failed request shows an inline message and preserves the entered email. Recovery: correct the entry and resubmit, or switch to Login.

Mods

• Information and state. The public catalogue of Minecraft mods. It shows the set of mods that have been uploaded and stored, each as a card carrying the mod name, a version tag, and a download count. It is readable by anyone, signed in or not.
• Primary action. Open a mod card to reach its Mod Details.
• Supporting actions. Search or filter the catalogue by mod name. Scroll the dense masonry of cards. Reach Upload Mod from the top bar.
• Domain entities. Mod (name, version, download count, card colour).
• Component responsibilities. Top navigation bar. Persistent yellow-on-black marquee band above the grid repeating NEW MODS — UPDATED — FEATURED. Search input. Dense masonry of rectangular mod cards, each a solid colour block drawn from the fixed palette of red, yellow, teal, and off-white, with the mod name in Anton, the version tag in yellow, and the download count in Space Grotesk. Empty-state block. Pagination or incremental loading control.
• States. Loading: card-shaped placeholders hold the masonry layout while the catalogue is fetched. Empty: a full-width block states that no mods have been posted yet and offers the upload path. Success: cards render with name, version, and download count. Error: a failed catalogue fetch shows a retry block in place of the grid. Recovery: retry re-requests the catalogue; a search that matches nothing shows a no-results block with a clear-search action.

Mod Details

• Information and state. The public record for one mod. It shows the mod's information — name, version, description, and download count — and is the place where a download begins. Readable by anyone.
• Primary action. DOWNLOAD — a red slab that retrieves the mod file to the visitor's device.
• Supporting actions. Return to Mods. Reach Upload Mod from the top bar.
• Domain entities. Mod (name, version, description, download count, file).
• Component responsibilities. Top navigation bar. Full-bleed type header with the mod name set large in Anton. Metadata block with version tag in yellow and download count in Space Grotesk. Description block. Flat pixel-art or blocky isometric preview icon in two or three colours where a preview exists. Red download slab. Error block for an unavailable mod.
• States. Loading: the header and metadata blocks hold their shape while the record is fetched. Empty: not applicable — a details page always describes one mod. Success: the record renders and the download slab is active; the download count reflects the completed download. Error: a mod that cannot be found or whose file is unavailable shows an error block with a route back to Mods. Recovery: return to Mods and choose another mod, or retry the download.

Upload Mod

• Information and state. The protected workspace where a verified Mod Uploader selects a file, fills in the mod's information, and makes it available to others. It is reachable only by a verified uploader; an unverified visitor is routed to Login or Sign Up first.
• Primary action. Submit the file and information to publish the mod.
• Supporting actions. Choose the mod file from the device. Fill in the mod name, version, and description. Review the entered information before submitting. Leave the workspace and return later.
• Domain entities. Mod (name, version, description, file), Uploader identity (owner of the mod).
• Component responsibilities. Two-column poster form: reversed-out all-caps labels in a red column at left, inputs on black at right, separated by a 3px rule. File picker showing the chosen filename and size. Text inputs for name, version, and description. Submit slab. Inline validation and error region. Confirmation block shown after a successful publish.
• States. Loading: the submit slab shows a pending state during the file transfer and the form is not double-submittable. Empty: the form starts blank with no file chosen. Success: a confirmation block states that the mod is published and offers a route to its Mod Details and to Mods. Error: a rejected file, a missing required field, or a failed transfer shows an inline message and preserves everything already entered. Recovery: correct the flagged field or reselect the file and resubmit without re-entering the rest of the form.

3. Functional Requirements

Each requirement is a distinct story point with its provenance, lifecycle facts, and observable acceptance.

FR-1 — Upload a Minecraft mod file As a Pengunggah Mod (Mod Uploader), I should be able to select a mod file from my device and submit it so that it becomes available for others to download.

• Provenance: explicit.
• Trigger/input: the uploader chooses a file from their device in the Upload Mod workspace.
• Observable result: the chosen file is transferred to the backend and stored together with its mod information.
• Access state: restricted to a verified Mod Uploader.
• Failure/recovery: if the file is rejected or the transfer fails, an inline message names the problem and everything already entered is preserved so the uploader can reselect and resubmit.
• Continuation: on success the uploader sees a confirmation and can open the new mod's Mod Details or return to Mods.

FR-2 — Provide mod information with the file As a Pengunggah Mod (Mod Uploader), I should be able to fill in the mod's name, version, and description so that downloaders know what they are getting.

• Provenance: explicit.
• Trigger/input: the uploader types the mod name, version, and description into the Upload Mod form.
• Observable result: the entered information is stored with the file and is displayed on the mod's card in Mods and on its Mod Details page.
• Access state: restricted to a verified Mod Uploader.
• Failure/recovery: a missing required field is flagged inline and the rest of the form is preserved.
• Continuation: the uploader submits the completed form.

FR-3 — Publish the mod to the public catalogue As a Pengunggah Mod (Mod Uploader), I should be able to publish my uploaded mod so that it appears in the catalogue for everyone.

• Provenance: explicit.
• Trigger/input: the uploader submits the completed Upload Mod form.
• Observable result: the mod appears as a card in Mods with its name, version, and download count, and its Mod Details page becomes reachable.
• Access state: restricted to a verified Mod Uploader.
• Failure/recovery: a failed publish leaves the mod unpublished and shows an inline error; the uploader can retry without re-entering the form.
• Continuation: the uploader is offered a route to the new mod's Mod Details and to Mods.

FR-4 — Browse the mod catalogue As a Pengundur Mod (Mod Downloader), I should be able to browse the list of uploaded Minecraft mods so that I can find something to download.

• Provenance: explicit.
• Trigger/input: the downloader opens Mods, from the Landing hero or the top navigation bar.
• Observable result: the catalogue renders as a dense masonry of mod cards, each showing the mod name, version tag, and download count.
• Access state: public — no identity required.
• Failure/recovery: a failed catalogue fetch shows a retry block in place of the grid.
• Continuation: the downloader opens a card to reach Mod Details.

FR-5 — Search the mod catalogue As a Pengundur Mod (Mod Downloader), I should be able to search the catalogue by mod name so that I can reach a specific mod quickly.

• Provenance: explicit.
• Trigger/input: the downloader types a term into the search input on Mods.
• Observable result: the grid narrows to the mods matching the term.
• Access state: public — no identity required.
• Failure/recovery: a term that matches nothing shows a no-results block with a clear-search action.
• Continuation: the downloader opens a matching card, or clears the search to see the full catalogue again.

FR-6 — Review a mod's details As a Pengundur Mod (Mod Downloader), I should be able to open a mod and read its information so that I can decide whether to download it.

• Provenance: explicit.
• Trigger/input: the downloader selects a mod card in Mods.
• Observable result: the Mod Details page shows the mod's name, version, description, and download count, with an active download slab.
• Access state: public — no identity required.
• Failure/recovery: a mod that cannot be found or whose file is unavailable shows an error block with a route back to Mods.
• Continuation: the downloader downloads the file or returns to Mods.

FR-7 — Download a mod file As a Pengundur Mod (Mod Downloader), I should be able to download the mod file to my device so that I can use it.

• Provenance: explicit.
• Trigger/input: the downloader activates the DOWNLOAD slab on Mod Details.
• Observable result: the mod file is retrieved to the downloader's device and the mod's download count reflects the completed download.
• Access state: public — no identity required.
• Failure/recovery: an unavailable file shows an error block with a route back to Mods; the downloader can retry the download.
• Continuation: the downloader returns to Mods to find another mod.

FR-8 — Establish an uploader identity by self-service registration As a Pengunggah Mod (Mod Uploader), I should be able to register myself before my first upload so that the mods I post belong to me.

• Provenance: required_inference.
• Trigger/input: an anonymous visitor who wants to upload opens Sign Up and submits an email and password.
• Observable result: an uploader identity is created and the uploader is taken to Upload Mod.
• Access state: anonymous entry — Sign Up is reachable without being signed in.
• Failure/recovery: an already-registered email or a failed request shows an inline message and preserves the entered email.
• Continuation: the uploader proceeds to Upload Mod, or switches to Login if the account already exists.

FR-9 — Verify identity on return As a Pengunggah Mod (Mod Uploader), I should be able to log in again so that I can reach and manage my upload flow.

• Provenance: required_inference.
• Trigger/input: a returning uploader opens Login and submits their credentials.
• Observable result: identity is verified and the uploader reaches Upload Mod.
• Access state: anonymous entry — Login is reachable without being signed in; Upload Mod remains unavailable until verification succeeds.
• Failure/recovery: unrecognised credentials or a failed request show an inline message and preserve the entered email so the uploader can correct and resubmit.
• Continuation: the uploader proceeds to Upload Mod.

FR-10 — Store mod files and information for later retrieval As the system, I should store each uploaded mod file together with its information so that it remains available for browsing and downloading.

• Provenance: required_inference.
• Trigger/input: a successful publish from Upload Mod.
• Observable result: the file and its name, version, description, and download count persist and are served to Mods, Mod Details, and the download action.
• Access state: system process — no human interacts with storage directly; the human-facing sides are owned by Upload Mod, Mods, and Mod Details.
• Failure/recovery: a storage failure prevents publication and surfaces as an inline error on Upload Mod rather than a silent loss.
• Continuation: the stored mod becomes visible in the catalogue.

4. User Personas

Pengunggah Mod (Mod Uploader)

Product context. This person has a Minecraft mod file on their device and wants to put it in front of other players. They are a creator or a sharer, not a shopper: they arrive with something in hand and need a place to post it. They may post once, or they may come back repeatedly with new versions and new builds.

Primary goal. Get the mod file and its information onto the wall so that other people can find it and download it.

Distinct accepted responsibilities. Choosing the mod file from their device; filling in the mod's name, version, and description; submitting the upload; and confirming that the mod is now available to others. This is the only participant who writes to the catalogue — the downloader only reads from it.

Relevant inputs and decisions. The file itself, and the metadata that will represent it: what the mod is called, which version it is, and how it should be described. The uploader also decides when the entry is complete enough to publish.

Interactions with other accepted participants. The uploader's work is the precondition for the downloader's. Nothing the downloader does is visible to the uploader in the current scope, and nothing the uploader does requires the downloader's involvement — the relationship is one-directional publication.

Observable success. The mod appears as a card in the Mods catalogue with its name, version, and download count, and its Mod Details page is reachable by anyone.

Constraints carried from source. Because the uploader's posted mods must remain bound to them and their upload flow must be resumable, this persona is the only one that establishes and verifies an identity. That identity is continuity, not rank: it grants no control over other people's mods and no differentiated visibility.

Pengundur Mod (Mod Downloader)

Product context. This person is looking for a mod file to take. They may arrive knowing exactly what they want, or they may be browsing to see what exists. They are the audience the catalogue is built for, and they are the reason the wall is public.

Primary goal. Find a mod and get its file onto their device.

Distinct accepted responsibilities. Browsing the catalogue, searching it by name, opening a mod to read its details, and downloading the file. This is the only participant who reads the catalogue and the only one who triggers a download.

Relevant inputs and decisions. A search term, or simply a scroll through the grid. The decision that matters is whether the mod they are looking at is the one they want — made from the name, version, description, and download count on Mod Details.

Interactions with other accepted participants. The downloader consumes what the uploader published. They never interact with the uploader directly, and they never need an identity to do their work.

Observable success. The mod file lands on their device and the mod's download count reflects it.

Constraints carried from source. Browsing, searching, viewing details, and downloading are all public. This persona is never asked to register or log in to accomplish any part of their goal.

5. Core User Flows

Flow A — A creator posts a mod for the first time

1. The visitor arrives on Landing and reads the three-block type wall: UPLOAD, DOWNLOAD, MODS.
2. They activate the UPLOAD A MOD slab. Because they are not yet verified, they are routed to Sign Up.
3. On Sign Up, they enter an email and a password and submit. The form is a single column framed by a thick red rule, with reversed-out all-caps labels at left and inputs on black at right.
4. The identity is created and they land on Upload Mod.
5. In the two-column poster form, they choose their mod file from their device. The chosen filename and size appear.
6. They fill in the mod name, version, and description.
7. They submit. The submit slab shows a pending state and the form cannot be double-submitted.
8. Observable result: a confirmation block states the mod is published and offers a route to its Mod Details and to Mods.
9. Continuation: they open the new mod's Mod Details page and see the name, version, description, and a download count of zero — the mod is now on the wall.

Failure and recovery: if the file is rejected or a required field is missing, an inline message names the problem and everything already entered is preserved. The uploader corrects the flagged item and resubmits without re-entering the rest of the form.

Flow B — A returning creator posts another mod

1. The uploader arrives on Landing and activates UPLOAD A MOD, or opens Login directly from the top bar.
2. On Login, they enter their email and password and submit.
3. Identity is verified and they land on Upload Mod.
4. They choose the new mod file, fill in its name, version, and description, and submit.
5. Observable result: the confirmation block appears and the new mod is published alongside their earlier one.
6. Continuation: they return to Mods and see both mods in the catalogue.

Failure and recovery: unrecognised credentials show an inline message and preserve the entered email; the uploader corrects the entry and resubmits, or switches to Sign Up if they never had an account.

Flow C — A player browses the catalogue and downloads a mod

1. The visitor arrives on Landing and activates the red BROWSE MODS slab.
2. They land on Mods. The yellow-on-black marquee band runs above the grid repeating NEW MODS — UPDATED — FEATURED, and the catalogue renders as a dense masonry of colour-block cards, each showing a mod name in Anton, a version tag in yellow, and a download count.
3. They scroll the grid. No account is requested at any point.
4. They select a card.
5. Observable result: the Mod Details page opens with the mod name set large in a full-bleed type header, the version tag and download count in the metadata block, the description, and an active red DOWNLOAD slab.
6. They activate DOWNLOAD.
7. Observable result: the mod file is retrieved to their device and the mod's download count reflects the completed download.
8. Continuation: they return to Mods to find another mod.

Failure and recovery: if the file is unavailable, an error block appears with a route back to Mods and the download can be retried.

Flow D — A player searches for a specific mod

1. The visitor opens Mods from the Landing hero or the top navigation bar.
2. They type a mod name into the search input.
3. Observable result: the grid narrows to the matching mods.
4. They select a matching card and land on Mod Details.
5. They read the version and description, then activate DOWNLOAD.
6. Observable result: the file is retrieved to their device.
7. Continuation: they clear the search to see the full catalogue again, or leave.

Failure and recovery: a term that matches nothing shows a no-results block with a clear-search action, returning them to the full catalogue.

Flow E — A visitor reaches a mod that is no longer available

1. The visitor opens Mods and selects a card, or follows a direct route to a Mod Details page.
2. The record cannot be found, or its file is unavailable.
3. Observable result: an error block appears in place of the record, with a route back to Mods.
4. Continuation: they return to Mods and choose another mod, or retry the download.

6. Visuals, Colors, and Theme

The creative direction is authoritative for this section. The muse is Paula Scher, and the headline idea is typography as terrain — mod files stacked like a public theatre poster, where the type is the interface.

Mode. Dark only. Black ground carries everything.

Colour tokens by role.

Blue is forbidden anywhere in the palette — no blue links, no blue badges, no blue focus rings. No gradients. No glass. No frosted panels.

Typography.

• Headings: Anton, weight 400, all-caps, tracking -0.02em, leading 0.88. Headlines are stacked in tight blocks that fill the full viewport width; on mobile the stack wraps to 3–4 lines, on desktop it can run edge to edge.
• Body: Space Grotesk.
• Type scale (1.5 modular): hero 64px mobile / 128px desktop; section title 40px / 72px; card title 24px / 36px; body 16px / 18px; label 12px / 12px, all-caps, tracked +0.12em.
• Inter, Roboto, Poppins, and system-ui are forbidden for any text.

Shape language. Hard edges only. Zero border-radius anywhere — no pills, no blobs, no rounded controls. Rectangular colour blocks, thick 3–4px black rules, diagonal bands, and solid fills. Buttons are square-cornered slabs with a hard offset shadow 4px 4px 0 #000 that snaps flat on press. No soft shadows.

Layout. Poster grid: 12 columns at desktop, 4 at mobile, with sections that break the grid deliberately. The hero is a full-bleed type composition. The mods index is a dense masonry of rectangular cards. Upload and Login/Sign Up are single-column forms framed by a thick red rule with a reversed-out label column. Navigation is a top bar with the wordmark at left, three all-caps links, and a red upload slab at right.

Imagery. Typography is the image. No photography of people, no 3D Minecraft renders, no device mockups, no Minecraft screenshots used as decoration. Mod cards use a solid colour block with the mod name set large; the only visual variation is the block colour drawn from the fixed palette. Where a mod needs a preview, it is a flat pixel-art icon or a blocky isometric diagram rendered in two or three colours, treated like a pictogram on a sign.

Readable text and controls stay whole. Headlines, wordmarks, labels, numbers, card text, and controls remain 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. Nothing covers any part of them. Where the direction asks for a cropped or bleeding gesture, the gesture is carried by imagery and decoration instead.

7. Signature Design Concept

The Poster Wall. The public entry is a full-viewport type wall. The words UPLOAD, DOWNLOAD, and MODS are stacked as three solid colour blocks — red, black, yellow — each filling the viewport width at clamp(64px, 12vw, 128px) in Anton, all-caps, tracking -0.02em, leading 0.88. The blocks butt directly against each other with no gap, so the three words read as one pasted poster rather than three sections.

The bottom block contains a single red slab button, BROWSE MODS, pinned left, and beneath it a smaller reversed-out line of copy — "Share your builds. Grab your files." — set in Space Grotesk at 18px. There is no image, no gradient, and no centred stack. The composition reads like a theatre poster pasted on a wall.

At the bottom edge, the first mod card peeks in as a teaser: a solid colour block with a mod name in Anton, a yellow version tag, and a download count in Space Grotesk. It is the only hint that a catalogue exists below, and it is what pulls the visitor into the scroll.

The concept recomposes only accepted content and controls: the three words name the product's two verbs and its subject, BROWSE MODS is the route to the Mods catalogue, and the teaser card is a real catalogue card. It introduces no new behaviour, page, or destination.

8. Interaction Model & Motion Direction

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

Landing Hero Motion Brief.

• Focal subject. The three-block type wall — UPLOAD on red, DOWNLOAD on black, MODS on yellow — stacked full-bleed at clamp(64px, 12vw, 128px).
• Input → transformation → outcome thesis. On load, the three colour blocks wipe in from the left edge in 200ms steps, one block per step, so the poster assembles itself in reading order. The outcome is a complete, static type wall with the BROWSE MODS slab pinned left in the bottom block and the teaser mod card settled at the bottom edge. No accepted behaviour is added — the wipe only reveals content that is already there.
• Motion vocabulary. Type marquees and colour-block wipes. Hard cuts, no easing curves on state changes, no bounce, no float, no spring physics, no parallax.
• Composed first frame. Before any motion, the frame is already legible: the three blocks are present at their final size and position, with the BROWSE MODS slab and the supporting line in place. The wipe is an entrance, not a prerequisite for reading.
• Reduced-motion state. With prefers-reduced-motion, the wipes become instant — the type wall is simply there on first paint. The marquee band on Mods becomes a static row of tags (NEW MODS, UPDATED, FEATURED) that wraps into rows so each tag is fully readable.

Additional motion in the current scope.

• A persistent yellow-on-black marquee band runs the full width above the mods grid on Mods, repeating NEW MODS — UPDATED — FEATURED as a moving ticker. It may cross the viewport edge by design; every item becomes fully readable as it passes.
• Mod cards hard-cut from #1A1A1A to #FF3B1F on hover, with the title inverting from off-white to black. No easing, no fade, no lift, no shadow growth.
• Upload form sections wipe in from the left in 200ms steps, one block per section.

9. Non-Functional Requirements

NFR-1 — Public catalogue without identity. Browsing Mods, searching, opening Mod Details, and downloading a mod file must all work for an anonymous visitor. No identity prompt may stand between a visitor and a download. Provenance: explicit — the request is for a web to upload and download mods, and the download side carries no stated account requirement.

NFR-2 — Protected upload workspace. Upload Mod must not be reachable or usable by an unverified visitor. An unverified visitor attempting to reach it is routed to Login or Sign Up, and the protected state remains unavailable until verification succeeds. Provenance: required_inference — an uploader's posted mods must remain bound to the correct person and the upload flow must be resumable.

NFR-3 — Anonymous identity entry. Login and Sign Up must be reachable without being signed in, because a page cannot own the interaction that grants access to itself. Provenance: required_inference.

NFR-4 — Durable mod storage. Uploaded mod files and their information must persist so that they remain available for browsing and downloading after the upload session ends. Provenance: required_inference — the accepted download journey depends on the file still being there.

NFR-5 — Download count integrity. A mod's download count must reflect completed downloads and must be visible on both the Mods card and the Mod Details page. Provenance: required_inference — the count is the catalogue's only signal of a mod's reach and is displayed in both places.

NFR-6 — Readable at every viewport. 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 nothing covering any part of them. Provenance: explicit — the creative direction's readability rule.

NFR-7 — Reduced-motion support. With prefers-reduced-motion, the marquee becomes a static row of tags that wraps or scrolls so every item can be brought fully into view, and the section wipes become instant. Provenance: explicit — the creative direction's motion rule.

NFR-8 — No blue, no gradients, no rounded corners. The palette contains no blue or indigo anywhere; no gradients, glass, or frosted panels are used; and no control carries a border-radius. Provenance: explicit — the creative direction's palette and shape constraints.

10. Tech Stack

The user specified no technology. The following are coherent defaults chosen to fit the accepted scope, labelled as defaults.

• Frontend: React. [Default — not specified by user] A single-page application serving the six pages, with the poster-grid layout, the marquee band, and the hard-cut card hover implemented in CSS.
• Backend: Python with FastAPI. [Default — not specified by user] Serves the catalogue, the mod records, the file upload endpoint, the file download endpoint, and identity registration and verification.
• Storage: a relational database for mod records and uploader identities, plus object or filesystem storage for the uploaded mod files themselves. [Default — not specified by user]
• Packaging: Docker with docker-compose for local and single-host deployment. [Default — not specified by user]
• Orchestration: Kubernetes is not required for the current scope and is not included. [Default — not specified by user]

11. Assumptions and Constraints

Assumptions.

• A-1. A visitor who only wants to download never needs an account. This follows from the request naming download alongside upload without attaching a condition to it, and from the download side of the catalogue being public.
• A-2. Identity is application-owned and established by self-service registration, because no provisioning or invitation boundary was specified for someone who wants to start uploading. [required_inference]
• A-3. A mod is owned by the uploader who published it, and that ownership is what makes the upload workspace worth protecting. [required_inference]
• A-4. The mod file is an opaque artifact to this platform: it is stored and served back byte-for-byte, and the platform does not inspect, validate, or execute it.
• A-5. The catalogue is public and shared: every verified uploader's mods appear in the same Mods grid, and no uploader sees a private subset.

Constraints.

• C-1. The page inventory is fixed at six pages in the order Landing, Login, Sign Up, Mods, Mod Details, Upload Mod, with the access stated in Section 2. No page may be added, removed, merged, split, renamed, or reordered.
• C-2. The two personas — Pengunggah Mod (Mod Uploader) and Pengundur Mod (Mod Downloader) — are the complete set of active human participants. No third persona is introduced.
• C-3. Identity grants continuity, not rank. There is no role-based visibility, no differentiated control over shared catalogue state, and no administrative layer.
• C-4. The visual system is bound by the creative direction: dark mode only, the stated palette with no blue anywhere, Anton and Space Grotesk only, zero border-radius, hard offset shadows, no gradients, no glass, no photography of people, and no 3D Minecraft renders.
• C-5. No future-horizon requirements were stated. Anything not described in Sections 3 through 5 is out of current scope, including mod installation, mod loading, game launching, server hosting, comments, ratings, following, messaging, payments, and moderation workflows.

12. Glossary

• Mod — a Minecraft modification file, together with the information that describes it: name, version, and description. On this platform a mod is the unit that is uploaded, listed, viewed, and downloaded.
• Mod file — the artifact itself, stored by the backend and served back to a downloader unchanged.
• Catalogue — the public, shared collection of all published mods, presented as the Mods grid.
• Mod card — the rectangular colour block in the Mods grid representing one mod, carrying its name, version tag, and download count.
• Pengunggah Mod (Mod Uploader) — the active human participant who selects a mod file, fills in its information, and publishes it. The only participant who establishes and verifies an identity.
• Pengundur Mod (Mod Downloader) — the active human participant who browses, searches, reviews, and downloads mods. Never required to identify themselves.
• Uploader identity — the application-owned record that binds a published mod to the person who posted it and lets that person return to the upload flow.
• Verified uploader — an uploader who has completed registration or login and can therefore reach Upload Mod.
• Publish — the act of submitting a mod file and its information so that the mod becomes visible in the catalogue and downloadable by anyone.
• Download count — the number of completed downloads recorded for a mod, shown on its card and on its Mod Details page.
• Poster wall — the signature visual concept: the full-bleed three-block type hero on Landing, in which UPLOAD, DOWNLOAD, and MODS are stacked as red, black, and yellow slabs.
• Marquee band — the persistent yellow-on-black ticker above the Mods grid repeating NEW MODS — UPDATED — FEATURED.