@contextrail/code-review-agent 0.1.2-alpha.1 → 0.1.2-alpha.3

package/dist/reviewers/prompt.js

@@ -1,133 +1,8 @@
-import { isDiffInputs } from '../review-inputs/index.js';
-/**
- * Severity calibration block with definitions and examples for each severity level.
- * This block is injected into reviewer system prompts to ensure consistent severity assignment.
- */
-export const SEVERITY_CALIBRATION_BLOCK = `
-## Severity Calibration
-
-You must assign severity levels accurately based on the following definitions and examples:
-
-### Critical
-**Definition**: Blocks deployment, active exploit path, or data corruption risk. Findings that could lead to security breaches, data loss, or system compromise.
-
-**Examples**:
-- SQL injection vulnerability: \`const query = \`SELECT * FROM users WHERE id = \${userInput}\`;\` (user input directly interpolated)
-- Authentication bypass: \`if (user.role === 'admin' || user.id === 1) { grantAccess(); }\` (hardcoded admin check)
-- Missing input validation on sensitive operations: \`await db.delete(userId);\` (no validation that userId belongs to requester)
-
-**When to use**: Only when there is a clear exploit path or risk of data corruption/integrity violation.
-
-### Major
-**Definition**: Significant bug, breaks functionality, or violates established patterns. Findings that cause incorrect behavior or violate architectural standards.
-
-**Examples**:
-- Missing error handling: \`const data = await fetch(url); return data.json();\` (no try-catch, will crash on network error)
-- Tight coupling: \`import { DatabaseConnection } from './db'; class UserService { private db = new DatabaseConnection(); }\` (direct instantiation, violates dependency injection)
-- Race condition: \`let count = 0; async function increment() { count++; await save(count); }\` (non-atomic increment)
-
-**When to use**: When functionality is broken or architectural patterns are violated, but no immediate security/data risk.
-
-### Minor
-**Definition**: Code quality issue, convention violation, or maintainability concern. Findings that don't break functionality but reduce code quality.
-
-**Examples**:
-- Magic numbers: \`if (user.age > 18) { ... }\` (should be \`const MIN_ADULT_AGE = 18\`)
-- Inconsistent naming: \`function getUserData() { ... }\` but \`function fetch_user_info() { ... }\` (mixed naming conventions)
-- Missing JSDoc: \`function calculateTotal(items) { ... }\` (no documentation for complex logic)
-
-**When to use**: Code quality, readability, or maintainability issues that don't affect functionality.
-
-### Info
-**Definition**: Observation, suggestion, or educational note. Findings that provide helpful context or suggestions without indicating a problem.
-
-**Examples**:
-- Performance suggestion: \`// Consider caching this query result if called frequently\`
-- Pattern suggestion: \`// This could use the Repository pattern for better testability\`
-- Documentation opportunity: \`// This algorithm implements the Fisher-Yates shuffle\`
-
-**When to use**: Helpful suggestions or observations that don't indicate actual problems.
-`;
-/**
- * Severity validation rules for critic pass (iteration 2+).
- * These rules help the critic validate and potentially downgrade severity.
- */
-export const SEVERITY_VALIDATION_RULES = `
-## Severity Validation Rules
-
-During the critic pass, validate each finding's severity against these rules:
-
-1. **Critical findings MUST have exploit path or data integrity evidence**
-   - If a critical finding lacks a clear exploit path or data corruption risk described in the rationale, downgrade to major
-   - Example: "SQL injection" without showing how user input reaches the query → downgrade to major
-
-2. **Major findings MUST demonstrate functional impact**
-   - If a major finding doesn't show how functionality is broken or patterns violated, downgrade to minor
-   - Example: "Missing error handling" without showing what breaks → downgrade to minor
-
-3. **Minor findings MUST indicate code quality impact**
-   - If a minor finding is just a style preference without maintainability impact, consider downgrade to info
-   - Example: "Use const instead of let" without explaining why → consider info
-
-4. **Downgrade rules**:
-   - Critical → Major: No exploit path or data integrity risk described
-   - Major → Minor: No functional impact demonstrated
-   - Minor → Info: No code quality/maintainability impact shown
-
-5. **Never upgrade severity** - Only downgrade if evidence doesn't support the assigned level
-`;
-/**
- * ContextRail tooling workflow requirements.
- * Forces reviewers to ground findings in retrieved contexts instead of guessing IDs/titles.
- */
-export const CONTEXTRAIL_TOOLING_BLOCK = `
-## ContextRail Standards Workflow (Required)
-
-When you identify potential issues, you MUST ground them in retrieved ContextRail standards:
-
-1. Use \`search_contexts\` first to discover relevant standards for this change.
-2. Use \`get_context\` for each context you plan to cite in findings.
-3. Use \`resolve_dependencies\` when cited contexts have required dependencies.
-4. Perform at least one \`search_contexts\` call before finalizing your findings.
-
-Attribution rules:
-- NEVER invent context IDs or titles.
-- Only include \`contextIdsUsed\`, \`contextIdsViolated\`, and \`contextTitles\` from contexts you actually retrieved.
-- If no relevant ContextRail standard exists after tool lookup, set those fields to \`null\` (not empty arrays) and explain that briefly in \`rationale\`.
-`;
-/**
- * Compact output contract optimized for structured-output reliability.
- * Keeps formatting constraints in one place for both standard and critic prompts.
- */
-export const OUTPUT_CONTRACT_BLOCK = `
-## Output Contract (Strict)
-
-Return a JSON object with:
-- \`findings\`: array
-- \`validated\`: boolean
-- \`notes\`: string | null
-
-For each finding:
-- Required keys: \`severity\`, \`title\`, \`description\`, \`rationale\`
-- Optional-but-required-by-schema keys: \`suggestedFix\`, \`file\`, \`line\`, \`endLine\`, \`contextIdsUsed\`, \`contextIdsViolated\`, \`contextTitles\`
-
-Schema compatibility rules:
-- Include all keys (never omit)
-- Use \`null\` when a value is not available
-- Use \`null\` (not empty arrays) for context attribution fields when no standards apply
-`;
-/**
- * Final guardrail checklist near generation point.
- * Repeats only non-negotiables to reduce mid-prompt loss on long inputs.
- */
-export const FINAL_CHECKLIST_BLOCK = `
-## Final Checklist (Must Pass)
-1. Every finding is supported by concrete code/diff evidence.
-2. ContextRail workflow was used (\`search_contexts\` -> \`get_context\` -> \`resolve_dependencies\` as needed).
-3. Context attribution fields only reference retrieved contexts (or are \`null\`).
-4. Severity is calibrated to evidence.
-5. Output strictly matches the JSON contract, and \`notes\` summarizes retrieved contexts (or none found).
-`;
+import { SEVERITY_CALIBRATION_BLOCK } from '../prompts/blocks.js';
+// Re-export blocks for backward compatibility
+export { SEVERITY_CALIBRATION_BLOCK, SEVERITY_VALIDATION_RULES, CONTEXTRAIL_TOOLING_BLOCK, OUTPUT_CONTRACT_BLOCK, FINAL_CHECKLIST_BLOCK, } from '../prompts/blocks.js';
+// Re-export prompt builders for backward compatibility
+export { buildCriticPrompt, buildStandardReviewPrompt, buildReviewerUserMessage } from '../prompts/reviewer.js';
 export const buildPromptMessages = (promptResult) => {
     return promptResult.messages.map((message) => {
         const role = message.role === 'user' ? 'user' : message.role === 'assistant' ? 'assistant' : 'system';
@@ -139,108 +14,3 @@ export const buildPromptMessages = (promptResult) => {
         return { role, content };
     });
 };
-/**
- * Build a critic prompt that challenges findings from a previous iteration.
- * The critic pass validates findings, removes false positives, and enforces evidence/standards.
- */
-const buildCriticPrompt = (inputs, understanding, findings, prDescription, reviewDomains) => {
-    const diffBlock = isDiffInputs(inputs)
-        ? `\nDiffs:\n${Object.entries(inputs.diffs)
-            .map(([file, diff]) => `\n## ${file}\n\`\`\`diff\n${diff}\n\`\`\``)
-            .join('\n')}`
-        : '';
-    const contextBlock = inputs.context && Object.keys(inputs.context).length > 0
-        ? `\n\nSurrounding Code Context:\n${Object.entries(inputs.context)
-            .map(([file, context]) => `\n## ${file}\n\`\`\`\n${context}\n\`\`\``)
-            .join('\n')}`
-        : '';
-    const prDescriptionBlock = prDescription ? `\n\nPR Description:\n${prDescription}\n` : '';
-    const reviewDomainsBlock = reviewDomains && reviewDomains.length > 0
-        ? `\n\nReview Focus Domains:\n${reviewDomains.map((domain) => `- ${domain}`).join('\n')}\n`
-        : '';
-    return `You are performing a CRITIC PASS to validate and challenge findings from the previous iteration.
-
-Your role is to:
-1. Challenge each finding - require concrete evidence from the code or ContextRail standards
-2. Remove false positives - findings that lack evidence or don't violate actual standards
-3. Enforce ContextRail standards - each finding MUST be grounded in retrieved contexts
-4. Validate severity - ensure severity matches the actual risk level using the severity validation rules below
-5. Only keep findings that are:
-   - Supported by evidence in the code/diffs
-   - Linked to specific ContextRail standards (contextIdsUsed or contextIdsViolated)
-   - Accurately categorized by severity
-
-${SEVERITY_VALIDATION_RULES}
-${CONTEXTRAIL_TOOLING_BLOCK}
-
-Context:
-${understanding}
-${prDescriptionBlock}${reviewDomainsBlock}
-Files:
-${inputs.files.map((f) => `- ${f}`).join('\n')}
-${diffBlock}${contextBlock}
-
-Previous findings (iteration 1) - CRITICALLY REVIEW THESE:
-${JSON.stringify(findings.findings, null, 2)}
-
-For each finding, ask yourself:
-- Is there concrete evidence in the code/diffs that supports this finding?
-- Does this finding reference specific ContextRail standards (contextIdsUsed or contextIdsViolated)?
-- Is the severity appropriate for the actual risk? (Apply severity validation rules above)
-- Could this be a false positive that should be removed?
-- Should the severity be downgraded based on the validation rules?
-
-Output requirements:
-- Remove any findings that lack evidence
-- Remove findings that claim ContextRail impact but do not include retrieved context attribution
-- Keep only findings that are well-supported and properly attributed
-- Validate severity using the rules above - downgrade if evidence doesn't support the assigned level
-- Set validated: true only if all remaining findings meet these criteria
-- Always include notes field: use a string when you have notes, or null when none
-- If you remove findings or downgrade severity, explain why in notes
-- In notes, summarize which ContextRail contexts were retrieved (or state that none were relevant after tool lookup)
-
-${OUTPUT_CONTRACT_BLOCK}
-${FINAL_CHECKLIST_BLOCK}`;
-};
-/**
- * Build a standard reviewer prompt for initial review (iteration 1).
- */
-const buildStandardReviewPrompt = (inputs, understanding, prDescription, reviewDomains) => {
-    const diffBlock = isDiffInputs(inputs)
-        ? `\nDiffs:\n${Object.entries(inputs.diffs)
-            .map(([file, diff]) => `\n## ${file}\n\`\`\`diff\n${diff}\n\`\`\``)
-            .join('\n')}`
-        : '';
-    const contextBlock = inputs.context && Object.keys(inputs.context).length > 0
-        ? `\n\nSurrounding Code Context:\n${Object.entries(inputs.context)
-            .map(([file, context]) => `\n## ${file}\n\`\`\`\n${context}\n\`\`\``)
-            .join('\n')}`
-        : '';
-    const prDescriptionBlock = prDescription ? `\n\nPR Description:\n${prDescription}\n` : '';
-    const reviewDomainsBlock = reviewDomains && reviewDomains.length > 0
-        ? `\n\nReview Focus Domains:\n${reviewDomains.map((domain) => `- ${domain}`).join('\n')}\n`
-        : '';
-    return `Review these changes using the reviewer prompt guidance.
-
-Context:
-${understanding}
-${prDescriptionBlock}${reviewDomainsBlock}
-Files:
-${inputs.files.map((f) => `- ${f}`).join('\n')}
-${diffBlock}${contextBlock}
-
-Please review these changes and provide findings.
-
-${CONTEXTRAIL_TOOLING_BLOCK}
-${OUTPUT_CONTRACT_BLOCK}
-${FINAL_CHECKLIST_BLOCK}`;
-};
-export const buildReviewerUserMessage = (inputs, understanding, iteration, findings, prDescription, reviewDomains) => {
-    // Use critic pass for iteration 2+
-    if (iteration > 1 && findings) {
-        return buildCriticPrompt(inputs, understanding, findings, prDescription, reviewDomains);
-    }
-    // Use standard review for iteration 1
-    return buildStandardReviewPrompt(inputs, understanding, prDescription, reviewDomains);
-};

package/package.json

@@ -1,6 +1,6 @@
 {
     "name": "@contextrail/code-review-agent",
-    "version": "0.1.2-alpha.1",
+    "version": "0.1.2-alpha.3",
     "description": "CLI tool for orchestrating ContextRail-powered code reviews",
     "homepage": "https://contextrail.app",
     "repository": {