Cobre: RF-CORE-006.

Como testar: com P1 vinculado e P2 não vinculado ao aluno A1, solicitar por identificador direto um registro de A1 em cada uma das dezesseis entidades; repetir nas duas entidades da classe restrita (conta_integracao e aceite_termos) com os dois profissionais; consultar o perfil de A1 como P1 e conferir campo a campo a resposta.

Passa quando: as dezesseis respondem negado ou vazio para P2 e respondem o registro para P1, as duas restritas respondem negado para os dois, fechando trinta e seis casos, e a consulta de perfil devolve exatamente nome, foto e, sendo profissional, especialidade e registro, sem nenhum dos oito campos privados de D.2.

Nota: este card é executado a cada card que cria uma entidade de dado de aluno, com o placar N de 36 impresso pelo arnês de integração; só é marcado quando as dezoito entidades existirem, o que acontece na Fase 8. Arnês executado em 06/09/2026: 2 de 36, 34 pendentes por card dono (gate .claude/gates/qa/modularfit-F1-08.gate).

Nota (R-3, {F1-19}, 13/09/2026): a cláusula de perfil público deste H1 foi executada em 13/09/2026, com o gate de qa de {F1-19}. O placar N de 36 não se moveu: mfit.usuario, mfit.perfil_aluno e mfit.perfil_profissional não estão entre as dezesseis entidades de E.1, e o número exato de casos fechados continua o do arnês, nunca presumido a partir desta Nota. Este card continua [ ], porque o universo dele é o de E.1 e as três tabelas de {F1-19} não estão nele; a data de fechamento entra aqui quando a décima oitava entidade nascer, na Fase 8.

Nota (gate {F3-08}, 2026-09-15): este card move o placar N de 36 em {F3-08}, e isso se declara porque é o oposto do que {F3-07} escreveu: preferencia_treino é a sexta das dezesseis entidades de dado de aluno de E.1, e {F3-08} é o primeiro card desde {F3-05} a fazer nascer uma delas. O placar sobe pela analogia das irmãs, por dois casos, o que nega ao profissional não vinculado e o que responde ao vinculado, e o número exato é o impresso pelo arnês no dia, nunca presumido a partir desta Nota. O card continua [ ]: o universo dele só se completa na Fase 8.

Cobre: RF-CORE-007.

Como testar: com o administrador, abrir um registro de cada uma das seis categorias sensíveis e consultar a auditoria.

Nota (Inspeção, {AUD-11}, drift 4, 2026-09-30): o universo deste caso passa de seis para dez entidades sensíveis (as seis de saúde, medida_corporal, refeicao, meta_nutricional e plano_alimentar): "abrir um registro de cada uma" vale para as dez, e o arnês do leitor único imprime N de 10, hoje 0 de 10, e 2 de 10 quando {AUD-11} entregar (refeicao e meta_nutricional). As demais seguem com os cards que as criam. O card continua [ ].

Fechamento parcial (Inspeção, {AUD-11}, 2026-09-30): o placar do arnês do leitor único passa de 0 de 10 para 2 de 10 (aritmética fecha: 2 servidas mais 8 pendentes igual 10): refeicao e meta_nutricional, cada uma no ponto único do seu módulo, que chama registrarSeAdministrativo. O qa confirmou em produção que o Super lê as duas com 200 e grava a trilha na mesma leitura (+4 entradas), e que o Administrador segue com 403 nomeado. O card permanece [ ].

Passa quando: os seis conteúdos são exibidos e existem seis entradas de acesso administrativo com autor, aluno, entidade e horário.

Nota: este card é executado a cada card da Fase 5 que cria uma entidade sensível, com o placar N de 6 impresso pelo arnês do leitor único; só é marcado quando as seis entidades existirem E a tela de {F1-11} estiver no ar. Mecanismo provado em 06/09/2026 contra tabela de ensaio; 0 de 6 entidades reais servidas (gate modularfit-F1-09.gate).

Fechamento parcial (Inspeção, {F5-01}, 2026-10-01): a anamnese passa a ser servida pelo ponto único do próprio módulo (anamnese/anamnese.ts), que chama registrarSeAdministrativo em toda leitura, e o arnês do leitor único mede 4 de 10 na revisão. O qa confirmou em produção que o Super lendo a lista deixa uma linha acesso_administrativo por anamnese devolvida (6 de 6) e uma no detalhe, e que o Administrador segue com 403 nomeado. O card permanece [ ].

Fechamento parcial (Inspeção, {F5-02}, 2026-10-06): a avaliação física passa a ser servida pelo ponto único do próprio módulo (avaliacao/avaliacao.ts), que chama registrarSeAdministrativo em toda leitura, e o arnês do leitor único mede 5 de 10 na revisão (aritmética fecha: 5 servidas mais 5 pendentes igual 10). O qa confirmou em produção que o Super lendo a lista deixa uma linha acesso_administrativo por avaliação devolvida e a comparação deixa duas, e que o Administrador segue com 403 nomeado. O card permanece [ ].

Nota de placar parcial (Inspeção, gate {F5-04}, Drift 6, 2026-10-06): com {F5-04}, a entregar e sem marcar, o arnês do leitor único sobe de 5 de 10 para 6 de 10 (aritmética: 6 servidas mais 4 pendentes igual 10), porque o exame passa a ser servido pelo ponto único do próprio módulo (exames/exames.ts), que chama registrarSeAdministrativo em toda leitura; o detalhe com anexo grava uma só trilha administrativa, a da emissão do endereço, e a lista não traz endereço. Na mesma entrega, a capacidade por especialidade do verificador de acesso sobe de 16 para 18 entradas (as duas entradas novas do exame). O placar vigente continua 5 de 10 até o fechamento medido. O card permanece [ ].

Fechamento parcial (Inspeção, {F5-04}, 2026-10-06): o exame passa a ser servido pelo ponto único do próprio módulo (exame/exame.ts), que chama registrarSeAdministrativo em toda leitura, e o arnês do leitor único mede 6 de 10 na revisão (aritmética fecha: 6 servidas mais 4 pendentes igual 10); a capacidade por especialidade do verificador de acesso mede 18 de 18 (as duas entradas novas do exame, inserção e atualização). O qa confirmou em produção que a lista nunca traz endereço, que o detalhe com anexo grava uma só trilha administrativa, que só o Super lê a trilha e que o Administrador segue com 403 nomeado. O card permanece [ ].

Nota de placar parcial (Inspeção, gate {F5-05}, Drift 9, 2026-10-06): com {F5-05}, a entregar e sem marcar, o arnês do leitor único sobe de 6 de 10 para 7 de 10 (aritmética: 7 servidas mais 3 pendentes igual 10), porque a prescrição passa a ser servida pelo ponto único do próprio módulo (prescricao/prescricao.ts), que chama registrarSeAdministrativo em toda leitura. Na mesma entrega, a capacidade por especialidade do verificador de acesso sobe de 18 para 20 entradas (as duas da prescrição) e as rotas de corpo do verificador de corpo sobem de 54 (37 JSON, 2 multipart e 15 sem corpo) para 56 (38, 2 e 16). O teste D-6.3, que usa uma tabela inexistente como prova, passa a usar sessao_reabilitacao, porque prescricao passa a existir. O placar vigente continua 6 de 10 até o fechamento medido. O card permanece [ ].

Fechamento parcial (Inspeção, {F5-05}, 2026-10-06): a prescrição passa a ser servida pelo ponto único do próprio módulo (prescricao/prescricao.ts), que chama registrarSeAdministrativo em toda leitura, e o arnês do leitor único mede 7 de 10 na revisão (aritmética fecha: 7 servidas mais 3 pendentes igual 10); a capacidade por especialidade do verificador de acesso mede 20 de 20 (as duas entradas novas da prescrição, inserção e atualização) e as rotas de corpo do verificador de corpo medem 56 (38 JSON, 2 multipart e 16 sem corpo). O qa confirmou em produção que o Administrador recebe 403 em lista, detalhe, registro e desativação, e que o Super Administrador lê (200). O card permanece [ ].

Nota de placar parcial (Inspeção, gate {F5-06}, Drift 9, 2026-10-06): com {F5-06}, a entregar e sem marcar, o arnês do leitor único sobe de 7 de 10 para 8 de 10 (aritmética: 8 servidas mais 2 pendentes igual 10), porque a sessão de reabilitação passa a ser servida pelo ponto único do próprio módulo (reabilitacao/reabilitacao.ts), que chama registrarSeAdministrativo em toda leitura. Na mesma entrega, a capacidade por especialidade do verificador de acesso sobe de 20 para 22 entradas (as duas da sessão de reabilitação) e as rotas de corpo do verificador de corpo sobem de 56 (38 JSON, 2 multipart e 16 sem corpo) para 58 (39, 2 e 17). O teste D-6.3, que usa uma tabela inexistente como prova, passa a usar foto_progresso, porque sessao_reabilitacao passa a existir. O placar vigente continua 7 de 10 até o fechamento medido, e os números de capacidade e de rotas se medem no fechamento, e não se projetam. O card permanece [ ].

Cobre: RF-CORE-008.

Como testar: como aluno e como profissional, tentar remover em definitivo cada uma das onze entidades citadas no requisito.

Passa quando: a única ação oferecida é desativar, o registro desativado continua no histórico e toda exclusão definitiva por papel diferente de administrador é negada nas onze.

