- Audited 1,891 text size class usages across 342 files
- Documented usage distribution: text-sm (870), text-xs (596), text-2xl (130), etc.
- Identified top 10 files with highest usage
- Analyzed usage patterns by component type (pages, forms, cards, navigation)
- Identified inconsistencies in heading hierarchies and body text sizes
- Provided recommendations for standardization
- Created comprehensive audit report in apps/web/docs/TYPOGRAPHY_AUDIT_REPORT.md
- Action 7.1.1.3 complete
- Created apps/web/tailwind.config.ts with documentation
- Verified text size utilities (text-xs through text-4xl) already working
- Confirmed 1871+ usages of text size classes throughout codebase
- Tailwind v4 automatically generates utilities from CSS variables in @theme
- All utilities functional via design-tokens.css
- Action 7.1.1.2 complete
- Verified all type scale variables (--text-xs through --text-4xl) already exist
- Values match standard Tailwind type scale
- All sizes properly documented with pixel equivalents
- Action 7.1.1.1 complete (already implemented)
- Edge cases for infinite scroll now handled
- End of list indicator added
- Error handling for scroll errors added
- Epic 6 (Scalability & Evolution) complete
- Added end of list indicator when all tracks loaded (hasNextPage false)
- Shows track count in end of list message
- Added error handling for infinite scroll errors (errors after initial load)
- Shows retry button when error occurs during scroll
- Only shows error indicator when tracks already loaded (not initial error)
- Edge cases now handled gracefully
- Action 6.3.1.5 complete
- Removed old page state reference from useEffect
- Fixed genres/formats extraction to use filteredTracks
- Updated TODO list with Action 6.3.1.3 completion
- Converted from useQuery with pagination to useInfiniteQuery
- Removed page state (no longer needed)
- Flattened all pages into single filteredTracks array
- Integrated useInfiniteScroll hook with VirtualizedList
- Removed pagination component (replaced with infinite scroll)
- Added loading indicator when fetching next page
- Updated query invalidation to use correct query key
- Fixed batchUpdate to use tracksApi.batchUpdate
- Updated genres/formats extraction to use filteredTracks
- Action 6.3.1.3 complete
- Verified Suspense boundaries with LoadingSpinner fallback in LazyComponent.tsx
- Verified LazyErrorBoundary wraps all lazy-loaded components
- Verified ErrorBoundary wraps all routes in router/index.tsx
- Confirmed loading states show during lazy load
- Confirmed error boundaries catch lazy loading and runtime errors
- All lazy components automatically include loading states and error boundaries
- Actions 6.2.1.5 and 6.2.1.6 complete (already implemented)
- Verified all routes in router/index.tsx use Lazy* components
- Confirmed LazyComponent.tsx implements React.lazy() with Suspense
- All page components are dynamically imported
- Error boundaries and loading states already in place
- Action 6.2.1.1 complete (already implemented)
- Audited all feature API files in features/*/api/
- Verified usage of each file:
- features/tracks/api/trackApi.ts: Used by services/api/tracks.ts
- features/auth/api/authApi.ts: Re-export for backward compatibility
- features/webhooks/api/webhookApi.ts: Used by WebhooksPage
- features/sessions/api/sessionsApi.ts: Used by SessionsPage
- features/admin/api/auditService.ts: Used by AdminDashboardPage
- Conclusion: No obsolete files found - all serve a purpose
- Action 6.1.1.11 complete
- Updated features/auth/api/authApi.ts to re-export from services/api/auth.ts
- Added deprecation comments to features/tracks/api/trackApi.ts
- Added documentation comments to webhooks, sessions, and admin API files
- All feature API files now document their relationship to the service layer
- Maintains backward compatibility
- No breaking changes
- Action 6.1.1.10 complete
- Updated apps/web/src/services/api/index.ts to export all API services
- Exports apiClient and utilities from './client'
- Exports authApi and types from './auth'
- Exports tracksApi and types from './tracks'
- Exports usersApi and types from './users'
- Exports playlistsApi and types from './playlists'
- Removed duplicate apiClient export from './auth'
- Added documentation comments for each service section
- All services properly exported and accessible via barrel export
- No TypeScript errors
- Action 6.1.1.9 complete
- Replaced imports in VerifyEmailPage.tsx (verifyEmail, resendVerificationEmail → authApi.verifyEmail, authApi.resendVerification)
- Replaced imports in useUsernameAvailability.ts (checkUsernameAvailability → authApi.checkUsername with response.available extraction)
- Replaced imports in usePasswordReset.ts (requestPasswordReset, resetPassword → authApi.requestPasswordReset, authApi.resetPassword)
- Replaced imports in RegisterPage.tsx (resendVerificationEmail → authApi.resendVerification)
- All function calls updated to use authApi methods with proper request object wrapping
- Test files still use direct imports (acceptable - tests can use implementation details)
- AuthContext.tsx uses services/authService (legacy service, separate from features/auth/services/authService)
- No TypeScript errors related to authApi
- Action 6.1.1.8 complete
- Replaced imports in UserProfilePage.tsx (listPlaylists → playlistsApi.list)
- Replaced imports in PlaylistDetailPage.tsx (getCollaborators → playlistsApi.getCollaborators)
- Replaced imports in CreatePlaylistDialog.tsx (createPlaylist → playlistsApi.create)
- Replaced imports in PlaylistList.tsx (searchPlaylists → playlistsApi.search)
- Replaced imports in CollaboratorManagement.tsx (getCollaborators → playlistsApi.getCollaborators)
- Replaced imports in PlaylistSearch.tsx (searchPlaylists → playlistsApi.search)
- Replaced imports in unifiedSearchService.ts (searchPlaylists → playlistsApi.search)
- Replaced imports in GlobalSearchBar.tsx (searchPlaylists → playlistsApi.search)
- Fixed type imports in services/api/playlists.ts (types from types.ts, not playlistService.ts)
- All function calls updated to use playlistsApi methods
- Test files and hooks still use direct imports (acceptable - tests can use implementation details, hooks will be updated in Action 6.1.1.10)
- No TypeScript errors related to playlistsApi
- Action 6.1.1.7 complete
- Replaced imports in UserProfilePage.tsx (getProfileByUsername → usersApi.getProfileByUsername)
- Replaced imports in SettingsPage.tsx (getSettings, updateSettings → usersApi.getSettings, usersApi.updateSettings)
- Replaced imports in ProfileForm.tsx (calculateProfileCompletion → usersApi.calculateProfileCompletion)
- Replaced dynamic imports in avatar-upload.tsx (uploadAvatar, deleteAvatar → usersApi.uploadAvatar, usersApi.deleteAvatar)
- All function calls updated to use usersApi methods
- Test files still use direct imports (acceptable - tests can use implementation details)
- No TypeScript errors related to usersApi
- Action 6.1.1.6 complete
- Replaced imports in UploadModal.tsx (uploadTrack → tracksApi.create)
- Replaced imports in ShareDialog.tsx (createTrackShare → tracksApi.createShare)
- Replaced imports in LibraryPage.tsx (getTracks, batchDeleteTracks, batchUpdateTracks → tracksApi.list, tracksApi.batchDelete, tracksApi.batchUpdate)
- Replaced imports in UserProfilePage.tsx (getTracks → tracksApi.list)
- All function calls updated to use tracksApi methods
- Types re-exported from tracksApi for convenience
- No direct imports from @/features/tracks/api/trackApi remain in feature components
- Test files still use direct imports (acceptable - tests can use implementation details)
- No TypeScript errors related to tracksApi
- Action 6.1.1.2 complete
- Created apps/web/src/services/api/tracks.ts with tracksApi object
- Exports: list, get, create, update, delete, getStats, getHistory, download, like, unlike, getLikes, createShare
- Includes chunked upload methods: initiateChunkedUpload, uploadChunk, completeChunkedUpload
- Includes batch operations: batchDelete, batchUpdate
- Wraps existing track API functions from features/tracks/api/trackApi.ts
- Includes getTrack from features/tracks/services/trackService.ts for single track retrieval
- Re-exports all related types for convenience
- Added to services/api/index.ts for barrel export
- No TypeScript errors
- Follows existing service layer pattern (similar to auth.ts)
- Action 6.1.1.1 complete
- Added PROACTIVE_REFRESH_INTERVAL_MS constant (4 minutes)
- Reduced PROACTIVE_REFRESH_BUFFER_MS to 1 minute (tokens expire in 5 min)
- Added proactiveRefreshInterval variable to track periodic refresh
- Created startPeriodicRefresh() function that sets up interval to refresh every 4 minutes
- Updated scheduleProactiveRefresh() to call startPeriodicRefresh()
- Updated cancelProactiveRefresh() to also clear the interval
- Periodic refresh checks token validity before refreshing
- Stops periodic refresh if token is expired or missing
- No TypeScript errors
- Works with existing token refresh infrastructure
- Action 5.1.1.5 complete
- Changed default AccessTokenTTL from 15 minutes to 5 minutes in jwt_service.go
- Updated test mock in mocks_test.go to match new default
- All references to AccessTokenTTL automatically use new value
- Tests pass successfully
- No breaking changes - frontend already handles token refresh
- Action 5.1.1.4 complete
- Integrated useFormValidation into features/auth/components/RegisterForm.tsx
- Integrated useFormValidation into features/auth/components/LoginForm.tsx
- Integrated useFormValidation into components/forms/RegisterForm.tsx
- Integrated useFormValidation into components/forms/LoginForm.tsx
- All forms now use backend pre-validation with debouncing (300ms)
- Backend validation errors displayed alongside client-side errors
- Note: Other forms require backend validation types to be added first
- Action 5.2.1.4 complete
- Integrated useFormValidation hook into RegisterForm
- Integrated useFormValidation hook into LoginForm
- Validation triggers on form data change (debounced 300ms)
- Backend validation errors displayed alongside client-side errors
- Errors mapped to correct form fields
- Uses watch() from react-hook-form to monitor form changes
- Handles field name mapping (password_confirm vs password_confirmation)
- No TypeScript errors
- Action 5.2.1.2 complete
- Created useFormValidation hook with validate function
- Accepts validation type (e.g., "RegisterRequest", "LoginRequest")
- Calls /api/v1/validate endpoint with type and data
- Returns validation state: isValidating, errors, isValid, error
- Provides clear() function to reset validation state
- Handles both wrapped and direct API response formats
- Uses parseApiError for consistent error handling
- Exported from hooks/index.ts with types
- No TypeScript errors
- Follows existing hook patterns
- Action 5.2.1.3 complete
- Created ValidateHandler with Validate method
- Endpoint accepts POST /api/v1/validate with type and data
- Supports RegisterRequest and LoginRequest validation types
- Uses existing validator from CommonHandler
- Returns ValidateResponse with valid flag and errors array
- Public endpoint (no auth required)
- Route registered in setupValidateRoutes
- Code compiles successfully
- Follows existing handler patterns
- Action 5.2.1.1 complete
- Created useIsRateLimited() hook to check rate limit state
- Updated CommentSection submit button to disable when rate limited
- Updated LikeButton to disable when rate limited
- Updated PlaylistForm submit button to disable when rate limited
- Updated ChatInput send button to disable when rate limited
- Updated UploadModal upload button to disable when rate limited
- All buttons check isLimited from rate limit store
- Hook uses Zustand selector for efficient re-renders
- Pattern established for future mutation buttons
- Action 5.4.1.4 complete
- Action 5.4.1.5: Countdown timer already implemented in RateLimitIndicator
- Action 5.4.1.7: Store integration already implemented via useRateLimitStore()
- Both actions were completed as part of Action 5.4.1.2
- Added RateLimitIndicator component to Header
- Placed after NotificationMenu for visibility
- Component automatically shows/hides based on rate limit state
- No TypeScript errors
- Action 5.4.1.3 complete
- Created RateLimitIndicator component to display rate limit status
- Shows when user is rate limited or when remaining < 20% of limit
- Displays remaining requests (e.g., "50/100 requests")
- Shows countdown timer until reset (formatted as "5m 30s" or "1h 15m")
- Uses AlertTriangle and Clock icons from lucide-react
- Color-coded: red for critical (rate limited), gold for warning (< 20% remaining)
- Updates timer every second using useEffect
- Returns null when no rate limit data or not limited
- Follows existing component patterns (similar to OfflineIndicator)
- Action 5.4.1.2 complete
- Created rate limit store (apps/web/src/stores/rateLimit.ts) to store parsed headers
- Added header parsing in success response interceptor:
- X-RateLimit-Limit: Maximum requests allowed
- X-RateLimit-Remaining: Requests remaining
- X-RateLimit-Reset: Unix timestamp when limit resets
- Added header parsing in error response interceptor:
- Includes Retry-After header for 429 errors
- All rate limit headers parsed from both lowercase and uppercase variants
- Store automatically updated on every API response
- Store includes isLimited flag calculated from remaining/retryAfter
- Uses Zustand with persistence for cross-tab state
- Actions 5.4.1.1 and 5.4.1.6 complete
- Added "Copy Request ID" button that copies request ID to clipboard
- Button appears for server errors when request_id is available
- Uses modern Clipboard API with fallback to execCommand
- Shows success toast when copied
- Added alongside existing "Report Issue" button
- Fixed TypeScript error in isServerError calculation
- Action 5.3.1.2 complete
- Removed development-only check for request ID in formatErrorMessage function
- Request ID now always included when includeRequestId parameter is true
- Improves error correlation in production environments
- Updated comment to reflect change
- Action 5.3.1.1 complete
- Added optimistic updates to notification mutations:
- markAsReadMutation: Optimistically marks notification as read
- markAllAsReadMutation: Optimistically marks all notifications as read
- Updated in both NotificationsPage and NotificationMenu
- Added optimistic updates to share link mutations:
- createShareMutation: Optimistically adds share link to local state
- revokeShareMutation: Optimistically removes share link from local state
- Added optimistic updates to chat mutations:
- leaveRoomMutation: Optimistically removes conversation from list
- deleteRoomMutation: Optimistically removes conversation from list
- Added optimistic update to reorder mutation:
- useReorderPlaylistTracks: Optimistically reorders tracks in playlist
- All mutations include:
- onMutate: Cancel queries, snapshot previous state, apply optimistic update
- onError: Rollback to previous state
- onSuccess: Invalidate queries for consistency
- Action 4.4.1.5 complete (18 mutations with optimistic updates)
- Created QueryClient singleton (queryClientSingleton.ts):
- Provides global access to QueryClient for state invalidation
- Set in main.tsx after QueryClient creation
- Updated invalidateQueries() to use QueryClient directly:
- Replaced custom event system with direct QueryClient.invalidateQueries()
- Added query key mapping for all resource types
- Event system kept as fallback if QueryClient not available
- Updated invalidateStore() for Library Store:
- Removed clearItems() call (method doesn't exist, domain data migrated to React Query)
- Library Store now only contains UI state (filters)
- React Query cache invalidation handles refetching
- Query keys mapped:
- tracks: ['tracks'], ['track'], ['library']
- playlists: ['playlists'], ['playlist']
- users: ['users'], ['user'], ['auth'], ['userProfile']
- conversations: ['conversations'], ['conversation'], ['chat'], ['chatConversations']
- roles: ['roles'], ['role']
- library: ['library'], ['tracks'], ['favorites'], ['libraryItems']
- auth: ['auth'], ['user']
- Action 4.6.1.5 complete
- Removed stateMiddleware utility (431 lines):
- Deleted apps/web/src/utils/stateMiddleware.ts
- Deleted apps/web/src/utils/stateMiddleware.test.ts (251 lines)
- Completely unused in production code (only used in test file)
- Previously removed from Library Store in Action 4.1.2.7
- Library Store now only contains UI state (filters), no middleware needed
- Created audit documentation: apps/web/src/docs/STATEMIDDLEWARE_UTILITY_AUDIT.md
- Action 4.6.1.4 complete
- Removed undoRedo utility (8587 bytes):
- Deleted apps/web/src/utils/undoRedo.ts
- Removed WithUndoRedo<T> type from stores/types.ts
- Removed WithUndoRedo export from stores/index.ts
- Completely unused (confirmed in Action 4.6.1.9 audit)
- Removed stateNormalization utility (6321 bytes):
- Deleted apps/web/src/utils/stateNormalization.ts
- Updated stores.test.ts to remove outdated tests:
- Removed createEmptyNormalized import
- Removed outdated Library Store tests (items/favorites)
- Updated Library Store tests to test current structure (filters only)
- Updated Chat Store tests to use feature store
- Updated Auth Store tests (user data migrated to React Query)
- Fixed beforeEach to not call non-existent methods
- Only used in outdated test file (confirmed in Action 4.6.1.11 audit)
- Both utilities made obsolete by React Query migration
- Actions 4.6.1.10 and 4.6.1.12 complete
- Audited undoRedo utility: completely unused (no imports found)
- Only type exports remain (WithUndoRedo) but also unused
- Previously removed from Library Store in Action 4.1.2.5
- Safe to remove (Action 4.6.1.10)
- Audited stateNormalization utility: only used in outdated test
- Only createEmptyNormalized used in stores.test.ts
- Tests check obsolete Library Store structure (items/favorites)
- Library Store migrated to React Query in Action 4.1.2.6
- Safe to remove after updating test file (Action 4.6.1.12)
- Created audit documentation:
- apps/web/src/docs/UNDOREDO_UTILITY_AUDIT.md
- apps/web/src/docs/STATENORMALIZATION_UTILITY_AUDIT.md
- Actions 4.6.1.9 and 4.6.1.11 complete
- Removed duplicate stores/chat.ts (old store)
- Consolidated to features/chat/store/chatStore.ts (active store)
- Updated ChatMessages.tsx to use feature store (currentConversationId + lookup)
- Updated storeSelectors.ts to use feature store and export only existing methods
- Updated stateHydration.ts to skip chat hydration (uses React Query)
- Updated stateInvalidation.ts to not call fetchConversations (React Query handles it)
- Updated stores/index.ts to export feature store
- Updated documentation
- Test files still reference old store (separate update needed)
- Action 4.5.1.5 complete
- Deleted apps/web/src/utils/optimisticStoreUpdates.ts (unused file)
- File was unused - no imports found in codebase
- Mutations already use React Query's onMutate pattern
- No TypeScript errors after deletion
- Actions 4.4.1.2 and 4.4.1.3 complete
- Added optional onStateSync callback to BroadcastSyncOptions
- Callback is called when state is updated locally or synced from another tab
- Callback receives new state and previous state as parameters
- Error handling prevents callback errors from breaking sync
- Stores can opt-in by providing callback that invalidates React Query queries
- No breaking changes - callback is optional
- Action 4.2.1.1 complete
- Removed _refreshUserPromise from AuthState interface
- Removed _refreshUserPromise from initial state
- Field no longer needed - React Query handles deduplication automatically
- No references to field remain in codebase
- Action 4.3.1.3 complete
- Removed manual promise deduplication logic (_refreshUserPromise usage)
- Removed promise creation and storage
- Simplified to direct async function that calls getMe()
- React Query's useUser hook handles deduplication automatically
- Preserved all error handling and state preservation logic
- Function simplified from 83 lines to 58 lines
- Action 4.3.1.2 complete
- Removed user field from AuthState interface
- Removed all user assignments in login, register, logout, refreshUser, checkAuthStatus
- Updated refreshUser to verify auth via getMe() but not store user (React Query handles that)
- Updated checkAuthStatus to verify auth via getMe() but not store user
- Updated persist partialize to not store user (only isAuthenticated)
- Updated broadcastSync shouldSync to only check isAuthenticated
- Removed User import
- Store now only manages isAuthenticated boolean
- User data exclusively managed by React Query (useUser hook)
- All production code already migrated (Actions 4.1.1.3-4.1.1.4 complete)
- Action 4.1.1.5 complete
- Tests already exist in response_test.go
- All tests passing (verified with go test)
- Tests cover all response helper functions
- Tests verify wrapped format for success and error responses
- Action 1.3.2.5 complete
- Created OfflineQueueManager component to display queued requests
- Shows request details: method, URL, timestamp, priority, retry count
- Allows removing individual requests
- Allows clearing entire queue
- Auto-updates queue every second while dialog is open
- Priority badges with color coding
- Empty state when no requests queued
- Uses Dialog component for modal display
- Action 2.5.1.4 complete
- Action 2.3.1.4 was already implemented in Action 2.3.1.1
- Message deduplication uses processedMessages Set to track message IDs
- Prevents duplicate cache updates from same message
- Includes cleanup of old processed message IDs
- Action 2.3.1.4 complete
- Added documentation explaining coexistence of Zustand and React Query sync
- Added type guards in broadcastSync.ts to verify message format before processing
- Added type guards in reactQuerySync.ts to verify message format before processing
- Both sync mechanisms use different channel names (no direct conflicts)
- Both sync mechanisms use different message formats (no cross-processing)
- Type guards ensure handlers only process their own message types
- Prevents accidental cross-processing of messages between sync mechanisms
- Both syncs can coexist safely without conflicts
- Action 2.3.1.3 complete
- Added useQueryClient hook to App component
- Added setupReactQuerySync import and initialization
- Initialize sync on App mount with cleanup on unmount
- React Query cache synchronization now active across browser tabs
- Multi-tab updates work when mutations succeed or queries are invalidated
- Action 2.3.1.2 complete
- Created reactQuerySync.ts with setupReactQuerySync() function
- Uses BroadcastChannel API to sync cache updates across browser tabs
- Subscribes to QueryClient mutation cache to broadcast mutation successes
- Subscribes to QueryClient query cache to broadcast query invalidations
- Implements message deduplication using message IDs and processed messages Set
- Implements tab ID tracking to avoid processing messages from same tab
- Handles three message types: query-invalidate, query-set-data, mutation-success
- Includes shouldSync filter function for selective synchronization
- Includes cleanup function to stop synchronization
- Focuses on invalidations and mutations (not every query update) for performance
- Comprehensive error handling and logging
- Action 2.3.1.1 complete - utility ready for integration
- Migrated useDashboard hook from useState/useEffect to React Query
- Added query key factory: dashboardQueryKeys for proper cache management
- Configured staleTime: 30 seconds (dashboard data changes frequently)
- Configured gcTime: 2 minutes (keeps data in cache)
- Added retry: 1 with retryDelay: 1000ms for automatic retry
- Preserved backward compatibility: same return interface
- Dashboard data now automatically cached and deduplicated
- Multiple components using useDashboard share cached data
- Automatic background refetching when data becomes stale
- Better performance and reduced API calls
- Action 2.1.1.7 complete - Sub-Epic 2.1.1 complete
- Removed getDashboardStats() function (old separate API call)
- Removed getRecentActivity() function (old separate API calls)
- Removed helper functions: mapActionToType, formatActivityTitle, formatActivityDescription
- Removed fallback to old methods in getDashboardData()
- Removed unused import of socialService
- All dashboard data now comes exclusively from aggregated /api/v1/dashboard endpoint
- No separate API calls remain in dashboard service
- Cleaner code, single source of truth for dashboard data
- Actions 2.1.1.5 and 2.1.1.6 complete - old API calls removed
- Updated getDashboardData() to call /api/v1/dashboard endpoint
- Added support for query parameters: activity_limit, library_limit, stats_period
- Added TrackPreview and LibraryPreview interfaces matching backend contract
- Updated DashboardData interface to include optional library_preview field
- Updated useDashboard hook to accept options and return libraryPreview
- Added fallback to old multiple-call method if new endpoint fails
- Dashboard now loads with single request instead of multiple parallel calls
- All existing functionality preserved, backward compatible during migration
- Action 2.1.1.3 complete - frontend ready to use aggregated endpoint
- Created DashboardHandler that aggregates multiple data sources
- Fetches stats, activity, and library preview in parallel
- Aggregates stats from audit logs (tracks_played, messages_sent, favorites, active_friends)
- Converts audit logs to RecentActivity format with type mapping
- Converts tracks to TrackPreview format for library preview
- Supports query parameters: activity_limit, library_limit, stats_period
- Returns wrapped format {success: true, data: DashboardResponse}
- Registered route: GET /api/v1/dashboard (protected, requires auth)
- Uses interface-based approach to avoid import cycle
- Router creates wrapper function to adapt track service
- Build successful, all handlers compile correctly
- Action 2.1.1.2 complete - dashboard endpoint ready for frontend integration
- Created comprehensive test suite for response format
- Test Success() returns wrapped format {success: true, data: {...}}
- Test Created() returns wrapped format
- Test Error() returns wrapped format for all status codes
- Test RespondWithAppError() returns wrapped format
- Test ValidationError() returns wrapped format with details
- Test all helper functions use wrapped format consistently
- All 7 test functions pass successfully (13+ test cases)
- Tests verify all response helpers return wrapped format
- Action 1.3.2.5 complete - backend response format verified
- Added comprehensive tests for wrapped format handling
- Test wrapped format with success: true and data unwrapping
- Test wrapped format with success: false and error handling
- Test wrapped format with null data
- Test safety check for non-wrapped responses (warning log)
- Test non-object response data handling
- Test verification that no direct format handling remains
- All 30 tests pass successfully
- Tests verify wrapped format only, no direct format handling
- Action 1.3.2.3 complete - response format consistency verified
- Removed direct format handling code (110+ lines)
- Removed validation and recovery logic for direct format responses
- Added safety check to log warning if non-wrapped response received
- Client now only handles wrapped format {success, data} or {success: false, error}
- Graceful degradation: non-wrapped responses still returned with warning
- TypeScript compilation successful, no linter errors
- Action 1.3.2.2 complete - frontend simplified to wrapped format only
- Updated system_metrics.go to use RespondSuccess() helper
- Updated bitrate_handler.go success responses to use wrapped format
- Updated frontend_log_handler.go to use RespondSuccess() helper
- Updated csrf.go to use RespondSuccess() and RespondWithError() helpers
- Updated audit.go: all 30+ error and success responses now use wrapped format helpers
- Updated comment_handler.go error responses to use RespondWithError()
- Updated system_metrics_test.go to expect wrapped format {success, data}
- All handlers now consistently use wrapped format helpers
- Build and tests pass successfully
- Action 1.3.2.1 complete - backend handlers standardized to wrapped format
- Added cache fallback: uses cached response for GET requests when validation fails
- Added optional retry mechanism (disabled by default, enabled via config)
- Added user notifications for recovery actions (configurable)
- Recovery config: { useCache, retry, notifyUser } on request config
- Prevents infinite retry loops with _validationRetryAttempted flag
- Validates cached responses before using them
- Handles both wrapped and direct format responses
- Graceful degradation: falls back to unvalidated data if recovery fails
- Applied to both validation sections (wrapped and direct formats)
- Action 1.2.2.5 complete - validation errors now handled gracefully
- Created ValidationAlerting class to monitor validation metrics
- Alerts when failure rate exceeds threshold (default 5%)
- Periodic checks every 5 minutes (configurable)
- Cooldown period (15 min) to prevent alert spam
- Minimum validations required (10) before alerting
- Structured alert logging with full metrics context
- Automatically starts in production (can be disabled via env var)
- Alerts sent to backend logging and Sentry
- Action 1.2.2.4 complete - validation alerting now active for monitoring
- Created ValidationMetricsTracker class to track validation metrics
- Tracks total, successful, and failed validations
- Calculates failure rate percentage
- Tracks failures by normalized endpoint patterns
- Records last failure and success timestamps
- Integrated into both validation points (wrapped and direct formats)
- Exported singleton for metrics access and monitoring
- Action 1.2.2.3 complete - validation metrics now tracked for monitoring
- Enhanced validation error logging with production monitoring context
- Added error_type field for easy filtering in monitoring systems
- Added timestamp and schema_provided flag for correlation
- Logs automatically sent to backend endpoint and Sentry in production
- Structured JSON format for easy aggregation and alerting
- Action 1.2.2.2 complete - validation failures now fully logged for production monitoring
- Enhanced response validation logging (wrapped and direct formats)
- Changed validation failures from warn to error level for better visibility
- Added structured error details (path, message, code, received, expected)
- Added response data preview for debugging
- Added success logging in debug mode
- Maintains graceful degradation (continues with unvalidated data) to avoid breaking app
- Action 1.2.2.1 complete - validation now comprehensive for all responses with schemas
- Action 1.1.3.10: Clarified that Track/User/ApiError are NOT obsolete
* ApiError already imported from schemas (not in api.ts)
* Track and User are necessary extended types with UI-specific fields
* Cannot be deleted without breaking functionality
- Action 1.1.3.11: Audited all type files for obsolete content
* No empty or redundant files found
* All type files serve a purpose (dto.ts, v2-v3-types.ts, backend-types.ts, api.ts)
* Future migration can replace DTOs with generated types (separate task)
- Both actions complete - no cleanup needed at this time
- Pre-commit hook already exists and is configured correctly
- Hook runs type generation script before each commit
- Renumbered duplicate Action 1.1.3.13 to 1.1.3.15 for clarity
- Action 1.1.3.15 complete - no changes needed
- Analyzed all extended types (User, Track) for duplicate properties
- No true duplicates found - all re-declarations serve a purpose:
* Type narrowing (making optional fields required)
* Type overrides (backward compatibility, type safety)
* UI-specific extensions (aliases, computed fields)
- Action 1.1.3.14 complete - no properties to remove
- Replace RefreshResponse with VezaBackendApiInternalDtoTokenResponse
- Replace ResendVerificationRequest with VezaBackendApiInternalDtoResendVerificationRequest
- Keep AuthResponse as is (uses extended User/AuthTokens)
- Keep form data types (frontend-specific)
- Tracks types already updated, roles/chat/settings kept as is
- Update User type in types/api.ts to extend VezaBackendApiInternalModelsUser
- Preserve UI-specific computed fields (avatar_url, stats, roles, status, etc.)
- Make required fields actually required (id, username, email, role, etc.)
- All existing imports continue to work via barrel exports
- No User-specific TypeScript errors introduced
- Update Track type in types/api.ts to extend VezaBackendApiInternalModelsTrack
- Update Track type in features/tracks/types/track.ts to extend generated type
- Preserve UI-specific computed fields (coverUrl, plays, likes, etc.)
- Support backward compatibility for duration (number|string)
- All existing imports continue to work without changes
- No Track-specific TypeScript errors introduced
- Replace manual ApiError interface with Zod-inferred type from apiSchemas
- Update all imports (15+ files) to use ApiError from @/schemas/apiSchemas
- Remove ApiError interface from types/api.ts
- Update ApiResponse to import ApiError from schemas
- All TypeScript checks pass for ApiError-related code
- Install husky as dev dependency
- Create pre-commit hook to run type generation script
- Ensures types are always up-to-date with backend API before commit
- Hook runs from apps/web directory to execute generate-types.sh
- Backend: Add X-API-Deprecated header alongside existing X-API-Version-Deprecated
- Frontend: Show deprecation warning toast when deprecated API version detected
- Warning shown only once per session to avoid spam
- Includes sunset date in warning message if available
- Migrated all hooks: useAuth, useChat, useLogin
- Migrated all components: Header, ProfileForm, FollowButton, LikeButton, PlaylistFollowButton, ChatMessage, ChatMessages, CommentThread, CommentSection, PlaylistList, ChatSidebar, SettingsPage, DashboardPage
- Updated storeSelectors.ts useAuthUser() to use React Query
- All production code now uses useUser() hook instead of Zustand store
- Action 4.1.1.3 and 4.1.1.4 complete
Actions 4.1.2.5, 4.1.2.6, and 4.1.2.7 were already completed in Action 4.1.2.4:
- undoRedo middleware removed (no domain data to track)
- stateNormalization utilities removed (React Query handles normalization)
- stateMiddleware wrapper removed (no domain data to track)
All middlewares were removed when domain data was removed from library store.
Actions 4.1.2.5, 4.1.2.6, 4.1.2.7 complete
- Remove items, favorites, pagination, isLoading, error from LibraryState
- Remove fetchItems, fetchFavorites, uploadFile, toggleFavorite, deleteItem, clearItems, setLoading, setError from LibraryActions
- Remove undoRedo and stateMiddleware wrappers (no domain data to track)
- Update useLibraryActions() to use React Query for all domain data actions
- Store now only contains filters (UI state)
- Update useLibraryItemsNormalized() and useLibraryFavoritesNormalized() to return empty state (deprecated)
- Update useLibraryPagination() to return both camelCase and snake_case for compatibility
Action 4.1.2.4 complete
All components using library store domain data have been migrated:
- DashboardPage components use selectors from storeSelectors.ts
- Selectors have been migrated to React Query hooks (Action 4.1.2.3.3)
- No direct access to store domain data found
- Components automatically migrated via selector abstraction layer
Action 4.1.2.8 complete
- Replace useLibraryItems() with React Query hook
- Replace useLibraryFavorites() with React Query hook
- Replace useLibraryPagination() to extract from React Query response
- Replace useLibraryStatus() to use React Query status
- Update useLibraryActions() to use queryClient.refetchQueries()
- Maintain same interface for backward compatibility
- Migrates DashboardPage components automatically
Action 4.1.2.3.3 complete
- Completed Action 2.2.1.1: Removed client-side filter logic from LibraryPage
- Removed unnecessary useMemo that was just passing through tracksData?.tracks
- Simplified to direct assignment: filteredTracks = tracksData?.tracks || []
- Backend handles all filtering (verified in Action 2.2.1.2)
- No actual filtering was happening - useMemo was just a pass-through
- Code simplified, behavior unchanged
- Completed Action 2.2.1.3: Handled LibraryPage.tsx vs LibraryPagePremium.tsx duplication
- Updated LIBRARY_PAGE_AUDIT.md with file comparison
- Verified LibraryPage.tsx is active (imported via LazyLibrary in routing)
- Verified LibraryPagePremium.tsx is duplicate/unused (not imported anywhere)
- LibraryPagePremium.tsx is older version without debounce improvements
- Removed LibraryPagePremium.tsx - safe deletion, no references found
- Routing continues to use LibraryPage.tsx, no breakage
- Completed Action 2.2.1.5: Removed LibraryPage.tsx.old
- File verified as safe to delete (no imports/references found in Action 2.2.1.4)
- Cleanup of obsolete backup file
- Active LibraryPage.tsx remains unchanged
- Completed Action 2.2.1.4: Verified LibraryPage.tsx.old has no imports
- Created LIBRARY_PAGE_AUDIT.md documenting file status
- Confirmed LibraryPage.tsx.old is safe to delete (no references)
- Identified LibraryPagePremium.tsx as duplicate/unused (needs Action 2.2.1.3)
- Active LibraryPage.tsx is imported via LazyComponent in routing
- Ready for Action 2.2.1.5: Remove LibraryPage.tsx.old
- Completed Action 1.2.1.5: Enhanced request validation logic
- Improved error messages with field paths and detailed validation errors
- Added structured logging for validation failures with request context
- Validation infrastructure was already in place, now ensures robust error handling
- All requests with _requestSchema are validated before sending
- FormData requests are skipped (validated separately)
- Type safety verified, no regressions
- Completed Action 1.3.2.4: Audited all response helper functions
- Created RESPONSE_HELPERS_AUDIT.md documenting all helpers
- Verified all helpers use wrapped format: Success(), Created(), Error(), RespondWithAppError(), RespondSuccess()
- Found two implementation approaches (gin.H vs APIResponse struct) - both produce wrapped format
- No changes needed - backend already compliant with wrapped format requirement
- Completed Action 1.3.1.2: Tested 36 endpoints for response format consistency
- Fixed test script to handle subshell issues with RESULTS array
- Created ENDPOINT_FORMAT_AUDIT.md documenting findings
- Found 2 endpoints using wrapped format, 0 direct format
- Most endpoints require auth (22) or have errors (12)
- Limited coverage due to authentication requirements and path parameters
