Revisão
A revisão resume alterações, arquivos e diagnósticos para apoiar a decisão de encerrar ou continuar a tarefa.
Leia o resumo
Comece pelo que a sessão afirma ter mudado. Depois confira arquivos e evidências que sustentam esse resumo.
Diagnósticos
Erros e avisos devem continuar visíveis até serem resolvidos ou conscientemente aceitos como limite da entrega.
Revisão independente de verdade
Revisão é mais útil quando não repete a mesma hipótese do agente que fez a mudança. Thesis e Melos podem atuar como leituras independentes antes de aceitar a entrega.
- Uma revisão deve apontar regressão observável, risco ou contrato violado; reprovar sem diagnóstico não ajuda.
Como isso entra no fluxo
Use Revisão como uma referência de operação, não como uma tela isolada. A própria proposta da página é: A revisão resume alterações, arquivos e diagnósticos para apoiar a decisão de encerrar ou continuar a tarefa. O ganho aparece quando isso se conecta ao que vem antes e ao que precisa acontecer depois.
Se o comportamento divergir do esperado, separe falha visual, falha de dados e falha de execução. O objetivo é descobrir em qual etapa de Revisão o estado deixou de corresponder ao que a interface prometia.
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.
Cenário real
Comece por “Leia o resumo”, confirme o estado visível e avance para “Diagnósticos” apenas quando a etapa anterior estiver estável. Em Revisão, pular contexto costuma gerar mais retrabalho do que velocidade.
- 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
Onde costuma quebrar
Imagine uma tarefa real em que Revisão 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.
Nem todo caso precisa da configuração mais avançada. Prefira o caminho mínimo que resolve o objetivo e aumente complexidade somente quando Revisão realmente exigir mais contexto, controle ou verificação.
Critério de conclusão
Se o comportamento divergir do esperado, separe falha visual, falha de dados e falha de execução. O objetivo é descobrir em qual etapa de Revisão o estado deixou de corresponder ao que a interface prometia.
Use Revisão como uma referência de operação, não como uma tela isolada. A própria proposta da página é: A revisão resume alterações, arquivos e diagnósticos para apoiar a decisão de encerrar ou continuar a tarefa. O ganho aparece quando isso se conecta ao que vem antes e ao que precisa acontecer depois.
- 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: Revisão
Nesta página, a referência completa cobre arquitetura, produto, segurança, regressão, visual e poder de veto. 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 Revisão
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.
