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.
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 ofconfiguracionAudioService.notificationColoralready asserted intest/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 reachesNotificationCompat.Buildercall 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 — seeopenspec/changes/notification-visual-polish/tasks.mdfor 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
configuracionAudioServicetop-levelAudioServiceConfigconstant defined inlib/main.dart - WHEN its
androidNotificationIconfield 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 tomipmap/ic_launcher)
Scenario: Audio notification icon is distinct from the default launcher fallback
- GIVEN the
configuracionAudioServicetop-levelAudioServiceConfigconstant - WHEN its
androidNotificationIconfield 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:
PluriWaveAlarmReceiver.kt(pre-notice notification, channelpluriwave_alarm_pre_notice) —setSmallIcon(R.drawable.ic_stat_pluriwave),.setColor(...)with cyan#21D4D9.AlarmScheduler.kt(snooze countdown notification, same channel as above) — same icon + color.PluriWaveAlarmService.kt(ringing/fire notification, channelpluriwave_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.