create-lexy 0.6.2 → 0.6.3

package/templates/ai/pautas/buenas-practicas.md

@@ -0,0 +1,236 @@
+# Buenas prácticas de implementación Lexy
+
+Reglas de oficio accionables: cuándo usar qué componente, cómo armar formularios,
+qué estados son obligatorios y qué anti-patrones evitar. Heredan principios de
+Fluent, Material y Apple HIG, aterrizados al registry Lexy y a React.
+
+Esto responde *cuándo y cómo*. Para *valores* (espaciado, color, densidad) usa
+[sistema-visual.md](sistema-visual.md); para *layouts completos* usa [recetas-layout.md](recetas-layout.md).
+
+---
+
+## 1. Elegir el componente correcto
+
+- **`Card` vs continuidad.** Usa `Card` para agrupar contenido independiente que se
+  consulta como unidad (un resumen, un item de lista). **No** envuelvas cada sección
+  de un formulario en una card: rompe la continuidad de lectura. En CRM, prefiere
+  superficie plana y tablas antes que muchas cards compitiendo.
+- **`Dialog` vs `Sheet` vs página.**
+  - `Dialog`: confirmación o tarea corta y focal que no debe perder el contexto detrás.
+  - `Sheet`: panel lateral para detalle o edición sin abandonar la lista (típico CRM).
+  - Página: flujos largos, multi-paso o que merecen URL propia. No metas un wizard
+    completo en un dialog.
+- **Tabla vs lista.** Tabla cuando comparas registros por las mismas columnas
+  (escaneo en diagonal, CRM). Lista cuando cada item es heterogéneo o se lee como
+  bloque. No uses tabla para dos campos; no uses cards para 200 filas.
+- **`Tabs` vs secciones.** Tabs para categorías pares que no se necesitan ver a la
+  vez. Si el usuario debe comparar o leer todo en orden, usa secciones apiladas.
+- **Botones.** `default` = acción primaria (una sola por vista/sección),
+  `secondary`/`outline` = secundarias, `ghost` = terciarias o de baja jerarquía,
+  `link` = navegación inline, `destructive` = solo acciones que borran o revierten.
+- **Data-driven antes que primitivas.** Para sidebar, header, diálogo estándar y
+  acordeón usa `AppSidebar`, `AppHeaderBar`, `AppDialog` y `AppAccordion` (les
+  pasas datos y componen solos); para una app interna completa parte de
+  `SidebarProvider` + `AppSidebar` + `SidebarInset` (receta 7). Las primitivas
+  (`Sidebar`, `HeaderBar`, `Dialog`, `Accordion`) quedan para composiciones a
+  medida que el wrapper no cubre.
+- **Listas largas.** Usa `Pagination` antes de renderizar cientos de filas o
+  cortar la lista arbitrariamente. `ScrollArea` es para desborde controlado de
+  paneles internos (no reemplaza el scroll de página ni la paginación).
+- **Fechas.** Campo de fecha en formulario = `DatePicker`; selección visual de
+  rango o navegación por mes = `Calendar` directo.
+- **`Separator` solo cuando es estrictamente necesario.** Prefiere el espaciado y la
+  agrupación (grid 8pt, fondos `card`, encabezados) para separar; el divisor es el
+  último recurso, no el primero. Úsalo únicamente para un corte jerárquico real
+  (p. ej. entre secciones de un menú o grupos de acciones), nunca entre cada
+  elemento de una lista ni para decorar. Por defecto, **no agregues divisores**: si
+  el layout se entiende sin ellos, déjalo sin ellos.
+
+## 2. Formularios
+
+- **`Label` siempre**, asociado con `htmlFor`/`id`. El placeholder **no** reemplaza al
+  label: es un ejemplo o instrucción de acción.
+- **Una columna por defecto.** Empareja campos (`grid grid-cols-2`) solo si se
+  responden juntos y ayuda a escanear (ej. ciudad/región).
+- **Agrupa con `fieldset`/`legend`** los campos de una misma decisión. El `legend`
+  puede ir `sr-only` si el título visible ya lo cubre.
+- **Validación en el momento correcto:** valida al salir del campo (`onBlur`) o al
+  enviar, no en cada tecla. El error va **junto al campo**, dice qué pasó y cómo
+  corregir, en tono neutro (ver [ux-writing.md](ux-writing.md)).
+- **Estados del control:** marca inválido con `aria-invalid` (el `Input` ya lo
+  estiliza), deshabilita con motivo, y en envío usa estado `loading` en el botón sin
+  bloquear toda la pantalla.
+- **Obligatorios:** indícalos de forma consistente y accesible, no solo con un
+  asterisco suelto. Orden de tabulación = orden visual y de lectura.
+- **No pierdas trabajo:** confirma antes de descartar cambios; preserva lo escrito
+  ante un error de red.
+
+## 3. Estados obligatorios (regla, no opción)
+
+Toda vista que depende de datos resuelve **los cuatro**:
+
+1. **Loading** — `Skeleton` con la forma del contenido real cuando el layout es
+   conocido; `Spinner` solo para esperas puntuales sin layout (acción de botón,
+   envío). Marca `aria-busy`/`aria-live`.
+2. **Empty** — usa el componente `Empty` (título + descripción + acción): explica
+   por qué está vacío y ofrece la acción de salida (ej. «Crear primer caso»). Un
+   vacío sin acción es un callejón.
+3. **Error** — di qué falló y ofrece reintentar; no escondas el error ni muestres
+   datos a medias.
+4. **Contenido** — el estado normal.
+
+Éxito puntual (guardado, envío) → `Toast` con el siguiente paso, no un estado de
+página. Ver receta 6 en [recetas-layout.md](recetas-layout.md).
+
+## 4. Feedback y motion
+
+- **Feedback inmediato.** Toda acción confirma su resultado: cambio de estado,
+  toast, o transición. Nunca dejes al usuario sin saber si algo pasó.
+- **No bloquees sin progreso.** Operación > ~400 ms muestra loading (botón, skeleton
+  o barra). Para listas, prefiere optimistic UI solo si puedes revertir con claridad.
+- **Motion corto y con propósito** (120–200 ms, sobre `opacity`/`transform`) y
+  respeta `prefers-reduced-motion`. Detalles en [sistema-visual.md](sistema-visual.md). El movimiento
+  nunca es la única señal de un cambio.
+
+## 5. Densidad y responsive
+
+- **Móvil primero en cliente; desktop primero en CRM** (el trabajo intensivo vive en
+  pantallas grandes), pero ambos deben degradar con dignidad.
+- **Qué colapsa:** en móvil, tablas densas pasan a lista o scroll horizontal
+  controlado; toolbars apilan; sidebars se vuelven `Sheet`. No escondas acciones
+  frecuentes, esconde detalle secundario.
+- **Target táctil mínimo** ~44×44 px en superficies touch: usa `size='default'`
+  (`h-10`) en cliente; reserva `sm` para toolbars de CRM con mouse.
+- **Texto fluido:** no fijes alturas que rompan con texto más largo o zoom; respeta
+  reflow hasta 200%.
+
+## 6. React y código
+
+- **Composición sobre props booleanas.** Prefiere componer (`Card` + contenido) antes
+  que un mega-componente con diez flags. Si acumulas `isX`, `hasY`, `showZ`, divide.
+- **Respeta la API del registry.** Usa las variantes que expone el componente
+  (`variant`, `size`, `tone`); no sobreescribas su estructura con `className` que
+  rompa su comportamiento. Extiende vía `className` con `cn()`, no clonando estilos.
+- **No reinventes lo que existe.** Antes de crear un control, busca en
+  `lexy-ai-manifest.json`. Si falta, créalo siguiendo los patrones del proyecto.
+- **`cn()` para clases condicionales**, nunca concatenación de strings con template
+  literals sueltos.
+- **Keys estables** en listas (id real, no índice cuando el orden cambia).
+- **Sin estado derivado.** No guardes en estado lo que puedes calcular en render;
+  evita efectos que solo sincronizan props con estado.
+- **Accesibilidad en el código:** HTML semántico, un `main`, landmarks, headings sin
+  saltos, foco visible, `aria-label` en botones solo-icono. Ver
+  [arquitectura-informacion-ux.md](arquitectura-informacion-ux.md).
+
+## 7. Convenciones de código (biblia front-end)
+
+### Arquitectura del proyecto
+
+La arquitectura no se elige por gusto técnico sino por la **forma del producto**
+(el mismo criterio que usa la TUI de `create-lexy`, en `projectShape.ts`):
+
+| Forma del producto | Arquitectura | Router |
+|---|---|---|
+| Una pantalla o flujo corto (landing, formulario, demo) | **layered** (`src/components`, `src/views`…) | sin router |
+| Una app con secciones y navegación (dashboard, listados, detalle) | **feature** (`src/features`, `src/app`…) | **react-router** |
+
+- En **feature**, la navegación entre vistas se hace con `react-router` (ya
+  viene instalado): el `App` monta `<Routes>` y cada vista nueva es un `<Route>`.
+  La app se envuelve en `<BrowserRouter>` en `main.tsx`.
+- En **layered** no hay router: una sola pantalla o un flujo corto sin URLs
+  propias. Si el proyecto crece a varias secciones, esa es la señal para haber
+  partido en feature.
+- **React Compiler** está activo en ambos (memoización automática vía babel en
+  `vite.config.ts`): no agregues `useMemo`/`useCallback` defensivos: confía en el
+  compilador y reserva la memoización manual para casos medidos.
+
+### Nomenclatura
+
+| Qué | Convención | Ejemplo |
+|---|---|---|
+| Componentes y vistas | PascalCase | `Button.tsx`, `CasosDesk.tsx` |
+| Hooks | `useX.ts` (camelCase con prefijo `use`) | `useCasos.ts`, `useIsMobile.ts` |
+| Servicios y utils | kebab-case | `casos-service.ts`, `format-rut.ts` |
+| Tipos (archivos) | kebab-case | `caso.types.ts`, `api-types.ts` |
+| Variables y funciones | camelCase | `casosActivos`, `formatearPlazo()` |
+| Borde back→front | `snake_case → camelCase` al recibir | `fecha_limite` → `fechaLimite` |
+
+El mapeo `snake_case → camelCase` ocurre **una vez, en el borde** (el servicio que
+consume la API); del servicio hacia adentro todo el front habla camelCase. No
+dejes que el deletreo del backend se filtre a componentes o vistas.
+
+### Estado global
+
+- **Zustand es el estándar por defecto** para estado global (stores chicos,
+  selectores, sin boilerplate).
+- **Jotai** solo para casos genuinamente atómicos (muchas piezas de estado
+  independientes y derivadas).
+- **Redux** solo en escenarios complejos o legacy que ya lo usan; no para empezar.
+- **No uses Context API para estado global.** Context es para inyección de
+  dependencias de bajo cambio (tema, locale, usuario autenticado); como store
+  re-renderiza árboles completos y no escala.
+- Antes de subir algo a un store global pregunta: ¿de verdad lo comparten vistas
+  lejanas? El estado local (`useState`) y el de URL siguen siendo lo primero.
+
+### Validación
+
+- **Zod es mandatorio en formularios**: el schema valida y **`z.infer` es la única
+  fuente de verdad del tipado** — no declares a mano un tipo que duplica el schema.
+- El componente `Form` del registry ya integra react-hook-form + zodResolver:
+  instálalo con `create-lexy add form` (trae `zod` y `@hookform/resolvers`).
+- Los mensajes de error viven en el schema, en español neutro que dice cómo
+  corregir (ver [ux-writing.md](ux-writing.md)).
+- El mismo criterio aplica al borde back→front: si parseas respuestas de API,
+  valida con zod y deriva el tipo con `z.infer`.
+
+### Barrels (index.ts)
+
+- **Solo como API pública de una feature hacia afuera**: `features/casos/index.ts`
+  exporta lo que otras features pueden consumir.
+- **Dentro de una feature, imports directos al archivo hermano**
+  (`./casos-service`, `./CasoCard`) — nunca a través del barrel propio (ciclos,
+  bundles inflados, jumps de navegación).
+- En arquitectura layer no hay barrels: se importa directo del archivo
+  (`@/components/base/Button`).
+
+## 8. Performance percibida
+
+- **Lazy de vistas pesadas** (`React.lazy` + `Suspense`) con un fallback que respete
+  el layout, no un salto en blanco.
+- **Sin layout shift:** reserva espacio para imágenes (`width`/`height` o aspect),
+  skeletons del tamaño final, y evita que el contenido «salte» al cargar.
+- **Listas largas:** pagina o virtualiza antes de renderizar miles de filas.
+
+## 9. Anti-patrones Lexy (lista negra)
+
+No hagas esto, aunque «se vea bien»:
+
+- **Eyebrow decorativo** (`PASO 1`, `CLIENTE`, `LEGAL TECH`) que repite el título o
+  solo adorna. Solo si comunica estado, ubicación real o categoría que cambia la decisión.
+- **Hero comercial en un intake o formulario.** Una ficha no es una landing.
+- **Card envolviendo cada sección** de un formulario o cada fila de una tabla.
+- **Color como único signo de estado.** Siempre acompaña con texto o icono.
+- **Title Case** en UI. Usa sentence case (mayúscula solo inicial).
+- **«¿Estás seguro?»** sin explicar la consecuencia concreta y cómo deshacer.
+- **Emoji** en la interfaz: no son parte de la identidad Lexy.
+- **Densidad sin jerarquía** en CRM: meter datos sin alineación ni agrupación no es
+  eficiencia, es ruido.
+- **Aire de cliente en una herramienta de trabajo** (y viceversa): confundir los dos
+  mundos es el error más grave.
+- **Esconder con progressive disclosure** costos, riesgos, plazos, errores
+  bloqueantes o próximos pasos.
+- **Context API como store global** o tipos duplicando un schema de zod a mano:
+  van contra las convenciones de la sección 7.
+
+---
+
+## Checklist antes de entregar
+
+1. ¿El componente elegido es el correcto para la tarea (no card por defecto)?
+2. ¿Una sola acción primaria por vista/sección?
+3. ¿Formularios con `Label`, error junto al campo y orden de tab correcto?
+4. ¿Resolviste loading, empty, error y contenido?
+5. ¿Hay feedback de toda acción y nada bloquea sin progreso?
+6. ¿Responsive: colapsa detalle, no acciones frecuentes; target táctil suficiente?
+7. ¿Código accesible, semántico y respetando la API del registry?
+8. ¿Ningún anti-patrón de la lista negra?

