yagyaraj234/skills

Préparation frontend

Invoquer comme $frontend-readiness diff, $frontend-readiness pr <URL>, $frontend-readiness release ou $frontend-readiness full.

Utiliser les règles de mode, de preuve, de verdict et d'édition dans check-readiness. En cas d'invocation directe, sélectionner un mode là-bas. Lorsqu'elle est invoquée par check-readiness, conserver sa cible sélectionnée. Évaluer uniquement les surfaces frontend.

Évaluer les vérifications qui s'appliquent à la cible choisie. Marquer une exception dans le périmètre N/A avec une raison. Une section qui ne s'applique pas (application non publique pour Recherche et partage, pas de framework pour Conventions du framework) donne une seule ligne N/A, pas une par vérification.

Zones bloquantes : flux ou route critique cassé, UI d'authentification et de permissions, rendu non sécurisé de contenu utilisateur, fuite de secrets, échecs d'accessibilité sur les flux critiques, états d'erreur ou vides manquants sur les surfaces pilotées par les données, échec de build ou de tests. Les autres échecs sont consultatifs.

Exactitude

• Chaque route dans le périmètre s'affiche via navigation directe, rafraîchissement, navigation dans l'application, retour et avant.
• Chaque flux critique termine son parcours heureux et conserve les entrées utiles en cas d'échec récupérable.
• Les formulaires valident les entrées, empêchent les soumissions en double, affichent des erreurs exploitables et exposent les erreurs aux technologies d'assistance.
• L'état client, serveur, URL et persistant reste cohérent lors du rafraîchissement, de l'annulation, des réponses périmées et des actions répétées.
• La console ne contient aucune nouvelle erreur ou avertissement ; les requêtes réseau échouées sont expliquées.
• Les limites d'authentification et de permissions affichent une UI correcte, préservent les routes de retour prévues et gèrent les sessions expirées, les réponses interdites et les changements de rôles.

Chaque surface pilotée par les données a une matrice d'états explicite. Marquer un état N/A uniquement lorsqu'il ne peut pas se produire ou n'offre aucune valeur utilisateur.

• Vide : un résultat réussi sans données explique ce qui s'est passé et propose une action utile.
• Chargement : la progression est claire, le contenu utile existant reste stable et les actions répétées restent contrôlées.
• Squelette : lorsque la disposition finale est prévisible et que le délai est perceptible, les placeholders correspondent et évitent le décalage de mise en page ; sinon, noter N/A.
• Partiel : le contenu disponible reste utilisable pendant que les sections indépendantes chargent ou échouent.
• Erreur : le message est exploitable, les entrées utiles sont conservées et la nouvelle tentative ou la récupération fonctionne.

Conventions du framework

Ignorer les éléments pour les frameworks que le projet n'utilise pas ; nommer le framework détecté et sa version.

• Les API du framework, du routeur et de chargement de données correspondent à la version installée et aux conventions existantes du projet ; enregistrer la version et la source de vérité.
• La navigation interne utilise le composant de lien du framework détecté, comme Link de next/link ou @tanstack/react-router ; le <a> natif gère les liens externes, de téléchargement, d'email et de téléphone.
• Les paramètres de route, les paramètres de recherche, les redirections et la navigation utilisent les API et hooks du routeur du framework.
• Les styles statiques et dynamiques suivent le système de style existant pris en charge par le framework ; les valeurs dynamiques utilisent des propriétés personnalisées CSS sauf si le positionnement requis par la bibliothèque nécessite des styles en ligne.

Interface et accessibilité

