fswp-qa-engineer

FSWP QA Engineer

Verifique a pasta construída, não corrija durante a verificação. Reporte primeiro, depois corrija no loop de correção do roteador.

1. Porta mecânica

bash scripts/setup_toolchain.sh              # uma vez por ambiente (somente apt + GitHub, sem Composer)
bash scripts/run_gate.sh <dir> [min-php] [--fix]

run_gate.sh detecta um tema (um style.css com um cabeçalho "Theme Name") e executa scripts/theme_check.py; caso contrário, executa scripts/qa_check.py. Ambos usam apenas a biblioteca padrão do Python e sempre funcionam. Em seguida, adiciona, onde PHP e as ferramentas existem: php -l, PHPCS WordPress-Extra (erros falham, avisos são listados), compatibilidade com a versão mínima de PHP e PHPStan nível 5 com stubs do WordPress.

• --fix executa phpcbf (padrão WordPress) primeiro. Use após scaffolding e após grandes edições; revise o diff.
• Plugin Check precisa de uma instalação do WordPress e da linha de comando (wp plugin check <slug>); NÃO É EXECUTADO em outros lugares. Diga ao usuário para executá-lo antes de enviar um plugin ao WordPress.org. Para temas, o equivalente é o plugin Theme Check ou a revisão automatizada do diretório.
• theme_check.py <dir> [--directory]: sem a flag, defeitos reais FALHAM e regras apenas de diretório AVISAM; com --directory, os requisitos do Diretório de Temas do WordPress.org FALHAM (cabeçalhos ausentes, tamanho e proporção da captura de tela, arquivos não permitidos, código de território de plugins, chamadas obrigatórias de tema clássico).
• qa_check.py também verifica regras de cabeçalho de plugin e readme do manual (comprimento da descrição, URI do plugin único, no máximo 5 tags, nenhum Stable tag: trunk, Tested up to numérico, comprimento da descrição curta) como avisos.
• qa_check.py impõe, para plugins: guards ABSPATH, correspondência de versão (cabeçalho, constante, Stable tag do readme), nenhum example.com ou CDN ou fontes hospedadas, permission_callback em cada rota com __return_true comentado, verificação de atualização de banco de dados, enfileiramento dentro de callbacks, funções banidas, guard de desinstalação, unidades somente com rem, traduções JS, fonte enviada com saída compilada, licenças de fonte. theme_check.py verifica o cabeçalho, licença, templates de entrada, validade do theme.json, funções banidas, heurística de echo sem escape, ativos remotos, domínio de texto, captura de tela e readme.

Regra de relatório: cada verificação é PASS, FAIL ou NOT RUN, com as versões das ferramentas usadas. NOT RUN nunca é uma aprovação e nunca é resumido como "limpo". Se PHP ou uma ferramenta estiver ausente, informe e nomeie o comando que a executaria.

1a. Verificação de escopo

Compare o diff ou a lista de arquivos com o resumo aprovado. Arquivos, hooks, opções ou dependências que o plano não solicitou são relatados como "scope creep" (veja fswp-developer/references/lean-coding.md). Conte as linhas adicionadas versus removidas e comente sobre a desproporção.

2. Lista de verificação manual

references/checklist.md: apenas os itens que um script não pode julgar. Execute-a após a porta mecânica estar verde.

3. Testes de cenário

Cada cenário numerado no PRD (fswp-architect) recebe PASS, FAIL ou NOT RUN com evidências. Sempre inclua:

• Instalação limpa sem opções ou tabelas anteriores: sem notificações ou fatais.
• Desativar e depois reativar: sem agendamentos ou opções duplicadas.
• Atualização a partir de dados armazenados de uma versão anterior sem reativar: esquema e opções migram no carregamento.
• Desinstalação: apenas dados de propriedade do plugin são removidos.
• Modo de migração: exporte diffs e a porta de regressão visual contra baseline/ (fswp-architect).

Por tipo de trabalho, adicione:

• Tema: cada tipo de template que o PRD lista é renderizado com conteúdo real e com conteúdo vazio; editor e front-end correspondem; navegação apenas por teclado funciona; trocar de tema e voltar não deixa fatal.
• Atualização: cada item na lista de paridade do resumo de alteração é verificado novamente e marcado; a atualização a partir de dados armazenados da versão anterior funciona; nada fora do resumo mudou (diff lido).
• Complemento: host ativo e dentro do intervalo (funciona); host inativo (complemento fica quieto, mostra um aviso, sem fatal); host abaixo da versão suportada (recusa limpa).
• Patch do core: a reprodução do ticket falha antes e passa depois; o grupo PHPUnit relevante passa; PHPCS limpo nas linhas alteradas; veja fswp-core-contributor.

Onde PHP puder ser executado, exercite a lógica de ativação e migração com um pequeno script PHP; caso contrário, rastreie lendo e rotule como "rastreado, não executado".

4. Verificação de lançamento

Depois de tudo acima estar verde: references/release-check.md.

Saída

Uma tabela: verificação | PASS/FAIL/NOT RUN | detalhe. Em seguida, lista de FAIL com arquivo e linha, depois o que o usuário deve executar manualmente. Para builds de várias sessões, copie a tabela para dentro de HANDOFF.md.