System Requirements Document for lumir-cliente

1. Introduction

lumir-cliente is a Minecraft client product. Its product intent, derived from the authoritative user requirement thread, is to deliver Lumi — a Minecraft client that bundles several functions beyond vanilla play, so that a player launches, connects, and plays Minecraft through Lumi with those additional functions available during use.

The audience is Minecraft players who want more than the vanilla experience: players who launch the game, pick a server or world, and then want extra client-side capability while playing. The product is a client application, not a server, not a hosting service, and not a marketplace.

Two hard product facts govern everything below:

• The product is named Lumi. The name "simple-hola" is explicitly rejected and must not be used anywhere in the product.
• Lumi is a Minecraft client with several functions. The specific function set is not yet enumerated by the user; this document therefore fixes the client's structure, entry, launch, connection, and in-client function-access lifecycle, and treats the concrete function list as an open, user-owned decision rather than inventing a feature catalogue.

2. System Overview

Lumi is a desktop Minecraft client. A player arrives at a public entry surface, understands that Lumi is a Minecraft client with extra functions, opens the client, chooses where to play (a server or a local game), and then uses Lumi's additional functions while the client is running.

Current delivery is a first-party custom client UI with four navigable destinations, in this exact order and with this exact access:

1. Landing — public, anonymous entry surface.
2. Launcher — client start surface.
3. Servers — server/game selection and connection surface.
4. Features — the player's access point to Lumi's additional functions during use.

All four are application-owned custom pages. None of them requires an account or sign-in; the accepted access contract for every one of them is none. Lumi therefore does not introduce account creation, login, profiles, subscriptions, or permission tiers. There is no differentiated visibility or role-based control anywhere in the accepted scope.

Actors:

• Jugador de Minecraft — the single accepted active human persona. This is a closed set of one.
• Minecraft server / game instance — a non-persona external system that Lumi connects to and that returns connection state (reachable, refused, timed out, version mismatch).
• Lumi client runtime — a non-persona system process that performs launch, connection, and in-client function execution.

Narrow exclusions for the current horizon: no account system, no authentication, no payment or store, no social or chat network, no server hosting, no moderation tooling, and no invented catalogue of specific mods or functions. The concrete list of "varias funciones" is deliberately left to the user; this document specifies how such functions are reached and surfaced, not which ones exist.

2a. Product Interpretation and Delivery Boundary

Lumi is delivered as a first-party client application with its own interface. The player's whole journey — discovering what Lumi is, opening it, choosing where to play, and reaching Lumi's extra functions — happens inside Lumi's own surfaces. Nothing in the accepted requirements hands any part of that journey to a provider-owned or external surface, and nothing in the accepted requirements makes any part of it headless.

Access is open. The accepted access contract states none for all four destinations, so the anonymous Landing surface is the true entry point and no protected destination exists. Because no destination is protected, there is no first-use identity establishment, no returning verification, and no session continuity requirement. The player can move from Landing to Launcher to Servers to Features without ever identifying themselves.

The current horizon covers the client's entry, launch, connection, and function-access lifecycle. Future horizon (not current, not in any page or acceptance criterion): the concrete set of additional functions, any per-function configuration depth, and any distribution or update mechanism beyond opening the client.

2c. Page Content and Component Coverage

Landing

• Information and state: what Lumi is (a Minecraft client), that it carries several functions beyond vanilla, and the current client data line (FPS, ping, version). Anonymous, no identity state.
• Primary action: open Lumi (proceed to the Launcher).
• Supporting actions: read the product statement; read the live-looking client data rail.
• Domain entities: product identity (Lumi), client data readout (FPS, ping, version, mod count).
• Component responsibilities:
  • Hero headline block — stacked headline, second line in cyan, flush-left, wrapping whole at 375px.
  • Live client data line — single mono line of instrument data.
  • Primary CTA pill — "Abrir Lumi", cyan, navigates to Launcher.
  • Real-time voxel hero subject — Three.js low-poly voxel island with emissive cyan seams, slow orbit, bleeding off the right and bottom edges.
  • Radial particle field — faint background drift behind the hero.
  • Bottom data rail — glass panel with 1px luminous top border, tabular mono FPS/ping/version/mod count.
  • Section divider — thin cyan hairline running the full viewport width beneath the fold line.
