@reidbuilds/slop 0.2.0

package/slop-index/patterns/001-hallucinated-imports.md

@@ -0,0 +1,39 @@
+---
+id: 001
+name: hallucinated-imports
+severity: high
+languages: [javascript, typescript, python]
+tags: [imports, runtime-error]
+added: 2024-01-01
+---
+
+# Pattern: Hallucinated Imports
+
+## Description
+AI generates import statements for packages or named exports that do not exist, using names that plausibly sound like they should.
+
+## What It Looks Like
+```js
+import { useAsyncCallback } from 'react-use-async'
+import { formatCurrency } from 'lodash'
+from utils import smart_retry
+```
+
+## Why AI Does This
+Training data contains thousands of similar-looking import patterns. The model autocompletes the most statistically likely package name without verifying it exists or that the named export is part of that package's actual API surface.
+
+## Catch Signal
+- Package name almost-matches a real one with subtle differences
+- Named export doesn't appear in the package's documented API
+- Package exists but the specific export was removed in a major version
+- Utility functions imported from general-purpose libraries that don't include them (e.g. `formatCurrency` from lodash)
+
+## Fix Template
+```js
+// Verify on npm before trusting. Replace with:
+import { useAsync } from 'react-async'        // verified equivalent
+// OR remove and use built-in alternatives
+```
+
+## Severity Rationale
+High — fails immediately at runtime with a module not found or undefined export error. No graceful degradation.

package/slop-index/patterns/002-comment-restatement.md

@@ -0,0 +1,53 @@
+---
+id: 002
+name: comment-restatement
+severity: low
+languages: [all]
+tags: [readability, comments]
+added: 2024-01-01
+---
+
+# Pattern: Comment Restatement
+
+## Description
+Comments that simply translate the code into English, adding no context, intent, or reasoning that isn't already obvious from reading the code itself.
+
+## What It Looks Like
+```js
+// Loop through users
+for (const user of users) {
+  // Check if user is active
+  if (user.isActive) {
+    // Add user to result array
+    result.push(user)
+  }
+}
+
+// Return the result
+return result
+```
+
+## Why AI Does This
+AI is trained to produce "well-commented" code. Without understanding what constitutes a useful comment, it defaults to narrating every line — which satisfies the surface pattern of commented code without providing actual value.
+
+## Catch Signal
+- Comment is a direct English translation of the line(s) below it
+- Comment contains no information about WHY, only WHAT
+- Removing the comment would lose zero information for any developer who can read the language
+- Phrases like "// Check if", "// Loop through", "// Return the", "// Set the"
+
+## Fix Template
+```js
+// Comments should explain intent, not mechanics:
+
+// Exclude suspended accounts from billing cycle
+for (const user of users) {
+  if (user.isActive) {
+    result.push(user)
+  }
+}
+return result
+```
+
+## Severity Rationale
+Low — doesn't break anything but adds noise, signals AI generation, and trains junior devs to write bad comments.

package/slop-index/patterns/003-unnecessary-abstraction.md

@@ -0,0 +1,56 @@
+---
+id: 003
+name: unnecessary-abstraction
+severity: medium
+languages: [all]
+tags: [architecture, readability, over-engineering]
+added: 2024-01-01
+---
+
+# Pattern: Unnecessary Abstraction
+
+## Description
+AI wraps simple, single-use logic in helper functions, classes, or utilities that will never be reused and add indirection without reducing complexity.
+
+## What It Looks Like
+```js
+// AI creates this helper...
+function addItemToArray(array, item) {
+  array.push(item)
+  return array
+}
+
+// ...to use it exactly once
+addItemToArray(results, newUser)
+
+// Or wraps a one-liner fetch in an unnecessary class
+class ApiClient {
+  constructor(baseUrl) { this.baseUrl = baseUrl }
+  async get(endpoint) {
+    return fetch(`${this.baseUrl}${endpoint}`).then(r => r.json())
+  }
+}
+```
+
+## Why AI Does This
+Training data rewards patterns that look "architecturally mature." Abstracting logic into named helpers and classes is a strong signal of professional code, so the model applies it indiscriminately regardless of whether the abstraction carries weight.
+
+## Catch Signal
+- Helper function used exactly once
+- Function body is one or two lines that could inline trivially
+- Class with a single method and no state
+- Abstraction that doesn't reduce parameters, complexity, or repetition
+- Function name is generic rather than domain-specific (`handleData`, `processItem`, `doOperation`)
+
+## Fix Template
+```js
+// Before (unnecessary abstraction):
+function addItemToArray(array, item) { return [...array, item] }
+const results = addItemToArray(results, newUser)
+
+// After (just write it):
+results.push(newUser)
+```
+
+## Severity Rationale
+Medium — doesn't break at runtime but actively degrades maintainability. Future developers chase function definitions expecting complexity they won't find.

