# Handoff de sessao unica (2026-07-22) — Blocos A/B + extrato pagador-recebedor/OTP + STR teto 15k/limites zerados Data: 2026-07-22 (fim do dia). Este handoff CONSOLIDA duas frentes que rodaram em paralelo hoje (duas sessoes) e agora estao unificadas na mesma historia linear da main. Supera e complementa `docs/handoff/2026-07-22-blocos-auth-pj-e-qa-onboarding-handoff.md` (aquele foi escrito na madrugada, no comeco do dia; este e o estado ao fim do dia). Regra que continua valendo (o dono cobrou): nada de "pronto/apto a clientes" sem prova empirica (build + teste + prova viva + screenshot). Zero inferencia. As jornadas de onboarding/cadastro NAO vao a PRD ate a validacao visual tela a tela COM o dono. Push e deploy PRD so com OK explicito (nao e transitivo). Nao deployar/reiniciar pix/spb com o dono operando money-path ao vivo. Segredos so no Secrets Manager. Docs pt-br sem travessao. --- ## 1. Estado canonico verificado (git) - `origin/main = 563694df` (`docs(evidencias): screenshots 22/07 das telas corrigidas movidos da raiz`). **Local == origin, 0 ahead / 0 behind. Tudo pushado.** - As duas frentes de hoje estao INTERCALADAS na mesma historia linear (ambas commitaram na mesma arvore e tudo aterrissou na main). Nao ha branch pendente, nao ha merge aberto. - Sequencia relevante (mais novo para mais velho), com a frente de cada commit: - `563694df` docs screenshots (frente STR) - `f860d20a` fix(ib) nome no complement AutBank + rotulo honesto de tarifa TED conta 059 (frente EXTRATO) - `8e6d8bde` fix(banking) QR de receber PIX quiet zone (frente STR) - `d5bfa43a` fix(ib) credito sem nome mostra INSTITUICAO pelo ISPB (frente EXTRATO) - `b21a33ea` fix(ib) TED nao duplica e mostra nome (dedup por transaction_id) (EXTRATO) - `78da6943` fix(ib) TED recebida usa num_ctrl_str + fallback XML NomCliDebtd (EXTRATO) - `2fb5af34` fix(core) rejeicao devolve ESPELHO, estorno do resumo diario no HoldRelease (STR) - `f99371be` fix(core) conta com zero a esquerda resolve no debito manual (STR) - `2fe03f4c` feat(core) sem configuracao no coreadmin = SEM teto de PIX/TED (STR) - `fd6042ad` fix(ib) cache do token da cabine SPB no backfill (EXTRATO) - `9d66a427` feat(ib) TED tambem mostra beneficiario/remetente no extrato (EXTRATO) - `496b91e7` fix(core) funil TED respeita travas do coreadmin (LimitCheck :ted), zero hardcode (STR) - `e502f6c3` Revert do guard hardcoded de R$ 15k (STR, por ordem do dono) - `5493f2a7` feat(ib) backfill do pagador/recebedor PIX a partir da CABINE (EXTRATO) - `18f2954b` fix(pix-admin) card ANS honesto em rejeicao (STR) - `0836ae29` perf(pix) keep-warm TLS ao HSM (STR) - `4c03e4b4` fix(spb) variante *E honesta, extrai CodErro (STR) - `284f4e84` feat(core) guard fail-closed teto STR (STR, revertido depois) - `1067bd05` fix(ib,merchant) nome pagador/recebedor no extrato, unificado com coreadmin (EXTRATO) - `23ba71c5` fix(ib) PIX recebido nao duplica + e-mail de OTP com logo real (EXTRATO) - `10d7852a` feat(onboarding) OTP do PF por e-mail via SES com branding, sem SMS (EXTRATO/BLOCO B) - `84cf11ee` feat(onboarding) PF sem captura manual, so Nextcode (BLOCO B) - `8bbddcbb` test(admin) conserta 2 falhas pre-existentes de AdminUserEditView (BLOCO B) - `d082c712` feat(admin) cadastro manual PF/PJ do coreadmin chama Nextcode (BLOCO B) - `6f65750c` feat(onboarding) PJ chama Nextcode logo apos SMS (BLOCO B) - (antes disso, na madrugada) BLOCO A: `c3917ed6` e ancestrais (merchants+merchant_users, auth, MerchantScope), + COMPE `4cdee0db`, + Nextcode payload `e420fc07`. --- ## 2. Revisoes ECS vivas (reconfirmar com describe-services no inicio da proxima sessao) Numeros CONFIRMADOS AO VIVO por `ecs describe-services` em 2026-07-22 fim do dia (todos COMPLETED, running==desired). Reconfirmar no inicio da proxima sessao, porque outra sessao pode mexer. - **PRD**: core-api **:99** (contem TUDO: Bloco A + Bloco B backend + COMPE + STR core + extrato), spb-api **:41**, pix-api **:73** (3 tasks, cap6 desired=3), pix-admin-ui **:29**, core-banking-ui **:14** (SEM a shell de onboarding de HML:49), core-merchant-ui **:10** (login email-only VIVO), core-admin-ui **:30**. - **HML**: core-api **:207**, spb-api **:72**, pix-api **:202** (3 tasks), pix-admin-ui **:55**, core-banking-ui **:49** (tem a shell de onboarding + autocomplete de banco por COMPE + locale pt-BR, SEGURADO de PRD), core-merchant-ui **:28** (login email-only + locale), core-admin-ui **:37**. - NOTA: PRD banking-ui:14 e merchant-ui:10 estao MUITO atras de HML (:49/:28), o que confirma que a jornada de onboarding (frontend) NAO esta em PRD. O bump PRD :13->:14 / :9->:10 foi rebuild pequeno (selo de ambiente / copy honesta), nao a shell de onboarding. Conferir o tag da imagem se precisar de certeza. **GOTCHA de deploy PRD (confirmado):** core-api PRD tem 1 so EC2 e `minimumHealthyPercent:0`, entao durante o swap ha janela curta de `running=0`. No deploy do COMPE os 2 core-api ficaram com 0 task e o ECS nao recolocou sozinho apesar de capacidade sobrar; resolvido com `--force-new-deployment` (houve janela em PRD, foi divulgada honestamente). VIGIAR isso em deploys futuros de core-api. Migration PRD usa a task-def leve `monetarie-core-migrate-prod` (768MB). UIs com selo de ambiente (banking/merchant) NAO podem ser retag por digest homolog->prod: exigem BUILD separado com `--build-arg VITE_APP_ENV=production`, senao o selo sai "Homologacao" em prod. --- ## 3. Migrations aplicadas hoje (HML + PRD, antes do swap) - `20260722100000` merchants + merchant_users + users.login_email + api_keys.merchant_ref + collaborator_invites.merchant_id (BLOCO A). Logs "Migrated" provados nos 2. - `20260722180000` institution_directory ganha code / full_name / compe_participant (BLOCO B, autocomplete de banco por COMPE). - Frente EXTRATO e frente STR NAO adicionaram migration nova (extrato = leitura no account_controller + backfill via rpc; STR = HoldRelease/LimitCheck/catalogo de erro compile-time; a `bacen_error_codes` ja existia). --- ## 4. Dados reparados em PRD hoje (com prova) - **Frente EXTRATO** (via `Monetarie.Release.PixPartyBackfill.run(:apply)`): 13 PIX + 5 TED ganharam o nome da contraparte puxado da CABINE, gravado no metadata da transacao (o extrato le local, nunca bate na cabine por linha). Conta 059: rotulo da tarifa AutBank corrigido. Provado vivo: contas 982/977/768/986 com `sem_nome=0`; conta 059 so a tarifa fica sem contraparte (correto, tarifa nao tem pagador). - **Frente STR**: estorno dos debitos-fantasma nas summaries diarias das 3 contas afetadas (2423, 2627, 2630; 4 linhas). Prova: `safe_balance == pg == tb` exatos (2423: 0; 2627: R$ 1.224.334,55; 2630: R$ 769.732,71). Fila "Em analise manual" do SPB PRD NEGADA e ZERADA (5 ops) por ordem do dono, com evento MANUAL_REV_DENIED auditavel. - **Frente BLOCO A**: 3 chaves de API sobre conta PF removidas em HML (extapi-validador-hml, dev vulci ativa, dev vulci revogada; nenhuma com last_used_at). As 4 chaves de PARCEIRO ficaram intactas (Partner API fora do escopo). PRD tinha 0 chaves PF. --- ## 5. Frente BLOCO A — auth PJ / merchant subconta por e-mail / API estruturalmente PJ-only Entregue, deployado e provado vivo nos 2 ambientes. Detalhe em `[[monetarie-bloco-a-auth-pj-merchant-0722]]`. - **Modelo**: `merchants` (1 por usuario PJ; unique `user_id` = a ponte; unique `document` com CHECK do CNPJ alfanumerico `^[0-9A-Z]{12}[0-9]{2}$`) + `merchant_users` (pessoa x merchant, role, capabilities). **`accounts` NAO foi tocada** (money-path): resolucao e `api_key.merchant_ref -> merchants.user_id -> accounts`. Credencial do merchant em `users.login_email` (coluna nova, indice unico parcial), porque `users.email` tem repetidos. - **SEM backfill** (decisao do dono): os 856 PJ seguem sem merchant; PJ sem merchant recebe 403 na gestao de chaves; ninguem entra no portal merchant ate o admin cadastrar. - **2 defeitos reais corrigidos**: (1) o login do IB normalizava com `String.replace(doc, ~r/\D/, "")`, entao `"@evil.com"` AUTENTICAVA (200 no RED); fix `Monetarie.Util.DocumentCredential` exige documento canonico (de brinde, CNPJ alfanumerico passou a logar). (2) `ApiKeyController.authorized?/2` so comparava id, entao PF criava chave; substituido pelo plug `MerchantScope` (deriva o merchant do TOKEN; token merchant exige capability `apikeys.manage`; token IB exige `member_pj`). - **Prova viva HML**: merchant login por e-mail 200; CPF 401 / CNPJ 401; IB com e-mail 401; IB com CNPJ 200; PF cria chave 403 e lista 403 (era 201/200); PJ cria 201 com merchant_ref correto. **Prova viva PRD** (sem criar nada): merchant CPF/CNPJ 401, IB e-mail 401, tabelas novas 2/2, MerchantScope carregado, api_keys=0. - **Onboarding parou de pedir senha**: `POST /api/auth/register` nasce com hash aleatorio e a senha enviada e ignorada (a credencial real vem na aprovacao/criacao da subconta). Teste prova que nao autentica. - **Fixtures vivas deixadas em HML**: merchant `7fb2770b-...` (EMPRESA PROVA BLOCO A) com operador `operador.prova.8226@monetarie.com` / `ProvaViva@2026`; merchant real ALDEIA MIRIM `55b4a472-...`. - **Pendencias do Bloco A**: convite/primeiro acesso do operador NAO implementado (o dono decidiu esperar o SES sair do sandbox; conferido vivo `ProductionAccessEnabled=false`); contracao (drop de `api_keys.merchant_id`) so depois de tudo rodado; achado para o Bloco B: a tela merchant `/register` nao envia o campo `cpf` que o backend exige (responderia 400). --- ## 6. Frente BLOCO B — jornada de onboarding/cadastro (Nextcode PF/PJ) + design system Entregue no backend e nas telas, com validacao visual PARCIAL. Detalhe em `[[monetarie-bloco-b-onboarding-nextcode-0722]]`. As telas de onboarding NAO estao em PRD (seguradas para validacao visual com o dono). - **Nextcode (ordem do dono "PF e PJ obrigatoriamente Nextcode")**: a key antiga de HML era INVALIDA (401, provado por sha256 + resposta diferente por estrategia). O dono forneceu key nova `6a5fd5ad...` que autentica 200, gravada no Secrets Manager `monetarie/{homolog,prod}/kyc/nextcode/api_key` E no `kyc_provider_configs` dos 2. Defeito real: `build_payload` nunca mandava os dados da pessoa e o journey oficial usa `deliveryTypes:["email"]`, entao a Nextcode recusava 422; fix `attach_applicant` injeta email/name/phone (commit e420fc07). Prova viva: proposta PJ criada com link real `https://onboarding-api.nxcd.app/proposals/.../loa`. - **Momento do gatilho antecipado**: PF apos o OTP; PJ apos o SMS (nao mais so no passo 8). Guard `journey_linked?` evita duplicata; TDD 11/0. - **PF sem captura manual** (commit 84cf11ee): a Nextcode faz OCR/liveness/face match na interface dela, entao DocumentView/SelfieView/ReviewView foram REMOVIDAS do router PF (os .vue continuam no repo, so nao roteados). Guarda https-only: link http ou vazio nunca vira redirect. Fluxo PF final = intro, Personal, Address, Occupation, Email, Phone (6), Nextcode, Pending, aprovacao admin. - **Design system**: OnboardingShell + BusinessOnboardingShell envolvem as 20 telas com o shell do login (painel verde, logo dourada, card, selo, seletor de idioma). "/register deixou de ser tela pelada". Contraste WCAG corrigido (era 1.42/2.85/2.99, agora >6). "[object Object]" corrigido (a causa era `new Error(body.error)` com objeto). PrimeVue em pt-BR (o "No results found" era o default do PrimeVue; banking so tinha calendario, merchant nao tinha locale nenhum). Regua de etapas PJ que vazava do card corrigida com flex-wrap. - **TED banco por COMPE** (commit 4cdee0db, backend deployado core-api PRD:88->:99): o cliente digitava "237" e a busca devolvia ZERO; pior, `institution_directory` estava VAZIA em PRD (0 vs 437 em HML), entao o autocomplete nunca funcionou em prod. Novo `InstitutionDirectoryImporter` le o ParticipantesSTRport.csv do BACEN (494 instituicoes, 348 com COMPE), idempotente, ABORTA se vier <200 linhas. Prova viva nos 2: 237=BRADESCO, 341=ITAU, 001=BCO DO BRASIL, 260=NU PAGAMENTOS. **NOTA de deploy**: o autocomplete (frontend banking-ui) esta em HML:49, SEGURADO de PRD junto com a shell de onboarding; em PRD o backend do COMPE ja existe (core-api:99, directory populado), mas a melhoria de UI da busca de banco ainda nao esta viva. - **Logo do e-mail Nextcode** corrigida (journey declarava .jpeg mas bytes eram PNG; renomeado .png). - **Validacao visual FEITA por screenshot**: telas PF (personal/address/occupation/email/phone/pending) e /register PJ (design certo, "responsavel" com acento, selo Homologacao). - **Pendencias do Bloco B**: validacao visual das telas PJ 2 a 9 (so /register PJ visto); telas PF address/occupation ainda mostram passos que a Nextcode poderia dispensar (a decisao so removeu document/selfie/review); prova viva do fluxo PF ponta a ponta pelo navegador (o OTP real por SMS nao chega ao ambiente de teste; o desvio foi provado por logica + backend TDD, nao por clique completo); busca de banco por apelido ("Nubank" ainda vazia, nome BACEN e "NU PAGAMENTOS - IP", exige tabela de apelidos). --- ## 7. Frente EXTRATO pagador/recebedor + OTP e-mail (esta sessao) Entregue, deployado em PRD (core-api:99) e provado vivo. Detalhe em `[[monetarie-extrato-pagador-recebedor-otp-0722]]`. Regra reforcada pelo dono, com raiva: NUNCA dizer "nao existe o dado" sem abrir a CABINE; a verdade tem que ser publicada ao cliente; inferencia estraga a imagem dele; a cabine (PIX e SPB) e a fonte de verdade do pagador/recebedor. - **Pagador/recebedor no extrato IB E Merchant** (mesmo endpoint `/accounts/:id/transactions`): mostrava "-". Cadeia de resolucao final no `entry_counterparty_name` e `payment_counterparty` do `account_controller.ex`: (1) nome do cliente na TRANSACAO espelhada via `Receipts.Payload.party_from_metadata` (mesma fonte do comprovante do IB); (2) nome no metadata do proprio lancamento; (3) INSTITUICAO pelo ISPB (payer_ispb credito / recipient_ispb debito) via `InstitutionDirectory.name_by_ispb`, como todo extrato bancario (TED da CAIXA mostra "CAIXA ECONOMICA FEDERAL"); (4) so entao nil. - **Onde o Core gravou nome null**, o `Monetarie.Release.PixPartyBackfill` puxa da cabine e grava no metadata UMA vez (o extrato le local, proibido bater na cabine por linha): PIX pela cabine PIX (E2E, debtor_name/creditor_name), TED ENVIADA pelo XML STR0008 da cabine SPB (`NomCliCredtd`, novo `CabinPartyLookup` fazendo `GET /api/messages/:id` -> xml_content), TED RECEBIDA por `spb_inbound_credits` (coluna e `num_ctrl_str`, NAO control_number) com fallback NomCliDebtd do XML. - **Correcao de rumo importante (o dono tinha razao)**: os creditos que eu chamei de "ausencia genuina" eram STR0006/STR0007 (LDL, credito interbancario/BACEN) cujo PAGADOR e uma instituicao (CAIXA/Banco do Brasil), identificavel pelo ISPB. Nao era ausencia, era o fallback institucional faltando. Ausencia REAL (ai sim "-") so quando nao ha nem nome nem ISPB (ex.: tarifa). - **Duplicacao PIX/TED**: o dedup casava so por `num_ctrl_str` (nulo no PIX); e a TED referencia o lancamento por `transaction_id`. As chaves de dedup e o `tx_by_key` agora reunem num_ctrl_str + end_to_end_id + transaction_id. Mantem o LANCAMENTO (rotulo/direcao certos), descarta a transacao espelhada. - **Acervo AutBank (ETL legado)**: registros antigos com a contraparte so no texto livre `metadata.complement`. `autbank_complement_name` extrai CONSERVADOR (parte depois de " - ", ou remocao de tokens numericos iniciais); onde comeca por ruido sem separador devolve nil (melhor "-" que nome errado, com teste). `entry_display_description`: lancamento AutBank com complement "TARIFA..." vira "Tarifa de emissao de TED" (era "Transf. a Debito"); tarifa nao tem contraparte. - **OTP de onboarding por e-mail via SES** (o dono confirmou o recebimento): o OTP publicava num topico NATS `notification.email` SEM consumidor (nunca entregava) e era texto puro. `Monetarie.UseCases.Onboarding.OtpEmail` entrega pelo `Monetarie.Mailer` (EMAIL_TRANSPORT=ses ja ligado nos 2), com o LOGO REAL (logo-monetarie-gold.png em priv/email_assets) por CID, acentos pt-br. Provado vivo: SES devolveu `{:ok, message_id}`. GOTCHA: conta SES em sandbox (so entrega a enderecos verificados ate a AWS liberar producao; dominio monetarie.com verificado). - **GOTCHAs novos**: a cabine SPB limita `/api/auth/login` a 5/min por IP, entao o backfill precisa cachear o token (persistent_term TTL 2min), senao "0 resolvidos" apos o dry_run gastar a cota; `spb_inbound_credits` tem `num_ctrl_str` (nao control_number); `GET /api/messages/:id` da cabine SPB expoe o XML completo em `message.xml_content`. --- ## 8. Frente STR teto 15k + limites zerados + *E + HSM keep-warm + ANS (outra sessao) Entregue, deployado nos 2 ambientes, com reparo PRD. Detalhe em `[[monetarie-str-teto-15k-egen1102-ans-0722]]`. - **CANONICO 1 (teto do STR, lado BACEN, nao e codigo nosso)**: o STR rejeita sincronamente TED de cliente (STR0008) >= R$ 15.000,00 na participacao da Monetarie, volta STR0008E com `CodErro="EGEN1102"` (Valor Invalido) no atributo do ``. Nao e saldo, nao e formato. Prova: acervo max confirmado = R$ 14.999,00; todas >= 15k rejeitadas. **Tratar no cadastral com BACEN/RTM se TED grande for requisito; hoje o trilho para valores grandes e PIX** (SPI nunca teve teto). - **CANONICO 2 (politica de limites, decisao do dono no chamado "limites zerados")**: R$ 0,00/vazio nas telas = NAO CONFIGURADO = ILIMITADO. Os defaults de sistema de transacao/dia/mes viraram o sentinela 1_000_000_000_000 subcent; limitar e SEMPRE configuracao. Unico default que resta: piso NOTURNO Res. 142 (R$ 1.000). O default antigo de R$ 15k/tx forcou o cliente a fatiar a liquidacao em 49 PIX de 15k. - **6 bugs corrigidos (TDD)**: (1) SPB variante *E cega, o parser nao lia `CodErro` em ATRIBUTO, classificador recebia "RJCT" e ia para manual_review falso; fix `ErrorVariantParser` + `BacenErrorCatalog` (CSV legado 5.318 codigos compile-time) + persistencia do motivo real + painel enxerga inbound da mesma operacao. (2) Funil TED sem motor de limites; agora `LimitCheck.verify(:ted)`, mesmo shape do PIX, ZERO hardcode (o guard de R$ 15k foi REMOVIDO por ordem do dono, revert e502f6c3). (3) Espelho envenenado por rejeicao (a raiz do "saldo insuficiente"): o trigger `update_daily_summary_on_insert` somava TODO INSERT em transactions e a rejeicao devolvia so o hold TB, entao cada TED/PIX rejeitado ficava como debito eterno em `account_daily_summaries` (conta 2423 chegou a pg_net = -R$ 1.459.638,32 e travou todo envio por BalanceGuard = min(tb,pg)); fix: HoldRelease estorna amount+fee do resumo na MESMA tx PG, exactly-once. (4) Conta com zero a esquerda no debito manual do spbadmin (`debtor_account_not_found`): o lookup strippava zeros do armazenado mas nao do input; fix no `AccountResolver.find_account_by_number`. (5) PIX cold-path (sign_ms 1438 frio vs 46 quente): `HsmKeepWarm` (GET /v1/health 20s) mata o sign frio; o post frio do ICOM so com trafego real (opcao ECHO_PROBE_ENABLED, decisao do dono, NAO ligada). (6) Card ANS do pix-admin rotulava rejeicao como "Aceite (ACCC)" + selo EXCEDIDO indevido; agora "Rejeicao (RJCT)" sem selo. - **CORRECAO DE RUMO (o dono tinha razao)**: NAO ha muro geral na participacao STR; SME0001 de R$ 1,3M e LPI0001 de 150k-200k manuais foram ACEITOS; a recusa >= 15k e ESPECIFICA de STR0008 (TED em favor de CLIENTE). O probe de fronteira (mesmo pagador/destino, 15.000,00 vs 14.999,99) fecha isso; armado, falta fundear a conta de teste 982. - **Decomposicao dos 7,2s de um PIX**: 4,8s nossos eram handshakes frios (sign HSM 1438ms + POST ICOM 3340ms); DS04 = decisao do PSP recebedor. - **QR de receber PIX** (commit 8e6d8bde): ganhou quiet zone + removeu wrapper duplicado. --- ## 9. O que NAO esta em PRD (segurado ate validacao visual com o dono) - **Jornada de onboarding/cadastro (frontend)**: banking-ui:49 (HML) tem a shell de onboarding, o autocomplete de banco por COMPE e o locale pt-BR. PRD segue banking-ui:13. NAO deployar ate o QA visual tela a tela. - **Cadastro manual PF do coreadmin (frontend admin)**: a mudanca da NextcodeJourneyForm (telefone opcional) e frontend; conferir se foi so HML. Backend (repasse do email ao create_proposal) esta em core-api:99. - **Observacao importante**: o BACKEND de onboarding (OtpEmail, Nextcode attach_applicant, PF sem captura) ESTA em PRD (core-api:99), mas e inerte sem o frontend rotear para ele e sem clientes reais exercitando a jornada. O que o dono quer segurar e a experiencia visual do cliente, nao o codigo backend. --- ## 10. Pendencias abertas (consolidadas e priorizadas) **Do onboarding/auth (Blocos A e B):** 1. Validacao visual COM o dono das telas PJ 2 a 9 e do fluxo PF ponta a ponta (so /register PJ e as telas PF isoladas foram vistas). So depois disso deployar banking-ui a PRD. 2. Merchant `/register` nao envia o campo `cpf` que o backend exige (responderia 400); corrigir no Bloco B. 3. Convite/primeiro acesso do operador merchant NAO implementado (espera o SES sair do sandbox). 4. Contracao do Bloco A: drop de `api_keys.merchant_id` so depois de tudo rodado. 5. Busca de banco por apelido/marca ("Nubank") ainda vazia; exige tabela de apelidos. **Do STR/limites:** 6. Responder o chamado do Gabriel (respostas prontas na sessao STR); as telas de limites do coreadmin ainda MOSTRAM R$ 0,00 cru, exibir o efetivo resolvido e follow-up de UI. 7. Cadastral BACEN/RTM do teto de R$ 15k do STR (se TED grande virar requisito). 8. Probe de fronteira STR0008 (15.000,00 vs 14.999,99): falta fundear a conta de teste 982. 9. Gatear a automacao STR0013/STR0014 das 08:00 por dia util (rodou no domingo e voltou EGEN0300 "Mensagem Fora do Horario"). 10. Flip opcional ECHO_PROBE_ENABLED para aquecer o post_ms frio do ICOM (decisao do dono). **Herdadas ainda abertas (do handoff da madrugada, secao 6; a #8 Nextcode key e a #12 push JA foram RESOLVIDAS):** 11. QR dinamico: cadastrar CQRC no BACEN via STA (cadastral, x5c+typ ja no ar; PEMs no Desktop; usuario STA "Sisbacen SCERTQRC"; revalidar no PIX Tester). `[[monetarie-qr-cert-audit-tednumctrlif-0720]]` 12. TED viva pelo IB em HML (PR#20 ponta a ponta no gate `:xsd_oficial`, NumCtrlIF=20; codigo provado, falta o teste vivo). 13. Validacao visual das telas do lote IB B/C+B4-B9 pelos hosts publicos. 14. STA follow-ups: token dedicado `STA_SERVICE_TOKEN` (exige +1 ARN na whitelist da execution role = IAM); snapshot do saldo da cabine em PRD nao atualizava; MetricsView mock; aviso benigno "static manifest" no boot. `[[monetarie-sta-v1-auth-failclosed-0721]]` 15. pix-api PRD: Postgrex disconnects periodicos (2-6/h, pre-existente, Task segurando conexao >15s). `[[monetarie-varredura-pos-wave1-0718]]` 16. Bloqueado em TERCEIROS: SES sandbox (pedido de producao na AWS + `CCS_NOTIFICATION_EMAILS`); conta de tesouraria para `SPI_REMUNERATION_SWEEP`; ensaio AMES-SIMBA (secret cloak_key + operador); infracao/MED em HML exige transacao LIQUIDADA via outra instituicao. `[[monetarie-deploy-pacote-degrau1-0719]]` 17. Vulci item 6 (tarifa SLB): unico ainda em desenvolvimento (14/15 atendidos). 18. Higiene baixa: 4 memorias 06-30 citam PIX signing UID `lMcWo5` (STALE; autoritativo pos-07-03 = T011 `oe1ZQyCUK4CwYFfbRaiX`). --- ## 11. Regras vivas (inegociaveis) - BACEN e verdade; achar NOSSO defeito e PROVAR empiricamente; zero inferencia. Em producao NAO existe teste. Validacao de tela SO com screenshot (regra #11), nunca com fixture do caminho feliz. NUNCA dizer "nao existe o dado" sem abrir a cabine. - NUNCA deployar/reiniciar pix/spb com o dono operando money-path ao vivo (troca liderança ICOM e PERDE mensagem). - Push e deploy PRD so com OK explicito do dono a cada vez (nao e transitivo). Segredos so no Secrets Manager. - Docs pt-br sem travessao. Terraform HML: nunca apply, drift nunca vira problema. - Nao deployar as jornadas de onboarding/cadastro (frontend) ate a validacao visual tela a tela com o dono. - AWS: conta 990933657879, profile `vulcimonetarie`, sa-east-1. Monetarie e o CLIENTE, Vulci e a desenvolvedora (docs ao cliente sempre assinados Vulci). - GOTCHAs de shell: zsh come `$r:h` (usar `${r}`); rpc por app: `bin/monetarie` (core), `bin/monetarie_pix`, `bin/bacen_gateway`; timeline SPB na UI vem de `operation_events` (message_state_history vazia). --- ## 12. Ordem recomendada para a proxima sessao 1. Reconfirmar o estado vivo (describe-services das revisoes; `git status` local==origin). 2. **Bloco B (visual, com o dono)**: QA tela a tela das jornadas PF e PJ com screenshot de cada, corrigindo o que aparecer, e SO ENTAO deployar banking-ui a PRD. Corrigir o `/register` merchant (campo cpf faltando). 3. Responder o chamado do Gabriel e resolver a exibicao do limite efetivo no coreadmin (item 6). 4. Fechar os cadastrais externos quando o dono liberar (SES producao, CQRC BACEN, teto STR). 5. Ao fechar qualquer frente: atualizar CLAUDE.md + MEMORY.md + memoria de topico + Serena, so com verdade comprovada. Memorias de topico desta consolidacao: `[[monetarie-bloco-a-auth-pj-merchant-0722]]`, `[[monetarie-bloco-b-onboarding-nextcode-0722]]`, `[[monetarie-extrato-pagador-recebedor-otp-0722]]`, `[[monetarie-str-teto-15k-egen1102-ans-0722]]`.