@kevinrabun/judges 3.123.4 → 3.124.0

package/agents/api-design.judge.md

@@ -32,6 +32,15 @@ RULES FOR YOUR EVALUATION:
 - Consider both API producer and consumer perspectives.
 - Score from 0-100 where 100 means exemplary API design.
 
+CLEAN CODE RECOGNITION (if ALL of the following are true, report ZERO findings):
+- API endpoints follow RESTful conventions with appropriate HTTP methods and status codes.
+- Input validation is present (schema validation, type checking, or manual guards).
+- Error responses use a consistent format with meaningful error codes/messages.
+- Pagination or result limits are applied to collection endpoints.
+- API versioning strategy is apparent (URL path, header, or documented convention).
+- Response shapes are consistent across similar endpoints.
+If the code meets these criteria, the API design is sound. Do NOT flag stylistic preferences or theoretical improvements.
+
 FALSE POSITIVE AVOIDANCE:
 - Only flag API design issues in code that defines or implements HTTP/REST/GraphQL API endpoints.
 - Do NOT flag CLI tools, batch scripts, internal libraries, or infrastructure code for API design issues.

package/agents/cloud-readiness.judge.md

@@ -30,6 +30,13 @@ RULES FOR YOUR EVALUATION:
 - Recommend specific services or patterns (e.g., "Use Azure Key Vault instead of .env files in production").
 - Score from 0-100 where 100 means fully cloud-native.
 
+CLEAN CODE RECOGNITION (if ALL of the following are true, report ZERO findings):
+- Configuration is loaded from environment variables or external config stores.
+- The application binds to configurable ports, not hardcoded values.
+- File system usage is for temporary/cache purposes, not persistent state.
+- External dependencies (DB, cache, queues) use client libraries with connection pooling.
+If the code follows 12-factor app principles, it is cloud-ready. Do NOT flag theoretical cloud improvements when the code already works correctly in containerized environments.
+
 FALSE POSITIVE AVOIDANCE:
 - Only flag cloud-readiness issues in code that involves cloud deployment, containerization, or distributed systems.
 - Do NOT flag local development utilities, CLI tools, or scripts for cloud-readiness issues.

package/agents/compliance.judge.md

@@ -30,6 +30,13 @@ RULES FOR YOUR EVALUATION:
 - Recommend both code changes and process changes where applicable.
 - Score from 0-100 where 100 means fully compliant.
 
+CLEAN CODE RECOGNITION (if ALL of the following are true, report ZERO findings):
+- Audit logging is present for administrative and data-modifying operations.
+- User consent management is implemented where personal data is collected.
+- Data retention policies are documented or implemented in code.
+- Access controls are present for sensitive data and operations.
+If the code demonstrates compliance awareness, do NOT flag it for missing specific certification requirements (HIPAA, PCI-DSS, SOC 2) that are organizational rather than code-level concerns.
+
 FALSE POSITIVE AVOIDANCE:
 - **"age" in cache/TTL contexts**: The word "age" in cache_age, max_age, ttl_age, stale_age refers to data freshness timing, NOT user age or minor-age verification. Only flag COMP-001 for age-related compliance when the code processes date-of-birth, minor status, or parental consent — not cache expiration.
 

package/agents/data-security.judge.md

@@ -27,6 +27,13 @@ RULES FOR YOUR EVALUATION:
 - Reference standards where applicable (OWASP, NIST 800-53, GDPR Article numbers).
 - Score from 0-100 where 100 means fully compliant with no findings.
 
+CLEAN CODE RECOGNITION (if ALL of the following are true, report ZERO findings):
+- Sensitive data (PII, credentials, tokens) is not logged, returned in error responses, or stored in plaintext.
+- Cryptographic operations use standard libraries with recommended algorithms (AES-256-GCM, SHA-256+, bcrypt/scrypt).
+- Database credentials and API keys are loaded from environment variables or secrets managers.
+- Data at rest and in transit uses encryption (TLS, encrypted storage).
+If the code meets these criteria, data security is properly implemented. Do NOT flag theoretical data handling improvements.
+
 FALSE POSITIVE AVOIDANCE:
 - Do NOT flag code that uses established encryption libraries (crypto, sodium, bouncy castle) with standard configurations.
 - Data flowing through authenticated APIs with proper access controls is not a data security issue.

package/agents/database.judge.md

