ChatDelivery PDV — Linha de progresso

Linha de progresso

Agora

A roteirização ficou de pé — o mapa mostra as entregas, tu escolhe quais saem juntas, e a rota já tem dono

333 testes verdes suíte roda em banco SEPARADO de prod ✓ 2.6.1 O TATO ✓ · review adversarial passou no ar · pdv.chatdelivery.cloud no ar · sandbox.chatdelivery.cloud

Onde estamos — Passo 2 · o PDV

Fechado ✓ 2.1 Login e permissões ✓ 2.2 Board de pedidos ✓ 2.3 Cardápio ✓ 2.4 Impressão ✓ 2.6 Marca ✓ 2.6.1 O tato

Em andamento ◐ 2.6.5 Impressão v2 VOCÊ ESTÁ AQUI ✓ endereço ✓ fila que sobrevive a deploy ✓ térmica de rede ✓ áreas — servidor ✓ áreas — tela ○ app da loja honrar o alvo ○ vias ○ comanda montada no servidor ○ blocos

Em andamento ◐ 2.6.4 Acabamento (vocabulário comum, tela por tela) ◐ Passo 3 Roteirização CONSTRUÍDA — falta despachar

Depois ○ 2.6.2 Arrastar em todas as colunas ○ 2.6.3 Som repete até aceitar ○ 2.7 O card mostra o que já sabe ○ Entregadores · Relatórios · Balcão

