# Handoff 2026-06-27 — camt.060 RESOLVIDO (6/7) + diagnóstico da timeline do detalhe de transação

HEAD/estado vivo no fim desta sessão:
- **pix-api = task-def `:70`** (`homolog-camt060dates`, digest `82bc7da5`), serviço ECS STABLE, 15/15 healthy.
- `RTM_HSM_ENABLED=true` (ICOM+DICT assinam no HSM, vHSM 60042, chave `lMcWo5...`).
- `origin/main = 75ca3376`; branch de trabalho PIX = `f0ebf6bf` (NÃO mergeada).
- **As correções da camt.060 desta sessão NÃO estão commitadas em git ainda** — estão só na imagem `:70` (working tree local + ECR). Precisam ser commitadas na branch PIX.

## 1. camt.060 — RESOLVIDA, 6/7 retornando relatório vivo

Era 0/7 (BACEN ACKava 201 mas DESCARTAVA). Resolvido lendo cada `admi.002` (MessageReject) que volta ASSÍNCRONO pela stream /out. Receita (provada vs BACEN + LegadoPIX `ConversaoObjetos.cs` + XSD `camt.060.spi.1.9`):

| Ação | ReqdMsgNmId | Prtry | Data (RptgPrd) | Status vivo |
|---|---|---|---|---|
| saldo-atual / saldo-na-data | camt.053 | CSA | só `<FrDt>` dia fechado, sem ToDt | ✅ camt.053 (R$9,16bi SADP/SABK) |
| demonstrativo-remuneracao | camt.053 | CRE | só `<FrDt>` dia fechado | ✅ camt.053 |
| lista-lanctos | camt.052 | REL | intervalo `<FrDt>+<ToDt>+<FrToTm>` (hora com ms) | ✅ camt.052 |
| demonstrativo-tir / total-tir | camt.052 | TRD / TRT | `<FrDt>` = 1º dia de mês fechado | ✅ camt.052 |
| detalha-lancto | camt.054 | (nenhum) | intervalo + `<Id>` do evento | ⚠️ exige Id de lançamento real; camt.052 de homolog volta vazia (0 Ntry) |

4 defeitos NOSSOS corrigidos: (1) canal — camt.060 tem de ir no PRIMÁRIO; (2) estrutura XSD do `<RptgReq>`; (3) faltavam `RptgPrd`+`ReqdBalTp`; (4) regra de data por tipo. Detalhe completo na memória `monetarie-camt060-recipe-solved.md`.

Código: `apps/spi_service/.../camt060.ex` (`@camt060_spec` + `date_opts/2` + `event_opts/1`) e `apps/shared/.../bacen/spi_client.ex` (`build_camt060_request` + `get_balance` força `channel: :primary` e repassa prtry/from_date/to_date/from_time/to_time/event_id).

## 2. Timeline do detalhe da transação — DIAGNÓSTICO (causa raiz provada, FIX pendente)

A "linha do tempo" do detalhe da transação aparece vazia. Investigado empiricamente (HTTP de dentro da task + SQL vivo):

**A timeline EXISTE** no front (`frontend/admin/src/views/transactions/TransactionDetailView.vue:414`, "Histórico de Status"); mostra estado vazio quando `store.transactionHistory.length === 0`. Os dados vêm de `GET /api/v1/payments/{id}/history`.

**Fluxo:** front → gateway `SpiProxyController.payment_history` → SPI `PaymentController.history` → `Integer.parse(id)` → tabela `monetarie_spi.message_history` WHERE `message_id == int_id`.

**Provas empíricas (de dentro da task pix-api):**
- `curl localhost:4002/api/v1/payments/50/history` (id INTEIRO) → **retorna 2 entradas** (PDNG, ACSP). ✅
- `curl localhost:4002/api/v1/payments/E4602.../history` (E2E string) → **`{"data":[]}`** (Integer.parse falha). ❌
- `message_history` vivo: 24 linhas, **2 por mensagem** (PDNG→ACSP), TODAS as 12 transações presas em `status_id=2` (ACSP). O ciclo pacs.008→pacs.002→ACCC→STLD NUNCA completa → timeline curta mesmo quando aparece.
- Tabela `monetarie_spi.status_history` **NÃO EXISTE** → o endpoint alternativo `/transactions/:id/history` (`TransactionController.history` → `get_status_history` → schema `StatusHistory`) quebraria.
- `SpiService.Transactions` usa `alias SpiService.Transactions.Transaction` = tabela **`monetarie_spi.transactions` VAZIA** (gotcha #10 do CLAUDE.md). Por isso `curl .../transactions/50` → 404 e `.../transactions` → 500 no SPI direto. O front só funciona porque o **gateway tem handler próprio** `list_payments` (spi_proxy_controller.ex:840) que lê `messages` e serializa `id: t.id` (inteiro).

**Causas raiz (a confirmar/fixar na próxima sessão, tela-a-tela no front vivo):**
1. **Fragilidade de id**: `payment_history`/`history` só aceitam id INTEIRO (`Integer.parse`). Se em qualquer caminho o front mandar o `end_to_end_id`, a timeline vem vazia. FIX: aceitar id inteiro OU e2e (tentar Integer.parse; senão resolver o e2e→message.id e então consultar `message_history`).
2. **Ciclo de vida incompleto**: todas as transações presas em ACSP (só 2 eventos). O `StatusUpdater` (`apps/spi_service/.../workers/status_updater.ex:453` — ÚNICO escritor de `message_history`) não avança ACSP→ACCC→STLD. Investigar por que a liquidação de saída não progride (conecta com [[monetarie-pix-cabin-flow-defects]]).
3. **Tabela `status_history` ausente + contexto na tabela errada**: `SpiService.Transactions` aponta p/ `monetarie_spi.transactions` (vazia) e dá preload em `:status_history` (tabela inexistente). Decidir: migrar contexto p/ `messages`/`message_history` OU criar a `status_history` OU remover o endpoint/preload mortos.

## 3. Mandato da próxima sessão (full deep audit + memória)

1. Reproduzir a timeline no front VIVO (login pixadmin, abrir um detalhe, capturar a chamada de rede real e o id passado) — provar qual das causas acima dispara, e fixar.
2. **Full deep audit review de TODO o repo** (PIX + Core/ETL + SPB) cruzando com os itens abertos das sessões anteriores (ver memórias abaixo).
3. **Garantir empiricamente que TODAS as persistências de memória estão atualizadas** (cada fato verificado um a um contra o vivo): `monetarie-aws-empirical-state` (pix-api :70), `monetarie-repo-state` (commitar a branch PIX!), `monetarie-camt060-recipe-solved`, `monetarie-pix-cabin-flow-defects`, etc.
4. Commitar as correções da camt.060 (hoje só na imagem `:70`, não em git).

## Itens abertos herdados (não regredir)
- Liquidação de saída presa em ACSP (ver [[monetarie-pix-cabin-flow-defects]] / [[monetarie-pix-msgflow-acsc-cid-certs]]).
- Validação tela-a-tela do pixadmin + relatório cliente (mandato [[monetarie-validacao-mandato]]) — ainda PENDENTE.
- Core/ETL: padronização de centavos (94 bugs) + re-migração ETL (ver [[monetarie-core-etl-deep-fix-session]]).
- MQ/SPB: GEN0001→BACEN bloqueada RTM-side (ver [[monetarie-mq-hml-spb-server-fix]]).

Regras do dono: BACEN é verdade (defeito é nosso, provado empírico, zero inferência); pt-br sem travessão de IA; AWS sempre `AWS_PROFILE=vulcimonetarie` (conta 990933657879).