Status: Approved · v1.1 · SPEC-UX-REDESIGN-REF-001

depends_on: SPEC-UX-VISUAL-001, SPEC-UX-TOKENS-001, SPEC-UX-A11Y-001

used_by: IS-MVP-19.1, IS-MVP-19.2, IS-MVP-19.4, IS-MVP-19.5, IS-MVP-19.6, IS-MVP-19.7, IS-MVP-19.8, IS-MVP-19.9, IS-MVP-19.10, IS-MVP-19.11, IS-MVP-19.12, IS-MVP-19.13, IS-MVP-19.14, IS-MVP-19.15, IS-MVP-19.16, IS-MVP-19.17, IS-MVP-19.18, IS-MVP-19.23, IS-MVP-19.28, IS-MVP-19.29, IS-MVP-19.30

Referência e paridade do redesign T1–T9

1. Finalidade

Este documento transforma os anexos de continuidade em uma referência versionada e rastreável. Ele não torna o código JSX standalone uma arquitetura de produção nem substitui specs de domínio, contratos, ADRs, permissões ou o estado SDD.

O objetivo aprovado é reproduzir a intenção visual e funcional dos protótipos no produto real, preservando toda função canônica existente e criando as capacidades ausentes por specs e EPs próprios.

2. Snapshot e autoridade

O snapshot bruto está em design/redesign/2026-08-prototype-continuity/raw/; seu manifest.sha256 registra nome, tamanho e SHA-256. Os arquivos são imutáveis dentro desta referência. Correções futuras entram em novo snapshot ou em specs canônicas, nunca por edição silenciosa do histórico.

Ordem de autoridade:

1. aprovação humana registrada;
2. spec, ADR e contract canônico revisado pelo redesign;
3. decisões finais mais recentes de 17-raizfc-design-rules.md e contexto confirmado de 10-CLAUDE.md;
4. JSX final de cada tela;
5. 11-raizfc-prototype-specs-reference.md e imagens de referência;
6. tentativas antigas, harness, toggles, mocks, logs e comentários de debug.

Quando um protótipo simplifica uma função existente, a função canônica vence. Quando o owner confirmou uma função nova, ela entra no backlog funcional, mas não pode ser simulada na UI antes de contrato, permissão e comportamento aprovados.

3. Regras transversais confirmadas

• temas têm duas dimensões: identidade Raiz | Neutro e luminosidade dark | light; tokens, persistência e fallback são globais;
• tabs de conteúdo são sublinhadas, scrolláveis quando necessário e nunca pills;
• botões e chips de filtro usam radius 10; radius-pill permanece reservado a elementos semanticamente circulares ou badges aprovados;
• todas as seções usam primitives compartilhadas de Section e SectionTitle;
• não existe aba vazia; conteúdo ausente omite a aba e a seção correspondente;
• novas ações entram no cluster existente, com prioridade e overflow definidos por largura local;
• a coluna do cluster de ações não encolhe e layouts ao redor de texto variável reservam espaço em fluxo;
• nome de time e sigla não usam ellipsis; removem-se colunas menos prioritárias antes do nome e o piso é a sigla completa medida no layout real;
• galeria usa miniaturas 4:3, cover, altura de referência 140 px no web, quantidade visível par e overflow +N simples;
• hooks são declarados antes de qualquer retorno condicional;
• geometria SVG complexa requer asset processado, proveniência e confirmação visual;
• identidade usa escudo, avatar ou ícone canônico conforme a entidade; não se inventam logos nem se promove base64 do protótipo;
• estados loading, empty, restricted, unavailable, partial e error continuam obrigatórios;
• web e mobile compartilham intenção e contratos, não implementação DOM/CSS.

4. Matriz T1–T9

