Seed y reinicio
Un framework de seed packs para demos de ventas, entornos de QA y onboarding de clientes — con un límite de seguridad fijado en código que hace imposible ejecutar seeds contra un cliente real. Datos realistas, desmontaje reversible, auditoría completa.
Los datos de demo, los datos de QA y los datos de onboarding tienen el mismo requisito: parecer reales, comportarse como reales y no contaminar jamás un tenant de producción. Demos se construye en torno a ese límite, lo primero.
Un comercial quiere enseñárselo a un prospecto. Entra en el tenant de producción y crea un evento ficticio. Los informes reales lo recogen. La conciliación real lo contabiliza. La vergüenza real llega después.
Los datos de prueba que todos envían son obviamente sintéticos — todos los nombres son «Test User 1», las fechas son de 2023, los presupuestos son de 1 $. Los prospectos pierden interés en segundos.
Un ingeniero de QA necesita un entorno de prueba limpio. El script de reinicio es un documento de Notion de 47 pasos. La mitad ya no se aplica. El entorno nunca se reinicia de verdad.
Los nuevos clientes abren el producto y se encuentran un tenant vacío. No saben qué pulsar. No saben qué aspecto tiene el valor. El primer login es la peor experiencia.
Cada capacidad convierte los seed packs en código de primera clase — versionados, reproducibles, reversibles y trazables. QA, ventas y onboarding tiran de la misma estantería.
Cada seed pack declara su id, versión, módulos cubiertos y funciones idempotentes de apply / plan. Los packs son código de primera clase, no un montón de fixtures SQL.
El pack event-agency-starter incluye 12 proveedores, 5 eventos, 15 oportunidades, 3 presupuestos, 5 órdenes de trabajo, 8 reservas — nombres realistas, costes realistas, fechas realistas. Una demo que parece una demo de verdad.
Cada fila creada se etiqueta en platform.seed_rows con el id del pack y el id de la aplicación. El desmontaje es determinista — sin filas huérfanas, sin limpieza manual.
Cada apply/reset comprueba organizations.is_production. Ninguna ruta del código de aplicación puede ejecutar seeds en un cliente real. Nunca.
Cada pack tiene una función plan que previsualiza qué se crearía — recuentos por tabla, filas de muestra, totales esperados. El dry-run es una operación de primera clase, no una conjetura.
Las aplicaciones de seed se registran en platform.seed_applications con el actor, la marca de tiempo, la versión del pack y los recuentos. QA reproduce bugs reejecutando el mismo seed exacto. Las demos de ventas quedan etiquetadas y rastreables.
Un solo pack puede cargar oportunidades de Ventas, líneas de Presupuesto, proveedores en Proveedores, órdenes de trabajo en Despacho y reservas en Espacios — todo en una sola transacción, preservando los enlaces entre módulos.
Aplicar un pack requiere teclear exactamente el slug de la organización destino. Reiniciar requiere lo mismo. Protección antitorpezas para administradores con prisa.
Seguro por defecto
Los seed packs no pueden ejecutarse en un tenant de producción — ni por error, ni por override, ni por nadie. El límite de seguridad vive a nivel de código y a nivel de datos.
lib/seeds/safety.ts::assertNotProduction(orgId) se llama antes de cada escritura. Si organizations.is_production = true, el pack lanza una excepción. Ninguna ruta del código de aplicación puede saltarse la comprobación.
Los tenants de clientes reales tienen is_production = true. Los tenants de demo y QA, no. El módulo Demos se desactiva por completo en organizaciones de producción mediante un feature flag — doble bloqueo absoluto, cinturón y tirantes.
La plataforma está activa. Solicita una demo para ver el módulo Demos en acción.
Parte de una plataforma de 13 módulos que se adapta a tu operación. Sin compromiso.