Bewegungs-Lexikon

Was macht Bewegungs-Lexikon?

Das Bewegungs-Lexikon ist ein Designsystem für Produktbewegungen. Es verbindet zwei gleichwertige Sammlungen: Motion Primitives beschreiben ein präzises Verhalten; Komponenten verwandeln ein oder mehrere Verhalten in eine vollständige, kopierbereite Produktinteraktion. Die Seitenkomposition platziert diese Interaktionen in einer kohärenten Produktoberfläche.

Entwerfen Sie vom Produktereignis des Benutzers aus. Erzeugen Sie Code nur dann, wenn er eine klare Zustandsänderung, einen fokussierten Akteur und eine zugängliche Übergabe unterstützt.

Wählen Sie einen Modus

Signal in der Anfrage	Modus	Liefergegenstand
Eine vollständige Seite, ein Bildschirm, eine Landingpage, ein Dashboard oder eine Einstellungsoberfläche	Seite erstellen	Seitenplan, genaue Registry-Komposition, Arbeitsseite und Akzeptanznachweise
Ein Gefühl, Begriff oder eine "Welche Animation"-Frage	Empfehlen	Rangliste der Kandidaten und eine Empfehlung
Ein Arbeitsablauf, Übergang oder eine mehrstufige Szene	Komponieren	Bewegungs-Blueprint und Beat-Plan
Eine Anfrage nach Produktionscode oder einer Framework-Anpassung	Implementieren	Portables HTML, CSS, JS oder angefragter Framework-Code
Vorhandener Code, eine Aufnahme oder ein Bericht über Ruckler	Überprüfen	Priorisierte Diagnose und konkrete Korrekturen
Ein neues Muster, Beispiel oder vorgeschlagene Bibliothekserweiterung	Beitragen	Kandidaten-Datensatz, bereit für die Prüfung durch den Betreuer

Wenden Sie die Moduspriorität deterministisch an: Eine vollständige Seite oder eine Oberfläche mit mehreren Regionen verwendet "Seite erstellen"; eine explizite Anfrage nach Code oder einer Framework-Implementierung einer einzelnen Interaktion verwendet "Implementieren"; eine Anfrage nur nach einem Designplan, Beat-Plan oder Blueprint verwendet "Komponieren". "Implementieren" kann einen Blueprint intern erstellen und liefert trotzdem das ausführbare Format, das der Benutzer angefordert hat. Eine Überprüfungsanfrage kann einen überarbeiteten Blueprint zurückgeben, wenn die aktuelle Interaktion eine größere Änderung benötigt.

Beginnen Sie jede Anfrage

1. Bewahren Sie die Sprache des Benutzers. Verwenden Sie Chinesisch für chinesische Anfragen und Englisch für englische Anfragen.
2. Identifizieren Sie den Produkt-Job, die primäre Aktion, den benutzersichtbaren Zustand vor und nach der Aktion, den primären Akteur und das beabsichtigte Gefühl.
3. Verwenden Sie die folgende Tabelle "Modus × Referenz". Laden Sie nur die für die aktuelle Aufgabe ausgewählten Dateien.
4. Laden Sie interior-principles.md, wenn die Anfrage Materialtiefe, Physikalität oder das Interior-Visualprofil benötigt.
5. Geben Sie Annahmen kurz an, wenn die Anfrage den Produktkontext offen lässt. Stellen Sie nur dann eine gezielte Frage, wenn eine fehlende Einschränkung das Design ändert.
6. Behalten Sie einen primären visuellen Akteur und höchstens zwei unterstützende Akteure in einem Beat bei. Geben Sie jedem Akteur eine semantische Art: Auslöser, Held, Status, Datensatz oder Umgebung. Geben Sie jedem Beat einen Produktzweck: Orientieren, Bestätigen, Kontinuität bewahren, Aufdecken oder Wiederherstellen.
7. Fügen Sie einen Plan für reduzierte Bewegung und Tastatur-/Fokus-Verhalten in jede komponierte, implementierte oder überprüfte Interaktion ein.
8. Untersuchen Sie bei einer Seitenanfrage das Host-Projekt, bevor Sie einen Stack auswählen. Bewahren Sie sein Routing, Komponentensystem, Design-Tokens und die Inhaltssprache. Verwenden Sie React und TypeScript für eine Neuentwicklung, es sei denn, der Benutzer fordert einen anderen Stack an.

Modus × Referenz-Routing