Nota: este card é executado a cada card que cria uma das onze entidades, com o placar N de 11 impresso pelo verificador de remoção; só é marcado quando as onze existirem E as listas de trabalho delas estiverem no ar, porque "a única ação oferecida é desativar" é afirmação de interface. Placar em 06/09/2026 após {F1-10}: 1 de 11 servida (vinculo, mecanismo no ar em produção), 10 pendentes pelos cards donos (gate .claude/gates/plan/modularfit-F1-10.gate). Nota (gate {F3-03}, 2026-09-14): placar sobe de 1 de 11 para 2 de 11, ficha_treino ganha rotas próprias de desativar e reativar, servindo o mecanismo já existente desde {F3-01}. Caso continua [ ], nove pendentes pelos cards donos. Nota (gate {F4-01}, 2026-09-30): placar sobe de 2 de 11 para 3 de 11: refeicao ganha desativar com rota e lista, provado pelo qa em produção (confirmação com Confirmar e Voltar, segunda desativação 409, refeição alheia 404, identificador inválido 400, a desativada vai a Desativadas neste dia). Caso continua [ ], oito pendentes pelos cards donos.

Cobre: RF-CORE-010.

Como testar: para cada uma das seis categorias, tentar escrever sem consentimento, conceder, escrever, revogar e tentar escrever de novo.

Passa quando: nas seis a escrita é bloqueada sem consentimento, conclui com consentimento e volta a ser bloqueada após a revogação, com o histórico ainda visível ao titular e ao Super Administrador.

Nota: o "Como testar" percorre as seis categorias escrevendo, e nenhuma das seis tabelas existe ainda; este card não fecha em {F1-12}. O que {F1-12} prova é o mecanismo, contra tabela de ensaio e contra a rota real de consentimento (GET/POST/DELETE /api/consentimentos), com o auxiliar mfit.tem_consentimento bloqueando a escrita, mfit.consentimento_visivel retirando a categoria revogada da leitura do profissional, e o histórico permanecendo legível ao titular e ao Administrador. TA-10 é marcado quando as seis existirem ({F5-01}, {F5-02}, {F5-04}, {F5-05}, {F5-06}, {F5-08}); até lá carrega o placar N de 6 que cada card dono sobe. Placar atual: 0 de 6. Mecanismo provado em produção em 07/09/2026 (F1-12) contra tabela de ensaio na transação de teste; placar 0 de 6; sobe a cada entidade sensível que nascer na Fase 5.

Nota (gate {F3-08}, 2026-09-15): o placar não se move em {F3-08}, e placar que não muda também se declara, senão o leitor supõe que ninguém olhou. A entidade de preferências de treino não é categoria de dado sensível: RN-001 fecha a lista em seis e nenhuma delas é preferência, o campo de limitações e lesões é declaração do próprio aluno e não registro clínico produzido por profissional, e a assimetria entre esse campo e a anamnese está declarada em RN-001 e nas Notas de RF-TREI-008, com a pergunta de produto registrada em {Q4} do Questionário. Continua 0 de 6.

Nota (Inspeção, {AUD-11}, 2026-09-30): RF-CORE-010 passa a ter sete categorias, com nutrição (refeição, meta nutricional e plano alimentar). O "Como testar" e o "Passa quando" deste caso valem para as sete, e o placar passa a N de 7: hoje 0 de 7. A categoria nutrição sobe o placar em um quando {TA-98} passar, e as seis de saúde seguem com os cards da Fase 5.

Fechamento parcial (Inspeção, {AUD-11}, 2026-09-30): {TA-98} passou em produção (merge 6490072), e com ele a categoria nutrição fecha o seu ciclo completo de escrever sem consentimento, conceder, escrever, revogar e ser bloqueada de novo, com o histórico legível ao titular e ao Super Administrador. O placar passa de 0 de 7 para 1 de 7, e o card permanece [ ]: as seis categorias de saúde seguem com os cards da Fase 5. Na mesma rodada o qa confirmou a regressão das seis antigas pela tela (/privacidade com sete cartões, exame concede e revoga com confirmação), o que não sobe o placar delas.

Fechamento parcial (Inspeção, {F5-01}, 2026-10-01): {TA-38} passou em produção (merge 9cb16f3, migração 0056), e com ele a categoria anamnese fecha o ciclo de escrever sem consentimento (bloqueado), conceder, escrever (201), revogar e ser bloqueada de novo, com o histórico legível ao titular e ao Super Administrador. O placar passa de 1 de 7 para 2 de 7 (aritmética fecha: 2 fechadas mais 5 pendentes igual 7: nutrição e anamnese). O card permanece [ ]: as cinco categorias restantes seguem com {F5-02}, {F5-04}, {F5-05}, {F5-06} e {F5-08}. Na mesma rodada o qa confirmou a regressão de nutrição (35 de 35 combinações iguais ao esperado).

Fechamento parcial (Inspeção, {F5-02}, 2026-10-06): {TA-39} passou em produção (merge 3ab8395, migração 0057), e com ele a categoria avaliação física fecha o ciclo de escrever sem consentimento (bloqueado, 403), conceder, escrever (201), revogar e ser bloqueada de novo, com o histórico legível ao titular e ao Super Administrador. O placar passa de 2 de 7 para 3 de 7 (aritmética fecha: 3 fechadas mais 4 pendentes igual 7: nutrição, anamnese e avaliação física). O card permanece [ ]: as quatro categorias restantes seguem com {F5-04}, {F5-05}, {F5-06} e {F5-08}. Na mesma rodada o qa confirmou a regressão da anamnese e da nutrição do aluno.

Nota de placar parcial (Inspeção, gate {F5-04}, Drift 6, 2026-10-06): com {TA-41}, a entregar e sem marcar, a categoria exame passa a fechar o ciclo de escrever sem consentimento (bloqueado), conceder, escrever, revogar e ser bloqueada de novo, e o placar sobe de 3 de 7 para 4 de 7 (aritmética: 4 fechadas mais 3 pendentes igual 7: nutrição, anamnese, avaliação física e exame). Restam {F5-05}, {F5-06} e {F5-08}. O placar vigente continua 3 de 7 até o fechamento medido. O card permanece [ ].

Fechamento parcial (Inspeção, {F5-04}, 2026-10-06): {TA-41} passou em produção (merge b078e76, migração 0059), e com ele a categoria exame fecha o ciclo de escrever sem consentimento (bloqueado, 403), conceder, escrever (201), revogar e ser bloqueada de novo (403), com o histórico ainda legível ao titular e ao Super Administrador (o Médico deixa de ler). Provado também com o consentimento restrito a outra especialidade e com o revogado. O placar passa de 3 de 7 para 4 de 7 (aritmética fecha: 4 fechadas mais 3 pendentes igual 7: nutrição, anamnese, avaliação física e exame). O card permanece [ ]: as três categorias restantes seguem com {F5-05}, {F5-06} e {F5-08}. Na mesma rodada o qa confirmou a regressão da anamnese, da avaliação e da nutrição do aluno.

Nota de placar parcial (Inspeção, gate {F5-05}, Drift 9, 2026-10-06): com {TA-42}, a entregar e sem marcar, a categoria prescrição passa a fechar o ciclo de escrever sem consentimento (bloqueado), conceder, escrever, revogar e ser bloqueada de novo, e o placar sobe de 4 de 7 para 5 de 7 (aritmética: 5 fechadas mais 2 pendentes igual 7: nutrição, anamnese, avaliação física, exame e prescrição). Restam {F5-06} e {F5-08}. O placar vigente continua 4 de 7 até o fechamento medido. O card permanece [ ].

Fechamento parcial (Inspeção, {F5-05}, 2026-10-06): {TA-42} passou em produção (merge de718a6, migrações 0060 e 0061), e com ele a categoria prescrição fecha o ciclo de escrever sem consentimento (bloqueado, 403), conceder (201), restringir a outra especialidade (403) e a Médico (201), revogar e ser bloqueada de novo (403). O placar passa de 4 de 7 para 5 de 7 (aritmética fecha: 5 fechadas mais 2 pendentes igual 7: nutrição, anamnese, avaliação física, exame e prescrição); a leitura do arnês de consentimento mede 7 de 10. O card permanece [ ]: as duas categorias restantes seguem com {F5-06} e {F5-08}. Na mesma rodada o qa confirmou a regressão da anamnese, da avaliação e do exame.

Nota de placar parcial (Inspeção, gate {F5-06}, Drift 9, 2026-10-06): com {TA-43}, a entregar e sem marcar, a categoria sessão de reabilitação passa a fechar o ciclo de escrever sem consentimento (bloqueado), conceder, escrever, revogar e ser bloqueada de novo, e o placar sobe de 5 de 7 para 6 de 7 (aritmética: 6 fechadas mais 1 pendente igual 7: nutrição, anamnese, avaliação física, exame, prescrição e sessão de reabilitação). Resta {F5-08}. O placar vigente continua 5 de 7 até o fechamento medido. O card permanece [ ].

Cobre: RF-CORE-012, D.6.

Como testar: percorrer os quatro pontos (termos no cadastro, cadastro do profissional de saúde, topo das telas de exame, prescrição, anamnese e sessão de reabilitação, e o pacote da exportação); publicar uma versão nova do texto e repetir; conferir o registro do aceite.

Passa quando: o aviso aparece nos quatro pontos, o aceite fica registrado com versão e data, a versão nova aparece nos quatro sem alterar o aceite anterior, e não existe conta ativa sem aceite registrado.

Nota (R-7, 2026-09-13): placar 2 de 4 pontos servidos. Servidos: termos do cadastro, cadastro do profissional (as quatro especialidades). Pendentes: topo das quatro telas clínicas (exame, prescrição, anamnese, sessão de reabilitação; cards {F5-01}, {F5-04}, {F5-05}, {F5-06}) e o pacote de exportação (card {F8-09}), porque as telas donas ainda não existem. O mecanismo que os servirá está entregue desde {F1-18} e é verificado por critério (ops/verifica-aviso-nao-clinico.mjs). Este card fecha quando o quarto ponto nascer.

