Sistema de Gestão de Rotina — proposta para validação

Versão 1 · 24/10/2026 · idioma pt-BR · fuso inicial America/Fortaleza.

1. Arquitetura e justificativa

Recomendação: PWA responsiva com Next.js e TypeScript na Vercel, Supabase exclusivo para Auth, PostgreSQL, Storage privado e rotinas de backend. A mesma aplicação atende iOS/iPadOS, Android, macOS e Windows por navegadores atuais. A interface se adapta ao espaço disponível e à entrada por toque, mouse ou teclado. No iPhone, abre no Safari e pode ser adicionada à Tela de Início. A proposta não inclui binários nativos para cada sistema nesta fase. O MVP exige conexão para confirmar alterações operacionais; rascunhos locais ficam claramente separados de registros oficiais.

Opção avaliada	Vantagem	Limitação para esta entrega
SwiftUI	Integração nativa com câmera, Keychain, notificações e execução local	Distribuição Apple e interface web separada; maior manutenção inicial
React Native	Código compartilhado iOS/Android e recursos nativos	Distribuição de binários; web administrativa exige trabalho próprio
Flutter	UI e código compartilhados	Outra stack; publicação Apple e integração web específicas
PWA / Next.js	Acesso imediato pelo domínio solicitado; mesma base no iPhone, iPad e web	Push no iPhone exige instalação na Tela de Início e permissão; execução de fundo é limitada pelo iOS

Reavaliar React Native se forem essenciais offline operacional prolongado, integração industrial com Bluetooth/NFC, política MDM ou distribuição pela App Store. Backend e contratos permanecem reutilizáveis. A PWA não será apresentada como binário nativo.

Componentes

flowchart TD
  A[iOS / Android / macOS / Windows] -->|HTTPS + sessão| B[Next.js na Vercel]
  B --> C[Supabase Auth]
  B -->|JWT do usuário| D[PostgreSQL: RLS + transações]
  A -->|upload autorizado| E[Storage privado]
  D --> F[Outbox de eventos]
  G[Supabase Cron] --> H[Worker / Edge Function]
  H --> F
  H --> I[Web Push / e-mail / caixa interna]
  H --> J[Tentativas e resultados]

Separar apresentação, contratos de API, serviços de domínio, comandos transacionais, consultas e adaptadores de provedores. Validações críticas e autorização ficam no banco/backend, não apenas nos componentes. As leituras e gravações usam JWT do usuário; segredo de serviço fica restrito ao worker administrativo. Funções privilegiadas internas têm escopo mínimo, search_path fixo e execução pública revogada.

Contas e disponibilidade verificadas

Vercel: equipe tallespv-2139s-projects (team_emaIw43NqV4rnssasKGTe0Eu). O registro do domínio confirma o e-mail criador tallespv@gmail.com.
Supabase: organização TallesPV (xxbipkalkfzzsuzxbqee), plano Free. O conector confirmou a organização, mas não retornou o e-mail do usuário autenticado. A titularidade exata do login precisa ser conferida antes de provisionar o banco.
Nenhum projeto Sistema de Gestão de Rotina existente encontrado nas consultas iniciais. Não reutilizar bancos de Selato, Virei3D ou do hub.
Domínio raiz registrado externamente; DNS autoritativo HostGator. Configurar apenas hadson, preservando site, e-mail e demais registros.
A sessão Vercel local está no plano Hobby. Antes de uso empresarial real, adequar o plano às condições comerciais: o Hobby é restrito a uso pessoal não comercial, conforme documentação oficial. Nenhum upgrade foi contratado.
Criação de projeto Supabase e custos serão avaliados depois da validação. Não presumir disponibilidade de projetos gratuitos, SLA, PITR ou capacidade de produção no plano atual.

2. Modelo relacional proposto

Todos os objetos operacionais têm UUID, organization_id, criação do servidor e versão para concorrência. Timestamps são timestamptz em UTC. Calendários e relatórios aplicam o fuso da unidade.

