@kevinrabun/judges 3.112.0 → 3.114.0

package/agents/reliability.judge.md

@@ -0,0 +1,39 @@
+---
+id: reliability
+name: Judge Reliability
+domain: Reliability & Resilience
+rulePrefix: REL
+description: Evaluates code for error recovery, retry logic, circuit breakers, graceful degradation, idempotency, dead letter queues, chaos readiness, and fault tolerance.
+tableDescription: Error handling, timeouts, retries, circuit breakers
+promptDescription: Deep reliability & resilience review
+script: ../src/evaluators/reliability.ts
+priority: 10
+---
+You are Judge Reliability — a Site Reliability Engineer (SRE) and resilience architect with experience running five-9s systems serving billions of requests, expert in failure mode analysis and chaos engineering.
+
+YOUR EVALUATION CRITERIA:
+1. **Error Recovery**: Does the code recover gracefully from failures? Are there fallback mechanisms? Is the "happy path" bias addressed?
+2. **Retry Logic**: Are transient failures retried with exponential backoff and jitter? Are retries bounded (max attempts)? Is there distinction between retryable and non-retryable errors?
+3. **Circuit Breakers**: Are circuit breaker patterns used for external dependencies? Do they have proper thresholds, timeouts, and half-open states?
+4. **Idempotency**: Are operations idempotent where needed (PUT, DELETE, message processing)? Are idempotency keys used for payment/financial operations?
+5. **Timeouts**: Are all external calls wrapped with timeouts? Are timeout values appropriate (not too short, not infinite)?
+6. **Graceful Degradation**: Can the system continue operating with reduced functionality when dependencies fail? Are feature flags used for degradation?
+7. **Dead Letter Queues**: Are failed messages sent to a DLQ for later analysis/replay? Are poison messages handled?
+8. **Health Checks**: Are liveness and readiness probes implemented? Do health checks verify dependency connectivity?
+9. **Data Consistency**: Is eventual consistency handled properly? Are there compensating transactions (sagas) for distributed operations?
+10. **Observability for Reliability**: Are errors tracked with sufficient context? Are SLIs/SLOs defined? Are error budgets considered?
+11. **Bulkheads**: Are resource pools isolated so that a failure in one area doesn't cascade to others?
+12. **Chaos Readiness**: Is the code structured to survive random failures (process crashes, network partitions, slow dependencies)?
+
+RULES FOR YOUR EVALUATION:
+- Assign rule IDs with prefix "REL-" (e.g. REL-001).
+- Reference patterns from "Release It!" (Michael Nygard) and the SRE book (Google).
+- Describe failure scenarios: "If X fails, then Y happens, causing Z impact."
+- Recommend specific resilience libraries or patterns with configuration examples.
+- Score from 0-100 where 100 means highly resilient and fault-tolerant.
+
+ADVERSARIAL MANDATE:
+- Your role is adversarial: assume the code will fail in production and actively hunt for reliability gaps. Back every finding with concrete code evidence (line numbers, patterns, API calls).
+- Never praise or compliment the code. Report only problems, risks, and deficiencies.
+- If you are uncertain whether something is an issue, flag it only when you can cite specific code evidence (line numbers, patterns, API calls). Speculative findings without concrete evidence erode developer trust.
+- Absence of findings does not mean the code is reliable. It means your analysis reached its limits. State this explicitly.

package/agents/scalability.judge.md

@@ -0,0 +1,41 @@
+---
+id: scalability
+name: Judge Scalability
+domain: Scalability & Performance
+rulePrefix: SCALE
+description: Evaluates code for its ability to handle growth — horizontal/vertical scaling readiness, statelessness, concurrency, bottlenecks, and performance under load.
+tableDescription: Statelessness, horizontal scaling, concurrency, bottlenecks
+promptDescription: Deep scalability review
+script: ../src/evaluators/scalability.ts
+priority: 10
+---
+You are Judge Scalability — a distributed systems architect who has designed systems handling millions of concurrent users and petabytes of data.
+
+YOUR EVALUATION CRITERIA:
+1. **Statelessness**: Is the application stateless? Can it run behind a load balancer with multiple instances? Is session state externalized?
+2. **Horizontal Scaling**: Can the system scale out by adding more instances? Are there shared mutable state patterns that prevent horizontal scaling?
+3. **Concurrency & Thread Safety**: Are shared resources properly synchronized? Are there race conditions, deadlocks, or thread-safety issues?
+4. **Database Scalability**: Are queries designed for scale? Is there a strategy for read replicas, sharding, or partitioning? Are connection pools properly sized?
+5. **Async / Event-Driven Patterns**: Are long-running operations handled asynchronously? Is there support for message queues, event buses, or pub/sub?
+6. **Rate Limiting & Backpressure**: Are rate limits implemented to protect the system? Is there backpressure handling for overwhelmed consumers?
+7. **Caching at Scale**: Is caching distributed (Redis, Memcached) rather than in-process? Are cache stampede protections in place?
+8. **Single Points of Failure**: Are there components that, if they fail, bring down the entire system? Is there redundancy and failover?
+9. **Performance Bottlenecks**: Are there synchronous blocking calls in hot paths? Are I/O operations optimized?
+10. **Data Volume Handling**: Will the code still work correctly with 10x, 100x, or 1000x the current data volume?
+
+RULES FOR YOUR EVALUATION:
+- Assign rule IDs with prefix "SCALE-" (e.g. SCALE-001).
+- Think about what breaks first when traffic increases 10x or 100x.
+- Distinguish between "works now" and "will work at scale."
+- Recommend specific architectural patterns (CQRS, event sourcing, circuit breakers, etc.).
+- Score from 0-100 where 100 means fully scalable with no bottlenecks.
+
+FALSE POSITIVE AVOIDANCE:
+- **Distributed lock with local fallback**: When code implements a distributed lock (Redlock, Redis lock, etcd, Consul) as the primary mechanism AND uses a local lock (asyncio.Lock, threading.Lock) as a documented single-instance fallback, do NOT flag the local lock as a scaling issue. This is a correct graceful-degradation pattern.
+- **Two-tier locking**: If comments document a two-tier design (distributed for multi-instance, local for single-instance), accept the design. A compliance/dev tool should still function without external infrastructure.
+
+ADVERSARIAL MANDATE:
+- Your role is adversarial: assume the code will not scale and actively hunt for bottlenecks. Back every finding with concrete code evidence (line numbers, patterns, API calls).
+- Never praise or compliment the code. Report only problems, risks, and deficiencies.
+- If you are uncertain whether something is an issue, flag it only when you can cite specific code evidence (line numbers, patterns, API calls). Speculative findings without concrete evidence erode developer trust.
+- Absence of findings does not mean the code will scale. It means your analysis reached its limits. State this explicitly.

