# Handoff de DEPLOY — 2026-07-20/21 (sessão Eduardo): SISBAJUD 5308 + conteúdo/logs reais do STA + indicadores de envio

**Para: Luiz / Micael.** Pacote na `feat/monetarie_improviments` (`3be24431..075f53aa` + este handoff, já com a main de 20/07 mergeada — `origin/main = 17b43fb1` está DENTRO da branch; o merge teve uma única interseção, `SisbajudView.vue`, resolvida adotando a decisão da main do filtro nascer vazio). Tudo com TDD + review adversarial por escopo; gates: core 473/0 (pacote judicial+sisbajud no container) + vitest admin 415/415 + vue-tsc 0; sta backend 1291 testes (só as 5 falhas pré-existentes conhecidas) + vue-tsc 0. Validação viva local com screenshots na sessão.

## O que o pacote entrega

1. **`fac1ec12` (sta-api)** — a cabine RETÉM o conteúdo dos arquivos recebidos (metadata, teto 2MB, inclusive nos retries) e o download re-baixa do BCB sob demanda para o acervo antigo (com verificação de sha256). Cura o `download_error_410` visto em PROD na tela Arquivos. Também: detalhe/listagem sem o blob, broadcast slim, filtros de data em dia de BRASÍLIA.
2. **`b6d81f2e` (sta-admin-ui)** — fix do skeleton ETERNO ao filtrar a tela Arquivos (loop infinito de refetch; watcher deep do Vue × reatribuição de pagination) + tela abre no dia corrente BRT.
3. **`9d028cd4` (sta-api + sta-admin-ui)** — tela "Logs em Tempo Real" passa a mostrar logs REAIS (a tela era 100% mock em 3 camadas; causa raiz: backends de Logger antigos são no-op desde o Elixir 1.15 — handler `:logger` novo). Canal de logs agora exige socket AUTENTICADO (o socket nunca tinha autenticado: salt errado + chave de token errada no front — corrigidos). Paginação 20/página.
4. **`e02d4319` (core-api)** — requisições de informação (5308) PERSISTIDAS (tabela `judicial_info_requests` revivida, CPF cifrado em repouso), endpoint `GET /v1/regulatory/sisbajud/info-requests` (mesmos gates de permissão do index), 5309 renomeado `RESP_INFO_<cnpj>_<data>` (distinto do 5302), preview do Upload reconhece 5308. **MIGRATION NOVA: `20260720230000`.**
5. **`61188b07` + `175520d4` (core-admin-ui)** — aba nova "Requisições de Info" (com filtro de data e atalho a partir dos Registros do 5309 na aba Arquivos), coluna Tipo (5302×5309) na aba Arquivos, filtros de Ordens alinhados (Resposta com os estados do badge, filtro por Tipo novo, Status completo).
6. **`11079c54` (core-api + core-admin-ui)** — saldo **bloqueado judicialmente** como INFORMATIVO (bloqueio não gera lançamento; o hold vive no TB e o extrato é batido TB×razão): endpoint de balance expõe `judicial_blocked`/`judicial_blocks_count` (centavos; `settle_failed`/`release_failed` CONTAM — hold segue vivo nesses estados), card âmbar no Resumo da conta, banner na tela de Extrato e bloco no rodapé do PDF. Sem migration. ⚠️ Pendência REGISTRADA para frente futura: a TRANSFERÊNCIA judicial (collect_funds) ainda não gera linha de débito no extrato — fechar antes da primeira TRANSFER real em PROD. **Ciclo bloqueio→desbloqueio VALIDADO vivo em local (21/07)** com remessas 5301 reais pela tela: ordem executed, hold TB congelado/devolvido ao centavo, card/banner aparecem e SOMEM sozinhos, COSIF `002→003` + estorno espelhado `003→002` (a `.003` zera). Inclui também `181d2c43`: alinhamento dos valores Saldo Anterior/Atual à coluna Saldo Acumulado do extrato.
7. **`a1bf6abf` + `e92b240b` (core-admin-ui; `e92b240b` toca também o core-api)** — pedidos do operador de 21/07: card **"Aguardando Envio"** no topo da tela SISBAJUD (conta respostas geradas/com falha SEM filtro — o envio ao BCB é manual e o filtro de data escondia pendências; clique abre a aba Arquivos só com as pendentes); badge "Aguardando envio" em âmbar na coluna Resposta (+ estado "Enviando" próprio para `delivering`); **motivo da falha no hover** (aba Arquivos e coluna Resposta — campo novo `response_file_error` no serializer do core-api, sem migration); filtro de data da aba Arquivos nasce VAZIO (mesma decisão da main `17b43fb1` — na virada do dia a aba abria vazia escondendo pendências).
8. **`b5e443cb` (core-admin-ui)** — remoção de travessão dos textos de UI do SISBAJUD (regra de escrita do dono; tooltips/labels usam vírgula/parênteses).
10. **`5b8f4b60` (core-api + core-admin-ui)** — balancete contábil de PROD saía visualmente errado por 3 causas, todas corrigidas: (a) linhas TRIPLICADAS — o plano tinha 4 famílias de código ativas (145 contas extras órfãs plantadas por Release.seed/ETL em 08-09/07 sem a poda do scd_cosif_setup; a hierarquia agrega por prefixo e cada família gerava linha sintética própria). **MIGRATION NOVA `20260721230000`** poda as órfãs (guardas: nunca apaga conta com lançamento/saldo/vínculo) e remove snapshots com data FUTURA; (b) sinais invertidos — a tela mostrava Ativo negativo e débito com '-' (inverso do balancete oficial WEBCTB); convenção alinhada em tela/PDF/XLSX/Balanço/Razão; (c) snapshot futuro — o ETL gravou 31/07 em 09/07 com valores daquele dia; gerador agora recusa data futura e o ETL só gera mês completo. ⚠️ Regra operacional NOVA: após qualquer `Release.seed` em PROD/HML, rodar `scd_cosif_setup.exs` na sequência (foi a ausência dela que poluiu o plano).
11. **`131b4ef7` (core-api + core-admin-ui + sta-api + sta-admin-ui)** — incidente REAL de 21/07: o BCB rejeitou o 5302 do PRIMEIRO ciclo automático (AJUD303 "cod 07 campo 010" nas 3 linhas = CNPJ_INSTITUICAO_BLOQUEIO em BRANCO). Pacote: (a) builder preenche o campo 10 (e os CNPJs dos registros 05/07) com o CNPJ do arquivo; (b) Validacao.Consumer CURA um arquivo rejeitado quando o veredito é de REENVIO comprovado (mesmo estágio re-executado ou protocolo STA maior; protocolo menor = redelivery stale, nunca rebaixa); (c) botão **Regerar** na aba Arquivos (rejeitado/falha): reconstrói o 5302 das ordens vinculadas com o builder atual NO MESMO registro e o Enviar reaparece — fim do beco sem saída do operador (fail-closed: só 5302, só ordens BLOCK com desfecho inequívoco); (d) Download liberado para rejeitado/falha + botão de download no banner da lista de registros; (e) STA: download ganha extensão pelo conteúdo (AJUD303 → .zip). Sem migration. ⚠️ NOTA OPERACIONAL (ciclo TODO fechado na sessão de 21/07): (a) o 5302 automático de 20/07 foi reenviado corrigido pela tela do STA e ACEITO pelo BCB (AJUD302 435830588 → AJUD303 435848168 SEM ERRO); arquivo de PROD curado à mão para confirmed (trilha `manual_cure` no metadata) — as 3 ordens mostram Aceita. (b) Os vereditos das RECUPERAÇÕES (15-17/07) tinham se PERDIDO (AJUD303s chegaram 20/07 14:31, ANTES do deploy da noite — STA velho publicava evento sem conteúdo); o operador recuperou os arquivos no portal STA do BCB e os vereditos foram aplicados à mão em PRD (trilha `manual_verdict_apply`): RESP-15 (435087162) e RESP-16 (435087274) rejeitadas com cod 03 campo 4 (DATA_MOVIMENTO do header) + cod 05 campo 2 (quantidade do rodapé) = janela de resposta fechada; RESP-17 (435111947) rejeitada com cod 07 campo 10 (mesmo CNPJ em branco). (c) RESP-17 corrigida FOI reenviada em 21/07 e o BCB rejeitou por JANELA FECHADA (cod 03 DATA_MOVIMENTO + cod 05 quantidade, veredito SEM id de remessa; os cod 07 das linhas SUMIRAM = a correção do CNPJ estava certa) — mesmo desfecho terminal das RESP-15/16, trilha `resubmission_20260721` no metadata; IMPORTANTE: esse veredito foi processado AUTOMATICAMENTE pelo Validacao.Consumer já deployado (prova viva de que a rejeição automática funciona em PRD). (d) As ordens dessas 3 remessas resolvem-se pela teimosinha do CNJ: parte JÁ FOI reapresentada na remessa de 20/07 20:34 e está ACEITA (EMERSON, FABIO); as demais (DO SUL, INSELETRO, LOOPTECH, JBG...) virão em reapresentações futuras, que pós-deploy respondem sozinhas com o campo 10 correto. NADA a fazer no deploy além de validar os status na tela; NÃO reenviar as respostas de 15-17/07 (janela fechada, rejeição é terminal e honesta).
12. **`075f53aa` (core-api + sta-api + sta-admin-ui)** — pedidos do operador de 21/07 noite: (a) respostas SISBAJUD nascem com o TIPO no nome (`RESP_5302_<cnpj>_<data>` / `RESP_5309_...`; homolog 5312/5319) — substitui o `RESP_INFO_` de 20/07; rename provado seguro (toda correlação é por metadata, nada casa nome por prefixo, BCB indiferente ao nome; arquivos antigos mantêm o nome que têm); (b) tela Arquivos do STA: coluna Sistema vira **Tipo** no vocabulário do BCB (enviados: 5302→AJUD302, 5309→AJUD309 via identificador do metadata, com whitelist p/ o 5300 do CADOC não virar "AJUD300"; recebidos: AJUD301/ACCS002 pelo nome; fallback = sistema). Sem migration.
9. **`660ca822` (sta-api + sta-admin-ui)** — a tela Arquivos do STA passa a mostrar os **ENVIADOS**: a lista só consultava `processed_protocols` e os uploads reais da cabine (5302, ACCS001...) vivem em `outbound_files` — em PROD o dashboard dizia "Arquivos de Saída 21" e a lista nunca mostrava nenhum (achado do operador 21/07). Lista agora mescla as duas tabelas (paginação sobre a união, dedup por protocolo, filtros valem para enviados); detalhe traz o motivo da falha do upload; retry usa o pipeline de upload verdadeiro e delete cancela pelo vocabulário certo (antes, retry/delete de um enviado = 500); card de saída com breakdown honesto (`uploaded` conta como concluído, `expired` como falha, `confirming` como enviando — antes os 20 uploaded de PROD apareciam como "0 concluído"); filtro de status e badge da UI ganham Enviado/Confirmando/Cancelado/Expirado nos 3 idiomas. Sem migration; testes 22/22 no controller + review adversarial 2 rodadas.

