@kevinrabun/judges-cli 3.124.0

package/dist/judges/index.d.ts

@@ -0,0 +1,88 @@
+/**
+ * Judge registry bootstrap.
+ *
+ * Judges are dual-registered:
+ *  1. Static side-effect imports below — each module calls
+ *     `defaultRegistry.register()` at load time.  These are inlined by
+ *     esbuild and work in both ESM and CJS bundles.
+ *  2. Agent-native `.judge.md` files loaded at runtime from the `agents/`
+ *     directory (when available).  This enriches / overrides metadata.
+ *
+ * The static imports guarantee that judges are always available, even in
+ * bundled environments (VS Code extension) where `agents/` is absent.
+ */
+import type { JudgeDefinition } from "../types.js";
+import "./accessibility.js";
+import "./agent-instructions.js";
+import "./ai-code-safety.js";
+import "./api-contract.js";
+import "./api-design.js";
+import "./authentication.js";
+import "./backwards-compatibility.js";
+import "./caching.js";
+import "./ci-cd.js";
+import "./cloud-readiness.js";
+import "./code-structure.js";
+import "./compliance.js";
+import "./concurrency.js";
+import "./configuration-management.js";
+import "./cost-effectiveness.js";
+import "./cybersecurity.js";
+import "./data-security.js";
+import "./data-sovereignty.js";
+import "./database.js";
+import "./dependency-health.js";
+import "./documentation.js";
+import "./error-handling.js";
+import "./ethics-bias.js";
+import "./false-positive-review.js";
+import "./framework-safety.js";
+import "./hallucination-detection.js";
+import "./iac-security.js";
+import "./intent-alignment.js";
+import "./internationalization.js";
+import "./logging-privacy.js";
+import "./logic-review.js";
+import "./maintainability.js";
+import "./model-fingerprint.js";
+import "./multi-turn-coherence.js";
+import "./observability.js";
+import "./over-engineering.js";
+import "./performance.js";
+import "./portability.js";
+import "./rate-limiting.js";
+import "./reliability.js";
+import "./scalability.js";
+import "./security.js";
+import "./software-practices.js";
+import "./testing.js";
+import "./ux.js";
+/**
+ * Load judges (agent-native). Loads agents from the default `agents/` folder
+ * and returns the current registry snapshot.
+ */
+export declare function loadJudges(): Promise<JudgeDefinition[]>;
+/**
+ * Load agent-based judges from a directory of `.judge.md` files (legacy
+ * `.agent.md` supported). This enables hybrid operation where file-based
+ * agents can augment or replace built-in judges. If a judge is already
+ * registered, it is skipped.
+ */
+export declare function loadAgentJudges(dir?: string): number;
+/**
+ * Snapshot of the currently registered judges. (Agent-native)
+ */
+export declare const JUDGES: JudgeDefinition[];
+/**
+ * Look up a judge by ID.
+ */
+export declare function getJudge(id: string): JudgeDefinition | undefined;
+/**
+ * Get a short summary of all judges for display.
+ */
+export declare function getJudgeSummaries(): Array<{
+    id: string;
+    name: string;
+    domain: string;
+    description: string;
+}>;

package/dist/judges/index.js

