UC_4.7.5 — Daily Loss Limit Bar (Persistent Global Header)

1. Overview

References/Wireframe/Stage 2/Dashboard/Dashboard.png Persistent header, Daily Loss Limit Bar in its normal in-session state (0%–100% fill per BR_4.7.5.1). Soft breach modal.png Daily Loss Limit Bar at its max-fill/motion-warning state, rendered underneath the Soft Breach overlay — this UC owns only the bar itself; the overlay content is owned by UC_4.10.1 §9.1 row 3. (No dedicated wireframe crop exists for the bar alone — these 2 files are the confirmed source per BA fallback QN-4.7.5-06, superseding the earlier text-only placeholder: "a persistent visual progress bar tracking Daily loss limit", dashboard_v7_full.txt L569-571.)

2. Trigger

• The Dashboard header (Ref: UC_4.1.1) renders — frontend subscribes to the RULE_TRACKING WebSocket event.
• A RULE_TRACKING event arrives with updated current_daily_pnl/daily_loss_limit values (dist_daily_loss is streamed in the same payload but is not used by this UC's fill calculation — Ref: BR_4.7.5.1).

3. Pre-conditions

• User is on the Dashboard, account type SIM.

4. Post-conditions

• The bar's fill level and visual state reflect the most recently received RULE_TRACKING values (Ref: BR_4.7.5.1).

5. Basic Flow

1. On Dashboard load, frontend subscribes to the RULE_TRACKING WebSocket event (no separate polling call — Ref: BR_4.7.5.2).
2. Each RULE_TRACKING event delivers dist_daily_loss, daily_loss_limit, current_daily_pnl for the current session.
3. Frontend computes the bar's fill percentage from current_daily_pnl (Net_P&L for the session) checked against daily_loss_limit (Ref: BR_4.7.5.1).
4. [If the trader has no loss this session — including a brand-new account that has never placed a trade] → bar renders at 0% fill, the default/empty state (Ref: BR_4.7.5.5).
5. [If current_daily_pnl <= -daily_loss_limit] → bar renders at max/full fill with the motion-warning visual state (Ref: BR_4.7.5.1; graduated blink rate below max-fill per BR_4.7.5.7).
6. [If the trader was in the max-fill/motion-warning state from a prior Soft Breach, and the account's trading session has since opened] → bar drops back to 0% fill, now reflecting the trader's actual (reset-to-0) loss for the new session (Ref: BR_4.7.5.6).

6. Alternative Flow

• [If the Daily Loss Limit is reached (Soft Breach) while the user is on the Dashboard] → the bar transitions to the max/motion-warning state per step 5 above. This UC does not cover Soft Breach logic — the breach detection, consequence (Read-Only lock, position flattening, unfreeze timing), and the "Daily Limit Reached" overlay (which renders the bar in its max-fill state underneath it, per UC_4.10.1 §9.1 row 3) are handled entirely by UC_4.10.1 — Soft Breach: Daily Loss Limit Hit.
• [If the account enters Hard Breach, Soft Breach, or Frosted Glass cooling-off] → per the persistent-header permission rule (Ref: UC_4.1.1 §2 Screen Description, row 1), this bar freezes on the state/value it held right before the breach and does not update further while the account remains in any of those 3 statuses (Source: BA/client direct instruction, 2026-08-17).

7. Exceptional Flow

• WebSocket disconnects: bar holds its last-known-good fill/state; no error banner from this component. Reconnect behavior follows the same shared pattern noted in UC_4.7.1 §7.

8. Business Rules

BR_4.7.5.1: Bar Fill Is Computed from Net_P&L vs. daily_loss_limit

The bar's fill percentage is computed by the frontend from two RULE_TRACKING-streamed values — current_daily_pnl (the session's Net_P&L, per the UC_4.10.1 §2 Trigger definition: Net_P&L = Realized P&L + Unrealized P&L) and daily_loss_limit — rather than consumed directly from the dist_daily_loss field:

fill_% = min(100%, max(0%, (-current_daily_pnl / daily_loss_limit) × 100%))

• daily_loss_limit is the positive threshold value calculated by UC_4.10.1 §2 Trigger: Daily_Loss_Limit = Absolute_Stop_Loss × Daily_Loss_Ratio, where Absolute_Stop_Loss = Notional × 7.5% (flat, all SIM tiers) and Daily_Loss_Ratio = 1/3.
• Soft Breach condition, per the same UC: Net_P&L ≤ −Daily_Loss_Limit (i.e. current_daily_pnl <= -daily_loss_limit) → fill clamps at 100%, with the blink rate at max-fill per BR_4.7.5.7.
• When current_daily_pnl >= 0 (no realized loss this session) → fill clamps at 0% (Ref: BR_4.7.5.5).

BR_4.7.5.2: Real-Time Update via WebSocket Push Only

The bar updates exclusively from the RULE_TRACKING WebSocket event — there is no separate polling API call for this component. (Source: QN-4.7.5-04)

BR_4.7.5.3: No-Loss / First-Day Display — Always 0% Fill

The bar shows 0% fill in both of these cases, and the UI cannot distinguish between them (both simply mean "no realized loss to display yet"):

• Trader has not lost money this session — current_daily_pnl >= 0 (i.e. Net_P&L is zero or positive, so the fill formula in BR_4.7.5.1 clamps at 0%), regardless of whether the trader is flat, in a winning position, or has an open unrealized loss that hasn't reduced Net_P&L below 0 yet.
• Trader's very first day — brand-new account that has never placed a trade. There is no separate "no data yet" visual state; a first-day account with current_daily_pnl = 0 renders identically to any other day with zero loss: 0% fill.

This UC does not compute or infer "first day" as a distinct condition — it only reads whatever current_daily_pnl/daily_loss_limit values RULE_TRACKING streams and applies the BR_4.7.5.1 formula, and a fresh account naturally streams current_daily_pnl = 0, which produces 0% fill. (Source: BA correction per user request, 2026-08-09; formula source updated per BA correction, 2026-08-19)

BR_4.7.5.4: Bar Resets to 0% Only on Soft Breach → New Session Open

The bar's fill level (and the underlying current_daily_pnl it reflects) resets back to 0 — i.e. back to showing the trader's actual loss as 0 — in exactly one scenario: the trader reached the Daily Loss Limit (Soft Breach) and the account's trading session has since opened (reset_time reached). Outside of that scenario, the bar simply tracks whatever dist_daily_loss the trader's ongoing session P&L produces; there is no other periodic or manual reset of this component.

• Daily P&L counter reset and Soft Lock lifted always move together, at reset_time — never independently (Ref: UC_4.10.1).
• reset_time varies by asset class — the reset logic itself (Soft Lock lifting, session-open detection) is owned entirely by UC_4.10.1, not covered by this UC:
  • Forex: resets at 17:00 EST (16:00 CST).
  • Futures: resets at 18:00 EST (17:00 CST).
• This UC's only responsibility at reset time is passive: once RULE_TRACKING streams the post-reset values (current_daily_pnl back to 0), the BR_4.7.5.1 formula naturally re-computes 0% fill per BR_4.7.5.5 — no separate reset-specific rendering logic exists in this UC. (Source: BA correction per user request, 2026-08-09; formula source updated per BA correction, 2026-08-19)

BR_4.7.5.5: Graduated Blink Rate — Step Function at 70% and 85% Fill

Once fill_% (Ref: BR_4.7.5.1) reaches the 70% threshold, the bar's motion-warning blink animation activates and steps up in exactly 2 stages as fill increases further — a step function, not a continuous ramp:

• The rate change at each threshold is an immediate step (jump to the new rate the instant fill_% crosses 70% or 85%), not an animated transition between rates.
• Crossing back below 70% (e.g. after the BR_4.7.5.6 reset-to-0% on new session open) stops the blink entirely, returning to the static <70% state.
• The "motion file" is the client-supplied Figma motion/animation asset for this component (Ref: dashboard_v7_full.txt, FE build input) — its authored blink frequency is the 100% reference rate this rule scales against. (Source: client instruction relayed by BA, 2026-08-20)

9. Screen Description

Changelog