## ORDEM DE DEPLOY (regras específicas)

**1º core-api — com a migration ANTES do swap (pré-condição DURA):**

- Migrations `20260720230000` **e `20260721230000`** via `ecs run-task` com a IMAGEM NOVA + command override `eval migrate` ANTES do swap (método padrão de 19/07; em PRD usar a task-def leve `monetarie-core-migrate-prod` por causa do teto de memória). Conferir no log o `Migrated` das DUAS.
- Por que a ordem importa: o insert das requisições depende das colunas novas. O código tem fail-soft real (savepoint — um 5308 chegando na janela NÃO trava a resposta ao CNJ), mas a ordem certa evita ruído de log e requisições não persistidas.
- ⚠️ **Rollback de SCHEMA só com a tabela vazia** (a coluna do documento vira bytea CIFRADO; o down com dados é impossível). Rollback de CÓDIGO é livre (o schema novo é retrocompatível com o código velho).

**2º core-admin-ui** — depois do core-api (a aba nova consome o endpoint novo; UI nova contra API velha degrada para aba vazia).

**3º sta-api** — sem migration; deploy normal. Sem env nova obrigatória (`redownload_missing_content` default ON; OFF só em test).

**4º sta-admin-ui** — depois do sta-api (a UI usa o REST de logs com Bearer e o socket autenticado novos; contra a API velha, a tela de Logs mostraria erro honesto em vez de stream). Buildar **`sta/frontend/`** (contrato `STA_API_HOST` inalterado — as task-defs já ficaram certas no deploy de 17b43fb1).

