Hum Rahi

────────────────────────────────────────────────────────────
US-029.FE.1 — Early Release Cancellation — Frontend Behaviour
────────────────────────────────────────────────────────────

Role
As a frontend developer on Ham Rahi,
I need to ensure that releasing the SOS button before the 5-second hold
completes immediately cancels the activation sequence and leaves no
residual state in the UI,
So that a citizen who accidentally begins pressing the SOS button
experiences a clean, silent reset with zero side effects.

User Story
As Priya,
I want the SOS countdown to cancel immediately and silently if I lift
my finger before 5 seconds,
So that an accidental or hesitant press does not trigger any emergency
action, alert, or visible trace of an attempted activation.

In-Scope

• Detecting pointer-up or touch-end events on the SOS button surface
  at any point during the 0–4.9 s hold window
• Immediately halting the countdown ring animation on early release
• Resetting the ring to its idle state (zero progress) — animated
  reset or snap-to-zero per the design spec from US-028.DESIGN.1
• Ensuring no activation event is emitted toward the backend boundary
  (US-029.BE.1) on early release
• Suppressing haptic feedback immediately on release; no further haptic
  pulses after the finger lifts
• Ensuring the button is fully interactive again (ready for a fresh
  hold attempt) immediately after the reset completes
• Handling edge cases: release at exactly the 5 s boundary — if the
  activation event has not yet been emitted, the release must cancel;
  if the activation event has already been emitted, cancellation is
  no longer possible (ownership passes to US-029.BE.1)
• Handling involuntary release caused by the OS (incoming call overlay,
  system interrupt) — treated identically to a manual early release

Out-of-Scope

• Cancellation of an SOS that has already been fully activated
  (post-5-second flows are outside this story)
• Any server-side cancel or rollback logic (covered in US-029.BE.1)
• User-facing confirmation dialogs or undo prompts on early release
  (MVP excludes these)
• Women Safety Companion SOS cancellation (separate epic)
• Police panel notification of a cancelled attempt

Acceptance Criteria

AC1 When the user releases the SOS button at any point between 0 s
and 4.9 s of hold, the countdown ring stops advancing and returns
to the idle zero-progress state; no partial ring remains visible
after the reset.

AC2 No SOS activation event is emitted to the backend boundary on
early release, regardless of how close to 5 s the release occurs
(provided the 5-second threshold had not yet been crossed).

AC3 All haptic feedback ceases immediately on finger lift; no
scheduled haptic pulses fire after the release event is detected.

AC4 The SOS button returns to a fully pressable idle state immediately
after reset — a fresh hold attempt can begin without any delay,
cooldown, or lock-out period.

AC5 An OS-level interrupt (incoming call screen, notification shade
pull-down, or app backgrounding) that lifts the touch context
mid-hold is treated as an early release and triggers the same
clean reset behaviour.

AC6 A release event registered at exactly the 5-second boundary
is resolved deterministically: if the activation event has
already been dispatched, the release is ignored at the frontend
layer; if it has not, the release cancels and no event is sent.

AC7 After an early release, the UI contains no visible or audible
indication that an SOS was attempted — the screen returns to its
pre-hold appearance in full.

AC8 The reset animation (ring returning to zero) completes within
300 ms of the release event; it must not linger or feel sluggish.

Definition of Done

• Early release at 1 s, 2 s, 3 s, 4 s, and 4.9 s tested and confirmed
  producing clean reset with no activation event emitted
• OS-interrupt mid-hold tested on physical Android and iOS devices
• Haptic silence after release confirmed on physical device
• Boundary condition at exactly 5 s documented and tested
• Button re-pressable immediately after reset confirmed
• No open P1 or P2 bugs against this component
• Code reviewed and merged