Roteirização: do mapa até o entregador com nome (20/07). A tela abre já com as entregas plotadas — tu marca na lista ou clica no pino, e a ordem de visita sai calculada da loja. O link do Google Maps já vai com as paradas na ordem, então a navegação é dele e a decisão é nossa. No fim, quem leva: um seletor com os entregadores cadastrados. Está no sandbox, não em produção.
Não precisa mais escolher marca pra despachar — era o que quebrava a promessa do painel (tu comanda todas as tuas lojas de um lugar só). Agora o ponto de partida sai dos próprios pedidos; se eles saírem de cozinhas diferentes, o sistema avisa em vez de inventar uma origem. O seletor de marca saiu do menu inteiro — ficou só dentro do Cardápio, onde a pergunta faz sentido.
Duas contas que eu ia errar, e a medição corrigiu. (1) O plano pedia um algoritmo aproximado; medindo 40.929 saídas reais, 96% têm até 5 paradas — então dá pra testar todas as ordens possíveis e acertar sempre. O aproximado erraria mais de 400 m em 34% dos casos, até 4,2 km nos piores: mais código e pior. (2) A distância que a gente calcula é em linha reta, e em Belém a baía faz ela mentir muito — deu 2,9 km contra 5,5 km pela rua no Google. A tela agora diz isso na cara, porque o número seco te faria decidir com metade do valor real.
⚠️ E aí eu quebrei a operação do Lucas — com um "conserto". Pra fechar o buraco da mistura de cozinhas eu passei a bloquear rota com marca sem endereço cadastrado. Só que 12 marcas dividem a mesma cozinha lá, e marca nova nasce sem endereço: eu tinha travado o dia a dia. Pior, a régua era chute — eu tinha escrito no próprio código que a variação de GPS entre marcas do mesmo endereço seria "alguns metros" e cravei 300 m. Fui medir depois da reclamação: duas marcas com o mesmo endereço cadastrado registraram coordenadas 696 m distantes. Agora a régua é o endereço escrito, não o GPS — e marca sem cadastro não bloqueia mais, só avisa. A lição: fechar a porta só vale quando o caminho fechado é exceção; quando é a operação do cliente, é só quebrar mais alto.
Uma coisa que é fácil assumir errado, então está escrito: montar rota e escolher o motoboy não despacha nada. O pedido continua "Em preparo" e quem despacha ainda é o botão do board, pedido por pedido. O desenho que a gente quer — o entregador escaneando o QR da comanda e se auto-despachando pelo app dele — depende de duas coisas que ainda não existem: o app do entregador e o bloco do QR no papel (que entra na fase de Impressão).
Botei a roteirização inteira sob ataque antes de te entregar — e ela tinha 8 buracos (21/07). Uma revisão adversarial com 85 revisores independentes, cada achado passando por três céticos que tentavam derrubá-lo. O pior: a rota misturava duas cozinhas em silêncio. Se uma marca ainda não tem o endereço cadastrado — e marca nova nasce assim — ela era simplesmente ignorada, a trava não disparava, e saía uma rota plausível: o motoboy ia num endereço cuja comanda tinha impresso na outra cozinha. Sem erro, sem nada estranho na tela, e repetindo toda vez. Ninguém ia ligar "entregas perdidas" com "falta cadastrar o endereço de uma marca".
O resto era a tela mentindo sobre o estado real. Pedido cancelado pelo cliente continuava como parada viva da rota, com o endereço dele dentro do link do Google Maps — 20 minutos de moto até uma porta que não tinha mais pedido. Cancelar uma rota deixava o painel dela vivo, com o nome do motoboy e o botão do Maps funcionando. E a lista de pedidos era uma foto do momento em que tu abria a tela: pedido que ficasse pronto depois nunca aparecia — atraso sem explicação nenhuma. Tudo isso agora tem teste que fica vermelho se alguém desfizer.
Uma coisa que tu me contou mudou a engenharia. Quando expliquei o risco de dois despachantes montarem a mesma rota ao mesmo tempo, tu explicou que na prática isso não acontece porque o entregador só despacha a comanda que está na mão dele — o papel é o cadeado, não o software. Isso rebaixou três dos oito achados de "bloqueador" pra "dívida técnica", e me fez priorizar diferente. É o tipo de coisa que não se descobre lendo código.
Três regras tuas entraram (20/07). (1) Só pedido "Em preparo" pode virar rota — o que ainda está em "Recebido" a loja pode recusar, e montar rota com ele seria montar uma rota que não pode sair; o beco só apareceria na hora de despachar, com o motoboy já esperando no balcão. A tela conta quantos ficaram de fora, senão "cadê o #0001?" vira caça a bug. (2) Quem leva aparece no card do board — e são dois selos diferentes, porque "em rota, sem motoboy" não é a mesma coisa que "o Jorge está com ele". (3) Aba "Montadas": as rotas que já existem, com o mapa da rota escolhida, trocar o motoboy, abrir no Maps e cancelar. Antes disso a rota sumia quando tu trocava de aba, e a única prova de que existia era a trava reclamando — saber pelo erro.
E um beco sem saída que só apareceu clicando. A trava avisava "já existe rota pra esses pedidos, cancele a outra antes" — e não existia botão pra cancelar rota em lugar nenhum. O aviso mandava fazer algo impossível. Agora o próprio aviso traz "Cancelar a rota anterior e montar esta". Nenhum teste tinha pegado isso: eles provam que a trava funciona, não que dá pra sair dela.
Uma trava que vale a entrega: o mesmo pedido não entra em duas rotas. Dois motoboys com a mesma entrega significa entregue duas vezes — ou nenhuma, cada um achando que o outro leva. E atribuir não é despachar: dizer quem leva não avisa o iFood nem faz o cliente ver "a caminho", porque o pedido ainda está no balcão esperando o motoboy chegar.
As ÁREAS ficaram prontas — servidor E tela (19/07). A loja agora cria o lugar de verdade ("Chapa", "Bebidas", "Cozinha do fundo") em vez de escolher um nome de fila do Windows, que ela não tem por que conhecer. É o que o Saipos não deixa: ele dá 9 abas FIXAS e o lojista se vira dentro delas. Apagar área que está em uso pergunta pra onde vão as marcas — e só oferece área que tem impressora, senão a comanda ficaria órfã pelo próprio caminho da guarda.
E apareceu um cano cortado no meio: o endereço da impressora era gravado no banco e morria antes de chegar no aparelho da loja — ou seja, configurar não produzia papel em lugar nenhum. Consertado nos dois caminhos (envio na hora e reenvio quando o aparelho reconecta). Falta a outra metade, que é o app instalado no PC obedecer — isso exige instalador novo.
Fechou a fase da MARCA inteira (2.6 · W0 a W4). O board mostra o selo da marca em cada card e deixa filtrar — mas segue sempre integrado, todas as marcas juntas na ordem de urgência, como tu cravaste. O cardápio agora é o da marca escolhida. E a comanda de cada marca sai na impressora da cozinha dela — é isso que aposenta o Saipos+Yooga.
O plano estava errado em dois pontos na impressão — e os dois falhariam calados, com a comanda saindo na cozinha errada e ninguém sabendo por quê. Achei rodando contra banco de verdade antes de escrever a wave. Corrigido, e o teste foi validado invertendo a lógica de propósito pra provar que ele sabe falhar. Prova final no fio: liguei um agente de impressão e vi #0001 (Açaí) → COZINHA-1 e #0002 (Burger) → COZINHA-2.
Marca sem impressora própria imprime na Padrão e a tela avisa com um selo — decisão tua, pra não descobrir pelo papel. Loja de uma marca só não muda nada: mesma tela de antes.
Fase 2.6.5 (Impressão v2) começou — e um ataque adversarial reordenou ela antes da primeira linha. O plano ia começar pelas áreas; nasceria quebrado, porque no modo térmico o agente não reporta impressora nenhuma — a tela abriria sem nada pra escolher. A térmica virou pré-requisito. Já de pé (construído, ainda não provado no papel): endereço no sandbox, fila de impressão persistida — antes disso todo deploy comia as comandas pendentes, calado — e a térmica de rede roteável. Falta: áreas, vias, render no servidor, blocos.
Dois buracos fechados antes de seguir — os dois achados investigando a 2.6.5, nenhum dos dois era o que eu fui procurar. (1) A suíte de testes rodava contra o banco de produção: o arquivo de config aponta pro mesmo Postgres da API no ar, e os testes apagam dados — um comando distraído levava dado real junto, sem avisar. Agora tem banco separado e uma trava que aborta se não for o de teste. (2) O localizador do iFood — o número de 8 dígitos que o entregador usa pra confirmar a entrega, e que expira — era guardado por pessoa, não por pedido: cliente que pedia de novo apagava o localizador do pedido anterior. É justamente o que a via de despacho vai imprimir.
E a boa notícia dentro da má: medi antes de mexer — o banco de produção nunca recebeu um pedido, então nada foi perdido nesses dois casos. Era bomba armada, não bomba estourada. Alarme falso que eu mesmo levantei e derrubei: achei que o webhook do iFood estivesse engolindo pedido em produção; investiguei e não é — são batimentos de presença a cada 30s, e responder sem gravar é o comportamento certo, exigido pela doc.

