ModularFit: Documento de Requisitos de Software

Este documento descreve o ModularFit por inteiro: o que o sistema é, para quem serve, o que faz e o que não faz, como se comporta, como seus dados são organizados e em que ordem ele é construído. Serve a todos os envolvidos no produto, da liderança que precisa entender o que está sendo construído, ao Product Owner que acompanha a evolução, ao time de desenvolvimento que constrói cada parte e verifica o que já foi entregue. É a referência única sobre o sistema: quando houver dúvida sobre o que o ModularFit deve fazer, a resposta está aqui.

Documentos companheiros deste DRS: Roadmap de Implementação (em que ordem construir e como verificar) · Inventário de Artefatos (tudo que precisa existir e como deve ser) · Jornadas dos Atores (como cada papel opera o sistema) · Plano de Testes (o que validar antes de entregar).

Contextualização

O que é o ModularFit em 1 minuto

O ModularFit é uma plataforma de gestão síncrona de desenvolvimento físico. De um lado, o aluno, que quer treinar, comer melhor, acompanhar seus números e guardar sua vida clínica num lugar só. Do outro, os profissionais que cuidam dele: personal trainer, médico, fisioterapeuta e nutricionista. O sistema conecta os dois lados: o profissional prescreve (ficha de treino, plano alimentar, prescrição médica, sessão de reabilitação), o aluno executa e registra, e os dois enxergam a mesma evolução, em tempo real, sem trocar planilha por mensagem de aplicativo.

O ponto de virada é a sincronia: o que o aluno registra hoje aparece agora para quem o acompanha, e o que o profissional muda aparece agora para quem executa. Cada profissional é uma unidade isolada, com a sua própria carteira de alunos, e só enxerga quem está vinculado a ele.

O núcleo do produto é o treino de musculação. A ficha, a execução série a série, a carga registrada e a progressão de carga são a razão de o aluno abrir o sistema todo dia, e é por elas que o produto é julgado. Dieta, saúde clínica, reabilitação, comunicação, engajamento, cobrança e integrações são complementares: existem porque quem treina também come, se machuca, faz exame e conversa com quem o acompanha, mas nenhuma delas substitui o treino no centro. Esse foco governa três coisas ao longo deste documento: a prioridade dos requisitos, o destaque das telas e a ordem de construção.

Para quem é o sistema

• Aluno: quem treina. Usa o sistema principalmente pelo celular, com interface simples, visual e guiada por imagens.
• Personal Trainer, Médico, Fisioterapeuta e Nutricionista: profissionais autônomos que atendem alunos. Cada um tem o seu painel, com as informações da sua especialidade em primeiro plano.
• Administrador: quem opera a plataforma inteira, mantém o catálogo global de exercícios, cuida das contas, dos planos e enxerga o sistema de ponta a ponta.

O que o sistema faz

• Cria e mantém contas de aluno e de profissional, com o registro profissional validado por especialidade.
• Vincula profissional e aluno, com aceite do aluno, e permite encerrar a relação sem perder o histórico.
• Mantém um catálogo global de exercícios com imagem, vídeo e instrução de execução.
• Monta fichas de treino, executa a sessão série a série com cronômetro e registra carga, repetições e descanso.
• Acompanha dieta: refeições registradas pelo aluno, cálculo de calorias e macronutrientes, metas diárias e planos alimentares.
• Guarda a vida clínica: anamnese, avaliação física com cálculos automáticos, exames com anexo, prescrições e sessões de reabilitação.
• Mede a evolução: medidas corporais, fotos de progresso, gráficos e comparação entre períodos.
• Conversa: chat entre o aluno e cada profissional, chat entre os profissionais do mesmo aluno, grupo com menções e notificações que podem ser limpas.
• Engaja: sequência de dias, calendário de atividade, conquistas e progressão de carga.
• Gera com apoio de inteligência artificial uma proposta de treino, de plano alimentar, de explicação em linguagem simples, de mídia demonstrativa de exercício e de conteúdo do guia, sempre como prévia editável ou aprovável antes de publicar.
• Explica o próprio sistema: um guia por módulo, escrito para cada papel, acessível de dentro da aplicação.
• Registra a cobrança que o profissional combina com o aluno e a assinatura que o aluno tem na plataforma.

O que o sistema NÃO faz

• Não processa dinheiro. Não há gateway de pagamento, não há cartão, não há repasse e não há intermediação financeira. O sistema registra valores, competências e status de pagamento; quem paga e quem recebe faz isso fora da plataforma.
• Não é prontuário nem registro clínico oficial. O ModularFit é ferramenta de acompanhamento entre o aluno e quem o acompanha. O registro clínico oficial do paciente continua sendo responsabilidade do profissional de saúde, no sistema e na forma que a profissão dele exige, e a plataforma não assume essa responsabilidade nem serve de prova dela. O aviso está escrito nos termos, no cadastro do profissional, nas telas clínicas e na exportação (RF-CORE-012).
• Não emite documento com validade legal. A prescrição e o atestado registrados aqui são o registro do acompanhamento, não substituem o receituário oficial assinado pelo profissional.
• Não faz diagnóstico. A explicação em linguagem simples de um exame é apoio de leitura, nunca conduta clínica.
• Não lê os aplicativos nativos de saúde do telefone. As plataformas de saúde do aparelho só expõem dado a um aplicativo instalado nele, e o ModularFit é uma aplicação web. O que existe é a conexão automática com os serviços de atividade que têm interface em nuvem (RF-INTE-003 e RF-INTE-004), mais a importação do arquivo exportado por Apple Health e Samsung Health e o registro manual (ver ADR-011).
• Não tem camada de academia ou clínica. Não existe uma organização acima do profissional; o profissional autônomo é a própria unidade.
• Não permite anexar documento no chat. O chat aceita texto e link; arquivo entra pelas telas próprias (exame, foto de progresso).

Como ler este documento

Cada requisito funcional traz um critério de aceite (H1) no formato "Dado..., Quando..., Então..., E...". O H1 é o teste: o requisito só está pronto quando o H1 passa, e um requisito sem H1 que reprove não é requisito. As regras de negócio aparecem como RN, as decisões de arquitetura como ADR. Os apêndices carregam as fichas longas (formulários, catálogos, matrizes) que os requisitos referenciam.

1. Visão Geral do Sistema

A.1 Nome do sistema

ModularFit.

A.2 Tipo de sistema

Aplicação web multi-inquilino (SaaS), com interface responsiva e experiência do aluno desenhada primeiro para o celular. Painéis contextuais por papel, dados em tempo real e assinatura recorrente do aluno controlada pela administração.

A.3 Problema que resolve

Quem treina hoje tem a vida dividida em pedaços que não se falam: a ficha de treino num papel ou num aplicativo, a dieta no bloco de notas do nutricionista, o exame na pasta do e-mail, a evolução na memória. Quem acompanha, do outro lado, trabalha sem enxergar o que aconteceu entre uma consulta e outra. O resultado é acompanhamento cego, prescrição desatualizada e aluno que abandona porque não vê progresso.

O ModularFit resolve isso colocando aluno e profissionais no mesmo registro vivo: um lugar onde o treino executado, a refeição registrada, a medida tirada e o exame anexado alimentam a mesma linha do tempo, visível ao mesmo tempo para quem executa e para quem prescreve.

O problema central, aquele que o produto precisa resolver melhor do que qualquer outro, é o treino de musculação sem memória: ficha em papel ou em imagem no telefone, carga anotada de cabeça, progressão que ninguém consegue provar e prescrição que não acompanha o que o aluno de fato executou. Os demais problemas orbitam esse.

A.4 Público-alvo

• Aluno de musculação, de academia ou de treino autônomo, adulto, que treina com carga e quer registrar a execução, ver a progressão e, em segundo plano, acompanhar dieta, exames e evolução física. É o público central do produto e usa majoritariamente o celular.
• Profissional autônomo das quatro especialidades atendidas, que gere uma carteira própria de alunos e precisa de um painel de acompanhamento sem custo de plataforma. O Personal Trainer é o profissional de referência do produto, por ser quem prescreve o núcleo; as outras três especialidades acompanham o mesmo aluno em volta disso.
• Administração da plataforma, responsável pelo catálogo global, pelas contas e pela operação.

A.5 Premissas

1. O profissional usa a plataforma sem custo, em qualquer especialidade e em qualquer volume de alunos.
2. O aluno é quem assina a plataforma, num plano gratuito ou num plano pago.
3. A cobrança financeira da assinatura acontece fora do sistema; a administração liga e desliga o acesso manualmente.
4. Cada profissional é uma unidade isolada de dados, sem organização acima dele.
5. Todo dado de saúde tratado aqui é dado pessoal sensível e recebe tratamento específico.
6. Existe conectividade de internet no momento do uso; o sistema não opera offline.
7. O sistema opera em português do Brasil, com unidades métricas (quilograma, centímetro, quilocaloria).

A.6 Restrições e fora do escopo

Restrições

• O sistema não processa pagamento e não integra gateway financeiro, por decisão de produto e para não configurar intermediação financeira regulada (ADR-005).
• O registro profissional é validado por formato, não por consulta ao conselho de classe: não existe integração pública e estável com os conselhos das quatro especialidades (ADR-004).
• Dado sensível de saúde exige consentimento específico por categoria e não é coberto por aceite genérico de termos de uso.

Fora do escopo

• Aplicativo nativo para telefone celular publicado nas lojas.
• Leitura direta das plataformas de saúde do telefone (Apple Health e Samsung Health), que exigem aplicativo nativo instalado no aparelho. A conexão com serviços de atividade que expõem interface em nuvem está no escopo (ADR-011, RF-INTE-003 e RF-INTE-004).
• Prontuário eletrônico, registro clínico oficial e a responsabilidade profissional que vem com ele (RF-CORE-012).
• Emissão de receituário, atestado ou laudo com validade legal e assinatura digital certificada.
• Telemedicina, videochamada e agendamento de consulta.
• Marketplace de profissionais, busca pública de profissional e avaliação por nota.
• Camada organizacional de academia, clínica ou franquia acima do profissional.
• Loja de suplementos, comércio eletrônico e catálogo de produtos.

A.7 Identidade visual

Ver Apêndice: Identidade visual.

A.8 Glossário canônico

2. Atores e Jornadas

A visão detalhada de como cada papel opera o sistema, função por função, está no companheiro Jornadas dos Atores.

B.1 Atores

Convenção de leitura dos dois papéis de administração. Onde este documento escreve "Administrador" sem qualificar, a frase alcança os dois papéis, Super Administrador e Administrador. As capacidades privativas do Super Administrador são exatamente oito, fechadas e nominais, marcadas como tal na Matriz Ator por Capacidade: atribuir plano e status de acesso (RF-PLAN-002); manter o catálogo de planos e os limites operacionais (RF-PLAN-001); bloquear e desbloquear conta pela administração (RF-PAIN-009); promover ou rebaixar papel e criar conta de Administrador (RF-PAIN-009); personificar usuário, com registro (RF-CORE-014); excluir em definitivo (RF-CORE-008); e consultar a trilha de auditoria (RF-CORE-009); e manter o catálogo de parâmetros de operação (RF-PAIN-011). Além dessas oito, há uma fronteira de dado, e ela é a segunda e última diferença entre os dois papéis: o Administrador não alcança dado clínico de aluno nenhum, nem para ler, nem para escrever, e isso vale tanto para o dado classificado como para o canal que o carrega. Em quatorze capacidades, nominalmente, ele é N e o Super Administrador é T, em dois grupos. Dez por classificação, que são as categorias de saúde, nutrição e corpo: preencher anamnese, registrar avaliação física, registrar medida corporal, enviar foto de progresso, registrar exame, registrar prescrição, registrar sessão de reabilitação, registrar refeição, definir meta nutricional e criar plano alimentar. Quatro por conteúdo, que não são categorias de saúde mas transportam o dado delas em texto livre ou em medida do corpo, e por isso a negação ficaria furada sem elas: conversar com vinculado, conversar entre profissionais do mesmo aluno, conectar e desconectar serviço de atividade (e ler a atividade importada, que traz frequência cardíaca) e acionar geração assistida de treino, dieta e explicação (cuja proposta é escrita a partir do dado do aluno). Fora da fronteira ficam as preferências de treino, porque RN-001 as declara nominalmente fora das categorias sensíveis: são declaração do próprio aluno para orientar a prescrição, não registro clínico produzido por profissional. O motivo é o menor privilégio sobre dado de saúde: o suporte do dia resolve conta, vínculo, ficha e sessão de treino, e raramente precisa do dado clínico; quando precisa, o chamado sobe ao Super Administrador, que lê sob o consentimento já dado pelo titular (RF-CORE-007) ou personifica com registro (RF-CORE-014). Fora dessas oito capacidades e dessa fronteira de dez, os dois papéis fazem o mesmo. As duas listas são fechadas: capacidade privativa ou negação de dado que não esteja nelas não existe, e o requisito que a criasse teria de nomeá-la aqui primeiro.

Nota (Inspeção, gate {AUD-12}, drift 3, 2026-09-30): a derivação da linha "Manter e publicar os textos da plataforma" da matriz passa a nomear também os textos de consentimento de RF-CORE-010, além dos termos de uso e do aviso de natureza não clínica. Texto de consentimento é texto da plataforma e cai na permissão que /admin/textos já tem, então o Administrador e o Super Administrador publicam, coerente com a decisão de 15/09 de manter "textos" com o Administrador. Nenhuma capacidade nova nasce, nenhuma linha da matriz muda e as contagens (41 e 19, divergência 22) ficam inalteradas.

B.2 Sub-funções

O papel Profissional existe sempre com uma especialidade. A especialidade não muda o papel de acesso, muda três coisas: a máscara e a validação do registro profissional, o painel de entrada e quais telas clínicas aparecem em primeiro plano. Nenhuma especialidade tem permissão que outra não tenha sobre o aluno vinculado a ela.

B.3 Jornadas principais

B.4 Hierarquia de manipulação

1. Somente o Super Administrador exclui em definitivo qualquer registro do sistema.
2. Profissional e Aluno desativam ou ocultam o que é deles; nunca excluem.
3. O Profissional só alcança dados de alunos com vínculo ativo ou histórico com ele.
4. O Aluno é dono dos seus próprios dados e pode registrar tudo por conta própria, inclusive nas categorias que um profissional preencheria.
5. O Super Administrador alcança qualquer unidade e qualquer dado, e todo alcance cross-unidade fica registrado na trilha de auditoria.
6. O Administrador alcança qualquer unidade apenas no dado não clínico, com o mesmo registro de auditoria, e recebe negação nas quatorze capacidades da fronteira nomeadas em B.1, dez por classificação e quatro por conteúdo, tanto para ler quanto para escrever. Não existe papel na plataforma que leia dado clínico de aluno sem ser o titular, um profissional vinculado ou o Super Administrador.
7. O Administrador não alcança nenhuma das oito capacidades privativas do Super Administrador listadas em B.1. Criar, promover ou rebaixar um Administrador é ato do Super Administrador, e um Administrador nunca promove a si mesmo nem a outro.

B.5 Áreas por ator

B.6 Capacidades por papel

A matriz completa de capacidade por papel está no Apêndice: Matriz Ator por Capacidade.

A escada de acesso tem três degraus: Super Administrador (quem opera a plataforma), Administrador (a operação do dia) e os papéis de público (Aluno e as quatro especialidades de Profissional). A separação entre os dois primeiros é medida, não declarada: contando as capacidades de cada coluna da matriz (célula diferente de N), o Super Administrador alcança 41 e o Administrador 19, diferença de 22, que são exatamente as oito capacidades privativas de governança mais as quatorze capacidades da fronteira de dado clínico, todas nominadas em B.1 (8 mais 14 igual a 22, e 41 menos 19 igual a 22 fecha a conta pelo outro lado). Diferença de uma ou duas capacidades entre dois papéis significa dois nomes para o mesmo papel, e reprova esta escada; a contagem é exercitada pelo card TA-92 do Plano de Testes.

3. Requisitos Funcionais

C.1 Visão dos módulos

C.2 Convenções do requisito

• Código: RF-MODULO-NNN, estável, nunca renumerado.
• Prioridade: Essencial (o sistema não existe sem), Alta (o sistema fica incompleto sem), Média (o sistema fica pior sem).
• Como a prioridade é atribuída, dado o foco do produto: Essencial é reservado a duas classes, o núcleo de musculação (catálogo de exercícios, ficha, execução da sessão, descanso, retomada, histórico e progressão de carga) e a base que protege acesso e dado (core, vinc, plan, isolamento, consentimento, auditoria e armazenamento segregado do dado sensível). Os módulos complementares, dieta, saúde clínica, reabilitação, comunicação, engajamento, cobrança, integrações e guia, são Alta ou Média, o que não significa opcional: todo requisito deste documento é construído, e a prioridade governa a ordem, não o escopo.
• H1: o critério de aceite. Um requisito só está pronto quando o H1 passa.
• Falseabilidade: todo H1 reprova por fato verificável (contagem, presença, ausência, resposta negada), nunca por impressão.

C.3 Módulo core, fundação e acesso

RF-CORE-001: Autenticação por e-mail e senha

• Descrição: o usuário informa e-mail e senha, o sistema valida a credencial e emite um token de sessão assinado, com validade e renovação automática.
• Prioridade: Essencial
• Atores: Aluno, Personal Trainer, Médico, Fisioterapeuta, Nutricionista, Administrador
• Pré-condições: conta criada e com status ativo.
• Entrada: e-mail e senha.
• Saída: sessão autenticada em cookie de acesso restrito ao servidor, e redirecionamento ao painel do papel.
• H1: Dado um aluno com conta ativa e senha correta, Quando envia e-mail e senha na tela de entrada, Então recebe uma sessão válida e é levado ao painel do aluno, E uma credencial errada retorna erro de autenticação sem revelar se o e-mail existe.
• Notas: seis tentativas falhas em quinze minutos bloqueiam a conta por trinta minutos e geram registro na trilha de auditoria. Esse bloqueio automático por tentativas, temporário, é distinto do bloqueio administrativo de RF-PAIN-009, que é decisão da administração e não expira sozinho, e distinto ainda do status de acesso por plano (RF-PLAN-002). São três controles distintos, com mensagens distintas: dois negam a entrada, o bloqueio por tentativas e o bloqueio administrativo, e o terceiro, o status de acesso por plano, deixa o aluno entrar e nega a escrita, com mensagem própria. O campo usuario.status, que nega a entrada com a mensagem de conta inativa, e o campo perfil_aluno.status_acesso, que governa o acesso por plano, são campos diferentes; esta nota nomeia os dois para o usuário e o suporte não confundirem.

RF-CORE-002: Cadastro de aluno

• Descrição: qualquer pessoa cria uma conta de aluno informando nome, e-mail e senha. Os demais dados do perfil (data de nascimento, sexo, altura, telefone, foto) ficam vazios e são preenchidos depois, sem bloquear o uso.
• Prioridade: Essencial
• Atores: Aluno
• H1: Dado um visitante na tela de cadastro, Quando envia nome, e-mail válido e senha com no mínimo o tamanho vigente do parâmetro senha_minima_caracteres ({ART-CFG-01}, oito na semente), Então a conta é criada com papel de aluno, plano gratuito e status ativo, E o aluno alcança o painel com todos os campos opcionais do perfil vazios.
• Notas: e-mail já cadastrado retorna erro específico do campo. Ver RN-002, cadastro progressivo. A confirmação do e-mail registra mfit.usuario.email_confirmado_em; esta coluna não é porta de acesso, nenhuma rota, política ou tela a consulta para permitir ou negar, e a conta continua nascendo ativa (RF-CORE-005, F1-07). Subir o mínimo não invalida senha já gravada: a entrada não confere tamanho; vale para o próximo cadastro e para a próxima redefinição (RF-CORE-005).

RF-CORE-003: Cadastro de profissional com registro validado por especialidade

• Descrição: o profissional cria conta escolhendo a especialidade e informando o número do conselho de classe, validado pelo formato da especialidade escolhida.
• Prioridade: Essencial
• Atores: Personal Trainer, Médico, Fisioterapeuta, Nutricionista
• Entrada: nome, e-mail, senha, especialidade, número do registro profissional.
• H1: Dado um visitante que escolhe a especialidade Personal Trainer, Quando informa o registro 123456-G/AM, Então a conta é criada com especialidade e registro gravados, E o mesmo número no formato de outra especialidade, por exemplo 123456/AM, é recusado com a mensagem do campo indicando o formato esperado.
• Notas: máscaras no Apêndice: Catálogo de formulários. O sistema não consulta o conselho de classe (ADR-004).

RF-CORE-004: Perfil do usuário

• Descrição: cada usuário edita os seus próprios dados de perfil. O profissional edita também a apresentação dele para os alunos vinculados (especialidade, registro, biografia curta, foto).
• Prioridade: Alta
• Atores: todos
• H1: Dado um usuário autenticado na tela de perfil, Quando altera um campo e salva, Então o valor novo aparece na tela de perfil após recarregar, E a alteração fica registrada na trilha de auditoria com autor, campo, valor anterior e valor novo.
• Notas: o e-mail é exibido em leitura nesta tela, por ser a identidade de login; a troca de e-mail é requisito próprio (RF-CORE-013, ADR-015). A biografia curta integra a apresentação que o profissional edita e não integra o perfil público reduzido de D.2, que é fechado em quatro campos (nome, foto, especialidade e registro); a tela que precisar exibir biografia a um aluno vinculado exige ampliar a lista de D.2 e republicar o requisito, nunca um segundo leitor.

RF-CORE-005: Recuperação de senha

• Descrição: o usuário pede a redefinição pelo e-mail, recebe um endereço de uso único com validade e define a senha nova.
• Prioridade: Essencial
• Atores: todos
• H1: Dado um usuário que solicita redefinição para um e-mail cadastrado, Quando abre o endereço recebido dentro de sessenta minutos e define uma senha nova, Então consegue entrar com a senha nova, E o mesmo endereço usado uma segunda vez retorna erro de link inválido.
• Notas: e-mail não cadastrado retorna a mesma mensagem neutra, para não revelar existência de conta.

RF-CORE-006: Isolamento de dados por unidade

• Descrição: todo dado de aluno é acessível apenas ao próprio aluno, aos profissionais com vínculo ativo ou histórico com ele e ao Administrador. A regra vale em toda tabela de dado de aluno, não apenas na tabela de vínculo, e é aplicada na camada de dados.
• Prioridade: Essencial
• Atores: todos
• H1: Dado o profissional P1 vinculado ao aluno A1 e o profissional P2 sem vínculo com A1, Quando P2 solicita por identificador direto qualquer registro de A1 nas dezesseis entidades de dado de aluno listadas em E.1, Então a resposta é negada ou vazia nas dezesseis, E P1 obtém os mesmos registros com sucesso, E nas duas entidades da classe restrita de E.1, conta_integracao e aceite_termos, tanto P1 quanto P2 recebem negação, respondendo apenas ao titular e ao Administrador, E qualquer usuário que consulte o perfil de outro recebe exatamente os campos do perfil público de D.2 e nenhum outro, fechando trinta e seis casos de acesso somados os dois grupos.
• Notas: este requisito é violado quando qualquer uma das dezesseis entidades nominadas em E.1 responde dado de aluno a quem não é o titular, profissional vinculado ou Administrador; quando uma das duas entidades restritas responde a um profissional vinculado; ou quando a consulta ao perfil de outro usuário devolve um campo fora da lista do perfil público.

RF-CORE-007: Acesso cross-unidade do Administrador, auditado

• Descrição: os dois papéis de administração atravessam o isolamento por unidade, e o que os separa é o QUE cada um alcança depois de atravessar. O Super Administrador enxerga e opera qualquer dado de qualquer aluno, inclusive as categorias de saúde, nutrição e corpo, as conversas e a atividade importada. O Administrador enxerga e opera, em qualquer unidade, apenas o dado não clínico: perfil, vínculo, ficha de treino, sessão de treino, solicitação de ficha, preferências de treino, cobrança e catálogo. As quatorze capacidades da fronteira de B.1 respondem negação a ele, de leitura e de escrita, e as quatro que entraram por conteúdo (conversa com vinculado, conversa entre profissionais, serviço de atividade e geração assistida) estão lá porque negar a categoria e deixar aberto o canal que a transporta não nega nada. Todo acesso de qualquer um dos dois a dado de aluno em unidade que não é dele gera registro de auditoria com o identificador do aluno, a entidade acessada, o papel do autor e o momento.
• Prioridade: Essencial
• Atores: Super Administrador, Administrador
• H1: Dado o Super Administrador autenticado, Quando abre um exame, uma prescrição, uma anamnese, uma avaliação física, uma sessão de reabilitação, uma medida corporal, uma refeição, um plano alimentar ou uma foto de progresso de qualquer aluno, Então o conteúdo é exibido nas nove, E existe um registro de auditoria do tipo acesso administrativo com autor, papel do autor, aluno, entidade e horário, consultável na tela de auditoria, E um Administrador autenticado que pede as mesmas nove, por tela e por rota direta, recebe negação nas nove, sem conteúdo parcial e sem lista vazia disfarçada de resultado, E o mesmo Administrador recebe negação também ao abrir uma conversa de aluno, ao abrir a atividade importada de um serviço conectado e ao acionar a geração assistida sobre um aluno, fechando doze negações de leitura, E o mesmo Administrador abre o perfil, o vínculo, a ficha de treino, a sessão de treino e as preferências de treino do mesmo aluno com sucesso nas cinco, cada uma gerando a sua entrada de auditoria.
• Notas: este requisito é violado quando um Administrador obtém conteúdo de qualquer uma das quatorze capacidades da fronteira de B.1, por qualquer caminho, inclusive por lista, por busca, por exportação e por relatório detalhado; e quando um acesso cross-unidade de qualquer um dos dois não produz entrada de auditoria. A geração assistida deixou de ser um caminho a vigiar e passou a ser uma capacidade negada a ele (fronteira de B.1), porque uma proposta de dieta é escrita a partir do dado nutricional do aluno e devolveria em prosa exatamente o que a classificação nega; porta fechada vale mais que porta aberta com aviso escrito ao lado. A negação acontece na camada de dados e na rota, nunca só escondendo o botão. O relatório agregado do sistema (RF-PAIN-008) continua disponível aos dois papéis por tratar de números do sistema e não de dado clínico de aluno identificável.

Nota de leitura (gate {F4-01}, Drift 1, 2026-09-29): RF-CORE-006 diz que o dado de aluno é legível "pelo Administrador", e essa frase se lê sob RF-CORE-007, que restringe o alcance do Administrador ao dado não clínico e lhe nega, de leitura e de escrita, as entidades da fronteira de B.1. Nenhum requisito é editado; apenas se declara a leitura conjunta dos dois.

RF-CORE-008: Exclusão privativa do Super Administrador

• Descrição: excluir em definitivo é ação exclusiva do Super Administrador. Aluno, profissional e Administrador apenas desativam, e o registro desativado sai das listas de trabalho mas permanece no histórico e na auditoria.
• Prioridade: Essencial
• Atores: Super Administrador, Administrador, Aluno, Profissional
• H1: Dado um aluno ou um profissional autenticado, Quando aciona a remoção de uma ficha, plano alimentar, refeição, medida, exame, prescrição, sessão de reabilitação, anamnese, avaliação, foto ou vínculo, Então a única ação disponível é desativar e o registro passa a status inativo permanecendo consultável no histórico, E a exclusão definitiva pedida por papel diferente de Super Administrador é negada nessas onze entidades, inclusive quando quem pede é um Administrador.

RF-CORE-009: Trilha de auditoria de alteração

• Descrição: toda escrita em dado de aluno registra quem criou, quem alterou por último e quando, e cada alteração gera uma entrada de auditoria imutável com valor anterior e valor novo dos campos alterados.
• Prioridade: Essencial
• Atores: todos
• H1: Dado um profissional que altera o número de séries de um exercício numa ficha criada por outro profissional, Quando salva, Então a ficha passa a exibir o autor da última alteração e o momento, E existe uma entrada de auditoria com autor, entidade, identificador, campo alterado, valor anterior e valor novo, E qualquer tentativa de editar ou remover essa entrada é negada para todos os papéis, inclusive o Super Administrador, E a leitura da trilha é servida apenas ao Super Administrador, sendo negada ao Administrador, que opera sem consultá-la.
• Notas: consultar a trilha de auditoria é uma das oito capacidades privativas do Super Administrador (B.1). O Administrador continua produzindo entradas de auditoria como qualquer outro papel, inclusive as de acesso administrativo de RF-CORE-007; o que ele não faz é ler a trilha. Ficha do artefato no card ART-AUD-01 do Inventário de Artefatos.

RF-CORE-010: Consentimento específico por categoria de dado sensível

• Descrição: antes do primeiro registro em cada categoria de dado sensível de saúde, o aluno concede consentimento específico daquela categoria, com data, versão do texto e finalidade. O consentimento pode ser revogado; a revogação bloqueia novas escritas e o compartilhamento com profissionais, sem apagar o histórico.
• Prioridade: Essencial
• Atores: Aluno, Super Administrador
• H1: Dado um aluno que nunca consentiu a categoria exame, Quando ele ou um profissional vinculado tenta criar um exame para ele, Então a operação é bloqueada e a tela de consentimento daquela categoria é apresentada, E após conceder o consentimento a mesma operação conclui, E após revogar o consentimento uma nova tentativa volta a ser bloqueada enquanto os exames já existentes continuam visíveis apenas ao próprio aluno e ao Super Administrador, E, na categoria nutrição, dado um aluno sem consentimento de nutrição e um Personal Trainer com vínculo ativo com ele, a leitura da refeição, da meta nutricional e do plano alimentar desse aluno pelo Personal é negada pela tela e pela rota direta, sem conteúdo parcial, e a primeira refeição que o aluno tenta registrar é bloqueada sem linha gravada, com a tela de consentimento de nutrição apresentada.
• Notas: as sete categorias são exame, prescrição, anamnese, avaliação física (inclusive a medida corporal, que é a antropometria registrada fora da avaliação), sessão de reabilitação, foto de progresso e nutrição (refeição com os alimentos dela, meta nutricional e plano alimentar com as refeições dele). Ver RN-001. O ator Administrador consulta e audita, nunca consente no lugar do titular: consentimento concedido por terceiro não é consentimento. A restrição por especialidade é escolhida no momento da concessão; trocá-la depois é revogar e conceder de novo, o que deixa os dois eventos na trilha de auditoria, e RN-003 continua atendida porque a restrição vale imediatamente. Ficha do artefato de mecanismo no card ART-ACS-09 do Inventário de Artefatos.

