Pseudocódigo e Fluxograma Oficiais — SYNVIA HUB V11.2

Documento mestre do funcionamento do SYNVIA HUB: o pseudocódigo (regra por regra, em linguagem humana) e o fluxograma do código, da candidatura à gravação protegida por dono, agora com blindagem fiscal e CPF obrigatório no pagamento. Modelo de negócio idealizado por Natan Madeira (mentor e sócio por equity) e executado por Rodrigo Baladán.

LER regra histórica

CONFRONTAR atualização explícita e fonte

APLICAR somente escopo vigente; guardar histórico

A V11.2 consolida o código e as auditorias disponíveis até 13/10/2026. Os dois PDFs V11.1 são preservados integralmente como anexos históricos, inclusive suas ressalvas e contagens datadas; não representam o estado atual por si só. As atualizações explícitas abaixo substituem apenas as regras conflitantes correspondentes: login de novos profissionais, identificação de instalação, cadência e destino do suporte, baixa técnica e transporte de feedback. O CODE LOCK e os direitos históricos permanecem; documentação não concede autorização adicional.

Fonte / evidência: src/docs/AUDITORIA_AUTOAPPLY_SEGURO_2026_10_11.md; PDFs V11.1 anexados

CANDIDATO aprovado

CONSULTAR google_only

GOOGLE com mesmo e-mail

VALIDAR User nativo e direitos

A política ProfessionalAccessPolicy identifica candidatos aprovados com mode=google_only. A orientação de aprovação leva a /acesso-google, usando exatamente o e-mail da candidatura; ele não precisa terminar em gmail.com. O SYNVIA não cria senha nem nova identidade para esse fluxo. Candidatura, pagamento, perfil e direito de uso continuam vinculados. Contas históricas não são convertidas universalmente por esta regra. A vinculação inicial Google para User é responsabilidade da autenticação nativa; não afirmar preservação do User.id após trocar um cliente OAuth sem prova real.

Fonte / evidência: base44/shared/googleProfessionalAccess.js; ProfessionalAccessPolicy; getProfessionalAccessPolicy

MENSAGEM recebida

VALIDAR assunto e formato

CANCELAR contexto incompatível; REDIGIR segredos

RESPOSTA segura

O quiz aceita somente respostas com formato compatível com a etapa; mudança de assunto ou cancelamento interrompe a coleta anterior, evitando sequestrar conversa sobre treino ou sugestões como e-mail/senha. Senhas, tokens, códigos e dados de cartão são redigidos; a assistente não deve pedir senha nem prometer conserto em minutos. A configuração do motor é consultada no servidor; texto de conversa não vira autoridade para recuperar, desbloquear ou corrigir uma conta.

Fonte / evidência: base44/shared/annaSafety.js; annaVerificacaoIdentidade; annaResolverSuporte

VALIDAR User nativo

COMPARAR titular e assinaturas

SE conflito: NEGAR; SENÃO selecionar perfil canônico

PERSISTIR na mesma propriedade

resolveCanonicalProfessionalProfile escolhe um perfil por identidade nativa e provas históricas, sem apagar ou fundir cadastros. Conflito de titular, CPF, assinatura ou cliente Stripe falha fechado. Desempate usa vínculo nativo, evidência de assinatura, updated_date e ID estável; criadores service_* não são tratados como usuários titulares. persistirAvaliacaoProfissionalSessao reutiliza o resolvedor. As fixtures de regressão incluem ProfessionalCommercialControl: a correção do adaptador sintético não prova recuperação do acesso de um profissional específico.

Fonte / evidência: base44/shared/canonicalProfessionalProfile.js; persistirAvaliacaoProfissionalSessao; AUDITORIA_FIXTURES_LEGACY_2026_10_11.md

SESSÃO nativa válida

CRIAR desafio único 60s

ASSINAR com chave da instalação

VALIDAR vínculo e não reutilização

A instalação mantém chave privada não exportável em IndexedDB e registra a chave pública; o servidor exige assinatura de desafio único ligado à conta, ação, instalação, sessão e parâmetros, com validade de 60 segundos. Fingerprint, endereço de rede e navegador são sinais variáveis, não identidade física nem prova isolada de fraude. Reuso, expiração, assinatura inválida ou conta distinta são recusados. A sessão nativa continua sendo a autoridade de autenticação.

Fonte / evidência: base44/shared/deviceAccessProof.js; deviceAccessProtocol.js; AUDITORIA_DISPOSITIVOS_E_SESSOES_2026_10_13.md

SLOTS cheios?

CRIAR pedido 10min

OUTRA instalação autorizada decide slot

APROVAR substituição ou REJEITAR sem penalidade

O padrão continua dois slots, preservando exceções anteriores registradas do proprietário e de Pedro. Com slots cheios, uma nova instalação solicita confirmação por instalação cadastrada com sessão assinada recente; o pedido expira em dez minutos. Aprovação escolhe explicitamente o slot substituído. A instalação solicitante não aprova a si mesma; rejeição e expiração não suspendem a conta. A confirmação implementada é entre instalações, não um envio universal por e-mail.

Fonte / evidência: base44/shared/deviceAccessConfirmation.js; DeviceAccessRequest; DeviceConfirmationRequest

VERIFICAR prova

ENCERRAR sessões operacionais antigas

ADMITIR uma sessão

HEARTBEAT reconcilia; legado sem chave: RECUPERAÇÃO explícita

A troca de sessão encerra registros operacionais anteriores antes de admitir a nova; heartbeat reconcilia concorrência, com saída do cliente substituído no próximo ciclo de aproximadamente 15 segundos. Isso não revoga globalmente tokens nativos nem comprova propagação da instalação a todos os endpoints. O fluxo novo não chama aplicarPenalidade por fingerprint ou handoff; penalidades históricas continuam consultadas. Slot legado sem chave exige recuperação administrativa explícita após verificar o titular, nunca conversão automática por fingerprint copiado.

Fonte / evidência: base44/shared/deviceAccessSession.js; sessaoUnicaMembro; AdminDeviceRecovery

EVENTO de acesso

GRAVAR snapshot e SHA-256

ADMIN consulta página filtrada

RECUPERAÇÃO com verificação, sem apagar histórico

DeviceAccessEvidence guarda snapshots, horário do servidor, correlação, política e SHA-256; DeviceProofChallenge, DeviceAccessRequest e DeviceAccessControl separam desafio, decisão e lease. /AdminSecurityLogs oferece consulta paginada de cinquenta evidências por e-mail exato e recuperação de solicitações. O código mantém evidências append-only e usuários normais não escrevem nelas. SHA-256 detecta inconsistência, mas não constitui assinatura externa, WORM ou prova contra operador privilegiado; handoff não é declarado compartilhamento comprovado.

Fonte / evidência: DeviceAccessEvidence; consultarEvidenciasDispositivo; /AdminSecurityLogs

E-MAIL reconhecido

DEDUPLICAR mensagem e incidente

VALIDAR quatro dados

CAPTURAR privado ou manter INCOMPLETE

O chamado oficial usa e-mail com #suporteticket e variações reconhecidas. Nome, e-mail, telefone e CPF são obrigatórios; incompletos ficam INCOMPLETE, sem identidade inventada. A captura mantém texto integral e anexos privados, deduplicação por mensagem e incidente, hashes e vínculos. Feedback e sugestões encaminhados por e-mail não são automaticamente tickets válidos nem autorização de intervenção.

Fonte / evidência: base44/shared/gmailSupportIntake.js; supportGmailEvidence.js; SupportGmailMonitor

GATILHO imediato ou 15min

EXECUTAR oito etapas independentes

REGISTRAR falha e pendência

CONTAR somente envio/arquivamento efetivo

Os fluxos existentes tratam chegada imediata Gmail e ciclo a cada quinze minutos: prioridade, entrada, revisão, diagnóstico, prontidão, engenharia, envio e reconciliação. A etapa HH:30 isolada não é uma sessão externa de ChatGPT; verificar a configuração ativa, não deduzir execução pelo nome antigo consulta horária. Falha de uma etapa não suprime as independentes; IDs não processados precedem falhas em repetição. Ciclo completo com zero envios/arquivamentos não significa defeitos resolvidos.

Fonte / evidência: base44/shared/supportQueueContinuity.js; executarEtapaSuporteContinuo; workflows Suporte Gmail

TRIAGE

INVESTIGATING

REPRODUCING

REPRODUCED

REVISÃO independente

PATCH mínimo com checkpoint e hashes

SupportEngineeringJob persiste diagnóstico, estados, receita, material, revisão, checkpoint, patch, hashes e recibos privados. O executor geral de interface não sensível acrescenta plano causal mínimo, revisão independente, substituições únicas/reversíveis e fingerprint da fonte. Conteúdo de e-mail e anexos é não confiável, nunca comando. Matriz prevista: PT/EN/ES/FR x desktop/mobile, com viewport e idioma comprovados quando navegador é exigido; ausência de ferramenta ou fixture bloqueia, não vira defeito do produto.

