@reidbuilds/slop 0.2.0

package/slop-index/proposed/024-repetitive-error-pattern.md

@@ -0,0 +1,76 @@
+---
+id: 024
+name: repetitive-error-pattern
+severity: medium
+languages: [javascript, typescript]
+tags: [error-handling, duplication, maintainability]
+added: 2026-05-20
+---
+
+# Pattern: Repetitive Error Pattern
+
+## Description
+AI generates identical error handling patterns across multiple functions, creating the same try-catch structure with generic error messages and state updates. This leads to code duplication and makes it harder to provide specific error context or handle different error types appropriately.
+
+## What It Looks Like
+```
+const fetchUsers = async () => {
+  try {
+    const response = await api.getUsers();
+    if (response.success) {
+      setUsers(response.data);
+    } else {
+      setError(response.error || 'Failed to fetch users');
+    }
+  } catch (err) {
+    setError(err instanceof Error ? err.message : 'Failed to fetch users');
+  }
+};
+
+const fetchPosts = async () => {
+  try {
+    const response = await api.getPosts();
+    if (response.success) {
+      setPosts(response.data);
+    } else {
+      setError(response.error || 'Failed to fetch posts');
+    }
+  } catch (err) {
+    setError(err instanceof Error ? err.message : 'Failed to fetch posts');
+  }
+};
+```
+
+## Why AI Does This
+AI models learn common error handling patterns and apply them consistently across similar functions. While consistency can be good, the AI doesn't recognize when the repetitive pattern should be abstracted or when different error types need specific handling strategies.
+
+## Catch Signal
+- Multiple functions with identical try-catch structure
+- Same error fallback message pattern repeated
+- Identical error instanceof checks across functions
+- Generic 'Failed to fetch X' messages with only noun changing
+- Same response.success checking pattern duplicated
+
+## Fix Template
+```
+const createAsyncHandler = <T>(operation: string, setter: (data: T) => void) => {
+  return async (apiCall: () => Promise<ApiResponse<T>>) => {
+    try {
+      const response = await apiCall();
+      if (response.success) {
+        setter(response.data);
+      } else {
+        handleApiError(response.error, operation);
+      }
+    } catch (err) {
+      handleUnexpectedError(err, operation);
+    }
+  };
+};
+
+const fetchUsers = createAsyncHandler('fetch users', setUsers);
+const fetchPosts = createAsyncHandler('fetch posts', setPosts);
+```
+
+## Severity Rationale
+medium — Medium severity because it creates maintainability issues and generic error handling but doesn't break functionality.

package/slop-index/proposed/025-environment-specific-fallbacks.md

@@ -0,0 +1,55 @@
+---
+id: 025
+name: environment-specific-fallbacks
+severity: high
+languages: [javascript, typescript]
+tags: [security, configuration, deployment]
+added: 2026-05-21
+---
+
+# Pattern: Environment Specific Fallbacks
+
+## Description
+Production credentials or environment-specific identifiers are hardcoded as fallback values in configuration objects. This creates security risks and deployment coupling where production keys, API endpoints, or database identifiers are embedded directly in source code and used when environment variables are missing.
+
+## What It Looks Like
+```
+const firebaseConfig = {
+  apiKey: process.env.FIREBASE_API_KEY || 'AIzaSyB0uWItoUyaozcnjntgG9kck6GJx84GQNY',
+  projectId: process.env.FIREBASE_PROJECT_ID || 'hardcore-synergy',
+  storageBucket: process.env.FIREBASE_STORAGE_BUCKET || 'hardcore-synergy.firebasestorage.app'
+};
+
+const stripeConfig = {
+  publishableKey: process.env.STRIPE_KEY || 'pk_test_51SrKL12EWDoWzTlbooO1c6Y3k1oMpjc2JAk266LPVK6TGgRPthyf4eeGjhFh6lDGeZEz3YxDxDUhQ4wBcnemfU1v00BKalQrEu'
+};
+```
+
+## Why AI Does This
+AI generates realistic fallback configurations to ensure code appears complete and functional, often using actual credential formats it has seen in training data. It prioritizes making code that 'works out of the box' over proper security practices, and may not fully understand the security implications of embedding production credentials in source code.
+
+## Catch Signal
+- Environment variable checks with || operator followed by real API keys or tokens
+- Fallback values containing actual domain names, project IDs, or service identifiers
+- Configuration objects mixing environment variables with hardcoded production values
+- Real credential patterns (pk_test_, AIzaSy, etc.) used as fallback strings
+- Production service URLs or identifiers as string literals in fallbacks
+
+## Fix Template
+```
+const firebaseConfig = {
+  apiKey: process.env.FIREBASE_API_KEY || (() => { throw new Error('FIREBASE_API_KEY environment variable is required') })(),
+  projectId: process.env.FIREBASE_PROJECT_ID || (() => { throw new Error('FIREBASE_PROJECT_ID environment variable is required') })(),
+  storageBucket: process.env.FIREBASE_STORAGE_BUCKET || (() => { throw new Error('FIREBASE_STORAGE_BUCKET environment variable is required') })()
+};
+
+// Or use a validation function
+function requireEnv(key: string): string {
+  const value = process.env[key];
+  if (!value) throw new Error(`${key} environment variable is required`);
+  return value;
+}
+```
+
+## Severity Rationale
+high — Exposes production credentials and creates security vulnerabilities that could lead to unauthorized access to services.

