System Requirements Document for gentle-project

1. Introduction

gentle-project is a first-party web instrument for building, reviewing, and operating a crypto scalping trading strategy on Binance-supported perpetual futures (مضاربي فيوتشرز سكالبينق). The product exists because the requester — acting as an expert in crypto trading algorithms and in the mathematics of trade construction — asked for a scalping strategy for the crypto coins that Binance futures markets support, and for that strategy to be usable rather than merely described.

The audience is therefore two distinct working roles inside the same product:

• the Crypto Scalping Strategy Developer, who authors the mathematical and algorithmic rules of the strategy (order-book imbalance, VWAP deviation, ATR-scaled stops, funding-rate carry, R multiples) and configures them for Binance-supported perpetual futures markets; and
• the Scalping Trader / Strategy Operator, who runs the configured strategy against supported Binance futures markets during short scalping sessions, reads its entry/exit signals and parameters in seconds, and acts on them without re-deriving the underlying mathematics.

The product is an instrument for reading noise, not a hype trading surface. Its visual and interaction language is a dark, museum-calm, data-physical one: a generative particle field derived from Binance perpetual market data, hard-edged zero-radius panels, monospace numerics that never shift column width, and a single hot amber accent reserved for actionable state.

2. System Overview

gentle-project is delivered as a custom first-party web application with application-owned identity and a backend integration to Binance-supported perpetual futures market data. It contains six destinations in a fixed order: Landing, Sign Up, Login, Strategy Library, Strategy Builder, and Signals.

Current accepted behavior:

• A public Landing surface explains the Binance futures scalping strategy product, its intended traders, and its algorithmic purpose, and is the anonymous entry point into the product.
• Sign Up provides self-service enrollment for a new strategy developer or strategy operator; Login provides returning verification so a user can resume access to saved strategy configurations and protected signal logic.
• Strategy Library is the revisitable overview where the developer reviews configured scalping strategies and selects one for refinement or use.
• Strategy Builder is the focused workspace where the developer defines mathematical rules, algorithmic parameters, and the Binance-supported futures scalping configuration.
• Signals is the protected working destination where the operator reads the configured scalping parameters and the entry/exit signal logic for supported Binance futures markets.

Actors: the two accepted human personas above, plus typed non-persona actors — the Binance-supported perpetual futures market-data source (external provider) and the application's own strategy-evaluation process (system process).

Narrow exclusions: the strategy scope is limited to crypto coins supported by Binance futures markets, and the strategy style is scalping (short-term) on futures — not spot and not long-horizon trading. No other market, venue, or horizon is in scope.

2a. Product Interpretation and Delivery Boundary

Delivery ownership. The product's human-facing work is delivered as first-party custom UI owned by this application. The application owns the identity that binds a saved strategy configuration and its protected signal logic to the correct person, so that a developer can leave and return to a strategy and an operator can resume a session against the same configured parameters. Market data itself is not owned by this application: Binance-supported perpetual futures market data is an external provider responsibility, consumed by the application to evaluate the configured strategy and produce usable scalping signals.

Access boundary. Landing, Sign Up, and Login are anonymously reachable. Strategy Library, Strategy Builder, and Signals require login. The interaction that establishes access to the protected destinations lives on Sign Up and Login, which are themselves anonymous — a protected destination never owns the interaction that grants access to itself. Identity here is continuity of ownership over a user's own saved strategy configurations and signal workflows; it does not create differentiated permissions, role-based visibility, or permission controls over shared product state.

Current vs. future boundary. Everything described in this document is current. No future-horizon capability is accepted by the source; nothing in this document should be read as committing to automated order placement, exchange account connection, portfolio or position management, backtesting infrastructure, or any market beyond Binance-supported perpetual futures.

2b. Source Content Inventory

Not applicable — no reference directive in this project declares content_source, so no source content inventory is rendered.

2c. Page Content and Component Coverage

Landing

