Sur le site
[server name] de mon serveur d'hébergement Opus Growth, crée un site événementiel statique et rapide pour
[event name]. Événement :
[what it is, who it is for, which edition, two sentences]. Date et heure :
[start and end, time zone]. Lieu : [venue name, full address, transport, parking, accessibility facilities]. Programme :
[for each day the time, session title, speaker and room]. Intervenants : [name, title, organisation, talk title, bio, photo link and permission to publish the photo]. Billets : [ticket types, prices, whether VAT is included, valid dates, the link on the ticketing platform, refund and transfer terms]. Organisateur :
[organisation name],
[email],
[phone]. Politique d'enregistrement et de photos :
[whether talks are recorded and photos taken]. Domaine :
[domain].
Pages : accueil (une ligne date et lieu, compte à rebours, courte présentation, ce qui va se passer, quatre des intervenants, un résumé du lieu, FAQ), programme (/program/ : onglets par jour et fichier calendrier .ics), intervenants (/konusmacilar/), billets (/bilet/ : types de billets, ce qui est inclus, remboursements, FAQ facturation), lieu (/mekan/ : adresse, transports, accessibilité, hébergement), confidentialité (/gizlilik/, y compris le choix concernant les photos et l'enregistrement) et 404.html.
Style : une affiche de conférence. Sans
[colour preference] indiquée, un bandeau hero jaune signal, un fond crème, du texte noir et des bordures noires de 2 pixels. Une police Fontshare large et grasse en capitales pour les titres (par exemple Panchang 700) et une police sans empattement arrondie pour le texte (par exemple Chillax 400 et 500) ; précharge d'abord les trois fichiers du premier écran. La mise en capitales exige `<html lang="tr">`, sinon « i » devient « I ». Si un intervenant n'a pas de photo ou n'a pas donné l'autorisation de la publier, utilise un monogramme d'initiales ; n'utilise jamais la photo de quelqu'un d'autre.
Règles d'interaction (aucune bibliothèque, un seul `ix.js` avec defer, uniquement sur les pages d'accueil, de programme et d'intervenants) :
1. Le compte à rebours est exact même sans JS : le HTML contient le texte « Début : <time datetime="2027-05-13T09:00:00+03:00">jeudi 13 mai 2027, 09 h 00</time> (heure de Turquie) » dans une boite de hauteur fixe. Le JS lit avec Date.parse les dates ISO avec décalage de fuseau dans data-start et data-end, puis écrit des cases jours, heures et minutes dans la même boite. La boite doit avoir la même hauteur dans les deux états (min-height CSS et hauteur d'unité fixe), sinon le premier écran se décale. N'affiche pas les secondes ; mets à jour chaque minute et arrête la mise à jour quand l'onglet est masqué. Les cases de nombres sont en aria-hidden, avec à côté une seule phrase visuellement masquée pour les lecteurs d'écran, et sans région live (aria-live), car elle serait lue à voix haute chaque minute. Une fois l'événement commencé, écris « en cours », une fois terminé, écris « terminé » ; n'affiche jamais de nombres négatifs pour une date passée.
2. Onglets de jours : dans le HTML, chaque jour est une section distincte avec son propre titre (id="gun-1", "gun-2"), avec au-dessus des liens qui y mènent ; sans JS, tous les jours s'affichent les uns sous les autres. Le conteneur des liens porte role="group" et un aria-label. Le JS les transforme en onglets ARIA (tablist, tab, tabpanel, aria-selected, tabindex, flèches, Début et Fin), sélectionne le deuxième jour quand la page s'ouvre avec #gun-2, et met à jour l'URL avec history.replaceState au changement d'onglet pour qu'un jour puisse être partagé par lien. Chaque session est une ligne de liste avec un `<time datetime>` : heure, titre, un lien vers l'ancre de l'intervenant sur la page des intervenants et la salle ; les pauses ont un fond distinct.
3. Bio de l'intervenant : dans le HTML, elle se trouve dans un `<details>` sur chaque fiche, donc lisible sans JS et par les moteurs de recherche. Le JS intercepte le clic sur le summary, construit un unique `<dialog>`, y copie le nom, le titre, le titre de la conférence et la bio avec textContent, l'ouvre avec showModal et place le focus sur le bouton « Fermer » ; Échap et un clic sur l'arrière-plan le ferment et le focus revient sur le summary. Ajoute aria-haspopup="dialog" au summary. L'id de chaque fiche est le slug de l'intervenant, vers lequel pointent les liens du programme.
4. Appel à l'action billetterie fixe : un bouton « Prendre un billet » dans l'en-tête sur ordinateur, et sur mobile une barre fixée en bas de l'écran (date, prix le plus bas et « Prendre un billet »). La barre est du HTML statique dans le gabarit de pied de page et est en position: fixed dès le premier affichage ; l'ajouter plus tard avec JS provoque un décalage de mise en page. Sur mobile, donne au body un padding bas égal à la hauteur de la barre pour que les derniers liens ne se cachent pas dessous, ajoute `env(safe-area-inset-bottom)` et masque la barre sur la page des billets via une classe sur le body.
5. Fichier calendrier : `/assets/
[event].ics` téléchargé depuis la page du programme (VCALENDAR avec un VEVENT, DTSTART et DTEND en UTC, SUMMARY, LOCATION, URL, fins de ligne CRLF). Ajoute l'attribut download au lien.
Schéma : le même Event (@id /#event) sur les pages d'accueil, de programme et de billets : name, description, startDate et endDate avec décalage de fuseau, eventStatus EventScheduled, eventAttendanceMode OfflineEventAttendanceMode, location sous forme de Place avec une PostalAddress complète, trois images aux ratios 1x1, 4x3 et 16x9, organizer, les intervenants en performer et un tableau offers (pour chaque type de billet name, price, priceCurrency "TRY", availability, validFrom, validThrough pour l'early bird, et la page de vente en url). Le résultat enrichi Événement de Google exige location et startDate et ne fusionne pas les @id d'une page à l'autre ; écris donc l'Event en entier sur chaque page qui l'utilise ; sur la page du programme, ajoute aussi chaque session en subEvent. Si l'événement est reporté ou annulé, mets eventStatus sur EventPostponed ou EventCancelled au lieu de supprimer la page. Place sur la page du lieu et BreadcrumbList sur chaque page intérieure. Les sponsors, le nombre de participants ou « complet » ne s'écrivent que s'ils sont vrais.
Mise en place et pièges connus (chacun a couté des points dans les mesures de la démo, n'en saute aucun) :
1. Si un site est déjà en ligne sur le serveur, préviens-moi d'abord, car l'installation écrase index.html et le dossier assets. Prévisualise scaffold_site avec confirm=false et appelle-le avec confirm=true seulement après mon accord. Lis ensuite site_design_guide et site_seo_guide. Avant d'écrire du code, consigne la direction de design (typographie, couleurs, grille, élément signature, langage de mouvement et bibliothèques qui ne seront PAS chargées) dans un court fichier ART.md hors du dossier assets et montre-le-moi.
2. Compile Tailwind, ne le charge pas depuis le CDN. Installe-le avec site_run_command et background=true (`npm i -D tailwindcss@3`) et fais suivre de site_command_status. Les chemins content de `tailwind.config.js` doivent couvrir tous les fichiers HTML, les gabarits `_src` et tout fichier JS qui écrit des classes. `_src/tw.css` contient la ligne `@import "../assets/app.css";` plus les trois lignes `@tailwind` ; compile-le en un seul fichier avec `npx tailwindcss -c tailwind.config.js -i _src/tw.css -o assets/site.css --minify`. Retire le script cdn.tailwindcss.com et le tailwind.config en ligne de chaque page et ne lie que `/assets/site.css`. Recompile après chaque modification du HTML.
3. Héberge les polices toi-même. Lis le CSS de la famille Fontshare choisie, télécharge le woff2 de chaque graisse séparément avec site_fetch dans `assets/fonts/`, et écris les règles @font-face avec `font-display: swap` dans `assets/app.css`, là où design-check cherche une police personnalisée. Vérifie le nom font-family dans le CSS téléchargé et assure-toi que la famille contient les lettres turques ı, İ, ş et ğ (Tanker n'a pas de ı). Précharge TOUTES les graisses utilisées au premier écran avec `<link rel="preload" as="font" type="font/woff2" crossorigin>`, placé avant la ligne de la feuille de style ; au-delà de trois fichiers, utilise moins de graisses. Dans la démo, une seule graisse de texte non préchargée a fait monter le LCP mobile à 2,6 secondes et fait tomber la Performance à 97. La plupart des polices Fontshare n'ont pas le signe ₺, écris donc les prix avec « TL ».
4. Rends le menu et le pied de page en HTML statique. Ne charge pas chrome.js, motion.js ni site.config.js sur les pages. Écris un petit `chrome-stamp.mjs` qui lit la liste de navigation dans site.config.js et estampille `_src/header.tpl` et `_src/footer.tpl` entre les marqueurs `<!-- nav:start --><!-- nav:end -->` et `<!-- footer:start --><!-- footer:end -->` sur chaque page, en ajoutant aria-current="page" au lien actif. Utilise des repères comme `
[[NAV]]` au lieu de `{{...}}` et ne donne pas aux gabarits l'extension .html, sinon design-check et seo-check les traitent comme des pages inachevées. Construis le menu mobile avec un `<details>` sans JS. Garde le nom de l'entreprise, l'adresse et le téléphone en texte brut dans le pied de page, et donne aux liens du pied de page et du fil d'Ariane au moins 44 pixels de hauteur.
5. Convertis les images pendant leur récupération avec site_fetch : écris la même image en fichiers distincts avec resize="480x", "800x" et "1200x", image_format="webp", quality=60 (site_fetch ne recadre pas, demande donc la source au ratio voulu). Donne à chaque `<img>` srcset, sizes ainsi que width et height conformes au vrai ratio. L'image qui est l'élément LCP de la page reçoit fetchpriority="high" et n'est pas en lazy ; toutes les autres images reçoivent loading="lazy" decoding="async". Si une image remplit le premier écran mobile, sers un recadrage plus petit au mobile avec `<picture>`.
6. Ajoute `<link rel="icon" href="/favicon.svg" type="image/svg+xml">` à chaque page et crée une apple-touch-icon de 180 pixels à partir du logo avec site_fetch et resize="180x180". Sans lien favicon, le navigateur demande /favicon.ico, enregistre un 404 et les Bonnes pratiques tombent à 96.
7. Règles du validateur HTML : commence chaque document par un `<!DOCTYPE html>` en majuscules ; chaque espace dans le texte visible d'un lien tel: doit être ` `, y compris celui après un préfixe comme « Appeler : 0212... » ; n'utilise pas style="" ; donne un type à chaque bouton ; mets aria-label uniquement sur les repères, les formulaires ou les éléments interactifs (sur un ul ou un div sans rôle, c'était une erreur) ; n'étiquette jamais deux repères avec le même nom ; ne laisse aucun espace en fin de ligne.
8. Ne saute pas de niveaux de titres : sur une page de liste, des titres de cartes en h3 juste après le h1 ont fait tomber l'Accessibilité à 98. Quand tu réutilises une carte, règle le niveau de titre page par page (h2 sur une page de liste, h3 dans une section h2).
9. Nomme l'attribut de mouvement data-reveal (design-check ne reconnait le mouvement que sous ce nom). Le JS ne donne l'état de départ masqué qu'aux blocs qui sont sous l'écran à l'ouverture de la page, et ne masque jamais le contenu du premier écran ; utilise transform, car un fondu en opacity abaisse l'audit de contraste. Place l'attribut sur le bloc qui enveloppe un titre et sa description, pas sur le titre seul ; dans la démo, un titre en attente a glissé par-dessus le paragraphe en dessous. Avec prefers-reduced-motion: reduce, rien n'est masqué et les animations sont désactivées.
SEO, AEO et GEO :
1. Utilise des URL de type répertoire avec une barre oblique finale. Remplis le bloc seo de site.config.js et exécute `node seo-stamp.mjs`. Écris le schéma propre à chaque page dans des blocs `<script type="application/ld+json">` séparés, reliés au graphe de base par @id. N'imbrique pas BreadcrumbList dans @graph ; garde-le dans son propre bloc, seule façon pour seo-check de le voir.
2. Titres de 60 caractères au maximum (seo-check signale comme erreur tout ce qui fait moins de 25 ou plus de 65), descriptions de 130 à 158 caractères, un seul h1 par page et au moins 150 mots de contenu principal sur chaque page. Les pages de contact, de confidentialité et de liste ont tendance à être trop courtes ; ajoute des informations propres à la page, pas du remplissage.
3. Le premier paragraphe de chaque page répond directement à la question de la page. Écris des FAQ propres à chaque page avec `<details>` et balise-les en FAQPage. Affiche l'éditeur et une date de « Dernière mise à jour » dans un élément `<time>`.
4. Dans robots.txt, écris ta décision avec sa raison pour GPTBot, OAI-SearchBot, ChatGPT-User, ClaudeBot, Claude-User, Claude-SearchBot, PerplexityBot, Perplexity-User, Google-Extended, Applebot-Extended, Bingbot et CCBot, et indique le sitemap. sitemap.xml contient de vraies dates lastmod. llms.txt contient un résumé exact du site en deux phrases et la liste des pages importantes.
5. Aucune invention : n'écris ni avis, ni notes, ni récompenses, ni nombre de clients, ni certificats, ni horaires d'ouverture, ni coordonnées, ni prix sans me demander. Laisse totalement hors du schéma tout champ que tu ne connais pas.
Contrôles (dans l'ordre ; ne dis pas « terminé » avant qu'ils passent tous) :
1. Avec site_run_command, exécute `node chrome-stamp.mjs`, la compilation Tailwind, `node seo-stamp.mjs`, `node seo-check.mjs` (0 erreur, 0 avertissement), `node design-check.mjs` (0 erreur ; justifie tout avertissement restant) et `npx html-validate "**/*.html"` (0 erreur).
2. Visualise chaque page avec site_preview, view="mobile" et view="desktop". site_preview capture la page avec le mouvement désactivé (reduced-motion) ; si du contenu manque dans cette capture, l'état statique est cassé. Dans les captures pleine page, des éléments fixes comme une barre fixe peuvent apparaitre au milieu de la page et les images lazy plus bas peuvent être vides ; ne les compte pas comme des erreurs, mais vérifie leurs chemins.
3. Exécute core_web_vitals pour chaque page avec strategy="mobile" et strategy="desktop". Critères d'acceptation : sur mobile, Performance d'au moins 95 (objectif 99 à 100) et Accessibilité, Bonnes pratiques et SEO à 100 ; sur ordinateur, les quatre à 100. Pour une page qui échoue, utilise resources=true pour trouver le fichier qui la retarde, corrige-le et mesure à nouveau. Exécute ensuite seo_audit sur la page d'accueil avec strategy="mobile" et runs=2. Aucune adresse extérieure à ton propre domaine ne doit rester dans la liste des requêtes réseau.
4. Aucun défilement horizontal à 360, 390, 768 et 1440 pixels de large, zones tactiles d'au moins 44 pixels, aucune erreur console.
Vérification des interactions : site_preview ne peut pas montrer le temps, les onglets ni les modales. Explique-moi comment vérifier que le compte à rebours affiche la bonne date avec JavaScript désactivé et se transforme en cases de même hauteur avec JS activé, que /program/#gun-2 ouvre le deuxième jour et que les onglets changent avec les flèches, qu'une bio d'intervenant s'ouvre en modale et que le focus revient après Échap, que sur téléphone la barre de billetterie ne recouvre pas les derniers liens de la page, que le fichier calendrier arrive dans le calendrier du téléphone à la bonne heure, et que le Test des résultats enrichis de Google affiche l'Event sans erreur.
Après la publication : prévisualise avec site_headers la règle `/assets/* Cache-Control: public, max-age=31536000, immutable` et applique-la une fois que j'ai donné mon accord ; ensuite, versionne le nom du fichier à chaque modification du CSS ou du JS (site-v2.css, etc.). Soumets sitemap.xml avec gsc_submit_sitemap et vérifie la page d'accueil avec gsc_url_inspect. À la fin, donne-moi : un tableau de scores page par page (page, quatre scores mobile, quatre scores ordinateur, LCP, CLS), le résultat de chaque contrôle et la liste des correctifs appliqués.