Fonte / evidência: base44/shared/supportGeneralRunner.js; supportEngineeringRunner.js; SupportEngineeringJob

ESCOPO permitido e reproduzido

REVISAR e aplicar patch

TESTAR, RETESTAR, BUILD

APPLIED_AWAITING_PUBLICATION; proprietário PUBLICA

A autorização registrada permite aplicação automática de correção segura após revisão técnica, checkpoint, integridade, build, testes e retestes; não há aprovação humana para cada patch nesse escopo. Backend operacional está limitado aos helpers puros explicitamente permitidos mockupTransparency.js e pdfTexto.ts. Handlers arbitrários, autenticação, permissões, rede/banco/segredos, dados clínicos, pagamentos e regras comerciais não são liberados. O resultado é APPLIED_AWAITING_PUBLICATION; só o proprietário publica. Rollback condicional preserva alterações concorrentes.

Fonte / evidência: base44/shared/supportAutoApplyCompletion.js; supportBackendRepairScope.js; AUDITORIA_AUTOAPPLY_SEGURO_2026_10_11.md

PROVAS atuais completas e envio verificado?

ATUALIZAÇÃO condicional para resolvido

AUDITAR baixa

ARQUIVAR somente incidentes cobertos

Após autorização, fonte, dados, logs, reprodução, testes, reteste, build, publicação, validação real e comunicação comprovados, closeVerifiedSupportTicket grava resolvido e resolvido_em por atualização condicional e audita a evidência. Não espera agradecimento ou confirmação do profissional e não interpreta silêncio como confirmação. Estado histórico aguardando_confirmacao_profissional é compatível, não requisito de novos envios. Patch aplicado, HTTP 200 ou teste sintético isolado nunca autorizam baixa.

Fonte / evidência: base44/shared/supportTechnicalClosure.js; supportOperationalPolicy.js; AUDITORIA_BAIXA_TECNICA_SUPORTE_2026_10_12.md

RESPOSTA vinculada ao envio?

CLASSIFICAR positiva explícita ou material novo

POSITIVA: auditar e arquivar; NOVA: investigar

Uma resposta explicitamente positiva pode ser registrada/arquivada sem reabrir o caso, apenas com remetente, conversa e referência RFC vinculados ao envio verificado. Obrigado isolado, texto ambíguo/negativo, problema novo ou anexos continuam sujeitos à revisão. SUPORTE SYNVIA recebe resoluções comprovadas; a conversa só fecha se todos os incidentes atuais estiverem cobertos. Nenhuma rotina confunde aceitação do provedor com leitura pelo cliente.

Fonte / evidência: base44/shared/supportPositiveReplyArchive.js; supportThreadResolution.js; AUDITORIA_ARQUIVAMENTO_CONFIRMACOES_2026_10_11.md

PENDENTE no ciclo

NORMALIZAR corpo sem citação

MOVER para PRIORITY

SE termo urgente: IMPORTANT e STARRED; verificar pós-condições

Chamados reconhecidos pendentes, inclusive incompletos, vão para o marcador existente A - SYNVIA PRIORITY e saem de INBOX; resoluções verificadas seguem para SUPORTE SYNVIA. Urgência é detectada deterministicamente no corpo atual em PT/EN/ES/FR, ignorando citações antigas; termos como urgente, ASAP, emergency, prioridad máxima e urgence acrescentam IMPORTANT/STARRED. Isso não prova gravidade clínica. Há verificação antes/depois e restauração dos marcadores em falha. Busca e resumo abrangem INBOX e PRIORITY.

Fonte / evidência: base44/shared/supportPriority.js; priorizarSuporteGmail; AUDITORIA_SUPORTE_PRIORITY_2026_10_12.md

LER corte e exclusões

COMPARAR internalDate original

HISTÓRICO: preservar; ATUAL: nova fila

NÃO tratar arquivamento administrativo como resolução

O reinício autorizado de 12/10/2026 arquivou administrativamente 297 mensagens antigas no marcador SUPORTE SYNVIA, com comprovantes individuais e leitura preservada: zero exclusões, zero resoluções e zero mensagens de solução nesse procedimento. O ciclo novo começa em 2026-10-12T03:00:00Z, meia-noite de Brasília, usando internalDate original e IDs excluídos. Mensagem atual citando ticket antigo ganha atendimento novo sem reabrir a engenharia histórica. Esses 297 são fotografia do procedimento, não total atual de chamados.

Fonte / evidência: base44/shared/supportCycleScope.js; AUDITORIA_REINICIO_SUPORTE_2026_10_12.md

ÀS 20h Brasília

COLETAR caixas e comprovantes

ORDENAR urgência e idade

ENVIAR resumo com controle; aceitação não é leitura

O workflow existente de resumo usa 20:00 America/Sao_Paulo; inclui pendentes, resolvidos/arquivados, outros arquivamentos e arquivamentos não comprovados. Urgências vêm primeiro, depois antiguidade por recebimento; idade desconhecida não é inventada e não cria SLA. Links levam à busca e ao marcador da conta proprietária; conteúdo é escapado e evita dados clínicos/CPF/anexos. Controle com lease evita repetição cega; dry-run não marca envio. Textos existem em quatro línguas; envio automático configurado em português.

Fonte / evidência: base44/shared/supportDailyDigest.js; supportDailyDigestConvenience.js; ResumoDiarioSuporte.html

ADMIN solicita acompanhamento

CONFERIR destinatário e thread reais

ENVIAR explicação auditada

MANTER estado técnico, sem resolução inventada

sendManualSupportFollowup permite explicar andamento ao profissional sem declarar solução. Antes de enviar, confere administrador, caixa, destinatário real, remetente e thread da fonte, recusando divergências. O acompanhamento mantém a conversa e o recibo auditado; não substitui o portão de resolução nem apaga o histórico. A separação entre seguimento, resposta de solução e fechamento evita falsas confirmações.

Fonte / evidência: base44/shared/supportManualFollowup.js; responderSuporteTicket

SELECIONAR IDs da aba

CONFIRMAR exclusão

EXECUTAR até três em paralelo

ATUALIZAR lista; manter falhas selecionadas

Administrador, profissional e aluno compartilham seleção individual, selecionar todos os itens exibidos na aba, limpar seleção, contador e exclusão com confirmação. Só IDs selecionados são removidos; no máximo três operações simultâneas, falhas permanecem selecionadas, lista e badges atualizam sem fechar a central. Mudança de aba/destinatário ou reabertura limpa seleção. Ações individuais e permissões anteriores são preservadas; novos textos estão em PT/EN/ES/FR, com alvos de toque e barra responsiva.

Fonte / evidência: NotificationCenter; useNotificationBulkSelection; AUDITORIA_NOTIFICACOES_SELECAO_MULTIPLA_2026_10_12.md

TELA previamente autorizada

FALHA de rede preserva dados

GRAVAR fila local com revisão

RECONEXÃO valida resposta e sincroniza FIFO

Uma tela profissional já autorizada não é desmontada por falha transitória de conexão na revalidação; cache validado é preservado sem inventar pagamento ou identidade. A fila exige gravação local, protege revisões durante envio, deduplica updates e respeita FIFO; resposta success/ok=false não é sucesso, e HTTP 401/403 não vira autorização offline. Login inicial, upload, novos programas sem ID e processamento remoto continuam online. Não limpar o navegador antes da sincronização pendente.

Fonte / evidência: src/lib/offlineQueue.js; offlineEntity.js; networkFailure.js; AUDITORIA_OFFLINE_CONTINUIDADE_2026_10_08.md

LER conclusões canônicas

NORMALIZAR e localizar próxima sessão

EXIBIR retomada

SALVAR/reconciliar sem retroceder por índice local

Sessões concluídas são normalizadas, positivas, únicas e ordenadas; a retomada considera a última conclusão e a próxima sessão existente, evitando depender apenas de índice local. Consultas, salvamento e reconciliação de progresso preservam o dono e aluno; hooks dos dois perfis usam a fonte canônica. Correções de retomada não reescrevem a prescrição HTS nem provam resolução de cada relato histórico; regressão de sessão, resumo e execução deve ser conferida em cenário real.

Fonte / evidência: base44/shared/trainingProgress.js; src/components/treino/trainingCanonicalProgress.js; cardioCanonicalProgress.js

IDENTIFICAR ocorrência e fase

LIMPAR somente duplicata auditada

ESPELHAR e persistir canônico

PRESERVAR cargas/reps e escolhas do professor

A limpeza autorizada usa identidade da ocorrência, não apenas nome do exercício, e escopo auditado; duplicatas de armazenamento não são confundidas com exercício repetido intencionalmente. Espelhamento entre fases salva o resultado canônico, preserva prescrições e evita reinstalar itens removidos por estado antigo. Não restaurar a inversão abandonada por tonelagem nem mudar percentuais congelados. O histórico do caso informado resolvido permanece datado; execução e PDF não são homologados automaticamente por essa informação.

