living-ai-documentation 1.2.0 → 1.4.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
@@ -54,8 +54,11 @@ Do not create durable documentation for trivial fixes, mechanical renames, or fo
54
54
  ## Progress Tracking
55
55
 
56
56
  The `DOCS_FOLDER/WORKLOG/` folder holds the operational state of in-progress tasks and the resume points between AI assistants. It does not replace ADRs.
57
+ The `DOCS_FOLDER/WORKLOG/` folder contains three complementary kinds of files; none of them replaces the durable ADRs that live under `DOCS_FOLDER/ADRS/`.
57
58
 
58
- `DOCS_FOLDER/WORKLOG/current-task.md` is the shared resume point. Every assistant must read it before resuming a task and update it before handing over when it has started, finished, interrupted, or left a known follow-up.
59
+ ### 1. `DOCS_FOLDER/WORKLOG/current-task.md` shared resume point
60
+
61
+ Every assistant must read it before resuming a task and update it before handing over when it has started, finished, interrupted, or left a known follow-up.
59
62
 
60
63
  The worklog must stay factual and useful for the next agent:
61
64
 
@@ -67,7 +70,50 @@ The worklog must stay factual and useful for the next agent:
67
70
  - remaining verifications;
68
71
  - next recommended action.
69
72
 
70
- Create a dedicated document under `DOCS_FOLDER/WORKLOG/` for an MVP ticket when more detailed tracking becomes necessary. Durable decisions stay in ADRs.
73
+ ### 2. `DOCS_FOLDER/WORKLOG/ROADMAP.md` ticket backlog
74
+
75
+ Ordered list of tickets needed to ship the product (or a major milestone). Format close to an ADR: frontmatter (`date`, `status`, `description`, `tags`) + Markdown body.
76
+
77
+ The starter ships an example roadmap — the user must replace it with the project's real tickets.
78
+
79
+ When a ticket is done, the agent:
80
+
81
+ 1. checks and strikes through the ticket's line in `ROADMAP.md`;
82
+ 2. creates a dedicated document under `DOCS_FOLDER/WORKLOG/` recording the realization (see section 3).
83
+
84
+ Checking convention inside the "Recommended order" section:
85
+
86
+ - `[ ]` or `[]` — ticket not started;
87
+ - `[x] ~~Ticket XX - ...~~` — ticket done, struck through for quick scanning.
88
+
89
+ ### 3. `DOCS_FOLDER/WORKLOG/YYYY_MM_DD_HH_mm_[WORKLOG]_ticket_XX_<slug>.md` — per-ticket realization record
90
+
91
+ Every time a roadmap ticket is completed, create a dedicated document under `DOCS_FOLDER/WORKLOG/`. The format looks like an ADR (same frontmatter) but the **semantics differ**:
92
+
93
+ - ADRs (`DOCS_FOLDER/ADRS/`) document the project's **durable decisions**: architecture, public contracts, structural conventions. They describe the **WHAT** and the **WHY**.
94
+ - per-ticket WORKLOG documents record the **realization** of a roadmap ticket: what was done, what choices were made during execution, what verifications were run. They describe **WHAT THE AGENT DID** for that specific ticket.
95
+
96
+ If a durable choice is made during a ticket (for example, picking a folder-structure convention), create an architectural ADR under `DOCS_FOLDER/ADRS/` and point the WORKLOG document to that ADR — do not duplicate the reasoning.
97
+
98
+ Recommended frontmatter for a per-ticket WORKLOG document:
99
+
100
+ ```markdown
101
+ ---
102
+ **date:** YYYY-MM-DD
103
+ **status:** To Be Validated
104
+ **description:** One sentence summarizing what was done for this ticket.
105
+ **tags:** worklog, ticket, <domain slugs>
106
+ ---
107
+ ```
108
+
109
+ Recommended sections in the body:
110
+
111
+ - **Context** — short reminder of the ticket and its goal (one paragraph, link to `ROADMAP.md`);
112
+ - **Realization** — factual list of what was done;
113
+ - **Choices made** — technical decisions taken during the ticket. Point to an ADR if the decision is durable;
114
+ - **Verifications** — tests passed, manual validations;
115
+ - **Follow-ups** — points of attention for the next tickets;
116
+ - **Related documents** — link to `ROADMAP.md` and any ADR(s).
71
117
 
72
118
  ## ADRs
73
119
 
@@ -9,7 +9,7 @@ Before making changes:
9
9
  3. Read `DOCS_FOLDER/AI/PROJECT-USEFUL-COMMANDS.md` to know the development, build, test, lint, and setup commands.
10
10
  4. Read `memory/MEMORY.md` and load only useful memory files.