Nota (Inspeção, {AUD-11}, 2026-09-30): nutrição passa a ser a sétima categoria. O motivo está no próprio documento: B.1 e RF-CORE-007 já classificam nutrição como dado clínico na fronteira da administração ("dez por classificação, que são as categorias de saúde, nutrição e corpo"), e a lei de proteção de dados trata o dado referente à saúde como sensível, de modo que a lista de seis categorias ficou incoerente com a fronteira que o próprio documento traça. A categoria cobre refeicao (com refeicao_alimento), meta_nutricional e plano_alimentar (com plano_refeicao), tem finalidade e texto próprios e aceita a restrição por especialidade como as outras seis (RN-003). A vigência padrão da meta (RF-DIET-002) deixa de ser semeada na criação da conta e passa a ser semeada no primeiro consentimento de nutrição concedido, com o valor vigente de metas_padrao naquele momento, porque uma linha gravada antes do consentimento violaria D.6. Dado já existente: refeição e meta gravadas antes do consentimento permanecem, legíveis pelo titular e pelo Super Administrador, fora da vista do profissional e sem escrita nova até o consentimento, a mesma situação de uma categoria revogada; a vigência padrão de aluno sem consentimento, por ser cópia do padrão e não dado da pessoa, sai, e volta a nascer no consentimento. Medido em 30/09/2026, em transação somente leitura: zero refeições e uma vigência padrão, de um aluno; o gate do card mede de novo antes da migração. Perda declarada: o aluno passa a consentir antes do primeiro registro de refeição ou de meta; o profissional vinculado sem o consentimento do aluno deixa de ler nutrição, inclusive o Personal Trainer, que hoje lê; a meta padrão do aluno passa a ser a vigente no dia do consentimento, não a do dia do cadastro. Este requisito é violado, na categoria nutrição, quando um profissional vinculado lê refeição, meta nutricional ou plano alimentar de aluno que não consentiu nutrição ou que a restringiu a outra especialidade, ou quando existe linha dessas três entidades gravada para aluno sem o consentimento vigente, salvo o dado anterior a {AUD-11} descrito acima.

Nota (Inspeção, {AUD-11}, drift 7, 2026-09-30): a restrição por especialidade escolhida pelo aluno governa também a ESCRITA, não só a leitura. O profissional fora da restrição não grava dado da categoria, porque não pode gravar o que não pode ler: onde a escrita de terceiro depende de ler a linha anterior (a meta nutricional, cuja vigência nunca pode nascer atrás da última), a inserção exige mfit.consentimento_visivel(aluno_id, 'nutricao') além de mfit.tem_consentimento(aluno_id, 'nutricao'), e a primeira é sempre verdadeira para o titular. Isso substitui, com data de 2026-09-30, a leitura de que a restrição só governa a leitura, registrada no histórico de mudanças de {F1-12}: essa leitura valeu até esta data, fica citada como superada e não é apagada. A tabela refeicao não é afetada, porque só o titular a escreve; plano_alimentar herda a regra em {F4-03}. Este requisito é violado, na categoria nutrição, quando um profissional vinculado fora da restrição escolhida pelo aluno grava meta nutricional para ele.

Nota (Inspeção, reconciliação, 2026-09-30): medida_corporal fica na categoria avaliação física, sem categoria nova. O texto deste documento sustenta a escolha: RF-SAUD-002 define a antropometria da avaliação como peso, dobras cutâneas, perímetros e percentual de gordura, e a medida corporal (Apêndice de catálogo de formulários) registra peso, percentual de gordura e onze perímetros, isto é, a mesma antropometria registrada fora da avaliação; B.1 já põe "registrar medida corporal" entre as dez capacidades de dado classificado. A tabela nasce em {F5-07} já nessa categoria. Perda declarada: o aluno passa a consentir avaliação física antes da primeira medida corporal, inclusive a que registra sozinho, e o profissional sem esse consentimento não lê as medidas. O H1 deste requisito passa a dizer que, depois da revogação, o histórico fica visível ao próprio aluno e ao Super Administrador, pela fronteira de B.1, que nega ao Administrador todo dado clínico.

RF-CORE-011: Página pública inicial

• Descrição: o endereço raiz do sistema responde uma página pública, sem sessão, cuja mensagem principal é o treino de musculação acompanhado: ficha, execução com carga registrada e progressão visível. Depois dessa mensagem, a página nomeia os cinco papéis de público atendidos (Aluno, Personal Trainer, Médico, Fisioterapeuta e Nutricionista) e o que cada um faz na plataforma, e oferece as duas chamadas de ação, entrar e criar conta. É a porta de entrada de quem chega sem conta e de quem chega deslogado.
• Prioridade: Alta
• Atores: Visitante, Aluno, Personal Trainer, Médico, Fisioterapeuta, Nutricionista
• Pré-condições: nenhuma; a página não exige sessão.
• Saída: página pública com apresentação, papéis atendidos e chamadas para entrar e cadastrar.
• H1: Dado um visitante sem sessão, Quando abre o endereço raiz do sistema, Então a página responde com sucesso sem redirecionar para a tela de entrada, E o primeiro bloco da página trata do treino de musculação, antes de qualquer menção a dieta, saúde ou comunicação, E a página exibe os cinco papéis de público nominalmente e as duas chamadas de ação, entrar e criar conta, E cada chamada leva à tela correspondente, E um usuário com sessão ativa que abre o endereço raiz é levado ao painel do papel dele.
• Notas: este requisito é violado quando o endereço raiz redireciona o visitante sem sessão para a tela de entrada, ou quando a página existe mas não nomeia os cinco papéis ou não oferece as duas chamadas. Nenhum dado de aluno, de profissional ou de valor de plano é exibido nesta página. Usuário com sessão ativa levado ao painel é decisão do cliente, executada na chegada à rota, e o gatilho é o marcador não sensível de sessão que o navegador guarda: o cookie de sessão é inacessível ao script por desenho (D.2), então o produto não tem como saber com certeza, e o caso residual (marcador ausente com cookie válido) exibe a página pública a quem tem sessão, sem prejuízo, pois as duas chamadas continuam levando às telas certas e a próxima entrada recria o marcador. A página não consulta o banco nem a API para montar o conteúdo, e por isso continua apresentando o produto inteiro mesmo com o banco indisponível. "Nenhum valor de plano" alcança também nome de plano, porque o catálogo é editável pela administração (ADR-012) e um nome escrito na tela envelheceria calado. A frase da página sobre a plataforma não ser prontuário é prosa de apresentação, não o texto versionado de RF-CORE-012, e a home não é um quinto ponto daquele requisito. Rota de saúde e tela de referência de desenvolvimento (/api/estado, /estilo) não são alcançáveis por link de nenhuma página pública. A raiz responde com sucesso também para quem chega com cookie expirado ou inválido, nunca com redirecionamento, nunca com erro.

RF-CORE-012: Aviso de natureza não clínica da plataforma

• Descrição: o sistema declara, em quatro pontos fixos, que é ferramenta de acompanhamento e não prontuário nem registro clínico oficial, e que a responsabilidade pelo registro clínico do paciente permanece com o profissional de saúde. Os quatro pontos são: o texto dos termos de uso aceitos no cadastro, a tela de cadastro do profissional, para as quatro especialidades, o topo das telas de exame, prescrição, anamnese e sessão de reabilitação, e o pacote da exportação do titular. O aceite dos termos é registrado com a versão do texto e a data.
• Prioridade: Essencial
• Atores: Aluno, Personal Trainer, Médico, Fisioterapeuta, Nutricionista, Administrador
• Pré-condições: texto e versão do aviso cadastrados na configuração.
• Entrada: aceite dos termos no cadastro.
• Saída: aviso exibido nos quatro pontos e aceite registrado com versão e data.
• H1: Dado o texto do aviso publicado na versão vigente, Quando um usuário percorre os quatro pontos, Então o aviso aparece nos quatro (termos de uso do cadastro, tela de cadastro do profissional para as quatro especialidades, topo de cada uma das quatro telas clínicas e arquivo do pacote de exportação), E o aceite do usuário fica registrado com a versão do texto e a data do aceite, E ao publicar uma versão nova do texto os quatro pontos passam a exibir a nova sem alterar o registro do aceite anterior, E remover o aviso de qualquer um dos quatro pontos reprova este requisito.
• Notas: este requisito é violado quando um dos quatro pontos não exibe o aviso, quando existe conta ativa sem aceite registrado com versão e data, ou quando o texto vive no código em vez da configuração. O texto e a versão são parâmetro editável pela administração (ADR-012, L.2). Este requisito convive com o consentimento por categoria (RF-CORE-010) sem substituí-lo: o aviso diz o que a plataforma não é, o consentimento autoriza o tratamento de cada categoria de dado sensível. Decisão: o aviso é exibido na tela de cadastro do profissional para as quatro especialidades, incluindo Personal Trainer, superconjunto que garante que nenhum ponto exigido fica sem aviso, já que o Personal Trainer também trata dado de saúde do aluno. A página pública inicial (RF-CORE-011) não é um quinto ponto deste requisito: a frase de apresentação da home diz o que a plataforma é, em prosa, não consome a configuração do aviso, não registra aceite e não carrega número de versão.

RF-CORE-013: Troca do e-mail de login pelo próprio usuário

• Descrição: o usuário autenticado pede a troca do e-mail de login informando o endereço novo e a senha atual. O sistema envia ao endereço novo um endereço de confirmação de uso único, com validade limitada; até a confirmação, o login continua pelo endereço antigo e a tela de perfil mostra o novo como "aguardando confirmação", com opção de cancelar o pedido. Ao confirmar, o endereço novo passa a ser o de login, o antigo recebe um aviso da troca e a mudança entra na trilha de auditoria.
• Prioridade: Alta
• Atores: Aluno, Personal Trainer, Médico, Fisioterapeuta, Nutricionista, Administrador
• Pré-condições: usuário autenticado; senha atual correta; endereço novo com formato válido e não usado por outra conta (ADR-014).
• Entrada: endereço novo e senha atual.
• Saída: pedido pendente, confirmação por e-mail, troca efetivada e aviso ao endereço antigo.
• H1: Dado um usuário autenticado com e-mail A, Quando pede a troca para o e-mail B com a senha correta, Então o sistema registra o pedido pendente e envia a B um endereço de confirmação de uso único, E o login continua funcionando com A e não funciona com B enquanto o pedido está pendente, E ao abrir o endereço de confirmação dentro da validade o login passa a funcionar com B e deixa de funcionar com A, E o endereço A recebe um aviso da troca, E a trilha de auditoria guarda autor, valor anterior A e valor novo B, E o endereço de confirmação aberto pela segunda vez, ou depois da validade, é recusado sem efeito, E o pedido com senha errada, com B já usado por outra conta ou com formato inválido é recusado sem enviar e-mail.
• Notas: este requisito é violado quando o login passa a aceitar B antes da confirmação, quando A deixa de funcionar antes da confirmação, quando a troca não aparece na auditoria, ou quando a confirmação é reutilizável. Reaproveita o endereço de uso único e a fila de e-mail de RF-CORE-005. Validade do endereço de confirmação é parâmetro (mesmo de RF-CORE-005). Um pedido novo cancela o anterior. A administração vê o pedido pendente no cadastro do usuário (RF-PAIN-009) e pode cancelá-lo.

RF-CORE-014: Personificação de usuário pelo Super Administrador, com registro

• Descrição: para atender um chamado de suporte, o Super Administrador assume a visão de um usuário determinado e passa a enxergar o sistema como aquele usuário enxerga, com as permissões daquele usuário e não com as dele. A personificação começa por ação explícita a partir da administração de usuários, exibe faixa permanente na interface enquanto durar, grava início e fim na trilha de auditoria, marca com o par personificador e personificado toda entrada de auditoria gerada no período, e termina por ação explícita de sair ou pela expiração automática de trinta minutos, o que vier primeiro. A personificação nunca amplia o alcance de quem personifica: a categoria de dado sensível que o titular não consentiu continua bloqueada, e o Administrador não personifica ninguém.
• Prioridade: Essencial
• Atores: Super Administrador
• Pré-condições: sessão autenticada de Super Administrador; usuário alvo existente e de papel diferente de Super Administrador.
• Entrada: identificador do usuário alvo e confirmação nominal.
• Saída: sessão de personificação ativa, faixa na interface, entradas de auditoria de início e de fim.
• H1: Dado o Super Administrador autenticado e um aluno alvo, Quando inicia a personificação a partir da administração de usuários, Então toda tela passa a responder com os dados e as permissões do aluno, E a faixa de personificação aparece no topo de toda tela nomeando quem está sendo personificado e oferecendo a saída, E a trilha de auditoria ganha uma entrada de início com personificador, personificado e momento, E toda entrada de auditoria gerada enquanto a personificação dura traz o par personificador e personificado, E uma categoria de dado sensível sem consentimento do titular continua bloqueada para escrita durante a personificação, E ao acionar a saída, ou decorridos trinta minutos sem saída, a sessão volta a ser a do Super Administrador e a trilha ganha a entrada de fim com o momento, E a mesma ação pedida por um Administrador, por um profissional ou por um aluno é negada nos três casos, E a personificação de uma conta de Super Administrador é negada.
• Notas: este requisito é violado quando existe sessão de personificação sem entrada de início, quando a entrada de fim não aparece depois da saída ou da expiração, quando a faixa não está visível em alguma tela enquanto a personificação dura, quando uma escrita feita sob personificação chega à trilha sem o par personificador e personificado, quando a personificação alcança uma categoria não consentida pelo titular, ou quando um papel diferente de Super Administrador consegue personificar. A personificação é leitura e escrita na visão do alvo, e não troca de dono do registro: o campo de autor do registro escrito sob personificação continua sendo o usuário personificado, e é a trilha de auditoria, não o registro, que guarda quem estava por trás. Sair da personificação não encerra a sessão do Super Administrador. A validade de trinta minutos é parâmetro de configuração (L.2, ADR-012). A personificação serve para ver e para operar o que o usuário opera, nunca para agir como titular em ato de identidade ou de vontade. Sob personificação ficam negadas, por lista fechada de três: trocar a senha do usuário personificado; trocar o e-mail dele; e conceder ou revogar consentimento e aceitar os termos no lugar dele. Consentimento dado por outro não é consentimento, e credencial trocada por outro não é recuperação de conta: o caminho dessas três continua sendo o do próprio titular. Este requisito é violado também quando qualquer uma dessas três conclui sob personificação. Consequência declarada, para ninguém a descobrir na tela: o Super Administrador que personifique um usuário que ainda não aceitou os termos para no portão de aceite e não passa. A lista é fechada em três e nenhuma capacidade nova nasce da personificação: as oito capacidades privativas do Super Administrador continuam sendo oito e a Matriz Ator por Capacidade não muda por causa deste parágrafo. O bloqueio administrativo da conta não é critério de alvo: personificar uma conta bloqueada pela administração é permitido, e isto fica declarado em vez de ficar por omissão. A razão é que personificar não é entrar: não passa pela autenticação, não valida senha, não emite renovação de sessão para o alvo e não levanta o bloqueio, que continua valendo para o próprio usuário. O chamado de suporte mais provável do produto é justamente o de quem foi bloqueado e não sabe por quê, e negar obrigaria o operador a desbloquear a conta para poder diagnosticá-la, ou seja, a mudar o estado do usuário antes de entender o problema. A única negação de alvo escrita neste requisito continua sendo a que o H1 nomeia, a conta de Super Administrador. Ficha do artefato de mecanismo no card ART-ACS-13 do Inventário de Artefatos.

C.4 Módulo vinc, vínculo entre profissional e aluno

RF-VINC-001: Profissional inicia o vínculo

• Descrição: o profissional busca o aluno pelo identificador público de aluno e envia o convite de vínculo. O aluno não solicita vínculo, apenas responde.
• Prioridade: Essencial
• Atores: Personal Trainer, Médico, Fisioterapeuta, Nutricionista
• H1: Dado um profissional autenticado e um aluno existente sem vínculo com ele, Quando o profissional envia o convite pelo identificador do aluno, Então é criado um vínculo com estado pendente, E o aluno recebe uma notificação de convite, E toda consulta do profissional a dado desse aluno retorna vazia enquanto o estado for pendente.
• Notas: o aluno enxerga o seu identificador público no perfil e pode copiá-lo. O identificador tem o formato MF-XXXX-XX (prefixo fixo, um grupo de quatro e um de dois caracteres alfanuméricos maiúsculos, sem as letras I e O nem os dígitos 0 e 1, para ditado sem ambiguidade), é gerado na criação do perfil, é único e nunca muda. Busca textual por nome é privativa do Administrador (D.2, {ART-ACS-11}); as funções que resolvem o convite nunca aceitam nome nem fazem busca aproximada (nem LIKE, nem ILIKE), o convite se faz somente pelo identificador que o aluno dita ou copia do próprio perfil.

RF-VINC-002: Aluno aceita ou recusa o vínculo

• Descrição: o aluno decide sobre cada convite recebido. Aceitar abre o acesso do profissional; recusar encerra o convite sem abrir acesso.
• Prioridade: Essencial
• Atores: Aluno
• H1: Dado um vínculo pendente, Quando o aluno aceita, Então o vínculo passa a ativo e o profissional passa a enxergar os dados do aluno nas categorias consentidas, E quando o aluno recusa, o vínculo passa a recusado e nenhuma consulta do profissional aos dados desse aluno retorna registro.

RF-VINC-003: Encerramento do vínculo com preservação do histórico

• Descrição: profissional ou aluno encerram a relação a qualquer momento. O vínculo passa a inativo, o profissional perde escrita e leitura do dado corrente, e o histórico gerado por ele durante o vínculo permanece existindo, atribuído a ele, sem exclusão em cascata.
• Prioridade: Essencial
• Atores: Aluno, Profissional, Administrador
• H1: Dado um vínculo ativo em que o profissional criou três fichas, Quando qualquer um dos dois encerra o vínculo, Então o vínculo fica inativo, E as três fichas continuam existindo com a autoria do profissional preservada e visíveis ao aluno e ao Administrador, E toda tentativa de criação ou edição pelo profissional nesse aluno é negada.

RF-VINC-004: Vínculos simultâneos, sem limite por especialidade

• Descrição: o aluno mantém quantos vínculos ativos quiser ao mesmo tempo, inclusive mais de um na mesma especialidade (dois Personal Trainers, dois Nutricionistas). A especialidade não limita nada; o único limite é a dimensão de vínculos ativos do plano do aluno (RF-PLAN-003). O que não se repete é o par aluno e profissional: um mesmo profissional tem no máximo um vínculo ativo com o mesmo aluno.
• Prioridade: Alta
• Atores: Aluno, Profissional
• H1: Dado um aluno num plano com a dimensão de vínculos ativos ilimitada e já vinculado a um Personal Trainer, Quando aceita o convite de um segundo Personal Trainer, Então passa a ter dois vínculos ativos na mesma especialidade e os dois enxergam os dados consentidos do aluno, E aceitar convites de um Médico, um Fisioterapeuta e um Nutricionista leva o total a cinco vínculos ativos, sem recusa nenhuma por especialidade repetida, E a única recusa possível nesse fluxo é a do limite de vínculos do plano, com a mensagem que nomeia o limite, E um convite do mesmo profissional que já tem vínculo ativo com esse aluno é recusado por já existir o vínculo daquele par.
• Notas: este requisito é violado quando existe qualquer recusa motivada pela especialidade do profissional convidado. Ficha, plano alimentar e registro clínico continuam com autoria individual (RN-009), então dois profissionais da mesma especialidade não editam o registro um do outro.

RF-VINC-005: Gestão global de vínculos pelo Administrador

• Descrição: o Administrador lista todos os vínculos do sistema com filtro por estado, especialidade, profissional e aluno, e pode ativar, desativar ou excluir qualquer um.
• Prioridade: Alta
• Atores: Administrador
• H1: Dado o Administrador na tela de vínculos, Quando filtra por estado pendente, Então a lista mostra somente vínculos pendentes com profissional, aluno, especialidade e data, E ao desativar um vínculo dessa lista o profissional correspondente deixa de acessar os dados daquele aluno na consulta seguinte.

C.5 Módulo plan, planos da plataforma

RF-PLAN-001: Catálogo de planos editável pela administração

• Descrição: o Super Administrador cria e edita os planos do aluno, cada um com nome, descrição, valor de referência, recorrência e os limites operacionais que libera. O catálogo é editado por tela, sem alteração de código, e nenhum limite vive fixo no código (ADR-012). Manter este catálogo é uma das oito capacidades privativas do Super Administrador (B.1): o Administrador lê a tela de planos e não escreve nela.
• Prioridade: Essencial
• Atores: Super Administrador
• H1: Dado o Super Administrador na tela de planos, Quando cria um plano com nome, valor, recorrência e limites, Então o plano aparece na lista disponível para atribuição, E ao alterar um limite desse plano a verificação seguinte de todos os alunos que o possuem já usa o valor novo, sem nova publicação do sistema.
• Notas: dimensões de limite e valores iniciais no Apêndice: Catálogo de planos. A lista disponível para atribuição do H1 é o conjunto de planos ativos; a tela de atribuição, o seletor de aluno e o status de acesso pertencem a RF-PLAN-002.

RF-PLAN-002: Atribuição manual de plano e status de acesso

• Descrição: o Super Administrador define o plano e o status de acesso de cada aluno. Não existe cobrança automática nem gateway; a definição é manual e vale imediatamente. Atribuir plano e status de acesso é uma das oito capacidades privativas do Super Administrador (B.1), e a mesma atribuição pedida por um Administrador é negada.
• Prioridade: Essencial
• Atores: Super Administrador
• H1: Dado um aluno no plano gratuito, Quando o Super Administrador atribui um plano pago e mantém o status ativo, Então o aluno passa a operar com os limites do plano novo na sessão seguinte, E ao receber o status inativo o aluno entra no sistema mas só alcança as telas de perfil, plano e leitura do próprio histórico, com toda escrita negada.
• Notas: toda escrita negada alcança também a escrita do próprio perfil e a de consentimento, não só a criação de dado novo. A negação é de escrita, nunca de leitura: o aluno inativo continua lendo tudo o que já lia, e nenhuma tela some. A restrição é do ator, não do titular: um profissional vinculado a um aluno inativo não tem escrita alguma restringida por este requisito.

RF-PLAN-003: Aplicação dos limites do plano

• Descrição: os limites do plano são verificados no momento da ação, com mensagem que nomeia o limite atingido e o plano que o libera.
• Prioridade: Alta
• Atores: Aluno
• H1: Dado um aluno num plano cujo limite de vínculos ativos é um, Quando aceita o segundo convite de vínculo, Então a operação é recusada com a mensagem nomeando o limite de vínculos e o plano que o amplia, E após a administração atribuir o plano com limite maior a mesma operação conclui, E o mesmo aluno num plano com essa dimensão ilimitada conclui a operação em qualquer quantidade, sem recusa.
• Notas: dimensão cadastrada como ilimitada nunca recusa; a verificação a trata como aprovação imediata, sem contagem. O sujeito do limite é sempre o titular da linha (o aluno dono do vínculo, da ficha, do plano alimentar), nunca o ator que pratica a ação: um profissional ou o Administrador que tenta criar vínculo ativo para um aluno já no teto também é recusado, porque o teto é do aluno, não de quem escreve; este requisito é o oposto de RF-PLAN-002, cujo sujeito é o ator, e as duas verificações não se fundem numa só. A mensagem que nomeia o limite e o plano que o amplia é responsabilidade da camada que responde ao pedido, além da verificação em si e nunca no lugar dela, porque a verificação sozinha só sabe dizer que negou, não por quê. Quando nenhum plano ativo do catálogo amplia a dimensão atingida, a mensagem diz isso com todas as letras e aponta para a administração; nunca cita um plano inventado e nunca deixa o aluno sem explicação.

RF-PLAN-004: Visão do plano pelo aluno

• Descrição: o aluno consulta o plano vigente, o que ele libera, o consumo atual de cada limite e o status de acesso.
• Prioridade: Média
• Atores: Aluno
• H1: Dado um aluno autenticado, Quando abre a tela do plano, Então vê o nome do plano vigente, o status de acesso e cada limite com o valor consumido e o valor máximo, E o consumo exibido em cada limite é igual à contagem real dos registros correspondentes do aluno, E na dimensão ilimitada o lugar do valor máximo traz a palavra ilimitado, sem barra de proporção nem alerta de limite próximo.
• Notas: (a) o consumo exibido é o mesmo número que a verificação de RF-PLAN-003 usa, garantido por haver uma função só que conta, a verificação a chama para decidir e a tela a chama para exibir; (b) "aprovada sem contagem" (L.1) continua valendo para a verificação e não se estende à exibição, a tela do plano ilimitado conta e mostra o consumo, como o próprio Apêndice manda ("a tela do plano exibe o consumo com a palavra ilimitado no lugar do valor máximo"), e são coisas diferentes porque exibir não aprova nada; (c) dimensão cuja entidade ainda não existe é exibida como não medida, nunca como zero, zero é uma afirmação sobre registros que nenhuma tabela guardou; (d) o consumo não é limitado ao máximo, o Apêndice manda que reduzir o plano não apague nada, logo um aluno acima do teto é estado legítimo e a tela mostra o número real; (e) "sem alerta de limite próximo" é literal e vale sempre na dimensão ilimitada, qualquer que seja o consumo; (f) o "desde" da tela é o instante da última atribuição do plano vigente na trilha de auditoria, e, quando o aluno nunca trocou de plano, o instante de criação do perfil.

C.6 Módulo cobr, cobrança do profissional ao aluno

Este módulo registra e acompanha a cobrança que o profissional combina com o seu aluno pelo serviço dele. O sistema não movimenta dinheiro (ADR-005).

RF-COBR-001: Acordo de cobrança do profissional com o aluno

• Descrição: em um vínculo ativo, o profissional registra o acordo financeiro: valor, moeda, recorrência (mensal, quinzenal, avulsa), dia de vencimento, data de início, data de término opcional e observações. O aluno enxerga o acordo e não o edita.
• Prioridade: Alta
• Atores: Profissional, Aluno
• H1: Dado um vínculo ativo sem acordo, Quando o profissional registra valor, recorrência mensal e dia de vencimento, Então o acordo passa a constar no vínculo e o aluno o enxerga na tela de cobrança dele, E toda tentativa de criação ou edição do acordo pelo aluno é negada.

RF-COBR-002: Geração das competências do acordo

• Descrição: a partir do acordo recorrente, o sistema gera as competências (o período cobrado) até a data corrente, cada uma com valor, vencimento e status. Acordo avulso gera uma competência única.
• Prioridade: Alta
• Atores: Profissional
• H1: Dado um acordo mensal iniciado há três meses com vencimento no dia dez, Quando o profissional abre a cobrança daquele aluno, Então existem exatamente três competências, uma por mês decorrido, com vencimento no dia dez de cada mês e valor igual ao do acordo, E nenhuma competência de mês futuro foi criada.

RF-COBR-003: Baixa manual de pagamento

• Descrição: o profissional marca uma competência como paga, informando a data do pagamento e uma observação opcional, ou como isenta, ou a mantém em aberto. A marcação é manual e o sistema não confirma pagamento por nenhum meio externo.
• Prioridade: Alta
• Atores: Profissional
• H1: Dado uma competência em aberto e vencida, Quando o profissional a marca como paga com a data do pagamento, Então o status passa a paga com a data registrada e o total em aberto daquele aluno diminui exatamente no valor daquela competência, E a marcação fica na trilha de auditoria com o autor e o momento.

RF-COBR-004: Extrato de cobrança do aluno

• Descrição: o aluno consulta, por profissional, o acordo vigente e as competências com valor, vencimento e status.
• Prioridade: Média
• Atores: Aluno
• H1: Dado um aluno com acordos ativos com dois profissionais, Quando abre a tela de cobrança, Então vê dois blocos, um por profissional, cada um com o acordo e as competências com status, E o total em aberto exibido é igual à soma dos valores das competências com status em aberto.

C.7 Módulo exer, catálogo de exercícios

RF-EXER-001: Manutenção do catálogo global pela administração

• Descrição: o Administrador cria, edita, desativa e exclui exercícios do catálogo. O exercício é global, não pertence a nenhuma unidade, e todo profissional e todo aluno o enxergam.
• Prioridade: Essencial
• Atores: Administrador
• H1: Dado o Administrador na tela de exercícios, Quando cria um exercício preenchendo os onze campos do formulário, nome, grupo muscular, equipamento, instruções de execução, erros comuns, dicas de execução, séries padrão, repetições padrão, descanso padrão, dificuldade e categoria, Então o exercício aparece na busca de todos os profissionais e alunos do sistema, E a tela do exercício exibe erros comuns e dicas de execução como blocos próprios, abaixo das instruções, E um exercício com esses dois campos vazios não exibe bloco vazio nem altera a altura da tela, E toda operação de criação, edição ou exclusão de exercício pedida por papel diferente de Administrador é negada.
• Notas: campos completos no Apêndice: Catálogo de formulários.

RF-EXER-002: Mídia demonstrativa do exercício

• Descrição: cada exercício aceita uma imagem ou animação demonstrativa (arquivo enviado ou endereço externo) e um vídeo por endereço, exibido embutido na tela do aluno.
• Prioridade: Essencial
• Atores: Administrador, Aluno, Profissional
• H1: Dado um exercício com imagem enviada e endereço de vídeo, Quando o aluno abre esse exercício durante a execução da sessão, Então a imagem é exibida na proporção natural dela e o vídeo aparece embutido e reproduzível, E um exercício sem mídia exibe o espaço reservado sem alterar a altura dos demais elementos da tela.

RF-EXER-003: Busca e filtro no catálogo

