System Requirements Document for heroic-binomo

1. Introduction

heroic-binomo is a 24/7 automated trading agent that operates exclusively on a Binomo DEMO account. The product's intent is to run a disciplined, rule-bound trading loop — market check every 15 minutes, multi-timeframe technical analysis, high-impact news screening, a single UP / DOWN / NO TRADE decision, and a fixed-stake DEMO execution or honest paper-trading fallback — while enforcing hard risk limits (fixed Rp14.000 per transaction, Rp500.000 daily net profit target, Rp42.000 daily stop-loss, stop after 3 consecutive losses, maximum one active position, no martingale) and reporting its own operational truth without exaggeration.

The defining product virtue is honesty of state: the system must never claim to be active when the scheduler has stopped or the connection has failed, must never claim a real transaction occurred when only paper trading ran, and must never present a REAL-account transaction as possible. The audience is a solo Indonesian retail trader/operator (areza ikhwanudin) who wants proof over promises: is the scheduler alive, is the data fresh, what did the agent decide, and what is the running P/L against the Rp500.000 target and the Rp42.000 daily floor.

The system must run on cloud infrastructure rather than depending on a phone staying awake, and must begin by checking whether all components are available and reporting honestly whether 24/7 operation is genuinely active or still requires configuration.

2. System Overview

heroic-binomo is a cloud-hosted, application-owned system with a custom web UI and background automation. Its current delivery consists of:

• A background scheduler that triggers a market check every 15 minutes and runs continuously (24/7) when the scheduler and cloud infrastructure support it.
• A market data and analysis pipeline that reads actual price data with candle timestamps, computes EMA 20/50, RSI 14, MACD, ATR, support/resistance, momentum, price structure, and volatility when data is available, across M1 (entry testing) and M5, M15, H1 (context), and checks high-impact economic news.
• A decision engine that emits exactly one of UP, DOWN, or NO TRADE, and refuses entry when data is stale, signals conflict, or market conditions do not satisfy the strategy rules.
• An execution layer that performs automated DEMO execution only when a legitimate, supported integration is genuinely available; otherwise it runs analysis and paper trading without claiming a real transaction occurred. It verifies every transaction result and never opens a double position.
• A risk and shutdown layer that enforces the fixed stake, daily profit ceiling, daily loss floor, consecutive-loss stop, single-position rule, and the prohibition on martingale / stake escalation / loss-chasing; it halts new transactions when a limit is reached while continuing system health checks, and resets statistics only when a new trading day begins.
• A recovery layer that, after an error, connection recovery, or server restart, re-verifies the DEMO account, balance, position status, and risk limits before resuming.
• A reporting layer that records time, instrument, decision, stake amount, transaction result, balance, daily profit/loss, consecutive losses, data status, and scheduler status.

Actors. The accepted active-human catalog is closed and consists of three personas: Operator Agen Auto-Trading, Analis Strategi Pasar, and Pengelola Risiko dan Kepatuhan. External systems (the DEMO broker integration, market data sources, economic news sources, cloud infrastructure) are non-persona actors.

Narrow exclusions. No REAL-account trading of any kind. No martingale, no stake escalation after a loss, no loss-chasing. No dependence on a phone remaining powered on. No claim of live 24/7 operation, and no claim of executed trades, when the scheduler, connection, or execution integration is unavailable.

2a. Product Interpretation and Delivery Boundary

Delivery ownership. heroic-binomo is delivered as a first-party web application with a first-party backend and a background scheduler process. The custom UI is application-owned; the DEMO broker integration, market data feed, and economic news feed are provider/external-owned and are consumed only when a legitimate, supported integration is genuinely available. The scheduler and cloud infrastructure are the runtime substrate; the product does not depend on any user device remaining powered on.

Access ownership. The application owns identity. Because the product must keep durable, actor-specific operational state (scheduler status, risk limits, decision history, recovery verification) bound to the correct participant and resumable across sessions, first-use identity establishment (self-service sign-up) and returning verification (login) are required. Anonymous visitors may read the public entry surface, which explains the DEMO-only agent, 24/7 operation, and the honesty-of-status boundary; all protected operational surfaces require an authenticated session. Access is role-restricted on the operational surfaces as defined by the page contract; this reflects differentiated control over shared operational state, not a general permission system.

Current vs. future boundary. Everything in this document is current. The 24/7 claim is conditional: it is true only when the scheduler and cloud infrastructure support it, and the product must report the honest state otherwise. Automated DEMO execution is conditional on a legitimate, supported integration being genuinely available; when it is not, the product runs analysis and paper trading and must not claim real transactions occurred. No future-horizon features are asserted.

2b. Source Content Inventory

Not applicable — no reference directive declares content_source.

2c. Page Content and Component Coverage

The page inventory below is the closed, ordered page contract. Each page appears exactly once.

Landing

• Information/state: Anonymous public entry. Explains the DEMO-only auto-trading agent, 24/7 operation (conditional on scheduler and cloud infrastructure), the fixed Rp14.000 stake, the Rp500.000 daily target, the Rp42.000 daily stop-loss, and the honesty-of-status boundary. A persistent "DEMO ONLY" plate restates the no-REAL-account constraint.
• Primary actions: Proceed to Sign Up; proceed to Login.
• Supporting actions: Read the operational/risk summary; view the honesty statement about when 24/7 is genuinely active.
• Domain entities: Agent description, operating mode, risk parameters, status-honesty statement.
• Component responsibilities: Hero instrument panel (headline stack, ruled status strip, daily P/L gauge with loss-floor hash, tick strip of recent checks); DEMO-only plate; primary and secondary CTAs.
• States: Loading (initial render), empty (no live status yet — shows "requires configuration" honestly), success (public content rendered), error (content unavailable — shows honest failure, no false "live" claim), recovery (retry render).

