A progress bar in the persistent header (Ref:UC_4.1.1 §2) showing how much of the trader's Daily Loss Limit budget remains for the day — same UI component and real-time behavior as the SIM sibling (UC_4.7.5), but LIVE derives its limit from the per-level Table A/B Market_Loss_When_Stopped value instead of SIM's flat 7.5% (Ref: A-04, BR_4.12.5.1). Scope is UI-component only — this UC owns bar rendering and real-time update; it does not own the Daily_Loss_Limit calculation formula's implementation or the breach consequence logic (Read-Only lock, force-close positions, unfreeze timing), which are owned by UC_4.15.1 — Soft Breach: Daily Loss Limit Hit (LIVE).
Zapier Flow
—
Zapier Table
Table A/B —Market_Loss_When_Stopped (per-level notional) · Table C — Daily_Loss_Ratio (consumed by UC_4.15.1's calculation, not by this UC directly)
The Dashboard header (Ref: UC_4.1.1) renders — frontend subscribes to the RULE_TRACKING WebSocket event, same mechanism as SIM.
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 — same as SIM, Ref: UC_4.7.5 BR_4.7.5.1; BR_4.12.5.2).
The bar's fill level and visual state reflect the most recently received RULE_TRACKING values, computed against the trader's current-level LIVE limit (Ref: BR_4.12.5.1).
On Dashboard load, frontend subscribes to the RULE_TRACKING WebSocket event — no separate polling call, identical mechanism to SIM (Ref: UC_4.7.5 BR_4.7.5.2).
Each RULE_TRACKING event delivers dist_daily_loss, daily_loss_limit, current_daily_pnl for the current session, where daily_loss_limit is already computed server-side from the trader's current level (Ref: BR_4.12.5.1).
Frontend computes the bar's fill percentage by checking current_daily_pnl (Net_P&L for the session) against daily_loss_limit — same formula and logic as SIM, only the daily_loss_limit source differs (Ref: BR_4.12.5.2):
[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 — same as SIM (Ref: UC_4.7.5 BR_4.7.5.5).
[If current_daily_pnl <= -daily_loss_limit] → bar renders at max/full fill with the motion-warning visual state — same as SIM (Ref: UC_4.7.5 BR_4.7.5.1; graduated blink rate below max-fill per BR_4.12.5.4).
[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 — same reset mechanism as SIM (Ref: UC_4.7.5 BR_4.7.5.6).
[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 7 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 are owned by UC_4.15.1 — Soft Breach: Daily Loss Limit Hit (LIVE), not yet documented in this repo — same ownership split as SIM's UC_4.10.1.
[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 — same rule as SIM (Ref: UC_4.7.5 §6; Source: BA/client direct instruction, 2026-08-17).
WebSocket disconnects: bar holds its last-known-good fill/state; no error banner from this component. Reconnect behavior follows the same shared pattern as SIM (Ref: UC_4.7.5 §7).
Unlike SIM, which uses a flat 7.5% of notional across all tiers as its Absolute_Stop_Loss base (Ref: UC_4.7.5 BR_4.7.5.1), LIVE's Daily Loss Limit is computed per the trader's current level (Source: BA verbatim, 2026-08-12, QnA_init_docs.md QN-4.12.5-01):
This UC does not implement or duplicate this formula, its rounding, or the Soft Breach detection/consequence logic — all of that is owned by UC_4.15.1 — Soft Breach: Daily Loss Limit Hit (LIVE), not yet documented in this repo (Source: QN-4.12.5-02).
The bar's rendering — fill % computed by checking current_daily_pnl (Net_P&L) against daily_loss_limit, 0%/max-fill states, motion-warning visual on breach, reset-on-new-session behavior — and its real-time update mechanism (RULE_TRACKING WS push only, no polling) are unchanged from SIM (Source: BA confirmation, 2026-08-12, QnA_init_docs.md QN-4.12.5-05; Ref: UC_4.7.5 BR_4.7.5.1/2/3/5/6). dist_daily_loss is streamed but not used, same as SIM. Only the daily_loss_limit value source differs (Ref: BR_4.12.5.1).
Identical rule to SIM's UC_4.7.5 BR_4.7.5.7 — once fill_% (Ref: BR_4.12.5.1) reaches 70%, the bar's motion-warning blink animation activates and steps up in exactly 2 stages, a step function not a continuous ramp:
fill_% range
Blink rate
< 70%
No blink — bar shows static fill only, no animation.
70% ≤fill_% < 85%
Blinks at50% slower than the motion file's reference blink rate (half the frequency).
Blinks at the same rate as the motion file — full reference frequency.
Rate changes step immediately at each threshold crossing, not an animated transition.
Crossing back below 70% (e.g. after the UC_4.7.5 BR_4.7.5.6 reset-to-0% on new session open) stops the blink entirely.
Since fill_% is computed identically to SIM (only the daily_loss_limit input differs, per BR_4.12.5.1), the 70%/85% thresholds apply to the same fill_% value — no LIVE-specific threshold adjustment. (Source: client instruction relayed by BA, 2026-08-20 — applied identically to both SIM and LIVE)
Displaying rule:- Fill % computed as (-current_daily_pnl / daily_loss_limit) × 100%, clamped to [0%, 100%] — checked against Net_P&L (current_daily_pnl), not the pre-computed dist_daily_loss field, where daily_loss_limit is derived per BR_4.12.5.1 (per-level Table A/B × Daily_Loss_Ratio), not SIM's flat 7.5%.- Blink animation activates at fill_% ≥ 70%, stepping through 2 rate stages: 70%–84% blinks at 50% slower than the motion file's reference rate, 85%–100% blinks at the motion file's exact reference rate; below 70% no blink — same as SIM (Ref: BR_4.12.5.4).- 0% fill / max-fill+motion-warning / reset-on-session-open — same as SIM (Ref: BR_4.12.5.2).Behaviour rule:- Passive display only — no click/interaction defined. Updates on every RULE_TRACKING WS push.
Fill % described as computed from the rawdist_daily_loss/daily_loss_limit fields (mirroring SIM's pre-correction wording); §6 had no note about the bar freezing during Hard/Soft Breach or Frosted Glass cooling-off.
Fill % now described as computed by checkingNet_P&L (current_daily_pnl) against daily_loss_limit — fill_% = min(100%, max(0%, (-current_daily_pnl / daily_loss_limit) × 100%)), same formula as SIM; dist_daily_loss is streamed but no longer described as used. §6 gained a bullet restating the Hard/Soft Breach/Frosted Glass "bar freezes" rule, mirroring SIM. The per-level Daily_Loss_Limit source formula itself (Market_Loss_When_Stopped(level) × Daily_Loss_Ratio, BR_4.12.5.1) is unchanged — only the fill-computation half was synced.
Sync requested by user immediately after the same correction was applied to SIM siblingUC_4.7.5 — LIVE and SIM must share the same Net_P&L-based fill logic, differing only in how daily_loss_limit itself is sourced. First Changelog section added to this file (none existed previously).
Blink behavior only described as a binary "motion-warning visual state" at 100% max-fill (Ref: BR_4.12.5.2/SIM's BR_4.7.5.1) — no graduated blink rate below 100%.
Added BR_4.12.5.4: graduated blink-rate step function, identical to SIM'sBR_4.7.5.7 — <70% no blink; 70%–84% blinks at 50% slower than the motion file's reference rate; ≥85% blinks at the motion file's exact reference rate. §5 Step 5 cross-references BR_4.12.5.4 without restating the rate detail (kept out of Basic Flow per BA request — detail belongs in Business Rules only).
Client instruction relayed by BA, 2026-08-20, applied identically to both SIM and LIVE — sync counterpart to the same change made toUC_4.7.5.
2026-08-20
v1.3
§5 Basic Flow Step 5, BR_4.12.5.4 (cross-refs)
Cross-referenced SIM's BR_4.7.5.3 for the max-fill/motion-warning state.
SIM removed BR_4.7.5.3 as a standalone rule (its content folded into BR_4.7.5.1/BR_4.7.5.7). Cross-references in this file updated to point to BR_4.7.5.1 instead -- no behavior change.
Sync counterpart to the BR_4.7.5.3 removal in SIM sibling UC_4.7.5.