---

UC_4.7.1 — Notification Center: Bell & Dropdown

1. Overview

🎨 Design reference: Bell — Collapsed · Bell — Expanded

2. Trigger

• The Dashboard layout (Ref: UC_4.1.1) has rendered — frontend calls GET /notifications for the initial unread badge count.
• A NOTIFICATION WebSocket event arrives while the user is on the Dashboard (Source: QN-4.7.1-03).
• User clicks the bell icon to open/close the dropdown panel.

3. Pre-conditions

• User is on the Dashboard (Ref: UC_4.1.1 §1 Overview).
• Applies to both SIM and LIVE account types — the bell icon, unread badge, and panel open/close mechanism are the same shared UI across account types. Only the underlying event set differs: SIM uses the 14 confirmed message patterns (Ref: BR_4.7.1.1); LIVE uses a separate event set (Ref: UC_4.12.4).

4. Post-conditions

• The bell badge shows the current total unread count.
• The dropdown, when open, renders the full paginated notification history starting at page 1, ordered by timestamp_utc descending (owned by UC_4.7.3; not repeated here).

5. Basic Flow

1. On Dashboard load, frontend calls GET /notifications (user_id, status=All) to populate the bell badge count only. The dropdown's list content is not fetched until the panel is opened.
2. Backend returns the total unread count.
3. Frontend renders the unread-count badge on the bell icon from the total unread count in the response (Source: QN-4.7.1-03).
4. User clicks the bell icon → dropdown panel opens, rendering the filter tabs (owned by UC_4.7.2) and the full paginated notification list, page 1 (owned by UC_4.7.3; not repeated here).
5. [If a NOTIFICATION WebSocket event arrives] → frontend prepends the new notification to the in-memory list and increments the unread badge immediately, without re-calling GET /notifications (Source: QN-4.7.1-03).
6. User clicks the bell icon again, or clicks outside the dropdown → dropdown closes.

6. Alternative Flow

• [If the user selects one of the 2 unconfirmed category tabs] (Payout Events / Mentor/Community Prompts) → the tab is shown and selectable (per A-13), but the list area renders the empty state, since no event source is wired for these categories yet (Ref: BR_4.7.1.1).
  • Context: this is a [BLOCKED — pending client confirmation] gap, not a bug; do not treat the empty list as an error state.
• [If the user selects the Level Events tab] → the tab renders the 2 NC-LVL-* notifications from BR_4.7.1.1, same as any other confirmed category — Level Events is confirmed on both SIM and LIVE (Ref: BR_4.7.1.1).

7. Exceptional Flow

• WebSocket disconnects while the dropdown is open: the currently-rendered list stays as last-known-good; no error banner. On reconnect, frontend re-calls GET /notifications to resync (same reconciliation pattern as UC_4.9.1 QN-4.9.1-11 — not yet documented in this repo).

8. Business Rules

BR_4.7.1.1: SIM Event Set — 14 Confirmed Message Patterns

SIM uses 14 confirmed message patterns (across 8 distinct Event IDs), across the 3 categories in BR_4.7.1.1. NC-RISK-05 and NC-SYS-01 each fire from a single Flow 24 webhook but carry several distinct Alert_Level values, each with its own severity and message pattern — shown below as separate rows (same Event ID, different Alert_Level, noted at the start of the Trigger Condition cell) so each pattern is traceable on its own. The 2 NC-LVL-* rows are the Level Events mapping (Ref: BR_4.7.1.1). NC-LVL-02 (Drawdown Defense Activated) is excluded from this SIM event set — it is a LIVE-only event, documented in UC_4.12.4 (Source: BA correction, 2026-08-28):

BR_4.7.1.2: Notifications Are Discrete Messages, Not Live-Ticking Countdowns

Each of the confirmed events (Ref: BR_4.7.1.1) is pushed as a discrete notification row with static text at its own checkpoint (e.g. T-30, T-10, T-1, T+1 for the News Protocol sequence). The target_timestamp field exists in the data model (nullable) but is not used by this UC to render a client-side ticking countdown inside a notification message — that live-countdown behavior belongs to the Market Status Widget (Ref: UC_4.1.3), a separate header component. (Source: QN-4.7.1-04)

BR_4.7.1.3: Real-Time Update via WebSocket Push

The bell badge (and, when the dropdown panel is open, the notification list rendered by UC_4.7.3) update immediately on receiving a NOTIFICATION WebSocket event — no polling and no re-call to GET /notifications is needed for live updates. The badge-only GET /notifications call is made once, on initial Dashboard mount; the panel's own list fetch (page 1) happens separately, each time the panel is opened (Ref: UC_4.7.3). (Source: QN-4.7.1-05)

BR_4.7.1.4: Flow 23 — News Event Currency-Relevance Mapping Logic

Elaborates the two Zapier filter conditions already referenced in NC-RISK-01–NC-RISK-04's Trigger Condition (Ref: BR_4.7.1.1):

1. Step 1 — Ingestion: Flow 23 calls a 3rd-party news API — Finnhub — to receive incoming Event Name / Impact_Level / Timestamp / Currency payloads. Finnhub is a client-confirmed change replacing the placeholder provider example (FXStreet) named in the original Zapier Integration V7.pdf §Flow 23 text ("Trigger: Webhook from External News Provider (e.g. FXStreet)") — no longer a source conflict; Finnhub is the confirmed provider going forward.
2. Step 2 — Filtering: each incoming event passes through 2 filters (Source: Zapier Integration V7.pdf §Flow 23):
   • Filter 1: Impact_Level == "High"?
   • Filter 2: Is Asset_Class relevant to the event's Currency? — the source states only this one-line condition; the relevance breakdown below is confirmed by the client:
     • Futures Traders: all whitelisted Futures indices, commodities, and treasuries (ES, NQ, CL, GC, etc.) are US-domiciled and priced/settled in USD. Any high-impact event with Currency == "USD" is automatically marked relevant and triggers the news protocol for all Futures traders — no per-account position scan needed.
     • Forex Traders: the system dynamically scans the trader's active open position metrics. If the account holds an open position on a currency pair where either the base or the quote currency matches the event's Currency (e.g., an open EURUSD position when a high-impact EUR or USD event is released), the account is flagged relevant/affected.
3. Step 3 — Persistence & Notification Sequencing: events passing both filters are saved into the system's news-event store, which then drives the sequential T-30 / T-10 / T-1 / T+1 notification checkpoints (NC-RISK-01–NC-RISK-04, Ref: BR_4.7.1.1).
4. Enforcement logic (the T-1 min POST /enforce-news-event universal P&L check, Stop_Threshold flatten, and Notional_Cap trim/liquidation actions) is out of scope for this UC — refer to the Stage 4 — Live Trading & Risk Management UC covering Flow 23 enforcement (Ref: UC_6.2.1, docs/BA/scratch/Stage4_LiveTrading_RiskManagement_Analysis.md, same reference already used for NC-RISK-03 in BR_4.7.1.1).

(Source: Zapier Integration V7.pdf §Flow 23 — News Event Manager, for Steps 1–3's filter/sequencing structure. Finnhub provider name and the Futures/Forex relevance breakdown: client-confirmed change, formalized as CHR_67 — Ref: References/CR/2026-08-28_CHR67_finnhub-replaces-fxstreet/CR_summary.md.)

9. Screen Description

---

Changelog

---