ChatDelivery · PDV + Despacho

Linha de progresso

Agora

O PDV está operando de verdade: no dia 06/08 passaram 1.117 pedidos por ele. A comanda sai calibrada no papel da loja, o acerto do entregador fecha com desconto de adiantamento, e a tela do pedido foi medida pixel a pixel contra a régua do concorrente — está no ar desde 10/08

2120 testes verdes (api 1371 · web 690 · agente 59) suíte roda em banco SEPARADO de prod ✓ caminho da homologação iFood mapeado ✓ 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 ✓ cara do iFood (visual + arrasto + auto-aceite) ✓ chrome (menu, barra de cima, marcas)

Fechado ✓ 2.6.5 Impressão v2 — o papel sai na loja ✓ térmica de rede é o padrão ✓ o agente descobre o IP da impressora ✓ áreas — servidor e tela ✓ comanda montada no servidor ✓ comanda calibrada no papel (06/08) ✓ fila que sobrevive a deploy ✓ auto-impressão liga/desliga por loja

Fechado ✓ Tier 1 · acerto do entregador — taxa por raio, repasse congelado, turnos ✓ fechar, cancelar e imprimir o extrato ✓ desconto de adiantamento (07/08)

Fechado ✓ Relatórios — quanto vendi ontem, no ar ✓ teto do board — não esconde mais pedido no pico, no ar ◐ 2.6.3 Som repete até aceitar ✓ 2.7 O pedido mostra o que já sabe — no ar ✓ a impressão avisa quando falha — no ar

Em andamento VOCÊ ESTÁ AQUI ◐ Paridade Saipos — os itens que furam caixa: forma de pagamento, motivo de cancelamento, estorno ◐ Passo 4 Homologação iFood — Order e Events aprovados; Merchant depende de chamado no portal ◐ 2.6.4 Acabamento (vocabulário comum, tela por tela) ◐ Passo 3 Roteirização — montagem de rota no ar; pool, atribuição e fila justa seguem

Depois ○ 2.6.2 Arrastar em todas as colunas ○ Entregadores · Balcão

