build-loop-gif

name	build-loop-gif
description	Expand a short character action such as “打招呼”, “挥手”, “点头”, or “跳一下” into six monotonic key poses on a strict 3×2 spritesheet, assemble a ten-frame ping-pong GIF, and reject or repair discontinuous frames. Use for this project's image-to-GIF prompt planning, Wan image generation, limb-continuity QA, spritesheet validation, and GIF assembly.

Build Loop GIF

Turn a reference character and a short action into a stable ten-frame looping GIF. Treat prompt planning, image generation, and visual QA as separate stages.

Workflow

1. Normalize the short action into one unambiguous movement.
2. Identify the smallest set of moving body parts. Explicitly freeze all other limbs, the feet, torso, camera, scale, baseline, clothing, and accessories.
3. Resolve left/right anatomically. For a front-facing character, state both the character side and its screen position.
4. Plan exactly six single-direction key poses at motion progress 0%, 20%, 40%, 60%, 80%, 100%.
5. Do not ask the image model to draw the return arc.
6. Render the complete image prompt with the contract in references/prompt-contract.md.
7. Generate one strict 3×2 spritesheet with wan2.7-image-pro.
8. Split and remove the green background. Assemble 1,2,3,4,5,6,5,4,3,2, producing ten displayed frames from six generated poses.
9. Inspect the contact sheet or GIF. Reject output if any hard check below fails.

Motion planning

For “打招呼” or “挥手”, move only the character's anatomical right arm and hand. In a front view this normally appears on the viewer's left. Keep the left arm down and unchanged in all frames.

Use MiMo-V2.5-Pro only as a text planner. Request JSON with action, moving_part, fixed_parts, and exactly six frames. Validate the response before inserting it into the image prompt. Fall back to a deterministic local plan when the API is missing, unavailable, or malformed.

Do not use MiMo-V2.5-Pro to generate the spritesheet: it outputs text, not images. Use mimo-v2.5 only when image-understanding QA is intentionally added; it can inspect an image but still cannot repair pixels.

Hard visual checks

Reject and regenerate when any condition is true:

• A hand or limb switches side, teleports, crosses the torso unexpectedly, changes length, reverses at an impossible joint angle, or becomes detached.
• An extra or missing hand, arm, leg, accessory, or character appears.
• A non-moving limb changes pose materially.
• Identity, face, clothing, viewpoint, character scale, center, or foot baseline drifts.
• Adjacent outward frames are duplicates or motion does not progress monotonically toward frame 6.
• The transition from the last displayed frame back to frame 1 visibly jumps.
• The sheet is not exactly 3×2, contains borders/text/watermarks, crops the character, or has a nonuniform background.

Never claim a GIF passed by inspecting metadata alone. View the animation or a six-pose contact sheet.

Repair policy

• If all six outward poses are coherent, assemble 1,2,3,4,5,6,5,4,3,2.
• If frames 5–6 are unusable but frames 1–4 are coherent, degrade to 1,2,3,4,3,2 and record a warning.
• If one of frames 1–4 is wrong, regenerate the entire sheet. Do not silently duplicate a neighboring frame because that creates a pause.
• If two generations fail the same limb check, simplify the action amplitude and strengthen moving/fixed-part constraints before retrying.
• Preserve the original generated sheet and record the displayed frame sequence and warnings in job metadata.