Files
Tobias GesellchenandClaude Sonnet 4.6 1421ad5ce1 chore(docs): widen docs-consistency test, archive stale concept docs
The TestDocsConsistency walk only iterated [".", "guides", "reference",
"analysis"] — concepts/ was silently invisible, which is why
amazon-music-oauth.md slipped into the tree without a SUMMARY entry.

Refactored to walk the entire docs/ tree, with a small dirsToSkip
allow-list (_includes, archive, diagrams, images) for asset trees.
New top-level narrative directories are picked up automatically;
only asset dirs need an explicit entry.

The wider walk surfaced six previously-hidden concepts/* files. Five
older planning artefacts ("Enhanced State Management System",
"Upstream Bose Service Simulation") moved into docs/archive/ where
the dirsToSkip already excludes them; concepts/README.md renamed to
upstream-service-simulation-overview.md since "README.md" inside
archive/ would be misleading. Spotify Overview and Amazon Music
OAuth are user-facing narrative docs and are now linked under
Concepts in SUMMARY.md.

Note: concepts/streborn-patterns.md is internal review notes (its
own opening line says so) and is currently unlinked from SUMMARY.md;
will be handled separately by the maintainer.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
2026-05-23 00:34:36 +02:00

11 KiB

Implementation Plan - Enhanced State Management System

Overview

This document provides a detailed, step-by-step implementation plan for the enhanced state management system. Each step is designed to be small, testable, and independently valuable while maintaining backward compatibility.

Development Principles

Quality Gates

Every step must pass these checks before proceeding:

  1. golangci-lint run --fix - no linting issues
  2. go test ./... - all tests pass
  3. Existing functionality remains intact
  4. New functionality has appropriate test coverage

KISS Principle

  • Write the simplest code that works
  • Avoid premature optimization
  • Use straightforward algorithms
  • Build incrementally with small changes

Leverage Existing Systems

  • Reuse interaction recording for request/response tracking
  • Build upon current parity mismatch detection
  • Extend existing datastore patterns
  • Integrate with established workflows

Phase 1: Foundation Preparation (2-3 weeks)

Step 1.1: Code Organization Preparation

Duration: 2-3 days Goal: Prepare package structure without changing behavior

Mini-milestone 1.1.1: Create account package structure

  • Create pkg/service/account/ directory
  • Add basic account.go with placeholder structs
  • Add account_test.go with basic test structure
  • Quality Check: Lint + test all packages

Mini-milestone 1.1.2: Create lifecycle package structure

  • Create pkg/service/lifecycle/ directory
  • Add basic lifecycle.go with placeholder structs
  • Add lifecycle_test.go with basic test structure
  • Quality Check: Lint + test all packages

Mini-milestone 1.1.3: Extend datastore interface preparation

  • Add placeholder methods to existing datastore for account operations
  • Ensure all existing functionality still works
  • Add tests for new placeholder methods
  • Quality Check: Lint + test all packages

Step 1.2: Account Management Foundation

Duration: 3-4 days Goal: Basic account creation and retrieval

Mini-milestone 1.2.1: Account data model

  • Define Account struct with basic fields
  • Add validation functions
  • Add comprehensive unit tests
  • Quality Check: Lint + test all packages

Mini-milestone 1.2.2: Account persistence

  • Implement account.json file read/write
  • Add atomic file operations
  • Test file operations thoroughly
  • Quality Check: Lint + test all packages

Mini-milestone 1.2.3: Account manager basic operations

  • Implement CreateAccount() function
  • Implement GetAccount() function
  • Add error handling and validation
  • Quality Check: Lint + test all packages

Mini-milestone 1.2.4: Integration with existing datastore

  • Modify datastore to use account manager
  • Ensure backward compatibility with existing accounts
  • Test migration of existing data structure
  • Quality Check: Lint + test all packages

Step 1.3: Basic API Endpoints

Duration: 2-3 days Goal: Add REST endpoints for account management

Mini-milestone 1.3.1: Account creation endpoint

  • Add POST /api/v1/accounts handler
  • Integrate with existing HTTP router
  • Add input validation and error responses
  • Quality Check: Lint + test all packages

Mini-milestone 1.3.2: Account retrieval endpoint

  • Add GET /api/v1/accounts/{id} handler
  • Add proper JSON serialization
  • Test endpoint functionality
  • Quality Check: Lint + test all packages

Mini-milestone 1.3.3: Integration testing

  • Test new endpoints with existing functionality
  • Ensure XML endpoints still work
  • Verify no breaking changes
  • Quality Check: Lint + test all packages

Phase 2: Device Lifecycle Foundation (2-3 weeks)

Step 2.1: Device State Model

Duration: 3-4 days Goal: Basic device lifecycle tracking

Mini-milestone 2.1.1: Device lifecycle data model

  • Define DeviceLifecycle struct
  • Define device states and transitions
  • Add validation and helper functions
  • Quality Check: Lint + test all packages

Mini-milestone 2.1.2: State transition logic

  • Implement basic state machine
  • Add transition validation
  • Create comprehensive tests for all transitions
  • Quality Check: Lint + test all packages

Mini-milestone 2.1.3: Lifecycle persistence

  • Implement lifecycle.json file operations
  • Add atomic updates and error handling
  • Test persistence thoroughly
  • Quality Check: Lint + test all packages

Step 2.2: Event Processing Foundation

Duration: 3-4 days Goal: Basic event handling and logging

Mini-milestone 2.2.1: Event data model

  • Define DeviceEvent struct
  • Add event types and validation
  • Create event builder helpers
  • Quality Check: Lint + test all packages

Mini-milestone 2.2.2: Simple event logging

  • Implement append-only event log writing
  • Add structured log format
  • Test log operations and rotation
  • Quality Check: Lint + test all packages

Mini-milestone 2.2.3: Event processing pipeline

  • Create basic synchronous event processor
  • Add event validation and filtering
  • Integrate with existing WebSocket events
  • Quality Check: Lint + test all packages

Step 2.3: Lifecycle Integration

Duration: 2-3 days Goal: Connect lifecycle to existing systems

Mini-milestone 2.3.1: Discovery integration

  • Trigger lifecycle events on device discovery
  • Update device state on discovery
  • Test discovery workflow with lifecycle
  • Quality Check: Lint + test all packages

Mini-milestone 2.3.2: WebSocket integration

  • Process WebSocket events through lifecycle
  • Update device state based on events
  • Log significant state changes
  • Quality Check: Lint + test all packages

Mini-milestone 2.3.3: Migration integration

  • Integrate lifecycle with existing migration system
  • Track migration events and state changes
  • Ensure existing migration still works
  • Quality Check: Lint + test all packages

Phase 3: Enhanced Features (2-3 weeks)

Step 3.1: Enhanced Mirroring

Duration: 3-4 days Goal: Improve existing parity detection

Mini-milestone 3.1.1: Extended disparity logging

  • Enhance existing parity mismatch logging
  • Add more detailed disparity information
  • Improve log format for analysis
  • Quality Check: Lint + test all packages

Mini-milestone 3.1.2: Disparity categorization

  • Add severity levels to disparities
  • Categorize different types of mismatches
  • Add filtering and search capabilities
  • Quality Check: Lint + test all packages

Mini-milestone 3.1.3: Enhanced mirror middleware

  • Extend existing mirror functionality
  • Add better response comparison
  • Integrate with lifecycle events
  • Quality Check: Lint + test all packages

Step 3.2: Data Source Management

Duration: 3-4 days Goal: Smart routing between local and upstream

Mini-milestone 3.2.1: Data source configuration

  • Add per-device source preferences
  • Implement source switching logic
  • Add configuration persistence
  • Quality Check: Lint + test all packages

Mini-milestone 3.2.2: Fallback mechanisms

  • Add graceful fallback on source failure
  • Implement simple health checking
  • Test fallback scenarios
  • Quality Check: Lint + test all packages

Mini-milestone 3.2.3: Migration orchestration

  • Add device-by-device migration control
  • Track migration progress
  • Add rollback capabilities
  • Quality Check: Lint + test all packages

Step 3.3: Monitoring and Health

Duration: 2-3 days Goal: Basic system monitoring

Mini-milestone 3.3.1: Health check endpoints

  • Add system health endpoints
  • Report service status
  • Add basic metrics collection
  • Quality Check: Lint + test all packages

Mini-milestone 3.3.2: Device health tracking

  • Track device connectivity
  • Monitor response times
  • Log health status changes
  • Quality Check: Lint + test all packages

Mini-milestone 3.3.3: System metrics

  • Add basic performance metrics
  • Track resource usage
  • Add metrics endpoints
  • Quality Check: Lint + test all packages

Quality Assurance Strategy

Testing Requirements

Each mini-milestone must include:

  • Unit tests for new functions
  • Integration tests for modified workflows
  • Regression tests for existing functionality
  • Performance tests for critical paths

Test Categories

Unit Tests

  • Test individual functions and methods
  • Mock external dependencies
  • Cover error conditions and edge cases
  • Aim for >90% code coverage on new code

Integration Tests

  • Test component interactions
  • Use real file operations in test environment
  • Test HTTP endpoints end-to-end
  • Verify existing functionality unchanged

Regression Tests

  • Ensure existing XML endpoints work
  • Verify device discovery still functions
  • Check migration compatibility
  • Test WebSocket event processing

Continuous Quality Checks

Pre-commit Checks

# Before each commit
golangci-lint run --fix
go test ./...
go test -race ./...

Milestone Validation

# Before marking milestone complete
golangci-lint run --fix
go test ./... -v
go test -race ./... -v
go test ./... -bench=.

Integration Validation

# Test with real soundtouch-service
make build
./soundtouch-service &
# Run integration test suite
make integration-test

Risk Mitigation

Backward Compatibility

  • All existing APIs must continue working
  • File structure changes must be additive
  • Configuration changes must have defaults
  • Migration paths for existing data

Rollback Strategy

  • Each step can be independently reverted
  • Configuration flags for new features
  • Graceful degradation when features disabled
  • Clear rollback documentation

Performance Impact

  • Monitor memory usage during development
  • Profile critical paths before and after changes
  • Set performance regression alerts
  • Simple before complex solutions

Documentation Requirements

Code Documentation

  • Comprehensive godoc comments
  • Example usage in comments
  • Error conditions documented
  • Performance characteristics noted

User Documentation

  • Update existing guides for new features
  • Add migration guides for new functionality
  • Create troubleshooting documentation
  • Update API documentation

Development Documentation

  • Architecture decision records
  • Testing strategy documentation
  • Deployment and rollback procedures
  • Performance benchmarking results

Success Criteria

Technical Metrics

  • All tests pass consistently
  • No linting issues
  • Memory usage increase <50MB
  • Response time degradation <10%

Functional Metrics

  • All existing functionality preserved
  • New account management works reliably
  • Device lifecycle tracking is accurate
  • Enhanced monitoring provides value

Quality Metrics

  • Code coverage maintained >85%
  • No critical security issues
  • Documentation completeness >95%
  • Community feedback positive

This implementation plan ensures steady, reliable progress while maintaining the quality and simplicity principles essential for the project's success.