@@ -30,6 +30,14 @@ RULES FOR YOUR EVALUATION:
 - Flag patterns that will degrade as data volume grows.
 - Score from 0-100 where 100 means excellent database practices.
 
+CLEAN CODE RECOGNITION (if ALL of the following are true, report ZERO findings):
+- Queries use parameterized statements or an ORM with proper escaping.
+- Connection pooling is configured (not per-request connections).
+- Transactions are used for multi-step data modifications.
+- No SELECT * in production queries — columns are explicitly listed.
+- Indexes are referenced in query design or migration files.
+If the code uses an ORM with standard patterns, database practices are adequate. Do NOT flag ORM-generated queries or standard CRUD operations.
+
 FALSE POSITIVE AVOIDANCE:
 - **Environment variable fallback defaults**: Connection strings in os.environ.get('DB_URL', 'sqlite:///default.db') or process.env.DB_URL || 'localhost' are standard development defaults, NOT hardcoded production credentials. Only flag DB-001 when a connection string with real credentials appears outside an env-var fallback pattern.
 - **In-memory/embedded databases as defaults**: SQLite, DuckDB, or H2 defaults are normal for local development and testing. Flag only when production deployment docs are missing, not the default value itself.

package/agents/documentation.judge.md

@@ -32,6 +32,13 @@ RULES FOR YOUR EVALUATION:
 - Evaluate from the perspective of a new developer encountering the code for the first time.
 - Score from 0-100 where 100 means exemplary documentation.
 
