claudient 0.1.0

package/workflows/fr/debugging-session.md

@@ -0,0 +1,146 @@
+> 🇫🇷 This is the French translation. [English version](../debugging-session.md).
+
+# Workflow de Session de Débogage
+
+Workflow systématique pour diagnostiquer et corriger des bugs avec Claude Code — sans chasser les symptômes.
+
+---
+
+## Quand utiliser ce workflow
+- Un bug qui n'est pas immédiatement évident à la lecture du code
+- Un test en échec dont la cause n'est pas claire
+- Une erreur de production que vous ne pouvez pas reproduire localement
+- Des échecs intermittents
+
+---
+
+## Étape 1 — Construire une boucle de feedback d'abord
+
+Avant d'investiguer, créez un moyen de reproduire le bug de façon fiable. Ne sautez pas cette étape.
+
+**Prompt Claude :**
+```
+I have a bug: [describe the symptom exactly — error message, unexpected behavior, what you expected]
+
+Before we investigate, help me build a reliable way to reproduce it.
+
+Options to consider:
+- A failing test that captures the bug
+- A curl command or script that triggers it
+- A minimal code snippet that demonstrates it
+- Steps to reproduce via the UI
+
+Which is most appropriate here, and write it now.
+```
+
+**Ne pas continuer sans une reproduction fiable.** Déboguer sans reproduction, c'est deviner.
+
+---
+
+## Étape 2 — Isoler le rayon de blast
+
+Comprendre où le bug peut se trouver avant de lire tout code.
+
+**Prompt Claude :**
+```
+Here is the reproduction: [paste the reproduction from Step 1]
+
+Without looking at code yet, answer:
+1. What is the earliest point in the call stack where this could go wrong?
+2. What external systems are involved (DB, cache, third-party API, queue)?
+3. What changed recently that could have introduced this? (check git log)
+4. What is the smallest unit of code that, if wrong, would cause this symptom?
+
+List the files most likely to contain the bug, ranked by probability.
+```
+
+---
+
+## Étape 3 — Générer des hypothèses
+
+**Prompt Claude :**
+```
+Based on the reproduction and the candidate files, generate 3–5 falsifiable hypotheses.
+
+For each hypothesis:
+- State it as a specific claim: "The bug occurs because [X] when [Y]"
+- Describe how to test it: what would we observe if this hypothesis is true?
+- Describe how to disprove it: what would we observe if it's false?
+
+Do not start testing yet. List all hypotheses first.
+```
+
+Révisez les hypothèses. Ajoutez celles que vous avez pensées que Claude a manquées. Classez-les par probabilité.
+
+---
+
+## Étape 4 — Tester les hypothèses, par ordre de probabilité décroissante
+
+**Pour chaque hypothèse :**
+```
+Test hypothesis [N]: "[paste the hypothesis]"
+
+Add the minimal instrumentation needed to confirm or rule this out:
+- A log statement at the right point
+- A debug assertion
+- A targeted test with a specific input
+
+Do not add instrumentation for other hypotheses yet.
+```
+
+Après chaque test :
+- Si confirmée : passer à l'Étape 5
+- Si réfutée : passer à l'hypothèse suivante
+- Si non concluante : affiner l'hypothèse et re-tester
+
+---
+
+## Étape 5 — Corriger et vérifier
+
+Une fois la cause racine confirmée :
+
+**Prompt Claude :**
+```
+Root cause confirmed: [describe what you found]
+
+Now:
+1. Apply the minimal fix — change only what's needed to fix this specific bug
+2. Do not refactor surrounding code
+3. Update the reproduction from Step 1 to be a regression test
+4. Run the full test suite — confirm nothing else broke
+
+Explain in one sentence why this fix works.
+```
+
+---
+
+## Étape 6 — Post-mortem (pour les bugs sérieux)
+
+Pour les bugs qui ont causé un impact utilisateur, une perte de données ou qui ont pris plus de 2 heures à trouver :
+
+**Prompt Claude :**
+```
+Write a brief post-mortem for this bug:
+
+1. What was the bug? (one sentence)
+2. What was the root cause?
+3. How long did it take to find and why?
+4. What would have caught this earlier? (missing test, missing monitoring, code review gap)
+5. What should we add/change to prevent this class of bug?
+
+Keep it under 200 words. No blame, no fluff.
+```
+
+---
+
+## Anti-patterns à éviter
+
+- **Corriger le symptôme, pas la cause** — si vous ne comprenez pas pourquoi, vous ne l'avez pas corrigé
+- **Changer plusieurs choses à la fois** — vous ne saurez pas quel changement a corrigé le bug
+- **Déboguer sans reproduction** — vous devinez
+- **Ajouter de l'instrumentation partout** — cibler des hypothèses spécifiques
+- **Sauter le test de régression** — le bug reviendra
+
+---
+
+> **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/workflows/fr/feature-development.md