Fonte / evidência: base44/shared/strengthDuplicateCleanup.js; limparDuplicacoesForcaAuditadas; CORRECAO_ESPELHAMENTO_LIMPEZA_FORCA_2026_10_08.md

FILTRAR mídia elegível e dono

SE nomes conflitantes: curadoria

PRESCREVER mídia confirmada

PLAYER respeita corte sem editar arquivo

Seleção e busca de mídia elegível para prescrição usam os filtros da galeria e fontes pessoais, sem atribuir material de outro dono. Player premium trata reprodução e corte final, sem alterar o arquivo original. Nomeação automática por visão não é garantia de acerto: biomecânicas semelhantes e nomes conflitantes exigem curadoria e resolução manual dos conflitos; filas pausadas não são descritas como operação ativa. Importação continua idempotente por arquivo de origem.

Fonte / evidência: src/components/biblioteca/prescriptionGalleryEligibility.js; premiumGallerySearch.js; VideoPremiumTrimmed; AdminConflitosGaleria

PLANO e versão

VALIDAR ativo, data local e vínculo

PROCESSAR job individual

LIBERAR uma vez ou agendar retry/isolar motivo

NutritionModuleJob processa cada plano/versão isoladamente, com tentativas, lease, próxima execução, histórico e estados PENDING/PROCESSING/RETRY/PROCESSED/ALREADY_DONE/SKIPPED/ISOLATED. O módulo só é liberado com plano ativo, vigência pela data local de Brasília e vínculo canônico profissional-aluno; ambiguidades falham fechado. Erro de um item não trava toda a fila, e uma liberação concluída não é repetida. Calendário/dias de dieta têm persistência própria; presença de código não prova correção de todos os bugs de visibilidade.

Fonte / evidência: base44/shared/nutritionModuleGrant.js; nutritionModuleQueue.js; NutritionModuleJob; processarLiberacaoNutricao

ANEXAR privado

EXTRAIR lote e validar origem

REVISÃO somente leitura READY

GERAR job durável; consultar resultado e compensação conforme estado

O fluxo único aceita PDF, JPG/JPEG, PNG, CSV, XLSX, JSON e HTML, até 10 MB por arquivo; anexos novos ficam privados e somente referências são persistidas. Extração transcreve dados, preserva zero/unidades/referências/origem e deduplica somente igualdade exata; revisão é somente leitura, sem entrada manual. Um lote novo não reextrai os anteriores. READY é exigido por aviso, não botão morto. A geração reutiliza extraídos e o pipeline durável já existente: cobrança confirmada, worker/fallback, persistência e compensação idempotente; não executar análise clínica paga para validar documentação.

Fonte / evidência: AUDITORIA_FLUXO_UNICO_EXAMES_2026_10_03.md; labWorker.js; labFinance.js; LabAnalysisJob

VALIDAR relatório e relação com aluno

RESOLVER autor nativo da avaliação

COMPARTILHAR conteúdo autorizado

PRESERVAR autoria e histórico

REPORT_SHARE_NATIVE_AUTHOR_V1 preserva a identidade do profissional autor da avaliação no envio, evitando substituir pelo operador ou perfil histórico arbitrário. Relatórios do aluno são consultados/liberados sob autorização e armazenamento privados; comparação de reavaliações e métricas usa as fontes persistidas, com resolvedores de peso/altura quando aplicáveis. Impressão isolada mantém conteúdo e blocos, sem declarar todos os formatos/PDFs homologados. A validação com alunos e alguns relatos de comparação/abertura continuam pendentes sem evidência real.

Fonte / evidência: src/components/relatorio/AprovarEnviarRelatorio.jsx; buscarRelatoriosMedicosAluno; ComparativoAvaliacoes

SALVAR feedback

ENVIAR ao suporte com chave estável

ACCEPTED? arquivar somente fila admin; FALHA: manter pendente

RETOMAR sem duplicar

enviarFeedbackAluno e o caminho legado reutilizam supportFeedbackEmail para encaminhar bugs/sugestões ao destino fixo suporte@synviahub.com, com descrição, contexto, evidências assinadas e mensagens já presentes. Cada criação de sugestão também dispara workflow imediato. Só após ACCEPTED a sugestão ganha encaminhada_email=true/data e sai da consulta administrativa; o histórico do autor não é apagado. A rotina de cinco minutos retoma pendentes sem repetir aceitos. Auditoria de 13/10: 39 existentes, 39 encaminhadas, zero pendentes; fotografia, não promessa para novos envios.

Fonte / evidência: base44/shared/supportFeedbackEmail.js; archiveSuggestionSupport.js; encaminharSugestoesSuporte; SugestaoMelhoria

RESERVAR chave e lease

TENTAR transporte configurado

PERSISTIR estado e hash

ACEITAÇÃO não equivale a entrega na caixa nem leitura

SupportFeedbackDelivery separa SENDING, ACCEPTED e FAILED, com lease_token, provider, provider_id, accepted_at e content_sha256; a concorrência evita reenvio pela mesma chave. O helper tenta Brevo e possui fallback Core.SendEmail; portanto a frase histórica todo e-mail exclusivamente Brevo não descreve este caminho atual. O lote observado foi aceito por plataforma ou já tinha recibo aceito. Aceitação não é confirmação de chegada, leitura ou resolução; resultado incerto não deve gerar sucesso fictício.

Fonte / evidência: base44/shared/enviarEmailSynvia.js; SupportFeedbackDelivery; SUGGESTION_EMAIL_TRANSFER_AUDIT_2026_10_13.md

PERFIL elegível e antispam

CHECKPOINT por ciclo

NOTIFICAR canais verificados

AUDITAR/revisar incerteza; Telegram valida vínculo e direito

O acompanhamento de profissionais ativos verifica três dias sem formulário recente, janela antispam de três dias e no máximo três tentativas por item/ciclo, com checkpoints e estados separados de app/Telegram. Resultado de entrega desconhecido exige revisão, não reenvio cego. A automação de inércia pode estar pausada: configuração de código não garante execução. O vínculo Telegram usa desafio e elegibilidade server-side, não username isolado; remoção/entrada de membros deve preservar comprovação de titularidade e direito histórico.

Fonte / evidência: base44/shared/inertiaFollowupPolicy.js; inertiaFollowupItem.js; telegramMembershipControl.js; TelegramMemberBinding

INSPECIONAR fontes

REGISTRAR nível real de prova

ATUALIZAR documentos e validar PDF

PROPRIETÁRIO publica; homologação exige evidência própria

As fontes citadas registram inspeção, testes sintéticos, consultas reais ou build conforme cada entrega; nenhum deles sozinho prova navegação em aparelhos, solução de incidente, publicação ou homologação. Esta atualização altera somente documentos e geração dos dois PDFs, com conteúdo novo em PT/EN/ES/FR e páginas responsivas existentes. O proprietário publica o frontend; geração estrutural do PDF, integridade/contagem do anexo, hash e URL são separados de teste visual e entrega final. Regras comerciais, contratos, autenticação e motores clínicos não são modificados por esta consolidação.

Fonte / evidência: Auditorias citadas; gerarChecklistV2Pdf; gerarPseudoCodigoPdf; documentPdf112.js

Pseudocódigo

CODE LOCK soberano: toda correção exige autorização explícita, atual e específica do proprietário. Este adendo não autoriza mudanças em autenticação, segurança, bloqueios, permissões, planos ou direitos históricos.
HH:00: coleta Gmail e conciliação da fila. HH:30: leitura da fonte integral e conferência canônica para preparar investigação técnica. A rotina não executa uma sessão externa de ChatGPT nem tem acesso autônomo à edição do código, build, publicação ou navegador autenticado.
Investigar incidentes novos e acompanhamentos materiais: ler integralmente; deduplicar mensagem e incidente; confrontar histórico, estado atual, dados canônicos, backend, logs, permissões e código. Alegação não é prova.
Bug confirmado: prioridade imediata de correção no escopo especificamente autorizado. Sem autorização ou acesso técnico, registrar bloqueio concreto e próxima decisão, sem fingir correção.
Separar não testado, inspeção estática, backend verificado, build aprovado, publicado e homologado. Exigir reprodução, teste, reteste, build, publicação e funcionamento real comprovados. Referências atestadas pelo proprietário não executam os testes.
Baixa como resolvido e arquivamento após testes, retestes, auditoria, validação real da correção publicada e comprovante de envio ao profissional. Confirmação ou agradecimento são opcionais; silêncio não bloqueia a baixa. Aceitação pelo provedor não prova leitura. Impedir reenvio; envio incerto requer conciliação. Sem novidade relevante, não notificar.
Instruções oficiais: botão vermelho duas vezes; botão verde uma vez, aguardar e pressionar novamente; novo login e código quando exigido. Guia: https://synviahub.com/?guia=login.
Não reabrir resolvidos sem evidência nova. Pedro Inocencio: informado resolvido em 08/10/2026. Fabio Wagner: múltiplos perfis versus exigência de unicidade demandam investigação da tentativa; não excluir perfis nem enfraquecer autorização automaticamente.
Auditar autor, data/hora, origem, contagens, ID/status do ticket, ação, autorização, evidências, testes, build, publicação/checkpoint comprovados, comunicação e bloqueios. Conteúdo normativo não equivale a deploy ou homologação.

