Oil Frontend

Que fait Oil Frontend ?

Identifier d'abord la tâche utilisateur, l'objet métier et la source des données, puis supprimer le contenu inutile, et établir les informations, les états, l'attribution du code et l'implémentation partagée corrects.

Toujours respecter

• Partir de la tâche utilisateur réelle, de l'objet métier et du résultat final ; ne conserver que les informations visibles qui aident à identifier, comparer, juger, manipuler ou comprendre le résultat.
• Une intention utilisateur ne s'exécute qu'une seule fois, l'action doit produire un résultat réel ; les limites des données, des actions, de l'occupation et de la soumission restent cohérentes ; en cas d'échec, conserver l'objet, la position et le contenu saisi actuels.
• Pour les tâches courantes, utiliser les connaissances existantes de l'utilisateur ; les ressources sont affichées par défaut, l'édition doit être déclenchée explicitement, les formulaires ne collectent que les données nécessaires à la tâche en cours et appartenant à l'objet courant.
• Les icônes, les façons de mettre en évidence et les tailles fixes doivent exprimer une signification stable ; ne pas utiliser de décoration générique d'IA, de bords de mise en évidence sans signification, ou de tailles adaptées uniquement à l'instance actuelle pour créer des niveaux.
• Pour les ajustements visuels, commencer par utiliser les variables de design, les composants et la densité existants du projet, puis traiter les niveaux, les espacements, la typographie, les surfaces et les retours ; utiliser les valeurs de repli des règles de référence uniquement en l'absence de standard de projet, et ne pas étendre une valeur de repli en un nouveau système de design.
• Pour une même donnée métier et une même signification, ne conserver qu'une seule source d'autorité ; privilégier la correction du flux de données, de la mise en page parente et de l'implémentation partagée, et ne pas appliquer de rustines récurrentes à différentes positions d'une page.
• Organiser les composants, Hooks, fonctions, types, styles et tests par appartenance métier ; placer le code d'un module à proximité, et ne le mettre dans la couche partagée que s'il est stablement réutilisé entre modules.
• Face à une logique complexe, vérifier d'abord les capacités existantes du projet et les bibliothèques matures ; si la dépendance existante n'est pas appropriée, introduire une nouvelle bibliothèque bien maintenue et compatible avec le projet, sans réimplémenter à la main une capacité déjà couverte par une solution mature. Pour une logique simple, l'implémenter directement, sans introduire de nouvelle dépendance pour quelques lignes de code.
• L'historique du projet n'est pas une preuve de correction ; un modèle erroné doit être remplacé, et après la migration des emplacements concernés, supprimer le code ancien, les fallback, la logique legacy et les états invalides.

Ordre de lecture des fichiers de référence

1. Après le déclenchement, ne lire d'abord que ce fichier, clarifier la tâche, l'objet et le périmètre de modification, sans lire les fichiers de référence à l'avance.
2. Si la tâche n'implique pas d'interface visible pour l'utilisateur, d'état et de flux de données frontend, d'implémentation de composant ou d'organisation du code frontend, arrêter d'utiliser cette compétence.
3. Choisir d'abord une règle principale en fonction du résultat que l'utilisateur souhaite modifier, et non en fonction du type de fichier ou des mots-clés CSS ou d'animation apparaissant dans le code.
4. Pour une modification simple et locale, ne lire qu'une seule règle principale ; n'en ajouter une supplémentaire que si la tâche implique simultanément un deuxième problème indépendant. Seule une revue multi-pages peut en lire trois au maximum, pas plus.
5. Ne pas continuer à lire des règles en raison de l'apparition de mots-clés, de liens dans le fichier ou "pour être sûr". Lorsqu'un symptôme visuel est causé par des données, un état ou une mise en page parente, lire la règle responsable de la cause racine réelle, sans charger de règle visuelle supplémentaire.

Tâche actuelle	Règle principale	Compléter uniquement dans ces cas
"Ça ne semble pas correct", retouche visuelle, hiérarchie, espacement, typographie, couleur, arrondi, bordure, ombre ou icône	Ingénierie visuelle	Si une modification de token partagé, de style par défaut ou de variante de composant est nécessaire, lire Composant et organisation du code ; si la structure de colonnes, de défilement ou responsive change, lire plutôt Viewport et boîte de dialogue comme règle principale
Animation, transition, micro-interaction, déroulement/repli, retour de glisser-déposer, effet de défilement ou ralentissement	Mouvement et performance	Si le mouvement assume un retour d'action ou un niveau visuel, lire Ingénierie visuelle ; si la cause racine est un état asynchrone, lire plutôt État et chargement comme règle principale
Limite de module, composant, Hook, fonction, type, appartenance de style, style partagé, organisation CSS ou implémentation partagée	Composant et organisation du code	Si une nouvelle vérification est nécessaire, lire Automatisation
Ajout ou modification de texte, signification de l'action, icône, retour de clic ou accentuation visuelle	Information et action	Si l'identité d'un objet, une image ou un sélecteur est impliqué, lire Reconnaissance de ressource