@@ -0,0 +1,155 @@
+> 🇫🇷 This is the French translation. [English version](../feature-development.md).
+
+# Workflow de Développement de Fonctionnalité
+
+Workflow de bout en bout pour mener une fonctionnalité de l'idée à la PR fusionnée avec Claude Code.
+
+---
+
+## Quand utiliser ce workflow
+- Construire une nouvelle fonctionnalité qui touche plus d'un fichier
+- Implémenter une spec ou un ticket qui doit être décomposé avant le code
+- Toute fonctionnalité où vous voulez un processus structuré et révisable
+
+---
+
+## Étape 1 — Définir et valider la portée
+
+Avant d'écrire du code, établissez exactement ce que vous construisez.
+
+**Prompt Claude :**
+```
+I need to build: [describe the feature in one paragraph]
+
+Read the relevant files first:
+- [list key files: routes, models, services]
+- CLAUDE.md and CONTEXT.md if present
+
+Then tell me:
+1. What files will need to change?
+2. What new files will be created?
+3. What are the edge cases I should handle?
+4. What decisions do I need to make before we start?
+5. Are there any risks or dependencies I'm missing?
+
+Do not write code yet.
+```
+
+**Ce qu'il faut chercher dans la réponse :**
+- Fichiers que vous n'aviez pas envisagés
+- Cas limites qui provoqueraient des bugs s'ils étaient manqués
+- Décisions qui devraient aller dans CLAUDE.md une fois prises
+
+---
+
+## Étape 2 — Planifier l'implémentation
+
+Une fois la portée claire, obtenez un plan séquencé.
+
+**Prompt Claude :**
+```
+Based on the scope we just defined, create a numbered implementation plan.
+
+Each step must be:
+- A concrete, bounded action (not "implement auth" — "add JWT validation middleware to src/middleware/auth.ts")
+- Completable in a single session
+- Independently testable
+
+Include which files change in each step. Note dependencies between steps.
+```
+
+Révisez le plan. Si une étape est trop grande, demandez à Claude de la décomposer davantage. Validez le plan avant de toucher au code.
+
+---
+
+## Étape 3 — Implémenter étape par étape
+
+Exécutez une étape du plan à la fois. Ne sautez pas en avant.
+
+**Pour chaque étape :**
+```
+Implement step [N]: [paste the step description]
+
+Rules:
+- Only change what's needed for this step
+- Write or update tests for this step's behavior
+- Do not refactor code outside the scope of this step
+- Tell me when this step is complete and what to verify
+```
+
+**Après chaque étape :**
+- Exécuter les tests : confirmer qu'ils passent avant de passer à l'étape suivante
+- Relire le diff vous-même : est-ce ce que vous attendiez ?
+- Si une étape révèle une nouvelle complexité, mettre à jour le plan avant de continuer
+
+---
+
+## Étape 4 — Vérification d'intégration
+
+Une fois toutes les étapes terminées, vérifier que la fonctionnalité complète fonctionne de bout en bout.
+
+**Prompt Claude :**
+```
+All implementation steps are complete. Now:
+
+1. Run the full test suite — report any failures
+2. Check that all edge cases from Step 1 are handled — list each one and confirm
+3. Check for any TODOs or incomplete error handling introduced during implementation
+4. Verify the feature works with [specific test scenario relevant to this feature]
+```
+
+Corriger tout problème trouvé avant de continuer.
+
+---
+
+## Étape 5 — Auto-révision
+
+Avant de créer une PR, révisez vos propres changements.
+
+**Prompt Claude :**
+```
+Review the changes on this branch against main.
+
+Focus on:
+1. CRITICAL issues (bugs, security, data loss risks)
+2. Missing tests for changed behavior
+3. Convention violations vs this project's CLAUDE.md
+4. Anything that would confuse a reader in 6 months
+
+Format: CRITICAL / SUGGESTED / NITPICK
+```
+
+Corriger tous les problèmes CRITICAL. Faire preuve de jugement sur les éléments SUGGESTED.
+
+---
+
+## Étape 6 — Description de PR
+
+**Prompt Claude :**
+```
+Write a PR description for these changes.
+
+Include:
+- What this PR does (one paragraph)
+- Why it's needed (the problem it solves)
+- How to test it (specific steps a reviewer can follow)
+- Any decisions made and why (reference CLAUDE.md or ADRs if relevant)
+- Screenshots or output if applicable
+
+Do not include a list of files changed — the diff covers that.
+```
+
+---
+
+## Liste de contrôle avant fusion
+
+- [ ] Tous les tests passent
+- [ ] Auto-révision terminée, pas de problèmes CRITICAL
+- [ ] Les cas limites de l'Étape 1 sont tous gérés
+- [ ] Description de PR rédigée
+- [ ] CLAUDE.md mis à jour si de nouvelles décisions ont été prises
+- [ ] CONTEXT.md mis à jour si de nouveaux termes de domaine ont été introduits
+
+---
+
+> **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/workflows/fr/new-project-bootstrap.md

