PROMPT DE CONTINUIDADE — IDR COMANDAS / PDV DE BALCÃO
Data do briefing: 22/10/2026

Quero que você atue como arquiteto de software, desenvolvedor desktop Windows, designer de interfaces e testador de qualidade para construir um aplicativo real, simples e utilizável. Sou Diego, sócio da IDR Soluções, empresa brasileira de consultoria fiscal, tecnologia e automação (não somos escritório de contabilidade).

LEIA TODO ESTE BRIEFING E COMECE PELO MVP FUNCIONAL. Não transforme o projeto num ERP complexo. Não pare na descrição de telas nem me entregue somente um HTML estático ou uma maquete sem persistência. Quero código-fonte e um programa para instalar/abrir em outro computador Windows, sem exigir que o cliente instale Python, VS Code ou faça procedimentos técnicos.

1. ORIGEM E OBJETIVO

Visitei um cliente que vai abrir uma cafeteria/lanchonete com possibilidade de servir refeições. Ele procura um sistema bom, barato, prático e que não trave como o sistema que conhece atualmente. Ele atenderá e registrará os pedidos NO BALCÃO, não por garçons com celulares. Precisamos organizar consumo em comandas, cobrar rapidamente e liberar a comanda após o pagamento. A IDR quer começar com esse cliente piloto e, se funcionar bem, oferecer o mesmo produto a outros estabelecimentos.

O sucesso do sistema é medido pela simplicidade, velocidade no balcão, consistência dos valores e preservação dos dados. Nada de controles administrativos complexos nessa primeira versão.

2. PLATAFORMA E ARQUITETURA

- MVP para um único computador com Windows, com dados armazenados localmente e operação sem internet.
- Aplicativo desktop executável (.exe) com janela própria; se necessário, instalador Windows simples. Não entregar apenas um endereço de site.
- Sugestão tecnológica: Python com interface desktop simples e moderna (por exemplo, Tkinter/CustomTkinter ou PySide6), banco SQLite e empacotamento com PyInstaller. Pode escolher solução equivalente mais simples, desde que seja mantível, offline e entregue em executável real.
- Banco local com transações e integridade referencial; gravar cada operação imediatamente e impedir corrupção por fechamento normal ou falha de energia tanto quanto tecnicamente viável.
- Uma instância de caixa por banco no MVP, evitando duas execuções simultâneas sobre o mesmo arquivo. Estruturar o código para permitir evolução futura, mas não implementar servidor/rede agora.
- Diretórios de dados e backup fora de áreas temporárias e fora do próprio executável; atualização da aplicação não pode apagar banco ou configurações.
- Não adicionar dependência de HostGator, servidor externo, conexão constante ou assinatura para o funcionamento técnico da primeira versão.

3. TELAS MÍNIMAS

A interface deve ter poucas áreas, com botões grandes e legíveis:

A) VENDER / NOVA COMANDA
- Escolher venda direta (cliente paga na hora) ou abrir comanda numerada.
- Informar número da comanda; nome do cliente opcional.
- Localizar produtos por nome/categoria e botões de favoritos (café, pão de queijo, salgado etc.).
- Adicionar produto com um clique, aumentar/reduzir quantidade, visualizar preço unitário, subtotal e total em tempo real.
- Salvar alterações imediatamente, sem perder itens se o usuário fechar a tela.

B) COMANDAS ABERTAS / FECHAR
- Mostrar números, total e status das comandas abertas; buscar digitando o número.
- Abrir comanda existente e adicionar consumo depois.
- Fechar comanda com confirmação da forma de pagamento: dinheiro, Pix, débito, crédito ou pagamento dividido entre modalidades.
- Registrar valor recebido e troco no caso de dinheiro.
- Concluir fechamento uma única vez, emitir comprovante interno opcional e liberar o número da comanda para novo atendimento.
- Preservar histórico da comanda antiga mesmo quando o número for reutilizado.
- Permitir apenas reabrir/cancelar lançamentos mediante permissão ou senha gerencial, com trilha de auditoria.

C) PRODUTOS
- Cadastro simples: código interno automático, nome, categoria, preço em reais, ativo/inativo e favorito.
- Editar preços sem alterar os preços registrados nas vendas já realizadas.
- Nenhum NCM, CEST, controle de estoque ou tributação obrigatórios nesta fase.

D) CAIXA E RELATÓRIOS
- Abertura de caixa com valor inicial, fechamento e resumo por dia/turno.
- Total vendido, quantidade de vendas, comandas pendentes e total por modalidade de pagamento.
- Registro simples de sangria/suprimento, se não prejudicar o prazo do MVP.
- Exportação CSV/Excel simples; evitar pacotes pesados sem necessidade.
- Conferir que somas dos recebimentos e os relatórios batem com as vendas concluídas, descontados estornos identificados.

4. REGRAS DE NEGÓCIO IMPORTANTES

