System Requirements Document for clever-mlbb

1. Introduction

clever-mlbb is a browser-delivered multi-tool hub for Mobile Legends: Bang Bang (MLBB), branded MULTI TOOLS MLBB and credited to Developer@Ashleytut. The product gives MLBB players and modders a single dark, high-energy operator console from which they can run four specific tools:

1. Generate Dev ID — produce a developer ID.
2. Ban Check (full info) — check a single target and return full ban information.
3. Bulk Ban (full info) — check multiple targets at once and return full ban information for each.
4. Brute Force via Dev ID — run a brute-force operation against a supplied developer ID and display the result.

The audience is a young, technically literate, Tagalog-speaking community of MLBB players and modders who want raw, fast, no-nonsense tool output. The interface must feel "maangas" — cocky, dangerous, futuristic — a console that feels more powerful than it should be, not a corporate dashboard. The tool set is deliberately limited to the four listed tools; nothing else is in scope.

2. System Overview

clever-mlbb is a single web application with a public entry surface and four focused tool pages. Every surface is anonymously reachable — the source establishes no accounts, no sign-in, and no per-user private state, so no identity, session, or permission layer is introduced. The application is backed by a server-side service that performs the dev-ID generation, ban lookups, bulk ban processing, and brute-force runs, and returns structured "full info" payloads that the UI renders inside HUD data panels.

Actors

• MLBB Tool User — opens the hub, picks a tool, supplies the required input, and reads the returned full-info results.
• Developer@Ashleytut (Tool Owner/Operator) — the named owner of the MULTI TOOLS MLBB build, credited on every surface and operating the same four tools through the same console.

Both personas use the identical tool set through the identical surfaces; the owner/operator role is distinguished by branding and ownership of the build, not by differentiated permissions or visibility.

Current delivery

• A flashy dark-void HUD landing surface presenting the brand, the developer credit, and the four numbered tool slots.
• Four tool pages, each with an input console and a live results panel.
• A backend service that executes the four operations and returns full-info results.

Explicit exclusions

• No tools beyond the four listed: [1] Generate Dev ID, [2] Ban Check full info, [3] Bulk Ban full info, [4] Brute Force via Dev ID.
• No account creation, login, or user profile system.
• No role-based permissions or differentiated visibility between the two personas.

2a. Product Interpretation and Delivery Boundary

Delivery ownership. clever-mlbb is a first-party web application. All five surfaces — Landing, Dev ID Generator, Ban Check, Bulk Ban, and Dev ID Brute Force — are application-owned custom pages. The four tool operations are executed by the application's own backend service; no third-party provider surface, external destination, or headless-only delivery is specified or accepted.

Access ownership. Every surface is anonymously reachable. The source never asks for accounts, sign-in, or private per-user state, and no accepted journey requires durable actor-specific state to be privately owned or resumed. The tool inputs (a target, a list of targets, a developer ID) are supplied per run and their results are returned per run; nothing must remain bound to a returning identity. Consequently no identity establishment, verification, or account-management capability is introduced, and no destination is protected.

Current vs. future boundary. Everything described in this document is current scope: the branded hub, the four tools, the flashy UI and background, and the backend execution of the four operations. No future-horizon requirements were stated by the user; the four-tool limit is a current hard constraint, not a roadmap placeholder.

2c. Page Content and Component Coverage

Landing

• Information / state: The brand wordmark MULTI TOOLS MLBB, the developer credit @Ashleytut (magenta caps), a one-line statement of what the hub is, and the four numbered tool slots — [01] DEV ID, [02] BAN CHECK, [03] BULK BAN, [04] BRUTE FORCE. No user data is held here.
• Primary actions: Launch the console (enter the tool set); select any of the four numbered tool slots to go directly to that tool page.
• Supporting actions: Hover/focus a tool slot to preview its name and purpose; pause the telemetry ticker on hover.
• Domain entities: Tool slot (number, name, route, destructive flag), brand identity, developer credit.
• Component responsibilities:
  • Hero stage — full-viewport dark-navy ground carrying the orbiting 3D obsidian-and-wireframe shard bleeding off the right and bottom edges, with a cyan radial bloom behind it and drifting foreground particles.
  • Wordmark block — MULTI TOOLS MLBB set uppercase at 900 weight, stacked in two lines, with a thin cyan rule beneath and the magenta @Ashleytut tag under the rule.
  • Tool chip row — four bracketed chips [01] DEV ID · [02] BAN CHECK · [03] BULK BAN · [04] BRUTE FORCE, each a real link into its tool page, the active one lit cyan.
  • Launch CTA — a single cyan-outlined LAUNCH CONSOLE control pinned bottom-left above the ticker.
  • Fixed left rail — four numbered tool slots, 88px icon+number on desktop, collapsing to a horizontally scrollable chip strip pinned under the header on mobile.
  • Bottom telemetry ticker — full-width continuous scroll reading MULTI TOOLS MLBB · DEV@ASHleytut · SESSION ACTIVE · PING 12MS, pausing on hover.
