# Auditoria do fluxo do cliente (Partner API) e telas ib/merchant, com evidência arquivo:linha

Data: 2026-07-17 (noite). Base: `origin/main = HEAD = 17815a90`, working tree limpa.
Metodologia: 6 trilhas de auditoria read-only em paralelo (Partner API, cabine PIX, cabine SPB,
referência AVIV em `/Users/luizpenha/coreproviders`, estado atual das telas, docs/Postman),
todas com mandato de evidência arquivo:linha e proibição de inferência. Classificação por item:
(a) existe e funciona ponta a ponta, (b) parcial/stub, (c) falta criar do zero.

Convenção de caminhos: relativos a `/Users/luizpenha/monetarie`. Partner API = `core/backend/lib/monetarie_web/{router.ex,controllers/partner_v1/*}`. Cabine PIX = `pix/backend/apps/*`. Cabine SPB = `spb/services/bacen_gateway`.

## 0. Contexto da Partner API (fundação para todas as rotas novas)

- Scope: `router.ex:133-222` (`/api/partner/v1`), pipeline `[:api, :partner_authenticated, :idempotent]`; auth OAuth client_credentials em `plugs/partner_bearer_auth.ex:45-56`; mapa rota-escopo em `plugs/permission_enforcer.ex:17-84` (SEM entradas para infraction e events).
- Padrão de resposta: sucesso `%{data: ...}`; erros `%{error: %{status, message}}` via helpers locais (`partner_v1/pix_controller.ex:2055-2069`); erros de cabine via `cabin_error/3` e `cabin_app_error/3` (`pix_controller.ex:2025-2053`).
- Catálogo de webhooks: 33 eventos + `webhook.test` em `schemas/webhooks/webhook.ex:33-49`, servido em `GET /webhooks/events` (`router.ex:212`). Existem `pix.claim.*` (5) e `pix.infraction.created|resolved`. NÃO existem `pix.med.*` nem `ted.refund.*`.
- Duas pontes Core para cabine DICT: (1) NATS req/reply `dict.api.request` (`dict_service/lib/dict_service/nats/dict_api_responder.ex`), usada pelo adapter `in_house` do Core; (2) HTTP via `settlement_service/lib/settlement_service/workers/core_event_processor.ex` chamando REST do dict_service.

## 1. Infrações na Partner API: (c) não existe a superfície; (b) cabine quase completa

Partner API: nenhuma rota de infração no scope (`router.ex:133-222`); nenhuma entrada no PermissionEnforcer; nenhuma action em `partner_v1/*`. O provider do Core JÁ tem as 5 operações (`services/pix_providers/provider.ex:81-85`: create/get/list/close/cancel_infraction) publicando em `dict.api.request` (`in_house/adapter.ex:266-294`), mas nada as chama pela Partner API.

Cabine PIX:
- Cliente DICT 2.11.0 COMPLETO e assinado: `shared/lib/shared/bacen/dict_client.ex` `create_infraction_report/2` L692, `get` L748, `list` L765, `acknowledge` L805, `close` L848 (AGREED/DISAGREED + FraudType), `cancel` L907.
- Contexto pronto: `dict_service/lib/dict_service/infractions.ex` (create L69, acknowledge L184, analyse L288, close L345, cancel L447, list L547), fail-closed BACEN-primeiro com outbox.
- INBOUND vivo e supervisionado: poll `poll_and_route_inbound_from_bacen/2` (`infractions.ex:669`) publica `monetarie.dict.med.infraction_received` L731; consumido por `spi_service/.../med/infraction_responder.ex` (supervisionado em `spi_service/lib/spi_service/workers/supervisor.ex:26`) que abre fraud claim + cautelar 72h.
- Loop de DEFESA vivo: `dict_service/lib/dict_service/nats/infraction_response_consumer.ex` (supervisionado, `application.ex:35`) consome `monetarie.dict.infractions.response` do Core: ACKNOWLEDGED L81, DISAGREED L94 (analyse+close), AGREED L156/162 (analyse+close+devolução `monetarie.spi.return.created` FR01).
- DEFEITO ESTRUTURAL: o CREATE de infração ao BACEN é ÓRFÃO em produção. O responder NATS `dict_api_responder.ex` só despacha `list_infractions` L291 e `get_infraction` L314 (sem create/acknowledge/close/cancel). O caminho HTTP do Core (`core_event_processor.ex:1404` `handle_infraction_create` fazendo `POST /api/v2/infraction-reports` L1422) aponta para rota INEXISTENTE (router do dict_service `dict_service_web/router.ex:263-267` só tem GET index/show + PUT acknowledge/analyse/close; `infraction_report_controller.ex` não tem `def create`). Resultado: 404. Único chamador real de `create_infraction_report/1` é o reconciliador (`dict_external_reconciler.ex:163`).