package/slop-index/patterns/004-unused-imports.md

@@ -0,0 +1,41 @@
+---
+id: 004
+name: unused-imports
+severity: low
+languages: [javascript, typescript, python]
+tags: [imports, readability, bundle-size]
+added: 2024-01-01
+---
+
+# Pattern: Unused Imports
+
+## Description
+Import statements for modules, functions, or types that are never referenced in the file body. Often leftovers from a generation that pivoted mid-way.
+
+## What It Looks Like
+```js
+import React, { useState, useEffect, useCallback, useMemo } from 'react'
+import { formatDate, formatCurrency, formatPhone } from './utils'
+import axios from 'axios'
+
+// File only uses useState and formatDate. Everything else is dead weight.
+```
+
+## Why AI Does This
+When generating code, the model front-loads imports based on what it anticipates using. When the implementation diverges from the plan, the unused imports remain. The model doesn't backtrack to clean up.
+
+## Catch Signal
+- Imported name never appears after the import block
+- Destructured imports where only some members are used
+- Type imports that are never referenced in type annotations
+- Multiple utility imports where only one is used
+
+## Fix Template
+```js
+// Only import what you use
+import { useState } from 'react'
+import { formatDate } from './utils'
+```
+
+## Severity Rationale
+Low in small projects. Medium in large apps — unused imports increase bundle size, slow tree-shaking analysis, and are a reliable signal of unreviewed AI output.

package/slop-index/patterns/005-hardcoded-config.md

@@ -0,0 +1,49 @@
+---
+id: 005
+name: hardcoded-config
+severity: high
+languages: [all]
+tags: [security, config, environment]
+added: 2024-01-01
+---
+
+# Pattern: Hardcoded Config
+
+## Description
+Configuration values, credentials, URLs, limits, or environment-specific constants embedded directly in source code instead of environment variables or config files.
+
+## What It Looks Like
+```js
+const API_URL = 'https://api.myapp.com/v1'
+const MAX_RETRIES = 3
+const DB_HOST = 'prod-db.internal.myapp.com'
+const SECRET_KEY = 'sk_live_abc123xyz'
+
+fetch('https://api.stripe.com/v1/charges', {
+  headers: { Authorization: 'Bearer sk_live_abc123xyz' }
+})
+```
+
+## Why AI Does This
+The model needs concrete values to make the code syntactically complete and runnable-looking. Placeholder values feel incomplete, so it fills them with plausible-looking real values. It doesn't model the operational risk of those values landing in version control.
+
+## Catch Signal
+- URL strings with real-looking domain names hardcoded inline
+- Numeric thresholds (retries, timeouts, limits) with no explanation or config reference
+- Any string that looks like an API key, token, password, or secret
+- Environment-specific hostnames (prod-, staging-, db., api.) in source
+- Magic numbers used more than once without being named constants
+
+## Fix Template
+```js
+// Move to environment variables
+const API_URL = process.env.API_URL
+const MAX_RETRIES = parseInt(process.env.MAX_RETRIES ?? '3')
+const SECRET_KEY = process.env.STRIPE_SECRET_KEY
+
+// Or a config module that reads from env
+import { config } from './config'
+```
+
+## Severity Rationale
+High — secrets in source code leak via git history, logs, and error messages. Even non-secret config hardcoding creates deployment fragility and environment coupling.

package/slop-index/patterns/006-deprecated-api-confidence.md

@@ -0,0 +1,52 @@
+---
+id: 006
+name: deprecated-api-confidence
+severity: high
+languages: [javascript, typescript, python]
+tags: [runtime-error, versioning, dependencies]
+added: 2024-01-01
+---
+
+# Pattern: Deprecated API Confidence
+
+## Description
+AI uses deprecated, removed, or version-specific APIs with full syntactic confidence, as if they are current best practice.
+
+## What It Looks Like
+```js
+// React — class components and old lifecycle methods
+componentWillMount() { }
+componentWillReceiveProps(nextProps) { }
+
+// Node.js — removed APIs
+const { parse } = require('url')
+require('sys').puts('hello')
+
+// Express — removed in v5
+app.del('/route', handler)
+
+// Python requests — old patterns
+requests.get(url, verify=False)  // used as if safe
+```
+
+## Why AI Does This
+Training data contains massive amounts of older code. Deprecated APIs are statistically overrepresented because they existed for longer. The model has no reliable signal for "this was correct in 2019 but not now."
+
+## Catch Signal
+- Lifecycle methods prefixed with `componentWill` in React
+- `require()` for modules moved to core or removed in modern Node
+- Framework methods that have documented replacements in current major versions
+- Python 2-style patterns appearing in Python 3 code
+- Any method call that produces a runtime deprecation warning when executed
+
+## Fix Template
+```js
+// Instead of componentWillMount:
+useEffect(() => { /* setup */ }, [])
+
+// Instead of app.del (Express v5+):
+app.delete('/route', handler)
+```
+
+## Severity Rationale
+High — deprecated APIs often still work in current versions but break on the next major upgrade. Removed APIs fail immediately. Both create maintenance debt that compounds.

