Überprüfen (Verify)
Das Skript erkennt mechanische Fehler. Der Screenshot ist, wo du Designfehler siehst. Führe beides jedes Mal durch.
Ausführen
node ~/.config/opencode/lib/design/verify.mjs "design/Foo.html" --full --out design/.verify/foo.png
Häufige Varianten:
| Fall | Flags |
|---|---|
| Deck, ein Bild pro Slide | --each "section" --step --each-out design/.verify/deck |
| Dokument, Druckbreite | --width 900 --height 1200 --full |
| Poster oder feste Leinwand | --width 1080 --height 1350 --full |
| Schmale Panel-Prüfung | --width 900 |
| Langsame Animation (beruhigen) | --settle 2000 |
Es stellt die Datei auf einem temporären Localhost-Port bereit, lädt sie headless und gibt JSON sowie eine Zusammenfassung auf stderr aus. Exit-Code 1 bedeutet, dass etwas nicht stimmt.
Ausgabe lesen
errors— Konsolenfehler und nicht abgefangene Ausnahmen. Meistens ein Skript, das auf ein fehlendes Element verweist. Behebe die Ursache, unterdrücke sie nicht.failedRequests— fehlende Schriftarten, Bilder, Geschwisterdateien. Eine fehlende Schriftart wird stillschweigend durch eine Fallback-Schrift ersetzt, und die gesamte Typografie-Entscheidung geht verloren – das ist wichtiger, als es aussieht.horizontalScroll— Die Seite ist breiter als der Viewport. Auf dem Bildschirm ein unerwünschter Scrollbalken; im Druck werden Inhalte am rechten Rand abgeschnitten. Finde das Element aus der Listeoverflowing.metrics.fontFamilies— Was tatsächlich gerendert wurde. Wenn die gewünschte Schriftart nicht vorhanden ist, wurde sie nicht geladen, und du prüfst die Fallback-Schrift.images[].loaded: false— fehlerhafte Ressource oder falscher relativer Pfad.metrics.nodeCount— eine Plausibilitätsprüfung, kein Zielwert.
Token-Disziplin prüfen
Bevor du das Design beurteilst, überprüfe, ob es tatsächlich das System verwendet. Wenn tokens.css neben dem Artefakt liegt, macht der Prüfer das für dich unter tokens: Er warnt, wenn die Seite die Datei nicht verlinkt, und listet jedes Farb-Literal – Hex, oklch(), rgb() und ähnliche – im eigenen CSS der Seite und in anderen lokalen Stylesheets wie components.css auf.
Jeder Treffer ist entweder ein Token, das existieren sollte, oder ein Wert, der die Datei umgeht. Strukturelles CSS (z. B. eine Skalierungstransformation eines Decks, das Raster eines Posters) enthält berechtigterweise px-Zahlen; Farb-Literale fast nie. Neutraler Viewer-Chrome, wie die Letterbox eines Decks oder der Schreibtisch um eine Dokumentseite, verwendet benannte Farben wie black und white.
Dann den Screenshot ansehen
Öffne die Datei. Beurteile in dieser Reihenfolge:
- Hierarchie – Landet das Auge zuerst auf der Überschrift, dann auf den unterstützenden Details? Blinzele: Wenn alles gleich stark ist, gibt es keine Hierarchie.
- Abstände – Konsistenter Rhythmus und ausreichend davon. Ungleiche Lücken zwischen Gruppen sind das häufigste Zeichen eines unüberlegten Layouts.
- Ausrichtung – Alles, das eine linke Kante teilen sollte, tut dies nicht.
- Beschneidung und Überlappung – Text berührt oder überschreitet eine Grenze, ein Element verlässt seinen Container.
- Kontrast – Gedämpftes Grau auf hellem Grau ist der Standardfehler. Prüfe die tatsächlichen Werte, vertraue nicht auf die Screenshot-Darstellung.
- Inhalt – Kein Füller, keine übrig gebliebenen Platzhaltertexte, keine selbst erfundenen Zahlen.
Korrigieren und erneut ausführen
Korrigiere direkt aus dem Fehlertext; lies nicht die gesamte Datei erneut, um die Zeile zu finden. Führe nach jeder wesentlichen Änderung erneut aus. Drei Durchläufe sind das Limit – danach übergib es mit einer ehrlichen Notiz, was noch falsch ist.
Export
Wenn das Artefakt an einen Ort ohne den Ordner geht:
node ~/.config/opencode/lib/design/inline.mjs "design/Foo.html"
Das schreibt Foo.standalone.html mit den eingebetteten lokalen Stylesheets. Führe den Prüfer auch auf der eigenständigen Kopie aus – Inlining ist der Punkt, an dem relative Pfade und url()-Referenzen brechen.
Sage niemals, dass ein Design fertig ist, weil das Skript mit Exit-Code 0 beendet wurde. Das Skript weiß nicht, ob es gut aussieht.