living-documentation 7.0.0

package/dist/starting-doc/2_guide/2026_04_09_11_00_[Configuration]_configurer_le_panneau_admin.md

@@ -0,0 +1,55 @@
+## Panneau Admin
+
+Le panneau Admin est accessible via le bouton **`⚙ Admin`** dans le header principal. Il permet de configurer Living Documentation sans éditer manuellement le fichier `.living-doc.json`.
+
+---
+
+### Changer le titre de l'application
+
+1. Ouvrez **⚙ Admin**
+2. Dans le champ **`Title`**, saisissez le nom de votre projet (ex. `Documentation — MonProjet`)
+3. Cliquez **`Save`**
+
+Le titre s'affiche dans l'onglet du navigateur et en haut de la sidebar.
+
+---
+
+### Changer le thème
+
+1. Dans le sélecteur **`Theme`**, choisissez parmi :
+   - `system` — suit la préférence système (clair/sombre)
+   - `light` — toujours clair
+   - `dark` — toujours sombre
+2. Cliquez **`Save`**
+
+> La préférence est aussi accessible depuis le bouton ☀️/🌙 dans le header, qui la persiste en `localStorage`.
+
+---
+
+### Modifier le pattern de nommage des fichiers
+
+1. Dans le champ **`Filename pattern`**, saisissez votre pattern personnalisé.
+
+   Exemples valides :
+   ```
+   YYYY_MM_DD_HH_mm_[Category]_title
+   [Category]_YYYY_MM_DD_title
+   YYYY_MM_DD_[Category]_title
+   ```
+
+2. Cliquez **`Save`**
+
+**Contrainte** : le pattern doit contenir `[Category]` **exactement une fois**. Un message d'erreur s'affiche sinon.
+
+> Pour la liste complète des tokens reconnus, consultez la [référence des tokens](?doc=4_reference%252F2026_04_09_02_00_%255BREFERENCE%255D_tokens_pattern_nommage).
+
+---
+
+### Activer le mode debug des diagrammes
+
+1. Cochez **`Show diagram debug overlay`**
+2. Cliquez **`Save`**
+
+En mode debug, un bouton `dbg` apparaît dans la barre d'outils de l'éditeur de diagramme. Il affiche les coordonnées et dimensions de chaque nœud sous forme d'overlays DOM.
+
+Utile pour diagnostiquer des problèmes de positionnement dans les diagrammes.

package/dist/starting-doc/2_guide/2026_04_09_12_00_[Configuration]_extra_files.md

@@ -0,0 +1,68 @@
+## Extra Files — inclure des fichiers extérieurs au dossier docs
+
+Les **Extra Files** permettent d'ajouter dans Living Documentation des fichiers Markdown qui se trouvent **en dehors** du dossier de documentation principal. Typiquement : `README.md`, `CLAUDE.md`, `CONTRIBUTING.md` à la racine du dépôt.
+
+Ces fichiers apparaissent toujours dans la section **General**, avant les documents normaux.
+
+---
+
+### Ajouter un Extra File via le panneau Admin
+
+1. Ouvrez **⚙ Admin**
+2. Descendez jusqu'à la section **General — Extra Files**
+3. Utilisez le **navigateur de fichiers intégré** pour parcourir votre système de fichiers
+4. Naviguez jusqu'au fichier `.md` souhaité et cliquez **`Add`**
+5. Le fichier apparaît dans la liste des Extra Files
+6. Cliquez **`Save`**
+
+✅ Le fichier est immédiatement visible dans la sidebar, dans la catégorie General.
+
+---
+
+### Réordonner les Extra Files
+
+Dans la liste des Extra Files du panneau Admin, vous pouvez **réordonner** les entrées par glisser-déposer ou via les flèches ↑↓. L'ordre défini est l'ordre d'apparition dans la sidebar.
+
+---
+
+### Supprimer un Extra File
+
+Cliquez sur l'icône **🗑** à droite de l'entrée dans la liste, puis **`Save`**.
+
+> Cela retire uniquement le fichier de la liste des Extra Files — le fichier sur disque n'est **pas supprimé**.
+
+---
+
+### Cas d'usage typiques
+
+```json
+{
+  "extraFiles": [
+    "/path/to/project/README.md",
+    "/path/to/project/CLAUDE.md",
+    "/path/to/project/CONTRIBUTING.md"
+  ]
+}
+```
+
+- **README.md** : page d'accueil du projet, visible directement dans la documentation
+- **CLAUDE.md** : instructions pour les agents IA, consultables sans ouvrir un éditeur
+- **CONTRIBUTING.md** : guide de contribution, partagé avec toute l'équipe via la documentation
+
+---
+
+### Configuration manuelle
+
+Les Extra Files sont stockés dans `.living-doc.json` sous la clé `extraFiles`. Vous pouvez les éditer directement :
+
+```json
+{
+  "extraFiles": [
+    "/chemin/absolu/vers/mon_fichier.md"
+  ]
+}
+```
+
+**Contraintes :**
+- Les chemins doivent être **absolus** et se terminer par `.md`
+- Les fichiers doivent exister sur le disque au moment du chargement

