|
| 1 | +# Bestiary image pipeline |
| 2 | + |
| 3 | +The bestiary image workflow is deliberately split into description, review, and image stages. An image prompt cannot be compiled until its monster visual record is approved. |
| 4 | + |
| 5 | +## Source and attribution |
| 6 | + |
| 7 | +The monster index includes material from the *System Reference Document 5.2.1* by Wizards of the Coast LLC, [available from D&D Beyond](https://www.dndbeyond.com/srd) and licensed under [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/legalcode). The visual sidecar preserves that attribution and the pinned source commit in `src/data/monster-visuals.json`. Generated descriptions and images must remain original expressions; do not copy third-party prose or artwork. |
| 8 | + |
| 9 | +## Files |
| 10 | + |
| 11 | +- `src/data/monster-visuals.json` is the editable sidecar keyed by `monsterId`. It contains source facts, description fields, review/image status, prompt version, and a hash of visual-relevant monster inputs. |
| 12 | +- `src/data/monster-visual-batches.json` assigns every monster exactly once to the pilot or one of 11 production batches. |
| 13 | +- `src/lib/monster-visuals.ts` defines the schema, art bible, validation, hashing, batching, and prompt compiler. |
| 14 | +- `scripts/enrich-bestiary-visuals.ts` synchronizes records after a bestiary import without replacing authored descriptions. |
| 15 | + |
| 16 | +## Workflow |
| 17 | + |
| 18 | +1. Run `npm run import:bestiary` when the pinned SRD source changes. |
| 19 | +2. Run `npm run visuals:sync`. New monsters receive pending records populated only with structured source facts. |
| 20 | +3. Author the physical description fields for a batch. Record distinguishing anatomy, silhouette, surface materials, palette, pose, environment, required elements, forbidden elements, and accessible alt text. Stage the 14-monster pilot with `npm run visuals:seed-pilot` and the remaining 317 descriptions with `npm run visuals:seed-production`. Both commands preserve matching reviewed records and refuse to replace any description that has subsequently been edited. |
| 21 | +4. Review against the licensed source and set `reviewStatus` to `approved`. Set `imageStatus` to `ready` only when the description is ready for generation. |
| 22 | +5. Compile the prompt through `compileMonsterImagePrompt`, generate candidate images, and track review through `draft` and `approved`. |
| 23 | +6. Run `npm run visuals:audit`, `npm run visuals:check`, `npm test`, and `npm run typecheck` before merging. |
| 24 | + |
| 25 | +If a monster's visual-relevant inputs or the prompt version changes, synchronization preserves its authored text but marks approved work `needs-revision`. Duplicate or orphaned records stop synchronization rather than being silently discarded. |
| 26 | + |
| 27 | +Run `npm run visuals:export-review` to create a batch-by-batch Markdown review packet under `docs/visual-review`. Those files are generated views; make corrections in the sidecar or authored seed source and export again. |
| 28 | + |
| 29 | +## Batch contract |
| 30 | + |
| 31 | +The pilot contains one representative of each creature type in a fixed order. After removing those 14 monsters, the remaining 317 are sorted by challenge rating, then name, then ID. Production batches 1–9 contain 29 monsters each; batches 10–11 contain 28 each. The manifest contains no timestamps, so repeated generation is byte-stable. |
0 commit comments