Modèles et exemples

La façon la plus rapide d'apprendre Sovrium est de partir d'une application fonctionnelle. Sovrium fournit un ensemble de configurations d'exemple — chacune étant un projet complet et exécutable qui compose de vraies fonctionnalités (tables, authentification, pages, thème, i18n, automatisations) en une seule arborescence de configuration. Ces mêmes exemples servent aussi de modèles sovrium init, vous pouvez donc échafauder n'importe lequel dans un nouveau répertoire et commencer à itérer immédiatement.

Chaque exemple est un répertoire avec un point d'entrée app.yaml. Tout ce qui dépasse le plus petit démarrage scinde sa configuration sur une sous-arborescence config/ à l'aide de $ref — un fichier par entité de collection, un fichier par singleton, les scalaires restant en ligne. Cela reflète la structure que sovrium init échafaude pour vous.

Modèles disponibles

Dix-huit modèles sont livrés avec le binaire. Les six premiers enseignent une capacité à la fois ; les autres sont des applications métier complètes, exécutables telles quelles.

Démarreurs — apprendre une capacité à la fois

Applications métier — des systèmes complets et exécutables

Chaque modèle embarque son propre bundle Claude Code — un CLAUDE.md rédigé pour le domaine du modèle, ainsi qu'un sous-agent app-editor de départ dans .claude/agents/app-editor.md. L'échafaudage est une simple copie d'arborescence : le bundle arrive donc avec la configuration, sans seconde étape d'installation. Voir la Référence CLI pour toutes les options d'init.

Échafauder un projet

sovrium init copie un modèle dans un nouveau répertoire (ou le répertoire courant). Sans --template, le démarrage minimal hello-world est utilisé.

# Défaut (hello-world, aucun agent associé)
sovrium init my-app

# Choisir un modèle — installe aussi l'agent éditeur associé
sovrium init my-app --template crm
sovrium init my-app --template landing-page
sovrium init my-app --template helpdesk
sovrium init my-app --template company-os

# Ignorer l'installation de l'agent associé
sovrium init my-app --template crm --no-agent

Exécutez ensuite l'application échafaudée :

sovrium start app.yaml          # Démarrer le serveur de développement
sovrium validate app.yaml       # Valider sans démarrer

Voir la Référence CLI pour toutes les options de init.

Anatomie d'un exemple

Un exemple non trivial ressemble à ceci (disposition abrégée de crm) :

crm/
├── app.yaml                 # Point d'entrée — référence tout via $ref
├── config/
│   ├── auth.yaml            # Singleton : stratégies d'auth, rôles
│   ├── theme.yaml           # Singleton : jetons de design
│   └── tables/
│       ├── companies.yaml   # Un fichier par table
│       └── contacts.yaml
└── public/                  # Ressources statiques (favicon, images)

Le point d'entrée app.yaml rassemble chaque partie avec $ref, gardant le fichier de premier niveau petit et chaque entité dans son propre fichier :

name: crm

auth:
  $ref: ./config/auth.yaml

theme:
  $ref: ./config/theme.yaml

tables:
  - $ref: ./config/tables/companies.yaml
  - $ref: ./config/tables/contacts.yaml

pages:
  - $ref: ./config/pages/dashboard.yaml
  - $ref: ./config/pages/sign-in.yaml

La résolution de $ref a lieu avant la validation : tout objet contenant exactement une clé — $ref dont la valeur est un chemin relatif — est remplacé par le contenu analysé de ce fichier. Un $ref peut lui-même contenir d'autres $ref, donc les configurations s'imbriquent à n'importe quelle profondeur. Les formes mono-fichier et multi-fichiers sont interchangeables ; choisissez celle qui garde le projet lisible.

Parcours d'apprentissage

Un ordre pratique pour parcourir les exemples :

1. hello-world — comprendre la forme minimale d'une configuration et le tableau pages.
2. landing-page — ajouter un thème, des composants réutilisables et l'i18n avec les clés de traduction $t:.
3. blog / docs-site — routes dynamiques et collections de contenu markdown.
4. crm — introduire les tables, l'authentification et les pages liées aux données (formulaires + tableaux de données).
5. api-only / mcp-server — exécuter Sovrium sans interface : comme backend REST ou serveur MCP face à un LLM.
6. helpdesk / expenses — automatisations, formulaires publics de saisie et permissions au niveau de la ligne.
7. company-os — plusieurs domaines dans une seule configuration, reliés par des automatisations inter-domaines.

Pages associées

• Démarrage rapide — de zéro à une application qui tourne, en YAML ou en TypeScript avec defineConfig.
• Fichiers de configuration — composition multi-fichiers YAML, JSON, TypeScript et $ref.
• Référence CLI — sovrium init et l'ensemble des commandes.
• Intégration MCP — le modèle de serveur MCP sans interface expliqué.