obsidian-vault/Pizza-Digital/docs/SPEC-CANAIS-DIGITAIS.md
Roger 62a20a2573 Add Pizza-Digital docs to Obsidian vault and sync with VM125.
Mirror all SPECs and construction docs from pizza-digital, add hub/sidebar links and bidirectional sync scripts.
2026-11-09 19:45:11 +00:00

114 lines
3.7 KiB
Markdown

# 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).