"use strict";
Object.defineProperty(exports, "__esModule", { value: true });
exports.DESCRIBE_MOTION_PROTOCOL = void 0;
/**
 * Reusable protocol for turning a video (or other motion artifact) into a
 * structured motion spec the variants flow can consume. Imported by the
 * shared variants protocol so Claude Code and Cursor receive the same
 * instructions. Adapted from the standalone `describe-motion` Claude Code
 * skill; this version is trimmed for Rivet's video-input path and emits
 * the spec in a shape that drops cleanly into a `motionBrief`
 * sourceArtifact.
 */
exports.DESCRIBE_MOTION_PROTOCOL = `### Describe Motion protocol (video / motion artifact -> motionBrief)

Use this protocol when the user attaches a video, gif, screen recording, or
frame sequence to a variants request. The output is a structured motion spec
the agent passes back to Rivet as a \`sourceArtifacts\` entry with
\`kind: 'motionBrief'\`. Run this BEFORE \`start_variants\` so the spec is
available to per-variant briefs and codegen.

If the user provided ONLY a static image or a URL, this protocol is the wrong
tool — describe the image as \`visualBrief\` / \`screenshotNotes\` instead.

#### Step 1 — Get frames you can inspect

Guessing from memory of a single playback is the most common failure mode.
Pull stills before describing anything.

- **Video (.mov/.mp4/.webm):** \`ffmpeg -i <input> -vf "fps=30" frames/%04d.png\`
  to step through, or \`ffmpeg -i <input> -ss <timestamp> -frames:v 1 frame.png\`
  for a single frame around a state change.
- **GIF:** \`magick <input> -coalesce frames/%04d.png\` (ImageMagick) for
  per-frame stills.
- **Unknown framerate:** assume 30 or 60fps. 33ms per frame at 30fps,
  16ms per frame at 60fps. Multiply frame count between state-change
  boundaries to get duration.
- **Frame sequence already supplied:** read every frame. The middle frames
  carry the easing.

If you cannot extract frames in the current environment, say so explicitly in
the spec and mark timing / easing fields with \`~estimated\`.

#### Step 2 — Five-phase pass

Run these in order. Later phases depend on earlier observations.

1. **Elements & trigger.** Which DOM nodes change between frames, what
   initiates the motion (\`hover\`, \`click\`, \`focus\`, \`mount\`, \`unmount\`,
   \`scroll\`, \`intersection\`, \`drag\`, \`route change\`, \`state change\`,
   \`keypress\`), and the direction (entrance / exit / hover / toggle / loop).
2. **States.** Enumerate discrete states. Most interactions are A -> B
   or A -> B -> A. Some have intermediates (idle -> loading -> success).
   For each state, note every property that will animate.
3. **Per-property motion.** For each animated property on each element:
   - **Property** — prefer compositor-friendly (\`transform\`, \`opacity\`).
   - **From -> to** — concrete values (\`opacity: 0 -> 1\`, \`translateY: 8px -> 0\`).
   - **Duration** — milliseconds, measured from frame count. Round to common
     UI durations when within 1 frame: 150, 200, 250, 300, 400, 500ms.
   - **Easing** — identify by shape (see easing guide below), not by guessing
     a cubic-bezier from memory.
   - **Delay** — t=0 or later?
4. **Choreography.** How per-property animations relate across elements:
   parallel (default), sequence (B starts after A), stagger (siblings with a
   fixed offset — note interval and direction), overlap (B starts before A
   finishes — note overlap duration), anchor / transform origin if non-default.
5. **Edge cases & quality.** Cover all of these, even if the answer is
   "not visible in artifact — recommend default":
   - **Reduced motion** — what \`prefers-reduced-motion: reduce\` should do.
     Default: skip transforms, keep opacity, shorten to ~0ms.
   - **Interrupt** — re-trigger mid-animation: snap, reverse from current,
     or queue?
   - **Exit symmetry** — is the exit the reverse of the entrance, or different?
   - **Loop** — one-shot, loop, ping-pong, or on-demand?
   - **Performance flags** — any property that would force layout
     (\`height\`, \`width\`, \`top\`)? Flag and suggest a transform alternative
     if visually equivalent.

#### Easing identification guide

Watch the speed across the animation, not just the endpoints.

- **Linear** — constant speed. Mechanical-feeling. Rare in good UI.
- **Ease-out** — fast start, slow end. Most common entrance.
- **Ease-in** — slow start, fast end. Best for exits.
- **Ease-in-out** — slow-fast-slow. For transitions between two non-home states.
- **Spring** — overshoots, then settles. Look for any frame where the element
  passes its final position. Springs cross the target; ease-out approaches
  monotonically.
- **Back-out / overshoot** — ease-out with a slight overshoot before settling.

#### Library recommendation

Pick one based on what you observed; the downstream codegen may override.

- **CSS transitions** — simple state change, single property, no interrupt
  complexity.
- **CSS keyframes** — loops, multi-step sequences with fixed timing.
- **Framer Motion** — springs, gestures, layout animations, exit animations
  via \`AnimatePresence\`, stagger via \`staggerChildren\`.
- **React Spring** — physics-driven motion where spring feel matters more
  than precise timing.
- **GSAP** — complex sequences, timeline choreography, SVG morphing.
- **Native View Transitions API** — page / route transitions where browser
  support allows.

#### Spec template (the motionBrief \`content\` payload)

Always produce this exact shape. If a field is not observable, write
\`not visible in artifact\` — do not omit the field. The content string is
what you pass as \`sourceArtifacts[i].content\`.

\`\`\`
# Motion spec: <short name>

## Source
- Artifact: <filename or description>
- Input type: video | gif | recording | frame-sequence
- Frames inspected: <count or "single playback only">
- Estimated framerate: <30 | 60 | unknown>

## Trigger
- Event: <hover | click | mount | scroll | intersection | ...>
- Element receiving event: <selector or description>

## Elements animated
1. <element name> — role in interaction
2. ...

## States
- A (initial): <description>
- B (final): <description>
- (intermediate states if any)

## Per-property motion
### <element 1>
- \\\`<property>\\\`: <from> -> <to>, duration <ms>, easing <type>, delay <ms>
- ...

### <element 2>
- ...

## Choreography
- <parallel | sequence | stagger | overlap with details>
- Transform origin: <if non-default>

## Edge cases
- Reduced motion: <behavior>
- Interrupt: <snap | reverse | queue>
- Exit: <symmetric reverse | different — describe>
- Loop: <one-shot | loop | ping-pong>
- Performance flags: <any layout-thrashing properties>

## Recommended implementation
- Library: <css | framer-motion | gsap | react-spring | view-transitions>
- Reason: <one line>

## Confidence
- High / Medium / Low on: <which fields>
- Estimates flagged with ~ in the spec above
\`\`\`

#### Working principles

- **Numbers over adjectives.** "Fast" is useless; "180ms" is implementable.
  If you cannot get a number, write \`~estimated\` and a range.
- **Frame counting beats vibes.** Snappy ~ 150-250ms; deliberate ~ 300-500ms.
  Measure when you can.
- **Identify easing by shape, not by name.** Watch where the element sits
  at 25%, 50%, 75% of the duration. Even spacing = linear. Compressed at
  the end = ease-out.
- **Distinguish observed from inferred.** Anything not seen in the artifact
  is inference. Mark it.
- **One spec per interaction.** If the video shows three interactions,
  produce three motionBrief entries, not one merged blob.

#### Handing the spec back to Rivet

Pass each finished spec as one entry in \`sourceArtifacts\`:

\`\`\`
sourceArtifacts: [
  {
    kind: 'motionBrief',
    label: '<short interaction name, <= 60 chars>',
    content: '<the full spec from the template above>',
  },
  // ... one entry per distinct interaction in the video
]
\`\`\`

**Routing.** A request that carries any \`sourceArtifacts\` (motionBrief,
visualBrief, screenshotNotes, siteBrief, urlText) is source-grounded.
Source-grounded fresh-project sessions go through
\`create_zero_to_one_project\` — its tool description explicitly lists
\`motionBrief\` alongside the other artifact kinds. Pass the artifacts under
\`sourceContext.sourceArtifacts\` on that call.

Do **NOT** call \`start_variants({ mode: 'zero_to_one' })\` directly with a
\`sourceContext\` containing any \`sourceArtifacts\` — that handler rejects
the request with \`INVALID_STAGE_ACTION\` and instructs you to use
\`create_zero_to_one_project\` instead, because the source-research
(\`source_plan\`) and brief-approval hops are only wired into the
\`create_zero_to_one_project\` path. \`start_variants(mode='zero_to_one')\`
is for prompt-only fresh projects.

If the video is supplementary to an existing project (the user wants
variants of a specific element / file / route in their open project and
attached a video for motion reference), use
\`start_variants({ mode: 'existing', target: ... })\` instead and embed the
motion spec into each variant's \`briefs[i].body\` — \`sourceArtifacts\` are
not part of the existing-project flow.

Per-variant briefs and codegen should treat the motionBrief as authoritative
timing / easing / choreography guidance — visual styling can diverge per
variant, motion fidelity should not.`;
//# sourceMappingURL=describe-motion-protocol.js.map