Assinatura mensal de café — com máquina em comodato
Cliente monta cesta de cafés + bebidas + complementos, escolhe máquina de espresso (comodato), assina e recebe entrega mensal cobrada todo dia 10. Cobertura inicial: Grande SP (39 municípios). Entrega valor desde a v0.1 — cada release é demoável para o cliente final e captura métrica de negócio.
Tire dúvidas (cliente final) ou opere o negócio (time Master Espresso) direto na home. Stack: Vercel AI SDK v6 + Anthropic Haiku 4.5 + Generative UI (gráficos, formulários e timelines renderizados inline). Sample interativo do v0.5 Chat Native.
💡 Veja exemplos do agente em ação (navegação demo, sem custo de IA):
Mostra o gráfico de MRR dos últimos 12 meses
Pronto! 📊 Aqui está o gráfico de MRR dos últimos 12 meses da Master Espresso. Total atual: R$ 12,4k/mês, +175% no período.
MRR Master Espresso · 12m
Total MRR atual: R$ 12.400 · Variação vs período anterior: +175.6%
↑ Demo estático (não chama IA). Pra usar de verdade, digite uma mensagem abaixo. ⬇
Status atual · próximas duas entregas
⮕ Próxima versão a entregar
v0.1
A primeira venda real do produto que o Fernando especificou no BRIEF — o cliente percorre as 7 telas definidas pelo Diretor Mukutu, escolhe a cesta + máquina em comodato e paga via Pix ou cartão recorrente automático. Esta versão prova que a visão original do BRIEF funciona em produção.
Negócio: Validação operacional da arquitetura que o Fernando desenhou: cobrança recorrente (Pix Automático ou cartão recorrente) + restrição CEP Grande SP + máquina em comodato — tudo conforme o escopo original. O Cliente Master Espresso fecha a primeira assinatura e registra faturamento real.
Janela: S1-S2 (8d camel — MVP guts, hard ceiling estendido p/ BRIEF Fernando ampliado)
📈 Lead time (rolling 7-8w)
— d
Sem releases shipados ainda. Lead time é capturado em manager.sqlite via task-start.ts / task-done.ts a partir da v0.1.
📝 Changelog
Nenhuma versão shipada ainda. Primeira release: v0.1.
Ciclos relativos (S1–S8) a partir do kickoff. Kickoff a confirmar com Cliente Master Espresso. Datas absolutas só fixadas após confirmação. Cada release é valor real entregue ao cliente final + Master Espresso. Budget estendido pra acomodar BRIEF Fernando ampliado (Next.js 15 + Tailwind v4 + Shadcn + cartão recorrente).
📐 Monte Carlo · 7-8w budget · WIP=1 por fase · Discovery overlap Coding
Cards entregues acumulados ao longo das 7-8 semanas (S0 → S8). Compara linha esperada vs realizada em tempo real. Use os botões pra simular 3 cenários de evolução: 🐌 atrasado · 🎯 no prazo · 🚀 super rápido.
📈 Burn-Up Live · 7-8 semanas budget (35-40d)
Cards entregues acumulados ao longo das semanas — quanto mais a linha sobe, mais perto da entrega completa.
Escolha um cenário para simular a evolução do burn-up ao longo das 7-8 semanas (35-40d budget).
Por versão · expandable · widgets + fases mukutu
Click no chevron pra expandir. Versão next (v0.1) já abre por default. Cada card mostra widgets entregues + flow de 4 fases Mukutu (Discovery / Coding / Internal QA / Customer Validation).
v0.1S1-S2 (8d camel — MVP guts, hard ceiling estendido p/ BRIEF Fernando ampliado) · 1.5 sempróximaA primeira venda real do produto que o Fernando especificou no BRIEF — o cliente percorre as 7 telas definidas pelo Diretor Mukutu, escolhe a cesta + máquina em comodato e paga via Pix ou cartão recorrente automático. Esta versão prova que a visão original do BRIEF funciona em produção.
Outcome clienteA primeira venda real do produto que o Fernando especificou no BRIEF — o cliente percorre as 7 telas definidas pelo Diretor Mukutu, escolhe a cesta + máquina em comodato e paga via Pix ou cartão recorrente automático. Esta versão prova que a visão original do BRIEF funciona em produção.
Outcome negócioValidação operacional da arquitetura que o Fernando desenhou: cobrança recorrente (Pix Automático ou cartão recorrente) + restrição CEP Grande SP + máquina em comodato — tudo conforme o escopo original. O Cliente Master Espresso fecha a primeira assinatura e registra faturamento real.
MétricaTaxa de conversão funil T1→T7 + ticket médio mensal R$ + tempo médio de onboarding em minutos + mix Pix vs cartão recorrente
Capabilities
T1 catálogo
T2 bebidas
T3 açúcar
T4 máquina comodato
T5 revisão+termos
T6 cadastro+ViaCEP
T7 Pix Automático + cartão recorrente (Pagar.me)
Widgets entregues nesta versão · 5
🎯
Funnel T1→T7client-facing
Conversão por step do onboarding, identifica drop-off
Por quê: Mostra se o funil das 7 telas — conforme o Fernando especificou no BRIEF — converte visitante em assinante real. Identifica em qual etapa o cliente abandona.
Como medir: Conta sessões que entraram em cada passo T1-T7 vs as que avançaram. Janela 7 dias, atualização diária.
T1 Cafés
100%
T3 Açúcar
78%
T5 Termos
54%
T7 Pago
38%
💰
Ticket médio assinaturaclient-facing
R$/mês médio das assinaturas fechadas na semana
Por quê: Confirma que o valor mensal da assinatura — incluindo cesta + máquina em comodato — sustenta a operação conforme o modelo de negócio do BRIEF Fernando.
Como medir: Soma o valor mensal de assinaturas ativas dividido pela contagem. Compara semana atual vs semana anterior.
87R$/mês▲ +R$12 vs sem ant
💳
Saúde cobrança recorrente (Pix + cartão)ops-stack
Taxa sucesso cobrança recorrente last 24h — agrega Pix Automático + cartão recorrente
Por quê: Garante que a cobrança recorrente — peça central do modelo de assinatura que o Fernando definiu — opera sem perda de receita por falha técnica. Mede Pix e cartão juntos porque assinante escolhe método no checkout.
Como medir: Webhook do gateway de pagamento conta cobranças pagas vs falhas (Pix + cartão) nas últimas 24h. Alerta automático abaixo de 95% de sucesso.
Por quê: A restrição CEP Grande SP é regra de negócio central do BRIEF. Se a validação travar no T6, o cliente abandona o cadastro — este indicador mostra se a etapa é fluida.
Como medir: Mede o p95 do tempo de resposta de lookup de CEP nas últimas 24h. Hits de cache são contados separados para medir resiliência.
🚨
Sentry healthops-stack
Taxa erro frontend/API last 24h + alertas críticos
Por quê: Garante que o produto em produção está estável — sem erros derrubando o onboarding ou o pagamento que o Cliente Master Espresso precisa operar no dia a dia.
Como medir: Calcula taxa de erro por sessão nas últimas 24h. Alerta crítico se saúde cair abaixo de 95% ou surgir erro inédito.
v0.2S3-S4 (6d dog — painel cliente) · 1 semplanejadaO assinante entra no painel — a área logada que o Fernando incluiu no escopo — e, sem ligar para ninguém, vê quando a próxima cobrança ocorre, quando a próxima caixa chega e altera endereço, método de pagamento (Pix ou cartão) ou dados por conta própria.
Outcome clienteO assinante entra no painel — a área logada que o Fernando incluiu no escopo — e, sem ligar para ninguém, vê quando a próxima cobrança ocorre, quando a próxima caixa chega e altera endereço, método de pagamento (Pix ou cartão) ou dados por conta própria.
Outcome negócioEntrega a área do cliente que o Diretor Mukutu especificou no BRIEF (T8-T9), eliminando a principal causa de contato de suporte pós-onboarding: alterações de endereço, método de pagamento (Pix/cartão) e dados cadastrais, que representam a maioria dos tickets recebidos.
MétricaPercentual de alterações feitas no painel sem acionar suporte humano + NPS da área do cliente
Capabilities
T8 dashboard cliente
T9 dados cadastrais
Supabase auth magic-link
Widgets entregues nesta versão · 3
📅
Próxima cobrança cardclient-facing
Data + valor + método (Pix ou cartão) da próxima cobrança recorrente
Por quê: A transparência sobre a próxima cobrança é parte fundamental da área do cliente que o Fernando pediu. Quando o assinante sabe exatamente quando, quanto e por qual método (Pix ou cartão) será cobrado, a dúvida 'quando me cobram?' some do suporte.
Como medir: Lê data, valor e método de cobrança via API do gateway de pagamento. Renderiza no dashboard do cliente a cada acesso.
12/julR$87,00→ Pix recorrente
🛠️
Edições self-service %internal
% mudanças feitas no painel vs via suporte
Por quê: Valida que a área self-service — pedida pelo Fernando no BRIEF — realmente desonera o time operacional: cada alteração feita pelo próprio assinante é um contato de suporte que não acontece.
Como medir: Conta eventos de edição no painel vs tickets de suporte de mesma natureza. Janela de 7 dias.
💾
ViaCEP cache hit rateops-stack
% lookups CEP servidos do cache (reduz custo external)
Por quê: A validação CEP Grande SP aparece novamente em T9 (edição de endereço). O cache garante que o assinante não aguarda uma API externa a cada alteração.
Como medir: Cache layer: hits / (hits + misses) nas últimas 24h. Meta 70%, monitorado em tendência semanal.
64% / alvo 70%
Visão executiva · 4 fases Mukutu · linguagem de negócio
v0.3S4-S5 (6d dog — alteração recorrência) · 1 semplanejadaO assinante personaliza a cesta do próximo mês — mais Bourbon, menos Tradicional, por exemplo — sem precisar cancelar e reassinar. A tela de alteração de recorrência que o Fernando previu no BRIEF (T10) transforma variedade em fidelidade.
Outcome clienteO assinante personaliza a cesta do próximo mês — mais Bourbon, menos Tradicional, por exemplo — sem precisar cancelar e reassinar. A tela de alteração de recorrência que o Fernando previu no BRIEF (T10) transforma variedade em fidelidade.
Outcome negócioEntrega a Tela 10 do BRIEF Fernando (Alteração de Recorrência), que converte o impulso de cancelamento por tédio em auto-atendimento. Assinante que personaliza a cesta permanece ativo; o time operacional não precisa intervir.
MétricaPercentual de assinantes que ajustam a cesta por mês + taxa de churn comparada ao período anterior à v0.3
Capabilities
T10 alteração recorrência
queue alterações pendentes
worker pré-cobrança
Widgets entregues nesta versão · 3
🔄
% mudanças cesta/mêsclient-facing
% assinantes que ajustam cesta antes da cobrança
Por quê: Valida a tese central da v0.3: o assinante que usa a alteração de cesta — recurso especificado pelo Fernando no BRIEF — tende a permanecer ativo em vez de cancelar.
Como medir: Conta assinantes que salvaram alteração em T10 antes da cobrança / total ativos. Janela mensal.
31%▲ +8pp
🏆
Top 3 trocasclient-facing
SKUs mais adicionados/removidos pelos assinantes
Por quê: Revela o que o assinante real quer na cesta — informação direta para o Cliente Master Espresso ajustar catálogo e compras de estoque.
Como medir: Agrega deltas de SKU na fila de alterações pendentes dos últimos 30 dias. Top 3 por volume adicionado/removido.
+ Bourbon Amarelo
42
− Café Tradicional
28
+ Cappuccino Premium
19
📉
Retention ringclient-facing
Churn rate quem alterou cesta vs quem não alterou
Por quê: Confirma se assinantes que personalizam a cesta retêm mais — valida a aposta do Diretor Mukutu de que variedade é o principal motor de retenção neste produto.
Como medir: Compara taxa de cancelamento em 30 dias entre cohort que alterou cesta vs cohort que não alterou. Atualização mensal.
Visão executiva · 4 fases Mukutu · linguagem de negócio
Discovery1-1.5d
Decidir quando alteração de cesta aplica no ciclo
Build2-3d
Cliente troca SKUs e queue aplica na próxima cobrança
QA1-2d
Smoke ciclo completo com cesta alterada antes da cobrança
Validation0.5-1d
Cliente Master Espresso troca SKU real e confirma próxima caixa
Decidir regra: quando alteração aplica (próximo ciclo D-N)
v0.4S6-S8 (9d camel — Chat Native + 4 Gen UI Suite) · 1.5 semplanejadaUma evolução inteligente do Painel Administrativo que o Fernando especificou no BRIEF (T11-T13): em vez de três telas estáticas de gestão, o Cliente Master Espresso opera a plataforma conversando com ela. Pede 'mostra faturamento do mês' → gráfico aparece. Pede 'lista assinantes em risco' → tabela na hora. Pede 'cadastra novo produto' → formulário preenchível. O assinante final também tem acesso ao chat: 'quando chega minha entrega' → timeline visual; 'como altero minha cesta' → orientação imediata. O valor que o Diretor Mukutu pediu — visibilidade operacional total — entregue de forma mais natural.
Outcome clienteUma evolução inteligente do Painel Administrativo que o Fernando especificou no BRIEF (T11-T13): em vez de três telas estáticas de gestão, o Cliente Master Espresso opera a plataforma conversando com ela. Pede 'mostra faturamento do mês' → gráfico aparece. Pede 'lista assinantes em risco' → tabela na hora. Pede 'cadastra novo produto' → formulário preenchível. O assinante final também tem acesso ao chat: 'quando chega minha entrega' → timeline visual; 'como altero minha cesta' → orientação imediata. O valor que o Diretor Mukutu pediu — visibilidade operacional total — entregue de forma mais natural.
Outcome negócioTraduz a proposta administrativa do BRIEF Fernando (Painel Admin T11-T13) em uma interface conversacional, evitando a construção de três telas customizadas que costumam consumir grande parte do orçamento de qualquer SaaS. O Cliente Master Espresso ganha visibilidade operacional completa sem depender de um painel estático: cada pergunta gera a interface certa, na hora. Sem ferramentas externas de suporte, sem manutenção de layouts adicionais.
MétricaPercentual de ações operacionais realizadas via assistente vs telas tradicionais + taxa de resolução sem escalonamento humano + custo por conversa
% chats AI resolveu sem escalar pro time Master Espresso no WhatsApp
Por quê: Mede se o assistente conversacional entrega o valor operacional que o Fernando previu: o Cliente Master Espresso e seus assinantes resolvem dúvidas sem acionar o time humano.
Como medir: Conta percentual de conversas encerradas sem acionar escalonamento humano. Janela de 7 dias.
💸
Custo por conversaops-stack
Custo de IA por conversa média
Por quê: Confirma que a abordagem conversacional escolhida para o Painel Admin opera dentro do orçamento — custo de IA por conversa deve ser marginal comparado a ferramentas externas equivalentes.
Como medir: Soma custo por tokens consumidos por sessão. Média dos últimos 7 dias.
R$0,02/chat→ marginal
🧩
Interfaces mais solicitadasinternal
Top componentes visuais invocados pelo assistente last 7d
Por quê: Revela quais interfaces visuais o Cliente Master Espresso mais requisita — as mais usadas têm prioridade de refinamento nas versões seguintes.
Como medir: Conta invocações por tipo de componente nos logs do assistente. Janela de 7 dias.
RevenueChart (admin)
28
OrderTimeline (cliente)
41
SubscriberGrid (admin)
14
ProductUploadForm (admin)
5
🎯
Top 3 intents clienteclient-facing
Categorias de pergunta mais comuns last 7d
Por quê: Mostra o que o assinante real pergunta com mais frequência — entrada direta para o Cliente Master Espresso priorizar melhorias na operação e no atendimento.
Como medir: Classifica a primeira mensagem de cada conversa por intenção via análise automatizada semanal.
Quando chega entrega
38
Mudar cartão
24
Alterar cesta
18
Visão executiva · 4 fases Mukutu · linguagem de negócio
Discovery1.5-2d
Curar FAQs Master Espresso e definir quando escalar humano
Build3-4.5d
Chat na home + 4 ferramentas visuais (gráfico, formulário, lista, entrega)
QA2-2.5d
20 perguntas reais resolvidas sem escalação humana ≥80%
Validation1-1.5d
Cliente Master Espresso opera 4 ferramentas inline no chat real
Curar 50 FAQs Master Espresso reais com Cliente Master Espresso
Decisões pendentes do Cliente Master Espresso · 4 itens
4 decisões realmente bloqueiam o time (Gateway saiu da lista — Pagar.me ratificado por Gabriel 2026-06-09). As outras questões abertas têm default proposto e procedem.
⚑ 4 decisões aguardando resposta + 1 resolvida
Decisão
Proposta (assumption)
Bloqueia se errado
Gateway de pagamento ✅
Pagar.me — Pix Automático + cartão recorrente (ratificado por Gabriel 2026-06-09 · Lane X)
—
“Novo cliente” T4
cheque duplo sessão + BD (ASSUMPTION-02)
v0.3 cadastro
Base Grande SP
39 municípios RMSP/IBGE (ASSUMPTION-03)
v0.3 CEP validação
Comodato — fidelidade + multa
12 meses fidelidade (ASSUMPTION-04 + RN-07)
v0.4 ativação assinatura
Cobrança — dia + corte
dia 10 · corte D-3 (ASSUMPTION-05)
v0.5 cobrança automática
Mais detalhe (links rápidos)
Capacidades — 16 capabilities + sketch arquitetura aplicação por use-case
Sobre este doc: render v0.2 da tensão pai #1 — converter BRIEF.md (proposta 19245) em base navegável para o time. Pipeline interno: gerado por agentes joyous-triceratops + quadratic-crab (workflow A1 Analyst → A4 Renderer). Lead time e changelog dos releases serão capturados em manager.sqlite + arquivos releases/v*.mdx (sustain pattern do skill ops-stack) a partir da v0.1. Esses identificadores são internos ao pipeline de geração e não interferem no escopo do projeto Master Espresso.