Nota (Inspeção, gate {F5-01}, Drift 7, 2026-10-01): as quatro telas clínicas (anamnese, exame, prescrição e sessão de reabilitação) vivem na mesma tela de saúde, /saude, uma linha do Apêndice de telas, com uma aba por tipo de registro. O aviso fica no topo da casca e serve as quatro abas por construção, de modo que o ponto 3, o topo das telas clínicas, é UM ponto. Com {F5-01}, a casca nasce com o aviso e o placar passa de 2 de 4 pontos servidos para 3 de 4, medido no fechamento do card; o quarto ponto continua sendo o pacote de exportação ({F8-09}). As abas de exame, prescrição e reabilitação nascem DENTRO da casca, nos cards {F5-04}, {F5-05} e {F5-06}, e o verificador reprova aba clínica fora dela. Nada é marcado: este card continua [ ] e o placar vigente continua 2 de 4.

Fechamento parcial (Inspeção, {F5-01}, 2026-10-01): a casca de /saude nasceu em produção (merge 9cb16f3) com o aviso de natureza não clínica no topo e o texto vigente da tabela de textos, e o verificador verificar:aviso-nao-clinico classifica o ponto telas_clinicas como servido. O placar passa de 2 de 4 pontos servidos para 3 de 4: termos do cadastro, cadastro do profissional e topo das telas clínicas; falta o pacote de exportação ({F8-09}). O card permanece [ ].

Nota (Inspeção, {F5-02}, 2026-10-06): o placar não se move em {F5-02}, e placar que não muda também se declara. A aba Avaliações nasce dentro da casca de /saude, que já traz o aviso no topo desde {F5-01}; o ponto telas_clinicas continua um só. Segue 3 de 4 pontos servidos. O card permanece [ ].

Nota (Inspeção, gate {F5-04}, Drift 6, 2026-10-06): o placar não se move em {F5-04}, e placar que não muda também se declara. A aba Exames nasce dentro da casca de /saude, que já traz o aviso no topo desde {F5-01} (Drift 7 de {F5-01}: a aba dentro da casca não é um ponto novo); o ponto telas_clinicas continua um só. Segue 3 de 4 pontos servidos. O card permanece [ ].

Nota (Inspeção, {F5-04}, 2026-10-06): fechamento medido: o placar não se moveu em {F5-04}, e placar que não muda também se declara. A aba Exames nasceu dentro da casca de /saude, com o aviso no topo em todas as telas conferidas pelo qa, sem ponto novo. Segue 3 de 4 pontos servidos; falta o pacote de exportação ({F8-09}). O card permanece [ ].

Cobre: RF-EXER-002.

Como testar: abrir na execução um exercício com imagem e vídeo e outro sem mídia, medindo a proporção renderizada da imagem. Técnica: comparar a proporção do retângulo renderizado, obtida por getBoundingClientRect() (fracionário, nunca clientWidth, que arredonda para inteiro e fabrica reprovação falsa em imagem pequena), com naturalWidth/naturalHeight do próprio elemento, tolerância 0,5 por cento; e, na lista, conferir que o encaixe é contain em vez de medir o retângulo da miniatura, que é 4 por 3 por desenho.

Passa quando: a proporção renderizada é igual à proporção natural do arquivo, o vídeo aparece embutido e reproduzível e o exercício sem mídia não altera a altura dos demais elementos.

Nota (R-10, {F2-02}): o Como testar exige a imagem e o vídeo na execução, e a execução da sessão é {F3-05}. Placar honesto: 1 de 2 pontos de exibição (tela do exercício servida em {F2-02}; execução da sessão pendente em {F3-05}). Este teste segue aberto.

Cobre: RF-EXER-005.

Como testar: com sete exercícios sem mídia, acionar a geração em lote, conferir o catálogo antes de qualquer aprovação, aprovar duas prévias e rejeitar cinco; depois acionar a geração individual num exercício que já tem mídia.

Passa quando: são produzidas sete prévias, nenhum exercício teve a mídia alterada antes da aprovação, exatamente dois passam a ter mídia, os cinco rejeitados voltam a constar na lista de exercícios sem mídia, e o exercício que já tinha mídia não entra no lote sem escolha individual.

Cobre: RF-TREI-006.

Como testar: concluir uma série num exercício com sessenta segundos de descanso, ajustar o tempo durante a contagem e conferir que o alvo e a barra acompanham, deixar chegar a zero e, em outra série, pular.

Passa quando: a contagem começa em sessenta e decresce; ao zerar emite o aviso e libera a série seguinte, e o aviso existe também sem som, com mudança visível na tela e texto anunciável, não apenas o beep; o ajuste aumenta o tempo restante sem estourar a barra e sem reiniciar a contagem; e o botão de pular encerra imediatamente.

Nota (gate {F3-06}, 2026-09-15): quatro cláusulas reconciliadas com a Descrição de RF-TREI-006, que cobra também o ajuste do tempo na hora e não apenas o H1. Fecha [x] só quando as quatro passarem no smoke. Atualização do gate de qa (2026-09-15): três cláusulas fecharam com dado real em https://fit.modulareasy.com (começa em sessenta e decresce; o ajuste +15 s soma sem estourar a barra nem reiniciar a contagem; o botão de pular encerra imediatamente). A quarta cláusula (zerar, emitir o aviso e liberar a série seguinte, com a metade de acessibilidade sem som) fechou só a metade sonora, medida pela mudança de role="status" e pelo retorno do bloco de registro; a metade de acessibilidade (mudança visível e texto anunciável confirmados sem áudio, com volume zero e leitor de tela) não foi testada isoladamente nesta rodada. Por isso o card continua [ ].

Cobre: RF-TREI-007.

Como testar: executar o mesmo exercício em duas sessões com cargas diferentes, registrar na mesma sessão um exercício só por tempo, depois executar um exercício inédito, e abrir o histórico pelos dois papéis, o aluno titular e um profissional vinculado, este com o aluno na consulta, tentando também com um profissional sem vínculo.

Passa quando: o histórico exibe a variação exata entre as duas cargas; o exercício inédito aparece marcado como primeira medição, sem variação; a linha da sessão exibe data, ficha, duração e volume conferindo com a sessão executada; o profissional vinculado vê o mesmo histórico do aluno e quem não tem vínculo não vê nada; e o exercício registrado só por tempo aparece sem chip de variação e sem zero, cálculo não exibido e nunca em zero, conforme RN-004.

Nota (gate {F3-07}, 2026-09-15): seis cláusulas acrescentadas. O texto anterior cobria duas das oito obrigações do requisito, a variação entre duas cargas e a marcação de primeira medição, e deixava de fora a linha da sessão com data, ficha, duração e volume, que é a primeira frase da Descrição e são quatro dos cinco elementos que o Apêndice de telas declara para /treinos/historico; a leitura pelo Profissional, que é o segundo ator declarado do requisito, do Apêndice de telas e da jornada dele; e o exercício só por tempo, que é a linha legítima em que a comparação não existe e não pode virar zero. Fecha [x] só quando as oito passarem no smoke com dado real. {TA-06} não cresce, e isso se declara para que ninguém suponha que ninguém olhou: nenhuma das entidades do modelo de dados nasce neste card.

Nota de fechamento (gate {F3-07}, 2026-09-15): gate de qa rodada 2 (.claude/gates/qa/modularfit-F3-07.gate) aprovado, com prova real em produção 07cfe0b: BUG-01 corrigido, espaço no chip da família .mf-etiqueta, confirmado desktop claro e mobile escuro; a variação exata entre cargas, chip verde mais cinco quilogramas, a marcação de primeira medição, chip laranja, e o exercício só por tempo sem chip, quinto estado que não nasce, confirmados com conta real em mobile 375 escuro e desktop claro; a sessão abandonada fora da lista confirmada; a barra de resumo, contagem de sessões e soma de volume, conferida contra a soma das linhas. Duas das cinco cláusulas do card não têm evidência no gate de qa: nenhuma citação à leitura pelo profissional vinculado nem à negativa a quem não tem vínculo, e nenhuma conferência linha a linha de data e ficha por sessão, só a soma de volume da barra de resumo foi conferida. Card continua [ ] até as duas lacunas fecharem numa próxima rodada de qa.

Cobre: RF-TREI-008.

Como testar: salvar dois objetivos, o nível intermediário, cinco equipamentos, três dias e sessenta minutos, com texto real nos dois campos longos, limitações e lesões e observações, e reabrir; tentar salvar sem objetivo e sem nível; tentar duração fora da faixa de 20 a 120 e duração que não seja múltipla de 5; tentar um valor fora das listas fechadas; desmarcar todos os equipamentos e todos os dias e salvar; e abrir a tela pelos dois papéis, o aluno titular e um profissional vinculado com o aluno na consulta, mais um profissional sem vínculo.

Passa quando: os cinco valores do H1 persistem e voltam exatamente como foram escolhidos; os dois textos voltam idênticos, caractere por caractere, com acento e quebra de linha, e o teto de 2000 caracteres é recusado tanto pela tela quanto pelo servidor; salvar sem objetivo ou sem nível é recusado por campo, com a mensagem no campo certo; valor fora da lista fechada e duração fora da faixa ou fora do passo são recusados; desmarcar tudo é aceito e ao reabrir os dois campos aparecem vazios, sem zero e sem traço; o profissional vinculado enxerga exatamente os mesmos valores e não consegue alterá-los, nem pela tela nem pela rota; e o profissional sem vínculo não enxerga nada.

Nota (gate {F3-08}, Drift 6, 2026-09-15): cinco cláusulas acrescentadas. O texto anterior cobria duas obrigações do requisito, a persistência dos cinco valores do H1 e a leitura pelo profissional vinculado, e deixava de fora justamente limitacoes e observacoes, os dois campos de 2000 caracteres do formulário, que nem apareciam no "Como testar"; a obrigatoriedade de objetivos e de nível, que o Apêndice declara por campo; a faixa e o passo da duração; a recusa de valor fora da lista fechada; e o lado negativo do profissional, que o requisito implica ao dizer "o profissional vinculado" e que a política do banco é quem garante. Fecha [x] só quando as sete passarem no smoke com dado real, e o teste dos textos longos usa 2000 caracteres de verdade, nunca a palavra "teste".