package/slop-index/patterns/007-try-catch-everything.md

@@ -0,0 +1,63 @@
+---
+id: 007
+name: try-catch-everything
+severity: medium
+languages: [all]
+tags: [error-handling, architecture]
+added: 2024-01-01
+---
+
+# Pattern: Try-Catch Everything
+
+## Description
+Blanket try/catch blocks wrapped around entire function bodies with generic error handling, silencing specific errors that should propagate or be handled distinctly.
+
+## What It Looks Like
+```js
+async function processOrder(orderId) {
+  try {
+    const order = await getOrder(orderId)
+    const inventory = await checkInventory(order.items)
+    const payment = await chargeCard(order.paymentMethod)
+    await fulfillOrder(order, inventory)
+    await sendConfirmationEmail(order)
+    return { success: true }
+  } catch (error) {
+    console.error('Something went wrong:', error)
+    return { success: false }
+  }
+}
+```
+
+## Why AI Does This
+Error handling is a strong signal of "production-ready" code. The model wraps everything in try/catch to satisfy that pattern without reasoning about which errors are recoverable, which should propagate, and which need distinct handling.
+
+## Catch Signal
+- Single try/catch wrapping 5+ distinct async operations
+- Catch block that only logs and returns a generic failure
+- No differentiation between network errors, validation errors, and business logic errors
+- Errors swallowed with `console.error` and no rethrow or structured response
+- `catch (e) {}` — empty catch that silences everything
+
+## Fix Template
+```js
+async function processOrder(orderId) {
+  const order = await getOrder(orderId)           // let not-found propagate
+  const inventory = await checkInventory(order.items)
+
+  let payment
+  try {
+    payment = await chargeCard(order.paymentMethod)
+  } catch (err) {
+    if (err.code === 'card_declined') return { success: false, reason: 'payment_failed' }
+    throw err  // unexpected errors propagate
+  }
+
+  await fulfillOrder(order, inventory)
+  await sendConfirmationEmail(order).catch(() => {}) // email failure is non-critical
+  return { success: true }
+}
+```
+
+## Severity Rationale
+Medium — doesn't break immediately but masks bugs, makes debugging extremely difficult, and creates silent failure modes that are hard to detect in production.

package/slop-index/patterns/008-generic-variable-names.md

@@ -0,0 +1,49 @@
+---
+id: 008
+name: generic-variable-names
+severity: low
+languages: [all]
+tags: [readability, maintainability]
+added: 2024-01-01
+---
+
+# Pattern: Generic Variable Names
+
+## Description
+Variables named with generic, context-free identifiers in non-trivial code where domain-specific names would communicate intent.
+
+## What It Looks Like
+```js
+const data = await fetchUserOrders(userId)
+const result = data.filter(item => item.status === 'pending')
+const temp = result.map(item => ({ ...item, flagged: true }))
+const final = await Promise.all(temp.map(item => updateOrder(item)))
+
+// Or in a function:
+function process(input) {
+  const obj = transform(input)
+  const val = calculate(obj)
+  return val
+}
+```
+
+## Why AI Does This
+Generic names (`data`, `result`, `temp`, `item`, `obj`, `val`) are maximally reusable in training data. The model defaults to these because they statistically appear next to nearly every operation, making them high-probability completions.
+
+## Catch Signal
+- Variables named: `data`, `result`, `temp`, `final`, `obj`, `val`, `info`, `thing`, `output`, `input` in non-trivial contexts
+- Loop variables named `item` when iterating over a typed collection
+- Function parameters named `input`, `param`, `arg` with no type annotation to compensate
+- Multiple generic names in the same function making it impossible to track which is which
+
+## Fix Template
+```js
+// Name for what it IS, not what it does generically:
+const pendingOrders = await fetchUserOrders(userId)
+const unfulfilled = pendingOrders.filter(order => order.status === 'pending')
+const flaggedForReview = unfulfilled.map(order => ({ ...order, flagged: true }))
+const updateResults = await Promise.all(flaggedForReview.map(order => updateOrder(order)))
+```
+
+## Severity Rationale
+Low individually. Medium when compounded — a function with five generic variable names is actively hostile to debugging and code review.