Sempre que regra histórica V9.x ou V10.0–V10.11 conflitar com regra explícita da V10.12, prevalece exclusivamente a V10.12.
Trechos substituídos só podem permanecer como [HISTÓRICO — REVOGADO PELA V10.12]. Nenhum agente, desenvolvedor ou rotina pode executá-los como requisito atual.
POLÍTICA DOCUMENTAL ≠ prova de implementação. Autenticação identifica QUEM É VOCÊ; entitlement define O QUE VOCÊ PODE FAZER.

RECEBER candidato PELO link de indicação OU candidatura espontânea
SE candidatura espontânea ENTÃO indicador ← rede da casa (P1: Rodrigo Baladán)
EXIGIR 6 dados: nome, e-mail, CPF, nascimento, telefone, CREF
EXIGIR Instagram + foto do CREF + selfie ao vivo
SE algum obrigatório vazio ENTÃO recusar envio E avisar campo exato
hash_integridade ← HASH(CPF + e-mail + telefone + nascimento + CREF)
SE existe ficha COM mesmo hash OU e-mail OU CPF OU CREF OU (telefone + nome)
   ENTÃO recusar candidatura (validação única) E encerrar
GRAVAR candidato COM status = "pendente"
GRAVAR lead no Painel do Admin COM origem rastreada (site OU indicador)
ENVIAR ficha completa + link do Dossiê Web PARA suporte@synviahub.com

ABRIR dossiê; SE vetado, comunicar motivo e arquivar
SE aprovado: provisionar identidade NATIVA Base44 no e-mail aprovado e vincular PerfilProfissional
GERAR código individual, cupom e elementos comerciais permitidos; nunca gerar senha
ENVIAR e-mail oficial SYNVIA: candidatura aprovada, conta pronta para ativação
MENSAGEM: Sua candidatura ao SYNVIA HUB foi aprovada. Sua conta está pronta para ativação. Clique no botão abaixo para ativar seu acesso e criar sua senha com segurança.
BOTÃO: ATIVAR MINHA CONTA → fluxo nativo de convite/ativação da plataforma
E-mail oficial pode conter nome, código, cupom, janela e links permitidos; NUNCA senha
Convite nativo da plataforma é necessário para definir acesso; NÃO orientar ignorá-lo
Código profissional reservado nasce inativo para indicação; Joia liga o direito de indicar
SYNVIA não cria, conhece, envia, armazena ou sincroniza segunda senha; não autentica por CredencialProfissional

QUANDO o profissional ABRIR o e-mail PELA PRIMEIRA VEZ
   SE cupom_aberto_em está vazio ENTÃO
      cupom_aberto_em ← agora  (imutável)
      cupom_expira ← agora + 24 horas
AO clicar no botão roxo: e-mail e cupom viajam no link (?email=…&cupom=…)
NÃO pedir formulário, e-mail ou código — reconhecimento automático
IGNORAR relógio do navegador: recarregar, limpar cache, trocar navegador,
   usar outro aparelho ou abrir aba anônima NÃO reinicia o prazo (o prazo vive no servidor)
SE cupom pertence AO e-mail E está no prazo E nunca usado ENTÃO
   preço ← R$ 2.500  E  links_de_aluno ← 10
SENÃO (perdeu as 24 horas)
   preço ← R$ 3.000  E  links_de_aluno ← 0  (perde o desconto E perde os links)
APLICAR desconto NO SERVIDOR (campo livre de cupom desligado)
PERMITIR que ele visite o Dashboard Espelho dentro das 24h SEM consumir a oferta

CÓDIGO DE INDICAÇÃO É OBRIGATÓRIO — NUNCA OPCIONAL:
   SE link não trouxe código ENTÃO buscar indicador NA ficha do candidato
   SE ainda sem código ENTÃO recusar (400) E avisar: ninguém entra sem padrinho
   SE código não existe OU está inativo ENTÃO recusar (403) E registrar auditoria
VALE NOS DOIS MODOS: consulta de preço E criação da sessão de pagamento
SEM código válido NÃO existe sessão Stripe (nem por chamada direta à API)
NA TELA: rótulo "Código de indicação (obrigatório)" E botão travado sem e-mail + código
CRIAR sessão Stripe COM cartão salvo para renovação anual
AO pagamento aprovado (webhook confirmarJoiaElite)
   MARCAR joia como paga E promover conta PARA Membro Elite
   GERAR os links individuais de aluno (10 com cupom / ZERO sem cupom)
   CONFERIR código do padrinho NA ficha (site → código da casa SYNVIA-BALADAN-0001)
   PAGAR comissão: Admin em conta PJ · membro SEMPRE em conta corrente pessoa física
   MARCAR cupom como usado
DEVOLVER profissional PARA a tela de confirmação SYNVIA
LEMBRAR: o Stripe NÃO cria senha e NÃO envia link de acesso

ATIVAR MINHA CONTA → convite/ativação nativa Base44 → usuário define sua própria senha
LOGIN PRINCIPAL ← e-mail da candidatura + senha definida pelo usuário na autenticação nativa
RESET ← somente fluxo nativo; proibidos hash próprio, senha padrão/fixa, token próprio e senha por API/suporte
Google: método alternativo pela MESMA identidade, quando suportado nativamente; não criar admin, perfil, plano ou entitlement; não presumir linking automático.
NUNCA derivar senha de nascimento, CPF, telefone, CREF, nome ou combinação previsível
HASH DE INTEGRIDADE ≠ HASH DE SENHA ≠ IDENTIDADE AUTENTICADA; conferência física não cria sessão
SE perfil incompleto: sessão válida e Conta acessível; exigir complemento somente em ações críticas
Sessão ← Base44 Auth; sessionStorage/localStorage ← UX apenas, nunca identidade ou autoridade
FUTURO (não implementado): magic link, código único, passkey, somente se suportados oficialmente

base44.auth.me() → identidade nativa → PerfilProfissional → status → plano/entitlements
SE Joia confirmada: ELITE; direitos Elite na própria carteira, comissão e rede conforme regras vigentes
SENÃO SE aluno válido/autorizado: MEMBRO COMUM; Plano START SOMENTE para CADA aluno autorizado
   UM aluno pago NÃO libera toda a carteira; qualquer outro alvo sem direito → negar
SENÃO: ONLY VIEW; sessão válida, ações críticas bloqueadas, Conta acessível
Aluno VIP do Legado conserva direito adquirido, sem novas entradas no plano Legado
Joia antes OU depois da ativação: associar pagamento à identidade aprovada existente; nunca criar outro User/senha
Link de aluno pode ser vendido antes da ativação se houver direito comercial; entitlement por aluno aguarda validação/pagamento
Elite/Legado preservam direitos; TURBO só adiciona créditos, jamais função Elite, rede, comissão ou entitlement
Mudança Only View → START → Elite altera SOMENTE permissão, nunca login ou credencial
DONO E ESCOPO: profissional nunca acessa dados de outro dono; verificar autorização por aluno no servidor

registered_devices <= 2; active_live_sessions <= 1; dois registros NÃO autorizam sessões simultâneas
Sessão autenticada deriva da Base44 Auth, nunca de sessionStorage/localStorage ou hash físico
device_id em sessionStorage apenas como identificador de aba; nenhuma exceção individual por e-mail ou user_id
Conflito de sessões: negar concorrência e auditar conforme política vigente; não afirmar revogação instantânea de token sem homologação

ANTES DE QUALQUER gravação (aluno, treino, dieta, avaliação, laudo, IA):
   SE não autenticado ENTÃO recusar
   SE admin ENTÃO liberar
   SE mais de 20 gravações no último minuto ENTÃO recusar (ritmo humano)
   SE existe penalidade ativa de compartilhamento ENTÃO recusar
   SE 6 dados não revalidados ENTÃO recusar
   SE nível = "Only View" ENTÃO recusar E registrar tentativa
   SENÃO gravar E registrar auditoria

PARA CADA registro clínico (avaliação, treino, dieta, fisio, laudo):
   PERMITIR ler/editar/apagar SOMENTE SE
      identidade interna do criador = usuário atual  (âncora imutável)
      OU e-mail do criador = usuário atual
      OU e-mail do profissional dono = usuário atual
      OU e-mail do cliente vinculado = usuário atual (apenas o que é dele)
      OU usuário é admin
NUNCA permitir que um profissional veja o trabalho de outro profissional
SE tentar abrir registro alheio pelo endereço direto ENTÃO devolver vazio

