create-lexy 0.6.2 → 0.6.3

package/templates/ai/pautas/sistema-visual.md

@@ -0,0 +1,197 @@
+# Sistema visual Lexy — valores y densidad
+
+Esta pauta da los **valores concretos** (espaciado, densidad, tipografía, color de
+estado, motion) que el tema no documenta solo. Es complemento técnico de
+[diseno-cliente.md](diseno-cliente.md) y [diseno-crm-lexy.md](diseno-crm-lexy.md): la filosofía dice *por qué*; esto dice
+*con qué números*. Para reglas de oficio y composición usa [buenas-practicas.md](buenas-practicas.md).
+
+El tema sigue la convención **shadcn/Tailwind**: usa los tokens semánticos
+(`bg-primary`, `text-muted-foreground`, `border-border`) y deja que el CSS resuelva
+los colores. Lo que sigue cubre lo que **no** es estándar y las decisiones de
+densidad inspiradas en Fluent, Material y Apple HIG, aterrizadas a Geist Sans y al tema Lexy.
+
+---
+
+## 1. Tokens no estándar (no inventes equivalentes crudos)
+
+shadcn base solo trae `primary`, `secondary`, `destructive`, `muted`, `accent`. El
+tema Lexy agrega tokens de estado. **Úsalos siempre; no uses colores crudos de
+Tailwind como `bg-green-500` o `text-red-600` para estado.**
+
+| Estado | Token | Texto/icono | Fondo sutil | Borde sutil |
+|---|---|---|---|---|
+| Éxito | `success` | `text-success-strong` | `bg-success/10` | `border-success/30` |
+| Alerta | `warning` | `text-warning-strong` | `bg-warning/10` | `border-warning/30` |
+| Error | `destructive` | `text-destructive` | `bg-destructive/10` | `border-destructive/20` |
+| Información | `info` | `text-info` | `bg-info/10` | `border-info/20` |
+| Marca | `primary` | `text-primary` | `bg-primary/10` | `border-primary/20` |
+
+Reglas:
+
+- **Patrón de superficie de estado:** para texto sobre fondo claro usa el paso
+  `-strong` de éxito/alerta; acompáñalo de fondo a `/10` y borde a `/30`.
+  `Tag` aplica este patrón. Los dots y rellenos usan el token base vívido.
+- `accent` (`bg-accent` / `text-accent-foreground`) es el tinte sutil del primary;
+  úsalo para selección, hover de items y estados activos discretos, no para CTA.
+- El color **nunca** es el único signo de estado: acompáñalo con texto o icono
+  (ver [buenas-practicas.md](buenas-practicas.md)).
+
+## 2. Familia y pesos tipográficos (Geist)
+
+**Geist es la familia tipográfica del producto.** Geist Sans cubre toda la interfaz
+y Geist Mono queda reservada para código, tokens e identificadores técnicos. Ambas
+son variables y autoalojadas. No agregues otra familia para crear jerarquía: cambia
+de rol tipográfico, tamaño o peso dentro de Geist.
+
+El tema usa sus pesos funcionales (`medium: 500`, `semibold: 600`, `bold: 700`).
+**Usa las clases de utilidad, no valores numéricos:**
+
+- `font-normal` (400) — cuerpo, captions.
+- `font-medium` (500) — labels, items de navegación, énfasis suave.
+- `font-semibold` (600) — títulos de sección, headers de tabla, botones.
+- `font-bold` (700) — display editorial y énfasis excepcional fuera de la jerarquía de producto.
+
+Los títulos de producto no se construyen combinando peso y tamaño a mano: los roles
+`type-*` ya asignan el peso correcto. `type-page-title`, por ejemplo, usa 600.
+
+No uses pesos arbitrarios ni `font-extrabold`: rompen la rampa calibrada para Geist.
+
+## 3. Rampa tipográfica (roles)
+
+La API de producto usa clases de **rol**, no combinaciones manuales de `text-*`,
+`leading-*`, `tracking-*` y `font-*`:
+
+| Clase | px / line-height | Rol |
+|---|---|---|
+| `type-meta` | 12 / 16 | Caption, metadatos, ayuda |
+| `type-supporting` | 14 / 20 | Ayuda y texto secundario |
+| `type-action-label` | 14 / 20 | Botones, tabs y labels de acción |
+| `type-data` | 14 / 20 | Montos, plazos, RUT y fechas (tabular) |
+| `type-body` | 16 / 24 | Cuerpo por defecto y lectura |
+| `type-item-title` / `type-section-title` | 16 / 24 | Ítem o encabezado de sección |
+| `type-subsection-title` | 22 / 28 | Subtítulo de documento |
+| `type-dialog-title` | 24 / 32 | Título de diálogo |
+| `type-page-title` | 32 / 40 | Título de página |
+
+- **CRM:** usa `type-body` y `type-supporting`; títulos de vista en
+  `type-subsection-title` o `type-page-title` según la jerarquía. La expresividad
+  display no pertenece a herramientas internas.
+- **Cliente:** título de pantalla `type-page-title`, cuerpo `type-body`, ayuda
+  `type-supporting`.
+- Un solo `h1` por página. No saltes niveles de heading para conseguir un tamaño.
+
+## 4. Espaciado — grid de 8 pt (contrato híbrido)
+
+Base de 8 px (con medios pasos de 4 px), convención compartida por Fluent, Material
+y Apple HIG. Usa la escala de Tailwind, que ya es múltiplo de 4:
+
+- Micro (dentro de un control): `gap-1` (4) · `gap-2` (8).
+- Entre elementos relacionados: `gap-3` (12) · `gap-4` (16).
+- Entre grupos / secciones: `gap-6` (24) · `gap-8` (32).
+- Separación de bloques mayores: `gap-12` (48) · `gap-16` (64).
+
+Reglas del contrato (las mismas que cumplen los componentes de la librería):
+
+- **Grilla de 4 px para todo espaciado entre elementos**: gaps, `space-*`,
+  márgenes y paddings de superficie. Evita valores arbitrarios (`p-[13px]`,
+  `mt-[7px]`); si necesitas algo intermedio, redondea al paso de 4 más cercano.
+  La escala de Tailwind v4 es dinámica: `w-70` (280 px) o `max-h-75` (300 px)
+  son válidos y preferibles a `w-[280px]`.
+- **Medio-pasos de 2 px solo DENTRO de un control**: padding fino de items de
+  menú (`py-1.5`), iconos pequeños (`size-3.5`) y offsets de alineación. Nunca
+  para separar hermanos o secciones.
+- **Nudge óptico de 2 px (`m*-0.5`)**: permitido solo como compensación
+  deliberada de baseline u óptica (icono junto a texto, asterisco de label).
+- **Caja compuesta simétrica**: en un componente o bloque con header/contenido/
+  footer, el espacio sobre el primer slot debe igualar el espacio bajo el
+  último, todos los slots comparten el mismo riel horizontal (`px`), y los gaps
+  entre slots son uniformes o decrecen con jerarquía clara. Cumplir la grilla
+  valor a valor no basta si la unidad queda asimétrica.
+
+## 5. Densidad — cliente vs CRM (el ajuste que más cambia el resultado)
+
+La misma jerarquía, dos densidades. No las mezcles.
+
+### Cliente (aire = calma)
+
+- Contenedor de contenido: `max-w-xl` (formularios) a `max-w-2xl` (lectura).
+- Padding de sección: `p-6` a `p-8`. Padding de página: `px-4` móvil, `px-6`+ desktop.
+- Separación entre campos de formulario: `gap-5` / `space-y-5`.
+- Separación entre secciones: `gap-8` a `gap-12`.
+- Altura de inputs: `h-10`. El botón usa 36 px por defecto y 40 px en `size="lg"`;
+  en flujos de cliente prefiere `lg` cuando la acción principal necesita más presencia.
+- Una idea principal por pantalla; deja respirar.
+
+### CRM (densidad jerarquizada = velocidad)
+
+- Contenedor: ancho completo del área de trabajo (`w-full`), sin `max-w` estrecho.
+- Padding de superficie: `p-4` (paneles), `px-4 py-3` (toolbars).
+- Separación entre campos: `gap-3` / `space-y-3`.
+- Filas de tabla: `h-10` cómoda, `h-9` compacta; celdas `px-3 py-2`.
+- Densidad alta solo si está jerarquizada (alineación, peso, agrupación). Densidad
+  sin jerarquía es ruido, no eficiencia.
+- Prefiere edición en línea y acciones por fila sobre navegar a otra pantalla.
+
+## 6. Superficie, bordes y radios
+
+- **Contención: espacio → superficie → línea.** Agrupa primero por proximidad. Si
+  hace falta un límite explícito, usa `bg-surface-container rounded-lg` con aire
+  interior. Reserva el hairline para separar ítems dentro de una misma superficie
+  cuando el espacio no baste; no cortes cada sección del documento con una línea.
+- **Elevación semántica.** La sombra solo aparece cuando algo realmente flota.
+  Cards y paneles estáticos usan superficie, tono y borde, sin sombra por defecto.
+  Usa `shadow-raised` para elevación cercana y `shadow-overlay` para dropdowns,
+  popovers, toasts, Dialog y Sheet. No inventes escalones con `shadow-sm/md/lg`.
+- **Radio por oficio.** La escala intermedia es 2–4px para detalles mini, 6px
+  para interacción rectangular, 8px para flotantes compactas, 10px para cards,
+  14px para overlays y 20px para media o paneles hero. Usa `rounded-control` (inputs), `rounded-button` (botones
+  de cualquier variante o tamaño), `rounded-menu-item`, `rounded-nav-item`,
+  `rounded-lg` (cards), `rounded-xl` (Dialog y Sheet) y `rounded-2xl` (media o
+  paneles hero). `rounded-sm` queda para detalle mini.
+- **Una geometría para todos los botones.** Primary, destructive, secondary,
+  outline, ghost y los botones solo-icono comparten `rounded-button` (6px), también
+  en tamaño `lg`. La jerarquía cambia color, borde y contenido, no la silueta.
+  `rounded-full` queda para avatares, dots, toggles y conteos cuya forma circular
+  expresa su función.
+- **Jerarquía por superficie:** `background` (canvas) < `surface-container`
+  (zona de agrupación) < `card` (contenido) < `popover` (flotante). No pongas card
+  sobre card sobre card; aplana.
+
+## 7. Iconografía (lucide-react)
+
+- Tamaño por defecto en botones y junto a texto: `size-4` (16 px) — el registry ya
+  lo aplica con `[&_svg]:size-4`. Iconos sueltos de acción: `size-4`/`size-5`.
+- El icono **acompaña**, no es la única explicación: botón solo-icono requiere
+  `aria-label`. Estado por icono requiere también texto.
+- Estilo consistente: trazo lineal de lucide, no mezcles con emoji (Lexy no usa emoji).
+- No decores cada sección con un icono. Un icono se gana su lugar si ayuda a
+  reconocer o actuar más rápido.
+
+## 8. Motion
+
+Inspirado en Material/Apple: el movimiento orienta, no entretiene.
+
+- **Duraciones por distancia:** `--duration-instant` (80 ms) para hover,
+  `--duration-fast` (120 ms) para presión, `--duration-normal` (180 ms) para
+  cambios de estado y `--duration-overlay` (220 ms) para capas.
+- **Easing:** `--ease-enter` para entradas, `--ease-standard` para cambios y
+  `--ease-exit` para salidas.
+- Anima `opacity` y `transform`, no `width`/`height`/`top` (evita reflow y jank).
+- **Respeta `prefers-reduced-motion`:** envuelve animaciones no esenciales y
+  ofrece una versión sin desplazamiento. Nunca dependas del movimiento para
+  comunicar (un cambio de estado debe leerse también detenido).
+- En CRM el movimiento es mínimo: feedback inmediato sobre animación elaborada.
+
+---
+
+## Checklist visual antes de entregar
+
+1. ¿Usaste tokens de estado (`success`/`warning`/`info`) y no colores crudos?
+2. ¿El estado se comunica con texto o icono además del color?
+3. ¿Pesos vía clases (`font-medium`/`font-semibold`), sin valores numéricos?
+4. ¿Espaciado en múltiplos de 4/8, sin valores arbitrarios?
+5. ¿Las cajas compuestas son simétricas (espacio tope = base, riel `px` único entre header/contenido/footer, gaps uniformes)?
+6. ¿La densidad corresponde al mundo (aire en cliente, compacto en CRM)?
+7. ¿Un solo `h1` y headings sin saltos por tamaño?
+8. ¿La contención sigue espacio → superficie → línea y la sombra aparece solo si algo flota?
+9. ¿Motion corto, sobre opacity/transform y con `prefers-reduced-motion`?

