Para que serve: guardar conta, perfil por papel, consentimento e trilha de auditoria.

Nota (R-5, {F1-18}): mfit.texto_versionado, criada em {F1-18}, é configuração, não identidade: a ficha dela é {ART-CFG-01}, e ela não entra nesta ficha.

Nota (onda AUD, {AUD-04} e {AUD-05}, 2026-09-15): esta ficha passa de 6 para 7 tabelas, e a sétima é sessao_personificacao. Duas mudanças acompanham: (a) o tipo do papel em usuario ganha o valor super_administrador, sem remover nenhum valor existente, e os valores passam a ser quatro (aluno, profissional, administrador, super_administrador); (b) auditoria ganha o papel do autor e o par personificador e personificado, este último preenchido apenas nas entradas geradas sob personificação. sessao_personificacao (id, personificador_id, personificado_id, iniciada_em, terminada_em anulável enquanto a sessão dura, motivo_fim entre saída e expiração) é da classe apenas acrescida no que importa: a linha nasce no início e recebe um único UPDATE, o do fim, nunca mais; índices em (personificador_id, iniciada_em) e (personificado_id, iniciada_em); leitura servida apenas ao Super Administrador, pela mesma política que serve auditoria. Ela guarda a SÉRIE, uma linha por personificação, e não o estado corrente: saber quem personificou quem em maio é exatamente o que a trilha existe para responder. Medição feita em 15/09/2026, antes da migração: o banco tinha 3 contas com papel de administrador, todas de topo, 1 de aluno e nenhuma de profissional; logo a migração de dados de {AUD-04} toca 3 linhas e nenhuma outra. As sete tabelas desta ficha passam a ser usuario, perfil_aluno, perfil_profissional, consentimento, aceite_termos, auditoria e sessao_personificacao.

Relacionado com: RF-CORE-001 a 012; tarefas F1-03 a F1-12, F1-18 e F1-19; ART-ACS, ART-AUD.

Onde fica: banco de dados, esquema principal.

Especificação: usuario (id, nome, email único, senha derivada, papel entre aluno, profissional, administrador e super administrador, status, bloqueado_pela_administracao, bloqueado_em, bloqueado_por, email_confirmado_em, criado_em), sendo o bloqueio administrativo independente do status_acesso do plano em perfil_aluno: o bloqueio nega a entrada de qualquer papel com mensagem própria, o status de acesso restringe o uso do aluno sem impedir a entrada; perfil_aluno (id, usuario_id chave estrangeira única, identificador_publico único e curto, nascimento, sexo, altura, telefone, foto, plano_id, status_acesso); perfil_profissional (id, usuario_id único, especialidade entre as quatro, registro, uf, registro_verificado, biografia, foto); consentimento (id, aluno_id, categoria entre as seis, versao_texto, finalidade, concedido_em, revogado_em, restrito_a_especialidades, sendo esta coluna um array de mfit.especialidade_profissional, NULL significando sem restrição conforme RN-003 e array vazio proibido por restrição de tabela, porque restringir a ninguém é revogação disfarçada e disfarçada não deixa data na trilha); aceite_termos (id, usuario_id, versao_termos, versao_aviso_nao_clinico, aceito_em); auditoria (id, autor_id, autor_papel, acao, entidade, entidade_id, campo, aluno_id anulável, valor_anterior, valor_novo, momento, personificador_id e personificado_id anuláveis, preenchidos apenas nas entradas geradas sob personificação; anonimização por exclusão de conta, RN-008, zera autor_id, aluno_id, personificador_id e personificado_id mantendo o restante da linha); sessao_personificacao (id, personificador_id, personificado_id, iniciada_em, terminada_em anulável, motivo_fim entre saída e expiração). Índices: usuario.email, perfil_aluno.identificador_publico, índice único parcial consentimento(aluno_id, categoria) WHERE revogado_em IS NULL (garante a linha ativa única e serve a consulta de toda escrita de categoria sensível), mais o índice não único consentimento(aluno_id, categoria) para o histórico, que o parcial não enxerga, aceite_termos(usuario_id, aceito_em), auditoria(entidade, entidade_id, momento), auditoria(autor_id, momento), sessao_personificacao(personificador_id, iniciada_em), sessao_personificacao(personificado_id, iniciada_em). Integridade: consentimento sem duplicidade ativa por aluno e categoria, garantida pelo índice único parcial acima, e reconceder cria registro novo sem apagar o anterior; DELETE revogado de mfit_app (o histórico nunca é apagado pela aplicação) e UPDATE mantido, porque a revogação é um UPDATE, por isso consentimento não entra na classe de tabela apenas acrescida, cujo critério é a linha nunca mudar; aceite_termos apenas acrescida, um registro por aceite, sem sobrescrever aceites anteriores quando a versão do texto muda, por privilégio UPDATE/DELETE revogado de mfit_app; auditoria apenas acrescida por esse mesmo mecanismo, privilégio UPDATE/DELETE revogado do papel de aplicação mfit_app, que serve os três papéis de produto e portanto os nega sem exceção. O dono do esquema (mfit_admin) não é papel de produto, não atende requisição nenhuma e atravessa por desenho: é por ele que roda a única exceção prevista à imutabilidade, a anonimização de RN-008 (zerar autor_id e aluno_id mantendo o restante da linha), executada pela rotina de retenção da Fase 8. Escopo: usuario e perfis por dono, com a leitura de terceiro reduzida ao perfil público de D.2 (nome, foto e, para profissional, especialidade e registro); aceite_termos legível apenas pelo titular e pelo administrador, nunca por profissional vinculado; auditoria legível apenas pelo administrador, por política de RLS de SELECT restrita ao papel administrador, com a inserção mantida livre para os gatilhos e para o leitor único de acesso administrativo.

