Cria na loja 1000 um pedido VIVO (ready-for-handling → ProntoSeparar) e ELEGIVEL para troca: pagamento em cartao, entrega delivery, itens de uma loja so. Nao abre janela nenhuma — a janela nasce depois, quando VOCE cancelar o pedido em /v2/orders escolhendo um motivo do grupo LOJA (SPEC 057). Motivo do grupo CLIENTE cancela e NAO abre janela. Depois de cancelar, o pedido entra em AguardandoNovoSeller e aparece em /v2/change-seller para as lojas 1001 e 1002. O pagamento e o detalhe que mais derruba este roteiro: o default do simulador e Pix, que a SellerChangeEligibilityPolicy nega — por isso aqui e creditCard, e por isso nao adianta ajustar depois (o pagamento e gravado na criacao e o reimport nao o reescreve).

O outro gatilho da janela, e o original (SPECs 044-048): quem avisa que a loja perdeu o pedido e o CANAL, nao o operador. O pedido do seller chega cancelado e o sinal mora no pedido PAI — `marketplaceStatus = window-to-change-seller`. Sai pronto para capturar: va direto a /v2/change-seller logado pela loja 1001 ou 1002. Qualquer outro valor de marketplaceStatus FECHA a candidatura (SPEC 048) — e o mesmo sinal nos dois sentidos. O assert de `vtex-cancel-order` em 0x e o que distingue janela ABERTA de recusada: quando a elegibilidade reprova, o use case cancela o pedido pai no canal e essa chamada aparece. Zero chamada com o TTL ausente tambem seria 0x, mas ai o pedido nao aparece na lista — se a lista vier vazia, e o TTL (OrderInChangeSellerHoursToLive na BU 1000).

A troca INTEIRA sem tela: cria o pedido na loja 1000 pela descida da SystemHope (cartao, delivery, um SKU), cancela como LOJA (o que abre a janela — motivo do grupo CLIENTE nao abriria), e captura pela irma 1001. O que o cenario afirma e o que so existe em execucao: `systemhope-move-location` (o FulfillmentOrder foi movido para a Location da loja que assumiu) e `systemhope-get-order` (a segunda perna buscou o pedido reatribuido, de onde o pedido da 1001 nasce pelo import). O cancelamento tambem afirma AUSENCIA de `systemhope-cancel`: pedido oferecido as irmas segue vivo na Shopify, e cancelar la seria irreversivel. Se o passo 2 disser que o pedido nao foi resolvido, o import nao concluiu — confira Sync.ImportItem (SupplierId 8, EntityTypeId 4), nao o cenario.

O mesmo pedido, pago em Pix. A `SellerChangeEligibilityPolicy` nega Pix, boleto, Pagar na Loja e Pagaleve — o que os quatro tem em comum e nao permitir reatribuir a cobranca a outra loja. O cancelamento ACONTECE (HTTP 200); o que nao acontece e a oferta, e o desfecho vem no CORPO (`sellerChangeWindow: RefusedByPolicy`), nao no status. E por isso que o passo declara `expectWindow`: sem ele este cenario ficaria verde tambem quando a janela abrisse, que e exatamente o defeito que ele existe para pegar. Sem janela nao ha captura, entao o passo 3 nao existe e a prova e a ausencia de `systemhope-move-location`.

A captura responde OK ao operador e a reatribuicao falha DEPOIS, no parceiro: o `systemhope-move-location` deste pedido devolve 422. E o desenho que torna a recusa compensavel — no instante da chamada existe um pedido so, entao devolver o pedido para AguardandoNovoSeller e reabrir a candidatura nao esbarra em referencia externa duplicada. Duas afirmacoes: o move-location acontece UMA vez (4xx e terminal na esteira de saida — `OutboundDispatcher` classifica 400-499 como Terminal —, entao 2 aqui significa retry indevido) e o `systemhope-get-order` NAO acontece (buscar o pedido reatribuido depois de uma recusa criaria o pedido da loja nova para uma troca que nao houve). O reparo — janela reaberta pelo ator, pedido de volta a vitrine — nao passa pelo parceiro e por isso nao aparece no call-log: confira em ChangeSellerOrder (ReassignFailedAt preenchido) ou na tela.