Precisão Digital

Camada 6 do PVD · Marca: BAZEá (slug: bazea)

Primeiro documento de Camada 6. Doutrina, não código — decisão do Alan em 2026-08-17 ("doutrina primeiro"), mesmo método que abriu cor, tipografia e grid: raciocinar e registrar antes de tocar em implementação. O modelo de dados, a arquitetura multi-tenant e o isolamento de tenant já estão especificados em 00-pvd-conceitual.md §3–4 — este documento não repete aquilo, resolve o que ficou registrado como "em aberto" lá (§7): a IA de navegação, e acrescenta o que só aparece agora que a Camada 5 está fechada — a decisão de reaproveitar o próprio sistema visual, o escopo do primeiro tenant, e a localização do código.

Depende de: componentes (a escala de elevação e os padrões editoriais que a UI do produto vai herdar) — fechado. Sem essa dependência, Camada 6 ficaria escolhendo estética de novo, o mesmo erro que a cor e os componentes já corrigiram.

Atualizado em 2026-08-31: Alan decidiu que a Camada 6 também vai ter login real de cliente, com área própria além da doutrina exposta — serviços, pagamentos, informações úteis (seção 5). O escopo original deste documento (seção 1) previa só a doutrina navegável; a decisão amplia isso sem contradizer o que já estava fechado.

---

1. O que a Camada 6 é, em uma frase

A plataforma que faz o próprio PVD parar de ser um conjunto de arquivos .md e .html e virar produto navegável — mas o conteúdo que ela expõe primeiro é o desta mesma pasta: a BAZEá é o tenant zero.

2. Reaproveitar o sistema visual, não desenhar um novo

A decisão que evita o erro mais previsível deste passo: a UI de Camada 6 usa os tokens, tipografia, componentes e curvas de motion que a Camada 5 acabou de fechar — Bitter/Work Sans, a paleta (Papel/Vellum/Sinal/Conferido/Mata/Tinta/Osso), o toggle skeuomórfico, o botão 3D, a escala de elevação, as curvas --e-papel/--e-metal/--e-tinta. Não é preguiça, é a regra de ouro aplicada à própria plataforma: se a Camada 6 inventasse uma paleta ou uma tipografia própria "porque é produto, é diferente", isso repetiria exatamente o erro que a doutrina de componentes já recusou (§5 de 05-programa-visual-componentes.md, kits de UI genéricos) — só que desta vez aplicado ao produto mais visível que a BAZEá vai ter. Uma plataforma que expõe rastreabilidade e não é ela mesma rastreável ao Embasamento seria a contradição mais visível que o PVD poderia cometer.

Isso também resolve uma pergunta de estilo antes dela virar decisão informal no meio de um sprint: dashboards de produto tendem a puxar para paleta genérica de SaaS (azul institucional, cinza neutro, cards com sombra suave). Essa estética já está listada em "Recusado por doutrina" desde componentes — vale aqui com o mesmo peso.

3. IA de navegação — resolve o "em aberto" de 00-pvd-conceitual.md §7

O erro que o próprio documento conceitual já preveniu: "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" (§6). A informação abaixo traduz isso em navegação real, não em princípio abstrato.

Seis seções de primeira classe, peso estrutural igual — nenhuma é "aba secundária" de outra:

Uma sétima superfície, transversal, não uma seção a mais: a auditoria de rastreabilidade — a tela que lista Elemento/Rastreamento e permite navegar de qualquer elemento da Camada 2–5 até o princípio da Camada 1 que o justifica, e vice-versa (clicar num princípio mostra tudo que ele sustenta). Isso não é uma "seção 7" no menu — é um modo de visualização que atravessa as seis, porque a regra de ouro do PVD é justamente essa ligação. O ensaio bazea-o04.html já tem uma versão embrionária disso (rastreabilidade clicável entre tabela e origem) — a Camada 6 generaliza esse mecanismo pra todas as camadas, não só tipografia.

4. Primeiro tenant, escopo mínimo real

