# SPEC — Entrada por Canais Digitais

| Campo | Valor |
|-------|--------|
| **Produto** | Pizza Digital |
| **Capítulo** | SPEC §5.5 · RF-CAN · Track C |
| **Versão** | 0.3.0 |
| **Data** | 2026-10-19 |
| **Owner** | Roger / iTecnologys |
| **Referência UX** | CityFoods Cardápio Digital + quadro Pedidos |
| **Cardápio (catálogo)** | [`SPEC-CARDAPIO.md`](SPEC-CARDAPIO.md) |
| **Estoque** | [`SPEC-ESTOQUE.md`](SPEC-ESTOQUE.md) — disponibilidade no PWA |

---

## 1. Objetivo

Fazer o cliente pedir **sem passar pelo balcão**, e a loja ver o pedido no mesmo quadro operacional (`/pedidos`) que já usa para PDV/KDS.

**Promessa:** menos telefone · menos erro de digitação · mais ticket digital · mesma cozinha.

---

## 2. Modelo de dados (alvo)

### 2.1 Dimensões

```ts
origin:      "pdv" | "cardapio" | "ifood" | "whatsapp" | "telefone"
fulfillment: "entrega" | "retirada" | "mesa"
```

### 2.2 Migração do `channel` atual

| Legado `channel` | `origin` | `fulfillment` |
|------------------|----------|---------------|
| `delivery` | `pdv` | `entrega` |
| `balcao` | `pdv` | `retirada` |
| `pdv` | `pdv` | `mesa` |

Novos pedidos digitais: `origin=cardapio` (ou `ifood`) + fulfillment escolhido pelo cliente.

---

## 3. Track C — sprints

| ID | Entrega | Dependência |
|----|---------|-------------|
| **C1.1** | Rotas públicas `/c/:slug` (cardápio PWA) | Menu API + loja aberta/fechada |
| **C1.2** | Carrinho + checkout (entrega/retirada, bairro, taxa) | Áreas de entrega |
| **C1.3** | Pagamento: Pix (stub/real) + “pagar na entrega” | Gateway Pix |
| **C1.4** | Create Order `origin=cardapio` → WS → `/pedidos` | Schema origin/fulfillment |
| **C1.5** | Badge origem + som no board | UI `/pedidos` |
| **C1.6** | Deep-link WhatsApp (`wa.me` → `/c/:slug`) | C1.1 |
| **C1.7** | API inbound WhatsApp (`POST /api/inbound/whatsapp`) | ✅ v0.1 — ver [`API-WHATSAPP-INBOUND.md`](API-WHATSAPP-INBOUND.md) |
| **C2.1** | Adaptador iFood (webhook + assinatura) | Conta loja iFood |
| **C2.2** | Normalizador iFood → Order + idempotência | C1.4 |

**Gate:** C1 só começa com S3 estável; idealmente após S5 (piloto). Pode prototipar C1.1 em paralelo.

---

## 4. Fluxo C1 — cardápio digital

```text
Cliente abre /c/pizza-digital-piloto
  → vê cardápio (categorias / pizzas / bebidas)
  → monta carrinho (meia-a-meia / borda / obs)
  → escolhe Entrega ou Retirada
  → se Entrega: bairro + endereço + taxa
  → pagamento (Pix ou na entrega)
  → POST /api/orders { origin: "cardapio", fulfillment, items, ... }
  → loja: card novo em /pedidos (ENTREGA/RETIRADA + badge CARDÁPIO)
  → KDS recebe como qualquer pedido
```

---

## 5. UX quadro `/pedidos` (já no ar)

| Elemento CityFoods | Nosso |
|--------------------|--------|
| Faixa ENTREGA / RETIRADA | `fulfillment` |
| Tags de sabor | components + notes |
| Preparo tardio | SLA > 20 min |
| Histórico | pedidos recentes |
| **Novo:** badge origem | APLICATIVO / IFOOD / PDV / WHATSAPP |

---

## 6. Fora de escopo (C1)

- App nativo iOS/Android consumidor
- Marketplace multi-loja Pizza Digital
- Fidelidade / cashback (fase posterior)
- Chat in-app com a loja

---

## 7. Critérios de aceite C1

1. Cliente finaliza pedido no cardápio sem login de staff.
2. Pedido aparece no `/pedidos` em ≤ 500 ms (WS) com badge **CARDÁPIO**.
3. KDS processa igual a pedido PDV.
4. Etiqueta mostra origem + fulfillment.
5. Loja fechada → cardápio bloqueia checkout com mensagem clara.

---

## 8. Próximo passo de implementação

1. ~~Migrar modelo `origin` + `fulfillment` (API + UI badges).~~ ✅ Central `/pedidos` + `POST /api/orders/demo-digital`
2. Scaffold PWA `/c/:slug`.
3. Ligar create order cardápio público → board (já validável via fixture).