Linguagem natural estruturada

Palavras também definem interfaces

O pedido melhore o catálogo transfere para o executor decisões que o solicitante talvez não pretendesse delegar. Melhorar pode significar mudar cores, reordenar serviços ou ocultar os inativos. Duas implementações podem parecer razoáveis e produzir efeitos incompatíveis. O primeiro reparo é formular a transformação desejada, em vez de multiplicar adjetivos.

Uma instrução estruturada reúne contexto, objetivo, fonte, restrições, entregáveis e aceites. Aceite é a condição observável usada para decidir se o resultado atende ao combinado. Entregável é o objeto que será examinado, como uma alteração de arquivo ou um registro de verificação. Informar um formato de entrega não basta: um relatório pode estar bem organizado e descrever um comportamento errado.

O contrato operacional precisa permitir perguntas. Se um dado necessário não existe, a instrução deve orientar a registrar a lacuna. Caso contrário, o executor pode inventar arquivos, regras ou resultados para completar uma narrativa aparentemente coerente.

Uma instrução que permite conferir o resultado

Este modelo preenchido solicita uma unidade da Oficina Caracol. Os caminhos são os do projeto contínuo. O modelo não informa que a implementação já ocorreu.

A fonte de dados define o material de entrada, mas não autoriza expor toda informação nela existente. O requisito de saída pública continua valendo. Essa distinção impede que o executor use a frase está no JSON como justificativa para revelar registros inativos.

Revisão do pedido antes de executar

• Troque palavras vagas por condições: profissional não é um aceite; ocultar serviços inativos é verificável.
• Leia a instrução como se fosse executar sem conhecer a conversa anterior. Localize a fonte de cada regra necessária.
• Produza duas interpretações plausíveis e compare o comportamento esperado.
• Resolva divergências que alterem requisito, dado público ou mudança permitida. Deixe decisões cosméticas livres quando não houver restrição.
• Confirme os comandos no README e em package.json. Uma instrução não deve ordenar um comando inexistente e tratar sua saída esperada como resultado real.

O teste das duas interpretações

Executora A entende ocultar como não desenhar o cartão na página, mas entrega todos os registros ao navegador. Executor B entende que a resposta pública deve omitir os inativos. A diferença é impeditiva quando REQ-002 proíbe revelar esses registros: é preciso esclarecer a fronteira pública e verificar a resposta, além da tela. Já usar margens de 12 ou 16 pixels pode ser aceitável se o pedido não fixa essa medida e a navegação permanece utilizável.

Condição de avanço

O pedido está pronto quando o executor consegue apontar fonte, mudança permitida e resultado verificável sem inventar regra relevante. Faça uma revisão de interpretação com exemplos. Uma divergência de gosto não bloqueia automaticamente o trabalho; uma divergência sobre quais dados podem sair bloqueia a unidade afetada até decisão.

Exercício com resposta

Reescreva: deixe o catálogo seguro e completo. Dados fornecidos: não há login; existem serviços ativos e inativos; o projeto não usa dependências externas; o objetivo desta unidade é somente REQ-002. Diga também uma ação que ficaria fora da solicitação.

Referências para aprofundamento

Leitura de apoio: S01, Software Requirements, temas de especificação e validação de requisitos. A instrução preenchida aplica esses princípios à unidade concreta; não é uma norma universal de redação de prompts.