Xinvtech/mobile-design-os

Mobile Design OS

Exécute la plus petite chaîne de conception mobile complète qui satisfait le résultat demandé. Aiguille le travail vers les compétences spécialisées, conserve les identifiants stables et les preuves entre les étapes, et ne laisse jamais des visuels polis effacer les lacunes non résolues concernant le produit, la plateforme, l'état ou la validation.

Établir l'exécution

Déterminez :

• Résultat demandé : analyse, cadrage produit, UX, concept visuel, package de conception complet, prototype, revue, ou remise pour implémentation.
• Plateforme et facteurs de forme cibles.
• Entrées disponibles : idée de produit, captures d'écran, URL, éléments de marque, contrats existants, code ou preuves d'exécution.
• Périmètre autorisé : conception uniquement, prototype, ou modifications de code.
• Décisions qui nécessitent réellement l'utilisateur, en particulier le modèle de sécurité, l'acteur principal, la frontière MVP, la direction visuelle, la substitution du framework et la licence publique.

Créez design-run.json à partir de assets/design-run-template.json lorsque le travail traverse deux étapes ou plus ou doit pouvoir être repris. Lisez references/pipeline-contract.md avant de créer ou de mettre à jour le manifeste.

Aiguiller vers les compétences requises

Lisez intégralement le SKILL.md de la compétence sélectionnée avant d'exécuter son étape. Ne chargez pas le corps de chaque compétence lorsque la demande ne nécessite qu'une ou deux étapes.

Besoin	Compétence	Preuve d'achèvement
Découvrir ou comparer des références	mobile-reference-research	reference-research.json valide
Extraire la mécanique et l'ADN de design	analyze-mobile-ui	design-dna.json valide
Cadrer le produit et le MVP	mobile-product-brief	product-brief.json valide
Définir les flux, objets, écrans et états	mobile-ux-architect	ux-architecture.json valide
Établir la hiérarchie basse fidélité	mobile-wireframe	wireframe.json valide
Explorer et rendre l'interface visuelle	mobile-ui-design	Sélectionné par l'utilisateur, verrouillé, ui-design.json valide lorsqu'une remise structurée est demandée
Extraire les jetons/composants réutilisables	mobile-design-system	design-system.json valide
Modéliser ou rendre le comportement interactif	mobile-prototype	prototype.json valide et rapport d'alignement UI lorsque l'UI existe
Décider et tester le comportement natif	mobile-platform-guidelines	platform-guidelines.json valide
Auditer la chaîne	mobile-design-review	review.json valide avec une décision honnête
Planifier ou échafauder l'implémentation	mobile-design-to-code	Remise valide plus preuves de construction/test réels lorsque le code est généré

Exécuter la chaîne complète

Pour une demande de bout en bout, utilisez cet ordre tout en sautant uniquement les étapes explicitement marquées not-required :

1. Exécutez mobile-product-brief pour verrouiller le problème, l'audience, l'activation, la boucle principale, le MVP, les limites de confiance et les décisions non résolues.
2. Exécutez mobile-reference-research lorsque des références manquent ou doivent être comparées.
3. Exécutez analyze-mobile-ui lorsque des captures d'écran ou des produits de référence doivent devenir un ADN de design traçable.
4. Exécutez mobile-ux-architect à partir du brief validé et des décisions de référence.
5. Exécutez mobile-wireframe avant le style visuel lorsque la hiérarchie ou la pression d'état est non triviale.
6. Exécutez mobile-ui-design. Imposez exactement trois aperçus comparables et arrêtez-vous à sa porte de choix utilisateur. Ne sélectionnez pas de direction visuelle à moins que l'utilisateur ne délègue explicitement le choix.
7. Après la sélection, verrouillez la direction visuelle et complétez les écrans rendus et l'artefact UI structuré.
8. Exécutez mobile-design-system lorsque des jetons de réutilisation ou d'implémentation en aval sont nécessaires.
9. Exécutez mobile-prototype, puis validez l'alignement des états et des interactions entre l'UI et le prototype.
10. Exécutez mobile-platform-guidelines pour le comportement natif et les cas de test sur appareil.
11. Exécutez mobile-design-review par rapport à la chaîne complète disponible.
12. Exécutez mobile-design-to-code uniquement lorsque l'implémentation ou la remise est demandée et que la décision de revue le permet.

Mettez à jour design-run.json après chaque étape. Préservez les identifiants des exigences, des flux, des écrans, des états, des jetons, des composants et des preuves en amont ; ne régénérez jamais silencieusement des identifiants à une étape aval.

Appliquer les points de contrôle

• Exécutez chaque validateur d'étape nommé par la compétence sélectionnée et corrigez les échecs structurels avant de continuer.
• Exigez un Brief Produit validé avant de prétendre à la complétude UX.
• Exigez une propriété d'état explicite et une récupération avant de prétendre à la complétude UI.
• Exigez visualLock.status: locked et une source de sélection utilisateur ou déléguée par l'utilisateur avant le travail sur le Système de Design ou le prototype rendu.
• Exigez un alignement UI-à-prototype lorsque les deux artefacts existent.
• Empêchez les captures d'écran et les exécuteurs de navigateur de prouver l'accessibilité au runtime, le cycle de vie, les permissions, les capteurs, la persistance, la livraison ou le comportement de l'appareil.
• Empêchez une remise de code de prouver que le code généré se construit ou est testé. Enregistrez les commandes et résultats exacts lorsque du code est généré.
• Exigez l'absence de P0 ou P1 ouverts et l'absence de preuves à haut risque manquantes avant un pass ; sinon, utilisez conditional-pass, revise ou fail comme défini par la compétence de revue.

Exécutez python3 scripts/validate_design_run.py <chemin-vers-design-run.json> --root <répertoire-d-exécution> avant de livrer une exécution multi-étapes.

S'arrêter uniquement pour les décisions matérielles

Faites une pause lorsque :

• L'utilisateur doit choisir parmi les trois directions visuelles.
• Une décision modifie la sécurité, la confidentialité, l'acteur principal, la boucle de valeur principale, le comportement destructeur ou le périmètre MVP.
• Une entrée ou autorisation requise est indisponible.
• L'étape suivante prétendrait à une évaluation externe, une preuve sur appareil physique, un comportement en production, ou une licence publique qui n'a pas réellement été fournie.

Sinon, continuez avec une hypothèse étiquetée et enregistrez-la dans le manifeste.

Livrer l'exécution

Retournez :

1. Le résultat et la décision de l'étape actuelle.
2. Les étapes terminées et les chemins d'artefacts validés.
3. Les décisions utilisateur et les hypothèses étiquetées.
4. Les problèmes P0/P1 ouverts et le comportement à haut risque non testé.
5. La prochaine étape exécutable, ou la porte externe/appareil/utilisateur exacte qui reste.

Ne décrivez pas la chaîne comme terminée lorsqu'une étape requise est en attente, en attente de sélection utilisateur, bloquée, ou structurellement valide mais non testée.