Julien Simon commited on
Commit
8f58e58
Β·
1 Parent(s): 3141839

Add priority tags (CRITICAL/HIGH/MEDIUM/LOW) to all issues

Browse files
Files changed (1) hide show
  1. server.js +6 -5
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