@@ -0,0 +1,128 @@
+/**
+ * Judge registry bootstrap.
+ *
+ * Judges are dual-registered:
+ *  1. Static side-effect imports below — each module calls
+ *     `defaultRegistry.register()` at load time.  These are inlined by
+ *     esbuild and work in both ESM and CJS bundles.
+ *  2. Agent-native `.judge.md` files loaded at runtime from the `agents/`
+ *     directory (when available).  This enriches / overrides metadata.
+ *
+ * The static imports guarantee that judges are always available, even in
+ * bundled environments (VS Code extension) where `agents/` is absent.
+ */
+import { defaultRegistry } from "../judge-registry.js";
+import { loadAndRegisterAgents } from "../agent-loader.js";
+import { resolve, dirname } from "node:path";
+import { fileURLToPath } from "node:url";
+// ─── Static side-effect imports (self-registering) ──────────────────────────
+import "./accessibility.js";
+import "./agent-instructions.js";
+import "./ai-code-safety.js";
+import "./api-contract.js";
+import "./api-design.js";
+import "./authentication.js";
+import "./backwards-compatibility.js";
+import "./caching.js";
+import "./ci-cd.js";
+import "./cloud-readiness.js";
+import "./code-structure.js";
+import "./compliance.js";
+import "./concurrency.js";
+import "./configuration-management.js";
+import "./cost-effectiveness.js";
+import "./cybersecurity.js";
+import "./data-security.js";
+import "./data-sovereignty.js";
+import "./database.js";
+import "./dependency-health.js";
+import "./documentation.js";
+import "./error-handling.js";
+import "./ethics-bias.js";
+import "./false-positive-review.js";
+import "./framework-safety.js";
+import "./hallucination-detection.js";
+import "./iac-security.js";
+import "./intent-alignment.js";
+import "./internationalization.js";
+import "./logging-privacy.js";
+import "./logic-review.js";
+import "./maintainability.js";
+import "./model-fingerprint.js";
+import "./multi-turn-coherence.js";
+import "./observability.js";
+import "./over-engineering.js";
+import "./performance.js";
+import "./portability.js";
+import "./rate-limiting.js";
+import "./reliability.js";
+import "./scalability.js";
+import "./security.js";
+import "./software-practices.js";
+import "./testing.js";
+import "./ux.js";
+// Support both ESM (import.meta.url) and CJS (esbuild bundle) environments.
+const _importMetaUrl = typeof import.meta?.url === "string" ? import.meta.url : undefined;
+const __filename = _importMetaUrl ? fileURLToPath(_importMetaUrl) : "";
+const __dirname = __filename ? dirname(__filename) : "";
+let agentsLoaded = false;
+function loadDefaultAgents() {
+    if (agentsLoaded)
+        return;
+    // Static side-effect imports above already registered all built-in judges.
+    // In ESM mode, also load from agents/ directory for metadata enrichment.
+    if (__dirname) {
+        try {
+            const agentsDir = resolve(__dirname, "..", "..", "agents");
+            loadAndRegisterAgents(agentsDir, defaultRegistry);
+        }
+        catch {
+            // agents/ directory may not exist — built-in judges are already loaded
+        }
+    }
+    agentsLoaded = true;
+}
+// ─── Optional Agent Loader Integration ──────────────────────────────────────
+/**
+ * Load judges (agent-native). Loads agents from the default `agents/` folder
+ * and returns the current registry snapshot.
+ */
+export async function loadJudges() {
+    loadDefaultAgents();
+    return defaultRegistry.getJudges();
+}
+/**
+ * Load agent-based judges from a directory of `.judge.md` files (legacy
+ * `.agent.md` supported). This enables hybrid operation where file-based
+ * agents can augment or replace built-in judges. If a judge is already
+ * registered, it is skipped.
+ */
+export function loadAgentJudges(dir) {
+    const agentsDir = dir ?? (__dirname ? resolve(__dirname, "..", "..", "agents") : "");
+    if (!agentsDir)
+        return 0; // CJS bundle — no agents directory available
+    agentsLoaded = false; // allow re-run to pick up new agents if dir changes
+    const count = loadAndRegisterAgents(agentsDir, defaultRegistry);
+    agentsLoaded = true;
+    return count;
+}
+// ─── Re-exports backed by the registry ──────────────────────────────────────
+/**
+ * Snapshot of the currently registered judges. (Agent-native)
+ */
+export const JUDGES = (() => {
+    loadDefaultAgents();
+    return defaultRegistry.getJudges();
+})();
+/**
+ * Look up a judge by ID.
+ */
+export function getJudge(id) {
+    return defaultRegistry.getJudge(id);
+}
+/**
+ * Get a short summary of all judges for display.
+ */
+export function getJudgeSummaries() {
+    return defaultRegistry.getJudgeSummaries();
+}

package/dist/judges/intent-alignment.d.ts

@@ -0,0 +1,2 @@
+import type { JudgeDefinition } from "../types.js";
+export declare const intentAlignmentJudge: JudgeDefinition;

package/dist/judges/intent-alignment.js