package/templates/ai/pautas/calidad-industria.md

@@ -0,0 +1,109 @@
+# Calidad nivel industria — el pase anti-genérico
+
+Esta pauta define la **vara de calidad** de una interfaz Lexy: qué separa una
+pantalla con oficio de una pantalla "generada por IA". Úsala en dos momentos:
+al **elegir el patrón** (antes de componer) y como **pase final** antes de
+entregar. Los valores concretos viven en [sistema-visual.md](sistema-visual.md);
+las reglas de oficio en [buenas-practicas.md](buenas-practicas.md). Esto es el
+criterio de revisión.
+
+## La referencia mental correcta
+
+Antes de componer, pregúntate a qué se parecería esta pantalla en un producto
+de primer nivel del mismo dominio:
+
+- **CRM / herramientas internas:** Linear, Stripe Dashboard, Notion, Attio,
+  Height. Superficies planas, tablas serias, toolbars compactas, color
+  funcional, cero decoración.
+- **Cliente en momento difícil:** GOV.UK, bancos digitales serios, portales de
+  salud bien diseñados. Una idea por pantalla, lenguaje directo, cero pirotecnia.
+
+Si tu composición no podría vivir en uno de esos productos, todavía no está al
+nivel. "Bonita" no es el estándar; **creíble como producto real** lo es.
+
+## Señales de interfaz genérica (si aparece una, corrígela)
+
+Estas son las marcas típicas de UI generada sin criterio. Ninguna pasa el pase
+final:
+
+1. **Hero + tres cards** para algo que no es una landing. Un intake, un desk o
+   un formulario no abren con claim emocional ni grid de features.
+2. **Todo centrado.** El centrado es para momentos puntuales (confirmación,
+   login). El trabajo real se alinea a la izquierda y a una grilla.
+3. **Stat-cards por defecto.** Cuatro tarjetas de métricas arriba de un
+   dashboard que nadie pidió. Las métricas entran solo si alguien decide algo
+   con ellas.
+4. **Cards uniformes para todo.** Grid de tarjetas idénticas como solución
+   universal de layout. La tabla, la lista y la superficie plana existen.
+5. **Iconos decorativos** en cada título de sección, ilustraciones genéricas,
+   emoji. Lexy no decora; cada icono se gana su lugar.
+6. **Gradientes y sombras dramáticas** donde el sistema pide superficie y borde.
+7. **Datos de relleno irreales:** "John Doe", "Lorem ipsum", "Empresa S.A.",
+   métricas redondas (100%, 1.000). Delatan demo y impiden evaluar la
+   jerarquía real.
+8. **Copy de folleto:** "Bienvenido a tu plataforma integral de gestión legal".
+   El título dice la tarea, no el pitch (ver [ux-writing.md](ux-writing.md)).
+9. **Estados ausentes:** solo se diseñó el caso feliz con datos perfectos, sin
+   carga, vacío ni error.
+10. **Simetría forzada:** rellenar columnas o cards para que "se vea parejo".
+    La jerarquía manda; el relleno es ruido.
+
+## Cómo se ve el oficio
+
+Lo que hace que una pantalla se sienta producto real:
+
+- **Un punto focal.** En cada vista se puede decir en una frase qué es lo más
+  importante, y la composición lo confirma sin leer.
+- **Ritmo de espaciado consistente.** El mismo gap para el mismo tipo de
+  relación, en toda la pantalla (grid 8pt; ver
+  [sistema-visual.md](sistema-visual.md)). El desorden de espaciado es lo
+  primero que delata falta de oficio.
+- **Alineación impecable.** Labels, celdas, botones y bordes comparten ejes.
+  Una sola columna desalineada rompe la credibilidad de toda la vista.
+- **Color con disciplina.** Neutros para la estructura, marca donde dirige la
+  mirada, tonos de estado solo para estado. Si una pantalla tiene más de un
+  acento compitiendo, sobra uno.
+- **Datos de ejemplo realistas del dominio:** nombres chilenos, RUT con
+  formato (`12.345.678-9`), materias reales (despido, deuda, error médico),
+  plazos concretos («Vence en 3 días»), montos verosímiles ($1.250.000). El
+  contenido realista obliga a resolver truncamiento, columnas y jerarquía de
+  verdad.
+- **Los cuatro estados resueltos** (carga, vacío, error, contenido) con los
+  componentes del sistema: `Skeleton`/`Spinner`, `Empty`, mensaje de error con
+  reintento.
+- **Microcopy específico.** Cada botón dice su resultado concreto; cada estado
+  dice qué hacer después. Texto genérico = diseño genérico.
+
+## Patrón reconocible antes que layout inventado
+
+Para cada tipo de encargo existe un patrón que la industria ya validó. Parte
+de ahí y vístelo de Lexy; no inventes la mecánica:
+
+| Encargo | Patrón de partida | Receta |
+|---|---|---|
+| Lista operativa de registros | Toolbar + tabla densa + paginación | [recetas-layout.md](recetas-layout.md) §4 |
+| Trabajo sobre un registro | Master-detail (contexto + tabs de trabajo) | [recetas-layout.md](recetas-layout.md) §5 |
+| Captura de datos cliente | Wizard de pasos enfocados con progreso | [recetas-layout.md](recetas-layout.md) §1 |
+| App interna completa | Sidebar colapsable + área de trabajo (`SidebarProvider`, `AppSidebar`, `SidebarInset`) | [recetas-layout.md](recetas-layout.md) §7 |
+| Acceso | Card única centrada | [recetas-layout.md](recetas-layout.md) §3 |
+| Confirmación / éxito | Mensaje + qué sigue + una salida | [recetas-layout.md](recetas-layout.md) §2 |
+
+Si el encargo trae referencia visual o Figma, **la referencia manda** sobre
+esta tabla (ver [arquitectura-informacion-ux.md](arquitectura-informacion-ux.md)).
+
+## El pase final (antes de entregar, siempre)
+
+Recorre la pantalla terminada una vez con estas preguntas. Si alguna falla,
+corrige antes de mostrar:
+
+1. ¿Podría esta pantalla vivir en un producto de primer nivel del mismo
+   dominio sin desentonar?
+2. ¿Hay alguna señal de la lista de genéricos (hero indebido, cards de
+   relleno, iconos decorativos, datos falsos, copy de folleto)?
+3. ¿El espaciado tiene un ritmo consistente y todo comparte ejes de alineación?
+4. ¿La densidad corresponde al mundo (aire en cliente, compacto jerarquizado
+   en CRM)?
+5. ¿Los datos de ejemplo son realistas y del dominio legal chileno?
+6. ¿Están los cuatro estados y el microcopy dice siempre el siguiente paso?
+7. Si quito un elemento cualquiera, ¿se pierde algo? Si no, quítalo
+   («menos, pero mejor»).

