Pular para o conteúdo principal
Modular Development Style · Roadmap de Implementacao

ModularCRM

Em que ordem construir e como verificar

Publicado em 10 de julho de 2026 Modulareasy · modulareasy.com/mds
◆ Especificacao Documento de Requisitos ▦ Provisionamento Inventario de Artefatos ✔ Validacao Plano de Testes ◉ Operacao Jornadas dos Atores ✎ Elicitacao Questionario de Elicitacao
Progresso da implementação ...
Planejamento 0%
Construção 0%
Testes 0%
Progresso geral: 0%
Clique no quadradinho para marcar como feito. O progresso é salvo automaticamente e compartilhado.

Roadmap de Implementação, ModularCRM

Documento companheiro do DRS, ModularCRM. Responde: em que ordem construir e como verificar cada entrega.

Progresso em três seções (40/40/20). Planejamento 40% (a Fase 0, concluída na aprovação do DRS), Construção 40% (as fases de construção), Testes 20% (o Plano de Testes). Leitura importante do percentual (2026-07-10). O produto V1 (Fases 1 a 5) está essencialmente entregue e em produção com o tenant piloto. A partir de 2026-07-10 o roadmap ganhou a Fase 6, o backlog de paridade com o GoHighLevel, que passou a contar como Construção. Esse backlog foi recortado no mesmo dia ao escopo real do produto (painel interno da Modulareasy, isolamento por subconta, sem revenda white-label): saíram Telefonia, Ecossistema de desenvolvedores e marketplace, Cursos e comunidades, Sites institucionais, Funis e Loja, e a parte de revenda do modo Agência, restando 12 áreas. A Inteligência Artificial foi mantida e recortada (bot de conversa, conteúdo e ações em automação, com custo traga-sua-própria-chave) e a Reputação foi mantida. Por isso a barra de Construção agora mede a jornada até a paridade com o GoHighLevel, e fica baixa de propósito: não significa que o V1 regrediu, significa que o horizonte de evolução ficou maior. As Fases 1 a 5 seguem o estado real do V1; a Fase 6 é direção de produto sem data.

