Regras do Repositório

---
title: "<nome da regra>"
scope: "file"            # "file" ou "pull-request"
path: []                 # lista de globs. exemplo: ["**/*.ts", "apps/web/**"]
severity_min: "high"     # "low", "medium", "high", "critical"
languages: []            # opcional. ex: ["jsts", "go", "php", "ruby", "java", "csharp", "dart", "kotlin", "rust"]
buckets: []              # opcional. ex: ["style-conventions", "error-handling", "security"]
uuid: ""                 # opcional. use para ID de regra estável
enabled: true            # opcional
---

## Instructions
Descreva o que revisar e como decidir. Seja direto e objetivo.
- Foque nos impactos de segurança, performance e contrato público.
- Forneça preferências ou padrões da equipe quando aplicável.
- Se for uma regra de PR, explique o que considerar no changeset.

## Examples

### Bad example
\`\`\`lang
// cole aqui um breve contra-exemplo que viola a regra
\`\`\`

### Good example  
\`\`\`lang
// cole aqui um breve exemplo que segue a regra
\`\`\`

---
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"