Motion Lexicon

Lexique du Mouvement

Le Lexique du Mouvement est un système de conception pour le mouvement de produit. Il connecte deux collections équivalentes : les Primitives de Mouvement décrivent un comportement précis ; les Composants transforment un ou plusieurs comportements en une interaction produit complète et prête à copier. La composition de page place ces interactions dans une surface produit cohérente.

Concevez à partir de l'événement produit de l'utilisateur. Produisez du code uniquement lorsqu'il soutient un changement d'état clair, un acteur ciblé et un transfert accessible.

Choisir un mode

Signal dans la demande	Mode	Livrable
Une page complète, un écran, une page d'accueil, un tableau de bord ou une surface de paramètres	Construire la Page	Plan de page, composition exacte du Registre, page fonctionnelle et preuve d'acceptation
Une sensation, un terme ou une question « quelle animation »	Recommander	Candidats classés et une recommandation
Un flux de travail, une transition ou une scène en plusieurs étapes	Composer	Plan directeur du mouvement et plan des battements
Une demande de code de production ou d'adaptation à un framework	Implémenter	Code HTML, CSS, JS portable ou code du framework demandé
Code existant, enregistrement ou rapport de saccades	Examiner	Diagnostic priorisé et correctifs concrets
Un nouveau modèle, un exemple ou une proposition d'ajout à la bibliothèque	Contribuer	Enregistrement candidat prêt pour la révision du mainteneur

Appliquez la priorité des modes de manière déterministe : une page complète ou une surface multi-régions utilise Construire la Page ; une demande explicite de code ou d'implémentation d'une interaction dans un framework utilise Implémenter ; une demande uniquement pour un plan de conception, un plan de battement ou un Plan directeur utilise Composer. Implémenter peut créer un Plan directeur en interne et livre toujours le format exécutable demandé par l'utilisateur. Une demande d'Examen peut renvoyer un Plan directeur révisé lorsque l'interaction actuelle nécessite un changement plus important.

Démarrer chaque demande

1. Préservez la langue de l'utilisateur. Utilisez le chinois pour les demandes en chinois et l'anglais pour les demandes en anglais.
2. Identifiez le travail produit, l'action principale, l'état visible par l'utilisateur avant et après, l'acteur principal et la sensation souhaitée.
3. Utilisez le tableau mode × référence ci-dessous. Chargez uniquement les fichiers sélectionnés pour la tâche en cours.
4. Chargez interior-principles.md lorsque la demande nécessite une profondeur matérielle, une physicalité ou le profil visuel Intérieur.
5. Énoncez brièvement les hypothèses lorsque la demande laisse le contexte produit ouvert. Posez une question ciblée uniquement lorsqu'une contrainte manquante modifie la conception.
6. Gardez un acteur visuel principal et au plus deux acteurs de soutien dans un battement. Donnez à chaque acteur un type sémantique : déclencheur, héros, état, enregistrement ou environnement. Donnez à chaque battement un objectif produit : orienter, confirmer, préserver la continuité, révéler ou récupérer.
7. Incluez un plan de mouvement réduit et un comportement clavier/foyer dans chaque interaction composée, implémentée ou examinée.
8. Pour une demande de page, inspectez le projet hôte avant de choisir une pile. Préservez son routage, son système de composants, ses jetons de conception et sa langue de contenu. Utilisez React et TypeScript pour une page nouvelle si l'utilisateur ne demande pas une autre pile.

Routage mode × référence

Mode ou tâche	Lire	Ajouter uniquement si pertinent
Construire la Page	page-composition.md, page-system.md et components.md	motion-lexicon-page.css lorsque l'hôte n'a pas de système visuel établi ; une référence de moment ou de primitive pour le changement d'état principal de la page
Recommander un composant publié	components.md	Une famille de primitives ci-dessous lorsque l'utilisateur demande comment fonctionne le mouvement
Recommander un comportement	motion-language.md	entrances, feedback, transitions ou sequencing
Composer un Moment Produit	composition.md et contract.md	feedback moment, choice moment, change moment ou workflow moment
Implémenter	implementation-css.md	contract.md lors de la consommation ou de la production d'un Plan directeur ; components.md pour un composant publié exact
Examiner	review-rubric.md	La référence de primitive ou de moment qui correspond au comportement observé
Contribuer	contribution.md et candidate-template.md	contract.md pour le Plan directeur requis et components.md pour exclure un composant existant

Langage du mouvement

Utilisez le profil inspiré de l'Intérieur tout au long de la compétence :

