sistema-de-diseno-nextora

Sistema de diseño Nextora

Autoridad única para la apariencia en este ecosistema. El código de temas hijo, código de bloques, plantillas y patrones difieren aquí para paleta, tipografía, tokens, variaciones de estilo y el conmutador. Carga este skill junto con nextora-child-themes para cualquier nuevo hijo, y con nextora-gutenberg-blocks para cualquier bloque reestilizado o nuevo.

Carga primero estas referencias

Archivo	Léelo para
references/presets-and-switching.md	Identidad canónica de preajustes, variables de rol, almacenamiento de color con ámbito y resolución en PHP, los dos mecanismos de estilo, la puerta de funcionalidad, lo que aporta un hijo, reglas de descubrimiento/fusión, semántica de scheme-switcher.json, precedencia en tiempo de ejecución, valores predeterminados de rol en :root para un nuevo hijo, y la lista de contra-reclamaciones.
../nextora-ecosystem/references/source-map.md	Vocabulario de procedencia y resolución raíz.
../nextora-ecosystem/references/quality-gates.md	Puertas más las recetas de aceptación compartidas aguas abajo (§8).

Los valores citados en la referencia son anclajes, no datos actuales. Vuelve a leer el theme.json del objetivo, su entrada CSS, los archivos styles/ y del conmutador antes de editar.

Flujo de trabajo ordenado

1. Resuelve el objetivo e identifica las fuentes de apariencia activas

Identifica la raíz del tema padre y la raíz del tema activo. Luego lee, en orden: theme.json (paleta, degradados, familias de fuentes, tamaños, espaciado, styles, customTemplates), la entrada CSS que se distribuye (resources/css/app.css para el padre, la entrada del hijo), el árbol styles/, y scheme-switcher.json. Nunca tomes un valor de paleta de un skill, una captura de pantalla o un tema hijo de muestra.

2. Decide qué mecanismo es correcto

