Behavior Validator: contrato, caixa-preta e evidência observável

ANÁLISE EDITORIAL

Uma validação pode parecer rigorosa e ainda assim confirmar apenas que o código está elegante. A Skill Behavior Validator propõe outro papel: testar o produto em execução sem abrir fonte, diff ou histórico Git, usando um contrato escrito antes do teste. O objetivo é verificar o que uma pessoa realmente consegue fazer em um aplicativo, CLI, API ou arquivo gerado, com evidência observável e sem aceitar uma mensagem de sucesso como prova suficiente.

O que esta Skill faz

A Behavior Validator organiza uma revisão de comportamento em modo caixa-preta. Primeiro, o agente lê um contrato que descreve objetivo, alvo, tarefas, resultados esperados, variações de entrada e evidências. Depois, usa apenas superfícies visíveis ao usuário ou ao operador, como navegador, comando de terminal, endpoint de API, arquivo produzido, log público, captura ou árvore de acessibilidade. O código que implementa o recurso fica fora do campo de visão.

Essa separação responde a uma pergunta simples: o produto funciona como prometido, independentemente de como foi construído? A Skill exige que cada cláusula termine como aprovada, reprovada, bloqueada ou fora de escopo. Também manda variar dados, repetir ações, testar entradas vazias ou inválidas e confirmar persistência. Assim, um botão que apenas exibe “concluído”, sem realizar a operação, tende a ser descoberto.

Para quem serve

Ela serve a equipes de produto, QA, desenvolvimento, suporte técnico, operações e revisores que precisam de uma segunda perspectiva sobre uma entrega. É útil depois de uma implementação, antes de aceitar uma correção, na conferência de uma automação, no teste de uma API ou na inspeção de um documento gerado. Também ajuda quando o código não pode ser compartilhado, mas existe acesso autorizado à execução.

O melhor cenário tem uma pessoa ou agente responsável pela implementação e outra sessão isolada para validar o comportamento. A segunda sessão recebe contrato, fixtures permitidas e forma de acesso, não recebe explicações internas. Isso reduz o risco de o revisor interpretar uma intenção do código como se fosse evidência do resultado.

Origem e curadoria

A Skill vem do repositório openclaw/agent-skills, apresentado pelo próprio projeto como fonte canônica de fluxos compartilhados usados em projetos OpenClaw. Em 10/09/2026, a API pública do GitHub registrava 1.082 estrelas para o repositório, que estava público, não arquivado e sob licença MIT. O número pertence ao repositório inteiro, não mede adoção isolada desta pasta.

A auditoria fixou o commit 567e63060e03503e965e91f0af06c5633be1221f e leu o conteúdo integral da pasta Behavior Validator. A pesquisa por nome e finalidade em GitHub, GitLab e Hugging Face não encontrou outra origem canônica para esta Skill. O catálogo do Bastidores também não tinha o mesmo repositório, caminho, nome, pacote ou finalidade.

Compatibilidade e limites

O pacote segue a estrutura de SKILL.md descrita no padrão Agent Skills e inclui um manifesto opcional para clientes OpenAI. Ele pode ser usado por agentes capazes de carregar Skills e operar a superfície indicada no contrato. O cliente ainda precisa oferecer navegador, terminal, chamada de API ou leitura de arquivo conforme o alvo.

A Skill não traz navegador, runner de testes, servidor, credenciais ou fixtures. Ela não inicia o produto por conta própria e não prova segurança, desempenho ou acessibilidade completa só porque um fluxo principal passou. Também não elimina variação de sistemas com IA. Seu valor está no método e na disciplina da evidência, não em um motor automático de verificação.

Pré-requisitos

• Um alvo autorizado e identificável: URL, comando, endpoint ou arquivo.
• Um ambiente de teste separado de produção sempre que houver mudança de estado.
• Contrato curto com tarefas, resultados observáveis, casos inválidos e evidência esperada.
• Fixtures sintéticas ou aprovadas, sem dados pessoais desnecessários.
• Credenciais fornecidas por ferramenta de segredo ou variável de ambiente exata, nunca copiadas para o relatório.
• Critérios para interromper o teste quando surgir risco, custo, efeito externo ou necessidade de inspecionar fonte.

Instalação com revisão

O download local desta página contém seis arquivos textuais: SKILL.md, LICENSE, ORIGEM.md, agents/openai.yaml e dois modelos na pasta references. Compare o SHA-256, extraia em uma pasta de revisão e leia tudo antes de copiar a Skill para o diretório aceito pelo agente. O ZIP não executa testes e não instala dependências.