package/agents/security.judge.md

@@ -0,0 +1,31 @@
+---
+id: security
+name: Judge Security
+domain: General Security Posture
+rulePrefix: SEC
+description: Holistic security assessment covering insecure data flows, weak cryptography, missing security controls, unsafe deserialization, XML external entities, prototype pollution, and other broad vulnerability patterns across all supported languages.
+tableDescription: Holistic security assessment — insecure data flows, weak cryptography, unsafe deserialization
+promptDescription: "Deep holistic security posture review: insecure data flows, weak cryptography, unsafe deserialization"
+script: ../src/evaluators/security.ts
+priority: 10
+---
+You are Judge Security — a senior application security architect with broad expertise in secure software design, threat modeling, and defense-in-depth strategies across multiple languages and frameworks.
+
+YOUR EVALUATION CRITERIA:
+1. **Insecure Data Flows**: Are user-controlled inputs used directly in database queries, file operations, HTTP requests, or object merges without validation?
+2. **Weak Cryptography**: Are deprecated or broken algorithms (MD5, SHA-1, DES, RC4) used for security-sensitive operations like password hashing or integrity checks?
+3. **Missing Security Controls**: Do web applications lack essential middleware (helmet, CORS, CSRF) or input validation?
+4. **Unsafe Deserialization**: Is data from untrusted sources deserialized using unsafe mechanisms (pickle, ObjectInputStream, BinaryFormatter)?
+5. **XML Security**: Are XML parsers configured without disabling external entity resolution?
+6. **Memory Safety**: In low-level languages, is unsafe code properly scoped and documented?
+7. **Secret Management**: Are secrets, tokens, or API keys compared using constant-time operations?
+8. **Redirect Validation**: Are user-controlled URLs used in redirects without validation?
+9. **Mass Assignment**: Is user input passed directly to database operations without field filtering?
+10. **Token Verification**: Are JWT/token verification routines configured with explicit algorithm restrictions?
+
+RULES FOR YOUR EVALUATION:
+- Assign rule IDs with prefix "SEC-" (e.g. SEC-001).
+- Focus on the security posture of the code as a whole.
+- Provide concrete remediation with code examples.
+- Reference CWE IDs where applicable.
+- Score from 0-100 where 100 means excellent security posture.

package/agents/software-practices.judge.md

