---

UC_4.12.1 — Countdown Timer (LIVE)

1. Overview

References/Wireframe/Stage 2/Dashboard/Less than 10 days.png — Same visual design and motion as SIM (UC_4.7.4); the pulse/glow motion renders identically to SIM (Ref: BR_4.12.1.1). Display granularity: the counter counts down in days and hours (e.g. "42 days 6 hours remaining"), ticking down live hour by hour — same display behavior as SIM (UC_4.7.4 BR_4.7.4.3).

2. Trigger

• The Dashboard header (Ref: UC_4.1.1) renders — frontend reads days_remaining (sourced from stagnation_deadline) via REST.

3. Pre-conditions

• User is on the Dashboard, account type LIVE.

4. Post-conditions

• The counter shows the current remaining time (toward the Stagnation Deadline) in days and hours ("{days_remaining} days {hours_remaining} hours remaining"), ticking down live as each hour passes; the pulse/glow visual state activates per BR_4.12.1.1. At days_remaining = 0, the account is Hard Breached and the Dashboard renders in a frosted-glass, action-disabled state.

5. Basic Flow

1. On Dashboard load, frontend reads days_remaining (source: stagnation_deadline) via REST — same mechanism as SIM's GET /user/status pattern, per QN-4.12.1-04.
2. Counter renders "{days_remaining} days {hours_remaining} hours remaining" — the countdown ticks down live in days and hours (same display behavior as SIM's UC_4.7.4): hours_remaining decrements every hour, and when it reaches 0, days_remaining decrements by 1.
3. [If pulse/glow threshold condition is met] → pulse/glow visual state activates on the counter (Ref: BR_4.12.1.1).
4. [If days_remaining = 0] → account enters Hard Breach: the Dashboard UI switches to a frosted-glass overlay state, and the user can no longer perform any action on the Dashboard screen (consequence flow detail per UC_4.15.2, not yet documented in this repo — not repeated here).

6. Alternative Flow

• [If days_remaining (Stagnation Deadline) drops below 48h while the account's Drawdown Defense Protocol 48h cooling-off timer is simultaneously counting down] → the Stagnation Deadline is not paused, extended, or superseded by the concurrent Defense cooling-off window; if the Stagnation Deadline reaches 0 before the trader resumes trading, the account is still Hard Breached and terminated on schedule, exactly as in Basic Flow step 4 — Defense being active provides no grace period or protection against the Stagnation countdown (Ref: BR_4.12.1.3). The Dashboard renders the same frosted-glass Hard Breach state described in UC_4.15.2 §5 Basic Flow — Step 6 / §9 Wireframe; the Defense Protocol's own dial/state-label widget (UC_4.12.2 BR_4.12.2.3, UC_4.12.2 BR_4.12.2.4) is superseded by the Hard Breach frost the same way any other widget is (Ref: UC_4.15.2 Post-conditions).

7. Exceptional Flow

• days_remaining reaches 0 (Stagnation Deadline hit) → Hard Breach and frosted-glass lockout per Basic Flow step 4. Detailed breach consequence logic itself hands off to UC_4.15.2 (not yet documented in this repo) per Flow 19/Flow 7 — not repeated here (single-source-of-truth principle, same pattern as UC_4.7.4 → UC_4.9.4).

8. Business Rules

BR_4.12.1.1: Pulse/Glow Threshold — Same Mechanism as SIM

The pulse/glow visual state on this counter follows the exact same display mechanism as SIM's BR_4.7.4.1 — there is no separate LIVE-specific rule. The threshold and motion behavior are identical to SIM (days_remaining <= 10, same visual intensity); only the countdown target differs (stagnation_deadline for LIVE vs. expiration_date for SIM), which does not change the pulse/glow rule itself.

BR_4.12.1.2: days_remaining Formula — Same Mechanism as SIM, stagnation_deadline Source

days_remaining = stagnation_deadline − Today; stagnation_deadline = Today + 90 days, clamped to 0 if negative — the counter never displays a negative number. Field name stays days_remaining (same field name as SIM), but the underlying source is stagnation_deadline instead of SIM's expiration_date (Source: QN-4.12.1-04). Because the mechanism is REST (not WebSocket), CR-14 (WS Reconnection Resiliency) does not apply to this UC (Source: QN-4.12.1-05).

BR_4.12.1.3: Stagnation Deadline Is Independent of the Drawdown Defense Cooling-Off Timer — Termination Still Occurs

The Stagnation Deadline (days_remaining, this UC) and the Drawdown Defense Protocol's 48h cooling-off timer (UC_4.12.2 BR_4.12.2.3, owned by UC_4.15.4, not yet documented in this repo) are two independent countdowns that can run concurrently — an account can have days_remaining < 48h on the Stagnation Deadline while simultaneously inside a Defense Protocol 48h cooling-off window.

• Being inside the Defense cooling-off window does not pause, extend, or otherwise protect the account from the Stagnation Deadline.
• If the Stagnation Deadline reaches 0 before the trader resumes trading (regardless of Defense state), the account is still Hard Breached and terminated — same Flow 19 → Flow 7 mechanism as any other Stagnation termination (Ref: Basic Flow step 4, Exceptional Flow).
• The resulting Hard Breach renders the same frosted-glass lockout state documented in UC_4.15.2 (Ref: UC_4.15.2 §2 Trigger for the general Hard Breach mechanism; this UC's trigger is specifically the Stagnation Deadline, Flow 19, not the Market_Loss_When_Stopped drawdown threshold that UC otherwise documents) — the Defense Protocol's own widgets (dial, state label) are superseded by the frost the same way as any other Hard Breach (Ref: UC_4.15.2 §4 Post-conditions).
• (Source: user/BA directive, 2026-08-19 — cross-referencing the Hard Breach screen/logic in UC_4.15.2 per instruction.)

9. Screen Description