Files
pluriwave/openspec/changes/notification-visual-polish/spec.md
T
FreeTLab bccc5c48b8
Build & Deploy PluriWave / Análisis de código (push) Successful in 38s
Build & Deploy PluriWave / Build APK + AAB release (push) Successful in 2m30s
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.
2026-07-04 12:42:11 +02:00

3.8 KiB

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.