package/slop-index/patterns/009-stub-with-shell.md

@@ -0,0 +1,61 @@
+---
+id: 009
+name: stub-with-shell
+severity: high
+languages: [all]
+tags: [completeness, runtime-error]
+added: 2024-01-01
+---
+
+# Pattern: Stub With Shell
+
+## Description
+Functions where the outer structure (signature, error handling, return shape) is fully implemented but the core business logic is a placeholder, stub, or TODO.
+
+## What It Looks Like
+```js
+async function calculateShippingRate(order, destination) {
+  try {
+    // TODO: implement actual shipping calculation
+    const rate = 0
+    return {
+      success: true,
+      rate,
+      estimatedDays: 5
+    }
+  } catch (error) {
+    return { success: false, error: error.message }
+  }
+}
+
+// Or more subtle:
+function validateCreditCard(cardNumber) {
+  // Basic validation
+  if (!cardNumber) return false
+  return true  // Always returns true — no actual validation
+}
+```
+
+## Why AI Does This
+The model is trained to produce structurally complete code. It can generate the scaffolding (signature, error handling, return type) from context, but the business logic requires domain knowledge the model doesn't have. Rather than omitting the function, it ships a shell that looks complete.
+
+## Catch Signal
+- `// TODO:` or `// FIXME:` inside otherwise complete-looking functions
+- Return values that are hardcoded zeros, empty arrays, or empty strings where real computation is expected
+- Functions that always return `true` or `null` regardless of input
+- Suspiciously short function bodies for complex-sounding function names
+- `throw new Error('Not implemented')` inside a function that the rest of the code calls as if it works
+
+## Fix Template
+```js
+// Option 1: Make the stub explicit at the call site
+// Option 2: Throw immediately so it fails loudly
+function calculateShippingRate(order, destination) {
+  throw new Error('calculateShippingRate: not yet implemented — see issue #42')
+}
+
+// Option 3: Implement it properly
+```
+
+## Severity Rationale
+High — stub functions compile and pass static analysis. They fail silently in production, returning wrong values that propagate through the system before anyone notices.

package/slop-index/patterns/010-async-misuse.md

@@ -0,0 +1,64 @@
+---
+id: 010
+name: async-misuse
+severity: high
+languages: [javascript, typescript, python]
+tags: [async, runtime-error, performance]
+added: 2024-01-01
+---
+
+# Pattern: Async Misuse
+
+## Description
+Incorrect application of async/await — either bolted onto synchronous operations, creating unnecessary promise chains, or used incorrectly in ways that break execution order.
+
+## What It Looks Like
+```js
+// async on a synchronous function for no reason
+async function formatName(first, last) {
+  return `${first} ${last}`
+}
+
+// await on a non-promise
+const name = await formatName('John', 'Doe')
+
+// Sequential awaits that should be parallel
+async function loadDashboard(userId) {
+  const user = await getUser(userId)
+  const orders = await getOrders(userId)      // these don't depend on each other
+  const notifications = await getNotifications(userId)  // but run sequentially
+  return { user, orders, notifications }
+}
+
+// Missing await causing unhandled promise
+function saveUser(user) {
+  db.save(user)  // returns a promise, no await, no .catch
+  return { success: true }  // lies
+}
+```
+
+## Why AI Does This
+async/await is statistically associated with "modern, correct" JavaScript in training data. The model applies it broadly as a quality signal without modeling the actual execution semantics of the event loop.
+
+## Catch Signal
+- `async` functions whose entire body contains no `await`
+- `await` called on functions that don't return promises
+- Sequential `await` chains where operations are independent (missing `Promise.all`)
+- Promise-returning functions called without `await` or `.then()` in contexts where the result matters
+- `async` in array callbacks where it creates unhandled promises (`arr.forEach(async () => {})`)
+
+## Fix Template
+```js
+// Parallel independent async operations:
+async function loadDashboard(userId) {
+  const [user, orders, notifications] = await Promise.all([
+    getUser(userId),
+    getOrders(userId),
+    getNotifications(userId)
+  ])
+  return { user, orders, notifications }
+}
+```
+
+## Severity Rationale
+High — async misuse causes race conditions, silent failures, and performance problems that are extremely difficult to debug because they're non-deterministic.

