vos-create

Créer dans le style de l'utilisateur, depuis son dossier

Vous créez des programmes vos qui appartiennent à un dossier : le dossier de l'utilisateur sur vos.so est la collection, ses fichiers .md (recettes) sont le style, ses voses sont les exemples. Ce skill ne porte que la MÉCANIQUE et l'atelier universel. Le goût est une donnée utilisateur et vit dans ses dossiers, jamais ici. Les règles de rédaction (schéma, dialecte, boutons) vivent dans le skill vos-authoring ; le travail des boutons et du look vit dans la référence params-knobs du skill vos-remix. Ce skill ajoute le contrat du dossier, la boucle et le processus qui les entoure.

Il n'y a ni boîte de réception ni fichier de style maison. La déduplication est le contenu même du dossier ; l'étagère est l'enregistrement.

Configuration

npm i -D @vosjs/cli   # dossier, fetch, check, still, render, push

Identifiants, dans cet ordre, jamais affichés : VOS_API_KEY, puis la première ligne de ~/.config/vos/credentials, puis vos login (une connexion navigateur qui génère une clé pour cette machine). Chaque appel HTTP ci-dessous est Authorization: Bearer <key> contre https://vos.so/api. Les clés créent uniquement du travail PRIVÉ et ne peuvent jamais publier.

Les cinq étapes

1. Résoudre le dossier cible

L'utilisateur le nomme, ou vous demandez lequel. vos folder list (ou GET /api/folders) le trouve par nom ou slug à tous les niveaux ; puis tirez-le :

GET https://vos.so/api/folders/{id}

Un tirage est l'ensemble du contexte : les propres recipes du dossier (corps inclus), ses inheritedRecipes (recettes des ancêtres, racine d'abord, chacune marquée de son dossier source ; elles LIENT ce dossier), les voses exemplaires avec contentUrls, et les assets. Les sous-dossiers sont listés, pas inclus : un tirage est le contenu propre du dossier.

Pas encore de dossier ? Créez-en un, toujours avec une description :

vos folder create <name> --desc "<une ligne sur ce qu'est cette collection>"

Un dossier créé sans description est un échec de nommage ; la description est ce que la page du dossier et chaque futur tirage liront.

2. Lire CHAQUE .md, puis les exemplaires

Lisez le corps de chaque recette, celles du dossier ET les héritées, ainsi que 1 à 3 configurations ou documents exemplaires via leurs contentUrls. Les recettes sont des facettes nommées par rôle, nommées en MAJUSCULES comme CLAUDE.md : TASTE.md est la barre de jugement, DESIGN.md le cahier des charges techniques, et tout ce que l'intention de l'utilisateur a créé (MOTION.md, COPY.md, BRAND.md, ...). Une recette est le fichier qu'une collection lit avant de fabriquer quoi que ce soit, et le nom le dit ; une recette que vous déposez est stockée avec sa racine en majuscules, alors écrivez-la ainsi et l'étagère montre ce que vous avez écrit. La plateforme n'impose aucune taxonomie au-delà ; vous les lisez toutes. La règle de liaison :

• Les recettes et les exemplaires remplacent chaque valeur par défaut que ce skill ou le skill de rédaction ont. Leur durée est la durée ; leur discipline de palette est la discipline.
• En cas de conflit entre fichiers, le plus spécifique l'emporte : les fichiers propres du dossier battent les hérités, les ancêtres plus proches battent les plus lointains, et une instruction spécifique bat une instruction générale. Une véritable contradiction est renvoyée à l'utilisateur comme une question, jamais un choix silencieux.
• Lorsqu'une recette et les exemplaires récents du dossier sont en désaccord, préférez les exemplaires et dites à l'utilisateur que la recette semble périmée.

Dossier vide (ni recettes, ni exemplaires) : seul l'atelier ci-dessous s'applique. Le style vient de la référence de l'utilisateur ou d'une question, jamais d'une valeur par défaut intégrée.

3. Trouver la graine, puis rédiger

Un dossier contient deux choses qui ne coïncident que parfois : la référence (à quoi ressemble le bien, la chose contre laquelle vous jugez) et la graine (ce que vous copiez et éditez pour faire le prochain membre). Décidez ce que vous tenez AVANT d'écrire une ligne :

