@in-the-loop-labs/pair-review 3.2.1 → 3.2.3

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@in-the-loop-labs/pair-review",
-  "version": "3.2.1",
+  "version": "3.2.3",
   "description": "Your AI-powered code review partner - Close the feedback loop with AI coding agents",
   "main": "src/server.js",
   "bin": {
@@ -81,5 +81,10 @@
     "jsdom": "^29.0.1",
     "supertest": "^7.1.4",
     "vitest": "^4.0.16"
+  },
+  "pnpm": {
+    "onlyBuiltDependencies": [
+      "better-sqlite3"
+    ]
   }
 }

package/plugin/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "pair-review",
-  "version": "3.2.1",
+  "version": "3.2.3",
   "description": "pair-review app integration — Open PRs and local changes in the pair-review web UI, run server-side AI analysis, and address review feedback. Requires the pair-review MCP server.",
   "author": {
     "name": "in-the-loop-labs",

package/plugin-code-critic/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "code-critic",
-  "version": "3.2.1",
+  "version": "3.2.3",
   "description": "AI-powered code review analysis — Run three-level AI analysis and implement-review-fix loops directly in your coding agent. Works standalone, no server required.",
   "author": {
     "name": "in-the-loop-labs",

package/plugin-code-critic/skills/analyze/references/orchestration-balanced.md

@@ -97,6 +97,14 @@ Prioritize suggestions in this order:
 - **Preserve reviewer autonomy** - you're a pair programming partner, not an enforcer
 - **Provide context** for why each suggestion matters to the reviewer
 
+## Summary Structure
+The summary field should synthesize the findings, but it should not be one big paragraph.
+- Start with 1-2 sentences describing the overall assessment
+- Then include a markdown bullet list using "- " bullets for the key specific points
+- After the bullets, add extra sentences or short paragraphs only when needed for requested context or follow-up detail
+- Focus on WHAT was found, not HOW it was found
+- Write as if a single reviewer produced this analysis
+
 ## Output Format
 
 **>>> CRITICAL: Output ONLY valid JSON. No markdown, no ```json blocks. Start with { end with }. <<<**
@@ -126,7 +134,7 @@ Output JSON with this structure:
     "confidence": 0.0-1.0,
     "reasoning": ["Step-by-step reasoning explaining why this issue was flagged (optional)"]
   }],
-  "summary": "Brief summary of the key findings and their significance to the reviewer. Focus on WHAT was found, not HOW it was found. Do NOT mention 'orchestration', 'levels', 'merged from Level 1/2/3' etc. Write as if a single reviewer produced this analysis."
+  "summary": "Formatted markdown summary following the Summary Structure guidance above."
 }
 
 ### GitHub Suggestion Syntax

package/plugin-code-critic/skills/analyze/references/orchestration-fast.md

@@ -76,6 +76,13 @@ Max 2-3 praise items. Prefer line-level over file-level. Include actionable sugg
 ### Framing
 Use "Consider...", "Worth noting..." - guidance not mandates.
 
+### Summary
+The summary field should be markdown, not one big paragraph.
+- Start with 1-2 sentences describing the overall assessment
+- Then include a markdown bullet list using "- " bullets for the key specific points
+- After the bullets, add extra sentences or short paragraphs only when needed for requested context or follow-up detail
+- Write as a single reviewer; do not mention levels or orchestration
+
 ## JSON Schema
 {
   "level": "orchestrated",
@@ -99,7 +106,7 @@ Use "Consider...", "Worth noting..." - guidance not mandates.
     "suggestion": "How to fix (omit for praise)",
     "confidence": 0.0-1.0
   }],
-  "summary": "Key findings as if from single reviewer (no mention of levels/orchestration)"
+  "summary": "Formatted markdown summary following the Summary guidance above."
 }
 
 ### GitHub Suggestion Syntax

package/plugin-code-critic/skills/analyze/references/orchestration-thorough.md

@@ -212,20 +212,21 @@ Frame all suggestions as guidance for a human reviewer, not automated mandates:
 Note: Confidence is about certainty of value, not severity. A minor improvement suggestion can have high confidence if you're sure it's helpful.
 
 ## Summary Synthesis Guidance
-The summary field is not a list of findings - it's a synthesis that helps the reviewer see the forest, not just the trees.
+The summary field should help the reviewer see the forest, not just the trees, but it should not be one big paragraph.
 
 **Effective Summary Approach:**
-- **Synthesize, don't summarize**: Identify the overarching narrative of this PR's quality and concerns
-- **Lead with the most important insight**: What single thing should the reviewer understand first?
-- **Connect the dots**: How do individual findings relate to each other or to a common theme?
-- **Calibrate severity**: Is this PR fundamentally sound with minor issues, or does it have structural problems?
+- **Start with 1-2 sentences of overall assessment**: Identify the overarching narrative of this PR's quality and concerns
+- **Then use a markdown bullet list with "- " bullets**: Capture the key specific points the reviewer should track
+- **Connect the dots**: Make the overview and bullets feel like one coherent review
+- **Calibrate severity**: Make clear whether this PR is fundamentally sound with minor issues or has structural problems
+- **After the bullets, add extra sentences or short paragraphs only when needed**: Use them for requested context, caveats, or follow-up detail
 - **Respect reviewer time**: A good summary lets the reviewer decide where to focus attention
 
 **Summary Anti-patterns to Avoid:**
 - Listing findings ("Found 3 bugs, 2 improvements, 1 praise...")
 - Implementation details ("Merged Level 1 and Level 2 suggestions...")
 - Vague platitudes ("This PR has some issues to consider...")
-- Excessive length (2-3 sentences is ideal)
+- A single unbroken paragraph with no bullets
 
 ## Output Format
 
@@ -256,7 +257,7 @@ Output JSON with this structure:
     "confidence": 0.0-1.0,
     "reasoning": ["Step-by-step reasoning explaining why this issue was flagged"]
   }],
-  "summary": "Brief summary of the key findings and their significance to the reviewer. Focus on WHAT was found, not HOW it was found. Do NOT mention 'orchestration', 'levels', 'merged from Level 1/2/3' etc. Write as if a single reviewer produced this analysis."
+  "summary": "Formatted markdown summary following the Summary Synthesis Guidance above."
 }
 
 ### GitHub Suggestion Syntax

package/public/js/modules/analysis-history.js

@@ -205,9 +205,11 @@ class AnalysisHistoryManager {
   /**
    * Load analysis runs from the API (initial load only)
    *
-   * This method is intended for initial page load and always selects the latest run.
-   * For refreshing after a new analysis completes, use refresh() instead, which has
-   * logic to optionally preserve the user's current selection.
+   * This method is intended for initial page load. On first load it selects the
+   * latest run; on subsequent calls it preserves the current selection when that
+   * run still exists. For refreshing after a new analysis completes, use
+   * refresh(), which has logic to optionally preserve the user's current
+   * selection while surfacing a new run indicator.
    *
    * @returns {Promise<Array>} The loaded runs
    */
@@ -227,11 +229,13 @@ class AnalysisHistoryManager {
       return [];
     }
 
-    // Always select the latest run (first in the list since they're ordered by date DESC)
-    // This ensures that after a new analysis completes, its results are displayed
     const latestRun = this.runs[0];
-    const shouldTriggerCallback = !this.selectedRunId || String(this.selectedRunId) !== String(latestRun.id);
-    await this.selectRun(latestRun.id, shouldTriggerCallback);
+    const currentRun = this.selectedRunId
+      ? this.runs.find(run => String(run.id) === String(this.selectedRunId))
+      : null;
+    const runToSelect = currentRun || latestRun;
+    const shouldTriggerCallback = String(this.selectedRunId) !== String(runToSelect.id);
+    await this.selectRun(runToSelect.id, shouldTriggerCallback);
 
     // Render the dropdown (after selecting so the selected state is correct)
     this.renderDropdown(this.runs);

package/src/ai/analyzer.js

@@ -96,7 +96,7 @@ function buildVoiceContext(voice, idx, instructions, progressCallback, db) {
   const voiceProvider = isExecutable ? createProvider(voice.provider, voice.model) : null;
 
   const voiceTier = voice.tier || 'balanced';
-  const voiceTimeout = voice.timeout || 600000;
+  const voiceTimeout = voice.timeout || ProviderClass?.defaultTimeout || 600000;
 
   // Wrap progress callback with voice-centric metadata
   const voiceProgressCallback = progressCallback ? (update) => {
@@ -319,7 +319,10 @@ class Analyzer {
     const runId = options.runId || uuidv4();
     const { analysisId, skipRunCreation, skipLevel3, reviewerNum, excludePrevious, serverPort } = options;
     const logPrefix = options.logPrefix || '';
-    const executionTimeout = options.timeout || 600000; // Default 10 minutes
+    // Respect provider-configured timeout (e.g. Pi's 15 min, executable providers)
+    const ProviderClass = getProviderClass(this.provider);
+    const providerTimeout = ProviderClass?.defaultTimeout;
+    const executionTimeout = options.timeout || providerTimeout || 600000; // Default 10 minutes
 
     // Resolve enabledLevels: prefer explicit option, fall back to skipLevel3 compat
     const enabledLevels = options.enabledLevels
@@ -3396,6 +3399,7 @@ File-level suggestions should NOT have a line number. They apply to the entire f
             : voice.customInstructions;
         }
 
+        const VoiceProviderClass = getProviderClass(voice.provider);
         voiceTasks.push({
           voiceId,
           reviewerLabel,
@@ -3404,7 +3408,7 @@ File-level suggestions should NOT have a line number. They apply to the entire f
           provider: voice.provider,
           model: voice.model,
           tier,
-          timeout: voice.timeout || 600000,
+          timeout: voice.timeout || VoiceProviderClass?.defaultTimeout || 600000,
           customInstructions: voiceInstructions,
           voiceCustomInstructions: voice.customInstructions || null
         });

package/src/ai/executable-provider.js

@@ -522,6 +522,11 @@ function createExecutableProviderClass(id, config) {
   ExecProvider.getDefaultModel = () => resolveDefaultModel(models) || models[0]?.id;
   ExecProvider.getInstallInstructions = () => config.installInstructions || `Install ${id}`;
 
+  // Surface configured timeout so the UI can pre-populate TimeoutSelect
+  if (config.timeout != null) {
+    ExecProvider.defaultTimeout = config.timeout;
+  }
+
   // Flags for the system
   ExecProvider.isExecutable = true;
   const caps = config.capabilities || {};

package/src/ai/prompts/baseline/consolidation/balanced.js

@@ -123,9 +123,11 @@ Assess severity based on the evidence and reasoning across all reviewers. When r
 
 <section name="summary-synthesis" required="true">
 ## Summary Synthesis
-The summary field should synthesize the findings, not list them.
-- Synthesize the key findings into a single cohesive paragraph
-- **Draw on reviewer summaries**: Use these as evidence for your own synthesis — integrate their insights into a cohesive conclusion rather than listing them individually
+The summary field should synthesize the findings, but it should not be one big paragraph.
+- Start with 1-2 sentences describing the overall assessment
+- Then include a markdown bullet list using "- " bullets for the key specific points
+- **Draw on reviewer summaries**: Use these as evidence for your own synthesis — integrate their insights into the overview and bullets rather than listing reviewer-by-reviewer conclusions
+- After the bullets, add extra sentences or short paragraphs only when needed for requested context or follow-up detail
 - Write as if a single reviewer produced this analysis — do not mention consolidation, merging, or multiple reviewers
 </section>
 
@@ -160,7 +162,7 @@ Output JSON with this structure:
     "confidence": 0.0-1.0,
     "reasoning": ["Step-by-step reasoning explaining why this issue was flagged (optional)"]
   }],
-  "summary": "Single cohesive paragraph summarizing key findings. Write as a single reviewer."
+  "summary": "Formatted markdown summary following the Summary Synthesis guidance above."
 }
 
 ### GitHub Suggestion Syntax

package/src/ai/prompts/baseline/consolidation/fast.js

@@ -83,7 +83,11 @@ Deduplicate, don't concatenate: merge duplicate findings, preserve distinct ones
 </section>
 
 <section name="summary-synthesis" required="true" tier="fast">
-Draw on reviewer summaries as evidence for your own synthesis. Write one cohesive paragraph — no mention of consolidation/merging.
+Draw on reviewer summaries as evidence for your own synthesis. The summary field should be markdown, not one big paragraph.
+- Start with 1-2 sentences describing the overall assessment
+- Then include a markdown bullet list using "- " bullets for the key specific points
+- After the bullets, add extra sentences or short paragraphs only when needed for requested context or follow-up detail
+- Write as a single reviewer with no mention of consolidation or merging
 </section>
 
 <section name="output-schema" locked="true">
@@ -109,7 +113,7 @@ Draw on reviewer summaries as evidence for your own synthesis. Write one cohesiv
     "suggestion": "How to address the file-level concern (omit for praise items)",
     "confidence": 0.0-1.0
   }],
-  "summary": "Single cohesive paragraph of key findings. Write as single reviewer."
+  "summary": "Formatted markdown summary following the summary guidance above."
 }
 
 ### GitHub Suggestion Syntax

package/src/ai/prompts/baseline/consolidation/thorough.js

@@ -167,13 +167,14 @@ Note: Confidence is about certainty of value, not severity.
 
 <section name="summary-synthesis" required="true" tier="thorough">
 ## Summary Synthesis Guidance
-The summary field should synthesize the findings, not list them.
+The summary field should synthesize the findings, but it should not be one big paragraph.
 
 **Effective Summary Approach:**
-- **Lead with the most important insight**: What should the reviewer focus on first?
-- **Connect the dots**: How do individual findings relate to each other?
-- **Calibrate severity**: Is this code fundamentally sound with minor issues, or are there structural problems?
-- **Draw on reviewer summaries**: Use these as evidence for your own synthesis — integrate their insights into a cohesive conclusion rather than listing them individually.
+- **Start with 1-2 sentences of overall assessment**: Lead with the most important insight and calibrate the overall severity
+- **Then use a markdown bullet list with "- " bullets**: Capture the key specific points the reviewer should keep in view
+- **Connect the dots**: Make the overview and bullets feel like one coherent review, not disconnected fragments
+- **Draw on reviewer summaries**: Use these as evidence for your own synthesis — integrate their insights into the overview and bullets rather than listing reviewer-by-reviewer conclusions.
+- **After the bullets, add extra sentences or short paragraphs only when needed**: Use them for requested context, caveats, or follow-up detail
 - **Write as a single reviewer**: Do not mention consolidation, merging, or multiple reviewers -- unless specifically requested
 </section>
 
@@ -208,7 +209,7 @@ Output JSON with this structure:
     "confidence": 0.0-1.0,
     "reasoning": ["Step-by-step reasoning explaining why this issue was flagged"]
   }],
-  "summary": "Single cohesive paragraph synthesizing key findings and their significance. Write as a single reviewer — do not mention consolidation, merging, or multiple reviewers."
+  "summary": "Formatted markdown summary following the Summary Synthesis Guidance above."
 }
 
 ### GitHub Suggestion Syntax

package/src/ai/prompts/baseline/orchestration/balanced.js

@@ -121,6 +121,16 @@ Prioritize suggestions in this order:
 - **Provide context** for why each suggestion matters to the reviewer
 </section>
 
+<section name="summary-synthesis" required="true">
+## Summary Structure
+The summary field should synthesize the findings, but it should not be one big paragraph.
+- Start with 1-2 sentences describing the overall assessment
+- Then include a markdown bullet list using "- " bullets for the key specific points
+- After the bullets, add extra sentences or short paragraphs only when needed for requested context or follow-up detail
+- Focus on WHAT was found, not HOW it was found
+- Write as if a single reviewer produced this analysis
+</section>
+
 <section name="output-schema" locked="true">
 ## Output Format
 
@@ -151,7 +161,7 @@ Output JSON with this structure:
     "confidence": 0.0-1.0,
     "reasoning": ["Step-by-step reasoning explaining why this issue was flagged (optional)"]
   }],
-  "summary": "Brief summary of the key findings and their significance to the reviewer. Focus on WHAT was found, not HOW it was found. Do NOT mention 'orchestration', 'levels', 'merged from Level 1/2/3' etc. Write as if a single reviewer produced this analysis."
+  "summary": "Formatted markdown summary following the Summary Structure guidance above."
 }
 
 ### GitHub Suggestion Syntax
@@ -218,6 +228,7 @@ const sections = [
   { name: 'priority-curation', required: true },
   { name: 'balanced-output', required: true },
   { name: 'human-centric-framing', required: true },
+  { name: 'summary-synthesis', required: true },
   { name: 'output-schema', locked: true },
   { name: 'diff-instructions', required: true },
   { name: 'file-level-guidance', optional: true, tier: ['balanced', 'thorough'] },
@@ -240,6 +251,7 @@ const defaultOrder = [
   'priority-curation',
   'balanced-output',
   'human-centric-framing',
+  'summary-synthesis',
   'output-schema',
   'diff-instructions',
   'file-level-guidance',

package/src/ai/prompts/baseline/orchestration/fast.js

@@ -103,6 +103,15 @@ Max 2-3 praise items. Prefer line-level over file-level. Include actionable sugg
 Use "Consider...", "Worth noting..." - guidance not mandates.
 </section>
 
+<section name="summary-synthesis" required="true" tier="fast">
+### Summary
+The summary field should be markdown, not one big paragraph.
+- Start with 1-2 sentences describing the overall assessment
+- Then include a markdown bullet list using "- " bullets for the key specific points
+- After the bullets, add extra sentences or short paragraphs only when needed for requested context or follow-up detail
+- Write as a single reviewer; do not mention levels or orchestration
+</section>
+
 <section name="output-schema" locked="true">
 ## JSON Schema
 {
@@ -127,7 +136,7 @@ Use "Consider...", "Worth noting..." - guidance not mandates.
     "suggestion": "How to fix (omit for praise)",
     "confidence": 0.0-1.0
   }],
-  "summary": "Key findings as if from single reviewer (no mention of levels/orchestration)"
+  "summary": "Formatted markdown summary following the Summary guidance above."
 }
 
 ### GitHub Suggestion Syntax
@@ -167,6 +176,7 @@ const sections = [
   { name: 'priority-curation', required: true, tier: ['fast'] },
   { name: 'balanced-output', required: true, tier: ['fast'] },
   { name: 'human-centric-framing', required: true, tier: ['fast'] },
+  { name: 'summary-synthesis', required: true, tier: ['fast'] },
   { name: 'output-schema', locked: true },
   { name: 'diff-instructions', required: true, tier: ['fast'] },
   { name: 'guidelines', required: true, tier: ['fast'] }
@@ -189,6 +199,7 @@ const defaultOrder = [
   'priority-curation',
   'balanced-output',
   'human-centric-framing',
+  'summary-synthesis',
   'output-schema',
   'diff-instructions',
   'guidelines'

package/src/ai/prompts/baseline/orchestration/thorough.js

@@ -248,20 +248,21 @@ Note: Confidence is about certainty of value, not severity. A minor improvement
 
 <section name="summary-synthesis" required="true" tier="thorough">
 ## Summary Synthesis Guidance
-The summary field is not a list of findings - it's a synthesis that helps the reviewer see the forest, not just the trees.
+The summary field should help the reviewer see the forest, not just the trees, but it should not be one big paragraph.
 
 **Effective Summary Approach:**
-- **Synthesize, don't summarize**: Identify the overarching narrative of this PR's quality and concerns
-- **Lead with the most important insight**: What single thing should the reviewer understand first?
-- **Connect the dots**: How do individual findings relate to each other or to a common theme?
-- **Calibrate severity**: Is this PR fundamentally sound with minor issues, or does it have structural problems?
+- **Start with 1-2 sentences of overall assessment**: Identify the overarching narrative of this PR's quality and concerns
+- **Then use a markdown bullet list with "- " bullets**: Capture the key specific points the reviewer should track
+- **Connect the dots**: Make the overview and bullets feel like one coherent review
+- **Calibrate severity**: Make clear whether this PR is fundamentally sound with minor issues or has structural problems
+- **After the bullets, add extra sentences or short paragraphs only when needed**: Use them for requested context, caveats, or follow-up detail
 - **Respect reviewer time**: A good summary lets the reviewer decide where to focus attention
 
 **Summary Anti-patterns to Avoid:**
 - Listing findings ("Found 3 bugs, 2 improvements, 1 praise...")
 - Implementation details ("Merged Level 1 and Level 2 suggestions...")
 - Vague platitudes ("This PR has some issues to consider...")
-- Excessive length (2-3 sentences is ideal)
+- A single unbroken paragraph with no bullets
 </section>
 
 <section name="output-schema" locked="true">
@@ -294,7 +295,7 @@ Output JSON with this structure:
     "confidence": 0.0-1.0,
     "reasoning": ["Step-by-step reasoning explaining why this issue was flagged"]
   }],
-  "summary": "Brief summary of the key findings and their significance to the reviewer. Focus on WHAT was found, not HOW it was found. Do NOT mention 'orchestration', 'levels', 'merged from Level 1/2/3' etc. Write as if a single reviewer produced this analysis."
+  "summary": "Formatted markdown summary following the Summary Synthesis Guidance above."
 }
 
 ### GitHub Suggestion Syntax