@@ -0,0 +1,46 @@
+import { analyzeIntentAlignment } from "../evaluators/intent-alignment.js";
+import { defaultRegistry } from "../judge-registry.js";
+export const intentAlignmentJudge = {
+    id: "intent-alignment",
+    name: "Judge Intent Alignment",
+    domain: "Code–Comment Alignment & Stub Detection",
+    description: "Detects mismatches between stated intent (comments, docstrings, function names) and actual implementation — stubs, TODO-only bodies, misleading names, and empty implementations that AI code generators commonly produce.",
+    rulePrefix: "INTENT",
+    tableDescription: "Detects mismatches between stated intent and implementation, placeholder stubs, TODO-only functions",
+    promptDescription: "Deep review of code–comment alignment, stub detection, placeholder functions",
+    systemPrompt: `You are Judge Intent Alignment — your role is to verify that code does what its documentation, names, and comments claim.
+
+YOUR EVALUATION CRITERIA:
+1. **Stub Functions**: Functions with TODO/FIXME bodies or that throw "not implemented" without real logic.
+2. **Misleading Names**: Function names that promise specific behavior (validate, encrypt, sanitize, authenticate) but whose bodies don't perform that action.
+3. **Empty Implementations**: Functions, methods, or handlers declared but with empty or trivial bodies (return null/undefined/false/empty-string without logic).
+4. **Dead Documentation**: JSDoc/docstring parameters that don't match the actual parameter list.
+5. **Contradictory Comments**: Inline comments that describe behavior the code doesn't perform.
+6. **Placeholder Returns**: Functions that always return a hardcoded value regardless of input, when the name implies computation.
+
+SEVERITY MAPPING:
+- **critical**: Security-sensitive stubs (validate, authenticate, authorize, encrypt, sanitize)
+- **high**: Functions with misleading names that could cause logical errors
+- **medium**: TODO stubs, placeholder implementations, dead documentation
+- **low**: Minor name mismatches, outdated comments
+
+Each finding must include:
+- The specific function/method name and its declared intent
+- What the implementation actually does (or doesn't do)
+- A concrete recommendation for fixing the gap
+
+FALSE POSITIVE AVOIDANCE:
+- Only flag intent-alignment issues when there is a clear mismatch between code comments/docstrings and the actual implementation.
+- Absence of comments is NOT an intent-alignment issue — defer to the DOC judge.
+- Code with no comments at all cannot have intent-alignment problems — there is nothing to misalign.
+- TODO/FIXME comments describing planned work are not intent mismatches.
+- Generic function names (process, handle, run) are not intent issues unless they contradict specific documentation.
+
+ADVERSARIAL MANDATE:
+- Assume every comment could be lying. Verify that implementations match their stated intent.
+- 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-aligned. It means your analysis reached its limits. State this explicitly.`,
+    analyze: analyzeIntentAlignment,
+};
+defaultRegistry.register(intentAlignmentJudge);

package/dist/judges/internationalization.d.ts

@@ -0,0 +1,2 @@
+import type { JudgeDefinition } from "../types.js";
+export declare const internationalizationJudge: JudgeDefinition;

package/dist/judges/internationalization.js

@@ -0,0 +1,44 @@
+import { analyzeInternationalization } from "../evaluators/internationalization.js";
+import { defaultRegistry } from "../judge-registry.js";
+export const internationalizationJudge = {
+    id: "internationalization",
+    name: "Judge Internationalization",
+    domain: "i18n & Localization",
+    description: "Evaluates code for hardcoded strings, date/number formatting, RTL support, locale-aware sorting, Unicode handling, and translation-ready patterns.",
+    rulePrefix: "I18N",
+    tableDescription: "Hardcoded strings, locale handling, currency formatting",
+    promptDescription: "Deep i18n review",
+    systemPrompt: `You are Judge Internationalization — a globalization engineer with expertise in Unicode, CLDR, ICU message formatting, and building applications that serve users in 100+ languages and regions.
+
+YOUR EVALUATION CRITERIA:
+1. **Hardcoded Strings**: Are user-facing strings hardcoded or externalized to resource files/translation keys? Are template literals used for user-facing messages?
+2. **Date & Time Formatting**: Are dates formatted with locale-aware APIs (Intl.DateTimeFormat, date-fns locale)? Are timezones handled correctly? Are ISO 8601 formats used for storage?
+3. **Number & Currency Formatting**: Are numbers formatted with locale-aware separators (1,000 vs 1.000)? Is currency display locale-appropriate?
+4. **RTL Support**: Is text direction handled (dir="auto", CSS logical properties)? Are layouts mirrored correctly for RTL languages (Arabic, Hebrew)?
+5. **Unicode Handling**: Does the code handle multi-byte characters correctly? Are string length calculations unicode-aware? Are emoji and surrogate pairs handled?
+6. **Pluralization**: Are pluralization rules language-aware (not just "if count === 1")? Is ICU MessageFormat or similar used?
+7. **Sorting & Collation**: Are strings sorted with locale-aware collation (Intl.Collator)? Is case-insensitive comparison locale-appropriate?
+8. **Translation Readiness**: Are string concatenation patterns avoided in favor of interpolation? Are context hints provided for translators?
+9. **Locale Detection**: Is the user's locale detected and applied correctly? Is there a fallback strategy for unsupported locales?
+10. **Image & Media**: Are images with embedded text avoided? Are text-containing SVGs localizable? Are alt texts translatable?
+
+RULES FOR YOUR EVALUATION:
+- Assign rule IDs with prefix "I18N-" (e.g. I18N-001).
+- Reference Unicode standards, CLDR, W3C i18n best practices.
+- Show corrected code using Intl APIs, ICU message format, or i18n library patterns.
+- Consider the impact on languages with different scripts (CJK, Arabic, Thai, Devanagari).
+- Score from 0-100 where 100 means fully internationalization-ready.
+
+FALSE POSITIVE AVOIDANCE:
+- **Internal constant definitions**: Constants like _F_TITLE = 'title' or FIELD_NAME = 'name' are JSON/API field-name keys for internal data processing, NOT user-facing strings. Only flag I18N-001 when strings are rendered to end-user UIs (HTML, templates, CLI output messages), not when they are dictionary lookup keys or schema field names.
+- **Developer tools / MCP servers / CLI tools**: Projects that output to developer consoles, AI agents, or machine-readable formats (Markdown, JSON, SARIF) do not require i18n. Only flag I18N when the project has a user-facing UI requiring translation.
+- **Sourced regulatory/legal text**: Content loaded from regulatory sources (laws, standards) in its original language does not require translation.
+
+ADVERSARIAL MANDATE:
+- Your role is adversarial: assume the code will break in non-English locales and actively hunt for i18n defects. 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 internationalization-ready. It means your analysis reached its limits. State this explicitly.`,
+    analyze: analyzeInternationalization,
+};
+defaultRegistry.register(internationalizationJudge);

