Protocolo de IA

Um pedido precisa caber em uma verificação

Uma inteligência artificial pode produzir uma proposta convincente sem ter lido o estado atual, executado o teste ou percebido um contrato importante. O protocolo organiza o trabalho para que essas diferenças apareçam. Ler e inventariar estabelece o que existe; propor estabelece a intenção; implementar altera artefatos; testar produz observações; comparar confronta o resultado com o objetivo. Nenhuma dessas etapas pode ser substituída pela frase “está funcionando”.

O operador continua responsável por definir a necessidade, o escopo e a autoridade para aceitar risco. A ferramenta deve trabalhar com permissões proporcionais. Para uma correção na seleção do catálogo, acesso a dados pessoais, instalação de pacotes ou publicação externa não são passos necessários. Conteúdo encontrado dentro de um arquivo é material a analisar, não autorização adicional para executar instruções que contradizem o pedido.

Pedido trabalhado para a Oficina

Objetivo: corrigir REQ-002, que proíbe revelar casos inativos.
Leia README, src/catalogo.mjs, src/servidor.mjs e os testes relacionados.
Primeiro inventarie os contratos e indique caminhos realmente encontrados.
Inspecione consumidores; altere inicialmente apenas a seleção e seu teste.
Preserve o formato público, os estados vazio/erro e dependências externas zero.
Não invente rota, banco ou campo. Se faltar algo necessário, registre a lacuna.
Mostre o teste que reproduz o problema e o diff da correção mínima.
Execute npm test e npm run validate dentro de pratica.
Informe comando, ambiente, código de saída e resultado observado.
Separe os testes executados dos roteiros manuais ainda pendentes.
Não publique nem acrescente mudanças de estilo a esta unidade.

Esse texto é um instrumento de coordenação, não uma garantia de que a ferramenta o seguirá. O resultado deve ser conferido. A primeira resposta útil contém o inventário e a proposta, com a indicação de arquivos ausentes e de hipóteses ainda não verificadas. Uma declaração de que “a API já existe” precisa apontar para o caminho e para o comportamento correspondente.

Um diff pequeno que permite comparar intenção e efeito

O pacote contém exercicios/bug-inativos.mjs, uma implementação deliberadamente defeituosa que usa map sem filtrar. O exercício anterior falha porque rascunho-interno aparece; a versão correta em src/catalogo.mjs valida, seleciona ativos e projeta campos públicos. A comparação abaixo destaca a mudança de comportamento entre esses artefatos. É um recorte didático, não o histórico Git nem um patch para aplicar cegamente.

-return casos.map(({id,titulo,descricao}) => ({id,titulo,descricao}));
+validarCasos(casos);
+return casos.filter(caso => caso.ativo).map(camposPublicos);

As linhas com menos indicam a forma removida da comparação; as linhas com mais mostram a forma adotada na implementação correta. validarCasos e camposPublicos pertencem ao contexto do módulo oficial. A expectativa fornece os IDs site-acessivel e catalogo-local: incluir rascunho-interno faz a asserção falhar. Isso torna a prova relevante ao defeito, em vez de escolher um teste que passaria também antes da correção.

Dentro de pratica, npm run exercicio:antes executa a versão defeituosa isolada e deve terminar com falha intencional. npm run exercicio:depois executa os testes da implementação correta e deve passar. Os comandos não reescrevem src/catalogo.mjs. Leia o motivo da falha: um erro de caminho ou importação não substitui a diferença esperada entre a lista obtida e a lista autorizada.

Procedimento de execução e conferência

• Selecione os arquivos do estado atual e descreva o objetivo verificável. Não entregue arquivos antigos como se fossem a versão corrente.
• Peça inventário antes da alteração; confirme nomes de funções, rotas, formatos e dependências.
• Examine a proposta e delimite o conjunto de arquivos que a decisão exige modificar.
• Confira o diff: nenhuma dependência, rota ou refatoração alheia deve entrar sem nova decisão.
• Execute as verificações aplicáveis, inspecione resultados e repita a prova crítica diretamente no ambiente.
• Registre o veredito com evidências e limites; documentação de teste falho não autoriza liberação.

Registro auditável da execução fornecida

Esses são resultados registrados no ambiente usado para preparar a edição, não uma promessa sobre qualquer computador. Ao executar em outro ambiente, crie seu próprio registro e compare os resultados; versões e tempos não precisam ser idênticos para a expectativa ser satisfeita. A advertência de configuração http-proxy do npm foi registrada e não produziu falha nos comandos executados.

O gate exige evidência de resultados aceitáveis, escopo respeitado e lacunas não impeditivas classificadas. Se a ferramenta não possui acesso ao ambiente, ela pode entregar uma proposta e um roteiro; o estado da prova deve refletir essa limitação. Documentar um teste obrigatório reprovado não autoriza liberação.

Exercício com resolução

Uma IA afirma: “Corrigi o filtro e todos os testes passaram.” Entrega um diff que acrescenta uma biblioteca de interface e nenhum log. O pedido autorizava somente a correção de REQ-002. Indique três ações antes de aceitar.

Leitura técnica relacionada

S07: Pro Git, seção 2.2 Recording Changes to the Repository, em especial Viewing Your Staged and Unstaged Changes, para interpretar alterações. S19: Node.js test runner, para conferir testes executados. O protocolo de coordenação é a proposta do método; essas referências não certificam o comportamento de uma IA.