Design system Google Stitch : diagnostiquer la dérive et vérifier le handoff

Google décrit le DESIGN.md comme un moyen portable d'importer et d'exporter des règles de design. Il peut contenir des décisions partagées sur les rôles de couleurs, la typographie, l'espacement, les principes de mise en page, le traitement des composants et les contraintes visuelles. Cette portabilité est essentielle : les règles peuvent circuler entre les projets et les plateformes au lieu de résider dans une seule conversation.

Le fichier a une mission plus restreinte. Il énonce des règles. Il ne prouve pas que chaque écran généré les a suivies, qu'un prompt ne les a pas outrepassées, ou que le code exporté les a préservées. Il ne certifie pas non plus l'achèvement des tâches, l'accessibilité, le comportement responsive, la qualité du code généré ou la préparation pour la production. Ces points nécessitent des vérifications distinctes.

Stitch évolue rapidement, et les résultats de recherche mélangent documentation produit, tutoriels et rapports d'utilisateurs. Qualifiez chaque affirmation de workflow par classe de preuve. Cela évite qu'un tutoriel optimiste ou un rapport d'échec isolé ne devienne accidentellement un contrat produit.

Pour toute capacité essentielle au handoff, utilisez la documentation officielle actuelle pour établir la disponibilité et vos propres observations enregistrées pour établir le comportement. Considérez les instructions tierces comme provisoires tant que vous ne les avez pas reproduites. Les rapports de la communauté sont des pistes de test, pas des prévisions.

Le maintien de la cohérence devient coûteux lorsque plusieurs artefacts semblent faisant autorité simultanément. Un site de référence suggère une échelle typographique, DESIGN.md en nomme une autre, un écran généré en introduit une troisième et quelqu'un corrige manuellement le code exporté. Sans registre de préséance, le dernier résultat visible a tendance à l'emporter, même quand il ne le devrait pas.

Pour chaque conflit non résolu, enregistrez les valeurs concurrentes, la couche propriétaire, la personne qui décide et les preuves dont elle a besoin. Ne tranchez pas en copiant simplement la valeur apparue dans la génération la plus récente.

Avant de demander à Stitch de générer d'autres écrans, notez les décisions qui doivent rester stables. Utilisez un langage observable. « Garder l'ensemble cohérent » n'est pas testable. « Utiliser la même structure de navigation principale sur les écrans de compte, de facturation et d'analyse » l'est.

• Navigation : structure, placement, état sélectionné, comportement de réduction et variations autorisées.
• Icônes : style source, traitement du contour ou du remplissage, règles de taille et endroits où des libellés textuels sont requis.
• Mode de couleur : modes autorisés, mode par défaut, rôles sémantiques et possibilité pour un écran de basculer indépendamment.
• Typographie : famille par rôle, graisses disponibles, échelle, intention de hauteur de ligne et traitement des données ou du code.
• Espacement et mise en page : largeurs de conteneurs, gouttières, rythme des sections, comportement de la grille et densité.
• Composants : traitements partagés pour les boutons, les champs de saisie, les cartes, les tableaux, les retours d'information et le focus.
• Exceptions : l'écran exact, l'état, le motif, l'approbateur et la limite de chaque déviation.

Ne vérifiez pas uniquement l'écran le plus abouti. Choisissez un ensemble représentatif incluant le shell principal, un écran de données dense, un formulaire, un état d'erreur ou destructif, et tout écran avec une exception approuvée. Si le mobile ou le mode sombre sont dans le périmètre, incluez explicitement ces états.

Lorsque deux écrans divergent, identifiez le premier point où les preuves diffèrent. Régénérer tous les écrans immédiatement peut masquer la cause et introduire de nouvelles modifications.

1. 1

   Vérifier si la règle directrice est complète

   Trouver la règle DESIGN.md correspondante. Si elle indique seulement « utiliser une navigation cohérente », elle ne définit ni la structure, ni les états, ni les exceptions. Révisez la règle au niveau de sa couche responsable avant de corriger les écrans.

2. 2

   Comparer les prompts et les suggestions acceptées

   Enregistrer le prompt original, les instructions de suivi et toutes les suggestions automatiques ou manuelles. Une instruction spécifique à un écran a pu outrepasser la règle partagée. Supprimez ou limitez cet override, puis réessayez uniquement le cas concerné.

3. 3

   Vérifier s'il existe une exception approuvée

   Une différence légitime n'est pas une dérive lorsque son écran, son état, sa raison et son périmètre ont été approuvés. Si l'exception n'est pas documentée, faites une pause et obtenez une décision de responsabilité plutôt que de la normaliser a posteriori.

