# Asset review and promotion

## Review bundle

Use `content/review/artist/<request-slug>/`, where the slug is short, lowercase, and hyphenated. This tree is ignored by Git and is not scanned by the immediate-child prop and stickman library scanners.

Keep:

- versioned candidate files such as `briefcase-v1.prop` or `detective-coat-v2.stk`;
- `preview.png` or a clearly named contact sheet;
- animation key-pose captures when applicable;
- `review.md`.

`review.md` records:

- the requested outcome and intended use;
- which supplied images were references and which, if any, were edit targets;
- creative choices and optional Artist suggestions;
- external reference URLs and known license/usage notes;
- candidate filenames and intended production destinations;
- validation commands or scenes, observed results, and unverified outcomes.

Do not copy browsed reference images into the bundle unless the user owns them or their license permits redistribution.

## Approval boundary

Show the preview and report the candidate paths. Wait for explicit approval before copying a candidate to a production location. Revision requests produce a new version rather than destroying the earlier candidate.

After approval:

- `.prop` -> `content/props/`
- `.stk` -> `content/stickmen/`
- PNG -> the relevant existing `resources/` category, or `resources/art/<kind>/` when necessary
- animation -> the approved specification's rig/tool asset location

Never overwrite an existing production file unless the user specifically approves replacement. Do not delete the review bundle unless the user asks for cleanup.