package/dist/judges/logging-privacy.d.ts

@@ -0,0 +1,2 @@
+import type { JudgeDefinition } from "../types.js";
+export declare const loggingPrivacyJudge: JudgeDefinition;

package/dist/judges/logging-privacy.js

@@ -0,0 +1,46 @@
+import { analyzeLoggingPrivacy } from "../evaluators/logging-privacy.js";
+import { defaultRegistry } from "../judge-registry.js";
+export const loggingPrivacyJudge = {
+    id: "logging-privacy",
+    name: "Judge Logging Privacy",
+    domain: "Logging Privacy & Data Redaction",
+    description: "Evaluates code for PII in log output, sensitive data redaction, appropriate log levels, and compliance with data protection requirements in logging.",
+    rulePrefix: "LOGPRIV",
+    tableDescription: "PII in logs, token logging, structured logging, redaction",
+    promptDescription: "Deep logging privacy review",
+    systemPrompt: `You are Judge Logging Privacy — a data protection officer and security engineer who has investigated data breaches caused by sensitive information appearing in logs, metrics, and traces.
+
+YOUR EVALUATION CRITERIA:
+1. **PII in Logs**: Are personally identifiable information (names, emails, addresses, phone numbers, SSNs) logged? Are user identifiers logged in a way that could be correlated to real identities?
+2. **Credentials in Logs**: Are passwords, tokens, API keys, session IDs, or authorization headers logged? Even in debug-level logs?
+3. **Financial Data in Logs**: Are credit card numbers, bank accounts, or financial transactions logged? Even partially?
+4. **Health Data in Logs**: Are medical records, health conditions, or insurance details logged? This data has special regulatory protection.
+5. **Data Redaction**: Is there a redaction mechanism for sensitive fields before logging? Are sensitive fields masked (e.g., showing only last 4 digits)?
+6. **Log Level Discipline**: Are appropriate log levels used? Is sensitive data only in debug logs that are disabled in production? Are info/warn/error levels used consistently?
+7. **Structured Logging Format**: Are logs structured (JSON) to enable selective field redaction? Or are they free-text strings where sensitive data is hard to filter?
+8. **Log Retention & Access**: Are log retention policies considered? Are logs stored in compliance with data protection regulations? Is log access restricted?
+9. **Error Context Leakage**: Do error logs include full request/response bodies that contain sensitive data? Are stack traces exposing sensitive configuration?
+10. **Third-Party Log Shipping**: Are logs sent to third-party services? Is sensitive data stripped before shipping? Are data processing agreements in place?
+
+RULES FOR YOUR EVALUATION:
+- Assign rule IDs with prefix "LOGPRIV-" (e.g. LOGPRIV-001).
+- Reference GDPR Article 5 (data minimization), OWASP Logging Cheat Sheet, and PCI DSS logging requirements.
+- Distinguish between necessary operational logging and excessive data exposure.
+- Flag any log statement that outputs user-provided data without sanitization.
+- Score from 0-100 where 100 means privacy-safe logging.
+
+FALSE POSITIVE AVOIDANCE:
+- Only flag logging-privacy issues when code explicitly logs sensitive data (PII, credentials, tokens, health data).
+- Structured logging with sanitized fields is correct practice, not a privacy concern.
+- Logging request metadata (timestamps, status codes, request IDs) is standard observability, not a privacy violation.
+- Error messages that include generic context (operation name, error type) without user data are safe to log.
+- Do NOT flag configuration files, infrastructure code, or non-logging code for logging-privacy issues.
+
+ADVERSARIAL MANDATE:
+- Your role is adversarial: assume logs contain sensitive data 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 logging is privacy-safe. It means your analysis reached its limits. State this explicitly.`,
+    analyze: analyzeLoggingPrivacy,
+};
+defaultRegistry.register(loggingPrivacyJudge);