@@ -0,0 +1,175 @@
+> 🇫🇷 This is the French translation. [English version](../new-project-bootstrap.md).
+
+# Workflow de Bootstrap de Nouveau Projet
+
+Comment lancer un nouveau projet avec Claude Code — structuré, opinionné et prêt à construire dès le premier jour.
+
+---
+
+## Quand utiliser ce workflow
+- Démarrer une nouvelle application de zéro
+- Configurer un nouveau service dans un système existant
+- Créer un nouveau dépôt pour un projet secondaire ou une mission client
+
+---
+
+## Étape 1 — Définir ce que vous construisez
+
+Avant de toucher au code ou à la config, répondez clairement à ces questions.
+
+**Prompt Claude :**
+```
+I am starting a new project. Help me define it clearly before we write any code.
+
+What I want to build: [describe in 2–3 sentences]
+
+Ask me the following questions one at a time and wait for my answer before asking the next:
+1. Who are the users and what is the primary thing they do?
+2. What is the expected scale at launch? (users, requests/sec, data volume)
+3. What are the hard constraints? (budget, timeline, team size, existing tech stack)
+4. What does "done" look like for v1?
+5. What is explicitly out of scope for v1?
+
+After I answer all five, summarize what we're building and confirm with me before proceeding.
+```
+
+Ne pas continuer tant que la portée n'est pas confirmée par écrit.
+
+---
+
+## Étape 2 — Choisir la stack
+
+**Prompt Claude :**
+```
+Based on what we're building:
+- [paste summary from Step 1]
+
+Recommend a specific stack. For each component (backend, frontend, database, auth, deployment), recommend:
+- Your recommended choice and why it fits our constraints
+- What we'd be giving up vs the next-best alternative
+- No more than 2 options per component — I need a decision, not a menu
+
+Be opinionated. I will push back if I disagree.
+```
+
+Validez la stack avant d'écrire du code. Enregistrez les décisions dans `docs/adr/` si elles ne sont pas évidentes.
+
+---
+
+## Étape 3 — Bootstrapper la structure du projet
+
+**Prompt Claude :**
+```
+Set up the initial project structure for: [stack from Step 2]
+
+Create:
+1. The directory structure (show as a tree before creating anything)
+2. Package/dependency files with pinned versions
+3. Configuration files (TypeScript, ESLint, Prettier, etc.)
+4. .gitignore appropriate for this stack
+5. A minimal working "hello world" that proves the stack runs
+
+Do not add features yet. The goal is a running skeleton.
+```
+
+Vérifiez qu'il fonctionne avant de continuer.
+
+---
+
+## Étape 4 — Configurer CLAUDE.md
+
+**Prompt Claude :**
+```
+Create a CLAUDE.md for this project.
+
+Include:
+1. What this project is (one paragraph)
+2. Stack summary (language, framework, key libraries, DB)
+3. Directory structure with purpose of each directory
+4. Coding conventions specific to this stack
+5. Commands to run (dev server, tests, build, lint)
+6. Decisions already made (from Steps 1–3) that should not be revisited
+7. What NOT to do in this project
+
+Make it dense and useful — not a tutorial. A senior developer should be able to start contributing after reading it.
+```
+
+---
+
+## Étape 5 — Configurer l'environnement de développement
+
+**Prompt Claude :**
+```
+Set up the development environment:
+
+1. Docker Compose file for local dependencies (database, cache, queues)
+2. Environment variable template (.env.example with all required vars, no real values)
+3. Database migrations setup (initial schema if applicable)
+4. Test setup (test runner config, example test, CI-ready)
+5. A Makefile or scripts/ directory with common commands:
+   - make dev (start local environment)
+   - make test (run tests)
+   - make build (production build)
+   - make lint (lint and format check)
+```
+
+---
+
+## Étape 6 — Configurer la CI
+
+**Prompt Claude :**
+```
+Set up a GitHub Actions CI pipeline:
+
+On every PR:
+- Install dependencies (with cache)
+- Run lint
+- Run tests
+- Build (if applicable)
+
+Use the github-actions skill for best practices:
+- Pin action versions
+- Explicit permissions
+- Dependency caching
+- Fail fast on test failures
+
+The pipeline must pass on the current skeleton before we add features.
+```
+
+Vérifiez que la CI passe sur le commit initial avant de passer au développement de fonctionnalités.
+
+---
+
+## Étape 7 — Planification de la première fonctionnalité
+
+Une fois le squelette en cours d'exécution et la CI verte :
+
+**Prompt Claude :**
+```
+The project is bootstrapped. Now plan the first feature:
+
+Feature: [describe the first user-facing capability]
+
+Use the feature-development workflow to plan and implement it.
+Start with Step 1 of that workflow.
+```
+
+Voir `workflows/feature-development.md`.
+
+---
+
+## Liste de contrôle de bootstrap
+
+- [ ] Portée définie et confirmée par écrit
+- [ ] Stack décidée avec un raisonnement documenté
+- [ ] Structure du projet créée et fonctionnelle ("hello world" fonctionne)
+- [ ] CLAUDE.md rédigé et commité
+- [ ] Docker Compose / dépendances locales en cours d'exécution
+- [ ] .env.example commité avec toutes les variables requises
+- [ ] Tests configurés et au moins un qui passe
+- [ ] Pipeline CI vert sur le premier push
+- [ ] `docs/adr/` créé avec les décisions architecturales initiales
+
+---
+
+> **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/workflows/fr/refactor-safely.md

