# PROMPT MAESTRO PARA CLAUDE CODE — Innovium

> **Cómo usar este prompt:**
> 1. Abre Claude Code en la raíz del proyecto Innovium (donde harás el desarrollo).
> 2. Asegúrate de que la carpeta `design-kit/` está en el repo (este kit completo).
> 3. Pega TODO el contenido de abajo (desde la línea `---` hasta el final) como tu primer mensaje.
> 4. Claude Code va a leer los archivos del design system y los mockups antes de empezar.
> 5. Trabajen iterativamente: una pantalla a la vez, validar visualmente cada una contra su mockup.

---

# Contexto del proyecto

Estoy construyendo **Innovium**, un SaaS multi-tenant para funerarias en Chile. Reemplaza un sistema PHP 7.4 legacy con problemas serios (inyección SQL, validación cliente bypasseada). El producto pertenece a **Crono Systems** (Santiago) y el primer tenant será una funeraria que ya opera con el sistema viejo, así que migraremos sus datos.

El diseño visual de Innovium **ya está cerrado**. Lo decidimos en una sesión previa de mockups y no se va a improvisar. La estética es **dark mode hero + light mode soportado**, en la liga visual de Linear / Vercel / Stripe / Arc / Raycast — glassmorphism, mesh gradients, Georgia para titulares, paleta violeta/cyan/pink/green/orange, bordes redondeados 16-24px, sombras suaves multi-capa, iconos lineales finos.

# Antes de escribir una sola línea de código

**Lee, en este orden, los siguientes archivos del repo y NO empieces a codear hasta haberlos leído completos:**

1. `design-kit/DESIGN_SYSTEM.md` — manual de diseño completo (paleta, tipografía, componentes, anti-patterns). **Source of truth visual.**
2. `design-kit/tailwind.config.js` — tokens listos para usar.
3. `design-kit/theme.css` — variables y utility classes globales.
4. `design-kit/mockups/v2_login.svg` — mockup del login (es la pantalla más representativa de la estética)
5. `design-kit/mockups/v2_dashboard.svg` — mockup del dashboard (sidebar, KPI cards, charts)
6. `design-kit/mockups/v2_contrato.svg` — mockup del contrato (split light/dark, signature canvas)

Los SVG son la **fuente visual canónica**. Cuando implementes una pantalla, abre el SVG correspondiente, replica colores hex exactos, espaciados, jerarquía tipográfica y composición. La improvisación es el enemigo de la consistencia visual.

# Stack técnico

Backend:
- **PHP 8.2+** con MVC custom ligero (sin Laravel ni Symfony)
- **MySQL 8 / MariaDB** con InnoDB + utf8mb4
- **PDO** con prepared statements obligatorios (NUNCA concatenación SQL)
- **Multi-tenant Modelo A**: una BD por funeraria (`innovium_<slug>`) + BD maestra `innovium_master`
- **Cloudflare R2** para storage, un único bucket con segregación por path `/tenants/{slug}/...`

Frontend:
- **Vanilla JS + Alpine.js** para interactividad (nada de React/Vue para el SPA principal)
- **Tailwind CSS** para estilos, con la config de `design-kit/tailwind.config.js`
- **Lucide Icons** (SVG inline o `lucide-static`) para iconografía
- **ApexCharts** para gráficos (donut, área, barras) — configurado con la paleta de marca
- **PWA** con Service Worker + IndexedDB para soporte offline
- **Mobile app companion** (ya existe, está en otro repo `yedistribuciones-frontend` adaptado): React Native/Expo, también debe seguir este design system

Hosting: VPS HostGator reseller (WHM/cPanel), wildcard SSL `*.innovium.cl`, subdominios por tenant (`acoger.innovium.cl`, `lirio.innovium.cl`, etc.).

# Reglas de oro del proyecto

1. **Seguridad sobre velocidad.** El sistema legacy tenía SQL injection. Acá: PDO prepared statements siempre, validación server-side obligatoria, escape de output, CSRF en todos los forms, RBAC en cada controller action.
2. **Aislamiento de tenants es sagrado.** Nunca un query puede mezclar datos entre funerarias. El TenantResolver en el front controller decide la conexión BD por subdominio. Storage prefijo automático.
3. **Estética FIJA.** No agregar colores nuevos, no usar fuentes distintas a Georgia/system-sans/JetBrains Mono, no inventar componentes que no existan en el design system. Si algo nuevo es necesario, se documenta primero en `DESIGN_SYSTEM.md` y luego se implementa.
4. **Mobile/tablet first donde aplica.** Las pantallas que el vendedor usa en terreno (crear contrato, capturar firma) deben funcionar perfectas a 1024×768 portrait y a 375px mobile.
5. **Offline matters.** Las acciones críticas del vendedor (crear contrato, capturar firma) deben poder hacerse sin red, encolar, y sincronizar cuando vuelva la conexión.
6. **Auditoría de todo.** Cada acción mutativa va a `audit_log` con usuario, IP, timestamp, antes/después.

# Estructura de carpetas propuesta

