Générateur de site

Le Générateur de site est l’assistant d’intégration du thème. La moitié « formulaire » fonctionne partout où le thème s’affiche, y compris sur GitHub Pages. La moitié « IA » se connecte via le proxy de développement local avec votre propre jeton de fournisseur — Claude (Anthropic) ou Grok (xAI) — et transforme l’assistant en une construction assistée : l’assistant voit chaque réponse, propose et applique des valeurs, vérifie la machine, lit le code source du thème, écrit le projet, exécute Docker et, dans une session ouverte, modifie un site existant fichier par fichier et génère des images pour celui-ci.

Ce que vous allez faire

Utilisez cette référence pour comprendre la structure de l’assistant, connecter un fournisseur, choisir entre les étapes guidées et une session ouverte, configurer ou étendre une étape, et voir exactement quelles actions la session IA est autorisée à effectuer.

Prérequis

• Le thème servi en local (docker compose up) pour que /setup/ s’affiche. En production, la page affiche un avis sauf si show_setup_wizard: true est défini.
• Pour la couche IA : Node.js 20.6+ et le proxy de développement en cours d’exécution. Un jeton peut être collé à l’étape Connexion ou conservé dans .env : un jeton OAuth Claude Code (claude setup-token, Pro/Max), une clé API Anthropic, ou une clé xAI depuis console.x.ai. Une clé xAI débloque également la génération d’images (Grok Imagine) ; une clé OpenAI constitue un moteur de rendu d’images alternatif.

Où il s’affiche

Les neuf étapes

Les étapes, les prérequis, les catalogues, les fournisseurs, les modes de session et le résumé du framework proviennent tous d’un seul fichier de données, _data/site_builder.yml, de sorte que le formulaire, les générateurs et l’invite IA ne peuvent pas diverger.

Choisissez votre fournisseur d’IA

L’étape Connexion affiche une carte par fournisseur depuis _data/site_builder.yml et demande au proxy de développement lesquels disposent déjà d’une clé. Le badge sur chaque carte indique la fin masquée de cette clé et son origine (.env ou un jeton collé lors de cette session).

Changer de fournisseur définit également le ai_chat.provider du site généré à l’étape Intégrations, et le choix d’image préconfigure preview_images, de sorte que le site que vous construisez est prêt pour le fournisseur que vous avez utilisé ; .env.example liste les clés correspondantes.

Le proxy fait autorité : il décide quels fournisseurs sont configurés, fixe le fournisseur et le modèle lorsqu’on le lui demande, et effectue la traduction pour xAI afin que le navigateur parle toujours le dialecte Anthropic Messages. Le widget de discussion présent sur chaque page bénéficie du même choix (ai_chat.provider) — voir Assistant de discussion IA.

Étapes guidées ou session ouverte

Le mode Guidé conserve le flux d’origine : l’assistant suit les neuf étapes, propose des invites par étape et remplit chaque formulaire avec une carte de confirmation.

La session ouverte fonctionne comme une session de codage dans un terminal. Les étapes restent disponibles mais optionnelles : décrivez ce que vous voulez, et l’assistant enchaîne les outils — jusqu’à 24 tours par échange — pour construire un nouveau site à partir d’un brief, ouvrir un site existant sous la racine cible, lire et modifier ses fichiers, ajouter des pages, générer des images, exécuter jekyll build et rendre compte des changements. Un bouton Stop interrompt une exécution longue ; tout outil que l’exécution n’a pas terminé reçoit une réponse pour le modèle afin que la conversation reste bien formée. Le mode ainsi que les choix de fournisseur, de modèle et d’image sont mémorisés dans localStorage ; jamais un jeton.

Modifier un site existant

L’étape Build répertorie chaque site sous la racine cible (dossiers contenant un _config.yml ou un docker-compose.yml) — les sites que ce constructeur a écrits auparavant, ou tout site Jekyll que vous y copiez. Open (ou l’outil open_project) en fait le projet de travail : l’assistant reçoit son arborescence de fichiers dans l’invite système et les outils de projet agissent à l’intérieur.

