Programa Visual Digital (PVD) — Documento Conceitual Fundacional

BAZEá · v2.0

---

1. Preceito fundamental

O PVD deixa de ser um repositório de assets (logotipo, cores, tipografia, componentes) e passa a ser o sistema vivo que rege tudo o que a marca é, vive, faz e fala — expresso e mantido digitalmente.

A referência doutrinária é o conceito de Design Total, de Ana Couto: branding não é identidade visual, é a integração coerente entre estratégia de negócio, cultura interna, experiência do cliente e comunicação. A identidade visual é consequência dessa integração, não seu ponto de partida.

Essa lógica converge com o legado de Ulm e Wollner, citado na fonte de referência do projeto: design é projeto, não ilustração — sistêmico, não isolado. A forma é sempre consequência de uma decisão intelectual prévia; sem análise, não há design, só ruído visual.

Regra de ouro do PVD: nenhum elemento visual, textual ou comportamental existe sem rastreabilidade até um princípio do Embasamento Visual. Se uma cor, um componente ou uma frase de tom de voz não pode ser justificada por um princípio da camada 1, ela não pertence ao PVD — é decoração.

---

2. As seis camadas

O PVD é hierárquico e causal. Cada camada só existe porque a anterior a fundamenta. Não são módulos paralelos de um manual — são níveis de derivação. Nomenclatura ancorada no texto de referência wollneriano indicado para o projeto (ver Anexo A).

Camada 1 — Embasamento Visual (o que a marca É)

Propósito, valores, território de atuação, arquétipo, posicionamento.

Ancoragem: a "Fase da Informação" do texto de referência — "informar para dar forma", a imersão em enfoque da empresa, problemas existentes e referências universais antes do primeiro traço.

Isso não é conteúdo do PVD — é sua constituição. Toda decisão nas camadas seguintes precisa remontar a um princípio definido aqui. É a camada que responde: por que essa marca existe e o que ela nunca vai ser.

Camada 2 — Postura Visual (o que a marca VIVE)

Como o time se comporta, decide e se comunica internamente. Rituais, forma de tratar cliente/paciente/usuário no dia a dia, valores praticados vs. valores declarados.

Sem esta camada, o PVD vira teatro: a marca parece uma coisa para fora e é outra por dentro. É a camada mais frequentemente ignorada em PVDs tradicionais — e a que mais rápido expõe incoerência quando ausente.

Camada 3 — Gestalt Visual (o que a marca FAZ)

Jornada do cliente ponta a ponta, touchpoints físicos e digitais, momentos de fricção e de encantamento.

Ancoragem: o conceito de "Gestalt Completa" do texto de referência — um projeto só atinge maturidade quando verificado em todas as suas extensões e aplicações, funcionando "sem o autor", como sistema autoexplicativo.

A maioria dos design systems de mercado nunca chega até aqui. No PVD, a experiência é onde o Embasamento é testado contra a realidade — um princípio que não se sustenta na jornada real é um princípio mal formulado.

Camada 4 — Linguagem Visual (o que a marca FALA)

Tom de voz, narrativa, messaging por canal e por público.

Ancoragem: o eixo "Linguagem" da tabela comparativa do texto de referência — o que separa o gestual/subjetivo/efêmero do estruturado/lógico/universalmente inteligível.

Não é uma diretriz de copy solta anexada ao final do manual — é derivada diretamente do Embasamento e validada contra a Gestalt (o que se fala precisa bater com o que se vive e o que se faz).

Camada 5 — Programa Visual (como a marca APARECE)

Cor, tipografia, grid, componentes, motion, fotografia, iconografia.

Termo wollneriano direto — "programação visual", herdado da Escola de Ulm. Aqui entram os assets clássicos, mas como consequência das quatro camadas acima, nunca como ponto de partida. Uma paleta de cores no PVD tem que ser justificável em termos de arquétipo e posicionamento, não escolhida por preferência estética isolada.

Camada 6 — Precisão Digital (como tudo se MANTÉM coerente no tempo)

A própria plataforma (ex.: brandsystem-lcc.bazea.com.br) que expõe as camadas 1–5 de forma navegável, versionada e viva.

Ancoragem: "A Ferramenta de Precisão" do texto de referência — o computador não cria, executa; garante a exatidão que torna o sistema industrializável. Manuais impressos de mil páginas são obsoletos; a eficiência moderna está nos templates/sistemas digitais que garantem a aplicação correta dos parâmetros em qualquer suporte.

É esta camada que transforma o PVD de documento estático em programa: regras que se aplicam, se atualizam e se auditam continuamente.

Nome guarda-chuva

Programa Visual Digital (PVD) é a fusão da Camada 5 (Programa Visual, o corpo clássico wollneriano) com a Camada 6 (Precisão Digital, o que mantém esse corpo vivo e coerente no tempo). O nome do sistema como um todo nasce do ponto de encontro entre as duas camadas que, juntas, resolvem o problema que os manuais impressos nunca resolveram: aplicação correta e atualizada em qualquer suporte.

---