Modus oder Aufgabe	Lesen	Hinzufügen nur, wenn relevant
Seite erstellen	page-composition.md, page-system.md und components.md	motion-lexicon-page.css, wenn das Host keine etablierte visuelle System hat; ein Moment oder eine primitive Referenz für die primäre Zustandsänderung der Seite
Empfehlen einer veröffentlichten Komponente	components.md	Eine primitive Familie unten, wenn der Benutzer fragt, wie die Bewegung funktioniert
Empfehlen eines Verhaltens	motion-language.md	entrances, feedback, transitions oder sequencing
Komponieren eines Produktmoments	composition.md und contract.md	feedback-moment, choice-moment, change-moment oder workflow-moment
Implementieren	implementation-css.md	contract.md, wenn ein Blueprint konsumiert oder produziert wird; components.md für eine genaue veröffentlichte Komponente
Überprüfen	review-rubric.md	Die eine primitive oder Moment-Referenz, die zum beobachteten Verhalten passt
Beitragen	contribution.md und candidate-template.md	contract.md für den erforderlichen Blueprint und components.md, um eine vorhandene Komponente auszuschließen

Bewegungssprache

Verwenden Sie das Interior-inspirierte Profil im gesamten Skill:

• Modellieren Sie einen realen Produktzustand mit einer Einfassung, einem erhöhten Panel und einem vertieften Well, wenn Materialtiefe bei der Orientierung hilft.
• Beginnen Sie Bewegung mit einem Ereignis: einem Druck, einer Auswahl, einem Routenwechsel, einer Statusaktualisierung oder einer direkten Manipulation.
• Reservieren Sie Platz für Zustandsänderungen, sodass Labels, Schaltflächen und Datensätze ihre Geometrie behalten.
• Verwenden Sie Ankunftsbewegung für neuen Kontext: cubic-bezier(.23, 1, .32, 1) über etwa 200–280 ms. Verwenden Sie Verlassensbewegung für entfernten Kontext: cubic-bezier(.23, 1, .32, 1) über etwa 110–180 ms.
• Verwenden Sie transform und opacity für die bewegte Arbeit. Verwenden Sie kurze Farb- oder Fokusübergänge, wenn Feedback eine sofortige Reaktion benötigt.
• Lassen Sie eine zweite Benutzeraktion die erste Aktion unterbrechen, umkehren oder beruhigen.
• Bewahren Sie bei reduzierter Bewegung Zustand, Hierarchie, Fokus und Feedback durch einen statischen Zustand oder einen kurzen Opacity-Überblendung.

Lesen Sie die detaillierten Regeln in interior-principles.md.

Seite erstellen

Erstellen Sie eine vollständige, ausführbare Produktoberfläche im Projekt des Benutzers. Lesen Sie page-composition.md, page-system.md und components.md, bevor Sie die Seite planen.

