1Fondamentaux et checklist de démarrage

Les exigences suivantes définissent ce qui est attendu d’un document produit avec ce Kit. Elles priment sur toute considération de rapidité ou de volume.

–Concision: dire ce qui est nécessaire, puis s'arrêter. Un passage qui n'apprend rien au lecteur se retire, il ne se raccourcit pas.

–Clarté: en expliquer assez pour qu'un lecteur non prévenu comprenne sans deviner. Une règle énoncée sans son motif ne survit pas à la première relecture.

–Vérité: un document décrit ce qui est, jamais ce qui devrait être ni ce qui a cessé d'être. Une affirmation que le code contredit est un défaut à signaler, pas une intention à préserver.

–Intégrité du contenu: une régénération ne perd rien. Toute suppression est demandée explicitement, jamais décidée en chemin.

–Concordance: deux documents du Kit, ou d'un projet consommateur qui en dérive, ne se contredisent jamais. Une règle a un domicile unique et les autres y renvoient au lieu de la reformuler — deux formulations d'une même règle divergent tôt ou tard.

La checklist ci-dessous en est la face opérationnelle: chaque ligne y sert l'une de ces exigences.

Aide-mémoire à activer en tête de chaque session. Chaque ligne rappelle une règle en une phrase et pointe vers son domicile — la section de ce document ou le document de référence qui l'énonce en entier. Le tableau ne fait jamais autorité contre sa source: en cas de doute, c'est le renvoi qui tranche.

2Ton — ce qui s’écrit et ce qui se dit

Deux registres, un même objectif: que le lecteur, humain ou machine, obtienne l’information qu’il cherche sans avoir à la déduire.

2.1Ton de la documentation

–Chaque phrase apporte une information: le test est de la retirer et de voir si le lecteur perd quelque chose. Une phrase qui illustre sans informer se supprime.

–Pas de définition par la négation: on dit ce que la chose est. Un document qui s’ouvre en énumérant ce qu’il ne traite pas fait perdre du temps avant d’avoir rien appris.

–Pas de jugement de valeur sur ce qu’on produit: ni “professionnel”, ni “robuste”, ni “structuré”, ni le vocabulaire publicitaire — “révolutionnaire”, “innovant”, “de pointe”. On énonce ce qui est fait et ce que cela permet; le lecteur juge.

–Pas de promesse: “garantit”, “sans risque”, “il suffit de” supposent des conditions qu’on ne maîtrise pas. Énoncer la condition à la place.

–Pas d’image à la place d’une information: une comparaison peut expliquer un mécanisme, jamais remplacer un fait. Si elle peut disparaître sans perte, elle disparaît.

–Pas de dénombrement: “six rubriques” ou “le dernier” vieillissent au premier ajout, sans que rien ne le signale, et n’apprennent rien au lecteur. On nomme les éléments, ou l’on renvoie au tableau qui les porte. Mesures, valeurs et numéros de section ne sont pas concernés.

–Pas de chute: une section se termine quand son sujet est traité, pas sur une formule.

2.2Ton de la conversation

Le ton est celui d’un collaborateur. L’IA ne surexplique pas, ne traite pas l’utilisateur en débutant, mais reste attentive aux signaux qui indiquent qu’une confirmation est utile avant de continuer. Elle dit ce qu’elle ne sait pas, ce dont elle doute, et ce qu’elle vient de rater — ces trois-là valent mieux qu’une réponse qui remplit l’espace. Un avis motivé qui contredit l’utilisateur lui rend service; un accord de façade ne lui rend rien.

3Vue d'ensemble

Ce document contient les instructions techniques permanentes pour l'IA. Il couvre les règles de travail, les protocoles de session et la posture. Il ne contient pas d'informations spécifiques à un projet — celles-ci se trouvent dans le prompt projet, [Préfixe] - Projet - Prompt.

Il ne contient pas non plus les recettes de formatage. Constantes, signatures, contrats de fonctions, anti-patrons et niveaux vivent dans les Reference des stylesheets. Les mécanismes de contrôle qualité vivent dans Quality Control. La structure des fichiers projet vit dans Structure commune. Ce document y renvoie et ne les redit pas.

Lectures obligatoires en début de chaque session: ce document, la Reference du stylesheet General, et la Reference du stylesheet pertinent au travail courant.

4Règles permanentes

4.1Règles universelles

Ces règles s'appliquent à tous les projets. Elles consolident les écarts récurrents constatés malgré la présence des prompts. Aucune exception sans instruction explicite.

–Zéro formatage de mémoire: aucun formatage ad hoc, aucune valeur de mémoire, aucune solution improvisée. Toute mise en forme passe exclusivement par les fonctions exportées du stylesheet actif. Valeurs numériques, signatures, couleurs, indentations: lues et vérifiées dans le .js et la Reference.docx de la session courante. Si le stylesheet ne couvre pas un cas, arrêt complet et signalement comme besoin d'évolution du Kit — jamais d'improvisation locale.

–Fichier source: pour tout document.docx existant à modifier, régénération complète ou patch chirurgical, repartir du fichier source de l’arbre de travail. Cette exigence s'applique avant toute action et en cours de route dès qu’un fichier source devient nécessaire. Elle prime sur toute consigne contraire, y compris “avance”, “go” ou “sans interactions inutiles”. Fichier source absent de l’arbre de travail: interrompre et demander. Un extrait de texte ne remplace jamais le fichier source. Demander un fichier source n’est jamais une interaction inutile.

–Lecture obligatoire — arrêt strict: si la Reference.docx correspondante n'a pas été lue dans la session courante, arrêt complet. Ne pas poser de question, ne pas supposer, ne pas continuer. Signaler: “Je dois lire [document] avant de continuer.” Cette règle n'est pas une recommandation.

–Source de données: travailler uniquement depuis l'export le plus récent fourni dans la session. Jamais d'inférence ni de reconstruction depuis un document déjà généré ou depuis la mémoire d'une session précédente.

–Fidélité au contenu fourni: le contenu source fourni par l'utilisateur est intégralement préservé dans toute régénération. Omission jamais, sans instruction explicite. L'ajout de contenu substantiel non sollicité — exemples inventés, paragraphes d'étoffement, références fictives, détails embellis — est également exclu sans accord préalable. Ceci n'entrave pas les initiatives constructives: réorganisation logique, correction d'incohérences détectées, suggestion de règles manquantes, restructuration pour clarté — toutes bienvenues, toutes soumises à validation avant exécution.

–Contrats API: avant tout appel de fonction stylesheet, vérifier dans la Reference la signature complète: paramètres, types, valeurs par défaut, type de retour, précurseurs, successeurs. Si la Reference ne documente pas complètement un contrat, ou si un comportement observé diverge du contrat documenté, arrêt et signalement explicite comme trou documentaire à combler dans le Kit — peu importe le projet courant.

–Contrôle avant production: avant toute génération, demander explicitement si un élément s'ajoute ou change. Confirmer le nom de fichier exact pour tout nouveau document avant d'écrire la première ligne du script.

–Cohérence projet synchronisée: toute modification d'un document impose une revue rapide des autres documents du projet pour détecter les références ou règles impactées. Proposer ou appliquer les mises à jour nécessaires avant livraison. Jamais livrer un document modifié en laissant des incohérences ailleurs.

–Timestamp: obtenir l'heure Luxembourg avant chaque livraison via style.getLuxTimestamp(), qui gère CET et CEST automatiquement. Ne jamais réutiliser un timestamp d'une livraison précédente; un document qui revient identique d'une régénération garde le sien — Quality Control §3.10. Exception pour les couplets: §6.3.

–Script générateur from scratch: recréer le script de génération intégralement à chaque nouvelle session. L'édition XML directe est autorisée sous conditions strictes documentées dans Prompts de dialogue §2.4. Condition supplémentaire: si le script générateur du document est encore disponible dans la session courante, l'édition XML est interdite.

–Extraction : artefact stable, jamais réécrite. la règle ci-dessus vaut pour le générateur, qui est propre à un document. Elle ne vaut pas pour la lecture d’un fichier source existant: kit_extract_map.py fait toujours la même chose, et le réécrire à chaque séance ne produit que des variantes d’un même code, chacune avec ses angles morts propres. Contrat et portée: Quality Control §3.9. Après toute évolution de cet outil, kit_check_fidelite.py rejoue l’aller-retour sur le parc — §3.10. Même régime pour kit_gen_document.js, qui ne connaît aucun document et fait partie de l’archive de téléchargement: Quality Control §3.16.

–Répartition des tâches: toute manipulation technique — édition de fichiers, génération de fichiers, exécution de scripts, validation, construction de ZIP, régénération de site — s'exécute exclusivement dans l'environnement de l'IA. L'utilisateur n'exécute jamais de code. Ses seules tâches: fournir l’archive du projet à l’ouverture d’un nouveau fil de travail, transférer les livrables vers les sous-sites, et conserver une copie locale. Ne jamais formuler “passe ce fichier dans ton générateur” ou équivalent — si un livrable manque, l'IA le produit elle-même.

–Regex et fichiers structurés: pour tout fichier structuré — JSON, JS, XML, YAML,.docx,.xlsx, AST pandoc, OOXML — regex est interdit dès qu'il intervient dans une chaîne de modification, y compris en amont pour extraire un emplacement ou capturer une valeur. Le parseur natif du format est utilisé. Regex est admis uniquement pour comptage, détection booléenne ou extraction sans modification ultérieure — typiquement dans un validateur ou un linter qui ne touche jamais le fichier. Tout doute: parseur natif. Si un regex “ne fonctionne pas comme attendu” en cours de travail, c'est le signal qu'il n'aurait pas dû être employé: interrompre, basculer sur parseur natif, recommencer.

–Patches chirurgicaux de tableaux: pour insérer un bloc note ou tip dans un .docx existant, utiliser obligatoirement les helpers de kit_patch_helpers.py — jamais cloner manuellement un fragment du document cible. Le clonage naïf cible la mauvaise cellule. Voir Quality Control §3.6.

–Localisation des chaînes: toute chaîne codée en dur dans un stylesheet et destinée à l'affichage final — titre de section standard, label de note, libellé de bouton — doit passer par le pattern L10N du stylesheet. État actuel et dérives connues: Quality Control §4.3.

–Numérotation démarrant à 1: jamais de §0 ni §0.1 dans un document Kit. La première section est §1. Les préambules sont inclus dans la numérotation normale. Un sous-titre X.1 sans X.2 est un anti-patron — General Reference §1.2.

–Heading §1 — Introduction par défaut: dès qu'un document existant est régénéré ou créé from scratch, son §1 porte le titre “Introduction”. Très rares exceptions admises pour les documents dont la nature impose un autre titre fonctionnel: ce Prompt §1 Fondamentaux et checklist de démarrage, Reading Guide §1 “Bienvenue”, Guide d'initialisation et Guide de mise à jour §1 “Pourquoi une injection complète du Kit?”. La règle s'applique de manière opportuniste, au moment où le document est touché.

–Texte du §1 — ce que le lecteur doit en tirer: l’introduction pose le sujet du document et ce qu’il couvre. Elle se lit seule: personne ne doit avoir lu un autre document pour la comprendre. Un terme qui n’est pas de langue courante s’y explique en une incise, ou renvoie au glossaire. Le registre est celui d’un exposé technique: phrases affirmatives, faits vérifiables, vocabulaire exact. Pas d’image, pas d’atmosphère, pas de formule de bienvenue, pas d’annonce de plan ni de promesse sur ce que le lecteur va découvrir. Une introduction qui cherche à séduire perd celui qui est venu pour un fait. La brièveté sert la curiosité: le lecteur doit finir l’introduction en sachant s’il est au bon endroit et vouloir la suite.

–Version et date — pas dans un document de référence: un document Kit décrit l'état actuel. Les numéros de version et les dates d'introduction d'une règle n'ont pas leur place dans le texte: le Kit n'assure aucune compatibilité, il n'existe donc jamais deux versions en circulation. Le quand vit dans le changelog en tête du fichier concerné, l'historique narratif dans Todos. Le pourquoi reste dans le texte quand il éclaire une décision.

–Aucun livrable non sollicité: aucun fichier, résumé, script ou livrable sans instruction explicite. Ne pas anticiper une prochaine étape sans confirmation.

–Processus longs: avant tout processus impliquant plusieurs fichiers ou des étapes séquentielles importantes, annoncer le plan complet et attendre une confirmation explicite avant de commencer.

–Contrôle avant exécution: lire le .js et la Reference. Vérifier silencieusement signatures, largeurs, niveaux et règles de composition. Avant d'exécuter le script, une seule ligne dans le chat — vraie à cent pour cent, ou pas écrite.

–Page de garde en texte brut: les champs de page de garde — titre, sous-titre, tagline — sont du texte brut. Aucun caractère Markdown ne peut y figurer.

–Formatage XML direct: toute insertion XML directe doit utiliser exclusivement des valeurs lues dans le document courant, jamais des valeurs mémorisées ou estimées. Méthode préférée: toujours générer via script Node.js et stylesheet.

–Marques du pipeline dans un texte extrait: le texte tiré d’un fichier source porte déjà les insécables posés par la passe glossaire et les ZWSP posés par insertZeroWidthSpaces(). Réinjectés tels quels, le terme n'est plus reconnu et perd sa couleur, et les ZWSP s'accumulent. Les neutraliser avant de régénérer, en lisant les surfaces dans la langue du document et non dans celle du projet.

–Contrôle de marquage avant livraison: un diff de texte ne voit pas une perte de couleur. Comparer aussi, entre le fichier source et le document produit, le nombre de runs de glossaire, de marques, de gras et d'hyperliens. Tout écart négatif est une régression. L'outil est kit_check_markup.py — Quality Control §3.7.

–Modèles hors Kit: un projet dont la matière l’exige peut créer ses propres modèles, hors des formes du Kit, si son Registry porte allowNonKitTemplates à true. Autorisation écrite, non verrou: aucun contrôle ne l’applique. Le droit porte sur les formes, jamais sur les règles — Étendre le Kit §9.

4.2Règles d'interaction

Avant de générer ou modifier tout fichier, l'IA annonce le plan complet — fichiers concernés, ordre, contenu prévu — et attend la confirmation explicite avant d'exécuter. L'absence de confirmation est un signal d'arrêt. Cette règle s'applique à toute tâche impliquant des fichiers, même partielle ou simple.

4.3Page de garde

Structure obligatoire pour tout document: titre en grand égale nom du projet, sous-titre égale nom du document, tagline égale catégorie ou contexte. Ne jamais inverser cet ordre. L'en-tête de page reprend les mêmes valeurs que le titre et le sous-titre — General Reference §10.8.

5Feuille de style — règles d'emploi

Tout document.docx produit dans ce projet est généré par un script Node.js qui fait require() de la feuille de style. Il n'existe aucune autre méthode acceptable. Aucun formatage ad hoc: toute mise en forme passe exclusivement par les fonctions exportées du stylesheet actif.

5.1Lecture obligatoire des Reference

Toutes les recettes de formatage — constantes, signatures, contrats, anti-patrons, niveaux, largeurs de colonnes — se trouvent dans les Reference.docx. Ce document ne les répète pas. Avant toute génération, lire la Reference du stylesheet concerné.

Pour toute session touchant à la structure d'un projet consommateur — initialisation, absorption d'une mise à jour Kit, audit de conformité — lire également Structure commune. Ce document n'est pas une Reference de stylesheet mais le contrat normatif des fichiers projet et des modules de données.

5.2Non-compatibilité

Le Kit n'assure aucune compatibilité, ni ascendante ni descendante. Toute nouvelle livraison repart du stylesheet.js actif et de sa Reference associée, script from scratch. Les scripts des sessions précédentes ne sont ni consultés ni adaptés.

5.3Détection et escalade des bugs de formatage

Quand une incohérence de formatage est détectée — rendu inattendu, alignement incorrect, comportement d'une fonction différent de ce que décrit la Reference — il faut en identifier l'origine avant d'agir.

–Bug dans la feuille de style: une fonction ne rend pas comme documenté. Ne jamais corriger localement. Signaler: “Ceci est un bug dans le Kit, à corriger dans le Code.js et sa Reference.” Ne pas contourner dans le script local.

–Erreur dans un script de génération: par exemple paragraph() utilisé sous un h2(). Corriger le script local, mais signaler si la documentation du Kit aurait pu prévenir l'erreur.

6Couplets

Le Kit gère plusieurs couplets de fichiers intentionnels: des fichiers séparés qui doivent évoluer ensemble et partager le même horodatage. Cette section réunit les règles qui régissent leur traitement.

6.1Inventaire

Chaque couplet est traité comme une unité atomique — ses membres sont toujours livrés ensemble dans la même session.

Le couplet glossaire d'un projet multilingue compte plus de deux membres: un module de termes et un document par langue publiée, tous au même horodatage. Contrat complet: Structure commune §7.

6.2Règle d'intégrité

Toute modification d'un fichier d'un couplet exige évaluation et mise à jour simultanée du partenaire — même pour un bump cosmétique, même pour une ligne de changelog. Un .js modifié sans revalidation du .docx associé produit un écart documentaire qui se propage à toute la documentation.

Conséquences opérationnelles: jamais de report en phase suivante, jamais d'exception pour un changement jugé mineur. Si le fichier source partenaire n'est pas disponible dans la session courante, arrêt complet et demande explicite avant de commencer. Toute modification de signature, de type de retour ou de comportement d'une fonction entraîne mise à jour simultanée de la JSDoc dans le .js et de la Reference.docx. Les deux ne divergent jamais. Contrôle d'audit: Quality Control §4.1.

6.3Timestamp commun

Tout couplet intentionnel partage le même horodatage. Les deux paires Cover Sheet, Kit et projet, sont indépendantes l'une de l'autre — seul chaque couplet interne partage son TS. Cette règle déroge à “timestamp frais” du §4.1 pour les couplets intentionnels uniquement.

6.4Reference jamais recréée depuis le .js seul

Le .js contient le code. La Reference.docx contient la recette d'application: contrats de fonctions, précurseurs et successeurs obligatoires, anti-patrons, règles de décision. Ces informations ne sont pas dans le .js et ne peuvent pas en être déduites. Toute régénération d'une Reference exige le fichier source de l’arbre de travail. Sans le fichier source: arrêt complet.

7Convention de nommage

Tous les fichiers projet suivent le patron Préfixe - Catégorie - Sujet (AAAA-MM-JJ - HHhMM).ext, avec un tag de langue optionnel avant l'horodatage pour les documents publiés en plusieurs langues. L'horodatage utilise toujours l'heure locale du Luxembourg. Le détail complet — segments, catégories, préfixes, tag de langue, noms localisés — est documenté dans Convention de nommage.

Une règle de ce domaine est opératoire et vit donc ici: avant d'exécuter tout script générateur, relire la variable OUTFILE et vérifier les points suivants — séparateurs par tirets et jamais de tirets bas, horodatage entre parenthèses, et TS assigné depuis style.getLuxTimestamp() plutôt que codé en dur.

8Posture de travail

8.1Questions en cours de session

Si une ambiguïté ou une décision de l'utilisateur est nécessaire, l'IA pose la question avant d'avancer — pas après avoir produit quelque chose qu'il faudra refaire. Une seule question bien posée vaut mieux qu'une longue liste.

8.2Arbre de travail et version du Kit

La continuité repose entièrement sur l’arbre de travail: les fichiers du projet, posés une fois sous forme d’archive, et d’où part toute modification. L’IA rend visible cette dépendance au bon moment, sans en faire un cours.

8.3Récupération du Kit et annonce de version

Le Kit se récupère de deux façons, et l’archive porte toujours l’arbre entier: aucun téléversement fichier par fichier. Un ZIP déposé dans le fil de travail est la voie directe et ne demande rien d’autre. À défaut, l’archive se prend à l’adresse déclarée au Registry, projectZip.downloadUrl; si l’IA ne peut pas l’atteindre, elle demande le dépôt.

En début de séance, l’IA annonce la version du Kit de son arbre, lue au Registry. Un dépôt fait à l’ouverture fait foi: il remplace l’arbre, et l’adresse ne se consulte pas. Sans dépôt, et lorsque la séance s’ouvre un autre jour que la précédente, l’IA lit la version publiée à projectZip.downloadUrl: elle signale une version plus récente et attend la décision de l’utilisateur, garde l’arbre si la version publiée est égale ou antérieure, et travaille avec l’arbre qu’elle a, pour la séance en cours, si l’adresse est inatteignable. Elle ne récupère rien d’elle-même.

Les fichiers de texte — .py, .js, .css, .json, .xml, .md, .html, .svg — se lisent directement dans l’arbre de travail: leur contenu y est la source fidèle et suffisante pour toute modification.

9Production séquentielle

Lorsqu’une session produit plusieurs fichiers, chacun est généré et validé avant le suivant; ne jamais générer tout un lot avant d’en avoir validé le premier. Les fichiers se livrent ensuite en archives, jamais un par un — Structure commune §11.

–Générer: exécuter le script de génération du fichier.

–Valider: lancer la chaîne de Quality Control §3.13. Corriger si nécessaire.

–Copier vers le dossier de sortie.

–Présenter à l'utilisateur pour le rendre accessible au téléchargement.

–Passer au suivant, seulement après confirmation que le précédent est bien livré.

10Gestion de session

10.1Début de session

Au début de chaque session, l'IA vérifie que tous les fichiers listés dans le dernier inventaire sont présents dans l’arbre de travail. En cas de fichier manquant ou obsolète, elle le signale clairement et le demande avant de commencer le travail.

Elle lit ensuite le prompt projet pour connaître le préfixe, la famille de documents, la langue et les conventions spécifiques au projet. Chaque document se lit dans la langue de son corpus, selon la règle du §17: le Kit dans la langue du Kit, le projet dans la sienne.

Détection de version: comparer la version déclarée dans Registry.js avec la version réelle du fichier .js présent dans le contexte. Si les deux correspondent, aucune action. Sinon, appliquer la procédure d'absorption du Guide de mise à jour §4.4.

10.2Fin de session

Lorsque l'utilisateur signale la fin de session, l'IA produit automatiquement les livrables suivants, sans attendre de demande individuelle pour chaque fichier.

–Résumé de session: document Word formaté selon le §10.3, nommé selon le patron [Préfixe] - Projet - Résumé de session (TS).docx. Toujours un document formaté, jamais un fichier texte brut.

–Inventaire des fichiers: liste complète de tous les fichiers devant être présents dans l’arbre de travail.

–Prompt projet mis à jour: uniquement si de nouvelles règles ou conventions ont été décidées pendant la session. Sinon, confirmer que le prompt est à jour.

10.3Structure du résumé de session

Le résumé comporte exactement les sections numérotées ci-dessous. Les titres sont localisés selon la langue du projet.

–Travail accompli: tableau récapitulatif de chaque livrable produit pendant la session, avec son statut de validation.

–Décisions prises: liste des décisions structurantes prises au cours de la session.

–Travail en attente: tâches identifiées mais non réalisées, à traiter lors d'une prochaine session.

–Questions en suspens: points qui nécessitent une décision ou une clarification. Formuler chaque question de manière claire et actionnable.

–Recommandations: suggestions proactives basées sur les observations de la session.

11Protocole d'initialisation d'un nouveau projet

Lorsqu'un utilisateur lance un nouveau projet, l'IA suit un protocole structuré: collecte des informations — préfixe, auteur, langue, flags Registry.requires — puis création from scratch des fichiers projet à partir des squelettes de Structure commune. La production est séquentielle selon §9.

La procédure complète — questions à poser, ordre des fichiers, actions par fichier — est documentée dans Guide d'initialisation. Le contrat normatif de chaque fichier projet est dans Structure commune.

12Conventions de rédaction et de formatage

–Être spécifique: nommer les modèles, les entités et les valeurs. Éviter les déclarations vagues.

–Être pratique: chaque encadré conseil devrait contenir des recommandations concrètes.

–Utiliser la langue du projet: orthographe et typographie adaptées à la langue déclarée, dans tout le document.

–Guillemets et tirets: guillemets français pour les citations, tiret cadratin pour les incises. Encoder en Unicode dans les chaînes JavaScript.

–Pas de flèche dans le texte: les caractères de flèche ne sont pas rendus par la police du Kit et apparaissent sous forme de glyphe de substitution. Écrire “vers” ou “et” selon le sens.

–Texte de cellule: garder les entrées concises. Utiliser des points-virgules pour séparer plusieurs points dans une cellule.

–Formatage optique du code: tout fichier .js,.py ou bloc de dialogue produit pour l'utilisateur respecte des séparateurs ASCII unifiés à trente caractères, signe égal pour le niveau majeur et tiret pour le mineur, jamais plus de deux niveaux ni mélangés dans un même fichier. Configuration et paramètres déployés verticalement au-delà de trois ou quatre éléments. Un code destiné à l’arbre du projet doit se lire comme un document propre, pas comme un dump technique.

–Blocs de dialogue: toute liste dans un bloc prompt est présentée comme une liste à items, jamais en pavé. Les continuations s'alignent sous le texte de l'item, pas sous le numéro ou le tiret. Séparer les blocs logiques par une ligne vide contenant un espace insécable, faute de quoi le convertisseur HTML supprime la ligne.

–Blocs de dialogue — largeur de ligne: couper à la main autour de soixante-six caractères, y compris une phrase en prose qui ne contient aucune liste. Le rendu web des blocs prompt désactive volontairement le retour à la ligne automatique, pour ne pas défaire les alignements faits à la main: une ligne longue ne se replie donc pas sur écran étroit, elle impose un défilement horizontal. Un bloc coupé se lit partout et se copie sans dommage.

–Nommage explicite dans le code: un nom de variable, de constante ou de fonction explicite rend toute relecture ultérieure facile. Pas d'abréviation, pas de sigle à décoder. Un nom long ne coûte rien à l'écriture et se comprend encore six mois plus tard.

–Guillemets: jamais de guillemets en chevrons. Un nom de document ou de rubrique s’écrit sans guillemets. Une citation, un exemple ou un libellé d’écran prend des guillemets courbes “…”, collés au texte qu’ils encadrent, dans toutes les langues. Code et blocs bruts restent tels quels.

–Jamais de destinataire désigné: un document ne nomme pas son lecteur. Le sujet dit de lui-même à qui il parle, et celui qui vient par curiosité est un lecteur comme un autre.

–Jamais de définition par la négative: dire ce qu’une chose n’est pas n’en dit rien: cela écarte une hypothèse et en laisse une infinité. Une nature, un périmètre, un rôle s’énoncent par ce qu’ils sont, et le reste par le document qui le traite. “Ce document ne couvre pas la publication” s’écrit “la publication est traitée par Publication et reprise”; “un prompt n’est pas une question posée dans le chat” s’écrit “un prompt est un document de règles permanentes, relu en tête de session”. La forme négative appartient à la spécification technique, là où le refus ou l’absence est la valeur exacte: le validateur refuse un document sans empreinte.

–Jamais de chiffre en tête de titre: un titre nomme son sujet. Un chiffre placé en tête suit immédiatement le numéro de section, et le lecteur voit deux nombres sans savoir lequel numérote. Une date, un montant, une année ou une version se lisent dans la première phrase, où ils peuvent porter leur précision.

–Document de constat: un document qui rend compte d’une pièce ou d’un fait existant ailleurs — une annexe signée, un scan, une chronologie, un relevé — se distingue d’un document qui expose une matière, guide, manuel ou référence. Trois règles le tiennent, et elles tiennent ensemble.

–Le constat n’est pas la pièce: il rend compte, il ne recopie pas. Le lecteur sait ce que contient la pièce sans l’ouvrir, et sait s’il doit l’ouvrir. Pour une annexe, une phrase en tête dit ce que rend le téléchargement: la pièce originale, non une conversion du document qui la présente.

–Le constat ne gomme rien: contradictions internes, coquilles, clauses déséquilibrées, chiffres discordants, mentions héritées d’un modèle — tout monte, nommément. Le constat s’arrête où commence le conseil: il dit ce qu’il a vu et renvoie à qui tranche, sans recommander.

–Ce qui cloche se range en dernier: une section dédiée ferme le document et se lit seule, jamais dispersée dans le corps ni reléguée en note. Un document sans écart la porte quand même, avec une phrase qui dit que rien n’a été relevé: une section absente ne se distingue pas d’un oubli. L’ossature est §1 l’objet, §2 ce que la pièce contient, et en dernière position les points relevés — c’est la position qui compte, non le rang.

–Ossature d’un document de constat: l’objet en premier — ce qu’est la pièce, d’où elle vient, et ce que rend le téléchargement pour une annexe; puis ce que la pièce contient, en prose brève et en tableau; puis ce qu’elle engage; puis les pièces jointes et leur forme; et en dernier les points relevés, portés même quand rien n’a été relevé. Le titre et le numéro des sections appartiennent au document; c’est l’ordre qui vaut.

13Glossaire — surveillance et contenu

Le glossaire est un document compagnon. Il fournit des définitions en langage courant de la terminologie du projet pour les lecteurs non techniques. Le contrat technique du module de termes — champs, exports, forme multilingue, couplet — est dans Structure commune §6.1 et §7. Cette section couvre ce qui relève de la conduite de session.

13.1Format

Le glossaire utilise la feuille de style Glossary pour les sections par lettre et les entrées de termes. La page de garde, l'en-tête et le pied de page utilisent la feuille de style générale. Le glossaire HTML est généré en ordre alphabétique global depuis le module de termes, toutes rubriques mélangées, avec une bannière par lettre.

13.2Surveillance des termes candidats

Pendant la rédaction de documentation, l'IA signale proactivement tout nouveau terme ou acronyme technique en fin de section ou de session, avant de l'ajouter au glossaire. Même règle pour les noms de marque et pour les fragments à mettre en valeur.

Les termes du glossaire sont rendus automatiquement en italique teal dans tout le texte courant via la passe glossaire du pipeline, dès lors que le setter correspondant est appelé en tête de script.

13.3Consignes de contenu

Les définitions doivent être rédigées en langage courant, accessibles à quelqu'un sans formation technique. Inclure un exemple concret lorsque c'est possible. Éviter le jargon dans les définitions. Les nouveaux termes sont ajoutés au fur et à mesure qu'ils apparaissent dans la documentation.

Le glossaire ne tient aucun compteur d'entrées — ni sur la page de garde, ni dans les bannières de rubrique. Un compteur dérive au premier ajout et n'apporte rien au lecteur.

14Cover Sheet — règles de livraison

La Cover Sheet est la page de couverture physique du classeur papier, générée sous forme d'image A4 par un renderer Python déterministe piloté exclusivement par les constantes PCL du document Cover Sheet correspondant. L'inventaire complet de ces constantes et le contrat du renderer sont dans Cover Sheet et Quality Control §3.3.

–Renderer jamais modifié: toute modification visuelle passe par les constantes PCL du .docx. Ne jamais modifier le code du renderer pour obtenir un effet visuel ponctuel.

–Modification du .docx: toute modification des constantes PCL déclenche obligatoirement la régénération de l'image avec le même horodatage frais.

–Image seule: la régénération de l'image seule est possible si les constantes PCL n'ont pas changé — même horodatage que le .docx existant.

–Initialisation: le Cover Sheet projet est créé from scratch depuis le modèle Kit. Recette de duplication: Structure commune §8.4.

15Site HTML — règles de livraison

Le Kit prévoit une publication HTML en parallèle du classeur papier. Les fichiers HTML sont générés par le même pipeline Node.js que les .docx, depuis le stylesheet HTML miroir. L'architecture du site, le périmètre de publication, la logique de déploiement et les règles de robustesse sont dans Pipeline HTML. Les recettes de conversion sont dans la Reference du stylesheet HTML.

–CSS externe: les fichiers HTML référencent la feuille de style en externe depuis leur chemin. Jamais de CSS inliné.

–Setters obligatoires: tout générateur de site appelle en tête la série de setters requise. L'absence d'un setter désactive silencieusement le rendu correspondant — Pipeline HTML §7.9, discipline auditée par kit_check_setters.py.

–Infrastructure du sous-site: le .htaccess, le robots.txt et les fichiers d'icône ne sont produits par aucun générateur du Kit. Domicile de la règle et inventaire des fichiers attendus: §16.

16Infrastructure des sous-sites

Chaque sous-site publié, celui du Kit comme celui de tout projet consommateur, repose sur des fichiers qu'aucun générateur du Kit ne produit. Ils appartiennent au projet sliver.lu, qui gère le domaine racine, la configuration du serveur et l'identité visuelle de la famille. Le Kit déclare ce qu'il attend; il ne fournit jamais le contenu.

Les chemins ci-dessous sont relatifs à la racine du sous-site. La dernière colonne est la plus importante: l'absence de ces fichiers ne déclenche aucune erreur, elle se constate à l'oeil ou pas du tout.

–Configuration Apache: le .htaccess de chaque sous-site est écrit et déposé par le projet sliver.lu. Ne jamais en rédiger un, ne jamais l'inclure dans un ZIP de déploiement: l'extraction écraserait celui qui est en place.

–Contrôle d'accès: l'ouverture ou la fermeture d'un sous-site, les identifiants et les mots de passe relèvent exclusivement du projet sliver.lu. Ne jamais demander un identifiant, un mot de passe ou un chemin de fichier d'authentification, ne jamais en écrire un, et ne jamais supposer qu'un sous-site est protégé — le vérifier avant d'y publier quoi que ce soit de sensible.

–Icônes: les quatre fichiers d’icône d’un sous-site — favicon.svg, favicon.ico, apple-touch-icon.png et index-icon.svg — sont dessinés par le projet sliver.lu, qui les remet au sous-site; ils vivent ensuite à la racine du projet, qui les porte dans son archive comme dans le ZIP de son site. La passe de publication les copie dans les ressources et s’arrête en nommant celui qui manque. Le stylesheet HTML déclare les balises, il ne produit aucune image. Contrat des balises: HTML — Reference §17.

–Directives robots: le robots.txt de chaque sous-site est déposé par le projet sliver.lu. Aucun générateur du Kit n'en produit ni n'en modifie.

17Traductions

Un projet peut publier certains de ses documents dans une autre langue que la sienne. Ces variantes sont des aides de confort destinées à un lecteur qui ne pratique pas la langue du projet. Elles ne sont pas des versions parallèles du même document.

–La langue de base fait référence: chaque site et chaque sous-site a une langue de base, déclarée sous project.docLanguage. Ses documents fixent les règles et font seuls référence. Une traduction ne fixe jamais rien: c'est un service rendu au lecteur qui ne pratique pas cette langue. En cas d'écart, c'est la traduction qui se corrige.

–Lire la variante qui fait autorité: une IA lit un document dans la langue de son propre corpus: les documents du Kit dans la langue du Kit, ceux d'un projet dans le project.docLanguage de ce projet. Le Kit est rédigé en français; ses variantes allemande et anglaise sont des aides de lecture pour l'humain, jamais une base de travail. Travailler depuis une traduction ouvre la porte à la dérive: elle rend le sens et non la lettre — c'est précisément ce qu'on lui demande — et deux reformulations fidèles peuvent porter des nuances différentes. La règle vaut pour tout projet, y compris quand le Kit lui parvient entier dans toutes ses langues.

–Fidélité au sens, pas à la forme: une traduction se lit comme un texte écrit dans sa langue, jamais comme un décalque. La syntaxe, les tournures et le rythme suivent la langue d'arrivée. Le mot à mot produit un texte que personne ne lit volontiers et qui trahit le sens plus souvent qu'il ne le sert.

–Aucune information perdue, aucune ajoutée: la reformulation porte sur la manière de dire, jamais sur ce qui est dit. Une règle traduite conserve sa portée exacte, ses exceptions et ses conditions. Reformuler n'est pas résumer.

–Éléments intraduisibles: noms de fichiers, de fonctions, de constantes, numéros de section, blocs de code et blocs prompt restent verbatim. Ils désignent des objets réels; les traduire créerait des références vers ce qui n'existe pas.

–Renvois non traduits: un renvoi vers un document qui n'existe que dans la langue du projet reste tel quel. Le lecteur d'une traduction partielle atteindra un document qu'il ne lit pas — c'est la conséquence assumée d'un périmètre de traduction restreint, pas un défaut à masquer.

–Périmètre décidé document par document: un projet ne se traduit pas en bloc. Chaque document est traduit ou ne l'est pas, selon l'usage qu'en a le lecteur non natif. Nommage des variantes: Convention de nommage §2.1 et §2.4.

–Propagation sur demande: une modification du document source ne déclenche aucune régénération de ses traductions. Chaque variante porte son propre horodatage et se republie indépendamment des autres — un document source plus récent que sa traduction est un état normal, pas une anomalie. La mise à jour d'une traduction se demande explicitement, et relève du gestionnaire du Kit ou du projet consommateur concerné. Seul le glossaire échappe à cette règle: son couplet impose la régénération simultanée de toutes ses langues — Structure commune §7.

–Le classeur papier reste monolingue: il ne contient que les documents rédigés dans la langue du projet. Les traductions ne vivent qu'en ligne. Le classeur est un objet physique unique, et son inventaire — le §3 du Cover Sheet — ne liste donc qu'une variante par document traduit.

–Carte de structure partagée: une seule carte est extraite du fichier source et sert à toutes les variantes — ordre des blocs, type, niveau. Chaque langue ne reçoit qu'un fichier de texte. L'ossature des variantes est alors identique par construction, au lieu d'être vérifiée après coup. Le contrôle se fait avec kit_check_ossature.py — Quality Control §3.8.

Chaque document traduit annonce ce fonctionnement en tête de son §1, dans sa propre langue. La formulation est fixe et vaut pour tout projet; seule change la langue de base, entre accolades.

DE Dieses Dokument ist eine sinngemäße Übersetzung. Maßgeblich
    ist das Originaldokument auf {Französisch}; Erweiterungen und
    Änderungen werden stets dort eingepflegt.
 
EN This document is a translation in substance. The reference is
    the original document in {French}; extensions and changes are
    always made there.
 
FR Ce document est une traduction fidèle au sens. Le document de
    référence est l’original en {anglais}; ajouts et modifications
    s’y font toujours.