Extended Thinking et Plan Mode

# Activer/désactiver l'Extended Thinking (toggle)
Alt+T        # Linux / Windows
Option+T     # macOS

# Voir le raisonnement interne de Claude (mode verbose)
Ctrl+O

# Configurer le budget de tokens alloué au raisonnement
export MAX_THINKING_TOKENS=10000

# Configurer via ~/.claude/settings.json
{
  "alwaysThinkingEnabled": true
}

"Nous devons choisir entre une architecture microservices et un monolithe modulaire
pour notre nouvelle API de gestion de flotte (500 véhicules, 50 utilisateurs simultanés,
données temps réel GPS, reporting analytique).

Analyse en profondeur les trade-offs : maintenabilité, coût d'infrastructure,
complexité opérationnelle, scalabilité à 5 ans, onboarding des nouveaux devs.
Recommande une architecture avec une justification détaillée."

"Notre API Node.js présente des fuites mémoire intermittentes en production.
Heap croît de 50MB/heure, GC ne récupère pas tout.
Logs : des requêtes GraphQL complexes corrèlent avec les pics.

Analyse les causes possibles et propose un plan de diagnostic systématique."

"Nous devons migrer 45 000 lignes de JavaScript vers TypeScript strict.
Le projet a 3 ans, pas de types existants, 0% de couverture de tests.
Équipe : 4 devs, contrainte : pas d'arrêt des nouvelles features pendant la migration.

Propose une stratégie de migration progressive avec étapes, risques et métriques de succès."

"Audite ce module d'authentification OAuth2 pour détecter toutes les vulnérabilités potentielles.
Ne te contente pas de la liste OWASP Top 10, analyse les timing attacks,
les problèmes de state management, les edge cases d'expiration de token."

# Demander un plan explicitement
"Avant de coder quoi que ce soit, propose-moi un plan détaillé.
Je validerai le plan avant que tu commences l'implémentation."

# Formulation alternative
"Fais d'abord une analyse et un plan. Attends ma validation avant de toucher au code."

"Je veux migrer notre state management de Redux Toolkit vers Zustand.
Le projet a 25 components qui utilisent Redux, 8 slices, 15 selectors complexes.

Propose un plan de migration avant de commencer.
Pour chaque étape : fichiers impactés, changements à faire,
risques de régression, tests à vérifier."

## Plan de migration Redux → Zustand

### Analyse de l'impact
- 25 composants utilisent useSelector ou useDispatch
- 8 slices : auth, cart, products, orders, ui, notifications, search, filters
- 15 selectors, dont 6 memoïsés avec createSelector

### Phase 1 : Installation et coexistence (Jour 1)
Fichiers : package.json, store/index.ts
Actions :
- Installer zustand et ses devtools
- Créer le premier store Zustand en parallèle du store Redux
- Configurer les devtools pour les deux
Risques : aucun (pas de modification du code existant)
Tests : build qui passe, pas de régression

### Phase 2 : Migration des slices simples (Jours 2-3)
Slices cibles : ui, notifications (pas de logique async)
Fichiers : store/ui.store.ts (nouveau), store/notifications.store.ts (nouveau)
Stratégie : créer les nouveaux stores Zustand, migrer les composants un par un
Risques : faible (slices sans dépendances croisées)

