weiguo-long/lwg-haibao-design

Posterartige HTML-Seiten für Vorträge

Entwirft „posterartige“ einseitige HTML-Seiten für Vorträge/Präsentationen und destilliert aus benutzereingereichten Bildern wiederverwendbare Regeln. Zwei Arbeitsabläufe:

• Arbeitsablauf A · Destillieren: Benutzer reicht Designbilder ein → Analyse von Farbschema/Layout/Schrift/Dekoration → Schreiben nach Vorlage in references/rules.md
• Arbeitsablauf B · Generieren: Benutzer gibt Anforderungen (Inhalt + Stimmung + Seitenverhältnis) → Bewertung und Auswahl nach references/selection.md → Generieren einer eigenständigen HTML-Seite mit angegebenem Seitenverhältnis → Abnahme nach references/checklist.md

Wichtigste Disziplin: Keine eigenen Layouts erfinden. Fast alle vom Benutzer abgelehnten Versionen entstanden durch „einen eigenen Stil erfinden“. Die Bibliothek enthält 24 Vorlagen und 9 Farbschemata. Nur wenn nichts Passendes gefunden wird, wird auf baseline.md zurückgegriffen. Wenn der Benutzer eine S-Nummer / C-Nummer nennt, wird diese direkt umgesetzt.

Arbeitsablauf A: Designbilder einreichen, Regeln destillieren

Zwei Analysemodi:

• Vollständige Analyse (Standard): Alle Felder gemäß Vorlage analysieren und als Vorlageneintrag (S-Nummer) ablegen.
• Nur Farbanalyse: Wenn der Benutzer „nur Farbschema“ oder „nur Farben analysieren“ angibt, oder das Bild offensichtlich eine Farbkarte/Farbinspiration ist (reine Farbblöcke, Farbtafeln), dann nur die Farbpalette extrahieren und Farbrollen zuweisen, als Farbschema-Eintrag (C-Nummer) ablegen; Layout/Schrift/Dekoration überspringen.

1. Bilder lesen: Bilder einzeln mit einem Bildbetrachter (z.B. ViewImage) ansehen; bei zu kleinem Text oder unklaren Details Bereich vergrößert betrachten. Bei mehreren Bildern erst alle vollständig ansehen, dann einheitlich destillieren. Nur das Design selbst analysieren: Wasserzeichen, Plattform-/Account-Logos sowie Statusleiste, Navigationsleiste usw. von Handy-Screenshots ignorieren; bei abgeschnittenen oder gestauchten Inhalten aus dem sichtbaren Hauptteil die ursprüngliche Designabsicht ableiten.
2. Einzelanalyse: Nach den Feldern von references/analysis-template.md analysieren (im Nur-Farben-Modus nach den entsprechenden Feldern dieser Datei). Schwerpunkt auf sofort wiederverwendbare Implementierungshinweise:
   • Farbschema: Hex-Werte von Primär-/Sekundär-/Akzent-/Neutralfarben, Flächenanteile, Hell-Dunkel-Verhältnis. Vorzugsweise python3 scripts/extract_palette.py <Bildpfad> für genaue Farbwerte verwenden; bei fehlendem Pillow oder Skriptfehler Näherungswerte mit dem Auge schätzen und im Eintrag „Näherung“ vermerken.
   • Layout: Aufteilung der Fläche, Fokusposition, Weißraumverhältnis, Raster, Symmetrie, Leserichtung.
   • Schrift: Titel-Stil, Schriftgrößen-Hierarchie (Prozent relativ zur kurzen Seite der Leinwand), Schriftstärke, Ausrichtung, Zeichenabstand.
   • Dekoration und Textur: Grafikelemente, Texturen, Rahmen, Verläufe/Rauschen/Farbblöcke usw.
   • Inhaltsdichte und geeignetes Seitenverhältnis: Passende Informationsmenge und Breiten-Höhen-Verhältnis.
   • Anwendungsszenario: Für welches Thema und welche Stimmung dieses Design geeignet ist.
