melgarafael/DeskcommCRM

O que está errado O MANIFEST.md registra a migration 0238_convites_de_time_persistidos com o timestamp 20260911160000, e o arquivo no disco é 20260911170000_0238_convites_de_time_persistidos.sql. Uma hora de diferença, na coluna que é a chave primária de supabase_migrations.schema_migrations. Medido em origin/main (não é de PR aberto): $ git grep -n '`0238_convites_de_time_persistidos`' origin/main -- supabase/migrations/MANIFEST.md origin/main:supabase/migrations/MANIFEST.md:299:| `20260911160000` | `0238_convites_de_time_persistidos` | ... $ git ls-tree --name-only origin/main supabase/migrations/ | grep 0238 supabase/migrations/20260911170000_0238_convites_de_time_persistidos.sql Por que o gate não pega tests/unit/manifest-x-migrations.test.ts casa a linha por NNNN_slug, não pelo timestamp — e isso é deliberado, com a razão escrita no próprio arquivo: o MANIFEST tem linhas históricas sem timestamp (| *(wave 5)* | \0013_ai_faq_items` |`), e prender o formato mediria a

O que acontece Quem instala o kit no próprio clone e depois dá git add acaba commitando dois arquivos de execução sem querer: .update.lock .deskcomm-site-url-avisado Os dois são criados em tempo de execução pelo kit — medido, com a ref declarada: $ git grep -ln "update.lock\|site-url-avisado" origin/main -- hostgator-setup-kit/ scripts/ origin/main:hostgator-setup-kit/agent.sh origin/main:hostgator-setup-kit/update.sh E nenhum dos dois está protegido: $ git ls-tree --name-only origin/main .update.lock .deskcomm-site-url-avisado # (vazio — não existem na main, corretamente) $ git check-ignore .update.lock .deskcomm-site-url-avisado # (vazio — NÃO estão ignorados) $ git show origin/main:.gitignore | grep -E "update\.lock|site-url|avisado" # (nenhuma menção) Ou seja: o projeto sabe criar os arquivos e não sabe ignorá-los. Já aconteceu, com uma pessoa real O PR #1008 (@faxamkt) carrega os dois. Ele não fez nada errado: rodou o kit para testar o próprio trabalho

O que quem usa vê: na ficha do contato, os dois campos de nome aparecem lado a lado como "NOME" e "DISPLAY NAME" — o segundo em inglês, num produto que serve português e espanhol. Onde: app/app/contacts/[id]/_client.tsx:148 escreve o rótulo cru, sem t(): <dt className="text-xs uppercase text-muted-foreground">Display name</dt> Como foi achado: na prova em tela do lote 12 da triagem (caso L12.QA.13), numa instalação fresca aplicada do baseline.sql. O defeito é anterior ao lote: a linha é igual na main. O que resolveria: passar o rótulo por t() com a entrada correspondente em lib/i18n/dicionario.ts, e escolher um nome que diga a diferença para quem usa — o campo guarda o nome que veio do perfil do WhatsApp, e desde o #907 o nome escolhido pela equipe vence esse. Não medido: se há outros rótulos crus na mesma ficha; a varredura foi só desta linha.

Para quem usa No editor do agente, quando Publicar está desabilitado, o motivo só aparece ao passar o mouse sobre o botão. Em tela de toque ele nunca aparece, e com o teclado não é anunciado. A pessoa vê um botão cinza sem saber o que falta. Evidência (main@54530c9, v1.27.2, somente leitura) app/app/ai/agents/[id]/_components/AgentForm.tsx:599: o motivo (publishBlockReason) vai apenas no title de um <span> que envolve o botão desabilitado. publishBlockReason não é exibido em nenhum outro lugar da tela. Esperado O motivo fica visível junto do botão quando a publicação está bloqueada, e é traduzido em português e espanhol. Não verificado Nada foi exercitado na tela. Critério de aceite Uma prova pela tela (Playwright) com um agente bloqueado, que mostra o motivo sem hover e fica vermelha se o texto voltar a morar só no title. Origem: nota lateral da #783.

O que acontece A ação de automação assign_owner responde user_not_in_org quando a consulta que confere se o usuário é membro da organização falha (rede, banco fora do ar). O operador lê "o usuário não é da organização", conclui que a regra está mal configurada e vai mexer no que está certo. Medido No lote 9 de triagem, com o supabase-js apontado para 127.0.0.1:1 (conexão recusada), o maybeSingle da consulta de membro volta com data: null. O error preenchido é ignorado, e o executor grava user_not_in_org no histórico da regra. Conserto provável Distinguir "consulta falhou" de "não é membro": com error presente, a ação devolve um código de falha transitória (e a execução fica failed com a mensagem do erro), não user_not_in_org. O teste prende os dois casos: membro ausente → user_not_in_org; consulta com erro → outro código. Classe: [falhar fechado na ação, aberto na informação]. A frase que o operador lê não pode acusar a configuração dele quando