ModularReports: Questionário de Elicitação

Quando você habilita o ModularReports para uma agência parceira (por exemplo V4 ou ADS4PROS), o admin dela entra pela primeira vez. Antes de conseguir montar o primeiro relatório, o que ela é obrigada a configurar?

Recomendação: exigir só a identidade visual da agência (cor e logo, que vão no chrome e no link do cliente). O resto (primeiro cliente, primeiro template) fica opcional, para não travar quem só quer testar.

Resposta:

Comentar em um relatório exige que o cliente esteja logado (a conta é do ModularHub, o cadastro de contato já é função dele). A pergunta é sobre o gesto do operador: ele libera esse acesso de dentro do ModularReports, com um botão "ativar acesso aos relatórios" na ficha do cliente, ou isso é feito à parte, no cadastro de contato do ModularHub?

Recomendação: um botão "ativar acesso" dentro do ModularReports, na ficha do cliente, que aciona o cadastro do ModularHub por baixo. O operador não precisa sair da ferramenta.

Resposta:

Um template é um tipo de relatório com os blocos padrão que ele deve ter (resultado de campanha, comparativo de anúncios, trimestral, sazonal). Quando uma agência começa, a biblioteca dela já vem com alguns modelos prontos, feitos pela Modulareasy, que ela pode usar e adaptar? Ou cada agência começa do zero e cria os seus?

Recomendação: vir com alguns modelos de fábrica (os tipos mais comuns), que toda agência recebe e pode duplicar e customizar. A agência também cria os próprios do zero quando quiser.

Resposta: RESPONDIDO em 2026-07-30. Não é escolha por projeto, é o padrão da casa: "todo template no sistema segue o esquema de Global (ativado e manipulado pelo super admin) e individual (criado pelo usuário mas não marcado como global pelo super admin, que pode fazer isso quando quiser)". Um template nasce individual (do usuário que o criou, no escopo da própria agência) e o Super Admin pode marcá-lo como Global quando quiser; templates Globais são manipulados só pelo Super Admin. Logo, a biblioteca de uma agência começa com os Globais que existirem e cresce com os individuais dela. Virou regra do sistema no DRS (RN-013, RF-ADM-009, RF-ADM-010, RF-ADM-016, RF-ADM-017) e Fatia 10 do Roadmap. Nota de 2026-08-02, sobre a redação da pergunta acima: os exemplos citados nela misturavam duas coisas que o sistema separa, o propósito do relatório e a periodicidade dele. Um template é tipo por PROPÓSITO (campanha, fechamento, pesquisa); a periodicidade é atributo da instância (ver {Q4} e RN-014). A biblioteca Global nasce com DOIS modelos do Ap.9 do DRS, os que estão sustentados por mais de um relatório real já entregue. Um terceiro modelo existe e nasce individual da agência de origem, e não Global, porque uma única amostra, ainda por cima em formato antigo, não sustenta apresentar uma hipótese a todas as agências como se fosse o jeito certo de fazer; promovê-lo é gesto seu quando aparecer um segundo caso real.

Um relatório pode comparar dois períodos (por exemplo, o mês atual contra o mês anterior, ou a campanha de agora contra a campanha passada), ou cada relatório cobre sempre um período único e fechado?

Recomendação: permitir um bloco de comparação com o período anterior quando ele existir. Isso dá contexto ao cliente e evita que o relatório do mês seguinte pareça repetido.

Resposta: RESPONDIDA POR CONSEQUÊNCIA em 2026-08-03, pela resposta de {Q4b}. Sim, o relatório compara períodos, e na edição gerada pela agenda a comparação com a edição anterior é automática, porque é ela que dá sentido à cadência (RF-CMP-027). As duas guardas de honestidade da comparação seguem valendo do mesmo jeito, como já valiam antes desta resposta: comparação entre janelas de larguras diferentes (um trimestre com um mês de dados contra o trimestre cheio do ano anterior, caso real que já produziu uma queda de 71 por cento que não existia) é recusada ou sai com a marca explícita de janela parcial; e métricas que não se somam entre janelas (alcance, usuários únicos, visitantes únicos) usam o pico, nunca a soma. Se a leitura acima não for a sua, ela é o ponto a corrigir: o que registramos é que comparar é automático na edição agendada.

