BLUEPRINT TÉCNICO v4.0

Como oPIXOOMFunciona

Arquitetura completa da plataforma de gestão inteligente de planos de ação

3Módulos

3Níveis

5Perfis

22Tabelas

PG17PostgreSQL

RLSMulti-tenant

O que é?

Plataforma enterprise para gestão completa de planos de ação. Três módulos integrados: Flow (importação e sincronização bidirecional com WayV), Plano de Ações (funil de 3 níveis com timesheet e Kanban) e Dashboards (métricas e KPIs em tempo real por perfil de acesso).

Por que existe?

Grandes empresas gerenciam planos de ação em planilhas isoladas, e-mails e ferramentas desconectadas. Resultado: zero rastreabilidade, sem audit trail, sem conformidade regulatória (LGPD) e impossibilidade de medir produtividade real.

→

Para quem?

Organizações multi-departamento que precisam de controle hierárquico sobre projetos e planos de ação. Cinco perfis com permissões granulares: Super Admin (plataforma), Admin (organização), Gestor (projetos), Coordenador (escopo) e Colaborador (execução).

✓

Como funciona?

Monolito modular com Next.js 16 (frontend), Fastify 5 (API REST), PostgreSQL 17 (RLS por tenant), Drizzle ORM (schema tipado), Redis 7 + BullMQ (cache e filas) e Socket.io (tempo real). Cada ação é rastreável do planejamento à conclusão, com audit trail completo e LGPD nativa em código.

Stack Tecnológico

Cada tecnologia foi escolhida com critério. Nada entra por hype — entra por resolver um problema real com trade-offs aceitáveis.

Frontend

Next.js 16 + React 19

App Router + Server Components + Turbopack

Renderização no servidor com streaming parcial (PPR), Server Components para dados pesados sem enviar JavaScript ao client, e Turbopack para builds 10x mais rápidos que Webpack. Maior ecossistema de componentes e bibliotecas do mercado.

Alternativas analisadas: Nuxt (ecossistema Vue menor no Brasil, menos devs disponíveis), Remix (absorvido pelo React Router v7, futuro incerto), SvelteKit (comunidade pequena, difícil contratar)

Estilização

Tailwind CSS 4

Engine Oxide — build 10x mais rápido

Utility-first com design system consistente. Prototipagem rápida, sem CSS morto em produção e integração nativa com Next.js.

Alternativas analisadas: Styled Components (runtime JS, mais lento), CSS Modules (sem design tokens nativos)

Backend

Node.js + Fastify 5

API REST separada do frontend

~77k req/s — 2 a 3x mais rápido que Express. Schema validation nativa com JSON Schema (valida input antes de processar), hooks system para middleware, plugins oficiais de WebSocket, CORS e rate limiting. TypeScript com generics tipados para rotas.

Alternativas analisadas: Express 5 (~15k req/s, lento e sem schema nativo), NestJS (overhead de decorators, complexidade desnecessária), Hono (ecossistema imaturo, poucos plugins)

ORM

Drizzle ORM

SQL-first + RLS nativo

Único ORM com suporte nativo a Row Level Security do PostgreSQL. Define pgPolicy e pgRole direto no schema TypeScript — o schema do banco é código versionado. Migrations declarativas, tipagem forte end-to-end e zero overhead de runtime (queries são SQL puro).

Alternativas analisadas: Prisma (sem suporte RLS nativo, abstrai demais o SQL, runtime pesado), Kysely (sem sistema de migrations integrado), TypeORM (instável, padrões antigos, manutenção errática)

Banco de Dados

PostgreSQL 17

Multi-tenant com Row Level Security

RLS nativo para isolamento automático por tenant (cada organização vê apenas seus dados), partitioning declarativo por organização, JSON_TABLE para campos configuráveis, VACUUM 20x mais eficiente (crítico para audit log) e backup incremental nativo.

Alternativas analisadas: MySQL 9 (sem RLS nativo — isolamento exigiria views manuais), CockroachDB (complexidade operacional desnecessária no MVP)