@@ -0,0 +1,44 @@
+---
+id: software-practices
+name: Judge Software Practices
+domain: Software Engineering Best Practices & Secure SDLC
+rulePrefix: SWDEV
+description: Evaluates code quality, maintainability, testing practices, documentation, SOLID principles, design patterns, error handling, and secure software development lifecycle (SSDLC) compliance.
+tableDescription: SOLID principles, type safety, error handling, input validation
+promptDescription: Deep software practices review
+script: ../src/evaluators/software-practices.ts
+priority: 10
+---
+You are Judge Software Practices — a principal software engineer and engineering quality leader with mastery of clean code, design patterns, testing strategies, and secure SDLC practices.
+
+YOUR EVALUATION CRITERIA:
+1. **Code Quality & Readability**: Is the code clean, well-organized, and self-documenting? Are naming conventions consistent and descriptive?
+2. **SOLID Principles**: Does the code follow Single Responsibility, Open/Closed, Liskov Substitution, Interface Segregation, and Dependency Inversion?
+3. **Design Patterns**: Are appropriate design patterns used? Are there anti-patterns (god objects, spaghetti code, magic numbers)?
+4. **Error Handling**: Is error handling comprehensive? Are errors caught at the right level? Are error messages helpful without leaking sensitive info?
+5. **Testing**: Is the code testable? Are there unit tests, integration tests, or end-to-end tests? Is test coverage adequate? Are edge cases considered?
+6. **Input Validation**: Is all external input validated? Are validation rules centralized and consistent? Is there defense-in-depth validation?
+7. **Documentation**: Are public APIs documented? Are complex algorithms explained? Is there a README, changelog, and contribution guide?
+8. **Dependency Management**: Are dependencies minimal, well-maintained, and from trusted sources? Are versions pinned? Is there a lock file?
+9. **Logging & Debugging**: Is logging structured and leveled (debug, info, warn, error)? Are log messages useful for troubleshooting?
+10. **Code Duplication**: Is there unnecessary duplication that should be refactored into shared utilities or abstractions?
+11. **Type Safety**: Is type safety enforced (TypeScript strict mode, type annotations, generics)? Are there `any` types or unsafe casts?
+12. **Secure SDLC**: Does the development process include threat modeling, code review, SAST/DAST, and security testing?
+
+RULES FOR YOUR EVALUATION:
+- Assign rule IDs with prefix "SWDEV-" (e.g. SWDEV-001).
+- Be direct: explain why the practice is a problem and what risk it introduces.
+- Provide refactored code examples when recommending improvements.
+- Reference Clean Code (Robert Martin), SOLID, DRY, KISS, YAGNI where applicable.
+- Score from 0-100 where 100 means exemplary software engineering.
+
+FALSE POSITIVE AVOIDANCE:
+- **Justified suppression comments**: type: ignore, noqa, eslint-disable, and similar comments that include a rationale (e.g., "# type: ignore  # JSON boundary") are intentional engineering decisions, not code quality violations. Only flag SWDEV-001 for bare suppressions without justification.
+- **Minimum-viable nesting in async code**: Async functions with try/except/with patterns inherently add 2-3 nesting levels. Only flag SWDEV-002 nesting when depth exceeds 4 and the pattern is not a standard async error-handling idiom.
+- **Single-module cohesion**: A module with one public entry point and private helpers implementing a single workflow (e.g., load → parse → index) is cohesive even if it has many private methods. Only flag MAINT-001/MAINT-002 when a module serves multiple unrelated concerns.
+
+ADVERSARIAL MANDATE:
+- Your role is adversarial: assume the code has engineering quality problems and actively hunt for them. Back every finding with concrete code evidence (line numbers, patterns, API calls).
+- Never praise or compliment the code. Report only problems, risks, and deficiencies.
+- If you are uncertain whether something is an issue, flag it only when you can cite specific code evidence (line numbers, patterns, API calls). Speculative findings without concrete evidence erode developer trust.
+- Absence of findings does not mean the code follows best practices. It means your analysis reached its limits. State this explicitly.

package/agents/testing.judge.md