```
/innovium-v2
  /public
    index.php           ← front controller único
    /assets             ← compiled CSS/JS, fuentes
  /app
    /Core               ← Router, Container, TenantResolver, Auth, CSRF, Storage gateway
    /Controllers        ← uno por módulo
    /Models             ← PDO models
    /Services           ← lógica de negocio (no en controllers)
    /Views              ← templates PHP / partials
    /Middleware         ← auth, csrf, rbac
  /resources
    /css                ← input para Tailwind, importa theme.css
    /js                 ← Alpine components, utilities
    /views              ← Blade-like simple templating o PHP plano
  /design-kit           ← este kit (NO modificar sin actualizar el documento)
  /database
    /migrations         ← SQL versionado
    /seeds              ← datos de prueba
  /scripts              ← CLI: tenant:create, tenant:seed, etc.
  /storage              ← uploads temporales antes de subir a R2
  /tests
  .env.example
  CLAUDE.md             ← instrucciones para esta misma sesión y futuras
  ARQUITECTURA.md       ← decisiones técnicas
  composer.json
  package.json          ← Tailwind + build tools
  tailwind.config.js    ← extiende design-kit/tailwind.config.js
  README.md
```

# Lo que NO debes hacer

- ❌ No usar Bootstrap, AdminLTE, Material UI, Tailwind UI premium components, ni cualquier framework de componentes pre-fabricados. Construimos componentes desde cero siguiendo el design system.
- ❌ No instalar React, Vue, Svelte ni ningún framework SPA pesado. Vanilla JS + Alpine es suficiente.
- ❌ No improvisar paletas de colores. Si te tienta usar `#3B82F6` o cualquier azul corporativo de banco, **te equivocaste**. Los azules de Innovium son cyan vibrante (`#22D3EE` / `#0891B2`).
- ❌ No usar Inter como display font. Inter es para body. Display = Georgia.
- ❌ No agregar emojis a UI funcional (botones, navegación, labels de tabla). Sí están permitidos como decoración aspiracional en marketing/landing.
- ❌ No copiar y pegar este prompt en commits, comentarios de código ni mensajes a otros sistemas. Es interno.
- ❌ No mostrar credenciales, RUTs reales, ni datos de la funeraria legacy en mocks o fixtures. Usar datos sintéticos siempre.

# Plan de trabajo recomendado (fases)

**Fase 0 · Setup (1 sesión)**
- Crear estructura de carpetas
- `composer.json`, `package.json`, `.env.example`
- Tailwind compilando, importando `design-kit/theme.css` y extendiendo `design-kit/tailwind.config.js`
- `public/index.php` front controller mínimo
- `app/Core/Router.php`, `app/Core/Container.php` básicos
- `CLAUDE.md` con instrucciones de la sesión y `ARQUITECTURA.md` con decisiones
- README del proyecto

**Fase 1 · Multi-tenancy core (1-2 sesiones)**
- BD maestra: schema + migración inicial con tabla `tenants`
- `TenantResolver` que lee subdominio y resuelve conexión BD
- `Storage` gateway con driver R2 + prefijo automático `/tenants/{slug}/`
- CLI `bin/innovium tenant:create <slug>` que crea BD + bucket folder + admin inicial
- Tests del aislamiento (un tenant nunca puede leer datos de otro)

**Fase 2 · Auth + RBAC (1 sesión)**
- Login con la pantalla del mockup `v2_login.svg` (replicar exacto)
- Sesiones, CSRF tokens, password hashing (Argon2id)
- Roles: superadmin (Crono Systems), tenant_admin, gerente, vendedor, operativo, contador
- Middleware de auth en cada controller

**Fase 3 · Layout principal + Dashboard (1-2 sesiones)**
- Replicar `v2_dashboard.svg` exacto: sidebar, topbar, KPI cards, charts, tabla
- ApexCharts configurado con la paleta de marca
- Tema toggle dark/light persistente

**Fase 4 · Módulo de contratos (2-3 sesiones)**
- Lista de contratos
- Wizard multi-step (replicar `v2_contrato.svg`): contratante → fallecido → servicio → pago → firma → PDF
- Signature canvas (HTML5 canvas, capture path, render gradient stroke purple)
- Generación de PDF con plantilla del tenant
- Subida de firma + PDF a R2 con metadata SHA-256

**Fase 5 en adelante** — cobranzas, operaciones, acompañamiento al duelo, bodega, personal, etc. Una fase = un módulo.

# Cómo trabajar conmigo

- **Iterativo y visual.** Después de implementar cada pantalla, mostrarme un screenshot o pedirme verificar el navegador. Comparar lado a lado contra el SVG.
- **Pregunta cuando dudes.** Si la decisión afecta arquitectura, seguridad o estética, preguntar antes de codear.
- **Documenta a medida que avanzas.** `CLAUDE.md` y `ARQUITECTURA.md` deben quedar actualizados.
- **Tests donde duela.** No exigiré 100% de coverage, pero sí tests para: TenantResolver, Storage gateway, validación de RUT, generación de cuotas, cálculo de comisiones, y cualquier punto donde un bug puede facturar mal.
- **Commits atómicos en español.** Mensajes claros, ej: `feat(auth): login con tenant resolver y CSRF`. Nada de "wip" ni "fix".

# Primera tarea concreta

Cuando termines de leer todo el design-kit, contesta confirmando estos 4 puntos:

1. ¿Entendiste la paleta exacta y vas a respetar los hex codes? (sin azules corporativos, sin grises Bootstrap)
2. ¿Vas a usar Georgia como display y NO Inter para titulares?
3. ¿Vas a construir componentes desde cero con Tailwind + theme.css, sin instalar libraries de componentes?
4. ¿Cuál fase te tinca empezar primero, fase 0 (setup) o saltamos directo a algo concreto?

Después de tu confirmación, arrancamos con la fase que decidamos.

---

**Crono Systems · Innovium · 2026**
*Build it the way it deserves to be built.*