¿Qué hace Lieflat Charts — Código de Estilo de Gráficos?

Lieflat Charts es un skill de visualización de datos que sigue el formato Agent Skills. Utiliza la escala de grises Mono como base, pero selecciona automáticamente una paleta de color predefinida cuando el contexto semántico y de uso lo requiere. Se enfoca en convertir datos en contenido visual con estilo editorial, legible y capaz de formar páginas completas. Este skill se creó en moxt.ai y admite la edición narrativa tipo Lupi, la visualización rápida tipo Glance, la edición básica tipo Basics y los gráficos interactivos a gran escala. El usuario proporciona datos y contexto, y tú generas un archivo HTML autónomo que se puede abrir con doble clic sin necesidad de compilación; modificar los datos solo requiere cambiar un array en la parte superior. Los gráficos SVG puro funcionan sin conexión; los que usan Chart.js, ECharts o fuentes en línea requieren conexión a internet si no están incrustados. Por defecto, primero debes seleccionar entre Lupi Editorial y Lupi Basics; solo si ninguno de estos tiene una plantilla adecuada, o si el usuario solicita explícitamente Glance / dashboard / lectura rápida de 3 segundos, se permite usar Glance.

No es necesario que el usuario active explícitamente los colores. Sigue la Sección 6.5 para elegir automáticamente entre Mono y los tres conjuntos predefinidos de color-presets.js; si el usuario proporciona colores de marca o valores de color personalizados, puedes crear una paleta custom para la entrega. Un mismo HTML o grupo de entregas solo puede usar un sistema de color, sin mezclas. Las muestras de cambio de tema están en templates/color/.

Cómo consultar el código de referencia de un gráfico: busca el tipo de gráfico en el catálogo → abre el archivo gallery correspondiente → encuentra el bloque <div class="card"> por el título de la tarjeta para ver la estructura → busca en <script> el bloque de comentarios // ════ con el mismo nombre para obtener el código de renderizado. No copies la página completa: el gallery contiene múltiples tarjetas; la entrega al usuario siempre debe ser un archivo de gráfico único, ensamblado según el esqueleto de la Sección 9.

El público objetivo son no programadores (escritores, operaciones, creadores de presentaciones). Hablan en lenguaje natural ("Ayúdame a dibujar las conversiones de este trimestre para el artículo de WeChat"), no nombran tipos de gráficos. Tu trabajo es traducir ese lenguaje natural al gráfico correcto, con una calidad visual que pueda publicarse directamente.

Cero: Restricción Estricta de Prioridad de Plantillas

Las siguientes reglas no son sugerencias; cualquier violación requiere reelaboración:

Debes generar desde las plantillas del repositorio. Cada gráfico final primero debe identificar el número de tipo en catalog.md, luego abrir la implementación real del gallery correspondiente: Lupi usa templates/lupi-gallery.html, los tipos básicos usan templates/basics-gallery.html, Glance usa templates/glance-gallery.html, y los gráficos interactivos grandes usan templates/big-*.html. Los gráficos en color también toman estas plantillas originales como base estructural; templates/color/ solo se usa para consultar combinaciones de colores.
Debes mantener el esqueleto de código de la plantilla seleccionada. Partiendo del <div class="card"> correspondiente al título de la tarjeta y el bloque de comentarios // ════ Nombre del Gráfico ════ del mismo nombre, conserva la estructura central SVG / Canvas / ECharts, la codificación de datos, las proporciones y el ritmo de animación. Está permitido reemplazar datos, títulos, notas al margen, fuentes y ajustes de diseño necesarios; está prohibido dibujar un gráfico "similar" sin usar la plantilla, combinar varias plantillas para crear un tipo híbrido, o volver a los estilos predeterminados de la biblioteca de gráficos.
El orden de selección predeterminado es fijo. Primero compara completamente Lupi Editorial (L1–L15), luego Lupi Basics (F1–F13). Si existe una plantilla que pueda representar honestamente los datos, contener las etiquetas y ser legible, debes elegir de estos dos grupos.
Glance es un plan de degradación predeterminado, no una opción principal. Solo si Lupi Editorial y Lupi Basics no son adecuados, o si el usuario solicita explícitamente Glance, dashboard, monitoreo, informes semanales o lectura rápida de 3 segundos, puedes usar Glance. Antes de degradar, debes escribir explícitamente por qué Lupi / Basics no son adecuados.
Crear un nuevo tipo fuera del catálogo es el último recurso. Cuando Lupi, Basics, Glance y las plantillas interactivas no puedan soportar el caso, puedes seguir el proceso de traducción de la Sección 6; el nuevo gráfico aún debe heredar la sintaxis visual y la estructura de código de la plantilla de gallery más cercana.

Uno: Flujo de Trabajo (Sigue estos seis pasos en cada solicitud)

