belloni123/b16-immersive-frontend

B16 Immersive Frontend

Créez une expérience mémorable autour d'une seule idée visuelle défendable. Cette compétence complète un flux de travail de projet plus large ; elle ne remplace pas les compétences de gouvernance, de planification, de construction, de vérification ou de révision et ne prétend pas reproduire B16 Dev OS.

Établir le brief

Digérez tout le contexte disponible avant de poser des questions. Inférez des faits uniquement lorsque les preuves les soutiennent, citez la source ou étiquetez l'inférence, et ne demandez que les lacunes qui peuvent matériellement changer la direction. Utilisez briefing.md lorsque la direction n'est pas déjà approuvée.

Avant l'implémentation, présentez une direction concise couvrant la thèse visuelle, la hiérarchie du contenu, le point focal du héros, la typographie, la palette, le rythme de la mise en page, le récit de mouvement, la stack probable, le budget de performance, les solutions de repli, la provenance des actifs et les exclusions. Obtenez l'approbation pour cette direction. Ne traitez pas l'approbation d'un concept comme une autorisation pour le déploiement, les achats, les comptes, les jetons ou les modifications système non liées.

Concevoir avec intention

• Commencez par le mobile, puis développez la composition et la chorégraphie pour les fenêtres d'affichage plus grandes.
• Ancrez l'identité dans le sujet, le public, les matériaux, la langue et le contenu réel. Évitez un look de kit de composants générique.
• Dépensez l'audace visuelle dans un seul endroit mémorable et gardez le système de support discipliné.
• Rédigez une copie humaine et techniquement précise à la voix active. Utilisez la casse des phrases et pas de ponctuation par tiret cadratin. N'inventez jamais de preuves, partenaires, témoignages, métriques ou capacités.
• Utilisez une famille d'icônes cohérente par projet, choisie pour l'adéquation à la stack, l'identité, la couverture, la licence, le coût, la maintenance, l'accessibilité et le poids. Utilisez les marques officielles ou autorisées. Importez des icônes individuelles avec un véritable tree shaking là où la stack le supporte.
• Rendez chaque action primaire opérable sans survol. Spécifiez les états tactile, clavier, focus, actif, chargement, désactivé, erreur et vide là où c'est pertinent.

Choisir la stack la plus petite et suffisante

Lisez stack-selection.md lorsque le mouvement, le canvas 2D ou la 3D sont envisagés. Préservez la stack actuelle à moins qu'un changement ne soit justifié et approuvé.

N'ajoutez pas React à WordPress pour un seul effet. Ne rendez aucune bibliothèque obligatoire sur tous les sites. N'installez pas une dépendance simplement parce qu'elle apparaît dans un plan. Préférez les API CSS et de plateforme pour les transitions simples, Motion pour la chorégraphie de composants, GSAP avec ScrollTrigger pour les séquences chronologiques ou de défilement délibérées, PixiJS pour les scènes 2D exigeantes, Three.js pour le WebGL direct, et React Three Fiber avec des helpers drei sélectifs lorsque React existe déjà et que la composition de scène déclarative est bénéfique. Lenis est optionnel, jamais automatique.

Utilisez ReactBits et Codrops uniquement comme références sélectives. Confirmez la licence et la provenance du code et des actifs avant de les réutiliser. Préférez la synthèse originale ; conservez les mentions requises pour tout extrait sous licence.

Spécifier le mouvement avant de le construire

Pour chaque animation significative, enregistrez :

1. Objectif : ce qu'elle explique, priorise, confirme ou rend spatialement lisible.
2. Déclencheur : chargement, entrée, clic, changement d'état, pointeur, défilement ou progression du média.
3. Durée et easing : incluez les limites de répétition et d'interruption.
4. Comportement mobile : ce qui change pour la fenêtre d'affichage, le pointeur grossier, le tactile, la batterie et la capacité de l'appareil.
5. Solution de repli : état statique final pour mouvement réduit, JavaScript indisponible, média défaillant, WebGL perdu ou matériel contraint.

Évitez la signification basée uniquement sur le survol et le mouvement continu décoratif. La navigation, le message principal et l'appel à l'action doivent fonctionner avant la fin de l'animation. Sous prefers-reduced-motion: reduce, affichez les états finaux stables et supprimez le comportement défilé, parallax, de lecture automatique ou de défilement fluide plutôt que de simplement le raccourcir.

Budgétiser la performance

Définissez des budgets mesurables appropriés au projet avant l'implémentation. Considérez le JavaScript initial, le poids des médias, le nombre de polices, la concurrence des animations, les longues tâches, le décalage de mise en page, le timing du plus grand contenu, la stabilité des images, la mémoire GPU, le ratio de pixels de l'appareil et le coût thermique.

Pour le canvas ou WebGL, fournissez une affiche statique ; plafonnez le ratio de pixels ; mettez en pause lorsqu'il est hors écran ou caché ; évitez l'allocation par image ; réduisez le travail sur les petits appareils ou appareils contraints ; gérez l'échec du contexte ; et libérez les images, observateurs, écouteurs, textures, géométries, matériaux, cibles de rendu et l'état du renderer. Le contenu sémantique et les contrôles doivent rester en dehors ou indépendants du canvas.

Implémenter de manière proportionnelle

Préservez la direction approuvée et les conventions de projet existantes. Gardez le HTML sémantique et le contenu réel comme source de vérité. Chargez les expériences lourdes uniquement là où elles ajoutent de la valeur. Limitez les effets afin que plusieurs systèmes ne contrôlent pas la même propriété. Utilisez au maximum un seul moteur de défilement fluide, et uniquement lorsque sa valeur dépasse la complexité.

N'installez pas de bibliothèques, ne modifiez pas un projet et n'implémentez pas avant que le plan ne soit approuvé. Lorsque l'implémentation est autorisée, expliquez tout ajout de stack ou d'actif avant de le faire et respectez le gestionnaire de paquets et le fichier de verrouillage du projet.

Vérifier honnêtement

Utilisez verification.md pour le travail d'implémentation ou de révision. Inspectez les captures d'écran mobiles et de bureau, les états d'interaction, le tactile, le clavier, le focus, le mouvement réduit, les solutions de repli statiques, le comportement de chargement et d'échec, les preuves de performance et le comportement de nettoyage, en proportion du changement.

Rapportez exactement ce qui a été exécuté, ce qui a réussi, ce qui a été inspecté visuellement et ce qui reste non vérifié. N'insinuez jamais qu'une construction, un test de navigateur, un contrôle d'accessibilité, un test d'appareil ou une mesure de performance a été effectué alors que ce n'est pas le cas.

Provenance de la référence

Les conseils sont une synthèse originale. Consultez sources.md pour la documentation faisant autorité et l'inspiration clairement étiquetée de la communauté. N'installez et n'exécutez pas de code de compétence tiers via cette compétence.