À compléter avant l'envoi
[server name][my full name][title, date, text or draft][year ranges and roles][email][GitHub, LinkedIn etc. or "none"][yes and from when, or no][domain][slug][[NAV]
Sur le site [server name] de mon serveur d'hébergement Opus Growth, crée un portfolio personnel statique pour [my full name], avec l'ambiance sombre et posée des sites de Linear et de Vercel. À propos de moi : [my title, my city, what I have done for how many years, two sentences]. Projets : [for each one the name, year, my role, whether I may publish the client's name, the technologies, context, constraints, approach and outcome notes, and a screenshot link]. Articles : [title, date, text or draft]. Parcours : [year ranges and roles]. Contact : [email] ; profils que je veux publier : [GitHub, LinkedIn etc. or "none"]. Disponible pour de nouvelles missions : [yes and from when, or no]. Domaine : [domain].
Pages : accueil (courte présentation, projets sélectionnés, derniers articles, ce que je fais en ce moment, FAQ), projets (/projeler/), une page par étude de cas (/projeler/[slug]/ : contexte, contraintes, approche, résultat, fiche du projet), articles (/yazilar/), une page par article (/yazilar/[slug]/), à propos (/hakkimda/) et 404.html. Si le client n'a pas validé les chiffres, n'écris aucun pourcentage ni aucune durée dans une étude de cas ; décris le résultat de façon qualitative.
Style : sombre et minimal. Un fond autour de #09090B, des cartes d'un cran plus claires, une bordure gris foncé de 1 pixel, un texte presque blanc, un texte secondaire dans un gris offrant au moins 7:1 de contraste sur le fond, et une seule couleur d'accent utilisée uniquement pour une pastille de statut, l'anneau de focus et les liens. Deux graisses d'une grotesque Fontshare (par exemple Bespoke Sans 400 et 500) ; pour les dates et les étiquettes, utilise la pile monospace du système sans télécharger de police (ui-monospace, SFMono-Regular, Menlo, Consolas). Si les chiffres paraissent elzéviriens, applique `font-variant-numeric: lining-nums`. Le hero n'a pas d'image ; de fines lignes de grille qui s'estompent sous un masque sont dessinées derrière lui en CSS.
Règles d'interaction :
1. GSAP, Lenis, Swiper et les bibliothèques de recherche toutes faites (Fuse.js et consorts) ne sont PAS chargés. Chaque page reçoit un seul petit `ix.js` en defer (spotlight, déclencheur du menu de commandes, data-reveal), et le menu de commandes lui-même vit dans un `ara.js` séparé. ara.js n'est pas téléchargé avec la page ; il se charge quand le pointeur entre dans le déclencheur ou que le focus l'atteint, ou à la première ouverture du menu. Dans la démo, les pages d'article n'avaient pas ix.js et Ctrl K n'y faisait rien ; le menu doit se comporter de la même façon sur toutes les pages.
2. Cartes spotlight : une lumière douce sur le ::before de la carte avec `radial-gradient(420px circle at var(--mx) var(--my), ...)` et une lueur d'accent sur la bordure de 1 pixel via ::after avec mask-composite. Le JS ajoute un seul écouteur pointermove sur le conteneur des cartes, le limite avec requestAnimationFrame, écrit --mx et --my relativement à la boite de chaque carte et les efface quand le pointeur sort. Cela ne s'exécute que sur les appareils qui correspondent à `(hover: hover) and (pointer: fine)` et ne demandent pas de mouvement réduit ; sur écran tactile, la carte reste simple. Le lien du titre de la carte recouvre toute la carte grace à un ::after.
3. Menu de commandes : l'élément « Rechercher » du header est un vrai lien vers /projeler/ dans le HTML (utile sans JS) et porte aria-keyshortcuts="Control+K Meta+K". Le JS intercepte le clic ; Ctrl K, Cmd K et la touche / (hors champs de saisie) ouvrent le menu. Le menu est un `<dialog>` construit par le JS à la première ouverture et ouvert avec showModal : un champ de recherche avec role="combobox", aria-expanded, aria-controls, aria-autocomplete="list" et aria-activedescendant, une liste de résultats avec role="listbox", et une zone role="status" qui annonce le nombre de résultats. Les flèches déplacent la sélection, Entrée ouvre la page sélectionnée, Échap ferme via le comportement natif du dialog, un clic sur l'arrière-plan ferme le menu et le focus revient au déclencheur à la fermeture.
4. Index de recherche `/assets/ara.json` : titre, type (Projet, Article, Page), URL, résumé d'une phrase et mots-clés pour chaque projet, article et page principale. N'écris pas ce fichier à la main ; génère-le à partir des mêmes données que celles des pages de projets et d'articles, pour que les deux ne divergent jamais. Rends la recherche insensible aux caractères turcs (toLocaleLowerCase("tr"), puis normalisation de ı, ş, ğ, ü, ö, ç), exige que tous les mots correspondent et classe plus haut les correspondances dans le titre.
5. Une page d'étude de cas s'ouvre sur un tableau de faits (année, rôle, client, technologie) et la capture d'écran qui est son élément LCP (fetchpriority="high", pas lazy) ; les titres de cartes sont en h2 sur les pages de liste et en h3 dans une section h2 sur l'accueil.
Schema : ProfilePage sur l'accueil et à propos (mainEntity Person), Person (@id /#person : name, jobTitle, url, email, une adresse avec seulement la ville et le pays, knowsAbout, et sameAs uniquement pour les profils que je t'ai donnés). Le bloc Organization que seo-stamp écrit représente mon activité d'entrepreneur individuel ; relie la Person à celui-ci avec worksFor. Les projets reçoivent un CollectionPage avec hasPart ; chaque étude de cas est un CreativeWork (creator Person, dateCreated, image, keywords) ; les articles reçoivent un Blog et chaque article un BlogPosting (headline, image, datePublished, dateModified, author Person ; seo-check lève une erreur si image ou datePublished manque). Les conférences, distinctions et listes de clients ne contiennent que des faits vérifiables.
Mise en place et pièges connus (chacun a fait perdre des points lors des mesures de la démo, n'en saute aucun) :
1. Si un site est déjà en ligne sur le serveur, dis-le-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 modèles `_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 inline 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 dans le premier écran avec `<link rel="preload" as="font" type="font/woff2" crossorigin>`, placé avant la ligne de la feuille de style ; si cela fait plus de trois fichiers, utilise moins de graisses. Dans la démo, une seule graisse de texte non préchargée a fait passer le LCP mobile à 2,6 secondes et 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 espaces réservés comme `[[NAV]]` à la place de `{{...}}` et ne donne pas aux modèles 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 simple dans le pied de page, et donne aux liens du pied de page et du fil d'Ariane une hauteur d'au moins 44 pixels.
5. Convertis les images au moment de les récupérer 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 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, journalise une 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 celle après un préfixe comme « Appeler : 0212... » ; n'utilise pas style="" ; donne un type à chaque bouton ; ne mets aria-label que sur les repères (landmarks), les formulaires ou les éléments interactifs (sur un ul ou un div sans rôle, c'était une erreur) ; ne donne jamais le même nom à deux landmarks ; ne laisse aucun espace en fin de ligne.
8. Ne saute pas de niveau de titre : 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 son 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 situés sous l'écran à l'ouverture de la page, et ne masque jamais le contenu du premier écran ; utilise transform, car un fondu par opacity fait baisser 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 glissait par-dessus le paragraphe suivant. 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. Renseigne le bloc seo de site.config.js et exécute `node seo-stamp.mjs`. Écris le schema propre à chaque page dans des blocs `<script type="application/ld+json">` distincts, reliés au graphe de base par @id. N'imbrique pas BreadcrumbList dans @graph ; garde-le dans son propre bloc, seul moyen 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 contact, confidentialité et les pages 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 justification pour GPTBot, OAI-SearchBot, ChatGPT-User, ClaudeBot, Claude-User, Claude-SearchBot, PerplexityBot, Perplexity-User, Google-Extended, Applebot-Extended, Bingbot et CCBot, et pointe vers 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. Pas d'invention : n'écris ni avis, ni notes, ni distinctions, ni nombre de clients, ni certificats, ni horaires, ni coordonnées, ni prix sans me demander. Omets entièrement du schema tout champ que tu ne connais pas.
Contrôles (dans l'ordre ; ne dis pas « terminé » avant qu'ils soient tous passés) :
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. Affiche 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 défaillant. Dans les captures pleine page, des éléments fixes comme une barre collante peuvent apparaitre en milieu de page et les images lazy plus bas peuvent être vides ; ne les compte pas comme des erreurs, mais vérifie leurs chemins.
3. Lance 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 desktop, les quatre à 100. Pour une page qui n'y arrive pas, utilise resources=true pour trouver le fichier qui la retarde, corrige-le et mesure à nouveau. Lance ensuite seo_audit sur la page d'accueil avec strategy="mobile" et runs=2. Aucune adresse extérieure à ton propre domaine ne doit subsister dans la liste des requêtes réseau.
4. Pas de défilement horizontal à 360, 390, 768 et 1440 pixels de large, zones tactiles d'au moins 44 pixels, aucune erreur console.
Contrôle des interactions : site_preview ne peut pas montrer le survol, les raccourcis clavier ni les dialogues. Explique-moi comment vérifier sur un ordinateur que la lumière suit le pointeur sur les cartes ; que Ctrl K, Cmd K et / ouvrent le menu ; qu'une saisie sans caractères turcs trouve quand même des résultats (« erisilebilir » et autres) ; que les flèches et Entrée m'emmènent vers un article ; que le focus revient au bouton Rechercher après Échap ; et que, JavaScript désactivé, le lien Rechercher ouvre la page des projets.
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 fois que le CSS ou le JS change (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 des scores page par page (page, quatre scores mobile, quatre scores desktop, LCP, CLS), le résultat de chaque contrôle et la liste des corrections appliquées.