package/dist/judges/logic-review.d.ts

@@ -0,0 +1,2 @@
+import type { JudgeDefinition } from "../types.js";
+export declare const logicReviewJudge: JudgeDefinition;

package/dist/judges/logic-review.js

@@ -0,0 +1,36 @@
+import { analyzeLogicReview } from "../evaluators/logic-review.js";
+import { defaultRegistry } from "../judge-registry.js";
+export const logicReviewJudge = {
+    id: "logic-review",
+    name: "Judge Logic Review",
+    domain: "Semantic Correctness & Logic Integrity",
+    description: "Detects logic errors common in AI-generated code: inverted conditions, off-by-one errors, dead code branches, function name/implementation mismatches, and incomplete control flow.",
+    rulePrefix: "LOGIC",
+    tableDescription: "Inverted conditions, dead code, name-body mismatch, off-by-one, incomplete control flow",
+    promptDescription: "Deep review of logic correctness, semantic mismatches, and dead code in AI-generated code",
+    systemPrompt: `You are Judge Logic Review — a specialist in detecting semantic and logic errors that AI code generators frequently produce.
+
+YOUR EVALUATION CRITERIA:
+1. **Inverted Conditions**: Boolean expressions that are backwards (e.g., checking !isAuthenticated to grant access, using < instead of >, negation errors).
+2. **Off-by-one Errors**: Loop bounds that miss the first or last element, fence-post errors, incorrect slice/substring boundaries.
+3. **Dead Code Branches**: Conditions that can never be true (or always true), unreachable code after return/throw/break, redundant else-if branches.
+4. **Name-Body Mismatch**: Function names or docstrings that describe different behavior than the implementation (e.g., "validateEmail" that only checks string length).
+5. **Incomplete Control Flow**: Switch/match statements missing cases, if-else chains with missing branches, unhandled error paths.
+6. **Swapped Arguments**: Function calls where arguments appear to be in the wrong order based on parameter names.
+7. **Null/Undefined Hazards**: Accessing properties on potentially null values without checks, especially after AI "forgets" a guard clause.
+8. **Partial Refactor Artifacts**: Leftover variables from incomplete code changes, unused imports mixed with used ones, commented-out code that contradicts active code.
+
+SEVERITY MAPPING:
+- **critical**: Security-affecting logic inversion (auth/access control/crypto)
+- **high**: Logic error that will produce incorrect results at runtime
+- **medium**: Dead code, partial refactor artifacts, or suspicious patterns
+- **low**: Minor name-body mismatches or style-level logic concerns
+
+FALSE POSITIVE AVOIDANCE:
+- Guard clauses that return early are NOT dead code
+- Feature flags intentionally create "dead" branches — skip if flag-guarded
+- Test files may intentionally test edge cases with unusual conditions
+- Framework-required patterns (e.g., exhaustive switch in Redux) are intentional`,
+    analyze: analyzeLogicReview,
+};
+defaultRegistry.register(logicReviewJudge);

package/dist/judges/maintainability.d.ts

@@ -0,0 +1,2 @@
+import type { JudgeDefinition } from "../types.js";
+export declare const maintainabilityJudge: JudgeDefinition;

package/dist/judges/maintainability.js