Entidade	Campos e relações principais
organizations	id, nome, timezone, política de retenção
profiles	id FK auth.users, nome, equipe, função, departamento, contato corporativo, ativo
units / areas / teams	organização → unidade → área; equipes e vínculo de pessoas
memberships / role_grants	usuário, organização, perfis acumuláveis e escopos de unidade/área/equipe
assets	organização, unidade/área, código único, nome, sistema, localização, ativo
categories / disciplines / block_reasons	catálogos por organização
tags	UUID imutável; código único por organização; título, descrição, categoria, ativo, unidade, área, localização, disciplina, criticidade, risco, referência externa, esforço estimado
tag_people	tag, pessoa, papel: demandante original, demandado, executor principal/secundário, aprovador, gestor, observador
assignments	tag, usuário/função, vigência início/fim, atribuído por, justificativa; apenas uma principal vigente
tag_dates	tag, created_at imutável, received_at, started_at, original_due_at imutável, approved_due_at, submitted_at, approved_at, closed_at
plan_versions	tag, número da versão, autor, justificativa, vigência; versão ativada imutável
stages	versão do plano, parent_stage_id opcional, título, descrição, executor, datas previstas/reais, peso, progresso, status, obrigatória, critério de aceite
stage_dependencies	predecessora, sucessora, obrigatória; sem ciclos e sem relações entre Tags
milestones	tag/etapa, título, vencimento previsto e realizado
progress_updates	etapa, valor anterior/novo, evidência, autor, timestamp; eventos anexados
blockers	tag/etapa, motivo, responsável pelo desbloqueio, previsão quando aplicável, resolução
deadline_requests / deadline_versions	original preservado, prazo anterior, proposto/aprovado, justificativa, solicitante e decisor
comments / attachments	tag/etapa, autor; objeto privado, tipo, tamanho, hash e estado de inspeção
approvals	tag, versão do plano, rodada, solicitação, aprovador, decisão, motivo, datas
audit_events	organização, agregado, ator, evento, dados anterior/novo pertinentes, motivo, correlação, timestamp; append-only
notification_rules	organização/equipe/criticidade, eventos, antecedência, recorrência, níveis de escalada, versão
notification_preferences / push_subscriptions	usuário, canais, horários, consentimento, endpoint/chaves protegidos
event_outbox / notification_jobs / attempts	evento, regra, destinatário, canal, agendamento, chave idempotente, tentativas, resultado e leitura interna
saved_views / report_jobs / settings	filtros e ordenação, exportação autorizada, parâmetros versionados

Integridade e índices

UNIQUE (organization_id, tag_code) e UUID separado; número gerado por sequência transacional, com lacunas aceitáveis.
FKs compostas com organização para impedir associação a pessoa, ativo ou área de outra organização. Sem cascata destrutiva para trilha operacional; inativação de cadastros.
Pesos positivos, progresso entre 0 e 100; plano ativo com soma 100, com validação transacional diferida. Não haverá normalização silenciosa.
Progresso de pais agrega folhas por peso; pais e filhos nunca entram duas vezes no total. Folhas sem peso ou plano incompleto impedem ativação.
Índices por organização + status + vencimento; unidade/área; responsável vigente; criticidade; atualização. Busca textual tsvector em português e índice trigram para código/ativo. Paginação por cursor.
UNIQUE (organization_id, actor_id, idempotency_key) para comandos; mesma chave com corpo diferente gera conflito.
Índice único parcial na atribuição principal ativa e em (event_id, rule_version, recipient_id, channel, scheduled_bucket) para notificações.
Audit trail sem UPDATE/DELETE para papéis da aplicação; correções geram novo evento referenciando o anterior. Administrador de infraestrutura continua sendo uma fronteira de confiança: exportação externa assinada de auditoria é prevista para requisitos mais fortes.

Comandos de domínio

create_tag, acknowledge_tag, start_execution, activate_plan, update_stage_progress, record_blocker, resolve_blocker, request_deadline_change, approve_deadline_change, transfer_assignment, submit_approval, decide_approval, close_tag, reopen_tag, cancel_tag.

Cada comando revalida sessão, escopo, permissão, versão esperada, dependências e transição; grava alteração, auditoria e outbox na mesma transação. Erros 403 (permissão), 409 (conflito de versão) e 422 (regra) são distintos. O horário oficial vem do servidor. Não oferecer gravação direta que contorne esses comandos.

3. Ciclo operacional e navegação

Entrada pública → login → Visão geral → Carteira → Detalhe da Tag. Navegação inferior em celulares iOS e Android: Visão geral, Tags, Agenda e Mais. Em telas amplas de Mac e Windows, navegação lateral. Botão Nova Tag visível, alvos mínimos 44 px, texto de campos 16 px, labels e foco acessíveis.

Detalhe → Resumo / Plano de ação / Histórico. Ações contextuais conforme permissão. Mais → Relatórios / Alertas / Pessoas / Configurações. Gestores usam o mesmo sistema em tela ampla com navegação lateral.

Cadastro rápido exige título, unidade/área, categoria, criticidade, demandante e responsável; ativo, descrição, anexos e referência externa podem ser enriquecidos conforme configuração. Código e criação são gerados ao confirmar no servidor. Rascunho não consome código oficial. Recuperação de formulário mostra data do salvamento e opção de descarte.