• States:

• Loading: hero shard initialises; wordmark, chips, rail, and ticker render immediately as static structure so no readable text or control is ever withheld.
• Empty: not applicable — the landing surface has no user-supplied data.
• Success: the four tool chips and rail slots are live links; the active slot is lit cyan.
• Error / recovery: if the WebGL hero subject fails to initialise, the stage falls back to a static render of the shard silhouette with the cyan bloom retained; all text, chips, rail, and CTA remain fully usable.
• Reduced motion: the shard freezes to a static render, border sweeps stop, and the ticker wraps into static rows.

Dev ID Generator

• Information / state: The generated developer ID, its generation timestamp, and the run status (idle, generating, complete, failed).
• Primary actions: Generate a developer ID; copy the generated ID; generate another.
• Supporting actions: Clear the current result; view the raw result payload.
• Domain entities: Developer ID (value, generated-at timestamp), generation run (status, result).
• Component responsibilities:
  • Input console (left, max 520px) — the generate control and any run parameters, inside a bracket-cornered HUD panel with 1px cyan edges.
  • Results panel (right) — the generated dev ID rendered in JetBrains Mono tabular figures inside a bracket-cornered HUD panel, streaming in character-by-character with a 40ms stagger.
  • Copy control — copies the generated ID to the clipboard and confirms inline.
  • Run status chip — capsule status chip showing idle / generating / complete / failed.
• States:
  • Loading: the generate control shows an in-progress state; the results panel shows a scanning border sweep.
  • Empty: results panel shows a bracketed placeholder reading that no dev ID has been generated yet, with the generate control as the only affordance.
  • Success: the dev ID appears in the results panel with its timestamp and a copy control.
  • Error / recovery: the status chip turns magenta and states the failure; the generate control re-arms so the user can retry immediately, and the previous result, if any, is preserved.
  • Reduced motion: the result renders in a single frame.

Ban Check

• Information / state: The submitted target, the run status, and the returned full ban information for that target.
• Primary actions: Submit a single target for a ban check; read the full ban info; run another check.
• Supporting actions: Clear the target field; copy the returned record.
• Domain entities: Target (the submitted identifier), ban record (full ban information fields returned by the check), check run (status, result).
• Component responsibilities:
  • Input console (left, max 520px) — a single target field and the check control, in a bracket-cornered HUD panel.
  • Results panel (right) — the full ban information rendered as labelled data rows in JetBrains Mono, each row streaming in with a 40ms stagger.
  • Run status chip — capsule chip showing idle / checking / complete / failed.
  • Copy control — copies the returned record.
• States:
  • Loading: the check control shows an in-progress state; the results panel shows a scanning border sweep.
  • Empty: results panel shows a bracketed placeholder prompting for a target.
  • Success: the full ban information for the target is displayed as labelled rows.
  • Error / recovery: the status chip turns magenta and states the failure; the target field retains its value and the check control re-arms so the user can retry or correct the target.
  • Reduced motion: the record renders in a single frame.

Bulk Ban

• Information / state: The submitted list of targets, the run status, per-target progress, and the returned full ban information for each target.
• Primary actions: Submit multiple targets for a bulk ban run; read the full ban info per target; run another batch.
• Supporting actions: Add or remove target rows; clear the list; copy the batch result; arm the destructive confirm by typing the target count.
• Domain entities: Target list (ordered entries), ban record (full ban information per target), bulk run (status, per-target results, counts).
• Component responsibilities:
  • Input console (left, max 520px) — a multi-entry target list and the run control, in a bracket-cornered HUD panel with magenta hazard-striped borders because this is a destructive tool.
  • Confirm control — requires typing the target count before the run arms; until then the run control stays disabled.
  • Results panel (right) — one bracket-cornered HUD row per target, each rendering its full ban information and streaming in with a 40ms stagger.
  • Batch summary — counts of processed, succeeded, and failed targets.
  • Run status chip — capsule chip showing idle / running / complete / failed.
• States:
  • Loading: per-target rows show in-progress markers; the batch summary counts up as results arrive.
  • Empty: results panel shows a bracketed placeholder prompting for targets; the run control is disabled until at least one target is entered and the count is typed.
  • Success: every target has its own full-info row and the batch summary reports the final counts.

• Error / recovery: failed targets are marked individually in magenta with their failure reason while successful rows remain intact; the target list retains its entries and the run control re-arms so the user can retry the failed subset.
• Reduced motion: rows render in a single frame.

