Nouveaux blocs et outils

16 — Atelier de personnages : recherche sur le « projet basic »

Statut : proposé · Phase : P16 · Mis à jour : 25/10/2026.

Ce document répond à la dernière question restée ouverte des plans 11 et 14 : ce qu'est le « projet basic » d'images en full JS. L'utilisateur l'a précisé le 25/10/2026 : « une réflexion où tu pouvais, grâce à des skills, générer des personnages ou autres avec du JS, des personnages pixélisés ? Avoir une sorte d'environnement de création de perso 2D ? ». Il a demandé une recherche profonde des dépôts GitHub sur ce thème, avec leurs plus et leurs moins.

C'est un rapport de recherche suivi d'une recommandation, au même niveau que les plans 10 à 15, avec les mêmes règles : une seule stack, une seule source, génération d'images toujours hors de Récit (les prompts sont des données), aucune métrique inventée. Les faits ci-dessous (étoiles, licences, dernière activité) ont été relevés le 25/10/2026 par gh api repos/... sur 96 dépôts ; les fichiers LICENSE ont été ouverts quand le rapport et l'API ne s'accordaient pas.

Ce plan ne change ni la propriété du personnage (plan 14, bible et kit de Broc), ni le rendu des poses (plan 11, D9 : bloc sprite). Il ajoute un outil de création en amont : de quoi produire une grille ```pixel, une recette de sprite à graine ou une planche codex-pet-v1 sans modèle d'image.

1. La question et ce qu'on cherche

1.1 La question

« Environnement de création de perso 2D, piloté par des skills, en JS. » Trois sens possibles, tous couverts par la recherche :

1. Pixel art en code : un agent écrit un fichier texte (grille, palette, frames), un outil le rend en image. Reproductible, versionnable, sans modèle.
2. Génération procédurale à graine : une graine et quelques paramètres donnent un sprite, un avatar ou un visage. Le personnage est une recette de quelques nombres.
3. Créateur en couches (paper doll) : on assemble un corps, des cheveux, des vêtements, et l'on obtient une planche animée complète.

S'y ajoutent les outils voisins : éditeurs pixel (retouche à la main), formats de planches (Aseprite, TexturePacker), lecteurs de planches et pipelines d'IA (à garder hors de Récit).

1.2 Critères

1.3 Le contrat codex-pet-v1 (rappel vérifié)

Source : openai/skills, skills/.curated/hatch-pet/references/animation-rows.md (Apache-2.0, faits d'interopérabilité réécrits, rien de copié). Planche 1536×1872, 8 colonnes × 9 lignes, cases de 192×208. Les cases inutilisées sont transparentes.

Aucun projet JS ne produit ce format directement. Tous les candidats demandent un adaptateur.

1.4 Couleurs : une par thématique, un défaut sobre

Demande de l'utilisateur (25/10) : une couleur différente pour chaque thématique, une couleur par défaut la plus sobre possible, et du noir et blanc pour le site de base qui référence le tout. Pour l'atelier, cela veut dire : une palette s'écrit en jetons de thème (text, accent, data.*, déjà prévus au plan 11 D3), jamais en couleurs figées. Un même sprite prend l'accent du thème du site qui l'affiche, et reste en noir et blanc sur le site de base. Un outil qui impose sa palette (Multiavatar, avvvatars) est donc écarté d'office.

2. Les dépôts, par catégorie

Légende : ★ = étoiles GitHub au 25/10/2026 ; « activité » = dernier push. Les licences « non vérifiées » sont annoncées dans un README sans fichier LICENSE : on les traite comme « tous droits réservés ».

2.1 Pixel art en code et skills d'agent

2.2 Générateurs procéduraux de sprites pixel

2.3 Personnages en couches (LPC)

2.4 Avatars et personnages vectoriels (SVG)

2.5 Poupées de papier (modèles de données)

2.6 Éditeurs pixel et format Aseprite

2.7 Planches : empaquetage et lecture

2.8 Animation vectorielle et squelettes

2.9 Pipelines d'IA (toujours hors de Récit)

2.10 Écartés à la vérification

• Licence : matveyco/8biticon et arusanov/avatar-generator (aucune), Mobilpadde/ww-psg (ni licence ni graine), Stipple Effect (EULA, Java), EsotericSoftware/spine-runtimes (licence Spine payante).
• Morts ou peu utiles : yuigoto/infiniship-js, maierfelix/poxi, jackschaedler/goya (ClojureScript, EPL), eonarheim/NES-Sprite-Editor, Chernavskikh/pixel-avatars, pixellab-code/pixellab-mcp (un README qui renvoie vers un service fermé).
• Hors sujet : M3-org/CharacterStudio (3D VRM), liveblocks/pixel-art-together (démo Svelte + SaaS), cubiq/PuLID_ComfyUI et ComfyUI_IPAdapter_plus (identité de visage réaliste ; IPAdapter en GPL-3.0).
• Doublons : dmester/jdenticon et stewartlord/identicon.js (minidenticons et DiceBear suffisent).
• Archaïques ou sans licence : fnaith/Godot-LPC, bluecarrot16/lpctools, buxx/lpcg (AGPL, Rust).

3. Analyse

3.1 Comme dépendance (rare, une seule stack)

Presque rien ne passe tous les critères à la fois. Les candidats sérieux :

Conclusion : aucune dépendance nouvelle en v1. Le code utile tient en quelques centaines de lignes pures (PRNG à graine, masque de Bollinger, miroir, contour, composition d'une grille 8×9), à écrire dans le module pixel de @recit/components (plan 11 D2, option B).

3.2 Comme outil externe (lancé par l'auteur, jamais importé)

Même règle que hatch-pet (plan 11 D10) : l'outil tourne hors de Récit ; ses requêtes et ses sorties sont des données du projet, enregistrées avec leur provenance (recit assets register, plan 14 D7).

3.3 Comme source d'inspiration (idées, rien de copié)

• Algorithme de masque de Bollinger (zfedoran, mixel) : la recette {width, height, mirrorX, mirrorY, data} est le bon modèle de schéma ; on le réimplémente avec une graine, ce que zfedoran ne fait pas.
• ZzSprite et starshipwright : un sprite = quelques graines (forme, mutation, couleur). Les graines de mutation donnent des variantes d'un même personnage.
• pixel-art-gen : motifs texte compacts, natifs en Markdown ; proche de la grille du plan 11 D3.
• pixelship : la recette est ce qu'on sauvegarde, la sortie est CC0 ; même philosophie que Récit.
• pickcells : l'atelier minimal = peindre un masque, puis générer des variations.
• paperdoll / paperbuddy : emplacements, fragments, ancres, sélecteurs conditionnels, si un jour des couches s'ajoutent.
• JSON Aseprite : forme d'échange (frames, durées en ms, frameTags) dont on tire un sous- ensemble zod pour l'import.
• pixeldetector, tachikomared : idées de validateur (vraie grille, palette réduite).
• facesjs, react-nice-avatar : graine → objet de configuration → SVG ; on stocke l'objet.

3.4 Licences à surveiller

4. Recommandation

4.1 Ce que Récit construit : le plus petit atelier utile

Tout dans le module pixel de @recit/components (fonctions pures, sans DOM), décision D2 du plan 11 inchangée. Zéro dépendance ajoutée.

1. Générateur procédural à graine : réimplémentation TS de l'algorithme de masque (miroir, contour, couleurs par jetons de thème) avec un PRNG à graine écrit dans le module (quelques lignes ; à vérifier : @recit/components ne doit pas importer le random() de Remotion). C'est l'option ::pixel{gen=sprite seed=…} déjà réservée par IM3. Sortie : la même grille que le bloc ```pixel, donc le même rendu SVG, les mêmes goldens.
2. Recette typée : PixelRecipe dans @recit/core/schema (zod) : { gen, seed, size, mask, mirror, palette, variants }. Le jumeau JSON décrit la recette ; la grille se recalcule. Une recette « figée » se convertit en grille ```pixel éditable à la main.
3. Poses par transformations : à partir d'une grille de base, des transformations déterministes (décalage, rebond, clignement, miroir pour running-left) remplissent les 9 lignes de codex-pet-v1. Rendu volontairement modeste, comme runcomfy, mais sans modèle.
4. Export codex-pet-v1 : composition des frames dans une grille 8×9 de cases 192×208 (pixels agrandis par un entier, cases inutilisées transparentes), en SVG ; la rasterisation PNG ou WebP passe par le runner Chromium existant (@recit/paged/runner, plan 15), pas par un encodeur ajouté. Le résultat se lit avec le bloc sprite du plan 11 D9 et se valide avec le schéma SpriteSheet du plan 14 D12.
5. Constantes du layout : le tableau du §1.3 en données typées (layout: "codex-pet-v1"), source unique pour le validateur, le bloc sprite et l'export.
6. Atelier web minimal : une page de docs (ou de ai.recit.dev en P16) avec une grille cliquable, un champ graine, un aperçu des 9 poses et deux boutons « copier le bloc Markdown » et « copier le JSON ». Aucun format de fichier propre : ce qu'on copie est la source Récit.
7. Skill : recit://guide/pixel décrit la syntaxe et la recette ; recit skills export en tire le skill produit (plan 14 IA3.3). Un agent écrit une grille ou une recette, pas une image.

Couleurs (§1.4) : la palette par défaut n'utilise que text et bg (noir et blanc, site de base) ; l'accent de chaque thématique vient du thème du site qui affiche le sprite. Un même personnage change donc de couleur selon le site, sans seconde source.

4.2 Ce que Récit intègre en outil externe

• Imports documentés, pas de code au départ : une page « importer depuis claude-pxl, Piskel, Aseprite, LPC » explique comment poser la planche, écrire la provenance et la licence.
• Import JSON Aseprite (plus tard) : un sous-ensemble zod du JSON exporté par Aseprite (frames, durées, frameTags) converti vers codex-pet-v1 quand les tags portent les noms des 9 états. Piskel, LibreSprite, claude-pxl et agent-sprite-forge savent produire ce JSON ou un voisin.
• LPC : outil externe uniquement, via son site ou lpc-spritesheet-mcp ; Récit importe la planche avec le CSV de crédits, et refuse en mode strict une planche LPC sans crédits.

4.3 Ce qu'il ne faut pas faire

• Pas de dépendance GPL, ni de copie de code LPC ou d'un dépôt sans licence.
• Pas d'appel à un modèle d'image depuis Récit (règle du plan 14).
• Pas d'éditeur graphique complet (calques, pinceaux, pelure d'oignon) : Piskel et Pixelorama le font ; le risque « dérive vers un éditeur graphique » du plan 11 reste valable.
• Pas de second système de personnage : la bible du plan 14 reste propriétaire ; un personnage généré est une entrée de bible avec une recette ou une planche.
• Pas de Broc en pixel art (plan 11 D9, inchangé) : l'atelier sert aux personnages Lorem, aux figurants, aux mascottes secondaires et aux exemples.
• Pas de dépendance à claude-pxl tant qu'il n'a ni release ni paquet npm.
• Pas de DiceBear tant qu'aucun format ne demande un portrait ; et alors, styles CC0 seulement.

5. Phases, risques, questions

Tâches AT, lots AT1 à AT4, sous-tâches ATn.m (convention de 06, « Backlog »). Rien en P4 ni en P5. Le « projet basic » n'est donc plus bloqué : il devient ce lot.

AT1 — Générateur à graine (S/M), avec IM3, lot avancé de P11 au plus tôt

Après IM1 (le bloc ```pixel doit exister).

