Was macht Lieflat Charts — Diagramme nach dem Codex der Ästhetik?

Lieflat Charts ist ein Datenvisualisierungs-Skill im Agent Skills-Format, der standardmäßig einen Mono-Graustufen-Look verwendet, aber bei passender Datensemantik und Nutzungsszenario automatisch eines von drei integrierten Farbschemata auswählt. Es konzentriert sich darauf, Daten in visuelle Inhalte zu verwandeln, die einen redaktionellen Anspruch haben, lesbar sind und zu vollständigen Seiten zusammengestellt werden können. Dieser Skill wurde bei moxt.ai erstellt und unterstützt Lupi (redaktionell/erzählend), Glance (schnelle Einschätzung), Basics (grundlegend) und interaktive Großgrafiken. Du erhältst vom Benutzer Daten und einen Kontext, und du erstellst eine einzelne HTML-Datei, die ohne Build-Schritt durch Doppelklick geöffnet werden kann; zum Ändern der Daten musst du nur ein Array am Anfang der Datei bearbeiten. Reine SVG-Diagramme funktionieren offline; Diagramme, die Chart.js, ECharts oder Online-Schriftarten verwenden, benötigen eine Internetverbindung, wenn die Abhängigkeiten nicht inline eingebettet sind.

Standardmäßig muss zuerst eine Auswahl aus Lupi Editorial und Lupi Basics getroffen werden; nur wenn keines der beiden passende Vorlagen bietet oder der Benutzer explizit Glance / Dashboard / 3-Sekunden-Überblick anfordert, ist die Verwendung von Glance erlaubt.

Die Farbgebung muss nicht explizit durch den Benutzer ausgelöst werden. Es wird automatisch zwischen Mono und den drei integrierten Schemata in color-presets.js gemäß Abschnitt 6.5 entschieden; wenn der Benutzer explizit Markenfarben oder benutzerdefinierte Farbwerte angibt, kann eine benutzerdefinierte Palette (custom) innerhalb der Auslieferung erstellt werden. Dieselbe HTML-Datei oder derselbe Satz von Auslieferungen darf nur ein Farbsystem verwenden, niemals gemischt. Farbmusterbeispiele befinden sich in templates/color/.

So findest du den Referenzcode für ein Diagramm: Suche den Diagrammtyp im Katalog → öffne die entsprechende Gallery-Datei → finde den <div class="card">-Block anhand des Titels in der Karte, um die Struktur zu sehen → suche im <script> nach dem gleichnamigen // ════-Kommentarblock für den Rendering-Code. Kopiere nicht die gesamte Seite – die Gallery ist eine Mehrfachkarten-Seite. Deine Auslieferung ist immer eine einzelne Diagrammdatei, die nach dem Gerüst in Abschnitt 9 aufgebaut ist.