package/slop-index/proposed/026-emoji-production-logs.md

@@ -0,0 +1,46 @@
+---
+id: 026
+name: emoji-production-logs
+severity: medium
+languages: [javascript, typescript, python, shell]
+tags: [logging, production, professionalism]
+added: 2026-05-21
+---
+
+# Pattern: Emoji Production Logs
+
+## Description
+Console output and log messages in production scripts contain emoji characters for visual decoration or status indication. This creates unprofessional logs, can cause encoding issues in different environments or log aggregation systems, and makes log parsing more difficult for monitoring tools.
+
+## What It Looks Like
+```
+console.log('🔥 Firebase Config Debug:');
+console.log('✓ Firebase app initialized:', app.name);
+console.log('🔍 Finding "Sweat Starter Test 1" program...');
+console.log('✅ Successfully populated program!');
+console.error('❌ Program not found');
+console.log('🔑 Loading Stripe with key:', key);
+```
+
+## Why AI Does This
+AI adds emoji to make console output more visually appealing and user-friendly, treating console logs like user interface elements. It mimics modern development practices where emoji are common in commit messages and informal communication, but doesn't distinguish between development debugging and production logging contexts.
+
+## Catch Signal
+- Console.log statements with emoji characters (🔥, ✅, ❌, 🔍, etc.)
+- Status indicators using emoji instead of text in production scripts
+- Emoji used in error messages or success confirmations in logs
+- Script output containing Unicode emoji characters
+- Log messages that prioritize visual appeal over machine readability
+
+## Fix Template
+```
+console.log('Firebase Config Debug:');
+console.log('Firebase app initialized:', app.name);
+console.log('Finding "Sweat Starter Test 1" program...');
+console.log('SUCCESS: Successfully populated program!');
+console.error('ERROR: Program not found');
+console.log('Loading Stripe with key:', key.substring(0, 20) + '...');
+```
+
+## Severity Rationale
+medium — Creates unprofessional output and potential encoding issues but doesn't break functionality.

package/slop-index/proposed/027-credentials-in-debug-logs.md

@@ -0,0 +1,48 @@
+---
+id: 027
+name: credentials-in-debug-logs
+severity: high
+languages: [javascript, typescript]
+tags: [security, logging, credentials]
+added: 2026-05-21
+---
+
+# Pattern: Credentials In Debug Logs
+
+## Description
+Debug console statements log sensitive credentials, API keys, or configuration values that should never appear in production logs. Even when credentials are meant to be semi-public (like Stripe publishable keys), logging them creates unnecessary exposure and security risks.
+
+## What It Looks Like
+```
+console.log('🔑 Loading Stripe with key:', STRIPE_PUBLISHABLE_KEY);
+console.log('🔑 Full key (for debugging):', STRIPE_PUBLISHABLE_KEY);
+console.log('Firebase Config:', {
+  apiKey: firebaseConfig.apiKey,
+  authDomain: firebaseConfig.authDomain,
+  projectId: firebaseConfig.projectId
+});
+```
+
+## Why AI Does This
+AI treats all configuration as debugging information and logs it to help with troubleshooting, without understanding the security implications. It may not distinguish between public configuration (like project IDs) and sensitive credentials, or understand that even 'public' keys shouldn't be logged in production systems.
+
+## Catch Signal
+- Console.log statements that output API keys, tokens, or credentials
+- Debug logging that includes full configuration objects with sensitive data
+- Credential values being logged even when partially masked elsewhere
+- Environment variables or secrets being output to console for debugging
+- Configuration validation that logs actual credential values instead of just presence checks
+
+## Fix Template
+```
+console.log('Loading Stripe with key:', STRIPE_PUBLISHABLE_KEY.substring(0, 20) + '...');
+console.log('Stripe key configured:', STRIPE_PUBLISHABLE_KEY ? 'YES' : 'NO');
+console.log('Firebase Config Status:', {
+  apiKey: firebaseConfig.apiKey ? 'CONFIGURED' : 'MISSING',
+  authDomain: firebaseConfig.authDomain ? 'CONFIGURED' : 'MISSING',
+  projectId: firebaseConfig.projectId // Project ID is safe to log
+});
+```
+
+## Severity Rationale
+high — Exposes sensitive credentials in logs which could be accessed by unauthorized parties or stored insecurely.

