Kirky-X/maliang (马良) – Design-System-Skill

Was macht maliang (马良) – Design-System-Skill?

Skript-Aufrufkonvention: Relative Pfade in python3 scripts/… beziehen sich auf das Installationsverzeichnis dieses Skills (CWD wird angenommen). Bei Ausführung im Benutzerprojekt werden alle Aufrufe mit dem absoluten Pfad {SKILL_DIR} ausgeführt, z. B. python3 {SKILL_DIR}/scripts/ui-graph.py …; Eingabeparameter wie --target/--framework-file zeigen explizit auf den Benutzerprojektpfad. Die Verwendung der mitgelieferten examples/ als Analyseziel ist verboten.

Die dreizehn Subkommandos decken den gesamten UI/UX-Lebenszyklus ab (Research → Definition → Design → Implementierung → Validierung → Auslieferung → Iteration, Gesamtübersicht siehe references/meta/lifecycle.md): design-md (Erstellung von DESIGN.md, inklusive Domänenexploration und Entscheidungsbuch) → redesign (Überarbeitung bestehender UI) → explore (Divergenz, Vergleich und Konvergenz bei unklarer Richtung) → draw-md (Seiten-Level UI-Markdown) · component (Einzelkomponenten-Briefing) → preview (Vorschau-Validierung) → critique (Usability-Review) → draw-harmony/draw-flutter/draw-element (Framework-Code) → ui-graph (UI-Beziehungsmanagement) · ip (IP-Charakter) / ip-handbook (IP-Visual-Handbuch).

• design-md (Upstream) – Erstellt ein prose-first DESIGN.md (YAML-Token + Markdown-Design-Begründung, Google Labs agent-first Format). Unterstützt die Aktionen 'Erstellen', 'Anwenden', 'Validieren' und 'Exportieren'. Beantwortet die Frage 'Was und Warum des Design-Systems'.
• redesign (Upstream-Umleitung) – Überarbeitet bestehende UI mit einer 10-dimensionalen Prüfung (inkl. SEO & Tracking, Produktkonsistenz) + Regelwerk. Unterstützt die Modi Refresh / Restructure / Rebuild / Deslop. Beantwortet die Frage 'Wie wird das bestehende Design besser'.
• draw-md (Midstream) – Erzeugt aus DESIGN.md harte Tokens UI-Markdown (Layout-Abschnitte + Komponenten-Parametertabelle, alle Farben/Schriftarten/Abstände referenzieren Tokens, RGBA + HEX). Beantwortet die Frage 'Wie wird jede Seite/Komponente konkret implementiert'.
• preview (Validierung) – Führt eine Live-Vorschau-Validierung des draw-md-Outputs mit dem Element Plus Framework durch, inklusive iOS/Android-Gerätehüllen. Beantwortet die Frage 'Stimmt das visuelle Ergebnis'.
• critique (Validierung · Tiefen-Review) – Nielsen 10 Heuristik 0-4 Bewertung + Persona-Walkthrough + Cognitive-Load-Checkliste; erzeugt Bewertungs-Snapshot/Trend/Backlog. Beantwortet die Frage 'Ist es benutzbar'. UI-Compliance/A11y-Checkliste liest references/meta/web-interface-guidelines.md; Produkt-UI-Craft-Disziplin und strenge Reviews/Deep-Slop-Entfernungsprozess siehe references/interface-design/ (ehemals unabhängiges Skill, jetzt integriert).
• draw-harmony (Downstream) – Konvertiert das logische UI aus draw-md in ein HarmonyOS (ArkTS) Framework-Implementierung. Beantwortet die Frage 'Wie schreibe ich den HarmonyOS-Code'.
• draw-flutter (Downstream) – Konvertiert das logische UI aus draw-md in ein Flutter Framework-Implementierung. Beantwortet die Frage 'Wie schreibe ich den Flutter-Code'.
• draw-element (Downstream) – Konvertiert das logische UI aus draw-md in ein Element Plus Framework-Implementierung. Beantwortet die Frage 'Wie schreibe ich den Element Plus-Code'.
• ui-graph (Beziehungsmanagement) – Erzeugt aus ui-markdown/ die Dateien ui-relationships.json (Hierarchie + Navigation), ui-hash-state.json (Hash-Baseline) und ui-implementation-map.json (Mapping logisches UI ↔ Implementierung). Beantwortet die Fragen 'Wie werden Seitenbeziehungen verwaltet, wie werden Änderungen verfolgt, wo sind Implementierungslücken'.
• ip (IP-Charakter) – Erstellt einen Prompt basierend auf der Tonalität des DESIGN.md, priorisiert den Aufruf der text_to_image API zur Bildgenerierung, fallback auf strukturiertes Prompt-Dokument. Beantwortet die Frage 'Wie wird das IP-Charakterbild generiert'.
• ip-handbook (IP-Visual-Handbuch) – Erzeugt Spezifikationen in 8 Modulen (Dreiseitenansicht / Bewegungsentwicklung / Emoji-Set / Schriftarten / Farben / Layout / Merchandise / Allgemeine Anforderungen), 2K HD 3:4. Beantwortet die Frage 'Wie wird das IP-Visual-System umgesetzt'.