Origem	Destino	Condições principais
Rascunho	Aberta	Validação dos campos e criação transacional
Aberta	Aguardando ciência	Atribuição registrada; notificar
Aguardando ciência	Planejada	Ciência pelo destinatário; plano/prazo definido
Aberta / Planejada / Reaberta	Em execução	Executor autorizado; registrar início efetivo uma vez
Em execução	Aguardando material / contratação / Bloqueada	Motivo e responsável pelo desbloqueio; previsão ou justificativa de ausência
Espera / Bloqueada	Planejada / Em execução	Resolução registrada; manter datas e histórico
Em execução	Concluída tecnicamente	Etapas técnicas obrigatórias concluídas; evidências de aceite
Concluída tecnicamente	Aguardando aprovação	Pacote de evidências; rodada e aprovador definidos
Aguardando aprovação	Encerrada e validada	Aprovação vigente; todos os requisitos finais, testes, documentos e bloqueios resolvidos
Aguardando aprovação	Reaberta	Rejeição motivada; preservar a rodada rejeitada
Encerrada e validada	Reaberta	Gestor autorizado, motivo, novo ciclo e novo prazo
Estados ativos	Cancelada	Gestor, justificativa; suspender jobs futuros

O estado Concluída tecnicamente é independente do percentual e da aprovação. Técnico 100% não significa encerramento. Marcos de aceite, testes e documentação podem ser gates fora do escopo de esforço técnico; se forem etapas técnicas ponderadas, entram no cálculo. Essa classificação deve ser explícita no plano.

Reabertura preserva o primeiro início e os encerramentos anteriores em ciclos históricos. Datas de criação não são editáveis. Transferência encerra vigência anterior e inicia outra, sem reescrever demandante original.

Protótipo entregue

Visão geral com indicadores calculados sobre fixtures; carteira com busca e filtros; agenda; detalhes com progresso e histórico; cadastro com recuperação de rascunho; simulações locais de início, bloqueio, progresso, aprovação e reabertura; exportação CSV e impressão do relatório. Proposta técnica acessível pelo menu.

Todos os registros são fictícios. As simulações ficam somente no navegador, podem ser reiniciadas e não implementam segurança, persistência de backend ou entrega de alertas. A validação desta fase é de navegação, linguagem e regras propostas. A revisão visual acrescenta atalhos operacionais, próxima ação contextual, feedback ao toque/clique, transições discretas, indicação de alterações não salvas e movimento reduzido automático ou manual. Os botões são controles HTML acessíveis, e a ilustração gerada é apenas apoio visual; textos e ações não ficam embutidos na imagem.

4. Indicadores e cálculos

Denominadores e filtros aparecem no relatório. Todos os cálculos usam apenas registros autorizados. Indicadores não recebem tendências inventadas: comparar períodos equivalentes somente quando houver histórico.

Indicador	Definição
Total	Tags oficiais criadas dentro do período filtrado; rascunhos separados
Em aberto	Todos os estados não terminais, exceto rascunho; inclui espera e aprovação
Em execução	Status exatamente Em execução
Aguardando terceiros	Material + contratação/recurso externo
Bloqueadas	Status Bloqueada; bloqueios abertos também listados no detalhe
Próximas do vencimento	Ativas com prazo vigente entre agora e limite configurável (inicial 7 dias)
Atrasadas	Ativas com prazo vigente menor que agora; bloqueio não pausa prazo automaticamente
Concluídas tecnicamente	Status Concluída tecnicamente; separadas de encerradas
Encerradas	Encerradas e validadas no período de encerramento
Progresso por Tag	Σ(peso da folha × progresso da folha) / Σ(pesos); escala 0 a 100; plano ativo válido
Média simples	Média dos progressos das Tags ativas com plano válido; divulgar cobertura x/y
Média por esforço	Σ(esforço estimado da Tag × progresso) / Σ(esforço estimado), apenas estimativas positivas; divulgar cobertura
No prazo vigente	Encerradas até o prazo aprovado vigente no fechamento / encerradas elegíveis no período
No prazo original	Mesmo denominador, comparação com prazo original; mostrar junto ao vigente
Idade média	Média de (agora − criação) das Tags ativas, em horas/24
Tempo até início	Início efetivo − criação; sem início aparece como pendente, nunca zero
Tempo de execução	Conclusão técnica − início do ciclo; tempo bruto e esperas explicitados
Tempo de aprovação	Decisão − submissão por rodada, sem apagar rejeições
Sem atualização	Ativas com último evento operacional anterior ao limiar configurado