package/slop-index/proposed/028-repetitive-service-wrappers.md

@@ -0,0 +1,59 @@
+---
+id: 028
+name: repetitive-service-wrappers
+severity: low
+languages: [javascript, typescript]
+tags: [abstraction, duplication, maintenance]
+added: 2026-05-21
+---
+
+# Pattern: Repetitive Service Wrappers
+
+## Description
+Multiple nearly identical wrapper functions that perform the same initialization steps and return configured service instances. Each function follows the exact same pattern with only the final service name parameter changing, creating unnecessary code duplication and maintenance overhead.
+
+## What It Looks Like
+```
+const getCreateJobFn = () => {
+  ensureFirebaseReady();
+  const functions = getFunctions(app, 'us-central1');
+  return httpsCallable(functions, 'createJob');
+};
+const getUpdateJobFn = () => {
+  ensureFirebaseReady();
+  const functions = getFunctions(app, 'us-central1');
+  return httpsCallable(functions, 'updateJob');
+};
+const getDeleteJobFn = () => {
+  ensureFirebaseReady();
+  const functions = getFunctions(app, 'us-central1');
+  return httpsCallable(functions, 'deleteJob');
+};
+```
+
+## Why AI Does This
+AI creates individual wrapper functions for each service method to maintain clear separation and explicit naming, following patterns it has learned about creating dedicated functions for each API endpoint. It prioritizes explicit, readable function names over DRY principles, and may not recognize when the pattern repetition creates maintenance burden.
+
+## Catch Signal
+- Multiple functions with identical structure but different final parameter
+- Wrapper functions that only change the last argument to a service call
+- Repeated initialization code across multiple service wrapper functions
+- Functions that follow the exact same pattern with only string literals differing
+- Service wrappers that are used exactly once and provide no additional logic
+
+## Fix Template
+```
+function createFirebaseFunction(functionName: string) {
+  ensureFirebaseReady();
+  const functions = getFunctions(app, 'us-central1');
+  return httpsCallable(functions, functionName);
+}
+
+// Usage
+const createJob = createFirebaseFunction('createJob');
+const updateJob = createFirebaseFunction('updateJob');
+const deleteJob = createFirebaseFunction('deleteJob');
+```
+
+## Severity Rationale
+low — Creates code duplication and maintenance overhead but doesn't impact functionality or security.

package/slop-index/proposed/029-forced-non-null-assertions.md

@@ -0,0 +1,59 @@
+---
+id: 029
+name: forced-non-null-assertions
+severity: medium
+languages: [typescript]
+tags: [type-safety, runtime-errors, null-safety]
+added: 2026-05-21
+---
+
+# Pattern: Forced Non Null Assertions
+
+## Description
+Non-null assertion operators (!) are used to bypass TypeScript's null safety checks without proper validation, creating potential runtime errors. The code assumes properties exist after checking parent objects, but doesn't verify the properties themselves are non-null.
+
+## What It Looks Like
+```
+const stats = {
+  weightChange: latestEntry && previousEntry
+    ? latestEntry.weight! - previousEntry.weight!
+    : 0,
+  totalChange: latestEntry && firstEntry
+    ? latestEntry.weight! - firstEntry.weight!
+    : 0,
+};
+
+// Usage without checking if user exists
+const profileUrl = user!.profile!.avatar!.url;
+```
+
+## Why AI Does This
+AI uses non-null assertions to quickly resolve TypeScript compilation errors without fully understanding the runtime implications. It sees that parent objects are checked for existence and assumes their properties must also exist, not recognizing that optional properties can be undefined even when the parent object exists.
+
+## Catch Signal
+- Non-null assertion operator (!) used on optional properties
+- Force unwrapping without corresponding null checks for the specific property
+- Assertions used to bypass TypeScript errors rather than handle null cases
+- Multiple chained non-null assertions on nested optional properties
+- Assumptions about property existence based only on parent object existence
+
+## Fix Template
+```
+const stats = {
+  weightChange: latestEntry?.weight && previousEntry?.weight
+    ? latestEntry.weight - previousEntry.weight
+    : 0,
+  totalChange: latestEntry?.weight && firstEntry?.weight
+    ? latestEntry.weight - firstEntry.weight
+    : 0,
+};
+
+// Or with proper validation
+function getWeightChange(latest: Entry | null, previous: Entry | null): number {
+  if (!latest?.weight || !previous?.weight) return 0;
+  return latest.weight - previous.weight;
+}
+```
+
+## Severity Rationale
+medium — Can cause runtime errors and defeats TypeScript's null safety benefits, but issues are typically caught during testing.

