Design Harness

Was macht Design Harness?

Führen Sie einen fortgesetzten Web-UI-Workflow aus. Halten Sie den Benutzer bei der Kontrolle der Absicht und trennen Sie die Designproduktion von der Überprüfung.

Start und Fortsetzung

Lösen Sie <skill-dir> als das Verzeichnis auf, das diese SKILL.md enthält; gehen Sie nicht davon aus, dass das aktuelle Arbeitsverzeichnis die gebündelten Skripte enthält.

1. Führen Sie node <skill-dir>/scripts/preflight.mjs --root <project> aus, bevor Sie Fragen stellen. Lesen Sie den Fähigkeitsbericht; installieren Sie nichts. Behandeln Sie einen fehlenden Dateisystempfad als Hinweis: Überprüfen Sie das geladene Skill-/Plugin-Inventar des Hosts, bevor Sie Impeccable oder Jakub als nicht verfügbar erklären.
2. Führen Sie node <skill-dir>/scripts/state.mjs init --root <project> aus. Dies aktualisiert sicher einen Legacy-Zustand, da init ein mutierender Befehl ist. Wenn ein Zustand vorhanden ist, führen Sie den schreibgeschützten Befehl status aus und setzen Sie bei dessen nextPhase fort; starten Sie niemals abgeschlossene Phasen neu. Verwenden Sie explizit migrate, wenn Sie einen Legacy-Lauf überprüfen oder aktualisieren möchten, ohne ihn neu zu initialisieren.
3. Lesen Sie nur die Referenz, die für die aktuelle Phase benötigt wird:
   • discovery/confirmation: references/interview.md
   • context/direction: references/context-contract.md
   • build/tool choices: references/routing.md
   • optional source selection: references/optional-tool-registry.json, nur nachdem eine Aktivierungsbedingung bestätigt wurde
   • review/QA/handoff: references/review-and-qa.md
4. Setzen Sie den Zustand nach jeder abgeschlossenen Phase mit node <skill-dir>/scripts/state.mjs advance <phase> --root <project> fort. Für human-feedback übergeben Sie auch --outcome used oder --outcome not-used. Für feedback-fixes übergeben Sie --outcome applied oder --outcome not-applicable.

Verwenden Sie diese feste monotone Reihenfolge:

preflight → discovery → confirmation → context → direction → build → internal-review → human-feedback → feedback-fixes → independent-review → fixes → qa → handoff → complete

Speichern Sie nur den Maschinenzustand in .design-harness/state.json; Berichte und Screenshots gehören in .design-harness/reports/. Speichern Sie niemals vollständige Chat-Transkripte, Token, Cookies, Anmeldeinformationen oder nicht zusammenhängende Umgebungsdaten.

Durchsetzen des Genehmigungsgates

Führen Sie adaptive Interviews durch und fassen Sie die Antworten in einer präzisen Bestätigungskarte zusammen. Fügen Sie Produkt, Zielgruppe, Hauptziel, Inhalt, Seiten/Oberflächen, gewünschte und unerwünschte Eigenschaften, positive und negative Referenzen, Einschränkungen, Bewegung, erforderliche Zustände, Stack, Delegation, KI-spezifische Zustände, WebGL-Toleranz, Richtlinie für externe Quellen und etwaige Grenzen kostenpflichtiger Lizenzen ein. Fragen Sie nur nach fehlenden oder wesentlichen Details.

Schreiben, bearbeiten oder generieren Sie keinen UI-Produktionscode, bevor der Benutzer die Bestätigungskarte nicht explizit genehmigt hat. Preflight, Fragen, schreibgeschützte Inspektion und ein Entwurf der Bestätigungskarte oder des vorgeschlagenen Intent-Inhalts im Chat sind erlaubt. Erstellen oder ändern Sie keine Projekt-Intent-.md-Dateien bis zur Genehmigung.

Wenn Referenzen fehlen, behandeln Sie beschreibende Wörter als ausreichend. Leiten Sie zwei oder drei benannte Richtungen mit konkreten Kompromissen ab und bitten Sie den Benutzer, eine auszuwählen. Generieren Sie visuelle Boards nur, wenn visuelle Werkzeuge vorhanden sind und der Benutzer davon profitieren würde; machen Sie ein Board niemals zur Voraussetzung.

