fuzzyplace/living-stage

Living stage : configuration guidée

Vous aidez quelqu'un à créer sa propre version de ce site : un personnage à l'encre qui a sa propre vie, dont les bras impriment la page au fur et à mesure du défilement, qui raconte son histoire avec ses mots. Le moteur fonctionne déjà. Votre travail consiste à le copier, interviewer la personne, et remplir cinq emplacements. N'écrivez pas de code moteur.

Les cinq emplacements qui lui appartiennent

Quoi	Fichier
Mots : nom, accroche, chapitres, appel à l'action, œufs de Pâques	src/content/site.ts
Liens dans l'arborescence de liens	src/content/links.ts
L'apparence du personnage	src/content/character.tsx (préréglages dans src/art/looks.tsx)
Palette, typographie, mouvement	design/tokens.json, reflété dans src/styles/tokens.css
Image de partage et icône	npm run og (généré à partir de ce qui précède)

Vous écrivez également les décisions de l'entretien dans docs/STORY.md, et vous pouvez lire src/art/looks.tsx pour copier un préréglage dans src/content/character.tsx.

Tout le reste (src/art/, src/audio/, src/components/, src/sections/, src/App.tsx) est le moteur. Ne le lisez pas pour effectuer cette tâche ; il est volumineux et vous n'en aurez pas besoin. Lisez docs/CHARACTER.md pour les règles d'apparence et d'accroche, et docs/DESIGN_SYSTEM.md avant de toucher aux tokens. Ouvrez les fichiers du moteur uniquement si une vérification échoue et que l'erreur y pointe.

Étape 0 : obtenir le code (rapide, sans génération)

Si le dossier actuel est déjà une copie du modèle (il contient src/content/site.ts et .claude/skills/living-stage/), passez à l'étape 1.

Sinon, demandez où le nouveau site doit se trouver (un nom de dossier), puis copiez le modèle sans son historique et installez-le :

npx degit fuzzyplace/lil_guy_portfolio mon-site
cd mon-site
git init
npm install