Necesidad	Usa
El autor elige un color/tipografía/espaciado para un contenedor de bloque	Soporte de bloque nativo supports + get_block_wrapper_attributes()
Un color dentro de la superficie propia del bloque	Un atributo con ámbito, almacenado como slug de preajuste, resuelto a una variable de preajuste en la salida (§5)
Una apariencia alternativa en todo el sitio que el propietario selecciona y mantiene	Una variación de estilo de theme.json (styles/*.json, styles/typography/*.json)
Una opción de vista previa para el visitante	El conmutador, y solo detrás de su puerta (§6)
Un valor predeterminado de marca para un tema hijo completo	Una contribución de paleta/fuente del hijo más los valores predeterminados de rol en :root (§7)

Prefiere primero los soportes nativos. Añade una sobrescritura con ámbito solo cuando los estilos globales no puedan expresarlo, y nunca inventes un segundo sistema de apariencia aparte de estos.

3. Cambia los preajustes de forma aditiva y por identificador

Añade slugs; no renombres ni redirijas un slug del padre que el contenido heredado ya utiliza. Cada superficie lee var(--wp--preset--color--<slug>), var(--wp--preset--gradient--<slug>) o var(--wp--preset--font-family--<slug>), por lo que un hex literal en CSS del tema excluye esa superficie de los cambios de paleta y del conmutador. Refleja los alias de Tailwind @theme solo donde la compilación CSS los consume, y verifica a qué apunta realmente cada alias en lugar de copiar un bloque de alias de una guía anterior — el --color-secondary del padre actualmente se resuelve al preajuste paragraph.

4. Dirige la tipografía a través de los roles de Nextora

La tipografía del cuerpo, encabezados y botones se resuelve a través de --nextora-font-body, --nextora-font-heading y --nextora-font-button. theme.json usa var(--nextora-font-body); el conmutador escribe esas tres propiedades en línea en <html> con una pila de familias concreta. Una superficie que lee una variable de preajuste directamente no seguirá un cambio de fuente del visitante. Añade o cambia una familia de fuentes en theme.json (con activos fontFace cuando no sea una pila del sistema) y cárgala antes de ofrecerla como opción de preajuste.

5. Almacena colores con ámbito como preajustes, resuélvelos en la salida

Sigue el patrón de ayuda existente en blocks/advanced-icon/color-utils.ts (normalizeColorForStorage, colorValueForPicker) y sus contrapartes en PHP (nextora_icon_resolve_color, nextora_icon_hex_to_preset_slug, nextora_ac_resolve_color): un preajuste elegido almacena su slug; un hex de opacidad completa que coincide con una entrada de paleta se normaliza al slug de esa entrada; los colores personalizados y los hex de 8 dígitos con alfa parcial se mantienen literales; los degradados conservan la identidad del preajuste de la misma manera. En la salida, un slug almacenado se convierte en var(--wp--preset--color--<slug>) para que un cambio de paleta alcance la superficie, y el hex de 8 dígitos se maneja antes de sanitize_hex_color(). Un valor vacío significa "predeterminado del tema" y no emite nada. Reutiliza las firmas reales; no escribas un resolvedor paralelo. Recuerda que un control de color no es un desinfectante: el HTML almacenado aún pasa wp_kses_post().

6. Respeta la puerta del conmutador, y contribuye datos en lugar de código

El conmutador de visitantes existe solo cuando NEXTORA_COLOR_SCHEME_SWITCHER es estrictamente true. Fuera de eso, no hay carga útil, script, CSS de tema de página ni ventana emergente — y no se debe escribir ningún sustituto del lado del hijo para llenar el vacío. Un hijo contribuye datos: styles/color-scheme/*.json, styles/font-preset/*.json, opcionalmente styles/*.json para una variación empaquetada, y una lista blanca opcional scheme-switcher.json. Al crear un nuevo hijo, establece los roles predeterminados del propio hijo en :root en su CSS cargado posteriormente (§7 de la referencia) en lugar de fijar una fuente de preajuste. Nunca añadas una implementación del conmutador a un hijo.

7. Verifica en las superficies reales

Compila con el script propio del objetivo (npm run build:css o npm run build) — nunca edites la salida de assets/css/*, y nunca afirmes que una compilación regenera assets/js/scheme-switcher.js, que se mantiene manualmente y está fuera del pipeline. Luego aplica ../nextora-ecosystem/references/quality-gates.md y su receta del sistema de diseño §8 más los pasos específicos de preajustes en references/presets-and-switching.md §10.

Límites estrictos

• No codifiques una paleta de marca. Los valores provienen de los preajustes activos del objetivo.
• No propagues valores de fallback hex obsoletos de documentos antiguos al nuevo CSS del tema.
• No reimplementes el conmutador, y no afirmes que funciona porque un hijo de muestra se ve bien: la muestra fija sus propias fuentes y añade entradas de paleta solo para el hijo.
• No prometas que un parámetro de URL de color sobrescribe un tema empaquetado ya resuelto, o que el Restablecimiento borra los estilos del Editor del Sitio.
• No reestilices la interfaz de wp-admin desde una hoja de estilo del tema; los reinicios del editor permanecen dentro del lienzo del editor.
• No aumentes silenciosamente el mínimo declarado de WordPress/PHP — en su lugar, expón el requisito.
• No modifiques el tema padre o el tema hijo de muestra mientras realizas este trabajo.

Comprobaciones de finalización

• Tema objetivo resuelto; cada preajuste, fuente, degradado y token referenciado existe en el theme.json/variaciones de ese tema.
• Se siguió la tabla de mecanismos del paso 2; se usaron los soportes nativos donde sean suficientes.
• La tipografía se resuelve a través de los roles --nextora-font-* y sigue un cambio de preajuste.
• Los colores con ámbito almacenan un slug de preajuste donde el color coincide con un preajuste, mantienen los valores personalizados y alfa parcial como literales, y se renderizan a través de variables de preajuste.
• Se respeta la puerta del conmutador; la contribución del hijo son solo datos; cualquier par predeterminado de nuevo hijo se declara en :root a través de los roles.
• Las variaciones de estilo (persistentes) y el conmutador (vista previa en tiempo de ejecución) se describen y prueban como cosas diferentes.
• Los pasos de aceptación del §8 se ejecutaron contra los estilos calculados, o la superficie no verificada se reporta claramente.

Límites

Solo instrucciones en Markdown y referencias respaldadas por el código fuente: sin scripts de tiempo de ejecución, generadores, árboles de tema copiados, gestión de paquetes o automatización de instalación, y sin ediciones en las fuentes del tema padre o hijo. Los comandos de compilación aguas abajo y verificación en navegador pertenecen al tema objetivo y se enumeran en ../nextora-ecosystem/references/quality-gates.md.