# PIX admin — handoff Onda 1 deployada + roadmap (2026-06-25)

Continuacao do deep audit do front PIX admin. Este doc e o ponto de partida da
proxima sessao. Tudo abaixo foi validado empiricamente ao vivo, salvo onde
marcado "deployado (validar na tela)".

## Onde trabalhar
- Worktree: `/Users/luizpenha/.config/superpowers/worktrees/monetarie/fix-camt060-verifier`
- Branch: `fix/pix-camt060-verifier-spi-msg-audit` (pushed). HEAD `dec884ec`.
- NAO editar a working tree principal. Builds saem da worktree -> ECR -> ecs.
- AWS: `AWS_PROFILE=vulcimonetarie`, conta 990933657879, sa-east-1. Wrapper `awsmon` no CLAUDE.md.
- rpc na task viva pix-api: harness reconstruido em scratchpad/runrpc.sh (ECS Exec -> /app/bin/monetarie_pix rpc, base64). Recriar se a sessao mudar (esta no scratchpad efemero).
- Front (browser/validacao): VPN no ar. Login http://pixadmin-h.monetarie.internal — admin@monetarie.com.br / Monetarie#Adm2026!. Prints via Playwright MCP salvam em /Users/luizpenha/monetarie/audit/ (root permitido /Users/luizpenha/monetarie).

## Estado de deploy
- pix-api: task-def `monetarie-pix-api-homolog:47` (digest 9fa101ac). Contem Onda A (volta) + Onda 1 backend.
- pix-admin-ui: tag mutavel `monetarie/pix-admin-ui:homolog-latest` (digest 3b10d8b7 da Onda 1; rebuild sobrescreve o mesmo tag, force-new-deployment). NAO incrementa task-def.
- Plano completo (300 achados, 5 ondas, arquivo:linha): `docs/handoff/2026-06-25-pix-admin-full-deep-audit-PLAN.md`.
- Audit cru (JSON dos 17 agentes): task output wmk1pjtup (efemero).

## Mecanica de build/deploy (IMPORTANTE)
- OrbStack (docker) cai sozinho. Antes de qualquer build: `docker info || orb start` (aguardar daemon). O `orb start` imprime "timed out" mas o daemon sobe ~3s depois.
- Builder buildx: `coreproviders-mk-builder`. ECR login: `awsmon ecr get-login-password | docker login --username AWS --password-stdin 990933657879.dkr.ecr.sa-east-1.amazonaws.com`.
- BACKEND (pix-api): `docker buildx build --builder coreproviders-mk-builder --platform linux/arm64 -t <ECR>/monetarie/pix-api:<tag> --push --provenance=false .` (contexto pix/backend). Depois registrar nova revisao de task-def (copiar a :45/atual, trocar image por @digest, remover campos read-only) e `ecs update-service --task-definition :N`. Deploy ja e 0/100 (single task, limite ICOM 6 conexoes); rollout ~2-3 min, task nova demora ~60-90s pra subir.
- FRONT (pix-admin-ui): build context pix/frontend/admin (Dockerfile vite+nginx, VITE_API_BASE_URL=""). Push para `:homolog-latest` + `ecs update-service --force-new-deployment`. CUIDADO: ao validar, use cache-buster (?cb=x) — o browser cacheia o index.html durante o rollout.

## Onda 1 — FEITO, deployado, validado (commit dec884ec)
FRONT (pix-admin-ui):
- Monitor: `stores/monitor.ts` default time_window 1h->24h (linhas 32,108) + `views/monitor/OperationsMonitorView.vue` @change="applyFilters" nos selects de janela/status. VALIDADO: abre em 24h com 462 ops sem clicar Aplicar. (O backend settlement_service MonitorController sempre funcionou.)
- Coluna Instrumento: `views/transactions/TransactionListView.vue` getInstrumentLabel(tx) deriva DICT/MANU (nunca tx.type/pacs.008); removido IPMF; acentos. VALIDADO.
- Travessao: purga U+2014 em 50 arquivos do front (perl). VALIDADO (0 restantes).
- Detalhe institucao: `views/transactions/TransactionDetailView.vue` mostra debtor/creditor_institution_name; backend `payment_controller.ex` institution_name/1 resolve do diretorio bacen_pix_participants (Repo.one limit 1 — a tabela tem ISPB duplicado, get_by levantava MultipleResultsError). VALIDADO: MONETARIE SCD / OWEM PAY.
- Paginacao: `views/keys/KeyListView.vue` e `views/qrcodes/QrCodeListView.vue` enviam limit/offset.
- Extratos: `services/statement.ts` normalizeStatement (statement_type/ispb/from_date->contrato front) + generate mapeia camt.05x->intraday/end_of_day, ispb, from/to.
- CID: `views/sync/CidSyncView.vue` eventTypeOptions so ADDED/REMOVED/UPDATED.
BACKEND (pix-api):
- `sessions.ex` list_sessions: + Repo.preload(:transactions) (creditos/debitos/posicao liquida).
- `cid_sync_controller.ex` @valid_event_types = ADDED REMOVED UPDATED all.
- `payment_controller.ex`: institution_name/1 + MessageHistory.record(tx,1,"USER") no create (timeline nao nasce vazia).

## Roadmap restante (tasks #7-#12; tudo com arquivo:linha no PLAN.md)
- Onda B (mocks, 45 itens/22 high): detalhe do Participante (Responsaveis/Webhooks/Limites mock + Limites 2x), accounting/monitor mock, acoes @click no-op. Ocultar ate backend existir OU implementar CRUD.
- Onda C (i18n, 76 itens): 62 views hardcoded pt-BR; externalizar para locales/*.json. CUIDADO ao paralelizar: conflito de escrita no JSON unico de locale — fazer por lotes de views disjuntas e um dono unico do JSON, ou sequencial.
- CAMT.060: camt060.ex:30-34 ignora params das 7 abas (manda a mesma msg). Parametrizar + consolidar 3 builders; saldo depende de camt.052/053 inbound.
- Onda E: return_controller.index [] hardcoded; createReturn reason->reason_code; claims status->action; accounting/history snake->camel; dict/policies payload.
- Features inexistentes (desenvolvimento novo): balance requests (credito/debito/aporte + LSO/RSO), CRUD alcada/grupos, estatisticas response-time/message-statistics, reports/balance|fees. O front chama rotas que nunca existiram no backend.
- Validacao final: capturar as ~120 telas + PDF completo (acervo parcial em audit/).

## Metodo (regras do dono)
- BACEN nunca erra; quando rejeita, defeito e NOSSO e tem que ser PROVADO. ZERO inferencia.
- pt-BR com acento, SEM travessao de IA (—). Segredos so no Secrets Manager.
- Nao considerar tela validada sem screenshot. Validar dado real (endpoint que o front consome), nao so o DB.