O que Bug Receipt (Comprovante de Bug) faz?
Saída obrigatória de encerramento
Para toda decisão de encerramento de bug ou incidente, retorne o recibo completo abaixo como o resultado inteiro visível ao usuário, mesmo quando o usuário solicitar uma resposta concisa ou não nomear este formato. Concisão encurta os valores dos campos; nunca remove ou renomeia uma linha. Não substitua o recibo por prosa.
BUG RECEIPT · VERIFIED | PARTIAL | BLOCKED
Problem <defeito observado e comportamento esperado>
Baseline <interação ou comando falho e resultado decisivo; ou not run>
Root cause <mecanismo comprovado; ou unproven hypothesis>
Change <mudança responsável; ou none>
Proof <verificação fornecida ou executada: resultado; inclua cada camada decisiva>
Gaps <none; ou prova exata faltante e único próximo experimento/pacote>
Source executed now | supplied | mixed
Use not run, unproven ou none explicitamente. Nunca omita uma linha para fazer o recibo parecer completo.
Estabeleça o limite de evidências
Antes de editar, registre o problema observado, o comportamento esperado, a verificação direta mais forte e a fonte da evidência: executed now, supplied ou mixed. Nunca insinue que evidências fornecidas foram executadas na execução atual.
Mantenha as evidências com privacidade mínima. Remova credenciais, tokens, cookies, dados pessoais, URLs privadas e cargas úteis confidenciais; 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.
Rastreie e repare
- Siga o caminho do proprietário ativo desde a entrada até o sintoma.
- Separe fatos observados, inferências delimitadas e lacunas.
- Exija uma localização concreta ou transição de tempo de execução antes de nomear a causa raiz.
- Faça a menor mudança 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 obsoleto, leitura de código fonte ou build bem-sucedido em prova do comportamento visível ao usuário.
Feche o loop de prova
Execute apenas as verificações exigidas pelo contrato afetado:
- reprodução original ou verificação de aceitação direta;
- verificação negativa ou de regressão mais próxima;
- build ou gate de integração afetado;
- caminho real de UI, API, persistência, concorrência ou tempo de execução quando a alegação cruzar esse limite.
Use estes limites decisivos:
| Superfície | Prova direta necessária |
|---|---|
| Lógica ou teste falho | Entrada falha original ou teste focado agora passa |
| Comportamento de UI | Interação real mais observação relevante de console e rede |
| API ou integração | Requisição, resposta e comportamento do serviço responsável |
| Persistência | Ciclo completo de escrita/leitura ou recarga pelo caminho real do proprietário |
| Condição de corrida ou ciclo de vida | Gatilho concorrente repetido; sucesso zero ou um; evidência de linha afetada e transação; invariante final |
| Bloqueador entre sistemas | Uma requisição/resposta falha sanitizada com carimbo de data/hora ou ID de requisição, logs de borda e aplicação, e logs do provedor de identidade quando o rastreio atingir esse proprietário |
Atribua o status
VERIFIED: linha de base observada, causa concreta, mudança responsável, todas as verificações declaradas passaram, nenhuma lacuna material.PARTIAL: evidência útil existe, mas uma camada de prova necessária está faltando ou é inconclusiva.BLOCKED: uma condição externa específica impede 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, localização ou resultado.
Para um recibo legível por máquina ou integração com CI, leia references/receipt-contract.md e siga seus campos JSON, marcador de fonte de evidência, regra de compatibilidade e invariantes de status.
Quando um artefato JSON for solicitado, comece de assets/receipt.template.json, escreva-o em um caminho de propriedade da tarefa e valide-o com node scripts/validate-receipt.mjs <receipt.json> a partir do diretório desta skill. Não commit o recibo gerado a menos que o usuário solicite.