Fora da Partner API existem: leitura de infrações no merchant portal (`router.ex:3361-3362` -> `V2.MerchantPortalController.list_infractions/show_infraction`, lendo da cabine via Provider `v2/merchant_portal_controller.ex:392-411`) e gestão/defesa no admin (item 4).

## 2. Claims /pix/claims: (b) parcial na superfície; (a) cabine completa

Partner API (`router.ex:179-182`, ações em `partner_v1/pix_controller.ex`):
- `POST /pix/claims` create_claim :372-401 (parceiro reivindicador); `GET /pix/claims/:id` show_claim :502-506; `POST .../confirm` :510-520 (ação do doador); `POST .../cancel` :524-534. Escopagem `scoped_claim/4` :539-560 aceita claimer OU donor da conta do parceiro.
- FALTA: `GET /pix/claims` (listagem). `Provider.list_claims` existe (`provider.ex:118`; `adapter.ex:423-424`) e o responder da cabine despacha `list_claims` (`dict_api_responder.ex:96`), só não há rota.
- FALTA: `POST /pix/claims/:id/complete` (conclusão pelo reivindicador). A cabine implementa `complete_claim` com validação de posse (`claims.ex:224`, OTP L232) e o responder despacha `complete_claim` (`dict_api_responder.ex:151`), sem rota partner.
- Lado receptor (doador): JÁ FUNCIONA por webhook. Consumer durável `core-dict-lifecycle-consumer` (`infra/nats/consumers/dict_lifecycle_consumer.ex:27-34`, subjects `monetarie.dict.claims.*`) + handler `infra/nats/handlers/dict_lifecycle_handler.ex:38-46,87-127` mapeando para `pix.claim.created|acknowledged|confirmed|cancelled|completed` com resolução do titular local e fail-closed.

Cabine (o ciclo mais maduro do sistema): `dict_service/lib/dict_service/claims.ex` create L78, acknowledge L139, confirm L181, complete L224, cancel L273; prazos 7/14/30 L43-45 com timers duráveis JetStream (`schedule_deadline_event` L1771; `claim_deadline_consumer.ex` supervisionado em `application.ex:34`); auto-resoluções L777/L890/L931; poll dos DOIS papéis (`inbound_sync.ex:244-248`, pernas `:claims_donor` e `:claims_claimer`); publish `monetarie.dict.claims.inbound_received` L645. Nota: `CONTEST` está em `@claim_actions` (`dict_api_responder.ex` contexto L34) sem lifecycle implementado.

## 3. MED 2.0 /pix/med: (b) parcial na superfície; cabine com 2 defeitos

Partner API (`router.ex:186-187`): só `POST /pix/med` create_med (`pix_controller.ex:408-437`, valida conta do parceiro + transação raiz por e2e :470-486, chama `Provider.create_recovery`) e `GET /pix/med/:id` show_med (:442-465).
FALTAM (todos já existentes no provider, sem rota): `cancel_recovery` (`provider.ex:98`), `list_recoveries` (:93), `request_med_return` / `list_med_returns` / `list_med_notifications` / `get_recovery_graph` (:94-97).