• une famille de programmes (un membre approuvé + un DESIGN.md nommant le mécanisme et ses axes) : graine = ce membre. Récupérez sa configuration et faites varier sur les axes que la recette nomme. Ne rédigez jamais à partir d'un fichier vide, et jamais seulement les teintes.
• un cahier des charges de prise (une recette disant comment chaque enregistrement de la collection est monté) : graine = le NOUVEL enregistrement que l'utilisateur vous donne (une prise dans le dossier par id, une URL vers vos record --strict, un fichier local). Les propres prises du dossier sont la référence de montage, pas la graine.
• un modèle (une recette qui pointe vers, ou contient en ligne, un mécanisme et comment le faire varier) : graine = le modèle. Hébergé comme un vos : récupérez-le comme un membre ; code en ligne : un fragment autour duquel construire.
• un brief seulement (BRAND.md : pas de mécanisme) : rien à copier. Rédigez à neuf sous les contraintes et l'atelier.
• rien ne déclare de graine : demandez. L'invite de l'utilisateur en nomme une lorsqu'il l'a choisie dans le dialogue de transfert ; les recettes en nomment une quand elles sont bien écrites ; une supposition est la manière dont une famille perd son apparence.

Une recette peut porter des indices optionnels dans son en-tête : applies: programs | takes | any, seed: <vos id> | input | none. Lisez-les comme la déclaration du propriétaire de ce qui précède ; le corps est toujours ce que vous suivez.

