Entrée utilisateur : $ARGUMENTS
Configuration
Avant toute chose : lire ${CLAUDE_SKILL_DIR}/../squad-config.md
Prouver
- Avant et après chaque fois que possible. Enregistrez chaque artefact et rapportez son chemin.
- Si un type de preuve n'est pas disponible, passez à un autre.
- Vous vérifiez le travail d'un autre (QA) ? Rejouez vous-même le rouge → vert — ne faites jamais confiance à leurs artefacts.
La preuve doit être postée dans les commentaires du ticket (tkt) avec le titre : « EOP » signifie « Evidence Of Proof » (Preuve de validation).
Types de preuve
| Classe de tkt | Preuve rouge → vert |
|---|---|
| UI / visuel | Outil de preuve UI captures d'écran avant/après (par défaut actuel) |
| UI vs une référence de design (le tkt cite un nœud Figma, ou joint un HTML/PNG de référence comme « le design ») | les captures d'écran sont le rouge ; le vert est un tableau de mesures par rapport à la référence rendue à la même taille de fenêtre — rect, rayon, écarts, décalage central — pour l'élément touché et ses voisins |
| API / contrat | curl du point d'accès → mauvais statut/corps, puis correct (sauvegarder les deux) |
| Logique métier / calcul / math financier | un test unitaire/d'intégration à la cause racine qui échoue d'abord, puis réussit |
| Données / état BDD | une requête BDD montrant l'état stocké erroné, puis correct (+ toute migration) |
| Événement / Kafka / asynchrone | produire le déclencheur et capturer le résultat observable du consommateur (ligne de log du dispatcher / ligne BDD / appel sortant) erroné, puis correct. Un test unitaire chez le producteur est une barrière de régression, pas cette preuve |