Pendência sua: revisar #38 (a roteirização inteira — mapa, rota, entregador). Nada disso está em produção; roda no sandbox pra tu clicar. Decisões abertas do Passo 3: despachar a rota (avisar o iFood) é o próximo momento · quem opera — despachante ou o próprio entregador com QR · distância pela rua de verdade em vez de linha reta.

As telas que já existem

Capturadas do ambiente de testes, com dados de demonstração — nenhum dado de cliente real aparece aqui. É o que está construído e funcionando hoje.

Tela: Entrar — **Entrar**A porta do sistema. Foto que muda por dia, tema seguindo o do computador.

Tela: Pedidos — **Pedidos**O quadro da operação: cada pedido é um card que anda entre as colunas. É a tela que fica aberta o dia inteiro.

Tela: Roteirização — **Roteirização**As entregas no mapa. Marca quais saem juntas, o sistema calcula a ordem e diz quem leva.

Tela: Entregadores — **Entregadores**Quem pode receber uma rota. O telefone é por onde a rota chega.

Tela: Cardápio — **Cardápio**O cardápio da marca escolhida, espelhado do iFood.

Tela: Impressoras — **Impressoras**Para onde cada comanda vai — é o que faz a marca certa imprimir na cozinha certa.

🖼 A tela de login — o “aperto de mão” do produto (20/07)

Primeira superfície repaginada por inteiro. O desenho não é palpite: 14 telas de login de PDV foram abertas e fotografadas (Saipos, Tatu, Consumer, Goomer, Anota AI, Cardápio Web, Toast, Deliverect, Otter, Lightspeed, iFood…). Tela dividida = 8/14 (forma dominante) · tema claro = 14/14 · campo sobre imagem = 0/14 · foto humana = 3/14, e uma delas é o iFood — o software que todo lojista de delivery abre todo dia.

Tela de login do Hubly: foto de entregador à esquerda, formulário à direita com botão roxo — No ar em **sandbox.chatdelivery.cloud/login** · PRs #36 (mergeado) e #37. **6 fotos, uma por dia**, iguais nos dois temas — o tema espelha o sistema do lojista, não escolhe a imagem. Todas com licença comercial verificada e sem rosto identificável.

