DRS, bloco J.5 Artefatos de apoio e Apêndice de identidade visual. Todas as telas do catálogo de telas, nas variações de papel (aluno no celular, quatro painéis de profissional, administração), com marca e cores oficiais, base de estilo compartilhada, motor configurado por página e navegador flutuante Mapa do mockup.

Como verificar (teste primeiro): todas as páginas respondem com sucesso na URL publicada; cada papel exibe o próprio painel; o fluxo de execução de sessão e o de registro de exame demonstram o passo a passo real em script; inspeção visual página a página em 375 e 1440; proporção de toda imagem conferida pela medição, não a olho.

Aceite (H1): Dado o mockup publicado, Quando o dono do projeto navega pelo Mapa do mockup, Então alcança toda tela do catálogo de telas do DRS, E cada papel aparece com o painel e a identidade corretos.

Gate. Apresentar ao dono do projeto, aplicar ajustes no próprio mockup e obter a aprovação.

Como verificar (teste primeiro): aprovação registrada; DRS atualizado no bloco J.5 declarando o mockup referência visual aprovada e guia do desenvolvimento, com o endereço publicado.

Aceite (H1): Dado o mockup aprovado, Quando a construção de uma tela começa, Então a página correspondente do mockup é o guia, E divergência visual se resolve consultando o mockup.

DRS G.1 e ADR-009. Instância própria, sem compartilhar banco nem identidade com outro produto; repositório público de mídia e repositório privado de dado sensível, com políticas distintas.

O que implementar: repositório de código próprio, compose isolado com banco e aplicação, migração de fundação (esquema, papel de execução sem privilégio de contorno de política, tabela de migrações), rota de estado que verifica o banco, os dois repositórios de arquivo no volume próprio, cópia de segurança diária e semanal, e o endereço público com proxy reverso.

Como verificar (teste primeiro): um arquivo no repositório público abre por endereço direto e um arquivo no privado retorna acesso negado por endereço direto.

Aceite (H1): Dado os dois repositórios provisionados, Quando o endereço direto de cada um é acessado sem sessão, Então o público responde conteúdo e o privado responde acesso negado.

DRS Apêndice de identidade visual e F.1. Tokens de cor, tipografia, espaçamento e raio numa fonte única; tamanho sempre relativo à base do contêiner; tema escolhido pelo usuário e lembrado.

Como verificar (teste primeiro): alterar a base do contêiner reescala toda a tipografia proporcionalmente; nenhum componente declara tamanho em pixel fixo fora de borda e sombra.

Aceite (H1): Dado o sistema de estilo aplicado, Quando o tema é alternado, Então toda tela troca de superfície e texto sem elemento ilegível, E o tema escolhido persiste após recarregar.

Nota [F1-17]: /estilo é referência visual de desenvolvimento, alcançável só por endereço direto, fora de menu e fora de link de qualquer página; não é tela de produto e por isso não entra no catálogo de telas do DRS nem conta em nenhuma ficha {ART-SCR-0x}. O mesmo vale para /api/estado, que é verificação de saúde. Nenhum card futuro deve reconectar o link a partir da home.

RF-CORE-001.

O que implementar: tela de entrada, emissão de sessão em cookie restrito ao servidor, renovação, bloqueio após seis tentativas em quinze minutos.

Como verificar (teste primeiro): credencial correta entra, credencial errada retorna erro genérico, sexta falha bloqueia por trinta minutos.

Aceite (H1): Dado um aluno com conta ativa e senha correta, Quando envia e-mail e senha na tela de entrada, Então recebe uma sessão válida e é levado ao painel do aluno, E uma credencial errada retorna erro de autenticação sem revelar se o e-mail existe.

RF-CORE-002.

Como verificar (teste primeiro): conta criada com plano gratuito e todos os campos opcionais nulos; nenhuma tela bloqueia por campo opcional.

Aceite (H1): Dado um visitante na tela de cadastro, Quando envia nome, e-mail válido e senha com no mínimo oito caracteres, Então a conta é criada com papel de aluno, plano gratuito e status ativo, E o aluno alcança o painel com todos os campos opcionais do perfil vazios.

RF-CORE-003.

Como verificar (teste primeiro): as quatro máscaras aceitam o formato próprio e recusam os outros três.

Aceite (H1): Dado um visitante que escolhe a especialidade Personal Trainer, Quando informa o registro 123456-G/AM, Então a conta é criada com especialidade e registro gravados, E o mesmo número no formato de outra especialidade é recusado com a mensagem do campo indicando o formato esperado.

Nota [F1-17]: os quatro rótulos de CATALOGO_ESPECIALIDADES ganharam um segundo leitor, e ele é público, a partir de {F1-17}: renomear um rótulo muda a página pública inicial. O décimo segundo verificador (ops/verifica-home.mjs) reprova se os dois lados divergirem, e o conserto é sempre no espelho (a fonte de texto da home), nunca uma terceira lista.

RF-CORE-004.

Aceite (H1): Dado um usuário autenticado na tela de perfil, Quando altera um campo e salva, Então o valor novo aparece na tela após recarregar, E a alteração fica registrada na trilha de auditoria com autor, campo, valor anterior e valor novo.

RF-CORE-005.

O que implementar: também passa a enviar a confirmação de conta (ART-MSG-01) das contas criadas em F1-04 e F1-05, incluindo as já existentes.

Aceite (H1): Dado um usuário que solicita redefinição para um e-mail cadastrado, Quando abre o endereço recebido dentro de sessenta minutos e define uma senha nova, Então consegue entrar com a senha nova, E o mesmo endereço usado uma segunda vez retorna erro de link inválido.

RF-CORE-006, D.2 e ADR-003.

O que implementar: o auxiliar único de decisão de acesso mfit.pode_ler_aluno, com as quatro condições de leitura de D.2 e a classe restrita como parâmetro; a tabela vinculo, da qual o auxiliar depende para decidir; a política nas entidades de dado de aluno que já existem hoje (aceite_termos); o gabarito que todo card futuro aplica ao criar a tabela dele; e o verificador que reprova a criação de tabela de dado de aluno sem política.

Como verificar (teste primeiro): os trinta e seis casos nascem aqui como arnês parametrizado por entidade, executado antes da interface existir; as duplas das entidades que ainda não existem são reportadas como pendentes com o nome do card dono, e passam a verde no card que cria cada tabela; o verificador ops/verifica-acesso-aluno.mjs roda dentro do node --test e reprova qualquer tabela de dado de aluno sem política.

Aceite (H1): Dado o profissional P2 sem vínculo com o aluno A1, Quando solicita por identificador direto o registro de A1 na entidade aceite_termos ou em qualquer entidade de dado de aluno já existente, Então a resposta é negada, E o profissional P1 vinculado a A1 obtém o registro com sucesso nas entidades já existentes, E a entidade restrita nega tanto P1 quanto P2, E a criação de uma tabela de dado de aluno sem política reprova o verificador. O H1 de RF-CORE-006 no DRS não muda, continua exigindo os trinta e seis casos, que fecham em TA-06 na Fase 8.

RF-CORE-007.

O que implementar: a coluna aluno_id na trilha de auditoria; o leitor único de registro sensível no servidor (server/src/acesso/leituraSensivel.ts), que é o único caminho pelo qual qualquer rota lê uma das seis entidades sensíveis e que grava a entrada acesso_administrativo na MESMA transação da leitura; a marcação sensivel na lista única de entidades; a seção nova do gabarito (GABARITO-ACESSO-ALUNO.md), que todo card da Fase 5 aplica; e o verificador (ops/verifica-leitura-sensivel.mjs) que reprova rota que leia entidade sensível por fora do leitor único.

Como verificar (teste primeiro): os seis casos de TA-07 nascem aqui como arnês parametrizado por entidade, executado antes de a interface existir; as seis entidades ainda não existem e são reportadas como pendentes com o nome do card dono; o mecanismo é provado hoje contra uma tabela sensível de ensaio criada e desfeita dentro da transação do próprio teste.

Aceite (H1): Dada uma entidade marcada como sensível, Quando o Administrador a lê pelo leitor único, Então o conteúdo é servido e existe exatamente uma entrada acesso_administrativo com autor, aluno, entidade, identificador e momento, E quando o titular lê a própria linha não existe entrada nenhuma, E uma rota que leia a entidade sensível por fora do leitor único reprova o verificador. O H1 de RF-CORE-007 no DRS não muda: ele continua exigindo as seis categorias e a tela, e é TA-07 que o fecha.

RF-CORE-008 e RN-008.

O que implementar: a política de DELETE explícita (FOR DELETE TO mfit_app USING (papel_atual() = 'administrador')) em vinculo, única das onze entidades que existe hoje; o gatilho genérico de auditoria de remoção, emitindo excluir em AFTER DELETE e desativar quando a coluna de desativação muda; a seção de remoção do gabarito (GABARITO-ACESSO-ALUNO.md), que todo card dono aplica ao criar a tabela dele; o campo removível na lista única de entidades com a trava aritmética das onze; e o verificador que reprova, por critério, toda tabela de dado de aluno sem política de DELETE, ou com política de DELETE que não exija o papel administrador, ou sem o gatilho de remoção.

Como verificar (teste primeiro): os casos nascem como arnês parametrizado por entidade, executado antes de a interface existir; as dez entidades ainda ausentes são reportadas como pendentes com o nome do card dono, placar 1 servida mais 10 pendentes igual a 11; o mecanismo é provado hoje contra vinculo e contra uma tabela de ensaio criada e desfeita dentro da transação do próprio teste, incluindo a prova negativa de uma segunda tabela de ensaio sem política de DELETE, que o verificador tem que reprovar.

Aceite (H1): Dada uma entidade de dado de aluno marcada como removível, Quando um aluno ou um profissional pede a exclusão definitiva, Então nenhuma linha é apagada e a rota responde negação explícita, E quando ele pede a desativação a linha passa ao estado inativo e continua legível no histórico com entrada de auditoria desativar, E quando o Administrador pede a exclusão definitiva a linha é apagada e existe entrada excluir com autor, aluno, entidade, identificador e momento, E uma tabela de dado de aluno sem política de DELETE reprova o verificador.

Nota: o H1 de RF-CORE-008 no DRS não muda, continua exigindo as onze entidades, e é TA-08 que o fecha quando todas existirem e as listas de trabalho delas estiverem no ar.

RF-CORE-009 e D.5.

O que implementar: REVOKE UPDATE, DELETE ON mfit.auditoria FROM mfit_app e o mesmo em mfit.aceite_termos; RLS de leitura em mfit.auditoria restrita ao Administrador, mantendo a inserção livre para o leitor único de {F1-09} e para os gatilhos; o índice de listagem por momento; a rota GET /api/admin/auditoria com filtros e paginação, privativa do Administrador; a tela /admin/auditoria fiel à página 36 do mockup; o trilho de navegação do Administrador, contendo só o que existe; e o verificador que reprova, por catálogo, toda tabela declarada apenas acrescida que ainda tenha UPDATE ou DELETE para mfit_app.

Como verificar (teste primeiro): os casos de banco rodam contra o Postgres efêmero antes de a tela existir, e a negação é provada pelo código de erro do Postgres (42501), nunca pelo texto da mensagem.

Aceite (H1): Dado um usuário que altera um campo do próprio perfil, Quando salva, Então existe a entrada de auditoria com autor, entidade, identificador, campo, valor anterior, valor novo e momento, E a tela /admin/auditoria a exibe e a encontra por autor, entidade e período, E toda tentativa de editar ou remover qualquer entrada da trilha, feita pela aplicação em qualquer um dos três papéis inclusive o Administrador, é recusada pelo banco com erro de permissão, E o mesmo vale para aceite_termos, E uma tabela declarada apenas acrescida que tenha UPDATE ou DELETE para o papel da aplicação reprova o verificador.

Nota: o H1 de RF-CORE-009 no DRS não muda, ele continua falando da ficha, e é TA-09 que o fecha, na Fase 3.

RF-CORE-010, RN-001 e ADR-010.

O que implementar: a entidade mfit.consentimento com a unicidade parcial da linha ativa; os dois auxiliares SECURITY DEFINER (mfit.tem_consentimento para a escrita, mfit.consentimento_visivel para a leitura pelo profissional); a quinta seção do gabarito, que toda tabela sensível aplica na própria migração de criação; o campo categoriaConsentimento na lista única, com a trava de bijeção contra o enum do banco; o verificador por catálogo que reprova toda tabela marcada sensível cuja política de escrita não exija o consentimento da categoria dela; as rotas GET/POST/DELETE /api/consentimentos; a tela /privacidade fiel à página 20 do mockup, sem o botão de exportar; e o cartão de consentimento como componente reutilizável, que as páginas 13 e 14 vão consumir quando existirem.

Como verificar (teste primeiro): os casos de banco rodam contra o Postgres efêmero antes de a tela existir, contra uma tabela de ensaio criada e desfeita dentro da transação do próprio teste (a mesma técnica de {F1-10} e {F1-11}), e a negação é provada pelo código de erro do Postgres (42501), nunca pelo texto da mensagem.

Aceite (H1): Dado um aluno que nunca consentiu uma categoria, Quando ele ou um profissional vinculado tenta escrever um registro daquela categoria, Então o banco recusa a escrita com erro de permissão, E a tela /privacidade apresenta a categoria como não concedida com a ação Conceder, E após conceder pela rota real a mesma escrita conclui, E após revogar ela volta a ser recusada enquanto os registros já existentes continuam legíveis ao titular e ao Administrador e deixam de ser legíveis ao profissional vinculado, E a concessão e a revogação geram entrada de auditoria, E uma tabela marcada sensível cuja política de escrita não exija o consentimento da categoria dela reprova o verificador.

Nota: o H1 de RF-CORE-010 no DRS não muda, ele continua falando do exame, e é TA-10 que o fecha, quando as seis existirem.

Nota (Inspeção, {AUD-11}, drift 7, 2026-09-30): a leitura registrada no histórico de mudanças deste card, de que a restrição por especialidade governa só a leitura, fica superada em 2026-09-30 para a escrita de terceiro que depende de ler a linha anterior: a restrição escolhida pelo aluno governa também a escrita, e o profissional fora dela não grava (RN-003, RF-CORE-010). O que valeu até esta data continua descrito, sem apagar. Detalhe em {AUD-11}.

RF-PLAN-001 e ADR-012.

O que implementar: as seis colunas tipadas de limite no lugar do documento estruturado, o enum de recorrência, a coluna padrao que desamarra o cadastro do nome do plano, o valor de referência anulável para as duas faixas ainda sem preço, a semeadura de Essencial e Completo com os limites do Apêndice, a RLS da tabela (leitura livre à aplicação, escrita privativa do Administrador, DELETE revogado), a auditoria de criação e de alteração reusando as funções genéricas que já existem, o auxiliar único mfit.limite_do_aluno e o auxiliar de comparação mfit.dentro_do_limite que {F1-15} vai consumir, a lista única DIMENSOES_PLANO com trava de bijeção contra as colunas do catálogo, o verificador que reprova nome de plano literal em código e dimensão sem coluna, as rotas GET/POST/PATCH /api/admin/planos mais GET /api/planos, e a tela /admin/planos fiel à página 34 do mockup, sem o botão de atribuir.

Como verificar (teste primeiro): os casos de banco rodam contra o Postgres efêmero antes de a tela existir; a negação de escrita é provada pelo código de erro do Postgres (42501), nunca pelo texto da mensagem; e a cláusula do H1 sobre "a verificação seguinte" é provada contra a única dimensão cujo dado real existe hoje (vinculos_ativos, contada em mfit.vinculo, entregue em {F1-08}), na mesma conexão, sem reinício e sem nova publicação.

Aceite (H1): Dado o Administrador autenticado em /admin/planos, Quando cria um plano informando nome, valor, recorrência e as seis dimensões de limite, Então o plano passa a constar na lista de planos ativos servida para atribuição (GET /api/planos), E ao alterar um limite desse plano pela tela, a consulta seguinte de mfit.dentro_do_limite para um aluno daquele plano já responde pelo valor novo, na mesma conexão, sem reinício do serviço e sem nova publicação do sistema, E a criação e a alteração geram entrada de auditoria visível em /admin/auditoria, E um plano com aluno vinculado não pode ser apagado, apenas descontinuado, E renomear o plano padrão não quebra o cadastro de aluno novo.

Nota: o H1 de RF-PLAN-001 no DRS não muda, ele continua falando da lista disponível para atribuição, e é TA-16 que o fecha, quando {F1-14} e {F1-15} existirem.

Fechamento [2026-09-07]: entregue e em produção (bae8f0d, migração 0013_catalogo_planos.sql). Ficou pronto: seis colunas limite_* tipadas no lugar do documento jsonb, coluna padrao por índice único parcial, tela /admin/planos, verificador verificar:planos, RLS e auditoria da tabela. QA achou e corrigiu BUG-03 (etiqueta PADRÃO não atualizava sem reload). TA-16 continua pendente de {F1-14} e {F1-15}.

RF-PLAN-002.

O que implementar: o auxiliar único mfit.autor_com_acesso_ativo(); a conjunção dele no WITH CHECK (nunca no USING) das cinco políticas de escrita já existentes alcançáveis pelo aluno; a seção nova do gabarito, que toda tabela de dado de aluno aplica ao nascer; a negação na camada de API dentro de sessaoAtual, valendo para todo método que não seja de leitura e para toda rota autenticada, inclusive as que ainda não existem; o código de erro nomeado acesso_inativo, distinto dos três que a entrada já emite; as rotas GET /api/admin/alunos?q= e PATCH /api/admin/alunos/:id/plano; o verificador que reprova tabela de dado de aluno com política de escrita sem a conjunção; o painel "Atribuir plano a aluno" em /admin/planos; e a humanização do status mais o aviso de conta inativa no painel do Aluno e em /perfil.

Como verificar (teste primeiro): os casos de banco rodam contra o Postgres efêmero antes de a tela existir; a negação de escrita é provada pelo código de erro do Postgres (42501), nunca pelo texto da mensagem; e a negação na API é provada pelas quatro rotas de escrita que existem hoje, uma a uma, mais o decoy de uma rota de ensaio criada dentro do próprio teste, que prova que a cobertura é do ponto único e não da lista.

Aceite (H1): Dado um aluno no plano gratuito, Quando o Administrador o busca em /admin/planos e lhe atribui um plano pago mantendo o status ativo, Então a próxima requisição do aluno já lê o plano novo do banco, sem reinício, sem nova sessão e sem nova publicação, E a atribuição gera entrada de auditoria com autor, campo, valor anterior e valor novo, visível em /admin/auditoria, E ao receber o status inativo o mesmo aluno continua entrando no sistema e continua lendo o próprio perfil, o próprio plano e o próprio histórico, E toda escrita dele é recusada, pela API com código próprio e pelo banco com erro de permissão, E nenhum aluno ativo, nem profissional, nem o Administrador tem qualquer escrita afetada.

Fechamento [2026-09-08]: entregue e em produção (37ad0ee, migração 0014_acesso_do_aluno.sql). Ficou pronto: mfit.autor_com_acesso_ativo() no WITH CHECK das cinco políticas de escrita do aluno, negação na camada de API por sessaoAtual com erro acesso_inativo, rotas de busca e atribuição, painel em /admin/planos, aviso de acesso inativo no painel, /perfil e /privacidade. RF-PLAN-002 fecha na parte da atribuição e do status inativo; a parte de limite continua em {F1-15}. TA-16 sobe para 2 de 3, TA-17 fecha 1 de 2, nenhum marcado.

RF-PLAN-003.

O que implementar: o auxiliar mfit.dentro_do_limite_do_aluno(p_aluno_id, p_dimensao, p_ignorar_id), que conta por dentro, com SECURITY DEFINER, e devolve true antes de contar quando a dimensão é ilimitada; a conjunção dele no WITH CHECK das duas políticas de escrita de mfit.vinculo (vinculo_escrita e vinculo_atualizacao), guardada por estado = 'ativo' e excluindo a própria linha por id; a função mfit.plano_que_amplia; o tradutor único server/src/planos/negacaoDeEscrita.ts, que transforma o erro de permissão do banco em resposta nomeada e responde acesso antes de limite; o código de erro limite_do_plano (409), distinto dos que o produto já emite; a seção do gabarito reescrita com o medido; os três campos novos de DIMENSOES_PLANO (forma, tabelaDona, cardDono) com trava própria; e o décimo verificador, com placar próprio.

Como verificar (teste primeiro): os casos rodam contra o Postgres efêmero antes de qualquer rota; a recusa é provada pelo código de erro de permissão do Postgres, nunca pelo texto; o caminho do H1 é provado pelo UPDATE de pendente para ativo em mfit.vinculo, que é o que o aceite de {F2-06} vai fazer, e não só pelo INSERT; e o ilimitado é provado verificando que a contagem não rodou, não só pela ausência de recusa.

Aceite (H1): Dado um aluno no plano Gratuito, cujo limite de vínculos ativos é um, e já com um vínculo ativo, Quando a entrada de um segundo vínculo em estado ativo é tentada, pelo próprio aluno, pelo profissional ou pelo Administrador, Então a operação é recusada pela camada de dados com erro de permissão, e a API a traduz em resposta que nomeia a dimensão, o limite, o plano atual e o plano que o amplia, E após a administração atribuir o plano Essencial a mesma operação conclui na próxima requisição, sem nova sessão, sem reinício e sem nova publicação, E no plano Completo, cuja dimensão é ilimitada, a operação conclui em qualquer quantidade, sem recusa e sem que contagem alguma seja executada, E encerrar, recusar ou cancelar vínculo nunca é recusado por limite, mesmo com o aluno acima do teto, E nenhuma escrita de profissional, de Administrador ou de aluno abaixo do limite é afetada.

Nota: a conjunção de limite (mfit.dentro_do_limite_do_aluno) e a de acesso (mfit.autor_com_acesso_ativo, {F1-14}) são perguntas diferentes e ficam separadas, nunca fundidas num auxiliar só; o sujeito da primeira é o titular da linha, o da segunda é o ator da sessão. Dentro do WITH CHECK a ordem de avaliação do AND não é observável nem garantida, as duas conjunções falham com o mesmo erro de permissão; a ordem "acesso antes de limite" existe em dois lugares reais: em middleware/sessaoAtual.ts, que recusa toda escrita do aluno inativo com acesso_inativo antes de o tratador rodar, e no tradutor negacaoDeEscrita.ts, que pergunta acesso primeiro e só depois limite, para a escrita que porventura não passe pelo middleware.

RF-PLAN-004.

O que implementar: a função mfit.consumo_do_aluno(p_aluno_id, p_dimensao, p_ignorar_id), que recebe o CASE inteiro hoje preso dentro de mfit.dentro_do_limite_do_aluno, com a mesma mensagem de exceção; o CREATE OR REPLACE de dentro_do_limite_do_aluno, que passa a chamá-la, mantendo o retorno antecipado do ilimitado antes da chamada; mfit.plano_vigente_desde, definer, que devolve só um instante; a rota GET /api/meu-plano, privativa do aluno, que lê pelo sub da sessão e nunca por id do pedido; a tela /plano da página 17 com o cartão do plano e as seis linhas de consumo; o link "Plano" na fileira de links do painel do Aluno; as classes .mf-consumo* e o modificador .mf-aviso--bloco; e o décimo primeiro verificador, com placar próprio.

Como verificar (teste primeiro): os casos rodam contra o Postgres efêmero antes de a tela existir; a identidade "consumo exibido igual consumo cobrado" é provada por construção (a política e a rota chamam a mesma função) e por comportamento (a identidade dentro_do_limite_do_aluno === dentro_do_limite(consumo_do_aluno) roda com contagem maior que zero, porque com zero ela é verdadeira à toa); e o decoy de uma rota de ensaio com contagem paralela tem de reprovar.

Aceite (H1): Dado um aluno autenticado, Quando abre /plano, Então vê o nome, a descrição e o status do plano vigente, e as seis dimensões na ordem da lista única, cada uma com o valor máximo, E o consumo exibido em cada dimensão medível vem da mesma função que a política de {F1-15} usa para cobrar, nunca de consulta paralela, E na dimensão ilimitada o lugar do máximo traz a palavra ilimitado, sem barra e sem alerta, ainda que o consumo seja alto, E na dimensão cuja tabela ainda não existe o consumo é exibido como não medido, nunca como zero, E o consumo nunca é limitado ao máximo, um aluno acima do teto por redução de plano vê o número real, com a barra cheia, E o aluno com acesso inativo vê a tela inteira, em leitura, com o aviso único de {F1-14}, E nenhuma escrita, upgrade, cobrança ou botão de mudança de plano existe nesta tela.

Nota: a tela /plano e o estado "conta inativa" com banner âmbar da página 17 são deste card; o painel do Aluno e /perfil receberam em {F1-14} apenas a humanização do status e o aviso, e o texto do aviso vive num só lugar, reusado pelos três.

Nota (F1-15): o consumo desta tela lê pelas mesmas contagens que a política de {F1-15} usa (mfit.dentro_do_limite_do_aluno e o CASE por dimensão), nunca por uma consulta paralela escrita de novo; consumo exibido diferente do consumo cobrado é o defeito clássico desta família.

Fechamento [2026-09-08]: entregue e em produção (03668f4, migração 0016_consumo_do_aluno.sql). Ficou pronto: tela /plano exibindo o consumo pela mesma função que a política de {F1-15} usa (mfit.consumo_do_aluno), mfit.plano_vigente_desde para o campo desde, rota GET /api/meu-plano privativa do aluno, e o décimo primeiro verificador com placar próprio. RF-PLAN-004 fecha. TA-19 fecha 2 de 2 cenários, marcado.