• Modélisez un état produit réel avec un cadre, un panneau surélevé et un puits encastré lorsque la profondeur matérielle aide à l'orientation.
• Commencez le mouvement à partir d'un événement : une pression, une sélection, un changement de route, une mise à jour de statut ou une manipulation directe.
• Réservez de l'espace pour les changements d'état afin que les étiquettes, les boutons et les enregistrements conservent leur géométrie.
• Utilisez le mouvement d'arrivée pour un nouveau contexte : cubic-bezier(.23, 1, .32, 1) sur environ 200–280 ms. Utilisez le mouvement de départ pour un contexte supprimé : cubic-bezier(.23, 1, .32, 1) sur environ 110–180 ms.
• Utilisez transform et opacity pour le travail en mouvement. Utilisez des transitions de couleur ou de focus courtes lorsque le feedback nécessite une réponse immédiate.
• Laissez une deuxième action utilisateur interrompre, inverser ou stabiliser la première action.
• En mouvement réduit, préservez l'état, la hiérarchie, le foyer et le feedback via un état statique ou un fondu enchaîné court.

Lisez les règles détaillées dans interior-principles.md.

Construire la Page

Construisez une surface produit complète et exécutable dans le projet de l'utilisateur. Lisez page-composition.md, page-system.md et components.md avant de planifier la page.

1. Inspectez le dépôt cible, le framework, les routes, les jetons existants et les dépendances installées. Réutilisez le système hôte là où il est cohérent.
2. Avant de modifier un fichier, affichez le tableau d'inspection de l'hôte et le Plan de Page compact ci-dessous. Incluez le travail et l'archétype de la page, chaque région majeure, l'ID de composant publié exact ou none, la limite d'état principale et les décisions de thème et de réactivité. Chaque valeur d'inspection de l'hôte cite le chemin du fichier inspecté. Une intention d'implémentation en prose ne satisfait pas cette contrainte.
3. Utilisez la source à https://motion-lexicon.pages.dev/r/<id>.json pour un composant publié. Lisez ses files, dependencies et runtime avant de modifier. Installez la source et les dépendances livrées ; adaptez uniquement ses props, étiquettes, données, callbacks et placement dans l'hôte. Ne régénérez pas une approximation du même composant.
4. Effectuez la validation de l'intégration du Registre avant de sélectionner un ID : chaque source actuelle du Registre utilise des classes d'utilitaires Tailwind. Confirmez que l'hôte compile déjà Tailwind, ou ajoutez sa configuration Tailwind prise en charge lorsque la modification de la chaîne d'outils de l'hôte est dans le périmètre. Si cette configuration ne peut pas être ajoutée, sélectionnez none pour la région et construisez une UI sémantique simple ; ne collez jamais silencieusement une réimplémentation CSS d'un composant du Registre. Enregistrez l'URL JSON, le fichier cible, la liste des dépendances et tout runtime requis dans le Plan de Page.
5. Auditez le nœud interactif rendu après l'intégration. La norme de page est d'au moins 44 x 44 px CSS, même si la hauteur visuelle par défaut d'un composant du Registre est plus petite. Passez une classe hôte via une prop className documentée et définissez min-width et min-height sur ce nœud. Si la source n'offre pas de crochet de style sûr, choisissez un composant approprié qui le fait ou laissez la région simple.
6. Donnez à la page une surface de travail dominante, un moment de mouvement principal et au plus deux moments de mouvement de soutien. Gardez le contenu statique calme.
7. Utilisez le système de conception de l'hôte. Pour une surface nouvelle, copiez et adaptez motion-lexicon-page.css, puis appliquez la hiérarchie exacte et les règles de réactivité de page-system.md.
8. Livrez l'intégralité de la route ou de la page, y compris le contenu réaliste, les états de chargement, vide, succès, échec et récupération qui appartiennent à son travail.
9. Vérifiez les dispositions à 320, 390, 768 et 1440 px ; les thèmes clair et sombre ; l'ordre du clavier et le focus ; le mouvement réduit ; les cibles interactives de 44 px ; le débordement ; et les erreurs de console ou d'hydratation. Le succès de la construction seul ne satisfait pas l'acceptation de la page. Démarrez l'application locale ou l'aperçu de production et utilisez l'automatisation du navigateur disponible pour exercer l'action principale et inspecter la géométrie rendue à chaque viewport requis. L'absence de script de test navigateur dans le projet n'est pas un blocage : utilisez un outil navigateur disponible contre l'aperçu local. À chaque viewport, énumérez chaque button, lien, input, select, textarea et nœud interactif personnalisé visible ; enregistrez la largeur et la hauteur minimales rendues, ainsi qu'une liste offenders pour les nœuds en dessous de 44 px dans l'une ou l'autre dimension. Corrigez chaque contrevenant et réexécutez les quatre audits de viewport avant de signaler l'acceptation. Signalez les commandes, interactions, mesures et résultats observables.

Gardez le Plan de Page concis :

## Inspection de l'hôte

| Préoccupation | Preuve observée de l'hôte |
| --- | --- |
| Framework | nom/version — `package.json` |
| Route | route actuelle et fichier cible — `src/router.tsx` |
| Système de composants | composants réutilisés ou aucun — `src/components/...` |
| Jetons / thème | mécanisme de jeton et de thème — `src/styles.css` |
| Tailwind | installé/compilé ou absent — `package.json`, `vite.config.ts` |
| Dépendances | packages et versions réutilisés — `package.json` |

