checklisted

# /check — garde de régression Exécuter chaque étape **dans l'ordre**, sans en sauter. Une étape sans configuration dans le manifeste est **annoncée comme sautée**, jamais silencieusement omise : un projet sans typecheck est un fait à rapporter, pas un vide à ignorer. ## Étape 0 — Lire le manifeste Lire `.claude/check.json`. S'il n'existe pas : le signaler, proposer le skill `bootstrap`, et exécuter ce qui est déductible du `package.json` (ou équivalent) en le disant explicitement. Le manifeste porte les étapes du projet, leurs commandes, leurs attendus, et les régressions connues à grepper. Cf. `templates/check.schema.json` du socle pour sa forme. ## Étape 1 — Les commandes de `steps`, dans l'ordre déclaré Pour chaque entrée de `steps` : 1. lancer `cmd` ; 2. comparer à `expect` ; 3. si `counter` est présent, comparer le nombre obtenu à la valeur attendue. **La dérive d'un compteur est une alerte, pas un détail.** Si le nombre de tests a bougé sans qu'un test ait été consciemment ajouté ou retiré, le signaler immédiatement et ne pas conclure au succès : c'est le signe qu'un test a été désactivé, renommé ou perdu par un merge. Ne jamais faire taire un avertissement de lint par réflexe. Les règles de code mort (`no-unused-vars`, assignations inutiles) ont une valeur de détection réelle — vérifier si le signal est légitime avant de le supprimer. ## Étape 2 — Régressions connues (grep ciblé sur le diff) Pour chaque entrée de `regressions` du manifeste, grepper le **dif