# Handoff de orientação e estado: re-seed do homolog e validação enterprise (2026-06-23)

Este documento registra, na íntegra, a orientação do dono e o estado empírico apurado, para que nada se perca ao longo do trabalho. Estilo: português correto, escrita humana, sem travessão de IA.

## 1. Orientação do dono (registrada fielmente)

1. Tudo que for encontrado de problema (bancos, migrações, seeds, configuração) deve ser **mapeado, estudado e corrigido**, para não haver atraso quando subirmos produção.
2. Produzir um **relatório enterprise-grade**, em português com acentuação, escrita bem feita e humana, sem travessão de IA, contemplando:
   - todos os frontends funcionando;
   - todo o branding novo (aplicado em 2026-06-22) presente tanto no login quanto no dashboard e telas internas;
   - sem nada hardcoded, sem mock, sem string de sistema vazando para a tela;
   - 100% validado, navegando por todas as páginas, todas as abas, todos os botões e todos os dados em tela;
   - verificando erros 4xx e 5xx;
   - verificando as traduções;
   - literalmente tudo.
3. Escrever um **handoff detalhado** com toda essa orientação (este documento), bem escrito, com validação e embasamento empírico.
4. Depois do handoff pronto, **voltar ao item da construção das APIs** (a API de Parceiro sistema-com-sistema: OAuth2 client_credentials que emite Bearer JWT de serviço, tabela `api_clients`, chave por usuário no fluxo interno). Decisões já fechadas com o dono: borda privada por enquanto, `api_clients` dedicada, sem shape JDPI (o cliente usa a cabine direto via RSFN).
5. Estilo de escrita permanente: pt-br com acentuação, sem o travessão "—", tom humano. Cada afirmação validada, sem ambiguidade.

## 2. Descoberta crítica: a nova Aurora (VPC 10.45) subiu com bancos vazios

Na migração de VPC de 2026-06-22 (10.40 para 10.45), a nova Aurora `monetarie-core-homolog-45` teve os bancos e as roles criados pela task `monetarie-db-bootstrap-homolog` (que apenas cria roles e bancos vazios), mas a carga de schema e seeds (feita por `Release.migrate` e `Release.seed` de cada serviço) não rodou completa para vários bancos. A validação canônica anterior ("logins OK", 36 screenshots) foi feita no banco antigo (VPC 10.40), que foi deletado.

Estado por banco apurado em 2026-06-23 (conectando como user `mon_core`, via task no ECS):

- `mon_core`: estava VAZIO (0 tabelas). **Corrigido nesta sessão** (migrate completo + production seed + entities + rbac).
- `mon_npc`, `mon_spb`, `mon_sta`: VAZIOS. Pendentes.
- `mon_pix`, `mon_clst`: têm `schema_migrations` e `oban_jobs` (subiram, ao menos em parte). Revisar se estão completos e seedados.

O login do Core dava HTTP 500 porque o `mon_core` não tinha sequer a tabela `users`; o erro de `oban_jobs` ausente era apenas um sintoma adicional.

## 3. O que já foi corrigido no Core (`mon_core`)

- `Monetarie.Release.migrate()` rodou completo: 267 migrações, incluindo a squash `20260101000000` que carrega `priv/repo/sql/mon_core_schema_clean.sql` via `psql` (a imagem do core-api tem `postgresql-client`).
- `Monetarie.Release.seed()` (production) rodou até o fim: institutions = MONETARIE SOCIEDADE DE CRÉDITO DIRETO S.A. (ISPB 46026562), bank_registry, COSIF (200), instrument_kinds, DeRE, etc.
- `entities.exs` rodou OK (`entities = 1`).
- `rbac_seed.exs` rodou OK (módulos, features e grupos, incluindo SUPER_ADMIN).

## 4. Bugs descobertos (mapear, estudar, corrigir antes da produção)

1. **`platform_admin_seed` falha por política de senha.** O secret `ADMIN_PASSWORD` contém um hex de 28 caracteres sem letra maiúscula, e o changeset do admin exige ao menos uma maiúscula. Resultado: `platform_admins = 0` e o login admin (`POST /api/admin/auth/login`) retorna 401. Correção: definir uma senha forte compatível com a política e criar o super admin com ela (e alinhar o secret).
2. **`users_seed.exs` falha com `ERROR 22001` (value too long for character varying(20)).** Algum campo do seed de usuários excede 20 caracteres. Corrigir no seed.
3. **Seed do TigerBeetle falha (`:circuit_open` / `:tb_timeout`).** As contas de sistema do ledger (Cash Asset, Fee Collection, etc.) não foram criadas porque o TigerBeetle está inalcançável a partir do app no momento. Investigar a conectividade do TB (EC2 10.45.1.20) e re-rodar o seed do ledger.
4. **A cadeia do `production.exs` está incompleta.** Ela não chama `entities.exs`, `rbac_seed.exs`, `platform_admin_seed.exs` nem `users_seed.exs`. Por isso o ambiente sobe sem entidade ativa, sem admin de plataforma e sem RBAC. Corrigir a cadeia (ou documentar e automatizar a ordem correta de seed) para que um deploy limpo suba completo.
5. **Avisos dependentes de entidade** (fee_configs, fee_categories, posições RF de cooperado) pulam quando não há entidade ativa ou cooperado com user_id. Parte se resolve após `entities.exs`; o restante depende de ETL/usuários.

