Status: Approved · v2.4 · SPEC-UX-SHARE-VISUAL-001

depends_on: SPEC-DOMAIN-SHARE-001, SPEC-DOMAIN-MATCH-001, SPEC-UX-VISUAL-001, SPEC-UX-TOKENS-001

used_by: IS-MVP-12.3, IS-MVP-17.4, IS-POST-12.1

Sistema visual de cards compartilháveis v2

Publicação esportiva gerada de dados canônicos — não screenshot, editor livre ou flyer improvisado.

1. Objetivo e referência

O sistema transforma eventos públicos confiáveis em PNGs e previews de link que times, jogadores e torcidas desejam distribuir. A entidade é protagonista; RaizFC assina e devolve tráfego à URL canônica.

design/RaizFC Cards.dc.html é a referência visual canônica das 10 composições. SPEC-DOMAIN-SHARE-001 governa privacidade, autorização, estados e snapshot. SPEC-DOMAIN-MATCH-001 governa placar e validação.

2. Formatos v2

Nome visual	Dimensão	Safe area mínima	Saída
story	1080 × 1920	96 topo, 128 rodapé, 72 laterais	PNG para Stories/Status
feed	1080 × 1080	64 em todos os lados	PNG quadrado para feed e mensageria
og:image	1200 × 630	64 em todos os lados	PNG de preview de rota pública

No contrato v2, feed é a apresentação visual do formato de domínio square; não exige renome incompatível. O formato vertical 1080 × 1350 continua como quarto output compatível, conforme decisão confirmada em 2026-07-22, e reutiliza a composição feed adaptada à altura. Não está deprecado.

Informação essencial não entra na safe area. Background, glow e textura podem sangrar. Preview reduzido a 360 px deve preservar placar, nomes, status, assinatura e URL.

3. Anatomia comum

1. Contexto: competição, rodada, território ou tipo do evento.
2. Protagonista: placar, entidade, atleta, ranking ou campanha.
3. Identidade: escudo/foto sem recoloração e cor de entidade autorizada.
4. Estado: validação, provisório ou atualização do snapshot junto do dado qualificado.
5. Metadados: somente dados factuais necessários.
6. Assinatura: logo/wordmark discreto e URL pública canônica.

Limites: uma mensagem principal, até dois badges, até quatro grupos de metadata. Bebas Neue é exclusiva de placar, números de stats e títulos de impacto; todo o restante usa Inter.

4. Catálogo canônico das 10 composições

CARD-01 — Resultado validado (story)

Campo	Especificação
Trigger	transição canônica da partida para validated; nunca em waiting_validation ou contested
Dados	competição, rodada, times, escudos, placar, autores de gols públicos, campo, território, URL da partida
Composição	eyebrow da competição; mensagem factual de resultado; placar como maior elemento; status Validada junto do placar; assinatura no rodapé
Fallbacks	iniciais quando faltar escudo; omitir gols sem snapshot público; nome longo reduz metadata antes de reduzir tipografia
Aceite específico	PNG 1080×1920; resultado contestado ou provisório jamais aparece como validado

CARD-02 — Convocação (story)

Campo	Especificação
Trigger	publicação/confirmação canônica de convocação pela gestão autorizada
Dados	time, escudo/cor, adversário, data, hora, campo, competição/rodada, relacionados públicos permitidos, URL da partida
Composição	identidade do time no hero; Tem jogo hoje somente quando a data confirmar; confronto e horário dominam; assinatura inferior
Fallbacks	Noite de Holofote quando a cor da entidade falhar contraste; omitir convidado não público
Aceite específico	escudo acima da marca; nenhum dado privado ou participante não confirmado indevidamente

CARD-03 — Artilheiro da rodada (story)

Campo	Especificação
Trigger	consolidação da rodada e das estatísticas validadas
Dados	atleta público, foto/avatar, apelido/nome, time, camisa quando pública, gols na rodada, gols no período, posição no ranking, território/competição, URL
Composição	atleta protagonista; número de gols e stats em Bebas; contexto da rodada sempre visível
Fallbacks	iniciais/placeholder neutro; omitir ranking quando provisório ou indisponível
Aceite específico	somente partidas validadas contam; privacidade do jogador é checada antes do render

CARD-04 — Aniversário de jogador (story)

Campo	Especificação
Disponibilidade	pós-MVP em IS-POST-12.1; não pertence ao runtime de IS-MVP-17.4
Trigger	a plataforma usa a data de nascimento cadastrada para criar sugestão privada ao aniversariante; a data pode permanecer privada e nenhum post/card se torna público sem aprovação
Dados	nome/apelido público, foto/avatar, idade somente quando autorizada, time/posição, até duas stats validadas, URL pública
Composição	título de celebração, atleta protagonista, stats factuais; decoração discreta e não animada
Fallbacks	omitir idade/stat sem autorização ou dado; placeholder neutro para foto
Aceite específico	nenhum dado de nascimento privado é inferido; aprovação é revalidada e auditada antes da publicação

CARD-05 — Aniversário de time ou torcida (story)