Auditoria de reconciliação (2026-07-10). Foi feito um walkthrough tela a tela do sistema em produção, papel por papel, cruzando cada tela com o banco de dados. O resultado confirmou que a superfície do produto está quase toda construída e que a maior parte dos fluxos internos funciona de ponta a ponta; os problemas se concentram na camada que liga o CRM ao mundo externo (canais, integrações, páginas públicas) e em pontos onde a interface indica sucesso sem que a ação tenha de fato acontecido. Os achados novos entraram como a Onda AUD ao final deste roadmap, e o Plano de Testes recebeu o estado real de cada validação. As notas "ver {AUD-nn}" nos cards abaixo apontam para o achado correspondente. Execução da Onda AUD (atualizado 2026-07-17): a fila começou pelo {AUD-14} (tokens Meta cifrados em repouso, com a fatia F10 regularizada no mesmo merge) e seguiu com o {AUD-01}, entregue e validado em produção em 2026-07-11: o Super Admin em modo "entrar como empresa" passou a enxergar os dados reais da empresa escolhida, com cada entrada e saída registrada no log de auditoria. No mesmo dia o {AUD-02} também foi entregue: o envio de mensagem passou a ser honesto, sem canal conectado o sistema bloqueia com aviso claro e não grava nada; com canal, o status gravado é o resultado real do despacho, e o envio de e-mail deixou de gravar registro duplicado. O alcance daquela entrega era o envio do operador pela tela, que era todo o alcance do RF-CONV-054 na época, e nele ela continua valendo; o levantamento de 2026-07-16 mostrou que o produto despacha whatsapp por outros pontos, que rodam sem pessoa diante da tela e não conferem o canal, e o {AUD-88} emendou o requisito para alcançar todos eles, deixando a entrega do conjunto com o {AUD-83}, entregue em 2026-07-17 junto com o {AUD-84} e o {AUD-90} (merge aca9db6), quando o whatsapp ganhou um lugar único que sonda o estado real do canal e os quatro pontos passaram a decidir por ele; a reconciliação dessa entrega abriu o {AUD-96} (o canal alternativo inutilizável nas duas pontas), o {AUD-97} (a resposta automática de IA desligada em silêncio por falta de chave) e o {AUD-98} (a telemetria de estado do canal que congela por falta de reconciliação). Ainda em 2026-07-11 o {AUD-07} foi entregue: o vínculo entre empresa e plano passou a ser íntegro por gatilho no banco, o tenant piloto Hiit Fitwear ficou no plano Pro real com ciclo de cobrança ativo e limites reais, o MRR do painel passou a ler o preço real do plano, e o cron diário de faturamento, que nunca tinha gerado uma fatura porque respondia 401 desde 2026-04-19, foi destravado e provado gerando fatura de teste. Fechando o dia, o {AUD-03} também foi entregue: a página pública de agendamento voltou a funcionar de ponta a ponta, com as consultas públicas movidas do navegador para o backend (lista fechada de campos, sem afrouxar o isolamento), horários no fuso do calendário, gravação honesta que recusa horário ocupado e cancelamento por link, tudo provado em produção com um agendamento real criado, vinculado a contato e cancelado. Também em 2026-07-11 o {AUD-04} foi entregue: o chat público e o widget de webchat voltaram a funcionar, corrigindo cinco defeitos combinados (endpoint chamado sem o prefixo da API, coluna do visitante ausente na tabela de contatos, coluna errada na listagem de mensagens, resposta de pré-voo CORS faltando no widget e status de entrega que nunca fechava), com o widget testado embedado num site externo e a conversa completa provada ponta a ponta em produção. Ainda em 2026-07-11 o {AUD-05} foi entregue: a aba SaaS do painel da agência voltou a abrir sem quebrar (a consulta de uso por organização passou a informar o nome do plano e a tela ficou resiliente a organização sem plano, mostrando "Sem plano" em vez de derrubar o painel), a participação de MRR passou a ser exibida como percentual real (antes mostrava o valor absoluto como se fosse porcentagem) e o gráfico de distribuição ficou legível no celular; a decisão de escopo foi manter a tela, que corresponde ao painel consolidado de status e uso por subconta previsto no DRS. Ainda em 2026-07-11 o {AUD-06} foi entregue: a tela de "Templates de Workflow" da agência voltou a funcionar de ponta a ponta, corrigindo quatro defeitos combinados (resposta embrulhada da API tratada como lista, consulta com filtros caindo em rota inexistente, criação que ignorava o estado inativo e lista fixa de categorias que corrompia categorias reais ao editar), com a listagem de rascunhos inativos restrita ao super admin e a validação provada em produção com lista, estado vazio, duplicação e filtros. {AUD-09} foi entregue: o botão de criar oportunidade da ficha do contato deixou de cair em página inexistente e passou a abrir o funil com a janela de nova oportunidade já vinculada ao contato (nome pré-preenchido e vínculo gravado ao salvar), com o atalho de agendar do mesmo menu corrigido no mesmo merge; a exclusão de contato que falha em silêncio descoberta no teste virou o card {AUD-18} e o reforço de isolamento no vínculo contato-oportunidade virou o {AUD-19}. {AUD-18} foi entregue fora de ordem por pedido direto: a exclusão de contato deixou de fingir sucesso; o banco ganhou regras de remoção e anonimização dos vínculos (com respaldo de LGPD nos formulários), qualquer falha real vira aviso claro mantendo o operador na ficha, e a confirmação diz o que sai junto. {AUD-08} foi entregue: os rótulos da ficha do contato voltaram a exibir acentuação correta (a corrupção estava em quinze linhas do código do componente, único ponto do app, recodificadas de forma cirúrgica e provadas sem resíduo em produção). Em 2026-07-12 o {AUD-10} foi entregue (merge b48fc8b): um gatilho genérico de auditoria passou a gravar criar, editar e excluir de operador em 22 tabelas de gestão, com autor, tipo, entidade, rótulo e data (escritas de sistema ficam fora, salvar sem mudar nada não grava, e falha de auditoria nunca derruba a ação do usuário); a tela de Registro de Auditoria passou a ler essa trilha real em vez da tabela errada que lia antes; e dois defeitos históricos na função de mesclagem de contatos (insert em colunas inexistentes e sintaxe inválida na verificação de organização) foram corrigidos no mesmo merge, com a mesclagem voltando a funcionar e a gravar a ação na trilha. O QA dessa entrega encontrou dois achados de polimento pré-existentes e não bloqueantes, que viraram os cards {AUD-20} (tema claro e mobile quebrados em Configurações) e {AUD-21} (403 nas sugestões de mesclagem da ficha do contato). {AUD-11} foi entregue em 2026-07-12 (merge df025d9): as janelas de nova tarefa, nova oportunidade e novo produto passaram a fechar ao salvar com sucesso, com o item aparecendo uma única vez na lista, e deixaram de fingir em caso de erro: quando o salvamento falha, a janela permanece aberta com os dados preservados e um aviso claro (sem expor mensagem técnica) no lugar de travar em silêncio, e o envio acidental em duplicidade é bloqueado. Em 2026-07-12 o {AUD-20} foi entregue (merge e991e03): a sub-navegação de Configurações passou a seguir o tema claro e o escuro pelos tokens do sistema e, em telas estreitas, virou um seletor no topo com o conteúdo em largura total, sem espremer. Em 2026-07-12 o {AUD-21} teve o defeito de 403 corrigido (merge a681a9a): as chamadas de leitura da ficha do contato (sugestões de mesclagem, identificadores e configuração de correspondência) passaram a reconhecer o Super Admin da operação, que antes recebia 403 ao abrir a ficha de um contato de uma empresa da qual não é membro; o isolamento foi preservado, quem não é membro nem Super Admin continua bloqueado. O card, porém, segue em aberto (parcial) porque a segunda metade do aceite não é atingível hoje: a sugestão automática de duplicados por identificador nunca produz candidato sob a regra de unicidade (empresa, tipo, valor) da tabela de identificadores, que impede dois contatos da mesma empresa dividirem o mesmo identificador. Esse defeito estrutural do casamento de duplicados foi catalogado como {AUD-22}. {AUD-13} foi entregue em 2026-07-12: as empresas de teste e internas ficaram ocultas por padrão na listagem de Subcontas (só o tenant real Hiit aparece), com selo Teste, um toggle para revelá-las e uma ação de linha que marca ou desmarca de forma reversível, sem apagar nada e sem afetar o entrar-como-empresa, validado por smoke visual real (claro, escuro e mobile) e QA E2E. {AUD-15} foi entregue em 2026-07-12 (merge a3d2158): o servidor de integrações passou a reconhecer o Super Admin em modo entrar-como-empresa nas ações que dependem do servidor (envio de e-mail e mensagens/comentários no Meta), com o mesmo reconhecimento transversal já usado na leitura e sem afrouxar o isolamento do usuário comum, provado em produção. Durante essa entrega o code review encontrou três endpoints de servidor sem verificação de autenticação (envio de campanha, envio de SMS e convite de membro), catalogados como {AUD-26} por serem risco de segurança independente do {AUD-15}. O {AUD-26} foi entregue em 2026-07-12 (merge e7cf713): os três endpoints de servidor sem autenticação (envio de campanha, envio de SMS e convite de membro) passaram a exigir token e acesso à empresa (membro ou Super Admin), o convite passou a derivar o autor do token e o front a enviá-lo, e o envio de campanha (que estava com a rota morta pelo reescrita do Nginx) voltou a funcionar autenticado. Durante essa entrega foi catalogado o {AUD-27} (outros handlers registrados só com o prefixo /api/ ficam mortos pelo mesmo reescrita do Nginx, alguns com tela quebrada como salvar configuração de e-mail e de SMS). O {AUD-16} foi entregue em 2026-07-12 (merge 9a4be41): endurecimento do agendamento público, com validação da janela de disponibilidade na gravação, garantia atômica no banco contra dois agendamentos no mesmo horário, limite por IP nas leituras públicas e cancelamento por código com validade. O {AUD-17} foi entregue em 2026-07-13 (merge b5df2a8): endurecimento do chat público, mesma classe do {AUD-16} mas para o chat, com a leitura do histórico de uma conversa passando a exigir prova de posse pelo identificador do visitante (antes bastava saber o id da conversa), rate-limit por IP no envio de mensagens e validação de tamanho e formato dos campos. O {AUD-19} foi entregue em 2026-07-13 (merge 807424e, migration 085): o vínculo entre contato e oportunidade passou a ser validado por gatilho no banco, que recusa contato de outra organização independentemente de quem chama; a permissão de criar oportunidade no frontend deixou de liberar por padrão enquanto o papel do usuário carrega ou falha, e a falha na consulta de funis passou a mostrar erro claro com opção de tentar novamente em vez de sumir em silêncio. O code review dessa entrega achou um ponto estrutural fora do escopo da fatia, catalogado como {AUD-29}: as permissões de papel hoje só valem no frontend, sem reforço equivalente no banco. Em 2026-07-13 a Onda AUD avançou: o {AUD-22} foi entregue (merge d12c179, migration 086), com a detecção de duplicados passando a comparar e-mail e telefone normalizados, o que destravou de vez o {AUD-21}, fechado no mesmo movimento porque o Super Admin passou a ver a sugestão real de duplicados e a concluir a mesclagem de fato. O teste de não regressão dessa entrega encontrou a mesclagem quebrada (500) para todo mundo havia cerca de dois meses, corrigida no mesmo merge como {AUD-30}, e essa correção revelou duas pendências novas: {AUD-31} (rotas de trigger links quebradas por variáveis indefinidas) e {AUD-32} (o modo entrar como empresa não alcança o restante do canal /api do webhook). Em 2026-07-13 o {AUD-23} foi entregue: os rótulos em inglês que restavam fora de Configurações (os cabeçalhos da tabela "Relatório por Origem" no painel inicial e os textos da tela de Pontuação Global no portal da agência) foram traduzidos para português, validados em produção nos modos claro, escuro e mobile. Em 2026-07-13 o {AUD-24} foi entregue: o seletor de Tipo de Empresa (Perfil da Empresa) passou a listar os tipos jurídicos brasileiros (MEI, EI, EIRELI, SLU, Ltda., S.A., Sociedade Simples, Sem fins lucrativos, Outro), e os cadastros existentes foram migrados sem perda de dado. Em 2026-07-14 o {AUD-25} foi entregue: as empresas de teste deixaram de ser contadas e listadas por padrão nas telas do Super Admin (indicadores de organizações e MRR do painel da agência, seletores de organização em Criar e Aplicar Snapshot, tabela de Whitelabel e o seletor "Sub-conta" do cabeçalho), com a opção de revelá-las por um interruptor onde faz sentido; o QA da fatia abriu o novo {AUD-33} (os indicadores de Usuários e Contatos do painel ainda contam empresas de teste). Em 2026-07-14 dois itens da fila foram entregues. O {AUD-27} foi entregue (merge 2146cfb): as dez rotas do servidor de integrações que a reescrita do Nginx deixava mortas (Google Calendar, reprocessar nomes de contatos do Meta, salvar configuração de e-mail e de SMS, relatórios de Google Analytics, Meta Ads e Google Meu Negócio, e formulários do Meta Leads) voltaram a responder pela URL pública com o mesmo guardião de autenticação do {AUD-26}, e as duas rotas que gravam credencial (senha SMTP, token do Twilio) passaram a exigir dono ou administrador da empresa. No qa dessa entrega apareceu, em handler distinto, o {AUD-34} (também entregue em 2026-07-14): a criação de conta de e-mail em Caixas de Email não funcionava por faltar o identificador da empresa no envio, e o interruptor de pular teste de conexão do Super Admin não era honrado pelo botão Salvar; os dois defeitos foram corrigidos e provados em produção. Dito sem maquiagem: a listagem de Caixas de Email ainda fica cega quando o Super Admin usa o modo entrar como empresa, isso está rastreado no {AUD-32} e não foi tocado nesta entrega. Planejamento do {AUD-29} (2026-07-14): quatro achados que mudaram a fila, registrados antes de escrever qualquer código. Primeiro, um problema de segurança grave e independente do card: as tabelas de formulários e de campanhas têm as regras de isolamento escritas mas com a proteção desligada, e ficou provado em produção que qualquer pessoa, sem login, de posse apenas da credencial pública que acompanha o site, lê o formulário cadastrado e a empresa dona dele, podendo ainda inserir, alterar e apagar. Virou o {AUD-35} e passou à frente do {AUD-29} na fila, porque é um rombo vivo enquanto o {AUD-29} corrige um risco ainda dormente. Por consequência, o teste {A-061} do Plano de Testes, que declarava o isolamento firme desde 2026-07-10, foi reaberto: ele estava aprovado e mentindo. Segundo, o modelo de papéis granulares (RF-PERM-001, Essencial) não está implementado: existem a tabela, o vínculo do membro com o papel e o controle que esconde botões, mas não existe tela nenhuma para o administrador criar ou atribuir papel, e em produção não há um único papel cadastrado nem um membro que não seja dono. Virou o {AUD-37}, e significa que o {AUD-29} endurece a metade-banco de uma funcionalidade cuja metade-produto ainda não existe: é defesa em profundidade legítima e barata, mas não entrega o RF-PERM-001, e este roadmap não vai dizer que entrega. Terceiro, o aceite do {AUD-29} falava em "uma ação" sem dizer quais, e requisito vago não reprova nada: foi escopado às ações de escrita, que é o que o próprio sintoma do card descreve, e ver e exportar saíram para o {AUD-36}, porque reforçá-los pela mesma técnica derrubaria o agendamento público e faria consultas voltarem vazias em silêncio. Quarto, várias telas consultam o controle de permissão por módulos que não existem no catálogo ou pelo módulo de outra entidade, o que hoje é inofensivo e vira defeito no primeiro papel restritivo: virou o {AUD-38}. O {AUD-35} foi entregue em 2026-07-14 (merge 51a055a), no mesmo dia em que foi descoberto. A proteção de isolamento foi ligada nas duas tabelas e em mais três da mesma família (cliques e aberturas de campanha e passos agendados de automação, que estavam sem proteção e sem nenhuma regra, e alcançam a empresa por vínculo), e as três ganharam regra de leitura pela empresa dona. Nenhuma das regras que já existiam foi alterada, e nenhuma regra de leitura pública foi criada: ficou provado por leitura de código e por requisição real que a página pública de formulário não lê a tabela direto, ela passa pelo servidor de integrações, que tem acesso próprio e não depende dessa proteção. Provas: quem não fez login passou a receber lista vazia em formulários e campanhas (antes recebia o formulário e a empresa dona), a tentativa de alterar o endereço de redirecionamento do formulário sem login não altera mais nada, e a página pública de formulário continua respondendo e recebendo envio. A migração ainda instalou um verificador que aborta qualquer migração futura se alguma tabela com dono de empresa ficar sem proteção, para esta classe de defeito não voltar. Causa-raiz, dita sem maquiagem: as duas tabelas nasceram antes do controle de migrações, com as regras certas escritas e sem o comando que as liga, e a auditoria de proteção feita em 2026-05-12 corrigiu a tabela filha (as respostas dos formulários) mas foi escopada a uma lista de catorze tabelas e nunca olhou a tabela mãe, deixando o furo aberto por cerca de dois meses. A lição virou regra: auditoria de isolamento se faz por critério (toda tabela que tem dono de empresa), nunca por lista curada. Durante essa entrega apareceu o {AUD-39}: a regra de leitura pública dos calendários libera todo calendário ativo sem filtrar empresa, e a evidência aponta que ela virou código morto depois que o {AUD-03} moveu as consultas públicas para o servidor. Por causa dele o teste {A-061} segue reprovado. O {AUD-29} foi entregue em 2026-07-14 (merge b74e049, migration 089). As permissões de papel, que até aqui só existiam no navegador, passaram a valer também no banco para as ações de escrita: uma função de autorização espelha regra por regra o mesmo controle que o frontend usa para esconder botões, e regras de escrita em nove tabelas de gestão consultam essa função antes de deixar criar, editar ou excluir. Nenhuma regra de isolamento por empresa que já existia foi alterada, e o reforço só nega, nunca concede. A prova foi feita por requisição real com o token de um membro de verdade, não por leitura de código: com o papel negando criar, a gravação é recusada e nada entra; com o papel permitindo, a mesma requisição passa; dono, administrador e Super Admin não sentiram diferença, inclusive no modo entrar como empresa; e o agendamento e o formulário públicos continuam funcionando, porque passam pelo servidor de integrações, que tem acesso próprio. O code review pegou, e a correção entrou antes do merge, uma divergência que teria deixado o banco mais frouxo que a tela: a checagem da permissão aceitava textos como "yes" no lugar de sim/não e chegava a quebrar com erro diante de um valor inesperado, em vez de simplesmente negar. Dito sem maquiagem, e repetindo o que o próprio card avisa: isto não entrega o RF-PERM-001. Continua não existindo tela para criar ou atribuir papel, e em produção seguem zero papéis cadastrados e nenhum membro que não seja dono, então o que este card fecha é um risco real mas dormente, esperando o {AUD-37}. Duas ressalvas honestas ficam registradas: uma escrita recusada em editar ou excluir volta silenciosa, como "nada a fazer", em vez de erro (o dado fica protegido, mas quem ligar a tela de papéis não pode ler esse silêncio como sucesso), e o reforço só alcança os módulos que existem no catálogo do produto, deixando formulários, produtos e tarefas sem regra de papel. Durante a validação apareceu o {AUD-41}: criar um usuário provisiona uma empresa automaticamente, e excluir o usuário deixa essa empresa órfã contando como cliente real no painel do Super Admin. Sessão de 2026-07-15 ({AUD-31}). A correção dos links rastreáveis foi feita e está no ar: os três endereços (criar, listar e apagar) liam duas variáveis de configuração que nunca existiram no arquivo, então estouravam antes de qualquer lógica e devolviam erro em toda chamada autenticada. Não é regressão: nasceram assim e nunca funcionaram em produção desde que foram escritos. A correção são três nomes de variável, e o aceite foi provado por requisição real (caso positivo e negativo) e também pela tela, por clique real de mouse: criar, listar, abrir o link curto, ver o contador subir e apagar, nos temas claro e escuro. O card foi fechado. Nesta sessão também foi decidido, com razão técnica registrada no {AUD-32}, não encaminhar ali a marca de entrar como empresa: a função que cria o link resolve a empresa por conta própria e ignoraria a marca, enquanto listar e apagar a honram, de modo que o Super Admin criaria um link que sumiria da própria lista. O achado maior da sessão não estava no card: ao conferir o que o DRS promete para links rastreáveis, descobriu-se que o editor de automações oferece gatilhos que a tela aceita e o produto nunca dispara: a automação fica salva como ativa e nunca roda. Virou o {AUD-43}, e o DRS, que afirmava que esses gatilhos "já existem", foi corrigido e republicado no mesmo dia. Reconciliação de 2026-07-15: a contagem da primeira versão do card estava errada e foi refeita conferindo emissor por emissor no código. O número certo é vinte gatilhos oferecidos, onze com emissor real, oito sem emissor nenhum e um (execução manual) que por desenho só roda quando outra automação o aciona. Errou porque contou por busca de texto literal, e cinco emissores escapam dela: as tags saem de um condicional e o ganho ou perda de oportunidade sai de um nome montado em tempo de execução. O risco é real mas dormente: as três automações em produção usam o gatilho de novo contato, que funciona, e a empresa cliente não tem automação nenhuma. Ainda da sessão de 2026-07-15, três achados menores foram catalogados e não corrigidos, para não inchar a fatia: o {AUD-44} (apagar link rastreável de outra empresa responde sucesso sem apagar nada. Entregue 2026-07-24 (merge ea19db9): o handler de exclusão passou a usar .select() e a checar linhas afetadas; zero linhas (RLS, outra empresa ou inexistente) responde não-encontrado (404), nunca sucesso falso. Provado com token real do c3po em produção (DELETE de link inexistente devolve 404 not_found) e por qa com RLS real (o dono apaga e recebe 200, o não-dono recebe 404), com a Hiit intacta., dormente porque o isolamento protege e só é alcançável por chamada direta), o {AUD-45} (o ajuste de tamanho do endereço curto existe no painel e não faz nada) e o {AUD-46} (uma leitura de contato devolveu erro durante navegação normal, ainda não investigada). O {AUD-47} foi entregue em 2026-07-15 (merge 67b7051), no mesmo dia em que nasceu. O barramento de eventos, que é o endereço por onde a tela avisa o servidor que um fato aconteceu, estava alcançável pela internet aberta e aceitava disparo sem autenticação nenhuma: bastava saber o identificador de uma empresa para fazer as automações ativas dela rodarem contra um contato escolhido, e as ações de automação enviam mensagem de verdade. Agora exige sessão válida e vínculo com a empresa alvo, reaproveitando a mesma verificação que a rota vizinha de convite já usava desde o {AUD-26}. O racional foi corrigido durante a investigação: o identificador da empresa não é público (o widget do site do cliente usa o apelido, não o identificador), mas ele é identificador e não credencial, nunca muda e é conhecido por qualquer um que um dia teve acesso, então, sem checagem de usuário, excluir alguém não revogava nada. Provas por requisição real: sem token responde recusa e nada dispara (antes respondia sucesso e criava duas execuções), token inválido idem, e o caminho legítimo continua funcionando, provado por clique real de mouse na tela, com as execuções subindo de treze para quinze e o registro gravado no banco, inclusive no modo entrar como empresa. Ressalva honesta registrada: a recusa por falta de vínculo não foi exercitada, porque os usuários disponíveis são super administradores e a verificação aprova por esse caminho antes de olhar o vínculo. Foi este card que expôs que o {AUD-43} estava apoiado em duas premissas falsas, hoje corrigidas no próprio card. O {AUD-43} foi entregue em 2026-07-15 (merge c6a0dbb), no mesmo dia em que o {AUD-47} nasceu dele. A lista de gatilhos do editor de automações passou a dizer a verdade: eram vinte gatilhos oferecidos, oito deles sem ninguém que os disparasse, e agora são treze, todos com emissor real, exatamente os treze que o RF-AUTO-002 nomeava naquela hora (na tarde do mesmo dia o requisito passou a nomear quinze, pela reentrada decidida de dois gatilhos; ver {AUD-52} e {AUD-53}). A causa-raiz foi corrigida antes da lista: a mesma lista existia quatro vezes no código e já tinha divergido (nove dos vinte sem rótulo, por isso o gatilho de formulário enviado, que funciona, aparecia como texto técnico cru na tela), e havia até um comentário prometendo uma sincronia que nada garantia; agora existe uma fonte única e as demais derivam dela. Sete gatilhos saíram da lista por decisão registrada no requisito, o rótulo da execução manual parou de prometer um botão que a tela não tem, e o template que entregava automação quebrada em um clique foi removido. O gatilho de agendamento marcado, único dos oito que o requisito nomeia, ganhou emissor nos dois caminhos por onde o agendamento nasce. Provas: pela tela, o editor mostra treze gatilhos e nenhum outro (conferido no valor do campo, não no rótulo); uma automação antiga com gatilho removido abre, mostra rótulo legível e continua com o gatilho intacto depois de salvar; e o agendamento passou a disparar a automação pelos dois caminhos, provado por execução gravada no banco, com o par negativo (automação desligada não gera execução). Uma ressalva honesta: o modo escuro do construtor é parcial e o aparelho móvel não foi verificado, ambos pré-existentes e não introduzidos por esta entrega. Pendentes acionáveis da fila agora (atualizado 2026-07-15): {AUD-57} (o agendamento público cria contato sem disparar automação, entregue o {AUD-49} em 2026-07-15, é agora o próximo item acionável da fila, e é um dos três caminhos com tráfego real que ainda estão mudos, ver {AUD-66}), {AUD-58} (o gatilho de mensagem recebida ignora quatro canais), {AUD-48} (enumerar por script toda rota exposta pela reescrita do servidor de borda), {AUD-50} (a coleta de e-mail recusa o próprio agendador), {AUD-59} (o aviso de limite de armazenamento só dispara para quem manda e-mail), {AUD-60} (ação em massa no funil não dispara o que a ação individual dispara), {AUD-32} (entrar como empresa no canal /api, com a instância nova do {AUD-34} documentada no próprio card), {AUD-33} (indicadores de Usuários e Contatos do painel da agência ainda contam empresas de teste), {AUD-39} (regra de leitura pública dos calendários cega quanto à empresa), {AUD-41} (empresa órfã ao criar e excluir usuário), {AUD-37} (a tela de Papéis e Permissões, que é o que de fato entrega o RF-PERM-001), {AUD-36} (reforço de ver e exportar) e {AUD-38} (chaves de módulo divergentes), {AUD-44}, {AUD-45} e {AUD-46} (os três achados menores de 2026-07-15). Adiados por decisão, com o motivo registrado no próprio card: {AUD-54} (status da conversa alterado tem cinco pontos de escrita e risco de laço) e {AUD-55} (fatura paga e fatura vencida dependem da cobrança automática da V2). Decididos em 2026-07-15 e promovidos de pendência a trabalho especificado, aguardando a vez na fila: {AUD-52} (o lembrete de agendamento vira automação montável e o agendador para de mandar sozinho), {AUD-53} (contato atualizado volta, com filtro por campo obrigatório) e {AUD-56} (o botão de executar automação na mão, com requisito próprio no RF-AUTO-043). O documento está à frente do código de propósito, e isto não é drift (2026-07-15). O RF-AUTO-002 nomeia dezesseis gatilhos e a tela oferece catorze. A ordem dos fatos explica a diferença: de manhã o {AUD-43} (merge c6a0dbb) subiu a lista honesta de treze, tirando os sete que não tinham emissor; à tarde o Wladimir decidiu a reentrada de dois deles, o lembrete de agendamento e o contato atualizado, subindo o requisito de treze para quinze nomeados, e o requisito foi emendado antes de qualquer código, como manda a regra; ainda na mesma tarde o RF-CONV-014 foi reconciliado e ganhou o décimo sexto gatilho nomeado, o clique em link rastreável, que o {AUD-51} entregou no mesmo dia, merge 109857f, subindo a tela de treze para catorze. Portanto os dois gatilhos que faltam na tela são backlog especificado ({AUD-52} e {AUD-53}), não defeito e não promessa esquecida. Quem for reconciliar documento e código nesta área: a correção é construir os dois gatilhos, nunca apagá-los do RF-AUTO-002. O DRS é lei e o código corre atrás dele, nunca o contrário. O {AUD-40} foi entregue em 2026-07-14 (merge b9a9e37), no mesmo dia em que nasceu: a saída do modo entrar como empresa limpava só parte do estado e deixava a empresa ativa gravada no navegador, então o modo voltava sozinho na navegação direta por endereço. A correção reaproveitou uma função de limpeza que já existia no código e que já prometia, na própria documentação dela, ser usada nessa saída, mas não era. Além do estado guardado, a empresa em memória também passou a ser zerada: mantê-la fazia a empresa visitada continuar sendo o escopo das telas depois da saída e realimentava a entrada seguinte, que era o que gerava o defeito. O teste provou os dois lados: não volta mais sozinho, e quem sai volta para a própria empresa em vez de ficar sem nenhuma. O {AUD-28} (ponte de trigger links do WhatsApp Evolution) segue parkeado, dependente do QR code do WhatsApp para prosseguir. Sessão de 2026-07-15 (segunda parte), o barramento de eventos. Ao planejar o conserto dos gatilhos apareceu um furo de segurança vivo: o endereço que recebe os eventos do sistema aceita disparo de qualquer pessoa da internet, sem login nenhum, e executa as automações ativas da empresa indicada, enviando mensagem de verdade ao contato e consumindo cota. Virou o {AUD-47}, P0, entregue e mergeado em 2026-07-15, no mesmo dia em que nasceu (o relato completo da entrega está acima). O DRS não cobria o caso: o requisito de isolamento falava em não retornar dados de outra empresa, ou seja, tratava de leitura, e o furo é de ação. Requisito vago não reprova nada, então o DRS foi emendado antes de qualquer código: o isolamento passou a valer também para escrita e nasceu o RNF-010 (Perímetro autenticado), que exige sessão válida e vínculo com a empresa alvo em todo endereço de servidor alcançável pela internet, antes de qualquer efeito. Do mesmo trabalho saíram mais três cards: o {AUD-48} (a auditoria dessa classe foi feita por lista curada e deixou passar justamente este endereço, então a varredura tem que ser exaustiva e por script), o {AUD-49} (o webhook público de captura de lead chama o motor de eventos com o nome de campo errado, então o contato entra e a automação nunca roda) e o {AUD-50} (a coleta de e-mail recusa o próprio agendador, porque ele manda o segredo no cabeçalho e essa rota, sozinha entre as irmãs, só lê o segredo no endereço).

