Store ALL-ON 2401. ready-for-handling → ProntoSeparar. MEDIDO: updi-getvendas 1× (a CRIAÇÃO do pedido, não o PaymentApproved) e crmbonus-stock-update 1× (a reserva). O destino da rota de estoque é `Ifood`; quem executa é o CrmBonusIntegrator, e por isso o endpoint observado é do CrmBonus. varejo-create-order 0×: separação não ocorre em ProntoSeparar. vtex-stock-update 0×: loopback exclui a origem.

Store ALL-ON 2401. handling → EmFaturamento: passa por ProntoSeparar (reserva estoque no CrmBonus, 1×) e dispara InvoicingStarted (Updi). updi-getvendas 2× = criação + faturamento. varejo-change-status 0×: SeparationFinished vive ADIANTE de EmFaturamento e o webhook não o alcança. crmbonus-order-status 0× (origem-VTEX sem ECCrmBonusSequence).

Store REALISTA 2921 (um ERP, dois canais). handling → passa por ProntoSeparar e dispara InvoicingStarted. Só `Updi` recebe: a loja não tem CrmBonusIntegrator, então a reserva de estoque que a 2401 faz aqui NÃO acontece (crmbonus-stock-update 0×), e não há rota de SepFinish (varejo 0×). O contraste com all-on-emfaturamento é o ponto: mesma transição, uma linha na aba de outbound em vez de duas.

Store REALISTA 2921. canceled → IntegrateOrderCancelled com UM destino (Updi). O contraste com all-on-cancelado é direto: lá a mesma tag roteia Ifood E Updi, e o cancelamento sai por dois caminhos.

Store 2922: config no nível de LOJA, um ERP (Updi), canais SITE + IFOOD. Venda via VTEX em ready-for-handling. É o par MÍNIMO que produz as DUAS pernas: updi-getvendas (criar pedido no ERP, via IntegrateOrderCreated) e crmbonus-stock-update (atualizar estoque; o destino da rota é `Ifood`, e o CrmBonusIntegrator é quem executa). Contraste com a 2921, que tem MKPlace em vez de IFOOD e por isso produz só a perna do ERP.

Store ALL-ON 2401 com status `invoiced` — o quinto e último status de entrada que a tela oferece, e o único que nenhum cenário cobria. MEDIDO: produz updi-getvendas E crmbonus-stock-update (a reserva da criação), e NÃO vtex-invoice — IntegrateInvoice é comando do operador.

Pedido que NASCE no CrmBonus, não na VTEX: POST /api/v2.0/CrmBonusOrder/Save. Escolhe a org pelo `sellerId` (= Store.SystemCode), então roda na loja realista 2921 — o ECId gerado carrega os dois: IFOOD-2921-<data>-CRMB-<run>-01. SalesChannelId é IFOOD, chumbado no controller. PROVA A ENTRADA pelo canal, não o fan-out: a descida ao Updi acontece (medido no log), mas a captura entra por fila e o traceId do cenário não atravessa esse salto, então a correlação não a alcança — afirmá-la seria falhar por instrumentação. Gap registrado.

Pedido que NASCE no MKPlace: POST /api/v2.0/MKPlaceWebhook/Order. A rota só exige `_id` e resolve a org de configuração GLOBAL (MKPlaceWebhookBusinessUnitId/StoreId/SellerSystemCode), apontada para a 2921 pelo seed — não há como escolher a loja por cenário. Prova a ENTRADA pelo canal; o que o pedido produz depois depende do inbox, e por isso as expectativas aqui são de ausência do que NÃO deve acontecer.

Store ALL-ON 2401. payment-pending → PagamentoPendente: IntegrateOrderCreated (Updi, updi-getvendas) + ReserveStock (CrmBonus; Vtex dropada por loopback). SEM separação (varejo-create-order 0×). Prova o gating por status do Map.

Store ALL-ON 2401. canceled → Cancelado: IntegrateOrderCancelled (Updi, updi-getvendas) + DropReserveStock. O DROP não exclui a origem (loopback assimétrico) → o estoque vai a CrmBonus E Vtex (vtex-stock-update REAPARECE, diferente do forward). crmbonus-order-status = 0× (origem-VTEX sem ECCrmBonusSequence).