pixelkiln 0.89.3 → 0.89.4

package/docs/CHARACTERS.md

@@ -209,6 +209,15 @@ higher, and it is sent to `/characters/animations`, the endpoint that
 documents it; every other mode keeps using `/animate-character`. Like a
 template loop it takes no `frames` and needs no prompt of its own.
 
+It needs a character PixelLab stored a 3D skeleton for. A `v3` base has
+one (a `skeleton-v3` loop on it billed 3 generations live). A `standard`
+base has none: PixelLab answers `POST /characters/animations` with a bare
+500 (`Failed to start any animation jobs`, nothing billed) and, asked,
+says to use `mode: "template"` for that character. `plan` and `validate`
+refuse the combination and name the engine. `pro` and `pro-flash` bases
+are not refused, but a `skeleton-v3` loop on one is unverified; try a
+single direction before a batch.
+
 ```jsonc
 "mira.walk": { "animation": { "of": "mira", "template": "walk", "mode": "skeleton-v3", "directions": ["south", "west", "north"] } }
 ```

package/docs/ENDPOINTS.md

@@ -781,6 +781,14 @@ one size; the higher cost tiers are still unconfirmed under
   carries `usage` once the job is gone, completed or not. `poll` reads the
   object/character for the result but would need this same job id, still
   polled separately today, to learn what it actually cost.
+- **A v3 character base once recorded `billed: {amount: 0, unit: "usd"}`**
+  against an estimate of 2 generations while the submit reported 1
+  generation consumed. Its job record had expired before the shape could be
+  read (jobs are deleted 8 hours after finishing, and the lock had dropped
+  the job id), so the real `usage` is unseen; `GET /characters/{id}` carries
+  none. `poll` now treats a dollar-denominated zero as not known, tries
+  `last_response.billing_usage`, and keeps `backgroundJobId` in the
+  character's lock metadata.
 - **`inpaint-v3` and `edit-images-v2` both confirmed live at their floor
   size**: a 32×32 masked inpaint and a separate 32×32 whole-image edit each
   billed exactly 20 generations, both matching a balance diff taken after.

package/docs/PIXELLAB.md

@@ -125,8 +125,8 @@ Each has been billed live and matched the plan: Pro sets at 32px (15) and
 64px (25, 25 tiles at transition 0.5), a second set connected to the first
 (15), standard sets (3 each), a sidescroller set (3), a 64×64 `imagePro`
 call with the Game Boy palette (10, every pixel one of its four colours), a
-lite described effect (1), and normal maps (0.5 each). The home page shows
-the results.
+lite described effect (1), and normal maps (0.5 each). The home page's latest
+updates section shows the results.
 
 ## Learn from PixelLab's tutorials
 

package/package.json

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

package/skills/pixelkiln/references/pixellab.md

@@ -388,7 +388,11 @@ character with PixelLab's skeleton video model instead of redrawing each
 frame: the steadiest template loop, 2 to 4 generations and 3 to 5 minutes
 per direction (plan budgets 4), beta, Tier 1 plans and up. Prefer it over a
 plain template loop when identity drift matters and the account qualifies;
-plain `template` stays the 1-generation option.
+plain `template` stays the 1-generation option. It needs a base with a
+stored 3D skeleton: a `v3` base has one (measured, 3 generations); a
+`standard` base has none, so PixelLab answers a bare 500 and pixelkiln
+refuses the loop at `plan`/`validate`, pointing at `mode: "template"`. `pro`
+and `pro-flash` bases are not refused but are unverified.
 
 A named `template` loop (`walk`, `breathing-idle`, and similar) is trained
 mostly on characters with empty hands, and reliably struggles once a