Dev ID Brute Force

• Information / state: The submitted developer ID, the run status, live progress, and the brute-force result.
• Primary actions: Submit a developer ID and start the brute-force run; read the result; run again.
• Supporting actions: Stop an in-progress run; copy the result; arm the destructive confirm by typing the target count.
• Domain entities: Developer ID (the submitted input), brute-force run (status, progress, attempts, result).
• Component responsibilities:
  • Input console (left, max 520px) — the developer ID field and the start control, in a bracket-cornered HUD panel with magenta hazard-striped borders because this is a destructive tool.
  • Confirm control — requires typing the target count before the run arms.
  • Progress gauge — a radial gauge with a needle sweep during the run.
  • Results panel (right) — the brute-force result rendered in JetBrains Mono inside a bracket-cornered HUD panel, streaming in with a 40ms stagger.
  • Run status chip — capsule chip showing idle / running / stopped / complete / failed.
• States:
  • Loading: the progress gauge sweeps and the status chip reads running.
  • Empty: results panel shows a bracketed placeholder prompting for a developer ID; the start control is disabled until an ID is entered and the count is typed.
  • Success: the brute-force result is displayed with the run's attempt information.

• Error / recovery: the status chip turns magenta and states the failure; the developer ID field retains its value and the start control re-arms so the user can retry. A user-stopped run reports as stopped and leaves the input intact for a fresh run.
• Reduced motion: the gauge renders as a static progress bar and the result renders in a single frame.

3. Functional Requirements

FR-1 — Branded multi-tool hub (explicit) As an MLBB Tool User, I should open a single hub branded MULTI TOOLS MLBB and credited to Developer@Ashleytut, so that I can see what the tool set is and reach any of its four tools.

• Trigger/input: the user opens the application.
• Observable result: the Landing surface displays the MULTI TOOLS MLBB wordmark, the @Ashleytut developer credit, and the four numbered tool slots.
• Access state: anonymous; no identity required.
• Failure/recovery: if the WebGL hero subject fails, the stage falls back to a static render and all text, chips, rail slots, and the CTA remain usable.
• Continuation: the user selects a tool slot or launches the console.

FR-2 — Flashy UI and background (explicit) As an MLBB Tool User, I should see a "maangas" (flashy/impressive) interface and background, so that the tool set feels like a powerful operator console rather than a plain utility page.

• Trigger/input: any surface is rendered.
• Observable result: the dark-void HUD treatment is applied — near-black navy ground, luminous 1px-edged glass panels, cyan primary accents, magenta reserved for destructive actions and the developer credit, the orbiting 3D hero subject, and the full-width telemetry ticker.
• Access state: anonymous; applies to every surface.
• Failure/recovery: under prefers-reduced-motion the motion stops and a static arrangement is presented; if the 3D subject cannot initialise, a static render is shown.
• Continuation: the user proceeds with any tool.

FR-3 — Generate Dev ID (explicit) As an MLBB Tool User, I should generate a developer ID, so that I have a dev ID to use with the other tools.

• Trigger/input: the user opens Dev ID Generator and activates the generate control.
• Observable result: a developer ID is produced and displayed in the results panel with its generation timestamp and a copy control.
• Access state: anonymous; no identity required.
• Failure/recovery: the run status chip turns magenta and states the failure; the generate control re-arms and any previous result is preserved so the user can retry.
• Continuation: the user copies the ID, generates another, or moves to another tool.

FR-4 — Ban Check with full info (explicit) As an MLBB Tool User, I should submit a single target to a ban check and receive full ban information, so that I can see the complete ban status of that target.

• Trigger/input: the user opens Ban Check, enters one target, and submits the check.
• Observable result: the full ban information for that target is displayed as labelled data rows in the results panel.
• Access state: anonymous; no identity required.
• Failure/recovery: the status chip turns magenta and states the failure; the target field retains its value and the check control re-arms so the user can retry or correct the target.
• Continuation: the user copies the record, runs another check, or moves to another tool.

FR-5 — Bulk Ban with full info (explicit) As an MLBB Tool User, I should submit multiple targets to a bulk ban run and receive full ban information for each, so that I can process a batch of targets in one operation.

• Trigger/input: the user opens Bulk Ban, enters multiple targets, types the target count to arm the destructive confirm, and starts the run.
• Observable result: one bracket-cornered HUD row per target displays that target's full ban information, and a batch summary reports processed, succeeded, and failed counts.
• Access state: anonymous; no identity required.
• Failure/recovery: failed targets are marked individually in magenta with their failure reason while successful rows remain intact; the target list retains its entries and the run control re-arms so the user can retry the failed subset.
• Continuation: the user copies the batch result, runs another batch, or moves to another tool.

