ui-lab

Laboratoire UI : suggestions UX

Une suggestion UX traverse trois phases :

1. Maquette — seuls les fichiers du laboratoire changent, sur la plateforme indiquée par les notes du projet. Le propriétaire parcourt les options en tapotant.
2. Clôture de l'itération — l'itération est étiquetée et documentée dans docs/ux-history/, et ses fichiers de laboratoire sont supprimés.
3. Promotion — après que le propriétaire a choisi une option et approuvé un plan, elle devient l'écran réel, avec sa logique partagée et l'autre plateforme si l'application en a une.

Notes de laboratoire du projet

Ce skill est le processus ; les spécificités de chaque projet se trouvent dans son .claude/ui-lab.md. Lisez-le avant tout. Il fournit :

• Plateforme : quelle application de laboratoire utiliser sur cette machine (uname -s), son identifiant, où placer le code du laboratoire et la commande qui ouvre un écran ;
• Dossiers d'options : le dossier et le package par plateforme, et où vont les chaînes de caractères ;
• Fichiers : le thème ou les couleurs utilisés par l'écran d'une option, et où son état se déplace lors de la promotion ;
• Données d'exemple : à partir de quoi les options construisent leurs données ;
• Simulations et cas limites : quelles données inventées ne peuvent pas être affichées dans cette application, et les cas à vérifier ;
• Captures d'écran : comment en prendre une par plateforme ;
• Promotion : chemins cibles, gestion de l'autre plateforme, documentation à mettre à jour et commandes de build release ;
• comment le laboratoire lui-même fonctionne (un lien vers un document).

Les notes priment là où elles diffèrent de ce skill. Si le projet n'a pas de .claude/ui-lab.md, ou s'il manque quelque chose mentionné ci-dessous, demandez au propriétaire plutôt que de deviner, et ajoutez la réponse aux notes.

Phase 1 : maquette

Travaillez sur une branche ux/<screen> à partir de la branche actuelle, afin qu'une autre machine puisse récupérer l'itération. Si l'arbre a des modifications non commitées qui ne sont pas les vôtres, demandez avant de changer de branche.

Un dossier par option

Chaque option vit dans son propre dossier (les notes indiquent où), afin de pouvoir être supprimée, ravivée ou promue seule. Il se trouve dans le package des écrans, donc le promouvoir revient à déplacer un fichier.

Fichier	Contient	Lors de la promotion
<Screen>Option<B>	l'écran, <Screen>Screen<B>(state, actions) : qualité production (les chaînes et le thème de l'application, selon les notes) et sans types de laboratoire	se déplace dans l'application
<Screen>Option<B>State	l'état que la logique de l'application ne produit pas encore, façonné comme elle le produirait	se déplace là où les notes l'indiquent
<Screen>Option<B>Lab	ses données d'exemple, son comportement simulé, ses actions vides, et sa valeur LabOption avec ce qu'elle simule au-dessus	supprimé
les chaînes de l'option, lorsque l'application utilise des ressources de chaînes (noms et emplacement selon les notes)	le nouveau texte de l'option	se déplace vers les chaînes de l'application