Nota (gate de qa {F3-08}, rodada 2 PASS, 2026-09-15): duas das cinco cláusulas acrescentadas estão provadas ao vivo nesta rodada, a recusa por campo de objetivo e de nível ausentes (422, mensagem no campo certo) e a ausência de leitura ao profissional sem vínculo (404). As outras três seguem sem prova ao vivo nesta rodada: os dois textos de até 2000 caracteres idênticos com o teto recusado tanto pela tela quanto pelo servidor; o valor fora da lista fechada e a duração fora da faixa ou fora do passo recusados; e desmarcar todos os equipamentos e todos os dias, salvar e reabrir vazio. O card continua [ ] até as sete passarem.

Cobre: RF-SAUD-006.

Como testar: registrar sessão com dor antes sete, depois três, preenchendo tratamento realizado, exercícios realizados, notas de amplitude, notas de progresso e plano da próxima sessão; abrir o painel do fisioterapeuta; registrar outra sessão só com os obrigatórios; tentar registrar dor onze.

Passa quando: a primeira aparece com variação de menos quatro e os cinco campos legíveis no detalhe, o plano da próxima sessão aparece no painel, a segunda salva exibindo só o preenchido, sem campo vazio na tela, e a dor onze é recusada na validação do campo.

Nota (Inspeção, gate {F5-06}, Drifts 1, 5, 6 e 9, 2026-10-06): o caso prova, além do H1, o que o gate decidiu. (1) Com dor antes sete e dor depois três, a variação mostrada é menos quatro, com o rótulo acessível "menos 4 pontos", e o detalhe traz os cinco textos do cenário (os "cinco campos" do caso são os cinco do cenário; o sexto texto é a observação, opcional, como na Nota de RF-SAUD-006). (2) O plano da próxima sessão aparece no painel do Fisioterapeuta como a ação seguinte daquele paciente, e só o da ÚLTIMA sessão ativa: depois de uma sessão mais nova sem plano, o plano antigo não sobe. (3) A sessão registrada só com os obrigatórios (região, tratamento realizado, dor antes, dor depois, duração e data) salva, e o detalhe omite os campos vazios, sem "Não informado". (4) São recusadas: dor 11, dor menos 1, duração 301, duração 0, data dois dias à frente (a mesma folga de fuso dos demais formulários de data) e byte nulo nos textos. (5) Quem grava: o Fisioterapeuta com vínculo ativo, e o aluno para si, com a especialidade do autor nula; Personal Trainer, Médico e Nutricionista são recusados, e o Administrador recebe 403. (6) Consentimento da categoria sessão de reabilitação: ausente, revogado e restrito a outra especialidade recusam, cada um com o par positivo. (7) Desativar só pelo autor ou pelo Super Administrador, e não existe rota de edição. (8) Os painéis de Personal, Médico e Nutricionista seguem idênticos. O cartão continua [ ], e os Betas seguem [ ].

Cobre: RF-SAUD-007.

Nota (Inspeção, reconciliação, 2026-09-30): a medida corporal é da categoria avaliação física de RF-CORE-010; o caso inclui registrar a primeira medida sem esse consentimento (bloqueado, sem linha gravada, com a tela de consentimento) e depois com ele, e o profissional sem o consentimento negado na leitura.

Como testar: registrar duas medições de peso diferentes e abrir o gráfico.

Passa quando: a variação exibida é a diferença exata e o gráfico tem dois pontos na série de peso ordenados por data.

Cobre: RF-SAUD-008.

Como testar: enviar duas fotos de frente em datas diferentes e uma de costas, abrir a comparação em cada categoria e acessar o endereço direto do arquivo sem assinatura.

Passa quando: a galeria agrupa por categoria, a comparação de frente oferece apenas as duas de frente e as exibe lado a lado com as datas, a categoria de costas com uma foto exibe comparação indisponível sem erro, e o endereço direto retorna acesso negado.

Cobre: RF-SAUD-009.

Como testar: acessar sem sessão o endereço direto de uma mídia de exercício e de um anexo de exame, e usar um endereço assinado expirado.

Passa quando: a mídia responde conteúdo, o exame responde acesso negado e o endereço assinado deixa de funcionar após a validade configurada.

Depende de: F1-01 prova o mecanismo (público responde, privado nega, assinatura expira) com arquivo semente; este teste só fecha em F5-08, quando existe anexo de exame real.

Nota (R-12, {F2-02}): o lado público deste teste passa a ter objeto real de mídia de exercício a partir de {F2-02}, em vez de apenas a semente de marca; o caso "endereço direto sem sessão responde conteúdo" deve ser reexecutado contra uma imagem de exercício real.

Cobre: RF-SAUD-010.

Como testar: acionar a explicação num exame, numa prescrição, numa anamnese e numa sessão de reabilitação do mesmo aluno, e depois gerar de novo em um deles.

Passa quando: os quatro oferecem o acionamento e exibem o texto formatado com o aviso, o conteúdo original de cada um permanece intacto, e a segunda geração substitui apenas a explicação daquele registro, sem tocar nos outros três.

Cobre: RF-COMU-001.

Como testar: enviar mensagem num vínculo ativo e tentar abrir a conversa com um profissional não vinculado.

Passa quando: a mensagem aparece para os dois com autor e horário e o não vinculado não consegue abrir nem listar a conversa.

Cobre: RF-COMU-002.

Como testar: enviar mensagem na conversa profissional de um aluno com dois profissionais vinculados, e tentar abri-la como aluno e como terceiro profissional.

Passa quando: o outro profissional recebe, o aluno não enxerga a conversa em nenhuma tela e o terceiro não consegue abri-la.

Cobre: RF-COMU-003.

Como testar: mencionar um dos três profissionais no grupo e depois encerrar o vínculo de um deles.

Passa quando: todos recebem a mensagem, só o mencionado recebe a notificação de menção, e o profissional com vínculo encerrado para de receber mensagens novas mantendo o histórico do período.

Cobre: RF-COMU-004.

Como testar: tentar anexar arquivo em cada um dos três tipos de conversa e enviar uma mensagem com endereço de internet.

Passa quando: os três anexos são bloqueados com a mensagem indicando a tela própria e o endereço vira link clicável.

Cobre: RF-COMU-005.

Como testar: acumular doze notificações, limpar todas, e receber cinco mensagens seguidas da mesma conversa.

Passa quando: a contagem vai a zero sem recarregar e as cinco mensagens aparecem como uma notificação agrupada com contador cinco.

Cobre: RF-COMU-006.

Como testar: com dois navegadores na mesma conversa, enviar de um e cronometrar no outro.

Passa quando: a mensagem aparece em até três segundos sem recarregar e o contador do sino é incrementado na mesma janela.

Cobre: RF-ENGA-001.

Como testar: abrir o painel recém-cadastrado, cumprir um passo e depois cumprir os quatro.

Passa quando: os quatro aparecem desmarcados, o cumprido é marcado sem ação manual e com os quatro cumpridos o bloco deixa de ser exibido.

Cobre: RF-ENGA-002.

Como testar: simular sessões em três dias consecutivos e depois dois dias sem sessão.

Passa quando: a sequência exibe três no dia seguinte sem treino e zero após o segundo dia sem sessão, e uma sessão abandonada no período não conta.

Cobre: RF-ENGA-003.

Como testar: ter sessões em quatro dias distintos dentro da janela e uma fora dela.

Passa quando: exatamente quatro casas aparecem preenchidas nas datas corretas e a sessão fora da janela não aparece, e uma sessão abandonada no período não conta.

Cobre: RF-ENGA-004.

Como testar: concluir a décima sessão de um aluno com nove e depois concluir mais duas.

Passa quando: a conquista de dez é concedida com a data de hoje e notificada, e não é concedida de novo nas sessões seguintes, e uma sessão abandonada no período não conta.

Cobre: RF-ENGA-005.

Como testar: escolher um exercício com cinco sessões e depois um nunca executado.

Passa quando: a série tem cinco pontos ordenados por data com a carga máxima de cada sessão e o exercício inédito exibe o estado vazio sem erro.

Cobre: RF-ENGA-006.

Como testar: com o conjunto de cinco campos configurado e só a altura preenchida, abrir o painel; usar o atalho de cada faltante; preencher um a um até os cinco.

Passa quando: exibe vinte por cento e os quatro faltantes nominalmente, cada atalho leva ao campo correspondente, ao preencher a data de nascimento passa a quarenta por cento e o campo sai da lista, e com os cinco preenchidos exibe cem por cento e o bloco deixa de ser exibido.

Cobre: RF-IAGE-001.

Como testar: acionar a geração para um aluno com cinco equipamentos declarados e conferir cada exercício proposto contra o catálogo.

Passa quando: todos os exercícios propostos existem no catálogo, são compatíveis com os equipamentos declarados e a duração respeita a preferência.

Cobre: RF-IAGE-002.

Como testar: acionar para um aluno com meta de duas mil calorias, quatro refeições e uma restrição alimentar declarada.

Passa quando: a proposta traz quatro refeições, o somatório fica dentro de mais ou menos dez por cento da meta e nenhum alimento restrito aparece.

Cobre: RF-IAGE-003.

Como testar: gerar, conferir a base antes de salvar, editar e salvar; repetir descartando.

Passa quando: nenhum registro existe antes de salvar, o registro salvo contém exatamente o conteúdo editado e o descarte não cria registro.

Cobre: RF-PAIN-001.

Como testar: abrir com dados reais em 375 pixels de largura, com e sem sessão em andamento, e depois com um aluno sem nenhum registro.