FR-6 — Brute Force via Dev ID (explicit) As an MLBB Tool User, I should submit a developer ID to a brute-force run and see its result, so that I can obtain the outcome of the brute-force operation for that dev ID.

• Trigger/input: the user opens Dev ID Brute Force, enters a developer ID, types the target count to arm the destructive confirm, and starts the run.
• Observable result: the progress gauge sweeps during the run and the brute-force result is displayed in the results panel with the run's attempt information.
• Access state: anonymous; no identity required.
• Failure/recovery: the status chip turns magenta and states the failure; the developer ID field retains its value and the start control re-arms so the user can retry. A user-stopped run reports as stopped and leaves the input intact for a fresh run.
• Continuation: the user copies the result, runs again, or moves to another tool.

FR-7 — Four-tool limit (explicit) As Developer@Ashleytut (Tool Owner/Operator), I should have the tool set limited to exactly the four listed tools, so that the build stays within the agreed scope.

• Trigger/input: any surface is rendered or navigated.
• Observable result: only [1] Generate Dev ID, [2] Ban Check full info, [3] Bulk Ban full info, and [4] Brute Force via Dev ID are offered; no additional tool is presented.
• Access state: anonymous; applies to every surface.
• Failure/recovery: not applicable — this is a scope constraint, not a runtime operation.
• Continuation: the user works within the four tools.

FR-8 — Backend execution of the four operations (required_inference) As an MLBB Tool User, I should have each tool's operation executed by the application's backend and its result returned to the page, so that the tool produces real output rather than a client-side placeholder.

• Trigger/input: the user submits a generate, check, bulk, or brute-force request from a tool page.
• Observable result: the backend returns the operation's result payload and the tool page renders it in its results panel.
• Access state: anonymous; no identity required.
• Failure/recovery: a backend failure surfaces as the tool's error state with the input preserved and the control re-armed.
• Continuation: the user reads the result or retries.

FR-9 — Destructive-action arming (explicit) As an MLBB Tool User, I should have the destructive tools (Bulk Ban and Brute Force) require me to type the target count before the run arms, so that an irreversible action cannot be started accidentally.

• Trigger/input: the user enters targets on Bulk Ban or a developer ID on Dev ID Brute Force.
• Observable result: the run control stays disabled and the panel shows magenta hazard-striped borders until the target count is typed correctly; once armed, the run control becomes available.
• Access state: anonymous; no identity required.
• Failure/recovery: an incorrect typed count leaves the control disabled and the panel in its hazard state.
• Continuation: the user starts the run or corrects the count.

4. User Personas

MLBB Tool User

Product context. A Mobile Legends: Bang Bang player or modder, likely in the Philippines and Tagalog-speaking, who needs quick, raw answers about dev IDs and ban status. They arrive at clever-mlbb already knowing what they want and expect the console to feel powerful and immediate.

Primary goal. Run any of the four tools — generate a dev ID, check a single target's full ban info, bulk-check many targets, or brute-force a dev ID — and read the returned full-info results without friction.

Distinct accepted responsibilities. This persona initiates every tool run: they choose the tool from the numbered rail or chip row, supply the input (nothing, one target, many targets, or a developer ID), arm the destructive confirm where required, and read the returned data. They are the only persona that supplies tool inputs.

Relevant inputs and decisions. Which of the four tools to run; the target or targets to check; the developer ID to brute-force; whether to arm and start a destructive run; whether to copy, retry, or move on after a result.

Interactions with other accepted participants. The MLBB Tool User interacts with the application's backend, which executes each operation and returns the result payload. They share the same surfaces and the same tool set as Developer@Ashleytut; there is no handoff, approval, or permission step between them.

Observable success. The tool page displays the requested output — a generated dev ID, a full ban record, a per-target batch of full ban records with a summary, or a brute-force result — inside a bracket-cornered HUD panel, with the input preserved on failure so a retry is one action away.

Developer@Ashleytut (Tool Owner/Operator)

Product context. The named owner of the MULTI TOOLS MLBB build. Their identity is the product's credit line: the @Ashleytut tag appears in magenta on the Landing surface and in the bottom telemetry ticker on every screen.

Primary goal. Present and operate a branded, flashy four-tool console that carries their credit and stays exactly within the agreed tool set.

Distinct accepted responsibilities. This persona owns the branding and scope of the build: the MULTI TOOLS MLBB wordmark and @Ashleytut credit must be present, the UI and background must read as "maangas", and the tool set must remain limited to the four listed tools. They operate the same four tools through the same surfaces as the MLBB Tool User.

Relevant inputs and decisions. The same tool inputs as the MLBB Tool User; decisions about the build's branding and its four-tool boundary.