11
11
  5. Read rules in `DOCS_FOLDER/AI/rules/*.md`.
12
- 6. Read `DOCS_FOLDER/WORKLOG/current-task.md` if present to resume the state of the current task.
12
+ 6. Read `DOCS_FOLDER/WORKLOG/current-task.md` if present to resume the state of the current task, and `DOCS_FOLDER/WORKLOG/ROADMAP.md` if present to know which ticket to pick up next.
13
13
  7. Inspect ADRs in `DOCS_FOLDER/ADRS/` by reading `description` and `tags` first, then open the full ADR only when relevant.
14
14
  8. Check whether the `living-ai-documentation` MCP is available and use it to create, update, and keep documentation reliable when the task touches a decision, rule, command, stack, or technical document.
15
15
 
@@ -9,7 +9,7 @@ Before making changes:
9
9
  3. Read `DOCS_FOLDER/AI/PROJECT-USEFUL-COMMANDS.md` to know the development, build, test, lint, and setup commands.
10
10
  4. Read `memory/MEMORY.md` and load only useful memory files.
11
11
  5. Read rules in `DOCS_FOLDER/AI/rules/*.md`.
12
- 6. Read `DOCS_FOLDER/WORKLOG/current-task.md` if present to resume the state of the current task.
12
+ 6. Read `DOCS_FOLDER/WORKLOG/current-task.md` if present to resume the state of the current task, and `DOCS_FOLDER/WORKLOG/ROADMAP.md` if present to know which ticket to pick up next.
13
13
  7. Inspect ADRs in `DOCS_FOLDER/ADRS/` by reading `description` and `tags` first, then open the full ADR only when relevant.
14
14
  8. Check whether the `living-ai-documentation` MCP is available and use it to create, update, and keep documentation reliable when the task touches a decision, rule, command, stack, or technical document.
15
15
 
@@ -0,0 +1,41 @@
1
+ ---
2
+ **date:** 2026-01-01
3
+ **description:** Example ticket roadmap — an ordered backlog used to deliver the product incrementally, with a visible acceptance criterion per ticket. This roadmap is written by the user; it is shipped only as an example.
4
+ **tags:** roadmap, tickets, mvp, planning
5
+ ---
6
+
7
+ # Tickets (example)
8
+
9
+ > This is an example roadmap shipped by the Living Documentation starter. Replace the tickets below with the project's real backlog. AI agents must rely on this roadmap to decide which ticket to pick up next.
10
+
11
+ ## Checking convention
12
+
13
+ - `[ ]` or `[]` — ticket not started;
14
+ - `[x] ~~Ticket XX - ...~~` — ticket done, struck through for quick scanning.
15
+
16
+ ## Recommended order
17
+
18
+ 1. [x] ~~Ticket 01 - Initialize the project~~
19
+ 2. [ ] Ticket 02 - First screen of the nominal flow
20
+
21
+ > This is an example ticket for the user (remove this line once the real roadmap is written)
22
+
23
+ ## Ticket 01 - Initialize the project
24
+
25
+ Goal: lay down the application foundations, ready to evolve.
26
+
27
+ Tasks:
28
+
29
+ - create the project structure (folder layout, baseline dependencies);
30
+ - configure linting and formatting;
31
+ - add a minimal layout and a routing system;
32
+ - verify that the application starts locally.
33
+
34
+ Acceptance criteria:
35
+
36
+ - the application starts locally without errors;
37
+ - the main routes exist;
38
+ - the code is typed if the stack allows it;
39
+ - no backend is required at this stage.
40
+
41
+ ## Ticket 02 - Complete me ...
@@ -54,8 +54,11 @@ Ne pas créer de documentation durable pour les corrections triviales, renommage
54
54
  ## Suivi de progression
55
55
 
56
56
  Le dossier `DOCS_FOLDER/WORKLOG/` contient l'état opérationnel des tâches en cours et les points de reprise entre assistants IA. Il ne remplace pas les ADR.
57
+ Le dossier `DOCS_FOLDER/WORKLOG/` contient trois types de fichiers complémentaires, aucun d'entre eux ne remplace les ADR durables qui vivent dans `DOCS_FOLDER/ADRS/`.
57
58
 
58
- `DOCS_FOLDER/WORKLOG/current-task.md` est le point de reprise partagé. Tout assistant doit le lire avant de reprendre une tâche et le mettre à jour avant de rendre la main lorsqu'il a commencé, terminé, interrompu ou laissé une suite connue.
59
+ ### 1. `DOCS_FOLDER/WORKLOG/current-task.md` point de reprise partagé
60
+
61
+ Tout assistant doit le lire avant de reprendre une tâche et le mettre à jour avant de rendre la main lorsqu'il a commencé, terminé, interrompu ou laissé une suite connue.
59
62
 
