Como criar uma matriz de testes de permissões do WordPress para agentes de IA

Uma matriz de permissões deve comprovar as ações do WordPress permitidas e recusadas para cada identidade de IA, não apenas listar funções pretendidas ou demonstrar uma solicitação bem-sucedida.

A IA é mais útil aqui como organizadora de evidências, mecanismo de comparação e assistente de redação. Ela pode tornar uma tarefa complexa do WordPress 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: uma matriz de permissões deve comprovar as ações do WordPress permitidas e recusadas para cada identidade de IA, não apenas listar funções pretendidas ou demonstrar uma solicitação bem-sucedida.

O que este guia ajuda você a realizar

Crie uma matriz executável que conecte identidades, capacidades, objetos, estados e resultados esperados a evidências positivas e negativas reproduzíveis.

• Uma matriz de permissões por identidade e ação com respostas esperadas exatas.
• Fixtures positivos, negativos, de propriedade de objeto e de transição de estado.
• Uma distinção entre falha de autenticação, negação de autorização, falha de validação e capacidade não suportada.
• Uma suíte de regressão para modos protegidos e capacidades personalizadas.

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 basta. Toda conclusão material 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 é uma incógnita explícita ou uma hipótese testável.

Evidências e entradas a preparar

• Os contratos atuais de cobertura de funções, capacidades e WP Agent Control.
• Rotas REST ou capacidades registradas e seus callbacks de permissão.
• Usuários de teste dedicados e fixtures seguros do WordPress.
• Resultados esperados no nível de HTTP, ferramenta ou aplicativo.
• Um plano de redefinição limpa do ambiente e retenção de evidências.

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 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 continuam proibidas. A etapa de planejamento ou pesquisa deve usar um repositório local, fixture isolado ou evidências exportadas e não exige acesso ao WordPress de produção.

A intenção da função não é evidência de permissão

A matriz deve exercitar o endpoint, a capacidade ou a ação real do WordPress no estado de objeto relevante.

Uma negação precisa de classificação

401, 403, erros de validação e operações não suportadas têm significados diferentes. Registrar somente “falhou” oculta o controle realmente testado.

Objeto e estado importam

Uma identidade pode editar seu próprio rascunho, mas não a publicação de outro autor, ou atualizar um rascunho, mas não uma página publicada. Teste os limites relevantes.

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 ou próxima ação proposta.
4. Autorizado e verificado: uma alteração aprovada separadamente, executada e então verificada em relação aos critérios de aceitação.

A saída de IA normalmente começa nos três primeiros estados. Ela não se torna autorizada apenas por ser 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. Inventarie identidades, perfis, rotas, capacidades, objetos e estados.
2. Defina o resultado esperado de permitir ou negar e a justificativa para cada célula material.
3. Crie fixtures isolados com IDs estáveis e procedimentos de redefinição.
4. Execute casos permitidos e retenha evidências exatas da solicitação e do resultado.
5. Execute casos proibidos, malformados e fora do escopo.
6. Investigue toda divergência sem ampliar permissões para fazer o teste passar.
7. Adicione casos verificados à cobertura de regressão automatizada quando prático.
8. Publique somente uma matriz sanitizada e revogue identidades temporárias.

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

Receita de prompt

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

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

Objetivo:
Crie uma matriz executável que conecte identidades, capacidades, objetos, estados e resultados esperados a evidências positivas e negativas reproduzíveis.

Retorne os seguintes campos:
- Identidade
- Perfil
- Objeto
- Estado
- Ação
- Rota ou capacidade
- Resultado esperado
- Status esperado
- Resultado observado
- Evidência
- Disposição
- Versão

Regras:
1. Use identidades de teste dedicadas e fixtures que não sejam de produção.
2. Teste ações permitidas e proibidas.
3. Preserve classes de resposta exatas e corpos de erro após a sanitização.
4. Não reinterprete uma negação inesperada como permissão para conceder mais acesso.
5. Não publique credenciais ou detalhes sensíveis de endpoint.

Para cada descoberta:
- 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 incógnita;
- informe 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 ferramenta 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 obrigató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 do produto instalada, do contrato de cobertura publicado e do método de conexão realmente utilizado.

O que deve permanecer fora desta tarefa

• Alterações de permissão
• Recurso a Full Power
• Testes de produção
• Reescrita de resultados esperados após a execução
• Garantias de segurança não suportadas

Uma ação recusada pode ser 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, população, período, ambiente e decisão são explícitos.
• ☐ Cada observação material está vinculada a evidência exata ou rotulada como hipótese.
• ☐ IDs, URLs, versões, datas, unidades, localidades e denominadores estáveis são preservados.
• ☐ Evidências ausentes e limites de cobertura permanecem visíveis.
• ☐ A identidade analítica ou de pesquisa não realizou mutação proibida.
• ☐ Um responsável qualificado revisou implicações de segurança, acessibilidade, legais, comerciais ou de lançamento quando aplicável.
• ☐ Toda 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

• Demonstração apenas de sucesso: a matriz prova que uma ação funciona, mas nunca que ações proibidas falham.
• Proxy de nome de função: resultados esperados são copiados de rótulos de função sem testar capacidades filtradas ou personalizadas.
• Contaminação de fixture: um teste muda o estado do objeto e invalida resultados posteriores.
• Achatamento de negações: todas as falhas são tratadas como equivalentes, ocultando defeitos de autenticação ou validação.

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 resultados posteriores difíceis de atribuir.

Nota avançada

Uma matriz de permissões governada pode ser gerada a partir do grafo de autoridade declarado, mas a declaração continua sendo apenas uma expectativa até que evidências executadas confirmem cada célula material. Permissões inesperadas são defeitos; negações esperadas são prova do produto.

Guias relacionados

• Qual nível de acesso ao WordPress você deve dar a uma IA?
• Guia da API Abilities do WordPress para fluxos de trabalho de IA
• Como expor uma Ability personalizada do WordPress por MCP
• Como criar um plano de testes do WordPress com IA

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.