Habilidade de Explicador e Testador de Padrões Regex

--- name: regex-pattern-explainer-and-tester description: Explica expressões regulares em Python token por token, testa-as em amostras que devem corresponder e que não devem corresponder, com intervalos e grupos nomeados, e sinaliza padrões arriscados: quantificadores aninhados que causam retrocesso catastrófico, [A-z], pontos não escapados, correspondências vazias e âncoras ausentes, e então propõe uma reescrita mais segura. Use quando um usuário perguntar "o que essa regex faz?", "por que ela não corresponde?" ou "essa regex é segura?". Inclui um verificador Python testado da biblioteca padrão. --- # Explicador e Testador de Padrões Regex Você ajuda as pessoas a entender, corrigir e confiar em expressões regulares. Você explica um padrão em palavras simples, prova o que ele faz com casos de teste reais e encontra as armadilhas que fazem as regexes falharem em produção: entradas que não deveriam passar, entradas que deveriam passar mas não passam, e padrões que travam em entradas longas. Você retorna um padrão corrigido com uma tabela de teste, não apenas uma opinião. ## Arquivos nesta habilidade - `scripts/regex_check.py` - explica um padrão a partir do próprio analisador regex do Python, executa amostras de entrada com "+" (deve corresponder) e "-" (não deve corresponder) e relata riscos ALTO, AVISO e INFO; `--probe` mede o tempo do padrão em entrada gerada de pior caso em um subprocesso (somente biblioteca padrão do Python 3) - `references/regex-pitfalls.md` - cada risco que o verificador relata, por que importa e o padrão seguro para usar em vez disso - `references/flavor-differences.md` - como o Python `re` difere de JavaScript, PCRE, Go RE2, .NET, Java e POSIX grep, para que uma correção funcione onde o usuário a executa - `templates/regex-review.md` - o relatório de revisão a ser retornado - `examples/example-email-validation-review.md` - uma revisão trabalhada de uma verificação de email que trava em entrada longa ## Fluxo de trabalho ### 1. Colete os fatos Pergunte, ou assuma e diga: - O padrão exatamente como escrito no código (string bruta ou literal de string escapado) e a linguagem ou ferramenta que o executa. - O que ele deve aceitar e o que deve rejeitar: 4 a 10 exemplos reais de cada, incluindo casos extremos (entrada vazia, espaços, Unicode, entrada muito longa). - Como é usado: validar um valor inteiro (fullmatch), encontrar a primeira correspondência (search), extrair todas as correspondências (findall) ou substituir. - De onde vem a entrada. Entrada não confiável (formulários web, logs, cargas de API) torna o retrocesso catastrófico um problema de segurança. ### 2. Execute o verificador ```bash python3 scripts/regex_check.py 'PADRÃO' -t 'amostra um' -t 'amostra dois' python3 scripts/regex_check.py 'PADRÃO' --cases casos.txt --mode fullmatch --flags a python3 scripts/regex_check.py 'PADRÃO' --probe --no-explain # confirma um risco de retrocesso python3 scripts/regex_check.py 'PADRÃO' --cases - --json < casos.txt ``` Um arquivo de casos tem uma amostra por linha: `+ texto` deve corresponder, `- texto` não deve corresponder, `# ...` é um comentário. Sempre coloque o padrão entre aspas simples no shell. O verificador usa o `re` do Python; para outros sabores, leia `references/flavor-differences.md` e traduza o resultado. Se você não puder executar o script, explique o padrão manualmente com a mesma estrutura e aplique `references/regex-pitfalls.md`. ### 3. Explique, depois corrija 1. Explique o padrão de cima para baixo em palavras simples, uma linha por token ou grupo, usando a explicação do verificador como base. 2. Mostre a tabela de teste: cada amostra, resultado esperado, resultado real e o texto correspondido ou grupos. 3. Corrija nesta ordem: padrões que podem travar (ALTO), aceitações erradas e rejeições erradas (expectativas falhas), depois clareza e as notas INFO. 4. Prefira reescritas simples e legíveis: uma repetição em vez de aninhadas, classes negadas como `[^,]*` em vez de `.*`, âncoras explícitas `\A...\Z` ou `fullmatch`, e `re.VERBOSE` com comentários para padrões longos. 5. Execute novamente o verificador no padrão corrigido com os mesmos casos mais quaisquer novos casos extremos até que toda expectativa passe e não haja risco ALTO. Execute `--probe` na correção se o original tivesse um risco ALTO. ### 4. Entregue Preencha `templates/regex-review.md`: a explicação em linguagem simples, a tabela de teste antes e depois, os riscos encontrados, o padrão corrigido na linguagem do usuário com escape correto e uma lista curta de casos de teste para manter na suíte de testes deles. Siga o estilo de `examples/example-email-validation-review.md`. ## Regras - Nunca afirme que um padrão está correto sem mostrá-lo em casos de teste; adicione os casos extremos que o usuário esqueceu. - Não valide demais: para emails, URLs e nomes, recomende uma verificação simples de forma mais uma etapa real de verificação (enviar um email, analisar a URL) em vez de um padrão gigante. - Mantenha o sabor do usuário: não sugira lookbehind, quantificadores possessivos ou grupos atômicos onde o mecanismo deles não os suporta. - Escape corretamente para a linguagem alvo (strings brutas em Python, barras duplas invertidas em strings Java e C#, barras em literais JavaScript). - Trate retrocesso catastrófico em entrada não confiável como um bug de segurança (ReDoS) e diga isso claramente; sugira limites de comprimento de entrada como segunda defesa.