Subkommando-Routing

🔴 CHECKPOINT: Ohne DESIGN.md ist der direkte Einstieg in die nachgelagerten Subkommandos draw-md / draw-* strikt verboten – es muss zuerst design-md durchlaufen werden, um das Design-System aufzubauen, da das UI-Markdown und der Framework-Code sonst keine Tokens referenzieren können.

Benutzerabsicht	Subkommando	Vollständiger Ablauf
DESIGN.md erstellen/generieren (aus Code/Screenshot/Interview)	design-md	references/commands/design-md.md
DESIGN.md auf Frontend-Code anwenden	design-md	references/commands/design-md.md
DESIGN.md linten / diffen / exportieren / validieren	design-md	references/commands/design-md.md
🔷 Vorhandene UI überarbeiten/redesignen (Refresh/Restructure/Rebuild/Deslop KI-Geruch entfernen)	redesign	references/commands/redesign.md
🔷 Richtungs-Feintuning (bolder/kühner / quieter/ruhiger / distill/verfeinert, visuelle Welt beibehalten, leichtes redesign-Dossier vorab)	redesign	references/commands/redesign.md
🔷 Einzelnes Komponenten-Briefing (Button / Eingabefeld / Toast etc., 8 Zustände hart)	component	references/commands/component.md
Seiten-Level UI-Markdown ausgeben (Token-Tabelle + Seiten-Spezifikation)	draw-md	references/commands/draw-md.md
Seitenübergreifende Komponenten (Navigationsleiste / Dock) standardisieren	draw-md	references/commands/draw-md.md
🔷 Richtung unklar, mehrere Konzepte vor der Finalisierung vergleichen (Layout/Dichte/Persönlichkeit/Interaktionsmodell wirklich unterschiedlich, Standard 3 max. 5)	explore	references/commands/explore.md
🔴 UI-Markdown Vorschau (Gerätehülle + Element)	preview	references/commands/preview.md
🔷 Usability-Review / Bewertung (Nielsen+Persona Walkthrough+Cognitive Load)	critique	references/commands/critique.md
🔴 UI-Markdown in HarmonyOS (ArkTS) Code konvertieren	draw-harmony	references/commands/draw-harmony.md
🔴 UI-Markdown in Flutter (Dart) Code konvertieren	draw-flutter	references/commands/draw-flutter.md
🔴 UI-Markdown in Element Plus (Vue 3) Code konvertieren	draw-element	references/commands/draw-element.md
🔷 UI-Beziehungsdiagramm generieren/abfragen (Hierarchie + Navigation + Hash + Implementierungs-Mapping)	ui-graph	references/commands/ui-graph.md
🔷 Navigationsziele abfragen (nicht generiert / abnormal / nicht implementierte Seite / semantische Drift Spezifikation↔Code (fehlende Funktion / hartcodierte Werte / Architekturabweichung))	ui-graph	references/commands/ui-graph.md
🔷 IP-Charakter basierend auf DESIGN.md generieren (API priorisiert, fallback prompt)	ip	references/commands/ip.md
🔷 IP-Visual-Handbuch generieren (Dreiseitenansicht/Bewegung/Emoji/Schriftart/Farbe/Layout/Merchandise)	ip-handbook	references/commands/ip-handbook.md