RF-CORE-011.

O que implementar: página sem sessão no endereço raiz, com apresentação do produto, os cinco papéis de público nominados e as chamadas entrar e criar conta; usuário com sessão ativa é levado ao painel do papel. A remoção dos dois links de ferramenta de desenvolvimento da home (/api/estado e /estilo), presentes na home provisória (P2 da Inspeção de 06/09); a fonte única de texto da página (kicker, título, parágrafo do herói, os cinco papéis, os três pilares, cabeçalho e rodapé públicos); o espelho dos quatro rótulos de papel contra CATALOGO_ESPECIALIDADES; e o décimo segundo verificador (ops/verifica-home.mjs), com placar próprio (1 aluno + 4 especialidades = 5 papéis).

Como verificar (teste primeiro): abrir o endereço raiz sem sessão e conferir que não há redirecionamento para a tela de entrada; conferir os cinco papéis e as duas chamadas; abrir o mesmo endereço com sessão ativa de cada papel. A conferência de conteúdo não se faz por requisição sem navegador, porque o servidor devolve o mesmo index.html para qualquer caminho, requisição crua prova só o código de resposta; e o cenário "com sessão ativa" roda com os três papéis (aluno, profissional, administrador), cada um chegando ao painel do próprio papel.

Aceite (H1): Dado um visitante sem sessão, Quando abre o endereço raiz do sistema, Então a página responde com sucesso sem redirecionar para a tela de entrada, E o primeiro bloco da página trata do treino de musculação, antes de qualquer menção a dieta, saúde ou comunicação, E a página exibe os cinco papéis de público nominalmente e as duas chamadas de ação, entrar e criar conta, E cada chamada leva à tela correspondente, E um usuário com sessão ativa que abre o endereço raiz é levado ao painel do papel dele.

Fechamento [2026-09-08]: entregue e em produção. Ficou pronto: home pública no endereço raiz com o treino de musculação como primeiro bloco, os cinco papéis de público nominados, as duas chamadas (entrar, criar conta), o redirecionamento por marcador de sessão para o painel do próprio papel, os dois links de ferramenta de desenvolvimento removidos da home (P2 da Inspeção de 06/09 fechado), e o décimo segundo verificador com placar próprio (1 aluno + 4 especialidades = 5 papéis). RF-CORE-011 fecha. TA-77 fecha 3 de 3 cenários, marcado.

RF-CORE-012, D.6 e ADR-012.

O que implementar: o registro de aceite já existe desde F1-04; este card traz o texto e a versão como configuração editável, os quatro pontos de exibição e a publicação de versão nova sem alterar aceite anterior.

Como verificar (teste primeiro): percorrer os quatro pontos e conferir a presença do texto em cada um; publicar uma versão nova e conferir que os quatro passam a exibi-la e que o aceite anterior continua com a versão antiga.

Aceite (H1): Dado o texto do aviso publicado na versão vigente, Quando um usuário percorre os quatro pontos, Então o aviso aparece nos quatro, E o aceite fica registrado com versão e data, E publicar versão nova troca o texto dos quatro sem alterar o registro do aceite anterior, E remover o aviso de qualquer um dos quatro pontos reprova o card.

Nota [F1-17]: a página pública inicial (RF-CORE-011) não é um quinto ponto deste requisito. Os quatro pontos continuam fixos e nominados (termos do cadastro, cadastro do profissional para as quatro especialidades, topo das quatro telas clínicas, pacote de exportação). A frase de apresentação da home diz o que a plataforma é, em prosa; não consome GET /api/cadastro/aviso-nao-clinico, não registra aceite e não carrega número de versão.

Nota (R-7, fechamento): o card entrega o MECANISMO (tabela versionada, componente único, verificador por critério), não os quatro pontos prontos. Placar honesto: 2 servidos (termos do cadastro, cadastro do profissional) + 2 pendentes (topo das quatro telas clínicas em {F5-01}, {F5-04}, {F5-05}, {F5-06}; pacote de exportação em {F8-09}) = 4. O placar sobe conforme os cards donos nascerem, cada um consumindo <AvisoNaoClinico />.

Fechamento [2026-09-13]: entregue e em produção (42c5637, migração 0017_texto_versionado.sql). Ficou pronto: tabela mfit.texto_versionado (versionada, imutável, RLS ligada), componente único AvisoNaoClinico no front, rota GET /api/textos/:chave/:ponto, painel /admin/textos com edição e publicação de versão nova, décimo terceiro verificador por critério (ops/verifica-aviso-nao-clinico.mjs), textos oficiais semeados (termos de uso versão 2.2, três variantes do aviso não clínico). QA achou e corrigiu o P0 de /privacidade sem o aviso (68e78f0). RF-CORE-012 fecha o MECANISMO, não os quatro pontos: placar 2 servidos (termos do cadastro, cadastro do profissional) + 2 pendentes (telas clínicas em {F5-01}, {F5-04}, {F5-05}, {F5-06}; pacote de exportação em {F8-09}) = 4. TA-85 continua aberto, placar 2 de 4.

RF-CORE-004, RF-CORE-006 e D.2.

O que implementar: o que este card entrega de verdade, medido no gate de plano (R-1 a R-10): o tipo composto mfit.perfil_publico_reduzido (quatro atributos fechados, nome, foto, especialidade e registro) e a função mfit.perfil_publico, únicas portas de leitura reduzida de terceiro; RLS ligada em mfit.usuario, mfit.perfil_aluno e mfit.perfil_profissional, com dez políticas restritas ao titular e ao Administrador, nunca ao vinculado; cinco funções SECURITY DEFINER estreitas (mfit.credencial_por_email, mfit.conta_ativa_por_email, mfit.nome_do_usuario, mfit.papel_do_usuario, mfit.criar_usuario) para os caminhos anônimos por requisito; promoção de claim (set_config dentro da transação, identidade já provada pelo token de uso único) na redefinição de senha e na confirmação de e-mail, cobrindo ao todo os nove caminhos sem claim medidos na Fase 0 do gate; REVOKE DELETE nas três tabelas, para que a exclusão negada seja erro de permissão e não zero linhas; a rota GET /api/perfil/:usuarioId com o ramo do Administrador auditado na mesma transação da leitura; o quarto placar de ops/verifica-acesso-aluno.mjs, por critério nominal (política por linha, conjunto fechado de quatro atributos, varredura estática do server/src proibindo SELECT direto nas três tabelas, os oito campos privados ausentes da resposta HTTP real); e a oitava seção do gabarito, "Perfil público reduzido". A RLS de plano_plataforma foi ligada em {F1-13}; este card apenas a confirma no quarto placar, não a liga de novo. A obrigação herdada de {F1-14} (AND mfit.autor_com_acesso_ativo() no WITH CHECK de perfil_aluno) entra no universo do critério (d) do verificador daquele card, cujo placar sobe de 3 servidas + 17 pendentes = 20 para 4 servidas + 17 pendentes = 21; perfil_profissional e usuario ficam fora desse critério, com motivo escrito (nenhum aluno escreve neles fora do próprio nome).

Como verificar (teste primeiro): consultar o perfil de outro usuário por cada caminho da aplicação e conferir campo a campo o que a resposta traz, procurando nominalmente por telefone, nascimento, sexo, altura, identificador público, plano, status e e-mail; três decoys obrigatórios, cada um visto reprovando antes de ser desfeito (acrescentar telefone ao tipo composto, criar um arquivo com SELECT direto nas três tabelas, remover a política de titular de usuario).

Aceite (H1): Dado dois usuários quaisquer com vínculo entre eles, Quando um consulta o perfil do outro por qualquer caminho da aplicação, Então recebe exatamente nome e foto, mais especialidade e registro quando o outro é profissional, E nenhum dos oito campos privados nominados em D.2 aparece na resposta, E o mesmo pedido feito pelo Administrador retorna o perfil completo com registro de auditoria.

Nota: a política de escrita de perfil_aluno criada aqui carrega AND mfit.autor_com_acesso_ativo() no WITH CHECK, seguindo a seção nova do gabarito de {F1-14}; até este card existir, a negação do PATCH /api/perfil para aluno inativo mora só na camada de API.

Nota (R-3, {TA-06}): a cláusula de perfil do H1 de RF-CORE-006 fecha neste card; as outras três cláusulas (dezesseis entidades, duas restritas, trinta e seis casos) só fecham na Fase 8. O placar N de 36 de {TA-06} não se move aqui: usuario, perfil_aluno e perfil_profissional não estão entre as dezoito entidades de E.1.

Placar honesto do card: 3 tabelas ligadas + 1 confirmada = 4; 4 campos públicos + 8 privados negados; 9 caminhos sem claim tratados; 1 de 4 cláusulas do H1 de {TA-06} fechada; placar N de 36 inalterado. Nunca "RF-CORE-006 fechou": ele fecha na Fase 8.

Nota (R-4, cinco lugares de D.2): a Nota nominal foi publicada nos cards que hoje possuem tela onde dois usuários se encontram: {F2-06} (lista de vínculos), {F7-07} a {F7-10} (carteira), {F6-01} e {F6-02} (conversa), {F6-03} (grupo). O quinto lugar, "autoria de registro" (o nome do autor de uma ficha, plano, prescrição ou sessão exibido a outro usuário), não tem um único card dono hoje: recorre em cada card que grava e exibe autoria (entre outros, {F3-01}, {F3-02}, {F3-04}, {F5-01}, {F5-04}, {F5-05}, {F5-06}); cada um desses, ao nascer, segue a mesma regra (consumir a leitura reduzida, nunca um SELECT próprio), e o quarto placar deste card os pega no dia em que nascerem lendo a tabela na mão.

RF-EXER-001.

Aceite (H1): Dado o Administrador na tela de exercícios, Quando cria um exercício com os onze campos do apêndice, incluindo erros comuns e dicas de execução, Então ele aparece na busca de todos os usuários e a tela do exercício exibe os dois campos novos como blocos próprios abaixo das instruções, E um exercício com os dois vazios não exibe bloco vazio, E toda operação de criação, edição ou exclusão por papel diferente de Administrador é negada.

Nota (R-1): a semente prometida (docs/seed/exercicios.csv e docs/seed/midia/) com os 113 exercícios do protótipo ainda não chegou. Este card entrega o mecanismo completo de manutenção do catálogo mais o importador idempotente (ops/importar-exercicios.mjs), e abre com o placar honesto 0 de 113 exercícios importados. O mapeamento de colunas segue o esquema medido do protótipo até o README da pasta chegar; nenhum exercício é inventado, e nenhum é redigitado à mão.