- Cada abertura gera identificador único interno, ainda que o número visível da comanda seja reaproveitado.
- Não permitir duas comandas abertas com o mesmo número.
- Uma comanda fechada é histórica e não pode ser sobrescrita por novo consumo.
- Pagamento finalizado não pode ser lançado duas vezes por clique duplo ou travamento de interface.
- Registrar vendas e pagamentos em centavos inteiros ou decimal apropriado, nunca em float binário para calcular dinheiro.
- Não aceitar quantidade negativa, preço negativo ou desconto maior que o valor da venda.
- Cancelamento/estorno exige motivo e usuário responsável, sem apagar o lançamento original.
- Usuários iniciais: administrador e operador de caixa, com senha armazenada por hash seguro, nunca em texto puro. Credenciais iniciais devem ser definidas na instalação, não fixas no código.
- Sempre mostrar mensagens claras quando um campo estiver faltando ou houver falha de gravação.
- Caso o fechamento do programa ocorra com uma comanda aberta, ela deve reaparecer com todos os itens ao reiniciar.

5. EXPERIÊNCIA DE USO

O atendente não tem tempo de procurar opções. Priorizar fluxo em poucos cliques, pesquisa instantânea, navegação por teclado, tela limpa e controles fáceis de entender. Mostrar sempre o total e a ação principal. Não usar animações pesadas. Deve funcionar em resolução comum de notebook ou monitor de caixa. Evitar tabelas apertadas, rolagem horizontal e excesso de menus.

Exemplo de teste: abrir comanda 10, lançar 2 cafés de R$ 6,00 e 1 pão de queijo de R$ 8,00; total deve ser R$ 20,00. Fechar em Pix; a comanda 10 desaparece da lista de abertas, o relatório soma R$ 20,00 em Pix, e uma nova comanda 10 pode ser aberta sem apagar o histórico. Todos esses produtos e valores são DADOS DEMONSTRATIVOS.

6. VISUAL PADRÃO IDR SOLUÇÕES V3.0

Aplicar aspecto premium e tecnológico, porém extremamente enxuto. Paleta: laranja principal #F47A1F, laranja escuro #C94F00, laranja claro #FF9A3D, preto #111111, grafite #262626, branco #FFFFFF, cinza claro #F4F5F7 e cinza médio #9CA3AF. Botões principais com fundo #C94F00 e texto branco. Fonte sem serifa legível, textos normais em torno de 14–16 px. Tema claro como padrão; escuro só se for simples adicionar sem atrasar o MVP. A logo deve ser exclusivamente o arquivo original da IDR fornecido, pequena e proporcional. Se a logo não estiver disponível, peça o arquivo, mas continue o desenvolvimento com identificação textual provisória, sem inventar um desenho da marca.

Nome de trabalho: IDR Comandas. O nome comercial definitivo ainda poderá ser escolhido.

7. DOCUMENTO FISCAL E PAGAMENTOS — LIMITES IMPORTANTES

- Esta primeira versão NÃO emitirá NFC-e, NF-e, NFS-e, SAT nem qualquer documento fiscal.
- Registro de Pix e cartão é MANUAL: o operador confirma que recebeu; não existe integração bancária, adquirente, TEF ou verificação automática de Pix.
- Recibo interno, se adicionado, deve ser claramente identificado como NÃO FISCAL.
- Isso NÃO dispensa o comerciante de cumprir sua obrigação de emitir documento fiscal. Antes de operar, o cliente deverá definir com sua contabilidade um processo fiscal regular, independente ou futuro módulo integrado. Não prometer que o sistema pode substituir a nota fiscal.
- Se a exigência fiscal inviabilizar o uso isolado, sinalize isso para decisão comercial; não invente dispensas legais.

8. O QUE FICA FORA DO MVP

Sem estoque avançado, compras, financeiro empresarial, folha, delivery, iFood, WhatsApp, cardápio QR, impressora de cozinha, mesas, garçons/celular, controle de produção, fidelidade, emissão fiscal, múltiplas filiais, sincronização em nuvem, dashboard complexo, integração com maquininha ou cadastro tributário. Adições futuras somente após validação do básico.

9. BACKUP E SEGURANÇA DOS DADOS

- Cópia de segurança automática diária e no fechamento do caixa, preferencialmente usando backup consistente do SQLite.
- Botão para exportar backup para pasta/pendrive e rotina documentada de restauração com confirmação explícita.
- Registrar erros em log local sem expor senhas/dados sensíveis.
- Não excluir informações reais em atualização; fazer migração de banco quando necessário.
- Testar restauração em uma cópia isolada antes de declarar a rotina pronta.
- Explicar ao cliente que backup em um único disco não protege contra falha física/roubo do computador e orientar cópia externa periódica.

10. DUAS MODALIDADES COMERCIAIS QUE A IDR QUER OFERECER

Quero que o aplicativo seja tecnicamente o mesmo nas duas modalidades; o contrato comercial muda:

OPÇÃO A — PAGAMENTO ÚNICO
- O cliente paga uma vez pela licença de uso local e implantação.
- Pode continuar utilizando a versão adquirida sem mensalidade, mesmo que não contrate atualizações posteriores.
- Atualizações evolutivas, novas funcionalidades, suporte continuado e visitas adicionais serão cobrados separadamente.
- Prever por escrito regras de reinstalação, troca de computador e tratamento de defeitos/garantia, respeitando a legislação aplicável.
- A IDR mantém titularidade do código-fonte e concede licença não exclusiva; não transferir exclusividade do produto no preço básico.