Les données, l'état et la mise en page continuent d'être choisis en fonction du résultat :

Tâche actuelle	Règle principale	Compléter uniquement dans ces cas
Liste, carte, détail, tableau ou opération par lots	Ensemble et détail	Si l'identité d'une ressource est impliquée, lire Reconnaissance de ressource ; si l'édition est impliquée, lire Interaction et édition
Formulaire, sélection, édition ou workflow en plusieurs étapes	Interaction et édition	Si la portée de la sauvegarde et la continuité du processus sont impliquées, lire Portée des données et des opérations
Résultat de requête, pagination, ensemble candidat, portée de sauvegarde, portée par lots ou appartenance du résultat de la requête	Portée des données et des opérations	Si l'affichage de loading, refreshing, empty, error ou processing change simultanément, lire État et chargement
loading, refreshing, empty, filtered-empty, error, queued, processing ou squelette	État et chargement	Si un snapshot de requête, une portée d'opération ou l'appartenance du résultat de sauvegarde sont impliqués, lire Portée des données et des opérations
Modification de la taille de page, des colonnes, du défilement, de la structure de la boîte de dialogue ou du comportement responsive	Viewport et boîte de dialogue	Si une superposition dépendant d'un déclencheur (menu déroulant, menu contextuel, infobulle) est impliquée, lire Calque

Ne pas déclencher de lecture supplémentaire dans les cas suivants :

• La présence de Tailwind, CSS, transition ou d'une bibliothèque d'animation dans le code ne signifie pas que la tâche est visuelle ou d'animation.
• Lors de la modification d'attributs visibles (couleurs, espacements, bordures, ombres, typographie, etc.), la règle principale est l'ingénierie visuelle ; ce n'est que lorsque la tâche exige également d'ajuster l'appartenance des styles, la manière de partager ou la limite du module qu'il faut compléter avec la règle d'organisation des composants et du code.
• Si l'on se contente de corriger un nom de variable de couleur, un nom de classe, un type ou une erreur d'importation, et que le résultat visuel ne change pas, ne pas lire la règle d'ingénierie visuelle.
• Si l'on modifie uniquement l'état métier, la liaison d'événement ou la source de données d'une animation existante, sans changer la manière de mouvement ou la performance, ne pas lire la règle d'animation.
• Si l'on déplace seulement un contrôle existant, sans changer le texte, la signification de l'action ou le retour, ne pas lire la règle d'information et d'action.
• Si l'on ajuste uniquement l'appartenance d'un conteneur parent enfant, sans changer la taille, le défilement, la boîte de dialogue ou le comportement responsive, ne pas lire la règle de viewport et de boîte de dialogue.
• Les liens dans les fichiers de référence indiquent seulement l'emplacement des règles concernées, et non l'obligation de continuer à les lire.

Lexique rapide

Les termes clés de ce fichier et des règles de référence sont compris selon les définitions suivantes :

• Identité de ressource : La combinaison minimale d'information permettant à l'utilisateur de reconnaître "quel objet est-ce" — image + nom + un champ de distinction. Exemple : une liste de membres affiche "avatar + nom + département", et non "uuid + étiquette de type".
• Pseudo-action : Un contrôle qui semble utilisable mais ne produit pas de résultat réel. Exemple : cliquer sur "Enregistrer" ne modifie qu'un état local, perdu après rafraîchissement ; un bouton "Supprimer" désactivé en permanence qui prend de la place.
• Rustine visuelle d'un seul composant : Au niveau de la page, pour un composant partagé, lui ajouter uniquement un style. Exemple : <Dialog className="h-[640px]">, remplacement avec !important, sélecteur spécifique à la page modifiant l'intérieur du composant. La bonne approche est de modifier le composant partagé lui-même, ou d'ajouter une variante de composant nommée selon son usage.
• Variante de composant nommée selon son usage (variant) : Nommer avec "pourquoi est-ce différent". Exemple : variant="destructive", size="compact" sont corrects ; variant="blue", variant="userListPage" sont incorrects.
• Action principale : L'opération qui accomplit la tâche principale dans la page, la boîte de dialogue ou la zone d'opération actuelle. Au maximum un bouton de forte accentuation par zone.
• Limite de soumission : Quand une modification prend-elle réellement effet — immédiatement, sauvegarde automatique, soumission unique explicite, ou simple prévisualisation temporaire.
• Portée d'occupation : La zone minimale où il faut empêcher les actions en double pendant qu'une requête est en cours. Une requête individuelle ne verrouille que cet élément, pas toute la page avec un masque.
• Snapshot de requête soumis : Les conditions de requête, la liste, le nombre total de résultats et les informations de pagination déterminés conjointement par une même réponse. Tant qu'une nouvelle requête n'est pas terminée, l'ancien snapshot appartient encore aux anciennes conditions.
• Tâche par lots de même type : Une tâche consistant à répéter les mêmes champs pour un groupe d'objets du même type, comme la planification par lots ou la modification de prix par lots.
• Feuille de travail éditable : Un tableau permettant à plusieurs lignes d'être en mode édition en continu pour des tâches par lots de même type. À opposer à une liste de ressources : affichée par défaut, l'édition doit être déclenchée explicitement.

