Laboratorio del componente Button. Esta sección muestra las variantes globales actuales antes de normalizar estados, semántica de color y responsabilidades de espaciado.

Principio: kitlu-button define la base común del control interactivo. Las variantes kitlu-button--primary y kitlu-button--secondary definen jerarquía visual. El botón expresa una acción; no debe asumir la composición del bloque que lo contiene.

Composiciones validadas:
kitlu-button + kitlu-button--primary para la acción principal.
kitlu-button + kitlu-button--secondary para una acción secundaria.
Ambas variantes pueden convivir en un mismo grupo siempre que exista una jerarquía clara entre ellas.

Reglas de mantenimiento: no crear variantes por tipo de contenido o destino cuando la diferencia sea solo semántica. El espaciado entre varios botones pertenece al contenedor de acciones, no a la intención del botón. Los CTAs y otros patrones deben reutilizar estas clases globales en lugar de recrear estilos locales.

Dimensión y composición: todas las variantes de Button deben compartir la misma altura visual mediante la clase base kitlu-button. La diferencia entre primary y secondary es únicamente de tratamiento visual, no de caja. Los márgenes exteriores no pertenecen al botón: la separación entre varias acciones debe resolverla siempre el contenedor que las agrupa mediante gap.

Laboratorio del patrón CTA. El CTA organiza contenido y acciones; los botones conservan su propia responsabilidad como controles interactivos.

Patrón de CTA de mayor jerarquía con contenido y media en dos zonas. En una columna, el contenido precede a la imagen; desde L se convierte en una composición 50/50.

Laboratorio del componente Badge. La base resuelve forma y escala; las variantes cambian únicamente el tratamiento visual y el grupo organiza separación y wrapping.

Principio: kitlu-badge es una unidad informativa breve. La clase base resuelve escala, forma y alineación; las variantes modifican únicamente el tratamiento visual. Un badge informa, clasifica o señala estado, pero no debe utilizarse como decoración ni sustituir texto necesario para comprender el contenido.

Variantes validadas:
kitlu-badge + kitlu-badge--subtle: tratamiento discreto para categorías, años, formatos o información auxiliar.
kitlu-badge + kitlu-badge--outline: alternativa transparente con borde semántico cuando no se desea añadir otra superficie.
kitlu-badge + kitlu-badge--accent: énfasis reservado para estados o señales realmente relevantes, como Destacado o Actualizado.

kitlu-badge-group organiza varias unidades, controla el gap y permite wrapping. Los badges individuales no deben incorporar márgenes exteriores para resolver su relación con otros badges.

Semántica y accesibilidad: la información no debe depender únicamente del color. Si el badge comunica un estado como Nuevo, Destacado, Actualizado o Cerrado, ese significado debe aparecer también en el texto. El componente base es informativo; si en un proyecto una etiqueta necesita ser clicable o seleccionable, deberá tratarse como un control interactivo específico y no convertir silenciosamente kitlu-badge en un botón.

Reglas de mantenimiento: no crear variantes por tipo de contenido como badge--noticia, badge--documento o badge--curso cuando la diferencia sea solo semántica. Reutilizar las variantes visuales existentes y cambiar el texto. Mantener tipografía, padding, radio, color y borde mediante tokens del sistema. No añadir iconos como requisito base. Evitar el uso masivo de kitlu-badge--accent; su utilidad depende de conservar una jerarquía visual excepcional.

Laboratorio del acordeón anidable de Bricks. El componente mantiene una presentación neutra y editorial: jerarquía clara, separadores ligeros y contenido libre de tratamientos decorativos.

Principio: kitlu-accordion organiza la relación entre encabezado y contenido desplegable. Su responsabilidad es abrir, cerrar y jerarquizar; no debe imponer cómo se presentan los componentes que viven dentro del contenido.

Anatomía:
kitlu-accordion: raíz estructural y separadores del conjunto.
kitlu-accordion__title: encabezado interactivo, padding, alineación y estados de foco/abierto.
kitlu-accordion__content: contenedor libre para texto, imágenes, botones, Cards, Grids o resultados dinámicos.
kitlu-accordion__icon: indicador visual del estado.
kitlu-accordion__title--surface: modificador opcional que fondea el título con var(--kitlu-color-background), actualmente resuelto por var(--kitlu-primitive-neutral-1).

Query Loop: el bucle debe aplicarse al elemento que se repite dentro de accordion-content-wrapper, no al acordeón completo. De esta forma, Accordion gestiona la interacción, Query Loop repite y Card/Listing presenta cada resultado. El contenido dinámico puede reutilizar las clases globales existentes sin crear un sistema paralelo.