• States:
  • Loading: hero subject initializing; headline, data line, and CTA render immediately and remain readable.
  • Empty: not applicable — the surface is static product content plus a data readout.
  • Success: player reads the statement and activates "Abrir Lumi".
  • Error: if the real-time hero subject fails to initialize, the static layered composition renders in its place with counters pre-resolved; the headline, data line, and CTA are unaffected.
  • Recovery: the CTA remains the single path forward regardless of hero state.

Launcher

• Information and state: client readiness (ready to start, starting, running, stopped), client version, and the last-used connection target if one exists.
• Primary action: start the Lumi client.
• Supporting actions: read client version and readiness; return to Landing; proceed to Servers once the client is running.
• Domain entities: client instance, client version, launch state, last-used target.
• Component responsibilities:
  • Dominant launch panel — glass card holding the start control and current launch state.
  • Data rail — version, launch state, and elapsed/ready indicators in tabular mono.
  • State indicator — radial gauge ring or equivalent instrument readout for launch progress.
  • Navigation to Servers — enabled once the client is running.
• States:
  • Loading: launch in progress; state indicator animates; start control disabled.
  • Empty: client not yet started — start control is the only prominent action.
  • Success: client running; Servers becomes the next step.
  • Error: launch fails (missing or incompatible client files, insufficient resources) — the failure is stated plainly with the reason, and the start control returns to an actionable state.
  • Recovery: retry start from the same panel; no re-entry of identity or configuration is required.

Servers

• Information and state: the list of available servers or games, each with name, address, version, ping, and player count; the currently selected target; connection state.
• Primary action: connect to the selected server or game.
• Supporting actions: select a row; add a server or game by address; refresh the list; return to Launcher.
• Domain entities: server/game entry (name, address, version, ping, player count), connection attempt, connection result.
• Component responsibilities:
  • Dominant server list panel — rows with hover scanline sweep and magenta corner tick.
  • Data rail — selected target detail, ping, version, connection state in tabular mono.
  • Add-target control — enter a server or game address.
  • Connect control — commits the connection to the selected target.
  • Connection status region — reports connecting, connected, or failed with reason.
• States:
  • Loading: list refreshing; existing rows remain readable.
  • Empty: no servers or games yet — the add-target control is the prominent action, with a plain statement that no targets exist.
  • Success: connected to the selected target; the player proceeds into play with Lumi's functions available.
  • Error: connection refused, timed out, unreachable, or version mismatch — the specific reason is shown against the affected row and in the status region.
  • Recovery: retry the same target, select another, or add a different address; the list is never left in an unusable state.

Features

• Information and state: the additional functions Lumi offers, each with its name, current on/off state, and a short description; the client's running state.
• Primary action: enable or disable a function.
• Supporting actions: read a function's description; return to Servers or Launcher.
• Domain entities: function entry (name, description, enabled state), client session.
• Component responsibilities:
  • Dominant function panel — the list of Lumi's additional functions with per-function state controls.
  • Data rail — active function count and client state in tabular mono.
  • Per-function control — toggle or equivalent state control with an unambiguous current state.
  • Function detail region — description of the selected function.
• States:
  • Loading: function list resolving; the panel states that it is loading.
  • Empty: no functions available in this build — a plain statement, with no fabricated entries.
  • Success: a function's state changes and the change is reflected immediately in the panel and the data rail count.
  • Error: a function fails to apply — the failure is reported against that function and its state reverts to the last known good value.
  • Recovery: retry the toggle, or leave the function disabled and continue playing.

3. Functional Requirements

FR-1 — Product identity As a Jugador de Minecraft, I should see the product presented as Lumi everywhere in the client, so that I recognize the client I am using.

• Provenance: explicit.
• Lifecycle: actor — Jugador de Minecraft; trigger — any surface renders; observable result — the name "Lumi" appears as the product name; access state — anonymous, no identity required; failure/recovery — not applicable; continuation — the player proceeds with the client.
• Acceptance: the string "simple-hola" never appears as the product name in any surface, label, title, or wordmark.

FR-2 — Understand that Lumi is a Minecraft client with several functions As a Jugador de Minecraft, I should understand from the entry surface that Lumi is a Minecraft client that carries several functions, so that I know what I am opening before I open it.

