# CLAUDE.md — sportcorico-release-guides Site statique qui héberge les **guides utilisateur des nouveautés** publiés à chaque mise à jour majeure de SportCorico. Un guide = un dossier daté contenant une page HTML autonome. URL en prod : `https://release-guides.sportcorico.com//` ## Stack HTML / CSS / JS vanilla. Aucun build, aucun framework. Servi en statique par Caddy depuis `/home/ubuntu/sites/release-guides.sportcorico.com` sur le serveur. ## Structure du projet ``` sportcorico-release-guides/ ├── CLAUDE.md ← ce fichier ├── styles.css ← feuille de style partagée par tous les guides ├── app.js ← lightbox, scrollspy, FAB sommaire mobile ├── logo-sportcorico.svg ← logo blanc, header des guides ├── favicon.png ← favicon SportCorico └── AAAA-MM-JJ/ ← un dossier par release (date du release_note) ├── index.html ← le guide en lui-même ├── release_note.md ← source : liste des changements └── screens/ ← captures organisées par thématique ├── champs personalises/ ├── licences/ ├── config club/ └── ... ``` Le CSS et le JS sont **mutualisés à la racine** — chaque guide les référence en `../styles.css` et `../app.js`. Idem pour le logo (`../logo-sportcorico.svg`) et le favicon (`../favicon.png`). ## Créer un nouveau guide — procédure ### 1. Préparer le brief (côté humain) Avant de demander à Claude de générer le guide, l'utilisateur doit déposer dans un nouveau dossier daté (ex: `2026-09-15/`) : - **`release_note.md`** — la liste des changements, organisée par thématique sous des titres `##`. Une ligne `-` par changement. - **`screens/`** — un dossier par thématique, contenant les captures d'écran utiles. Nom des fichiers libre mais explicite (ex: `licences_index_champ_perso_epingle_et_code_promo.png`). - **Le hash du commit Flutter de départ** — le commit à partir duquel les changements ont commencé sur l'app Flutter. Indispensable pour permettre à Claude de croiser les screens avec les commits et comprendre le contexte technique. Structure attendue d'un brief : ``` sportcorico-release-guides/2026-09-15/ ├── release_note.md └── screens/ ├── thematique-1/ │ ├── capture-1.png │ └── capture-2.png ├── thematique-2/ └── ... ``` ### 2. Générer le guide (côté Claude) Quand l'utilisateur demande la génération avec une référence au dossier de brief, suis cette procédure : 1. **Lire `release_note.md`** pour identifier les chapitres et les fonctionnalités. 2. **Lire toutes les images** du dossier `screens/` (l'outil `Read` accepte les images). Une image vaut mille mots — c'est ce qui permet de décrire précisément ce qui change, pas juste de paraphraser le release note. 3. **Croiser avec les commits Flutter** depuis le hash fourni : `cd ../sportcorico-flutter-app && git log --oneline ..HEAD` puis `git show --stat ` sur les commits pertinents. Ça révèle des détails non visibles sur les screens (nouvelles constantes, conditions techniques, périmètre exact). 4. **Générer `index.html`** dans le dossier de la release, en réutilisant les composants de `styles.css` (voir section suivante). 5. **Vérifier** que les chemins des assets sont corrects : - `../styles.css`, `../app.js`, `../logo-sportcorico.svg`, `../favicon.png` - `screens/...` pour les captures (chemin relatif au guide) ### 3. Squelette HTML à dupliquer ```html SportCorico — Nouveautés du JJ MOIS AAAA

Mise à jour · JJ MOIS AAAA

Nouveautés SportCorico

Une phrase d'intro qui pose la release.

📝 Titre du chapitre

Intro du chapitre.

``` ## Composants CSS disponibles | Classe | Usage | |---|---| | `section.chapter` | Un chapitre du guide (= une grande thématique) | | `.feature` | Une nouveauté à l'intérieur d'un chapitre | | `.feature p.lead` | Paragraphe d'accroche en muted sous le titre | | `.tag.new` | Badge orange "Nouveau" | | `.tag.mobile` | Badge bleu "App mobile" (préciser le périmètre) | | `.tag.admin` | Badge neutre "Admin" | | `.where` | Fil d'Ariane / chemin de navigation dans l'app (`` + `›`) | | `.ui` | Reprend un libellé exact de l'interface (style inline code) | | `ol.steps` | Étapes numérotées avec pastilles primary | | `.callout` | Encadré bleu (info contextuelle) | | `.callout.warning` | Encadré jaune (conditions, limites) | | `.callout.tip` | Encadré vert primary (astuce, à retenir) | | `.screens` | Grille auto-responsive de captures (desktop par défaut) | | `.screens.single` | Une seule capture (alignée à gauche, largeur bornée) | | `.screens.mobile` | Grille adaptée aux captures mobiles (colonnes étroites) | | `figure.mobile-screen` | Capture d'app mobile (largeur ≤ 240 px, hauteur ≤ 420 px) — **toujours** ajouter cette classe aux figures issues de l'app mobile | Toutes les figures sont cliquables (lightbox). Le sommaire latéral devient un **FAB bottom-sheet** sur mobile, géré automatiquement par `app.js` à partir du `aside nav` — pas de markup à dupliquer. ## Rédaction — règles d'or - **Une nouveauté = un `.feature`**. Ne pas tasser plusieurs choses dans un seul bloc. - **Toujours dire OÙ trouver la nouvelle fonction** dans l'app via un `.where` (chemin de navigation). - **Mentionner les conditions / limites** dans un `.callout.warning` quand il y en a (ex : "le groupe doit avoir une catégorie"). - **Préciser le périmètre** : tag `App mobile`, `Admin`, etc. selon le cas. - **Reprendre les libellés exacts** de l'app dans des `…` plutôt que de paraphraser. - **Vocabulaire utilisateur** : "case à cocher", pas "toggle" ; "menu déroulant", pas "dropdown" ; "fenêtre", pas "modale". Le public n'est pas développeur. ## Déploiement ```bash # Depuis ta machine git add 2026-XX-XX/ git commit -m "Release 2026-XX-XX" git push # Sur le serveur (manuel ou webhook) cd /home/ubuntu/sites/release-guides.sportcorico.com && git pull ``` Caddy sert le contenu directement, pas de redémarrage requis. ## Hébergement — bloc Caddy ```caddy release-guides.sportcorico.com { root * /home/ubuntu/sites/release-guides.sportcorico.com encode zstd gzip file_server browse try_files {path} {path}/ /index.html } ``` Caddy obtient le cert Let's Encrypt automatiquement. `browse` activé permet d'avoir un listing navigable des releases en attendant la création d'un `index.html` racine.