Passa quando: os blocos aparecem empilhados sem rolagem horizontal, o bloco de treino é o primeiro da pilha, acima de nutrição, medidas, sequência, calendário, conquistas e completude, o atalho de retomar ocupa o topo do bloco de treino quando há sessão em andamento, e cada bloco exibe dado real ou o próprio estado vazio, nunca valor de exemplo.

Cobre: RF-PAIN-002.

Como testar: abrir com quatro alunos vinculados e uma solicitação aberta, existindo alunos de outro profissional na base.

Passa quando: vê os quatro e o indicador de uma solicitação, e nenhum aluno de outro profissional aparece.

Cobre: RF-PAIN-003.

Como testar: abrir com três pacientes com registros nos últimos sete dias.

Passa quando: os três aparecem com aderência do período e plano vigente, e o painel exibido é o da especialidade nutricional.

Cobre: RF-PAIN-004.

Como testar: abrir com um exame enviado ontem por um paciente vinculado e outro por paciente sem vínculo ativo.

Passa quando: o do vinculado aparece com nome e data e o do não vinculado não aparece.

Cobre: RF-PAIN-005.

Como testar: abrir com um paciente com três sessões na mesma região, a última com plano da próxima sessão preenchido, outro paciente cuja última sessão não trouxe plano e outro sem sessão há mais de trinta dias.

Passa quando: a curva de dor da região tem os três pontos na ordem das datas, o plano da próxima sessão aparece sem abrir o detalhe, o paciente sem plano aparece sem esse trecho em vez de campo vazio, e o terceiro aparece marcado como sem sessão recente.

Cobre: RF-PAIN-006.

Como testar: com um aluno de oito dias sem atividade, outro de dois, e um terceiro cuja única atividade nos últimos oito dias foi uma atividade externa sincronizada, abrir o painel, registrar atividade no primeiro e reabrir.

Passa quando: só o primeiro aparece na lista, o terceiro não aparece por ter atividade externa dentro da janela, e após a atividade o primeiro sai da lista na abertura seguinte.

Cobre: RF-PAIN-007.

Como testar: comparar cada indicador com a contagem na base e criar um usuário novo.

Passa quando: cada indicador é igual à contagem correspondente e o total sobe em um na abertura seguinte.

Cobre: RF-PAIN-008.

Como testar: exportar o relatório de atividade de trinta dias e comparar com a tela.

Passa quando: o arquivo tem exatamente as mesmas linhas do mesmo período e o total do rodapé é igual à soma da coluna.

Cobre: RF-PAIN-009.

Como testar: criar um profissional com especialidade médica, entrar com ele, aplicar o bloqueio administrativo e tentar entrar, remover o bloqueio e entrar de novo; em paralelo, marcar um aluno com status de acesso inativo por plano, sem bloqueio, e tentar entrar com ele.

Passa quando: o profissional entra com a senha inicial e cai no painel clínico, o bloqueio nega a entrada com a mensagem de conta bloqueada pela administração, diferente da mensagem de conta inativa por plano, o registro guarda quem bloqueou e quando, removido o bloqueio ele entra sem senha nova, e o aluno com acesso inativo continua entrando e alcançando perfil, plano e leitura do histórico.

Cobre: RF-PAIN-010, RF-CORE-008.

Como testar: nas quatro listas (treinos, histórico, usuários e exercícios), selecionar todas as linhas de um filtro que exibe doze e aplicar a ação; repetir com aluno e com profissional tentando a exclusão em definitivo; repetir com um registro fora do alcance do papel dentro da seleção.

Passa quando: exatamente doze registros são alterados, a contagem informada é doze, existem doze entradas de auditoria, a exclusão em definitivo não é oferecida nem aceita para aluno e profissional nos doze, e a seleção com registro fora de alcance recusa aquele registro, conclui os demais e informa afetados e recusados.

Cobre: RF-INTE-001.

Como testar: importar um arquivo com dez atividades e reimportar o mesmo arquivo.

Passa quando: dez registros são criados e aparecem no calendário marcados com a origem, e a reimportação mantém dez.

Cobre: RF-INTE-002.

Como testar: exportar os dados de um aluno com registros em todas as categorias e comparar as contagens.

Passa quando: cada categoria tem no pacote o mesmo número de registros da base, os anexos estão presentes e o pacote traz o aviso de natureza não clínica.

Cobre: RF-INTE-003.

Como testar: conectar um serviço habilitado até o fim; abandonar outra autorização no meio; inspecionar as respostas da aplicação procurando a credencial; desconectar e disparar a sincronização.

Passa quando: a conta aparece conectada com data e permissões, a sincronização seguinte cria as atividades do período, a autorização abandonada não cria conta, a credencial não aparece em nenhuma resposta ao navegador nem em registro de log, e após desconectar nenhuma sincronização ocorre e as atividades já importadas continuam no histórico.

Cobre: RF-INTE-004.

Como testar: com um serviço que tem doze atividades no período, rodar a sincronização duas vezes; acrescentar uma atividade no serviço e rodar de novo; revogar a autorização do lado do serviço e rodar mais uma vez.

Passa quando: a primeira execução cria doze registros com a origem nomeando o serviço, a segunda mantém doze, a terceira passa a treze, e após a revogação a conta fica no estado que exige nova autorização, o aluno é notificado e os treze registros permanecem.

Cobre: RF-INTE-005, RN-005, RN-006.

Como testar: num mesmo dia, concluir uma sessão no sistema e trazer duas atividades externas; abrir o calendário como aluno e o acompanhamento como profissional vinculado; conferir a sequência de dias; e, num segundo aluno, deixar a atividade externa como única atividade dos últimos oito dias e abrir a lista de inativos.

Passa quando: as três aparecem no dia identificadas pela origem, a externa não é exibida como sessão do sistema, a sequência conta apenas a sessão do sistema (RN-005), o profissional enxerga as três, e o segundo aluno não aparece na lista de inativos, porque a atividade externa é a quarta fonte de RN-006.

Cobre: RF-CORE-013, ADR-014, ADR-015, RF-CORE-009.

Como testar: com um usuário de e-mail A, pedir a troca para B com a senha correta; tentar entrar com B antes de confirmar; abrir o endereço de confirmação; tentar entrar com A e com B; reabrir o endereço de confirmação; repetir o pedido com senha errada, com um B já usado por outra conta e com um B inválido; conferir a caixa de A e a auditoria.

Passa quando: antes da confirmação só A entra; depois só B entra; A recebeu o aviso; a auditoria tem autor, A e B; o endereço reaberto ou vencido não tem efeito; os três pedidos inválidos são recusados e nenhum e-mail sai da fila para eles.

Cobre: RF-COBR-001.

Como testar: registrar o acordo como profissional e tentar criá-lo e editá-lo como aluno.

Passa quando: o acordo consta no vínculo e é visível ao aluno, e as tentativas do aluno são negadas.

Cobre: RF-COBR-002.

Como testar: com acordo mensal iniciado há três meses, abrir a cobrança; repetir com acordo cujo dia de vencimento não existe no mês.

Passa quando: existem exatamente três competências com o valor do acordo, nenhuma de mês futuro, e no mês sem o dia contratado o vencimento cai no último dia do mês.

Cobre: RF-COBR-003.

Como testar: marcar uma competência vencida como paga e conferir o total em aberto e a auditoria.

Passa quando: o total em aberto diminui exatamente no valor da competência e a marcação consta na auditoria com autor e momento.

Cobre: RF-COBR-004.

Como testar: abrir a cobrança de um aluno com acordos de dois profissionais.

Passa quando: aparecem dois blocos com acordo e competências e o total em aberto é igual à soma das competências em aberto.

Cobre: RF-AJUD-001.

Como testar: publicar um guia do módulo de treino com conteúdo distinto para Aluno e para Personal Trainer, abrir com os dois papéis, conferir a entrada no menu dos seis papéis e abrir um módulo sem guia para aquele papel.

Passa quando: cada papel lê o conteúdo publicado para ele com os sete blocos presentes, a entrada do guia aparece no topo do menu dos seis papéis, e o módulo sem guia exibe o estado vazio nomeando o módulo, sem erro e sem conteúdo de outro papel.

Cobre: RF-AJUD-002.

Como testar: publicar a versão 1, editar em rascunho e conferir o que o leitor enxerga, publicar a versão 2, consultar o histórico, restaurar a versão 1 e tentar escrever no guia com cada papel que não é administrador.

Passa quando: a versão 2 nasce com data e autor e é a que os leitores enxergam, a versão 1 continua consultável com o conteúdo original, o rascunho nunca aparece ao leitor, restaurar a versão 1 cria a versão 3 sem apagar a 2, e toda escrita por papel diferente de administrador é negada.

Cobre: RF-AJUD-003.

Como testar: acionar a geração para um módulo sem guia, conferir a base antes de publicar, editar dois blocos e publicar; repetir descartando a prévia.

Passa quando: a prévia traz os sete blocos, nenhuma versão existe no banco antes da publicação, a versão criada contém exatamente o conteúdo revisado e o descarte não cria versão nenhuma.

Cobre: todas as telas do catálogo do DRS.

Como testar: abrir cada tela do catálogo em 375 e em 1440 pixels, nos temas claro e escuro, com dado real e no estado vazio, registrando imagem, incluindo a página inicial pública sem sessão e as três telas do guia.

Passa quando: nenhuma tela apresenta rolagem horizontal, texto cortado, contraste insuficiente ou imagem fora da proporção natural medida.

Nota (R-12, {F2-02}): a técnica e a tolerância de "imagem fora da proporção natural medida" são as de {TA-21}: getBoundingClientRect() contra naturalWidth/naturalHeight, tolerância 0,5 por cento, nunca clientWidth.

Cobre: RF-CORE-006, RF-CORE-007, D.2 e a matriz de capacidade.

