verifylisted

Un build vert ne prouve pas qu'un outil marche. Les étapes 1 à 3 sont obligatoires ; la 4 l'est dès que la tranche a touché à l'écran. ## 1. Épingler le point fixe Avant de lancer quoi que ce soit, savoir exactement ce qu'on vérifie et contre quoi : - **La tranche.** Celle que l'utilisateur désigne ; sinon la première de la section « Tranches » de `BACKLOG.md`. Si le diff ne ressemble pas à cette tranche-là, ne pas deviner : le dire et demander laquelle. - **Le critère**, recopié **mot pour mot** depuis la tranche, plus le critère de réussite de `SPEC.md`. Pas reformulé — recopié. Une Vérif qui porte plusieurs points séparés par `·` se recopie **en entier** : chacun est un verdict, aucun ne se laisse tomber parce que la tranche n'y a pas touché. - **Le port de dev**, lu dans `package.json`. Il est fixe et propre à ce dépôt, et le sous-agent de l'étape 3 en a besoin : sans lui, il ne peut pas remplir l'obligation qu'on lui donne de vérifier quel serveur il pilote. - **Le diff**, depuis le dernier commit : `git diff HEAD --stat` **et** `git status --porcelain`. Les deux, jamais l'un seul — `git diff` ne voit pas les fichiers non suivis, et une tranche qui ne fait qu'ajouter des fichiers lui paraît vide alors qu'elle a tout écrit. C'est quand **les deux** ne rendent rien qu'il n'y a rien à vérifier : le dire et s'arrêter là. - **La ligne de direction visuelle** de `DECISIONS.md`, si la tranche a touché à l'écran. Un point fixe qui ne résout pas, un critère absent ou un diff