L’audit, en clair.

Tu révises uniquement la microcopy adjacente au CTA principal du hero de quentinlecocq.com.

Contexte vérifié : le CTA « Trouver mon premier usage » ouvre Cal.com. La page doit annoncer, près de ce CTA, la destination Cal.com, une durée de 20 min et l’absence d’engagement. Ne change pas le CTA, ne crée pas de second CTA et ne formule aucune promesse commerciale supplémentaire.

Entrées :
- Texte actuel du hero : [COLLER]
- CTA actuel : [COLLER]
- Destination actuellement vérifiée : [COLLER]
- Contraintes de ton : [COLLER OU « aucune fournie »]

Propose une seule microcopy exacte, sous cette forme :
« Réservation Cal.com, 20 min, sans engagement »

Si une adaptation de ponctuation est indispensable pour respecter le ton existant, donne-la comme variante unique et explique en une phrase ce qui change. Vérifie explicitement que le texte n’ajoute ni durée différente, ni promesse, ni nouveau lien.

Inspecte d’abord le dépôt réel : identifie le composant ou la source de contenu qui rend le CTA principal du hero, son href actuel et les styles qui régissent sa zone d’action. Ne déduis pas la structure depuis le site public.

Cette demande est de revue uniquement : ne modifie aucun fichier du dépôt, ne lance aucune commande, aucun test, aucun serveur local ou aperçu, ne consulte pas d’environnement distant et n’effectue aucune action externe. Toute application nécessite une instruction humaine distincte.

Ensuite, propose avant toute modification :
1. un plan concis ;
2. les fichiers concernés et pourquoi ;
3. un diff minimal qui ajoute sous le CTA du hero le texte HTML exact « Réservation Cal.com, 20 min, sans engagement » ;
4. les tests ou vérifications à exécuter.

Contraintes non négociables :
- conserve exactement la destination Cal.com existante du lien ;
- n’ajoute aucun second lien, CTA, événement, tracking ou destination ;
- conserve le texte comme HTML sélectionnable, visuellement associé au CTA, sans remplacer son libellé accessible ;
- vérifie le rendu à 390 px et 1440 px, sans débordement horizontal ;
- ne publie pas, ne déploie pas, ne crée pas de pull request, ne merge pas et n’ouvre aucune réservation.

Retourne uniquement le plan, les fichiers concernés, un diff proposé non appliqué et un protocole de vérification à exécuter ultérieurement par une personne autorisée. Pour chaque test proposé, indique l’objectif, les prérequis et le résultat attendu. Signale explicitement les éléments non vérifiables sans exécution.

Relis la correction A1 dans son rendu local. Vérifie mot à mot que la microcopy visible sous le CTA du hero est « Réservation Cal.com, 20 min, sans engagement ». Vérifie que le CTA conserve exactement son href Cal.com existant et qu’aucun second lien ne concurrence l’action principale. Signale toute promesse, durée, destination ou formulation ajoutée qui ne figure pas dans la consigne. Donne un verdict : conforme, à corriger, ou non vérifiable.

Exécute une QA locale ou de prévisualisation pour A1, sans ouvrir ni soumettre de réservation. Contrôle à 390 px et 1440 px : lisibilité du CTA et de la microcopy, ordre de lecture, absence de chevauchement et de débordement horizontal. Inspecte le href final du CTA et compare-le à sa valeur avant modification. Retourne un tableau critère / résultat / preuve / anomalie, puis un verdict de validation.

Tu prépares le contenu d’un média de premier usage réel pour le hero ou sa proximité sur quentinlecocq.com.

Ne travaille que sur les faits fournis. Le média doit rendre compréhensible la séquence Discord, note Obsidian, historique GitHub. Ne simule aucune donnée client et ne transforme pas une hypothèse en preuve.

Entrées :
- Média et source réelle : [COLLER]
- Autorisation et attribution : [COLLER]
- Éléments anonymisés : [COLLER]
- Faits observables dans la séquence : [COLLER]

Produis :
1. un résumé textuel adjacent de 2 à 3 phrases maximum ;
2. un alt utile ou, si le média est trop détaillé, une recommandation de texte équivalent adjacent ;
3. une liste des données qui doivent rester invisibles ;
4. un contrôle explicite confirmant qu’aucune promesse de résultat, métrique ou donnée non autorisée n’a été ajoutée.

Si l’autorisation, l’anonymisation ou le caractère réel du média ne sont pas démontrés, arrête-toi et réponds « contenu non intégrable à ce stade ».

Inspecte d’abord le dépôt réel pour localiser le hero, le composant média existant, la gestion des images ou vidéos, les conventions d’accessibilité et le comportement responsive. Ne suppose pas le composant à partir de l’inspection publique.

Cette demande est de revue uniquement : ne modifie aucun fichier du dépôt, ne lance aucune commande, aucun test, aucun serveur local ou aperçu, ne consulte pas d’environnement distant et n’effectue aucune action externe. Toute application nécessite une instruction humaine distincte.

Avant toute modification, demande ou vérifie les prérequis bloquants : média réel, autorisé, anonymisé et utilisable. Si un prérequis manque, ne propose aucun faux contenu et explique précisément le blocage.

Si les prérequis sont confirmés, fournis :
1. un plan concis intégrant A2 avec A3 si les deux modifications touchent le même premier écran ;
2. les fichiers concernés ;
3. un diff minimal qui rend le média et son texte d’accompagnement disponibles à 390 px et 1440 px ;
4. les contrôles d’alt ou d’équivalent textuel, de poids du média et de responsive ;
5. les tests à exécuter.

Contraintes :
- le média doit provenir d’un usage réel et ne contenir aucune donnée identifiable ou non autorisée ;
- la séquence Discord, Obsidian puis GitHub doit rester compréhensible par le média et le texte adjacent ;
- ne masque ni le H1 ni le CTA, y compris sur mobile ;
- ne publie pas, ne déploie pas, ne crée pas de pull request, ne merge pas et n’appelle aucun service externe.

Retourne uniquement le plan, les fichiers concernés, un diff proposé non appliqué et un protocole de vérification à exécuter ultérieurement par une personne autorisée. Pour chaque test proposé, indique l’objectif, les prérequis et le résultat attendu. Signale explicitement les éléments non vérifiables sans exécution.

Relis A2 uniquement à partir des preuves fournies. Confirme séparément : origine réelle du média, autorisation, anonymisation, compréhension de la séquence Discord puis Obsidian puis GitHub, présence d’un alt ou texte équivalent et absence de promesse non documentée. Si l’un de ces éléments n’est pas prouvé, classe le contenu « non intégrable à ce stade ». Ne déduis jamais le consentement d’une simple capture.

Effectue une QA locale A2 sans publication ni appel externe. À 390 px et 1440 px, vérifie la présence du média ou de son équivalent textuel, sa lisibilité, son alt ou texte adjacent, l’absence de masquage du H1 et du CTA, l’absence de débordement et le poids réel du média si l’outil le permet. Documente séparément les contrôles techniques et ceux qui exigent une validation humaine d’autorisation/anonymisation.

Tu rédiges un bloc de trois paires avant / après pour quentinlecocq.com, à proximité du hero.

Utilise uniquement les situations fournies et formule chacune comme une situation quotidienne concrète, non comme une capacité technique. Les trois thèmes attendus sont : retrouver le contexte, préparer une action avec des notes organisées, garder une trace versionnée.

Entrées :
- Situations et faits source : [COLLER]
- Ton et formulation existante : [COLLER]
- Contraintes de longueur : [COLLER]

Retourne trois paires clairement étiquetées « Avant » et « Après ». Ne mets aucun gain chiffré, délai, promesse de résultat, causalité, témoignage non documenté ou bénéfice non fourni. Reste factuel et cohérent avec la page. Ajoute une courte note expliquant comment préserver la hiérarchie du CTA.

Inspecte d’abord le dépôt réel pour identifier le hero, la zone d’actions, la section suivante, les motifs de contenu réutilisables et les règles responsive. Vérifie aussi si A2 est traité dans le même changement afin d’éviter deux ajouts concurrents dans le premier écran.

Cette demande est de revue uniquement : ne modifie aucun fichier du dépôt, ne lance aucune commande, aucun test, aucun serveur local ou aperçu, ne consulte pas d’environnement distant et n’effectue aucune action externe. Toute application nécessite une instruction humaine distincte.

Si les trois situations validées et leurs contenus source ne sont pas fournis, arrête-toi et réponds : « A3 non intégrable à ce stade : situations source ou validation éditoriale manquantes ». Ne rédige aucune paire avant / après de substitution.

Avant toute modification, fournis :
1. un plan concis pour l’emplacement et l’ordre de lecture ;
2. les fichiers concernés ;
3. un diff minimal pour un bloc HTML sémantique de trois paires avant / après ;
4. les tests et vérifications de rendu.

Contraintes :
- emploie de vrais intertitres et du texte HTML ;
- ne différencie pas avant et après par la seule couleur ou une icône ;
- n’ajoute aucune métrique, promesse de productivité, délai, résultat client ou témoignage non documenté ;
- à 390 px et 1440 px, maintiens le bon ordre, la lisibilité et la hiérarchie du hero et du CTA ;
- ne publie pas, ne déploie pas, ne crée pas de pull request et ne merge pas.

Retourne uniquement le plan, les fichiers concernés, un diff proposé non appliqué et un protocole de vérification à exécuter ultérieurement par une personne autorisée. Pour chaque test proposé, indique l’objectif, les prérequis et le résultat attendu. Signale explicitement les éléments non vérifiables sans exécution.

Relis les trois paires A3. Pour chacune, identifie la situation concrète décrite et vérifie qu’elle ne se réduit pas à une capacité technique. Cherche explicitement chiffres, délais, promesses, causalité et témoignages non documentés. Vérifie que « Avant » précède « Après » dans l’ordre de lecture. Rends un verdict par paire puis un verdict global : conforme, à corriger, ou non vérifiable.

Teste A3 en environnement local ou de prévisualisation, sans action externe. À 390 px et 1440 px, contrôle l’ordre de lecture, les intertitres, les retours à la ligne, la lisibilité, la hauteur du premier écran, le maintien du H1 et du CTA, ainsi que l’absence de débordement horizontal. Vérifie au clavier que le contenu n’est pas dépendant de la couleur ou d’icônes seules. Retourne les résultats avec capture ou référence de preuve disponible.

Évalue si une seconde preuve peut être intégrée dans la section #preuve de quentinlecocq.com.

Préconditions obligatoires : preuve réelle, consentement, attribution validée et anonymisation si nécessaire. N’invente ni témoignage, ni résultat, ni consentement, ni attribution.

Entrées :
- Preuve source : [COLLER]
- Autorisation traçable : [COLLER]
- Attribution autorisée : [COLLER]
- Contexte minimal : [COLLER]
- Éléments anonymisés : [COLLER]

Si une précondition manque ou n’est pas prouvée, réponds exactement : « A4 non intégrable à ce stade : [précondition manquante] ». Ne rédige aucun bloc de remplacement.

Si toutes les préconditions sont prouvées, propose un bloc distinct concis contenant uniquement le contenu documenté, son attribution autorisée et son contexte minimal. Vérifie explicitement qu’il ne généralise pas, ne chiffre pas et ne prétend pas à une causalité au-delà de la source.

Inspecte d’abord le dépôt réel pour localiser la section #preuve, sa structure de contenu, les composants existants de témoignage ou de preuve, les conventions d’accessibilité et le comportement responsive. Ne déduis aucune structure privée du DOM public.

Cette demande est de revue uniquement : ne modifie aucun fichier du dépôt, ne lance aucune commande, aucun test, aucun serveur local ou aperçu, ne consulte pas d’environnement distant et n’effectue aucune action externe. Toute application nécessite une instruction humaine distincte.

Avant de planifier un diff, vérifie les préconditions documentaires : preuve réelle, consentement, attribution validée et anonymisation si nécessaire. Si l’une manque, arrête le travail et retourne « A4 non intégrable à ce stade », avec le prérequis manquant. Ne crée aucun placeholder ni faux bloc.

Si toutes les préconditions sont satisfaites, présente avant toute modification :
1. un plan concis ;
2. les fichiers concernés ;
3. un diff minimal ajoutant un bloc de preuve distinct ;
4. les tests de lisibilité, d’attribution et de responsive.

Contraintes :
- conserve la source, l’attribution autorisée et le contexte minimal ;
- ne formule aucun résultat généralisé, chiffré ou causal au-delà du contenu réellement documenté ;
- associe explicitement contenu, attribution et contexte ; tout visuel a un alt utile ou est décoratif ;
- à 390 px et 1440 px, le bloc est lisible, attribution visible, sans débordement ;
- ne contacte personne, ne publie pas, ne déploie pas, ne crée pas de pull request et ne merge pas.

Retourne uniquement le plan, les fichiers concernés, un diff proposé non appliqué et un protocole de vérification à exécuter ultérieurement par une personne autorisée. Pour chaque test proposé, indique l’objectif, les prérequis et le résultat attendu. Signale explicitement les éléments non vérifiables sans exécution.

Relis A4 avec une posture de contrôle de preuve. Vérifie la trace de réalité, l’autorisation, l’attribution et l’anonymisation avant de commenter le style. Compare chaque affirmation au verbatim ou document source. Marque comme bloquante toute généralisation, tout chiffre, toute causalité, toute attribution ou tout consentement non prouvé. Confirme aussi qu’aucun bloc n’a été créé si les préconditions sont absentes. Donne un verdict : intégrable, à corriger, ou non intégrable à ce stade.

Réalise une QA locale A4 sans contacter, publier, envoyer ni appeler de service externe. Vérifie la présence conjointe du contenu, de son attribution autorisée et de son contexte, ainsi que l’alt si un visuel est présent. À 390 px et 1440 px, contrôle lisibilité, densité, ordre de lecture, visibilité de l’attribution et absence de débordement. Sépare les résultats de rendu des validations documentaires qui relèvent d’un humain.

Tu clarifies les termes techniques de quentinlecocq.com dans #anatomie, #methode, #perimetre et #preuve.

Pour chaque terme ciblé présent dans les extraits fournis, conserve le terme quand il est utile puis ajoute, à sa première occurrence, une conséquence courte et factuelle pour le lecteur. Les termes ciblés sont : vault, versionné, infra, socle et garde-fou.

Entrées :
- Extraits source : [COLLER]
- Ton et terminologie à préserver : [COLLER]
- Termes réellement présents : [COLLER]

Retourne un tableau terme / extrait original / réécriture proposée / conséquence utile. Ne réécris pas une promesse commerciale, n’ajoute aucun gain, délai ou résultat, et ne fournis pas d’explication dans une infobulle. Signale tout terme absent plutôt que de l’inventer.

Inspecte d’abord le dépôt réel pour localiser l’origine ou la centralisation du contenu de #anatomie, #methode, #perimetre et #preuve. Recherche les occurrences réelles de vault, versionné, infra, socle et garde-fou, ainsi que les composants ou données partagés qui les rendent.

Cette demande est de revue uniquement : ne modifie aucun fichier du dépôt, ne lance aucune commande, aucun test, aucun serveur local ou aperçu, ne consulte pas d’environnement distant et n’effectue aucune action externe. Toute application nécessite une instruction humaine distincte.

Avant toute modification, fournis :
1. un plan concis ;
2. un inventaire terme / première occurrence / fichier ou source concernée ;
3. un diff minimal contenant seulement les explications éditoriales validées ;
4. les tests de contenu et de rendu à exécuter.

Contraintes :
- chaque terme ciblé présent dans le périmètre reçoit une conséquence utile à sa première occurrence ;
- garde des mots compréhensibles dans le texte courant, sans réserver l’explication à une infobulle inaccessible au clavier ;
- n’ajoute aucune promesse de gain, délai ou résultat ;
- contrôle les retours à la ligne à 390 px et 1440 px ;
- ne publie pas, ne déploie pas, ne crée pas de pull request et ne merge pas.

Retourne uniquement le plan, les fichiers concernés, un diff proposé non appliqué et un protocole de vérification à exécuter ultérieurement par une personne autorisée. Pour chaque test proposé, indique l’objectif, les prérequis et le résultat attendu. Signale explicitement les éléments non vérifiables sans exécution.

Relis A5 en comparant chaque terme ciblé au texte source réel. Vérifie que chaque terme présent reçoit, à sa première occurrence, une conséquence utile, compréhensible et factuelle. Cherche les gains, délais, résultats ou promesses introduits par la réécriture. Contrôle qu’aucun terme absent n’a été ajouté. Retourne un tableau terme / conforme / correction nécessaire / justification.

Effectue une QA locale A5. Recherche dans le rendu les occurrences de vault, versionné, infra, socle et garde-fou, puis vérifie l’explication associée à leur première occurrence. À 390 px et 1440 px, contrôle les retours à la ligne, la lisibilité et l’absence de débordement horizontal. Vérifie aussi au clavier que les explications utiles sont disponibles dans le texte courant. Retourne les preuves disponibles et les écarts.

Tu aides à classer les textes de quentinlecocq.com avant une correction typographique A6. Ne propose aucun style ni code tant que l’inventaire n’est pas complet.

Entrées :
- Extraits ou captures des sections #anatomie, #perimetre et #preuve : [COLLER]
- Inventaire initial : [COLLER]

Pour chaque texte, classe-le en :
- « porteur de sens » s’il est nécessaire pour comprendre une description, un mode de permission, une légende utile ou un texte de preuve ;
- « repère décoratif » s’il s’agit uniquement d’un numéro, séparateur ou repère non nécessaire à la compréhension ;
- « à valider » si le rôle est ambigu.

Retourne un tableau texte / section / classification / justification. Ne conclus pas qu’un texte est décoratif parce qu’il est petit, et ne formule aucune modification globale non vérifiée.

Inspecte d’abord le dépôt réel pour inventorier les textes de #anatomie, #perimetre et #preuve, leurs composants, styles calculés, variables globales et classes locales. Distingue les textes porteurs de sens des repères décoratifs avant toute proposition de style. Ne suppose pas que les variables ou classes observées publiquement ont la même portée dans le dépôt.

Cette demande est de revue uniquement : ne modifie aucun fichier du dépôt, ne lance aucune commande, aucun test, aucun serveur local ou aperçu, ne consulte pas d’environnement distant et n’effectue aucune action externe. Toute application nécessite une instruction humaine distincte.

Avant toute modification, fournis :
1. un plan concis ;
2. un inventaire texte / rôle / style actuel / composant ou fichier ;
3. une analyse des variables globales et classes locales potentiellement touchées ;
4. un diff minimal ciblant uniquement les textes informatifs à 14 px minimum ;
5. les tests de styles calculés et de responsive à exécuter.

Contraintes :
- chaque texte informatif ciblé doit s’afficher à 14 px minimum ;
- ne modifie pas par défaut les numéros, séparateurs et repères purement décoratifs ;
- ne fais pas de hausse globale non vérifiée ;
- préserve contraste, interlignage et ordre de lecture ;
- à 390 px et 1440 px, aucune carte, section ou texte ciblé ne déborde, ne se chevauche ou ne devient tronqué ;
- ne publie pas, ne déploie pas, ne crée pas de pull request et ne merge pas.

Retourne uniquement le plan, les fichiers concernés, un diff proposé non appliqué et un protocole de vérification à exécuter ultérieurement par une personne autorisée. Pour chaque test proposé, indique l’objectif, les prérequis et le résultat attendu. Signale explicitement les éléments non vérifiables sans exécution.

Relis A6 à partir de l’inventaire et du rendu. Vérifie que chaque texte modifié est bien porteur de sens et qu’aucun repère décoratif n’a été modifié par défaut. Pour chaque élément informatif ciblé, contrôle la taille calculée à 14 px minimum. Signale toute généralisation de style non justifiée, toute baisse de contraste ou tout changement d’ordre de lecture. Rends un verdict : conforme, à corriger, ou non vérifiable.

Effectue une QA locale A6, sans toucher à la production. À 390 px et 1440 px, contrôle les styles calculés des textes informatifs ciblés, leur taille minimale de 14 px, le contraste, l’interlignage, l’ordre de lecture, les cartes, les sections longues et l’absence de chevauchement, troncature ou débordement horizontal. Vérifie que les repères décoratifs non ciblés n’ont pas été modifiés par défaut. Retourne un inventaire de contrôle avec preuve disponible, résultat et anomalie.