package/dist/starting-doc/2_guide/2026_04_09_13_00_[WORDCLOUD]_word_cloud.md

@@ -0,0 +1,54 @@
+## Word Cloud — visualiser le vocabulaire dominant
+
+Le **Word Cloud** génère un nuage de mots à partir du contenu de n'importe quel dossier de votre système de fichiers. Utile pour identifier les thèmes dominants d'une base de code ou d'une documentation.
+
+---
+
+### Lancer le Word Cloud
+
+1. Cliquez sur **`☁ Word Cloud`** dans le header principal.
+
+   Un overlay plein écran s'ouvre.
+
+2. Dans le champ **Search root**, saisissez le chemin du dossier à analyser.
+
+   Vous pouvez aussi cliquer **`Browse`** pour naviguer dans votre système de fichiers et sélectionner un dossier.
+
+3. Cochez les **extensions de fichiers** à inclure dans l'analyse :
+
+   | Famille    | Extensions disponibles                        |
+   |------------|-----------------------------------------------|
+   | Docs       | `.md`, `.txt`                                 |
+   | JS/TS      | `.js`, `.ts`, `.jsx`, `.tsx`                  |
+   | JVM        | `.java`, `.kt`, `.scala`                      |
+   | Systèmes   | `.py`, `.go`, `.rs`, `.cs`, `.swift`, `.rb`   |
+   | Web        | `.html`, `.css`                               |
+   | Config     | `.yml`, `.yaml`, `.json`                      |
+
+4. Cliquez **`Launch`**.
+
+   Living Documentation scanne récursivement le dossier, lit tous les fichiers correspondants, et génère le nuage de mots.
+
+---
+
+### Filtrage automatique
+
+Le Word Cloud applique automatiquement plusieurs filtres pour ne conserver que les mots porteurs de sens :
+
+- **Mots vides humains** (EN + FR) : `the`, `and`, `le`, `de`, `avec`, etc.
+- **Mots-clés du langage** : selon les extensions sélectionnées (`function`, `import`, `class`, `return`…)
+- **Lignes d'import/package** : supprimées avant la tokenisation
+
+---
+
+### Persistance
+
+Le dossier racine et les extensions sélectionnées sont mémorisés en `localStorage` sous les clés `wc-root` et `wc-exts`. Ils sont rechargés automatiquement à la prochaine ouverture.
+
+---
+
+### Cas d'usage
+
+- **Audit d'une documentation** : vérifier que les termes métier apparaissent bien en bonne place
+- **Revue d'une base de code** : détecter les concepts dominants dans un module
+- **Onboarding** : donner à un nouveau développeur une vision rapide du vocabulaire du projet

package/dist/starting-doc/2_guide/2026_04_09_14_00_[DIAGRAM]_creer_et_lier_un_diagramme.md