Práticas de sempre: tag imutável por commit, PRD = retag da imagem de HML por imagetools com DIGEST MATCH conferido, rollbacks anotados.

## Validação pós-deploy (checklist)

- **Core**: `GET /v1/regulatory/sisbajud/info-requests` = 200 autenticado; na tela SISBAJUD a aba "Requisições de Info" abre; no próximo AJUD308 real, os pedidos aparecem na aba e a resposta sai como `RESP_INFO_...zip` na aba Arquivos com o Tipo distinto (o envio segue MANUAL pelo botão, como o 5302). O card **"Aguardando Envio"** deve refletir as respostas pendentes de PROD independente do filtro de data, e o hover num badge Falha/Rejeitada mostra o motivo real. Numa conta com bloqueio judicial ativo (as 13 ordens de PROD são no_balance — sem bloco; validar quando houver bloqueio real), o Resumo mostra o card "Bloqueado Judicialmente" e o Extrato o banner âmbar.
- **STA tela Arquivos**: filtrar (Status/Sistema) NÃO pode mais travar em skeleton; a lista abre no dia corrente; baixar um arquivo NOVO funciona na hora; baixar um HISTÓRICO (ex.: AJUD305 de 17/07) deve funcionar via re-download do BCB (se o BCB ainda retém o protocolo; senão 410 com mensagem honesta).
- **STA tela Logs**: logado, status "Live" e logs REAIS da aplicação (Phoenix/consumers), paginados de 20 em 20. Buffer vazio logo após o boot é normal (enche com o tráfego).
- **STA tela Arquivos (enviados)**: com Direção = Saída, os uploads de PROD (os "21" do card) devem aparecer na lista com status traduzido (maioria "Enviado"); o card "Arquivos de Saída" do dashboard deve mostrar breakdown coerente (soma = total) em vez de "0 concluído".
- **Balancete (Contabilidade → Relatórios Contábeis)**: gerar o Balancete Contábil pós-deploy — cada nível deve aparecer UMA vez (sem ATIVO/DISPONIBILIDADES triplicados), Ativo POSITIVO, Passivo/PL/Receitas negativos, débitos positivos e créditos com '-' (mesma convenção do balancete oficial WEBCTB). Conta de liquidação `1.1.2.10.01.10.001` deve bater positiva com o razão (~R$ 3,09M em 21/07).
- Seguem valendo do handoff anterior: vigiar o CCS de terça 01:00 BRT (`202607220001`) e o AJUD305 noturno populando as varas.