Login

• Information/state: Returning-verification surface for all three personas. Collects credentials and establishes an authenticated session.
• Primary actions: Submit credentials to sign in.
• Supporting actions: Navigate to Sign Up; recover from invalid credentials.
• Domain entities: Credential, session.
• Component responsibilities: Credential form; submit control; error region; link to Sign Up.
• States: Loading (submitting), empty (blank form), success (session established, redirect to Dashboard), error (invalid credentials — clear message, no session), recovery (re-attempt).

Sign Up

• Information/state: Self-service first-use identity establishment for all three personas. No provisioning or invitation boundary is set by the source.
• Primary actions: Create an account.
• Supporting actions: Navigate to Login; correct invalid input.
• Domain entities: Account, credential.
• Component responsibilities: Registration form; submit control; validation/error region; link to Login.
• States: Loading (submitting), empty (blank form), success (account created, proceed to Login or authenticated session), error (validation/duplicate — clear message), recovery (correct and resubmit).

Dashboard

• Information/state: Authenticated summary of operational status, schedule, risk, and results; routes to specialized work. Shows scheduler state, next-check countdown, daily P/L against target and floor, consecutive-loss counter, and recent decision summary.
• Primary actions: Navigate to System Health, Market Monitor, Market Analysis, Trade Decisions, Trade Execution, Risk Controls, Recovery, Activity Logs.
• Supporting actions: Read current status at a glance.
• Domain entities: Scheduler status, daily P/L, risk limits, consecutive losses, recent decisions.
• Component responsibilities: Instrument rail (DEMO badge, scheduler chip, countdown, P/L gauge, streak counter, risk rows); summary panels; navigation.
• States: Loading (fetching status), empty (no data yet — honest "no checks recorded"), success (status rendered), error (status unavailable — honest failure, no false live claim), recovery (refresh).

System Health

• Information/state: Role-restricted (Operator). Checks whether all components are available: scheduler, connection, cloud infrastructure, and whether 24/7 operation is genuinely active or still requires configuration. Reports failure honestly and never claims the system is active when the scheduler has stopped or the connection has failed.
• Primary actions: Run component availability check; read the honest 24/7 status verdict.
• Supporting actions: Inspect individual component states; view scheduler/connection detail.
• Domain entities: Component availability, scheduler status, connection status, cloud infrastructure status, 24/7 verdict.
• Component responsibilities: Component checklist; scheduler/connection indicators; honest verdict banner; failure reporting.
• States: Loading (running check), empty (not yet checked — prompts to run), success (all components available — 24/7 active), error (component/scheduler/connection failure — explicit failure, no active claim), recovery (re-run check after fix).

Market Monitor

• Information/state: Role-restricted (Operator, Analis). Displays the 15-minute market check cadence, actual price data, candle timestamps, and data status (fresh/stale).
• Primary actions: Review the latest and recent market checks; inspect data freshness.
• Supporting actions: View candle timestamp detail; view check cadence.
• Domain entities: Price data, candle timestamp, check cadence, data status.
• Component responsibilities: Cadence indicator; price/timestamp readouts; data-status indicator; recent-check list.
• States: Loading (fetching), empty (no checks yet), success (fresh data shown), error (stale/unavailable data — explicit stale flag), recovery (refresh on next check).

Market Analysis

• Information/state: Role-restricted (Analis). Displays multi-timeframe indicators (EMA 20/50, RSI 14, MACD, ATR, support/resistance, momentum, price structure, volatility) when data is available, across M1 (entry testing) and M5, M15, H1 (context), plus high-impact economic news checks.
• Primary actions: Review indicator readouts and news check results.
• Supporting actions: Inspect per-timeframe detail; view news impact.
• Domain entities: EMA 20/50, RSI 14, MACD, ATR, support/resistance, momentum, price structure, volatility, timeframe (M1/M5/M15/H1), news events.
• Component responsibilities: Indicator readouts; timeframe selector; news-check panel; data-availability indicators.
• States: Loading (computing), empty (insufficient data — indicators marked unavailable), success (indicators and news shown), error (data unavailable — explicit unavailability), recovery (recompute on next data).

Trade Decisions

• Information/state: Role-restricted (Analis). Manages the UP / DOWN / NO TRADE decision and the validation that rejects entry when data is stale, signals conflict, or market conditions do not satisfy the strategy rules.
• Primary actions: Review the decision; review the rejection reason when NO TRADE.
• Supporting actions: Inspect the reasoning (indicators and news) behind the decision.
• Domain entities: Decision (UP/DOWN/NO TRADE), rejection reason, supporting indicators.
• Component responsibilities: Decision readout; rejection-reason panel; reasoning drawer.
• States: Loading (evaluating), empty (no decision yet), success (decision rendered), error (evaluation failed — explicit failure, no fabricated decision), recovery (re-evaluate).

Trade Execution

• Information/state: Role-restricted (Operator, Pengelola Risiko). Runs or records DEMO paper trading, verifies each transaction result, and prevents double positions or REAL transactions. Automated DEMO execution is used only when a legitimate, supported integration is genuinely available; otherwise it runs analysis and paper trading without claiming a real transaction occurred.
• Primary actions: Execute/record a DEMO transaction; verify the transaction result.
• Supporting actions: Inspect execution mode (automated DEMO vs. paper trading); inspect verification status.
• Domain entities: Transaction, stake (Rp14.000), execution mode, verification result, position status.
• Component responsibilities: Execution control; mode indicator (automated DEMO / paper trading); verification readout; double-position guard; REAL-transaction block.
• States: Loading (submitting/verifying), empty (no transaction), success (verified result recorded), error (execution unavailable — honest paper-trading fallback, no real-transaction claim), recovery (re-verify).

Risk Controls