Como testar: para cada papel, tentar cada capacidade marcada como negada na matriz do DRS, incluindo acesso por identificador direto e por endereço de arquivo. (R-9, {F1-19}): consultar o perfil de outro usuário como aluno, como profissional vinculado, como profissional sem vínculo e como Administrador, conferindo campo a campo a resposta contra os quatro públicos e os oito privados de D.2, e tentando também por consulta direta à tabela com o papel de aplicação. (R-1, {F2-02}): medir os cabeçalhos de resposta da aplicação com o servidor web da frente fora do caminho (requisição direta ao container), derrubando o vhost do caminho para provar que os cabeçalhos continuam saindo da aplicação.

Passa quando: toda capacidade negada na matriz é negada no sistema, sem exceção, e nenhuma negação depende apenas de o botão estar escondido. E, para o critério de {F2-02}, os cinco cabeçalhos de segurança (X-Content-Type-Options, X-Frame-Options, Referrer-Policy, Permissions-Policy, Content-Security-Policy) continuam presentes na resposta mesmo com o servidor web da frente fora do caminho.

Cobre: D.1 e D.4.

Como testar: medir as cinco linhas da tabela de desempenho com o volume de referência de D.4, três execuções e mediana.

Passa quando: as cinco ficam dentro do alvo declarado.

Cobre: RF-PAIN-001 e F.1.

Como testar: percorrer no celular o cadastro, a execução completa de uma sessão, o registro de refeição, o registro de medida e o chat.

Passa quando: os cinco fluxos completam sem zoom, sem rolagem horizontal e com alvos de toque acionáveis com o polegar.

Cobre: o escopo já entregue.

Como testar: ao fim de cada fase, reexecutar todos os cards Alfa das fases anteriores.

Passa quando: nenhum card anteriormente aprovado passa a falhar.

Cobre: as jornadas de todos os papéis do documento de Jornadas.

Como testar: percorrer cada jornada de cada papel na aplicação real, executando de verdade e conferindo o resultado no banco e na tela.

Passa quando: toda jornada completa de ponta a ponta com resultado observado, com tabela mostrando dado real, botão executando e formulário persistindo.

Cobre: F.1.

Como testar: a partir de cada tela alcançada nas jornadas, voltar usando apenas a interface.

Passa quando: toda tela tem caminho de volta pela própria interface, sem depender do botão de voltar do navegador nem de digitar o endereço de novo.

Cobre: a matriz de capacidade do DRS.

Como testar: para cada papel, exercitar todas as capacidades marcadas como permitidas na matriz.

Passa quando: cada papel consegue executar tudo que a matriz permite a ele, sem depender de outro papel para uma tarefa que é dele.

Cobre: RF-CORE-007 na parte que declara a fronteira de dado clínico, mais RF-PAIN-009, RF-PLAN-001, RF-PLAN-002, RF-CORE-008 e RF-CORE-009 na parte que separa Super Administrador de Administrador; card {AUD-04} do Roadmap.

Como testar: contar, antes da migração, as contas por papel e guardar a lista; rodar a migração e recontar. Criar uma conta de Administrador de teste. Entrar com ela e exercitar, uma a uma, as capacidades privativas de governança de B.1 que já têm rota no sistema nesta data: atribuir plano e status de acesso, escrever na tela de planos, excluir em definitivo e abrir a trilha de auditoria. As outras três das sete não têm rota nenhuma e por isso não se provam aqui pela interface: bloquear e desbloquear conta e promover ou rebaixar papel nascem em {F7-14} e personificar nasce em {AUD-05}; a negação das duas primeiras se prova hoje no banco, pelo gatilho de governança que {AUD-04} instala. Depois, com a mesma conta, pedir leitura e escrita em cada uma das capacidades da fronteira de dado clínico cuja entidade já exista no sistema, com dado criado por outra conta antes de pedir, para que negado e vazio não se confundam. A fronteira tem quatorze capacidades, dez por classificação e quatro por conteúdo (conversa com vinculado, conversa entre profissionais, serviço de atividade e geração assistida), e cada uma só pode ser exercitada depois que a entidade dela nascer: nesta data nenhuma nasceu, e a Nota de placar parcial abaixo nomeia o card dono de cada uma. Pedir também a leitura das preferências de treino, que ficam com ele, esperando sucesso: sem esse controle negativo o card provaria apenas que a conta é fraca, e não que a fronteira é a lista de B.1. Cada tentativa se faz pela interface e, quando o controle não aparece, também pela rota direta, porque esconder não é negar. Depois exercitar as rotas de administração comuns que já existem, quatro das sete (/admin, /admin/exercicios, /admin/vinculos e /admin/textos), mais a leitura da tela de planos e a operação do dado não clínico de um aluno, esperando sucesso; as três que faltam nascem nos cards donos, /admin/usuarios em {F7-14}, /admin/relatorios em {F7-13} e /admin/guia em {F9-03}.

Passa quando: 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 a contagem de cada um dos demais papéis é igual à de antes da migração, E o Administrador de teste é negado nas capacidades privativas de governança que já têm rota, pela interface e pela rota direta, fechando 4 de 7, com as três restantes 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 no banco pelo gatilho de governança, E é negado em leitura e em escrita nas capacidades da fronteira cuja entidade já existe, com dado criado por outra conta antes de pedir, fechando o placar parcial que a Nota deste cartão declara, e que nesta data é 0 de 28 porque nenhuma das quatorze entidades da fronteira existe ainda, E alcança as rotas comuns que já existem, a leitura de planos, o dado não clínico de um aluno e as preferências de treino dele, 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 este cartão permanece aberto até o último dos três cards donos fechar, no mesmo tratamento que {TA-06} e {TA-08} já recebem.

Nota de placar parcial (onda AUD, {AUD-04}, 2026-09-15): este cartão tem três placares, e os três nascem parciais por aritmética, não por preguiça. Governança, 4 de 7: existem atribuir plano e status de acesso, escrever na tela de planos, excluir em definitivo e consultar a trilha de auditoria; faltam bloquear e desbloquear conta e promover ou rebaixar papel, de {F7-14}, e personificar, de {AUD-05}, e a negação das duas primeiras já se prova no banco pelo gatilho de governança de {AUD-04}. Lado positivo, 7 de 10: existem /admin, /admin/exercicios, /admin/vinculos e /admin/textos, mais a leitura de planos, o dado não clínico de um aluno e as preferências de treino dele; faltam /admin/usuarios de {F7-14}, /admin/relatorios de {F7-13} e /admin/guia de {F9-03}. Fronteira de dado clínico, 0 de 28 nesta data, porque nenhuma das quatorze entidades existe: preencher anamnese é {F5-01}; registrar avaliação física é {F5-02}; registrar medida corporal é {F5-07}; enviar foto de progresso é {F5-08}; registrar exame é {F5-04}; registrar prescrição é {F5-05}; registrar sessão de reabilitação é {F5-06}; registrar refeição é {F4-01}; definir meta nutricional é {F4-02}; criar plano alimentar é {F4-03}; conversar com vinculado é {F6-01}; conversar entre profissionais do mesmo aluno é {F6-02}; conectar e desconectar serviço de atividade é {F8-13}; e acionar geração assistida de treino, dieta e explicação é {F8-06}, {F8-07} e {F5-10}, sobre a camada de {F8-05}. Cada capacidade entra no placar no card que cria a entidade dela, pela política de acesso por linha e não só pela guarda de rota, e este cartão permanece [ ] até o último dos donos fechar. Medido em 2026-09-15 no roadmap publicado: zero cards marcados nas Fases 4, 5, 6 e 8, que é o que sustenta o 0 de 28 e o que o torna falseável, porque basta um card daqueles fechar para o número subir. Confirmação de fechamento [2026-09-15]: os placares de governança (4 de 7) e do lado positivo (7 de 10) estão provados em produção pelo gate de qa de {AUD-04} (retrato super_administrador 3, aluno 1, migrações 0031 a 0033 aplicadas, ops/semear-contas-de-topo.mjs idempotente nas duas rodadas); a fronteira de dado clínico (0 de 28) permanece sem mudança, porque nenhuma das quatorze entidades nasceu.

Fechamento [2026-09-29] de {AUD-05}: o placar de governança sobe de 4 de 7 para 5 de 7. Personificar passou a ter rota e a negação dela foi provada pela rota direta em produção: Administrador, profissional e aluno recebem 403 em POST /api/admin/personificar/:aluno, e o topo recebe 403 ao mirar outro Super Administrador ou a si mesmo, com o par positivo (topo para aluno, profissional e administrador) devolvendo 201. Faltam as duas de {F7-14}, bloquear e desbloquear conta e promover ou rebaixar papel. O lado positivo (7 de 10) e a fronteira de dado clínico (0 de 28) não se movem nesta entrega, porque /admin/usuarios mínima de {AUD-05} é privativa do Super Administrador e não entra no lado positivo do Administrador. O cartão permanece [ ].

Fechamento parcial [2026-09-30] de {F4-01}: a fronteira de dado clínico sobe de 0 de 28 para 2 de 28. Leitura e escrita de refeicao são negadas ao Administrador em produção, com dado criado antes pelo titular e o par positivo no mesmo alvo devolvendo 200; no banco o Administrador lê 0 linhas e o INSERT é negado. Governança (5 de 7) e lado positivo (7 de 10) não se movem. Faltam 26 de 28, nomeadas com os cards donos na Nota de placar parcial acima. O cartão permanece [ ].

Cobre: o bloco B.6 e o Apêndice: Matriz Ator por Capacidade do DRS; ADR-017.

Como testar: contar, na matriz publicada, as células diferentes de N por coluna, e confrontar cada contagem com o comportamento medido no sistema para uma conta de cada papel. A contagem do documento e a medição no sistema são dois caminhos independentes até o mesmo número, e é a coincidência entre os dois que vale; contar só o documento provaria apenas que o documento fecha consigo mesmo.