SE direito comercial autoriza link/venda, não exigir aprovação Stripe Connect para existir o link
Membro Comum: comissão ZERO, rede NENHUMA, não precisa Connect para comissão inexistente
Elite/Legado com comissão: registrar a receber; sem conta Connect aprovada NÃO transferir
Connect controla recebimento/payout, não autenticação nem venda; respeitar carência aplicável
Cupom: janela promocional 24 horas conforme regra vigente; cobrança e nota fiscal pela empresa

FUNÇÃO validarContaRecebimento(membro):
   SE membro É admin/dono ENTÃO devolver LIBERADO (conta PJ da casa já é a Stripe do SYNVIA)
   SE tipo_conta = PESSOA_JURÍDICA ENTÃO RECUSAR ("apenas conta de pessoa física")
   SE nome_titular ≠ nome_completo_da_ficha ENTÃO RECUSAR
   SE cpf_titular ≠ cpf_da_ficha ENTÃO RECUSAR ("nem mãe, nem pai, nem cônjuge, nem sócio")
   SE conta_conjunta E cpf_do_membro NÃO É titular ENTÃO RECUSAR
   SE banco/agência/conta/dígito inválidos ENTÃO RECUSAR
   SE cpf_da_ficha JÁ possui outra conta de recebimento ENTÃO RECUSAR E alertar CyberGuardian
   SE Stripe pede documento/selfie/comprovante ENTÃO manter somente PAYOUT pendente até regularizar
   SE details_submitted E payouts_enabled ENTÃO devolver PAYOUT_LIBERADO
   SENÃO devolver AGUARDANDO (o prazo é da Stripe — minutos a horas; SYNVIA não antecipa)
TROCA DE CONTA → nova verificação Stripe; links permanecem, repasses aguardam aprovação
NUNCA repassar comissão por Pix avulso, por transferência manual ou para conta de terceiro

MEMBRO COMUM: comissão ← 0% · rede ← NENHUMA · créditos próprios ← 0
MEMBRO ELITE (pagou a Joia) ← vira P1 · pode indicar · tem rede de 5 níveis
O P1 RECEBE DE TODOS ABAIXO DELE:
   nível 2 ← R$ 5 · nível 3 ← R$ 4 · nível 4 ← R$ 3 · nível 5 ← R$ 2
P2, P3 e P4 NÃO recebem da rede do P1 — cada um monta a SUA própria rede de 5 níveis
JOIA ELITE — DUAS FAIXAS:
   SE dentro das 24h da PRIMEIRA abertura do e-mail ENTÃO preço ← R$ 2.500 E créditos ← 300/mês
   SENÃO preço ← R$ 3.000 E créditos ← 200/mês
   ⚠️ V6.0 — CORREÇÃO: links_de_aluno_gratuitos ← 10 SOMENTE dentro das 24h
   SE perdeu as 24h ENTÃO links_de_aluno_gratuitos ← 0 (NENHUM link, sem exceção)
CÓDIGO DE INDICAÇÃO (V6.0): nasce na aprovação COM pode_indicar ← FALSO
   AO confirmar a Joia paga na Stripe ENTÃO pode_indicar ← VERDADEIRO (mesmo código)
   REGISTRAR auditoria da liberação (quem, quando, qual sessão Stripe)
SACAR ≠ INDICAR (V6.0):
   SE joia paga ENTÃO liberar indicar, vender e montar a rede de 5 níveis
   SE conta PF NÃO aprovada na Stripe ENTÃO
      MOSTRAR o valor no painel SYNVIA como "a receber" E NÃO criar transferência
      MANTER o dinheiro no saldo Stripe do SYNVIA até a conta ser regularizada
BOLSO DO ALUNO START (Membro Comum) ← 12 créditos/mês; Elite/Legado conforme direito vigente
BOLSO DO PROFISSIONAL ← Joia + TURBO; só alunos próprios COM direito, nunca cria entitlement
ANTES DE QUALQUER geração de Inteligência Suprema:
   SE bolso do aluno tem saldo ENTÃO debitar do aluno
   SENÃO SE bolso do profissional tem saldo ENTÃO debitar do profissional
   SENÃO bloquear a geração E liberar apenas prescrição manual
AVISAR o profissional em 50%, 80% e 100% do consumo (ninguém é pego de surpresa)
MEMBRO ELITE ← PASSE LIVRE (nenhum corte de funções se aplica a ele)
CORTES E LIMITES DE FUNÇÕES ← valem SOMENTE para o Membro Comum
PACOTES TURBO (anual, à vista, LIBERADOS PARA TODOS — Elite E Comum):
   TURBO 100 ← R$ 1.500/ano (+100 créditos/mês)
   TURBO 200 ← R$ 2.500/ano (+200 créditos/mês)
   TURBO 300 ← R$ 3.500/ano (+300 créditos/mês)
PREÇO DO ALUNO ← R$ 29,90/mês PROMOCIONAL por tempo indeterminado, reajustável pela empresa
   AVISAR assinantes ativos COM 30 dias de antecedência de qualquer reajuste
AO gerar comissão: liberado_em ← data do pagamento + 30 dias
NUNCA repassar comissão antes da carência de 30 dias (antifraude E proteção do profissional)
AO aprovar profissional: EXIGIR assinatura por certificado digital OU gov.br
AO liberar aluno: EXIGIR aceite eletrônico COM data, IP e hash (MP 2.200-2/2001)
SEM aceite ou assinatura NÃO existe acesso
APÓS 7 dias do pagamento: reembolso da Joia ← NENHUM (saída = perda integral do ciclo)
AO detectar fraude (burla, mentira, aluno falso, documento falso, invasão, conta compartilhada):
   perder TUDO (Joia, créditos, comissões pendentes e links)
   expulsar definitivamente do SYNVIA HUB
   estornar integralmente as comissões do período da fraude
   acionar o jurídico do SYNVIA HUB nas esferas civil E criminal
COMISSÃO sobre aluno cancelado em menos de 30 dias ← estorno no ciclo seguinte
TRIBUTOS sobre a comissão ← responsabilidade EXCLUSIVA do membro
TODA simulação de ganho ← ILUSTRATIVA (o SYNVIA HUB NÃO promete renda)

EM TODO checkout Stripe: EXIGIR CPF ou CNPJ do pagador E endereço de cobrança
SE pagador sem CPF/CNPJ ENTÃO não existe nota fiscal válida — logo, não existe checkout
APLICADO em 9 checkouts E comprovado com sessão real aprovada pela Stripe
NENHUM e-mail de teste participa de fluxo fiscal ou administrativo
   (8 endereços fantasma removidos das funções fiscais e de admin)
PROMOVER a admin: SOMENTE pelo e-mail oficial do dono (segunda porta fechada)
SE existe conta admin não autorizada ENTÃO rebaixar automaticamente E avisar o Mestre
ENVIAR e-mail: SOMENTE pelo Brevo, no domínio verificado synviahub.com
   provedor Resend ← ERRADICADO (funções, campanhas, auditorias e chave do cofre)
EMITIR NFS-e: SOMENTE pelo microserviço próprio do SYNVIA (NFE.io removido)
XML do DPS Nacional ← CONGELADO enquanto o retorno da prefeitura for Sucesso
ENTREGAR nota: PDF e XML por LINK SEGURO no e-mail, NUNCA como anexo
WEBHOOK de pagamento ← UM ÚNICO (stripeWebhook) · handler duplicado eliminado
PREÇO da Joia Elite e da assinatura do aluno ← DINÂMICO, gerado no servidor
NÃO existe mais Price ID fixo para vencer, ser desativado ou quebrar um checkout
CATÁLOGO Stripe antigo ← TODO arquivado (planos e preços)
ROTAS de planos antigos (/checkout-planos, /checkout-profissional-anual)
   ← redirecionam para a home SEM mostrar erro a ninguém
LEMBRAR DAS: dia 1º (declaração liberada) E dia 18 (vencimento dia 20)
   PARA suporte@synviahub.com pelo Brevo

PRINCÍPIO: código que trata um evento NÃO funciona se a Stripe não ENVIAR esse evento.
   Tratar sem assinar o evento = silêncio absoluto (nada falha, nada acontece).
O endpoint ÚNICO (stripeWebhook) DEVE assinar, no mínimo, 7 eventos:
   checkout.session.completed ← compra aprovada (joia, aluno, plano)
   customer.subscription.created ← assinatura nasceu
   customer.subscription.updated ← assinatura mudou de status
   customer.subscription.deleted ← assinatura cancelada
   invoice.paid ← RENOVAÇÃO MENSAL DO ALUNO (dispara o split da rede de 5 níveis)
   invoice.payment_failed ← inadimplência (bloqueia o aluno)
   account.updated ← CONTA BANCÁRIA PF DO MEMBRO MUDOU DE STATUS
