Add sound effects mode for subtle notifications

[Helmi]

Description

Add sound effects as a subtle alternative to TTS notifications. Instead of voice announcements, users can opt for discrete audio cues (chimes, tones, beeps) that convey event information without being intrusive or requiring verbal processing.

Context

• Project area: Core notification system (src/ccnotify/notify.py, src/ccnotify/config.py)
• Complexity assessment: 6/10 (moderate - new provider pattern, sound research, config integration)
• Current behavior: TTS or macOS system sounds only
• Goal: Less obtrusive notification option while maintaining information value

Technical Details

Affected files:

• src/ccnotify/notify.py - Add sound effects mode to NotificationHandler
• src/ccnotify/config.py - Extend configuration with sound effects options
• src/ccnotify/tts/ - Possibly new sound effects provider or extend existing pattern
• sounds/ or assets/sounds/ - New directory for default sound library
• pyproject.toml - Possibly new dependencies for sound generation

Current Architecture Integration:

• ✅ pydub already in use for audio processing
• ✅ play_sound_file() method exists for audio playback
• ✅ Config system supports structured options (notifications.sound_enabled)
• ✅ TTS provider pattern can be extended for sound effects

Sound Strategy Research

Option 1: Pre-built Sound Library

• Freesound.org: Creative Commons licensed sounds, professional quality
• Mixkit: 36 free notification sounds, royalty-free
• Pixabay: No attribution required, good selection

Option 2: Programmatic Generation

• pydub + numpy: Generate consistent tones/chimes
• Event-specific frequencies: Different tones for different event types
• Procedural sounds: Ensures consistency and small footprint

Option 3: Hybrid Approach (Recommended)

• Curated high-quality sounds for key events (error, completion, input needed)
• Generated sounds for less common events
• User customizable through config

Requirements

Core Functionality

1. Configuration option to enable sound effects mode instead of TTS
2. Event-specific sound mapping - different sounds for different event types:
   • tool_activity - Subtle click or soft chime
   • execution_complete - Success chime
   • error - Alert tone (not harsh)
   • input_needed - Attention tone
   • subagent_done - Completion beep
3. Sound volume control via configuration
4. Fallback to system sounds if sound effects unavailable

Advanced Features

1. Custom sound files - users can provide their own sounds
2. Sound themes - different sound palettes (minimal, professional, playful)
3. Programmatic generation for consistent sound design
4. Caching system similar to TTS caching for generated sounds

Implementation Steps

• Research and select initial sound library (CC licensed)
• Decide between extending TTS provider pattern vs. separate sound effects system
• Add configuration options for sound effects mode
• Implement sound effects handler with event mapping
• Add programmatic sound generation capabilities (optional)
• Create default sound library with appropriate licensing
• Update configuration documentation
• Test cross-platform compatibility (macOS focus, Linux consideration)

Acceptance Criteria

• Users can enable sound effects mode instead of TTS via configuration
• Different sound effects play for different event types
• Sound effects are subtle and non-intrusive
• Volume is configurable
• System falls back gracefully if sounds unavailable
• Performance impact is minimal (sounds cached/pre-loaded)
• Cross-platform compatibility maintained (at least macOS)
• Documentation updated with new configuration options

Benefits

• Reduced cognitive load: Audio cues vs. verbal processing
• Better for shared spaces: Less intrusive than voice announcements
• Faster recognition: Brief sounds vs. full sentences
• Accessibility: Works well alongside other audio (music, calls)
• Customization: Users can adjust to their preference/environment

[Helmi]

Event Categorization for Sound vs TTS

Based on further discussion, here's the refined approach for which events should use sound effects vs TTS:

Keep TTS (Attention needed - project context is critical)

• Full completion - Project name helps identify where to look
• Input needed - Need to know what's being requested and in which project
• Error - Need to know what failed and where

Use Sound Effects (Status/background events)

• Subagent finished - Simple status update
• Subagent started - Background process notification
• Some tool uses - Possibly certain MCP servers being used
• Compaction - Background process (if filterable)

Stay Silent (Already filtered by smart filtering)

• Most bash commands - Routine operations
• Most tool uses - Non-critical tool usage

Key Principle

If attention is needed, the project name is an important signal on where to look - use TTS. For background status events, subtle sounds are sufficient.

This approach maximizes the benefit of both:

• TTS: Provides context when you need to act
• Sound effects: Gives status awareness without interruption
• Silence: Eliminates noise from routine operations

The smart filtering from #14 already handles the "stay silent" category perfectly.