T

deploy efc9d35f94 feat(plataforma): o provisionamento passa a LER o repositorio GitOps

A etapa MANIFESTOS_GERADOS renderiza o molde para tenants/<nome> numa copia de
trabalho, e o pod obtem essa copia clonando o Gitea na subida. Clonar e leitura.

Escrever continua fora de alcance, de proposito: empurrar no ramo padrao E o
deploy, e depende de uma credencial que ainda nao existe.

O Gitea aceita clone ANONIMO deste repositorio (conferido com git ls-remote sem
credencial), entao a etapa 1 funciona antes de a credencial de escrita existir.

A MESMA armadilha de rede, pela TERCEIRA vez. De dentro do pod, antes desta
politica: HTTP 000, exit 7. O ipBlock 10.43.0.0/16 da deny-cross-tenant cobre o
ClusterIP do Gitea e nao adianta — o k3s avalia DEPOIS do DNAT, e ali o destino
ja e o IP do POD.

Aconteceu com a API do Kubernetes em 20/09, com o sealed-secrets hoje mais cedo,
e agora aqui. E regra deste cluster, nao coincidencia.

Estreita: so o servico-captacao, so o POD do Gitea por rotulo (namespaceSelector
sozinho abriria a 3000 do namespace inteiro, onde tambem vivem o Valkey e o
runner de CI), so a 3000, so saida.

2026-09-22 22:08:45 +00:00

moldes/consolidado

feat(moldes): o molde do tenant novo entra no repositorio GitOps

2026-09-22 22:07:34 +00:00

platform

chore(platform): sincroniza platform/ com o monorepo

2026-09-21 23:30:21 +00:00

tenants

feat(plataforma): o provisionamento passa a LER o repositorio GitOps

2026-09-22 22:08:45 +00:00

.deploy-notes

chore: push via token Gitea (sem senha no .git/config)