package/templates/ai/pautas/ux-writing.md

@@ -0,0 +1,214 @@
+# Lexy — Guía de UX Writing
+
+> Documento para IA y diseñadores. Define cómo se escribe dentro de los productos Lexy: tono, patrones de microcopy y reglas por tipo de componente. Los ejemplos están tomados de los productos Lexy (flujo de Carga de Documentos y desks del equipo).
+
+Esta guía es operativa: no habla de filosofía de marca (eso vive en otros documentos), sino de **qué palabras poner en pantalla y cómo**. Cuando escribas un texto de interfaz para Lexy, esta es la referencia.
+
+---
+
+## 0. La regla base: háblale de tú
+
+Lexy siempre habla de **tú**: cercano, directo, humano.
+
+- *"Ingresa tu clave aquí"*
+- *"Aún puedes subir los documentos"*
+- *"Tu contraseña se usará solo para validar tu información"*
+- *"Completa los datos solicitados"*
+
+Única excepción: textos legales o contractuales (términos, mandatos) donde el registro jurídico lo exige. Todo lo demás es tú.
+
+---
+
+## 1. Principios de redacción
+
+1. **Claridad antes que completitud.** Una frase corta que se entiende le gana a una correcta pero larga. Si puedes decirlo en menos palabras sin perder sentido, hazlo.
+2. **El usuario primero, el sistema después.** Habla de lo que la persona gana o tiene que hacer, no de cómo funciona el sistema por dentro.
+3. **Di qué pasa después.** Todo mensaje de estado deja claro el siguiente paso. Nunca dejes a la persona sin saber qué viene.
+4. **Honestidad sin alarmismo.** Cuando hay una consecuencia (un plazo que vence, datos que se borran), dila con claridad — pero sin asustar ni culpar.
+5. **Lenguaje cotidiano, no jurídico.** "Documento", "deuda", "plazo" — no "instrumento", "obligación crediticia", "término perentorio". El término técnico solo cuando no hay equivalente simple.
+6. **Mayúscula solo inicial, no Title Case.** Títulos y botones llevan mayúscula en la primera letra nada más: *"Subir documento"*, no *"Subir Documento"*. Los nombres propios de documentos sí se capitalizan: *"Certificado de Dominio Vigente"*.
+7. **Accesible para distintas formas de uso.** El texto debe funcionar para quien lee rápido, usa lector de pantalla, navega con teclado, tiene baja visión, está cansado o necesita volver a revisar. No dependas de posición, color o iconos sin nombrar la acción o el estado.
+8. **Escaneable antes que decorativo.** Usa títulos, subtítulos, labels y agrupaciones que permitan encontrar rápido lo importante. Evita frases genéricas que suenan bien pero no describen la tarea.
+
+---
+
+## 2. Botones y llamados a la acción
+
+**Patrón:** verbo en infinitivo o imperativo, concreto, que dice exactamente qué va a pasar.
+
+- `Continuar`
+- `Subir documento` · `Subir documentos ahora`
+- `Guardar y continuar`
+- `Guardar y enviar para revisión`
+- `Volver al inicio`
+
+**Reglas:**
+- **Di el resultado, no la mecánica.** *"Guardar y enviar para revisión"* es mejor que *"Enviar"* porque anticipa qué ocurre.
+- **Evita "Aceptar / OK" genéricos** cuando puedes nombrar la acción.
+- **Los botones de confirmación restatean la elección.** En vez de Sí/No, el botón repite la decisión en las palabras del usuario:
+  - Pregunta: *"¿Este archivo incluye las 3 liquidaciones?"*
+  - Botones: *"Sí, contiene las 3 liquidaciones"* / *"No, es solo una liquidación"*
+  - Así se elimina la ambigüedad de un Sí/No suelto y queda claro qué se confirma.
+- **Máximo ~4 palabras**, salvo en los botones que restatean.
+- **Un solo verbo por acción en todo el producto.** Para subir archivos, usa siempre **"subir documento"** (no alternes con "adjuntar archivo").
+
+---
+
+## 3. Títulos y encabezados
+
+- **Secciones:** sustantivo, claro y escaneable. *"Documentos financieros"*, *"Documentación personal"*, *"Bienes"*, *"Instrucciones"*.
+- **Títulos específicos.** Un título debe describir el tema o la tarea, no decorar la pantalla. *"Datos de la deuda"* es mejor que *"Tu información"* si la sección trata de deuda.
+- **Palabras importantes al inicio.** La persona debe poder escanear en diagonal y reconocer campos, estados y acciones sin leer párrafos completos.
+- **Agrupa con subtítulos cuando ayuda a evitar errores.** Divide datos personales, deudas, bienes y confirmación si la persona debe revisar cada bloque por separado.
+- **No uses Title Case.** Todo texto de interfaz usa mayúscula solo inicial: títulos, headings, labels, menú, navegación, app bars y botones. Los nombres propios y términos de marca conservan su capitalización.
+- **Ayuda contextual como pregunta del usuario.** Encabeza la ayuda con la duda real, en primera persona:
+  - *"¿Cómo obtener este documento?"*
+  - *"¿Cómo obtener tu clave de boletín comercial?"*
+  - *"¿Necesitas ayuda visual?"*
+  - *"¿Documento rechazado o vencido?"*
+  - *"¿Problemas con un documento? Habla con el asistente virtual"*
+- Usa la pregunta para entradas a ayuda, FAQ, asistente y estados problemáticos. Para títulos de sección operativa, usa sustantivo.
+
+---
+
+## 4. Consecuencias y confirmaciones
+
+Cuando una acción tenga impacto, explica el resultado en lenguaje neutro, directo y verificable. No intentes empujar la decisión con miedo, culpa o dramatización.
+
+**Patrón:** acción + consecuencia + posibilidad de deshacer o corregir, si existe.
+
+- *"Enviar documentos para revisión"* → *"El equipo legal revisará estos documentos. Si falta algo, te pediremos corregirlo."*
+- *"Eliminar documento"* → *"El documento saldrá de esta solicitud. Puedes volver a subirlo antes de enviar."*
+- *"Reiniciar formulario"* → *"Se borrarán los datos ingresados en este paso. Podrás completarlos nuevamente."*
+
+**Reglas:**
+- Di qué pasará si la persona confirma la acción y qué podrá hacer después.
+- Si existe una forma de deshacer, restaurar o corregir, nómbrala en el mismo mensaje.
+- No exageres la consecuencia: evita *"perderás todo"*, *"acción irreversible"* o *"¿estás seguro?"* si puedes explicar el resultado concreto.
+- No suavices una consecuencia real. Si un dato se borra, di que se borra; si queda en revisión, di que queda en revisión.
+- En acciones sensibles, el botón debe repetir la acción concreta: `Eliminar documento`, `Enviar para revisión`, `Reiniciar formulario`.
+
+**Evita:**
+- *"¿Estás seguro?"* sin explicar qué cambia.
+- Mensajes que intentan influir: *"No podrás avanzar si haces esto"* cuando en realidad hay una alternativa.
+- Consecuencias ambiguas: *"Se actualizará tu caso"* sin decir qué se actualiza.
+
+---
+
+## 5. Mensajes de éxito
+
+**Patrón:** exclamación celebratoria breve + qué pasa ahora + dónde hacer seguimiento.
+
+- *"¡Tus documentos fueron enviados con éxito!"* → *"Estamos revisando los documentos. Podrás seguir su estado en la pestaña 'Enviados'."*
+- *"¡Documentos cargados con éxito!"*
+- *"Documentos guardados con éxito"* → *"Tu información se guardó correctamente."*
+
+**Reglas:**
+- El título celebra (con `¡!`); el cuerpo informa el siguiente paso.
+- Nunca termines en el "éxito" a secas: di qué sigue (*"estamos revisando"*, *"podrás seguir su estado"*).
+- Si hay un lugar donde seguir el proceso, nómbralo explícitamente.
+
+---
+
+## 6. Plazos, vencimientos y urgencia
+
+El momento más delicado del tono: comunicar urgencia real **sin asustar**. Combina una consecuencia honesta con una salida siempre abierta.
+
+- *"¡Llegaste al final del plazo!"* → *"Tienes 3 días adicionales para enviar tus documentos. Si no lo haces a tiempo, deberás reiniciar el proceso de documentación desde cero."*
+- *"El plazo ha terminado, por favor sube tus documentos. Tu ejecutiva legal revisará tu información en conjunto con el abogado y te indicará los siguientes pasos."*
+- *"Plazo cumplido. Aún puedes subir los documentos y estudiaremos tu caso."*
+
+**Reglas:**
+- **Siempre deja una puerta abierta.** Incluso con el plazo cumplido: *"Aún puedes subir los documentos y estudiaremos tu caso"*. Nunca un callejón sin salida.
+- **La consecuencia se dice clara pero neutra:** *"deberás reiniciar el proceso desde cero"* es un hecho, no una amenaza. Sin "perderás todo", sin mayúsculas de pánico, sin exclamación en la consecuencia.
+- **Humaniza el proceso.** Mencionar a *"tu ejecutiva legal"* y *"el abogado"* recuerda que hay personas reales acompañando — baja la ansiedad.
+- **Cuenta regresiva con número visible** (*"15 días"*, *"3 días adicionales"*) para que la urgencia sea concreta, no vaga.
+
+---
+
+## 7. Estados de documentos / ítems
+
+Estados cortos, una o dos palabras, consistentes en todo el producto:
+- `Documento subido` · `Aprobado` · `En revisión` · `Documento rechazado` · `Documento vencido`
+
+**Reglas:**
+- Un solo término por estado, en todas las pantallas. No alternes *"rechazado"* / *"no aprobado"* / *"denegado"*.
+- Cuando un estado es problemático (rechazado/vencido), **acompáñalo siempre de la acción de salida**:
+  - *"Si un documento aparece como rechazado o vencido, haz clic en [ícono] para conocer el motivo y subirlo nuevamente."*
+- El estado dice qué pasó; el texto de apoyo dice qué hacer.
+
+---
+
+## 8. Instrucciones y ayuda contextual
+
+Explica el *cómo* paso a paso, con lenguaje de acción directa:
+- *"Completa los datos solicitados y descarga el PDF."*
+- *"Puedes hacer clic en cada imagen para abrirla en tamaño completo."*
+- Referencias concretas a sitios reales: *"www.registrocivil.cl"*.
+
+**Reglas:**
+- Imperativo amable en segunda persona: *"Completa"*, *"Descarga"*, *"Haz clic"*.
+- Pasos en el orden exacto en que se ejecutan.
+- Nombra herramientas y sitios reales sin rodeos; la persona los va a buscar.
+- Cuando ofrezcas ayuda extra, enmárcala como beneficio: *"¿Necesitas ayuda visual?"* antes de explicar el truco.
+- Evita abreviaturas si hay espacio para escribir la palabra completa. Usa *"por ejemplo"* en vez de *"ej."*, *"y otros documentos"* en vez de *"etc."*.
+- Si una abreviatura es necesaria o muy conocida en el dominio, escríbela de forma consistente y con apoyo contextual cuando pueda confundirse. Por ejemplo, `RUT` puede usarse, pero el label debe ser claro: *"RUT del solicitante"*.
+
+---
+
+## 9. Confianza, privacidad y datos sensibles
+
+Cuando pidas algo sensible (una clave, un dato personal), **explica para qué y da garantía** en el mismo momento del pedido.
+
+- *"Tu contraseña se usará solo para validar tu información en el Boletín Comercial, garantizando la confidencialidad y protección de tus datos."*
+
+**Reglas:**
+- Junto al campo sensible, explica **para qué se usa** y **que está protegido**.
+- Acota el uso ("solo para…") — nada de propósitos vagos.
+- Nunca pidas un dato sensible sin justificarlo ahí mismo.
+
+---
+
+## 10. Campos de formulario
+
+- **Placeholder = instrucción de acción:** *"Ingresa tu clave aquí"*.
+- Label corto y claro; el placeholder ejemplifica o instruye, no repite el label.
+- Mensajes de error: di qué pasó y cómo arreglarlo, en tono neutro (*"Ingresa un correo válido"*, no *"Error de validación"*).
+- El label debe existir aunque haya placeholder. El placeholder no reemplaza al label.
+- Si un campo es obligatorio, dilo de forma consistente y accesible; no dependas solo de un asterisco sin explicación.
+- Para botones con solo icono, escribe un `aria-label` claro: `Eliminar deuda`, `Abrir ayuda`, `Cerrar`.
+- Los estados deben leerse como texto: `En revisión`, `Documento rechazado`, `Guardado`, no solo por color.
+
+---
+
+## 11. Glosario de términos preferidos
+
+| Usa | Evita |
+|---|---|
+| documento | instrumento / archivo adjunto |
+| subir un documento | adjuntar archivo |
+| deuda | obligación crediticia |
+| plazo | término / fecha perentoria |
+| revisar tu caso | analizar el expediente |
+| tu ejecutiva legal / el abogado | el equipo jurídico |
+| contraseña | credencial |
+| enviar para revisión | someter a evaluación |
+| por ejemplo | ej. / e.g. |
+| y otros documentos | etc. |
+
+---
+
+## 12. Checklist antes de publicar un texto
+
+1. ¿Está en **tú**?
+2. ¿Se entiende en una lectura, sin jerga jurídica?
+3. Si es un estado o acción, ¿dice **qué pasa después**?
+4. Si hay una consecuencia, ¿está dicha **clara, neutra y sin asustar**, con opción de deshacer o corregir cuando exista?
+5. ¿El botón dice el **resultado concreto** de la acción?
+6. ¿Usa el **término del glosario** y es consistente con el resto del producto?
+7. ¿Mayúscula solo inicial (no Title Case)?
+8. ¿Los títulos y subtítulos permiten escanear la pantalla rápido?
+9. ¿Evitaste abreviaturas innecesarias?
+10. ¿Sobra alguna palabra? Quítala.
+
+> La prueba final: léelo imaginando que se lo dices, de tú, a alguien que está estresado y no sabe de leyes. Si suena claro, cálido y le deja claro el siguiente paso — está listo.

