System Requirements Document for mercy-24

1. Introduction

mercy-24 is a personal game-server control product. The user asked, in Arabic, for a server that stays running 24 hours a day and that is linked to their game: "ابنيلي سيرفر يفضل شغال 24 ساعة اربطة بلعبتي". The product therefore exists to give a single game owner/operator a persistent, always-on server they control, and a way to connect that server to their own game.

The audience is one technical, self-reliant player-operator — the Game Server Owner — who wants a machine that simply never stops. The product's core proof is continuity: uptime, heartbeat, and live connection state. The interface is a control surface for that continuity, not a general hosting marketplace, not a social platform, and not a multi-tenant administration suite.

2. System Overview

mercy-24 is a first-party web application with an application-owned identity boundary and a backend that runs and monitors the owner's game server continuously.

Current delivery consists of five pages, in this order:

1. Landing — anonymous public entry surface.
2. Sign Up — anonymous identity-access surface for self-service enrollment.
3. Login — anonymous identity-access surface for returning verification.
4. Server — login-protected destination for starting and keeping the game server running continuously.
5. Game Link — login-protected destination for linking the server to the owner's game.

Actors:

• Game Server Owner (active human persona) — the sole accepted human actor. They enroll, verify, start and keep the server running, and link it to their game.
• mercy-24 backend runtime (system actor) — executes the server process, maintains the heartbeat, records uptime, and performs the outbound connection to the owner's game.
• The owner's game (external destination) — the external system the server is linked to. It is not a first-party page and is not a persona.

Accepted behavior in scope: continuous server operation with a stated preference for 24-hour-a-day availability; starting and keeping the server running; linking the server to the owner's game; and the identity continuity needed to return to that durable configuration.

Narrow exclusions: no multi-user collaboration, no role or permission differentiation, no billing or marketplace, no game hosting for third parties, and no game client modification. The game itself remains external and is owned by the user.

2a. Product Interpretation and Delivery Boundary

The product is delivered as a first-party web application. The public entry, enrollment, and returning verification are anonymously reachable; the two operational destinations — Server and Game Link — require the owner to be verified, because the server runtime and the game link are durable, owner-specific state that must remain bound to the correct person across visits.

Identity is application-owned and established by self-service enrollment, because the owner independently begins using the product and no invitation, provisioning, or deployment bootstrap boundary is established by the source. Enrollment and returning verification are journey prerequisites only; they do not introduce account-management, team, or permission features.

The server runtime itself is a backend responsibility: it runs continuously and is monitored by the product. The owner's interaction with it — starting it, watching it stay up, and linking it to the game — is first-party UI. The owner's game is external: mercy-24 connects out to it, and the game is never re-implemented inside this product.

Everything described in this document is current. No future-horizon requirements were stated by the user.

2b. Source Content Inventory

Not applicable. No reference directive with content_source authority was supplied.

2c. Page Content and Component Coverage

Landing

• Information and state: Anonymous public entry. Explains what mercy-24 is — a game server that stays running around the clock and links to the owner's game. Shows the product's continuity proof: a live uptime readout, a heartbeat trace, and a LINKED / NOT LINKED ruled label. When no server is running yet, the uptime readout shows 24H:00M:00S at zero and the link label reads NOT LINKED.
• Primary action: START THE SERVER — a hard-edged teal-outlined rectangle cut into the canvas edge at bottom-left. For an anonymous visitor this leads into the identity boundary (Sign Up, or Login if already enrolled).
• Supporting action: Connect your game → — a quieter text link leading to the same identity boundary, then to Game Link.
• Domain entities: server uptime, heartbeat tick, link state.
• Component responsibilities: full-bleed generative canvas as the first viewport; fixed 72px left rail carrying the wordmark MERCY-24 rotated 90° and a single status dot (cyan when running, ember orange when down); oversized flush-left headline across columns 1–7; live telemetry stack in columns 9–12; numbered sections 01 / 02 / 03 in the left gutter below the fold, separated by horizontal rules.
• States: Loading — canvas initializes and telemetry placeholders hold their ruled positions. Empty — no server yet: zeroed uptime, NOT LINKED, status dot ember orange. Success — running server: uptime counting up, cyan heartbeat trace, status dot cyan. Error — telemetry unavailable: the readout rows remain with an explicit unavailable marker rather than fabricated numbers. Recovery — the field and readouts resume on the next heartbeat tick.