3. Ablegen: Analyseergebnisse als Eintrag in references/rules.md anhängen – vollständige Analyse als Vorlageneintrag (S-Nummer), Nur-Farben-Analyse als Farbschema-Eintrag (C-Nummer). Beide in die Index-Tabelle eintragen (Nummer aus der Platzhalterzeile am Ende der Index-Tabelle nehmen, nach Gebrauch eine neue Platzhalterzeile hinzufügen; Regeln siehe analysis-template.md). Bei hoher Ähnlichkeit mit vorhandenen Einträgen diese zusammenführen oder als Variante kennzeichnen, keine Duplikate anhäufen. Die Originalbilder gleichzeitig in references/samples/ speichern (Einzelbild S-XX.jpg, Variante S-XXa.jpg / S-XXb.jpg) und im README dieses Verzeichnisses eintragen – nur Textbeschreibungen verlieren die Details, warum etwas gut aussieht (bei S-13 wurden die dreizeiligen weißen Hintergrundblöcke deshalb übersehen, jetzt im Eintrag nachgetragen).
4. Auswahl-Tabelle synchron aktualisieren: In references/selection.md in der Vorlagen-Tabelle eine Zeile ergänzen (Stimmung / Hell-Dunkel / Material / Dichte / Signaturelement / Seitenverhältnis-Eignung) und die neue Vorlage je nach Hell-Dunkel in die Sektion 4 „C × S Kompatibilitätsmatrix“ einfügen; sonst ist die neue Vorlage bei der Auswahl „unsichtbar“.
5. Bericht: Dem Benutzer mitteilen, welche Regel hinzugefügt wurde und für welches Szenario sie geeignet ist, damit er sie beim nächsten Mal direkt auswählen kann.

Arbeitsablauf B: Anforderungen eingeben, Seite generieren

1. Anforderungen analysieren: Themeninhalt, emotionale Stimmung (ernst/neutral/lebhaft/künstlerisch/frisch), Inhaltsdichte (einzelner Satz vs. Aufzählungspunkte vs. Daten vs. Text+Bild), angegebenes Seitenverhältnis (beliebig), ob echte Fotos benötigt werden.
2. Bewertung und Auswahl (nicht überspringbar): references/selection.md lesen, mit den fünf-dimensionalen Labels harte Filterung und Bewertung durchführen, die Top 3 auswählen; in einem Satz erklären, warum die ausgewählte Vorlage geeignet ist (Zusammenhang zwischen Signaturelement und Inhaltssemantik), dann zum nächsten Schritt übergehen. Gleichzeitig mit Sektion 4 „C × S Kompatibilitätsmatrix“ das Farbschema bestimmen, die fünf Rollen (bg / text / mid / accent / decor) mit Farbwerten füllen. Nach der Auswahl die Dateiliste in references/samples/README.md prüfen; bei vorhandenen Originalbildern diese unbedingt ansehen (Varianten-Dateinamen sind S-XXa / S-XXb, nicht den Pfad nach S-XX.jpg erraten); anhand der tatsächlichen Form der Signaturelemente erst loslegen. Nur wenn die Bibliothek leer ist oder keine Vorlage passt, baseline.md verwenden.
3. Inhalt strukturieren: Benutzerinhalt in eine posterartige einseitige Struktur organisieren (Haupttitel, Untertitel, Aufzählungspunkte, Daten, Zeitleiste usw.), in einem Bildschirm abgeschlossen, klare Hierarchie, einziger Fokuspunkt.
4. Seitenverhältnis anpassen: Leinwand auf das angegebene Seitenverhältnis setzen (Methode siehe „Seitenverhältnis-Anpassungsspezifikation“ und „Einheitenkonvention“ in baseline.md); Schriftgrößen/Abstände basierend auf der kurzen Seite der Leinwand umrechnen – .stage deklariert container-type:inline-size, bei Hochformat cqw, bei Querformat cqh verwenden, eine Änderung skaliert global.
5. HTML generieren: Das html-Skill ist eine optionale, verstärkende Abhängigkeit: Wenn installiert, zuerst komplett dessen SKILL.md und references/design/frontend-design.md lesen als Ergänzung; wenn nicht installiert, einfach überspringen und nach references/baseline.md (Design-Prinzipien, Schrift-Hierarchie, Seitenverhältnis-Anpassung, Einheitenkonvention) und references/checklist.md (12 Punkte Abnahme) verfahren. Die Auslieferung darf dadurch nicht unterbrochen werden. Ergebnis: eine eigenständige .html-Datei: Inline-CSS/JS, semantischer Dateiname (nicht index.html), Mobile-First, keine Zombie-Buttons, kein Emoji, mit Favicon; Bildmaterial mit lokalen relativen Pfaden oder Data-URIs, externe Bilder zuerst lokal herunterladen. Vor Überarbeitung zuerst cp der aktuellen Version nach _backup/ (Verzeichnis bei Bedarf mit mkdir -p anlegen).
6. Abnahme: Die 12 Punkte aus references/checklist.md einzeln nachrechnen (cqw / cqh → px manuell berechnen), wenn möglich Rendering-Screenshots erstellen und überprüfen (Text aus dem Rahmen / Elemente überlagern Text / Farbkontraste). Bei Nichtbestehen korrigieren, dann ausliefern (present_files mit files: [absoluter HTML-Pfad]). In der Lieferbeschreibung die Auswahlbegründung, geänderte Parameter und die tatsächliche Verifikationsmethode angeben.
7. Ablehnung notieren: Wenn der Benutzer eine Version ablehnt, in Sektion 5 von references/selection.md eine Zeile anhängen (Vorlage/Farbschema, wörtliche Aussage des Benutzers, Problemdiagnose), damit bei der nächsten Auswahl dieselbe Kombination vermieden wird.