package/templates/scripts/check-geometry.mjs

@@ -0,0 +1,139 @@
+/**
+ * Chequeo del contrato de geometría Lexy — versión para proyectos.
+ * Instalado por `npx create-lexy install-ai`; el contrato se fiscaliza en cada repo.
+ *
+ * Uso:
+ *   pnpm lint:geometry           → valida el contrato (exit 1 si hay violaciones)
+ *   pnpm lint:geometry -- --box  → además imprime la tabla de caja por slot de
+ *                                  cada componente compuesto
+ *
+ * Contrato (resumen — ver ai/pautas/sistema-visual.md):
+ * - Grilla híbrida: múltiplos de 4px para espaciado entre elementos y superficies;
+ *   medio-pasos de 2px permitidos SOLO dentro de un control. Márgenes, posiciones
+ *   y space-* siempre en grilla 4px.
+ * - Valores arbitrarios [..] solo funcionales (vars, %, vh/vw, calc, inherit).
+ * - Radios por rol: aliases `rounded-control`/`button`/`menu-item`/`nav-item`
+ *   para interacción; `rounded-lg` para cards, `rounded-xl` para overlays,
+ *   `rounded-2xl` para media/hero, `rounded-sm` para detalle mini y
+ *   `rounded-full` solo para objetos cuya función es circular.
+ * - Sombras: `shadow-sm` superficies, `shadow-md` flotantes, `shadow-lg` solo
+ *   overlays modales. `shadow-xl` no existe.
+ * - El theme define --radius y sus derivados (toda la escala cuelga de una perilla).
+ */
+import fs from "node:fs/promises";
+import path from "node:path";
+
+const cwd = process.cwd();
+const printBox = process.argv.includes("--box");
+
+const lexy = JSON.parse(await fs.readFile(path.join(cwd, ".lexy"), "utf-8").catch(() => "{}"));
+const componentsDir = path.join(cwd, lexy.paths?.components ?? "src/components/base");
+const themeFile = path.join(cwd, "src/lexy-theme.css");
+
+const GEOMETRIC_ARBITRARY = /^-?(?:p|px|py|pt|pb|pl|pr|m|mx|my|mt|mb|ml|mr|gap|gap-x|gap-y|space-x|space-y|w|h|size|min-w|min-h|max-w|max-h|top|bottom|left|right|inset|rounded(?:-[tblr]{1,2})?|border(?:-[tblrxy])?|text|leading)-\[/;
+const ARBITRARY_FUNCTIONAL = /\[(?:var\(|--|inherit|calc\(|[\d.]+(?:%|vh|vw|svh|dvh))/;
+const SHADOW_LG_ALLOWLIST = new Set(["Dialog", "Sheet", "AppDialog"]);
+const ROUNDED_XL_ALLOWLIST = new Set(["Dialog", "Sheet", "AlertDialog"]);
+const HALF_STEP_ALLOWED = /^(?:p|px|py|pt|pb|pl|pr)-(?:0\.5|1\.5|2\.5)$|^gap-(?:0\.5|1\.5)$|^(?:h|w|size|min-w|min-h)-(?:0\.5|1\.5|2\.5|3\.5)$|^translate-[xy]-0\.5$|^(?:top|right|bottom|left)-(?:0\.5|1\.5|2\.5|3\.5)$|^m[trblxy]?-0\.5$/;
+const HALF_STEP = /^-?[a-z-]+-\d+\.5$/;
+const RADIUS_TOKENS = [
+  "--radius-sm:",
+  "--radius:",
+  "--radius-interactive:",
+  "--radius-control:",
+  "--radius-button:",
+  "--radius-button-lg:",
+  "--radius-menu-item:",
+  "--radius-nav-item:",
+  "--radius-md:",
+  "--radius-lg:",
+  "--radius-xl:",
+  "--radius-2xl:",
+  "--radius-full:",
+];
+
+const CLASS_STRING = /["'`]([^"'`]*)["'`]/g;
+const tokensOf = (source) => {
+  const tokens = [];
+  for (const match of source.matchAll(CLASS_STRING)) {
+    for (const raw of match[1].split(/\s+/)) if (raw) tokens.push(raw);
+  }
+  return tokens;
+};
+const baseUtility = (raw) => raw.split(":").pop();
+
+const violations = [];
+
+const theme = await fs.readFile(themeFile, "utf-8").catch(() => null);
+if (theme === null) {
+  violations.push({ file: "src/lexy-theme.css", token: "(archivo)", rule: "theme ausente" });
+} else {
+  for (const token of RADIUS_TOKENS) {
+    if (!theme.includes(token)) {
+      violations.push({ file: "lexy-theme.css", token: token.replace(":", ""), rule: "token de radius ausente en el theme" });
+    }
+  }
+}
+
+const entries = (await fs.readdir(componentsDir).catch(() => []))
+  .filter((f) => f.endsWith(".tsx"))
+  .sort();
+
+for (const fileName of entries) {
+  const name = path.basename(fileName, ".tsx");
+  const source = await fs.readFile(path.join(componentsDir, fileName), "utf-8");
+  const seen = new Set();
+
+  for (const raw of tokensOf(source)) {
+    const base = baseUtility(raw);
+    const key = `${name}:${base}`;
+    if (seen.has(key)) continue;
+    seen.add(key);
+
+    if (base.includes("[")) {
+      if (!GEOMETRIC_ARBITRARY.test(base)) continue;
+      if (!ARBITRARY_FUNCTIONAL.test(base)) {
+        violations.push({ file: name, token: base, rule: "arbitrario no funcional → usar escala" });
+      }
+      continue;
+    }
+    if (HALF_STEP.test(base.replace(/^-/, "")) && !HALF_STEP_ALLOWED.test(base.replace(/^-/, ""))) {
+      violations.push({ file: name, token: base, rule: "medio-paso fuera de control → grilla 4px" });
+      continue;
+    }
+    if (base === "shadow-xl") {
+      violations.push({ file: name, token: base, rule: "shadow-xl no existe en el contrato → shadow-md" });
+    } else if (base === "shadow-lg" && !SHADOW_LG_ALLOWLIST.has(name)) {
+      violations.push({ file: name, token: base, rule: "shadow-lg solo overlays modales → shadow-md" });
+    }
+    if (base === "rounded-xl" && !ROUNDED_XL_ALLOWLIST.has(name)) {
+      violations.push({ file: name, token: base, rule: "rounded-xl fuera de contrato → rounded-lg" });
+    }
+  }
+}
+
+if (printBox) {
+  console.log("── Tabla de caja por componente compuesto ──\n");
+  const BOX_TOKEN = /^-?(?:p|px|py|pt|pb|pl|pr|gap|gap-x|gap-y|space-y|space-x|m|mx|my|mt|mb|ml|mr)(?:-|$)/;
+  for (const fileName of entries) {
+    const name = path.basename(fileName, ".tsx");
+    const source = await fs.readFile(path.join(componentsDir, fileName), "utf-8");
+    const sections = source.split(/(?=^(?:export\s+)?(?:function|const)\s+[A-Z][A-Za-z0-9]*)/m);
+    const rows = [];
+    for (const section of sections) {
+      const header = section.match(/^(?:export\s+)?(?:function|const)\s+([A-Z][A-Za-z0-9]*)/);
+      if (!header) continue;
+      const boxTokens = Array.from(new Set(tokensOf(section).map(baseUtility).filter((t) => BOX_TOKEN.test(t))));
+      if (boxTokens.length > 0) rows.push(`    ${header[1]}: ${boxTokens.join(" ")}`);
+    }
+    if (rows.length > 0) console.log(`  ${name}\n${rows.join("\n")}\n`);
+  }
+}
+
+if (violations.length > 0) {
+  console.error(`✗ ${violations.length} violaciones del contrato de geometría:\n`);
+  for (const v of violations) console.error(`  ${v.file}: ${v.token} — ${v.rule}`);
+  process.exitCode = 1;
+} else {
+  console.log(`✓ Contrato de geometría: sin violaciones (${entries.length} componente(s) revisados).`);
+}