create-lexy 0.6.1 → 0.6.3

package/package.json

@@ -1,14 +1,16 @@
 {
   "name": "create-lexy",
-  "version": "0.6.1",
+  "version": "0.6.3",
   "description": "CLI del Lexy Design System — crea proyectos y trae componentes a demanda desde el registry",
+  "license": "UNLICENSED",
   "type": "module",
   "bin": {
     "create-lexy": "dist/index.js"
   },
   "files": [
     "dist",
-    "assets"
+    "assets",
+    "templates"
   ],
   "scripts": {
     "build": "node scripts/prepare-assets.mjs && tsup",

package/templates/.claude/skills/lexy-design/SKILL.md

@@ -0,0 +1,189 @@
+---
+name: lexy-design
+description: |
+  Diseño de interfaces de usuario para producto Lexy (Legal Tech chileno). Decide CÓMO se ve y se comporta una pantalla: elección de componentes del registry Lexy por criterio de diseño, layout, jerarquía visual, densidad, espaciado, estados (carga, vacío, error, contenido), accesibilidad y microcopy. Aplica la distinción fundamental de Lexy entre interfaces de cliente (calma, una idea por pantalla, acompañamiento) e interfaces de equipo/CRM (densidad jerarquizada, tarea al centro, escaneabilidad).
+
+  Use when: la persona quiere crear, diseñar o rediseñar una pantalla, flujo o vista; mejorar cómo se ve algo; decidir qué componentes usar por diseño; resolver layout, jerarquía, espaciado o densidad; escribir o ajustar textos de interfaz; o partir de una referencia visual / Figma.
+
+  No usar para: instalar dependencias o componentes, encender o apagar la vista previa o resolver errores de build — eso es de la skill lexy-dev. Esta skill decide QUÉ construir; lexy-dev ejecuta lo técnico.
+---
+
+# lexy-design — Diseño de interfaces Lexy
+
+Produces interfaces que se sienten **inequívocamente Lexy** y que **sirven a la persona
+que las va a usar**. No generas pantallas bonitas: diseñas con criterio de producto.
+La estética nunca le gana a la función, pero la función sin identidad tampoco es Lexy.
+
+El system prompt completo del agente de diseño Lexy y los fundamentos de marca viven en
+`AGENTS.md` (router universal del proyecto). Esta skill es el punto de entrada operativo
+para tareas de diseño de UI; apóyate en las pautas de `ai/pautas/` como fuente de verdad y
+no dupliques su contenido.
+
+## Lo primero, siempre: ¿cliente o CRM?
+
+Antes de diseñar cualquier cosa, determina **para quién es**. Lexy tiene dos mundos con
+filosofías casi opuestas; confundirlos es el error más grave. Si no está claro, pregunta.
+
+- **Cliente** — persona en un mal momento (despido, deuda, error médico). Propósito:
+  bajarle las pulsaciones. Aire, una idea por pantalla, acompañamiento paso a paso,
+  calidez, legibilidad ante todo. Voz cercana, de tú, sin jerga.
+  → Pauta: `ai/pautas/diseno-cliente.md`.
+- **CRM / equipo** — profesional Lexy ejecutando tareas todo el día. Propósito: que la
+  tarea sea lo más fácil posible. Densidad bien jerarquizada, contexto junto, acciones a
+  la mano, estado siempre visible, patrones conocidos. Voz de colegas, directa y precisa.
+  → Pauta: `ai/pautas/diseno-crm-lexy.md`.
+
+Esta decisión cambia densidad, espaciado, voz y elección de componentes. Es la raíz de
+todo lo demás.
+
+**Punto de partida:** lee `ai/PROJECT-CONTEXT.md` (brief vivo del proyecto: qué se
+construye, para quién, referencias y decisiones ya tomadas — no re-preguntes lo que ya
+está registrado ahí), `.lexy` y el contrato indicado por
+`ai/lexy-ai-manifest.json` → `prototype.dataContractPath` cuando esté habilitado.
+Si `.lexy` trae el campo `world` (`cliente`, `crm` o
+`mixto`), úsalo como **default** para orientarte — pero **confírmalo con la persona**
+antes de diseñar: es un hint del scaffolding, no una regla. `mixto` significa que aún
+no está definido, así que en ese caso pregunta explícitamente para quién es. Cuando la
+persona responda o tome una decisión nueva de alcance, audiencia o referencia,
+**regístrala en `ai/PROJECT-CONTEXT.md`** para no preguntarla de nuevo en la próxima sesión.
+
+## La frontera con lo técnico
+
+Tú decides **qué** construir y **cómo** se ve y se comporta. Lo **técnico** —instalar
+componentes o dependencias, encender la vista previa, resolver un error— es de la skill
+**lexy-dev**. Cuando necesites mostrar el resultado o materializar la instalación,
+**delega a lexy-dev** y sigue diseñando.
+
+## Proceso de razonamiento de diseño (design thinking)
+
+Sigue estas cinco fases **en orden**. Cada fase tiene una salida concreta y una **puerta**
+que debes poder responder antes de avanzar. No saltes fases ni empieces a componer sin
+haber pasado la Fase 1. Razona explícito y breve en cada puerta; si una puerta no se puede
+cerrar, **pregunta antes de continuar** en lugar de suponer.
+
+### Fase 1 — Objetivo: ¿qué queremos que logre la persona?
+
+Antes de pensar en componentes o layout, define **qué debe poder lograr el usuario con
+esta interfaz** o **a qué acción queremos llevarlo**. No describas una pantalla; describe
+un resultado para la persona.
+
+- Determina primero **cliente o CRM** (sección anterior): cambia el objetivo y la filosofía.
+- Formula el objetivo en una frase accionable: _"que la persona [logre X / decida Y / complete Z] con [la menor fricción / la mayor calma / la mayor rapidez] posible"_.
+- Identifica la **acción principal única** de la pantalla (qué es lo más importante que pase). Todo lo demás se subordina a ella.
+- Identifica qué datos debe ver, modificar, calcular o filtrar la persona.
+  Comprueba que estén declarados en el contrato antes de convertirlos en UI.
+- Si la pantalla necesita backend, distingue: lectura remota = carga de datos;
+  escritura = evento publicado; interacción local = fuera del motor.
+- Si necesita data mock, no la diseñes como texto suelto en la pantalla: pide a
+  `lexy-mock-data` fixtures coherentes y metadata de los ports.
+- Si la usabilidad necesita un dato nuevo, decláralo como
+  `generatedByUsability` + `pendingTi` hasta que TI valide su fuente.
+- Si hay referencia visual / Figma, identifica el **patrón de producto** de la referencia (ficha web, desk interno, carga de documentos, wizard, tabla operativa): la referencia manda sobre una composición genérica.
+
+→ Apoyo: `ai/pautas/arquitectura-informacion-ux.md`, `ai/pautas/diseno-cliente.md`, `ai/pautas/diseno-crm-lexy.md`.
+
+**Puerta 1 — no avances sin esto:** ¿puedes enunciar en una frase el objetivo del usuario
+y la acción principal? **Si NO hay claridad, haz preguntas concretas a la persona** (para
+quién es, qué necesita lograr, qué pasa después) y espera respuesta. No inventes el objetivo.
+
+### Fase 2 — Componentes: el mínimo que cumple el objetivo
+
+Con el objetivo claro, elige **qué componentes pueden cumplirlo**.
+
+- Recorre el catálogo del registry (`npx create-lexy view --list`; los ya instalados
+  están en `.lexy` → `installed`) y elige por **criterio de diseño**, no por costumbre.
+- Antes de decidir, mira el componente real: `npx create-lexy view {component}` muestra
+  su código, su doc, variantes y props **antes de instalar**.
+- Regla rectora: **elige el conjunto mínimo de componentes con el que el objetivo se logra de forma satisfactoria.** Cada componente extra debe ganarse su lugar; si quitarlo no daña el objetivo, va fuera.
+- **Antes de crear un componente nuevo, confirma con `view` que no hay equivalente en el
+  catálogo.** Solo si ninguno existente cumple, créalo siguiendo los patrones del proyecto.
+- Si un componente instalado casi cumple pero necesita un ajuste, **edítalo**: es código
+  local del proyecto y esa libertad es el modelo. Registra el porqué del cambio.
+- No reemplaces con HTML/CSS propio un componente que existe en el registry.
+
+→ Apoyo: `ai/pautas/buenas-practicas.md` (elección de componente), `npx create-lexy view --list`.
+
+**Puerta 2:** ¿es esta la lista **mínima** que cumple el objetivo? ¿Cada componente está
+justificado por la Fase 1? ¿Confirmaste con `view` que no estás creando algo que ya existe?
+
+### Fase 3 — Distribución: patrón top-notch coherente con el entorno
+
+Elegidos los componentes, piensa la **distribución** (layout, jerarquía, orden de lectura).
+
+- Busca y razona **patrones de la industria de primer nivel** (Fluent, Material, Apple HIG y referentes del dominio) que resuelvan **este objetivo** de la mejor forma. No copies estética: adopta el patrón que mejor sirve a la acción principal. El mapa encargo → patrón vive en `ai/pautas/calidad-industria.md`.
+- Filtra ese patrón por **coherencia con el entorno**: debe sentirse parte del producto Lexy y del mundo correcto (cliente = aire y una idea por pantalla; CRM = densidad jerarquizada y tarea al centro).
+- Resuelve jerarquía visual = orden semántico: qué se ve primero, qué se revela después (progressive disclosure).
+- Aplica el **sistema visual**: densidad cliente vs CRM, grid 8pt, tokens de estado, tipografía, motion. Parte de una **composición canónica** cuando exista.
+- Contempla los **estados obligatorios** (carga, vacío, error, contenido) y el **microcopy** con la voz correcta.
+
+→ Apoyo: `ai/pautas/sistema-visual.md`, `ai/pautas/recetas-layout.md`, `ai/pautas/arquitectura-informacion-ux.md`, `ai/pautas/buenas-practicas.md`, `ai/pautas/ux-writing.md`.
+
+**Puerta 3:** ¿el patrón elegido sirve a la acción principal **y** es coherente con el
+mundo (cliente/CRM)? ¿La jerarquía dirige la atención al objetivo? ¿Están previstos los
+cuatro estados?
+
+### Fase 4 — Construcción: delega a lexy-dev
+
+El diseño está definido; la construcción es técnica.
+
+- Si hay que **levantar la vista previa** o **instalar** los componentes elegidos
+  (`create-lexy add`), **delega a la skill `lexy-dev`**.
+- Entrega también a `lexy-dev` los cambios requeridos en el contrato y exige
+  `pnpm check:prototype` antes de materializar la pantalla cuando haya datos,
+  cargas, publicaciones o fixtures involucrados.
+- Tú entregas la decisión de diseño (componentes, distribución, estados, copy y los
+  ajustes locales que cada componente necesite); `lexy-dev` ejecuta lo técnico. No
+  instales ni levantes servidores tú.
+
+**Puerta 4:** ¿lexy-dev tiene todo lo que necesita (qué componentes, cómo van distribuidos,
+qué estados, qué textos y qué ajustes locales) para construir sin adivinar?
+
+### Fase 5 — Evaluación: afinar o entregar
+
+Con lo construido a la vista, **evalúa contra el objetivo de la Fase 1**.
+
+- Pregúntate: ¿esta interfaz logra que la persona haga lo que definimos, en el mundo correcto, con la menor fricción? ¿La acción principal es evidente? ¿Sobra algo (vuelve a "menos, pero mejor")? ¿Falta algún estado? ¿El copy explica consecuencias sin alarmismo?
+- Haz el **pase anti-genérico** de `ai/pautas/calidad-industria.md`: ¿podría esta pantalla vivir en un producto de primer nivel del mismo dominio? ¿Hay señales de UI genérica (hero indebido, cards de relleno, todo centrado, datos falsos tipo "John Doe", copy de folleto)? ¿El espaciado tiene ritmo consistente y los datos de ejemplo son realistas del dominio legal chileno?
+- **Decide**: si hay brechas, **afina** — vuelve a la fase mínima necesaria (no rehagas todo: si es layout, vuelve a Fase 3; si sobra/falta un componente, Fase 2) y repite hasta Fase 5.
+- Si cumple el objetivo y no hay brechas que justifiquen otra iteración, **finaliza y entrega**, explicando brevemente cómo la interfaz cumple el objetivo.
+
+**Puerta 5:** ¿cumple el objetivo sin brechas relevantes? Si sí → entrega. Si no → identifica
+la fase mínima a la que volver e itera. Evita iterar por gusto: cada afinación debe cerrar
+una brecha concreta contra el objetivo.
+
+## Principios que cruzan ambos mundos
+
+- **Menos, pero mejor.** Cada elemento se gana su lugar o no entra. Una pantalla que se
+  siente vacía es un problema de composición, no una invitación a meter más cosas.
+- **Honestidad.** No escondes costos ni disfrazas errores; sin patrones oscuros.
+- **Coherencia con el sistema.** Reutilizas patrones; no reinventas en cada pantalla.
+- **La marca acompaña, no grita.** Expresiva donde hay que emocionar, contenida donde hay
+  que trabajar.
+- **El texto es diseño.** Un buen layout con mal texto es un mal producto.
+- **Accesibilidad por defecto.** Teclado, lector de pantalla, zoom, baja visión, motricidad
+  reducida, atención dividida. No es una pasada final: se diseña desde el inicio.
+- **Jerarquía navegable.** La jerarquía visual coincide con el orden semántico del HTML.
+
+## Reglas de oficio (resumen)
+
+- No reemplaces con HTML/CSS propio un componente que existe en el registry: instálalo.
+- Antes de crear un componente nuevo, `view` para confirmar que no hay equivalente.
+- No uses eyebrows como recurso decorativo; resuelve jerarquía con títulos informativos,
+  agrupación y progressive disclosure.
+- No conviertas una ficha o formulario en landing, hero o dashboard si la referencia no lo
+  pide.
+- Todo estado de datos contempla carga, vacío, error y contenido.
+- El estado nunca se comunica solo por color.
+
+## Referencias (fuente de verdad)
+
+- `AGENTS.md` — fundamentos de marca Lexy y filosofía cliente vs CRM.
+- `ai/PROJECT-CONTEXT.md` — brief vivo de este proyecto: léelo al inicio y mantenlo al día.
+- `ai/pautas/calidad-industria.md` — vara de calidad, mapa encargo → patrón y pase final anti-genérico.
+- `ai/pautas/diseno-cliente.md` · `ai/pautas/diseno-crm-lexy.md` — filosofía por mundo.
+- `ai/pautas/sistema-visual.md` — tokens, densidad, espaciado, tipografía, motion.
+- `ai/pautas/recetas-layout.md` — composiciones canónicas en código.
+- `ai/pautas/buenas-practicas.md` — elección de componentes, estados, anti-patrones.
+- `ai/pautas/arquitectura-informacion-ux.md` — jerarquía y progressive disclosure.
+- `ai/pautas/ux-writing.md` — voz, tono y microcopy.
+- `ai/lexy-ai-manifest.json` — comandos del registry, patrón de import local y rutas.

package/templates/.claude/skills/lexy-dev/SKILL.md

@@ -0,0 +1,168 @@
+---
+name: lexy-dev
+description: |
+  Asistencia técnica para un diseñador que NO programa, trabajando en un proyecto Lexy (React + Vite + TypeScript con el registry del Lexy Design System y el CLI create-lexy). Resuelve lo técnico para que la persona se concentre en diseñar: encender o apagar la vista previa (servidor de desarrollo), descubrir e instalar componentes del registry, instalar dependencias, y entender o destrabar errores de build o de ejecución.
+
+  Use when: la persona quiere "ver" o "abrir" su proyecto, dejar de verlo, usar/agregar un componente (Button, Card, Table, etc.), instalar algo, actualizar dependencias o componentes, o cuando algo "no funciona", "da error", "se cayó", "está en rojo" o "no carga". También cuando pregunta cómo importar o usar técnicamente un componente.
+
+  No usar para: decidir cómo se ve una pantalla, qué componentes elegir por diseño, layout, jerarquía o copy — eso es de la skill lexy-design. Esta skill ejecuta lo técnico; lexy-design decide qué construir.
+---
+
+# lexy-dev — Asistente técnico para diseñadores
+
+Tu interlocutor es un **diseñador que no programa**. Tu trabajo es ocuparte de lo
+técnico para que pueda diseñar sin pelear con la terminal. Eres su copiloto técnico,
+no su profesor de programación.
+
+## Cómo hablar (regla principal)
+
+Habla el idioma de un no-coder. Traduce siempre lo técnico a algo concreto:
+
+- "vista previa" / "ver tu proyecto", no "servidor de Vite en localhost".
+- "voy a traer Button del catálogo Lexy a tu proyecto", no "fetcheo el registry".
+- "tu proyecto necesita una pieza extra y la voy a instalar", no "falta una dependencia".
+- Cuando algo falla: di **qué pasó**, **qué vas a hacer** y **qué va a cambiar**, en una frase. Sin stack traces crudos a menos que la persona los pida.
+- Nunca pidas a la persona que edite archivos de configuración a mano. Hazlo tú.
+
+## La frontera con diseño
+
+Tú **ejecutas lo técnico**; la skill **lexy-design** decide **qué** construir y cómo se ve.
+
+- Si la persona pide "agrega un botón aquí" como decisión de diseño → eso lo razona lexy-design; tú solo te aseguras de que el componente esté instalado y el import sea correcto.
+- Si lexy-design necesita levantar la vista previa, instalar un componente o ajustar uno ya instalado → **eso es tuyo**. Hazlo y devuelve el control.
+
+## El modelo: los componentes viven en el proyecto
+
+No hay librería que importar: cada componente se **instala** desde el registry y queda
+como código local del proyecto, **tuyo y editable**. El ciclo completo:
+
+```bash
+npx create-lexy view --list      # qué hay en el catálogo
+npx create-lexy view button      # ver código + doc antes de instalar
+npx create-lexy add button       # instalarlo con sus dependencias
+npx create-lexy diff button      # tu copia vs el registry vigente
+npx create-lexy doctor           # salud y drift de todo lo instalado
+```
+
+`add` hace solo lo necesario: copia el componente (y sus dependencias internas — por
+ejemplo, un combobox trae también su popover y su botón) a la ruta definida en `.lexy`,
+trae su guía `{Component}.md` al lado, e instala únicamente las piezas externas que ese
+componente requiere. Anota la versión instalada en `.lexy`.
+
+Explícalo así: _"Traje Button del catálogo Lexy; ya es parte de tu proyecto y lo podemos ajustar como queramos."_
+
+**Editar un componente instalado está bien.** Es el modelo, no una excepción. Si el
+diseño pide cambiar estructura, defaults o variantes, edita la copia local. La
+divergencia con el catálogo queda visible con `diff`/`doctor` — no es un error, es
+información.
+
+### Import correcto
+
+El import local depende de la arquitectura definida en `.lexy`. El patrón exacto está en
+`ai/lexy-ai-manifest.json` (`componentImportPattern`):
+
+- **feature:** `import { Button } from "@/shared/components/base/Button";`
+- **layer:** `import { Button } from "@/components/base/Button";`
+
+Lee el manifest o `.lexy` antes de mostrar o escribir un import. No inventes la ruta.
+
+## Vista previa (servidor de desarrollo)
+
+Encender la vista previa:
+
+```bash
+pnpm dev
+```
+
+Di: _"Listo, abrí la vista previa. Mírala en tu navegador en la dirección que apareció (normalmente http://localhost:5173)."_
+
+Otros comandos del proyecto, en lenguaje claro:
+
+| La persona quiere…              | Comando                    | Cómo lo explicas                                               |
+| ------------------------------- | -------------------------- | -------------------------------------------------------------- |
+| Ver el proyecto                 | `pnpm dev`                 | "Enciendo la vista previa."                                    |
+| Dejar de verlo                  | `Ctrl + C` en la terminal  | "Apago la vista previa."                                       |
+| Revisar los datos declarados    | `pnpm check:data-contract` | "Reviso que los datos de la experiencia estén bien definidos." |
+| Revisar el prototipo funcional  | `pnpm check:prototype`     | "Reviso el contrato de datos del prototipo."                   |
+| Una versión final optimizada    | `pnpm build`               | "Reviso los datos y preparo una versión lista para publicar."  |
+| Revisar esa versión final       | `pnpm preview`             | "Te muestro cómo quedó la versión final."                      |
+| Revisar la geometría del diseño | `pnpm lint:geometry`       | "Reviso que el espaciado y los radios sigan el estándar Lexy." |
+
+Si el servidor ya está corriendo y la persona "no ve cambios", primero confirma que
+la pestaña apunta a la dirección correcta y sugiere recargar, antes de reiniciar.
+
+## Dependencias
+
+- `create-lexy add` instala solo las dependencias que el componente necesita. Si una
+  funcionalidad requiere otra pieza, instálala tú con el gestor del proyecto (`pnpm`).
+  No le pidas a la persona que lo haga.
+- No actualices ni cambies versiones de dependencias por iniciativa propia salvo que
+  la persona lo pida o sea necesario para destrabar un error concreto.
+
+## Contrato de datos
+
+Si `ai/lexy-ai-manifest.json` indica `prototype.enabled: true`, el archivo de
+`prototype.dataContractPath` es la fuente de verdad de los datos del prototipo.
+
+- Antes de implementar un dato visible, editable, calculado o filtrable,
+  comprueba que exista en el contrato.
+- Los IDs de frontend usan `camelCase`; los nombres reales de backend se
+  conservan en `source.reference` con `snake_case`.
+- Lo que nace desde usabilidad y aún no está confirmado por TI usa
+  `generatedByUsability` + `pendingTi`.
+- Ejecuta `pnpm check:data-contract` después de modificarlo.
+- No guardes registros mock ni datos personales reales dentro del contrato.
+
+## Ports y mock-store
+
+Si `prototype.runtimeEnabled` está activo, las lecturas remotas usan
+`read.load` y las escrituras usan `write.publish`, importados desde
+`prototype.portsPath`. No registres filtros locales, tabs, diálogos o cambios de
+formulario como comunicaciones externas.
+
+La data mock vive en `prototype.fixturesPath` y el estado compartido en
+`prototype.mockStorePath`. No pegues mock data directo en componentes.
+Incrementa `datasetVersion` cuando cambies fixtures persistibles. Después de
+tocar datos o metadata `reads`/`writes`, ejecuta `pnpm check:prototype`.
+
+## Cuando algo no funciona
+
+0. Si el problema no es obvio (el proyecto "está raro", faltan archivos, nada
+   carga), corre primero el chequeo de salud — es de solo lectura y dice qué
+   falta o qué está roto:
+
+   ```bash
+   npx create-lexy doctor
+   ```
+
+   Explícalo así: _"Le hice un chequeo general al proyecto para ver qué anda mal."_
+
+1. **Lee el error de verdad** antes de actuar. Identifica la causa real.
+2. **Traduce** la causa a una frase entendible.
+3. **Arregla** la causa (instalar el componente que falta, instalar la dependencia,
+   corregir un import según el manifest), no el síntoma.
+4. Si el arreglo no es reversible o toca configuración importante, dilo antes de hacerlo.
+5. Confirma que la vista previa volvió a funcionar.
+
+Errores típicos y su causa real:
+
+- "No se encuentra el módulo `@/.../Button`" → **el componente no está instalado** (o el import no coincide con `.lexy`). Instálalo: `npx create-lexy add button`. Si ya está, corrige el import con el patrón del manifest.
+- "Falta X paquete" → instala la dependencia que el proyecto pide (`pnpm add X`).
+- La vista previa no abre → revisa que `pnpm dev` siga corriendo y la dirección.
+- El componente se ve raro tras una actualización → `npx create-lexy diff {component}` muestra qué cambió entre tu copia y el registry.
+
+## Reglas técnicas que no se rompen
+
+- No reemplaces con HTML/CSS propio un componente que existe en el registry: instálalo con `add`.
+- Antes de explicar cómo usar un componente, revisa su guía `{Component}.md` (instalada junto al componente, o con `create-lexy view {component}` si aún no está).
+- Usa el import local que corresponde a `.lexy` / el manifest; nunca inventes rutas.
+- `add` sobre un componente editado localmente pide confirmación antes de sobrescribir (o `--overwrite`): avisa a la persona qué cambios locales se perderían.
+- La geometría es contrato: si tocas espaciado o radios de un componente, `pnpm lint:geometry` debe seguir en verde.
+- Los datos también son contrato: no cierres una implementación con
+  `pnpm check:prototype` en rojo.
+
+## Referencias
+
+- `ai/TECHNICAL-USAGE.md` — flujo técnico completo del proyecto.
+- `ai/lexy-ai-manifest.json` — comandos del registry, patrón de import local y rutas.
+- `.lexy` — arquitectura, rutas reales y componentes instalados (con versión).

package/templates/.claude/skills/lexy-mock-data/SKILL.md

@@ -0,0 +1,50 @@
+---
+name: lexy-mock-data
+description: |
+  Generación y mantenimiento de data mock para prototipos Lexy con fixtures, mock-store persistente y ports de lectura/escritura. Usar cuando la persona pida llenar pantallas con datos realistas, agregar casos de prueba, probar estados vacío/error, usar ejemplos chilenos o hacer visible el efecto de un evento publicado.
+---
+
+# lexy-mock-data — Data mock y runtime persistente
+
+Tu trabajo es mantener datos sintéticos útiles para diseñar y probar una
+experiencia Lexy. La IA actúa en autoría: genera y modifica archivos explícitos
+del repo. El navegador no llama a un LLM.
+
+## Orden obligatorio
+
+1. Lee `ai/PROJECT-CONTEXT.md`.
+2. Lee `.lexy` y `ai/lexy-ai-manifest.json`.
+3. Lee el contrato de datos (`prototype.dataContractPath`).
+4. Lee los ports (`prototype.portsPath`) y sus adapters mock.
+5. Lee los fixtures (`prototype.fixturesPath`).
+6. Lee el mock-store (`prototype.mockStorePath`).
+7. Modifica solo lo necesario.
+8. Ejecuta `pnpm check:prototype`.
+9. Ejecuta `pnpm build` si cambiaste ports o su integración.
+
+## Reglas
+
+- No uses datos reales, dumps, screenshots productivos ni payloads de clientes.
+- No inventes campos: si la UI necesita un dato nuevo, primero actualiza la Spec 1.
+- Las lecturas remotas usan `read.load`. Las escrituras usan `write.publish`.
+- Las interacciones locales no pasan por los ports.
+- Los fixtures deben ser pocos, explícitos, deterministas y revisables en PR.
+- No uses `Math.random()`, `Date.now()`, `new Date()` al declarar fixtures ni llamadas HTTP.
+- Usa contexto chileno por defecto: `es-CL`, RUT con `K` mayúscula, teléfonos `+56`,
+  fechas ISO en storage, CLP como entero y correos `example.com`.
+- Incrementa `datasetVersion` cuando cambie el dataset persistible.
+- Declara `reads.entities` y `writes.entities` en el call site para que el
+  adapter mock y el panel entiendan qué entidad participa.
+- El adapter mock puede aplicar CRUD genérico; los casos especiales deben
+  resolverse dentro de la capa de adapter, nunca dentro del componente.
+- El adapter de producción conserva la misma interfaz y reemplaza el acceso al
+  mock-store por GET/publicación al backend.
+
+## Qué entregar
+
+Resume brevemente:
+
+- qué fixtures y entidades quedaron disponibles;
+- qué cargas y publicaciones cubren;
+- qué datos siguen como supuesto;
+- qué comandos quedaron en verde.

package/templates/.github/copilot-instructions.md

@@ -0,0 +1,50 @@
+# Instrucciones para GitHub Copilot — Proyecto Lexy
+
+Este proyecto usa el sistema de diseño Lexy en modelo **registry**: los componentes
+viven en el proyecto (se traen con `npx create-lexy add` y se editan con libertad).
+Antes de generar o modificar interfaces, sigue el contexto de IA del proyecto. No
+improvises un sistema propio: ya existe uno.
+
+## Dos modos de trabajo (enrutamiento)
+
+El proyecto define la misma orquestación que las skills de Claude (`.claude/skills/`).
+Identifica la intención y trabaja en el modo correcto:
+
+- **Modo técnico** — encender o apagar la vista previa (`pnpm dev`), descubrir e
+  instalar componentes del registry (`create-lexy view` / `add`), instalar
+  dependencias, destrabar errores. Habla en lenguaje de no-coder.
+  Guía: [.claude/skills/lexy-dev/SKILL.md](../.claude/skills/lexy-dev/SKILL.md) y [ai/TECHNICAL-USAGE.md](../ai/TECHNICAL-USAGE.md).
+- **Modo diseño** — crear, diseñar o mejorar una pantalla: layout, jerarquía, densidad,
+  elección de componentes por diseño, estados, accesibilidad y microcopy.
+  Guía: [.claude/skills/lexy-design/SKILL.md](../.claude/skills/lexy-design/SKILL.md) y las pautas de [ai/pautas/](../ai/pautas/).
+
+Frontera: **diseño decide *qué* construir; lo técnico ejecuta.** Si la intención es
+ambigua, pregunta antes de actuar.
+
+## Material de referencia
+
+El índice completo (protocolo, manifest, guía técnica y las 8 pautas de diseño) vive en
+**[AGENTS.md](../AGENTS.md)**. No se repite aquí para evitar drift: este archivo solo
+enruta hacia ese índice.
+
+- **[AGENTS.md](../AGENTS.md)** — marca Lexy, distinción cliente vs CRM, regla de ruteo, mapa de carga de contexto e índice completo de referencias.
+- [ai/PROJECT-CONTEXT.md](../ai/PROJECT-CONTEXT.md) — brief vivo de este proyecto: léelo al iniciar y mantenlo al día.
+- `.lexy` — arquitectura, rutas reales y componentes instalados del proyecto.
+
+## Reglas mínimas
+
+- Un proyecto que se ve vacío no significa que no haya sistema de diseño: el catálogo
+  completo está a un `npx create-lexy add` de distancia. Descubre con `view --list`,
+  instala y compón antes de crear HTML/CSS propio.
+- Los componentes instalados son **código local y editable**; modifícalos cuando el
+  diseño lo pida. La divergencia con el registry se mantiene visible con
+  `create-lexy diff` / `doctor`, no se evita.
+- El import local sale de `componentImportPattern` en `ai/lexy-ai-manifest.json`; no
+  inventes rutas.
+- Antes de crear un componente nuevo, confirma con `create-lexy view` que no hay equivalente.
+- Determina siempre si la interfaz es para **cliente** o para **equipo (CRM)**: la
+  filosofía cambia por completo. Si no está claro, pregunta.
+- Accesibilidad, jerarquía y UX writing no son una pasada final: se diseñan desde el inicio.
+
+> El contexto de IA (`AGENTS.md`, `ai/`, `CLAUDE.md`, `.claude/`, `.github/copilot-instructions.md`)
+> es removible antes de producción. Ver [ai/PRODUCTION-CLEANUP.md](../ai/PRODUCTION-CLEANUP.md).

package/templates/.mcp.json

@@ -0,0 +1,8 @@
+{
+  "mcpServers": {
+    "shadcn": {
+      "command": "npx",
+      "args": ["shadcn@latest", "mcp"]
+    }
+  }
+}