A mesma tela de login no tema escuro: o roxo clareia e o texto do botão fica escuro — **A mesma tela no tema ESCURO.** Não é a versão clara invertida: o roxo da marca clareia pra `#b887e8` e o texto do botão passa a ser escuro — contraste medido em **6,76:1**, contra os 14,86:1 do claro. A foto do dia é a mesma nos dois; o tema espelha o sistema do lojista e não escolhe a imagem.

A marca virou roxa em TODAS as telas — 13 tokens no globals.css e mais nada, porque nenhum componente usa cor crua. É o retorno da fundação visual da 2.6.0. Contraste medido antes de trocar: 7,10:1 no claro (o petróleo dava 6,19:1 — melhorou), 6,80:1 no escuro.
O nome Hubly vale só nesta rota por enquanto. O menu lateral segue ChatDelivery PDV até o nome ser fechado.
Movimento portado do protótipo: Ken Burns na foto, entrada em sequência, rótulo flutuante nos campos, spinner no botão, shake no erro — tudo desligado sob prefers-reduced-motion.
3 bugs que passariam batido e só apareceram ao OLHAR a tela: o output: standalone do Next não empacota public/ (build verde, página 200, as 6 fotos em 404) · animação sem @keyframes compila e não anima · e o animate-in sobrescrevia o Ken Burns no mesmo elemento.
Campos no modelo da Nina (referência do Lucas): rótulo fixo em cima + ícone dentro. O nome do campo não se mexe, então não existe estado em que ele esteja pequeno e apagado. Entram “Lembrar de mim” (funcionando: estende a sessão de 12h pra 30 dias) e os dois caminhos de ajuda apontando pro WhatsApp do admin.
O tema segue o sistema operacional do lojista. Estava com enableSystem={false} — o app ignorava a preferência do SO e quem usava escuro abria no claro toda vez. Achado pelo Lucas usando o sandbox.
Nenhuma linha de lógica mudou: os 5 ramos de erro por faixa de status, o routeAfterAuth e os autoComplete continuam idênticos.

🧭 Anatomia do PDV — esqueleto do MVP (o que falta pra ser vendável)

Cruzando o menu real do Saipos (PDV homologado, capturado ao vivo) com pesquisa de 108 abas · 92 fontes · 12 vendors. 6 abas primárias, a complexidade escondida em Configurações, o resto sinalizado "em breve". Decidido 13/07.

Temos Parcial Falta Reaproveita stack Nina

ChatDelivery

🧾Pedidosboard vivo + KDSTemos

🍧Cardápioitens · complementos · por-pesoFalta

🛵Entregadorescadastro ✓ · atribuir ✓ · despacho · acertoParcial

📊Relatóriosnúcleo de 8Falta

🧮Venda (PDV)balcão · tigela · pesoParcial

⚙️ Configurações ▾

Loja / EquipeParcial

Horário de funcionamentoabre/fecha · feriados (A4)Falta

Impressorasapp de bandeja + pareamentoProvado

Taxas de entregaFalta

PagamentoFalta

Integrações (iFood)Reaproveita

Usuários & permissõesParcial

Em breve — visíveis, desabilitados

Financeiro Estoque / CMV → link Clientes / CRM Fiscal (NFC-e)

Cardápio

Sem ele nada vende — destrava o PDV e o cardápio digital. Diferencial barato: import/export CSV (dor real de quem usa Saipos).

∥

Spike de Impressão paralelo maior risco

✅ PROVADO NO PAPEL (14/07): o lojista instala por duplo-clique, pareia com um código de 6 dígitos, escolhe a impressora no PDV e o pedido aceito sai na impressora. App de bandeja (Electron), sobe no boot, zero terminal. Falta o roteamento por marca (as 2 cozinhas).

Entregadores reaproveita

Cadastro + despacho + acerto, puxando rota-ativa e acerto de motoboy que já existem no stack Nina.

Veredito honesto: o módulo mais caro (Pedidos + KDS) já está de pé. Mas "minimamente vendável" ainda trava em 3 bloqueantes greenfield — Cardápio, Impressão e Entregadores. Nenhum finge; Impressão é o único que depende de hardware no cliente.

🟢 Must-haveo núcleo