@@ -0,0 +1,39 @@
+---
+id: testing
+name: Judge Testing
+domain: Test Quality & Coverage
+rulePrefix: TEST
+description: Evaluates code for test-to-code ratio, test isolation, mocking strategy, edge case coverage, flaky test patterns, and test pyramid balance (unit/integration/e2e).
+tableDescription: Test coverage, assertions, test isolation, naming
+promptDescription: Deep testing quality review
+script: ../src/evaluators/testing.ts
+priority: 10
+---
+You are Judge Testing — a quality engineering architect with mastery of TDD, BDD, testing pyramids, mutation testing, and test infrastructure at scale.
+
+YOUR EVALUATION CRITERIA:
+1. **Testability**: Is the code structured for easy testing? Are dependencies injectable? Are side effects isolated? Is business logic separated from I/O?
+2. **Test Pyramid Balance**: Is there an appropriate mix of unit tests (many), integration tests (some), and E2E tests (few)? Are tests at the right level?
+3. **Edge Cases**: Are boundary conditions tested (empty arrays, null inputs, max values, concurrent access, unicode, timezone boundaries)?
+4. **Mocking Strategy**: Are mocks/stubs/spies used appropriately? Is there over-mocking (mocking implementation details rather than contracts)? Are test doubles faithful to real behavior?
+5. **Test Isolation**: Do tests depend on each other's state? Is there shared mutable state between tests? Do tests clean up after themselves?
+6. **Flaky Test Patterns**: Are there patterns that could cause flaky tests (timing dependencies, random data without seeds, file system access, network calls)?
+7. **Assertion Quality**: Are assertions specific and meaningful? Do they test behavior rather than implementation? Are error messages in assertions helpful?
+8. **Test Naming & Organization**: Do test names describe the behavior being tested? Are tests organized by feature/behavior rather than by class?
+9. **Error Path Testing**: Are error conditions and exception paths tested? Are failure modes verified, not just success paths?
+10. **Performance Testing**: Are there tests for response time, throughput, or resource usage? Are performance baselines established?
+11. **Security Testing**: Are there tests for authentication, authorization, input validation, and injection attempts?
+12. **Test Data Management**: Is test data created programmatically? Are fixtures/factories used instead of hardcoded data? Is sensitive data avoided in tests?
+
+RULES FOR YOUR EVALUATION:
+- Assign rule IDs with prefix "TEST-" (e.g. TEST-001).
+- Reference testing best practices (Kent Beck, Martin Fowler's Test Pyramid, FIRST principles).
+- Recommend specific test cases that should be written, with example test code.
+- Evaluate both the tests AND the testability of the code under test.
+- Score from 0-100 where 100 means comprehensive, well-structured test suite.
+
+ADVERSARIAL MANDATE:
+- Your role is adversarial: assume the test coverage is insufficient and actively hunt for gaps. Back every finding with concrete code evidence (line numbers, patterns, API calls).
+- Never praise or compliment the code. Report only problems, risks, and deficiencies.
+- If you are uncertain whether something is an issue, flag it only when you can cite specific code evidence (line numbers, patterns, API calls). Speculative findings without concrete evidence erode developer trust.
+- Absence of findings does not mean the code is well-tested. It means your analysis reached its limits. State this explicitly.

package/agents/ux.judge.md

@@ -0,0 +1,37 @@
+---
+id: ux
+name: Judge UX
+domain: User Experience & Interface Quality
+rulePrefix: UX
+description: Evaluates code for user experience patterns including loading states, error feedback, responsive design, mobile-friendliness, and interaction quality.
+tableDescription: Loading states, error messages, pagination, destructive actions
+promptDescription: Deep user experience review
+script: ../src/evaluators/ux.ts
+priority: 10
+---
+You are Judge UX — a UX engineer and frontend architect who bridges design and engineering, specializing in performance perception, error communication, and inclusive interaction design.
+
+YOUR EVALUATION CRITERIA:
+1. **Loading States**: Are loading indicators shown during async operations? Is there feedback when the user initiates an action? Are skeleton screens or spinners used?
+2. **Error Feedback**: Are errors communicated to users in a clear, actionable way? Are generic "Something went wrong" messages avoided? Do errors suggest next steps?
+3. **Responsive Design**: Does the UI adapt to different screen sizes? Are media queries or responsive frameworks used? Is content readable on mobile?
+4. **Form UX**: Are forms validated with inline feedback? Are error messages placed near the relevant field? Are required fields marked? Is there auto-save or draft preservation?
+5. **Navigation & Wayfinding**: Is navigation intuitive? Are breadcrumbs provided? Can users always find their way back? Are deep links supported?
+6. **Performance Perception**: Are optimistic updates used? Is there pagination or infinite scroll for large lists? Are perceived loading times minimized?
+7. **Empty States**: Are empty states handled (no data, no results, first-time user)? Do they provide guidance on what to do next?
+8. **Confirmation & Safety**: Are destructive actions confirmed (delete, submit, send)? Can actions be undone? Are users warned about data loss?
+9. **Mobile & Touch**: Are touch targets large enough (48x48px)? Are hover-dependent interactions avoided? Is the interface usable without a mouse?
+10. **Progressive Enhancement**: Does the core functionality work without JavaScript? Are there graceful fallbacks for unsupported features?
+
+RULES FOR YOUR EVALUATION:
+- Assign rule IDs with prefix "UX-" (e.g. UX-001).
+- Reference Nielsen's Heuristics, Material Design guidelines, and WCAG criteria where applicable.
+- Distinguish between "functional" and "user-friendly."
+- Consider diverse users: slow connections, small screens, assistive technology.
+- Score from 0-100 where 100 means excellent user experience.
+
+ADVERSARIAL MANDATE:
+- Your role is adversarial: assume the user experience is poor and actively hunt for problems. Back every finding with concrete code evidence (line numbers, patterns, API calls).
+- Never praise or compliment the code. Report only problems, risks, and deficiencies.
+- If you are uncertain whether something is an issue, flag it only when you can cite specific code evidence (line numbers, patterns, API calls). Speculative findings without concrete evidence erode developer trust.
+- Absence of findings does not mean the UX is good. It means your analysis reached its limits. State this explicitly.

package/dist/api.d.ts

@@ -28,10 +28,13 @@ export { findingsToSarif, evaluationToSarif, verdictToSarif, validateSarifLog }
 export type { SarifValidationError } from "./formatters/sarif.js";
 export { verdictToCsvRows, verdictsToCsv, findingsToCsv } from "./formatters/csv.js";
 export { verdictToGitHubActions } from "./formatters/github-actions.js";
-export { runCli } from "./cli.js";
 export { registerPlugin, unregisterPlugin, getRegisteredPlugins, getCustomRules, getPluginJudges, evaluateCustomRules, runBeforeHooks, runAfterHooks, clearPlugins, } from "./plugins.js";
 export type { CustomRule, JudgesPlugin, PluginRegistration } from "./plugins.js";
 export { JudgeRegistry, defaultRegistry } from "./judge-registry.js";
+export { parseFrontmatter, validateFrontmatter, parseAgentFile, resolveEvaluator, agentToJudgeDefinition, loadAgentDirectory, loadAndRegisterAgents, } from "./agent-loader.js";
+export type { AgentFrontmatter, ParsedAgent } from "./agent-loader.js";
+export { parseSkillFrontmatter, validateSkillFrontmatter, parseSkillFile, loadSkillDirectory, listSkills, runSkill, } from "./skill-loader.js";
+export type { SkillFrontmatter, ParsedSkill } from "./skill-loader.js";
 export { fingerprintCode, fingerprintToFindings } from "./fingerprint.js";
 export type { AiFingerprint, AiSignal } from "./fingerprint.js";
 export { buildCalibrationProfile, calibrateFindings, autoCalibrateFindings } from "./calibration.js";
@@ -50,8 +53,12 @@ export { compareCapabilities, formatComparisonReport, formatFullComparisonMatrix
 export type { ToolProfile, ToolCapability, ComparisonResult } from "./comparison.js";
 export { runBenchmarkSuite, benchmarkGate, formatBenchmarkReport, formatBenchmarkMarkdown, analyzeL2Coverage, formatL2CoverageReport, ingestFindingsAsBenchmarkCases, deduplicateIngestCases, BENCHMARK_CASES, } from "./commands/benchmark.js";
 export type { BenchmarkCase, BenchmarkResult, BenchmarkGateOptions, BenchmarkGateResult, L2CoverageAnalysis, L2JudgeCoverage, L2CategoryCoverage, } from "./commands/benchmark.js";
-export { parseLlmRuleIds, constructPerJudgePrompt, constructTribunalPrompt, selectStratifiedSample, scoreLlmCase, computeLlmMetrics, formatLlmSnapshotMarkdown, formatLayerComparisonMarkdown, } from "./commands/llm-benchmark.js";
+export { parseLlmRuleIds, constructPerJudgePrompt, constructTribunalPrompt, selectStratifiedSample, scoreLlmCase, computeLlmMetrics, formatLlmSnapshotMarkdown, formatLayerComparisonMarkdown, extractValidatedLlmFindings, getValidRulePrefixes, } from "./commands/llm-benchmark.js";
 export type { LlmBenchmarkSnapshot, LlmCaseResult } from "./commands/llm-benchmark.js";
+export type { LlmFinding, ValidationResult } from "./probabilistic/llm-response-validator.js";
+export { runReviewAutopilot, dedupeComments, filterAlreadyPostedComments } from "./commands/review.js";
+export { buildContextSnippets } from "./context/context-snippets.js";
+export { EmbeddingCache, FallbackEmbeddingProvider, getOrCreateEmbedding } from "./context/embedding-cache.js";
 export { exportTeamConfig, importTeamConfig, pullRemoteConfig, writePolicyLock, readPolicyLock, validatePolicyCompliance, } from "./commands/config-share.js";
 export type { TeamConfig, PolicyLock, PolicyValidationResult } from "./commands/config-share.js";
 export { getLanguagePack, listLanguagePacks, suggestPack, LANGUAGE_PACKS } from "./commands/language-packs.js";
@@ -136,4 +143,3 @@ export declare function evaluateFilesStream(files: FileInput[], options?: Evalua
 export declare function evaluateFilesBatch(files: FileInput[], concurrency?: number, options?: EvaluationOptions, onProgress?: (completed: number, total: number) => void): Promise<FileEvaluationResult[]>;
 export { handleWebhook, verifyWebhookSignature, loadAppConfig, startAppServer, runAppCommand } from "./github-app.js";
 export type { GitHubAppConfig } from "./github-app.js";
-//# sourceMappingURL=api.d.ts.map

package/dist/api.js

@@ -34,12 +34,14 @@ export { clearProjectCache } from "./evaluators/project.js";
 export { findingsToSarif, evaluationToSarif, verdictToSarif, validateSarifLog } from "./formatters/sarif.js";
 export { verdictToCsvRows, verdictsToCsv, findingsToCsv } from "./formatters/csv.js";
 export { verdictToGitHubActions } from "./formatters/github-actions.js";
-// ─── CLI ─────────────────────────────────────────────────────────────────────
-export { runCli } from "./cli.js";
 // ─── Plugin API ──────────────────────────────────────────────────────────────
 export { registerPlugin, unregisterPlugin, getRegisteredPlugins, getCustomRules, getPluginJudges, evaluateCustomRules, runBeforeHooks, runAfterHooks, clearPlugins, } from "./plugins.js";
 // ─── Judge Registry ──────────────────────────────────────────────────────────
 export { JudgeRegistry, defaultRegistry } from "./judge-registry.js";
+// ─── Agent Markdown Loader ───────────────────────────────────────────────────
+export { parseFrontmatter, validateFrontmatter, parseAgentFile, resolveEvaluator, agentToJudgeDefinition, loadAgentDirectory, loadAndRegisterAgents, } from "./agent-loader.js";
+// ─── Skill Loader ───────────────────────────────────────────────────────────
+export { parseSkillFrontmatter, validateSkillFrontmatter, parseSkillFile, loadSkillDirectory, listSkills, runSkill, } from "./skill-loader.js";
 // ─── AI Code Fingerprinting ─────────────────────────────────────────────────
 export { fingerprintCode, fingerprintToFindings } from "./fingerprint.js";
 // ─── Confidence Calibration ─────────────────────────────────────────────────
@@ -58,7 +60,11 @@ export { compareCapabilities, formatComparisonReport, formatFullComparisonMatrix
 // ─── Benchmark Gate ──────────────────────────────────────────────────────────
 export { runBenchmarkSuite, benchmarkGate, formatBenchmarkReport, formatBenchmarkMarkdown, analyzeL2Coverage, formatL2CoverageReport, ingestFindingsAsBenchmarkCases, deduplicateIngestCases, BENCHMARK_CASES, } from "./commands/benchmark.js";
 // ─── LLM Benchmark ──────────────────────────────────────────────────────────
-export { parseLlmRuleIds, constructPerJudgePrompt, constructTribunalPrompt, selectStratifiedSample, scoreLlmCase, computeLlmMetrics, formatLlmSnapshotMarkdown, formatLayerComparisonMarkdown, } from "./commands/llm-benchmark.js";
+export { parseLlmRuleIds, constructPerJudgePrompt, constructTribunalPrompt, selectStratifiedSample, scoreLlmCase, computeLlmMetrics, formatLlmSnapshotMarkdown, formatLayerComparisonMarkdown, extractValidatedLlmFindings, getValidRulePrefixes, } from "./commands/llm-benchmark.js";
+// Review autopilot (GitHub App / scripts)
+export { runReviewAutopilot, dedupeComments, filterAlreadyPostedComments } from "./commands/review.js";
+export { buildContextSnippets } from "./context/context-snippets.js";
+export { EmbeddingCache, FallbackEmbeddingProvider, getOrCreateEmbedding } from "./context/embedding-cache.js";
 // ─── Config Sharing & Policy ─────────────────────────────────────────────────
 export { exportTeamConfig, importTeamConfig, pullRemoteConfig, writePolicyLock, readPolicyLock, validatePolicyCompliance, } from "./commands/config-share.js";
 // ─── Language Packs ──────────────────────────────────────────────────────────
@@ -161,4 +167,3 @@ export async function evaluateFilesBatch(files, concurrency = 4, options, onProg
 }
 // ─── GitHub App ──────────────────────────────────────────────────────────────
 export { handleWebhook, verifyWebhookSignature, loadAppConfig, startAppServer, runAppCommand } from "./github-app.js";
-//# sourceMappingURL=api.js.map

package/dist/ast/cross-file-taint.d.ts

@@ -40,4 +40,3 @@ export declare function analyzeCrossFileTaint(files: Array<{
     content: string;
     language: string;
 }>): CrossFileTaintFlow[];
-//# sourceMappingURL=cross-file-taint.d.ts.map

package/dist/ast/cross-file-taint.js

@@ -715,4 +715,3 @@ function deduplicateCrossFlows(flows) {
         return true;
     });
 }
-//# sourceMappingURL=cross-file-taint.js.map

package/dist/ast/index.d.ts

@@ -23,4 +23,3 @@ export declare function analyzeStructure(code: string, language: string): CodeSt
  * tree-sitter grammars are fully loaded before analysis.
  */
 export declare function analyzeStructureAsync(code: string, language: string): Promise<CodeStructure>;
-//# sourceMappingURL=index.d.ts.map

package/dist/ast/index.js

@@ -146,4 +146,3 @@ export async function analyzeStructureAsync(code, language) {
             };
     }
 }
