# 26 — Roadmap : le format `roadmap` et roadmap.recit.dev **Statut : proposé · Phase : P9 · Mis à jour : 02/11/2026.** Ce plan détaille la phase P9 de [06 · Feuille de route](/06-roadmap) : le format `roadmap`, la fondation `@recit/time` dans sa première moitié (dates, trimestres, ICS en écriture), et le site roadmap.recit.dev. Il part de la spécification de [08 · Formats](/08-formats) §4, qu'il précise sans la contredire ; là où le code ou une règle acceptée oblige à s'en écarter, l'écart est posé en question ouverte (§12). Il s'appuie sur le code tel qu'il est le 02/11/2026, pas sur les textes plus anciens : `packages/core/src/schema`, `packages/formats/motion`, `packages/cli`, `packages/integrations/site-stories`, `examples/motion-hello` et `e2e/site-motion.spec.ts`. Il dépend de [02 · Architecture](/02-architecture), de [03 · Packaging](/03-packaging) §6 et §8, de [07 · Domaines](/07-domaines), de [09 · Langues et JSON](/09-langues-et-json), de [12 · Glossaire et annuaire](/12-glossaire-annuaire) (l'analyseur `{k=v}`, lot DI0.2, créé avant ce plan), de [15 · Export PDF](/15-export-pdf) (chaîne d'impression, manifeste `exports.json`) et de [21 · Tests](/21-tests). Le calendrier, qui consomme les jalons de la roadmap, est le plan 27. Chaque choix porte une **recommandation**. Rien n'est implémenté avant l'accord de l'utilisateur. ## 1. Pourquoi - **Une roadmap est une story comme une autre.** Un titre, des pistes, des éléments datés ou non, des jalons : c'est un document que l'on écrit, que l'on traduit et que l'on publie. Aujourd'hui, on l'écrit dans un outil fermé (GitHub Projects, Linear, Notion), ou dans un Markdown sans structure que personne ne sait afficher en frise. Récit donne les deux : le texte en Markdown, les statuts en JSON typé, et trois vues. - **Le format prouve la promesse « une source, plusieurs rendus » sur des données.** Le deck et le motion rendent de la prose ; la roadmap rend une liste d'éléments typés (statut, dates, dépendances) en trois vues, un PDF, un fichier ICS et un flux RSS, depuis la même source. - **Récit en a besoin pour lui-même.** Le plan [06 · Feuille de route](/06-roadmap) et la page `sites/vision/pages/roadmap.mdx` sont deux roadmaps écrites à la main, en deux langues, qui dérivent l'une de l'autre. Le format est la manière de les tenir d'une seule source (§7). - **Il prépare le calendrier.** Les jalons datés passent dans le calendrier (pont roadmap → calendar, P10, plan 27) par le même type de date et le même écrivain ICS. ## 2. Ce qui existe déjà et qu'on réutilise | Brique | État réel au 02/11/2026 | Ce que P9 en fait | | ------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------- | | `RoadmapSourceSchema` | `packages/core/src/schema/source.ts` : `genericSource("roadmap")`, un `looseObject` sans champ typé (règle L6 : « les champs typés arrivent avec le format ») | remplacé par un `strictObject` typé (§3.3), comme `MotionSourceSchema` | | Convertisseur Markdown ⇄ JSON | `packages/core/src/schema/convert.ts` : un convertisseur de scène par format (`deckScene`, `docsScene`, `motionScene`), choisi par une cascade de ternaires ; `genericScene` pour les autres | ajout de `roadmapScene` et de son inverse, et passage de la cascade à une table par format (§3.4) | | Compilation d'un JSON | `compileStorySource` (`compile/compile-story.ts`) passe le JSON en Markdown par `sourceToMarkdown`, puis compile ce Markdown : **le Markdown est le pivot de compilation** | le format relit `scene.mdast` et `scene.attrs`, comme `@recit/motion` (`source/story.ts`) ; le pivot doit être exact | | Attributs de séparateur | `parser/split-slides.ts` : `key=value`, valeurs entre guillemets, forme JSON `--- {…}` ; coercition des nombres (`id=3` reste une chaîne, mais `date=2027` deviendrait un nombre) | les dates sont relues en chaînes par le schéma du format (§3.5) | | Compagnon (`kind: "sidecar"`) | `mergeSidecar` (`schema/assemble.ts`) fusionne par `id` de **scène** ; un `id` inconnu est une erreur (`sidecar-unknown-scene`) | étendu aux **listes à clé** (les `items` d'une piste), même règle d'erreur (§3.4) | | Test d'aller-retour | `core/src/__tests__/source-conversion.spec.ts` parcourt `examples/` et `sites/*/stories` | couvre `examples/roadmap-product` et la roadmap de Récit sans rien ajouter | | JSON Schema | `schema/json-schema.ts`, `recit schema [name]`, `schemaUrl("roadmap")` | `roadmap.json` publié avec les autres | | Packages | `packages/formats/roadmap` et `packages/time` : squelettes privés (`export {}`), tags `scope:format` et `scope:foundation` déjà posés | deviennent publiés (exports à trois conditions, `tsdown`, `LICENSE.md`, `release.projects`) | | Analyseur `{k=v}` | à créer en DI0.2 ([12 · Glossaire et annuaire](/12-glossaire-annuaire)), un seul module dans `@recit/core` | réutilisé tel quel pour les items | | Intégration aux sites | `site-stories/src/plugin.tsx` choisit la vue par `story.format === "motion" ? : ` ; `vite.ts` calcule le film au build (`storyMotion`) | une table de visionneuses par format (§6.1), à aligner avec le plan 23 | | Chaîne PDF, contrat d'impression, `exports.json` | spécifiés par [15 · Export PDF](/15-export-pdf) (PDF0 à PDF1 en P6) : `?print=1`, `whenPrintable()`, `@recit/paged/runner`, `ExportManifestSchema` | extension `RoadmapPdfOptionsSchema`, variantes `ics` et `rss` du manifeste | | Graphiques | d3 sans DOM (`d3-scale`, `d3-shape`), tranché le 24/10 (question 10 de 06) ; dans le lockfile, aujourd'hui seulement en dépendance transitive | la frise est un SVG calculé au build par `d3-scale` (`scaleUtc`) : aucune bibliothèque de plus | | Composants de site | `@recit/site-kit` : `FormatHero`, `Gallery`, `ExportPanel`, `BridgeCard`… ([07 · Domaines](/07-domaines) §4) ; `StatusBadge` existe déjà (statut d'un **format**) | réutilisés ; le badge d'un élément de roadmap prend un autre nom (`RoadmapStatus`), un mot par chose | | Horloge | aucune : rien dans Récit ne dépend encore de la date du jour | une seule horloge de build, `SOURCE_DATE_EPOCH` (§3.5) | ## 3. Le modèle ### 3.1 Une scène = une piste ou un jalon Accepté dans [08 · Formats](/08-formats) §0 et repris tel quel : une scène est une **piste** (un groupe d'éléments : « Editor », « API ») ou un **jalon** (une date qui compte : « 1.0 release »). Les **éléments** vivent à l'intérieur d'une piste, comme les entrées d'une section d'annuaire ([12 · Glossaire et annuaire](/12-glossaire-annuaire) D2). Le seul séparateur reste `---`. Les vues travaillent sur les éléments, pas sur les scènes : now-next-later et kanban répartissent les éléments en colonnes, la frise place les éléments sur leurs pistes et les jalons sur l'axe. ### 3.2 La syntaxe Markdown ```md --- title: Lorem Product Roadmap format: roadmap lang: en view: now-next-later # now-next-later | timeline | kanban period: quarter # month | quarter | half : graduation de la frise statuses: [planned, in-progress, shipped, paused] --- --- id=editor ## Editor Lorem ipsum dolor sit amet, consectetur adipiscing elit. - [x] Lorem ipsum export {id=export quarter=2026-Q3 end=2026-09-18 link=https://example.com} - [ ] Dolor sit amet sync {id=sync status=in-progress start=2026-10-01 end=2026-12-15 owner=team-lorem} - [ ] Consectetur offline mode {id=offline quarter=2027-Q1 tags=mobile,beta horizon=later} :::item{id=offline} Sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. ![Lorem sketch](./img/offline.png) ::: --- id=api ## API - [ ] Adipiscing webhooks {id=webhooks quarter=2027-Q1 depends=sync} --- type=milestone id=v1 date=2027-03-31 ## 1.0 release Ut enim ad minim veniam. ``` | Élément | Rôle | | -------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `--- id=…` | une piste. Le premier titre est son libellé, la prose qui suit (avant la liste) sa description | | item de liste terminé par `{…}` | un élément. Attributs : `id` (obligatoire, §3.6), `status`, `horizon`, `start`, `end`, `quarter`, `owner`, `tags`, `link`, `depends`. `[x]` vaut `status=shipped` par défaut | | `[ ]` sans `status` | premier statut de `statuses` (`planned` par défaut) | | `:::item{id=…}` | description longue d'un élément, Markdown complet (accepté dans 08) | | `--- type=milestone id=… date=…` | un jalon, sur la frise et dans l'ICS. Le corps est sa description (voir la question 3 sur `type=`) | | compagnon `product.json` (`kind: "sidecar"`) | statuts, dates et propriétaires tenus par un outil (CI, script), le texte restant dans le `.md` (09 §1) | `08 · Formats` écrivait `--- lane=editor id=editor` : l'attribut `lane=` répète l'`id` et ne sert à rien d'autre, puisque toute scène qui n'est pas un jalon est une piste. Recommandation : `--- id=…` seul ; `lane=` n'existe pas (question 8). Les attributs `{k=v}` suivent la grammaire du séparateur (mêmes guillemets, mêmes listes séparées par des virgules) ; c'est l'analyseur unique de DI0.2. Un item sans `{…}` est une ligne de prose de la piste, pas un élément : une liste ordinaire reste possible dans la description. ### 3.3 Le schéma (dans `@recit/core/schema`) Les schémas de source restent dans `packages/core/src/schema/source.ts`, à côté de ceux du deck et du motion ; les types en sont dérivés (`z.infer`), et `@recit/roadmap` les importe sans les redéfinir (règle d'`AGENTS.md`). Les primitives de date sont partagées avec le calendrier (plan 27) et vivent dans un module à part, `packages/core/src/schema/time.ts`, importé par les deux. ```ts import * as z from "zod/mini"; // packages/core/src/schema/time.ts — shared by roadmap (P9) and calendar (P10) /** A calendar date without time or zone: "2026-11-02" */ export const PlainDateSchema = z .string() .check(z.regex(/^\d{4}-\d{2}-\d{2}$/), z.refine(isValidPlainDate, { message: "invalid date" })); /** "2026-Q3" */ export const QuarterSchema = z.string().check(z.regex(/^\d{4}-Q[1-4]$/)); // packages/core/src/schema/source.ts export const ROADMAP_VIEWS = ["now-next-later", "timeline", "kanban"] as const; export const ROADMAP_HORIZONS = ["now", "next", "later"] as const; export const RoadmapItemSourceSchema = z.strictObject({ /** Required: anchor, RSS guid, sidecar key; stable across languages */ id: z.string().check(z.regex(/^[a-z0-9][\w-]*$/)), title: LocalizedSchema, /** One of settings.statuses; checked once the settings are known */ status: z.optional(z.string()), /** Column of the now-next-later view; derived from the status when absent */ horizon: z.optional(z.enum(ROADMAP_HORIZONS)), start: z.optional(PlainDateSchema), end: z.optional(PlainDateSchema), quarter: z.optional(QuarterSchema), owner: z.optional(z.string()), tags: z.optional(z.array(z.string())), link: z.optional(z.url()), /** Ids of other items of the same story */ depends: z.optional(z.array(z.string())), /** The :::item{id} block (Markdown) */ description: z.optional(LocalizedSchema), }); export const RoadmapSceneSourceSchema = z.strictObject({ id: sceneFields.id, /** A lane unless it is a milestone */ type: z.optional(z.enum(["milestone"])), title: z.optional(LocalizedSchema), /** Milestone date */ date: z.optional(PlainDateSchema), /** Prose of the lane or milestone (before the list) */ body: sceneFields.body, notes: sceneFields.notes, attrs: sceneFields.attrs, items: z.optional(z.array(RoadmapItemSourceSchema)), }); export const RoadmapSettingsSourceSchema = z.strictObject({ view: z.optional(z.enum(ROADMAP_VIEWS)), period: z.optional(z.enum(["month", "quarter", "half"])), statuses: z.optional(z.array(z.string()).check(z.minLength(1))), /** The status that means "done": changelog, RSS, [x] (default shipped) */ done: z.optional(z.string()), /** Status → column when an item has no horizon */ horizons: z.optional(z.partialRecord(z.enum(ROADMAP_HORIZONS), z.array(z.string()))), /** Labels of custom statuses; the default ones come from the UI strings */ statusLabels: z.optional(z.record(z.string(), LocalizedSchema)), ics: z.optional(z.strictObject({ items: z.optional(z.boolean()) })), // pdf: RoadmapPdfOptionsSchema, added by RM3 (15 §3.2: no field before its phase) }); export const RoadmapSourceSchema = z.strictObject({ ...storyFields, format: z.literal("roadmap"), settings: z.optional(RoadmapSettingsSourceSchema), scenes: z.array(RoadmapSceneSourceSchema), }); ``` Les noms exacts de l'API zod/mini (`z.partialRecord`, `z.url`) sont à vérifier à l'implémentation, comme dans [15 · Export PDF](/15-export-pdf) §3.2 ; le principe est fixe. Les défauts (`view: now-next-later`, `period: quarter`, `statuses`, `done: shipped`, et la table `horizons: { now: [in-progress], next: [planned], later: [paused] }`) sont posés par la section `roadmap:` de `recit.config` (`RoadmapConfigSchema`, avec `.prefault({})`, règle d'`AGENTS.md`), pas par le schéma de source : la source dit ce que l'auteur a écrit, la config résolue dit ce qui s'applique. Les réglages s'écrivent à plat dans le frontmatter (08, « Réglages à plat »). Contrôles portés par le schéma (`z.refine` au niveau de la story, avec chemin JSON) : `end` avant `start`, `quarter` et `start`/`end` qui se contredisent, `date` absent d'un jalon daté, `items` sur un jalon. Les contrôles qui demandent toute la story (dépendances, statuts connus) sont des diagnostics du format (§3.6), parce qu'ils doivent porter le numéro de ligne du Markdown. ### 3.4 Le jumeau et le compagnon **Le jumeau** (`kind: "story"`) est la même roadmap en JSON. Le convertisseur vit dans le cœur, comme celui du motion (`motionScene` de `convert.ts`) : - `markdownToSource` : le premier titre de la scène devient `title`, la prose avant la liste `body`, chaque item `{…}` un `items[]`, chaque `:::item{id}` la `description` de l'élément du même `id`, `type` et `date` du séparateur les champs typés, le reste `attrs` ; - `sourceToMarkdown` émet l'ordre canonique : titre, prose, liste, blocs `:::item`. Une prose écrite après la liste est déplacée avant elle, avec un avertissement (`roadmap-text-after-items`) ; la liste se réécrit sans perte ; - la cascade `format === "deck" ? … : format === "docs" ? …` devient une table `SCENE_CODECS: Record` (aller et retour), dans laquelle chaque format ajoute sa ligne. Le plan 23 (report) touche au même endroit : un seul mécanisme pour les deux. Exemple du jumeau de la piste `editor` ci-dessus : ```json { "id": "editor", "title": "Editor", "body": "Lorem ipsum dolor sit amet, consectetur adipiscing elit.", "items": [ { "id": "export", "title": "Lorem ipsum export", "status": "shipped", "quarter": "2026-Q3", "end": "2026-09-18", "link": "https://example.com" }, { "id": "sync", "title": "Dolor sit amet sync", "status": "in-progress", "start": "2026-10-01", "end": "2026-12-15", "owner": "team-lorem" }, { "id": "offline", "title": "Consectetur offline mode", "quarter": "2027-Q1", "tags": ["mobile", "beta"], "horizon": "later", "description": "Sed do eiusmod…" } ] } ``` `[x]` ne s'écrit pas dans le JSON : il est `status: "shipped"`. Au retour, un élément au statut `done` s'écrit `[x]` sans `status=`, les autres `[ ]` avec leur `status=` sauf s'il vaut le premier statut. L'aller-retour du test (`compile(md) == compile(toJson(md))`) passe donc par une forme canonique unique. **Le compagnon** (`kind: "sidecar"`) complète une piste par son `id`, comme aujourd'hui, et ses éléments **par leur `id`**. Dans le compagnon, les éléments s'écrivent en objet à clé, jamais en tableau, pour que la fusion soit sans ambiguïté : ```json { "kind": "sidecar", "version": 1, "scenes": { "editor": { "items": { "sync": { "status": "shipped", "end": "2026-11-28" }, "offline": { "owner": "team-ipsum" } } } } } ``` `mergeSidecar` gagne la notion de **liste à clé** : un champ déclaré comme tel par le format (`items` pour la roadmap ; `entries` pour l'annuaire du plan 12, qui en a le même besoin) se fusionne élément par élément. Un `id` d'élément inconnu est une erreur (`sidecar-unknown-item`), comme un `id` de scène inconnu ; le compagnon ne crée jamais d'élément et n'en retire jamais (règle d'`AGENTS.md` : un compagnon ne redéfinit pas la liste). La déclaration vit dans le cœur, à côté de `SCENE_CODECS`. C'est le chemin d'une synchronisation : un script lit GitHub Projects ou Linear et réécrit `product.json`, jamais le `.md`. Les scripts eux-mêmes restent hors du cœur et hors de P9 (08 §4). ### 3.5 Les dates - Une roadmap ne manie que des **dates civiles**, sans heure ni fuseau : `start`, `end`, `date` (jalon) sont des `PlainDate` (`2026-11-02`), `quarter` un trimestre (`2026-Q3`). C'est volontaire : une roadmap ne promet pas d'heure, et une date sans fuseau ne change pas de jour d'un pays à l'autre. Le fuseau n'apparaît qu'à l'export ICS (journées entières, `VALUE=DATE`) et RSS (minuit UTC du jour, écrit en RFC 822). - Les valeurs du séparateur sont relues en chaînes par le convertisseur du format : `date=2027` (que `coerceValue` transforme en nombre) produit l'erreur « date attendue `AAAA-MM-JJ` », jamais une date silencieusement fausse. - Trimestres, semestres et mois de la frise viennent de `@recit/time` (`quarterOf`, `quarterRange`, `halfOf`), calculés sur des dates civiles, sans `Temporal` : la moitié « roadmap » de la fondation n'a besoin d'aucun polyfill. `Temporal` n'arrive qu'avec le calendrier (plan 27). - **Une seule horloge.** La frise trace « aujourd'hui », et l'avertissement « élément `planned` dont la date est passée » a besoin de la date du jour. `@recit/time` expose `today()` et `now()`, qui lisent `SOURCE_DATE_EPOCH` (la convention des builds reproductibles) quand elle est posée, sinon l'horloge réelle. Les e2e et les goldens la fixent ; rien d'autre ne lit `Date.now()`. Le rendu now-next-later, lui, ne dépend jamais de la date (§4.2). - Affichage par `Intl.DateTimeFormat` dans la langue de la page (`2026-Q3` devient « T3 2026 » en `fr`, « Q3 2026 » en `en`) ; les dates ne sont jamais localisables dans la source (09 §2.3). ### 3.6 Les règles de validation Toutes portent le fichier et la ligne (règle d'`AGENTS.md`), ou le chemin JSON pour un jumeau, par le même `Diagnostic` que le reste du cœur. | Code | Gravité | Cas | | -------------------------- | ------------- | ----------------------------------------------------------------------------------------- | | `roadmap-item-id` | erreur | item `{…}` sans `id`, ou `id` en double dans la story | | `roadmap-unknown-status` | erreur | `status` hors de `statuses` | | `roadmap-unknown-depends` | erreur | `depends` vers un `id` inconnu | | `roadmap-depends-cycle` | erreur | cycle de dépendances (le chemin du cycle est dans le message) | | `roadmap-date-order` | erreur | `end` avant `start`, ou `start`/`end` hors du `quarter` donné | | `roadmap-invalid-date` | erreur | date ou trimestre mal écrit (`2026-13-01`, `2026-Q5`, `2027`) | | `roadmap-milestone-items` | erreur | une liste d'éléments dans un jalon | | `roadmap-done-undated` | avertissement | élément au statut `done` sans `end` : il n'entre ni dans le changelog daté ni dans le RSS | | `roadmap-overdue` | avertissement | élément non terminé dont `end` est passé (horloge de build) ; jamais une erreur | | `roadmap-text-after-items` | avertissement | prose après la liste d'une piste (déplacée avant, §3.4) | | `sidecar-unknown-item` | erreur | `id` d'élément du compagnon absent de la piste | `id` est obligatoire (recommandé, question 5) : un `id` déduit du titre changerait avec la langue, casserait la parité de `recit i18n check`, les ancres, les GUID du RSS et les clés du compagnon. ### 3.7 Les langues Textes localisables : `title` de la story, des pistes, des jalons et des éléments, `body`, `description`, `statusLabels`. Communs à toutes les langues : `id`, statuts, dates, `owner`, `tags`, `link`, `depends` (09 §2.3, §5). `recit i18n check` ajoute à la parité des scènes celle des éléments : un `id` d'élément présent dans `product.md` et absent de `product.fr.md` est une erreur, un statut ou une date différents aussi (attributs structurels). Les libellés des statuts par défaut entrent dans les packs `UI_STRINGS` (`packages/core/src/i18n/ui.ts`), en `en` et en `fr`. ## 4. Le rendu ### 4.1 Le modèle compilé `@recit/roadmap` compile une `Story` de format `roadmap` en un modèle de rendu, comme `@recit/motion` compile une story en `Film` : ```ts // packages/formats/roadmap/src/model.ts export const RoadmapSchema = z.strictObject({ title: z.string(), lang: LocaleTagSchema, view: z.enum(ROADMAP_VIEWS), period: z.enum(["month", "quarter", "half"]), statuses: z.array(z.strictObject({ id: z.string(), label: z.string(), done: z.boolean() })), lanes: z.array(RoadmapLaneSchema), // id, title, html, items (resolved: horizon, range, html) milestones: z.array(RoadmapMilestoneSchema), // id, title, date, html /** Today, from the build clock; only the timeline reads it */ today: PlainDateSchema, }); export type Roadmap = z.infer; export function storyToRoadmap(story: Story, options?: { file?: string }): RoadmapResult; ``` - Il relit `scene.mdast` (titres, liste, blocs `:::item`) et `scene.attrs`, jamais le texte brut ; c'est le chemin qui marche pour un `.md` comme pour un jumeau, puisque le JSON passe par le pivot Markdown (§2). - Les textes y sont déjà résolus dans une langue et rendus en HTML sanitizé par la chaîne du cœur. Le client ne reçoit que ce modèle, sans `mdast` (comme `toClientStory`). - `Roadmap` est un type propre au format, défini une fois dans `@recit/roadmap`, dérivé de son schéma (comme `FilmSchema` de `@recit/motion`). Les types partagés (dates, source, config, diagnostics) restent ceux du cœur. ### 4.2 Les trois vues | Vue | Ce qu'elle montre | Données nécessaires | | ------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------- | | `now-next-later` (défaut) | trois colonnes. Un élément va dans la colonne de son `horizon`, sinon dans celle de son statut selon `horizons`. Les éléments `done` sont repliés dans « Livré » sous la vue | statuts ; **aucune date** | | `timeline` | une frise : une ligne par piste, une barre par élément daté (`start`–`end`, ou le trimestre), les jalons en losanges sur l'axe, la ligne « aujourd'hui », les dépendances | dates ; les éléments sans date vont dans une ligne « Non planifié » | | `kanban` | une colonne par statut, dans l'ordre de `statuses` ; lecture seule (pas de glisser-déposer : la source est le fichier) | statuts | La vue par défaut ne dépend d'aucune date (risque « une roadmap publique qui promet des dates », 08 §9). La vue se choisit dans le frontmatter et, à la lecture, par `?view=` dans l'URL (comme `?slide=N` du deck). Les filtres aussi : `?status=in-progress&tag=mobile&owner=team-lorem&lane=api`. Chaque élément a une ancre (`#sync`), et la carte d'un élément ouvre sa description dans un `` natif. Composants (08 §4, un renommage) : `Roadmap` (racine, choix de la vue), `NowNextLater`, `Timeline`, `Kanban`, `RoadmapItem`, `RoadmapStatus` (au lieu de `StatusBadge`, déjà pris par `@recit/site-kit` pour le statut d'un format), `Milestone`, `ProgressBar` (part des éléments `done` par piste), `RoadmapFilters`, `DependencyLine`, `Changelog` (éléments `done` par date). Ils vivent dans `packages/formats/roadmap/src/components/`, chacun avec son module CSS et sa story. La frise est un SVG **calculé au build** : `d3-scale` (`scaleUtc`) place les dates, aucune mise en page n'attend le navigateur. Elle s'affiche sans JavaScript, s'imprime telle quelle, et ne bouge pas d'une capture à l'autre. Le JavaScript du client ne sert qu'aux filtres, au choix de vue et au dialogue. ### 4.3 Style et accessibilité - **Loi du plan 19** : React et un module CSS par composant, compilé par Lightning CSS (`scripts/build-css-modules.js`, table typée `X.module.css.ts`), une seule feuille publiée `@recit/roadmap/styles.css`. Pas de Mantine dans un package publié (Mantine n'est que dans le framework de sites et `@recit/site-kit`), donc des éléments natifs : ``, `
` de cases à cocher pour les filtres, `