OPÇÃO B — MENSALIDADE
- Implantação inicial, se adotada, e mensalidade recorrente.
- Direito de usar a solução, receber correções, melhorias gerais da versão contratada e suporte básico dentro de limites claros (horário/canal/tempo de atendimento a definir).
- Funcionalidades personalizadas grandes, equipamentos, emissão fiscal e integrações de terceiros não estão automaticamente incluídos na mensalidade.
- Definir no contrato o tratamento do sistema após cancelamento, bem como exportação dos dados do cliente, sem criar bloqueio inesperado.

Os valores ainda NÃO estão fechados. Na conversa anterior foi cogitada apenas a combinação preliminar R$ 590 de implantação + R$ 119 por mês; não a trate como preço aprovado. Apresente uma sugestão economicamente sustentável para as duas opções, incluindo custos de implantação, manutenção, suporte e margem para a IDR, e peça a confirmação do Diego antes de incluir preços finais em proposta comercial ou no software. Não construir validação de licença remota/DRM complexa no MVP.

11. PRAZO E PRIORIDADES

Desejo máxima agilidade. Meta inicial de planejamento: uma demonstração navegável o quanto antes, talvez no mesmo dia de trabalho; uma versão funcional simples em cerca de 2 a 5 dias úteis se o ambiente e o escopo permitirem. Isso não significa prometer produção segura antes dos testes. Seja transparente quanto aos riscos, dependências e tempo adicional de validação em máquina Windows real. O prazo é estimativa, não garantia.

Ordem de implementação:
1. Definir estrutura do projeto e modelo de dados mínimo.
2. Implementar produtos, abrir/adicionar itens/salvar comanda, consultar e fechar.
3. Implementar pagamentos manuais, abertura/fechamento de caixa e resumo do dia.
4. Incluir usuários/permissões, auditoria, backup/restauração e tratamento de erros.
5. Executar testes automatizados e testes manuais do fluxo crítico.
6. Gerar executável Windows e instruções de instalação e backup.

12. TESTES DE ACEITAÇÃO OBRIGATÓRIOS

- Produtos e preços cadastrados persistem após sair e reabrir o sistema.
- Abrir comanda, adicionar novos pedidos horas depois e fechar com total correto.
- Fechamento parcial/dividido soma exatamente o valor devido.
- Duplo clique não duplica venda nem pagamento.
- Mesma comanda pode ser reutilizada somente depois do fechamento, preservando o histórico anterior.
- Alteração posterior do cadastro não altera valor histórico de venda.
- Aplicativo reiniciado conserva comandas não pagas e relatórios corretos.
- Fechamento de caixa confere com as formas de recebimento registradas.
- Cancelamento exige autorização e mantém trilha.
- Backup restaurado em ambiente isolado recupera vendas e comandas corretamente.
- Programa roda sem internet em Windows, sem instalação manual de Python.
- Interface permanece responsiva em volume razoável de uso de uma cafeteria; documentar a carga efetivamente testada.

Nunca diga que testou algo sem realmente executar o teste. Se não puder construir/testar .exe no ambiente disponível, entregue o projeto completo e os comandos/scripts de compilação, explicando claramente que o executável ainda depende de compilação e testes em Windows.

13. ENTREGÁVEIS

Entregar:
- Código-fonte organizado e comentado somente onde necessário.
- Banco de demonstração com produtos claramente fictícios; não misturar com produção.
- Executável/instalador Windows quando tecnicamente viável, ou build script preciso e reproduzível se o ambiente não suportar compilação Windows.
- Arquivo ZIP com projeto, assets originais permitidos, requirements, instruções de compilação e manual de uso curto.
- Guia de instalação, backup, recuperação e atualização sem perda de dados.
- Relatório de testes feitos, testes pendentes e limitações reais.
- Proposta comercial editável separada com as duas modalidades, sem valores inventados como aprovados.

14. COMO VOCÊ DEVE RESPONDER E AGIR AGORA

Não reinicie a discussão sobre ERP nem acrescente módulos que não pedi. Resuma em poucas linhas a arquitetura mínima escolhida e comece a implementar o MVP REAL, por etapas verificáveis. Evite perguntas que não bloqueiam o desenvolvimento; use dados demonstrativos para prototipar. Só pergunte o indispensável para instalar na máquina real, principalmente versão do Windows, impressora opcional e confirmação de um único terminal. Mantenha decisões técnicas simples e reversíveis, priorize consistência financeira, operação offline e uma tela de caixa muito rápida. Não publique, não instale no cliente e não afirme pronto para produção sem autorização e sem validação.

RESULTADO FINAL ESPERADO: um PDV de balcão pequeno e confiável, com comandas e caixa, que a IDR possa demonstrar, instalar e vender em modalidade de pagamento único ou assinatura, preservando o código-fonte e podendo evoluir o mesmo produto para outros clientes.