-//# sourceMappingURL=index.js.map

package/dist/ast/structural-parser.d.ts

@@ -1,3 +1,2 @@
 import type { CodeStructure } from "./types.js";
 export declare function analyzeStructurally(code: string, language: string): CodeStructure;
-//# sourceMappingURL=structural-parser.d.ts.map

package/dist/ast/structural-parser.js

@@ -754,4 +754,3 @@ function extractImports(lines, language) {
     }
     return imports;
 }
-//# sourceMappingURL=structural-parser.js.map

package/dist/ast/taint-tracker.d.ts

@@ -34,4 +34,3 @@ export type TaintSinkKind = "code-execution" | "command-exec" | "sql-query" | "x
  * For other languages, falls back to generic regex-based analysis.
  */
 export declare function analyzeTaintFlows(code: string, language: string): TaintFlow[];
-//# sourceMappingURL=taint-tracker.d.ts.map

package/dist/ast/taint-tracker.js

@@ -1031,4 +1031,3 @@ function deduplicateFlows(flows) {
         return true;
     });
 }
-//# sourceMappingURL=taint-tracker.js.map

package/dist/ast/tree-sitter-ast.d.ts

@@ -31,4 +31,3 @@ export declare function analyzeWithTreeSitterSync(code: string, language: string
  * fall back to analyzeStructurally().
  */
 export declare function analyzeWithTreeSitter(code: string, language: string): Promise<CodeStructure>;
-//# sourceMappingURL=tree-sitter-ast.d.ts.map

package/dist/ast/tree-sitter-ast.js

@@ -13,6 +13,8 @@
 import { createRequire } from "node:module";
 import { fileURLToPath } from "node:url";
 import { dirname, join } from "node:path";
+import { existsSync, mkdirSync, renameSync, unlinkSync, writeFileSync } from "node:fs";
+import { homedir } from "node:os";
 // Support both ESM (import.meta.url) and CJS (esbuild bundle) environments.
 // When bundled by esbuild with --format=cjs, import.meta.url is undefined,
 // so we fall back to __filename (which esbuild injects for CJS bundles).
@@ -53,6 +55,43 @@ const _moduleDir = _importMetaUrl
 // In dist: dist/ast/ → ../../grammars/
 // In vscode bundle: out/ → ../grammars/ (but tree-sitter gracefully degrades)
 const GRAMMAR_DIR = join(_moduleDir, "..", "..", "grammars");
+const GRAMMAR_CACHE_DIR = join(homedir(), ".judges", "grammars");
+const GRAMMAR_BASE_URL = process.env.JUDGES_GRAMMAR_BASE_URL?.replace(/\/+$/, "") ||
+    "https://raw.githubusercontent.com/KevinRabun/judges/main/grammars";
+async function downloadGrammar(file, targetPath) {
+    if (typeof fetch !== "function")
+        return false;
+    const tempPath = `${targetPath}.tmp`;
+    try {
+        const response = await fetch(`${GRAMMAR_BASE_URL}/${file}`);
+        if (!response.ok)
+            return false;
+        const bytes = new Uint8Array(await response.arrayBuffer());
+        mkdirSync(GRAMMAR_CACHE_DIR, { recursive: true });
+        writeFileSync(tempPath, bytes);
+        renameSync(tempPath, targetPath);
+        return true;
+    }
+    catch {
+        try {
+            unlinkSync(tempPath);
+        }
+        catch {
+            // ignore cleanup errors
+        }
+        return false;
+    }
+}
+async function ensureGrammarPath(file) {
+    const bundledPath = join(GRAMMAR_DIR, file);
+    if (existsSync(bundledPath))
+        return bundledPath;
+    const cachedPath = join(GRAMMAR_CACHE_DIR, file);
+    if (existsSync(cachedPath))
+        return cachedPath;
+    const downloaded = await downloadGrammar(file, cachedPath);
+    return downloaded ? cachedPath : null;
+}
 async function ensureInit() {
     if (initPromise)
         return initPromise;
@@ -76,7 +115,10 @@ async function getLanguage(lang) {
     if (!file)
         return null;
     try {
-        const grammar = await parserModule.Language.load(join(GRAMMAR_DIR, file));
+        const grammarPath = await ensureGrammarPath(file);
+        if (!grammarPath)
+            return null;
+        const grammar = await parserModule.Language.load(grammarPath);
         languageCache.set(lang, grammar);
         return grammar;
     }
@@ -1120,4 +1162,3 @@ function findFirstByType(node, type) {
     }
     return null;
 }
-//# sourceMappingURL=tree-sitter-ast.js.map

package/dist/ast/types.d.ts

@@ -48,4 +48,3 @@ export interface CodeStructure {
     /** Class names discovered in the file (Python, Java, C#, etc.) */
     classes?: string[];
 }
-//# sourceMappingURL=types.d.ts.map

package/dist/ast/types.js

@@ -5,4 +5,3 @@
 // lightweight structural parser for other languages.
 // ─────────────────────────────────────────────────────────────────────────────
 export {};
-//# sourceMappingURL=types.js.map

package/dist/auto-tune.d.ts

@@ -144,4 +144,3 @@ export declare function formatAutoTuneReport(report: AutoTuneReport): string;
  * Format auto-tune report as JSON.
  */
 export declare function formatAutoTuneReportJson(report: AutoTuneReport): string;
-//# sourceMappingURL=auto-tune.d.ts.map

package/dist/auto-tune.js

@@ -371,4 +371,3 @@ export function formatAutoTuneReportJson(report) {
         summary: report.summary,
     }, null, 2);
 }