Ordre de décision

Répondre successivement avant toute modification.

Tâche et objet :

1. Quelle tâche l'utilisateur souhaite-t-il accomplir actuellement, et quel résultat marque l'achèvement ?
2. Quel objet central la page gère-t-elle, et à qui appartiennent respectivement les champs ?
3. S'agit-il actuellement de navigation, de comparaison, de sélection ou d'édition, et utilise-t-on des structures et termes familiers à l'utilisateur ?

Données et portée :

4. Les données proviennent-elles d'un ensemble complet, d'un ensemble visible actuel ou d'un résultat de recherche ?
5. Quelles sont les portées affectées respectivement par l'opération, l'état d'occupation et la limite de soumission ; les conditions de requête distante et la liste actuelle appartiennent-elles déjà à un même résultat soumis ?
6. Sur quelles informations l'utilisateur se base-t-il pour distinguer des objets adjacents ?
7. Peut-on supprimer du texte, des étapes, des confirmations, des saisies répétées ou des champs déjà connus du système ?
8. Quelles informations appartiennent à l'ensemble, et lesquelles uniquement au détail ?

Structure et état :

9. Quelle est l'action principale de la page, de la boîte de dialogue ou de la zone d'opération actuelle ?
10. Qui est responsable respectivement du premier écran, du conteneur de défilement et de la limite du calque superposé ?
11. Comment s'excluent mutuellement loading, empty, filtered-empty, queued, processing, error, ready ?

Visuel et animation, à répondre uniquement si la tâche le demande :

12. Quels sont les Tokens, composants et pages adjacents du projet actuel qui définissent la hiérarchie, la densité et le langage d'animation ? Quel attribut visible est réellement incohérent ?
13. L'animation sert-elle à retourner un état, à expliquer une relation spatiale ou à décorer ; peut-on utiliser uniquement transform, opacity ou les capacités existantes des composants ?

Point d'atterrissage :

14. Existe-t-il déjà un module, un composant, un Hook, une fonction, un type, une variable de design unifiée ou un style avec la bonne appartenance, et quelle source de données, mise en page parente ou implémentation partagée faut-il finalement modifier ?

Lorsqu'il est impossible de répondre clairement, arrêter d'abord d'ajouter des éléments d'interface : poser à l'utilisateur les 1–2 questions les plus cruciales ; s'il est impossible de poser une question, mettre en œuvre sur la plus petite portée vérifiable, et déclarer les hypothèses faites dans la sortie.

Processus d'exécution

1. Rétablir les faits

• Rechercher les modules, composants, Hooks, fonctions, types, variables de design unifiées et styles existants du projet, et vérifier si une même signification a déjà une implémentation correcte.
• Trouver toutes les pages et composants utilisant des composants partagés, ainsi que les autres entrées pour les mêmes données.
• La revue ne fournit que des preuves et des suggestions ; ne mettre en œuvre que si l'utilisateur demande une modification.

2. Définir la portée

• Définir l'objet central, le propriétaire des champs, l'ensemble de données, la portée de l'opération, la portée d'occupation et la limite de soumission.
• Distinguer les problèmes de structure de page, le comportement par défaut des composants, les erreurs d'utilisation de page et les erreurs de flux de données.
• Pour un problème visuel, enregistrer uniquement les différences qui peuvent indiquer un élément, un attribut, une base existante et un point d'atterrissage de code ; lorsqu'une valeur correcte ne peut être déterminée, utiliser d'abord les Tokens existants du projet ou un composant similaire adjacent, sans inventer de valeurs précises par goût esthétique.

3. Supprimer d'abord

• Supprimer les contenus qui n'influencent pas le jugement, les états redondants, les entrées redondantes, les confirmations redondantes et les rustines visuelles ciblant un seul composant.
• Supprimer les pseudo-actions qui n'ont pas de changement d'état réel ou qui ne peuvent pas vraiment enregistrer de données.
• Supprimer les anciens composants, anciennes fonctions, anciens types, anciens états, fallback, logique legacy, anciens styles et références invalides qui ont été remplacés par une nouvelle implémentation.

4. Choisir la structure