Se preferir instalar da origem, clone o repositório, faça checkout do commit auditado e use o instalador documentado no README fixado. Evite apontar um ambiente estável diretamente para main, pois o ramo pode mudar depois da curadoria.

Escreva o contrato antes do teste

O contrato é a proteção contra uma revisão oportunista. Escreva o objetivo do ponto de vista do usuário, identifique a superfície, liste duas ou três tarefas concretas e diga o que deve aparecer, mudar ou persistir. Inclua também o comportamento esperado para dado vazio, inválido ou indisponível. O modelo original de contrato é curto de propósito.

Não escreva o contrato depois de ver o resultado. Isso permitiria ajustar a promessa ao que já funciona. Se o pedido original é ambíguo, registre a interpretação e os itens fora de escopo antes de testar. Uma cláusula boa é observável: “ao atualizar a página, o item criado continua na lista”. Uma cláusula ruim é interna: “o banco usa a tabela correta”.

Preserve o isolamento source-blind

Crie uma pasta temporária privada que contenha apenas contrato, fixtures autorizadas e evidências redigidas. Não copie source, diff, testes existentes, notas de implementação ou histórico Git. Se o aplicativo precisa ser iniciado a partir do checkout, faça isso em outro terminal e entregue ao validador apenas a URL ou o comando de acesso. O SKILL.md fixado chama acesso à implementação de contaminação.

Esse isolamento não é teatro. Um revisor que conhece a função, a variável ou o ticket tende a completar mentalmente lacunas da interface. Quando a fonte for indispensável para prosseguir, a saída correta é blocked_source_required. A revisão de código pode acontecer em outra etapa, com outro papel e outro relatório.

Primeiro uso seguro

Um primeiro pedido pode ser: “Use a Behavior Validator para conferir este formulário contra behavior-contract.md. Não leia arquivos do projeto. Acesse apenas a URL de teste, use os dados sintéticos indicados e registre evidência sem cookies ou dados pessoais”. O agente deve repetir as tarefas como uma pessoa real, não apenas verificar se elementos existem.

Para um aplicativo web, uma ferramenta como o Playwright pode ajudar a operar a interface, mas não substitui o contrato. Para uma API, a documentação oficial do curl ajuda a formar requisições reproduzíveis. Use somente ferramentas permitidas pelo ambiente e nunca amplie o alvo sem autorização.

Provas antiengano

A Skill chama de anti-cheat probes as variações que distinguem trabalho real de aparência. Troque o valor da fixture e verifique se o resultado acompanha a mudança. Atualize a página ou reabra o arquivo para conferir persistência. Use entrada vazia, limite e formato inválido. Repita uma ação para observar idempotência. Inspecione o arquivo gerado, não apenas a notificação de que ele foi criado.

Essas provas precisam seguir o risco do alvo. Não force falhas em produção e não dispare e-mails, cobranças ou exclusões para “ter certeza”. Em sistemas mutáveis, use ambiente de laboratório, destinatários controlados e dados descartáveis. O projeto oficial do OWASP Web Security Testing Guide reforça a importância de escopo e autorização em testes de aplicações.

Evidência sem vazar dados

Uma evidência deve permitir repetir o teste sem carregar material desnecessário. Registre alvo, horário, entrada sintética, passos, resultado observado e cláusula correspondente. Capturas, trechos de terminal e respostas de API precisam omitir tokens, cookies, chaves, nomes privados e conteúdo não relacionado. Nunca salve o valor de uma credencial apenas para tornar o relatório “completo”.

O schema JSON incluído separa alvo, verificações, provas antiengano e bloqueios. Ele é útil para orquestração, mas não garante qualidade por si só. Confiança numérica deve refletir a cobertura e a força da evidência, não decorar uma conclusão.

Resultado esperado

O resultado saudável é um relatório que identifica o alvo exercitado, o contrato usado, o resumo de passagens e falhas, os passos de reprodução, a evidência, as variações executadas e os bloqueios restantes. Cada cláusula relevante termina com um estado explícito. Uma falha observável não vira sugestão de estilo, e um bloqueio por acesso não vira reprovação do produto.

Quando a equipe corrige um achado, execute novamente as cláusulas afetadas e as provas vizinhas de regressão. Não é preciso repetir todo o universo de testes sem motivo. Ainda assim, uma correção em persistência pode afetar criação, edição e reabertura, então o reteste deve cobrir o caminho completo que sustenta a promessa.

