Admin d669f56398 Import Pizza Digital SPECs and docs from Obsidian vault sync

Co-authored-by: Cursor <cursoragent@cursor.com>

2026-11-09 19:52:34 +00:00

3.7 KiB

Raw Permalink Blame History

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`
Estoque	`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

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`
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

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

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

8. Próximo passo de implementação

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

3.7 KiB Raw Permalink Blame History