Ce que tout agent IA (Claude, Copilot, Cursor…) doit respecter quand il construit ou modifie une interface, un README ou une icône dans un projet qui utilise Pelote. Ces règles priment sur les habitudes par défaut de l'agent.

Icônes

• Ne jamais générer, dessiner ou inventer une icône, même simple (réglages, recherche, fermer, menu, flèche, poubelle…). Pas de <path> écrit à la main, pas de SVG « inspiré de », pas d'emoji à la place.
• Toujours utiliser une icône existante des Material Symbols de Google : Rounded pour M3E et Plaza, Sharp pour Chrome.
  • Web : la police Google Fonts avec icon_names= et <span class="ms">settings</span>. S'il faut un fichier SVG (favicon, icône d'app, image dans un README), le télécharger depuis le dépôt officiel des Material Symbols, sans le retoucher.
  • Flutter : Icons.settings_rounded (et _sharp en Chrome). Compose : Icons.Rounded.Settings.
• Chercher le nom exact sur fonts.google.com/icons. Si aucune icône ne correspond, choisir la plus proche et le signaler, au lieu d'en créer une.
• Les icônes d'app et favicons suivent la fiche AppIcon : un Material Symbol rempli sur cookie9, rien d'autre.

Code

• Composants réutilisables avant tout. Avant d'écrire un composant, chercher s'il existe déjà (dans l'app ou dans ce système) et le réutiliser ou l'étendre par ses props, plutôt que de dupliquer du balisage ou du style.
• Un composant doit pouvoir être réutilisé ailleurs : il reçoit ses données par props (ou paramètres en Flutter), ne va pas chercher lui-même l'état global de l'écran, et n'embarque pas de texte ou de couleur propres à une seule page. Les variantes passent par des props (variant, size), pas par des copies.
• Une fonction, une responsabilité. Une fonction fait une seule chose et se nomme d'après elle. Séparer récupération des données, transformation et affichage. Une fonction qui grossit se découpe.
• Ne pas surcharger le code : pas de logique dupliquée entre deux écrans (la factoriser dans un composable, un hook ou un utilitaire partagé), pas de styles copiés-collés (utiliser les classes et tokens du système), pas d'abstraction inventée pour un seul usage.
• Les helpers du système (Pelote.SHAPES, calque d'état .st, classes .btn, .chip, .card…) sont la base : on les consomme, on ne les recrée pas.

Web : PWA et Lighthouse

• Tout site ou app web livré est une PWA complète et retire le reflet bleu au tap (voir Règles UX, « Web mobile et PWA »).
• Lighthouse à 100 sur SEO, Bonnes pratiques, Accessibilité et Agentic search, en mobile comme en desktop. La Performance n'a pas à être à 100, mais doit en être le plus près possible (images en WebP / AVIF dimensionnées, polices sous-ensemble en font-display: swap, code découpé, rien qui bloque le rendu).
• Concrètement, sans exception : <title> et meta description par page, lang sur <html>, URL canoniques, robots.txt et sitemap.xml, données structurées quand elles ont un sens, contrastes et noms accessibles sur tous les contrôles, alt sur toutes les images, HTTPS, aucune erreur dans la console, contenu lisible sans JavaScript côté serveur ou prérendu (le portfolio prérend déjà ses pages).
• Lancer Lighthouse avant de livrer et corriger tout ce qui fait passer une de ces catégories sous 100.

Layout

• Navigation : barre en bas sur téléphone, rail à gauche sur tablette et PC, deux volets sur un fold ouvert (section Layout).
• Sur PC, jamais d'espace mort : une vue d'ensemble passe en bento pleine largeur (tuiles de tailles différentes), un contenu qui se lit reste borné avec un volet utile (widgets, détail, aperçu) ou centré. Jamais de cartes identiques étirées.

Mouvement

• Ne jamais écrire « Chargement… », « Loading… » ou « Veuillez patienter » comme seul retour : toujours un loader du système (fiche Loader), squelette pour le contenu.
• Animations idle : uniquement sur le décor, une par zone, lentes, en pause hors écran, coupées par prefers-reduced-motion (fiche IdleMotion).

Couleurs et formes

• Toujours livrer un réglage d'apparence : mode clair, sombre ou système, couleur du thème au choix, et sur Android l'option Material You (couleurs du fond d'écran), activée par défaut sur Android 12+.

• Toujours passer par les rôles M3 (primary, secc, sc…), jamais une couleur en dur, y compris dans les variantes Plaza et Chrome.

• Formes : uniquement les 26 formes de Pelote.SHAPES. Ne pas recréer de forme par une formule, ne pas utiliser les formes exclues (éclats, pixel, heart, puffy, flower).

• Statuts : ok, warn, bad, toujours avec un mot ou une icône.

Texte

• Toute interface livrée est au moins en français et en anglais, sans texte en dur, avec les règles de localisation des Règles UX (boutons sans largeur fixe qui passent en pile, aucun texte tronqué, formats via Intl).

• Dans une carte, aucun élément court seul sur sa ligne s'il tient ailleurs : pas de vide inutile.

• Langue de l'app, casse de phrase, verbes d'action sur les boutons.

• Jamais de tiret cadratin, pas d'emoji, pas de point d'exclamation.

README

• Suivre la section README GitHub : banner clair et sombre, badges, sections numérotées, footer de la marque toujours présent et cliquable (beedywool.com sur les projets actuels).
• Vérifier chaque visuel sur fond blanc et sur #0d1117 avant de livrer.

En cas de doute

Reprendre un composant ou un écran existant de ce système plutôt qu'en inventer un. Signaler ce qui manque au lieu de l'improviser.