Design Harness

Que fait Design Harness ?

Exécutez un workflow d'interface utilisateur Web reproductible. Gardez l'utilisateur en contrôle de l'intention et séparez la production du design de la revue.

Démarrage et reprise

Résolvez <skill-dir> comme le répertoire contenant ce SKILL.md ; ne supposez pas que le répertoire de travail courant contient les scripts fournis.

1. Exécutez node <skill-dir>/scripts/preflight.mjs --root <project> avant de poser des questions. Lisez son rapport de capacités ; n'installez rien. Considérez un chemin de système de fichiers manquant comme un conseil : vérifiez l'inventaire des compétences/plugins chargés par l'hôte avant de déclarer Impeccable ou Jakub indisponibles.
2. Exécutez node <skill-dir>/scripts/state.mjs init --root <project>. Cela met à jour en toute sécurité un état hérité car init est une commande de mutation. Si un état existe, exécutez la commande en lecture seule status et reprenez à sa nextPhase ; ne redémarrez jamais les phases terminées. Utilisez explicitement migrate lors de la vérification ou de la mise à niveau d'une exécution héritée sans la réinitialiser.
3. Lisez uniquement la référence nécessaire pour la phase en cours :
   • découverte/confirmation : references/interview.md
   • contexte/direction : references/context-contract.md
   • construction/choix d'outils : references/routing.md
   • sélection de source optionnelle : references/optional-tool-registry.json, uniquement après confirmation d'une condition d'activation
   • revue/QA/remise : references/review-and-qa.md
4. Avancez l'état après chaque phase terminée avec node <skill-dir>/scripts/state.mjs advance <phase> --root <project>. Pour human-feedback, passez aussi --outcome used ou --outcome not-used. Pour feedback-fixes, passez --outcome applied ou --outcome not-applicable.

Utilisez cette séquence monotone fixe :

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

Stockez uniquement l'état machine dans .design-harness/state.json ; les rapports et captures d'écran appartiennent à .design-harness/reports/. Ne stockez jamais de transcriptions complètes de chat, jetons, cookies, identifiants ou données d'environnement non liées.

Appliquer la porte d'approbation

Menez l'entretien de manière adaptative et résumez les réponses dans une carte de confirmation concise. Incluez le produit, le public, l'objectif principal, le contenu, les pages/surfaces, les qualités souhaitées et non souhaitées, les références positives et négatives, les contraintes, l'animation, les états requis, la pile technique, la délégation, les états spécifiques à l'IA, la tolérance WebGL, la politique relative aux sources externes et toute limite de licence payante. Ne demandez que les détails manquants ou conséquents.

N'écrivez, ne modifiez et ne générez pas de code de production UI avant que l'utilisateur n'ait explicitement approuvé la carte de confirmation. Le pré-vol, les questions, l'inspection en lecture seule et un brouillon dans le chat de la carte de confirmation ou du contenu d'intention proposé sont autorisés. Ne créez ni ne modifiez les fichiers .md d'intention du projet jusqu'à l'approbation.

Si les références sont absentes, traitez les mots descriptifs comme suffisants. Dérivez deux ou trois directions nommées avec des compromis concrets et demandez à l'utilisateur de choisir. Générez des planches visuelles uniquement lorsque des outils visuels existent et que l'utilisateur en bénéficierait ; ne faites jamais d'une planche une condition préalable.

Créer le contexte approuvé

Après confirmation, remplissez ces fichiers à partir des réponses de l'utilisateur ou des propositions que l'utilisateur approuve explicitement :

• PRODUCT.md, incluant un registre brand ou product approuvé
• REFERENCES.md
• DESIGN.md
• ACCEPTANCE.md
• au moins un .impeccable/surfaces/<slug>.md

Copiez les structures à partir des modèles PRODUCT, references, design, acceptance et surface. Marquez chaque fichier d'intention comme approuvé uniquement après que l'utilisateur a approuvé son contenu. Exécutez node <skill-dir>/scripts/validate-context.mjs --root <project> avant la construction.

Conservez les sections H2 de DESIGN.md exactement, une fois chacune, dans cet ordre : Overview, Colors, Typography, Elevation, Components, Do’s and Don’ts.

Considérez PRODUCT.md et DESIGN.md comme protégés après approbation. Pour toute modification ultérieure, montrez le diff proposé, demandez une approbation explicite, puis appliquez-la. Ne rationalisez jamais silencieusement une déviation.

Enregistrez chaque composant externe approuvé, recette, effet ou intégration de retour dans REFERENCES.md avec sa source exacte, l'élément sélectionné, la version ou le commit épinglé lorsqu'il est disponible, la date d'accès, le but prévu, le résultat actuel de la licence/conditions, les adaptations et les solutions de repli requises. "Utiliser des bibliothèques externes" n'est pas une approbation pour une source spécifique.

Construire avec Impeccable