Cabine PIX:
- Cliente DICT completo: `/refunds` (`dict_client.ex` create L984, get L1018, list L1044, cancel L1085, close L1121) e `/funds-recoveries` (create L553, get L608, tracking L624, cancel L648, refund_request L948).
- Contexto `funds_recovery.ex` completo (create L71, refresh_tracking L183, refund_request L229, complete L266, cancel L336/L462, list L573, poll inbound de refunds L619 publicando `monetarie.dict.recovery.refund_received` L756).
- A liquidação da devolução especial NÃO sai do FundsRecovery: sai pelo SPI via pacs.004 (`monetarie.spi.return.created` reason FR01, `infraction_response_consumer.ex:162` -> `return_processor.ex:184`).
- DEFEITO 1: `recovery_complete_refund` do Core aponta para rota inexistente. `core_event_processor.ex:1358/1375` chama `PUT /funds-recoveries/refunds/{id}/complete`; o router da cabine só tem `PUT /refund-requests/:id/complete` (`dict_service_web/router.ex:272`). Resultado: 404.
- DEFEITO 2: a máquina MED do SPI existe mas NUNCA É SUPERVISIONADA: `SpiService.Med.ResolutionConsumer` (libera cautelar via camt.029), `CautelarWorker`/`TimerEnforcer` (prazos 30min/7d/90d + expiração), `Trck002Handler`. Nenhuma referência em `spi_service` `application.ex`/`workers/supervisor.ex` (só `Med.InfractionResponder` está no supervisor :26). Liberação de cautelar e enforcement de prazos estão MORTOS em produção.
- Responder NATS: MED só tem list/get/create/tracking (`dict_api_responder.ex:166-264`); sem dispatch de refund create/cancel/close.
- Webhooks `pix.med.*` não existem no catálogo.

## 4. Publicação de defesas: (a) existe só como admin; (c) inexistente no fluxo do cliente

- Rota atual: `POST /api/admin/infractions/:id/defense` (`router.ex:2523`) em scope `admin_only` (`router.ex:2313-2314`, plug EnsureAdmin) e por isso o lojista recebe 403. Guardas extras no controller (`admin/infractions_controller.ex:26-34`).
- O que a defesa admin faz de verdade: atualiza um `MedCautelarBlock` (`admin/infractions_controller.ex:115-127, 291-309`: grava `defense_text` em `evidence_metadata`, `analysis_status: "defense_submitted"`); a resolução chama `UseCases.Med.Processor.resolve_analysis/4` (:331-337).
- O loop de defesa de infração DICT (responder ao relato contra nós com ACKNOWLEDGED/AGREED/DISAGREED) já existe na cabine (`infraction_response_consumer.ex`, item 1) alimentado pelo subject `monetarie.dict.infractions.response`; falta o gatilho partir do cliente (Partner API).
- Referência AVIV: defesa do merchant com `defense_text` + até 5 arquivos 10MB (`fluxiq_web/controllers/merchant/infractions/defense_controller.ex:21-105`), defensável só em open/ACKNOWLEDGED (:52), prazos de urgência 48h; defesa MED com evidence tipada e estados defensáveis (`external/pix/med_defense_controller.ex:21-71`); resposta ao DICT sempre restrita a `AnalysisResult in {ACKNOWLEDGED, AGREED, DISAGREED}` com guard de papel (só o participante CREDITADO fecha; `fluxiq pix_compliance.ex:1040-1049`).

## 5. Refund /pix/payments/:id/refund: (a) existe, mas com semântica CEGA (defeito real)

- `router.ex:169` -> `partner_v1/pix_controller.ex:1050-1134`, lógica inline no controller.
- O que faz: escopo da conta -> `StatusGate` -> valida valor -> saldo -> `hold` da PRÓPRIA conta do parceiro -> cria `PaymentTransactions` outbound com `metadata.message_type: "pacs.004"` -> publica `Provider.return_funds` no subject `monetarie.core.pix.return` (`in_house/adapter.ex:41-46`) com `original_transaction_id` e `end_to_end_id` AMBOS = o `:id` da URL -> webhook `pix.refund.requested` (:1108).
- DEFEITO: NUNCA carrega a transação original. Não valida existência, direção (inbound vs outbound), titularidade nem teto (valor da original). Um `:id` de PIX ENVIADO passa direto: debita o parceiro e publica pacs.004 semanticamente inválida (rejeição só a jusante). Também aceita `:id` inexistente.
- Semântica BACEN correta: pacs.004 é emitida pelo RECEBEDOR do pagamento original. O endpoint deve cobrir devolução de PIX RECEBIDO pela conta do parceiro (a devolução em si é um movimento de saída). Para PIX ENVIADO pelo parceiro e devolvido pela contraparte, o fluxo é INBOUND: a cabine processa a pacs.004 recebida (`inbound_processor.ex:202` -> `process_incoming_return` L1167, aceite pacs.002 L1298, crédito gated por liquidação camt.054 BOOK L1521-1564) e publica `monetarie.spi.transaction.returned` ao Core (`event_publisher.ex:158`; `core_event_adapter.ex:50` type `pix_return`). O catálogo tem `pix.payout.returned`; a ponta Core->webhook do parceiro precisa ser validada na implementação.
- Ressalva da cabine a verificar: `core_event_processor.ex:841` (`handle_return_request`, subject `monetarie.core.pix.return_request`) cria a linha pacs.004 e publica `transaction.returned` sem montar xml nem enfileirar `outbound.return`; o envio real passa por `monetarie.spi.return.created` -> ReturnProcessor. O caminho vivo do IB (provado em produção nas devoluções parciais de 14-15/07) usa `monetarie.core.pix.return`.