Sessão de 2026-07-15 (terceira parte), o planejamento do {AUD-43} e o que ele revelou. Antes de escrever uma linha de código para consertar a lista de gatilhos, o planejamento conferiu emissor por emissor e achou a causa-raiz que o card não via: a lista de gatilhos existe quatro vezes no código, mantida à mão, e as quatro já divergiram entre si. Por isso a correção não é editar as listas, o que reintroduziria o drift no card seguinte, e sim fazer as telas derivarem de uma fonte só. O planejamento também achou uma armadilha ativa que desmente o "risco dormente" do card: um dos modelos prontos de automação entrega, em um clique, uma automação com um gatilho que nunca dispara, e dois dos três workflows que existem em produção nasceram de modelos. Como manda a regra, o documento foi emendado antes do código. O RF-AUTO-002 deixou de listar eventos "como" isto ou aquilo (lista ilustrativa não reprova nada, e foi ela que deixou os oito gatilhos mortos conviverem com o requisito sem violá-lo) e passou a nomear o conjunto exato dos treze gatilhos que o produto oferece, com a regra de honestidade explícita (a lista da tela não pode oferecer gatilho que o produto não dispara, e nenhum gatilho vale só para parte dos caminhos) e com os sete que saem declarados fora do escopo atual, para que sair da lista não vire drift no futuro. O RF-CONV-014 foi reconciliado na direção inversa, que é a mais perigosa: ele afirmava como fato existente que o clique em link serve de gatilho, e isso era falso nos dois sentidos (o gatilho não existe em lugar nenhum, e o clique é gravado sem contato atribuído, então não haveria a quem inscrever). Virou o {AUD-51}. Do mesmo planejamento saíram mais nove cards: {AUD-52} a {AUD-56} (os gatilhos adiados e o botão de executar, cada um com o motivo registrado), {AUD-57} (o agendamento público cria contato sem disparar automação, irmão do {AUD-49}), {AUD-58} (o gatilho de mensagem recebida ignora SMS, chat do site, Instagram e Messenger), {AUD-59} (o aviso de limite de armazenamento só dispara para quem manda e-mail) e {AUD-60} (mover oportunidades em massa não dispara o que mover uma dispara). Os quatro últimos são da mesma família do {AUD-49} e merecem prioridade explícita, porque são mais graves do que a contagem de gatilhos do {AUD-43} sugere: não são gatilhos que faltam, são gatilhos que existem, estão na lista, e mentem em parte dos caminhos. Esse é o defeito mais difícil de perceber, porque o teste feito por um caminho passa.