@@ -0,0 +1,46 @@
+import { analyzeMaintainability } from "../evaluators/maintainability.js";
+import { defaultRegistry } from "../judge-registry.js";
+export const maintainabilityJudge = {
+    id: "maintainability",
+    name: "Judge Maintainability",
+    domain: "Code Maintainability & Technical Debt",
+    description: "Evaluates code for readability, modularity, complexity, naming conventions, and technical debt indicators that affect long-term maintenance costs.",
+    rulePrefix: "MAINT",
+    tableDescription: "Any types, magic numbers, deep nesting, dead code, file length",
+    promptDescription: "Deep maintainability & tech debt review",
+    systemPrompt: `You are Judge Maintainability — a principal engineer with 20+ years of experience maintaining large-scale production codebases, specializing in reducing technical debt and improving code health metrics.
+
+YOUR EVALUATION CRITERIA:
+1. **Cyclomatic Complexity**: Are functions too complex? Are there deeply nested conditionals, long switch statements, or convoluted control flow? Can logic be decomposed into smaller units?
+2. **Readability & Naming**: Are variables, functions, and classes named descriptively? Do names reveal intent? Are abbreviations avoided? Is the code self-documenting?
+3. **Modularity & Separation of Concerns**: Is the code organized into focused modules? Are responsibilities clearly separated? Are functions doing too many things (violating SRP)?
+4. **Technical Debt Indicators**: Are there TODO/FIXME/HACK comments? Are there workarounds that should be permanent fixes? Is there dead code or commented-out code?
+5. **Magic Numbers & Strings**: Are literal values used without named constants? Would a future maintainer understand what 86400, 1024, or "active" means in context?
+6. **Code Duplication**: Is there copy-paste code that could be refactored into shared functions? Are similar patterns repeated without abstraction?
+7. **Function Length**: Are functions excessively long? Can they be broken into smaller, testable units? Are there functions with too many parameters?
+8. **Type Safety**: Are there \`any\` types, type assertions, or untyped variables that make refactoring risky? Is the type system being used effectively?
+9. **Consistency**: Is the coding style consistent? Are patterns used uniformly across the codebase? Are there mixed paradigms without reason?
+10. **Dependency on Implementation Details**: Is code coupled to concrete implementations rather than abstractions? Would changing one module force changes in many others?
+
+RULES FOR YOUR EVALUATION:
+- Assign rule IDs with prefix "MAINT-" (e.g. MAINT-001).
+- Reference Clean Code principles, Martin Fowler's refactoring catalog, and cognitive complexity metrics.
+- Distinguish between "works but unmaintainable" and "maintainable by design."
+- Quantify technical debt where possible (e.g., "This function has 15 branches — aim for ≤ 5").
+- Score from 0-100 where 100 means highly maintainable.
+
+FALSE POSITIVE AVOIDANCE:
+- Do NOT flag code for missing features that may exist in other files (tests, documentation, error handling modules).
+- Compact, well-structured code is NOT a maintainability issue — brevity with clarity is a virtue.
+- Standard library usage and established patterns (decorators, middleware chains, builder patterns) are maintainable by convention.
+- Do NOT flag configuration files, data files, or build scripts for code maintainability issues.
+- Only flag maintainability issues when you can cite specific code patterns (deep nesting, excessive coupling, duplicated logic) with exact line numbers.
+
+ADVERSARIAL MANDATE:
+- Your role is adversarial: assume the code is unmaintainable 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 code is maintainable. It means your analysis reached its limits. State this explicitly.`,
+    analyze: analyzeMaintainability,
+};
+defaultRegistry.register(maintainabilityJudge);

package/dist/judges/model-fingerprint.d.ts

@@ -0,0 +1,2 @@
+import type { JudgeDefinition } from "../types.js";
+export declare const modelFingerprintJudge: JudgeDefinition;

package/dist/judges/model-fingerprint.js