Sign Up

• Information and state: Anonymous self-service enrollment. States plainly that an account is what keeps the owner's server configuration and game link bound to them.
• Primary action: submit enrollment details to create the owner's identity.
• Supporting actions: move to Login if already enrolled; return to Landing.
• Domain entities: owner identity, enrollment submission.
• Component responsibilities: ruled form rows (label left, input right, hairline between rows) — no cards, no glass panels; inline validation messaging; a single submit control.
• States: Loading — submit disabled with a restrained progress indication. Empty — blank fields. Success — identity created and the owner proceeds to the Server page. Error — invalid or already-used details shown inline against the offending row. Recovery — the owner corrects the field and resubmits without losing entered values.

Login

• Information and state: Anonymous returning verification. Explains that signing in restores control of the durable server runtime and game link.
• Primary action: submit credentials to verify the returning owner.
• Supporting actions: move to Sign Up if not yet enrolled; return to Landing.
• Domain entities: owner identity, verification attempt.
• Component responsibilities: ruled form rows; inline error messaging; a single submit control.
• States: Loading — submit disabled with a restrained progress indication. Empty — blank fields. Success — verified and returned to the destination the owner was heading for (Server or Game Link). Error — credentials not accepted, stated inline without revealing which field failed. Recovery — retry, or move to Sign Up.

Server

• Information and state: The owner's instrument panel for the running server. Shows uptime as a thin cyan ring plus a ruled readout table (label left, tabular value right, hairline between every row): uptime, heartbeat tick, tick rate, connected players, ping, and current run state. The left rail status dot reads cyan when running and ember orange when down.
• Primary actions: start the server; stop the server.
• Supporting action: navigate to Game Link to connect the game.
• Domain entities: server process, run state, uptime, heartbeat, tick rate, connected players, ping.
• Component responsibilities: full-width live trace replacing the landing canvas; ruled readout table with zero cards; start/stop control; state-change pulse; left rail status dot.
• States: Loading — readout rows hold their ruled positions while the runtime reports in. Empty — server not yet started: uptime zeroed, run state STOPPED, status dot ember orange. Success — running: uptime counting rather than jumping, live trace advancing, status dot cyan. Error — the server fails to start or the runtime stops unexpectedly: run state shows the failure, the status dot goes ember orange, and a single orange pulse marks the state change. Recovery — the owner restarts the server from the same control and uptime resumes from the new run.

Game Link

• Information and state: The owner's destination for connecting the server to their game. Shows the current link state as a ruled label (LINKED / NOT LINKED), the connection target, and the last successful connection time. Supporting visuals are diagrammatic: a thin cyan schematic of game client → MERCY-24 node → 24/7 heartbeat, and ink-wash data traces from the last 24 hours on a white-ground variant.
• Primary actions: enter the game connection details and link the server to the game; unlink.
• Supporting action: return to Server to watch the running state.
• Domain entities: game connection target, link state, last successful connection.
• Component responsibilities: ruled form rows for connection details; ruled link-state readout; schematic diagram; 24-hour trace panel; link/unlink control.
• States: Loading — link state unresolved while the connection is checked. Empty — no game linked: NOT LINKED, no last-connection time. Success — LINKED, with the last successful connection time recorded and the schematic showing the live path. Error — the connection to the game fails: NOT LINKED with the failure stated plainly and no fabricated success. Recovery — the owner corrects the connection details and links again.

3. Functional Requirements

FR-1 — Build a server for the owner's game (explicit) As a Game Server Owner, I should have a server built for my game, so that I have a machine of my own to run it on.

• Trigger/input: the owner's request for a server for their game.
• Observable result: a server exists and is owned by the owner.
• Access state: the server's runtime state is reachable from the login-protected Server page.
• Failure/recovery: if the server cannot be provisioned, the owner sees the failure on the Server page and can retry.
• Continuation: the owner proceeds to start the server.