Interactions with other accepted participants. They share every surface with the MLBB Tool User and are credited on all of them. No differentiated permissions, visibility, or approval relationship exists between the two personas.

Observable success. Every surface shows the MULTI TOOLS MLBB brand and the @Ashleytut credit, the dark-void HUD treatment is applied throughout, and no tool beyond the four listed is offered anywhere in the product.

5. Core User Flows

Flow 1 — MLBB Tool User: reach a tool from the hub

1. The MLBB Tool User opens clever-mlbb and lands on Landing (anonymous; no identity required).
2. The Landing surface presents the MULTI TOOLS MLBB wordmark, the magenta @Ashleytut credit, the orbiting 3D shard, the fixed left rail of four numbered slots, the bracketed tool chip row, and the bottom telemetry ticker.
3. The user selects a tool — either from the rail/chip row ([01] DEV ID, [02] BAN CHECK, [03] BULK BAN, [04] BRUTE FORCE) or via the LAUNCH CONSOLE CTA.
4. The chosen tool page opens with its input console on the left and its results panel on the right.
5. Failure/recovery: if the WebGL hero subject fails to initialise, the stage falls back to a static render and every chip, rail slot, and the CTA remain fully usable.
6. Continuation: the user proceeds to the tool's own flow.

Flow 2 — MLBB Tool User: generate a dev ID

1. The user opens Dev ID Generator from the rail or chip row.
2. The results panel shows a bracketed placeholder stating that no dev ID has been generated yet; the generate control is the only affordance.
3. The user activates the generate control. The status chip reads generating and the results panel shows a scanning border sweep.
4. The backend produces a developer ID and returns it.
5. The dev ID appears in the results panel in JetBrains Mono tabular figures, streaming in character-by-character with a 40ms stagger, alongside its generation timestamp and a copy control.
6. Failure/recovery: if generation fails, the status chip turns magenta and states the failure; the generate control re-arms and any previous result is preserved so the user can retry immediately.
7. Continuation: the user copies the ID, generates another, or moves to another tool.

Flow 3 — MLBB Tool User: check one target's full ban info

1. The user opens Ban Check from the rail or chip row.
2. The results panel shows a bracketed placeholder prompting for a target.
3. The user enters one target in the input console and submits the check. The status chip reads checking and the results panel shows a scanning border sweep.
4. The backend runs the ban check and returns the full ban information for that target.
5. The full ban information is displayed as labelled data rows in JetBrains Mono, each row streaming in with a 40ms stagger, with a copy control for the record.
6. Failure/recovery: if the check fails, the status chip turns magenta and states the failure; the target field retains its value and the check control re-arms so the user can retry or correct the target.
7. Continuation: the user copies the record, runs another check, or moves to another tool.

Flow 4 — MLBB Tool User: bulk-check many targets

1. The user opens Bulk Ban from the rail or chip row. The panel carries magenta hazard-striped borders because this is a destructive tool.
2. The user enters multiple targets into the target list. The run control stays disabled.
3. The user types the target count into the confirm control. Once the count matches, the run control arms.
4. The user starts the run. The status chip reads running; per-target rows show in-progress markers and the batch summary counts up as results arrive.
5. The backend processes the batch and returns full ban information for each target.
6. One bracket-cornered HUD row per target displays that target's full ban information, streaming in with a 40ms stagger, and the batch summary reports processed, succeeded, and failed counts.
7. Failure/recovery: failed targets are marked individually in magenta with their failure reason while successful rows remain intact; the target list retains its entries and the run control re-arms so the user can retry the failed subset.
8. Continuation: the user copies the batch result, runs another batch, or moves to another tool.

Flow 5 — MLBB Tool User: brute-force a dev ID

1. The user opens Dev ID Brute Force from the rail or chip row. The panel carries magenta hazard-striped borders because this is a destructive tool.
2. The user enters a developer ID. The start control stays disabled.
3. The user types the target count into the confirm control. Once the count matches, the start control arms.
4. The user starts the run. The status chip reads running and the radial progress gauge sweeps its needle.
5. The backend runs the brute-force operation and returns its result.
6. The brute-force result is displayed in the results panel in JetBrains Mono, streaming in with a 40ms stagger, with the run's attempt information and a copy control.
7. Failure/recovery: if the run fails, the status chip turns magenta and states the failure; the developer ID field retains its value and the start control re-arms so the user can retry. If the user stops an in-progress run, the status chip reads stopped and the input remains intact for a fresh run.
8. Continuation: the user copies the result, runs again, or moves to another tool.

Flow 6 — Developer@Ashleytut (Tool Owner/Operator): operate and present the branded console

