Status: Approved · v1 · SPEC-DELIVERY-RC-AUDIT-001

depends_on: SPEC-DELIVERY-READINESS-001, SPEC-DELIVERY-RISKS-001

used_by: IS-MVP-15.5

Auditoria de MVP readiness, demo e release candidate

Auditoria final do arco de hardening (EP-MVP-15.1–15.4) contra as oito dimensões da matriz de SPEC-DELIVERY-READINESS-001, mais achados novos desta própria pack (EP-MVP-15.5) e o veredito de go/no-go que fecha o MVP como release candidate.

Método

Os quatro packs anteriores do arco 15.x já auditaram, achado a achado, contract parity (EP-MVP-15.1), permissões/segurança/privacidade (EP-MVP-15.2), performance/acessibilidade/visual (EP-MVP-15.3) e observabilidade/jobs/preparação operacional (EP-MVP-15.4) — ver docs/07_delivery/{security_privacy_audit,performance_accessibility_audit,observability_jobs_audit}.md. Esta pack não repete esse trabalho. Ela faz o que só pode ser feito depois que as quatro auditorias anteriores estão fechadas: rodar os catorze arcos de incremento (01.x–14.x) como um MVP único e verificável, checar a integridade cruzada de specs/IS/EP/index, e emitir o veredito final de go/no-go. Método concreto:

1. Rodar pnpm run quality (typecheck, lint, teste, repository:validate) e pnpm run build do zero, com as mesmas variáveis de ambiente do gate de CI, para confirmar que o baseline aprovado por EP-MVP-15.4 continua verde sem nenhuma regressão.
2. Rodar next dev com mocks e navegar de verdade (Chromium real via Playwright, disponível neste ambiente de execução) por toda a lista "Smoke P0" de SPEC-ARCH-QUALITY-001 mais um conjunto de páginas públicas P1 (torcida, campo, serviço, distrito, bairro) e o fluxo de login/gestão — não apenas verificar status HTTP, mas ler o DOM renderizado e capturar todo erro de console/página.
3. Verificar a consistência entre .ai/execution/index.yaml, increments/index.yaml e o status real registrado no handoff.md de cada Execution Pack (- Status: Completed/Concluído).
4. Revisar docs/07_delivery/risk_register.md linha a linha contra os quatro achados por auditoria e concluir se algum risco aberto é crítico o suficiente para bloquear a release.

Achados desta pack

#	Achado	Severidade	Evidência (antes)	Correção	Teste
1	O link de navegação pública "Jogos" (<nav aria-label="Navegação pública">, presente em oito páginas públicas: campo, distrito, bairro, campeonato, jogador, torcida, serviço e partida — mais o CTA "Ver outros jogos" na página de partida) apontava para href="/games". Essa rota não existe no web — só existe no mobile (apps/mobile/app/(tabs)/games.tsx, a Aba Jogos nativa); a rota real do web para partidas é /matches (apps/web/app/matches/page.tsx). Sem nenhum redirect/rewrite cobrindo /games no next.config.ts, todo clique em "Jogos" nessas oito páginas — a navegação mais básica entre conteúdo público e a lista de partidas — sempre resultava em 404. Confirmado ao vivo: curl -s -o /dev/null -w "%{http_code}" http://localhost:3000/games → 404; confirmado em Chromium real que o clique no link levava ao 404 antes da correção.	HIGH (quebra a navegação P0 mais básica em 8 das 9 páginas públicas do catálogo; nenhum teste automatizado existente cobria hrefs literais de navegação)	apps/web/src/features/{public-field,public-territory (×2),public-championship,public-player,public-torcida,public-service,public-match}/*.screen.tsx — 9 ocorrências de href="/games"	href trocado para /matches (a rota real) nas 9 ocorrências. Verificado ao vivo em Chromium real: clique no link "Jogos" agora navega para /matches (200) e renderiza a lista real de partidas.	scripts/validation/check-mvp-readiness-invariants.mjs (public-nav-broken-games-link, novo guard de regressão permanente, parte de pnpm run repository:validate), com teste próprio (3 casos: baseline atual, regressão sintética, correção sintética)
2	.ai/execution/index.yaml e increments/index.yaml marcavam status: planned/Planned para 45 dos 49 Execution Packs/Increments já concluídos (EP-MVP-02.3 até EP-MVP-15.4), apesar de cada um ter - Status: Completed/Concluído — APROVADO no próprio handoff.md. Os três ponteiros "current" (raizfc.manifest.yaml, .ai/manifest.yaml, .ai/execution/manifest.yaml) também apontavam para EP-MVP-02.4/IS-MVP-02.4, congelados desde a segunda pack do projeto — consistentes entre si (por isso pnpm run docs:validate nunca falhou, já que ele só checa consistência cruzada entre os três ponteiros, não a veracidade do valor), mas sem relação alguma com o trabalho real já entregue. SPEC-DELIVERY-READINESS-001 exige explicitamente "Docs indexes/IS/EP consistent" como critério de aceite.	HIGH (índice de progresso do projeto inteiro estava obsoleto há 13 packs; qualquer agente ou humano lendo .ai/execution/index.yaml/increments/index.yaml para decidir o próximo passo veria um retrato falso do que já existe)	status: planned em 45 entradas de .ai/execution/index.yaml; status: Planned em 45 entradas de increments/index.yaml (mesmo conjunto, mais EP-MVP-14.2/15.1–15.3, que tinham status correto em .ai/execution/index.yaml mas errado em increments/index.yaml); current: EP-MVP-02.4 nos três manifests	Todas as 45 entradas de cada arquivo corrigidas para completed/Completed, uma a uma, cruzando contra o - Status: real de cada handoff.md (nenhuma mudança de status inferida sem essa evidência). Os três ponteiros "current" atualizados para EP-MVP-15.5/IS-MVP-15.5 (esta própria pack, a única de fato em execução). EP-MVP-15.5/IS-MVP-15.5 permanecem planned/Planned até este handoff ser aprovado — não antecipar a própria conclusão.	pnpm run docs:validate (python scripts/validate_repository.py) continua OK após a correção — o script já verificava consistência estrutural, só não a veracidade do campo status; não há guard automatizado para isso (ver "Riscos e pendências" abaixo)