Correção do exemplo fornecido: 10×100 + 20×100 + 20×50 + 40×25 + 10×0 = 5.000; dividido por 100 = 50%. A especificação dizia 40%, mas a fórmula resulta em 50%.

Prazo informado como data civil vence no fim desse dia no fuso da unidade; prazo com horário vence naquele instante. Dias de atraso exibidos = teto das horas positivas /24, acompanhados da data/hora exata. O worker compara instantes, não strings de datas. Dias úteis só com calendário corporativo configurado.

5. Notificações e escalonamento

Regras versionadas por organização, criticidade, equipe e usuário. Antecedências, recorrência, silêncio e escaladas são dados de configuração; valores 7/3/1/0 dias são sugestões iniciais editáveis.

Transação operacional cria evento na outbox.
Cron no servidor seleciona vencimentos e eventos de ciência/início ausentes, cria jobs deduplicados e avalia níveis de escalada.
Worker reivindica jobs com lock e lease, confere novamente estado atual, responsável, regra e preferências e despacha por canal.
Retentativas com backoff e limite; fila de falhas para inspeção. Cancelamento/encerramento invalida cobranças pendentes. Mudança de prazo invalida geração anterior e recalcula jobs; jobs já reivindicados revalidam antes de enviar.
Chave única impede repetição lógica; falha após aceite do provedor pode gerar resultado indeterminado. Provedores sem idempotência não permitem prometer entrega exatamente uma vez. Reconciliar quando possível.

Eventos previstos: atribuição, ciência/início ausentes, marcos, prazos, atrasos de etapa, bloqueio, transferência, prazo alterado, aprovação solicitada/rejeitada, conclusão, encerramento e reabertura. Nenhuma cobrança em Tag cancelada ou encerrada. Reabertura cria novo ciclo com nova chave.

Escalada: executor → executor/supervisor → gestor de área → gestor de carteira, com níveis e limiares por criticidade, atraso, impacto, bloqueio e ausência de atualização. Bloqueios também direcionam a cobrança ao responsável pelo desbloqueio. Ausência de contato/equipe entra em exceções visíveis, sem destinatário inventado.

Push inclui código, resumo, prazo, responsável, situação e deep link; opção de conteúdo discreto para tela bloqueada. Permissão por gesto do usuário. No iPhone, Web Push exige app na Tela de Início em iOS 16.4+; testar versões atuais e aparelhos reais. Sem permissão, oferecer caixa interna/e-mail conforme preferência. O aceite do push não prova exibição, leitura ou entrega física. Leitura é registrada na caixa interna; e-mail tem eventos do provedor quando disponíveis.

Fontes técnicas: WebKit — Web Push no iOS, Supabase Cron.

6. Permissões

Perfis acumuláveis, sempre limitados pelo escopo; negar por padrão. Uma pessoa não aprova o próprio trabalho por padrão. Exceção exige gestor autorizado e trilha explícita. Administrador não recebe dispensa silenciosa dos gates.

Ação	Administrador	Gestor	Demandante	Executor	Aprovador	Visualizador
Consultar	Escopo	Carteira	Próprias/permitidas	Atribuídas	Designadas	Autorizadas
Criar	Sim	Sim	Sim	Se acumular demandante	Se acumular demandante	Não
Configurar pessoas/regras	Sim	Regras autorizadas da carteira	Não	Não	Não	Não
Atribuir/transferir	Sim	Sim	Não	Solicitar	Não	Não
Ciência/início/progresso	Se executor designado	Se executor designado	Não	Sim, nas atribuídas	Não	Não
Solicitar prazo	Sim	Sim	Solicitar	Solicitar	Não	Não
Aprovar prazo/pesos/exceções	Sim, com escopo	Sim, com escopo	Não	Não	Só com perfil gestor	Não
Aprovar/rejeitar entrega	Se designado	Se designado	Não	Não, quando autor	Sim, se designado	Não
Encerrar	Após gates	Após gates	Não	Não	Após aceite e autorização	Não
Cancelar/reabrir	Sim, motivo	Sim, motivo	Solicitar	Solicitar	Solicitar	Não
Exportar	Dados autorizados	Dados autorizados	Se autorizado	Se autorizado	Se autorizado	Se autorizado

RLS em todas as tabelas expostas; autorização não usa user_metadata editável. Memberships consultados no backend evitam depender apenas de claims antigas. Views de consulta com security_invoker; escopo também no Storage e nas funções de relatório. MFA obrigatório para administradores/gestores no piloto de produção. Sessões revogáveis, HTTPS e política de expiração.

7. Segurança, confiabilidade e privacidade

