# Flujo de Proyecto desde Base de Datos

## Contexto

Cuando el proyecto usa configuración almacenada en base de datos, el demo, skin y módulos se determinan en runtime desde datos persistidos, no desde `config/cd-system.php` estático.

## Proveedores de Configuración

### DemoConfigServiceProvider

Carga la configuración del demo y módulos desde la base de datos (tabla `demos` o `settings`). Sobrescribe los valores de `config/cd-system.php` con los valores de la DB.

### CdSystemSeeder

Carga el archivo **`cd-system.json`** (o similar) que contiene:

- `theme.demo`: demo activo
- `theme.skin`: skin activo
- `modules.{x}.active`: módulos activos
- `modules.{x}.navigation`: enlaces header/footer

Este JSON alimenta la tabla correspondiente o se importa a la config.

### SiteDataSeeder

Carga **`site-data.json`** que contiene:

- Información del sitio (nombre, logo, contacto)
- Footer links
- Redes sociales

Alimenta `config/site.php` o tabla equivalente.

## Flujo de Inicialización

```
1. Migración DB
   └── Tablas: demos, settings, site_data, ...

2. Seeders
   ├── CdSystemSeeder      → cd-system.json → config cd-system
   ├── SiteDataSeeder      → site-data.json → config site
   └── (otros seeders)

3. DemoConfigServiceProvider (boot)
   └── Lee DB → merge en config('cd-system')

4. Request
   └── config('cd-system.theme.demo') ya tiene el valor de DB
   └── get_theme_demo() retorna el demo correcto
   └── Layout y vistas se resuelven según ese demo
```

## Archivos de Referencia

| Archivo | Contenido |
|---------|-----------|
| database/seeders/CdSystemSeeder.php | Importa cd-system.json |
| database/seeders/SiteDataSeeder.php | Importa site-data.json |
| storage/cd-system.json | Config demo/módulos (si se usa archivo) |
| config/cd-system.php | Valores por defecto, sobrescritos por DB |
| app/Providers/DemoConfigServiceProvider.php | Merge config desde DB |

## Proyecto por Instalación

Cada instalación de CD-System puede tener:

- **Un único proyecto** (single-tenant): config en .env o config fija.
- **Multi-proyecto** (multi-tenant): cada proyecto tiene su fila en DB con demo, skin, módulos. El middleware o dominio selecciona el proyecto y carga su config.

## Principio: Una DB = Un Proyecto (multitenant)

Para que el CMS se adapte al cambiar de base de datos:

1. **Config por DB**: La configuración de demo y módulos se lee de la **base de datos actual** (tabla `settings` con keys `cd-system.*` y/o tabla `demos` con `cd_system_config`). No se asume un estado global compartido entre proyectos.

2. **Cache por DB**: `CdSystemConfigService` y `SiteConfigService` usan en la clave de cache el nombre de la DB (`env('DB_DATABASE')`), de modo que cada proyecto tiene su propio cache. Al cambiar `DB_DATABASE` en `.env`, tras limpiar caché se cargan los datos del nuevo proyecto.

3. **Demo activo desde la DB**: Si no se fuerza con `APP_DEMO` en `.env`, el demo activo es el de la DB actual (primera fila activa en `demos` o valores en `settings`). Así, **cambiar DB = cambiar demo y módulos** sin tocar código.

4. **Comandos y seeders son por proyecto**: Cualquier comando que modifique configuración (p. ej. `cd-system:enable-menu-module`) o que ejecute seeders actúa sobre la **DB actual**. Al cambiar a otra DB y ejecutar seeders o comandos, se afecta solo a ese proyecto.

Tras cambiar `DB_DATABASE`, ejecutar: `php artisan config:clear && php artisan cache:clear` (y opcionalmente `CdSystemConfigService::clearCache()` / `SiteConfigService::clearCache()` si se usan). Ver [TROUBLESHOOTING-CAMBIO-DB.md](../saas/TROUBLESHOOTING-CAMBIO-DB.md).

## Documentación Relacionada

- [docs/saas/](../saas/) - Implementación multi-tenant desde DB
- [01-arquitectura-cms-multitenant.md](01-arquitectura-cms-multitenant.md) - Visión general