Confirmado íntegro (sem correção necessária)

Verificado por navegação real e leitura direta, não apenas pelas quatro auditorias anteriores:

• Todas as rotas "Smoke P0" de SPEC-ARCH-QUALITY-001 (/ — home feed, /search, /matches, /teams/:slug, /players/:slug, /matches/:id, /championships/:slug, /management, /profile) respondem 200 e renderizam sem erro de console/página em Chromium real. A própria spec nomeia a rota como /feed; o app implementa a home feed em / desde EP-MVP-11.1 — mnemônico da spec diverge do path literal, mas não é um achado (nenhum link do produto aponta para /feed literal; / é a home real e funciona).
• Nove páginas públicas P1 adicionais (/torcidas/:slug, /fields/:slug, /services/:slug, /districts/:slug, /neighborhoods/:slug, /notifications, /support-requests, /reports, /rankings) respondem 200 sem erro de console/página.
• Login real com sessão de demonstração (gestor@raizfc.com.br/Raiz@1234) autentica e chega em /profile corretamente exibindo o perfil real ("Marta Gestora"). Uma navegação de página inteira para /management logo em seguida reseta o MockState em memória do navegador e volta à tela de login — limitação de ambiente já registrada e aceita desde EP-MVP-02.1, não um achado novo desta pack; o management dashboard populado já está coberto pela suíte automatizada (services/api/packages/mocks, centenas de testes via sessão HTTP real, sem esse reset).
• Nenhum outro href literal quebrado: varredura de todo apps/web/src/apps/web/app por href="/..." literal (não Link/router.push dinâmico) encontrou só 4 alvos distintos (/, /matches — pós-correção —, /profile, /search), todos existentes.
• Um 404 de console isolado, não reproduzível: um único evento de console Failed to load resource: 404 apareceu na primeira carga fria de next dev (Turbopack) em uma das execuções desta auditoria; não reapareceu nas 17 navegações subsequentes da mesma sessão nem em nenhuma execução seguinte, e o build de produção (pnpm run build, que não usa Turbopack dev/HMR) não tem equivalente algum. Tratado como ruído do dev server, não um defeito de produto — sem correção aplicada, sem risco novo registrado (nada a mitigar em produção).
• pnpm run quality (typecheck 11 tasks, lint boundaries+ESLint+Prettier, testes) e pnpm run build (7/7 tasks) idênticos ao baseline aprovado por EP-MVP-15.4, sem nenhuma regressão antes das duas correções desta pack — confirmando que os catorze arcos de incremento seguem estáveis.