FR-2 — Keep the server running 24 hours a day (explicit; stated as a preference, not an absolute guarantee) As a Game Server Owner, I should have my server preferably running 24 hours a day, so that it is available continuously rather than only when I am present.

• Trigger/input: the owner starts the server.
• Observable result: the server runs continuously, and the Server page shows uptime counting up, a live heartbeat trace, and a cyan status dot in the left rail.
• Access state: login-protected.
• Failure/recovery: if the server stops or fails to start, the run state shows the failure, the status dot turns ember orange, and a single orange pulse marks the state change; the owner can restart from the same control.
• Continuation: the owner leaves the server running and returns later to confirm uptime has accumulated.
• Note: the source states this as a preference ("يفضل"), so the requirement is continuous availability as the product's aim, not a contractual uptime guarantee.

FR-3 — Link the server to the owner's game (explicit) As a Game Server Owner, I should link my server to my game, so that my game is connected to the server I control.

• Trigger/input: the owner enters their game connection details on the Game Link page and confirms the link.
• Observable result: the link state reads LINKED, the last successful connection time is recorded, and the schematic shows the live path from game client through the MERCY-24 node to the 24/7 heartbeat.
• Access state: login-protected.
• Failure/recovery: if the connection to the game fails, the page reads NOT LINKED with the failure stated plainly; the owner corrects the details and links again.
• Continuation: the owner returns to the Server page to watch the running state with the game connected.

FR-4 — Self-service enrollment before first use (required_inference) As a Game Server Owner, I should be able to enroll myself before first use, so that my server configuration and game link stay bound to me.

• Trigger/input: the owner chooses START THE SERVER or Connect your game → on the anonymous Landing page without an existing identity.
• Observable result: the owner's identity is created and they proceed to the destination they were heading for.
• Access state: Sign Up is anonymously reachable; protected state remains unavailable until identity is established.
• Failure/recovery: invalid or already-used details are shown inline against the offending row, and the owner corrects and resubmits without losing entered values.
• Continuation: the owner continues to Server or Game Link.

FR-5 — Returning verification before managing the server or game connection (required_inference) As a Game Server Owner, I should verify myself when I return, so that I regain control of my durable server runtime and game link.

• Trigger/input: the owner returns and opens Server or Game Link without an active verified session.
• Observable result: after verification the owner lands on the destination they were heading for, with their server state and link state intact.
• Access state: Login is anonymously reachable; Server and Game Link require login.
• Failure/recovery: credentials not accepted are stated inline without revealing which field failed; the owner retries or moves to Sign Up.
• Continuation: the owner manages the server or the game link.

FR-6 — Observe the server's live continuity state (required_inference) As a Game Server Owner, I should see my server's uptime, heartbeat, and link state at a glance, so that I can tell whether it is actually staying up.

• Trigger/input: the owner opens Landing (public continuity proof) or Server (full readout).
• Observable result: uptime counts rather than jumps, the heartbeat trace advances, and the left rail status dot reads cyan when running and ember orange when down.
• Access state: the public continuity proof is anonymous; the full readout is login-protected.
• Failure/recovery: when telemetry is unavailable, readout rows remain with an explicit unavailable marker rather than fabricated numbers, and resume on the next heartbeat tick.
• Continuation: the owner acts on what they see — starting, restarting, or linking.

FR-7 — Start and stop the server (required_inference) As a Game Server Owner, I should start and stop my server, so that I control when it runs.

• Trigger/input: the owner uses the start/stop control on the Server page.
• Observable result: run state changes, uptime begins or ends, and a single orange pulse marks the state change.
• Access state: login-protected.
• Failure/recovery: a failed start shows the failure in run state with the ember orange status dot; the owner retries from the same control.
• Continuation: the owner leaves the server running and returns to confirm accumulated uptime.

4. User Personas

Game Server Owner

Product context. A single technical, self-reliant player-operator who runs their own game and wants a machine that simply never stops. They are not shopping for hosting plans and they are not administering other people's servers; they want one persistent server of their own, connected to their own game. They read numbers for a living, so the product's proof of value is telemetry they can trust: uptime, heartbeat, tick rate, ping, connected players, link state.