• Vérifier d'abord les usages établis dans le projet pour des tâches similaires et les composants conteneurs partagés ; ne conserver un modèle existant que s'il est conforme à cette norme, sinon rechoisir une structure en fonction de la tâche réelle.
• En fonction de la tâche (navigation, comparaison, sélection, configuration par lots ou édition approfondie), choisir une liste, un tableau, une feuille de travail, un sélecteur, une boîte de dialogue ou un espace de travail complet.
• Laisser les listes gérer l'identification et la comparaison, les détails le contenu complet, et les éditeurs la modification.
• Traiter les ajustements visuels dans l'ordre suivant : "hiérarchie de l'information → espacement et alignement → typographie → surface → état des contrôles → animation" ; arrêter dès que la couche précédente résout le problème, sans continuer à superposer des décorations.

5. Corriger l'erreur réelle

• Privilégier la correction de la portée des données, de la portée des opérations, de la mise en page parente, du comportement par défaut des composants partagés et des variantes de composants à signification stable.
• Utiliser des composants partagés pour les identités de ressource récurrentes, les menus, les calques, le chargement, les boîtes de dialogue et les barres d'opérations.
• N'abstraire que lorsque les responsabilités, les entrées/sorties et le comportement sont stables et répétés ; ne pas copier de composants pour une similarité partielle de structure, et ne pas créer de composant universel avec de nombreux interrupteurs de page.
• Si un composant partagé, une fonction, un style ou un flux de données existant est lui-même erroné, le corriger ou le remplacer directement dans le périmètre autorisé, et traiter tous les emplacements d'utilisation affectés ; ne pas continuer à ajouter des implémentations erronées pour compatibilité avec l'historique.
• S'il est impossible de tout modifier dans le périmètre actuel, arrêter d'étendre l'ancien modèle, signaler clairement les anciens emplacements d'utilisation restants et jusqu'où la modification actuelle a été effectuée, sans prétendre à une unification.
• Lors de la correction d'un problème détectable de manière répétée, juger si le projet a vraiment besoin d'ajouter une nouvelle règle de lint, de test ou de vérification ; si nécessaire, lire complémentairement Automatisation en fonction de la table de routage, et le compter dans le nombre de règles complémentaires. Pour une petite modification, ne pas mettre en place d'automatisation préalable pour cela.
• Ne pas modifier les zones non concernées.

6. Valider

• Exécuter les vérifications de type, Lint, tests ou builds existants du projet et liés à la modification.
• Pour une modification simple et locale, ne vérifier que l'emplacement modifié, le comportement direct et les emplacements d'utilisation les plus récents, sans déployer une matrice d'état complète.
• Lorsque la modification implique des composants partagés, la portée des données, un état asynchrone, un flux de formulaire, le défilement, une réponse responsive ou plusieurs pages, vérifier en plus les états affectés, la portée des données, les viewports représentatifs et tous les emplacements d'utilisation.
• Pour une modification visuelle, vérifier le contenu réel, les états principaux et les viewports affectés ; pour une modification d'animation, vérifier uniquement par type les interruptions, déclenchements répétés, sorties, démontages ou comportements de défilement applicables. N'utiliser un enregistrement de performance que pour une animation complexe ou un ralentissement réel, sans transformer chaque transition en projet particulier de performance.
• Ne signaler que les éléments vérifiés, non vérifiés et la cause du blocage.

Auto-vérification indépendante

Déclencher une auto-vérification indépendante sans contexte historique uniquement lorsque la revue frontend implique plusieurs pages, tous les emplacements d'utilisation de composants partagés, plusieurs viewports ou états, ou des ajustements de règles à grande échelle. Pour une page unique, un composant unique, une capture d'écran unique et une différence locale, l'agent principal vérifie directement.

L'auto-vérification indépendante ne reçoit que l'objet de vérification, la portée et oil-frontend ; elle ne reçoit ni historique de conversation, ni conclusions existantes, ni suppositions de problème, ni réponses attendues, ni solutions de correction.

Exigences de sortie

Donner d'abord la conclusion, puis les preuves. Ne sortir que :

1. Le problème spécifique ;
2. Le contenu à supprimer ;
3. La structure correcte de l'information, de l'action et de l'espace ;
4. Les modules, composants partagés ou flux de données à modifier ;
5. Les éléments vérifiés et non vérifiés.

Interdiction d'utiliser des descriptions comme "améliorer l'expérience", "plus moderne", "plus intuitif" qui ne guident pas l'implémentation.

Ne pas étendre activement en un audit d'accessibilité spécialisé. Continuer à utiliser des éléments d'interaction natifs lors de l'implémentation de l'interface, sans casser le focus, le clavier, les étiquettes et le comportement ARIA existants du projet ; ne déclencher une vérification que si l'utilisateur le demande explicitement ou si la modification actuelle rend une tâche impossible à accomplir.