Débogage parallèle

Framework pour déboguer les problèmes complexes en utilisant la méthodologie de l'Analyse des hypothèses concurrentes (ACH) avec investigation d'agents en parallèle.

Quand utiliser cette skill

• Le bug a plusieurs causes racines plausibles
• Les premières tentatives de débogage n'ont pas identifié le problème
• Le problème s'étend sur plusieurs modules ou composants
• Besoin d'une analyse systématique de la cause racine avec preuves
• Vouloir éviter le biais de confirmation dans le débogage

Framework de génération d'hypothèses

Générez des hypothèses sur 6 catégories de modes de défaillance :

1. Erreur logique

• Logique conditionnelle incorrecte (mauvais opérateur, cas manquant)
• Erreurs hors limites dans les boucles ou accès aux tableaux
• Gestion manquante des cas extrêmes
• Implémentation d'algorithme incorrecte

2. Problème de données

• Données d'entrée invalides ou inattendues
• Incompatibilité de type ou erreur de coercion
• Null/undefined/None là où une valeur est attendue
• Problème d'encodage ou de sérialisation
• Troncature ou débordement de données

3. Problème d'état

• Race condition entre opérations concurrentes
• Cache périmé retournant des données obsolètes
• Initialisation incorrecte ou valeurs par défaut erronées
• Mutation involontaire d'état partagé
• Erreur de transition de machine d'état

4. Défaillance d'intégration

• Violation de contrat API (demande/réponse incompatible)
• Incompatibilité de version entre composants
• Déconnexion de configuration entre environnements
• Variables d'environnement manquantes ou incorrectes
• Timeout réseau ou défaillance de connexion

5. Problème de ressource

• Fuite mémoire causant une dégradation progressive
• Épuisement du pool de connexions
• Fuite de descripteur de fichier ou de handle
• Espace disque ou quota dépassé
• Saturation CPU due au traitement inefficace

6. Environnement

• Dépendance runtime manquante
• Version incorrecte de la libraire ou du framework
• Différence de comportement spécifique à la plateforme
• Problème de permission ou de contrôle d'accès
• Comportement lié au fuseau horaire ou à la locale

Standards de collecte de preuves

Qu'est-ce qui constitue une preuve

Format de citation

Citez toujours les preuves avec des références fichier:ligne :

**Preuve** : La fonction de validation à `src/validators/user.ts:87`
ne vérifie pas les chaînes vides, seulement null/undefined. Cela permet
aux adresses email vides de passer la validation.

Niveaux de confiance

Protocole d'arbitrage des résultats

Après que tous les enquêteurs aient rendu compte :

Étape 1 : Catégoriser les résultats

• Confirmé : Confiance élevée, preuves fortes, chaîne causale claire
• Plausible : Confiance moyenne, quelques preuves, chaîne causale raisonnable
• Réfuté : Les preuves contredisent l'hypothèse
• Inconclusif : Preuves insuffisantes pour confirmer ou réfuter

Étape 2 : Comparer les hypothèses confirmées

Si plusieurs hypothèses sont confirmées, classer par :

1. Niveau de confiance
2. Nombre de preuves qui les soutiennent
3. Force de la chaîne causale
4. Absence de preuves contradictoires

Étape 3 : Déterminer la cause racine

• Si une hypothèse domine clairement : déclarer comme cause racine
• Si plusieurs hypothèses sont également probables : peut être un problème composé (plusieurs causes contributives)
• Si aucune hypothèse confirmée : générer de nouvelles hypothèses basées sur les preuves recueillies

Étape 4 : Valider le correctif

Avant de déclarer le bug corrigé :

• [ ] Le correctif répond à la cause racine identifiée
• [ ] Le correctif n'introduit pas de nouveaux problèmes
• [ ] Le cas de reproduction d'origine n'échoue plus
• [ ] Les cas extrêmes liés sont couverts
• [ ] Les tests pertinents sont ajoutés ou mis à jour