O {AUD-51} foi entregue em 2026-07-15 (merge 109857f), no mesmo dia em que nasceu, com o front buildado, o webhook reiniciado e a rota pública respondendo 200 em produção. O clique em link rastreável virou gatilho de automação de verdade, com o contato atribuído. A URL do link curto virou /l/<slug>?c=<token>, com um id opaco de envio de 32 hex por par de link e contato, emitido pela RPC issue_link_token, que exige que o link e o contato sejam da mesma empresa; o identificador do contato não viaja na URL, porque identificador não vale como credencial (RNF-010). A função register_click passou a resolver o contato pelo token escopado ao próprio link, grava o clique com o contato atribuído e lança a linha no histórico dele, aba Atividade, tipo link_click. A rota responde o redirecionamento primeiro e só então emite o evento link.clicked em processo, e só quando há contato atribuído: clique anônimo, token de outro link ou token de outra empresa redirecionam e contam, e não atribuem nem disparam nada. O endereço curto do link passou a ser único em todo o produto, não mais só por empresa, porque o resolvedor não olhava a empresa e isso teria feito o evento nascer para a empresa errada. A merge tag {{link.<slug>}} nas ações de automação passou a expandir para a URL com o token daquele contato, com o endereço base vindo do ajuste shortlink_base_url, editável no painel, sem valor fixo no código. Na tela, o editor de automações passou a oferecer catorze gatilhos, um a mais que antes: entrou Clique em link rastreável, em Mensagens, confirmado na própria tela em produção. De quebra, a aba Atividade passou a exibir rótulo em português para os seis tipos de evento, que antes apareciam com o nome cru em caixa alta (NOTE, TASK). Gates: plan APPROVED, qa PASS, review APPROVED, zero Critical, checagem de antirregressão limpa. Migration 090 aplicada, com backup em /root/backups/mcrm/backup_pre_090_20260715_192803.dump; a prova de volta ao normal conferiu workflow_runs em 13 e trigger_links em 0, com a Hiit intacta, 1503 contatos. Duas ressalvas honestas ficam registradas: o caminho de agendamento com a variável do nome do contato não foi exercitado ao vivo, coberto por revisão de código, linhas não tocadas por esta entrega, e o aparelho móvel não foi verificado; e a variável do nome do contato chegou vazia na atividade disparada pelo clique, que é o defeito pré-existente já catalogado no {AUD-61}, não introduzido por esta entrega.

O {AUD-49} foi entregue em 2026-07-15 (merge 5e4f590), no mesmo dia em que nasceu. O webhook público de captura de lead chamava o motor de eventos com o campo errado e com o pacote de dados na forma errada; o motor recusava em silêncio, o contato nascia e a automação nunca rodava. Corrigido: agora chama certo, e a guarda do motor deixou de ser muda, passando a registrar no log o evento malformado em vez de sumir. Mas o planejamento desta fatia varreu por critério, não por amostra, todos os pontos do produto que criam contato, e achou uma realidade maior do que o card supunha: dezoito pontos criam contato, cinco emitem o evento de novo contato (quatro provados no backend e um, o do frontend, não provado; o número foi corrigido de quatro para cinco em 2026-07-16, e o conjunto passou a fechar) e treze não emitem; não é um quebrado mais um irmão, são um quebrado e treze mudos. O dado que mais incomoda: dos contatos dos últimos trinta dias, seis vieram do livechat, quatro do agendamento público e três do formulário, zero do webhook de captura de lead; os três caminhos com tráfego de verdade seguem mudos, e o {AUD-49} consertou o único caminho sem tráfego. O RF-AUTO-002 continua violado pelos outros caminhos e este card não o entrega. Seis cards novos nasceram desta fatia: {AUD-65} (a raiz, duas portas para o mesmo fato, uma exaustiva por construção via gatilho de banco e outra exaustiva só por disciplina, com recomendação de decidir por council antes de abrir os doze pontos mudos), {AUD-66} (os doze pontos mudos, nominais, priorizando livechat e formulário porque são os dois com tráfego real), {AUD-67} (lead com mensagem derruba o webhook com erro quinhentos, defeito pré-existente achado pelo qa), {AUD-68} (o passo de automação "adicionar tag" marca sucesso sem aplicar a tag, mesma família da Onda AUD), {AUD-69} (a guarda nova pode logar dado pessoal do contato, achado do review) e {AUD-70} (o {AUD-49} referenciava o requisito errado, RF-LEAD em vez de RF-CAPT-004, e o requisito de captura não reprova o silêncio da automação). Recomendação explícita: decidir o {AUD-65} antes de abrir os doze cards do {AUD-66} um a um, porque um conserto na raiz evita pagar doze vezes o mesmo tipo de correção.