-//# sourceMappingURL=auto-tune.js.map

package/dist/cache.d.ts

@@ -51,4 +51,3 @@ export declare class LRUCache<T> {
     /** Evict the least recently used (oldest / first) entry. */
     private evictLru;
 }
-//# sourceMappingURL=cache.d.ts.map

package/dist/cache.js

@@ -84,4 +84,3 @@ export class LRUCache {
             this.cache.delete(first);
     }
 }
-//# sourceMappingURL=cache.js.map

package/dist/calibration.d.ts

@@ -106,4 +106,3 @@ export declare function buildAllModelProfiles(store: FeedbackStore, options?: Ca
  * the general profile when no model-specific data is available.
  */
 export declare function calibrateFindingsForModel(findings: Finding[], generalProfile: CalibrationProfile, modelProfile: CalibrationProfile | undefined, options?: CalibrationOptions): Finding[];
-//# sourceMappingURL=calibration.d.ts.map

package/dist/calibration.js

@@ -217,4 +217,3 @@ export function calibrateFindingsForModel(findings, generalProfile, modelProfile
     const profile = modelProfile?.isActive ? modelProfile : generalProfile;
     return calibrateFindings(findings, profile, options);
 }
-//# sourceMappingURL=calibration.js.map

package/dist/commands/auto-detect.d.ts

@@ -59,4 +59,3 @@ export declare function formatProjectSummary(signals: ProjectSignals): string;
  * Format a preset recommendation for display.
  */
 export declare function formatRecommendation(rec: PresetRecommendation): string;
-//# sourceMappingURL=auto-detect.d.ts.map

package/dist/commands/auto-detect.js

@@ -326,4 +326,3 @@ export function formatRecommendation(rec) {
     lines.push("");
     return lines.join("\n");
 }
-//# sourceMappingURL=auto-detect.js.map

package/dist/commands/benchmark-advanced.d.ts

@@ -12,4 +12,3 @@
  */
 import type { BenchmarkCase } from "./benchmark.js";
 export declare const BENCHMARK_ADVANCED_CASES: BenchmarkCase[];
-//# sourceMappingURL=benchmark-advanced.d.ts.map

package/dist/commands/benchmark-advanced.js

@@ -5055,4 +5055,3 @@ function errorHandler(err: Error, req: Request, res: Response, next: NextFunctio
         difficulty: "medium",
     },
 ];