1. Untersuchen Sie das Ziel-Repository, Framework, die Routen, vorhandene Tokens und installierten Abhängigkeiten. Wiederverwenden Sie das Host-System, wo es kohärent ist.
2. Geben Sie vor dem Bearbeiten einer Datei die Host-Inspektionstabelle und den kompakten Seitenplan aus, wie unten gezeigt. Fügen Sie den Seiten-Job und Archetyp, jede Hauptregion, die genaue veröffentlichte Komponenten-ID oder none, die primäre Zustandsgrenze und die Entscheidungen zu Responsive-Design und Theme ein. Jeder Host-Inspektionswert verweist auf den inspizierten Dateipfad. Eine Prosa-Implementierungsabsicht erfüllt dieses Gate nicht.
3. Verwenden Sie die Quelle unter https://motion-lexicon.pages.dev/r/<id>.json für eine veröffentlichte Komponente. Lesen Sie deren files, dependencies und Laufzeit vor dem Bearbeiten. Installieren Sie die gelieferte Quelle und Abhängigkeiten; passen Sie nur deren Props, Labels, Daten, Callbacks und Host-Platzierung an. Generieren Sie keine Annäherung derselben Komponente neu.
4. Schließen Sie das Registry-Integrations-Gate ab, bevor Sie eine ID auswählen: Jede aktuelle Registry-Quelle verwendet Tailwind-Utility-Klassen. Bestätigen Sie, dass das Host bereits Tailwind kompiliert, oder fügen Sie dessen unterstütztes Tailwind-Setup hinzu, wenn die Änderung der Host-Toolchain im Rahmen liegt. Wenn dieses Setup nicht hinzugefügt werden kann, wählen Sie none für die Region und erstellen Sie einfaches semantisches UI; fügen Sie niemals stillschweigend eine CSS-Neuimplementierung einer Registry-Komponente ein. Notieren Sie die JSON-URL, die Zieldatei, die Abhängigkeitsliste und alle erforderlichen Laufzeiten im Seitenplan.
5. Überprüfen Sie den gerenderten interaktiven Knoten nach der Integration. Der Seitenstandard liegt bei mindestens 44 x 44 CSS-Pixel, auch wenn die standardmäßige visuelle Höhe einer Registry-Komponente kleiner ist. Übergeben Sie eine Host-Klasse durch ein dokumentiertes className-Prop und setzen Sie min-width und min-height auf diesem Knoten. Wenn die Quelle keinen sicheren Styling-Hook bietet, wählen Sie eine passende Komponente, die dies tut, oder lassen Sie die Region schlicht.
6. Geben Sie der Seite eine dominante Arbeitsfläche, einen primären Bewegungsmoment und höchstens zwei unterstützende Bewegungsmomente. Halten Sie statische Inhalte ruhig.
7. Verwenden Sie das Host-Designsystem. Für eine Neuentwicklung kopieren und passen Sie motion-lexicon-page.css an, wenden Sie dann die genaue Hierarchie und Responsive-Regeln aus page-system.md an.
8. Liefern Sie die gesamte Route oder Seite, einschließlich realistischer Inhalte, Lade-, Leer-, Erfolgs-, Fehler- und Wiederherstellungszustände, die zu ihrem Job gehören.
9. Überprüfen Sie 320, 390, 768 und 1440 Pixel Layouts; helle und dunkle Themes; Tastaturreihenfolge und Fokus; reduzierte Bewegung; interaktive Ziele mit 44 Pixel; Überlauf; und Konsolen- oder Hydratationsfehler. Ein erfolgreicher Build allein erfüllt nicht die Seitenakzeptanz. Starten Sie die lokale App oder die Produktionsvorschau und verwenden Sie verfügbare Browser-Automatisierung, um die primäre Aktion auszuführen und die gerenderte Geometrie bei jeder erforderlichen Ansichtsgröße zu überprüfen. Ein fehlendes Browser-Test-Skript im Projekt ist kein Hindernis: Verwenden Sie ein verfügbares Browser-Tool gegen die lokale Vorschau. Zählen Sie bei jedem Viewport jedes sichtbare button, link, input, select, textarea und benutzerdefinierten interaktiven Knoten auf; notieren Sie die minimale gerenderte Breite und Höhe plus eine offenders-Liste für Knoten unter 44 Pixel in einer Dimension. Beheben Sie jeden Täter und führen Sie alle vier Viewport-Prüfungen erneut aus, bevor Sie die Akzeptanz melden. Berichten Sie die Befehle, Interaktionen, Messungen und beobachtbaren Ergebnisse.

Halten Sie den Seitenplan prägnant:

## Host-Inspektion

| Bereich | Beobachtete Host-Evidenz |
| --- | --- |
| Framework | Name/Version — `package.json` |
| Route | Aktuelle Route und Zieldatei — `src/router.tsx` |
| Komponentensystem | Wiederverwendete Komponenten oder keine — `src/components/...` |
| Tokens / Theme | Token- und Theme-Mechanismus — `src/styles.css` |
| Tailwind | Installiert/kompiliert oder abwesend — `package.json`, `vite.config.ts` |
| Abhängigkeiten | Wiederverwendete Pakete und Versionen — `package.json` |

## Seitenplan

Job: …
Archetyp: …
Primäre Aktion: …
Primärer Zustand: Leerlauf → Ausstehend → Erfolg/Fehler

| Region | Produktzweck | Veröffentlichte Komponente | Zustand oder Bewegung |
| --- | --- | --- | --- |
| … | … | `component-id` oder `none` | … |

Registry:
- `component-id` — https://motion-lexicon.pages.dev/r/component-id.json —
  `target/file.tsx` — Abhängigkeiten: `package` / none

Responsive: 320/390 …; 768 …; 1440 …
Theme: hell …; dunkel …; reduzierte Bewegung …

Beginnen Sie nicht mit der Implementierung, bis jede Zeile in diesem Plan konkret ist.

Die endgültige Übergabe muss nach dem Einklappen zwischenzeitlicher Nachrichten unabhängig prüfbar bleiben. Wiederholen Sie die vollständige Host-Inspektionstabelle und den Seitenplan, einschließlich der Regionstabelle und der Registry-Zeilen, und fügen Sie dann eine Akzeptanztabelle mit einer beobachteten Zeile für jedes der folgenden Elemente hinzu:

| Prüfung | Beobachtete Evidenz |
| --- | --- |
| Build | Befehl und Exit-Ergebnis |
| 320 | Viewport-/Dokumentbreite, minimale Zielbreite/-höhe, Anzahl der Täter |
| 390 | Viewport-/Dokumentbreite, minimale Zielbreite/-höhe, Anzahl der Täter |
| 768 | Viewport-/Dokumentbreite, minimale Zielbreite/-höhe, Anzahl der Täter |
| 1440 | Viewport-/Dokumentbreite, minimale Zielbreite/-höhe, Anzahl der Täter |
| Hell / dunkel | Wie jedes Theme aktiviert und inspiziert wurde |
| Tastatur / Fokus | Genauer Tastenpfad, Fokus-Eintritt und Fokus-Rückkehr |
| Reduzierte Bewegung | Emulierte Präferenz und beobachtetes statisches oder Überblendungs-Ergebnis |
| Ziele | Gemessene minimale Breite und Höhe der sichtbaren interaktiven Knoten |
| Primärer Zustand | Ausgeführte ausstehende, Erfolgs-, Fehler-/Wiederholungs- und Unterbrechungszustände, die zutreffen |
| Laufzeit | Anzahl der Konsolen-, Seiten-, Anfrage- und Hydratationsfehler |

Nennen Sie die installierten Komponenten-IDs und geänderten Dateien. Verwenden Sie Unvollständig für eine nicht beobachtete Zeile und geben Sie die fehlende Fähigkeit an. Beschreiben Sie keine nicht beobachtete Prüfung als unterstützt oder bestanden.

Wenn der Benutzer das Aussehen des Bewegungs-Lexikons anfordert, bewahren Sie das visuelle Profil und die Interaktionsqualität, während Sie die Inhalte und Informationsarchitektur an das tatsächliche Produkt anpassen. Vermeiden Sie es, eine Seite mit Bibliotheksdemos zu füllen.

Empfehlen

Geben Sie eine kompakte Entscheidung zurück, die der Benutzer sofort anwenden kann.

1. Ordnen Sie die Anfrage bis zu drei veröffentlichten Kandidaten aus components.md oder aus der einen relevanten primitiven Referenz zu, die oben ausgewählt wurde. Beginnen Sie jede Kandidatenzelle mit ihrer genauen veröffentlichten Komponenten- oder primitiven ID in Backticks, gefolgt von einem menschenlesbaren Label, wenn nützlich. Ein beschreibendes Label allein ist unvollständig. Präsentieren Sie niemals eine unbekannte oder erfundene ID als veröffentlicht.
2. Erklären Sie den visuellen Unterschied in Produktbegriffen: räumliche Kontinuität, Gewicht, Tempo, Aufmerksamkeit oder Statusvertrauen.
3. Wählen Sie einen Kandidaten, wiederholen Sie dessen genaue veröffentlichte ID in der Auswahlzeile und geben Sie das Standard-Timing, die Standard-Easing, den Standard-Auslöser und die Behandlung für reduzierte Bewegung an.
4. Bieten Sie einen Bewegungs-Blueprint an, wenn die Anfrage mehrere Zustände beschreibt.

Verwenden Sie dieses Format:

## Vorschlag / Recommendation

| Kandidat / Candidate | Passendes Szenario / Fit | Unterschied / Difference |
| --- | --- | --- |
| `published-id` / … | … | … |

**Auswahl / Pick:** `published-id` / …

- Auslöser / Trigger: …
- Timing / Timing: …
- Barrierefreiheit / Accessibility: …

Komponieren

Erstellen Sie einen Bewegungs-Blueprint, bevor Sie zu Implementierungsdetails übergehen. Verwenden Sie assets/motion-blueprint.schema.json als Vertrag. Jede Kompositionsantwort enthält ein schema-gültiges, gefenstertes JSON-Objekt; ersetzen Sie den Blueprint nicht durch eine Prosa-Tabelle oder ein Textdiagramm. Halten Sie Zeichenkettenwerte im Chat kompakt, schreiben Sie dann dasselbe JSON in eine Datei, wenn der Benutzer nach einem wiederverwendbaren Artefakt fragt.

Jeder beats[].primitive- und jeder provenance.foundations[]-Wert muss eine genaue veröffentlichte primitive ID sein, die aus den ausgewählten Referenzen kopiert wurde. Menschliche Labels und unveröffentlichte Pseudo-IDs erfüllen den Blueprint-Vertrag nicht.

Schreiben Sie das endgültige JSON vor dem Antworten in eine temporäre Datei und führen Sie aus:

node "$CODEX_HOME/skills/motion-lexicon/scripts/validate-motion-blueprint.mjs" /tmp/blueprint.json

Beheben Sie jeden Validierungsfehler und führen Sie erneut aus, bis der Befehl mit dem Exit-Code 0 endet. Kopieren Sie das gefensterte JSON byte-[…]

[Truncated for translation]