Passa quando: Dado o documento publicado, Quando se contam as células diferentes de N por coluna nas 48 linhas, Então os números são Super Administrador 41, Administrador 19, Aluno 28, Fisioterapeuta 22, Personal Trainer 21, Médico 19 e Nutricionista 19, E a diferença entre os dois papéis de administração é 22 e não 1 nem 2, E essa diferença se decompõe sem sobra em 8 capacidades privativas de governança mais 14 da fronteira de dado clínico, dez por classificação e quatro por conteúdo, conferidas nominalmente linha a linha e não só pela subtração, E a medição no sistema devolve os mesmos sete números para as capacidades que já existem, E qualquer divergência entre a matriz e o sistema reprova este card sem arredondamento e sem "próximo o bastante". A metade documental deste cartão fechou com {AUD-04} nos números vigentes então (47 linhas, Super Administrador 41, diferença 21, 7 mais 14) e reabre e refecha em {AUD-06}, porque RF-PAIN-011 criou uma oitava capacidade privativa que B.1 ainda não nomeava naquela data; medida de novo por contagem célula a célula no publicado, agora em 48 linhas, Super Administrador 42, diferença 22, 8 mais 14. Reabre e refecha em {AUD-09}, Drift 3 (2026-09-30), porque a linha "Criar ficha de treino" dava T às duas colunas de administração contra os requisitos que a derivam; medida de novo célula a célula, 48 linhas, Super Administrador 41, Administrador 19, diferença 22, 8 mais 14, decomposição inalterada. A medição no sistema só fecha quando o produto fechar, porque a matriz mede 48 capacidades de produto inteiro e a maioria nasce nas Fases 4 a 8, e por isso o cartão permanece aberto com placar parcial declarado em vez de ser marcado no último dia do projeto.

Cobre: a jornada de primeiro uso do Aluno.

Quem testa: aluno real, recém-cadastrado.

Como validar: chega pela página inicial pública, entende para quem é a plataforma, cria a conta, aceita os termos, e a partir do painel tenta chegar ao primeiro treino, criando a própria ficha ou aguardando a do profissional; depois preenche o que quiser do perfil pelo indicador de completude.

Passa quando: completa sem bloqueio por campo opcional, confirma que a página pública deixou claro que o sistema é para treino de musculação acompanhado, chega ao primeiro treino sem ajuda, e confirma que entendeu que o preenchimento do perfil é opcional.

Cobre: a jornada de consentimentos do Aluno.

Quem testa: aluno real.

Como validar: lê as finalidades, concede uma categoria, restringe outra a uma especialidade e revoga uma terceira.

Passa quando: entende o que cada categoria significa, as três ações têm efeito visível e ele confirma que se sente no controle dos próprios dados.

Cobre: a jornada de resposta a convite do Aluno.

Quem testa: aluno real que recebeu um convite.

Como validar: encontra o convite pela notificação, confere quem é o profissional e aceita.

Passa quando: completa sem ajuda e confirma que sabia quem estava aceitando antes de aceitar.

Cobre: a jornada de execução de treino do Aluno.

Quem testa: aluno real, no celular, dentro da academia.

Como validar: executa uma sessão inteira registrando cargas e usando o descanso, com o celular ocioso entre séries, e no meio do treino fecha o aplicativo e retoma pelo atalho.

Passa quando: conclui a sessão sem interromper o treino para entender a tela, não precisa desbloquear a tela a cada série, a retomada traz o que já tinha registrado, e confirma que os números batem com o que fez.

Cobre: a jornada de ficha própria e solicitação do Aluno.

Quem testa: aluno real.

Como validar: monta uma ficha sozinho, duplica uma recebida e envia um pedido de ajuste com motivo.

Passa quando: completa as três ações e entende por que não consegue editar diretamente a ficha do profissional.

Cobre: a jornada de nutrição do Aluno.

Quem testa: aluno real, ao longo de um dia inteiro.

Como validar: registra as refeições do dia e acompanha o que falta para a meta.

Passa quando: registra o dia completo sem abandonar no meio e confirma que os totais fazem sentido.

Cobre: a jornada de evolução do Aluno.

Quem testa: aluno real.

Como validar: registra as medidas, envia a foto escolhendo a pose e compara com a foto anterior da mesma pose e com a medição anterior.

Passa quando: completa, entende por que a comparação acontece dentro da mesma pose, e confirma que consegue ver a própria evolução sem interpretar número solto.

Cobre: a jornada clínica do Aluno.

Quem testa: aluno real, sem profissional daquela especialidade vinculado.

Como validar: preenche a própria anamnese, anexa um exame e aciona a explicação em linguagem simples no exame e na anamnese.

Passa quando: completa sem bloqueio indevido, encontra a anamnese guardada com a data do dia, e confirma que as explicações ajudaram sem parecer diagnóstico.

Cobre: a jornada de comunicação do Aluno.

Quem testa: aluno real com dois profissionais vinculados.

Como validar: conversa com cada um, participa do grupo, envia um link e limpa as notificações.

Passa quando: completa e confirma que as notificações não se acumularam de forma incômoda.

Cobre: a jornada de plano e cobrança do Aluno.

Quem testa: aluno real com acordo registrado.

Como validar: consulta o plano, os limites e o que deve a cada profissional.

Passa quando: encontra as duas informações sem ajuda e entende que o pagamento acontece fora do sistema.

Cobre: a jornada de integrações do Aluno.

Quem testa: aluno real que usa relógio ou aplicativo de corrida.

Como validar: conecta o serviço que já usa, treina fora do sistema e volta no dia seguinte para ver o registro; depois desconecta.

Passa quando: conecta sem ajuda, encontra a atividade dela no calendário identificada pela origem no dia seguinte, entende que aquilo não virou sessão de treino do sistema, e ao desconectar confirma que o histórico não sumiu.

Cobre: a jornada de portabilidade do Aluno.

Quem testa: aluno real com histórico em várias categorias.

Como validar: solicita a exportação e abre o pacote recebido.

Passa quando: recebe o pacote e reconhece os próprios dados nele.

Cobre: a jornada de abertura do dia do Personal Trainer.

Quem testa: personal trainer real com carteira de alunos.

Como validar: abre o painel e decide por quem começar.

Passa quando: identifica em menos de um minuto quem precisa de atenção e confirma que a informação é a que ele usaria.

Cobre: a jornada de vinculação do Personal Trainer.

Quem testa: personal trainer real.

Como validar: busca o aluno e envia o convite.

Passa quando: o vínculo é criado e ele confirma que entendeu por que não vê nada do aluno até o aceite.

Cobre: a jornada de prescrição do Personal Trainer.

Quem testa: personal trainer real.

Como validar: lê preferências e histórico e monta uma ficha completa, manualmente e depois com a geração assistida.

Passa quando: entrega uma ficha que ele daria a um aluno real, e a prévia gerada precisou de ajuste que ele conseguiu fazer.

Cobre: a jornada de solicitação do Personal Trainer.

Quem testa: personal trainer real.

Como validar: recebe a solicitação, lê o motivo e atende criando a ficha.

Passa quando: o ciclo fecha com o aluno notificado e ele confirma que não perderia o pedido de vista.

Cobre: a jornada de avaliação do Personal Trainer.

Quem testa: personal trainer real, com um aluno presente.

Como validar: preenche as seis seções durante a avaliação e compara com a anterior.

Passa quando: preenche no ritmo do atendimento e confirma que os cálculos batem com o que ele faria à mão.

Cobre: a jornada de acompanhamento do Personal Trainer.

Quem testa: personal trainer real.

Como validar: revisa a semana da carteira, olha a progressão de carga e aciona quem parou.

Passa quando: identifica os alunos que precisam de ação e confirma que a leitura de progressão é útil.

Cobre: a jornada de cobrança do Personal Trainer.

Quem testa: personal trainer real.

Como validar: registra o acordo, acompanha as competências e dá baixa numa paga.

Passa quando: o extrato reflete a realidade dele e confirma que substituiu o controle que fazia por fora.

Cobre: a jornada de comunicação do Personal Trainer.

Quem testa: personal trainer real com aluno atendido por outra especialidade.

Como validar: conversa com o aluno e alinha com o outro profissional pela conversa reservada e por menção no grupo.

Passa quando: o alinhamento acontece sem sair do sistema e ele confirma que o aluno não viu a conversa reservada.

Cobre: a jornada de abertura do dia do Médico.

Quem testa: médico real.

Como validar: abre o painel e identifica o que precisa ler e prescrever.

Passa quando: identifica sem ajuda e confirma que a ordem das informações é a que ele usaria.

Cobre: a jornada de vinculação do Médico.

Quem testa: médico real.

Como validar: envia o convite pelo identificador ou pelo nome.

Passa quando: o vínculo é criado e ele confirma que o processo respeita o consentimento do paciente.

Cobre: a jornada de anamnese do Médico.

Quem testa: médico real.

Como validar: abre uma anamnese nova de um paciente que já tinha uma anterior, confere o tronco pré-preenchido, corrige o que mudou e completa a seção clínica; depois abre a anamnese anterior.

Passa quando: não precisa redigitar o que já existia, confirma que a seção clínica cobre o que ele pergunta, e reconhece a anamnese anterior intacta na lista, com a data em que foi coletada.

Cobre: a jornada de exames do Médico.

Quem testa: médico real.

Como validar: abre um exame anexado pelo paciente, registra resumo e observações e aciona a explicação simples.

Passa quando: o anexo abre com qualidade de leitura e ele confirma que a explicação gerada é adequada para entregar ao paciente.

Cobre: a jornada de prescrição do Médico.

Quem testa: médico real.