• Provenance: explicit (client identity and "varias funciones"), required_inference (the anonymous entry surface that carries the statement).
• Lifecycle: actor — Jugador de Minecraft; trigger — the player arrives at Landing; observable result — the player can state that Lumi is a Minecraft client with additional functions; access state — anonymous, no identity required; failure/recovery — if the real-time hero subject fails, the statement still renders; continuation — the player activates "Abrir Lumi".
• Acceptance: Landing states both facts — Minecraft client, and several functions — in readable text at 375px, 768px, and 1280px.

FR-3 — Open the Lumi client As a Jugador de Minecraft, I should open the Lumi client from the entry surface, so that I can start playing through Lumi.

• Provenance: required_inference (indispensable prerequisite for the accepted outcome of playing Minecraft through Lumi).
• Lifecycle: actor — Jugador de Minecraft; trigger — activation of the "Abrir Lumi" control; observable result — the Launcher surface is presented; access state — anonymous, no identity required; failure/recovery — if the client cannot be opened, the reason is stated and the control remains actionable; continuation — the player starts the client from the Launcher.
• Acceptance: activating the primary control on Landing leads to the Launcher, and the Launcher is reachable without any identity step.

FR-4 — Start the client and observe its state As a Jugador de Minecraft, I should start the Lumi client and see whether it is starting, running, or stopped, so that I know when I can play.

• Provenance: required_inference (indispensable state transition between opening Lumi and connecting to a game).
• Lifecycle: actor — Jugador de Minecraft; trigger — activation of the start control on Launcher; observable result — launch state changes from not-started to starting to running, shown in the panel and the data rail; access state — anonymous, no identity required; failure/recovery — on launch failure the specific reason is shown and the start control returns to an actionable state for retry; continuation — once running, the player proceeds to Servers.
• Acceptance: the launch state is always visible and unambiguous, and a failed launch never leaves the surface without an actionable retry.

FR-5 — Choose where to play As a Jugador de Minecraft, I should see the servers or games available to me and select one, so that I can decide where to play.

• Provenance: required_inference (indispensable selection step for the accepted outcome of connecting to a partida or servidor).
• Lifecycle: actor — Jugador de Minecraft; trigger — arrival at Servers; observable result — a list of targets with name, address, version, ping, and player count, and one selected target; access state — anonymous, no identity required; failure/recovery — if the list cannot be retrieved, the surface states the failure and offers refresh; continuation — the player connects to the selected target.
• Acceptance: each row shows its identifying data, selection is unambiguous, and hover on a row produces the cyan scanline sweep and magenta corner tick.

FR-6 — Add a server or game by address As a Jugador de Minecraft, I should add a server or game by its address, so that I can play somewhere that is not already listed.

• Provenance: required_inference (indispensable input path when the accepted target set is not fixed by the source).
• Lifecycle: actor — Jugador de Minecraft; trigger — entry of a server or game address; observable result — the new target appears in the list and can be selected; access state — anonymous, no identity required; failure/recovery — an invalid or unreachable address is reported against the entry and the list is unchanged; continuation — the player selects and connects to the added target.
• Acceptance: an added target persists in the list for the session and is selectable like any other row.

FR-7 — Connect to the selected server or game As a Jugador de Minecraft, I should connect to the server or game I selected, so that I can play Minecraft through Lumi.

• Provenance: explicit (the accepted outcome is playing Minecraft through Lumi), required_inference (the connection step itself).
• Lifecycle: actor — Jugador de Minecraft; trigger — activation of the connect control with a target selected; observable result — connection state moves through connecting to connected, and the player is in play; access state — anonymous, no identity required; failure/recovery — refused, timed-out, unreachable, and version-mismatch outcomes are each reported with their specific reason against the affected row and in the status region, and the player can retry, select another target, or add a different address; continuation — the player plays with Lumi's functions available.
• Acceptance: a successful connection is observable as a distinct connected state, and every failure names its cause rather than failing silently.

FR-8 — Reach Lumi's additional functions during use As a Jugador de Minecraft, I should reach Lumi's additional functions while I am using the client, so that I get the "varias funciones" that make Lumi more than vanilla.