Chaque écriture est délimitée par le même bac à sable que le scaffold : chemins relatifs uniquement, extensions autorisées, plafonds de taille, secrets et chemins VCS refusés, jamais à l’intérieur de la copie de travail du thème.

Une particularité de Jekyll que les outils prennent en compte : --watch ne suit que les documents de collection qui existaient au démarrage du serveur, si bien qu’un article ou une page nouvellement ajouté n’apparaît pas sur le site en cours d’exécution. write_project_file le signale dans son résultat et propose un bouton de redémarrage, et run_compose("restart") le rend visible.

Génération d’images

generate_image génère avec le fournisseur d’images sélectionné — Grok Imagine (grok-imagine-image-2.0) ou OpenAI Images (gpt-image-2) — et enregistre le PNG/JPEG/WebP sous le dossier assets/ du projet (les octets sont détectés, plafond de 8 Mo). La carte de confirmation affiche l’invite, le chemin cible et le modèle car cela coûte de l’argent ; la carte de résultat affiche une vignette servie par le proxy. L’outil renvoie le chemin pour que l’assistant puisse l’intégrer : front matter preview:, landing.hero.image dans le plan du site, ou un <img>. L’étape Apparence propose un raccourci Image d’en-tête avec ….

Fichiers générés

Le panneau d’aperçu affiche chaque fichier en direct et se régénère à chaque frappe. Tout fichier peut être remplacé à la main ou par Claude ; les fichiers remplacés portent un point sur leur onglet.

Download file enregistre le fichier actif. Download bundle enregistre zer0-site-bundle.sh, un script bash auto-extractible qui recrée toute l’arborescence dans un dossier que vous nommez.

Le plan de site (sortie pilotée par schéma)

Au-delà des champs du formulaire, l’agent produit un plan de site : une description structurée de la page d’accueil, de la forme de navigation, des surcharges de thème et des pages d’exemple. Le plan est validé par rapport à plan_schema dans _data/site_builder.yml (un sous-ensemble de JSON-Schema : type, properties, required, additionalProperties, enum, enumFrom un catalogue, items, maxItems, maxLength, pattern) avant tout changement, et les générateurs le transforment en fichiers. Chaque option que l’agent peut choisir provient d’un catalogue dans le même fichier de données, si bien qu’ajouter une palette, un appariement de polices, un modèle de page d’accueil ou un type de section est un changement de données.

Les valeurs par défaut du modèle comblent ce que le plan laisse de côté, si bien qu’un plan comportant uniquement landing.template: showcase produit tout de même une page d’accueil complète dont le texte est dérivé du brief et des collections. L’étape Structure expose les mêmes choix sous forme de contrôles (style de navigation, barre latérale, modèle de landing, un planificateur de pages) et l’étape Apparence expose des cartes de palette, un appariement de polices avec aperçu en direct, et le rayon des angles ; Preview on this page applique les surcharges générées à l’assistant lui-même. Claude soumet des plans avec set_site_plan ; le navigateur affiche une carte de confirmation listant ce qui change et rejette tout ce que le schéma n’autorise pas, en renvoyant les erreurs au modèle.

Configuration

site_builder:
  enabled: true
  endpoint: '/api/wizard'      # dev proxy base; _config_dev.yml sets http://localhost:8787/api/wizard
  chat_endpoint: ''            # '' reuses ai_chat.endpoint
  provider: 'auto'             # auto | anthropic | xai — card preselected on Connect (the proxy decides what is configured)
  model: 'claude-opus-4-8'     # fallback when the proxy reports none; CHAT_MODEL / XAI_CHAT_MODEL win
  mode: 'guided'               # guided | open
  image_provider: ''           # '' | xai | openai — image renderer offered when its key exists
  max_tokens: 8192             # open sessions write whole files; the proxy's MAX_TOKENS_CAP still caps it
  default_port: 4000