FALHA HISTÓRICA CORRIGIDA (10/09/2026):
   o endpoint estava assinando apenas 4 eventos
   invoice.paid NÃO estava assinado → o split da rede JAMAIS rodava em renovação
   account.updated NÃO estava assinado → o SYNVIA nunca sabia da conta aprovada
   nenhuma comissão foi perdida: havia ZERO contas Connect criadas na época
AO receber account.updated:
   SE details_submitted E payouts_enabled ENTÃO conta PF ← APROVADA
      GRAVAR connect_onboarding_completo ← VERDADEIRO no código do membro
      AVISAR o membro no sino: "Sua conta bancária foi aprovada na Stripe"
      LIBERAR a transferência das comissões (respeitada a carência de 30 dias)
   SENÃO manter SOMENTE repasses pendentes; links seguem o direito comercial
   REGISTRAR auditoria SEMPRE (status antes, status depois, requisitos pendentes)
REGRA PERMANENTE: ao criar handler de evento novo, ASSINAR o evento na Stripe no MESMO dia.
AUDITORIA OBRIGATÓRIA: conferir a lista de eventos assinados a cada mudança de fluxo de pagamento.

REGRA NOVA (10/09/2026) — VALE PARA TODA CANDIDATURA DAQUI PARA A FRENTE:
EXIGIR, ALÉM do número do CREF, o PDF ORIGINAL da CERTIDÃO DE REGULARIDADE PROFISSIONAL
   extraída do próprio site do conselho (CREF)
MOTIVO: número de CREF pode ser inventado, copiado ou estar suspenso/cancelado.
   A certidão é o único documento que prova que o profissional está REGULAR HOJE.
CAMPO OBRIGATÓRIO EM TRÊS CAMADAS (não existe porta lateral):
   1) tela: botão de envio + arrastar-e-soltar, aceita SOMENTE PDF, e a caixa fica vermelha se faltar
   2) servidor: cadastro recusado (400) SE certidao_regularidade_url estiver vazia
   3) banco: certidao_regularidade_url É campo obrigatório da ficha do candidato
ENTREGAR a certidão ao Mestre em DOIS lugares:
   no e-mail do suporte ← botão verde "ABRIR CERTIDÃO DE REGULARIDADE PROFISSIONAL"
   no Dossiê Web ← mesmo botão, acima de APROVAR/VETAR
SE a ficha não tiver certidão (ficha histórica) ENTÃO exibir alerta vermelho "CERTIDÃO NÃO ENVIADA"
NUNCA aprovar candidatura sem abrir e conferir a certidão
VALE nas 4 línguas do sistema, no desktop E no celular

REGRA MÃE: a prescrição do professor É SOBERANA. Nenhum automatismo a reescreve.
AO montar a sessão de força, LER a configuração de forma do microciclo:
   SE forma = "volume" ENTÃO carga ← FIXA E apenas repetições progridem
   SE forma = "intensidade" ENTÃO repetições ← FIXAS E apenas carga progride
   SE forma = "volume_intensidade" ENTÃO progredir AS DUAS variáveis
A variável travada NUNCA é recalculada — nem pela onda, nem pelo reescritor de VTT
MATVEEV: ONDA COMO REFERÊNCIA %Tn (Teste 2 usa %1RM real do teste):
   Tn100 ← (carga do Teste 2 × reps até a falha) ÷ (%1RM real do teste ÷ 100)
   %Tn real vem de carga × reps; %1RM define intensidade da carga
   PRESERVAR prescrições manuais e mostrar %Tn REAL na tela e no PDF
TETO ABSOLUTO: nenhum cálculo do motor passa de 100% de 1RM
PARIDADE TELA ↔ PDF: o PDF mostra EXATAMENTE o que a tela mostra (a tela é a verdade)
TRAVA DOCUMENTAL (12/09/2026): regras de percentuais CONGELADAS em documento de lock interno
SEM autorização explícita e atual do dono, NENHUMA dessas regras é alterada

MÍDIAS MP4 PREMIUM — IMPORTAÇÃO E NOMEAÇÃO:
PARA CADA vídeo da pasta do Google Drive:
   SE o identificador do arquivo JÁ existe na Galeria ENTÃO pular (idempotência)
   SENÃO baixar o vídeo E enviar para a Inteligência Suprema ASSISTIR
      GRAVAR nome técnico em português E em inglês
      GRAVAR grupo muscular, equipamento e tags de busca
      GRAVAR o identificador do arquivo do Drive no registro (nunca duplica)
PROCESSAR em lotes de 2 vídeos por vez (proteção de memória do servidor)
NUNCA adivinhar o exercício pelo nome do arquivo

CORTE DOS 2 SEGUNDOS FINAIS (regra permanente):
AO exibir QUALQUER mídia de exercício:
   SE a mídia termina em .mp4, .webm ou .mov ENTÃO usar o player premium
      AO atingir (duração − 2 segundos): reiniciar (em laço) OU pausar (com controles)
   SENÃO exibir como imagem (GIF comum)
RESULTADO: a logomarca de terceiros NUNCA aparece ao profissional nem ao aluno
O ARQUIVO no armazenamento NÃO é alterado — o corte acontece na reprodução
VALE, SEM FURO, em: miniatura da Galeria · modal do exercício da Galeria ·
   aba GIF do exercício · Galeria Pessoal do profissional ·
   demonstração do exercício dentro do treino do aluno
AUDITORIA (13/09/2026): 1.749 MP4 premium conferidos — ZERO sem nome PT,
   ZERO sem nome EN, ZERO sem equipamento, ZERO duplicado
VALE nas 4 línguas do sistema, no desktop E no celular

REGRA MÃE: SEM ACEITE NÃO EXISTE ENTRADA — nem candidatura, nem assinatura de aluno.

CONTRATO DO PROFISSIONAL (na ficha de candidatura):
EXIBIR o contrato na TELA para leitura (nunca em PDF, nunca em download)
BLOQUEAR impressão, cópia, seleção de texto, arrastar e menu de contexto
MOTIVO: o candidato ainda NÃO é cliente do SYNVIA — ele lê na tela e marca a caixa
SE contrato_aceito ≠ verdadeiro ENTÃO recusar cadastro (400) E não criar ficha

CONTRATO DO ALUNO (antes do pagamento) — NOVO NA V10.1:
DECLARAR: o SYNVIA HUB TECNOLOGIA EM SAÚDE E FITNESS LTDA é EMPRESA DE TECNOLOGIA
   e apenas a PONTE entre o aluno e o profissional (não é academia, clínica nem empregadora)
DECLARAR: treino, carga, dieta, reabilitação e conduta ← responsabilidade EXCLUSIVA do profissional
DECLARAR: cálculos e protocolos ← já dominados pelo profissional e públicos na literatura científica
DECLARAR: não é serviço médico · risco inerente ao exercício assumido pelo aluno
DECLARAR (STRIPE): pagamento processado EXCLUSIVAMENTE pela Stripe (instituição independente)
   o SYNVIA NÃO captura, NÃO armazena e NÃO acessa o número do cartão
   falha, recusa, atraso, bloqueio antifraude, estorno ou indisponibilidade ← da Stripe/banco
   honorários combinados com o personal ← relação SEPARADA, faturada por ele, fora da plataforma
   nota fiscal do SYNVIA ← somente da assinatura do software
DECLARAR: recorrência mensal automática · cancelamento no fim do ciclo pago · 7 dias de arrependimento
DECLARAR (LGPD): profissional ← CONTROLADOR dos dados de saúde · SYNVIA ← OPERADOR
DECLARAR (TETO): responsabilidade total do SYNVIA HUB, sócios, administradores e de RODRIGO BALADÁN
   ← limitada ao valor pago pelo aluno à plataforma nos últimos 3 meses

TRAVA E PROVA (servidor, nunca a tela):
ANTES de criar a sessão Stripe do aluno:
   SE contrato_aceito ≠ verdadeiro ENTÃO recusar (400) E NÃO criar sessão de pagamento
   contrato_ip ← endereço de rede da requisição
   contrato_aceito_em ← agora
   contrato_hash ← HASH(CPF + e-mail + nome + versão do contrato + data/hora)
   GRAVAR versão, data/hora, IP, navegador e hash no log de auditoria
AO confirmar o pagamento: GRAVAR a prova do aceite na assinatura do aluno (imutável)
ENTREGAR a prova ao Mestre: aceite do profissional NO DOSSIÊ (painel admin + página do suporte)
   COM versão, data/hora, IP e hash · aceite do aluno NO registro da assinatura
VALIDADE JURÍDICA: aceite eletrônico registrado conforme a MP 2.200-2/2001
VALE nas 4 línguas do sistema, no desktop E no celular

NA FICHA DE CANDIDATURA, EXIGIR (no lugar do campo único "CREF"):
   profissao ← Educação Física | Nutrição | Fisioterapia | Terapia Ocupacional | Medicina | Outra
   conselho ← preenchido AUTOMATICAMENTE pela profissão (CREF, CRN, CREFITO, CRM)
   SE profissao = "outra" ENTÃO pedir a sigla do conselho ao candidato
   registro_numero ← somente o número (sem sigla, sem UF)
   registro_uf ← UF/jurisdição do registro