Determina la forma de los datos. No preguntes al usuario qué gráfico quiere; observa cómo son sus datos: ¿comparación de varias categorías? ¿serie temporal? ¿proporciones? ¿valores positivos y negativos? ¿pertenencia multia-unívoca? ¿red? ¿distribución de registros individuales? La forma es la clave para seleccionar el gráfico.
Audita primero Lupi y Basics. Escanea todas las plantillas candidatas de Lupi Editorial (L1–L15) y Lupi Basics (F1–F13) que puedan soportar la forma de los datos. Compara al menos 3 candidatos; si hay menos de 3, enumera todos. Evalúa la adecuación semántica, la honestidad de las unidades, la capacidad de las etiquetas, la velocidad de lectura, el impacto narrativo y si el tipo ya se ha repetido en este lote.
Solo verifica Glance si es necesario. Solo si todos los candidatos de Lupi y Basics fallan, o si el usuario solicita explícitamente Glance / dashboard / monitoreo / informe semanal / lectura rápida de 3 segundos, escanea Glance (G1–G18). Al seleccionar Glance, registra por qué Lupi y Basics no pueden soportar el caso; no escribas simplemente "Glance es más intuitivo".
Fija la plantilla real, luego organiza la página completa. Cada gráfico debe registrar el sistema, el número de tipo, el archivo gallery y el título de la tarjeta, y usar la estructura real y el código de renderizado de esa tarjeta como esqueleto. Está prohibido pensar primero "esta página contará seis cosas" y luego inventar gráficos sobre la marcha; la narrativa de la página solo se puede organizar después de fijar la plantilla.
Forma lotes según la regla de número de gráficos. Un gráfico solo debe representar una conclusión independiente; después de eliminar conclusiones duplicadas, sigue los intervalos predeterminados de la Sección 1.1 para determinar la cantidad. Las plantillas deben asignarse globalmente: no repetir, no apilar el mismo contorno, no agregar gráficos forzados para completar el número.
Renderiza según la plantilla y autoverifica (Secciones Cero, Dos, Tres, Ocho). Revisa elemento por elemento si el producto final aún corresponde a la implementación del gallery seleccionado; no debes cambiar la geometría central, la codificación o los efectos de la plantilla solo por modificar los datos. Sigue la Sección 6.5 para elegir Mono o un conjunto de paletas de color predefinido para toda la entrega; los tipos de gráficos fuera del catálogo siguen el proceso de traducción (Sección 6).

1.1 Regla de Número de Gráficos

La cantidad de gráficos está determinada por el número de conclusiones independientes, no por "cuántas columnas de datos hay", y no exige fijamente 5 o 6 gráficos:

Tipo de solicitud	Cantidad predeterminada de productos	Regla
Una sola pregunta / una tabla / un indicador	1	Entrega solo el mejor gráfico, no expandas para mostrar plantillas
Dos o tres conclusiones claras	2–3	Cada gráfico asume una conclusión diferente, pueden compartir la misma fuente de datos
Un artículo, tesis o caso completo	4–6	Cubre diferentes formas de datos: resumen, composición, comparación, relación o cambio
Usuario solicita una cantidad explícita	Según el usuario	Aún así elimina gráficos duplicados; si no hay suficientes, explica y haz menos

El límite predeterminado por página es de 6 gráficos; si se supera, divide en varias páginas o entrega por capítulos.
Las soluciones candidatas y los borradores de comparación Glance/Lupi no cuentan en el número final de gráficos; son parte del proceso de selección, no del lote final.
Una página con varios gráficos debe tener al menos una conclusión de resumen; los demás gráficos deben proporcionar nuevas dimensiones de comparación, relaciones, cambios temporales o evidencia detallada.
Si dos gráficos expresan la misma conclusión, conserva solo el que sea más adecuado para el contexto de lectura y tenga un contrato de datos más honesto.

Dos: Sintaxis Mono · Reglas Estrictas (Violación = Reelaboración)

Se hace referencia por defecto a mono-tokens.js (al distribuir en código abierto, incrusta el contenido en el HTML). Cualquier valor que entre en conflicto con los tokens debe respetar los tokens. Al usar color, solo se reemplazan los tokens de color; las fuentes, los bordes redondeados, el diseño y las animaciones aún se rigen por mono-tokens.js.

Colores

Por defecto, solo dos polos: gris papel #F0EFEB y negro carbón #1C1C1A, con 7 niveles de gris intermedios. Las excepciones de color comienzan desde las predefinidas según la Sección 6.5.
El brillo es el dato: lo más importante = lo más oscuro (en tarjetas oscuras, se invierte: lo más brillante). Las series múltiples se asignan a lo largo de la escala de grises según su importancia, no se toman al azar en orden.
Siempre sólido: sin materiales transparentes, sin brillo, sin filtros de degradado, sin sombras. La textura proviene únicamente del contraste de brillo y las formas. La única excepción: en gráficos de superposición (Radial Patchwork), la transparencia codifica la densidad (es dato, no decoración).
Tarjeta oscura (.card.dark): solo se permite para dos tipos de gráficos: formas que requieren fondo oscuro (pétalos, líneas/luz con brillo/redes). Por defecto, tarjeta clara; por pantalla (4 tarjetas), máximo 1 tarjeta oscura.

Tipografía