4. 4

   Localiser le premier artefact divergent

   Comparez des écrans Stitch représentatifs avant d'inspecter le code en aval. Si les écrans concordent mais que l'export diffère, acheminez le constat vers la limite d'export ou d'implémentation. Si les écrans divergent déjà, maintenez la correction en amont.

5. 5

   Modifier une seule variable contrôlée par le responsable

   Appliquez un seul changement de règle restreint, comme le mode couleur par défaut ou le traitement de la sélection de navigation. Ne regroupez pas la typographie, l'espacement et les révisions de composants dans le même test.

6. 6

   Attribuer une disposition

   Validez (Pass) lorsque le changement prévu apparaît là où il est attendu sans dérive matérielle non liée. Révisez (Revise) lorsque la règle directrice ou le prompt est incomplet. Bloquez (Block) lorsque la responsabilité, les preuves ou la parité en aval ne sont pas résolues.

Un changement contrôlé teste si une règle déclarée atteint les endroits où elle le devrait. C'est plus restreint qu'une revue visuelle générale. Choisissez une règle avec un résultat observable, nommez les écrans et la surface d'export concernés, puis capturez les effets prévus et imprévus.

Controlled change

Project:
Observed date:
Reviewer:

Governing layer:
Rule identifier:
Current rule:
Proposed rule:
Reason for change:
Owner and approver:

Representative screens:
- Screen / state:
  Expected change:
  Actual observation:
  Evidence reference:
- Screen / state:
  Expected change:
  Actual observation:
  Evidence reference:

Approved exceptions:
- Screen / state:
  Exception and reason:
  Expected to remain unchanged: yes / no

Exported artifact:
Artifact and version:
Expected change:
Actual observation:
Evidence reference:

Unrelated drift:
- Navigation:
- Icons:
- Color mode:
- Typography:
- Spacing and layout:
- Component treatment:

Unresolved conflicts:
Owner:
Next evidence required:

Disposition: pass / revise / block
Disposition reason:

« Aucune dérive non liée observée » n'est valable que pour les écrans et l'artefact nommés. Cela ne signifie pas que l'ensemble du projet est cohérent. Lorsque votre flux de travail le permet, joignez des références aux captures d'écran, aux versions d'écrans, au texte des prompts, aux révisions de DESIGN.md et aux commits ou archives exportés.

Ce registre d'entrée montre comment intégrer une source délimitée dans le processus sans inventer des résultats Stitch. Ambient Sage est un kit Identity Forge gratuit et publié. Sa typographie documentée utilise Plus Jakarta Sans pour les rôles de corps de texte et de titres aux graisses 400, 500, 600 et 700, ainsi que JetBrains Mono pour le rôle mono aux graisses 400, 500 et 700. L'échelle publiée est compact-product.

Artifact intake: Ambient Sage

Source state
- Public kit page: documented
- Kit access: free and published
- Typography roles: documented
- Body and heading family: Plus Jakarta Sans
- Body and heading weights: 400, 500, 600, 700
- Mono family: JetBrains Mono
- Mono weights: 400, 500, 700
- Typography scale: compact-product
- DESIGN.md: available
- Semantic light and dark tokens: available
- Delivery formats: shadcn, Tailwind, CSS, and DTCG

Stitch evidence state
- DESIGN.md imported into Stitch: not tested
- Import warnings or transformations: not tested
- Generated-screen adherence: not tested
- Navigation consistency: not tested
- Icon consistency: not tested
- Light and dark mode behavior: not tested
- Typography and spacing parity: not tested
- Exported-artifact parity: not tested
- Controlled-change result: not tested

Handoff disposition
- Status: block pending evidence
- Reason: the source artifact is documented, but no Stitch-specific behavior or source-to-export parity has been observed
- Next action: import through the currently documented Stitch workflow, capture any transformation, then run one controlled change across representative screens and the chosen export

Transmettez ensemble le DESIGN.md directeur, les tokens lisibles par machine ou les artefacts d'implémentation, le registre des exceptions, le registre des changements contrôlés et le code exporté. Attribuez à chaque élément une version ou une référence de preuve stable. Le développeur doit pouvoir tracer une valeur visible jusqu'à un rôle sémantique ou une règle écrite et voir quelles différences ont été approuvées.

• Nommer la révision de DESIGN.md et l'artefact de token utilisés pour la génération.
• Lister les écrans représentatifs et leurs états enregistrés.
• Inclure les exceptions approuvées exactes et les conflits non résolus.
• Enregistrer la méthode d'export et la version de l'artefact résultant.
• Séparer la parité vérifiée des zones qui n'ont pas été testées.
• Acheminer les corrections en aval vers la règle responsable lorsqu'elles représentent des décisions de design partagées.

