Admin
e3da540b6e
Each PRD documents real UI/API processes, service methods, states and gaps. Co-authored-by: Cursor <cursoragent@cursor.com>
65 lines
2.4 KiB
Markdown
65 lines
2.4 KiB
Markdown
# PRD — Entrada por Canais Digitais
|
||
|
||
| Campo | Valor |
|
||
|-------|--------|
|
||
| **Produto** | Pizza Digital |
|
||
| **Versão app auditada** | v0.5.0 |
|
||
| **Ambiente** | https://pizza.itecnologys.com · VM125 · loja `pizza-digital-piloto` |
|
||
| **Spec de origem** | `docs/SPEC-CANAIS-DIGITAIS.md` |
|
||
| **Módulo** | Ingestão multi-canal → quadro único /pedidos |
|
||
| **Rotas UI** | `/pedidos` · inbound WhatsApp |
|
||
| **APIs** | `POST /api/inbound/whatsapp` · `POST /api/orders/demo-digital` · Meta webhook |
|
||
| **Data** | 2026-11-09 |
|
||
| **Estilo** | PRD operacional detalhado (visão de desenvolvedor) |
|
||
| **Audiência** | Dev / QA / Product |
|
||
|
||
> Como ler: cada seção descreve o **processo real** (o que o sistema faz hoje),
|
||
> com passos de usuário, chamadas de API, regras de negócio e estados.
|
||
> Status: ✅ construído · ⚠️ parcial · ⏳ especificado / não entregue · 🐛 gap observado.
|
||
|
||
|
||
## 1. Problema que o código resolve
|
||
|
||
Pedidos chegam de PDV, WhatsApp, telefone, app. Sem quadro único, a cozinha quebra.
|
||
A Spec define **origin × fulfillment** e Track C.
|
||
|
||
## 2. Modelo
|
||
- `Order.origin`: pdv | cardapio(aplicativo) | whatsapp | telefone | ifood(futuro)
|
||
- `Order.fulfillment`: entrega | retirada | mesa
|
||
- Idempotência inbound: `Order.inboundKey`
|
||
|
||
## 3. Processo — pedido WhatsApp (construído)
|
||
|
||
1. Bot/n8n/Make chama `POST /api/inbound/whatsapp` com header `X-Api-Key`.
|
||
2. Guard `InboundApiKeyGuard` valida `INBOUND_API_KEY`.
|
||
3. Service normaliza payload → cria Order `origin=whatsapp`.
|
||
4. Se `inboundKey` repetido → não duplica.
|
||
5. Pedido aparece em `/pedidos` com badge WhatsApp.
|
||
6. Meta: `GET/POST /api/inbound/whatsapp/meta` (verify token + webhook).
|
||
|
||
## 4. Processo — demo canal digital
|
||
1. Operador/dev chama `POST /api/orders/demo-digital`.
|
||
2. Gera pedido sintético para validar UI Central (filtros/som/badges).
|
||
|
||
## 5. Processo — Central (operador)
|
||
1. Abre `/pedidos`.
|
||
2. Filtra por origin/fulfillment.
|
||
3. Ouve Socket para novos pedidos.
|
||
4. Encaminha mentalmente à cozinha (já ticketado no create).
|
||
|
||
## 6. Aceite / gaps
|
||
- ✅ Inbound WhatsApp + demo digital + badges Central
|
||
- ⏳ PWA cardápio público Track C1
|
||
- ⏳ iFood Track C2
|
||
- ⚠️ SMTP/notificações reais
|
||
|
||
|
||
## 7. Camada inbound (WhatsappService)
|
||
|
||
| Método | Fluxo |
|
||
|--------|-------|
|
||
| `createOrder` | Payload API key → Order whatsapp |
|
||
| `fromMetaText` | Webhook Meta texto → parse |
|
||
| `resolveItems` | Mapeia texto/IDs para MenuItem |
|
||
|
||
Guard: `InboundApiKeyGuard` em `POST /api/inbound/whatsapp`.
|