Tela	Protótipo	Baseline a preservar	Gap confirmado	Dependência antes da implementação
T1 Auth	19-raizfc-fase1-auth.jsx	e-mail/telefone, confirmação, recovery/reset, onboarding, loading/error	layout e quatro temas; Google só com OAuth real	foundation; CR de identidade se Google entrar
T2 Home	21-raizfc-fase2-home.jsx	reason sheet, ocultar/desfazer, mute, preferências, paginação	ManagementCard e cards editoriais; ranking exige projeção real	foundation; ranking público antes do card
T3 Time	2-raizfc-fase3-team.jsx	privacy, warnings, viewer, share/report/card e estados parciais	calendário completo, títulos, filtros, métricas sociais separadas, galeria	foundation e evolução aditiva do DTO público
T4 Partida	12-raizfc-fase4-match.jsx	dez status, validação/contestação, viewer, escalação, timeline, súmula, H2H, galeria e prestadores	publicação por lado, técnico/ausências, agregado, forma, campeonato contextual, lembrete, Canal/Mídia	foundation; specs funcionais de partida/campeonato/mídia
T5 Jogador	1-raizfc-fase5-player.jsx	filtros completos, privacy, invite, trajetória e estados	status público separado, idade com privacidade, seguidores, camisa predileta, múltiplos times	foundation e revisão de perfil público
T6 Campeonato	3-raizfc-fase6-championship.jsx	formatos, standings, bracket, inscrições, artilharia, disciplina e regulamento	desempates publicados, sorteio/potes/vagas, slots pendentes, avatar/jogos	foundation e projeção esportiva compartilhada com T4
T7 Torcida	4-raizfc-fase7-torcida.jsx	joinMode, convite, pending, resubmit, permissões e wallet	galeria e apresentação completa sem reduzir o fluxo real	foundation e extensão de galeria
T8 Campo	5-raizfc-fase8-field.jsx	privacidade de endereço, jogos, galeria e claim quando elegível	redesign e card público do campo; claim não pode sumir	foundation e revisão do sistema de share cards
T9 Território	6-raizfc-fase9-territory.jsx	State/Municipality/District/Neighborhood, privacy e merged/inactive	Zone, campos, rankings de jogadores e governança de bairro	specs de domínio, contratos, permissão, auditoria e migração

5. Recorte final de T4 Partida

T4 cobre todos os dez status públicos canônicos. O snapshot bruto demonstrava oito; a working revision working/T4/raizfc-fase4-match.jsx acrescenta result_reported e finished sem mutar o histórico. Loading/error/partial são estados de composição, não status esportivos. O layout final preserva dados, permissões, warnings, retry, metadata/SSR e deep links.

Ordem web registrada para convergência:

1. header, contexto e placar;
2. transmissões, somente quando a capability de mídia estiver aprovada e disponível;
3. timeline e súmula;
4. escalações;
5. classificação contextual;
6. chaveamento;
7. confronto direto e forma recente;
8. galeria e prestadores;
9. patrocinadores, somente conforme domínio público existente.

No mobile, tabs confirmadas são Jogo, Escalações, Competição, H2H e Fotos, omitidas quando sem conteúdo. A timeline permanece cronológica no contrato/exportação e abre visualmente pelo evento recente; DOM/leitura assistiva preservam sequência cronológica ou alternativa equivalente. Galeria não sobrepõe legendas nas miniaturas, mas preserva caption/credit no detalhe e na descrição acessível.

Escalações são publicadas independentemente por lado. O campinho usa asset real, deriva badges da timeline como fonte única, suporta foto/silhueta, múltiplos eventos e +N, e apresenta titulares, reservas, técnico e ausências conforme visibilidade pública aprovada.

Classificação e chaveamento são primitives compartilhadas com T6. Tabela prioriza colunas por desempates do campeonato. Chave mantém slots defined | pending_draw, potes e vagas parciais; mobile mostra uma fase e web uma janela progressiva. A ligação grupo → primeira fase eliminatória faz parte do source graph público de EP-MVP-19.12: deve ser acíclica, section-aware, privacy-safe e coberta por contracts, mocks, API, shared e cenários parciais; não permanece como exceção visual pendente.

Notificar-me e Canal/Mídia não são detalhes visuais: exigem contracts, API/mocks, services/hooks, auth/privacy/security e EPs próprios. Não entram como botão morto ou iframe sem política. Sponsors não fazem parte do snapshot nem do EP de contexto T4 e permanecem omitidos até CR/spec/projeção pública próprios.

6. Features funcionais que exigem tracks próprios

1. Foundation visual v3: quatro modos, tokens, providers, primitives responsivas e assets.
2. Projeções de campeonato: desempates, agregado/perna, chave com origem, sorteio, potes e slots abertos.
3. Publicação e lembrete de partida: visibilidade independente por time, técnico/ausências e assinatura idempotente.
4. Canal/Mídia: ownership, vínculos, moderação, URL segura, allowlist, CSP, sandbox, consentimento, fallback e analytics.
5. Perfis públicos enriquecidos: times, jogador, torcida, campo e share cards sem expor dados privados.
6. Rankings territoriais: fórmulas, desempates, provisório, auditoria e integração editorial.
7. Hierarquia e governança territorial: decisão sobre Zone, membership, voto, quórum, concorrência, histórico e inativação.

7. Exclusões do runtime

