Combat Character Animation State-Machine Planner

Design a combat-animation system for a {{combat_archetype}} in {{engine}}.

Current system: {{character_system}}
Motion policy: {{motion_policy}}
Runtime: {{network_model}}

1. Separate verified engine/version facts, assumptions, and missing inputs. If a graph exists, define a minimal-change boundary.
2. Classify locomotion, aiming, attack, dodge, guard, hit reaction, airborne, and death into hierarchical states, layers, and one-shot actions; explain how to prevent state explosion.
3. Produce a table for state, entry, exit, priority, interrupt window, blend, root displacement, synchronization event, and network authority, plus a Mermaid state diagram.
4. Design input buffering, combo windows, movement locks, facing authority, montage/clip events, hit priority, and one source of truth between animation and gameplay logic.
5. Provide types, data structures, pseudocode, or a minimal scaffold that uses real {{engine}} concepts. Label unverified classes or APIs as requiring verification.
6. Define happy-path, boundary, failure, low-frame-rate, and network-latency tests with observability, reproduction steps, and acceptance criteria.

Shared execution rules
- First restate the inputs and selectors as a work contract; label unresolved details as explicit assumptions.
- Prefer current official documentation for engine features and separate fact, inference, and recommendation. If browsing is unavailable, do not claim recency.
- Respond in the order analysis → architecture → deliverable → verification table, with testable acceptance criteria for every section.
- Do not copy protected characters, games, or a studio's distinctive expression. Generated video and images are production references, not engine-ready assets.
- Rights, rigging, collision, root motion, networking, performance, and accessibility require human validation in the actual engine and target hardware. Never invent measurements or APIs.