## 🔴 Segurança (registrar na frente do finding conhecido)

O finding `/api/v1/*` do sta_connector SEM autenticação fica **mais grave** com este pacote: o download agora serve os bytes REAIS de arquivos judiciais (PII) e o re-download alcança o BCB sob demanda (o endpoint `GET /files/protocol/:number` permite resolver protocolos numéricos → UUIDs). O canal de LOGS via WebSocket já ficou fail-closed neste pacote, mas o escopo REST v1 segue aberto — **prioriza o token m2m + SsoAuth** (coordenar com o core, que sobe CCS por essa API).

## Follow-ups registrados (não bloqueiam o deploy)

- SISBAJUD: claim atômico próprio no `Delivery.send_via_sta` (o Regerar tem claim; o Enviar ainda pode gravar por cima num envio em voo iniciado antes — janela mínima, single-operator); rebuild do 5309 (hoje só 5302); DH do fio em UTC vs convenção BRT do leiaute (pré-existente ao pacote, o BCB aceita sintaticamente).
- RBAC: vínculo `Super Admin` do admin `eduardo@vulci.com.br` foi criado À MÃO em PRD em 21/07 (metadata `operator_fix_20260721`) — Micael formalizar no fluxo de criação de admin (criação nascia sem grupo RBAC).
- Contábil: auditar `posting_templates` do seed 030 que apontam para códigos COSIF não-canônicos (STR_TRANSFER/SEL_* — caminho dormente de securities; primeiro uso falharia com account_not_found após a poda).
- Contábil: embutir a poda SCD no fluxo do próprio `Release.seed` (hoje depende do operador rodar `scd_cosif_setup.exs` na sequência).

- Filtro server-side por `response_file_id` em `list_info_requests` (hoje o atalho dos Registros filtra no cliente sobre o limit da listagem — mesma limitação pré-existente do lado das Ordens).
- MetricsView do STA ainda tem mock próprio (mesma classe do que foi eliminado na tela de Logs).
- Timeout menor no client do re-download (hoje pode segurar o request até ~60s no pior caso antes do 410); rate-limit/negative-cache no re-download quando a frente do token m2m entrar.
- Telemetria/alerta quando a persistência de requisições retornar vazio com pares não-vazios (hoje só ERROR em log).
- `Files.list_protocols` (canal STA) ainda carrega o blob do banco na listagem (o REST admin já exclui).

Co-Authored-By: Claude Fable 5