Primary goal. To have a persistent, always-available server they control, with their game connected to it.

Distinct accepted responsibilities.

• Enrolling themselves before first use, so their configuration and game link stay bound to them.
• Verifying themselves when they return, to regain control of that durable state.
• Starting the server and keeping it running continuously, with a stated preference for 24-hour-a-day availability.
• Linking the server to their game, and correcting the connection when it fails.
• Reading the continuity state — uptime, heartbeat, link state — to judge whether the server is genuinely staying up.

Relevant inputs and decisions. Their game's connection details; the decision to start or stop the server; the decision to link or unlink the game; the judgment, from the readouts, of whether the server is healthy.

Interactions with other accepted participants. The owner is the only accepted human actor. Their counterparties are non-human: the mercy-24 backend runtime, which executes the server and maintains the heartbeat, and the owner's own game, which is external and receives the outbound connection. The owner initiates; the runtime and the game respond; the owner observes the result on the Server and Game Link pages.

Observable success. The server is running continuously with uptime accumulating, the status dot in the left rail is cyan, and the Game Link page reads LINKED with a recorded last successful connection.

What makes this role distinct. The owner is simultaneously the operator and the sole beneficiary. There is no team, no client, and no approval chain: every decision — enroll, verify, start, stop, link, unlink — is theirs alone, and the only thing they are accountable to is whether the machine stayed up.

5. Core User Flows

Flow 1 — First use: enroll, start the server, and keep it running

1. The owner arrives at the anonymous Landing page. The full-bleed generative canvas is seeded from server telemetry; the headline reads "A server that never sleeps." and the telemetry stack shows 24H:00M:00S at zero with NOT LINKED and an ember orange status dot in the left rail.
2. The owner chooses START THE SERVER, the hard-edged teal-outlined rectangle cut into the canvas edge at bottom-left.
3. Because no identity exists yet, the owner is taken to the anonymous Sign Up page. They enter their enrollment details and submit.
4. On success, the owner's identity is created and they proceed to the Server page.
5. On the Server page the readout table shows run state STOPPED, uptime zeroed, and the status dot ember orange. The owner uses the start control.
6. The server starts. Run state changes, a single orange pulse marks the state change, the status dot turns cyan, and uptime begins counting up rather than jumping. The live trace advances.
7. The owner leaves the server running. On returning later, they open Server, are asked to verify on the anonymous Login page, and after verification land back on Server with uptime accumulated — confirming the server stayed up in their absence.
8. Continuation: the owner proceeds to Flow 2 to connect their game.

Failure and recovery: if the server fails to start, run state shows the failure and the status dot stays ember orange; the owner retries from the same control and uptime resumes from the new run. If telemetry is unavailable, the readout rows remain with an explicit unavailable marker rather than fabricated numbers, and resume on the next heartbeat tick.

Flow 2 — Link the server to the owner's game

1. From the Server page, with the server running, the owner navigates to Game Link.
2. The page shows NOT LINKED, no last-connection time, and the schematic of game client → MERCY-24 node → 24/7 heartbeat with the path not yet live.
3. The owner enters their game connection details in the ruled form rows and confirms the link.
4. The product connects out to the owner's game. On success the link state reads LINKED, the last successful connection time is recorded, and the schematic shows the live path.
5. The owner returns to Server to watch the running state with the game connected: uptime counting, heartbeat trace advancing, status dot cyan.
6. Continuation: the owner leaves both the server and the link in place and returns later to confirm both are still up.

Failure and recovery: if the connection to the game fails, the page reads NOT LINKED with the failure stated plainly and no fabricated success; the owner corrects the connection details and links again. If the owner later needs to sever the connection, they use the unlink control and the page returns to NOT LINKED.

Flow 3 — Returning to check and control the running server

