# Delta for native-alarms Existing spec: `openspec/specs/native-alarms/spec.md` (native foreground service, sole ring-audio ownership, fade-in curve, focus/no-volume-writes, notification channel migration, "ring screen is pure UI"). None of that native/audio behavior changes in this redesign — it is a visual restyle of the Alarmas root, the alarm card, and the ringing screen. This delta ADDS requirements for card affordances, the hero skip action, the editor's preserved advanced fields, and the ringing screen's static status label. Traceable to WU8 (card + hero), WU10 (editor), WU11 (ringing screen). ## ADDED Requirements ### Requirement: Alarm Card Tap-to-Edit, Swipe-to-Delete The simplified alarm card (giant time + station + switch, no always-visible action row) MUST preserve edit and delete capability: tapping the card MUST open the editor for that alarm; swiping it MUST trigger delete (with confirmation). No capability present in the current always-visible button row may be lost. #### Scenario: Tap opens the editor - GIVEN an alarm card is visible on the Alarmas root - WHEN the user taps it - THEN the editor sheet opens pre-filled with that alarm's data #### Scenario: Swipe deletes with confirmation - GIVEN an alarm card is visible - WHEN the user swipes it and confirms - THEN that alarm is deleted and its card is removed from the list ### Requirement: Hero Banner Inline Skip The Alarmas root's hero banner MUST include an inline "Saltar" action that skips the next occurrence of the featured (soonest-firing) alarm, in addition to any per-card skip action. #### Scenario: Tapping "Saltar" on the hero banner skips the featured alarm - GIVEN the hero banner shows the soonest-firing alarm - WHEN the user taps its inline "Saltar" action - THEN that alarm's next occurrence is marked skipped, consistent with the existing skip-next behavior ### Requirement: Alarm Editor Preserves Date, Fallback Station, and Sound Fields The rewritten editor (giant inline HH:MM display, always-visible weekday circles) MUST NOT drop the existing one-time date field, the fallback-station picker, or the sound dropdown. These MUST remain reachable, e.g. under a collapsed "Advanced" section. #### Scenario: One-time date alarm is still creatable - GIVEN the user is creating a new alarm - WHEN they choose a specific one-time date instead of a weekly recurrence - THEN the date field is reachable and the saved alarm reflects that specific date, not a weekday pattern #### Scenario: Fallback station and sound remain settable - GIVEN the editor's Advanced section - WHEN the user sets a fallback station and a sound choice - THEN both persist and are reflected the next time the alarm is edited ### Requirement: Ringing Screen Shows a Static Status Label (No Live Countdown) The ringing screen's "Subiendo volumen" status MUST render as a static label with no live seconds counter. Adding a live counter is out of scope: it would require native-to-Flutter progress plumbing that is deliberately absent from the architecture. #### Scenario: Status label has no numeric countdown - GIVEN an alarm is ringing and fading in - WHEN the status label renders - THEN it shows "Subiendo volumen" (or equivalent localized text) with no accompanying seconds value that changes over time ### Requirement: Dismiss Guard and Force-Stop Banner Survive the Restyle (First-Class Regression Guard) The ringing screen's single-exit dismiss guard and force-stop retry banner MUST be preserved unmodified by the visual restyle. #### Scenario: Dismiss guard test passes unmodified - GIVEN `test/pantallas/pantalla_alarma_sonando_dismiss_guard_test.dart` - WHEN the ringing screen restyle lands - THEN that test file passes without being modified #### Scenario: Force-stop retry banner still appears on failure - GIVEN a stop action fails to actually silence the ring - WHEN the failure is detected - THEN the force-stop retry banner is shown, in whatever position the restyled layout places it