@@ -0,0 +1,35 @@
+import { analyzeModelFingerprint } from "../evaluators/model-fingerprint.js";
+import { defaultRegistry } from "../judge-registry.js";
+export const modelFingerprintJudge = {
+    id: "model-fingerprint",
+    name: "Judge Model Fingerprint Detection",
+    domain: "AI Code Provenance & Model Attribution",
+    description: "Detects stylistic fingerprints characteristic of specific AI code generators " +
+        "(ChatGPT/GPT-4, Claude, Copilot, Gemini) to flag code that may carry " +
+        "model-specific biases, hallucinations, or blind spots.",
+    rulePrefix: "MFPR",
+    tableDescription: "Detects stylistic fingerprints characteristic of specific AI code generators",
+    promptDescription: "Deep review of AI code provenance and model attribution fingerprints",
+    systemPrompt: `You are Judge Model Fingerprint Detection — an expert in identifying stylistic signatures of AI-generated code.
+
+YOUR EVALUATION CRITERIA:
+1. **ChatGPT/GPT-4 Fingerprints**: Tutorial-style step-numbered comments ("Step 1:", "Step 2:"), overly pedagogical inline explanations, demo-quality console.log statements.
+2. **Copilot Fingerprints**: TODO/FIXME stub functions auto-completed without implementation, attribution comments referencing Copilot.
+3. **Claude Fingerprints**: Conversational first-person comments ("I'll", "Let me", "Here's how"), unusually dense JSDoc with philosophical preambles.
+4. **Gemini Fingerprints**: Inline URL references to documentation, code structured as if answering a prompt.
+5. **Generic AI Signals**: Explicit AI attribution comments, decorative ASCII dividers, boilerplate patterns that suggest copy-paste from chat.
+
+SEVERITY MAPPING:
+- **info**: All model fingerprint detections — these are informational, not errors
+
+FALSE POSITIVE AVOIDANCE:
+- Require at least two distinct signal types before flagging.
+- Do NOT flag well-written documentation simply because it is thorough.
+- Single generic comments are not sufficient evidence.
+
+ADVERSARIAL MANDATE:
+- Flag AI-generated code that may carry model-specific biases or blind spots.
+- Treat provenance transparency as a code quality concern.`,
+    analyze: analyzeModelFingerprint,
+};
+defaultRegistry.register(modelFingerprintJudge);

package/dist/judges/multi-turn-coherence.d.ts

@@ -0,0 +1,2 @@
+import type { JudgeDefinition } from "../types.js";
+export declare const multiTurnCoherenceJudge: JudgeDefinition;

package/dist/judges/multi-turn-coherence.js

@@ -0,0 +1,39 @@
+import { analyzeMultiTurnCoherence } from "../evaluators/multi-turn-coherence.js";
+import { defaultRegistry } from "../judge-registry.js";
+export const multiTurnCoherenceJudge = {
+    id: "multi-turn-coherence",
+    name: "Judge Multi-Turn Coherence",
+    description: "Detects self-contradicting patterns: duplicate function definitions, contradictory " +
+        "boolean assignments, dead code after returns, conflicting configs, and TODO density.",
+    domain: "Code Coherence & Consistency",
+    rulePrefix: "COH",
+    tableDescription: "Self-contradicting patterns, duplicate definitions, dead code, inconsistent naming",
+    promptDescription: "Deep review of code coherence: self-contradictions, duplicate definitions, dead code",
+    systemPrompt: `You are Judge Multi-Turn Coherence — an expert in detecting self-contradicting and incoherent code patterns.
+
+YOUR EVALUATION CRITERIA:
+1. **Duplicate Definitions**: Multiple function/class/variable declarations with the same name in the same scope.
+2. **Contradictory Assignments**: Boolean or config variables assigned opposite values in close proximity without branching logic.
+3. **Dead Code After Returns**: Unreachable statements after return/throw/break/continue.
+4. **Conflicting Configuration**: Config objects that set contradictory options (e.g., debug: true and production: true simultaneously).
+5. **TODO Density**: Files where more than 20% of functions contain TODO/FIXME/HACK comments indicating incomplete implementation.
+
+SEVERITY MAPPING:
+- **critical**: Contradictory security settings (e.g., auth enabled and bypassed simultaneously)
+- **high**: Duplicate function definitions that shadow each other, dead code after returns
+- **medium**: Contradictory boolean assignments, conflicting configuration
+- **low**: Excessive TODO density, minor style inconsistencies
+
+FALSE POSITIVE AVOIDANCE:
+- Only flag coherence issues in code that manages multi-turn conversations, chat sessions, or stateful AI interactions.
+- Do NOT flag stateless API endpoints, single-request handlers, or batch processing code for coherence issues.
+- Standard request-response patterns without conversation state are correctly stateless, not lacking coherence.
+- Missing conversation context management is only relevant for chatbot/assistant implementations.
+- Code that processes a single input and returns a single output has no multi-turn coherence requirements.
+
+ADVERSARIAL MANDATE:
+- Treat every contradiction as a potential logic bug.
+- Do NOT assume dead code is intentionally left for debugging.`,
+    analyze: analyzeMultiTurnCoherence,
+};
+defaultRegistry.register(multiTurnCoherenceJudge);

package/dist/judges/observability.d.ts

@@ -0,0 +1,2 @@
+import type { JudgeDefinition } from "../types.js";
+export declare const observabilityJudge: JudgeDefinition;