Ensuite, lancez le serveur de développement (npm run dev, ou l'outil de prévisualisation si vous en avez un) et montrez-leur le site exemple pour qu'ils sachent ce qu'ils vont créer. Si vous ne pouvez pas lancer ou consulter un serveur de développement, utilisez plutôt des captures d'écran : npm run build && npm run verify écrit screenshots/verify-desktop-hero.png (le héros, en pleine acrobatie) et compagnie, et npm run looks écrit des gros plans de chaque apparence. (Première fois : npx playwright install chromium.) Dites-leur en deux lignes ce qui va se passer ensuite : un entretien court, une question à la fois, puis vous construirez, vérifierez et (avec leur accord) déploierez.

Étape 1 : l'entretien

Comment décider (c'est ce qui compte le plus)

Décidez de haut en bas, une couche à la fois, et ne demandez jamais une couche inférieure avant que la couche supérieure soit verrouillée. Des visuels terminés avant que l'histoire et la voix ne soient fixées conduisent à un contenu qui n'a pas de sens.

1. Intention : à qui le site est destiné, ce qu'ils doivent ressentir, et ce qu'ils doivent faire à la fin.
2. Histoire : l'arc narratif, défilement de haut en bas.
3. Style d'écriture : la voix, la forme des phrases, les dispositifs de cadrage.
4. Structure : les blocs (chapitres, une fenêtre contextuelle, contact) et l'objectif de chacun.
5. Dialogues : les mots réels, accroche d'abord.
6. Personnage : à quoi il ressemble.
7. Palette, typographie et mouvement.
8. Liens : l'arborescence de liens et l'appel à l'action.

Écrivez chaque couche verrouillée dans docs/STORY.md sous "VERROUILLÉ" (remplacez les entrées du persona exemple au fur et à mesure). Tout ce qui suit doit en découler. Si une idée ultérieure contredit une couche verrouillée, dites-le et demandez avant de modifier quoi que ce soit.

Comment demander

• Une question à la fois, en texte de chat simple. Pas de formulaires ou de boîtes de dialogue à questions multiples.
• Avant chaque question, dites en une ligne ce qu'elle décide et ce qu'elle change sur la page.
• Montrez, ne décrivez pas. Pour les questions de style et d'apparence, donnez 3 ou 4 options, chacune écrite sur leur vrai contenu : les trois mêmes moments à chaque fois (l'ouverture, un chapitre, la fin). Pour le personnage, montrez les préréglages (?look=beanie|bun|hood|bot sur le serveur de développement, ou npm run looks pour les gros plans). Pour les palettes, montrez des échantillons avec la couleur du texte sur l'arrière-plan.
• Recommandez une option et dites pourquoi en une phrase. Ils choisissent, mixent ou refusent.
• Après chaque réponse, reformulez en une ligne ce qui est maintenant verrouillé, écrivez-le dans docs/STORY.md, puis posez la question suivante.
• "À vous de décider" signifie que vous décidez, consignez-le sous "Décisions" dans docs/STORY.md, et passez à la suite.
• Gardez une idée du coût : ne relisez pas les fichiers déjà lus, ne régénérez pas tout le site pour chaque réponse, modifiez uniquement les lignes qui ont changé.

Que demander, couche par couche

1. Intention. À qui est-ce destiné (responsables de recrutement, clients, collaborateurs, amis) ? Que doivent-ils ressentir ? Quelle est la seule chose qu'ils doivent faire à la fin (email, réserver un appel, suivre, rien) ?
2. Histoire. Demandez d'abord la matière première (ce qu'ils ont fait, font maintenant, veulent faire ensuite, tout ce qu'ils créent à côté), puis proposez 2 ou 3 arcs en une ligne chacun. L'arc par défaut est passé, présent, une fenêtre contextuelle avec le fil conducteur, futur, contact ; n'importe quel ordre de chapitres et de fenêtres contextuelles fonctionne.
3. Style d'écriture. Proposez 3 ou 4 voix rendues sur leur propre matériel, par exemple : première personne discrète ; cahier de laboratoire ; notes de terrain ; journal de bord ; ou un mélange. Recommandez-en une.
4. Structure. La liste des blocs, chacun avec sa fonction en une ligne, plus ceux qui apparaissent dans la navigation d'en-tête. Un bloc doit être le bloc de contact.
5. Dialogues. Rédigez chaque ligne dans la voix verrouillée, puis montrez-les ensemble dans leur contexte (le serveur de développement, après avoir écrit site.ts). Obtenez d'abord l'accroche correcte : lisez "Accroches" dans docs/CHARACTER.md (2 à 4 lignes courtes, un mot réel sur la première ligne, lettres hautes à côté de lettres courtes, une virgule à la fin d'une ligne ; au maximum 24 caractères par ligne). Aussi : le sourcil, l'accroche principale, l'œuf de Pâques du pied de page, l'œuf de Pâques de la console, les deux lignes de confiance, la ligne 404. Le brouillon du contenu est acceptable ; rien n'est publié avant qu'ils ne l'approuvent.
6. Personnage. Montrez les quatre préréglages. Si aucun ne convient, demandez une description en une phrase (cheveux ou chapeau, vêtements, la chose qui accroche la lumière) et dessinez un look personnalisé en copiant le préréglage le plus proche dans src/content/character.tsx et en modifiant une forme à la fois. Suivez les règles de boîte, d'articulations et de remplissage dans docs/CHARACTER.md. Ne tracez jamais une photo ou l'apparence d'une personne réelle à moins que ce ne soit la leur et qu'ils le demandent. Les préréglages partagent parts.NECK et parts.SKULL (exportés depuis src/art/looks.tsx). Montrez le résultat avec npm run looks (screenshots/look-current.png).
7. Palette, typographie et mouvement. Proposez 3 palettes sous forme d'échantillons (les gris d'encre par défaut, et deux qui correspondent à leur histoire), la couleur d'accentuation, et s'il faut conserver les polices par défaut. Modifiez d'abord design/tokens.json, reflétez chaque couleur modifiée dans src/styles/tokens.css (seulement la rampe de gris a des variables --md-ref-gray-* là-bas ; toutes les autres couleurs sont directement sur leur --md-sys-color-<role>), puis exécutez npm run tokens:contrast : cela vérifie le contraste du texte (4,5:1) et que les deux fichiers sont en accord. Le brouillard (fog-light, fog-mid, fog-deep, fog-edge) porte l'ambiance de la palette : teintez les quatre. Gardez l'accentuation discrète (docs/DESIGN_SYSTEM.md). Mouvement : durées par défaut ou plus calmes (plus longues).
8. Liens. Demandez chaque lien et où il va (Connecter, Travail, Loisirs, ou groupes renommés). Que des URL réelles : tout ce qu'ils n'ont pas encore est href: null, status: 'soon' (affiché en développement, caché en production). Ensuite, l'appel à l'action : un lien de réservation, un email ou un lien de profil.

Étape 2 : construction et vérification

1. Écrivez les fichiers de contenu à partir de ce qui est verrouillé. Définissez site.url à l'endroit où le site vivra (https://hote, sans barre oblique finale). Pas encore de domaine : utilisez l'adresse de l'hôte (par exemple https://leur-site.vercel.app) et mettez-la à jour plus tard.
2. Exécutez npm run check (types, tests incluant les règles de copie, contraste et dérive des tokens, build). Corrigez ce qui échoue. Le build émet un avertissement tant que site.url pointe encore vers la démo du modèle (lil-guy-portfolio.vercel.app) ou l'appel à l'action vers example.com. Les règles de copie : pas de tirets cadratins ou demi-cadratins, pas de points d'exclamation, pas de mots de remplissage génériques.
3. Exécutez npm run og pour la carte de partage et l'icône.
4. Exécutez npm run build && npm run verify (première fois : npx playwright install chromium). Cela vérifie à 1440 et 375, avec et sans mouvement réduit, que le personnage apparaît au chargement, effectue l'entrée et l'acrobatie du titre, reste à l'écran pendant le défilement, et qu'aucune erreur ne se produit. Si aucune acrobatie ne se produit, l'accroche ne lui donne rien sur quoi se tenir : revoyez-la avec eux.
5. Montrez-leur les captures d'écran (screenshots/verify-desktop-hero.png et verify-mobile-hero.png pour le héros en pleine acrobatie, verify-desktop.png et verify-mobile.png pour la fin de la page) et le serveur de développement, et demandez ce qu'il faut modifier. Bouclez jusqu'à ce qu'ils soient satisfaits. node scripts/shots-sections.mjs donne une capture par chapitre.
6. Passe vie privée. Relisez chaque chaîne dans src/content/ une fois de plus. Signalez tout ce qu'ils pourraient ne pas vouloir rendre public : une adresse personnelle, un numéro de téléphone ou un email personnel qu'ils n'ont pas choisi de partager, des détails familiaux ou de santé, des employeurs ou clients qu'ils n'ont pas approuvés. Supprimez les restes du persona exemple : "Pim Lanternby", "PIM", "The Quiet Hour", les lignes de lampe et de radio, et tout lien example.com, example.org ou example.net qu'ils ne vous ont pas donnés eux-mêmes, ainsi que l'adresse de démo lil-guy-portfolio.vercel.app.

Étape 3 : déploiement

Le déploiement publie leur site, alors demandez avant de le faire. Suivez docs/DEPLOY.md (Vercel par défaut ; Netlify et GitHub Pages fonctionnent aussi). Une fois en ligne, ouvrez l'URL, vérifiez la carte de partage avec le og.png déployé, et donnez-leur le lien.

Terminez par un court résumé : ce qui est en ligne, ce qui est encore soon, et tout ce qu'ils ont dit qu'ils enverraient plus tard.