Campo	Especificação
Disponibilidade	pós-MVP em IS-POST-12.1; não pertence ao runtime de IS-MVP-17.4
Trigger	a plataforma cria sugestão privada a partir da data de fundação cadastrada; publicação exige aprovação de usuário autorizado pela entidade
Dados	escudo, nome, cor, anos, data/território públicos quando aplicáveis, até três métricas consolidadas, URL do time ou torcida
Composição	identidade da entidade, escudo dominante, anos em Bebas, marca RaizFC subordinada
Fallbacks	fundo Noite de Holofote sem cor válida; omitir métrica não consolidada
Aceite específico	não inventar data, títulos, jogos ou torcedores; aprovação é revalidada; contraste validado

CARD-06 — Classificação parcial (feed)

Campo	Especificação
Trigger	publicação de snapshot de classificação após rodada ou atualização oficial
Dados	competição, rodada/período, território, até quatro posições, pontos, escudos, linha da entidade em contexto, URL
Composição	tabela editorial compacta; linha contextual destacada por primary; badge Provisório quando aplicável
Fallbacks	lista menor quando faltarem posições; iniciais sem escudo
Aceite específico	nunca omitir estado provisório; pagamento/patrocínio não altera destaque nem ranking

CARD-07 — Placar em andamento (feed)

Campo	Especificação
Trigger	snapshot público canônico de partida em in_progress; não é criado por relógio ou placar simulado
Dados	times, escudos, placar atual, período textual disponível, updatedAt, campo, URL da partida
Composição	badge Em andamento/Ao vivo junto do placar, horário da atualização e chamada factual
Fallbacks	se o domínio não fornecer snapshot confiável, não gerar; usar próximo jogo ou página pública normal
Aceite específico	não prometer lance a lance; conteúdo expira/regenera quando a fonte muda de estado

CARD-08 — Marco de campanha (feed)

Campo	Especificação
Disponibilidade	pós-MVP em IS-POST-12.1; não pertence ao runtime de IS-MVP-17.4
Trigger	regra ativa do catálogo detecta o marco e cria sugestão privada; pessoa/time envolvido precisa aprovar antes de post/card público
Dados	entidade, escudo/cor, competição/período, V/E/D, gols pró/contra, forma recente, posição quando válida, URL
Composição	identidade do time; até quatro stats em Bebas; forma V/E/D; contexto da competição no topo
Fallbacks	omitir posição provisória sem status; reduzir quantidade de stats antes da fonte
Aceite específico	marco tem id, versão da regra e fonte canônica; aprovação é revalidada; derrotas não são escondidas para produzir narrativa enganosa

CARD-09 — Partida validada (og:image)

Campo	Especificação
Trigger	geração/refresh do metadata da rota pública de partida e mudança do snapshot público
Dados	competição/rodada, status, times, escudos, placar, resumo público, campo/data, URL canônica
Composição	status no mesmo bloco do placar; participantes equilibrados; URL completa na assinatura
Fallbacks	template de partida sem placar quando não validada; iniciais sem escudo
Aceite específico	PNG 1200×630; cache deve invalidar quando status/placar público mudar

CARD-10 — Página pública da entidade (og:image)

Campo	Especificação
Trigger	geração/refresh do metadata de rota pública de time/torcida e mudança do snapshot público
Dados	nome, escudo, cor, território, descrição curta factual, até quatro métricas públicas, URL canônica
Composição	hero herda cor da entidade; escudo e nome dominam; RaizFC fecha a peça
Fallbacks	Noite de Holofote e iniciais quando identidade incompleta; métricas ausentes são omitidas
Aceite específico	mesma regra deve ser reutilizável por outras rotas públicas com composição apropriada, sem expor dados privados

5. Regras de geração e distribuição

• Todo card do catálogo é exportável em PNG a partir do preview.
• Toda rota pública entrega og:image 1200×630; rotas sem template especializado usam fallback Noite de Holofote com título, identidade pública, assinatura e URL.
• Geração MVP é orientada a resultado validado, convocação publicada, artilheiro/rodada consolidada, snapshot em andamento elegível e mudança de rota pública.
• Aniversário e marco de campanha são pós-MVP: o evento cria somente sugestão privada; PNG/post público nasce após aprovação em IS-POST-12.1.
• Template recebe props/DTO público e não faz fetch.
• Preview e export usam o mesmo renderer/tokens; não se aceita “aproximação” separada.
• Falha preserva o snapshot seguro, permite retry e oferece texto + link.
• Cache de og:image é invalidado por mudança pública relevante, não por dado privado.

6. Fundo, entidade e holofote

Noite de Holofote é o fallback: asfalto, surface quente e radial glow controlado. Cards de time/torcida herdam entityColor apenas quando validada e contrastante. Escudo não é recolorido. Cor branca/placa neutra pode proteger o asset. Textura e glow não atravessam texto pequeno.

7. Validação e estados

• waiting_validation: label Aguardando validação, prazo vindo do domínio e linguagem não definitiva.
• validated: label Validada; pode disparar CARD-01/CARD-09.
• contested: label Contestada; nunca dispara resultado validado e sai de rankings/stats definitivos.
• provisional: label sempre visível em ranking/campanha afetados.
• in_progress: só CARD-07 com snapshot canônico e updatedAt; não altera a máquina de validação.