• AT1.1 — PRNG à graine et algorithme de masque dans le module pixel de @recit/components.
• AT1.2 — PixelRecipe dans @recit/core/schema ; directive ::pixel{gen=sprite seed=…}.
• AT1.3 — Palette en jetons de thème ; défaut noir et blanc.
• AT1.4 — examples/motion-pixel : une section « généré » (Lorem), en et fr.
• Tests : même graine → même grille → même SVG ; équivalence Markdown ⇄ JSON ; goldens.

Sortie : une graine donne toujours le même sprite, dans tous les formats, sans dépendance ajoutée.

AT2 — Poses et export codex-pet-v1 (M), P16, avec IM4

• AT2.1 — Constantes typées du layout codex-pet-v1 (source unique avec le plan 14 D12).
• AT2.2 — Transformations de poses et composition 8×9 en SVG.
• AT2.3 — recit pixel sheet <recette|grille> : PNG/WebP par @recit/paged/runner, provenance origin: code écrite automatiquement.
• AT2.4 — Planche synthétique d'examples/stories-character (IM4.2) produite par cet export.
• Tests : taille 1536×1872, cases inutilisées transparentes, chaque pose jouée par sprite.

Sortie : la planche de l'exemple Lorem est générée, pas dessinée, et rejouée par le bloc sprite.

