` with no motion marker** in `get_design_context` but still animates — because the motion targets the path *inside* the opaque ``, which the markers can't see. Only `get_motion_context` reveals it, so walk every node there: ```tsx // get_design_context — plain div, NO motion marker, yet 1:51 animates

// get_motion_context for 1:51 — a bare motion.path (path-trim draw) ``` ```tsx // result — inline the SVG; svg stays plain, only the becomes motion.path

``` Full worked set — wrapper-only (`motion.svg` opacity), path-only (above), and both layers together — with the inlining mechanics (`pathLength="1"`, preserving ``, wrapper+path layering): [svg-and-path-motion.md#worked-examples](svg-and-path-motion.md#worked-examples). ## Anti-example: don't rebuild the DOM `get_design_context` is the structure of record — here a wrapper node around the vector (classNames trimmed; the point is the hierarchy and the ids): ```tsx

{/* the animated node */}

``` `get_motion_context` is the animation for node `1:348` (a `skewX` on the vector): ```jsonc { "nodeId": "1:348", "codeSnippets": { "motionDev": "" } } ``` What NOT to do — flatten the tree and animate one element: ```tsx // ❌ the 1:348 wrapper is gone, data-node-ids dropped, motion put straight on the img

``` Why it's wrong: `get_design_context` already gives the correct DOM — keep its hierarchy and `data-node-id`s, and layer the motion *onto* that tree. The `motion.div` wrapper (`1:348`) must survive; the only change is inlining the vector as an ``) and attaching the snippet's `initial`/`animate`/`transition` verbatim. ## Anti-example: keep each node's position bound to its id A rotating group with two mirror-image copies of a vector — a left and a right one. `get_motion_context` animates the group *and* the RIGHT copy (`1:245`). `get_design_context` puts each copy where it belongs via its `inset` (Tailwind `inset-[top right bottom left]`, so the 4th value is the left edge): ```tsx {/* group — rotates, so both children rotate with it */} {/* left edge 52.53% = RIGHT; also rotates */}

{/* left edge 4.4% = LEFT; static */}

``` What NOT to do — swap the two siblings' positions while transcribing: ```tsx // ❌ 1:245 (the animated node) given the LEFT inset, 1:246 given the RIGHT inset … {/* now on the left */}

…

{/* now on the right */} ``` The motion still attaches to the right node id (`1:245`), but its position drifted to the sibling's — so the WRONG copy does the extra rotation. Mirror-image pairs (left/right, top/bottom) are exactly where this slips. Why it's wrong / do instead: take every node's values from `get_design_context` — position, sizing, structure, attributes, text — and keep them bound to the SAME `data-node-id` the motion targets. `get_design_context` is the source of truth for everything except the animation; only the motion values come from `get_motion_context`. Keep the *values* verbatim, but adapt the styling *format* to the target project — `get_design_context` returns React + Tailwind as a reference, so convert the Tailwind classes to the project's styling (e.g. inline styles / its CSS) when it has no Tailwind, without changing what they encode. Don't infer placement from element order or `data-name`, and don't re-derive any value — the animated node must keep its own design-context output, or the right motion plays on the wrong element. ## Anti-example: `transformOrigin` is per element A scaling icon where `get_motion_context` returns a `transformOrigin` on _each_ scaling node — here both the outer group and the inner icon grow from the bottom-right: ```tsx ``` What NOT to do — apply `transformOrigin` to the outer element but forget the nested one: ```tsx {/* ❌ no transformOrigin → defaults to center 50% 50%, so this icon grows from the wrong corner */} … ``` Apply each node's own `transformOrigin` (`100% 100%` on both here) so every scaler grows from the corner the snippet specifies. A scale or rotate with no `transformOrigin` pivots from the default center — the growth/spin starts at the wrong corner even though the keyframe values are correct.