Reglas de mantenimiento: preferir Accordion Nested nativo de Bricks y conservar sus atributos de accesibilidad. Mantener los estilos fundacionales en XS/Base. No crear variantes por tipo de contenido como accordion--agenda o accordion--faq cuando la diferencia sea solo semántica. La variante kitlu-accordion__title--surface añade jerarquía visual sin modificar la anatomía. No usar el acordeón para ocultar información esencial.

Laboratorio del componente Tabs Nested de Bricks. Las pestañas organizan bloques equivalentes de contenido sin convertir la navegación en una colección de botones decorativos.

Principio: kitlu-tabs organiza contenidos paralelos y equivalentes. La navegación cambia de panel; el contenido interior mantiene su propia responsabilidad. Tabs no debe utilizarse simplemente para ocultar información ni para sustituir una lectura secuencial cuando Accordion o una composición abierta resulten más claras.

Anatomía base:
kitlu-tabs: raíz estructural.
kitlu-tabs__menu: contiene las pestañas y controla separación, wrapping y línea de navegación.
kitlu-tabs__title: control interactivo de cada pestaña y estado activo.
kitlu-tabs__content: contiene los paneles y su espaciado interior.

Las etiquetas deben ser breves y comprensibles. El comportamiento base se activa por clic y debe existir una pestaña activa al cargar, normalmente la primera.

Variantes validadas:
kitlu-tabs__title--surface añade fondo neutral, borde y radio mediante tokens del sistema, con una separación inferior ligera respecto a la línea del menú.
kitlu-tabs--vertical mantiene la navegación horizontal en XS/S/M y, desde L, pasa a menú lateral con panel de contenido a la derecha. En escritorio el estado activo se señala mediante borde derecho de acento.

Estas variantes cambian la presentación, no la semántica ni la anatomía del componente.

Contenido dinámico, accesibilidad y mantenimiento: un Query Loop debe vivir dentro del panel correspondiente y aplicarse al elemento que realmente se repite; Tabs cambia de panel, Query Loop repite y Card/Listing/Grid presenta el resultado. Conservar la estructura nativa de Tabs Nested de Bricks para mantener tablist, tab, tabpanel, aria-selected y aria-controls. No crear variantes por tipo de contenido como tabs--programa o tabs--recursos cuando solo cambia el significado del panel. Si las pestañas son demasiadas, sus etiquetas son largas o el contenido debe recorrerse de forma secuencial, reconsiderar el patrón antes de añadir más estilos.

Laboratorio del popup nativo de Bricks. La prueba se limita a esta página y utiliza una composición modal sencilla para validar contenido, acciones, backdrop y cierre.

Principio: Popup es una capa modal para mostrar información o una acción secundaria sin abandonar el contexto actual. En LuSiteKit se construye con el sistema nativo de plantillas Popup de Bricks; la plantilla controla backdrop, tamaño, posición, condiciones y cierre, mientras que las clases kitlu-popup* organizan el contenido interior.

Anatomía base:
kitlu-popup: estructura interior general.
kitlu-popup__header: título e introducción.
kitlu-popup__body: contenido principal, libre para texto, formularios, imágenes, Cards u otros componentes.
kitlu-popup__actions: organiza las acciones y neutraliza márgenes exteriores de Button. Los botones reutilizan siempre kitlu-button*.

Interacción y accesibilidad: la apertura y el cierre deben resolverse mediante las interacciones nativas de Bricks. El popup necesita una vía de cierre explícita dentro del contenido y puede permitir además cierre sobre el backdrop o con ESC según el caso. Mantener el enfoque automático salvo una razón concreta para desactivarlo y evitar utilizar la modal para ocultar información esencial que debería formar parte de la lectura normal de la página.

Reglas de mantenimiento: las condiciones de la plantilla determinan dónde existe el popup y no deben sustituirse por variantes visuales por tipo de contenido. El tamaño y la superficie pertenecen a la plantilla Popup; la composición interna pertenece a kitlu-popup*. Las acciones conservan la anatomía común de Button: misma altura, padding y alineación; su jerarquía se expresa únicamente mediante las variantes visuales. No crear popup--formulario, popup--aviso u otras variantes cuando la diferencia sea solo el contenido.

Laboratorio del Slider Nested nativo de Bricks. El carrusel controla desplazamiento, navegación y cantidad visible; cada slide conserva libertad para alojar componentes del sistema.

Principio: kitlu-slider controla desplazamiento, navegación y cantidad visible. Cada slide conserva libertad para alojar componentes del sistema sin que Slider redefina su presentación.

Anatomía:
kitlu-slider: raíz del Slider Nested nativo de Bricks/Splide.
kitlu-slider__slide: unidad repetible, estática o dinámica. Puede combinarse con Card, Listing u otros componentes existentes.
En Query Loop, el elemento que representa el slide repetido lleva hasLoop:true; Slider desplaza, Query Loop repite y Card/Listing presenta.