A tela do pedido foi medida pixel a pixel contra a régua do concorrente — e o Lucas achou três coisas que a medição jurava estar certas (10/08). O modal fechou com 1,17px de diferença média e altura de 884 contra 883. Mas o que vale contar é como os três últimos apareceram: em todos, o erro era do instrumento, não da tela. O alinhamento do nome do cliente perseguia um número que nunca foi medido — era uma estimativa que virou alvo, e persegui-la ainda afastava mais. O arredondamento dos cantos saía errado porque a borda desfocada engana quem mede a primeira linha. E o pin do bairro sumiu da medição por ser claro demais: o limiar que separa texto de fundo não o enxergava, e a conclusão virou "o concorrente não tem esse ícone" — a mudança errada chegou a ser aplicada, e foi revertida. A régua era o defeito nas três.
Um erro no telefone que ninguém tinha visto: o 0800 saía impossível de discar (10/08). 0800 200 5011 virava (08) 00200-5011 — um DDD que não existe. Formatar errado é pior que não formatar: o número continua legível, mas o agrupamento ensina a discar errado, e quem lê em voz alta pro cliente repete. Apareceu ao pôr as duas telas lado a lado, não em teste nenhum.
O valor que a loja bancou de desconto agora aparece na tela do pedido (10/08). O dado já viajava do iFood e a tela descartava — a linha do desconto mostrava só a descrição, sem o valor. Junto entrou o nome da loja, que vinha vazio para todo pedido de toda loja: era um campo que o servidor esquecia de buscar, e parecia decisão de layout. E um botão pra copiar o pedido em texto, pra colar no WhatsApp.
O sistema entrou em operação de verdade — e o número diz isso melhor que qualquer promessa (07/08). No dia 06/08 passaram 1.117 pedidos pelo PDV em produção, contra 748 no dia anterior. Não é mais pedido de teste: é a operação real chegando, sendo impressa e despachada. Os dois containers (a API e a tela) atravessaram o jantar inteiro sem cair.
A comanda virou a régua do Saipos e do Yooga — e o veredito foi a tinta, não a tela (06/08). O papel agora resolve pra onde vai, o que vai dentro e se cobra: sai RECEBER R$ 39,05 ou NAO COBRAR DO CLIENTE, em vez do antigo "conferir no app" que empurrava a dúvida pro motoboy na porta do cliente. Três defeitos não existiam na tela: a comanda saía com 3 horas a mais, o R$ vinha com um caractere invisível que a impressora não conhece, e o tracejado ignorava a margem. Nenhum apareceria sem imprimir. Tem uma seção só sobre isso mais abaixo.
O ciclo do dinheiro do motoboy fechou (03 a 07/08). Antes, o sistema sabia quem entregou mas não quanto pagar. Agora: a loja cadastra a taxa por distância, o valor é congelado no momento do despacho (mudar a tabela hoje não reescreve o que já saiu), o acerto soma entregas e diárias, aceita desconto de adiantamento ou vale com o motivo escrito, e imprime o extrato A4 que o entregador assina. Acerto fechado não reabre: cancela e refaz, e o cancelado continua visível.
Pagar a mesma entrega duas vezes é impossível — por construção, não por cuidado (04/08). A trava é do banco de dados, não do programa: existe um índice que recusa fisicamente a segunda gravação da mesma entrega em outro acerto. Foi provado disparando dois fechamentos ao mesmo tempo: um passou com sucesso, o outro foi barrado. Uma checagem feita no programa deixaria os dois passarem — as duas leituras diriam "ainda não foi pago" antes de qualquer escrita.
O sistema passou a avisar sozinho quando para (06/08). Se a conexão com o iFood cair ou uma comanda encalhar, chega aviso — em vez de alguém descobrir pelo cliente ligando. Falta o Lucas passar o token do Telegram: até lá o aviso está mudo.
Os 8 endpoints do módulo Merchant fecharam (05/08). É o que o iFood exige para homologar a parte de "loja": horário de funcionamento, status, interrupções. O que falta agora não é código — é o chamado no portal do iFood, que só o Lucas pode abrir, com o dossiê já escrito e pronto.
O caminho da homologação no iFood deixou de ser palpite (29/07). A gente investigou a fundo e derrubou duas crenças que estavam na nossa própria documentação. A primeira: achávamos que faltava construir um jeito inteiro de conectar as lojas antes de poder ir a produção. Não falta — o modelo que o nosso sistema já usa é o de produção; o que separava era documentação errada nossa, não código. A segunda: achávamos que abrir e fechar a loja pelo PDV era pré-requisito. Também não é — o iFood aprova módulo por módulo, e o teste automático cobra só cinco coisas: conectar, receber e confirmar pedido, despachar, validar e cancelar. Tudo isso o PDV já faz. O que sobra é um item burocrático que só o Lucas resolve (a atividade cadastrada do CNPJ precisa ser de tecnologia, e isso se pede por chamado — leva dias, então vale abrir cedo).
O Lucas testou como usuário e achou um defeito — bem no lugar que o iFood vai olhar (29/07). Ao selecionar vários pedidos de uma vez e mandar despachar, nem todos iam. Investigando, eram três problemas no mesmo botão. O pior era silencioso: se um dos pedidos escolhidos tivesse saído da tela, ele era descartado sem avisar ninguém — o operador achava que tinha movido cinco e tinha movido quatro. O segundo: arrastar um pedido que fazia parte da seleção movia só aquele, ignorando os outros. E o terceiro era o próprio nome do botão: "Avançar" prometia uma coisa só, mas deixava cada pedido seguir o caminho dele — dois pedidos escolhidos juntos podiam parar em colunas diferentes. Agora o botão se chama "Mover para" (sugestão do Lucas), você escolhe o destino, e ele só oferece destinos que servem pra todos os selecionados. No fim, a tela presta contas: "3 de 5 movidos" — e os que falharam continuam marcados, prontos pra tentar de novo, em vez de sumirem. Vale reparar que despachar e cancelar são justamente duas das cinco etapas que o iFood testa.
Tudo que a gente fez ontem já está no ar (29/07, madrugada). Os Relatórios, o aviso de comanda que não saiu e o quadro de pedidos doze vezes menos travado entraram em produção. Uma observação pra não assustar: a tela de Relatórios mostra zero hoje, e isso está certo — os únicos pedidos no sistema de produção são os pedidos de teste do iFood, e a regra é clara em não contar pedido de teste como dinheiro. Quando entrar pedido de verdade, o número aparece.
Duas coisas novas, e uma delas responde a pergunta que você faz toda manhã (28/07). A primeira é a aba Relatórios: quanto entrou, quantos pedidos, ticket médio, quantos foram cancelados — e a quebra por marca e por item mais vendido, com botão pra baixar em planilha. A tela foi feita com uma regra específica: a pergunta tem UMA resposta e ela é um número, então o número aparece grande, sem gráfico enfeitando. A segunda é invisível e é sobre velocidade: o quadro de pedidos ficava travando um pouquinho a cada segundo — quase nada sozinho, mas o dia inteiro, com a tela cheia. A causa era um relógio que atualizava TODOS os cartões de uma vez, mesmo os que só mostram minuto. Agora só quem precisa de precisão de segundo (o cartão esperando aceite) fica no relógio rápido. Medido antes e depois: caiu de 62 para 5 — doze vezes menos travamento.
A impressora falhava e ninguém ficava sabendo — agora a tela avisa (29/07). Quando um pedido era aceito, a comanda saía sozinha na impressora da cozinha. Se ela não saía — papel acabou, computador da loja desligado, impressora fora do ar — o erro ficava guardado num arquivo de log que ninguém abre. O pedido entrava, o iFood começava a contar o tempo de entrega, e a cozinha simplesmente não sabia que tinha pedido. Agora o board avisa em cima, o pedido afetado ganha uma marca vermelha, e dá pra mandar imprimir de novo ali mesmo, sem sair procurando. O aviso só aparece depois de 2 minutos sem confirmação da impressora: comanda normal sai em segundos, então uma tela que avisasse na hora estaria sempre acesa — e aviso que toca sempre é aviso que ninguém lê.
Tudo que estava pronto há duas semanas finalmente entrou no ar (28/07). O sistema de produção estava rodando uma versão de 16 de julho — doze dias de trabalho aprovado esperando na fila. Entraram de uma vez: a cara do iFood, o conserto do board que escondia pedido no pico, as vias de impressão, a comanda montada no servidor, a roteirização inteira, a tela de Equipe, o aviso sonoro que repete até aceitar, e o pedido que para de esconder o que já sabe. Feito na ordem certa: cópia de segurança do banco antes de tudo, versão antiga guardada pra voltar em um comando, e o servidor velho ficou de pé durante a atualização do banco. Conferido entrando no sistema como usuário — e o primeiro pedido que abrimos, um pedido real do iFood, mostrou os 4 complementos que estavam guardados desde 19 de julho sem nunca terem aparecido numa tela.
E a parte chata que a gente arrumou de brinde: o site de produção morava na mesma pasta onde a gente programa (28/07). Parece detalhe, mas era a causa de dois sustos reais — em 19 de julho um comando de limpeza derrubou o PDV, e nesta mesma manhã uma reconstrução aconteceu por baixo do site no ar. Agora o site roda isolado, no próprio container, como o resto do sistema. Mexer no código não tem mais nenhum caminho físico até o que está servindo o cliente. Voltar atrás, se precisar, é uma linha.
O pedido já sabia o complemento e o recado do cliente — e a tela não mostrava (28/07). Quem pede açaí escolhe leite condensado, granola, banana, e às vezes escreve "sem banana" ou "tocar o interfone". Isso tudo já chegava do iFood e já saía na comanda impressa — mas na tela o pedido aparecia como uma linha só, "1× Açaí 500ml", e ponto: quem estava no computador via menos do que quem estava segurando o papel. Agora o pedido aberto mostra os complementos de cada item, o que o cliente pediu pra tirar, o recado dele em destaque, o complemento e a referência do endereço (o que faz o motoboy achar a porta), o telefone e, quando é dinheiro, quanto separar de troco. Pedido marcado pra mais tarde ganhou um selo AGENDADO — antes era idêntico a um pedido pra agora. Nada disso é dado novo: é o que já estava lá, saindo do esconderijo.
E no caminho apareceu um vazamento de endereço que ninguém procurava (28/07). Quando é o iFood que entrega (não a loja), o endereço do cliente é dado deles, não nosso — e a lista de pedidos já escondia isso corretamente. Só que ao abrir o pedido, aparecia tudo: rua, número, complemento, CEP, até a coordenada no mapa. Uma regra que o próprio código dizia por escrito estar seguindo, e não estava. Corrigido — e corrigido do jeito que não volta: a tela de dentro agora herda a regra da tela de fora, então não dá pra esquecer de esconder num lugar sem quebrar o outro na hora.
O board estava escondendo pedido no pico do jantar — e ninguém tinha como saber (28/07). A gente foi contar o pico de verdade: na segunda passaram 596 pedidos só no iFood, e às 21h26 havia 95 pedidos vivos ao mesmo tempo. O board pede no máximo 100 ao servidor — 5 de distância. Passando disso, ele simplesmente não recebe o resto, e os que ficam de fora são os mais antigos, ou seja, exatamente os atrasados. Pior: o corte não se conserta sozinho — o pedido que ficou de fora não volta mais, nem depois. Está sendo consertado agora: o teto sobe pra 300, o servidor passa a dizer quantos existem de verdade, e a tela avisa "mostrando 100 de 137" com um botão pra carregar o resto. Nota: isso é só o iFood, que é metade da operação — se o board passar a mostrar todos os canais, o pico dobra.
E a pergunta do Lucas sobre o botão de tema devolveu um achado maior (28/07). Ele perguntou se aquele efeito bonito de trocar claro/escuro pesava na máquina. Em vez de responder de cabeça, foi medido: o botão roda 2 vezes por dia e custa meio segundo. Só que o relógio que atualiza os cartões roda 86.400 vezes por dia e, com 94 pedidos na tela, trava a tela 62 milésimos a cada segundo, sem parar. A resposta certa não era "o botão está ok" — era "olha o relógio". Correção já planejada: quase nenhum cartão precisa de precisão de segundo, então só os que precisam continuam no relógio rápido.
O menu lateral e a barra de cima entraram na régua medida do iFood (26/07). Os ícones do menu agora vêm da mesma família que o iFood usa, e o item onde tu está fica preenchido em vez de mudar de cor — é assim que eles marcam, por peso e não por matiz. A barra de cima ganhou o seletor de marcas, e o filtro virou uma matriz marca × plataforma (qual marca, em qual canal). Está no ambiente de testes, ainda não em produção — os prints acima já são dele.
O board virou a cara do iFood — a tela que todo lojista de delivery já abre todo dia (25/07). Fomos no Gestor de Pedidos do iFood de verdade e copiamos a régua: o fundo das colunas ficou cinza e cada pedido virou um cartão branco que flutua por cima, com uma leve sombra. Antes era tudo bege e claro, e o cartão sumia no fundo. O painel ganhou cantos arredondados e o menu da esquerda virou uma faixa branca de ícones com o item de agora marcado em roxo. A ideia é simples: quem já usa o iFood não precisa reaprender nada.
Dá pra arrastar o pedido livre entre as colunas — no ambiente de teste (25/07). Pra ensaiar a operação sem depender de um pedido de verdade cair, agora tu pega o cartão e solta na coluna que quiser (Cozinha → Saiu → Entregue), e arrastar pra "Cancelados" abre a janela de motivo, nunca cancela seco. Só no sandbox: no pedido real o iFood continua mandando a ordem certa, isso é ensaio.
O "aceitar pedido sozinho" deixou de ser trava do dono — agora o atendente liga e desliga (25/07). O auto-aceite (o pedido entra em "Em preparo" sem ninguém clicar) estava escondido atrás da permissão de dono. Mas quem opera a tela na correria é o atendente — então o botão apareceu pra ele. É decisão do dia a dia, não configuração de dono.
E dois consertos que tu pegou no olho (25/07): a busca cortava a palavra "código" no meio ("...cóc"), e a dica que aparece no botão vazava pra cima do pedido da coluna vizinha. Os dois ajustados — a dica agora abre pra dentro do próprio cartão.
Despachar a rota agora tem confirmação — e o mapa parou de fugir da tela (21/07, tarde). Quando tu aperta Despachar rota, a janela troca tudo por um ✓ Rota despachada e some sozinha: antes era um aviso que aparecia no canto oposto ao que tu estava olhando — e, pior, pintado de vermelho, a cor de erro, num sucesso. Se um pedido da rota falhar no meio, o ✓ não aparece: a tela nomeia quem saiu e quem não saiu, porque um ✓ ali seria a tela mentindo sobre uma entrega que não foi.
O mapa ficou fixo na lateral; quem rola é a lista (21/07). Antes, com muitos pedidos, a lista empurrava a página inteira e o mapa saía por baixo — justo no momento de pico, que é quando ele mais serve. Agora a tela tem altura travada e cada coluna cuida da sua rolagem.
Trocar pra aba "Montadas" troca o assunto do mapa (21/07). Some o monte de pedidos soltos e aparecem as paradas das rotas já montadas, com a casinha da loja de onde saíram. Antes essa aba abria com o mapa vazio até tu clicar numa rota — o que se lê como "não tem nada", quando a verdade era "ainda não escolhi".
Pedido que a loja ainda não aceitou aparece em cinza, em vez de sumir (21/07). Ele fica apagado, com o selo não aceito, e não deixa ser marcado pra rota. Esconder respondia a pergunta errada: quem vê 2 pedidos na tela e 3 comandas na mão conclui que o sistema perdeu um.
Passar o mouse num pedido no mapa abre a ficha dele por cima (21/07) — número, cliente, número no iFood, endereço, quanto a loja prometeu e a hora prevista. Se o pedido estiver na beirada do mapa, o mapa se desloca o mínimo pra ficha caber inteira, em vez de mostrá-la cortada.
A tela de roteirização foi repaginada seguindo o Tatu (21/07) — cada pedido virou um cartão com o tempo que falta pra promessa do iFood estourar, em número e numa barrinha que enche. O nome do cliente aparece, o bairro vem na frente (é por ele que se decide o que sai junto), e clicar no pino abre um cartão no mapa com os detalhes.
E aqui o Lucas corrigiu a engenharia. Eu tinha inventado uma régua de atraso a partir de uma média — com um pedaço da conta estimado por mim, que eu tinha deixado escrito como o elo fraco. Ele apontou: "a barra pode seguir a previsão oficial do iFood". Fui conferir: o iFood manda a hora prometida ao cliente em todo pedido, e a gente jogava fora essa informação desde sempre. Agora cada pedido tem a própria régua — 45 minutos prometidos e 90 minutos prometidos não são a mesma urgência — e a pergunta deixou de ser "esse pedido está velho?" pra ser "a gente vai furar o combinado?", que é o que o cliente sente.
E aí ela virou a segunda tela repaginada do produto (a primeira foi o login). O mapa agora é fundo lavado — tiramos dois terços da cor dele de propósito, pra o pedido aparecer em cima em vez de competir com estrada amarela e parque verde. Cada pedido mostra há quanto tempo está esperando, em número e em cor: verde no ritmo, âmbar pedindo atenção, vermelho atrasado — com legenda no canto, porque cor sem legenda é enfeite. E o bairro subiu na frente do endereço, que é por onde se decide o que sai junto.
A roteirização foi aprovada e entrou no código principal (21/07). São 23 mudanças, 333 testes automáticos passando, e cada tela conferida clicando de verdade no ambiente de testes — não só "o teste passou". Ainda não está em produção: entrar no código principal e ir pro ar são coisas diferentes, e subir é uma decisão à parte.
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.

A roteirização está em produção desde 28/07 (mapa, rota, entregador, despacho com confirmação). A impressão saiu do "pronto no código" e virou papel na cozinha da loja, com as vias separadas — o motoboy leva o endereço na mão. O que falta pra homologar: o chamado do módulo Merchant no portal do iFood, que só o Lucas abre. O que falta pro produto vender sozinho: os itens de paridade com o Saipos que ainda furam o caixa — forma de pagamento no relatório, motivo de cancelamento e estorno.

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 ▾

Linha de progresso

Cardápio

Spike de Impressão paralelo maior risco

Entregadores reaproveita