-//# sourceMappingURL=benchmark-advanced.js.map

package/dist/commands/benchmark-ai-agents.d.ts

@@ -6,4 +6,3 @@ import type { BenchmarkCase } from "./benchmark.js";
  * HALLU judge has zero existing coverage — this file is critical.
  */
 export declare const BENCHMARK_AI_AGENTS: BenchmarkCase[];
-//# sourceMappingURL=benchmark-ai-agents.d.ts.map

package/dist/commands/benchmark-ai-agents.js

@@ -4121,4 +4121,3 @@ export function SearchComponent() {
         difficulty: "medium",
     },
 ];
-//# sourceMappingURL=benchmark-ai-agents.js.map

package/dist/commands/benchmark-ai-output.d.ts

@@ -7,4 +7,3 @@ import type { BenchmarkCase } from "./benchmark.js";
  * Covers LOGIC, TEST, and enhanced HALLU prefixes.
  */
 export declare const BENCHMARK_AI_OUTPUT: BenchmarkCase[];
-//# sourceMappingURL=benchmark-ai-output.d.ts.map

package/dist/commands/benchmark-ai-output.js

@@ -363,4 +363,3 @@ export async function handleRequest(req: Request) {
         aiSource: "copilot",
     },
 ];
-//# sourceMappingURL=benchmark-ai-output.js.map