Sessão de 2026-07-15 (quarta parte), o qa do {AUD-49} revalidado e duas fatias novas. O qa desta última entrega, testando com lead trazendo o campo de mensagem, achou que o webhook quebrava com erro quinhentos mesmo depois de criar o contato: virou o {AUD-67}, entregue no mesmo dia, merge aaa0c29. A causa era um catch encadeado num resultado da biblioteca de acesso ao banco que só parece uma promessa, mas não é uma de verdade (é thenable, não tem catch), e o TypeError também pulava a chamada seguinte do motor de eventos: lead com mensagem não disparava zero notas e zero execuções, não só erro quinhentos. Provado por controle antes e depois do conserto, e em produção depois: sucesso, nota gravada, evento contact.created, duas execuções, nota visível na tela do contato nos dois temas. Consequência para o {AUD-49}: por cerca de duas horas o marcador de concluído daquele card foi verdade parcial, porque o teste da época só exercitou lead sem mensagem; o qa desta fatia revalidou o {AUD-49} nos dois ramos e hoje o marcador de concluído é verdade de fato, com a nota registrada no próprio card. Na mesma varredura apareceram mais duas ocorrências do mesmo tipo de erro, em pontos que liberam o lock de conversa do Instagram e do Messenger dentro de um finally: o TypeError ali também mascarava a exceção original do try e impedia a mensagem do cliente de entrar no inbox. Viraram o {AUD-71}, P1 latente porque o caminho nunca rodou em produção (a conexão Meta está morta pelo {AUD-42}), entregue na mesma branch e no mesmo merge. O qa do {AUD-71}, medindo depois do conserto, achou que o lock às vezes continua preso por outra causa, arquitetural e pré-existente, lock de sessão combinado com o pool de conexão persistente do PostgREST: virou o {AUD-72}, P1, sem conserto nesta fatia. O mesmo qa mediu o contraste do rótulo da linha do tempo do contato e achou reprovação do RF-UX-004, pré-existente e não introduzida por nenhuma fatia recente: virou o {AUD-73}. Ao fim daquele dia o próximo item acionável da fila era o {AUD-57} (o agendamento público cria contato sem disparar automação), e a sessão seguinte mudou essa ordem: ver o parágrafo de 2026-07-16 abaixo.

Sessão de 2026-07-16, o {AUD-68} replanejado e o requisito que faltava. O planejamento do {AUD-68} varreu por critério, e não por amostra, as vinte e uma rotas de ação do motor de automação, e achou uma realidade maior que a do card: nenhuma delas confere o próprio efeito antes de dizer concluído. O estado do passo não vem da ação, vem da ausência de erro, e nada no motor produz erro, então o registro só sabe dizer uma coisa. O dado que fecha o diagnóstico: em toda a história do produto os passos de automação registraram dezoito vezes concluído, uma vez em execução, e nenhuma vez falha ou ignorado. Um campo de estado que só assume um valor não é estado, é enfeite. A emenda veio antes do código, e era obrigatória: nenhum requisito reprovava isto. O RF-CONV-054 trata da mensagem e o gatilho do H1 dele é o operador tentando enviar pela tela, então a condição dele nunca ocorre aqui, onde quem roda é o motor sozinho e metade dos casos não é mensagem nenhuma. Nasceu o RF-AUTO-044, publicado no DRS em 2026-07-16, que define os três desfechos do passo (concluído, ignorado, falha), o discriminador entre eles (a ausência é do dado ou da empresa, e então ignora e segue; ou é da configuração, e então falha e para), a divergência deliberada de que empresa sem canal conectado gera ignorado e não falha, e a regra de honestidade da lista de ações, espelhando a que o RF-AUTO-002 recebeu em 2026-07-15 para os gatilhos. O card {AUD-68} foi reconciliado no mesmo dia: ele apontava para o RF-CONV-054, que não o reprova, e prescrevia um conserto que o planejamento recusa por escrito (resolver o nome da tag em tempo de execução), porque faria o sintoma sumir deixando as outras vinte rotas mentindo. Quatro cards novos nasceram deste planejamento: {AUD-74} (a tela oferece duas ações que o motor não executa, e a que funciona não é oferecida: é o {AUD-43} de novo, agora nas ações), {AUD-75} (o modelo pronto entrega automação quebrada em um clique), {AUD-76} (a ação de enviar fatura não emite fatura e ainda registra que emitiu) e {AUD-77} (a condição não ramifica e criar tarefa está desativada). O momento é o mais barato que este conserto vai ter na vida do produto: o tenant piloto não tem automação nenhuma, e as duas automações ativas são de uma empresa de teste, então não existe automação de cliente real para quebrar. Quando houver, o mesmo commit teria que ser negociado com um cliente real. O {AUD-68} foi entregue em 2026-07-16 (commit 67224ec, merge 06e9724): o executor passou a derivar o desfecho de cada uma das vinte e uma rotas do que a rota de fato faz, em vez de assumir sucesso pela ausência de erro. Gates plan APPROVED, qa PASS, review APPROVED. O qa provou os sete discriminadores do H1 por efeito real no banco (concluído com efeito real, ignorado que segue por dado ou canal ausente, falha que para por configuração inválida ou ação que o motor não executa) e achou, de quebra, uma regressão restrita a um único workflow interno de dogfooding, sem alcance a cliente pagante, que virou o {AUD-78}. O review achou, fora do escopo da fatia, que a superfície de dado pessoal em log cresceu de um para cerca de doze pontos de escrita, anexado ao {AUD-69} já existente. O próximo item acionável da fila volta a ser o {AUD-57} (o agendamento público cria contato sem disparar automação): o {AUD-68} era escopo cravado por decisão direta do Wladimir e furou a fila por isso, não porque fosse o próximo por ordem.

Smoke visual real de 2026-07-16 (sessão viva em produção, modo claro e modo escuro) confirma o {AUD-68} na tela: a execução do "Welcome + Tag" aparece Falhou com o erro nomeado, e a Taxa de sucesso (30d) mostra 42,9% (6 de 14). O mesmo smoke revelou dois cards novos, {AUD-79} (o painel de automações conta zero workflows ativos com dois ativos na lista ao lado) e {AUD-80} (o nome do contato está vazio em 100% dos registros do tenant piloto, raiz que amplia o {AUD-61}), ambos ao final da Onda AUD. O próximo item acionável da fila passa a ser a fase F0 da sequência decidida no {AUD-65} (o council rodou em 2026-07-16 e a decisão está registrada naquele card); os dois cards novos entram na fila por prioridade, não furam.

Sessão de 2026-07-16 (segunda parte), reconciliação de texto: nenhuma linha de código de produto foi escrita. Esta sessão não entregou fatia nenhuma, e o que ela fez foi conferir no banco e no código o que os cards já publicados afirmavam. Três deles afirmavam fato falso e foram corrigidos aqui. (1) O {AUD-65} dizia "dezoito criam contato, só quatro emitem" e, na mesma frase, "treze mudos": os números não fechavam, porque a varredura procurou o nome do emissor do backend e não viu o emissor do frontend. São cinco emissores e treze mudos, e agora o conjunto fecha. Na terceira parte desta mesma data o quinto emissor deixou de ser dedução: foi medido em produção e emite de verdade. (2) O mesmo {AUD-65} mandava copiar o desenho dos webhooks de saída como se ele estivesse provado inteiro: a emissão está (3616 notificações), a entrega nunca rodou em tráfego real (zero enfileiradas, seis entregas de teste em maio, as assinaturas desligadas ou com filtro vazio), e "nunca perdeu um" é indistinguível de "nunca entregou nenhum". (3) O {AUD-80} se chamava "o nome está vazio em todos os registros": falso, 25 dos 25 contatos de canal vivo têm nome; o que existe é uma divisão limpa por caminho, a carga em lote de maio preenche uma coluna e todo canal vivo preenche a outra. O diagnóstico de fundo dos três continua de pé; o que mudou foram os fatos que os sustentavam. Nasceram seis cards, {AUD-81} a {AUD-86}, todos de defeito medido e nenhum de suposição, e o RF-AUTO-006 foi emendado para reprovar o {AUD-75}, que até hoje era um card que requisito nenhum reprovava.

O {AUD-57} NÃO foi executado nesta sessão, e a decisão é fundamentada. Ele era o próximo da fila, e não foi aberto de propósito: ele é sintoma, não raiz, e o próprio {AUD-65} manda decidir a arquitetura antes de abrir os doze pontos mudos um por um, porque a casa pagaria doze vezes um conserto que o desenho certo faria uma vez. O council do {AUD-65} rodou em 2026-07-16, convergiu, e a decisão está TOMADA e registrada no próprio card: o motor ganha exaustividade por construção para o fato contato criado, por gatilho no banco consumido pela fila que já existe, com sequência obrigatória de fases (medir a emissão da tela, chave de idempotência, salvaguardas com desligamento geral e listas de permissão, o gatilho, e só então remover os emissores antigos). Com a raiz decidida, o {AUD-57} deixa de ser o próximo item por si: ele migra para o desenho novo junto com os doze do {AUD-66}, em vez de ganhar correção pontual. Além disso a sessão achou um acoplamento que precisa ficar em ata: o {AUD-65} e o {AUD-80} são incompatíveis na mesma janela, porque o conserto do nome é uma atualização em massa em 1503 contatos e o gatilho de notificação já dispara em atualização; sem lista de permissão por tipo de evento, o card que conserta o nome vira o card que dispara automação para 1438 contatos reais.

