Um usuário não via o dia de ontem. Abri todo o passado do Garfim.

Em 6 de novembro de 2026, tomei uma decisão de produto a partir do feedback de um usuário que não conseguia ver o dia anterior. O aplicativo só mostrava o consumo de hoje.

A especificação do projeto já contemplava a edição retroativa e a cópia de refeições antigas. As fotos guardadas também nunca eram lidas de volta. O feedback evidenciou uma promessa no planejamento que a tela não entregava.

Defini então um registro de decisão técnica para reorganizar essa navegação. Deixo claro que se trata de uma decisão de arquitetura: em 7 de novembro, nada disso está no aplicativo no ar. Minha regra de trabalho exige que toda implementação seja a menor necessária, testada localmente e validada em ambiente de testes antes de subir para a produção.

Qualquer dia anterior funciona exatamente como o dia atual

A premissa da mudança é direta: qualquer dia passado precisa funcionar como o dia de hoje. A tela principal ganha uma faixa com os dias da semana para permitir a troca de data no mesmo espaço. Ao tocar numa data anterior, a pessoa vê as refeições registradas, o consumo de água e os totais nutricionais daquele dia.

O dia selecionado fica salvo apenas na memória do aparelho. Se o usuário fechar o aplicativo ou se o dia virar, a visualização retorna para a data corrente. Também desenhei uma tela de histórico mensal com calendário, total de dias registrados, média calórica e lista em ordem decrescente, com busca pelo nome do alimento.

A regra temporal estabelece limites claros. O sistema recusa registros com data futura, aceitando no máximo 15 minutos de folga em relação ao servidor para celulares com relógio adiantado. Para o passado, não há limite: os dados são da pessoa e ela preenche o histórico quando quiser.

Refeições em dias anteriores recebem o horário usual do turno naquela data (08:00, 12:30, 16:00 e 20:00 no fuso horário da conta). A tela permite alterar o horário exato ou mover o prato de dia. A água também passa a ser editável no passado, com os copos adicionados no meio-dia da data escolhida.

O que consome inteligência artificial mantém a cota diária

Um ponto central foi separar o que consome processamento de inteligência artificial das consultas de dados. Tudo o que não gera custo computacional segue gratuito. Visualizar o passado, editar porções, mover refeições, copiar pratos antigos, excluir registros e cadastrar alimentos por busca de texto ou código de barras permanecem liberados no plano gratuito.

O consumo das cotas gratuitas ocorre quando o aplicativo chama os modelos de visão ou de áudio. Uma análise fotográfica de um prato de ontem consome o limite diário da data em que a chamada é realizada, não da data da refeição.

No mesmo dia 6, removi das fichas das lojas a promessa de escolher fotos da galeria, pois o aplicativo não tinha esse recurso. A decisão do histórico agora inclui a importação de fotos da galeria para refeições fotografadas antes e não registradas na hora. Por exigir código nativo no celular, essa função chegará aos usuários numa versão nova das lojas, aplicando a mesma miniatura de 512 pixels das fotos comuns.

Para a remoção de várias refeições, o aplicativo processa as exclusões em lote após uma única confirmação, informando o total de calorias antes e depois da limpeza.

As fotos voltam a ser exibidas sem criar novos caminhos no sistema

Até agora, as fotos enviadas não eram lidas de volta pela interface. A nova regra determina que a foto da refeição volta a ser exibida para quem a tirou, permanecendo disponível enquanto o registro existir na conta.

A leitura dessas imagens aproveita a mesma sessão e checagem de propriedade das refeições, sem criar rotas paralelas ou novas estruturas de segurança. A antiga regra que apagava fotos após 30 dias foi revogada. Excluir a refeição ou a conta remove as imagens, e a limpeza automática continua descartando rascunhos após 24 horas.

A opção de salvar imagens segue como escolha em Privacidade, mas passa a vir ativada por padrão no consentimento do cadastro. Contas existentes preservam a opção já definida. Se a foto de uma refeição não foi guardada ou expirou na regra antiga, a tela mostra uma ilustração de prato com aviso de foto indisponível, mantendo a lista de alimentos. A numeração da política de privacidade fica igual para não invalidar consentimentos já concedidos.

O que foi recusado para manter a estrutura enxuta

Durante a proposta, avaliei e recusei três alternativas que trariam complexidade ao código:

1. A criação de telas separadas para rotas de datas específicas, o que duplicaria a interface já existente na tela principal.
2. A criação de caminhos paralelos no servidor para servir imagens, o que exigiria um segundo fluxo de autenticação para arquivos pequenos.
3. A adição de uma nova biblioteca externa para seleção de calendário, visto que a base nativa do aplicativo já oferece esse componente.

Uma frase de um usuário bastou para mostrar que a especificação prometia o que a tela não entregava. A entrega vem em partes pequenas, cada uma testada localmente e em staging antes de chegar ao aplicativo. No mesmo dia, a ficha das lojas também precisou alinhar promessa e produto, como contei em 62% baixavam o Garfim, e o problema estava antes da página.