1. Developer@Ashleytut opens clever-mlbb and lands on Landing (anonymous; no identity required).
2. They confirm the MULTI TOOLS MLBB wordmark and the magenta @Ashleytut credit are present, the dark-void HUD treatment is applied, and the rail and chip row offer exactly four tools: [01] DEV ID, [02] BAN CHECK, [03] BULK BAN, [04] BRUTE FORCE.
3. They select any tool from the rail or chip row and operate it exactly as the MLBB Tool User does — supplying the input, arming the destructive confirm where required, and reading the returned full-info results.
4. Observable result: every surface carries the brand and credit, the telemetry ticker scrolls MULTI TOOLS MLBB · DEV@ASHleytut · SESSION ACTIVE · PING 12MS across the bottom, and no tool beyond the four listed is offered anywhere.
5. Failure/recovery: if the 3D hero subject fails to initialise, the static fallback preserves the brand, credit, chips, rail, and CTA.
6. Continuation: the owner/operator continues operating the four tools or returns to the hub.

6. Visuals, Colors and Theme

Muse and headline. Gleb Kuznetsov — Dark-void HUD console for a game-hacking toolset. The interface itself is the hero: deep black ground, luminous volumetric forms, HUD data readouts, thin glowing strokes, and motion as the dominant element. The register is "maangas" — cocky, dangerous, futuristic — never corporate.

Colour tokens (dark mode only)

The near-black navy void covers roughly 70% of every screen. Panels sit on #0D1220 with 1px rgba(0,229,255,0.18) borders and a faint inner glow. Magenta is reserved strictly for destructive actions (Bulk Ban, Brute Force) and the developer credit, so danger always reads magenta and never blue. Body text #EAF2FF on #05070C and on #0D1220 both exceed 12:1 contrast. No gradients as decoration — glow is emitted by elements (radial falloff behind the hero orb, box-shadow bloom on active controls), never painted as a background blob.

Typography

• Headings and body: Space Grotesk. All labels and tool names uppercase with 0.14em tracking. Hero wordmark at 900 weight, 0.92 line-height, clamp(44px, …, 132px).
• Data: JetBrains Mono at tabular spacing so dev IDs, ban counts, and timers align in columns.
• Scale: 1.25 modular — display 132 / 96 / 64 / 44; heading 40 / 28 / 22; body 17 / 15; micro-label 13 uppercase tracked. JetBrains Mono data sizes: 32 / 22 / 15.

Shape language. Sharp-cornered glass panels (2px radius maximum) with 1px luminous edges; thin 1px stroke circuits and radial gauges; hexagonal and capsule status chips; hairline scanlines and bracket corners on every data block, as if the panel were a piece of HUD hardware. Nothing soft or pill-shaped except the live-status dot.

Spacing rhythm. A 4px base unit; 8/12/16/24/40/64 steps. Panels use 24px internal padding on desktop and 16px on mobile. The fixed left rail is 88px wide on desktop; the bottom telemetry ticker is a fixed full-width band.

Imagery style. One crafted real-time 3D subject in the hero: a dark faceted obsidian shard wrapped in a cyan wireframe cage, orbiting slowly with volumetric glow and drifting particles — built in Three.js / React Three Fiber, no stock photography. Supporting imagery is purely generated: radial gauges, waveform meters, hex-grid floor lines, and a magenta hazard-striped band for destructive tools. Never flat clip art, never device mockups.

7. Signature Design Concept

The Orbiting Shard Console. The public entry is a full-viewport black-navy stage. The dominant element is the orbiting 3D obsidian-and-wireframe shard, roughly 60vw wide on desktop, centred in the right two-thirds and bleeding off the right and bottom edges, with a cyan radial bloom behind it and drifting particles in the foreground plane. The wordmark MULTI TOOLS MLBB is set at 132px uppercase Space Grotesk 900 on the left, stacked in two lines, with a thin cyan rule running under it and the developer tag @Ashleytut in magenta caps beneath. Below the wordmark sits a horizontal row of four bracketed tool chips — [01] DEV ID · [02] BAN CHECK · [03] BULK BAN · [04] BRUTE FORCE — each a real link into its tool page, with the active one lit cyan. A single cyan-outlined CTA LAUNCH CONSOLE is pinned bottom-left above the telemetry ticker. There is no centred headline, no subtext paragraph, no blue button, and no gradient blob.

The signature moves that carry through the whole product:

• The orbiting 3D wireframe-caged shard as the hero subject, bleeding off the right edge, with a cyan radial bloom and drifting foreground particles.
• A fixed left rail of numbered tool slots [01]–[04] that becomes a horizontally scrollable chip strip on mobile — the whole product navigable in one gesture, never a hamburger.
• Every data block (dev ID, ban record, bulk result row) renders inside a bracket-cornered HUD panel with 1px cyan edges and a 40ms character-by-character stream-in on return.
• A full-width bottom telemetry ticker scrolling MULTI TOOLS MLBB · DEV@ASHleytut · SESSION ACTIVE · PING 12MS continuously, pausing on hover and wrapping into static rows under prefers-reduced-motion.
• Destructive tools (Bulk Ban, Brute Force) swap the cyan accent for magenta hazard-striped borders and a confirm control that requires typing the target count before it arms.

8. Interaction Model & Motion Direction

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

Landing Hero Motion Brief

• Focal subject: the dark faceted obsidian shard wrapped in a cyan wireframe cage, orbiting slowly in the right two-thirds of the stage with volumetric glow and drifting foreground particles.
• Input → transformation → outcome thesis: as the page loads, the shard resolves from a dim silhouette into a fully lit, slowly orbiting form while the cyan radial bloom behind it expands; the wordmark, cyan rule, magenta credit, four bracketed tool chips, and the LAUNCH CONSOLE CTA settle into place around it. The outcome is a live, dangerous-feeling console whose four tools are immediately selectable — no scroll, no reveal gate.
• Motion vocabulary: slow continuous orbit of the shard; scanning light sweeps across panel borders every 6s; data rows streaming in character-by-character with a 40ms stagger when a tool returns results; a needle-sweep on the progress gauge during Brute Force; scroll-scrubbed parallax shifting the hero orb and the ticker at different rates. All loops are slow and low-amplitude; nothing bounces.
• Composed first frame: black-navy void; the shard already visible at partial brightness, bleeding off the right and bottom edges; the two-line MULTI TOOLS MLBB wordmark at 132px on the left with the cyan rule and magenta @Ashleytut beneath; the four bracketed chips below the wordmark; the cyan-outlined LAUNCH CONSOLE pinned bottom-left; the telemetry ticker already scrolling along the bottom edge.
• Reduced-motion state: the orb freezes to a static render, border sweeps stop, the ticker wraps into static rows, and results render in a single frame. All text, chips, rail slots, and the CTA remain fully readable and operable.

Landing Hero 3D Scene Brief — DIRECTION-DERIVED

• Object: one crafted real-time subject — a dark faceted obsidian shard enclosed in a thin cyan wireframe cage, with a soft volumetric glow and a sparse field of drifting particles in the foreground plane.
• Defining state shown: the shard's slow orbit and the cyan bloom behind it express the console's "live and armed" state; the four bracketed tool chips and the lit active slot sit in front of it as the product's defining navigation.
• Behaviour: continuous slow orbit with low-amplitude drift; scroll-scrubbed parallax moves the shard and the ticker at different rates; the shard never occludes the wordmark, the chips, the rail, or the CTA.
• Reduced motion: the shard renders as a single static frame with the bloom retained; no orbit, no parallax, no particle drift.

9. Non-Functional Requirements

NFR-1 — Branding presence (explicit) The string MULTI TOOLS MLBB and the credit Developer@Ashleytut must appear on the Landing surface, and the @Ashleytut credit must appear in the bottom telemetry ticker on every surface. Rationale: the user explicitly required this branding and credit.

NFR-2 — Flashy presentation (explicit) The UI and background must read as "maangas" — dark-void HUD treatment, luminous panel edges, cyan primary accents, magenta reserved for destructive actions and the developer credit, and the orbiting 3D hero subject. Rationale: the user explicitly required a flashy UI and background.

NFR-3 — Readable text and controls at every viewport (explicit) At 375px, 768px, and 1280px, headlines, wordmarks, labels, numbers, card text, and controls must stay entirely inside the viewport and their container, wrapping or scaling (for example font-size: clamp(...) with its mobile size) to fit, and no other element may cover any part of them. Imagery, decoration, and motion may be cropped, bled off an edge, rotated, overlapped, or cut as the creative direction asks, as long as they cover no readable text or control. Moving and scrollable content (the telemetry ticker, the mobile chip strip) may cross the viewport or container edge by design; every item must become fully readable as it passes or scrolls. Rationale: explicit readability constraint in the creative direction.

NFR-4 — Reduced-motion support (explicit) Under prefers-reduced-motion, the hero orb freezes to a static render, border sweeps stop, the ticker wraps into static rows, and results render in a single frame. Rationale: explicit requirement in the creative direction.

NFR-5 — Responsive rail behaviour (explicit) The fixed left rail of four numbered tool slots stays visible at every breakpoint: 88px icon+number on desktop, collapsing to a horizontally scrollable chip strip pinned under the header on mobile. Rationale: explicit layout requirement in the creative direction.