Sessão de 2026-07-16 (terceira parte), a primeira medição que fechou um placar, e o que ela destravou. Esta sessão entregou o {AUD-82}: o mesmo fato disparado três vezes passou a gerar uma execução por automação, e não três, e quatro automações distintas ficaram com exatamente uma execução cada depois de o serviço reiniciar. O RNF-003 sai de violado por construção e passa a cumprido. O limite precisa ficar escrito, porque é o tipo de coisa que vira folclore: a chave protege contra a mesma coisa acontecer duas vezes, e NÃO protege contra o aviso se perder no caminho, porque o salto do banco até o ouvinte continua sem garantia. Ninguém pode vender a F3 do {AUD-65} como durabilidade resolvida por causa desta entrega.

Com a F1 cumprida, a F3 deixa de estar PROIBIDA pela falta da chave, e é só isso que mudou na ordem: ela continua atrás da F2 e da F2.bis, que são as salvaguardas, e essas não foram entregues. A F0 também fechou: o cadastro rápido de contato foi exercitado em produção e avisa o motor de verdade, com resposta de sucesso e o evento registrado no servidor. O quinto emissor era dedução e virou medição, e com isso o placar de cinco emissores do {AUD-65} está fechado por medição, e não por leitura de código. O defeito próprio daquele emissor continua real, mas mudou de natureza: ele engoliria uma recusa em silêncio, o que é risco latente e não falha viva, e por isso o {AUD-85} caiu de prioridade alta para média e a dúvida "será que emite?" saiu do card, respondida. Também se confirmou o {AUD-75} pelo lado que faltava: às 15:39 daquele dia o passo do modelo falhou com o motivo nomeado, em produção, o que prova de uma vez que o modelo curado entrega automação que não funciona E que o {AUD-68} está funcionando, porque o registro ficou honesto.

A F2.bis cresceu, e essa é a mudança de trabalho desta sessão. Ela era um emissor e virou o conjunto inteiro: quatro pontos do produto despacham whatsapp e nenhum deles decide pelo estado real do canal. Um pergunta por uma informação de estado que não existe e por isso nunca envia; os outros três seguem em frente sem olhar o estado do canal e sempre enviam, e um deles nunca tinha sido listado em card nenhum. A raiz é que não existe um lugar único que responda "esta empresa tem whatsapp utilizável?", então cada ponto refaz a conferência à sua maneira ou esquece dela, e é por isso que quatro pontos erraram de quatro jeitos diferentes. O {AUD-83} foi reescrito para cobrir o conjunto e para mandar criar esse lugar único, que é o que mata os casos de uma vez, e o {AUD-84} ficou irmanado a ele, porque consertá-lo sozinho LIGA um canal que está morto desde sempre. Nasceram dois cards: o {AUD-87}, um modelo aplicado que pode deixar a automação criada e vazia sem avisar ninguém, e o {AUD-88}, que endurece o requisito de honestidade do envio até ele reprovar o robô de conversa, hoje o único despachante que requisito nenhum reprova.

A F3 e a F4 do {AUD-65} foram entregues, e o motor de automação virou exaustivo por construção para o fato contato criado (2026-07-17). Um gatilho no banco, depois de cada inserção de contato, notifica um canal próprio, e a fila que já existe consome esse aviso e chama o emissor de eventos de sempre por um endpoint interno fail closed, sem nunca criar execução direto. Medido: um contato inserido direto no banco, sem nenhuma linha de código que anuncie o fato, dispara a automação, que é justamente o que a disciplina não garantia. Os cinco emissores antigos foram removidos um a um, cada um provado a seguir disparando só pelo gatilho, e não sobrou nenhum fora do trilho novo. A chave geral do motor, que shipou desligada, foi LIGADA em 2026-07-17 sob observação e com GO explícito do Wladimir, depois que o {AUD-100} foi resolvido, para o motor não estrear com automação quebrada. Prova de estreia: um contato de prova gerou duas execuções e o "Welcome + Tag" completou aplicando a tag de verdade. O escopo efetivo segue contido: a lista de organizações permitidas tem só a organização de teste (a Hiit segue fora por ausência de automação), a lista de eventos permitidos só tem contato criado, e o teto é de sessenta disparos por hora. Dois limites ficam declarados e não podem sumir: só o fato contato criado é por construção, os demais fatos seguem por disciplina e o {AUD-85} continua aberto; e o salto do gatilho até o ouvinte é dispare e esqueça, agora sem o cinto e suspensório que os emissores antigos davam, o que faz nascer o card de caixa de saída, o {AUD-99}. Um segundo card, o {AUD-100}, foi resolvido no mesmo dia: a única instância de automação com a configuração legada quebrada (um passo do "Welcome + Tag" da organização de teste) teve o nome da tag resolvido para o identificador e passou a aplicar a tag de verdade. O próximo item acionável da fila segue a ordem do próprio roadmap.

O {AUD-32} foi entregue em 2026-07-17 (merge 1ec9c8d, migration 094), o primeiro card aberto da fila na ordem do documento. O modo entrar como empresa do Super Admin passou a alcançar todo o canal /api do webhook: um auxiliar único no servidor honra a marca somente quando quem chama é Super Admin e foi aplicado nos cinco pontos que resolviam a empresa pela identidade do usuário; o frontend ganhou um ponto único de chamada que injeta a marca em toda requisição autenticada (37 chamadas roteadas, 11 públicas intocadas de propósito); os três repasses de links rastreáveis encaminham a marca; e a função do banco que cria o link rastreável passou a honrar a marca e ficou determinística. As provas foram em produção, com par positivo e negativo: a listagem de Caixas de Email deixou de vir vazia no modo, o link criado nasce na empresa escolhida e aparece na própria lista, membro comum forjando a marca não escala privilégio, e quem não é membro nem Super Admin segue bloqueado. A validação ainda achou e a própria fatia corrigiu um defeito irmão do {AUD-27}: a rota de gerar código Pix de fatura exigia um prefixo que o servidor de borda remove, então estava morta para qualquer usuário desde que nasceu; agora responde e foi exercitada de ponta a ponta em produção. Fronteira honesta: os dois endereços do canal alternativo de whatsapp seguem mortos para todos pelo defeito próprio do {AUD-96}, que já tem o auxiliar aplicado e passa a valer quando aquele card os religar. O {AUD-33} foi entregue em 2026-07-18 (merge eb2e875, migration 095): os cards Usuários e Contatos do painel da agência passaram a contar só as empresas reais, por função agregada com gate de Super Admin, e o valor deixou de variar conforme a empresa ativa. Da medição desta fatia nasceu o {AUD-101} (os gráficos das abas SaaS e Atividade contam empresas de teste, mesma família). O próximo card aberto da fila na ordem do documento é o {AUD-36}.

Sessão de 2026-07-18, o controle de acesso por papel virou produto de verdade, das três telas divergentes até a tela que o administrador usa. Três cards fecharam em sequência. O {AUD-38} (merge 3670d2f) fixou o catálogo canônico de treze módulos como fonte única no código e no requisito, e alinhou sete telas que perguntavam a permissão pelo módulo errado (Tarefas, Produtos e Formulários pediam Contatos, Automações pedia um módulo inexistente, Relatórios ganhou módulo próprio, Campanhas entrou com a ação de enviar, Caixas de Email passou a exigir Configurações). O {AUD-37} (merge d821fec) entregou a tela de Papéis e Permissões em Configurações, restrita a dono e administrador, com a grade de módulos e ações desenhada a partir do mesmo catálogo, criar, editar e excluir papel, e a atribuição de papel na tela de Minha Equipe, mais a migration 096 que fechou uma auto-escalação (qualquer membro escrevia na tabela de papéis, agora só dono e administrador). O qa reprovou a primeira rodada do {AUD-37} porque o banco recusava a escrita negada só em seis módulos: nasceu daí o {AUD-38b} (migration 097, mesma entrega), que estendeu o reforço às tabelas de Tarefas, Produtos, Formulários, Campanhas, orçamentos e cupons, provado ao vivo com token de membro real. O smoke real confirmou a tela em produção, claro, escuro e a 375px, sem rolagem horizontal. Próximo card aberto na ordem do documento é o {AUD-36}, o reforço de ver e exportar, agora exercitável porque a tela de papéis existe. Ainda nesta sessão, o planejamento do {AUD-37} havia revelado um defeito de segurança na regra de escrita de membros de empresa, que virou o {AUD-103} e foi entregue no mesmo dia (merge f6b3bfd, migration 098): um ramo escrito comparando uma coluna consigo mesma permitia que um usuário sem nenhum vínculo de empresa se inserisse como dono de qualquer empresa, e o ramo foi removido, deixando a escrita só para dono e administrador.

