Visual Fix

Que fait Visual Fix ?

Transformez un problème visible d'interface utilisateur en une modification de code localisée, approuvée et vérifiée.

Preuves prises en charge

Acceptez toute combinaison utile de :

• Une capture d'écran de l'interface actuelle
• Une capture d'écran avec une région annotée ou décrite
• Une capture d'écran actuelle et une capture cible avec leurs rôles identifiés
• Une route, un viewport, un nom de composant, une chaîne visible, un sélecteur ou un identifiant de test
• Un symptôme en langage clair tel que "cette carte est coupée" ou "ces contrôles ne sont pas alignés"

Ne demandez que les preuves qui bloquent une localisation fiable. Une route plus une chaîne visible unique peuvent suffire sans capture d'écran. Une capture d'écran avec des composants répétés peut encore nécessiter une route, une étiquette ou un état.

Traitez un problème visuel à la fois. Séparez les symptômes non liés en correctifs distincts.

Workflow

1. Établir la cible

Réexprimez le résultat délimité en termes concrets :

• Ce qui semble incorrect actuellement
• Ce que l'utilisateur s'attend à voir
• Quelle route, composant, état et viewport sont pertinents lorsqu'ils sont connus
• Quel ancrage visible identifie la cible

Si le résultat demandé est subjectif ou pourrait affecter différents éléments, posez la plus petite question qui les distingue.

2. Établir une base de référence en lecture seule

Avant de modifier :

• Trouvez les instructions du dépôt et la source de vérité.
• Inspectez l'état du worktree et préservez les modifications existantes de l'utilisateur.
• Identifiez le framework, l'entrée de route, l'arborescence des composants, le système de style et les commandes d'exécution ou de test disponibles.
• Reproduisez la route et le viewport cibles lorsque l'environnement le permet.
• Capturez ou enregistrez l'état actuel avant de le modifier.

Ne modifiez pas la sortie générée lorsqu'un fichier source maintenu existe. Ne nettoyez pas et n'écrasez pas les modifications non liées du worktree.

Rapportez brièvement la base de référence :

Contexte
- Route/état : /catalog, filtres ouverts
- Viewport : 390 x 844
- Source de vérité : src/routes/catalog.tsx + src/styles/catalog.css
- Modifications utilisateur existantes : aucune
- Reproduction : disponible

3. Localiser la source rendue

Tracez les preuves de l'élément rendu jusqu'au code maintenu. Utilisez la route, le nom accessible, le texte visible, le sélecteur DOM, le nom du composant, l'identifiant de test, la classe, le jeton de style ou la géométrie de la capture d'écran. Lisez references/locating.md lorsque plusieurs fichiers ou couches de style sont impliqués.

Identifiez un emplacement source principal et au maximum deux emplacements connexes requis. Les preuves de fichier et de ligne doivent provenir du worktree actuel.

Localisé
- Principal : src/components/ProductGrid.tsx:42, ProductGrid
- Connexe : src/styles/products.css:18
- Preuve : `.grid` contrôle l'espacement horizontal répété visible entre les cartes
- Confiance : élevée

Si deux éléments similaires restent plausibles, expliquez les preuves distinctives et arrêtez-vous pour clarification.

4. Diagnostiquer à partir des preuves

Connectez le symptôme visible au code réel. Privilégiez une cause prise en charge. Proposez deux ou trois hypothèses uniquement lorsque les preuves restent ambiguës.

Pour chaque hypothèse, incluez :

• La propriété, le sélecteur, le jeton ou le composant impliqué
• Le code ou la preuve rendue qui la soutient
• La direction de correction envisagée
• Une observation qui la réfuterait

N'inventez pas de valeurs CSS à partir de la capture d'écran. Inspectez d'abord la valeur actuelle et le système de conception environnant.

5. Présenter le plan de modification exact

Montrez le correctif proposé avant de modifier :

Plan de modification
- Fichiers : src/components/ProductGrid.tsx:42
- Actuel : gap: 8px
- Proposition : utiliser le jeton space-4 existant (16px)
- Portée : ProductGrid sur /catalog et /search
- Préservation : remplissage des cartes, nombre de colonnes sur mobile, routes non liées
- Vérification : test ciblé, lint, captures d'écran à 390 x 844 et 1280 x 800
- Risque : moyen ; le composant est partagé par deux routes

Attendez l'approbation explicite de ce plan. Choisir un diagnostic n'approuve pas une modification de code. Si le plan s'étend ultérieurement à un autre fichier, dépendance, fichier de verrouillage, artefact généré ou route, présentez le plan révisé et obtenez à nouveau l'approbation.

6. Appliquer le correctif approuvé

Effectuez la plus petite modification qui implémente le plan. Limitez les modifications aux fichiers et à la portée approuvés. Inspectez immédiatement le diff :

• Exécutez git diff --check lorsque le projet utilise Git.
• Confirmez que le diff ne contient que la modification planifiée.
• Préservez les modifications préexistantes et évitez le churn de formatage non lié.
• Ne validez pas, ne poussez pas, n'installez pas de dépendances et ne modifiez pas de services externes, sauf autorisation distincte.

7. Vérifier le résultat

Lisez references/verification.md avant de déclarer le succès.

Utilisez la preuve la plus solide disponible :

1. Exécutez des tests ciblés, le formatage, des vérifications de type ou une construction pertinente pour le code modifié.
2. Rendez la même route, le même état et le même viewport que ceux utilisés pour la base de référence.
3. Comparez visuellement avant et après.
4. Vérifiez un viewport ou une route partagée à proximité lorsque la source modifiée a une portée plus large.

Rapportez exactement un état de vérification :

• Vérifié visuellement lorsque des preuves de rendu avant et après comparables existent
• Vérifié statiquement lorsque les vérifications de code réussissent mais que l'interface n'a pas pu être rendue
• Impossible de vérifier visuellement lorsque l'environnement manque de la route, du navigateur, du fixture ou du chemin de démarrage
• Échec de la vérification avec la commande en échec ou la régression observée

Si la vérification échoue, revenez au diagnostic. N'empilez pas un deuxième correctif non approuvé sur le premier.

Rapport d'achèvement

Gardez la transmission compacte et basée sur des preuves :

Corrigé
- Cible : espacement des cartes du catalogue sur largeur mobile
- Source : src/components/ProductGrid.tsx:42
- Changement : gap utilise désormais space-4
- Vérification : Vérifié visuellement à 390 x 844 ; test unitaire et lint réussis
- Vérifications élargies : /search à 390 x 844 et /catalog à 1280 x 800

Mentionnez toute incertitude visuelle restante. Ne décrivez jamais un diff de code comme une preuve visuelle.