Fechamento [2026-09-13]: merge f3addf5 na main, deploy provado em produção (https://fit.modulareasy.com, versão f3addf5); migração 0019 aplicada (tabela mfit.exercicio, três enums, três índices, quatro políticas, três gatilhos de auditoria reaproveitados, extensão pg_trgm); gates plan, qa e review verdes (qa PASS após correção de dois achados P0 de contrato em 608633c); décimo quarto verificador (ops/verifica-exercicios.mjs) registrado. Placar da semente: 0 de 113 exercícios importados, porque docs/seed/exercicios.csv do dono não existe (pendência dele, fora do escopo de código, sem bloquear o card). Telas entregues: /admin/exercicios, /exercicios, /exercicios/:id.

Nota (fechamento da semente, 2026-09-14): docs/seed/exercicios.csv chegou (commit 53cb783, branch feat/semente-exercicios, merge na main pendente nesta data); ops/importar-exercicios.mjs --aplicar rodou em produção: 113 de 113 importados, 0 atualizados, 0 recusados, confirmado por contagem direta no banco (113 exercícios ativos). Placar da semente passa de 0 de 113 para 113 de 113. A etapa de mídia de {F2-02} continua 0 de N, docs/seed/midia/ ainda ausente.

RF-EXER-002.

Como verificar (teste primeiro): medir a proporção renderizada e comparar com a proporção natural do arquivo, não julgar a olho.

Aceite (H1): Dado um exercício com imagem enviada e endereço de vídeo, Quando o aluno o abre durante a sessão, Então a imagem é exibida na proporção natural e o vídeo aparece embutido e reproduzível, E um exercício sem mídia exibe o espaço reservado sem alterar a altura dos demais elementos.

Nota (R-13): o card entrega envio de imagem pela administração com guarda de tamanho e formato por bytes; endereço externo de imagem aceito; vídeo por endereço de lista fechada, embutido e reproduzível; dimensão natural medida no servidor; exibição por aspect-ratio sem deslocamento; retângulo reservado quando não há mídia; middleware único de cabeçalhos de segurança; importador estendido para docs/seed/midia/ abrindo em 0 de N porque a pasta não existe (medido); décimo quinto verificador, o primeiro com navegador. Placar: 13 de 13 campos do formulário, 1 de 2 pontos de exibição de mídia (execução da sessão pendente em {F3-05}), 1 de 2 repositórios com escrita, 27 parâmetros de operação. {TA-21} fica aberto.

Fechamento [2026-09-13]: entregue e em produção (merge 9d326d0 na main, https://fit.modulareasy.com); migração 0020 aplicada (duas colunas de dimensão em mfit.exercicio, zero política e zero gatilho novos, as quatro políticas e os três gatilhos de {F2-01} já cobriam); gates plan, qa e review verdes (qa aprovado na rodada 3, após BUG-01, BUG-02 e o achado do DELETE). Ficou pronto: middleware único de cabeçalhos de segurança emitido pela própria aplicação, não pelo vhost do servidor web da frente; imagem por arquivo enviado ou por endereço externo, na mesma coluna; vídeo sempre por endereço, lista fechada de serviços; as duas colunas de dimensão medidas no servidor a partir dos bytes do arquivo, alimentando aspect-ratio sem deslocamento; retângulo reservado quando não há mídia; décimo quinto verificador (ops/verifica-midia-exercicio.mjs), o primeiro com navegador, medindo a proporção renderizada por getBoundingClientRect() contra naturalWidth/naturalHeight, tolerância 0,5 por cento. Placar honesto: 13 de 13 campos do formulário, 1 de 2 pontos de exibição de mídia (execução da sessão pendente em {F3-05}), 1 de 2 repositórios com escrita, 27 parâmetros de operação, semente de mídia do dono (docs/seed/midia/) ausente, placar 0 de N. {TA-21} continua aberto.

RF-EXER-003.

Aceite (H1): Dado um catálogo com exercícios de dez grupos musculares, Quando o usuário filtra por grupo Costas e dificuldade Iniciante, Então a lista contém somente itens que atendem às duas condições, E o contador exibido é igual ao número de itens listados.

Nota (R-10, {F2-01}): {F2-01} já entrega a busca por texto no nome mais o contador, na mesma rota e na mesma consulta, porque o H1 de RF-EXER-001 exige que o exercício apareça na busca de todos os usuários e uma lista sem contador não se verifica. Este card não reconstrói a rota nem o índice: acrescenta os quatro filtros combináveis (grupo, dificuldade, categoria, equipamento) na MESMA rota e na MESMA consulta, e o contador continua sendo o mesmo número da lista, nunca uma segunda contagem.

Fechamento [2026-09-14]: merge 05d52cf na main, deploy provado em produção (https://fit.modulareasy.com, versão 05d52cf); sem migração, sem índice novo (o exercicio_grupo_dificuldade_idx existente 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, dentro de transação desfeita: 0,242 ms com grupo mais dificuldade, 0,144 ms com os quatro filtros mais o LIKE); gates plan, qa e review verdes. Ficou pronto: grupo, dificuldade, categoria e equipamento como parâmetros opcionais e combináveis da MESMA rota GET /api/exercicios, validados contra os conjuntos fechados de catalogo.ts (400 parametro_invalido por campo, nunca uma segunda lista de valores), equipamento como texto livre de comparação exata com o vocabulário vindo do próprio dado; totalAtivos calculado na mesma janela da consulta (count(*) FILTER (WHERE ativo) OVER()), nunca uma segunda consulta nem contagem no cliente; tamanhoPagina lido da resposta do servidor nas duas telas. Verificador npm run verificar:exercicios rodou 15 de 15 no critério (h), aprovado, zero problemas. Dois drifts corrigidos antes do H1 fechar: a paginação pública usava uma constante local (ITENS_POR_PAGINA=20) desalinhada com o tamanhoPagina=24 do servidor, e o cabeçalho da administração contava itens.filter(...).length sobre a página carregada em vez do universo do catálogo; os dois passaram a ler o número do servidor, sem placar novo de RF (paginação é D.1, já publicada). {TA-22} fecha. Construção sobe de 23 de 96 para 24 de 96.

RF-EXER-004.

Aceite (H1): Dado um aluno no plano gratuito e sem vínculo, Quando abre o catálogo, Então consulta qualquer exercício com nome, mídia e instruções, E nenhuma ação de escrita é oferecida nem aceita para ele.

Fechamento [2026-09-14]: entregue e em produção (merge 98db15a na main, deploy provado em https://fit.modulareasy.com, versão 98db15a); sem migração; gates plan, qa e review verdes. Ficou pronto: três pontos de entrada por interface, o link Exercícios nos painéis do aluno, do profissional e do administrador (único gap funcional medido, a tela já existia desde {F2-01}); décimo quarto verificador com dois critérios novos, (j) 0 de 6 dimensões de plano tocam o catálogo (ausência gravada como medida, não como zero) e (k) 5 de 5 rotas que mutam mfit.exercicio sob /api/admin com o papel conferido antes do banco, por varredura de server/src/rotas; décimo quinto verificador com sessão real de aluno navegando /exercicios e o detalhe sem encontrar nenhum controle de escrita; arnês leituraPorPapel.test.ts com aluno criado pela rota real (Gratuito, 0 vínculos), lendo lista, detalhe e mídia, cinco negações para aluno e profissional com controle positivo de administrador. {TA-23} fecha, {TA-21} continua aberto (pendente da execução da sessão em {F3-05}). Construção sobe de 24 de 96 para 25 de 96.

RF-VINC-001.

Aceite (H1): Dado um profissional autenticado e um aluno sem vínculo com ele, Quando envia o convite pelo identificador do aluno, Então nasce um vínculo pendente, E o aluno recebe a notificação, E toda consulta do profissional a dado desse aluno retorna vazia enquanto pendente.

Nota (achado do code-review em F1-08): a política vinculo_leitura hoje usa pode_ler_aluno(aluno_id), que responde por vínculo ATIVO com o aluno, sem amarrar à linha de vínculo específica sendo lida. Ao construir a máquina de estados deste card, a leitura de vinculo deve passar a profissional_id = mfit.usuario_atual() OR aluno_id = mfit.usuario_atual() OR papel administrador, e não pode_ler_aluno(aluno_id) genérico: hoje um profissional com vínculo ativo lê também os convites pendentes do aluno com outros profissionais, e ver os próprios vínculos não é ver dado clínico do aluno.

Nota (F1-15): o convite nasce pendente e pendente não conta limite, a guarda de RF-PLAN-003 é na entrada em ativo; além disso a recusa por par já existente é 23505 do índice único parcial, uma recusa diferente da de limite, com mensagem própria, e o tradutor único de {F1-15} só age sobre o erro de permissão.

Nota (gate {F2-05}, achado de planejamento): a Descrição de RF-VINC-001 permitia busca "ou pelo nome" no DRS; reconciliado, pois {ART-ACS-11} e D.2 nunca aceitam nome nem LIKE, e o H1 já citava só o identificador. O convite se faz somente pelo identificador que o aluno dita ou copia do próprio perfil.

Nota (gate {F2-05}, transição sem dono): E.3 lista seis transições do vínculo; pendente para cancelado (profissional cancela o próprio convite) não aparece em H1 de nenhum card da Fase 2 até aqui, embora o mockup preveja a ação "Cancelar" na carteira. Este card não a constrói; o dono fica a nomear entre {F2-06} e {F2-07} no fechamento da fase.

Fechamento [2026-09-14]: merge 7eaa87b na main, deploy provado em produção (https://fit.modulareasy.com, versão 7eaa87b); migração 0021_convite_de_vinculo.sql; gates plan, qa e review verdes. Ficou pronto: a política vinculo_leitura passa de pode_ler_aluno(aluno_id) para "meus vínculos" (profissional dono da linha, aluno titular ou Administrador), com a perda declarada e única, o profissional com vínculo ativo deixa de ler as linhas de vínculo do aluno com terceiros; mfit.usuario_por_identificador_publico, sexta função SECURITY DEFINER estreita, resolve o identificador MF-XXXX-XX por igualdade exata e devolve só o uuid; gatilho AFTER INSERT ON mfit.vinculo WHEN (NEW.estado = 'pendente') enfileira a notificação de convite por e-mail na origem, garantindo por construção que todo caminho que cria vínculo pendente notifica; POST /api/vinculos (identificador no corpo, especialidade sempre do perfil) e GET /api/vinculos no arquivo já existente; tela /alunos mínima, com o convite e a lista de pendentes enviados. Décimo sexto verificador (ops/verifica-vinculo.mjs) com quatro placares: 3 de 3 políticas restritas às partes mais Administrador, 1 de 6 transições servidas, 27 de 27 pontos que criam vínculo pendente notificam por construção, pendente 0 linha e ativo 1 linha no lado negativo do acesso. {TA-11} fecha. Construção sobe de 25 de 96 para 26 de 96.

RF-VINC-002.

Aceite (H1): Dado um vínculo pendente, Quando o aluno aceita, Então o vínculo fica ativo e o profissional enxerga os dados nas categorias consentidas, E quando recusa, o vínculo fica recusado e nenhuma consulta do profissional retorna registro.

Nota (F1-15): o aceite é um UPDATE de pendente para ativo e já nasce coberto pela política de {F1-15}; não escrever uma segunda verificação de limite no tratador, envolver a escrita em SAVEPOINT e chamar traduzirNegacaoDeEscrita, que devolve a mensagem que RF-PLAN-003 exige.

Nota (F1-16): nada muda; a guarda e a mensagem continuam as de {F1-15}.

Nota (R-4, {F1-19}): a lista de vínculos do aluno (tela de vínculo pendente e ativo, com nome e foto do profissional do outro lado) consome GET /api/perfil/:usuarioId (ou a função perfilPublicoReduzido, quando a leitura for no servidor); proibido SELECT próprio em mfit.usuario, mfit.perfil_aluno ou mfit.perfil_profissional. O quarto placar de ops/verifica-acesso-aluno.mjs reprova o arquivo novo que ler a tabela na mão, e a política por linha já nega telefone, nascimento, sexo, altura, identificador público, plano, status de acesso e e-mail.

Nota (gate {F2-06}, escopo reconciliado em 2026-09-14): entrega o aceite e a recusa pelo aluno no bloco Vínculos de /perfil (tela 23), sem rota /vinculos nova; GET /api/vinculos passa a servir os dois papéis; a notificação ao profissional nasce por gatilho na origem, irmão do de {F2-05}; a auditoria da transição nasce por critério (WHEN estado mudou AND NEW.estado <> 'inativo'), ação alterar, sem valor de enum novo; o placar de transições da máquina de estados fecha em 3 de 6 servidas ou 4 de 6 se a prova de reconvite rodar, sempre medido; e a cláusula "categorias consentidas" do H1 se prova hoje por mfit.consentimento e mfit.pode_ler_aluno, com o placar honesto 0 de 6 tabelas de categoria sensível (nascem na Fase 5).

Fechamento [2026-09-14]: merge 9b994b0 na main, deploy provado em produção (https://fit.modulareasy.com, versão 9b994b0); migração 0022_aceite_e_recusa_do_vinculo.sql; gates plan, qa e review verdes. Ficou pronto: aceite e recusa como UPDATE condicional dentro de SAVEPOINT, guardado por aluno_id = claims.sub AND estado = 'pendente' no próprio WHERE, sem segunda verificação de limite fora da política de {F1-15}; notificação ao profissional por gatilho na origem, irmão do de {F2-05} (AFTER UPDATE OF estado ... WHEN (OLD.estado = 'pendente' AND NEW.estado IN ('ativo','recusado'))); auditoria da transição por critério (WHEN OLD.estado IS DISTINCT FROM NEW.estado AND NEW.estado <> 'inativo'), ação alterar, sem valor de enum novo; GET /api/vinculos passa a servir os dois papéis, conserto e não feature, o aluno recebia lista vazia com 200; bloco Vínculos nasce em /perfil (tela 23), sem rota /vinculos nova; /alunos do profissional passa a exibir o estado real da linha. Décimo sexto verificador (ops/verifica-vinculo.mjs), dois critérios mais exigentes: máquina de estados com o placar 4 de 6 transições servidas, mais o lado negativo novo, as duas transições proibidas de E.3 com o caminho de escrita medido que as alcança hoje (POST /api/vinculos/:id/desativar), dono nomeado {F2-07}; notificação exaustiva pelos dois gatilhos (0021 e 0022). Arnês com banco real prova as duas cláusulas do H1 com controle positivo e negativo, inclusive a jornada completa do limite. {TA-12} fecha; {TA-18} fecha com a jornada completa (recusa por limite, ampliação, ilimitado). pendente para cancelado e a transição proibida hoje alcançável pela rota de desativar seguem nomeadas para {F2-07} (entregue). Construção sobe de 26 de 96 para 27 de 96.

RF-VINC-003.

Aceite (H1): Dado um vínculo ativo com três fichas criadas pelo profissional, Quando qualquer um dos dois encerra, Então o vínculo fica inativo, E as três fichas continuam existindo com a autoria preservada e visíveis ao aluno e ao Administrador, E toda criação ou edição pelo profissional nesse aluno é negada.

Nota (F1-15): encerrar vínculo nunca é recusado por limite, mesmo com o aluno acima do teto, a guarda estado = 'ativo' da conjunção de {F1-15} garante isso; e o Apêndice manda que reduzir o plano não apague nada.

Nota (gate {F2-06}, dono nomeado em 2026-09-14): este card é o dono de pendente para cancelado (o botão "Cancelar" do convite pelo profissional, tela 25 do mockup), decidido pelo critério do ATOR: {F2-06} serve as duas transições do aluno (aceitar, recusar), {F2-07} serve as de encerramento, inclusive esta, que é do profissional sobre o próprio convite. Medição que este card herda: POST /api/vinculos/:id/desativar ({F1-10}) hoje aceita um vínculo pendente e o leva a inativo (WHERE id = $1 AND estado <> 'inativo'), produzindo a transição pendente para inativo que E.3 declara proibida; o conserto dessa rota é deste card, e o verificador (item b) imprime as duas transições proibidas de E.3 e o caminho de escrita medido que as alcança até o conserto entrar.

Fechamento [2026-09-14]: merge 42cd973 na main, deploy provado em produção (https://fit.modulareasy.com, versão 42cd973); migração 0023_encerramento_do_vinculo.sql; gates plan, qa e review verdes. Ficou pronto: gatilho BEFORE UPDATE OF estado (mfit.validar_transicao_vinculo) valida a tabela de E.3 na origem, recusando pendente para inativo e ativo para pendente com P0001, nunca só pelo WHERE das rotas; nenhuma rota /encerrar nasce, POST /api/vinculos/:id/desativar consertado e restrito a ativo, mais a rota nova POST /api/vinculos/:id/cancelar (pendente para cancelado, profissional dono ou Administrador); perda declarada e devolvida, o Administrador sai de /desativar num convite pendente e entra em /cancelar; notificação das duas partes por gatilho na origem (mfit.enfileirar_saida_de_vinculo, SECURITY DEFINER), encerramento notifica os dois lados e cancelamento notifica o aluno; e-mail de cancelamento corrigido no review antes do merge. Arnês com banco real (encerramento.test.ts, 22 casos) prova o H1 pelos dois lados, aluno e profissional, em tabela de ensaio mfit.ficha_ensaio. {TA-13} fecha. Décimo sexto verificador: placar de transições em 6 de 6, placar de notificação em 6 de 6. Construção sobe de 27 de 96 para 28 de 96.

RF-VINC-004, RF-PLAN-003 e E.3.

O que implementar: nenhuma guarda por especialidade na criação nem no aceite do vínculo; a única recusa é a do limite de vínculos do plano; unicidade apenas do par aluno e profissional em estado ativo ou pendente.

Como verificar (teste primeiro): conferir no banco que não existe índice nem verificação por aluno e especialidade; aceitar dois vínculos da mesma especialidade num plano ilimitado.

Aceite (H1): Dado um aluno num plano com vínculos ilimitados e já vinculado a um Personal Trainer, Quando aceita o convite de um segundo Personal Trainer, Então passa a ter dois vínculos ativos na mesma especialidade e os dois enxergam os dados consentidos, E aceitar Médico, Fisioterapeuta e Nutricionista leva o total a cinco sem recusa nenhuma, E a única recusa possível é a do limite do plano, E um convite do mesmo profissional que já tem vínculo ativo com o aluno é recusado por já existir aquele par.

Nota (F1-15): a única recusa por quantidade é a do limite de vínculos; a recusa por par repetido é outra coisa (índice único, 23505); e nenhuma guarda por especialidade nasce, nem no WITH CHECK.

Fechamento [2026-09-14]: merge 25e96ad na main, deploy provado em produção (https://fit.modulareasy.com, versão 25e96ad); nenhuma migração nova, última continua 0023; zero linha de código de produto tocada, este card é PROVA. Ficou pronto: critério (e) novo em verificarVinculos.ts mais placar em ops/verifica-vinculo.mjs, por universo de catálogo, nunca varredura de palavra, com decoy obrigatório de seis trechos (quatro que reprovam, dois que passam). Placar de ausência: 0 de 15 objetos de mfit.vinculo usam especialidade como guarda (1 restrição, 3 índices, 4 políticas, 7 gatilhos); 0 de 5 caminhos de escrita em mfit.vinculo aplicam guarda por especialidade. Placar positivo, dentro da mesma transação: 4 de 4 especialidades do catálogo aceitam vínculo ativo simultâneo no mesmo aluno, 2 vínculos ativos de personal_trainer no mesmo aluno, 5 vínculos ativos no total, contagem do limite = 5; teto de exibição medido e impresso, 50 linhas por consulta, sem paginação (Drift 3, dono {F7-07}). Arnês server/src/vinculos/simultaneos.test.ts (16 casos), rotas reais, e-mails com MX, transação desfeita: as quatro metades de {TA-14} providas (cinco vínculos pelas rotas reais sem recusa por especialidade; par repetido recusado com 409 vinculo_ja_existe; plano numérico até estourar com a mensagem que nomeia o limite; conferência no banco aplicado, zero predicado sobre especialidade nos quinze objetos). Décimo sexto verificador: placar de transições inalterado, 6 de 6; medição idêntica reproduzida contra a produção. Construção sobe de 28 de 96 para 29 de 96.

RF-VINC-005.

Aceite (H1): Dado o Administrador na tela de vínculos, Quando filtra por estado pendente, Então a lista mostra somente pendentes com profissional, aluno, especialidade e data, E ao desativar um vínculo o profissional deixa de acessar aquele aluno na consulta seguinte.

Nota ({F2-08}): filtro de listagem por especialidade nesta tela não é guarda de vínculo, que RF-VINC-004 proíbe por desenho; o critério (e) do verificador ops/verifica-vinculo.mjs (núcleo em verificarVinculos.ts) reprova quem confundir os dois.

Nota (gate {F2-09}, escopo reconciliado em 2026-09-14): entra a listagem global dos vínculos com os quatro filtros (estado, especialidade, profissional e aluno) e paginação por chave, a tela /admin/vinculos com o ponto de entrada no menu da administração, e as três ações pelas rotas que já existem (desativar vínculo ativo, cancelar convite pendente e excluir em definitivo), sem rota de ação nova, sem política, sem gatilho e sem valor de enum novo. Não entra "Ativar" e não entra "Novo vínculo" pelo Administrador: E.3 não tem evento de ativação por terceiro, o único caminho até ativo é o aceite do aluno (RF-VINC-002), e o gatilho de validação de transição confere o par de estados e não o ator, então hoje é a ausência do botão que sustenta a regra. Se o botão existisse, a notificação de aceite diria "vínculo aceito" sem que o aluno tivesse aceitado, e a trilha registraria a alteração sem dizer por que alguém que não é parte mudou o estado. A Descrição de RF-VINC-005, a linha do Apêndice de telas, esta jornada e a tela 33 do mockup prometiam "Ativar"; a linha do Apêndice, a jornada e a Nota do mockup foram reconciliadas para o que a máquina sustenta, o requisito NÃO foi editado, e "Ativar" e "Novo vínculo" continuam sem card dono, como decisão de produto a confirmar com o dono, porque abrir acesso a dado de aluno sem ato do aluno é decisão de privacidade (D.2, RN-003).

Nota (gate {F2-09}, Drift 4, 2026-09-14): GET /api/vinculos hoje devolve 200 com lista vazia ao Administrador, porque o núcleo decide por papel e qualquer papel que não seja aluno cai no ramo do profissional, cujo filtro é o próprio identificador. É o terceiro papel da mesma classe de defeito que {F2-06} consertou quando o aluno recebia lista vazia com 200, e este card é o dono do conserto: a rota passa a recusar o Administrador nomeando a porta certa, e a resposta ao aluno e ao profissional continua idêntica, campo a campo. Fechamento [2026-09-14]: merge 0668358 na main, deploy provado em produção (https://fit.modulareasy.com, versões 97f3760 e 7523ed9 durante o card, final 0668358); migração 0024_gestao_global_de_vinculos.sql (índice vinculo_criado_em_id_idx e COMMENT da função mfit.perfil_publico, nada além); gates plan, qa e review verdes. Ficou pronto: nenhuma rota de ação nova, as três ações (desativar, cancelar, excluir) continuam pelas rotas que já existiam; rota nova GET /api/admin/vinculos, listagem global paginada por chave com os quatro filtros (estado, especialidade, profissional, aluno), nomes resolvidos por LEFT JOIN LATERAL mfit.perfil_publico, sem citar as três tabelas de perfil; tela /admin/vinculos com Desativar, Cancelar e Excluir, cada uma com confirmação nominal, sem botão Ativar e sem Novo vínculo (decisão A do mds-architect: E.3 não tem evento de ativação pelo Administrador, RF-VINC-002 dá o aceite ao aluno; "Ativar" e "Novo vínculo" seguem sem card dono, como decisão de produto a confirmar com o dono). Perda declarada e única: GET /api/vinculos passa a devolver 403 negado ao Administrador em vez do 200 com lista vazia que nenhum consumidor usava; aluno e profissional recebem os mesmos campos de antes. Critério (c) do quarto placar de ops/verifica-acesso-aluno.mjs ganha lista nominal de dois chamadores autorizados de mfit.perfil_publico; filtro por especialidade provado, no arnês, que não é guarda (o vínculo escondido pela lista continua ativo e continua dando acesso). Arnês server/src/rotas/admin/vinculos.test.ts (unitário, client falso) e server/src/vinculos/gestaoGlobal.test.ts (banco real) provam as duas metades de {TA-15}: filtro por estado pendente trazendo só pendentes, com a aritmética das linhas restantes fechando contra o total sem filtro; e a desativação pelo Administrador, com a sessão do profissional aberta antes, sem novo login, lendo zero depois, mais o controle negativo de um segundo profissional que continua lendo o aluno. {TA-15} fecha. Construção sobe de 29 de 96 para 30 de 96, e a Fase 2 fecha.

RF-CORE-008, RN-008, D.6.

O que implementar: remover em definitivo, na ordem das chaves estrangeiras, as contas inspecao-qa-20260906@modulareasy.com, inspecao-visual-20260907@modulareasy.com, inspecao-qa2-aluno-20260914@modulareasy.com e as duas inspecao-qa3-*-20260914@modulareasy.com (criadas pelo QA da Inspeção em 14/09), com os vínculos, consentimentos, fichas, auditoria e e-mails associados, registrando a contagem removida por tabela no CHANGELOG; acrescentar ao ops/ um comando limpar-contas-de-teste --prefixo inspecao- reutilizável pelo Administrador.

Como verificar (teste primeiro): contar linhas por tabela antes e depois; select count(*) from mfit.usuario where email like 'inspecao-%' igual a zero; curl https://fit.modulareasy.com/api/estado 200.

Aceite (H1): Dado o banco de produção com as cinco contas de teste, Quando o comando roda com o prefixo, Então zero usuários com o prefixo permanecem, E nenhuma linha órfã fica em vínculo, consentimento, ficha, auditoria ou e-mail, E as contas reais e as três de topo (wladimir, c3po, r2d2) permanecem intactas, E o comando recusa rodar sem prefixo.

Nota (gate {AUD-03}, reconciliado em 2026-09-14): RN-008 nunca autoriza apagar entrada de auditoria (ela é mantida, anonimizada); o texto acima cumpre isso por dois verbos: apaga o que deixa de existir (usuário, perfis, aceite de termos, sessão, token, vínculo, consentimento, ficha, solicitação, e-mail) e anonimiza (autor_id e aluno_id postos a NULL, o resto da linha permanece) a entrada de auditoria cuja referência parte de linha que sobrevive; o comando ainda grava, na mesma transação, uma entrada excluir por conta removida com origem = 'ops/limpar-contas-de-teste', atendendo D.6. Medido em 14/09: o alvo são 4 contas, não 5 (inspecao-qa2-aluno-20260914@ já havia sido removida pelo qa de {F3-02}); auditoria.entidade_id não tem chave estrangeira, e 5 entradas hoje apontam para linhas de vinculo que saem com o alvo. A execução em produção espera o merge de {F3-04} e a limpeza das contas qa.f304.* do qa dele, banco compartilhado com sessão em voo em 14/09.

RF-CORE-007, RF-CORE-008, RF-CORE-009, RF-PLAN-001, RF-PLAN-002, RF-PAIN-009, RN-010, ADR-017 e os blocos B.1, B.4, B.5 e B.6 do DRS. A escada de acesso passa a ter dois papéis de administração: o Super Administrador, de quem opera a plataforma, e o Administrador, da operação do dia.

O que implementar: (1) migração do tipo papel_usuario acrescentando o valor de super administrador, sem remover nenhum valor existente; (2) migração de dados promovendo a super administrador exatamente as três contas de topo da plataforma, medidas na data do card, e nenhuma outra, com a mudança de papel gravada na trilha de auditoria como qualquer outra; (3) revisão de TODA política de acesso por linha, função auxiliar e guarda de rota que hoje compara o papel com o literal de administrador, agora em TRÊS classes e não duas: onde a capacidade é comum aos dois papéis, a comparação passa a ser contra a lista dos dois; onde a capacidade é uma das sete privativas de governança de B.1, a comparação passa a ser apenas contra super administrador; e onde a entidade pertence à fronteira de dado clínico (as quatorze capacidades de B.1, dez por classificação e quatro por conteúdo, estas últimas alcançando conversa, mensagem, conta de integração, atividade externa e o acionamento da geração assistida), a comparação também passa a ser apenas contra super administrador, valendo para LEITURA e para escrita, o que exige que o auxiliar único de decisão de acesso (ART-ACS-07) passe a receber a entidade consultada e a lista das entidades da fronteira viva num lugar só; (4) telas de administração divididas conforme o Apêndice de catálogo de telas, sete rotas para os dois papéis, /admin/auditoria só para o Super Administrador e /admin/planos com escrita do Super Administrador e leitura do Administrador; (5) na tela de usuários, as quatro ações privativas deixam de ser oferecidas ao Administrador na interface E são negadas no servidor, sendo a interface consequência da negação e nunca o controle; (6) semente idempotente das três contas de topo no padrão de RN-010, com o registro de quem é quem e a senha vigente no arquivo de credenciais do projeto, fora do repositório.

Como verificar (teste primeiro): contar, antes da migração, quantas contas têm papel de administrador e quais são, e conferir depois que exatamente essas três viraram super administrador e que a contagem de cada um dos demais papéis não mudou; varrer o código e o catálogo do banco por toda comparação com o literal de papel de administrador e fechar o placar nas três classes acima, comum, privativa de governança e fronteira de dado clínico, sem sobra; entrar com uma conta de Administrador criada para o teste e exercitar, uma a uma, as capacidades privativas de governança que já têm rota nesta data, esperando negação em cada uma e fechando 4 de 7: atribuir plano e status de acesso, escrever na tela de planos, excluir em definitivo e abrir a trilha de auditoria; as três restantes não têm rota nenhuma, e por isso a negação delas se prova no banco, pelo gatilho de governança que este card instala, com a negação por rota nascendo nos cards donos, bloquear e desbloquear conta e promover ou rebaixar papel em {F7-14} e personificar em {AUD-05}; pedir, com essa mesma conta, leitura e escrita em cada uma das quatorze capacidades da fronteira, pela tela E pela rota direta, esperando negação nas vinte e oito tentativas, sem conteúdo parcial e sem lista vazia que se confunda com resultado legítimo (a diferença entre negado e vazio se prova criando o dado com outra conta antes de pedir, e as quatro capacidades de conteúdo exigem conversa, atividade importada e proposta gerada já existentes no banco); exercitar as rotas comuns que já existem e o dado não clínico do mesmo aluno, inclusive as preferências de treino, que ficam com ele, esperando sucesso e fechando 7 de 10 do lado positivo, porque das sete rotas comuns existem quatro nesta data (/admin, /admin/exercicios, /admin/vinculos e /admin/textos) e as três restantes nascem nos cards donos, /admin/usuarios em {F7-14}, /admin/relatorios em {F7-13} e /admin/guia em {F9-03}; contar as células diferentes de N por coluna na matriz do DRS e conferir 41 para o Super Administrador e 20 para o Administrador, com as 21 células divergentes enumeradas nominalmente e não só subtraídas.

Aceite (H1): Dado o banco migrado, Quando se conta o papel de cada conta, Então exatamente as três contas de topo têm papel de super administrador e nenhuma outra conta teve o papel alterado, E um Administrador criado para o teste entra, alcança as rotas de administração comuns que já existem, lê a tela de planos e opera o dado não clínico de qualquer aluno, fechando 7 de 10 do lado positivo, com as três que faltam nomeadas com o card dono (/admin/usuarios em {F7-14}, /admin/relatorios em {F7-13} e /admin/guia em {F9-03}), E as capacidades privativas de governança de B.1 que já têm rota são negadas a ele pela rota e pela política de acesso por linha, e não apenas escondidas na interface, fechando 4 de 7, com as três que faltam nomeadas com o card dono (bloquear e desbloquear conta e promover ou rebaixar papel em {F7-14}, personificar em {AUD-05}) e a negação das duas primeiras provada nesta data no banco, pelo gatilho de governança, E as quatorze capacidades da fronteira de dado clínico negam a ele leitura e escrita, fechando 28 de 28 tentativas negadas com dado existente no banco, E as preferências de treino continuam alcançáveis por ele, prova de que a fronteira é a lista de B.1 e não uma impressão de sensibilidade, E a contagem de capacidades por papel devolve 41 e 20, diferença de 21 que se decompõe em 7 mais 14, E a semente das três contas rodada duas vezes seguidas não cria conta repetida, não rebaixa papel e não sobrescreve senha já trocada.

Perda declarada, e ela tem duas metades. Primeira metade, governança: o papel de Administrador, que até aqui era o topo, deixa de poder sete coisas que podia, que são atribuir plano e status de acesso, manter o catálogo de planos e os limites operacionais, bloquear e desbloquear conta pela administração, promover ou rebaixar papel e criar conta de Administrador, personificar usuário, excluir em definitivo e consultar a trilha de auditoria. Segunda metade, dado clínico: ele deixa de LER e de escrever anamnese, avaliação física, medida corporal, foto de progresso, exame, prescrição, sessão de reabilitação, refeição, meta nutricional e plano alimentar de aluno nenhum, em unidade nenhuma, e deixa também de ler as conversas do aluno, de operar e ler as integrações de atividade dele e de acionar a geração assistida, quatro capacidades que não são categorias de saúde mas transportam o dado delas. Preferências de treino ficam com ele (RN-001). Consequência operacional que se declara em vez de se descobrir depois: o chamado de suporte que toca saúde, dieta, evolução, conversa ou relogio passa a exigir escalada ao Super Administrador, que lê sob o consentimento já dado (RF-CORE-007) ou personifica com registro (RF-CORE-014); em troca, nenhuma conta de operação do dia guarda acesso permanente a dado de saúde, que é o menor privilégio que a decisão buscou. Continua podendo tudo o mais, inclusive atravessar o isolamento sobre o dado não clínico, sempre com registro de auditoria. Perda técnica que vem junto: toda comparação por igualdade com o literal de papel de administrador deixa de ser suficiente, e a que sobrar sem revisão vira negação indevida ao Super Administrador ou, pior, permissão indevida ao Administrador sobre dado de saúde, que é exatamente o que o placar de três classes do Como verificar mede.

RF-CORE-014, RF-CORE-010, D.2, D.5 e a entidade sessao_personificacao de E.1. O Super Administrador assume a visão de um usuário para dar suporte, e tudo o que acontece nesse período fica rastreável até ele.

O que implementar: depende de {AUD-04}. (1) tabela sessao_personificacao, apenas acrescida, com personificador, personificado, início, fim e motivo do fim; (2) início da personificação por ação explícita com confirmação nominal a partir de /admin/usuarios, negada a todo papel que não seja Super Administrador e negada também quando o alvo é Super Administrador; (3) sessão personificada que carrega as permissões do personificado, nunca as do personificador, com as políticas de acesso por linha decidindo pelo personificado; (4) faixa permanente no topo de toda tela enquanto a personificação durar, nomeando quem está sendo personificado, mostrando o tempo restante e oferecendo a saída; (5) trilha de auditoria com entrada de início e entrada de fim, e com o par personificador e personificado em toda entrada gerada no período; (6) saída por ação explícita ou por expiração de trinta minutos, parâmetro de configuração, voltando à sessão do Super Administrador sem exigir nova entrada. (7) fechamento da personificação expirada em dois níveis: preguiçoso na aplicação, nos três pontos que já abrem transação, a passagem pela camada única de sessão, a renovação e o início de uma personificação nova, cobrindo todo operador que volta; mais uma rotina de operação chamada pelo agendador do sistema que já existe, de dez em dez minutos, cobrindo quem não volta, com a janela de até dez minutos declarada na ficha {ART-WF-19} do Inventário de Artefatos. Nenhum agendador de aplicação nasce aqui. (8) personificar conta bloqueada pela administração é permitido, porque personificar não é entrar e o bloqueio continua valendo para o próprio usuário: a única negação de alvo continua sendo a conta de Super Administrador.

Como verificar (teste primeiro): personificar um aluno e conferir, pela rota real, que a leitura devolve os dados dele e não os de outro aluno; conferir na tela que a faixa aparece em cada uma das rotas alcançadas, contando telas visitadas contra telas com faixa e fechando o placar; escrever um registro sob personificação e conferir que o autor gravado é o personificado e que a entrada de auditoria traz o par; tentar escrever numa categoria sensível sem consentimento do titular e esperar bloqueio; sair e conferir a entrada de fim; deixar expirar e conferir a segunda forma de fim; tentar personificar com conta de Administrador, de profissional e de aluno, esperando negação nas três; tentar personificar uma conta de Super Administrador, esperando negação.

Aceite (H1): Dado o Super Administrador autenticado e um aluno alvo, Quando inicia a personificação, Então as telas respondem com os dados e as permissões do aluno, E a faixa aparece em todas as telas alcançadas, E a trilha ganha a entrada de início com personificador, personificado e momento, E toda entrada gerada no período traz o par, E a escrita em categoria não consentida pelo titular continua bloqueada, E a saída explicita e a expiração de trinta minutos produzem cada uma a entrada de fim, E a mesma ação pedida por Administrador, profissional ou aluno é negada nos três casos, E personificar uma conta de Super Administrador é negado.

Nota de fechamento [2026-09-29]: merge 3dabc30, https://fit.modulareasy.com, migrações 0034, 0035 e 0036, gates plan, qa (rodada 2, PASS COM RESSALVAS) e review (APPROVED) verdes. Provado em produção pelo qa, com curl de cookie real e navegador em dois temas e duas larguras: sair pela faixa devolve o Super Administrador a /admin sem tela de entrada (8 de 8 combinações), /admin/auditoria mostra início e fim de personificação com o par (Autor "operador como alvo"), a faixa aparece em 44 de 44 telas visitadas do aluno (11 telas em 4 combinações), a expiração fecha a linha com o motivo certo, e as negações dão 403 para Administrador, profissional e aluno, para alvo Super Administrador e para si mesmo. {ART-WF-19} instalado no crontab do host, de dez em dez minutos. Ressalvas nominais, nenhuma bloqueia o card: /admin/usuarios é mínima e o resto é de {F7-14}; as negações de senha e e-mail sob personificação seguem sem rota para provar (as rotas ainda não existem); o travessão em /plano e em células vazias de /admin/auditoria e a carga direta de /privacidade e /plano sem marcador de sessão são preexistentes e viram cards próprios.

Perda declarada: nada do que existe hoje deixa de funcionar, porque a capacidade é nova. O que se perde de propósito é a possibilidade de o operador da plataforma olhar a tela do usuário sem deixar rastro: a partir deste card, ver o sistema pelos olhos de alguém custa duas entradas na trilha de auditoria e uma faixa visível na tela. O Administrador não ganha essa capacidade, e o suporte que ele presta continua sendo pelo alcance cross-unidade de RF-CORE-007, que mostra o dado sem assumir a sessão.

RF-TREI-001.

Nota (F1-16): ao criar a tabela da dimensão, o ramo novo entra no CASE de mfit.consumo_do_aluno (não mais em dentro_do_limite_do_aluno, que desde {F1-16} só decide); sem o ramo a função continua levantando exceção, de propósito, e a política nova nasce quebrando, nunca liberada em silêncio; e a tela /plano passa a exibir aquela dimensão sozinha, sem uma linha de código de front, não escrever uma segunda contagem para a tela.

Aceite (H1): Dado um profissional com vínculo ativo, Quando cria uma ficha com título e quatro exercícios com séries, repetições e descanso, preenchendo a observação num dos itens, Então a ficha aparece na lista do aluno com os quatro itens na ordem definida, E o autor registrado é o profissional que a criou, E na execução o item com observação a exibe junto do exercício, E os três sem observação não reservam espaço para ela.

Nota (F1-10): entidade removível de RF-CORE-008. ficha_treino já tem status; ao aplicar a seção de remoção do gabarito (GABARITO-ACESSO-ALUNO.md), este card declara se inativo passa a usar o status existente ou se a tabela ganha desativado_em/desativado_por como as demais (R-2 do gate {F1-10}), além da política FOR DELETE exigindo o papel administrador e do gatilho de remoção, com o verificador de verificarPoliticas.ts rodando antes do gate do qa.

Nota (F1-15): a dimensão fichas_ativas é servida por esta tabela; ao criar a tabela, aplicar a seção "Limite de plano por dimensão" do gabarito e acrescentar o ramo 'fichas_ativas' ao CASE de mfit.dentro_do_limite_do_aluno, sem o ramo a função levanta exceção, de propósito, e a política nova nasce quebrando, nunca liberada em silêncio.

Nota (R-9, {F2-01}): a exclusão definitiva do exercício no catálogo global é livre só enquanto nada o referencia. Quando ficha_item nascer aqui, a coluna exercicio_id entra com REFERENCES mfit.exercicio(id) ON DELETE RESTRICT (nunca CASCADE, para não apagar histórico de treino do aluno), e a tela de administração de exercícios passa a recusar a exclusão com mensagem própria, mantendo a desativação como caminho.

Nota (D-6, {F2-07}): autoria preservada é regra de LEITURA, não de ESCRITA. Ao criar tabela de dado de aluno com coluna autor_id, a política FOR SELECT chama mfit.pode_ler_aluno(aluno_id, autor_id); as políticas FOR INSERT e FOR UPDATE chamam mfit.pode_ler_aluno(aluno_id) sem o segundo argumento, em conjunção com mfit.autor_com_acesso_ativo() (seção "Autoria preservada não é escrita preservada" do GABARITO-ACESSO-ALUNO.md). O critério (e) de ops/verifica-acesso-aluno.mjs reprova qualquer política de escrita que passe autor_id.

Nota (D-3, {F2-08}): autoria também é regra por LINHA, e a conjunção que a garante é diferente da de leitura. Quem chega aqui consulta as DUAS seções do GABARITO-ACESSO-ALUNO.md: "Autoria preservada não é escrita preservada" (a Nota acima, D-6, {F2-07}) e "Autoria por LINHA", que é esta. Por RN-009, só o autor da ficha e o Administrador a editam, e RF-VINC-004 torna o cenário comum, porque o aluno acumula vínculos ativos da mesma especialidade: dois personal trainers ativos ao mesmo tempo, cada um com as próprias fichas. Sem a conjunção AND autor_id = mfit.usuario_atual() na política FOR UPDATE, o UPDATE de um profissional sobre a linha do outro é silenciosamente ACEITO, sem erro e sem aviso, porque mfit.pode_ler_aluno(aluno_id) responde verdadeiro para os dois. A conjunção vai no FOR UPDATE; no FOR INSERT a mesma igualdade existe por outro motivo, garantir que a autoria nasça de quem escreve e que ninguém grave ficha em nome de outro, e as duas não se confundem.

Nota de smoke (gate {F3-01}, Drift 8, 2026-09-14): o catálogo global de exercícios está em 0 de 113 em produção nesta data, e a semente é pendência nomeada fora deste card. Isso NÃO bloqueia o código nem o arnês, que criam os exercícios de que precisam pelas rotas reais, dentro da transação que desfazem; governa o smoke com olhos humanos, porque ninguém monta uma ficha de quatro exercícios numa tela cuja busca não devolve nada, e o smoke reprovaria a tela por um defeito que não é dela. Antes do smoke, o qa cadastra pela tela real de administração de exercícios QUATRO exercícios de grupos musculares diferentes, deixa-os no catálogo (exercício é catálogo global legítimo, não é conta de teste) e registra no relatório do card quais criou. Esperar a semente seria parar a fila do produto por pendência de terceiro, e a própria pendência diz que não bloqueia a fila.

Fechamento [2026-09-14]: merge 17bd22e na main, gates plan, qa e review verdes (processo padrão autônomo), deploy provado em produção (https://fit.modulareasy.com), versões em produção durante o card 58d3727, 4a7b6a1, 90f0db0, d0aafb4, final 17bd22e; migração 0025_ficha_de_treino.sql aplicada, última migração em produção. Seis seções na mesma migração: as tabelas mfit.ficha_treino e mfit.ficha_item (D-2); as três políticas de acesso com as perguntas de autoria separadas, leitura com dois argumentos (aluno_id, autor_id), escrita com um (aluno_id), e autor_id = mfit.usuario_atual() a mais no UPDATE (D-3, D-6 e D-3 de {F2-07} e {F2-08}); os dois gatilhos de remoção na forma de três argumentos, desativação por status (D-1, decisão declarada, ficha_treino NÃO ganhou desativado_em/desativado_por); o ramo fichas_ativas no CASE de mfit.consumo_do_aluno (D-5); exercicio_id com ON DELETE RESTRICT e a rota traduzindo 23503 em 409 exercicio_referenciado, perda declarada e única, o Administrador deixa de excluir em definitivo um exercício referenciado por ficha, com a desativação como caminho equivalente e nomeado na mensagem (D-6, D-14); e as duas funções SECURITY DEFINER do Adendo, mfit.negacao_por_limite_do_aluno e mfit.acesso_do_aluno_ativo, ambas STABLE, guarda única mfit.pode_ler_aluno(p_aluno, NULL, false). Três rotas, nenhuma a mais: POST e GET /api/fichas, GET /api/fichas/:id (D-9). Três telas: criação (/fichas/nova), lista do aluno (/treinos, entrega mínima) e detalhe (/treinos/:id, detalhe da mesma tela de /treinos, não uma décima quinta), as três com caminho de chegada pela interface e componente único do item (ItemDaFicha.tsx, D-11 e D-12). Nome do autor por LEFT JOIN LATERAL mfit.perfil_publico, terceiro chamador nominal, trava síncrona de !== 2 para !== 3, COMMENT ON FUNCTION mfit.perfil_publico(uuid) reescrito na mesma migração (D-10). Verificador do Drift 7 com o critério novo indireto (varredura de information_schema.columns não alcança as seis tabelas de forma 2, sem aluno_id) e decoy que reprova de verdade: placar 1 servida + 5 pendentes = 6 tabelas de forma 2. Placares honestos colados pelo qa: acesso 2 de 18 tabelas com autor_id cobertas pelo critério (e); remoção 2 de 11 entidades com o gatilho genérico; entidades sensíveis inalteradas; inativo (entidades removíveis com coluna de estado declarada) 5 + 16; consumo_do_aluno 2 de 6 dimensões com ramo no CASE; chamadores nominais de mfit.perfil_publico 3 de 3. O verificador de exercícios (ops/verifica-exercicios.mjs) passou a detectar citação de mfit.exercicio em qualquer posição da consulta, não só no FROM, fechando dois pontos cegos achados no qa e no code-reviewer durante este card. Uma perda declarada e intencional (D-14); nenhuma outra: nenhum papel perde capacidade, nenhuma rota existente muda de resposta, nenhum placar existente muda de valor fora dos de cobertura. {TA-24} continua [ ], as duas primeiras cláusulas do "Passa quando" provadas aqui, as duas últimas aguardando {F3-05} (Nota já publicada em {TA-24}, Drift 4).

RF-TREI-002 e ADR-002.

Aceite (H1): Dado um aluno sem nenhum vínculo ativo, Quando cria uma ficha com três exercícios, Então a ficha é salva com autoria dele e fica disponível para execução, E aparece para os profissionais vinculados depois, identificada como criada pelo aluno.

Nota de escopo (gate {F3-02}, Drift 2, 2026-09-14): o que entra neste card: o próprio aluno cria ficha para si, sem vínculo nenhum, pela MESMA tela /fichas/nova que {F3-01} construiu (a Nota do Apêndice de catálogo de telas já decidiu que a criação tem uma tela só servindo os dois papéis, e nenhum prefixo por papel nasce aqui); e o profissional lê essa ficha pela MESMA tela /treinos, com o aluno na consulta, chegando até ela pela linha do aluno em /alunos. Isso reconcilia a implementação ao catálogo, nunca o contrário: o Apêndice de catálogo de telas do DRS já declara /treinos e /fichas/nova servindo Aluno, Profissional, e foi a implementação de {F3-01} que estreitou uma ao papel aluno e a outra ao papel profissional. O requisito não é editado, o ADR não é editado e o Apêndice de telas não é editado: os três já estão certos. O que NÃO entra: edição de ficha ({F3-03}), pedido de ajuste e solicitação de ficha nova ({F3-04}), duplicação ({F3-09}), execução ({F3-05}), histórico ({F3-07}), preferências ({F3-08}), a tela de detalhe do aluno ({F7-07} a {F7-11}) e a geração assistida por IA (Fase 8, {F8-05} e {F8-12}), esta última em nenhuma forma, nem botão desabilitado, nem rótulo "em breve", nem banner: ausência é ausência. A criação NÃO se abre ao Administrador: a Matriz de papéis deriva "criar ficha de treino" de RF-TREI-001 e RF-TREI-002, e ele não está em nenhum dos dois (RN-009 lhe dá a edição, não a criação), então o guarda de papel é fechado em lista, nunca removido. Placares de tela: {ART-SCR-01} e {ART-SCR-02} não mudam, porque nenhuma tela nova nasce e /treinos e /fichas/nova já são contadas uma vez cada, em {ART-SCR-01}, pelo precedente de /perfil. Placar de banco: nenhum, este card não cria tabela nem migração, e a última migração em produção continua 0025.

Nota do rótulo de autoria (gate {F3-02}, Drifts 3 e 4, 2026-09-14): a pergunta "fui eu que criei?" é sobre o LEITOR; o campo que o servidor calcula responde uma pergunta sobre a LINHA, "o autor é o titular da ficha?". Até este card as duas coincidiam por acidente, porque nenhuma ficha em produção tinha o aluno como autor, e por isso o detalhe da ficha dizia "Criada por você" a QUALQUER leitor, inclusive ao profissional que abrisse a ficha de um aluno; a lista, do outro lado, nunca consultava o campo e mostrava o nome do autor, de modo que a mesma ficha já se descrevia de dois jeitos para o mesmo leitor. Não é defeito de texto: é a assinatura de que a regra mora em dois arquivos de tela e só um deles sabe que ela existe. A partir daqui o rótulo tem ponto único, um módulo só, com função pura que decide pelo LEITOR antes de decidir pela linha, nesta ordem: o leitor é o autor, "Criada por você"; o autor é o titular da ficha, "Criada pelo aluno"; caso contrário, o nome do autor com o registro quando houver; sem nome, "Autor não disponível". A identidade do leitor vem da sessão, nunca de comparação de identificadores feita na tela e nunca de uma segunda consulta. O ponto único é protegido por critério de verificador próprio, com lista nominal fechada de arquivos autorizados a ler o campo, trava de cardinalidade que recusa carregar o módulo se a lista crescer sem decisão, e decoy visto reprovando antes de ser desfeito. Esta Nota governa os sete cards futuros que a Nota (R-4, cinco lugares de D.2) já nomeia como exibidores de autoria, {F3-05}, {F3-07}, {F3-09}, {F5-01}, {F5-04}, {F5-05} e {F5-06}: cada um consome a mesma função e a mesma leitura reduzida, nunca um SELECT próprio e nunca um if novo na tela onde o defeito aparecer. {TA-25} não ganha Nota: ele fecha inteiro neste card, porque as duas metades do "Passa quando" (a ficha salva com autoria do aluno, e a mesma ficha aparecendo ao profissional vinculado depois, identificada como criada pelo aluno) passam a ser servíveis pela interface aqui.

Fechamento [2026-09-14]: merge 3d25e27 na main, gates plan, qa e review verdes (processo padrão autônomo, .claude/gates/{plan,qa,review}/modularfit-F3-02.gate), deploy provado em produção (https://fit.modulareasy.com), versões em produção durante o card 7c9f722, 7c2f833, 28e97bf, final 3d25e27; ZERO migração, última em produção continua 0025_ficha_de_treino.sql (D-3, provado em Postgres efêmero na VPS, conjunção por conjunção). Guarda de criarFicha fechado em lista de papéis (profissional, aluno), nunca por exclusão (D-1); Administrador recebe 403 com mensagem nomeando os dois papéis que criam. alunoId opcional só para o titular, com 403 na camada 1 antes do banco quando o aluno informa alunoId alheio (D-2). Rótulo de autoria com ponto único em web/src/fichas/autoria.ts, decidindo pelo LEITOR antes da LINHA, consumido pelos dois lugares que hoje exibem autoria (D-5); décimo sétimo verificador ops/verifica-rotulo-autoria.mjs, lista nominal fechada, trava de cardinalidade e decoy visto reprovando (D-11). /treinos passa a servir os dois papéis por ?aluno=, com o link novo na linha do aluno em /alunos (D-4); /fichas/nova ganha o ramo do aluno, sem seletor e sem GET /api/vinculos para ele (D-9); três caminhos de chegada novos, painel do aluno, topo e vazio de /treinos, e a linha de /alunos (D-10). Achado do qa durante o card, corrigido no mesmo card: FichaDetalhe não tratava aluno_id no caminho de volta por papel, ajustado para o profissional voltar a /alunos e o aluno a /treinos. Perda declarada e única (D-13): POST /api/fichas deixa de responder 403 "Somente o profissional cria..." ao papel aluno, e o caso de teste homônimo foi invertido, não apagado, passando a provar a aceitação do aluno e a recusa do alunoId alheio; o caso irmão do Administrador permanece. {TA-25} fecha inteiro (as duas metades do H1 provadas pela interface real). Nenhum outro papel perde capacidade, nenhuma rota existente muda de resposta fora da declarada.

RF-TREI-003, ADR-006 e RN-009.

Aceite (H1): Dado uma ficha criada por um Personal Trainer, Quando o aluno dono tenta alterar séries, repetições, ordem ou lista, Então a operação é negada e as ações oferecidas são consultar, pedir ajuste e duplicar, E quando o autor faz a mesma alteração ela é gravada e produz auditoria com valor anterior e novo.

Nota de escopo (gate {F3-03}, Drifts 7, 8 e 9, 2026-09-14): o que ENTRA neste card: a edição da ficha pelo autor e pelo Administrador (RN-009 dá a edição aos dois, e é o banco de hoje que recusa o Administrador, o que se corrige na migração 0026, nunca no requisito); a negação ao não autor nas duas camadas (ADR-013), com a única ação que existe hoje, consultar; a auditoria da alteração com valor anterior e valor novo pelo gatilho genérico, que é o que o H1 cobra por escrito; e a desativação e a reativação da ficha, que entram aqui porque o mecanismo existe no banco desde {F3-01} e nenhum card posterior da Fase 3 o reivindica, medido card a card de {F3-04} a {F3-10}: se não nascer aqui, não nasce na fase, e o teto de fichas ativas fica beco sem saída para o aluno no limite. O que NÃO entra: pedir ajuste, que é a solicitação de RF-TREI-004 e tem card dono {F3-04} (a entidade solicitacao_ficha e o cartão {ART-SM-03} já declaram isso, e o próprio RF-TREI-003 remete a duplicação a RF-TREI-009 pelo texto); duplicar, RF-TREI-009, card dono {F3-09}; execução ({F3-05}); histórico ({F3-07}); preferências ({F3-08}); retomada ({F3-10}); e a notificação de prescrição alterada ({ART-WF-06}), em nenhuma forma. Ao não autor a tela oferece apenas consultar: nenhum botão desabilitado, nenhum rótulo "em breve", nenhum banner explicando que a ação chega depois. Ausência é ausência, e oferecer as duas ações que ainda não existem seria mentir na tela para fechar um caso de teste. O título do card não é editado: ele descreve a intenção do produto, e esta Nota descreve a fronteira da entrega. A edição não é tela nova: é ESTADO da tela de criação /fichas/nova, alcançado pelo caminho /fichas/:id/editar, no mesmo precedente já usado por /exercicios/:id e /treinos/:id, e por isso {ART-SCR-01} e {ART-SCR-02} não mudam de placar. O requisito não é editado, o ADR não é editado e RN-009 não é editada: os três já estão certos, e quem diverge deles é o banco. {TA-09} fecha inteiro neste card; {TA-26} fica [ ] com Nota nominal, no precedente literal de {TA-24}; {TA-08} sobe de placar sem fechar. Placar de banco: nenhuma tabela nova, e a última migração em produção passa de 0025 para 0026 no fechamento.

RF-TREI-004.

Aceite (H1): Dado um aluno com vínculo ativo, Quando envia solicitação com motivo preenchido, Então o profissional recebe a notificação e vê a solicitação aberta, E ao criar a ficha vinculando a solicitação o estado passa a atendido e o aluno recebe a notificação com a ficha nova.

Nota de escopo (gate {F3-04}, 2026-09-14): o que ENTRA neste card: as duas formas de pedido que RF-TREI-004 descreve no próprio texto, a ficha nova e o ajuste de uma existente, cada uma com a sua pergunta gravada em coluna própria; o atendimento pelo profissional destinatário, criando a ficha ou alterando a que é dele, com o estado passando a atendida; a recusa com motivo obrigatório; os três avisos do fluxo {ART-WF-05}, por gatilho na origem, no molde dos três avisos de vínculo que já estão em produção; e o acompanhamento do próprio pedido pelo aluno, em forma mínima, que a jornada dele cobra por escrito. O que NÃO entra: duplicar, que é RF-TREI-009 e tem card dono {F3-09}; a execução ({F3-05}), o cronômetro ({F3-06}), o histórico ({F3-07}), as preferências ({F3-08}) e a retomada ({F3-10}), e por isso sessao_treino, sessao_serie e preferencia_treino não nascem aqui e {ART-ENT-04} para em 3 de 6; a central de notificações com sino, contagem e limpar todas, que é {F6-05} e {ART-ENT-07}; a notificação de prescrição alterada ({ART-WF-06}), em nenhuma forma, cujo dono continua sendo {F6-05}; o painel do profissional com os cinco indicadores, a carteira, o alerta de inativo e o bloco por especialidade, que é {F7-07}, de modo que {ART-DASH-02} continua [ ] e {ART-SCR-02} continua 1 de 4; e a geração assistida, que é da Fase 8, em nenhuma forma, nem botão desabilitado, nem rótulo "em breve", nem banner: ausência é ausência. O título do card não é editado, e nenhum requisito, regra de negócio ou decisão de arquitetura é editada: o que se reconcilia são três descrições que estavam incompletas diante do próprio RF, a especificação da entidade em E.1 e em {ART-ENT-04}, a máquina de estados em E.3 e a Matriz Ator por Capacidade, mais as notas de fronteira do Inventário. Os quatro caminhos são estado e caminho de telas já contadas, nunca rota nova de catálogo: pedir ficha nova e acompanhar vivem em /treinos, pedir ajuste vive em /treinos/:id, ver e resolver vivem em /pro/painel, e atender leva a /fichas/nova com a solicitação na consulta; é o mesmo precedente já firmado por /exercicios/:id, por /treinos/:id e pelo estado de edição em /fichas/:id/editar, e por isso {ART-SCR-01} continua 5 de 14 e {ART-SCR-02} continua 1 de 4. O bloco do profissional nasce mínimo, no precedente literal da /alunos mínima de {F2-05} e do bloco Vínculos dentro de /perfil de {F2-06}. Donos nominais do que fica de fora: duplicar é {F3-09}, a central de notificações é {F6-05}, o painel completo é {F7-07}. {TA-27} fecha inteiro neste card; {TA-26} continua [ ] com Nota atualizada, porque duplicar continua ausente; {TA-09}, {TA-24} e {TA-25} não são tocados. A tela de detalhe da ficha, que desde {F3-03} oferecia ao não autor apenas consultar, passa a oferecer consultar e pedir ajuste, e essa é a única mudança de comportamento que este card declara.

RF-TREI-005.

Nota (R-15, {F2-02}): a exibição da mídia na execução da sessão é o ponto 2 de 2 de {TA-21} e o ponto 2 de 2 de {TA-20}. Este card não reimplementa a leitura da mídia nem o cálculo de proporção: consome o mesmo componente único de mídia de {F2-02}, e o que fecha aqui são os dois placares, não um desenho novo.

O que implementar: navegação exercício a exercício com a observação do item visível, cronômetro geral, registro de série aceitando carga e repetições ou tempo de execução em segundos, observação por série e observação da sessão, pular exercício, encerrar a qualquer momento, e bloqueio de tela do dispositivo enquanto a sessão está em andamento, liberado ao encerrar ou ao sair da tela.

Como verificar (teste primeiro): executar a ficha no celular e deixar a tela ociosa durante a sessão, conferindo que ela não escurece onde o navegador concede o bloqueio, e que a ausência do recurso não gera erro nem interrompe a sessão.

Aceite (H1): Dado um aluno com ficha de cinco exercícios, Quando inicia a sessão, registra três séries de carga no primeiro, pula o segundo, registra no terceiro uma série por tempo de sessenta segundos sem repetições e conclui os demais, Então a sessão registra duração maior que zero, um exercício pulado, as séries de carga completas e a série por tempo com os sessenta segundos e repetições vazias, sem erro de validação, E o volume soma apenas as séries com carga e repetições, ignorando a série por tempo (RN-004), E as observações da série e da sessão aparecem no histórico, E durante a sessão a tela do dispositivo não escurece por inatividade em todo navegador que conceda o bloqueio.

RF-TREI-006.

Aceite (H1): Dado um exercício com descanso de sessenta segundos, Quando o aluno conclui uma série, Então a contagem começa em sessenta e decresce, E ao chegar a zero emite o aviso e libera a série seguinte, E o botão de pular encerra a contagem imediatamente.

Nota de escopo (gate {F3-06}, 2026-09-15): o que ENTRA neste card: a contagem regressiva a partir do alvo definido em ficha_item.descanso, lido de ItemDaSessao.descanso_segundos; o aviso sonoro ao chegar a zero; o aviso visível e anunciável que acompanha o som; o botão de pular; e o botão de ajustar o tempo na hora (+15 s) que a Descrição de RF-TREI-006 exige e o mockup materializa, a quarta obrigação que o H1 não nomeia mas a Descrição sim. Cinco comportamentos que nenhum artefato declarava e que o mockup decide: o descanso não começa quando não há série seguinte a liberar, nem quando o alvo é zero; pular exercício, navegar para outro exercício, encerrar a sessão e sair da tela cancelam o descanso sem aviso sonoro; a barra mostra o tempo restante e esvazia; e o descanso não persiste, de modo que recarregar a página no meio dele volta ao bloco de registro. O que NÃO entra, com dono nominal: nenhuma coluna, migração, tabela, índice, restrição, política, gatilho, função de banco ou rota; nenhum parâmetro de operação; e a vibração, que não está em requisito, em inventário, em caso de teste nem no mockup, e por isso não entra em forma nenhuma. A preferência do aluno de silenciar o aviso sonoro não existe em artefato nenhum hoje: está registrada em {Q2} do Questionário, sem bloquear a fila. O título do card não é editado e o H1 do card não é editado.

RF-TREI-007.

Aceite (H1): Dado um aluno com carga máxima anterior de quarenta quilogramas no supino, Quando conclui uma sessão com quarenta e cinco, Então o histórico exibe a variação de mais cinco naquele exercício, E a primeira execução de um exercício exibe a marcação de primeira medição em vez de variação.

Nota de escopo (gate {F3-07}, 2026-09-15): o card entrega RF-TREI-007 inteiro, as oito obrigações da Descrição e do H1, em três pontos de entrega: a tela /treinos/historico, com uma linha por sessão concluída trazendo data, ficha, duração, volume e contagem de séries, mais um chip de variação por exercício; o bloco de evolução por exercício no resumo da execução, com o link Ver histórico no lugar do comentário datado que hoje declara o beco sem saída; e a carga máxima anterior exibida durante a execução, ao lado do descanso alvo, elemento que o desenho aprovado já atribuía a este card por nome e que a Descrição de RF-TREI-007 passou a nomear nesta data. A progressão é derivada na leitura, em ponto único, nunca agregado gravado: nenhuma coluna, tabela, índice, restrição, política, gatilho, função de banco ou migração nasce aqui. O chip tem quatro estados (subiu, caiu, igual e primeira medição) e o quinto não nasce: exercício cuja sessão só teve tempo, ou que foi pulado, simplesmente não tem chip, pela regra terminal de RN-004, cálculo não exibido e nunca em zero; carga zero registrada de propósito é valor, não ausência, e entra na cadeia. A janela de retenção do histórico visível do plano passa a ser aplicada aqui, na leitura, pelo mesmo ponto único, com o valor ilimitado não filtrando nada, e a comparação de carga continua sobre todo o histórico do aluno, porque a janela decide quais sessões são listadas e nunca quais fatos são verdadeiros; a decisão e os dois cenários estão registrados em {Q3} do Questionário, e a dimensão de retenção do histórico visível, que até aqui não tinha card dono em nenhuma das oito fases, passa a ter este card como dono declarado. Cinco comportamentos que nenhum artefato declarava e que este card decide: a sessão abandonada não entra na lista; a linha clicada leva ao resumo daquela sessão; o profissional vinculado abre a mesma tela com o aluno na consulta, chegando por /treinos; os chips vêm um por exercício com série registrada, na ordem dos itens da ficha; e a barra de resumo mostra a contagem de sessões e a soma de volume do filtro corrente. Sem paginação, porque nenhum artefato a declara para esta tela: o volume se resolve pelo filtro de período com teto de linhas e o total visível, de modo que teto atingido se veja em vez de truncar calado; se vier a ser necessária, é card novo. O que NÃO entra, com dono nominal: caixa de seleção por linha, Selecionar todas e ação em lote são RF-PAIN-010 e {F7-16}; o gráfico de progressão de carga por exercício é RF-ENGA-005 e {F7-05}; melhor marca, recorde e marco pessoal não estão em artefato nenhum e não nascem, sob pena de requisito nascido num gate; sequência de dias e calendário são {F7-02} e {F7-03}; conquistas são {F7-04} e {F7-05}; atalho de retomar, retomada e passagem automática a abandonada são {F3-10}; listar sessão abandonada no histórico não tem dono hoje e, se o dono quiser, é card novo; cronômetro de descanso e aviso sonoro são {F3-06}; preferências de treino são {F3-08}; duplicação de ficha é {F3-09}; painel do aluno e treino do dia são {F7-06}; a tela de detalhe do aluno para o profissional é {F7-07} a {F7-11}; exportação do histórico em arquivo é RF-CORE-007 e card da Fase 8; notificação, sino e contagem são {F6-05}; geração assistida é da Fase 8, {F8-05} e {F8-12}. Em todas, ausência é ausência: sem botão desabilitado, sem rótulo "em breve", sem banner. Aritmética de placares, que só se movem no fechamento, medidos no dia: {ART-SCR-01} passa de 6 de 14 para 7 de 14 com /treinos/historico, que é linha própria do Apêndice de catálogo de telas e não detalhe de /treinos; {ART-WF-04} passa de 2 de 5 para 3 de 5 passos e o cartão segue [ ]; {ART-SCR-02} continua 1 de 4, porque a tela serve os dois papéis e é contada uma vez só, no precedente literal de /perfil, /treinos e /fichas/nova; {ART-ENT-04} continua 5 de 6 tabelas; {ART-CFG-01} continua com vinte e oito parâmetros; {ART-SM-03} continua [ ], porque o card lê o estado concluída e não produz transição; {ART-DASH-01} e {ART-DASH-02} continuam [ ]; {TA-30} fecha inteiro, e só depois de as seis cláusulas que faltavam entrarem no "Passa quando". O título do card não é editado e o H1 do card não é editado.

RF-TREI-008.

Aceite (H1): Dado um aluno na tela de preferências, Quando escolhe dois objetivos, nível intermediário, cinco equipamentos, três dias e sessenta minutos e salva, Então os valores aparecem preenchidos ao reabrir, E o profissional vinculado enxerga as mesmas preferências na ficha do aluno.

Nota de escopo (gate {F3-08}, 2026-09-15): o card entrega RF-TREI-008 inteiro, as oito obrigações da Descrição e do H1, e nada além: os sete campos do Apêndice de catálogo de formulários, com objetivos e nível obrigatórios e os outros cinco opcionais (RN-002, todo o restante nasce nulo), as três listas fechadas do Apêndice (oito objetivos, três níveis, vinte e seis equipamentos), os dias da semana de segunda a domingo, a duração de 20 a 120 minutos com passo de 5, e os dois textos de até 2000 caracteres cada. A tela /treinos/preferencias passa a existir em catálogo: ela não tinha linha no Apêndice de catálogo de telas do DRS nem em {ART-SCR-01}, apesar de o H1 falar em "tela de preferências", e essa reconciliação foi publicada nesta data, mudando o universo do cartão de telas do aluno de catorze para quinze. Ela é uma só e serve os dois papéis, no precedente literal de /perfil, de /treinos, de /fichas/nova e de /treinos/historico: o profissional vinculado chega à mesma rota com o aluno na consulta e a vê em somente leitura de verdade, com os valores e sem controle nenhum, nunca um formulário desabilitado, e o estado vazio dele tem texto próprio, porque dizer "preencha suas preferências" a quem não pode preencher é mentira de tela. A escrita é exclusiva do titular, numa rota que nunca aceita identificador de aluno, e por isso a Matriz Ator por Capacidade ganhou nesta data duas linhas e não uma, registrar e ler, com marcas diferentes. O ponto de entrada é um botão Preferências no cabeçalho de /treinos, ao lado do Histórico, com a mesma regra de parâmetro, porque os dois pontos de entrada que o desenho aprovado tem para esta tela são de outros cards, o passo de primeiros passos do painel ({F7-06}) e o resumo da geração assistida (Fase 8), e sem um terceiro a tela nasceria inalcançável. Preferência não guarda série, e isso é decisão declarada, não omissão: aluno_id é único, é uma linha por aluno, M.3 manda ler sempre o valor vigente, e o valor anterior de cada alteração já fica na trilha imutável de RF-CORE-009, gravada pelo gatilho genérico; se o dono quiser uma tela de histórico de preferências, é card novo. O que NÃO entra, com dono nominal: o botão Salvar e gerar treino que o desenho põe dentro desta mesma tela, a tela de gerar treino e qualquer leitura das preferências pela geração assistida são {F8-05} e {F8-12}; a correspondência entre a lista fechada de vinte e seis equipamentos do aluno e o equipamento em texto livre do exercício do catálogo não existe hoje em artefato nenhum e não nasce aqui, e o dono dela é {F8-05}, que é quem precisa cruzar as duas para cumprir o H1 de RF-IAGE-001; o bloco de primeiros passos do painel e a rotação de fichas por preferência são {F7-06}; a tela de detalhe do aluno é {F7-07} a {F7-11}, e quando ela nascer a aba de treino linka para esta rota em vez de redesenhar o bloco; notificar o profissional quando a preferência muda é {F6-05}, e {ART-WF-06} não menciona preferência; materializar o parâmetro de listas fechadas em tabela editável é do card que vier a ser dono de {ART-CFG-01}, que tem 1 de 28 materializado; exclusão da preferência não é de ninguém, porque a entidade não está entre as onze de RF-CORE-008 e o aluno esvazia editando. Em todas, ausência é ausência: sem botão desabilitado, sem rótulo "em breve", sem banner. Duas declarações que o card faz em vez de corrigir: o mesmo fato clínico é dado sensível quando vive na anamnese e não é sensível quando o aluno o escreve no campo de limitações e lesões, porque RN-001 fecha a lista em seis categorias e preferência não está nelas; a assimetria passa a estar escrita em RN-001 e nas Notas do requisito, a tela avisa o aluno do alcance do campo antes de ele escrever, e a pergunta de produto sobre restringir esse campo por especialidade está em {Q4} do Questionário, sem bloquear a fila. E {Q2}, sobre silenciar o aviso sonoro do cronômetro, também não bloqueia: o card entrega o Cenário 1, e se o dono responder o Cenário 2 a emenda é uma coluna e um controle, em card novo. Aritmética de placares, que só se movem no fechamento, medidos no dia: {ART-ENT-04} fecha em 6 de 6 tabelas com a sexta e última; {ART-SCR-01} passa a 8 de 15, universo já crescido nesta reconciliação; {ART-FORM-03} fecha em 7 de 7 campos, com o campo Estado que ele não tinha; {ART-SCR-02} continua 1 de 4; {ART-CFG-01} continua com vinte e oito parâmetros, nenhum nasce, nenhum é materializado e nenhum é lido; {ART-WF-12} continua [ ]; {TA-31} fecha inteiro, e só depois de as cláusulas que faltavam entrarem no "Passa quando"; {TA-06} sobe, com o placar impresso pelo arnês no dia e nunca presumido; {TA-10} continua 0 de 6, porque a entidade não é sensível. O título do card não é editado e o H1 do card não é editado.

RF-TREI-009.

Aceite (H1): Dado uma ficha criada por um profissional, Quando o aluno a duplica, Então nasce uma ficha nova com os mesmos exercícios, autoria do aluno e referência à origem, E a original permanece inalterada, E o aluno consegue editar a cópia.

Nota de escopo (gate {F3-09}, 2026-09-15): o card entrega RF-TREI-009 inteiro, as cinco cláusulas do H1, e nada além: a ação Duplicar individual no detalhe da ficha, ao lado de Pedir ajuste, a rota própria de duplicação com corpo vazio e o identificador da origem no caminho, a cópia nascendo com os mesmos exercícios na mesma ordem, autoria de quem duplicou e referência à ficha de origem, a exibição dessa referência no detalhe da cópia, e a cópia editável pelo novo autor pela rota de edição que {F3-03} já entregou. A cópia mantém o titular e muda só o autor: "para si", em RF-TREI-003, é sobre autoria e nunca sobre titularidade, o profissional não tem perfil de aluno para ser titular de ficha nenhuma, e o aluno que duplica já é o titular; trocar o titular criaria um caminho de mover ficha entre alunos que requisito nenhum pede. Título e descrição da cópia são idênticos aos da origem, sem sufixo e sem prefixo, porque quem distingue as duas na lista é o rótulo de autoria que já existe e a referência à origem no detalhe. A cópia nasce ativa e por isso conta em fichas_ativas, de modo que o aluno no teto do plano recebe a recusa de limite traduzida pelo mesmo tradutor único, sem segunda contagem e sem mensagem nova, e a ordem é sempre acesso antes de limite, com o aluno de acesso inativo recebendo a recusa de acesso e nunca a de limite. Uma ficha de origem inativa pode ser duplicada, porque RF-TREI-009 não condiciona ao estado e retomar uma ficha antiga é exatamente o caso de uso. A duplicação pré-checa o catálogo inteiro antes de escrever, no molde da edição, e a origem com exercício desativado desde então recusa nomeando a ordem, nunca com erro de banco. A referência à origem só aparece quando o leitor ainda pode ler a origem, e quem decide isso é a política de leitura pela junção e não um condicional na tela: origem fora de alcance simplesmente não é desenhada, sem rótulo de indisponível. O Administrador não duplica, e isso é medido e não escolhido: RF-TREI-009 nomeia Aluno e Profissional e não o nomeia, RN-009 lhe dá a edição e nunca a criação, e duplicar cria; a Matriz Ator por Capacidade do DRS ganhou nesta data a linha de duplicar, com ele em N, terceira quebra do padrão dele, com o motivo escrito. A dívida do comportamento ao excluir a origem, deixada por declarar na migração que criou a coluna de referência e nominada a este card, fecha aqui: a referência é anulada quando a ficha de origem é excluída em definitivo. As alternativas de recusa fariam a primeira cópia criada em produção revogar na prática o direito de exclusão em definitivo que RF-CORE-008 dá ao Administrador sobre a origem, e a alternativa em cascata apagaria fichas de outro autor e outro titular, contradizendo de frente a consequência escrita de ADR-006; anular perde a referência e nunca a cópia, e o momento da duplicação continua respondível pela trilha imutável de RF-CORE-009. A seleção em massa NÃO é deste card: a faixa com "Selecionar todas", contador e as ações Desativar e Duplicar em lote é RF-PAIN-010, tem caso {TA-81} e card dono {F7-16}, e as três Notas do desenho aprovado que a atribuíam a este card foram corrigidas nesta data. O que mais não entra, com dono nominal: duplicar plano alimentar é da Fase 4 ({F4-03}); notificar alguém de que uma ficha foi duplicada é {F6-05}, e requisito nenhum o pede hoje; listar as cópias pelo lado da origem não está em artefato nenhum e seria card novo; renomear no ato da duplicação, escolher outro titular, duplicar a própria ficha e duplicar pelo Administrador não existem; copiar sessões, histórico, execuções ou solicitações junto da ficha não acontece, porque o H1 cobra os mesmos exercícios e nada mais; geração assistida é Fase 8 ({F8-05} e {F8-12}); atalho de retomar, retomada e abandono são RF-TREI-010 e {F3-10}. Em todas, ausência é ausência: sem botão desabilitado, sem rótulo "em breve", sem banner. Nenhuma entidade e nenhuma rota nascem. Aritmética de placares, que só se movem no fechamento e medidos no dia: {ART-ENT-04} não muda, {ART-SCR-01} não muda, {ART-SCR-02} continua 1 de 4, {ART-FORM-01} não muda porque a cópia reusa os mesmos sete campos por item, {ART-CFG-01} continua com vinte e oito parâmetros, {ART-SM-03} continua [ ] porque duplicar não é transição de estado, {TA-06} não sobe porque nenhuma entidade nova nasce, {TA-10} continua 0 de 6; {TA-26} e {TA-32} fecham inteiros neste card, e {TB-05} continua [ ] por ser beta com aluno real. Placar que não muda também se declara, senão o leitor supõe que ninguém olhou. O título do card não é editado e o H1 do card não é editado.

RF-TREI-010 e E.3.

O que implementar: atalho de retomar no painel e na lista de treinos enquanto houver sessão em andamento, retomada carregando do banco e não da memória da tela, e passagem automática a abandonada pelo prazo configurado.

Nota de fronteira (gate {F3-05}, Drift 6, 2026-09-14): a persistência da sessão e das séries no banco a cada registro saiu deste card e é servida por {F3-05}, por construção: {ART-ENT-04} atribui a série gravada a cada registro ao desenho da tabela, que nasce lá, e o H1 de RF-TREI-005 cobra duração e volume vindos do banco, conforme RN-004. Se a obrigação ficasse aqui, {F3-05} guardaria as séries na memória da tela e {F3-10} reescreveria o caminho de escrita inteiro: dois desenhos incompatíveis para a mesma coluna. Nenhum requisito é editado, RF-TREI-010 continua inteiro, e o que se corrige é a divisão de trabalho escrita neste card. Este card fica com o que é dele: o atalho, a retomada lendo do banco e o abandono pelo prazo configurado.

Nota de escopo (gate {F3-10}, Drifts 5 e 7, 2026-09-29): o que nasce neste card é o atalho nas duas telas, a regra de prazo e a correção do gatilho; a retomada pelo banco, entregue por {F3-05}, é LIGADA e provada aqui, não reconstruída. "Último registro" inclui a navegação sem série: herdado de {F3-05} (D-4, item 5) e mantido, porque mudar seria desfazer decisão de outro card.

Como verificar (teste primeiro): registrar duas séries, fechar o navegador, entrar em outro dispositivo e conferir o atalho nas duas telas e as séries carregadas; adiantar o relógio além do prazo e conferir que a sessão vira abandonada e some do atalho.

Aceite (H1): Dado um aluno que iniciou uma sessão e registrou duas séries, Quando fecha o navegador e volta em outro dispositivo, Então painel e lista de treinos exibem o atalho de retomar, E ao retomar as duas séries aparecem com o cronômetro seguindo do início original, E ao concluir o volume considera as séries anteriores mais as novas, E a mesma sessão sem registro além do prazo configurado passa a abandonada, some do atalho nas duas telas e não conta para sequência, calendário, conquistas nem progressão.

RF-DIET-001.

Nota (gate {AUD-07}, 2026-09-29): a lista nasce como linhas de mfit.lista_fechada_item (valor no CHECK de lista), nunca enum nem constante ({AUD-07}).

Aceite (H1): Dado um aluno na tela de refeições, Quando registra uma refeição com dois alimentos de cem e duzentas calorias, Então a refeição exibe trezentas calorias, E o mesmo vale para proteína, carboidrato e gordura, cada um igual à soma dos itens.

Nota (F1-10): entidade removível de RF-CORE-008. Ao criar a tabela, aplicar a seção de remoção do gabarito (GABARITO-ACESSO-ALUNO.md): coluna desativado_em/desativado_por (R-2 do gate {F1-10}), a política FOR DELETE exigindo o papel administrador e o gatilho de remoção, e rodar o verificador de verificarPoliticas.ts antes do gate do qa.

Fechamento [2026-09-30]: entregue e em produção (merge 5e36145, migração 0043_refeicao.sql, https://fit.modulareasy.com, /api/estado na versão servida 5e36145 (= merge), gates plan (APPROVED com trava de drift, Drifts 1 a 5 republicados antes do código), qa (PASS COM RESSALVAS na rodada 1, PASS na rodada 2) e review (APPROVED na rodada 3) verdes). Telas /nutricao (mínima: navegador de data, refeições do dia com os quatro totais de cada uma, Registrar refeição, Desativar e o vazio do dia) e /nutricao/refeicoes/nova (estado de /nutricao, não tela nova). Duas tabelas, refeicao e refeicao_alimento; lista fechada tipo_refeicao com 8 itens (60 itens no total da tabela); duas linhas novas em mfit.parametro (44 no total). H1 provado em produção: 100 e 200 kcal dão 300 e as três somas de macronutriente, no POST e no GET do dia, e três itens com decimais somam exato. Fronteira de dado clínico: 1 de 13 entidades servidas. refeicao é a primeira: leitura e escrita negadas ao Administrador com 403 nomeado (dado criado antes, par positivo do titular no mesmo alvo devolvendo 200); no banco o Administrador lê 0 das 4 refeições existentes e o INSERT falha com 42501, e o Super Administrador lê com uma linha em acesso_administrativo por refeição. Placar de parâmetros: 52 pendentes de 98, C 51, universo 149 (decisão do Fiscal: a C a mais é o espelho web do teto de numeric(7,1), limite do tipo de coluna). Perda declarada: o Administrador perde o alcance a refeição, que nunca existiu, por decisão de RF-CORE-007; mfit.pode_ler_aluno de três argumentos passa a delegar com resultado idêntico; nada muda para aluno, profissional e Super Administrador no que já existia. Ressalvas do qa, as quatro fechadas na rodada 2: aviso geral do formulário que sobrava depois da correção, erro nomeado por campo, quantidade na lista do dia e vírgula sobrando em /admin/listas. Lacuna nominal: a comparação de pg_policies antes e depois só a sanidade efêmera do gate cobre, e não foi repetida em produção. Os quatro cartões contra a meta e o total do dia continuam sendo de {F4-04}.

RF-DIET-002.

Aceite (H1): Dado um aluno com meta de duas mil calorias, Quando o nutricionista vinculado altera para duas mil e quatrocentas, Então a tela diária passa a comparar o consumo com o valor novo, E a alteração fica na auditoria com o autor.

Nota (gate {F4-02}, Drift 2, 2026-09-29): o aceite medido é o H1 de RF-DIET-002 no DRS, com dois Nutricionistas e três vigências (2000, depois 2400, depois 2200), duas entradas de auditoria, cada uma com o autor correspondente, e o histórico preservando as três vigências sem apagar nenhuma; o H1 abreviado deste cartão (um Nutricionista, sem a cláusula do histórico) não é o critério, igual à decisão de {TA-34}. Título e H1 do cartão não se editam.

Fechamento [2026-09-30]: entregue e em produção (merge b569460, migração 0044, https://fit.modulareasy.com, /api/estado na versão servida b569460 (= merge), gates plan (APPROVED com trava de drift), qa (PASS COM RESSALVAS, reconferido na rodada 2) e review (APPROVED na rodada 2) verdes). Bloco "Metas do dia" em /nutricao nas duas pontas, formulário "Meta nutricional" (Editar metas) para o aluno titular e para o Nutricionista de vínculo ativo, e leitura do dia pelo Profissional vinculado em /nutricao?aluno=<id> (sem Registrar refeição e sem Desativar). Tabela meta_nutricional só de acréscimo (UPDATE e DELETE pela aplicação negados com 42501 no banco e 404 nas rotas PUT, PATCH e DELETE); mfit.meta_vigente(aluno, data) é o ponto único da meta do dia e mfit.tem_vinculo_ativo_na_especialidade é a primeira capacidade da Matriz aplicada por especialidade no banco. H1 do DRS provado em produção: dois Nutricionistas de vínculo ativo, 2000 (padrão), depois 2400, depois 2200; auditoria com exatamente 2 entradas, cada uma com o autor correspondente, e a vigência padrão sem entrada; histórico com as 3 vigências, sem apagar nenhuma; a meta de hoje não altera a de dias anteriores (ontem e 30 dias atrás seguem em 2000). Fronteira de dado clínico: 2 de 13 entidades servidas (meta_nutricional é a segunda e a primeira com autor): Administrador com 403 nomeado e 0 linhas no banco (INSERT negado com 42501), com o par positivo do titular no mesmo alvo. Personal, Médico e Fisio vinculados leem e não editam (GET 200, POST 403); Nutricionista sem vínculo ativo ou ex-vinculado: GET 404, POST 403. Placar de parâmetros: 52 de 98, C 53, universo 151 (ratificado pelo Fiscal; a C a mais é o espelho web da folga de fuso); metas_padrao ganha o primeiro consumidor. Perda declarada: Personal, Médico e Fisio leem e não editam meta; o Administrador nunca alcançou meta; o aluno existente guarda a vigência padrão que recebeu; Médico e Nutricionista continuam criando ficha de treino até {AUD-09}. Ressalvas do qa: R1 (cartão "Sem permissão para ver estes dados" no lugar de duas linhas soltas), R3 (botão "Histórico de metas" com 2,75rem de altura) e R4 (horário em vigências do mesmo dia) corrigidas e reconferidas; R2 confirmada pelo Fiscal como comportamento da lei (meta_nutricional é não sensível e sem categoria de consentimento em RF-CORE-010, então o servidor nega por vínculo e por papel, não por consentimento); na reconferência o Administrador é redirecionado a /admin em vez de ver o cartão, por desenho, e a API segue com 403 nomeado. Não entra aqui: a comparação do painel com a meta (consumido, restante e percentual) é de {F4-04}.

RF-DIET-003.

Nota (Inspeção, {AUD-11}, 2026-09-30): plano_alimentar e plano_refeicao nascem sob a categoria nutrição de RF-CORE-010: sensivel: true e categoriaConsentimento: 'nutricao' no registro de entidades, mfit.tem_consentimento(aluno_id, 'nutricao') no WITH CHECK de escrita e mfit.consentimento_visivel(aluno_id, 'nutricao') na leitura, pela quinta seção do gabarito, e o plano criado para aluno sem o consentimento é recusado com a tela de consentimento. Este card vem depois de {AUD-11} e de {AUD-10} na fila.

Nota (F1-16): ao criar a tabela da dimensão, o ramo novo entra no CASE de mfit.consumo_do_aluno (não mais em dentro_do_limite_do_aluno, que desde {F1-16} só decide); sem o ramo a função continua levantando exceção, de propósito, e a política nova nasce quebrando, nunca liberada em silêncio; e a tela /plano passa a exibir aquela dimensão sozinha, sem uma linha de código de front, não escrever uma segunda contagem para a tela.

Aceite (H1): Dado um nutricionista com vínculo ativo, Quando cria um plano com quatro refeições estruturadas, Então o plano aparece na tela do aluno na ordem de horário, E a edição por quem não é o autor é negada.

Nota (F1-10): entidade removível de RF-CORE-008. plano_alimentar já tem status; ao aplicar a seção de remoção do gabarito (GABARITO-ACESSO-ALUNO.md), este card declara se inativo passa a usar o status existente ou se a tabela ganha desativado_em/desativado_por como as demais (R-2 do gate {F1-10}), além da política FOR DELETE exigindo o papel administrador e do gatilho de remoção, com o verificador de verificarPoliticas.ts rodando antes do gate do qa.

Nota (F1-15): a dimensão planos_alimentares_ativos é servida por esta tabela; ao criar a tabela, aplicar a seção "Limite de plano por dimensão" do gabarito e acrescentar o ramo 'planos_alimentares_ativos' ao CASE de mfit.dentro_do_limite_do_aluno, sem o ramo a função levanta exceção, de propósito, e a política nova nasce quebrando, nunca liberada em silêncio.

Nota de correção (gate {F4-03}, Drift 5, 2026-09-30): duplicar plano alimentar e pedir ajuste de plano NÃO nascem neste card, em forma nenhuma. Nenhum RF dá essas duas ações ao plano: RF-TREI-009 e RF-TREI-004 são de ficha, RN-009 diz "duplicar quando o tipo permitir" e nenhum requisito o permite para plano, e o H1 de RF-DIET-003 não as pede. O mockup desenha Duplicar e Pedir ajuste no detalhe do plano (tela 12b) e os dois botões não se constroem; "Gerar dieta com IA" e "Gerar com IA" são de {F8-06}. A Nota de {F3-09} que atribuía "duplicar plano alimentar" a este card está corrigida. Se o dono quiser as ações, é RF novo mais card.

Nota de correção (gate {F4-03}, Drift 7, 2026-09-30): a Nota (F1-15) acima está desatualizada quanto ao destino do ramo: desde {F1-16} o ramo 'planos_alimentares_ativos' mora em mfit.consumo_do_aluno (e mfit.dentro_do_limite_do_aluno só decide), como diz a Nota (F1-16). Vale a Nota (F1-16); da Nota (F1-15) permanece a aplicação da seção de limite de plano por dimensão do gabarito. Título e H1 do card não mudam.

Nota (Inspeção, 2026-09-30): Releitura obrigatória contra main com {AUD-11} mergeado antes de codar: o consentimento de nutrição (sétima categoria) passa a governar o plano alimentar.

Nota (gate {AUD-11}, drift 8, 2026-09-30): a releitura em uma passada, antes de codar, corrige quatro pontos deste card. (1) A migração passa a ser 0048, porque {AUD-11} usa 0046 e 0047. (2) A decisão aberta sobre nutrição como categoria de consentimento está decidida em {AUD-11}: as conjunções do gabarito (mfit.tem_consentimento(aluno_id, 'nutricao') no WITH CHECK, mfit.consentimento_visivel(aluno_id, 'nutricao') na leitura) entram na própria 0048. (3) plano_alimentar declara o seu leitorUnico no registro de entidades (hoje provisoriamente acesso/leituraSensivel.ts), conforme a Nota de {ART-AUD-02}, e o leitor de módulo chama registrarSeAdministrativo. (4) A inserção de plano_alimentar exige também mfit.consentimento_visivel(aluno_id, 'nutricao'), porque a restrição por especialidade governa a escrita (drift 7 de {AUD-11}): o profissional fora da restrição não grava.

Nota (Inspeção, gate {AUD-10}, drift 8, 2026-09-30): a migração 0048 é de {AUD-10} (0048_modelos_de_email.sql), e não deste card: onde a Nota do gate de {AUD-11} acima diz que a migração passa a ser a 0048, leia a primeira migração livre depois de {AUD-12}, que numera a 0049 (ou a 0049 e a 0050 se precisar de ADD VALUE). O gate de {F4-03} é relido em uma passada antes de codar.

Nota (Inspeção, gate {AUD-12}, drift 4, 2026-09-30): a migração deste card passa a ser a 0052 ({AUD-12} ocupa a 0050 e a 0051); as Notas anteriores que citam a 0048 e a 0049 ficam superadas.

Nota de correção (Inspeção, gate {F4-03}, Drift 10, 2026-09-30): a Nota de {AUD-11} acima, que diz que plano_alimentar e plano_refeicao nascem com sensivel: true no registro de entidades, fica corrigida: plano_refeicao herda o consentimento do plano pai (como refeicao_alimento herda de refeicao) e fica fora do registro de entidades sensíveis; a entidade sensível é plano_alimentar. A contagem de entidades sensíveis continua 10.

Fechamento [2026-09-30]: entregue e em produção (merge 2f5c560, repositório wladimirdjr/modularfit, migração 0052, https://fit.modulareasy.com, /api/estado na versão 2f5c560; o qa provou em produção nas versões 0cf4faa e 5fbaf4b; gates plan (APPROVED COM TRAVA DE DRIFT, releitura contra 4e5ed26 aprovada para codar), db (PASS), qa (PASS COM RESSALVAS, reconferência na rodada 2 PASS) e review (APPROVED na rodada 2) verdes). Tela /nutricao/planos para o aluno e para o Profissional vinculado, com os estados /nutricao/planos/:id, /nutricao/planos/novo e /nutricao/planos/:id/editar; botão Planos alimentares em /nutricao. H1 provado em produção: o Nutricionista de vínculo ativo cria quatro refeições fora de ordem (20:00, 12:30, 06:30, 16:00) e o aluno as vê na ordem 06:30, 12:30, 16:00, 20:00; as calorias saem somadas pelo banco, iguais à soma independente (1148; 1030,5 pela interface, com vírgula); a edição por aluno, Personal e outro Nutricionista é negada com 403 nomeado e título intacto, e o autor edita com atualizado_por gravado. Desativar com confirmação nominal, 409 ao repetir, reativar; aluno sem Nutricionista cria o próprio plano (201), com Nutricionista ativo recebe 403 nomeado e a tela não oferece Criar plano; limite do plano Gratuito aplicado (segundo ativo 409 nomeando o plano que amplia, /plano mostra 1 de 1). Consentimento de nutrição ({AUD-11}): sem consentimento o aluno não cria, não edita nem desativa (403 consentimento_necessario) e continua lendo, e o Nutricionista vinculado sem consentimento recebe 403 categoria_nao_compartilhada. Fronteira de dado clínico: 3 de 13 entidades servidas; Administrador com 403 nomeado nas seis rotas, 0 linhas lidas de 7 no banco e escrita recusada, com os pares positivos no mesmo alvo. Placares: consentimento por entidade 3 de 10, leitor único 3 de 10, capacidade por especialidade 12 de 12, verifica-parametros inalterado (51 de 98, C 54, universo 152, 33 parâmetros, 7 listas). Exceção FILHAS_COM_EXCLUSAO_NA_EDICAO ratificada pelo Fiscal: o DELETE de plano_refeicao na edição não é a remoção de entidade de RF-CORE-008 (precedente de ficha_item), com a condição cumprida: a trilha grava refeicao_removida com o conteúdo anterior (nome, notas, horário e alimentos), autor e momento, na mesma transação do DELETE, e o qa provou o caso em produção na reconferência (5fbaf4b: Jantar removido, uma linha de trilha, Café e Almoço mantidos). Perda declarada: o aluno com Nutricionista de vínculo ativo não cria plano próprio (o plano que criou antes continua dele); a linha Planos alimentares de /plano deixa de ser não medida; Administrador nunca alcançou plano; o Super Administrador edita plano de terceiro pela API, sem tela; o texto do 403 consentimento_necessario passa a citar o plano alimentar; a ordem das refeições não é renumerada no PATCH. Ressalvas do qa: P1-1 (a trilha sem o valor anterior) e P2-2 (tipografia do nome da refeição) corrigidas e reconferidas; P2-1 segue, porque o autor fora da restrição do aluno recebe 404 e não 403 nomeado em editar e desativar (escrita barrada, plano intacto); P2-3 é de fora do card; lacuna declarada: a tela /admin/auditoria do Super Administrador não foi percorrida e o ramo "Super edita plano" foi lido no código, não exercitado. Não entra aqui: duplicar plano e pedir ajuste (sem requisito), notificação ao aluno ({F6-05}), geração com IA ({F8-06}), acompanhamento por período ({F4-05}) e cartões de consumo contra a meta ({F4-04}).

Nota (Inspeção, {AUD-11}, 2026-09-30): a leitura do profissional vinculado passa por mfit.consentimento_visivel(aluno_id, 'nutricao'): sem o consentimento de nutrição do aluno, ou com a categoria restrita a outra especialidade, o painel e o acompanhamento lhe são negados, e o titular continua lendo.

RF-DIET-004.

Aceite (H1): Dado um aluno com meta de duas mil calorias e mil e duzentas registradas, Quando abre o painel diário, Então vê mil e duzentas consumidas, oitocentas restantes e sessenta por cento, E num dia sem registro os quatro totais aparecem em zero, sem erro.

Nota (gate {F4-01}, Drift 3, 2026-09-29): completa a tela que {F4-01} abre. {F4-01} entrega /nutricao em versão mínima (navegador de data, lista das refeições do dia com os quatro totais de cada uma, Registrar refeição, Desativar e o vazio do dia); este card acrescenta os quatro cartões contra a meta e o total do dia.

Nota (gate {F4-02}, Drift 4, 2026-09-29): consome mfit.meta_vigente(aluno, data), o ponto único que {F4-02} cria para a meta do dia, e nunca reescreve a regra; fecha a cláusula de comparação de {TA-34} (consumido, restante e percentual contra a meta do dia). {F4-02} entrega só o bloco "Metas do dia" (os quatro valores da meta, o autor e o histórico) nas duas pontas; os quatro cartões contra a meta seguem sendo deste card.

Fechamento [2026-09-30]: entregue e em produção (merge a6624e9, repositório wladimirdjr/modularfit, migração 0053, https://fit.modulareasy.com; o qa provou em produção nas versões 86449c2 e 3f98363, e 3f98363 é o código do merge; gates plan (APPROVED COM TRAVA DE DRIFT), db (PASS), qa (PASS COM RESSALVAS, reconferência em 3f98363 PASS) e review (APPROVED na rodada 3) verdes). Em /nutricao, o bloco "Metas do dia" ganha no topo os quatro cartões contra a meta (calorias, proteína, carboidrato e gordura, cada um com o consumido sobre a meta, o restante e o percentual) e o total do dia (refeições e kcal); depois de Desativar uma refeição o bloco recarrega sem o aluno recarregar a página. Regra única da comparação: mfit.comparacao_com_meta(consumido, meta) (migração 0053, função pura, IMMUTABLE, sem SECURITY DEFINER) devolve o restante com uma casa e o percentual inteiro, meio para cima e sem teto; meta nula, zero ou negativa devolve nulo e a tela diz "Sem meta definida", sem barra (RN-004). A soma do dia é feita pelo banco, só com refeições ativas (totaisDoDia, no leitor único de refeição); dia sem registro dá zero nos quatro. O painel é o campo painel de GET e POST /api/metas, de corpos iguais. Funções do schema de 57 para 58, políticas 77 e parâmetros 33, inalterados. H1 provado em produção ({TA-36}): meta 2000 e 1200 registradas mostram 1.200 consumidas, 800 restantes e 60%; o dia sem registro mostra os quatro totais em zero, "Nenhuma refeição registrada" e "Dia sem registro", sem erro e com o console limpo. Casos medidos: abaixo da meta, 1463,7 de 2200 dá 736,3 restantes e 67%; acima, 2300 de 2000 mostra "300 kcal acima da meta · 115%" com a barra cheia; igual, 230 de 230 dá 0 e 100%; proteína com meta 0 mostra "Sem meta definida"; desativar uma refeição leva 1200 a 700 e 60% a 35% na hora; a navegação por data usa a meta daquele dia. Quarta cláusula de {TA-34} provada: com um Nutricionista trocando a meta para 2400 e depois outro para 2200, o painel compara sempre com a mais recente, e {TA-34} fecha 4 de 4. Acesso: o painel herda a leitura de GET /api/metas: o titular, o Profissional de vínculo ativo com a categoria de nutrição visível (sem Registrar nem Desativar) e o Super Administrador, que grava uma linha de acesso administrativo por refeição somada; sem a categoria visível o profissional recebe 403 categoria_nao_compartilhada e o Administrador, 403 nomeado. Verificador da fronteira endurecido (D-8): a chamada positiva passou a ser obrigatória em exclusaoNaEdicaoValida e nos critérios de Super Administrador e de administração; NOT e = false reprovam, e a forma viva da migração 0032 (grupo OR dentro de AND) continua aprovada, com os decoys e os controles das políticas reais nos testes. PATCH concorrente de plano (D-9): o segundo recebe 409 conflito_de_edicao em vez de 403, provado 6 de 6 em produção, e a negação legítima segue 403. Placares medidos: fronteira de dado clínico 3 de 13, consentimento por entidade 3 de 10, leitor único 3 de 10, capacidade por especialidade 12 de 12, verifica-parametros inalterado em 51 de 98, C 54, universo 152, 33 parâmetros e 7 listas. Perda declarada: a barra do painel deixa o degradê da marca (decisão do qa, por causa do contraste mínimo de 3:1 contra a trilha); Personal, Médico e Fisioterapeuta de vínculo ativo com a categoria visível passam a ver a conta do consumo contra a meta, de dois dados que já liam; o corpo de GET e POST /api/metas cresce com painel; o Super Administrador passa a gravar mais linhas de trilha ao ler o dia; o verificador reprova mais formas; e o segundo PATCH concorrente deixa de receber 403. Ressalvas do qa: P2-1 ("/ meta" quebrando de linha no cartão de calorias), P2-2 (valor ARIA acima do máximo) e P2-3 (contraste da barra no tema claro) corrigidas e reconferidas em 3f98363; lacunas declaradas, o D-9 não foi rodado contra o código anterior e o D-8 não foi exercitado pelo qa (coberto pelo arnês e pelo review). O link "Painel" do topo com área de toque menor que a do padrão vem de {F4-01} e é corrigido em {F4-05}. Não entra aqui: dia com meta atingida e médias por período ({F4-05}), bloco do painel geral ({F7-06}), tolerância e cor de alerta, que não existem.

Nota (Inspeção, {AUD-11}, 2026-09-30): a leitura do profissional vinculado passa por mfit.consentimento_visivel(aluno_id, 'nutricao'): sem o consentimento de nutrição do aluno, ou com a categoria restrita a outra especialidade, o painel e o acompanhamento lhe são negados, e o titular continua lendo.

RF-DIET-005.

Aceite (H1): Dado um nutricionista com vínculo ativo em um aluno com trinta dias de registros, Quando abre o acompanhamento com período de trinta dias, Então vê a média diária de calorias e de cada macronutriente e o número de dias em que a meta foi atingida, E o mesmo acompanhamento para aluno sem vínculo ativo é negado.

Nota (gate {F4-02}, Drift 4, 2026-09-29): a leitura do dia pelo Profissional (/nutricao?aluno=<id>, sem Registrar refeição nem Desativar) e o bloco "Metas do dia" nasceram em {F4-02}; este card é o acompanhamento por período (média diária e dias na meta) e lê a meta de cada dia do mesmo ponto único, mfit.meta_vigente, sem reescrever a regra.

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.

Nota (Inspeção, gate {F4-05}, Drifts 1 e 2, 2026-09-30): a regra do acompanhamento (o que é dia com meta atingida, média só sobre dias com registro, período que termina ontem, janelas de 7 e 30 dias) está publicada como Nota em RF-DIET-005 do DRS, e o parâmetro nutricao_meta_tolerancia_pct (10, faixa 1 a 50) em L.2 e em {ART-CFG-01}. Migração 0054, a entregar neste card, sem marcar entrega: a função mfit.meta_atingida(consumido, meta, tolerância), que consome mfit.comparacao_com_meta ({F4-04}) e decide o dia, e o parâmetro novo em mfit.parametro, que passa de 33 para 34 linhas. O código que lê o parâmetro entra no mesmo deploy da migração, porque a trava de cardinalidade da carga faz o processo antigo recusar subir com 34 linhas. Drifts 3 a 6 estão como Notas em RF-DIET-005, no Apêndice de telas do DRS, em {F5-07} e em {ART-DASH-03}.

Fechamento [2026-10-01]: entregue e em produção (merge f609a9c, repositório wladimirdjr/modularfit, migrações 0054 e 0055, https://fit.modulareasy.com; o qa provou em produção em de85d1c e reconferiu em 1b0002c; gates plan (APPROVED), db (PASS), qa (PASS COM RESSALVAS na rodada 1, PASS na reconferência) e review (CHANGES_REQUESTED só de texto do CHANGELOG, corrigido em 60cbdce) verdes). A tela /nutricao/acompanhamento?aluno= (estado de /nutricao, com o botão "Acompanhamento" no cabeçalho do Profissional) e a rota GET /api/acompanhamento-nutricional entregam o acompanhamento por período de 7 ou 30 dias: média diária de calorias e de cada macronutriente, dias com registro, dias na meta e dias sem meta, e a lista dos dias. Regra única, no banco: mfit.meta_atingida(consumido, meta, tolerância) (migração 0054, função pura, IMMUTABLE, sem SECURITY DEFINER) decide o dia sobre mfit.comparacao_com_meta; a meta é a vigente DO DIA (nunca a de hoje), a média é só sobre dias com registro, o dia sem registro nunca conta na meta, refeição desativada fica fora e o período termina ontem na tela. Tolerância editável: o parâmetro nutricao_meta_tolerancia_pct (10, faixa 1 a 50) é a trigésima quarta linha de mfit.parametro e vale na próxima leitura, sem reiniciar. H1 provado em produção ({TA-37}): aluno com 30 dias de registros, 28 com registro e 19 na meta, médias 2197,8 de calorias, 137,4, 274,7 e 73,3 de macronutrientes, iguais à soma independente; o aluno sem vínculo recebe 404, e o vinculado sem consentimento de nutrição recebe 403 categoria_nao_compartilhada. Bordas da tolerância com meta 2000: 1789 fora, 1790 dentro, 2209 dentro, 2210 fora; tolerância trocada para 5 dá 11 dias e para 25 dá 28, 0 e 51 recusados com 400, e o valor 10 foi restaurado e conferido. Decisão única de leitura de nutrição (D-4): as três rotas antigas (/api/refeicoes, /api/metas, /api/planos-alimentares) e a nova passam a decidir a leitura num lugar só, e as três antigas mantêm status, erro e campo idênticos ao pai (a6624e9) em 210 de 210 combinações. LinkDoTopo: os links do topo de dezesseis telas viram um componente único com área de toque de 2,75rem em 375 de largura, destino e texto iguais, e .mf-plano-voltar deixa de existir. Placares medidos: funções do schema de 58 para 59, políticas 77 (inalterado), parâmetros de 33 para 34, última migração 0055 (só de COMMENT, porque os textos de mfit.parametro e da política de alteração ainda diziam 33), verifica-parametros 51 de 98, C 56, universo 154, 7 listas; fronteira de dado clínico 3 de 13, consentimento por entidade 3 de 10, leitor único 3 de 10 e capacidade por especialidade 12 de 12, inalterados. Perda declarada: o Super Administrador, ao ler o acompanhamento, grava uma linha acesso_administrativo por refeição do período e por vigência lida (28 refeições mais 2 vigências no caso provado), trilha maior por desenho; Personal, Médico e Fisioterapeuta com a categoria de nutrição visível passam a ver médias e dias na meta, conta sobre dados que já liam; o Aluno não ganha tela de acompanhamento (a API o serve, a tela redireciona para /painel); a linha do topo de dezesseis telas fica um pouco mais alta; o processo antigo não sobe contra a tabela de 34 parâmetros. Ressalvas do qa: P2-1 (cartão de 404 com título e texto que se contradiziam) e P2-2 (etiqueta de situação quebrando de linha a 400 de largura) corrigidas e reconferidas em 1b0002c (48 de 48 combinações de tela, tema e largura); P2-3 (trilha do Super por refeição) previsto e declarado. Lacuna declarada: o cenário de dias sem meta vigente (dias_sem_meta maior que zero) não foi exercitado pelo qa, porque a vigência padrão cobre todo dia anterior; está coberto pelo arnês do executor. Fecha a Fase 4: {F4-01} a {F4-05} entregues. Não entra aqui: o bloco de peso e composição ({F5-07}), o painel do Nutricionista e a aderência média ({F7-08}), e o P2-1 do {F4-03}, fechado sem card por decisão do Fiscal (o 404 fica, porque um 403 nomeado revelaria a existência do plano a quem a restrição do aluno exclui).

RF-SAUD-001 e ADR-007.

O que implementar: esquema único com tronco comum e seções por especialidade; um registro por ocasião de coleta, com data, autor e especialidade do autor; lista das anamneses do aluno em ordem decrescente de data; pré-preenchimento editável do tronco a partir da anamnese anterior.

Como verificar (teste primeiro): registrar uma anamnese, registrar outra meses depois por outra especialidade alterando campos do tronco, e conferir no banco que existem dois registros e que o primeiro manteve os valores originais.

Aceite (H1): Dado um aluno com uma anamnese registrada por um Personal Trainer, Quando um Médico vinculado preenche uma anamnese nova, Então o formulário abre com o tronco pré-preenchido pela anterior e com as seções médicas, E ao salvar existem exatamente duas anamneses, cada uma com a própria data, autor e especialidade, E a anterior permanece intacta inclusive nos campos alterados na nova, E a lista exibe as duas em ordem decrescente de data.

Nota (F1-09): entidade sensível de RN-001. A leitura desta entidade é servida pelo leitor único de registro sensível (server/src/acesso/leituraSensivel.ts), nunca por consulta própria da rota; rodar ops/verifica-leitura-sensivel.mjs antes do gate do qa, conforme a seção do gabarito em GABARITO-ACESSO-ALUNO.md.

Nota (F1-10): entidade removível de RF-CORE-008. Ao criar a tabela, aplicar a seção de remoção do gabarito (GABARITO-ACESSO-ALUNO.md): coluna desativado_em/desativado_por (R-2 do gate {F1-10}), a política FOR DELETE exigindo o papel administrador e o gatilho de remoção, e rodar o verificador de verificarPoliticas.ts antes do gate do qa.

Nota (F1-12): entidade sensível de consentimento (RN-001). Ao criar a tabela, aplicar a quinta seção do gabarito (GABARITO-ACESSO-ALUNO.md, "Consentimento por categoria"): marcar categoriaConsentimento: 'anamnese' na entrada dela em ENTIDADES_E1; a política de leitura em conjunção com mfit.consentimento_visivel(aluno_id, 'anamnese'), além de mfit.pode_ler_aluno; o WITH CHECK de INSERT e de UPDATE em conjunção com mfit.tem_consentimento(aluno_id, 'anamnese'); o gatilho AFTER INSERT chamando mfit.auditar_criacao('aluno_id'); e rodar o verificador de {F1-12} antes do gate do qa, subindo o placar N de 6 no Plano de Testes (TA-10).

Nota [F1-18]: a tela nasce com <AvisoNaoClinico ponto="telas_clinicas" /> no topo, consumindo o texto vigente da tabela; não escreva o parágrafo no componente. O décimo terceiro verificador (ops/verifica-aviso-nao-clinico.mjs) reprova se esta tela existir sem ele, e o placar de RF-CORE-012 sobe de 2 para 3 e para 4 conforme elas nascerem.

Nota (Inspeção, gate {F5-01}, Drifts 1 a 5, 7 e 9, 2026-10-01): publicados antes do código. (1) A ficha dos 46 campos, com tipo, obrigatoriedade e teto, está no Apêndice: Catálogo de formulários do DRS e em {ART-FORM-04}: todos opcionais, e o envio exige ao menos um campo (422 anamnese_vazia). (2) Dois tetos de texto editáveis, anamnese_texto_curto_max_caracteres (200, faixa 80 a 500) e anamnese_texto_longo_max_caracteres (2000, faixa 500 a 10000), em L.2 e em {ART-CFG-01}: mfit.parametro passa de 34 para 36 linhas. (3) Quem preenche o quê, Nota em RF-SAUD-001: o profissional, o tronco e somente a seção da própria especialidade, com vínculo ativo nela; o aluno, o tronco e as seções das especialidades sem vínculo ativo. (4) A anamnese não se edita: correção é nova coleta, e o autor e o Super Administrador só desativam (Notas em RF-SAUD-001 e em RN-009); o banco concede atualização somente em desativado_em e desativado_por. (5) A ficha de anamnese em {ART-ENT-06} está corrigida: data é o momento da coleta (padrão do banco), criado_em sai, entram desativado_em e desativado_por, índice (aluno_id, data decrescente). (7) A tela é a casca de /saude, que serve as quatro telas clínicas. (9) Correção da Nota F1-09 acima: o leitor único de registro sensível (leituraSensivel.ts) lê um registro por id e emite o endereço, mas não lista nem escreve, e esta entidade precisa listar, gravar e desativar; no molde de {AUD-11} (nutrição), o leitor único da anamnese é o módulo anamnese/anamnese.ts, que lê, lista, grava e desativa e chama o registro de leitura administrativa de leituraSensivel.ts em toda leitura, nunca uma cópia. Ficam fora deste card: edição de conteúdo, explicação ({F5-10}), avaliação, exame, prescrição, reabilitação, anexo, pré-preenchimento pelo perfil, 360 do aluno, exportação e /admin/emails. Migração 0056, a entregar neste card, sem marcar entrega: a tabela mfit.anamnese, as quatro políticas e os dois parâmetros; tabelas de 31 para 32, políticas de 77 para 81, funções inalteradas em 59, parâmetros de 34 para 36, listas inalteradas em 7. O código que lê os dois parâmetros entra no mesmo deploy da migração, porque a trava de cardinalidade da carga faz o processo antigo recusar subir com 36 linhas.

Fechamento [2026-10-01]: entregue e em produção (merge 9cb16f3, repositório wladimirdjr/modularfit, migração 0056, https://fit.modulareasy.com (/api/estado na versão 9cb16f3); o qa provou em produção na versão 5b42dd0, e as correções dos achados P2-1 e P2-4 entraram em 25b0cc6, com testes 9 de 9 no efêmero e deploy em produção; gates plan (APPROVED com trava de drift, drifts publicados antes do código), db (PASS), qa (PASS COM RESSALVAS, limpeza de produção concluída depois) e review (APPROVED, 0 Critical, 0 Important, 6 Minor) verdes). Entregue: a tabela mfit.anamnese com quatro políticas (anamnese_leitura, anamnese_insercao, anamnese_atualizacao, anamnese_exclusao) e quatro gatilhos, sem função nova; GRANT UPDATE somente em desativado_em e desativado_por, de modo que nenhum campo de conteúdo aceita atualização (nova coleta nunca altera a anterior); as rotas GET /api/anamneses?aluno=, GET /api/anamneses/:id, GET /api/anamneses/base?aluno=, POST /api/anamneses e POST /api/anamneses/:id/desativar; as telas /saude (casca com o aviso não clínico no topo e a aba Anamneses), /saude/anamneses/nova e /saude/anamneses/:id; o contrato único de 46 campos (tronco de 20 mais as quatro seções de 5, 5, 8 e 8) com espelho na web; os dois tetos de texto editáveis (anamnese_texto_curto_max_caracteres 200 e anamnese_texto_longo_max_caracteres 2000), de modo que mfit.parametro vai de 34 para 36 linhas; o link "Saúde" em /alunos e no painel do aluno; e o ponto único de decisão de leitura e de tradução da negação generalizado por categoria (nutrição passou a chamá-lo com os mesmos textos). H1 provado em produção ({TA-38}): a matriz de quatro profissionais por quatro seções dá 12 negativos (403 secao_fora_da_permissao, contagem de linhas inalterada) e 4 positivos (201); o aluno sem vínculo grava o tronco e as quatro seções, com Personal, Médico e Nutricionista ativos grava só a seção funcional e leva 403 nas três outras; especialidade_autor, autor e data vêm da sessão e do banco (corpo com qualquer um deles dá 400 campo_desconhecido); o detalhe de uma anamnese fica byte a byte igual depois de três novas coletas, e o tronco-base passa a ser o da próxima ativa quando a mais recente é desativada; sem consentimento o aluno recebe 403 consentimento_necessario e o profissional 403 categoria_nao_compartilhada, e o par positivo concede e grava 201; restrita ao Médico, Personal e Nutricionista levam 403; revogada, o titular e o Super leem e ninguém grava; o Administrador recebe 403 nomeado nas cinco rotas, sem alterar o banco; o não vinculado recebe 404; desativar vale para o autor e para o Super, a segunda vez dá 409 e o não autor recebe 403 nomeado; PATCH, PUT, reativar e ativar dão 404; validações de formato e de teto (vazia 422, só brancos 422, caractere NUL 400, dor 11 e -1 400, 200 e 2000 caracteres aceitos, 201 e 2001 recusados). Trilha: criar grava em anamneses, desativar grava 3, alterar e excluir gravam 0, e o Super lendo a lista deixa uma linha acesso_administrativo por anamnese devolvida (6 de 6) e uma no detalhe. Placares medidos: tabelas de 31 para 32, políticas de 77 para 81, funções inalteradas em 59, parâmetros de 34 para 36, listas inalteradas em 7 (db-ops, 107 casos por modo, 107 ok, 0 falhas); verifica-parametros 51 de 98, C 57, universo 155; capacidade por especialidade 14 de 14; leitor único 4 de 10; suíte do servidor 1440 testes, 1360 passam, 0 falham, 80 pulados, e web 283 de 283. Perda declarada: o autor não corrige erro de digitação sem nova coleta (desativa e coleta de novo), porque a anamnese não se edita (ADR-007); o Super Administrador personificando consegue gravar anamnese como o aluno (201, autor igual ao aluno, trilha com o personificador), no mesmo desenho das demais escritas, e a decisão de proibir é do Fiscal (P2-3); o botão Desativar existe só no detalhe do autor e não no cartão da lista, divergência declarada do desenho D-10 (o cartão é um link); data não é travada pela política do banco, só omitida pelo servidor, e travá-la é decisão do Fiscal em migração futura; o processo antigo não sobe contra a tabela de 36 parâmetros; o Super lendo a lista grava uma linha de trilha por anamnese. Ressalvas do qa: P2-1 (grupo "saúde" sem rótulo em /admin/parametros, aparecia "SAUDE") e P2-4 (a limpeza de contas de teste recusava quando o Super desativou uma anamnese) corrigidos em 25b0cc6; P2-2 (JSON malformado devolve 422 anamnese_vazia em vez de 400) fica como está, igual à nutrição; P2-3 vai ao Fiscal. Limpeza: limpar-contas-de-teste.mjs --prefixo qa.f501 --aplicar apagou as 9 contas de teste, aritmética fechada, 0 resíduo em 40 verificações. Lacunas declaradas: contraste medido só a olho, sem ferramenta; a tela não foi comparada pixel a pixel com a tela 14 do mockup; o Super personificando não foi exercitado pela interface (só pela API); 429 e carga não testados; a edição dos dois tetos em /admin/parametros não foi exercitada em produção (os valores ficaram como estão); o review aceitou 6 Minor (entre eles o CASE por papel de SQL_CAPACIDADE como segunda cópia da política, coberto por teste de coerência). Abre a Fase 5. Não entra aqui: o botão Explicar ({F5-10}), edição de conteúdo, avaliação, exame, prescrição e reabilitação ({F5-02} a {F5-06}), anexo, pré-preenchimento pelo perfil, 360 do aluno ({F7}) e exportação ({F8-09}).

RF-SAUD-002.

Nota (gate {AUD-07}, 2026-09-29): a lista nasce como linhas de mfit.lista_fechada_item (valor no CHECK de lista), nunca enum nem constante ({AUD-07}).

O que implementar: as seis seções para as quatro especialidades e para o aluno, incluindo a antropometria pelo Nutricionista, com as quatro dobras cutâneas do protocolo padrão (tríceps, suprailíaca, abdominal e coxa, em milímetros, lista de pontos vinda da configuração), o teste de flexibilidade na seção neuromuscular, o teste de resistência na aeróbica e o histórico de lesões, medicamentos e estilo de vida na anamnese resumida.

Aceite (H1): Dado um aluno com uma avaliação anterior, Quando um profissional vinculado de qualquer uma das quatro especialidades registra uma nova, Então a comparação exibe cada métrica presente nas duas com valor anterior, atual e variação, E métricas presentes em apenas uma aparecem sem variação calculada, E o Nutricionista vinculado registra a avaliação com a antropometria completa, sem recusa por especialidade.

Nota (F1-09): entidade sensível de RN-001. A leitura desta entidade é servida pelo leitor único de registro sensível (server/src/acesso/leituraSensivel.ts), nunca por consulta própria da rota; rodar ops/verifica-leitura-sensivel.mjs antes do gate do qa, conforme a seção do gabarito em GABARITO-ACESSO-ALUNO.md.

Nota (F1-10): entidade removível de RF-CORE-008. Ao criar a tabela, aplicar a seção de remoção do gabarito (GABARITO-ACESSO-ALUNO.md): coluna desativado_em/desativado_por (R-2 do gate {F1-10}), a política FOR DELETE exigindo o papel administrador e o gatilho de remoção, e rodar o verificador de verificarPoliticas.ts antes do gate do qa.

Nota (F1-12): entidade sensível de consentimento (RN-001). Ao criar a tabela, aplicar a quinta seção do gabarito (GABARITO-ACESSO-ALUNO.md, "Consentimento por categoria"): marcar categoriaConsentimento: 'avaliacao_fisica' na entrada dela em ENTIDADES_E1; a política de leitura em conjunção com mfit.consentimento_visivel(aluno_id, 'avaliacao_fisica'), além de mfit.pode_ler_aluno; o WITH CHECK de INSERT e de UPDATE em conjunção com mfit.tem_consentimento(aluno_id, 'avaliacao_fisica'); o gatilho AFTER INSERT chamando mfit.auditar_criacao('aluno_id'); e rodar o verificador de {F1-12} antes do gate do qa, subindo o placar N de 6 no Plano de Testes (TA-10).

Nota (Inspeção, gate {F5-02}, Drifts 1 a 9, 2026-10-01): publicados antes do código. (1) A ficha dos campos da avaliação, com tipo, faixa e teto, está no Apêndice: Catálogo de formulários do DRS e em {ART-FORM-05}: todos opcionais, o envio exige ao menos um campo (422 avaliacao_vazia), e a seção cardiovascular ganha idade_anos, insumo da frequência cardíaca máxima de {F5-03}. (2) Dois tetos de texto editáveis, avaliacao_texto_curto_max_caracteres (200, faixa 80 a 500) e avaliacao_texto_longo_max_caracteres (2000, faixa 500 a 10000), em L.2 e em {ART-CFG-01}: mfit.parametro passa de 36 para 38 linhas. (3) A avaliação não se edita: correção é nova avaliação, e o autor e o Super Administrador só desativam (Notas em RF-SAUD-002 e em RN-009); o banco concede atualização somente em desativado_em e desativado_por. (4) Regra da comparação, Nota em RF-SAUD-002: contra a ativa anterior ou outra ativa escolhida, métrica de teste só com o mesmo teste, ausente nunca vale zero. (5) A ficha de avaliacao_fisica em {ART-ENT-06} e em E.1 está corrigida: sai cálculos derivados; entram especialidade_autor, dobras_pontos, dobras_mm, desativado_em e desativado_por; data é gravada pelo banco e travada na política. (6) A lista ponto_dobra_cutanea nasce neste card, com quatro itens (Tríceps, Suprailíaca, Abdominal e Coxa): as listas fechadas com consumidor passam de sete para oito. (7) A comparação nasce como bloco do detalhe, e a aba Avaliações nasce dentro da casca de /saude; o mockup não tem tela de comparação e traz campos fora da ficha (o DRS vence). (8) Correção da Nota F1-09 acima: o leitor único de registro sensível (leituraSensivel.ts) lê um registro por id, mas não lista nem escreve, e esta entidade precisa listar, gravar e desativar; o leitor único da avaliação é o módulo avaliacao/avaliacao.ts, que lê, lista, grava e desativa e chama o registro de leitura administrativa em toda leitura, no molde da anamnese. (9) Fronteira com os vizinhos: Notas em {F5-03} (cálculos feitos na leitura) e em {F5-07} (a medida corporal não é escrita aqui). Migração deste card: 0057_avaliacao_fisica.sql, a seguinte à 0056 de {F5-01}: a tabela mfit.avaliacao_fisica com quatro políticas e gatilhos, a lista ponto_dobra_cutanea com quatro itens e os dois parâmetros; tabelas do schema de 32 para 33, políticas de 81 para 85, parâmetros de 36 para 38 e listas de 7 para 8, a medir no fechamento e não a projetar. Ficam fora deste card: cálculos derivados ({F5-03}), edição de conteúdo, explicação (RF-SAUD-010 não inclui a avaliação), pré-preenchimento por avaliação anterior, medida corporal e gráfico ({F5-07}), exame, prescrição e reabilitação ({F5-04} a {F5-06}), 360 do aluno e atalho do painel do profissional ({F7}) e exportação ({F8-09}). O cartão continua [ ].

Fechamento [2026-10-06]: entregue e 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); gates plan (APPROVED com trava de drift, drifts publicados antes do código), db (PASS, 0057 e 0058), qa (rodada 1 FAIL por um P1, reteste na versão 87ae8e0 PASS) e review (APPROVED, 0 Critical, 0 Important, 6 Minor) verdes). Entregue: a tabela mfit.avaliacao_fisica com quatro políticas (_leitura, _insercao, _atualizacao, _exclusao), cinco gatilhos (um de lista e quatro de auditoria) e sete CHECKs, sem função nova; GRANT UPDATE somente em desativado_em e desativado_por, de modo que nenhum campo de conteúdo aceita atualização (a avaliação não se edita, correção é nova avaliação); o INSERT exige data = now(); a lista ponto_dobra_cutanea (Tríceps, Suprailíaca, Abdominal e Coxa) em mfit.lista_fechada_item, editável em /admin/listas; os dois tetos de texto editáveis (avaliacao_texto_curto_max_caracteres 200 e avaliacao_texto_longo_max_caracteres 2000), de modo que mfit.parametro vai de 36 para 38 linhas e as listas fechadas com consumidor de sete para oito; as rotas de /api/avaliacoes (lista por aluno, detalhe com ?com= para escolher a avaliação de comparação, criar e desativar); as telas /saude/avaliacoes, /saude/avaliacoes/nova e /saude/avaliacoes/:id (aba Avaliações dentro da casca de /saude, com o aviso não clínico no topo); o contrato único de campos com espelho na web; o leitor único avaliacao/avaliacao.ts, que chama o registro de leitura administrativa em toda leitura; a comparação como função pura sobre as avaliações ativas (variação com sinal e unidade, métrica ausente aparece como "não informado" e nunca vale zero, métrica de teste só varia com o mesmo teste, avaliação desativada fica fora); e o tempo do teste aeróbico em minutos e segundos (mm:ss) no formulário, no detalhe e na comparação. Migração 0058 (aprovada pelo Fiscal sem card): troca só o CHECK anamnese_secoes_formato da anamnese pela forma estrita, que recusa {"medico":[]} (arranjo no lugar de objeto), com aborto nomeando a contagem de linhas violadoras (produção tinha 0 anamneses); provada 19 de 19 casos e com rollback ensaiado, e no qa o POST com {"medico":[]} dá 400. H1 provado em produção ({TA-39}): cada uma das quatro especialidades registra com a especialidade_autor correta (201), o Nutricionista com a antropometria completa e quatro dobras, o aluno registra com especialidade_autor nula (com quatro vínculos e sem vínculo); a comparação mostra anterior, atual e variação com sinal e unidade (peso -1,5 kg, dobra -1,0 mm), métrica presente em só uma avaliação sem variação, o mesmo teste normalizado varia e testes diferentes aparecem como "testes diferentes"; consentimento ausente, restrito e revogado negam como esperado (403 categoria_nao_compartilhada para o Personal quando restrito ao Médico, titular e Super leem a revogada); o Administrador recebe 403 nomeado nas rotas e o Super lê o mesmo detalhe; o não vinculado recebe 404; desativar vale para o autor e o Super (segunda vez 409, não autor que lê 403, PATCH, PUT, DELETE e reativar 404); validações de forma e de teto (campo desconhecido no corpo, NUL, dobra inexistente, 11 testes, idade 121, peso 501, 200 e 2000 caracteres aceitos, 201 e 2001 recusados). Trilha: criar grava em avaliacoes, alterar 0, e o Super lendo a lista deixa uma linha acesso_administrativo por avaliação devolvida (duas na comparação). Placares medidos: db-ops no efêmero, 133 casos por modo, 133 ok, 0 falhas, tabelas de 32 para 33, políticas de 81 para 85, funções inalteradas em 59, parâmetros de 36 para 38, listas de 7 para 8; produção conferida pelo qa em 38 parâmetros e 8 listas em /admin/listas; verificar:acesso capacidade por especialidade 16 de 16; leitor único 5 de 10; verifica-parametros 51 de 98, C 58, universo 156; suíte do servidor 1475 testes, 1397 passam, 0 falham, 78 pulados, e web 306 de 306. Perda declarada: a avaliação não se corrige, só se refaz (RN-009); o autor de vínculo encerrado lê o detalhe pelo identificador e não encontra a avaliação na lista (decisão do Fiscal: mantém); o Super ao desativar gera duas linhas acesso_administrativo (leitura prévia e resposta); JSON malformado em POST /api/avaliacoes devolve 422 avaliacao_vazia em vez de 400, mesmo padrão já aceito na anamnese, e a decisão do Fiscal leva o ajuste para {F5-03}; o placeholder pendente: F5-02 de avaliacao_fisica nas suítes genéricas de remoção e acesso administrativo segue (a cobertura real está em avaliacao.test.ts, e a anamnese tem o mesmo placeholder). Ressalvas do qa: P1-1 (a tabela de comparação mostrava o tempo em segundos) corrigido em 87ae8e0 e confirmado no reteste (12:34, 11:50 e -0:44 em claro e escuro); P2 "Comparar com" (opções idênticas no mesmo dia) corrigido, com rótulo "1a do dia" e a medida; P2 do degrau do cartão "Mais recente" corrigido, 0 degrau em 6 larguras; P2-5 (lista de anamneses a 768 de largura, etiqueta do cartão "Mais recente" quebra e desce a data 27 px) fica aberto como achado novo, sem bloqueio, e não se provou se já existia. Limpeza: limpar-contas-de-teste.mjs na rodada 1 apagou 11 contas e na do reteste 5 contas (--prefixo qa.f502r), aritmética fechada e 0 resíduo em 43 verificações nas duas, usuários restantes 4 (três de topo mais aluno.teste). Lacunas declaradas: item de lista desativado pelo Super não exercitado em produção (coberto em S-8 do db), Super personificando não exercitado, contraste de fundo em gradiente não medido pelo instrumento (olhado, legível), 429 e carga não testados; o review aceitou 6 Minor. Não entra aqui: cálculos derivados (IMC, relação cintura quadril e frequência cardíaca máxima, {F5-03}), exame, prescrição e reabilitação ({F5-04} a {F5-06}), medida corporal ({F5-07}), o botão Explicar ({F5-10}), edição de conteúdo e exportação ({F8-09}).

RF-SAUD-003 e RN-004.

Como verificar (teste primeiro): teste unitário por fórmula, com valor conhecido e caso de borda de campo ausente.

Aceite (H1): Dado um aluno com oitenta quilogramas, um metro e oitenta, cintura noventa, quadril cem e trinta anos, Quando a avaliação é salva, Então o índice de massa corporal exibido é 24,7, a relação cintura quadril é 0,90 e a frequência cardíaca máxima é 190, E as faixas de intensidade são calculadas sobre esse valor.

Nota (Inspeção, gate {F5-02}, Drift 9, 2026-10-01): os cálculos são uma função pura no contrato da avaliação, aplicada na LEITURA (detalhe, lista e comparação), sobre peso_kg, altura_cm, cintura_cm, quadril_cm e idade_anos, que {F5-02} já grava; nenhuma coluna e nenhuma migração para guardar cálculo (RN-004, "calculados, não digitados"). Campo ausente nunca vira zero: sem a altura, o índice de massa corporal não é exibido. Os cálculos entram na comparação como métricas, pela mesma regra de RF-SAUD-002.

Nota (Inspeção, gate {F5-03}, Drifts 1 a 6 e P2 visual, 2026-10-06): publicados antes do código; nenhuma marcação muda e o H1 não muda. (1) Onde: o cálculo aparece no detalhe e na comparação; a lista fica fora, porque o RF exige exibir a fórmula e ela não cabe no cartão. Isto substitui "detalhe, lista e comparação" da Nota do Drift 9 acima. (2) Constantes: a frequência cardíaca máxima como 220 menos a idade, o índice de massa corporal, a relação cintura quadril e as cinco zonas (50 a 60, 60 a 70, 70 a 80, 80 a 90 e 90 a 100 por cento da frequência máxima) 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. Uma linha C nomeada no verificador de parâmetros; nenhum parametro() novo, nenhuma coluna e nenhuma migração. (3) Comparação: índice de massa corporal (uma casa, kg/m²), relação cintura quadril (duas casas) e frequência cardíaca máxima (zero casas, bpm) entram ao fim, na seção "Cálculos", pela regra de RF-SAUD-002 (e); as zonas não entram (função da frequência máxima, dez linhas redundantes); as linhas antigas mantêm ordem e chave. (4) Não exibido: o número some e a linha diz "não calculado: informe a altura"; nunca zero. (5) Arredondamento: meio para cima sobre a representação decimal, e não toFixed; divisor zero ou ausente devolve nulo. (6) Corpo inválido: 400 corpo_invalido para JSON malformado ou corpo que não é objeto, em um ponto único novo, server/src/http/corpoJson.ts, adotado em POST /api/avaliacoes e POST /api/anamneses; nutrição não muda (JSON malformado lá segue 422 campos_invalidos); medido no gate: 36 leituras de corpo em 23 arquivos, 9 em 4 arquivos já respondem 400 por try/catch próprio; o restante é o card {AUD-13}. (7) P2 visual (alinhamento das listas clínicas): .mf-clin-lista passa a usar subgrid, com o item da lista e o cartão em grid-template-rows: subgrid e uma linha explícita por parte (cabeçalho, data, resumo opcional, rodapé), de modo que cartões vizinhos alinham cabeçalho, data e rodapé na mesma linha de grade; o cabeçalho é uma grade 1fr auto sem quebra, com a etiqueta na primeira linha do título; sem suporte a subgrid vale a regra atual; só em e rem, zero px. Prova: degrau zero medido em 360, 768, 1024, 1280, 1440 e 1920, nos temas claro e escuro, nas duas listas (anamnese e avaliação, com o título longo "Prática esportiva" e etiqueta).

Perda declarada ({F5-03}): o cliente que manda JSON inválido ou corpo que não é objeto às duas rotas recebia 422 *_vazia e passa a receber 400 (os testes de anamnese e de avaliação que esperavam 422 passam a esperar 400, decidido); no cartão da lista, a etiqueta deixa de quebrar para baixo do título e passa a ficar ao lado, inclusive em tela estreita. Nada mais: o detalhe e a comparação só ganham campos, e nutrição e as demais leituras de corpo ficam intocadas.

Fechamento [2026-10-06]: entregue e 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); gates plan (APPROVED com 7 drifts, 1 a 4 publicados antes do código), review (rodada 1 CHANGES REQUESTED por um Important, corrigido, APPROVED) e qa (rodada 1 PASS, 0 P0, 0 P1, 0 P2, 2 P3) verdes). Entregue: a função pura calcularDerivados (server/src/avaliacao/calculos.ts), aplicada na leitura, sem coluna e sem migração: índice de massa corporal, relação cintura quadril, frequência cardíaca máxima (220 menos a idade) e as cinco zonas de intensidade, cada um com valor, unidade, casas e fórmula visível; o bloco "Cálculos" no detalhe da avaliação (valor, unidade e fórmula, zonas em tabela que empilha em tela estreita, aviso não clínico no topo); três linhas novas ao fim da comparação (calculo.imc, calculo.rcq, calculo.fc_max, seção "Cálculos"), com as 14 linhas antigas na mesma ordem e chave e as zonas fora; o ponto único server/src/http/corpoJson.ts, que faz POST /api/avaliacoes e POST /api/anamneses responderem 400 corpo_invalido a JSON malformado, corpo vazio, null, lista, texto e número; e o subgrid nas listas clínicas (.mf-clin-lista), com a etiqueta "Mais recente" ao lado do título. H1 provado em produção ({TA-40}): 80 kg, 180 cm, cintura 90, quadril 100 e 30 anos dão índice de massa corporal 24,7, relação cintura quadril 0,90 e frequência cardíaca máxima 190, com as zonas 95 a 114, 114 a 133, 133 a 152, 152 a 171 e 171 a 190 sobre esse valor, na API e na tela; 48 kg e 160 cm dão 18,8 e 28,8 kg e 160 cm dão 11,3 (o meio para cima, que o review achou errado em ponto flutuante e foi corrigido para a conta em centímetros); idade 33 dá 187; sem insumo o valor é nulo e a linha diz "Não calculado: informe ..." (peso e altura, cintura e quadril, idade), nunca zero. A lista de avaliações não traz cálculo. 400 provado: nas duas rotas, os seis corpos inválidos dão 400 com a contagem de registros inalterada, {} segue 422 (avaliacao_vazia e anamnese_vazia), o Administrador recebe 403 antes do 400 e nutrição (/api/refeicoes) segue 422 campos_invalidos. Subgrid provado: degrau 0 em título, data, legenda, rodapé e altura dentro da fileira, nas listas de anamneses e de avaliações, em 360, 768, 1024, 1280, 1440 e 1920, nos temas claro e escuro (24 combinações, 0 achados, controle negativo detectado), sem rolagem horizontal. Placares medidos: suíte do servidor na rodada do review 1491 testes, 1413 passam, 0 falham, 78 pulados (os mesmos de {F5-02}), com a correção do Important acrescentando dois testes (48 kg e 160 cm, 32 kg e 160 cm; arquivo de cálculos 13 de 13); web 315 de 315; verificar:parametros 51 de 98 inalterado, universo 156 para 157, exceção C 58 para 59 (a linha das constantes de literatura); verificar:acesso e verificar:leitura-sensivel (5 de 10) verdes. Perda declarada: o cliente que manda corpo inválido às duas rotas recebia 422 *_vazia e passa a receber 400 (decidido, D6), e no cartão da lista a etiqueta fica ao lado do título e, em 768, o título longo quebra em duas linhas no cartão com etiqueta e o vizinho reserva a linha em branco (consequência do subgrid, P3). Ressalvas: os 2 P3 do qa (o espaço sob o título curto em 768; os rótulos "Zona", "Intensidade" e "Batimentos" literais no JSX e o tipo corpo_invalido triplicado, que {AUD-13} reúne). Lacunas declaradas: o Super personificando e o Chrome com cabeça não foram exercitados (Edge headless via playwright-core). Limpeza: 4 contas, 7 avaliações físicas e 3 anamneses de teste apagadas pelo script, aritmética fechada e 0 resíduo em 43 verificações. O resto do 400 é {AUD-13}, que segue [ ] e entra antes de {F5-04}. Não entra aqui: classificação do índice de massa corporal (o produto não é clínico), cálculo na lista, as zonas na comparação, exame, prescrição e reabilitação ({F5-04} a {F5-06}), medida corporal e gráfico ({F5-07}).

RF-SAUD-004 e ADR-009.

Nota (gate {AUD-07}, 2026-09-29): a lista nasce como linhas de mfit.lista_fechada_item (valor no CHECK de lista), nunca enum nem constante ({AUD-07}).

Nota (R-14, {F2-02}): o middleware de cabeçalhos, a guarda de tamanho, a detecção de formato pelos bytes e a ordem "objeto antes da linha" nascem em {F2-02}. Este card não constrói uma segunda via de arquivo: escreve no repositório privado reusando aquele desenho, e acrescenta o que é dele (consentimento, endereço assinado na leitura, auditoria de leitura sensível).

Aceite (H1): Dado um aluno que consentiu a categoria exame, Quando envia um exame com anexo de até vinte megabytes, Então o exame aparece na lista com tipo, nome e data e o anexo abre por endereço assinado, E arquivo acima do limite ou de extensão fora da lista é recusado com a mensagem do campo.

Nota (F1-09): entidade sensível de RN-001. A leitura desta entidade é servida pelo leitor único de registro sensível (server/src/acesso/leituraSensivel.ts), nunca por consulta própria da rota; rodar ops/verifica-leitura-sensivel.mjs antes do gate do qa, conforme a seção do gabarito em GABARITO-ACESSO-ALUNO.md.

Nota (F1-10): entidade removível de RF-CORE-008. Ao criar a tabela, aplicar a seção de remoção do gabarito (GABARITO-ACESSO-ALUNO.md): coluna desativado_em/desativado_por (R-2 do gate {F1-10}), a política FOR DELETE exigindo o papel administrador e o gatilho de remoção, e rodar o verificador de verificarPoliticas.ts antes do gate do qa.

Nota (F1-12): entidade sensível de consentimento (RN-001). Ao criar a tabela, aplicar a quinta seção do gabarito (GABARITO-ACESSO-ALUNO.md, "Consentimento por categoria"): marcar categoriaConsentimento: 'exame' na entrada dela em ENTIDADES_E1; a política de leitura em conjunção com mfit.consentimento_visivel(aluno_id, 'exame'), além de mfit.pode_ler_aluno; o WITH CHECK de INSERT e de UPDATE em conjunção com mfit.tem_consentimento(aluno_id, 'exame'); o gatilho AFTER INSERT chamando mfit.auditar_criacao('aluno_id'); e rodar o verificador de {F1-12} antes do gate do qa, subindo o placar N de 6 no Plano de Testes (TA-10).

Nota (F1-16): ao criar a tabela da dimensão de armazenamento de anexos, o ramo novo entra no CASE de mfit.consumo_do_aluno (não mais em dentro_do_limite_do_aluno, que desde {F1-16} só decide); sem o ramo a função continua levantando exceção, de propósito, e a política nova nasce quebrando, nunca liberada em silêncio; e a tela /plano passa a exibir aquela dimensão sozinha, sem uma linha de código de front, não escrever uma segunda contagem para a tela.

Nota [F1-18]: a tela nasce com <AvisoNaoClinico ponto="telas_clinicas" /> no topo, consumindo o texto vigente da tabela; não escreva o parágrafo no componente. O décimo terceiro verificador (ops/verifica-aviso-nao-clinico.mjs) reprova se esta tela existir sem ele, e o placar de RF-CORE-012 sobe de 2 para 3 e para 4 conforme elas nascerem.

Nota (Inspeção, gate {F5-01}, Drift 7, 2026-10-01): a Nota F1-18 acima passa a dizer: a aba desta tela nasce DENTRO da casca de /saude, criada em {F5-01}, que já traz <AvisoNaoClinico ponto="telas_clinicas" /> no topo e serve as quatro telas clínicas; não nasce rota de tela clínica fora da casca, e o verificador reprova aba clínica fora dela. O placar de RF-CORE-012 sobe de 2 para 3 com {F5-01}, e o quarto ponto é o pacote de exportação ({F8-09}); as abas de {F5-04} a {F5-06} não sobem o placar, porque o ponto 3 é uma tela só.

Nota (Inspeção, gate {F5-04}, Drifts 1 a 11 e migração 0059, 2026-10-06): publicados antes do código; nenhuma marcação muda e o H1 não muda. (1) Fronteira com {F5-09}: este card só EMITE o endereço assinado no detalhe, pelo ponto que já existe (emitirEnderecoArquivoSensivel); não toca assinar.ts, privado.ts, a faixa de 1 a 60 minutos de url_assinada_validade (o "até quinze minutos" do H1 de {F5-09} é daquele card) nem a separação entre mídia e exame. (2) Limite de envio: o limite de corpo de 20 megabytes do servidor web barra um arquivo de exatamente 20 MiB mais o envelope do envio com um 413 em HTML, e o H1 falharia na borda; a faixa de anexo_tamanho_max vai a 50, então o limite sobe para 51 megabytes (validado antes da recarga, recarregado e nunca reiniciado). Condição ratificada: o limite de 51 megabytes vale SÓ no bloco do servidor de fit.modulareasy.com, nunca no arquivo global do servidor web, e a faixa publicada de anexo_tamanho_max (1 a 50 megabytes) não pode passar do limite desse bloco: subir a faixa exige subir o limite antes e republicar a faixa. (3) Desativar não apaga o objeto: o exame desativado segue legível ao titular e ao Super Administrador e o anexo segue contando na cota; o objeto só é apagado na exclusão definitiva (hoje só a limpeza, sem rota de exclusão clínica, precedente da anamnese), e quem garante é o verificador de órfãos disco contra banco no repositório privado. (4) Diretório vazio: o defeito do diretório que sobrava vazio é corrigido AQUI, no mecanismo comum de remoção: remover um objeto apaga o diretório pai quando ele fica vazio, nunca acima da raiz do repositório; o exercício ganha a mesma limpeza junto. (5) Aviso aos Médicos: a notificação aos Médicos vinculados (Apêndice de formulários, {ART-WF-07}) NÃO é deste card: fica em {F6-05}, no precedente do Drift 6 de {F4-03}; o H1 de {F5-04} e o caso {TA-41} não a pedem. (6) Placares parciais, sem marcar: com {F5-04}, {TA-85} fica em 3 de 4 (a aba Exames nasce dentro da casca de /saude, que já contava; Drift 7 de {F5-01}); sobem {TA-10} de 3 de 7 para 4 de 7, {TA-07} de 5 de 10 para 6 de 10, a capacidade por especialidade de 16 para 18 e o leitor único de registro sensível de 5 de 10 para 6 de 10, a medir no fechamento. (7) O exame não se edita: a atualização só desativa, e só o autor ou o Super Administrador (como em {F5-02}); notas em RF-SAUD-004 e RN-009 do DRS. (8) Data: a data do exame é do usuário, não futura com a folga de fuso já existente no servidor, e o momento do registro é gravado pelo banco e exigido igual a agora na política (Apêndice de formulários). (9) Tetos de texto como parâmetros (precedente da refeição): exame_nome_max_caracteres 160 (faixa de 80 a 500), exame_resumo_max_caracteres 4000 (faixa de 500 a 10000) e exame_observacoes_max_caracteres 2000 (faixa de 500 a 10000), e o mínimo de 3 caracteres do nome é regra fixa; mfit.parametro passa de 38 para 41 linhas (L.2, {ART-CFG-01}). (10) Cota de anexos: ramo novo de anexos_megabytes em mfit.consumo_do_aluno (soma de anexo_bytes, megabytes arredondados para cima; a foto entra em {F5-08}); a política usa a forma genérica (consumo anterior menor que o limite) e a soma com o anexo novo é decidida pelo servidor ANTES de gravar o objeto, com a mensagem de limite existente. (11) Tipo pelos bytes e pela extensão declarada: os dois na lista 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; a lista tipo_exame nasce com cinco itens e as listas fechadas com consumidor passam de oito para nove. Migração deste card: 0059_exame.sql, a seguinte à 0058: a tabela mfit.exame (id, aluno_id, autor_id, especialidade_autor nula quando o autor é o aluno, tipo, nome, data_exame, resumo, observacoes, anexo_chave, anexo_bytes e anexo_formato juntos ou nenhum, criado_em, desativado_em e desativado_por); leitura por pode_ler_aluno(aluno_id, autor_id, false, 'exame') em conjunção com consentimento_visivel; inserção com tem_consentimento e vínculo ativo de Médico (literal) ou titular; atualização concedida somente em desativado_em e desativado_por; exclusão só do Super Administrador; cinco gatilhos (um de lista e quatro de auditoria); nenhuma função nova; a lista tipo_exame e os três parâmetros. Tabelas do schema de 33 para 34, parâmetros de 38 para 41 e listas de 8 para 9, a medir no fechamento e não a projetar; a trava de cardinalidade da carga passa a 41 no mesmo deploy da migração (migração e código novo entram no mesmo passo, sem janela). Ficam fora deste card: o endereço assinado com validade curta e a separação mídia x exame ({F5-09}), o aviso aos Médicos ({F6-05}), a explicação em linguagem simples ({F5-10}), a foto de progresso e a cota dela ({F5-08}) e a exportação ({F8-09}). Perda declarada: um envio acima de 20 megabytes e até 51 chega à aplicação, que o recusa pela guarda de tamanho, em vez de receber o 413 do servidor web; no exercício, a remoção passa a apagar também o diretório vazio (ninguém o lia); nada mais, porque a mídia só troca a origem das assinaturas. O cartão continua [ ].

Fechamento [2026-10-06]: entregue e em produção (merge b078e76, repositório wladimirdjr/modularfit, migração 0059_exame.sql aplicada em produção em 06/10, limite de envio de 51 megabytes no bloco do servidor de https://fit.modulareasy.com, só nele (a mesma árvore já provada em produção como bde96b3; o deploy da main em b078e76 segue em curso); gates plan (APPROVED com 11 drifts, D1 a D11 ratificados pelo Fiscal, 1, 3, 5 e 7 publicados antes do código), db (PASS), review (rodada 1 APPROVED, 0 Critical, 0 Important, 6 Minor) e qa (rodada 1 PASS, 0 P0, 0 P1, 0 P2, 3 P3) verdes). Entregue: a tabela mfit.exame (migração 0059: quatro políticas, cinco gatilhos, atualização concedida somente em desativado_em e desativado_por, exclusão só do Super Administrador, nenhuma função nova); o ramo anexos_megabytes em consumo_do_aluno (soma de anexo_bytes de toda linha do titular, ativa ou desativada, em megabytes arredondados para cima, os três ramos antigos intactos); os três tetos de texto como parâmetros editáveis com as faixas publicadas (exame_nome_max_caracteres 160, faixa de 80 a 500; exame_resumo_max_caracteres 4000 e exame_observacoes_max_caracteres 2000, ambos de 500 a 10000); a lista tipo_exame (Laboratorial, Imagem, Cardiológico, Funcional e Outro); a escrita única de arquivos (arquivos/escrita.ts, pública e privada, no lugar de escritaPublico.ts) com a ordem 401, Administrador 403, guarda de Content-Length, corpo, consentimento, vínculo, cota, objeto e linha, e remoção do objeto se a linha falhar; o tipo pelos bytes e pela extensão declarada (formatoPelosBytes); o ponto único do módulo de exame (exame/exame.ts), que grava uma só trilha administrativa por detalhe com anexo e não põe endereço na lista; e a aba Exames dentro da casca de /saude, com o aviso não clínico no topo, sem px. Contagens medidas: tabelas do schema de 33 para 34, políticas de 85 para 89, funções inalteradas em 59, parâmetros de 38 para 41, listas fechadas de 8 para 9, rotas de corpo 54 = 37 JSON + 2 multipart + 15 sem corpo. H1 provado em produção ({TA-41}): PDF de exatamente 20 MiB aceito (201) e aberto pelo endereço assinado com 20971520 bytes; 20 MiB mais um byte recusado com a mensagem do campo (JSON anexo_grande_demais, com a faixa de 1 a 50 e o limite vigente, e não o 413 em HTML do servidor web); .exe, .svg, .html, PNG renomeado para .pdf, arquivo vazio, sem extensão e texto com byte nulo recusados, com zero objeto no disco. O endereço abre sem cookie; assinatura adulterada, expiração estendida e endereço vencido (medido de verdade) dão 403. Sem consentimento, com consentimento revogado ou restrito a outra especialidade, e para o Personal Trainer e o Administrador, não grava (com os pares positivos em 201); o Médico sem vínculo recebe 404. Desativar não apaga o objeto: o arquivo segue no disco, abre e a cota não cai. Cota do plano Gratuito: cinco envios de 20 MiB fecham 100 de 100 e o sexto recebe 409 com a mensagem de limite. Tetos 160, 4000 e 2000 aceitos e mais um caractere recusado. No exercício, remover a imagem e apagar o exercício fazem a pasta sumir (D4). 72 combinações de 6 larguras, 2 temas e 6 telas sem rolagem horizontal. Limpeza das contas de teste provada: zero resíduo, verificador de órfãos 0, 0 e 0. Placares medidos: capacidade por especialidade 18 de 18; leitor único de registro sensível 6 de 10; consentimento por categoria 4 de 7; aviso não clínico segue 3 de 4 (Drift 7 de {F5-01}: a aba dentro da casca não é ponto novo); suíte do servidor na rodada do review 1597 testes, 1521 passam, 0 falham, 76 pulados (nenhum do exame); web 332 de 332; verificador de corpo 13 de 13 decoys. Perda declarada, confirmada: um envio de 20 a 51 megabytes chega à aplicação, que o recusa em JSON, em vez do 413 do servidor web; remover um objeto agora apaga também o diretório vazio (exercício e exame); nada mais. Lacunas declaradas: Fisioterapeuta e Nutricionista não foram exercitados (o cadastro de teste bateu em 429; coberto o Personal, mesma negação), a tela do 413 de servidor não foi exercitada (o cliente barra antes; o 413 foi provado por API) e o contraste por script não rodou nesta rodada. P3 do qa: a tela do arquivo de 20 MiB mais um byte diz "20 MB e o limite é 20 MB" (arredondamento); o alerta geral do formulário fica depois de corrigir; POST /api/exames sem o aluno dá 403 e não 400. Para os cards seguintes: o CHECK da extensão e a allowlist do repositório privado com Content-Disposition ficam em {F5-09} e {F5-08}, e um decoy do limite no INSERT da soma de grandeza em {F5-08}. Fora deste card, como declarado: o endereço de validade curta e a separação mídia x exame ({F5-09}), o aviso aos Médicos ({F6-05}), a explicação em linguagem simples ({F5-10}), a foto e a cota dela ({F5-08}) e a exportação ({F8-09}). O Beta correspondente segue [ ], porque depende de operador real. O cartão passa a [x].

RF-SAUD-005.

Aceite (H1): Dado um médico com vínculo ativo, Quando registra uma prescrição com diagnóstico, medicamentos, posologia e duração, Então ela aparece na tela do aluno com data e autor, E exibe o aviso de que não substitui o receituário oficial.

Nota (F1-09): entidade sensível de RN-001. A leitura desta entidade é servida pelo leitor único de registro sensível (server/src/acesso/leituraSensivel.ts), nunca por consulta própria da rota; rodar ops/verifica-leitura-sensivel.mjs antes do gate do qa, conforme a seção do gabarito em GABARITO-ACESSO-ALUNO.md.

Nota (F1-10): entidade removível de RF-CORE-008. Ao criar a tabela, aplicar a seção de remoção do gabarito (GABARITO-ACESSO-ALUNO.md): coluna desativado_em/desativado_por (R-2 do gate {F1-10}), a política FOR DELETE exigindo o papel administrador e o gatilho de remoção, e rodar o verificador de verificarPoliticas.ts antes do gate do qa.

Nota (F1-12): entidade sensível de consentimento (RN-001). Ao criar a tabela, aplicar a quinta seção do gabarito (GABARITO-ACESSO-ALUNO.md, "Consentimento por categoria"): marcar categoriaConsentimento: 'prescricao' na entrada dela em ENTIDADES_E1; a política de leitura em conjunção com mfit.consentimento_visivel(aluno_id, 'prescricao'), além de mfit.pode_ler_aluno; o WITH CHECK de INSERT e de UPDATE em conjunção com mfit.tem_consentimento(aluno_id, 'prescricao'); o gatilho AFTER INSERT chamando mfit.auditar_criacao('aluno_id'); e rodar o verificador de {F1-12} antes do gate do qa, subindo o placar N de 6 no Plano de Testes (TA-10).

Nota [F1-18]: a tela nasce com <AvisoNaoClinico ponto="telas_clinicas" /> no topo, consumindo o texto vigente da tabela; não escreva o parágrafo no componente. O décimo terceiro verificador (ops/verifica-aviso-nao-clinico.mjs) reprova se esta tela existir sem ele, e o placar de RF-CORE-012 sobe de 2 para 3 e para 4 conforme elas nascerem.

Nota (Inspeção, gate {F5-01}, Drift 7, 2026-10-01): a Nota F1-18 acima passa a dizer: a aba desta tela nasce DENTRO da casca de /saude, criada em {F5-01}, que já traz <AvisoNaoClinico ponto="telas_clinicas" /> no topo e serve as quatro telas clínicas; não nasce rota de tela clínica fora da casca, e o verificador reprova aba clínica fora dela. O placar de RF-CORE-012 sobe de 2 para 3 com {F5-01}, e o quarto ponto é o pacote de exportação ({F8-09}); as abas de {F5-04} a {F5-06} não sobem o placar, porque o ponto 3 é uma tela só.

Nota (Inspeção, gate {F5-05}, Drifts 1 a 10 e migrações 0060 e 0061, 2026-10-06): publicados antes do código; nenhuma marcação muda e o H1 não muda. (1) A prescrição não se edita (Drift 1): só desativa, o autor ou o Super Administrador, como em {F5-01}, {F5-02} e {F5-04}; Nota em RN-009 do DRS. (2) Colunas (Drift 2): a tabela nasce COM observacoes e SEM explicacao_gerada, que é de {F5-10}. (3) Notificação (Drift 3): a notificação de prescrição criada fica em {F6-05}. (4) Aviso do receituário (Drift 4): texto versionado editável, chave nova aviso_receituario no ponto prescricao existente, publicada em /admin/textos e exibida pelo componente AvisoDoReceituario na lista, no formulário e no detalhe, com o texto vindo sempre da tabela e nunca do componente; o verificador conta 3 de 3. Não é RF-CORE-012: {TA-85} fica em 3 de 4 e este card não é dono do quarto ponto ({F8-09}). (5) Tetos (Drift 5): um só, prescricao_texto_longo_max_caracteres, 4000, faixa de 500 a 10000, para os quatro textos longos (diagnóstico, medicamentos, posologia e observações); o teto curto não nasce, porque a duração deixou de ser texto (Drift 7). mfit.parametro passa de 41 para 42 linhas, e não 43 (L.2, {ART-CFG-01}). (6) Data (Drift 6): data da prescrição não futura, com a folga de fuso espelhada do servidor (o literal na política é o mesmo AMPLITUDE_DE_FUSO_EM_DIAS, com verificador com decoy), e criado_em = now() exigido na política. (7) Duração estruturada (Drift 7, decisão da Inspeção): duracao_quantidade (inteiro maior que zero) e duracao_unidade (dias, semanas ou meses, restrição no banco, constante estrutural e não lista editável), ou uso_continuo; a vigência (data da prescrição mais a duração menos 1 dia; uso contínuo até desativar) alimenta {F7-09}; a posologia segue texto livre; nenhuma lista nova nasce e as listas com consumidor continuam 9. (8) {ART-FORM-08} (Drift 8) cobre dois formulários: este card entrega a metade prescrição e NÃO marca o cartão; {F5-06} o fecha. (9) Placares parciais, sem marcar (Drift 9): {TA-10} de 4 de 7 para 5 de 7; {TA-07} (leitor único de registro sensível) de 6 de 10 para 7 de 10; capacidade por especialidade do verificador de acesso de 18 para 20 entradas; rotas de corpo de 54 (37 JSON, 2 multipart e 15 sem corpo) para 56 (38, 2 e 16); universo do verificador de parâmetros de 160 para 162 (o teto longo e a constante da unidade, classificada C), a confirmar pelo verificador no fechamento; {TA-85} não se move; o teste D-6.3 passa a usar sessao_reabilitacao como tabela inexistente, porque prescricao passa a existir. Tudo a medir no fechamento, e não a projetar. (10) Escopo extra (Drift 10): (a) textoDeTamanhosDistintos no trecho espelhado de contratoExame: sobe a precisão (1 casa, 2 casas, KB, bytes) até tamanho e teto diferirem, e o 413 do servidor e a recusa do cliente usam a mesma; (b) hook comum web/src/saude/errosDoFormulario.ts: o alerta de campos é derivado e some quando não há erro, o alerta de outra origem fica até o próximo envio, adotado nos quatro formulários, e os três limparErroDe saem. O 403 de POST sem aluno NÃO muda: o auxiliar serve sete módulos, o desfecho depende do papel e a tela nunca envia sem aluno, e mudar mexeria em 14 rotas por um P3; a prescrição herda o 403, fixado em teste. Migrações deste card: 0060 contém SÓ ALTER TYPE mfit.chave_texto ADD VALUE 'aviso_receituario' (isolada; irreversível, e declarado); 0061_prescricao.sql cria a tabela mfit.prescricao (id, aluno_id, autor_id, especialidade_autor 'medico', diagnostico, medicamentos, posologia, duracao_quantidade, duracao_unidade, uso_continuo, data_prescricao, observacoes, criado_em, desativado_em e desativado_por); leitura por pode_ler_aluno(aluno_id, autor_id, false, 'prescricao') em conjunção com consentimento_visivel; inserção com autor igual à sessão, profissional, tem_vinculo_ativo_na_especialidade(aluno_id, 'medico') literal, tem_consentimento e data até hoje mais 1 dia; atualização concedida somente em desativado_em e desativado_por; exclusão só do Super Administrador; gatilhos de auditoria; o parâmetro e a semente do texto; nenhuma função nova. Ordem das recusas na rota de criação: 401, Administrador 403, corpo 400, aluno, consentimento, vínculo, campos, data e só então o INSERT; byte nulo recusado; trilha administrativa só do Super Administrador. Contagens a medir no fechamento, e não a projetar: tabelas do schema de 34 para 35, parâmetros de 41 para 42, listas fechadas com consumidor 9. Perda declarada: nos formulários de anamnese, avaliação e exame, o alerta de campos passa a sumir ao corrigir (antes ficava até o envio); a recusa de anexo grande muda de texto, mais precisa; nada mais. O cartão continua [ ].

Fechamento [2026-10-06]: entregue e em produção (merge de718a6, repositório wladimirdjr/modularfit, migrações 0060 e 0061 aplicadas em produção em 07/10 (UTC; noite de 06/10 em Brasília), https://fit.modulareasy.com (a mesma árvore já provada em produção como 9510270; o deploy da main em de718a6 segue em curso); gates plan (APPROVED com 10 drifts, D1 a D4 e D7 publicados antes do código, e a duração estruturada decidida pelo Fiscal), db (PASS), review (rodada 1 CHANGES REQUESTED por 1 Important, a tela /admin/textos sem a chave do aviso, corrigido em seguida; a revisão do ajuste de datas APPROVED) e qa (rodada 1 PASS, 0 P0, 0 P1; reteste bf90408 PASS; reteste 9510270 PASS) verdes). Entregue: a tabela mfit.prescricao (15 colunas, 8 restrições, 4 políticas, 4 gatilhos de auditoria, nenhuma função nova) e o módulo server/src/prescricao/ (leitor único), com GET /api/prescricoes, GET /api/prescricoes/:id, POST /api/prescricoes e POST /api/prescricoes/:id/desativar; não existe PUT, PATCH nem DELETE. Só o Médico com vínculo ativo grava (a decisão é do banco); Personal, Fisioterapeuta, Nutricionista, aluno e Administrador recebem 403, e o Super Administrador sem personificar também; o aluno só lê. A recusa por papel vem antes do consentimento. Duração estruturada: duracao_quantidade de 1 a 999, duracao_unidade em dias, semanas ou meses (constante estrutural com restrição no banco, não lista editável) ou uso_continuo explícito; vigente e vigente_ate saem da leitura, sem coluna. Aviso do receituário: texto versionado aviso_receituario no ponto prescricao, versão 1 semeada pela migração e editável em /admin/textos (a tela passou a oferecer a chave, com o rótulo "Aviso do receituário"), exibido pelo componente AvisoDoReceituario na lista, no formulário e no detalhe, sempre com o texto vindo da tabela; o qa publicou duas versões pela tela e voltou ao texto original, que é o vigente (as versões 2 e 3 ficam no histórico imutável). Contagens medidas: tabelas do schema de 34 para 35, políticas de 89 para 93, funções inalteradas em 59, parâmetros de 41 para 42 (só prescricao_texto_longo_max_caracteres nasce, 4000, faixa de 500 a 10000), listas fechadas com consumidor 9 (nada de lista muda); suíte do servidor 1653 testes, 1579 passam, 0 falham, 74 pulados; verificadores: acesso (capacidade 20 de 20, consentimento 7 de 10, fronteira 7 de 13), leitura sensível 7 de 10, parâmetros (universo 165, 67 classificados C, 98 editáveis), corpo (56 rotas = 38 JSON + 2 multipart + 16 sem corpo; 13 de 13 decoys), aviso não clínico 3 + 1 + 0, órfãos 0, 0, 0; {TA-85} segue em 3 de 4. H1 provado em produção ({TA-42}): o Médico vinculado registra e a prescrição aparece na tela do aluno com data, autor e o aviso; vigência na leitura medida contra a aritmética de datas (1 dia hoje vale até hoje; 7 dias a partir de 7 dias atrás vale até ontem e não é vigente; 7 dias a partir de 6 dias atrás vale até hoje; 2 semanas valem até hoje mais 13; 1 mês a partir de 31/01 vale até 27/02; uso contínuo sem data de fim); consentimento ausente, restrito a outra especialidade e revogado dão 403, com o par positivo em cada negação; desativar só pelo autor ou pelo Super Administrador, repetido dá 409; data futura recusada. 96 combinações de largura, tema e tela sem rolagem horizontal. Correções extras do card, dentro do mesmo merge: (1) as datas exibidas passam a ser as de Brasília, em um ponto único do web (web/src/formato/data.ts), em todas as telas (antes a data de registro e de desativação saía em UTC e, entre 21h e 24h de Brasília, mostrava o dia seguinte; achado P2 do qa); data civil pura nunca passa por Date; (2) o nascimento do perfil passa a ser data pura AAAA-MM-DD (o campo abria vazio e o painel do aluno mostrava o instante cru; bug anterior ao card, achado pelo qa no reteste, P2-04); (3) o erro do seletor de data não cita mais o formato e a data da prescrição abre em hoje. Perdas ratificadas: nos formulários de anamnese, avaliação e exame o alerta de campos passa a sumir ao corrigir o último campo, e a recusa de anexo grande ganha os dois números (20 MiB mais um byte diz 20.971.521 B e 20.971.520 B). Lacunas declaradas: o qa não reavaliou o P3-03 (título e conteúdo do cartão de detalhe em eixos 21px afastados); depois das 21h de Brasília o servidor aceita data de até 2 dias à frente, a folga de fuso desenhada no Drift 6. {ART-FORM-08} NÃO se marca: {F5-06} o fecha. {F5-06}, {F5-10} e {F6-05} seguem abertos.