@reidbuilds/slop 0.2.0

package/hardcoresyn-slop.md

@@ -0,0 +1,1887 @@
+# Slop Report
+
+Generated: 2026-05-20
+
+## vite-env.d.ts
+
+✓ Clean
+
+## main.tsx
+
+✓ Clean
+
+## App.tsx
+
+✓ Clean
+
+## index.ts
+
+### [LOW] generic-variable-names — line 75
+
+**Code:** `odiserId: string;`
+
+**Issue:** The field name 'odiserId' appears to be a typo or generic placeholder - should likely be 'userId' based on context and other similar fields in the codebase
+
+**Fix:** Rename to 'userId: string;' to match the pattern used in other interfaces
+
+## populateSweatStarterTest.ts
+
+### [MEDIUM] console-log-left-in — line 11
+
+**Code:** `console.log('🔍 Finding "Sweat Starter Test 1" program...');
+console.log('✓ Found program:', (targetProgram as any).id);
+console.log('🔍 Fetching exercises from library...');
+console.log(`✓ Found ${exercises.length} exercises`);
+console.log(`✓ Created ${workouts.length} workouts`);
+console.log('✅ Successfully populated "Sweat Starter Test 1" program!');
+console.log(`   - ${totalWeeks} weeks`);
+console.log(`   - ${workoutsPerWeek} workouts per week`);
+console.log(`   - ${totalWorkouts} total workouts`);
+console.log(`   - 2 exercises per workout`);`
+
+**Issue:** Multiple console.log statements throughout the function that appear to be debug/status logging left in production code. While this is a script, these logs clutter output and suggest AI-generated debugging scaffolding.
+
+**Fix:** Replace with proper logging using a logger library, or remove if this is truly a one-time script. For scripts, consider using a --verbose flag to control output.
+
+### [LOW] generic-variable-names — line 23
+
+**Code:** `programsSnapshot.docs.forEach(doc => {
+      const data = doc.data() as any;
+      if (data.name === 'Sweat Starter Test 1') {`
+
+**Issue:** Generic variable name 'data' used for what is specifically workout program data. This makes the code less readable and is a common AI pattern.
+
+**Fix:** const programData = doc.data() as WorkoutProgram;
+
+## videoThumbnail.ts
+
+### [LOW] generic-variable-names — line 11
+
+**Code:** `const maxW = options?.maxWidth ?? 1280;`
+
+**Issue:** Variable abbreviated to 'maxW' instead of a clear descriptive name in non-trivial video processing context
+
+**Fix:** const maxWidth = options?.maxWidth ?? 1280;
+
+### [LOW] generic-variable-names — line 34
+
+**Code:** `const dur = video.duration;`
+
+**Issue:** Variable abbreviated to 'dur' instead of clear 'duration' in complex video timing logic
+
+**Fix:** const duration = video.duration;
+
+### [LOW] generic-variable-names — line 55
+
+**Code:** `const vw = video.videoWidth;
+    const vh = video.videoHeight;`
+
+**Issue:** Variables abbreviated to 'vw' and 'vh' instead of descriptive names in dimension calculation logic
+
+**Fix:** const videoWidth = video.videoWidth;
+    const videoHeight = video.videoHeight;
+
+### [LOW] generic-variable-names — line 61
+
+**Code:** `let dw = vw;
+    let dh = vh;`
+
+**Issue:** Variables abbreviated to 'dw' and 'dh' instead of descriptive names like 'displayWidth' and 'displayHeight'
+
+**Fix:** let displayWidth = videoWidth;
+    let displayHeight = videoHeight;
+
+## stripe.ts
+
+### [HIGH] hardcoded-config — line 7
+
+**Code:** `const fallbackKey = 'pk_test_51SrKL12EWDoWzTlbooO1c6Y3k1oMpjc2JAk266LPVK6TGgRPthyf4eeGjhFh6lDGeZEz3YxDxDUhQ4wBcnemfU1v00BKalQrEu';`
+
+**Issue:** Stripe publishable key hardcoded directly in source code. Even though publishable keys are less sensitive than secret keys, they should still be externalized to avoid version control coupling and environment management issues.
+
+**Fix:** Remove hardcoded fallback and require the environment variable: `const STRIPE_PUBLISHABLE_KEY = import.meta.env.VITE_STRIPE_PUBLISHABLE_KEY?.trim();` with proper validation that throws if missing.
+
+### [MEDIUM] console-log-left-in — line 21
+
+**Code:** `console.log('🔑 Loading Stripe with key:', STRIPE_PUBLISHABLE_KEY.substring(0, 20) + '...');
+    console.log('🔑 Key length:', STRIPE_PUBLISHABLE_KEY.length);
+    console.log('🔑 Key starts with pk_test_:', STRIPE_PUBLISHABLE_KEY.startsWith('pk_test_'));
+    console.log('🔑 Full key (for debugging):', STRIPE_PUBLISHABLE_KEY);`
+
+**Issue:** Debug console.log statements left in production code, including one that logs the full Stripe key. While publishable keys are less sensitive, this creates log noise and reveals implementation details in production.
+
+**Fix:** Remove debug console.log statements or replace with proper logging: `logger.debug('Initializing Stripe', { keyType: STRIPE_PUBLISHABLE_KEY.startsWith('pk_test_') ? 'test' : 'live' })`
+
+### [HIGH] hardcoded-config — line 45
+
+**Code:** `'sweat-starter': import.meta.env.VITE_STRIPE_PRICE_SWEAT_STARTER || 'price_1SuKsG2EWDoWzTlbwUA9bdpb',`
+
+**Issue:** Stripe price ID hardcoded as fallback value. Price IDs are environment-specific configuration that should not be embedded in source code.
+
+**Fix:** Remove hardcoded fallback: `'sweat-starter': import.meta.env.VITE_STRIPE_PRICE_SWEAT_STARTER,` and validate that required price IDs are configured at startup.
+
+## nutritionUtils.ts
+
+### [MEDIUM] unnecessary-abstraction — line 17
+
+**Code:** `export function macroDelta(consumed: number, target: number): {
+  pct: number;
+  over: boolean;
+  under: boolean;
+  diff: number;
+  label: string;
+} {
+  if (target <= 0) {
+    return { pct: 0, over: false, under: false, diff: 0, label: '' };
+  }
+  const pct = Math.round((consumed / target) * 100);
+  const diff = consumed - target;
+  const over = diff > 0;
+  const under = diff < 0;
+  const abs = Math.abs(diff);
+  let label = 'On target';
+  if (over) label = `+${abs} over`;
+  else if (under) label = `${abs} under`;
+  return { pct, over, under, diff, label };
+}
+
+export function macroDeltaGrams(consumed: number, target: number): {
+  pct: number;
+  over: boolean;
+  under: boolean;
+  diff: number;
+  label: string;
+} {
+  if (target <= 0) {
+    return { pct: 0, over: false, under: false, diff: 0, label: '' };
+  }
+  const pct = Math.round((consumed / target) * 100);
+  const diff = Math.round((consumed - target) * 10) / 10;
+  const over = diff > 0;
+  const under = diff < 0;
+  const abs = Math.abs(diff);
+  let label = 'On target';
+  if (over) label = `+${abs}g over`;
+  else if (under) label = `${abs}g under`;
+  return { pct, over, under, diff, label };
+}`
+
+**Issue:** Two nearly identical functions with the same signature and return type, differing only in decimal rounding and adding 'g' to the label. The abstraction creates unnecessary code duplication instead of parameterizing the difference.
+
+**Fix:** Combine into a single function with an optional unit parameter: function macroDelta(consumed: number, target: number, unit?: string, precision = 0) and handle rounding/labeling based on the unit parameter.
+
+## firebase.ts
+
+### [HIGH] hardcoded-config — line 6
+
+**Code:** `  apiKey: import.meta.env.VITE_FIREBASE_API_KEY || 'AIzaSyB0uWItoUyaozcnjntgG9kck6GJx84GQNY',
+  authDomain: import.meta.env.VITE_FIREBASE_AUTH_DOMAIN || 'hardcore-synergy.firebaseapp.com',
+  projectId: import.meta.env.VITE_FIREBASE_PROJECT_ID || 'hardcore-synergy',
+  storageBucket: import.meta.env.VITE_FIREBASE_STORAGE_BUCKET || 'hardcore-synergy.firebasestorage.app',
+  messagingSenderId: import.meta.env.VITE_FIREBASE_MESSAGING_SENDER_ID || '277466650255',
+  appId: import.meta.env.VITE_FIREBASE_APP_ID || '1:277466650255:web:59e0aeeb3f36c9fde002fa',
+  measurementId: import.meta.env.VITE_FIREBASE_MEASUREMENT_ID || 'G-NZ20RHHZR9',`
+
+**Issue:** Real Firebase API keys and configuration values are hardcoded as fallbacks. This exposes production credentials in source code which will leak via git history and any public repositories.
+
+**Fix:** Remove hardcoded fallbacks and fail explicitly when environment variables are missing: apiKey: import.meta.env.VITE_FIREBASE_API_KEY || (() => { throw new Error('VITE_FIREBASE_API_KEY is required') })()
+
+### [MEDIUM] console-log-left-in — line 15
+
+**Code:** `console.log('🔥 Firebase Config Debug:');
+console.log('  - API Key:', firebaseConfig.apiKey ? '✓ Set' : '✗ MISSING');
+console.log('  - Auth Domain:', firebaseConfig.authDomain);
+console.log('  - Project ID:', firebaseConfig.projectId);
+console.log('  - Storage Bucket:', firebaseConfig.storageBucket);
+console.log('  - Messaging Sender ID:', firebaseConfig.messagingSenderId ? '✓ Set' : '✗ MISSING');
+console.log('  - App ID:', firebaseConfig.appId ? '✓ Set' : '✗ MISSING');`
+
+**Issue:** Debug console.log statements left in production code. These will clutter production logs and potentially expose configuration details in browser console or server logs.
+
+**Fix:** Replace with proper logging that can be filtered in production: import { logger } from './logger'; logger.debug('Firebase config status', { hasApiKey: !!firebaseConfig.apiKey, projectId: firebaseConfig.projectId })
+
+### [MEDIUM] console-log-left-in — line 29
+
+**Code:** `console.log('✓ Firebase app initialized:', app.name);`
+
+**Issue:** Production console.log statement logging Firebase app initialization details.
+
+**Fix:** Remove or replace with proper logging: logger.info('Firebase app initialized')
+
+### [MEDIUM] console-log-left-in — line 41
+
+**Code:** `console.log('✓ Firebase services initialized (auth, db, storage)');`
+
+**Issue:** Production console.log statement logging service initialization details.
+
+**Fix:** Remove or replace with proper logging: logger.info('Firebase services initialized')
+
+## coerceFirestoreDate.ts
+
+✓ Clean
+
+## api.ts
+
+### [MEDIUM] console-log-left-in — line 32
+
+**Code:** `console.error('Failed to get auth token:', error);`
+
+**Issue:** Console.error statement left in production code that logs authentication errors, potentially exposing sensitive information about auth failures
+
+**Fix:** Replace with proper logging: logger.error('Failed to get auth token', { error: error.message })
+
+### [MEDIUM] console-log-left-in — line 61
+
+**Code:** `console.warn(`API endpoint ${endpoint} returned non-JSON response (${contentType}). This endpoint may not exist.`);`
+
+**Issue:** Console.warn statement left in production code that logs API endpoint information and content types, creating noise in production logs
+
+**Fix:** Replace with proper logging: logger.warn('API endpoint returned non-JSON response', { endpoint, contentType })
+
+### [MEDIUM] console-log-left-in — line 79
+
+**Code:** `console.error(`API call to ${endpoint} failed:`, error);`
+
+**Issue:** Console.error statement left in production code that logs API call failures with potentially sensitive endpoint information
+
+**Fix:** Replace with proper logging: logger.error('API call failed', { endpoint, error: error.message })
+
+### [MEDIUM] try-catch-everything — line 45
+
+**Code:** `try {
+    // Get auth token for authenticated requests
+    const token = await getAuthToken();
+    // ... entire apiCall function body
+  } catch (error) {
+    console.error(`API call to ${endpoint} failed:`, error);
+    return {
+      success: false,
+      error: error instanceof Error ? error.message : 'An error occurred',
+    };
+  }`
+
+**Issue:** Blanket try-catch around entire function body with generic error handling, masking different types of errors (network, auth, parsing) that might need distinct handling
+
+**Fix:** Handle specific error types separately - auth failures, network errors, and JSON parsing errors should be handled with different logic rather than generic catch-all
+
+## useWorkouts.ts
+
+### [MEDIUM] try-catch-everything — line 16
+
+**Code:** `try {
+        const response = await getWorkoutPrograms();
+        if (response.success && response.data) {
+          setPrograms(response.data.programs);
+        } else {
+          setError(response.error || 'Failed to fetch programs');
+        }
+      } catch (err) {
+        setError(err instanceof Error ? err.message : 'Failed to fetch programs');
+      }`
+
+**Issue:** Generic try/catch with same error handling for both API response errors and network/runtime errors. Both paths set the same generic error message.
+
+**Fix:** Handle API response errors separately from network errors, and let authentication/authorization errors propagate to be handled at a higher level
+
+### [MEDIUM] try-catch-everything — line 43
+
+**Code:** `try {
+      const response = await getClientWorkouts(currentUser.uid, completed);
+      if (response.success && response.data) {
+        setWorkouts(response.data.workouts);
+      } else {
+        setError(response.error || 'Failed to fetch workouts');
+      }
+    } catch (err) {
+      setError(err instanceof Error ? err.message : 'Failed to fetch workouts');
+    }`
+
+**Issue:** Same pattern repeated - generic try/catch that treats all errors the same way with identical error messages for different failure modes.
+
+**Fix:** Differentiate between network errors, authentication errors, and API response errors with specific handling for each
+
+### [MEDIUM] try-catch-everything — line 74
+
+**Code:** `try {
+      const response = await assignWorkoutProgram(currentUser.uid, programId);
+      if (response.success) {
+        return { success: true, assignmentId: response.data?.assignmentId };
+      } else {
+        setError(response.error || 'Failed to assign program');
+        return { success: false };
+      }
+    } catch (err) {
+      setError(err instanceof Error ? err.message : 'Failed to assign program');
+      return { success: false };
+    }`
+
+**Issue:** Third instance of the same generic error handling pattern - no differentiation between error types that might need different user-facing messages or recovery strategies.
+
+**Fix:** Handle specific error cases like network failures, permission errors, and invalid program IDs with appropriate user feedback
+
+### [MEDIUM] try-catch-everything — line 99
+
+**Code:** `try {
+      const response = await logWorkout(workoutId, log);
+      if (response.success) {
+        return { success: true, logId: response.data?.logId };
+      } else {
+        setError(response.error || 'Failed to log workout');
+        return { success: false };
+      }
+    } catch (err) {
+      setError(err instanceof Error ? err.message : 'Failed to log workout');
+      return { success: false };
+    }`
+
+**Issue:** Fourth repetition of identical error handling pattern. All four hooks use the exact same try/catch structure with generic fallback messages.
+
+**Fix:** Create a shared error handling utility that can distinguish between different error types and provide appropriate responses
+
+## useSweatStarterWorkouts.ts
+
+### [MEDIUM] console-log-left-in — line 69
+
+**Code:** `console.error('Failed to listen to program:', error);`
+
+**Issue:** Debug console error statements left in production code that will clutter production logs with Firebase listener errors
+
+**Fix:** Replace with proper error logging using a logger service or remove if error handling is done elsewhere
+
+### [MEDIUM] console-log-left-in — line 80
+
+**Code:** `console.error('Failed to listen to assignments:', error);`
+
+**Issue:** Debug console error statements left in production code that will clutter production logs with Firebase listener errors
+
+**Fix:** Replace with proper error logging using a logger service or remove if error handling is done elsewhere
+
+### [MEDIUM] console-log-left-in — line 118
+
+**Code:** `console.error('Failed to listen to progress:', error);`
+
+**Issue:** Debug console error statements left in production code that will clutter production logs with Firebase listener errors
+
+**Fix:** Replace with proper error logging using a logger service or remove if error handling is done elsewhere
+
+## useProgress.ts
+
+### [HIGH] async-misuse — line 67
+
+**Code:** `const stats = {
+    currentWeight: latestEntry?.weight,
+    startingWeight: firstEntry?.weight,
+    weightChange: latestEntry && previousEntry
+      ? latestEntry.weight! - previousEntry.weight!
+      : 0,
+    totalChange: latestEntry && firstEntry
+      ? latestEntry.weight! - firstEntry.weight!
+      : 0,
+    entriesCount: entries.length,
+    averageEnergy: entries.length > 0
+      ? entries.reduce((sum, e) => sum + (e.energyLevel || 0), 0) / entries.length
+      : 0,
+  };`
+
+**Issue:** The code uses non-null assertion operator (!) on optional weight properties without checking if they exist, which could cause runtime errors if weight is undefined
+
+**Fix:** Replace with proper null checking: latestEntry.weight - previousEntry.weight instead of latestEntry.weight! - previousEntry.weight!, or add explicit undefined checks
+
+## useMealPlans.ts
+
+✓ Clean
+
+## ThemeContext.tsx
+
+✓ Clean
+
+## DemoDataContext.tsx
+
+### [LOW] generic-variable-names — line 102
+
+**Code:** `const demoExercises: WorkoutExercise[] = [`
+
+**Issue:** Variable name 'demoExercises' uses generic 'demo' prefix when it specifically contains lower body exercises based on the content (hip thrust, deadlift, squats). This makes it unclear when 'upperExercises' is defined later.
+
+**Fix:** Rename to 'lowerBodyExercises' or 'gluteExercises' to reflect the actual exercise types
+
+### [MEDIUM] over-engineered-simple — line 75
+
+**Code:** `interface DemoDataContextType {
+  demoClient: DemoClientData;
+  updateDemoClient: (updates: Partial<DemoClientData>) => void;
+  assignWorkout: (workout: Workout, scheduledDate: Date) => void;
+  assignMealPlan: (mealPlan: MealPlan) => void;
+  completeWorkout: (workoutId: string, duration: number) => void;
+  logProgress: (entry: Omit<ProgressEntry, 'id' | 'clientId' | 'date'>) => void;
+  resetDemoData: () => void;
+}`
+
+**Issue:** Complex context interface with multiple specialized methods for what appears to be demo/mock data. This creates unnecessary abstraction layers for demonstration purposes when simpler mock data objects would suffice.
+
+**Fix:** Consider using plain mock data objects instead of a full context provider for demo scenarios, or simplify to a single 'updateDemoData' method
+
+## AuthContext.tsx
+
+### [MEDIUM] console-log-left-in — line 24
+
+**Code:** `console.log('🔄 Initializing Firebase...');
+  // ...
+  console.log('✓ Firebase initialized successfully');
+  console.log('  - Auth:', auth ? '✓' : '✗');
+  console.log('  - Firestore:', db ? '✓' : '✗');
+  console.log('  - Google Provider:', googleProvider ? '✓' : '✗');`
+
+**Issue:** Multiple console.log statements left in production code that will clutter production logs with implementation details about Firebase initialization status
+
+**Fix:** Replace with proper logging using a logger library that can be filtered in production, or remove entirely if not needed for production debugging
+
+### [MEDIUM] console-log-left-in — line 31
+
+**Code:** `console.error('❌ Firebase initialization failed:', firebaseError);
+  console.error('  Full error:', e);
+  console.warn('  Running in demo mode. To fix:');
+  console.warn('  1. Create .env file in project root');
+  console.warn('  2. Add VITE_FIREBASE_API_KEY=your-api-key');
+  console.warn('  3. Restart the dev server');`
+
+**Issue:** Console statements providing setup instructions that should not appear in production logs, revealing internal configuration details
+
+**Fix:** Move setup instructions to documentation and use proper error logging that can be configured per environment
+
+### [MEDIUM] console-log-left-in — line 139
+
+**Code:** `console.log('  📄 Fetching profile for:', userId);`
+
+**Issue:** Debug console.log statement logging user IDs in production, which could expose sensitive user data in logs
+
+**Fix:** Remove or replace with proper debug logging that filters out sensitive data in production
+
+### [MEDIUM] console-log-left-in — line 141
+
+**Code:** `console.warn('  ⚠️ Firestore not available');`
+
+**Issue:** Console warning left in production code that reveals internal state about database availability
+
+**Fix:** Use proper error logging or remove if this is expected behavior in demo mode
+
+### [MEDIUM] console-log-left-in — line 161
+
+**Code:** `console.log('  👑 Admin email detected, setting role to admin');`
+
+**Issue:** Console.log revealing role assignment logic and potentially sensitive email information in production logs
+
+**Fix:** Remove or replace with secure audit logging that doesn't expose role assignment logic in client-side logs
+
+## Skeleton.tsx
+
+✓ Clean
+
+## ProtectedRoute.tsx
+
+### [HIGH] hardcoded-config — line 57
+
+**Code:** `const coachedTiers = ['body-blueprint', 'peach-elite'];`
+
+**Issue:** Business tier configuration is hardcoded in component logic. Adding new tiers or changing tier names requires code changes rather than config updates.
+
+**Fix:** Move tier configuration to environment variables or config file: const coachedTiers = process.env.COACHED_TIERS?.split(',') || ['body-blueprint', 'peach-elite'];
+
+## ProgressBar.tsx
+
+✓ Clean
+
+## PaymentForm.tsx
+
+### [HIGH] hardcoded-config — line 55
+
+**Code:** `const FUNCTION_URL = 'https://us-central1-hardcore-synergy.cloudfunctions.net/createSubscription';`
+
+**Issue:** Cloud function URL is hardcoded with a specific project ID and deployment region, making this code environment-specific and impossible to deploy to staging/dev without code changes
+
+**Fix:** const FUNCTION_URL = process.env.REACT_APP_FUNCTION_URL || process.env.NEXT_PUBLIC_FUNCTION_URL;
+
+### [MEDIUM] try-catch-everything — line 29
+
+**Code:** `try {
+      const card = elements.getElement(CardElement);
+      // ... entire payment flow ...
+    } catch (err) {
+      const message = err instanceof Error ? err.message : 'An error occurred';
+      setError(message);
+      onError(message);
+    }`
+
+**Issue:** Single try-catch wraps the entire payment flow including authentication, payment method creation, backend API call, and payment confirmation. Different error types need distinct handling - auth errors, network errors, and payment failures should be handled differently
+
+**Fix:** Handle auth errors separately before try block, catch API errors distinctly from Stripe errors, and let critical errors propagate with specific error types
+
+## PageHeader.tsx
+
+✓ Clean
+
+## NutritionChatWidget.tsx
+
+### [MEDIUM] console-log-left-in — line 74
+
+**Code:** `console.log('estimateMacrosClientSide called with:', description, '-> lowercase:', lowerDesc);`
+
+**Issue:** Debug console.log statement left in production code that logs internal state and function parameters
+
+**Fix:** Remove the console.log statement or replace with proper logging: logger.debug('Estimating macros', { description })
+
+### [MEDIUM] console-log-left-in — line 62
+
+**Code:** `console.error('Failed to load chat history:', error);`
+
+**Issue:** Console.error statement in production code - should use proper error logging
+
+**Fix:** Replace with structured logging: logger.error('Failed to load chat history', { error, userId: currentUser?.uid })
+
+## LoadingSpinner.tsx
+
+✓ Clean
+
+## Layout.tsx
+
+✓ Clean
+
+## Input.tsx
+
+✓ Clean
+
+## ExercisePicker.tsx
+
+### [MEDIUM] console-log-left-in — line 50
+
+**Code:** `console.error('Failed to fetch exercises:', error);`
+
+**Issue:** Debug console.error statement left in production code that will log full error objects to browser console, potentially exposing internal Firebase configuration or sensitive error details
+
+**Fix:** Replace with proper error logging: import a logger and use logger.error('Failed to fetch exercises', { message: error.message }) or remove entirely if error handling is sufficient
+
+## ExerciseCardMedia.tsx
+
+✓ Clean
+
+## EmptyState.tsx
+
+✓ Clean
+
+## Card.tsx
+
+✓ Clean
+
+## Button.tsx
+
+### [HIGH] hallucinated-imports — line 2
+
+**Code:** `import LoadingSpinner from './LoadingSpinner';`
+
+**Issue:** Imports a component './LoadingSpinner' that is used in the code but may not exist. This is a common AI pattern of importing plausible-sounding components without verifying they exist in the project structure.
+
+**Fix:** Verify that './LoadingSpinner' component exists, or replace with an actual loading spinner implementation or a verified component library import like 'import { Spinner } from '@/components/ui/spinner'
+
+## BottomNav.tsx
+
+✓ Clean
+
+## Badge.tsx
+
+✓ Clean
+
+## WorkoutHistory.tsx
+
+### [MEDIUM] console-log-left-in — line 45
+
+**Code:** `console.error('Failed to fetch workout history:', error);`
+
+**Issue:** Debug console.error statement left in production code that will clutter production logs and potentially leak internal error details
+
+**Fix:** Replace with proper logging: logger.error('Failed to fetch workout history', { userId: currentUser.uid, error: error.message })
+
+## WorkoutDetail.tsx
+
+### [MEDIUM] console-log-left-in — line 119
+
+**Code:** `console.error('Failed to fetch sweat starter workout:', error);`
+
+**Issue:** Debug console statement left in production code that will clutter production logs and potentially leak implementation details about sweat starter workout fetching
+
+**Fix:** Replace with proper logging: logger.error('Failed to fetch sweat starter workout', { error: error.message })
+
+### [MEDIUM] console-log-left-in — line 133
+
+**Code:** `console.error('Failed to fetch workout:', error);`
+
+**Issue:** Debug console statement left in production code that will clutter production logs and potentially leak implementation details about workout fetching
+
+**Fix:** Replace with proper logging: logger.error('Failed to fetch workout', { error: error.message })
+
+## WorkoutBrowser.tsx
+
+### [MEDIUM] console-log-left-in — line 87
+
+**Code:** `console.error('Failed to fetch workouts:', error);`
+
+**Issue:** Debug console statement left in production code that will clutter production logs and potentially expose internal error details
+
+**Fix:** Replace with proper logging: logger.error('Failed to fetch workouts', { error: error.message, userId: currentUser.uid })
+
+## TrainerWorkoutTemplates.tsx
+
+### [HIGH] stub-with-shell — line 69
+
+**Code:** `const fetchTemplates = async () => {
+      setLoading(true);
+      await new Promise((r) => setTimeout(r, 500));
+      setTemplates(mockTemplates);
+      setLoading(false);
+    };`
+
+**Issue:** Function simulates async data fetching with a hardcoded delay and mock data, but the rest of the component treats it as if it's making real API calls. This will break when integrated with a real backend.
+
+**Fix:** Replace with actual API call or make the mock nature explicit: // TODO: Replace with actual API call - see issue #XX
+
+## TrainerWorkoutTemplateNew.tsx
+
+### [MEDIUM] over-engineered-simple — line 57
+
+**Code:** `const mockTemplateData: Record<string, {
+  title: string;
+  description: string;
+  category: string;
+  focusAreas: string[];
+  difficulty: string;
+  duration: number;
+  equipment: string[];
+  warmUps: WarmUpItem[];
+  exercises: ExerciseItem[];
+  finishers: FinisherItem[];
+}> = {`
+
+**Issue:** Complex Record type definition for what is essentially a simple lookup object with 2 items. The verbose type annotation provides no value since TypeScript can infer the structure from the object literal.
+
+**Fix:** const mockTemplateData = { '1': { title: 'Upper Body Strength', ... }, '2': { title: 'Lower Body Power', ... } } or extract to a separate constants file if it grows
+
+### [HIGH] hardcoded-config — line 123
+
+**Code:** `const [duration, setDuration] = useState(35);`
+
+**Issue:** Default workout duration of 35 minutes is hardcoded. This configuration value should be externalized to allow different defaults per user type or configurable by admins.
+
+**Fix:** const [duration, setDuration] = useState(config.DEFAULT_WORKOUT_DURATION || 35);
+
+## TrainerWorkoutPrograms.tsx
+
+### [MEDIUM] console-log-left-in — line 37
+
+**Code:** `console.error('Failed to fetch programs:', error);`
+
+**Issue:** Console.error statement left in production code that will clutter production logs and potentially leak implementation details
+
+**Fix:** Replace with proper logging: logger.error('Failed to fetch programs', { error }) or remove entirely
+
+### [MEDIUM] console-log-left-in — line 67
+
+**Code:** `console.error('Failed to delete program:', error);`
+
+**Issue:** Console.error statement left in production code that will clutter production logs and potentially leak implementation details
+
+**Fix:** Replace with proper logging: logger.error('Failed to delete program', { error }) or remove entirely
+
+## TrainerWorkoutProgramNew.tsx
+
+### [LOW] generic-variable-names — line 122
+
+**Code:** `for (let i = weeks.length; i < newDuration; i++) {`
+
+**Issue:** Generic loop variable 'i' used in context where 'weekIndex' would be more descriptive
+
+**Fix:** for (let weekIndex = weeks.length; weekIndex < newDuration; weekIndex++) {
+
+### [LOW] generic-variable-names — line 137
+
+**Code:** `for (let i = 0; i < newWeeks.length; i++) {`
+
+**Issue:** Generic loop variable 'i' used in context where 'weekIndex' would be more descriptive
+
+**Fix:** for (let weekIndex = 0; weekIndex < newWeeks.length; weekIndex++) {
+
+### [LOW] generic-variable-names — line 138
+
+**Code:** `if (i !== fromWeek) {`
+
+**Issue:** Generic variable 'i' used where 'weekIndex' would be clearer
+
+**Fix:** if (weekIndex !== fromWeek) {
+
+### [LOW] generic-variable-names — line 139
+
+**Code:** `newWeeks[i] = newWeeks[fromWeek].map(day => ({ ...day }));`
+
+**Issue:** Generic variable 'i' used where 'weekIndex' would be clearer
+
+**Fix:** newWeeks[weekIndex] = newWeeks[fromWeek].map(day => ({ ...day }));
+
+### [LOW] generic-variable-names — line 213
+
+**Code:** `exercises: currentWorkout.exercises.filter((_, i) => i !== index),`
+
+**Issue:** Generic parameter 'i' in filter callback where 'exerciseIndex' would be more descriptive
+
+**Fix:** exercises: currentWorkout.exercises.filter((_, exerciseIndex) => exerciseIndex !== index),
+
+## TrainerWorkoutProgramDetail.tsx
+
+### [HIGH] hardcoded-config — line 33
+
+**Code:** `const mockPrograms: Record<string, WorkoutProgram & { weeks: { day: number; workout: DetailedWorkout | null }[][] }> = {
+  '4': {
+    id: '4',
+    name: 'Basic Muscle-Building (At Home)',
+    description: 'Build lean muscle and strength...',
+    // ... entire hardcoded workout program structure`
+
+**Issue:** Large hardcoded workout program data structure embedded directly in component code with specific exercise names, reps, durations, and program details that should be externalized
+
+**Fix:** Move workout program data to a separate data file, configuration, or fetch from an API/database: import { workoutPrograms } from '../data/workoutPrograms' or fetch from Firebase
+
+### [LOW] generic-variable-names — line 33
+
+**Code:** `const mockPrograms: Record<string, WorkoutProgram & { weeks: { day: number; workout: DetailedWorkout | null }[][] }>`
+
+**Issue:** Variable named 'mockPrograms' uses generic 'mock' prefix when it contains specific workout program data that could have a more descriptive domain name
+
+**Fix:** Rename to something more specific like 'workoutProgramTemplates' or 'prebuiltPrograms' to indicate what type of programs these are
+
+## TrainerProfile.tsx
+
+### [HIGH] hardcoded-config — line 12
+
+**Code:** `const [phone, setPhone] = useState('555-0123');`
+
+**Issue:** Hardcoded phone number '555-0123' is a placeholder value that should come from user profile data or be empty initially
+
+**Fix:** const [phone, setPhone] = useState(userProfile?.phone || '');
+
+### [HIGH] hardcoded-config — line 11
+
+**Code:** `const [bio, setBio] = useState('Certified personal trainer with 5+ years of experience specializing in body recomposition and strength training.');`
+
+**Issue:** Hardcoded bio text as default value should come from user profile data or be empty for user input
+
+**Fix:** const [bio, setBio] = useState(userProfile?.bio || '');
+
+### [HIGH] stub-with-shell — line 33
+
+**Code:** `const handleSave = async () => {
+    setSaving(true);
+    await new Promise((r) => setTimeout(r, 1000));
+    // TODO: API call to save profile
+    setSaving(false);
+  };`
+
+**Issue:** Function has complete error handling structure but core business logic (saving profile) is a TODO stub with fake delay
+
+**Fix:** Either implement the actual save API call or throw an error indicating it's not implemented yet
+
+## TrainerMessages.tsx
+
+### [LOW] generic-variable-names — line 115
+
+**Code:** `await new Promise((r) => setTimeout(r, 500));`
+
+**Issue:** Promise resolver callback parameter is named 'r' instead of a descriptive name like 'resolve'
+
+**Fix:** await new Promise((resolve) => setTimeout(resolve, 500));
+
+### [LOW] generic-variable-names — line 152
+
+**Code:** `const filteredConversations = conversations.filter((c) =>
+    c.clientName.toLowerCase().includes(searchQuery.toLowerCase())
+  );`
+
+**Issue:** Loop variable named 'c' when iterating over conversations - should be more descriptive
+
+**Fix:** const filteredConversations = conversations.filter((conversation) =>
+    conversation.clientName.toLowerCase().includes(searchQuery.toLowerCase())
+  );
+
+### [LOW] generic-variable-names — line 156
+
+**Code:** `const selectedClient = conversations.find((c) => c.id === selectedConversation);`
+
+**Issue:** Loop variable named 'c' when iterating over conversations - should be more descriptive
+
+**Fix:** const selectedClient = conversations.find((conversation) => conversation.id === selectedConversation);
+
+## TrainerMealTemplates.tsx
+
+### [LOW] generic-variable-names — line 28
+
+**Code:** `const filteredPlans = mealPlans.filter((p) =>`
+
+**Issue:** Loop variable 'p' is generic when iterating over a typed collection of meal plans. 'plan' would be more descriptive.
+
+**Fix:** const filteredPlans = mealPlans.filter((plan) => plan.name.toLowerCase().includes(searchQuery.toLowerCase()) || plan.description.toLowerCase().includes(searchQuery.toLowerCase()));
+
+### [LOW] generic-variable-names — line 18
+
+**Code:** `const res = await getMealPlanTemplates();`
+
+**Issue:** Variable 'res' is a generic name for what is specifically a meal plan templates API response.
+
+**Fix:** const templatesResponse = await getMealPlanTemplates();
+
+## TrainerMealPlanNew.tsx
+
+### [HIGH] hardcoded-config — line 11
+
+**Code:** `targetCalories: '2000',
+    targetProtein: '150',
+    targetCarbs: '200',
+    targetFat: '65',`
+
+**Issue:** Default macro values are hardcoded in the component state. These nutritional targets should come from configuration or business logic rather than being embedded in the UI component.
+
+**Fix:** Move default values to a config file or environment variables: const DEFAULT_MACROS = { calories: process.env.DEFAULT_CALORIES || 2000, ... }
+
+### [HIGH] hardcoded-config — line 28
+
+**Code:** `targetCalories: Number(form.targetCalories) || 2000,
+      targetProtein: Number(form.targetProtein) || 150,
+      targetCarbs: Number(form.targetCarbs) || 200,
+      targetFat: Number(form.targetFat) || 65,`
+
+**Issue:** Fallback macro values are duplicated and hardcoded in the submission logic. These magic numbers should be constants or come from configuration to ensure consistency and maintainability.
+
+**Fix:** Extract to constants: const DEFAULT_MACROS = { calories: 2000, protein: 150, carbs: 200, fat: 65 }; then use DEFAULT_MACROS.calories, etc.
+
+## TrainerIntakes.tsx
+
+### [HIGH] hardcoded-config — line 14
+
+**Code:** `const mockIntakes: PendingIntake[] = [
+  {
+    id: '1',
+    clientName: 'Emma Wilson',
+    email: 'emma@example.com',
+    tier: 'body-blueprint',
+    submittedAt: new Date(Date.now() - 2 * 60 * 60 * 1000),
+    primaryGoal: 'lose-fat',
+  },
+  // ... more mock data`
+
+**Issue:** Mock data with hardcoded emails and configuration values embedded directly in the component. This creates coupling between test data and production code.
+
+**Fix:** Move mock data to a separate test data file or environment-based configuration: import { mockIntakes } from './testData' or fetch from process.env.NODE_ENV === 'development'
+
+### [HIGH] stub-with-shell — line 42
+
+**Code:** `const fetchIntakes = async () => {
+  setLoading(true);
+  await new Promise((r) => setTimeout(r, 500));
+  setIntakes(mockIntakes);
+  setLoading(false);
+};`
+
+**Issue:** Function has complete async structure with loading states but core logic is just a setTimeout delay returning mock data. This will appear to work but provides no real data fetching.
+
+**Fix:** Replace with actual API call: const response = await fetch('/api/intakes'); const data = await response.json(); setIntakes(data);
+
+## TrainerIntakeReview.tsx
+
+### [HIGH] stub-with-shell — line 79
+
+**Code:** `const fetchData = async () => {
+      setLoading(true);
+      await new Promise((r) => setTimeout(r, 500));
+      setIntakeData(mockIntakeData);
+      setLoading(false);
+    };`
+
+**Issue:** The fetchData function has the structure of a real API call (async, loading states, error handling pattern) but only contains a setTimeout and uses mock data. This creates the illusion of working functionality while being a stub.
+
+**Fix:** Replace with actual API call: `const response = await fetch(`/api/intakes/${id}`); setIntakeData(await response.json());` or make the stub explicit with a comment and throw for missing implementation.
+
+### [HIGH] stub-with-shell — line 92
+
+**Code:** `setSubmitting(true);
+    await new Promise((r) => setTimeout(r, 1000));
+    // TODO: API call to approve intake
+    navigate('/trainer/intakes');`
+
+**Issue:** The handleApprove function has complete error handling and loading states but contains only a setTimeout and TODO comment instead of the actual approval logic. This will appear to work in testing but do nothing in production.
+
+**Fix:** Implement the actual API call: `await fetch('/api/intakes/${id}/approve', { method: 'POST', body: JSON.stringify({ program: selectedProgram, mealPlan: selectedMealPlan }) })` or throw an error if not ready for production.
+
+## TrainerDemoClientDetail.tsx
+
+### [LOW] generic-variable-names — line 131
+
+**Code:** `demoClient.assignedWorkouts.filter(w => w.id !== workoutId)`
+
+**Issue:** Loop variable 'w' is generic when iterating over a typed collection of workouts. 'workout' would be more descriptive.
+
+**Fix:** demoClient.assignedWorkouts.filter(workout => workout.id !== workoutId)
+
+## TrainerDashboard.tsx
+
+### [HIGH] stub-with-shell — line 36
+
+**Code:** `const fetchData = async () => {
+      setLoading(true);
+      // TODO: Replace with actual API calls
+      await new Promise((r) => setTimeout(r, 500));
+      
+      setStats({
+        activeClients: 12,
+        pendingIntakes: 3,
+        pendingCheckins: 5,
+        unreadMessages: 8,
+      });
+
+      setRecentActivity([
+        {
+          id: '1',
+          type: 'workout',
+          clientName: 'Sarah M.',
+          description: 'Completed Lower Body Power',
+          timestamp: new Date(Date.now() - 30 * 60 * 1000),
+        },
+        // ... more hardcoded activity items
+      ]);`
+
+**Issue:** Function has complete structure and error handling but core business logic (API calls) is stubbed with hardcoded mock data and a TODO comment. The dashboard will display fake data instead of real trainer statistics.
+
+**Fix:** Replace with actual API calls to fetch real dashboard data, or make the stub explicit by throwing an error until implemented
+
+## TrainerClients.tsx
+
+### [LOW] generic-variable-names — line 112
+
+**Code:** `const res = await getTrainerClients(currentUser.uid);`
+
+**Issue:** Variable 'res' is a generic name that doesn't communicate what type of response or data it contains
+
+**Fix:** const clientsResponse = await getTrainerClients(currentUser.uid);
+
+### [LOW] generic-variable-names — line 115
+
+**Code:** `res.data.clients.map((c) => ({`
+
+**Issue:** Parameter 'c' in the map function is generic when iterating over a typed collection of clients
+
+**Fix:** res.data.clients.map((client) => ({
+
+## TrainerClientDetail.tsx
+
+### [LOW] generic-variable-names — line 166
+
+**Code:** `const res = await getTrainerClient(currentUser.uid, id);`
+
+**Issue:** Variable 'res' is a generic name that doesn't communicate what kind of response this is - it's specifically a trainer client fetch response
+
+**Fix:** const clientResponse = await getTrainerClient(currentUser.uid, id);
+
+### [LOW] generic-variable-names — line 168
+
+**Code:** `const c = res.data;`
+
+**Issue:** Variable 'c' is a single-letter generic name that doesn't communicate it represents client data
+
+**Fix:** const clientData = res.data;
+
+### [LOW] generic-variable-names — line 155
+
+**Code:** `await new Promise((r) => setTimeout(r, 300));`
+
+**Issue:** Parameter 'r' is a generic name in the Promise resolve callback - while common in this pattern, 'resolve' would be clearer
+
+**Fix:** await new Promise((resolve) => setTimeout(resolve, 300));
+
+## TrainerCheckins.tsx
+
+### [LOW] generic-variable-names — line 130
+
+**Code:** `{[...Array(5)].map((_, i) => (`
+
+**Issue:** Using generic variable name 'i' for array index in loading skeleton generation where 'skeletonIndex' would be more descriptive
+
+**Fix:** {[...Array(5)].map((_, skeletonIndex) => (
+
+### [HIGH] hardcoded-config — line 118
+
+**Code:** `await new Promise((r) => setTimeout(r, 500));`
+
+**Issue:** Hardcoded 500ms delay for simulating API loading time should be configurable or removed in production
+
+**Fix:** const MOCK_DELAY = process.env.NODE_ENV === 'development' ? 500 : 0; await new Promise((r) => setTimeout(r, MOCK_DELAY));
+
+### [HIGH] hardcoded-config — line 132
+
+**Code:** `{[...Array(5)].map((_, i) => (`
+
+**Issue:** Hardcoded number of skeleton loading items (5) should match expected data size or be configurable
+
+**Fix:** const SKELETON_COUNT = 5; {[...Array(SKELETON_COUNT)].map((_, i) => (
+
+## TrainerCheckinReview.tsx
+
+### [HIGH] stub-with-shell — line 67
+
+**Code:** `// TODO: API call to submit review`
+
+**Issue:** The handleSubmit function appears complete with error handling and loading states, but the core functionality (submitting the review) is just a TODO comment. This will silently fail to save review data in production.
+
+**Fix:** Replace TODO with actual API call: `await api.submitCheckinReview(id, { feedback, newCalories, newProtein, newCarbs, newFat, nextWeekFocus })`
+
+### [HIGH] hardcoded-config — line 22
+
+**Code:** `progressPhotos: {
+    front: 'https://placehold.co/400x600/e0e7ff/6366f1?text=Front',
+    side: 'https://placehold.co/400x600/e0e7ff/6366f1?text=Side',
+  }`
+
+**Issue:** Hardcoded placeholder URLs in mock data that could accidentally make it to production, creating broken image links.
+
+**Fix:** Move to environment config: `front: process.env.REACT_APP_PLACEHOLDER_IMAGE_BASE + '/front'` or use proper mock data service
+
+## ProgressTracking.tsx
+
+### [MEDIUM] console-log-left-in — line 79
+
+**Code:** `console.log('Setting entries:', limitedEntries.length, 'entries for user', userId);`
+
+**Issue:** Debug logging statement left in production code that logs user ID and entry count details
+
+**Fix:** Remove the console.log statement or replace with proper logger: logger.debug('Progress entries loaded', { count: limitedEntries.length })
+
+### [MEDIUM] console-log-left-in — line 86
+
+**Code:** `console.log('Setting up real-time listener for progress entries (fetching all, filtering client-side), userId:', userId);`
+
+**Issue:** Debug logging statement left in production code that logs user ID and implementation details
+
+**Fix:** Remove the console.log statement or replace with proper logger: logger.debug('Setting up progress listener')
+
+### [MEDIUM] console-log-left-in — line 91
+
+**Code:** `console.log('Progress entries updated from Firestore:', snapshot.docs.length, 'total entries');`
+
+**Issue:** Debug logging statement left in production code that logs database query details
+
+**Fix:** Remove the console.log statement or replace with proper logger: logger.debug('Progress entries updated', { count: snapshot.docs.length })
+
+## Measurements.tsx
+
+### [MEDIUM] console-log-left-in — line 83
+
+**Code:** `console.error('Failed to fetch measurements:', error);`
+
+**Issue:** Debug console statement left in production code that will clutter production logs and potentially expose internal error details
+
+**Fix:** Replace with proper error logging: logger.error('Failed to fetch measurements', { error: error.message })
+
+### [MEDIUM] try-catch-everything — line 58
+
+**Code:** `try {
+        // Try to get latest measurements from Firestore
+        if (db) {
+          const entriesRef = collection(db, 'progressEntries');
+          const q = query(
+            entriesRef,
+            where('clientId', '==', currentUser.uid)
+          );
+          
+          const snapshot = await getDocs(q);
+          // Sort by date descending client-side
+          const sortedDocs = snapshot.docs.sort((a, b) => {
+            const dateA = a.data().date?.toDate() || new Date(0);
+            const dateB = b.data().date?.toDate() || new Date(0);
+            return dateB.getTime() - dateA.getTime();
+          });
+          // Find the first entry with measurements
+          for (const docSnap of sortedDocs.slice(0, 30)) {
+            const data = docSnap.data();
+            const measurements = data.measurements;
+            if (measurements && (measurements.chest || measurements.waist || measurements.hips)) {
+              setLatestMeasurements(measurements);
+              setFormData({
+                chest: measurements.chest?.toString() || '',
+                waist: measurements.waist?.toString() || '',
+                hips: measurements.hips?.toString() || '',
+                glutes: measurements.glutes?.toString() || '',
+                leftBicep: measurements.leftBicep?.toString() || '',
+                rightBicep: measurements.rightBicep?.toString() || '',
+                leftThigh: measurements.leftThigh?.toString() || '',
+                rightThigh: measurements.rightThigh?.toString() || '',
+              });
+              break;
+            }
+          }
+        }
+      } catch (error) {
+        console.error('Failed to fetch measurements:', error);
+      }`
+
+**Issue:** Blanket try/catch around entire Firestore operation with generic error handling that only logs and continues. Different Firebase errors (network, permissions, quota) should be handled differently
+
+**Fix:** Handle specific Firebase errors differently - network errors might warrant retry, permission errors should redirect to auth, and only log unexpected errors
+
+## ProfileSupport.tsx
+
+### [HIGH] hardcoded-config — line 17
+
+**Code:** `description: 'support@hardcoresynergy.com'`
+
+**Issue:** Email address is hardcoded in source code, making it difficult to change for different environments or configurations
+
+**Fix:** Move to environment variable: process.env.REACT_APP_SUPPORT_EMAIL || 'support@hardcoresynergy.com'
+
+### [HIGH] hardcoded-config — line 18
+
+**Code:** `action: () => window.location.href = 'mailto:support@hardcoresynergy.com'`
+
+**Issue:** Support email address is hardcoded again, duplicating the configuration value
+
+**Fix:** Use a constant or environment variable to avoid duplication
+
+### [HIGH] hardcoded-config — line 68
+
+**Code:** `onClick={() => window.location.href = 'mailto:support@hardcoresynergy.com'}`
+
+**Issue:** Support email hardcoded a third time, creating maintenance burden when email needs to change
+
+**Fix:** Extract to constant: const SUPPORT_EMAIL = process.env.REACT_APP_SUPPORT_EMAIL || 'support@hardcoresynergy.com'
+
+### [HIGH] stub-with-shell — line 14
+
+**Code:** `action: () => alert('Support chat coming soon!')`
+
+**Issue:** Function presents as working support contact but is just a placeholder alert that provides no actual functionality
+
+**Fix:** Either implement the feature or disable/hide the option until ready: disabled: true, or remove from supportOptions array
+
+### [HIGH] stub-with-shell — line 23
+
+**Code:** `action: () => alert('FAQs coming soon!')`
+
+**Issue:** FAQs option appears functional but only shows a placeholder alert, misleading users who need help
+
+**Fix:** Remove from supportOptions array until FAQ system is implemented, or navigate to existing FAQ page if available
+
+## ProfileSettings.tsx
+
+### [HIGH] stub-with-shell — line 25
+
+**Code:** `const handleSave = async () => {
+    setSaving(true);
+    // TODO: Implement app settings API call (language, sound effects, haptic feedback)
+    await new Promise((r) => setTimeout(r, 500));
+    setSaving(false);
+    alert('Settings saved!');
+    navigate('/profile');
+  };`
+
+**Issue:** Function has complete error handling, loading states, and success flow but the core business logic is a TODO comment with a fake delay. This will appear to work but won't actually save settings.
+
+**Fix:** Replace with actual API call: `await saveUserSettings({ language: settings.language, soundEffects: settings.soundEffects, hapticFeedback: settings.hapticFeedback });`
+
+### [LOW] comment-restatement — line 20
+
+**Code:** `// Sync darkMode from theme context
+  useEffect(() => {
+    // Settings state is now managed by theme context
+  }, [darkMode]);`
+
+**Issue:** The comment simply restates what the useEffect dependency array already indicates - that it syncs with darkMode. The inner comment adds no meaningful information since the effect body is empty.
+
+**Fix:** Remove the comments or add meaningful context about why this effect exists if it has a purpose, or remove the entire empty useEffect.
+
+### [LOW] comment-restatement — line 36
+
+**Code:** `const handleDarkModeToggle = (enabled: boolean) => {
+    setDarkMode(enabled);
+    // Save immediately without needing to click "Save Settings"
+  };`
+
+**Issue:** Comment merely describes the mechanical difference from other settings rather than explaining the business reason or user experience rationale for this behavior.
+
+**Fix:** Replace with meaningful context: `// Dark mode preference is persisted immediately for better UX` or remove if the behavior is self-evident.
+
+## ProfileNotifications.tsx
+
+### [HIGH] stub-with-shell — line 19
+
+**Code:** `const handleSave = async () => {
+    setSaving(true);
+    // TODO: Implement notification preferences API call
+    await new Promise((r) => setTimeout(r, 1000));
+    setSaving(false);
+    alert('Notification preferences saved!');
+    navigate('/profile');
+  };`
+
+**Issue:** Function has complete structure with loading state management and navigation flow, but the core business logic (saving preferences to backend) is a TODO comment with a fake timeout. The UI shows success feedback even though no actual save operation occurred.
+
+**Fix:** Either implement the actual API call or throw an error to fail loudly: throw new Error('Save preferences not implemented - see issue #X')
+
+## ProfileEdit.tsx
+
+### [HIGH] stub-with-shell — line 20
+
+**Code:** `const handleSave = async () => {
+    setSaving(true);
+    // TODO: Implement profile update API call
+    await new Promise((r) => setTimeout(r, 1000));
+    setSaving(false);
+    alert('Profile updated successfully!');
+    navigate('/profile');
+  };`
+
+**Issue:** Function has complete error handling structure and UI feedback but the core business logic (saving profile data) is just a TODO comment with a fake delay. The function claims success without actually persisting any data.
+
+**Fix:** Either implement the actual API call or make the stub explicit: throw new Error('Profile update not implemented - see issue #X') so it fails loudly instead of silently lying about success.
+
+## Profile.tsx
+
+### [MEDIUM] console-log-left-in — line 54
+
+**Code:** `console.error('Failed to sign out:', error);`
+
+**Issue:** Debug console statement left in production code within error handling. While this is console.error rather than console.log, it still exposes internal error details that should use proper logging.
+
+**Fix:** Replace with proper error logging: logger.error('Sign out failed', { error: error.message }) or remove if error handling is sufficient
+
+## NutritionLog.tsx
+
+### [MEDIUM] console-log-left-in — line 131
+
+**Code:** `console.error('Failed to log nutrition:', error);`
+
+**Issue:** Debug console.error statement left in production code that logs internal error details
+
+**Fix:** Replace with proper error logging: logger.error('Failed to log nutrition', { error: error.message }) or remove if error is already handled by alert
+
+## NutritionHistory.tsx
+
+### [MEDIUM] console-log-left-in — line 82
+
+**Code:** `console.error('Failed to fetch nutrition logs:', error);`
+
+**Issue:** Debug console.error statement left in production code that will clutter production logs and potentially leak implementation details
+
+**Fix:** Replace with proper logging: import { logger } from './logger'; logger.error('Failed to fetch nutrition logs', { error: error.message });
+
+## MealPlan.tsx
+
+### [MEDIUM] console-log-left-in — line 133
+
+**Code:** `console.error('Failed to fetch nutrition data:', error);`
+
+**Issue:** Console.error statement left in production code that will log error details to browser console, potentially exposing internal error information
+
+**Fix:** Replace with proper error logging using a logger service or remove if error handling is done elsewhere
+
+## MacroCalculator.tsx
+
+### [MEDIUM] console-log-left-in — line 100
+
+**Code:** `console.error('No results to update');`
+
+**Issue:** Debug console statements left in production code that will clutter production logs
+
+**Fix:** Remove console.error or replace with proper logger
+
+### [MEDIUM] console-log-left-in — line 105
+
+**Code:** `console.error('No user logged in');`
+
+**Issue:** Debug console statements left in production code that will clutter production logs
+
+**Fix:** Remove console.error or replace with proper logger
+
+### [MEDIUM] console-log-left-in — line 111
+
+**Code:** `console.log('Updating macros:', {
+        targetCalories: results.targetCalories,
+        targetProtein: results.protein,
+        targetCarbs: results.carbs,
+        targetFat: results.fat,
+      });`
+
+**Issue:** Debug console.log statement left in production code that logs internal application state
+
+**Fix:** Remove console.log or replace with proper logger that can be filtered in production
+
+### [MEDIUM] console-log-left-in — line 125
+
+**Code:** `console.log('Macros updated successfully');`
+
+**Issue:** Debug console.log statement left in production code that will clutter production logs
+
+**Fix:** Remove console.log or replace with proper logger
+
+### [MEDIUM] console-log-left-in — line 130
+
+**Code:** `console.error('Failed to update macros:', error);`
+
+**Issue:** Debug console statements left in production code that will clutter production logs
+
+**Fix:** Remove console.error or replace with proper logger
+
+## IntakeForm.tsx
+
+### [MEDIUM] console-log-left-in — line 69
+
+**Code:** `console.log('Draft loaded from Firestore');`
+
+**Issue:** Debug console.log statement left in production code that will clutter production logs
+
+**Fix:** Remove debug log or replace with proper logger: logger.debug('Draft loaded from Firestore')
+
+### [MEDIUM] console-log-left-in — line 93
+
+**Code:** `console.log('Draft saved to Firestore');`
+
+**Issue:** Debug console.log statement left in production code that will clutter production logs
+
+**Fix:** Remove debug log or replace with proper logger: logger.debug('Draft saved to Firestore')
+
+### [MEDIUM] console-log-left-in — line 125
+
+**Code:** `console.log('Submitting intake form...');`
+
+**Issue:** Debug console.log statement left in production code that will clutter production logs
+
+**Fix:** Remove debug log or replace with proper logger: logger.info('Submitting intake form')
+
+### [MEDIUM] console-log-left-in — line 135
+
+**Code:** `console.log('Client profile saved to Firestore');`
+
+**Issue:** Debug console.log statement left in production code that will clutter production logs
+
+**Fix:** Remove debug log or replace with proper logger: logger.info('Client profile saved')
+
+### [MEDIUM] console-log-left-in — line 139
+
+**Code:** `console.log('Intake marked as completed');`
+
+**Issue:** Debug console.log statement left in production code that will clutter production logs
+
+**Fix:** Remove debug log or replace with proper logger: logger.info('Intake completed')
+
+## Home.tsx
+
+### [MEDIUM] console-log-left-in — line 125
+
+**Code:** `console.log('📹 Loaded motivational content:', content);`
+
+**Issue:** Debug console.log statement left in production code that logs internal application state and data structures
+
+**Fix:** Remove the console.log or replace with a proper logger: logger.debug('Loaded motivational content', { contentId: content.id })
+
+### [MEDIUM] console-log-left-in — line 138
+
+**Code:** `console.log('📹 Loaded video from all content (fallback):', videos[0]);`
+
+**Issue:** Debug console.log statement left in production code that logs fallback data loading behavior
+
+**Fix:** Remove the console.log or replace with a proper logger: logger.debug('Loaded video from fallback query', { videoId: videos[0].id })
+
+### [MEDIUM] console-log-left-in — line 140
+
+**Code:** `console.log('⚠️ No video content found');`
+
+**Issue:** Debug console.log statement left in production code that logs application flow information
+
+**Fix:** Remove the console.log or replace with a proper logger: logger.warn('No video content found')
+
+### [MEDIUM] console-log-left-in — line 131
+
+**Code:** `console.warn('Preferred query failed, trying fallback:', error);`
+
+**Issue:** Debug console.warn statement left in production code that logs error details and fallback behavior
+
+**Fix:** Remove the console.warn or replace with a proper logger: logger.warn('Preferred query failed, using fallback', { error: error.message })
+
+### [MEDIUM] console-log-left-in — line 93
+
+**Code:** `console.error('Failed to fetch workouts:', error);`
+
+**Issue:** Debug console.error statement left in production code that logs error information
+
+**Fix:** Replace with a proper logger: logger.error('Failed to fetch workouts', { error: error.message, userId: currentUser.uid })
+
+## SignUp.tsx
+
+✓ Clean
+
+## SignIn.tsx
+
+### [MEDIUM] try-catch-everything — line 24
+
+**Code:** `try {
+      await signIn(email, password);
+      // Redirect based on subscription status
+      if (!subscriptionTier) {
+        navigate('/pricing');
+      } else {
+        navigate(from, { replace: true });
+      }
+    } catch (err) {
+      setError(err instanceof Error ? err.message : 'Failed to sign in');
+    }`
+
+**Issue:** Generic catch block that handles all errors the same way, whether they're network failures, authentication failures, or validation errors. Different error types should be handled distinctly for better UX.
+
+**Fix:** Handle specific error types differently - authentication failures vs network errors vs validation errors should show different messages and potentially different recovery actions.
+
+### [MEDIUM] try-catch-everything — line 60
+
+**Code:** `try {
+      await signInWithGoogle();
+      // Note: If using redirect, navigation won't happen here
+      // The redirect result handler will navigate after successful auth
+      if (!subscriptionTier) {
+        navigate('/pricing');
+      } else {
+        navigate(from, { replace: true });
+      }
+    } catch (err) {
+      setError(err instanceof Error ? err.message : 'Failed to sign in with Google');
+    }`
+
+**Issue:** Another generic catch block that treats all Google sign-in errors the same. Popup blocked, user cancelled, network errors, and OAuth errors should be handled differently.
+
+**Fix:** Check error codes/types to provide specific handling - popup blocked should suggest alternative, user cancellation should not show error, OAuth errors should provide specific guidance.
+
+## Pricing.tsx
+
+### [MEDIUM] console-log-left-in — line 93
+
+**Code:** `console.error('Failed to update subscription:', error);`
+
+**Issue:** Console.error statement left in production code that will clutter production logs and expose internal implementation details
+
+**Fix:** Replace with proper error logging: logger.error('Failed to update subscription', { error: error.message, userId: currentUser?.uid })
+
+### [MEDIUM] console-log-left-in — line 99
+
+**Code:** `console.error('Payment error:', error);`
+
+**Issue:** Console.error statement left in production code in the payment error handler
+
+**Fix:** Replace with proper error logging: logger.error('Payment processing failed', { error }) or remove since comment indicates error is already shown in PaymentForm component
+
+## AdminWorkoutPrograms.tsx
+
+### [MEDIUM] console-log-left-in — line 48
+
+**Code:** `console.error('Failed to fetch programs:', error);`
+
+**Issue:** Debug console statement left in production code that will clutter production logs and potentially leak internal implementation details
+
+**Fix:** Replace with proper error logging: logger.error('Failed to fetch programs', { error })
+
+### [MEDIUM] console-log-left-in — line 70
+
+**Code:** `console.error('Failed to delete program:', error);`
+
+**Issue:** Debug console statement left in production code that will clutter production logs and potentially leak internal implementation details
+
+**Fix:** Replace with proper error logging: logger.error('Failed to delete program', { programId, error })
+
+## AdminUsers.tsx
+
+### [LOW] generic-variable-names — line 44
+
+**Code:** `const res = await getAdminUsers({ limit: 500 });`
+
+**Issue:** Variable 'res' is a generic name that doesn't communicate what the response contains - it's an admin users API response
+
+**Fix:** const usersResponse = await getAdminUsers({ limit: 500 });
+
+### [LOW] generic-variable-names — line 46
+
+**Code:** `setUsers(res.data.users.map((u) => normalizeAdminUser(u as unknown as Record<string, unknown>)));`
+
+**Issue:** Variable 'u' in the map function is generic when 'user' or 'rawUser' would be more descriptive for the user data being normalized
+
+**Fix:** setUsers(res.data.users.map((rawUser) => normalizeAdminUser(rawUser as unknown as Record<string, unknown>)));
+
+## AdminTrainers.tsx
+
+### [LOW] generic-variable-names — line 88
+
+**Code:** `const openEdit = (t: TrainerProfile) => {`
+
+**Issue:** Parameter named 't' instead of a descriptive name like 'trainer' makes the function less readable, especially given the complex logic that follows
+
+**Fix:** const openEdit = (trainer: TrainerProfile) => {
+
+### [LOW] generic-variable-names — line 106
+
+**Code:** `setTrainers(
+        res.data.trainers.map((t) => mapUserDocToTrainer(t as unknown as Record<string, unknown>))
+      );`
+
+**Issue:** Loop variable 't' in map function should be named 'trainer' or 'trainerData' to clarify what's being transformed
+
+**Fix:** res.data.trainers.map((trainer) => mapUserDocToTrainer(trainer as unknown as Record<string, unknown>))
+
+## AdminSweatStarterWorkouts.tsx
+
+### [MEDIUM] console-log-left-in — line 86
+
+**Code:** `console.error('Failed to fetch data:', error);`
+
+**Issue:** Debug console statement left in production code that will log error details to browser console
+
+**Fix:** Replace with proper error logging: logger.error('Failed to fetch data', error) or remove if error handling is done elsewhere
+
+### [MEDIUM] console-log-left-in — line 152
+
+**Code:** `console.warn('Workout missing ID:', workout);`
+
+**Issue:** Debug console statement left in production code that logs workout data to browser console
+
+**Fix:** Replace with proper logging or remove: use a logger service or handle the missing ID case appropriately without console output
+
+### [MEDIUM] console-log-left-in — line 164
+
+**Code:** `console.log(`  Added workout ${workout.id} (week ${weekNumber}, day ${dayIndex}) to week ${weekNumber}`);`
+
+**Issue:** Debug console statement left in production code that logs detailed workout assignment information
+
+**Fix:** Remove this debug logging statement or replace with proper logging service if needed for production monitoring
+
+## AdminSettings.tsx
+
+### [HIGH] hardcoded-config — line 12
+
+**Code:** `appName: 'Hardcore Synergy',
+supportEmail: 'support@hardcoresynergy.com',
+contactInfo: '1-800-HARD-CORE',
+termsUrl: 'https://hardcoresynergy.com/terms',
+privacyUrl: 'https://hardcoresynergy.com/privacy'`
+
+**Issue:** Company-specific configuration values are hardcoded directly in the React component. These values should be configurable without code changes, especially URLs and contact information that may need to be updated by administrators.
+
+**Fix:** Move these values to environment variables or a configuration file: process.env.REACT_APP_NAME, process.env.REACT_APP_SUPPORT_EMAIL, etc., or load them from an API endpoint that admins can update.
+
+### [HIGH] async-misuse — line 29
+
+**Code:** `const handleSave = async () => {
+  setSaving(true);
+  await new Promise((r) => setTimeout(r, 1000));
+  setSaving(false);
+};`
+
+**Issue:** Function is marked async and uses await, but only to create a fake delay with setTimeout. This simulates async behavior without actually performing any real async operation like saving data to a server.
+
+**Fix:** Either remove async/await and make it synchronous if no real async work is needed, or implement actual async functionality like: 'await saveSettingsToAPI(settings)'
+
+### [HIGH] stub-with-shell — line 29
+
+**Code:** `const handleSave = async () => {
+  setSaving(true);
+  await new Promise((r) => setTimeout(r, 1000));
+  setSaving(false);
+};`
+
+**Issue:** The save function has all the UI scaffolding (loading state, async signature) but contains only a fake delay instead of actual save logic. This will appear to work but won't persist any settings changes.
+
+**Fix:** Implement actual save functionality: 'await fetch('/api/admin/settings', { method: 'PUT', body: JSON.stringify(settings) })' or throw an error if not yet implemented.
+
+## AdminExercises.tsx
+
+### [MEDIUM] console-log-left-in — line 69
+
+**Code:** `console.log('🎭 Demo mode: Using empty exercise list');`
+
+**Issue:** Debug console.log statement left in production code that logs internal application state
+
+**Fix:** Remove debug log or replace with proper logging: logger.debug('Demo mode: Using empty exercise list')
+
+### [MEDIUM] console-log-left-in — line 75
+
+**Code:** `console.error('Firestore database not initialized');`
+
+**Issue:** Console.error used for application error handling instead of proper error logging
+
+**Fix:** Use proper error logging: logger.error('Firestore database not initialized')
+
+### [MEDIUM] console-log-left-in — line 82
+
+**Code:** `console.warn('No current user, cannot fetch exercises');`
+
+**Issue:** Console.warn used for application warning instead of proper logging
+
+**Fix:** Use proper logging: logger.warn('No current user, cannot fetch exercises')
+
+### [MEDIUM] console-log-left-in — line 87
+
+**Code:** `console.log('Fetching exercises...', { userId: currentUser.uid, email: currentUser.email });`
+
+**Issue:** Debug console.log statement left in production code that logs user identification data including email
+
+**Fix:** Remove debug log or use proper logging without sensitive data: logger.debug('Fetching exercises', { userId: currentUser.uid })
+
+### [MEDIUM] console-log-left-in — line 93
+
+**Code:** `console.log('Fetching exercises from Firestore...');`
+
+**Issue:** Debug console.log statement left in production code
+
+**Fix:** Remove debug log or use proper logging: logger.debug('Fetching exercises from Firestore')
+
+### [MEDIUM] console-log-left-in — line 95
+
+**Code:** `console.log('Query successful, got', snapshot.docs.length, 'exercises');`
+
+**Issue:** Debug console.log statement left in production code
+
+**Fix:** Remove debug log or use proper logging: logger.debug('Query successful', { count: snapshot.docs.length })
+
+### [MEDIUM] console-log-left-in — line 103
+
+**Code:** `console.log('Successfully loaded', exercisesData.length, 'exercises');`
+
+**Issue:** Debug console.log statement left in production code
+
+**Fix:** Remove debug log or use proper logging: logger.info('Successfully loaded exercises', { count: exercisesData.length })
+
+### [MEDIUM] console-log-left-in — line 105
+
+**Code:** `console.error('Failed to fetch exercises:', error);`
+
+**Issue:** Console.error used for application error handling instead of proper error logging
+
+**Fix:** Use proper error logging: logger.error('Failed to fetch exercises', { error })
+
+### [HIGH] console-log-left-in — line 106
+
+**Code:** `console.error('Error details:', {
+        code: error?.code,
+        message: error?.message,
+        stack: error?.stack,
+        userId: currentUser?.uid,
+        email: currentUser?.email,
+      });`
+
+**Issue:** Console.error logging sensitive user data including email address and user ID in production code
+
+**Fix:** Remove sensitive data from logs: logger.error('Error details', { code: error?.code, message: error?.message })
+
+### [MEDIUM] console-log-left-in — line 138
+
+**Code:** `console.error('Cannot edit: exercise is null or undefined');`
+
+**Issue:** Console.error used for application error handling instead of proper error logging
+
+**Fix:** Use proper error logging: logger.error('Cannot edit: exercise is null or undefined')
+
+## AdminExerciseUpload.tsx
+
+### [MEDIUM] console-log-left-in — line 150
+
+**Code:** `console.warn('Auto cover from video failed:', e);`
+
+**Issue:** Debug console statement left in production code that will log errors to browser console in production, potentially exposing implementation details
+
+**Fix:** Replace with proper error logging: logger.warn('Auto cover generation failed', { error: e.message }) or remove entirely if non-critical
+
+## AdminDashboard.tsx
+
+### [LOW] generic-variable-names — line 49
+
+**Code:** `const res = await getPlatformAnalytics();`
+
+**Issue:** Variable 'res' is a generic name that doesn't communicate what the response contains - analytics data in this case
+
+**Fix:** const analyticsResponse = await getPlatformAnalytics();
+
+### [LOW] generic-variable-names — line 50
+
+**Code:** `if (res.success && res.data) {`
+
+**Issue:** Using generic 'res' variable makes the conditional logic less clear about what's being checked
+
+**Fix:** if (analyticsResponse.success && analyticsResponse.data) {
+
+### [LOW] generic-variable-names — line 51
+
+**Code:** `setAnalytics(res.data);`
+
+**Issue:** Generic 'res' variable continues to obscure the intent - this is setting analytics data
+
+**Fix:** setAnalytics(analyticsResponse.data);
+
+### [LOW] generic-variable-names — line 55
+
+**Code:** `res.error ||`
+
+**Issue:** Generic 'res' variable used in error handling where a more descriptive name would clarify this is an analytics API error
+
+**Fix:** analyticsResponse.error ||
+
+## AdminContent.tsx
+
+### [MEDIUM] console-log-left-in — line 61
+
+**Code:** `console.warn('OrderBy failed, fetching without order:', orderError);`
+
+**Issue:** Debug console statement left in production code that exposes internal error handling logic and Firebase implementation details
+
+**Fix:** Replace with proper logging: logger.warn('Firestore orderBy failed, using fallback query', { error: orderError.message })
+
+### [MEDIUM] console-log-left-in — line 78
+
+**Code:** `console.error('Failed to fetch content:', error);`
+
+**Issue:** Debug console statement left in production code in error handler
+
+**Fix:** Replace with proper logging: logger.error('Content fetch failed', { error: error.message, userId: currentUser?.uid })
+
+### [MEDIUM] console-log-left-in — line 108
+
+**Code:** `console.error('Failed to load content:', error);`
+
+**Issue:** Debug console statement left in production code in error handler for content loading
+
+**Fix:** Replace with proper logging: logger.error('Content load failed', { contentId: id, error: error.message })
+
+### [MEDIUM] console-log-left-in — line 136
+
+**Code:** `console.error('Upload error:', error);`
+
+**Issue:** Debug console statement left in production code in file upload error handler
+
+**Fix:** Replace with proper logging: logger.error('File upload failed', { error: error.message, fileName: file.name })
+
+## AdminCommunity.tsx
+
+### [LOW] comment-restatement — line 79
+
+**Code:** `{/* Reported Posts Alert */}`
+
+**Issue:** Comment simply restates what's obvious from the JSX structure - the alert component for reported posts is self-evident from the content
+
+**Fix:** Remove the comment or replace with context about why this alert appears conditionally
+
+### [LOW] comment-restatement — line 96
+
+**Code:** `{/* Search & Filters */}`
+
+**Issue:** Comment translates the JSX into English without adding any information about purpose or behavior
+
+**Fix:** Remove the comment - the search input and filter select are self-documenting
+
+### [LOW] comment-restatement — line 119
+
+**Code:** `{/* Posts List */}`
+
+**Issue:** Comment simply describes what the following JSX does without providing context about data structure or behavior
+
+**Fix:** Remove the comment or explain the post filtering/rendering logic
+
+### [LOW] comment-restatement — line 130
+
+**Code:** `{/* Header */}`
+
+**Issue:** Comment restates the obvious structure of the post header section
+
+**Fix:** Remove the comment - the header structure is clear from the JSX elements
+
+## AdminAnalytics.tsx
+
+### [LOW] generic-variable-names — line 41
+
+**Code:** `const res = await getPlatformAnalytics();
+      if (cancelled) return;
+      if (res.success && res.data) {`
+
+**Issue:** Variable 'res' is a generic name that doesn't communicate what kind of response this is. In a function dealing with analytics data, a more descriptive name would improve readability.
+
+**Fix:** const analyticsResponse = await getPlatformAnalytics();
+
+### [LOW] generic-variable-names — line 57
+
+**Code:** `? analytics.revenueByTier.map((r) => ({ month: r.tier, mrr: r.amount }))`
+
+**Issue:** Loop variable 'r' is generic when iterating over revenue data. A more descriptive name would clarify what each item represents.
+
+**Fix:** ? analytics.revenueByTier.map((revenue) => ({ month: revenue.tier, mrr: revenue.amount }))
+
+### [LOW] generic-variable-names — line 64
+
+**Code:** `? analytics.signupsByMonth.map((s) => ({`
+
+**Issue:** Loop variable 's' is generic when iterating over signup data. A more descriptive name would improve code clarity.
+
+**Fix:** ? analytics.signupsByMonth.map((signup) => ({
+
+### [LOW] generic-variable-names — line 73
+
+**Code:** `return analytics.activeUsersByDay.map((d) => ({`
+
+**Issue:** Loop variable 'd' is generic when iterating over daily user data. A more descriptive name would clarify the data structure.
+
+**Fix:** return analytics.activeUsersByDay.map((dailyData) => ({
+
+### [LOW] generic-variable-names — line 85
+
+**Code:** `const total = entries.reduce((s, [, v]) => s + Number(v), 0) || 1;`
+
+**Issue:** Variables 's' and 'v' in the reduce function are generic. More descriptive names would clarify this is summing user counts.
+
+**Fix:** const total = entries.reduce((sum, [, userCount]) => sum + Number(userCount), 0) || 1;
+
+### [LOW] generic-variable-names — line 86
+
+**Code:** `return entries.map(([name, v]) => ({`
+
+**Issue:** Variable 'v' is generic when destructuring tier data. A more descriptive name would improve readability.
+
+**Fix:** return entries.map(([name, userCount]) => ({
+
+### [LOW] generic-variable-names — line 88
+
+**Code:** `value: Math.round((Number(v) / total) * 100),`
+
+**Issue:** Using generic variable 'v' from destructuring instead of the more descriptive name that should have been used.
+
+**Fix:** value: Math.round((Number(userCount) / total) * 100),
+
+## TrainerSidebar.tsx
+
+✓ Clean
+
+## TrainerLayout.tsx
+
+✓ Clean
+
+## ClientCard.tsx
+
+✓ Clean
+
+## AdminSidebar.tsx
+
+✓ Clean
+
+## AdminLayout.tsx
+
+✓ Clean
+
+## Summary
+
+| Severity | Count |
+|---|---|
+| High | 36 |
+| Medium | 81 |
+| Low | 46 |
+| **Total** | **163** |