• La disposition fonctionne à chaque fenêtre enregistrée sans débordement involontaire. Le texte long, les médias manquants, les données lentes et les grandes collections restent utilisables.
• La hiérarchie, l'espacement, la typographie, les couleurs et le retour interactif sont cohérents ; les contrôles couvrent les états de survol, focus, actif, désactivé, chargement et erreur.
• Les actions destructrices nécessitent une intention claire et offrent une récupération lorsque c'est pratique.
• Les points de repère sémantiques, les titres, les contrôles, les étiquettes et les noms accessibles correspondent à l'objectif.
• L'utilisation exclusive du clavier atteint et opère chaque élément interactif dans un ordre logique ; le focus reste visible et se déplace correctement à travers les boîtes de dialogue, les menus, les erreurs et les changements de route.
• Le texte et l'UI essentielle respectent la cible d'accessibilité enregistrée (WCAG 2.2 AA sauf si une exigence plus stricte s'applique) ; la signification ne dépend pas uniquement de la couleur.
• Les images ont des alternatives appropriées ; les médias décoratifs restent silencieux. Le zoom, le redimensionnement du texte, la réduction de mouvement et les annonces vocales requises préservent le flux.

Résilience, confidentialité et sécurité

• Le contenu contrôlé par l'utilisateur est rendu de manière sécurisée ; les secrets et les décisions privilégiées restent côté serveur.
• Les liens externes, les redirections, les téléchargements, le stockage et les API du navigateur valident les entrées non fiables. Les onglets externes utilisent un comportement d'opener sécurisé lorsque applicable.
• Le comportement hors ligne et de timeout évite la perte de données.
• L'UI d'erreur omet les informations sensibles internes tandis que les journaux conservent suffisamment de contexte de diagnostic.
• Les produits d'authentification ou de données personnelles exposent les pages publiques de Conditions d'utilisation et de Confidentialité à partir de l'authentification et de la navigation persistante ; le contenu correspond au comportement réel.
• Les cookies, les défenses CSRF, les en-têtes de sécurité des réponses, les redirections et la politique de cache sont vérifiés lorsque l'application les contrôle.
• L'analyse, le suivi des erreurs et le consentement respectent les exigences de confidentialité et n'exposent pas de données personnelles ou secrètes.
• Les indicateurs de fonctionnalité ont une valeur d'environnement cible vérifiée et, pour les changements risqués, un chemin de rollback ou de désactivation documenté.

Performances et assets

• Les routes représentatives sont mesurées à partir d'une build de production dans l'environnement enregistré en utilisant TTFB, LCP, INP, CLS, premier contenu utile et timing de l'interaction principale.
• Chaque route dans le périmètre affiche un contenu utile ou un fallback exploitable et accepte son interaction principale dans le budget enregistré ; cinq secondes est la valeur par défaut uniquement lorsqu'aucun budget produit plus strict n'existe.
• La sortie de la build de production, les chunks de route et la cascade réseau ne contiennent aucun coût important inexpliqué.
• Les optimisations de performances modifiées ont un bénéfice mesuré et préservent le comportement du clavier, du focus, du lecteur d'écran et hors ligne lorsque applicable.
• Les effets libèrent les écouteurs, abonnements, observateurs, requêtes en attente, workers, timers, images d'animation et travaux debounced/throttled lorsque les dépendances changent ou que les composants se démontent.
• Les images utilisent l'optimisation du framework disponible, des dimensions réactives et sizes, des formats modernes, la compression, des rapports d'aspect stables et une priorité eager/lazy correcte. Les vidéos et polices ont un comportement de livraison, de fallback et de préchargement délibéré.
• Les scripts tiers, en ligne et bloquants ont un objectif explicite et une priorité de chargement.

Recherche et partage

S'applique uniquement aux routes publiques ou partageables ; les applications nécessitant une authentification n'ont besoin que de la vérification de non-indexation.

• Chaque route définit des métadonnées de titre et de description appropriées. Les routes publiques indexables définissent des intentions canoniques et robots via les API du framework ; les environnements non productifs et protégés ne sont pas accidentellement indexés.
• Les routes partageables résolvent les métadonnées Open Graph et sociales en valeurs absolues et crawlables. Les images OG renvoient le bon type de contenu, dimensions et texte alternatif ; les balises rendues et un aperçu réel du partage sont vérifiés.
• Pour un point de contrôle de release, Lighthouse s'exécute contre les routes de production déployées sur les profils mobile et desktop enregistrés ; les résultats et régressions de Performance, Accessibilité, Meilleures pratiques et SEO sont enregistrés.

Ingénierie et déploiement

• Le formateur, le linter, la vérification de type, les tests et la build de production passent ou ont un échec de base explicite.
• La logique modifiée a la plus petite vérification automatisée de régression utile.
• Les variables d'environnement, les indicateurs de fonctionnalité, les URL d'API, la prise en charge du navigateur et les comptes de test correspondent à l'environnement cible.
• Le suivi des erreurs, les favicons et les icônes d'installation fonctionnent là où le produit les exige.
• Pour un point de contrôle de release ou un changement affectant le déploiement, les assets déployés, les routes, les API, l'authentification, les en-têtes, les redirections et le comportement du cache sont vérifiés dans l'environnement cible.