• Provenance: explicit (several functions), required_inference (the access point that makes them reachable during use).
• Lifecycle: actor — Jugador de Minecraft; trigger — arrival at Features, before or during play; observable result — the available functions are listed with their names, descriptions, and current states; access state — anonymous, no identity required; failure/recovery — if the function list cannot be resolved, the surface states that plainly and offers retry; continuation — the player enables a function and returns to play.
• Acceptance: Features is reachable from the client's navigation without leaving the client, and it lists functions rather than a single hardcoded capability.

FR-9 — Enable or disable a function and see the result As a Jugador de Minecraft, I should turn a function on or off and immediately see its state, so that I control what Lumi does while I play.

• Provenance: required_inference (indispensable control and observable result for accepted function access).
• Lifecycle: actor — Jugador de Minecraft; trigger — activation of a function's state control; observable result — the function's state changes in the panel and the active-function count in the data rail updates; access state — anonymous, no identity required; failure/recovery — if the function fails to apply, the failure is reported against that function and its state reverts to the last known good value; continuation — the player continues playing with the resulting function set.
• Acceptance: every function shows an unambiguous current state, and a failed change never leaves the displayed state inconsistent with the actual state.

FR-10 — Read live client instrument data As a Jugador de Minecraft, I should see the client's live-looking instrument data — FPS, ping, version, and function count — so that I can judge how the client is performing.

