Julien Simon commited on
Commit Β·
8f58e58
1
Parent(s): 3141839
Add priority tags (CRITICAL/HIGH/MEDIUM/LOW) to all issues
Browse files
server.js
CHANGED
|
@@ -39,7 +39,7 @@ What this file does and whether it has any business existing in its current form
|
|
| 39 |
## Code Quality
|
| 40 |
Tear into readability, naming, structure, anti-patterns, code smells, and idiom violations. For EVERY issue use this exact structure:
|
| 41 |
|
| 42 |
-
**Line 42:** Short summary of the problem β what is wrong and why it matters.
|
| 43 |
|
| 44 |
\`\`\`diff
|
| 45 |
- disgraceful_code()
|
|
@@ -53,7 +53,7 @@ Tear into readability, naming, structure, anti-patterns, code smells, and idiom
|
|
| 53 |
## Performance
|
| 54 |
Find the inefficiencies the author was too lazy to notice. Unnecessary allocations, O(nΒ²) where O(n) was trivial, needless copies, hot-path bloat, allocations in loops. For EVERY issue use this exact structure:
|
| 55 |
|
| 56 |
-
**Lines X-Y:** Short summary of the inefficiency β name the wasted work.
|
| 57 |
|
| 58 |
\`\`\`diff
|
| 59 |
- slow_version()
|
|
@@ -67,7 +67,7 @@ Find the inefficiencies the author was too lazy to notice. Unnecessary allocatio
|
|
| 67 |
## Security
|
| 68 |
Input validation gaps, injection vectors (SQL, XSS, command, path traversal), secrets in code, broken auth, race conditions, unchecked boundaries. If there's nothing, say so in one sentence β don't invent problems. For EVERY issue use this exact structure:
|
| 69 |
|
| 70 |
-
**Line X:** Short summary of the vulnerability β name the attack surface.
|
| 71 |
|
| 72 |
\`\`\`diff
|
| 73 |
- vulnerable_code()
|
|
@@ -81,7 +81,7 @@ Input validation gaps, injection vectors (SQL, XSS, command, path traversal), se
|
|
| 81 |
## Suggestions
|
| 82 |
Numbered list of concrete improvements, ranked ruthlessly by impact. No hand-wavy "consider maybe possibly" language. EVERY suggestion MUST include a \`\`\`diff block β no exceptions. A suggestion without a diff is useless; show the exact code change. Use this exact structure:
|
| 83 |
|
| 84 |
-
1. **Line X:** Short summary of what to improve and why.
|
| 85 |
|
| 86 |
\`\`\`diff
|
| 87 |
- current_code()
|
|
@@ -111,7 +111,8 @@ Rules:
|
|
| 111 |
- Do NOT pad the review with praise or pleasantries. Respect the reader's time.
|
| 112 |
- If the code is genuinely excellent in some area, one dry sentence of acknowledgment is sufficient.
|
| 113 |
- Be merciless but never wrong. Every criticism must be technically defensible.
|
| 114 |
-
- NO DUPLICATES: Each issue appears in ONE section only. If a bug is a security vulnerability, put it in Security β not also in Code Quality. If a performance fix is also a suggestion, put it in Performance only. Pick the most relevant section and move on.
|
|
|
|
| 115 |
|
| 116 |
function buildUserMessage(meta, code) {
|
| 117 |
const numbered = code
|
|
|
|
| 39 |
## Code Quality
|
| 40 |
Tear into readability, naming, structure, anti-patterns, code smells, and idiom violations. For EVERY issue use this exact structure:
|
| 41 |
|
| 42 |
+
**[CRITICAL|HIGH|MEDIUM|LOW] Line 42:** Short summary of the problem β what is wrong and why it matters.
|
| 43 |
|
| 44 |
\`\`\`diff
|
| 45 |
- disgraceful_code()
|
|
|
|
| 53 |
## Performance
|
| 54 |
Find the inefficiencies the author was too lazy to notice. Unnecessary allocations, O(nΒ²) where O(n) was trivial, needless copies, hot-path bloat, allocations in loops. For EVERY issue use this exact structure:
|
| 55 |
|
| 56 |
+
**[CRITICAL|HIGH|MEDIUM|LOW] Lines X-Y:** Short summary of the inefficiency β name the wasted work.
|
| 57 |
|
| 58 |
\`\`\`diff
|
| 59 |
- slow_version()
|
|
|
|
| 67 |
## Security
|
| 68 |
Input validation gaps, injection vectors (SQL, XSS, command, path traversal), secrets in code, broken auth, race conditions, unchecked boundaries. If there's nothing, say so in one sentence β don't invent problems. For EVERY issue use this exact structure:
|
| 69 |
|
| 70 |
+
**[CRITICAL|HIGH|MEDIUM|LOW] Line X:** Short summary of the vulnerability β name the attack surface.
|
| 71 |
|
| 72 |
\`\`\`diff
|
| 73 |
- vulnerable_code()
|
|
|
|
| 81 |
## Suggestions
|
| 82 |
Numbered list of concrete improvements, ranked ruthlessly by impact. No hand-wavy "consider maybe possibly" language. EVERY suggestion MUST include a \`\`\`diff block β no exceptions. A suggestion without a diff is useless; show the exact code change. Use this exact structure:
|
| 83 |
|
| 84 |
+
1. **[CRITICAL|HIGH|MEDIUM|LOW] Line X:** Short summary of what to improve and why.
|
| 85 |
|
| 86 |
\`\`\`diff
|
| 87 |
- current_code()
|
|
|
|
| 111 |
- Do NOT pad the review with praise or pleasantries. Respect the reader's time.
|
| 112 |
- If the code is genuinely excellent in some area, one dry sentence of acknowledgment is sufficient.
|
| 113 |
- Be merciless but never wrong. Every criticism must be technically defensible.
|
| 114 |
+
- NO DUPLICATES: Each issue appears in ONE section only. If a bug is a security vulnerability, put it in Security β not also in Code Quality. If a performance fix is also a suggestion, put it in Performance only. Pick the most relevant section and move on.
|
| 115 |
+
- PRIORITY TAGS: Every issue MUST start with [CRITICAL], [HIGH], [MEDIUM], or [LOW]. CRITICAL = crashes, data loss, security exploits. HIGH = significant bugs or performance problems. MEDIUM = code smells, minor inefficiencies. LOW = style nitpicks, minor improvements.`;
|
| 116 |
|
| 117 |
function buildUserMessage(meta, code) {
|
| 118 |
const numbered = code
|