@@ -0,0 +1,77 @@
+## Créer un diagramme et le lier à un document
+
+L'éditeur de diagrammes est intégré dans Living Documentation. Les diagrammes sont stockés dans le même dossier que vos documents, versionnable avec votre code.
+
+---
+
+### Créer un nouveau diagramme
+
+1. Cliquez sur **`⬡ Diagram`** dans le header principal.
+
+   L'éditeur de diagramme s'ouvre dans un nouvel onglet (ou dans la même page selon votre navigateur).
+
+2. Dans la liste de diagrammes (panneau gauche), cliquez sur **`+ New diagram`**.
+
+3. Donnez un nom à votre diagramme.
+
+4. Construisez votre diagramme :
+   - **Double-clic** sur le canvas → crée un nœud
+   - **Glisser** entre deux nœuds → crée une arête
+   - **Clic sur un nœud** → sélectionne, affiche le panneau de formatage
+   - **Double-clic sur un nœud** → édite le label
+
+5. Cliquez **`💾 Save`** (ou `Cmd/Ctrl+S`).
+
+   Le diagramme est sauvegardé sous forme JSON dans `DOCS_FOLDER/.diagrams/`.
+
+---
+
+### Exporter le diagramme en PNG
+
+1. Depuis l'éditeur, cliquez **`📷 Export PNG`**.
+
+   Une image PNG du canvas est générée et sauvegardée dans `DOCS_FOLDER/images/`.
+
+2. Notez le nom du fichier généré (ex. `diagram-d1234567890.png`).
+
+---
+
+### Lier le diagramme à un document
+
+Une fois le PNG exporté, insérez-le dans votre document Markdown en tant qu'image cliquable pointant vers l'éditeur de diagramme.
+
+**En mode édition**, utilisez le snippet **`Lien vers un diagramme`** :
+
+1. Ouvrez le document cible en mode édition
+2. Cliquez **`🧩 Snippets`** → **`Lien vers un diagramme`**
+3. Renseignez :
+   - L'URL de l'image PNG (`./images/diagram-d1234567890.png`)
+   - L'ID du diagramme (visible dans l'URL de l'éditeur : `/diagram?id=d1234567890`)
+4. Cliquez **`Insérer`**
+
+Ou directement en Markdown :
+
+```markdown
+[![Mon diagramme](./images/diagram-d1234567890.png)](/diagram?id=d1234567890)
+```
+
+✅ Dans l'article, un clic sur l'image ouvre l'éditeur de diagramme.
+`Shift+Clic` sur l'image l'affiche en plein écran.
+
+---
+
+### Deep-link vers un diagramme spécifique
+
+Vous pouvez créer un lien direct vers un diagramme depuis n'importe quel document :
+
+```markdown
+[Voir le diagramme d'architecture](/diagram?id=d1234567890)
+```
+
+Au chargement de l'éditeur, le diagramme correspondant est ouvert automatiquement.
+
+---
+
+### Bouton ← Retour
+
+Le bouton **`← Back`** dans l'éditeur de diagramme appelle `history.back()` et retourne à la page qui a ouvert le diagramme (généralement l'article qui contient l'image).

package/dist/starting-doc/3_concept/2026_04_08_20_58_[DOCUMENTING]_ADRS.md

@@ -0,0 +1,20 @@
+
+## Les ADR : une bonne idée, des limites réelles
+
+Les **Architecture Decision Records**, ces petits documents Markdown versionnés dans le dépôt, au plus près du code, sont une des meilleures pratiques que j'aie adoptées dans ma longue carrière de développeur et elle le reste encore aujourd'hui.<br/>
+Pas besoin d'outil externe, pas de synchronisation à gérer, l'historique des décisions **vit** avec le code.
+
+Mais certains problèmes subsistent :
+
+- Les **diagrammes** : l'ADR affiche un beau PNG généré depuis un outil visuel (parce que mermaid ca va un moment !!)<br/>
+Mais le fichier source du diagramme a disparu depuis longtemps ➔ Le PNG ne sera jamais mis à jour ➔ Documentation obsolete ➔ C'est dommage car moi perso je suis un visuel
+- L'**ordre** des ADRs : laborieux à maintenir, des dossiers, des sous-dossiers, des conventions *superseded / not superseded*, tout ca tiens mal dans la durée.
+- Les **markdowns** : C'est bien mais les outils pour les visualiser sont plutôt limités et pas très pratiques.
+
+---
+
+<h2 style="text-align:center">➠ Vers un meilleur type de partage de connaissance</h2>
+
+[![Living Documentation](./images/living_documentation.png)](?doc=3_concept%252F2026_04_08_22_15_%255BDOCUMENTING%255D_living_documentation)
+
+<h1 style="text-align:center"><code>CLIC sur l'image pour naviguer 😉</code></h1>

