Spec plan for a Lottie to Rive proof of concept

Spec work, not commissioned. Built for a stand-in character app from the lines of a listing and the brief it links. No rig file is claimed here: that is editor work. This is the part that decides whether the editor work pays off, and it is the part that is usually missing when a proof of concept is reviewed.

Live demo: https://demos.mc.mightyhouseinc.com/s3smrqcm-rive-poc/ Rig structure: https://demos.mc.mightyhouseinc.com/s3smrqcm-rive-poc/rig.html Control surface: https://demos.mc.mightyhouseinc.com/s3smrqcm-rive-poc/control.html Benchmark: https://demos.mc.mightyhouseinc.com/s3smrqcm-rive-poc/bench.html Risk and routines: https://demos.mc.mightyhouseinc.com/s3smrqcm-rive-poc/risk.html

What it has, line by line from the brief

Each task in the brief against the procedure that proves it and the artifact that is the evidence.

The file structure: artboards, the state machine, and wearable groups that ride the skeleton instead of being re-keyed per animation.

A live control surface that switches between the two named animations.

Per-item visibility controls, grouped, usable while an animation runs.

Body color and per-group wearable color, changed live.

The exact Dart call behind every control, against a pinned runtime version.

A benchmark method: what to record, in which scenes, at how many characters on screen, and the limits that make the answer no.

The step sequence for adding an animation without touching every wearable.

The step sequence for a monthly wearable drop, sized to one week.

Platform-change risk, the cost to keep the system, and how a new person is trained onto it.

No client file is used anywhere. Every shape in the demo is drawn by a script.