Storage privado, links assinados de curta duração, validação de extensão/conteúdo/tamanho e inspeção de anexos antes da liberação. Exportações privadas, temporárias e auditadas; CSV protegido contra fórmulas maliciosas.
Rate limits em login, comandos e uploads. Logs técnicos sem credenciais, endpoints push ou conteúdo pessoal desnecessário.
Escritas com versão esperada; conflitos exigem recarregar/comparar, nunca sobrescrever silenciosamente. Retry reutiliza a chave idempotente. Incerteza de rede mostra “confirmação pendente” e consulta o resultado antes de reenviar.
MVP online: nenhum armazenamento offline de carteira industrial. Rascunho local com prazo de expiração e limpeza no logout; opção de desativar em dispositivo compartilhado. Offline operacional criptografado e resolução de conflitos são uma fase própria, não alegar proteção de localStorage.
Backup de banco e Storage são rotinas separadas. Proposta inicial RPO 24h e RTO 8h, sujeitos a plano/custo e ensaio de restauração. Exportação criptografada externa, retenção, inventário de objetos e exercício de recuperação em ambiente isolado antes do uso real. Não prometer RPO/RTO sem medir.
LGPD: definir controlador/operador, finalidade, base legal, contato de privacidade, retenção e processo de titulares com a organização. Minimização de contatos e fotos; retenção de auditoria documentada. Conformidade depende desses processos e contratos, não somente do código.
Observabilidade: jobs atrasados, falhas de autenticação/worker, dead letters, entregas indeterminadas, disponibilidade e falhas de backup; alertas de operação com responsáveis definidos.

8. Etapas de desenvolvimento e implantação

Etapa	Entrega	Gate de aceite
0 — atual	Arquitetura, modelo, protótipo, fórmulas, plano	Validação do usuário
1 — fundação	Supabase dedicado, Auth, memberships/RLS, catálogo mínimo, migrations	Login e testes de isolamento/negativa de acesso
2 — MVP operacional	Cadastro, atribuição/ciência, planos, início/progresso, prazos, bloqueios, aprovação, auditoria	Fluxo completo em banco real e concorrência/idempotência
3 — gestão e alertas	Dashboard real, busca/filtros, caixa interna, worker e escaladas, CSV	Indicadores conciliados e scheduler sem app aberto
4 — piloto multiplataforma	PWA, Web Push, anexos, sincronização por recarga/Realtime autorizado, relatórios	iPhone e Android reais; Mac e Windows; push aberto/fundo/fechado e restauração
5 — evolução	Excel, PDF de servidor, quadro, calendário avançado, favoritos, offline conforme necessidade	Aceites específicos e desempenho

Ambientes separados para desenvolvimento/homologação/produção. Migrations versionadas revisadas, verificações de RLS, testes e build antes de promover na Vercel. Testar migrações em homologação, fazer backup e usar mudanças compatíveis com versões anterior e nova. Rollback do frontend não desfaz migrações; recuperação do banco requer plano próprio.

Variáveis previstas: NEXT_PUBLIC_SUPABASE_URL, NEXT_PUBLIC_SUPABASE_PUBLISHABLE_KEY, APP_URL, credencial de worker somente no servidor, segredo do endpoint do scheduler, chaves VAPID pública/privada, identificação e chave do provedor de e-mail. Nunca versionar .env nem publicar segredo privilegiado em NEXT_PUBLIC_*. Rotação com runbook e verificação.

Domínio de produção: https://sgr.tallespv.com.br; acesso público ao app/login, conteúdo privado após autenticação. HTTPS e propagação DNS precisam de verificação externa. O protótipo público mostra somente dados fictícios.

Distribuição inicial: abrir no Safari → Compartilhar → Adicionar à Tela de Início → entrar com conta corporativa convidada → habilitar notificações se desejado. Não há binário ou App Store nesta proposta inicial. Publicação Apple futura exige conta, identificadores, política de privacidade, assinatura, TestFlight e revisão.

Decisões a validar

App web responsivo para iOS, Android, macOS e Windows, hospedado na Vercel e com backend Supabase dedicado.
MVP online, com rascunho recuperável e sem edição offline de dados oficiais.
Perfis acumuláveis, escopos por unidade/área e aprovação independente do executor.
Progresso ponderado com pesos somando 100; aprovação e encerramento separados.
Evolução nas etapas acima, com custos e titularidade Supabase conferidos antes do provisionamento.

Pendências de negócio para o piloto: nome e estrutura real das unidades/áreas, cadastro inicial dos responsáveis e aprovadores, regras de autoaprovação/exceção, política de horário de cobrança, calendário útil, provedor de e-mail, retenção, capacidade e orçamento. Esses dados podem ser coletados durante a fundação sem inventar estrutura industrial.