O prazo de auto-validação não é token nem copy fixa. SPEC-DOMAIN-MATCH-001 atualmente define 72h para partidas elegíveis; qualquer protótipo/copy de 24h se adapta ao valor do domínio.

8. Assinatura e URL

A assinatura contém asset oficial RaizFC e URL pública canônica. A marca ocupa menos peso visual que escudo/foto e nunca é removida no MVP. OG usa a URL específica da rota; exports usam a URL do conteúdo de origem.

9. Privacidade e proibições

Somente snapshots públicos entram no renderer. Documento, telefone/endereço privado, saldo, valor de apoio, permissão interna, evidência de contestação, data de nascimento privada e guest não permitido são proibidos. Também ficam proibidos patrocínio no card, editor livre, animação, remoção de marca, frase inventada, campeão inferido e placar em tempo real simulado.

10. QA e critérios de aceite

• As sete composições ativas do MVP possuem fixture determinística, caso longo, asset ausente e fallback; as três celebrativas recebem essa cobertura quando IS-POST-12.1 for refinado e executado.
• Story/feed/OG renderizam nas dimensões exatas e respeitam safe areas.
• PNG e preview têm paridade visual; texto + link sempre funciona.
• Bebas/Inter, cores, glow, assinatura e identidade seguem specs v2.
• Status de validação/provisório fica junto do placar/ranking, nunca só no rodapé.
• Resultados e stats vêm apenas de fontes permitidas pelo domínio.
• Cor de entidade passa por contraste e possui fallback Noite de Holofote.
• Toda rota pública tem og:image e URL canônica; cache/invalidação são testados.
• O card parece mídia esportiva profissional, não bet, flyer infantil ou screenshot.

11. Impacto de domínio registrado

• SPEC-DOMAIN-SHARE-001 descreve story, square e vertical; v2 mapeia feed → square, mantém vertical como quarto output e trata og:image como pipeline de rota, não como substituição silenciosa do contrato.
• Placar em andamento e OG por rota não estão integralmente modelados no domínio atual. IS-MVP-17.4 deve evoluir contratos/specs de domínio antes do código caso a modelagem vigente não comporte os snapshots e triggers sem inferência. Aniversários e campanha pertencem a IS-POST-12.1.
• SPEC-DOMAIN-MATCH-001 mantém 72h e não autoriza tempo real confiável no MVP; esta spec não altera essas regras.

12. Decisão pós-MVP — sugestões celebrativas

Aniversários e marcos de campanha não são publicações automáticas. A plataforma prepara uma sugestão privada, e a pessoa ou gestão da entidade envolvida aprova/rejeita antes de qualquer post/card público.

• Fuso de virada: todos os gatilhos de aniversário usam o fuso de negócio America/Sao_Paulo (horário de Brasília, UTC−03:00 na decisão atual), independentemente do fuso do dispositivo.
• Aniversário de jogador: a fonte é a data de nascimento cadastrada. A sugestão é criada para o próprio jogador e independe de a idade estar pública; o card só mostra idade quando o painel de privacidade do jogador permitir.
• Aniversário de time ou torcida: a fonte é a respectiva data de fundação cadastrada. A sugestão é entregue aos usuários autorizados a publicar pela entidade envolvida.
• Marco de campanha inicial: três regras configuráveis — atingir 5 vitórias validadas na campanha, alcançar o 100º jogo validado e entrar no top 3 de qualquer ranking canônico disponível. Invencibilidade não entra na primeira versão porque ainda exigiria definir a quantidade de jogos.
• Catálogo de regras: adicionar, desativar ou remover um tipo de marco deve ser simples, versionado e testável, sem hardcode no renderer. Remover regra impede novas sugestões e não apaga posts já aprovados.
• Periodicidade de ranking: cada ranking canônico pode gerar sugestões periodicamente; regras de agenda e deduplicação são configuráveis por ranking para não repetir a mesma conquista no mesmo ciclo.
• Aprovação: a notificação abre o preview completo do card. Somente a ação explícita Aprovar publicação cria o post no feed; abrir ou marcar como lida não publica.
• Retenção: a sugestão não expira automaticamente por tempo. Permanece na central até aprovação, rejeição ou arquivamento, sempre revalidando permissões e estado antes de publicar.

O EP pós-MVP ainda deve detalhar contratos, cadência configurável por ranking, deduplicação, auditoria e comportamento quando a permissão for revogada. Até lá, IS-MVP-17.4 pode preservar layouts como referência, mas não implementa os três triggers celebrativos.

13. Histórico

• 2.4 — fuso de Brasília, fontes elegíveis, privacidade da idade, aprovação por notificação, retenção persistente e top 3 em qualquer ranking canônico.
• 2.3 — aniversário e campanha movidos para sugestões pós-MVP com aprovação; três marcos iniciais e registry configurável.
• 2.2 — catálogo visual de 10 cards, eventos, story/feed/OG e Design Direction v1.0.
• 2.1 — templates funcionais anteriores e story/square/vertical, preservados no histórico Git.