claudient 0.1.0

package/rules/common/fr/security.md

@@ -0,0 +1,45 @@
+> 🇫🇷 This is the French translation. [English version](../security.md).
+
+# Règles de Sécurité
+
+Copiez les sections pertinentes dans le `CLAUDE.md` de votre projet.
+
+---
+
+## Secrets
+
+- Ne jamais mettre des secrets dans le code source — ni dans les commentaires, ni dans les fichiers de test, ni dans les configurations d'exemple
+- Ne jamais logger des secrets — vérifier que les appels de logger n'incluent pas des champs `password`, `token`, `key`, `secret`, ou `credential`
+- Utiliser des variables d'environnement pour tous les secrets ; les lire au démarrage, valider leur existence
+- Faire tourner les secrets qui ont été accidentellement committés — traiter tout secret commité comme compromis
+
+## Validation des entrées
+
+- Valider toutes les entrées aux frontières du système : paramètres API, chaînes de requête, corps de requête, uploads de fichiers, variables d'environnement
+- Valider le type, le format, la longueur et la plage — pas seulement la présence
+- Utiliser une liste d'autorisation (valeurs valides) plutôt qu'une liste de refus (valeurs bloquées) quand c'est possible
+- Ne jamais utiliser les entrées utilisateur directement dans des requêtes SQL, des commandes shell, des chemins de fichiers, ou du HTML sans assainissement
+
+## Authentification et autorisation
+
+- Vérifier l'authentification sur chaque requête qui le requiert — ne jamais se fier au routage frontend
+- Vérifier l'autorisation (l'utilisateur peut faire CETTE action) séparément de l'authentification (l'utilisateur est connecté)
+- Les vérifications d'autorisation doivent référencer l'utilisateur authentifié depuis le contexte de requête — jamais depuis un paramètre de requête
+- L'expiration des tokens doit être appliquée côté serveur — ne jamais faire confiance aux timestamps de tokens fournis par le client
+
+## Bases de données
+
+- Utiliser des requêtes paramétrées ou un ORM — ne jamais concaténer du SQL sous forme de chaîne
+- Les utilisateurs de base de données doivent avoir les permissions minimales requises — l'utilisateur de l'app ne doit pas avoir accès au DDL
+- Ne jamais exposer les erreurs internes de la base de données aux clients — logger côté serveur, retourner une erreur générique au client
+
+## Dépendances
+
+- Épingler les versions des dépendances — ne jamais utiliser `*` ou `latest` en production
+- Exécuter `npm audit` / `pip-audit` / `govulncheck` avant chaque release
+- Supprimer les dépendances inutilisées — chaque dépendance est une surface d'attaque potentielle
+- Vérifier la source des nouvelles dépendances avant de les ajouter
+
+---
+
+> **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/testing.md

@@ -0,0 +1,45 @@
+> 🇫🇷 This is the French translation. [English version](../testing.md).
+
+# Règles de Tests
+
+Copiez les sections pertinentes dans le `CLAUDE.md` de votre projet.
+
+---
+
+## Ce qu'il faut tester
+
+- Tester le comportement via les APIs publiques — pas les détails d'implémentation internes
+- Les tests doivent survivre au refactoring : si renommer une fonction privée casse les tests, les tests sont incorrects
+- Tester les cas limites : entrées null/vides, valeurs aux bornes, chemins d'erreur
+- Ne pas tester le code du framework ou les builtins du langage
+
+## Structure des tests
+
+- Une assertion logique par test — si un test vérifie plusieurs choses non liées, le diviser
+- Les noms de tests décrivent CE QUE fait le système, pas COMMENT : `"returns 404 when user not found"` pas `"test findUser"`
+- Arrange → Act → Assert — un bloc chacun, sans interleaving
+- Pas de logique conditionnelle dans les tests — si vous avez besoin d'un `if`, écrire deux tests
+
+## Mocking
+
+- Ne pas mocker les modules internes — mocker uniquement aux frontières du système (APIs externes, bases de données, système de fichiers)
+- Ne jamais mocker la classe/module en cours de test
+- Les tests d'intégration doivent toucher la vraie base de données — utiliser une base de données de test, pas des mocks
+- Si un test unitaire nécessite 5+ mocks, le code n'est probablement pas bien structuré
+
+## Couverture
+
+- La couverture est un plancher, pas une cible — 80% de couverture avec de mauvais tests est pire que 60% avec de bons tests
+- Chaque nouvelle fonctionnalité nécessite au moins un test de chemin heureux et un test de chemin d'erreur
+- Chaque correction de bug nécessite un test de régression qui aurait détecté le bug
+
+## Données de test
+
+- Utiliser des factories ou des fixtures — ne jamais coder en dur des IDs d'utilisateurs, des emails ou des UUIDs dans les tests
+- Les tests doivent être isolés — pas d'état mutable partagé entre les tests
+- Les tests doivent être déterministes — pas de données aléatoires, pas d'assertions dépendantes du temps sans mocker l'horloge
+- Nettoyer après chaque test — tronquer les tables, réinitialiser les mocks, supprimer les fichiers créés
+
+---
+
+> **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/git.md

