# Anatomía de un demo (en cd-frontend-dev) > **Audiencia**: devs frontend que trabajan en `cd-frontend-dev`. > **Fuente de verdad backend**: `../product-readiness/estandar-demo.md` — incluye registros backend (helpers, config) que el dev frontend NO toca. > **Última actualización**: 2026-05-04 Este doc explica qué archivos componen un demo "completo" desde la perspectiva del repo `cd-frontend-dev`: qué se sincroniza, qué se monta como volume y qué reglas seguir al editar. --- ## Lo mínimo que debe existir por demo (9 archivos) Tomemos `demo-restaurant` como referencia. Un demo "completo" implica estos archivos en `cd-frontend-dev`: ``` 1. resources/views/modules/cd-base/frontend/demos/demo-restaurant/welcome.blade.php 2. resources/views/modules/cd-base/frontend/demos/demo-restaurant/about.blade.php 3. resources/views/modules/cd-base/frontend/demos/demo-restaurant/contact.blade.php 4. resources/views/layout/front/headers/demo-restaurant.blade.php 5. resources/views/layout/front/footers/demo-restaurant.blade.php 6. resources/views/layout/front/partials/page-header-restaurant.blade.php ← sin prefijo "demo-" 7. public/template/css/demos/demo-restaurant.css 8. public/template/css/skins/skin-restaurant.css 9. public/template/js/demos/demo-restaurant.js ← OPCIONAL (no todos lo tienen) ``` Plus 5 partials defaults compartidos por TODOS los demos (no se duplican): ``` resources/views/layout/front/partials/_header.blade.php ← orquestador (decide qué header cargar) resources/views/layout/front/partials/_footer.blade.php ← orquestador del footer resources/views/layout/front/partials/_styles.blade.php ← carga CSS dinámico + custom properties resources/views/layout/front/partials/_scripts.blade.php ← carga JS resources/views/layout/front/partials/_whatsapp.blade.php ← botón WhatsApp opcional ``` --- ## Tabla de roles por archivo | # | Archivo | Rol | Quién lo edita típicamente | |---|---------|-----|-----------------------------| | 1 | `welcome.blade.php` | Hero + secciones del index del demo | Frontend dev | | 2 | `about.blade.php` | Página interna "Nosotros" | Frontend dev | | 3 | `contact.blade.php` | Página interna "Contacto" | Frontend dev | | 4 | `headers/demo-X.blade.php` | Navegación principal (logo, menú, CTA) | Frontend dev | | 5 | `footers/demo-X.blade.php` | Pie de página (newsletter, links, copyright) | Frontend dev | | 6 | `partials/page-header-X.blade.php` | Banner que aparece en páginas internas (about, contact, blog post, etc.) | Frontend dev | | 7 | `css/demos/demo-X.css` | Layout, typography (sin font-family), componentes, overrides visuales | Frontend dev | | 8 | `css/skins/skin-X.css` | **Solo paleta de colores** como CSS custom properties | Frontend dev | | 9 | `js/demos/demo-X.js` | JS específico (sliders custom, animaciones, etc.) | Frontend dev (raro) | --- ## Cómo se cargan en runtime Cuando un visitor entra a un sitio con `demo-restaurant` activo: ``` 1. Laravel router → renderiza la vista (welcome.blade.php) 2. La vista hereda del layout principal 3. El layout incluye: - _styles.blade.php → carga skin-restaurant.css + demo-restaurant.css + CSS dinámico (fonts del cliente) - _header.blade.php → resuelve a headers/demo-restaurant.blade.php (via get_demo_layout_mapping) - {contenido de la vista (welcome / about / contact)} - _footer.blade.php → resuelve a footers/demo-restaurant.blade.php - _scripts.blade.php → carga JS vendor + demo-restaurant.js si existe - _whatsapp.blade.php (si está habilitado en config del proyecto) ``` --- ## Reglas críticas (NO romper) ### 1. Nunca hardcodees fonts en demo CSS ```css /* ❌ MAL */ html.demo-restaurant body { font-family: "Helvetica", sans-serif !important; } /* ✅ BIEN */ html.demo-restaurant body { font-weight: 300; line-height: 1.6; } ``` Las fonts las controla el cliente desde el panel admin de cada proyecto. Si las hardcodeás, el cliente pierde la editabilidad. ### 2. Scope todo bajo `html.demo-` ```css /* ❌ MAL — afecta a todos los demos */ .hero-cta { background: red; } /* ✅ BIEN — solo afecta al demo restaurant */ html.demo-restaurant .hero-cta { background: var(--primary); } ``` ### 3. Skin = solo colores. Demo CSS = layout + componentes + overrides ```css /* ✅ skin-restaurant.css */ :root { --primary: #c8a165; --primary-100: #d4b485; --secondary: #2c1810; /* etc. */ } /* ❌ skin-restaurant.css — NO mezclar layout */ .btn { padding: 12px 24px; border-radius: 4px; } ``` ### 4. Usá CSS variables, no hex literales en demo CSS ```css /* ❌ MAL */ html.demo-restaurant .navbar { background: #c8a165; } /* ✅ BIEN */ html.demo-restaurant .navbar { background: var(--primary); } ``` Razón: cada cliente puede personalizar la paleta desde admin sin tocar el demo CSS. Si hardcodeás hex, rompés la editabilidad multi-tenant. --- ## Demos activos en cd-frontend-dev (al 2026-05-04) 18 demos activos. Cada uno tiene los 9 archivos del listado (algunos sin JS custom, algunos sin page-header): | Demo | Header | Footer | Page-header | CSS | Skin | JS | |------|--------|--------|-------------|-----|------|-----| | demo-accounting-1 | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | | demo-accounting-2 | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | | demo-architecture-2 | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | | demo-business-consulting | ✅ | ✅ | ✅ | ✅ | ✅ | — | | demo-construction | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | | demo-construction-2 | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | | demo-creative-agency-2 | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | | demo-creative-portfolio | ✅ | ✅ | — | ✅ | — ⚠️ | — | | demo-digital-agency-2 | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | | demo-insurance | ✅ | ✅ | ✅ | ✅ | ✅ | — | | demo-law-firm-2 | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | | demo-marketing-1 | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | | demo-photography-3 | ✅ | ✅ | ✅ | ✅ | ✅ | — | | demo-product-landing | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | | demo-real-estate | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | | demo-restaurant | ✅ | ✅ | ✅ | ✅ | ✅ | — | | demo-sass | ✅ | ✅ | ✅ | ✅ | ✅ | — | | demo-transportation-logistic | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ⚠️ `demo-creative-portfolio` no tiene `page-header-creative-portfolio.blade.php` ni `skin-creative-portfolio.css` propios — usa fallback. Pendiente decidir si se completa. --- ## Cómo agregar un demo nuevo > **No es lo común** — coordinar con maintainer de cd-system primero porque hay registros backend a crear. 1. **Maintainer (en `cd-system`)** crea los registros backend: - `app/helpers.php` → `get_demo_layout_mapping()` agrega la entrada - `app/helpers.php` → `get_demo_skin_mapping()` agrega la entrada - `config/page-headers.php` agrega el partial name - 10 dynamic-headers (services, blog, gallery, etc.) agregan `@elseif` para el demo 2. **Frontend dev (en `cd-frontend-dev`)** crea los archivos visuales (los 9 del listado). 3. Push a `cd-frontend-dev/main` → el sync workflow detecta cambios en `resources/**` y `public/**` → abre/actualiza el PR `frontend-sync/pending` en cd-system. 4. Maintainer mergea las 3 etapas (`staging-frontend → main → cd-system`) → demo disponible en producción. > Si solo vas a **modificar** un demo existente, NO necesitás registrar nada — directamente editás los archivos. --- ## Referencias - Estándar técnico completo (incl. registros backend): [`../product-readiness/estandar-demo.md`](../product-readiness/estandar-demo.md) - Setup y comandos del día a día: [`guia-de-uso.md`](guia-de-uso.md) - Cómo se sincroniza con cd-system: [`sync-architecture.md`](sync-architecture.md) - Flujo de PRs end-to-end (3 etapas): [`../infrastructure/06-frontend-pr-workflow.md`](../infrastructure/06-frontend-pr-workflow.md)