Diagnósticos
Diagnósticos destacam erros e avisos encontrados durante execução ou revisão.
Leia nível e origem
Quando disponível, o item mostra se é erro ou aviso e aponta o arquivo ou contexto associado. Comece pelo diagnóstico mais específico.
Resolvido ou aceito
Antes de encerrar a tarefa, resolva o que bloqueia a entrega ou registre claramente o que permanece como limitação conhecida.
Falha classificada, resposta adequada
TIMEOUT e RATE_LIMIT pedem retry; SYNTAX_ERROR, TYPE_ERROR e TEST_FAILURE pedem correção; BASE_DRIFT e CONTEXT_DRIFT invalidam conclusões derivadas.
- Diagnóstico bom muda a próxima ação, em vez de apenas renomear o erro.
Da intenção ao resultado
Considere o fluxo concluído quando o resultado pode ser reaberto, revisado e entendido sem depender da memória de quem executou a tarefa. Isso é especialmente importante em Diagnósticos, onde o contexto pode atravessar mais de uma etapa.
Comece por “Leia nível e origem”, confirme o estado visível e avance para “Resolvido ou aceito” apenas quando a etapa anterior estiver estável. Em Diagnósticos, pular contexto costuma gerar mais retrabalho do que velocidade.
No Giorgio Code, isso também significa distinguir o que foi apenas proposto, o que foi escrito em arquivo e o que foi realmente executado ou verificado.
Durante a execução
Nem todo caso precisa da configuração mais avançada. Prefira o caminho mínimo que resolve o objetivo e aumente complexidade somente quando Diagnósticos realmente exigir mais contexto, controle ou verificação.
Imagine uma tarefa real em que Diagnósticos deixa de ser uma opção de menu e passa a decidir a qualidade da entrega. Faça uma primeira passagem curta, observe o retorno do sistema e só então aumente escopo, quantidade de arquivos ou duração da sessão.
- trate mensagens de erro como dados de diagnóstico, não como detalhe visual
- revise a saída no mesmo ambiente em que ela será usada
- confirme o estado antes de iniciar a próxima ação
Se algo sair do esperado
Use Diagnósticos como uma referência de operação, não como uma tela isolada. A própria proposta da página é: Diagnósticos destacam erros e avisos encontrados durante execução ou revisão. O ganho aparece quando isso se conecta ao que vem antes e ao que precisa acontecer depois.
Fechamento do trabalho
Comece por “Leia nível e origem”, confirme o estado visível e avance para “Resolvido ou aceito” apenas quando a etapa anterior estiver estável. Em Diagnósticos, pular contexto costuma gerar mais retrabalho do que velocidade.
Considere o fluxo concluído quando o resultado pode ser reaberto, revisado e entendido sem depender da memória de quem executou a tarefa. Isso é especialmente importante em Diagnósticos, onde o contexto pode atravessar mais de uma etapa.
- confirme o estado antes de iniciar a próxima ação
- mantenha arquivos, sessão e contexto ligados ao mesmo objetivo
- trate mensagens de erro como dados de diagnóstico, não como detalhe visual
Referência de produção: Diagnósticos
Nesta página, a referência completa cobre classe, severidade, retry, repair, drift e causa raiz. O objetivo não é decorar nomes de controles; é entender entradas, estado, efeitos colaterais, falhas recuperáveis e a evidência que confirma a conclusão.
- confirme o estado inicial antes de executar a ação
- identifique quais dados ou arquivos a superfície realmente possui
- trate loading, vazio, erro, retry e reentrada como comportamento principal
- verifique o resultado no mesmo contrato que o usuário consegue observar
Casos de borda de Diagnósticos
A versão robusta desta função continua coerente quando a rede atrasa, a sessão muda, o conteúdo está vazio, o usuário repete a ação, o viewport encolhe ou uma dependência externa deixa de responder. Esses estados fazem parte da documentação porque também fazem parte do produto.