Quando você diz que vai usar muito relatório quinzenal, mensal, trimestral, semestral e anual, existem duas leituras possíveis, e elas produzem sistemas bem diferentes. Não dá para escolher uma por dedução: as duas são plausíveis e nós não sabemos qual é a sua.

Leitura A, o sistema gera sozinho. Chegou o fim do mês, o sistema monta o relatório daquele cliente por conta própria, já comparando com a edição anterior, e avisa você para revisar e publicar. A cadência é um agendamento de verdade.

Leitura B, você cria cada um à mão. Você abre o assistente quando quer, escolhe o cliente e o período, e a cadência é só o rótulo que diz que aquele relatório é o mensal, o trimestral ou o anual. Nada acontece sozinho.

Por que isto importa e não é detalhe: a leitura A exige uma peça que hoje está escrita no documento como evolução futura e fora da primeira versão (a fila que compõe em segundo plano e guarda o progresso). Se a resposta for A, essa peça deixa de ser evolução e vira parte do produto. Se for B, o que já está construído basta.

Recomendação, e ela vale para as duas respostas: manter a cadência como um campo que você declara no relatório (com um valor sugerido pela conta do cliente e pela largura do período que você escolheu, mas nunca adivinhado em silêncio), e manter o tipo de relatório fechado nos três propósitos que existem hoje, campanha, fechamento e pesquisa. Propósito e periodicidade são duas coisas independentes, e misturá-las numa lista só produziria quinze tipos de relatório, quase todos natimortos. O peso do argumento está no jeito como o modelo errado falha: ele não quebra, ele entrega uma página que PARECE certa (um aviso de "sem base de comparação" aparecendo justamente para o cliente que tem doze meses de histórico), e ninguém reporta o que parece certo.

Resposta: RESPONDIDA em 2026-08-03. É a leitura A: o sistema gera sozinho. Palavras suas: "Sim, configuravel, editavel, e ativavel (pausável)". As quatro palavras foram tratadas como requisitos e não como adjetivos, e cada uma virou requisito com critério de aceite próprio. Configurável: você declara a periodicidade, o dia do ciclo em que a edição deve nascer, o modelo e quem revisa, por cliente e por propósito, com uma agenda só para cada par (RF-ADM-019). Editável: muda depois sem recriar, e a agenda continua sendo a mesma, com as edições que já gerou ainda ligadas a ela (RF-ADM-020); recriar a cada mudança partiria o acervo do cliente em dois e esvaziaria a base de comparação justamente do cliente mais maduro. Ativável e pausável: pausar só impede o nascimento de edições novas, e não apaga a configuração, o histórico, os relatórios já gerados nem os links já entregues ao cliente (RF-ADM-021); retomar segue do próximo período à frente e nunca despeja de uma vez os períodos que passaram, que ficam listados para você recuperar à mão o que quiser (RF-ADM-022). A edição nasce em rascunho já comparada com a anterior (RF-CMP-027).

Com isso, a peça que estava escrita como evolução futura passou a ser parte do produto, como esta pergunta antecipava. Duas consequências ficaram escritas porque já se sabe onde elas doem. A primeira: a geração automática não publica sozinha e não ganha atalho nenhum pelas conferências de honestidade, senão a automação vira o caminho de fuga de todas as guardas, justamente por rodar sem ninguém olhando e em volume (RF-CMP-028). A segunda: numa cadência curta e automática as edições passam a nascer no ritmo do calendário e não no seu, o que pressiona muito mais a guarda que evita relatório repetitivo; por isso a correção dela, que passa a comparar variação do DADO contra variação do TEXTO, virou pré-requisito da agenda e não melhoria paralela. Sem essa correção, punir repetição de texto empurra a redação a inventar variação onde o dado não variou. Virou a Fase F19 do Roadmap, com nove cartões.

