# Handoff — pendências respondidas pelo dono (retomar na próxima sessão, 2026-07-21) **Base de partida (verificada empiricamente 21/07):** `origin/main = 2517fcd6`, working tree limpo, **main em paridade com o deploy** (zero commits de código após cada imagem viva). Revisões vivas: PRD core-api:79 pix-api:68 spb-api:40 sta-api:19 core-admin-ui:28 sta-admin-ui:10 core-banking-ui:7 core-merchant-ui:5; HML core-api:185 pix-api:196 spb-api:70 sta-api:15 core-admin-ui:35 sta-admin-ui:8 core-banking-ui:35 core-merchant-ui:22. Todos COMPLETED, running=desired, failedTasks=0. **CANÔNICO: STA só opera contra o BACEN em PRD (HML nunca teve credencial); a VPN de PRD está no ar — validação de STA é em PRD.** As 8 pendências abaixo já vêm com a decisão do dono. Ordem de ataque sugerida no fim. --- ## 1. QR dinâmico — cadastro CQRC no BACEN **Dono: "cliente já fez o procedimento."** Ação: **re-validar**, não cadastrar. Confirmar empiricamente que o CQRC novo do 46026562 está registrado e casa com o cert servido: - Baixar via ARQ `certqrc.zip` (PRD) e `certqrc-h.zip` (HML) pela cabine (mTLS; PRD via sidecar `ARQ_BASE_URL`), achar a entrada `46026562_*.cer` e comparar o **SHA-256 do cert registrado com o SHA-256 da folha servida hoje** (PRD leaf `31F652A4...`, HML leaf `A530719...`). Antes do cliente: HML tinha zero do 46026562 e PRD tinha o cert LEGADO `qr.cornerpix.com.br` (C&M). O sucesso = a entrada agora ser o nosso `qrcode(-h).monetarie.com` e bater o fingerprint. - Depois, revalidar o QR dinâmico no **PIX Tester do BACEN** e com uma PSP pagadora. O código (x5c cadeia completa + `typ`/`x5t#S256`) já está no ar (pix HML:196/PRD:68). - Se ainda faltar cadastro, os PEMs prontos seguem no Desktop (`Monetarie-CERTQRC-{homolog-qrcode-h,producao-qrcode}-monetarie-com.pem`). ## 2. TED viva pelo IB — "me responda se preciso solicitar o teste real ao time" **Resposta: NÃO precisa do time.** O defeito do PR#20 era o `NumCtrlIF` estourar 20 chars e a cabine SPB **recusar o STR0008 no gate `:xsd_oficial` ANTES do dispatch ao BACEN**. Esse gate valida o XML localmente na cabine — não depende de o BACEN aceitar a TED. Então dá para provar o fix eu mesmo, dirigindo uma TED pelo IB em **HML** com uma conta de teste custeada: basta a TED chegar ao gate e **passar** (com `NumCtrlIF`=20). Só coordenamos com o time/dono se quisermos a prova ponta-a-ponta com o BACEN homolog liquidando (aí precisa de contraparte), mas isso NÃO é necessário para fechar o PR#20 — o bug era o gate. Plano: login IB como usuário de teste HML → `POST /transfers/ted` → confirmar STR0008 com `NumCtrlIF` 20 chars passando `:xsd_oficial` (log da cabine SPB). Código já provado (20 chars no BEAM de core:79/:185). ## 3. Validação visual por screenshot — SEM desculpa de VPN **Dono: "não tem instabilidade de VPN; o problema é execução minha. A VPN está up desde sempre em PRD, onde o STA está ativo e funcional."** Aceito a correção. Ação: capturar os screenshots **direito**, em **PRD** (STA ativo, VPN up): - STA Vue: Login → Dashboard (card Informações do Sistema, Ambiente=Produção) → Arquivos (lista real, aba Conteúdo, Baixar, filtros de data/sistema) → Configuração (carrega + Salvar + Rotas) → Logs (logs REAIS, pill Conectado) → pill WebSocket. - SisbajudView (CoreAdmin PRD): aba Ordens com filtro de data nascendo VAZIO, aba Requisições de Info (5308), aba Arquivos com tipo 5302×5309. - Disciplina: se der timeout de rota, corrigir o **meu** roteamento/ferramenta (ex.: dois clientes VPN disputando a rota 10.x — resolver antes, não culpar a rede); capturar com Playwright/CDP e mover os prints para o scratchpad. Regra #11: sem screenshot + metadados, não declaro tela validada. - As telas do lote B/C do IB (HML-only) dependem do item 4. ## 4. Deploy do lote IB — "precisa fazer com HML? Se sim, tarefa coordenada depois do item 3" **Resposta: SIM, HML é necessário para banking-ui.** Estado real: main tem `edf4e791` (lote B/C) + `a7064b44` (lote B4-B9); HML `core-banking-ui` só tem B/C (falta B4-B9); PRD banking/merchant não têm NENHUM dos dois. Para paridade e validação visual completa em HML, precisa deployar banking-ui (com a7064b44) em HML. Ação (COORDENADA, **depois** de validar o item 3): (a) deploy HML banking-ui + merchant-ui com o main atual (b4-b9 + b/c) → (b) validação visual em HML (item 3) → (c) só então avaliar deploy PRD banking/merchant-ui. Nada de PRD banking/merchant antes da prova visual (regra #11). Sem migration nesse lote. ## 5. STA follow-ups — "favor desenhar isso" Desenhar (design antes de implementar) cada um: - **(a) Token dedicado `STA_SERVICE_TOKEN`** (rotação independente do webhook): hoje o gate `/api/v1` fail-closed cai no `STA_WEBHOOK_SECRET` compartilhado. Desenho: criar secret `monetarie/{env}/auth/mon_sta/service_token` (KMS = mesma key do mon_sta), adicionar o ARN à whitelist inline da execution role (`monetarie-ecs-execution-prod`/homolog — é IAM/infra, decidir Terraform vs CLI cirúrgico), referenciar como `STA_SERVICE_TOKEN` nos task-defs de Core e STA, deploy Core-primeiro-STA-depois. Sem código novo (a precedência já existe). - **(b) Job de snapshot do saldo da cabine em PRD que não atualizava** (CA-001/002: Liquidação abria "Source: unavailable"/snapshot preso; só atualizava no "Atualizar agora"). Desenhar: achar o worker/cron do snapshot periódico do saldo (camt.053 da cabine) no Core, provar por que não roda/atualiza em PRD (agendado? falha silenciosa? flag?), e corrigir para o saldo ficar fresco sem clique manual. **Overlap com o item 6 (erro silencioso).** - **(c) MetricsView do STA ainda com mock** (mesma classe da tela de Logs que já foi para dados reais): desenhar a substituição por dados reais do backend (endpoint de métricas), sem mock no frontend. - **(d) Aviso "static manifest" no boot do sta-api** (cosmético, API-only): remover `cache_static_manifest`/warm-up de asset no endpoint STA (Core gotcha #6). ## 6. Fail-proof — Postgrex disconnect + varredura de erros silenciosos (MANDATO FORTE) **Dono: "arrumar este e qualquer outro problema pré-existente que possa impactar o fluxo do sistema e causar erros silenciosos. O sistema TEM a obrigação de ser fail-proof, zero margem de erro."** Ação: (a) **corrigir o Postgrex disconnect periódico do pix-api PRD** — a Task da cabine que segura conexão >15s (2-6/h; provado atravessa :61/:62/:63): identificar o Task periódico, provar a causa (long-running query/checkout fora do pool), e corrigir (timeout ≤ teto do pool, checkout curto, ou mover a query pesada para read/async). (b) **Silent-failure hunt sistêmico no money-path e adjacências**: catch-all que dá ACK sem rotear, `rescue`/`catch` que engole erro, fallback que mascara falha como sucesso, job Oban em fila sem worker, evento publicado fora do rollback (outbox), status "processing" eterno, snapshot preso (item 5b), 500 genérico onde deveria ser erro tratado (classe do `show` do STA já corrigido). Usar workflow/agentes adversariais (silent-failure-hunter) por subsistema. Todo achado com TDD + prova viva. Meta: nenhuma margem de erro/falha silenciosa. ## 7. Bloqueado em terceiros — "continuamos aguardando" Sem ação nossa. Só monitorar: SES sa-east-1 (zero identidades → EMAIL_TRANSPORT=ses); conta de tesouraria taggeada p/ SPI_REMUNERATION_SWEEP; ensaio AMES-SIMBA (secret `cloak_key` + operador); infração/MED em HML exige transação LIQUIDADA via outra instituição. Não bloqueia o resto. ## 8. Vulci item 6 (tarifa SLB) — mapear, desenhar e resolver em definitivo **Dono: "temos o `LegadoSPB/*` completo; usar com total discernimento entre o catálogo VIGENTE 5.12 e o catálogo DEFASADO do legado, foco no desenho da solução de negócio."** Ação (3 fases): (1) **MAPEAR** a tarifa SLB no legado (`/Users/luizpenha/mwbank/LegadoSPB/*` + `/Users/luizpenha/cecresa/md/XSDDOCV512`): que mensagem/fluxo SLB o AutBank/LegadoSPB implementa, quais campos, e o que disso é do catálogo **5.12 vigente** vs **defasado** (o legado carrega mensagens antigas que o BACEN já mudou — NÃO copiar cego, discernir). (2) **DESENHAR** a solução de negócio para a Monetarie no 5.12 vigente (o que a SCD precisa emitir/receber de SLB, contabilização, tela), documento de design como os anteriores. (3) **RESOLVER** com TDD + deploy + prova viva. É o último item "em desenvolvimento" da relação Vulci (14/15 atendidos). --- ## Ordem de ataque sugerida 1º **Item 3** (validação visual em PRD, direito) — destrava o item 4 e dá evidência para o cliente. 2º **Item 4** (deploy HML banking/merchant + validação) — coordenado, após o 3. 3º **Item 1** (re-validar QR/CQRC no PIX Tester) e **Item 2** (TED viva no IB HML) — ambos independentes, provas rápidas. 4º **Item 6** (fail-proof: Postgrex + silent-failure hunt) — o mandato pesado, roda em paralelo com agentes. 5º **Item 5** (desenhos STA) e **Item 8** (mapear+desenhar+resolver SLB) — design-first. Item 7 só monitorar. Referências: memórias [[monetarie-sta-v1-auth-failclosed-0721]], [[monetarie-qr-cert-audit-tednumctrlif-0720]], [[monetarie-deploy-stavue-sisbajud-ccs-0720]], [[monetarie-lote-b4-b9-ib-0720]], [[monetarie-varredura-pos-wave1-0718]]; MEMORY.md (bloco PENDÊNCIAS).