GRAVAR cref ← CONSELHO + NÚMERO + "/" + UF (compatibilidade com as fichas históricas)

TRÊS DECLARAÇÕES EXPRESSAS — TODAS OBRIGATÓRIAS:
   d1 ← inscrição ATIVA, REGULAR e APTA + documentos autênticos, próprios e vigentes
   d2 ← atuação EXCLUSIVA dentro das competências legais da própria profissão
   d3 ← prescrições e programas são responsabilidade de quem valida e assina, NÃO do SYNVIA
SE d1 E d2 E d3 não estiverem marcadas ENTÃO
   NA TELA: destacar o bloco em vermelho E avisar o que falta
   NO SERVIDOR: recusar (400) E NÃO criar a ficha (nem por chamada direta)
declaracoes_hash ← HASH(CPF + e-mail + registro + d1 + d2 + d3 + data/hora)

CONTRATOS V3.0 (profissional e aluno) SUBSTITUEM os textos anteriores
TEXTO VINCULANTE ← PORTUGUÊS, regido pela lei brasileira
NAS TELAS EM EN/ES/FR: exibir 1 linha no idioma do usuário avisando que o texto
   vinculante é o português abaixo — NUNCA apresentar tradução livre como documento aprovado
SELFIE ← conferência visual com a cédula profissional (SEM biometria, SEM reconhecimento facial)

REVALIDAÇÃO ANUAL DA REGULARIDADE (1 vez por ano):
AO confirmar pagamento da joia (primeira compra OU renovação anual):
   regularidade_revalidar_em ← data do pagamento + 366 dias
   regularidade_pendente ← FALSO
TODOS OS DIAS às 08:00 (horário de Brasília):
   PARA CADA ficha COM status aprovado OU ativo E regularidade_revalidar_em ≤ agora:
      SE já está pendente ENTÃO pular (não avisa duas vezes)
      regularidade_pendente ← VERDADEIRO E regularidade_cobrada_em ← agora
      AVISAR o profissional no sino, NO IDIOMA DELE
      REGISTRAR auditoria da cobrança
QUANDO o profissional reapresentar a certidão (aba Conta › Regularidade Profissional):
   certidao_regularidade_url ← novo PDF
   regularidade_revalidada_em ← agora
   regularidade_revalidar_em ← agora + 366 dias
   regularidade_pendente ← FALSO
   REGISTRAR auditoria (certidão anterior, certidão nova, data/hora, novo vencimento)
VALE nas 4 línguas do sistema, no desktop E no celular

REGRA MÃE: existe UM ÚNICO lugar por ambiente que define teto de créditos.
   Nenhuma tela e nenhuma função escreve limite de crédito à mão — todas LEEM da fonte única.
TABELA OFICIAL (congelada):
   trial ← 10 créditos TOTAIS · basico ← 50/mês
   profissional (LEGADO PROFISSIONAL) ← 200/mês  [direito adquirido]
   premium (LEGADO ELITE) ← 500/mês  [direito adquirido]

FUNÇÃO resolverLimiteCreditos(assinatura, plano):
   SE assinatura tem teto gravado (override > 0) ENTÃO devolver o teto gravado
   SENÃO devolver o valor do plano NA TABELA OFICIAL
   SE plano desconhecido ENTÃO devolver 10 (piso de segurança)

AO CONFIRMAR O PAGAMENTO DA JOIA (webhook confirmarJoiaElite):
   SE tipo_joia = "elite" ENTÃO
      SE usou o cupom das 24h ENTÃO teto ← 300 E origem ← "joia_elite_24h"
      SENÃO teto ← 200 E origem ← "joia_elite_padrao"
      BUSCAR a assinatura do profissional (por criador E por e-mail, priorizando a ATIVA)
      SE encontrou ENTÃO ATUALIZAR: plano ← premium · status ← ativa · periodicidade ← anual · teto · origem
      SENÃO CRIAR assinatura nova COM os mesmos dados + data de renovação anual
      REGISTRAR auditoria (assinatura alterada, teto aplicado, origem)
   SE tipo_joia = "legado" ENTÃO NÃO TOCAR em crédito nenhum (200 / 500 congelados)
   SE a gravação falhar ENTÃO registrar o erro E NÃO derrubar a confirmação do pagamento

FALHA HISTÓRICA CORRIGIDA (17/09/2026):
   o webhook NÃO gravava teto de crédito — o novo Membro Elite ficava com o limite do plano antigo
ANTES DE CADA COBRANÇA DE INTELIGÊNCIA SUPREMA:
   limite ← resolverLimiteCreditos(assinatura, plano)   (owner segue com bypass total)
   O cartão "Seu Plano Atual" MOSTRA esse mesmo limite — tela e motor nunca divergem

TESTE DE MESA EXECUTADO (17/09/2026) no banco de TESTE:
   assinatura fictícia COM cupom → gravou 300 · SEM cupom → gravou 200 · Legado Elite → intacta em 500
   os 3 registros fictícios foram APAGADOS após a conferência
   NADA foi criado em Produção e NENHUM pagamento real foi disparado
VALE nas 4 línguas do sistema, no desktop E no celular

REGRA MÃE: MEMBRO ELITE ← PASSE LIVRE. MEMBRO LEGADO ← direito adquirido.
   O PLANO START vale SOMENTE para o aluno de R$ 29,90 do MEMBRO COMUM.
FONTE ÚNICA: a lista de bloqueios e as cotas vivem em UM lugar por ambiente.

BLOQUEADO PARA SEMPRE (visível na tela COM selo 🔒 ELITE, nunca executável):
   dexa · postural · postural_total · baladan_brain · medicina · fisioterapia
   ressonancia · exames_imagem · analise_sanguinea · analise_laboratorial
   cardio_grupos_especiais · cardio_atletas · cardio_corrida_rua · relatorios_avancados

COTA MENSAL — 1 (UMA) VEZ POR MÊS CADA:
   periodizacao_forca ← 1 por mês · 4 créditos
   periodizacao_cardio ← 1 por mês · 3 créditos
   plano_nutricional ← 1 por mês · 5 créditos
   TOTAL DO PACOTE ← 12 créditos/mês
BOLSO DO ALUNO ← 12 créditos/mês (era 35; ajustado para o tamanho exato do pacote)

LIVRE E ILIMITADO (custo ZERO de crédito):
   avaliacao_simples · antropometria · dobras_cutaneas · composicao_corporal
   biblioteca_exercicios · prescricao_manual · planilha_aluno · execucao_sessao
   agenda · chat · metas_manuais

ANTES DE EXECUTAR QUALQUER FUNÇÃO PARA O ALUNO:
   SE membro é ELITE ou LEGADO ou admin ENTÃO manter trava por dono e direito por aluno; dispensar apenas corte START
   SE startBloqueia(funcao) ENTÃO NÃO executar E abrir o carimbo 🔒 ELITE
   SE startCota(funcao) existe E já foi usada neste mês ENTÃO NÃO executar E abrir o carimbo
   SENÃO debitar os créditos da função E executar

CARIMBOS PSICOLÓGICOS (autorizados em 17/09/2026):
   NUNCA esconder a função trancada — MOSTRAR e NEGAR (a dor é o produto)
   AO tocar na função trancada: nomear o que o ELITE tem e ele não
      + Joia pode dar direitos Elite; TURBO só créditos para funções já permitidas
   ESPELHO DA REDE (painel de comissões do Membro Comum):
      comissão exibida ← R$ 0,00 RISCADO
      frase 1 ← "cada aluno seu paga R$ 29,90 e 100% vai para o SYNVIA"
      frase 2 ← "R$ 11,96 de CADA aluno seu (40%) poderia estar caindo no seu bolso"
      TABELA (simulação oficial do site: cada profissional indica 5) COM APENAS 4 ALUNOS CADA:
         P1 · 1 prof · 4 alunos · R$ 11,96 → R$ 47,84
         P2 · 5 prof · 20 alunos · R$ 5,00 → R$ 100,00
         P3 · 25 prof · 100 alunos · R$ 4,00 → R$ 400,00
         P4 · 125 prof · 500 alunos · R$ 3,00 → R$ 1.500,00
         P5 · 625 prof · 2.500 alunos · R$ 2,00 → R$ 5.000,00
         TOTAL ← 781 profissionais · 3.124 alunos · R$ 7.047,84 POR MÊS
      EXIBIR cada linha RISCADA (ele vê o valor e não recebe nada)
      facada ← "você deixaria de ganhar R$ 7.047,84 POR MÊS, sem dar uma aula a mais"
      motivo ← "você não recebe porque não é Membro Elite. É o único motivo."

CONTA QUE FECHA (por aluno, com padrinho fundador e imposto de 6%):
   29,90 − 5,00 (nível 2) − 1,49 (Stripe) − 6,00 (12 créditos) − 1,79 (imposto) = R$ 15,62
   SEM padrinho fundador ← R$ 20,62
