CLI
Reglas de Validación y Seguridad
Motor de Compatibilidad en Tiempo Real
A diferencia de otros generadores que crean código roto al combinar opciones incompatibles, Koko cuenta con un motor de validación estricto en `internal/compatibility`. Si pasas flags inválidos por terminal o intentas elegirlos en el TUI, el CLI abortará con un mensaje de error explicativo y sugerencias de corrección.
Las 7 Reglas de Seguridad
✓ Regla 1: Frontend y Backend simultáneos en None: Un proyecto no puede tener ambos extremos vacíos; debe seleccionarse al menos un Frontend o un Backend.
✓ Regla 2: SPAs sin backend conectadas a Base de Datos: Una SPA pura de cliente (React + Vite o Svelte) no puede incluir credenciales de base de datos ni ORMs sin un servidor intermedio.
✓ Regla 3: Consistencia DB vs ORM: No es posible seleccionar un ORM si la base de datos está marcada como "none".
✓ Regla 4: ORMs Relacionales (SQL) vs Documentales (NoSQL): Drizzle, SQLAlchemy y GORM no pueden usarse con MongoDB. Mongoose no puede usarse con PostgreSQL, MySQL o SQLite.
✓ Regla 5: Ecosistema de Lenguaje vs ORM: SQLAlchemy solo es compatible con Python. GORM solo es compatible con Go. Drizzle, Prisma y Mongoose solo son compatibles con Node.js / TypeScript.
✓ Regla 6: Gestor de Paquetes por Lenguaje: Un backend puro en Go solo admite `go_mod`. Un backend puro en Python solo admite `pip` o `uv`.
✓ Regla 7: Proveedores de Autenticación: Better-Auth requiere un entorno TypeScript (Next.js, Express o Hono). NextAuth.js requiere específicamente Next.js como frontend.
Ejemplo de Diagnóstico de Error
Si intentas ejecutar un comando con tecnologías incompatibles:
koko init my-app -f react -b none --database postgres --orm drizzle
# Salida del CLI:
# ✗ Incompatible stack error:
# Una aplicación SPA cliente (react) sin backend no puede conectarse directamente a la base de datos 'postgres'
# Sugerencia: Agrega un backend (como Express, Hono, FastAPI o Go Chi) o usa un framework fullstack (como Next.js o Nuxt)