# Subida para Produção do Ecossistema Monetarie (Core/PIX/SPB): Design > Documento de design validado em brainstorming (2026-07-07). O plano de execução > detalhado (tarefa a tarefa) será escrito em seguida via writing-plans. **Instituição:** MONETARIE SOCIEDADE DE CREDITO DIRETO S.A. (SCD). CNPJ 46.026.562/0001-05, ISPB 46026562, COMPE 526, SISBACEN 00018. **Objetivo:** subir Core, PIX e SPB em produção na conta AWS 990933657879 (sa-east-1), range 10.50.0.0/16, espelhando a topologia de homologação, com um estado inicial limpo, sem os dados de teste que foram colocados em homologação. --- ## 1. Decisões fundacionais (travadas no brainstorming) 1. **Base de infra:** mesma conta 990933657879, adotando a VPC de produção 10.50.0.0/16 existente (fornecida pela RTM) via `data` sources, exatamente o padrão usado com a VPC 10.45 da homologação. Nenhuma VPC criada pelo Terraform. Alinhado ao whitelist RTM #331997 que já cita 10.50.0.0/16. 2. **Dados no go-live:** produção nasce vazia de negócio. Sobem apenas a base de sistema (admin inicial, grupos/permissões, plano de contas COSIF, diretório de instituições, tabelas de referência). Zero conta, saldo, cliente, chave PIX, mensagem ou transação. A migração de dados reais de clientes é um plano separado, posterior e auditado. 3. **mTLS do PIX:** resolvido via HSM (PKCS#11 do RTM). A chave privada do PIC nunca sai do HSM. Depende de o HSM de produção expor PKCS#11 ou equivalente, o que exige um spike de validação com a RTM antes de qualquer dependência. 4. **Limpezas grandes (coop e OnZ):** abordagem map-first. Primeiro produzo um mapa que classifica cada referência, você aprova, e só então executo em ondas com dupla revisão. ## 2. Princípios que guiam o plano - **Paridade de infra, não de dados.** A stack Terraform é a mesma, parametrizada por `env`. Muda `env=prod`, o CIDR (10.50), os endpoints RTM/HSM/MQ/RSFN de produção e os segredos. Nenhum recurso novo inventado, apenas o que já existe em homologação (com as diferenças explícitas da seção 3). - **Seed é só sistema.** Um perfil de seed de produção contendo exclusivamente configuração real. Nada de dado de teste. - **Nada de homologação carimbada.** Referências a homologação viram parametrizadas por `env` ou removidas. - **Tudo provado, nada inferido.** Cada corte tem gate de evidência (eco assinado com cert de produção, health 200, migrations conferidas, seeds contados, rollback documentado). - **Segredos só no Secrets Manager `monetarie/prod/*` e KMS.** Nenhuma senha, UID de HSM, chave privada ou credencial em markdown, tfvars, log ou git (regra #10). ## 3. Workstream A: Infra de produção Novo estado Terraform isolado (workspace/backend próprio, `env=prod`) sobre `infra/aws/greenfield/`. Sufixo `-prod` no lugar de `-45`/`-homolog`. Nenhum recurso de homologação é tocado. Espelhando homologação: - **Rede:** adotar VPC 10.50 e subnets a/b/c, route table, ALB interno, Route 53 privada `monetarie.internal` (zona de produção), VPC endpoints (PrivateLink), OpenVPN (egress RSFN/HSM/MQ de produção), Route 53 Resolver outbound para `rsfn.net.br` de produção. - **Dados:** Aurora ElastiCache e KMS (uma CMK por domínio: core, pix, spb, npc, sta, clst). - **ECS:** cluster `monetarie-greenfield-prod`, serviços Fargate + os serviços EC2 do Core, task-defs com secrets de `monetarie/prod/*`. - **ECR:** mesmos repositórios. Imagens promovidas de homologação para produção por digest (não rebuild às cegas). Diferenças explícitas de produção: - **Aurora PostgreSQL 17.x** (versão 17 GA mais recente em sa-east-1), não a 16 da homologação. - **NATS JetStream com 3 nós** (homologação roda 1 nó). - **TigerBeetle: cluster de 3 nós EC2**, imagem `ghcr.io/tigerbeetle/tigerbeetle:0.17.3` (versão travada, comprovadamente funcional), 3 réplicas com EBS dedicado por nó, **1 nó por AZ** (resiliência de zona). `TB_POOL_SIZE=3` nas cabines e no Core que falam com o TB. Novo módulo Terraform de cluster (generalizar o atual de 1 nó para as 3 réplicas com `--addresses` dos peers). - **MQ Linux de produção `172.31.1.50`** entra na matriz de validação de acessos (o de homologação era `172.31.2.50`). ## 4. Workstream B: Bootstrap de dados - **B1. Auditoria dos seeds.** Levantar todos os seeds (Core/PIX/SPB) e classificar cada bloco: - REAL (sobe): COSIF/plano de contas, tabelas de referência (bancos, error codes, feriados, tipos de mensagem, status catalog, tags de auditoria), grupos/permissões (`group_features`), parametrizações iniciais de sistema. - SUJEIRA (não sobe): participantes de teste, contas/saldos fabricados, chaves PIX de teste, mensagens/transações mock, fixtures MED/fraude, usuários de teste com senha padrão, saldos STR fabricados do Liquidante, simulador BACEN e cenários. - **B2. Seed de produção.** Perfil `SEED_PROFILE=prod` (ou `seeds/prod/*`) que roda só os blocos REAIS mais o admin inicial. Senha inicial gerada só no Secrets Manager, troca obrigatória no primeiro login. - **B3. Migrations.** Todas rodam limpas no Aurora de produção via `rpc` (não `eval`, gotcha conhecido). Sem os upserts destrutivos de dados de teste. Conferência de contagem pós-migration (referência bate, negócio igual a zero). - **B4. Parametrizações iniciais.** ISPB 46026562, COMPE 526, SISBACEN 00018, endpoints BACEN de produção (DICT/ICOM/RSFN de produção, não homologação), flags de negócio no estado seguro (ENVIO desabilitado até o eco, limites e alçadas iniciais). - **B5. Diretório de instituições.** Construído a partir da fonte oficial de produção do BACEN concatenada com o fluxo de participantes que já existe no PIX (`Shared.Bacen.PixParticipants.ImportWorker`, que puxa de `www.bcb.gov.br`), reconciliando ISPB a ISPB e cruzando com os certs dos bundles Ativados (SPB e MES). Um diretório único e bem construído. **Admin inicial:** `admin@monetarie.com` para os 3 sistemas. Senha inicial fornecida pelo dono, gravada exclusivamente no Secrets Manager `monetarie/prod/admin/*`. Observação registrada: o domínio institucional é `monetarie.com.br`; confirmar se `admin@monetarie.com` (sem `.br`) é intencional antes do provisionamento. **Gate:** dump do estado inicial provado (referência com contagem esperada, negócio zerado, 1 admin por sistema, zero registro com marcador de teste). ## 5. Workstream C: Higiene de código Vale para o código compartilhado, logo para homologação e produção (as mesmas imagens servem os dois ambientes). - **C1. Cooperativa para SCD (576 refs no Core admin), map-first.** O Core admin foi construído sobre um modelo de cooperativa de crédito (CooperativeRole com caixa/atendente/gerente/diretor/ conselheiro/auditor, CooperativeMember, cooperados_ativos, relatórios de cooperados, receita cooperativa/não-cooperativa). A Monetarie é SCD. - Fase 1 (mapa aprovado): classificar cada referência em i18n/labels, types/interfaces, rotas/URLs, relatórios, campos de dashboard/contábil, marcando INCOMPATIVEL-SCD (renomear/ remover) vs GENERICO (manter). Governança cooperativa (conselheiro, assembleia, quadro social) sai; conceitos que são só cliente/instituição/usuário com nome infeliz são renomeados para o vocabulário SCD. - Fase 2: execução em ondas (i18n, depois types, rotas, relatórios, backend correlato), cada onda com build verde, revisão spec e revisão de qualidade. Rotas mantêm redirect de compat quando necessário. - **C2. Nomenclatura de homologação.** Hardcode de homolog/HML/homologação vira parametrizado por `env` (mostra PROD/HML conforme o deploy) ou é removido (texto morto). Endpoints/URLs de homolog hardcoded viram config por `env`. - **C3. Dedup de menus.** Consolidar itens duplicados (Administradores vs Usuários Admin no Core, e varredura de duplicidade equivalente nos 3 fronts) num único item, rota canônica mantida, redundante removida com redirect quando preciso. - **C4. Remoção OnZ/AvivPay (272 refs), map-first.** O Core foi construído para sentar sobre um provedor PIX externo OnZ/AvivPay CloudPIX e reconciliar contra ele (ONZ_BASE_URL, poller, MGMT query, login OnZ, CaixaAvivView, SettlementBalanceCard com "saldo real OnZ" e "saldo próprio AvivPay", e backend em money-path: money_boundary, tb_first/handler, reconciliação órfã e pós-deploy). A Monetarie tem a própria cabine PIX, não usa OnZ. - Fase 1 (mapa aprovado): classificar em (a) integração OnZ pura (remover), (b) lógica de reconciliação/settlement que deve apontar para a nossa cabine em vez do OnZ (readequar), (c) rótulos (renomear). - **MGMT Query: readequar, não remover.** Manter o contrato de resposta e trocar a fonte: em vez de consultar a API MGMT do OnZ, disparar uma camt.060 de consulta de operação (`detalha-lancto`, `ReqdMsgNmId=camt.054`, `RptgReq/Id=E2E`) contra a nossa cabine/BACEN (o caminho comprovado nesta bateria: ACK 201 seguido de camt.054 com valor/ISPBs/status) e mapear o camt.054 para o mesmo formato que a tela já espera do retorno OnZ. A UI não muda, só a origem verdadeira dos dados. Contrato documentado no mapa antes de executar. - Fase 2: execução em ondas com atenção redobrada ao money-path (não quebrar crédito e reconciliação), build e testes verdes, revisão dupla. **Gate:** `grep` de coop/homolog/OnZ/Aviv volta só o que foi conscientemente mantido (documentado nos mapas). Build dos 3 fronts verde. Fluxo de crédito PIX-in e reconciliação provados ao vivo sobre a cabine Monetarie. Screenshots antes/depois dos menus (regra #11). ## 6. Workstream D: Trilhas de auditoria (3 fronts) Cada front consome uma trilha diferente, então cada um é investigado separadamente. - **D1. Diagnóstico por front (banco vivo).** - PIX admin: `GET /api/v1/audit/logs`. Verificar se a trilha de ações administrativas (login, mudança de config, aprovação de alçada) é gravada e lida. `xml_audit_logs` já popula; o gap provável é a trilha de ações do usuário. - SPB admin: `GET /admin/audit-trail` e `/admin/audit-reports`. Checar se ações são registradas e se a tela lê a fonte certa. - Core admin: não há chamada de serviço de auditoria no front. O Core tem `monetarie.audit` (schema) e loggers específicos (CADOC/SISBAJUD/SIMBA). Mapear o que existe vs o que a tela espera. - **D2. Fechar a malha.** Garantir que eventos sensíveis são gravados (plug/middleware de auditoria em login, CRUD de usuário/grupo/permissão, mudança de config, aprovações, operações BACEN), lidos pelo endpoint certo e exibidos com paginação/filtro. - **D3. Dicionário de tags.** Definir e documentar cada tipo/tag (AUTH_LOGIN, CONFIG_CHANGE, USER_CREATE, ALCADA_APPROVE, BACEN_SEND, DAY_OPEN etc.), com origem (SYSTEM/USER/BACEN), severidade e retenção. Semeado como tabela de referência de produção e exibido como legenda nos 3 fronts. **Gate:** ação real disparada em cada front (ex.: login mais criar grupo) aparece na trilha com a tag correta, provada ao vivo e screenshot. ## 7. Workstream E: Cripto, certs e HSM de produção - **E1. Truststore ICP-Brasil (cadeia completa).** Montar o `icp_brasil_ca_chain.pem` de produção com toda a cadeia: Raiz Brasileira v5/v10/v11/v12, AC SERPRO SSLv1, AC SERPRO Final SSL, CSPB-1/CSPB-6, AC VALID SPB v5. Validar cada caminho (`openssl verify`) antes de subir. Sem a cadeia completa, o `verify_peer` e a verificação XMLDSig dão erro intermitente. - **E2. Peers do BACEN (ISPB 00038166).** `PIA-P515` (verifica assinatura do BACEN no PIX), `PIC-P514` (`CN=*.pi.rsfn.net.br`, pin do TLS do BACEN no mTLS), `SPB-P060` e `MES-P061` (verificar SPB/MES). Todos AC SERPRO. - **E3. Diretórios Ativados.** Bundles `Ativados-SPB` e `Ativados-MES` (um `.cer` por ISPB) carregados no CertificateRegistry para verificar assinatura de qualquer participante. - **E4. Nossos certs no HSM de produção.** PIX: `PIA P003` (assinatura, no HSM) e `PIC P002` (mTLS via PKCS#11 do HSM). SPB: os 2 certs MONETARIE SCD P001. Só os públicos entram no repo/registry; as privadas ficam no HSM de produção, com UIDs em Secrets Manager `monetarie/prod/*`, nunca no repo. - **E5. Endpoint do HSM de produção.** Novo endpoint RTM de produção (não o `-hml`), configurado por `env`. Spike bloqueante: validar que o HSM de produção expõe PKCS#11/assinatura para PIA e mTLS-PIC antes de depender dele; localizar/confirmar os UIDs de cada chave (locate-all no HSM). - **E6. Validação por eco (gate final do go-live BACEN).** Pós-deploy, com o BACEN de produção: pibr.001 assinada (PIX) esperando 201 mais eco pibr.002; eco/GEN0001 assinado (SPB) esperando 201. Prova de que assinatura, mTLS, cadeia e endpoint estão 100%. Só depois disso o ENVIO real é considerado apto. **Gate:** eco assinado aceito (201) em PIX e SPB com os certs de produção, com evidência. ## 8. Workstream F: Cutover, ordem, gates e rollback Sequenciamento (dependências reais): 1. Higiene de código (C1 a C4, D) primeiro, em homologação, imagens promovidas depois para produção. Cada onda com build, testes, revisão dupla e evidência. 2. Infra de produção (A): Terraform `env=prod` na VPC 10.50. `terraform plan` revisado antes do `apply`. 3. Bootstrap (B): migrations limpas, seeds só-sistema, diretório de instituições, admin inicial. 4. Cripto/certs (E): truststore/cadeia, peers BACEN, Ativados no registry, nossos certs no HSM de produção (spike PKCS#11 antes). 5. Validação de acessos: RSFN, HSM e MQ (`172.31.1.50`) de produção conectam e autenticam. 6. Deploy dos serviços (imagens por digest, promovidas de homologação) na ordem SPB, PIX, Core. 7. Gate BACEN: eco assinado (pibr.001 PIX e GEN0001 SPB) com certs de produção retornando 201. Gates que travam avanço: build/testes verdes, `terraform plan` limpo, migrations conferidas (negócio igual a zero, referência conforme esperado), health 200 nos hosts, acessos RSFN/HSM/MQ provados, eco assinado aceito. Nenhum ENVIO real liberado antes do eco. Rollback: infra de produção isolada (não toca homologação), cada serviço com revisão anterior, seeds e migrations reproduzíveis, flags de negócio no estado seguro (ENVIO desabilitado até o eco). Evidências (regra #11): cada gate com prova viva (screenshot, JSON, log), consolidadas num handoff de go-live. ## 9. Riscos e pré-condições externas - **HSM de produção com PKCS#11** para o mTLS do PIC (spike E5 é bloqueante do go-live PIX). - **Endpoints RTM de produção** (HSM, MQ `172.31.1.50`, RSFN) liberados e autenticando para a origem 10.50. - **VPC 10.50 provisionada** pela RTM e adotável via `data` sources. - **Certs BACEN com validade curta:** SPB-P060 e MES-P061 vencem em 2026-09-01; monitorar renovação. - **Confirmar o e-mail do admin inicial** (`admin@monetarie.com` vs `admin@monetarie.com.br`). ## 10. Próximo passo Escrever o plano de execução detalhado (writing-plans), tarefa a tarefa, começando pelos mapas das Fases 1 de C1 (coop para SCD) e C4 (OnZ/AvivPay) para aprovação antes de qualquer execução.