Producto multi-tenant de Cofundo: un comercial compone un dossier vivo por prospecto (módulos de UI animados, orden, ocultos, precio) y lo comparte como enlace bajo la marca de su empresa (pitch. /d/). Enjoy the Club es el primer tenant.
Producto multi-tenant de Cofundo: un comercial compone un dossier vivo por prospecto (módulos de UI animados, orden, ocultos, precio) y lo comparte como enlace bajo la marca de su empresa (pitch.<tenant>/d/<token>). Enjoy the Club es el primer tenant.
Puesta en marcha (Supabase, Vercel, dominio) paso a paso: docs/SETUP.md
Stack: Astro 5 SSR (Vercel o Node/Docker) · Tailwind 3 sobre CSS vars · Zod · Svelte 5 (builder) · Supabase (Postgres + Auth + RLS).
Arrancar en local (modo DEMO, sin Supabase)
npm install
cp .env.example .env # deja vacías las claves de Supabase → modo DEMO con supabase/seed/fixtures.json
npm run dev # http://localhost:4321
# o con el build de producción: npm run build && npm run start:demo
En un build de producción sin Supabase la app responde 503 (no entra en demo salvo DEMO_MODE=1).
Consola: en demo eliges usuario (comercial / admin de Enjoy, o comercial de otro tenant → 403)
localhost se resuelve al tenant DEV_TENANT_SLUG (por defecto enjoy); *.localhost se resuelve por la tabla domain.
En modo demo los cambios hechos en /admin se ven al momento en /d/<token> (BD en memoria; se pierde al reiniciar).
Con Supabase
Producción: sigue docs/SETUP.md. En local con la CLI (supabase start aplica migraciones, seed de demo y plantillas de email de supabase/config.toml).
El renderer público solo usa la clave anon y dos RPC security definer (resolve_tenant, get_public_dossier).
La consola usa Supabase Auth (contraseña, enlace mágico, invitaciones, recuperación) con cookies httpOnly (@supabase/ssr); cada consulta va con el JWT del usuario → la RLS aplica siempre. La service_role solo se usa para invitar usuarios y en el script de alta.
Listado: filtros por estado / "solo míos" / búsqueda; alta de dossier (vacío o desde plantilla)
/admin/dossiers/:id
Builder: datos del prospecto, modo de precio (none/total/per_module), catálogo, reordenar (drag & drop + botones ↑↓), ocultar, precio por módulo, personalizar textos (JSON validado contra el schema), actualizar a la última versión del módulo, publicar/despublicar/archivar/borrar, generar/copiar/revocar enlaces con caducidad, vista previa móvil/tablet/escritorio
/admin/dossiers/:id/preview
Vista previa autenticada (cualquier estado)
/admin/api/dossiers/:id
API JSON del builder: GET estado · POST {op} → estado · DELETE
/admin/catalog(admin)
Módulos y versiones: crear variante, borrador → publicar → archivar, preview, uso por dossiers
/admin/team(admin)
Invitar por email, cambiar rol, quitar (nunca sin al menos un admin)
/admin/brand(admin)
Colores, radios, tipografía (fuente propia), logos/favicon/imagen OG (subida a Storage), contacto (WhatsApp…), con vista previa
/admin/learn
Aprende a vender: formación por módulo (jugadas oficiales, vista previa del módulo, trucos del equipo, votos, proponer mejoras), progreso y novedades
/admin/learn/sector/:key
Sector: cliente ideal, cómo compran, módulos que encajan y actores (quién decide, paga, puede tumbarlo; cómo abordarles)
/admin/compose
Preparar mensaje: contexto listo para el Cerebro de Ventas en Claude/ChatGPT («tipo DJ → mensaje»)
/admin/playbook(admin)
Mercado y actores (editor), bandeja de propuestas, jugadas (crear/editar con versión y nota), «qué funciona», exportación con formato del Cerebro
/admin/dossiers/:id → «Guion de venta»
Guion de la reunión generado del playbook para ese dossier (orden, precio, objeciones); imprimible en
Arquitectura: el builder (Svelte) solo envía operaciones (src/lib/admin/ops.ts); las reglas viven en un único servicio (src/lib/admin/service.ts) sobre la interfaz AdminDb, con dos implementaciones: memoria (demo) y Supabase con la sesión del usuario. La misma batería de tests de contrato (service.contract.ts) se ejecuta contra ambas.
Scripts
Script
npm run dev / build / start / start:demo
Desarrollo / build SSR / servidor Node / servidor Node en demo
npm run tenant:bootstrap -- tenants/<slug> [--dry-run]
Alta/actualización idempotente de un tenant en Supabase (service role)
npm run check
astro check (tipos)
npm test
Vitest: unitarias de todo src/ y los contratos contra la base demo (ver docs/DESARROLLO.md)
npm run db:test
Migración + seed + aserciones de RLS/RPC sobre un Postgres pelado (stub de auth), sin Supabase CLI
npm run db:it
Contrato del servicio de la consola (dossiers, equipo, catálogo, marca) y script de alta contra Postgres + PostgREST + RLS reales con supabase-js (POSTGREST_BIN=/ruta/postgrest)
npm run db:seed:build
Regenera supabase/seed.sql desde fixtures.json (CI comprueba que está al día)
node scripts/smoke-e2e.cjs
Smoke Playwright del enlace público (orden, precios, 404s, tema, multi-instancia)
node scripts/smoke-admin.cjs
Smoke Playwright de la consola: plan §13 pasos 2–7 por la UI (login, crear, drag & drop, ocultar, precio, publicar, enlace, revocar, RBAC, móvil)
node scripts/smoke-tenant-admin.cjs
Smoke Playwright de catálogo, equipo y marca (incl. reflejo en el enlace público)
node scripts/smoke-market.cjs
Smoke Playwright de sectores/actores, Preparar mensaje, cuenta del dossier, guion «Con quién hablas» y seguimiento
node scripts/smoke-playbook.cjs
Smoke Playwright del playbook: aprender, votar, compartir, proponer, bandeja del líder, guion en el builder
Los smokes van contra un servidor en modo demo: npm run build && npm run start:demo. Hay uno por flujo en scripts/smoke-*.cjs (todos en CI); arriba solo los primeros. Cómo se prueba, dónde va cada cosa y las reglas de rendimiento: docs/DESARROLLO.md.
Esquema Supabase + RLS + RPC token-gated, con tests de seguridad
Middleware de tenant por Host, renderer /d/<token> con gates y 404 neutro
Fase 1 — consola y builder: hecha
Auth (Supabase Auth email+contraseña / magic link; login de demo), RBAC admin/rep, 403 por tenant
Listado con filtros y alta (vacío o desde plantilla)
Builder: catálogo, drag & drop + teclado/botones, ocultar, precio none|total|per_module + overrides, personalización validada, actualizar versión, publicar/despublicar/archivar/borrar, enlaces con caducidad y revocación, vista previa por dispositivo
CSRF propio (Origin vs host del tenant) — ver ADR-0001
Tests: contrato del servicio en demo y en Postgres+PostgREST+RLS; E2E de consola en navegador
Fase 1.5 — listo para producción (salvo cuentas y datos de Enjoy)
Guardia de producción (sin config → 503, nunca demo), /api/health
Equipo, catálogo y marca desde la consola; invitaciones, recuperación y cuenta
Marca en el dossier (logo, CTA WhatsApp, pie, favicon, OG para compartir)
Storage por tenant con RLS; permisos por columna; nunca sin admin
Script de alta idempotente + tenants/enjoy prerrellenado; despliegue Vercel/Docker; guía SETUP
Playbook de ventas — propuesta implementada para revisar (docs/PLAYBOOK.md)
Jugadas tipadas por módulo con la taxonomía del Cerebro (etapa/objeción) y referencias a sus fichas
«Aprende» (formación con progreso y novedades), capa de equipo (trucos y mejoras), bandeja del líder con versiones
Guion de venta por dossier en el builder + imprimible; «me funcionó»; resultado del dossier; métricas; export
Import del playbook en tenant.json; contenido de ejemplo para Enjoy
Consola con el design system de Cofundo: shell con dos navegaciones, listas como tarjetas, modales que dicen lo que no hacen, vacíos tipados, lint:copy en CI
Situaciones configurables por tenant (personalidad, región, rasgos) y cierres documentados ganados o perdidos
«Qué ha funcionado» con parecido explicado y ranking por cierres reales; fuera los votos
Configuración guiada con iconos y puntos de partida (ocio y eventos, turismo activo y buceo, en blanco)
Pendiente — necesita a otra persona
Tú: crear el proyecto Supabase, SMTP, Vercel y DNS → docs/SETUP.md
