--- title: Décisions relative à l’écriture du site aliases: [] names: [] __au: FrViPofm __cr: CC-by-SA-NC 3.0 __dc: 20260831T102424 __dm: 20260903T083315 __id: EpA/S/Site_web,_conventions __vs: 6 --- > [!introduction]- > La présente note Obsidian rassemble les conventions d’écriture du projet de site *Ensemble pour Aixe* avec assistance d’intelligence artificielle. > Elle précise aussi les usages de dialogue homme machine. > La présente note est modifiable par l’IA qui peut y ajouter de nouvelles règles posées en séances de travail, modifier les règles selon les discussions, et peut en proposer une version mise à jour et complétée en fin de séance. > Elle a pour rôle, entre autre, d’être la mémoire persistante entre les sessions de travail. > [☚](../Index) •  > > keywords: #code, #programmation, #IA # Session de travail ## Ouverture de la session À l’ouverture d’une session de travail, une série de document est présentée en **préambule**, ce document de synthèse est préparé par le programmeur l’aide de l’outil [ia_launcher]() * pour définir des usages de dialogue homme-machine, * pour fixer des règles de fonctionnement * pour exposer les éléments techniques : contexte, contraintes, avancées, éléments produits Ce préambule est préparé, côté programmeur, grâce à l’outil en ligne de commande `ia_launcher` L’IA peut demander, au vu des éléments fournis, des pièces complémentaires ou des informations absentes. À l'ouverture d'une session de travail, après réception du *préambule*, l'IA accuse réception, confirme la compréhension de celui-ci ou indique les points obscures ou à compléter. Le cas échéant, elle peut soumettre une requête du type `` Le tutoiement est permis. ## Documents complémentaire Lorsque c’est nécessaire en cous de session de travail, l’IA peut demander des compléments d’information, notamment une série de fichiers sources. Pour permettre la collecte rapide du contenu de ces fichiers, elle peut préparer et présenter un fichier de *config* de l’outil `ia_launcher` qui sera exécuté par le programmeur. Afin d’éviter des confusions le paramètre `preamble` de cette requête compémentaire sera mis à `null`. # Usage typographique Dans les parties textuelles, tant dans le projet en construction que dans les notes Obsidian, l’apostrophe typographique *’* est préférée au simple *'*. Lorsque l’ambiguïté ou le doute existent l’apostrophe simple est conservée. L’IA peut, d’elle-même, effectuer les corrections évidentes et suggérer d’autres remplacement. # Révision des notes Les notes sont révisables par l’IA. Lorsqu’une fin de session est annoncée, l’IA récapitule l’avancée des travaux, les étapes à venir et propose de réviser les notes afférentes, de les mettre à jour comme persistance mémorielle entre les sessions coté client. La note `Site_web,_ckecklist` est une note brouillon de démarrage et n’est pas destinée à durer. Son sera reporté selon les opportunités dans les autres notes du projet : notes générales ( `Site_web,_architecture`, `Site_web,_decisions`, ...) ou spécifique (`Site_web,_module_Tagcloud`, `Site_web,_section_Evenements`, `Site_web,_outil_Recherche`, ...). Les suggestions de l’IA sont le bienvenues. Les propositions sont les bienvenues. ## Marqueurs `[!Noter]` Pendant une séance de travail, le marqueur `[Noter]` signale qu’une réflexion, une décision ou une piste doit être reportée dans les notes du projet lors de leur révision. Le paramètre est facultatif : * `[!Noter]` : destination par défaut, la note maîtresse de la séance de travail ; * `[!Noter:Accueil]`, `[!Noter:section Accueil]` : destination explicitement désignée, avec une formulation abrégée admise lorsqu’elle ne prête pas à ambiguïté ; * `[!Noter:?]` : destination à déterminer parmi les notes selon le contenu lors de la révision des notes. Le marqueur n’est pas destiné à être intégré au site ni aux fichiers du projet : il constitue une instruction de travail adressée à l’IA. Cette convention est encore à préciser et pourra évoluer. ## Évolution des notes pendant les séances Les réflexions exprimées au cours d’une séance peuvent faire évoluer les décisions et l’architecture initialement documentées. Les notes ne doivent donc pas être considérées comme figées par rapport au préambule de session : les décisions nouvelles ou les modifications de conception sont reportées dans les notes afférentes lors de leur révision. ## Sauvegardes intermédiaires et continuité de session Lorsque la séance de travail devient substantielle ou qu’un jalon important est atteint, l’IA peut proposer une sauvegarde intermédiaire des notes, sans attendre l’annonce de fin de session. L’IA ne dispose pas d’un indicateur fiable du quota restant de la conversation et ne peut donc pas garantir une sauvegarde juste avant son épuisement. Elle doit néanmoins privilégier les sauvegardes intermédiaires lorsque la quantité d’informations nouvelles devient importante, afin de limiter le risque de perte du contexte de travail. Une sauvegarde intermédiaire peut notamment être proposée : * après une décision d’architecture importante ; * après la validation et le test d’un élément fonctionnel ; * avant une étape susceptible de produire de nombreuses modifications ; * lorsque plusieurs notes ont évolué au cours de la séance. Le principe est de préserver dans les notes les décisions et résultats déjà stabilisés avant de poursuivre les travaux. # Travaux sur les fichiers ## Blocs de code à copier Pour une identification rapide des parties de note ou de fichier à modifier, celles-ci sont introduites, avant le code à copier, hors du bloc de code, par la mention de son nom et de la partie à modifier sous la forme : `> Note: Site_web,_desisions.md# Révision des notes` ou `> Fichier:templates/modular/tagcloud.html.twig#ligne~25` L’intitulé de la section, le numéro de ligne pouvant varier entre les versions, locale et distante, ces mentions sont indicatives et n’ont pas besoin d’être exactes. Elles aident cependant à localiser l’intervention. Du fait de problème d’interface, pour permettre la copie facile des blocs, les *writing block* sont évités, ainsi que l’inclusion de block marckdown `...`. Le bloc de code unique et simple. sans autre formatage à l’intérieur, délimité en externe par quatre backticks, pour un copier-coller direct dans Obsidian, est requis. Cette méthode semble permettre le respect des trois backstiks de délimitation de blocs interne. ### Contraintes particulières des templates Twig Dans un template Twig, lorsqu’un fichier contient `{% extends 'partials/base.html.twig' %}` (Template de blocs), aucun code HTML, Twig ou commentaire de repérage ne doit être placé en dehors des blocs composaznt le document. Les commentaires de repérage propres au projet doivent donc être placés à l’intérieur des blocs, par exemple : ```twig {% block content %} ... {% endblock content %} ``` # Commentaires de repérage ## Templates simples Les *templates* simples portent en début et fin des commentaires *html* exposant le *path* relatif html du fichier sous la forme : ```twig ... code twig... ``` ## Templates de blocs Dans les *templates* comportant des blocks, les commentaires comportent le nom du block sous la forme : ```twig {% block X} ... code twig... {% block X} ``` Il ne peut y avoir de html ou de texte en dehors des blocs. # Conventions de données ## Author Le champ `author` est est un champ transversal, présent dans de nombreuses pages de multiples sections. Le champs est utilisé pour stoker l’information d’organisateur d’événement. Il permettra une recherche spécifique ou un classement des résultats *par auteur*. ## Date ### Date des événements La date propre à l’événement est distincte de la date générique éventuellement prévue par les modèles ou par Grav pour les contenus. Le blueprint `evenement` utilise donc explicitement : * `event_date` : date de l’événement, obligatoire ; * `event_date_end` : date de fin éventuelle, facultative ; * `author` : auteur ou rédacteur associé à l’événement. Le format de saisie de la date dans l’interface d’administration reste à améliorer. Le format actuellement présenté par Grav n’est pas considéré comme satisfaisant pour les rédacteurs ; une solution permettant notamment une saisie de type `DD-MM-AAAA` pourra être recherchée ultérieurement.