Familia Inter completa. Títulos 700 / valores numéricos en el gráfico 800 / etiquetas de eje 600. La estructura de la tarjeta es fija en cuatro partes: título de conclusión (h2) + subtítulo (leyenda y rango temporal, separados por ·) + gráfico + línea de fuente (en mayúsculas, con espaciado entre letras).
El título escribe la conclusión, no el nombre del tipo de gráfico: "Ingresos por plan" está bien, "Gráfico de barras" no; mejor aún con un juicio: "Donde ganamos, donde perdimos".
Tamaño mínimo de fuente SVG: tarjeta de media anchura 6.5px, ancho completo 5.5px. La información que no cabe se muestra al pasar el cursor; no se reduce el tamaño de fuente para forzar la inclusión.

Formas

Bordes redondeados de tarjeta de 24px, sin borde ni sombra, separación por espacios en blanco. Las barras tienen bordes redondeados en los extremos (barras verticales: extremo superior redondeado; barras horizontales: extremo exterior redondeado).
Los gráficos de barras no deben tener el eje truncado. El contrato de una barra es longitud ∝ valor; truncar el eje rompe el contrato. La forma correcta de manejar valores extremos: ① dejar que el valor extremo se dispare (lo más honesto) ② gráfico principal + lupa ③ romper la barra, no el eje (indicar explícitamente que no cabe).
Los pétalos (costuras negras gruesas + pétalos de ángulo redondeado) solo son adecuados para gráficos radiales con divisiones iguales o aproximadamente iguales. Los sectores de ancho muy diferente se ocultan entre sí, reduciendo la legibilidad.

Animaciones

Las animaciones de entrada están activadas por defecto, con quarticOut para una entrada rápida y parada suave, sin rebotes (las ondas pueden usar elasticOut). Puntos con stagger de 8–15ms/unidad, barras con 80–130ms/barra.
Mecanismo de revelado unificado: se reproduce al entrar en la vista + se reproduce al hacer clic (usando obsReveal del token, con limpieza por temporizador).
Debe incluir degradación para prefers-reduced-motion (ya incluido en el CSS del token).
La animación no puede superar a la estructura: un efecto que requiere inventar un nuevo diseño para colocarse no merece existir.

Datos

Para datos de demostración, usa rnd(i,k) del token para pseudoaleatoriedad determinista; está prohibido Math.random(): la actualización debe tener el mismo aspecto.
Los valores y lo visual deben ser estrictamente proporcionales. La codificación de área usa Math.sqrt(v) para convertir el radio; está prohibido usar el valor directamente como radio.

Tres: División de Trabajo de Dos Sistemas de Estilo

Bajo la misma paleta mono, hay dos visiones del mundo. La elección depende del contexto y de cuántos segundos el lector está dispuesto a dedicar:

	Sistema Glance (18 gráficos)	Sistema Lupi (lectura detallada, 15 gráficos)
Unidad básica	Forma (barras gruesas, arcos grandes, bloques de color)	Registro (un punto = un dato)
Líneas	2px+, con contundencia	0.5–0.7px, como un cabello
Agregación	Agregada previamente, da la conclusión	Rechaza la agregación, muestra la materia prima
Lectura	Un vistazo (<10s)	Lectura cercana (30s+)
Contexto	Informes semanales, dashboards, notas rápidas	Informes anuales, páginas de historias externas, carteles
Motor	Chart.js / ECharts	SVG escrito a mano

Estrategia predeterminada: Lupi Editorial → Lupi Basics → Glance. Sin un contexto claro, está prohibido usar Glance por defecto. Al crear informes anuales, artículos largos para WeChat, carteles, README de código abierto o portafolios, elige primero Lupi Editorial; cuando los datos son menos o se adaptan a tipos de gráficos familiares, elige Lupi Basics. Solo si los dos primeros grupos no tienen plantillas adecuadas, o si el usuario solicita explícitamente dashboard, monitoreo, informes semanales o lectura rápida de 3 segundos, entra en el grupo candidato de Glance.

La auditoría completa de candidatos no significa "hacer todos los gráficos". Primero, filtra los candidatos que puedan codificar la misma entidad según la forma de los datos. Luego, divide los candidatos en:

Semánticamente adecuados: cada punto, línea, área o cuenta tiene una unidad real o un criterio de agregación claro.
Visualmente adecuados: las etiquetas caben, la densidad es suficiente, el lector puede leer en el tiempo esperado.
Narrativamente adecuados: la forma del gráfico puede soportar el juicio que estos datos deben contar, no solo mostrar los números.

La selección final es la intersección de los tres criterios, no "qué archivo de plantilla es más fácil de copiar". La auditoría predeterminada se completa primero dentro de Lupi Editorial y Lupi Basics; solo si ambos grupos fallan, se extiende a Glance. Si se deben hacer varios gráficos en el mismo lote, asigna globalmente entre los candidatos: sin repetir plantillas, alternando formas, máximo una tarjeta oscura, evitando que toda la página se convierta en seis anillos o barras similares.