• Information/state: Role-restricted (Pengelola Risiko). Enforces the fixed Rp14.000 stake, the Rp500.000 daily net profit ceiling, the Rp42.000 daily loss floor, the stop after 3 consecutive losses, the single-active-position rule, and the daily reset. Halts new transactions when a limit is reached while health checks continue.
• Primary actions: Review enforced limits and current standing; confirm halt state.
• Supporting actions: Inspect consecutive-loss counter; inspect reset timing.
• Domain entities: Fixed stake, daily profit target, daily stop-loss, consecutive losses, position count, halt state, trading-day reset.
• Component responsibilities: Limit readouts; halt indicator; streak counter; reset indicator; prohibition notices (no martingale / no escalation / no loss-chasing).
• States: Loading (fetching), empty (no data yet), success (limits and standing shown), error (data unavailable — explicit), recovery (refresh).

Recovery

• Information/state: Role-restricted (Operator, Pengelola Risiko). After an error, connection recovery, or server restart, re-verifies the DEMO account, balance, position status, and risk limits before resuming.
• Primary actions: Run recovery verification; confirm resume readiness.
• Supporting actions: Inspect each verified item (account, balance, position, limits).
• Domain entities: DEMO account, balance, position status, risk limits, recovery event.
• Component responsibilities: Verification checklist; resume gate; recovery-event context.
• States: Loading (verifying), empty (no recovery event), success (all verified — resume permitted), error (verification failed — resume blocked, explicit), recovery (re-run verification).

Activity Logs

• Information/state: Authenticated (all personas). Displays operational, analysis, decision, transaction, risk, data, and scheduler logs, recording time, instrument, decision, stake amount, transaction result, balance, daily profit/loss, consecutive losses, data status, and scheduler status.
• Primary actions: Review log entries; filter by category.
• Supporting actions: Inspect individual entry detail.
• Domain entities: Log entry (time, instrument, decision, stake, result, balance, daily P/L, streak, data status, scheduler status).
• Component responsibilities: Ruled log table; category filter; entry detail.
• States: Loading (fetching), empty (no entries yet), success (entries shown), error (logs unavailable — explicit), recovery (refresh).

3. Functional Requirements

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

FR-01 — 24/7 operation (conditional). As the Operator Agen Auto-Trading, I should operate the system 24 hours a day, 7 days a week when the scheduler and cloud infrastructure support it, so that the agent runs continuously without my device being involved. Provenance: explicit. Trigger: system start. Observable result: the scheduler runs continuously and the system reports 24/7 as active only when the scheduler and cloud infrastructure genuinely support it. Failure/recovery: if the scheduler stops or the connection fails, the system reports the failure and does not claim it is still active. Continuation: health checks continue.

FR-02 — DEMO-only account. As the Pengelola Risiko dan Kepatuhan, I should ensure only a DEMO account is used and a REAL account is never used, so that no real funds are ever at risk. Provenance: explicit. Trigger: any account interaction. Observable result: the DEMO account is the only account used; REAL transactions are never performed. Failure/recovery: any attempt to use a REAL account is blocked and reported. Continuation: DEMO operation continues.

FR-03 — 15-minute market check. As the Analis Strategi Pasar, I should have the system run a market check every 15 minutes, so that decisions are based on a regular, bounded cadence. Provenance: explicit. Trigger: 15-minute interval. Observable result: a market check occurs every 15 minutes and is recorded. Failure/recovery: a missed check is reported honestly. Continuation: the next check proceeds on schedule.

FR-04 — Cloud execution, not phone-dependent. As the Operator Agen Auto-Trading, I should have the process run on a cloud server when that feature is available, so that operation does not depend on a phone staying powered on. Provenance: explicit. Trigger: deployment. Observable result: the process runs on cloud infrastructure; no phone dependency exists. Failure/recovery: if cloud infrastructure is unavailable, the system reports it honestly. Continuation: operation resumes when infrastructure is available.

FR-05 — Honest failure reporting. As the Operator Agen Auto-Trading, I should be told when the scheduler stops or the connection fails, so that I am never misled into believing the system is active. Provenance: explicit. Trigger: scheduler stop or connection failure. Observable result: an explicit failure is reported and no active claim is made. Failure/recovery: the failure state persists until resolved. Continuation: health checks continue.

FR-06 — Fixed stake. As the Pengelola Risiko dan Kepatuhan, I should have every transaction use a fixed nominal of Rp14.000, so that stake size is constant and non-escalating. Provenance: explicit. Trigger: transaction creation. Observable result: the stake is exactly Rp14.000. Failure/recovery: any deviation is blocked. Continuation: transactions continue at the fixed stake.

FR-07 — Daily profit target. As the Pengelola Risiko dan Kepatuhan, I should have a daily net profit target of Rp500.000, so that the agent stops opening new transactions when the target is reached. Provenance: explicit. Trigger: daily net profit reaching Rp500.000. Observable result: new transactions stop. Failure/recovery: the halt persists for the trading day. Continuation: health checks continue without new transactions.

FR-08 — Daily stop-loss. As the Pengelola Risiko dan Kepatuhan, I should have a daily stop-loss of Rp42.000, so that the agent stops opening new transactions when the daily loss reaches that floor. Provenance: explicit. Trigger: daily loss reaching Rp42.000. Observable result: new transactions stop. Failure/recovery: the halt persists for the trading day. Continuation: health checks continue without new transactions.

FR-09 — Consecutive-loss stop. As the Pengelola Risiko dan Kepatuhan, I should have the agent stop after 3 consecutive losses, so that a losing streak cannot continue unchecked. Provenance: explicit. Trigger: 3 consecutive losses. Observable result: new transactions stop. Failure/recovery: the halt persists until a new trading day. Continuation: health checks continue without new transactions.