1. The owner returns and opens Server directly.
2. Because no verified session is active, they are taken to the anonymous Login page. They submit their credentials.
3. On success they land on Server with their durable state intact: uptime as it stands, the live trace, and the current link state.
4. The owner reads the instrument panel — uptime ring, heartbeat tick, tick rate, connected players, ping — and judges whether the server is healthy.
5. If the server is down, run state shows the failure, the status dot is ember orange, and a single orange pulse marked the state change. The owner uses the start control to bring it back up; uptime resumes from the new run.
6. Continuation: the owner leaves the server running again and returns later to confirm accumulated uptime.

Failure and recovery: if credentials are not accepted, the error is stated inline without revealing which field failed; the owner retries, or moves to Sign Up if they have not enrolled.

6. Visuals Colors and Theme

The creative direction is authoritative for this section: Data made physical — a 24-hour uptime sculpture that never sleeps, after the muse Refik Anadol. The headline idea is that the product's core proof is continuity — uptime, heartbeat, live connection — which is literally a stream of data, so the visual language is a live data sculpture rather than decoration.

Mode. Dark mode.

Colour tokens by role.

Ratio: roughly 80% ground / 12% surface / 6% cyan light / 2% orange.

Typography.

• Headings: Instrument Serif, weight 400 only, set enormous at clamp(64px, …, 168px), tracking -0.02em, sentence case, with the key noun in italic — a museum wall label blown up to poster scale.
• Body: Archivo, 400, 16px, line-height 1.6.
• Labels: Archivo 600, 13px, uppercase, 0.14em tracking.
• Numeric readouts (uptime, ticks, ms, players): Archivo tabular-nums, weight 500.
• Scale, 1.5 modular: 168 / 112 / 72 / 40 / 24 / 16 / 13.

Shape language. Almost no shape at all — the generative field supplies the form. Panels are flat rectangles with 2px radii and 1px #232733 borders. No shadows, no glass blur, no pill buttons. The only curves in the interface are the arcs of the particle flow and the circular uptime ring. Controls are hard-edged rectangles with a 1px underline on hover. Anything that would read as a card with a soft shadow is forbidden.

Layout. Full-bleed generative canvas as the first viewport, with a fixed 72px left rail carrying the wordmark MERCY-24 rotated 90° and a status dot. Content sits on a 12-column grid with a 96px outer margin; the hero headline occupies columns 1–7 and the live telemetry stack columns 9–12, so type and data face each other across the field. Below the fold: horizontal rules only, sections numbered 01 / 02 / 03 in the left gutter, generous 160px vertical rhythm, no cards — rows and rules instead. The Server page replaces the canvas with a single full-width live trace plus a ruled readout table (label left, tabular value right, hairline between every row).

Imagery style. No stock photography, no 3D game renders, no clip art. The imagery is the generative render: a particle/flow field seeded from the server's own telemetry (uptime seconds, tick rate, player count, ping), so the hero looks different for every user's server. Supporting visuals are diagrammatic — a thin cyan schematic of game client → MERCY-24 node → 24/7 heartbeat, and ink-wash data traces from the last 24 hours on a white-ground variant for the link page.

7. Signature Design Concept

The public entry is a live data sculpture, not a marketing page.

The first screen is a full-bleed black generative canvas (#08090C) where a slow luminous cyan particle field flows left-to-right like a current, seeded by the server's live uptime. Over it, flush-left and not centred: the headline "A server that never sleeps." set in Instrument Serif at 168px across columns 1–7, with "never sleeps" in italic and the final word clipped slightly by the viewport edge — type as architecture. In the right columns, a bare telemetry stack: 24H:00M:00S uptime counting up in tabular figures, a thin cyan heartbeat trace, and LINKED / NOT LINKED as a ruled label. The primary CTA is a hard-edged teal-outlined rectangle cut into the canvas edge at bottom-left, reading START THE SERVER; a second, quieter text link reads Connect your game →.

The fixed 72px left rail spells MERCY-24 rotated 90°, with a single status dot that is cyan when running and ember orange when down — the whole app's state readable from the gutter. There is no gradient blob, no centred stack, and no blue button: the field is the hero and the type sits on top of it like a caption on an artwork.

This concept recomposes only accepted content, states, and controls: the uptime readout, the heartbeat trace, the link label, the start action, and the connect-game action.

8. Interaction Model & Motion Direction

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

Landing Hero Motion Brief