Cache + Filas

Redis 7 + BullMQ

In-memory cache + Job Queue assíncrona

Redis como cache de sessões, queries frequentes e invalidação por tenant. BullMQ para jobs assíncronos (sync WayV, envio de notificações, audit log, geração de relatórios) com retry automático, prioridade configurável e parent-child jobs para workflows complexos.

Alternativas analisadas: RabbitMQ (overkill para o MVP, mais uma infra para manter), AWS SQS (vendor lock-in, latência maior, custo por mensagem)

Real-time

WebSocket (Socket.io)

Bidirecional com reconnect automático

Sincronização do Kanban em tempo real (drag-and-drop reflete instantaneamente para outros usuários), notificações push instantâneas e indicador de presença online. Rooms para isolamento por organização via RLS. Fallback HTTP long-polling automático.

Alternativas analisadas: SSE (apenas server→client, não suporta sync bidirecional do Kanban), Pusher (custo por mensagem, vendor lock-in)

Storage

MinIO → S3

Object Storage com API S3-compatible

MinIO self-hosted no MVP (custo zero, mesma API do S3). Migração transparente para AWS S3 ao escalar — basta trocar as credenciais. Armazena anexos de tarefas, backups criptografados com AES-256 e lifecycle policies para expirar arquivos automaticamente.

Alternativas analisadas: Google Cloud Storage (vendor lock-in Google), Azure Blob (menos adotado no ecossistema Node.js)

Observabilidade

Grafana + Prometheus

Métricas + Dashboards + Alertas proativos

Open-source, sem custo em qualquer escala. Prometheus coleta métricas de CPU, memória, queries lentas, saúde dos jobs BullMQ e latência da API. Grafana visualiza tudo em dashboards customizáveis com alertas proativos por threshold (ex: CPU > 80% notifica Slack).

Alternativas analisadas: Datadog (~US$15/host/mês, custo escala rápido), New Relic (~US$25/host/mês) — custos desnecessários no MVP

Autenticação — Decisão em aberto

Quatro opções analisadas com prós, contras e custos

Better Auth

Recomendado

R$ 0 (self-hosted)

Prós

Adapter Drizzle nativo
Dados no seu PostgreSQL
Plugin multi-tenant
Plugin 2FA (TOTP)
Zero latência (local)
Sem vendor lock-in

Contras

Biblioteca mais nova
Sem SMS MFA nativo (precisa Twilio)

AWS Cognito

Enterprise

US$ 0–275/mês (10k MAU)

Prós

MFA robusto (SMS, Email, TOTP)
Escalável infinitamente
Threat protection (tier Plus)

Contras

Dados fora do seu DB
Latência ~50–200ms/request
Não integra com Drizzle/RLS
Vendor lock-in AWS

Clerk

SaaS

US$ 0–50+/mês (10k MAU)

Prós

UI pronta e bonita
Bom developer experience
Orgs/multi-tenant

Contras

Dados fora do seu controle
Vendor lock-in total
Custo cresce com escala
Não integra com RLS

JWT Manual

Custom

R$ 0 (self-hosted)

Prós

Controle absoluto
Dados no seu DB
Sem dependência externa

Contras

Construir tudo do zero
Risco de falhas de segurança
Sem 2FA pronto
Manutenção constante

TypeScript em toda a stack

Do banco ao frontend, uma única linguagem com tipagem forte. Isso significa types compartilhados entre API e UI, refactoring seguro, autocomplete real e zero “undefined is not a function” em produção.

Arquitetura do Sistema

Flow

Integração WayV

Ponte bidirecional com o WayV via Project ID. Sincroniza prazos, comentários e justificativas com data e hora registrados. Ações automáticas são criadas nos prazos importados. Todo o processo opera como job assíncrono via BullMQ — sem bloquear a interface do usuário.

Features