FR-10 — Single active position. As the Pengelola Risiko dan Kepatuhan, I should have at most one active position at a time, so that no double position is ever opened. Provenance: explicit. Trigger: transaction attempt while a position is active. Observable result: the attempt is blocked. Failure/recovery: the block is reported. Continuation: the existing position proceeds to its result.

FR-11 — No martingale / escalation / loss-chasing. As the Pengelola Risiko dan Kepatuhan, I should have martingale, stake escalation after a loss, and loss-chasing prohibited, so that risk cannot compound. Provenance: explicit. Trigger: any attempt to escalate stake or chase losses. Observable result: the attempt is blocked. Failure/recovery: the block is reported. Continuation: the fixed-stake rule remains enforced.

FR-12 — Actual price data and candle timestamps. As the Analis Strategi Pasar, I should have the system check actual price data and candle timestamps, so that analysis is grounded in real, time-stamped data. Provenance: explicit. Trigger: market check. Observable result: actual price data and candle timestamps are read and recorded. Failure/recovery: missing or stale data is flagged. Continuation: analysis proceeds only on fresh data.

FR-13 — Multi-indicator analysis. As the Analis Strategi Pasar, I should have the system analyze EMA 20/50, RSI 14, MACD, ATR, support/resistance, momentum, price structure, and volatility when data is available, so that decisions rest on a defined indicator set. Provenance: explicit. Trigger: market check. Observable result: each indicator is computed and shown when data is available. Failure/recovery: unavailable indicators are marked unavailable. Continuation: analysis proceeds with available indicators.

FR-14 — Multi-timeframe context. As the Analis Strategi Pasar, I should have M1 used for entry testing and M5, M15, and H1 used for context, so that entry timing and broader context are separated. Provenance: explicit. Trigger: market check. Observable result: M1 drives entry testing; M5/M15/H1 provide context. Failure/recovery: missing timeframe data is flagged. Continuation: analysis proceeds with available timeframes.

FR-15 — High-impact news check. As the Analis Strategi Pasar, I should have the system check high-impact economic news, so that news risk is part of the decision. Provenance: explicit. Trigger: market check. Observable result: high-impact news is checked and recorded. Failure/recovery: unavailable news data is flagged. Continuation: the decision accounts for the news check.

FR-16 — Decision output. As the Analis Strategi Pasar, I should have the decision result be exactly UP, DOWN, or NO TRADE, so that the outcome is unambiguous. Provenance: explicit. Trigger: completed analysis. Observable result: exactly one of UP, DOWN, or NO TRADE is produced. Failure/recovery: an evaluation failure is reported without fabricating a decision. Continuation: the decision feeds execution or rejection.

FR-17 — Entry refusal conditions. As the Analis Strategi Pasar, I should have entry refused when data is stale, signals conflict, or market conditions do not satisfy the strategy rules, so that the agent does not trade on weak conditions. Provenance: explicit. Trigger: stale data, conflicting signals, or non-conforming conditions. Observable result: NO TRADE is produced and the reason is recorded. Failure/recovery: the refusal is reported. Continuation: the next check re-evaluates.

FR-18 — Automated DEMO execution only when genuinely available. As the Operator Agen Auto-Trading, I should have automated DEMO execution used only when a legitimate, supported integration is genuinely available, so that the system never pretends to execute. Provenance: explicit. Trigger: decision to execute. Observable result: automated DEMO execution occurs only with a genuine integration; otherwise paper trading runs. Failure/recovery: absence of integration is reported honestly. Continuation: analysis and paper trading continue.

FR-19 — Transaction result verification. As the Operator Agen Auto-Trading, I should have every transaction result verified, so that recorded outcomes are trustworthy. Provenance: explicit. Trigger: transaction completion. Observable result: the result is verified and recorded. Failure/recovery: unverified results are flagged. Continuation: the verified result updates balance and P/L.

FR-20 — No double position. As the Pengelola Risiko dan Kepatuhan, I should have the system never open a double position, so that exposure stays single. Provenance: explicit. Trigger: overlapping transaction attempt. Observable result: the second attempt is blocked. Failure/recovery: the block is reported. Continuation: the single position proceeds.

FR-21 — No REAL transactions. As the Pengelola Risiko dan Kepatuhan, I should have the system never perform REAL transactions, so that no real money is ever traded. Provenance: explicit. Trigger: any transaction attempt. Observable result: REAL transactions are never performed. Failure/recovery: any REAL attempt is blocked and reported. Continuation: DEMO/paper operation continues.

FR-22 — Paper-trading fallback without false claims. As the Operator Agen Auto-Trading, I should have the system run analysis and paper trading without claiming real transactions occurred when automated execution is unavailable, so that reporting stays honest. Provenance: explicit. Trigger: automated execution unavailable. Observable result: analysis and paper trading run; no real-transaction claim is made. Failure/recovery: the fallback state is reported. Continuation: operation continues in paper mode.

FR-23 — Halt on profit target. As the Pengelola Risiko dan Kepatuhan, I should have new transactions stopped when daily net profit reaches Rp500.000, so that the target is respected. Provenance: explicit. Trigger: daily net profit reaching Rp500.000. Observable result: new transactions stop. Failure/recovery: the halt persists for the trading day. Continuation: health checks continue.

FR-24 — Halt on daily loss. As the Pengelola Risiko dan Kepatuhan, I should have new transactions stopped when daily loss reaches Rp42.000, so that the floor is respected. Provenance: explicit. Trigger: daily loss reaching Rp42.000. Observable result: new transactions stop. Failure/recovery: the halt persists for the trading day. Continuation: health checks continue.

FR-25 — Halt after 3 consecutive losses. As the Pengelola Risiko dan Kepatuhan, I should have new transactions stopped after 3 consecutive losses, so that the streak rule is enforced. Provenance: explicit. Trigger: 3 consecutive losses. Observable result: new transactions stop. Failure/recovery: the halt persists until a new trading day. Continuation: health checks continue.

