Como revisar código de plugin WordPress com IA

A IA pode ajudar a inspecionar código de plugin WordPress, mas conclusões sobre segurança, capacidades, migração de dados e lançamento exigem evidências exatas do repositório, testes de execução e mantenedores responsáveis.

A IA é mais útil aqui como organizadora de evidências, mecanismo de comparação e assistente de redação. Ela pode tornar uma tarefa WordPress complexa mais fácil de inspecionar, mas não pode criar autoridade ausente, certificar fatos que não observou nem converter silenciosamente uma recomendação em permissão para agir.

Em uma frase: A IA pode ajudar a inspecionar código de plugin WordPress, mas conclusões sobre segurança, capacidades, migração de dados e lançamento exigem evidências exatas do repositório, testes de execução e mantenedores responsáveis.

O que este guia ajuda você a realizar

Crie um pacote de revisão de plugin que rastreie hooks, permissões, entradas, armazenamento, chamadas de saída, atualizações e comportamento de desinstalação antes que qualquer correção ou lançamento seja aprovado.

• Um mapa de arquitetura de pontos de entrada, hooks, endpoints, trabalhos agendados e armazenamentos de dados.
• Um registro de achados com referência de linha e status das evidências.
• Uma revisão de permissões, privacidade, atualização e desinstalação.
• Uma fila de remediação e lançamento apoiada por testes.

O artefato final deve ser compreensível para a pessoa responsável pela decisão e reproduzível por alguém que não participou do prompt original. Uma resposta fluente não é suficiente. Toda conclusão relevante precisa de uma fonte, um escopo e um caminho de verificação. Quando as evidências não podem estabelecer algo, a saída correta é um desconhecido explícito ou uma hipótese testável.

Evidências e entradas a preparar

• O commit exato do plugin e o pacote distribuível.
• Bloqueios de dependências do Composer, npm e dependências incluídas.
• Versões compatíveis do WordPress e PHP.
• Esquema do banco de dados, rotinas de atualização, endpoints REST e verificações de capacidade.
• Testes existentes, saída do Plugin Check e comportamento documentado do produto.

Antes de fornecer evidências a um assistente, remova credenciais, valores secretos e informações pessoais não relacionadas. Preserve os identificadores, versões, carimbos de data e hora, localidade, unidades e rótulos de fonte necessários para interpretar o que resta. Uma captura de tela sem URL, estado ou data pode ser um contexto útil, mas raramente é autoridade suficiente para uma decisão de produção.

Não comece com uma solicitação ampla como “revise isto”, “corrija isto” ou “melhore isto”. Defina a decisão que o trabalho deve apoiar, a população incluída, a fonte que é autoritativa para cada campo, as operações permitidas e as ações que permanecem proibidas. A etapa de planejamento ou pesquisa deve usar um repositório local, um fixture isolado ou evidências exportadas e não exige acesso ao WordPress de produção.

O repositório e o pacote de lançamento podem ser diferentes

Ativos gerados, bibliotecas incluídas, arquivos de desenvolvimento excluídos e artefatos de build obsoletos podem fazer um pacote se comportar de modo diferente da árvore revisada.

Verificações de capacidade pertencem aos limites de ação

Uma restrição de menu ou controle oculto não prova que um endpoint REST, uma ação AJAX ou um trabalho em segundo plano imponha autorização.

Código de atualização é código de produção

Migrações executadas raramente podem alterar ou perder dados. Elas precisam de fixtures específicos da versão, verificações de idempotência e planejamento de reversão.

Mantenha observação, inferência e autoridade separadas

Uma revisão controlada deve distinguir pelo menos quatro estados:

1. Observado: presente diretamente em um registro, arquivo, resposta, página renderizada ou teste executado nomeado.
2. Inferido: uma interpretação plausível apoiada por evidências, mas não estabelecida diretamente.
3. Recomendado: uma decisão humana proposta ou próxima ação.
4. Autorizado e verificado: uma alteração aprovada separadamente, executada e então conferida contra critérios de aceitação.