Faites de la compétence Impeccable installée et de son contexte approuvé l'unique autorité de conception et de production pour ce passage. Chargez sa compétence et les références de domaine pertinentes, puis donnez-lui les fichiers d'intention et surfaces approuvés. Ne le laissez pas répéter la découverte ou réinterpréter l'intention approuvée. Laissez Impeccable générer ou rafraîchir .impeccable/design.json ; ne modifiez jamais ce sidecar manuellement, et n'acceptez jamais un changement résultant de PRODUCT.md ou DESIGN.md sans le flux de diff-et-approbation protégé.

Ne chargez aucune autre compétence large de goût ou de système de design dans le même passage de production. Acheminez les aides étroites uniquement selon references/routing.md. Préservez la bibliothèque de composants et la pile technique existantes, sauf si le contexte approuvé autorise un changement. N'installez et ne copiez jamais automatiquement une entrée de registre optionnelle ; expliquez l'utilisation exacte et limitée et obtenez d'abord l'approbation.

Exécutez une auto-revue Impeccable après la construction et enregistrez les résultats ; c'est internal-review, pas la revue indépendante. Une fois l'interface utilisateur suffisamment stable pour être inspectée, passez à human-feedback : proposez le point de contrôle Agentation approuvé quand il est utile, ou enregistrez Non utilisé avec --outcome not-used et avancez. Gardez Agentation développement uniquement et manuel/local par défaut ; MCP, webhooks et résolution autonome nécessitent une approbation explicite distincte. Dans feedback-fixes, appliquez uniquement les annotations utilisateur jugées et enregistrez --outcome applied ; lorsque les retours ont été ignorés, enregistrez Non applicable avec --outcome not-applicable et avancez sans modification. Résolvez les annotations utilisateur avant la revue indépendante.

Revue séparée, correctifs et QA

Pour independent-review, démarrez un sous-agent/contexte frais en lecture seule avec la compétence better-interface actuelle de Jakub et ses six compétences de domaine. Donnez-lui des captures d'écran, les fichiers d'implémentation pertinents, les contraintes de la bibliothèque de composants et les documents d'intention approuvés. Demandez une revue complète après la construction. Le réviseur doit uniquement rapporter les résultats et ne doit pas modifier ni reconcevoir silencieusement.

Jugez chaque résultat dans le contexte racine par rapport à PRODUCT.md, DESIGN.md, les spécifications de surface, les critères d'acceptation et la bibliothèque de composants. Enregistrez accepter/rejeter/différer ainsi que la justification. Appliquez les correctifs acceptés séparément via l'autorité de production, puis demandez une revue rapide ciblée en lecture seule des zones modifiées.

Suivez references/review-and-qa.md. Exécutez le détecteur Impeccable, les captures d'écran Playwright aux formats mobile/tablette/desktop, axe et Lighthouse. Couvrez les routes représentatives et les états applicables de chargement, vide, erreur, long texte, survol, focus et mouvement réduit. Pour les sources optionnelles, exercez également leurs portes de registre : solutions de repli sémantiques/statiques, comportement sans WebGL, navigateurs approuvés, budgets CPU/GPU mobile ou bundle, et exclusion de production des outils de développement selon le cas. Marquez les états non pris en charge ou non testés comme Non examiné ; ne les rapportez jamais comme réussis.

Pour les interfaces avec un mouvement de défilement de document significatif ou pour la préparation de vidéo/démo, démarrez la construction de production fraîche sur un port local dédié et exécutez node <skill-dir>/scripts/verify-motion.mjs --root <project> --base-url <url> --routes /,<autre-routes> --config .design-harness/qa/motion.config.json après avoir adapté la configuration échafaudée. Le vérificateur teste mobile, tablette et desktop par défaut, isole chaque route dans un contexte frais, nécessite une réponse de route réussie, une racine de contenu configurée, une chaîne d'URL/redirection attendue observée, et un défilement de document mesurable, et ne simule pas les demandes d'application ni n'autorise les redirections sauf si une configuration de projet explicite déclare chaque exception. Conservez sa provenance Playwright/navigateur de version de schéma 4 et les hachages de capture d'écran/mock avec la remise. Traitez les seuils de première image/sonde de démarrage et de cadencement d'image comme des preuves pour cette machine et ce navigateur uniquement, jamais comme une garantie universelle de 60 FPS.

Utilisez node <skill-dir>/scripts/scaffold-qa.mjs --root <project> pour prévisualiser un échafaudage QA générique et ajoutez --apply après que la carte de confirmation a autorisé le plan QA. Ne redemandez que lorsque des fichiers existants seraient remplacés. Il n'installe jamais de dépendances.

Remise

Déclarez l'état Prêt uniquement lorsque les critères d'acceptation approuvés sont satisfaits et qu'aucun résultat bloquant ou écart QA inexpliqué ne subsiste ; sinon, déclarez Pas prêt. Listez les fichiers modifiés, les captures d'écran, les résultats de la revue et leurs dispositions, les vérifications automatisées et leurs résultats, les états non pris en charge, les lacunes restantes et chaque source externe réellement utilisée avec sa provenance épinglée et le résultat de la licence. Avancez handoff, puis exécutez node <skill-dir>/scripts/state.mjs complete --root <project> uniquement lorsque le workflow est véritablement terminé.