3. Princípio de rastreabilidade

Todo elemento registrado nas camadas 2–5 deve carregar referência explícita ao princípio do Embasamento Visual que o originou, acompanhada da justificativa dessa ligação — não basta o vínculo, é preciso registrar o porquê. Forma sem justificativa é ruído visual, não design.

Essa é a diferença estrutural entre um manual de marca e um PVD: o manual documenta o quê; o PVD documenta o quê e o porquê, e torna esse porquê consultável e auditável.

3.1 Modelo de dados

A rastreabilidade se traduz em uma tabela de junção explícita — não um array de IDs, não uma relação many-to-many implícita do Prisma — porque essas alternativas ligam elementos a princípios sem lugar para guardar a justificativa, que é o dado que de fato opera a regra de ouro.

model Elemento {
  id        String         @id @default(cuid())
  marcaId   String
  marca     Marca          @relation(fields: [marcaId], references: [id])
  camada    Camada
  tipo      String         // subtipo livre por camada: "cor", "componente", "tom_de_voz", "comportamento"...
  titulo    String
  conteudo  Json           // payload heterogêneo — validado por Zod na service layer
  status    ElementoStatus @default(RASCUNHO)

  rastreamentos Rastreamento[]

  @@index([marcaId, camada])
}

enum Camada {
  POSTURA
  GESTALT
  LINGUAGEM
  PROGRAMA
  PRECISAO
}

enum ElementoStatus {
  RASCUNHO
  VALIDADO
  PUBLICADO
  DEPRECATED
}

// A justificativa É a rastreabilidade — sem ela, seria só um many-to-many implícito
model Rastreamento {
  id            String    @id @default(cuid())
  elementoId    String
  elemento      Elemento  @relation(fields: [elementoId], references: [id])
  principioId   String
  principio     Principio @relation(fields: [principioId], references: [id])
  justificativa String

  @@unique([elementoId, principioId])
}

conteudo é Json e não colunas normalizadas porque as camadas têm tipos de elemento radicalmente diferentes — uma cor não tem os mesmos campos que um comportamento cultural. Normalizar cada tipo em tabela própria explode o schema num MVP; o trade-off (perda de validação no nível do banco) é compensado por schema Zod por tipo, validado na service layer. Se o número de tipos estabilizar e o volume crescer, migra para tabelas próprias depois.

3.2 Onde a regra de ouro vira regra de fato

Ter a tabela Rastreamento não impede, por si só, um Elemento sem justificativa — FK não garante cardinalidade mínima. Solução no estágio atual: bloquear a transição de status para PUBLICADO na service layer se rastreamentos.length === 0. Trigger de banco fica como opção futura, se o overhead de manutenção se justificar.

Query de auditoria — "elementos publicados sem princípio associado" — vira tela de auditoria no produto, não só regra documental.

---

4. Arquitetura multi-tenant

Decisão: framework comum parametrizável. Instância própria por cliente (LCC, futuros) é o oposto de replicável — é fork. Toda correção de doutrina ou refinamento teria que ser propagado manualmente para N instâncias divergentes, o que contradiz diretamente o requisito de arquitetura replicável e sem código sujo.

4.1 O que é comum (código) vs. o que varia (dado)

• Comum: as 6 camadas (Camada enum — doutrina fixa, não varia por cliente), a lógica de rastreabilidade, a UI do produto, a regra "sem princípio associado não publica"
• Varia: os princípios em si, os tipos de princípio, os elementos de cada camada, a paleta/tipografia/tom de voz específicos de cada marca

4.2 Schema — tenant e tipos de princípio como dado

PrincipioTipo não é enum global — isso seria código, não dado, e forçaria migration toda vez que um cliente precisasse de um tipo de princípio que outro não tem. Vira tabela configurável por marca, com seed de defaults na criação de toda Marca nova.

model Marca {
  id             String          @id @default(cuid())
  slug           String          @unique  // subdomínio: brandsystem-{slug}.bazea.com.br
  nome           String
  tiposPrincipio TipoPrincipio[]
  principios     Principio[]
  elementos      Elemento[]
}

// Seed roda os 5 defaults (Propósito, Valor, Arquétipo, Posicionamento, Território)
// na criação de toda Marca nova. Cliente pode estender, nunca precisa de migration.
model TipoPrincipio {
  id         String      @id @default(cuid())
  marcaId    String
  marca      Marca       @relation(fields: [marcaId], references: [id])
  chave      String      // "proposito", "arquetipo"...
  label      String
  principios Principio[]

  @@unique([marcaId, chave])
}

model Principio {
  id        String        @id @default(cuid())
  marcaId   String
  marca     Marca         @relation(fields: [marcaId], references: [id])
  tipoId    String
  tipo      TipoPrincipio @relation(fields: [tipoId], references: [id])
  titulo    String
  descricao String

  rastreamentos Rastreamento[]
  @@index([marcaId])
}

4.3 Isolamento de tenant

Framework comum só funciona se o vazamento entre marcas for estruturalmente impossível, não só por convenção. Duas camadas de proteção:

1. Toda query passa marcaId — nunca um findMany sem filtro de tenant. Idealmente um middleware do Prisma ($extends) que injeta o filtro automaticamente, em vez de depender de disciplina individual.
2. Resolução de tenant pelo subdomínio — brandsystem-lcc.bazea.com.br resolve slug: "lcc" num middleware do Next.js antes de qualquer coisa tocar o banco. Já bate com o padrão de subdomínio em produção.

---

5. PVD tradicional vs. PVD Design Total

---

6. Implicação para o produto BAZEá

A Precisão Digital (camada 6) é o primeiro produto da BAZEá. A plataforma não pode ser estruturada como um site de manual de marca com abas para "logotipo, cores, tipografia, aplicações" — essa estrutura cobre só as camadas 1 e 5.

Para ser Design Total de fato, a arquitetura de informação do produto precisa tratar Postura, Gestalt e Linguagem como seções de primeira classe, com o mesmo peso estrutural do Programa Visual — e a rastreabilidade (camadas 2–5 → Embasamento) já está modelada como dado (seção 3), não como texto solto.

---

7. Em aberto

• Conteúdo de referência complementar (vídeo indicado, ainda não incorporado — pendente de acesso/transcrição)
• IA de navegação do produto refletindo as 6 camadas como seções de primeira classe
• Definição do middleware de tenant scoping ($extends do Prisma) como próxima etapa de implementação

---

8. Histórico — Camada 5 (BAZEá) fechada por inteiro (2026-08-30/31)

Este documento descreve o PVD como framework. Esta seção registra o primeiro caso real de uma marca percorrendo a Camada 5 até o fechamento total — a própria BAZEá, tenant zero, servindo de prova de que a Camada 5 (seção 2) funciona como consequência causal e não como escolha estética isolada, honrando a regra de ouro da seção 1.

30/08/2026 — logotipo, primeira rodada. Wordmark fechado (imagem, depois vetor). Símbolo em Sinal (#f47c00), herdado sem questionamento da paleta da seção 5 de 05-programa-visual-cor.md.

30–31/08/2026 — logotipo, segunda rodada: símbolo substituído. Uma nova versão de símbolo foi submetida a comparação medida contra a versão fechada (proporção, massa de tinta, IoU de sobreposição, peso de traço — não impressão visual) e a uma mesa redonda entre cinco vozes de referência (Alexandre Wollner, Aloísio Magalhães, Ana Couto, Marcelo Kimura, David Carson), registrada em entregas/comparativo-logotipo-teste06.html. Conclusão 4 a 1 a favor do símbolo novo (Carson dissidente). Confirmado por Alan em 31/08/2026. Nenhuma forma foi proposta ou gerada por IA nesse processo — só medição e leitura de forma já fornecida, conforme o limite documentado em entregas/logotipo-oficial-camada5.html e reiterado em entregas/bazea-o06.html.

31/08/2026 — emenda de cor do logotipo. A discussão do símbolo expôs uma tensão nunca resolvida entre a seção 5 de 05-programa-visual-cor.md (Sinal como cor rara, disciplina 60-30-10, "só o que está em aberto ou pede atenção") e o fato de um símbolo de marca aparecer em toda aplicação, permanentemente — o oposto estrutural de raro. Formalizado como Emenda §8 naquele documento: a cor permanente do símbolo passa a ser Tinta (#14130f), Osso (#ece9e3) sobre fundo escuro; Sinal continua na paleta, mas deixa de ser o padrão do logotipo. Este é exatamente o mecanismo da seção 3 em ação — um elemento (a cor do símbolo) só migrou de status porque a rastreabilidade contra o princípio (a definição de Sinal) expôs a contradição; a correção ficou registrada como emenda datada, não como edição silenciosa do que já estava fechado.

31/08/2026 — Camada 5 fechada por inteiro. Com símbolo, wordmark e cor resolvidos, a Camada 5 da BAZEá (cor, tipografia, grid, iconografia, componentes, motion, fotografia, logotipo) fecha como conjunto. Registrado em entregas/bazea-o06.html (sexto ensaio) e consolidado em entregas/manual-de-identidade.html; a geometria e a cor corrigidas foram propagadas a toda peça publicada que usa o símbolo, incluindo o carrossel de leads em entregas/.

Único item real ainda em aberto dentro do logotipo fechado: área de proteção e tamanho mínimo — deliberadamente não medidos até existir uma aplicação real em escala pequena que justifique a medição (evitar regra sem caso de uso, não frouxidão de processo).

---

Anexo A — Fonte de ancoragem terminológica

Texto de referência fornecido pelo usuário via NotebookLM: "O Caminho do Projeto: Do Software Humano à Precisão Digital" — trata do legado de Ulm e Wollner, distinção entre design (projeto sistêmico) e ilustração (peça isolada), fase de informação, processo manual de rascunho, papel do computador como ferramenta de precisão, e o conceito de Gestalt Completa. Usado como base para a nomenclatura das seis camadas na seção 2.