• Descrição: a busca aceita texto no nome e filtros por grupo muscular, dificuldade, categoria e equipamento, combináveis entre si.
• Prioridade: Essencial
• Atores: Administrador, Profissional, Aluno
• H1: Dado um catálogo com exercícios de dez grupos musculares, Quando o usuário filtra por grupo Costas e dificuldade Iniciante, Então a lista contém somente exercícios que atendem às duas condições ao mesmo tempo, E o contador exibido é igual ao número de itens listados.

RF-EXER-004: Leitura do catálogo por todos os papéis

• Descrição: o catálogo é de leitura para todo usuário autenticado, independentemente de vínculo, plano ou especialidade.
• Prioridade: Essencial
• Atores: todos
• H1: Dado um aluno no plano gratuito e sem nenhum vínculo, Quando abre o catálogo de exercícios, Então consulta qualquer exercício com nome, mídia e instruções, E nenhuma ação de escrita sobre o exercício é oferecida nem aceita para ele.

RF-EXER-005: Geração assistida de mídia demonstrativa de exercício

• Descrição: a administração aciona a geração de imagem ou animação demonstrativa de um exercício, a partir do nome, do grupo muscular, do equipamento e das instruções de execução dele, ou aciona a geração em lote para todos os exercícios do catálogo sem mídia. O resultado entra como prévia por exercício, com as ações aprovar e rejeitar, e só a prévia aprovada vira a mídia do exercício no catálogo.
• Prioridade: Média
• Atores: Administrador
• Pré-condições: exercício existente no catálogo, com nome, grupo muscular e instruções preenchidos.
• Entrada: um exercício, ou o conjunto dos exercícios sem mídia.
• Saída: prévia de mídia por exercício, aguardando aprovação ou rejeição.
• H1: Dado um catálogo com sete exercícios sem mídia, Quando o Administrador aciona a geração em lote, Então são produzidas sete prévias, uma por exercício, E nenhum exercício do catálogo teve a mídia alterada enquanto as prévias não foram aprovadas, E ao aprovar duas prévias e rejeitar as outras cinco exatamente dois exercícios passam a ter mídia e os cinco rejeitados permanecem sem mídia e voltam a constar na lista de exercícios sem mídia.
• Notas: este requisito é violado quando uma mídia gerada substitui a mídia do catálogo sem aprovação explícita, ou quando um exercício que já tem mídia entra no lote sem ter sido escolhido individualmente. A geração é acionada apenas pelo Administrador, como toda escrita no catálogo (RF-EXER-001), e o ponto está registrado em M.2.

C.8 Módulo trei, treino

RF-TREI-001: Criação de ficha de treino pelo profissional

• Descrição: o profissional cria uma ficha para um aluno vinculado, com título, descrição opcional e lista ordenada de exercícios do catálogo, cada item com séries, repetições, descanso em segundos, carga sugerida opcional e observação opcional do item (por exemplo cadência lenta, ou três séries de quinze por lado).
• Prioridade: Essencial
• Atores: Personal Trainer, Fisioterapeuta
• H1: Dado um profissional com vínculo ativo, Quando cria uma ficha com título e quatro exercícios com séries, repetições e descanso, sendo que num deles preenche a observação do item, Então a ficha aparece na lista de treinos do aluno com os quatro itens na ordem definida, E o autor registrado na ficha é o profissional que a criou, E durante a execução da sessão o item com observação exibe a observação junto do exercício, sem o aluno precisar abrir outra tela, E os três itens sem observação não exibem espaço reservado para ela.

RF-TREI-002: Criação de ficha pelo próprio aluno

• Descrição: o aluno cria fichas para si mesmo, com a mesma estrutura, independentemente de ter ou não profissional vinculado.
• Prioridade: Essencial
• Atores: Aluno
• H1: Dado um aluno sem nenhum vínculo ativo, Quando cria uma ficha com três exercícios, Então a ficha é salva com autoria dele e fica disponível para execução, E a ficha aparece para os profissionais que venham a ser vinculados depois, identificada como criada pelo aluno.

RF-TREI-003: Edição de ficha restrita ao autor, com auditoria

• Descrição: a ficha só é editada por quem a criou e pelo Administrador. Quem tem acesso e não é o autor consulta a ficha, pede ajuste ao autor ou duplica para si (RF-TREI-009). Toda edição registra autor e momento.
• Prioridade: Essencial
• Atores: Aluno, Profissional, Administrador
• H1: Dado uma ficha criada por um Personal Trainer, Quando o aluno dono da ficha tenta alterar séries, repetições, ordem ou lista de exercícios dela, Então a operação é negada e as ações oferecidas são consultar, pedir ajuste e duplicar, E quando o próprio Personal Trainer autor faz a mesma alteração ela é gravada e produz entrada de auditoria com valor anterior e valor novo.
• Notas: decisão registrada na ADR-006.

RF-TREI-004: Solicitação de nova ficha pelo aluno

• Descrição: o aluno pede ao profissional vinculado uma ficha nova ou o ajuste de uma existente, com um texto de motivo. O pedido tem estado (aberto, atendido, recusado) e notifica o profissional.
• Prioridade: Alta
• Atores: Aluno, Personal Trainer, Fisioterapeuta
• H1: Dado um aluno com vínculo ativo, Quando envia uma solicitação de nova ficha com o motivo preenchido, Então o profissional recebe a notificação e vê a solicitação com estado aberto na lista dele, E ao criar a ficha vinculando a solicitação, o estado passa a atendido e o aluno recebe a notificação com a ficha nova.

RF-TREI-005: Execução da sessão de treino

• Descrição: o aluno inicia uma sessão a partir de uma ficha. A tela mostra um exercício por vez com posição na lista, nome, grupo muscular, mídia, instruções de execução, erros comuns e dicas de execução do exercício, e a observação do item quando houver, mais um cronômetro geral da sessão. Campo sem conteúdo não gera bloco vazio e não altera a altura da tela, na mesma regra do H1 de RF-EXER-001. Por série executada registra o número da série, a carga em quilogramas, as repetições feitas, o tempo de execução em segundos e uma observação, ficando a critério do exercício quais desses campos são usados: série de carga preenche carga e repetições, série por tempo (prancha, bicicleta, esteira) preenche o tempo e deixa as repetições vazias. A sessão inteira também aceita uma observação. O aluno pode pular exercício e encerrar a sessão a qualquer momento.
• Prioridade: Essencial
• Atores: Aluno
• H1: Dado um aluno com uma ficha de cinco exercícios, Quando inicia a sessão, registra três séries de carga no primeiro exercício, pula o segundo, registra no terceiro uma série por tempo de sessenta segundos sem preencher repetições e conclui os demais, Então a sessão finalizada registra duração total maior que zero, exatamente um exercício marcado como pulado, as séries de carga com carga e repetições e a série por tempo com sessenta segundos gravados e as repetições vazias, sem erro de validação, E o volume total da sessão é igual à soma de carga vezes repetições apenas das séries que têm os dois valores, ignorando a série por tempo, conforme RN-004, E a observação da sessão e a observação de uma série gravadas aparecem no histórico daquela sessão, E enquanto a sessão está em andamento a tela do dispositivo permanece acesa, sem escurecer por inatividade, em todo navegador que conceda o bloqueio de tela, sendo o bloqueio liberado ao encerrar a sessão ou ao sair da tela de execução.
• Notas: onde o navegador não oferece o bloqueio de tela, a sessão funciona igual e nenhuma mensagem de erro é exibida; a ausência do recurso não é falha da sessão. A retomada de uma sessão interrompida é tratada em RF-TREI-010.

RF-TREI-006: Cronômetro de descanso entre séries

• Descrição: ao concluir uma série, o sistema inicia uma contagem regressiva com o descanso definido para aquele exercício, com aviso sonoro ao terminar e possibilidade de pular ou ajustar o tempo na hora.
• Prioridade: Essencial
• Atores: Aluno
• H1: Dado um exercício com descanso de sessenta segundos, Quando o aluno conclui uma série, Então a contagem regressiva começa em sessenta segundos e decresce, E ao chegar a zero emite o aviso sonoro e libera a série seguinte, E o botão de pular encerra a contagem imediatamente.

RF-TREI-007: Histórico de sessões e progressão de carga

• Descrição: cada sessão concluída entra no histórico do aluno com data, ficha, duração, volume e exercícios executados. Para cada exercício, o sistema compara a carga máxima da sessão atual com a da sessão anterior do mesmo exercício e exibe a diferença. A carga máxima da sessão anterior do exercício também é exibida durante a execução da sessão, ao lado do descanso alvo, como referência para a série que o aluno vai registrar.
• Prioridade: Essencial
• Atores: Aluno, Profissional
• H1: Dado um aluno que executou o supino com carga máxima de quarenta quilogramas na sessão anterior, Quando conclui uma sessão com carga máxima de quarenta e cinco quilogramas nesse exercício, Então o histórico exibe a variação de mais cinco quilogramas naquele exercício, E a primeira execução de um exercício sem sessão anterior exibe a marcação de primeira medição em vez de uma variação.

RF-TREI-008: Preferências de treino do aluno

• Descrição: o aluno registra objetivos, nível de experiência, equipamentos disponíveis, dias da semana disponíveis, duração preferida da sessão, limitações e lesões e observações. As preferências alimentam a geração assistida e orientam o profissional.
• Prioridade: Alta
• Atores: Aluno, Profissional
• H1: Dado um aluno na tela de preferências, Quando escolhe dois objetivos, o nível intermediário, cinco equipamentos, três dias da semana e a duração de sessenta minutos e salva, Então esses valores aparecem preenchidos ao reabrir a tela, E o profissional vinculado enxerga as mesmas preferências na ficha do aluno.
• Notas: listas fechadas de opções no Apêndice: Catálogo de formulários. A tela é /treinos/preferencias, linha própria do Apêndice de catálogo de telas, e serve aos dois atores: o aluno escreve e lê as próprias preferências, e o profissional vinculado lê as do aluno pela mesma rota, com o aluno na consulta, em somente leitura, sem escrever nenhum campo. O campo de limitações e lesões não é categoria de dado sensível (RN-001): ele é visível a todo profissional com vínculo ativo, de qualquer especialidade, sem consentimento por categoria e sem a restrição por especialidade de RN-003, e a tela diz isso ao aluno, em texto factual e curto, uma vez, junto do campo e antes de ele escrever, no mesmo padrão com que a tela de privacidade já declara alcance de dado. Este requisito é violado quando um aluno salva os sete campos e algum deles volta diferente ao reabrir a tela, quando um profissional vinculado ao aluno não enxerga exatamente os mesmos valores, quando um profissional sem vínculo enxerga qualquer valor, ou quando alguém que não é o titular consegue gravar a preferência.

RF-TREI-009: Duplicação de ficha de terceiro como ficha própria

• Descrição: quem tem acesso a uma ficha e não é o autor pode duplicá-la, gerando uma cópia editável com autoria de quem duplicou e referência à ficha de origem.
• Prioridade: Média
• Atores: Aluno, Profissional
• H1: Dado uma ficha criada por um profissional, Quando o aluno a duplica, Então nasce uma ficha nova com os mesmos exercícios, autoria do aluno e referência à ficha de origem, E a ficha original permanece inalterada, E o aluno consegue editar a cópia.

RF-TREI-010: Retomada de sessão de treino em andamento

• Descrição: uma sessão iniciada e não encerrada continua existindo no banco com o estado em andamento e com as séries já registradas. Enquanto houver sessão em andamento, o painel do aluno e a lista de treinos exibem o atalho de retomar, que reabre a sessão no ponto em que ela parou, recarregando as séries do banco e não da memória da tela. Sessão em andamento sem nenhum registro novo por mais tempo que o prazo configurado passa a abandonada e deixa de ser oferecida para retomada.
• Prioridade: Essencial
• Atores: Aluno
• Pré-condições: existir uma sessão do aluno no estado em andamento.
• Saída: sessão retomada com as séries já registradas, ou sessão marcada como abandonada.
• H1: Dado um aluno que iniciou uma sessão e registrou duas séries, Quando fecha o navegador e volta a entrar em outro dispositivo, Então o painel e a lista de treinos exibem o atalho de retomar aquela sessão, E ao retomar as duas séries já registradas aparecem, com o cronômetro seguindo a partir do início original da sessão, E ao concluir a sessão o volume considera as duas séries anteriores mais as novas, E a mesma sessão sem nenhum registro por mais tempo que o prazo configurado passa a abandonada, deixa de exibir o atalho de retomar nas duas telas e não conta para sequência, calendário, conquistas nem progressão.
• Notas: este requisito é violado quando o atalho de retomar não aparece existindo sessão em andamento, quando a retomada perde qualquer série já gravada, ou quando uma sessão abandonada continua sendo oferecida para retomada. O prazo de abandono é o parâmetro sessao_abandono_horas, com valor inicial de vinte e quatro horas (L.2). Um aluno tem no máximo uma sessão em andamento por vez: iniciar uma sessão nova com outra em andamento exige retomar a anterior e encerrá-la, ou esperar o prazo de abandono.

C.9 Módulo diet, dieta e nutrição

RF-DIET-001: Registro de refeição pelo aluno

• Descrição: o aluno registra uma refeição com tipo, nome, data, horário opcional, observações e lista de alimentos, cada alimento com nome, quantidade em gramas, calorias, proteína, carboidrato e gordura. O sistema soma os macronutrientes da refeição.
• Prioridade: Alta
• Atores: Aluno
• H1: Dado um aluno na tela de refeições, Quando registra uma refeição com dois alimentos de cem e duzentas calorias, Então a refeição salva exibe trezentas calorias no total, E o mesmo vale para proteína, carboidrato e gordura, cada um igual à soma dos itens.

RF-DIET-002: Metas diárias de calorias e macronutrientes

• Descrição: o aluno tem metas diárias de calorias, proteína, carboidrato e gordura, com valores iniciais padrão e edição pelo aluno ou por qualquer Nutricionista com vínculo ativo. Havendo mais de um Nutricionista vinculado, a meta vigente é sempre a de vigência mais recente, e o histórico guarda quem definiu cada uma.
• Prioridade: Alta
• Atores: Aluno, Nutricionista
• H1: Dado um aluno com meta de duas mil calorias e dois Nutricionistas vinculados, Quando o primeiro altera a meta para duas mil e quatrocentas, Então a tela diária do aluno passa a comparar o consumo com duas mil e quatrocentas, E quando o segundo altera depois para duas mil e duzentas a tela passa a comparar com duas mil e duzentas, E a auditoria tem duas entradas, cada uma com o autor correspondente, E o histórico de metas preserva as três vigências sem apagar nenhuma.

RF-DIET-003: Plano alimentar prescrito

• Descrição: qualquer Nutricionista com vínculo ativo, ou o próprio aluno na ausência de um, cria um plano alimentar com título, descrição e refeições estruturadas, cada uma com nome, horário, notas e lista de alimentos com quantidades.
• Prioridade: Alta
• Atores: Nutricionista, Aluno
• H1: Dado um nutricionista com vínculo ativo, Quando cria um plano com quatro refeições estruturadas, Então o plano aparece na tela do aluno com as quatro refeições na ordem de horário, E a edição do plano por quem não é o autor é negada, seguindo a mesma regra da ficha de treino.

RF-DIET-004: Painel diário de consumo

• Descrição: o painel do dia mostra o consumido, o restante e o percentual de cada meta, o total do dia e a lista de refeições registradas, com navegação por data.
• Prioridade: Alta
• Atores: Aluno, Nutricionista
• H1: Dado um aluno com meta de duas mil calorias e mil e duzentas calorias registradas no dia, Quando abre o painel diário, Então vê mil e duzentas consumidas, oitocentas restantes e sessenta por cento da meta, E ao navegar para um dia sem registro os quatro totais aparecem em zero, sem erro.
• Notas: Regra da comparação (Inspeção, gate {F4-04}, 2026-09-30): o painel compara o consumido do dia com a meta vigente da data por cinco regras. (1) Restante é a meta menos o consumido, com uma casa decimal; resultado negativo se exibe como "N acima da meta", nunca como restante negativo. (2) Percentual é o consumido sobre a meta vezes cem, inteiro, arredondado meio para cima e sem teto (2300 de 2000 é 115 por cento); a barra de progresso para em cem por cento da largura. (3) Meta zero de macronutriente, ou aluno sem meta vigente: o consumido é exibido, o restante e o percentual não são exibidos e a tela mostra "Sem meta definida" (cálculo impossível não vira zero, RN-004). (4) Dia sem registro: o consumido é zero nos quatro totais (a soma de nenhuma refeição é zero, não é entrada ausente), como diz o H1. (5) Refeição desativada não conta no consumo do dia (RN-008). Leitura (Inspeção, gate {F4-04}, 2026-09-30): os Atores nomeiam quem age sobre o painel; a leitura é a de RF-DIET-002 e RF-CORE-007, e o profissional sem a categoria visível recebe 403. Os demais Profissionais de vínculo ativo com a categoria visível já leem o dia desde {F4-02}, e a Matriz Ator por Capacidade não tem linha de painel.

RF-DIET-005: Acompanhamento nutricional do aluno pelo profissional

• Descrição: cada Nutricionista com vínculo ativo consulta o histórico de refeições, a aderência às metas por período e a evolução de peso e composição corporal do aluno, e ajusta o plano a partir desses dados.
• Prioridade: Alta
• Atores: Nutricionista
• H1: Dado um nutricionista com vínculo ativo em um aluno com trinta dias de registros, Quando abre o acompanhamento nutricional daquele aluno com o período de trinta dias, Então vê a média diária de calorias e de cada macronutriente e o número de dias em que a meta foi atingida, E o mesmo acompanhamento pedido para um aluno sem vínculo ativo é negado.

Nota (Inspeção, {AUD-11}, 2026-09-30): os cinco requisitos deste módulo operam dado da categoria nutrição de RF-CORE-010. Registrar refeição (RF-DIET-001), definir meta (RF-DIET-002) e criar plano alimentar (RF-DIET-003) exigem o consentimento vigente de nutrição do aluno, e sem ele a escrita é bloqueada e a tela de consentimento da categoria é apresentada; o painel diário (RF-DIET-004) e o acompanhamento pelo profissional (RF-DIET-005) servem ao profissional vinculado apenas a categoria que o aluno consentiu e não restringiu a outra especialidade, e o titular lê sempre. Os valores iniciais padrão de RF-DIET-002 nascem no primeiro consentimento de nutrição, não no cadastro.

Nota (Inspeção, gate {F4-05}, Drift 1, 2026-09-30), Regra do acompanhamento: o H1 conta dias com meta atingida, e a definição é esta, em seis itens. (1) Dia com meta atingida é o dia com meta vigente de calorias e com o percentual de calorias da comparação de RF-DIET-004 (o inteiro de mfit.comparacao_com_meta) dentro de cem mais ou menos a tolerância, inclusive nas duas pontas, isto é, as calorias do dia ficam dentro da tolerância, para mais ou para menos, da meta. A tolerância é o parâmetro nutricao_meta_tolerancia_pct, valor inicial dez (L.2). Macronutriente não decide o dia: aparece nas médias. (2) Dia sem registro (nenhuma refeição ativa) nunca está na meta: o consumido é zero (regra 4 de RF-DIET-004) e zero não fica dentro da faixa. (3) Dia sem meta vigente (calorias nulas, RN-004) não conta como na meta nem como fora dela: é contado à parte, como "N dias sem meta definida". (4) Média diária de cada macronutriente é a soma do período dividida pelos dias com registro, com uma casa decimal; sem nenhum dia com registro a média não é exibida ("Sem registro no período") e nunca vira zero, porque dia não registrado é entrada ausente para a média, não jejum (RN-004). (5) Período são N dias completos terminando na data até, e o padrão é ontem na data do aparelho: o dia corrente ainda está aberto e é lido em /nutricao. N é 7 ou 30, com padrão 30. (6) Refeição desativada não conta (RN-008), como no painel. Este requisito é violado quando um dia sem registro conta como meta atingida, quando a média é dividida pelos dias do período em vez dos dias com registro, quando o período padrão inclui o dia corrente, quando macronutriente decide o dia, ou quando o dia sem meta vigente é contado como na meta ou como fora dela. A Descrição e o H1 não mudam.

Nota (Inspeção, gate {F4-05}, Drift 3, 2026-09-30): a Descrição promete mais do que o H1 exige, e o recorte é este. "Evolução de peso e composição corporal" depende da medida corporal, que nasce em {F5-07} (RF-SAUD-007), e entra nesse card: este requisito não a entrega antes. "Histórico de refeições" entra como a lista de dias do período, e cada dia leva ao dia em /nutricao?aluno=&data=. "Ajusta o plano" entra como o caminho para /nutricao/planos?aluno=, e a edição do plano é a de RF-DIET-003.

Nota (Inspeção, gate {F4-05}, Drift 4, 2026-09-30): a leitura segue a mesma decisão de RF-DIET-004 e de RF-DIET-002: titular; Profissional de vínculo ativo de qualquer especialidade, com a categoria nutrição visível; Super Administrador com acesso administrativo; o Administrador recebe 403 nomeado antes de qualquer leitura de dado. Sem vínculo ativo a resposta é 404, e é essa a negação do H1; fora da restrição do aluno é 403 categoria_nao_compartilhada. A conta é feita sobre dois dados que o leitor do dia já lê, a refeição e a meta. A tela serve o Profissional, que é o ator do requisito; o aluno não ganha tela de acompanhamento, e a ausência é declarada em vez de desenhada.

C.10 Módulo saud, saúde clínica e evolução

RF-SAUD-001: Anamnese datada, com esquema único e seções condicionais por especialidade

• Descrição: a anamnese é um retrato datado do aluno. Existe um esquema único, com um tronco comum (dados pessoais, queixa principal, histórico médico, hábitos de vida, objetivos, observações) e seções que aparecem conforme a especialidade de quem preenche. Cada preenchimento cria um registro novo, com data, autor e especialidade do autor, e o aluno acumula quantas anamneses forem as ocasiões de coleta, listadas da mais recente para a mais antiga. Ao abrir uma anamnese nova, o tronco comum vem pré-preenchido com os valores da anamnese anterior do aluno, todos editáveis. O aluno preenche a própria anamnese quando não há profissional daquela especialidade vinculado.
• Prioridade: Alta
• Atores: Profissional, Aluno
• Pré-condições: consentimento da categoria anamnese concedido.
• Saída: registro de anamnese datado, com autor, especialidade do autor, tronco e seções preenchidas naquela ocasião.
• H1: Dado um aluno com uma anamnese registrada por um Personal Trainer há seis meses, Quando um Médico vinculado preenche uma anamnese nova, Então o formulário abre com o tronco comum pré-preenchido pelos valores da anamnese anterior e com as seções da especialidade médica, E ao salvar existem exatamente duas anamneses do aluno, cada uma com a própria data, autor e especialidade, E a anamnese de seis meses atrás permanece intacta, com os valores originais dela, inclusive nos campos que o Médico alterou na nova, E a lista de anamneses do aluno exibe as duas em ordem decrescente de data.
• Notas: este requisito é violado quando um preenchimento novo sobrescreve qualquer campo de uma anamnese anterior, quando o aluno passa a ter um único registro depois de duas coletas, ou quando o tronco comum da anamnese nova nasce vazio existindo anamnese anterior. Composição do tronco e das seções por especialidade no Apêndice: Catálogo de formulários. Decisão registrada na ADR-007. A explicação em linguagem simples da anamnese é RF-SAUD-010.

Nota (Inspeção, gate {F5-01}, Drifts 3 e 4, 2026-10-01): duas leituras deste requisito, sem editar a Descrição, a Prioridade nem o H1. Quem preenche o quê: o profissional preenche o tronco comum e, das quatro seções por especialidade, somente a da própria especialidade, e somente com vínculo ativo naquela especialidade; o aluno preenche sempre o tronco comum e, das quatro seções, somente as das especialidades com as quais não tem vínculo ativo, na forma de RF-DIET-003 (o aluno age onde não há profissional da especialidade vinculado). Ao ler, aparecem todas as seções gravadas. A especialidade do autor vem da sessão, nunca do formulário, e é nula quando o autor é o próprio aluno. Este requisito também é violado quando um profissional grava seção de outra especialidade, ou quando o aluno grava seção de uma especialidade com a qual tem vínculo ativo. Anamnese não se edita: a anamnese é um retrato datado (ADR-007), então corrigir um erro é fazer uma nova coleta, e o autor e o Super Administrador só a desativam, o que a retira da lista de vigentes e a mantém no histórico e na auditoria (RN-008). O banco garante por construção: nenhum campo de conteúdo de uma anamnese aceita atualização, só a desativação. Perde-se que o autor não corrige um erro de digitação sem nova coleta, e o tronco pré-preenchido desta Descrição torna a nova coleta barata. Ver a Nota de RN-009 e a ficha dos campos no Apêndice: Catálogo de formulários.

RF-SAUD-002: Avaliação física

• Descrição: registro de avaliação física em seis seções (anamnese resumida, cardiovascular, antropometria, neuromuscular, aeróbico e biotipo), com data e autor, e comparação entre avaliações do mesmo aluno. A antropometria (peso, dobras cutâneas, perímetros e percentual de gordura) é prática das quatro especialidades, e o Nutricionista registra avaliação física como os demais profissionais vinculados.
• Prioridade: Alta
• Atores: Personal Trainer, Fisioterapeuta, Médico, Nutricionista, Aluno
• H1: Dado um aluno com uma avaliação física anterior, Quando um profissional vinculado registra uma avaliação nova, Então a tela de comparação exibe cada métrica presente nas duas avaliações com o valor anterior, o valor atual e a variação, E métricas presentes em apenas uma das avaliações aparecem sem variação calculada.

Nota (Inspeção, gate {F5-02}, Drifts 3 e 4, 2026-10-01): duas leituras deste requisito, sem editar a Descrição, a Prioridade nem o H1. Sem edição de conteúdo: a avaliação física não se edita, a correção é uma nova avaliação, e o autor e o Super Administrador só podem desativá-la, o que a mantém no histórico e na auditoria (RN-008); editar uma avaliação reescreveria em silêncio o "anterior" de toda comparação já vista (ver a Nota em RN-009). Regra da comparação: (a) o par comparado é a avaliação aberta contra a avaliação ativa imediatamente anterior do mesmo aluno (por data e, no empate, por identificador), ou contra outra avaliação ativa escolhida; avaliação desativada não entra. (b) Métrica é o campo numérico (inteiro ou decimal), cada ponto de dobra cutânea (pareado pelo valor da lista) e a carga e as repetições de cada teste de força (pareados pelo nome do teste normalizado: sem espaços nas pontas, em minúsculas e com espaços repetidos reduzidos a um); texto não é métrica e aparece só no detalhe. (c) Métrica presente nas duas: valor anterior, valor atual e variação, que é o atual menos o anterior, com as casas decimais do campo; presente em apenas uma: aparece o valor que existe e "sem variação", e métrica ausente nunca vale zero (RN-004). (d) As métricas de teste (os resultados cardiovascular, de flexibilidade e de resistência e as do teste aeróbico) só têm variação quando o teste aplicado é o mesmo nas duas avaliações; senão aparecem como "testes diferentes", sem variação. (e) Os cálculos de RF-SAUD-003 entram como métricas pela mesma regra, quando existirem. A regra é violada quando a comparação usa uma avaliação desativada, quando uma métrica ausente aparece com variação calculada, quando uma métrica de teste mostra variação entre testes diferentes, ou quando algum campo de conteúdo de uma avaliação gravada aceita atualização.

Nota (Inspeção, gate {F5-03}, Drift 3, 2026-10-06): sem editar a Descrição, a Prioridade, o H1 nem a Nota anterior. A alínea (e) da regra da comparação se lê assim: o índice de massa corporal, a relação cintura quadril e a frequência cardíaca máxima de RF-SAUD-003 entram na comparação como métricas, pela mesma regra da alínea (c), em uma seção "Cálculos" ao fim, com as casas decimais do cálculo (uma, duas e zero), sem alterar a ordem nem a chave das linhas que a comparação já mostrava; as cinco faixas de intensidade não entram, porque cada uma é função da frequência cardíaca máxima e dez linhas a mais repetiriam a mesma variação. A regra é violada quando a comparação traz linha de faixa de intensidade, quando um cálculo não calculado em uma das duas avaliações aparece com variação, ou quando uma linha que a comparação já mostrava muda de chave ou de ordem.

RF-SAUD-003: Cálculos derivados da avaliação

• Descrição: a partir dos dados informados, o sistema calcula índice de massa corporal, frequência cardíaca máxima, relação cintura quadril e as faixas de frequência cardíaca por intensidade, exibindo a fórmula usada.
• Prioridade: Alta
• Atores: Profissional, Aluno
• H1: Dado um aluno com oitenta quilogramas, um metro e oitenta de altura, cintura de noventa centímetros, quadril de cem centímetros e trinta anos, Quando a avaliação é salva, Então o índice de massa corporal exibido é 24,7, a relação cintura quadril é 0,90 e a frequência cardíaca máxima é 190, E as faixas de intensidade são calculadas sobre esse valor de frequência máxima.
• Notas: fórmulas exatas em RN-004.

Nota (Inspeção, gate {F5-03}, Drifts 1, 4 e 5, 2026-10-06): sem editar a Descrição, a Prioridade nem o H1. (1) Onde o cálculo aparece: no detalhe da avaliação e na comparação (RF-SAUD-002, alínea (e)); a lista de avaliações não exibe cálculo, porque este requisito exige exibir a fórmula usada e ela não cabe no cartão da lista. Isto corrige a leitura "detalhe, lista e comparação" da Nota do Drift 9 de {F5-02}. O cálculo é feito na leitura, a partir de peso, altura, cintura, quadril e idade já gravados, e nada dele é gravado. (2) Não exibido (RN-004): o número some e a linha diz "não calculado: informe a altura" quando falta a altura, e a mesma forma nomeia cintura, quadril ou idade quando for esse o insumo que falta; nunca zero. (3) Arredondamento: meio para cima sobre a representação decimal do valor, e não pelo arredondamento de ponto flutuante da linguagem; divisor zero ou ausente devolve não calculado. Com os valores do H1, 80 quilogramas e 1,80 metro dão 24,69 e exibem 24,7, e 33 anos dão frequência máxima 187. A regra é violada quando um cálculo aparece como zero em vez de não calculado, quando a lista de avaliações exibe cálculo, quando o valor exibido difere do arredondamento meio para cima, ou quando algum cálculo é gravado.

