# Prompt para a próxima sessão (copiar e colar)

Cole o bloco abaixo na próxima sessão para retomar todos os pontos pendentes.

---

```
Retomando a Monetarie. Leia o handoff docs/handoff/2026-07-17-partner-api-deploy-validacao-fixes-handoff.md e o mapeamento docs/reports/2026-07-17-mapeamento-ibfront-merchantfront-vs-aviv.md. Confira git rev-parse origin/main HEAD (deve estar limpo) e suba os containers de teste (monetarie-pg :15432 e monetarie-tb-test) antes de qualquer mix test.

Regras de sempre: money-path fail-safe, sem inferência, provar empiricamente; TDD com RED primeiro; revisão adversarial após cada item; commit + push na main a cada item concluído; deploy (HML+PROD) só com meu OK; atualizar as 4 memórias ao fechar cada frente. Em relatório para o cliente: nunca expor defeito interno, 4xx nunca como sucesso (recusas de proteção em seção própria com o erro real), evidência = chamada + retorno + erro, acentuação pt-br 100% na prosa mas literais da API intactos, sem travessão, e incluir seção de responsabilidade do cliente.

O objetivo desta frente é fechar TUDO que falta no fluxo do cliente (Partner API) e nas telas. Comece por uma AUDITORIA com discernimento (pode usar agentes em paralelo), com evidência arquivo:linha, separando para cada item: (a) o que já existe e funciona ponta a ponta, (b) o que existe parcial/stub, (c) o que falta criar do zero, e distinguindo Partner API (cliente) vs telas ib/merchant vs backend/cabine. Depois me apresente um plano priorizado antes de implementar. Implemente item a item com TDD e revisão adversarial; não deploye sem meu OK.

Itens a cobrir:

APIs do fluxo do cliente que faltam ou estão incompletas (Partner API):
1. Infrações: relatar, consultar e gerir infração (não existe rota de infração na Partner API hoje; existe MED e claims). Criar o ciclo do cliente.
2. Reivindicações / portabilidade de chave: já existe /pix/claims (create/show/confirm/cancel) parcial. Auditar e completar o ciclo de portabilidade e reivindicação ponta a ponta (inclusive o lado de quem recebe a reivindicação).
3. MED 2.0: já existe /pix/med (create/show) parcial. Auditar e completar (devolução especial, infração nos dois sentidos, prazos, refunds com pacs.004 real).
4. Publicação de defesas: hoje a defesa de infração do lojista cai em rota admin e retorna 403. Expor a publicação de defesa no fluxo do cliente.
5. Devolução via pacs.004 de uma operação de PIX OUT: auditar o /pix/payments/:id/refund atual (semântica e se cobre PIX enviado) e habilitar a devolução via pacs.004 de uma operação de PIX out.
6. Devolução de TED: criar a API para solicitar a devolução de uma TED, que deve gerar uma STR0010 pela cabine SPB. Não existe hoje.

Deploy da blindagem já pronta:
7. Aplicar a migration 20260717150000 (CHECK key_type = UPPER em monetarie_dict.keys) via rpc em HML+PROD no próximo deploy do pix-api. Já commitada (ab49616d), não deployada.

P0 das telas (ib-front e merchant-front) — money-path visível ao usuário final:
8. QR das telas (IB e merchant) é stub com EMV inválido sem CRC (core/backend/.../v2/pix_controller.ex:702, TODO); o motor real da cabine só está ligado na Partner API. Ligar o gateway real (monetarie.pix.qrcode.static|dynamic) nas telas.
9. Copia e cola do IB chama pix.payQrCode que não existe em usePix.ts; o backend (pix_controller.ex:753) está pronto. Consertar o front.
10. monetarie.settlement.qrcode.paid: consumer já foi ligado no Core (P0-3, deployado). Validar a cobrança paga ponta a ponta pelas telas.

P1 das telas:
11. TED agendada só existe no v1; o v2 que as telas usam debita imediato e ignora scheduledDate. Rotear o v2 pelo ScheduledTed.
12. Limites invisíveis ao usuário (telas estáticas, enforcement real). Expor consulta e alteração.
13. TEF entre contas retorna 501 com tela ativa; o handler real existe no partner. Ligar.
14. PIX Automático com trilho duplo: in_house/adapter.ex:88-137 publica sem o campo event e cai na DLQ. Corrigir/remover o lado morto e confirmar qual trilho as telas chamam.
15. Rotas v1 /pix/in e /pix/out publicam envelope sem event e vão para a DLQ. Matar as rotas ou corrigir o envelope.
16. Chamadas mortas do merchant (busca de extrato, favoritos bare, lookup-account, kyc/submit, webhooks bare, onboarding colidindo com admin).

Outros:
17. Publicar a rota GET /accounts/:id/events da Partner API (hoje 404).
18. Follow-ups gerais: payables/open_finance stubs (visíveis na DLQ), DLQ triagem, CI inexistente, contador COSIF (SME/LPI), frente de performance e custo.

Ao final de cada API nova do cliente, quero um relatório de validação nos moldes do que fizemos para a Partner API (evidência de chamada, retorno e erro por item; seção de responsabilidade do cliente e modelo de envio de evidências para os fluxos que dependem de terceiros).
```

---

## Referência rápida do estado (para eu não perder o fio)

- `origin/main = d01262af`. Revisões vivas: HML core:157 pix:181 spb:66 / PROD core:61 pix:58 spb:37.
- Partner API HOJE tem: refund (`/pix/payments/:id/refund`), claims (create/show/confirm/cancel), med (create/show), transfers/ted (envio), transfers/internal. NÃO tem: infrações, publicação de defesa, devolução de TED (STR0010).
- Handoff da sessão: `docs/handoff/2026-07-17-partner-api-deploy-validacao-fixes-handoff.md`. Mapeamento das telas: `docs/reports/2026-07-17-mapeamento-ibfront-merchantfront-vs-aviv.md`.