Vue d'ensemble du CMS

Vue d'ensemble

Le CMS de Yayaw est la couche d'exploitation de contenu dans le dashboard. Il combine données structurées, sections réutilisables, pages, ressources média, design tokens publics, modèles d'e-mails transactionnels et recettes de composants sous un même modèle d'autorisation.

Le point d'entrée principal est :

• /dashboard/content

Ce dashboard résume l'inventaire des pages, l'inventaire des sections, le stockage média, les données CMS publiées, les jobs IA, la santé de publication et les raccourcis vers chaque surface de contenu disponible pour l'utilisateur courant.

Carte des surfaces

Pile de contenu

Le CMS est volontairement organisé en couches :

1. Les modèles de données définissent les champs typés, les règles de localisation et la cardinalité.
2. Les entrées de données publient des valeurs partagées, comme les menus d'en-tête, les menus de pied de page et les variables de site.
3. Les ressources média fournissent des URL publiques durables pour les fichiers sélectionnés ou générés.
4. Les composants définissent l'inventaire UI réutilisable et les moteurs de rendu de recettes.
5. Les sections lient des littéraux, des données CMS ou des médias dans des unités de page réutilisables.
6. Les pages composent des noeuds de mise en page, des références de composants et des références de sections publiées dans des routes publiques ou réservées aux membres d'organisation.
7. Les design tokens modifient la présentation publique au runtime sans changer les documents de page.
8. Les modèles d'e-mails transactionnels réutilisent les variables CMS quand cela convient, mais sont envoyés par le runtime e-mail, pas par le moteur de rendu des pages publiques.

Cette séparation garde le contenu réutilisable au même endroit. Les pages doivent référencer des sections et des entrées de données publiées au lieu de copier le JSON de menu, les promesses partagées, les images ou le contenu répété dans chaque document.

Flux d'édition

Une modification CMS typique suit ce parcours :

1. Créer ou mettre à jour la source structurée dans les modèles de données, les entrées de données ou la médiathèque.
2. Construire une section réutilisable quand le contenu doit apparaître sur plus d'une page.
3. Composer la page dans l'éditeur Puck avec des noeuds de mise en page intégrés, des références de sections et des références directes de composants seulement si nécessaire.
4. Publier la page ou la section une fois les diagnostics de validation propres.
5. Vérifier la route publique ou réservée aux membres d'organisation.

Les flux assistés par IA suivent le même modèle de persistance. Page AI promeut le contenu généré en sections réutilisables, la génération d'images Page AI persiste les médias via la médiathèque, et l'absence de publication d'une section produit un échec explicite au lieu d'un fallback inline.

Résolution au runtime

Le contenu publié se résout depuis des révisions immuables et des lignes de publication :

• les pages chargent ui_page_publications et rendent le PuckPageDocumentV1 publié
• les références de sections se résolvent via ui_section_publications
• les bindings de données résolvent les entrées de données CMS globales ou d'organisation publiées
• les bindings média utilisent l'URL publique stockée dans media_assets
• les design tokens publics se résolvent depuis les charges utiles de tokens sémantiques enregistrées
• les e-mails transactionnels chargent le modèle actif en base pour la locale demandée avant de retomber sur les valeurs par défaut des composants

Les pages publiques globales alimentent /sitemap.xml et les métadonnées SEO publiques. Les pages membres d'organisation exigent une adhésion et émettent des métadonnées noindex même quand des champs SEO existent au niveau de la page.

Localisation

Les documents CMS utilisent les locales applicatives configurées dans src/config/i18n.config.ts. Les locales actuelles sont l'anglais et le français.

Le contenu localisé apparaît dans :

• le texte des pages et les champs SEO
• les valeurs d'entrées de données globales et d'organisation
• les entrées de menus d'en-tête et de pied de page
• les valeurs de recettes de sections générées
• les objets, textes d'aperçu, HTML de corps et exports texte des e-mails transactionnels

Les bindings de sections de page générées sont stockés comme texte d'objet JSON dans le document Puck (propsBindingsJson, apiBindingsJson, harnessBindingsJson et champs de binding associés). La validation bloque le JSON de binding mal formé et les sections générées sans binding variant valide afin que les sauvegardes MCP ou dashboard ne puissent pas publier silencieusement des sections de fallback au runtime.

Les docs anglaises sont canoniques. Du contenu français peut exister dans le produit, mais la nouvelle documentation technique doit d'abord mettre à jour l'anglais.

Autorisation

Le CMS utilise le modèle d'autorisation par groupes et rôles de Yayaw. La navigation du dashboard n'est qu'un indice ; les loaders serveur, actions, services et opérations MCP doivent encore autoriser chaque lecture ou mutation.

Ressources CMS courantes :

• page
• sections
• global-data
• media
• components
• global-variables
• email-template

Les membres d'organisation reçoivent normalement l'accès list/read au contenu scopé par organisation. Les managers, admins, owners et superadmins reçoivent l'accès de gestion selon leurs bindings de rôles de groupe.

Plan de contrôle (control plane)

Les workflows CMS opérationnels doivent partager la logique de service entre le dashboard, MCP, les scripts CLI et les tests quand ils sont exposés hors de l'interface.

La couverture actuelle du plan de contrôle (control plane) inclut :

• opérations de pages
• opérations de données CMS
• opérations de modèles d'e-mails transactionnels
• opérations de catalogue de facturation utilisées par les variables CMS

Quand vous ajoutez une fonctionnalité CMS, décidez si les clients MCP de confiance doivent pouvoir l'opérer. Si oui, ajoutez des schémas typés, un reason pour les écritures, des enregistrements d'audit, des contrôles d'autorisation et des mises à jour de documentation. Si non, documentez pourquoi la fonctionnalité est volontairement limitée au dashboard.

Règles opérationnelles

• Stocker le contenu réutilisable comme données, médias, sections ou modèles publiés.
• Garder les documents de page comme documents de composition, pas comme stores de contenu dupliqué.
• Ne pas exécuter de code de composant stocké en base.
• Ne pas stocker les binaires média dans Postgres.
• Garder les design tokens publics scopés hors des routes dashboard et auth.
• Scoper explicitement les données CMS globales et les données CMS d'organisation.
• Revalider les chemins dashboard et runtime publics affectés après publication/archivage.
• Traiter les fichiers assistants générés comme des artefacts dérivés ; mettre d'abord à jour content/llm/llm-source.md, puis les régénérer.

Validation

Vérifications utiles après des changements de documentation ou de comportement CMS :

bun run docs:generate
bun run docs:check-links
bun run docs:check-translations
bun run docs:llm:generate
bun run docs:llm:check
bun run check
bunx tsc --noEmit

Exécuter les tests de domaine au besoin quand des changements d'implémentation touchent les pages, sections, modèles de données, médias, composants, tokens ou modèles d'e-mails.

Docs liées

• Tableau de bord
• Autorisation
• Catalogue des pages
• Catalogue des sections
• Modèles de données CMS
• Médiathèque
• Catalogue des composants
• Design tokens
• Modèles d'e-mails transactionnels
• Plan de contrôle