Src-Tauri Codebase Cleanup Plan

Analysis Summary

After analyzing the src-tauri codebase, I've identified several areas requiring cleanup and optimization. The codebase shows signs of rapid development with some architectural debt that can be addressed systematically.

Key Issues Identified

1. Legacy Code Presence

• lib_old_complex.rs (2,437 lines) - Large legacy file that appears to contain old implementation
• Dual Audio Systems - Both audio/ and audio_v2/ modules exist, indicating migration in progress
• Multiple pub use * wildcard imports creating unclear dependency boundaries

2. Incomplete Implementation Areas

• 20+ TODO comments across audio_v2 modules indicating incomplete features
• Substantial placeholder code in audio_v2 system (Phase 2, 3, 4 implementations pending)
• Debug logging scattered throughout codebase (9 occurrences of println!/dbg!)

3. Module Organization Issues

• Redundant module patterns - Many modules follow identical structure (mod.rs with single pub use *)
• Unclear boundaries between audio systems
• Command/handler duplication in multiple modules

4. Dependency Management

• 122 lines in Cargo.toml with some potentially unused dependencies
• Git dependencies that could be moved to stable releases
• Complex feature flags for hardware acceleration (currently disabled)

Cleanup Plan (Phased Approach)

Phase 1: Remove Dead Code & Legacy Systems

Priority: High | Risk: Low | Estimated: 2-3 hours

1. Remove legacy file

   • Delete lib_old_complex.rs after ensuring no active dependencies
   • Update any remaining references

2. Consolidate audio systems

   • Evaluate audio_v2 completion status
   • Either complete audio_v2 migration or remove incomplete modules
   • Maintain single, clear audio system architecture

3. Clean up TODO markers

   • Address or document 20+ TODO/FIXME comments
   • Remove placeholder implementations that won't be completed
   • Convert remaining TODOs to proper issue tracking

Phase 2: Refactor Module Organization

Priority: Medium | Risk: Medium | Estimated: 4-5 hours

1. Simplify module structure

   • Remove redundant mod.rs files with single pub use statements
   • Consolidate related functionality into fewer, more cohesive modules
   • Establish clear module boundaries and responsibilities

2. Standardize command patterns

   • Create consistent command/handler patterns across modules
   • Reduce command duplication between modules
   • Implement shared command traits where applicable

3. Improve imports and exports

   • Replace pub use * with explicit imports where possible
   • Create clear public APIs for each module
   • Remove unused imports and dead code markers

Phase 3: Optimize Dependencies & Configuration

Priority: Medium | Risk: Low | Estimated: 2-3 hours

1. Dependency audit

   • Review all 40+ dependencies for actual usage
   • Move git dependencies to stable crate versions where possible
   • Remove unused dependencies
   • Consolidate duplicate dependencies

2. Feature flag optimization

   • Re-enable and test hardware acceleration features
   • Create sensible default feature combinations
   • Document feature flag usage and platform requirements

3. Configuration cleanup

   • Standardize configuration patterns across modules
   • Centralize shared configuration logic
   • Improve error handling consistency

Phase 4: Code Quality Improvements

Priority: Low | Risk: Low | Estimated: 3-4 hours

1. Error handling standardization

   • Replace panic-prone patterns with proper error handling
   • Implement consistent error types across modules
   • Improve error messaging and logging

2. Performance optimizations

   • Review large files (1000+ lines) for splitting opportunities
   • Optimize async/await patterns
   • Reduce memory allocations in hot paths

3. Documentation and testing

   • Add module-level documentation
   • Document public APIs
   • Consider adding integration tests for critical paths

Risk Assessment

• Low Risk: Dependency cleanup, documentation, removing TODOs
• Medium Risk: Module restructuring, audio system consolidation
• High Risk: None identified - changes are mostly additive or clearly isolated

Success Metrics

• Reduce total lines of code by 15-20%
• Eliminate all TODO/FIXME comments
• Achieve faster compilation times
• Reduce module complexity and improve maintainability
• Ensure all existing functionality remains intact

Recommended Execution Order

1. Start with Phase 1 (dead code removal) - safest changes
2. Proceed to Phase 3 (dependencies) - independent of code structure
3. Execute Phase 2 (refactoring) - requires most careful attention
4. Complete with Phase 4 (quality improvements) - adds polish

This plan will significantly improve code maintainability while preserving all existing functionality.