package/templates/ai/pautas/diseno-cliente.md

@@ -0,0 +1,136 @@
+# Lexy — Filosofía de Diseño
+
+> Hacemos fácil lo legal.
+
+Este documento no contiene tokens, colores ni medidas. Es la brújula. Si alguna vez no sabes qué decisión tomar, vuelve aquí: describe *cómo se siente* Lexy, no *cómo se construye*. Las especificaciones técnicas viven en otro lugar; esto vive en el criterio.
+
+---
+
+## 1. Quiénes somos cuando diseñamos
+
+Lexy existe para una persona que está, casi siempre, en un mal momento: la despidieron, la está ahogando una deuda, un error médico le cambió la vida. Llega asustada, desinformada y convencida de que "lo legal" es un mundo hostil hecho para dejarla afuera.
+
+Nuestro trabajo de diseño tiene un solo propósito: **bajarle las pulsaciones**. Todo lo que diseñamos debe hacer que esa persona respire un poco más tranquila. Si una pantalla, un texto o una composición genera ansiedad, intimida o confunde, está mal diseñada — por muy bonita que sea.
+
+No somos un estudio jurídico que se ve moderno. Somos una empresa de tecnología que resuelve problemas legales. Esa diferencia de identidad lo cambia todo: no buscamos transmitir solemnidad, prestigio ni autoridad inalcanzable. Buscamos transmitir **claridad, cercanía y control**.
+
+---
+
+## 2. La sensación que perseguimos
+
+Si tuviéramos que resumir el "feel" de Lexy en una imagen: **una conversación tranquila con alguien que sabe lo que hace y no te hace sentir tonto.**
+
+- **Claro, no simplón.** Simplificamos lo complejo sin tratar al usuario como si no entendiera nada. Respeto e inteligencia, siempre.
+- **Cercano, no informal.** Hablamos de tú, con calidez, pero nunca perdemos la credibilidad. Somos el abogado amigo, no el amigo que improvisa.
+- **Moderno, no frío.** La tecnología está al servicio de la persona, no para presumir. Nada de futurismo gélido ni minimalismo que parece hospital.
+- **Seguro, no arrogante.** Transmitimos que esto va a salir bien, sin prometer imposibles ni inflar el pecho.
+
+Cuando dudemos del tono de algo, la pregunta es: *¿esto tranquiliza o impresiona?* Siempre elegimos tranquilizar.
+
+---
+
+## 3. Principios de diseño
+
+**1. Primero la legibilidad, después todo lo demás.**
+Un texto que no se lee con comodidad es un fracaso, sin importar qué tan lindo se vea el fondo. La decoración nunca le gana al contenido. Si hay que elegir entre un recurso visual impactante y la claridad de un mensaje, gana el mensaje.
+
+**2. El espacio es parte del mensaje.**
+El aire comunica calma. Una composición apretada le grita al usuario que ya está sobrepasado. Damos respiro generoso, dejamos que las cosas respiren, no llenamos cada rincón porque sí.
+
+**3. Una idea por pantalla.**
+Acompañamos a la persona paso a paso. No la abrumamos con todo a la vez. Cada momento del recorrido tiene un foco claro y una sola cosa importante que hacer o entender.
+
+**4. Menos, pero mejor.**
+Mil "no" por cada "sí". No agregamos secciones, datos, íconos ni adornos para "rellenar" o para parecer más completos. Cada elemento se gana su lugar o no entra. Si una pantalla se siente vacía, es un problema de composición, no una invitación a meter más cosas.
+
+**5. Consistencia que genera confianza.**
+La persona aprende a usar Lexy una vez y confía en que va a funcionar igual siempre. La sorpresa es enemiga de la tranquilidad. Repetimos patrones, no reinventamos en cada pantalla.
+
+**6. Honestidad visual.**
+No escondemos costos en letra chica, no disfrazamos errores, no usamos trucos para empujar decisiones. El diseño refleja la misma transparencia que prometemos en el servicio. Si algo es malo para el usuario, no lo maquillamos.
+
+**7. Accesibilidad por defecto.**
+La persona puede estar estresada, cansada, con baja visión, con poca motricidad, usando el teléfono en malas condiciones o apoyándose en tecnología asistiva. Diseñamos para esas variaciones desde el inicio. Una interfaz cliente debe poder leerse con comodidad, navegarse con teclado, entenderse sin depender solo del color y corregirse sin culpa ni confusión. Los mínimos WCAG son punto de partida; la meta es que más personas puedan completar el flujo con autonomía.
+
+---
+
+## 4. Patrones de interfaz cliente
+
+### Ficha web o formulario de antecedentes
+
+Cuando el encargo sea una ficha web, intake, formulario de antecedentes o carga de datos para revisión legal, no diseñes una landing. La pantalla debe sentirse como un trámite guiado y tranquilo, no como una página comercial.
+
+Patrón recomendado:
+
+- Flujo por pasos cuando la información sea extensa.
+- Stepper visible si hay varias etapas.
+- Una sección principal por pantalla o paso.
+- Título directo de la tarea, por ejemplo `Datos personales`.
+- Copy breve que explique para qué se piden los datos.
+- Nota clara para campos obligatorios si corresponde.
+- Formulario de ancho contenido, legible, con pares de campos solo cuando ayudan a escanear.
+- CTA principal claro al final del paso, por ejemplo `Guardar y continuar`.
+- Ayuda contextual o flotante cuando reduzca ansiedad sin competir con el formulario.
+
+Evita:
+
+- Hero grande con claim emocional.
+- Eyebrows como `Ficha`, `Evaluación`, `Nuevo caso` si no aportan orientación.
+- Cards envolviendo cada bloque de formulario cuando el patrón necesita continuidad.
+- Aside explicativo o resumen lateral si el diseño de referencia no lo muestra.
+- Iconos decorativos para cada sección.
+- Meter todas las etapas en una sola pantalla para parecer completo.
+
+Si una referencia de Figma muestra una ficha de un paso, respeta ese patrón: stepper, foco único, densidad, campos y CTA. No la transformes en dashboard ni en formulario completo multi-sección salvo que el encargo lo pida.
+
+---
+
+## 5. Identidad visual — el espíritu, no la receta
+
+**El isotipo es nuestra firma.** La marca tiene un símbolo propio que comunica activación, conexión y "encendido" — la chispa de poner las cosas en movimiento. Lo tratamos con respeto: tiene aire alrededor, protagonismo cuando corresponde, y nunca lo deformamos ni lo recargamos. Funciona mejor como gesto grande y seguro que como adorno pequeño y repetido sin criterio.
+
+**Los fondos y patrones son atmósfera, no ruido.** La marca tiene un mundo gráfico propio, con texturas y patrones construidos a partir de su símbolo. Los usamos para dar identidad y profundidad — pero **siempre subordinados al contenido**. Un patrón nunca compite con un texto. Cuando hay que comunicar algo importante, el fondo se hace a un lado: se atenúa, se calma, se vuelve telón. La regla de oro: si tienes que entrecerrar los ojos para leer encima de un fondo, el fondo perdió.
+
+**La tipografía tiene jerarquía clara.** Hay una voz para los grandes momentos — los titulares, las portadas, lo que tiene que emocionar y quedar — y otra voz para el trabajo diario — los textos largos, las interfaces, lo que tiene que leerse sin esfuerzo durante minutos. No confundimos los roles: lo expresivo para destacar, lo legible para acompañar. Mezclar mal estos registros es la forma más rápida de que algo se sienta poco profesional.
+
+**El color tiene jerarquía emocional.** Hay un color que es la marca, que aparece donde importa y dirige la mirada. Hay tonos de apoyo que crean ambiente. Y hay colores con trabajo funcional — avisar de un éxito, una alerta, un error — que tienen que leerse como lo que son, universalmente, sin que el usuario tenga que aprender un código. Un estado de éxito se siente como éxito; una alerta se siente como alerta. Nunca sacrificamos esa claridad funcional por coherencia estética.
+
+**Las submarcas son familia, no clones.** Lexy tiene líneas especializadas. Cada una tiene su matiz propio que la hace reconocible, pero todas pertenecen claramente a la misma casa. Se sienten hermanas: comparten estructura, tono y espíritu, y se diferencian con sutileza, no con estridencia.
+
+---
+
+## 6. Voz y tono editorial
+
+La forma en que escribimos *es* diseño. Un buen layout con mal texto es un mal producto.
+
+**Cómo suena Lexy:**
+
+- **Hablamos de tú.** Cercanía directa, nunca el "usted" distante y acartonado de los abogados tradicionales.
+- **Primera persona plural.** "Hacemos", "creemos", "te acompañamos". Estamos del mismo lado de la mesa que el usuario, no enfrente.
+- **Frases cortas y humanas.** Decimos "lo legal", no "la materia jurídica". Si una palabra técnica se puede reemplazar por una cotidiana sin perder precisión, la reemplazamos.
+- **Primero el beneficio, después la prueba.** Abrimos con lo que la persona gana, no con nuestras credenciales ni con latinazgos.
+- **Énfasis con intención.** Cuando queremos destacar una idea, lo hacemos en un solo gesto y sobre una sola palabra — el diferenciador, el verbo que importa. No acumulamos recursos de énfasis ni gritamos con mayúsculas y signos. Un acento bien puesto vale más que diez.
+
+**Lo que nunca hacemos:**
+
+- No usamos jerga legal para impresionar.
+- No prometemos lo que no podemos cumplir.
+- No asustamos para vender ("si no actúas ya, lo pierdes todo").
+- No usamos emoji: no son parte de nuestra identidad y diluyen la credibilidad.
+- No escribimos párrafos eternos donde basta una frase.
+
+**La prueba del tono:** lee cualquier texto en voz alta imaginando que se lo dices a alguien recién llegado, asustado, sentado frente a ti. Si suena a folleto corporativo, a contrato o a robot, reescríbelo. Si suena a una persona competente y amable explicándole las cosas con calma — está listo.
+
+---
+
+## 7. Cómo tomar decisiones cuando esto no alcanza
+
+Ningún documento cubre todos los casos. Cuando enfrentes una decisión sin respuesta obvia, pásala por estos filtros, en orden:
+
+1. **¿Tranquiliza a una persona estresada?** Si genera ansiedad, descártalo.
+2. **¿Se entiende sin esfuerzo?** La claridad le gana a la elegancia siempre.
+3. **¿Es honesto?** Si esconde, presiona o engaña, no es Lexy.
+4. **¿Se siente parte de la familia?** Coherente con todo lo demás, sin sorpresas gratuitas.
+5. **¿Sobra?** Si lo puedes quitar y nada se pierde, quítalo.
+
+Diseñar para Lexy es, en el fondo, un acto de empatía: ponerse en los zapatos de alguien que la está pasando mal y construirle un camino claro, cálido y sin trampas. Si cada decisión nace de ahí, el resto se ordena solo.