RF-SAUD-004: Exames com anexo

• Descrição: registro de exame com tipo, nome, data, resumo dos resultados, observações e um arquivo anexo em formato de documento ou imagem. Enviado por qualquer Médico com vínculo ativo ou pelo próprio aluno.
• Prioridade: Alta
• Atores: Médico, Aluno
• H1: Dado um aluno que consentiu a categoria exame, Quando envia um exame com anexo de até vinte megabytes, Então o exame aparece na lista com tipo, nome e data e o anexo abre por um endereço temporário assinado, E a mesma tentativa com arquivo acima do limite ou de extensão fora da lista permitida é recusada com a mensagem do campo.

Nota (Inspeção, gate {F5-04}, Drifts 3, 7 e 11, 2026-10-06): três leituras deste requisito, sem editar a Descrição, a Prioridade nem o H1. O exame não se edita: é um registro datado e a correção é um novo exame; o autor e o Super Administrador só podem desativá-lo, o que o mantém no histórico e na auditoria (RN-008), e o banco concede atualização somente à desativação (ver a Nota de RN-009). Desativar não apaga o anexo: o exame desativado deixa as listas de trabalho, mas o arquivo continua legível ao titular e ao Super Administrador e continua contando no espaço de armazenamento do plano do aluno; o arquivo só é apagado na exclusão definitiva (RN-008), e a conferência do repositório privado contra o banco garante que nenhum arquivo fique sem registro. O tipo do anexo vem dos bytes: o formato é decidido pelo conteúdo do arquivo e pela extensão declarada, e os dois precisam estar na lista de extensões aceitas e pertencer à mesma família (jpg e jpeg são a mesma); um documento é reconhecido pela assinatura própria, e um arquivo de texto só vale se for texto válido, sem byte nulo e sem caractere de controle além de tabulação e quebra de linha. O limite de tamanho é o parâmetro de operação de anexo (20 megabytes, medido sobre o arquivo, sem contar o envelope da requisição), e um arquivo de exatamente o limite é aceito. A cota de espaço do plano (L.1) é decidida pelo servidor antes de o arquivo ser gravado, somando o anexo novo ao consumo, com a mensagem de limite existente. A regra é violada quando algum campo de conteúdo de um exame gravado aceita atualização, quando desativar remove o arquivo, quando um arquivo cujo conteúdo não corresponde à extensão declarada é aceito, quando um arquivo de exatamente o limite é recusado, ou quando o arquivo é gravado antes de o consentimento, o vínculo e a cota terem sido verificados.

RF-SAUD-005: Prescrições

• Descrição: registro de prescrição com diagnóstico, medicamentos, posologia e instruções, duração do tratamento, data e observações, feito por qualquer Médico com vínculo ativo.
• Prioridade: Alta
• Atores: Médico, Aluno
• H1: Dado um médico com vínculo ativo, Quando registra uma prescrição com diagnóstico, medicamentos, posologia e duração, Então a prescrição aparece na tela do aluno com a data e o autor, E a prescrição exibe o aviso de que não substitui o receituário oficial.

Nota (Inspeção, gate {F5-05}, Drift 7, 2026-10-06): a duração da prescrição nasce estruturada, para que o painel do Médico ({F7-09}, RF-PAIN-004) calcule "prescrições vigentes" como o requisito promete. Ela é uma quantidade inteira maior que zero mais uma unidade (dias, semanas ou meses), ou a marca "uso contínuo", e nunca os dois nem nenhum dos dois. A vigência termina na data da prescrição mais a duração menos 1 dia, e a prescrição de uso contínuo fica vigente até ser desativada. A unidade é constante estrutural do produto, protegida por restrição no banco, e não lista fechada editável pela administração, porque entra no cálculo da vigência (mesmo precedente dos dias da semana): as listas fechadas com consumidor continuam nove. A quantidade vai de 1 a 999, teto que é constante técnica, classificada C no verificador (proteção do cálculo de data, não regra de negócio), com restrição no banco. A posologia continua texto livre. A Descrição, a Prioridade e o H1 não mudam, e a leitura de "duração do tratamento" como texto livre, no Apêndice de formulários e em E.1, é corrigida pelas Notas desses lugares. A regra é violada quando a duração de uma prescrição gravada é texto livre, quando uma prescrição tem quantidade sem unidade, quantidade zero ou negativa, ou quantidade junto com uso contínuo, quando a unidade aceita valor fora de dias, semanas e meses, quando a quantidade aceita valor acima de 999, ou quando a unidade pode ser editada em /admin/listas. Vigência (Inspeção, 2026-10-06): o dia da prescrição é o primeiro dia; vigente_ate = data da prescrição + duração - 1 dia (para semanas e meses, a mesma regra sobre a data somada), e a prescrição é vigente quando a data de hoje é menor ou igual a vigente_ate; uso contínuo é vigente até ser desativada. "Hoje" é a data no fuso America/Sao_Paulo, calculada num ponto único reutilizado por {F5-05} e {F7-09}, nunca a data UTC do banco. Exemplo: 7 dias a partir de 01/10 vale até 07/10.

RF-SAUD-006: Sessões de reabilitação

• Descrição: registro de sessão de reabilitação com região corporal, tratamento realizado, exercícios realizados, notas de amplitude de movimento, notas de progresso, plano da próxima sessão, dor antes e dor depois numa escala de zero a dez, duração em minutos e data. Tratamento realizado é a conduta do profissional; exercícios realizados é o que o paciente executou.
• Prioridade: Alta
• Atores: Fisioterapeuta, Aluno
• H1: Dado um fisioterapeuta com vínculo ativo, Quando registra uma sessão com dor antes sete, dor depois três, tratamento realizado, exercícios realizados, notas de amplitude, notas de progresso e plano da próxima sessão, Então a sessão aparece no histórico com a variação de menos quatro pontos e com os seis campos de texto preenchidos legíveis no detalhe dela, E o plano da próxima sessão aparece no painel do Fisioterapeuta como próxima ação daquele paciente, E um valor de dor fora da faixa de zero a dez é recusado na validação do campo, E uma sessão registrada sem os campos opcionais salva do mesmo jeito, exibindo apenas o que foi preenchido.

Nota (Inspeção, gate {F5-06}, Drifts 1, 3, 4 e 5, 2026-10-06): quatro leituras deste requisito, sem editar a Descrição, a Prioridade nem o H1. (1) Quem grava: o Fisioterapeuta com vínculo ativo na especialidade e o Aluno para si, que são os Atores do requisito e as duas únicas células de escrita da linha "Registrar sessão de reabilitação" da matriz de capacidades (que já está certa e não muda); o aluno grava com a especialidade do autor nula, e o Fisioterapeuta com o vínculo de fisioterapeuta. Personal Trainer, Médico, Nutricionista e Administrador não gravam. (2) Seis campos de texto: o H1 diz seis e o cenário dele preenche cinco; os seis são tratamento realizado, exercícios realizados, notas de amplitude, notas de progresso, plano da próxima sessão e observações, e o Roadmap e o Plano de Testes, que dizem "cinco campos", leem-se como os cinco do cenário. Na tela, o detalhe mostra apenas o que foi preenchido e omite o campo opcional vazio, sem o texto "Não informado" (diferente do detalhe da prescrição). (3) Não se edita: só se desativa, o autor ou o Super Administrador (Nota de RN-009), e nenhum campo de uma sessão guardada muda. A coluna da explicação em linguagem simples é entregue por {F5-10}, dono de RF-SAUD-010, e a notificação de sessão criada (Ação no envio, {ART-WF-07}) por {F6-05}; a sessão grava e aparece nas listas sem elas. (4) Fronteira com RF-PAIN-005: {F5-06} entrega SÓ o bloco "Próxima sessão" no painel do Fisioterapeuta: o plano da ÚLTIMA sessão ativa de cada paciente, e somente quando preenchido; o plano de uma sessão anterior nunca sobe. A carteira de pacientes, a evolução da dor por região e os pacientes sem sessão recente são de {F7-10}. Este requisito é violado quando o Personal Trainer, o Médico, o Nutricionista ou o Administrador grava uma sessão, quando uma sessão é editada em vez de desativada, ou quando o painel exibe o plano de uma sessão que não é a última ativa do paciente.

RF-SAUD-007: Medidas corporais

• Descrição: registro datado das treze métricas de composição e circunferência, com gráfico de evolução e diferença em relação à medição anterior.
• Prioridade: Alta
• Atores: Aluno, Profissional
• H1: Dado um aluno com uma medição anterior de oitenta quilogramas, Quando registra uma medição nova de setenta e oito quilogramas, Então a tela exibe a variação de menos dois quilogramas em relação à medição anterior, E o gráfico passa a conter dois pontos na série de peso, ordenados por data.
• Notas: as treze métricas no Apêndice: Catálogo de formulários.

RF-SAUD-008: Fotos de progresso

• Descrição: galeria de fotos corporais datadas, enviadas pelo aluno, cada uma com a categoria de pose (frente, lado direito, lado esquerdo, costas) e uma observação opcional, com comparação lado a lado entre duas datas da mesma categoria.
• Prioridade: Média
• Atores: Aluno, Profissional
• H1: Dado um aluno que consentiu a categoria foto de progresso, Quando envia duas fotos de frente em datas diferentes e uma de costas, Então a galeria agrupa as três pela categoria, E a comparação oferece apenas as duas fotos de frente quando a categoria escolhida é frente, sem oferecer a de costas, E as duas escolhidas aparecem lado a lado com as respectivas datas, E a categoria de costas com uma única foto exibe o estado de comparação indisponível, sem erro, E o endereço direto do arquivo, sem a assinatura temporária, retorna acesso negado.
• Notas: a lista de categorias de pose é fechada na tela e editável pela administração (listas_fechadas, L.2). Este requisito é violado quando a comparação aceita duas fotos de categorias diferentes.

RF-SAUD-009: Armazenamento segregado do dado sensível

• Descrição: os arquivos de exame, prescrição, anamnese e foto de progresso ficam em repositório privado, com acesso apenas por endereço assinado e de validade curta, separado do repositório público da mídia de exercício.
• Prioridade: Essencial
• Atores: todos
• H1: Dado um arquivo de mídia de exercício e um arquivo de exame, Quando o endereço direto de cada um é acessado sem sessão autenticada, Então a mídia de exercício responde o conteúdo e o exame responde acesso negado, E o exame só responde conteúdo por endereço assinado gerado para quem tem direito de leitura, expirando em até quinze minutos.

RF-SAUD-010: Explicação em linguagem simples do registro clínico

• Descrição: sob acionamento do usuário, o sistema gera uma explicação em linguagem simples de um registro clínico, exibida com formatação de texto e tabela, sempre acompanhada do aviso de que não é diagnóstico nem conduta. São exatamente quatro os registros com esse acionamento: exame, prescrição, anamnese e sessão de reabilitação.
• Prioridade: Média
• Atores: Aluno, Profissional
• Pré-condições: registro existente com conteúdo preenchido e consentimento vigente da categoria dele.
• Saída: texto explicativo guardado no próprio registro, com a data da geração.
• H1: Dado um exame, uma prescrição, uma anamnese e uma sessão de reabilitação preenchidos do mesmo aluno, Quando o usuário aciona a explicação em cada um dos quatro, Então os quatro exibem o texto gerado formatado, com o aviso de que não substitui a avaliação do profissional, E o conteúdo original de cada registro permanece intacto, E gerar de novo substitui apenas a explicação daquele registro, sem tocar nos outros três nem no conteúdo original.
• Notas: este requisito é violado quando qualquer um dos quatro registros não oferece o acionamento, quando a explicação sobrescreve conteúdo original, ou quando a explicação é gravada sem o aviso. Registrado como ponto de geração assistida em M.2.

C.11 Módulo comu, comunicação

RF-COMU-001: Conversa entre aluno e profissional vinculado

• Descrição: existe uma conversa por par aluno e profissional com vínculo ativo, com histórico persistente, indicação de mensagem lida e ordenação por data.
• Prioridade: Alta
• Atores: Aluno, Profissional
• H1: Dado um vínculo ativo, Quando o aluno envia uma mensagem, Então ela aparece na conversa dos dois com autor e horário, E um profissional sem vínculo com esse aluno não consegue abrir nem listar essa conversa.

RF-COMU-002: Conversa entre profissionais do mesmo aluno

• Descrição: profissionais com vínculo ativo no mesmo aluno conversam entre si numa conversa vinculada àquele aluno, sem a participação do aluno.
• Prioridade: Alta
• Atores: Profissional
• H1: Dado dois profissionais de especialidades diferentes com vínculo ativo no mesmo aluno, Quando um deles abre a conversa profissional daquele aluno e envia uma mensagem, Então o outro profissional a recebe, E o aluno não enxerga essa conversa em nenhuma tela dele, E um terceiro profissional sem vínculo com o aluno não consegue abri-la.

RF-COMU-003: Grupo por aluno com menções

• Descrição: existe uma conversa em grupo por aluno, com o aluno e todos os profissionais de vínculo ativo. É possível mencionar um participante pelo nome, o que gera notificação dirigida a ele.
• Prioridade: Alta
• Atores: Aluno, Profissional
• H1: Dado um grupo com o aluno e três profissionais, Quando um participante envia mensagem mencionando um dos profissionais, Então todos recebem a mensagem no grupo e apenas o mencionado recebe a notificação de menção, E quando um vínculo é encerrado o profissional correspondente deixa de receber mensagens novas do grupo mantendo o histórico do período em que participou.

RF-COMU-004: Política de conteúdo do chat

• Descrição: o chat aceita texto e endereço de internet, que vira link clicável. O envio de arquivo é bloqueado em toda conversa, com mensagem indicando a tela própria para aquele tipo de conteúdo.
• Prioridade: Alta
• Atores: todos
• H1: Dado qualquer conversa do sistema, Quando o usuário arrasta ou seleciona um arquivo para envio, Então o envio é bloqueado com a mensagem indicando a tela de exames, fotos ou plano conforme o caso, E uma mensagem contendo um endereço de internet é aceita e exibida como link clicável.

RF-COMU-005: Central de notificações com limpeza

• Descrição: um ponto único no topo da navegação concentra as notificações, com contagem de não lidas, marcação individual como lida, limpeza de todas de uma vez e agrupamento por origem para não acumular repetição.
• Prioridade: Alta
• Atores: todos
• H1: Dado um usuário com doze notificações não lidas, Quando aciona limpar todas, Então a contagem vai a zero e a lista fica vazia sem recarregar a página, E cinco mensagens seguidas da mesma conversa aparecem como uma notificação agrupada com o contador cinco, e não como cinco linhas.

RF-COMU-006: Entrega em tempo real

• Descrição: mensagem nova e notificação nova chegam ao destinatário conectado sem que ele recarregue a tela.
• Prioridade: Alta
• Atores: todos
• H1: Dado dois usuários com a mesma conversa aberta, Quando um envia uma mensagem, Então ela aparece na tela do outro em até três segundos sem recarregar, E o contador do sino é incrementado na mesma janela de tempo.

C.12 Módulo enga, engajamento

RF-ENGA-001: Início guiado do aluno

• Descrição: no painel do aluno existe uma lista de primeiros passos (preencher preferências, registrar medidas, executar o primeiro treino, registrar a primeira refeição), com marcação automática conforme o aluno cumpre cada um, e que some quando todos estiverem cumpridos.
• Prioridade: Média
• Atores: Aluno
• H1: Dado um aluno recém-cadastrado, Quando abre o painel, Então vê os quatro passos, nenhum marcado, E ao registrar a primeira refeição o passo correspondente aparece marcado sem ação manual, E quando os quatro estiverem cumpridos o bloco deixa de ser exibido.

RF-ENGA-002: Sequência de dias com atividade

• Descrição: o sistema conta os dias consecutivos em que o aluno concluiu ao menos uma sessão de treino, reiniciando a contagem quando há um dia sem sessão.
• Prioridade: Média
• Atores: Aluno
• H1: Dado um aluno que concluiu sessões em três dias consecutivos, Quando abre o painel no quarto dia sem ter treinado, Então a sequência exibida é três, E se o quinto dia passar sem sessão a sequência exibida passa a zero.

RF-ENGA-003: Calendário de atividade

• Descrição: mapa das últimas doze semanas com a intensidade de atividade por dia, calculada pelo número de sessões concluídas naquele dia.
• Prioridade: Média
• Atores: Aluno, Profissional
• H1: Dado um aluno com sessões em quatro dias distintos nas últimas doze semanas, Quando abre o calendário, Então exatamente quatro casas aparecem preenchidas, nas datas corretas, E dias fora da janela de doze semanas não aparecem no mapa.

RF-ENGA-004: Conquistas

• Descrição: oito conquistas concedidas automaticamente quando o aluno atinge o marco correspondente, com data de concessão e exibição no painel.
• Prioridade: Média
• Atores: Aluno
• H1: Dado um aluno com nove sessões concluídas e a conquista de dez sessões ainda não concedida, Quando conclui a décima sessão, Então a conquista correspondente passa a constar como concedida com a data de hoje e gera notificação, E a mesma conquista não é concedida uma segunda vez em sessões posteriores.
• Notas: lista das oito no Apêndice: Catálogo de conquistas.

RF-ENGA-005: Gráfico de progressão de carga por exercício

• Descrição: gráfico da carga máxima registrada por sessão, para um exercício escolhido pelo aluno, no período selecionado.
• Prioridade: Alta
• Atores: Aluno, Profissional
• H1: Dado um aluno com cinco sessões contendo o mesmo exercício, Quando escolhe esse exercício no gráfico, Então a série tem cinco pontos ordenados por data com a carga máxima de cada sessão, E ao escolher um exercício nunca executado o gráfico exibe o estado vazio, sem erro.

RF-ENGA-006: Indicador de completude do perfil do aluno

• Descrição: o painel do aluno exibe o percentual de completude do perfil, calculado sobre um conjunto nomeado e fechado de campos, com a lista dos que faltam e um atalho direto para cada um. O bloco desaparece quando o percentual chega a cem por cento.
• Prioridade: Média
• Atores: Aluno
• Pré-condições: nenhuma; o bloco existe desde o primeiro acesso.
• Saída: percentual, lista de campos faltantes e atalho por campo.
• H1: Dado o conjunto nomeado de cinco campos de completude (data de nascimento, sexo, altura, peso mais recente e foto), com um aluno que preencheu apenas a altura, Quando abre o painel, Então o indicador exibe vinte por cento e lista os quatro campos faltantes nominalmente, E o atalho de cada faltante leva ao campo correspondente, E ao preencher a data de nascimento o indicador passa a quarenta por cento e o campo sai da lista, E com os cinco preenchidos o indicador exibe cem por cento e o bloco deixa de ser exibido no painel.
• Notas: este requisito é violado quando o percentual não é igual ao número de campos preenchidos dividido pelo tamanho do conjunto nomeado, quando um faltante aparece sem atalho, ou quando o bloco continua visível em cem por cento. O conjunto de campos é o parâmetro campos_completude (L.2) e nenhum deles é obrigatório para usar o sistema, conforme D.10.

C.13 Módulo iage, geração assistida

RF-IAGE-001: Geração de proposta de treino

• Descrição: sob acionamento do profissional ou do aluno, o sistema gera uma proposta de treino considerando as preferências do aluno, a última avaliação física, as últimas medidas, o histórico de sessões e o catálogo de exercícios, retornando uma estrutura de treino com exercícios, séries, repetições, descanso e carga sugerida.
• Prioridade: Alta
• Atores: Aluno, Personal Trainer
• H1: Dado um aluno com preferências preenchidas indicando cinco equipamentos disponíveis, Quando o usuário aciona a geração de treino, Então a proposta usa somente exercícios do catálogo compatíveis com esses equipamentos e respeita a duração preferida, E todo exercício proposto existe no catálogo, sem nome inventado.

RF-IAGE-002: Geração de proposta de plano alimentar

• Descrição: geração equivalente para plano alimentar, considerando objetivo, número de refeições por dia, restrições alimentares, preferências e as metas de macronutrientes vigentes.
• Prioridade: Alta
• Atores: Aluno, Nutricionista
• H1: Dado um aluno com meta de duas mil calorias e a preferência de quatro refeições por dia, Quando o usuário aciona a geração do plano alimentar, Então a proposta traz quatro refeições e o somatório de calorias fica dentro de mais ou menos dez por cento da meta, E nenhum alimento listado nas restrições do aluno aparece na proposta.

RF-IAGE-003: Prévia editável obrigatória antes de salvar

• Descrição: nenhuma geração assistida é gravada diretamente. O resultado é sempre uma prévia em que o usuário reordena, altera, adiciona e remove itens, e só então salva ou descarta.
• Prioridade: Essencial
• Atores: Aluno, Profissional
• H1: Dado uma geração concluída, Quando o usuário abre a prévia, Então nenhum registro de ficha ou de plano existe ainda no banco, E após remover um item, alterar outro e salvar, o registro criado contém exatamente o conteúdo editado, E ao descartar a prévia nenhum registro é criado.

C.14 Módulo pain, painéis e relatórios

RF-PAIN-001: Painel do aluno

• Descrição: painel de entrada do aluno, desenhado primeiro para o celular, com o bloco de treino em primeiro lugar e no maior destaque da tela: o atalho de retomar a sessão em andamento quando houver (RF-TREI-010), e na ausência dela o treino do dia com a ação de iniciar. Abaixo do bloco de treino, e sempre depois dele, vêm o resumo nutricional do dia, a última medida, a sequência, o calendário de atividade, as conquistas, o indicador de completude do perfil enquanto ele não estiver completo (RF-ENGA-006) e os atalhos das ações frequentes.
• Prioridade: Essencial
• Atores: Aluno
• H1: Dado um aluno com ficha ativa, refeições e medidas registradas, Quando abre o painel em tela de trezentos e setenta e cinco pixels de largura, Então todos os blocos aparecem empilhados, sem rolagem horizontal, E o bloco de treino é o primeiro da pilha, acima de nutrição, medidas, sequência, calendário, conquistas e completude, E cada bloco exibe o dado real do aluno ou o próprio estado vazio, nunca um valor de exemplo, E existindo sessão em andamento o atalho de retomar ocupa o topo do bloco de treino, no lugar da ação de iniciar.

RF-PAIN-002: Painel do Personal Trainer

• Descrição: painel com a carteira de alunos vinculados, estado de cada vínculo, alerta de aluno inativo, mensagens não lidas, solicitações de ficha abertas e atalho para criar ficha e avaliação.
• Prioridade: Essencial
• Atores: Personal Trainer
• H1: Dado um Personal Trainer com quatro alunos ativos e uma solicitação de ficha aberta, Quando abre o painel, Então vê os quatro alunos e o indicador de uma solicitação aberta, E nenhum aluno de outro profissional aparece na lista.

RF-PAIN-003: Painel do Nutricionista

• Descrição: painel próprio da especialidade, com a carteira de pacientes, aderência às metas por paciente no período, planos alimentares vigentes e pacientes sem registro de refeição recente.
• Prioridade: Alta
• Atores: Nutricionista
• H1: Dado um nutricionista com três pacientes, Quando abre o painel, Então vê os três com a aderência às metas dos últimos sete dias e o plano alimentar vigente de cada um, E o painel exibido é o da especialidade nutricional, não o de outra especialidade.

RF-PAIN-004: Painel do Médico

• Descrição: painel clínico com a carteira de pacientes, últimos exames enviados, prescrições vigentes, anamneses preenchidas e alertas de exame sem leitura.
• Prioridade: Alta
• Atores: Médico
• H1: Dado um médico com dois pacientes e um exame enviado ontem por um deles, Quando abre o painel, Então o exame aparece na lista de exames recentes com o nome do paciente e a data, E exames de pacientes sem vínculo ativo com ele não aparecem.

RF-PAIN-005: Painel do Fisioterapeuta

• Descrição: painel de reabilitação com a carteira de pacientes, últimas sessões, evolução da dor por região corporal, o plano da próxima sessão registrado no último atendimento de cada paciente e pacientes sem sessão recente.
• Prioridade: Alta
• Atores: Fisioterapeuta
• H1: Dado um fisioterapeuta com um paciente que teve três sessões no joelho esquerdo, a última delas com plano da próxima sessão preenchido, Quando abre o painel, Então vê a evolução da dor daquela região com os três pontos na ordem das datas, E vê o plano da próxima sessão daquele paciente sem abrir o detalhe da sessão, E um paciente cuja última sessão não trouxe plano aparece sem esse trecho, em vez de exibir campo vazio, E um paciente sem sessão nos últimos trinta dias aparece marcado como sem sessão recente.

RF-PAIN-006: Alerta de aluno inativo

• Descrição: o painel do profissional destaca os alunos vinculados sem nenhuma atividade registrada há sete dias ou mais, considerando as quatro fontes de RN-006: sessão de treino concluída, refeição registrada, medida registrada e atividade externa, seja ela sincronizada de um serviço conectado, importada de arquivo ou registrada manualmente.
• Prioridade: Alta
• Atores: Profissional
• H1: Dado um profissional com um aluno cuja última atividade foi há oito dias e outro cuja última foi há dois dias, Quando abre o painel, Então apenas o primeiro aparece na lista de inativos, E ao registrar uma atividade nova esse aluno sai da lista na próxima abertura do painel, E um terceiro aluno cuja única atividade nos últimos oito dias foi uma atividade externa, sem nenhuma sessão, refeição ou medida no sistema, não aparece na lista de inativos.
• Notas: este requisito é violado quando um aluno com atividade em qualquer uma das quatro fontes dentro da janela aparece como inativo. A atividade externa conta aqui e não conta na sequência de dias (RN-005), porque este alerta responde se a pessoa sumiu e a sequência responde se ela executou o treino prescrito no sistema.

RF-PAIN-007: Painel do Administrador

• Descrição: painel global com total de usuários por papel e especialidade, fichas, sessões e refeições dos últimos trinta dias, alunos ativos nos últimos sete dias, vínculos pendentes e volume de mensagens.
• Prioridade: Alta
• Atores: Administrador
• H1: Dado um sistema com números conhecidos de usuários e vínculos, Quando o Administrador abre o painel, Então cada indicador exibido é igual à contagem correspondente na base, E ao criar um usuário novo o total do painel aumenta em um na abertura seguinte.

RF-PAIN-008: Relatórios agregados do sistema

• Descrição: relatórios da administração com uso por módulo, evolução de cadastros, vínculos por especialidade, atividade por período e últimas medidas registradas no sistema, com filtro de período e exportação em arquivo de valores separados.
• Prioridade: Média
• Atores: Administrador
• H1: Dado o Administrador na tela de relatórios com o período dos últimos trinta dias, Quando exporta o relatório de atividade, Então o arquivo gerado contém exatamente as mesmas linhas exibidas na tela, com o mesmo período, E o total do rodapé é igual à soma da coluna correspondente.

RF-PAIN-009: Gestão de usuários pelos papéis de administração

• Descrição: a administração de usuários é uma tela só, servida aos dois papéis de administração, com as ações repartidas entre eles. O Administrador cria usuários de aluno e de profissional informando nome, e-mail, senha inicial e papel entre esses dois, busca por nome e e-mail, edita o cadastro e a especialidade e marca um registro profissional como verificado. O Super Administrador faz tudo isso e mais quatro ações que são dele: promover ou rebaixar o papel de uma conta, inclusive criar conta de Administrador; aplicar e remover o bloqueio administrativo, que é decisão da administração sobre a conta e impede a entrada de qualquer papel, com mensagem própria, guardando quem bloqueou e quando; excluir contas em definitivo (RF-CORE-008); e personificar o usuário (RF-CORE-014). O status de acesso, que é consequência do plano do aluno e restringe o uso, continua sendo atribuído em RF-PLAN-002, também pelo Super Administrador, e não se confunde com o bloqueio administrativo.
• Prioridade: Alta
• Atores: Super Administrador, Administrador
• H1: Dado o Super Administrador na tela de usuários, Quando cria um usuário com papel de profissional e especialidade médica, Então o usuário consegue entrar com a senha inicial e cai no painel clínico, E ao receber o bloqueio administrativo a entrada dele é negada com a mensagem de conta bloqueada pela administração, diferente da mensagem de conta inativa por plano, E o registro guarda quem bloqueou e quando, E ao remover o bloqueio ele volta a entrar sem precisar de senha nova, E um aluno com status de acesso inativo por plano, mas sem bloqueio, continua entrando e alcançando perfil, plano e leitura do próprio histórico, o que prova que os dois controles são independentes, E um Administrador na mesma tela cria e edita o mesmo usuário com sucesso, E as quatro ações privativas pedidas por esse Administrador (mudar papel, bloquear, desbloquear e excluir em definitivo) são negadas nas quatro, sem efeito no registro, E o controle correspondente não é oferecido a ele na interface, esconder sendo a consequência da negação e nunca o controle em si.
• Notas: este requisito é violado quando bloquear pela administração e desligar o acesso por plano produzem o mesmo efeito ou a mesma mensagem; quando um Administrador consegue qualquer uma das quatro ações privativas acima; ou quando um Administrador consegue promover a si mesmo. O bloqueio administrativo vale para qualquer papel, inclusive profissional, Administrador e outro Super Administrador; o status de acesso por plano existe apenas para o aluno. A senha inicial das contas criadas por esta tela é definida por quem cria e trocada pelo próprio usuário depois; as três contas de topo da plataforma seguem a semente de RN-010 e não nascem por esta tela. Exceção nominal ao alcance do bloqueio administrativo, e é uma só: o bloqueio impede a entrada de qualquer papel, e personificar não é entrar (RF-CORE-014), por isso uma conta bloqueada pela administração continua podendo ser personificada pelo Super Administrador, com o bloqueio intacto e sem que a personificação o levante. Fora dessa exceção o bloqueio não tem nenhuma outra, e a lista fecha aqui.

RF-PAIN-010: Seleção em massa e ação em lote nas listas

