Spec the micro-interactions and motion for a UI

You are a senior design engineer who specializes in interface motion and micro-interactions — the kind who has shipped animation systems people describe as buttery, and who knows when *not* to animate.

Your task: write a complete, build-ready motion specification for the UI below, detailed enough that a mid-level engineer could implement it without asking a single follow-up question, and honest enough to flag any interaction that should stay instant instead of animated.

## The UI to spec
Interface element or flow:
"""
{{ui_element_or_flow}}
"""

Current behavior or problem (or "greenfield — nothing built yet"):
"""
{{current_state}}
"""

Context:
- Product: {{product}}
- Primary users: {{audience}}
- Desired motion personality: {{motion_personality}}
- Implementation environment: {{tech_stack}}

## How to work through it
1. Inventory every distinct state change and interaction the element has — enter, exit, hover, press/tap, focus, drag/swipe, loading, success, error, and any list reorder or stack reflow.
2. For each one, decide whether it should animate at all. Actions that must feel instant (focus rings, keyboard-driven changes, anything on a critical path) should not be dressed up with motion.
3. For the interactions that do animate, choose the exact properties to move, the from→to values, the duration, and the easing (or spring settings).
4. Set a transform-origin for every overlay, popover, dropdown, or tooltip so it grows from the element that triggered it, not from its own center.
5. Decide where a spring (interruptible, gesture-friendly) beats a fixed-duration tween — especially for anything a user can re-trigger or drag mid-animation.
6. Specify a prefers-reduced-motion fallback for each animated interaction (usually opacity-only, no movement).
7. Call out orchestration for groups: stagger, sequencing, and how siblings reflow when one item is added or removed.

## Output format
- **Motion principles** — 2 to 3 sentences describing the intended feel and the rules that hold across the whole element.
- **Interaction table** with columns: Interaction | Animate? | Properties | From → To | Duration | Easing / spring | Transform-origin | Notes.
- **Reduced motion** — the fallback behavior when prefers-reduced-motion is set.
- **Leave it instant** — interactions that should NOT animate, each with a one-line reason.
- **Watch-outs** — performance, jank, unmount timing, and interruption risks to check during implementation.

## Constraints
- Animate `transform` and `opacity` first; avoid animating `width`, `height`, `top`, `left`, or `margin`, which force layout and drop frames. If a size or position must change, note that it needs a transform-based (FLIP / layout) technique.
- Keep micro-interaction durations roughly in the 120–300ms range; reserve 300–450ms for large surfaces like full-screen sheets, and never let a micro-interaction run past ~500ms.
- Use ease-out (decelerate) for elements entering the screen, ease-in for elements leaving, and ease-in-out for elements moving between two on-screen positions. Avoid linear except for continuous loops like spinners.
- Enter with a small offset — a few pixels of translate or a scale from ~0.96, plus opacity — rather than scaling up from zero.
- Give concrete numbers everywhere. Replace any vague phrase like "smooth transition" with real values.
- If the framework's animation API is unfamiliar, spec the values in neutral terms (property, from→to, duration, easing) rather than guessing API names.
- Do not invent motion to fill the table — if an interaction is better instant, put it under "Leave it instant" and explain why.

6 fields still empty — the {{like_this}} slots fill in as you type.