• Information / state: anonymous public entry. Explains what the product is (a scalping strategy for Binance-supported perpetual futures), who it is for (the strategy developer and the scalping operator), and its algorithmic purpose. Presents the product's data-physical identity: a full-bleed generative particle field derived from Binance perpetual tick data, bleeding off all four edges.
• Primary action: proceed to build the strategy — a single amber CTA that leads an unauthenticated visitor into the identity boundary (Sign Up) and a returning user into Login.
• Supporting actions: read the headline and supporting explanation; read the live monospace ticker strip of three Binance symbols with price and funding rate; follow the link to Login.
• Domain entities: Binance perpetual symbol, price, funding rate, scalping horizon (1s–5s), strategy concept.
• Component responsibilities: full-bleed generative canvas (WebGL/R3F) seeded from Binance perpetual tick data; asymmetric overlay column pinned to the right five columns on LTR and mirrored to the left five columns on RTL Arabic via logical properties; 12px amber rule above the headline; display headline at clamp(2.75rem, 7vw, 5.5rem); 48px-tall amber CTA; live monospace ticker strip with tabular figures; bottom-left 2px teal line with a 14px monospace caption BINANCE PERPETUAL · 1s–5s SCALP HORIZON; persistent 12-column grid with hairlines at 1/3 and 2/3.
• States: loading — canvas initializes and the ticker strip shows its first values; empty — not applicable (no user-owned collection on this surface); success — canvas drifting at museum pace with live ticker values counting in amber and teal; error — if market data cannot be reached, the canvas renders from a seeded field and the ticker strip shows its last known or seeded values without blocking the CTA; recovery — the field continues to render and the CTA remains fully usable, so the visitor is never blocked from entering the product by a data outage.

Sign Up

• Information / state: anonymous enrollment surface. Establishes the identity that will own saved strategy configurations and protected signal workflows.
• Primary action: create the account and enter the product.
• Supporting actions: move to Login if the visitor already has an account; correct invalid input.
• Domain entities: account identity (credential and its verification), the user's future strategy ownership.
• Component responsibilities: underlined input fields (not boxes) on the grid; rectangular submit control with a 2px amber left rule; inline validation messaging in muted #7A7A8C at 14px+ semibold, never used for critical numbers; hairline-separated layout consistent with the rest of the instrument.
• States: loading — submission in progress with the control held in a pending state; empty — pristine form with no values entered; success — identity established and the user continues into the protected product; error — invalid or already-used credentials reported inline against the offending field with the entered values preserved; recovery — the user corrects the field and resubmits, or switches to Login, without losing the rest of the form.

Login

• Information / state: anonymous returning-verification surface. Re-establishes the identity that owns saved strategy configurations and protected signal workflows.
• Primary action: verify and resume access to the protected destinations.
• Supporting actions: move to Sign Up if the visitor has no account; correct invalid input.
• Domain entities: account identity (credential and its verification), the user's saved strategies and signal workflows.
• Component responsibilities: underlined input fields; rectangular submit control with a 2px amber left rule; inline failure messaging; consistent hairline grid.
• States: loading — verification in progress; empty — pristine form; success — verified and returned to the protected destination the user was seeking; error — credentials rejected, reported inline without disclosing which factor failed beyond what is necessary; recovery — the user retries, or moves to Sign Up, with the form otherwise intact.

Strategy Library

• Information / state: login-protected overview of the strategies the signed-in developer has configured, each with enough identity to recognize it (name and its Binance-supported futures scalping configuration summary).
• Primary action: select a configured strategy to refine it in Strategy Builder, or to use it.
• Supporting actions: start a new strategy configuration; review the parameters of an existing one before opening it.
• Domain entities: strategy configuration, its mathematical/algorithmic parameter set, its target Binance-supported perpetual futures symbols, its scalping horizon, its last-modified state.
• Component responsibilities: ruled list/table of strategies with monospace numerics aligned to the baseline grid; hard-edged #101018 panels with 1px #22222E hairlines and no shadow; rectangular controls with a 2px amber left rule; persistent left rail (80px desktop, bottom tab bar at 375px) carrying Library, Builder, Signals, Account.
• States: loading — the list resolves with a placeholder ruled structure; empty — no strategies configured yet, with a clear path into Strategy Builder to create the first one; success — the developer's strategies listed and selectable; error — the list cannot be loaded, reported without discarding the developer's place in the product; recovery — retry the load, or proceed directly into Strategy Builder to create or continue work.

Strategy Builder