60
63
  Le worklog doit rester factuel et utile pour l'agent suivant :
61
64
 
@@ -67,7 +70,50 @@ Le worklog doit rester factuel et utile pour l'agent suivant :
67
70
  - vérifications restantes ;
68
71
  - prochaine action recommandée.
69
72
 
70
- Créer un document dédié dans `DOCS_FOLDER/WORKLOG/` pour un ticket MVP lorsqu'un suivi plus détaillé devient nécessaire. Les décisions durables restent dans les ADR.
73
+ ### 2. `DOCS_FOLDER/WORKLOG/ROADMAP.md` backlog de tickets
74
+
75
+ Liste ordonnée des tickets à réaliser pour livrer le produit (ou une grande étape). Format proche d'un ADR : frontmatter (`date`, `status`, `description`, `tags`) + corps Markdown.
76
+
77
+ Le starter livre une roadmap d'exemple — l'utilisateur doit la remplacer par les tickets réels du projet.
78
+
79
+ Quand un ticket est terminé, l'agent :
80
+
81
+ 1. coche et barre la ligne du ticket dans `ROADMAP.md` ;
82
+ 2. crée un document dédié dans `DOCS_FOLDER/WORKLOG/` qui consigne la réalisation (voir point 3).
83
+
84
+ Convention de cochage dans la section « Ordre recommandé » :
85
+
86
+ - `[ ]` ou `[]` — ticket non démarré ;
87
+ - `[x] ~~Ticket XX - ...~~` — ticket terminé, barré pour visualisation rapide.
88
+
89
+ ### 3. `DOCS_FOLDER/WORKLOG/YYYY_MM_DD_HH_mm_[WORKLOG]_ticket_XX_<slug>.md` — trace de réalisation par ticket
90
+
91
+ À chaque fois qu'un ticket de roadmap est terminé, créer un document dédié dans `DOCS_FOLDER/WORKLOG/`. Le format ressemble à un ADR (même frontmatter) mais la **sémantique est différente** :
92
+
93
+ - les ADR (`DOCS_FOLDER/ADRS/`) documentent les **décisions durables** du projet : architecture, contrats publics, conventions structurantes. Ils décrivent le **QUOI** et le **POURQUOI**.
94
+ - les documents WORKLOG par ticket documentent la **réalisation** d'un ticket de roadmap : ce qui a été fait, les choix retenus pendant l'exécution, les vérifications passées. Ils décrivent **CE QUE L'AGENT A FAIT** pour ce ticket précis.
95
+
96
+ Si un choix durable est pris pendant la réalisation d'un ticket (par exemple, le choix d'une convention de structure de dossiers), créer un ADR architectural dans `DOCS_FOLDER/ADRS/` et faire pointer le document WORKLOG vers cet ADR — ne pas dupliquer le raisonnement.
97
+
98
+ Frontmatter recommandé du document WORKLOG par ticket :
99
+
100
+ ```markdown
101
+ ---
102
+ **date:** YYYY-MM-DD
103
+ **status:** To Be Validated
104
+ **description:** Une phrase qui résume ce qui a été fait pour ce ticket.
105
+ **tags:** worklog, ticket, <slugs métiers>
106
+ ---
107
+ ```
108
+
109
+ Sections recommandées dans le corps :
110
+
111
+ - **Contexte** — rappel du ticket et de son objectif (un paragraphe court, lien vers `ROADMAP.md`) ;
112
+ - **Réalisation** — liste factuelle de ce qui a été fait ;
113
+ - **Choix retenus** — décisions techniques prises pendant le ticket. Pointer vers un ADR si la décision est durable ;
114
+ - **Vérifications** — tests passés, validations manuelles ;
115
+ - **Suites éventuelles** — points de vigilance pour les tickets suivants ;
116
+ - **Documents liés** — lien vers `ROADMAP.md` et ADR(s) éventuel(s).
71
117
 
72
118
  ## ADR
73
119
 
@@ -9,7 +9,7 @@ Avant toute modification :
9
9
  3. Lire `DOCS_FOLDER/AI/PROJECT-USEFUL-COMMANDS.md` pour connaître les commandes de développement, build, test, lint et setup.
10
10
  4. Lire `memory/MEMORY.md` et charger seulement les fichiers mémoire utiles à la tâche.
11
11
  5. Lire toutes les règles dans `DOCS_FOLDER/AI/rules/*.md`.