package/dist/starting-doc/3_concept/2026_04_08_22_15_[DOCUMENTING]_living_documentation.md

@@ -0,0 +1,17 @@
+## La documentation qui vit avec le code
+
+La formation que j'ai eu l'occasion de suivre et le livre de **Cyrille Martraire** <a href="https://www.amazon.fr/Living-Documentation-Cyrille-Martraire/dp/0134689321" target="_blank">*Living Documentation*, Addison-Wesley</a> ont cristallisé quelque chose d'essentiel : la documentation traditionnelle est périmée dès qu'elle est écrite, parce qu'elle est séparée de ce qu'elle décrit.
+
+Son principe directeur :
+
+> Chaque connaissance doit avoir **une source unique faisant autorité**, et tout le reste doit en découler automatiquement. Ce qui ne peut pas être automatisé doit être traité comme du code, versionné, revu, maintenu activement.
+
+S'il s'appuie sur le Domain-Driven Design pour que le code *soit* lui-même de la documentation, il pose une question plus large : comment faire en sorte que la documentation reste vivante, fiable, et qu'elle coûte le moins possible à maintenir ?
+
+De surcroît avec les LLM et les agents IA actuels (je fais déjà écrire mes ADRS par un `skills CLAUDE`), cette notion de documentation vivante est un sujet auquel j'accorde beaucoup d'importance.
+
+---
+
+[![Diataxis](./images/diataxis_callout.png)](?doc=3_concept%252F2026_04_08_22_46_%255BMETHODOLOGY%255D_diataxis_architecture_du_contenu)
+
+<h1 style="text-align:center"><code>CLIC sur l'image pour naviguer 😉</code></h1>

package/dist/starting-doc/3_concept/2026_04_08_22_46_[METHODOLOGY]_diataxis_architecture_du_contenu.md

@@ -0,0 +1,16 @@
+
+## Diátaxis — l'architecture du contenu
+
+La méthode <a href="https://diataxis.fr/" target="_blank">**Diátaxis**</a> répond à une question différente de celle de [`Living Documentation`](?doc=3_concept%252F2026_04_08_22_15_%255BDOCUMENTING%255D_living_documentation) mais néanmoins complémentaire : non pas *comment maintenir* la documentation, mais *comment la structurer* pour qu'elle serve vraiment.
+
+Sa réponse tient en une règle : **un document, une seule orientation**.
+
+Un tutoriel n'est pas un guide de référence, une explication n'est pas un how-to.
+
+Mélanger les genres, c'est produire des documents qui ne servent personne complètement. 
+
+![Diataxis](./images/diataxis.png)
+
+L'outil **Living Documentation** est agnotique de toute méthodologie, vous pouvez le moduler à votre guise, toutefois personnellement je recommande l'approche **Diataxis** car c'est celle que j'utilise depuis un certain temps et qui je trouve fonctionne le mieux pour documenter les projets sur lesquels je travaille.
+
+Cet exemple introductif en est également une démonstration aussi ouvrons sans plus tarder le premier document de référence de ce bel outil qu'est [`Living Documentation`](?doc=4_reference%252F2026_04_08_23_14_%255BFUNDAMENTALS%255D_the_living_documentation_tool)

package/dist/starting-doc/4_reference/2026_04_08_23_14_[FUNDAMENTALS]_the_living_documentation_tool.md

