# 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`](05-sealed-db-credentials.yaml) e
[`06-sealed-keycloak-admin.yaml`](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`](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:

```sh
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`.