@@ -0,0 +1,46 @@
+# Git Rules
+
+Copy the relevant sections into your project's `CLAUDE.md`.
+
+---
+
+## Commit messages
+
+- Format: `type: short description` (imperative mood, ≤ 72 chars)
+- Types: `feat`, `fix`, `docs`, `refactor`, `test`, `chore`, `perf`
+- Examples: `feat: add webhook signature verification`, `fix: handle null user in auth middleware`
+- No generic messages: "update", "changes", "fix bug", "wip" are not acceptable
+- Body (optional): explain WHY, not what. The diff shows what.
+
+## Branches
+
+- Feature branches: `feat/short-description`
+- Bug fixes: `fix/short-description`
+- Never commit directly to `main` or `master`
+- Delete branches after merge
+
+## What never to commit
+
+- `.env` files or any file containing secrets
+- `node_modules/`, `__pycache__/`, build artifacts
+- Personal editor settings (`.idea/`, `.vscode/settings.json`)
+- Files > 10MB (use git-lfs or external storage)
+- Generated files that can be reproduced from source
+
+## Before pushing
+
+- Run tests locally — never push red
+- Review your own diff before every push: `git diff origin/main...HEAD`
+- Squash WIP commits before pushing to a shared branch
+- Never force-push to `main` or any shared branch
+
+## Dangerous commands — always confirm before running
+
+- `git reset --hard` — destroys uncommitted changes permanently
+- `git clean -f` — deletes untracked files permanently
+- `git push --force` — rewrites remote history
+- `git stash drop` — permanently discards stashed changes
+
+---
+
+> **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/nl/coding-style.md

