Reglas del Repositorio

---
title: "<nombre de la regla>"
scope: "file"            # "file" o "pull-request"
path: []                 # lista de globs. ejemplo: ["**/*.ts", "apps/web/**"]
severity_min: "high"     # "low", "medium", "high", "critical"
languages: []            # opcional. ej: ["jsts", "go", "php", "ruby", "java", "csharp", "dart", "kotlin", "rust"]
buckets: []              # opcional. ej: ["style-conventions", "error-handling", "security"]
uuid: ""                 # opcional. usar para ID de regla estable
enabled: true            # opcional
---

## Instructions
Describe qué revisar y cómo decidir. Sé directo y objetivo.
- Enfócate en seguridad, rendimiento e impactos en el contrato público.
- Proporciona preferencias o patrones del equipo cuando sea aplicable.
- Si es una regla de PR, explica qué considerar en el conjunto de cambios.

## Examples

### Bad example
\`\`\`lang
// pega aquí un contraejemplo corto que viole la regla
\`\`\`

### Good example  
\`\`\`lang
// pega aquí un ejemplo corto que siga la regla
\`\`\`

---
title: "Avoid console.log in production code"
scope: "file"
path: ["src/**/*.ts", "src/**/*.tsx"]
severity_min: "medium"
languages: ["jsts"]
buckets: ["style-conventions"]
enabled: true
---

## Instructions
Check for console.log statements in production TypeScript/JavaScript files.
- Console logs should not appear in production code
- Use proper logging libraries instead
- Allow console.log only in development utilities

## Examples

### Bad example
\`\`\`typescript
function processUser(user: User) {
  console.log('Processing user:', user.id);
  return user.process();
}
\`\`\`

### Good example
\`\`\`typescript
import { logger } from './logger';

function processUser(user: User) {
  logger.info('Processing user:', user.id);
  return user.process();
}
\`\`\`

---
title: "New API endpoints must have tests"
scope: "pull-request"
path: ["**/*"]
severity_min: "high"
buckets: ["testing"]
enabled: true
---

## Instructions
When new API endpoints are added, ensure corresponding tests are included in the PR.
- Check for new route definitions in controllers
- Verify test files exist for new endpoints
- Ensure both positive and negative test cases

## Examples

### Bad example
Added new endpoint `/api/users/profile` but no test file included in the PR.

### Good example
Added new endpoint `/api/users/profile` with corresponding test file `tests/api/users/profile.test.ts` that covers success and error cases.

docker logs kodus_api 2>&1 | grep "kody-rules-sync"
docker logs kodus_api 2>&1 | grep "kody-rules-eval"