• Provenance: required_inference (observable result that makes the client's value visible, consistent with the accepted client-with-functions intent).
• Lifecycle: actor — Jugador de Minecraft; trigger — any surface renders the data rail; observable result — tabular mono values for FPS, ping, version, and function count; access state — anonymous, no identity required; failure/recovery — if a value is unavailable it is shown as unavailable rather than as a fabricated number; continuation — the player continues in the current surface.
• Acceptance: the data rail is present on Landing, Launcher, Servers, and Features, and its numerals are set in tabular monospace.

4. User Personas

Jugador de Minecraft

Product context. This player already plays Minecraft and is looking for a client that does more than vanilla. They are comfortable with launchers, server addresses, versions, and ping numbers, and they judge a client by how it feels to run — fast, responsive, and visibly instrumented. They play in a dark room, often fullscreen, and they want the client to read as an upgrade rather than a settings window.

Primary goal. Play Minecraft through Lumi, on the server or game of their choice, with Lumi's additional functions available while they play.

Distinct accepted responsibilities.

• Understand, from the entry surface, that Lumi is a Minecraft client with several functions.
• Open the Lumi client.
• Start the client and read its launch state.
• Choose where to play from the available servers or games, or add one by address.
• Commit the connection to the chosen target and read the connection result.
• Reach Lumi's additional functions and turn them on or off.
• Read the client's instrument data to judge performance.

Relevant inputs and decisions. The server or game address; which target to select; whether to connect or retry; which functions to enable; whether a reported failure warrants a retry or a different target.

Interactions with other accepted participants. The player's counterpart in the connection lifecycle is the Minecraft server or game instance, which is an external system rather than a persona: it accepts or refuses the connection and returns the state the player reads. There is no other human participant in the accepted scope — no account holder, no administrator, no moderator, and no other player role is established by the source.

Observable success. The client is running, the player is connected to the chosen target, the functions they enabled are active, and the data rail reflects the running client.

What makes this role's work different. This is not an administrative or configuration role. The player's work is a short, repeated, low-friction loop — open, start, pick, connect, adjust, play — performed under time pressure and judged by feel. Every state the player needs (launch state, connection state, function state, performance) must be visible without navigating away from what they are doing, which is why the instrument data rail is persistent rather than a separate reporting surface.

5. Core User Flows

Flow 1 — Discover Lumi and open the client

1. The player arrives at Landing with no identity and no prior state.
2. The player reads the headline stating that Lumi is a Minecraft client, with the second line in cyan, and the mono data line beneath it.
3. The player reads the bottom data rail showing FPS, ping, version, and function count in tabular mono.
4. The player activates the cyan pill CTA "Abrir Lumi".
5. Observable result: the Launcher is presented. No identity step occurs at any point.
6. Failure/recovery: if the real-time voxel hero subject fails to initialize, the static layered composition renders with counters pre-resolved; the headline, data line, and CTA remain readable and the CTA still works.
7. Next step: the player starts the client from the Launcher.

Flow 2 — Start the client

1. The player is on Launcher with the client not yet started.
2. The dominant launch panel shows the start control as the only prominent action, and the data rail shows the client version and a not-started state.
3. The player activates the start control.
4. Observable result: the state indicator animates and the launch state moves from not-started to starting; the start control is disabled while starting.
5. On success, the launch state becomes running and the navigation to Servers becomes available.
6. Failure/recovery: if launch fails — missing or incompatible client files, or insufficient resources — the specific reason is stated plainly in the panel, and the start control returns to an actionable state. The player retries from the same panel without re-entering anything.
7. Next step: the player proceeds to Servers.

Flow 3 — Choose a server or game and connect

1. The player is on Servers with the client running.
2. The dominant server list panel shows the available targets, each row carrying name, address, version, ping, and player count.
3. The player moves the pointer over rows; each hovered row shows a horizontal cyan scanline sweep and a magenta corner tick.
4. The player selects a target. The data rail updates to show the selected target's detail, ping, and version.
5. The player activates the connect control.
6. Observable result: the connection status region moves through connecting to connected, and the player is in play with Lumi's functions available.
7. Failure/recovery: if the connection is refused, times out, is unreachable, or the version mismatches, the specific reason is shown against the affected row and in the status region. The player retries the same target, selects another, or adds a different address. The list is never left unusable.
8. Next step: the player plays, and can reach Features at any time.

Flow 4 — Add a server or game by address

1. The player is on Servers and the target they want is not listed.
2. The player activates the add-target control and enters the server or game address.
3. Observable result: the new target appears in the list and is selectable like any other row.
4. Failure/recovery: if the address is invalid or unreachable, the failure is reported against the entry and the list is unchanged.
5. Next step: the player selects the added target and connects (Flow 3, steps 4–7).

Flow 5 — Reach and control Lumi's additional functions

1. The player is on Features, either before connecting or while playing.
2. The dominant function panel lists Lumi's additional functions, each with its name, a short description, and its current on/off state. The data rail shows the active function count.
3. The player selects a function and reads its description in the detail region.
4. The player activates that function's state control.
5. Observable result: the function's state changes immediately in the panel, and the active-function count in the data rail updates.
6. Failure/recovery: if the function fails to apply, the failure is reported against that function and its state reverts to the last known good value. The player retries the toggle or leaves the function disabled and continues playing.
7. Next step: the player returns to Servers or to play with the resulting function set.

Flow 6 — Judge client performance while playing

1. The player is in any surface — Landing, Launcher, Servers, or Features.
2. The persistent bottom data rail shows FPS, ping, version, and function count in tabular mono, with values ticking up softly as sections enter.
3. Observable result: the player reads the current values without leaving what they are doing.
4. Failure/recovery: if a value is unavailable, it is shown as unavailable rather than as a fabricated number.
5. Next step: the player continues in the current surface, adjusting functions or changing targets as the numbers warrant.

6. Visuals, Colors and Theme

Authoritative creative direction: Cinematic future tech after Gleb Kuznetsov. Muse: Gleb Kuznetsov. Headline register: powerful, fast, slightly illicit, glowing — a futuristic cockpit over the blocky world.

Color tokens (dark mode, exact):

Panel borders: 1px luminous edges at rgba(232,237,247,0.12). Connectors: thin 1px cyan strokes. Blue–indigo primaries (#2563EB, #4F46E5, #6366F1 family) and white or near-white grounds are forbidden.

Typography:

• Headings and body: Space Grotesk. Headlines at 700 weight with -0.02em tracking; micro-labels uppercase at 11px with 0.18em tracking.
• Numerals: JetBrains Mono, tabular, for all FPS, ping, version, and function-count data at 13px fixed.
• Scale: 1.25 modular on a 4px baseline — display 44px mobile → 96px desktop; h2 28 → 48; h3 20 → 28; body 15 → 17; micro-label 11px uppercase fixed; data 13px mono fixed. Sizes use clamp(...) with their mobile size so text stays whole at 375px.
• Inter, Roboto, Poppins, and system-ui are forbidden for headings and body.

Shape language: floating glass panels with 14px radii and 1px luminous edges; thin 1px cyan strokes as connectors; radial gauge rings for performance metrics; hard-edged voxel cubes as the only sharp-cornered element in the UI. The contrast between soft glass chrome and the cubic world is the point.

Layout: full-bleed dark stage as the page. Content floats as glass cards in a loose 12-column grid with 96px gutters on desktop and 20px on mobile. Section transitions are horizontal light sweeps rather than hard rules. Launcher, Servers, and Features each get one dominant panel plus a data rail — never a grid of identical hover-lift cards.

Imagery: one crafted real-time 3D subject — a floating low-poly voxel island (grass block, torch, water block) with glowing cyan seam lines, rendered in Three.js with a slow orbit and emissive edges. Supporting imagery is abstract: particle fields, thin luminous wireframes, HUD arcs. No stock photos, no flat clip art, no Minecraft screenshot collage, no flat pixel-art illustration.

7. Signature Design Concept

"Cockpit over the blocky world."

The public entry — Landing — is a full-bleed #07090F stage. The left 7 columns hold a stacked headline in Space Grotesk 700, flush-left, reading "TU MINECRAFT, RECARGADO" with the second line in cyan #22E0C8. Beneath it sits a single mono line of live client data — FPS 240 · PING 12ms · 1.21.4 — and one cyan pill CTA, "Abrir Lumi". The right 5 columns carry the Three.js voxel island, bleeding off the right and bottom edges, lit only by its own emissive seams and a magenta #FF4FD8 rim light. Behind everything, a faint radial particle field drifts. A thin cyan hairline runs the full viewport width beneath the fold line as a section divider.

The concept's argument is that Lumi's value is invisible machinery — FPS, ping, version, function count — and the design makes that machinery the visible subject. The voxel island is the world; the glass, the seams, and the instrument numerals are the client wrapped around it. The persistent bottom data rail carries the same idea into every surface, so the player never leaves the cockpit to check the instruments.

This concept recomposes only accepted content and controls: the product statement, the client data readout, the "Abrir Lumi" control, and the navigation into the client. It introduces no new behaviour, page, or destination.

8. Interaction Model & Motion Direction

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

Landing Hero Motion Brief

• Focal subject: the floating low-poly voxel island — grass block, torch, water block — with glowing cyan seam lines, rendered in Three.js, bleeding off the right and bottom edges.
• Input → transformation → outcome thesis: as the player scrolls, the hero camera tilts in a scroll-scrubbed motion while the voxel cluster continues its slow continuous orbit; the island's emissive seams and magenta rim light stay lit throughout, and the mono data line and counters resolve to their values as the section enters. The outcome is a first frame that already reads as a running client, not a static poster.
• Motion vocabulary: continuous slow orbit on the voxel cluster; light sweeps crossing glass panels every 8–12s; counters that tick up on scroll-in; a scroll-scrubbed camera tilt on the hero; a horizontal cyan scanline pass on server-row hover; full-width 2px cyan light sweeps as section transitions.
• Composed first frame: dark #07090F stage; headline flush-left in the left 7 columns with the second line in cyan; the mono data line and cyan pill CTA beneath it; the voxel island occupying the right 5 columns and bleeding off the right and bottom edges; the faint radial particle field behind; the cyan hairline divider beneath the fold line.
• Reduced-motion state: all motion freezes to a static layered composition — the voxel island holds a single composed pose, counters are pre-resolved to their final values, light sweeps and scanlines do not run, and the scroll-scrubbed camera tilt is disabled. The headline, data line, CTA, and data rail remain fully readable and operable.

Landing Hero 3D Scene Brief — DIRECTION-DERIVED

One crafted real-time object: a compact low-poly voxel island built from a small number of hard-edged cubes — a grass block, a torch, and a water block — with emissive cyan seam lines along the cube edges and a magenta rim light from behind. The scene shows the product's defining state: a blocky world rendered inside a glowing client. It orbits slowly and continuously, is lit only by its own emissive seams and the rim light, and is composed to bleed off the right and bottom edges of the viewport. Under prefers-reduced-motion the orbit stops and the island holds a single composed pose.

9. Non-Functional Requirements

• NFR-1 — Readability at every viewport. Headlines, the wordmark, labels, numbers, card text, and controls 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: explicit creative direction. Rationale: the direction's own readability rule takes precedence over any cropping gesture.
• NFR-2 — Reduced motion. All motion respects prefers-reduced-motion by freezing to a static layered composition with counters pre-resolved. Provenance: explicit creative direction. Rationale: accessibility of the cinematic motion language.
• NFR-3 — No forbidden palette or typography. No white or near-white grounds, no blue–indigo primary, no Inter/Roboto/Poppins/system-ui for headings or body, no light mode. Provenance: explicit creative direction. Rationale: the dark HUD register is the product's identity.
• NFR-4 — Instrument numerals. Every FPS, ping, version, and function-count value is set in tabular monospace so digits do not shift as values change. Provenance: explicit creative direction. Rationale: numbers must read as instrument data.
• NFR-5 — No identity requirement. No surface in the accepted scope requires an account, sign-in, or profile. Provenance: accepted access contract (none for all four destinations). Rationale: the accepted journeys contain no identity step, and adding one would introduce an unaccepted capability.
• NFR-6 — Honest state reporting. Launch state, connection state, and function state are always shown truthfully; failures name their specific cause and never fail silently. Provenance: required_inference. Rationale: the player's decisions depend on these states.
• NFR-7 — No fabricated data. Unavailable instrument values are shown as unavailable rather than as invented numbers, and an empty function list is stated plainly rather than filled with fabricated entries. Provenance: required_inference. Rationale: the client's value proposition is trustworthy instrumentation.

10. Tech Stack

• Frontend: React, with Three.js / React Three Fiber for the real-time voxel hero subject on Landing.
• Backend: Python / FastAPI, serving the client's data endpoints — server/game list retrieval, target addition, connection status, and function list and state.
• Storage: a lightweight persistent store for the player's added server or game targets and their function states, so the client resumes with the same configuration.
• Packaging: Docker and docker-compose for the backend service and its storage, extending the existing backend process rather than introducing a separate service for the client's data endpoints.

No Kubernetes deployment is required by the accepted scope.

11. Assumptions and Constraints

• Constraint (explicit, binding): the product is named Lumi. The name "simple-hola" must not be used. This is a hard constraint and applies to every surface, label, title, and wordmark.
• Constraint (explicit, binding): Lumi is a Minecraft client, and it must include several functions. The specific function set is not enumerated by the user and is deliberately left open; this document specifies how functions are reached and controlled, not which functions exist.
• Assumption: the client runs on a desktop platform where a launcher, a server browser, and in-client function controls are meaningful. This follows from the accepted product category and is not an added capability.
• Assumption: the Minecraft server or game instance is an external system owned by the player or a third party. Lumi connects to it; Lumi does not host, provision, or moderate it.
• Assumption: the instrument data shown in the data rail reflects the running client. Where a value cannot be obtained, it is reported as unavailable (NFR-7).
• Boundary: no account system, authentication, profile, subscription, payment, store, social network, chat network, server hosting, or moderation tooling is in the current scope. None of these is established by the authoritative source, and none is inferred here.
• Boundary: the concrete list of additional functions, any per-function configuration depth, and any distribution or update mechanism beyond opening the client are future horizon and are excluded from current pages and acceptance criteria.

12. Glossary

• Lumi — the product name. A Minecraft client with several functions. The name "simple-hola" is rejected.
• Cliente — the Lumi application the player runs to play Minecraft.
• Launcher — the surface where the player starts the Lumi client and reads its launch state.
• Servers — the surface where the player views, adds, selects, and connects to a Minecraft server or game.
• Features — the surface where the player reaches and controls Lumi's additional functions.
• Función — one of the additional capabilities Lumi offers beyond vanilla Minecraft. The concrete set is not enumerated by the source.
• Data rail — the persistent glass panel showing FPS, ping, version, and function count in tabular monospace.
• Voxel island — the real-time Three.js hero subject on Landing: a low-poly island of hard-edged cubes with emissive cyan seams.
• Scanline sweep — the horizontal cyan pass that crosses a server row on hover, paired with a magenta corner tick.
• Target — a server or game entry the player can select and connect to.