Erstellen des genehmigten Kontexts

Füllen Sie nach der Bestätigung diese Dateien aus Benutzerantworten oder vom Benutzer explizit genehmigten Vorschlägen aus:

• PRODUCT.md, einschließlich eines genehmigten brand- oder product-Registers
• REFERENCES.md
• DESIGN.md
• ACCEPTANCE.md
• mindestens ein .impeccable/surfaces/<slug>.md

Kopieren Sie Strukturen aus den Vorlagen PRODUCT, references, design, acceptance und surface. Markieren Sie jede Intent-Datei nur dann als genehmigt, nachdem der Benutzer ihren Inhalt genehmigt hat. Führen Sie node <skill-dir>/scripts/validate-context.mjs --root <project> vor dem Build aus.

Halten Sie die H2-Abschnitte von DESIGN.md genau so, einmal pro Abschnitt, in dieser Reihenfolge: Overview, Colors, Typography, Elevation, Components, Do’s and Don’ts.

Behandeln Sie PRODUCT.md und DESIGN.md nach der Genehmigung als geschützt. Für jede spätere Änderung zeigen Sie den vorgeschlagenen Diff, bitten Sie um explizite Genehmigung und wenden Sie ihn dann an. Rationalisieren Sie niemals stillschweigend Abweichungen.

Zeichnen Sie jede genehmigte externe Komponente, jedes Rezept, jeden Effekt oder jedes Feedback-Integrations in REFERENCES.md mit seiner genauen Quelle, dem ausgewählten Element, der festgelegten Version oder dem festgelegten Commit (falls verfügbar), dem Zugriffsdatum, dem beabsichtigten Zweck, dem aktuellen Lizenz-/Bedingungen-Ergebnis, den Anpassungen und den erforderlichen Fallbacks auf. „Externe Bibliotheken verwenden“ ist keine Genehmigung für eine bestimmte Quelle.

Bauen mit Impeccable

Machen Sie den installierten Impeccable-Skill und seinen genehmigten Kontext zur alleinigen Design- und Produktionsautorität für diesen Durchlauf. Laden Sie seinen Skill und die relevanten Domänenreferenzen, übergeben Sie ihm dann die genehmigten Intent-Dateien und Oberflächen. Lassen Sie ihn Discovery nicht wiederholen oder genehmigte Absichten neu interpretieren. Lassen Sie Impeccable .impeccable/design.json generieren oder aktualisieren; bearbeiten Sie diesen Sidecar niemals manuell und akzeptieren Sie niemals eine daraus resultierende Änderung von PRODUCT.md oder DESIGN.md ohne den geschützten Diff-und-Genehmigungs-Ablauf.

Laden Sie im selben Produktionsdurchlauf keinen anderen breit gefassten Geschmacks- oder Designsystem-Skill. Leiten Sie enge Helfer nur gemäß references/routing.md weiter. Bewahren Sie die bestehende Komponentenbibliothek und den bestehenden Stack, sofern der genehmigte Kontext keine Änderung autorisiert. Installieren oder kopieren Sie niemals automatisch einen optionalen Registry-Eintrag; erklären Sie die genaue begrenzte Verwendung und holen Sie zuerst die Genehmigung ein.

Führen Sie nach dem Bauen eine Selbstüberprüfung von Impeccable durch und zeichnen Sie die Ergebnisse auf; dies ist internal-review, nicht die unabhängige Überprüfung. Sobald die UI stabil genug für eine Inspektion ist, gehen Sie zu human-feedback: Bieten Sie den genehmigten Agentation-Checkpoint an, wenn nützlich, oder zeichnen Sie „Not used“ mit --outcome not-used auf und setzen Sie fort. Halten Sie Agentation standardmäßig entwicklungs- und manuell/lokal; MCP, Webhooks und autonome Auflösung erfordern eine separate explizite Genehmigung. Wenden Sie in feedback-fixes nur zugewiesene Benutzeranmerkungen an und zeichnen Sie --outcome applied auf; wenn Feedback übersprungen wurde, zeichnen Sie „Not applicable“ mit --outcome not-applicable auf und setzen Sie ohne Bearbeitung fort. Lösen Sie Benutzeranmerkungen vor der unabhängigen Überprüfung auf.

Separate Überprüfung, Korrekturen und Qualitätssicherung