A saída da IA geralmente começa nos três primeiros estados. Ela não se torna autorizada apenas porque é detalhada, internamente consistente ou tecnicamente convincente. Preserve essa distinção em tabelas, relatórios, tickets e estudos de caso públicos.

Um fluxo de trabalho seguro

1. Congele o commit de origem, o hash do pacote e a matriz de versões compatíveis.
2. Faça o inventário de hooks, pontos de entrada, capacidades, entradas, saídas, armazenamento e chamadas externas.
3. Execute ferramentas de codificação, dependências e Plugin Check, mantendo as saídas brutas.
4. Peça à IA para criar achados vinculados a evidências e identificar cobertura de testes ausente.
5. Reproduza achados de alto risco em fixtures isolados.
6. Revise as implicações de segurança, privacidade, licenciamento e contrato do produto com os responsáveis.
7. Prepare patches mínimos e testes em uma branch autorizada separada.
8. Gere um pacote novo e verifique os caminhos de instalação, atualização, ativação, desativação e desinstalação.

Essa sequência coloca deliberadamente uma revisão responsável entre a análise e a implementação. Se uma etapa posterior precisar de acesso mais amplo, crie uma nova tarefa, uma nova identidade ou uma alteração explícita de permissão. Não atualize silenciosamente a identidade analítica porque ela atingiu um limite correto.

Receita de prompt

Substitua cada valor entre colchetes antes de usar o prompt. Não cole senhas, chaves de API, cookies de autenticação, registros privados de clientes ou informações pessoais não relacionadas.

Você está revisando [TASK SCOPE] para [SITE, REPOSITORY OR DATASET] usando apenas as evidências fornecidas.

Objetivo:
Criar um pacote de revisão de plugin que rastreie hooks, permissões, entradas, armazenamento, chamadas de saída, atualizações e comportamento de desinstalação antes que qualquer correção ou lançamento seja aprovado.

Retorne os seguintes campos:
- ID do achado
- Arquivo e linha
- Ponto de entrada
- Autoridade da entrada
- Verificação de capacidade
- Efeito nos dados
- Efeito externo
- Reprodução
- Justificativa da gravidade
- Teste
- Correção
- Impacto do lançamento

Regras:
1. Use as versões exatas da origem e do pacote.
2. Não infira proteção de endpoint a partir da visibilidade da UI administrativa.
3. Separe cheiro de código, defeito, vulnerabilidade e incompatibilidade com o contrato do produto.
4. Preserve a saída bruta de ferramentas e as classificações de falsos positivos.
5. Não modifique nem lance o plugin durante a revisão.

Para cada achado:
- identifique a fonte, o registro, a URL, o arquivo, a linha, o ID do objeto, o estado ou a linha do conjunto de dados exatos;
- preserve datas, versões, unidades, localidade, identificadores e denominadores;
- separe observação, inferência, recomendação e desconhecido;
- declare quais evidências não estavam disponíveis;
- não altere WordPress, código-fonte, dados comerciais, análises, sistemas externos ou conteúdo publicado.

Por que este prompt é estruturado dessa forma

O prompt cria um contrato de evidências antes de pedir recomendações. Ele torna dados ausentes visíveis, reduz a chance de um modelo completar um registro incompleto com prosa plausível e produz uma saída que pode ser revisada sistematicamente. Campos estruturados também facilitam comparar execuções repetidas ou entregar um subconjunto aprovado a um fluxo de implementação posterior.

Uma implementação de produção pode adicionar esquema JSON, entradas de ferramentas tipadas ou validação automatizada. Esses mecanismos melhoram a consistência, mas não estabelecem que as evidências de origem sejam verdadeiras, completas ou atuais. A revisão humana e a verificação específica do sistema continuam necessárias.

Limite de acesso recomendado

