Guia da API Abilities do WordPress para fluxos de trabalho de IA

A API Abilities do WordPress pode expor capacidades tipadas e detectáveis, mas cada ability ainda precisa de metadados precisos, callbacks de permissão, validação de entrada, tratamento de saída e evidências de que a execução corresponde ao contrato publicado.

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: A API Abilities do WordPress pode expor capacidades tipadas e detectáveis, mas cada ability ainda precisa de metadados precisos, callbacks de permissão, validação de entrada, tratamento de saída e evidências de que a execução corresponde ao contrato publicado.

O que este guia ajuda você a realizar

Explique e documente um caminho seguro para registrar, descobrir e testar abilities do WordPress antes de expô-las a clientes de IA ou camadas de execução remota.

• Uma distinção clara entre a definição de uma ability, seu callback de execução e sua lógica de autorização.
• Uma lista de verificação de registro para metadados, esquemas, anotações e exposição REST.
• Uma matriz de permissões e testes negativos.
• Um contrato versionado para clientes e responsáveis pela manutenção.

O artefato final deve ser compreensível pela 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. Cada 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 é um desconhecido explícito ou uma hipótese testável.

Evidências e entradas a preparar

• A documentação atual da API Abilities do WordPress e a versão-alvo.
• A ação de negócio e a regra de permissão autoritativa.
• Esquemas de entrada e saída com fixtures seguras.
• Efeitos colaterais esperados, modos de falha e requisitos de observabilidade.
• O cliente ou adaptador que descobrirá ou executará a ability.

Antes de fornecer evidências a um assistente, remova credenciais, valores secretos e informações pessoais sem relação. Preserve os identificadores, as versões, os carimbos de data e hora, a localidade, as unidades e os 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 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, uma fixture isolada ou evidências exportadas e não exige acesso de produção ao WordPress.

Uma ability é um contrato, não um prompt

Seu nome, descrição, esquemas, anotações e callbacks definem uma operação invocável por máquina. A clareza em linguagem natural importa, mas a validação executável e as verificações de permissão continuam sendo autoritativas.

Detectável não significa executável por todos

Listar metadados e executar uma ability são operações distintas. A autorização deve ser aplicada no limite de execução.

As anotações não devem prometer demais

As afirmações sobre comportamento somente leitura, efeitos destrutivos ou idempotência devem refletir a implementação testada, não apenas a intençã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 segundo 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. Defina uma capacidade de negócio restrita e seu proprietário responsável.
2. Especifique nomenclatura estável, descrição, esquema de entrada, esquema de saída e efeitos colaterais.
3. Implemente callbacks explícitos de permissão e validação.
4. Registre a ability no ciclo de vida e ambiente compatíveis.
5. Teste a descoberta, a execução válida, a entrada inválida e a execução não autorizada.
6. Revise se a exposição REST ou MCP é apropriada e compatível.
7. Documente versionamento, erros, observabilidade e comportamento de rollback.
8. Exponha a ability somente depois que o contrato e os testes negativos forem aprovados.

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 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 ou informações pessoais sem relação.

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

Objetivo:
Explique e documente um caminho seguro para registrar, descobrir e testar abilities do WordPress antes de expô-las a clientes de IA ou camadas de execução remota.

Retorne os seguintes campos:
- Nome da ability
- Finalidade
- Esquema de entrada
- Esquema de saída
- Callback de permissão
- Efeito colateral
- Anotação
- Fixture válida
- Fixture inválida
- Fixture não autorizada
- Versão
- Proprietário

Regras:
1. Use nomes e assinaturas atuais da API oficial.
2. Não registre abilities gerais que aceitem tudo.
3. Exija callbacks explícitos de permissão e validação de entrada.
4. Teste descrições e anotações em relação ao comportamento real.
5. Não exponha uma ability a REST ou MCP por suposição.

Para cada descoberta:
- identifique a fonte, o registro, a URL, o arquivo, a linha, o ID de 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 desta forma

O prompt cria um contrato de evidências antes de pedir recomendações. Ele torna visíveis os dados ausentes, 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 tornam mais fácil comparar execuções repetidas ou entregar um subconjunto aprovado a um fluxo de trabalho 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 efetivamente usado.

O que deve permanecer fora desta tarefa

• Registro de ability em produção
• Capacidade administrativa ampla
• Contorno de permissão
• Alterações de esquema não validadas
• Alegações de compatibilidade universal com clientes

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 necessária mais restrita.

Como o WP Agent Control se encaixa

A pasta privada guiada para Claude Code ou Codex usa REST do WordPress e uma senha de aplicativo com perfil dedicado somente para leitura. Os perfis existentes Read Only, Draft, Content Editor e Publisher permanecem nas opções avançadas. Não são convertidos automaticamente para OAuth nem recebem o modelo remoto de tarefas e aprovação exata.

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.
• ☐ Cada observação material 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.
• ☐ As evidências ausentes e os limites de cobertura permanecem visíveis.
• ☐ A identidade analítica ou de pesquisa não realizou mutação proibida.
• ☐ Um proprietário qualificado revisou implicações de segurança, acessibilidade, jurídicas, 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 revogadas, redefinidas ou descartadas após a tarefa.

Modos de falha comuns

• Ability em forma de prompt: uma operação ampla aceita instruções arbitrárias e contorna o design explícito de capacidades.
• Autorização por metadados: a descrição da ability diz que é restrita, mas o callback de execução não aplica a restrição.
• Deriva de esquema: a implementação aceita ou retorna campos que o contrato publicado não descreve.
• Rotulagem incorreta de somente leitura: uma ability anotada como somente leitura aciona gravações, caches, e-mails ou chamadas externas ocultas.

Uma falha recorrente e transversal é 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, compatível ou segura. Isso destrói o valor probatório da recusa e torna difícil atribuir resultados posteriores.

Nota avançada

Em uma arquitetura governada, abilities são operações admissíveis cujos metadados, permissões e efeitos colaterais são versionados independentemente do transporte. REST ou MCP podem projetar a mesma ability, mas nenhum transporte pode ampliar sua autoridade.

Guias relacionados

• Como expor uma Ability personalizada do WordPress por MCP
• Como criar uma matriz de testes de permissões do WordPress para agentes de IA
• Como documentar uma API REST do WordPress com IA
• 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.