@@ -0,0 +1,150 @@
+> 🇫🇷 This is the French translation. [English version](../refactor-safely.md).
+
+# Workflow de Refactoring Sécurisé
+
+Comment refactoriser du code avec Claude Code sans casser le comportement — en utilisant les tests comme filet de sécurité tout au long.
+
+---
+
+## Quand utiliser ce workflow
+- Extraire des fonctions d'une grande méthode
+- Renommer et réorganiser des modules
+- Remplacer un pattern par un meilleur à travers plusieurs fichiers
+- Réduire la duplication dans la base de code
+- Améliorer la structure d'un module sans changer son comportement externe
+
+---
+
+## La règle d'or
+
+**Ne jamais refactoriser et changer le comportement dans le même commit.** Un refactoring préserve le comportement externe. Si les tests cassent, vous avez soit changé le comportement soit les tests testaient des détails d'implémentation (les deux sont des problèmes).
+
+---
+
+## Étape 1 — Établir une baseline de test
+
+Avant de changer quoi que ce soit, confirmez que vous avez une couverture de test adéquate.
+
+**Prompt Claude :**
+```
+I want to refactor: [describe what you're refactoring and why]
+
+First, assess the current test coverage:
+1. Read the relevant files: [list files]
+2. What behaviors are currently tested?
+3. What behaviors are NOT tested that could break during refactoring?
+4. Write any missing tests now, before we touch production code
+
+Do not change production code yet. Tests only.
+```
+
+**Committez les ajouts de test avant de refactoriser.** Cela rend clair quels tests existaient avant vs. ont été ajoutés dans le cadre du refactoring.
+
+---
+
+## Étape 2 — Définir la portée du refactoring
+
+**Prompt Claude :**
+```
+Here is what I want to refactor: [describe the goal]
+
+Read the relevant files: [list files]
+
+Define the scope:
+1. What will change structurally? (function signatures, file locations, module boundaries)
+2. What will NOT change? (external behavior, API contracts, database schema)
+3. What are the riskiest parts of this refactor?
+4. What is the smallest first step that makes progress without risk?
+
+Do not start the refactor yet.
+```
+
+---
+
+## Étape 3 — Refactoriser en petits incréments testables
+
+Décomposez le refactoring en étapes suffisamment petites pour que les tests puissent vérifier chacune.
+
+**Pour chaque incrément :**
+```
+Refactor step [N]: [describe the specific structural change]
+
+Rules:
+- Change only what's needed for this step
+- Do not change any behavior
+- After this change, all existing tests must still pass
+- Tell me what to verify after this step
+```
+
+**Après chaque incrément :**
+```bash
+# Exécuter les tests — doivent être verts avant l'étape suivante
+npm test  # or pytest, go test, etc.
+```
+
+Si les tests échouent après un changement purement structurel : arrêter, comprendre pourquoi, corriger avant de continuer. Un test en échec après un refactoring signifie que soit le refactoring a changé le comportement soit le test testait l'implémentation (les deux sont des problèmes à corriger maintenant).
+
+---
+
+## Étape 4 — Vérifier que le comportement externe est inchangé
+
+Après tous les incréments :
+
+**Prompt Claude :**
+```
+The refactor is structurally complete. Verify that external behavior is unchanged:
+
+1. Run the full test suite
+2. Check that all public APIs/interfaces are identical to before (same inputs, same outputs)
+3. Check that database queries produce identical results
+4. Check that error cases still produce the same errors
+5. If there are integration tests or end-to-end tests, run them
+
+Report any behavioral differences — even small ones.
+```
+
+---
+
+## Étape 5 — Nettoyage
+
+**Prompt Claude :**
+```
+Before committing, clean up:
+
+1. Remove any debugging code or temporary comments added during refactoring
+2. Remove any dead code that the refactor made unreachable
+3. Update any documentation or comments that referenced the old structure
+4. Check that import paths are clean (no unused imports)
+
+Do not introduce new logic in this step.
+```
+
+---
+
+## Étape 6 — Committer avec un message clair
+
+Structurez le ou les commits de refactoring pour raconter une histoire claire :
+
+```
+refactor: extract payment processing into PaymentService
+
+Moves payment logic out of OrderController into a dedicated service.
+No behavior change — all existing tests pass.
+Motivation: OrderController was 600 lines; this makes both units testable in isolation.
+```
+
+Ne jamais mélanger un commit de refactoring avec un commit de fonctionnalité ou de correction de bug. Les garder séparés.
+
+---
+
+## Anti-patterns de refactoring
+
+- **"Pendant que j'y suis..."** — faire un refactoring et une fonctionnalité en même temps. Arrêter. Terminer le refactoring d'abord.
+- **Refactoriser sans tests** — vous allez casser quelque chose et ne pas le savoir
+- **Refactoring big-bang** — tout changer d'un coup. Faire de façon incrémentale.
+- **Renommer en dernière étape** — renommer d'abord (mécanique, faible risque), puis restructurer
+- **Sauter la baseline** — supposer que les tests sont adéquats sans vérifier d'abord
+
+---
+
+> **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/)