Pocos datos (solo unos pocos porcentajes) no significa solo Glance. El camino correcto para Lupi es la descomposición en unidades: desagregar los números agregados en unidades contables (1 punto = 1 persona / 1 punto porcentual); la densidad proviene de las unidades, no del número de registros. Escribe el significado de las unidades en el subtítulo; solo descompón unidades honestas (si la suma de porcentajes es 100 → 100 puntos). Si al redondear la suma no llega a 100 (por ejemplo, 49.0+27.4+13.9+5.0+3.2 → 98), indica en la nota al pie "otros N fueron redondeados", no inventes unidades falsas.

Prioridad de ruta para pocos datos en Lupi (validado en múltiples casos):

Escanea completamente primero, luego elige el esqueleto de código — El grupo de tipos básicos F1–F13 (templates/basics-gallery.html) son el vocabulario Lupi para datos dispersos: barras/líneas/áreas/anillos/barras horizontales/agrupadas/apiladas/dispersión/cascada/calor/progreso/mancuernas/mapa de rectángulos; los tipos editoriales L1–L15 proporcionan sintaxis para registros individuales, descomposición en unidades, relaciones y anotaciones. No elijas directamente un gráfico F solo porque basics-gallery.html tiene código listo.
Comienza con la plantilla más cercana a la entidad — Para preguntas de opción múltiple, compara primero L15, F5, L2; para composición 100%, compara L14, L5, F4, G4; para embudo, compara L13, la expresión degradada de F1/F5. La selección se basa en la forma de codificación de datos, no en el orden del archivo.
Solo crea uno nuevo si realmente no hay una forma correspondiente en el catálogo, y la nueva creación debe extender la sintaxis existente del gallery (ticks finos, vibración determinista rnd, resplandor paint-order, anotaciones en mayúsculas); no se permite agregar referencias externas — "estilo Lupi" se refiere a la sintaxis visual de los gráficos del gallery, no al estilo dibujado a mano de Giorgia Lupi.
Los gráficos de pocos datos creados nuevos deben estar acompañados de una capa completa de estructura ambiental: la mitad de la belleza del gallery proviene del mobiliario sin datos (líneas horizontales de papel de contabilidad, guías punteadas, marcas de borde rim, cuadrícula de postes cada 10 unidades, líneas de anotación). La capa de datos es honestamente escasa; el presupuesto de densidad se gasta en el mobiliario. Un gráfico de pocos datos que solo dibuja los datos + una línea base inevitablemente parecerá pobre.

En el mismo lote de producción (varios gráficos en una página), las plantillas no se repiten. 15 gráficos Lupi son suficientes para rotar; cuando varios candidatos pueden soportar los mismos datos, elige el que aún no se haya usado en este lote.

Cuatro: Árbol de Decisiones de Tipos de Gráficos (Forma de Datos → Candidatos)

Los números corresponden a catalog.md. Estos son solo tablas de recuperación de candidatos; las flechas y el orden de escritura no representan prioridad. La selección real debe cumplir: primero revisa todos los candidatos de Lupi Editorial y Lupi Basics; solo si no hay plantillas adecuadas, se permite usar candidatos de Glance.

Comparación de pocas categorías (≤8) → G3 Chunky Bars ⇄ vertical F1 Rung Bars / horizontal F5 Tick Rows ⇄ L2 Dot Cascade (⚠️ cascade: nombres de categorías verticales, solo se puede usar cuando el nombre tiene ≤4 caracteres o es una abreviatura corta; categorías largas en chino deben usar F5/L5/L12)
Porcentajes de opción múltiple (cada ítem 0–100, suma puede exceder 100) → G3 Chunky Bars ⇄ L15 Ballot Tally
Distribución de múltiples categorías (30–60 barras) → G12 Stagger Wave
Valores categóricos con positivos y negativos → G10 Diverging Bar
Proporciones / composición 100% → G4 Dot Waffle ⇄ L14 Hundred Field ⇄ F4 Tick Donut (alternativa predeterminada a los gráficos circulares); divisiones aproximadamente iguales y con impacto visual → G2 Petal Rose; codificación doble proporción × intensidad → G13 Big Slice; apilado por categoría → F7 Stacked Rungs
Comparación de dos puntos temporales (antes/después) → A nivel de categoría (≤6 categorías) → F12 Dumbbell Queue (horizontal, cuentas = unidades reales) ⇄ F6 Paired Rungs (dos escaleras lado a lado); solo 2–4 series para dibujar línea de tendencia → Glance chunky slope (línea gruesa, números grandes, conclusión en el título). Las pendientes con muchos cruces reducen la legibilidad; no agregues estructura decorativa para forzar un estilo Lupi.
Secuencia diaria (≤30 días, con rango) → G1 Range Capsules ⇄ lectura diaria F2 Hairline Line ⇄ (escala de 90 días, con textura) L3 Barcode Lollipop; 30–60 días para ver la forma → F3 Hairline Area
Crecimiento acumulado → G18 Draw-in + Counter
Causalidad de dos series (insumo vs producto) → G8 Rainfall
Datos en tiempo real → G17 Dynamic Stream
Ranking que cambia con el tiempo → G16 Bar Race
Semana × hora × cantidad → G14 Single Axis ⇄ F10 Dot Heat
Cascada / descomposición de aumentos y disminuciones (≤6 niveles) → F9 Rung Waterfall
Progreso de un solo valor (0–100%) → F11 Tick Gauge ⇄ G18 Draw-in + Counter
Dispersión bidimensional (≤20 puntos) → F8 Plumb Scatter; cientos de puntos de distribución → G15 Jitter Strip
Distribución por grupos, registros individuales → G15 Jitter Strip
Categoría × categoría + cantidad (matriz) → Ligero (≤100 celdas) L4 Arc Matrix ⇄ Pesado (gran rango, necesita anotaciones) L9 Bubble Almanac
Pertenencia multia-unívoca → Con forma fuerte L5 Radial Convergence ⇄ Con lista de nombres L12 Type Colonnade
Embudo / disminución por etapas → L13 Hourglass Stream
Estructura jerárquica → G7 Tree LR
Jerarquía + participación / peso (dos niveles, valores positivos) → F13 Nested Treemap; solo ver quién pertenece a quién, sin comparar tamaños → G7 Tree LR
Historial de vida de secuencia de eventos → L11 Trend Lineage
Tiempo de nacimiento + estado actual de múltiples entidades → L1 Launch Fan
Distribución de eventos en el tiempo (dentro de un día) → L10 Radial Patchwork
Escala bipolar (ambos extremos son válidos) → L7 Brand Spectrum. Nota: diferenciar de la puntuación unipolar (radar); para unipolar, usa el radar nativo de ECharts
Red → ≤15 nodos G6/G11 gráfico pequeño; >15 o necesidad de consultar datos → B1 anillo / B2 dirigido por fuerza; flujo de múltiples rutas → B3 Threads
Múltiples grupos × cuadrícula (con sensación decorativa) → L8 Dotty Matrix; para leer valores → aplanar con G14
Carrusel multidimensional del mismo conjunto de entidades (demostración) → G9 Scatter Morph

