docs(nexus): adiciona seção sobre importância do Terraform vs Console OCI

- Comparativo de tempo: 90min manual vs 5min Terraform por cluster
- Demonstração do que 1 apply cria (47 recursos)
- Scale up/down: 1 linha no tfvars vs 3 operações manuais
- Infraestrutura como documentação viva (tfvars)
- Lições aprendidas: custo de não usar Terraform (orphans, duplicatas, etc.)

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

inventcloud/invista/nexus/OCI-DEV-NEXUS.md

@@ -543,6 +543,120 @@ tf_oci_clusters (pipeline ID 51)
 
 ---
 
+## 11. Por que Terraform — Importância e Comparativo com Console OCI
+
+### 11.1 O problema de provisionar manualmente
+
+Criar o ambiente DEV Nexus via OCI Console exige navegar por dezenas de telas, preencher formulários e decorar dependências entre recursos. Qualquer erro (subnet errada, CIDR conflitante, security list faltando uma porta) só aparece quando algo não funciona — e não existe histórico do que foi feito nem como desfazer de forma controlada.
+
+Exemplo real desse ambiente: as **8 VCNs orphans** encontradas em 2026-02-25 existiam porque clusters foram criados/destruídos manualmente sem deletar os recursos de rede. Resultado: 104 recursos abandonados consumindo cota sem nenhum registro.
+
+---
+
+### 11.2 Comparativo: Console OCI vs Terraform
+
+#### Criar 1 cluster OKE completo (cluster + node pool + rede)
+
+| Etapa | Via Console OCI | Via Terraform |
+|---|---|---|
+| Criar VCN | ~5 min (telas: VCN, CIDR, DNS) | `terraform apply` |
+| Criar subnets (5x) | ~20 min (cada subnet: nome, CIDR, tipo, route table, security list) | já incluso no `apply` |
+| Criar IGW + NAT + SGW | ~10 min (3 recursos separados) | já incluso |
+| Criar route tables (3x) + regras | ~15 min | já incluso |
+| Criar security lists (3x) + regras de portas | ~20 min | já incluso |
+| Criar cluster OKE | ~10 min (escolher versão, VCN, subnets, endpoint) | já incluso |
+| Criar node pool | ~10 min (shape, imagem, placement, SSH key) | já incluso |
+| **Total (1 cluster)** | **~90 min · propenso a erros** | **~5 min · repetível** |
+| **Total (3 clusters como no DEV)** | **~4–5 horas** | **~5 min (mesma execução)** |
+
+#### Recriar o ambiente do zero (ex.: novo ambiente HML/PROD)
+
+| Cenário | Console OCI | Terraform |
+|---|---|---|
+| Tempo estimado | 1–2 dias (com documentação detalhada) | 15–20 min (`cp -r environments/dev environments/staging` + ajuste de tfvars) |
+| Risco de divergência entre ambientes | Alto — cada clique pode ser diferente | Zero — mesmos módulos, variáveis diferentes |
+| Rastreabilidade | Nenhuma — "alguém clicou em alguma coisa" | Git blame, PR, histórico de apply |
+| Rollback | Manual — deletar na ordem certa | `terraform destroy` ou reverter commit |
+
+---
+
+### 11.3 O que o Terraform garante nesse ambiente
+
+```
+Um único comando:
+terraform apply -var-file=terraform.ci.tfvars
+
+Cria/garante automaticamente:
+  ✅  1 VCN (vcn-oke 10.110.0.0/16)
+  ✅  6 subnets (workers x3, LB x2, api-gateway x1)
+  ✅  3 gateways (IGW + NAT + SGW)
+  ✅  3 route tables com regras corretas
+  ✅  3 security lists com portas OKE (6443, 10250, NodePort, etc.)
+  ✅  3 clusters OKE (cls-dev-nexus / barramento / observabilidade)
+  ✅  3 node pools (np-dev-1/2/3 · VM.Standard.E4.Flex · 2cpu/16gb · 3 nodes)
+  ✅  ArgoCD v7.3.0 instalado via Helm nos 3 clusters
+  ✅  Kubeconfigs gerados em ~/.kube/config-dev-{1,2,3}
+  ✅  API Gateway MFE (api-gateway-mfe-dev) + deployment mfe-user
+  ✅  Alarms de CPU (WARNING 75% / CRITICAL 90%)
+  ✅  Log Group + Dashboard de observabilidade OKE
+
+  Total: ~47 recursos OCI · 1 comando · ~12 min de pipeline
+```
+
+---
+
+### 11.4 Scale up / Scale down em segundos
+
+Um dos maiores benefícios práticos: **ligar e desligar os node pools** sem recriar os clusters.
+
+```bash
+# Desligar workers (economizar custo fora do horário):
+# terraform.ci.tfvars:
+scale_mode = "down"   # node_pool_size_down = 0
+
+# Ligar workers:
+scale_mode = "up"     # node_pool_size_up = 3
+```
+
+Via Console: editar cada node pool individualmente (3 clusters × 1 node pool = 3 operações manuais, ~15 min).
+Via Terraform: alterar 1 linha no tfvars + push → pipeline aplica em todos os 3 clusters automaticamente.
+
+---
+
+### 11.5 Infraestrutura como código = documentação viva
+
+O arquivo `terraform.ci.tfvars` documenta **exatamente** o estado atual do ambiente:
+
+```hcl
+kubernetes_version = "v1.34.1"   # versão do K8s nos 3 clusters
+node_shape         = "VM.Standard.E4.Flex"
+ocpus              = 2            # CPU por worker
+memory_in_gbs      = 16           # RAM por worker
+vcn_cidr           = "10.110.0.0/16"
+node_pool_size_up  = 3            # workers ativos
+enable_bastion     = true         # bastion habilitado
+admin_cidr         = "187.65.249.125/32"  # IP liberado para acesso admin
+```
+
+Qualquer pessoa com acesso ao repositório sabe exatamente o que está rodando — sem precisar abrir o Console OCI.
+
+---
+
+### 11.6 Custo de não usar Terraform (lição aprendida)
+
+| Problema encontrado em 2026-02-25 | Causa | Se fosse Terraform |
+|---|---|---|
+| 2 compartments `cmp-dev-nexus` (um vazio, um ativo) | Ciclo anterior criou manualmente fora do state | Terraform teria gerenciado 1 único compartment |
+| 8 VCNs orphans + 104 sub-recursos abandonados | Clusters destruídos via console sem destruir rede | `terraform destroy` teria removido tudo |
+| VCN-DEV usada para API Gateway (arquitetura incorreta) | API Gateway criado manualmente na VCN errada | Terraform teria posto na subnet correta (`sbn-api-gateway`) |
+| Sem rastreabilidade de quando/por quê recursos foram criados | Console não deixa histórico | Git commit com autor, data e motivo |
+
+---
+
+*Atualizado em: 2026-02-25*
+
+---
+
 ## Referências
 
 | Recurso | OCID / URL |