Refogando
Refogar: dourar alho e cebola na gordura quente — o gesto por onde quase toda comida brasileira começa. É daí que vem o nome.
App de receitas com IA, bilíngue pt-BR / en-US desde a primeira linha. Você busca o que já existe, cria conversando com a IA, ou cria no capricho por formulário — e um único núcleo de domínio cuida de tudo, idêntico em qualquer idioma.
O que dá pra fazer
- Criar receita com IA em três modos: conversa (chat multi-turno, retomável), estruturado (formulário → geração sob medida) e texto livre (descreve o prato, sai a receita).
- Descobrir e buscar: a home é um feed indexável, e a busca híbrida (full-text por idioma + semântica com embeddings) acha por nome, ingrediente ou "perfil culinário" (cozinha, categoria, tags). Acervo raso pro pedido? A busca pode oferecer links da web.
- Catálogo curado + comunidade: receitas editoriais (curadas por gente) convivem com as públicas da comunidade — sem se misturarem num ranking cego.
- Estúdio de imagem por IA: gerar e editar a foto do prato, com galeria por receita e selo honesto de "gerada / editada por IA".
- Social, na medida: seguir cozinheiros, salvar em coleções, avaliar com nota 1–5★ + comentário (e a foto do prato que você cozinhou), e uma caixa de notificações.
Stack
- Next.js 16 (App Router) + TypeScript, Tailwind + shadcn/ui.
- Postgres (Neon) via Drizzle ORM; busca semântica com pgvector.
- Better Auth (e-mail/senha, Google opcional).
- IA: texto no Claude (Anthropic), imagem no Gemini (Google).
- Vercel pro deploy — as migrações rodam no próprio deploy.
Rodando localmente
npm ci
cp .env.example .env.local # preencha DATABASE_URL, BETTER_AUTH_SECRET e as chaves de IA
npm run dev # http://localhost:3000
Comandos que você vai usar:
npm run typecheck # tsc --noEmit
npm run lint # eslint
npm test # vitest — dois projetos: "node" (Postgres real) e "ui" (jsdom)
npm run e2e # Playwright de fumaça (ver docs/e2e.md)
npm run db:generate # gera a migração Drizzle a partir do schema
As migrações são geradas no repo e aplicadas no deploy (o vercel.json roda db:migrate antes do build). Nunca migre o banco de produção da sua máquina.
Como o projeto pensa (leia antes de mexer)
CONTEXT.md — a linguagem ubíqua do domínio (Receita, Proveniência, Visibilidade, Cozinha, Avaliação, Salvar…). É a fonte da verdade dos nomes; se um termo não está aqui, provavelmente não devia existir.docs/adr/ — as decisões de arquitetura, uma por assunto, com o porquê e as alternativas rejeitadas.docs/handoffs/ — handoffs auto-suficientes de cada fase de trabalho.docs/observabilidade.md — as linhas de log ([erro], [mail]…) e como achá-las nos logs da Vercel.docs/agents/ — as convenções pra agentes (issue tracker, triage, docs de domínio).
Fluxo de trabalho
Desenvolvimento por fases, e cada issue passa por um pipeline de 8 passos: explorar → planejar → revisar o plano → corrigir → implementar em TDD → code-review multi-lente → corrigir → validar e mergear. Tudo por branch + PR + squash-merge — nunca direto na main (que é protegida). Os detalhes vivem no CLAUDE.md.
Bom saber
- Um bom teste testa comportamento, não implementação. A suíte
node sobe um Postgres real e descartável.
- PRs só de documentação (
docs/** ou qualquer .md) pulam a CI e o deploy — handoff e ADR não mexem no build.
- Os selos de IA (receita gerada, imagem gerada/editada) são honestos e obrigatórios dentro do app: a gente não disfarça o que a máquina fez.
Feito com café e alho dourando na panela.
