athletic-map-deploy/tenants/plataforma

Tenant plataforma

Este não é um cliente. É onde a Athletic Map opera a si mesma: o namespace, o banco e o realm da própria empresa, separados dos clientes e separados também do tenant de demonstração.

Gerado em 2026-09-17 pela tarefa P3.1 (card 137).

Estado: preparado, não aplicado

Nada aqui foi publicado. Os manifests estão prontos para o ArgoCD, mas faltam duas credenciais que só um humano pode gerar — veja 05-sealed-db-credentials.yaml e 06-sealed-keycloak-admin.yaml. No lugar dos SealedSecret há um ConfigMap marcador, com nome impossível de confundir (CREDENCIAL-DO-BANCO-NAO-FOI-GERADA) e com o comando kubeseal a rodar.

Enquanto os marcadores estiverem no lugar, o postgres e o keycloak não sobem. É deliberado: melhor não subir do que subir com senha conhecida.

Por que o assistente não gerou as credenciais: SealedSecret é selado para um namespace. O do piloto-prod não decifra em plataforma-prod — o controlador recusa. E gerar segredo novo significaria escrevê-lo em algum lugar antes de selar, o que o preâmbulo das tarefas proíbe.

O que este tenant leva, e o que não leva

Um cliente roda 13 contextos. Aqui rodam 4, porque a Athletic Map não é uma escolinha — não tem atleta, treino, campeonato nem prontuário.

Leva	Para quê
servico-configuracao	catálogos e parâmetros
servico-cadastro	pessoas — os próprios funcionários
servico-financeiro	o financeiro da casa (veja a ressalva abaixo)
servico-captacao	só existe aqui: os leads da landing page
bff + frontend-spa	a porta de entrada
postgres, keycloak, backup	a infraestrutura do silo

Não leva, de propósito:

• os 9 contextos restantes (agenda, saúde, pedagógico, nutrição, campeonato, organização, planejamento, assistência social, administrativo) — sem uso aqui;
• o 30-apps-stubs.yaml do piloto, que carrega o stub backend legado. P0.5 mediu: 11 requisições externas em 50 dias, todas 401. Tenant novo não nasce com dívida, então o Ingress foi escrito do zero (30-ingress.yaml) e sem o catch-all /api.

Domínio

Hoje: plataforma.athleticmap.influxdigital.com.br e auth-plataforma.athleticmap.influxdigital.com.br.

Não é o canônico. O canônico decidido em 2026-09-16 é <tenant>.athleticmap.com (P0.9), mas o corte ainda não foi executado. Conferido em 2026-09-17: plataforma.athleticmap.com não tem registro A, e o apex athleticmap.com resolve para 72.61.42.87, que não é o cluster (187.77.37.184). Como o cert-manager usa desafio HTTP-01, nascer no .com hoje daria certificado não emitido e login quebrado.

*.athleticmap.influxdigital.com.br é wildcard para o cluster, então este tenant sobe já e deve atravessar o corte junto com os demais, no passo 5 do plano.

Atenção — este tenant NÃO está no corte preparado. O plano vive em docs/p09-plano-de-corte-dominio.md, que não existe nesta branch: está em feat/dominio-app-athleticmap (commit f71480a). E esse commit altera acme, demo e piloto — o plataforma ainda não existia quando foi escrito. Quem executar o P0.9 precisa incluir esta pasta à mão, senão ela fica sozinha no domínio do fornecedor.

Os hosts a trocar aqui estão em 30-ingress.yaml, 20-keycloak.yaml, 35-realm-import-cm.yaml, realm/athleticmap-realm.json, 95-frontend-spa.yaml, o ATM_ISSUER dos quatro serviços e o CAPTACAO_ORIGEM.

Uma ressalva sobre "cobrar a si mesma"

O card 137 descreve este tenant como "onde a Athletic Map cobra a si mesma". Isso contradiz project-docs/Escolinhas esportivas/Produto e negócio/Planos de assinatura.md:137, que diz: "Billing da assinatura é outro sistema. O servico-financeiro cobra o aluno do cliente; cobrar o cliente exige gateway próprio (Asaas, Stripe, Iugu) e ciclo de inadimplência/suspensão — não dá para reaproveitar."

O tenant foi montado assim mesmo porque a infraestrutura é idêntica nas duas leituras — namespace, banco, realm e login não mudam. O que muda é se o servico-financeiro daqui serve para cobrar assinatura. Isso está em aberto e é o que os cards 138 (P3.2) e 139 (P3.3, Asaas) decidem.

Como verificar, quando for aplicado

O critério do card é "login no tenant plataforma funciona e o financeiro abre vazio". Depois de gerar as duas credenciais e deixar o ArgoCD sincronizar:

kubectl -n plataforma-prod get pods          # postgres, keycloak e os 6 serviços prontos
kubectl -n plataforma-prod get ingress       # certificado emitido, ADDRESS preenchido
curl -sI https://plataforma.athleticmap.influxdigital.com.br | head -1   # 200

O "financeiro vazio" é o esperado: banco novo, nenhuma cobrança. Se vier dado, o tenant está apontando para o banco errado — pare e confira o 05-sealed-db-credentials.yaml.