## Plan de Page

Travail : …
Archétype : …
Action principale : …
État principal : inactif → en attente → succès/erreur

| Région | Objectif produit | Composant publié | État ou mouvement |
| --- | --- | --- | --- |
| … | … | `id-composant` ou `none` | … |

Registre :
- `id-composant` — https://motion-lexicon.pages.dev/r/id-composant.json —
  `fichier/cible.tsx` — dépendances : `package` / aucun

Réactif : 320/390 … ; 768 … ; 1440 …
Thème : clair … ; sombre … ; mouvement réduit …

Ne commencez pas l'implémentation tant que chaque ligne de ce plan n'est pas concrète.

Le transfert final doit rester indépendamment vérifiable après la réduction des messages intermédiaires. Répétez le tableau complet d'inspection de l'hôte et le Plan de Page, y compris le tableau des régions et les lignes du Registre, puis ajoutez un tableau d'Acceptation avec une ligne observée pour chaque élément ci-dessous :

| Vérification | Preuve observée |
| --- | --- |
| Construction | commande et résultat de sortie |
| 320 | largeur de la fenêtre/document, largeur/hauteur minimale de la cible, nombre de contrevenants |
| 390 | largeur de la fenêtre/document, largeur/hauteur minimale de la cible, nombre de contrevenants |
| 768 | largeur de la fenêtre/document, largeur/hauteur minimale de la cible, nombre de contrevenants |
| 1440 | largeur de la fenêtre/document, largeur/hauteur minimale de la cible, nombre de contrevenants |
| Clair / sombre | comment chaque thème a été activé et inspecté |
| Clavier / focus | chemin de touche exact, entrée de focus et retour de focus |
| Mouvement réduit | préférence émulée et résultat statique ou fondu observé |
| Cibles | largeur et hauteur minimales mesurées des nœuds interactifs visibles |
| État principal | états en attente, succès, erreur/reprise et interruption exercés qui s'appliquent |
| Runtime | nombre d'erreurs de console, de page, de requête et d'hydratation |

Nommez les ID de composants installés et les fichiers modifiés. Utilisez Incomplet pour une ligne non observée et indiquez la capacité manquante. Ne décrivez pas une vérification non observée comme prise en charge ou réussie.

Lorsque l'utilisateur demande l'apparence du Lexique du Mouvement, préservez le profil visuel et la qualité d'interaction tout en adaptant le contenu et l'architecture de l'information au produit réel. Évitez de remplir une page avec des démos de bibliothèque.

Recommander

Renvoie une décision compacte que l'utilisateur peut appliquer immédiatement.

1. Associez la demande à un maximum de trois candidats publiés de components.md, ou de la référence de primitive pertinente sélectionnée ci-dessus. Commencez chaque cellule candidate par son ID de composant publié exact ou de primitive entre guillemets, suivi d'une étiquette humaine si utile. Une étiquette descriptive seule est incomplète. Ne présentez jamais un ID inconnu ou inventé comme publié.
2. Expliquez la différence visuelle en termes de produit : continuité spatiale, poids, rythme, attention ou confiance dans l'état.
3. Choisissez un candidat, répétez son ID publié exact dans la ligne Pick, et indiquez le timing par défaut, l'assouplissement, le déclencheur et le traitement du mouvement réduit.
4. Proposez un Plan directeur de mouvement lorsque la demande décrit plusieurs états.

Utilisez ce format :

## 建议 / Recommandation

| Candidat / Candidate | Scénario approprié / Fit | Différence / Difference |
| --- | --- | --- |
| `id-publié` / … | … | … |

**推荐 / Pick:** `id-publié` / …

- 触发 / Déclencheur: …
- 节奏 / Timing: …
- 无障碍 / Accessibilité: …

Composer

Créez un Plan directeur de mouvement avant de développer les détails d'implémentation. Utilisez assets/motion-blueprint.schema.json comme contrat. Chaque réponse Composer inclut un objet JSON valide selon le schéma et entre guillemets ; ne remplacez pas le Plan directeur par un tableau en prose ou un diagramme texte. Gardez les valeurs de chaîne compactes dans le chat, puis écrivez le même JSON dans un fichier lorsque l'utilisateur demande un artefact réutilisable.

Chaque beats[].primitive et chaque valeur provenance.foundations[] doit être un ID de primitive publié exact copié des références sélectionnées. Les étiquettes humaines et les pseudo-ID non publiés ne satisfont pas le contrat du Plan directeur.

Avant de répondre, écrivez le JSON final dans un fichier temporaire et exécutez :

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

Corrigez chaque échec de validation et réexécutez jusqu'à ce que la commande se termine par 0. Copiez le JSON entre guillemets...