Como validar: registra uma prescrição completa e confere como o paciente a enxerga.

Passa quando: o registro é suficiente para o acompanhamento e ele confirma que o aviso de não substituição do receituário está claro.

Cobre: a jornada de cobrança do Médico.

Quem testa: médico real.

Como validar: registra o acordo e dá baixa numa competência.

Passa quando: o extrato reflete a realidade dele.

Cobre: a jornada de comunicação do Médico.

Quem testa: médico real.

Como validar: alinha uma conduta com quem treina ou alimenta o paciente, usando menção.

Passa quando: o alinhamento acontece sem sair do sistema e o mencionado responde.

Cobre: a jornada de abertura do dia do Fisioterapeuta.

Quem testa: fisioterapeuta real.

Como validar: abre o painel e identifica os tratamentos que precisam de atenção.

Passa quando: identifica sem ajuda e confirma que a curva de dor é a leitura que ele usaria.

Cobre: a jornada de vinculação do Fisioterapeuta.

Quem testa: fisioterapeuta real.

Como validar: envia o convite e aguarda o aceite.

Passa quando: o vínculo é criado sem dúvida sobre o passo seguinte.

Cobre: a jornada de anamnese do Fisioterapeuta.

Quem testa: fisioterapeuta real.

Como validar: completa a seção funcional sobre o tronco já existente.

Passa quando: os campos cobrem a avaliação inicial dele sem precisar escrever tudo em observações.

Cobre: a jornada de sessão do Fisioterapeuta.

Quem testa: fisioterapeuta real, ao fim de um atendimento.

Como validar: registra região, tratamento realizado, exercícios realizados, notas de amplitude e de progresso, dor antes e depois, duração e o plano da próxima sessão.

Passa quando: registra no tempo do atendimento, a evolução da dor aparece corretamente na sessão seguinte, e ele reencontra no painel o plano que deixou escrito, sem reler a sessão inteira.

Cobre: a jornada de prescrição de exercícios do Fisioterapeuta.

Quem testa: fisioterapeuta real.

Como validar: monta uma ficha terapêutica com exercícios do catálogo e acompanha a execução pelo histórico.

Passa quando: encontra no catálogo os exercícios de que precisa, ou registra nominalmente os que faltam para inclusão.

Cobre: a jornada de cobrança do Fisioterapeuta.

Quem testa: fisioterapeuta real.

Como validar: registra o acordo por sessões e dá baixa nas pagas.

Passa quando: o extrato reflete o modelo de cobrança dele.

Cobre: a jornada de comunicação do Fisioterapeuta.

Quem testa: fisioterapeuta real.

Como validar: comunica ao profissional de treino uma restrição de movimento do paciente.

Passa quando: a restrição chega a quem prescreve e a ficha é ajustada em seguida.

Cobre: a jornada de abertura do dia do Nutricionista.

Quem testa: nutricionista real.

Como validar: abre o painel e identifica quem está fora da meta.

Passa quando: identifica sem ajuda e confirma que a medida de aderência é a que ele usaria.

Cobre: a jornada de vinculação do Nutricionista.

Quem testa: nutricionista real.

Como validar: envia o convite e aguarda o aceite.

Passa quando: o vínculo é criado sem dúvida sobre o passo seguinte.

Cobre: a jornada de anamnese do Nutricionista.

Quem testa: nutricionista real.

Como validar: completa a seção alimentar sobre o tronco já existente.

Passa quando: os campos cobrem a consulta inicial dele, incluindo restrições que depois bloqueiam a geração de dieta.

Cobre: a jornada de metas do Nutricionista.

Quem testa: nutricionista real.

Como validar: define as quatro metas e confere como o paciente as enxerga no painel diário.

Passa quando: as metas valem imediatamente e o paciente entende o que mudou.

Cobre: a jornada de avaliação física do Nutricionista.

Quem testa: nutricionista real, com um paciente presente.

Como validar: registra a avaliação com dobras cutâneas, perímetros e o percentual de gordura pelo método que utiliza, e compara com a avaliação anterior do paciente.

Passa quando: consegue registrar a antropometria completa sem recusa por especialidade, no ritmo do atendimento, e confirma que os cálculos e a comparação servem para ajustar meta e plano.

Cobre: a jornada de plano alimentar do Nutricionista.

Quem testa: nutricionista real.

Como validar: monta o plano manualmente e depois com a geração assistida, editando a prévia.

Passa quando: entrega um plano que ele daria a um paciente real e a prévia gerada respeitou as restrições declaradas.

Cobre: a jornada de acompanhamento do Nutricionista.

Quem testa: nutricionista real, após duas semanas de registros do paciente.

Como validar: consulta médias, dias com meta atingida e evolução de peso, e ajusta o plano.

Passa quando: consegue decidir o ajuste com o que a tela mostra, sem exportar nada.

Cobre: a jornada de cobrança do Nutricionista.

Quem testa: nutricionista real.

Como validar: registra o acordo e dá baixa numa competência.

Passa quando: o extrato reflete a realidade dele.

Cobre: a jornada de comunicação do Nutricionista.

Quem testa: nutricionista real.

Como validar: alinha com quem prescreve o treino o volume e o gasto estimado do paciente.

Passa quando: o alinhamento acontece sem sair do sistema.

Cobre: a jornada de catálogo do Administrador.

Quem testa: operador real da administração.

Como validar: cadastra exercícios novos com mídia, aciona a geração de mídia em lote para os que estão sem, aprova umas e rejeita outras, e desativa vários em desuso pela seleção em massa.

Passa quando: o cadastro é rápido o bastante para uma carga de dezenas de itens, a mídia aprovada aparece correta na tela do aluno, a rejeitada não entra no catálogo, e a contagem da ação em lote confere com o que ele selecionou.

Cobre: a jornada de contas, na parte comum e na parte privativa.

Quem testa: um operador com conta de Administrador e um com conta de Super Administrador.

Como validar: o Administrador cria uma conta, corrige o cadastro, marca um registro como verificado e desativa; o Super Administrador, na mesma tela, promove um papel, bloqueia e desbloqueia uma conta e exclui em definitivo.

Passa quando: as ações comuns completam para os dois e o usuário afetado sente o efeito imediatamente, E o Administrador diz, sem consultar documento nenhum, o que a tela lhe permite e o que ele precisa encaminhar, porque a tela deixou isso claro sozinha.

Cobre: a jornada de planos do Super Administrador.

Quem testa: operador real da plataforma.

Como validar: cria um plano, ajusta um limite operacional, atribui a um aluno e desliga o acesso de outro; depois abre a mesma tela com uma conta de Administrador e confirma que lê sem escrever.

Passa quando: o efeito aparece na sessão seguinte dos alunos e a operação de cobrança por fora do sistema fica viável.

Cobre: a jornada de vínculos do Administrador.

Quem testa: operador real da administração.

Como validar: resolve um caso de suporte filtrando e ajustando um vínculo.

Passa quando: o caso é resolvido pelo próprio painel, sem intervenção técnica.

Cobre: a jornada de relatórios do Administrador.

Quem testa: responsável pelo produto.

Como validar: acompanha um mês de operação pelos relatórios e exporta uma tabela.

Passa quando: responde as perguntas de acompanhamento do produto sem precisar consultar o banco.

Cobre: a jornada de auditoria do Administrador.

Quem testa: operador real da administração.

Como validar: apura quem alterou um registro específico e quando.

Passa quando: chega à resposta pelos filtros disponíveis e vê também os próprios acessos registrados.

Cobre: a jornada de pedido do titular do Administrador.

Quem testa: responsável pela proteção de dados.

Como validar: atende um pedido de exportação e um de eliminação, do início ao registro.

Passa quando: os dois pedidos são atendidos e comprovados, com a auditoria preservada e anonimizada.

Cobre: a jornada de rotinas do Administrador.

Quem testa: operador real da administração.

Como validar: confere por uma semana se as sete rotinas rodaram e reage a uma falha simulada.

Passa quando: identifica a falha pelo registro e pelo alerta, e sabe o que fazer sem depender de acesso técnico.

Cobre: a jornada de manutenção do guia do Administrador.

Quem testa: operador real da administração.

Como validar: percorre a matriz de módulo por papel, escreve um guia, gera outro com a geração assistida e revisa, publica os dois e restaura uma versão anterior.

Passa quando: identifica pela matriz o que está sem guia, publica sem precisar de apoio técnico, confirma que o leitor não viu rascunho e que a versão restaurada não apagou a anterior.

Cobre: a jornada de consulta ao guia, comum aos seis papéis.

Quem testa: um usuário real de cada um dos seis papéis.

Como validar: cada um chega ao guia pelo menu, escolhe o módulo sobre o qual tem dúvida e tenta resolver a dúvida só com o que está escrito ali.

Passa quando: os seis encontram o guia sem ajuda, resolvem a dúvida sem perguntar a outra pessoa e confirmam que o texto fala a língua do papel deles, sem descrever ação que o sistema não permite àquele papel.

Cobre: todas as jornadas.

Quem testa: um usuário de cada papel.

Como validar: cada um percorre as próprias jornadas e relata se ficou preso em alguma tela.

Passa quando: nenhum usuário precisou do botão de voltar do navegador nem digitar endereço para sair de uma tela.

Cobre: N.2.

Quem testa: todos os participantes da etapa.

Como validar: cada um envia retorno pelo canal dentro da aplicação, registrando papel, tela e o que atrapalhou.

Passa quando: existe retorno registrado de todos os seis papéis e a fila foi triada.

Cobre: o resultado dos cartões Beta.

Quem testa: o time do produto com o dono.

Como validar: classificar cada retorno em correção, ajuste de requisito ou fora de escopo, e tratar as correções.

Passa quando: nenhuma correção classificada como bloqueante segue aberta e todo ajuste de requisito foi levado ao DRS antes de virar código.