Medido durante a construção da Fatia 1, em 28 de julho de 2026: a conta gratuita do provedor de IA que a plataforma usa hoje tem um teto de 100 mil palavras-token por dia, e o próprio protótipo consumiu esse teto em um dia de trabalho (99.492 de 100.000). O segundo provedor gratuito, que servia de reserva, está indisponível. Na prática, a cadeia gratuita de hoje comporta poucas dezenas de relatórios por dia, contando as conferências de qualidade, e quando ela acaba a composição simplesmente não roda.

Isso não impede construir o sistema: a parte que garante os números (extração, proveniência, guardas de honestidade) não usa inteligência artificial nenhuma e continua funcionando. O que fica limitado é a escrita da narrativa e a medição de qualidade.

Recomendação: manter a regra de nunca subir para modelo pago em silêncio, e decidir uma entre três saídas: (a) aceitar o teto atual e operar poucos relatórios por dia enquanto a ferramenta é de uso interno; (b) repor um segundo provedor gratuito na plataforma-mãe, o que devolve a reserva sem custo; (c) contratar uma faixa paga apenas para a composição, com teto de gasto declarado por agência. A escolha muda quantos relatórios por dia a operação aguenta, não muda nenhuma garantia de veracidade dos números.

Resposta: RESPONDIDO em 2026-07-29. Montar uma STACK de provedores gratuitos (não apenas repor um), aproveitando os que a plataforma-mãe já tem configurados e criando a estrutura necessária no servidor quando fizer falta. A cadeia passa a encadear vários provedores gratuitos com troca automática quando um esgota a cota do dia. Segue valendo: nunca subir para modelo pago em silêncio, e falhar de forma explícita se toda a stack cair. Complemento do dono, mesmo dia: a operação fica só com IA gratuita (sem crédito pago), mas com comunicação explícita ao operador sobre o que aconteceu e um botão de um clique para avisar o admin da agência quando a stack inteira cair (RF-CMP-020, {F8-14}).

A régua de qualidade da narrativa foi construída a partir das regras de redação do próprio documento (toda afirmação ancorada em um dado, comparação sempre com fonte nomeada, lacuna declarada). Ao rodá-la sobre o acervo real de relatórios já entregues, dois deles ficaram abaixo do piso, justamente na dimensão de honestidade comparativa: usam comparações vagas, sem dizer de onde vem o parâmetro ("muito competitivo para o nicho").

Ou seja: a régua nova é mais exigente do que a prática que a agência vinha seguindo. Isso é um bom sinal para o produto, mas derruba a premissa de que o acervo antigo pode servir como exemplo de nota máxima para calibrar a régua.

Recomendação: manter a régua como está (ela está funcionando: separa relatório bom de relatório degradado com folga), tratar o acervo antigo como material de referência de conversão e não como padrão de qualidade, e medir o portão de qualidade sobre o que a ferramenta produz, que é o que precisa ser bom daqui pra frente.

Resposta: RESPONDIDO em 2026-07-29. Manter a régua exigente. O acervo antigo passa a ser material de referência de conversão, não padrão de qualidade; o portão mede o que a ferramenta produz daqui pra frente.

Existem hoje dois caminhos para uma página de resultados chegar ao cliente: o renderizador que já atende os clientes e este produto novo. A pergunta é o que acontece com o primeiro.

Se substitui: existe uma migração a planejar (o que acontece com os links já entregues aos clientes, o que acontece com as páginas publicadas, e a partir de que data nenhum relatório novo sai pelo caminho antigo).

Se convivem: precisamos saber por qual critério cada relatório vai para um ou para o outro, e quem decide isso na hora. Sem esse critério, a decisão acaba sendo tomada caso a caso por quem estiver montando, e os dois sistemas divergem sem que ninguém tenha decidido que eles deveriam divergir.