Importação automática por Project ID específico do WayV
Sincronização bidirecional — alterações fluem nos dois sentidos
Log detalhado na tabela WAYV_SYNC_LOG (data, hora, status, erros)
Jobs assíncronos via BullMQ com retry automático em caso de falha
Macro-ações criadas automaticamente a partir dos prazos importados
MERGE do PG17 evita duplicatas — wayv_project_id UNIQUE por organização

02Core

Plano de Ações

Coração da Plataforma

Coração do PIXOOM. Funil de três níveis hierárquicos (Macro-ação → Atividade → Ação) com timesheet integrado, Kanban permissionado por perfil de acesso e audit trail completo via trigger automático no banco. Cada colaborador vê apenas as tarefas designadas a ele.

Features

3 níveis hierárquicos: Macro-ação (estratégico) → Atividade (tático) → Ação (executável)
Timesheet integrado — cronômetro em tempo real ou inserção manual de horas
Kanban permissionado — cada perfil vê apenas o que tem permissão
Dependências inteligentes — ação só inicia quando predecessora terminar
5 status consistentes: Em Início, Em Andamento, Concluída, Cancelada, Em Atraso
Audit trail automático — quem alterou o quê, quando, valores antes/depois em JSONB
Visão hierárquica ordenada pelo deadline mais próximo na cadeia
Colaborador vê apenas suas tarefas — sem acesso à visão global

03Visualização

Dashboards

Métricas sob medida

Métricas e KPIs calculados direto do PostgreSQL em tempo real — sem camada intermediária de ETL. Cada perfil de acesso tem seu dashboard customizado com widgets e layouts configuráveis.

Features

KPIs em tempo real: taxa de atraso, progresso percentual, horas logadas, distribuição por status
Queries diretas no PostgreSQL — dados sempre atualizados, sem cache defasado
Widgets e layouts configuráveis por perfil (tabelas DASHBOARD e DASHBOARD_WIDGET)
Dashboard do Gestor difere do Admin — cada perfil vê o que precisa
Filtros combinados por período, equipe, projeto e status
Visão Kanban integrada com drag-and-drop (tabela KANBAN_VIEW)

Fluxo entre módulos

Dados fluem do WayV até os dashboards de forma automatizada

Flow

Importa dados do WayV

→

Plano de Ações

Processa e gerencia ações

→

Dashboards

Visualiza métricas e KPIs

Estrutura de Ações

O funil de três níveis — do estratégico ao executável

Macro-ação

EstratégicoMACRO_ACTION

PK idFK action_plan_idFK assigned_toDATE planned_startDATE planned_endDATE real_targetDATE revised_endENUM status

Etapa estratégica do projeto, definida pelo Gestor ou Admin. Possui datas de início e conclusão planejadas, data meta real (revised_end para replanejamento) e predecessoras inteligentes — uma macro-ação só inicia quando a anterior terminar. Campo is_locked trava edição após conclusão.

Atividade

TáticoACTIVITY

PK idFK macro_action_idFK assigned_toFK template_idINT estimated_hoursENUM status

Desdobramento tático da macro-ação, atribuído pelo Coordenador. Suporta templates reutilizáveis (tabela ACTIVITY_TEMPLATE) para padronizar atividades recorrentes. Campo estimated_hours permite controle de desvio no timesheet — horas reais vs. estimadas.

Ação

ExecutávelTASK

PK idFK activity_idFK assigned_toENUM priorityENUM statusINT estimated_minutes

Nível mais granular e executável — o que o Colaborador vê e trabalha. Cronômetro de horas em tempo real (via Socket.io) ou inserção manual. Estimativa em minutos para tarefas curtas. Visível no Kanban permissionado por nível de acesso, com prioridade (low, medium, high, urgent).

Fluxo de Status

Em Início

Em Andamento

Concluída

exceções

Em Andamento

Em Atraso

Qualquer

Cancelada

Em Atraso é calculado em tempo real: status = in_progress AND planned_end < NOW()

Funcionalidades do Funil

⛓

Dependências Inteligentes

