@reidbuilds/slop 0.2.0

package/slop-index/proposed/036-identical-wrapper-proliferation.md

@@ -0,0 +1,53 @@
+---
+id: 036
+name: identical-wrapper-proliferation
+severity: medium
+languages: [javascript, typescript]
+tags: [abstraction, duplication, code-quality]
+added: 2026-05-21
+---
+
+# Pattern: Identical Wrapper Proliferation
+
+## Description
+AI creates multiple nearly identical wrapper functions that perform the same initialization steps but call different underlying functions, resulting in repetitive boilerplate code instead of a single parameterized function that could handle all cases.
+
+## 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');
+};
+```
+
+## Why AI Does This
+AI models generate wrapper functions by following a template pattern without recognizing that the repetitive structure indicates a need for parameterization. They create one-to-one mappings between wrapper functions and underlying functions instead of abstracting the common pattern.
+
+## Catch Signal
+- Multiple functions with identical structure except for one parameter
+- Repeated initialization code across similar functions
+- Wrapper functions that are each used exactly once
+- Functions that differ only in a string literal parameter
+- Identical error handling or setup logic duplicated
+
+## Fix Template
+```
+const getCallableFn = (functionName: string) => {
+  ensureFirebaseReady();
+  const functions = getFunctions(app, 'us-central1');
+  return httpsCallable(functions, functionName);
+};
+
+// Usage:
+const createJob = await getCallableFn('createJob')(data);
+const updateJob = await getCallableFn('updateJob')(data);
+```
+
+## Severity Rationale
+medium — Medium severity as it creates maintenance burden and code bloat but doesn't affect functionality or security.

package/slop-index/proposed/037-forced-null-assertions.md

@@ -0,0 +1,50 @@
+---
+id: 037
+name: forced-null-assertions
+severity: high
+languages: [typescript]
+tags: [type-safety, runtime-errors, null-safety]
+added: 2026-05-21
+---
+
+# Pattern: Forced Null Assertions
+
+## Description
+AI uses TypeScript's non-null assertion operator (!) to bypass type checking on potentially null or undefined values without proper validation, creating runtime errors when the assumed non-null values are actually null or undefined.
+
+## What It Looks Like
+```
+const stats = {
+  weightChange: latestEntry && previousEntry
+    ? latestEntry.weight! - previousEntry.weight!
+    : 0,
+  totalChange: latestEntry && firstEntry
+    ? latestEntry.weight! - firstEntry.weight!
+    : 0,
+};
+```
+
+## Why AI Does This
+AI models use non-null assertions as a quick way to satisfy TypeScript's type checker without implementing proper null checking. They assume that if an object exists, all its properties must also exist, ignoring the possibility that properties themselves could be null or undefined.
+
+## Catch Signal
+- Non-null assertion operator (!) used on optional properties
+- Force unwrapping without preceding null checks
+- Assertions on properties that could be undefined
+- Using ! operator in calculations or operations
+- Bypassing TypeScript warnings with assertions instead of proper validation
+
+## Fix Template
+```
+const stats = {
+  weightChange: latestEntry?.weight && previousEntry?.weight
+    ? latestEntry.weight - previousEntry.weight
+    : 0,
+  totalChange: latestEntry?.weight && firstEntry?.weight
+    ? latestEntry.weight - firstEntry.weight
+    : 0,
+};
+```
+
+## Severity Rationale
+high — High severity because forced assertions can cause runtime errors and crashes when null values are encountered.

package/slop-index/proposed/038-emoji-production-logging.md

@@ -0,0 +1,42 @@
+---
+id: 038
+name: emoji-production-logging
+severity: low
+languages: [javascript, typescript]
+tags: [professionalism, logging, production]
+added: 2026-05-21
+---
+
+# Pattern: Emoji Production Logging
+
+## Description
+AI includes emoji characters in production console output, creating unprofessional logs that can cause encoding issues in different environments and make log parsing more difficult for automated systems.
+
+## What It Looks Like
+```
+console.log('✅ Successfully populated program!');
+console.log('🔍 Finding program...');
+console.log('❌ Program not found');
+console.log('🔑 Loading Stripe with key...');
+```
+
+## Why AI Does This
+AI models use emojis to make console output more visually appealing and easier to read during development, without considering that these characters are inappropriate for production logging systems and can cause encoding or parsing issues.
+
+## Catch Signal
+- Console.log statements containing emoji characters
+- Success/failure messages with emoji symbols
+- Progress indicators using emoji in production scripts
+- Debug output decorated with emoji characters
+- Production logging with visual emoji indicators
+
+## Fix Template
+```
+console.log('[SUCCESS] Successfully populated program!');
+console.log('[INFO] Finding program...');
+console.log('[ERROR] Program not found');
+console.log('[DEBUG] Loading Stripe configuration...');
+```
+
+## Severity Rationale
+low — Low severity as it affects professionalism and log parsing but doesn't impact core functionality or security.

package/slop-index/proposed/039-fake-delay-operations.md

@@ -0,0 +1,52 @@
+---
+id: 039
+name: fake-delay-operations
+severity: medium
+languages: [javascript, typescript]
+tags: [fake-async, user-experience, misleading]
+added: 2026-05-21
+---
+
+# Pattern: Fake Delay Operations
+
+## Description
+AI creates artificial delays using setTimeout in production code to simulate processing time or create the illusion of work being performed, misleading users about system behavior and creating unnecessary latency.
+
+## What It Looks Like
+```
+const handleSave = async () => {
+  setSaving(true);
+  // TODO: Implement actual save
+  await new Promise(resolve => setTimeout(resolve, 1000));
+  setSaving(false);
+  navigate('/dashboard');
+};
+```
+
+## Why AI Does This
+AI models add artificial delays to make user interfaces feel more realistic or to simulate the expected duration of operations, without understanding that fake delays mislead users and create poor user experience when no actual work is being performed.
+
+## Catch Signal
+- setTimeout with hardcoded delays in async functions
+- Fake loading states with artificial wait times
+- Promise.resolve with setTimeout to simulate async work
+- Arbitrary delays before navigation or state changes
+- Hardcoded timeouts that don't correspond to real operations
+
+## Fix Template
+```
+const handleSave = async () => {
+  setSaving(true);
+  try {
+    await saveUserSettings(settings);
+    navigate('/dashboard');
+  } catch (error) {
+    setError('Failed to save settings');
+  } finally {
+    setSaving(false);
+  }
+};
+```
+
+## Severity Rationale
+medium — Medium severity because it degrades user experience and can mask the absence of actual functionality.

package/slop-index/proposed/040-forced-null-assertion-chains.md

@@ -0,0 +1,45 @@
+---
+id: 040
+name: forced-null-assertion-chains
+severity: high
+languages: [typescript]
+tags: [type-safety, runtime-errors, null-safety]
+added: 2026-05-21
+---
+
+# Pattern: Forced Null Assertion Chains
+
+## Description
+Code uses multiple non-null assertion operators (!) in chains or calculations without proper null checks, creating potential runtime errors. This pattern assumes nested properties exist when TypeScript's type system indicates they might be undefined.
+
+## What It Looks Like
+```
+const weightChange = latestEntry && previousEntry
+  ? latestEntry.weight! - previousEntry.weight!
+  : 0;
+const totalChange = latestEntry && firstEntry
+  ? latestEntry.weight! - firstEntry.weight!
+  : 0;
+```
+
+## Why AI Does This
+AI models see the logical check for object existence (latestEntry && previousEntry) and assume this validates all nested properties, not understanding that weight could still be null/undefined even if the parent object exists. They use the non-null assertion as a quick way to satisfy TypeScript's compiler without implementing proper null safety.
+
+## Catch Signal
+- Multiple ! operators in calculations or property access
+- Non-null assertions after basic object existence checks
+- Forced unwrapping in mathematical operations
+- ! operator used on optional properties from interfaces
+
+## Fix Template
+```
+const weightChange = latestEntry?.weight && previousEntry?.weight
+  ? latestEntry.weight - previousEntry.weight
+  : 0;
+const totalChange = latestEntry?.weight && firstEntry?.weight
+  ? latestEntry.weight - firstEntry.weight
+  : 0;
+```
+
+## Severity Rationale
+high — Runtime crashes are likely when assumed properties are null/undefined.

package/slop-index/proposed/041-production-debug-configuration.md

@@ -0,0 +1,45 @@
+---
+id: 041
+name: production-debug-configuration
+severity: medium
+languages: [javascript, typescript]
+tags: [debugging, configuration, production-safety]
+added: 2026-05-21
+---
+
+# Pattern: Production Debug Configuration
+
+## Description
+Code contains detailed configuration debugging statements that log internal system details, API keys, or environment variables to the console in production. These logs expose internal architecture and potentially sensitive configuration details while cluttering production logs.
+
+## What It Looks Like
+```
+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);
+```
+
+## Why AI Does This
+AI generates comprehensive debugging output to help developers verify configuration during development, but fails to distinguish between development debugging and production-ready code. It treats configuration validation as always beneficial without considering the security and operational implications of verbose logging in production.
+
+## Catch Signal
+- Console statements logging configuration objects or keys
+- Debug messages that reveal internal system architecture
+- Configuration validation logs with detailed output
+- Emojis or detailed formatting in configuration logging
+
+## Fix Template
+```
+if (process.env.NODE_ENV === 'development') {
+  console.log('Firebase Config Debug:', {
+    apiKeySet: !!firebaseConfig.apiKey,
+    authDomain: firebaseConfig.authDomain,
+    projectId: firebaseConfig.projectId
+  });
+}
+```
+
+## Severity Rationale
+medium — Exposes internal architecture and may leak sensitive configuration in production logs.

package/slop-index/proposed/042-repetitive-firebase-wrappers.md

@@ -0,0 +1,51 @@
+---
+id: 042
+name: repetitive-firebase-wrappers
+severity: low
+languages: [javascript, typescript]
+tags: [abstraction, duplication, firebase]
+added: 2026-05-21
+---
+
+# Pattern: Repetitive Firebase Wrappers
+
+## Description
+Code creates multiple identical wrapper functions for Firebase Cloud Functions that only differ by the function name parameter. Each wrapper performs the same initialization steps and returns httpsCallable, adding unnecessary indirection without reducing complexity.
+
+## What It Looks Like
+```
+const getCreateCustomerFn = () => {
+  ensureFirebaseReady();
+  const functions = getFunctions(app, 'us-central1');
+  return httpsCallable(functions, 'createCustomer');
+};
+const getUpdateCustomerFn = () => {
+  ensureFirebaseReady();
+  const functions = getFunctions(app, 'us-central1');
+  return httpsCallable(functions, 'updateCustomer');
+};
+```
+
+## Why AI Does This
+AI models often create wrapper functions for consistency and to encapsulate initialization logic, not recognizing when the abstraction adds no value. They generate similar patterns repeatedly without identifying opportunities to create a single parameterized function that handles the common behavior.
+
+## Catch Signal
+- Multiple functions with identical structure differing only by string parameter
+- Repeated Firebase getFunctions and httpsCallable patterns
+- Wrapper functions used exactly once
+- ensureFirebaseReady() called in multiple similar functions
+
+## Fix Template
+```
+const createFirebaseFunction = (functionName: string) => {
+  ensureFirebaseReady();
+  const functions = getFunctions(app, 'us-central1');
+  return httpsCallable(functions, functionName);
+};
+
+export const createCustomer = (data: any) => createFirebaseFunction('createCustomer')(data);
+export const updateCustomer = (data: any) => createFirebaseFunction('updateCustomer')(data);
+```
+
+## Severity Rationale
+low — Creates unnecessary code duplication but doesn't impact functionality or security.

package/slop-index/proposed/043-hardcoded-process-timeouts.md

@@ -0,0 +1,48 @@
+---
+id: 043
+name: hardcoded-process-timeouts
+severity: medium
+languages: [javascript, typescript]
+tags: [reliability, hardcoded-values, process-management]
+added: 2026-05-21
+---
+
+# Pattern: Hardcoded Process Timeouts
+
+## Description
+Scripts use hardcoded setTimeout calls to terminate processes or simulate completion, creating unreliable execution that may cut off operations mid-execution. This pattern assumes operations will complete within arbitrary time limits rather than waiting for actual completion.
+
+## What It Looks Like
+```
+// Perform database operations
+await updateFirestoreData();
+
+// Exit after arbitrary delay
+setTimeout(function() { 
+  process.exit(0); 
+}, 5000);
+```
+
+## Why AI Does This
+AI models generate timeouts as a safety mechanism to prevent scripts from hanging indefinitely, but don't understand how to properly wait for async operations to complete. They use arbitrary delays as a simple solution without implementing proper completion detection or error handling.
+
+## Catch Signal
+- setTimeout with process.exit() calls
+- Hardcoded delays before script termination
+- Magic number timeouts in deployment or setup scripts
+- No actual completion verification before timeout
+
+## Fix Template
+```
+try {
+  await updateFirestoreData();
+  console.log('✅ Operation completed successfully');
+  process.exit(0);
+} catch (error) {
+  console.error('❌ Operation failed:', error);
+  process.exit(1);
+}
+```
+
+## Severity Rationale
+medium — Can cause data corruption or incomplete operations in production environments.

package/slop-index/proposed/044-fictional-package-versions.md

@@ -0,0 +1,37 @@
+---
+id: 044
+name: fictional-package-versions
+severity: high
+languages: [javascript, typescript]
+tags: [dependencies, versioning, imports]
+added: 2026-05-21
+---
+
+# Pattern: Fictional Package Versions
+
+## Description
+Code imports from specific package versions that don't exist, such as Firebase 12.8.0 when the package never released that version. This creates import failures and suggests AI generated version numbers without understanding actual package release histories.
+
+## What It Looks Like
+```
+import { initializeApp } from "https://www.gstatic.com/firebasejs/12.8.0/firebase-app.js";
+import { getFirestore } from "https://www.gstatic.com/firebasejs/12.8.0/firebase-firestore.js";
+```
+
+## Why AI Does This
+AI models generate version numbers that follow semantic versioning patterns but don't verify against actual package registries or release histories. They may extrapolate from training data or generate plausible-looking versions without understanding the specific versioning schemes used by different packages.
+
+## Catch Signal
+- Version numbers that don't exist in package registries
+- Major version jumps that skip actual releases
+- Inconsistent versioning patterns for well-known packages
+- CDN imports with non-existent version paths
+
+## Fix Template
+```
+import { initializeApp } from "https://www.gstatic.com/firebasejs/10.7.1/firebase-app.js";
+import { getFirestore } from "https://www.gstatic.com/firebasejs/10.7.1/firebase-firestore.js";
+```
+
+## Severity Rationale
+high — Causes immediate import failures and prevents application from running.

package/test-sample.js

@@ -0,0 +1,89 @@
+import React, { useState, useEffect, useCallback, useMemo } from 'react'
+import { formatCurrency, formatPhone, formatDate } from 'lodash'
+import { useAsyncHandler } from 'react-use-async'
+import axios from 'axios'
+
+const API_URL = 'https://api.myapp.com/v1'
+const SECRET_KEY = 'sk_live_abc123xyz987'
+
+class DataProcessorRegistry {
+  constructor() {
+    this.processors = new Map()
+  }
+  register(name, processor) {
+    this.processors.set(name, processor)
+  }
+  get(name) {
+    return this.processors.get(name)
+  }
+}
+
+class UserDataProcessor {
+  constructor() {}
+  process(data) {
+    return data
+  }
+}
+
+const registry = new DataProcessorRegistry()
+registry.register('user', new UserDataProcessor())
+
+async function loadDashboard(userId) {
+  // Get the user
+  const user = await getUser(userId)
+  // Get the orders
+  const orders = await getOrders(userId)
+  // Get the notifications
+  const notifications = await getNotifications(userId)
+  // Return the result
+  return { user, orders, notifications }
+}
+
+async function processOrder(orderId) {
+  try {
+    const data = await fetchOrder(orderId)
+    console.log('order data:', data)
+    const result = await validateOrder(data)
+    console.log('validation result:', result)
+    const temp = await chargeCard(data.paymentMethod, SECRET_KEY)
+    console.log('HERE')
+    console.log('charge result:', temp)
+    const final = await fulfillOrder(data)
+    return { success: true }
+  } catch (error) {
+    console.error('Something went wrong:', error)
+    return { success: false }
+  }
+}
+
+function calculateShippingRate(order, destination) {
+  try {
+    // TODO: implement actual shipping calculation
+    const rate = 0
+    return { success: true, rate, estimatedDays: 5 }
+  } catch (error) {
+    return { success: false }
+  }
+}
+
+function addItemToList(list, item) {
+  list.push(item)
+  return list
+}
+
+export default function Dashboard({ userId }) {
+  const [data, setData] = useState(null)
+  const [result, setResult] = useState(null)
+
+  useEffect(async () => {
+    const data = await loadDashboard(userId)
+    setData(data)
+  }, [userId])
+
+  // Return the JSX
+  return (
+    <div>
+      <h1>Dashboard</h1>
+    </div>
+  )
+}