package/slop-index/proposed/030-production-credential-fallbacks.md

@@ -0,0 +1,51 @@
+---
+id: 030
+name: production-credential-fallbacks
+severity: high
+languages: [javascript, typescript]
+tags: [security, credentials, environment]
+added: 2026-05-21
+---
+
+# Pattern: Production Credential Fallbacks
+
+## Description
+Real production credentials, API keys, and service configuration values are hardcoded as fallback values when environment variables are missing. This creates security vulnerabilities and environment coupling, as production secrets become embedded in source code that could be exposed in version control or client-side builds.
+
+## What It Looks Like
+```
+const STRIPE_KEY = process.env.STRIPE_KEY || 'pk_live_51SrKL12EWDoWzTlbooO1c6Y3k1oMpjc2JAk266LPVK6TGgRPthyf4eeGjhFh6lDGeZEz3YxDxDUhQ4wBcnemfU1v00BKalQrEu';
+const firebaseConfig = {
+  apiKey: process.env.FIREBASE_API_KEY || 'AIzaSyB0uWItoUyaozcnjntgG9kck6GJx84GQNY',
+  projectId: process.env.FIREBASE_PROJECT_ID || 'my-production-app'
+};
+```
+
+## Why AI Does This
+AI models generate fallback values to ensure code runs immediately without configuration errors, and they often use realistic-looking credentials from training data or generate plausible keys. They prioritize functional completeness over security best practices, creating working examples that inadvertently embed real or realistic production credentials.
+
+## Catch Signal
+- Real API keys or tokens in fallback values after || operator
+- Production service URLs or project IDs as default values
+- Environment variable patterns with actual credentials as fallbacks
+- Firebase, Stripe, AWS, or other service credentials hardcoded
+- Realistic-looking keys with proper prefixes (pk_, sk_, AIzaSy, etc.)
+
+## Fix Template
+```
+const STRIPE_KEY = process.env.STRIPE_KEY;
+if (!STRIPE_KEY) {
+  throw new Error('STRIPE_KEY environment variable is required');
+}
+
+const firebaseConfig = {
+  apiKey: process.env.FIREBASE_API_KEY || '',
+  projectId: process.env.FIREBASE_PROJECT_ID || 'development-project'
+};
+if (!firebaseConfig.apiKey) {
+  throw new Error('Firebase configuration incomplete');
+}
+```
+
+## Severity Rationale
+high — Exposes real production credentials in source code, creating immediate security vulnerabilities.

package/slop-index/proposed/031-fake-version-confidence.md

