vos-criar

Criar no estilo do usuário, a partir da sua pasta

Você cria programas vos que pertencem a uma pasta: a pasta do usuário no vos.so é a coleção, seus arquivos .md (receitas) são o estilo, seus voses são os exemplares. Este skill carrega apenas a MECÂNICA e o chão de fábrica universal. O gosto são dados do usuário e vive em suas pastas, nunca aqui. As regras de autoria (esquema, dialeto, knobs) vivem no skill vos-authoring; a arte de knobs e Looks, na referência de parâmetros e knobs do skill vos-remix. Este skill adiciona o contrato da pasta, o laço e o processo em torno deles.

Não há caixa de entrada nem arquivo de estilo da casa. A deduplicação é o conteúdo da própria pasta; a estante é o registro.

Configuração

npm i -D @vosjs/cli   # pasta, buscar, verificar, still, renderizar, enviar

Credenciais, nesta ordem, nunca impressas: VOS_API_KEY, depois a primeira linha de ~/.config/vos/credentials, depois vos login (um login no navegador que gera uma chave para esta máquina). Cada chamada HTTP abaixo é Authorization: Bearer <key> contra https://vos.so/api. Chaves criam trabalho PRIVADO apenas e nunca podem publicar.

As cinco etapas

1. Resolver a pasta alvo

O usuário a nomeia, ou você pergunta qual. vos folder list (ou GET /api/folders) encontra-a pelo nome ou slug em todos os níveis; então, puxe-a:

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

Uma única puxada é o pacote de contexto completo: as recipes da própria pasta (corpos inlineados), suas inheritedRecipes (receitas ancestrais, raiz primeiro, cada uma marcada com sua pasta de origem; elas VINCULAM esta pasta), voses de exemplo com contentUrls, e assets. As subpastas são listadas, não inlineadas: uma puxada é o conteúdo da própria pasta.

Ainda não tem pasta? Crie uma, sempre com uma descrição:

vos folder create <nome> --desc "<uma linha sobre o que é esta coleção>"

Uma pasta criada sem descrição é uma falha de nomenclatura; a descrição é o que a página da pasta e toda puxada futura lerão.

2. Ler CADA .md, depois os exemplares

Leia o corpo de cada receita, as da própria pasta E as herdadas, e de 1 a 3 configurações ou documentos exemplares através de seus contentUrls. As receitas são facetas nomeadas por função, nomeadas em MAIÚSCULAS como CLAUDE.md é: TASTE.md é a barra de julgamento, DESIGN.md a especificação de técnica, e tudo o mais que a intenção do usuário criou (MOTION.md, COPY.md, BRAND.md, ...). Uma receita é o arquivo que uma coleção lê antes de fazer qualquer coisa, e o nome é o que assim o diz; uma receita que você arquiva é armazenada com sua raiz em maiúsculas, então escreva-a dessa forma e a estante mostrará o que você escreveu. A plataforma não impõe taxonomia além disso; você lê todas elas. A regra de vinculação:

• Receitas e exemplares substituem todo padrão que este skill ou o skill de autoria têm. A duração é a duração; a disciplina de paleta é a disciplina.
• Em caso de conflito entre arquivos, o mais específico vence: os arquivos da própria pasta vencem os herdados, ancestrais mais próximos vencem os mais distantes, e uma instrução específica vence uma geral. Uma contradição genuína volta para o usuário como uma pergunta, nunca uma escolha silenciosa.
• Quando uma receita e os exemplares recentes da pasta discordam, prefira os exemplares e diga ao usuário que a receita parece desatualizada.

Pasta vazia (sem receitas, sem exemplares): apenas o chão de fábrica abaixo se aplica. O estilo vem da referência do usuário ou de uma pergunta, nunca de um padrão embutido.

3. Encontrar a semente, depois criar

Uma pasta contém duas coisas que só às vezes coincidem: a referência (o que parece bom, a coisa contra a qual você julga) e a semente (o que você copia e edita para fazer o próximo membro). Decida qual você está segurando ANTES de escrever uma linha:

• uma família de programas (um membro aprovado + um DESIGN.md nomeando o mecanismo e seus eixos): semente = esse membro. Busque sua configuração e varie-a nos eixos que a receita nomeia. Nunca crie a partir de um arquivo em branco, e nunca apenas as matizes.
• uma especificação de take (uma receita dizendo como cada gravação na coleção é cortada): semente = a NOVA gravação que o usuário lhe dá (um take na pasta por id, uma URL para vos record --strict, um arquivo local). Os takes da própria pasta são o corte de referência, não a semente.
• um template (uma receita que aponta para, ou inlinea, um mecanismo e como variá-lo): semente = o template. Hospedado como um vos: busque-o como um membro; código inlineado: um fragmento para construir ao redor.
• apenas um briefing (BRAND.md: sem mecanismo): nada para copiar. Crie do zero sob as restrições e o chão de fábrica.
• nada declara uma semente: pergunte. O prompt do usuário nomeia uma quando ele a escolheu no diálogo de transferência; as receitas nomeiam uma quando estão bem escritas; um palpite é como uma família perde sua aparência.

Uma receita pode carregar dicas opcionais de frontmatter: applies: programs | takes | any, seed: <vos id> | input | none. Leia-as como a declaração do proprietário sobre o acima; o corpo ainda é o que você segue.

Uma receita é o documento do usuário, e o que ele PEDE AGORA tem precedência sobre qualquer linha nela. Se uma receita contradiz o pedido (uma nota que diz para esperar, uma regra que o pedido quebra), diga isso em uma linha e siga o pedido: trabalho privado é barato e o proprietário pode restaurar. Nunca pare em uma linha de um arquivo.

Em seguida, escreva as configurações localmente (VosConfigJson puro, versão 2), seguindo as regras de autoria do skill vos-authoring sob o estilo da pasta.

Buscar um membro ou um template é a busca do vos-remix: vos fetch https://vos.so/vos/<id> escreve <slug>/config.json com parâmetros preservados, mais vos.json rastreando a versão base.

Para briefings "reproduzir X": obtenha a fonte ou uma gravação primeiro, ou confirme que o briefing quer apenas a aparência. Um still subdetermina o movimento; uma correspondência de captura de tela que inventa o mecanismo errado é um erro mesmo quando o quadro concorda. Aquisição de fonte, licenciamento e o laço de medição correspondente são trabalho de reprodução; faça isso primeiro, depois volte aqui para criar a partir do que isso produziu.

4. Verificar, fotografar, julgar, contra os documentos da PASTA

1. Verificar:

   vos check <arquivo>.json     # migrar → esquema → sintaxe → compilar → lints
   

   Corrija e execute novamente até passar. Nunca suprima um erro de lint para passar adiante. Duas verificações não estão em vos check ainda, então faça-as renderizando:
   • Honestidade do knob: cada parâmetro declarado deve agir visivelmente. Renderize o programa duas vezes com essa chave alterada em data (seu mínimo e seu máximo) e compare os stills; um knob que lê o mesmo em ambas as extremidades está morto. Para takes, --set <caminho>=<valor> em vos frames/vos render é a substituição.
   • Honestidade da paleta: um knob de cor não deve passar por new THREE.Color() dentro de um uniforme (ele é linearizado; a matiz renderizada se desvia do hex). Pesquise suas strings de função por isso.
2. Fotografar:

   vos still <arquivo>.json f12.webp --time <12% da duração>
   vos still <arquivo>.json f40.webp --time <40%>
   vos still <arquivo>.json f70.webp --time <70%>
   

   Para uma peça LIDERADA POR MOVIMENTO, fotografe uma tira densa (8+ vezes, ou uma folha de contato de 1s); três stills não podem julgar a ponderação do movimento.
3. Julgar: pontue os quadros contra o chão de fábrica abaixo E os documentos da própria pasta. Uma peça de coleção responde tanto ao DESIGN.md da coleção quanto ao TASTE.md herdado. Revise e repita (máx. 3 rodadas); se ainda falhar, descarte-a e diga por quê. Nunca envie trabalho que você não defenderia.

5. Enviar PARA a pasta, iterar como versões

vos push <arquivo>.json --title "…" --desc "uma linha" --tags a,b \
  --folder <folderId|slug> --label "o que você fez" --note "porquê: o pedido"

Passe --label e --note em CADA envio, inclusive o primeiro: uma criação os carimba na v1, e o histórico é a conversa que o humano lê. O envio cria um vos PRIVADO na estante do proprietário da chave, arquivado na pasta que você puxou; a pré-visualização e a miniatura são renderizadas na nuvem a partir do próprio salvamento. Itere com --vos <id> contra a base rastreada (o laço vos-remix: vos pull antes de cada rodada, nós editados por humanos são protegidos, --override apenas sob instrução explícita). Chaves nunca podem publicar; a promoção é um gesto humano no vos.so.