NFR-6 — Contrast (explicit) Body text #EAF2FF on #05070C and on #0D1220 must exceed 12:1 contrast; muted #7C8AA5 is used only for micro-labels and never below 13px. Rationale: explicit requirement in the creative direction.

NFR-7 — Backend execution (required_inference) The four tool operations must be executed by the application's backend and their results returned to the page, because the tools produce real output (a generated dev ID, ban records, batch results, a brute-force result) that cannot be produced client-side. Rationale: causally necessary for the accepted tool outcomes.

NFR-8 — Input preservation on failure (required_inference) On any tool failure, the user's input must be preserved and the run control re-armed so recovery is a single action. Rationale: causally necessary for the accepted failure/recovery behaviour of each tool.

10. Tech Stack

• Frontend: React (web), with Three.js / React Three Fiber for the hero 3D subject. (React and R3F are required by the creative direction's WebGL hero; React is the default web framework.)
• Styling: Space Grotesk (headings and body) and JetBrains Mono (data) via a webfont loader; CSS custom properties for the colour tokens in Section 6. (Fonts and tokens are explicit in the creative direction.)
• Backend: Python / FastAPI service exposing the four tool operations — dev-ID generation, single ban check, bulk ban, and dev-ID brute force — and returning structured full-info payloads. (Default backend choice; the source specifies no backend technology.)
• Storage: none required for current scope — no accounts, no durable per-user state, and no history is accepted. (Default — not specified by user.)
• Packaging: Docker with docker-compose.yml running the frontend and the FastAPI backend as the two services. (Default — not specified by user.)
• Kubernetes: not required for current scope. (Default — not specified by user.)

11. Assumptions and Constraints

Assumptions

1. The four tools are executed by the application's own backend; no third-party provider surface or external destination is specified for them. (required_inference)
2. Tool inputs and results are per-run and are not persisted or bound to a returning identity, because no account, session, or history is accepted. (required_inference)
3. The LAUNCH CONSOLE CTA on Landing enters the tool set; the four numbered rail slots and bracketed chips are the direct links into the four tool pages. (required_inference)
4. The telemetry ticker text MULTI TOOLS MLBB · DEV@ASHleytut · SESSION ACTIVE · PING 12MS is presentational branding, not a live system metric. (required_inference)
5. The confirm control on destructive tools arms when the typed count matches the number of entered targets. (required_inference)

Constraints

1. Branding must read MULTI TOOLS MLBB and credit Developer@Ashleytut. (explicit)
2. The UI and background must be "maangas" (flashy/impressive). (explicit)
3. The tool set is limited to the four listed tools: [1] Generate Dev ID, [2] Ban Check full info, [3] Bulk Ban full info, [4] Brute Force via Dev ID. (explicit)
4. No account creation, login, or user profile system is in scope. (explicit by omission — the source establishes no identity requirement)
5. No role-based permissions or differentiated visibility between the two personas. (explicit by omission — the source establishes no differentiated control)
6. The generic indigo/blue-on-white SaaS template is forbidden; the surface is dark navy with cyan and magenta only. (explicit in the creative direction)
7. Inter, Roboto, Arial, Poppins, Lato, and system-ui are forbidden for headings and body. (explicit in the creative direction)
8. Corners stay at 2px maximum with luminous hairline edges; no soft pill-shaped buttons or large border radii. (explicit in the creative direction)
9. No bouncy or springy easing — motion is slow, orbital, and low-amplitude only. (explicit in the creative direction)
10. No photographic stock imagery, device mockups, friendly illustration, emoji, or rounded character art. (explicit in the creative direction)

12. Glossary

• MLBB — Mobile Legends: Bang Bang, the game the tool set targets.
• MULTI TOOLS MLBB — the product's brand name, credited to Developer@Ashleytut.
• Dev ID — a developer ID; the value produced by the Generate Dev ID tool and the input consumed by the Brute Force via Dev ID tool.
• Ban Check — the tool that accepts one target and returns that target's full ban information.
• Bulk Ban — the tool that accepts multiple targets and returns full ban information for each.
• Brute Force via Dev ID — the tool that accepts a developer ID, runs a brute-force operation, and displays its result.
• Full info — the complete set of ban information fields returned by a ban check or bulk ban run.
• Target — the identifier submitted to a ban check or bulk ban run.
• HUD panel — a bracket-cornered data block with 1px cyan edges and a 40ms character-by-character stream-in on return.
• Telemetry ticker — the full-width bottom band scrolling MULTI TOOLS MLBB · DEV@ASHleytut · SESSION ACTIVE · PING 12MS.
• Maangas — Tagalog for flashy, impressive, cocky; the required emotional register of the UI and background.
• Destructive tool — Bulk Ban and Dev ID Brute Force; these swap the cyan accent for magenta hazard-striped borders and require typing the target count before arming.