FR-26 — Health checks continue after halt. As the Operator Agen Auto-Trading, I should have system health checks continue after a limit is reached without opening new transactions, so that I can still see the system's true state. Provenance: explicit. Trigger: any halt condition. Observable result: health checks continue; no new transactions open. Failure/recovery: health failures are reported. Continuation: health monitoring persists.

FR-27 — Daily statistics reset. As the Pengelola Risiko dan Kepatuhan, I should have statistics reset only when a new trading day begins, so that daily limits are not reset prematurely. Provenance: explicit. Trigger: start of a new trading day. Observable result: statistics reset. Failure/recovery: no premature reset occurs. Continuation: the new day begins with fresh statistics.

FR-28 — Post-error/recovery/restart re-verification. As the Operator Agen Auto-Trading, I should have the DEMO account, balance, position status, and risk limits re-verified after an error, connection recovery, or server restart before continuing, so that resumption is safe. Provenance: explicit. Trigger: error, connection recovery, or server restart. Observable result: account, balance, position, and limits are re-verified before resuming. Failure/recovery: failed verification blocks resumption and is reported. Continuation: operation resumes only after successful verification.

FR-29 — Operational logging. As the Operator Agen Auto-Trading, I should have the system record time, instrument, decision, stake amount, transaction result, balance, daily profit/loss, consecutive losses, data status, and scheduler status, so that the full operating record is available. Provenance: explicit. Trigger: each operational event. Observable result: all listed fields are recorded. Failure/recovery: logging failures are reported. Continuation: logging continues.

FR-30 — Initial component availability check and honest 24/7 report. As the Operator Agen Auto-Trading, I should have the system begin by checking whether all components are available and report honestly whether 24/7 operation is genuinely active or still requires configuration, so that I know the true starting state. Provenance: explicit. Trigger: system start. Observable result: a component availability check runs and an honest 24/7 verdict is reported. Failure/recovery: missing components are reported as requiring configuration. Continuation: configuration or operation proceeds accordingly.

FR-31 — Self-service identity establishment and returning verification. As each persona, I should be able to establish an account and verify my identity on return, so that my operational state is bound to me and resumable. Provenance: required_inference. Trigger: first use or return visit. Observable result: an account is created or a session is established. Failure/recovery: invalid credentials or validation errors are reported. Continuation: access to protected surfaces.

FR-32 — Scheduler and cloud configuration prerequisite. As the Operator Agen Auto-Trading, I should have scheduler and cloud infrastructure configured before 24/7 operation can be declared active, so that the active claim is truthful. Provenance: required_inference. Trigger: system start. Observable result: 24/7 is declared active only after configuration. Failure/recovery: unconfigured state is reported. Continuation: configuration proceeds.

FR-33 — Legitimate execution integration boundary. As the Operator Agen Auto-Trading, I should have the system use a legitimate, supported execution integration when available and otherwise run analysis and paper trading, so that execution claims match reality. Provenance: required_inference. Trigger: execution attempt. Observable result: automated DEMO execution or paper trading, truthfully labeled. Failure/recovery: absence of integration is reported. Continuation: operation continues in the available mode.

FR-34 — DEMO account verification. As the Pengelola Risiko dan Kepatuhan, I should have the DEMO account verified and REAL transactions disallowed, so that the account boundary is enforced. Provenance: required_inference. Trigger: account interaction. Observable result: the DEMO account is verified; REAL transactions are disallowed. Failure/recovery: verification failure blocks operation and is reported. Continuation: DEMO operation continues.

FR-35 — Post-recovery verification gate. As the Operator Agen Auto-Trading, I should have the DEMO account, balance, position, and risk limits verified before resuming after an error, connection recovery, or restart, so that resumption is gated on verified state. Provenance: required_inference. Trigger: error, recovery, or restart. Observable result: verification gates resumption. Failure/recovery: failed verification blocks resumption. Continuation: resumption after successful verification.

4. User Personas

Operator Agen Auto-Trading

Product context. The Operator runs and supervises the 24/7 Binomo DEMO auto-trading agent. They are the person who starts the system, checks whether all components are available, and watches the scheduler and connection for signs of failure. They are the primary reader of the honesty contract: they must be able to tell whether the system is genuinely active or still requires configuration.

Primary goal. Keep the agent running continuously and truthfully, and know at all times whether it is actually operating.

Distinct accepted responsibilities. Starting the initial component availability check; reading the honest 24/7 verdict; monitoring scheduler and connection status; following up on failure reports; re-verifying the DEMO account, balance, position status, and risk limits after an error, connection recovery, or server restart before continuing; reviewing operational logs.

Relevant inputs or decisions. Component availability results; scheduler state; connection state; cloud infrastructure state; recovery verification results; the decision to resume after recovery.

Interactions with other accepted participants. Consumes the Analis Strategi Pasar's decisions and the Pengelola Risiko dan Kepatuhan's risk state; acts on failures that affect both.

Observable success. The system reports 24/7 as active only when it genuinely is, reports failures honestly when it is not, and resumes only after verified recovery.

Analis Strategi Pasar

Product context. The Market Strategy Analyst reviews the 15-minute market checks, the actual price data and candle timestamps, the multi-timeframe indicator set (EMA 20/50, RSI 14, MACD, ATR, support/resistance, momentum, price structure, volatility), and the high-impact economic news check. They are the person who judges whether a UP, DOWN, or NO TRADE decision is legitimate.

Primary goal. Ensure decisions are grounded in fresh, non-conflicting data and conform to the strategy rules.

Distinct accepted responsibilities. Reviewing indicator readouts across M1 (entry testing) and M5/M15/H1 (context); reviewing the news check; validating that entry is refused when data is stale, signals conflict, or conditions do not satisfy the strategy rules; inspecting the reasoning behind each decision.

