pixelkiln 0.66.0 → 0.67.0

package/docs/CLI.md

@@ -344,6 +344,23 @@ Show one provider's remaining balance and cost unit. A mixed manifest requires
 `--provider`; a single-provider manifest infers it. Reports a capability error
 when an installed provider, such as local ComfyUI, has no balance endpoint.
 
+### `estimate-skeleton`
+
+```bash
+pixelkiln estimate-skeleton <image> [--out keypoints.json]
+```
+
+PixelLab only. Derives an 18-joint skeleton from an image via
+`/estimate-skeleton` and prints the keypoints JSON, or writes it with `--out`.
+Same category as `balance`: a direct, un-budgeted account call outside the
+manifest/plan/lock pipeline — no manifest is read beyond locating
+`.env.local`, and nothing is written to a lockfile. This is how to bootstrap
+an `animate-skeleton` revision's `keypointsFile` (see
+[Controlled asset revisions](./REVISIONS.md#skeleton-driven-animation)):
+estimate once, sanity-check the result, hand-tweak a few joints for
+in-between frames, rather than hand-authoring 18 joints of
+`{label, x, y, z_index}` from scratch.
+
 ### `status`
 
 Summarize lock entries by state and successful submission spend by cost unit.

package/docs/MANIFEST.md

@@ -468,7 +468,7 @@ their own page: [Characters](./CHARACTERS.md) and
 
 | Revision field | Type | Meaning |
 |---|---|---|
-| `mode` | enum, required | `image-to-image`, `inpaint`, `outpaint`, `reduce-colors`, `correct-pixelart`, `animate`, `animate-pixminimax`, `interpolate`, or `edit-animation`. The selected provider must opt into the mode. |
+| `mode` | enum, required | `image-to-image`, `inpaint`, `outpaint`, `reduce-colors`, `correct-pixelart`, `animate`, `animate-pixminimax`, `animate-skeleton`, `interpolate`, or `edit-animation`. The selected provider must opt into the mode. |
 | `from` | asset id, required | Parent asset in the same style. Self-references, unknown ids, and cycles are rejected. A parent written as a set (a character's directions, an animation's frames) is read as every member: `reduce-colors`, `correct-pixelart`, and `edit-animation` take the whole set in one call; the other modes refuse it. See [Revising a whole set at once](./REVISIONS.md#revising-a-whole-set-at-once). |
 | `mask` | string | Manifest-relative PNG required for `inpaint`; rejected for the other modes. Its dimensions must match an available source. |
 | `strength` | number 0–1 | Workflow edit/denoise strength (`image-to-image`, `correct-pixelart`); rejected for `reduce-colors`, `animate`, `animate-pixminimax`, `interpolate`, and `edit-animation`. Interpretation is provider- and model-specific. |
@@ -476,11 +476,14 @@ their own page: [Characters](./CHARACTERS.md) and
 | `paletteImage` | string | `reduce-colors` only. Manifest-relative image whose colors become the palette; unlike `mask`, no size relationship to the source is required. |
 | `dithering` | enum | `reduce-colors` only. `none` (default), `2x2`, `4x4`, or `8x8`. |
 | `ditheringStrength` | number 0–10 | `reduce-colors` only. Ignored when `dithering` is `none`. |
-| `frames` | integer 4–40, even | `animate`/`animate-pixminimax` only. `animate` caps at 16; `animate-pixminimax` allows up to 40. |
+| `frames` | integer 4–40, even | `animate`/`animate-pixminimax` only. `animate` caps at 16; `animate-pixminimax` allows up to 40. Rejected for `animate-skeleton` (frame count comes from `keypointsFile` instead), `interpolate`, and `edit-animation`. |
 | `fps` | integer 1–60 | `animate`/`animate-pixminimax`/`interpolate`/`edit-animation` only. Playback rate recorded with the frames; the provider does not store one. Defaults to the parent's own rate when it is a loop, else 8. |
 | `lastFrame` | string | `animate`/`animate-pixminimax`: manifest-relative image pinning where the motion ends, turning an open-ended animation into an interpolation. `interpolate`: required, the ending keyframe (the parent is the start); it must match the parent's size. |
-| `direction` | enum | `animate-pixminimax` only. The sprite's facing, used only alongside `enhancePrompt`. |
+| `direction` | enum | `animate-pixminimax`/`animate-skeleton`. Optional (alongside `enhancePrompt`) for the former; **required** for the latter. |
 | `enhancePrompt` | boolean | `animate`/`animate-pixminimax` only. Lets the provider expand the prompt into a fuller motion description first, for an extra documented +0.05-generation surcharge. |
+| `keypointsFile` | string, required for `animate-skeleton` | Manifest-relative JSON file (`src/skeleton.ts`'s `SkeletonSetSchema`): the pose the source is already in, plus 3–15 per-frame poses. See [Skeleton-driven animation](./REVISIONS.md#skeleton-driven-animation). |
+| `skeletonTemplate` | string | `animate-skeleton` only. Body a joint's missing `depth` is taken from: `mannequin` (default), `bear`, `cat`, `dog`, `horse`, or `lion`. |
+| `description` | string | `animate-skeleton` only. What the subject *looks like* (colours, clothing, held items) — the asset's own `prompt` is sent as the motion's short label instead. |
 | `engine` | enum | `image-to-image`/`inpaint` only. `pro-flash` draws the edit with PixelLab's Pro Flash edit or inpaint endpoint instead of the default Pro one: 5–9 generations instead of 20–40, 32 to 256px per side in multiples of 4, no `strength`. Omit for the default. |
 
 The parent may use committed `source`, downloaded generated output, or a

package/docs/PIXELLAB.md

@@ -156,20 +156,21 @@ comparing notes with someone using a different one:
 
 ## What is outside this adapter
 
-PixelLab offers more than PixelKiln currently exposes. Lip-sync and
-skeleton-driven animation are not part of this adapter. Characters, their
-states, their animations, their portraits, and outfit transfer onto their
-loops are the `character` generator, with all four creation engines
-(standard, v3, pro, pro-flash),
-reference sprites, concept images, style anchors, mirrors, and every
-`animate-character` control; see [Characters](./CHARACTERS.md). Masked
-inpainting and whole-image editing are the `revision` asset shape, not the
-`character` generator; see [Controlled asset revisions](./REVISIONS.md).
-The same revision shape animates, interpolates, recolors, and cleans up any
-asset, a whole character or loop at once where the endpoint takes a set.
-Object Creator is the `objectPro` generator, UI panels and elements are
-`uiAsset` and `uiElement`, and fonts and unzooming reference art are the
-standalone `pixelkiln font` and `pixelkiln unzoom` commands. Map Workshop
+PixelLab offers more than PixelKiln currently exposes. Lip-sync and vocal
+animation are not part of this adapter. Characters, their states, their
+animations, their portraits, and outfit transfer onto their loops are the
+`character` generator, with all four creation engines (standard, v3, pro,
+pro-flash), reference sprites, concept images, style anchors, mirrors, and
+every `animate-character` control; see [Characters](./CHARACTERS.md). Masked
+inpainting, whole-image editing, and skeleton-driven animation (posing a
+reference image frame-by-frame from a supplied keypoint skeleton, not a text
+description) are the `revision` asset shape, not the `character` generator;
+see [Controlled asset revisions](./REVISIONS.md). The same revision shape
+animates, interpolates, recolors, and cleans up any asset, a whole character
+or loop at once where the endpoint takes a set. Object Creator is the
+`objectPro` generator, UI panels and elements are `uiAsset` and `uiElement`,
+and fonts and unzooming reference art are the standalone `pixelkiln font` and
+`pixelkiln unzoom` commands. Map Workshop
 scene composition (placing objects and characters into a map, in-scene
 inpainting, export) is a separate PixelLab product surface this adapter does
 not model at all — including PixelKiln's own `map` generator, which is

package/docs/REVISIONS.md

@@ -7,11 +7,12 @@ dependencies before submission, and records the lineage in the lockfile.
 
 The manifest and pipeline are provider-neutral. ComfyUI and PixelLab implement
 it; PixelLab covers `image-to-image`, `inpaint`, `reduce-colors`,
-`correct-pixelart`, `animate`, `animate-pixminimax`, `interpolate`, and
-`edit-animation`, not `outpaint` (its API has no canvas-expansion endpoint).
-ComfyUI covers every mode generically except the four frame-set modes
-(`animate`, `animate-pixminimax`, `interpolate`, `edit-animation`), which need
-an ordered frame set its revision path cannot produce. Retro Diffusion and Scenario reject revision
+`correct-pixelart`, `animate`, `animate-pixminimax`, `animate-skeleton`,
+`interpolate`, and `edit-animation`, not `outpaint` (its API has no
+canvas-expansion endpoint). ComfyUI covers every mode generically except the
+five frame-set modes (`animate`, `animate-pixminimax`, `animate-skeleton`,
+`interpolate`, `edit-animation`), which need an ordered frame set its
+revision path cannot produce. Retro Diffusion and Scenario reject revision
 work during offline resolution instead of silently starting a fresh
 text-to-image job.
 
@@ -316,6 +317,81 @@ writes a single output image, and an animation is a frame set — a structural
 gap rather than a missing binding, so `supportsRevision` refuses it up front
 rather than failing partway through submission.
 
+## Skeleton-driven animation
+
+A third mode, `animate-skeleton`, poses the source image frame-by-frame from
+a supplied 18-joint skeleton per frame instead of a text motion description:
+
+```jsonc
+{
+  "assets": {
+    "hero-swing": {
+      "prompt": "swinging the sword downward",
+      "revision": {
+        "mode": "animate-skeleton",
+        "from": "hero-idle",
+        "keypointsFile": "poses/hero-swing.json",
+        "direction": "south"
+      }
+    }
+  }
+}
+```
+
+`keypointsFile` names a manifest-relative committed JSON file, not inline
+manifest data — the same reasoning `mask`/`lastFrame` are files rather than
+inline pixels. It must match the shape `src/skeleton.ts`'s `SkeletonSetSchema`
+validates: `{"firstFrameKeypoints": [...18 joints], "frames": [[...18
+joints], ...3 to 15 of them]}`, each joint `{"label": "RIGHT KNEE", "x": 0.52,
+"y": 0.71, "z_index": 9, "depth": 4}` (`depth` optional — PixelLab fills it
+from `skeletonTemplate`, default `mannequin`, when omitted). Bootstrap this
+file with `pixelkiln estimate-skeleton <image> --out poses/hero-swing.json`
+(see [CLI reference](./CLI.md#estimate-skeleton)) rather than hand-typing 18
+joints from scratch, then hand-tweak individual joints for in-between frames.
+
+`direction` is **required** for this mode (unlike `animate-pixminimax`,
+where it is optional). `frames`/`fps`/`lastFrame`/`enhancePrompt` are all
+rejected — the frame count comes from the keypoints file itself
+(`frames.length`), never a manifest number. `description` (optional: what the
+character *looks like* — colours, clothing, held items) is a new field
+distinct from the asset's own `prompt`, which this mode sends as the motion's
+short label (PixelLab's `action`) — the same `prompt`-as-motion convention
+`animate`/`animate-pixminimax` already use, just under this endpoint's own
+field name.
+
+`firstFrameKeypoints` (inside the keypoints file) describes the pose the
+reference image is *already* in — PixelLab redraws that frame first to learn
+its background and colors before animating forward, and does not return it.
+**PixelKiln cannot verify this against the image's actual content.** A
+mismatch does not error; it silently degrades transparency and color
+accuracy in every generated frame. When in doubt, run `estimate-skeleton` on
+the reference image itself and use that result, rather than hand-authoring
+a guess.
+
+**Deliberately not wired into the manifest pipeline: `estimate-skeleton`
+itself.** `PixelLabClient.estimateSkeleton()` exists and the CLI command above
+calls it directly, but nothing in `resolveSpecs`/`estimate()`/`submitRevision`
+ever calls it — planning stays offline by construction (the keypoints file is
+read like any other manifest input, never a network call), and the only
+PixelLab endpoint `animate-skeleton`'s submission composes is
+`animate-with-skeleton-v3` itself, not two never-tested-live calls chained
+together. A future pipeline stage that budgets and tracks `estimate-skeleton`
+calls the way `gen` does everything else is tracked separately, once this
+mode has shipped and seen real use.
+
+Cost uses PixelLab's own documented anchors (3 frames = 2 generations, 8 = 3,
+15 = 4 — barely moving with length, unlike `animate`/`animate-pixminimax`'s
+canvas-area formula) and interpolates between the nearest two for any
+in-between frame count, ceiling'd — the safe direction for `--budget` — since
+no in-between value is confirmed live. **Neither `animate-with-skeleton-v3`
+nor `estimate-skeleton` has been exercised against a live account**; request
+field names come from the live `animate_with_skeleton_v3` MCP tool schema
+(the same authoritative source already trusted for the character/object
+family), not an observed call.
+
+ComfyUI does not support this mode either, for the same structural reason as
+`animate`/`animate-pixminimax`.
+
 ## Dependency gate
 
 `pixelkiln plan` reports a revision as `blocked` when its parent is not safe to
@@ -464,6 +540,14 @@ further — there is nothing to ask.
   request/response shapes come from PixelLab's live OpenAPI document, not an
   observed call. Treat the exact field names as provisional until a real
   call confirms them.
+- `animate-skeleton` calls `/animate-with-skeleton-v3`, also a real async
+  background job, at most 256 pixels per side and 3-15 frames (the frame
+  count comes from `keypointsFile`, not a manifest field). See
+  [Skeleton-driven animation](#skeleton-driven-animation) above for the full
+  field list, the `keypointsFile` shape, and the `estimateSkeleton`
+  CLI-only-and-never-in-the-submission-path decision. Same unverified-live
+  caveat as `animate`/`animate-pixminimax`, sourced from the live
+  `animate_with_skeleton_v3` MCP tool schema rather than an observed call.
 
 - The mask convention is fixed, not graph-defined like ComfyUI's: white marks
   the area to generate, black the area to preserve. There is no way to flip it.
@@ -535,16 +619,20 @@ hash, strength, and — for `reduce-colors` — `numColors`, the palette image's
 hash, and the dithering settings, or — for `animate`/`animate-pixminimax` —
 `frames`, `fps`, the last frame's hash, `direction`, and `enhancePrompt`
 (`interpolate` records `fps` and the end keyframe's hash; `edit-animation`
-records `fps`). For a set parent, the parent hash is one hash over every
-member's hash in order.
+records `fps`), or — for `animate-skeleton` — the keypoints file's hash,
+`skeletonTemplate`, and `description` (`direction` is recorded the same way;
+`frames` comes from the keypoints file itself, same field, same staleness
+rule as the others). For a set parent, the parent hash is one hash over
+every member's hash in order.
 ComfyUI provider metadata also retains the same lineage beside the workflow
 hash.
 
 Changing the prompt, workflow, mode, strength, parent bytes, mask bytes, color
 count, palette image bytes, dithering settings, frame count, last frame
-bytes, direction, or enhancePrompt makes the child stale. Moving an unchanged
-parent, mask, palette image, or last frame file does not. When a child
-has a quality profile, the new raw output hash also invalidates its old quality
+bytes, direction, enhancePrompt, keypoints file bytes, skeletonTemplate, or
+description makes the child stale. Moving an unchanged parent, mask, palette
+image, last frame file, or keypoints file does not. When a child has a
+quality profile, the new raw output hash also invalidates its old quality
 record, so a revised image cannot inherit approval from an earlier generation.
 
 Commit the parent art or parent lock entry, masks, child output, child lock

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "pixelkiln",
-  "version": "0.66.0",
+  "version": "0.67.0",
   "description": "Manifest-driven pixel-art generation, review, recovery, and packaging with deterministic provenance.",
   "type": "module",
   "sideEffects": false,

package/schema/manifest.schema.json

@@ -1012,6 +1012,7 @@
                       "correct-pixelart",
                       "animate",
                       "animate-pixminimax",
+                      "animate-skeleton",
                       "interpolate",
                       "edit-animation"
                     ]
@@ -1082,6 +1083,18 @@
                   "enhancePrompt": {
                     "type": "boolean"
                   },
+                  "keypointsFile": {
+                    "type": "string",
+                    "minLength": 1
+                  },
+                  "skeletonTemplate": {
+                    "type": "string",
+                    "minLength": 1
+                  },
+                  "description": {
+                    "type": "string",
+                    "minLength": 1
+                  },
                   "engine": {
                     "type": "string",
                     "enum": [

package/skills/pixelkiln/references/pixellab-roadmap.md

@@ -246,6 +246,28 @@ which tutorial(s) demonstrated real (not hypothetical) demand for it.
   actually describe `uiAsset`'s pricing. Left unpatched from one data point:
   over-reading stays the safe `--budget` direction, but a real call likely
   costs about half of what `pixelkiln plan` prints, pending a second size.
+- **Skeleton-driven animation** (`POST /animate-with-skeleton-v3`, beta,
+  tier 1+ subscription — pose a reference image frame-by-frame from a
+  supplied 18-joint skeleton per frame, instead of a text motion
+  description) — closed by the `revision` asset shape's `animate-skeleton`
+  mode; see `pixellab.md` and `docs/REVISIONS.md#skeleton-driven-animation`.
+  `POST /estimate-skeleton` (auto-derive a reference image's own keypoints)
+  is wrapped too, but deliberately kept outside the manifest pipeline — a
+  standalone `pixelkiln estimate-skeleton` CLI command, not a
+  `resolveSpecs`/`estimate()`-time call — so `animate-skeleton`'s submission
+  composes exactly one never-tested-live PixelLab endpoint, not two chained
+  together. **Correcting this catalog's own prior research**: this entry
+  used to also claim a distinct "animation to animation" endpoint existed,
+  for transferring an existing walk cycle's motion onto a different
+  character. Checked against the live `animate_with_skeleton_v3` MCP tool
+  schema: **there is no such endpoint.** The real composition is
+  `estimate-skeleton` run once per frame of a source animation, then
+  `animate-with-skeleton-v3` against a *different* reference image reusing
+  those keypoints — a two-endpoint composition a person can now build by
+  hand with the primitives above, not a primitive pixelkiln itself
+  automates. Neither `animate-with-skeleton-v3` nor `estimate-skeleton` has
+  been exercised against a live account; request field names come from the
+  MCP tool schema, not an observed call.
 
 - **Fonts** (`/generate-font-pro`, an 80-glyph atlas plus a `.ttf` from a
   style description) — no tutorial demonstrated it in depth, so demand is
@@ -367,22 +389,23 @@ native Godot 4 `TileSet` resource directly, verified in CI — worth knowing if
 Map Workshop parity is ever considered, since the export leg is arguably
 already solved better here than in PixelLab's own reference flow.
 
-## Skeleton-driven animation and animation-to-animation motion transfer
-
-Two more animation mechanisms with no equivalent: **"Animate with skeleton"**
-(fit a rig template — bipedal, realistic, chibi, or quadruped body plans —
-generate two frames at a time with each accepted pair becoming context for
-the next, height/head-size/offset controls) and **"Animation to animation"**
-(transfer the motion/shape structure of an *existing* walk cycle onto a
-newly described or referenced character, frame budget capped by the source's
-canvas size). Both demonstrated in "How to Make Walking Animations for Pixel
-Art Characters in PixelLab." Neither exists in pixelkiln's `character`
-schema, which only knows named templates, v3 text loops, and pro loops — none
-take a user-supplied motion source or expose a skeleton-editing surface.
-Already flagged as explicitly out of scope in docs/PIXELLAB.md
-("skeleton-driven animation"); animation-to-animation is new information not
-previously catalogued anywhere.
+## Animation-to-animation motion transfer
 
+Transferring the motion of an *existing* walk cycle onto a newly described or
+referenced character — demonstrated in "How to Make Walking Animations for
+Pixel Art Characters in PixelLab." As corrected in the now-closed
+skeleton-driven-animation entry above: this is not one endpoint, it is
+`estimate-skeleton` run per frame of the source animation plus
+`animate-with-skeleton-v3` against the new character's reference image
+reusing those keypoints. Both primitives exist in this adapter now
+(`animate-skeleton` revision mode, `pixelkiln estimate-skeleton`), so a
+person can build this by hand today — chaining `estimate-skeleton` calls
+across a source animation's frames into one keypoints file, then pointing an
+`animate-skeleton` revision's `from` at a different character. What remains
+a real gap is automating that chain as its own pixelkiln capability (one
+command, not N manual `estimate-skeleton` calls plus hand-assembling the
+result into a `SkeletonSetSchema` file) — worth scoping once the base
+`animate-skeleton` mode has shipped and seen real use.
 
 ## Not PixelLab gaps at all — different products, no action implied
 

package/skills/pixelkiln/references/pixellab.md

@@ -388,28 +388,43 @@ contained a generated signature-like glyph.
 An asset that declares `revision` against a PixelLab style calls `inpaint`
 (masked), `image-to-image` (whole-image, no mask), `reduce-colors`
 (palette quantize, `/reduce-colors`), `correct-pixelart` (edge/noise
-cleanup, `/correct-pixelart`), `animate` (`/animate-with-text-v3`), or
+cleanup, `/correct-pixelart`), `animate` (`/animate-with-text-v3`),
 `animate-pixminimax` (`/animate-pixminimax`, beta, tier 1 subscription or
-higher), `interpolate` (`/interpolation-v2`, in-betweens from the parent to
-a required `lastFrame` keyframe), or `edit-animation` (`/edit-animation-v2`,
-one edit across a whole frame set); `outpaint` is refused, since PixelLab has no canvas-expansion
-endpoint. `reduce-colors`/`correct-pixelart` send no prompt to PixelLab at
-all — they are mechanical, not described — and complete synchronously with
-no background job, unlike every other PixelLab call this adapter makes.
-`animate`/`animate-pixminimax` DO send the asset's own prompt, as the motion
-description, and produce an ordered **frame set** landing in candidate
+higher), `animate-skeleton` (`/animate-with-skeleton-v3`, also beta/tier
+1+ — poses the source frame-by-frame from a supplied 18-joint skeleton per
+frame, via a committed `keypointsFile` rather than a text motion
+description), `interpolate` (`/interpolation-v2`, in-betweens from the parent
+to a required `lastFrame` keyframe), or `edit-animation` (`/edit-animation-v2`,
+one edit across a whole frame set); `outpaint` is refused, since PixelLab has
+no canvas-expansion endpoint. `reduce-colors`/`correct-pixelart` send no
+prompt to PixelLab at all — they are mechanical, not described — and complete
+synchronously with no background job, unlike every other PixelLab call this
+adapter makes. `animate`/`animate-pixminimax`/`animate-skeleton` DO send the
+asset's own prompt, as the motion description (`animate-skeleton` calls it
+`action`, alongside a separate optional `description` field for appearance —
+the skeleton carries the motion, the text only names it and what the subject
+looks like), and produce an ordered **frame set** landing in candidate
 review, not a single image — the one revision mode shape that isn't "one
-image in, one image out." Neither animate endpoint's completed-job response
-shape has ever been observed; `pollAnimateRevision` guesses defensively
-rather than assume one. Read `docs/REVISIONS.md`'s PixelLab section before
-using any of these. A parent written as a set (a character's directions, an
-animation's frames) goes to `reduce-colors`, `correct-pixelart`, and
-`edit-animation` whole, in one call, so every member shares one palette or
-edit; the other modes refuse a set parent. `reduce-colors`/`correct-pixelart` cost is **confirmed
-live**: a flat 0.1 generations each (not the schema's dollar-denominated
-example), at least at a 32×32 source — `animate`/`animate-pixminimax` remain
-schema-only and unexercised, taken from PixelLab's live OpenAPI document
-rather than an observed call.
+image in, one image out." None of the animate/interpolate/edit-animation
+endpoints' completed-job response shape has ever been observed;
+`pollAnimateRevision` guesses defensively rather than assume one. Read
+`docs/REVISIONS.md`'s PixelLab section before using any of these. A parent
+written as a set (a character's directions, an animation's frames) goes to
+`reduce-colors`, `correct-pixelart`, and `edit-animation` whole, in one call,
+so every member shares one palette or edit; the other modes refuse a set
+parent. `reduce-colors`/`correct-pixelart` cost is **confirmed live**: a flat
+0.1 generations each (not the schema's dollar-denominated example), at least
+at a 32×32 source — `animate`/`animate-pixminimax`/`animate-skeleton`/
+`interpolate`/`edit-animation` remain schema-only and unexercised.
+`animate-skeleton`'s request field names come from the live
+`animate_with_skeleton_v3` MCP tool schema, a more authoritative source than
+the OpenAPI document the others are taken from, but still not an observed
+call. `estimate-skeleton` (auto-derive a reference image's own keypoints) is
+wrapped too, but deliberately as a standalone `pixelkiln estimate-skeleton`
+CLI command, never inside `submitRevision` — see
+[pixellab-roadmap.md](./pixellab-roadmap.md)'s now-closed skeleton-driven-
+animation entry for why composing two never-tested-live endpoints in one
+submission was rejected.
 
 `animate-pixminimax`'s `direction` + `enhancePrompt` combination has a
 measured-in-practice gotcha, not just a schema quirk: PixelLab's own tutorial