Use Nenhum acesso ao WordPress durante a etapa de planejamento ou pesquisa para a etapa descrita neste guia. As capacidades exatas disponíveis para uma identidade devem vir da versão instalada do produto, do contrato de cobertura publicado e do método de conexão realmente usado.

O que deve permanecer fora desta tarefa

• Aplicação automática de patches
• Migração de banco de dados de produção
• Recuperação de segredos
• Alegações de vulnerabilidade não verificadas
• Envio a diretório ou lançamento

Uma ação recusada pode ser uma evidência útil de que o limite de controle está funcionando. Não responda a uma recusa esperada concedendo uma conta ampla de administrador ou Full Power. Primeiro determine se a ação pertence ao mandato atual. Se pertencer, crie uma etapa autorizada separadamente com a capacidade mais restrita necessária.

Como o WP Agent Control se encaixa

Este é um fluxo geral de WordPress, sem prometer que o Agent Control edite todos os objetos ou integrações abordados. No fluxo guiado, comece pelas páginas públicas. Operações de plugins, temas, usuários, configurações, arquivos, exclusão, WooCommerce, ACF e construtores não são tarefas guiadas nativas. Use ferramentas e permissões avaliadas separadamente quando necessário.

Obtenha informações estruturadas do site e inspecione páginas publicadas selecionadas após conectar. Essa leitura pública não exige tarefa temporária. Você também pode visitar páginas públicas sem o plugin; o Agent Control acrescenta acesso estruturado e continuidade para o trabalho autorizado no WordPress.

Conectar sua IA: docs first profile · Ver recursos e compatibilidade: coverage

Lista de verificação

• ☐ A tarefa, a população, o período, o ambiente e a decisão são explícitos.
• ☐ Toda observação relevante está vinculada a evidências exatas ou rotulada como hipótese.
• ☐ IDs estáveis, URLs, versões, datas, unidades, localidades e denominadores são preservados.
• ☐ Evidências ausentes e limites de cobertura permanecem visíveis.
• ☐ A identidade analítica ou de pesquisa não executou mutação proibida.
• ☐ Um responsável qualificado revisou implicações de segurança, acessibilidade, legais, comerciais ou de lançamento quando aplicável.
• ☐ Qualquer implementação tem mandato, nível de acesso, backup e plano de verificação separados.
• ☐ Identidades temporárias, fixtures e evidências sensíveis são revogados, redefinidos ou descartados após a tarefa.

Modos de falha comuns

• Revisão de caminho feliz: A instalação funciona, mas os caminhos de atualização, multisite, falha e desinstalação não são testados.
• Substituição por nonce: Um nonce é tratado como autorização mesmo quando a ação também precisa de uma verificação de capacidade.
• Invisibilidade de dependência: Código incluído ou compilado é omitido da revisão apesar de ser enviado aos usuários.
• Limpeza agressiva: A desinstalação remove dados compartilhados ou pertencentes ao usuário sem um contrato claro.

Uma falha transversal recorrente é a deriva de permissões: a tarefa inicial encontra um limite, e o operador amplia o acesso antes de determinar se a operação ausente é necessária, suportada ou segura. Isso destrói o valor probatório da recusa e torna os resultados posteriores difíceis de atribuir.

Nota avançada

Uma revisão de plugin governada pode vincular achados aos hashes da origem e do pacote, possibilitando provar se um ZIP lançado realmente contém a implementação e os testes revisados.

Guias relacionados

• Como criar um plano de testes do WordPress com IA
• Como revisar um pacote de lançamento do WordPress com IA
• Como criar uma matriz de testes de permissões do WordPress para agentes de IA
• Como preparar com IA um plano de alteração do WordPress pronto para reversão

Próxima etapa

Continue com o guia de apoio mais relevante e use o guia de níveis de acesso antes de qualquer tarefa autenticada. Quando o acesso temporário ao WordPress não for mais necessário, conclua revogando a identidade.