Relevant inputs or decisions. Price data and candle timestamps; indicator values; news events; the decision and its rejection reason.

Interactions with other accepted participants. Produces the decision that the Operator executes or paper-trades and that the Pengelola Risiko dan Kepatuhan constrains.

Observable success. Every decision is one of UP, DOWN, or NO TRADE, with a recorded reason, and no entry occurs on stale or conflicting data.

Pengelola Risiko dan Kepatuhan

Product context. The Risk and Compliance Manager enforces the transaction parameters and shutdown rules: fixed Rp14.000 stake, Rp500.000 daily net profit target, Rp42.000 daily stop-loss, stop after 3 consecutive losses, maximum one active position, and the prohibitions on martingale, stake escalation after a loss, loss-chasing, and REAL transactions.

Primary goal. Ensure the agent never exceeds its risk limits and never violates the DEMO-only and no-escalation constraints.

Distinct accepted responsibilities. Reviewing enforced limits and current standing; confirming halt states; monitoring the consecutive-loss counter; confirming that statistics reset only when a new trading day begins; ensuring health checks continue after a halt without new transactions.

Relevant inputs or decisions. Daily P/L; consecutive-loss count; position count; halt state; trading-day boundary.

Interactions with other accepted participants. Constrains the Analis Strategi Pasar's decisions and the Operator's execution; shares recovery verification with the Operator.

Observable success. New transactions stop exactly at the profit target, loss floor, or 3 consecutive losses; no double position, no escalation, and no REAL transaction ever occurs.

5. Core User Flows

Flow 1 — Operator: initial component check and honest 24/7 verdict.

1. The Operator opens the Landing page and reads the DEMO-only, 24/7, and fixed-stake summary.
2. The Operator proceeds to Sign Up (first use) or Login (returning) and establishes a session.
3. On the Dashboard, the Operator navigates to System Health.
4. The Operator runs the component availability check.
5. The system reports each component's state and an honest verdict: 24/7 active, or still requires configuration.
6. If components are missing, the Operator configures the scheduler and cloud infrastructure (FR-32) and re-runs the check.
7. Observable result: the Operator knows the true operating state. Continuation: monitoring proceeds on the Dashboard.

Flow 2 — Operator: scheduler or connection failure.

1. The Operator is on the Dashboard or System Health.
2. The scheduler stops or the connection fails.
3. The system reports the failure explicitly and does not claim it is still active (FR-05).
4. The Operator inspects the failure detail and the affected components.
5. Observable result: the failure is visible and unambiguous. Continuation: health checks continue; the Operator resolves the failure and re-runs the check.

Flow 3 — Analis: 15-minute market check and analysis.

1. The Analis opens Market Monitor and reviews the latest 15-minute check, actual price data, candle timestamps, and data status.
2. The Analis opens Market Analysis and reviews EMA 20/50, RSI 14, MACD, ATR, support/resistance, momentum, price structure, and volatility across M1, M5, M15, and H1, plus the high-impact news check.
3. If data is stale or unavailable, the indicators are marked unavailable and the analysis proceeds only with available data.
4. Observable result: the Analis has a complete, timestamped view of the market state. Continuation: the decision is reviewed.

Flow 4 — Analis: decision and entry refusal.

1. The Analis opens Trade Decisions.
2. The system presents exactly one of UP, DOWN, or NO TRADE.
3. If data is stale, signals conflict, or conditions do not satisfy the strategy rules, the decision is NO TRADE with a recorded reason (FR-17).
4. The Analis inspects the reasoning drawer (indicators and news) behind the decision.
5. Observable result: a legitimate, reasoned decision. Continuation: a UP/DOWN decision proceeds to execution; NO TRADE returns to the next check.

Flow 5 — Operator/Pengelola: DEMO execution or paper-trading fallback.

1. A UP or DOWN decision reaches Trade Execution.
2. The system checks whether a legitimate, supported DEMO execution integration is genuinely available.
3. If available, it performs automated DEMO execution at the fixed Rp14.000 stake and verifies the result (FR-18, FR-19).
4. If unavailable, it runs analysis and paper trading and does not claim a real transaction occurred (FR-22).
5. The system blocks any double position (FR-20) and any REAL transaction (FR-21).
6. Observable result: a verified result or an honestly labeled paper trade. Continuation: balance and daily P/L update.

Flow 6 — Pengelola: risk limit enforcement and halt.

1. The Pengelola opens Risk Controls and reviews the fixed stake, daily target, daily floor, consecutive-loss counter, and position count.
2. Daily net profit reaches Rp500.000, or daily loss reaches Rp42.000, or 3 consecutive losses occur.
3. The system stops new transactions (FR-23, FR-24, FR-25).
4. Health checks continue without opening new transactions (FR-26).
5. Statistics reset only when a new trading day begins (FR-27).
6. Observable result: the halt is enforced and visible. Continuation: the next trading day begins with reset statistics.

Flow 7 — Operator/Pengelola: recovery after error, connection recovery, or restart.

1. An error occurs, the connection recovers, or the server restarts.
2. The Operator or Pengelola opens Recovery.
3. The system re-verifies the DEMO account, balance, position status, and risk limits (FR-28, FR-35).
4. If verification fails, resumption is blocked and the failure is reported.
5. If verification succeeds, resumption is permitted.
6. Observable result: a verified, safe resumption. Continuation: normal operation resumes.

Flow 8 — All personas: operational log review.

1. Any persona opens Activity Logs.
2. The system displays recorded time, instrument, decision, stake amount, transaction result, balance, daily profit/loss, consecutive losses, data status, and scheduler status (FR-29).
3. The persona filters by category and inspects entry detail.
4. Observable result: a complete, honest operating record. Continuation: the persona returns to the relevant operational surface.

