Vérification de la qualité du code
Vérification complète de la qualité pour le code récemment écrit. Combine la conformité aux spécifications, la sécurité inter-couches et les contrôles de pré-validation.
Étape 1 : Identifier ce qui a changé
git diff --name-only HEAD
git status
Étape 2 : Lire les artefacts de la tâche et les spécifications applicables
Lisez les artefacts de la tâche en cours dans l'ordre :
prd.mddesign.md(si présent)implement.md(si présent)
python3 ./.trellis/scripts/get_context.py --mode packages
Pour chaque package/couche modifié, lisez l'index des spécifications et suivez sa section Vérification de la qualité :
cat .trellis/spec/<package>/<layer>/index.md
Lisez les fichiers de directives spécifiques référencés — l'index est un pointeur, pas l'objectif.
Étape 3 : Exécuter les vérifications du projet
Exécutez les commandes de lint, de typage et de test du projet. Corrigez toute défaillance avant de continuer.
Étape 4 : Passer en revue la liste de contrôle
Qualité du code
- Le linter passe-t-il ?
- Le vérificateur de types passe-t-il (si applicable) ?
- Les tests passent-ils ?
- Aucun journal de débogage laissé ?
- Aucun avertissement supprimé ou contournement de sécurité de type ?
Couverture des tests
- Nouvelle fonction → test unitaire ajouté ?
- Correction de bug → test de régression ajouté ?
- Comportement modifié → tests existants mis à jour ?
Synchronisation des spécifications
-
.trellis/spec/nécessite-t-il des mises à jour ? (nouveaux modèles, conventions, leçons apprises)
"Si j'ai corrigé un bug ou découvert quelque chose de non évident, dois-je le documenter pour que mon futur moi ne rencontre pas le même problème ?" → Si OUI, mettez à jour le document de spécification concerné.
Discipline de périmètre
- Y a-t-il du nettoyage de code que la tâche n'exigeait pas ?
- Y a-t-il une abstraction, une configuration ou un point d'extension ajouté pour un cas qui n'existe pas encore ?
- Y a-t-il un repli spéculatif pour un état qui ne peut pas se produire ?
- Y a-t-il un fichier modifié que les critères d'acceptation ne mentionnent pas ?
- Y a-t-il un contournement ajouté à l'appelant au lieu d'un correctif là où le comportement se trouve réellement ?
Étape 5 : Dimensions inter-couches (si applicable)
Ignorez cette étape si votre modification se limite à une seule couche.
A. Flux de données (les modifications touchent 3+ couches)
- Les flux de lecture sont corrects : Stockage → Service → API → UI
- Les flux d'écriture sont corrects : UI → API → Service → Stockage
- Les types/schémas sont-ils correctement transmis entre les couches ?
- Les erreurs sont-elles correctement propagées à l'appelant ?
B. Réutilisation du code (modification de constantes, création d'utilitaires)
- Avez-vous recherché du code similaire existant avant d'en créer un nouveau ?
grep -r "pattern" src/ - Si la même valeur se répète, représente-t-elle un concept stable dont les appelants doivent changer ensemble ? Extrayez seulement alors — deux littéraux qui coïncident aujourd'hui doivent rester séparés.
- Après une modification par lots, toutes les occurrences sont-elles mises à jour ?
C. Importation/Dépendance (création de nouveaux fichiers)
- Chemins d'importation corrects (relatifs vs absolus) ?
- Pas de dépendances circulaires ?
D. Cohérence au sein de la même couche
- Les autres endroits utilisant le même concept sont-ils cohérents ?
Étape 6 : Signaler et corriger
Signalez chaque violation que vous trouvez. Ensuite :
- Mécanique et locale (point de lint, type manquant, mauvaise importation, branche morte, assertion échouée) → corrigez sur place, puis relancez les vérifications du projet.
- Conception ou jugement (nommer un concept partagé, déplacer une limite de module, modifier une interface publique, réaffecter l'emplacement du comportement) → enregistrez les preuves et votre recommandation, puis arrêtez-vous. Ne le réécrivez pas en silence.
Si un correctif toucherait des fichiers en dehors du périmètre de la tâche actuelle, dites-le et arrêtez-vous au lieu d'élargir la modification.