package/dist/commands/benchmark-compliance-ethics.d.ts

@@ -6,4 +6,3 @@ import type { BenchmarkCase } from "./benchmark.js";
  * Covers COMP, SOV, ETHICS, A11Y, I18N, UX, COMPAT, DEPS, PORTA prefixes.
  */
 export declare const BENCHMARK_COMPLIANCE_ETHICS: BenchmarkCase[];
-//# sourceMappingURL=benchmark-compliance-ethics.d.ts.map

package/dist/commands/benchmark-compliance-ethics.js

@@ -3058,4 +3058,3 @@ v2.get("/api/v2/users/:id", async (req, res) => {
         difficulty: "medium",
     },
 ];
-//# sourceMappingURL=benchmark-compliance-ethics.js.map

package/dist/commands/benchmark-expanded-2.d.ts

@@ -10,4 +10,3 @@
  */
 import type { BenchmarkCase } from "./benchmark.js";
 export declare const EXPANDED_BENCHMARK_CASES_2: BenchmarkCase[];
-//# sourceMappingURL=benchmark-expanded-2.d.ts.map

package/dist/commands/benchmark-expanded-2.js

@@ -5528,4 +5528,3 @@ app.listen(3000);`,
         difficulty: "medium",
     },
 ];
-//# sourceMappingURL=benchmark-expanded-2.js.map

package/dist/commands/benchmark-expanded.d.ts

@@ -10,4 +10,3 @@
  */
 import type { BenchmarkCase } from "./benchmark.js";
 export declare const EXPANDED_BENCHMARK_CASES: BenchmarkCase[];
-//# sourceMappingURL=benchmark-expanded.d.ts.map

package/dist/commands/benchmark-expanded.js

@@ -2597,4 +2597,3 @@ func encryptCBC(plaintext []byte) ([]byte, error) {
         difficulty: "hard",
     },
 ];
-//# sourceMappingURL=benchmark-expanded.js.map

package/dist/commands/benchmark-infrastructure.d.ts

@@ -6,4 +6,3 @@ import type { BenchmarkCase } from "./benchmark.js";
  * Covers IAC, CLOUD, CFG, CICD, COST, SCALE, CACHE, REL, RATE prefixes.
  */
 export declare const BENCHMARK_INFRASTRUCTURE: BenchmarkCase[];
-//# sourceMappingURL=benchmark-infrastructure.d.ts.map

package/dist/commands/benchmark-infrastructure.js

@@ -2880,4 +2880,3 @@ async function processMessages() {
         difficulty: "hard",
     },
 ];
-//# sourceMappingURL=benchmark-infrastructure.js.map

package/dist/commands/benchmark-languages.d.ts

@@ -6,4 +6,3 @@ import type { BenchmarkCase } from "./benchmark.js";
  * Covers various judge prefixes in non-TypeScript languages.
  */
 export declare const BENCHMARK_LANGUAGES: BenchmarkCase[];
-//# sourceMappingURL=benchmark-languages.d.ts.map

package/dist/commands/benchmark-languages.js

@@ -1961,4 +1961,3 @@ end`,
         difficulty: "medium",
     },
 ];
-//# sourceMappingURL=benchmark-languages.js.map

package/dist/commands/benchmark-quality-ops.d.ts

@@ -6,4 +6,3 @@ import type { BenchmarkCase } from "./benchmark.js";
  * Covers ERR, DB, CONC, TEST, PERF, OBS, MAINT, DOC, CICD prefixes.
  */
 export declare const BENCHMARK_QUALITY_OPS: BenchmarkCase[];
-//# sourceMappingURL=benchmark-quality-ops.d.ts.map