Pedidos / Board + KDScoração operacional, multicanalTemos
Cardápioitens · categorias · disponibilidade1º a fazer
Complementos / Adicionaisonde o pedido de açaí aconteceFalta
Produtos por-pesoaçaí = 500ml/1L (decidido 13/07); por-grama é expansão de mercado, não bloqueia o LucasDívida consciente
Cardápio digital própriolink + QR · anti-comissãoFalta
Integrações (iFood)âncora de marketplaceReaproveita
Taxas de entregabairro/raio · cobrado ≠ pagoFalta
Formas de pagamento+ fechamento de caixaFalta
Entregadorescadastro · despacho · acertoParte no stack
Impressãoapp de bandeja · comanda no papel ✓Pronto
Relatóriosnúcleo de 8Falta
PDV / Balcãotigela · peso · trocoParcial
Loja / Config / Equipesetup + integraçõesParcial

🟡 Nice-to-haveagrega, não bloqueia

Estoque / Insumos + CMVjá é módulo separado no arTemos → link
Clientes / CRM / Fidelidaderetenção de açaí de bairroDepois
Cupons / Marketingalavanca de conversão barataDepois
Conciliação de repassescartão · marketplacesDepois
Agendamento de pedidoshorário futuroDepois
Fiscal (NFC-e)obrigatório, mas MEI começa semDeferido / stub

🔴 Futurofora do delivery-first

Mesas / Salão / Garçomsó se abrir consumo no local
Totem / Autoatendimentoloja física de fluxo
Roteirização + GPSno Saipos é módulo PAGO à parte
Financeiro completo / DRErestaurante médio/grande
Bot / Atendente WhatsAppé a Nina — ativo nosso, não "PDV mínimo"É nosso

🖨 Impressoras — configuração mockup · conceito

Uma PDV só, 12 marcas, 2 cozinhas — cada marca aponta pra sua impressora.

Hoje vocês usam Saipos + Yooga ao mesmo tempo só pra conseguir separar a impressão das comandas dessas 12 marcas nas 2 cozinhas (o Saipos não deixa separar dentro do sistema). Aqui isso é nativo: todas as marcas ficam na mesma loja do PDV e cada uma tem sua impressora setada.

Dispositivos conectados

Cozinha 1

Térmica · Epson TM-T20 (80mm)

Online

tcp://192.168.0.50:9100 · última comanda há 2 min

Cozinha 2

Térmica · Epson TM-T20 (80mm)

Online

tcp://192.168.0.51:9100 · última comanda há 5 min

Escritório

A4 · Epson L4260 (fila Windows)

Online

EPSON L4260 Series · bancada de teste

Balcão

Térmica · Elgin i9 (80mm)

Offline

tcp://192.168.0.52:9100 · reconectando…

Roteamento — marca → impressora

Marca	Cozinha	Impressora
Raiz Açaí	Cozinha 1 · Saipos	Térmica Cozinha 1 ▾
Cia do Peixe	Cozinha 1 · Saipos	Térmica Cozinha 1 ▾
Dom Marmita	Cozinha 1 · Saipos	Térmica Cozinha 1 ▾
Cia da Marmita	Cozinha 1 · Saipos	Térmica Cozinha 1 ▾
N1 Chicken	Cozinha 2 · Yooga	Térmica Cozinha 2 ▾
N1 Burguers	Cozinha 2 · Yooga	Térmica Cozinha 2 ▾
N1 Bites	Cozinha 2 · Yooga	Térmica Cozinha 2 ▾
Brasileirinho Delivery	Cozinha 2 · Yooga	Térmica Cozinha 2 ▾
Brasileirinho Saudável	Cozinha 2 · Yooga	Térmica Cozinha 2 ▾
Spaleti	Cozinha 2 · Yooga	Térmica Cozinha 2 ▾

Por que isso vende: é a dor que hoje custa duas assinaturas (Saipos + Yooga) só pra separar comanda. No nosso PDV, 12 marcas convivem numa loja e cada comanda cai na cozinha certa — sem gambiarra, sem sistema duplo.

Marcas reais da operação (as de cima hoje saem pelo Saipos, as de baixo pelo Yooga). Faltam ~2 a confirmar. Backend de roteamento (marca→dispositivo) = próximo módulo; o cano de impressão já está no ar.