6. Visão de execução

Cenário 1: login e chamada autenticada à API

sequenceDiagram
    autonumber
    actor U as Profissional
    participant W as web (Next.js)<br/>Better Auth
    participant DB as PostgreSQL
    participant A as order-lifecycle
    participant R as Redis

    U->>W: POST /api/auth/sign-in/email
    W->>DB: valida credenciais, cria Session
    W-->>U: Set-Cookie moldape.session_token<br/>(domínio .moldape.com, 30 dias)
    U->>A: GET /api/v2/me/drafts (cookie enviado, withCredentials)
    A->>R: sessão em cache?
    alt cache miss
      A->>DB: busca Session + User pelo token
      A->>R: grava sessão em cache
    end
    A-->>U: 200 lista de rascunhos

O cookie é emitido com crossSubDomainCookies no domínio moldape.com, por isso api.moldape.com o recebe. O Fastify não confia em JWT: valida o token de sessão direto no banco (com fallback para o endpoint do Better Auth). O jsonwebtoken só é usado para tipar e tratar erros no middleware.

Cenário 2: criação no estúdio com salvamento automático

sequenceDiagram
    autonumber
    actor U as Profissional
    participant S as Estúdio (Konva)
    participant A as order-lifecycle
    participant V as Volume /uploads

    U->>S: envia plantigrafia (A4, ≤ 5 MB)
    S->>A: POST /api/v2/upload/plantigraphy (multipart ou chunked)
    A->>V: grava arquivo (PDF convertido em imagem)
    A-->>S: URL do arquivo
    S->>A: PATCH /drafts/:id/plantigraphy/:side
    U->>S: escolhe produto / peças / cobertura
    S->>A: POST /drafts/:id/product · /pieces · /coverage
    loop a cada alteração (debounce)
      S->>A: PATCH /drafts/:id/vector-state
      S->>A: PUT /drafts/:id/creation-images (PNG exportado do canvas)
    end

Cenário 3: checkout e confirmação de pagamento

sequenceDiagram
    autonumber
    actor U as Profissional
    participant W as web
    participant A as order-lifecycle
    participant P as InfinitePay
    participant M as SMTP

    U->>W: Prosseguir para Pagamento
    W->>A: POST /carts/:id/convert-to-order
    A-->>W: Order (PENDING)
    W->>A: POST /payments/create-payment-link<br/>{handle, items (centavos), order_nsu=orderId-cartId,<br/>redirect_url, webhook_url}
    A->>P: POST /invoices/public/checkout/links
    P-->>A: { url }
    A-->>W: url
    W-->>U: redireciona para o checkout
    U->>P: paga (Pix / cartão)
    P->>W: POST /api/webhook {order_nsu, paid_amount, …}
    W->>A: PATCH /orders/:id/status {PAID, cartId}<br/>cookie de serviço (PAYMENT_BYPASS_TOKEN)
    A->>A: gera PDFs (pedido, etiqueta, plantigrafias)
    A->>M: e-mail de confirmação com links
    P-->>U: redirect_url → /home/paymentSucceeded/:orderId
    loop a cada 3 s até PAID
      U->>A: GET /orders/:id
    end

Risco crítico neste fluxo

O webhook não verifica autenticidade (assinatura, origem ou consulta ao gateway) nem compara paid_amount com o total do pedido. Ver R-01 em Riscos.

Cenário 4: administrador atualiza o status do pedido

sequenceDiagram
    autonumber
    actor F as Fábrica (admin)
    participant W as web /admin/orders
    participant A as order-lifecycle
    participant M as SMTP

    F->>W: Alterar Status
    W->>A: PATCH /orders/:id/status (requireAdmin)
    alt novo status = PAID
      A->>A: gera e salva PDFs
      A->>M: confirmação do pedido
    else novo status = READY
      Note over W,A: exige PATCH /orders/:id/shipping<br/>(rastreio ou retirada)
      A->>M: pedido pronto
    else demais status
      A->>M: atualização de status
    end