@@ -0,0 +1,50 @@
+---
+id: 031
+name: fake-version-confidence
+severity: medium
+languages: [javascript, typescript, html]
+tags: [dependencies, versioning, cdn]
+added: 2026-05-21
+---
+
+# Pattern: Fake Version Confidence
+
+## Description
+Code confidently references specific version numbers of libraries or CDN resources that don't exist, such as Firebase 12.8.0 or other non-existent versions. AI generates plausible but incorrect version numbers, creating import failures and broken dependencies that won't be caught until runtime.
+
+## What It Looks Like
+```
+import { initializeApp } from 'https://www.gstatic.com/firebasejs/12.8.0/firebase-app.js';
+// Firebase v12 doesn't exist - current is v10.x
+
+<script src="https://cdnjs.cloudflare.com/ajax/libs/react/19.4.2/react.min.js"></script>
+<!-- React 19.4.2 doesn't exist -->
+
+const stripe = require('stripe')('^5.2.8');
+// Assumes version exists without verification
+```
+
+## Why AI Does This
+AI models extrapolate version numbering patterns from training data without understanding actual release cycles or semantic versioning constraints. They generate plausible-looking version numbers that follow expected patterns but don't correspond to real releases, prioritizing code completeness over accuracy.
+
+## Catch Signal
+- CDN URLs with non-existent version numbers
+- Import statements referencing impossible version combinations
+- Version numbers that don't follow project's actual release pattern
+- Future versions or versions higher than latest release
+- Mixing of incompatible version ranges across dependencies
+
+## Fix Template
+```
+import { initializeApp } from 'https://www.gstatic.com/firebasejs/10.7.1/firebase-app.js';
+// Use actual current version
+
+<script src="https://cdnjs.cloudflare.com/ajax/libs/react/18.2.0/react.min.js"></script>
+<!-- Verify version exists before using -->
+
+const stripe = require('stripe')('3.10.0');
+// Check actual available versions
+```
+
+## Severity Rationale
+medium — Causes import failures and broken builds, but can be easily detected and fixed during development.

package/slop-index/proposed/032-forced-non-null-assertions.md

@@ -0,0 +1,53 @@
+---
+id: 032
+name: forced-non-null-assertions
+severity: medium
+languages: [typescript]
+tags: [typescript, null-safety, runtime-errors]
+added: 2026-05-21
+---
+
+# Pattern: Forced Non Null Assertions
+
+## Description
+Excessive use of TypeScript's non-null assertion operator (!) to bypass type checking without proper null/undefined validation, often in contexts where the value could legitimately be null or undefined. This defeats TypeScript's null safety and creates potential runtime errors.
+
+## What It Looks Like
+```
+const user = users.find(u => u.id === targetId);
+const profile = user!.profile; // user could be undefined
+
+const weight = latestEntry?.weight;
+const change = weight! - previousWeight!; // weights could be null
+
+const element = document.getElementById('myId');
+element!.addEventListener('click', handler); // element could be null
+```
+
+## Why AI Does This
+AI models use non-null assertions as a quick way to resolve TypeScript compilation errors without implementing proper null checking logic. They prioritize making code compile over ensuring runtime safety, treating the ! operator as a simple way to assert confidence in values that the type system correctly identifies as potentially nullable.
+
+## Catch Signal
+- Non-null assertions on array find() or DOM query results
+- Multiple ! operators in arithmetic or property access chains
+- Non-null assertions on optional properties without prior validation
+- Using ! operator immediately after optional chaining (?.) operators
+- Non-null assertions in contexts where null/undefined is a valid state
+
+## Fix Template
+```
+const user = users.find(u => u.id === targetId);
+if (!user) throw new Error('User not found');
+const profile = user.profile;
+
+const weight = latestEntry?.weight;
+const change = (weight && previousWeight) ? weight - previousWeight : 0;
+
+const element = document.getElementById('myId');
+if (element) {
+  element.addEventListener('click', handler);
+}
+```
+
+## Severity Rationale
+medium — Creates potential runtime errors by bypassing type safety, but impact depends on actual null occurrence frequency.

package/slop-index/proposed/033-emoji-production-logs.md

@@ -0,0 +1,44 @@
+---
+id: 033
+name: emoji-production-logs
+severity: low
+languages: [javascript, typescript]
+tags: [logging, professionalism, encoding]
+added: 2026-05-21
+---
+
+# Pattern: Emoji Production Logs
+
+## Description
+Using emoji characters in production logging, console output, and script messages that will appear in production environments. This creates unprofessional output in production logs and can cause encoding issues in different terminal environments or log aggregation systems.
+
+## What It Looks Like
+```
+console.log('🔥 Starting Firebase initialization...');
+console.log('✅ Database connection established');
+console.error('❌ Authentication failed');
+logger.info('🚀 Deployment successful!');
+console.log('🔍 Processing user data...');
+```
+
+## Why AI Does This
+AI models use emojis to make output more visually appealing and user-friendly, drawing from examples in tutorials and development blogs where emojis are used for visual distinction. They don't distinguish between development-friendly output and production logging requirements, treating console messages as user-facing rather than system logs.
+
+## Catch Signal
+- Emoji characters in console.log, console.error, or logger calls
+- Emojis in production scripts or deployment tools
+- Unicode emoji in system messages or status updates
+- Emojis in error messages or success confirmations
+- Visual symbols in logging that aren't standard ASCII
+
+## Fix Template
+```
+console.log('Starting Firebase initialization...');
+console.log('Database connection established');
+console.error('Authentication failed');
+logger.info('Deployment successful!');
+console.log('Processing user data...');
+```
+
+## Severity Rationale
+low — Affects log readability and professionalism but doesn't impact core functionality or security.