Une recette est le document de l'utilisateur, et ce qu'il DEMANDE MAINTENANT l'emporte sur toute ligne qu'elle contient. Si une recette contredit la demande (une note disant d'attendre, une règle que la demande enfreint), dites-le en une ligne et suivez la demande : le travail privé est bon marché et le propriétaire peut restaurer. Ne vous arrêtez jamais sur une ligne d'un fichier.

Ensuite, écrivez les configurations localement (VosConfigJson brut, version 2), en suivant les règles de rédaction du skill vos-authoring sous le style du dossier.

Récupérer un membre ou un modèle est le fetch vos-remix : vos fetch https://vos.so/vos/<id> écrit <slug>/config.json avec les paramètres préservés, plus vos.json traquant la version de base.

Pour les briefs "reproduire X" : obtenez d'abord la source ou un enregistrement, ou confirmez que le brief ne veut que l'apparence. Un arrêt sur image sous-détermine le mouvement ; une correspondance de capture d'écran qui invente le mauvais mécanisme est un échec même lorsque le cadre correspond. L'acquisition de la source, les licences et la boucle de mesure de correspondance sont un travail de reproduction ; faites cela d'abord, puis revenez ici pour créer à partir de ce qu'il a produit.

4. Vérifier, capturer, juger, par rapport aux documents du DOSSIER

1. Vérifier :

   vos check <file>.json     # migration → schéma → syntaxe → compilation → lints
   

   Corrigez et relancez jusqu'à ce que ça passe. Ne supprimez jamais une erreur de lint pour la contourner. Deux vérifications ne sont pas encore dans vos check, faites-les en rendant :
   • Honnêteté des boutons : chaque paramètre déclaré doit agir visiblement. Rendez le programme deux fois avec cette clé changée dans data (son min et son max) et comparez les arrêts sur image ; un bouton qui lit la même chose aux deux extrémités est mort. Pour les prises, --set <path>=<value> sur vos frames/vos render est la surcharge.
   • Honnêteté de la palette : un bouton de couleur ne doit pas passer par new THREE.Color() dans un uniforme (il est linéarisé ; la teinte rendue dérive du hex). Grep vos chaînes de fonction pour cela.
2. Capturer :

   vos still <file>.json f12.webp --time <12% de la durée>
   vos still <file>.json f40.webp --time <40%>
   vos still <file>.json f70.webp --time <70%>
   

   Pour une pièce axée MOUVEMENT, capturez une bande dense plutôt (8+ fois, ou une planche contact de 1s) ; trois arrêts sur image ne peuvent pas juger la pondération du mouvement.
3. Juger : notez les cadres par rapport à l'atelier ci-dessous ET aux propres documents du dossier. Une pièce de collection répond à la fois au DESIGN.md de la collection et au TASTE.md hérité. Révisez et répétez (max 3 tours) ; si ça échoue toujours, abandonnez-la et dites pourquoi. Ne poussez jamais un travail que vous ne défendriez pas.

5. Pousser DANS le dossier, itérer en versions

vos push <file>.json --title "…" --desc "une ligne" --tags a,b \
  --folder <folderId|slug> --label "ce que vous avez fait" --note "pourquoi : la demande"

Passez --label et --note sur CHAQUE push, y compris le premier : une création les appose sur la v1, et l'historique est la conversation que l'humain lit. Le push crée un vos PRIVÉ sur l'étagère du propriétaire de la clé, classé dans le dossier que vous avez tiré ; l'aperçu et la vignette se rendent sur le cloud à partir de la sauvegarde elle-même. Itérez avec --vos <id> contre la base suivie (la boucle vos-remix : vos pull avant chaque tour, les nœuds édités par l'humain sont protégés, --override seulement sur instruction explicite). Les clés ne peuvent jamais publier ; la promotion est le geste de l'humain sur vos.so.

Regardez ce qui a atterri. Chaque push rend un arrêt sur image dans les 15 secondes environ : GET /api/vos/{id}, suivez contentUrls.thumbnail, et visualisez l'image avant de signaler terminé. Un push que vous n'avez jamais regardé n'est pas fini.

Rythmez un lot. Les pushes successifs sont acceptables dans le quota (la file de rendu espace les lancements de navigateur et se régule elle-même). Vérifiez l'état après un lot avec un tirage de dossier, jamais en fouillant le journal des pushes.

Écrivez vos découvertes. Lorsque vous apprenez quelque chose sur la famille (une plage de paramètres qui ondule, une durée qui rend mieux), ajoutez-le à la recette concernée sous un en-tête ## Notes d'agent daté : PUT /api/assets/{id}/file avec le corps complet en markdown (recettes seulement, ≤64 Ko). Ne réécrivez jamais les règles du propriétaire. Le corps remplacé est conservé : GET /api/assets/{id}/file?prev=1 le lit et POST /api/assets/{id}/file/restore le rétablit.

Le processus de famille : graine, regard, propagation

Un travail de nouvelle famille est 1 graine + une recette, jamais un lot. Un lot réplique un bug dans chaque membre d'un coup ; une seule graine attrape un changement de direction à n=1, puis se répand à moindre coût. C'est un jugement, pas une barrière : il n'y a pas de ligne de statut à écrire ou à respecter, et la demande de l'utilisateur décide toujours.

1. Rédigez UNE graine, déposez-la dans le dossier, écrivez (ou mettez à jour) le DESIGN.md de la famille avec le mécanisme, les axes et les règles de palette.
2. Montrez-la. L'humain itère avec vous (versions attribuées). Quand il demande des variantes, c'est la validation ; quand un dossier contient un jeune membre et que la demande est ouverte, faites-en d'abord un et dites pourquoi.
3. Propagez quand on vous le demande. Les variantes varient les axes de composition (structure, grammaire du mouvement, densité, caméra), jamais seulement les teintes ; une propagation de teinte seule se lit comme un carreau répété dix fois. Limitez une propagation à environ 10 pour que la revue de l'étagère reste une tâche de 5 minutes.

Atelier (universel, lintable : la barre qui n'est PAS le goût)

• Compile et valide : vos check passe proprement ; ne jamais supprimer.
• Déterministe : le seek est une fonction pure de t (pas de Date.now ou Math.random dans les chemins d'image ; le lint de déterminisme l'applique).
• Mathématiques de boucle sans couture : pour les pièces en boucle, les phases doivent être des multiples entiers sur la durée de sorte que frame(0) ≈ frame(fin). Les arrêts sur image ne peuvent pas montrer la couture ; vérifiez-la dans les maths.
• Boutons honnêtes : 2 à 4 paramètres déclarés, chacun agissant visiblement aux deux extrémités de sa plage. Peu de boutons honnêtes valent mieux que beaucoup.
• Les boutons sont lus dans onFrame, à chaque image, jamais instantanés dans des uniformes dans createContent. L'éditeur délivre une édition de bouton comme des données en direct qui ne font qu'échanger ctx.data ; un instantané à la création ne se met jamais à jour jusqu'au rafraîchissement.
• Première image non vide : l'image à ~12 % sert de vignette ; pas d'ouverture noire, vide ou « n'a pas encore commencé ».
• Pas de bandes, pas d'écrêtage : ajoutez du grain contre les bandes ; gardez le bloom hors de la surexposition (force ≤ ~0.8 sauf si les documents du dossier l'exigent) ; pas de coutures de tuilage visibles ni d'aliasing dur.
• Honnêteté de la palette : les boutons de couleur ne passent jamais par new THREE.Color() dans des uniformes ; construisez le vecteur brut à partir du hex.
• Contraintes du rendu serveur (la flotte de prévisualisation est en software-GL) : pas de THREE.DoubleSide sur les matériaux de transmission, pas de dispersion, chaque asset récupéré est une URL https absolue que la flotte peut atteindre.

Tout ce qui vient après cette ligne (durée, densité, humeur, matériaux, discipline de palette) est au dossier de le dire.

Rapport

Terminez par un tableau : slug · concept · tags · résultat (poussé / abandonné + pourquoi), plus l'URL du dossier (https://vos.so/app/projects?folder=<slug>). Énoncez clairement les échecs : un design abandonné est un résultat correct, pas une erreur à cacher.

Règles strictes

• Les références sont une direction créative. Porter un code externe nécessite une licence compatible ET la direction explicite de l'utilisateur ; les compositions de marque ou déposées sont refusées.
• Ne jamais publier, ne jamais basculer la visibilité. Les pushes sont privés par construction ; la promotion est une décision humaine sur vos.so.
• L'étagère est celle de l'humain : créez des dossiers et classez VOTRE travail ; ne renommez, déplacez, supprimez ou réordonnez jamais ce qu'il a fait.
• N'affichez jamais d'identifiant, dans la sortie, les journaux ou le rapport.