Si un développeur modifie une couleur partagée, une valeur d'espacement ou un traitement de composant uniquement dans le code exporté, traitez cela comme une dérive en aval jusqu'à ce que la source directrice accepte le changement. S'il s'agit d'un détail d'implémentation sans conséquence pour le design system, maintenez-le dans le code et expliquez pourquoi il n'a pas besoin de remonter en amont.

Validez le handoff du design system lorsque la règle directrice et le responsable sont clairs, que les écrans représentatifs affichent le résultat attendu, que les exceptions approuvées restent limitées, que l'artefact exporté préserve le changement vérifié et qu'aucune dérive matérielle non liée n'apparaît dans le périmètre.

Choisissez revise lorsque les preuves indiquent une règle DESIGN.md incomplète, un override de prompt trop large ou une exception mal définie que le propriétaire actuel peut corriger. Choisissez block lorsque les sources sont contradictoires sans propriétaire désigné, qu'un comportement spécifique à Stitch n'a pas été observé, que l'artéfact exporté enfreint une règle directrice ou que le dossier de preuves est trop insuffisant pour reproduire la décision.

Pour un nouveau projet, remplissez le registre d'autorité à quatre niveaux avant de générer un autre écran. Pour un projet existant, identifiez une incohérence visible, orientez-la vers sa couche responsable et exécutez la fiche de travail de changement contrôlé avant d'accepter ou de régénérer le reste.

• Le format DESIGN.md de Stitch est désormais open-source pour une utilisation multiplateforme : Google présente DESIGN.md comme un format portable permettant d'importer et d'exporter des règles de design entre différents projets et plateformes.
• Présentation du « vibe design » avec Stitch : Google décrit le workflow actuel de Stitch comme une combinaison d'un canevas AI-native, d'un agent de design, du support de DESIGN.md, de l'itération et de surfaces de livraison pour les développeurs.
• De l'idée à l'application : présentation de Stitch, une nouvelle façon de concevoir des UI : L'article de lancement de Google documente la génération à partir de texte ou d'images, l'affinement interactif, le transfert vers Figma et l'exportation de code frontend.
• Design system ou guide de style sur un projet Stitch : Un fil de discussion communautaire signale des incohérences d'icônes, de navigation et de mode couleur entre les écrans générés. Une réponse signée Google recommande des prompts plus explicites et la protection d'éléments sélectionnés.
• Comment utiliser Google Stitch pour créer un design system de site web en quelques minutes : Ce tutoriel tiers décrit l'extraction d'URL, la génération de prototypes multipages, l'itération et l'exportation, mais ses affirmations ne constituent pas un engagement produit officiel.
• Kit de design Ambient Sage : le kit public Ambient Sage propose un exemple de design délimité par la source avec un fichier DESIGN.md, des artefacts de livraison lisibles par machine, des rôles typographiques documentés et un système visuel compact orienté produit.
• Checklist de revue UI IA : testez les interfaces générées avant le déploiement : La checklist de revue publiée par Identity Forge sépare la conformité au design system de la préparation globale et utilise des états représentatifs, des changements contrôlés, des dossiers de preuves et des dispositions explicites.

• Stitch's DESIGN.md format is now open-source so you can use it across platforms: Google définit le fichier DESIGN.md comme un format portable permettant l'importation et l'exportation de règles de design entre différents projets et plateformes.
• Introducing "vibe design" with Stitch: Google décrit le workflow actuel de Stitch comme une combinaison d'un canevas natif IA, d'un agent de design, du support de DESIGN.md, de l'itération et de surfaces de livraison pour les développeurs.
• From idea to app: Introducing Stitch, a new way to design UIs: L'article de lancement de Google documente la génération à partir de texte ou d'images, l'affinement interactif, le transfert vers Figma et l'exportation de code frontend.
• Design system or design guideline on Stitch project: Un fil de discussion communautaire signale des incohérences d'icônes, de navigation et de mode couleur entre les écrans générés. Une réponse signée Google recommande des prompts plus explicites et la protection d'éléments sélectionnés.
• How to Use Google Stitch to Build a Website Design System in Minutes: Ce tutoriel tiers décrit l'extraction d'URL, la génération de prototypes multipages, l'itération et l'exportation, mais ses affirmations ne constituent pas un engagement produit officiel.
• Ambient Sage Design Kit: Le kit public Ambient Sage propose un exemple de design délimité par la source, incluant un fichier DESIGN.md, des artefacts de livraison lisibles par machine, des rôles typographiques documentés et un système visuel compact orienté produit.
• AI UI review checklist: test generated interfaces before you ship: La checklist de revue publiée par Identity Forge sépare la conformité au design system de la préparation globale et utilise des états représentatifs, des changements contrôlés, des dossiers de preuves et des dispositions explicites.