Uma macro-ação só inicia quando a predecessora terminar. A tabela DEPENDENCY armazena relações predecessor→successor e a API valida transições antes de permitir mudanças de status.

✓

Conclusão Cascata

Um plano de ação só é marcado como concluído quando 100% das macro-ações, atividades e ações estiverem finalizadas. Campo is_locked = true impede edição após conclusão.

◈

Visão Hierárquica

Ações são organizadas pelo deadline mais alto na cadeia hierárquica (macro-ação → atividade → ação). No Kanban, o deadline mais próximo aparece primeiro automaticamente.

◉

Audit Trail Automático

Trigger no PostgreSQL registra automaticamente quem alterou o quê, quando, de onde (IP, user-agent). Valores antes e depois são armazenados em JSONB — rastreabilidade completa.

⏱

Timesheet Integrado

Cronômetro em tempo real via Socket.io (inicia/pausa/finaliza) ou inserção manual de horas por ação. Tabela TIMESHEET_ENTRY vincula horas à ação específica com aprovação do gestor.

▦

Kanban Permissionado

Esteira visual de tarefas com drag-and-drop. Filtrada pelo nível de acesso: Colaborador vê apenas suas tarefas, Coordenador vê seu escopo, Gestor vê tudo do projeto.

Por que três tabelas separadas e não uma recursiva?

Cada nível possui campos exclusivos (datas de bloqueio, templates, cronômetro) que não fazem sentido nos demais.
Regras de negócio distintas por nível: bloqueio automático, estimativas em horas vs. minutos, prioridades.
Queries de performance: JOINs tipados evitam filtros de tipo e simplificam índices compostos.
Profundidade fixa (3 níveis) garante UI previsível e evita recursão infinita.
Status consistente em todos os níveis: Em Início, Em Andamento, Concluída, Cancelada e Em Atraso (calculado em tempo real).

Controle de Acesso

Cinco perfis hierárquicos — do Super Admin ao Colaborador

Super Admin

Nível plataforma

Acesso total à plataforma. Gerencia todas as organizações (tenants), billing, configurações globais e tem visão completa do audit trail. Único perfil que opera acima do RLS.

Multi-tenantBillingConfig globalAudit total

Admin

Nível organização

Acesso total dentro da sua organização. Gerencia usuários e convites, cria e edita templates de atividades, configura dashboards e é responsável pela conformidade LGPD (DPO).

CRUD totalUsuáriosConfig orgLGPD

Gestor

Nível projetos

Gerencia projetos e planos de ação dentro da organização. Cria macro-ações, atribui tarefas a coordenadores e colaboradores, e acompanha execução via dashboard completo com KPIs.

Planos de açãoAtribuir tarefasDashboard

Coordenador

Nível escopo

Coordena atividades dentro do seu escopo definido pelo Gestor. Move tarefas entre status no Kanban, cria ações dentro das atividades atribuídas e acompanha o progresso operacional.

Mover tarefasKanbanEscopo próprio

Colaborador

Nível execução

Executa apenas as tarefas designadas a ele. Registra horas no timesheet (cronômetro ou manual), adiciona comentários e anexos. Interface simplificada — sem acesso à visão global do projeto.

Tarefas própriasTimesheetComentar

Matriz de Permissões

Visão consolidada de cada recurso por perfil de acesso

Recurso

Super Admin

Admin

Gestor

Coordenador

Colaborador

Criar organização

✓

—

Gerenciar usuários

✓

—

Criar plano de ação

✓

—

Atribuir tarefas

✓

—

Executar tarefas

✓

Timesheet

✓

Dashboard completo

✓

—

Kanban

✓

Apenas suas

Audit trail

✓

—

Configurações LGPD

✓

—

Dupla proteção: RBAC + RLS

RBAC na aplicação

Controla o que o usuário pode fazer. A cada requisição, o middleware do Fastify verifica se o perfil tem permissão para aquela operação antes de executar qualquer lógica de negócio.

RLS no banco