+CLEAN CODE RECOGNITION (if ALL of the following are true, report ZERO findings):
+- Public/exported functions have JSDoc, docstrings, or clear descriptive names that convey purpose.
+- Complex algorithms or non-obvious logic have inline comments explaining the "why."
+- Function/method names and parameter names are self-documenting.
+- Module or file has a top-level comment or README describing its purpose (if it's a standalone module).
+If the code is reasonably self-documenting, do NOT demand exhaustive JSDoc on every function. Well-named code does not need redundant documentation.
+
 FALSE POSITIVE AVOIDANCE:
 - Do NOT flag missing documentation for self-documenting code (clear function names, obvious parameters, standard patterns).
 - Configuration files, data files, and infrastructure code have different documentation standards than application code.

package/agents/observability.judge.md

@@ -30,6 +30,14 @@ RULES FOR YOUR EVALUATION:
 - 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.

package/agents/reliability.judge.md

@@ -32,6 +32,15 @@ RULES FOR YOUR EVALUATION:
 - Recommend specific resilience libraries or patterns with configuration examples.
 - Score from 0-100 where 100 means highly resilient and fault-tolerant.
 
+CLEAN CODE RECOGNITION (if ALL of the following are true, report ZERO findings):
+- External I/O operations (network, database, file) have error handling (try/catch, error callbacks, or Result types).
+- HTTP responses check status codes before processing data.
+- Promises/async operations have rejection handling.
+- Resource cleanup is present (finally blocks, defer, using/with statements, or disposal patterns).
+- No fire-and-forget async operations on critical paths.
+- Timeouts are configured for external calls.
+If the code meets these criteria, it is handling failures appropriately. Do NOT flag missing retry logic, circuit breakers, or graceful degradation when error handling is already present — those are architectural enhancements, not defects.
+
 FALSE POSITIVE AVOIDANCE:
 - Only flag reliability issues in code that handles production workloads, external dependencies, or user-facing operations.
 - Scripts, CLI tools, and development utilities have different reliability requirements than production services.

package/agents/scalability.judge.md

@@ -30,6 +30,15 @@ RULES FOR YOUR EVALUATION:
 - Recommend specific architectural patterns (CQRS, event sourcing, circuit breakers, etc.).
 - Score from 0-100 where 100 means fully scalable with no bottlenecks.
 
+CLEAN CODE RECOGNITION (if ALL of the following are true, report ZERO findings):
+- Database queries use parameterized statements and avoid N+1 patterns.
+- No unbounded in-memory collections (results are paginated or streamed).
+- Connection pooling is used for database connections (not per-request connections).
+- Background/async processing for long-running operations.
+- No global mutable state that would prevent horizontal scaling.
+- Caching strategy is present for frequently-accessed data.
+If the code meets these criteria, it is reasonably scalable. Do NOT flag theoretical scaling concerns for code that already follows standard patterns — only flag concrete bottlenecks that would fail under realistic load.
+
 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.

package/agents/software-practices.judge.md

@@ -32,6 +32,16 @@ RULES FOR YOUR EVALUATION:
 - Reference Clean Code (Robert Martin), SOLID, DRY, KISS, YAGNI where applicable.
 - Score from 0-100 where 100 means exemplary software engineering.
 
+CLEAN CODE RECOGNITION (if ALL of the following are true, report ZERO findings):
+- Code follows consistent naming conventions and formatting throughout.
+- Functions/methods are reasonably sized (under ~50 lines) with clear single responsibilities.
+- No bare linter/type-checker suppression directives without justification.
+- Variables use const/let (not var) and meaningful names — no single-letter names outside loops.
+- Error handling is present for I/O operations and external calls.
+- No obvious code duplication (copy-paste blocks of 10+ lines).
+- Dependencies are imported from standard registries, not vendored or outdated.
+If the code meets these criteria, it follows good software practices. Do NOT manufacture findings about theoretical improvements.
+
 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.

package/agents/testing.judge.md

@@ -32,6 +32,12 @@ RULES FOR YOUR EVALUATION:
 - Evaluate both the tests AND the testability of the code under test.
 - Score from 0-100 where 100 means comprehensive, well-structured test suite.
 
+CLEAN CODE RECOGNITION (if ALL of the following are true, report ZERO findings):
+- The code being evaluated IS a test file, OR the code is a small utility/helper that would be tested at a higher level.
+- Type definitions, interfaces, enums, and configuration files do not need dedicated tests.
+- Generated code, data migrations, and infrastructure-as-code have different testing strategies.
+Do NOT flag code for "missing tests" unless it contains complex business logic or critical paths that clearly need unit test coverage.
+
 FALSE POSITIVE AVOIDANCE:
 - Only flag testing issues when evaluating test files or when application code lacks testability.
 - Do NOT flag production code for "missing tests" — tests exist in separate files that may not be provided.

package/dist/judges/api-design.js

@@ -31,6 +31,15 @@ RULES FOR YOUR EVALUATION:
 - Consider both API producer and consumer perspectives.
 - Score from 0-100 where 100 means exemplary API design.
 
+CLEAN CODE RECOGNITION (if ALL of the following are true, report ZERO findings):
+- API endpoints follow RESTful conventions with appropriate HTTP methods and status codes.
+- Input validation is present (schema validation, type checking, or manual guards).
+- Error responses use a consistent format with meaningful error codes/messages.
+- Pagination or result limits are applied to collection endpoints.
+- API versioning strategy is apparent (URL path, header, or documented convention).
+- Response shapes are consistent across similar endpoints.
+If the code meets these criteria, the API design is sound. Do NOT flag stylistic preferences or theoretical improvements.
+
 FALSE POSITIVE AVOIDANCE:
 - Only flag API design issues in code that defines or implements HTTP/REST/GraphQL API endpoints.
 - Do NOT flag CLI tools, batch scripts, internal libraries, or infrastructure code for API design issues.

package/dist/judges/cloud-readiness.js

@@ -29,6 +29,13 @@ RULES FOR YOUR EVALUATION:
 - Recommend specific services or patterns (e.g., "Use Azure Key Vault instead of .env files in production").
 - Score from 0-100 where 100 means fully cloud-native.
 
+CLEAN CODE RECOGNITION (if ALL of the following are true, report ZERO findings):
+- Configuration is loaded from environment variables or external config stores.
+- The application binds to configurable ports, not hardcoded values.
+- File system usage is for temporary/cache purposes, not persistent state.
+- External dependencies (DB, cache, queues) use client libraries with connection pooling.
+If the code follows 12-factor app principles, it is cloud-ready. Do NOT flag theoretical cloud improvements when the code already works correctly in containerized environments.
+
 FALSE POSITIVE AVOIDANCE:
 - Only flag cloud-readiness issues in code that involves cloud deployment, containerization, or distributed systems.
 - Do NOT flag local development utilities, CLI tools, or scripts for cloud-readiness issues.

package/dist/judges/compliance.js

@@ -29,6 +29,13 @@ RULES FOR YOUR EVALUATION:
 - Recommend both code changes and process changes where applicable.
 - Score from 0-100 where 100 means fully compliant.
 
+CLEAN CODE RECOGNITION (if ALL of the following are true, report ZERO findings):
+- Audit logging is present for administrative and data-modifying operations.
+- User consent management is implemented where personal data is collected.
+- Data retention policies are documented or implemented in code.
+- Access controls are present for sensitive data and operations.
+If the code demonstrates compliance awareness, do NOT flag it for missing specific certification requirements (HIPAA, PCI-DSS, SOC 2) that are organizational rather than code-level concerns.
+
 FALSE POSITIVE AVOIDANCE:
 - **"age" in cache/TTL contexts**: The word "age" in cache_age, max_age, ttl_age, stale_age refers to data freshness timing, NOT user age or minor-age verification. Only flag COMP-001 for age-related compliance when the code processes date-of-birth, minor status, or parental consent — not cache expiration.
 

package/dist/judges/data-security.js

@@ -26,6 +26,13 @@ RULES FOR YOUR EVALUATION:
 - Reference standards where applicable (OWASP, NIST 800-53, GDPR Article numbers).
 - Score from 0-100 where 100 means fully compliant with no findings.
 
+CLEAN CODE RECOGNITION (if ALL of the following are true, report ZERO findings):
+- Sensitive data (PII, credentials, tokens) is not logged, returned in error responses, or stored in plaintext.
+- Cryptographic operations use standard libraries with recommended algorithms (AES-256-GCM, SHA-256+, bcrypt/scrypt).
+- Database credentials and API keys are loaded from environment variables or secrets managers.
+- Data at rest and in transit uses encryption (TLS, encrypted storage).
+If the code meets these criteria, data security is properly implemented. Do NOT flag theoretical data handling improvements.
+
 FALSE POSITIVE AVOIDANCE:
 - Do NOT flag code that uses established encryption libraries (crypto, sodium, bouncy castle) with standard configurations.
 - Data flowing through authenticated APIs with proper access controls is not a data security issue.

package/dist/judges/database.js

@@ -29,6 +29,14 @@ RULES FOR YOUR EVALUATION:
 - Flag patterns that will degrade as data volume grows.
 - Score from 0-100 where 100 means excellent database practices.
 
+CLEAN CODE RECOGNITION (if ALL of the following are true, report ZERO findings):
+- Queries use parameterized statements or an ORM with proper escaping.
+- Connection pooling is configured (not per-request connections).
+- Transactions are used for multi-step data modifications.
+- No SELECT * in production queries — columns are explicitly listed.
+- Indexes are referenced in query design or migration files.
+If the code uses an ORM with standard patterns, database practices are adequate. Do NOT flag ORM-generated queries or standard CRUD operations.
+
 FALSE POSITIVE AVOIDANCE:
 - **Environment variable fallback defaults**: Connection strings in os.environ.get('DB_URL', 'sqlite:///default.db') or process.env.DB_URL || 'localhost' are standard development defaults, NOT hardcoded production credentials. Only flag DB-001 when a connection string with real credentials appears outside an env-var fallback pattern.
 - **In-memory/embedded databases as defaults**: SQLite, DuckDB, or H2 defaults are normal for local development and testing. Flag only when production deployment docs are missing, not the default value itself.

package/dist/judges/documentation.js

@@ -31,6 +31,13 @@ RULES FOR YOUR EVALUATION:
 - Evaluate from the perspective of a new developer encountering the code for the first time.
 - Score from 0-100 where 100 means exemplary documentation.
 
+CLEAN CODE RECOGNITION (if ALL of the following are true, report ZERO findings):
+- Public/exported functions have JSDoc, docstrings, or clear descriptive names that convey purpose.
+- Complex algorithms or non-obvious logic have inline comments explaining the "why."
+- Function/method names and parameter names are self-documenting.
+- Module or file has a top-level comment or README describing its purpose (if it's a standalone module).
+If the code is reasonably self-documenting, do NOT demand exhaustive JSDoc on every function. Well-named code does not need redundant documentation.
+
 FALSE POSITIVE AVOIDANCE:
 - Do NOT flag missing documentation for self-documenting code (clear function names, obvious parameters, standard patterns).
 - Configuration files, data files, and infrastructure code have different documentation standards than application code.

package/dist/judges/observability.js

@@ -29,6 +29,14 @@ RULES FOR YOUR EVALUATION:
 - 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.

package/dist/judges/reliability.js

@@ -31,6 +31,15 @@ RULES FOR YOUR EVALUATION:
 - Recommend specific resilience libraries or patterns with configuration examples.
 - Score from 0-100 where 100 means highly resilient and fault-tolerant.
 
+CLEAN CODE RECOGNITION (if ALL of the following are true, report ZERO findings):
+- External I/O operations (network, database, file) have error handling (try/catch, error callbacks, or Result types).
+- HTTP responses check status codes before processing data.
+- Promises/async operations have rejection handling.
+- Resource cleanup is present (finally blocks, defer, using/with statements, or disposal patterns).
+- No fire-and-forget async operations on critical paths.
+- Timeouts are configured for external calls.
+If the code meets these criteria, it is handling failures appropriately. Do NOT flag missing retry logic, circuit breakers, or graceful degradation when error handling is already present — those are architectural enhancements, not defects.
+
 FALSE POSITIVE AVOIDANCE:
 - Only flag reliability issues in code that handles production workloads, external dependencies, or user-facing operations.
 - Scripts, CLI tools, and development utilities have different reliability requirements than production services.

package/dist/judges/scalability.js

@@ -29,6 +29,15 @@ RULES FOR YOUR EVALUATION:
 - Recommend specific architectural patterns (CQRS, event sourcing, circuit breakers, etc.).
 - Score from 0-100 where 100 means fully scalable with no bottlenecks.
 
+CLEAN CODE RECOGNITION (if ALL of the following are true, report ZERO findings):
+- Database queries use parameterized statements and avoid N+1 patterns.
+- No unbounded in-memory collections (results are paginated or streamed).
+- Connection pooling is used for database connections (not per-request connections).
+- Background/async processing for long-running operations.
+- No global mutable state that would prevent horizontal scaling.
+- Caching strategy is present for frequently-accessed data.
+If the code meets these criteria, it is reasonably scalable. Do NOT flag theoretical scaling concerns for code that already follows standard patterns — only flag concrete bottlenecks that would fail under realistic load.
+
 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.

package/dist/judges/software-practices.js

@@ -31,6 +31,16 @@ RULES FOR YOUR EVALUATION:
 - Reference Clean Code (Robert Martin), SOLID, DRY, KISS, YAGNI where applicable.
 - Score from 0-100 where 100 means exemplary software engineering.
 
+CLEAN CODE RECOGNITION (if ALL of the following are true, report ZERO findings):
+- Code follows consistent naming conventions and formatting throughout.
+- Functions/methods are reasonably sized (under ~50 lines) with clear single responsibilities.
+- No bare linter/type-checker suppression directives without justification.
+- Variables use const/let (not var) and meaningful names — no single-letter names outside loops.
+- Error handling is present for I/O operations and external calls.
+- No obvious code duplication (copy-paste blocks of 10+ lines).
+- Dependencies are imported from standard registries, not vendored or outdated.
+If the code meets these criteria, it follows good software practices. Do NOT manufacture findings about theoretical improvements.
+
 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.

package/dist/judges/testing.js

@@ -31,6 +31,12 @@ RULES FOR YOUR EVALUATION:
 - Evaluate both the tests AND the testability of the code under test.
 - Score from 0-100 where 100 means comprehensive, well-structured test suite.
 
+CLEAN CODE RECOGNITION (if ALL of the following are true, report ZERO findings):
+- The code being evaluated IS a test file, OR the code is a small utility/helper that would be tested at a higher level.
+- Type definitions, interfaces, enums, and configuration files do not need dedicated tests.
+- Generated code, data migrations, and infrastructure-as-code have different testing strategies.
+Do NOT flag code for "missing tests" unless it contains complex business logic or critical paths that clearly need unit test coverage.
+
 FALSE POSITIVE AVOIDANCE:
 - Only flag testing issues when evaluating test files or when application code lacks testability.
 - Do NOT flag production code for "missing tests" — tests exist in separate files that may not be provided.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@kevinrabun/judges",
-  "version": "3.123.4",
+  "version": "3.124.0",
   "description": "45 specialized judges that evaluate AI-generated code for security, cost, and quality.",
   "mcpName": "io.github.KevinRabun/judges",
   "type": "module",

package/server.json

@@ -16,12 +16,12 @@
       "mimeType": "image/png"
     }
   ],
-  "version": "3.123.4",
+  "version": "3.124.0",
   "packages": [
     {
       "registryType": "npm",
       "identifier": "@kevinrabun/judges",
-      "version": "3.123.4",
+      "version": "3.124.0",
       "transport": {
         "type": "stdio"
       }