Reglas Estrictas para F13 Nested Treemap

Solo acepta datos jerárquicos y pesos no negativos; el valor del padre es la suma de los hijos, está prohibido que el total de padre e hijo se contradiga. El área se delega directamente al layout treemap de ECharts, sin aplicar raíz cuadrada al valor.
Muestra dos niveles por defecto (grupo padre + hojas). Solo cuando hay más de dos niveles y el lector necesita consultar por niveles, se habilita el drill-down; en entregas estáticas normales, mantén nodeClick:false para evitar cambios de vista por clics accidentales.
En Mono, la escala de grises solo representa el nivel jerárquico, no asigna aleatoriamente claridad a cada hoja; el grupo padre se distingue por el título de la tarjeta, el espacio entre grupos y los bordes. Después de eliminar el color, la agrupación aún debe ser visible.
Porcelain: usa claridad de un solo tono para representar la participación o el nivel jerárquico ordenado del grupo padre; Palm: usa tonos correspondientes a no más de 4 categorías de nivel superior; Wire: mantiene la escala de grises, solo permite un HERO claramente definido.
Cuando el área ya expresa el valor, el color no debe repetir el mismo valor sin explicación. El subtítulo debe escribir claramente area = ...; al usar color, también escribe color = ....
Cuando hay más de 30 hojas, la mayoría de las etiquetas están omitidas, o el rectángulo más pequeño es demasiado pequeño para formar una zona estable, primero combina la cola larga en "Otros", divide en varios gráficos, o usa G7 / L12 / gráficos de relación de la serie B.
El tooltip debe mostrar al menos la ruta jerárquica completa, el valor original y el porcentaje del total; si la etiqueta no cabe en la tarjeta, ocúltala, no la reduzcas por debajo del tamaño mínimo de fuente.

Cinco: Tres Preguntas de Interactividad (Decide si Estático o Interactivo)

Pregunta en orden:

¿Detrás de esta línea/punto hay un registro real? Si no (decoración pura de textura, como los radios de Cluster Field, las líneas de Hourglass) → está prohibido agregar interactividad; agregar hover a elementos sin contenido es engañoso.
Si hay registro → ¿Se puede leer sin hacer clic? Elementos <50 y con etiquetas en ambos extremos (como Colonnade) → Estático es suficiente; hover es un extra.
Elementos >50 o múltiples rutas (como Threads) → Debe tener hover/pin, de lo contrario es solo un gráfico de ambiente. La implementación interactiva consulta templates/big-threads.html: debajo de las líneas visibles, coloca una línea gemela transparente de 9px como zona activa; al pasar el cursor sobre una línea, se ilumina toda la ruta; al pasar sobre una etiqueta, se tira de todo el conjunto; al hacer clic, se fija.

Seis: Tipos de Gráficos Fuera del Catálogo · Proceso de Traducción

Cuando el usuario solicita un gráfico que no está en las 49 opciones (o envía una imagen de referencia), no es que no se pueda hacer, es que hay que crear una nueva expresión sobre la marcha. El proceso tiene cuatro pasos; el primero no se puede omitir:

Responde primero a la entidad: ¿Qué codifica este tipo de gráfico? ¿Qué dimensión de datos corresponde a cada canal visual (posición/longitud/ángulo/área/brillo/densidad)? Si no puedes responder, pregunta al usuario por la estructura de datos. Copiar la forma sin el alma = trabajo en vano (ejemplo: un gráfico de barras pictórico una vez codificó erróneamente "recuento de símbolos" como "altura del árbol", requiriendo reelaboración).
Encuentra el pariente más cercano: en el catálogo, busca el gráfico con la forma de datos más similar como punto de partida, hereda su esqueleto de diseño y ritmo de animación.
Crea la expresión con tokens: la paleta, las fuentes, los bordes redondeados y los parámetros de animación deben tomarse todos de mono-tokens.js; está prohibido inventar nuevos colores o tamaños de fuente. El producto debe verse "de la misma familia" que los gráficos del catálogo. Al usar color, los colores se toman de una sola predefinida de color-presets.js; otros tokens aún se rigen por mono-tokens.js.
Pasa por las reglas estrictas de la Sección 2 y la autoverificación de la Sección 8, con el mismo estándar que los gráficos del catálogo.

Reglas adicionales para la traducción de imágenes de referencia: identifica a qué escuela pertenece la imagen de referencia (Glance o Editorial). La densidad, las anotaciones y la sensación de dibujo a mano (blob) del estilo Editorial son parte de la entidad; no las suavices — un almanac una vez requirió reelaboración por "no atreverse a apiñar".

Seis punto cinco: Color (Selección Automática según el Contexto, Sistema de Color Único)

Mono es el plan base, no una respuesta forzada cuando no se activa el color. Cuando el usuario no menciona el color, también debes evaluar si el color es adecuado según la semántica de los datos, la cantidad de categorías, el contexto de lectura y el tono del contenido; si la relación de adecuación no es clara, o el color no aporta valor informativo real, vuelve a Mono.

El borrador inicial en color elige uno de los tres conjuntos predefinidos; los valores de color están en color-presets.js, las muestras en templates/color/. Los predefinidos son para obtener rápida y establemente una primera versión unificada, no son paletas fijas. Cuando el usuario solicita "este azul un poco más oscuro", ajusta dentro del sistema de color actual; cuando el usuario proporciona colores de marca, valores de color o paletas completas, crea una paleta custom según las reglas a continuación. Después del ajuste, debes volver a verificar el contraste, la jerarquía visual y la semántica de los datos.

Un mismo HTML o grupo de entregas debe primero fijar un sistema de color global: Mono, porcelain, palm, wire o un custom. Todos los gráficos comparten esa elección. Si un gráfico no soporta el sistema seleccionado, no se puede cambiar de color individualmente; elige un sistema globalmente compatible, o vuelve todo el grupo a Mono.

La estructura de referencia siempre es el gallery original. Para consultar el código de renderizado, ve al gallery en el directorio raíz templates/; templates/color/ solo se usa para consultar combinaciones de colores. Primero, según la Sección Cero, selecciona la estructura; luego decide si cambiar el tema.

Usar o No Usar Color

Determina según la siguiente prioridad:

Usuario especifica explícitamente. Cuando el usuario solicita un color, tono o predefinido, prioriza su solicitud, pero aún así pasa las verificaciones de capacidad, contraste y semántica de datos.
Selección automática del Agente. Incluso si el usuario no menciona el color, siempre que la forma de los datos y el contexto tengan una correspondencia clara con un predefinido, se puede usar automáticamente: series ordenadas individuales son adecuadas para porcelain; pocas categorías desordenadas son adecuadas para palm; necesidad de un punto de atención controlado es adecuado para wire.
Si la relación no es clara, usa Mono. Cuando hay demasiadas categorías, alta densidad de registros, el color no tiene un significado estable, o el grupo completo de gráficos no puede compartir el mismo predefinido, usa Mono.

El color no es una versión mejorada, sino una herramienta semántica que el Agente puede seleccionar activamente. La entrega debe incluir una frase que explique el sistema de color seleccionado y el significado de datos que asume.

Paleta Personalizada (Solo se Activa cuando el Usuario lo Solicita Explícitamente)

El Agente no debe inventar por sí mismo una quinta estética predeterminada. Solo cuando el usuario proporciona valores de color explícitos, colores de marca, especificaciones de marca o "usa la combinación de colores de esta imagen de referencia", se crea una paleta custom; si solo dice "hazlo más bonito", aún se selecciona de los tres conjuntos predefinidos.