@@ -0,0 +1,41 @@
+## Ce que cet outil propose
+
+L'outil `Living Documentation` est un outil low footprint, opensource, ne necessitant ni abonnement, ni installation complexe, ni SAAS dédié, ni puissance de calcul massive, rien de tout cela.
+
+C'est un outil installé localement sur n'importe lequel de vos projets et qui nécessite simplement de disposer de **NodeJS** sur sa machine.
+
+Lancez l'outil en pointant vers votre dossier de documentation, le mieux étant de versionner ce dossier au sein de votre projet :
+
+```bash
+npx living-documentation ./docs
+```
+
+Pour plus d'information consulter le [`Guide de démarrage`](?doc=2_guide%252F2026_04_08_23_38_%255BConfiguration%255D_demarrage_de_living_documentation)
+
+---
+
+## Vue d'ensemble de l'outil
+
+<h2 style="text-align:center"><code>SHIFT+CLIC sur l'image pour l'agrandir 😉</code></h2>
+<h2 style="text-align:center"><code>CLIC sur l'image pour accéder au diagamme en modification 😲</code></h2>
+
+[![The Living Documentation Tool](./images/the_living_documentation_tool.png)](/diagram?id=d1775684671412)
+
+- **Garder la documentation dans le dépôt**, en Markdown, versionnée avec le code, sans dépendance externe
+- **Résoudre le problème des diagrammes** avec un éditeur intégré dont la source est stockée dans le même dossier que les documents
+- **Rendre la navigation agréable** sans avoir à ouvrir GitHub ou un éditeur de code
+- **Laisser la structure émerger naturellement** à partir des noms de fichiers et de l'arborescence, sans contraintes, sans base de données, sans synchronisation, sans état à gérer
+- **Encourager Diátaxis** ça c'est ce que moi je vous recommande, mais libre à vous de m'écouter ou non
+
+L'outil ne remplace pas : 
+
+- la méthodologie (Ex. Diataxis Again 😉) 
+- la discipline d'écriture (Mais un mode MCP arrive bientôt 🤩)
+
+Mais il essaie de supprimer les **frictions** qui font qu'on finit par **ne plus écrire du tout** et propose une approche novatrice basée sur la reclecture et l'IA pour **détecter** et **corriger** les parties obsolètes d'une documentation !
+
+> Comme j'adore la méthode Diàtaxis, je vous propose d'aller explorer les Tutoriels et les Guides pour en apprendre davantage sur living-documentation
+>
+> Pour commencer, c'est par [ici](?doc=2026_04_11_12_55_%255BGeneral%255D_premiers_pas)
+>
+> — Youssef MEDAGHRI-ALAOUI (Concepteur de Living Documentation)

package/dist/starting-doc/4_reference/2026_04_09_01_00_[REFERENCE]_raccourcis_clavier.md

@@ -0,0 +1,61 @@
+## Raccourcis clavier
+
+### Visionneuse principale (`/`)
+
+| Raccourci            | Action                                    |
+|----------------------|-------------------------------------------|
+| `Cmd/Ctrl + S`       | Sauvegarder le document en cours d'édition |
+| `Escape`             | Quitter le mode édition (= Cancel)        |
+| `Cmd/Ctrl + V`       | En mode édition avec image dans le presse-papiers : coller et uploader l'image |
+
+---
+
+### Éditeur de diagramme (`/diagram`)
+
+#### Général
+
+| Raccourci            | Action                                    |
+|----------------------|-------------------------------------------|
+| `Cmd/Ctrl + S`       | Sauvegarder le diagramme                 |
+| `Cmd/Ctrl + Z`       | Annuler (Undo)                           |
+| `Cmd/Ctrl + Shift + Z` | Rétablir (Redo)                        |
+| `Cmd/Ctrl + C`       | Copier les nœuds sélectionnés            |
+| `Cmd/Ctrl + V`       | Coller les nœuds (avec remapping des IDs) |
+| `Delete` / `Backspace` | Supprimer les nœuds/arêtes sélectionnés |
+| `Escape`             | Désélectionner tout                      |
+
+#### Navigation canvas
+
+| Raccourci            | Action                                    |
+|----------------------|-------------------------------------------|
+| `+` / `-`            | Zoom avant / arrière                     |
+| `0`                  | Réinitialiser le zoom (fit to screen)    |
+| `Molette`            | Zoom centré sur le curseur               |
+| `Clic + Drag` (canvas) | Déplacer la vue                        |
+
+#### Nœuds
+
+| Raccourci                        | Action                                    |
+|----------------------------------|-------------------------------------------|
+| `Double-clic` (canvas vide)      | Créer un nœud                            |
+| `Double-clic` (nœud)             | Éditer le label du nœud                  |
+| `Clic` (nœud)                    | Sélectionner                             |
+| `Shift + Clic` (nœud)            | Ajouter à la sélection                   |
+| `Drag` (nœud)                    | Déplacer                                 |
+| `Drag` (handle de coin)          | Redimensionner                           |
+
+#### Arêtes
+
+| Raccourci                        | Action                                    |
+|----------------------------------|-------------------------------------------|
+| `Drag` (nœud source → nœud cible) | Créer une arête                         |
+| `Double-clic` (arête)            | Éditer le label de l'arête              |
+
+---
+
+### Images dans les articles
+
+| Raccourci            | Action                                    |
+|----------------------|-------------------------------------------|
+| `Shift + Clic`       | Afficher l'image en plein écran (overlay) |
+| `Clic` sur une image liée | Naviguer vers la destination (document, diagramme, URL externe) |

