Triage Issue

Investiguer un problème signalé, en trouver la cause racine et créer une GitHub issue avec un plan de correction TDD. C'est un workflow largement mains libres - minimisez les questions à l'utilisateur.

Process

1. Capturer le problème

Obtenez une brève description de l'issue de la part de l'utilisateur. S'il n'en a pas fourni une, posez UNE question : « Quel est le problème que vous rencontrez ? »

NE posez PAS de questions de suivi pour le moment. Commencez à investiguer immédiatement.

2. Explorer et diagnostiquer

Utilisez l'outil Agent avec subagent_type=Explore pour investiguer profondément la codebase. Votre objectif est de trouver :

Où le bug se manifeste (points d'entrée, UI, réponses API)
Quel chemin de code est impliqué (tracez le flux)
Pourquoi il échoue (la cause racine, pas seulement le symptôme)
Quel code connexe existe (motifs similaires, tests, modules adjacents)

Examinez :

Les fichiers source connexes et leurs dépendances
Les tests existants (ce qui est testé, ce qui manque)
Les changements récents dans les fichiers affectés (git log sur les fichiers pertinents)
La gestion des erreurs dans le chemin de code
Les motifs similaires ailleurs dans la codebase qui fonctionnent correctement

3. Identifier l'approche de correction

Basé sur votre investigation, déterminez :

Le changement minimal nécessaire pour corriger la cause racine
Quels modules/interfaces sont affectés
Quels comportements doivent être vérifiés via les tests
S'il s'agit d'une régression, d'une fonctionnalité manquante ou d'un défaut de conception

4. Concevoir le plan de correction TDD

Créez une liste concrète et ordonnée de cycles RED-GREEN. Chaque cycle est une tranche verticale :

RED : Décrivez un test spécifique qui capture le comportement cassé/manquant
GREEN : Décrivez le changement de code minimal pour faire passer ce test

Règles :

Les tests vérifient le comportement via les interfaces publiques, pas les détails d'implémentation
Un test à la fois, tranches verticales (PAS tous les tests d'abord, puis tout le code)
Chaque test doit survivre à des refactors internes
Incluez une étape de refactor final si nécessaire
Durabilité : Suggérez uniquement des corrections qui survivraient à des changements radicaux de codebase. Décrivez les comportements et contrats, pas la structure interne. Les tests affirment sur des résultats observables (réponses API, état UI, effets visibles pour l'utilisateur), pas l'état interne. Une bonne suggestion se lit comme une spec ; une mauvaise ressemble à un diff.

5. Créer la GitHub issue

Créez une GitHub issue en utilisant gh issue create avec le modèle ci-dessous. NE demandez PAS à l'utilisateur de vérifier avant de créer - créez-la simplement et partagez l'URL.

<issue-template>

Problem

Une description claire du bug ou de l'issue, incluant :

Ce qui se passe (comportement réel)
Ce qui devrait se passer (comportement attendu)
Comment reproduire (si applicable)

Root Cause Analysis

Décrivez ce que vous avez trouvé pendant l'investigation :

Le chemin de code impliqué
Pourquoi le code actuel échoue
Tous les facteurs contributifs

N'incluez PAS les chemins de fichiers spécifiques, les numéros de ligne ou les détails d'implémentation qui se couplent à la disposition actuelle du code. Décrivez plutôt les modules, les comportements et les contrats. L'issue devrait rester utile même après des refactors majeurs.

TDD Fix Plan

Une liste numérotée de cycles RED-GREEN :

RED : Écrire un test qui [décrit le comportement attendu] GREEN : [Changement minimal pour le faire passer]
RED : Écrire un test qui [décrit le comportement suivant] GREEN : [Changement minimal pour le faire passer]

...

REFACTOR : [Tout nettoyage nécessaire après que tous les tests passent]

Acceptance Criteria

[ ] Criterion 1
[ ] Criterion 2
[ ] All new tests pass
[ ] Existing tests still pass

</issue-template>

Après avoir créé l'issue, imprimez l'URL de l'issue et un résumé d'une ligne de la cause racine.

triage-issue