Advisory 04 — four findings from the 2026-08-19 manifest
To: docade · From: WootBuild · Date: 2026-08-19 Status: open — docade decides Trigger: ingesting assets/ART-BRIEF.md, assets/asset-list.csv and assets/manifest.json as regenerated 2026-08-19. Catalogue moved 246 → 336.
Everything below is a recommendation. Nothing here has been changed in your repo; WootBuild reads it read-only.
1. The rarity contradiction is still there, and it is now expensive
Fourteen pieces where your own manifest disagrees with itself. The brief text says RARE or LEGENDARY; the Rarity column on the same row says common.
sunbaked/jackalope · sunbaked/thunderbird · frostline/narwhal · frostline/ice-mammoth · meadow/butterfly-rhino · meadow/dandelion-lion · cloudbank/thunder-ram · cloudbank/halcyon · canopy/orchid-mantis · canopy/jaguar-macaw · stonepeak/crystal-ibex · stonepeak/griffin · emberfall/ember-lynx · emberfall/phoenix
This was raised on 2026-08-17 and the regenerated manifest has not changed it. What has changed is that it now has a cost. WootBuild takes the brief text — a person wrote that sentence, and a blank-looking column is the likelier mistake — so twelve of those fourteen have been produced as rare or legendary. They carry a second signal colour and a more ambitious silhouette, because 14-ASSET-MANIFEST.md principle 5 says rarity must read without a label.
If your database is populated from the column, you will ship legendary artwork attached to rows the product believes are common. The art will look wrong for a reason nobody can see in the art.
Ask: confirm the brief text is right and fix the column, or tell us the column is right and we will re-run those twelve as commons. Cheap either way (~$0.07 a piece) and much cheaper now than after they are in a player's collection.
2. arcade cannot be produced as one lane
Twenty-one pieces at four different sizes: eleven at 128px, five at 256px, four at 1024px, one at 24px.
A WootBuild lane is a production method and a spec — one style contract, one output size, one QA rule. arcade has been left configured but explicitly marked do-not-produce, rather than given a spec that would be wrong for seventeen of its twenty-one pieces. It is Phase 3 and unstarted, so nothing is blocked today.
Your manifest already carries a per-piece size, so this is solvable from either end:
- You normalise — if the 128s and 256s are the same artwork at two resolutions, they are one piece with derived sizes, not two pieces.
- We add per-piece specs — the data is there; this is a WootBuild capability gap, not a fault in your manifest.
Ask: are the 128/256 pairs genuinely different artwork, or the same art delivered twice?
3. room-treatments would have shipped at half size
Your manifest puts room treatments at 1024px. They were inside our world lane, which declares 512. Twenty-four pieces would have been produced at half their delivered size, and nothing would have complained until someone opened one on a phone.
Fixed on our side — room is now its own lane at 1024. No action needed; recorded because it is the kind of error that only surfaces at delivery, and because it grew 6 → 24 in this manifest, which is what made it worth catching.
4. Seven furniture keys were dropped
clock · plant · poster · side-table · string-lights · toybox · window are in our previous snapshot and not in the new one, while furniture grew 12 → 65.
Nothing was lost — none had been produced. Recorded only so that if their removal was accidental rather than a restructure, you find out now rather than when a room renders with a gap in it.
And one answer you are owed
Q44 — how a colourway is produced — is settled, and it was settled by measurement, not opinion.
A recolour is a deterministic offline attribute edit: $0.08 once for a flat vector plate, $0.00 per colourway, then $0.0675 per render. It works only because the fills are flat and separable, which is your principle 3 demonstrated rather than asserted.
That bears directly on your Q25 note — "each COLORWAY is its own collection entry, so the shipped entry count is this number times the colorways per sculpt — which is NOT yet decided (Q44)". The economics are no longer the constraint. Sixty sculpts at three colourways each is 180 entries for the cost of sixty renders plus a script. Decide the number on game design, not on budget.
What WootBuild changed on its own side
Read-only against your repo, as always.
| Manifest snapshot | 246 → 336 pieces, all 22 categories |
| Lanes | 10 → 14. world split into world (furniture, 512), room (1024) and arcade (do-not-produce); category-icons folded into glyph; new milestone and social lanes |
| Coverage | 336 of 336 pieces are in a lane |
| Identity | Your approved package is held at clients/docade/identity/ so our console can render your mark. Copy, never a source — regenerate yours and we re-copy |
Untouched: the 60 stuffies keys are byte-identical to your new manifest, so the 20 approved and 40 awaiting a verdict are unaffected. That was checked at key level before anything else was changed.
Addendum, same day — 12 pieces whose size no single spec can express
Found by art intake docade, which diffs your manifest rather than overwriting our copy of it. This one is ours, and the fix is already in.
WootBuild read your Size (px) column with Number(). Twelve of your rows legitimately carry something else — vector, per-device, varies, 600w, 1200x630, 1024x500, device — and every one of those became NaN, which JSON writes as null. Twelve declared sizes were being discarded in silence. The snapshot now keeps what you actually wrote, always.
| your size | why it matters | |
|---|---|---|
identity/og-image | 1200x630 | would have been produced square |
store-listing/play-feature-graphic | 1024x500 | same |
identity/splash-portrait · 5 store shots | per-device / device | one artwork, many device frames |
identity/wordmark · -mono | vector | SVG, not a raster size |
identity/email-header | 600w | width-constrained, height free |
system-states/state-loading | varies | animation frames |
This is the same shape as finding 3 above — room-treatments at half size — and it is the second time in one ingest that a size would have been wrong at delivery and correct nowhere earlier. No action from you is required. What would help, when convenient: confirm the five device rows are one artwork rendered into several frames rather than several artworks. That is the same question as finding 2's 128/256 pairs, and one answer settles both.
Addendum 2 — finding 1 has a root cause, and it is eight lines
You do not have a data problem. You have a lookup table that stopped at set 3.
scripts/asset-csv.mjs derives the Rarity column from a hardcoded map:
const RARITY = {
'forest/deer': 'rare', 'forest/stag': 'legendary',
'deepsea/octopus': 'rare', 'deepsea/whale': 'legendary',
'nightsky/owl-moon': 'rare','nightsky/dragon': 'legendary',
}
...
const rarity = isStuffy ? (RARITY[key] ?? 'common') : ''
Six entries, covering Forest Friends, Deep Sea and Night Sky. The seven sets added on 2026-08-18 — Sunbaked Flats, Frostline, Wildflower Meadow, Cloudbank, Canopy, Stonepeak, Emberfall — are not in it, so every one of their rare and legendary pieces falls through to common.
Seven sets × (1 rare + 1 legendary) = 14. That is exactly the fourteen, and the arithmetic is checkable: zero of the conflicts are in the three sets the map covers, and all fourteen are in the seven it does not.
So finding 1 above is not a question about which source to trust. Your manifest.json subjects[key].what already says RARE and LEGENDARY for all fourteen, and it is right. The column is a stale copy of information the manifest already holds.
The fix is to stop keeping it twice. Derive rarity from the text rather than from a second list that has to be remembered:
const rarity = isStuffy
? (/\bLEGENDARY\b/.test(subject.what) ? 'legendary'
: /\bRARE\b/.test(subject.what) ? 'rare' : 'common')
: ''
That is what WootBuild already does when it reads your CSV (lib/manifest.mjs), which is why the twelve were produced correctly. It was a workaround on our side; this makes it unnecessary on both.
This supersedes the ask in finding 1. Nothing needs re-running and no decision is owed — the brief text was right, the column was derived from a list that was never extended, and one regex retires the list. Extending RARITY by hand would work too, and would break again at set 11.
Correction, same day — §2's question was based on a premise nobody checked
There are no 128/256 pairs. §2 asked whether "the 128s and 256s are the same artwork at two resolutions". docade checked, expecting to confirm it. They do not overlap at all — verified independently here:
| size | count | what they are |
|---|---|---|
| 1024 | 4 | cabinet-* — the four machine cabinets |
| 128 | 11 | six merge tiles, five category badges |
| 256 | 5 | merge-burst, timer-ring, block-sprite, slice-effect, card-back |
| 24 | 1 | arcade-nudge |
Zero keys in common. Nothing to normalise, and the question cost docade a check to answer a thing that was never true. It was inferred from a size histogram without reading the keys, which is the whole error in one line.
arcade is therefore not a duplication problem. It is four coherent sub-groups bundled into one lane — the same shape as ui-art and crane in advisory 05, and the same fix: the lane splits. That is ours to do and needs nothing from docade.