package/slop-index/patterns/011-console-log-left-in.md

@@ -0,0 +1,53 @@
+---
+id: 011
+name: console-log-left-in
+severity: medium
+languages: [javascript, typescript]
+tags: [debugging, security, readability]
+added: 2024-01-01
+---
+
+# Pattern: Console Log Left In
+
+## Description
+Debug console.log statements left in production code, often logging sensitive data, internal state, or development-only context.
+
+## What It Looks Like
+```js
+async function authenticateUser(email, password) {
+  console.log('Authenticating user:', email, password)  // logs credentials
+  const user = await findUser(email)
+  console.log('Found user:', user)  // logs full user object including hashed password
+  const valid = await bcrypt.compare(password, user.passwordHash)
+  console.log('Password valid:', valid)
+  return valid ? generateToken(user) : null
+}
+
+// Or the carpet-bomb approach:
+console.log('data:', data)
+console.log('result:', result)
+console.log('here')
+console.log('HERE')
+console.log('===========')
+```
+
+## Why AI Does This
+AI adds console.log statements during code generation as scaffolding — the same way a human would when building something locally. It doesn't model the concept of "this code will run in production" vs "this is debug scaffolding."
+
+## Catch Signal
+- `console.log` statements in non-error paths of production functions
+- Any `console.log` that logs a variable containing `password`, `token`, `secret`, `key`, `auth`
+- Multiple consecutive `console.log` calls suggesting a debugging session
+- `console.log('here')` or similar navigation logs
+- `console.log` inside loops (performance issue at scale)
+
+## Fix Template
+```js
+// Remove debug logs. For intentional logging use a logger:
+import { logger } from './logger'
+logger.info('User authentication attempted', { email })  // never log passwords
+logger.debug('Auth result', { success: valid })          // filtered in production
+```
+
+## Severity Rationale
+Medium-to-high when sensitive data is involved (credentials, tokens, PII). Medium otherwise — leaks implementation details, clutters production logs, and creates noise that obscures real errors.

package/slop-index/patterns/012-over-engineered-simple.md

@@ -0,0 +1,64 @@
+---
+id: 012
+name: over-engineered-simple
+severity: medium
+languages: [all]
+tags: [architecture, readability, over-engineering]
+added: 2024-01-01
+---
+
+# Pattern: Over-Engineered Simple
+
+## Description
+Applying enterprise-scale architectural patterns (factories, registries, strategy pattern, dependency injection) to problems that could be solved with a function or a plain object.
+
+## What It Looks Like
+```js
+// Needed: format a date
+// AI produces: a formatting framework
+
+class FormatterRegistry {
+  constructor() { this.formatters = new Map() }
+  register(name, formatter) { this.formatters.set(name, formatter) }
+  get(name) { return this.formatters.get(name) }
+}
+
+class DateFormatter {
+  constructor(locale) { this.locale = locale }
+  format(date) { return new Intl.DateTimeFormat(this.locale).format(date) }
+}
+
+const registry = new FormatterRegistry()
+registry.register('date', new DateFormatter('en-US'))
+const formatted = registry.get('date').format(new Date())
+
+// Should have been:
+const formatted = new Intl.DateTimeFormat('en-US').format(new Date())
+```
+
+## Why AI Does This
+Enterprise patterns score highly in training data as signals of "good architecture." The model applies them as quality indicators without evaluating whether the problem warrants the complexity. More layers = more "professional" in the training signal.
+
+## Catch Signal
+- Factory or registry pattern for a fixed set of 2-3 things that never changes
+- Strategy pattern where there's only one strategy
+- Dependency injection into a function that's called from one place
+- Abstract base class with a single concrete implementation
+- Configuration objects for functions with one or two settings
+- Interface/type definitions for objects used exactly once
+
+## Fix Template
+```js
+// Match the solution scale to the problem scale.
+// If it's used once and never changes, inline it.
+// If it has 2-3 variants, use a plain object or switch.
+// Reach for patterns only when the problem actually has the shape they solve.
+
+const formatters = {
+  date: (d) => new Intl.DateTimeFormat('en-US').format(d),
+  currency: (n) => new Intl.NumberFormat('en-US', { style: 'currency', currency: 'USD' }).format(n)
+}
+```
+
+## Severity Rationale
+Medium — doesn't break at runtime but creates a maintenance burden where future developers must understand unnecessary abstraction layers before making simple changes.