Fechamento [2026-09-29] de {AUD-05}: a sétima tabela, sessao_personificacao, está em produção (merge 3dabc30, https://fit.modulareasy.com, migrações 0034, 0035 e 0036, gates plan, qa e review verdes), medida no catálogo do banco: a tabela existe, com quatro índices (chave primária, um por personificador, um por personificado e o único parcial que impede duas personificações ativas do mesmo operador), e auditoria tem as colunas personificador_id e personificado_id. Placar da ficha: 7 de 7, ficha fechada; o 6 de 7 anterior era a ausência desta tabela.

Estado: usuario, tentativa_entrada e sessao provisionadas em F1-03; perfil_aluno, plano_plataforma (com o Gratuito) e aceite_termos provisionadas em F1-04; perfil_profissional provisionada em F1-05; foto e edição em F1-06/F5. Revogação de UPDATE/DELETE de mfit_app em auditoria e aceite_termos e RLS de leitura da auditoria restrita ao Administrador no ar desde F1-11; consentimento provisionada em produção desde F1-12 (migração 0012). RLS ligada em usuario, perfil_aluno e perfil_profissional, com a leitura de terceiro passando a ser servida pela leitura reduzida de {ART-ACS-11}, desde F1-19 (2026-09-13).

Para que serve: ser a única fonte de exercício para ficha e para proposta gerada.

Relacionado com: RF-EXER-001 a 005; tarefas F2-01 a F2-04 e F8-12; ART-FORM-02, ART-WF-15.

Onde fica: banco de dados, tabela global sem coluna de dono.

Especificação: exercicio (id, nome, grupo_muscular, equipamento, instrucoes, erros_comuns, dicas, imagem_url, video_url, imagem_largura, imagem_altura, series_padrao, reps_padrao, descanso_padrao, dificuldade, categoria, ativo, criado_por, atualizado_por, atualizado_em), com erros_comuns e dicas em texto longo, um item por linha, exibidos como blocos próprios na tela do exercício e na execução, e ocultos quando vazios. imagem_largura e imagem_altura são inteiras positivas, ambas nulas ou ambas preenchidas, medidas no servidor na ingestão a partir dos bytes do arquivo, para o front declarar aspect-ratio antes de a imagem carregar (deslocamento zero); nulas quando a imagem é endereço externo, caso em que o retângulo reservado usa a proporção padrão do mockup. Ordem de escrita: objeto no disco primeiro, linha depois, e o objeto antigo é removido apenas após o commit, para que a falha possível seja arquivo órfão e nunca linha apontando para objeto ausente. Os três enums (grupo_muscular com dez valores, dificuldade com três, categoria com dois) são canônicos, minúsculos e sem acento; o rótulo acentuado de cada valor vive num catálogo único no código, nunca escrito à mão na tela. Chave natural (grupo_muscular, lower(btrim(nome))), sem unaccent (a extensão existe mas não é IMMUTABLE, e o DRS não pede insensibilidade a acento). Índices: exercicio(grupo_muscular, dificuldade) para o filtro combinado; índice textual GIN por trigrama (pg_trgm) sobre lower(nome), para busca por pedaço de palavra. Restrição: nome único por grupo_muscular. Escopo: leitura para todo usuário autenticado, escrita apenas para administrador. imagem_url e video_url nascem como coluna aqui, ainda sem tela: são servidas por ART-FORM-02 quando F2-02 entregar a mídia.

Estado: tabela, políticas, auditoria, rotas e telas entregues em F2-01; mídia (incluindo as duas colunas de dimensão) entregue em F2-02; prévia assistida em F8-12. Filtros combináveis e contador entregues em F2-03, sem índice novo: exercicio_grupo_dificuldade_idx (nascido em F2-01) já serve os dois filtros do H1 e os quatro filtros mais a busca por Bitmap Index Scan, medido por EXPLAIN ANALYZE em 5.000 linhas sintéticas (44 vezes o volume real de 113), dentro de transação desfeita: Execution Time 0,242 ms com grupo mais dificuldade, 0,144 ms com os quatro filtros mais o LIKE do nome; índice por categoria ou equipamento isolado recusado por medição, não por gosto.

Para que serve: guardar a prescrição, a execução e as preferências de treino.

Relacionado com: RF-TREI-001 a 010; tarefas F3-01 a F3-10.

Onde fica: banco de dados, esquema principal.

Especificação: ficha_treino (id, aluno_id, autor_id, titulo, descricao, status ativo ou inativo, ficha_origem_id, criado_em, atualizado_por, atualizado_em); ficha_item (id, ficha_id, exercicio_id, ordem, series, reps, descanso, carga_sugerida, observacao de até 280 caracteres, exibida junto do exercício durante a execução); sessao_treino (id, aluno_id, ficha_id, inicio, fim, duracao_segundos, volume_kg, status entre em andamento, concluida e abandonada, exercicio_atual_ordem, ultimo_registro_em, observacao da sessão), com no máximo uma sessão em andamento por aluno, garantida por índice único parcial em aluno_id para o status em andamento, e a série gravada a cada registro, de modo que a retomada leia do banco e não da memória da tela; sessao_serie (id, sessao_id, exercicio_id, numero_serie, carga_kg, repeticoes, duracao_segundos, observacao, pulado), aceitando série de carga (carga e repetições preenchidas, duração vazia) ou série por tempo (duração preenchida, carga e repetições podendo ficar vazias), sem exigir os dois pares ao mesmo tempo e sem gravar zero no lugar de vazio; preferencia_treino (id, aluno_id único, objetivos, nivel, equipamentos, dias, duracao_min, limitacoes, observacoes, criado_em, atualizado_em), uma linha por aluno: objetivos é conjunto não vazio do catálogo fechado de oito objetivos e nivel é valor único do catálogo fechado de três níveis, os dois obrigatórios conforme o Apêndice de catálogo de formulários; equipamentos é conjunto, possivelmente vazio, do catálogo fechado de vinte e seis equipamentos; dias é conjunto, possivelmente vazio, de dia da semana de segunda a domingo, guardado na ordem em que o Apêndice o escreve, de modo que o critério de exibição e o de ordenação sejam o mesmo; duracao_min é anulável, de 20 a 120 e múltipla de 5, nunca zero, pela regra terminal de RN-004; limitacoes e observacoes são anuláveis, até 2000 caracteres cada. Conjunto vazio é vazio, nunca nulo disfarçado e nunca elemento de preenchimento, e a ausência de escolha é um fato, não um desconhecido. atualizado_por não existe: só o titular escreve, então a coluna gravaria sempre o mesmo valor de aluno_id, e a pergunta de quem alterou e quando já tem dono na trilha imutável de RF-CORE-009; solicitacao_ficha (id, aluno_id, profissional_id, motivo escrito pelo aluno, obrigatório e não vazio, com teto de mil caracteres; ficha_alvo_id anulável, preenchida quando o pedido é de ajuste de uma ficha existente e nula quando o pedido é de ficha nova; ficha_id anulável, a ficha que atendeu o pedido, preenchida apenas no estado atendida; motivo_recusa anulável, exigido apenas no estado recusada e garantido pela guarda de transição, nunca por NOT NULL na coluna, que quebraria os dois estados legítimos em que ele é nulo; estado entre aberta, atendida e recusada; criado_em; resolvido_em, preenchido nos dois estados terminais). As duas colunas de ficha respondem perguntas diferentes e por isso são duas: ficha_alvo_id é a ficha de que o aluno reclamou e ficha_id é a ficha que atendeu, e no atendimento por criação elas nem são a mesma; fundir as duas apagaria a pergunta exatamente no instante em que a resposta chegasse. Coerência entre estado e colunas garantida por restrição de verificação, nunca por disciplina da rota: atendida exige ficha_id e resolvido_em preenchidos, recusada exige motivo_recusa e resolvido_em preenchidos, aberta exige os três nulos. Índices: ficha_treino(aluno_id, status), sessao_treino(aluno_id, inicio), sessao_serie(sessao_id), sessao_serie(exercicio_id, sessao_id) para a progressão de carga, solicitacao_ficha(profissional_id, estado) para a lista de pedidos do profissional solicitacao_ficha(aluno_id, estado) para o acompanhamento do aluno e preferencia_treino(aluno_id) único, que é o que materializa o aluno_id único declarado acima e serve a toda consulta desta tabela, sempre por aluno. Integridade: ficha_item.ordem única por ficha; sessao_serie.numero_serie única por sessão e exercício; o volume da sessão soma apenas as séries com carga e repetições preenchidas, ignorando as séries por tempo, conforme RN-004.

Nota de decisão declarada (gate {F3-01}, 2026-09-14): a desativação de ficha_treino usa a coluna status que a própria ficha já declara (ativo e inativo, as duas únicas transições que E.3 prevê) e a tabela NÃO ganha desativado_em nem desativado_por. A pergunta estava aberta desde {F1-10}, que exige do card dono uma declaração e proíbe decidir por analogia. Três motivos medidos: um par de colunas ao lado de status criaria duas fontes para o mesmo fato, e o dia em que uma linha tivesse status ativo com desativado_em preenchido nenhum verificador perceberia, com a dimensão fichas_ativas contando uma coisa e a lista de trabalho filtrando outra; quem desativou e quando já tem dono, que é a trilha imutável de RF-CORE-009, gravada pelo gatilho genérico de remoção sem a tabela precisar de coluna nenhuma, na mesma forma de três argumentos já usada por vinculo; e a própria lista única de entidades prevê declarar qual é a coluna de desativação, conferindo por catálogo que a coluna declarada existe, nunca que ela se chama desativado_em. Isto é decisão declarada, não entrega: as duas tabelas nascem em {F3-01} e o placar deste cartão segue 0 de 6 até lá. plano_alimentar tem a mesma pergunta aberta e NÃO é decidida aqui: o card dono dela é {F4-03}, com o mesmo dever de declarar.

Nota (gate {F3-02}, 2026-09-14): {F3-02} não cria tabela, migração, política, gatilho, função nem índice. O aluno titular já passa, conjunção por conjunção, pela política de inserção que {F3-01} escreveu, e o único guarda que o recusava era uma linha da camada de aplicação. O placar deste cartão fica exatamente onde {F3-01} o deixou, 2 de 6 tabelas, e a última migração em produção continua 0025. Placar que não muda também se declara, senão o leitor supõe que ninguém olhou.

Fechamento [2026-09-14]: confirmado inalterado. {F3-02} entrou em produção (3d25e27) sem tocar tabela, migração, política, gatilho, função nem índice. Placar continua 2 de 6 tabelas, última migração em produção continua 0025.

Nota (gate {F3-03}, 2026-09-14): {F3-03} não cria tabela, coluna, índice nem GRANT, e por isso o placar deste cartão fica onde {F3-01} o deixou, 2 de 6 tabelas. Ele cria uma migração, que é outra coisa: 0026_edicao_da_ficha.sql altera duas políticas de UPDATE que já existem, acrescenta a política de DELETE que faltava em ficha_item, recria a restrição de ordem única como adiável dentro da transação e instala os gatilhos de auditoria das duas tabelas. solicitacao_ficha, sessao_treino, sessao_serie e preferencia_treino não nascem aqui, e a última migração em produção passa de 0025 para 0026 só no fechamento. Decisão declarada sobre a escrita: a edição acontece por uma rota só, PATCH /api/fichas/:id, numa transação só, e a lista de itens é reconciliada por identificador, nunca por posição e nunca por apagar tudo e reinserir: item conhecido com campos diferentes recebe UPDATE, que é a única forma de a trilha ter valor anterior e valor novo, que é o que o H1 cobra; item conhecido sem diferença nenhuma não é escrito; item sem identificador recebe INSERT; item que existia e não veio no corpo recebe DELETE; e item cujo identificador não pertence a esta ficha é recusado antes de o banco ser tocado, para que o erro não conte a existência de outra ficha. A rota nunca escreve status: desativar e reativar têm rotas próprias, porque estado e conteúdo mudando na mesma instrução apagariam a alteração de conteúdo da trilha. ficha_item.ordem continua única por ficha; o que muda é que a restrição passa a ser adiável dentro da transação, para que reordenar não colida no meio do caminho e a trilha não registre uma ordem intermediária que nunca existiu. Placar que não muda também se declara.

Fechamento [2026-09-14]: confirmado em produção (merge 76bc9cd, migração 0026_edicao_da_ficha.sql aplicada, última em produção passa de 0025 para 0026). A decisão de escrita descrita acima está implementada: PATCH /api/fichas/:id numa transação, item conhecido com diferença recebe UPDATE, sem identificador recebe INSERT, ausente no corpo recebe DELETE, identificador alheio é recusado antes do banco; status fora da rota, com desativar e reativar próprios; ficha_item.ordem única e agora DEFERRABLE. Placar continua 2 de 6 tabelas, nenhuma tabela nova.

Nota (gate {F3-04}, Drifts 2 e 3, 2026-09-14): a especificação de solicitacao_ficha acima foi reconciliada nesta data, e a reconciliação é da FICHA da tabela, nunca do requisito: RF-TREI-004 sempre disse "uma ficha nova ou o ajuste de uma existente", e quem estava incompleto era esta ficha, que tinha uma coluna de ficha para dois significados. Três colunas entram, cada uma com dono declarado: ficha_alvo_id, porque o pedido de ajuste precisa dizer qual ficha o aluno quer mudar e sem ela a lista do profissional mostraria o pedido sem o alvo; motivo_recusa, porque {ART-SM-03} exige motivo obrigatório na recusa e motivo já tem dono, que é o texto do aluno cobrado pelo H1, de modo que reaproveitá-lo apagaria o pedido no ato de recusá-lo; e criado_em e resolvido_em, que a irmã ficha_treino deste mesmo cartão já tem por escrito e sem as quais nem a lista ordena nem a tela exibe a data da resolução. O placar deste cartão não muda aqui, continua 2 de 6 tabelas, porque nada é criado antes de o código existir; quando {F3-04} entregar, solicitacao_ficha nasce e o placar passa a 3 de 6, e para aí: sessao_treino, sessao_serie e preferencia_treino são de {F3-05}, {F3-08} e {F3-10}. Placar que não muda também se declara.

Para que serve: guardar o que o aluno come, as metas e o plano prescrito.

Relacionado com: RF-DIET-001 a 005; tarefas F4-01 a F4-05.

Onde fica: banco de dados, esquema principal.

Especificação: refeicao (id, aluno_id, tipo, nome, data, horario, observacoes, criado_em, desativado_em, desativado_por); refeicao_alimento (id, refeicao_id, ordem, nome, quantidade_g, calorias, proteina_g, carboidrato_g, gordura_g); meta_nutricional (id, aluno_id, calorias, proteina_g, carboidrato_g, gordura_g, autor_id, vigente_desde, definida_em), com autor_id e vigente_desde nulos juntos e só juntos na vigência padrão (uma por aluno); plano_alimentar (id, aluno_id, autor_id, titulo, descricao, status, criado_em, atualizado_por, atualizado_em), com status texto ativo ou inativo (E.3); plano_refeicao (id, plano_id, ordem, nome, horario, notas, alimentos), com alimentos em documento [{nome, quantidade, calorias}] validado no banco e unicidade (plano_id, ordem). Índices: refeicao(aluno_id, data), refeicao_alimento(refeicao_id), meta_nutricional(aluno_id, vigente_desde, definida_em), plano_alimentar(aluno_id, status), plano_refeicao(plano_id). Regra: a meta do dia D é a de maior vigente_desde menor ou igual a D, a vigência padrão valendo antes de todas, e no empate a de maior definida_em, o que preserva o histórico sem recalcular o passado.

Nota (gate {F4-01}, Drift 2, 2026-09-29): reconciliação da FICHA, nunca do requisito. A especificação de refeicao trazia criado_por, sem desativado_em e desativado_por; E.1 e a lista única de entidades removíveis de RF-CORE-008 dizem o contrário, e criado_por seria sempre igual a aluno_id, porque só o titular escreve (o Super Administrador escreve personificando, e a trilha guarda o par). A ficha acima já está corrigida: criado_por sai, criado_em, desativado_em e desativado_por entram, refeicao_alimento ganha ordem e o índice refeicao_alimento(refeicao_id). O placar deste cartão (0 de 5 tabelas) só muda no fechamento de {F4-01}, quando as duas tabelas existirem em produção.

Fechamento [2026-09-30] de {F4-01}: placar 2 de 5 tabelas. refeicao e refeicao_alimento estão em produção (migração 0043) com as colunas da ficha acima, o índice refeicao(aluno_id, data) e a unicidade (refeicao_id, ordem) na filha; desativação por desativado_em e desativado_por, sem rota de exclusão definitiva (só o Super Administrador, no banco). Faltam meta_nutricional ({F4-02}) e plano_alimentar com plano_refeicao ({F4-03}). O cartão permanece [ ].

Nota (gate {F4-02}, Drift 5, 2026-09-29): reconciliação da FICHA, nunca do requisito. A ficha de meta_nutricional não ordenava duas metas do mesmo dia (o H1 de RF-DIET-002 troca a meta duas vezes, tipicamente no MESMO dia, e vigente_desde sozinho não diz qual é a mais recente) e não tinha forma para a vigência padrão do aluno novo, que não tem data certa porque o fuso do aluno é desconhecido no cadastro. A ficha acima já está corrigida: entra definida_em; autor_id e vigente_desde são NULOS juntos e só juntos na vigência padrão (uma por aluno); a regra passa a dizer que a meta do dia D é a de maior vigente_desde menor ou igual a D, a vigência padrão valendo antes de todas, e no empate a de maior definida_em; o índice passa a (aluno_id, vigente_desde, definida_em). O placar deste cartão (2 de 5 tabelas) só muda no fechamento de {F4-02}, medido no dia.

Fechamento [2026-09-30] de {F4-02}: placar 3 de 5 tabelas. meta_nutricional está em produção (migração 0044, https://fit.modulareasy.com) com as colunas da ficha acima já corrigida (definida_em incluída; autor_id e vigente_desde nulos juntos e só juntos na vigência padrão, uma por aluno) e o índice (aluno_id, vigente_desde, definida_em); só de acréscimo, com UPDATE e DELETE pela aplicação negados (42501). A regra da ficha está provada: a meta do dia D é a de maior vigente_desde menor ou igual a D, a vigência padrão valendo antes de todas, e no empate a de maior definida_em, calculada no ponto único mfit.meta_vigente(aluno, data). Falta plano_alimentar com plano_refeicao ({F4-03}). O cartão permanece [ ].

Nota (Inspeção, {AUD-11}, 2026-09-30): as cinco tabelas deste cartão são dado da categoria nutrição de RF-CORE-010, a sétima: refeicao, meta_nutricional e plano_alimentar decidem acesso com mfit.tem_consentimento(aluno_id, 'nutricao') na escrita e mfit.consentimento_visivel(aluno_id, 'nutricao') na leitura, e refeicao_alimento e plano_refeicao seguem a linha pai. A vigência padrão de meta_nutricional passa a nascer no primeiro consentimento de nutrição, não na criação do aluno, e a de aluno sem consentimento sai na migração de {AUD-11}. Placar deste cartão inalterado, 3 de 5 tabelas.

Fechamento [2026-09-30] de {AUD-11}: placar inalterado, 3 de 5 tabelas: nenhuma tabela nasce neste card, as três que existem (refeicao, refeicao_alimento, meta_nutricional) passam a estar sob a categoria nutrição em produção (migrações 0046 e 0047). A vigência padrão de meta_nutricional agora nasce no primeiro consentimento de nutrição do aluno, e a de aluno sem consentimento foi removida pela migração (era cópia de metas_padrao, conforme o gate de db); nenhuma linha com autor foi tocada. Faltam plano_alimentar com plano_refeicao ({F4-03}, migração 0048), que já nascem sob a categoria. O cartão permanece [ ].

Nota (gate {F4-03}, Drift 2, 2026-09-30): reconciliação da FICHA, nunca do requisito. A ficha de plano_alimentar e de plano_refeicao não trazia o que RF-CORE-009 exige (quem alterou por último e quando), não desempatava dois horários iguais e não dizia a forma dos alimentos. A ficha acima já está corrigida: plano_alimentar ganha criado_em, atualizado_por e atualizado_em, com status ativo ou inativo (E.3) e índice (aluno_id, status); plano_refeicao ganha ordem, e alimentos passa a documento [{nome, quantidade, calorias}] validado no banco (Cenário 1 do Drift 1 do mesmo gate, com calorias), com unicidade (plano_id, ordem), índice (plano_id) e exibição por horario e depois ordem. plano_alimentar usa o status existente como coluna de desativação, no molde de ficha_treino; quem desativou e quando fica na trilha. O placar deste cartão (3 de 5 tabelas) só muda no fechamento de {F4-03}, medido no dia.

Nota de correção (Inspeção, gate {F4-03}, Drift 9, 2026-09-30): a migração do plano alimentar é a 0052 ({F4-03}); o fechamento de {AUD-11} acima, que numera a migração de {F4-03} como 0048, fica corrigido (a 0048 é de {AUD-10}). A categoria nutricao existe desde a 0046 ({AUD-11}).

Fechamento [2026-09-30] de {F4-03}: placar 5 de 5 tabelas. plano_alimentar e plano_refeicao estão em produção (migração 0052, https://fit.modulareasy.com) com as colunas da ficha acima já corrigida: status texto ativo ou inativo (E.3) e índice (aluno_id, status) no plano; ordem, alimentos em documento [{nome, quantidade, calorias}] validado no banco, unicidade (plano_id, ordem) e índice (plano_id) na filha. Titular e autor imutáveis por privilégio de coluna; a filha herda o consentimento de nutrição do plano pai; a soma de calorias por refeição e por plano é do banco, sem coluna de total. Medido em produção na conferência de fechamento: as cinco tabelas de nutrição existem e mfit.parametro tem 33 linhas. Remover refeição ao editar grava na trilha refeicao_removida com o conteúdo anterior. O cartão passa a [x].

Nota (gate {F4-04}, Drift 2, 2026-09-30): mfit.comparacao_com_meta, migração 0053, é a regra única da comparação do consumo com a meta; {F4-05} a consome e define por cima dela o que é meta atingida. A razão: se a tela calculasse o percentual e o acompanhamento calculasse em SQL, um dia que a tela mostra "100 por cento" poderia não contar como atingido. Placar do cartão inalterado, 5 de 5 tabelas (a função não é tabela).

Fechamento [2026-09-30] de {F4-04}: placar inalterado, 5 de 5 tabelas: nenhuma tabela nasce neste card. O que nasce é a função mfit.comparacao_com_meta(consumido, meta) (migração 0053, https://fit.modulareasy.com, merge a6624e9), função pura e IMMUTABLE, sem SECURITY DEFINER, com EXECUTE para o papel da aplicação: devolve restante com uma casa e percentual inteiro, meio para cima e sem teto, e nulo nos dois quando a meta é nula, zero ou negativa, ou o consumido é nulo. É a regra única da comparação do consumo com a meta, e {F4-05} a consome. Medido: funções do schema de 57 para 58 (só a nova), políticas 77 e parâmetros 33, inalterados; a 0053 não cria tabela, política, gatilho, privilégio de tabela nem parâmetro. A soma do dia continua sobre refeicao e refeicao_alimento, pelo leitor único de refeição, só com refeições ativas.

Fechamento [2026-10-01] de {F4-05}: placar inalterado, 5 de 5 tabelas: nenhuma tabela nasce. Nasce a função mfit.meta_atingida(consumido, meta, tolerância) (migração 0054, função pura, IMMUTABLE, sem SECURITY DEFINER, consome mfit.comparacao_com_meta), que decide o dia com meta atingida de RF-DIET-005; funções do schema de 58 para 59, políticas 77 e gatilhos inalterados. A tolerância chega como argumento e a função nunca lê mfit.parametro. NULL não é falso: meta ausente, zero ou negativa devolve nulo. A migração 0055 é só de COMMENT.

Para que serve: criar a conta do profissional com o registro do conselho no formato certo.

Relacionado com: RF-CORE-003; tarefa F1-05.

Onde fica: tela de cadastro, caminho /cadastrar.

Especificação: ficha completa no Apêndice de catálogo de formulários do DRS, seção Cadastro de profissional. Contém a tabela de campos, as quatro máscaras, a ação no envio, as mensagens e o idioma.

Para que serve: cadastrar e editar o exercício global.

Relacionado com: RF-EXER-001, RF-EXER-002; tarefas F2-01 e F2-02.

Onde fica: administração de exercícios, caminho /admin/exercicios.

Especificação: ficha completa no Apêndice de catálogo de formulários do DRS, seção Exercício do catálogo, com os treze campos, as listas fechadas e os limites de arquivo. imagem aceita arquivo enviado ou endereço, as duas formas moram na mesma coluna, distinguidas pelo prefixo; video é só endereço.

Estado: 13 de 13 campos servidos, ficha fechada, aritmética 11 ({F2-01}) mais 2 ({F2-02}) igual 13. A ficha do Apêndice tem treze linhas.

Para que serve: capturar o que orienta a prescrição e a geração assistida.

Relacionado com: RF-TREI-008, RF-IAGE-001; tarefas F3-08 e F8-06.

Onde fica: tela de preferências do aluno.

Especificação: ficha completa no Apêndice de catálogo de formulários do DRS, seção Preferências de treino do aluno, com os sete campos, a obrigatoriedade declarada por campo (objetivos e nível sim, os outros cinco não), as oito opções de objetivo, os três níveis, a lista fechada de vinte e seis equipamentos, os dias de segunda a domingo, a duração de 20 a 120 minutos com passo de 5 e o teto de 2000 caracteres de cada um dos dois textos.

Estado: 7 de 7 campos servidos, ficha fechada. A ficha do Apêndice tem sete linhas, e os sete são de um card só, {F3-08}, que os serve de uma vez, porque o formulário salva inteiro num botão só.

Nota (gate {F3-08}, Drift 8, 2026-09-15): este cartão não tinha campo Estado, logo não tinha universo declarado contra o qual fechar, e seria marcado [x] sem ninguém poder conferir contra o quê. O universo nasce aqui, sete campos, no molde literal de {ART-FORM-02}, e o cartão fecha campo a campo, com a obrigatoriedade, as listas fechadas e os limites conferidos contra o Apêndice, item por item, incluindo os três rótulos com barra da lista de equipamentos. A metade que não é de {F3-08} é a leitura das preferências pela geração assistida, que o próprio campo "Relacionado com" já nomeia em {F8-06}, e ela continua com o dono dela: servir os sete campos ao aluno e ao profissional vinculado fecha este cartão, e ler para gerar treino não é campo deste formulário.

Fechamento [2026-09-15]: os sete campos em produção (merge ce1787b, https://fit.modulareasy.com), conferidos contra o Apêndice, obrigatoriedade, listas fechadas e limites inclusos. Cartão fecha 7 de 7.

Para que serve: montar o histórico do aluno uma única vez, acrescido por especialidade.

Relacionado com: RF-SAUD-001, ADR-007, RF-CORE-012; tarefa F5-01, F1-18.

Onde fica: aba de saúde do aluno.

Especificação: ficha completa no Apêndice de catálogo de formulários do DRS, seção Anamnese, com o tronco comum e as quatro seções por especialidade. Cada envio cria um registro datado, com autor e especialidade do autor, e não altera nenhum registro anterior; o tronco de uma anamnese nova abre pré-preenchido pela anterior do aluno, editável, com a indicação da data de origem. A tela lista as anamneses do aluno da mais recente para a mais antiga e permite abrir qualquer uma em leitura. Pré-condição: consentimento da categoria anamnese. A tela nasce com <AvisoNaoClinico ponto="telas_clinicas" /> no topo (R-9, {F1-18}).

Nota (Inspeção, gate {F5-01}, Drifts 1, 3 e 4, 2026-10-01): a ficha dos 46 campos, com tipo, obrigatoriedade e teto, está no Apêndice: Catálogo de formulários do DRS, na Nota do Drift 1: tronco com 20 campos e quatro seções de 5, 5, 8 e 8; todos opcionais, mas o envio exige ao menos um campo preenchido (422 anamnese_vazia); texto curto e texto longo com os tetos de anamnese_texto_curto_max_caracteres e anamnese_texto_longo_max_caracteres ({ART-CFG-01}). Quem preenche o quê: o profissional preenche o tronco e somente a seção da própria especialidade, e somente com vínculo ativo nela; o aluno preenche o tronco e as seções das especialidades com as quais não tem vínculo ativo; ao abrir uma anamnese, todas as seções gravadas aparecem. Sem edição: a anamnese não se edita, a correção é nova coleta, e o autor e o Super Administrador só a desativam; a tela não tem ação de editar. O cartão continua [ ].

Fechamento [2026-10-01] de {F5-01}: formulário e lista da anamnese em produção (merge 9cb16f3, repositório wladimirdjr/modularfit, migração 0056, https://fit.modulareasy.com (/api/estado na versão 9cb16f3)), em /saude (aba Anamneses), /saude/anamneses/nova e /saude/anamneses/:id. Os 46 campos (tronco de 20 mais as seções de 5, 5, 8 e 8) seguem o contrato único do servidor com espelho na web provado por teste; todos opcionais, o envio exige ao menos um campo (422 anamnese_vazia), texto curto e longo com os tetos editáveis (200 e 2000), números com vírgula aceita e as faixas de plausibilidade (o qa recusou idade 121, altura 49, peso com duas casas e sexo inválido, e aceitou dor de 0 a 10). Cada envio cria um registro datado, com autor e especialidade vindos da sessão; o tronco abre pré-preenchido pela anamnese ativa mais recente, com a indicação da data de origem; a tela lista da mais recente para a mais antiga, o formulário mostra só as seções da própria especialidade (o aluno, as das especialidades sem vínculo) e a leitura mostra todas as seções gravadas, com "não informado" visível no campo vazio. A anamnese não se edita: a tela não tem ação de editar, e o autor ou o Super só desativam, com confirmação, no detalhe (divergência declarada: não há botão no cartão da lista). O aviso não clínico fica no topo da casca. Pré-condição de consentimento provada em produção. O cartão passa a [x].

Para que serve: registrar as medições e testes e alimentar os cálculos derivados.

Relacionado com: RF-SAUD-002, RF-SAUD-003; tarefas F5-02 e F5-03.

Onde fica: aba de saúde do aluno.

Especificação: ficha completa no Apêndice de catálogo de formulários do DRS, seção Avaliação física, com as seis seções e o bloco de cálculos, que é calculado e nunca digitado. Quem preenche: as quatro especialidades com vínculo ativo e o próprio aluno; a seção de antropometria não é restrita a especialidade nenhuma.

Nota (Inspeção, gate {F5-02}, Drifts 1, 3, 4 e 7, 2026-10-01): a ficha dos campos, com tipo, faixa e teto, está no Apêndice: Catálogo de formulários do DRS, na Nota do Drift 1: anamnese resumida com 8 campos, cardiovascular com 6 (entra idade_anos, insumo da frequência cardíaca máxima de RN-004), antropometria com 6 mais um campo por ponto de dobra ativo, neuromuscular com até 10 testes de força, aeróbico com 6 e biotipo com 2; todos opcionais, mas o envio exige ao menos um campo (422 avaliacao_vazia); texto curto e texto longo com os tetos de avaliacao_texto_curto_max_caracteres e avaliacao_texto_longo_max_caracteres ({ART-CFG-01}). Quem preenche não muda. Sem edição: a avaliação não se edita, a correção é nova avaliação, e o autor e o Super Administrador só a desativam; a tela não tem ação de editar. Comparação: bloco do detalhe, pela regra da Nota de RF-SAUD-002 (contra a ativa anterior ou outra ativa escolhida; métrica de teste só com o mesmo teste; ausente nunca vale zero). O mockup traz campos que a ficha não tem (peitoral, braço direito e esquerdo, preensão manual, FC final, objetivo e nível): o DRS vence, e perímetro extra é medida corporal ({F5-07}). O cartão continua [ ].

Nota (Inspeção, gate {F5-03}, Drifts 1 a 5, 2026-10-06): o bloco de cálculos desta ficha ganha o desenho, sem mudar a ficha dos campos. Detalhe da avaliação: bloco "Cálculos" com índice de massa corporal, relação cintura quadril e frequência cardíaca máxima, cada um com valor, unidade e a fórmula usada ("peso / altura² (m)", "cintura / quadril" e "220 menos a idade"), e as cinco zonas de intensidade em tabela que empilha em tela estreita; sem classificação de índice de massa corporal, porque o produto não é clínico. Comparação: seção "Cálculos" ao fim, com índice de massa corporal (uma casa, kg/m²), relação cintura quadril (duas casas) e frequência cardíaca máxima (zero casas, bpm); as zonas não entram; as linhas antigas mantêm ordem e chave. Lista de avaliações: não exibe cálculo. Cálculo sem insumo: o número some e a linha diz "não calculado: informe a altura" (e a forma equivalente para cintura, quadril e idade), nunca zero. Arredondamento: meio para cima sobre a representação decimal; divisor zero ou ausente não calcula. Constantes: 220 menos a idade, o índice de massa corporal, a relação cintura quadril e as cinco zonas são constantes de literatura com fonte citada (Fox, 1971; Quetelet e OMS; OMS, 2008; ACSM) e não parâmetro: mudar é mudar RN-004, e o verificador de parâmetros as conhece como exceção C nomeada. Nada dele é gravado. O cartão continua [ ].

Fechamento [2026-10-06] de {F5-02}: formulário, detalhe e comparação da avaliação física em produção (merge 3ab8395, repositório wladimirdjr/modularfit, migrações 0057 e 0058 aplicadas em produção em 06/10, https://fit.modulareasy.com (/api/estado na versão 87ae8e0, a mesma árvore do merge; o deploy da main em 3ab8395 segue em curso)), em /saude/avaliacoes (aba Avaliações da casca de /saude), /saude/avaliacoes/nova e /saude/avaliacoes/:id. As seis seções (anamnese resumida, cardiovascular, antropometria, neuromuscular, aeróbico e biotipo) seguem o contrato único do servidor com espelho na web provado por teste; todas opcionais, o envio exige ao menos um campo (422 avaliacao_vazia), texto curto e longo com os tetos editáveis (200 e 2000), números com vírgula aceita e faixas de plausibilidade (o qa recusou idade 121 e peso 501), as quatro dobras cutâneas em milímetros pela lista de pontos vinda da configuração, o teste de flexibilidade, o teste de resistência e o tempo aeróbico em minutos e segundos (mm:ss). Cada envio cria um registro datado, com autor e especialidade vindos da sessão (o aluno grava com especialidade nula) e o Nutricionista vinculado registra a antropometria completa sem recusa. A avaliação não se edita: a tela não tem ação de editar, e o autor ou o Super só desativam, com confirmação, no detalhe. Comparação: bloco do detalhe, contra a ativa anterior ou outra ativa escolhida em "Comparar com" (as opções se distinguem por autor, ordem no dia e a medida); variação com sinal e unidade, "não informado" e "sem variação" onde falta dado, métrica de teste só com o mesmo teste. O aviso não clínico fica no topo da casca. Pré-condição de consentimento provada em produção. O cartão passa a [x].

Fechamento [2026-10-06] de {F5-03}: o bloco de cálculos desta ficha está em produção (merge 08b35ed, repositório wladimirdjr/modularfit, sem migração, https://fit.modulareasy.com (a mesma árvore já provada em produção como 208a883; o deploy da main em 08b35ed segue em curso)), como a Nota de {F5-03} desenhou: no detalhe da avaliação, o bloco "Cálculos" com índice de massa corporal (uma casa, kg/m²), relação cintura quadril (duas casas) e frequência cardíaca máxima (zero casas, bpm), cada um com valor, unidade e fórmula, e as cinco zonas de intensidade em tabela que empilha em tela estreita; na comparação, a seção "Cálculos" ao fim com as três métricas e as zonas fora; a lista não exibe cálculo. Sem insumo o número some e a linha diz "Não calculado: informe ...", nunca zero. Arredondamento meio para cima sobre a representação decimal, provado com 48 kg e 160 cm (18,8). Nada é gravado: nenhuma coluna e nenhuma migração. Prova: H1 de {TA-40} em produção (24,7, 0,90, 190 e as zonas 95 a 114 até 171 a 190). O cartão segue [x].

Para que serve: guardar o exame com o arquivo no repositório privado.

Relacionado com: RF-SAUD-004, RF-SAUD-009, RF-CORE-012; tarefas F5-04 e F5-09, F1-18.

Onde fica: aba de saúde do aluno.

Especificação: ficha completa no Apêndice de catálogo de formulários do DRS, seção Exame, com os seis campos, a lista editável de tipos e o limite de vinte megabytes. A tela nasce com <AvisoNaoClinico ponto="telas_clinicas" /> no topo (R-9, {F1-18}).

Nota (Inspeção, gate {F5-04}, Drifts 2, 5, 7, 8, 9 e 11, 2026-10-06): a ficha dos seis campos está no Apêndice: Catálogo de formulários do DRS, na Nota do exame, e {ART-CFG-01} traz os parâmetros. Sem edição: o exame não se edita, a correção é novo exame, e o autor e o Super Administrador só o desativam; a tela não oferece edição. Data: informada pelo usuário e não futura, com a folga de fuso já existente no servidor; o momento do registro é do banco. Tetos: nome (mínimo de 3 caracteres, regra fixa, e teto de exame_nome_max_caracteres), resumo (exame_resumo_max_caracteres) e observações (exame_observacoes_max_caracteres), todos editáveis; a mensagem do campo diz o teto vigente. Tipo: a lista tipo_exame (Laboratorial, Imagem, Cardiológico, Funcional e Outro). Anexo: o tipo vem dos bytes e da extensão declarada, os dois na lista de extensões aceitas e da mesma família (jpg é jpeg); documento por %PDF-; texto só se for UTF-8 válido, sem byte nulo e sem controle além de tabulação e quebra de linha; um arquivo de extensão aceita e conteúdo de outro formato é recusado com a mensagem do campo; um arquivo de exatamente o limite é aceito; a cota do plano é decidida antes de gravar o objeto. Aviso aos Médicos: não é desta tela nem de {F5-04}; é {F6-05}. O cartão continua [ ].

Fechamento [2026-10-06] de {F5-04}: formulário, lista e detalhe do exame estão em produção (merge b078e76, repositório wladimirdjr/modularfit, migração 0059, https://fit.modulareasy.com (a mesma árvore já provada em produção como bde96b3; o deploy da main em b078e76 segue em curso)), como a Nota de {F5-04} desenhou, dentro da casca de /saude (aba Exames, com <AvisoNaoClinico ponto="telas_clinicas" /> no topo, sem rota clínica fora da casca): os seis campos (tipo da lista tipo_exame, nome, data, resumo, observações e anexo), mensagem do campo com o teto vigente, "Não informado" e "Sem anexo" nos vazios, barra de envio, confirmação ao desativar e anexo aberto em nova aba por endereço assinado, emitido só no detalhe. Sem edição: nenhuma tela ou rota altera conteúdo, o autor e o Super Administrador só desativam. Data do usuário, não futura além da folga de fuso, e o momento do registro gravado pelo banco. Anexo pelos bytes e pela extensão declarada, 20 MiB exatos aceitos e 20 MiB mais um byte recusados com a mensagem do campo. Prova: H1 de {TA-41} em produção, e 72 combinações de largura, tema e tela sem rolagem horizontal. Lacuna: o formulário mostra "20 MB e o limite é 20 MB" para 20 MiB mais um byte (P3 do qa). O aviso aos Médicos segue em {F6-05}. O cartão passa a [x].

Para que serve: capturar o que o aluno comeu com os macronutrientes.

Relacionado com: RF-DIET-001; tarefa F4-01.

Onde fica: tela de nutrição do dia.

Especificação: ficha completa no Apêndice de catálogo de formulários do DRS, seção Refeição registrada, com os campos da refeição e os seis campos por alimento. Ação no envio: cria a refeição, soma os totais e recalcula o dia contra a meta vigente.

Nota (gate {F4-01}, Drift 4, 2026-09-29): {F4-01} soma a refeição (RN-004); a comparação do dia com a meta vigente é de {F4-02} e {F4-04}. A ação no envio descrita na Especificação acima se lê nesse recorte: neste card o envio cria a refeição com os alimentos e devolve os totais somados da própria refeição.

Fechamento [2026-09-30] de {F4-01}: o formulário está em produção em /nutricao/refeicoes/nova (estado de /nutricao, não tela nova), com os campos da refeição (tipo lido da lista fechada tipo_refeicao de oito itens, nome, data, horário e observações) e os seis campos por alimento, cada linha de alimento com a ação de remover. Os tetos de caracteres de nome e de observações vêm de refeicao_nome_max_caracteres e refeicao_observacoes_max_caracteres e mudam sem reiniciar. Validação provada pelo qa: tipo inexistente ou desativado, valores negativos, quantidade zero, mais de duas casas, teto de numeric(7,1) e ausência de alimento respondem 422, e o formulário nomeia o campo com erro. O envio soma a refeição no servidor e a tela mostra os totais que o servidor devolveu.

Para que serve: cada usuário editar os próprios dados de perfil, com campos que variam por papel.

Relacionado com: RF-CORE-004, RF-CORE-009, ADR-004; tarefa F1-06; ART-SCR-01, ART-AUD-01.

Onde fica: tela de perfil, caminho /perfil.

Especificação: ficha completa no Apêndice de catálogo de formulários do DRS, seção Perfil do usuário, com os campos por papel, o e-mail em leitura, a foto ainda não disponível (Fase 5) e a regra de que trocar o registro profissional zera o registro verificado.

Estado: entregue em F1-06.

Para que serve: prescrever um exercício dentro da ficha com o que o aluno precisa para executá-lo, na ordem em que ele vai executar.

Relacionado com: RF-TREI-001, RF-TREI-002, RF-TREI-003, RF-EXER-001, RF-EXER-004, RN-009; tarefas F3-01, F3-02, F3-03 e F3-09; ART-ENT-04 (tabela ficha_item), ART-SCR-01 (a tela /fichas/nova), ART-FORM-02 (o exercício do catálogo, de onde o item vem).

Onde fica: tela de criação e de edição da ficha, caminho /fichas/nova, e leitura do item no detalhe da ficha e na execução da sessão.

Especificação: ficha completa no Apêndice de catálogo de formulários do DRS, seção Item da ficha de treino, com os sete campos, os tipos, a obrigatoriedade e a validação de cada um: exercício vindo do catálogo global por seleção, nunca texto livre (RF-EXER-001); séries de 1 a 20; repetições em texto livre, que aceita faixa, tempo ou por lado, e por isso sem formato imposto, porque impor formato aqui recusaria prescrição legítima; descanso de 0 a 600 segundos; carga sugerida opcional, em quilogramas com uma casa decimal; observação opcional de até 280 caracteres; e ordem única por 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, e o item sem observação não reserva espaço para ela.

Estado: entregue em {F3-01}, https://fit.modulareasy.com, merge 17bd22e. Aritmética dos cartões de formulário nesta data: 12 cartões existentes ({ART-FORM-01} a {ART-FORM-12}) mais este igual a 13 cartões, cobrindo 14 formulários, porque {ART-FORM-08} cobre dois (prescrição e sessão de reabilitação). Fechamento [2026-09-14]: os sete campos, os tipos, a obrigatoriedade e a validação estão na tela /fichas/nova exatamente como a Especificação descreve; a observação do item aparece no detalhe da ficha (/treinos/:id) e o item sem observação não reserva espaço para ela, provado no arnês e na tela real. A metade que acontece na execução ({F3-05}) fica com {TA-24}, não com este formulário, que fecha campo a campo aqui. Nota (gate {F3-01}, Drift 3, 2026-09-14): a ficha deste formulário já existia no Apêndice do DRS desde a publicação inicial; o que faltava era o cartão onde marcá-la entregue, e era por isso que o artefato central de {F3-01} não tinha onde ser conferido campo a campo. A tabela de tipos de artefato declarava 11 e foi medida e corrigida nesta mesma republicação: contava errado antes mesmo deste cartão nascer, e índice que conta errado é a primeira coisa que faz um placar mentir.

Nota (gate {F3-02}, 2026-09-14): o formulário é o MESMO, campo a campo: os sete campos do item, os tipos, a obrigatoriedade e a validação não mudam quando quem cria é o próprio aluno. O que muda é o entorno da tela, porque o titular passa a ser implícito para o aluno e o seletor não aparece para ele, e isso não é campo deste formulário. Placar inalterado, 13 de 13 campos.

Fechamento [2026-09-14]: confirmado inalterado. Em produção (3d25e27), os sete campos do item continuam idênticos para os dois papéis. Placar continua 13 de 13 campos.

Nota (gate {F3-03}, Drift 8, 2026-09-14): o formulário é o MESMO, campo a campo, na criação e na edição: os sete campos do item, os tipos, a obrigatoriedade e a validação não mudam, e o componente que desenha o item continua sendo um só, consumido também pela execução. O campo "Onde fica" deste cartão já dizia "tela de criação e de edição da ficha, caminho /fichas/nova", e é {F3-03} que torna a segunda metade dessa frase verdadeira, pelo caminho /fichas/:id/editar, que é estado da mesma tela e não uma tela nova. Nenhum segundo formulário com os mesmos sete campos nasce, pela mesma razão já escrita para a criação não se dividir por papel. Placar inalterado, 13 de 13 campos.

Fechamento [2026-09-14]: a edição está em produção (76bc9cd) pelo caminho /fichas/:id/editar, com os sete campos, os tipos, a obrigatoriedade e a validação idênticos aos da criação, provado no arnês e na tela real. Placar continua 13 de 13 campos.

Para que serve: definir a meta diária de calorias e macronutrientes do aluno, com vigência datada, contra a qual o dia é comparado.

Relacionado com: RF-DIET-002; tarefa F4-02; ART-FORM-09, ART-SCR-01 (a tela /nutricao), ART-ACS (capacidade "Definir meta nutricional", da Matriz Ator por Capacidade).

Onde fica: tela de nutrição, caminho /nutricao, no estado de metas: bloco "Metas do dia" com a ação Editar metas, que abre este formulário com confirmação. Não é rota nova, e sim estado de /nutricao, conforme a Nota de ART-SCR-01 ({F4-02}, Drift 4).

Especificação: ficha completa no Apêndice de catálogo de formulários do DRS, seção 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, o que preserva o histórico de metas e faz a alteração valer no cálculo seguinte, sem recalcular o passado. Quem pode: o aluno titular e o Nutricionista com vínculo ativo com o aluno; os demais papéis profissionais e o Administrador não definem meta.

Nota (ficha criada em 2026-09-30, a pedido da Inspeção): o formulário foi entregue em produção por {F4-02} (merge b569460) e existia no Apêndice do DRS, mas não tinha cartão onde ser conferido campo a campo. Aritmética dos cartões de formulário nesta data: 13 cartões existentes ({ART-FORM-01} a {ART-FORM-13}) mais este igual a 14 cartões, cobrindo 15 formulários, porque {ART-FORM-08} cobre dois (prescrição e sessão de reabilitação). A marca de entregue segue o fluxo do loop e não é posta aqui.

Fechamento [2026-09-30] de {F4-02}, conferido na atualização de {AUD-09}: o formulário está alcançável em produção: a rota /nutricao/metas responde 200 no build servido, e o qa de {F4-02} provou o formulário em produção (gate de qa modularfit-F4-02). Cartão marcado [x].

Fechamento [2026-09-30] de {F4-04}: a meta deste formulário passa a ser comparada com o consumo do dia em /nutricao, no bloco "Metas do dia". O formulário não muda; GET e POST /api/metas devolvem agora também o campo painel (os quatro cartões e o total do dia), e os consumidores (DefinirMetas e o formulário de plano alimentar) o ignoram, provados na regressão do qa. Meta de macronutriente igual a zero é válida no formulário e o painel a trata como "Sem meta definida", nunca como zero.

Para que serve: prescrever ao aluno um plano de alimentação em refeições estruturadas, cada uma com horário e lista de alimentos com quantidade e calorias, que é a base do que o aluno deve comer e da soma contra as metas vigentes.

Relacionado com: RF-DIET-003, RF-CORE-007, RF-CORE-008, RF-CORE-009, RN-009; tarefa F4-03; ART-FORM-14 (a meta nutricional, contra a qual a soma do plano é lida), ART-ENT-05 (tabelas plano_alimentar e plano_refeicao), ART-SCR-01 (a tela /nutricao/planos), ART-ACS-05 (capacidade "Criar plano alimentar", da Matriz Ator por Capacidade).

Onde fica: tela de planos alimentares, caminho /nutricao/planos, nos estados /nutricao/planos/novo e /nutricao/planos/:id/editar (formulário único de criação e de edição). Não é rota nova, e sim estado de /nutricao/planos, conforme a Nota de ART-SCR-01 (gate {F4-03}, Drift 4).

Especificação: ficha completa no Apêndice de catálogo de formulários do DRS, seção Plano alimentar. Campos do plano: título (texto, obrigatório) e descrição (texto longo, opcional). Campos de cada refeição, pelo menos uma: nome (texto, obrigatório), horário (HH:MM, obrigatório) e notas (texto longo, opcional). Campos de cada alimento, pelo menos um por refeição: nome (texto, obrigatório), quantidade (TEXTO, obrigatório, porque a prática usa "2 un", "200 ml", "1 col." e "à vontade") e calorias (número, obrigatório, maior ou igual a zero, uma casa decimal). Limites de texto pelos dois parâmetros de nutrição já existentes (nome e observações), editáveis pela administração. Ação no envio: cria o plano ativo, 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 (ficha criada em 2026-09-30, gate {F4-03}, Drift 1, a pedido da Inspeção): o formulário não existia no Apêndice do DRS, e sem ele o artefato central de {F4-03} não tinha onde ser conferido campo a campo. Decisão ratificada, Cenário 1: calorias de cada alimento obrigatórias, porque só assim o plano salvo carrega a soma que o mockup mostra e que RF-IAGE-002 cobra. Aritmética dos cartões de formulário nesta data: 14 cartões existentes ({ART-FORM-01} a {ART-FORM-14}) mais este igual a 15 cartões, cobrindo 16 formulários, porque {ART-FORM-08} cobre dois (prescrição e sessão de reabilitação). A marca de entregue segue o fluxo do loop e não é posta aqui.

Fechamento [2026-09-30] de {F4-03}: o formulário está em produção (https://fit.modulareasy.com, migração 0052) em /nutricao/planos/novo e /nutricao/planos/:id/editar, com os campos da ficha acima: plano com título e descrição, pelo menos uma refeição com nome, horário e notas, e pelo menos um alimento por refeição com nome, quantidade em texto e calorias (a vírgula é aceita). A soma gravada é a do banco; a prévia ao lado das metas vigentes é calculada na interface e não é gravada. Provado pelo qa: o Nutricionista de vínculo ativo e o aluno sem Nutricionista ativo criam; o Administrador recebe 403 nomeado; o segundo plano ativo do plano Gratuito é recusado com a mensagem do limite. O cartão passa a [x].

Para que serve: página inicial pública, entrada, cadastro, recuperação de senha e gestão de consentimentos.

Relacionado com: RF-CORE-001, 002, 003, 005, 010, 011, RF-INTE-002; tarefas F1-03 a F1-07, F1-12, F1-17, F8-09.

Onde fica: aplicação, caminhos /, /entrar, /cadastrar, /recuperar e /privacidade.

Especificação: linhas correspondentes do Apêndice de catálogo de telas do DRS. Regras próprias: a página inicial responde sem sessão, apresenta o produto, nomeia os cinco papéis de público com o que cada um faz na plataforma, oferece as chamadas entrar e criar conta, não exibe dado de usuário nem valor de plano, e leva ao painel quem já tem sessão; a tela de privacidade lista as seis categorias com estado, data de concessão, restrição por especialidade e as ações conceder e revogar. O botão "Exportar meus dados" pertence a RF-INTE-002 ({F8-09}) e não é renderizado até existir destino: affordance sem destino é beco, e ausência se declara, não se explica em rótulo. A página inicial não nomeia plano nenhum, nem nome nem preço, porque o catálogo é editável pela administração (ADR-012) e um nome escrito na tela envelheceria calado; nenhum link de ferramenta de desenvolvimento (/api/estado, /estilo) sai de página pública; e os quatro rótulos de especialidade da página inicial espelham a fonte única do servidor (CATALOGO_ESPECIALIDADES.rotulo), com verificador próprio que reprova a divergência.

Estado: 5 de 5 entregues. Entrar em {F1-03} com os quatro estados; Cadastro em {F1-04} (duas etapas, cinco estados) e {F1-05} (etapa do profissional); /recuperar já no ar desde {F1-07}; /privacidade em {F1-12}; / pública em {F1-17}. Aritmética: /entrar ({F1-03}) + /cadastrar ({F1-04} e {F1-05}) + /recuperar ({F1-07}) + /privacidade ({F1-12}) + / (este card) = 5 de 5. Ressalva: este total fecha o universo de cinco telas que esta própria ficha declara, não "todas as telas públicas do produto". /redefinir e /confirmar estão em produção desde {F1-07} e constam no Apêndice de catálogo de telas do DRS, mas não têm ficha de tela em nenhum dos cinco cartões {ART-SCR-0x}, hoje só existem como modelo de e-mail (fichas de confirmação de cadastro e de redefinição de senha). Ampliar o universo para sete telas não é feito aqui: mexeria na aritmética dos 32 que {ART-SCR-05} carrega e colide com a divergência "30 rotas x trinta e três rotas" aberta desde R-11(a) de {F1-16}; os dois seguem no mesmo bilhete ao mds-architect.

Para que serve: definir o alcance do profissional de nutrição.

Relacionado com: RF-DIET-002, RF-DIET-003, RF-SAUD-002; tarefas F4-02, F4-03 e F5-02.

Onde fica: políticas de acesso do banco.

Especificação: recorte da matriz do DRS, coluna Nutri. O que o distingue: é o único papel profissional que define meta nutricional e cria plano alimentar. Registra avaliação física como as demais especialidades, por a antropometria ser prática central dele. Não cria ficha de treino, não prescreve medicamento e não registra exame.

Nota (gate {AUD-09}, 2026-09-30): a parte "não cria ficha de treino" desta ficha está aplicada no banco e na rota desde a migração 0045 (merge d760b2d, em produção), nos mesmos termos da Nota de {ART-ACS-03}: 403 nomeado, leitura preservada, verificador de capacidade por especialidade de 1 de 7 para 7 de 7. O cartão permanece [ ] porque o plano alimentar ({F4-03}) ainda falta.

Nota (gate {F4-02}, Drift 6, 2026-09-29): "define meta nutricional" é a primeira capacidade da Matriz aplicada POR ESPECIALIDADE no banco, e nasce em {F4-02}, na migração 0044. Antes dela nenhuma política nem rota do produto distinguia especialidade (medido no gate de {F4-02}, M-3). O auxiliar novo, mfit.tem_vinculo_ativo_na_especialidade(p_aluno, p_especialidade), responde uma pergunta de CAPACIDADE (existe vínculo ativo do usuário atual com o aluno naquela especialidade), não de leitura: o auxiliar único de leitura, {ART-ACS-07}, continua um só. O servidor pergunta o mesmo auxiliar para dizer se a tela oferece Editar metas, sem cópia em TypeScript. O formulário de meta entra no Apêndice de formulários do DRS na mesma republicação.

Fechamento [2026-09-30] de {F4-02}: a capacidade "define meta nutricional" está em produção (migração 0044, https://fit.modulareasy.com) e é a primeira da Matriz aplicada por especialidade no banco: mfit.tem_vinculo_ativo_na_especialidade(p_aluno, p_especialidade) decide, e o servidor pergunta o mesmo auxiliar para a tela oferecer Editar metas. Provado pelo qa: Nutricionista de vínculo ativo grava (201); Personal, Médico e Fisio vinculados leem (200) e não editam (403, 0 linhas); Nutricionista sem vínculo ativo ou ex-vinculado: GET 404, POST 403. Falta o plano alimentar ({F4-03}), por isso o cartão permanece [ ]. Fora do card e declarado: Médico e Nutricionista ainda criam ficha de treino até {AUD-09}, que reusa este auxiliar.

Nota (gate {F4-03}, Drift 3, 2026-09-30): "cria plano alimentar" é a segunda capacidade da Matriz aplicada POR ESPECIALIDADE no banco e usa os DOIS auxiliares de capacidade: para o Nutricionista, mfit.tem_vinculo_ativo_na_especialidade (pergunta sobre o ATOR, {F4-02}); para o aluno sem Nutricionista, mfit.aluno_tem_vinculo_ativo_na_especialidade (pergunta sobre o TITULAR, {F4-03}). Ratificação da Inspeção: a regra de {AUD-09}, "nunca um segundo auxiliar", vale para a pergunta de capacidade do ator, que continua uma só; a pergunta sobre o titular é outra e tem o seu auxiliar. Nutricionista de vínculo encerrado e aluno com Nutricionista ativo não criam plano. O cartão permanece [ ].

Fechamento [2026-09-30] de {F4-03}: a capacidade "cria plano alimentar" está em produção (migração 0052, https://fit.modulareasy.com) e é a segunda da Matriz aplicada por especialidade no banco, com os dois auxiliares da Nota acima. Provado pelo qa: o Nutricionista de vínculo ativo cria plano; o aluno sem Nutricionista ativo cria o próprio (201, autor "eu mesmo"); o aluno com Nutricionista ativo recebe 403 nomeado e 0 linhas; a edição por aluno, Personal e outro Nutricionista é negada; o Administrador recebe 403 nomeado nas seis rotas. Verificador de capacidade por especialidade de 7 de 7 para 12 de 12. Com {F4-02} e {AUD-09} o recorte do papel fecha: o cartão passa a [x].

Para que serve: operar a plataforma inteira, atravessando o isolamento de forma auditável, e deter as sete capacidades de governança que nenhum outro papel alcança.

Relacionado com: RF-CORE-007, RF-CORE-008, RF-CORE-009, RF-CORE-014, RF-PLAN-001, RF-PLAN-002, RF-PAIN-009, RN-010, ADR-017; tarefas F1-09, F1-10, F7-14, AUD-04 e AUD-05; ART-ACS-12 (o papel irmão), ART-ACS-13 (personificação), ART-WF-18 (semente das contas de topo).

Onde fica: políticas de acesso do banco, com política de exceção própria, e guarda de rota nas dez rotas de administração.

Especificação: recorte da matriz do DRS, coluna Super Admin, com escopo total em 41 das 48 capacidades e N nas sete restantes (três do titular: executar e retomar sessão, registrar preferências de treino, e consultar o próprio plano, os limites e o consumo; e quatro por ausência de requisito, já explicadas no Apêndice: criar ficha de treino, duplicar ficha de terceiro, solicitar ficha de treino ao profissional, e atender ou recusar solicitação de ficha). O que o distingue do Administrador são vinte e duas capacidades, e só elas: quatorze da fronteira de dado clínico, detalhadas em {ART-ACS-12}, e oito de governança, que são: 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); consultar a trilha de auditoria (RF-CORE-009); e manter o catálogo de parâmetros de operação (RF-PAIN-011). Valor do papel no tipo mfit.papel_usuario: super_administrador. Contas que o detêm: exatamente as três de topo da plataforma (RN-010), promovidas pela migração de {AUD-04}; qualquer quarta conta exige ato deliberado registrado na auditoria. Toda leitura dele em categoria sensível gera entrada de auditoria de acesso administrativo, igual à do Administrador. Teste mecânico da escada: 41 contra 19, diferença de 22, que se decompõe em 8 de governança mais 14 de dado clínico, dez por classificação e quatro por conteúdo, sem sobra; diferença de uma ou duas reprovaria o desenho, por significar dois nomes para o mesmo papel.

Para que serve: dar à operação do dia a dia o alcance necessário para manter o catálogo, o guia e o atendimento, sem entregar a governança da plataforma e sem lhe dar dado de saúde de aluno nenhum.

Relacionado com: RF-EXER-001, RF-AJUD-002, RF-PAIN-008, RF-PAIN-009, RF-CORE-007 (que declara a fronteira de dado), RF-CORE-010, D.2, D.6, ADR-017; tarefa AUD-04; ART-ACS-06 (o papel acima dele na escada), ART-ACS-07 (o auxiliar que passa a distinguir os dois).

Onde fica: políticas de acesso do banco (inclusive as das entidades clínicas, que passam a negar este papel), auxiliar único de decisão de acesso e guarda de rota das sete rotas de administração comuns.

Especificação: recorte da matriz do DRS, coluna Admin, com escopo total em 20 das 47 capacidades. Valor do papel no tipo mfit.papel_usuario: administrador, valor que já existe e cujo significado muda com {AUD-04}. O que ele ALCANÇA: manter o catálogo global de exercícios e acionar a geração de mídia demonstrativa; manter e publicar o guia da plataforma; ler os relatórios agregados do sistema; criar, buscar e editar cadastro de aluno e de profissional e marcar registro profissional como verificado; gerir vínculos globalmente para resolver caso de suporte; e atravessar o isolamento para ler e operar o dado NÃO CLÍNICO de qualquer aluno (perfil, vínculo, ficha de treino e itens, sessão de treino e séries, solicitação de ficha, preferência de treino, acordo e competência de cobrança e aceite de termos), sempre com entrada de auditoria de acesso administrativo.

O que ele NÃO alcança, e são duas listas fechadas. Primeira, as oito capacidades privativas de governança listadas em {ART-ACS-06}. Segunda, a fronteira de dado clínico, quatorze capacidades em que ele é N, em dois grupos. Dez por classificação: 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: conversar com vinculado, conversar entre profissionais do mesmo aluno, conectar e desconectar serviço de atividade (e ler a atividade importada) e acionar geração assistida de treino, dieta e explicação. Ler preferências de treino fica fora da fronteira, por RN-001. A negação alcança leitura e escrita, e por isso mora na política de acesso por linha das entidades correspondentes, não só na guarda de rota: o auxiliar único de decisão de acesso ({ART-ACS-07}) passa a distinguir os dois papéis de administração, liberando o Super Administrador em toda entidade e o Administrador apenas nas nove não clínicas. 8 mais 14 igual a 22, que é exatamente 41 menos 19, e é esse fechamento que o card TA-92 mede. Motivo: menor privilégio sobre dado de saúde; o chamado que precisa do dado clínico sobe ao Super Administrador, que lê sob consentimento (RF-CORE-007) ou personifica com registro (RF-CORE-014).

Telas: as sete rotas de administração comuns mais /admin/planos em leitura; /admin/auditoria responde negativa a ele; e as telas de saúde, dieta, evolução, conversas e integrações de atividade de aluno respondem negativa a ele em qualquer unidade (B.5), restando-lhe as próprias notificações. Contas que o detêm hoje: nenhuma; o papel nasce vazio em {AUD-04} e se povoa quando um Super Administrador promover alguém.

Nota (gate {F4-01}, Drift 1, 2026-09-29): o mecanismo que faz o auxiliar único distinguir os dois papéis por entidade ({ART-ACS-07}) nasce em {F4-01}, com refeicao, a primeira entidade da fronteira; cada card dono de entidade da fronteira passa o nome da própria entidade como quarto argumento do auxiliar nas suas políticas. A negação de leitura e de escrita descrita na Especificação acima passa a ter efeito por entidade à medida que cada card dono a entrega, e nenhuma delas é contada como entregue antes do fechamento do card dono.

Fechamento [2026-09-30] de {F4-01}: a primeira entidade da fronteira nega este papel em produção. refeicao responde 403 nomeado ao Administrador na leitura própria, na leitura de aluno indicado, na criação e na desativação, sem lista vazia disfarçada de resultado; PATCH, PUT e DELETE não têm rota (404). O painel dele não mostra Nutrição, e /nutricao e /nutricao/refeicoes/nova o redirecionam a /admin. O par positivo, o titular no mesmo alvo, devolve 200. Fronteira: 1 de 13 entidades servidas; as doze restantes seguem com os cards donos.

Para que serve: permitir que o Super Administrador enxergue o sistema como um usuário determinado, para resolver um chamado de suporte, sem que isso aconteça sem rastro nem amplie o alcance de quem personifica.

Relacionado com: RF-CORE-014, RF-CORE-010, D.2, D.5; tarefa AUD-05; ART-ENT-01 (tabela sessao_personificacao e as colunas novas de auditoria), ART-AUD-01 (trilha); a faixa vive no topo de toda tela e não pertence a cartão de tela nenhum, pelo mesmo critério da central de notificações.

Onde fica: servidor de aplicação (início, saída e expiração da sessão personificada), banco de dados (tabela sessao_personificacao e par nas entradas de auditoria) e a faixa no topo de toda tela.

Especificação: início por ação explícita com confirmação nominal a partir de /admin/usuarios, negada a todo papel diferente de Super Administrador e negada quando o alvo é Super Administrador. A sessão personificada decide acesso pelo usuário personificado: o auxiliar único de decisão de acesso ({ART-ACS-07}) recebe o identificador do personificado, nunca o do personificador, e por isso categoria sensível não consentida pelo titular continua bloqueada. Duração máxima de trinta minutos, parâmetro de configuração ({ART-CFG-01}), com dois desfechos, saída explícita e expiração, cada um gravando a entrada de fim com o motivo. Registro: uma linha em sessao_personificacao por personificação (personificador, personificado, início, fim, motivo do fim), apenas acrescida, e o par personificador e personificado carimbado em toda entrada de auditoria gerada no período. Autoria: o registro escrito sob personificação tem como autor o usuário personificado; quem estava por trás vive na trilha, nunca no registro. Interface: faixa permanente no topo de toda tela com nome e papel do personificado, tempo restante e ação de sair, com estado próprio próximo da expiração. Sair da personificação devolve a sessão do Super Administrador sem exigir entrada nova.

Estado: materializado em produção em 2026-09-29 (merge 3dabc30, https://fit.modulareasy.com, migrações 0034, 0035 e 0036, gates plan, qa e review verdes). Provado pelo qa: início a partir de /admin/usuarios, faixa em 44 de 44 telas do aluno, autoria sob personificação gravada como o alvo, negação por 403 para Administrador, profissional, aluno, alvo Super Administrador e o próprio operador, saída sem tela de entrada em 8 de 8 combinações, expiração com o motivo certo. As negações de senha e e-mail não têm rota para provar hoje.

Para que serve: decidir, num só lugar, se quem pergunta pode ler a linha de um aluno, para que toda política de tabela de dado de aluno chame o mesmo auxiliar, e exista um só lugar a auditar.

Nota (onda AUD, {AUD-04}, 2026-09-15): este auxiliar passa a receber também a ENTIDADE consultada, porque o alcance dos dois papéis de administração deixa de ser igual: o Super Administrador é liberado em toda entidade de dado de aluno, e o Administrador apenas nas não clínicas, recebendo negação nas entidades das quatorze capacidades da fronteira de B.1 (RF-CORE-007), que incluem conversa, mensagem, conta de integração e atividade externa, e não apenas as categorias de saúde. O ponto único a auditar continua sendo um só, que é exatamente a razão de a distinção entrar aqui e não ser espalhada por política de tabela; a lista de entidades clínicas vive num lugar só, ao lado dele.

Nota de fronteira (R-6, {F1-19}): o universo deste verificador é a coluna aluno_id das dezoito entidades de E.1. usuario, perfil_aluno e perfil_profissional ficam de fora dele: têm titular por usuario_id e não por aluno_id, e a leitura de terceiro nelas é o quarto placar de {ART-ACS-11}, nunca este auxiliar (usá-lo ali entregaria telefone e e-mail ao vinculado). mfit.plano_plataforma está confirmada desde {F1-13}, com USING (true) intencional e motivo escrito no banco (não é dado de aluno, é informação de produto igual para todos); não é pendência deste verificador nem do quarto placar.

Relacionado com: RF-CORE-006, D.2, ADR-003 e ADR-013; tarefa F1-08; ART-ENT-02 (tabela vinculo, de que o auxiliar depende); ART-ACS-11 (o quarto placar, que cobre usuario, perfil_aluno, perfil_profissional e a confirmação de plano_plataforma).

Onde fica: banco de dados, função mfit.pode_ler_aluno, chamada pela política de leitura de cada tabela de dado de aluno.

Especificação: assinatura mfit.pode_ler_aluno(p_aluno_id uuid, p_autor_id uuid default null, p_restrito boolean default false) returns boolean. Quatro condições avaliadas nesta ordem: primeiro o papel Administrador, que sempre recebe verdadeiro; depois a ausência de claim de sessão, que sempre recebe falso; depois o titular (usuario_atual() = p_aluno_id), que sempre recebe verdadeiro, inclusive na classe restrita; depois, se p_restrito for verdadeiro, falso para qualquer outro (é a classe restrita, que só titular e Administrador leem); por fim, para os demais casos, verdadeiro quando existe vínculo do autor da chamada com o aluno em estado ativo, ou quando p_autor_id corresponde ao autor da chamada (o profissional que foi autor do registro, mesmo com vínculo já encerrado). Classe restrita: conta_integracao e aceite_termos, chamadas com p_restrito = true. Declaração: SECURITY DEFINER com SET search_path = mfit, pg_catalog fixo na própria função, nunca herdado da sessão, e STABLE, não VOLATILE nem IMMUTABLE, para o planejador reaproveitar o resultado dentro da mesma consulta. Gabarito de uso por tabela nova, publicado em db/migrations/GABARITO-ACESSO-ALUNO.md: aluno direto (USING (mfit.pode_ler_aluno(aluno_id, autor_id))), aluno indireto (mesma chamada com subconsulta que resolve o titular pela chave estrangeira) e classe restrita (USING (mfit.pode_ler_aluno(<titular>, NULL, true))), sempre com ENABLE ROW LEVEL SECURITY e política de escrita explícita junto da de leitura. Verificador ops/verifica-acesso-aluno.mjs: reprova toda tabela do esquema mfit com coluna aluno_id sem relrowsecurity verdadeira e sem política que chame o auxiliar; confere nominalmente as dezoito entidades de E.1, reportando cobertas e pendentes; reprova política USING (true) ou concedida a PUBLIC; e imprime a aritmética cobertas + pendentes = 18.

Estado: entregue em F1-08. O auxiliar, a tabela vinculo, o gabarito e o verificador nasceram em {F1-08}, cobrindo hoje aceite_termos; as dezessete entidades restantes de E.1 recebem a política pelo gabarito no card que as cria, até fechar na Fase 8. Nota ({F2-05}): {F2-05} PROVA a condição 2 desta função no caminho de vínculo pendente, sem alterá-la, o décimo sexto verificador mede pendente 0 linha e ativo 1 linha como controle positivo e negativo do mesmo auxiliar. Nota ({F2-06}): o aceite PROVA a condição 2 no caminho oposto, vínculo passando a ativo: com a sessão do profissional, mfit.pode_ler_aluno devolve verdadeiro e a leitura de mfit.consentimento do aluno passa de zero para as linhas concedidas, controle positivo do arnês do H1; a recusa prova a mesma condição negada, pode_ler_aluno falso e zero linhas. Placar pendente 0, recusado 0, ativo 1 (décimo sexto verificador). Nota ({F2-07}): {F2-07} PROVA a condição 3 desta função pela primeira vez no produto (autor com vínculo já encerrado continua lendo), sem alterá-la: com o vínculo em inativo, mfit.pode_ler_aluno com p_autor_id do próprio profissional devolve verdadeiro para as três fichas que ele escreveu, e devolve falso para a quarta ficha de autoria alheia (controle negativo). Placar pendente 0, recusado 0, inativo 0, ativo 1 (décimo sexto verificador). Função inalterada. Nota (gate {F3-01}, Drift 7, 2026-09-14): o universo do critério (a) deste verificador é a lista das tabelas do esquema que têm a coluna aluno_id, e por isso ele NÃO enxerga a tabela que guarda dado de aluno por chave estrangeira para uma tabela pai, sem coluna própria de titular. O gabarito chama essa forma de aluno indireto e nomeia seis tabelas nela (mensagem, acordo_cobranca, ficha_item, sessao_serie, plano_refeicao, refeicao_alimento); nenhuma delas entra no universo de hoje, e o critério (b), que percorre a lista única de entidades de E.1, também não as alcança, porque essa lista é das entidades com titular direto. Consequência medida, não suposta: uma tabela de forma indireta nascendo sem segurança por linha, ou com segurança por linha e sem política, passaria em todos os verificadores, na suíte inteira e nos gates, sem erro e sem aviso, exatamente como a guarda por especialidade passava antes de {F2-08} e como o segundo chamador da leitura reduzida passava antes de {F2-09}. ficha_item é a primeira das seis a nascer, em {F3-01}, e é nesse card que o critério novo entra, com três exigências: lista nominal e fechada das seis tabelas de forma indireta, com o card dono de cada uma e trava síncrona de cardinalidade que recusa carregar o módulo se a lista mudar de tamanho sem alguém atualizar o número; as mesmas exigências do critério (a) aplicadas a elas (segurança por linha habilitada, política de leitura chamando mfit.pode_ler_aluno pela subconsulta que resolve o titular no pai, política de escrita explícita, nada de USING (true) nem concessão a PUBLIC); e a exigência própria da forma indireta, que o gabarito escreve e nenhum critério mede hoje, um índice na chave estrangeira usada pela subconsulta. Obrigatório também o lado negativo, no molde do critério (e) de {F2-08}: trechos fabricados que o critério tem de REPROVAR (tabela de forma indireta sem segurança por linha; com segurança por linha e sem política; com política USING (true); sem índice na chave estrangeira) e trechos que ele tem de ACEITAR. Critério que nunca reprovou nada não é verificador, é enfeite. Placar previsto quando {F3-01} entregar, separado dos demais e nunca somado a eles: 1 servida (ficha_item, {F3-01}) mais 5 pendentes igual a 6. Nada disto move o placar cobertas mais pendentes igual a 18 do critério (a), que segue com o universo próprio.

Nota (gate {F3-03}, Drift 2, 2026-09-14): nasce ao lado deste auxiliar um segundo, de escopo próprio e nome próprio, mfit.pode_editar_por_autoria(p_autor_id uuid), que responde a pergunta de RN-009, "quem edita a linha que tem autor", e não a pergunta deste cartão, "quem lê a linha de um aluno". Ele existe porque a política de UPDATE escrita em 0025 compara o autor com o usuário da sessão de forma crua e por isso recusa o Administrador, a quem RN-009 dá a edição em letra: o requisito está certo e quem diverge é o banco, então a correção é a migração 0026 e nunca o texto de RN-009. Ele entra apenas nas políticas de UPDATE das duas tabelas da ficha e no USING da política de DELETE de ficha_item; no WITH CHECK do INSERT a igualdade crua permanece literal e intocada, porque lá a pergunta é outra, "a autoria nasce de quem escreve", e o Administrador não cria ficha. Ele não substitui mfit.pode_ler_aluno nem mfit.autor_com_acesso_ativo, que continuam nas mesmas conjunções e na mesma ordem: uma conjunção, uma pergunta, e um falso fundido não diz qual negou. É função, e não condição colada em cada política, porque a regra alcança dez entidades com autor de terceiro na lista única e só uma existe hoje: as nove restantes herdam a regra inteira pelo gabarito, e condição colada produz nove oportunidades de colar metade dela. O GABARITO-ACESSO-ALUNO.md ganha no mesmo passo a seção "Autoria por LINHA tem DUAS exceções", ligada às duas que já existem. Placar deste cartão inalterado, cobertas mais pendentes igual a 18, porque o universo aqui é a leitura por titular e nada nele muda.

Fechamento [2026-09-14]: mfit.pode_editar_por_autoria em produção (migração 0026, merge 76bc9cd), liberando o Administrador nas políticas de UPDATE das duas tabelas e no USING do DELETE de ficha_item, sem tocar mfit.pode_ler_aluno nem mfit.autor_com_acesso_ativo. Placar deste cartão continua inalterado, cobertas mais pendentes igual a 18.

Nota (gate {F3-04}, Drift 9, 2026-09-14): mfit.solicitacao_ficha nasce com coluna aluno_id e por isso entra no universo do critério (a) deste verificador, que enumera por catálogo, e passa a ser medida por ele sem ninguém precisar lembrar. E ainda assim o placar cobertas mais pendentes igual a 18 NÃO muda, e o motivo se escreve antes de alguém estranhar: as dezoito são as dezesseis entidades de dado de aluno nomeadas por RF-CORE-006 mais as duas de classe restrita, e a solicitação não está entre as dezesseis por critério de produto, não por esquecimento, porque ela não é um registro do acompanhamento do aluno, é uma mensagem com estado entre duas pessoas. ficha_item, sessao_serie, plano_refeicao e refeicao_alimento ficam de fora da mesma lista pelo mesmo tipo de critério, e ficha_item já nasceu assim em {F3-01}. A tabela é coberta por construção pelo critério que varre o catálogo, e não contada na lista nominal: as duas coisas convivem, e quem olhar o placar depois deste card deve ler este parágrafo antes de supor que alguém esqueceu uma linha. Placar que não muda também se declara.

Nota (gate {F4-01}, Drift 1, 2026-09-29): a distinção por entidade declarada na Nota de {AUD-04} acima não existia no banco quando {F4-01} foi medido: mfit.pode_ler_aluno tinha três argumentos e devolvia verdadeiro ao papel de administração na primeira condição, em toda entidade, e nenhuma entidade clínica existia para revelar o furo (o caso {TA-90} media 0 de 28). {F4-01} cria refeicao, a primeira entidade da fronteira, e por isso o mecanismo nasce ali, na migração 0043. Assinatura de quatro argumentos: mfit.pode_ler_aluno(uuid, uuid, boolean, text), sem valores padrão, sendo o quarto o nome da entidade consultada; a versão de três argumentos continua existindo e delega à de quatro com NULL::text, de modo que nenhuma política existente muda de comportamento e um só corpo decide. Corpo: o Super Administrador recebe verdadeiro em toda entidade; o Administrador recebe NOT mfit.entidade_da_fronteira_clinica(p_entidade); dali em diante valem as condições de sempre. A primeira condição da Especificação abaixo (o papel Administrador sempre recebe verdadeiro) passa a valer só fora da fronteira; a Especificação registra o estado entregue em {F1-08} e não se reescreve. A lista clínica vive ao lado do auxiliar, numa função fechada mfit.entidade_da_fronteira_clinica(p_entidade text), com as treze entidades de E.1 que a fronteira alcança: refeicao, meta_nutricional, plano_alimentar, medida_corporal, foto_progresso, anamnese, avaliacao_fisica, exame, prescricao, sessao_reabilitacao (as dez por classificação que têm entidade em E.1) e mensagem, atividade_externa, conta_integracao (três das quatro por conteúdo; a conversa entre profissionais e a geração assistida não têm entidade própria em E.1 e ficam com os cards donos {F6-01} e {F8-05}). O placar de {ART-ACS-11} e o de {TA-90} só se movem no fechamento, medidos no dia.

Fechamento [2026-09-30] de {F4-01}: o mecanismo está em produção (migração 0043, https://fit.modulareasy.com): mfit.pode_ler_aluno(uuid, uuid, boolean, text) com quatro argumentos e mfit.entidade_da_fronteira_clinica com as treze entidades da nota acima; a versão de três argumentos delega e nenhuma política existente mudou de comportamento (caminho antigo reconferido pelo qa em todos os papéis). refeicao e refeicao_alimento são as primeiras a chamar o auxiliar com o quarto argumento. Medido em produção: o Administrador lê 0 das 4 refeições e o INSERT é negado (42501), o titular lê as 4 refeições e os 9 alimentos, e o controle com três argumentos devolve verdadeiro para o mesmo alvo, o que prova que o quarto argumento é quem nega. Fronteira de dado clínico: 1 de 13 entidades servidas; {TA-90} sobe de 0 de 28 para 2 de 28.

Gabarito de uso, linha nova (gate {F4-01}, Drift 1, 2026-09-29): entidade da fronteira de dado clínico, USING (mfit.pode_ler_aluno(<titular>, NULL, false, '<entidade>')), com o nome da própria entidade como quarto argumento (na filha, o nome da mãe); a política de escrita repete o predicado do titular com o mesmo quarto argumento. Tabela da fronteira com três argumentos entrega o dado ao Administrador em silêncio, e é isso que o critério novo do verificador reprova.

Para que serve: ser o mecanismo único de remoção de dado de aluno, para que toda entidade nasça já com exclusão privativa do Super Administrador e desativação para os demais, sem depender de alguém lembrar.

Relacionado com: RF-CORE-008, RN-008; tarefas {F1-10} e {AUD-04}; ART-ACS-06 (o papel Super Administrador que a política exige).

Onde fica: banco de dados, política FOR DELETE por tabela mais o gatilho genérico de auditoria de remoção; campo removível na lista única de entidades em server/src/acesso/verificarPoliticas.ts.

Especificação: política CREATE POLICY ... FOR DELETE TO mfit_app USING (mfit.e_super_administrador()) em cada uma das onze entidades de RF-CORE-008, por chamada à função de papel e nunca por comparação com literal; nenhum REVOKE DELETE de mfit_app (o privilégio é do role, a política decide por papel). Desativação: estado = 'inativo' em vinculo (já existente); desativado_em timestamptz anulável mais desativado_por uuid referenciando usuario(id) nas oito entidades sem coluna própria; status existente em ficha_treino e plano_alimentar, com a decisão de reaproveitar ou ganhar as duas colunas tomada pelo card dono. Toda exclusão e toda desativação gera entrada de auditoria (excluir em AFTER DELETE, desativar em AFTER UPDATE quando a coluna de desativação muda), sem conteúdo da linha na trilha. DELETE negado por política não lança erro, então a rota confere rowCount e traduz zero em negação explícita. Verificador por critério, nunca por lista escrita à mão: reprova tabela de dado de aluno sem política FOR DELETE, política que não exija o papel de Super Administrador, qualquer comparação com literal de papel dentro de política, função ou gatilho, ausência do gatilho de remoção nas entidades que já existem, e ausência da coluna de desativação declarada. Placar impresso: N servidas + (11-N) pendentes = 11, cada pendente nomeada com o card dono.

Estado: entregue em F1-10: política vinculo_exclusao, mfit.auditar_remocao() e os dois gatilhos (excluir/desativar) em vinculo (migração 0010), seção Remoção em db/migrations/GABARITO-ACESSO-ALUNO.md, campo removível na lista única de entidades em server/src/acesso/verificarPoliticas.ts, verificador por critério com prova negativa, rotas mínimas de vínculo traduzindo zero linhas afetadas em negação explícita. Cobre 1 de 11; as dez restantes recebem política, coluna de desativação e gatilho pelo gabarito no card que as cria, até fechar na Fase 8, quando TA-08 fecha junto.

Nota (gate {F3-03}, Drifts 3 e 9, 2026-09-14): duas declarações, e nenhuma delas muda o placar deste cartão. Primeira: remover um item de uma ficha NÃO é remoção de entidade de RF-CORE-008, é edição do conteúdo da prescrição, com a trilha guardando o que saiu; ficha_item não tem titular próprio e não pertence às onze entidades removíveis, então a política de exclusão de item que {F3-03} cria em 0026 segue a regra de autoria do card e não a regra de exclusão privativa do Administrador. Sem esta declaração, a leitura ingênua de RN-008 tornaria o autor incapaz de tirar um exercício da própria ficha, invertendo ADR-006 no card que existe para sustentá-lo. A política de exclusão da ficha inteira fica intocada, privativa do Administrador, e nenhuma tela a oferece. Segunda: a desativação da ficha ganha caminho de escrita em {F3-03}, por rotas próprias de desativar e de reativar, no molde literal das rotas de vínculo, nunca por um campo de formulário de edição; ela existia no banco desde {F3-01} (coluna de estado, política, gatilho e contagem) e não tinha uma única porta, o que deixava o aluno no teto do plano sem nenhuma ação disponível. O placar de remoção deste cartão fica inalterado; o que se move com {F3-03} é o caso de teste {TA-08}, de 1 de 11 para 2 de 11, sem fechar.

Fechamento [2026-09-14]: as duas declarações confirmadas em produção (76bc9cd): a política de exclusão de ficha_item segue a regra de autoria, não a de RF-CORE-008, e a ficha inteira continua exclusão privativa do Administrador; desativar e reativar ganham rota própria. Placar deste cartão continua inalterado; {TA-08} sobe para 2 de 11, sem fechar.

Nota (gate {F3-04}, Drift 11, 2026-09-14): o placar de remoção deste cartão fica inalterado, e o motivo se escreve. mfit.solicitacao_ficha nasce com política de exclusão privativa do Administrador, exatamente como o gabarito manda, mas não é uma das onze entidades de RF-CORE-008: ela recebe a política por CRITÉRIO, porque o verificador varre toda tabela de dado de aluno do esquema, e não por pertencer à lista das onze. Somar uma coisa na outra faria o denominador crescer toda vez que uma tabela nova nascesse, e o placar deixaria de medir o que RF-CORE-008 enumera. O aluno e o profissional não excluem a solicitação; o que a resolve é transição de estado, que preserva a trilha, e apagar o pedido no ato de respondê-lo seria perder exatamente o texto que explica o que o aluno queria.

Para que serve: impedir, na camada de dados, a escrita de categoria sensível sem consentimento ativo do titular, e retirar a categoria revogada da visibilidade do profissional.

Relacionado com: RF-CORE-010, RN-001, RN-003, ADR-010; tarefa {F1-12}; ART-ENT-01 (tabela consentimento), ART-SM-04 (a máquina de estados), ART-WF-10 (a revogação), ART-AUD-01 (a auditoria de concessão e revogação), ART-ACS-07 (o auxiliar de acesso, ao lado do qual este entra na leitura, nunca no lugar dele).

Onde fica: banco de dados, funções mfit.tem_consentimento e mfit.consentimento_visivel, chamadas pela política de cada tabela sensível; rotas GET/POST/DELETE /api/consentimentos.

Especificação: assinaturas mfit.tem_consentimento(p_aluno_id uuid, p_categoria mfit.categoria_sensivel) returns boolean e mfit.consentimento_visivel(p_aluno_id uuid, p_categoria mfit.categoria_sensivel) returns boolean, ambas STABLE, SECURITY DEFINER, SET search_path = mfit, pg_catalog fixo na própria declaração. tem_consentimento: existe linha de consentimento daquela categoria, daquele aluno, com revogado_em IS NULL; entra em conjunção no WITH CHECK das políticas de INSERT e de UPDATE de cada tabela sensível. consentimento_visivel: decide se o leitor enxerga a categoria, nesta ordem, papel administrador sempre verdadeiro, titular sempre verdadeiro, sem consentimento ativo falso, restrito_a_especialidades nulo verdadeiro (padrão de RN-003, todas as especialidades vinculadas), senão verdadeiro apenas se a especialidade do leitor estiver no array; entra em conjunção no USING da política de SELECT de cada tabela sensível, ao lado de mfit.pode_ler_aluno, nunca no lugar dela. O que estas funções NÃO decidem: acesso (isso é mfit.pode_ler_aluno), auditoria de leitura (isso é leituraSensivel.ts), plano e limite (isso é {F1-15}). Campo categoriaConsentimento na lista única ENTIDADES_E1, não nulo exatamente nas seis entidades marcadas sensivel: true. Rotas: GET devolve as seis categorias sempre, cada uma com estado; POST carimba versao_texto e finalidade do ponto único de configuração, nunca do corpo da requisição, e traduz concessão repetida em 409 com a linha ativa; DELETE é a revogação, confere rowCount e traduz zero em negação explícita. Verificador por catálogo, dois critérios: (g) toda entidade sensivel: true que exista tem política FOR INSERT/FOR UPDATE cujo WITH CHECK chama mfit.tem_consentimento com o literal de categoriaConsentimento, e política FOR SELECT cujo USING chama mfit.consentimento_visivel além de mfit.pode_ler_aluno; (h) bijeção entre categoriaConsentimento e os seis valores do enum mfit.categoria_sensivel lidos de pg_enum. Placar impresso: servidas + pendentes = 6, nunca misturado com os placares de leitura (19), remoção (11), sensível (6) nem imutabilidade (2).

Estado: entregue em F1-12: mecanismo, auxiliares, gabarito e verificador no ar cobrindo 0 de 6 entidades sensíveis; cada uma nasce já servida no card dela (Fase 5). Nota ({F2-06}): o aceite exercita mfit.consentimento como PROVA do H1 (categoria já concedida via /privacidade antes do aceite), sem tocar as duas funções: a cláusula "categorias consentidas" do RF-VINC-002 se prova hoje por mfit.consentimento e mfit.pode_ler_aluno (ART-ACS-07), porque nenhuma das seis entidades sensíveis existe ainda. Placar de entidades sensíveis inalterado, 0 de 6.

Nota (Inspeção, {AUD-11}, 2026-09-30): o tipo mfit.categoria_sensivel passa de seis para sete valores, com nutricao; o mecanismo e as duas funções não mudam, e as entidades que decidem acesso por categoria passam de seis para dez tabelas (as seis de saúde, medida_corporal na categoria avaliação física, e refeicao, meta_nutricional e plano_alimentar). Placar por entidade coberta: hoje 0 de 10; sobe para 2 de 10 quando {AUD-11} entregar (refeicao e meta_nutricional) e para 3 de 10 com {F4-03}. O universo do leitor único de {ART-AUD-02} cresce da mesma forma.

Nota (Inspeção, {AUD-11}, drift 7, 2026-09-30): a ficha põe mfit.consentimento_visivel só no USING da política de leitura. Para meta_nutricional ele entra também no WITH CHECK da inserção, em conjunção com mfit.tem_consentimento, porque o profissional fora da restrição escolhida pelo aluno que gravasse sem poder ler quebraria a regra de vigência "nunca atrás" e escreveria o que não pode ler (RN-003, RF-CORE-010). Vale para plano_alimentar em {F4-03}; refeicao não é afetada, porque só o titular a escreve. As funções não mudam.

Fechamento [2026-09-30] de {AUD-11}: placar por entidade coberta 2 de 10 (8 pendentes: plano_alimentar em {F4-03}, medida_corporal em {F5-07} e as seis de saúde na Fase 5). refeicao e meta_nutricional estão em produção (migrações 0046 e 0047, https://fit.modulareasy.com) com mfit.consentimento_visivel(aluno_id, 'nutricao') na leitura e mfit.tem_consentimento(aluno_id, 'nutricao') na escrita (na inserção de meta_nutricional, as duas, conforme a Nota do drift 7), e refeicao_alimento com a mesma conjunção pela linha mãe. O tipo mfit.categoria_sensivel tem 7 valores. A Especificação acima, escrita para seis, lê-se com sete: GET /api/consentimentos devolve as sete categorias sempre, e o critério (h) passa de bijeção a igualdade de conjuntos (toda categoria do enum reivindicada por ao menos uma entidade, nenhuma fora dele), de modo que duas entidades podem reivindicar a mesma categoria: 7 = 7. A meta padrão nasce na concessão de nutrição, pelo ponto único concederConsentimento, e a função de semente recusa (42501) sem consentimento. As duas funções tem_consentimento e consentimento_visivel não mudaram. O cartão permanece [x].

Para que serve: ser a única porta pela qual um usuário enxerga o perfil de outro, entregando exatamente os quatro campos públicos de D.2 e nenhum outro, na camada de dados, sem depender de a interface esconder campo nenhum.

Relacionado com: RF-CORE-004, RF-CORE-006, D.2, ADR-003, ADR-013; tarefa {F1-19}; ART-ENT-01 (tabelas usuario, perfil_aluno e perfil_profissional, de onde ela lê); ART-ACS-07 (fronteira declarada na Nota dela, R-6).

Onde fica: banco de dados, tipo composto mfit.perfil_publico_reduzido e função mfit.perfil_publico(p_usuario_id uuid); ponto único no servidor server/src/acesso/perfilPublico.ts; rota GET /api/perfil/:usuarioId.

Especificação: tipo composto mfit.perfil_publico_reduzido com exatamente quatro atributos, nominais e fechados: nome text, foto_caminho text, especialidade mfit.especialidade_profissional (nula quando o outro não é profissional) e registro text (nula quando o outro não é profissional); nunca um quinto atributo, nunca papel no retorno. Função mfit.perfil_publico(p_usuario_id uuid) returns mfit.perfil_publico_reduzido, language sql stable security definer set search_path = mfit, pg_catalog, resolve a foto pela tabela de perfil do papel do titular por dentro da própria função; não decide acesso (não pergunta vínculo, não audita), decide só o recorte. RLS ligada em mfit.usuario, mfit.perfil_aluno e mfit.perfil_profissional: política de SELECT só para o titular (usuario_atual()/usuario_id = usuario_atual()) e para o Administrador (papel_atual() = 'administrador'), nunca para o vinculado; sem política de INSERT em usuario (o único INSERT passa por mfit.criar_usuario, função definer); WITH CHECK de perfil_aluno com AND mfit.autor_com_acesso_ativo() fora dos parênteses da expressão de titular; perfil_profissional sem essa conjunção, por não ter escrita de aluno; REVOKE DELETE ON mfit.usuario, mfit.perfil_aluno, mfit.perfil_profissional FROM mfit_app nas três, para que a exclusão negada seja erro de permissão e não zero linhas. Nove caminhos sem claim de sessão, tratados por dois mecanismos: promoção de claim (set_config dentro da transação, depois de a identidade ser provada pelo consumo do token de uso único) na redefinição de senha e na confirmação de e-mail; cinco funções SECURITY DEFINER estreitas para os demais, cada uma devolvendo só as colunas do caminho que serve, nunca aceitando nome nem fazendo LIKE: mfit.credencial_por_email (entrada), mfit.conta_ativa_por_email (pedido de recuperação), mfit.nome_do_usuario (abertura de link de redefinição e rotina de e-mail, os dois caminhos), mfit.papel_do_usuario (renovação de sessão) e mfit.criar_usuario (cadastro, resolve a armadilha do RETURNING da política de SELECT). Rota GET /api/perfil/:usuarioId: alvo é o próprio solicitante devolve perfil completo; solicitante Administrador devolve perfil completo do alvo com registro de auditoria (acesso_administrativo, mesma transação da leitura, entidade = perfil_aluno ou perfil_profissional, campo/valor_anterior/valor_novo nulos); qualquer outro autenticado devolve a leitura reduzida, sem vínculo exigido; a chave de consulta é o identificador interno, nunca identificador_publico. Quarto placar em ops/verifica-acesso-aluno.mjs, núcleo server/src/acesso/verificarPerfilPublico.ts, quatro critérios: (a) RLS e política por linha nas quatro tabelas da lista TABELAS_DO_PERFIL (usuario, perfil_aluno, perfil_profissional, plano_plataforma confirmada), nenhuma citando mfit.pode_ler_aluno; (b) o tipo composto com exatamente os quatro atributos, por igualdade de conjunto nominal, nunca por ausência dos oito; (c) varredura estática de server/src proibindo SELECT direto nas três tabelas fora de uma lista autorizada e nominal; (d) os oito campos privados de D.2 (telefone, nascimento, sexo, altura_cm, identificador_publico, plano, status_acesso, email), mais senha_hash e biografia, ausentes da resposta HTTP real. Placar impresso: 4 tabelas do perfil = 3 ligadas em {F1-19} + 1 confirmada em {F1-13}; 4 campos públicos + 8 campos privados nominados negados; 9 caminhos sem claim = 6 por função definer + 2 por promoção de claim + 1 por política existente.

Estado: entregue em {F1-19} (2026-09-13): tipo composto, função de leitura reduzida, cinco funções definer estreitas, dez políticas nas três tabelas, três REVOKE DELETE, rota GET /api/perfil/:usuarioId com o ramo do Administrador auditado, quarto placar do verificador, oitava seção do gabarito ("Perfil público reduzido"). Não fecha {TA-06} (nota em {TA-06}, R-3): o placar N de 36 do isolamento de dados de aluno não se move, porque usuario, perfil_aluno e perfil_profissional não estão entre as dezoito entidades de E.1. Nota ({F2-05}): a sexta função SECURITY DEFINER estreita, mfit.usuario_por_identificador_publico, nasceu em {F2-05}; ela roda COM claim de sessão (o profissional autenticado), então o placar 9 caminhos sem claim desta ficha não se move. Nota (gate {F2-09}, Drift 3, 2026-09-14): o comentário desta função no banco e o do módulo no servidor afirmam ponto único, mas nenhum critério mede isso: o critério (c) do quarto placar varre server/src por citação das três tabelas do perfil, nunca por chamada da função, então um segundo chamador passaria calado por todos os verificadores, pela suíte inteira e pelos três gates. {F2-09} precisa do segundo chamador (a listagem global resolve as duas pontas de cada linha por junção lateral com mfit.perfil_publico, numa consulta só, sem citar nenhuma das três tabelas, em vez de resolver uma ponta por chamada dentro de um laço), e por isso a afirmação deixa de ser caneta e passa a ser medida, em duas peças: (1) critério novo no quarto placar varrendo server/src por chamada de mfit.perfil_publico, com lista nominal autorizada de DOIS arquivos (o ponto único do servidor e a listagem administrativa de vínculos), excluindo os arnês e o próprio verificador, com lado positivo obrigatório, um trecho fabricado que ele tem de reprovar e um que tem de aceitar; (2) o comentário da função reescrito na migração seguinte, dizendo o que passa a ser verdade, que o ponto único da FORMA HTTP continua sendo o módulo do servidor e que existe um segundo chamador, em SQL, na listagem administrativa, nominal e medido pelo critério novo. O que não muda: campo privado não cabe no tipo de retorno de quatro atributos, então o segundo chamador não amplia o que D.2 permite ver; o que ele amplia é o número de lugares que montam a forma reduzida, e é disso que o critério novo passa a cuidar. O placar 9 caminhos sem claim continua inalterado, porque a listagem roda com claim de sessão do Administrador. Fechamento [2026-09-14]: o segundo chamador está em produção (server/src/rotas/admin/vinculos.ts), a lista nominal autorizada do critério novo tem exatamente dois arquivos, e o COMMENT ON FUNCTION mfit.perfil_publico(uuid) foi reescrito na migração 0024_gestao_global_de_vinculos.sql, dizendo o que passa a ser verdade: ponto único da forma HTTP continua em acesso/perfilPublico.ts, e existe um segundo chamador, em SQL, na listagem administrativa. A afirmação de ponto único deixou de ser caneta. Nota de decisão declarada (gate {F3-01}, 2026-09-14): {F3-01} traz o TERCEIRO chamador de mfit.perfil_publico, porque a lista de fichas do aluno e o detalhe da ficha exibem o nome do autor, e a regra da casa proíbe SELECT próprio nas três tabelas do perfil. A lista nominal autorizada do critério (d) passa de dois para três arquivos, e a trava síncrona de cardinalidade passa de 2 para 3 no mesmo commit, junto do comentário da função reescrito para dizer o que passa a ser verdade. A trava recusar carregar com três entradas até alguém atualizar o número é o comportamento desejado, não um obstáculo: ampliar a lista é uma DECISÃO, nunca um efeito colateral. O que não muda: o tipo de retorno tem exatamente quatro atributos, então campo privado de D.2 não cabe nele e o terceiro chamador não amplia o que se pode ver, só o número de lugares que montam a forma reduzida. O placar 9 caminhos sem claim segue inalterado, porque as duas telas rodam com claim de sessão. Fechamento [2026-09-14]: o terceiro chamador está em produção (server/src/fichas/fichas.ts, merge 17bd22e), a lista nominal autorizada do critério (d) tem exatamente três arquivos, a trava síncrona recusa carregar com número diferente de 3, e o COMMENT ON FUNCTION mfit.perfil_publico(uuid) foi reescrito na migração 0025_ficha_de_treino.sql. Placar impresso pelo qa: chamadores nominais 3 de 3. Nenhum campo privado no retorno, LEFT preservado (autor que não resolva aparece com nome nulo, nunca some da lista).

Nota (gate {F3-02}, 2026-09-14): {F3-02} consome a leitura reduzida pelos chamadores que já existem e não acrescenta um quarto. Quem lê o nome do autor da ficha continua sendo o módulo de fichas, pela mesma junção lateral escrita em {F3-01}, e a obrigação da Nota R-4 do roadmap (consumir a leitura reduzida, nunca um SELECT próprio) é cumprida sem tocar em nada. A lista nominal de chamadores autorizados continua em três.

Fechamento [2026-09-14]: confirmado inalterado. Em produção (3d25e27), nenhum quarto chamador nasceu. Lista nominal continua em três.

Para que serve: decidir, na camada de dados, se a escrita de um vínculo em estado ativo respeita o limite do plano do aluno titular, e traduzir a recusa numa mensagem que nomeia o limite e o plano que o amplia.

Relacionado com: RF-PLAN-003, RF-VINC-002 a 004, L.1, ADR-012, ADR-013; tarefa {F1-15}; ART-ACS-07 (o auxiliar de acesso, ao lado do qual este entra na conjunção, nunca fundido), ART-ACS-09 (o auxiliar de consentimento, mesma disciplina de auxiliar único por pergunta), ART-SM-01 (a máquina de estados que a guarda governa), ART-ENT-02 (a tabela vinculo de que o auxiliar depende).

Onde fica: banco de dados, quatro funções empilhadas mais uma de apoio, chamadas pelas políticas de escrita de mfit.vinculo e pela rota GET /api/meu-plano; servidor de aplicação, tradutor único server/src/planos/negacaoDeEscrita.ts.

Especificação: quatro funções empilhadas, cada uma com um trabalho só, mais uma de apoio: mfit.limite_do_aluno(aluno_id, dimensao) lê o limite do plano, existente desde {F1-13}; mfit.dentro_do_limite(aluno_id, dimensao, contagem) compara contagem contra limite, nulo é ilimitado, existente desde {F1-13}; mfit.consumo_do_aluno(aluno_id, dimensao, ignorar_id) conta, com SECURITY DEFINER, existente desde {F1-16}; mfit.dentro_do_limite_do_aluno(aluno_id, dimensao, ignorar_id) decide, devolvendo verdadeiro antes de chamar consumo_do_aluno quando a dimensão é ilimitada, e chamando as outras três para as demais decisões. A contagem saiu do decisor para consumo_do_aluno em {F1-16} porque a tela do plano precisa do número e o decisor devolve um booleano, e duplicar o CASE na rota seria o defeito que a Nota do card manda evitar; consumo_do_aluno não decide acesso nenhum e nunca entra num WITH CHECK diretamente, quem entra na política continua sendo dentro_do_limite_do_aluno. Mais mfit.plano_que_amplia(aluno_id, dimensao), que devolve o primeiro plano ativo cuja coluna da dimensão é maior que o limite atual ou nula, por ordem de limite crescente com nulo por último, depois valor de referência crescente com nulo por último, depois nome. A conjunção de limite entra só no WITH CHECK das duas políticas de escrita de mfit.vinculo, guardada por estado = 'ativo', nunca em pendente, recusado, cancelado ou inativo, e excluindo a própria linha por id. Nunca se funde com mfit.pode_ler_aluno, mfit.tem_consentimento nem mfit.autor_com_acesso_ativo: cada auxiliar responde uma pergunta só, acesso, consentimento ou limite, e um auxiliar fundido devolveria um "falso" que não diz qual pergunta negou. O tradutor único negacaoDeEscrita.ts transforma o erro de permissão do banco em resposta nomeada, perguntando acesso antes de limite (ordem de RF-PLAN-003), envolto em SAVEPOINT porque o erro aborta a transação da requisição. Gabarito: seção "Limite de plano por dimensão" em db/migrations/GABARITO-ACESSO-ALUNO.md, aplicada por toda tabela que materializa uma dimensão ao nascer, acrescentando o ramo dela ao CASE de dentro_do_limite_do_aluno; dimensão sem ramo levanta exceção, nunca aprova em silêncio. Placar impresso: 1 servida + 3 pendentes de tabela + 1 pendente de forma + 1 fora do universo de escrita = 6, as seis dimensões de L.1.

Nota ({F2-06}): o aceite entra como segundo caminho de escrita a acionar este auxiliar dentro de SAVEPOINT, ao lado do de {F2-05}; a recusa passa pelo mesmo tradutor mas nunca aciona a conjunção de limite, porque a guarda estado <> 'ativo' da política a exclui por construção, controle negativo provado no arnês do H1 de {F2-06}. Placar de dimensões inalterado, 6.

Nota (Inspeção, gate {F5-04}, Drift 10, 2026-10-06): a dimensão de espaço de armazenamento de anexos ganha o ramo no CASE de mfit.consumo_do_aluno em {F5-04}, a entregar: a soma de anexo_bytes dos exames do aluno, em megabytes arredondados para cima (a foto de progresso entra em {F5-08}); o exame desativado segue na soma, porque o objeto continua no repositório. A política de inserção do exame usa a forma genérica, consumo anterior menor que o limite, como as demais dimensões; a soma com o anexo novo é decidida pelo servidor ANTES de gravar o objeto, com a mensagem de limite existente, porque a política não conhece os bytes de um arquivo que ainda não foi gravado. mfit.dentro_do_limite_do_aluno não muda e nenhum auxiliar novo nasce. A tela /plano passa a exibir a dimensão sozinha, sem linha de código de front. O cartão continua [x].

Fechamento [2026-10-06] de {F5-04}: o ramo anexos_megabytes está em mfit.consumo_do_aluno em produção (migração 0059, merge b078e76): soma de anexo_bytes de toda linha do titular, ativa ou desativada, em megabytes arredondados para cima; os três ramos antigos, a assinatura e a mensagem do ELSE ficaram idênticos (provado no aborto da migração). A política do exame usa a forma genérica e o servidor decide a soma com o anexo novo antes de gravar o objeto. Provado em produção no plano Gratuito (100 megabytes): cinco envios de 20 MiB fecham 100 de 100, o sexto recebe 409 com a mensagem de limite, e o exame desativado segue na cota (21 megabytes antes e depois). Lacuna declarada: a soma com o anexo novo arredonda duas vezes e pode recusar um arquivo que caberia por até 1 megabyte (desvio 4 declarado, aceitável; documentar na tela do plano). mfit.dentro_do_limite_do_aluno não mudou e nenhum auxiliar nasceu. O cartão continua [x].

Para que serve: ser o único caminho pelo qual qualquer rota do servidor lê uma das seis entidades sensíveis de RN-001, registrando o acesso administrativo cross-unidade na mesma transação da leitura.

Relacionado com: RF-CORE-007, D.5, ADR-013; tarefa F1-09; ART-ENT-01 (coluna aluno_id da trilha), ART-AUD-01 (a trilha).

Onde fica: servidor de aplicação, server/src/acesso/leituraSensivel.ts, chamado por toda rota que sirva uma das seis entidades sensíveis.

Especificação: assinatura lerRegistroSensivel({ client, claims, entidade, id }): Promise<Registro | null>. Condição que dispara o registro: claims.papel === 'administrador' e claims.sub diferente do titular da linha lida; titular, profissional vinculado e profissional autor não geram entrada. Garantia de transação única: o registro e a leitura ocorrem na mesma transação já aberta por sessaoAtual; se a inserção da auditoria falhar, a leitura não é servida (rollback). Coluna a coluna da linha gravada: autor_id recebe claims.sub, autor_papel recebe claims.papel, acao recebe acesso_administrativo, entidade recebe o nome da tabela, entidade_id recebe o id do registro lido, aluno_id recebe o titular do registro, campo, valor_anterior e valor_novo ficam nulos (leitura não copia conteúdo clínico para a trilha), origem vem de current_setting('mfit.origem'), momento vem de now(). Arquivo: a emissão de endereço assinado de foto_progresso passa pelo mesmo leitor, e o registro acontece na emissão, não no download. O que ele NÃO decide: acesso (isso é mfit.pode_ler_aluno), consentimento, escrita, listagem. Verificador ops/verifica-leitura-sensivel.mjs: reprova toda ocorrência do nome de tabela sensível em SQL fora deste arquivo; confere nominalmente as seis entidades de RN-001, cobertas ou pendentes por card dono; reprova entrada acesso_administrativo com aluno_id nulo ou emissão de endereço assinado de arquivo sensível fora do leitor; imprime a aritmética servidas + pendentes = 6.

Estado: entregue em F1-09. O leitor, a marcação sensivel e o verificador nascem em {F1-09}, cobrindo hoje 0 das 6 entidades sensíveis (nenhuma existe ainda); cada uma nasce já servida pelo leitor no card dela (Fase 5), até fechar em 6 de 6.

Nota (Inspeção, {AUD-11}, drift 1, 2026-09-30): o universo deste leitor passa de seis para dez entidades sensíveis (as seis de saúde, medida_corporal, refeicao, meta_nutricional e plano_alimentar), e as duas frases da ficha ficam ampliadas. Onde fica passa a ser server/src/acesso/leituraSensivel.ts, ou o ponto único do módulo declarado em leitorUnico, que chama registrarSeAdministrativo. Especificação: cada entidade sensível declara o seu leitor, no campo leitorUnico (caminho relativo a server/src) da lista única ENTIDADES_E1, não nulo exatamente nas entidades sensíveis: acesso/leituraSensivel.ts para as seis de saúde, para medida_corporal e, provisoriamente, para plano_alimentar ({F4-03} declara o seu); refeicoes/refeicoes.ts para refeicao e metas/metas.ts para meta_nutricional. Todo leitor declarado que não seja acesso/leituraSensivel.ts chama registrarSeAdministrativo( com o nome da entidade, de modo que a auditoria de leitura administrativa (RF-CORE-007) segue na mesma transação da leitura. O verificador ops/verifica-leitura-sensivel.mjs troca a regra "toda ocorrência do nome de tabela sensível fora deste arquivo reprova" por duas: (a) ocorrência de mfit.<tabela> em arquivo .ts de produção fora do leitorUnico DAQUELA entidade reprova; (a2) leitor declarado que não seja leituraSensivel.ts e não contenha registrarSeAdministrativo( e o nome da entidade reprova. Arquivos .test.ts saem do universo (fixture não serve leitura a usuário), o que se compensa com o critério positivo (a2) e com decoy (mfit.refeicao em arquivo de produção fora do leitor reprova; leitor declarado sem a chamada reprova). Motivo: sem esta declaração, marcar refeicao e meta_nutricional como sensíveis reprovaria os dois pontos únicos de módulo de {F4-01} e {F4-02} e cerca de oitenta linhas de fixture. Placar impresso pelo verificador, sem número escrito à mão: servidas + pendentes = 10, hoje 0 de 10, e 2 de 10 quando {AUD-11} entregar (refeicao e meta_nutricional); e, dos leitores de módulo, 2 de 2 com registrarSeAdministrativo. Isenção dos testes (gate modularfit-AUD-11, Drift 1, 2026-09-30): arquivos .test.ts ficam isentos do critério (a) do leitor único, e a isenção vale para as dez entidades sensíveis, não só para as duas de nutrição. Texto do gate: "Arquivos *.test.ts saem do universo (fixture não serve leitura a usuário)". Motivo medido no gate (M-8 e M-9): o critério (a) de {F1-09} reprovava toda ocorrência de mfit.<tabela sensível> em qualquer .ts de server/src, testes inclusos, fora de acesso/leituraSensivel.ts; as ocorrências de mfit.refeicao e mfit.meta_nutricional são 9 nos pontos únicos refeicoes.ts e metas.ts mais cerca de oitenta em 16 arquivos .test.ts, e a fixture de teste semeia e confere dado, não serve leitura a usuário. A isenção cobre somente o critério (a): o critério (a2) segue valendo para todo leitor declarado, e a compensação do gate (R-5) é o critério positivo (a2) mais o decoy (mfit.refeicao em arquivo de produção fora do leitor reprova; leitor declarado sem a chamada reprova).

Fechamento [2026-09-30] de {AUD-11}: placar do leitor único 2 de 10 servidas (2 servidas mais 8 pendentes igual 10): refeicao por refeicoes/refeicoes.ts e meta_nutricional por metas/metas.ts, cada uma chamando registrarSeAdministrativo com o nome da entidade (critério (a2), 2 de 2 leitores de módulo). O campo leitorUnico está nas 10 entidades sensíveis e nulo nas demais, com as travas de carga 10, 10 e leitorUnico igual a sensível, entidade a entidade. Os arquivos *.test.ts saíram do universo do critério (a), compensados por (a2) e por decoys nos dois sentidos. Em produção o Super lê as duas entidades com 200 e a trilha grava a entrada na mesma leitura (+4 entradas), e o Administrador segue com 403 nomeado. O cartão permanece [x].

Para que serve: governar quando o profissional passa a enxergar e deixa de enxergar o aluno.

Relacionado com: RF-VINC-001 a 004; tarefas F2-05 a F2-08.

Onde fica: coluna vinculo.estado e as regras de transição no servidor.

Especificação: tabela de transições do bloco E.3 do DRS. Estado inicial pendente; terminais recusado, cancelado e inativo; transições proibidas: pendente direto para inativo e ativo de volta para pendente. Guarda de entrada em pendente: não existir vínculo ativo nem pendente entre aquele profissional e aquele aluno. Guarda de entrada em ativo: limite de vínculos do plano do aluno não excedido, guarda que passa a existir na camada de dados em {F1-15}, no WITH CHECK das duas políticas de escrita de mfit.vinculo (ART-ACS-10); {F2-06} não a reimplementa no servidor, a máquina de estados dele confia na política e chama o tradutor único de {F1-15} para produzir a mensagem, sem uma segunda verificação no tratador. A especialidade não é guarda de transição nenhuma. Efeito colateral de cada transição: notificação conforme a lista nominal do bloco M.1 do DRS (nem toda transição notifica as duas partes; o cancelamento notifica só o aluno), e revogação imediata do acesso corrente quando sai de ativo.

Estado: medido em 14/09/2026 (gate {F2-07}). O caminho de escrita que leva ativo a inativo já existe desde {F1-10} (desativarVinculo, em server/src/rotas/vinculo.ts), mas hoje não respeita esta tabela: o UPDATE é WHERE id = $1 AND estado <> 'inativo', então um vínculo pendente vira inativo com 204, produzindo a transição proibida pendente para inativo direto. A validação da tabela de transições como lista única, por gatilho BEFORE UPDATE na origem, nasce em {F2-07}; até aqui o único controle era o WHERE de cada rota, isto é, exaustividade por disciplina, não por construção. O caminho de cancelamento (pendente para cancelado) também nasce em {F2-07}, hoje inexistente. Fechamento [2026-09-14] de {F2-06}: as duas transições do aluno passam a servida: true (pendente para ativo, pendente para recusado), guardadas pela política de {F1-15}/{ART-ACS-10} sem segunda verificação no tratador, como esta ficha já previa. Placar do décimo sexto verificador (ops/verifica-vinculo.mjs): 4 de 6 transições servidas (a prova de reconvite rodou), mais o lado negativo nomeado, as duas transições proibidas de E.3 e o caminho de escrita medido que as alcança hoje (POST /api/vinculos/:id/desativar), dono {F2-07}. pendente para cancelado, ativo para inativo e a validação da tabela inteira por gatilho BEFORE UPDATE continuam em {F2-07}. Fechamento [2026-09-14] de {F2-07}: gatilho mfit.validar_transicao_vinculo() (BEFORE UPDATE OF estado ... WHEN (OLD.estado IS DISTINCT FROM NEW.estado)) valida a tabela de E.3 como lista única na origem, nunca mais só pelo WHERE das rotas; pendente para cancelado (rota nova /cancelar) e ativo para inativo (/desativar consertado) passam a servida: true. Aritmética das seis transições de E.3: quatro por UPDATE servidas (pendente para ativo, pendente para recusado, pendente para cancelado, ativo para inativo) mais o reconvite inativo para pendente (linha nova, INSERT, não UPDATE) mais a entrada (inexistente) para pendente (o convite, INSERT) fecham 6 de 6. As duas proibidas (pendente para inativo direto, ativo para pendente) são recusadas na origem pelo gatilho, P0001, controle negativo provado no arnês encerramento.test.ts. Placar do décimo sexto verificador: 6 de 6 transições servidas, 6 de 6 transições notificando por construção (gatilhos 0021, 0022, 0023). Nota (gate {F2-08}, 2026-09-14): placar de transições inalterado, 6 de 6, este card não serve transição nenhuma; acrescenta a prova de que a especialidade não é guarda de transição nenhuma, critério (e) do mesmo verificador, universo de catálogo em mfit.vinculo. Nota (gate {F2-09}, 2026-09-14): placar de transições inalterado, 6 de 6, este card não serve transição nenhuma; prova, no arnês, que o filtro de listagem por especialidade não altera acesso (o vínculo escondido pelo filtro continua ativo e continua dando acesso), reforçando a mesma distinção entre filtro e guarda. Nota (gate {F3-01}, 2026-09-14): placar de transições inalterado, 6 de 6, este card não toca mfit.vinculo nem transição nenhuma; a ficha de treino é entidade nova, com máquina de estados própria e menor (ativo/inativo, D-1), sem gatilho BEFORE UPDATE de validação, porque E.3 não lhe atribui transição proibida nenhuma.

Nota (gate {F3-02}, 2026-09-14): nenhuma transição de vínculo é criada, alterada ou exercitada de forma nova. Este card entrega justamente o caminho que NÃO depende de vínculo (ADR-002, o aluno sem profissional monta a própria ficha), e o vínculo que o caso de teste cria depois usa as transições já fechadas em {F2-07}. Placar inalterado, 6 de 6.

Fechamento [2026-09-14]: confirmado inalterado. Em produção (3d25e27), nenhuma transição de vínculo nova. Placar continua 6 de 6.

Nota (gate {F3-03}, 2026-09-14): nenhuma transição de vínculo é criada, alterada ou exercitada de forma nova. O estado que {F3-03} passa a escrever é o da ficha (ativo e inativo), que é outro autômato, declarado em E.3 e coberto pelo cartão da própria entidade; o vínculo entra apenas como condição de leitura, pelas conjunções já escritas, e o segundo profissional vinculado ao mesmo aluno continua sendo recusado ao tentar editar a ficha do colega, que é a conjunção de {F2-08} preservada e provada por controle negativo. Placar inalterado, 6 de 6.

Fechamento [2026-09-14]: confirmado inalterado. Em produção (76bc9cd), nenhuma transição de vínculo nova; o autômato da ficha (ativo/inativo) ganha rotas de desativar e reativar. Placar continua 6 de 6.

Para que serve: distinguir treino em curso, concluído e abandonado, e o ciclo do pedido do aluno.

Relacionado com: RF-TREI-004, RF-TREI-005, RF-TREI-010; tarefas F3-04, F3-05 e F3-10.

Onde fica: colunas sessao_treino.status e solicitacao_ficha.estado.

Especificação: sessão: em andamento na abertura, com no máximo uma em andamento por aluno; retomável enquanto em andamento, carregando as séries do banco; concluída quando o aluno encerra com ao menos uma série registrada; abandonada quando encerra sem série, ou quando fica sem registro novo por mais tempo que o parâmetro sessao_abandono_horas, com valor inicial de vinte e quatro horas. Abandonada é terminal e não é oferecida para retomada. Apenas a concluída conta para sequência, calendário, conquistas e progressão. Solicitação: aberta na criação; atendida quando o autor vincula a ficha criada; recusada com motivo obrigatório. Solicitação atendida ou recusada não volta a aberta.

Nota (gate {F3-04}, Drift 4, 2026-09-14): a metade da solicitação deste cartão fecha em {F3-04} e a metade da sessão continua em {F3-05} e {F3-10}, e por isso o cartão continua [ ] com motivo escrito, no molde exato da Nota de {TA-24}, nunca [x] por metade e nunca [ ] mudo. A prosa da solicitação escrita aqui foi transcrita para o bloco E.3 do DRS nesta data, em tabela de origem, evento, destino e guarda, no mesmo formato das outras três máquinas de estado daquele bloco, sem acrescentar nada: este cartão não é editado porque já dizia tudo. O motivo de a tabela existir lá é que a guarda de transição do banco se escreve TRANSCREVENDO a tabela publicada, e não interpretando prosa de outro artefato; a diferença aparece no dia em que alguém perguntar por que uma transição é proibida e a resposta precisar ser um documento, não uma opinião. A obrigatoriedade do motivo da recusa vive na guarda de transição, nunca em coluna não nula, porque a coluna é legitimamente nula em aberta e em atendida.

Para que serve: governar a escrita de dado sensível e o acesso do aluno inativo.

Relacionado com: RF-CORE-010, RF-PLAN-002; tarefas F1-12 e F1-14.

Onde fica: tabela consentimento e coluna perfil_aluno.status_acesso.

Especificação: consentimento por categoria: ausente na origem, concedido com data e versão, revogado com data; concedido é a única condição que libera escrita, e revogar também retira a categoria da visibilidade dos profissionais. Reconceder cria um registro novo, sem apagar o anterior. Acesso do aluno: ativo libera tudo que o plano permite; inativo libera apenas perfil, plano e leitura do próprio histórico, com toda escrita negada; a transição é manual e exclusiva do administrador.

Estado: a metade do consentimento entregue em {F1-12}: os três estados implementados, "reconceder cria um registro novo, sem apagar o anterior" garantido por construção (unicidade parcial mais gatilho que só aceita a transição de revogado_em de nulo para preenchido, nunca de volta), "só concedido libera escrita" garantido pelo WITH CHECK, "revogar retira a categoria da visibilidade dos profissionais" garantido pela conjunção no USING. A metade do acesso do aluno (perfil_aluno.status_acesso, ativo e inativo) foi entregue em {F1-14}: a conjunção de acesso entra em consentimento_insercao e em consentimento_revogacao só dentro do WITH CHECK, nunca no USING, e o aluno inativo continua lendo os próprios consentimentos, e o profissional vinculado continua enxergando exatamente o que enxergava, porque nenhuma leitura foi tocada.

Para que serve: fazer o pedido do aluno chegar e voltar.

Relacionado com: RF-TREI-004; tarefa F3-04.

Onde fica: servidor de aplicação.

Especificação: gatilho um, criação de solicitacao_ficha, notifica o profissional. Gatilho dois, ficha criada vinculada à solicitação, muda o estado para atendida e notifica o aluno com o destino da ficha. Gatilho três, recusa, exige motivo e notifica o aluno. Idempotência, uma solicitação só é atendida uma vez.

Nota (gate {F3-04}, Drift 10, 2026-09-14): o gatilho dois deste fluxo pendura no FATO, não no caminho. A especificação o escreve como "ficha criada vinculada à solicitação", e a jornada do Personal descreve o atendimento como "cria a ficha nova ou altera a que é dele vinculando a solicitação": são dois caminhos publicados, e se o aviso pendurasse na criação de ficha o segundo caminho notificaria ninguém. Leitura declarada, sem o cartão mudar de texto: o gatilho dois observa a transição da própria solicitação, o momento em que a ficha passa a estar vinculada e o estado vai a atendida, cobrindo por construção os dois caminhos publicados e qualquer terceiro que nasça depois. É o que ele sempre quis dizer. Os três avisos deste fluxo nascem em {F3-04} por gatilho na origem, em fila de correio eletrônico, no molde literal dos três avisos de vínculo que já estão em produção, com chave de evento garantindo que repetir o mesmo fato não gera segunda mensagem; a central de notificações com sino e contagem é outro artefato, {ART-NOT-01}, e continua em {F6-05}.

Para que serve: trazer os 113 exercícios do protótipo para o catálogo global sem redigitação manual.

Relacionado com: RF-EXER-001; tarefa F2-01; ART-ENT-03.

Onde fica: script de operação (ops/importar-exercicios.mjs), acionado manualmente.

Especificação: gatilho, acionamento manual pela operação. Condição, arquivo docs/seed/exercicios.csv presente e cabeçalho conferido contra o mapeamento de colunas conhecido. Passos: ler o CSV, normalizar os valores de grupo muscular, dificuldade e categoria para os enums canônicos, casar pela chave natural (grupo_muscular, lower(btrim(nome))), inserir ou atualizar. Idempotência, por essa chave natural, reexecutar não duplica. Falha, arquivo ausente ou coluna desconhecida no cabeçalho aborta sem escrever nada e reporta nominalmente qual falta. Saída, placar N de M importados, K atualizados, J recusados (cada recusa com o motivo). Modo --ensaio é o padrão, que só conta e relata; escrever exige --aplicar. Etapa de mídia (R, {F2-02}): quando docs/seed/midia/ existir, casa o arquivo de mídia pela coluna do CSV, mede e valida pelo mesmo critério de bytes do card de mídia, copia para o repositório público com nome por hash e preenche imagem_url, imagem_largura e imagem_altura; escreve como mfit_app com claim de administrador, pelas mesmas políticas. A pasta hoje não existe (medido); o relatório abre em 0 de N exercícios com imagem, N lido do banco, nunca de constante no script.

Estado: importador entregue e idempotente em {F2-01}. Etapa de mídia entregue em {F2-02}; placar honesto 0 de N exercícios com imagem, porque docs/seed/midia/ do dono ainda não existe (pendência dele, mesma natureza, não bloqueia o card).

Fechamento [2026-09-14]: docs/seed/exercicios.csv do dono chegou (114 linhas, cabeçalho mais 113 exercícios do protótipo), commit 53cb783 na branch feat/semente-exercicios. Executado ops/importar-exercicios.mjs --ensaio (idempotente, sem escrever) e depois --aplicar em produção: placar 113 de 113 importados, 0 atualizados, 0 recusados. Medido direto no banco de produção após a carga: 113 linhas ativas em mfit.exercicio pela chave natural do importador. Etapa de mídia continua 0 de 0, docs/seed/midia/ do dono ainda ausente, pendência dele, mesma natureza, não bloqueia o card. Placar da semente sobe de 0 de 113 para 113 de 113.

Para que serve: garantir que as três contas de operação da plataforma existam, com o papel de topo e a senha no padrão, em qualquer ambiente que suba do zero.

Relacionado com: RN-010, RF-PAIN-009, ART-ACS-06; tarefa AUD-04.

Onde fica: comando de operação do servidor de aplicação, executado na instalação e reexecutável a qualquer momento.

Especificação: cria ou reconcilia exatamente três contas, uma por operador da plataforma, todas com papel super_administrador e status ativo. 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. Idempotência, e ela se prova: rodar duas vezes seguidas deixa o mesmo número de contas, não rebaixa papel de conta já promovida e não sobrescreve senha que o operador já tenha trocado, reconhecida por a derivada em banco ser diferente da derivada do padrão. Nenhum endereço de e-mail, nenhuma senha e nenhum valor de padrão aparece neste documento nem em qualquer documento publicado: o registro vive no arquivo de credenciais do projeto, fora do repositório de código. Saída do comando: uma linha por conta dizendo criada, promovida ou inalterada, e a contagem final, que é o observável do H1 de {AUD-04}.

Para que serve: garantir que a entrada de fim chegue à trilha de auditoria também quando o Super Administrador simplesmente vai embora, fechando o navegador sem sair da personificação.

Relacionado com: RF-CORE-014, RF-CORE-009; tarefa AUD-05; ART-ACS-13 (o mecanismo), ART-ENT-01 (tabela sessao_personificacao), ART-AUD-01 (a entrada de fim), ART-CFG-01 (o teto de duração que ela lê).

Onde fica: script de operação do servidor de aplicação, chamado pelo agendador do sistema operacional que já existe. Não é rotina agendada de aplicação e não pertence ao grupo ART-JOB, que é da fase de cobrança: nenhum agendador novo nasce por causa desta ficha.

Especificação: gatilho, o agendador do sistema operacional, de dez em dez minutos. Processa, toda linha de sessao_personificacao sem fim gravado cuja duração já passou do teto configurado. Passos, gravar o fim com o motivo expiração e escrever a entrada de fim na trilha, com o mesmo par personificador e personificado da entrada de início. Idempotência, alcança apenas linha sem fim gravado, e o gatilho de atualização única da tabela recusa a segunda escrita: reexecutar não duplica entrada nem sobrescreve motivo. Falha, a linha que não fechar é relatada nominalmente e as demais seguem, nunca aborta o lote inteiro. Saída, placar N de M personificações fechadas por execução, e zero é resultado legítimo e esperado na maioria das execuções. Janela declarada, e ela é a razão de esta ficha existir com cadência em vez de sob demanda: o fechamento preguiçoso que a aplicação faz em três pontos, a passagem pela camada única de sessão, a renovação e o início de uma personificação nova, cobre todo operador que volta, e esta rotina cobre quem não volta; entre a expiração e a execução seguinte existe uma janela de até dez minutos em que a linha continua aberta, e ela é consequência da cadência, não defeito. Reduzir a janela é mudar a cadência, e a cadência vive no agendador, nunca dentro do código.

Estado: instalado em produção em 2026-09-29 (merge 3dabc30, https://fit.modulareasy.com, migrações 0034, 0035 e 0036, gates plan, qa e review verdes): a rotina ops/fechar-personificacoes-expiradas.mjs está no agendador do sistema operacional do servidor, a cada dez minutos (*/10), com o log em arquivo próprio. O qa rodou o mesmo comando a mão sobre uma linha órfã expirada: fechadas=1, motivo expiração, saída 0.

Para que serve: confirmar o endereço de e-mail informado no cadastro.

Relacionado com: RF-CORE-002, RF-CORE-003; tarefas F1-07 (envio), disparado pela criação de conta em F1-04 e F1-05.

Onde fica: envio transacional.

Especificação: canal, e-mail. Disparado por, criação de conta. Assunto, confirmação de cadastro no ModularFit. Corpo com as variáveis nome e endereço de confirmação. Idioma, português do Brasil. Remetente, endereço institucional do produto. Ação, confirmar o e-mail. Janela, imediato. Sem descadastro, por ser transacional.

Nota (gate {AUD-08}, 2026-09-29): Assunto: valor inicial; editável em email_assunto_<modelo> ({ART-CFG-01}). Prazo: recuperacao_validade_min.

Fechamento [2026-09-29] de {AUD-08}: o assunto deste e-mail é o parâmetro email_assunto_confirmacao_conta, em mfit.parametro (merge fa725bc, migração 0041), editável em /admin/parametros pelo Super Administrador e valendo para o próximo e-mail renderizado, inclusive os já na fila e ainda não enviados. A prova ao vivo do qa do assunto novo saído foi feita no e-mail de recuperação; este segue o mesmo caminho da tabela e do renderizador.

Nota (Inspeção, {AUD-10}, 2026-09-30): assunto e corpo deste e-mail passam a viver no modelo confirmacao_conta de {ART-CFG-03}, editável em /admin/emails, e o parâmetro email_assunto_confirmacao_conta sai de mfit.parametro quando {AUD-10} entregar. As variáveis do corpo são as da linha do modelo no catálogo de variáveis de {ART-CFG-03}.

Fechamento [2026-09-30] de {AUD-10}: assunto e corpo deste e-mail vivem agora no modelo confirmacao_conta (merge 17b62d6, migrações 0048 e 0049, https://fit.modulareasy.com, /api/estado na versão 17b62d6), editável em /admin/emails, e o parâmetro email_assunto_confirmacao_conta saiu de mfit.parametro. Texto idêntico ao de antes na versão 1 (regressão de {TA-96}).

Para que serve: permitir redefinir a senha com segurança.

Relacionado com: RF-CORE-005; tarefa F1-07.

Onde fica: envio transacional.

Especificação: canal, e-mail. Disparado por, pedido de redefinição. Assunto, redefinição de senha. Corpo com as variáveis nome, endereço de uso único e prazo de sessenta minutos. Regra, e-mail não cadastrado não gera envio e a tela exibe a mesma mensagem neutra. Janela, imediato. Uso único, o endereço expira ao ser usado.

Nota (gate {AUD-08}, 2026-09-29): Assunto: valor inicial; editável em email_assunto_<modelo> ({ART-CFG-01}). Prazo: recuperacao_validade_min.

Fechamento [2026-09-29] de {AUD-08}: o assunto deste e-mail é o parâmetro email_assunto_recuperacao_senha, em mfit.parametro (merge fa725bc, migração 0041), editável em /admin/parametros pelo Super Administrador e valendo para o próximo e-mail renderizado, inclusive os já na fila e ainda não enviados. Provado ao vivo pelo qa: com o valor alterado, o e-mail enviado gravou o assunto novo em mfit.email_saida, sem reiniciar a aplicação, e o valor foi restaurado depois (trilha com antes e depois).

Nota (Inspeção, {AUD-10}, 2026-09-30): assunto e corpo deste e-mail passam a viver no modelo recuperacao_senha de {ART-CFG-03}, editável em /admin/emails, e o parâmetro email_assunto_recuperacao_senha sai de mfit.parametro quando {AUD-10} entregar. As variáveis do corpo são as da linha do modelo no catálogo de variáveis de {ART-CFG-03}.

Fechamento [2026-09-30] de {AUD-10}: assunto e corpo deste e-mail vivem agora no modelo recuperacao_senha (merge 17b62d6, migrações 0048 e 0049, https://fit.modulareasy.com, /api/estado na versão 17b62d6), editável em /admin/emails, e o parâmetro email_assunto_recuperacao_senha saiu de mfit.parametro. Provado ao vivo: a versão 2 (de teste) saiu no e-mail real com o marcador e modelo_versao 2, e a versão 3, restauração da 1, devolveu o texto original; o HTML diz "Acesse" no lugar de "Clique" (troca declarada).

Para que serve: garantir que todo valor de operação do catálogo seja lido de um lugar só, e que nenhum literal de negócio novo nasça fora dele.

Relacionado com: RF-PAIN-011, ADR-012, L.2, {ART-CFG-01}; tarefa {AUD-06}.

Onde fica: servidor, módulo único de leitura; e ops/verifica-parametros.mjs.

Especificação: módulo único server/src/parametros.ts com duas leituras: parametro(chave) para os escalares de mfit.parametro e listaFechada(nome) para as listas de mfit.lista_fechada_item, cada uma com cache carregado na subida, invalidado na escrita, e trava de cardinalidade (28 linhas; seis listas, cada uma com ao menos um item ativo). A leitura parametro(chave) é tipada. Duas travas na carga: cardinalidade contra o catálogo publicado (a tabela tem de ter exatamente o número de linhas declarado, senão o processo NÃO sobe) e chave desconhecida (a função lança, nunca devolve nulo). O verificador é por LITERAL, nunca por nome, com lista nominal de exceções técnicas com motivo de uma linha por item, decoy que o reprova, controle negativo que não o reprova, e trava de universo que reprova quando o total de ocorrências sobe sem linha nova no catálogo. Placar honesto obrigatório: o verificador imprime quantos dos valores de negócio medidos já estão no ponto único e quantos faltam, com card dono nominal dos que faltam.

Estado: entregue em {AUD-06} (merge 29380ae, https://fit.modulareasy.com, migrações 0037 e 0038). Função única parametro(chave) com cache invalidado na escrita e as duas travas na carga (cardinalidade 28 e chave desconhecida lança). Verificador ops/verifica-parametros.mjs: RESULTADO OK, 79 de 101 literais de negócio restantes (22 fechados mais 79 restantes igual a 101, universo 148, 121 candidatas, 0 soltas), com decoy que o reprova, controle negativo que não o reprova e dono nominal em cada restante ({AUD-07} 9, {AUD-08} 17, consentimento_textos 1, cards de módulo 52). Ressalva nomeada: o verificador lê a árvore de fonte e não roda dentro da imagem do servidor, roda na árvore do commit. Nota (gate {AUD-07}, Drift 2, 2026-09-29): server/src/arquivos/tipoConteudo.ts é reclassificado de B para C, com o motivo "mapa extensão para tipo MIME (protocolo IANA); serve também os ativos da SPA; a regra de negócio é anexo_extensoes e midia_exercicio_formatos"; o denominador de editáveis passa de 101 para 100 quando {AUD-07} fechar, e a medição acima permanece como o retrato de {AUD-06}.

Nota (gate {AUD-08}, Drifts 4 e 8, 2026-09-29): duas reclassificações de A para C, no molde do tipoConteudo de {AUD-07}. config.emailRemetente: marca única (L.3) e endereço autenticado no provedor de envio (SMTP_URL, SPF e DKIM do domínio): trocar o endereço exige infraestrutura, trocar o nome contraria L.3; {ART-MSG-01} já o fixa como "endereço institucional do produto". config.ajudaRegistroProfissional: reafirma ADR-004 ao usuário; o texto só muda quando a decisão muda, e editar sem deploy deixaria a tela afirmar o que o sistema não faz. Denominador de editáveis: 100 para 98. Trava de cardinalidade 42 linhas (era 28); o verificador também reconhece a forma texto e confere que nenhum parâmetro do catálogo tem cópia literal no web.

Fechamento [2026-09-29] de {AUD-07} (merge 7b47fa6, https://fit.modulareasy.com): a segunda leitura listaFechada(nome) está entregue no mesmo módulo server/src/parametros.ts, com cache carregado na subida, recarregado depois da escrita confirmada e trava de carga (seis listas, cada uma com ao menos um item ativo). O verificador fecha em RESULTADO OK com 70 de 100 literais de negócio restantes (30 fechados, sendo 22 de {AUD-06} mais 8 de {AUD-07}; 47 exceções C; universo 147, 70 + 30 + 47). A nota acima do Drift 2 está cumprida: o denominador de editáveis passou de 101 para 100.

Fechamento [2026-09-29] de {AUD-08} (merge fa725bc, migração 0041, https://fit.modulareasy.com): o verificador fecha em RESULTADO OK com 52 de 98 literais de negócio restantes (46 fechados, sendo 22 de {AUD-06}, 8 de {AUD-07} e 16 de {AUD-08}; 48 exceções C; universo 146, 52 + 46 + 48; 0 soltas), com a trava de cardinalidade em 42 linhas e o denominador de editáveis em 98. Nenhum restante tem dono {AUD-08}. A forma texto é reconhecida e nenhum parâmetro do catálogo tem cópia literal no web.

Para que serve: permitir ao Super Administrador ajustar assunto e corpo de cada e-mail transacional sem publicar versão nova, com as variáveis protegidas e o histórico guardado.

Relacionado com: RF-PAIN-011 (extensão dos modelos de e-mail), ADR-012, L.2; {ART-CFG-01} (a ficha modelos_email), {ART-CFG-02} (o verificador), {ART-MSG-01} a {ART-MSG-03}, {ART-WF-01} a {ART-WF-03} e {ART-WF-05} (quem dispara), {ART-INT-03} (o envio), {ART-SCR-03} (a tela); tarefa {AUD-10}; teste {TA-99}.

Onde fica: banco de dados (tabela do modelo e tabela das versões), servidor (renderizador único e rotas de administração) e aplicação (/admin/emails).

Especificação: entidades: modelo_email (chave única, evento em texto de uma linha, variáveis permitidas, variáveis obrigatórias, versão vigente) e modelo_email_versao (id, modelo, número sequencial por modelo, assunto, corpo, autor, criada em), esta só de acréscimo, com alteração e remoção negadas à aplicação e unicidade de (modelo, número). Semente: um registro por modelo e a versão 1 de cada um, com o assunto vigente em mfit.parametro no dia da migração e o corpo de hoje do código, as interpolações trocadas pelas variáveis. Formulário do editor, um por modelo: assunto (texto, obrigatório, 3 a 120 caracteres, linha única, aceita variáveis da lista do modelo); corpo (texto longo, obrigatório, 20 a 5000 caracteres, parágrafos separados por linha em branco, texto simples, sem HTML); as variáveis permitidas do modelo à vista, cada uma inserível no cursor; ações pré-visualizar, gravar (confirmação nominal do modelo) e cancelar. Histórico: lista das versões com número, autor e data, e a ação restaurar, que cria versão nova com o conteúdo da escolhida. Validação no servidor, na gravação e na prévia: toda ocorrência de chaves duplas tem de ser uma variável da lista do modelo, e a desconhecida é recusada com 422 e a mensagem nomeando a variável e a lista aceita; {{endereco}} é obrigatória no corpo dos onze; chave dupla sem fechamento é recusada; assunto vazio, só de espaços, com quebra de linha ou TAB, ou fora de 3 a 120 caracteres é recusado com a faixa na mensagem; corpo fora de 20 a 5000 é recusado com a faixa; recusa não grava versão. Renderização: um renderizador único, usado pelo envio e pela prévia, lê a versão vigente no momento de renderizar, substitui as variáveis, produz o texto e deriva o HTML (cada parágrafo em <p>, todo valor e todo texto do operador escapados, {{endereco}} como link), e o registro do envio guarda o número da versão usada; nenhum texto de e-mail fica em código, e o verificador de {ART-CFG-02} reprova corpo literal, com o remetente como exceção nomeada. Prévia: dados de demonstração fixos por variável (nome "Maria Exemplo", endereço de exemplo do produto, especialidade "Personal Trainer", validade igual ao valor vigente de recuperacao_validade_min), sem gravar e sem enfileirar. Permissão: o Super Administrador lê, grava e restaura; o Administrador lê a lista, o conteúdo, as variáveis e o histórico, sem controle de edição, e a rota de escrita lhe responde 403; profissional e aluno não alcançam a tela nem as rotas. Auditoria: cada gravação e cada restauração gera entrada com modelo, versão, assunto e corpo antes e depois. Catálogo de variáveis, com os valores entre chaves duplas no texto (exemplo: {{nome}}):

Para que serve: entregar confirmação de conta, recuperação de senha e acesso criado.

Relacionado com: RF-CORE-002, RF-CORE-005, RF-PAIN-009; tarefas F1-04, F1-07, F7-14.

Onde fica: servidor de aplicação.

Especificação: direção, saída. Autenticação, credencial de serviço no servidor. Fila, tabela mfit.email_saida, com chave de evento única garantindo a idempotência por construção. Rotina de envio, no próprio processo mfit-app (ADR-013), sem processo externo. Eventos enviados, os três templates de ART-MSG. Idempotência, um envio por evento, com chave de evento. Falha, nova tentativa em fila com recuo progressivo e alerta quando a fila passa de cinquenta itens. Sem envio de marketing por este canal.

Para que serve: parametrizar o servidor sem colocar segredo no código.

Relacionado com: G.1, F.2, ADR-013; tarefas F1-01, F1-07, F8-05, F8-13.

Onde fica: ambiente do servidor de aplicação.

Especificação: URL_BANCO (conexão de runtime, role sem privilégio de dono do schema, segredo, obrigatória no F1-01); URL_BANCO_ADMIN (conexão usada pelo comando de migração e pelas ferramentas de operação que escrevem como dona do schema, role dona do schema, segredo, obrigatória no F1-01); SEGREDO_TOKEN (assinatura do token de sessão, segredo, obrigatória no F1-01, rotação invalida sessões); SEGREDO_ARQUIVOS (segredo que assina o endereço de saída do repositório privado, HMAC, segredo, obrigatória no F1-01; renomeia CHAVE_SERVICO_ARQUIVOS, não há serviço externo de armazenamento, ADR-013); DIR_ARQUIVOS (raiz do volume de arquivos dentro do container, caminho, obrigatória no F1-01); URL_PUBLICA_ARQUIVOS (caminho base do repositório público, servido pela própria aplicação, obrigatória no F1-01); URL_APLICACAO (base usada em e-mail e no retorno de autorização, URL, obrigatória no F1-01); SMTP_URL (envio de e-mail, segredo, usada no F1-07; a ausência degrada o envio, a mensagem fica enfileirada e registrada no log, nunca derruba o arranque; a alternativa de torná-la obrigatória foi reprovada); CHAVE_GERACAO (provedor de geração assistida, segredo, obrigatória no F8-05); MODELO_GERACAO_PADRAO (valor inicial do parâmetro editável, valor, opcional, usada no F8-05); CREDENCIAIS_PROVEDORES_ATIVIDADE (identificador e segredo de cada provedor habilitado, segredo, obrigatória apenas se houver provedor habilitado, um par por provedor, usada no F8-13); CHAVE_CIFRA_CREDENCIAL (chave que cifra a credencial guardada em conta_integracao, segredo, obrigatória se houver provedor habilitado, rotação exige reautorização de todas as contas conectadas, usada no F8-13). Nenhum valor é escrito neste documento; a rotação de cada uma é feita pela administração da operação, e a rotação do segredo do token exige aviso porque desconecta todos.

Estado: as 12 variáveis existem em /opt/modularfit/.env desde F1-01; SMTP_URL preenchida em produção no F1-07 (Postfix do host); as demais 4 opcionais recebem valor no card que as consome.

Para que serve: sustentar a aplicação em produção.

Relacionado com: G.1, G.3, G.4, K.2, K.3, ADR-013; tarefas F1-01 e F8-11.

Onde fica: hospedagem própria da operação, projeto isolado, dois processos (mfit-db, mfit-app).

Especificação: os seis papéis abaixo NÃO são seis serviços provisionados, são papéis dentro de dois processos reais. mfit-app (servidor de aplicação) concentra quatro papéis: servidor de aplicação (papel, servir a interface e as rotas; dependências, banco, identidade, arquivos; verificação de saúde na rota de estado; reinício automático; middleware único de cabeçalhos de segurança em toda resposta, X-Content-Type-Options, X-Frame-Options, Referrer-Policy, Permissions-Policy e Content-Security-Policy, emitido pela aplicação e não pelo vhost do servidor web da frente, {F2-02}), serviço de identidade (papel, emissão e validação de token, dependência, banco), armazenamento de objetos (dois repositórios, público e privado, servidos pela própria aplicação), canal de tempo real (papel, entrega de mensagem e notificação; degradação aceitável para consulta periódica se indisponível) e agendador (papel, executar as sete rotinas; registro de cada execução). mfit-db concentra o papel de banco de dados (papel, persistência com política por linha; cópia diária e semanal; verificação de conexão). Isolamento, nenhum destes papéis é compartilhado com outro produto. Cópia de segurança conforme K.3, com teste de restauração trimestral.