Click-Path Audit

Sélectionné par Skill Harbor : un audit comportemental des flux qui trouve les bugs que la lecture statique du code rate. Le débogage traditionnel vérifie si la fonction existe, si elle plante, si les types concordent. Il ne vérifie jamais si l'état final de l'UI correspond à ce que promet le libellé du bouton, si la fonction B annule silencieusement ce que la fonction A vient de faire, ou si l'état partagé a des effets de bord qui annulent l'action voulue. L'exemple déclencheur : un bouton « New Email » appelait setComposeMode(true) puis selectThread(null) ; chacun marchait isolément, mais selectThread avait un effet de bord qui remettait composeMode à false, donc le bouton ne faisait rien, et 54 autres bugs trouvés par débogage systématique l'avaient raté. La méthode : d'abord cartographier chaque action du store d'état vers ce qu'elle définit et ce qu'elle réinitialise silencieusement (la référence critique), puis auditer chaque handler de point de contact appel par appel dans l'ordre, en vérifiant six modèles : annulation séquentielle, courses async, closures périmées, transitions d'état manquantes (le bouton dit « Sauvegarder » mais rien ne sauvegarde), chemins morts conditionnels, et interférence useEffect. Chaque trouvaille reçoit une sévérité, la trace exacte avec l'appel en conflit marqué, l'état attendu versus réel, et un correctif précis. Inclut un guide de cadrage (audits appli complète, page unique, ou centrés sur un store, avec répartition d'agents parallèles recommandée) et se positionne après le débogage systématique et avant la vérification. À utiliser quand le débogage systématique n'a trouvé « aucun bug » mais que les utilisateurs signalent des boutons cassés, après modification d'un store d'état partagé, après des refactors qui touchent l'état partagé, ou avant release sur les flux critiques. Par @affaan-m, listé ici avec crédit à son créateur. Tiré du dépôt affaan-m/ECC (MIT). Bémols honnêtes : l'audit coûte cher, cadrez-le délibérément ; les exemples penchent Zustand et React, adaptez l'étape de cartographie à votre solution d'état ; il trouve les bugs d'interaction, pas les problèmes d'API ou de style. Skill Harbor ne vérifie jamais le code, examinez-le vous-même avant usage.