6. Visuals Colors and Theme

The creative direction is authoritative: Precision instrument dark — titanium ground, amber needles, dial-grade data, muse MARQ by Garmin.

Color tokens (dark mode only; light mode is not offered):

Proportion: 70% dark ground, 18% surface panels, 6% bone type mass, 4% amber, 2% teal/red combined. No blue anywhere; no gradient fills on any surface.

Typography:

• Headings: Saira Condensed at 600/700, uppercase, tracking +0.02em, leading 0.9.
• Data numerals: Saira Condensed 700 with tabular figures so EMA/RSI/ATR columns and Rp amounts align like a dial face.
• Body: Archivo 400/500 at 16px with 1.6 leading.
• Micro-labels: Archivo 600 uppercase at 11px, tracking +0.14em, in muted grey.
• Never set a paragraph in the condensed face.
• Scale: 1.333 modular on a 4px baseline — display 44px mobile → 96px desktop (clamp), h1 32→56, h2 24→36, h3 20→24, body 16, micro-label 11, numeral-readout 40→72 (clamp, tabular). Line heights: 0.92 display, 1.15 h2/h3, 1.6 body.

Shape language: Instrument geometry, not soft SaaS geometry. Circular gauge rings and bezels (SVG stroke-arcs with a tick scale) for RSI, daily P/L against target, and the 15-minute cadence; 4px radii on panels and buttons — near-square, milled, never pill. Ruled data rows with 1px hairlines at #2A3034 separating label/value pairs, aligned on a hard right edge for numerals. Section boundaries are full-width rules, not cards. One exception for warmth: a single brushed-metal top edge (2px #C9A227 → transparent linear fade) on the hero panel and the primary CTA, reading as a machined chamfer.

Layout: A cockpit, not a marketing page. 12-column grid at 1280px with a persistent left rail (240px) carrying the instrument stack: account mode (DEMO badge), scheduler state, next check countdown, daily P/L gauge, consecutive-loss counter, and the risk limits as ruled rows. Main column is a vertical log: hero instrument panel, then the decision record as a dense ruled table (time, instrument, decision, stake, result, balance, daily P/L, streak, data status, scheduler status) where each row is a full-width band, not a card. Three-up stat cluster uses a 2:1 asymmetric split (target gauge double-width, loss floor and streak single). At 768px the rail collapses to a horizontal instrument strip pinned under the header; at 375px everything stacks single-column, gauges scale to 120px, the log becomes stacked label/value blocks with the same ruled hairlines. No grid of identical hover-lift cards anywhere.

Imagery: No stock photography, no people, no 3D blobs. The imagery is engineered: SVG gauge arcs with tick marks, a topographic contour texture at 4% opacity behind the hero panel, thin luminous stroke diagrams of the EMA 20/50 ribbon and an ATR volatility band drawn from the actual series, and a candle-timestamp strip rendered as a horizontal ruled scale with M1/M5/M15/H1 marked. Where a photograph is unavoidable (e.g. a section on cloud infrastructure), use one macro shot of brushed titanium or a server-rack edge, cropped edge-to-edge, desaturated to graphite with a single amber highlight.

7. Signature Design Concept

The public entry (Landing) is a full-bleed titanium-dark instrument panel, not a centred headline.

• Left two-thirds: an oversized Saira Condensed headline stacked in three flush-left lines at 44px mobile → 96px desktop — "DEMO ONLY.", "24/7 SCHEDULER.", "Rp14.000 FIXED." — sitting on the dark ground with an amber 3px rule under the first line. Beneath it, a single ruled status strip reading SCHEDULER · LIVE · NEXT CHECK 00:14:52 in tabular numerals.
• Right third: a 320px circular gauge, half-bleed off the right viewport edge on desktop, showing daily net P/L as an amber needle arc against a tick scale marked 0 and Rp500.000, with the loss floor Rp42.000 drawn as a red hash at the bottom of the dial.
• Bottom-left of the hero, pinned beneath the headline block, two controls: a solid amber "MULAI PEMERIKSAAN" button with a brushed top edge, and a hairline outlined "LIHAT LOG KEPUTUSAN".
• Bottom edge: a horizontal ruled tick-strip of the last 24 checks runs the full viewport width, each tick coloured teal (win), red (loss) or grey (NO TRADE), with the 15-minute interval labels beneath.

Nothing is centred; nothing floats; every element reads as a gauge or a rule. The gauge is the product's honesty contract: if the scheduler is dead, the needle drops to zero and the dial greys out with a FAILED stamp instead of animating.

8. Interaction Model & Motion Direction

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

Landing Hero Motion Brief.

• Focal subject: the daily P/L circular gauge with its amber needle arc, tick scale (0 → Rp500.000), and the red Rp42.000 loss-floor hash, paired with the full-width tick strip of the last 24 checks.
• Input → transformation → outcome thesis: on mount, the needle sweeps from zero to the day's net P/L (600ms, cubic-bezier(0.2,0,0,1)) while the numeral counts up once (tabular, 500ms) and then holds; the tick strip's 24 ticks enter with a 120ms stagger. The outcome is a single, readable instrument state — the day's P/L against target and floor — with no ambiguity.
• Motion vocabulary: precise and mechanical, at the muse's cinematic ceiling but never playful. A single needle sweep at mount; numbers count up once on first paint and then hold; the scheduler pulse is a 2s opacity breathe on a 6px teal dot when LIVE, frozen solid red with no animation when the scheduler is dead — the absence of motion is the failure signal. Log rows enter with a 120ms stagger and no bounce. Hover on a row brightens its hairline to amber and reveals the reasoning drawer with a 180ms slide; no scale, no lift.
• Composed first frame: the three-line headline flush-left with the amber rule under line one, the ruled status strip beneath it, the half-bled gauge on the right at its resting value, and the tick strip along the bottom edge — every element already legible before any motion begins.
• Reduced-motion state: gauges render at final value, counters appear already-counted, the log is fully expanded, and the scheduler state is a static labelled chip. The tick strip wraps into rows or scrolls horizontally so every tick remains fully readable.

