ira-review 3.1.7 → 3.1.8

package/dist/cli.js

@@ -269,9 +269,9 @@ var REVIEW_CHECKLIST = `
 `;
 var REVIEW_CATEGORIES = "security, business-logic, race-condition, data-consistency, async, error-handling, defensive, best-practice";
 var TEAM_RULES_PRECEDENCE = `
-**PRECEDENCE \u2014 Team Rules vs general checklist guidance.** When a Team Rule in the Team Rules section above has a \`bad:\` example whose pattern matches the diff, the Team Rule WINS over any "Do NOT report" / "Skip" clause in checklist sections 1\u20136, and over the general "style-only" / "when in doubt, do not report" framing in the Rules section. Report the violation, label it under Team Standards, and use the Team Rule's stated severity.
+**PRECEDENCE \u2014 Team Rules vs general checklist guidance.** When a Team Rule in the Team Rules section above semantically matches the code in the diff \u2014 i.e. the rule's \`description\` (or optional \`bad:\` example) clearly describes the pattern you see in the changed lines \u2014 the Team Rule WINS over any "Do NOT report" / "Skip" clause in checklist sections 1\u20136, and over the general "style-only" / "when in doubt, do not report" framing in the Rules section. Report the violation, label it under Team Standards, and use the Team Rule's stated severity. You do NOT need a literal \`bad:\` snippet \u2014 a clear, specific description is sufficient (e.g. "do not commit console.log statements" applies to any \`console.log(...)\` in the changed lines).
 
-**Exception \u2014 checklist Section 7 (Defensive Coding) is NOT overridden.** A Team Rule that loosely mentions "type safety", "best practices", "defensive coding", or similar broad concepts does NOT authorise reporting null/undefined check suggestions on values the type system, framework, or stdlib already guarantees. Only report null-handling issues that meet the strict criteria in Section 7 (i.e. a concrete runtime path to null with no guard). A Team Rule may only override Section 7 if it provides a specific \`bad:\` example that matches the exact code pattern in the diff.
+**Exception \u2014 checklist Section 7 (Defensive Coding) is NOT overridden by vague rules.** A Team Rule that only loosely mentions "type safety", "best practices", "defensive coding", or similar broad concepts does NOT authorise reporting null/undefined check suggestions on values the type system, framework, or stdlib already guarantees. To override Section 7 the rule must EITHER provide a specific \`bad:\` example matching the diff, OR have a description that names the exact defensive pattern required (e.g. "always null-check API response \`data\` before access").
 `;
 function buildStandalonePrompt(filePath, diff, framework, sourceFile, teamRulesSection, sensitiveAreaContext) {
   const frameworkContext = framework ? `The codebase uses **${framework}**. Tailor your review to ${framework} best practices.` : "";

package/dist/index.cjs

@@ -461,9 +461,9 @@ var REVIEW_CHECKLIST = `
 `;
 var REVIEW_CATEGORIES = "security, business-logic, race-condition, data-consistency, async, error-handling, defensive, best-practice";
 var TEAM_RULES_PRECEDENCE = `
-**PRECEDENCE \u2014 Team Rules vs general checklist guidance.** When a Team Rule in the Team Rules section above has a \`bad:\` example whose pattern matches the diff, the Team Rule WINS over any "Do NOT report" / "Skip" clause in checklist sections 1\u20136, and over the general "style-only" / "when in doubt, do not report" framing in the Rules section. Report the violation, label it under Team Standards, and use the Team Rule's stated severity.
+**PRECEDENCE \u2014 Team Rules vs general checklist guidance.** When a Team Rule in the Team Rules section above semantically matches the code in the diff \u2014 i.e. the rule's \`description\` (or optional \`bad:\` example) clearly describes the pattern you see in the changed lines \u2014 the Team Rule WINS over any "Do NOT report" / "Skip" clause in checklist sections 1\u20136, and over the general "style-only" / "when in doubt, do not report" framing in the Rules section. Report the violation, label it under Team Standards, and use the Team Rule's stated severity. You do NOT need a literal \`bad:\` snippet \u2014 a clear, specific description is sufficient (e.g. "do not commit console.log statements" applies to any \`console.log(...)\` in the changed lines).
 
-**Exception \u2014 checklist Section 7 (Defensive Coding) is NOT overridden.** A Team Rule that loosely mentions "type safety", "best practices", "defensive coding", or similar broad concepts does NOT authorise reporting null/undefined check suggestions on values the type system, framework, or stdlib already guarantees. Only report null-handling issues that meet the strict criteria in Section 7 (i.e. a concrete runtime path to null with no guard). A Team Rule may only override Section 7 if it provides a specific \`bad:\` example that matches the exact code pattern in the diff.
+**Exception \u2014 checklist Section 7 (Defensive Coding) is NOT overridden by vague rules.** A Team Rule that only loosely mentions "type safety", "best practices", "defensive coding", or similar broad concepts does NOT authorise reporting null/undefined check suggestions on values the type system, framework, or stdlib already guarantees. To override Section 7 the rule must EITHER provide a specific \`bad:\` example matching the diff, OR have a description that names the exact defensive pattern required (e.g. "always null-check API response \`data\` before access").
 `;
 function buildStandalonePrompt(filePath, diff, framework, sourceFile, teamRulesSection, sensitiveAreaContext) {
   const frameworkContext = framework ? `The codebase uses **${framework}**. Tailor your review to ${framework} best practices.` : "";