joo6077/design-mockup

Gotchas

1. Keine Unterscheidung von Entwürfen allein durch Farbvariationen – Unterscheidbarkeit ist keine Behauptung, sondern eine Berechnung – Entwürfe müssen unterschiedliche Layout-/Kompositionsansätze verfolgen. Farben, Token-Werte, Kopiertexte und Icon-Austausche zählen nicht als axis_vector-Elemente; daher haben zwei Entwürfe, die sich nur darin unterscheiden, eine Hamming-Distanz von 0 und sind FEHLGESCHLAGEN. Entscheidungsformel und ausführbares Gate: ../../references/visual-change-protocol.md §5 Variantenvertragsmatrix. Die empirische Begründung ist der globale REJECT UI-04 – der Vertrag hat bereits 4 Achsen explizit spezifiziert, aber beide Entwürfe hatten auf allen Achsen identische Werte.
2. Keine doppelten IDs – Alle Komponenten-IDs müssen über alle generierten Entwürfe hinweg global eindeutig sein. Verwende das Format {Komponentenname}-{kurzerHash}. Bei gleichem Hash wird neu generiert.
3. Keine Missachtung von Barrierefreiheitsprinzipien – Auch High-Fidelity-Entwürfe müssen die WCAG 2.2 AA-Kontrastverhältnisse (4,5:1) und minimale Touch-Ziele einhalten. WCAG 2.2 SC 2.5.8 AA = 24×24 CSS px / SC 2.5.5 AAA = 44×44 CSS px / Apple HIG 44pt ist die praktische Empfehlung für Touch-Geräte. Wenn Entwürfe standardmäßig AAA/Plattform-Empfehlungen von 44pt verwenden, sind sie sicher für die Figma/HTML-zu-Code-Phase. Auch wenn es visuell ansprechend ist, darf es keine Barrierefreiheitsverletzung geben. Quelle: W3C WCAG 2.2 SC 2.5.8.
4. Kein Fehler bei nicht konfiguriertem Figma MCP – Bei einer Figma-Übertragungsanfrage, wenn MCP nicht konfiguriert ist, behandle es als Hinweis, nicht als Fehler. Gib einen Hinweis wie „Für die Figma-Übertragung ist die Figma MCP-Konfiguration erforderlich“ zusammen mit dem HTML-Dateipfad.
5. Kein Lorem Ipsum – Platzhaltertexte werden anders gelesen als Inhalte, die echte Benutzer vorfinden werden. Verwende echte Inhalte oder realistische Beispieldaten. Titel, Schaltflächenbeschriftungen und Beschreibungstexte in Lorem Ipsum erlauben keine ordnungsgemäße Bewertung der Layout-Absicht.
6. Beschrifte Entwürfe nicht nur als „Variante A/Variante B“ – Jeder Entwurf sollte eine andere strategische Priorität widerspiegeln. Die Bezeichnung sollte diese Absicht enthalten. Beispiel: Konversionsoptimiert, Navigationsstark, Marken-Impact. Dies fördert eine Diskussion über Auswahlkriterien anstelle einer Geschmacksabstimmung.
7. Verwende Geräterahmen je nach Zweck selektiv – Für Kundenpräsentationen oder fast finale Demos vermitteln Geräterahmen einen fertigen Eindruck. Wenn jedoch der Vergleich von Layout-Strukturen oder die Überprüfung der Inhaltsdichte das Ziel ist, ist es besser, ohne Rahmen zu präsentieren. Der Rahmen-Chrome kann die eigentliche Beurteilung des Layouts beeinträchtigen.
8. Wenn Interaktion der Kernpunkt ist, verlasse dich nicht auf statische Vergleiche – Dropdowns, Overlays, Multi-Step-Flows, Ladezustände und Modale-Übergänge sind nur schwer anhand von nebeneinanderliegenden Standbildern zu beurteilen. Füge in HTML-Entwürfen Hover-/Fokus-/Klick-Interaktionen ein oder stelle interaktive Prototyp-Links bereit.
9. Beende responsive Entwürfe nicht nur mit Breakpoint-Snapshots – Wenn du die mobile/tablet/desktop-Dreiteilung zeigst, stelle sicher, dass auf jedem Bildschirm derselbe Benutzerszenario-Zustand eingestellt ist, damit der Vergleich sinnvoll ist. Gib auch Layout-Regeln wie Spaltenanzahl, Gutter und max-width an.
10. Container Queries werden empfohlen – Verwende für responsive Entwürfe auf Seitenebene Media Queries, auf Komponentenebene container-type: inline-size + @container-Queries. Größen-Queries werden ab Chrome 105, Firefox 110, Safari 16 unterstützt (style- und scroll-state-Queries haben andere Unterstützungsbereiche). Mit den Einheiten cqw/cqi sind containerrelative Größenangaben möglich. Setze Breakpoints dort, wo Inhalte umbrechen, und vermeide gerätebasierte Ziele. Quelle: research-log §J.
11. Fluid Typografie anwenden – Wende fluid font-size mit clamp(min, preferred, max) auf Texte in Entwürfen an, um ohne Breakpoints einen natürlichen Größentransition über alle Viewports zu zeigen. Besonders effektiv bei Hero-/Display-Texten. Quelle: research-log §E.
12. mockup.html ist im HTML-Format das normale Artefakt – Das Ausgabeformat dieses Skills (.design/mockups/*.html) verwendet bewusst das HTML-Format. Die strukturelle Abweichung von .md-Vertragsmustern wie design-tokens.md, audit-report.md ist ein beabsichtigter Designunterschied und kein Fehler. Wenn QA-Bewertungen oder Validierungstools darauf hinweisen, dass „das HTML-Format vom .md-Muster abweicht“, wird dies als False-Positive behandelt und unter Berufung auf dieses Gotcha ignoriert.
13. Bestätigung = Erstellung einer Genehmigungsdatei (nicht nur im Gesprächsprotokoll belassen) – Wenn der Benutzer einen Entwurf bestätigt, erstelle in Schritt 5 .design/approvals/{YYYYMMDD}-{Bildschirmname}.md. Notiere darin die ausgewählte Variante, den Artefaktpfad, die bestätigten visuellen Werte (Farben, Typografie, Abstände) und die Quellenangabe. Wenn die Bestätigung nur im Gespräch erfolgt und keine Datei hinterlassen wird, kann die spätere QA die „Überprüfbarkeit der Zielbedingungen (Entwurfsgenehmigungsaufzeichnung)“ nicht bestätigen und wird mit REJECT quittiert – das ist der tatsächliche Grund für den globalen REJECT UI-06 vom 2026-07-13. Wenn die Genehmigung im autonomen Modus erfolgt, hinterlasse ebenfalls einen Eintrag und gib als Genehmigungsinstanz „Autonomer Modus“ an. Spezifikation: ../../references/visual-change-protocol.md §4.
14. Ersetze bestätigte Entwurfswerte nicht durch Tokens (Visual Source of Truth Precedence) – Die vom Benutzer im Browser bestätigten Farben und Abstände haben Vorrang vor Projektpaletten-Tokens. Wenn du Entwurfsänderungswünsche bearbeitest, normalisiere die bestätigten Werte nicht auf einen einzelnen Tint oder vorhandenen Akzent „gemäß Token-Schema“. Wenn eine Tokenisierung erforderlich ist, definiere einen Token für diesen Wert, anstatt den Wert zu ändern, und schlage dies separat vor. Wenn das Projekt bereits ein Farbschema hat, liste die vorhandenen Werte zuerst auf, bevor du eine neue Palette einführst. Prioritätstabelle: ../../references/visual-change-protocol.md §1.
15. Teiländerungsanfragen betreffen nur die genannte Eigenschaft – Change Manifest ist Pflicht – Ändere bei Anfragen wie „nur diesen Kartenrahmen dicker“, „die Farbe ist jetzt richtig, aber nur das Gradient zurück“ nicht auch andere visuelle Eigenschaften (Hintergrund, Füllung, Radius, Schatten, Abstand, Typografie), die nicht genannt wurden. Hinterlasse vor der Bearbeitung eine Liste mit Ändern / Behalten in der Antwort und überprüfe nach der Änderung, ob die Werte der Behalten-Liste unverändert sind. Wenn sich Bereiche außerhalb der Absicht geändert haben, ist dies kein Erfolg, sondern ein Fehler; mache es rückgängig und wende es erneut an. Partielle Rollback-Anfragen machen nur die genannten Achsen rückgängig. Details: ../../references/visual-change-protocol.md §2.
16. Vereinbare die Variantenvertragsmatrix vor der Erstellung (Anzahlvertrag + Unterscheidbarkeits-Gate) – Fülle vor der Erstellung auch nur eines Entwurfs die 6 Spalten der ../../references/visual-change-protocol.md §5 Variantenvertragsmatrix aus und stimme sie mit dem Benutzer ab. Die Anzahl ist genau die vom Benutzer genannte, wenn nicht genannt, mindestens 5 und nach oben unbegrenzt so viele wie nötig. Die Regeln für die Anzahl, die Anzahl der Primärachsen und das Verbot von Nebenartefakten (Token-Dateien, Designsysteme, Surface-Lanes, Kataloge) sind im Quelltext harness/docs/guides/skill-design-guide.md §5.6 Variant Budget definiert und werden hier nicht neu definiert. Wenn auf eine Anfrage nach „ein paar Mockups“ Dutzende von Kacheln und Token-Dateien erstellt werden, muss der Benutzer alles löschen – das ist tatsächlich passiert.
17. Ein Entwurfsscreenshot ist ein artifact_snapshot – behaupte nicht, dass es den App-Bildschirm korrekt zeigt – Dass ein Mockup-HTML gut geladen wird, und dass der Benutzer diesen Bildschirm in der echten App sieht, sind unterschiedliche Aussagen. Wenn du Beweise anführst, gib den Kanalnamen mit an und füge in den PASS-Satz die 5 Elemente viewport, route/state, visible locator, count/height und screenshot id ein. Kanaldefinition: ../../references/visual-change-protocol.md §7 Evidence Channels. Wenn der Benutzer meldet, dass „es immer noch kaputt ist“, widerspreche nicht, sondern reproduziere es – die verbindliche Regel ist harness/docs/guides/skill-design-guide.md §3.8 User-Reported Failure Gate.

Prozess

Schritt 0: Automatische Erkennung und Laden

Durchsuche das Projekt nach Artefakten aus vorherigen Schritten:

# Erkennungsziele
.design/concept.md          → Konzept laden
**/theme/** **/tokens/**    → Design-Tokens laden
**/design-tokens.*          → Design-Tokens laden
.design/approvals/*.md      → Bestätigte Konfigurationen und verworfene Alternativen desselben Bildschirms laden
.planning/prd-*.md          → Nicht-Ziel-Tabellen (## Non-goals (einschließlich verworfener Entscheidungen) · ## No-gos) mit verworfenen Entscheidungen laden

• Konzept vorhanden → Stimmungs-Keywords, Farb-/Typografie-Richtung, UI-Muster in den Entwurf einfließen lassen
• Token vorhanden → konkrete Farbwerte, Typografie-Skala, Abstände im Entwurf anwenden
• Keines von beiden vorhanden → Entwurf nur aus Benutzeranforderungen erstellen
• Genehmigungsaufzeichnung vorhanden → bestätigte Konfiguration beibehalten, verworfene Alternativen und Elemente nicht wieder in den Entwurf aufnehmen, es sei denn, der Benutzer bittet darum (../../references/visual-change-protocol.md §4)
• PRD Nicht-Ziel-Tabelle vorhanden → deren Elemente nicht in den Entwurf aufnehmen. Auch wenn Code-Spuren vorhanden sind, nicht als Anforderung behandeln; wenn sie wiederbelebt werden sollten, frage vor der Erstellung den Benutzer (planning-kit plan-prd Gotcha 14)
• Genehmigungsaufzeichnung mit Pfad in der Verwerfenspalte → Diese Datei öffnen und den Originaltext lesen. Bei einem PRD-Pfad die Einträge der Nicht-Ziel-Tabelle verwenden, bei einem Arbeitsvertragspfad die Zeilen in Bereichsgrenze deren Zeilenende Kein PRD ist als verworfene Einträge behandeln und nicht in den Entwurf aufnehmen. Wenn die Datei nicht existiert oder nicht gelesen werden kann (.harness wird in neuen Arbeitsbäumen nicht mitgeführt), teile Kann nicht lesen: <Pfad> mit und frage den Benutzer vor der Erstellung des Entwurfs
• App-Code vorhanden → Die Konventionstabelle aus §0 wird erst in Schritt 1 erstellt, nachdem der Zielbildschirm festgelegt wurde – ohne Ziel kann man nicht „dieselbe Rolle“ auswählen. Lese so viele verschiedene vorhandene Bildschirme derselben Rolle gemäß der von §0 festgelegten Anzahl (Quelltext harness skill-design-guide.md §8.9). Verwende für wiederverwendbare Komponenten nur die tatsächlich durch grep bestätigten Namen. Füge die Konvention in die constants der Matrix aus Schritt 2-a ein

Schritt 1: Bildschirmanforderungen erfassen

Ermittle aus der Benutzeranfrage:

• Welche Seite/welcher Bildschirm (Login, Dashboard, Einstellungen usw.)
• Hauptfunktionen und Informationselemente
• Zielbenutzer

Hinterlege vor der Dateierstellung eine Antwort mit der Ziel- und Rücksprache aus ../../references/visual-change-protocol.md §0 – mit dem Dateipfad und der Route des Zielbildschirms (bei neuen Bildschirmen: Neu), und einem Satz, der die Anfrage inklusive Elementnamen und Platzierung wiedergibt. Bei Zweideutigkeit nachfragen.

Bei Unklarheiten beim Benutzer nachfragen.

Schritt 2: Anzahlvereinbarung · Variantenvertragsmatrix vereinbaren, dann High-Fidelity-HTML-Entwürfe erstellen

Schritt 2-a: Anzahl und Achsen zuerst festlegen (vor der Dateierstellung)

Fülle die ../../references/visual-change-protocol.md §5 Variantenvertragsmatrix aus und stimme sie mit dem Benutzer ab. Die Regeln für die Anzahl, die Achsenanzahl und das Verbot von Nebenartefakten sind im Quelltext harness/docs/guides/skill-design-guide.md §5.6 definiert.

Situation	Anzahl der Ausgaben
Benutzer nennt Anzahl	Genau diese Anzahl – sowohl Über- als auch Unterschreitung sind Verstöße
Nicht angegeben	Mindestens 5 – bei Bedarf mehr. Keine Obergrenze

Fülle die 6 Spalten der Matrix (variant_id · strategy_label · axis_vector · constants · intended_user_scenario · erstellte Datei) aus und bestehe den Selbsttest auf Unterscheidbarkeit – bei 3 oder mehr angegebenen Achsen muss die Hamming-Distanz aller Paare ≥ 2, bei 2 oder weniger ≥ 1 sein. Das ausführbare Gate befindet sich in §5. Wenn es ein überlappendes Paar gibt, reiche diesen Satz nicht ein, sondern entwerfe die überlappende Seite neu (globaler REJECT UI-04).

Erstelle keine nicht angeforderten Token-Dateien, Designsysteme, Surface-Lanes oder Komponentenkataloge. Wenn sie benötigt erscheinen, schlage sie als separaten Vorschlag vor und erstelle sie nach Genehmigung.

Schritt 2-b: Erstelle die vereinbarte Anzahl

Beziehe dich auf references/mockup-guidelines.md und erstelle die Entwürfe im Format ../../templates/mockup.html:

Jeder Entwurf wird als eigenständige HTML-Datei erstellt:

• .design/mockups/{Seitenname}-{Merkmal}.html (z. B. dashboard-sidebar.html)
• High-Fidelity-Niveau mit echten Farben, Typografie und Abständen
• Alle UI-Elemente mit ID im Format {Komponentenname}-{4-stelligerHash} versehen
• JavaScript-Overlay zur Anzeige der ID beim Hover enthalten
• Kein Lorem Ipsum – verwende echte Inhalte oder realistische Beispieldaten

Pool von strategy_label-Kandidaten (wähle gemäß der vereinbarten Anzahl aus. Wenn die vereinbarte Anzahl größer als der Pool ist, erstelle zusätzliche Strategien außerhalb des Pools, die zum angeforderten Bildschirm passen – diese Liste ist ein Beispiel, keine Begrenzung):

• Konversionsoptimiert – Sidebar-Navigation + Hauptinhalt, wichtige CTA oben fixiert
• Navigationsstark – Topbar + Kartenraster, Filter/Sortierung weit vorne platziert
• Informationsdicht – Tab-basiert + Listenansicht, betont scanbare Texthierarchie
• Marken-Impact – Vollbild-Hero + Scrollabschnitte, visuell zentrierter Einstieg
• Dashboard/Steuerung – Widget-Panel-Layout, Statuszusammenfassung + Schnellaktionen priorisiert

Das Grundgerüst hat fünf Entwurfsfelder A–E. Ab dem sechsten Entwurf wird ein Feldblock (f, g …) nach und nach hinzugefügt – Tab-Buttons, Panel, zwei Optionen für Vergleichsauswahl, Abstimmungskarte, Notizfeld, MOCKUP_CONFIG.variants-Einträge, T.ko.tab / T.en.tab-Buchstaben. Das Grundgerüst-Skript liest die Entwurfsliste nur aus MOCKUP_CONFIG.variants, also wird das Skript nicht geändert. Auch CSS wird nicht geändert – die Zeilen für Abstimmungskarten und Notizfelder verwenden grid-auto-flow: column, sodass sie auf breiten Bildschirmen in einer Zeile platziert werden, bei 768px oder weniger in zwei Spalten und bei 400px oder weniger in einer Spalte umbrechen.

Wenn Reaktionsfähigkeit in den Anforderungen enthalten ist, füge in jedem Entwurf Abschnitte für mobile/tablet/desktop-Breakpoints hinzu und gebe die Regeln für Spaltenanzahl, Gutter und max-width an.

Schritt 3: Erläuterung der Designabsicht

Erläutere für jeden Entwurf:

• Die strategische Priorität, die der Entwurf widerspiegelt (Konversion, Navigation, Marke usw.)
• Gründe für die Layout-Wahl und Informationsarchitektur
• Visuelle Schwerpunkte – wo die Aufmerksamkeit verweilt
• Für welches Benutzerszenario/welchen Kontext er am besten geeignet ist
• Einfache Begründung für die wichtigsten Entscheidungen (warum diese Anordnung)

Ordne die Präsentation nicht als „Bildschirmauflistung“ an, sondern als Fluss von Benutzerszenarien. Erkläre nicht jeden Entwurf isoliert, sondern stelle gegenüber, wie unterschiedliche Entwürfe dasselbe Problem unterschiedlich lösen, um die Diskussion über Auswahlkriterien zu erleichtern.

Schritt 4: Benutzerauswahl und Änderungen

• Benutzer wählt einen Entwurf aus oder gibt Feedback

• Kommunikation über IDs: „Vergrößere card-product-a3f2“

• Bei Anfragen zum Vergleich von Entwürfen eine Vergleichsmethode wählen:

  • Vergleich von strukturell sehr unterschiedlichen Entwürfen → Side-by-Side (nebeneinander anordnen)
  • Vergleich von Änderungen an einzelnen Elementen desselben Bildschirms → Vorher/Nachher überlagert erklären
  • Vergleich mit Entscheidungsbegründung/Handoff → Annotationen hinzufügen
  • Vergleich von Interaktionen/Zustandsänderungen → Hover/Fokus/Klick-Verhalten einschließen

• Bei Änderungsanfragen, die eine einzelne Eigenschaft oder ein einzelnes Element betreffen (nur Rahmen, nur Farbe, nur Abstand, nur dieser Chip) vor der Bearbeitung ein Change Manifest hinterlegen (Gotcha 15 · ../../references/visual-change-protocol.md §2):

  ## Change Manifest
  - Ändern: [Eigenschaft — Ziel-ID — aktueller Wert → Zielwert]
  - Behalten: [Restliche visuelle Eigenschaften desselben Elements – background / fill / radius / shadow / spacing / typography, soweit zutreffend · bei Angabe eines einzelnen Elements auch benachbarte Elemente in derselben Zeile/demselben Bereich und deren Platz]
  

  Überprüfe nach der Änderung, ob die Werte der Behalten-Liste unverändert sind. Wenn sie sich geändert haben, mache es rückgängig und wende nur die genannte Eigenschaft erneut an. Die Reihenfolge der Änderungen, die Überprüfung der Umsetzung und die Obergrenze für die Anzahl der Selbstkorrekturen folgen der Reihenfolge in §3 Vergleichswiederholung (Quelltext harness skill-design-guide.md §8.9). Bei jedem Capture die Capture-Checkliste aus §3 überprüfen.

• Nach der Änderung die HTML-Datei aktualisieren

• Bei Bestätigung die endgültige Version in .design/mockups/ behalten

Schritt 5: Genehmigungsaufzeichnung erstellen (bei Bestätigung Pflicht)

Wenn der Benutzer einen Entwurf bestätigt, erstelle .design/approvals/{YYYYMMDD}-{Bildschirmname}.md. Wenn die Bestätigung nur im Gesprächsprotokoll erfolgt, kann die spätere QA den Genehmigungsbeleg nicht überprüfen und wird mit REJECT quittiert (Gotcha 13 · global UI-06).

# Genehmigungsaufzeichnung — {Bildschirmname}

- Genehmigungsdatum: {YYYY-MM-DD}
- Genehmigungsinstanz: {Benutzer direkt bestätigt | Autonomer Modus (Begründung der Entscheidung angeben)}
- Zielartefakt: .design/mockups/{Dateiname}.html
- Ausgewählter Entwurf: {Strategielabel + Entwurfs-ID}
- Bestätigte visuelle Werte: {Zum Zeitpunkt der Genehmigung festgelegte Farben, Typografie, Abstände – bei späterem Konflikt mit Tokens haben diese Werte Vorrang}
- Bestätigte Konfiguration: {Elemente und Anordnung auf dem Bildschirm}
- Verworfene Alternativen/Gründe: {Verworfene Entwürfe/Elemente und Gründe – bei Entscheidungen, Funktionen oder Einstellungen zu entfernen, den Grund hier nicht wiederholen. Nur den Pfad zur PRD-Nicht-Ziel-Tabelle dieser Funktion und die Zeile „Nicht zu tun“ angeben (planning-kit plan-prd Gotcha 14) · wenn keine, `Keine`}
- Unbestätigt/Nachfolge: {Nicht vereinbarte, zurückgestellte Elemente}
- Quellenbeleg: {Zitat aus der Benutzeräußerung}

Wenn kein PRD für diese Funktion existiert (.planning/prd-<slug>.md), trage den Entscheidungstext im Arbeitsvertrag unter Bereichsgrenze an einer Stelle ein, mit den gleichen vier Feldern wie in der PRD-Nicht-Ziel-Tabelle (Nicht zu tun · Grund · Bereich · Code-Spuren) und hänge Kein PRD an das Zeilenende. In der Verwerfenspalte trage nur den Vertragspfad ein – wenn der Entscheidungstext an zwei Stellen steht, wird nur eine aktualisiert (../../references/visual-change-protocol.md §4). Wenn auch kein Arbeitsvertrag für diese Funktion existiert, ist der Entscheidungstext nur an dieser Stelle in der Verwerfenspalte dieser Genehmigungsaufzeichnung – trage die gleichen vier Felder, eine Entscheidung pro Zeile, unter der Verwerfenspalte als Liste mit - beginnend ein und hänge Kein PRD an das Zeilenende. Vor dem nächsten Entwurf folgt Schritt 0 den Pfaden in der Verwerfenspalte, um den Text zu lesen. Erstelle keinen PRD nur, um Verwerfungsaufzeichnungen zu führen (plan-prd Gotcha 1).

Überprüfe direkt nach der Erstellung:

ls .design/approvals/                      # Datei existiert
grep -c 'Bestätigte visuelle Werte' .design/approvals/{Dateiname}.md   # → 1
grep -cE '^- (Bestätigte Konfiguration|Verworfene Alternativen/Gründe):' .design/approvals/{Dateiname}.md   # → 2

Wenn der Entwurf nach der Genehmigung erneut geändert wird, aktualisiere auch diese Aufzeichnung. Veraltete Genehmigungsaufzeichnungen sind schlimmer als keine.

Schritt 6: Figma-Übertragung (optional)

Wenn der Benutzer eine Figma-Übertragung anfordert:

• Überprüfe die Figma MCP-Konfiguration
• Konfiguriert → übertrage den ausgewählten Entwurf oder einzelne Komponenten (nach ID) an Figma
• Nicht konfiguriert → gib den Hinweis „Für die Figma-Übertragung ist die Figma MCP-Konfiguration erforderlich“ + den HTML-Dateipfad erneut an
• Übertragung fehlgeschlagen → Fehlermeldung + HTML-Dateipfad angeben

Referenzen

• references/mockup-guidelines.md — Details zu den Entwurfserstellungsstandards
• ../../templates/mockup.html — Ausgabeformat für Entwurfs-HTML (gemeinsame Vorlage)
• ../../references/visual-change-protocol.md — Visuelle Priorität · Isolierung von Teiländerungen · Spezifikation der Genehmigungsaufzeichnung · §5 Variantenvertragsmatrix · §7 Evidence Channels (SSOT)
• harness/docs/guides/skill-design-guide.md §5.6 Variant Budget · §3.8 User-Reported Failure Gate — Quelltext für die Regeln zu Anzahl, Verbot von Nebenartefakten und Benutzermeldeprotokoll