package/dist/starting-doc/4_reference/2026_04_09_02_00_[REFERENCE]_tokens_pattern_nommage.md

@@ -0,0 +1,75 @@
+## Tokens du pattern de nommage
+
+Le pattern de nommage des fichiers est configurable via **⚙ Admin** → champ *Filename pattern*. Il détermine comment Living Documentation extrait la date, la catégorie et le titre depuis le nom du fichier.
+
+---
+
+### Tokens reconnus
+
+| Token        | Description                          | Exemple dans le nom de fichier | Valeur parsée       |
+|--------------|--------------------------------------|-------------------------------|---------------------|
+| `YYYY`       | Année sur 4 chiffres                 | `2024`                        | 2024                |
+| `MM`         | Mois sur 2 chiffres (01–12)          | `03`                          | Mars                |
+| `DD`         | Jour sur 2 chiffres (01–31)          | `15`                          | 15                  |
+| `HH`         | Heure sur 2 chiffres (00–23)         | `14`                          | 14                  |
+| `mm`         | Minutes sur 2 chiffres (00–59)       | `30`                          | 30                  |
+| `[Category]` | Catégorie entre crochets             | `[Architecture]`              | Architecture        |
+| *(reste)*    | Tout le reste forme le titre         | `choix_base_de_donnees`       | Choix Base De Donnees |
+
+---
+
+### Pattern par défaut
+
+```
+YYYY_MM_DD_HH_mm_[Category]_title
+```
+
+Exemple complet :
+
+```
+2024_03_15_14_30_[Architecture]_choix_base_de_donnees.md
+```
+
+| Extrait      | Valeur                  |
+|--------------|-------------------------|
+| Date         | 15 mars 2024, 14:30     |
+| Catégorie    | Architecture            |
+| Titre        | Choix Base De Donnees   |
+
+---
+
+### Patterns alternatifs valides
+
+L'ordre des tokens est respecté. Exemples :
+
+```
+[Category]_YYYY_MM_DD_title
+YYYY_MM_DD_[Category]_title
+YYYY_MM_DD_HH_mm_[Category]_title    ← par défaut
+```
+
+**Contrainte obligatoire** : `[Category]` doit apparaître **exactement une fois**. Un pattern sans `[Category]` ou avec deux occurrences est rejeté (erreur 400).
+
+---
+
+### Stratégies de fallback du parser
+
+Le parser essaie trois stratégies dans l'ordre, de la plus complète à la plus permissive :
+
+1. **Full match** — date + catégorie présents → extrait date, catégorie, titre
+2. **Date-only** — date présente, pas de catégorie → catégorie = `General`, titre extrait du reste
+3. **Fallback total** — rien ne correspond → titre = nom du fichier, catégorie = `General`, date = null
+
+Les fichiers qui ne suivent pas du tout le pattern sont quand même affichés sous **General**.
+
+---
+
+### Séparateur
+
+Le séparateur entre les tokens est le `_` (underscore). Le titre peut donc lui-même contenir des underscores — tout ce qui est après le dernier token reconnu forme le titre.
+
+---
+
+### Tri des documents
+
+Les documents sont triés par **nom de fichier complet** en ordre alphabétique ascendant (`localeCompare`) au sein de chaque catégorie. Le préfixe de date (`YYYY_MM_DD`) garantit donc un tri chronologique si le pattern est respecté.