package/templates/ai/pautas/diseno-crm-lexy.md

@@ -0,0 +1,109 @@
+# Lexy CRM — Filosofía de Diseño (interfaz interna)
+
+> La interfaz existe para que el trabajo se haga fácil. Todo gira en torno a la tarea.
+
+Este documento es la brújula para diseñar la plataforma interna de Lexy: el lugar donde los abogados y el equipo gestionan casos, ejecutan tareas, hacen seguimiento y mueven el trabajo hacia adelante. No contiene tokens, colores ni medidas — describe *cómo se siente* trabajar acá, no *cómo se construye*.
+
+**Lee esto antes que nada:** la interfaz para clientes y la interfaz para el equipo son dos mundos distintos. La del cliente existe para *tranquilizar a alguien que la está pasando mal*. Esta existe para *que el abogado ejecute su trabajo de la forma más fácil e intuitiva posible*. No las confundas. Pero ojo: "fácil e intuitivo" no significa lento ni espaciado — significa que en cada momento la interfaz pone por delante lo que la tarea necesita, anticipa el siguiente paso y elimina la fricción. Es una herramienta orientada a la tarea, y la tarea es siempre el centro.
+
+---
+
+## 1. Para quién diseñamos acá
+
+El usuario es un abogado o un miembro del equipo Lexy que va a pasar **horas al día, todos los días**, dentro de esta herramienta para ejecutar tareas concretas: avanzar un caso, redactar una gestión, cumplir un plazo, hacer seguimiento. Conoce el dominio y maneja muchos casos a la vez, mientras le interrumpen constantemente.
+
+Nuestro trabajo de diseño tiene un propósito claro: **que cada tarea sea lo más fácil e intuitiva de realizar.** Que el abogado nunca tenga que pensar *cómo* usar la herramienta, solo *qué* quiere lograr — y que la interfaz lo lleve hasta ahí sin tropiezos. Eso a veces significa anticiparle el siguiente paso, a veces poner una acción justo donde la mano la busca, a veces tener todo el contexto a la vista para que no tenga que ir a buscarlo. La interfaz hace el trabajo pesado para que la persona se concentre en el criterio, que es lo único que el software no puede poner.
+
+Nuestro éxito no se mide en "qué linda quedó la pantalla". Se mide en **qué tan fácil y fluido le resultó al abogado hacer lo que vino a hacer.**
+
+---
+
+## 2. La sensación que perseguimos
+
+Si el producto de cliente se siente como *una conversación tranquila*, esto se siente como **un buen taller de trabajo**: cada herramienta a la mano, todo a la vista, nada que estorbe entre la persona y la tarea. Ordenado, fluido y sin fricción.
+
+- **Fácil, no simplista.** La tarea se realiza con el mínimo esfuerzo posible — pero sin esconder lo que el trabajo realmente requiere. Quitamos fricción, no capacidad.
+- **Intuitivo, no adivinatorio.** El siguiente paso es siempre evidente. La persona no tiene que detenerse a pensar cómo se usa la herramienta; la herramienta se explica sola al ritmo de la tarea.
+- **Eficiente, no apurado.** La velocidad nace del orden y de la anticipación, no del caos. Densidad que se entiende, no que abruma.
+- **Predecible, no rígida.** Todo está donde la tarea lo necesita y responde al instante. Las sorpresas, acá, cuestan tiempo y errores.
+
+La pregunta de oro cuando dudemos: *¿esto hace más fácil ejecutar la tarea, o solo se ve bien?* Si no facilita el trabajo, sobra.
+
+---
+
+## 3. Principios de diseño
+
+**1. La tarea es el centro de todo.**
+Cada pantalla se diseña preguntando primero: ¿qué vino a hacer aquí la persona? Todo lo que ayuda a esa tarea va al frente; todo lo que no, se aparta o desaparece. No diseñamos "pantallas de información", diseñamos lugares donde se ejecuta un trabajo concreto, y los ordenamos alrededor de ese trabajo.
+
+**2. La densidad al servicio de la tarea.**
+Acá el espacio en blanco generoso no es calma, es scroll y clics extra. El abogado quiere ver su lista de casos, los datos clave de uno y sus próximas acciones sin tener que navegar. Mostramos más por pantalla — siempre que siga siendo legible y jerárquico, y siempre que sirva a la tarea que está ejecutando. Compactar bien es un acto de respeto por su tiempo.
+
+**3. La información que se necesita junta, va junta.**
+Nada de mandar al usuario a tres pantallas para juntar el contexto de una decisión. Lo que se consulta en conjunto, vive en conjunto. El trabajo fluye cuando el contexto no se fragmenta.
+
+**4. La acción está siempre a la mano.**
+Las tareas frecuentes se hacen en el menor número de pasos posible, idealmente sin cambiar de contexto. Acciones rápidas, edición en línea, atajos de teclado para los power users. Si algo se hace cincuenta veces al día, tiene que costar casi cero.
+
+**5. El estado siempre es visible.**
+El experto debe saber, sin preguntar: en qué etapa está cada caso, qué le toca hacer, qué está atrasado, qué espera de otros. El sistema le quita de la cabeza lo que el sistema puede recordar por él. La memoria de trabajo es un recurso escaso; no la gastamos en cosas que la interfaz puede sostener.
+
+**6. Escaneabilidad sobre belleza.**
+Una tabla densa y bien alineada que se lee en diagonal vale más que una tarjeta espaciosa y elegante. Priorizamos alineación, jerarquía visual y consistencia de formato para que el ojo encuentre lo que busca de inmediato. La estética sirve a la lectura rápida, no al revés.
+
+**7. Cero pérdida de trabajo.**
+Nada erosiona más la confianza de un profesional que perder lo que hizo. Guardado confiable, estados claros de "se guardó / no se guardó", confirmaciones solo donde el riesgo lo amerita, y siempre una forma de deshacer. El sistema es un colega responsable, no uno que te hace repetir trabajo.
+
+**8. Consistencia férrea.**
+El experto memoriza la herramienta y trabaja en piloto automático. Cada patrón que se repite igual es velocidad ganada; cada excepción es un tropiezo. Acá la consistencia importa todavía más que en el producto de cliente, porque el uso es intensivo y repetido.
+
+**9. Accesibilidad operativa.**
+El abogado también puede trabajar con fatiga visual, interrupciones, una mano ocupada, pantallas pequeñas, zoom alto o necesidades permanentes de accesibilidad. La densidad nunca justifica perder contraste, foco visible, navegación por teclado, labels claros o estados comprensibles. Una herramienta interna accesible reduce errores y velocidad perdida; no es una concesión, es calidad operativa.
+
+---
+
+## 4. Jerarquía y densidad — el espíritu, no la receta
+
+**El trabajo manda; la marca acompaña.** Esta es una herramienta, no una pieza de marca. La identidad de Lexy está presente, pero contenida: da pertenencia y coherencia sin robar protagonismo ni espacio. Acá los fondos decorativos, los patrones expresivos y los gestos de marca grandes **no tienen lugar** — cada pixel que ocupa decoración es un pixel que no muestra información útil. El lujo, en una herramienta de trabajo, es la sobriedad.
+
+**Los patrones conocidos son una fuente de confianza.** Tenemos un design system propio — nuestros componentes, nuestra estética, nuestra identidad — y eso no está en discusión. Lo que no reinventamos es *cómo se comportan* las cosas: una tabla se ordena como la gente espera que se ordene, un formulario valida cuando corresponde, un menú se abre donde la mano lo busca, un botón primario pesa más que uno secundario. Nos apoyamos deliberadamente en las convenciones y guidelines de la industria — los principios de Apple HIG, Fluent Design, Material y compañía — no para copiar su apariencia, sino para heredar décadas de patrones de interacción que el abogado ya tiene internalizados. Vestimos esos patrones con la piel de Lexy; no inventamos mecánicas nuevas para problemas ya resueltos. Cuando un control se ve propio pero se comporta como la persona espera, puede apretar el botón y avanzar **sin dudar**, confiando en que la herramienta hará exactamente lo que parece que va a hacer. Esa previsibilidad — alineación impecable, coherencia entre pantallas, consistencia férrea en cómo se ven y actúan los elementos — es lo que le da la seguridad para ejecutar la tarea en piloto automático. La originalidad, acá, se reserva para resolver mejor el problema de fondo, nunca para sorprender con la mecánica de un control. Lo familiar en el comportamiento no es falta de creatividad: es respeto por la confianza del usuario.
+
+**La jerarquía visual hace el trabajo pesado.** Con mucha información en pantalla, lo que distingue una buena interfaz de una abrumadora es la jerarquía: qué se ve primero, qué es secundario, qué está agrupado con qué. Usamos peso, tamaño, agrupación y alineación para que el ojo del experto vaya solo a lo importante. Un buen tablero denso se *siente* ordenado aunque tenga el triple de datos que una pantalla de cliente.
+
+**El color trabaja, no decora.** En esta interfaz el color es sobre todo funcional: distinguir estados, señalar urgencias, agrupar categorías, marcar lo que requiere atención. Un caso atrasado, una tarea vencida, un hito cumplido — se reconocen al instante por su color, de forma consistente en todo el sistema. El color es un lenguaje de trabajo, no un adorno; lo usamos con disciplina para que nunca pierda significado.
+
+**La tipografía es para leer rápido y mucho.** Acá no buscamos expresividad ni momentos memorables; buscamos que se puedan leer tablas, listas y formularios durante horas sin fatiga. Claridad, alineación impecable y una jerarquía de texto sobria y predecible. Lo expresivo se queda en el producto de cliente; acá manda lo funcional.
+
+**Las tablas y listas son ciudadanas de primera clase.** Buena parte del trabajo vive en vistas de muchos registros. Las tratamos con el cariño que merecen: ordenables, filtrables, escaneables, con la información correcta en cada columna y acciones al alcance. Una tabla bien diseñada es, en este producto, tan importante como una buena portada lo es en el de cliente.
+
+---
+
+## 5. Voz y tono editorial
+
+El producto de cliente habla cálido y tranquilizador. Acá hablamos como **colegas eficientes entre profesionales**: directos, precisos, sin rodeos.
+
+**Cómo suena el CRM:**
+
+- **Preciso y breve.** Etiquetas claras, sin adornos. El experto no necesita que lo motiven con frases lindas; necesita saber qué es cada cosa de un vistazo.
+- **Vocabulario profesional, sin miedo.** Acá sí usamos los términos del oficio — etapas procesales, tipos de gestión, nomenclatura jurídica real. El usuario los conoce y traducirlos a lenguaje simple solo lo haría más lento.
+- **Orientado a la acción.** Los textos de botones y tareas dicen qué va a pasar, en verbos claros y concretos. Nada de ambigüedad sobre el resultado de una acción.
+- **Sin paternalismo, pero nunca a costa de la claridad.** No explicamos de más ni celebramos cada microacción, pero sí dejamos siempre evidente qué hacer y cómo. Respetar al usuario es no hacerle perder el tiempo — jamás es dejarlo perdido.
+
+**Los mensajes que sí importan: errores y estados.** Cuando algo sale mal o hay que confirmar algo riesgoso, somos claros y útiles: qué pasó, qué consecuencia tiene, qué puede hacer. Sin alarmismo pero sin esconder la gravedad. En una herramienta de trabajo, un buen mensaje de error vale más que diez frases motivacionales.
+
+**La prueba del tono:** imagina que un colega abogado con experiencia lee el texto por encima del hombro. Si le suena obvio, profesional y eficiente — bien. Si le suena a que lo están tratando como novato o a que le están haciendo perder el tiempo con relleno — reescríbelo.
+
+---
+
+## 6. Cómo tomar decisiones cuando esto no alcanza
+
+Pasa cada decisión por estos filtros, en orden:
+
+1. **¿Hace más fácil ejecutar la tarea?** Ese es el norte. Si no facilita el trabajo, sobra.
+2. **¿El siguiente paso es evidente sin pensarlo?** Si la persona tiene que detenerse a descifrar la interfaz, falló.
+3. **¿Muestra lo necesario sin obligar a navegar?** El contexto fragmentado es el enemigo.
+4. **¿Es consistente con el resto?** El uso intensivo premia la repetición y castiga la excepción.
+5. **¿Protege el trabajo del usuario?** Nada que arriesgue perder lo hecho.
+6. **¿La decoración le está quitando espacio a la tarea?** Si sí, gana la tarea.
+
+Diseñar el CRM de Lexy es diseñar alrededor de la tarea. El acto de empatía acá es hacerle el trabajo fácil al abogado: entender qué viene a lograr, quitarle del camino todo lo que estorba, anticiparle el siguiente paso y construirle un lugar donde ejecutar su trabajo sea simple, intuitivo y fluido — para que pueda dedicar su cabeza a lo único que importa: el caso de una persona real.