## 6. Devolução de TED: (c) superfície inexistente; (a) motor SPB COMPLETO

A cabine SPB já tem o ciclo STR0010 de ponta a ponta:
- XSD v5.12 (`priv/xsd/v512/STR/STR0010.XSD`, choice STR0010/R1/R2; `STR0010E.XSD`), catálogo `priv/catalog/v512_message_routes.json` (só v512).
- Builder outbound `messages/str/str0010.ex:42-93` (CodMsg, NumCtrlIF, ISPBIFDebtd/Credtd, VlrLanc fail-closed, CodDevTransf, NumCtrlSTROr, Hist, DtMovto); parsers `str0010r1.ex:34-64`, `str0010r2.ex:46-75`, `str0010e.ex:88-106` e parse da STR0010 recebida (`str0010.ex:101-132`).
- Motor: `devolution/devolution_engine.ex:409-474` `build_and_send_return/1` resolve a TED original inbound por `control_number_clearing = NumCtrlSTR` (:616), valida returnable (:647), idempotência (:667), monta com INVERSÃO de ISPBs e valor integral (:485-504), despacha pelo mesmo wiring do STR0008 vivo (:701) e publica desfecho no subject dedicado `monetarie.spb.credits.return_status` (:367-368; outbox `outbox/worker.ex:179`).
- Respostas processadas: `post_integration/specific_handlers/str_handler.ex:68-86` roteia R1/R2/E para o engine; idempotência de R2 duplicado em `lifecycle_engine.ex:606-616`.
- O consumer do Core JÁ ACEITA a ordem: `consumers/core_event_consumer.ex:217` `handle_event("devolution_request")` -> `DevolutionEngine.build_and_send_return/1` (payload com `num_ctrl_str` da original + `reason_code` numérico; domínio de motivos `devolution/reason_codes.ex:26-87`, default "70").
- Operador já tem via dedicada: `POST /api/devolutions` (`devolution_controller.ex:34`; rotas `router.ex:356-361`) + tela `DevolutionsView.vue`.

O que falta (lado Core/Partner):
- Rota Partner de solicitação de devolução de TED recebida; use case Core que resolva a transação de crédito TED do cliente até o `NumCtrlSTR` (verificar onde o Core guarda esse vínculo ao consumir `monetarie.spb.credits.inbound`); publish do `devolution_request` em `monetarie.core.spb.*`; consumer no Core para `monetarie.spb.credits.return_status` (não encontrado consumidor no Core); webhooks `ted.refund.*` (inexistentes no catálogo).
- Notas SPB: colunas runtime do engine criadas via `ensure_runtime_columns/0` (`devolution_engine.ex:896-932`) sem migration formal; design doc citado nos comentários (`docs/plans/2026-06-10-spb-efetividade-devolucao-completa-design.md`) NÃO existe no repo; PAG0111 mapeado como tipo de retorno não-STR sem builder despachável (gap fora do escopo TED/STR).

## 7. Migration 20260717150000 (key_type UPPER): pronta, não deployada

Commitada em `ab49616d`. Aplicar via `bin/monetarie_pix rpc "Shared.Release.migrate()"` HML+PROD no PRÓXIMO deploy do pix-api (que os itens 1/3 desta frente exigirão). Deploy só com OK do dono.

## 8-10. P0 das telas (estado confirmado em 17815a90)

