Hum Rahi

────────────────────────────────────────────────────────────
US-032.FE.1 — SOS Alert Card Frontend Implementation on Police Panel
────────────────────────────────────────────────────────────

Role
As a frontend developer on Ham Rahi working on the police panel,
I need to implement the SOS alert card exactly as specified in the
design handoff (US-032.DESIGN.1), rendering it in real time as
incoming SOS events and continuous location and audio status updates
arrive via the WebSocket channel,
So that ASI Akram sees an accurate, live, and immediately actionable
alert the moment a citizen activates SOS.

User Story
As ASI Akram,
I want an SOS alert card to appear on my panel instantly when a
citizen activates SOS, showing their name, live location, and audio
connection status, and updating automatically throughout the session,
So that I always have the current picture of the emergency without
refreshing or navigating.

In-Scope

• Listening on the existing WebSocket or server-sent event channel
  (established in US-030.BE.1) for incoming SOS session events
• Rendering the SOS alert card immediately on receipt of the incoming
  SOS event, in the incoming state as per the design spec
• Playing the audio alert sound on incoming SOS until the operator
  acknowledges; stopping the sound on acknowledgement interaction
• Implementing the acknowledgement interaction as specified in the
  design handoff; transitioning the card to the acknowledged then
  active state on completion
• Rendering the live map thumbnail on the card using the initial GPS
  coordinates from the activation payload; updating the pin position
  on every incoming location update event from US-031.BE.1
• Displaying citizen display name or masked citizen ID, activation
  timestamp, GPS coordinates, accuracy radius, and session ID in the
  card layout as specified
• Reflecting location state changes in real time: nominal, stale,
  and unavailable states as flag values arrive from US-031.BE.1
• Reflecting audio stream status in real time: connected, buffering,
  degraded, and disconnected states as stream health events arrive
  from US-030.BE.1
• Rendering multiple simultaneous SOS alert cards without layout
  collision if concurrent SOS sessions are active
• Implementing the resolved state on receipt of a session-close event;
  transitioning the card to resolved and removing it from the active
  queue after a defined display duration
• Ensuring the card and all its live updates render correctly in the
  primary police panel viewport (desktop, minimum 1280 px wide)

Out-of-Scope

• Full incident detail page (card is entry point only)
• Operator audio controls or two-way audio UI (Phase 2)
• Dispatch or unit assignment UI (Phase 2)
• Mobile or native panel implementation
• Backend WebSocket channel or location broadcast logic
  (US-030.BE.1, US-031.BE.1)
• Map tile service provisioning (INFRA dependency — assumed available)
• Citizen-facing screens

Acceptance Criteria

AC1 The SOS alert card renders on the police panel within 1 second
of the incoming SOS WebSocket event arriving at the browser
client, in the incoming state with all required fields populated.

AC2 The audio alert sound plays immediately on card render in the
incoming state and stops as soon as the operator completes the
acknowledgement interaction; it does not replay after
acknowledgement.

AC3 The live map thumbnail renders the citizen's initial pin
position on card appearance and moves the pin to each new
coordinate within 1 second of a location update event arriving
at the browser client.

AC4 The card displays citizen display name or masked ID, activation
timestamp, current GPS coordinates and accuracy radius, audio
stream status indicator, and session ID simultaneously without
truncation in the primary 1280 px viewport.

AC5 Location state transitions — nominal to stale, stale to
unavailable, and recovery back to nominal — are reflected on
the card within 1 second of the corresponding flag arriving
from the backend, using the visual treatments defined in the
design spec.

AC6 Audio stream status transitions — connected, buffering,
degraded, disconnected — are reflected on the card within
1 second of the corresponding health event arriving, using
the iconography defined in the design spec.

AC7 When two or more SOS sessions are active simultaneously, each
session renders as a separate card; cards do not overlap,
collapse each other's content, or share state.

AC8 On receipt of a session-close event, the card transitions to
the resolved state and is removed from the active queue after
the display duration defined in the design spec; no orphaned
cards remain after session close.

AC9 The card and all live update behaviours render correctly and
without visual regression in the latest stable versions of
Chrome and Edge (primary police panel browsers).

AC10 If the WebSocket connection is interrupted mid-session, the
card enters a degraded connection state and displays a
reconnecting indicator; on reconnection it resumes live
updates from the latest available data without requiring a
page reload.

Definition of Done

• Card renders within 1 second of incoming SOS event confirmed by
  QA timing test
• Audio alert plays on incoming and stops on acknowledgement
  confirmed on physical desktop setup
• Map thumbnail pin update latency within 1 second confirmed
• All seven card states rendered and verified against design spec
• Concurrent multi-card layout tested with minimum three
  simultaneous simulated SOS sessions
• Session-close resolved state and card removal confirmed
• WebSocket disconnect and reconnect behaviour confirmed
• Cross-browser test passing on Chrome and Edge latest stable
• No open P1 or P2 bugs
• Code reviewed and merged