# Runbook: acompanhar o primeiro PIX real em producao (perna a perna)

Decisao do dono (2026-07-09): em producao nao existe teste. A validacao definitiva do money path sera feita acompanhando a primeira transacao REAL organica, com evidencia de cada perna. Este runbook deixa as consultas prontas.

Contexto: ate 2026-07-09, producao teve exatamente 1 pacs.008 recebida (incidente E9270206720260709071301850031025, resolvido) e 0 pacs.008 enviadas. O caminho automatico de credito nunca rodou com sucesso em prod (a unica tentativa morreu na cadeia de 5 defeitos, corrigida em pix-api:19/:20). A recepcao de pacs.002 nunca foi exercitada em prod.

## Acesso

Prod (10.50) nao tem VPN do Mac; tudo via ECS exec (SSM). Pegar task ARNs frescos:

```bash
awsmon() { env -u AWS_ACCESS_KEY_ID -u AWS_SECRET_ACCESS_KEY -u AWS_SESSION_TOKEN AWS_PROFILE=vulcimonetarie AWS_REGION=sa-east-1 aws "$@"; }
awsmon ecs list-tasks --cluster monetarie-greenfield-prod --family monetarie-pix-api-prod --desired-status RUNNING --query 'taskArns[0]' --output text
awsmon ecs list-tasks --cluster monetarie-greenfield-prod --family monetarie-core-api-prod --desired-status RUNNING --query 'taskArns[0]' --output text
```

Consultas via rpc: base64 do codigo Elixir e `Code.eval_string(Base.decode64!(...))`. Usar `Repo.query!` com SQL cru (import Ecto.Query nao esta no escopo do eval). Limite de ~50s por chamada (SSM mata).

## Detectar que chegou/saiu um PIX real

No pix-api (banco mon_pix):

```sql
-- entrada e saida novas (audit fim a fim)
select message_type, direction, end_to_end_id, created_at
from monetarie_audit.xml_audit_logs
where message_type in ('pacs.008','pacs.002','pacs.004')
  and created_at > now() - interval '1 day'
order by created_at;
```

## PIX-IN (recebido): checklist perna a perna

Cabine (mon_pix), com o E2E em maos:

1. pacs.008 RECEIVED no xml_audit_logs.
2. pacs.002 ACSP SENT no xml_audit_logs (a resposta tem que ter saido; codigo de rejeicao, se houver, precisa ser do enum, gate RejectCodes).
3. Linha de negocio criada e avancada a ACCC (status_id 3):
   `select id, status_id, direction, message_code from monetarie_spi.messages where end_to_end_id = '<E2E>';`
4. Evento publicado ao Core: job Oban do outbox concluido (tabela oban_jobs do mon_pix, args com o E2E, state completed).

Core (mon_core):

ATUALIZACAO 2026-07-09 (fim de tarde): o elo do credito automatico foi CORRIGIDO e deployado (`core-api:9`, commit `944cbde2`). Antes disso, o PixHandler tratava `transaction.created` como audit-only (desde 25/06, commit `7c6957c5`) e o credito nao aconteceria. Agora: created INBOUND untracked credita via `handle_transaction_ledger` (guardas: rejected nunca credita, OUTBOUND/direcao desconhecida audit-only, redelivery nao duplica). Prova E2E sintetica em HML (core-api:98): TB 223700 -> 224000 (+R$0,03), extrato, transactions, sem duplicacao em 3 entregas. Rollback: `core-api:8` (com ele o credito automatico NAO ocorre; remediacao manual = caminho do incidente).

5. Audit do consumo: `select action, inserted_at from audit_logs where action like 'PIX_%' order by inserted_at desc limit 5;` (esperado PIX_TRANSACTION_CREATED seguido de PIX_TRANSACTION).
6. Credito TigerBeetle + espelho PG:
   `select amount, category, reference, status from account_entries where reference = '<E2E>';`
   e saldo TB da conta: `Monetarie.UseCases.Wallet.get_balance(<account_id>)` deve bater com `sum(amount)` do PG ao subcentavo.
7. Registro em transactions: `select status from transactions where end_to_end_id = '<E2E>';`
8. Tarifa (se aplicavel) e extrato visivel no IB.
9. Monitor (pix-admin): fluxo deve exibir Concluido (nao "Aguardando retorno").

## PIX-OUT (enviado): checklist perna a perna

1. pacs.008 SENT no xml_audit_logs (assinada, aceita pelo BACEN com 201).
2. pacs.002 RECEIVED no xml_audit_logs. Esta e a PRIMEIRA pacs.002 real de producao: conferir que foi APLICADA.
3. Status aplicado: `select status_id from monetarie_spi.messages where end_to_end_id = '<E2E>';` esperado 4 (ACSC/settled) ou 8 (RJCT) conforme o TxSts.
4. Se falha de aplicacao: com o hardening fail-CLOSED (pix-api:20), a mensagem NAKa e retenta; apos esgotar, cai na DLQ MONETARIE_DLQ. Log com "[InboundProcessor] Status update ... FALHOU" em /ecs/monetarie/prod/pix-api.
5. Core: fundos liberados/estornados conforme o desfecho; transactions atualizada; comprovante correto no IB.

## Confirmacao de liquidacao pela verdade BACEN

Em caso de duvida sobre qualquer perna, a verdade e o BACEN: consulta camt.060 de operacao (RptgReq com Id = E2E, ReqdMsgNmId = camt.054) via `SpiService.OperationQuery.query(e2e)`. A resposta camt.054 com CdtDbtInd e Amt e a prova. Nunca inferir liquidacao (ou ausencia dela) apenas dos nossos registros.

## Avisos

- NUNCA reprocessar a pacs.008 do incidente que esta na DLQ (duplo credito + pacs.002 atrasada ao BACEN).
- NUNCA ligar TWO_PHASE_PIX_IN em producao: o gatilho de settled desse modo so existe no simulador; ligar interrompe o credito de PIX-in (ver memoria monetarie-pix-in-credit-path-canonical).
- Nao criar transacao sintetica em producao. Teste so em HML.