docs(openspec): add SDD artifact trail for recent alarm and EQ changes

Persist the exploration, proposal, spec, design, tasks, and
verify/archive reports produced during the multi-device EQ,
alarm-countdown, and notification-visual-polish SDD cycles.

openspec/changes/notification-visual-polish/spec.md

@@ -0,0 +1,86 @@
+# 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.