Comportamiento validado: un elemento visible en XS, dos desde M y tres desde L; desplazamiento de una unidad; teclado cuando el slider tiene foco; flechas y paginación activas; autoplay desactivado como comportamiento base. El patrón responsive se expresa con las opciones nativas de Splide dentro del Slider Nested de Bricks.

Navegación visual: las flechas se sitúan hacia dentro del carrusel, sin borde, con fondo neutral translúcido e icono semitransparente en reposo; hover y focus aumentan su presencia. La paginación se coloca debajo del contenido, centrada, con puntos inactivos neutros y activo en color de acento. Los controles no deben competir con el contenido del slide ni ocultarlo innecesariamente.

Reglas de mantenimiento: no usar autoplay por defecto ni crear variantes por tipo de contenido como slider--noticias o slider--recursos. Mantener el contenido interior independiente del componente de navegación. Reutilizar tokens semánticos para color, foco, espaciado y forma, y conservar las interacciones y accesibilidad nativas de Bricks/Splide siempre que sea posible.

Laboratorio del Offcanvas nativo de Bricks. El panel lateral sirve para alojar navegación secundaria, filtros o información contextual sin abandonar la página.

Principio: Offcanvas es un panel lateral auxiliar para contenido que complementa la tarea principal sin abandonar la página. En LuSiteKit se construye con el elemento Offcanvas nativo de Bricks; el componente controla apertura, cierre, dirección, backdrop y foco, mientras que las clases kitlu-offcanvas* organizan el contenido interior.

Anatomía base:
kitlu-offcanvas: raíz y tratamiento visual general.
kitlu-offcanvas__panel: superficie lateral y espaciado interior.
kitlu-offcanvas__header: título e introducción.
kitlu-offcanvas__body: contenido principal.
kitlu-offcanvas__actions: acciones del panel y responsable del gap entre botones.

Interacción y accesibilidad: abrir y cerrar mediante interacciones nativas de Bricks. Mantener una acción de cierre explícita dentro del panel, un aria-label descriptivo y autofocus salvo una razón concreta para desactivarlo. El patrón base bloquea el scroll del body mientras está abierto y utiliza un backdrop suave para conservar el contexto de la página.

Usos recomendados y mantenimiento: navegación secundaria, filtros, ayuda e información contextual. Offcanvas no sustituye Popup: el primero mantiene una relación lateral con la página; el segundo interrumpe deliberadamente la lectura como capa modal. No crear variantes por tipo de contenido como offcanvas--filtros u offcanvas--menu cuando la diferencia sea solo semántica. Los componentes interiores conservan sus propias responsabilidades y estilos.

Laboratorio del elemento Form nativo de Bricks. Esta primera prueba fija la apariencia y los estados básicos de los campos sin vincular el formulario a un envío real.

Laboratorio equivalente construido con Pro Forms de Bricksforge. Cada campo es un elemento independiente y el layout puede organizarse con gap real sin alterar la anatomía de los controles.

Criterio de implementación: Pro Forms de Bricksforge es la solución preferente para formularios en LuSiteKit. El Form nativo de Bricks queda como recurso básico o fallback cuando no se necesiten campos nestables, composición avanzada, validación granular o lógica adicional.

Arquitectura: kitlu-proform define la composición general del formulario y el lenguaje visual común de labels, campos, foco, placeholders y controles. Cada campo de Pro Forms es un elemento independiente. kitlu-form-field--full permite que un campo ocupe todas las columnas cuando el formulario adopta layout multicolumna.

Layout responsive: el formulario se resuelve en una columna en XS/S/M. Desde L puede pasar a dos columnas con gap real del sistema. Los campos que deben conservar todo el ancho, como select, textarea, privacidad y submit, usan kitlu-form-field--full. No pegar campos mediante porcentajes sin separación.

Controles y estados: mantener labels visibles, marcar los campos obligatorios en el label y no duplicar el asterisco en el placeholder. Inputs, select y textarea comparten superficie, borde, radio, tipografía y altura mínima del sistema. El foco debe ser siempre visible. Checkbox y radio usan el color primario como acento, y los estados de error o éxito deben comunicarse también mediante texto, nunca solo mediante color.

Submit: el botón de envío de Pro Forms debe reutilizar directamente kitlu-button + kitlu-button--primary. Las clases globales de Button están preparadas para funcionar tanto sobre botones Bricks como sobre el .bricks-button generado por Pro Forms, de modo que altura, padding, tipografía, radio, color y hover se mantengan consistentes.

Reglas de mantenimiento: no crear variantes de formulario por finalidad editorial cuando solo cambia el contenido. La estructura y estados pertenecen al sistema de formulario; la acción visual pertenece a Button. Aprovechar los elementos nestables y las capacidades propias de Pro Forms para select, checkbox, radio, validación, condiciones o formularios multistep antes de recurrir a soluciones paralelas.