Permissões e riscos

Os seis arquivos do pacote são texto e não realizam ações sozinhos. O risco nasce das superfícies usadas durante a validação. Um navegador pode enviar formulários e alterar contas. Uma CLI pode escrever arquivos ou acionar serviços. Uma API pode criar, atualizar ou remover registros. Um arquivo gerado pode conter informações privadas. Defina ações permitidas, volume, destino e condição de parada antes da execução.

Use contas de teste, menor privilégio e segredos temporários. Não coloque credenciais no contrato, prompt, screenshot ou JSON final. A Privacy Framework do NIST oferece uma referência oficial para organizar riscos de dados, mas as políticas da organização e a legislação aplicável continuam prevalecendo.

Erros comuns e como corrigir

O contrato descreve a implementação

Reescreva cada cláusula em termos de tarefa e resultado visível. Troque “chama o serviço X” por “depois do envio, o protocolo aparece e permanece após atualizar”.

O validador abriu o código para entender

Interrompa a sessão e marque contaminação. Se a fonte for realmente necessária, encaminhe a questão para revisão de código e mantenha o resultado comportamental como bloqueado.

A mensagem de sucesso foi aceita como prova

Verifique o efeito: reabra a tela, consulte o recurso, baixe o arquivo ou leia a resposta autorizada. Varie a entrada para confirmar que o resultado não é estático.

O teste não pode avançar por falta de acesso

Use blocked, registre exatamente o acesso, fixture ou ferramenta ausente e não invente um resultado. Falta de credencial não demonstra defeito.

O relatório contém dados sensíveis

Remova valores, regenere capturas redigidas e mantenha apenas identificadores sintéticos ou parciais. Se a exposição já ocorreu, siga o procedimento interno de incidente.

O que a revisão editorial confirmou

A pasta auditada contém o arquivo principal, dois modelos Markdown e um manifesto YAML. Não há scripts, binários, dependências ou chamadas de rede. A licença MIT permite redistribuir o material com o aviso preservado. O manifesto agents/openai.yaml define apenas nome, descrição curta e prompt padrão.

A revisão não executou a Skill contra um produto real, não testou todas as integrações possíveis e não certifica segurança ou qualidade. Confirmamos conteúdo, estrutura, referências, licença, commit, ausência de executáveis e finalidade distinta de revisão de código. A capa é uma ilustração conceitual, não evidência de uma execução.

Quando não usar

Não use a Behavior Validator para explicar a causa interna de um bug, revisar arquitetura, julgar qualidade de código ou localizar uma linha defeituosa. Esses trabalhos exigem acesso à implementação. Também não use o método para pentest fora de escopo, teste destrutivo, carga em produção ou coleta de dados privados sem autorização específica.

Se não existe superfície executável, o máximo possível pode ser revisar um artefato gerado ou marcar o teste como bloqueado. Se a decisão depende de gosto ou escolha de produto não registrada, classifique-a fora de escopo e peça que o responsável transforme a decisão em cláusula observável.

Versão, licença e pacote auditado

Origem: openclaw/agent-skills, pasta skills/behavior-validator, commit 567e63060e03503e965e91f0af06c5633be1221f, licença MIT. A Skill não declara versão própria; o commit é a referência reproduzível. O pacote local contém seis arquivos textuais, tem 5.690 bytes e SHA-256 ede4bf83342f19cc44525d9cf0e449a72b261648b3d60d3d53bbb85fa638eb21.

O botão de download entrega o espelho documental auditado. O botão do repositório abre a origem em nova aba. Eles são ações distintas. O ZIP não inclui produto, runner, código do alvo, fixtures, credenciais, contratos de usuários, evidências ou relatórios.

Checklist antes de avançar

• Fixei o commit e conferi os seis arquivos do pacote.
• Escrevi o contrato antes de observar o resultado.
• Defini alvo, ambiente, fixtures, ações permitidas e condição de parada.
• Separei a sessão de validação do código e do histórico da implementação.
• Planejei variação de dados, entrada inválida, repetição e persistência.
• Forneci segredos somente por mecanismo aprovado.
• Defini evidência compacta e redigida para cada cláusula.
• Distingo falha observável, bloqueio técnico e item fora de escopo.
• Obtive autorização antes de qualquer ação mutável ou externa.

Fontes oficiais consultadas

• SKILL.md fixado no GitHub.
• Modelo oficial de contrato de comportamento.
• Schema oficial do relatório.
• Licença MIT do repositório.
• Especificação do formato Agent Skills.