8. QR stub confirmado: `v2/pix_controller.ex:702-717` (BR Code por interpolação SEM CRC16, tag 54 malformada, `qrcode_base64 = nil`). Motor real da cabine acessível pelo gateway já usado pela Partner API (`use_cases/pix/gateway/qr_code.ex:28,40`, subjects `monetarie.pix.qrcode.static|dynamic`).
9. Copia-e-cola confirmado: `PixCopyPasteView.vue:59` chama `pix.payQrCode` que não existe em `usePix.ts` (exports :426-440). Backend pronto: `pay_qrcode/2` em `v2/pix_controller.ex:753` (rotas `router.ex:3164` e self `router.ex:3283`) EXECUTA o pagamento; o passo de leitura/consulta que a tela espera é `POST /api/pix/qrcode/consult` (`router.ex:3282`). O conserto correto do front é: consultar -> confirmar -> pagar.
10. Cobrança paga: consumer `core-pix-qrcode-consumer` vivo (`infra/nats/consumers/pix_consumer.ex:50-54,118-120` -> `use_cases/pix/charge_paid.ex`: gate pelo crédito liquidado :74-86, `mark_paid` :92-102, webhook `pix.charge.paid` :108-121). As telas JÁ leem o espelho via `GET /api/qrcodes[/:id]` (`router.ex:3333-3334`; ambos os fronts chamam), MAS: (i) o serializer mapeia `"paid" -> "used"` (`merchant_portal_controller.ex:1072`), o usuário nunca vê "Pago"; (ii) a criação de cobrança persistida pela tela é 501 (`merchant_portal_controller.ex:171-176`), então o lojista de tela não tem cobrança para ver. Validar ponta a ponta EXIGE fechar o item 8 + expor o status pago.

## 11-16. P1 das telas (estado confirmado)

11. TED agendada: v1 ramifica por `settlement_date` (`ted_controller.ex:46-57`); v2 ignora agendamento (`v2/transfer_controller.ex` sem ScheduledTed; `scheduled_date` só vai como campo morto no fio :672); o front nem envia `scheduledDate` (tipo em `useTransfer.ts:9`, nenhuma view popula) e `TransferScheduledView.vue:66` consulta fonte que nunca verá `scheduled_teds`.
12. Limites: enforcement real (`use_cases/limits/transaction_limits.ex:80-117`, hierarquia conta -> primária -> GlobalLimit -> defaults :50-66, piso noturno R$1.000 :47; `limit_check.ex:50-88`). Endpoints existentes: Partner GET/PUT `/accounts/:id/limits` (`router.ex:152-153`); Admin (`router.ex:2399,2408`); GlobalLimits admin (`router.ex:2831-2834`). NO ESCOPO DO USUÁRIO (V2) NÃO EXISTE NADA. Telas: banking `LimitsView.vue` e `PixLimitsView.vue` estáticas; merchant `LimitsView.vue` estática; merchant `PixLimitsView.vue:67` chama `GET /limits` INEXISTENTE (o único `/limits` é `/api/discount/limits`, factoring) e degrada para fee-preview.
13. TEF: `merchant_portal_controller.ex:181-182` 501; handler real no partner `transfers_controller.ex:237` (`internal`, monta OutboundPaymentParams type "tef" :513-526).
14. PIX Automático: `in_house/adapter.ex:88-137` publica recurrence/mandate/camt/pibr/reda com envelope `%{"data" => params}` SEM `event` (`nats_publish/3` :458-460) e cai no catch-all/DLQ. O trilho vivo é `monetarie.spi.recurrence.execute`. Confirmar vivo qual trilho as telas chamam.
15. Rotas v1: `POST /api/v1/pix/in|/out` montadas (`router.ex:289-290`) publicando `%{"type"..., "data"...}` sem `event` (`pix_controller.ex:108-111,192-195,197-207`) -> DLQ.
16. Chamadas mortas do merchant (base `/api`, `api.ts:4`): `GET /transactions/search` (`StatementView.vue:132`, rota inexistente); `/transfers/favorites` bare (`useTransfer.ts:87,101,115`; existe scoped `router.ex:3082-3084`); `/transfers/lookup-account` (`useTransfer.ts:128`, inexistente); `POST /kyc/submit` + `GET /kyc/status` (`api.ts:274-276`, inexistentes); onboarding `/api/onboarding/:merchantId` (`api.ts:284-286`) COLIDE com onboarding PF/Nextcode (`router.ex:3932-3938`), não com admin. CORREÇÃO ao mapeamento anterior: webhooks do merchant JÁ estão scoped e VIVOS (`api.ts:221-237` -> `router.ex:3182-3194`).