Veja o que chegou. Cada envio renderiza um still em cerca de 15 segundos: GET /api/vos/{id}, siga contentUrls.thumbnail, e veja a imagem antes de reportar a conclusão. Um envio que você nunca viu não está terminado.

Dosear um lote: envios consecutivos são ok na cota (a fila de renderização espaça as inicializações do navegador e faz back-off sozinha). Verifique estado após um lote com uma puxada de pasta, nunca examinando o log de envios.

Escreva descobertas de volta. Quando você aprende algo sobre a família (um intervalo de parâmetros que cria faixas, uma duração que soa melhor), anexe-o à receita relevante sob um título datado ## Notas do agente: PUT /api/assets/{id}/file com o corpo markdown completo (receitas apenas, ≤64KB). Nunca reescreva as regras do proprietário. O corpo substituído é mantido: GET /api/assets/{id}/file?prev=1 o lê e POST /api/assets/{id}/file/restore o troca de volta.

O processo da família: semente, olhar, espalhar

O trabalho de nova família é 1 semente + uma receita, nunca um lote. Um lote replica um bug em cada membro de uma vez; uma única semente captura uma mudança de direção em n=1, depois espalha-se barato. Isso é julgamento, não um portal: não há linha de status para escrever ou obedecer, e o pedido do usuário sempre decide.

1. Crie UMA semente, coloque-a na pasta, escreva (ou atualize) o DESIGN.md da família com o mecanismo, eixos e regras de paleta.
2. Mostre-a. O humano itera com você (versões atribuídas). Quando eles pedirem variantes, isso É a aprovação; quando uma pasta contém um membro jovem e o pedido é aberto, faça um primeiro e diga por quê.
3. Espalhe quando pedido. Variantes variam eixos de composição (estrutura, gramática de movimento, densidade, câmera), nunca apenas matizes; uma propagação só de matizes parece um azulejo dez vezes. Limite uma propagação a cerca de 10 para que a revisão da estante permaneça uma tarefa de 5 minutos.

Chão de fábrica (universal, lintável: a barra que NÃO é gosto)

• Compila e valida: vos check passa limpo; nunca suprima.
• Determinístico: seek é uma função pura de t (sem Date.now ou Math.random em caminhos de quadro; o lint de determinismo o impõe).
• Matemática de emenda de loop: para peças looping, as fases devem ser múltiplos inteiros sobre a duração para que quadro(0) ≈ quadro(final). Stills não podem mostrar a emenda; verifique na matemática.
• Knobs honestos: 2 a 4 parâmetros declarados, cada um agindo visivelmente em ambas as extremidades de seu intervalo. Poucos knobs honestos vencem muitos.
• Knobs são lidos em onFrame, a cada quadro, nunca capturados em uniforms dentro de createContent. O editor entrega uma edição de knob como dados vivos que apenas trocam ctx.data; uma captura no momento da criação nunca atualiza até a atualização.
• Primeiro quadro não vazio: o quadro ~12% serve como miniatura; sem aberturas pretas, vazias ou "ainda não começou".
• Sem faixas, sem clipping: adicione granulado contra faixas; mantenha bloom fora do blowout (força ≤ ~0.8 a menos que os documentos da pasta exijam); sem costuras de tile visíveis ou aliasing duro.
• Honestidade da paleta: knobs de cor nunca passam por new THREE.Color() dentro de uniforms; construa o vetor bruto a partir do hex.
• Restrições de renderização do servidor (a frota de pré-visualização é software-GL): sem THREE.DoubleSide em materiais de transmissão, sem dispersion, cada asset buscado uma URL https absoluta que a frota pode alcançar.

Tudo após esta linha (duração, densidade, humor, materiais, disciplina de paleta) é a pasta que deve dizer.

Relatório

Termine com uma tabela: slug · conceito · tags · resultado (enviado / descartado + porquê), mais o URL da pasta (https://vos.so/app/projects?folder=<slug>). Declare falhas claramente: um design descartado é um resultado correto, não um erro a esconder.

Regras rígidas

• Referências são direção criativa. Portar código externo precisa de uma licença compatível E a direção explícita do usuário; composições marcadas ou registradas são recusadas.
• Nunca publique, nunca alterne a visibilidade. Envios são privados por construção; a promoção é uma decisão humana no vos.so.
• A estante é do humano: crie pastas e arquive SEU trabalho; nunca renomeie, mova, exclua ou reordene o que eles fizeram.
• Nunca imprima uma credencial, na saída, logs ou relatório.