Marca { slug: "bazea" } é o primeiro registro, não um cliente futuro. Migrar este mesmo repositório (pvd/*.md) para Elemento/Principio/Rastreamento é o primeiro trabalho de dado, não de interface — e serve como teste de estresse real do schema: se o modelo genérico (conteudo: Json, tipo: String livre) não aguenta representar a cor, o grid e a fita de atenção que já existem, o schema está errado antes de qualquer cliente pagante encostar nele.

Isso também resolve, por adiamento consciente e não por esquecimento, a pergunta já registrada no CLAUDE.md raiz: "quando a Camada 6 existir, vale decidir se o app do LCC migra pra dentro dela ou continua como está". Essa decisão só faz sentido depois que o tenant zero (BAZEá) provar o schema — migrar o LCC pra uma plataforma ainda não testada seria o mesmo erro que instância-própria-por-cliente já foi descartado em 00-pvd-conceitual.md §4.

5. Área do cliente — login real, além da doutrina exposta

Decisão de Alan em 2026-08-31: o cliente não vai só visualizar o próprio brand system logado — vai ter uma área de conta própria, com serviços contratados, pagamentos e informações úteis para a operação do dia a dia com a BAZEá.

Isso muda o que a Camada 6 cobre. A seção 1 define a camada como "a plataforma que expõe o PVD navegável" — mas serviço contratado e data de vencimento de fatura não são elementos de marca, não existe princípio de Embasamento que os justifique. Forçar isso pela regra de ouro (seção 1 de 00-pvd-conceitual.md) seria burocracia sem função — o oposto do que a regra protege. A decisão é tratar como dois domínios de dado dentro do mesmo produto e do mesmo login, não dois produtos separados:

• Domínio de doutrina — Elemento/Principio/Rastreamento (00-pvd-conceitual.md §3), sujeito à regra de ouro.
• Domínio operacional — serviços, pagamentos, informações úteis: dado do relacionamento com o cliente, sem rastreabilidade a princípio nenhum. Schema próprio, ainda não desenhado (seção 7).

Os dois domínios compartilham a mesma base de tenant já fechada em 00-pvd-conceitual.md §4 (Marca { slug }, isolamento por marcaId, login via Supabase Auth). Separar em dois produtos repetiria, entre módulos do mesmo sistema, o mesmo erro que "instância própria por cliente" já foi entre clientes (§4 daquele documento).

Papéis, com essa decisão:

• Alan — superadmin, atravessa todos os tenants, acesso aos dois domínios de qualquer marca.
• Cliente logado — escopado ao próprio marcaId. No domínio operacional, naturalmente só leitura (serviços e pagamentos são registrados pela BAZEá, não pelo cliente). No domínio de doutrina, se o cliente pode editar elementos da própria marca ou só visualiza segue não decidido (seção 7) — mais provável que só visualize, já que curadoria de doutrina é o serviço que a BAZEá vende, mas isso não foi confirmado.

Pagamentos — decisão parcial. Confirmado que a área existe. Não decidido: exibir status/histórico (mais simples — cobrança continua acontecendo fora da plataforma) ou processar pagamento de verdade dentro dela (exige gateway, compliance PCI, escopo bem maior). Alan adiou essa escolha explicitamente em 2026-08-31 — ver seção 7.

6. Stack e localização — decidido, execução pendente

• Stack: Next.js + Prisma + Supabase (Postgres), conforme 00-pvd-conceitual.md §3–4. Middleware de tenant scoping por subdomínio (brandsystem-{slug}.bazea.com.br já é o padrão em produção para o LCC) e por $extends do Prisma para isolamento de query — ambos já especificados, não redecidido aqui.
• Localização do código: repositório Git próprio, fora deste workspace — decisão de Alan em 2026-08-17, mesmo padrão do brand-system-app do LCC (C:\dev\brand-system-app). bazea/ continua sendo doutrina e ensaios visuais, nunca o código do produto. O repositório existe desde 2026-11-02 (github.com/alan-ghub/brand-system-bazea, cópia de trabalho em C:\dev\brand-system-bazea) — ver seção 9.

7. Recusado por doutrina, não por gosto

• Paleta/tipografia própria "de produto" — ver seção 2. A Camada 6 herda o sistema visual que ela mesma expõe, ponto.
• Estrutura de "manual de marca com abas" (logotipo/cores/tipografia/aplicações) — já recusada em 00-pvd-conceitual.md §6; cobre só Embasamento e Programa Visual, invisibiliza Postura/Gestalt/Linguagem.
• Instância própria por cliente (fork por marca) — recusada em 00-pvd-conceitual.md §4; framework comum parametrizável é a decisão.
• Migrar o LCC para a nova plataforma antes do tenant zero provar o schema — ver seção 4. Não é recusa permanente, é sequenciamento.
• Misturar dado operacional (serviços/pagamentos) no schema Elemento/Rastreamento — ver seção 5. A regra de ouro é sobre design justificado por princípio; aplicá-la a dado administrativo seria burocracia sem função.

8. Em aberto

1. Criação do repositório real — pendente, fora do escopo deste documento de doutrina.
2. Migração de pvd/*.md para Elemento/Rastreamento — schema de importação (parser markdown → Json validado por Zod) ainda não desenhado.
3. Middleware de tenant scoping ($extends do Prisma) — já registrado como próxima etapa em 00-pvd-conceitual.md §7, segue pendente.
4. Permissão do cliente no domínio de doutrina — decidido que o cliente loga e tem tenant próprio (seção 5); não decidido se ele pode editar Elemento/Rastreamento da própria marca ou só visualiza.
5. Schema do domínio operacional — Servico, Pagamento/histórico, Informação (ou nomes equivalentes): estrutura ainda não desenhada, ver seção 5.
6. Pagamento: exibição vs. processamento real — Alan adiou essa escolha explicitamente em 2026-08-31 (ver seção 5). Processar pagamento dentro da plataforma implica gateway (ex. Stripe), compliance PCI e escopo bem maior do que exibir status.
7. Decisão sobre migração do LCC — explicitamente adiada até o tenant zero validar o schema (seção 4).
8. Conteúdo de referência complementar (vídeo NotebookLM sobre "Precisão Digital") — mesma pendência já registrada em 00-pvd-conceitual.md §7, ainda sem transcrição.
9. Monoespaçada de marca — avaliada e adiada na tipografia (Martian Mono segue no chrome de interface sem ter passado pelo processo formal); Camada 6 é onde essa decisão volta a ficar relevante, por ser onde chrome de interface (IDs de tenant, timestamps, slugs) realmente aparece em produto.

---

Rastreabilidade → Elemento (PRECISAO), seed

---

9. Estado de implementação (2026-11-02)

O repositório existe: github.com/alan-ghub/brand-system-bazea, cópia de trabalho em C:\dev\brand-system-bazea (fora do Drive, como a doutrina decidiu em 2026-08-17). MVP navegável: Next.js 16 + React 19 + Tailwind v4, 13 páginas migradas de pvd/*.md por scripts/migrar-pvd.mjs (69 rastreamentos, 7 órfãos), navegação pelas 6 camadas, superfície /auditoria filtrável por princípio, camada e texto, wordmark vigente no header (acento em modo monocromático até o Alan decidir a cor). Não feito: login e área do cliente, Prisma/Supabase, multi-tenant e middleware de tenant scoping. O MVP é baseado em arquivos (frontmatter MDX) e valida o modelo Elemento/Rastreamento antes do schema. Incidente de 2026-11-02: na cópia do Drive, o repositório local estava sem histórico (.git/objects vazio) e 173 arquivos de um app anterior (login, assets, componentes) tinham sumido do disco e do índice do Git, sem nunca ter ido ao GitHub. O MVP foi reconstruído a partir do que sobrou (lib/, styles/, docs/). A pasta brand-system-bazea/ do Drive ficou como estava e não deve ser editada.

Decisões que o MVP tomou por conta própria, para o Alan confirmar: (1) base de arquivos em vez de banco, para validar o modelo antes do schema; (2) uma página por documento de pvd/, sem fatiar por seção; (3) o vínculo de elemento a princípio é lido da coluna "Vínculo" de cada tabela de rastreabilidade, e vínculo que não cita um dos cinco princípios vira órfão (por exemplo, "postura: guiar com perguntas" liga a outra camada, não à Camada 1); (4) logotipo do header em modo monocromático até a decisão da cor do acento.