## 17. GET /accounts/:id/events: (c) não existe

Rota nunca montada (accounts partner = `router.ex:145-156`), sem action `events` no `partner_v1/accounts_controller.ex`. Único "events" partner é `GET /webhooks/events` (catálogo). Definir a fonte (eventos da conta: ciclo account.*, entregas de webhook, trilha de auditoria) na implementação.

## 18. Docs portal + Postman (estado para a regeneração final)

- Existem DOIS portais: `docs-portal/` (interno docs-h, nginx estático com infra ECS viva: `infra/aws/greenfield/ecs.tf:350-357`, `alb-internal.tf:119-125`; agrega os docs/ no build `docs-portal/Dockerfile:8-15`) e `docs/partner-portal/` (VitePress trilíngue pt/en/es, `.vitepress/config.ts:89-145`), que tem Dockerfile pronto mas NENHUMA infra no Terraform (sem ECR/ECS/ALB; decisão de onde publicar fica para o deploy).
- OpenAPI: gerado do código via open_api_spex (`api_spec/api_spec.ex`, paths do router :96, security partner_oauth :67-93), servido vivo em `/api/swaggerui`. Não há arquivo estático versionado.
- Postman: mantida À MÃO em cópias byte-idênticas `docs/postman/Monetarie-Partner-API.postman_collection.json` e `docs/partner-portal/public/...json` (md5 igual). Precisa de reconciliação manual item a item ao final da frente (manter as 2 cópias em sincronia).
- Webhooks documentados em `docs/partner-portal/endpoints/webhooks.md` (3 línguas), que afirma paridade 1:1 com `GET /webhooks/events`; manter essa paridade ao adicionar eventos novos.

## Defeitos NOVOS achados pela auditoria (além dos itens do mandato)

1. Refund partner "cego" (item 5): debita o parceiro sem validar a transação original. Money-path real.
2. CREATE de infração órfão na cabine: cliente/contexto prontos, sem gatilho de produção (NATS sem dispatch de escrita; HTTP POST sem rota). 404 garantido no caminho HTTP do Core.
3. `recovery_complete_refund` Core -> cabine: URL errada, 404 garantido.
4. Máquina MED do SPI não supervisionada: ResolutionConsumer, CautelarWorker/TimerEnforcer, Trck002Handler mortos em produção (liberação de cautelar e prazos MED não rodam).
5. Serializer de QR esconde o pago: `"paid" -> "used"` (`merchant_portal_controller.ex:1072`).
6. Merchant `PixLimitsView` chama rota inexistente e degrada em silêncio para fee-preview.
7. `handle_return_request` da cabine aparenta registrar pacs.004 sem enviar (verificar na implementação do item 5).
8. `Provider.create_infraction` do Core publicaria action sem dispatch no responder (cai no catch-all "Unknown action" `dict_api_responder.ex:485`).
9. Colunas runtime do DevolutionEngine sem migration formal (`ensure_runtime_columns/0`).
10. Design doc referenciado e inexistente no repo (`2026-06-10-spb-efetividade-devolucao-completa-design.md`).

## Referência AVIV (síntese do que importa portar em conceito)

Stack Elixir/Phoenix (fluxiq), 3 APIs de cliente (merchant JWT, external api_key+HMAC, integration token). Infrações: ciclo completo no merchant (create/close/leitura + defesa com `defense_text` + 5 arquivos 10MB, defensável só open/ACKNOWLEDGED, prazos com urgência 48h), webhooks `pix.infraction.created|resolved|defense_submitted`. MED: blocos cautelares com `analysis_status` (pending/defense_submitted/analyzing/founded/unfounded/cancelled), prazo default 72h, founded -> pacs.004 -> transferred, unfounded -> libera; MED programático com `respond` agree/disagree; devolução com código BACEN normalizado (default MD06; texto livre derrubava o SPI com AB03). Claims: create/confirm/cancel do reivindicador; SEM webhook de claim (nós já temos, vantagem nossa). Compliance sync por poll de 15 min com reconciliação de CLOSE na fonte; resposta ao DICT restrita ao previsto pelo BACEN (`AnalysisResult in {ACKNOWLEDGED, AGREED, DISAGREED}`) com guard de papel (só o participante CREDITADO fecha a infração).