SynseHub
Saúde em equilíbrio com o seu futuro.
Painel de gestão das academias do ecossistema Synse — alunos, planos, mensalidades,
treinos, check-in e pagamentos em um único produto.
Testar agora
O projeto sobe sem nenhuma configuração. Sem credenciais de Supabase ele
entra em modo de demonstração, com uma academia completa em memória: 520 alunos,
12 meses de mensalidades, check-ins, treinos e avaliações.
Na sua máquina
Requer Node 22 ou mais recente, disponível em nodejs.org.
git clone -b claude/kind-goldberg-c16nsx https://github.com/BrazZ7/SynseHUB.git
cd SynseHUB
npm install
npm run dev
Abra http://localhost:3000 e escolha um perfil na tela de login.
Com Docker
docker build -t synsehub .
docker run -p 3000:3000 synsehub
Na Vercel
Ou, para publicar o seu próprio repositório: em vercel.com → Add New → Project,
importe BrazZ7/SynseHUB e selecione o branch claude/kind-goldberg-c16nsx.
O Next.js é detectado automaticamente e nenhuma variável de ambiente é
necessária para o modo de demonstração.
Roteiro de teste
| Perfil | O que vale a pena olhar |
|---|
| Emerson Braz (Proprietário) | Dashboard, financeiro, inadimplentes, Synse Pay |
| Rafael Nunes (Professor) | O mesmo dashboard sem receita nem inadimplência — o RBAC em ação |
| Lucas Ferraz (Recepção) | Check-in: busque um aluno e registre a presença |
| Aluno Synse App | A experiência do aluno: treino do dia, check-in, progresso, PIX |
| Synse Plataforma (Super admin) | /synse-admin: GMV, comissão e organizações |
Vale testar também: cadastrar um aluno em Alunos → Novo aluno (ele nasce com
Synse ID e primeira mensalidade), dar baixa numa cobrança em Inadimplentes →
Cobrar → Registrar pagamento e ver o painel recalcular, e reduzir a janela do
navegador até a largura de um celular.
Visão do Synse
O Synse é um ecossistema de saúde, fitness e bem-estar operando em B2B2C:
a academia contrata a plataforma, e os alunos dela ganham acesso gratuito ao app.
A Synse também pode vender diretamente a esses usuários.
| Produto | O que é | Estado |
|---|
| SynseHub | Painel administrativo da academia | Fase 1 implementada |
| Synse App | Área do aluno (PWA responsiva) | Primeira versão |
| Synse Pay | Cobranças, split e conciliação | Arquitetura + provedor simulado |
| Synse+ | Assinatura premium do consumidor | Página de venda |
| Synse Pro | Profissionais independentes | Papel e permissões prontos |
| Synse Market / AI / Corporate | Marketplace, IA e corporativo | Arquitetura preparada |
Synse ID
Cada pessoa tem um identificador vitalício no formato SYN-XXXXXXXX
(Crockford base32, sem I, L, O e U). Ele é não sequencial por decisão de
segurança: um ID não permite inferir outro nem estimar o tamanho da base.
A conta sobrevive ao vínculo com a academia. Um aluno que treina dois anos na
Academia Alpha e sai continua com a conta Synse, o histórico e o progresso —
respeitando consentimentos e regras de acesso.
Arquitetura
src/
app/
(auth)/ Login e escolha de perfil
(hub)/ SynseHub — painel da academia
(student)/ Synse App — experiência do aluno
synse-admin/ Painel da plataforma (SUPER_ADMIN)
api/ Webhooks e health check
components/
ui/ Primitivas (Radix + CVA), estilo shadcn/ui
synse/ Componentes da marca: MetricCard, DataTable, ProgressRing…
charts/ Gráficos Recharts com paleta validada
features/ Um módulo por domínio: actions, services e telas
auth/ students/ payments/ checkin/ workouts/ dashboard/ organizations/
lib/
auth/ Sessão, guardas de rota e server actions de acesso
database/ Data sources (demo e Supabase) + clientes
payments/ Interface PaymentProvider e adapters
permissions/ RBAC e guarda de servidor
validations/ Schemas Zod
db/migrations/ SQL versionado: schema, índices, RLS
types/ Modelo de domínio
config/ Configuração pública e navegação
Princípios que a estrutura sustenta
Multi-tenancy em duas camadas. Toda consulta filtra por organization_id
explicitamente, e o Postgres aplica Row Level Security por cima. A redundância é
intencional: se uma policy for afrouxada por engano, a aplicação continua isolada.
Autorização no servidor. O front-end usa can() apenas para esconder UI.
Cada server action passa por requirePermission() antes de tocar em dados.
Esconder um botão nunca é o controle de acesso.
Gateway atrás de uma interface. Nenhum código específico de gateway existe fora
de lib/payments/providers/. O resto do sistema conhece apenas PaymentProvider,
e isso já se provou na prática: o Asaas foi removido sem que uma linha de regra de
negócio, tela ou migration precisasse mudar.
Dinheiro só muda por confirmação externa. O status de um pagamento muda a partir
de um webhook validado ou de uma consulta ao provedor. Nunca a partir do navegador.
Lógica fora dos componentes. Componentes React renderizam. Regra de negócio vive
em features/*/service.ts, acesso a dados em data sources, validação em schemas Zod.
As APIs já estão desenhadas para servir também um app React Native no futuro.
Tecnologias
Next.js 15 (App Router) · React 19 · TypeScript strict · Tailwind CSS 3
Radix UI · Lucide Icons · Recharts · Zod · React Hook Form · TanStack Query
Supabase (Postgres, Auth, Storage, RLS)
Instalação
git clone https://github.com/BrazZ7/SynseHUB.git
cd SynseHUB
npm install
cp .env.example .env.local
npm run dev
Abra http://localhost:3000.
Modo demonstração
Sem nenhuma configuração o projeto já sobe funcionando. Sem credenciais de
Supabase, o SynseHub usa um data source em memória com uma academia completa:
520 alunos, 12 meses de mensalidades, check-ins, treinos e avaliações. O dataset é
determinístico — os mesmos números em qualquer máquina.
Na tela de login você escolhe o perfil com que quer entrar:
| Perfil | O que enxerga |
|---|
| Emerson Braz — Proprietário | Tudo na organização |
| Marina Duarte — Gerente | Operação, alunos e financeiro |
| Rafael Nunes — Professor | Treinos, avaliações e alunos; sem financeiro |
| Lucas Ferraz — Recepção | Check-in, matrículas e cobranças |
| Aluno Synse App | A experiência do aluno |
| Synse Plataforma — Super admin | Todas as organizações e o GMV |
Não existe senha em modo demonstração: a persona escolhida vira uma sessão em
cookie, e as permissões de cada papel valem normalmente — inclusive as restrições.
O modo só existe quando não há Supabase configurado.
Como a demonstração guarda o que você altera
O dataset base é determinístico e nunca é alterado: ele é reconstruído
idêntico em qualquer processo. O que o visitante muda — matricular um aluno, dar
baixa numa cobrança, registrar presença — vira uma entrada num diário guardado
em cookie, reaplicada sobre o dataset base a cada leitura.
Essa separação resolve dois problemas de uma vez:
- Funciona em serverless. Na Vercel cada requisição pode cair numa execução
diferente, com a própria memória. Uma escrita guardada em variável de módulo
sumiria na navegação seguinte. Viajando no cookie, ela acompanha o visitante.
- Isola quem testa. Duas pessoas abrindo o mesmo link têm demonstrações
independentes. Ninguém estraga a demonstração de ninguém.
O diário guarda no máximo 40 alterações e 3,5 KB. Ao estourar, as mais antigas
saem. O botão Reiniciar demonstração, no topo do painel, apaga o diário e
devolve tudo ao estado inicial.
Variáveis de ambiente
Copie .env.example para .env.local. Nenhum segredo é versionado.
| Variável | Obrigatória | Descrição |
|---|
NEXT_PUBLIC_APP_URL | sim | URL pública (links de cobrança, webhooks) |
NEXT_PUBLIC_SYNSE_ENV | sim | development · staging · production |
NEXT_PUBLIC_SUPABASE_URL | não¹ | URL do projeto Supabase |
NEXT_PUBLIC_SUPABASE_ANON_KEY | não¹ | Chave anônima (sujeita à RLS) |
SUPABASE_SERVICE_ROLE_KEY | não² | Somente servidor. Ignora RLS |
PAYMENT_PROVIDER | sim | mock — é o único hoje. Nome desconhecido cai no simulado e aparece em /api/health?deep=1 |
SYNSE_DEFAULT_PLATFORM_FEE_PERCENTAGE | não | Comissão padrão (o valor efetivo vem do banco) |
¹ Sem as duas, a aplicação entra em modo demonstração.
² Necessária para processar webhooks e rodar o seed.
Banco de dados
Migrations
Arquivos versionados em src/db/migrations, aplicados em ordem:
| Arquivo | Conteúdo |
|---|
0001_core.sql | Perfis, organizações, equipe, planos, alunos, matrículas |
0002_payments.sql | Contas, cobranças, pagamentos, split, webhooks, régua |
0003_training_health_content.sql | Check-in, treinos, avaliações, nutrição, conteúdo, CRM, LGPD |
0004_rls.sql | Row Level Security em todas as tabelas |
0005_student_profile_visibility.sql | Equipe lê o perfil de quem tem matrícula |
0006_unique_profile_email.sql | E-mail único por perfil |
0007_organization_signup.sql | Cadastro de academia pela própria dona |
0008_rls_performance.sql | Políticas em forma de conjunto: 997 ms → 23 ms |
0009_payment_marketplace.sql | Subconta por academia e segredo do provedor |
0010_organization_fiscal_address.sql | Dados fiscais exigidos pelo provedor |
0011_self_signup.sql | Código de convite, entrada do aluno, tipo da organização |
0012_notification_events.sql | Gatilhos que enchem o sino |
0013_synse_solo.sql | Organização reservada: treinar sem academia vinculada |
0014_baseline_experience.sql | Plano da conta, desafios base, progresso e medalhas |
0015_professional_unlock.sql | Perfil profissional como assinatura, não como tipo de cadastro |
0016_synse_run.sql | SynseRun: atividades, rota, parciais e recordes |
npm run db:migrate # lista as migrations e como aplicá-las
npm run db:migrate -- --print > db.sql # SQL consolidado
# Aplicar via Supabase CLI
supabase link --project-ref <project-ref>
supabase db push
Seed
npm run db:seed
Cria uma academia, seis profissionais, cinco planos, 534 alunos com mensalidades,
check-ins e avaliações — volume suficiente para as consultas revelarem o que uma
academia de vinte alunos esconde.
Nenhuma senha é gerada. As contas nascem no Supabase Auth com e-mail
confirmado e sem senha — o acesso previsto é por link no e-mail. Não existe
credencial fixa no repositório nem no banco.
Primeiro acesso
Enquanto não houver SMTP próprio, o link do e-mail não chega a lugar nenhum.
Para entrar sem depender de e-mail:
npm run db:set-password -- --gerar # sorteia a senha e mostra uma vez
npm run db:set-password # ou digite a sua
npm run db:set-password -- [email protected] # em outra conta
O script exige SUPABASE_SERVICE_ROLE_KEY no .env.local, mostra o estado da
conta (e-mail confirmado, provedores, último acesso) e testa o login de
verdade antes de dizer que deu certo. Se a tela recusar depois de o teste
passar, o problema não é a senha.
A senha nunca vai por argumento — isso a gravaria no histórico do shell.
Estrutura de usuários e permissões
| Papel | Escopo |
|---|
SUPER_ADMIN | Plataforma Synse: organizações, GMV, assinaturas, webhooks |
OWNER | Controle completo da sua organização |
MANAGER | Administrativo, sem alterar configurações nem estornar |
RECEPTIONIST | Alunos, pagamentos, check-in e agenda |
TRAINER | Treinos, avaliações e alunos atribuídos |
NUTRITIONIST | Área nutricional dos pacientes autorizados |
PROFESSIONAL | Profissional independente (Synse Pro) |
STUDENT | Synse App |
A matriz completa está em src/lib/permissions/permissions.ts e é visível na
interface em Configurações → Permissões.
Três camadas independentes protegem cada acesso:
requireHubSession(permission) barra a rota antes de renderizar.requirePermission(session, permission) barra cada server action.- Row Level Security barra a query, mesmo que as duas primeiras falhem.
Synse Pay
Trocando de provedor
// Todo o sistema depende apenas disto:
const provider = getPaymentProvider()
await provider.createPix({ ... })
Para adicionar um gateway, implemente PaymentProvider
(src/lib/payments/provider.ts) e registre na fábrica em
src/lib/payments/index.ts. Nenhuma tela muda.
Split
A comissão da Synse nunca está fixa no código. Ela vem de
organization_billing_settings (percentual, taxa fixa e quem absorve a tarifa do
provedor) e é alterável apenas pela plataforma — a própria academia não edita a
própria comissão. O cálculo vive em src/lib/payments/split.ts e garante que a
soma feche com o valor cobrado, sem centavo perdido.
Webhooks
Sem provedor, não há rota de webhook — ela nasce junto com o adapter. O mecanismo
que recebe o evento continua de pé e vale para quem vier:
- O token do cabeçalho é comparado em tempo constante, e sem token configurado
todo webhook é rejeitado — nunca aceito por omissão.
- Idempotência por constraint:
webhook_events tem UNIQUE (provider, event_id).
O mesmo evento reenviado falha no INSERT, é reconhecido e ignorado. Não existe
liquidação em duplicidade.
- Uma confirmação grava, na mesma transação lógica: baixa da cobrança, registro do
pagamento, split calculado e entrada na trilha de auditoria.
Estado da cobrança
Não há provedor de pagamento conectado. O Asaas foi removido por causa da taxa
e o substituto ainda não foi escolhido, então o único provedor é o simulado: nenhum
centavo se move, em nenhum ambiente. O Synse Pay — o marketplace em que a academia
cobra o aluno e a plataforma retém a comissão — está engavetado junto, e as telas
dizem isso em vez de fingir que operam.
Quem for ligar o próximo provedor escreve um adapter em lib/payments/providers/
e uma rota de webhook. O que a interface exige é o que restringe a escolha: além de
PIX, boleto, cartão e assinatura recorrente, ela pede createPaymentAccount
(subconta por academia) e configureSplit. Provedor sem marketplace atende a
assinatura do Synse+ e não atende o Synse Pay.
Privacidade e LGPD
Dados de saúde (avaliações físicas e planos nutricionais) recebem tratamento
próprio:
- Acesso restrito por papel e por policy no banco. Um recepcionista não lê
avaliação física; um professor não lê plano nutricional.
- Plano nutricional individual só existe com profissional responsável: a coluna
author_staff_id é NOT NULL com ON DELETE RESTRICT. O sistema não emite
prescrição clínica nem interpreta medidas automaticamente.
- Consentimento versionado por finalidade, com data de aceite e de revogação.
- Ranking é opt-in duplo: o desafio precisa ter ranking ativo e o participante
precisa ter autorizado. Métrica pessoal nunca aparece sem consentimento.
- Trilha de auditoria em operações críticas, imutável pelo cliente
(
INSERT WITH CHECK (false) na chave anônima).
- Minimização: nenhum dado de cartão trafega ou é armazenado pelo Synse.
Scripts
npm run dev # desenvolvimento
npm run build # build de produção
npm run start # servidor de produção
npm run lint # ESLint
npm run typecheck # TypeScript strict
npm run format # Prettier
npm run db:migrate # migrations
npm run db:seed # dados de demonstração
Identidade visual
Os tokens vivem em src/app/globals.css e são consumidos pelo Tailwind. O tema
escuro redefine apenas as variáveis — nenhuma classe de componente muda.
| Token | Claro | Escuro |
|---|
--synse-bg | #F5FAF8 | #041D1B |
--synse-surface | #FFFFFF | #082925 |
--synse-primary | #00A98F | #17C4A5 |
--synse-cyan | #22C7D8 | #35D6E6 |
--synse-text | #102B29 | #E6F5F1 |
O gradiente da marca (#00A98F → #22C7D8) é reservado para áreas estratégicas:
logo, CTA principal, indicadores de progresso e banners.
As paletas dos gráficos foram validadas para banda de luminosidade, piso de
croma, separação sob daltonismo (protanopia, deuteranopia, tritanopia) e contraste
contra a superfície do card — nos dois temas, com passos próprios em cada um.
Os valores estão em src/components/synse/charts/chart-theme.ts.
O SynseHub é executivo; o Synse App é inspiracional. Ambos pertencem visivelmente à
mesma marca.
Roadmap
Fase 1 — implementada
Autenticação · Multi-tenancy com RLS · Layout e navegação por papel · Dashboard com
métricas derivadas · Gestão de alunos com filtros e paginação · Perfil do aluno em
abas · Planos · Mensalidades · Financeiro · Inadimplentes com régua · Synse Pay
simulado · Check-in por QR Code e recepção · Treinos · Synse App · Painel da
plataforma · Landing page
Fase 2
Integração real de pagamento · Webhooks em produção · Split ao vivo · Assinaturas
recorrentes · Régua automatizada com disparo · Avaliações com registro pelo
profissional · Biblioteca de conteúdo · Receitas · Programas Synse 21/30/60/90 ·
Synse+
Fase 3
Nutrição profissional · Synse Pro · Gamificação e desafios · CRM avançado ·
Marketplace · Wearables · Synse AI
Synse AI não é construída agora, mas a arquitetura já a acomoda: ela responderá
apenas sobre dados que o usuário autorizou e não substitui diagnóstico médico.
Testes
npm test # tudo
npm run test:unit # lógica pura, sem banco
npm run test:db # RLS e schema, exige PostgreSQL
Os testes de banco constroem o schema a partir das migrations reais — não há
schema duplicado no diretório de testes, porque um schema paralelo divergiria
justamente nos detalhes que os testes existem para proteger. Sem PostgreSQL
disponível eles pulam com aviso, e a suíte de lógica pura continua rodando.
Para rodar a suíte completa, aponte TEST_DATABASE_URL para um banco vazio:
TEST_DATABASE_URL=postgresql://postgres@localhost:5432/synse_test npm run test:db
O que a suíte cobre, e por quê:
| Arquivo | Protege |
|---|
unit/split | o cálculo do dinheiro: soma exata, arredondamento, as três estratégias de tarifa |
unit/permissions | quem enxerga o quê, incluindo o professor que não vê o financeiro |
db/rls | isolamento entre academias, acesso anônimo, nome dos alunos visível para a equipe |
db/schema | RLS ligada em toda tabela, e-mail único, formato do Synse ID, comissão vinda do banco |
db/signup | cadastro de academia: anônimo recusado, duplicidade recusada, isolamento preservado |
db/rls-performance | a forma do plano de execução, para a RLS não voltar a ser avaliada linha a linha |
Cada teste de banco corresponde a uma falha que já aconteceu. O de desempenho
verifica o plano, não o relógio: o que importa é a política ser avaliada uma vez
por consulta, e não o número de milissegundos numa máquina específica.
Antes do primeiro cliente pagante
Credenciais a rotacionar, ambiente de desenvolvimento separado, plano da Vercel
e a verificação do Synse Pay ponta a ponta estão em
docs/pre-producao.md, e o roteiro para publicar nas
lojas — do Supabase ao envio — em
docs/publicar-passo-a-passo.md.
Durante a construção é comum
adiar esses itens — a lista existe para que adiar não vire esquecer.
O que ainda não está pronto
Honestidade sobre o estado atual, revisada em 12/09/2026.
Telas que dizem algo que não é verdade
- Os consentimentos no perfil do aluno são fixos. A tela lista quatro itens
com "Aceito"/"Não autorizado" escritos no código, e a legenda promete que
"cada consentimento é registrado com versão e data". A tabela
consents
existe desde a 0003 e não é lida nem escrita por lugar nenhum. É a única tela
do produto que afirma algo falso sobre dado do usuário, e por ser matéria de
LGPD deveria sair ou virar verdade antes de qualquer cliente.
- O QR Code do totem é um padrão visual determinístico, não um código
escaneável.
Funciona, com limite conhecido
- Cobrança é avulsa. PIX por aluno, na mão. A régua de cobrança e as regras
de recorrência estão no schema e são lidas, mas não existe geração mensal
automática de mensalidade.
- Synse Pay está engavetado. Sem provedor de pagamento conectado, nenhuma
cobrança é emitida: as telas funcionam sobre o provedor simulado e dizem isso.
O marketplace — subconta por academia e split da comissão — volta quando o
substituto do Asaas for escolhido.
- O fechamento do desafio acontece quando a pessoa abre o app. Sem
agendador: se ninguém abrir, a medalha do mês não sai — e é idempotente, então
sai inteira na primeira visita seguinte.
- A assinatura do consumidor não existe. Synse+ e perfil profissional têm a
tela, a coluna e a função de liberação; o botão fica travado até haver
checkout. Hoje só se libera pelo SQL, com a chave de serviço.
Não existe ainda
- Montar treino pelo painel. O professor não cria plano nem atribui a aluno:
/workouts é somente leitura. É a lacuna mais cara do produto — o gatilho de
"novo treino disponível" nunca dispara porque nada atribui treino.
- Cadastrar plano de mensalidade.
createPlan existe no data source e não
tem tela nem ação.
- Editar aluno. Dá para cadastrar e confirmar; não dá para corrigir dado,
trocar de plano nem encerrar matrícula pela interface.
- Feed social, desafios de corrida e ranking do SynseRun: o schema aguenta
(a atividade já tem organização e privacidade por atividade), as telas não
existem.
- Módulos marcados "em breve" na navegação — agenda, avaliações, nutrição do
painel, conteúdos, desafios do painel, CRM e relatórios — têm modelo de dados
e permissões, e nenhuma tela.
- Rastrear com a tela apagada. Limite de plataforma, não de esforço: num
navegador, o iOS suspende o JavaScript da aba em segundo plano, e nenhuma API
de site contorna isso. O SynseRun mantém a tela acesa (Wake Lock), grava cada
ponto no aparelho e reconstrói ao voltar — rastreamento com tela apagada exige
aplicativo nativo.
Sobre a base
- Schema, RLS e escritas foram exercitados contra PostgreSQL real, e as
migrations 0001 a 0015 estão aplicadas em produção. O isolamento entre
organizações é testado com duas academias concorrentes: anônimo e usuário sem
vínculo não leem nada.
- As migrations não concedem privilégios de tabela. Dependem do padrão que o
Supabase aplica ao schema
public. Num PostgreSQL fora do Supabase é preciso
conceder na mão.
- A suíte passa de mil testes — unidade e banco contra um PostgreSQL real.
Os de banco pulam em silêncio sem Postgres no ar, então conferir o número
de arquivos que rodaram vale mais do que a cor do resultado.
Disciplina hoje. Liberdade sempre.
Saúde é a base de tudo.
