@reidbuilds/slop 0.2.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/.claude/settings.local.json +11 -0
- package/.firebaserc +5 -0
- package/README.md +73 -0
- package/cli/analyzer.js +150 -0
- package/cli/index.js +182 -0
- package/cli/learner.js +156 -0
- package/cli/reporter.js +126 -0
- package/cli/scanner.js +45 -0
- package/ff-slop.md +27 -0
- package/firebase.json +16 -0
- package/functions/index.js +30 -0
- package/functions/package-lock.json +2755 -0
- package/functions/package.json +12 -0
- package/hardcoresyn-slop.md +1887 -0
- package/package.json +17 -0
- package/slop-index/catches.jsonl +590 -0
- package/slop-index/patterns/001-hallucinated-imports.md +39 -0
- package/slop-index/patterns/002-comment-restatement.md +53 -0
- package/slop-index/patterns/003-unnecessary-abstraction.md +56 -0
- package/slop-index/patterns/004-unused-imports.md +41 -0
- package/slop-index/patterns/005-hardcoded-config.md +49 -0
- package/slop-index/patterns/006-deprecated-api-confidence.md +52 -0
- package/slop-index/patterns/007-try-catch-everything.md +63 -0
- package/slop-index/patterns/008-generic-variable-names.md +49 -0
- package/slop-index/patterns/009-stub-with-shell.md +61 -0
- package/slop-index/patterns/010-async-misuse.md +64 -0
- package/slop-index/patterns/011-console-log-left-in.md +53 -0
- package/slop-index/patterns/012-over-engineered-simple.md +64 -0
- package/slop-index/patterns/013-emoji-debugging.md +44 -0
- package/slop-index/patterns/014-fake-async-simulation.md +71 -0
- package/slop-index/patterns/015-credential-fallbacks.md +51 -0
- package/slop-index/patterns/016-mock-data-pollution.md +75 -0
- package/slop-index/proposed/.gitkeep +0 -0
- package/slop-index/proposed/017-emoji-progress-logging.md +44 -0
- package/slop-index/proposed/018-test-credentials-in-fallbacks.md +54 -0
- package/slop-index/proposed/019-fake-loading-simulation.md +75 -0
- package/slop-index/proposed/020-configuration-debugging-left-in.md +53 -0
- package/slop-index/proposed/021-emoji-production-logging.md +42 -0
- package/slop-index/proposed/022-fake-delay-simulation.md +70 -0
- package/slop-index/proposed/023-credential-hardcoding-with-fallbacks.md +57 -0
- package/slop-index/proposed/024-repetitive-error-pattern.md +76 -0
- package/slop-index/proposed/025-environment-specific-fallbacks.md +55 -0
- package/slop-index/proposed/026-emoji-production-logs.md +46 -0
- package/slop-index/proposed/027-credentials-in-debug-logs.md +48 -0
- package/slop-index/proposed/028-repetitive-service-wrappers.md +59 -0
- package/slop-index/proposed/029-forced-non-null-assertions.md +59 -0
- package/slop-index/proposed/030-production-credential-fallbacks.md +51 -0
- package/slop-index/proposed/031-fake-version-confidence.md +50 -0
- package/slop-index/proposed/032-forced-non-null-assertions.md +53 -0
- package/slop-index/proposed/033-emoji-production-logs.md +44 -0
- package/slop-index/proposed/034-realistic-mock-data-leakage.md +62 -0
- package/slop-index/proposed/035-production-credential-exposure.md +43 -0
- package/slop-index/proposed/036-identical-wrapper-proliferation.md +53 -0
- package/slop-index/proposed/037-forced-null-assertions.md +50 -0
- package/slop-index/proposed/038-emoji-production-logging.md +42 -0
- package/slop-index/proposed/039-fake-delay-operations.md +52 -0
- package/slop-index/proposed/040-forced-null-assertion-chains.md +45 -0
- package/slop-index/proposed/041-production-debug-configuration.md +45 -0
- package/slop-index/proposed/042-repetitive-firebase-wrappers.md +51 -0
- package/slop-index/proposed/043-hardcoded-process-timeouts.md +48 -0
- package/slop-index/proposed/044-fictional-package-versions.md +37 -0
- package/test-sample.js +89 -0
|
@@ -0,0 +1,44 @@
|
|
|
1
|
+
---
|
|
2
|
+
id: 013
|
|
3
|
+
name: emoji-debugging
|
|
4
|
+
severity: medium
|
|
5
|
+
languages: [javascript, typescript]
|
|
6
|
+
tags: [debugging, logging, production, maintenance]
|
|
7
|
+
added: 2026-05-20
|
|
8
|
+
---
|
|
9
|
+
|
|
10
|
+
# Pattern: Emoji Debugging
|
|
11
|
+
|
|
12
|
+
## Description
|
|
13
|
+
Using emoji characters and decorative symbols in debug output, console logs, or error messages. This creates unprofessional production logs, can cause encoding issues in different environments, and makes log parsing and searching more difficult for monitoring systems.
|
|
14
|
+
|
|
15
|
+
## What It Looks Like
|
|
16
|
+
```
|
|
17
|
+
console.log('🔍 Finding "Sweat Starter Test 1" program...');
|
|
18
|
+
console.log('✓ Found program:', program.id);
|
|
19
|
+
console.error('❌ Program not found');
|
|
20
|
+
console.log('🔥 Firebase Config Debug:');
|
|
21
|
+
console.log('✅ Successfully populated program!');
|
|
22
|
+
```
|
|
23
|
+
|
|
24
|
+
## Why AI Does This
|
|
25
|
+
AI models are trained on diverse code examples including tutorials, demos, and beginner-friendly examples that often use emoji to make output more visually appealing and easier to follow. The AI associates emoji with good user experience without understanding that production systems require clean, parseable log output.
|
|
26
|
+
|
|
27
|
+
## Catch Signal
|
|
28
|
+
- Emoji characters (🔍, ✓, ❌, 🔥, ✅) in console.log or error messages
|
|
29
|
+
- Unicode symbols mixed with technical output
|
|
30
|
+
- Decorative characters in debug strings
|
|
31
|
+
- Progress indicators using visual symbols instead of text
|
|
32
|
+
- Status messages with celebratory or attention-grabbing emoji
|
|
33
|
+
|
|
34
|
+
## Fix Template
|
|
35
|
+
```
|
|
36
|
+
console.log('Finding "Sweat Starter Test 1" program...');
|
|
37
|
+
console.log('Found program:', program.id);
|
|
38
|
+
console.error('Program not found');
|
|
39
|
+
console.log('Firebase Config Debug:');
|
|
40
|
+
console.log('Successfully populated program!');
|
|
41
|
+
```
|
|
42
|
+
|
|
43
|
+
## Severity Rationale
|
|
44
|
+
medium — Medium severity because it creates maintenance issues and unprofessional output but doesn't break core functionality.
|
|
@@ -0,0 +1,71 @@
|
|
|
1
|
+
---
|
|
2
|
+
id: 014
|
|
3
|
+
name: fake-async-simulation
|
|
4
|
+
severity: high
|
|
5
|
+
languages: [javascript, typescript]
|
|
6
|
+
tags: [async, testing, mocking, production]
|
|
7
|
+
added: 2026-05-20
|
|
8
|
+
---
|
|
9
|
+
|
|
10
|
+
# Pattern: Fake Async Simulation
|
|
11
|
+
|
|
12
|
+
## Description
|
|
13
|
+
Creating fake asynchronous operations using setTimeout with hardcoded delays to simulate real async work like API calls or database operations. This creates the illusion of working functionality while providing no real implementation, and the arbitrary delays will cause performance issues and unpredictable behavior in production.
|
|
14
|
+
|
|
15
|
+
## What It Looks Like
|
|
16
|
+
```
|
|
17
|
+
const handleSave = async () => {
|
|
18
|
+
setSaving(true);
|
|
19
|
+
// TODO: Implement API call
|
|
20
|
+
await new Promise(r => setTimeout(r, 1000));
|
|
21
|
+
setSaving(false);
|
|
22
|
+
alert('Saved successfully!');
|
|
23
|
+
};
|
|
24
|
+
|
|
25
|
+
const fetchData = async () => {
|
|
26
|
+
setLoading(true);
|
|
27
|
+
await new Promise(r => setTimeout(r, 500));
|
|
28
|
+
setData(mockData);
|
|
29
|
+
setLoading(false);
|
|
30
|
+
};
|
|
31
|
+
```
|
|
32
|
+
|
|
33
|
+
## Why AI Does This
|
|
34
|
+
AI models often see timeout-based delays in examples used for demonstrating loading states or simulating network latency in tutorials. The AI incorrectly applies this pattern as a placeholder for real async operations, not understanding that setTimeout should only be used for actual timing requirements, not as a substitute for meaningful async work.
|
|
35
|
+
|
|
36
|
+
## Catch Signal
|
|
37
|
+
- setTimeout wrapped in Promise constructor with resolve callback
|
|
38
|
+
- Hardcoded delay values (500ms, 1000ms) in async functions
|
|
39
|
+
- await new Promise(r => setTimeout(r, number)) patterns
|
|
40
|
+
- TODO comments about API calls combined with fake delays
|
|
41
|
+
- Loading states that resolve after arbitrary timeouts rather than real operations
|
|
42
|
+
|
|
43
|
+
## Fix Template
|
|
44
|
+
```
|
|
45
|
+
const handleSave = async () => {
|
|
46
|
+
setSaving(true);
|
|
47
|
+
try {
|
|
48
|
+
const result = await saveUserProfile(profileData);
|
|
49
|
+
if (result.success) {
|
|
50
|
+
showSuccessMessage('Profile saved successfully!');
|
|
51
|
+
}
|
|
52
|
+
} catch (error) {
|
|
53
|
+
showErrorMessage('Failed to save profile');
|
|
54
|
+
} finally {
|
|
55
|
+
setSaving(false);
|
|
56
|
+
}
|
|
57
|
+
};
|
|
58
|
+
|
|
59
|
+
const fetchData = async () => {
|
|
60
|
+
setLoading(true);
|
|
61
|
+
try {
|
|
62
|
+
const response = await apiClient.getData();
|
|
63
|
+
setData(response.data);
|
|
64
|
+
} finally {
|
|
65
|
+
setLoading(false);
|
|
66
|
+
}
|
|
67
|
+
};
|
|
68
|
+
```
|
|
69
|
+
|
|
70
|
+
## Severity Rationale
|
|
71
|
+
high — High severity because it creates non-functional code that appears to work but provides no real value and can mislead developers about system behavior.
|
|
@@ -0,0 +1,51 @@
|
|
|
1
|
+
---
|
|
2
|
+
id: 015
|
|
3
|
+
name: credential-fallbacks
|
|
4
|
+
severity: high
|
|
5
|
+
languages: [javascript, typescript]
|
|
6
|
+
tags: [security, configuration, credentials, environment]
|
|
7
|
+
added: 2026-05-20
|
|
8
|
+
---
|
|
9
|
+
|
|
10
|
+
# Pattern: Credential Fallbacks
|
|
11
|
+
|
|
12
|
+
## Description
|
|
13
|
+
Providing real API keys, tokens, or other credentials as hardcoded fallback values in environment variable lookups. While intended as defaults when environment variables are missing, this embeds production credentials directly in source code, creating security risks and making it impossible to rotate keys without code changes.
|
|
14
|
+
|
|
15
|
+
## What It Looks Like
|
|
16
|
+
```
|
|
17
|
+
const config = {
|
|
18
|
+
apiKey: process.env.FIREBASE_API_KEY || 'AIzaSyB0uWItoUyaozcnjntgG9kck6GJx84GQNY',
|
|
19
|
+
stripeKey: process.env.STRIPE_KEY || 'pk_test_51SrKL12EWDoWzTlbooO1c6Y3k1oMpjc2JAk266LPVK6TGgRPthyf4eeGjhFh6lDGeZEz3YxDxDUhQ4wBcnemfU1v00BKalQrEu',
|
|
20
|
+
databaseUrl: process.env.DB_URL || 'hardcore-synergy.firebaseapp.com'
|
|
21
|
+
};
|
|
22
|
+
```
|
|
23
|
+
|
|
24
|
+
## Why AI Does This
|
|
25
|
+
AI models see environment variable patterns with fallback values in many code examples and tutorials, where hardcoded values are used for convenience in demonstrations. The AI doesn't understand the security implications of embedding real credentials and treats them as helpful defaults that ensure the code always has working values.
|
|
26
|
+
|
|
27
|
+
## Catch Signal
|
|
28
|
+
- Real API keys or tokens in || fallback expressions
|
|
29
|
+
- Environment variable lookups with credential strings as defaults
|
|
30
|
+
- Firebase config objects with hardcoded API keys
|
|
31
|
+
- Stripe keys, database URLs, or service endpoints as fallback values
|
|
32
|
+
- process.env.VAR || 'real-credential-string' patterns
|
|
33
|
+
|
|
34
|
+
## Fix Template
|
|
35
|
+
```
|
|
36
|
+
const config = {
|
|
37
|
+
apiKey: process.env.FIREBASE_API_KEY || (() => { throw new Error('FIREBASE_API_KEY environment variable is required') })(),
|
|
38
|
+
stripeKey: process.env.STRIPE_KEY || (() => { throw new Error('STRIPE_KEY environment variable is required') })(),
|
|
39
|
+
databaseUrl: process.env.DB_URL || 'localhost:5432'
|
|
40
|
+
};
|
|
41
|
+
|
|
42
|
+
// Or use a configuration validation library
|
|
43
|
+
const config = {
|
|
44
|
+
apiKey: requireEnv('FIREBASE_API_KEY'),
|
|
45
|
+
stripeKey: requireEnv('STRIPE_KEY'),
|
|
46
|
+
databaseUrl: process.env.DB_URL || 'localhost:5432'
|
|
47
|
+
};
|
|
48
|
+
```
|
|
49
|
+
|
|
50
|
+
## Severity Rationale
|
|
51
|
+
high — High severity because it exposes real credentials in source code, creating immediate security vulnerabilities.
|
|
@@ -0,0 +1,75 @@
|
|
|
1
|
+
---
|
|
2
|
+
id: 016
|
|
3
|
+
name: mock-data-pollution
|
|
4
|
+
severity: medium
|
|
5
|
+
languages: [javascript, typescript]
|
|
6
|
+
tags: [testing, data, hardcoding, maintenance]
|
|
7
|
+
added: 2026-05-20
|
|
8
|
+
---
|
|
9
|
+
|
|
10
|
+
# Pattern: Mock Data Pollution
|
|
11
|
+
|
|
12
|
+
## Description
|
|
13
|
+
Embedding large amounts of detailed mock data directly in component files or business logic, often with realistic-looking but fake personal information. This clutters the codebase, makes components harder to understand, and creates maintenance overhead when the mock data inevitably becomes outdated or needs to change.
|
|
14
|
+
|
|
15
|
+
## What It Looks Like
|
|
16
|
+
```
|
|
17
|
+
const mockIntakes: PendingIntake[] = [
|
|
18
|
+
{
|
|
19
|
+
id: '1',
|
|
20
|
+
clientName: 'Emma Wilson',
|
|
21
|
+
email: 'emma@example.com',
|
|
22
|
+
tier: 'body-blueprint',
|
|
23
|
+
submittedAt: new Date(Date.now() - 2 * 60 * 60 * 1000),
|
|
24
|
+
primaryGoal: 'lose-fat',
|
|
25
|
+
age: 28,
|
|
26
|
+
weight: 145,
|
|
27
|
+
height: '5\'6"',
|
|
28
|
+
activityLevel: 'moderate'
|
|
29
|
+
},
|
|
30
|
+
// ... 15 more detailed mock objects
|
|
31
|
+
];
|
|
32
|
+
|
|
33
|
+
const mockTemplateData: Record<string, {
|
|
34
|
+
title: string;
|
|
35
|
+
description: string;
|
|
36
|
+
category: string;
|
|
37
|
+
focusAreas: string[];
|
|
38
|
+
// ... many more fields
|
|
39
|
+
}> = {
|
|
40
|
+
// Large object with detailed fake data
|
|
41
|
+
};
|
|
42
|
+
```
|
|
43
|
+
|
|
44
|
+
## Why AI Does This
|
|
45
|
+
AI models are trained on examples where mock data is used for demonstrations and prototyping. The AI generates realistic and comprehensive mock data to make the interface look complete and functional, not realizing that production components should either use real data sources or minimal placeholder data for structure testing.
|
|
46
|
+
|
|
47
|
+
## Catch Signal
|
|
48
|
+
- Large arrays of mock objects with detailed fake personal information
|
|
49
|
+
- Mock data constants defined directly in component files
|
|
50
|
+
- Realistic fake emails, names, and personal details in hardcoded data
|
|
51
|
+
- Complex mock objects with many fields that mirror production data structures
|
|
52
|
+
- Mock data that includes computed dates or timestamps
|
|
53
|
+
|
|
54
|
+
## Fix Template
|
|
55
|
+
```
|
|
56
|
+
// Move to separate test data file
|
|
57
|
+
// __tests__/mockData.ts
|
|
58
|
+
export const mockIntakes = [
|
|
59
|
+
{
|
|
60
|
+
id: '1',
|
|
61
|
+
clientName: 'Test User 1',
|
|
62
|
+
email: 'test1@example.com',
|
|
63
|
+
tier: 'body-blueprint'
|
|
64
|
+
}
|
|
65
|
+
];
|
|
66
|
+
|
|
67
|
+
// In component, use data service
|
|
68
|
+
const { data: intakes, loading } = useIntakes();
|
|
69
|
+
|
|
70
|
+
// Or minimal inline placeholder
|
|
71
|
+
const placeholderIntake = { id: '', clientName: 'Loading...', email: '' };
|
|
72
|
+
```
|
|
73
|
+
|
|
74
|
+
## Severity Rationale
|
|
75
|
+
medium — Medium severity because it creates maintenance burden and code clutter but doesn't affect core functionality or security.
|
|
File without changes
|
|
@@ -0,0 +1,44 @@
|
|
|
1
|
+
---
|
|
2
|
+
id: 017
|
|
3
|
+
name: emoji-progress-logging
|
|
4
|
+
severity: low
|
|
5
|
+
languages: [typescript, javascript]
|
|
6
|
+
tags: [logging, debugging, production, console]
|
|
7
|
+
added: 2026-05-20
|
|
8
|
+
---
|
|
9
|
+
|
|
10
|
+
# Pattern: Emoji Progress Logging
|
|
11
|
+
|
|
12
|
+
## Description
|
|
13
|
+
Using emoji characters and visual progress indicators in console logging statements throughout production code. While these make development debugging more visually appealing, they create unprofessional log output in production environments and can cause encoding issues in log aggregation systems.
|
|
14
|
+
|
|
15
|
+
## What It Looks Like
|
|
16
|
+
```
|
|
17
|
+
console.log('🔍 Finding "Sweat Starter Test 1" program...');
|
|
18
|
+
console.log('✓ Found program:', targetProgram.id);
|
|
19
|
+
console.error('❌ Program not found');
|
|
20
|
+
console.log('🔥 Firebase Config Debug:');
|
|
21
|
+
console.log('✅ Successfully populated program!');
|
|
22
|
+
```
|
|
23
|
+
|
|
24
|
+
## Why AI Does This
|
|
25
|
+
AI models are trained on tutorial code and beginner examples that often use emoji for visual appeal and clarity. They apply this pattern to make logs more readable during development without considering the professional context or production log requirements.
|
|
26
|
+
|
|
27
|
+
## Catch Signal
|
|
28
|
+
- Console logging with emoji characters (🔍, ✓, ❌, 🔥, ✅)
|
|
29
|
+
- Progress indicators using visual symbols in logs
|
|
30
|
+
- Mix of informational and error logging with decorative characters
|
|
31
|
+
- Logging patterns that prioritize visual appeal over log parsing
|
|
32
|
+
- Console statements with status symbols instead of proper log levels
|
|
33
|
+
|
|
34
|
+
## Fix Template
|
|
35
|
+
```
|
|
36
|
+
logger.debug('Finding Sweat Starter Test 1 program');
|
|
37
|
+
logger.info('Found program', { programId: targetProgram.id });
|
|
38
|
+
logger.error('Program not found', { programName: 'Sweat Starter Test 1' });
|
|
39
|
+
logger.debug('Firebase configuration loaded');
|
|
40
|
+
logger.info('Successfully populated program', { totalWorkouts, totalWeeks });
|
|
41
|
+
```
|
|
42
|
+
|
|
43
|
+
## Severity Rationale
|
|
44
|
+
low — Low severity because it's primarily a cosmetic issue that doesn't break functionality but creates unprofessional production logs.
|
|
@@ -0,0 +1,54 @@
|
|
|
1
|
+
---
|
|
2
|
+
id: 018
|
|
3
|
+
name: test-credentials-in-fallbacks
|
|
4
|
+
severity: high
|
|
5
|
+
languages: [typescript, javascript]
|
|
6
|
+
tags: [security, credentials, configuration, environment]
|
|
7
|
+
added: 2026-05-20
|
|
8
|
+
---
|
|
9
|
+
|
|
10
|
+
# Pattern: Test Credentials In Fallbacks
|
|
11
|
+
|
|
12
|
+
## Description
|
|
13
|
+
Using real test environment API keys, tokens, or credentials as hardcoded fallback values in configuration. This creates security risks by embedding actual credentials in source code and makes it impossible to rotate keys without code changes. Even test credentials should be managed through environment variables.
|
|
14
|
+
|
|
15
|
+
## What It Looks Like
|
|
16
|
+
```
|
|
17
|
+
const stripeKey = process.env.STRIPE_KEY || 'pk_test_51SrKL12EWDoWzTlbooO1c6Y3k1oMpjc2JAk266LPVK6TGgRPthyf4eeGjhFh6lDGeZEz3YxDxDUhQ4wBcnemfU1v00BKalQrEu';
|
|
18
|
+
const firebaseConfig = {
|
|
19
|
+
apiKey: process.env.FIREBASE_KEY || 'AIzaSyB0uWItoUyaozcnjntgG9kck6GJx84GQNY',
|
|
20
|
+
projectId: process.env.PROJECT_ID || 'hardcore-synergy'
|
|
21
|
+
};
|
|
22
|
+
```
|
|
23
|
+
|
|
24
|
+
## Why AI Does This
|
|
25
|
+
AI models see environment variable patterns with fallbacks in training data and generate realistic-looking credentials to make code appear functional. They don't understand that even test credentials should be externalized or that hardcoded fallbacks defeat the purpose of environment-based configuration.
|
|
26
|
+
|
|
27
|
+
## Catch Signal
|
|
28
|
+
- Real-looking API keys or tokens as fallback values
|
|
29
|
+
- Test environment credentials (pk_test_, sk_test_) hardcoded in source
|
|
30
|
+
- Firebase, Stripe, or other service credentials as literal strings
|
|
31
|
+
- Environment variable patterns with credential fallbacks
|
|
32
|
+
- Configuration objects mixing env vars with hardcoded keys
|
|
33
|
+
|
|
34
|
+
## Fix Template
|
|
35
|
+
```
|
|
36
|
+
const stripeKey = process.env.STRIPE_KEY;
|
|
37
|
+
if (!stripeKey) {
|
|
38
|
+
throw new Error('STRIPE_KEY environment variable is required');
|
|
39
|
+
}
|
|
40
|
+
|
|
41
|
+
const firebaseConfig = {
|
|
42
|
+
apiKey: requireEnv('FIREBASE_API_KEY'),
|
|
43
|
+
projectId: requireEnv('FIREBASE_PROJECT_ID')
|
|
44
|
+
};
|
|
45
|
+
|
|
46
|
+
function requireEnv(key: string): string {
|
|
47
|
+
const value = process.env[key];
|
|
48
|
+
if (!value) throw new Error(`${key} environment variable is required`);
|
|
49
|
+
return value;
|
|
50
|
+
}
|
|
51
|
+
```
|
|
52
|
+
|
|
53
|
+
## Severity Rationale
|
|
54
|
+
high — High severity because it exposes real credentials in source code, creating security vulnerabilities and deployment risks.
|
|
@@ -0,0 +1,75 @@
|
|
|
1
|
+
---
|
|
2
|
+
id: 019
|
|
3
|
+
name: fake-loading-simulation
|
|
4
|
+
severity: medium
|
|
5
|
+
languages: [typescript, javascript]
|
|
6
|
+
tags: [async, ui, mocking, delays]
|
|
7
|
+
added: 2026-05-20
|
|
8
|
+
---
|
|
9
|
+
|
|
10
|
+
# Pattern: Fake Loading Simulation
|
|
11
|
+
|
|
12
|
+
## Description
|
|
13
|
+
Creating artificial loading states and delays using setTimeout to simulate async operations that don't actually exist. This creates a false impression of working functionality and will break user expectations when real async operations are implemented, as the timing and behavior will change dramatically.
|
|
14
|
+
|
|
15
|
+
## What It Looks Like
|
|
16
|
+
```
|
|
17
|
+
const [loading, setLoading] = useState(false);
|
|
18
|
+
|
|
19
|
+
const handleSave = async () => {
|
|
20
|
+
setLoading(true);
|
|
21
|
+
await new Promise(resolve => setTimeout(resolve, 1000));
|
|
22
|
+
// TODO: Implement actual save logic
|
|
23
|
+
setLoading(false);
|
|
24
|
+
alert('Settings saved!');
|
|
25
|
+
};
|
|
26
|
+
|
|
27
|
+
const fetchData = async () => {
|
|
28
|
+
setLoading(true);
|
|
29
|
+
await new Promise(r => setTimeout(r, 500));
|
|
30
|
+
setData(mockData);
|
|
31
|
+
setLoading(false);
|
|
32
|
+
};
|
|
33
|
+
```
|
|
34
|
+
|
|
35
|
+
## Why AI Does This
|
|
36
|
+
AI models understand that real async operations take time and create loading states, but when generating stub code, they simulate this timing with setTimeout to make the UI behavior appear realistic. They don't realize this creates misleading UX expectations and technical debt.
|
|
37
|
+
|
|
38
|
+
## Catch Signal
|
|
39
|
+
- setTimeout used to simulate async operation delays
|
|
40
|
+
- Loading states paired with artificial delays
|
|
41
|
+
- Promise.resolve with setTimeout for fake async behavior
|
|
42
|
+
- Consistent delay timing (500ms, 1000ms) across different operations
|
|
43
|
+
- Mock data returned after simulated loading periods
|
|
44
|
+
|
|
45
|
+
## Fix Template
|
|
46
|
+
```
|
|
47
|
+
const [loading, setLoading] = useState(false);
|
|
48
|
+
|
|
49
|
+
const handleSave = async () => {
|
|
50
|
+
setLoading(true);
|
|
51
|
+
try {
|
|
52
|
+
await api.saveSettings(settings);
|
|
53
|
+
showSuccessMessage('Settings saved!');
|
|
54
|
+
} catch (error) {
|
|
55
|
+
showErrorMessage('Failed to save settings');
|
|
56
|
+
} finally {
|
|
57
|
+
setLoading(false);
|
|
58
|
+
}
|
|
59
|
+
};
|
|
60
|
+
|
|
61
|
+
const fetchData = async () => {
|
|
62
|
+
setLoading(true);
|
|
63
|
+
try {
|
|
64
|
+
const data = await api.getData();
|
|
65
|
+
setData(data);
|
|
66
|
+
} catch (error) {
|
|
67
|
+
setError('Failed to load data');
|
|
68
|
+
} finally {
|
|
69
|
+
setLoading(false);
|
|
70
|
+
}
|
|
71
|
+
};
|
|
72
|
+
```
|
|
73
|
+
|
|
74
|
+
## Severity Rationale
|
|
75
|
+
medium — Medium severity because it creates misleading UX expectations and technical debt that will require significant refactoring when real async operations are implemented.
|
|
@@ -0,0 +1,53 @@
|
|
|
1
|
+
---
|
|
2
|
+
id: 020
|
|
3
|
+
name: configuration-debugging-left-in
|
|
4
|
+
severity: medium
|
|
5
|
+
languages: [typescript, javascript]
|
|
6
|
+
tags: [debugging, configuration, logging, security]
|
|
7
|
+
added: 2026-05-20
|
|
8
|
+
---
|
|
9
|
+
|
|
10
|
+
# Pattern: Configuration Debugging Left In
|
|
11
|
+
|
|
12
|
+
## Description
|
|
13
|
+
Leaving detailed configuration debugging statements in production code that log sensitive configuration details, API endpoints, or system internals. These debug statements expose implementation details and potentially sensitive information while cluttering production logs with development-time diagnostic information.
|
|
14
|
+
|
|
15
|
+
## What It Looks Like
|
|
16
|
+
```
|
|
17
|
+
console.log('🔑 Loading Stripe with key:', STRIPE_KEY.substring(0, 20) + '...');
|
|
18
|
+
console.log('🔑 Key length:', STRIPE_KEY.length);
|
|
19
|
+
console.log('🔑 Full key (for debugging):', STRIPE_KEY);
|
|
20
|
+
console.log('🔥 Firebase Config Debug:');
|
|
21
|
+
console.log(' - API Key:', config.apiKey ? '✓ Set' : '✗ MISSING');
|
|
22
|
+
console.log(' - Project ID:', config.projectId);
|
|
23
|
+
```
|
|
24
|
+
|
|
25
|
+
## Why AI Does This
|
|
26
|
+
AI models generate debugging code to help developers verify configuration is loaded correctly, but they don't distinguish between development debugging and production code. They create comprehensive logging to demonstrate that the configuration system is working properly.
|
|
27
|
+
|
|
28
|
+
## Catch Signal
|
|
29
|
+
- Console logging of API keys or credentials (even partially)
|
|
30
|
+
- Configuration validation logging with service details
|
|
31
|
+
- Debug statements showing internal system state
|
|
32
|
+
- Logging that exposes service names, endpoints, or keys
|
|
33
|
+
- Development-style diagnostic logging in production files
|
|
34
|
+
|
|
35
|
+
## Fix Template
|
|
36
|
+
```
|
|
37
|
+
// Use proper logging levels and avoid exposing sensitive data
|
|
38
|
+
logger.debug('Stripe client initialized');
|
|
39
|
+
logger.debug('Firebase services initialized', {
|
|
40
|
+
services: ['auth', 'firestore', 'storage']
|
|
41
|
+
});
|
|
42
|
+
|
|
43
|
+
// For development, use environment-specific debug logging
|
|
44
|
+
if (process.env.NODE_ENV === 'development') {
|
|
45
|
+
logger.debug('Configuration loaded', {
|
|
46
|
+
hasStripeKey: !!process.env.STRIPE_KEY,
|
|
47
|
+
hasFirebaseConfig: !!process.env.FIREBASE_API_KEY
|
|
48
|
+
});
|
|
49
|
+
}
|
|
50
|
+
```
|
|
51
|
+
|
|
52
|
+
## Severity Rationale
|
|
53
|
+
medium — Medium severity because it can expose sensitive configuration details and creates security risks while polluting production logs.
|
|
@@ -0,0 +1,42 @@
|
|
|
1
|
+
---
|
|
2
|
+
id: 021
|
|
3
|
+
name: emoji-production-logging
|
|
4
|
+
severity: medium
|
|
5
|
+
languages: [javascript, typescript]
|
|
6
|
+
tags: [logging, production, debugging, ui-pollution]
|
|
7
|
+
added: 2026-05-20
|
|
8
|
+
---
|
|
9
|
+
|
|
10
|
+
# Pattern: Emoji Production Logging
|
|
11
|
+
|
|
12
|
+
## Description
|
|
13
|
+
AI generates console logging statements that include emoji characters and casual language intended for development debugging but left in production code. These logs create visual noise in production environments and suggest unprofessional development practices.
|
|
14
|
+
|
|
15
|
+
## What It Looks Like
|
|
16
|
+
```
|
|
17
|
+
console.log('🔍 Finding "Sweat Starter Test 1" program...');
|
|
18
|
+
console.log('✓ Found program:', targetProgram.id);
|
|
19
|
+
console.error('❌ Program not found');
|
|
20
|
+
console.log('✅ Successfully populated program!');
|
|
21
|
+
```
|
|
22
|
+
|
|
23
|
+
## Why AI Does This
|
|
24
|
+
AI models are trained on diverse code examples including tutorial code and development scripts where emoji logging is used to make output more readable during learning. The AI doesn't distinguish between development utility scripts and production code, carrying over this casual logging style inappropriately.
|
|
25
|
+
|
|
26
|
+
## Catch Signal
|
|
27
|
+
- console.log statements with emoji characters
|
|
28
|
+
- Success/error messages with ✓, ❌, ✅ symbols
|
|
29
|
+
- Progress indicators with 🔍, 🔑, 🔥 emojis
|
|
30
|
+
- Multiple themed console statements in sequence
|
|
31
|
+
- Casual language combined with emoji in logging
|
|
32
|
+
|
|
33
|
+
## Fix Template
|
|
34
|
+
```
|
|
35
|
+
logger.debug('Finding target program:', programName);
|
|
36
|
+
logger.info('Found program', { programId: targetProgram.id });
|
|
37
|
+
logger.error('Program not found', { programName });
|
|
38
|
+
logger.info('Successfully populated program', { programId, workoutCount });
|
|
39
|
+
```
|
|
40
|
+
|
|
41
|
+
## Severity Rationale
|
|
42
|
+
medium — Medium severity because it creates log pollution and unprofessional output but doesn't break functionality.
|
|
@@ -0,0 +1,70 @@
|
|
|
1
|
+
---
|
|
2
|
+
id: 022
|
|
3
|
+
name: fake-delay-simulation
|
|
4
|
+
severity: high
|
|
5
|
+
languages: [javascript, typescript]
|
|
6
|
+
tags: [async, mocking, testing, production-risk]
|
|
7
|
+
added: 2026-05-20
|
|
8
|
+
---
|
|
9
|
+
|
|
10
|
+
# Pattern: Fake Delay Simulation
|
|
11
|
+
|
|
12
|
+
## Description
|
|
13
|
+
AI creates artificial delays using setTimeout in Promise wrappers to simulate async operations like API calls or database queries. This creates the illusion of working functionality during development but will fail when real async operations are needed.
|
|
14
|
+
|
|
15
|
+
## What It Looks Like
|
|
16
|
+
```
|
|
17
|
+
const fetchData = async () => {
|
|
18
|
+
setLoading(true);
|
|
19
|
+
await new Promise(r => setTimeout(r, 500));
|
|
20
|
+
setData(mockData);
|
|
21
|
+
setLoading(false);
|
|
22
|
+
};
|
|
23
|
+
|
|
24
|
+
const handleSave = async () => {
|
|
25
|
+
setSaving(true);
|
|
26
|
+
await new Promise(r => setTimeout(r, 1000));
|
|
27
|
+
setSaving(false);
|
|
28
|
+
alert('Settings saved!');
|
|
29
|
+
};
|
|
30
|
+
```
|
|
31
|
+
|
|
32
|
+
## Why AI Does This
|
|
33
|
+
AI models generate fake delays to simulate the user experience of async operations while building UI components. This allows the generated code to demonstrate loading states and async patterns without requiring real backend integration, but creates non-functional stubs that appear to work.
|
|
34
|
+
|
|
35
|
+
## Catch Signal
|
|
36
|
+
- await new Promise(r => setTimeout(r, number))
|
|
37
|
+
- Async functions with only setTimeout delays
|
|
38
|
+
- Loading states around artificial delays
|
|
39
|
+
- Success messages after fake delays
|
|
40
|
+
- Mock data returned after setTimeout
|
|
41
|
+
|
|
42
|
+
## Fix Template
|
|
43
|
+
```
|
|
44
|
+
const fetchData = async () => {
|
|
45
|
+
setLoading(true);
|
|
46
|
+
try {
|
|
47
|
+
const response = await apiClient.get('/data');
|
|
48
|
+
setData(response.data);
|
|
49
|
+
} catch (error) {
|
|
50
|
+
setError('Failed to fetch data');
|
|
51
|
+
} finally {
|
|
52
|
+
setLoading(false);
|
|
53
|
+
}
|
|
54
|
+
};
|
|
55
|
+
|
|
56
|
+
const handleSave = async (settings: Settings) => {
|
|
57
|
+
setSaving(true);
|
|
58
|
+
try {
|
|
59
|
+
await apiClient.put('/settings', settings);
|
|
60
|
+
showSuccessToast('Settings saved!');
|
|
61
|
+
} catch (error) {
|
|
62
|
+
showErrorToast('Failed to save settings');
|
|
63
|
+
} finally {
|
|
64
|
+
setSaving(false);
|
|
65
|
+
}
|
|
66
|
+
};
|
|
67
|
+
```
|
|
68
|
+
|
|
69
|
+
## Severity Rationale
|
|
70
|
+
high — High severity because it creates completely non-functional code that appears to work during development.
|
|
@@ -0,0 +1,57 @@
|
|
|
1
|
+
---
|
|
2
|
+
id: 023
|
|
3
|
+
name: credential-hardcoding-with-fallbacks
|
|
4
|
+
severity: high
|
|
5
|
+
languages: [javascript, typescript]
|
|
6
|
+
tags: [security, credentials, configuration, environment]
|
|
7
|
+
added: 2026-05-20
|
|
8
|
+
---
|
|
9
|
+
|
|
10
|
+
# Pattern: Credential Hardcoding With Fallbacks
|
|
11
|
+
|
|
12
|
+
## Description
|
|
13
|
+
AI hardcodes real API keys, tokens, or service credentials directly in source code as fallback values when environment variables aren't available. While using environment variables is good practice, the hardcoded fallbacks expose real credentials and create security vulnerabilities.
|
|
14
|
+
|
|
15
|
+
## What It Looks Like
|
|
16
|
+
```
|
|
17
|
+
const stripeKey = process.env.STRIPE_KEY || 'pk_test_51SrKL12EWDoWzTlbooO1c6Y3k1oMpjc2JAk266LPVK6TGgRPthyf4eeGjhFh6lDGeZEz3YxDxDUhQ4wBcnemfU1v00BKalQrEu';
|
|
18
|
+
|
|
19
|
+
const firebaseConfig = {
|
|
20
|
+
apiKey: process.env.FIREBASE_API_KEY || 'AIzaSyB0uWItoUyaozcnjntgG9kck6GJx84GQNY',
|
|
21
|
+
authDomain: process.env.FIREBASE_AUTH_DOMAIN || 'hardcore-synergy.firebaseapp.com'
|
|
22
|
+
};
|
|
23
|
+
```
|
|
24
|
+
|
|
25
|
+
## Why AI Does This
|
|
26
|
+
AI models attempt to create working code examples by providing fallback values for environment variables, but they generate realistic-looking credentials that may be real test keys from training data. The AI prioritizes making code that "just works" over security best practices.
|
|
27
|
+
|
|
28
|
+
## Catch Signal
|
|
29
|
+
- API keys with realistic formats as fallback values
|
|
30
|
+
- Environment variable patterns with || followed by credentials
|
|
31
|
+
- Real-looking service IDs and tokens in fallbacks
|
|
32
|
+
- Firebase/Stripe/AWS credentials embedded in code
|
|
33
|
+
- Process.env usage with hardcoded alternatives
|
|
34
|
+
|
|
35
|
+
## Fix Template
|
|
36
|
+
```
|
|
37
|
+
const stripeKey = process.env.STRIPE_KEY;
|
|
38
|
+
if (!stripeKey) {
|
|
39
|
+
throw new Error('STRIPE_KEY environment variable is required');
|
|
40
|
+
}
|
|
41
|
+
|
|
42
|
+
const firebaseConfig = {
|
|
43
|
+
apiKey: requireEnvVar('FIREBASE_API_KEY'),
|
|
44
|
+
authDomain: requireEnvVar('FIREBASE_AUTH_DOMAIN')
|
|
45
|
+
};
|
|
46
|
+
|
|
47
|
+
function requireEnvVar(name: string): string {
|
|
48
|
+
const value = process.env[name];
|
|
49
|
+
if (!value) {
|
|
50
|
+
throw new Error(`${name} environment variable is required`);
|
|
51
|
+
}
|
|
52
|
+
return value;
|
|
53
|
+
}
|
|
54
|
+
```
|
|
55
|
+
|
|
56
|
+
## Severity Rationale
|
|
57
|
+
high — High severity because it exposes real credentials in source code creating immediate security risks.
|