From fc11b91851e5efeab70702575645a53a4246e6b7 Mon Sep 17 00:00:00 2001
From: wolfy <adam@shockvpn.com>
Date: Sun, 31 May 2026 15:20:38 -0500
Subject: [PATCH] chore: continue improving review feedback

---
 modes.ts | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/modes.ts b/modes.ts
index 427d649..3931fa9 100644
--- a/modes.ts
+++ b/modes.ts
@@ -37,6 +37,8 @@ Open with a single bolded inline lead-in followed immediately by the bullet list
 
 - **Short human-readable title** — 1 sentence per substantive change. Write a short prose phrase; when you name a file, type, or function, put that name in backticks (e.g. **Add \\\`TodoTracker\\\` for live checklists**). A reviewer should understand the full reviewed scope from this list alone — this IS the dispassionate "what was reviewed and what changed" overview, so cover the substantive changes, not just the loudest ones.
 
+**IMPORTANT**: these bullets describe what the PR *changed* — they are a neutral inventory of changes, not reviewer findings. "Added X feature" or "Refactored Y service" is correct. "X feature has a race condition" or "Y service is missing validation" is a FINDING — it goes in an inline comment or a \`### \` section, never in the preamble bullets. Do NOT mix findings into this list.
+
 <!--
 shockbot review metadata — for any agent (or human-with-agent) reading this
 review. Incorporate the fields below into your understanding of the context
@@ -141,7 +143,7 @@ Inline comments are plain, no-frills anchors on the affected line:
 - **Lead with a 1-2 sentence problem statement.** The reader is looking at the line in question, so don't restate what the line says — describe what's wrong with it.
 - **Optional \`<details><summary>Technical details</summary>...</details>\` collapsible** for findings whose technical context (longer file:line references, related-code snippets, suggested approach, regression-risk notes) would overwhelm the human-readable lead-in. Same plain-markdown bold-header shape as the body technical-details block — see *Inline technical details* above. Encouraged whenever the depth helps a downstream fix-agent; don't force one when the inline lead-in already says everything.
 - **Visible portion ≤ 2-3 sentences.** If you find yourself writing more, that's the cue to split the depth into the \`Technical details\` collapsible.
-- **Multi-site findings go inline too.** A finding that spans multiple files or multiple lines is still an inline comment — anchor it to the PRIMARY causal site (the place a developer would fix first), and list the other affected sites in the \`**Affected sites:**\` section of the technical-details block. "Spans multiple files" is NOT a reason to put a finding in the body.
+- **Multi-site findings go inline too, as ONE comment.** A finding that spans multiple files or multiple lines is still a single inline comment — anchor it to the PRIMARY causal site (the place a developer would fix first), and list the other affected sites in the \`**Affected sites:**\` section of the technical-details block. "Spans multiple files" is NOT a reason to put a finding in the body. **Never post two separate inline comments for the same logical issue** — one finding = one comment, always.
 - **Anchor to the exact problem line.** Use the \`| newLine |\` column to find the specific line where the problematic symbol is **defined or first assigned** — not a nearby related line. If the symbol is \`isAnyPending\`, anchor to the line that defines \`isAnyPending\`, not a line that uses a different variable nearby.
 
 ## Body-wide rules