Sessão de 2026-07-19, o {AUD-36} fechou e o reforço de acesso por papel chegou à leitura. O {AUD-36} foi entregue (merge 151fef5, migration 099): a permissão de ver deixou de valer só na tela e passou a valer no banco, com quinze regras restritivas de leitura, uma por tabela, exigindo que o papel libere o módulo, nas mesmas quinze tabelas do mapa de escrita do {AUD-29} e do {AUD-38b}. Os dois medos do card foram refutados por medição: as páginas públicas leem por um caminho de servidor com acesso próprio e não caem, e os encaixes de dado de outro módulo foram mapeados, a linha-mãe sobrevive com o campo aninhado em branco em vez de a consulta voltar vazia em silêncio. Recorte declarado: exportar não tem endereço de servidor próprio, colapsa em ver no banco, e o delta ver-liberado com exportar-negado segue só na tela. Provado por qa com acesso de membro de papel restritivo (zero linhas em contatos, oportunidades e conversas onde existiam dezenove, dois e dez; dono, administrador, membro sem papel e Super Admin intactos; públicos funcionando), gates verdes e smoke visual real. Do qa desta fatia nasceu o {AUD-104}, fora do escopo do card: o Super Admin sem vínculo na subconta não cria papel pela tela e o botão trava em Salvando; está catalogado ao fim da Onda AUD. Nesta sessão o {AUD-38c} e o {AUD-38d}, que restavam como pendência de catalogação, entraram como cards da Onda AUD, cada um com o seu recorte do reforço de escrita que falta. Ainda em 2026-07-19 o {AUD-38c} também fechou (merge a7c92e1, migration 100): o reforço de escrita chegou às vinte e uma tabelas acessórias dos próprios módulos, com cinquenta e duas regras restritivas, junções protegidas pela permissão de editar da entidade mãe, captura pública de formulário intacta e os oito botões de excluir das telas alinhados à permissão. O próximo card aberto da fila na ordem do documento é o {AUD-38d}, os módulos de configuração e administração.

Sessão de 2026-07-19 (segunda parte), o {AUD-38d} fechou e o reforço de escrita por papel chegou aos módulos de configuração e administração. O {AUD-38d} foi entregue (merge cd5efd2, migration 101): vinte e sete regras restritivas de escrita em nove tabelas de Configurações e Administração, cada uma exigindo que o papel libere editar o módulo. O recorte real foi reconciliado com a medição: das onze tabelas nomeadas no título, nove foram gateadas e duas ficaram de fora por construção (snapshots e aplicações de snapshot, recurso do fornecedor, sem empresa dona, já restrito a Super Admin). Ficou registrada a nota honesta de que só quatro das nove têm efeito exercitável hoje (campos personalizados, integrações, SMS e WhatsApp) e as outras cinco são reforço defensivo, exaustivo por construção, sobre tabelas que dono e administrador já cobriam. Provado por qa com token de membro de papel restritivo de verdade, telas alinhadas ao gating de editar, caminhos de servidor imunes. Da medição nasceram dois cards ao fim da Onda AUD: o {AUD-105} (a leitura de Configurações e Administração ainda não é reforçada por papel no banco, gap que o {AUD-36} deixou fora ao cobrir só as quinze tabelas operacionais) e o {AUD-106} (o padrão do membro sem papel libera editar Administração por omissão, ao contrário de Configurações; decisão tomada em 2026-07-22, negar por simetria, o card virou o fix da migration 103). O {AUD-39} fechou nesta sessão (2026-07-19, merge 1c916d2, migration 102): a regra pública cega de leitura de calendários foi removida, e a leitura da biblioteca de modelos de automação passou a exigir login, com rascunho restrito ao Super Admin, provada por três identidades. O {AUD-41} fechou em 2026-07-22 (migration 103, merge 83cc7a0): a empresa deixou de ser provisionada sozinha ao criar um usuário.

Sessão de 2026-07-22 (S25), o {AUD-41} e o {AUD-107} fecharam. Migration 103 aplicada no banco do ModularCRM: o gatilho que, a cada usuário criado, criava perfil, empresa e posse dela junto, passou a criar só o perfil; o provisionamento de empresa ficou explicito, só pelo assistente do Super Admin, que já era o caminho oficial. O comentário do convite de membro foi corrigido para não prometer o que o código não faz. Entregue, qa PASS e review APPROVED (gates na VPS), merge 83cc7a0 em main, webhook reiniciado (200), smoke do painel de Subcontas confirmando só a Hiit Fitwear como cliente real e o painel sem tela branca. Na sequência, irmã do mesmo dia, o {AUD-107} fechou a porta da tela e do sistema de login que o {AUD-41} deixou aberta: GoTrue com auto-cadastro desligado (DISABLE_SIGNUP=true, recreate só do mcrm-auth, provado com 422 signup_disabled e convite por token de serviço funcionando com o auto-cadastro desligado), frontend sem a página pública de criar conta (redirecionamento para o login, CTAs removidos e repontados, smoke visual real na página de apresentação e na tela de entrada), migration 104 removendo a função generate_slug (zero chamador, rollback LIFO), qa PASS e review APPROVED (gates na VPS), merge b121c7d em main, site respondendo 200. Ainda no mesmo dia, a construção da Onda C-MCRM começou: a primeira sub-fatia do {C-MCRM-2} (conexão Meta permanente) entregou a etapa de configuração do aplicativo Meta (migration 105, merge e3a523e), com as sub-fatias 2 a 4 seguindo pendentes. Sessão de 2026-07-23 (S27), a sub-fatia 2 do {C-MCRM-2} fechou. O caminho primário de conexão com a Meta passou a ser o Login do Facebook para Empresas pelo aplicativo dedicado, com o tipo do acesso decidido perguntando à própria Meta em vez de assumido, e a validação de assinatura dos webhooks deixou de falhar aberta. Provado com clique real na tela de Integrações em produção. Merge f63ba42 em main, qa PASS e review APROVADO com comentários (gates na VPS), site respondendo 200 e nada de outro projeto na máquina afetado. O card {C-MCRM-2} segue em aberto porque as sub-fatias 3 e 4 não entraram. Nasceu o {AUD-109} a partir do olhar na tela.

Sobre o {AUD-42} (2026-07-23): o mecanismo que ele pedia está construído e no ar (sonda de hora em hora, estado honesto na tela, painel de saúde), mas o card segue em aberto por honestidade: o estado "expirada" nunca foi observado de verdade, porque provocá-lo exigiria invalidar a credencial viva de um cliente real. Está coberto por leitura de código e pelos dois gates, não por observação. Fecha de fato quando uma conexão real vencer ou quando a migração para o aplicativo novo criar uma janela segura de teste.

A fila seguinte, na ordem do documento: {AUD-104} → {AUD-105} → {AUD-106} → {AUD-108}. (O {AUD-44} e o {AUD-45} fecharam em 2026-07-24; o {AUD-109} fechou na S27. Nasceram o {AUD-110} e o {AUD-111} do planejamento do {AUD-45}.)

Cada tarefa é um card com um estado e um "Como verificar". Marcação: [x] concluído e em produção, [ ] pendente na retomada.

Planejamento (Fase 0)

Concluída na aprovação do DRS. Reúne o trabalho de elicitação, especificação e definição de escopo.

Fase M, Mockup Navegável

Etapa padrão pós-planejamento e pré-construção. Como o sistema já foi construído e está em produção, esta fase é retroativa: a referência visual é o produto em produção mais a paridade GHL, não um protótipo estático.

Fase 1, Pilares Core

1.1 Captura de Leads

1.2 Gestão de Leads

1.3 Conversas e Inbox

1.4 Experiência e Interface

Fase 2, Módulos Secundários

Fase 3, API Pública e Integrações

Fase 4, Habilitação do Tenant Piloto (retomada)

Ações operacionais para deixar a Hiit Fitwear 100% operacional. São o primeiro bloco da retomada.

Fase 5, Polimento e Evolução

Fase 6, Paridade GoHighLevel (backlog)

Backlog de paridade com o GoHighLevel, recortado em 2026-07-10 ao escopo real do produto (painel interno da Modulareasy, isolamento por subconta, sem revenda white-label). Cada card é uma área; o detalhe requisito a requisito, com H1, está na subseção do DRS. Sem data: é direção de produto, a priorizar por você. Retiradas do backlog: Telefonia, marketplace de desenvolvedores, Cursos e comunidades, Sites institucionais, Funis e Loja, e a parte de revenda do modo Agência.

Onda AUD, Correções da auditoria (2026-07-10)

Achados do walkthrough tela a tela de 2026-07-10, agora no formato de fatia executável: cada card traz sintoma, causa provável, o que fazer, como verificar e o aceite (H1). São correções do que já existe, não funcionalidades novas. Estão ordenados por prioridade: primeiro a segurança e os bloqueios de alto impacto (AUD-14, 01, 02, 07, 03, 04), depois os defeitos de tela de média prioridade (05, 06, 09, 08, 10), por fim o polimento (11, 12, 13). Cada card é uma fatia: branch própria, planner gate antes de codar, qa + code-reviewer, smoke visual real na tela afetada, e o checkbox só vira [x] com o aceite 100% cumprido. Pegar sempre o primeiro card [ ] na ordem abaixo.

Segurança e bloqueios de alto impacto

Defeitos de tela (média prioridade)

Polimento (baixa prioridade)

Achados do planejamento do {AUD-51} (2026-07-15)