Zielgruppe sind Nicht-Programmierer (Autoren, Marketingmitarbeiter, Leute, die Präsentationen erstellen). Sie sprechen in natürlicher Sprache („Hilf mir, die diesjährigen Conversion-Zahlen für den Blog-Beitrag zu visualisieren") und nennen keine Diagrammtypen. Deine Aufgabe ist es, diese natürliche Sprache in das richtige Diagramm zu übersetzen, das zudem so gut aussieht, dass es direkt veröffentlicht werden kann.

0. Harte Einschränkung: Vorlagen zuerst

Die folgenden Regeln sind keine Empfehlungen. Jede Verletzung einer dieser Regeln erfordert eine Nacharbeit:

Muss aus einer Repository-Vorlage generiert werden. Jedes finale Diagramm wird zuerst im catalog.md identifiziert (Typnummer), dann wird die entsprechende Gallery-Implementierung geöffnet: Lupi verwendet templates/lupi-gallery.html, Grundtypen templates/basics-gallery.html, Glance templates/glance-gallery.html, interaktive Großgrafiken templates/big-*.html. Auch farbige Diagramme verwenden diese Originalvorlagen als strukturelle Grundlage; templates/color/ dient nur zum Nachschlagen von Farbschemata.
Muss das Code-Gerüst der gewählten Vorlage verwenden. Beginne mit dem <div class="card">-Block, der dem Kartentitel entspricht, und dem gleichnamigen // ════ Diagrammname ════-Kommentarblock. Behalte die Kern-SVG/Canvas/ECharts-Struktur, Datenkodierung, Proportionen und Animationsrhythmen bei. Das Ersetzen von Daten, Titeln, Anmerkungen, Quellen und notwendigen Layout-Anpassungen ist erlaubt. Es ist verboten, außerhalb der Vorlage ein „ungefähr ähnliches" Diagramm zu zeichnen, mehrere Vorlagen zu einem Hybriddiagramm zu kombinieren oder auf die Standardstile der Diagrammbibliothek zurückzugreifen.
Die Standard-Auswahlreihenfolge ist festgelegt. Vergleiche zuerst vollständig die Lupi Editorial (L1–L15), dann Lupi Basics (F1–F13). Nur wenn unter diesen eine Vorlage existiert, die die Daten ehrlich darstellen, Beschriftungen aufnehmen und lesbar sein kann, muss aus diesen beiden Gruppen gewählt werden.
Glance ist die standardmäßige Downgrade-Option, kein gleichberechtigter Erstwunsch. Nur wenn weder Lupi Editorial noch Lupi Basics passen, oder wenn der Benutzer explizit Glance, Dashboard, Monitoring, Wochenbericht oder 3-Sekunden-Überblick anfordert, darf Glance verwendet werden. Vor einem Downgrade muss schriftlich begründet werden, warum Lupi/Basics ungeeignet sind.
Neuerstellung außerhalb des Katalogs ist das letzte Mittel. Wenn weder Lupi, Basics, Glance noch interaktive Vorlagen geeignet sind, darf erst der Übersetzungsprozess in Abschnitt 6 durchgeführt werden. Neue Diagramme müssen dennoch die visuelle Syntax und Code-Struktur der nächstgelegenen Gallery-Vorlage erben.

1. Arbeitsablauf (Diese sechs Schritte für jede Anfrage)

Bestimme die Datenform. Frage nicht, welches Diagramm der Benutzer möchte, sondern schau dir die Form seiner Daten an: Vergleich mehrerer Kategorien? Zeitreihe? Anteile? Positive/negative Werte? Viele-zu-Eins-Zuordnung? Netzwerk? Verteilung einzelner Datensätze? Die Datenform ist der primäre Schlüssel zur Diagrammauswahl.
Prüfe zuerst Lupi und Basics. Scanne basierend auf der Datenform alle Kandidaten aus Lupi Editorial (L1–L15) und Lupi Basics (F1–F13), die die Daten aufnehmen können. Vergleiche mindestens 3 Kandidaten; wenn es weniger als 3 gibt, liste alle auf. Vergleiche semantische Passung, ehrliche Einheiten, Beschriftungskapazität, Lesegeschwindigkeit, erzählerische Spannung und ob der Typ in dieser Charge bereits verwendet wurde.
Prüfe Glance nur bei Bedarf. Scanne Glance (G1–G18) nur, wenn alle Lupi- und Basics-Kandidaten gescheitert sind oder der Benutzer explizit Glance/Dashboard/Monitoring/Wochenbericht/3-Sekunden-Überblick anfordert. Dokumentiere bei der Wahl von Glance, warum Lupi und Basics nicht geeignet waren. Es ist nicht erlaubt, nur „Glance ist intuitiver" zu schreiben.
Wähle die echte Vorlage aus, dann organisiere die gesamte Seite. Jedes Diagramm muss das System, die Diagrammnummer, die Gallery-Datei und den Kartentitel dokumentieren. Verwende die echte Struktur und den Rendering-Code dieser Karte als Gerüst. Es ist verboten, zuerst zu überlegen, „was diese Seite erzählen soll" und dann ad hoc Diagramme zu erfinden. Die Seitenerzählung kann erst nach der Vorlagenauswahl organisiert werden.
Bilde Batches gemäß der Diagramm-Anzahl-Regel. Ein Diagramm trägt genau eine unabhängige Schlussfolgerung. Entferne doppelte Schlussfolgerungen und bestimme dann die Anzahl basierend auf den Standardintervallen in Abschnitt 1.1. Die Vorlagen müssen global zugewiesen werden: keine Wiederholungen, keine Anhäufung derselben Form, keine erzwungenen Diagramme, um eine Zahl zu erreichen.
Rendere gemäß der Vorlage und führe eine Selbstprüfung durch (Abschnitte 0, 2, 3, 8). Überprüfe Punkt für Punkt, ob das finale Produkt noch der gewählten Gallery-Implementierung entspricht. Das Ändern von Daten darf nicht dazu führen, dass die Kerngeometrie, -kodierung oder -animation der Vorlage ausgetauscht wird. Wähle gemäß Abschnitt 6.5 Mono oder eines der Farbschemata für die gesamte Auslieferung; Diagramme außerhalb des Katalogs durchlaufen den Übersetzungsprozess (Abschnitt 6).

1.1 Regel zur Anzahl der Diagramme

Die Anzahl der Diagramme wird durch die Anzahl der unabhängigen Schlussfolgerungen bestimmt, nicht durch die Anzahl der Datenspalten, und beträgt nicht zwingend 5 oder 6:

Art der Anfrage	Standard-Anzahl	Regel
Einzelne Frage / Einzeltabelle / Eine Metrik	1	Liefere nur das stärkste Diagramm aus, erweitere nicht nur zur Vorstellungspräsentation.
Zwei bis drei klare Schlussfolgerungen	2–3	Jedes Diagramm trägt eine andere Schlussfolgerung, kann aber dieselbe Datenquelle teilen.
Ein Artikel, eine Arbeit oder ein vollständiger Fall	4–6	Abdecken verschiedener Datenformen wie Überblick, Zusammensetzung, Vergleich, Beziehung oder Veränderung.
Benutzer gibt explizite Anzahl vor	Nach Wunsch	Entferne dennoch doppelte Diagramme; wenn die Anzahl nicht unterstützt werden kann, erkläre und mache weniger.

Das Standard-Limit pro Seite ist 6 Diagramme; bei mehr als 6 auf mehrere Seiten oder nach Kapiteln aufteilen.
Kandidaten-Entwürfe, Glance/Lupi-Vergleiche zählen nicht zu den finalen Diagrammen; sie sind Teil des Auswahlprozesses, nicht der finale Batch.
Bei mehreren Diagrammen auf einer Seite muss mindestens eines einen Gesamtüberblick bieten; die anderen müssen neue Vergleichsdimensionen, Beziehungen, zeitliche Veränderungen oder Detailnachweise liefern.
Wenn zwei Diagramme dieselbe Schlussfolgerung ausdrücken, behalte nur dasjenige, das für den Lesekontext besser geeignet ist und einen ehrlicheren Datenvertrag hat.

2. Mono-Syntax · Harte Regeln (Verstoß führt zu Nacharbeit)

Standardmäßig wird mono-tokens.js referenziert (bei Open-Source-Verteilung den Inhalt inline in HTML einbetten). Bei Konflikten mit Token-Werten haben die Token Vorrang. Bei Verwendung von Farbe werden nur die Farb-Token ersetzt; Schriftarten, Eckenradien, Layout und Animationen basieren weiterhin auf mono-tokens.js.

Farben

Standardmäßig gibt es nur die beiden Extremwerte Papiergrau #F0EFEB und Holzkohleschwarz #1C1C1A, dazwischen eine 7-stufige Grauskala. Ausnahmen für Farbe folgen Abschnitt 6.5 ab einem Preset.
Helligkeit ist Daten: Das Wichtigste = das dunkelste Element (auf dunklen Karten umgekehrt das hellste). Mehrere Serien werden entlang der Grauskala nach Wichtigkeit zugewiesen, nicht willkürlich der Reihe nach.
Durchgehend Vollflächig: Keine transparenten Materialien, kein Leuchten, keine Farbverläufe, keine Schatten. Die Textur entsteht ausschließlich durch Helligkeitskontraste und Formen. Einzige Ausnahme: Bei überlagernden Diagrammen (Radial Patchwork) kodiert die Transparenz selbst die Dichte – das sind Daten, keine Dekoration.
Dunkle Karten (.card.dark) sind nur für zwei Diagrammtypen erlaubt: solche, die einen dunklen Hintergrund zur Formgebung benötigen (Blütenblätter, leuchtende Faden-/Netzgrafiken). Standardmäßig helle Karten; maximal 1 dunkle Karte pro Bildschirmseite (4 Karten).

Typografie

Inter-Schriftart-Familie. Titel 700 / Zahlen in Diagrammen 800 / Achsenbeschriftungen 600. Die Kartenstruktur ist festgelegt (Vier-Satz): Schlussfolgernder Titel (h2) + Untertitel (Legende und Zeitbereich hier, getrennt durch ·) + Diagramm + Quellenzeile (in Großbuchstaben, mit Buchstabenabstand).
Der Titel schreibt die Schlussfolgerung, nicht den Diagrammnamen: „Umsatz nach Plan" ist okay, „Balkendiagramm" nicht; noch besser ist ein wertender Titel: „Wo wir gewonnen haben, wo wir verloren haben".
Minimale Schriftgröße in SVG: Halbbreite Karte 6.5px, volle Breite 5.5px. Informationen, die nicht platziert werden können, erscheinen beim Hover; die Schriftgröße darf nicht verkleinert werden, um sie zu erzwingen.

Formen

Karten-Eckenradius 24px, keine Ränder, keine Schatten, Trennung durch Weißraum. Balkenenden haben einen Kapsel-Eckenradius (senkrechte Balken oben abgerundet, waagerechte Balken am äußeren Ende).
Balkendiagramme haben keine unterbrochene Achse. Der Vertrag eines Balkens ist Länge ∝ Wert; eine unterbrochene Achse zerstört diesen Vertrag. Korrekte Vorgehensweise bei Ausreißern: ① Den Ausreißer in den Himmel ragen lassen (am ehrlichsten) ② Hauptdiagramm + Lupen-Detaildiagramm ③ Balken brechen, nicht die Achse (explizit sagen, dass es nicht mehr passt).
Blütenblatt-Form (dicke schwarze Nähte + abgerundete Segmente) nur für gleichmäßig oder annähernd gleichmäßig aufgeteilte Radialdiagramme. Segmente mit stark unterschiedlicher Breite verdecken sich gegenseitig und reduzieren die Lesbarkeit.

Animationen

Entry-Animation standardmäßig aktiviert, quarticOut, schnell rein und schnell stoppen, kein Hüpfen (Wellen-Entry darf elasticOut verwenden). Punkt-Stagger 8–15ms/Punkt, Balken 80–130ms/Balken.
Einheitlicher Reveal-Mechanismus: Abspielen beim Einrollen ins Viewport + Abspielen bei Klick (verwende obsReveal aus den Token mit Timer-Bereinigung).
Muss einen prefers-reduced-motion-Fallback haben (enthalten im CSS der Token).
Animation darf nicht wichtiger sein als die Struktur: Ein Effekt, der ein neues Layout erfordert, um platziert zu werden, ist nicht existenzberechtigt (Lehre aus effectScatter).

Daten

Beispieldaten verwenden die deterministische Pseudo-Zufallsfunktion rnd(i,k) aus den Token. Math.random() ist verboten – beim Aktualisieren muss es gleich aussehen.
Werte und visuelle Darstellung sind streng proportional. Bei Flächenkodierung Math.sqrt(v) zur Radiusumrechnung verwenden; Werte nicht direkt als Radius verwenden.

3. Arbeitsteilung der beiden Stilrichtungen

Unter derselben Mono-Palette gibt es zwei Weltanschauungen. Die Wahl hängt vom Kontext und davon ab, wie viele Sekunden der Leser investieren möchte:

	Glance-Serie (18 Diagramme)	Lupi-Serie (genaues Lesen, 15 Diagramme)
Basiseinheit	Form (dicke Balken, große Bögen, Farbblöcke)	Datensatz (ein Punkt = ein Datenpunkt)
Linien	2px+, selbstbewusst	0.5–0.7px Haarstriche
Aggregation	Voraggregiert, Schlussfolgerung präsentieren	Keine Aggregation, Rohdaten ausbreiten
Lesemethode	Überfliegen (<10s)	Nahlesen (30s+)
Kontext	Wochenbericht, Dashboard, Schnappschuss	Jahresbericht, externe Story-Seite, Poster
Engine	Chart.js / ECharts	Handgeschriebenes SVG

Standardstrategie: Lupi Editorial → Lupi Basics → Glance. Wenn der Kontext nicht klar ist, ist Glance standardmäßig verboten. Für Jahresberichte, lange Blog-Beiträge auf öffentlichen Konten, Poster, Open-Source-READMEs, Portfolios wähle zuerst Lupi Editorial; bei weniger Daten oder wenn vertraute Diagrammtypen passen, wähle Lupi Basics. Nur wenn keine der ersten beiden Gruppen eine passende Vorlage bietet oder der Benutzer explizit Dashboard, Monitoring, Wochenbericht oder 3-Sekunden-Überblick anfordert, darf der Glance-Kandidatenpool betreten werden.

Die vollständige Kandidatenprüfung bedeutet nicht, „alle Diagramme einmal zu machen". Filtere zuerst basierend auf der Datenform Kandidaten, die dieselbe Entität kodieren können, und teile sie dann ein in:

Semantisch passend: Hinter jedem Punkt, jeder Linie, jeder Fläche, jeder Perle steckt eine echte Einheit oder eine klare Aggregationsvorschrift.
Visuell passend: Beschriftungen passen, Dichte ausreichend, Leser können im erwarteten Zeitrahmen lesen.
Erzählerisch passend: Die grafische Form kann das Urteil tragen, das diese Daten vermitteln sollen, und stellt nicht nur Zahlen dar.

Die endgültige Wahl ist die Schnittmenge dieser drei, nicht „welche Vorlagendatei am einfachsten zu kopieren ist". Standardmäßig wird die Prüfung zuerst innerhalb von Lupi Editorial und Lupi Basics durchgeführt; nur wenn beide Gruppen scheitern, wird auf Glance erweitert. Wenn im selben Batch mehrere Diagramme erstellt werden müssen, führe eine globale Zuweisung der Kandidaten durch: Vorlagen nicht wiederholen, Formen rotieren, maximal eine dunkle Karte, vermeide, dass die gesamte Seite aus sechs ähnlichen Ringen oder waagerechten Balken besteht.

Wenige Daten (nur ein paar Prozent) bedeuten nicht automatisch Glance. Der richtige Weg zur Lupi-ifizierung ist die Einheitenzerlegung: Zerlege die aggregierte Zahl in zählbare Einheiten (1 Punkt = 1 Person / 1 Prozentpunkt). Die Dichte kommt von den Einheiten, nicht von der Anzahl der Datensätze. Schreibe die Bedeutung der Einheiten in den Untertitel. Zerlege nur ehrliche Einheiten (Summe der Anteile 100 → 100 Punkte). Erfinde keine nicht existierenden individuellen Datensätze. Wenn beim Runden die Summe unter 100 liegt (z. B. 49.0 + 27.4 + 13.9 + 5.0 + 3.2 → 98), schreibe in einer Fußnote: „Weitere N Personen wurden durch Rundung verschluckt". Erfinde keine gefälschten Einheiten.

Priorität der Pfade für kleine Datenmengen in Lupi (durch mehrere Fallbeispiele bestätigt):

Zuerst vollständiger Scan, dann Code-Gerüst auswählen – Die Basic-Gruppe F1–F13 (templates/basics-gallery.html) ist der Lupi-Wortschatz für sparse Daten: Balken/Linien/Fläche/Ring/Waagerechte Balken/Gruppiert/Gestapelt/Scatter/Waterfall/Heatmap/Fortschritt/Hantel/Rechteckbaum; die redaktionelle Gruppe L1–L15 bietet Syntax für Einzeldatensätze, Einheitenzerlegung, Beziehungen und Anmerkungen. Wähle nicht direkt ein F-Diagramm, nur weil basics-gallery.html fertigen Code bereitstellt.
Beginne mit der Vorlage, die der Entität am nächsten kommt – Bei Multiple-Choice-Prozenten vergleiche bevorzugt L15, F5, L2; bei 100%-Zusammensetzung vergleiche bevorzugt L14, L5, F4, G4; bei Trichtern vergleiche bevorzugt L13, Downgrade-Darstellung von F1/F5. Die Auswahl basiert auf der Datenkodierung, nicht auf der Dateireihenfolge.
Erfinde nur dann eine neue Form, wenn sie wirklich nicht im Katalog vorhanden ist, und die Neuerfindung muss von der bestehenden Syntax der Gallery ausgehen (Haarstrich-Ticks, deterministischer rnd-Jitter, paint-order-Glow, Großbuchstaben-Anmerkungen). Keine Referenzen außerhalb des Katalogs einführen – „Lupi-Stil" bezieht sich auf die visuelle Syntax der Diagramme in der Gallery, nicht auf den handgezeichneten Stil von Giorgia Lupi persönlich.
Neue Diagramme mit wenigen Daten müssen mit Umgebungsstrukturschichten ausgestattet werden: Ein Teil der Attraktivität der Gallery kommt von nicht-datenbezogenen Möbeln (Buchhaltungspapier-Linien, gestrichelte Führungslinien, rim-Skalen, Säulengitter alle 10 Einheiten, Anmerkungsführungslinien). Die Datenschicht ist ehrlich dünn, das Dichtebudget wird für die Möbel ausgegeben. Ein Diagramm, das nur die Daten + eine Grundlinie zeichnet, wirkt zwangsläufig dürftig.

Innerhalb desselben Output-Batches (mehrere Diagramme auf einer Seite) dürfen Vorlagen nicht wiederholt werden. 15 Lupi-Diagramme reichen für eine Rotation; wenn mehrere Vorlagen dieselben Daten aufnehmen können, wähle diejenige, die in diesem Batch noch nicht verwendet wurde.

4. Entscheidungsbaum für Diagrammtypen (Datenform → Kandidaten)

Die Nummern entsprechen catalog.md. Dies ist nur eine Kandidaten-Rückruftabelle. Pfeile und Schreibreihenfolge repräsentieren keine Priorität. Die tatsächliche Auswahl muss befolgen: Zuerst alle Lupi Editorial- und Lupi Basics-Kandidaten prüfen; erst wenn keine passende Vorlage gefunden wird, darf ein Glance-Kandidat verwendet werden.

Vergleich weniger Kategorien (≤8) → G3 Chunky Bars ⇄ Vertikal F1 Rung Bars / Horizontal F5 Tick Rows ⇄ L2 Dot Cascade (⚠️ Cascade: Kategoriennamen vertikal, nur wenn Name ≤4 Zeichen oder kurze Abkürzung verwendbar; lange chinesische Kategorienamen durch F5/L5/L12 ersetzen)
Multiple-Choice-Prozente (jeweils 0–100, Summe kann >100) → G3 Chunky Bars ⇄ L15 Ballot Tally
Verteilung vieler Kategorien (30–60 Balken) → G12 Stagger Wave
Kategoriale Werte mit Positiv/Negativ → G10 Diverging Bar
Anteile / 100%-Zusammensetzung → G4 Dot Waffle ⇄ L14 Hundred Field ⇄ F4 Tick Donut (Standard-Ersatz für Kuchendiagramm); annähernd gleiche Teile und repräsentativ → G2 Petal Rose; Anteil × Intensität doppelt kodiert → G13 Big Slice; gestapelt nach Kategorie → F7 Stacked Rungs
Vergleich zweier Zeitpunkte (Vorher/Nachher / Früher/Heute) → Kategorieebene (≤6 Kategorien) → F12 Dumbbell Queue (horizontal, Perlen = echte Einheiten) ⇄ F6 Paired Rungs (Seite-an-Seite Doppelleitern); Nur 2–4 Serien mit Trendlinie → Glance chunky slope (dicke Linien, große Zahlen, Schlussfolgerung in den Titel). Slope-Diagramme mit vielen Kreuzungen reduzieren die Lesbarkeit erheblich; füge keine dekorativen Strukturen zur Lupi-ifizierung hinzu.
Tägliche Sequenz (≤30 Tage, mit Bereich) → G1 Range Capsules ⇄ Tägliche Werte F2 Hairline Line ⇄ (90-Tage-Ebene, mit Textur) L3 Barcode Lollipop; 30–60 Tage, Form erkennen → F3 Hairline Area
Kumulatives Wachstum → G18 Draw-in + Counter
Kausale Beziehung zweier Serien (Input vs. Output) → G8 Rainfall
Echtzeitdaten → G17 Dynamic Stream
Rangfolge im Zeitverlauf → G16 Bar Race
Wochentag × Stunde × Wert → G14 Single Axis ⇄ F10 Dot Heat
Waterfall / Aufschlüsselung (≤6 Stufen) → F9 Rung Waterfall
Einzelwert-Fortschritt (0–100%) → F11 Tick Gauge ⇄ G18 Draw-in + Counter
2D-Scatter (≤20 Punkte) → F8 Plumb Scatter; Hunderte von Punkten → G15 Jitter Strip
Gruppierte Verteilung, Einzeldatensätze → G15 Jitter Strip
Kategorie × Kategorie + Wert (Matrix) → Leicht (≤100 Zellen) L4 Arc Matrix ⇄ Schwer (große Spanne, mit Anmerkungen) L9 Bubble Almanac
Viele-zu-Eins-Zuordnung → Formal stark L5 Radial Convergence ⇄ Mit Namensliste L12 Type Colonnade
Trichter / Stufenweiser Rückgang → L13 Hourglass Stream
Hierarchische Struktur → G7 Tree LR
Hierarchie + Anteil / Gewicht (zwei Ebenen, Werte positiv) → F13 Nested Treemap; Nur sehen, wer zu wem gehört, keine Größenvergleiche → G7 Tree LR
Lebensgeschichte einer Ereignissequenz → L11 Trend Lineage
Geburtszeit mehrerer Entitäten + aktueller Status → L1 Launch Fan
Verteilung der Ereigniszeitpunkte (innerhalb eines Tages) → L10 Radial Patchwork
Bipolare Skala (beide Enden legitim) → L7 Brand Spectrum. Achtung: Abgrenzung zur unipolaren Bewertung (Radar); für unipolare Bewertung natives ECharts-Radar verwenden
Netzwerk → ≤15 Knoten G6/G11 kleines Diagramm; >15 oder zum Nachschlagen → B1 Ring / B2 Force-Directed; Mehrere Pfadflüsse → B3 Threads
Mehrere Gruppen × Raster (mit dekorativem Touch) → L8 Dotty Matrix; zum Ablesen → Flachlegen mit G14
Mehrdimensionale Rotation derselben Entitätsmenge (Präsentation) → G9 Scatter Morph

F13 Nested Treemap Harte Regeln

Akzeptiert nur hierarchische Daten und nicht-negative Gewichte; Elternknotenwerte werden durch Summe der Kinder gebildet, Eltern-Kind-Gesamtsummen dürfen nicht widersprüchlich sein. Die Fläche wird direkt an das ECharts-Treemap-Layout übergeben, keine Quadratwurzel der Werte.
Standardmäßig zwei Ebenen anzeigen (Elterngruppe + Blätter). Drill-down nur aktivieren, wenn mehr als zwei Ebenen vorhanden sind und der Leser schrittweise Abfragen benötigt; bei normaler statischer Auslieferung nodeClick:false beibehalten, um versehentliche Ansichtswechsel zu vermeiden.
Der Mono-Graustufenwert repräsentiert nur die Hierarchieebene, nicht zufällige Helligkeitszuweisung pro Blatt; die Elterngruppe wird durch Titelzeilen, Gruppenabstände und Grenzen unterschieden. Nach dem Entfernen der Farbe müssen die Gruppen noch erkennbar sein.
porcelain: Einfarbige Helligkeit repräsentiert geordnete Elternanteile oder Hierarchieebenen; palm: Farbtonkorrespondenz für maximal 4 Top-Level-Kategorien; wire: Graustufen beibehalten, nur ein klar definierter Protagonist darf HERO verwenden.
Wenn die Fläche bereits den Wert ausdrückt, darf die Farbe nicht ohne Erklärung denselben Wert erneut kodieren. Der Untertitel muss area = ... klar angeben; bei Verwendung von Farbe zusätzlich color = ... angeben.
Bei mehr als 30 Blättern, großflächig fehlenden Beschriftungen oder wenn die kleinsten Rechtecke zu klein für stabile Hit-Zonen sind, zuerst den langen Schwanz zu „Andere" zusammenfassen, auf mehrere Diagramme aufteilen oder zu G7 / L12 / B-Serien-Beziehungsdiagrammen wechseln.
Tooltip zeigt mindestens den vollständigen Hierarchiepfad, den Originalwert und den Gesamtanteil; wenn die Beschriftung in der Karte nicht platziert werden kann, ausblenden, nicht unter die minimale Schriftgröße verkleinern.

5. Drei Fragen zur Interaktivität (Entscheidung statisch vs. interaktiv)

In dieser Reihenfolge fragen:

Steckt hinter dieser Linie/diesem Punkt ein echter Datensatz? Nein (reine Texturdeko, z. B. Speichen von Cluster Field, Tropflinien von Hourglass) → Interaktivität verbieten. Einem inhaltslosen Element einen Hover-Effekt zu geben, ist Täuschung.
Ja, echter Datensatz → Kann die Information ohne Klick gelesen werden? Elemente <50 und an beiden Enden beschriftet (z. B. Colonnade) → Statisch ausreichend, Hover ist das i-Tüpfelchen.
Elemente >50 oder mehrere Pfade (z. B. Threads) → Hover/Pin zwingend erforderlich, sonst reine Stimmungsgrafik. Interaktive Implementierung siehe templates/big-threads.html: Unter der sichtbaren Linie eine 9px transparente Zwillingslinie als Hit-Zone legen, Hover auf einzelner Linie hebt den gesamten Pfad hervor, Hover auf Beschriftung zieht das gesamte Bündel, Klick fixiert.

6. Übersetzungsprozess für Diagrammtypen außerhalb des Katalogs

Wenn der Benutzer ein Diagramm möchte, das nicht in den 49 enthalten ist (oder ein Referenzbild sendet), heißt das nicht, dass es nicht gemacht werden kann, sondern dass es ad hoc formuliert werden muss. Vier Schritte, der erste darf nicht übersprungen werden:

Zuerst die Entität beantworten: Welche Entität kodiert dieser Diagrammtyp? Welcher visuelle Kanal (Position/Länge/Winkel/Fläche/Helligkeit/Dichte) entspricht welcher Datendimension? Wenn du es nicht beantworten kannst, frage den Benutzer nach der Datenstruktur. Die Form zu kopieren, ohne die Seele zu erfassen, ist umsonst (pictorial bar hatte einmal fälschlich „Symbol zählen" als „Baum wird größer" interpretiert, Nacharbeit).
Finde den nächsten Verwandten: Suche im Katalog nach dem Diagramm mit der ähnlichsten Datenform als Ausgangspunkt. Erbe sein Layout-Gerüst und seinen Animationsrhythmus.
Formuliere mit Token: Palette, Schriftart, Eckenradius, Animationsparameter alle aus mono-tokens.js nehmen. Keine neuen Farben oder Schriftgrößen erfinden. Das Ergebnis muss mit den Diagrammen im Katalog „wie aus einer Familie" aussehen. Bei Verwendung von Farbe werden die Farben aus einem einzigen Preset von color-presets.js genommen; andere Token basieren weiterhin auf mono-tokens.js.
Prüfe gegen die harten Regeln in Abschnitt 2 und die Selbstprüfung in Abschnitt 8 mit dem gleichen Standard wie die Katalogdiagramme.

Zusatzregeln für die Übersetzung von Referenzbildern: Identifiziere, zu welcher Schule das Referenzbild gehört (Glance oder Redaktion). Der redaktionelle Stil mit seiner Dichte, seinen Anmerkungen und der handgezeichneten Anmutung (blob) ist ein Teil der Entität. Mache es nicht konvergenter – Almanac musste einmal nachgearbeitet werden, weil es sich „nicht getraut hat, eng zu sein".

6.5 Farbe (Automatische Auswahl basierend auf dem Szenario, einheitliches Farbsystem)

Mono ist der Basisplan, nicht die erzwungene Antwort, wenn keine Farbe ausgelöst wird. Auch wenn der Benutzer keine Farbe erwähnt, muss anhand der Datensemantik, der Anzahl der Kategorien, des Lesekontexts und des Inhaltsstils bewertet werden, ob Farbe geeignet ist. Wenn die Anpassungsbeziehung nicht klar ist oder Farbe keinen echten Informationswert bietet, zurück zu Mono.

Der erste farbige Entwurf wird aus einem der drei integrierten Presets ausgewählt. Die Farbwerte befinden sich in color-presets.js, Beispiele in templates/color/. Die Presets dienen dazu, schnell eine stabile, einheitliche erste Version zu erhalten, nicht als feste Palette. Wenn der Benutzer „dieses Blau etwas dunkler" wünscht, wird innerhalb des aktuellen Farbsystems weiter angepasst; wenn der Benutzer explizit Markenfarben, Farbwerte oder eine vollständige Palette angibt, wird gemäß den folgenden Regeln eine benutzerdefinierte Palette (custom) erstellt. Nach der Anpassung müssen Kontrast, visuelle Hierarchie und Datensemantik erneut geprüft werden.

Dieselbe HTML-Datei oder derselbe Satz von Auslieferungen muss zuerst ein globales Farbsystem festlegen: Mono, porcelain, palm, wire oder eine benutzerdefinierte Palette (custom). Alle Diagramme teilen diese Wahl. Wenn ein Diagramm das gewählte System nicht unterstützt, darf es nicht einzeln umgefärbt werden; wechsle zu einem global kompatiblen System oder kehre für die gesamte Gruppe zu Mono zurück.

Die strukturelle Grundlage ist immer die Original-Gallery. Den Rendering-Code in der Gallery im Wurzelverzeichnis templates/ suchen; templates/color/ dient nur zum Nachschlagen von Farbschemata. Zuerst die Struktur gemäß Abschnitt 0 auswählen, dann entscheiden, ob ein Farbschema angewendet wird.

Farbe verwenden oder nicht?

Prüfung in dieser Priorität:

Benutzer spezifiziert explizit. Wenn der Benutzer eine bestimmte Farbe, einen bestimmten Stil oder ein bestimmtes Preset wünscht, hat dies Vorrang, muss aber dennoch auf Kapazität, Kontrast und Datensemantik geprüft werden.
Agent wählt automatisch. Auch wenn der Benutzer keine Farbe erwähnt, kann Farbe automatisch verwendet werden, solange die Datenform und der Kontext eine klare Korrespondenz zu einem Preset haben: Geordnete Einzelserie passt zu porcelain; wenige ungeordnete Kategorien passen zu palm; ein kontrollierter Blickfang passt zu wire.
Bei unklarem Zusammenhang Mono verwenden. Zu viele Kategorien, hohe Datendichte, Farbe hat keine stabile Bedeutung, oder die gesamte Gruppe von Diagrammen kann nicht dasselbe Preset teilen → Mono verwenden.

Farbe ist kein Upgrade, sondern ein semantisches Werkzeug, das der Agent aktiv wählen kann. Gib mit einem Satz an, welches Farbsystem gewählt wurde und welche Datenbedeutung es trägt.

Benutzerdefinierte Palette (nur auf expliziten Wunsch des Benutzers aktivieren)

Der Agent darf keine fünfte ästhetische Standardeinstellung erfinden. Nur wenn der Benutzer explizite Farbwerte, Markenfarben, Markenrichtlinien angibt oder sagt „verwende die Farben dieses Referenzbildes", wird eine benutzerdefinierte Palette erstellt; bei einem einfachen „mach es schöner" wird weiterhin aus den drei integrierten Presets gewählt.

Zuerst die Farblogik bestimmen, dann Farbwerte zuweisen. Geordnete Daten: Einfarbige Helligkeitsskala; ungeordnete Kategorien: Kategorische Farben; Fokussierung nötig: Neutrale Farbe + eine Akzentfarbe. Es ist verboten, zuerst fünf Farben zu nehmen und sie dann gleichmäßig auf alle Elemente zu verteilen.
Vollständige Rollen definieren, nicht direkt Hex-Werte verteilen. custom definiert mindestens BG, TXT, MUT, GRID, DATA; bei Bedarf HERO für Schwerpunkte, bei geordneten Daten RAMP, bei kategorischen Daten CAT. Das finale Produkt enthält ein CUSTOM-Objekt; alle Diagramme beziehen ihre Farben aus diesen Rollen.
Basierend auf der Anzahl der Eingaben interpretieren. 1 Farbe: Einfarbige Helligkeitsskala generieren. 2 Farben: Standardmäßig aufteilen in Hauptdatenfarbe + Akzentfarbe, nicht automatisch als zwei gleichberechtigte Kategorien betrachten. 3–6 Farben: Nur wenn die Daten tatsächlich entsprechende Kategorien haben, in CAT aufnehmen. Bei mehr als 6 Farben zuerst Kategorien zusammenfassen, auf Position/Beschriftung ausweichen oder zu Mono zurückkehren.
Abgeleitete Helligkeiten erlaubt, Einschmuggel neuer Farbtöne verboten. Helle Farben durch Mischen der Benutzerfarbe mit BG, dunkle Farben durch Mischen der Benutzerfarbe mit TXT. Es ist verboten, Farbwerte von porcelain, palm, wire auszuleihen, um custom zu ergänzen.
Kontrast ist eine harte Anforderung. Fließtext und kleine Beschriftungen relativ zum Hintergrund mindestens 4.5:1, große Schriften mindestens 3:1; kritische Grenzen, Datenformen und interaktive Zustände relativ zu benachbarten Farben mindestens 3:1. Bei Nichteinhaltung zuerst die Helligkeit anpassen; den vom Benutzer angegebenen Hauptfarbton nicht eigenmächtig ändern.
Farbe darf nicht die einzige Unterscheidungsmöglichkeit sein. Kategorien behalten Beschriftungen, ordinale Daten behalten Position/Länge/Fläche, Schwerpunkte werden durch Titel oder Anmerkungen erläutert. Ein Benutzer mit Farbsehschwäche sollte nach dem Entfernen der Farbe die Diagrammstruktur noch verstehen können.
Es wird immer nur genau diese eine benutzerdefinierte Palette verwendet. custom wird nicht mit integrierten Presets gemischt; mehrere Diagramme teilen sich dasselbe CUSTOM. custom wird nur im aktuellen Produkt inline eingebettet und nicht in color-presets.js zurückgeschrieben, es sei denn, der Benutzer fordert explizit, dass die Markenfarben als projektweites Preset festgelegt werden.

Wenn der Benutzer später „etwas dunkler", „etwas wärmerer Hintergrund" oder Ersatz eines Farbwerts wünscht, ändere die entsprechende Rolle und prüfe erneut den gesamten Kontrast und die semantische Zuordnung; ändere nicht nur das genannte Element.

Welches Preset wählen: Zuerst auf die Datenform achten, dann auf den Stil

Datenform	Erlaubt	Grund
Geordnet / Einzelserie (Fortschritt, Heatmap, Zeitreihe, Einzelmetrik, Rangfolge)	porcelain, wire	Der Vertrag Helligkeit = Daten bleibt bestehen
Ungeordnete Kategorien ≤4	palm	Farbton entspricht Kategorie
Ungeordnete Kategorien 5–6	palm (knapp)	Mit Helligkeit und Sättigung unterscheiden
Kategorien >6	Mono-Grauskala	Farbpalette-Kapazität nicht ausreichend
Zurückhaltend, aber ein Blickfang gewünscht	wire	Graustufen tragen Daten, Orange markiert nur den Protagonisten

Benutzer sagt	Preset	Stil
Blau, kalt, akademisch, rational, seriös, technisch	porcelain	Einfarbige Blauskala
Grün, warm, natürlich, sanft, retro, Morandi	palm	Grün-Gelb, geringe Sättigung, Amber als Akzent
Schwarz-Weiß, zurückhaltend, Magazin-Stil, Redaktion	wire	Schwarz-Grau mit einem Hauch Neon-Orange

Harte Farbregeln

Nur ein Farbsystem pro Auslieferung verwenden. Ein Diagramm, dieselbe HTML-Datei oder derselbe Satz von Geschwisterdiagrammen darf nur Mono, ein Preset aus color-presets.js oder eine explizit vom Benutzer angeforderte benutzerdefinierte Palette (custom) verwenden. Das Mischen von Presets untereinander ist verboten, ebenso das Ausleihen von Farben aus integrierten Presets für custom.
Linienbreite ×1.8, Transparenz-Boden .85. Haarstriche im Graustufen-Modus verschwinden leicht, wenn sie in helle Farben umgewandelt werden; Ausnahme: dot heat.
Jedes Diagramm benötigt mindestens 3 Farbstufen oder -positionen. Bei nur 1–2 Farben zurück zu Graustufen.
Farbe muss eine echte Dimension kodieren. Ordinale Skala bindet an Werte, segmentierte Farbe an Monate oder Abschnitte, kategorische Farbe an Kategorien; in der Fußnote klar angeben, was die Farbe kodiert.
Akzentfarbe nur für einen Protagonisten. Ein zweiter Protagonist würde die Akzentwirkung aufheben.
Datenfarbe auf dunklen Karten muss heller als der Kartenhintergrund sein. Bei dunklen Großgrafiken den DARK-Block des Presets verwenden. big-circular / big-force / big-threads verwenden nur porcelain und palm; wire verwendet die original Mono-Großgrafiken.
In palm müssen DATA und HERO unterschiedlich sein. Amber und Oliv haben ähnliche Helligkeit; verwende sie nicht als gleichberechtigte Kategorienfarben.

7. Wann man Nein sagt

Etwas abzulehnen ist glaubwürdiger, als alles anzunehmen. In folgenden Fällen nicht machen und Alternativen anbieten:

Balkendiagramm mit unterbrochener Achse → Ablehnen, drei ehrliche Alternativen geben (in den Himmel ragen lassen / Lupe / Balken brechen, nicht die Achse).
Leuchteffekte / Glas-Morphismus / 3D → Ablehnen, bestehende visuelle Syntax beibehalten. Benutzerdefinierte Farbwerte nach den custom-Regeln zuordnen; Mischen mehrerer Farbsysteme ablehnen.
Mehrere Farbtöne für eine einzelne geordnete Serie → Ablehnen. porcelain, wire oder zurück zu Mono.
Mehr als 6 Kategorien und trotzdem Farbe gewünscht → Ablehnen, zurück zu Mono-Grauskala.
Kartentypen (Choroplethen, Trajektorien) → Im Katalog gibt es keine geografische Pipeline. Ehrlich sagen, dass es nicht gemacht werden kann; nicht etwas Abweichendes hinkritzeln.
Reinen Dekorationselementen Interaktivität hinzufügen (Abschnitt 5, Frage 1) → Ablehnen und erklären.
Radardiagramm-Rekonstruktion → Nicht rekonstruieren. Nativer ECharts-Radar + Mono-Token-Reskinning verwenden (durch Praxis bestätigt: In Präsentationsszenarien haben „wiedererkennbare Diagrammtypen" einen Wert).
Zu wenige Daten, um den gewählten Diagrammtyp zu tragen (z. B. 3 Knoten für Force-Directed) → Auf ein einfacheres Diagramm downgraden und erklären.

8. Checkliste vor der Auslieferung

Sind Werte und visuelle Darstellung proportional? (Fläche mit sqrt? Keine unterbrochene Achse?)
Ist die Farbpalette kontrolliert? Verwendet die gesamte HTML-Datei oder derselbe Satz von Auslieferungen nur Mono, ein einziges integriertes Preset oder eine einzige benutzerdefinierte Palette? Wenn in Mono eine Nicht-Ladder-Farbe auftaucht, Nacharbeit; wenn in eingebetteter Farbe eine andere Preset-Farbe auftaucht, Nacharbeit; bezieht custom nur aus CUSTOM-Rollen und besteht den Kontrastcheck?
Überlappen sich Beschriftungen? (Lehre aus Barcode: Benachbarte Spitzenbeschriftungen benötigen einen minimalen Abstand.)
Wird die minimale Schriftgröße eingehalten? (Halbbreite 6.5 / volle Breite 5.5)
Sind die Beispieldaten deterministisch mit rnd? Sieht beim zweimaligen Aktualisieren gleich aus?
Funktioniert der Reveal-Mechanismus? (Beim Einrollen abspielen, bei Klick abspielen, Timer nicht überlappend, reduced-motion-Fallback vorhanden?)
Syntax mit node --check geprüft? (Den <script>-Inhalt extrahieren und prüfen.)
Ist der Vier-Satz der Karte vollständig? Ist der Titel eine Schlussfolgerung und kein Diagrammname?
Klärt der Untertitel die Legende klar? (Der Leser sieht nur diese Zeile, ohne den Code zu lesen.)
Wurde eine vollständige Kandidatenprüfung durchgeführt? Mindestens 3 Kandidaten und Ablehnungsgründe notieren, nicht nur „welche Vorlage verwendet wurde".
Wenn es mehrere Diagramme auf einer Seite gibt, wurden die Vorlagen global zugewiesen? Gibt es Wiederholungen ähnlicher Konturen, zu viele dunkle Karten, sind alle Diagramme zur gleichen radialen Form geworden?
Wurde für jedes Diagramm die Typnummer, die Gallery-Datei und der Kartentitel notiert? Stammt die Kernstruktur des fertigen Produkts tatsächlich aus dieser Vorlage und ist nicht neu erfunden?
Wenn Glance verwendet wird, wurde schriftlich festgehalten, warum Lupi Editorial und Lupi Basics nicht passen? Wenn nicht, zurück zu Lupi/Basics.
Letzte Frage: Wenn dieses Diagramm neben die entsprechende Karte in der gewählten Gallery gelegt wird, gehört es dann zur gleichen Vorlagenfamilie, nicht nur „der Stil ist irgendwie ähnlich"?

9. Einzeldatei-Vorlagengerüst

<!doctype html>
<html lang="de">
<head>
<meta charset="utf-8" />
<meta name="viewport" content="width=device-width,initial-scale=1" />
<title>Mono — {Diagrammname}</title>
<!-- Für ECharts: -->
<script src="https://cdn.jsdelivr.net/npm/echarts@6/dist/echarts.min.js"></script>
<!-- Für 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>/* Inline MONO.CARD_CSS */</style>
</head>
<body>
<div class="grid2">
  <div class="card"><!-- oder card dark / card wide -->
    <h2>{Schlussfolgerung als Titel}</h2>
    <div class="sub">{Erklärung} · {Legende} · {Zeitbereich}</div>
    <!-- Diagramm-Container, je nach Engine eine der drei Optionen: -->
    <div class="ch" id="ch"></div><!-- ECharts -->
    <!-- Handgeschriebenes SVG: <svg id="ch" viewBox="0 0 400 320"></svg> -->
    <!-- Chart.js (G1/G3): <div class="wrap"><canvas id="ch"></canvas></div>, mit .wrap{position:relative;height:320px} -->
    <!-- ⚠️ Chart.js erfordert zwingend .wrap{position:relative;height:320px}, da Chart.js sonst die Leinwand auf 0×0 skaliert. -->
    <div class="src">QUELLE: ...</div>
  </div>
</div>
</body>
</html>

...

[Der Rest des Skills (Anmerkungen, Lizenz etc.) folgt im gleichen Stil.]

Lieflat Charts — Diagramme nach dem Codex der Ästhetik

Was ist Lieflat Charts — Diagramme nach dem Codex der Ästhetik?

In Ihrer bevorzugten KI fragen

Dokumentation