package/dist/starting-doc/4_reference/2026_04_09_03_00_[REFERENCE]_types_de_snippets.md

@@ -0,0 +1,68 @@
+## Types de snippets disponibles
+
+Les snippets sont accessibles en mode édition via le bouton **`🧩 Snippets`**. Voici la liste exhaustive.
+
+---
+
+### Snippets simples
+
+| Snippet                    | Description                                              | Markdown généré (exemple)                                     |
+|----------------------------|----------------------------------------------------------|----------------------------------------------------------------|
+| **Bloc dépliable**         | Bloc `<details>` avec titre et contenu masqué par défaut | `<details><summary>Titre</summary>\n\nContenu\n</details>`    |
+| **Lien**                   | Lien Markdown standard vers une URL                      | `[Texte](https://exemple.com)`                                |
+| **Lien vers un document**  | Lien vers un autre document Living Documentation         | `[Texte](?doc=<id_encodé>)`                                   |
+| **Lien d'ancre**           | Lien vers une section du document courant                | `[Texte](#titre-de-section)`                                  |
+| **Lien d'ancre (autre doc)** | Lien vers une section d'un autre document              | `[Texte](?doc=<id_encodé>#titre)`                             |
+| **Lien vers un diagramme** | Image cliquable ouvrant l'éditeur de diagramme           | `[![Alt](./images/img.png)](/diagram?id=<id>)`                |
+| **Image**                  | Image Markdown simple                                    | `![Alt](./images/img.png)`                                    |
+| **Bloc de code**           | Bloc de code avec langage                                | ` ```langage\ncode\n``` `                                     |
+| **Citation**               | Bloc blockquote                                          | `> Texte de la citation`                                      |
+| **Séparateur**             | Ligne horizontale                                        | `---`                                                         |
+| **Liste numérotée**        | Liste ordonnée à 3 niveaux d'imbrication                 | `1. item\n   1. sous-item\n      1. sous-sous-item`           |
+| **Liste à puces**          | Liste non ordonnée à 3 niveaux d'imbrication             | `- item\n   - sous-item\n      - sous-sous-item`              |
+
+---
+
+### Snippets complexes
+
+#### Tableau (éditeur dynamique)
+
+Ouvre une grille interactive dans le panneau Snippets.
+
+- Définissez le nombre de colonnes et de lignes
+- Remplissez les cellules dans l'interface
+- Génère un tableau Markdown correctement aligné
+
+```markdown
+| Col 1  | Col 2  | Col 3  |
+|--------|--------|--------|
+| val 1  | val 2  | val 3  |
+```
+
+#### Arbre ASCII (éditeur d'indentation)
+
+Ouvre un éditeur textuel basé sur l'indentation.
+
+- Saisissez les nœuds de l'arbre, un par ligne
+- L'indentation (espaces ou tab) définit la hiérarchie
+- Génère un bloc de code `text` avec les connecteurs `├──` / `└──`
+
+```text
+racine/
+├── dossier-a/
+│   ├── fichier-1.md
+│   └── fichier-2.md
+└── dossier-b/
+    └── fichier-3.md
+```
+
+---
+
+### Mode détection
+
+Si vous **sélectionnez** du texte dans le textarea avant d'ouvrir le panneau Snippets, l'outil tente de reconnaître le type de snippet :
+
+- **Message vert** : snippet reconnu, champs pré-remplis → modifiez et réinsérez
+- **Message orange** : sélection non reconnue, panneau vide → créez un nouveau snippet
+
+Snippets détectables : bloc dépliable, lien, image, image liée, bloc de code, citation, tableau, liste.

package/dist/starting-doc/4_reference/2026_04_11_17_31_[FUNDAMENTALS]_architecturer_une_documentation.md

