Índice · comece aqui
A história que este protótipo conta
“Tenho um acampamento na semana que vem. Quero descobrir quem ainda
não autorizou os documentos obrigatórios.”
São 46 telas, mas você não precisa ver as 46. Comece pela História — sete telas, na ordem —
e só depois abra os grupos que interessarem. Cada tela tem, no rodapé, para onde ir em seguida
e um atalho de volta para cá.
Começar pela história ›
Leitura técnica ›
Percorra estas sete telas na ordem. É o experimento inteiro: descobrir quem falta e agir.
Onde o documento nasce, versiona e é consultado. Herdado do Figma existente.
Como uma atividade passa a exigir um documento — e o que acontece quando não exige.
Os seis contextos de bloqueio. É o mesmo componente, mudando uma frase.
O lado do participante: ele responde, e a resposta muda a lista dela. Nem todo documento bloqueia — o de opt-in nunca bloqueia.
O que sustenta um aceite, e os três estados que exigem ação.
Os estados de erro. O terceiro é o pior, porque parece sucesso.
A pergunta de quem acompanha de cima: onde há exposição hoje?
A HISTÓRIA
Percorra estas sete telas na ordem. É o experimento inteiro: descobrir quem falta e agir.
↑ voltar ao índice
t01 · Evento › Inscrições — a tela de hoje, com o sinal novoa coluna exige contar autorizações por inscrição
inchurchID da Igreja: 442⌘K · Portal do Cliente
ResumoInformaçõesTickets
InscriçõesComunicaçãoInteressadosFinanceiro
| Check-in | Código | Comprador ⇅ | Proprietário |
Tipo de ingresso | Data da compra ⇅ | Status do pagamento | Autorizações | Ações |
| ☐ Não realizado | AC-1041 | Mariana Andrade | Cecília Andrade |
Criança 4-6 | 18/06/2026 | Pago |
1 de 2 |
ver ⋮ |
| ☐ Não realizado | AC-1042 | Felipe Andrade | Bento Andrade |
Criança 7-10 | 18/06/2026 | Pago |
2 de 2 |
ver ⋮ |
| ☐ Não realizado | AC-1043 | Juliana Prado | Miguel Prado |
Criança 7-10 | 18/06/2026 | Pendente |
0 de 2 |
ver ⋮ |
A coluna Autorizações é o único acréscimo desta tela. O restante — abas, cabeçalho,
colunas, ações-ícone — é o esqueleto de hoje.
t03 · NÚCLEO — a tela do experimentonão existe rota que responda quem falta
inchurchID da Igreja: 442⌘K · Portal do Cliente
42participantes
84autorizações exigidas
69autorizadas
15precisam de ação
| Participante | Documento exigido | Versão | Estado | Quem autorizou | |
| Cecília Andrade | Participação de menores | v3 |
autorizado | Mariana Andrade (responsável) |
ver |
| Cecília Andrade | Uso de imagem | v1 |
nunca respondeu | — |
cobrar |
| Bento Andrade | Participação de menores | v3 |
autorizado | Felipe Andrade (responsável) |
ver |
| Bento Andrade | Uso de imagem | v1 |
recusado | Felipe Andrade (responsável) |
ver |
| Miguel Prado | Participação de menores | v3 |
revogado | Juliana Prado (responsável) |
ver |
| Miguel Prado | Uso de imagem | v1 |
nunca respondeu | — |
cobrar |
A unidade da lista é pessoa × documento exigido. Os quatro estados são distinguidos por
forma da borda, nunca por cor. Nunca respondeu, recusado e revogado caem
todos em “precisa de ação” e continuam distintos na tela.
t04 · O que ela abre na semana da atividadedepende da mesma rota
inchurchID da Igreja: 442⌘K · Portal do Cliente
| Participante | Documento exigido | Estado | Responsável | |
| Cecília Andrade | Uso de imagem |
nunca respondeu | Mariana Andrade |
cobrar |
| Bento Andrade | Uso de imagem |
recusado | Felipe Andrade |
ver motivo |
| Miguel Prado | Participação de menores |
revogado | Juliana Prado |
ver |
| Miguel Prado | Uso de imagem |
nunca respondeu | Juliana Prado |
cobrar |
A conversa é diferente em cada caso — quem nunca respondeu é lembrete, quem recusou é
negociação, quem revogou mudou de posição. Por isso os três não viram um estado só.
t05 · Saber sem poder cobrar resolve meio job — a objeção O-10não há disparo de lembrete em lote
inchurchID da Igreja: 442⌘K · Portal do Cliente
Enviar lembrete a 15 responsáveis
Quem recusou ou revogou não entra no lembrete em massa: é conversa, não lembrete.
t08 · A contrapartida da cobrança — o que o responsável recebenão há notificação disparada por pendência
Aplicativo do membro9h04
Igreja Vida Nova
Falta a sua autorização para o Acampamento de Jovens 2026. Toque para ler e responder.
Pendências
Uso de imagem · Cecíliaresponder
Participação de menores · Cecíliaautorizado
Abrir o documento pendente
t09 · A tela de resposta — as duas saídas são operáveisbackend pronto · POST /accept/
‹ Autorização de uso de imagemv1
ParaCecília Andrade
AtividadeAcampamento de Jovens 2026
Versãov1 — a que a atividade exige
Texto integral da versão 1 do documento, exatamente como será registrado no comprovante.
Rolar até o fim. O registro guarda esta versão, e não “o documento” — é o que permite
provar depois o que foi apresentado.
Autorizo
Não autorizo
t07 · CHEGADA — o estado final que prova que o job foi resolvidodepende da rota do organizador
inchurchID da Igreja: 442⌘K · Portal do Cliente
42participantes
84autorizações exigidas
81autorizadas
3precisam de ação
O que sobrou, nominalmente
Bento Andrade · Uso de imagemrecusado — participa, imagem não usada
Miguel Prado · Participação de menoresrevogado — impede a participação
Ana Beatriz Lima · Uso de imagemnunca respondeu — lembrete enviado em 13/08
Zero pendências não é o estado final — o estado final é saber exatamente quem falta e por quê,
nominalmente, antes da data. É isto que a organizadora não consegue hoje.
O MÓDULO DE DOCUMENTOS LEGAIS
Onde o documento nasce, versiona e é consultado. Herdado do Figma existente.
↑ voltar ao índice
m01 · MÓDULO — herdado do Figma, não reinventadobackend pronto · GET /legal_document/
inchurchID da Igreja: 1985Sara Paulson
| Nome do documento ⇅ | Função | Exigido em | Abrangência |
Versão vigente ⇅ | Status ⇅ | |
| Termo de participação de menores | Consentimento | Inscrição em evento |
Igreja | 3.0 · pt, en |
Ativo (vigente) |
ver detalhes ⋮ |
| Autorização de uso de imagem | Consentimento | Cadastro kids |
Igreja | 1.0 · pt |
Ativo (vigente) |
ver detalhes ⋮ |
| Termo de uso do aplicativo | Termos contratuais | Acesso ao app/site |
Denominação | 2.0 · pt, pt-PT, en, es |
Inativo (arquivado) |
ver detalhes ⋮ |
Exibindo 1 a 100 de 11.240 registros
Itens por página: 100 · 1 2 3 … 50
Menu da linha, como desenhado: Ver detalhes · Editar · Arquivar — e Publicar quando o documento está arquivado.
Colunas conferidas contra a IN-41513: nome · função · contexto de exigência · abrangência · versão
vigente · ativo/inativo. Publicado por saiu porque só existe se o serializer expuser created_by.
⚠ Arquivar não é uma ação disponível
O menu da linha vem do Figma e traz Arquivar. Não existe PATCH no recurso, e desativar
por PUT cria a versão N+1 — com requires_re_acceptance=true, isso devolve
pendência de aceite à base inteira.
A IN-41513 declara este bloco fora da entrega, aguardando endpoint próprio. Enquanto isso, a ação está
desenhada e não é operável: um clique aqui é um evento de pendência em massa.
m02 · CRIAÇÃO — a Exigência já estava desenhada, do lado do documentosem endpoint para escolher o evento · scope=content_object
inchurchID da Igreja: 1985Sara Paulson
☑ Solicitar o aceite apenas em eventos específicos
O aceite do documento será exigido ao se inscrever nos seguintes Eventos:
Buscar evento
Acampamento de Jovens 2026 ×
Retiro de Casais ×
É esta a Exigência, expressa do lado do documento. O evento é consumido de uma busca, nunca cadastrado aqui.
✓ Conflito RESOLVIDO — rota 1, em 2026-08-14 → IN-41698
O escopo fica. A IN-41513 excluía scope=content_object por falta de contrato para
buscar o evento, e a exclusão era consequência da lacuna, não decisão de produto.
O motivo é de produto: sem content_object, o contexto
event_registration exige o mesmo documento em toda inscrição em evento. Um
acampamento de menores precisa de autorização do responsável; um café da manhã não.
O que falta é uma peça, não a capacidade: a rota de busca de eventos para vincular. O campo já
existe no modelo, o Figma já desenha esta caixa, e é o caso de uso 2 da especificação.
Conteúdo do documento — por idioma
ptpt-PTenes+ idioma
EscreverAnexar
Adicionar anexo · arquivo em formato PDF
O conteúdo é
uma lista por idioma, não um texto só —
languages: [{ language, content |
content_file }], com pelo menos um item. Salvar com dois idiomas cria
uma versão com os dois.
Duas igrejas do público-alvo desta PD estão em
Portugal (Maranata e CCLX), então
pt-PT
não é hipótese. Acrescentar idioma depois é
outro caminho, que
não gera versão.
Publicar para
Se nenhum público específico for selecionado, o aceite é solicitado para toda a denominação.
m03 · DETALHE — de onde se chega às respostas, ao histórico e às revogaçõesbackend pronto · GET /legal_document/{pk}/
inchurchID da Igreja: 1985Sara Paulson
Configuração
FunçãoTermo de consentimento
Exigido dePessoas usuárias do App/Site da igreja
Exigido paraSe inscrever em um evento · 2 eventos específicos
Publicado paraToda a denominação
Versão vigente3.0 · publicada em 01/04/2026 por Ana Sousa
Onde este documento é exigido
Acampamento de Jovens 202638 de 42 autorizados
Retiro de Casais12 de 12 autorizados
Esta lista responde a objeção O-15: dá para ver a exposição sem entrar em cada evento.
m04 · EDIÇÃO — publicar v4 NÃO troca a versão das atividades em cursoPUT sempre gera versão · não há PATCH nem pin por atividade
inchurchID da Igreja: 1985Sara Paulson
Conteúdo — por idioma
ptpt-PTenes+ idioma
editor de texto · o conteúdo da versão 3 em pt, editável
⚠ Editar é substituição TOTAL. O PUT reenvia todos os idiomas da versão
vigente, inclusive os que você não abriu. Idioma omitido desaparece da versão nova — perda
silenciosa de conteúdo jurídico.
Antes de publicar — confirmação obrigatória
Esta alteração cria a versão 4
Este documento exige reaceite. Ao publicar a versão 4,
todas as 1.284 pessoas que aceitaram a versão 3 voltam a ter pendência e são bloqueadas no
próximo acesso.
CancelarPublicar a versão 4
Critério de aceite da IN-41513, e ele são duas frases, não uma: avisar que cria a versão N,
e — quando requires_re_acceptance=true — que os aceites anteriores voltam a ser exigidos.
O aviso que já existia abaixo é sobre outro eixo (a versão fixada por atividade).
Salvar cria a versão 4
Atividades que exigem a v3 hojeAcampamento de Jovens 2026 · Retiro de Casais
O que acontece com elasnada — continuam exigindo a v3
Para trocarpromover a versão em cada atividade, um ato próprio
Este comportamento é a recomendação da pergunta aberta 10 (opção B), não uma decisão fechada.
Hoje a política de reaceite mora no documento e vale globalmente.
m05 · RESPOSTAS — a visão por DOCUMENTO (a do Figma)/acceptances/ não devolve para quem vale · sem paginação declarada
inchurchID da Igreja: 1985Sara Paulson
| Pessoa | Versão | Resposta | Em nome de | Canal | Data |
| Mariana Andrade | 3.0 | aceito | Cecília Andrade | aplicativo | 10/08/2026 |
| Felipe Andrade | 3.0 | aceito | Bento Andrade | aplicativo | 09/08/2026 |
| Juliana Prado | 3.0 | revogado | Miguel Prado | aplicativo | 11/08/2026 |
Esta tela é por documento e responde “quem respondeu”. A tela de Autorizações do evento é
por atividade e responde “quem falta”. São perguntas diferentes, e a segunda é a novidade.
m06 · HISTÓRICO — versão nunca somebackend pronto · GET /versions/
inchurchID da Igreja: 1985Sara Paulson
| Versão | Publicada em | Publicada por | Estado |
| 4.0 | 13/08/2026 | Sara Paulson | vigente |
| 3.0 | 01/04/2026 | Ana Sousa | anterior · exigida em 2 atividades |
| 2.0 | 12/01/2026 | Ana Sousa | anterior |
Nenhuma ação de exclusão: versão com aceite vinculado não pode ser apagada.
m07 · REVOGAÇÕES — desenhado no Figma, nunca construídorevogação é global · a rota só opera sobre o próprio usuário
inchurchID da Igreja: 1985Sara Paulson
| Pessoa | Documento | Versão | Aceitou em | Revogou em |
| Juliana Prado | Participação de menores | 3.0 | 02/08/2026 | 11/08/2026 |
A revogação é global no modelo construído — revogar aqui vale para todas as atividades,
porque só existe um aceite por versão e pessoa. É achado do discovery, não decisão de desenho.
m09 · CASO 10 — o ATO que faltava; a lista sozinha não revoga nadanão existe rota para a igreja revogar por terceiro
inchurchID da Igreja: 1985Sara Paulson
Revogar aceite a pedido do titular
PessoaJuliana Prado
DocumentoParticipação de menores · v3
Aceito em02/08/2026
Pedido recebido em11/08/2026
O registro original é preservado. O que muda é a validade.
Este documento é termo contratual: revogar devolve a pessoa ao bloqueio no contexto correspondente.
⚠ No modelo construído a revogação é global: ela vale para todas as atividades que
exigem esta versão, não só para uma. Achado do discovery, não escolha de desenho.
m10 · IDIOMAS — acrescentar idioma NÃO cria versãobackend pronto · POST /legal_document/{pk}/add_language/
inchurchID da Igreja: 1985Sara Paulson
Idiomas da versão 3 (vigente)
| Idioma | Conteúdo | Acrescentado em | |
| pt · Português (Brasil) | texto | 01/04/2026 | ver |
| en · English | texto | 02/04/2026 | ver |
Acrescentar idioma
Isto não cria a versão 4. O idioma entra na versão vigente, e ninguém é obrigado a reaceitar.
Por que esta tela existe, e por que ela não existia até agora: uma subtarefa inteira do backend
(IN-38172, concluída) trocou a abordagem para suportar múltiplos idiomas, e o protótipo não tinha
nenhuma noção de idioma. Duas igrejas do público-alvo desta PD estão em Portugal — Maranata e CCLX —
e há denominação internacional na lista.
É o único caminho que mexe no conteúdo sem versionar: tentar acrescentar um idioma que já existe
devolve erro do backend no campo. Não há exclusão de idioma nem de versão, em nenhuma tela.
m08 · ESTADO VAZIO — a igreja que ainda não publicou nadabackend pronto
inchurchID da Igreja: 1985Sara Paulson
Nenhum documento legal publicado.
Publique um documento para poder exigir aceite no aplicativo, no site, no painel,
na inscrição em evento, no cadastro do Kids ou na contratação de plano.
+ Novo documento
A EXIGÊNCIA NA ATIVIDADE
Como uma atividade passa a exigir um documento — e o que acontece quando não exige.
↑ voltar ao índice
t02 · Contexto — a atividade escolhe o que exigira Exigência não existe como entidade
inchurchID da Igreja: 442⌘K · Portal do Cliente
| Documento | Versão exigida | Aplica-se a | Autorizados | |
| Termo de autorização de participação de menores |
v3 fixada |
Todos os participantes | 38 de 42 |
acompanhar |
| Autorização de uso de imagem |
v1 fixada |
Todos os participantes | 31 de 42 |
acompanhar |
Origem do documento
Termo de autorização de participação de menorespublicado pela Denominação · reutilizado, não copiado
Autorização de uso de imagempublicado pela Igreja
✓ Conflito RESOLVIDO — rota 1, em 2026-08-14 → IN-41698
Esta tela depende de scope=content_object, que a IN-41513 declarava fora da entrega.
O escopo fica: sem ele, todo evento exigiria o mesmo documento. A peça ausente é a rota de busca
de eventos, e ela entrou como trabalho nomeado naquela história.
A versão exigida é fixada quando a exigência é criada. Publicar uma versão nova do documento
não altera esta atividade — trocar a versão daqui é um ato próprio.
t11 · Estado vazio da atividade — e o ramo negativo do fluxo 4depende da Exigência
inchurchID da Igreja: 442Portal do Cliente
Nenhum documento exigido nesta atividade.
A inscrição prossegue normalmente, sem pedir aceite.
Exigir um documento
É o ramo negativo do fluxo 4 da spec: “se o evento não possui documentos vinculados,
a inscrição prossegue normalmente”. Sem esta tela, o protótipo só mostrava o caso em que existe exigência.
p12 · O contraste: sem exigência, não há modal nenhumausência de exigência · nada a chamar
Aplicativo do membro9h30
Retiro de Casais
Data22/11/2026
IngressoCasal · R$ 180
Nenhum documento exigido — a inscrição segue sem interrupção.
Concluir inscrição
t12 · Quem se inscreveu na sexta para o domingoexige cruzar população da atividade com autorizações
inchurchID da Igreja: 442Portal do Cliente
45participantes hoje
3entraram depois
6precisam de ação
| Participante | Inscrito em | Documento exigido | Estado | |
| Sofia Lima | ontem | Participação de menores |
nunca respondeu |
cobrar |
| Sofia Lima | ontem | Uso de imagem |
nunca respondeu |
cobrar |
| Théo Menezes | hoje | Participação de menores |
nunca respondeu |
cobrar |
A população da exigência é viva: quem entra depois entra pendente, e a lista muda sozinha.
Pergunta aberta: a lista fecha em algum momento antes da atividade? Objeção O-11.
ONDE O DOCUMENTO É EXIGIDO
Os seis contextos de bloqueio. É o mesmo componente, mudando uma frase.
↑ voltar ao índice
p01 · CASO 3 — o usuário é barrado na entrada do appbackend pronto · GET /pending/ + POST /accept/
Aplicativo do membro9h30
Termos de Uso e Política de Privacidade
Para usar o app, você precisa concordar com os Termos de Uso e Política de Privacidade.
Revogação disponível ao solicitar à igreja.
☑ Declaro que li e estou de acordo.
p02 · CASO 5 — mesmo componente, outra frasebackend pronto
Aplicativo do membro9h30
Termos de Uso e Política de Privacidade
Para se inscrever nesse evento, você precisa concordar com os Termos de Uso e Política de Privacidade.
Revogação disponível ao solicitar à igreja.
☑ Declaro que li e estou de acordo.
p03 · CASO 7 — o responsável, por conta própria, no appbackend pronto
Aplicativo do membro9h30
Termos de Uso e Política de Privacidade
Para cadastrar a criança, você precisa concordar com os Termos de Uso e Política de Privacidade.
Revogação disponível ao solicitar à igreja.
☑ Declaro que li e estou de acordo.
p04 · o sexto contexto — contratação de planobackend pronto
Aplicativo do membro9h30
Termos de Uso e Política de Privacidade
Para contratar esse plano, você precisa concordar com os Termos de Uso e Política de Privacidade.
Revogação disponível ao solicitar à igreja.
☑ Declaro que li e estou de acordo.
p05 · A fila — a pessoa responde em sequência, com posição/pending/ devolve a lista ordenada por escopo
Aplicativo do membro9h31
Documento 2 de 3
Aviso de privacidade
Para usar o app, você precisa concordar com os documentos pendentes.
O acesso é liberado depois do último.
Documentos de
opt-in não entram nesta fila —
p13.
☑ Declaro que li e estou de acordo.
p06 · CASO 4 — membro de equipe barrado ao entrar no painelnão há guard global no painel · toca arquivo de bootstrap
inchurchID da Igreja: 442Portal do Cliente
Documentos pendentes
Termos operacionais da igreja
Para usar o painel, você precisa concordar com os Termos operacionais.
Revogação disponível ao solicitar à igreja.
☑ Declaro que li e estou de acordo.
Quem é barrado aqui não tem permissão de gestão de documentos — e ainda assim precisa
alcançar esta tela. É a rota que não pode depender da permissão.
p08 · CASO 6 — aceite anônimo, sem dado pessoal no registrobackend pronto · link_anonymous
Site da igreja9h32
Inscrição · Acampamento de Jovens 2026
☑ Li e concordo com o Termo de participação de menores
O aceite é registrado agora com um identificador temporário, sem nome nem e-mail.
Quando a inscrição é processada, ele é vinculado à pessoa.
Concluir inscrição
p07 · CASOS 8 e 13 — em nome de terceiro, declarado pela igrejaunicidade (versão, pessoa) colide com dois filhos do mesmo responsável
inchurchID da Igreja: 442Portal do Cliente
Termo de participação de menores · v3
conteúdo da versão exigida
CriançaCecília Andrade
ResponsávelMariana Andrade
Quem está registrandoTereza dos Santos (secretaria)
☑ Declaro, em nome do responsável, que ele leu e está de acordo.
O registro guarda quem executou, em nome de quem, para quem vale e que foi
declarado pela igreja. Quem tem autoridade para isso é pergunta aberta do brief.
p11 · CASO 13 — contexto cadastro de usuário, que NÃO é o do Kidscontexto user_registration sem fluxo na spec
inchurchID da Igreja: 442Portal do Cliente
Termo de membresia · v2
conteúdo da versão exigida no cadastro
Pessoa sendo cadastradaRafael Bittencourt
Quem está registrandoTereza dos Santos (secretaria)
Contextocadastro de usuário — não é o do Kids
☑ Declaro, em nome da pessoa, que ela leu e está de acordo.
Quem tem autoridade para declarar em nome de outra pessoa é pergunta aberta do brief,
com leitura jurídica pendente. A tela existe para a pergunta ser discutível, não para respondê-la.
A PESSOA QUE RESPONDE
O lado do participante: ele responde, e a resposta muda a lista dela.
↑ voltar ao índice
t10 · O ciclo fecha — a resposta dele muda a tela delabackend pronto · idempotente
Autorização registrada9h06
Registrado
DocumentoUso de imagem · v1
Quem autorizouMariana Andrade, em nome próprio
ParaCecília Andrade
Quando13/08/2026 · 9h06
Pendências
nenhuma pendência para esta atividade
t10b · A recusa é resposta, não silêncioo Figma tem Rejeitar e o backend não sabe registrar recusa
Resposta registrada9h06
Você não autorizou
DocumentoUso de imagem · v1
O que isso significaa Cecília participa; a imagem dela não é usada
Pode mudar depois?sim, até a data da atividade
Rever o documento
p09 · CASOS 10 e 11 — de onde a pessoa pede revogaçãobackend pronto · /pending/ e /revoke/
Perfil › Configurações9h34
Meus termos
Termos de Uso · v2aceito em 12/01/2026
Participação de menores · v3aceito em 10/08/2026
Uso de imagem · v1rejeitado
Para revogar um aceite, solicite à igreja. A revogação é registrada com data e o
registro original é preservado.
Solicitar revogação
p13 · OPT-IN — a ação é OPTAR, e ela NÃO bloqueiao painel não trata opt_in; a recusa não tem rota que a escreva
Aplicativo do membro9h34
Comunicações da igreja
Quer receber avisos sobre eventos e campanhas no seu e-mail?
Não, obrigadoQuero receber
Você pode mudar isso quando quiser em Meus termos.
O que este documento NÃO faz
Bloqueia o acesso?não — nunca
Entra na fila de pendências?não
Revogar tem que consequência?só remove o opt-in
Terceiro tipo de documento, e o protótipo tratava tudo como aceitar/recusar. A função
consent_text obriga required_action=opt_in; contract_terms e
privacy_notice obrigam accept. Qualquer outra combinação é barrada no formulário.
Critério de aceite explícito da IN-41513: "um documento pendente com required_action=opt_in
no contexto control_panel_access não entra na fila e não bloqueia o acesso". E o motivo é uma
lacuna, não uma escolha: não há rota que registre a recusa, então o painel o ignora por ora — o mesmo
DECLINED que existe no enum e ninguém escreve.
p14 · IDIOMA AUSENTE — o backend faz fallback, e a tela precisa AVISARo aviso não existe em nenhuma tela desenhada
App · idioma do aparelho: es9h36
⚠ Este documento ainda não está disponível em espanhol. Exibindo em português.
Termo de participação de menores
Eu, responsável legal pelo menor identificado nesta autorização, declaro…
☑ Declaro que li e estou de acordo.
O backend não devolve vazio: ele cai no primeiro idioma cadastrado. Sem o aviso, a pessoa recebe um
documento jurídico num idioma que ela não pediu e não tem como saber que existe outra versão — ela aceita
o que não leu. É critério de aceite da IN-41513, e é o caso que mais interessa às duas igrejas de Portugal e à
denominação internacional do público-alvo.
Acessibilidade, e ela vale para as seis telas de bloqueio: a tela é bloqueante, então tem de ser
operável só com teclado, com o foco contido enquanto bloqueia e devolvido à aplicação ao encerrar.
Também é critério de aceite, e nenhuma tela de bloqueio o representava.
p10 · CASO 11 — o efeito da revogação, operável em vez de afirmadorevogar devolve pendência
Aplicativo do membro11h02
Participação de menores
Sua autorização foi revogada em 11/08/2026. Para voltar a usar este recurso, é preciso concordar novamente com o documento.
A revogação anterior continua registrada.
☐ Declaro que li e estou de acordo.
A PROVA E AS EXCEÇÕES
O que sustenta um aceite, e os três estados que exigem ação.
↑ voltar ao índice
t06 · Contexto — por que esta pessoa está autorizadacampos existem · o alvo não é devolvido pela API
inchurchID da Igreja: 442⌘K · Portal do Cliente
Quem precisa estar autorizado
ParticipanteCecília Andrade · 1 ano e 8 meses
AtividadeAcampamento de Jovens 2026
Documento exigidoParticipação de menores · v3
Quem autorizou
ExecutouMariana Andrade
Em nome deela mesma, como responsável
Data10/08/2026 · 20h14
Canalaplicativo
Versão lidav3 — a mesma que a atividade exige
Texto que ela leu
conteúdo da versão 3, exatamente como foi apresentado
t06b · Exceção operável — recusaAcceptanceStatus.DECLINED existe no enum e nenhuma rota o escreve
inchurchID da Igreja: 442⌘K · Portal do Cliente
Estado
DocumentoUso de imagem · v1
Estado jurídicorecusado
Estado operacionalprecisa de ação
Quem respondeuFelipe Andrade, em 09/08/2026
O que a recusa implica
Uso de imagem é texto de consentimentoa criança participa; a imagem não é usada
Participação de menores é termo contratualrecusa impediria a participação
O que a recusa provoca depende da função do documento — não existe regra única.
t06c · Exceção operável — revogaçãoestado existe · alcance é global
inchurchID da Igreja: 442⌘K · Portal do Cliente
A trilha continua inteira
AutorizouJuliana Prado · 02/08/2026 · v3
RevogouJuliana Prado · 11/08/2026
Registro originalpreservado — permanente não é o mesmo que eternamente válido
Estado hojerevogado · precisa de ação
Ponto de atenção levantado no discovery
Alcance da revogaçãohoje o modelo construído revoga globalmente, não só nesta atividade
QUANDO DÁ ERRADO
Os estados de erro. O terceiro é o pior, porque parece sucesso.
↑ voltar ao índice
e01 · ERRO — e a decisão de produto: falha NÃO bloqueiapolítica de falha não decidida
inchurchID da Igreja: 442Portal do Cliente
⚠ Quando a verificação de pendências falha em um ponto de entrada, a proposta da
Engenharia é não bloquear a pessoa: registra-se o erro em observabilidade, sem dado pessoal,
e reavalia-se na próxima verificação. É pergunta aberta do brief — a tela mostra a proposta,
não a decisão.
e02 · ERRO — o caso que a Engenharia nomeou, e o mais delicadoretry é seguro · o serviço é idempotente
inchurchID da Igreja: 442Portal do Cliente
A criança foi cadastrada; o aceite não
Cecília Andradecadastrada com sucesso
Termo de participação de menoresaceite não registrado
Tentar de novo é seguro: o registro é idempotente, e reenviar não cria aceite duplicado.
Ao fechar sem sucesso, a criança permanece cadastrada e a autorização fica pendente —
aparecendo na lista da organizadora.
Política proposta pela Engenharia na história do painel, ainda não decidida por produto
nem lida pelo jurídico. A tela existe para a decisão ser tomada olhando o estado, não no abstrato.
e03 · ERRO PARCIAL — o pior tipo, porque parece sucessodepende do disparo em lote
inchurchID da Igreja: 442Portal do Cliente
12lembretes enviados
3não enviados
| Responsável | Participante | Motivo | |
| Juliana Prado | Miguel Prado | sem e-mail cadastrado |
ver na lista |
| Ana Beatriz Lima | Sofia Lima | não tem o aplicativo instalado |
ver na lista |
| Carlos Menezes | Théo Menezes | notificações desativadas |
ver na lista |
Estes três continuam pendentes e precisam de contato por outro caminho. Dizer só
“lembrete enviado” esconderia o problema: a organizadora acharia que cobrou 15.
e04 · A rota que NÃO pode depender da permissãopermissão legal_document não existe em nenhuma subtarefa
inchurchID da Igreja: 442Portal do Cliente
Documentos pendentes
O que este operador vê
Tela de pendênciasalcança — e precisa alcançar
Item de menu Documentos Legaisnão aparece
Lista, criação, edição, revogaçõesbloqueadas
Autorizações de uma atividadesó se tiver acesso ao evento
Você não tem permissão para gerenciar documentos legais.
Fale com quem administra a igreja.
O público que é bloqueado (membro de equipe, líder de célula, equipe de evento)
não tem permissão de gestão. Se a rota de pendências exigisse essa permissão,
ele ficaria trancado sem conseguir se destravar.
v01 · A objeção O-15 do Rafael, respondidaexige agregação que nenhuma rota faz
inchurchID da Igreja: 1985Sara Paulson
| Atividade | Quando | Documento exigido | Autorizados | Precisam de ação | |
| Acampamento de Jovens 2026 | em 3 dias | 2 documentos | 78 de 90 |
12 |
abrir |
| Retiro de Casais | em 3 meses | nenhum | — |
— |
abrir |
| Cadastro Kids · turma 2026 | contínuo | 1 documento | 210 de 214 |
4 |
abrir |
⚠ Esta tela não é gatilho. Ela responde “onde há exposição” para quem
vem procurar — governança. Ela não avisa ninguém, e isso é deliberado: a hipótese que
estamos testando é se o organizador volta sozinho. Ver a decisão no prototypes.md.
PARA O TIME TÉCNICO
O que já está construído, o que não existe, e onde o desenho contradiz o que foi implementado.
↑ voltar ao índice
Leitura técnica · o estado do backend por trás de cada telalido em código, não presumido
Como ler os selos
borda simplesjá construído na branch feature/IN-37362--LegalDocument
borda tracejadanão existe — é trabalho novo
borda duplao desenho contradiz o que foi implementado
As cinco contradições, todas verificadas em código
Unicidade do aceite(document_version, basic_user) com status aceito, global — duas atividades não podem ter, cada uma, o aceite da mesma pessoa; e dois filhos do mesmo responsável colidem
RecusaDECLINED está no enum e nenhuma rota o escreve — mas o Figma tem botão “Rejeitar”
Revogaçãoopera sobre o aceite por id e filtra pelo próprio usuário — é global, e o painel não revoga por terceiro
Política de reaceiterequires_re_acceptance mora no documento — não pode variar por atividade
Pergunta do organizador/pending/ calcula a pendência do usuário da requisição — não existe rota para “quem falta”
Auditoria contra a documentação do Jira — 2026-08-14
O protótipo foi conferido contra tudo o que está ligado à
PD-3757: a especificação funcional, a história IN-41513 [Frontend] (Development Backlog, 21 critérios
de aceite), as seis subtarefas de backend, a PD-1964 incorporada e as quatro PDs relacionadas. Sete lacunas
foram fechadas nesta rodada; duas decisões ficaram abertas.
Multi-idiomafaltava por inteiro — subtarefa IN-38172 concluída,
tabela legal_document_version_language, add_language. Fechado em
m10, p14 e nas abas de m02/m04
Opt-ino protótipo tratava tudo como aceitar/recusar.
consent_text obriga opt_in, que não bloqueia e não entra na fila. Fechado em
p13
Arquivarestava oferecido e é um evento de pendência em massa (sem
PATCH; via PUT cria versão N+1). Declarado não-operável em
m01
Aviso de reaceiteo aviso obrigatório de que a base inteira volta a ter
pendência não existia. Fechado em m04
Colunas da listafaltavam função, contexto de exigência e abrangência —
as três que distinguem um documento do outro
Slug e acessibilidadeo campo e a operação por teclado com foco contido,
ambos critério de aceite
As quatro PDs relacionadas — o que elas pedem, e o que já está coberto
PD-3793 · termo próprio da denominaçãocoberto — abrangência
Denominação. Nomeia a Reviver (Portugal), o que reforça o multi-idioma
PD-2651 · igreja customiza a política de privacidadecoberto —
função privacy_notice com abrangência Igreja
PD-2236 · ver o termo em editar perfilparcial — existe
Meus termos; a superfície declarada é editar perfil, e essa é decisão
de onde mora, não lacuna de fluxo
PD-1819 · convite de admin com termo + definir senhaNÃO
representado — o e-mail de convite é superfície que não existe neste protótipo
A PD-1819 é relates to, não incorporada — diferente da PD-1964, que foi
merged from. Desenhar tela para ela aqui seria puxar escopo que não pertence à declaração
congelada desta PD (pd-scope): o desfecho certo é ela competir por prioridade como PD própria,
não entrar de carona. Registrado para que a ausência seja declarada, não silenciosa.
As duas decisões — tomadas em 2026-08-14, com rota registrada
✓ 1 · A exigência por atividade FICA no escopo — rota 1 → IN-41698
A IN-41513 declara scope=content_object fora da entrega do painel — não há
contrato para selecionar o evento. Mas é sobre ele que repousam t02, os chips
de evento em m02 e a versão fixada por atividade, que é a história que este
instrumento conta.
Decidido: o escopo fica. Sem content_object, o contexto
event_registration exigiria o mesmo documento em toda inscrição em evento — o que está
errado para a igreja. A exclusão na história era consequência da lacuna de contrato, não decisão de produto.
O trabalho nomeado: a rota de busca de eventos, e a retirada da suposição da descrição da IN-41513.
A pergunta do experimento não muda: este protótipo
segue testando o que testava.
✓ 2 · Membresia é OUTRA oportunidade — rota 3 → IN-41699
A PD-1964 foi incorporada a esta PD e pede o termo de membresia no fluxo de membresia do
app. O enum construído tem seis contextos e nenhum é membresia:
user_registration · app_site_access · control_panel_access · event_registration · kids_enrollment ·
subscription_purchase.
Decidido: rota 3 — problema novo. Pelas três perguntas de pertencimento, membresia passa em
problema e em métrica, e falha na necessidade: o administrador comprova quem aceitou
qual versão nos seis contextos construídos sem membresia. Ela melhora o resultado; não o
habilita — a borda que a régua documenta para não fazer a PD nunca encerrar.
Não é juízo sobre o valor: a PD-1964 é a demanda mais concreta que esta PD tinha absorvido
(Comunidade Vida de Guarapuava · João Marcos · CS Matheus Suzano), hoje por Google Forms. Ela está em
Inbox — nunca saiu do board — então nada precisa ser reaberto: ela recompete por
prioridade, e o link merged from é que sai.
Achado que fica, e não é sobre membresia: a PD promete
"adicionar termos a qualquer contexto futuro sem novo desenvolvimento", e o enum é fechado —
contexto novo exige migração. Vale para todo contexto futuro. Registrado na IN-37362.
O que a API devolve e o desenho precisa
/legal_document/{pk}/acceptances/não devolve o alvo (a criança) nem declared_by_church; paginação não declarada
scope=content_objecto campo existe; não há rota para listar ou buscar o evento a vincular
Permissão legal_documentnenhuma subtarefa a cria — sem ela, criar e editar falham mesmo para admin
IdiomaCharField(max_length=5) sem choices e sem rota que liste idiomas
O que não é pergunta técnica, e sim decisão de produto em aberto
Versão por atividadepublicar v4 troca a versão das atividades em curso, ou não? Sem isso, o fluxo de versão não se desenha
Rascunhosalvar já publica e já exige — não há revisão antes
Falha na verificaçãobloqueia por segurança ou libera e observa?
Autoridade para declararquem pode aceitar em nome de terceiro, e o que fazer quando o responsável não tem cadastro
Escape do bloqueioexiste rota que nunca é bloqueada, para o caso de trancar todos os administradores?
Esta tela é leitura de estado, não refinamento. Critério de aceite, estimativa e quebra em
subtarefas são do /refine, que roda depois do /epics e do
/breakdown-epic — nenhum dos dois existe ainda.
Apêndice — ideias consideradas e não seguidas.
Bloqueio na inscrição (ninguém entra pendente): não cobre a população que já existe antes da atividade,
que é o cenário descrito. Virou mecanismo possível, não a solução.
Painel agregador fora do evento: contradiz a decisão de que o módulo consome atividades em vez de as cadastrar.
Digest por e-mail sem tela: não responde “quem falta”, só “quantos faltam”.
O registro completo, com o motivo de cada descarte, está no prototypes.md.