尚未检测到更新。GitHub 发布版本后会显示在这里。
按最近已完成的 8 小时观测回合间的 GitHub 星标增量排序
The distributed app store for vibe-coded projects. Browse, discover, and install open-source apps from across GitHub.
翻译准备中
个人 GitHub 账号下公开仓库的所有者可以登录并验证所有权，自行管理介绍，无需管理员批准。
登录并生成验证文件，在 30 分钟内将其提交到此仓库的默认分支。其他分支或分叉仓库中的文件无效。然后在下方检查文件，即可无需管理员批准直接管理项目。请保留文件以维持管理权限。
如需登录，将前往登录页面。登录后请回到此处，再次点击所选的验证按钮。
在项目文件夹中运行 /nomorevibe verify，即可验证所有权并自行管理介绍。
一分钟完成验证正在加载完整 README。 以下为已保存的摘录。
Seu restaurante. Sua loja. Seus pedidos. SaaS B2B multi-tenant para restaurantes: cardápio digital, checkout próprio (Pix/dinheiro/cartão) e painel operacional, sem comissão por pedido. Stack: Next.js 16 (App Router) + React 19 + TypeScript + Tailwind CSS 4; Supabase (Postgres + Auth + Storage, com RLS) como backend; Sentry para monitoramento de erros; Vitest para testes unitários. Abra http://localhost:3000. Outros scripts: npm run build, npm run lint, npm test.查看完整 README ↗
Seu restaurante. Sua loja. Seus pedidos.
SaaS B2B multi-tenant para restaurantes: cardápio digital, checkout próprio (Pix/dinheiro/cartão) e painel operacional, sem comissão por pedido.
Stack: Next.js 16 (App Router) + React 19 + TypeScript + Tailwind CSS 4; Supabase (Postgres + Auth + Storage, com RLS) como backend; Sentry para monitoramento de erros; Vitest para testes unitários.
cp .env.example .env.local # preencher com as credenciais do projeto Supabase (ver seção abaixo)
npm install
npm run dev
Abra http://localhost:3000.
Outros scripts: npm run build, npm run lint, npm test.
Ver .env.example (todas comentadas). Só as duas do Supabase são obrigatórias:
NEXT_PUBLIC_SUPABASE_URL e NEXT_PUBLIC_SUPABASE_ANON_KEY — projeto Supabase.GOOGLE_MAPS_GEOCODING_API_KEY — opcional; sem ela o frete "Por KM" fica indisponível e a taxa fixa continua funcionando.ASAAS_API_KEY e ASAAS_ENV (sandbox por padrão, ou production) — opcionais; sem a chave, "Assinar plano" mostra um aviso em vez de fingir sucesso. Nunca prefixar com NEXT_PUBLIC_.SUPABASE_SERVICE_ROLE_KEY e CRON_SECRET — só para a cobrança (registro da assinatura provada na API do Asaas e reconciliação diária). Sem elas a cobrança fica desligada. Servidor apenas: nunca prefixar com NEXT_PUBLIC_, nunca commitar.A assinatura do lojista é cobrada pelo Asaas (o pedido do cliente final continua sendo Pix direto, sem gateway). Para operar:
ASAAS_API_KEY (comece pelo sandbox), SUPABASE_SERVICE_ROLE_KEY e CRON_SECRET./master/assinaturas (nome e valor reais, nada é semeado)./master/assinaturas e configure o mesmo valor no webhook do Asaas (Integrações → Webhooks → Token de acesso), apontando para https://<seu-domínio>/api/webhooks/asaas. Sem token salvo, nenhum webhook é aceito. O roteiro de teste ponta a ponta com o sandbox está em docs/asaas-sandbox-e2e.md.npm test roda o Vitest. Os testes cobrem a lógica de src/lib/, o webhook e a rotina de reconciliação do Asaas e a Server Action de assinatura (com dependências simuladas). O vitest.config.ts resolve o alias @/. As demais Server Actions ainda não têm teste automatizado.
Isolamento entre restaurantes (banco): supabase/tests/tenant_isolation.sql verifica RLS e RPCs com quatro personas (dono da loja A, usuário sem loja, master fora da loja e visitante anônimo): ninguém lê nem altera dados de outra loja, o master só enxerga lojas alheias pelas RPCs master_*, e o checkout público recusa produto de outra loja. Cole o arquivo no SQL Editor do Supabase; ele roda numa transação que sempre é desfeita e o relatório vem na mensagem final (RESULTADO: OK | N verificacoes ou RESULTADO: FALHOU ...). Rode-o depois de qualquer mudança em policies ou RPCs. Ele ainda não roda no CI, que não tem banco.
Proteção das colunas de cobrança: supabase/tests/restaurant_billing_columns.sql (145 verificações) garante que nenhum usuário da API (OWNER, STAFF, outra loja ou anônimo) altera plan_id, subscription_status e demais colunas de cobrança de restaurants, que os fluxos legítimos continuam funcionando e que a segunda camada (trigger) barra mesmo com um GRANT amplo. Rode só em banco isolado (ele cria usuários em auth.users); não use contra a produção.
Cobrança de assinaturas: supabase/tests/billing_subscriptions.sql (192 verificações) garante que o acesso pago só é liberado por pagamento confirmado em evento autenticado do provedor: IDs inventados, cobrança pendente, atraso, duplicidade, evento fora de ordem, chargeback, cancelamento com período pago, renovação, reconciliação, webhook inválido, tentativas de OWNER/STAFF, isolamento entre restaurantes e checkout dos clientes intocado. Mesma regra: só em banco isolado. Modelo e regras de manutenção em docs/seguranca/cobranca-de-assinaturas.md.
Papéis OWNER e STAFF: supabase/tests/roles_owner_staff.sql (222 verificações) comprova que o STAFF só opera pedidos e liga/desliga a disponibilidade de produtos e adicionais, no banco (RLS e triggers), nas RPCs e nas Server Actions, e que o OWNER, o checkout público e a venda de balcão seguem funcionando. Regras e camadas em docs/seguranca/permissoes-owner-staff.md. Rode só em banco isolado.
Privilégios de tabela: supabase/tests/table_privileges.sql (153 verificações) garante que anon, authenticated e PUBLIC não têm TRUNCATE, TRIGGER, REFERENCES nem MAINTAIN nas tabelas de public (nem nas futuras), que o DML usado pelo app segue concedido e que service_role e o dono mantêm tudo. Migration: 20261009030000_harden_table_privileges.sql. Rode só em banco isolado.
Todo o schema (tabelas, RLS, RPCs) vive em supabase/migrations/ — esse diretório é a fonte de verdade do estado do banco em produção; qualquer alteração de schema deve ser adicionada ali como uma nova migration (nunca aplicada só em produção sem o arquivo correspondente).
Documentação relacionada: reconciliação do histórico de migrations (versões dos arquivos × versões registradas no Supabase), regras de manutenção das colunas de cobrança e modelo de cobrança de assinaturas.
/loja/[slug]): cardápio com categorias/adicionais/combos, carrinho, checkout e acompanhamento do pedido — sem exigir login do cliente final./painel): dashboard, pedidos (Kanban em tempo real), cozinha (KDS), frente de caixa (PDV), cadastro de produtos/categorias/adicionais/combos, cupons e marketing, clientes, configuração de delivery (inclui zonas por bairro)/horários/pagamentos/aparência, equipe (convites de STAFF), plano e assinatura, e ajuda./painel/plano continua acessível para regularizar). A regra vive no banco (função _restaurant_access_state) e vale também no create_order./master): acesso restrito a quem tem profiles.is_master (só concedível pelo editor SQL do Supabase). Telas reais: dashboard da plataforma, restaurantes (lista e detalhe), assinaturas (planos e token do webhook) e configurações. Ainda em branco: Usuários, Métricas, Suporte e Auditoria.src/app — rotas (App Router): fanpage (/), /cadastro, /onboarding, /convite/[token] (aceite de convite de equipe), /loja/[slug] (loja pública), /painel (lojista), /master (administração da plataforma).src/lib — acesso a dados (tenant.ts, store.ts), Server Actions (lib/actions/) e regras de negócio puras testadas em *.test.ts.src/components/ui — primitivos (Button, Badge, Card, Modal, estados de loading/vazio/erro).src/components/layout — sidebar (com menu mobile), topbar e banner de impersonation do Master.src/components/scaffold — placeholder usado nas rotas ainda não implementadas visualmente.supabase/migrations — schema do banco (ver seção acima).design-reference/stitch — export original do Stitch, preservado como referência visual (ver design-reference/README.md para o mapa tela → rota).