@@ -0,0 +1,47 @@
+> 🇳🇱 Dit is de Nederlandse vertaling. [Engelse versie](../coding-style.md).
+
+# Codeerstijlregels
+
+Kopieer de relevante secties naar de `CLAUDE.md` van je project.
+
+---
+
+## Naamgeving
+
+- Variabelen en functies: `camelCase` (JS/TS), `snake_case` (Python, Go, Rust)
+- Klassen en typen: `PascalCase` in alle talen
+- Constanten: `SCREAMING_SNAKE_CASE` alleen voor echte constanten die nooit veranderen
+- Booleaanse variabelen: voorvoegsel met `is`, `has`, `can`, `should` — `isActive`, `hasPermission`
+- Verkort namen niet tenzij de afkorting universeel bekend is (`id`, `url`, `db`, `ctx`)
+
+## Functies
+
+- Één verantwoordelijkheid per functie — als je "en" nodig hebt in de beschrijving, splits dan
+- Maximaal 40 regels per functie; als langer, extraheer subfuncties
+- Geen booleaanse parameters — gebruik een opties-object of twee afzonderlijke functies
+- Keer vroeg terug voor bewakende clausules — nest het gelukkige pad niet in conditionals
+
+## Opmerkingen
+
+- Schrijf geen opmerkingen tenzij het WAAROM niet vanzelfsprekend is
+- Schrijf nooit opmerkingen die beschrijven wat de code doet (de code doet dat al)
+- Schrijf een opmerking wanneer: er een verborgen beperking is, een workaround voor een specifieke bug, of gedrag dat een lezer zou verrassen
+- Schrijf nooit TODO-opmerkingen — maak in plaats daarvan een bijgehouden issue aan
+
+## Foutafhandeling
+
+- Slik fouten nooit stilletjes in (`catch (e) {}` is altijd fout)
+- Behandel fouten altijd op de grens waar je actie kunt ondernemen
+- Geef fouten naar boven door met context — wikkel in met de relevante ID of operatienaam
+- Gebruik geen `console.error` in productiecode — gebruik de logger van het project
+
+## Bestandsorganisatie
+
+- Één primaire export per bestand
+- Bestandsnamen komen overeen met hun primaire export: `UserService.ts` exporteert `UserService`
+- Geen barrel-bestanden (`index.ts` re-exports) — importeer direct vanuit het bronbestand
+- Groepeer imports: externe packages eerst, dan interne modules, dan relatieve imports
+
+---
+
+> **Werk met ons:** Claudient wordt ondersteund door [Uitbreiden](https://uitbreiden.com/) — we bouwen AI-producten en B2B-oplossingen met ontwikkelaarsgemeenschappen. [uitbreiden.com](https://uitbreiden.com/)

package/rules/common/nl/git.md

@@ -0,0 +1,48 @@
+> 🇳🇱 Dit is de Nederlandse vertaling. [Engelse versie](../git.md).
+
+# Git-regels
+
+Kopieer de relevante secties naar de `CLAUDE.md` van je project.
+
+---
+
+## Commit-berichten
+
+- Formaat: `type: korte beschrijving` (gebiedende wijs, ≤ 72 tekens)
+- Typen: `feat`, `fix`, `docs`, `refactor`, `test`, `chore`, `perf`
+- Voorbeelden: `feat: add webhook signature verification`, `fix: handle null user in auth middleware`
+- Geen generieke berichten: "update", "changes", "fix bug", "wip" zijn niet acceptabel
+- Berichttekst (optioneel): leg uit WAAROM, niet wat. De diff toont wat.
+
+## Branches
+
+- Feature-branches: `feat/korte-beschrijving`
+- Bugfixes: `fix/korte-beschrijving`
+- Commit nooit direct naar `main` of `master`
+- Verwijder branches na merge
+
+## Wat nooit te committen
+
+- `.env`-bestanden of bestanden met secrets
+- `node_modules/`, `__pycache__/`, build-artefacten
+- Persoonlijke editorinstellingen (`.idea/`, `.vscode/settings.json`)
+- Bestanden > 10MB (gebruik git-lfs of externe opslag)
+- Gegenereerde bestanden die kunnen worden gereproduceerd vanuit bron
+
+## Voor pushen
+
+- Voer tests lokaal uit — push nooit rood
+- Bekijk je eigen diff voor elke push: `git diff origin/main...HEAD`
+- Squash WIP-commits voor push naar een gedeelde branch
+- Force-push nooit naar `main` of een gedeelde branch
+
+## Gevaarlijke commando's — bevestig altijd voor uitvoering
+
+- `git reset --hard` — vernietigt niet-gecommitte wijzigingen permanent
+- `git clean -f` — verwijdert niet-gevolgde bestanden permanent
+- `git push --force` — herschrijft de externe geschiedenis
+- `git stash drop` — gooit stashed wijzigingen permanent weg
+
+---
+
+> **Werk met ons:** Claudient wordt ondersteund door [Uitbreiden](https://uitbreiden.com/) — we bouwen AI-producten en B2B-oplossingen met ontwikkelaarsgemeenschappen. [uitbreiden.com](https://uitbreiden.com/)

package/rules/common/nl/performance.md

@@ -0,0 +1,40 @@
+> 🇳🇱 Dit is de Nederlandse vertaling. [Engelse versie](../performance.md).
+
+# Prestatieregels
+
+Kopieer de relevante secties naar de `CLAUDE.md` van je project.
+
+---
+
+## Database
+
+- Voer nooit queries uit binnen lussen — batch met `IN (...)` of gebruik een join
+- Pagineer altijd queries die onbegrensde resultaten kunnen retourneren — geen `SELECT *` zonder een `LIMIT`
+- Voeg indexen toe voordat de query traag is in productie, niet daarna — analyseer queryplannen tijdens ontwikkeling
+- Selecteer alleen de kolommen die je nodig hebt — `SELECT *` haalt ongebruikte data op en voorkomt index-only scans
+- Gebruik aggregatie op databaseniveau (`COUNT`, `SUM`, `GROUP BY`) — laad geen rijen in geheugen om ze te tellen
+
+## API en netwerk
+
+- Cache antwoorden die duur zijn om te berekenen en zelden veranderen — stel expliciete TTL's in
+- Pagineer lijst-endpoints — retourneer maximaal N items per verzoek met een cursor of offset
+- Maak geen N+1-queries — batch gerelateerde data met DataLoader, `include` of een join
+- Vermijd synchrone aanroepen naar externe services in verzoekhandlers — gebruik wachtrijen voor niet-kritiek werk
+- Stel time-outs in op alle externe HTTP-aanroepen — laat nooit een trage afhankelijkheid je server ophangen
+
+## Geheugen
+
+- Laad geen grote datasets in geheugen om ze te verwerken — stream of pagineer
+- Geef referenties vrij wanneer klaar — vermijd onbedoelde closures die garbage collection voorkomen
+- Gebruik generators/iterators voor grote reeksen in plaats van volledige lijsten in geheugen te bouwen
+
+## Meting
+
+- Profileer voor optimalisatie — raad nooit waar de bottleneck zit
+- Meet onder productie-achtige omstandigheden — lokale benchmarks zijn misleidend
+- Stel een baseline vast voor het maken van wijzigingen — zonder baseline kun je verbetering niet bevestigen
+- Prestatietests horen in CI thuis — regressie die codereview passeert maar het prestatiebudget misloopt moet automatisch worden gevangen
+
+---
+
+> **Werk met ons:** Claudient wordt ondersteund door [Uitbreiden](https://uitbreiden.com/) — we bouwen AI-producten en B2B-oplossingen met ontwikkelaarsgemeenschappen. [uitbreiden.com](https://uitbreiden.com/)

package/rules/common/nl/security.md

@@ -0,0 +1,45 @@
+> 🇳🇱 Dit is de Nederlandse vertaling. [Engelse versie](../security.md).
+
+# Beveiligingsregels
+
+Kopieer de relevante secties naar de `CLAUDE.md` van je project.
+
+---
+
+## Secrets
+
+- Zet nooit secrets in broncode — niet in opmerkingen, niet in testbestanden, niet in voorbeeldconfiguraties
+- Log nooit secrets — controleer dat loggingaanroepen geen `password`-, `token`-, `key`-, `secret`- of `credential`-velden bevatten
+- Gebruik omgevingsvariabelen voor alle secrets; lees ze bij opstarten, valideer dat ze bestaan
+- Roteer secrets die per ongeluk zijn gecommit — behandel elk gecommit secret als gecompromitteerd
+
+## Invoervalidatie
+
+- Valideer alle invoer bij systeemgrenzen: API-parameters, querystrings, aanvraagbodies, bestandsuploads, omgevingsvariabelen
+- Valideer type, formaat, lengte en bereik — niet alleen aanwezigheid
+- Gebruik een allowlist (geldige waarden) in plaats van een denylist (geblokkeerde waarden) waar mogelijk
+- Gebruik nooit gebruikersinvoer direct in SQL-queries, shell-commando's, bestandspaden of HTML zonder sanering
+
+## Authenticatie en autorisatie
+
+- Controleer authenticatie op elk verzoek dat dit vereist — vertrouw nooit op frontend-routing
+- Controleer autorisatie (gebruiker kan DEZE actie uitvoeren) apart van authenticatie (gebruiker is ingelogd)
+- Autorisatiecontroles moeten verwijzen naar de geauthenticeerde gebruiker uit de aanvraagcontext — nooit uit een queryparameter
+- Token-vervaldatum moet server-side worden afgedwongen — vertrouw nooit client-verstrekte token-tijdstempels
+
+## Databases
+
+- Gebruik geparametriseerde queries of ORM — concateneer nooit SQL
+- Databasegebruikers moeten minimaal vereiste rechten hebben — app-gebruiker mag geen DDL-toegang hebben
+- Stel nooit interne databasefouten bloot aan clients — log server-side, retourneer generieke fout aan client
+
+## Afhankelijkheden
+
+- Pin afhankelijkheidsversies — gebruik nooit `*` of `latest` in productie
+- Voer `npm audit` / `pip-audit` / `govulncheck` uit voor elke release
+- Verwijder ongebruikte afhankelijkheden — elke afhankelijkheid is een potentieel aanvalsoppervlak
+- Bekijk de bron van nieuwe afhankelijkheden voor ze toe te voegen
+
+---
+
+> **Werk met ons:** Claudient wordt ondersteund door [Uitbreiden](https://uitbreiden.com/) — we bouwen AI-producten en B2B-oplossingen met ontwikkelaarsgemeenschappen. [uitbreiden.com](https://uitbreiden.com/)

package/rules/common/nl/testing.md

@@ -0,0 +1,45 @@
+> 🇳🇱 Dit is de Nederlandse vertaling. [Engelse versie](../testing.md).
+
+# Testregels
+
+Kopieer de relevante secties naar de `CLAUDE.md` van je project.
+
+---
+
+## Wat te testen
+
+- Test gedrag via publieke API's — geen interne implementatiedetails
+- Tests moeten refactoring overleven: als het hernoemen van een private functie tests breekt, zijn de tests fout
+- Test randgevallen: null/lege invoer, grenswaarden, foutpaden
+- Test geen framework-code of taalbuiltins
+
+## Teststructuur
+
+- Één logische bewering per test — als een test meerdere niet-gerelateerde zaken controleert, splits dan
+- Testnamen beschrijven WAT het systeem doet, niet HOE: `"returns 404 when user not found"` niet `"test findUser"`
+- Arrange → Act → Assert — één blok per fase, geen vermenging
+- Geen conditionele logica in tests — als je een `if` nodig hebt, schrijf twee tests
+
+## Mocken
+
+- Mock geen interne modules — mock alleen op systeemgrenzen (externe API's, databases, bestandssysteem)
+- Mock nooit de klasse/module die wordt getest
+- Integratietests moeten de echte database raken — gebruik een testdatabase, geen mocks
+- Als een unit-test 5+ mocks vereist, is de code waarschijnlijk niet goed gestructureerd
+
+## Dekking
+
+- Dekking is een bodem, geen doel — 80% dekking met slechte tests is erger dan 60% met goede tests
+- Elke nieuwe functie heeft minimaal één happy-path test en één foutpad test nodig
+- Elke bugfix heeft een regressietest nodig die de bug had moeten vangen
+
+## Testdata
+
+- Gebruik factories of fixtures — codeer nooit gebruikers-ID's, e-mailadressen of UUID's hard in tests
+- Tests moeten geïsoleerd zijn — geen gedeelde veranderlijke state tussen tests
+- Tests moeten deterministisch zijn — geen willekeurige data, geen tijdsafhankelijke beweringen zonder de klok te mocken
+- Ruim na elke test op — verkort tabellen, reset mocks, verwijder gemaakte bestanden
+
+---
+
+> **Werk met ons:** Claudient wordt ondersteund door [Uitbreiden](https://uitbreiden.com/) — we bouwen AI-producten en B2B-oplossingen met ontwikkelaarsgemeenschappen. [uitbreiden.com](https://uitbreiden.com/)

package/rules/common/performance.md

@@ -0,0 +1,38 @@
+# Performance Rules
+
+Copy the relevant sections into your project's `CLAUDE.md`.
+
+---
+
+## Database
+
+- Never run queries inside loops — batch with `IN (...)` or use a join
+- Always paginate queries that can return unbounded results — no `SELECT *` without a `LIMIT`
+- Add indexes before the query is slow in production, not after — analyze query plans during development
+- Select only the columns you need — `SELECT *` fetches unused data and prevents index-only scans
+- Use database-level aggregation (`COUNT`, `SUM`, `GROUP BY`) — do not load rows into memory to count them
+
+## API and network
+
+- Cache responses that are expensive to compute and change infrequently — set explicit TTLs
+- Paginate list endpoints — return a maximum of N items per request with a cursor or offset
+- Do not make N+1 queries — batch related data with DataLoader, `include`, or a join
+- Avoid synchronous calls to external services in request handlers — use queues for non-critical work
+- Set timeouts on all external HTTP calls — never let a slow dependency hang your server
+
+## Memory
+
+- Do not load large datasets into memory to process them — stream or paginate
+- Release references when done — avoid accidental closures that prevent garbage collection
+- Use generators/iterators for large sequences instead of building full lists in memory
+
+## Measurement
+
+- Profile before optimizing — never guess where the bottleneck is
+- Measure in production-like conditions — local benchmarks are misleading
+- Establish a baseline before making changes — without a baseline, you cannot confirm improvement
+- Performance tests belong in CI — regression that passes code review but fails perf budget must be caught automatically
+
+---
+
+> **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/security.md

@@ -0,0 +1,43 @@
+# Security Rules
+
+Copy the relevant sections into your project's `CLAUDE.md`.
+
+---
+
+## Secrets
+
+- Never put secrets in source code — not in comments, not in test files, not in example configs
+- Never log secrets — check that logger calls don't include `password`, `token`, `key`, `secret`, or `credential` fields
+- Use environment variables for all secrets; read them at startup, validate they exist
+- Rotate secrets that have been accidentally committed — treat any committed secret as compromised
+
+## Input validation
+
+- Validate all input at system boundaries: API params, query strings, request bodies, file uploads, environment variables
+- Validate type, format, length, and range — not just presence
+- Use an allowlist (valid values) not a denylist (blocked values) where possible
+- Never use user input directly in SQL queries, shell commands, file paths, or HTML without sanitization
+
+## Authentication and authorization
+
+- Check authentication on every request that requires it — never rely on frontend routing
+- Check authorization (user can do THIS action) separately from authentication (user is logged in)
+- Authorization checks must reference the authenticated user from the request context — never from a query parameter
+- Token expiry must be enforced server-side — never trust client-provided token timestamps
+
+## Databases
+
+- Use parameterized queries or ORM — never string-concatenate SQL
+- Database users must have minimum required permissions — app user should not have DDL access
+- Never expose internal database errors to clients — log server-side, return generic error to client
+
+## Dependencies
+
+- Pin dependency versions — never use `*` or `latest` in production
+- Run `npm audit` / `pip-audit` / `govulncheck` before every release
+- Remove unused dependencies — every dependency is a potential attack surface
+- Review the source of new dependencies before adding them
+
+---
+
+> **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/testing.md

@@ -0,0 +1,43 @@
+# Testing Rules
+
+Copy the relevant sections into your project's `CLAUDE.md`.
+
+---
+
+## What to test
+
+- Test behavior through public APIs — not internal implementation details
+- Tests must survive refactoring: if renaming a private function breaks tests, the tests are wrong
+- Test edge cases: null/empty inputs, boundary values, error paths
+- Do not test framework code or language builtins
+
+## Test structure
+
+- One logical assertion per test — if a test checks multiple unrelated things, split it
+- Test names describe WHAT the system does, not HOW: `"returns 404 when user not found"` not `"test findUser"`
+- Arrange → Act → Assert — one block each, no interleaving
+- No conditional logic in tests — if you need an `if`, write two tests
+
+## Mocking
+
+- Do not mock internal modules — mock only at system boundaries (external APIs, databases, file system)
+- Never mock the class/module under test
+- Integration tests must hit the real database — use a test database, not mocks
+- If a unit test requires 5+ mocks, the code is probably not well-structured
+
+## Coverage
+
+- Coverage is a floor, not a target — 80% coverage with bad tests is worse than 60% with good tests
+- Every new feature needs at least one happy-path test and one error-path test
+- Every bug fix needs a regression test that would have caught the bug
+
+## Test data
+
+- Use factories or fixtures — never hardcode user IDs, emails, or UUIDs in tests
+- Tests must be isolated — no shared mutable state between tests
+- Tests must be deterministic — no random data, no time-dependent assertions without mocking the clock
+- Clean up after each test — truncate tables, reset mocks, delete created files
+
+---
+
+> **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/language-specific/de/go.md

@@ -0,0 +1,48 @@
+> 🇩🇪 Dies ist die deutsche Übersetzung. [Englische Version](../go.md).
+
+# Go Regeln
+
+## Anwenden auf
+Alle Go-Dateien (`*.go`) in jedem Projekt.
+
+## Regeln
+
+1. **Fehler sind Werte — mit `%w` umschließen** — `fmt.Errorf("operation failed: %w", err)` erhält den ursprünglichen Fehler für `errors.Is`- und `errors.As`-Prüfungen. Fehler niemals mit `_` verwerfen.
+
+2. **Tabellengetriebene Tests** — `[]struct{ name, input, want, wantErr }`-Muster verwenden. Jeder Fall hat einen `t.Run(tt.name, ...)`-Untertest. Macht Testfälle leicht erweiterbar und Fehlermeldungen beschreibend.
+
+3. **Context als erstes Argument** — jede Funktion, die I/O durchführt oder blockiert, nimmt `ctx context.Context` als erstes Parameter. Kontext niemals in einer Struct speichern.
+
+4. **Interfaces dort definieren, wo sie konsumiert werden, nicht wo implementiert** — das Interface in das Paket legen, das es verwendet, nicht in das Paket, das die Implementierung bereitstellt. Hält Pakete entkoppelt.
+
+5. **Interfaces maximal 1-3 Methoden** — größere Interfaces sind schwieriger zu erfüllen und zu mocken. Wenn ein Interface 8 Methoden hat, überlegem, es aufzuteilen.
+
+6. **`panic` nur für wirklich nicht behebbare Programmierfehler** — fehlende erforderliche Konfiguration beim Start, verletzte Invarianten, die nie auftreten sollten. Nicht für Laufzeitfehler wie "record not found".
+
+7. **Keine nackten Returns** — `return x, nil` nicht nur `return`. Benannte Rückgabewerte sind für die Dokumentation in Ordnung, aber nackte Returns verschleiern, was zurückgegeben wird.
+
+8. **`init()` nur für Paket-Level-Nebeneffekte ohne Alternative** — Registrierungsmuster, Treiber-Init. Niemals zum Laden von Konfigurationen oder zum Aufbauen von Verbindungen — das gehört in `main` oder einen Konstruktor.
+
+9. **`log/slog` für strukturiertes Logging** — `slog.Info("request", "method", r.Method, "path", r.URL.Path)`. `fmt.Println` nur für CLI-Ausgabe.
+
+10. **`sync.Once` für lazy Singleton-Initialisierung** — threadsicher, null Overhead nach dem ersten Aufruf:
+    ```go
+    var (
+        instance *DB
+        once     sync.Once
+    )
+    func GetDB() *DB {
+        once.Do(func() { instance = newDB() })
+        return instance
+    }
+    ```
+
+11. **Einbetten statt Erben** — Go hat keine Vererbung. Typen durch Einbettung zusammensetzen: `type AdminUser struct { User; AdminLevel int }`. Interfaces für Polymorphismus verwenden.
+
+12. **Schleifenvariablen explizit erfassen** — in Goroutines innerhalb von Schleifen: `i, v := i, v` vor dem `go func()`. In Go 1.22+ sind Schleifenvariablen pro Iteration; in früheren Versionen werden sie geteilt.
+
+13. **`errgroup` für parallele Operationen mit Fehler-Propagierung** — `golang.org/x/sync/errgroup` statt manuellem `WaitGroup`, wenn Fehler von Goroutines zurückgegeben werden müssen.
+
+14. **Sentinel-Fehler für erwartete Bedingungen, typisierte Fehler für strukturierte Fehler** — `var ErrNotFound = errors.New("not found")` für einfache Bedingungen. Benutzerdefinierte Fehlertypen (die das `error`-Interface implementieren), wenn Aufrufer Felder inspizieren müssen.
+
+15. **HTTP-Handler erhalten nur `(w http.ResponseWriter, r *http.Request)`** — Handler nicht in Structs einbetten oder Closures für einfache Handler verwenden. Dependency Injection über eine Handler-Struct mit einer `ServeHTTP`-Methode verwenden, wenn Abhängigkeiten benötigt werden.

package/rules/language-specific/de/python.md

@@ -0,0 +1,38 @@
+> 🇩🇪 Dies ist die deutsche Übersetzung. [Englische Version](../python.md).
+
+# Python Regeln
+
+## Anwenden auf
+Alle Python-Dateien (`*.py`) in jedem Projekt.
+
+## Regeln
+
+1. **Type Hints auf allen Funktionssignaturen** — Parameter und Rückgabetypen. `from __future__ import annotations` für Forward-Referenzen verwenden. Keine ungetypten Funktionen ohne Type Hints in Produktionscode.
+
+2. **`pathlib.Path` statt `os.path`** — `Path("dir") / "file.txt"` ist sauberer und funktioniert plattformübergreifend. `os.path` ist Legacy.
+
+3. **f-Strings statt `.format()` und `%`** — `f"Hello {name}"` überall. `.format()` nur wenn das Template als String-Variable gespeichert ist.
+
+4. **Niemals veränderliche Standardargumente verwenden** — `def fn(items: list = [])` erstellt eine Liste, die über alle Aufrufe geteilt wird. `def fn(items: list | None = None)` verwenden und innen zuweisen.
+
+5. **`dataclasses` für Daten-Container, `Pydantic` für validierte externe Daten** — wenn es eine Systemgrenze überquert (HTTP, Datei, Env), Pydantic verwenden. Wenn es rein interner State ist, ist `@dataclass` leichtgewichtiger.
+
+6. **`with`-Anweisungen für alle Ressourcenverwaltung bevorzugen** — Dateien, DB-Verbindungen, Locks, HTTP-Sessions. Niemals `.close()` manuell aufrufen.
+
+7. **Generator-Ausdrücke statt List-Comprehensions, wenn nur einmal iteriert wird** — `sum(x*x for x in range(1000))` alloziert keine Liste.
+
+8. **`__all__` in jedem öffentlichen Modul definieren** — explizite öffentliche API. Verhindert `import *`-Verschmutzung und dokumentiert die Absicht.
+
+9. **Spezifische Ausnahmen werfen, spezifische Ausnahmen abfangen** — `raise ValueError("message")` nicht `raise Exception`. `except ValueError` nicht `except Exception`, außer an einer Top-Level-Fehlergrenze.
+
+10. **`logging`-Modul für Produktionscode, niemals `print()`** — `import logging; logger = logging.getLogger(__name__)`. `print()` nur in CLI-Ausgabecode.
+
+11. **`Enum` für feste Wertmengen verwenden** — keine String-Konstanten. `class Status(str, Enum): ACTIVE = "active"` gibt Typensicherheit und IDE-Vervollständigung.
+
+12. **`subprocess.run()` statt `os.system()`** — erfasst Ausgabe, wirft bei Fehler mit `check=True`, vermeidet Shell-Injection mit Listen-Args: `subprocess.run(["git", "status"], check=True)`.
+
+13. **`dict.get(key, default)` statt `key in dict` + `dict[key]`** — eine Abfrage statt zwei.
+
+14. **Abstrakte Basisklassen via `abc.ABC`** — wenn erzwungene Interface-Verträge benötigt werden. `Protocol` für strukturelles Subtyping (Duck Typing mit Typ-Prüfung).
+
+15. **Virtuelle Umgebungen immer, Abhängigkeiten in `pyproject.toml`** — `uv` oder `poetry` für Verwaltung. Kein `requirements.txt` für neue Projekte.

package/rules/language-specific/de/typescript.md

@@ -0,0 +1,51 @@
+> 🇩🇪 Dies ist die deutsche Übersetzung. [Englische Version](../typescript.md).
+
+# TypeScript Regeln
+
+## Anwenden auf
+Alle TypeScript-Dateien (`*.ts`, `*.tsx`) in jedem Projekt.
+
+## Regeln
+
+1. **`strict: true` in `tsconfig.json`** — immer. Dies aktiviert `strictNullChecks`, `noImplicitAny` und `strictFunctionTypes`. Den Strict-Modus niemals deaktivieren, um Fehler zu unterdrücken; die Typen korrigieren.
+
+2. **`unknown` statt `any` für ungetypte externe Daten** — `any` deaktiviert die Typprüfung vollständig. `unknown` erzwingt die Einschränkung des Typs vor der Verwendung. Externe Daten mit Zod oder ähnlichem parsen.
+
+3. **`satisfies`-Operator für typgeprüfte Objekt-Literale** — `const config = { port: 3000 } satisfies Config` fängt Typfehler ab, während der Literal-Typ erhalten bleibt (keine Erweiterung auf `Config`).
+
+4. **Diskriminierte Unions statt nullbarer Felder** — bevorzugen:
+   ```ts
+   type Result = { status: "ok"; data: User } | { status: "error"; message: string }
+   ```
+   statt `{ data?: User; error?: string }`. Diskriminierte Unions ermöglichen erschöpfende `switch`-Prüfung.
+
+5. **Keine `as`-Typ-Assertions in Produktionscode** — `as SomeType` bringt den Compiler zum Schweigen ohne zu prüfen. Typ-Prädikate oder `satisfies` stattdessen verwenden. Ausnahme: DOM-Abfragen, wo TypeScript nicht besser inferieren kann.
+
+6. **Typ-Prädikate für Einschränkung** — `function isUser(v: unknown): v is User { return typeof v === "object" && v !== null && "email" in v }`.
+
+7. **`interface` für Objektformen, `type` für Unions und Aliase** — `interface` unterstützt `extends` und Deklarations-Merging. `type` wird für Unions und gemappte Typen benötigt.
+
+8. **`const`-Assertions für Literal-Typen** — `const ROLES = ["admin", "user"] as const` gibt Typ `readonly ["admin", "user"]` statt `string[]`.
+
+9. **Niemals den `Function`-Typ verwenden** — spezifische Signaturen verwenden: `(event: MouseEvent) => void`. `Function` akzeptiert alles und gibt alles zurück.
+
+10. **Zod für Laufzeitvalidierung externer Daten** — HTTP-Request-Bodies, API-Antworten, Env-Vars, Konfigurationsdateien. TypeScript-Typen gelten nur zur Kompilierzeit; Zod validiert zur Laufzeit:
+    ```ts
+    const UserSchema = z.object({ email: z.string().email(), age: z.number().int().positive() })
+    const user = UserSchema.parse(req.body)  // wirft ZodError wenn ungültig
+    ```
+
+11. **`readonly` auf Arrays und Objekten, die nicht verändert werden sollen** — `readonly string[]` verhindert push/splice. `Readonly<Config>` auf Konfigurationsobjekten, die durch Schichten weitergegeben werden.
+
+12. **Explizite Rückgabetypen auf öffentlichen/exportierten Funktionen** — verbessert Lesbarkeit und erkennt versehentliche Rückgabetyp-Änderungen.
+
+13. **`import type` für nur-Typ-Imports** — `import type { User } from './types'` wird zur Laufzeit gelöscht und vermeidet zirkuläre Abhängigkeitsprobleme.
+
+14. **`never` zur erschöpfenden Behandlung** — im Default-Fall eines Switch über eine diskriminierte Union:
+    ```ts
+    default:
+      const _exhaustive: never = status  // Kompilierfehler wenn ein Fall fehlt
+      throw new Error(`Unhandled: ${_exhaustive}`)
+    ```
+
+15. **`noUncheckedIndexedAccess` aktivieren** — Array- und Objekt-Indexzugriff gibt `T | undefined` statt `T` zurück, was Null-Prüfungen erzwingt, wo sie benötigt werden.