@@ -0,0 +1,12 @@
+Il existe plusieurs approches pour organiser une documentation : par équipe, par produit, par date, par type de contenu…, chacune ayant ses avantages.
+[![Architecturer Une Documentation (Reference)](./images/architecturer_une_documentation_reference.png)](/diagram?id=d1775924007206)
+
+Personnellement j'utilise l'approche `Dàtaxis` que je trouve excellente pour structurer de documentations.<br/>
+Et je trouve que cela donne d'excellents résultats que ce soit chez mes clients, ou sur mes projets open source personnels.
+
+`Diataxis` distingue quatre types de contenus, chacun dans son dossier :
+
+- **1_tutorial** — des guides pas à pas pour apprendre en faisant (comme celui-ci)
+- **2_guide** — des recettes orientées tâche : "comment faire X ?"
+- **3_concept** — des explications pour comprendre le pourquoi et le comment
+- **4_reference** — des descriptions factuelles et exhaustives (API, config, glossaire)

package/dist/starting-doc/4_reference/2026_04_12_14_07_[FUNDAMENTALS]_dossiers_et_catgories.md

@@ -0,0 +1,89 @@
+# Dossiers et Catégories
+
+Dans Living Documentation, deux notions distinctes structurent la barre latérale : les **dossiers** et les **catégories**. Elles ne sont pas interchangeables.
+
+---
+
+## Les dossiers
+
+Un dossier correspond directement à un **répertoire sur le système de fichiers**.
+
+Living Documentation scanne le dossier de documentation de façon récursive. Chaque sous-répertoire devient un nœud collapsible dans la sidebar.
+
+```
+docs/
+├── adrs/              → dossier "Adrs" dans la sidebar
+│   └── tests/         → sous-dossier "Tests" (imbriqué)
+├── guides/            → dossier "Guides" dans la sidebar
+└── mon_doc.md         → document à la racine (pas de dossier)
+```
+
+**Règles :**
+- Les noms de dossiers sont affichés en *title case* (`adrs` → `Adrs`)
+- Un préfixe numérique (`1_`, `2_`, …) contrôle l'ordre d'affichage et est **masqué** dans l'interface (visible uniquement dans le tooltip au survol)
+- L'imbrication est illimitée
+
+---
+
+## Les catégories
+
+Une catégorie est extraite du **nom du fichier**, via le token `[Category]` du pattern de nommage.
+
+```
+2024_01_15_10_00_[Architecture]_choix_bdd.md
+                  ^^^^^^^^^^^^^^
+                  catégorie = "Architecture"
+```
+
+La catégorie est indépendante du dossier dans lequel le fichier se trouve. Un fichier `adrs/2024_01_15_[Architecture]_choix.md` appartient au dossier `Adrs` **et** à la catégorie `Architecture`.
+
+**Règles :**
+- Si le fichier ne contient pas de `[Category]`, il tombe dans la catégorie **General**
+- Les fichiers Extra Files sont toujours placés dans **General**
+- La catégorie **General** apparaît toujours en premier, à chaque niveau
+
+---
+
+## Comment la sidebar combine les deux
+
+À chaque niveau de l'arborescence, la sidebar affiche dans cet ordre :
+
+1. **General** (catégorie, toujours en tête)
+2. **Sous-dossiers** (triés alphabétiquement, ou par préfixe numérique)
+3. **Autres catégories** (triées alphabétiquement)
+
+Exemple concret :
+
+```
+docs/
+├── getting-started/
+│   ├── 2024_01_[Tutoriel]_premiers_pas.md
+│   └── 2024_01_[Tutoriel]_installation.md
+├── 2024_02_[Architecture]_choix_bdd.md
+└── README.md                              ← extra file (General)
+```
+
+Sidebar générée :
+
+```
+📂 (racine)
+  ├── General
+  │   └── README.md
+  ├── Getting-Started
+  │   └── Tutoriel
+  │       ├── Premiers Pas
+  │       └── Installation
+  └── Architecture
+      └── Choix Bdd
+```
+
+---
+
+## Récapitulatif
+
+| Notion     | Source                     | Contrôle                        | Affiché dans         |
+|------------|----------------------------|---------------------------------|----------------------|
+| Dossier    | Répertoire système de fichiers | Nom du répertoire (+ préfixe numérique) | Nœud collapsible dans la sidebar |
+| Catégorie  | Token `[Category]` dans le nom de fichier | Pattern de nommage configurable | Groupe sous chaque dossier |
+
+> Pour modifier le pattern de nommage, allez dans **⚙ Admin** → champ *Filename pattern*.