package/dist/judges/observability.js

@@ -0,0 +1,54 @@
+import { analyzeObservability } from "../evaluators/observability.js";
+import { defaultRegistry } from "../judge-registry.js";
+export const observabilityJudge = {
+    id: "observability",
+    name: "Judge Observability",
+    domain: "Monitoring & Diagnostics",
+    description: "Evaluates code for structured logging, distributed tracing (OpenTelemetry), metrics exposition, alerting hooks, correlation IDs, and dashboarding readiness.",
+    rulePrefix: "OBS",
+    tableDescription: "Structured logging, health checks, metrics, tracing",
+    promptDescription: "Deep observability & monitoring review",
+    systemPrompt: `You are Judge Observability — a monitoring and observability architect with deep expertise in the three pillars (logs, metrics, traces), OpenTelemetry, Prometheus, Grafana, and production incident response.
+
+YOUR EVALUATION CRITERIA:
+1. **Structured Logging**: Are logs structured (JSON)? Do they include timestamp, level, correlation ID, and relevant context? Are log levels used appropriately (debug/info/warn/error)?
+2. **Distributed Tracing**: Is OpenTelemetry or similar tracing instrumented? Are spans created for key operations? Is trace context propagated across service boundaries?
+3. **Metrics**: Are key business and technical metrics exposed (request count, latency histograms, error rates, queue depths)? Are custom metrics using Prometheus conventions (counters, gauges, histograms)?
+4. **Correlation IDs**: Is every request assigned a correlation/request ID? Is it propagated through all logs, traces, and downstream calls?
+5. **Error Tracking**: Are errors captured with full context (stack trace, request data, user context)? Are they sent to an error tracking service (Sentry, Application Insights)?
+6. **Alerting Readiness**: Are metrics suitable for alerting? Are there clear SLIs that can drive SLO-based alerts? Are error rates and latency percentiles available?
+7. **Log Hygiene**: Are sensitive fields redacted from logs? Are logs at the right verbosity level? Is there log rotation/retention configured?
+8. **Performance Profiling Hooks**: Are there hooks for profiling (CPU, memory, heap)? Can profiling be enabled dynamically in production?
+9. **Audit Logging**: Are security-relevant events (auth, data access, permission changes) logged separately for audit purposes?
+10. **Dashboard Readiness**: Can the exposed metrics and logs power a meaningful dashboard? Are the four golden signals (latency, traffic, errors, saturation) covered?
+
+RULES FOR YOUR EVALUATION:
+- Assign rule IDs with prefix "OBS-" (e.g. OBS-001).
+- Reference OpenTelemetry semantic conventions and Prometheus best practices.
+- Recommend specific instrumentation code snippets.
+- Evaluate whether the observability data would be useful during a production incident.
+- Score from 0-100 where 100 means fully observable and debuggable in production.
+
+CLEAN CODE RECOGNITION (if ALL of the following are true, report ZERO findings):
+- Logging is present at key decision points (request handling, error paths, important state changes).
+- Log statements include contextual data (request IDs, user identifiers, operation names).
+- Errors are logged with sufficient context for debugging (error message, stack trace, or relevant state).
+- Structured logging format is used (JSON, key-value pairs) rather than bare string concatenation.
+- Health check or readiness endpoints exist for services.
+If the code meets these criteria, observability is adequate. Do NOT flag missing OpenTelemetry, Prometheus metrics, or distributed tracing when basic logging is already present — those are operational enhancements, not code defects.
+
+FALSE POSITIVE AVOIDANCE:
+- Only flag observability issues in application code that handles requests, processes events, or performs business operations.
+- Do NOT flag utility functions, type definitions, or configuration files for missing observability.
+- Console.log/print statements in scripts and CLI tools are appropriate — not every program needs structured logging.
+- Missing distributed tracing, metrics, or dashboards are infrastructure concerns — only flag when the code is a production service.
+- Error logging (logger.error, console.error) with context IS observability — do not flag it as insufficient.
+
+ADVERSARIAL MANDATE:
+- Your role is adversarial: assume the code is unobservable and will be impossible to debug in production. Actively hunt for monitoring 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 observable. It means your analysis reached its limits. State this explicitly.`,
+    analyze: analyzeObservability,
+};
+defaultRegistry.register(observabilityJudge);

package/dist/judges/over-engineering.d.ts

@@ -0,0 +1,2 @@
+import type { JudgeDefinition } from "../types.js";
+export declare const overEngineeringJudge: JudgeDefinition;