Repository Rules

---
title: "<rule name>"
scope: "file"            # "file" or "pull-request"
path: []                 # list of globs. example: ["**/*.ts", "apps/web/**"]
severity_min: "high"     # "low", "medium", "high", "critical"
languages: []            # optional. ex: ["jsts", "go", "php", "ruby", "java", "csharp", "dart", "kotlin", "rust"]
buckets: []              # optional. ex: ["style-conventions", "error-handling", "security"]
uuid: ""                 # optional. use for stable rule ID
enabled: true            # optional
---

## Instructions
Describe what to review and how to decide. Be direct and objective.
- Focus on security, performance and public contract impacts.
- Give team preferences or patterns when applicable.
- If it's a PR rule, explain what to consider in the changeset.

## Examples

### Bad example
\`\`\`lang
// paste here a short counter-example that violates the rule
\`\`\`

### Good example  
\`\`\`lang
// paste here a short example that follows the rule
\`\`\`

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