## 5. Mecanismo de operação no homolog (para repetir com segurança)

- AWS: conta `990933657879`, região `sa-east-1`, profile `vulcimonetarie`. Nunca usar o profile default (aponta para outra conta).
- O `core-api` roda em **EC2** (não Fargate), ARM64, numa única instância de container com pouca folga de memória (cerca de 822 MB livres). Tasks one-off precisam caber nessa folga (usar `--launch-type EC2` e `memory` reduzido no override; a squash e o migrate cabem em 768 MB).
- Para operar no banco vivo há dois caminhos:
  - **ECS Exec na task viva** (`enableExecuteCommand=true`): `/app/bin/monetarie rpc "<expr>"`. Para comandos que demoram, segurar a sessão aberta alimentando o stdin com `( sleep N ) | aws ecs execute-command ...`, senão a sessão fecha e mata o processo. Para código com aspas, gravar um arquivo via base64 e dar `Code.eval_file`.
  - **Task one-off** (`aws ecs run-task --launch-type EC2`) com `--overrides file://...` montado por script (evita problema de aspas). O seed completo precisa do app inteiro de pé (memória), então roda melhor via Exec na task viva.
- Comandos: `Monetarie.Release.migrate()` e `Monetarie.Release.seed()`. Seeds adicionais (entities, rbac, platform_admin, users) via `Code.eval_file(Application.app_dir(:monetarie, "priv/repo/seeds/<arquivo>"))`.
- Banco do Core: Aurora `monetarie-core-homolog-45`, database `mon_core`, user `mon_core`. Só alcançável de dentro da VPC (o security group libera as tasks ECS, não o Mac via VPN). A Aurora resolve para 10.45.3.209 pela VPN, mas a porta 5432 não abre do Mac.

## 6. Sequência de execução (realista)

1. Terminar de corrigir o Core: criar o super admin com senha compatível (login admin OK), corrigir `users_seed`, restabelecer o TigerBeetle e seedar o ledger.
2. Revisar e corrigir todos os demais bancos: `mon_pix`, `mon_spb`, `mon_npc`, `mon_sta`, `mon_clst` (migrate e seed de cada serviço, a partir da imagem de cada serviço).
3. Corrigir a cadeia de seed no código para que um deploy limpo suba completo (sem depender de passos manuais).
4. Validação enterprise dos frontends: navegar todas as páginas, abas, botões e dados; checar 4xx/5xx; conferir traduções e o branding novo no login e nas telas internas; garantir ausência de mock, hardcoded e string de sistema. Só é possível com o backend 100% funcional.
5. Produzir o relatório enterprise-grade com embasamento empírico (screenshots e evidências, regra #11).
6. Finalizar e manter este handoff atualizado.
7. Voltar à construção das APIs (API de Parceiro). Ver `docs/plans/2026-06-22-monetarie-partner-api-design.md` e o estado em memória.

## 7. Credenciais (registrar no documento restrito de acessos, fora do git)

- Admin Core (platform_admin): `admin@monetarie.com.br` / senha forte a definir nesta correção.
- Demais usuários conforme o seed (a preencher após corrigir `users_seed`).
- Regra #10: senhas reais só no documento restrito com permissão 600, nunca no git nem no relatório do cliente.
- Padronização de senhas (orientação do dono, 2026-06-23): todas as senhas de login de todos os sistemas padronizadas para `Monetarie#Adm2026!`. Já aplicado nos 5 secrets `monetarie/homolog/admin/{core,pix,spb,npc,sta}/initial_password`. O `platform_admin` do Core já está com essa senha.

## 8. Estratégia de certificados PIX (orientação do dono, 2026-06-23)

Enquanto não há acesso ao HSM da RTM, a homologação contra o BACEN segue com certificados ICP-Brasil próprios, guardados no AWS Secrets Manager:

- **PIC** (certificado de conexão): usado no **mTLS** com o BACEN/RSFN (transporte).
- **PIA** (certificado de assinatura): usado na **assinatura XMLDSig** das mensagens.
- O **HSM da RTM fica em stand-by** (`RTM_HSM_ENABLED=false`). O código já prevê o fallback: com o HSM desligado, a assinatura usa a chave privada local do certificado (a PIA), e o mTLS usa a PIC.
- O cliente vai subir a PIA e a PIC pelo recurso de upload de certificado, que deve estar 100% funcional e conectado ao Secrets Manager. Garantir o caminho upload -> Secrets Manager -> consumo (mTLS + assinatura) na cabine PIX. Isso acelera a homologação real contra o BACEN sem depender do HSM.