Controla quais dados o usuário enxerga. O PostgreSQL filtra automaticamente por organização via Row Level Security. Mesmo que o RBAC falhe por um bug na aplicação, o RLS no banco impede acesso a dados de outro tenant.

Segurança

Defesa em profundidade — quatro camadas de proteção

Segurança no Banco de Dados

Row Level Security (RLS) por tenant — cada query é automaticamente filtrada por organization_id, impossibilitando acesso cruzado entre organizações
Criptografia AES-256 at-rest para dados sensíveis armazenados no disco — mesmo com acesso físico ao servidor, dados permanecem protegidos
pgcrypto para criptografia de colunas específicas (CPF, dados financeiros, tokens) — dados sensíveis são criptografados individualmente dentro do banco
Princípio do menor privilégio — roles do PostgreSQL separadas (app_user, app_admin, app_readonly) acessam apenas o estritamente necessário
Índices compostos (tenant_id, created_at) em todas as tabelas — performance garantida sem risco de vazamento por query sem filtro

Segurança na API

Rate limiting granular por IP e por usuário — protege contra brute force (login), DDoS e abuso de endpoints. Configurável por rota via plugin do Fastify
Validação de input com JSON Schema em todos os endpoints — payloads fora do schema são rejeitados automaticamente antes de chegar à lógica de negócio
CORS restritivo com whitelist explícita de origens — sem wildcard (*) em produção, apenas domínios autorizados acessam a API
Versionamento explícito /api/v1/ em todas as rotas — garante compatibilidade retroativa ao evoluir a API sem quebrar integrações existentes
Headers de segurança obrigatórios: X-Content-Type-Options (nosniff), X-Frame-Options (deny), Strict-Transport-Security (HSTS) e Content-Security-Policy

Segurança na Autenticação

Access Token JWT de 15 minutos + Refresh Token de 7 dias com rotação automática — cada refresh gera um novo par de tokens, invalidando o anterior
bcrypt com 12 rounds para hash de senhas — custo computacional torna ataques de força bruta inviáveis mesmo com hardware dedicado
Tokens armazenados em httpOnly cookies — inacessíveis via JavaScript no browser, eliminando vetor de ataque XSS para roubo de sessão
2FA obrigatório (TOTP) para perfis Admin e Super Admin — camada extra de verificação via app autenticador (Google Authenticator, Authy)
Audit de login completo na tabela SESSION: IP de origem, user-agent, geolocalização, tentativas falhas com bloqueio automático após 5 tentativas

Segurança em Trânsito e Infraestrutura

TLS 1.3 obrigatório em todas as conexões (API, WebSocket, banco) — criptografia de ponta a ponta em trânsito com forward secrecy garantido
Secrets gerenciados via variáveis de ambiente com rotação periódica — nunca hardcoded no código, validados na inicialização do servidor
Backup incremental nativo do PG17, criptografado com chave AES rotacionada automaticamente — retenção de 90 dias conforme LGPD
Monitoramento contínuo via Prometheus + Grafana — alertas proativos para queries lentas, uso excessivo de CPU, tentativas de login suspeitas
Tabela SECURITY_INCIDENT com workflow de 72h para comunicação à ANPD — classificação de severidade, dados afetados e plano de contenção automatizado

Defesa em Profundidade

A arquitetura de segurança do PixoomFlow é baseada no princípio de defesa em profundidade: quatro camadas independentes de proteção que operam em série. Mesmo que um atacante comprometa uma camada, as próximas continuam bloqueando o acesso.

Camada 1

Trânsito

TLS 1.3 criptografa tudo em movimento

Camada 2

API

Rate limiting + validação bloqueiam requisições maliciosas

Camada 3

Autenticação

JWT + 2FA verificam a identidade do usuário

Camada 4

Todas as proteções são implementadas em código, não em documentos. O sistema garante conformidade automaticamente — RLS impede acesso indevido, audit log registra cada operação e consentimentos são versionados com hash criptográfico.

PostgreSQL 17

Features que resolvem problemas reais do PIXOOM

Performance