AT3 — Atelier web et skill (M), P16, avec IA3 et IA4

• AT3.1 — Page atelier (grille, graine, aperçu des 9 poses, copie Markdown et JSON).
• AT3.2 — Guide recit://guide/pixel complété ; skill exporté par recit skills export.
• AT3.3 — Page « importer depuis claude-pxl, Piskel, Aseprite, LPC », avec les règles de licence du §3.4.
• Tests : e2e de l'atelier (copie, graine), skill régénéré identique.

AT4 — Options (après P16, sur besoin réel)

• Import JSON Aseprite → codex-pet-v1.
• Portraits DiceBear (styles CC0) pour les entrées de bible, si un format en a besoin.
• Extraction de @recit/pixel si l'atelier devient un second consommateur hors de @recit/components (plan 11 D2).
• Validateur « vraie grille » (idée de pixeldetector) pour les planches importées.

5.1 Risques

5.2 Questions

Décisions prises sans l'utilisateur, à sa demande (« je te laisse choisir »), réversibles :

1. « Projet basic » : de quoi s'agit-il ? Répondu (25/10) : un environnement de création de personnages 2D pixel en JS, piloté par des skills. Il devient le lot AT.
2. Dépendance ou code maison ? Tranché : code maison, zéro dépendance (§3.1).
3. Placement ? Tranché : AT1 avec IM3 (P11 au plus tôt), AT2 et AT3 en P16, AT4 après.

Restent pour l'utilisateur, sans bloquer AT1 :

4. Faut-il un portrait par entrée de bible (ce qui ferait entrer DiceBear en AT4) ?
5. Le site lebrocoli.fr doit-il proposer l'atelier au public, ou seulement ai.recit.dev ?
6. Accepte-t-on des assets LPC dans des stories publiées, avec crédits et share-alike, ou les exclut-on de toute publication Récit ?

À reporter dans les autres documents si ce plan est accepté

• 11-images.md D10 : « projet basic » répondu, renvoi vers ce plan ; IM3 cite AT1.
• 14-ia-scenario.md : IA3 et IA4 citent AT3 ; §5.2, rien de nouveau dans NOTICE (aucun code repris).
• 06-roadmap.md : ligne du backlog « atelier de personnages », lots AT1 à AT4.
• journal.md : retirer « ce qu'est le projet basic » des questions restantes.