Quatro achados que apareceram ao planejar o {AUD-51} e que ficaram FORA daquela fatia, de propósito: nenhum deles serve ao aceite dele, e enfiá-los na mesma entrega inflaria o diff e faria o card fugir do próprio H1. Ficam aqui porque achado que não vira card é invisível para a fila. Os dois primeiros são defeitos reais em produção hoje; o terceiro é o limite declarado da entrega do {AUD-51}; o quarto depende de uma decisão de produto que ainda não foi tomada.

  • Entregue em 2026-07-16, commit 67224ec, merge 06e9724, path específico webhook-index.js, com o webhook reiniciado e a prova rodada em produção. Zero migração, zero tela nova, zero DDL. Gates: plan APPROVED, qa PASS, review APPROVED.
  • Provas do qa (efeito real no banco, não só o próprio registro do passo): reprova antes, sem reverter código, usando dado histórico real (seis execuções antigas do workflow "Welcome + Tag" registravam concluído sem a tag "novo" jamais ter existido na empresa); anti-falso-positivo (tag real aplicada, linha real em contact_tags fora do próprio registro do passo, e o passo seguinte roda); dois casos de ignorado que segue (contato sem telefone, empresa sem canal de WhatsApp), cada um com o motivo nomeado e o passo seguinte rodando de fato; configuração inválida (identificador de tag ausente) fica em falha e a automação para, sem o passo seguinte ganhar linha; ação que o motor não executa (nome que a tela oferece e o motor não implementa) fica em falha e a automação para; remover uma tag que o contato nunca teve permanece concluído, porque zero linhas apagadas é o estado desejado alcançado.
  • Achado do qa fora do escopo desta fatia, correto pelo H1 e não bloqueante: rodar o evento real contra os dois workflows ativos da organização de teste (dogfooding da própria Modulareasy) mostrou o "Follow-up automático" sem mudança de comportamento, e o "Welcome + Tag" passando a falhar e parar no primeiro passo, porque o passo de adicionar tag daquele workflow está configurado com o nome da tag em vez do identificador, e nunca resolveu para uma tag real. Auditado nas seis organizações do banco por critério, não por amostra: o padrão existe num único workflow, este; a Hiit, tenant piloto, tem zero workflows; zero exposição a cliente pagante. Virou o {AUD-78}.
  • Achado do review, fora do escopo desta fatia, anexado ao {AUD-69} já existente: a superfície de dado pessoal em log e erro cresceu de um ponto de escrita para cerca de doze, sem filtro.
  • Confirmação visual (2026-07-16, sessão viva em produção, modo claro e modo escuro): o Dashboard de Automações mostra a execução do "Welcome + Tag" como Falhou, em vermelho, com o erro nomeado (Step add_tag failed: add_tag: configuracao invalida, tag_id ausente), e a Taxa de sucesso (30d) passa a mostrar 42,9% (6 de 14), honesto contra os 100% falsos de antes. O mesmo smoke achou dois defeitos novos, adiante neste roadmap em {AUD-79} e {AUD-80}.
  • Adendo do review do {AUD-68} (2026-07-16, achado I1, fora do escopo daquela fatia, anexado aqui por já existir card para a classe): a superfície de dado pessoal em log e erro cresceu de um ponto de escrita para cerca de doze (onze rotas do executor mais o novo log central do passo), cada uma propagando a mensagem de erro crua do banco sem filtro. Não é regressão, e nenhuma rota interpola campo de contato direto na mensagem, mas a área que este card cobre ficou maior: o mesmo risco descrito acima, log sem filtro de dado pessoal, agora em mais lugares.

Achados do planejamento do {AUD-68} (2026-07-16)

Os quatro cards abaixo nasceram da varredura por critério das vinte e uma rotas de ação do motor de automação, feita no planejamento do {AUD-68}. Todos vêm DEPOIS do {AUD-68}, e a ordem não é preferência: é o {AUD-68} que torna estes visíveis, porque com o desfecho padrão virando falha eles gritam na primeira execução. Consertar qualquer um deles antes apagaria a única reprova natural que existe hoje em produção. Os quatro compartilham a raiz que o {AUD-68} não cobre: o {AUD-68} torna honesto o registro do que o passo tentou, e não do que o passo deveria ser.

Achados do smoke visual real (2026-07-16)

O Wladimir abriu o Dashboard de Automações em produção (organização Modulareasy, sessão viva) depois de disparar um lead real, em modo claro e modo escuro, e confirmou visualmente o {AUD-68}: a execução do "Welcome + Tag" aparece Falhou, em vermelho, com o erro nomeado (Step add_tag failed: add_tag: configuracao invalida, tag_id ausente), e a Taxa de sucesso (30d) passou a mostrar 42,9% (6 de 14), um número honesto contra os 100% falsos de antes. O mesmo smoke revelou dois defeitos que nenhuma query tinha mostrado, abaixo.

  • Entregue em 2026-07-16, e o H1 está fechado pelos dois lados, por execução e não por dedução. A página de entrada passou a ser conferida com o servidor a cada abertura, e os demais arquivos, que já carregam identificação de versão no próprio nome, seguem guardados por muito tempo, que é o desejado. As duas metades do aceite foram medidas em separado. A primeira, que o navegador confere a cada abertura: em navegador real com perfil que persiste, em três aberturas seguidas e sem limpar nada, a página de entrada foi conferida com o servidor todas as três vezes, enquanto os 34 pedidos dos demais arquivos vieram do arquivo local do navegador sem ida ao servidor: o conserto é seletivo, e foi provado seletivo. A segunda, que quem tem versão antiga recebe a nova: um navegador que guardava a versão atual recebeu a resposta curta de zero byte, e um navegador que guardava versão obsoleta recebeu a versão nova inteira, sem limpar nada e sem forçar recarregamento. Como a página de entrada é a que nomeia todos os demais arquivos pela versão deles, recebê-la nova é receber o sistema novo, e não existe no produto nenhuma outra camada de guarda que possa contornar isso. O que NÃO foi exercitado, e fica registrado: a cerimônia completa de publicar uma versão nova e vê-la aparecer, porque não houve publicação nova durante o teste. O que se fez foi medir cada elo da corrente em separado, inclusive o elo decisivo, que é o navegador com versão antiga pedindo e recebendo a nova. Resta um efeito de transição, honesto e que se resolve sozinho: o navegador que guardou a página de entrada ANTES desta entrega a guardou sem instrução de validade nenhuma, e pode levar a própria janela curta dele para voltar a perguntar, uma única vez. Nenhum conserto desta natureza alcança o que já foi entregue antes dele, e o aceite não pode exigir isso. Fica registrada também uma imprecição deste próprio card, que a entrega revelou e que marcar o card não conserta: ele cita como requisito o RNF-009, que trata de isolamento de infraestrutura entre produtos e não alcança nada do que este card trata. Nenhum requisito publicado reprova o defeito que este card corrigiu, o que o tornaria imortal se ele não tivesse sido feito. É a mesma lacuna do {AUD-92}, na família de operação e implantação em vez da de credenciais, e ela segue aberta.

Onda C-MCRM, Conexão Meta permanente e captura confiável de leads (2026-07-22)

Origem: council de arquitetura de 2026-07-22 (GO condicional), a partir do requisito do dono de conexão Meta permanente e de que o CRM não pode perder lead. Esta onda reflete a revisão dos RFs de captura P1 (RF-CAPT-001, RF-CAPT-008 a RF-CAPT-010) e de integração Meta (RF-INT-001, RF-INT-005, RF-INT-006) no DRS. É a raiz da correção do {AUD-42} (conexão Meta morta) e absorve o padrão do {AUD-99} (caixa de saída) para o enriquecimento de leads. O construto novo é greenfield: a conexão Meta atual já está morta, então nada em produção se perde ao construir o mecanismo novo. Prioridade relativa à fila vigente. A fila do MDS segue na ordem do documento: o próximo card continua sendo o {AUD-41}, depois o {AUD-42}. Esta onda é pilar P1 core (captura de leads Meta), então tem precedência de produto sobre o backlog de auditoria de prioridade média e sobre a Fase 6; a sequência exata entre o {AUD-41} e o início desta onda fica para o Wladimir cravar na próxima sessão do MCRM. O gate externo (verificação de negócio e revisão de acesso avançado da Meta) tem calendário próprio e não é controlado pelo produto, por isso o {C-MCRM-1} pode começar em paralelo desde já sem bloquear o restante da fila. Ordem interna da onda: {C-MCRM-1} destrava tudo; {C-MCRM-3} independe de {C-MCRM-2}; {C-MCRM-4} depende de {C-MCRM-2} e {C-MCRM-3}; {C-MCRM-5} converge no destino de {C-MCRM-4}; {C-MCRM-6} fecha o {AUD-42} junto com {C-MCRM-2}; {C-MCRM-7} entra por último.

O card {C-MCRM-2} segue em aberto de propósito: o mecanismo inteiro está construído, mas ninguém ainda se conectou pelo caminho primário. Falta gravar o segredo do aplicativo novo e uma pessoa autorizar na Meta, os dois do {C-MCRM-1}. Enquanto o segredo não é gravado, o sistema opera coerente no aplicativo antigo e vira para o novo de uma vez só quando ele chegar.

Defeito encontrado e corrigido na mesma sessão, que teria quebrado a conexão: a configuração estava sendo montada campo a campo e misturava a identificação do aplicativo NOVO com o segredo do aplicativo ANTIGO. A Meta recusava esse par, então a autorização teria falhado no retorno, depois de a pessoa já ter autorizado. A escolha da fonte passou a ser atômica: ou tudo da configuração, ou tudo do ambiente, nunca metade de cada. O que ainda não pôde ser provado ponta a ponta é a autorização em si, que exige uma pessoa autorizando na Meta, e a gravação do segredo do aplicativo novo, ambas do {C-MCRM-1}. Ressalva de segurança (achado do review, 2026-07-22, RESOLVIDA em 2026-07-23 na sub-fatia 2): a validação de assinatura do webhook Meta lia o segredo antigo direto da variável de ambiente e falhava aberta, ou seja, deixava passar, se essa variável sumisse. Agora ela lê a configuração cifrada, nega quando não há segredo nenhum, e aceita durante a migração tanto o segredo do aplicativo novo quanto o legado da variável antiga, para que gravar o segredo novo não derrube de uma vez os webhooks das conexões que ainda assinam pelo aplicativo antigo. A guarda também ganhou a garantia de nunca derrubar o processo: qualquer falha ao ler a configuração vira recusa, não queda do serviço inteiro.

Definição de Pronto da Onda C-MCRM. Uma empresa conecta a Meta uma vez e recebe leads sem religar de rotina; um lead nunca se perde (webhook assinado independe do acesso, reconciliação cobre o que o webhook não entregou, enriquecimento fica retido até reconectar dentro da janela da Meta); acesso morto vira alerta acionável na Central com a marca da agência, e "conectada" nunca aparece sobre acesso morto; os valores de operação são editáveis pelo painel. Isso fecha o {AUD-42} e absorve o {AUD-99} para a captura de leads. A migração das conexões sociais de outro produto é ciclo separado e não faz parte desta onda.
Documento Roadmap de Implementação, ModularCRM
Metodologia MDS · Modular Development Style · 15 blocos / 86 campos
Publicado por Modulareasy
Site modulareasy.com/metodologias/mds