claudient 0.1.0

package/rules/common/coding-style.md

@@ -0,0 +1,45 @@
+# Coding Style Rules
+
+Copy the relevant sections into your project's `CLAUDE.md`.
+
+---
+
+## Naming
+
+- Variables and functions: `camelCase` (JS/TS), `snake_case` (Python, Go, Rust)
+- Classes and types: `PascalCase` in all languages
+- Constants: `SCREAMING_SNAKE_CASE` only for true constants that never change
+- Boolean variables: prefix with `is`, `has`, `can`, `should` — `isActive`, `hasPermission`
+- Do not abbreviate names unless the abbreviation is universally known (`id`, `url`, `db`, `ctx`)
+
+## Functions
+
+- One responsibility per function — if you need "and" in the description, split it
+- Maximum 40 lines per function; if longer, extract sub-functions
+- No boolean parameters — use an options object or two separate functions
+- Return early for guard clauses — don't nest the happy path inside conditionals
+
+## Comments
+
+- Write no comments unless the WHY is non-obvious
+- Never write comments that describe what the code does (the code already does that)
+- Write a comment when: there is a hidden constraint, a workaround for a specific bug, or behavior that would surprise a reader
+- Never write TODO comments — create a tracked issue instead
+
+## Error handling
+
+- Never swallow errors silently (`catch (e) {}` is always wrong)
+- Always handle errors at the boundary where you can take action
+- Propagate errors upward with context — wrap with the relevant ID or operation name
+- Do not use `console.error` in production code — use the project's logger
+
+## File organization
+
+- One primary export per file
+- File names match their primary export: `UserService.ts` exports `UserService`
+- No barrel files (`index.ts` re-exports) — import directly from the source file
+- Group imports: external packages first, then internal modules, then relative imports
+
+---
+
+> **Work with us:** Claudient is backed by [Uitbreiden](https://uitbreiden.com/) — we build AI products and B2B solutions with developer communities. [uitbreiden.com](https://uitbreiden.com/)

package/rules/common/de/coding-style.md

@@ -0,0 +1,47 @@
+> 🇩🇪 Dies ist die deutsche Übersetzung. [Englische Version](../coding-style.md).
+
+# Coding Style Regeln
+
+Relevante Abschnitte in die `CLAUDE.md` des Projekts kopieren.
+
+---
+
+## Benennung
+
+- Variablen und Funktionen: `camelCase` (JS/TS), `snake_case` (Python, Go, Rust)
+- Klassen und Typen: `PascalCase` in allen Sprachen
+- Konstanten: `SCREAMING_SNAKE_CASE` nur für echte Konstanten, die sich nie ändern
+- Boolesche Variablen: Präfix mit `is`, `has`, `can`, `should` — `isActive`, `hasPermission`
+- Namen nicht abkürzen, außer die Abkürzung ist allgemein bekannt (`id`, `url`, `db`, `ctx`)
+
+## Funktionen
+
+- Eine Verantwortlichkeit pro Funktion — wenn "und" in der Beschreibung benötigt wird, aufteilen
+- Maximal 40 Zeilen pro Funktion; bei längeren Unterfunktionen extrahieren
+- Keine booleschen Parameter — ein Options-Objekt oder zwei separate Funktionen verwenden
+- Frühzeitig bei Guard-Klauseln zurückkehren — den Happy Path nicht innerhalb von Bedingungen verschachteln
+
+## Kommentare
+
+- Keine Kommentare schreiben, außer das WARUM ist nicht offensichtlich
+- Niemals Kommentare schreiben, die beschreiben, was der Code tut (das macht der Code bereits)
+- Kommentar schreiben wenn: eine versteckte Einschränkung vorhanden ist, ein Workaround für einen bestimmten Bug, oder Verhalten, das einen Leser überraschen würde
+- Niemals TODO-Kommentare schreiben — stattdessen ein nachverfolgbares Issue erstellen
+
+## Fehlerbehandlung
+
+- Fehler niemals stillschweigend schlucken (`catch (e) {}` ist immer falsch)
+- Fehler immer an der Grenze behandeln, wo eine Aktion möglich ist
+- Fehler nach oben propagieren mit Kontext — mit der relevanten ID oder dem Operationsnamen umschließen
+- Kein `console.error` in Produktionscode verwenden — den Logger des Projekts verwenden
+
+## Dateiorganisation
+
+- Ein primärer Export pro Datei
+- Dateinamen passen zu ihrem primären Export: `UserService.ts` exportiert `UserService`
+- Keine Barrel-Dateien (`index.ts`-Re-Exports) — direkt aus der Quelldatei importieren
+- Imports gruppieren: zuerst externe Pakete, dann interne Module, dann relative Imports
+
+---
+
+> **Mit uns arbeiten:** Claudient wird von [Uitbreiden](https://uitbreiden.com/) unterstützt — wir bauen KI-Produkte und B2B-Lösungen mit Entwickler-Communities. [uitbreiden.com](https://uitbreiden.com/)

package/rules/common/de/git.md

@@ -0,0 +1,48 @@
+> 🇩🇪 Dies ist die deutsche Übersetzung. [Englische Version](../git.md).
+
+# Git Regeln
+
+Relevante Abschnitte in die `CLAUDE.md` des Projekts kopieren.
+
+---
+
+## Commit-Nachrichten
+
+- Format: `type: kurze Beschreibung` (Imperativ-Modus, ≤ 72 Zeichen)
+- Typen: `feat`, `fix`, `docs`, `refactor`, `test`, `chore`, `perf`
+- Beispiele: `feat: add webhook signature verification`, `fix: handle null user in auth middleware`
+- Keine generischen Nachrichten: "update", "changes", "fix bug", "wip" sind nicht akzeptabel
+- Body (optional): WARUM erklären, nicht was. Das Diff zeigt was.
+
+## Branches
+
+- Feature-Branches: `feat/kurze-beschreibung`
+- Bugfixes: `fix/kurze-beschreibung`
+- Niemals direkt in `main` oder `master` committen
+- Branches nach dem Merge löschen
+
+## Was niemals committen
+
+- `.env`-Dateien oder jede Datei, die Secrets enthält
+- `node_modules/`, `__pycache__/`, Build-Artefakte
+- Persönliche Editor-Einstellungen (`.idea/`, `.vscode/settings.json`)
+- Dateien > 10MB (git-lfs oder externen Speicher verwenden)
+- Generierte Dateien, die aus dem Quellcode reproduziert werden können
+
+## Vor dem Pushen
+
+- Tests lokal ausführen — niemals rot pushen
+- Eigenes Diff vor jedem Push überprüfen: `git diff origin/main...HEAD`
+- WIP-Commits squashen, bevor zu einem geteilten Branch gepusht wird
+- Niemals `force-push` auf `main` oder einem geteilten Branch
+
+## Gefährliche Befehle — immer bestätigen vor der Ausführung
+
+- `git reset --hard` — zerstört uncommittete Änderungen dauerhaft
+- `git clean -f` — löscht nicht verfolgte Dateien dauerhaft
+- `git push --force` — überschreibt die Remote-Historie
+- `git stash drop` — verwirft gespeicherte Änderungen dauerhaft
+
+---
+
+> **Mit uns arbeiten:** Claudient wird von [Uitbreiden](https://uitbreiden.com/) unterstützt — wir bauen KI-Produkte und B2B-Lösungen mit Entwickler-Communities. [uitbreiden.com](https://uitbreiden.com/)

package/rules/common/de/performance.md

@@ -0,0 +1,40 @@
+> 🇩🇪 Dies ist die deutsche Übersetzung. [Englische Version](../performance.md).
+
+# Performance-Regeln
+
+Relevante Abschnitte in die `CLAUDE.md` des Projekts kopieren.
+
+---
+
+## Datenbank
+
+- Niemals Abfragen in Schleifen ausführen — mit `IN (...)` batch-verarbeiten oder einen Join verwenden
+- Abfragen, die unbegrenzte Ergebnisse zurückgeben können, immer paginieren — kein `SELECT *` ohne `LIMIT`
+- Indizes hinzufügen, bevor die Abfrage in der Produktion langsam wird, nicht danach — Abfrage-Pläne während der Entwicklung analysieren
+- Nur die benötigten Spalten auswählen — `SELECT *` ruft ungenutzte Daten ab und verhindert Index-Only-Scans
+- Aggregation auf Datenbankebene verwenden (`COUNT`, `SUM`, `GROUP BY`) — keine Zeilen in den Speicher laden, um sie zu zählen
+
+## API und Netzwerk
+
+- Antworten cachen, die aufwändig zu berechnen sind und sich selten ändern — explizite TTLs setzen
+- Listen-Endpunkte paginieren — maximal N Elemente pro Anfrage mit einem Cursor oder Offset zurückgeben
+- Keine N+1-Abfragen — verwandte Daten mit DataLoader, `include` oder einem Join batchen
+- Synchrone Aufrufe zu externen Diensten in Request-Handlern vermeiden — Queues für nicht-kritische Arbeit verwenden
+- Timeouts für alle externen HTTP-Aufrufe setzen — niemals eine langsame Abhängigkeit den Server hängen lassen
+
+## Speicher
+
+- Keine großen Datensätze in den Speicher laden, um sie zu verarbeiten — streamen oder paginieren
+- Referenzen freigeben, wenn fertig — versehentliche Closures vermeiden, die Garbage Collection verhindern
+- Generatoren/Iteratoren für große Sequenzen verwenden, anstatt vollständige Listen im Speicher aufzubauen
+
+## Messung
+
+- Vor der Optimierung profilieren — niemals raten, wo der Engpass liegt
+- Unter produktionsähnlichen Bedingungen messen — lokale Benchmarks sind irreführend
+- Baseline vor Änderungen festlegen — ohne Baseline kann keine Verbesserung bestätigt werden
+- Performance-Tests gehören in CI — Regressionen, die Code-Review bestehen, aber das Performance-Budget verletzen, müssen automatisch erkannt werden
+
+---
+
+> **Mit uns arbeiten:** Claudient wird von [Uitbreiden](https://uitbreiden.com/) unterstützt — wir bauen KI-Produkte und B2B-Lösungen mit Entwickler-Communities. [uitbreiden.com](https://uitbreiden.com/)

package/rules/common/de/security.md

@@ -0,0 +1,45 @@
+> 🇩🇪 Dies ist die deutsche Übersetzung. [Englische Version](../security.md).
+
+# Sicherheitsregeln
+
+Relevante Abschnitte in die `CLAUDE.md` des Projekts kopieren.
+
+---
+
+## Secrets
+
+- Niemals Secrets im Quellcode — nicht in Kommentaren, nicht in Testdateien, nicht in Beispielkonfigurationen
+- Niemals Secrets protokollieren — prüfen, dass Logger-Aufrufe keine `password`-, `token`-, `key`-, `secret`- oder `credential`-Felder enthalten
+- Umgebungsvariablen für alle Secrets verwenden; beim Start lesen und ihre Existenz validieren
+- Secrets rotieren, die versehentlich committet wurden — jeden committeten Secret als kompromittiert behandeln
+
+## Eingabevalidierung
+
+- Alle Eingaben an Systemgrenzen validieren: API-Parameter, Query-Strings, Request-Bodies, Datei-Uploads, Umgebungsvariablen
+- Typ, Format, Länge und Bereich validieren — nicht nur Vorhandensein
+- Eine Allowlist (gültige Werte) anstelle einer Denylist (blockierte Werte) verwenden, wo möglich
+- Niemals Benutzereingaben direkt in SQL-Abfragen, Shell-Befehlen, Dateipfaden oder HTML ohne Bereinigung verwenden
+
+## Authentifizierung und Autorisierung
+
+- Authentifizierung bei jeder Anfrage prüfen, die sie erfordert — niemals auf Frontend-Routing verlassen
+- Autorisierung (Benutzer kann DIESE Aktion durchführen) separat von Authentifizierung (Benutzer ist angemeldet) prüfen
+- Autorisierungsprüfungen müssen den authentifizierten Benutzer aus dem Anfrage-Kontext referenzieren — niemals aus einem Query-Parameter
+- Token-Ablauf muss serverseitig erzwungen werden — niemals client-seitig bereitgestellte Token-Zeitstempel vertrauen
+
+## Datenbanken
+
+- Parametrisierte Abfragen oder ORM verwenden — niemals SQL durch String-Verkettung erstellen
+- Datenbankbenutzer müssen Mindestberechtigungen haben — App-Benutzer sollte keinen DDL-Zugriff haben
+- Interne Datenbankfehler niemals an Clients weitergeben — serverseitig protokollieren, generischen Fehler an den Client zurückgeben
+
+## Abhängigkeiten
+
+- Abhängigkeitsversionen pinnen — niemals `*` oder `latest` in der Produktion verwenden
+- `npm audit` / `pip-audit` / `govulncheck` vor jedem Release ausführen
+- Nicht verwendete Abhängigkeiten entfernen — jede Abhängigkeit ist eine potenzielle Angriffsfläche
+- Quellcode neuer Abhängigkeiten prüfen, bevor sie hinzugefügt werden
+
+---
+
+> **Mit uns arbeiten:** Claudient wird von [Uitbreiden](https://uitbreiden.com/) unterstützt — wir bauen KI-Produkte und B2B-Lösungen mit Entwickler-Communities. [uitbreiden.com](https://uitbreiden.com/)

package/rules/common/de/testing.md

@@ -0,0 +1,45 @@
+> 🇩🇪 Dies ist die deutsche Übersetzung. [Englische Version](../testing.md).
+
+# Test-Regeln
+
+Relevante Abschnitte in die `CLAUDE.md` des Projekts kopieren.
+
+---
+
+## Was testen
+
+- Verhalten über öffentliche APIs testen — nicht interne Implementierungsdetails
+- Tests müssen Refactoring überleben: wenn das Umbenennen einer privaten Funktion Tests bricht, sind die Tests falsch
+- Edge Cases testen: null/leere Eingaben, Grenzwerte, Fehlerpfade
+- Framework-Code oder Sprach-Builtins nicht testen
+
+## Test-Struktur
+
+- Eine logische Assertion pro Test — wenn ein Test mehrere nicht zusammenhängende Dinge prüft, aufteilen
+- Testnamen beschreiben WAS das System tut, nicht WIE: `"returns 404 when user not found"` nicht `"test findUser"`
+- Arrange → Act → Assert — je ein Block, kein Durchmischen
+- Keine Bedingungslogik in Tests — wenn ein `if` benötigt wird, zwei Tests schreiben
+
+## Mocking
+
+- Interne Module nicht mocken — nur an Systemgrenzen mocken (externe APIs, Datenbanken, Dateisystem)
+- Die Klasse/das Modul, das getestet wird, niemals mocken
+- Integrationstests müssen die echte Datenbank treffen — Test-Datenbank verwenden, keine Mocks
+- Wenn ein Unit-Test 5+ Mocks benötigt, ist der Code wahrscheinlich nicht gut strukturiert
+
+## Abdeckung
+
+- Abdeckung ist ein Minimum, kein Ziel — 80% Abdeckung mit schlechten Tests ist schlechter als 60% mit guten Tests
+- Jedes neue Feature benötigt mindestens einen Happy-Path-Test und einen Error-Path-Test
+- Jeder Bugfix benötigt einen Regressionstest, der den Bug erkannt hätte
+
+## Testdaten
+
+- Factories oder Fixtures verwenden — niemals User-IDs, E-Mails oder UUIDs in Tests hardcoden
+- Tests müssen isoliert sein — kein gemeinsamer veränderbarer State zwischen Tests
+- Tests müssen deterministisch sein — keine Zufallsdaten, keine zeitabhängigen Assertions ohne Mockierung der Uhr
+- Nach jedem Test bereinigen — Tabellen abschneiden, Mocks zurücksetzen, erstellte Dateien löschen
+
+---
+
+> **Mit uns arbeiten:** Claudient wird von [Uitbreiden](https://uitbreiden.com/) unterstützt — wir bauen KI-Produkte und B2B-Lösungen mit Entwickler-Communities. [uitbreiden.com](https://uitbreiden.com/)

package/rules/common/es/coding-style.md

@@ -0,0 +1,47 @@
+> 🇪🇸 Esta es la traducción en español. [Versión en inglés](../coding-style.md).
+
+# Reglas de Estilo de Código
+
+Copia las secciones relevantes en el `CLAUDE.md` de tu proyecto.
+
+---
+
+## Nomenclatura
+
+- Variables y funciones: `camelCase` (JS/TS), `snake_case` (Python, Go, Rust)
+- Clases y tipos: `PascalCase` en todos los lenguajes
+- Constantes: `SCREAMING_SNAKE_CASE` solo para constantes verdaderas que nunca cambian
+- Variables booleanas: prefijo con `is`, `has`, `can`, `should` — `isActive`, `hasPermission`
+- No abrevies nombres a menos que la abreviatura sea universalmente conocida (`id`, `url`, `db`, `ctx`)
+
+## Funciones
+
+- Una responsabilidad por función — si necesitas "y" en la descripción, divídela
+- Máximo 40 líneas por función; si es más larga, extrae sub-funciones
+- Sin parámetros booleanos — usa un objeto de opciones o dos funciones separadas
+- Retorno anticipado para cláusulas de guarda — no anides el camino feliz dentro de condicionales
+
+## Comentarios
+
+- No escribas comentarios a menos que el POR QUÉ no sea obvio
+- Nunca escribas comentarios que describan lo que hace el código (el código ya lo hace)
+- Escribe un comentario cuando: hay una restricción oculta, una solución para un bug específico, o comportamiento que sorprendería al lector
+- Nunca escribas comentarios TODO — crea un issue rastreado en su lugar
+
+## Manejo de errores
+
+- Nunca ignores errores silenciosamente (`catch (e) {}` siempre está mal)
+- Siempre maneja los errores en el límite donde puedas tomar acción
+- Propaga los errores hacia arriba con contexto — envuelve con el ID o nombre de operación relevante
+- No uses `console.error` en código de producción — usa el logger del proyecto
+
+## Organización de archivos
+
+- Una exportación primaria por archivo
+- Los nombres de archivo coinciden con su exportación primaria: `UserService.ts` exporta `UserService`
+- Sin archivos barrel (`index.ts` re-exportaciones) — importa directamente desde el archivo fuente
+- Agrupa las importaciones: paquetes externos primero, luego módulos internos, luego importaciones relativas
+
+---
+
+> **Trabaja con nosotros:** Claudient está respaldado por [Uitbreiden](https://uitbreiden.com/) — construimos productos de IA y soluciones B2B con comunidades de desarrolladores. [uitbreiden.com](https://uitbreiden.com/)

package/rules/common/es/git.md

@@ -0,0 +1,48 @@
+> 🇪🇸 Esta es la traducción en español. [Versión en inglés](../git.md).
+
+# Reglas de Git
+
+Copia las secciones relevantes en el `CLAUDE.md` de tu proyecto.
+
+---
+
+## Mensajes de commit
+
+- Formato: `tipo: descripción corta` (modo imperativo, ≤ 72 caracteres)
+- Tipos: `feat`, `fix`, `docs`, `refactor`, `test`, `chore`, `perf`
+- Ejemplos: `feat: add webhook signature verification`, `fix: handle null user in auth middleware`
+- Sin mensajes genéricos: "update", "changes", "fix bug", "wip" no son aceptables
+- Cuerpo (opcional): explica el POR QUÉ, no el qué. El diff muestra el qué.
+
+## Ramas
+
+- Ramas de funcionalidades: `feat/descripción-corta`
+- Correcciones de bugs: `fix/descripción-corta`
+- Nunca hagas commit directamente en `main` o `master`
+- Elimina las ramas después de hacer merge
+
+## Qué nunca hacer commit
+
+- Archivos `.env` o cualquier archivo que contenga secretos
+- `node_modules/`, `__pycache__/`, artefactos de build
+- Configuraciones personales del editor (`.idea/`, `.vscode/settings.json`)
+- Archivos > 10MB (usa git-lfs o almacenamiento externo)
+- Archivos generados que pueden reproducirse desde el código fuente
+
+## Antes de hacer push
+
+- Ejecuta las pruebas localmente — nunca hagas push en rojo
+- Revisa tu propio diff antes de cada push: `git diff origin/main...HEAD`
+- Aplasta los commits WIP antes de hacer push a una rama compartida
+- Nunca hagas force-push en `main` ni en ninguna rama compartida
+
+## Comandos peligrosos — siempre confirmar antes de ejecutar
+
+- `git reset --hard` — destruye los cambios sin commit permanentemente
+- `git clean -f` — elimina archivos sin rastrear permanentemente
+- `git push --force` — reescribe el historial remoto
+- `git stash drop` — descarta permanentemente los cambios guardados en stash
+
+---
+
+> **Trabaja con nosotros:** Claudient está respaldado por [Uitbreiden](https://uitbreiden.com/) — construimos productos de IA y soluciones B2B con comunidades de desarrolladores. [uitbreiden.com](https://uitbreiden.com/)

package/rules/common/es/performance.md

@@ -0,0 +1,40 @@
+> 🇪🇸 Esta es la traducción en español. [Versión en inglés](../performance.md).
+
+# Reglas de Rendimiento
+
+Copia las secciones relevantes en el `CLAUDE.md` de tu proyecto.
+
+---
+
+## Base de datos
+
+- Nunca ejecutes consultas dentro de bucles — agrupa con `IN (...)` o usa un join
+- Siempre pagina las consultas que pueden devolver resultados ilimitados — sin `SELECT *` sin `LIMIT`
+- Agrega índices antes de que la consulta sea lenta en producción, no después — analiza los planes de consulta durante el desarrollo
+- Selecciona solo las columnas que necesitas — `SELECT *` obtiene datos no usados e impide escaneos solo de índice
+- Usa agregación a nivel de base de datos (`COUNT`, `SUM`, `GROUP BY`) — no cargues filas en memoria para contarlas
+
+## API y red
+
+- Cachea las respuestas que son costosas de calcular y cambian poco — establece TTLs explícitos
+- Pagina los endpoints de lista — devuelve un máximo de N elementos por solicitud con un cursor u offset
+- No hagas consultas N+1 — agrupa los datos relacionados con DataLoader, `include` o un join
+- Evita llamadas síncronas a servicios externos en los manejadores de solicitudes — usa colas para el trabajo no crítico
+- Establece timeouts en todas las llamadas HTTP externas — nunca dejes que una dependencia lenta bloquee tu servidor
+
+## Memoria
+
+- No cargues grandes conjuntos de datos en memoria para procesarlos — usa streaming o paginación
+- Libera las referencias cuando termines — evita closures accidentales que impidan la recolección de basura
+- Usa generadores/iteradores para secuencias grandes en lugar de construir listas completas en memoria
+
+## Medición
+
+- Perfila antes de optimizar — nunca adivines dónde está el cuello de botella
+- Mide en condiciones similares a producción — los benchmarks locales son engañosos
+- Establece una línea base antes de hacer cambios — sin una línea base, no puedes confirmar la mejora
+- Las pruebas de rendimiento pertenecen al CI — las regresiones que pasan la revisión de código pero fallan el presupuesto de rendimiento deben detectarse automáticamente
+
+---
+
+> **Trabaja con nosotros:** Claudient está respaldado por [Uitbreiden](https://uitbreiden.com/) — construimos productos de IA y soluciones B2B con comunidades de desarrolladores. [uitbreiden.com](https://uitbreiden.com/)

package/rules/common/es/security.md

@@ -0,0 +1,45 @@
+> 🇪🇸 Esta es la traducción en español. [Versión en inglés](../security.md).
+
+# Reglas de Seguridad
+
+Copia las secciones relevantes en el `CLAUDE.md` de tu proyecto.
+
+---
+
+## Secretos
+
+- Nunca pongas secretos en el código fuente — ni en comentarios, ni en archivos de test, ni en configs de ejemplo
+- Nunca registres secretos — verifica que las llamadas al logger no incluyan campos `password`, `token`, `key`, `secret` o `credential`
+- Usa variables de entorno para todos los secretos; léelos al inicio, valida que existen
+- Rota los secretos que hayan sido accidentalmente comprometidos — trata cualquier secreto comprometido como comprometido
+
+## Validación de entradas
+
+- Valida todas las entradas en los límites del sistema: parámetros de API, query strings, cuerpos de solicitudes, cargas de archivos, variables de entorno
+- Valida el tipo, formato, longitud y rango — no solo la presencia
+- Usa una lista de permitidos (valores válidos) no una lista de bloqueados (valores bloqueados) donde sea posible
+- Nunca uses la entrada del usuario directamente en consultas SQL, comandos de shell, rutas de archivo o HTML sin saneamiento
+
+## Autenticación y autorización
+
+- Verifica la autenticación en cada solicitud que lo requiera — nunca confíes en el enrutamiento del frontend
+- Verifica la autorización (el usuario puede hacer ESTA acción) separadamente de la autenticación (el usuario ha iniciado sesión)
+- Las verificaciones de autorización deben referenciar al usuario autenticado desde el contexto de la solicitud — nunca desde un parámetro de consulta
+- La expiración del token debe ser forzada en el servidor — nunca confíes en las marcas de tiempo de token proporcionadas por el cliente
+
+## Bases de datos
+
+- Usa consultas parametrizadas u ORM — nunca concatenes cadenas SQL
+- Los usuarios de la base de datos deben tener los permisos mínimos requeridos — el usuario de la app no debe tener acceso DDL
+- Nunca expongas errores internos de la base de datos a los clientes — registra en el servidor, devuelve un error genérico al cliente
+
+## Dependencias
+
+- Fija las versiones de las dependencias — nunca uses `*` o `latest` en producción
+- Ejecuta `npm audit` / `pip-audit` / `govulncheck` antes de cada lanzamiento
+- Elimina las dependencias no utilizadas — cada dependencia es una superficie de ataque potencial
+- Revisa el código fuente de las nuevas dependencias antes de agregarlas
+
+---
+
+> **Trabaja con nosotros:** Claudient está respaldado por [Uitbreiden](https://uitbreiden.com/) — construimos productos de IA y soluciones B2B con comunidades de desarrolladores. [uitbreiden.com](https://uitbreiden.com/)

package/rules/common/es/testing.md

@@ -0,0 +1,45 @@
+> 🇪🇸 Esta es la traducción en español. [Versión en inglés](../testing.md).
+
+# Reglas de Testing
+
+Copia las secciones relevantes en el `CLAUDE.md` de tu proyecto.
+
+---
+
+## Qué probar
+
+- Prueba el comportamiento a través de APIs públicas — no los detalles de implementación interna
+- Las pruebas deben sobrevivir al refactoring: si renombrar una función privada rompe las pruebas, las pruebas están mal
+- Prueba los casos límite: entradas nulas/vacías, valores de frontera, rutas de error
+- No pruebes el código del framework ni los builtins del lenguaje
+
+## Estructura de las pruebas
+
+- Una aserción lógica por prueba — si una prueba verifica múltiples cosas no relacionadas, divídela
+- Los nombres de las pruebas describen LO QUE hace el sistema, no CÓMO: `"returns 404 when user not found"` no `"test findUser"`
+- Preparar → Actuar → Asegurar — un bloque cada uno, sin entrelazar
+- Sin lógica condicional en las pruebas — si necesitas un `if`, escribe dos pruebas
+
+## Mocking
+
+- No hagas mock de módulos internos — solo haz mock en los límites del sistema (APIs externas, bases de datos, sistema de archivos)
+- Nunca hagas mock de la clase/módulo bajo prueba
+- Las pruebas de integración deben usar la base de datos real — usa una base de datos de prueba, no mocks
+- Si una prueba unitaria requiere 5+ mocks, el código probablemente no está bien estructurado
+
+## Cobertura
+
+- La cobertura es un suelo, no un objetivo — 80% de cobertura con malas pruebas es peor que 60% con buenas pruebas
+- Cada nueva funcionalidad necesita al menos una prueba del camino feliz y una del camino de error
+- Cada corrección de bug necesita una prueba de regresión que habría detectado el bug
+
+## Datos de prueba
+
+- Usa factories o fixtures — nunca hardcodees IDs de usuario, emails o UUIDs en las pruebas
+- Las pruebas deben estar aisladas — sin estado mutable compartido entre pruebas
+- Las pruebas deben ser deterministas — sin datos aleatorios, sin aserciones dependientes del tiempo sin mockear el reloj
+- Limpia después de cada prueba — trunca las tablas, reinicia los mocks, elimina los archivos creados
+
+---
+
+> **Trabaja con nosotros:** Claudient está respaldado por [Uitbreiden](https://uitbreiden.com/) — construimos productos de IA y soluciones B2B con comunidades de desarrolladores. [uitbreiden.com](https://uitbreiden.com/)

package/rules/common/fr/coding-style.md

@@ -0,0 +1,47 @@
+> 🇫🇷 This is the French translation. [English version](../coding-style.md).
+
+# Règles de Style de Code
+
+Copiez les sections pertinentes dans le `CLAUDE.md` de votre projet.
+
+---
+
+## Nommage
+
+- Variables et fonctions : `camelCase` (JS/TS), `snake_case` (Python, Go, Rust)
+- Classes et types : `PascalCase` dans tous les langages
+- Constantes : `SCREAMING_SNAKE_CASE` uniquement pour les vraies constantes qui ne changent jamais
+- Variables booléennes : préfixer avec `is`, `has`, `can`, `should` — `isActive`, `hasPermission`
+- Ne pas abréger les noms sauf si l'abréviation est universellement connue (`id`, `url`, `db`, `ctx`)
+
+## Fonctions
+
+- Une responsabilité par fonction — si vous avez besoin de "et" dans la description, séparez-la
+- Maximum 40 lignes par fonction ; si plus long, extraire des sous-fonctions
+- Pas de paramètres booléens — utiliser un objet d'options ou deux fonctions séparées
+- Retourner tôt pour les clauses de garde — ne pas imbriquer le chemin heureux dans des conditionnels
+
+## Commentaires
+
+- N'écrire aucun commentaire sauf si le POURQUOI n'est pas évident
+- Ne jamais écrire des commentaires qui décrivent ce que fait le code (le code le fait déjà)
+- Écrire un commentaire quand : il y a une contrainte cachée, un contournement pour un bug spécifique, ou un comportement qui surprendrait un lecteur
+- Ne jamais écrire des commentaires TODO — créer un problème suivi à la place
+
+## Gestion des erreurs
+
+- Ne jamais avaler silencieusement les erreurs (`catch (e) {}` est toujours faux)
+- Toujours gérer les erreurs à la limite où vous pouvez agir
+- Propager les erreurs vers le haut avec du contexte — envelopper avec l'ID ou le nom d'opération pertinent
+- Ne pas utiliser `console.error` dans le code de production — utiliser le logger du projet
+
+## Organisation des fichiers
+
+- Un export primaire par fichier
+- Les noms de fichiers correspondent à leur export primaire : `UserService.ts` exporte `UserService`
+- Pas de fichiers barrel (`index.ts` qui réexporte) — importer directement depuis le fichier source
+- Grouper les imports : packages externes d'abord, puis modules internes, puis imports relatifs
+
+---
+
+> **Travaillez avec nous :** Claudient est soutenu par [Uitbreiden](https://uitbreiden.com/) — nous construisons des produits IA et des solutions B2B avec des communautés de développeurs. [uitbreiden.com](https://uitbreiden.com/)

package/rules/common/fr/git.md

@@ -0,0 +1,48 @@
+> 🇫🇷 This is the French translation. [English version](../git.md).
+
+# Règles Git
+
+Copiez les sections pertinentes dans le `CLAUDE.md` de votre projet.
+
+---
+
+## Messages de commit
+
+- Format : `type: courte description` (mode impératif, ≤ 72 caractères)
+- Types : `feat`, `fix`, `docs`, `refactor`, `test`, `chore`, `perf`
+- Exemples : `feat: add webhook signature verification`, `fix: handle null user in auth middleware`
+- Pas de messages génériques : "update", "changes", "fix bug", "wip" ne sont pas acceptables
+- Corps (optionnel) : expliquer le POURQUOI, pas le quoi. Le diff montre le quoi.
+
+## Branches
+
+- Branches de fonctionnalités : `feat/short-description`
+- Corrections de bugs : `fix/short-description`
+- Ne jamais committer directement sur `main` ou `master`
+- Supprimer les branches après fusion
+
+## Ce qu'il ne faut jamais committer
+
+- Fichiers `.env` ou tout fichier contenant des secrets
+- `node_modules/`, `__pycache__/`, artefacts de build
+- Paramètres d'éditeur personnels (`.idea/`, `.vscode/settings.json`)
+- Fichiers > 10 Mo (utiliser git-lfs ou un stockage externe)
+- Fichiers générés qui peuvent être reproduits depuis la source
+
+## Avant de pousser
+
+- Exécuter les tests localement — ne jamais pousser en rouge
+- Relire votre propre diff avant chaque push : `git diff origin/main...HEAD`
+- Squasher les commits WIP avant de pousser sur une branche partagée
+- Ne jamais force-pousser sur `main` ou toute branche partagée
+
+## Commandes dangereuses — toujours confirmer avant d'exécuter
+
+- `git reset --hard` — détruit les modifications non committées de façon permanente
+- `git clean -f` — supprime les fichiers non suivis de façon permanente
+- `git push --force` — réécrit l'historique distant
+- `git stash drop` — supprime définitivement les modifications mises en attente
+
+---
+
+> **Travaillez avec nous :** Claudient est soutenu par [Uitbreiden](https://uitbreiden.com/) — nous construisons des produits IA et des solutions B2B avec des communautés de développeurs. [uitbreiden.com](https://uitbreiden.com/)

package/rules/common/fr/performance.md

@@ -0,0 +1,40 @@
+> 🇫🇷 This is the French translation. [English version](../performance.md).
+
+# Règles de Performance
+
+Copiez les sections pertinentes dans le `CLAUDE.md` de votre projet.
+
+---
+
+## Base de données
+
+- Ne jamais exécuter des requêtes dans des boucles — regrouper avec `IN (...)` ou utiliser une jointure
+- Toujours paginer les requêtes qui peuvent retourner des résultats non bornés — pas de `SELECT *` sans `LIMIT`
+- Ajouter des index avant que la requête soit lente en production, pas après — analyser les plans de requête pendant le développement
+- Sélectionner uniquement les colonnes dont vous avez besoin — `SELECT *` récupère des données inutilisées et empêche les scans index-only
+- Utiliser l'agrégation au niveau base de données (`COUNT`, `SUM`, `GROUP BY`) — ne pas charger des lignes en mémoire pour les compter
+
+## API et réseau
+
+- Mettre en cache les réponses coûteuses à calculer et qui changent peu — définir des TTLs explicites
+- Paginer les endpoints de liste — retourner un maximum de N éléments par requête avec un curseur ou un offset
+- Ne pas faire de requêtes N+1 — regrouper les données liées avec DataLoader, `include`, ou une jointure
+- Éviter les appels synchrones vers des services externes dans les gestionnaires de requêtes — utiliser des queues pour les tâches non critiques
+- Définir des timeouts sur tous les appels HTTP externes — ne jamais laisser une dépendance lente bloquer votre serveur
+
+## Mémoire
+
+- Ne pas charger de grands jeux de données en mémoire pour les traiter — streamer ou paginer
+- Libérer les références quand c'est terminé — éviter les fermetures accidentelles qui empêchent le garbage collection
+- Utiliser des générateurs/itérateurs pour les grandes séquences plutôt que de construire des listes complètes en mémoire
+
+## Mesure
+
+- Profiler avant d'optimiser — ne jamais deviner où est le goulot d'étranglement
+- Mesurer dans des conditions similaires à la production — les benchmarks locaux sont trompeurs
+- Établir une baseline avant de faire des changements — sans baseline, vous ne pouvez pas confirmer l'amélioration
+- Les tests de performance appartiennent à la CI — une régression qui passe la revue de code mais échoue le budget de performance doit être détectée automatiquement
+
+---
+
+> **Travaillez avec nous :** Claudient est soutenu par [Uitbreiden](https://uitbreiden.com/) — nous construisons des produits IA et des solutions B2B avec des communautés de développeurs. [uitbreiden.com](https://uitbreiden.com/)