• Information / state: login-protected focused workspace for defining the strategy's mathematical rules, algorithmic parameters, and Binance-supported futures scalping configuration. Two hairline-separated panes: the parameter form on the reading side and a live signal preview on the other.
• Primary action: define and save the strategy configuration — mathematical rules, algorithmic parameters, and the Binance-supported perpetual futures scalping settings.
• Supporting actions: adjust individual parameters and observe the preview re-render; select the Binance-supported symbols the strategy targets; set the scalping horizon; review the resulting entry/exit logic before saving.
• Domain entities: strategy configuration; mathematical rule definitions; algorithmic parameters (including order-book imbalance, VWAP deviation, ATR-scaled stops, funding-rate carry, and R multiples as the strategy's mathematical vocabulary); target Binance-supported perpetual futures symbols; scalping horizon; live signal preview output.
• Component responsibilities: underlined input fields rather than boxes; circular gauge rings (thin 1px stroke, one amber arc) framing live metrics such as volatility, funding carry, and win-rate, with the value set in monospace at the ring's centre; live signal preview pane that re-renders as parameters change; hairline separator between panes; at 375px the preview collapses to a sticky 72px strip of the three live numbers; uppercase 11px/0.18em letterspaced micro-labels for data categories (ORDER BOOK, FUNDING, ATR STOP).
• States: loading — the workspace and its preview initialize; empty — a new strategy with no parameters set yet, with the form ready for the first rule; success — parameters accepted, preview re-rendered, configuration saved and available in Strategy Library; error — an invalid or incomplete parameter set is reported against the offending field and the preview does not present a misleading signal; recovery — the developer corrects the parameter and the preview re-renders, with previously entered values preserved.

Signals

• Information / state: login-protected working destination presenting the configured scalping parameters and the entry/exit signal logic for supported Binance futures markets, as a dense ruled table — symbol, side, entry, stop, target, R, confidence.
• Primary action: read the current entry/exit signal for a supported Binance perpetual futures symbol and act on it during a scalping session.
• Supporting actions: scan the table for the symbol and side of interest; read the configured parameters behind a signal; observe live values updating.
• Domain entities: signal row (symbol, side, entry, stop, target, R, confidence); configured scalping parameters; Binance-supported perpetual futures market data (price, funding rate, order-book depth, trade intensity); scalping horizon.
• Component responsibilities: dense ruled table with a 3px left rule per row — amber for LONG, teal for SHORT; entry/stop/target/R columns in IBM Plex Mono with tabular figures aligned to the baseline grid; numbers counting to their new value over 600ms with easing; horizontal scrolling contained inside the table container with no page-level horizontal overflow; circular gauge rings for live metrics; persistent left rail (80px desktop, bottom tab bar at 375px).
• States: loading — the table resolves against current market data; empty — no signal currently qualifies for the configured strategy, stated plainly rather than filled with placeholder rows; success — qualifying signals presented with side, entry, stop, target, R, and confidence readable at a glance; error — market data unavailable or the configured strategy cannot be evaluated, reported without presenting stale values as live; recovery — the destination retries against the market-data source and resumes presenting signals, and the operator can return to Strategy Builder to adjust the configuration if no signal qualifies.

3. Functional Requirements

FR-1 — Build a Binance futures scalping strategy. As a Crypto Scalping Strategy Developer, I should be able to build a crypto trading strategy for scalping on Binance-supported perpetual futures (مضاربي فيوتشرز سكالبينق), so that I have a defined, usable strategy rather than an informal idea. Provenance: explicit. Lifecycle: initiated by the developer in Strategy Builder; the indispensable participant is the Scalping Trader / Strategy Operator, who must be able to read the resulting configuration and its signals on Signals; the authoritative state is the saved strategy configuration; failure is an invalid or incomplete parameter set, recovered by correcting the offending field with prior values preserved; continuation is the saved strategy appearing in Strategy Library and its signals being readable on Signals.

FR-2 — Ground the strategy in trading algorithms and trading mathematics. As a Crypto Scalping Strategy Developer, I should be able to express the strategy through explicit mathematical and algorithmic rules and parameters, so that the strategy's behavior is derived from trading mathematics rather than asserted. Provenance: explicit. Lifecycle: initiated by the developer in Strategy Builder; the observable result is a parameter set whose rules are visible and whose live preview re-renders as they change; failure is an incoherent parameter set, recovered by correction with the preview re-rendering; continuation is saving the configuration and reviewing it in Strategy Library.

FR-3 — Target only Binance-supported crypto coins. As a Crypto Scalping Strategy Developer, I should be able to select the crypto coins the strategy targets from those supported by Binance futures markets, so that the strategy only ever evaluates markets that exist on the intended venue. Provenance: explicit. Lifecycle: initiated by the developer in Strategy Builder; the observable result is a configuration whose target symbols are Binance-supported perpetual futures; failure is a symbol outside that set, which cannot be configured; continuation is the configured symbols appearing in the strategy's signals on Signals.

FR-4 — Keep the strategy scalping-style on futures. As a Crypto Scalping Strategy Developer, I should be able to configure the strategy for short-term scalping on futures, so that its parameters and signals match a scalping horizon rather than spot or long-horizon trading. Provenance: explicit. Lifecycle: initiated by the developer in Strategy Builder; the observable result is a configuration whose horizon and parameters are scalping-scale; failure is a configuration that does not express a scalping horizon, recovered by adjusting the horizon and parameters; continuation is signals presented on Signals at that horizon.

FR-5 — Self-service enrollment. As a new Crypto Scalping Strategy Developer or Scalping Trader / Strategy Operator, I should be able to enroll myself on Sign Up, so that I can own saved strategy configurations and reach the protected signal workflows without an invitation or provisioning step. Provenance: required_inference. Lifecycle: initiated anonymously on Sign Up; the observable result is an established identity that owns the user's strategies; failure is invalid or already-used credentials, reported inline with entered values preserved; continuation is entry into the protected product.

FR-6 — Returning verification. As a returning Crypto Scalping Strategy Developer or Scalping Trader / Strategy Operator, I should be able to verify myself on Login, so that I can resume access to my saved strategy configurations and protected signal logic. Provenance: required_inference. Lifecycle: initiated anonymously on Login; the observable result is a verified session returned to the protected destination the user sought; failure is rejected credentials, reported inline; continuation is resuming work in Strategy Library, Strategy Builder, or Signals.

FR-7 — Review configured strategies. As a Crypto Scalping Strategy Developer, I should be able to review my configured scalping strategies in Strategy Library and select one for refinement or use, so that I can return to prior work instead of rebuilding it. Provenance: required_inference. Lifecycle: initiated by the developer in Strategy Library; the observable result is a selectable list of the developer's own strategies; failure is a list that cannot be loaded, recovered by retrying or proceeding into Strategy Builder; continuation is opening the selected strategy in Strategy Builder or using it.

FR-8 — Define and save the strategy configuration. As a Crypto Scalping Strategy Developer, I should be able to define mathematical rules, algorithmic parameters, and the Binance-supported futures scalping configuration in Strategy Builder and save it, so that the strategy exists as a durable configuration. Provenance: required_inference. Lifecycle: initiated by the developer in Strategy Builder; the observable result is a saved configuration with a re-rendered live signal preview; failure is an invalid or incomplete parameter set, recovered by correction with prior values preserved; continuation is the configuration appearing in Strategy Library.

FR-9 — Read scalping signals for supported Binance futures markets. As a Scalping Trader / Strategy Operator, I should be able to read the configured scalping parameters and the entry/exit signal logic for supported Binance futures markets on Signals, so that I can act during a short scalping session without re-deriving the underlying mathematics. Provenance: required_inference. Lifecycle: initiated by the operator on Signals; the indispensable participant is the Crypto Scalping Strategy Developer, whose saved configuration is what the operator is reading; the authoritative state is the current signal set for the configured strategy; failure is unavailable market data or an unevaluable configuration, reported without presenting stale values as live; continuation is acting on the signal, or returning to Strategy Builder to adjust the configuration.

FR-10 — Consume Binance-supported perpetual futures market data. As the application, I should consume Binance-supported perpetual futures market data to evaluate the configured strategy and produce usable scalping signals, so that the signals the operator reads reflect the markets the strategy targets. Provenance: required_inference. Lifecycle: system process supporting FR-9; the human-facing interaction it supports is owned by Signals; failure is an unreachable or unusable market-data source, surfaced on Signals as an error state rather than as stale live values; continuation is resuming evaluation when the source is available.

4. User Personas

Crypto Scalping Strategy Developer

Product context. This persona is the one who asked for the product: an expert in crypto trading algorithms and in the mathematics of trade construction, working on a scalping strategy for the crypto coins Binance futures markets support. Their work is authoring, not watching — they are the person who decides what the strategy's rules are and what its parameters mean.

Primary goal. To produce a defined, saved scalping strategy for Binance-supported perpetual futures whose behavior follows from explicit mathematical and algorithmic rules, and to be able to return to it and refine it.

Distinct accepted responsibilities. Defining the strategy's mathematical rules and algorithmic parameters; selecting the Binance-supported perpetual futures symbols the strategy targets; setting the scalping horizon and the parameters that express it; saving the configuration; reviewing configured strategies and selecting one for refinement or use.

Relevant inputs and decisions. The mathematical vocabulary of the strategy — order-book imbalance, VWAP deviation, ATR-scaled stops, funding-rate carry, R multiples — and the decision of which of these govern entry and exit; the choice of target symbols from the Binance-supported set; the choice of scalping horizon; the decision to save a configuration or keep refining it.

Interactions with other accepted participants. The developer's saved configuration is what the Scalping Trader / Strategy Operator reads on Signals. The developer's work is only complete when the operator can follow the resulting signals without re-deriving the mathematics, so the developer's success is observable on a surface the developer does not operate.

Observable success. A saved strategy configuration appears in Strategy Library, its parameters are visible and coherent, and its entry/exit logic is presented on Signals for the Binance-supported symbols it targets.

Scalping Trader / Strategy Operator

Product context. This persona runs the strategy during short scalping sessions on Binance-supported perpetual futures. Their working context is time-critical: they read a signal in seconds and act, and they must be able to trust that what they are reading is the developer's configured logic rather than a re-derivation of it.

Primary goal. To read the configured scalping parameters and the current entry/exit signals for supported Binance futures markets quickly enough to act on them during a session.

Distinct accepted responsibilities. Reading the configured scalping parameters behind a signal; reading the current entry/exit signal for a supported Binance perpetual futures symbol — its side, entry, stop, target, R, and confidence; acting on that signal during a scalping session; recognizing when no signal currently qualifies rather than treating an empty readout as a signal.

Relevant inputs and decisions. The signal row itself (symbol, side, entry, stop, target, R, confidence); the configured parameters behind it; the decision to act on a presented signal or to wait; the decision to ask for a configuration change when no signal qualifies.

Interactions with other accepted participants. The operator consumes the Crypto Scalping Strategy Developer's saved configuration; the operator's need to read signals without re-deriving the mathematics is the reason the developer's parameters must be legible on Signals. The operator does not author the strategy's mathematics.

Observable success. The operator can read a qualifying signal's side, entry, stop, target, R, and confidence at a glance, with LONG and SHORT distinguishable instantly, and can tell the difference between "no signal qualifies" and "market data is unavailable."

5. Core User Flows

Flow A — A new developer enrolls and reaches the protected product

1. The visitor arrives on Landing and reads what the product is: a scalping strategy for Binance-supported perpetual futures, for a strategy developer and a scalping operator.
2. The visitor selects the amber CTA to begin building the strategy.
3. Because the visitor has no identity yet, the product presents Sign Up.
4. On Sign Up, the visitor enters their credentials in the underlined fields and submits.
5. Observable result: the identity is established and the visitor enters the protected product.
6. Failure / recovery: if the credentials are invalid or already in use, the error is reported inline against the offending field and the entered values are preserved; the visitor corrects the field and resubmits, or moves to Login.
7. Next step: the developer continues into Strategy Library or directly into Strategy Builder.

Flow B — A returning developer verifies and resumes saved work

1. The developer arrives on Landing and selects the path into Login.
2. On Login, the developer enters their credentials and submits.
3. Observable result: the session is verified and the developer is returned to the protected destination they were seeking.
4. Failure / recovery: if verification fails, the failure is reported inline and the developer retries, or moves to Sign Up; the form is otherwise intact.
5. Next step: the developer opens Strategy Library to review configured strategies, or Strategy Builder to continue refining one.

Flow C — The developer builds and saves a Binance futures scalping strategy

1. The developer opens Strategy Builder from the left rail (or from Strategy Library).
2. In the parameter pane, the developer defines the strategy's mathematical rules and algorithmic parameters — the vocabulary of order-book imbalance, VWAP deviation, ATR-scaled stops, funding-rate carry, and R multiples.
3. The developer selects the crypto coins the strategy targets from those supported by Binance futures markets, and sets the scalping horizon.
4. Observable result: the live signal preview in the second pane re-renders as parameters change, and the circular gauge rings framing volatility, funding carry, and win-rate update with their values set in monospace at the ring's centre.
5. Failure / recovery: if a parameter is invalid or the set is incomplete, the error is reported against the offending field, the preview does not present a misleading signal, and previously entered values are preserved; the developer corrects the parameter and the preview re-renders.
6. The developer saves the configuration.
7. Observable result: the saved strategy appears in Strategy Library.
8. Next step: the developer refines it further, or the Scalping Trader / Strategy Operator reads its signals on Signals.

Flow D — The developer reviews configured strategies and selects one

1. The developer opens Strategy Library.
2. Observable result: the developer's configured scalping strategies are listed with enough identity to recognize each one and its Binance-supported futures scalping configuration summary.
3. Empty state: if no strategy is configured yet, the library states this plainly and offers a clear path into Strategy Builder to create the first one.
4. Failure / recovery: if the list cannot be loaded, the failure is reported without discarding the developer's place in the product; the developer retries, or proceeds directly into Strategy Builder.
5. The developer selects a strategy.
6. Next step: the selected strategy opens in Strategy Builder for refinement, or is used as the configuration behind Signals.

Flow E — The operator reads scalping signals during a session

1. The operator verifies on Login and opens Signals.
2. Observable result: the dense ruled table presents the configured scalping parameters and the entry/exit signal logic for supported Binance futures markets — symbol, side, entry, stop, target, R, confidence — with each row's side marked by a 3px amber (LONG) or teal (SHORT) left rule and the numeric columns in tabular monospace aligned to the baseline grid.
3. The operator scans for the symbol and side of interest; live values count to their new values over 600ms with easing, and the digits never shift column width.
4. The operator reads the configured parameters behind a signal to confirm what the strategy is doing.
5. Observable result: the operator acts on the signal during the scalping session without re-deriving the underlying mathematics.
6. Empty state: if no signal currently qualifies for the configured strategy, the destination states this plainly rather than filling the table with placeholder rows.
7. Failure / recovery: if market data is unavailable or the configured strategy cannot be evaluated, the destination reports this and does not present stale values as live; the destination retries against the market-data source and resumes presenting signals.
8. Next step: the operator continues the session, or asks the Crypto Scalping Strategy Developer to adjust the configuration in Strategy Builder when no signal qualifies.

Flow F — Market data supports the operator's readout

1. The application consumes Binance-supported perpetual futures market data.
2. Observable result: the configured strategy is evaluated against that data and usable scalping signals are produced for the symbols the strategy targets.
3. Failure / recovery: if the source is unreachable or unusable, the failure surfaces on Signals as an error state rather than as stale live values; evaluation resumes when the source is available.
4. Next step: the operator's readout on Signals reflects the markets the strategy targets.

6. Visuals Colors and Theme

Muse and headline. Refik Anadol — data made physical: scalping signals as a living particle field. The product must read as a scientific instrument for reading noise, not a hype trading app, and must stay legible in Arabic-friendly RTL layout at speed.

Mode. Dark mode only.

Colour tokens (exact hex, by role).

Amber #F2A63B is the single hot signal colour and is used only for actionable state — never decoration. Teal-mint #4FE3C1 is the counter-signal so long/short read instantly without red/green clichés. The full flow spectrum appears only inside the generative canvas, never on text or controls. Body text #EDEDF2 on #07070B is approximately 16:1 contrast.

Typography.

• Headings: Space Grotesk, weights 500–700, tracking -0.02em on display sizes, sentence case for editorial headlines; uppercase 11px / 0.18em letterspaced micro-labels for data categories (ORDER BOOK, FUNDING, ATR STOP). Scale does the shouting, not weight.
• Numerics: IBM Plex Mono with tabular figures at 1.05 line-height for all readouts — price, basis points, leverage, PnL, R multiples — so digits never shift column width as they tick.
• Body: IBM Plex Sans.
• Type scale: 1.333 modular on a 4px baseline — 12 / 14 / 16 / 21 / 28 / 38 / 50 / 67 / 89px. Display clamp(2.75rem, 7vw, 5.5rem) for the hero; clamp(1.75rem, 3.5vw, 2.375rem) for section heads; 16px body; 14px table cells; 12px micro-labels.

Shape language. Zero-radius data surfaces: panels are hard-edged rectangles with 1px #22222E borders and no shadow, like plates of glass laid on black. The only curves in the product are the circular gauge rings that frame live metrics and the flowing particle/flow-field curves of the generative canvas. Buttons are rectangular with a 2px amber left rule rather than pills; inputs are underlined fields, not boxes. Long vertical hairlines at 1/3 and 2/3 mark the grid on every page so all screens feel like one instrument.

Spacing rhythm. 4px baseline grid; 12-column layout with a fixed left rail (80px on desktop, bottom tab bar at 375px) carrying Library, Builder, Signals, Account; hairline separators rather than gaps or shadows between panes.

Imagery style. No stock photography, no device mockups, no 3D coins. The single image system is generative: flow fields, particle density clouds, and depth-heatmaps rendered from the product's own market data (order-book depth, trade intensity, funding history) in the Anadol spectrum. Supporting imagery is schematic — candlestick and depth-chart line art in 1px hairlines, plus small monospace "data cards" showing raw JSON-ish market snapshots. Every visual is either data or the diagram of data.

7. Signature Design Concept

The instrument field. The public entry is a full-bleed #07070B field in which a slow generative particle flow — derived from BTCUSDT and ETHUSDT perpetual tick data — occupies the entire viewport and bleeds off all four edges. Nothing is centred and nothing is a card.

Over the field, an overlay column is pinned to the right five columns on LTR and mirrored to the left five columns on RTL Arabic via logical properties, sitting flush on the grid line. It holds a four-line Space Grotesk headline at clamp(2.75rem, 7vw, 5.5rem) — اقرأ الفوضى. / نفّذ بدقة. — with a 12px amber rule above it and a single 48px-tall amber CTA beneath it (ابدأ بناء الاستراتيجية). Beneath the CTA, a live monospace ticker strip of three real Binance symbols shows price and funding rate counting in amber and teal with tabular figures.

At the bottom-left of the viewport, a 2px teal line carries a 14px monospace caption: BINANCE PERPETUAL · 1s–5s SCALP HORIZON.

The only colour on the screen besides the data canvas is the one amber CTA. The concept recomposes only accepted content — the product's purpose, its intended traders, its algorithmic character, and live Binance perpetual market data — into a single composed first frame; it introduces no new behavior, page, or destination.

8. Interaction Model & Motion Direction

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

Landing Hero Motion Brief.

• Focal subject. A full-bleed generative particle/flow field derived from BTCUSDT and ETHUSDT perpetual tick data, bleeding off all four edges of the viewport.
• Input → transformation → outcome thesis. Live (or seeded) Binance perpetual tick data enters the field as particle density and flow direction; the field drifts and reorganizes at museum pace, never strobing and never reacting to hover with bounce; the outcome is a continuously readable picture of market turbulence behind the headline and the live ticker strip, so the product's own data is the hero rather than a decoration on it.
• Motion vocabulary. Slow continuous drift; scroll-linked turbulence on Landing, where the field calms as the user descends into the product; 400ms crossfades with a 12px upward drift on content during page transitions; numbers counting to their new value over 600ms with easing (a signal price, a PnL, a funding rate).
• Composed first frame. Black #07070B ground; the particle field already flowing and bleeding off all edges; the asymmetric overlay column flush on the grid line with the 12px amber rule, the four-line headline, the 48px amber CTA, and the monospace ticker strip counting in amber and teal; the 2px teal line and 14px monospace caption at bottom-left.
• Reduced-motion state. With prefers-reduced-motion, the canvas renders one static frame and all counts appear instantly; the headline, CTA, ticker values, and caption remain whole and readable.

Landing Hero 3D Scene Brief — DIRECTION-DERIVED. The direction specifies webgl hero dimensionality, so a real-time WebGL/R3F scene is expected. One crafted scene: a particle/flow field whose density and flow direction are driven by Binance perpetual tick data for BTCUSDT and ETHUSDT, rendered in the Anadol flow spectrum (#6C4BF4 → #35D0FF → amber) on a #07070B ground, drifting at museum pace and bleeding off all four viewport edges. The scene shows the product's defining state — a continuously flowing stream of market data being read as structure rather than noise — and it must never strobe, bounce, or react to hover, and must render a single static frame under reduced motion.

9. Non-Functional Requirements

• NFR-1 — Market-data scope. The product consumes market data only for crypto coins supported by Binance futures markets, and only for perpetual futures. Provenance: explicit constraint. Rationale: the strategy's scope is defined by the venue and instrument type the requester named.
• NFR-2 — Scalping horizon legibility. Signal and parameter readouts must be readable at scalping speed: numeric columns use IBM Plex Mono with tabular figures at 1.05 line-height so digits never shift column width as they tick, and LONG/SHORT are distinguishable instantly by the 3px amber/teal left rule. Provenance: required_inference from the accepted scalping use. Rationale: the operator must act in seconds without re-deriving the mathematics.
• NFR-3 — RTL and Arabic legibility. The layout must be legible in Arabic-friendly RTL, with the asymmetric overlay column mirrored via logical properties and all readable text and controls staying whole inside the viewport and their container at 375px, 768px, and 1280px. Provenance: explicit creative direction. Rationale: the product's primary language context is Arabic.
• NFR-4 — No page-level horizontal overflow. Tables scroll horizontally inside their own container; the page itself never scrolls horizontally. Provenance: explicit creative direction. Rationale: the dense Signals table must remain an instrument readout rather than breaking the layout.
• NFR-5 — Reduced motion. Under prefers-reduced-motion, the generative canvas renders one static frame, all counts appear instantly, and any moving or scrollable content stops and shows whole items (wrapping into rows or sitting in a horizontally scrollable row). Provenance: explicit creative direction. Rationale: accessibility without losing the data.
• NFR-6 — Contrast and colour discipline. Body text #EDEDF2 on #07070B is approximately 16:1; muted #7A7A8C is used only at 14px+ semibold and never for critical numbers; amber #F2A63B is reserved for actionable state and teal #4FE3C1 for counter-signal state. Provenance: explicit creative direction. Rationale: a single hot accent must carry every actionable decision.
• NFR-7 — Identity continuity. Saved strategy configurations and protected signal workflows are bound to the identity that created them, so a returning user resumes their own work. Provenance: required_inference. Rationale: the accepted journeys require resuming saved configurations and protected signal logic.
• NFR-8 — No stale values presented as live. When market data is unavailable or the configured strategy cannot be evaluated, the product reports the failure rather than presenting stale values as current. Provenance: required_inference. Rationale: the operator acts on what is displayed during a scalping session.

10. Tech Stack

• Frontend: React (web), with React Three Fiber / Drei for the WebGL generative hero canvas. Provenance: required_inference from the accepted custom-UI delivery and the direction's webgl hero dimensionality.
• Backend: Python with FastAPI, providing the application's API, identity handling, strategy configuration persistence, and the Binance-supported perpetual futures market-data integration. Provenance: required_inference from the accepted backend integration and application-owned identity.
• Storage: a persistent store for account identities and saved strategy configurations. Provenance: required_inference from the accepted need to resume saved configurations.
• Containerization: Docker with docker-compose for local and single-host deployment. Provenance: [Default — not specified by user].
• Orchestration: Kubernetes is not included; the accepted scope does not establish a deployment requirement that needs it. Provenance: [Default — not specified by user].

11. Assumptions and Constraints

Constraints (binding).

• The strategy is limited to crypto coins supported by Binance futures markets.
• The strategy style is scalping (short-term) on futures — not spot and not long-horizon trading.
• The product's human-facing work is delivered as first-party custom UI with application-owned identity; Landing, Sign Up, and Login are anonymously reachable, and Strategy Library, Strategy Builder, and Signals require login.
• Binance-supported perpetual futures market data is an external provider responsibility consumed by the application; the application does not own that data.
• The generic indigo/blue-on-white SaaS template is forbidden for this project.

Assumptions (narrow, labeled).

• [Assumption] The two accepted personas are the complete active-human set for this generation; no additional human role is introduced.
• [Assumption] Identity in this product establishes continuity of ownership over a user's own saved strategies and signal workflows only; it does not establish differentiated permissions, role-based visibility, or permission controls over shared product state.
• [Assumption] The strategy's mathematical vocabulary — order-book imbalance, VWAP deviation, ATR-scaled stops, funding-rate carry, R multiples — is the vocabulary the developer expresses rules in; the specific rule set is the developer's to define in Strategy Builder.
• [Assumption] The product presents signals for the operator to act on; it does not place orders or connect to an exchange account, because no such capability is accepted by the source.
• [Assumption] The product is dark-mode only, per the creative direction.

12. Glossary

• Binance perpetual futures — the futures instrument type on Binance that this product's strategy targets; the venue and instrument boundary of the entire product.
• Scalping — short-term trading on a seconds-scale horizon (the direction names a 1s–5s scalp horizon); the strategy style this product is built for.
• Strategy configuration — the saved, developer-owned definition of mathematical rules, algorithmic parameters, target Binance-supported perpetual futures symbols, and scalping horizon.
• Signal — a row on Signals presenting a symbol, side, entry, stop, target, R, and confidence for a supported Binance perpetual futures market under the configured strategy.
• LONG / SHORT — the two signal sides; LONG is marked by a 3px amber left rule and SHORT by a 3px teal left rule.
• R multiple — the risk multiple expressing a signal's target relative to its stop, displayed in tabular monospace.
• ATR-scaled stop — a stop level scaled by average true range, part of the strategy's mathematical vocabulary.
• VWAP deviation — deviation from volume-weighted average price, part of the strategy's mathematical vocabulary.
• Order-book imbalance — the asymmetry between bid and ask depth, part of the strategy's mathematical vocabulary.
• Funding-rate carry — the cost or credit of holding a perpetual futures position via its funding rate, part of the strategy's mathematical vocabulary and a live metric framed by a gauge ring.
• Gauge ring — the thin 1px-stroke circular ring with a single amber arc that frames a live metric (volatility, funding carry, win-rate), with its value set in monospace at the ring's centre; the only curves in the UI besides the generative canvas.
• Generative canvas — the full-bleed WebGL particle/flow field derived from Binance perpetual tick data that forms the Landing hero and the product's single image system.