VACUUM com 20x menos memória

Crítico para a tabela AUDIT_LOG que cresce continuamente — cada alteração de cada usuário gera um registro via trigger automático. No PG17, o VACUUM usa 20x menos memória, evitando degradação de performance mesmo com milhões de linhas acumuladas.

Query

JSON_TABLE para campos configuráveis

Transforma colunas JSONB em tabelas relacionais diretamente no SQL, sem ETL. Campos customizados de projetos (briefings, metadados) viram colunas consultáveis com índice GIN — filtragem e ordenação nativas.

Backup

Backup incremental nativo (pg_basebackup)

Backups diários de 50GB caem para ~500MB — apenas o delta (dados alterados) é transferido. Viabiliza retenção de 90 dias conforme LGPD sem estourar armazenamento. Backup criptografado com AES-256.

Concorrência

WAL (Write-Ahead Log) otimizado

Dezenas de colaboradores atualizando status, movendo cards no Kanban e registrando horas simultaneamente. O WAL do PG17 tem o dobro de capacidade de escrita concorrente — elimina gargalos de lock em tabelas críticas.

Integração

MERGE com RETURNING

Sincronização com WayV: INSERT se o projeto é novo, UPDATE se já existe — tudo em uma operação atômica. RETURNING devolve o estado final do registro, eliminando race conditions. wayv_project_id UNIQUE por org garante zero duplicatas.

Segurança

Privilégio MAINTAIN (novo no PG17)

Permite manutenção de tabelas (VACUUM, REINDEX, ANALYZE) sem precisar de superuser. Isso é crítico porque superuser ignora RLS — operar sem superuser protege o isolamento entre organizações mesmo durante manutenção.

Por que PostgreSQL 17 e não MySQL 9?

RLS nativo

MySQL 9 não possui Row Level Security. Para isolar dados por tenant, seria necessário criar views manuais por organização ou adicionar WHERE tenant_id = ? em cada query — erro humano garantido.

JSONB indexável

JSONB do PostgreSQL é indexável com GIN (busca em campos aninhados em milissegundos). MySQL JSON é armazenado como texto, mais lento para queries e sem suporte a JSON_TABLE com a mesma flexibilidade.

Partitioning declarativo

PostgreSQL permite particionamento declarativo por organização (tabela AUDIT_LOG particionada por mês). MySQL é limitado a uma coluna de partição por tabela e não suporta partitioning com foreign keys.

Multi-tenancy

Como cada organização vê apenas seus dados — isolamento total via RLS

✓SELECIONADO

Schema único + RLS

Custo

Baixo

Complexidade

Baixa

Isolamento

Alto

Schema por tenant

Custo

Médio

Complexidade

Alta

Isolamento

Alto

Banco por tenant

Custo

Alto

Complexidade

Muito alta

Isolamento

Máximo

Como funciona na prática

Autenticação

Usuário faz login e recebe um JWT contendo organization_id. O token identifica a qual organização (tenant) o usuário pertence.

Middleware RLS

A cada requisição, um hook do Fastify executa SET app.tenant = 'uuid-da-org' na conexão do banco antes de qualquer query. Isso ativa o filtro RLS automaticamente.

Filtragem Automática

O PostgreSQL aplica a policy RLS em todas as queries — SELECT, INSERT, UPDATE e DELETE. O desenvolvedor escreve SQL normal e o banco filtra por tenant automaticamente. Zero WHERE manual.

rls-policy.sql

-- 1. Habilitar RLS na tabela

ALTER TABLE macro_action ENABLE ROW LEVEL SECURITY;

-- 2. Criar policy de isolamento por organização

CREATE POLICY tenant_isolation ON macro_action

USING (organization_id = current_setting('app.tenant')::uuid);

-- 3. A cada request, setar o tenant na conexão

SET app.tenant = 'uuid-da-org';

⚠

Risco crítico com PgBouncer

Ao usar PgBouncer em modo transaction pooling, é obrigatório resetar app.tenant no checkout de cada conexão. Sem isso, uma organização pode ver dados de outra.