### Phase 3 : Migration des slices avec async (Jours 4-6)
Slices cibles : auth, products, search
Fichiers : 3 nouveaux stores + tous les composants concernés
Stratégie : remplacer createAsyncThunk par des actions async dans Zustand
Risques : moyen (tester les race conditions et l'état de loading)

[...]

Voulez-vous que je commence par la Phase 1, ou souhaitez-vous modifier le plan ?

"Je veux implémenter un système de notifications en temps réel.
Contraintes : WebSockets, fallback SSE si WebSocket indisponible,
reconnexion automatique, gestion des notifications non lues, persistance Redis.

Fais un plan d'implémentation par phases avec dépendances entre les phases.
Je valide avant que tu commences."

"[Extended Thinking activé]

Je dois prendre une décision d'architecture critique : notre API Gateway actuelle
(Express monolithique) ne tient plus la charge (pics à 10K req/s).
Options : Kong, Nginx + Lua, AWS API Gateway, tRPC.
Contraintes : budget < 500€/mois, team de 3 devs junior, déploiement K8s.

1. Analyse en profondeur chaque option avec ses trade-offs réels
2. Propose un plan de migration détaillé pour l'option recommandée
3. Identifie les risques cachés que je n'aurais peut-être pas vus

Prends le temps qu'il faut pour raisonner."

# Formulation 1 : étapes numérotées
"Analyse ce bug étape par étape :
1. Identifie les symptômes observés
2. Formule 3 hypothèses sur la cause
3. Pour chaque hypothèse, dis comment la valider
4. Recommande par où commencer le debugging"

# Formulation 2 : "raisonne avant de répondre"
"Avant de proposer une solution, raisonne à voix haute :
quelles sont les contraintes, les options, les compromis.
Montre ton raisonnement avant la conclusion."

# Formulation 3 : "joue l'avocat du diable"
"Propose ta solution, puis joue l'avocat du diable :
quels sont les arguments contre ta proposition ?
Comment la rendrais-tu plus robuste face à ces critiques ?"

"Nous choisissons une base de données pour un système d'inventaire temps réel
(50K produits, mises à jour stock chaque seconde, 200 utilisateurs simultanés,
requêtes de reporting hebdomadaire sur 2 ans d'historique).

Raisonne étape par étape :
1. Quels sont les patterns d'accès dominants (lecture/écriture, latence, volume) ?
2. PostgreSQL vs MongoDB vs Redis vs TimescaleDB : évalue chacun sur nos critères
3. Quels sont les compromis du choix que tu recommanderai ?
4. Y a-t-il des architectures hybrides à envisager (Redis + PostgreSQL) ?
5. Qu'est-ce que je n'ai pas pensé à demander mais qui est critique pour ce choix ?"

"Pour chaque affirmation technique que tu fais, indique si c'est :
[CERTAIN] : tu en es sûr
[PROBABLE] : tu penses que c'est vrai mais tu n'es pas certain
[VÉRIFIER] : à vérifier dans la documentation officielle

Si tu ne sais pas quelque chose, dis 'je ne sais pas' plutôt qu'inventer."

"Réponds uniquement sur la base de ce que tu sais de PostgreSQL 15 et Prisma 5.
Si la question sort de ce périmètre ou si tu n'es pas sûr, dis-le explicitement
plutôt que de généraliser depuis d'autres bases de données."

"Avant de me dire qu'une API ou une méthode existe, vérifie dans les fichiers
du projet que cette API est bien importée et utilisée. Ne me dis pas qu'une
fonction existe si tu ne l'as pas vue dans le code."

"[Extended Thinking + Plan Mode]

Je dois concevoir un service de traitement de commandes e-commerce.
Contraintes : 1000 commandes/minute en pic, garantie de livraison (pas de perte),
saga pattern pour les transactions distribuées, retry automatique.

Analyse les patterns event-driven adaptés, propose une architecture
avec les trade-offs, puis génère le plan d'implémentation."

"[Extended Thinking]

Notre API Express perd des requêtes de façon aléatoire en production (1 sur 500).
Logs incohérents : parfois 200 OK, parfois timeout, rarement erreur explicite.
Load balancer Nginx, 3 instances Node.js, Redis pour les sessions.

Analyse toutes les causes possibles, y compris les race conditions,
les problèmes réseau, et les edge cases de timing. Propose un plan
de diagnostic systématique avec les métriques à collecter."

"[Extended Thinking]

Review ce code de service de paiement pour détecter :
- Les failles de sécurité (pas seulement OWASP Top 10)
- Les problèmes de concurrence et de race conditions
- Les edge cases non gérés dans le flux de paiement
- Les problèmes de performance sous charge
- Les risques de conformité PCI-DSS

Pour chaque problème : sévérité, explication, correction suggérée.
[coller le code]"