Primero determina la lógica del color, luego asigna los valores. Para datos ordenados, usa una escala de claridad de un solo tono; para categorías desordenadas, usa colores de clasificación; cuando se necesita enfoque, usa colores neutros + un color de énfasis. Está prohibido obtener cinco colores y luego distribuirlos uniformemente a todos los elementos.
Establece roles completos, no salpiques directamente hex. custom debe definir al menos BG, TXT, MUT, GRID, DATA; cuando se necesite un punto de atención, define HERO; para datos ordenados, define RAMP; para datos categóricos, define CAT. El producto final incrusta un objeto CUSTOM; todos los gráficos toman colores de los roles.
Interpreta según la cantidad de entrada. 1 color genera una escala de claridad del mismo tono; 2 colores se dividen por defecto en color principal de datos + color de énfasis, no se tratan automáticamente como dos categorías iguales; 3–6 colores solo se colocan en CAT si los datos tienen categorías correspondientes. Más de 6: primero combina categorías, usa posición/etiquetas, o vuelve a Mono.
Permite derivar claridad y oscuridad, pero no introducir nuevos tonos de contrabando. Los colores claros se obtienen mezclando el color del usuario con BG; los oscuros mezclando con TXT; está prohibido tomar prestados los valores de color de porcelain, palm o wire para completar custom.
El contraste es una regla estricta. El texto del cuerpo y las etiquetas pequeñas deben tener al menos 4.5:1 con respecto al fondo; el texto grande al menos 3:1; los bordes clave, las formas de datos y los estados interactivos deben tener al menos 3:1 con respecto al color adyacente. Si no se cumple, ajusta primero la claridad; no cambies arbitrariamente el tono principal especificado por el usuario.
El color no puede ser la única pista. Las categorías aún deben tener etiquetas; los ordinales aún conservan la posición/longitud/área; los énfasis aún tienen título o anotación. Después de eliminar el color (para usuarios con daltonismo), la estructura del gráfico aún debe ser legible.
Solo se fija este custom a la vez. custom no se mezcla con ningún predefinido; las entregas de múltiples gráficos comparten el mismo CUSTOM. A menos que el usuario solicite explícitamente fijar el color de marca como predefinido a nivel de proyecto, custom solo se incrusta en el producto actual, no se escribe en color-presets.js.

Si posteriormente el usuario solicita "un poco más oscuro", "fondo más cálido" o reemplazar un valor de color, modifica el rol correspondiente y vuelve a verificar todo el contraste y el mapeo semántico, no solo el elemento mencionado.

Cómo Elegir: Primero la Forma de los Datos, luego el Tono

Forma de los datos	Permitido	Razón
Ordenado / serie única (progreso, calor, series temporales, un indicador, ranking)	porcelain, wire	El contrato "brillo = dato" sigue vigente
Categorías desordenadas ≤4	palm	Tono corresponde a categoría
Categorías desordenadas 5–6	palm (apenas)	Se ayuda con claridad y saturación para diferenciar
Categorías >6	Escala de grises Mono	Capacidad de color predefinido insuficiente
Necesidad de moderación pero un punto de atención	wire	Escala de grises carga datos, naranja solo marca el protagonista

El usuario dirá	Predefinido	Tono
Azul, frío, académico, racional, serio, tecnológico	porcelain	Escala de azul de un solo tono
Verde, cálido, natural, suave, vintage, Morandi	palm	Verde y amarillo de baja saturación, ámbar como punto clave
Blanco y negro, moderado, sensación de revista, editorial	wire	Negro y gris con un toque de naranja fluorescente

Reglas Estrictas de Color

Un solo sistema de color por entrega. Un gráfico, el mismo HTML o el mismo grupo de gráficos hermanos solo puede usar Mono, un predefinido de color-presets.js, o un custom solicitado explícitamente por el usuario. Está prohibido mezclar predefinidos entre sí, o que custom tome prestados colores de predefinidos para complementarse.
Ancho de línea ×1.8, opacidad mínima .85. Las líneas finas en escala de grises pueden desaparecer fácilmente al cambiar a colores claros; excepto dot heat.
Cada gráfico debe tener al menos 3 niveles o posiciones de color. Si solo se usan 1–2 colores, vuelve a la escala de grises.
El color debe conectar con una dimensión real. La escala ordinal se conecta con valores; los colores segmentados se conectan con meses o rangos; los colores de clasificación se conectan con categorías; la nota al pie debe explicar qué codifica el color.
El color de énfasis solo para un protagonista. Un segundo protagonista disuelve el énfasis.
El color de los datos en tarjetas oscuras debe ser más claro que el fondo. Las tarjetas oscuras grandes usan el bloque DARK del predefinido. big-circular / big-force / big-threads solo admiten porcelain y palm; wire usa la versión original Mono para gráficos grandes.
En palm, DATA y HERO deben ser diferentes. El ámbar y el olivo tienen claridad similar; no los trates como colores de categorías iguales.

Siete: Cuándo Decir que No

Es más confiable atreverse a rechazar que aceptarlo todo. No se hacen los siguientes casos, y se ofrecen alternativas:

Gráfico de barras con eje truncado → Rechazar, ofrecer tres soluciones honestas (disparar / lupa / romper barra sin romper eje).
Brillo / vidrio esmerilado / 3D → Rechazar, mantener la sintaxis visual actual. Los valores de color personalizados se mapean según las reglas custom; se rechaza la mezcla entre sistemas de color.
Usar múltiples tonos para una serie ordenada → Rechazar. Ofrecer porcelain, wire o volver a Mono.
Categorías >6 y aún así quieren color → Rechazar, volver a la escala de grises Mono.
Gráficos de mapa (coropletas, mapas de trayectoria) → El catálogo no tiene tuberías geográficas; di honestamente que no se puede, no intentes dibujar algo que no se ajuste.
Agregar interactividad a elementos puramente decorativos (Sección 5, Pregunta 1) → Rechazar y explicar.
Reconstruir gráfico radar → No reconstruir, usar ECharts radar nativo + cambio de tema con token Mono (probado: en escenarios de presentación, "un tipo de gráfico reconocible" tiene valor).
Datos demasiado escasos para soportar el tipo de gráfico seleccionado (por ejemplo, 3 nodos para dirigido por fuerza) → Degradar a un gráfico más simple y explicar.

Ocho: Lista de Autoverificación Previa a la Entrega

¿Valores y visual son proporcionales? (¿Área usó sqrt? ¿Barra no tiene eje truncado?)
¿La paleta está controlada? ¿Todo el HTML o grupo de entregas usa solo Mono, un predefinido único o un custom único? Si en Mono aparece cualquier color que no sea de la escala, reelaboración; si en color predefinido aparece otro conjunto, reelaboración; ¿el custom solo toma colores de los roles CUSTOM y pasa la verificación de contraste?
¿Las etiquetas se superponen? (Lección de barcode: las etiquetas de picos adyacentes deben tener distancia mínima forzada)
¿El tamaño mínimo de fuente cumple? (Media anchura 6.5 / ancho completo 5.5)
¿Los datos de demostración son deterministas con rnd? ¿Tienen el mismo aspecto al actualizar dos veces?
¿El revelado funciona correctamente? (Reproducir al entrar en la vista, reproducir al hacer clic, temporizador no se apila, degradación reduced-motion presente)
¿Se verificó la sintaxis con node --check? (Extraer contenido de <script> y verificarlo)
¿El conjunto de cuatro partes de la tarjeta está completo? ¿El título es una conclusión, no el nombre del tipo de gráfico?
¿El subtítulo explica claramente la leyenda? (El lector, sin mirar el código, solo con esta línea)
¿Se completó la auditoría completa de candidatos? Anota al menos 3 candidatos y las razones de su eliminación, no solo "se usó esta plantilla".
Si es una página con varios gráficos, ¿se asignaron globalmente las plantillas? ¿Hay contornos similares repetidos, exceso de tarjetas oscuras, o todos los gráficos se convirtieron en el mismo tipo radial?
¿Cada gráfico registró el número de tipo, el archivo gallery y el título de la tarjeta? ¿La estructura central del producto final proviene realmente de esa plantilla, no es una reinvención?
Si se usó Glance, ¿se escribió por qué Lupi Editorial y Lupi Basics no son adecuados? Si no, reelaborar para volver a Lupi / Basics.
Última pregunta: Si se coloca este gráfico al lado de la tarjeta correspondiente del gallery seleccionado, ¿pertenecen a la misma familia de plantillas, o solo "el estilo se parece un poco"?

Nueve: Esqueleto de Plantilla de Archivo Único

<!doctype html>
<html lang="es">
<head>
<meta charset="utf-8" />
<meta name="viewport" content="width=device-width,initial-scale=1" />
<title>Mono — {Nombre del Gráfico}</title>
<!-- Si necesita ECharts: -->
<script src="https://cdn.jsdelivr.net/npm/echarts@6/dist/echarts.min.js"></script>
<!-- Si necesita Chart.js (G1 / G3): -->
<!-- <script src="https://cdn.jsdelivr.net/npm/chart.js@4/dist/chart.umd.min.js"></script> -->
<link rel="preconnect" href="https://fonts.googleapis.com">
<link href="{MONO.FONT.link}" rel="stylesheet">
<style>/* Incrustar MONO.CARD_CSS */</style>
</head>
<body>
<div class="grid2">
  <div class="card"><!-- o card dark / card wide -->
    <h2>{Título de conclusión}</h2>
    <div class="sub">{Explicación} · {Leyenda} · {Rango temporal}</div>
    <!-- Contenedor del gráfico, elegir según motor: -->
    <div class="ch" id="ch"></div><!-- ECharts -->
    <!-- SVG escrito a mano: <svg id="ch" viewBox="0 0 400 320"></svg> -->
    <!-- Chart.js (G1/G3): <div class="wrap"><canvas id="ch"></canvas></div>, con .wrap{position:relative;height:320px} -->
    <!-- ⚠️ Chart.js requiere .wrap y altura fija; de lo contrario, el canvas puede colapsar. -->
    <!-- Datos en MONO.data -->
    <div class="src">FUENTE · {Fuente}</div>
  </div>
</div>
<script>/* Incrustar MONO.SCRIPT */</script>
</body>
</html>

(El contenido se ha truncado parcialmente para la traducción. Continúa en la versión completa del skill.)

Lieflat Charts — Código de Estilo de Gráficos

¿Qué es Lieflat Charts — Código de Estilo de Gráficos?

Preguntar en tu IA favorita

Documentación