Suivi, roadmap et checklists — Implémentations
Compléments de préambule (archives) : hub SUIVI_ROADMAP_COMPLEMENTS ; segments mensuels complements/ — blocs Complément horodatés ; le résumé agent court peut rester en fin de ce bloc ou être recopié en tête du SUIVI principal lors des sessions.
Partie B (roadmap §0–§9, tableaux §3, Marty §9) : SUIVI_ROADMAP_PARTIE_B.
Historique agent : SUIVI_ROADMAP_HISTORIQUE_AGENT.
Mode d'emploi — comment remplir et utiliser ce document
Ce fichier est le point d'entrée unique pour piloter le suivi de la release 3.0.0 et au-delà. Il consolide les todolists, checklists, roadmap et traçabilité qui étaient auparavant dispersées dans plusieurs fichiers. Voici les règles à respecter pour conserver l'unité et la lisibilité dans la durée.
Principes directeurs
- Source de vérité centralisée — toute tâche, tout changement de statut, toute checklist complétée doit être portée ici. Le détail métier/technique reste dans la SPEC ou le plan concerné ; ce document centralise l'état et les renvois.
- Pas de doublon narratif — ne pas dupliquer un historique déjà présent dans le CHANGELOG ou dans une SPEC ; un renvoi suffit. Les entrées de l'Historique des mises à jour agent sont volontairement courtes (une ligne par session) pour permettre la recherche textuelle.
- Structure stable — les huit parties (A–H) et le découpage du document ne changent pas. Les sections numérotées à l'intérieur d'une partie peuvent être enrichies mais jamais renommées ni réordonnées (les ancres Markdown servent de référence croisée).
Quand mettre à jour
| Événement | Que faire ici |
|---|---|
| Implémentation livrée (code fusionné) | Cocher la case dans Partie A §2–§4 ou dans Partie B §0 (backlog agent) ; mettre à jour le statut dans le tableau Partie B §3 (A faire → Fait (date)) et le tableau Partie D (SPECs) si la spec passe en Réalisé ou change de statut |
| Modification de SPEC (nouveau, fusion, changement de statut) | Mettre à jour Partie D (colonne Statut) ; si la roadmap est impactée, ajuster Partie B §3 / §8.x et Partie F §8.1 / §8.1bis |
| Checklist complétée (déploiement, smoke, audit a11y…) | Cocher dans Partie A §2–§3 ; marquer dans Partie C si la checklist y figure |
| Nouveau stub documenté ou périmètre optionnel | Ajouter ou mettre à jour le tableau §8.1sexies (Partie F) et la SPEC source |
| Session agent (Cursor) | Ajouter une ligne horodatée dans l'Historique des mises à jour agent ; mettre à jour la ligne résumé en tête du document |
| Modification structure docs/ | Mettre à jour l'index plan directeur (index) et exécuter pnpm run structure:update |
Comment remplir les entrées
- Statuts :
A faire,Fait (AAAA-MM-JJ),Livré dépôt (AAAA-MM-JJ)(critères code/docs tenus dans le dépôt),À valider hors dépôt(recette instance, perf, homologation infra — ATTENTES, smoke, runbooks),Bloqué opérateur(ex. Phase 0.1–0.3sans déploiement réel — règle §2 ci-dessous),Backlogvision G V*),Socle OK,Migré,Sous-périmètre clos. Ne plus utiliser le seul libellé « Partiel » (ambigu) : préférer Livré dépôt + À valider / Backlog explicites. - Migration libellés (2026-04-01) : les anciens libellés ambigus (« Partiel », « Partiel avancé ») sont remplacés par Livré dépôt + précision du résidu (À valider ou Backlog).
- Cases à cocher :
[ ]→[x]uniquement quand la preuve existe (code livré, test passé, rapport rédigé). Ne jamais cocher §2 (0.1–0.3) sans déploiement réel et preuves. - Renvois : liens relatifs vers les SPECs, plans et audits du dépôt (pas de liens absolus).
- Ancres : ne pas modifier les ancres existantes (
#0-backlog-exécuteur-agent-audit-transverse-2026-03-27, etc.) car elles sont référencées depuis d'autres documents.
Comment utiliser ce document
- Lecture rapide : consulter le Résumé agent (prochaine action, blocages), puis la Table des matières.
- Planification : la Partie B §3 est le tableau de planification ordonnée (1→N, N=126 au 2026-04-01 : 63–68 = Marty P15 / 5.22–5.27, 69–78 = Perf/Bugs P16 / F1–F10, 79–84 = D1–D6, 85–106 = G1–G22, 107–126 = suites Arch-G / E / SPECs / vision G-V) ; synthèse P15 : §6.5 + §9.4 ; séquence P16 : §6.5bis ; P17 (Arch-G suite) : §6.6 ; l'ordre canonique est complété par .
- Agent Cursor : lire le §0 de la Partie B (backlog priorisé P0→P3), prendre la prochaine case non cochée et enchaîner. Après chaque livraison : CHANGELOG,
code-docs-sync, puis cocher ici. - Travail parallèle (plusieurs agents / pistes) : déclarer la piste et la branche dans (tableau claim + Session en cours) ; à la clôture, aligner Partie B / §3 et une ligne Complément en tête de ce fichier si besoin — en-tête PARALLEL : section Intégration SUIVI — roadmap et vérité d’état (rôles SUIVI vs journal).
- Validation : après mise à jour, exécuter
pnpm run docs:check -- --strictetpnpm run docs:check:duplicates -- --strict.
Relation avec les autres documents
| Document | Rôle | Ce SUIVI |
|---|---|---|
| SPECs (SPEC *) | Détail métier / technique | Renvoie vers la SPEC ; porte le statut dans Partie D |
| CHANGELOG (CHANGELOG) | Journal des modifications code → docs | Complète le CHANGELOG en même temps que le SUIVI |
| Phases 0 → 6 détaillées | Partie B §3 est l'ordre d'exécution global | |
| Fil d'exécution résumé linéaire | Complémentaire au §3 ; lecture séquentielle | |
| Statut de chaque SPEC (§0) | Croisé avec Partie D ; garder cohérent | |
| (plan directeur) | Hub documentaire et décisions transverses | Mettre à jour si un document est ajouté/déplacé |
| Journal multi-agents : sessions datées, tableau des pistes (claim), append-only | Complémentaire : ne remplace pas ce SUIVI ; toute clôture de piste = mise à jour ici (statuts §3, §0, Partie D) et ligne + journal PARALLEL ; voir §1bis — Claim branche, journal parallèle | |
| Règle code-docs-sync.mdc | Obligations de synchronisation code ↔ docs | S'applique à chaque modification de ce SUIVI |
Index des fragments (corps)
| Fragment | Fichier |
|---|---|
| Résumé agent | |
| Carte d’orchestration | |
| Partie A | |
| Partie C | |
| Partie D | |
| Partie E | |
| Partie G | |
| Partie H |