• componentes duplicados entre JSX;
• contratos ou enums locais do protótipo;
• dados inline, base64, alerts, toggles, painéis de tema/dev e cenários de harness;
• dangerouslySetInnerHTML para assets importados;
• endpoints fragmentados sugeridos pela referência quando a arquitetura canônica usa composição;
• conteúdo de odds, bet, likes, comentários, avaliação de jogador ou estatísticas profissionais não aprovadas.

8. Fluxo de prototipação a manter

Para uma nova referência externa: registrar URL/prints e aspectos relevantes; ignorar odds; comparar com regras canônicas; apresentar questionário de decisões materiais; aguardar respostas do owner; implementar uma rodada curta; validar todos os caminhos condicionais em runtime; registrar decisões finais na spec e no EP. Referência externa nunca altera identidade por conta própria.

9. Critérios de paridade

• cada tela possui frame mobile e web, quatro modos, extremos de nomes/dados e todos os estados relevantes;
• toda feature do protótipo está classificada como existente, gap aprovado, dependência ou não objetivo;
• nenhuma função canônica desaparece por estar ausente no JSX;
• nenhuma UI lê fixture ou chama endpoint diretamente;
• contracts continuam a fonte de shapes e mocks mantêm parity;
• componentes transversais têm um único owner e implementação compartilhada;
• screenshots e validação de runtime comprovam caminhos condicionais, foco, contraste e reduced motion;
• cada EP fecha review e validation independentes antes de commit/push e do próximo pack.

10. Contrato obrigatório de implementação e validação

Para qualquer EP de redesign ainda não concluído, o protótipo da tela/feature indicado na matriz é entrada obrigatória, não material opcional de inspiração. A implementação deve reproduzir fielmente composição, hierarquia, proporções, tipografia, espaçamento, cores, assets, conteúdo demonstrativo equivalente, responsividade e comportamento interativo, adaptando somente o que specs canônicas exigirem para preservar funções reais, privacidade, acessibilidade ou arquitetura.

Cada EP mantém uma matriz de cobertura com uma linha por elemento ou comportamento observável do protótipo. A linha registra: referência, estado/cenário, implementação web/mobile, origem do dado, contract, mock e API/endpoint quando aplicável, service/hook, teste e evidência visual/runtime. Uma linha só pode ser não objetivo quando houver decisão canônica explícita; ausência de asset, dado, endpoint ou serviço não é justificativa.

Capabilities aprovadas pelo owner devem ser construídas no EP funcional que as possui. Isso inclui evolução aditiva de contracts, cenários de mocks, handlers e endpoints reais, services/hooks e a integração das telas consumidoras. EPs visuais não inventam fixtures nem duplicam fetch; aguardam a capability e então a consomem. O resultado não pode conter CTA morto, comportamento simulado, placeholder substituindo asset disponível ou seção omitida para esconder backend incompleto.

Review e validation independentes devem:

1. abrir o protótipo canônico e o runtime real lado a lado;
2. verificar mobile e web nos quatro modos, larguras extremas e conteúdo longo/curto;
3. exercitar loading, success, empty, partial, restricted, unavailable e error, além dos estados de domínio e permissão do EP;
4. capturar screenshots determinísticas e comparação visual por frame, registrando toda diferença;
5. executar cada ação real e provar efeitos, foco, teclado, reduced motion, persistência, navegação e fallback aplicáveis;
6. auditar a cadeia contract → mock/API → service/hook → UI e impedir fixture inline ou acesso direto;
7. reprovar qualquer divergência não aprovada, ainda que testes estruturais estejam verdes.

Evidência puramente textual, snapshot de componente isolado ou relato do implementer não satisfaz esse gate. completed requer screenshots/runtime, matriz de cobertura completa, contract parity e zero divergência visual ou funcional sem aprovação explícita do owner.

O artifact runtime-results é um único manifesto JSON/YAML schema_version: 1, vinculado ao EP e ao validated_head_sha exato. Ele lista prototype_refs, platforms: [web, mobile], os temas raiz-dark | raiz-light | neutral-dark | neutral-light, viewports com id/platform/width/height, scenarios e frames. Cada frame referencia prototype_ref, actual, platform, theme, viewport, scenario e result: passed; actual aponta para imagem não vazia do mesmo run também declarada em evidence_artifacts.visual-comparison. Reviewer e validator produzem manifests e capturas próprios para o mesmo SHA que promovem. Run ancestral, PNG avulso, manifesto vazio ou combinação de evidências de SHAs diferentes não satisfaz o gate.