9. Non-Functional Requirements

• NFR-01 — Continuous operation. The system must operate 24/7 when the scheduler and cloud infrastructure support it. Provenance: explicit. Rationale: the source requires continuous operation conditional on infrastructure support.
• NFR-02 — Cloud hosting. The process must run on cloud infrastructure when available and must not depend on a phone remaining powered on. Provenance: explicit. Rationale: the source explicitly forbids phone dependence.
• NFR-03 — Honest state reporting. The system must never claim to be active when the scheduler has stopped or the connection has failed, and must never claim a real transaction occurred when only paper trading ran. Provenance: explicit. Rationale: the source demands honest failure reporting.
• NFR-04 — 15-minute cadence. Market checks must occur every 15 minutes. Provenance: explicit. Rationale: the source specifies the cadence.
• NFR-05 — Data freshness. Analysis must use actual price data with candle timestamps, and entry must be refused on stale data. Provenance: explicit. Rationale: the source requires fresh, timestamped data.
• NFR-06 — Risk limit integrity. The fixed stake, daily target, daily floor, consecutive-loss stop, and single-position rule must be enforced without exception. Provenance: explicit. Rationale: the source states these as hard parameters.
• NFR-07 — DEMO-only boundary. No REAL-account transaction may ever be performed. Provenance: explicit. Rationale: the source states this as a hard constraint.
• NFR-08 — Durable state. Operational state (scheduler status, risk limits, decision history, recovery verification) must persist across sessions and restarts. Provenance: required_inference. Rationale: recovery and daily-reset rules require durable state.
• NFR-09 — Accessible, readable instrumentation. Headlines, labels, numbers, and controls must remain whole and readable at 375px, 768px, and 1280px, with a usable static arrangement under prefers-reduced-motion. Provenance: explicit (creative direction). Rationale: the direction requires readable text and controls at every viewport.

10. Tech Stack

• Frontend: React (web) with the instrument-panel design system described in Sections 6–8.
• Backend: Python / FastAPI, extending a single shared backend process for the API, analysis pipeline, decision engine, risk enforcement, and reporting.
• Background automation: a scheduler process running the 15-minute market check loop and the health-check loop, deployed as an independent worker process alongside the backend.
• Storage: a durable relational store for operational state, decisions, transactions, and logs; Redis for scheduler/worker coordination and short-lived state, as required by the planning scope.
• Deployment: Docker / docker-compose for the backend, scheduler worker, and storage services; Kubernetes only if the deployment requires it.
• External integrations: DEMO broker execution integration, market data feed, and economic news feed — consumed only when a legitimate, supported integration is genuinely available.

11. Assumptions and Constraints

Assumptions.

• A1 — The DEMO broker integration, market data feed, and economic news feed are external and may be unavailable; the product must degrade honestly. [Assumption — not specified by user]
• A2 — The trading day boundary used for the daily reset is a single, consistent definition applied by the system. [Assumption — not specified by user]
• A3 — The instrument(s) traded are those available through the DEMO integration; the source does not name a specific instrument. [Assumption — not specified by user]

Constraints.

• C1 — DEMO account only; REAL accounts are prohibited.
• C2 — No REAL transactions.
• C3 — No martingale, no stake escalation after a loss, no loss-chasing.
• C4 — Fixed stake of Rp14.000 per transaction.
• C5 — Maximum one active position at a time; no double positions.
• C6 — No dependence on a phone remaining powered on; cloud execution when available.
• C7 — Automated DEMO execution only when a legitimate, supported integration is genuinely available.
• C8 — When automated execution is unavailable, run analysis and paper trading without claiming real transactions occurred.
• C9 — If the scheduler stops or the connection fails, report the failure and do not claim the system is still active.
• C10 — No entry when data is stale, signals conflict, or market conditions do not satisfy the strategy rules.
• C11 — Stop new transactions at Rp500.000 daily net profit, Rp42.000 daily loss, or 3 consecutive losses; continue health checks without new transactions.
• C12 — Reset statistics only when a new trading day begins.
• C13 — 24/7 operation only when the scheduler and cloud infrastructure support it.

12. Glossary

• DEMO account — a simulated Binomo account used for practice; the only account type this system may use.
• REAL account — a live-money account; prohibited for this system.
• Market check — the scheduled 15-minute evaluation of price data, indicators, and news.
• EMA 20/50 — exponential moving averages over 20 and 50 periods.
• RSI 14 — relative strength index over 14 periods.
• MACD — moving average convergence divergence.
• ATR — average true range, a volatility measure.
• Support/resistance — price levels where movement tends to pause or reverse.
• Momentum — the rate and strength of price movement.
• Price structure — the arrangement of highs and lows defining trend and range.
• Volatility — the magnitude of price fluctuation.
• M1 / M5 / M15 / H1 — one-minute, five-minute, fifteen-minute, and one-hour timeframes; M1 is used for entry testing, the others for context.
• High-impact economic news — scheduled economic events capable of moving the market.
• UP / DOWN / NO TRADE — the three possible decision outcomes.
• Stale data — price data whose timestamp is too old to be reliable for entry.
• Paper trading — simulated trading used when automated DEMO execution is unavailable.
• Consecutive losses — the running count of losses in a row; the agent stops at 3.
• Daily net profit target — Rp500.000; new transactions stop when reached.

• Daily stop-loss — Rp42.000; new transactions stop when reached.
• Trading day — the period after which daily statistics reset.
• Scheduler — the process that triggers market checks and health checks on schedule.
• Health check — a system status check that continues even after trading halts.