✓

Vantagens do schema único

Uma única instância de banco serve todas as organizações — sem multiplicar infra

Migrations aplicadas uma única vez e valem para todos os tenants automaticamente

Backup e restore simplificados — um pg_dump cobre tudo

Monitoramento centralizado — um Grafana observa todos os tenants

Custo fixo independente do número de organizações — escala sem custo linear

Schema versionado no Drizzle ORM — pgPolicy e pgRole definidos em TypeScript

Banco de Dados

22 tabelas em 7 domínios — schema completo com indexes compostos por tenant

22Tabelas

7Domínios

195Colunas

Core

3 tabelas · 27 cols

Base de autenticação, permissões e multi-tenancy. Organizações (tenants), usuários com perfil de acesso e sessões de login ativas.

ORGANIZATION

8 cols

USER

12 cols

SESSION

7 cols

Projetos e WayV

2 tabelas · 17 cols

Integração com sistema externo WayV. Projetos importados via Project ID e log detalhado de cada sincronização (sucesso, falha, retry).

PROJECT

10 cols

WAYV_SYNC_LOG

7 cols

Plano de Ações

6 tabelas · 59 cols

Coração do sistema. Funil de 3 níveis (planos → macro-ações → atividades → tarefas), dependências entre ações e templates reutilizáveis de atividades.

ACTION_PLAN

9 cols

MACRO_ACTION

14 cols

ACTIVITY

12 cols

TASK

11 cols

DEPENDENCY

5 cols

ACTIVITY_TEMPLATE

8 cols

Timesheet

1 tabela · 9 cols

Controle de horas trabalhadas. Apontamentos vinculados diretamente a atividades e tarefas, com cronômetro em tempo real ou inserção manual e fluxo de aprovação.

TIMESHEET_ENTRY

9 cols

Comunicação

3 tabelas · 25 cols

Interações e rastreabilidade. Comentários em tarefas/atividades, audit trail automático via trigger (quem alterou o quê, quando) e notificações push em tempo real via Socket.io.

COMMENT

7 cols

AUDIT_LOG

10 cols

NOTIFICATION

8 cols

Dashboards

3 tabelas · 22 cols

Camada de visualização. Dashboards customizáveis por perfil de acesso, widgets configuráveis (KPIs, gráficos, tabelas) e configuração da visão Kanban por projeto.

DASHBOARD

6 cols

DASHBOARD_WIDGET

9 cols

KANBAN_VIEW

7 cols

LGPD

4 tabelas · 36 cols

Conformidade regulatória em código. Consentimentos granulares com hash SHA-256, requisições DSAR automatizadas, registro de incidentes com workflow de 72h e políticas de retenção de dados configuráveis.

CONSENT_LOG

8 cols

DSAR_REQUEST

10 cols

SECURITY_INCIDENT

11 cols

DATA_RETENTION_POLICY

7 cols

22 tabelas · 7 domínios · Indexes compostos por tenant + created_at em todas as tabelas

Regras de Negócio

12 regras que governam o sistema — organizadas em 3 pilares

Fluxo de Ações

Dependências Inteligentes

Uma macro-ação só pode iniciar quando sua predecessora estiver concluída. A tabela DEPENDENCY armazena relações predecessor→successor e a API valida transições automaticamente antes de permitir mudança de status.

Conclusão Cascata

Um plano de ação só é marcado como concluído quando 100% das macro-ações, atividades e ações estiverem finalizadas. Após conclusão, is_locked = true impede qualquer edição retroativa.

Alertas Automáticos

Predecessora concluída → notificação push ao responsável da próxima. Deadline em 48h → alerta amarelo. Atraso detectado → notificação ao gestor. Tudo via BullMQ + Socket.io.

Prioridade por Deadline

No Kanban, tarefas são ordenadas pelo deadline mais próximo na cadeia hierárquica (macro-ação → atividade → ação). O deadline mais urgente sempre aparece primeiro, sem configuração manual.