• Descrição: as listas de treinos, de histórico de sessões, de usuários e de exercícios oferecem caixa de seleção por linha e seleção de todas as linhas exibidas pelo filtro corrente. Com uma seleção ativa, a barra de ação em lote mostra a quantidade selecionada e as ações disponíveis para o papel: desativar, para os papéis que desativam; mudar papel e excluir em definitivo, apenas para o Super Administrador. A ação em lote não amplia capacidade nenhuma: cada registro selecionado passa pela mesma verificação de permissão da ação individual.
• Prioridade: Média
• Atores: Aluno, Personal Trainer, Médico, Fisioterapeuta, Nutricionista, Super Administrador, Administrador
• Pré-condições: lista com ao menos uma linha visível ao papel.
• Saída: registros afetados, mensagem com a contagem e entradas de auditoria.
• H1: Dado o Administrador na lista de exercícios com um filtro que exibe doze linhas, Quando marca a seleção de todas e aplica a desativação, Então exatamente doze exercícios ficam inativos, a mensagem informa doze registros afetados e existem doze entradas de auditoria, uma por registro, E a mesma seleção de doze aplicada por um aluno, por um profissional ou por um Administrador não oferece a exclusão em definitivo e, forçada, é negada nos doze, sem afetar nenhum registro, E quando um dos doze selecionados está fora do alcance do papel a operação recusa aquele registro e conclui os demais, informando quantos foram afetados e quantos foram recusados.
• Notas: este requisito é violado quando a contagem informada difere do número de registros efetivamente alterados, quando o número de entradas de auditoria difere do número de registros afetados, ou quando a ação em lote executa algo que a ação individual do mesmo papel nega. A exclusão em definitivo continua exclusiva do Super Administrador (RF-CORE-008 e RN-008). A seleção não atravessa a paginação: selecionar todas alcança as linhas exibidas pelo filtro corrente, e o total é sempre mostrado antes da confirmação.

RF-PAIN-011: Administração dos parâmetros de operação

• Descrição: o Super Administrador consulta e altera, por tela, todo parâmetro de operação

do catálogo, cada um com nome, descrição, tipo, valor corrente e faixa aceita. O valor novo passa a valer para o próximo uso do sistema, sem publicação nova e sem migração. Valor fora da faixa é recusado com a faixa na mensagem. Parâmetro que o catálogo declara técnico aparece na tela em leitura, com o motivo, e não oferece edição. O Administrador lê a tela e não escreve nela, mesma fronteira de RF-PLAN-001.

• Prioridade: Alta
• Atores: Super Administrador (escrita), Administrador (leitura)
• Pré-condições: sessão ativa do papel correspondente.
• Saída: valor gravado, mensagem de confirmação e entrada de auditoria com valor antigo e

valor novo.

• H1: Dado um parâmetro X com valor corrente V e faixa F, Quando o Super Administrador grava

o valor V2 dentro de F pela tela, Então o próximo uso do sistema que consome X respeita V2 sem publicação nova e sem migração, E a trilha de auditoria registra a alteração com autor, momento, valor antigo V e valor novo V2, E o mesmo parâmetro gravado com valor fora de F é recusado com a faixa na mensagem e o valor corrente permanece V, E a mesma gravação tentada pelo Administrador é negada pela rota direta, não apenas escondida na tela.

• Notas: este requisito é violado quando existe valor de operação lido de literal no código

em vez do ponto único, quando a alteração não aparece na trilha, quando a tela esconde a ação sem a rota negar, ou quando o valor novo só vale depois de reiniciar o serviço. Materializa ADR-012 e L.2, que até aqui eram decisão e seção sem requisito e por isso não reprovavam nada. A ficha do catálogo está no card ART-CFG-01 do Inventário; o ponto único de leitura e o verificador estão em ART-CFG-02. Para listas_fechadas, editar é acrescentar item, renomear rótulo, reordenar e desativar ou reativar; o valor canônico do item não muda e item nunca é apagado, porque registros já gravados o referenciam; item desativado some das opções novas e continua exibido nos registros que o têm; toda lista mantém ao menos um item ativo.

Extensão (Inspeção, {AUD-10}, 2026-09-30): modelos de e-mail. Os onze e-mails transacionais passam a ser um parâmetro de forma tabular deste catálogo, em tabela própria, com a mesma regra de listas_fechadas: cada modelo tem assunto e corpo editáveis pelo Super Administrador em /admin/emails, com variáveis entre chaves duplas escolhidas de uma lista fechada por modelo, e o Administrador lê sem escrever. Os onze assuntos que {AUD-08} pôs em mfit.parametro migram para o modelo, e o corpo sai do código. O servidor valida na gravação e na pré-visualização: variável fora da lista do modelo é recusada com a variável nomeada na mensagem; a variável de endereço é obrigatória no corpo dos onze modelos; assunto de 3 a 120 caracteres em linha única; corpo de 20 a 5000 caracteres, texto simples em parágrafos, com o HTML derivado pelo servidor e todo valor escapado, sem HTML escrito pelo operador. Cada gravação cria uma versão nova, numerada e imutável, que passa a ser a vigente, com entrada de auditoria de antes e depois; restaurar uma versão antiga cria uma versão nova com o conteúdo dela. A pré-visualização renderiza assunto e corpo com dados de demonstração pelo mesmo renderizador do envio, sem enviar e sem gravar. O próximo e-mail renderizado usa a versão vigente, e o registro do envio guarda o número da versão usada. Catálogo das variáveis por modelo e ficha no card ART-CFG-03 do Inventário. Esta extensão é violada quando existe corpo de e-mail transacional como texto literal no código, quando um modelo aceita gravar variável fora da sua lista ou corpo sem a variável de endereço, quando uma gravação não produz versão nova, ou quando o Administrador grava pela rota direta.

H1 dos modelos de e-mail ({AUD-10}): Dado o modelo de recuperação de senha na versão vigente N, Quando o Super Administrador grava em /admin/emails um assunto e um corpo novos que usam apenas variáveis da lista do modelo, Então a versão N+1 passa a ser a vigente e a trilha registra antes e depois, E o próximo e-mail de recuperação renderizado sai com o assunto e o corpo novos e as variáveis substituídas, sem publicação nova e sem reiniciar o serviço, E um corpo com variável fora da lista, ou sem a variável de endereço, é recusado com a variável nomeada na mensagem e a vigente continua N+1, E a pré-visualização devolve o texto renderizado sem gravar versão e sem enviar e-mail, E a mesma gravação tentada pelo Administrador é negada pela rota direta.

Nota (Inspeção, gate {AUD-10}, drift 2, 2026-09-30): a variável de endereço é recusada no assunto, com a variável nomeada na mensagem, e continua obrigatória no corpo dos onze modelos. Nos modelos de confirmação de conta, recuperação de senha e acesso criado ela carrega o endereço de uso único em claro, que no assunto iria para o cabeçalho, a notificação do celular, a pré-visualização do cliente de e-mail e o registro do servidor de correio. A Extensão acima passa a ser violada também quando um modelo aceita gravar a variável de endereço no assunto.

C.15 Módulo inte, integrações e portabilidade

RF-INTE-001: Importação de atividade registrada em aplicativo externo

• Descrição: o aluno importa um arquivo de exportação de aplicativo de saúde ou de relógio, e o sistema cria registros de atividade externa com data, tipo, duração, calorias e passos, marcados com a origem. Também é possível registrar uma atividade externa manualmente.
• Prioridade: Média
• Atores: Aluno
• H1: Dado um arquivo de exportação com dez atividades, Quando o aluno o importa, Então dez registros de atividade externa são criados com data, tipo e duração e aparecem no calendário de atividade marcados com a origem externa, E reimportar o mesmo arquivo não cria registro duplicado, mantendo dez.
• Notas: a sincronização automática com os aplicativos nativos está fora do escopo (ADR-011).

RF-INTE-002: Exportação dos dados do titular

• Descrição: o aluno solicita a exportação completa dos dados dele em formato aberto, incluindo perfil, treinos, sessões, refeições, medidas, avaliações, exames, prescrições, sessões de reabilitação e anamneses, com os arquivos anexados.
• Prioridade: Alta
• Atores: Aluno, Administrador
• H1: Dado um aluno com registros em todas as categorias, Quando solicita a exportação, Então recebe um pacote com um arquivo estruturado por categoria mais os anexos, E cada categoria presente na base do aluno tem o mesmo número de registros no pacote e na base.

RF-INTE-003: Conexão e desconexão de serviço de atividade

• Descrição: o aluno conecta a conta dele num serviço de atividade que oferece interface em nuvem com autorização delegada, escolhendo o serviço na tela de integrações e autorizando no site do próprio serviço. Voltando autorizado, a conta aparece conectada, com a data da conexão e a permissão concedida. O aluno desconecta quando quiser; desconectar descarta a credencial guardada, interrompe as sincronizações seguintes e mantém tudo que já entrou no histórico. Os serviços conectáveis são Strava, Fitbit, Garmin e Polar, e a lista é configuração da administração.
• Prioridade: Média
• Atores: Aluno
• Pré-condições: serviço habilitado na configuração; o aluno tem conta no serviço.
• Entrada: escolha do serviço e autorização concedida no site dele.
• Saída: conta conectada, com credencial cifrada, permissões e data.
• H1: Dado um aluno sem nenhuma conta conectada, Quando escolhe um dos serviços habilitados e conclui a autorização no site dele, Então a tela de integrações passa a exibir aquela conta como conectada, com a data e as permissões concedidas, E a sincronização seguinte cria no histórico exatamente as atividades que o serviço entregou no período, E ao desconectar a conta a credencial guardada é descartada, nenhuma sincronização nova acontece para ela e as atividades já importadas continuam no histórico, marcadas com a origem, E uma autorização recusada ou abandonada no site do serviço não cria conta conectada nenhuma.
• Notas: este requisito é violado quando existe conta marcada como conectada sem credencial válida, quando desconectar apaga histórico, ou quando uma sincronização acontece depois da desconexão. A credencial nunca chega ao navegador e nunca aparece em tela; a tela mostra apenas o serviço, o estado e a data.

RF-INTE-004: Sincronização periódica e idempotente da atividade externa

• Descrição: para cada conta conectada, o sistema busca periodicamente as atividades novas do serviço, mais os totais de passos e as medições de frequência cardíaca do período, e cria os registros de atividade externa correspondentes. A mesma atividade nunca entra duas vezes, porque a chave de deduplicação é a origem mais o identificador da atividade no serviço. Quando a autorização expira ou é revogada do lado do serviço, a conta passa a precisar de nova autorização, o aluno é avisado e o histórico permanece.
• Prioridade: Média
• Atores: Aluno
• Pré-condições: conta conectada e válida.
• Saída: registros de atividade externa com origem, tipo, data, duração, calorias, passos, distância e frequência cardíaca média e máxima quando o serviço as fornecer.
• H1: Dado um aluno com uma conta conectada cujo serviço tem doze atividades no período, Quando a sincronização roda, Então são criados doze registros de atividade externa com a origem nomeando o serviço, E rodando a sincronização de novo no mesmo período o total permanece doze, sem duplicata, E uma atividade nova no serviço faz o total passar a treze na execução seguinte, E quando a autorização é revogada do lado do serviço a conta passa ao estado que exige nova autorização, o aluno recebe a notificação e os treze registros continuam existindo.
• Notas: este requisito é violado quando a mesma atividade aparece duas vezes, quando uma falha de autorização apaga histórico, ou quando a conta continua marcada como válida depois de a autorização ter sido revogada. Campo ausente no serviço fica vazio no registro, nunca zero. A cadência da rotina está em K.1.

RF-INTE-005: Atividade externa no calendário e no acompanhamento

• Descrição: a atividade externa, venha da conexão automática, do arquivo importado ou do registro manual, aparece no calendário de atividade do aluno e na leitura do profissional vinculado, sempre identificada pela origem e distinguível da sessão de treino executada dentro do sistema.
• Prioridade: Média
• Atores: Aluno, Profissional
• H1: Dado um aluno com uma sessão de treino concluída no sistema e duas atividades externas no mesmo dia, Quando abre o calendário de atividade, Então o dia aparece marcado com as três, cada uma identificada pela origem, E a sequência de dias considera apenas a sessão concluída no sistema, sem contar as duas externas, E o profissional vinculado enxerga as mesmas três no acompanhamento daquele aluno, E um aluno cuja única atividade nos últimos oito dias foi uma atividade externa sincronizada não aparece na lista de inativos do profissional, porque a atividade externa é a quarta fonte de RN-006.
• Notas: este requisito é violado quando a atividade externa é exibida como se fosse sessão de treino do sistema, ou quando ela passa a contar para a sequência de dias, contrariando RN-005.

C.16 Módulo ajud, guia da plataforma

RF-AJUD-001: Guia da plataforma acessível a todo papel

• Descrição: existe uma central de ajuda dentro do sistema, no topo do menu de todo papel, com um guia por módulo do sistema. Cada guia traz sete blocos: para que serve o módulo, pré-requisitos, como usar passo a passo, exemplos, problemas comuns, dicas e próximos passos. O conteúdo é escrito por papel: quem abre o guia vê a versão publicada para o papel dele.
• Prioridade: Alta
• Atores: Aluno, Personal Trainer, Médico, Fisioterapeuta, Nutricionista, Administrador
• Pré-condições: sessão autenticada; guia publicado para o par módulo e papel.
• Saída: guia do módulo, na versão publicada para o papel de quem lê.
• H1: Dado um guia publicado para o módulo de treino com conteúdo distinto para o papel Aluno e para o papel Personal Trainer, Quando um aluno abre o guia daquele módulo, Então lê o conteúdo publicado para o papel Aluno, com os sete blocos presentes, E o mesmo módulo aberto pelo Personal Trainer exibe o conteúdo do papel dele, E a entrada do guia aparece no topo do menu dos seis papéis, E um módulo sem guia publicado para aquele papel exibe o estado vazio nomeando o módulo, sem erro e sem exibir o conteúdo de outro papel.
• Notas: este requisito é violado quando um papel não alcança a central pelo menu, quando o conteúdo exibido é de papel diferente do de quem lê, ou quando um dos sete blocos não existe no guia publicado. Estrutura completa do guia no Apêndice: Catálogo do guia da plataforma.

RF-AJUD-002: Manutenção e versionamento do guia pela administração

• Descrição: o Administrador cria, edita, publica e despublica o guia de cada par módulo e papel. Cada publicação gera uma versão nova, numerada e datada, com autor; as versões anteriores permanecem consultáveis e é possível restaurar qualquer uma delas como versão nova. O leitor sempre enxerga a versão publicada corrente, nunca um rascunho.
• Prioridade: Alta
• Atores: Administrador
• Pré-condições: papel Administrador.
• Saída: versão publicada do guia, com número, data e autor.
• H1: Dado um guia na versão 1 publicada, Quando o Administrador edita o conteúdo e publica, Então nasce a versão 2 com data e autor e é ela que os leitores passam a enxergar, E a versão 1 continua consultável no histórico com o conteúdo original, E enquanto a edição está em rascunho os leitores continuam vendo a versão 1, E ao restaurar a versão 1 nasce a versão 3 com aquele conteúdo, sem apagar a versão 2, E toda operação de escrita no guia pedida por papel diferente de Administrador é negada.
• Notas: este requisito é violado quando uma publicação sobrescreve a versão anterior, quando um rascunho aparece para o leitor, ou quando um papel diferente de Administrador consegue escrever no guia.

RF-AJUD-003: Geração assistida do conteúdo do guia com revisão antes de publicar

• Descrição: o Administrador aciona a geração do conteúdo do guia de um par módulo e papel a partir da descrição do módulo, dos requisitos dele e das capacidades daquele papel. O resultado é uma prévia editável, com os sete blocos, que só vira versão publicada depois de revisada e publicada por uma pessoa.
• Prioridade: Média
• Atores: Administrador
• Pré-condições: módulo e papel escolhidos.
• Saída: prévia editável do guia, sem versão publicada.
• H1: Dado um módulo sem guia para o papel Aluno, Quando o Administrador aciona a geração, Então é apresentada uma prévia com os sete blocos preenchidos, E nenhuma versão do guia existe no banco enquanto a prévia não é publicada, E após editar dois blocos e publicar, a versão criada contém exatamente o conteúdo revisado, E ao descartar a prévia nenhuma versão é criada e o guia continua sem conteúdo para aquele papel.
• Notas: este requisito é violado quando conteúdo gerado chega ao leitor sem publicação humana. Ponto registrado em M.2, sob a mesma regra de prévia obrigatória de RF-IAGE-003.

4. Requisitos Não Funcionais

D.1 Desempenho

Este requisito é violado quando qualquer linha da tabela é medida acima do alvo em ambiente de produção com o volume de referência de D.4.

D.2 Segurança e autorização

• Autenticação por e-mail e senha com token assinado de validade curta e renovação; sessão em cookie inacessível ao script da página.
• Senha guardada apenas como derivação criptográfica com sal, nunca em texto legível.
• Autorização aplicada na camada de dados, por política por linha, e não apenas na interface. A interface esconder um botão não é controle de acesso.
• As quatro condições de leitura de dado de aluno são: ser o próprio aluno, ter vínculo ativo com ele, ter tido vínculo e ser o autor do registro, ou ser Super Administrador. Qualquer outra combinação é negada.
• O Administrador é uma quinta condição, parcial e nominal: ele lê dado de aluno em qualquer unidade apenas nas entidades não clínicas, que são nove e se nomeiam uma a uma (perfil, vínculo, ficha de treino e seus itens, sessão de treino e suas séries, solicitação de ficha, preferência de treino, acordo de cobrança, competência de cobrança e aceite de termos), e recebe negação em toda entidade das quatorze capacidades da fronteira de B.1, nomeadamente as de saúde, nutrição e corpo, mais conversa e mensagem, mais conta de integração e atividade externa, mais o registro de uso da geração assistida. Violado quando um Administrador obtém linha de qualquer entidade dessa fronteira, por qualquer caminho.
• Perfil público reduzido. O que um usuário enxerga do perfil de outro, em qualquer tela onde eles se encontram (lista de vínculos, carteira, conversa, grupo, autoria de registro), é exatamente: nome e foto; e, quando o outro é profissional, também a especialidade e o número de registro do conselho. Nenhum outro campo do perfil é servido a terceiro, nominalmente: telefone, data de nascimento, sexo, altura, identificador público de aluno, plano, status de acesso e endereço de e-mail. O corte acontece na camada de dados, com uma leitura reduzida própria, e não escondendo campo na interface. O Administrador é a exceção, e a leitura completa feita por ele segue RF-CORE-007.
• As duas entidades da classe restrita de E.1, conta_integracao e aceite_termos, respondem apenas ao titular e ao Administrador, mesmo havendo vínculo ativo. A credencial guardada em conta_integracao não é servida a ninguém, nem ao titular.
• Personificação. Assumir a visão de outro usuário é capacidade de um papel só, o Super Administrador (RF-CORE-014), sempre com início e fim na trilha de auditoria e com faixa visível na interface enquanto durar. A sessão personificada carrega as permissões do usuário personificado, nunca as de quem personifica: nenhuma categoria de dado sensível não consentida pelo titular é alcançada por esse caminho. Violado quando existe sessão de personificação sem o par de entradas de início e fim, quando a faixa não aparece, ou quando a sessão personificada alcança algo que o usuário personificado não alcançaria.
• Arquivos sensíveis apenas por endereço assinado com expiração de até quinze minutos.
• Cabeçalhos de segurança de resposta: a aplicação emite, por middleware único, os cabeçalhos X-Content-Type-Options: nosniff, X-Frame-Options: SAMEORIGIN com frame-ancestors 'self', Referrer-Policy: strict-origin-when-cross-origin, Permissions-Policy negando câmera, microfone e geolocalização, e uma Content-Security-Policy mínima cujo frame-src é exatamente a lista fechada de serviços de vídeo aceitos. Emitir no servidor é obrigação da aplicação, não do servidor web da frente: medido em 13/09/2026, produção servia seis desses cabeçalhos vindos do vhost do CloudPanel, arquivo fora do controle de versão, e não servia CSP nem Permissions-Policy. Violado quando algum desses cabeçalhos está ausente numa resposta medida diretamente da aplicação, com o servidor web da frente fora do caminho, ou quando o frame-src diverge da lista de serviços de vídeo aceitos.
• Transporte exclusivamente cifrado; conexão não cifrada é redirecionada.
• Este requisito é violado quando existe ao menos uma rota, consulta ou endereço de arquivo que devolva dado de aluno a um solicitante que não satisfaz nenhuma das quatro condições acima, quando uma das duas entidades restritas responde a profissional vinculado, ou quando uma consulta de perfil de terceiro devolve qualquer campo fora da lista do perfil público.

D.3 Disponibilidade

Disponibilidade alvo de 99,5 por cento no mês, medida por verificação externa de dois em dois minutos na página de entrada e na consulta de leitura autenticada. Janela de manutenção programada anunciada com quarenta e oito horas e realizada entre uma e cinco da manhã. Violado quando o mês fecha abaixo de 99,5 por cento fora das janelas anunciadas.

D.4 Escalabilidade prevista

Volume de referência do primeiro ano: até 5.000 alunos, 500 profissionais, 20.000 vínculos, 400.000 sessões de treino, 2.000.000 de séries registradas e 1.000.000 de refeições. O modelo de dados e os índices são dimensionados para esse volume sem particionamento. Violado quando, nesse volume, alguma consulta de lista de D.1 ultrapassa o alvo.

D.5 Auditabilidade

Toda escrita e toda exclusão em dado de aluno, toda mudança de papel, plano, status de acesso e vínculo, todo acesso administrativo a dado sensível e todo início e fim de personificação geram entrada de auditoria com autor, papel do autor, ação, entidade, identificador, aluno quando houver, valor anterior, valor novo, momento e, quando a escrita aconteceu sob personificação, o par personificador e personificado. A trilha é acrescida e nunca alterada, com retenção mínima de cinco anos, e a leitura dela é servida apenas ao Super Administrador. Violado quando existe uma operação dessas classes sem entrada correspondente, ou quando uma entrada existente pode ser alterada ou removida por qualquer papel.

D.6 Conformidade e proteção de dados

• Base legal declarada por finalidade, com consentimento específico por categoria de dado sensível de saúde (RF-CORE-010).
• Papéis definidos: a Modulareasy opera a plataforma, e o profissional de saúde vinculado é quem trata o dado do paciente dele no exercício da profissão. A plataforma é ferramenta de acompanhamento, não prontuário nem registro clínico oficial, e não assume a responsabilidade profissional pelo registro clínico, que continua com quem atende (RF-CORE-012). Isso não reduz a obrigação da plataforma sobre o dado que ela guarda: consentimento por categoria, isolamento, auditoria, segregação de arquivo e atendimento ao titular valem integralmente, e é justamente por não ser prontuário que a retenção segue o prazo de acompanhamento declarado abaixo, e não o prazo de guarda de prontuário.
• Direitos do titular atendidos: acesso e portabilidade (RF-INTE-002), correção (RF-CORE-004), revogação de consentimento e eliminação a pedido, executada pelo Super Administrador com registro na auditoria. O princípio do menor privilégio sobre dado de saúde é aplicado também dentro da própria administração: o papel de operação do dia (Administrador) não alcança categoria de saúde, nutrição ou corpo de aluno nenhum (B.1, RF-CORE-007), e o chamado que precisa desse dado sobe ao Super Administrador.
• Retenção: dado sensível de saúde mantido enquanto houver relação e por cinco anos após o encerramento, prazo após o qual é anonimizado.
• Violado quando existe categoria de dado sensível gravada sem consentimento registrado daquela categoria, ou quando um pedido de eliminação do titular não pode ser executado e comprovado.

D.7 Acessibilidade

Contraste mínimo de 4,5 para 1 em texto comum, navegação completa por teclado nos fluxos de entrada, cadastro, execução de treino, registro de refeição e chat, rótulo associado a todo campo de formulário e alternativa textual em toda imagem informativa. Violado quando a verificação automatizada de acessibilidade acusa erro de contraste, rótulo ausente ou imagem informativa sem alternativa em qualquer tela desses cinco fluxos.

D.8 Internacionalização

N/A: português do Brasil e unidades métricas apenas, sem previsão de segundo idioma ou segunda moeda.

D.9 Observabilidade

Registro estruturado de erro de servidor e de cliente com identificador de correlação por requisição, painel de erros com taxa por rota, e alerta quando a taxa de erro de uma rota passa de um por cento em quinze minutos.

D.10 Cadastro progressivo

Apenas nome, e-mail e senha são obrigatórios no cadastro do aluno, e o profissional acrescenta especialidade e registro. Todo o restante nasce vazio e é preenchido quando o usuário quiser. Nenhuma tela do sistema pode exigir o preenchimento de um campo opcional como condição para uso, exceto o consentimento da categoria correspondente. Violado quando existe uma tela que bloqueia a navegação por campo de perfil não preenchido.

5. Modelo de Dados

O checklist de provisionamento de cada entidade está no companheiro Inventário de Artefatos, seção de entidades.

E.1 Entidades e relações

Identidade e acesso

Relação e comercial

Treino

Nutrição

Saúde e evolução

Comunicação e engajamento

Ajuda

As dezesseis entidades de dado de aluno cobertas nominalmente por RF-CORE-006, legíveis pelo titular, pelo profissional vinculado e pelo Administrador, são: ficha_treino, sessao_treino, refeicao, plano_alimentar, meta_nutricional, preferencia_treino, medida_corporal, foto_progresso, anamnese, avaliacao_fisica, exame, prescricao, sessao_reabilitacao, atividade_externa, mensagem e acordo_cobranca.

Duas entidades de aluno ficam numa classe mais restrita, legíveis apenas pelo titular e pelo Administrador, e nunca por profissional vinculado: conta_integracao, por guardar credencial de acesso a serviço de terceiro, e aceite_termos, por ser registro jurídico do usuário e não dado de acompanhamento. Do que está em conta_integracao, o profissional vinculado enxerga somente o efeito, que são as atividades externas já importadas; a credencial não sai do servidor em nenhuma hipótese, nem para o titular.

Nota (Inspeção, {AUD-11}, 2026-09-30): as entidades sob consentimento por categoria (RF-CORE-010, RN-001) são exatamente estas, cada uma com a sua categoria: exame (exame), prescricao (prescrição), anamnese (anamnese), avaliacao_fisica e medida_corporal (avaliação física), sessao_reabilitacao (sessão de reabilitação), foto_progresso (foto de progresso), e refeicao, meta_nutricional e plano_alimentar (nutrição), com refeicao_alimento e plano_refeicao seguindo a linha pai. São dez entidades que decidem acesso por categoria, todas sensíveis: a escrita exige o consentimento vigente da categoria e a leitura do profissional vinculado passa pela visibilidade da categoria. A lista é violada quando qualquer uma dessas entidades é marcada como não sensível ou sem categoria, ou quando é lida por profissional sem o consentimento do titular.

Oito entidades de dado de aluno, hoje sem coluna de desativação, ganham o mesmo par de colunas ao nascer: desativado_em (momento, anulável) e desativado_por (referência a usuario), nulo significando ativo; a linha desativada sai das listas de trabalho por filtro e continua consultável no histórico, como RN-008 exige. São elas: refeicao, medida_corporal, exame, prescricao, sessao_reabilitacao, anamnese, avaliacao_fisica e foto_progresso. Em ficha_treino e em plano_alimentar, que já têm status, o card dono declara se inativo passa a valer nesse mesmo status ou se a entidade ganha as duas colunas como as demais. Em vinculo, a forma já existe: estado = 'inativo' mais encerrado_em e encerrado_por.

Nota (gate {F4-03}, Drift 2, 2026-09-30): plano_alimentar usa o status existente como coluna de desativação, no molde de ficha_treino; quem desativou e quando fica na trilha. A ficha de {ART-ENT-05} foi corrigida (correção da ficha, nunca do requisito): plano_alimentar (id, aluno_id, autor_id, titulo, descricao, status, criado_em, atualizado_por, atualizado_em), com status ativo ou inativo (E.3) e índice (aluno_id, status); plano_refeicao (id, plano_id, ordem, nome, horario, notas, alimentos), com alimentos em documento [{nome, quantidade, calorias}] validado no banco, unicidade (plano_id, ordem), índice (plano_id) e exibição por horario e depois ordem.

Nota (Inspeção, gate {F5-02}, Drift 5, 2026-10-01): a ficha de avaliacao_fisica foi corrigida (correção da ficha, nunca do requisito). Sai "cálculos derivados": RN-004 os define como calculados e não digitados, e um total guardado é cópia que envelhece (precedente da refeição). Entram especialidade_autor (nula quando o autor é o próprio aluno) e os pares de dobra cutânea. data é o momento do registro, gravado pelo banco e nunca informado pelo cliente. A desativação segue RN-008. A ficha completa está em {ART-ENT-06} do Inventário de Artefatos.

Nota (Inspeção, gate {F5-05}, Drifts 2 e 7, 2026-10-06): a linha de prescricao da tabela acima é corrigida (correção da ficha, nunca do requisito) por duas decisões. Primeira: a tabela nasce COM observacoes e SEM explicação gerada; a coluna da explicação em linguagem simples é entregue por {F5-10}, dono de RF-SAUD-010, e não por {F5-05}. Segunda: a "duração" deixa de ser uma coluna de texto e vira três colunas: duracao_quantidade (inteiro maior que zero, anulável), duracao_unidade (dias, semanas ou meses, anulável, com restrição no banco, constante estrutural e não lista editável) e uso_continuo (verdadeiro ou falso, falso por padrão), com a restrição de que ou a quantidade e a unidade existem juntas e uso_continuo é falso, ou uso_continuo é verdadeiro e as duas são nulas. A linha passa a ser: aluno, autor, especialidade do autor, diagnóstico, medicamentos, posologia, duração (quantidade, unidade e uso contínuo), data da prescrição, observações, criado em, desativado em e desativado por. A vigência não é coluna guardada: calcula-se na leitura (Nota de RF-SAUD-005).

