@vosjs/cli 0.47.0 → 0.48.1

package/skills/vos-migrate/SKILL.md

@@ -0,0 +1,108 @@
+---
+name: vos-migrate
+description: Turn an existing Loom, Screen Studio, Cap, or plain mp4/webm screen demo into an editable vosso take — re-encode the file, synthesize the take's metadata, plan, and push, so the old demo becomes a living document you re-cut instead of a file you re-record. Use when asked to "convert this Loom", "migrate our old demos", "re-edit this mp4", "make our Screen Studio recording editable", or to bring any already-recorded demo into vosso.
+license: MIT
+---
+
+# Migrate a recorded demo into an editable take
+
+You are turning a FINISHED video file into a vosso take: a document whose
+zooms, trims, speed and layers are data, hosted with version history, and
+editable in the studio. What the file loses by being foreign is honesty
+you must carry: it has NO cursor track, so nothing can be auto-zoomed and
+the digest sees little — your eyes are the contact sheet, and every zoom
+is placed by eye.
+
+Two doors:
+
+- **The human door**: drop the file on https://vos.so/studio — it enters as
+  the browser-recorder shape and opens in the take editor directly. When a
+  human is present, this is the shortest path; hand them the link.
+- **The agent door** (this skill): build the take directory yourself and
+  run the normal pipeline. Proven end to end below.
+
+## 1. Probe the source
+
+```bash
+ffprobe -v quiet -print_format json -show_streams -show_format demo.mp4
+```
+
+Keep: width, height, duration, fps, whether an audio stream exists. A
+Loom/Screen Studio export is typically 1080p H.264 with the camera bubble
+and any edits BAKED IN — they migrate as pixels, not as layers. Say so in
+the handoff: the migration makes the file editable from here on, it does
+not un-bake old edits.
+
+## 2. Build the take directory
+
+```bash
+mkdir take
+ffmpeg -i demo.mp4 -c:v libvpx-vp9 -crf 34 -b:v 0 -row-mt 1 \
+       -c:a libopus take/recording.webm     # drop -c:a if no audio stream
+```
+
+Then write `take/meta.json` from the probe (every field required; times in
+ms; `producer: "migrated"` marks provenance):
+
+```json
+{
+  "producer": "migrated",
+  "dpr": 1, "zoom": 1,
+  "t0": 0,
+  "durationMs": 36766,
+  "width": 1920, "height": 1080,
+  "fps": 30,
+  "hasAudio": false
+}
+```
+
+`t0` may be any epoch ms; `width`/`height` are the video pixels (there was
+no browser viewport). Set `hasAudio` true only when the webm actually
+carries the track.
+
+## 3. Plan, and see it honestly
+
+```bash
+vos plan take --fresh       # builds doc.json; cursorKept false, zoomAuto 0
+vos frames take --times 0,10%,25%,50%,75%,90%,100%   # the contact sheet IS your eyes
+vos digest take             # runs, but expect little: head/tail and only
+                            # hard scene cuts - no clicks, no typing, no dwells
+```
+
+No auto-zoom is possible and none should be faked. Read the stills, find
+the 2–4 moments that matter, and write manual spans by eye:
+
+```bash
+# doc.json - every span you add carries "source": "manual"
+# zoom: [{ "id": "m1", "in": 10.5, "out": 14.0, "level": 1.6,
+#          "cx": 0.52, "cy": 0.35, "source": "manual" }]
+# segments: trim dead heads/tails; speed: only where footage truly idles
+```
+
+Set `export.resolution` to MATCH the footage (a 1080p source is `1080p` —
+migrating does not add pixels). `vos validate take` must pass; spot-check
+with `vos render take check.webm --range a..b --draft`.
+
+## 4. Push — the old demo becomes a living document
+
+```bash
+vos push take --folder <project> --label "migrated from <source>" \
+    --note "<what it shows; that old edits are baked; what you re-cut>"
+```
+
+End on the loop: the watch page plays it, the studio edits every span you
+wrote plus everything the file never had (backdrops, text layers, speed),
+and `vos pull` brings human edits back down. The pitch belongs in the
+handoff, in one line: **this is the last demo you edit blind — record the
+next one with `vos record` and the camera plans itself.**
+
+## Honest limits (say them, never paper over them)
+
+- No cursor track ⇒ no auto-zoom, no click effects, no typing zooms, and
+  no framing lint — every zoom is yours, by eye, and you say so.
+- Old edits, camera bubbles and captions are baked pixels.
+- The migration re-encodes once (VP9); a badly compressed source stays
+  badly compressed — migrating does not restore quality.
+- A spec-size deliverable ladder (store stills, posters) works from the
+  migrated take exactly as from a native one — the `launch-kit` skill
+  takes over when the ask is a release.

