pixelkiln 0.92.0 → 0.92.1

package/docs/GENERATORS.md

@@ -721,8 +721,11 @@ is what PixelLab enforces.
 A style whose `palette` was already set keeps its hash, so `plan` does not
 call it stale, but regenerating it will now send that palette on the routes
 above (it was already true for `imagePro`). **Costs are unchanged by
-PixelLab's documentation and unmeasured here**, except `imagePro` (a 64×64
-call billed exactly 10 with a palette); the rollout was tested against mocked
+PixelLab's documentation**, and two more routes are now measured with a
+palette: `imagePro` (a 64×64 call billed exactly 10), `imageProFlash` (a
+32×32 still billed exactly 5, in only the four palette colours) and `tiles`
+(one numbered description, 4 tiles at 16px, billed exactly 10, every
+candidate in the palette's greens). The other routes are tested against mocked
 requests only. `maxColors` without a `palette` on a multi-direction asset
 caps each direction separately, so the directions may pick different colours;
 give `colors` for those. Not done: `/create-character-v3` and the 4-direction

package/docs/PIXELLAB.md

@@ -183,8 +183,9 @@ states, portraits and outfits), Pro `terrain`, and the `interpolate` and
 `edit-animation` revisions send a style's `palette`, `paletteName` and
 `maxColors` as `target_palette`. Standard characters and every character
 animation keep their `color_image` swatch, and `pixflux` keeps its own. Costs
-with a palette are unverified outside `imagePro` (PixelLab quotes none), and
-this rollout is covered by mocked tests only, not a live generation.
+with a palette are measured for `imagePro` (10), `imageProFlash` (a 32×32
+still, 5, in only the four palette colours), and `tiles` (4 tiles at 16px,
+10), and unverified elsewhere. The other routes are covered by mocked tests only.
 
 ## Learn from PixelLab's tutorials
 

package/package.json

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

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

@@ -408,7 +408,7 @@ and which tutorial(s) demonstrated real (not hypothetical) demand for it.
   revisions, through one helper (`targetPaletteBody`). `paletteName` and
   `maxColors` are style fields on those generators, hashed only when set; an
   existing style `palette` keeps its hash and is simply sent on regeneration.
-  **Mocked tests only, costs unmeasured** outside `imagePro`. **Not done**:
+  **Measured live** with a Game Boy palette: `imageProFlash` (a 32×32 still, 5, only the four colours) and `tiles` (4 tiles at 16px, 10, every candidate in the palette), matching the plan, as `imagePro` did (10). **The other routes are mocked tests only, costs unmeasured.** **Not done**:
   standard character bases and every character animation (their verified
   `color_image` + `force_colors` swatch stays, and the schema does not say it
   combines), the standard terrain set (the field is "mode='pro' only"), the

package/skills/pixelkiln/references/pixellab.md

@@ -215,7 +215,7 @@ characters (bases, states, portraits, outfits), top-down Pro `terrain`, and
 `interpolate`/`edit-animation` revisions, with `paletteName`/`maxColors`
 accepted on those generators' styles. Standard characters and character
 animations keep their `color_image` swatch, `pixflux` its own, and the
-costs are unmeasured outside `imagePro` (see `docs/GENERATORS.md#target-palette`).
+costs with a palette are measured for `imagePro`, `imageProFlash`, and `tiles`, and unmeasured elsewhere (see `docs/GENERATORS.md#target-palette`).
 PixelLab's `smart` palette
 mapping is not wrapped: it is "single images only", and this endpoint
 returns a grid of candidates below 171px. Reference