Compétence d'Explication et de Test de Motifs Regex

--- name: regex-pattern-explainer-and-tester description: Explique les expressions régulières Python jeton par jeton, les teste sur des échantillons devant correspondre et ne devant pas correspondre avec les positions et les groupes nommés, et signale les motifs risqués : quantificateurs imbriqués provoquant un retour arrière catastrophique, [A-z], points non échappés, correspondances vides, et ancres manquantes, puis propose une réécriture plus sûre. À utiliser lorsque l'utilisateur demande "que fait cette regex ?", "pourquoi ne correspond-elle pas ?", ou "cette regex est-elle sûre ?". Inclut un vérificateur stdlib Python testé. --- # Expliqueur et Testeur de Motifs Regex Vous aidez les gens à comprendre, corriger et faire confiance aux expressions régulières. Vous expliquez un motif en termes simples, prouvez ce qu'il fait avec des cas de test réels, et trouvez les pièges qui font échouer les regex en production : entrées qui ne devraient pas passer, entrées qui devraient passer mais ne passent pas, et motifs qui bloquent sur des entrées longues. Vous renvoyez un motif corrigé avec un tableau de test, pas seulement une opinion. ## Fichiers dans cette compétence - `scripts/regex_check.py` - explique un motif à partir du propre analyseur regex de Python, exécute des entrées d'échantillon avec "+" (doit correspondre) et "-" (ne doit pas correspondre) comme attentes, et signale les risques HIGH, WARN et INFO ; `--probe` chronomètre le motif sur une entrée générée dans le pire des cas dans un sous-processus (bibliothèque standard Python 3 uniquement) - `references/regex-pitfalls.md` - chaque risque signalé par le vérificateur, pourquoi il est important, et le motif sûr à utiliser à la place - `references/flavor-differences.md` - comment Python `re` diffère de JavaScript, PCRE, Go RE2, .NET, Java, et POSIX grep, pour qu'une correction fonctionne là où l'utilisateur l'exécute - `templates/regex-review.md` - le rapport de revue à renvoyer - `examples/example-email-validation-review.md` - une revue travaillée d'un contrôle d'email qui bloque sur une entrée longue ## Flux de travail ### 1. Collecter les faits Demandez, ou supposez et dites-le : - Le motif exactement tel qu'écrit dans le code (chaîne brute ou littéral de chaîne échappé) et le langage ou l'outil qui l'exécute. - Ce qu'il doit accepter et ce qu'il doit rejeter : 4 à 10 exemples réels de chaque, y compris les cas limites (entrée vide, espaces, Unicode, entrée très longue). - Comment il est utilisé : valider une valeur entière (fullmatch), trouver la première correspondance (search), extraire toutes les correspondances (findall), ou remplacer. - D'où vient l'entrée. Une entrée non fiable (formulaires web, journaux, charges API) rend le retour arrière catastrophique un problème de sécurité. ### 2. Exécuter le vérificateur ```bash python3 scripts/regex_check.py 'MOTIF' -t 'échantillon un' -t 'échantillon deux' python3 scripts/regex_check.py 'MOTIF' --cases cas.txt --mode fullmatch --flags a python3 scripts/regex_check.py 'MOTIF' --probe --no-explain # confirmer un risque de retour arrière python3 scripts/regex_check.py 'MOTIF' --cases - --json < cas.txt ``` Un fichier de cas a un échantillon par ligne : `+ texte` doit correspondre, `- texte` ne doit pas correspondre, `# ...` est un commentaire. Toujours citer le motif entre guillemets simples dans le shell. Le vérificateur utilise `re` de Python ; pour d'autres saveurs, lisez `references/flavor-differences.md` et traduisez le résultat. Si vous ne pouvez pas exécuter le script, expliquez le motif à la main avec la même structure et appliquez `references/regex-pitfalls.md`. ### 3. Expliquer, puis corriger 1. Expliquez le motif de haut en bas en termes simples, une ligne par jeton ou groupe, en utilisant l'explication du vérificateur comme base. 2. Montrez le tableau de test : chaque échantillon, résultat attendu, résultat réel, et le texte correspondant ou les groupes. 3. Corrigez dans cet ordre : motifs qui peuvent bloquer (HIGH), acceptations erronées et rejets erronés (attentes échouées), puis la clarté et les notes INFO. 4. Préférez des réécritures simples et lisibles : une répétition au lieu de répétitions imbriquées, des classes niées comme `[^,]*` au lieu de `.*`, des ancres explicites `\A...\Z` ou `fullmatch`, et `re.VERBOSE` avec commentaires pour les motifs longs. 5. Relancez le vérificateur sur le motif corrigé avec les mêmes cas plus tout nouveau cas limite jusqu'à ce que chaque attente passe et qu'il n'y ait aucun risque HIGH. Exécutez `--probe` sur la correction si l'original avait un risque HIGH. ### 4. Livrer Remplissez `templates/regex-review.md` : l'explication en langage simple, le tableau de test avant et après, les risques trouvés, le motif corrigé dans le langage de l'utilisateur avec un échappement correct, et une courte liste de cas de test à conserver dans leur suite de tests. Suivez le style de `examples/example-email-validation-review.md`. ## Règles - Ne prétendez jamais qu'un motif est correct sans le montrer sur des cas de test ; ajoutez les cas limites que l'utilisateur a oubliés. - Ne survalidez pas : pour les emails, URL et noms, recommandez un contrôle de forme simple plus une étape de vérification réelle (envoi d'un email, analyse de l'URL) au lieu d'un motif géant. - Respectez la saveur de l'utilisateur : ne suggérez pas de lookbehind, de quantificateurs possessifs, ou de groupes atomiques là où leur moteur ne les prend pas en charge. - Échappez correctement pour le langage cible (chaînes brutes en Python, doubles barres obliques inverses en Java et chaînes C#, barres obliques dans les littéraux JavaScript). - Traitez le retour arrière catastrophique sur une entrée non fiable comme un bug de sécurité (ReDoS) et dites-le clairement ; suggérez des limites de longueur d'entrée comme seconde défense.