Session QA

Menez une session QA interactive. L'utilisateur décrit les problèmes qu'il rencontre. Vous clarifiez, explorez le dépôt pour avoir du contexte, et créez des issues GitHub durables, centrées sur l'utilisateur, et qui utilisent le langage métier du projet.

Pour chaque issue soulevée par l'utilisateur

1. Écoutez et clarifiez légèrement

Laissez l'utilisateur décrire le problème avec ses propres mots. Posez au maximum 2-3 courtes questions de clarification portant sur :

Ce qu'il attendait par rapport à ce qui s'est réellement passé
Les étapes pour reproduire (si ce n'est pas évident)
Si c'est régulier ou intermittent

Ne sur-interrogez PAS. Si la description est suffisamment claire pour créer une issue, passez à la suite.

2. Explorez le dépôt en arrière-plan

Pendant que vous parlez à l'utilisateur, lancez un Agent (subagent_type=Explore) en arrière-plan pour comprendre la zone pertinente. L'objectif n'est PAS de trouver une correction — c'est de :

Apprendre le langage métier utilisé dans cette zone (consultez UBIQUITOUS_LANGUAGE.md)
Comprendre ce que la fonctionnalité est censée faire
Identifier la limite du comportement visible par l'utilisateur

Ce contexte vous aide à rédiger une meilleure issue — mais l'issue elle-même ne doit PAS faire référence à des fichiers spécifiques, des numéros de ligne, ou des détails d'implémentation interne.

3. Évaluez la portée : une seule issue ou découpe ?

Avant de créer l'issue, décidez si c'est une seule issue ou si cela doit être découpé en plusieurs issues.

Découpez quand :

La correction s'étend sur plusieurs zones indépendantes (par ex. « la validation du formulaire est mauvaise ET le message de succès manque ET la redirection est cassée »)
Il y a des préoccupations clairement séparables sur lesquelles différentes personnes pourraient travailler en parallèle
L'utilisateur décrit quelque chose qui a plusieurs modes de défaillance ou symptômes distincts

Gardez comme une seule issue quand :

C'est un comportement unique qui est mauvais à un seul endroit
Les symptômes sont tous causés par le même comportement racine

4. Créez la ou les issues GitHub

Créez des issues avec gh issue create. Ne demandez PAS à l'utilisateur de vérifier d'abord — créez simplement et partagez les URLs.

Les issues doivent être durables — elles doivent avoir du sens après des refactorisations majeures. Rédigez du point de vue de l'utilisateur.

Pour une seule issue

Utilisez ce modèle :

## Ce qui s'est passé

[Décrivez le comportement réel vécu par l'utilisateur, en langage simple]

## Ce que j'attendais

[Décrivez le comportement attendu]

## Étapes pour reproduire

1. [Étapes concrètes et numérotées qu'un développeur peut suivre]
2. [Utilisez les termes métier du dépôt, pas les noms de modules internes]
3. [Incluez les entrées pertinentes, les drapeaux ou la configuration]

## Contexte supplémentaire

[Toute observation supplémentaire de la part de l'utilisateur ou de l'exploration du dépôt qui aide à cadrer l'issue — par ex. « cela ne se produit que lors de l'utilisation de la couche Docker, pas de la couche système de fichiers » — utilisez le langage métier mais ne citez pas les fichiers]

Pour une découpe (plusieurs issues)

Créez les issues dans l'ordre de dépendance (d'abord les bloqueurs) pour pouvoir référencer les vrais numéros d'issue.

Utilisez ce modèle pour chaque sous-issue :

## Issue parente

#<numéro-issue-parente> (si vous avez créé une issue de suivi) ou « Signalée lors de la session QA »

## Ce qui ne va pas

[Décrivez ce problème de comportement spécifique — juste cette tranche, pas tout le rapport]

## Ce que j'attendais

[Comportement attendu pour cette tranche spécifique]

## Étapes pour reproduire

1. [Étapes spécifiques à CETTE issue]

## Bloquée par

- #<numéro-issue> (si cette issue ne peut pas être corrigée avant qu'une autre ne le soit)

Ou « Aucun — peut commencer immédiatement » s'il n'y a pas de bloqueurs.

## Contexte supplémentaire

[Toute observation supplémentaire pertinente à cette tranche]

Lors de la création d'une découpe :

Préférez de nombreuses issues fines à quelques épaisses — chacune doit être indépendamment corrigeable et vérifiable
Marquez les relations de blocage honnêtement — si l'issue B ne peut vraiment pas être testée avant que l'issue A soit corrigée, dites-le. Si elles sont indépendantes, marquez les deux comme « Aucun — peut commencer immédiatement »
Créez les issues dans l'ordre de dépendance pour pouvoir référencer les vrais numéros d'issue dans « Bloquée par »
Maximisez le parallélisme — l'objectif est que plusieurs personnes (ou agents) puissent prendre des issues différentes simultanément

Règles pour tous les corps d'issue

Pas de chemins de fichiers ou de numéros de ligne — ils deviennent obsolètes
Utilisez le langage métier du projet (consultez UBIQUITOUS_LANGUAGE.md s'il existe)
Décrivez les comportements, pas le code — « le service de synchronisation échoue à appliquer le patch » et non « applyPatch() lance une exception ligne 42 »
Les étapes de reproduction sont obligatoires — si vous ne pouvez pas les déterminer, posez la question à l'utilisateur
Gardez-le concis — un développeur doit pouvoir lire l'issue en 30 secondes

Après la création, affichez toutes les URLs d'issue (avec les relations de blocage résumées) et demandez : « Issue suivante, ou on arrête ? »

5. Continuez la session

Continuez jusqu'à ce que l'utilisateur dise qu'il en a terminé. Chaque issue est indépendante — ne les regroupez pas.

qa