• En plus du dossier (et des fichiers de chaînes lorsque les ressources ne peuvent pas s'y trouver), une option ajoute une ligne : son entrée dans la liste de son écran dans LabScreens (<screen>OptionB,).
• Tout dans le dossier est private sauf l'écran, son état et la valeur LabOption, dont les noms portent l'option, afin que les options n'entrent jamais en conflit.
• Une option qui nécessite une version modifiée d'un composant existant de l'application utilise sa propre copie, dans son dossier.
• Les données d'exemple proviennent des sources que les notes nomment, telles qu'elles sont, plus ce que l'option ajoute dans son fichier Lab. N'inventez pas de texte là où les notes disent que les données sont réelles.

Étapes

1. Ouvrez l'écran dans le laboratoire et regardez current, l'écran tel que l'application l'a actuellement.
2. Écrivez 2–3 directions distinctes comme options a, b, c après current, chacune avec une note d'une ligne sur ce qu'elle change.
3. Au-dessus de chaque valeur LabOption, listez ce que l'option simule : les données que la logique de l'application n'a pas, le comportement qui n'est pas construit, et ce que les données inventées ne peuvent pas montrer (les notes listent ceux habituels de cette application).
4. Vérifiez les cas limites listés dans les notes, plus tout ce qui est inhabituel pour l'écran. Un cas qui change le design devient sa propre option (a-rtl, a-dark).
5. Buildez, ouvrez chaque option et regardez une capture d'écran (commandes dans les notes ; le skill android-emulator couvre les appareils Android). Une capture d'écran entièrement noire provenant d'un téléphone signifie qu'il est verrouillé : demandez au propriétaire de le déverrouiller.
6. Commitez sur la branche et dites au propriétaire les identifiants des options (<screen> <option>), ce que chacune simule, et l'appareil.

Lorsque le propriétaire demande de modifier une option, la modification devient une nouvelle option dans son propre dossier (b2 à côté de b). Les options que le propriétaire écarte restent jusqu'à la clôture de l'itération, afin que l'étiquette de l'itération les contienne toutes.

Phase 2 : clôture de l'itération

Lorsque le propriétaire a choisi une option ou les a toutes refusées :

1. Étiquetez le dernier commit de l'itération, alors que chaque option y est encore, et poussez l'étiquette : git tag ux/<screen>/<yyyy-mm-dd> && git push origin ux/<screen>/<yyyy-mm-dd>. L'étiquette garde le code accessible après la suppression de la branche ; une deuxième itération le même jour reçoit -2.
2. Écrivez docs/ux-history/<screen>/<yyyy-mm-dd>-<topic>.md dans le format ci-dessous, et liez-le depuis l'endroit indiqué par les notes (le document d'un écran, par exemple).
3. Supprimez les dossiers des autres options, les fichiers de chaînes et les lignes LabScreens ; l'option choisie reste jusqu'à la phase 3.
4. Commitez. Si toutes les options sont refusées, l'itération se termine ici : fusionnez la branche (le fichier d'historique est son seul changement durable) ou supprimez-la, comme le propriétaire préfère.

# <Screen> — <topic> (<yyyy-mm-dd>, <platform>)

Étiquette : `ux/<screen>/<yyyy-mm-dd>`

## Options
- **a — <name>** : <ce qu'elle change>. *Choisie*, promue dans <commit>.
- **b — <name>** : <ce qu'elle change>. *Refusée* : <la raison du propriétaire, si donnée>.

## Ce qu'elles simulaient
- b : <ce que la maquette montrait que l'application ne peut pas encore faire>.

## Raviver une option
    git checkout ux/<screen>/<yyyy-mm-dd> -- <dossier de l'option> <fichiers de chaînes>
Puis ajoutez `<screen>Option<B>,` à `LabScreens`.
Construit avec <composants et données d'exemple utilisés> à la date de l'étiquette. Les erreurs de compilation après le ravivement se trouvent dans les copies de l'option et les données d'exemple ; corrigez-les là.

Raviver

Lorsque le propriétaire demande une option antérieure, suivez son fichier d'historique : extrayez les chemins depuis l'étiquette sur une branche ux/<screen>, ajoutez la ligne LabScreens, corrigez ce qui ne compile plus dans le dossier de l'option, et ouvrez-la. Elle devient alors une option active d'une nouvelle itération.

Phase 3 : promotion

Avec l'itération clôturée sur une option choisie, entrez en mode plan (EnterPlanMode) et présentez le plan avec ExitPlanMode ; le propriétaire l'approuve avec son bouton. Le plan couvre :

• les fichiers qui se déplacent et l'écran qu'ils remplacent ;
• le travail de logique derrière chaque élément simulé : les modifications proposées de l'état, du modèle de vue ou du contrôleur, et leurs tests ;
• l'autre plateforme, lorsque l'application en a une, comme le disent les notes ;
• les documents que les notes disent de mettre à jour.

Après approbation, sur la même branche :

1. git mv le fichier d'écran de l'option dans l'application (cible selon les notes), en remplaçant l'ancien écran, et donnez à la fonction ou à la vue le nom de l'écran.
2. Déplacez ses chaînes dans celles de l'application, sans le préfixe ou la table de l'option.
3. Déplacez son état là où les notes l'indiquent, faites en sorte que la logique de l'application le produise avec des tests, et connectez les actions.
4. Repliez ses composants copiés dans les originaux, et supprimez le reste de son dossier et sa ligne LabScreens ; pointez current de l'écran dans LabScreens vers l'écran promu.
5. Buildez en release avec les commandes des notes, où toute référence au code de laboratoire échoue à la compilation.
6. Effectuez les parties du plan concernant l'autre plateforme et les documents, et placez le commit de promotion dans le fichier d'historique de l'itération.

La fusion de la branche est à la discrétion du propriétaire.