Variables côté proxy : CHAT_PROVIDER, CHAT_MODEL, XAI_CHAT_MODEL, XAI_API_KEY, OPENAI_API_KEY, IMAGE_PROVIDER, XAI_IMAGE_MODEL, OPENAI_IMAGE_MODEL, MAX_TOKENS_CAP, CHAT_DEV_ENV_FILE.

La session IA

Chaque tour envoie une invite système construite à partir de cinq éléments : le brief de framework issu du fichier de données, le schéma de champs exposé par l’assistant, les indications de l’étape en cours (ou le brief de session ouverte), un résumé de chaque réponse, résultat de vérification et fichier généré, et l’arborescence du projet en cours lorsqu’un projet est ouvert. Comme le formulaire est l’unique source de vérité et que le script ne dialogue avec lui qu’à travers window.Zer0SetupWizard, tout ce que vous saisissez et tout ce que l’assistant applique est immédiatement visible des deux côtés.

Outils disponibles pour le modèle :

La transcription visible est conservée dans sessionStorage uniquement sous forme de tours en texte brut, de sorte qu’une conversation restaurée ne puisse jamais laisser un résultat d’outil orphelin.

Routes du proxy de développement

Les routes n’existent que dans templates/deploy/chat-proxy/dev-proxy.mjs et sont délimitées par wizard-store.mjs. Le Worker Cloudflare ne les possède jamais.

Environnement : WIZARD_TARGET_ROOT, WIZARD_DISABLE_COMPOSE=1, CHAT_DEV_ENV_FILE.

Valider un build de bout en bout

Comme les réponses de l’agent ne sont pas déterministes, l’assistant fournit un lanceur de scénarios plutôt qu’une transcription fixe. Il échantillonne un brief réaliste, un auteur, un ton, un skin, un mode de couleur et des intégrations pour un type de site, pilote tout l’assistant dans un vrai navigateur avec l’enregistrement vidéo activé, accepte les cartes de confirmation de Claude, écrit le projet, le démarre avec Docker, et vérifie des faits structurels sur le résultat : les fichiers attendus existent, le site répond sur chaque route de ce type, et il porte le titre et le skin choisis.

# theme on :4000, dev proxy on :8787
node test/visual/site-builder-walkthrough.mjs                       # one random scenario
SCENARIO=cookbook SEED=42 node test/visual/site-builder-walkthrough.mjs
SCENARIO=all COUNT=6 SITE_PORT=4100 node test/visual/site-builder-walkthrough.mjs

Les scénarios résident dans test/visual/site-builder-scenarios.mjs (blog, docs, cookbook, portfolio, garden, mixed). Chaque exécution imprime sa graine et écrit report.md, report.json, des captures d’écran et video-desktop.webm sous test/visual-results/site-builder-walkthrough/<timestamp>/. Lorsque l’assistant est indisponible, le lanceur enregistre ces vérifications comme échouées, remplit des substituts déterministes, et exécute quand même le build. Les sites générés utilisent SITE_PORT + 10·i avec LiveReload sur le port suivant, de sorte qu’ils s’exécutent à côté du serveur de développement du thème.

Vérifier

1. Démarrez le thème et le proxy, ouvrez /setup/, choisissez un fournisseur, collez un jeton (ou fiez-vous à .env) et confirmez que le badge indique Claude connecté ou Grok connecté.
2. Appuyez sur Run checks à l’étape des prérequis et confirmez que chaque ligne change d’état.
3. Saisissez un brief, appuyez sur Draft with Claude, et confirmez qu’une carte demande avant que les champs changent.
4. Sur Build, appuyez sur Check, Write project, puis docker compose up ; le terminal diffuse le build et Open site charge le nouveau site.

Dépannage

Ressources associées

• Démarrage rapide du Site Builder est le guide pas à pas destiné aux nouveaux utilisateurs.
• Assistant de chat IA documente le proxy partagé et ses modes d’authentification.
• Configuration de la machine est la référence manuelle pour l’étape Prérequis.