🔴 markierte Zeilen erfordern, dass zuerst ein draw-md-Output existiert; preview/draw-* sollten ohne UI-Markdown-Input im Subkommando-Prozess einen Fallback durchführen, der den Benutzer zurück zu draw-md führt. Wenn der Benutzer kein Ziel-Framework angibt, prüft draw-* zuerst den bestehenden Frontend-Stack des Benutzerprojekts (vorhanden → diesem Stack folgen und Annahme erläutern; nicht vorhanden → gemäß framework/INDEX.md 'Framework-Auswahl-Leitfaden' nach Szenario empfehlen, nach Bestätigung durch den Benutzer fortfahren). 🔷 markierte Zeilen gehören zu neuen Fähigkeiten: critique benötigt zuerst preview-Output oder eine zugängliche Seite, ui-graph benötigt zuerst draw-md-Output, ip/ip-handbook benötigen zuerst DESIGN.md.

Nach dem Einstieg in ein Subkommando wird gemäß dessen Ablaufdokument verfahren. Checkpoints, Grenzfälle und Liefer-Checklisten befinden sich in den jeweiligen Subkommando-Dokumenten – dieser Router enthält keine Prozessschritte.

Aufgaben-Größenklassen (Light / Full)

Klasse	Kriterium	Ablauf
Light	Projekt hat bereits DESIGN.md, Änderungsumfang = einzelne Komponente (component-Subkommando) oder lokale Anpassung einer einzelnen Seite	Kein erneutes Durchlaufen von design-md und Vollseiten-Checkliste: direkt draw-md für die Zielseite (Einzelkomponente über component) + preview Stichprobe dieser Seite/Komponente
Full	Neues Projekt / neuer Seitentyp / mehrere Seitenänderungen / Richtung unklar (zuerst explore) / kein DESIGN.md	Vollständige Kette design-md → draw-md → preview → draw-*

Light-Klasse ist keine Freifahrkarte von den Gate-Regeln. Die folgenden nicht kürzbaren Punkte müssen unabhängig von der Klasse vollständig ausgeführt werden:

1. a11y-Prüfung – aria-label, Touch-Ziele ≥44px, Kontrast, prefers-* Präferenzen (CRITICAL-Klasse, siehe references/meta/rules-priority.md Konfliktauflösungsregel 4, nicht verhandelbar);
2. preview hartes Gate – validate-draw-md-Prüfung und preview-Review-Disposition werden normal durchgeführt; die 'Stichprobe' der Light-Klasse bezieht sich nur auf die geänderte Seite, nicht auf Überspringen oder Absenken der Schwelle. Einzige Ausnahme: Wenn der Benutzer ausdrücklich keine Vorschau wünscht, wird die Darstellung und das Review gemäß preview.md „Überspringbedingungen (expliziter Opt-out)“ übersprungen, die validate-Prüfung läuft trotzdem, und der Auslieferungshinweis enthält ein DEGRADED-Banner;
3. draw-md harte Constraints (Token-Referenz / Dark-Referenz / Animation ≤400ms) werden mit der geänderten Seite Punkt für Punkt durchgegangen (siehe Constraints-Zusammenfassung in references/commands/draw-md.md).

Light-Klasse-Anfragen ohne DESIGN.md werden gemäß der ersten Zeile von „Fehlermodi und Fallback“ behandelt: Zuerst zu design-md führen, keine Ausnahme von der Größenklasse.

Unbeaufsichtigter Betrieb und CHECKPOINT-Degradierung

Kriterium: Wenn der Benutzer ausdrücklich sagt „du entscheidest / mach einfach“ oder die Sitzung unbeaufsichtigt ist (Benutzer abwesend, reagiert nicht), blockieren CHECKPOINTs nicht mehr punktuell. Nur wenn „die fehlenden Informationen die Kernrichtung ändern würden und nicht ableitbar sind“, wird einmalig nachgefragt; Details, die später geändert werden können, werden selbst entschieden und mit Annahmen erläutert.

