yurgeno/taut-data-community

dev-review — le réviseur (étape 3)

Un regard indépendant sur le changement. Examinez la DIFF par rapport à la TÂCHE — pas la diff par rapport à rien.

Appel	dev-review <TÂCHE>
Entrée	le diff de l'arbre de travail + memory/spec/<TÂCHE>/analysis.md et implementation.md
Sortie	memory/spec/<TÂCHE>/review.md, status: draft, verdict approuver / changements-nécessaires
Porte	le propriétaire accepte le verdict — voir La porte du propriétaire ci-dessous
Suivant	changements-nécessaires → dev-implement <TÂCHE> à nouveau ; approuver → le propriétaire livre le changement

0. Vérification d'entrée

• Aucune <TÂCHE> donnée → demander.
• implementation.md manquant ou vide → stop : il n'y a rien à revoir pour l'instant.
• implementation.md toujours status: draft → le mentionner et revoir quand même si le propriétaire le demande, mais enregistrer dans le verdict que l'étape 2 n'avait pas passé sa porte.
• Lire l'analyse AVANT le diff. Juger un changement sans savoir ce qui était prévu produit des commentaires de style et manque la constatation importante.

Processus (universel)

1. Re-dériver l'intention à partir de la tâche et de l'analyse ; puis juger si le diff l'atteint. Un changement magnifique au mauvais endroit est une constatation critique.

2. Exactitude d'abord : cas limites, chemins d'erreur, concurrence, formes de données aux frontières. Ensuite les conventions et la clarté. Les nits de style uniquement en dernier et marqués comme tels.

3. Ne faites pas confiance aux preuves de l'implémenteur — reproduisez-les. Relancez la vérification décisive vous-même (déléguez au sous-agent dev-reviewer lorsque la suite est longue). Les notes d'implémentation disent ce qui a été exécuté ; votre travail est de vérifier que cela tient toujours et que les BONNES choses ont été exécutées.

4. Vérifiez le rayon d'explosion : qu'est-ce qui consomme d'autre le code modifié ? Cherchez les utilisations que le diff n'a pas touchées ; les changements non intentionnels de lockfile, config ou fichier généré sont des constatations.

5. Constatations, pas correctifs. Signalez par sévérité (critique / devrait-corriger / nit) avec fichier et ligne ; les correctifs mécaniques triviaux PEUVENT être appliqués directement, tout le reste retourne à dev-implement. Écrivez le verdict dans memory/spec/<TÂCHE>/review.md, en commençant par :

   ---
   task: <TÂCHE>
   stage: review
   status: draft
   verdict: approuver | changements-nécessaires
   ---
   

Vérifications de revue spécifiques à la pile

node: échappements de type (any, as, @ts-ignore) introduits par le diff ; chaînes de promesses sans gestion d'erreur ; dérive non intentionnelle de dépendance ou de lockfile ; modifications de monorepo qui contournent le graphe du projet (imports relatifs profonds entre paquets).

jvm: nullabilité aux nouvelles frontières (types de plateforme Kotlin, mauvais usage de Optional) ; gestion des ressources (try-with-resources / use) ; portée transactionnelle et DI des nouveaux beans ; tests placés pour être réellement exécutés (bon module, bonne convention de nommage).

android: vérifiez le cycle de vie, pas seulement la logique — un travail démarré dans un composable ou une Activity doit survivre à la rotation et s'arrêter lorsque la portée meurt (collecter dans repeatOnLifecycle/collectAsStateWithLifecycle, annuler les coroutines avec la bonne portée). Un Context détenu dans un objet à longue durée de vie est une fuite. De nouvelles permissions dans AndroidManifest.xml nécessitent également le chemin de demande runtime ; les API au-dessus du minSdk nécessitent une porte explicite. Les builds Release diffèrent des builds Debug — les règles R8/ProGuard pour tout ce qui est réflexif (sérialisation, Room, DI) font partie du changement. Et demandez si les tests instrumentés ont été réellement EXÉCUTÉS : ce sont ceux que CI saute le plus souvent.

php: declare(strict_types=1) et types de paramètres/retour sur le nouveau code ; surfaces d'injection (SQL brut, sortie non échappée) dans les chemins touchés ; suppression d'erreur (@) introduite par le diff ; changements de config/DI cohérents avec les conventions du framework.

python: typage aux nouvelles frontières (Any, types de retour manquants, # type: ignore introduits par le diff) ; arguments par défaut mutables et état mutable au niveau de la classe ; ressources fermées (with pour les fichiers et connexions) et appels async réellement attendus ; gestion d'exception qui avale (except Exception: pass) ; manifeste et lock changés ensemble (pyproject.toml vs uv.lock / poetry.lock) ; Django : une migration pour chaque changement de modèle, réversible ; tests placés là où le lanceur les trouve (tests/, test_*.py, fixtures conftest.py) et non ignorés par un marqueur obsolète.

La porte du propriétaire

STOP ici — le réviseur ne livre jamais le changement et ne le réimplémente jamais. Rapportez le verdict en deux phrases avec les constatations qui le motivent.

• changements-nécessaires → le propriétaire décide ; sur sa parole, la boucle retourne à dev-implement <TÂCHE>, qui ajoute à implementation.md plutôt que de recommencer. review.md reste comme trace de ce qui n'allait pas.
• approuver → sur l'acceptation explicite du propriétaire, définir status: approved. Livrer le changement (commit, branche, push) est l'acte du propriétaire selon les lois git de l'espace de travail — pas de cette compétence.

Terminé quand

review.md porte son préambule et le verdict avec les constatations par sévérité, la vérification décisive a été RELANCÉE PAR VOUS, et le résumé de chat donne le verdict en deux phrases. N'approuvez que ce que vous défendriez dans le post-mortem de quelqu'un d'autre.