# Proposta de publicação do portal do parceiro (decisão do dono)

Data: 2026-07-18. Frente F4 (Wave 1). Este documento apenas compara opções e recomenda; NENHUMA infraestrutura foi alterada. A execução da opção escolhida é do orquestrador, fora do plano F4.

## Inventário (sondado read-only em 18/07)

- O service ECS `docs-portal` existe e está vivo em HML e PROD (`infra/aws/greenfield/ecs.tf:350-357`), com ECR `monetarie/docs-portal`, task-def própria e regra de ALB por host `docs<sufixo>.monetarie.internal` (prioridade 190, `alb-internal.tf:119-125`).
- A imagem ATUAL do `docs-portal` (`docs-portal/Dockerfile`) copia TODA a documentação interna do repositório para `/raw/`. Essa exposição foi mapeada em 24/06 e o takedown está PENDENTE por ordem do dono (memória `monetarie-docs-h-internal-exposure`).
- `docs/partner-portal/Dockerfile` é uma imagem nginx própria e limpa: serve somente o build do portal (`.vitepress/dist`, que embute a collection Postman em `/Monetarie-Partner-API.postman_collection.json`), health em `/health`, porta 8080. Não tem Terraform associado.
- Não existe NENHUM `aws_s3_bucket` no Terraform greenfield (grep vazio); publicar por S3/CloudFront exigiria infra nova.
- Clientes já possuem perfis OpenVPN emitidos (memória `monetarie-openvpn-client-issuance`), então um host interno É alcançável pelo cliente.

## Opção A (recomendada): reaproveitar o service `docs-portal` existente

Buildar a imagem a partir de `docs/partner-portal/Dockerfile` (nginx limpo servindo só o dist do portal trilingue + a collection), push para o ECR `monetarie/docs-portal` e `force-new-deployment` no service existente (HML e, se aprovado, PROD).

- Zero Terraform: service, ALB rule, DNS e ECR já existem.
- BÔNUS: executa na prática o takedown pendente da exposição interna do docs-h, porque a imagem nova NÃO contém `/raw/` nem qualquer doc interna.
- Acesso do cliente: host interno via perfil OpenVPN já emitido.
- Riscos e mitigação: o host `docs`/`docs-h` passa a servir SOMENTE o portal do parceiro (a doc interna sai do ar; é exatamente o objetivo do takedown, mas precisa da confirmação do dono). A task-def atual referencia tag mutável; recomenda-se atualizar a task-def com tag IMUTÁVEL (padrão dos demais deploys) na execução.

## Opção B: takedown puro + entrega como artefato

`desired-count 0` no `docs-portal` e entrega do portal ao cliente como zip/PDF (status quo de 14 a 17/07). Zero infra e resolve a exposição, mas sem link vivo nem atualização contínua.

## Opção C: S3/CloudFront público

Não existe bucket no Terraform; exigiria infra nova (vetado nesta frente). Registrada como caminho futuro caso o dono queira acesso sem VPN (por exemplo para integradores externos sem perfil OpenVPN).

## Recomendação e perguntas ao dono

Recomendação: **Opção A**.

1. Aprova o conteúdo do host `docs` virar exclusivamente o portal do parceiro (takedown da doc interna junto)?
2. Publicar em HML apenas, ou HML + PROD?
3. Atualizar a task-def com tag imutável na mesma execução?