VALE nas 4 línguas do sistema, no desktop E no celular

REGRA MÃE: TURBO é COMBUSTÍVEL, NÃO é CHAVE. Ele soma créditos e NÃO abre nada.
AO Membro Comum escolher qualquer TURBO (100, 200 ou 300):
   ABRIR aviso em tela cheia, em letras grandes, ANTES de qualquer sessão de pagamento
   LISTAR em bloco vermelho O QUE O TURBO NÃO FAZ:
      NÃO destrava as 14 abas ELITE (todas seguem com o selo 🔒 depois da compra)
      NÃO dá comissão · NÃO dá rede de 5 níveis · NÃO permite indicar ninguém
      NÃO dá os 10 links individuais de aluno
      NÃO vira Membro Elite · NÃO dá acesso à Stripe · NÃO permite saque
   LISTAR em bloco verde O QUE O TURBO FAZ:
      SOMA créditos mensais ao que ele JÁ tem liberado (12 créditos/mês do Plano Start)
      SERVE para usar MAIS o que já está aberto — nunca para abrir o que está trancado
      COBRANÇA anual, à vista, em uma única parcela
   DECLARAR: único caminho para as 14 abas e para dinheiro ← JOIA ELITE (não existe outro)
   DECLARAR: após 7 dias (CDC) NÃO há reembolso, NÃO há conversão e NÃO há troca pela Joia
CAIXA DE ACEITE OBRIGATÓRIA (padrão Adobe):
   aceite ← FALSO por padrão
   SE aceite = FALSO ENTÃO botão de avançar ao pagamento ← DESABILITADO
      E avisar em vermelho: "Marque a caixa acima para poder avançar para o pagamento"
   SOMENTE com aceite = VERDADEIRO o profissional segue para o pagamento
OFERECER, na mesma tela, a saída honesta: "Prefiro a Joia Elite (abre tudo e paga comissão)"
VALE nas 4 línguas do sistema, no desktop E no celular

1. TESTING AGENT PROIBIDO — O Testing Agent não faz parte do fluxo oficial de homologação do SYNVIA HUB.
É proibido: recomendar Testing Agent; executar Testing Agent; utilizar resultado do Testing Agent como evidência; substituir sessão real por Testing Agent; bloquear entrega aguardando Testing Agent.
Métodos oficiais permitidos: testes backend seguros; consultas reais ao banco; reconciliação independente; inspeção de código; testes manuais guiados; sessão autenticada real; conta QA real e controlada quando necessário.
Quando uma validação exigir interação humana, o agente deve parar e informar: 1. página; 2. conta/perfil; 3. ação; 4. resultado esperado; 5. evidência necessária.
2. REGRA DE FOCO — O agente não pode aproveitar uma tarefa para alterar áreas adjacentes. Se a tarefa é Dashboard Admin BI, trabalhar exclusivamente no Dashboard Admin BI.
Não modificar, por iniciativa própria: dashboard profissional; textos de suporte; login; Google Login; Stripe; contratos; pagamentos; motores clínicos; HTS; responsividade; traduções; segurança; banco; onboarding; funcionalidades externas ao escopo.
Problemas encontrados fora do escopo devem ser apenas registrados no backlog.
3. ORDEM ATUAL DE PRIORIDADE DO PROJETO — 1. DASHBOARD ADMIN BI SYNVIA COMPLETO; 2. AUTH-01; 3. PODER SOBERANO; 4. SEC-CLIN-01; 5. SEC-CRED-03; 6. DEMAIS ITENS TÉCNICOS DO BACKLOG; 7. FINAL GLOBAL CLOSEOUT.
Nenhuma etapa posterior deve ser antecipada enquanto o Dashboard Admin BI estiver em implementação.
4. DASHBOARD ADMIN BI — REGRA DE FOCO ATUAL — O objetivo imediato do projeto é fazer o Dashboard Admin responder ao proprietário do SYNVIA, com dados reais, exatamente o que está acontecendo no negócio.
O Dashboard deve priorizar: profissionais; alunos; entitlements; atividade; avaliações; prescrições; vendas; assinaturas; receita quando reconciliada; qualidade dos dados; segurança; suporte; saúde operacional; funil; retenção; módulos; créditos; rede; comissões.
Não deixar a implementação do Dashboard ser desviada por melhorias cosméticas ou funcionalidades externas.
COMANDO UNIVERSAL PERMANENTE — SYNVIA CODE LOCK. Você está sob o COMANDO UNIVERSAL PERMANENTE — SYNVIA CODE LOCK. Você é um agente do SYNVIA HUB no Base44.
REGRA ABSOLUTA: Você está proibido de alterar, corrigir, refatorar, apagar, mover, recriar ou otimizar qualquer linha de código, arquivo, componente, função, entidade, tradução, layout mobile, desktop ou responsivo sem autorização explícita e atual de Rodrigo Baladán.
Só execute exatamente o que estiver abaixo da frase: “CORRIJA APENAS O QUE ESTÁ ABAIXO:”.
Antes de qualquer alteração, faça: 1. Liste os arquivos que pretende tocar. 2. Liste as linhas/funções afetadas. 3. Explique o motivo. 4. Aguarde confirmação explícita: “AUTORIZO ALTERAR ESTES ITENS” ou “AUTORIZO ALTERAR APENAS ESTES ITENS”.
Sem essa confirmação, responda apenas: “Não tenho autorização para alterar código. Aguardando permissão explícita.”
É proibido: melhorar por conta própria; corrigir bugs não solicitados; alterar design não solicitado; modificar traduções; mexer em responsivo; refatorar; otimizar; criar arquivos extras; alterar lógica de login; alterar pagamento; alterar admin; alterar segurança; alterar banco; alterar qualquer funcionalidade fora do escopo atual.
A regra vale para: PT; EN; ES; FR; mobile; desktop; tablet; todas as áreas do SYNVIA HUB.
Toda ação deve gerar log contendo: autor; data; pedido; arquivos alterados; motivo; confirmação recebida.
Não inventar. Não alucinar. Não presumir resultado. Não declarar teste como aprovado sem evidência.
Se não souber: responder “não sei”. Se não lembrar: responder “não me lembro”. Se não houver evidência: responder “não há evidência suficiente”. Faça o básico bem feito.
REGISTRO DOCUMENTAL V10.12 — Autor: Base44; data: 26/09/2026; pedido: consolidar os dois documentos V10.11 em V10.12; arquivos autorizados: checklistOnboardingContent.js, pseudoCodigoSynvia.js e os dois PDFs V10.12; motivo: aprovação e ativação nativa, separação de autenticação e entitlement, correção de regras históricas; confirmação: autorização explícita no pedido V10.12. Trechos conflitantes de V9.x a V10.11 ficam REVOGADOS.

TESTE 1: estimar 1RM (máximo 15 reps digitadas; série importada preserva reps originais)
TESTE 2: receber %1RM real do teste + reps máximas até a falha por exercício
cargaTeste2 ← 1RM × (%1RM real do Teste 2 ÷ 100)
Tn100 ← (cargaTeste2 × reps máximas) ÷ (%1RM real do Teste 2 ÷ 100)
ONDA Matveev ← patamar de referência %Tn, NÃO impor reps por divisão do alvo pela carga
CALCULAR carga e reps pela base individual e pelos incrementos escolhidos pelo professor
MOSTRAR %Tn real ← carga × reps ÷ Tn100 × 100; %1RM real ← carga ÷ 1RM × 100
SOMAR VTT ← soma carga × reps de cada série, em kg·rep; manter regressão série a série
SE onda sobe dentro do microciclo E não é Recuperativo: ajustar VTT contra sessão anterior já ajustada
SE platô OU descida OU Recuperativo: NÃO forçar aumento (nem sessão 6 se onda não sobe)
FORMA volume → reps; intensidade → carga; ambas → alternância; ajuste limitado, verificar resultado
VIRADA de microciclo: semente separada, máximo +1 rep; NÃO aplicar antiga inversão
PDF usa o mesmo motor da tela; validar 4 idiomas, desktop, celular e impressão antes de aprovar

AO APROVAR: copiar somente campos validados e ausentes da candidatura para Conta/Perfil
NUNCA sobrescrever informações existentes; NÃO tocar em login, senha, Joia ou assinatura
NO ACESSO: autenticar a sessão real; admin e aluno não passam pelo bloqueio profissional
PENDÊNCIAS ← nome, telefone, WhatsApp, endereço, Instagram, CPF válido, registro e especialidade
SE pendências ≠ vazio: mostrar apenas a Conta para completar e salvar
ANTES de gravação crítica: verificar novamente NO SERVIDOR; se incompleto → recusar 403 e auditar
SE todos completos: liberar automaticamente conforme direitos da Joia/aluno pagante
NUNCA suspender por perfil incompleto, emitir avisos 1/5 ou exigir novo login/senha

Fluxograma