Comprovante de Bug

Saída obrigatória de encerramento

Para cada decisão de encerramento de bug ou incidente, retorne o comprovante completo abaixo como o resultado completo para o usuário, mesmo quando o usuário solicitar uma resposta concisa ou não nomear este formato. A concisão encurta os valores dos campos; nunca remove ou renomeia uma linha. Não substitua o comprovante por prosa.

BUG RECEIPT · VERIFIED | PARTIAL | BLOCKED

Problem    <observed defect and intended behavior>
Baseline   <failing interaction or command and decisive result; or not run>
Root cause <proven mechanism; or unproven hypothesis>
Change     <responsible change; or none>
Proof      <supplied or executed check: result; include every decisive layer>
Gaps       <none; or exact missing proof and single next experiment/package>
Source     executed now | supplied | mixed

Use not run, unproven ou none explicitamente. Nunca omita uma linha para fazer o comprovante parecer completo.

Estabelecer o limite da evidência

Antes de editar, registre o problema observado, o comportamento pretendido, a verificação direta mais forte e a fonte da evidência: executed now, supplied ou mixed. Nunca implique que a evidência fornecida foi executada na execução atual.

Mantenha a privacidade da evidência no mínimo. Redija credenciais, tokens, cookies, dados pessoais, URLs privadas e cargas úteis sensíveis; preserve apenas os identificadores e trechos necessários para reproduzir ou correlacionar a falha.

Reproduza a falha com a verificação segura mais restrita, quando possível. Se a reprodução não estiver disponível, preserve a evidência obtida e limite o resultado a PARTIAL ou BLOCKED.

Rastrear e reparar

1. Siga o caminho do proprietário ativo da entrada ao sintoma.
2. Separe fatos observados, inferências limitadas e lacunas.
3. Exija um local concreto ou transição de tempo de execução antes de nomear a causa raiz.
4. Faça a menor alteração responsável; evite limpeza não relacionada, novas tentativas, fallbacks silenciosos e exceções específicas de fixture.

Não converta um patch plausível, log desatualizado, leitura de código-fonte ou build bem-sucedido em prova do comportamento visível ao usuário.

Fechar o ciclo de prova

Execute apenas as verificações exigidas pelo contrato afetado:

• Reprodução original ou verificação de aceitação direta;
• Verificação de regressão ou negativa mais próxima;
• Gate de build ou integração afetado;
• Caminho real de UI, API, persistência, concorrência ou tempo de execução quando a reclamação cruza essa fronteira.

Use estes limites decisivos:

Atribuir status

• VERIFIED: linha de base observada, causa concreta, alteração responsável, todas as verificações declaradas passaram, sem lacuna material.
• PARTIAL: evidência útil existe, mas uma camada de prova exigida está ausente ou inconclusiva.
• BLOCKED: uma condição externa específica impede a reprodução, reparo ou prova.

Para PARTIAL ou BLOCKED, nomeie o único experimento mínimo ou pacote de evidências correlacionadas que fecha a lacuna decisiva. Nunca invente um comando, observação, contagem, local ou resultado.

Para um comprovante legível por máquina ou integração de CI, leia references/receipt-contract.md e esteja em conformidade com seus campos JSON, marcador de fonte de evidência, regra de compatibilidade e invariantes de status.

Quando um artefato JSON for solicitado, comece em assets/receipt.template.json, escreva-o em um caminho de propriedade da tarefa e valide-o com node scripts/validate-receipt.mjs <receipt.json> deste diretório de skill. Não confirme o comprovante gerado, a menos que o usuário o solicite.

Fonte e licença

Originalmente publicado em https://github.com/lMysticl/bug-receipt sob a Licença MIT.