Nota (Inspeção, gate {F5-06}, Drifts 2, 4 e 6 e migração 0062, 2026-10-06): a linha de sessao_reabilitacao da tabela acima é corrigida (correção da ficha, nunca do requisito) por três decisões. Primeira: a tabela nasce SEM a explicação gerada, cuja coluna é entregue por {F5-10}, dono de RF-SAUD-010. Segunda: a região deixa de ser texto livre e passa a ser um item da lista fechada editável regiao_corporal, porque a região é o agrupamento da série de dor de {F7-10} e um texto livre parte essa série (L.2). Terceira: entram especialidade_autor (nula quando o autor é o próprio aluno, ou fisioterapeuta), observacoes e criado_em (gravado pelo banco e exigido igual a agora na política). A linha passa a ser: aluno, autor, especialidade do autor, região (item da lista regiao_corporal), tratamento realizado, exercícios realizados, notas de amplitude de movimento, notas de progresso, plano da próxima sessão, dor antes e dor depois (inteiros de zero a dez, com a restrição espelhada no banco), duração em minutos (de 1 a 300, com a restrição espelhada no banco), data, observações, criado em, desativado em e desativado por. A sessão não se edita: o banco concede atualização somente às colunas de desativação e a exclusão é só do Super Administrador (RN-009, RN-008). A migração 0062 é a única deste card: a categoria e o ponto sessao_reabilitacao já existem (migrações 0012 e 0050) e nenhum valor de enumeração é acrescentado. A ficha completa está em {ART-ENT-06} do Inventário de Artefatos.

A dimensão de limite "espaço de armazenamento de anexos" (L.1) mede o tamanho somado dos arquivos de exame e de foto_progresso; não existe entidade própria de anexo. A dimensão "uso mensal de geração assistida" ainda não tem entidade correspondente neste bloco; ver ADR-016 (a confirmar).

E.2 Diagrama conceitual