12
- 6. Lire `DOCS_FOLDER/WORKLOG/current-task.md` si présent pour reprendre l'état de la tâche courante.
12
+ 6. Lire `DOCS_FOLDER/WORKLOG/current-task.md` si présent pour reprendre l'état de la tâche courante, et `DOCS_FOLDER/WORKLOG/ROADMAP.md` si présent pour savoir quel ticket attaquer ensuite.
13
13
  7. Inspecter les ADR dans `DOCS_FOLDER/ADRS/` en lisant d'abord `description` et `tags`, puis ouvrir l'ADR complet seulement s'il est pertinent.
14
14
  8. Vérifier si le MCP `living-ai-documentation` est disponible et l'utiliser pour créer, mettre à jour et fiabiliser la documentation lorsque la tâche touche une décision, une règle, une commande, la stack ou un document technique.
15
15
 
@@ -9,7 +9,7 @@ Avant toute modification :
9
9
  3. Lire `DOCS_FOLDER/AI/PROJECT-USEFUL-COMMANDS.md` pour connaître les commandes de développement, build, test, lint et setup.
10
10
  4. Lire `memory/MEMORY.md` et charger seulement les fichiers mémoire utiles à la tâche.
11
11
  5. Lire toutes les règles dans `DOCS_FOLDER/AI/rules/*.md`.
12
- 6. Lire `DOCS_FOLDER/WORKLOG/current-task.md` si présent pour reprendre l'état de la tâche courante.
12
+ 6. Lire `DOCS_FOLDER/WORKLOG/current-task.md` si présent pour reprendre l'état de la tâche courante, et `DOCS_FOLDER/WORKLOG/ROADMAP.md` si présent pour savoir quel ticket attaquer ensuite.
13
13
  7. Inspecter les ADR dans `DOCS_FOLDER/ADRS/` en lisant d'abord `description` et `tags`, puis ouvrir l'ADR complet seulement s'il est pertinent.
14
14
  8. Vérifier si le MCP `living-ai-documentation` est disponible et l'utiliser pour créer, mettre à jour et fiabiliser la documentation lorsque la tâche touche une décision, une règle, une commande, la stack ou un document technique.
15
15
 
@@ -0,0 +1,41 @@
1
+ ---
2
+ **date:** 2026-01-01
3
+ **description:** Exemple de roadmap de tickets — backlog ordonné pour livrer progressivement le produit, avec un critère d'acceptation visible par ticket. Cette roadmap est écrite par l'utilisateur, elle est fournie à titre d'exemple.
4
+ **tags:** roadmap, tickets, mvp, planning
5
+ ---
6
+
7
+ # Tickets (exemple)
8
+
9
+ > Ceci est une roadmap d'exemple fournie par le starter Living Documentation. Remplacer les tickets ci-dessous par le backlog réel du projet. Les agents IA doivent se baser sur cette roadmap pour savoir quel ticket attaquer ensuite.
10
+
11
+ ## Convention de cochage
12
+
13
+ - `[ ]` ou `[]` — ticket non démarré ;
14
+ - `[x] ~~Ticket XX - ...~~` — ticket terminé, barré pour la lisibilité.
15
+
16
+ ## Ordre recommandé
17
+
18
+ 1. [x] ~~Ticket 01 - Initialiser le projet~~
19
+ 2. [ ] Ticket 02 - Premier écran du parcours nominal
20
+
21
+ > Ceci est un exemple de ticket pour l'utilisateur (supprimer cette ligne une fois la vraie roadmap écrite)
22
+
23
+ ## Ticket 01 - Initialiser le projet
24
+
25
+ Objectif : poser la base applicative, prête à évoluer.
26
+
27
+ Tâches :
28
+
29
+ - créer la structure du projet (arborescence, dépendances de base) ;
30
+ - configurer le linting et le formatage ;
31
+ - ajouter un layout minimal et un système de routes ;
32
+ - valider que l'application démarre localement.
33
+
34
+ Critères d'acceptation :
35
+
36
+ - l'application démarre localement sans erreur ;
37
+ - les routes principales existent ;
38
+ - le code est typé si la stack le permet ;
39
+ - aucun backend n'est requis à ce stade.
40
+
41
+ ## Ticket 02 - Complétez ...
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "living-ai-documentation",
3
- "version": "1.2.0",
3
+ "version": "1.4.0",
4
4
  "description": "Local Markdown documentation hub with a built-in MCP server — coding agents create ADRs, draw diagrams and detect drift while you code.",
5
5
  "main": "dist/src/server.js",
6
6
  "bin": {
@@ -57,6 +57,9 @@
57
57
  "express": "5.2.1",
58
58
  "marked": "12.0.2"
59
59
  },
60
+ "overrides": {
61
+ "glob": "^13.0.0"
62
+ },
60
63
  "devDependencies": {
61
64
  "@playwright/test": "^1.59.1",
62
65
  "@types/archiver": "^7.0.0",