package/skills/vos-remix/SKILL.md

@@ -0,0 +1,136 @@
+---
+name: vos-remix
+description: Remix a vos.so gallery program into your own — fetch its config, edit the declared knobs or code locally, validate with vos check, and push a private copy back with lineage that iterates as versions. Carries the params/Looks doctrine and the GLB 3D-showcase recipe. Use when asked to remix, customize or personalize a gallery animation, swap a 3D model into a showcase, or iterate a fetched program as versions.
+license: MIT
+---
+
+# Remix a vos program
+
+Every video on [vos.so/gallery](https://vos.so/gallery) is a program:
+inputs + a deterministic function → video. Remixing is editing that
+program's JSON config and pushing the result back as a **private** vos on
+the user's account, with lineage. You edit locally; the platform validates,
+compiles, and renders a preview.
+
+## Setup
+
+```bash
+npm i -D @vosjs/cli   # the fetch/check/push/pull loop
+```
+
+No browser needed for this loop (rendering previews happens on the
+platform). Everything also works as plain HTTP if the CLI is unavailable:
+`references/remix-contract.md` documents every endpoint.
+
+## Credentials (never print them)
+
+Two shapes, both used as `Authorization: Bearer`:
+
+1. **Remix grant** (`vos_rg_…`) — if the user's prompt contains one, use it.
+   24h lifetime, bound to ONE source vos, max 5 pushes.
+2. **Durable key** (`vos_sk_…`) — resolution order before asking:
+   `VOS_API_KEY` env, then the first line of `~/.config/vos/credentials`.
+   Humans mint keys at https://vos.so/app/api.
+3. **No credential at all** — the claimable push (programs only):
+   ```bash
+   vos push my-remix.json --claimable --title "My remix"
+   # → claim: https://vos.so/claim/…   expires: <72h from now>
+
+   # No CLI, or an older one? The same thing over plain HTTP:
+   curl -s -X POST https://vos.so/api/claim \
+     -H 'content-type: application/json' \
+     -d '{"title": "My remix", "config": <the VosConfigJson>}'
+   # → { "claimUrl": "https://vos.so/claim/…", "expiresAt": "…" }
+   ```
+   Hand `claimUrl` to the user and nowhere else — it is the only reference
+   and the only credential. The link lasts 72 hours; unclaimed work is
+   deleted after that (deliberate cleanup, not data loss — re-push if it
+   lapses). Claiming moves the vos into the user's library and starts its
+   hosted preview; iteration after claim rides their key (the loop below).
+   Limits: config ≤200KB, 5 pushes per day per network.
+
+The CLI resolves grants and keys automatically (`export VOS_API_KEY=…`). No
+shape can publish: pushed voses stay private until a human publishes on
+vos.so.
+
+## The loop
+
+1. **Fetch** the source program (public programs need no auth):
+   ```bash
+   vos fetch https://vos.so/vos/<id>        # or the bare id
+   # → <slug>/config.json (params preserved) + <slug>/vos.json (tracking)
+   ```
+
+2. **Edit** `config.json` locally. The function fields (`setup`,
+   `createContent`, `createTimeline`, `onFrame`) are JavaScript **as
+   strings** — no TypeScript syntax, no `${}` template interpolation.
+   Change 1–2 axes decisively (palette, motion grammar, density) — never a
+   10%-nudge duplicate. If the program declares `params`, prefer retuning
+   or extending those knobs over surgery on function strings.
+
+3. **Declare knobs and Looks** — the remix's control surface. 2–4
+   intent-named params plus 2–3 presets. This is a craft with rules:
+   `references/params-knobs.md`.
+
+4. **Check** locally before pushing:
+   ```bash
+   vos check <slug>/config.json     # migrate → schema → syntax → compile → lints
+   vos still <slug>/config.json probe.webp --time 2   # RUN it — check compiles
+                                    # but never executes the module; a runtime
+                                    # throw (a TDZ against the function's own
+                                    # declarations) ships invisibly on check
+                                    # alone. Render a still after every code
+                                    # edit, before every push.
+   ```
+   Fix every error; treat determinism warnings seriously (a config that
+   renders differently per run is broken by definition).
+
+5. **Push** as a private vos with lineage (the CLI reads `vos.json` beside
+   the config for the `remixOfId` credit):
+   ```bash
+   vos push <slug>/config.json --title "Aurora Ribbons — dusk"
+   # → Created private vos <id>
+   #   watch:  https://vos.so/vos/<id>
+   #   studio: https://vos.so/studio?vos=<id>
+   ```
+
+6. **Iterate** — further edits become versions of the same vos:
+   ```bash
+   vos push <slug>/config.json --vos <id> --note "cooler palette, slower drift"
+   ```
+   The directory TRACKS its vos through `vos.json`, so the base version is
+   carried automatically: if the human edited in the studio since your last
+   push, the push is rejected WITH their typed changelog. `--note` is your
+   handoff line — it is what the human reads first; `--label` names the
+   version.
+
+7. **Pull before every editing round** — the human may have fine-tuned:
+   ```bash
+   vos pull <slug>          # what changed since your base, then sync
+   ```
+   Prints each version attributed (`v3 (studio · warmer): knob hue 0.2→0.35`
+   plus their notes), syncs `config.json` to the head (your previous copy is
+   kept as `config.backup.json`), and repoints the base. **Human-edited
+   nodes are protected**: a push that touches them is rejected unless you
+   pass `--override <id>` — do that ONLY when the user's instruction
+   explicitly targets that node. Their turns of your knobs are preference
+   data: read the changelog before deciding what to do next.
+
+8. **Hand back BOTH links** — the watch page (preview, knobs, code) and the
+   studio (`https://vos.so/studio?vos=<id>`) where the user fine-tunes your
+   knobs live. Publishing is their act, on vos.so.
+
+## Rules that keep pushes honest
+
+- **Private is the contract.** Never try `visibility: "public"` — it clamps
+  to private, and publishing by key is rejected by design.
+- **Quota-aware**: durable keys create ≤50 voses/24h; grants push ≤5. Iterate
+  versions on one vos instead of creating many voses.
+- **Server-render constraints** (the preview fleet is software-GL): no
+  `THREE.DoubleSide` on transmission materials, no `dispersion`, and every
+  fetched asset must be an absolute `https` URL the fleet can reach.
+- **Every knob must act.** A param the code never reads is worse than no
+  param — see the honesty section of `references/params-knobs.md`.
+- 3D model swaps (GLB into a showcase program): `references/3d-recipe.md`.
+- Full endpoint reference, quotas, and error table:
+  `references/remix-contract.md`.

package/skills/vos-remix/references/3d-recipe.md

@@ -0,0 +1,37 @@
+# The 3D recipe — showcase a model
+
+The 3D showcase programs (gallery tag `3d` — e.g. Studio Turntable, Dolly
+Reveal: https://vos.so/gallery?tag=3d) are built to take a model swap.
+
+## Steps
+
+1. **Fetch** a 3d-tagged program: `vos fetch <its watch URL>`.
+2. **Point it at the model**, either way:
+   - Add or replace the async `setup` field to load a GLB by URL:
+     ```js
+     "setup": "async (ctx) => { const gltf = await new ctx.loaders.GLTFLoader().loadAsync('https://…/model.glb'); return { model: gltf.scene } }"
+     ```
+     then replace the `buildProduct()` body — it is commented as **THE SWAP
+     POINT** in these programs — with the loaded `setupData.model`,
+     bbox-normalized to ~1.7 units and grounded at `y = 0` (the templates
+     ship the normalization snippet; keep it so `scale` knobs stay
+     model-independent).
+   - Or keep the template's own product and only retune params.
+3. **The model URL must be CORS-clean and absolute `https`.** Assets
+   uploaded to vos.so (`POST /api/assets/upload`, browser-session auth,
+   `.glb`/`.gltf` ≤50MB) serve public+immutable with `ACAO: *` at
+   `/api/assets/{id}/file` — bake that absolute URL into the config so the
+   platform's preview render can fetch it. Any other host must send
+   `Access-Control-Allow-Origin` and be publicly reachable.
+4. **Knob honesty on GLBs**: the template's material knobs (hue, finish) do
+   nothing on a GLB's own materials — declare only params that act
+   (backdrop, light mood, camera pace, and whatever you wire yourself).
+   Verify per `params-knobs.md` rule 2.
+5. **Check and push** as usual: `vos check` → `vos push`. Humans do the
+   same flow UI-side by dropping a GLB on https://vos.so/gallery.
+
+## Server-render cautions (the preview fleet)
+
+- No `THREE.DoubleSide` on transmission materials; no `dispersion`.
+- Big GLBs slow the preview render — prefer draco-compressed models and
+  keep textures ≤2K for the showcase context.

package/skills/vos-remix/references/params-knobs.md

@@ -0,0 +1,80 @@
+# Params and Looks — the control surface you ship
+
+A remix delivers output *plus the controls you considered while making it*.
+The human's next instruction can be a knob turn, a prompt in knob
+vocabulary, or both: human instructs → agent creates (program + knobs +
+Looks) → human feels the space and settles or redirects → settled values
+bake in, the surface renegotiates, repeat. **You ship an interface, not
+just an artifact.**
+
+## Format
+
+```json
+"params": [{ "key": "hue", "label": "Hue", "kind": "number",
+             "min": 0, "max": 1, "default": 0.6,
+             "hint": "Shifts every color around the wheel",
+             "unit": "°", "group": "Color", "order": 1 }]
+```
+
+- kinds: `number` (min/max/step) | `color` | `select` (options) | `toggle`
+- `hint`: ONE sentence on what visibly changes — always write it
+- `unit` shows inside the number field (`px` `%` `s` `×` `°`);
+  `group`/`order` cluster related knobs into their own panel card
+- The program reads each key from `ctx.data` where it animates:
+  ```js
+  const d = ctx.data || {}
+  if (typeof d.hue === 'number') u.uHue.value = d.hue
+  ```
+
+Looks are named points in param space — free variants (one program, three
+directions, zero extra render cost):
+
+```json
+"presets": [{ "name": "Vivid", "values": { "hue": 0.9, "speed": 2 } },
+            { "name": "Calm",  "values": { "hue": 0.3, "speed": 0.6 } }]
+```
+
+Values must reference declared param keys with matching types (anything
+else is dropped on save; max 8 Looks, names ≤24 chars). Ship 2–3 Looks
+whenever the program has 4+ params.
+
+## The five rules
+
+1. **The knob budget is a negotiation, not an accumulation.** Curate 2–4
+   knobs (the schema caps at 12). A knob earns its slot by being touched or
+   asked about. **Collapse**: when the human settles a value and stops
+   touching it, bake it into the code as the new default and free the slot —
+   the surface is a cache of live decisions, not an archive. **Promotion**:
+   recurring prompt themes become knobs ("you keep circling pacing — I
+   added `pace`").
+2. **Knob honesty is renderable.** Every knob must visibly change the
+   output. Verify: render frames at several points of the knob's range and
+   compare — min, MIDPOINT, max for numbers. The midpoint matters:
+   circular quantities (hue is the classic) look identical at the two range
+   ends (±half a turn is the same rotation), so a min-vs-max check calls a
+   working knob dead. If the best pair is near-identical, the knob is dead;
+   wire it or drop it. Fake agency poisons the whole paradigm.
+3. **Respect human-set values.** A value the human adjusted is theirs — when
+   you regenerate code, preserve what each knob does. Renaming or retiring
+   a knob is something you SAY in the iteration note ("replaced `speed`
+   with `tempo`"), never something that happens silently. This rule is
+   ENFORCED: the platform rejects a push that touches nodes a studio
+   version edited since your last push, until you pass `--overrides` — the
+   consent switch for "the user asked me to change exactly this".
+4. **Name knobs by intent, not implementation** — `mood`, `drama`, `pace`;
+   never `blurRadius`. The knob is language between two authors; its name
+   becomes the vocabulary of the next prompt.
+5. **State the boundary.** Knobs cover the aesthetic space (continuous or
+   enumerable dimensions). Structural change — a new scene, a new object, a
+   different narrative — stays prompt territory. Knobs are for feeling;
+   prompts are for asking.
+
+## Craft notes
+
+- A `select` of curated combinations often beats three independent numbers
+  (e.g. `mood: dusk | noon | neon` driving palette + light together).
+- Defaults must reproduce the pushed output exactly: knobs at defaults =
+  the video you shipped.
+- On GLB/model swaps, template material knobs usually stop acting (the
+  model brings its own materials) — see `3d-recipe.md`; declare only knobs
+  you have verified act.

package/skills/vos-remix/references/remix-contract.md

@@ -0,0 +1,81 @@
+# The remix contract (HTTP)
+
+Mirror of https://vos.so/llms-remix.txt — the canonical, always-current
+copy. Everything the CLI's `fetch`/`check`/`push` do rides these endpoints;
+use them directly when the CLI is unavailable.
+
+## Auth
+
+Two credential shapes; NEVER print either.
+
+1. **Remix grant** (`vos_rg_…`) — ephemeral, zero-setup. The watch page's
+   "remix with your agent" prompt embeds one. Grants expire in 24h and are
+   bound to ONE source vos: they can only POST remixes of it (`remixOfId`
+   required, max 5 pushes), iterate the voses they created, and read those.
+2. **Durable content key** (`vos_sk_…`) — minted at https://vos.so/app/api.
+   Resolution order before asking the user: `VOS_API_KEY` env, then
+   `~/.config/vos/credentials` (first line). If the user pastes a key into
+   chat, use it — and suggest rotating it afterward.
+
+```
+Authorization: Bearer <token>
+```
+
+Both shapes can create/read/iterate voses. They can NEVER publish
+(`visibility: "public"` is clamped or rejected — publishing stays a human
+act on vos.so) and never touch the render API. Durable-key creates are
+quota'd (50/24h).
+
+## Endpoints
+
+| Call | What |
+| --- | --- |
+| `GET /api/vos/{id}` | metadata: title, slug, params, `contentUrls`, `forkedFrom`, `currentVersionId` |
+| `GET /api/vos/{id}/config` | `{ "config": VosConfigJson }` — the raw stored config, params included |
+| `POST /api/vos` | create: `{ title, slug, visibility: "private", config, remixOfId? }` → `201 { vos: { id, … } }`; preview render auto-queues |
+| `POST /api/vos/{id}/versions` | iterate: `{ config, baseVersionId?, label?, note?, overrides? }` → `201 { version: { id, versionNumber } }`; stale base or protected nodes → 409 (see Errors) |
+| `GET /api/vos/{id}/changes?since={versionId}` | owner-only: the typed changelog after your base — attributed versions (origin/label/note), semantic `summary` + ops per version, and the `protected` human-edited node set |
+| `PATCH /api/vos/{id}` | `{ title \| config \| tags \| visibility: "private"\|"unlisted" }` |
+| `POST /api/claim` | **no auth** — the claimable push: `{ title, slug?, config }` → `201 { claimUrl, expiresAt, vos: { id } }`. Programs only, config ≤200KB, 5/24h per network. The claimUrl goes to the user and nowhere else; unclaimed work is deleted after 72h |
+
+Base URL `https://vos.so`. `slug` is `[a-z0-9-]`, unique per user, ≤50
+chars. `remixOfId` stamps the "remixed from" credit — always set it when
+the work started from someone's program.
+
+## Config rules (enforced server-side)
+
+- Function fields are JS **strings**: no TypeScript syntax; escape
+  backticks/`${}` that must survive into output.
+- `createContent` returns `{ objects, refs, dispose }`; `createTimeline`
+  reaches custom handles via `content.refs.<x>`.
+- Server-render constraints: no `THREE.DoubleSide` on transmission
+  materials, no `dispersion`, assets by absolute `https` URL only.
+- The platform compiles on every push — a push that 400s with a compile
+  error was going to render nothing; fix and re-push. `vos check` runs the
+  same compiler locally first.
+
+## Params and presets (preserved by contract)
+
+`config.params` (max 12 declared; curate 2–4) and `config.presets` (max 8,
+names ≤24 chars) survive every create/version/PATCH — the platform
+re-attaches them even though its schema strips unknown fields. Format and
+craft rules: `params-knobs.md`.
+
+## Hand-back
+
+Give the user both URLs every time:
+
+- watch: `https://vos.so/vos/{id}` — preview, knobs, the program
+- studio: `https://vos.so/studio?vos={id}` — live fine-tuning of your knobs
+
+## Errors
+
+| Status | Meaning | Do |
+| --- | --- | --- |
+| 400 | Invalid input / Failed to compile config | fix locally (`vos check`), re-push |
+| 401 | Invalid or revoked key | re-resolve credentials; ask the user |
+| 403 | missing `content` scope · cannot publish · grant off its source vos | respect the boundary; don't retry |
+| 409 | slug exists (on create) | pick another slug (the CLI retries derived slugs automatically) |
+| 409 | `stale_base` (on versions) | the platform copy moved since your base — the body EMBEDS the typed changes you missed; `vos pull`, re-apply, push with the fresh base |
+| 409 | `protected_conflict` (on versions) | your push touches nodes a studio version edited since your last push — keep the human's values, or include the listed ids in `overrides` ONLY when the user asked for that change |
+| 429 | 50/24h create quota, or grant's 5-push cap | iterate versions instead of creating; or wait |