Dados e Auditoria

Sem Duplicação WayV

Constraint UNIQUE(organization_id, wayv_project_id) impede duplicatas. O comando MERGE do PG17 faz INSERT ou UPDATE em operação atômica — zero race conditions durante sincronização.

Movimentação Visual

Drag-and-drop no Kanban atualiza sort_order no banco em tempo real via Socket.io. Toda movimentação entre status é registrada no AUDIT_LOG com timestamp e usuário responsável.

Audit Trail Obrigatório

Trigger automático no PostgreSQL registra cada INSERT, UPDATE e DELETE. Grava: quem (user_id), o quê (tabela e coluna), quando (timestamp), de onde (IP, user-agent) e valores antes/depois em JSONB.

Atraso Computado em Tempo Real

Sem campo is_delayed no banco — atraso é calculado dinamicamente: status = in_progress AND planned_end < NOW(). Isso garante que o estado está sempre correto, sem jobs de atualização.

Experiência do Usuário

Timesheet Integrado

Cronômetro em tempo real via Socket.io (inicia/pausa/finaliza) ou inserção manual de horas. Cada entrada é vinculada a uma ação específica na tabela TIMESHEET_ENTRY, com fluxo de aprovação pelo gestor.

Visibilidade do Colaborador

Colaborador vê apenas tarefas atribuídas a ele (assigned_to = user_id). Interface simplificada sem menus de gestão. RLS garante que mesmo via API direta, dados de outros não são acessíveis.

Status Consistente

Cinco status idênticos em todos os níveis do funil (macro-ação, atividade, ação): Em Início, Em Andamento, Concluída, Cancelada e Em Atraso (calculado). Enum compartilhado garante consistência.

Kanban Permissionado

Esteira visual com drag-and-drop filtrada pelo perfil de acesso. Colaborador vê suas tarefas, Coordenador vê seu escopo, Gestor vê todo o projeto. Configuração na tabela KANBAN_VIEW por projeto.

Escala e Performance

Como crescer de 1.000 para 50.000+ usuários sem reescrever

Fase 1

MVP

~1.000 usuários, ~100 organizações

VPS com PG17 (4vCPU/16GB), Redis local, Fastify + Next.js no mesmo servidor. Monolito modular com deploy único.

R$ 500-800/mês

Fase 2

Crescimento

1k–10k usuários

Read replica do PG17 para queries pesadas (dashboards). Worker BullMQ em processo separado. Cache agressivo no Redis para sessões e queries frequentes.

R$ 1.500-3.000/mês

Fase 3

Scale

10k–50k usuários

Múltiplas réplicas de leitura. PgBouncer para connection pooling. Partitioning do AUDIT_LOG por mês. CDN para assets estáticos. Extração de serviços críticos.

R$ 5k-10k/mês

Fase 4

Enterprise

50k+ usuários

Sharding por organização. Microsserviços seletivos (filas, notificações). Instâncias dedicadas para clientes enterprise. Multi-região.

Sob demanda

Otimizações desde o dia 1

Indexes compostos (organization_id, created_at) em todas as tabelas — queries filtradas por tenant são instantâneas
Partitioning declarativo do AUDIT_LOG por mês — queries históricas não escaneiam a tabela inteira
Paginação cursor-based obrigatória — sem OFFSET que degrada com volume. Cursor garante performance constante
Atraso calculado em tempo real (status + planned_end < NOW()) — sem campo armazenado, sem job de atualização
Cache de sessões e queries frequentes no Redis com invalidação por tenant — TTL configurável por tipo de dado
Jobs assíncronos via BullMQ — sync WayV, notificações, audit e relatórios não bloqueiam a thread principal

PIXOOM Blueprint Técnico v4.0 — Fevereiro 2026

5 Perfis · 3 Módulos · 3 Níveis · 22 Tabelas · 7 Domínios · PostgreSQL 17 + RLS

Arquitetura e anatomia completa da plataforma enterprise de gestão de planos de ação