package/slop-index/proposed/034-realistic-mock-data-leakage.md

@@ -0,0 +1,62 @@
+---
+id: 034
+name: realistic-mock-data-leakage
+severity: medium
+languages: [javascript, typescript]
+tags: [security, privacy, data]
+added: 2026-05-21
+---
+
+# Pattern: Realistic Mock Data Leakage
+
+## Description
+Mock or example data that appears realistic enough to be mistaken for real user data, including plausible email addresses, phone numbers, addresses, or personal information. While using example.com domains, the realistic nature creates risks of accidental exposure or confusion with real data during development and testing.
+
+## What It Looks Like
+```
+const mockUsers = [
+  {
+    name: 'Emma Wilson',
+    email: 'emma.wilson@example.com',
+    phone: '(555) 123-4567',
+    address: '123 Main St, Springfield, IL 62701',
+    ssn: '123-45-6789'
+  },
+  {
+    name: 'John Smith', 
+    email: 'john.smith@company.com', // not example.com
+    creditCard: '4532-1234-5678-9012'
+  }
+];
+```
+
+## Why AI Does This
+AI models generate realistic-looking data to make examples more relatable and demonstrate proper data structures, often drawing from common names and realistic patterns in training data. They aim to create convincing examples that help developers understand data flow, but don't consider the risks of realistic personal information in codebases.
+
+## Catch Signal
+- Realistic personal names combined with contact information
+- Plausible addresses, phone numbers, or identification numbers
+- Credit card numbers or financial information in mock data
+- Email addresses not using example.com or test domains
+- Mock data that could be mistaken for real customer information
+
+## Fix Template
+```
+const mockUsers = [
+  {
+    name: 'Test User 1',
+    email: 'testuser1@example.com',
+    phone: '000-000-0000',
+    address: '123 Test St, Test City, TS 00000',
+    id: 'mock-user-1'
+  },
+  {
+    name: 'Sample User',
+    email: 'sample@example.com',
+    id: 'mock-user-2'
+  }
+];
+```
+
+## Severity Rationale
+medium — Could lead to privacy concerns or confusion with real data, but typically doesn't affect core application security.

package/slop-index/proposed/035-production-credential-exposure.md

@@ -0,0 +1,43 @@
+---
+id: 035
+name: production-credential-exposure
+severity: high
+languages: [javascript, typescript]
+tags: [security, credentials, production]
+added: 2026-05-21
+---
+
+# Pattern: Production Credential Exposure
+
+## Description
+AI generates code that explicitly logs or exposes credentials and API keys in production environments, often with debugging statements that print full keys or configuration details to console logs where they can be harvested by attackers or leaked in log aggregation systems.
+
+## What It Looks Like
+```
+console.log('🔑 Full key (for debugging):', STRIPE_PUBLISHABLE_KEY);
+console.log('Firebase Config Debug:');
+console.log('  - API Key:', firebaseConfig.apiKey);
+console.log('  - Auth Domain:', firebaseConfig.authDomain);
+```
+
+## Why AI Does This
+AI models generate debugging code to help developers verify configuration without understanding the security implications of logging credentials in production. They treat all configuration as equally safe to log and don't distinguish between public and private data.
+
+## Catch Signal
+- console.log statements containing API keys or tokens
+- Full credential values being printed to logs
+- Configuration objects logged with sensitive fields
+- Debug statements that expose authentication details
+- Production code that prints environment variables
+
+## Fix Template
+```
+// Log only non-sensitive configuration details
+console.log('🔑 Stripe key configured:', STRIPE_PUBLISHABLE_KEY ? '✓' : '✗');
+console.log('Firebase Config Status:');
+console.log('  - API Key:', firebaseConfig.apiKey ? '✓ Set' : '✗ MISSING');
+console.log('  - Project ID:', firebaseConfig.projectId); // Project ID is public
+```
+
+## Severity Rationale
+high — High severity because credential exposure creates immediate security vulnerabilities that can be exploited by attackers.