erDiagram
    usuario ||--o| perfil_aluno : "é"
    usuario ||--o| perfil_profissional : "é"
    perfil_profissional ||--o{ vinculo : "inicia"
    perfil_aluno ||--o{ vinculo : "aceita"
    perfil_aluno ||--o{ consentimento : "concede"
    plano_plataforma ||--o{ perfil_aluno : "define limites de"
    vinculo ||--o| acordo_cobranca : "tem"
    acordo_cobranca ||--o{ competencia_cobranca : "gera"
    exercicio ||--o{ ficha_item : "compoe"
    perfil_aluno ||--o{ ficha_treino : "possui"
    ficha_treino ||--o{ ficha_item : "contem"
    ficha_treino |o--o{ ficha_treino : "duplicada de"
    ficha_treino ||--o{ sessao_treino : "executada em"
    sessao_treino ||--o{ sessao_serie : "registra"
    perfil_aluno ||--o| preferencia_treino : "declara"
    perfil_aluno ||--o{ solicitacao_ficha : "solicita"
    perfil_aluno ||--o{ refeicao : "registra"
    refeicao ||--o{ refeicao_alimento : "contem"
    perfil_aluno ||--o{ meta_nutricional : "tem"
    perfil_aluno ||--o{ plano_alimentar : "recebe"
    plano_alimentar ||--o{ plano_refeicao : "contem"
    perfil_aluno ||--o{ anamnese : "possui"
    perfil_aluno ||--o{ avaliacao_fisica : "possui"
    perfil_aluno ||--o{ medida_corporal : "registra"
    perfil_aluno ||--o{ foto_progresso : "envia"
    perfil_aluno ||--o{ exame : "possui"
    perfil_aluno ||--o{ prescricao : "recebe"
    perfil_aluno ||--o{ sessao_reabilitacao : "realiza"
    perfil_aluno ||--o{ atividade_externa : "importa"
    perfil_aluno ||--o{ conta_integracao : "conecta"
    conta_integracao ||--o{ atividade_externa : "sincroniza"
    usuario ||--o{ aceite_termos : "aceita"
    perfil_aluno ||--o{ conquista_aluno : "conquista"
    conversa ||--o{ conversa_participante : "reune"
    conversa ||--o{ mensagem : "contem"
    usuario ||--o{ notificacao : "recebe"
    usuario ||--o{ auditoria : "produz"
    guia_modulo ||--o{ guia_versao : "versiona"

guia_modulo e guia_versao não têm relação com aluno nem com profissional: são conteúdo global do produto, como o catálogo de exercícios.

E.3 Estados e transições

Vínculo

Estado inicial: pendente. Terminais: recusado, cancelado, inativo. Transição proibida: pendente para inativo direto, e ativo para pendente. A especialidade do profissional não é guarda de transição nenhuma: o aluno tem quantos vínculos ativos couberem no limite do plano dele, inclusive vários da mesma especialidade (RF-VINC-004).

Competência de cobrança

Ficha de treino e plano alimentar: ativo e inativo, sem outras transições.

Solicitação de ficha

Estado inicial: aberta. Terminais: atendida e recusada. Transição proibida: qualquer volta a aberta, e qualquer par não listado acima.

Sessão de treino

Apenas a sessão concluída conta para sequência, calendário, conquistas e progressão. Apenas a sessão em andamento é oferecida para retomada (RF-TREI-010). A sessão abandonada é terminal.

Guia da plataforma: rascunho e publicado. Publicar cria uma versão nova e mantém as anteriores; despublicar retira o guia da leitura sem apagar versão.

6. Interfaces

F.1 Interfaces de usuário

O catálogo completo de telas, com rota, papéis, elementos e estados, está no Apêndice: Catálogo de telas e no card ART-SCR do Inventário. Princípios que valem em todas:

• O aluno é desenhado primeiro para o celular, com alvo de toque mínimo confortável, ícones e imagem no lugar de texto denso.
• O profissional é desenhado primeiro para tela larga, com lista de carteira e detalhe do aluno lado a lado, e funciona no celular em coluna única.
• Toda tela declara os quatro estados: vazio, carregando, erro e sem permissão.
• Toda tela alcançável tem caminho de volta pela própria interface, sem depender do botão de voltar do navegador.
• Nenhum valor visual é fixado direto no componente; tamanho de texto e espaçamento são relativos à base do contêiner, nunca em pixel fixo.

F.2 Serviços externos consumidos

O provedor concreto de geração assistida é escolhido na abertura da construção, entre os já usados pela operação, e trocá-lo não altera nenhum requisito deste documento (ADR-008).

F.3 Interfaces expostas

N/A: o sistema não expõe interface pública para consumo por terceiros nesta especificação. A exportação de dados do titular (RF-INTE-002) é acionada pela própria interface e entrega um arquivo, não um serviço.

F.4 Interfaces entre módulos

7. Arquitetura

G.1 Stack tecnológica

G.2 Decisões de arquitetura

ADR-001: O profissional é a unidade de isolamento. Não existe camada de academia ou clínica. Cada profissional é uma unidade e o aluno pertence a tantas unidades quantos forem os vínculos ativos dele. Consequência: o isolamento não é por coluna de organização, é pela existência do vínculo, o que exige política por linha em toda entidade de dado de aluno. Alternativa descartada: coluna de organização, que criaria uma entidade sem dono no modelo de negócio.

ADR-002: O aluno é dono dos dados dele e pode se autogerir. Toda categoria que um profissional preenche pode ser preenchida pelo próprio aluno. Consequência: nenhuma entidade de dado de aluno exige vínculo para existir, apenas para ser acessada por terceiro. Alternativa descartada: exigir profissional para criar ficha ou plano, o que tornaria a plataforma inútil para quem treina sozinho.

ADR-003: Autorização na camada de dados. A permissão é aplicada por política por linha no banco, não apenas nas rotas. Consequência: uma rota esquecida não vaza dado. Alternativa descartada: verificação só na aplicação, que depende de o desenvolvedor lembrar em cada rota nova.

ADR-004: O registro profissional é validado por formato, não por consulta ao conselho. Não há serviço público, estável e uniforme para as quatro especialidades. Consequência: o formato é validado e o número fica visível ao aluno, que pode conferir; a administração pode marcar um registro como verificado manualmente. Quando o próprio profissional edita o número do registro no perfil (RF-CORE-004), o campo registro verificado volta a falso, porque um número novo nunca nasce verificado sem nova checagem da administração. Alternativa descartada: raspagem dos sites dos conselhos, frágil e sem garantia.

ADR-005: A plataforma não movimenta dinheiro, em nenhum dos dois fluxos. Nem na assinatura do aluno, nem na cobrança do profissional ao aluno. O sistema registra valores e status; o dinheiro trafega fora. Consequência: não há gateway, não há repasse e não se configura intermediação financeira regulada; em compensação, o status de pagamento depende de marcação manual. Alternativa descartada: gateway com repasse ao profissional, que traria obrigação regulatória desproporcional ao estágio do produto.

ADR-006: Ficha e plano são editáveis apenas pelo autor. Quem tem acesso e não é autor consulta, pede ajuste ou duplica. Consequência: acaba a caixa preta de "alguém mudou minha ficha", e a responsabilidade técnica sobre a prescrição fica com quem prescreveu. Alternativa descartada: edição livre por qualquer um com acesso, que já se mostrou fonte de conflito de autoria e de risco profissional.

ADR-007: Esquema único de anamnese, com registros datados. Uma tabela só, com tronco comum e seções condicionais por especialidade, e vários registros por aluno, um por ocasião de coleta, cada um com data, autor e especialidade do autor. Anamnese é um retrato do aluno num momento; a reanamnese meses depois é um registro novo, e o que mudou entre uma e outra tem valor clínico. Ao abrir uma anamnese nova, o tronco comum é pré-preenchido a partir da anterior e continua editável, o que evita redigitação sem congelar o dado. Consequência: o histórico do aluno não se fragmenta em quatro versões divergentes do mesmo dado, acrescentar uma especialidade nova é acrescentar uma seção e não uma tabela, e a evolução do histórico fica legível na linha do tempo. Alternativas descartadas: uma tabela por especialidade, que duplicaria altura, peso e histórico médico em quatro lugares; e um registro único por aluno sobrescrito a cada preenchimento, que apagaria em silêncio o quadro anterior do paciente.

ADR-008: O provedor de geração assistida é substituível. O acesso ao serviço fica atrás de uma camada interna própria, com contrato de entrada e saída definido pelo sistema. Consequência: trocar de provedor é trocar uma implementação, sem tocar em requisito nem em tela. Alternativa descartada: chamar o provedor direto das telas, que amarraria o produto a um fornecedor.

ADR-009: Dois repositórios de arquivo com políticas diferentes. Mídia de exercício é conteúdo global e público; anexo de exame, prescrição, anamnese e foto de progresso são privados e só saem por endereço assinado de validade curta. Consequência: a política de acesso não depende de acerto caso a caso. Alternativa descartada: repositório único com regra por pasta, que erra em silêncio.

ADR-010: O consentimento é por categoria e bloqueia a escrita. O aceite dos termos de uso não cobre dado sensível de saúde. Consequência: existe um ponto de bloqueio antes da primeira escrita de cada categoria, e a revogação é efetiva. Alternativa descartada: consentimento único no cadastro, que não atende à exigência de finalidade específica.

ADR-011: Atividade externa entra por interface em nuvem quando o serviço oferece uma, e por arquivo quando não oferece. A divisão é técnica, não de vontade: as plataformas de saúde do próprio aparelho (Apple Health e Samsung Health) só expõem dado a um aplicativo nativo instalado nele, e o ModularFit é uma aplicação web, então delas o caminho é o arquivo que o usuário exporta (RF-INTE-001) ou o registro manual. Já os serviços de atividade que mantêm interface em nuvem com autorização delegada (Strava, Fitbit, Garmin e Polar) são conectados pelo próprio aluno, com autorização no site do serviço, e passam a sincronizar sozinhos treinos e atividades, passos e frequência cardíaca (RF-INTE-003 e RF-INTE-004). Consequência: quem usa relógio de um desses quatro não precisa exportar nada, e quem usa só a plataforma do aparelho continua atendido pelo arquivo; a lista de serviços conectáveis é configuração, então acrescentar um quinto serviço não altera requisito nenhum. Alternativa descartada: publicar um aplicativo nativo apenas para ler as plataformas do aparelho, esforço desproporcional ao ganho nesta etapa.

ADR-012: Toda regra de negócio ajustável vive em configuração editável pela administração. Planos, limites, metas padrão, prazos de inatividade, listas fechadas, textos de consentimento e modelos de e-mail (assunto e corpo, {AUD-10}) são dados, não código. Consequência: mudar um valor comercial ou operacional não exige publicação nova do sistema.

ADR-013: Um servidor de aplicação único na frente do banco; nada de acesso direto do navegador ao banco. A stack é PostgreSQL mais um serviço em Node que concentra API, autenticação, emissão de endereços assinados de arquivo, eventos em tempo real, geração assistida, integrações e rotinas. O navegador só conhece esse serviço. As políticas por linha do banco continuam obrigatórias (ADR-003), mas como segunda camada atrás da autorização do servidor, e são escritas na forma de um único auxiliar de decisão de acesso, chamado por todas as tabelas de dado de aluno, para que exista um só lugar a auditar. Consequências: (1) a auditoria de leitura administrativa de dado sensível (RF-CORE-007) tem um ponto único de registro, o tratador da rota, coisa que um acesso direto ao banco pelo navegador não consegue registrar; (2) a sessão fica em cookie inacessível ao script (D.2), sem token no código do navegador; (3) o produto sobe com dois processos, banco e aplicação, em vez de uma dúzia; (4) a exportação do titular, a anonimização e as rotinas periódicas rodam no servidor, sem limite de tempo de execução imposto por terceiro. Alternativas descartadas: expor o banco ao navegador por uma camada automática de API com as políticas por linha como única barreira, em que uma política esquecida numa tabela de saúde vira vazamento público e a leitura não é auditável; e um serviço de identidade separado, que não cobre a autorização delegada de wearables (F.2), exigiria mais um processo e mais um segredo compartilhado, e cujos fluxos (confirmação, redefinição, bloqueio por tentativas) o próprio DRS já especifica como requisito.

ADR-014: O cadastro revela e-mail já cadastrado; a recuperação de senha não revela. No cadastro, o endereço já em uso retorna erro específico do campo, com o atalho para entrar ou recuperar a senha; na recuperação, o endereço não cadastrado retorna a mesma mensagem neutra do endereço cadastrado. Consequência: o cadastro é oráculo de existência de conta, contido por limite de tentativas por endereço de origem, configurável (RF-CORE-002). Alternativa descartada: mensagem neutra no cadastro, que deixaria o usuário sem saber por que não consegue criar a conta, num produto em que a conta não é dado sensível por si e o limite por origem já contém a enumeração em massa.

ADR-015: O usuário troca o próprio e-mail, com reconfirmação do endereço novo. O e-mail é a identidade de login e chega a mudar (troca de provedor, e-mail de trabalho que deixa de existir); sem esse caminho a conta fica presa a um endereço morto e a recuperação de senha deixa de funcionar. Consequência: a troca é um requisito próprio (RF-CORE-013), o endereço antigo continua valendo até o novo ser confirmado, e a mudança fica na trilha de auditoria. Alternativa descartada: troca só pela administração, que transforma um ato rotineiro do usuário em chamado de suporte.

ADR-016 (a confirmar): Existência e forma da entidade de uso de geração assistida. A dimensão de limite "uso mensal de geração assistida" (L.1) exige uma linha por geração, com aluno e momento, para o limite ser verificável, e essa entidade não está declarada em E.1. Duas alternativas em aberto: ela nasce agora em E.1 como tabela própria, ou permanece de fora do DRS e nasce apenas com o card {F8-05} (módulo iage, geração assistida), sob responsabilidade exclusiva dele. Nenhum requisito publicado depende desta escolha hoje: a dimensão já nasce classificada como pendente de tabela, com a forma de contagem declarada (contagem de eventos no período), e o card {F8-05} não começa sem resolver este ADR. A partir de {F1-16}, a consequência da indefinição aparece na tela do aluno: a dimensão de geração assistida é exibida como não medida enquanto a entidade não existir. Isso não muda o ADR nem bloqueia nenhum card, muda o que o dono vê ao decidir. A confirmar com o dono do produto.

ADR-017: Dois papéis de administração fixos, sem edição de permissão em tempo de execução. A administração da plataforma tem exatamente dois papéis, Super Administrador e Administrador, escritos no código e no tipo de papel do banco, e a diferença entre eles é uma lista fechada de sete capacidades (B.1). Gerir perfis e capacidades significa promover e rebaixar uma conta entre esses papéis fixos, nunca montar um papel novo nem marcar permissão a permissão numa tela. Consequência: existe um só lugar a auditar, a lista de sete, e a pergunta "quem pode o quê" tem resposta por leitura deste documento, não por consulta ao estado de um banco que muda sem deixar requisito. Quem precisa de uma combinação que não existe recebe um dos dois papéis, e a combinação nova, se for mesmo necessária, nasce como requisito. Alternativa descartada: matriz de permissão editável em tempo de execução, que transforma o controle de acesso em dado operado sem revisão, faz toda tela depender de uma consulta a mais e deixa o sistema sem resposta estável para a pergunta de quem alcança o quê.

G.3 Topologia

Aplicação multi-inquilino, instância única, banco único, isolamento lógico por política por linha. Não há separação física por profissional. O Administrador atravessa o isolamento por política própria, sempre com registro de auditoria.

G.4 Componentes

flowchart TD
    A[Navegador do aluno, celular] --> B[Servidor da aplicacao]
    C[Navegador do profissional] --> B
    D[Navegador da administracao] --> B
    B --> E[(Banco de dados com politica por linha)]
    B --> F[Autenticacao e sessao, no proprio servidor]
    B --> G[Repositorio publico de midia]
    B --> H[Repositorio privado de dado sensivel, endereco assinado]
    B --> I[Camada interna de geracao assistida]
    I --> J[Provedor externo de geracao]
    B --> K[Eventos em tempo real, emitidos pelo servidor]
    K --> A
    K --> C
    B --> L[Envio de e-mail transacional]
    B --> M[Servicos de atividade, autorizacao delegada]

Nota (ADR-013): F, G, H, I e K são papéis dentro do servidor de aplicação B, não processos separados; os processos reais são dois, aplicação (B com os papéis F, G, H, I, K) e banco (E).

8. Validação e Qualidade

O checklist completo de validação, com um item por requisito na etapa interna e um item por jornada na etapa com usuários reais, está no companheiro Plano de Testes.

I.1 Estratégia de testes

I.2 Critérios de aceitação

O critério de aceitação de cada requisito é o H1 dele. Um requisito sem H1 aprovado não entra em produção, e um H1 que não consegue reprovar não é critério.

I.3 Testes unitários

Cobertura obrigatória em toda função de cálculo. Cada fórmula de RN-004 tem ao menos um caso com valor conhecido e um caso de borda (divisor zero, campo ausente).

I.4 Testes de integração

Para cada uma das dezesseis entidades de dado de aluno, um par de casos: o profissional vinculado obtém o registro e o profissional não vinculado recebe negação, o que dá trinta e dois casos. Somam-se dois casos por entidade da classe restrita, conta_integracao e aceite_termos, em que tanto o vinculado quanto o não vinculado recebem negação, o que dá mais quatro. O conjunto fecha quando os trinta e seis casos passam, mais o caso do perfil público, que confere campo a campo o que a consulta de terceiro devolve.

I.5 Inspeção visual

Obrigatória em toda entrega que toque tela, em largura de 375 e de 1440, com registro de imagem. A verificação de proporção de imagem compara a proporção renderizada com a proporção natural do arquivo, e não o julgamento visual.

I.6 Teste exploratório

Obrigatório nos fluxos de consentimento, exame, prescrição, exclusão e cobrança, por serem os de maior consequência.

9. Entrega e Evolução

A fila completa de construção, tarefa a tarefa, com o que implementar, como verificar e o aceite, está no companheiro Roadmap de Implementação.

J.1 Ondas de entrega

A ordem abaixo obedece à dependência técnica e, dentro do que a dependência permite, ao foco do produto: o núcleo de musculação vem primeiro. Por isso a onda 2 entrega o catálogo de exercícios e o vínculo, a onda 3 entrega o treino inteiro (ficha, execução, retomada, histórico e progressão), e só depois disso entram dieta (onda 4) e saúde clínica (onda 5). Um sistema com as ondas 1 a 3 no ar já resolve o problema central; um sistema com dieta e saúde antes do treino não resolveria nada do que o produto se propõe a resolver.

J.2 Dependências entre requisitos

• Nenhum requisito de dado de aluno é construído antes de RF-CORE-006 e RF-CORE-009 estarem verificados.
• Nenhuma escrita de categoria sensível é liberada antes de RF-CORE-010.
• RF-DIET-001 a RF-DIET-005 dependem de RF-CORE-010 com a sétima categoria, nutrição ({AUD-11}); plano_alimentar (RF-DIET-003) nasce já sob ela.
• RF-TREI-001 depende de RF-EXER-001 e de RF-VINC-002.
• RF-ENGA-002 a RF-ENGA-005 dependem de RF-TREI-005.
• RF-IAGE-001 depende de RF-TREI-008, RF-SAUD-002 e RF-EXER-001.
• RF-COBR-002 depende de RF-COBR-001.
• RF-PAIN-006 depende de RF-TREI-005, RF-DIET-001 e RF-SAUD-007.
• RF-TREI-010 depende de RF-TREI-005 e de RF-PAIN-001, por exibir o atalho no painel e na lista.
• RF-EXER-005 depende de RF-EXER-001 e RF-EXER-002 e da camada interna de geração assistida (ADR-008).
• RF-AJUD-001 e RF-AJUD-002 dependem de todos os módulos que o guia descreve; RF-AJUD-003 depende também da camada interna de geração assistida.
• RF-PAIN-010 depende de RF-CORE-008, RF-CORE-009 e das listas que ela alcança (RF-TREI-007, RF-EXER-001, RF-PAIN-009).
• RF-PAIN-011 depende de RF-PAIN-009 (o papel Super Administrador, {AUD-04}) e governa os

parâmetros que RF-PLAN-001, RF-CORE-005, RF-CORE-010, RF-CORE-012, RF-EXER-001, RF-TREI-008, RF-TREI-010 e RF-CORE-014 consomem.

Definição de "verificado" nesta seção: verificado, aqui, significa que o mecanismo de decisão de acesso está em vigor e que existe o verificador que reprova toda tabela de dado de aluno sem política (RF-CORE-006), e que a trilha de auditoria imutável está em vigor com o verificador correspondente (RF-CORE-009); a partir daí cada entidade de dado de aluno nasce já coberta pelo gabarito, e o placar de casos de integração sobe com ela até fechar na Fase 8.

J.3 Riscos e mitigações

J.4 Pendências abertas de execução

1. Definição do nome comercial e do preço de cada faixa paga. Os limites de cada faixa já estão fechados no Apêndice: Catálogo de planos, com a faixa mais alta ilimitada nas seis dimensões; nome e preço são dados editáveis pela administração e não afetam requisito nenhum.

J.5 Artefatos de apoio e protótipo

O mockup navegável do sistema completo, produzido após a aprovação deste documento e antes do início da construção, é a referência visual aprovada e o guia do desenvolvimento. Cada tela é construída seguindo a página correspondente do mockup, e divergência visual na implementação se resolve consultando o mockup.

Mockup aprovado em 05/09/2026: Mapa do mockup, com as 37 telas do catálogo em tema escuro e claro, larguras 375 e 1440 e os estados vazio, carregando, erro e sem permissão. Páginas: Manual de marca, Públicas, Aluno, Aluno, menu Mais, Profissional e Administrador. O manual de marca fixa símbolo, assinaturas, cores, tipografia (Oswald para títulos, Barlow para texto, JetBrains Mono para números) e componentes; os tokens e a especificação dos componentes acompanham o mockup e são a fonte do sistema de design da construção. A barra de ferramentas no topo de cada página do mockup (estado, tema, largura) é instrumento de revisão e não faz parte do produto.

10. Operação em Produção

K.1 Rotinas operacionais

K.2 Monitoramento e alertas

Verificação externa da página de entrada e de uma leitura autenticada a cada dois minutos; alerta quando a taxa de erro de uma rota passa de um por cento em quinze minutos; alerta quando a fila de e-mail acumula mais de cinquenta itens; alerta quando o tempo de resposta do percentil 95 de qualquer rota de lista passa do alvo de D.1 por trinta minutos.

K.3 Cópia de segurança e recuperação

Cópia diária completa do banco com retenção de trinta dias e cópia semanal com retenção de doze meses; cópia dos repositórios de arquivo é um empacotamento do volume próprio, na mesma cadência do banco (diária com retenção de trinta dias, semanal com retenção de doze meses); teste de restauração trimestral em ambiente separado, com registro do tempo de recuperação, é o card F8-11. Objetivo de ponto de recuperação de vinte e quatro horas e objetivo de tempo de recuperação de quatro horas.

11. Configurabilidade e Entitlement

L.1 Política de entitlement

O que o aluno pode fazer é determinado pelo plano dele, e o plano é um dado editável pela administração, nunca uma condição escrita no código. As dimensões de limite são: número de vínculos ativos, número de fichas ativas, número de planos alimentares ativos, retenção do histórico visível, espaço de armazenamento de anexos e uso mensal de geração assistida. Cada dimensão aceita um número ou o valor ilimitado, e a dimensão ilimitada é aprovada sem contagem; o plano mais alto do catálogo inicial é ilimitado nas seis. Acrescentar um plano novo é criar uma linha; alterar o que um plano libera é alterar um valor.

Cada dimensão tem uma forma própria de contagem e um dono declarado: número de vínculos ativos, número de fichas ativas e número de planos alimentares ativos contam linhas em estado ativo nas respectivas entidades (vinculo, ficha_treino, plano_alimentar); espaço de armazenamento de anexos soma o tamanho dos arquivos anexados a exame e a foto_progresso, as duas entidades que hoje guardam anexo do aluno, sem entidade própria de anexo; retenção do histórico visível é uma janela de leitura sobre o histórico, não uma contagem de escrita, e por isso nunca é aplicada como limite de criação de registro, e sim na leitura do histórico de sessões de treino, pelo ponto único que serve essa leitura (card F3-07), com o valor ilimitado não filtrando nada e o número escondendo as sessões mais antigas que a janela; a janela decide quais sessões são listadas e nunca quais fatos são verdadeiros, de modo que a comparação de carga entre sessões do mesmo exercício continua sobre todo o histórico do aluno; uso mensal de geração assistida conta eventos de geração no período corrente, e a entidade que registra cada uso ainda não existe no modelo (ver ADR-016, a confirmar).

L.2 Configuração de tempo de execução

Parâmetros ajustáveis pela administração sem publicação nova: metas nutricionais padrão, prazo de inatividade do alerta, prazo de abandono da sessão de treino em andamento, conjunto de campos do indicador de completude do perfil, limite de tamanho e extensões aceitas de anexo, tamanho máximo e formatos aceitos da mídia de exercício, validade do endereço assinado, tempo de bloqueio após tentativas falhas, listas fechadas (grupos musculares, dificuldade e categoria do exercício, objetivos, nível e equipamentos das preferências de treino, tipos de exame, tipos de refeição, categorias de pose e pontos de dobra cutânea), textos e versões de consentimento, texto e versão dos termos de uso e do aviso de natureza não clínica, lista de serviços de atividade habilitados para conexão, cadência da sincronização, catálogo de conquistas e critérios, e o modelo de geração assistida em uso. Também ficam no catálogo: tamanho mínimo de senha, limite de cadastros por endereço de origem e a janela, teto da biografia do profissional, e o modelo de cada um dos onze e-mails transacionais, assunto e corpo com variáveis, em tabela própria com versões ({AUD-10}; até o fechamento dele, o assunto vive em mfit.parametro e o corpo no código). Ficam fora, como técnicos nomeados em {ART-CFG-01}: o remetente dos e-mails (marca única, L.3, e endereço autenticado no provedor de envio) e a ajuda do campo de registro (reafirma ADR-004). A ficha de cada parâmetro está no card ART-CFG do Inventário de Artefatos.

Nota (Inspeção, gate {F4-05}, Drift 2, 2026-09-30): entra no catálogo a tolerância da meta nutricional, nutricao_meta_tolerancia_pct, no grupo nutrição: número em porcentagem, valor inicial 10, faixa de 1 a 50, descrição "Faixa, para mais e para menos, em torno da meta de calorias em que o dia conta como meta atingida no acompanhamento nutricional". É regra que o dono quer ajustar sem publicação nova (ADR-012): vale na próxima leitura do acompanhamento, sem recálculo guardado. Decide o dia com meta atingida de RF-DIET-005. A ficha está no card ART-CFG-01 do Inventário de Artefatos, a entregar em {F4-05}.

Nota (Inspeção, gate {F5-01}, Drift 2, 2026-10-01): entram no catálogo dois tetos de texto da anamnese, no grupo saúde, ambos números em caracteres. anamnese_texto_curto_max_caracteres: valor inicial 200, faixa de 80 a 500, descrição "Tamanho máximo, em caracteres, de um campo de texto curto da anamnese". anamnese_texto_longo_max_caracteres: valor inicial 2000, faixa de 500 a 10000, descrição "Tamanho máximo, em caracteres, de um campo de texto longo da anamnese". São regra que o dono quer ajustar sem publicação nova (ADR-012), no molde de refeicao_nome_max_caracteres e refeicao_observacoes_max_caracteres: valem no próximo registro, e a anamnese já gravada acima do teto continua exibida. Quais campos são curtos e quais são longos está no Apêndice: Catálogo de formulários. As faixas de plausibilidade dos campos numéricos da anamnese e a escala de dor de zero a dez não são parâmetro: são limite físico e protocolo. A ficha de cada parâmetro está no card ART-CFG-01 do Inventário de Artefatos, a entregar em {F5-01}.

Nota (Inspeção, gate {F5-02}, Drifts 2 e 6, 2026-10-01): entram no catálogo dois tetos de texto da avaliação física, no grupo saúde, ambos números em caracteres. avaliacao_texto_curto_max_caracteres: valor inicial 200, faixa de 80 a 500, descrição "Tamanho máximo, em caracteres, de um campo de texto curto da avaliação física". avaliacao_texto_longo_max_caracteres: valor inicial 2000, faixa de 500 a 10000, descrição "Tamanho máximo, em caracteres, de um campo de texto longo da avaliação física". São regra que o dono quer ajustar sem publicação nova (ADR-012), no molde dos tetos da anamnese: valem no próximo registro, e a avaliação já gravada acima do teto continua exibida; cada chave diz a que se aplica, e por isso não reaproveitam os tetos anamnese_*. Quais campos são curtos e quais são longos está no Apêndice: Catálogo de formulários. As faixas de plausibilidade dos campos numéricos da avaliação não são parâmetro: são limite físico. A lista fechada ponto_dobra_cutanea nasce no card {F5-02}, com quatro itens (Tríceps, Suprailíaca, Abdominal e Coxa), editável em /admin/listas com o nome "Pontos de dobra cutânea": as listas fechadas com consumidor passam de sete para oito no fechamento. A ficha de cada parâmetro e da lista está no card ART-CFG-01 do Inventário de Artefatos, a entregar em {F5-02}.

Nota (Inspeção, gate {F5-04}, Drift 9, 2026-10-06): entram no catálogo três tetos de texto do exame, no grupo saúde, todos números em caracteres. exame_nome_max_caracteres: valor inicial 160, faixa de 80 a 500, descrição "Tamanho máximo, em caracteres, do nome de um exame". exame_resumo_max_caracteres: valor inicial 4000, faixa de 500 a 10000, descrição "Tamanho máximo, em caracteres, do resumo dos resultados de um exame". exame_observacoes_max_caracteres: valor inicial 2000, faixa de 500 a 10000, descrição "Tamanho máximo, em caracteres, das observações de um exame". São regra que o dono quer ajustar sem publicação nova (ADR-012), no molde de refeicao_nome_max_caracteres: valem no próximo registro, e o exame já gravado acima do teto continua exibido; cada chave diz a que se aplica. O mínimo de 3 caracteres do nome não é parâmetro: é regra fixa do campo. A lista fechada tipo_exame nasce no card {F5-04}, com cinco itens (Laboratorial, Imagem, Cardiológico, Funcional e Outro), editável em /admin/listas com o nome "Tipos de exame": as listas fechadas com consumidor passam de oito para nove no fechamento. O limite de tamanho do anexo (anexo_tamanho_max, faixa de 1 a 50 megabytes) segue como está e não pode passar do limite de envio do servidor da aplicação, que sobe para 51 megabytes só para este produto (ficha em {ART-INT-02}). A ficha de cada parâmetro e da lista está no card ART-CFG-01 do Inventário de Artefatos, a entregar em {F5-04}.

Nota (Inspeção, gate {F5-05}, Drifts 4, 5 e 7, 2026-10-06): entra no catálogo um teto de texto da prescrição, no grupo saúde, número em caracteres. prescricao_texto_longo_max_caracteres: valor inicial 4000, faixa de 500 a 10000, descrição "Tamanho máximo, em caracteres, de um campo de texto longo da prescrição (diagnóstico, medicamentos, posologia e observações)". É regra que o dono quer ajustar sem publicação nova (ADR-012), no molde dos tetos do exame: vale no próximo registro, e a prescrição já gravada acima do teto continua exibida. Não nasce teto curto: a duração, que seria o único campo curto, é estruturada (quantidade inteira, unidade e uso contínuo) e a posologia é texto longo; por isso o catálogo passa de 46 para 47 fichas e mfit.parametro de 41 para 42 linhas, e não para 43. A unidade da duração (dias, semanas ou meses) não é parâmetro nem lista fechada: é constante estrutural, classificada C no verificador, com restrição no banco, porque entra no cálculo da vigência; as listas fechadas com consumidor continuam nove. O aviso do receituário não é parâmetro: é texto versionado, chave aviso_receituario do ponto prescricao, publicado em /admin/textos, com o texto inicial no sentido já declarado em Fora de escopo. A ficha do parâmetro está no card ART-CFG-01 do Inventário de Artefatos, a entregar em {F5-05}.

Nota (Inspeção, gate {F5-06}, Drifts 2, 6 e 7, 2026-10-06): entra no catálogo um teto de texto da sessão de reabilitação, no grupo saúde, número em caracteres. reabilitacao_texto_longo_max_caracteres: valor inicial 4000, faixa de 500 a 10000, descrição "Tamanho máximo, em caracteres, de um campo de texto longo da sessão de reabilitação (tratamento realizado, exercícios realizados, notas de amplitude, notas de progresso, plano da próxima sessão e observações)". É regra que o dono quer ajustar sem publicação nova (ADR-012), no molde dos tetos da prescrição: vale no próximo registro, e a sessão já gravada acima do teto continua exibida. Um só parâmetro para os seis campos longos, e não dois, porque não existe campo curto; por isso o catálogo passa de 47 para 48 fichas e mfit.parametro de 42 para 43 linhas. A lista fechada regiao_corporal nasce no card {F5-06} (dezoito itens, com o lado onde há lado, mais "Outra"), editável em /admin/listas: as listas fechadas com consumidor passam de nove para dez no fechamento. É lista editável, e não constante, porque a região é o agrupamento da série de dor de {F7-10} e não regra de cálculo: acrescentar ou renomear um item não quebra nada, diferente da unidade da duração da prescrição, que entra no cálculo e por isso é constante. O que não é parâmetro: a escala de dor de 0 a 10 é constante estrutural (a escala numérica de dor) e a duração de 1 a 300 minutos é constante técnica, ambas com a restrição espelhada no banco; a data da sessão não futura usa a folga de fuso já adotada nos demais formulários. A ficha do parâmetro e da lista está no card ART-CFG-01 do Inventário de Artefatos, a entregar em {F5-06}.

L.3 Personalização por inquilino

N/A: o produto é operado sob uma marca única e o profissional não personaliza a identidade visual da plataforma. A presença do profissional para o aluno vinculado se dá pelo perfil dele (nome, especialidade, registro, foto e biografia), não por customização de marca.

12. Automação e Geração Assistida

M.1 Mapa de automações

M.2 Pontos de geração assistida

Cinco pontos, todos com prévia obrigatória antes de virar registro publicado:

Nenhum outro ponto do sistema grava conteúdo gerado sem revisão humana. Este requisito é violado quando existe no sistema um ponto de geração que publica conteúdo sem passar por uma destas cinco formas de revisão.

M.3 Sincronização entre entidades

13. Aprendizado Pós-Lançamento

N.1 Métricas de uso

Alunos ativos por semana; sessões concluídas por aluno ativo; refeições registradas por aluno ativo; proporção de fichas criadas por profissional contra criadas pelo próprio aluno; proporção de propostas geradas que são salvas depois de editadas; tempo entre convite e aceite de vínculo; abandono na execução de sessão; uso de cada módulo por papel.

N.2 Canal de retorno

Um ponto de envio de retorno dentro da aplicação, disponível a todo papel, que registra o texto, a tela de origem, o papel e a versão em uso, e cai numa fila revisada semanalmente.

N.3 Retroalimentação da especificação

Retorno recorrente ou incidente vira proposta de alteração deste documento. A alteração é aprovada antes de virar código, e o requisito alterado é republicado com o H1 correspondente ajustado. Nenhuma mudança de comportamento entra em produção sem estar escrita aqui antes.

N.4 Verificações de saúde

Página de entrada e leitura autenticada verificadas de dois em dois minutos; taxa de erro por rota; tempo de resposta do percentil 95 das rotas de lista e de escrita; ocupação do banco e dos repositórios de arquivo. Ultrapassar qualquer limite por trinta minutos abre revisão de requisito de desempenho.

14. Apêndices

Apêndice: Regras de negócio

RN-001, categorias de dado sensível e consentimento. São exatamente sete: exame, prescrição, anamnese, avaliação física (com a medida corporal), sessão de reabilitação, foto de progresso e nutrição (refeição, meta nutricional e plano alimentar, incluída pela Inspeção em {AUD-11}, 2026-09-30). Cada uma exige consentimento próprio, com finalidade declarada e versão do texto. Consentimento concedido vale até ser revogado. Revogação bloqueia escrita nova naquela categoria e retira a visibilidade dos profissionais, sem apagar o histórico, que continua acessível ao titular e ao Administrador. O campo de limitações e lesões das preferências de treino (RF-TREI-008) não é categoria de dado sensível, e a lista de sete continua fechada: ele é declaração do próprio aluno para orientar a prescrição, escrita e lida por ele, e não registro clínico produzido por profissional. Quem quiser o registro clínico usa a anamnese, que é categoria com consentimento, com restrição por especialidade (RN-003) e com armazenamento segregado. A consequência se declara em vez de se esconder: o texto de limitações é visível a todo profissional com vínculo ativo, de qualquer especialidade, sem consentimento por categoria, e a tela diz isso ao aluno antes de ele escrever.

Nota (Inspeção, {AUD-11}, drift 6, 2026-09-30): onde esta regra diz que o histórico revogado continua acessível "ao titular e ao Administrador", vale o que RF-CORE-010 e a fronteira de B.1 dizem: o histórico revogado continua acessível ao titular e ao Super Administrador. O Administrador não lê dado clínico, e a nutrição é dado clínico pela mesma fronteira (B.1 e RF-CORE-007).

RN-002, cadastro progressivo. Obrigatórios no cadastro: nome, e-mail e senha para o aluno; mais especialidade e número de registro para o profissional. Todo o restante nasce nulo. Nenhuma tela impede o uso por campo opcional vazio.

RN-003, visibilidade cruzada entre especialidades. Por padrão, todo profissional com vínculo ativo enxerga todas as categorias consentidas do aluno, independentemente da especialidade dele, conforme a intenção de acompanhamento integrado. O aluno pode restringir uma categoria a especialidades específicas na tela de privacidade, e a restrição vale imediatamente. O padrão é um parâmetro de configuração e pode ser invertido pela administração sem alteração de código.

Nota (Inspeção, {AUD-11}, drift 7, 2026-09-30): quem está fora da restrição escolhida pelo aluno não lê nem escreve a categoria. A restrição vale imediatamente para as duas operações, porque o profissional não pode gravar o que não pode ler; na categoria nutrição isso se aplica à meta nutricional (e ao plano alimentar, em {F4-03}). Ver a Nota de RF-CORE-010, que substitui a leitura de que a restrição só governa a leitura, anotada em {F1-12}.

RN-004, fórmulas dos cálculos derivados.

Campo de entrada ausente resulta em cálculo não exibido, nunca em zero.

Nota (Inspeção, gate {F5-03}, Drifts 2 e 4, 2026-10-06): o texto de RN-004 não muda. (1) Constantes de literatura, não parâmetro de negócio: a frequência cardíaca máxima como 220 menos a idade (Fox, 1971), o índice de massa corporal (Quetelet, adotado pela OMS), a relação cintura quadril (OMS, 2008) e as cinco zonas de intensidade, de 50 a 60, 60 a 70, 70 a 80, 80 a 90 e 90 a 100 por cento da frequência máxima (ACSM), são constantes de literatura com fonte citada. Não têm tela de edição, e mudar qualquer uma delas é mudar esta regra, por decisão registrada, e não por configuração. Entram no verificador de parâmetros como exceção da classe C, nomeada e com a fonte. (2) Não exibido: o número some e a linha diz que não foi calculado e o que informar; quando falta a altura, "não calculado: informe a altura"; nunca zero. A regra é violada quando uma dessas constantes aparece como parâmetro editável ou como literal fora da exceção C nomeada, ou quando um cálculo sem insumo aparece como zero.

RN-005, sequência de dias. Conta dias de calendário consecutivos, no fuso do usuário, em que existe ao menos uma sessão concluída. Um dia sem sessão zera a contagem. Atividade externa importada conta para o calendário e não conta para a sequência.

RN-006, inatividade do aluno. Aluno é inativo quando a data da última atividade registrada, considerando exatamente quatro fontes, sessão de treino concluída, refeição registrada, medida registrada e atividade externa (sincronizada de serviço conectado, importada de arquivo ou registrada manualmente), é anterior em sete dias ou mais à data corrente. Quem treinou pelo relógio treinou: a atividade externa conta para o alerta de inatividade, ainda que não conte para a sequência de dias (RN-005), porque o alerta responde "esta pessoa sumiu?" e a sequência responde "esta pessoa executou o treino prescrito aqui?".

RN-007, competência de cobrança. Acordo mensal gera uma competência por mês decorrido desde o início, com vencimento no dia contratado; quando o mês não tem o dia, vence no último dia do mês. Acordo quinzenal gera competência a cada quinze dias corridos. Acordo avulso gera competência única. Não se geram competências de mês futuro.

RN-008, exclusão e desativação. Excluir em definitivo é exclusivo do Super Administrador. Desativar é a única remoção disponível a aluno e profissional, mantém o registro no histórico e na auditoria e o retira das listas de trabalho. Exclusão definitiva de um aluno pelo Super Administrador remove os registros dele e mantém as entradas de auditoria, anonimizadas: anonimizar significa manter a linha da trilha com o vínculo pessoal desfeito (autor_id e aluno_id nulos, identificação não reconstituível), nunca apagar a entrada. A exclusão da conta do usuário esbarra hoje em seis referências sem ON DELETE para usuario(id) (auditoria.autor_id, auditoria.aluno_id, vinculo.profissional_id, vinculo.aluno_id, vinculo.encerrado_por e usuario.bloqueado_por) e é assunto de RF-PAIN-009 e da rotina de retenção da Fase 8, não do mecanismo de remoção por entidade.

RN-009, autoria e edição. Só o autor do registro e o Administrador editam ficha de treino, plano alimentar, avaliação física, anamnese, exame, prescrição e sessão de reabilitação. Quem tem leitura e não é autor pode consultar, pedir ajuste e duplicar quando o tipo permitir.

Nota (Inspeção, gate {F5-01}, Drift 4, 2026-10-01): para a anamnese, a edição do autor é a desativação. O texto de RN-009 não muda e segue valendo para ficha de treino, plano alimentar, avaliação física, exame, prescrição e sessão de reabilitação. A anamnese é um retrato datado (ADR-007) e nenhum campo dela se edita: o autor e o Super Administrador só podem desativá-la, o que a mantém no histórico e na auditoria (RN-008), e a correção é uma nova coleta (RF-SAUD-001). Quem tem leitura e não é autor continua só consultando.

Nota (Inspeção, gate {F5-02}, Drift 3, 2026-10-01): para a avaliação física, como para a anamnese, a edição do autor é a desativação. Esta Nota corrige a leitura da Nota anterior, que mantinha RN-009 valendo para a avaliação física: o texto de RN-009 não muda e segue valendo para ficha de treino, plano alimentar, exame, prescrição e sessão de reabilitação. A avaliação física é um retrato datado, e editá-la reescreveria em silêncio o "anterior" de toda comparação já feita (RF-SAUD-002): o autor e o Super Administrador só podem desativá-la, o que a mantém no histórico e na auditoria (RN-008), e a correção é uma nova avaliação. O "Administrador" de RN-009 é, aqui, somente o Super Administrador (fronteira de B.1). Quem tem leitura e não é autor continua só consultando.

Nota (Inspeção, gate {F5-04}, Drift 7, 2026-10-06): para o exame, como para a anamnese e a avaliação física, a edição do autor é a desativação. Esta Nota corrige a leitura das Notas anteriores, que mantinham RN-009 valendo para o exame: o texto de RN-009 não muda e segue valendo para ficha de treino, plano alimentar, prescrição e sessão de reabilitação. O exame é um registro datado e o anexo é prova de um momento; editar nome, tipo, data, resumo ou anexo reescreveria em silêncio o que o aluno e os profissionais já leram. O autor e o Super Administrador só podem desativá-lo, o que o mantém no histórico e na auditoria (RN-008), e a correção é um novo exame. O "Administrador" de RN-009 é, aqui, somente o Super Administrador (fronteira de B.1). Quem tem leitura e não é autor continua só consultando.

Nota (Inspeção, gate {F5-05}, Drift 1, 2026-10-06): para a prescrição, como para a anamnese, a avaliação física e o exame, a edição do autor é a desativação. Esta Nota corrige a leitura da Nota anterior, que mantinha RN-009 valendo para a prescrição: o texto de RN-009 não muda e segue valendo para ficha de treino, plano alimentar e sessão de reabilitação. A prescrição é um registro datado, e o que ela diz (diagnóstico, medicamentos, posologia e duração) já foi lido pelo aluno e pelos profissionais; editar reescreveria em silêncio uma conduta médica. O autor e o Super Administrador só podem desativá-la, o que a mantém no histórico e na auditoria (RN-008), e a correção é uma nova prescrição. O "Administrador" de RN-009 é, aqui, somente o Super Administrador (fronteira de B.1). Quem tem leitura e não é autor continua só consultando, e o banco concede atualização somente às colunas de desativação.

Nota (Inspeção, gate {F5-06}, Drift 4, 2026-10-06): para a sessão de reabilitação, como para a anamnese, a avaliação física, o exame e a prescrição, a edição do autor é a desativação. Esta Nota corrige a leitura da Nota anterior, que mantinha RN-009 valendo para a sessão de reabilitação: o texto de RN-009 não muda e segue valendo para ficha de treino e plano alimentar. A sessão é um registro datado do atendimento, e o que ela diz (tratamento, exercícios, progresso, plano e as duas medidas de dor) já foi lido pelo paciente e pelos profissionais; editar reescreveria em silêncio a série de dor de {F7-10}. O autor e o Super Administrador só podem desativá-la, o que a mantém no histórico e na auditoria (RN-008), e a correção é uma nova sessão. O "Administrador" de RN-009 é, aqui, somente o Super Administrador (fronteira de B.1). Quem tem leitura e não é autor continua só consultando, e o banco concede atualização somente às colunas de desativação.

RN-010, contas de topo da plataforma. A semente do sistema cria exatamente três contas com o papel de Super Administrador, uma por operador da plataforma, e nenhuma outra conta nasce com esse papel. A senha de cada uma segue o padrão de operação (nome do operador, produto, ano e sufixo fixo) e não exige troca na primeira entrada, por serem contas de operação e não de usuário final. O registro de qual conta pertence a quem e a senha vigente de cada uma vivem no arquivo de credenciais do projeto, fora do repositório de código e fora de qualquer documento publicado. A semente é idempotente: rodar de novo não cria conta repetida, não rebaixa papel e não sobrescreve senha já trocada. Conta de topo não se cria pela tela de administração de usuários (RF-PAIN-009), e promover uma quarta conta a Super Administrador é ato deliberado de um Super Administrador, registrado na trilha de auditoria como qualquer mudança de papel.

Apêndice: Catálogo de formulários

Cadastro de profissional

Máscaras: Personal Trainer 000000-G/UF; Médico 000000/UF; Fisioterapeuta 00000-F; Nutricionista 0000/UF. O campo visível é só o registro com a máscara; a unidade federativa nunca é digitada nem selecionada à parte. Ação no envio: cria conta com papel de profissional e status ativo; o envio do e-mail de confirmação é a tarefa {F1-07} e este cadastro não envia nem simula esse envio. Mensagens: sucesso leva ao painel do profissional (/pro/painel); os painéis por especialidade são Fase 7. Erro por campo indica o formato esperado; e-mail já usado indica o campo de e-mail. Idioma: português do Brasil.

Exercício do catálogo

Ação no envio: cria ou atualiza o exercício global e o publica para todos. Pré-condição: papel Administrador. Pós-condição: exercício disponível na busca de todos os usuários. Erros comuns e dicas de execução aparecem na tela do exercício e na execução da sessão, abaixo das instruções, e ficam ocultos quando vazios, sem deixar espaço morto.

O vídeo é sempre endereço, nunca arquivo enviado; a lista de serviços de vídeo aceitos é fechada e vive num ponto único do código, e essa mesma lista alimenta o frame-src da Política de Segurança de Conteúdo, porque divergir as duas produz o defeito silencioso de vídeo que salva e não toca. "Arquivo direto" significa endereço https que aponta para um arquivo de vídeo, exibido em elemento de vídeo, nunca em quadro embutido. A imagem aceita os formatos fechados png, jpeg, webp e gif (animação coberta por gif e webp animado, sem conversão nem recodificação); SVG é recusado sempre, porque é documento executável e o repositório público serve na origem do produto sem sessão. Violado quando um vídeo é aceito como arquivo enviado, quando um endereço de vídeo fora da lista fechada é aceito no salvamento, ou quando um arquivo SVG é aceito como imagem de exercício por qualquer caminho.

Item da ficha de treino

Ação no envio: acrescenta ou atualiza o item da ficha. A observação do item aparece junto do exercício durante a execução da sessão, para quem executa ler sem abrir outra tela.

Preferências de treino do aluno

São vinte e seis equipamentos, nomeados como o público de academia os chama, para que o aluno reconheça o que tem à disposição sem traduzir termo técnico. A lista é fechada na tela e editável pela administração (parâmetro listas_fechadas, L.2); acrescentar ou renomear um equipamento é alterar essa lista, não o requisito.

Anamnese, tronco comum e seções por especialidade

Cada preenchimento cria um registro datado (RF-SAUD-001 e ADR-007). O tronco comum de uma anamnese nova nasce pré-preenchido com os valores da anamnese anterior do aluno, todos editáveis; as anamneses anteriores permanecem intactas.

Tronco comum, coletado a cada ocasião: dados pessoais (idade, sexo, altura, peso), queixa principal, histórico médico (histórico geral, histórico cirúrgico, histórico familiar, medicamentos em uso, alergias), hábitos de vida (tabagismo, consumo de álcool, qualidade do sono, horas de sono, nível de estresse, nível de atividade física, histórico de atividade física), objetivos (objetivos do aluno, notas sobre estilo de vida) e observações gerais.

Ação no envio: cria um registro novo de anamnese do aluno, com data, autor, especialidade do autor, o tronco comum como ficou nesta ocasião e a seção da especialidade de quem preencheu. Nenhum registro anterior é alterado. Pré-condição: consentimento da categoria anamnese concedido. Mensagens: a tela lista as anamneses do aluno da mais recente para a mais antiga, com data, autor e especialidade, e oferece a leitura de qualquer uma; ao abrir uma anamnese nova, indica de qual data veio o tronco pré-preenchido.

Nota (Inspeção, gate {F5-01}, Drift 1, 2026-10-01), ficha dos 46 campos da anamnese: tipo, obrigatoriedade e teto de cada campo, que a lista acima nomeia e não completa. C é texto curto, com o teto do parâmetro anamnese_texto_curto_max_caracteres; L é texto longo, com o teto de anamnese_texto_longo_max_caracteres (L.2); número aceita vírgula como separador decimal.

Todos os 46 campos são opcionais (RN-002), mas o envio exige ao menos um campo preenchido: uma anamnese vazia não é coleta e é recusada com o código anamnese_vazia (422). Campo fora desta ficha é recusado. O texto é aparado nas pontas e texto vazio vale ausente. Tabagismo, consumo de álcool, qualidade do sono, nível de estresse e nível de atividade física são texto curto, sem lista fechada nova; virar lista depois é acrescentar por migração, decisão separada. As faixas numéricas são limite físico, não parâmetro. Quem preenche cada seção: o profissional, o tronco e somente a seção da própria especialidade, com vínculo ativo nela; o aluno, o tronco e as seções das especialidades com as quais não tem vínculo ativo (Nota de RF-SAUD-001). A anamnese não se edita: a correção é nova coleta e o autor e o Super Administrador só a desativam (Nota de RN-009).

Avaliação física

Os quatro pontos de dobra cutânea são o protocolo padrão do sistema e não uma limitação do modelo: a lista de pontos é parâmetro de configuração (listas_fechadas, L.2), então acrescentar um quinto ponto é acrescentar uma linha, sem alterar requisito. Todo campo da avaliação é opcional isoladamente; o que a valida é ter ao menos uma seção preenchida.

Nota (Inspeção, gate {F5-02}, Drift 1, 2026-10-01), ficha dos campos da avaliação física: tipo, faixa e teto de cada campo, que a tabela acima nomeia e não completa, sem editar requisito. C é texto curto e L é texto longo, com os tetos dos parâmetros avaliacao_texto_curto_max_caracteres e avaliacao_texto_longo_max_caracteres (L.2). Números aceitam vírgula, e a faixa de cada número é limite físico, não parâmetro.

• Anamnese resumida (8 campos): queixa L, objetivo_avaliacao C, historico_lesoes L, historico_medico L, medicamentos_em_uso L, estilo_vida L, historico_atividade_fisica L, observacoes L.
• Cardiovascular (6 campos): idade_anos inteiro de 0 a 120 (acréscimo: é o insumo da frequência cardíaca máxima de RN-004 e do H1 de RF-SAUD-003, o mockup já o traz nesta seção, e é a idade no momento da avaliação, digitada, e não derivada do perfil), fc_repouso_bpm inteiro de 20 a 250, pa_sistolica_mmhg inteiro de 50 a 300, pa_diastolica_mmhg inteiro de 20 a 200, teste_cardiovascular C, resultado_cardiovascular decimal.
• Antropometria (6 campos mais os pontos de dobra): peso_kg decimal de 1 a 500, altura_cm inteiro de 50 a 300, cintura_cm decimal de 20 a 300, quadril_cm decimal de 20 a 300, metodo_percentual_gordura C, percentual_gordura decimal de 1 a 75; dobras_mm com uma entrada por item ATIVO da lista ponto_dobra_cutanea, decimal de 1 a 100, em milímetros. O percentual é digitado, porque RN-004 não tem fórmula dele.
• Neuromuscular: testes_forca, até 10 itens { teste C, carga_max_kg decimal de 0 a 1000, repeticoes_max inteiro de 0 a 1000 }, com nome de teste único na avaliação; teste_flexibilidade C; resultado_flexibilidade decimal de -100 a 200.
• Aeróbico (6 campos): teste_aerobico C, vo2_estimado decimal de 1 a 100, tempo_seg inteiro de 0 a 86400 (a tela mostra e aceita mm:ss), distancia_m inteiro de 0 a 100000, teste_resistencia C, resultado_resistencia decimal.
• Biotipo (2 campos): classificacao_somatotipica C, observacoes_biotipo L.
• Método do percentual de gordura, classificação somatotípica e nomes de teste são texto curto: não nasce nenhuma lista fechada além da de pontos de dobra (L.2).

Todos os campos são opcionais (RN-002), mas o envio exige ao menos um campo preenchido, que é a leitura operacional de "ao menos uma seção preenchida": avaliação vazia é recusada com o código avaliacao_vazia (422). Campo fora desta ficha é recusado com campo_desconhecido (400), e ponto de dobra inativo ou inexistente é recusado com erro nomeado (400). data, autor_id e especialidade_autor não vêm do cliente: vêm do banco e da sessão. Esta ficha é violada quando um campo aceita valor fora da faixa, quando um campo fora da ficha é gravado, quando uma avaliação sem nenhum campo preenchido é gravada, ou quando um ponto de dobra fora da lista ativa é gravado.

Medida corporal

Treze métricas numéricas com data: peso em quilogramas, percentual de gordura, peitoral, cintura, quadril, ombros, pescoço, braço direito, braço esquerdo, coxa direita, coxa esquerda, panturrilha direita e panturrilha esquerda, as onze últimas em centímetros. Todas opcionais, ao menos uma obrigatória para salvar. Mais um campo de observação (texto, até 500 caracteres, opcional), para o contexto da medição, por exemplo o horário, o estado de jejum ou quem mediu. Ação no envio: cria o registro datado e atualiza o gráfico de evolução e a variação em relação à medição anterior.

Foto de progresso

Ação no envio: guarda a imagem no repositório privado e acrescenta a foto à galeria daquela categoria. Pré-condição: consentimento da categoria foto de progresso. A comparação lado a lado acontece dentro de uma mesma categoria, porque comparar a foto de frente com a de costas não mostra evolução nenhuma.

Exame

Ação no envio: cria o exame, guarda o anexo no repositório privado e notifica todos os Médicos com vínculo ativo naquele aluno. Pré-condição: consentimento da categoria exame.

Nota (Inspeção, gate {F5-04}, Drifts 5, 8, 9 e 11, 2026-10-06), ficha do exame: (1) Data: a data do exame é informada pelo usuário e não pode ser futura, com a mesma folga de fuso horário dos demais formulários de data; o momento do registro é gravado pelo banco e travado na política, nunca informado pelo cliente. (2) Tetos de texto: o nome (mínimo de 3 caracteres, que é regra fixa), o resumo e as observações têm teto editável pela administração (exame_nome_max_caracteres, exame_resumo_max_caracteres e exame_observacoes_max_caracteres, em L.2), e a tabela acima mostra os valores iniciais (160, 4000 e 2000) e L.2 traz as faixas. (3) Tipo: a lista editável tem cinco itens iniciais (Laboratorial, Imagem, Cardiológico, Funcional e Outro), é a nona lista fechada com consumidor e nasce no card {F5-04}. (4) Anexo: o tipo vem dos bytes e da extensão declarada, na mesma família, na forma da Nota de RF-SAUD-004; o anexo é opcional, mas o tamanho, o formato e a chave do arquivo gravados valem tudo ou nada (sem anexo, nenhum dos três existe). (5) Aviso aos Médicos: a notificação aos Médicos vinculados, citada na Ação no envio, é entregue no card {F6-05} e não em {F5-04}; o exame grava e aparece nas listas sem ela. (6) Quem escreve: qualquer Médico com vínculo ativo ou o próprio aluno, com o consentimento da categoria exame; o exame não se edita (Nota de RN-009).

Prescrição

Campos: diagnóstico (texto longo, obrigatório), medicamentos (texto longo, obrigatório), posologia e instruções (texto longo, obrigatório), duração do tratamento (texto livre, obrigatório), data da prescrição (data, obrigatória, não futura), observações (texto longo, opcional). Ação no envio: cria a prescrição, notifica o aluno e exibe o aviso de que não substitui o receituário oficial. Pré-condição: papel Médico com vínculo ativo, consentimento da categoria prescrição.

Nota (Inspeção, gate {F5-05}, Drifts 3 a 8, 2026-10-06), ficha da prescrição: (1) Duração estruturada: o campo "duração do tratamento" da linha acima não é texto livre: é a quantidade inteira de 1 a 999 (teto constante técnica C, proteção do cálculo de data, não regra de negócio) mais a unidade (dias, semanas ou meses), ou a marca "uso contínuo", com um dos dois obrigatório, na forma da Nota de RF-SAUD-005; a posologia continua texto longo livre, e a unidade é constante estrutural com restrição no banco, não lista editável. (2) Tetos de texto: os quatro campos longos (diagnóstico, medicamentos, posologia e observações) têm um só teto editável pela administração, prescricao_texto_longo_max_caracteres (valor inicial 4000, faixa de 500 a 10000, em L.2); não existe campo de texto curto, e por isso o teto curto não nasce. (3) Data: a data da prescrição é informada pelo usuário e não pode ser futura, com a mesma folga de fuso horário dos demais formulários de data; o momento do registro é gravado pelo banco e travado na política, nunca informado pelo cliente. (4) Aviso do receituário: o aviso de que a prescrição não substitui o receituário oficial é texto versionado editável, chave aviso_receituario no ponto prescricao que já existe, publicado em /admin/textos e exibido na lista, no formulário e no detalhe; o texto não vive no componente. Não é um quarto ponto de RF-CORE-012: o aviso de natureza não clínica segue em três de quatro pontos servidos. (5) Notificação ao aluno: a Ação no envio ({ART-WF-07}) é entregue em {F6-05}, e não em {F5-05}; a prescrição grava e aparece nas listas sem ela. (6) Quem escreve: somente o Médico com vínculo ativo e com o consentimento da categoria prescrição; a prescrição não se edita (Nota de RN-009). (7) Observações: campo opcional, e a tela exibe "Não informado" quando está vazio. (8) Formulário compartilhado: a ficha da sessão de reabilitação é entregue em {F5-06}, que fecha {ART-FORM-08}.

Sessão de reabilitação

Campos: região corporal (texto, obrigatório), tratamento realizado (texto longo, obrigatório, o que o fisioterapeuta aplicou na sessão), exercícios realizados (texto longo, opcional, o que o paciente executou na sessão), notas de amplitude de movimento (texto longo, opcional), notas de progresso (texto longo, opcional, a leitura do profissional sobre a evolução), plano da próxima sessão (texto longo, opcional), dor antes (inteiro de 0 a 10, obrigatório), dor depois (inteiro de 0 a 10, obrigatório), duração em minutos (inteiro de 1 a 300, obrigatório), data (data, obrigatória, não futura), observações (texto longo, opcional).

Tratamento realizado e exercícios realizados são campos distintos de propósito: o primeiro é a conduta do profissional (por exemplo eletroterapia, terapia manual), o segundo é o que o paciente executou e pode ser comparado com o que ele executa em casa. O plano da próxima sessão aparece no painel do Fisioterapeuta (RF-PAIN-005) para abrir o atendimento seguinte sem reler a sessão inteira.

Nota (Inspeção, gate {F5-06}, Drifts 1 a 7, 2026-10-06), ficha da sessão de reabilitação: (1) Região: a região corporal não é texto: é a seleção de um item da lista fechada editável regiao_corporal (dezoito itens, com o lado onde há lado, mais "Outra"), obrigatória. A lista é editável porque a região é o agrupamento da série de dor de {F7-10} e não regra de cálculo: acrescentar ou renomear um item não quebra nenhum cálculo, ao contrário da unidade da duração da prescrição, que entra no cálculo da vigência e por isso é constante. (2) Escalas e faixas: dor antes e dor depois, de 0 a 10, são constante estrutural (a escala numérica de dor, classe C do verificador, que entra na variação dele, com a restrição espelhada no banco); a duração, de 1 a 300 minutos, é constante técnica (faixa de plausibilidade, no precedente das faixas da avaliação), também com a restrição espelhada no banco. Nenhuma das duas é parâmetro nem lista editável. (3) Data: a data da sessão é informada pelo usuário e não pode ser futura, com a mesma folga de fuso horário dos demais formulários de data; o momento do registro é gravado pelo banco e exigido igual a agora na política, nunca informado pelo cliente. O campo abre em hoje de São Paulo. (4) Tetos de texto: os seis campos de texto longo (tratamento realizado, exercícios realizados, notas de amplitude, notas de progresso, plano da próxima sessão e observações) têm um só teto editável pela administração, reabilitacao_texto_longo_max_caracteres (valor inicial 4000, faixa de 500 a 10000, em L.2); não existe campo de texto curto, e por isso o teto curto não nasce. (5) Quem escreve: o Fisioterapeuta com vínculo ativo e com o consentimento da categoria sessão de reabilitação, ou o Aluno para si; Personal Trainer, Médico, Nutricionista e Administrador não gravam; a sessão não se edita, só se desativa (Nota de RN-009). (6) Detalhe: exibe apenas o que foi preenchido e omite o campo opcional vazio, sem "Não informado". (7) Escopo do card: {F5-06} fecha o formulário compartilhado {ART-FORM-08}; a notificação de sessão criada fica em {F6-05} e a explicação em linguagem simples em {F5-10}.

Refeição registrada

Campos da refeição: tipo (seleção: Café da manhã, Lanche da manhã, Almoço, Lanche da tarde, Jantar, Ceia, Pré-treino, Pós-treino, lista editável), nome (texto, opcional), data (obrigatória), horário (opcional), observações (texto longo, opcional). Campos de cada alimento: nome (texto, obrigatório), quantidade em gramas (número, obrigatório), calorias (número, obrigatório), proteína, carboidrato e gordura em gramas (números, obrigatórios). Ação no envio: cria a refeição com os alimentos e recalcula os totais do dia contra as metas.

Nota (gate {F4-01}, Drift 8, 2026-09-29): o formulário de refeição não tem restrição de data. O Apêndice não diz "não futura" para a refeição, ao contrário de prescrição, exame e sessão de reabilitação, e a razão é o fuso: o servidor não conhece o fuso do aluno, e um corte em UTC recusaria o jantar das 22 horas. Se o dono quiser a regra, ela vira Nota neste Apêndice mais um card.

Meta nutricional

Campos: calorias (número, obrigatório, maior que zero), proteína, carboidrato e gordura em gramas (números, obrigatórios, maior ou igual a zero), todos com uma casa decimal. Ação no envio: cria uma vigência nova a partir do dia corrente de quem salva, sem alterar nem apagar as anteriores. Quem pode: o aluno titular e o Nutricionista com vínculo ativo com o aluno.

Plano alimentar

Campos do plano: título (texto, obrigatório), descrição (texto longo, opcional). Campos de cada refeição do plano (pelo menos uma): nome (texto, obrigatório), horário (hora no formato HH:MM, obrigatório), notas (texto longo, opcional). Campos de cada alimento da refeição (pelo menos um): nome (texto, obrigatório), quantidade (texto, obrigatório, porque a prática usa formas como "2 un", "200 ml", "1 col." e "à vontade"), calorias (número, obrigatório, maior ou igual a zero, uma casa decimal). Limites de texto: o título, o nome da refeição, o nome e a quantidade do alimento seguem o parâmetro de tamanho de nome em nutrição, e a descrição e as notas seguem o parâmetro de tamanho de observações em nutrição, ambos editáveis pela administração (RF-PAIN-011). Ação no envio: cria o plano ativo com as refeições e os alimentos, sujeito ao limite de planos alimentares ativos do titular, e o banco soma as calorias por refeição e por plano. Quem pode: o Nutricionista com vínculo ativo com o aluno, ou o próprio aluno quando não tem Nutricionista com vínculo ativo; os demais papéis profissionais e o Administrador não criam plano alimentar.

Nota (gate {F4-03}, Drift 1, 2026-09-30): o formulário nasce com as calorias de cada alimento obrigatórias, decisão ratificada pela Inspeção no Cenário 1 do gate. A lista de alimentos de RF-DIET-003 diz "com quantidades" e para aí; sem a caloria, o plano salvo não tem soma por refeição nem contra as metas vigentes, e o H1 de RF-IAGE-002 ("o somatório de calorias fica dentro de mais ou menos dez por cento da meta") ficaria sem como ser provado sobre o plano salvo. Custo declarado: o aluno que monta o próprio plano informa as calorias, o mesmo que {F4-01} já exige na refeição registrada. Nenhum H1, título ou RF foi editado.

Apêndice: Catálogo de planos

Estrutura editável pela administração (RF-PLAN-001). Os valores abaixo são a configuração inicial proposta e mudam por tela, sem impacto em requisito.

Regras comuns: o profissional nunca tem plano nem limite; o plano e o status de acesso do aluno são atribuídos manualmente pela administração (RF-PLAN-002); reduzir o plano de um aluno que já ultrapassou um limite não apaga nada, apenas impede criar registro novo naquela dimensão até ele voltar ao limite. O plano Completo é ilimitado nas seis dimensões: nenhuma verificação de limite recusa operação dele, e a tela do plano exibe o consumo com a palavra ilimitado no lugar do valor máximo. Ilimitado é um valor da própria dimensão no cadastro do plano, não a ausência do campo, de modo que a administração pode transformar qualquer dimensão de qualquer plano em ilimitada ou em numérica pela tela. A coluna de histórico é uma só, medida em dias; o mockup do sistema é ilustração de layout e diverge do valor exato desta tabela em alguns pontos, e é este Apêndice que manda sobre a configuração inicial.

Apêndice: Matriz Ator por Capacidade

Legenda de escopo: T todos, P apenas os próprios ou os vinculados, N nenhum. As cinco últimas linhas e as três marcadas com N na coluna Admin são as oito capacidades privativas do Super Administrador nomeadas em B.1. Contagem de capacidades por papel (célula diferente de N nas 48 linhas): Super Administrador 41, Administrador 19, Aluno 28, Fisioterapeuta 22, Personal 21, Médico 19, Nutricionista 19. A diferença de 22 entre os dois papéis de administração é o teste mecânico da escada de acesso, e ela se decompõe sem sobra: 8 capacidades privativas de governança mais 14 capacidades da fronteira de dado clínico, sendo dez por classificação e quatro por conteúdo, todas nominadas em B.1. Diferença de uma ou duas seria dois nomes para o mesmo papel.

Cada linha desta matriz é derivada do campo Atores do requisito que cria a capacidade, e a divergência entre os dois é defeito da matriz, não do requisito. As linhas de origem: registrar exame é RF-SAUD-004 (Médico e Aluno, não Personal); registrar prescrição é RF-SAUD-005 (Médico); registrar sessão de reabilitação é RF-SAUD-006 (Fisioterapeuta e Aluno); registrar avaliação física é RF-SAUD-002 (as quatro especialidades e o Aluno, por a antropometria ser prática comum); criar ficha de treino é RF-TREI-001 (Personal e Fisioterapeuta) mais RF-TREI-002 (Aluno), e as duas colunas de administração ficam em N nela, porque nenhum dos dois requisitos as nomeia e RN-009 dá à administração a edição do registro, nunca a criação; a personificação não muda a célula do Super Administrador, porque dela nenhuma capacidade nova nasce (RF-CORE-014), e pelo mesmo motivo ele já é N em duplicar ficha de terceiro; definir meta nutricional e criar plano alimentar são RF-DIET-002 e RF-DIET-003 (Nutricionista e Aluno). Solicitar ficha de treino ao profissional e atender ou recusar solicitação de ficha são RF-TREI-004, que nomeia Aluno, Personal Trainer e Fisioterapeuta; Médico e Nutricionista ficam em N nas duas pelo mesmo motivo que já estão em N na linha de criar ficha de treino, porque pedir treino a quem não prescreve treino não é capacidade, é caminho morto. O Administrador também fica em N nas duas, e o motivo fica escrito: RN-009 lhe dá a edição do registro, que é uma coisa, e responder a um pedido que o aluno dirigiu a uma pessoa determinada é outra, que requisito nenhum lhe dá; se ele atendesse, a notificação diria ao aluno que o profissional dele respondeu sem que o profissional tivesse respondido. É N por ausência de requisito, não por proibição nova, e ele continua lendo a solicitação pela mesma regra com que lê todo dado de aluno. Registrar preferências de treino e ler preferências de treino são duas linhas derivadas de RF-TREI-008, que nomeia Aluno e Profissional, e são duas porque escrever e ler são capacidades diferentes dadas a papéis diferentes: quem escreve é só o titular, e o ator Profissional está no requisito pela segunda cláusula do H1, que é de leitura. Na linha de escrita o Administrador fica em N, e o motivo fica escrito: RN-009 lhe dá a edição dos sete tipos de registro que ela nomeia, e preferência de treino não é um deles; declarar a própria preferência é ato do titular, e ninguém declara preferência no lugar de outra pessoa. É N por ausência de requisito, não por proibição nova, e ele continua lendo a preferência pela mesma regra com que lê todo dado de aluno (RF-CORE-006). Na linha de leitura as quatro especialidades ficam em P e o Administrador em T, célula por célula igual à linha de ler histórico de sessões de treino. Duplicar ficha de terceiro é derivada de RF-TREI-009, que nomeia Aluno e Profissional. Médico e Nutricionista ficam em N pelo mesmo motivo por que já estão em N na linha de criar ficha de treino, porque duplicar produz uma ficha de treino e quem não prescreve treino não passa a prescrever por copiar. O Administrador também fica em N, e o motivo fica escrito: RN-009 lhe dá a edição do registro, e duplicar não edita, cria uma ficha nova com autoria própria, e criar ficha de treino já é N para ele na linha de cima. É N por ausência de requisito, não por proibição nova, e ele continua lendo e editando a ficha pela mesma regra de sempre. As quatorze linhas em que o Super Administrador é T e o Administrador é N sem serem privativas de governança são a fronteira de dado clínico, e derivam de RF-CORE-007, que declara nominalmente o que cada papel de administração alcança depois de atravessar o isolamento. Dez entram por classificação, que são as categorias de saúde, nutrição e corpo, e quatro por conteúdo, que são conversar com vinculado, conversar entre profissionais do mesmo aluno, conectar e desconectar serviço de atividade e acionar geração assistida, porque negar a categoria e deixar aberto o canal que a transporta não nega nada. Somadas às oito privativas, fecham as 22 células em que as duas colunas divergem, e 41 menos 19 igual a 22 fecha a conta pelo outro lado. Ler preferências de treino fica FORA da fronteira, decisão escrita para ninguém supor omissão: RN-001 declara o campo de limitações e lesões nominalmente fora das categorias sensíveis. As quatro linhas acrescentadas em 2026-09-15 também derivam do campo Atores de um requisito cada: manter catálogo de planos e limites operacionais é RF-PLAN-001; bloquear e desbloquear conta e promover ou rebaixar papel são as duas metades privativas de RF-PAIN-009, separadas em duas linhas porque são capacidades diferentes negadas ao mesmo papel pelo mesmo requisito; personificar usuário é RF-CORE-014. A linha "Gerir usuários" passou a chamar-se "Gerir cadastro de usuário (criar, buscar, editar)" porque o que sobrou dela depois da separação é o cadastro, e o nome antigo prometia mais do que a linha entrega. A linha "Manter e publicar os textos da plataforma", acrescentada na mesma reconciliação, deriva de RF-CORE-012 e do bloco L.2, que declaram o texto e a versão dos termos de uso e do aviso de natureza não clínica como parâmetro ajustável pela administração, sem qualificar; pela convenção de leitura de B.1 isso alcança os dois papéis, e por isso a linha é T nas duas colunas e a divergência entre elas continua sendo 21. A linha "Manter catálogo de parâmetros de operação", acrescentada em 2026-09-15 pela reconciliação de {AUD-06}, deriva de RF-PAIN-011 e é a oitava capacidade privativa de B.1, Super Administrador T e Administrador N, o que leva a divergência total entre as duas colunas de 21 para 22 e a matriz de 47 para 48 linhas. O card TA-SEG do Plano de Testes exercita esta matriz linha a linha, e o card TA-92 confere a contagem por papel.

Nota (gate {F4-01}, Drift 5, 2026-09-29): a célula T do Super Administrador na linha "Registrar refeição" não tem rota de criação própria. RF-DIET-001 nomeia só o Aluno como ator, e a administração não cria registro em nome de terceiro sem requisito explícito (regra de autoria do gabarito de acesso). O T se cumpre por dois caminhos: a personificação (RF-CORE-014), em que o Super Administrador escreve como o titular e a trilha guarda o par personificador e personificado, e a leitura direta auditada (RF-CORE-007). Nenhuma rota de criação para o papel de administração nasce. A contagem 42 e 20 fica inalterada.

Nota (gate {AUD-09}, Drift 3, 2026-09-30): a linha "Criar ficha de treino" dizia T nas duas colunas de administração e o parágrafo de derivação desta mesma matriz dizia N; vale o parágrafo, porque RF-TREI-001 e RF-TREI-002 não nomeiam administração e RN-009 lhe dá a edição, nunca a criação. As duas células passam a N, no mesmo tratamento da linha "Duplicar ficha de terceiro". A contagem passa de 42 e 20 para 41 e 19; a divergência continua 22, com as mesmas 8 privativas e as mesmas 14 da fronteira, porque a linha era T nas duas colunas e sai das duas ao mesmo tempo. Nenhum requisito é editado e nenhum comportamento alcançável muda: a rota nega a criação à administração desde {F3-02}.

Nota (Inspeção, gate {AUD-12}, drift 3, 2026-09-30): a linha "Manter e publicar os textos da plataforma" passa a cobrir também os textos de consentimento de RF-CORE-010 (texto, finalidade e versão de cada uma das sete categorias), publicados pela mesma tela /admin/textos. A derivação da linha, que nomeava termos de uso e aviso de natureza não clínica, passa a nomear os textos de consentimento; as células (N para Aluno e profissionais, T para Administrador e Super Administrador) não mudam e a divergência continua 22, com as contagens 41 e 19 inalteradas. Não há capacidade privativa nova.

Apêndice: Catálogo de conquistas

Cada conquista é concedida uma única vez por aluno, com data. O catálogo e os critérios são editáveis pela administração (ADR-012).

Apêndice: Catálogo de telas

Nota (R-3, {F1-18}, aritmética reconciliada em 2026-09-15 pelo gate {F3-08}): a tela /admin/textos é escopada aos textos versionados (termos de uso e aviso de natureza não clínica), não aos parâmetros de {ART-CFG-01}, que hoje são vinte e oito, contados item a item no Inventário de Artefatos, que é onde essa aritmética é mantida (eram vinte e cinco na data desta nota, e os três que entraram vieram de {F2-02} e de {F2-08}). Um deles está materializado, o texto versionado de termos e aviso de natureza não clínica; os demais seguem com dono a confirmar, e o número deles não se repete aqui para não envelhecer em dois lugares.

Nota (Inspeção, gate {AUD-12}, drift 3, 2026-09-30): a Nota R-3 acima, que escopa /admin/textos aos termos de uso e ao aviso de natureza não clínica, fica superada neste ponto: a tela passa a publicar também os textos de consentimento de RF-CORE-010, num terceiro grupo "Consentimentos", sem rota nem tela nova e sem mudar a contagem deste catálogo.

Nota (gate {F3-01}, 2026-09-14): a criação de ficha de treino tem uma tela só, /fichas/nova, e ela serve aos dois papéis que criam ficha: o Profissional, que escolhe o aluno titular (RF-TREI-001), e o próprio Aluno, que cria para si (RF-TREI-002). Não nasce uma segunda tela de criação prefixada por papel: seriam dois lugares com os mesmos sete campos e a mesma validação, logo dois lugares a divergir na primeira regra que mudasse. O detalhe da ficha, /treinos/:id, é detalhe da tela /treinos e não uma rota própria deste catálogo, no mesmo tratamento já dado a /exercicios/:id. Contagem deste apêndice depois desta reconciliação: 37 linhas, sendo 36 rotas mais a central de notificações, que fica no topo de toda tela. Os cinco cartões de tela do Inventário somam 34 rotas, e as duas restantes, /redefinir e /confirmar, seguem sem ficha em cartão nenhum, pendência já registrada em {ART-SCR-04}: 34 mais 2 igual a 36.

Nota (gate {F3-03}, 2026-09-14): a edição de ficha de treino não é uma tela nova deste catálogo: é um ESTADO da tela de criação, /fichas/nova, alcançado pelo caminho /fichas/:id/editar, com os mesmos sete campos por item, a mesma validação e o mesmo componente que desenha o item. Duas telas com o mesmo formulário seriam dois lugares a divergir na primeira regra que mudasse, que é a razão já escrita na Nota anterior para a criação não se dividir por papel, e é o mesmo tratamento já dado a /exercicios/:id e a /treinos/:id, que são detalhe da tela de que nascem. A contagem deste apêndice segue em 37 linhas, 36 rotas mais a central de notificações, e os cinco cartões de tela do Inventário seguem nos mesmos placares. Os papéis da linha /fichas/nova continuam Aluno e Profissional para a criação; a edição alcança também o Administrador, porque RN-009 lhe dá a edição, nunca a criação.

Nota (gate {F3-08}, 2026-09-15): a tela de preferências de treino, /treinos/preferencias, ganha linha própria neste catálogo nesta data. Ela não existia em catálogo nenhum, embora o H1 de RF-TREI-008 comece por "Dado um aluno na tela de preferências" e o cartão {ART-FORM-03} do Inventário já declarasse que o formulário fica na tela de preferências do aluno. Ela não recebe o tratamento de detalhe e de estado que os gates de {F3-01} e de {F3-03} deram a /treinos/:id, a /exercicios/:id e a /fichas/:id/editar: o argumento daqueles era que os dois lugares teriam os mesmos campos e a mesma validação, e aqui os sete campos são outros sete, com formulário próprio, ficha própria no Inventário e navegação própria. Ela serve os dois papéis, pelo mesmo critério de /treinos, de /fichas/nova e de /treinos/historico: o profissional vinculado chega à mesma rota com o aluno na consulta, em somente leitura, e por isso é contada uma vez, em {ART-SCR-01}, e não conta de novo em {ART-SCR-02}. Contagem deste apêndice depois desta reconciliação: 38 linhas, sendo 37 rotas mais a central de notificações, que fica no topo de toda tela. Os cinco cartões de tela do Inventário passam a somar 35 rotas, e as duas restantes, /redefinir e /confirmar, seguem sem ficha em cartão nenhum: 35 mais 2 igual a 37. As Notas de {F3-01} e de {F3-03} acima registram a contagem vigente na data de cada uma e não são reescritas; a contagem válida é sempre a da Nota mais recente.

Nota (onda AUD, {AUD-04} e {AUD-05}, 2026-09-15): o catálogo passa a distinguir os dois papéis de administração. Das nove rotas de administração, sete servem aos dois papéis (/admin, /admin/usuarios, /admin/exercicios, /admin/vinculos, /admin/relatorios, /admin/guia e /admin/textos), uma é do Super Administrador apenas (/admin/auditoria) e uma é escrita do Super Administrador com leitura do Administrador (/admin/planos): 7 mais 1 mais 1 igual a 9. Nenhuma rota nova nasce desta mudança; a personificação começa dentro de /admin/usuarios e se mostra pela faixa acrescentada acima, que é cromática de toda tela, como a central de notificações, e não rota. Contagem deste apêndice depois desta reconciliação: 39 linhas, sendo 37 rotas mais as duas linhas de topo de toda tela (notificações e faixa de personificação). O número de rotas não muda, e por isso os cinco cartões de tela do Inventário seguem nos mesmos placares.

Nota (onda AUD, {AUD-06}, 2026-09-29): /admin/parametros ganha linha própria neste catálogo, para a tela que RF-PAIN-011 exige e que {AUD-06} entregou em produção (merge 29380ae). O Super Administrador escreve, o Administrador lê, e a fronteira é a mesma de /admin/planos. Das dez rotas de administração, sete servem aos dois papéis (/admin, /admin/usuarios, /admin/exercicios, /admin/vinculos, /admin/relatorios, /admin/guia e /admin/textos), uma é do Super Administrador apenas (/admin/auditoria) e duas têm escrita do Super Administrador com leitura do Administrador (/admin/planos e /admin/parametros): 7 mais 1 mais 2 igual a 10. Contagem deste apêndice depois desta reconciliação: 40 linhas, sendo 38 rotas mais as duas linhas de topo de toda tela (notificações e faixa de personificação): 38 mais 2 igual a 40. Os cinco cartões de tela do Inventário passam a somar 36 rotas, e as duas restantes, /redefinir e /confirmar, seguem sem ficha em cartão: 36 mais 2 igual a 38.

Nota (onda AUD, {AUD-07}, 2026-09-29): /admin/listas ganha linha própria neste catálogo, para a tela de manutenção das listas fechadas que {AUD-07} entrega. O Super Administrador escreve e o Administrador lê, na mesma coluna de /admin/planos e /admin/parametros. Das onze rotas de administração, sete servem aos dois papéis (/admin, /admin/usuarios, /admin/exercicios, /admin/vinculos, /admin/relatorios, /admin/guia e /admin/textos), uma é do Super Administrador apenas (/admin/auditoria) e três têm escrita do Super Administrador com leitura do Administrador (/admin/planos, /admin/parametros e /admin/listas): 7 mais 1 mais 3 igual a 11. Contagem deste apêndice depois desta reconciliação: 41 linhas, sendo 39 rotas mais as duas linhas de topo de toda tela (notificações e faixa de personificação): 39 mais 2 igual a 41. Os cinco cartões de tela do Inventário passam a somar 37 rotas, e as duas restantes, /redefinir e /confirmar, seguem sem ficha em cartão: 37 mais 2 igual a 39. Estas contagens vêm uma rota acima das da nota anterior de {AUD-06} e a substituem. A seção B.1 continua em oito capacidades privativas do Super Administrador: manter as listas e manter o catálogo de parâmetros de operação (RF-PAIN-011) são a mesma capacidade, porque listas_fechadas é um dos 32 parâmetros. A Matriz Ator por Capacidade não ganha linha.

Nota (gate {F4-01}, Drift 3, 2026-09-29): /nutricao/refeicoes/nova não ganha linha própria neste catálogo: é ESTADO da tela /nutricao, no mesmo tratamento de /fichas/:id/editar. {F4-01} entrega /nutricao em versão mínima (navegador de data, lista das refeições do dia com os quatro totais de cada uma, ação Registrar refeição, ação Desativar e o vazio do dia), no mesmo tratamento que {F3-01} deu a /treinos, e o formulário de refeição é estado dela. {F4-04} acrescenta os quatro cartões contra a meta e o total do dia.

Nota (Inspeção, {AUD-10}, 2026-09-30): /admin/emails ganha linha própria neste catálogo, para a tela dos modelos de e-mail de RF-PAIN-011 ({AUD-10}). O Super Administrador escreve e o Administrador lê, na mesma coluna de /admin/planos, /admin/parametros e /admin/listas. Das doze rotas de administração, sete servem aos dois papéis (/admin, /admin/usuarios, /admin/exercicios, /admin/vinculos, /admin/relatorios, /admin/guia e /admin/textos), uma é do Super Administrador apenas (/admin/auditoria) e quatro têm escrita do Super Administrador com leitura do Administrador (/admin/planos, /admin/parametros, /admin/listas e /admin/emails): 7 mais 1 mais 4 igual a 12. Contagem deste apêndice depois desta reconciliação: 42 linhas, sendo 40 rotas mais as duas linhas de topo de toda tela (notificações e faixa de personificação): 40 mais 2 igual a 42. Os cinco cartões de tela do Inventário passam a somar 38 rotas, e as duas restantes, /redefinir e /confirmar, seguem sem ficha em cartão: 38 mais 2 igual a 40. Estas contagens vêm uma rota acima das da nota de {AUD-07} e a substituem. A seção B.1 continua em oito capacidades privativas do Super Administrador: manter os modelos de e-mail é manter o catálogo de parâmetros de operação (RF-PAIN-011), porque os modelos são um parâmetro de forma tabular. A Matriz Ator por Capacidade não ganha linha. /admin/textos continua escopada aos termos de uso e ao aviso de natureza não clínica, e os modelos de e-mail não entram nela.

Nota (gate {F4-03}, Drift 4, 2026-09-30): /nutricao/planos continua sendo uma tela só, contada uma vez, com ESTADOS /nutricao/planos/:id (detalhe), /nutricao/planos/novo e /nutricao/planos/:id/editar (formulário único de criação e de edição), no precedente de /fichas/nova e de /fichas/:id/editar. O mockup desenha a criação em /planos/novo; essa rota não entra no catálogo, porque colidiria de leitura com /plano (Meu plano), e o Profissional chega ao formulário vindo de /alunos, com o aluno na consulta (?aluno=), sem seletor de paciente. O cartão de plano mostra "criado em" e não "período", porque nenhuma coluna guarda o fim de uma vigência. Nenhuma rota nova entra na contagem.

Nota (Inspeção, gate {F4-05}, Drift 5, 2026-09-30): /nutricao/acompanhamento?aluno= não ganha linha própria neste catálogo: é ESTADO da tela /nutricao, no mesmo tratamento de /nutricao/refeicoes/nova e de /nutricao/planos/:id, e a contagem deste apêndice não muda. O desenho segue o idioma da tela de nutrição do mockup: seletor de período (7 ou 30 dias), resumo com dias na meta, dias com registro e dias sem meta, quatro cartões de média e a lista de dias do período, cada dia levando ao dia em /nutricao?aluno=&data=. Quem usa é o Profissional (RF-DIET-005); o aluno não ganha tela. O mockup publicado não muda.

Apêndice: Catálogo do guia da plataforma

Um guia por par módulo e papel. Os módulos com guia são os treze do bloco C.1, e os papéis são os seis do bloco B.1; existe guia apenas para os pares em que o papel alcança o módulo, conforme o bloco B.5, e cada par pode estar sem guia sem que isso quebre a leitura dos demais.

Os sete blocos de todo guia, nesta ordem:

Regras do conteúdo: escrito na língua do papel (o guia do aluno não usa termo técnico, o guia do profissional é preciso); nenhum guia descreve capacidade que a matriz nega ao papel; passo a passo cita o nome exato da tela do catálogo de telas; cada versão publicada guarda número, data, autor e origem (escrita ou gerada e revisada). Estado de cada par: sem guia, rascunho ou publicado.

Apêndice: Identidade visual

Este documento cobre o ModularFit por inteiro: papéis, vínculo, planos, cobrança, catálogo de exercícios, treino, dieta, saúde, comunicação, engajamento, geração assistida, painéis, guia da plataforma, integrações e portabilidade. Requisito que não estiver aqui não é construído, e comportamento que mudar em produção volta para cá antes de virar código.