Por que isto importa: enquanto não se decide, o produto novo persegue um alvo que se move a cada pedido de cliente que chega pelo caminho antigo. Toda funcionalidade nova que aparece lá vira, no dia seguinte, uma pergunta aqui sobre se precisamos ter também.

Resposta: RESPONDIDA em 2026-08-03. Não substitui nada por enquanto. O "por enquanto" ficou preservado no documento como parte da decisão: ela é reversível, não permanente, e o dia em que você quiser trocar de ideia não vai encontrar nada escrito como se fosse definitivo. A consequência registrada é que os dois convivem e que este produto não herda automaticamente cada mudança que o outro receber. Um bloco novo, um componente novo ou uma regra nova que nasça lá entra aqui por decisão sua e por cartão no Roadmap, com o mesmo critério que usamos para os blocos (quantos relatórios reais já usam aquilo), e nunca por espelhamento. Divergência entre os dois passa a ser estado esperado, não defeito a corrigir por padrão. Enquanto esta for a decisão vigente, nenhuma migração de links ou de acervo é planejada. Virou regra do sistema (RN-019) e decisão de arquitetura (ADR-024).

Uma parte desta pergunta continua sem resposta e virou {Q5c} abaixo, porque ela só existe no cenário de convivência: por qual critério cada relatório novo vai para um ou para o outro.

A construção chegou no ponto em que o Reports precisa ser reconhecido pelo ModularHub: aparecer na lista de módulos, ter a chave de liberação por agência (desligada por padrão) e usar os papéis de acesso do Hub. Até aqui, tudo foi construído sem tocar no ModularHub: o Reports tem o seu próprio espaço no banco, o seu próprio código e o seu próprio ritmo.

Dar esse passo significa editar o ModularHub, que está no ar com clientes reais e tem o seu próprio processo de aprovação e publicação. São duas mudanças pequenas mas em produto alheio: liberar a chave nova na tabela de módulos e refletir isso no código que lista os módulos.

Recomendação: fazer isso quando a tela do operador (a fatia seguinte) estiver pronta para ser ligada, e fazer pelo processo do próprio ModularHub, com os gates dele. Antes disso não há ganho: o Reports não tem tela para o entitlement liberar. Enquanto essa decisão não vem, a construção segue nas partes que não dependem dela.

Resposta: RESPONDIDO em 2026-07-29. Fazer agora. O registro do módulo, a liberação por agência (desligada por padrão) e as permissões entram já, pelo processo do próprio ModularHub (branch, gates e deploy dele).

Você respondeu em {Q5b} que o ModularReports não substitui nada por enquanto, e isso resolveu a parte maior. Sobra a parte de operação: quando chegar o próximo pedido de relatório, ele é montado aqui ou no sistema antigo, e quem decide isso na hora?

Sem um critério escrito, a decisão acaba sendo tomada caso a caso por quem estiver montando, normalmente pelo que estiver mais rápido naquele dia. O efeito é lento e difícil de perceber: os dois sistemas divergem sem que ninguém tenha decidido que eles deveriam divergir, e um ano depois cada um atende um pedaço da carteira por acidente histórico.

Recomendação: um critério simples e verificável, não uma política. Por exemplo, todo relatório de cliente que já tem agenda aqui é montado aqui, e o resto continua no caminho antigo até você mandar mudar. Qualquer critério serve, desde que caiba numa frase e possa ser conferido depois; o que não serve é não ter nenhum.

Resposta: RESPONDIDA em 2026-08-03. Palavras suas: "a princípio no novo só relatórios manuais, mas isso não importa muito".

Registramos as DUAS partes, porque a segunda muda o que se constrói. O critério: por enquanto, o sistema novo recebe os relatórios montados à mão, e o caminho antigo segue com o resto. O peso: "não importa muito", e isso é informação de projeto, não modéstia. Significa que não se constrói regra elaborada de roteamento: nada de seletor de sistema no assistente, nada de campo de destino no cadastro do cliente, nada de decisão automática de qual sistema recebe cada relatório. Quem monta escolhe onde monta, e pronto.