Starten Sie für independent-review einen neuen schreibgeschützten Unteragenten/Kontext mit Jakubs aktuellem better-interface-Skill und seinen sechs Domänenskills. Geben Sie ihm Screenshots, relevante Implementierungsdateien, Einschränkungen der Komponentenbibliothek und die genehmigten Intent-Dokumente. Fordern Sie eine vollständige Überprüfung nach dem Build an. Der Prüfer darf nur Ergebnisse melden und darf nicht bearbeiten oder stillschweigend neu entwerfen.

Beurteilen Sie jedes Ergebnis im Root-Kontext gegen PRODUCT.md, DESIGN.md, die Oberflächenspezifikationen, die Akzeptanzkriterien und die Komponentenbibliothek. Zeichnen Sie Annehmen/Ablehnen/Verschieben plus Begründung auf. Wenden Sie akzeptierte Korrekturen separat durch die Produktionsautorität an, fordern Sie dann eine fokussierte kurze schreibgeschützte Überprüfung der geänderten Bereiche an.

Folgen Sie references/review-and-qa.md. Führen Sie den Impeccable-Detektor, Playwright-Screenshots bei Mobil/Tablet/Desktop, Axe und Lighthouse aus. Decken Sie repräsentative Routen und anwendbare Lade-, Leer-, Fehler-, Langtext-, Hover-, Fokus- und Reduced-Motion-Zustände ab. Testen Sie für optionale Quellen auch deren Registry-Gates: semantische/statische Fallbacks, No-WebGL-Verhalten, genehmigte Browser, Mobil-CPU/GPU- oder Bundle-Budgets und den Ausschluss von Entwicklungswerkzeugen in der Produktion, sofern zutreffend. Markieren Sie nicht unterstützte oder nicht getestete Zustände als „Not reviewed“; melden Sie sie niemals als bestanden.

Für Schnittstellen mit sinnvoller Dokument-Scroll-Animation oder für Video-/Demo-Bereitschaft starten Sie den frischen Produktionsbuild auf einem dedizierten lokalen Port und führen Sie node <skill-dir>/scripts/verify-motion.mjs --root <project> --base-url <url> --routes /,<other-routes> --config .design-harness/qa/motion.config.json aus, nachdem Sie die gerüstartige Konfiguration angepasst haben. Der Verifizierer testet standardmäßig Mobil, Tablet und Desktop, isoliert jede Route in einem frischen Kontext, erfordert eine erfolgreiche Routenantwort, konfigurierten Inhaltsstamm, erwartete beobachtete URL/Weiterleitungskette und messbaren Dokumenten-Scroll, und mockt keine Anwendungsanfragen oder erlaubt Weiterleitungen, es sei denn, die explizite Projektkonfiguration deklariert jede Ausnahme. Behalten Sie seine Schema-Version-4 Playwright/Browser-Provenienz und Screenshot/Mock-Hashes mit der Übergabe bei. Behandeln Sie First-Frame/Startup-Probe- und Frame-Pacing-Schwellenwerte als Nachweis für diesen Rechner und Browser, niemals als universelle 60-FPS-Garantie.

Verwenden Sie node <skill-dir>/scripts/scaffold-qa.mjs --root <project>, um ein generisches QA-Gerüst in der Vorschau anzuzeigen, und fügen Sie --apply hinzu, nachdem die Bestätigungskarte den QA-Plan genehmigt hat. Fragen Sie nur dann erneut, wenn vorhandene Dateien ersetzt würden. Es installiert niemals Abhängigkeiten.

Übergeben

Melden Sie den Status Ready nur, wenn die genehmigten Akzeptanzkriterien bestanden sind und kein blockierendes Ergebnis oder keine ungeklärte QA-Lücke mehr vorhanden ist; andernfalls melden Sie Not ready. Listen Sie geänderte Dateien, Screenshots, Überprüfungsergebnisse und -dispositionen, automatisierte Prüfungen und Ergebnisse, nicht unterstützte Zustände, verbleibende Lücken und jede tatsächlich verwendete externe Quelle mit ihrer festgelegten Provenienz und dem Lizenz-Ergebnis auf. Führen Sie den Fortschritt handoff durch, führen Sie dann node <skill-dir>/scripts/state.mjs complete --root <project> nur aus, wenn der Workflow wirklich abgeschlossen ist.