CHECKPOINT-Kategorie	Standardaktion im unbeaufsichtigten Modus
Richtungs-/Vorschlagsbestätigung (design-md 0b/0c, explore-Richtungsliste)	Basierend auf Beweisen und Empfehlungen direkt vorantreiben; explore materialisiert trotzdem 3 Richtungen, drei Startbildschirme auf 480px verkleinert nebeneinander zur Eigenauswahl mit Begründung; wenn die Aufgabe nur eine Richtung vorgibt, wird nicht gefragt und keine Vergleichsseite erstellt
Extraktions-/Bestandsbestätigung (Token-Extraktion, Seitenliste)	Werte basierend auf aktuellen Beweisen ableiten und mit Konfidenz markieren (✅/⚠️/❓, Schreibweise siehe design-md 'Extraktionspfad-Konfidenzmarkierung'); Liste gemäß Standardregeln generieren
Lieferbestätigung (preview / critique Aktionsbestätigung)	Basierend auf Gate-Regeln und Beweisergebnissen vorantreiben, Lieferhinweis in der ersten Zeile mit Degradierungsbanner versehen; preview überspringen gehört nicht zu den autonomen Aktionen – nur wenn der Benutzer es ausdrücklich sagt, gemäß preview.md „Überspringbedingungen (expliziter Opt-out)“ erlaubt, unbeaufsichtigte Sitzungen führen es immer aus
Material-/API-Bestätigung (ip etc.)	Wenn API nicht verfügbar, bestehenden Fallback verwenden; Output im neuen Pfad speichern, nicht überschreiben

Präsentationsdisziplin: Lieferhinweis in der ersten Zeile mit ⚠️ DEGRADED: unbeaufsichtigt (<Grund>) (verwendet die bestehende DEGRADED-Form von critique/preview, keine zweite Modalität einführen); autonome Entscheidungen und Begründungen Punkt für Punkt in den Designhinweis aufnehmen; wenn kein Bild betrachtet werden kann, „Tatsächliche Optik nicht verifiziert“ vermerken, keine visuelle Bewertung abgeben; wenn keine ausführbare Umgebung vorhanden ist, nicht sagen, dass die Interaktion bestanden wurde. Nach Rückkehr des Benutzers werden Anpassungen gemäß seinen Kommentaren vorgenommen, die Revisionen gehen in das Entscheidungs-Backlog ein.

Schwache Laufzeitumgebung und Cross-Agent-Degradierung

Komplementär zum vorherigen Abschnitt: Die unbeaufsichtigte Tabelle regelt die Benutzerabwesenheitsachse, diese Tabelle regelt die Ausführungsfähigkeitsachse (kein Sub-Agent / nicht-mainstream-Modell / kleiner Kontext-Runtime).

Stufenweise Degradierung nach Belastungsgrad, die Degradierung opfert Abläufe, nicht die harten Constraints (a11y-Prüfung, Token-Referenz, G01–G46 CRITICAL-Gates, Echt-Asset-Vereinbarungen werden nicht ausgenommen):

1. explore mehrere Richtungen parallel → seriell: Vor jeder Richtung nur das DESIGN.md-Vertragsdokument und die eigene Richtungskarte lesen, nicht auf bereits bearbeitete Richtungen Bezug nehmen;
2. Immer noch angespannt → 1 komplette Spezifikation für die Hauptrichtung + leichte Karten für die restlichen Richtungen (nur 7 Felder der Richtungskarte + Startbildschirm-Skelett), Vergleichsseite auf nebeneinanderliegende Richtungskarten reduziert;
3. references nur die Pflichtlesespalte aus der aktuellen „Meta-Dokument-Lade-Reihenfolge“ des Subkommandos lesen, nicht alles;
4. draw-md bei großen Seitenmengen zuerst P0-Seiten ausliefern (siehe default-pages), restliche Seiten nach Richtungsbestätigung in Batches;
5. Checkpoint-Fragen durch Annahmen-Liste im Output ersetzen (Gate-Datei und CHECKPOINT-Degradierungssemantik bleiben gleich – siehe vorheriger Abschnitt, beide teilen sich dies).

Versionsprüfung

Dieser Abschnitt informiert den Benutzer darüber, ob es eine neue Version des maliang-Skills gibt. Die deterministische Logik (Throttling-Entscheidung / Versionsvergleich / Protokollierung) befindet sich in scripts/version-check.py, die Statusdatei ist standardmäßig ~/.maliang/version-check (mit --state änderbar); der Agent führt nur den Befehl und git ls-remote aus.

Vor der Verwendung dieses Skills zuerst python3 {SKILL_DIR}/scripts/version-check.py due ausführen; Ausgabe skip:* überspringt diesen Abschnitt direkt. Bei Ausgabe due:

1. Führe git -C {SKILL_DIR} ls-remote --tags --refs --sort=-v:refname origin 'v*' aus, nimm den ersten Tag und übergib ihn an python3 {SKILL_DIR}/scripts/version-check.py compare <tag> (--current liest standardmäßig das SKILL.md frontmatter dieses Repos);
2. Wenn compare same ausgibt (oder der Tag nicht dem Format vX.Y.Z entspricht – wird wie kein Tag behandelt), nichts erwähnen; bei Ausgabe von newer zuerst die Benutzeraufgabe beenden, danach dem Benutzer mitteilen „Maliang hat eine neue Version vX.Y.Z, Update unter https://github.com/Kirky-X/maliang/releases , bei Bedarf git -C {SKILL_DIR} pull --ff-only ausführen; um weitere Benachrichtigungen zu deaktivieren, führe python3 {SKILL_DIR}/scripts/version-check.py record off aus“;
3. Unabhängig vom Ergebnis mit dem tatsächlichen Ergebnis abschließen: python3 {SKILL_DIR}/scripts/version-check.py record ok (gefunden) oder record failed (Netzwerk getrennt / Netzwerk in Sandbox deaktiviert, in 7 Tagen erneut versuchen).

Ob ein Update durchgeführt wird, entscheidet der Benutzer; das Update wird nicht automatisch ausgeführt und es werden keine Dateien heruntergeladen.

Meta-Dokument-Ladereihenfolge (Phase × Pflichtlektüre)

Die normative Ebene references/meta/ muss nicht auf einmal vollständig gelesen werden – sie wird je nach aktueller Phase geladen. Planungsarbeiten laden keine Ausführungsdokumente:

Phase (Subkommando)	Pflichtlektüre vor Arbeitsbeginn	Nach Bedarf konsultieren
design-md (System erstellen)	product-reasoning.md, philosophy.md(vor Phase 1 prose verpflichtend), principles.md, ux-laws.md (Gesetzesebene „Warum“)	token-provenance.md(Phase 0d Entscheidungstabelle + Token-Herkunft), dials.md, spec-schema.md, analytics-events.md(Event-Tabelle), content-guide.md, templates/README.md(Auswahl in 4 Schritten), data-floor.md(für datenbasierte Produkte Phase 0a obligatorisch: Bindungstabelle + Kaltstart-Texte), workbench-structures.md(11 Struktur-Entscheidungen)
redesign (Überarbeitung)	ai-tells.md, rules-priority.md	dials.md, accessibility.md, surface-modes.md, ux-rules.md
explore (Richtung unklar, mehrere Konzepte vergleichen)	dials.md, surface-modes.md, token.md	ai-tells.md(Ausnahmeregeln), ux-rules.md, workbench-structures.md(vor datenbasierten Interface-Divergenzen Haupt-/Nebenstruktur bestimmen); vor Arbeitsbeginn python3 {SKILL_DIR}/scripts/style-ledger.py check (projektübergreifendes Aussehen-Hauptbuch, wiederholte Hintergrundfarben/Schriftfamilien aktiv vermeiden, blockiert nicht)
draw-md (Seitenspezifikationen ausgeben)	token.md, ai-tells.md	surface-modes.md, visual-assets.md, copy-strategy.md(Texte-Strategie für Persuade-Seiten), templates/INDEX.md, ux-rules.md, llm-behavior.md(lange Outputs vor Abschneiden schützen), performance.md, alignment.md(Ausrichtungsachsen/gleiche Höhe in einer Reihe, G44/G45), workbench-structures.md(Schritt 2.7 Struktur-Entscheidung), data-floor.md(Schritt 2.7 Datenbasis-Bindungstabelle), app-screen-floor.md(Datenbildschirm-Boden für Operate/Data-Modi); vor Arbeitsbeginn python3 {SKILL_DIR}/scripts/style-ledger.py check (projektübergreifendes Aussehen-Hauptbuch, blockiert nicht)
preview (Validierung & Auslieferung)	numbered-gates.md(nummerierte Gates G01–G46, Entscheidungsebene für Auslieferung/Ablehnung), ai-tells.md(Ausnahmeregeln), performance.md	token-provenance.md(Gruppe A Herkunftsbestimmung protokollieren), ux-rules.md, accessibility.md, content-guide.md, hardening.md(Produktionshärtung)
critique (Usability-Tiefen-Review)	surface-modes.md, principles.md	accessibility.md, ux-rules.md, day-two-blacklist.md(Vierte Frage·Definitionsebene Audit)
draw-harmony/flutter/element	performance.md, accessibility.md, polish-craft.md(Feinschliff-Handwerk, die meisten Einträge web-only)	token.md(Namen nachtragen), ux-rules.md
ip / ip-handbook	product-reasoning.md	content-guide.md