A razão de escrever isso explicitamente é que a primeira metade sozinha convida a construir um mecanismo. Alguém lê "o sistema novo recebe relatório manual", entende que existe uma regra de roteamento a implementar, e entrega um seletor que ninguém pediu e que depois precisa ser mantido. A {Q5b} já tinha dito que os dois convivem; esta diz como conviver na prática, que é sem cerimônia.

A camada de resultado que veio da sua planilha de gestão tem dezenove métricas, e sete delas são dado comercial da agência e não do cliente: o fee cobrado, a margem de contribuição, o multiplicador de recompra e os lucros calculados a partir deles. Elas existem no sistema porque a agência precisa delas para gerir. A pergunta é se elas também aparecem na página que o cliente abre.

Isto é diferente de todas as outras guardas do sistema, e por isso é pergunta e não decisão nossa: nenhum conferidor de honestidade pega este caso, porque o número é verdadeiro. Um fee correto na página do cliente não é um erro de dado, é uma decisão comercial que só você pode tomar.

Recomendação, e ela já está valendo como default seguro: essas sete nascem marcadas como internas e NÃO entram na página publicada (o corte acontece na hora de publicar, tirando o número do conteúdo servido, e não só escondendo na tela). Elas seguem visíveis para você e para o admin da agência enquanto o relatório é montado. Afrouxar isso é gesto explícito do admin da agência, métrica por métrica, e vale só dos próximos relatórios em diante. Se a sua resposta for que o cliente pode ver alguma delas, é só dizer quais.

O default estar valendo não responde a pergunta. Ele existe para que nada vaze enquanto você decide, e não para encerrar o assunto por conveniência. Esta pergunta segue aberta até você responder, mesmo com a proteção em vigor.

Resposta:

Ao montar um relatório você escreve um nome para ele, e a partir de agora dá para trocar esse nome a qualquer momento enquanto ele é rascunho. A pergunta é o que esse nome deveria fazer.

Hoje ele é um nome interno: aparece para a sua equipe, na lista de relatórios e na ficha do cliente, e serve para achar a peça depois. Ele não chega à página que o cliente abre por caminho nenhum. O que o cliente vê como título da aba do navegador, e no cartão que aparece quando o link é compartilhado, é o texto do card de compartilhamento, que é outro campo, escrito na hora de publicar.

Isso não é defeito, é uma escolha que nunca foi feita explicitamente, e ela tem dois desfechos legítimos.

Cenário 1, o nome continua interno. Nada muda. Você nomeia a peça pensando na sua operação ("Fechamento junho, revisão 2"), com a liberdade de escrever o que ajudar a equipe, e quem cuida do que o cliente lê é o card de compartilhamento, preenchido no momento de publicar. O preço: são dois campos para manter, e quem publicar com pressa deixa o card no texto genérico, e aí o cliente recebe um link sem título próprio.

Cenário 2, o nome vira o título público. O nome do relatório passa a ser o título da página do cliente quando o card de compartilhamento não for preenchido. Você escreve uma vez e serve para os dois lados. O preço, e ele é real: o nome deixa de ser espaço livre da equipe, porque passa a ser lido pelo cliente; e, por ser texto seu que chega à página, ele entra na mesma disciplina que vale para todo texto do relatório, ou seja, um número dentro do nome ("340 leads em junho") passaria a ser recusado na publicação, exatamente como já acontece na legenda de um criativo.

Recomendação: Cenário 1. É o que já está valendo, o card de compartilhamento existe justamente para o texto que o cliente lê e já tem prévia de como o link aparece, e o Cenário 2 troca liberdade de nomeação interna por uma conveniência que o card já cobre. Se você preferir o Cenário 2, ele é barato de construir, mas a regra do número no nome vem junto e não é negociável, porque é ela que sustenta a página inteira.

Resposta: