living-documentation 7.46.0 → 7.48.0

package/dist/starting-doc-fr/AI/HOW_TO.md

@@ -0,0 +1,338 @@
+# HOW TO - Initialiser le contexte IA
+
+Ce dossier contient une configuration de départ pour le développement assisté par IA.
+
+L'objectif est de donner aux outils IA un point d'entrée déterministe :
+
+- `AGENTS.md` pour Codex et les outils de type agent
+- `CLAUDE.md` pour Claude
+- `memory/MEMORY.md` pour la mémoire locale du projet
+- `AI/project-instructions.md` pour les instructions projet partagées
+- `AI/rules/*.md` pour les règles à appliquer pendant les modifications
+
+Codex cherche `AGENTS.md`. Claude cherche `CLAUDE.md`. Les deux fichiers doivent pointer vers les mêmes instructions projet pour que les outils suivent les mêmes règles.
+
+## Comment ça marche
+
+Ce starter sépare le contexte IA en couches déterministes :
+
+```text
+AGENTS.md / CLAUDE.md
+  -> points d'entrée propres aux outils à la racine du projet
+
+AI/project-instructions.md
+  -> instructions de travail partagées par tous les outils IA
+
+AI/rules/*.md
+  -> petites règles réutilisables à appliquer selon les fichiers modifiés
+
+ADRS/*.md
+  -> décisions durables qui expliquent pourquoi le projet fonctionne ainsi
+
+memory/MEMORY.md
+  -> index de mémoire locale pour le contexte réutilisé souvent
+```
+
+Les fichiers d'entrée doivent rester courts. Leur rôle est de dire à l'IA où chercher, pas de dupliquer toute la connaissance du projet.
+
+Living Documentation rend ensuite ces fichiers visibles comme des documents classiques. Quand un même fichier doit être visible depuis plusieurs endroits, préférer les liens symboliques afin de conserver une seule source de vérité.
+
+Workflow IA attendu :
+
+1. Lire `AGENTS.md` ou `CLAUDE.md`, selon l'outil.
+2. Suivre le lien vers `AI/project-instructions.md`.
+3. Lire `memory/MEMORY.md` et charger seulement les mémoires pertinentes.
+4. Lire les règles applicables dans `AI/rules/*.md`.
+5. Inspecter le frontmatter des ADR lorsque la tâche peut toucher une décision existante.
+6. Réaliser la modification.
+7. À la fin d'une feature cohérente, mettre à jour la documentation durable si nécessaire.
+8. Attacher les métadonnées Living Documentation aux documents créés ou mis à jour lorsque des fichiers source prouvent leur contenu.
+
+## 1. Choisir un flavor d'instructions projet
+
+Le fichier par défaut est :
+
+```text
+AI/project-instructions.md
+```
+
+Vous pouvez le garder ou le remplacer par un des exemples dans :
+
+```text
+AI/flavors/
+```
+
+Exemples disponibles :
+
+```text
+AI/flavors/project-instructions-frontend-app.md
+AI/flavors/project-instructions-backend-api.md
+AI/flavors/project-instructions-library-cli.md
+AI/flavors/project-instructions-monorepo.md
+```
+
+Pour utiliser un flavor, copiez-le par-dessus le fichier par défaut :
+
+```bash
+cp AI/flavors/project-instructions-frontend-app.md AI/project-instructions.md
+```
+
+Si vous préférez renommer l'exemple choisi plutôt que le garder dans `AI/flavors/`, déplacez-le vers l'emplacement canonique :
+
+```bash
+mv AI/flavors/project-instructions-frontend-app.md AI/project-instructions.md
+```
+
+Puis éditez `AI/project-instructions.md` :
+
+- remplacez `DOCS_FOLDER` par le vrai nom du dossier de documentation, par exemple `documentation`, `docs` ou `example`
+- remplacez les commandes d'exemple par les vraies commandes du projet
+- supprimez les sections qui ne s'appliquent pas
+- ajoutez les notes d'architecture spécifiques au projet
+
+## 2. Installer les points d'entrée des agents
+
+Les templates sont fournis dans :
+
+```text
+AI/default/AGENTS.md
+AI/default/CLAUDE.md
+```
+
+Créez des liens symboliques depuis la racine du projet vers ces templates.
+
+Si le dossier de documentation s'appelle `documentation` :
+
+```bash
+ln -s documentation/AI/default/AGENTS.md AGENTS.md
+ln -s documentation/AI/default/CLAUDE.md CLAUDE.md
+```
+
+Si le dossier a un autre nom, adaptez le chemin :
+
+```bash
+ln -s <docs-folder>/AI/default/AGENTS.md AGENTS.md
+ln -s <docs-folder>/AI/default/CLAUDE.md CLAUDE.md
+```
+
+Utilisez les deux fichiers si le projet peut être utilisé par plusieurs outils IA. Gardez seulement celui dont vous avez besoin si l'équipe standardise un seul outil.
+
+Après création des liens, ouvrez `AGENTS.md` et `CLAUDE.md` depuis la racine du projet et vérifiez que leurs chemins pointent vers le bon dossier de documentation.
+
+## 3. Installer la mémoire projet
+
+La mémoire doit vivre dans le projet, pas dans un dossier global propre à un outil IA.
+
+Créez un dossier mémoire local :
+
+```bash
+mkdir -p memory
+```
+
+Puis créez un lien symbolique vers l'index mémoire du starter :
+
+```bash
+ln -s ../<docs-folder>/AI/default/MEMORY.md memory/MEMORY.md
+```
+
+Exemple si le dossier de documentation est `documentation` :
+
+```bash
+ln -s ../documentation/AI/default/MEMORY.md memory/MEMORY.md
+```
+
+Ensuite, éditez `memory/MEMORY.md` et ajoutez les fichiers mémoire utiles au projet.
+
+Fichiers mémoire typiques :
+
+```text
+memory/project-overview.md
+memory/architecture.md
+memory/testing.md
+memory/domain-language.md
+```
+
+## 4. Relire les règles IA
+
+Les règles vivent dans :
+
+```text
+AI/rules/
+```
+
+Le starter inclut :
+
+```text
+AI/rules/no-magic-numbers.md
+```
+
+Gardez-la si elle est utile, adaptez-la au projet ou supprimez-la.
+
+Ajoutez d'autres règles lorsque vous voulez qu'un comportement soit appliqué de façon constante par les outils IA :
+
+- règles i18n
+- stratégie de tests
+- compatibilité d'API publique
+- limites de sécurité
+- contraintes d'architecture
+
+## 5. Comprendre les ADR
+
+Les ADR vivent dans :
+
+```text
+ADRS/
+```
+
+Le starter inclut un ADR exemple :
+
+```text
+ADRS/2026_01_01_[ADR]_example_architecture_decision.md
+```
+
+Utilisez-le comme template lorsqu'une décision importante doit être enregistrée.
+
+Un ADR n'est pas un journal de tâches. Il doit expliquer une décision que les humains ou les assistants IA devront comprendre avant de modifier le code lié.
+
+Bons candidats pour un ADR :
+
+- choix d'un framework, format de stockage ou protocole ;
+- définition d'une frontière d'architecture ;
+- changement d'un contrat d'API publique ;
+- adoption d'une stratégie de test, release ou déploiement ;
+- création d'une règle expliquant pourquoi le code doit être écrit d'une certaine façon.
+
+Évitez les ADR pour les petits détails d'implémentation évidents dans le code.
+
+Workflow IA recommandé :
+
+1. Lister les fichiers dans `ADRS/`.
+2. Lire d'abord seulement le frontmatter : `description` et `tags`.
+3. Charger l'ADR complet seulement s'il est pertinent pour la tâche.
+4. À la fin d'une feature cohérente ou d'un refactor significatif, décider si un ADR doit être créé ou mis à jour.
+5. Si la feature change une décision durable, créer ou mettre à jour l'ADR de manière autonome.
+6. Après écriture de l'ADR, attacher les métadonnées aux fichiers source qui prouvent ou implémentent la décision.
+
+C'est volontaire : l'écriture d'ADR ne doit pas dépendre d'une demande utilisateur à chaque fois. L'IA doit garder le journal de décisions à jour lorsqu'elle termine une feature significative.
+
+Format de nommage recommandé :
+
+```text
+YYYY_MM_DD_[CATEGORY]_short_decision_title.md
+```
+
+Exemple :
+
+```text
+2026_01_01_[ADR]_example_architecture_decision.md
+```
+
+Gardez le frontmatter utile pour la découverte :
+
+```markdown
+---
+**date:** 2026-01-01
+**status:** Accepted
+**description:** Une phrase qui explique la décision et pourquoi elle compte.
+**tags:** architecture, testing, api
+---
+```
+
+Utilisez `status` de façon cohérente. Valeurs courantes :
+
+- `Proposed`
+- `Accepted`
+- `Superseded`
+- `To be validated`
+
+## 6. Comprendre les métadonnées et la fiabilité
+
+Living Documentation peut lier un document à des fichiers source. Chaque lien stocke un hash du fichier source. La jauge de fiabilité montre ensuite si le document a peut-être dérivé du code.
+
+Pour le développement assisté par IA, cela fait partie du workflow documentaire :
+
+- quand une IA crée ou met à jour un ADR, attacher les fichiers source qui implémentent ou prouvent la décision ;
+- quand une IA crée ou met à jour un guide technique, attacher les fichiers source décrits par le guide ;
+- quand le document est correct, rafraîchir ou rebaseliner les hashes de métadonnées ;
+- si l'IA ne peut pas mettre à jour les métadonnées directement, elle doit le dire et lister les fichiers à attacher manuellement.
+
+Si l'IA a accès aux outils MCP Living Documentation, elle doit préférer :
+
+```text
+add_metadata
+refresh_metadata
+```
+
+Sinon, utilisez l'interface de métadonnées du document dans Living Documentation.
+
+## 7. Enregistrer les fichiers d'instructions dans Living Documentation
+
+Démarrez Living Documentation :
+
+```bash
+npx living-documentation <docs-folder>
+```
+
+Ouvrez :
+
+```text
+http://localhost:4321/context
+```
+
+Utilisez **Add AI instruction file** pour lier les fichiers d'instructions comme `AGENTS.md`, `CLAUDE.md`, `memory/MEMORY.md` ou d'autres documents projet.
+
+Living Documentation crée des liens symboliques sous :
+
+```text
+AI/
+```
+
+Cela rend les fichiers visibles dans la documentation principale sans créer de sources de vérité dupliquées.
+
+## 8. Nettoyer le starter
+
+Après l'installation, supprimez ce qui n'est pas utile.
+
+Supprimez généralement les flavors inutilisés :
+
+```bash
+rm -rf AI/flavors
+```
+
+Supprimez les templates d'entrée inutiles si vous n'utilisez pas les deux outils :
+
+```bash
+rm AI/default/CLAUDE.md
+```
+
+ou :
+
+```bash
+rm AI/default/AGENTS.md
+```
+
+Gardez `AI/default/MEMORY.md` seulement si `memory/MEMORY.md` pointe vers lui. Si vous avez copié le fichier au lieu de créer un lien, supprimez le template inutilisé.
+
+Gardez `AI/HOW_TO.md` seulement si vous voulez que les futurs contributeurs voient le processus d'installation. Sinon, supprimez-le après initialisation.
+
+Gardez l'ADR exemple seulement si vous voulez un template dans le projet. Sinon, copiez-le quand nécessaire et supprimez l'exemple.
+
+## 9. Structure finale attendue
+
+Un projet initialisé minimal ressemble généralement à :
+
+```text
+AGENTS.md -> <docs-folder>/AI/default/AGENTS.md
+CLAUDE.md -> <docs-folder>/AI/default/CLAUDE.md
+memory/
+  MEMORY.md -> ../<docs-folder>/AI/default/MEMORY.md
+<docs-folder>/
+  AI/
+    project-instructions.md
+    rules/
+      no-magic-numbers.md
+  ADRS/
+    2026_01_01_[ADR]_example_architecture_decision.md
+```
+
+Adaptez la structure à votre projet. L'important est que les outils IA aient des fichiers déterministes à lire et que la source de vérité ne soit pas dupliquée.

package/dist/starting-doc-fr/AI/default/AGENTS.md

@@ -0,0 +1,14 @@
+# AGENTS.md - Living Documentation
+
+Ce fichier est le point d'entrée Codex pour ce dépôt.
+
+Avant de modifier le projet :
+
+1. Lire `DOCS_FOLDER/AI/project-instructions.md`.
+2. Lire `memory/MEMORY.md` et charger les fichiers mémoire pertinents qui y sont listés.
+3. Lire chaque règle dans `DOCS_FOLDER/AI/rules/*.md` et appliquer celles dont les motifs `appliesTo` correspondent aux fichiers modifiés.
+4. Pour comprendre les décisions existantes, lister les ADR, lire seulement `description` et `tags` dans le frontmatter, puis charger l'ADR complet seulement s'il est pertinent.
+
+Remplacer `DOCS_FOLDER` par le vrai dossier de documentation du projet.
+
+Si une règle IA contredit la demande utilisateur ou une autre instruction du projet, signaler explicitement le conflit avant de continuer.

package/dist/starting-doc-fr/AI/default/CLAUDE.md

@@ -0,0 +1,14 @@
+# CLAUDE.md - Living Documentation
+
+Ce fichier est le point d'entrée Claude pour ce dépôt.
+
+Avant de modifier le projet :
+
+1. Lire `DOCS_FOLDER/AI/project-instructions.md`.
+2. Lire `memory/MEMORY.md` et charger les fichiers mémoire pertinents qui y sont listés.
+3. Lire chaque règle dans `DOCS_FOLDER/AI/rules/*.md` et appliquer celles dont les motifs `appliesTo` correspondent aux fichiers modifiés.
+4. Pour comprendre les décisions existantes, lister les ADR, lire seulement `description` et `tags` dans le frontmatter, puis charger l'ADR complet seulement s'il est pertinent.
+
+Remplacer `DOCS_FOLDER` par le vrai dossier de documentation du projet.
+
+Si une règle IA contredit la demande utilisateur ou une autre instruction du projet, signaler explicitement le conflit avant de continuer.

package/dist/starting-doc-fr/AI/default/MEMORY.md

@@ -0,0 +1,7 @@
+# Index mémoire
+
+Toujours stocker les fichiers mémoire dans le dossier `memory/` du projet courant, pas dans un dossier global propre à un outil IA.
+
+**Pourquoi :** le contexte doit rester visible, versionnable et contrôlé dans le projet.
+
+**Comment appliquer :** écrire les fichiers mémoire dans `<project_root>/memory/`. Mettre à jour `memory/MEMORY.md` à chaque ajout ou suppression de fichier mémoire.

package/dist/starting-doc-fr/AI/flavors/project-instructions-backend-api.md

@@ -0,0 +1,41 @@
+# Instructions IA du projet - API backend
+
+Utilisez ce flavor pour les API HTTP, workers, services et applications côté serveur.
+
+## Routine de démarrage
+
+1. Lire ce fichier.
+2. Lire `memory/MEMORY.md`.
+3. Lire toutes les règles dans `DOCS_FOLDER/AI/rules/*.md`.
+4. Inspecter le frontmatter des ADR avant d'ouvrir les ADR complets.
+
+Remplacer `DOCS_FOLDER` par le vrai dossier de documentation.
+
+## Règles backend
+
+- Identifier la validation des requêtes, l'autorisation, la persistance et la gestion d'erreurs avant de modifier des routes.
+- Préserver la compatibilité d'API sauf demande explicite de breaking change.
+- Préférer le parsing et la validation structurés aux manipulations de chaînes ad hoc.
+- Garder les frontières filesystem et base de données explicites.
+- Ajouter des tests ciblés autour du comportement modifié et des chemins d'erreur.
+
+## Documentation continue
+
+À la fin de chaque feature cohérente ou refactor significatif :
+
+- créer ou mettre à jour un ADR si le changement affecte une frontière d'architecture, un contrat public, un format de stockage, un protocole, un workflow ou une convention durable ;
+- éviter les ADR pour les corrections triviales et détails évidents dans le code ;
+- quand un ADR ou une page de documentation durable est créée ou mise à jour, attacher les métadonnées Living Documentation aux fichiers source qui la prouvent ou l'implémentent ;
+- si les outils MCP sont disponibles, préférer `add_metadata` et `refresh_metadata` ;
+- si les métadonnées ne peuvent pas être mises à jour, lister les fichiers source à attacher.
+
+## Vérification
+
+Utiliser les vraies commandes du projet, par exemple :
+
+```bash
+npm run build
+npm run test
+```
+
+Pour les changements d'API, inclure au moins un test qui exerce la route ou le contrat public.

package/dist/starting-doc-fr/AI/flavors/project-instructions-frontend-app.md

@@ -0,0 +1,42 @@
+# Instructions IA du projet - Application frontend
+
+Utilisez ce flavor pour les applications React, Vue, Svelte, Angular ou frontend statique.
+
+## Routine de démarrage
+
+1. Lire ce fichier.
+2. Lire `memory/MEMORY.md`.
+3. Lire toutes les règles dans `DOCS_FOLDER/AI/rules/*.md`.
+4. Inspecter le frontmatter des ADR avant d'ouvrir les ADR complets.
+
+Remplacer `DOCS_FOLDER` par le vrai dossier de documentation.
+
+## Règles frontend
+
+- Garder les textes visibles par l'utilisateur dans le système i18n du projet lorsqu'il existe.
+- Préserver les conventions du design system existant avant d'ajouter de nouveaux patterns UI.
+- Vérifier les layouts responsives sur petits écrans et desktop.
+- Éviter les décalages de layout causés par le texte dynamique, les icônes et les états de chargement.
+- Préférer les composants et utilitaires partagés existants aux nouvelles abstractions.
+
+## Documentation continue
+
+À la fin de chaque feature cohérente ou refactor significatif :
+
+- créer ou mettre à jour un ADR si le changement affecte une frontière d'architecture, un contrat public, un format de stockage, un protocole, un workflow ou une convention durable ;
+- éviter les ADR pour les corrections triviales et détails évidents dans le code ;
+- quand un ADR ou une page de documentation durable est créée ou mise à jour, attacher les métadonnées Living Documentation aux fichiers source qui la prouvent ou l'implémentent ;
+- si les outils MCP sont disponibles, préférer `add_metadata` et `refresh_metadata` ;
+- si les métadonnées ne peuvent pas être mises à jour, lister les fichiers source à attacher.
+
+## Vérification
+
+Utiliser les vraies commandes du projet, par exemple :
+
+```bash
+npm run build
+npm run lint
+npm run test
+```
+
+Pour les changements visuels, ajouter une vérification navigateur ou screenshot quand c'est pratique.

package/dist/starting-doc-fr/AI/flavors/project-instructions-library-cli.md

@@ -0,0 +1,41 @@
+# Instructions IA du projet - Librairie ou CLI
+
+Utilisez ce flavor pour les packages, SDK, CLI et outils développeur.
+
+## Routine de démarrage
+
+1. Lire ce fichier.
+2. Lire `memory/MEMORY.md`.
+3. Lire toutes les règles dans `DOCS_FOLDER/AI/rules/*.md`.
+4. Inspecter le frontmatter des ADR avant d'ouvrir les ADR complets.
+
+Remplacer `DOCS_FOLDER` par le vrai dossier de documentation.
+
+## Règles librairie et CLI
+
+- Traiter les API publiques, flags de commande, formats de sortie et fichiers de config comme des surfaces de compatibilité.
+- Garder les messages d'erreur actionnables et stables lorsque les tests ou utilisateurs peuvent en dépendre.
+- Préférer de petits helpers ciblés aux abstractions larges.
+- Mettre à jour la documentation ou les exemples lorsque le comportement change.
+- Tester les chemins de succès et les entrées invalides.
+
+## Documentation continue
+
+À la fin de chaque feature cohérente ou refactor significatif :
+
+- créer ou mettre à jour un ADR si le changement affecte une frontière d'architecture, un contrat public, un format de stockage, un protocole, un workflow ou une convention durable ;
+- éviter les ADR pour les corrections triviales et détails évidents dans le code ;
+- quand un ADR ou une page de documentation durable est créée ou mise à jour, attacher les métadonnées Living Documentation aux fichiers source qui la prouvent ou l'implémentent ;
+- si les outils MCP sont disponibles, préférer `add_metadata` et `refresh_metadata` ;
+- si les métadonnées ne peuvent pas être mises à jour, lister les fichiers source à attacher.
+
+## Vérification
+
+Utiliser les vraies commandes du projet, par exemple :
+
+```bash
+npm run build
+npm run test
+```
+
+Pour les changements CLI, vérifier la commande avec des arguments réalistes.

package/dist/starting-doc-fr/AI/flavors/project-instructions-monorepo.md

@@ -0,0 +1,41 @@
+# Instructions IA du projet - Monorepo
+
+Utilisez ce flavor pour les dépôts contenant plusieurs apps, packages ou services.
+
+## Routine de démarrage
+
+1. Lire ce fichier.
+2. Lire `memory/MEMORY.md`.
+3. Lire toutes les règles dans `DOCS_FOLDER/AI/rules/*.md`.
+4. Inspecter le frontmatter des ADR avant d'ouvrir les ADR complets.
+
+Remplacer `DOCS_FOLDER` par le vrai dossier de documentation.
+
+## Règles monorepo
+
+- Identifier le package ou l'application propriétaire des fichiers avant modification.
+- Utiliser les scripts et configs du package le plus proche quand c'est possible.
+- Éviter les refactors cross-package sauf nécessité liée à la tâche.
+- Vérifier les frontières de dépendances workspace avant d'importer entre packages.
+- Préférer d'abord les tests ciblés du package concerné, puis élargir si un contrat partagé a changé.
+
+## Documentation continue
+
+À la fin de chaque feature cohérente ou refactor significatif :
+
+- créer ou mettre à jour un ADR si le changement affecte une frontière d'architecture, un contrat public, un format de stockage, un protocole, un workflow ou une convention durable ;
+- éviter les ADR pour les corrections triviales et détails évidents dans le code ;
+- quand un ADR ou une page de documentation durable est créée ou mise à jour, attacher les métadonnées Living Documentation aux fichiers source qui la prouvent ou l'implémentent ;
+- si les outils MCP sont disponibles, préférer `add_metadata` et `refresh_metadata` ;
+- si les métadonnées ne peuvent pas être mises à jour, lister les fichiers source à attacher.
+
+## Vérification
+
+Utiliser les vraies commandes du projet, par exemple :
+
+```bash
+npm run build --workspace <package>
+npm run test --workspace <package>
+```
+
+Adapter les commandes au package manager utilisé par le dépôt.

package/dist/starting-doc-fr/AI/project-instructions.md

@@ -0,0 +1,78 @@
+# Instructions IA du projet
+
+Ce fichier est le guide de travail partagé pour les assistants IA qui interviennent sur ce projet.
+
+Gardez ce fichier court, concret et spécifique au projet. `AGENTS.md` et `CLAUDE.md` doivent pointer vers lui au lieu de dupliquer les mêmes instructions.
+
+## Routine de démarrage
+
+Avant de modifier le projet :
+
+1. Lire ce fichier.
+2. Lire `memory/MEMORY.md` et charger seulement les fichiers mémoire utiles à la tâche.
+3. Lire toutes les règles dans `DOCS_FOLDER/AI/rules/*.md`.
+4. Pour comprendre les décisions existantes, inspecter d'abord le frontmatter des ADR : lire `description` et `tags`, puis ouvrir l'ADR complet seulement s'il est pertinent.
+
+Remplacez `DOCS_FOLDER` par le vrai dossier de documentation du projet, par exemple `documentation` ou `docs`.
+
+## Règles IA
+
+Les règles vivent dans `DOCS_FOLDER/AI/rules/*.md`.
+
+Chaque règle utilise un frontmatter :
+
+- `id` - identifiant stable
+- `title` - nom court lisible
+- `severity` - `guideline`, `warning` ou `required`
+- `description` - résumé concis
+- `tags` - thèmes utilisés pour la découverte
+- `appliesTo` - globs indiquant où la règle s'applique
+
+Appliquer chaque règle dont les motifs `appliesTo` correspondent aux fichiers modifiés. Si une règle contredit la demande utilisateur ou une autre instruction du projet, signaler explicitement le conflit avant de continuer.
+
+## ADRs
+
+Les ADR sont le registre durable des décisions importantes.
+
+Pour comprendre pourquoi quelque chose existe :
+
+1. Lister les fichiers ADR.
+2. Lire seulement `description` et `tags` dans le frontmatter.
+3. Ouvrir l'ADR complet seulement s'il est pertinent pour la tâche.
+4. Si une décision importante est prise ou modifiée, créer ou mettre à jour un ADR.
+
+## Documentation continue
+
+À la fin de chaque feature cohérente ou refactor significatif, mettre à jour la documentation durable de manière autonome lorsque le changement crée une connaissance que les prochains travaux devront préserver.
+
+Créer ou mettre à jour un ADR lorsque la feature :
+
+- change une frontière d'architecture, un contrat public, un format de stockage, un protocole ou un workflow ;
+- introduit une convention que les futurs changements devront respecter ;
+- résout un compromis difficile à déduire du code seul ;
+- remplace ou invalide une décision précédente.
+
+Ne pas créer d'ADR pour les corrections triviales, renommages mécaniques, changements de formatage ou détails d'implémentation évidents dans le code.
+
+Quand un ADR ou une page de documentation durable est créée ou mise à jour, attacher les métadonnées de fichiers source afin que Living Documentation puisse afficher la dérive de fiabilité :
+
+1. Lier le document aux fichiers source qui prouvent ou implémentent ce qu'il décrit.
+2. Quand le document est correct, rafraîchir/rebaseliner ses hashes de métadonnées.
+3. Si les outils MCP sont disponibles, préférer `add_metadata` et `refresh_metadata`.
+4. Si les métadonnées ne peuvent pas être mises à jour depuis l'environnement courant, le dire explicitement et lister les fichiers source à attacher.
+
+## Mémoire
+
+Les fichiers mémoire vivent dans le projet, sous `memory/`.
+
+Ne pas stocker la mémoire projet dans un dossier global propre à un outil si l'utilisateur attend une mémoire locale au projet. Mettre à jour `memory/MEMORY.md` à chaque ajout ou suppression de fichier mémoire.
+
+## Vérification
+
+Avant de terminer une tâche, lancer la plus petite vérification utile :
+
+- commande de build si du code typé ou des fichiers de build ont changé
+- tests ciblés si le comportement a changé
+- lint ou formatage si le projet en possède
+
+Si une vérification ne peut pas être lancée, expliquer pourquoi.

package/dist/starting-doc-fr/AI/rules/no-magic-numbers.md

@@ -0,0 +1,18 @@
+---
+id: no-magic-numbers
+title: Éviter les magic numbers
+severity: warning
+description: Les valeurs numériques porteuses de sens métier ou technique doivent être nommées par des constantes plutôt que répétées comme littéraux bruts.
+tags: ["qualite-code", "maintenabilite"]
+appliesTo: ["src/**/*.ts", "src/frontend/**/*.js"]
+---
+
+Les valeurs numériques qui portent un sens doivent être nommées là où elles sont introduites.
+
+Préférer une constante dont le nom explique l'intention :
+
+```ts
+const DEFAULT_CUSTOM_SHAPE_SIZE = 65;
+```
+
+Éviter de répéter des nombres bruts dans le code quand la valeur porte un sens produit, rendu, dimensionnement, timing ou protocole.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "living-documentation",
-  "version": "7.46.0",
+  "version": "7.48.0",
   "description": "A CLI tool that serves a local Markdown documentation viewer",
   "main": "dist/src/server.js",
   "bin": {

package/dist/starting-doc/.annotations.json

@@ -1 +0,0 @@
-{}