Matriz de readiness (SPEC-DELIVERY-READINESS-001)

Dimensão	Pronto quando	Evidência desta pack
Produto	MVP/pós-MVP e jornadas estão claros	RELEASE_NOTES.md (o que está entregue) + docs/07_delivery/post_mvp_roadmap.md (trilhas beta/pós-MVP) — ambos revisados nesta pack, sem lacuna nova
Domínio	invariantes, status e autoridade estão definidos	Confirmado pelas 14 arcos de incremento + EP-MVP-15.1 (contract parity) — nenhuma mudança de domínio nesta pack
UX	telas P0/P1, estados, responsividade e acessibilidade especificados	EP-MVP-15.3 (auditoria dedicada) + achado #1 desta pack (navegação quebrada, corrigido)
API/contracts	requests/responses/errors/mocks alinhados	EP-MVP-15.1 (18/18 testes de contract parity, sem regressão nesta pack)
Arquitetura	boundaries e troca mock/API comprovadas	pnpm run lint:boundaries verde; Controller→Application Service→Repository e Route/Screen→Hook→Service→HttpClient preservados — nenhum código de domínio tocado nesta pack
Qualidade	gates e testes críticos executáveis	pnpm run quality verde do zero (typecheck/lint/test/repository:validate) + pnpm run build 7/7 + pnpm run validate:contract-parity 18/18, todos re-executados nesta pack
Operação	security, observability, env e rollback definidos	EP-MVP-15.2/15.4 + runbooks/{deploy,rollback,incident-response,support-operations}.md, revisados sem lacuna nova
IA	manifest, skills, IS/EP e validation funcionam	Achado #2 desta pack (índices obsoletos, corrigido) — os três manifests "current" e os dois índices de execução agora refletem o estado real

Go/no-go

Veredito consolidado, sem nenhum achado BLOCKER ou HIGH em aberto ao final desta pack (os dois HIGH encontrados — navegação quebrada e índices obsoletos — foram corrigidos e verificados antes desta aprovação):

• Demonstração e preview mockado: GO. Os catorze arcos de incremento (01.x–14.x) mais as cinco packs de hardening (15.1–15.5) estão concluídos, testados e navegáveis de ponta a ponta sem link quebrado, com identidade visual profissional/editorial confirmada por EP-MVP-15.3 e reconfirmada nesta pack.
• Staging com dados mockados: GO, mesmas condições do preview.
• Beta com dados reais: segue condicionado, não a esta pack, mas a decisões de infraestrutura fora do artifact boundary de 01.x–15.x (persistência real, auth de produção, storage real, provider Pix real) — já mapeadas como a trilha Beta em docs/07_delivery/post_mvp_roadmap.md e como os incrementos IS-BETA-01.1–01.6 em increments/index.yaml, todos Planned corretamente (não antecipados por esta pack).
• Pagamentos reais: NO-GO, condicionado a provider Pix real e revisão jurídica/compliance dos fluxos financeiros — nenhuma mudança desta pack altera essa condição (SPEC-ARCH-SECURITY-001 R-012, segredo do webhook Pix ainda é placeholder).

Nenhum achado desta pack é de privacidade/financeiro/permissão (escopo residual dessa dimensão já fechado por EP-MVP-15.2, sem achado novo aqui) — a regra "Block release on critical privacy/financial/permission defects" do IS não é acionada.

Riscos e pendências

• R-011/R-012/R-013/R-014 (risk_register.md), herdados de EP-MVP-15.2–15.4, permanecem sem alteração — nenhum deles foi tocado por esta pack.
• Nenhum guard automatizado impede .ai/execution/index.yaml/increments/index.yaml de voltarem a ficar obsoletos — a correção desta pack é um snapshot pontual, não uma trava estrutural (travar isso exigiria, por exemplo, um script que compare status contra o handoff.md de cada pack, fora do escopo desta auditoria de leitura/correção). Cada Execution Pack futuro deve continuar atualizando o próprio status nos dois índices como parte do próprio handoff, disciplina já seguida por EP-MVP-15.1–15.4 mas ausente nas packs anteriores a 14.1.
• Verificação interativa desta pack cobriu Chromium real (web); mobile (Expo/RN) permanece sem simulador disponível neste ambiente de execução, mesma limitação já registrada desde EP-MVP-02.4 — a Aba Jogos do mobile em si não foi tocada por esta pack (o achado #1 é exclusivo do web, que nunca teve uma rota /games).