Metaregeln: rules-priority.md und philosophy.md sind die phasenübergreifende Entscheidungsebene, die bei Konflikten Vorrang vor phasenspezifischen Dokumenten haben; lifecycle.md ist die Gesamtübersicht des gesamten Lebenszyklus (sieben Phasen × Träger × Checkpoint); theory-router.md ist die Hilfsschicht für theoretische Entscheidungen (automatische Stufung + Phase×Theoriemodellpaket + Auslösebedingungen + zusammengesetzte Regeln); wenn in irgendeiner Phase theoretische Modelle für Schlussfolgerungen/Zuordnungen/Überzeugungen benötigt werden, wird nach Bedarf geladen; die detaillierte Ebene design-theory-models.md wird nur nach Ankerpunkten durchsucht, nicht vollständig gelesen; llm-behavior.md ist bei langen Dokumenten (> 2 Bildschirme) Pflichtlektüre.

Allgemein

• Unsicher, welches verwendet werden soll? Zuerst design-md. Ohne DESIGN.md können keine zuverlässigen draw-md-Hard-Tokens erzeugt werden, geschweige denn eine Framework-Anpassung.
• Vollständige Prozesskette (jeder Schritt Output = nächster Schritt Input): design-md (→.maliang/DESIGN.md) → draw-md (→.maliang/ui-markdown/.md) → preview (→.maliang/preview/preview_.html) → critique (→ Bewertungs-Snapshot) → draw-harmony/draw-flutter/draw-element (→ Framework-Code); Iteration fließt über redesign/ui-graph zurück in das Entscheidungsbuch.
• Dimensionsspezifikationen (Farbe / Schrift / Bild / Abstand / Ecke / Linie / Layout / Ausrichtung / Höhe) befinden sich in references/dimensions/ (enthält Farbpaletten-Bibliothek, Referenz-Design-Systeme, Glas-Effekt/Glas-Fortgeschritten Rezepte, Textur-Budget (eine Texturfamilie pro Seite / Transparenz tokenisiert), Elevation-Oberflächenhöhe, Ausrichtungsachsen/gleiche Höhe in einer Reihe/Überhang-Beziehungen, H5-Frame Handy-spezifischer Seiten-Container-Vertrag); Designprinzipien in references/meta/principles.md, die dreizehn Subkommandos teilen sich die Referenzen, keine Wiederholung in diesem Router. Sechs mechanische Fehler vom Desktop aufs Handy siehe references/meta/mobile-floor.md.
• Vorlagenwand in references/templates/: 14 Designsprachen (Glas-Effekt/M3 Expressive/Fluent 2/Bento/Schweizer Redaktion/OLED-Dunkelmodus/Daten-Dashboard etc.) + ganze Seiten-Modi (Bearbeitungsspalte / Tiefengalerie / Dashboard-Stilsammlung / Mobile 5 Typen / Scrollbildband / AI-Arbeitsplatz) + Landing-Page-Choreografie + Persönlichkeits-Richtungskarten; Auswahl über README 4-Schritte-Routing + variation-engine 7-Achsen-Kombination + Cross-Build-Gedächtnis (build-log + CSS-Stempel, ≥5 gleiche Achsen → Neuauswahl).
• Liefer-Skelett-Vorlagen in template/: DESIGN.md-Skelett / ui-markdown-Seitenskelett / IP-Prompt-Vertrag / A11y-Testprotokoll, zum Kopieren und Befüllen – die einzige kanonische Form des Skeletts befindet sich in den jeweiligen Dateien, die Befüllmethode und Validierungsregeln in den entsprechenden Subkommando-Dokumenten; Arbeitsteilung mit der Vorlagenwand (Auswahlreferenz vs. Ablage-Startpunkt) siehe template/README.md.
• Begriffsdatenbank in [`ref

… (Der Inhalt wurde aus Gründen der Kürze abgeschnitten.)