# Handoff: frente de qualidade CoreAdmin + STA (relatório de bugs do cliente) + fix openingDate do IB Data: 2026-07-17 (noite). Sessão da frente de QUALIDADE (paralela à sessão money-path, que trabalha na mesma árvore). RETOMAR POR ESTE ARQUIVO. Plano de origem: `docs/plans/2026-07-17-relatorio-bugs-coreadmin-sta-mapeamento-plano.md`. ## 1. Estado do git (CONFIRMADO) - `origin/main = ef27c21d`, working tree LIMPA (zero modificação não commitada; só `diversos/` untracked, que não é desta frente). - TUDO desta sessão está commitado E pushado na main: - `b0cd09ad` fix openingDate do cadastro de chave PIX pelo IB (DEPLOYADO em HML). - `2cdb1d0b` handoff do openingDate com validação viva. - `ef27c21d` merge do lote de qualidade CoreAdmin (branch `fix/coreadmin-bugs-relatorio-0717`, 6 commits `163b1605..b540667b`; branch e worktree já REMOVIDAS, conteúdo 100% na main). - `75a9eed1` docs: análise R2 (COSIF) + mapeamento dos 4 docs do cliente. - Suítes re-provadas NA MAIN pós-merge: vitest admin 373/373 (52 arquivos), backend alvo (cosif + admin controllers + opening_date) 31/0, build do admin verde. - A main está APTA a subir tudo que está pendente de deploy (seção 3). ## 2. FEITO E DEPLOYADO (HML) ### 2.1 Fix do cadastro de chave PIX pela tela do IB (openingDate) - Detalhe completo: `docs/handoff/2026-07-17-fix-cadastro-chave-ib-openingdate-handoff.md` (causa, prova, solução, validação). - Resumo: `V2.PixController.create_key` não enviava `opening_date`; BACEN rejeitava 100% dos cadastros do IB. Fonte única nova `Monetarie.Util.DictOpeningDate` usada pelo IB e pelo Partner. - HML: core-api task-def `:162` (imagem `homolog-b0cd09ad-openingdate-20260717`, rollback `:161`). Validado vivo como o cliente Gabriel: ANTES 422 na `:161`, DEPOIS 202 com EVP do BACEN na `:162`, listagem ACTIVE, chave de teste excluída (DICT homolog limpo). - **PRD SEGURADO por ordem do dono.** Atenção: a imagem `:162` foi buildada ANTES do merge do lote (seção 3); o deploy PRD do openingDate pode (e deve) já sair da main equalizada com o lote junto, num build novo. ## 3. PRONTO NA MAIN, AGUARDANDO DEPLOY ### 3.1 Lote de qualidade CoreAdmin (22 dos 26 CA do relatório do cliente) O que corrige (tudo com TDD RED provado antes + revisão adversarial de 8 ângulos): - CA-007/019/020 (R3): enum `ready`≠`done` do detalhe de taxas (com download consertado pela rota autenticada `?download=true`), `members_with_balance_count`, `member_number`. - CA-018/021 (R5): export PDF de TODO o Reports Hub quebrado (jspdf-autotable v5 ESM não registra `doc.autoTable`); agora API funcional + toast de erro. - CA-003 (R6, BACKEND): consolidado da Liquidação não exclui mais transactions com `entity_id` NULL (100% das linhas de PRD). - CA-009/010 (R9, BACKEND+front): `duplicate_e2e` com valores agregados/direção e TODA divergência com data (coluna Data ordenável na tela). - CA-004/008/015 (R4): fonte única `src/lib/enumLabels.ts` (paridade com os enums do backend garantida por teste, incluindo `payment_status` completo: accepted/timeout/refunded). - CA-024/023 (R8): paginação da Gestão de Clientes não volta mais para a página 1; Extrato da conta navega por `query.accountId`. - CA-006/013a/014 (R10): estados vazios (a prop `emptyMessage` NÃO EXISTE no DataTable do PrimeVue v4, virou slot `#empty`), Créditos SPB abre em Todos. - CA-005/012/016 (R11): chips PIX (E2E)/TED (STR), "Captura nº" com tooltip, cores débito/crédito no grid. - CA-017/022 (R7): grid de 5 KPIs numa linha. CA-025 (R12): Caixa Institucional fora do menu. - NÃO incluído: CA-001/002/011 (=R1, seção 4), CA-026 (=R2, seção 5), CA-013b (decisão de produto: cabine PIX como disponibilidade, depende do R1), STA-001/002 (R13, feature de sessão própria). Deploy necessário: `core-admin-ui` (o grosso, isolado e sem risco) + `core-api` (R6/R9; sem migration). Receita HML: `./scripts/deploy_hml_arm64.sh homolog-ef27c21d-qualidade-20260718 core-api` e idem `core-admin-ui`. Validação pós-deploy sugerida (dados reais, nunca fixture): Liquidação (consolidado aparece; status traduzidos; chips), Reconciliação Contábil PIX (coluna Data), Relatório de Taxas (Gerar detalhe termina em Pronto e baixa CSV), Saldo Diário CC (card e coluna), export PDF de qualquer relatório do hub, paginação de Gestão de Clientes. ### 3.2 PRD (tudo SEGURADO até comando do dono) Quando liberado, na ordem de menor risco: build/retag da main equalizada (mesmo digest homolog, imagetools, guard MATCH) para `core-api` e `core-admin-ui` PRD. A task-def PRD do core-api avança também pela sessão paralela: registrar SEMPRE em cima da revisão vigente na hora (hoje `:64`). O R1 (4.abaixo) pode pegar carona na MESMA task-def nova do core-api PRD (troca de env + imagem num registro só). ## 4. R1: login da cabine PIX em PRD (CA-001/002/011) - PRONTO, aguarda OK - Provado vivo (2x nesta sessão): cabine PIX PRD aceita `admin@monetarie.com` (200) e recusa `admin@monetarie.com.br` (401). A task-def `monetarie-core-api-prod` usa o `.com.br` errado em `PIX_CABIN_ADMIN_LOGIN`. HML usa `.com.br` e LÁ está correto (200). Fix é SÓ PRD, 1 env var, sem rebuild. - Aplicação: registrar task-def nova de `monetarie-core-api-prod` trocando `PIX_CABIN_ADMIN_LOGIN` para `admin@monetarie.com` + update-service. Combinar a janela (sessão paralela também deploya core-api). - Validação pós-fix: tela Reconciliação Tesouraria, botão "Reconciliar agora": card mostra o saldo real da Conta PI (não "Indisponível") e o gráfico histórico volta a plotar. ## 5. R2: Conta de Liquidação COSIF -R$ 253,8M (CA-026) - CAUSA PROVADA, reparo aguarda dono + contador - Análise completa com evidência: `docs/reports/2026-07-17-analise-cosif-conta-liquidacao-negativa-r2.md`. - Resumo: acervo COSIF PIX de 13-14/07 envenenado (pré-fix de 10/07): 2 lançamentos do mesmo E2E com direção invertida e unidade 100x/10000x + 4 órfãos idênticos de R$ 13,7M. Mensais são sãos (+R$ 1,03M). É espelho regulatório: NADA de TB/dinheiro real envolvido. - Reparo proposto (NÃO executar sem OK): estorno/expurgo dos 6 lançamentos + relançamento correto do E904...134524 (D liquidação / C cliente, 2.000.000 centavos) + recomputo dos snapshots diários. Validar com a tela de Reconciliação Contábil PIX em 13-17/07 (o lote novo mostra Data e valores do duplicate). ## 6. Mapeamento dos 4 documentos do cliente - FEITO - `docs/reports/2026-07-17-mapeamento-4-docs-cliente-core-spb-pix.md`: ACCS/CCS, Relatórios Vulci, BACENJUD, 4111/APIX001/6209/AMES, classificados por sistema (core / cabine SPB / cabine PIX / STA / integração) com arquivo:linha, status EXISTE/PARCIAL/FALTA e validação viva em HML (endpoints CCS, SISBAJUD, CADOC, SIMBA, reconciliação = 200). - Divisão decidida pelo dono: itens de CORE primeiro; SPB e PIX depois de fechado o core. A lista de próximos passos por frente está no fim do relatório. ## 7. LOGS DE PRODUÇÃO - diagnóstico feito, melhoria MAPEADA (aguarda OK para executar) Diagnóstico empírico (17/07): - Apps ECS PRD: CloudWatch Logs `/ecs/monetarie/prod/` (sidecars no mesmo grupo com stream próprio), retenção de APENAS 14 dias em todos, sem archive. - Aurora PRD `monetarie-core-prod-50`: export de logs PostgreSQL para CloudWatch DESLIGADO. - ALB interno PRD: access logs DESABILITADOS (sem S3). - NATS/TigerBeetle (EC2): logs locais nas instâncias, sem CloudWatch. Plano de execução (dono já sinalizou querer; confirmar os NÚMEROS de retenção antes de rodar): 1. Retenção money-path (proposta 365 dias; instituição financeira com operação BACEN): `awsmon logs put-retention-policy --log-group-name /ecs/monetarie/prod/core-api --retention-in-days 365` (repetir para `pix-api`, `spb-api`, `sta-api`; UIs proposta 30 dias; considerar HML 30 dias tambem.) 2. Aurora PRD, export postgresql: `awsmon rds modify-db-cluster --db-cluster-identifier monetarie-core-prod-50 --cloudwatch-logs-export-configuration '{"EnableLogTypes":["postgresql"]}' --apply-immediately` (mudança dinâmica, sem downtime esperado; conferir no console após aplicar; gera custo de ingest.) 3. ALB access logs: criar bucket S3 dedicado (policy de log delivery da região sa-east-1) e ligar `access_logs.s3.enabled=true` no `monetarie-internal-prod-50` via `modify-load-balancer-attributes`. 4. Opcional (estudo): CloudWatch agent nas EC2 de NATS/TigerBeetle ou pelo menos logrotate + snapshot; hoje o log morre com a instância. Custo: retenção maior só muda armazenamento (~US$0,03/GB/mês; volume atual total ~300 MB, irrelevante); export do Aurora cobra ingest. ## 8. Follow-ups registrados (não bloqueiam nada) - Varredura da prop inerte `emptyMessage` (~130 ocorrências em ~90 views do CoreAdmin, mesma classe do CA-006). O lote corrigiu as 2 tabelas da tela reportada. - Decisão multi-tenant do `entity_id IS NULL` no consolidado: as queries irmãs da MESMA tela (rankings, timeseries) mantêm o filtro estrito e possivelmente também zeram com entity na sessão (candidatas a CA-003 latentes). Hoje mono-entity, sem urgência. - Do handoff do openingDate: accountNumber no DICT = id interno (não o número textual da conta), teto de 50 na listagem de chaves da cabine, casing EVP no entry_controller do pix-admin. - R13 (STA-001/002): gestão de usuários + Meu perfil no STA. O backend já tem users+RBAC+login; falta controller CRUD, troca de senha própria e telas. Feature para sessão dedicada. ## 9. Gotchas e receitas desta sessão - Túnel para HML: SSM port-forward na EC2 NATS HML `i-02ce3a3b6b3ad0d37` para o ALB interno, Host header roteia (`coreapi-h.monetarie.internal` etc.). PRD idem via `i-0c9cd61aa15983b89`. - Login admin do core = `POST /api/admin/auth/login`. Login do IB = `POST /api/auth/login` com campo `document` (não cpf/email). - Aurora PRD NÃO é alcançável por port-forward (nem via EC2 do ECS; o SG é das ENIs das tasks). Consulta read-only: `aws ecs execute-command` no container core-api + `bin/monetarie rpc` com `Repo.query!` (escapar `\$1` no shell; params Postgrex exigem tipos certos, ex. `~U[...]` para timestamptz). - Worktree nova do monorepo: `@monetarie/shared` precisa de build (tsup) antes do vitest do admin, senão 19 suítes falham com import não resolvido; gerenciador é pnpm na raiz `core/`. - vitest do admin agora tem `setupFiles` global (`src/test/setup.ts`) com o polyfill de matchMedia; specs novos de componentes PrimeVue não precisam mais colar o stub. - Deploy HML: `scripts/deploy_hml_arm64.sh ` faz build+push+task-def+update preservando env/secrets. --- # PARTE B — Money-path PIX: validação das mensagens recebidas do BACEN + DEFEITO RAIZ da consulta de E2E (sessão paralela, 2026-07-17 noite) > Esta parte é da frente money-path (não da qualidade CoreAdmin). Foi consolidada aqui a pedido do dono para haver UM ponto único de retomada. TUDO abaixo é verdade validada empiricamente, prova coletada de PRODUÇÃO (rpc read-only via `aws ecs execute-command` no container `pix-api`) ou arquivo:linha do código. Sem inferência. ## B0. COMANDO DE RETOMADA (copiar e colar na próxima sessão) ``` /retomar Retomar a frente money-path PIX pela PARTE B do handoff docs/handoff/2026-07-17-frente-qualidade-coreadmin-sta-handoff.md. Executar, com TDD (RED antes) e revisão adversarial, na ordem P0->P1->P2->P3 da seção B4, SEM deploy enquanto o dono opera money-path ao vivo: 1) P0: consertar a consulta de E2E — extract_ntfctn_id/1 (inbound_processor.ex:2594) usa String.to_charlist e quebra o xmerl em XML acentuado; trocar por :erlang.binary_to_list (igual message_parser.ex:47) e auditar apply_camt054_enrichment/resolve_outbound_from_camt054 pelo mesmo padrão. Provar com um camt.054 acentuado REAL. Depois re-consultar a operação da Wise E2E E5958811120260717205916346PG2TJD e confirmar desfecho. 2) P1/P2/P3 conforme B4. Antes de mexer, revalidar as provas de PRD da seção B5 (os comandos estão prontos para colar). Regras: BACEN é a verdade, achar NOSSO defeito e PROVAR; em produção não existe teste; nunca deployar/reiniciar pix durante operação ao vivo (troca liderança ICOM e perde mensagem). ``` ## B1. DEFEITO RAIZ P0 (PROVADO EM PRD): a consulta de operação por E2E (camt.060 -> camt.054) quebra por acento **Sintoma relatado pelo dono:** a consulta de E2E "estava funcionando e parou"; a camt.054 de retorno "não volta"; travou a resolução de uma devolução recebida da Wise (R$ 52,74). **Verdade medida (não é o que eu disse antes; o que provei agora):** - O camt.054 NÃO parou de chegar. Em PRD há 36.159 no `icom_received` (a maior parte carga inicial 07-08/09; orgânico 5/6/3/3 por dia em 14/15/16/17). O da Wise chegou hoje 22:42:24 com o lançamento **R$ 52,74 CRDT BOOK** e o E2E `E59588111...`. - O BACEN ECOA o MsgId da nossa camt.060 no `Ntfctn/Id` do camt.054 (provado: `M00038166...` do BACEN, depois `M46026562ca35d93d167071a3593eb51` = o MsgId da NOSSA camt.060). O camt.054 é gravado em `bacen_inbound` (3 hoje). Mesmo assim a `OperationQuery` deu timeout. **Causa raiz (arquivo:linha):** `extract_ntfctn_id/1` em `apps/spi_service/lib/spi_service/workers/inbound_processor.ex:2594` faz `xml |> String.to_charlist() |> :xmerl_scan.string(...)`. `String.to_charlist()` quebra o xmerl em QUALQUER XML acentuado (`wfc_Legal_Character bad_character` — MESMO defeito do incidente pacs.004 PDNG de 13/07, já corrigido em `apps/shared/lib/shared/bacen/iso20022/message_parser.ex:40-47` mandando usar `:erlang.binary_to_list()`, mas esta função ficou de fora). O crash é engolido pelo `catch :exit -> nil` (linha 2600), a função devolve `nil`, o gate da linha 1337 (`String.starts_with?(ntfctn_id, "M" <> own_ispb)`) falha, `correlate_camt060_response` (chamada na linha 1339) NUNCA roda, o `camt060_requests` fica `timeout`, e `OperationQuery` (apps/spi_service/lib/spi_service/operation_query.ex) expira mesmo com a resposta gravada. **Prova empírica em PRD (rodada no camt.054 real da Wise):** ``` extract_ntfctn_id ATUAL (String.to_charlist): nil xml multibyte/acentuado: true contém id de correlação M46026562...: true extração via BYTES (:erlang.binary_to_list): ["M46026562ca35d93d167071a3593eb51"] ``` **Fix P0 (uma linha + auditoria):** trocar `String.to_charlist()` por `:erlang.binary_to_list()` em `extract_ntfctn_id/1`. Auditar `apply_camt054_enrichment` (ip:1346) e `resolve_outbound_from_camt054` (ip:1353/1410) pelo mesmo risco de acento (resolve_outbound usa Regex.scan, checar). TDD com um camt.054 acentuado real (o da Wise serve de fixture). **Impacto:** a consulta de E2E falha para toda operação cujo camt.054 tenha nome de pessoa com acento (quase todo brasileiro). Era intermitente por isso (funcionava só quando o nome não tinha acento; ex.: 16/07 uma consultou OK). ## B2. Devolução da Wise (E2E E5958811120260717205916346PG2TJD) — estado factual - pacs.008 de entrada liquidou 20:59: Conta PI creditada R$ 52,74 (`balance_history` reference_type `spi_settlement`, "PIX inbound - UEkBn3HgYnQn..."). camt.054 correspondente confirma CRDT BOOK do E2E. - A consulta de operação por camt.060 estava dando timeout SÓ pelo defeito B1 (o BACEN respondeu certo). Não há erro nosso de dinheiro provado nesta operação; o que faltava era fechar a correlação da consulta. - `camt060_requests` da Wise: 21:53:53 `op_status_manual` timeout; 3 re-consultas às 22:41-22:42 (as camt.054 voltaram, mas não correlacionaram por B1). Ação: após o fix B1, re-consultar e decidir o desfecho (a operação já está liquidada de entrada; se houver devolução a ENVIAR à contraparte, é o trilho do ReturnProcessor, confirmar antes). ## B3. Matriz de validação — mensagens que o BACEN pode enviar (ancorada nos XSD oficiais mwbank/md, com arquivo:linha) Metodologia: significado tirado do XSD/exemplo em `/Users/luizpenha/mwbank/md/v5.12.1/{xsd,exemplos}/` (NUNCA do comentário do código — um comentário nosso descrevia trck.002 como "MED/fraude", ficção). Legenda: `ip`=inbound_processor.ex, `parser`=message_parser.ex, `schemas`=validation/message_schemas.ex, `cep`=core_event_processor.ex. **pacs (money path) — TODAS CORRETAS:** - pacs.008 `FIToFICstmrCdtTrf` -> `process_incoming_payment` ip:417 (credita Conta PI, valida conta no Core, responde pacs.002/pacs.004; XMLDSig fail-closed). CORRETA. - pacs.002 `FIToFIPmtStsRpt` -> `process_status_report` ip:2091 (correlaciona por E2E/InstrId, status terminal fail-closed). CORRETA. - pacs.004 `PmtRtr` -> `process_incoming_return` ip:1171 (aceite pacs.002 da devolução; crédito diferido até camt.054 BOOK). CORRETA. **camt:** - camt.052 `BkToCstmrAcctRpt` -> `process_account_report` ip:2381. CORRETA. Ressalva: download do extrato só com env `BACEN_STATEMENT_DOWNLOAD_URL` (nunca setada em prod) -> degrada fail-loud para notificação. - camt.053 `BkToCstmrStmt` -> `process_eod_statement` ip:2603. CORRETA (credita remuneração REMN idempotente; posição SADP/SABK). - camt.054 `BkToCstmrDbtCdtNtfctn` -> `process_notification` ip:1319. Resolução CORRETA, MAS a correlação da consulta quebra por acento (B1, P0). - camt.014 `RtrMmb` -> `process_member_directory_update` ip:2796. CORRETA (upsert de participantes). - camt.060 `AcctRptgReq` OUTBOUND (nós enviamos) -> `Camt060.query`; resposta é camt.052/053/054. CORRETA. - camt.025 `Rct` -> `process_receipt` ip:2207. **PARCIAL (beira STUB):** status hardcoded "ACCEPTED", não lê `ReqHdlg/Sts/Cd` -> recibo de rejeição (RJCT/AG01) mascarado como aceito. - camt.029 `RsltnOfInvstgtn` -> `process_med_resolution` ip:2224. **PARCIAL:** nunca extrai `PmtInfCxlSts` (ACCR/RJCR) -> claim MED sempre vira "analysis"; aceite/rejeição de devolução indistinguíveis. - camt.055 `CstmrPmtCxlReq` -> `process_cancellation_request` ip:2706. **STUB efetivo:** `cancellation_id`/`reason_code`/`amount`=nil (`CxlRsnInf`≠`StsRsnInf`) e evento `med.cancellation_requested` SEM consumidor -> devolução/cancelamento recebido não abre claim nem aciona bloqueio. **admi / pibr / trck / pain:** - admi.002 raiz REAL `admi.002.001.01` (MessageReject: RltdRef+Rsn). Detector nosso usa `SysEvtNtfctn` (parser:106) e `schemas:327` = **ERRADO (é a raiz da admi.004)**. Roteia certo NA PRÁTICA via MsgDefIdr; handler `process_system_event` ip:210 faz correlação real de rejeição REDA/camt.060. Veredito CORRETA via MsgDefIdr, detector/validador fictícios (latente: admi.002 sem MsgDefIdr = rejeição do BACEN perdida). - admi.004 raiz REAL `SysEvtNtfctn`. Detector usa `SysEvtAck` (parser:107, inexistente). **PARCIAL** (audit-only; sub-rotinas guardadas a "admi.002" não rodam para admi.004). - pibr.001 `EchoReq` OUTBOUND. CORRETA. - pibr.002 `EchoRpt` -> `process_echo_response`->generic ip:212. **PARCIAL** (audit-only; correlação de eco no monitor ICOM). - trck.002 raiz REAL `PmtStsTrckrRpt` (cenário BOK1/BOK2 = book transfer / PIX interno; NÃO é MED/fraude). Envio BOK1 REAL em `handle_internal_settlement` cep:1821 (assina e envia). O módulo `apps/spi_service/lib/spi_service/med/trck002_handler.ex` é **STUB+FICÇÃO**: envio comentado (:104-105), parse de tags inventadas `ChainNode/AcctId/HopDpth/ClmId` (:299-317) que não existem no XSD. PRD: 0 trck.002 enviadas — verificar compliance (houve PIX interno não reportado por BOK1?). - pain.009 `MndtInitnReq` -> `process_generic` ip:217. Inbound só auditada; outbound real (recurrences.ex:503). - pain.011 raiz REAL `MndtCxlReq` (cancelamento). Detector usa `MndtAmdmntReq` (parser:100) = **TROCADO** (MndtAmdmntReq é pain.010). Inbound só auditada. - pain.012 raiz REAL `MndtAccptncRpt` (relatório). Detector usa `MndtCxlReq` (parser:101) = **TROCADO** (é a raiz da pain.011). Inbound só auditada. - pain.013 `CdtrPmtActvtnReq` -> `process_generic` ip:217. Inbound só auditada. - pain.014 `CdtrPmtActvtnReqStsRpt` -> `process_payment_activation_status` ip:2744. **PARCIAL** (publica `recurrence.activation_status` SEM consumidor). **reda / DICT (validado por agente dedicado contra XSD + arquivo:linha):** - reda.016 `PtyStsAdvc` INBOUND -> `process_party_status_advice` ip:1882. **CORRETA (REAL):** extrai `OrgnlBizInstr/MsgId`/`PtySts/Sts`(COMP/QUED/REJT)/`StsRsn/Rsn/Prtry` (parser:341) e materializa a máquina de estados em `indirect_participants` via `Shared.Reda.mark_status` (reda.ex:136). - reda.017 `PtyRpt` INBOUND -> `process_party_report` ip:2023. **STUB:** só `upsert_inbound` + broadcast vazio; descarta em silêncio o ISPB do participante e o `PRAZOCONFI` (prazo de confirmação de migração do PI). Sem extractor. - reda.041 `PtyActvtyAdvc` INBOUND -> `process_party_activity_advice` ip:2060. **STUB:** broadcast com `target_ispb`/`changes` = nil; descarta o `Rcrd/Othr` (FldNm/OdFldVal/NewFldVal = log de alteração cadastral). Sem extractor. - reda.014/022/031 = OUTBOUND (nós enviamos; builders `message_builder.ex` :706/:1218/:1447); inbound cairia em generic. - Respostas DICT REST (poll via `DictInboundPollWorker` dict_inbound_poll_worker.ex:44 -> `InboundSync.sync`): **ListRefunds** (FundsRecovery.sync_inbound_refunds_from_bacen funds_recovery.ex:619, upsert por refund_id), **ListInfractionReports** (infractions.ex:670, upsert por id + rota MED), **ListClaims** (claims.ex:494, upsert por claim_id + timers), **ListCidSetEvents** (cid_sync_service.ex:913, ON CONFLICT DO NOTHING), **GetCidSetFile** (cid_sync_service.ex:692, verifica SHA-256 + reconcilia vs keys), **GetEntry** (dict_client.ex:123, lookup síncrono devolvido, não persiste) = todas **MATERIALIZADAS/CORRETAS**. **CreateSyncVerification** (cid_sync_service.ex:534) = **PARCIAL (só loga):** mismatch de sincronismo da base DICT não é materializado nem alertado; resync fica no full-sync de 6h. GOTCHA: idempotência dos polls refunds/claims/infractions é get-then-insert (TOCTOU latente; só `cid_events` tem unique constraint no DB), OK hoje pelo `unique:[period:60]`/`max_attempts:1` do worker. ## B4. Defeitos priorizados (para a próxima sessão executar) - **P0 (trava a Wise e qualquer resolução):** B1, consulta de E2E por acento (`extract_ntfctn_id` -> bytes). - **P1 (MED / devolução recebida quebrada):** camt.055 (STUB, sem consumidor), camt.029 (não distingue ACCR/RJCR), camt.025 (mascara RJCT). Extratores dedicados + ligar consumidor da devolução recebida. - **P2 (detector fictício, hoje latente porque a via MsgDefIdr salva o roteamento):** admi.002<->admi.004 e pain.011<->pain.012 trocados/fictícios no parser e no schemas; corrigir raiz real + fallback de conteúdo (risco: mensagem sem MsgDefIdr). - **P3 (Pix Automático / cadastro / limpeza):** pain.011/012/013 inbound só auditadas (sem máquina de mandato), pain.014 evento órfão; reda.017 (STUB, descarta ISPB+PRAZOCONFI) e reda.041 (STUB, descarta o log de alteração cadastral) precisam de extractor+materialização como a reda.016 já tem; CreateSyncVerification só loga (drift DICT sem alerta); remover a ficção do `med/trck002_handler.ex`; verificar compliance do BOK1 (0 em PRD). ## B5. Provas de PRD — comandos prontos para RE-VALIDAR (read-only) Task pix-api PRD: `PIXPROD=$(awsmon ecs list-tasks --cluster monetarie-greenfield-prod --service-name monetarie-pix-api-prod --query 'taskArns[0]' --output text)` (ou reusar o task arn salvo). Padrão de query que funciona: `bin/monetarie_pix rpc "IO.inspect(Shared.Repo.query!(~s|SQL com aspas simples literais dentro do sigil pipe|).rows)"`. Evitar `~s(...)` quando o texto tiver `)`. - Censo de entrada: `SELECT coalesce(msg_type,'(nil)'), count(*), to_char(min(received_at),'MM-DD'), to_char(max(received_at),'MM-DD') FROM monetarie_spi.icom_received GROUP BY 1 ORDER BY 2 DESC` (deu camt.054=36159, pibr.002=2112, admi.002=237, camt.053=45, pacs.002=33, pacs.008=10...). - camt.054 por dia: `SELECT received_at::date, count(*), to_char(max(received_at),'HH24:MI:SS') FROM monetarie_spi.icom_received WHERE msg_type='camt.054' GROUP BY 1 ORDER BY 1`. - Consultas de E2E: `SELECT to_char(sent_at,'MM-DD HH24:MI'), action, reqd_msg_nm_id, status, response_type FROM monetarie_spi.camt060_requests ORDER BY inserted_at DESC LIMIT 12`. - Prova do defeito B1 (rodar no camt.054 da Wise): carregar `raw_xml` de `icom_received` WHERE msg_type='camt.054' AND received_at::date=current_date, e comparar `SpiService.Workers.InboundProcessor.extract_ntfctn_id(xml)` (=nil) com a extração por bytes via `:erlang.binary_to_list(xml) |> :xmerl_scan.string(...)` + xpath `//Ntfctn/Id` (=o MsgId da nossa camt.060). ## B6. Estado dos agentes de validação desta sessão 4 grupos validados por subagentes contra os XSD oficiais (pacs; camt; admi/pibr/trck/pain; reda/DICT). Relatório consolidado desta parte salvo em `scratchpad` durante a sessão; a matriz acima é o resumo com arquivo:linha. Nada aqui foi deployado. Nenhum commit desta PARTE B foi feito sem OK (pedir antes de commitar/pushar o handoff). ## 10. Memórias [[monetarie-bugs-gabriel-frente-qualidade-0717]] (estado da frente de qualidade), [[monetarie-ib-cadastro-chave-openingdate-quebrado-0717]] (defeito do openingDate), [[monetarie-relatorio-bugs-coreadmin-0717]] (mapeamento original dos 28 itens), [[monetarie-consulta-e2e-camt054-acento-0717]] (PARTE B: defeito raiz da consulta de E2E por acento + matriz de validação das mensagens do BACEN).