# Entrega e aprovação ## Entrega & Aprovação ### Contexto Uma vez que um pedido é **financiado**, o marketplace entra na **fase de execução**. Neste ponto: * os fundos ficam presos em escrow, * o vendedor pode entregar com segurança, * o comprador sabe que o pagamento está garantido, * a plataforma aplica o processo. Este fluxo se aplica a **tanto bens quanto serviços**. *** ### Objetivo Permitir que o vendedor: * forneça atualizações de entrega, * marque o pedido como concluído, e permitir que o comprador: * aprove a entrega **ou** * abra uma disputa, com desfechos aplicados pelo escrow. *** ### Atores * **Vendedor** * **Comprador** * **UI do OfferHub** * **Backend do OfferHub (Orquestrador)** * **Supabase** (perfis & papéis) * **Escrow Trustless Work** * **Rede Stellar** *** ### Pré-condições * O pedido existe e está em **Financiado / Em Progresso** * Escrow existe e está totalmente financiado * Vendedor e comprador estão vinculados ao pedido * Papéis no escrow já estão atribuídos: * Vendedor = Marcador de Marco (Milestone Marker) * Comprador = Aprovador * Plataforma = Resolutor de Disputas & Assinante de Liberação *** ### Alinhamento do Ciclo de Vida Este fluxo move o pedido e o escrow através destes estados: ``` Em Progresso → Para Revisão (Entrega Concluída) → Aprovado OU Disputado → Liberado OU Reembolsado ``` *** ### Experiência do Vendedor — Fase de Entrega #### 1. Vendedor é Notificado ``` Escrow financiado → Vendedor notificado ``` O vendedor agora pode começar o cumprimento. *** #### 2. Vendedor Fornece Atualizações de Entrega (Off-Chain) O vendedor tem acesso a um **painel do vendedor** onde ele pode: * atualizar o status do pedido (ex.: “processando”, “enviado”) * fazer upload de evidências (número de rastreamento, arquivos, notas) * comunicar-se com o comprador Essas atualizações são: * **off-chain** * **informacionais** * **não aplicadas pelo escrow** Elas existem para apoiar a UX e a resolução de disputas posteriormente. *** #### 3. Vendedor Marca a Entrega como Concluída (Sinal On-Chain) Quando a entrega estiver completa: ``` Vendedor → UI do OfferHub: Marcar como Entregue OfferHub → Trustless Work: Marcar marco como Concluído ``` Esta ação: * move o escrow para **Para Revisão** * sinaliza que o vendedor declara conclusão * **não libera fundos** Neste ponto: * o vendedor não pode mais alterar o status da entrega * é necessária uma ação do comprador *** ### Experiência do Comprador — Fase de Revisão #### 4. Comprador Revisa o Pedido O comprador vê: * status da entrega * atualizações e evidências do vendedor * linha do tempo do pedido O comprador deve escolher **uma das duas ações**. *** ### Caminho A — Comprador Aprova a Entrega #### Experiência do Usuário > “Tudo parece certo.” *** #### Fluxo do Sistema ``` Comprador → UI do OfferHub: Aprovar OfferHub → Trustless Work: Aprovar marco ``` Isto move o escrow para **Aprovado**. ⚠️ **Requisito de Assinatura (Importante)**\ Esta aprovação **exige uma assinatura** vinculada ao papel de Aprovador. O que assina esta aprovação depende do modelo final de integração: * **Opção 1 (UX Preferida):** * Aprovação do comprador é autorizada via OfferHub * A plataforma assina on-chain como autoridade delegada * **Opção 2 (A ser validada com a Airtm):** * A conta do comprador vinculada à Airtm pode autorizar/assinar a aprovação do escrow * Isso exigiria suporte da Airtm para assinatura ou assinatura delegada 👉 **Este é um ponto-chave de exploração no piloto com a Airtm.** *** ### Caminho B — Comprador Abre uma Disputa #### Experiência do Usuário > “Algo está errado.” *** #### Fluxo do Sistema ``` Comprador → UI do OfferHub: Abrir Disputa OfferHub → Trustless Work: Marcar escrow como Disputado ``` Isto: * congela o escrow * impede a liberação * entrega o controle à plataforma (resolutor de disputas) A partir daqui, o **Disputas & Resolução** fluxo se aplica. *** ### O Que Acontece Em Seguido #### Se Aprovado * Escrow está pronto para liberação * A plataforma executa a liberação dos fundos * O vendedor recebe o pagamento #### Se Disputado * Escrow permanece bloqueado * A plataforma investiga e resolve * O resultado é aplicado on-chain *** ### Saídas * ✅ Entrega marcada como concluída * ✅ Escrow movido para **Para Revisão** * ✅ Ação do comprador registrada (aprovar ou disputar) * ✅ Trilha de auditoria completa (off-chain + on-chain) *** ### Falhas & Casos Limítrofes #### Vendedor Marca Entrega Cedo Demais * Comprador pode disputar * Evidências são revisadas * Nenhuma liberação automática ocorre #### Comprador Está Inativo * Escrow permanece em **Para Revisão** * Sem liberação automática baseada em tempo por padrão * A plataforma pode intervir manualmente (decisão de política) *** ### Notas de Segurança & Confiança * Vendedor **não pode liberar fundos** * Comprador **não pode liberar fundos por si só** * Plataforma **não pode liberar fundos a menos que as condições sejam atendidas** * O escrow aplica as transições de estado *** ### Notas Educacionais #### Por que as Atualizações de Entrega são Off-Chain * Flexível * Amigável à UX * Evita gravações on-chain desnecessárias * Ainda utilizável como evidência em disputas #### Por que a Aprovação Exige Assinatura A aprovação é o **gatilho econômico** para a liberação.\ Deve ser autorizada criptograficamente, não apenas um clique na interface. *** ### Perguntas em Aberto (Validação do Piloto) O piloto do Offer Hub irá explorar explicitamente: 1. **Contas Airtm podem participar dos fluxos de assinatura do escrow?** 2. **A Airtm pode suportar assinatura delegada ou por procuração?** 3. **As aprovações devem sempre ser assinadas pela plataforma para simplicidade de UX?** Essas decisões afetam: * pressupostos de confiança * atrito de UX * limites de conformidade --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.trustlesswork.com/trustless-work/v1-pt/dapps-oss/offerhub-marketplace/fluxos-principais/entrega-e-aprovacao.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.