# Spec: Notification Visual Polish

## Scope Note (spec-weight rationale)

This change is presentation-only wiring across 4 notification builders (3 Kotlin,
1 Dart). It is deliberately spec-light:

- **Testable surface**: exactly one — `configuracionAudioService.androidNotificationIcon`
  (a Dart top-level const field), following the established precedent of
  `configuracionAudioService.notificationColor` already asserted in
  `test/tema/notification_color_test.dart`.
- **Non-testable surface**: the 3 Kotlin alarm notification builders
  (`PluriWaveAlarmReceiver.kt`, `AlarmScheduler.kt`, `PluriWaveAlarmService.kt`).
  No Kotlin/native test harness exists in this repo (confirmed during exploration —
  no JVM/Robolectric/instrumented test infra reaches `NotificationCompat.Builder`
  call chains). These are verified via **manual/on-device QA**, not spec scenarios.
  Writing given/when/then for these would fabricate automated verification that
  cannot exist under current tooling — see `openspec/changes/notification-visual-polish/tasks.md`
  for the manual QA checklist instead.

No existing capability is added, removed, or behaviorally altered. This spec adds
one new normative requirement (icon resource wiring on the audio notification
config) to the `alarm-notifications` capability area and documents the Kotlin-side
change as an implementation-verified-by-QA fact, not a spec requirement.

---

## ADDED Requirements

### Requirement: Audio Notification Icon Resource

The audio/media playback notification configuration (`configuracionAudioService`
in `lib/main.dart`) MUST declare an explicit `androidNotificationIcon` pointing to
the app's monochrome status-bar drawable, so Android does not fall back to
silhouetting the full-color `mipmap/ic_launcher` asset.

#### Scenario: Audio notification config declares the branded monochrome icon

- **GIVEN** the `configuracionAudioService` top-level `AudioServiceConfig` constant
  defined in `lib/main.dart`
- **WHEN** its `androidNotificationIcon` field is read
- **THEN** the value MUST equal `'drawable/ic_stat_pluriwave'`
- **AND** the value MUST NOT be `null` (the audio_service package default,
  which resolves to `mipmap/ic_launcher`)

#### Scenario: Audio notification icon is distinct from the default launcher fallback

- **GIVEN** the `configuracionAudioService` top-level `AudioServiceConfig` constant
- **WHEN** its `androidNotificationIcon` field is compared against the package
  default resource string `'mipmap/ic_launcher'`
- **THEN** the two values MUST differ

---

## Non-Normative: Kotlin Alarm Notification Builders (manual QA, not spec scenarios)

The following 3 call sites receive the same icon resource and a shared cyan
brand color. They are implementation facts carried over from the proposal,
recorded here for traceability only — they are **not** testable requirements
and MUST NOT be treated as spec scenarios requiring automated coverage:

1. `PluriWaveAlarmReceiver.kt` (pre-notice notification, channel
   `pluriwave_alarm_pre_notice`) — `setSmallIcon(R.drawable.ic_stat_pluriwave)`,
   `.setColor(...)` with cyan `#21D4D9`.
2. `AlarmScheduler.kt` (snooze countdown notification, same channel as above) —
   same icon + color.
3. `PluriWaveAlarmService.kt` (ringing/fire notification, channel
   `pluriwave_alarm_fire_v2`) — same icon + color.

Verification for these 3 sites is a manual/on-device QA checklist item
(status-bar legibility at small size, tint applied where the OS honors
`setColor`), not an automated spec scenario, because no Kotlin/native test
harness exists in this repository to assert against `NotificationCompat.Builder`
output.

---

## MODIFIED Requirements

None. No existing spec-level behavior changes; the pre-notice countdown,
snooze rescheduling, and alarm-fire capabilities are unaffected by this
presentation-only icon/color change.

## REMOVED Requirements

None.