Wartung der Regelbibliothek

• references/rules.md: Inkrementelle Regelbibliothek, das Kernvermögen dieser Fähigkeit. Bei jeder Bildeingabe wird ein Vorlageneintrag abgelegt; bei der Seitengenerierung wird bevorzugt daraus ausgewählt. Vor dem Lesen der CSS-Ausschnitte zuerst die „Einheitenkonvention“ oben beachten.
• references/selection.md: Auswahl-Entscheider. Fünf-dimensionale Labels der Vorlagen, Bewertungsregeln, C×S-Kompatibilitätsmatrix (deckt alle 24 Vorlagen ab), fünf Farbrollen, Ablehnungsprotokoll. Neue Vorlagen müssen gleichzeitig in der Label-Tabelle und der Matrix eingetragen werden.
• references/checklist.md: Abnahme-Checkliste vor Auslieferung. 12 nachrechenbare Standards + zwei strenge Regeln.
• references/baseline.md: Allgemeine Basislinie. Fallback, wenn die Regelbibliothek leer ist oder nichts passt; enthält Poster-Design-Prinzipien, Schrift-Hierarchie, Seitenverhältnis-Anpassungsspezifikation, Einheitenkonvention und Verbote.
• references/analysis-template.md: Feldvorlage und Nummerierungsregeln für die Bildanalyse; die abgelegten Einträge werden nach dieser Struktur geschrieben.
• references/samples/: Originalbild-Archiv und Dateiliste.

Externe Abhängigkeiten (optional, blockieren nicht)

1. Erforderlich: scripts/extract_palette.py (benötigt Pillow). Bei fehlendem Pillow auf Schätzung mit dem Auge zurückfallen und im Eintrag „Näherung“ vermerken.
2. Optional: html-Skill. Das Skill-Wurzelverzeichnis variiert je nach Umgebung (auf Benutzerebene lokal: ~/.workbuddy/skills/), mit Glob nach **/html/SKILL.md suchen; wenn gefunden, nacheinander <html-skill>/SKILL.md und <html-skill>/references/design/frontend-design.md als ergänzende Design-Spezifikationen lesen. Das dazugehörige Screenshot-Skript (shot.py) existiert meist nicht, nicht erzwingen.
3. Wenn html-Skill / Screenshot-Skript nicht gefunden werden: Direkt nach baseline.md + checklist.md ausliefern und abnehmen, und in der Lieferbeschreibung ehrlich „kein Rendering-Screenshot erstellt“ oder die verwendete alternative Verifikationsmethode angeben. Es ist verboten, den Arbeitsablauf B wegen fehlender externer Fähigkeiten zu unterbrechen.