{
"format": "driftproof-answers/2",
"receipt_hash": "1c9ada1036b3c143c278438e008ac56df967a7132d863649e386e8d3c4664741",
"model_id": "claude-opus-5-5",
"answers": {
"12afa44ffd74e524c1e446c552820686e7cce366a8708d630509eafb989c4722": "# Heading Reveal + Card Entrance (Seekable)\n\nEverything lives in **one paused GSAP timeline** with explicit `fromTo` values. Because every tween defines its start state, the renderer and preview can jump to any time, forward or backward, and get the same frame.\n\n## Choreography (3.0s scene)\n\n| Time | Beat |\n| --------- | --------------------------------------------------------------------------------- |\n| 0.00–0.70 | Heading slides up out of a clipped mask (`yPercent` 110 → 0), `power3.out` |\n| 0.35–0.85 | Subhead fades and rises 16px, overlapping the heading's tail |\n| 0.70–1.55 | Three cards rise 40px, scale 0.96 → 1, fade in, staggered 0.12s, `power2.out` |\n| 1.55–3.00 | Hold, so the scene reads before the next clip |\n\n## Markup\n\n```html\n
\n
Ship faster
\n
Three tools, one workflow
\n
\n Plan\n Build\n Launch\n
\n
\n```\n\n```css\n.heading-mask { overflow: hidden; } /* mask for the line reveal */\n.heading-line { display: inline-block; } /* needed so yPercent applies */\n.card { will-change: transform, opacity; }\n```\n\nWire the root and any `.clip` attributes per `hyperframes-core`. `data-duration` is shown here only to show that it sets the length.\n\n## Timeline\n\n```js\ndocument.fonts.ready.then(() => {\n const tl = gsap.timeline({ paused: true });\n\n tl.fromTo(\".heading-line\",\n { yPercent: 110 },\n { yPercent: 0, duration: 0.7, ease: \"power3.out\" }, 0)\n .fromTo(\".subhead\",\n { opacity: 0, y: 16 },\n { opacity: 1, y: 0, duration: 0.5, ease: \"power2.out\" }, 0.35)\n .fromTo(\".card\",\n { opacity: 0, y: 40, scale: 0.96 },\n { opacity: 1, y: 0, scale: 1, duration: 0.6, ease: \"power2.out\",\n stagger: 0.12 }, 0.7);\n\n // Register only after the timeline is fully built.\n window.__timelines = window.__timelines || {};\n window.__timelines[\"heading-cards\"] = tl;\n});\n```\n\nMatch the registration key and shape to `hyperframes-core`'s convention. The important part is the ordering: build first, register last, inside the async callback.\n\n## Why it's seek-safe\n\n- **One paused timeline.** HyperFrames drives the playhead, and nothing auto-plays.\n- **Explicit `fromTo`.** Seeking backward restores the hidden state. There are no page-load `gsap.set` calls and no reliance on CSS starting styles.\n- **Deterministic.** The stagger is a fixed 0.12s. There is no `Math.random`, `Date.now`, or `performance.now`, and no `from: \"random\"`.\n- **No measurement at tween time.** Offsets are constants (`yPercent`, 16px, 40px), not `getBoundingClientRect()` reads.\n- **Transforms and opacity only.** No `width`, `height`, `top`, `left`, `display`, or raw `visibility` tweens.\n- **Finite.** There is no `repeat: -1`, and the total length (about 1.55s of motion) fits inside the 3s duration.\n- **No side-effect callbacks.** There is no `onComplete` or `onStart` logic that would fire inconsistently when scrubbing.\n\n## Optional variations\n\n- **Per-word heading.** Wrap each word in its own masked span and stagger at 0.06s. Keep the split in static markup, not runtime DOM measurement.\n- **Directional cards.** Use `stagger: { each: 0.12, from: \"center\" }`, which is still deterministic.\n- **Accent.** Tween a card border's `backgroundColor` or `borderRadius` at around 1.4s. Both are allowed non-spatial properties.\n\nAfter authoring, run `animation-map.mjs` to check stagger consistency and find dead zones.",
"f05fb358b23af4747b47d1caff7f2981ca6a13836f0cb2f9a5344a7a461b9920": "# Heading Reveal + Card Entrance\n\nThe scene uses a masked word-rise for the heading, then a staggered lift-and-settle for the cards. Everything runs on **one paused GSAP timeline** so the preview can seek to any frame deterministically.\n\n## Choreography (4s scene)\n\n| Time | Beat |\n| ----------- | ------------------------------------------------------------------ |\n| 0.0 – 0.2s | Hold (clean first frame) |\n| 0.2 – 1.0s | Heading words rise out of a mask, 0.08s stagger, `expo.out` |\n| 0.7 – 1.1s | Accent rule scales in from left (overlaps heading tail) |\n| 1.0 – 1.9s | Cards lift 40px, scale 0.96 → 1, fade in, 0.12s stagger, `power3.out` |\n| 1.9 – 4.0s | Rest. The content stays readable through the scene end. |\n\n## Markup\n\n```html\n
\n
\n Ship\n faster\n together\n
\n \n
\n …\n …\n …\n
\n
\n```\n\n```css\n.mask { display: inline-block; overflow: hidden; vertical-align: bottom; }\n.word { display: inline-block; will-change: transform; }\n.rule { transform-origin: left center; }\n.card { will-change: transform, opacity; }\n```\n\n## Timeline\n\n```js\ndocument.fonts.ready.then(() => {\n const tl = gsap.timeline({ paused: true });\n\n tl.fromTo(\".word\",\n { yPercent: 110 },\n { yPercent: 0, duration: 0.8, ease: \"expo.out\", stagger: 0.08 }, 0.2)\n .fromTo(\".rule\",\n { scaleX: 0 },\n { scaleX: 1, duration: 0.4, ease: \"power2.out\" }, 0.7)\n .fromTo(\".card\",\n { y: 40, scale: 0.96, opacity: 0 },\n { y: 0, scale: 1, opacity: 1, duration: 0.6, ease: \"power3.out\", stagger: 0.12 }, 1.0);\n\n // Register only after the timeline is fully built\n window.__timelines = window.__timelines || {};\n window.__timelines[\"scene\"] = tl;\n});\n```\n\n## Why this is seek-safe\n\n- **Single paused timeline.** Nothing autoplays, so the renderer or preview controls the playhead.\n- **`fromTo` everywhere.** The start states are explicit. Jumping backward from 3s to 0.5s gives the same pixels as a linear playthrough. There are no page-load `gsap.set` calls.\n- **Absolute position parameters** (`0.2`, `0.7`, `1.0`). The timing doesn't depend on chained offsets or runtime measurement.\n- **Transform aliases plus opacity only.** It uses `yPercent`, `y`, `scale`, and `scaleX`. There are no `width`, `top`, `display` or `visibility` tweens, and no `getBoundingClientRect()` calls.\n- **No randomness or clocks.** There is no `Math.random`, `Date.now` or `repeat: -1`.\n- **Registered after `document.fonts.ready`.** The word masks are sized with final glyph metrics before any frame is sampled.\n- **The `.clip` lifecycle is left to the framework.** The tweens target only children of the clip.\n\n## Assumptions to verify\n\n- The registration key shape (`window.__timelines[\"scene\"]`) and the exact `data-*` attributes on the clip. Check both against `hyperframes-core`; I wrote them from the general contract, not from the core docs.\n- After authoring, run `animation-map.mjs` and `npx hyperframes check` to confirm the stagger spacing and that no lifecycle warnings appear.",
"c364e18b91141283adde4b1411a743d8c3e1a81ab8dcdc44fa24564c22f43ac5": "# Heading Reveal + Card Entrance (seekable)\n\n## Plan\n\nOne paused GSAP timeline. Every tween is a `fromTo` with explicit start and end values, so seeking to any time gives the same frame. Nothing depends on playback history.\n\n| Time | Beat |\n| ----------- | -------------------------------------------------------------------- |\n| 0.00–0.60s | Heading mask-slides up: line wrapper clips, inner text goes `y: 100% → 0` |\n| 0.35–0.85s | Accent rule scales in from left (`scaleX: 0 → 1`) |\n| 0.70–1.40s | Three cards rise and fade in with a 0.12s stagger (`y: 40 → 0`, `autoAlpha: 0 → 1`, `scale: 0.96 → 1`) |\n| 1.40–4.00s | Hold. A finite root `data-duration` governs the scene length. |\n\n## Markup\n\n```html\n
\n
\n Built for speed\n
\n \n
\n
Fast
\n
Reliable
\n
Simple
\n
\n
\n```\n\n```css\n.line { display: block; overflow: hidden; } /* mask */\n.line-inner { display: block; will-change: transform; }\n.rule { transform-origin: left center; }\n.card { will-change: transform, opacity; }\n```\n\n## Timeline\n\n```js\nconst tl = gsap.timeline({ paused: true });\n\ntl.fromTo(\".line-inner\",\n { yPercent: 100 },\n { yPercent: 0, duration: 0.6, ease: \"power3.out\" }, 0)\n .fromTo(\".rule\",\n { scaleX: 0 },\n { scaleX: 1, duration: 0.5, ease: \"power2.out\" }, 0.35)\n .fromTo(\".card\",\n { y: 40, scale: 0.96, autoAlpha: 0 },\n { y: 0, scale: 1, autoAlpha: 1, duration: 0.7,\n ease: \"power2.out\", stagger: 0.12 }, 0.7);\n\n// Register only after the timeline is fully built.\n// If you wait on fonts first, build and register inside the callback:\n// document.fonts.ready.then(() => { /* build tl, then register */ });\nwindow.__timelines = window.__timelines || [];\nwindow.__timelines.push(tl);\n```\n\nThe exact shape of `window.__timelines` (array or keyed by composition ID) is defined in `hyperframes-core`. Match that contract.\n\n## Why it scrubs cleanly\n\n- **Paused timeline, fully deterministic.** No `Math.random`, `Date.now`, or `performance.now`. The stagger is a fixed value, not `\"random\"`.\n- **`fromTo` everywhere.** Start states live in the timeline, not in a page-load `gsap.set`. Seeking backward to 0 restores them.\n- **Transform aliases only** (`yPercent`, `y`, `scale`, `scaleX`) plus `autoAlpha`. No `top`, `height`, `display`, or raw `visibility` tweens.\n- **`autoAlpha` targets the inner `.card` elements, not a `.clip`.** The framework owns clip lifecycle.\n- **No layout measurement at tween time.** `yPercent: 100` covers the mask offset without `getBoundingClientRect()`.\n- **No infinite repeats.** The finite `data-duration=\"4\"` bounds the scene.\n\n## Optional variations\n\n- **Per-word heading:** split into word spans (pre-split in markup) and stagger `yPercent` by 0.06s.\n- **Snappier cards:** use `ease: \"back.out(1.4)\"`. Keep the overshoot small so cards don't clip their container.\n\nAfter authoring, you can run `scripts/animation-map.mjs` on the composition to check stagger spacing and lifecycle warnings.",
"a270f9c8174b130c9fea8b42f40a8735ef2651da7893434894c397bf920319b5": "# Heading Reveal + Card Entrance (Seekable)\n\nSeeking only works if every frame is a **pure function of time**. The design below follows that rule. I couldn't check HyperFrames' current API from here, so the specifics are based on its documented pattern: an HTML composition plus a **paused GSAP timeline** registered on `window.__timelines`. Verify the attribute names against your installed version.\n\n## Timing (3.0s)\n\n| Time | Element | Motion |\n|---|---|---|\n| 0.00–0.70s | Heading | Mask wipe (left→right) plus a 24px rise |\n| 0.35–0.85s | Subhead | Fade in plus a 12px rise |\n| 0.60–1.40s | Cards ×3 | Rise 40px, scale 0.96→1, fade in, 0.12s stagger |\n| 1.40–3.00s | — | Hold |\n\n## Composition\n\n```html\n
\n
Ship faster
\n
Three things that changed this quarter
\n
\n
Builds 2× faster
\n
Zero-downtime deploys
\n
Unified logs
\n
\n
\n\n\n\n\n```\n\n## Why this supports jumping to any time\n\n- **The timeline is paused.** The runtime calls `tl.seek(t)`, so nothing advances on wall-clock time.\n- **Tweens use `fromTo`, not `from`.** Start and end states are both explicit, so seeking backward or jumping to arbitrary points resolves correctly. `from()` can capture the wrong end state after a seek.\n- **All positions are absolute** (`0`, `0.35`, `0.6`), not relative chains. The layout stays readable and doesn't shift if you edit one tween.\n- **There are no side effects.** No `onComplete` or `onStart` logic, `setTimeout`, `requestAnimationFrame`, `Math.random()`, or CSS `@keyframes`/`transition`. Any of these would make frames depend on playback history.\n- **The stagger is deterministic.** A fixed `0.12s` gives the same result on every seek.\n- **Fonts are preloaded.** If a webfont swaps mid-render, the first-frame metrics will differ from later frames.\n\n## Quick check\n\nScrub to **0.0s, 0.5s, 1.0s, 3.0s, then back to 0.3s**. Each frame should look the same whether you reach it by playing or by jumping. If the 0.3s frame differs after a backward jump, look for a `from()` tween or a time-based side effect.",
"5acecb1920234bb154c47ed9e9a8e0e7b7a502955a043212daa96fadf1e71cd7": "# Seekable Heading Reveal and Card Entrance\n\n## Seekability rules\n\nTo jump to any time, every frame has to be a **pure function of time**. Concretely:\n\n- Build one **paused** timeline. Let the preview or renderer set its time. Never autoplay.\n- Use `fromTo` with explicit start and end values. Seeking backward then restores the correct state, and nothing depends on what was rendered before.\n- Don't use CSS `transition` or `@keyframes`, `setTimeout`, `requestAnimationFrame` loops, unseeded randomness, or `onComplete` callbacks that change the DOM.\n- Animate only `transform`, `opacity` and `clip-path`. They are cheap and have no layout side effects.\n\n## Timing (about 1.5s total)\n\n| Time | Element | Motion |\n|---|---|---|\n| 0.00–0.70s | Heading | Clip-path wipe from left to right, rising 16px |\n| 0.15–0.75s | Subheading | Fade in, rising 10px |\n| 0.45–1.45s | 3 cards | Staggered by 0.12s: rise 28px, scale 0.96→1, fade in |\n\nEasing is `power3.out` for the heading and `power2.out` for the cards.\n\n## Markup and styles\n\n```html\n\n
Ship faster
\n
Three ways to cut build time
\n
\n Cache\n Parallelize\n Prune\n
\n\n```\n\n```css\n.heading, .sub, .card { will-change: transform, opacity; }\n.cards { display: grid; grid-template-columns: repeat(3, 1fr); gap: 24px; }\n```\n\nThe hidden starting state comes from the timeline, not from CSS. Time 0 is then always correct, and so is any time you seek to.\n\n## Timeline\n\n```js\nconst tl = gsap.timeline({ paused: true });\n\ntl.fromTo(\".heading\",\n { clipPath: \"inset(0 100% 0 0)\", y: 16 },\n { clipPath: \"inset(0 0% 0 0)\", y: 0, duration: 0.7, ease: \"power3.out\" }, 0)\n .fromTo(\".sub\",\n { opacity: 0, y: 10 },\n { opacity: 1, y: 0, duration: 0.6, ease: \"power2.out\" }, 0.15)\n .fromTo(\".card\",\n { opacity: 0, y: 28, scale: 0.96 },\n { opacity: 1, y: 0, scale: 1, duration: 0.64, ease: \"power2.out\",\n stagger: 0.12 }, 0.45);\n\n// Hand the paused timeline to the HyperFrames runtime so it drives tl.seek(t).\nwindow.__timelines = window.__timelines || {};\nwindow.__timelines[\"scene\"] = tl;\n```\n\n## Points to confirm\n\n- **Registration hook.** I wrote `window.__timelines` and `data-duration` from memory of HyperFrames conventions, not from the docs you have. Check the exact names in your HyperFrames version. The animation design doesn't depend on them.\n- **Scrubbing test.** Seek to 0, 0.5, 1.0 and 3.0 in any order, including backward jumps. Each frame should look identical regardless of how you reached that time.\n- **Fonts.** Make sure web fonts are loaded before the first seek. Otherwise the clip-path wipe can measure the wrong text width.",
"ba0bdbea16c8f6aa60ce537adcd122b1c092612f3c627b21b6952803fe3aa351": "# Heading reveal and card entrance for a seekable HyperFrames scene\n\n**Assumption to check:** I'm writing this from general knowledge of HyperFrames. It is HTML compositions driven by a paused GSAP timeline that the runtime seeks. I couldn't check the exact registration hook or the `data-*` attribute names here, so compare them against your version's docs before using this.\n\n## Seekability rules\n\nEvery rule comes from one requirement: **what's on screen must depend only on the time `t`.**\n\n- Use one **paused** timeline, and let the player seek it. Never call `play()`.\n- Use `fromTo()` (or `set()` plus `to()`) so each tween states its start and end values. This keeps any seek point correct, including backward jumps and a first frame in the middle of the scene.\n- Avoid CSS `transition` and `@keyframes`, `setTimeout`, `requestAnimationFrame` loops, and `onComplete` code that changes the DOM.\n- Avoid unseeded randomness. If you want stagger jitter, compute it once from fixed values.\n- Use only transforms, opacity and `clip-path`, so seeking doesn't trigger layout.\n\n## Timing (about 1.6 s)\n\n| t (s) | Beat |\n|---|---|\n| 0.00–0.60 | Heading wipes up from a mask, rising 24px, with opacity 0→1 |\n| 0.35–0.75 | Accent underline scales in along X from the left |\n| 0.55–1.60 | Three cards rise 40px and scale 0.96→1, with opacity, staggered 0.12 s |\n\n## Sketch\n\n```html\n
\n
Quarterly Results
\n \n
\n
…
…
…
\n
\n
\n\n\n\n\n```\n\n## Checking it in the preview\n\n1. Jump straight to t = 0.7 on a fresh load. The heading should be fully visible, the rule should be mostly drawn, and card 1 should be partly in.\n2. Scrub backward from the end to 0. Everything should return to hidden, with nothing left at its final state.\n3. Seek to the same t twice. The frames should be identical, which confirms the scene is deterministic.\n\nIf any of these checks fails, it is almost always one of three things: a `from()` tween caching values when it was created, a CSS transition on an animated property, or an element styled visible in CSS with no matching `fromTo` start state.",
"e010738d0adba8b124b2611f67bc62b0e0fc7c977d06971a161e71e2ccf183e8": "**Consult `adapters/lottie.md`.** The routing table sends Lottie / dotLottie work there, and it covers the `window.__hfLottie` integration. Because seeking is governed by the composition contract, also review **`hyperframes-core` → One paused timeline + Non-negotiable rules**.\n\n**Property to check: whether the Lottie instance is registered on `window.__hfLottie`.** The skill says each runtime registers its instances on its runtime-specific global \"so HyperFrames can seek all of them in one pass.\" If the player isn't registered there, HyperFrames can't seek it, and the animation will drift from the timeline or ignore scrubbing.\n\nRelated things to confirm while you're there:\n- The animation is driven by seeking, not free-playing on its own clock. The core contract requires a single paused timeline, no `Date.now` or `performance.now`, and determinism.\n- Nothing loops forever (no `repeat: -1` equivalent) unless the root has a finite `data-duration`.\n- Registration happens only after setup finishes, including any async loading such as fetching the animation JSON.\n\nThe supplied material doesn't include the contents of `adapters/lottie.md`, so I can't quote its exact API calls or registration snippet. Read that file for the precise steps.",
"0177f00c036b698cc8224b546562b0f5a9b522489b24e1e38f9aad20d80e76f3": "**Consult `adapters/lottie.md`.** The skill's routing table sends Lottie / dotLottie work (After Effects exports, characters) there, and it is listed with the `window.__hfLottie` global.\n\n**Check that the Lottie instance is registered on `window.__hfLottie`.** The skill says each runtime registers its instances on its own global so HyperFrames can seek all of them in one pass. A Lottie animation that isn't registered there won't be seeked by the framework, so it will drift from the timeline or play on its own clock.\n\nAlso re-check these `hyperframes-core` constraints, which the animation skill lists as prerequisites:\n- There must be a single paused root timeline, with `data-duration` governing length.\n- Behavior must be seek-safe and deterministic: no `Math.random`, `Date.now`, or `performance.now`.\n- No unbounded looping (`repeat: -1`) without a finite root `data-duration`.\n- Register only after the build is fully complete, including when setup runs in an async callback like a Lottie load or `document.fonts.ready`.\n\nThe exact player API calls (how to seek a frame, disable autoplay, and so on) are in `adapters/lottie.md`. I haven't read that file here, so I can't quote them.",
"5e61bc6223da328f7065a4495814bfd03d6ce9cc6f963595fc32d1075b4c7bf3": "**Guidance to consult**\n\n1. **`adapters/lottie.md`** is the primary reference. The routing table points Lottie/dotLottie work there, and it covers the `window.__hfLottie` integration.\n2. **`hyperframes-core`**, specifically *One paused timeline* and *Non-negotiable rules*. The seek contract comes from there: one paused timeline, `data-duration` governs length, no wall-clock time sources, and no `repeat: -1` without a finite root `data-duration`.\n\n**Property to check**\n\nCheck that the Lottie instance is registered on **`window.__hfLottie`**. Each runtime registers its instances on its own global so HyperFrames can seek all of them in one pass. If the Lottie player isn't registered there, the renderer can't drive it. The animation would then play on its own clock instead of following the seek position, which is the usual cause of seek drift.\n\nRelated things to verify in the same pass:\n\n- **Finite duration.** A looping Lottie needs a finite root `data-duration`.\n- **No wall-clock timing.** Nothing should use `Date.now`, `performance.now`, or autoplay timing to advance the animation.\n- **Late registration.** If setup is async (for example, waiting on the asset or `document.fonts.ready`), register only after the instance is fully built.\n\nI haven't read `adapters/lottie.md` itself. Its exact registration API and player settings should be confirmed there before you edit.",
"9346762dbd39f3fcbf0ab2bc90b48d6fd06fd1dd33d067a4b5067ddeb8e54ff3": "No specific guidance documents or facts were included in your message, so I can't name the exact guide your project expects. Based on how Lottie seeking generally works:\n\n**Guidance to consult:** The Lottie-specific guidance for your rendering or animation framework, meaning the section on driving Lottie from an external timeline. If you're using Remotion, that's the `@remotion/lottie` docs. Otherwise, look for whatever adapter guide covers Lottie in your stack. Ignore generic animation docs. Seek bugs almost always come from how Lottie is synced to the host timeline.\n\n**Property to check:** Check whether the Lottie animation is **timeline-driven rather than self-playing**:\n\n- **`autoplay` must be `false`, and `loop` should be handled deliberately.** If Lottie runs its own internal clock, seeking the scene won't move the animation. It also drifts from the timeline.\n- **Seeking should map the host time to a Lottie frame**, for example `anim.goToAndStop(frame, true)`. The `true` means the value is a frame, not milliseconds.\n- **The Lottie file's frame rate (`fr` in the JSON) must match the composition's fps**, or the conversion must account for the difference. A mismatch makes seeks land on the wrong frame.\n\nIf you paste the guidance or facts you meant to include, I can point to the exact document and property they specify.",
"8142d7dd6029c236e37a45c41337b2a5367796a1df2512d863962b939d75670f": "**No guidance documents or facts came with your message.** I can't say which specific file or skill your project expects you to consult, or what property it names. If you paste the relevant guidance (for example, a rules or skill index), I can point to the exact entry.\n\nFrom general knowledge, here's what usually applies when fixing Lottie seek behavior in a frame-driven renderer such as Remotion:\n\n- **Guidance to consult:** the project's Lottie-specific guidance, such as a `lottie` rule or skill doc, or the `@remotion/lottie` documentation. The core principle is that Lottie must not autoplay on its own clock. The host's current frame (e.g., `useCurrentFrame()`) must drive it, so seeking, scrubbing and rendering stay deterministic.\n- **Property to check:** the animation's own frame rate, the `fr` field in the Lottie JSON. Compare it with the composition's `fps`. If they differ, the frame must be converted (`lottieFrame = frame / fps * fr`), or seeks will land on the wrong frame. Also check:\n - that autoplay is disabled and the component is seeked imperatively per frame;\n - `loop` and `playbackRate`, which change how a seek maps to a Lottie frame;\n - the `ip`/`op` (in/out point) range, so seeks are clamped or wrapped correctly.\n\nIf your supplied facts name a different property, go with that one over this general answer.",
"14262483fe99a3f3ebf6710d33f23b1fb9672aeac3936050e456afd94bccda44": "I don't see any facts, docs, or skill files supplied in this conversation beyond the workspace metadata (an empty git repo with no commits). So I can't name the specific guidance document you have in mind. Paste it in and I'll answer from it directly. Here is the general answer for Lottie seek fixes.\n\n**Guidance to consult:** the Lottie/lottie-web adapter or integration guidance for your scene framework, specifically the section on controlled or deterministic playback. Seeking should be driven by the host timeline, not by Lottie's own clock.\n\n**Property to check:** whether the seek is **frame-accurate and deterministic**. That means seeking to time *t* always renders the same frame, whether you jump there directly or play up to it. In practice, verify:\n\n- **`autoplay: false`** (and usually `loop: false`). Lottie's internal ticker must not advance the animation independently of the scene's clock.\n- **Seek call semantics.** Use `goToAndStop(value, isFrame)` with the correct `isFrame` flag. Passing a frame number with `isFrame=false` makes Lottie treat it as milliseconds, which is a common seek bug.\n- **Frame-rate and range mapping.** Convert scene time to a Lottie frame using the animation's own `fr` (frame rate) and its `ip`/`op` (in/out points), not the host's fps. Clamp the result to that range.\n- **Readiness.** Don't seek before `DOMLoaded`/`data_ready` fires, or the seek is silently dropped.\n\nIf your supplied guidance names a different specific property, share it and I'll align the answer to it.",
"6a1231ec089660ddf2fa9433c2b74cca25cd1b9cea8fa8c886eb5fc59763f173": "**Recommendation:** for a scene that already matches the brand-reveal template, load that blueprint instead of composing atomic rules.\n\n## When a blueprint is appropriate\n\nLoad a blueprint when either of these is true:\n\n1. **The scene matches an existing pre-designed multi-phase template** (brand-reveal, social-proof, and so on), and reusing its phase pipeline saves real authoring time.\n2. **You want runnable ground-truth code for a complex 4-5 phase choreography**, rather than working out the phase sequencing yourself.\n\nYour scene meets the first condition, and a complex brand reveal likely meets the second as well.\n\nTwo usage notes:\n- Blueprints are listed in `blueprints-index.md`. Each entry points to a full recipe at `blueprints/.md`.\n- Don't read a blueprint just to see what's in it. Open it only after you've decided you need scene-level orchestration, as you have here.\n\n## How it differs from atomic rules\n\n| | Atomic rules (default) | Blueprints |\n|---|---|---|\n| **Scope** | A single motion pattern, such as one entrance, stagger or effect | A whole scene with several phases |\n| **Workflow** | Pick 2-4 rules from `rules-index.md` and connect them with one paused GSAP timeline | Load one recipe that already defines the phase pipeline |\n| **Where to look** | `rules-index.md` → `rules/.md` (the HTML, CSS and GSAP for one rule) | `blueprints-index.md` → `blueprints/.md` |\n| **Tradeoff** | Faster to build and less code when no template fits | More upfront structure, but you skip designing the choreography |\n| **Default?** | Yes, the starting point for most scenes | Only when a template clearly matches |\n\nIn short, atomic rules are small pieces you combine yourself. A blueprint is a complete, pre-sequenced scene.\n\n## What doesn't change\n\nUsing a blueprint doesn't relax any of the HyperFrames constraints. The composition still needs:\n- **One paused timeline**, registered only after it is fully built.\n- **Deterministic code**: no `Math.random`, `Date.now` or `performance.now`.\n- **No unbounded loops**: no `repeat: -1` unless the root has a finite `data-duration`.\n- **Layout positions computed once at setup**, never from `getBoundingClientRect()` while tweens run.\n- **Spatial motion through transform aliases** (`x`, `y`, `scale`, `rotation`) only, never `width`, `height`, `top` or `left`.\n\nAfter you adapt the blueprint, you can run `scripts/animation-map.mjs` on the composition. It checks the choreography for dead zones, stagger consistency and lifecycle warnings.",
"57f6c556ffde4fadc7e09922e0e4869b4543d570d4db0a0e42a67171a89c0c59": "**For this scene, use the blueprint.** A requested scene that already matches the complex brand-reveal template is the case blueprints exist for.\n\n## When a blueprint is appropriate\n\nLoad one only when both of these hold:\n\n1. **The scene matches an existing pre-designed multi-phase template** (brand-reveal, social-proof, etc.), and reusing its phase pipeline saves real authoring time.\n2. **You want runnable ground-truth code for a complex choreography,** typically 4–5 phases that would be fiddly to sequence by hand.\n\nPick it from `blueprints-index.md`, then load the recipe at `blueprints/.md`, here likely `blueprints/brand-reveal.md`. Don't read blueprints speculatively. Load one only after you've decided the scene needs scene-level orchestration.\n\n## How it differs from atomic rules\n\n| | Atomic rules (the default) | Blueprints |\n|---|---|---|\n| **Scope** | A single motion pattern (one entrance, one stagger, one effect) | A whole multi-phase scene |\n| **How you use them** | Pick 2–4 from `rules-index.md` and glue them into one paused GSAP timeline | Reuse a pre-built phase pipeline as the scene's backbone |\n| **Lookup** | By trigger or tag in `rules-index.md`, full recipe in `rules/.md` | By scene type in `blueprints-index.md`, full recipe in `blueprints/.md` |\n| **Cost** | Faster to author, less code | Larger, but saves time when the scene already fits the template |\n| **Best for** | Most scenes, especially novel or simple ones | Scenes that clearly match a known template |\n\nIf the scene only partly resembles a brand reveal, or needs just two or three motions, composing atomic rules is quicker and leaner than adapting a blueprint.\n\n## Constraints that apply either way\n\nA blueprint doesn't exempt you from the core contract:\n\n- Use one paused timeline, and register it only after it is fully built.\n- `data-duration` governs length.\n- Don't use `Math.random`, `Date.now`, or `performance.now`.\n- Pre-calculate layout constants instead of calling `getBoundingClientRect()` at tween time.\n- Use transform aliases (`x`, `y`, `scale`, `rotation`) for spatial motion, never `width`, `height`, `top`, or `left`.\n\nAfter authoring, you can audit the choreography with `scripts/animation-map.mjs` to catch dead zones and stagger inconsistencies.",
"bffe1ccacde856175ecdbf1f2ae624e55f07472d84b6afb5993a3f4c6d951fd8": "**For this scene, a blueprint is appropriate.** The scene already matches the brand-reveal template, which is the case blueprints are meant for.\n\n## When to load a blueprint\n\nLoad one only once you've decided you need scene-level orchestration. Two situations qualify:\n\n1. **The scene matches a pre-designed multi-phase template**, such as brand-reveal or social-proof. Reusing that template's phase pipeline saves real authoring time.\n2. **You want runnable ground-truth code for a complex 4–5 phase choreography**, rather than building the sequencing yourself.\n\nBlueprints are listed in `blueprints-index.md`, and each entry points to a recipe at `blueprints/.md`. Don't read them speculatively. Pull the specific one, here the brand-reveal recipe, after making the call.\n\n## How blueprints differ from atomic rules\n\n| | Atomic rules (default) | Blueprints |\n|---|---|---|\n| **Scope** | One motion pattern, such as a single entrance, stagger or effect | A whole multi-phase scene template |\n| **Workflow** | Pick 2–4 rules from `rules-index.md` and glue them into one paused GSAP timeline | Load one recipe that already defines the phase pipeline |\n| **Lookup** | `rules-index.md` → `rules/.md` (HTML / CSS / GSAP recipe) | `blueprints-index.md` → `blueprints/.md` |\n| **Cost** | Faster, less code | More code, but saves time when the choreography is complex |\n| **Best for** | Most scenes, and anything without a matching template | Scenes matching an existing template, or complex 4–5 phase sequences |\n\nComposing atomic rules is the default because it's faster and lighter. A blueprint only wins when its pre-built phase structure saves more effort than its extra size costs.\n\n## Constraints that apply either way\n\nA blueprint doesn't exempt you from the core contract:\n\n- **Timeline:** use one paused timeline, and register it only after it's fully built, including when the build runs inside an async callback like `document.fonts.ready`.\n- **Duration:** `data-duration` governs length.\n- **Determinism:** no `Math.random`, `Date.now` or `performance.now`, and no `repeat: -1` without a finite root duration.\n- **Visibility:** no `display` or raw `visibility` tweens.\n- **Clips:** no page-load `gsap.set` on later-scene clips, and leave `.clip` lifecycle to the framework.\n- **Layout:** pre-calculate layout constants at setup, and never call `getBoundingClientRect()` at tween time.\n- **Motion properties:** spatial motion uses only `x`, `y`, `scale` and `rotation`, never `width`, `height`, `top` or `left`.\n\nAfter authoring, you can audit the result's choreography with `scripts/animation-map.mjs`. It flags dead zones, stagger inconsistencies and lifecycle warnings.",
"8661dc887d5332d447660e6d42a260e651cddbb8a3f42a7e6e3d4f43c6b717dd": "# Blueprints vs. Atomic Rules\n\n**Recommendation:** Since the requested scene already matches the complex brand-reveal template, start from the **blueprint**. Then use atomic rules only to adjust the details that differ from the template.\n\n## When a blueprint is appropriate\n\nA blueprint is a pre-composed, multi-part recipe for a whole scene type. It fits when:\n\n- **The request maps to a known scene pattern.** A brand reveal has a recognizable structure: build-up, logo entrance, tagline, hold or resolve.\n- **Many elements must coordinate.** Timing, easing, layering, camera moves, and audio cues all depend on each other. Getting those relationships right from scratch is the hard part, and the blueprint already encodes them.\n- **Consistency matters.** Reusing a proven structure gives predictable pacing and quality across scenes or deliverables.\n- **Speed matters more than novelty.** You fill in parameters such as logo, colors, copy, and duration instead of designing the choreography.\n\nA blueprint is less appropriate when:\n\n- the scene only partly resembles the template,\n- the template would force a structure the user didn't ask for, or\n- the request is a small, isolated effect where the blueprint adds unnecessary layers.\n\n## How it differs from atomic rules\n\n| | **Blueprint** | **Atomic rules** |\n|---|---|---|\n| **Scope** | A whole scene or sequence | A single behavior or constraint, e.g. \"ease-out on entrances\" or \"logo stays in the safe area\" |\n| **Composition** | Pre-assembled; the relationships between parts are built in | Independent units you combine yourself |\n| **What it encodes** | Structure, ordering, and timing between elements | Local correctness of one property or element |\n| **Flexibility** | Lower: you customize parameters within a fixed shape | Higher: any arrangement is possible |\n| **Effort and risk** | Low effort, low risk of incoherent pacing | More effort, and you own the overall coherence |\n| **Best for** | Recognized, complex scene types | Novel scenes, small tweaks, or overriding parts of a blueprint |\n\n## How they work together\n\nThe two are layered, not competing:\n\n1. **Select the blueprint** for the overall skeleton of the brand reveal.\n2. **Parameterize it** with brand assets, copy, palette, and duration.\n3. **Apply atomic rules** for local overrides or extra constraints, such as a different easing on the tagline or an accessibility contrast rule.\n4. **Check for conflicts.** If an atomic change breaks the blueprint's internal timing, either adjust the dependent parts or decide the scene has diverged enough to build it from atomic rules instead.\n\nIn short, the blueprint gives you the scene's architecture, and atomic rules govern individual parts. Since this scene already matches the template, building it up from atomic rules would mean rebuilding coordination the blueprint already provides.",
"ebb930ce5d05f2b91aef6b8ae27c7675bc3919130f22f1fca838880a4bc4f887": "Since the scene already matches a complex brand-reveal template, a **blueprint** is the right choice. Here is why, and how blueprints differ from atomic rules.\n\n## When a blueprint is appropriate\n\nUse a blueprint when the request maps onto a **known, multi-part composition** whose pieces have to be coordinated. A brand reveal is a good example:\n\n- **Several elements move together.** Logo, wordmark, tagline, background and light sweeps all depend on one another's timing.\n- **The structure is proven.** The template has a tested sequence (build-up, reveal, hold, resolve) with pacing and easing that already work.\n- **Consistency matters more than novelty.** Brand work needs predictable, on-brand results, not improvisation.\n- **The variables are few and well-defined.** You mainly swap in assets (logo, colors, copy, duration) and leave the choreography alone.\n\nIn those cases, building the scene from scratch out of individual rules adds risk without adding value. You'd have to recreate the timing relationships, layer order and transitions that the template already handles.\n\nAtomic rules are the better fit when:\n\n- the scene is new or only partly matches any template,\n- you need to change one isolated behavior, such as a single fade or easing curve, or\n- forcing the request into a template would distort what was actually asked.\n\n## How a blueprint differs from atomic rules\n\n| Aspect | Blueprint | Atomic rules |\n|---|---|---|\n| **Scope** | A whole scene or sequence | One small behavior or constraint |\n| **Unit of reuse** | A composition of many coordinated parts | Independent building blocks |\n| **Relationships** | Timing, layering and dependencies are encoded | Each rule stands alone, and you compose them yourself |\n| **Customization** | Fill in parameters and slots within a fixed structure | Freely combine and reorder |\n| **Predictability** | High, because the result follows a proven pattern | Varies with how the rules are combined |\n| **Flexibility** | Lower, since it is opinionated about structure | Higher, since it is unopinionated |\n| **Best for** | Recurring, complex, high-stakes patterns | New scenes, fine-grained tweaks, edge cases |\n\nIn short, atomic rules are the vocabulary and a blueprint is a pre-written sentence built from that vocabulary. A blueprint usually *contains* atomic rules, already arranged and tuned to work together.\n\n## Applied here\n\nBecause the request already matches the brand-reveal template:\n\n1. **Start from the blueprint** so the coordinated choreography stays intact.\n2. **Parameterize it** with the brand's assets, palette, copy and target duration.\n3. **Use atomic rules only for deviations.** If the request needs something the template doesn't cover, such as a different logo entrance, override that one piece with a targeted rule and keep the rest of the structure.\n\nThis keeps the reliability of the template while still meeting any specific requirements.",
"7d326d0ac107fb2578b6d22d5679de13c5e9f4048e3b491045d0d2be277c335a": "A blueprint fits here because the requested scene already matches a complex brand-reveal template. Here's when to use one and how it differs from atomic rules. You didn't supply any framework-specific docs, so this describes the general pattern rather than one tool's exact API.\n\n## When a blueprint is appropriate\n\nUse a blueprint when the request matches a known, multi-part composition as a whole, not just in its pieces. A brand reveal is the classic case:\n\n- **Several coordinated elements**: logo, tagline, background, particles or light sweep, sound hit.\n- **Choreographed timing**: build-up, reveal moment, hold, settle. The relative offsets matter more than any single animation.\n- **Proven structure**: the arrangement has already been tuned to look right, so rebuilding it from scratch risks drifting from a known-good result.\n- **Variation is in parameters, not structure**: the user mainly changes the logo asset, brand colors, text, duration, or easing intensity.\n\nSignals that a blueprint fits:\n- The request names or clearly describes the template's pattern.\n- You'd otherwise need to combine many rules in a specific order.\n- Consistency across outputs, such as a series of reveals for different brands, is valuable.\n\nSignals it doesn't fit:\n- The scene only loosely resembles the template.\n- The user wants a novel structure.\n- Adapting the blueprint would mean overriding most of it. At that point, compose from atomic rules instead.\n\n## How it differs from atomic rules\n\n| | Atomic rules | Blueprint |\n|---|---|---|\n| **Scope** | One concern, e.g. \"fade in with ease-out,\" \"keep text inside safe margins,\" \"spring config for logo scale\" | A whole scene: layers, sequencing, and timing relationships |\n| **Composition** | You assemble them yourself, deciding order and interaction | Pre-assembled; the relationships are already encoded |\n| **Reuse unit** | Small and widely applicable across many scene types | Large and specific to one scene archetype |\n| **Customization** | Choose and combine rules | Fill in slots or parameters (assets, colors, copy, durations) |\n| **Risk** | Flexible, but more room for inconsistent or incoherent results | Consistent, but rigid; a poor fit if forced onto the wrong scene |\n| **Relationship** | Building blocks | Usually built from atomic rules and still subject to them |\n\n## Practical approach for this case\n\n1. **Start from the brand-reveal blueprint** as the scene skeleton.\n2. **Parameterize** it with the user's assets, palette, text, and timing.\n3. **Apply atomic rules** for anything outside the blueprint's slots. Examples: a different easing on the tagline, or accessibility constraints like contrast and motion intensity.\n4. **Don't break the blueprint's core timing relationships** unless the user asks. Those relationships are the reason to use the blueprint.\n5. **Fall back to atomic composition** if the requested changes start replacing the structure rather than filling it.\n\nIn short, a blueprint answers \"what does this kind of scene look like as a whole.\" Atomic rules answer \"how should each individual piece behave.\" Use the blueprint when the whole is already known, and use atomic rules to refine it or to build when no good blueprint fits.",
"c4d50c73ff9c2b95cf86a17f4782a32197ec5dc12d5a664815dab754ca6581ea": "Since the requested scene already matches a complex brand-reveal template, start from that **blueprint** rather than composing it from scratch with atomic rules.\n\n## When a blueprint is appropriate\n\nUse a blueprint when:\n\n- **The scene matches a known, multi-part pattern.** A brand reveal usually combines a logo entrance, background treatment, typography timing, easing, and a final hold. A blueprint captures that whole arrangement.\n- **The parts depend on each other.** The logo lands on a beat, then the tagline fades in after it, then the background settles. A blueprint preserves those relationships, which are easy to get wrong when rebuilt piece by piece.\n- **Consistency matters.** Reusing a proven structure gives predictable, on-brand results across many renders or variants.\n- **Speed matters more than novelty.** You customize a few slots (logo asset, colors, copy, duration) instead of designing the choreography.\n\nAvoid a blueprint, or depart from it, when the request differs from the template in ways that would mean fighting its structure. Examples include a different narrative order, an unusual aspect ratio or pacing, or effects the template doesn't account for. Forcing a poor match usually produces worse results than building from atomic rules.\n\n## How it differs from atomic rules\n\n| | Atomic rules | Blueprint |\n|---|---|---|\n| **Scope** | One focused piece of guidance, such as how to animate an opacity fade, sequence elements, or apply a spring easing | A complete, pre-arranged scene composed of many such pieces |\n| **Granularity** | Building blocks | An assembled structure |\n| **Decisions left to you** | Almost all composition, timing, and layout | Mostly parameter choices and small adjustments |\n| **Flexibility** | High: any scene can be built | Lower: optimized for one scene type |\n| **Risk** | Inconsistent or unpolished results if the composition is weak | Mismatch if the request doesn't truly fit the template |\n| **Best for** | Novel, unusual, or simple one-off scenes | Recurring, well-understood, complex scenes |\n\n## Practical approach for this case\n\n1. Start from the brand-reveal blueprint as the base.\n2. Fill its parameters with the brand's logo, palette, typography, copy, and duration.\n3. Use atomic rules only for local adjustments, such as changing one element's easing or adding an accent animation. Keep the blueprint's overall timing structure intact.\n4. If the adjustments start to restructure the scene's core sequence, reconsider. A custom build from atomic rules may then be cleaner.\n\nIn short, atomic rules are the vocabulary, and a blueprint is a ready-made sentence. Here the sentence already says what you need, so reuse it and edit the words."
},
"draws": [
{
"id": "timeline",
"mode": "with_skill",
"draw_index": 0,
"generation_hash": "12afa44ffd74e524c1e446c552820686e7cce366a8708d630509eafb989c4722",
"answer_sha256": "12afa44ffd74e524c1e446c552820686e7cce366a8708d630509eafb989c4722",
"status": "measured",
"judge_outputs": [
"{\"score\": 1.0, \"pass\": true, \"reason\": \"Uses a single paused GSAP timeline (criterion 1), a small set of motion rules (fade, slide, scale, stagger) (criterion 2), deterministic fixed values with no random or wall-clock use (criteria 3 and 4 met).\"}",
"{\"score\": 1.0, \"pass\": true, \"reason\": \"Uses one paused GSAP timeline, a small set of deterministic motion rules with explicit fromTo, and no wall-clock timers or autoplay, meeting all four criteria.\"}",
"{\"score\": 1.0, \"pass\": true, \"reason\": \"Uses a single paused GSAP timeline (criterion 1), a small set of motion rules (fade/slide/scale/stagger with power eases) (criterion 2), deterministic seek-safe fromTo tweens with no random/time functions (criterion 3), and no autoplay or wall-clock timers (criterion 4).\"}",
"{\"score\": 1.0, \"pass\": true, \"reason\": \"Uses one paused GSAP timeline (criterion 1), a small set of appropriate rules like fromTo, stagger, and transforms/opacity (criterion 2), deterministic values with no random or clock calls (criterion 3), and no wall-clock timers or autoplay (criterion 4).\"}",
"{\"score\": 1.0, \"pass\": true, \"reason\": \"Uses one paused GSAP timeline (criterion 1), a small set of motion rules (fade/slide/scale with fixed stagger) (criterion 2), deterministic fixed offsets with no randomness (criterion 3), and no wall-clock timers or autoplay (criterion 4).\"}"
]
},
{
"id": "timeline",
"mode": "with_skill",
"draw_index": 1,
"generation_hash": "f05fb358b23af4747b47d1caff7f2981ca6a13836f0cb2f9a5344a7a461b9920",
"answer_sha256": "f05fb358b23af4747b47d1caff7f2981ca6a13836f0cb2f9a5344a7a461b9920",
"status": "measured",
"judge_outputs": [
"{\"score\": 1.0, \"pass\": true, \"reason\": \"Uses one paused GSAP timeline, a small set of fitting motions (masked word rise, rule scale, staggered card lift), fromTo start states with absolute positions for deterministic seeking, and no timers or autoplay.\"}",
"{\"score\": 1.0, \"pass\": true, \"reason\": \"Uses a single paused GSAP timeline (criterion 1), a small set of motion rules (mask rise, rule scale, card lift/fade) (criterion 2), deterministic fromTo tweens with absolute positions and no randomness (criterion 3), and no wall-clock timers or autoplay (criterion 4).\"}",
"{\"score\": 1.0, \"pass\": true, \"reason\": \"Uses one paused GSAP timeline, a small set of fitting motion rules (mask word-rise, rule scale, card lift/fade), explicit fromTo states for deterministic seeking, and no timers, repeats, or autoplay.\"}",
"{\"score\": 1.0, \"pass\": true, \"reason\": \"Uses one paused GSAP timeline, a small set of fitting motion rules (word rise, rule scale, card lift), explicit fromTo tweens with no randomness, and no timers or autoplay.\"}",
"{\"score\": 1.0, \"pass\": true, \"reason\": \"Uses one paused GSAP timeline (criterion 1), a small set of motion rules (mask rise, rule scale, card lift/fade) (criterion 2), fromTo with explicit absolute positions for seek-determinism (criterion 3), and explicitly avoids random, Date.now, repeat:-1, and autoplay (criterion 4).\"}"
]
},
{
"id": "timeline",
"mode": "with_skill",
"draw_index": 2,
"generation_hash": "c364e18b91141283adde4b1411a743d8c3e1a81ab8dcdc44fa24564c22f43ac5",
"answer_sha256": "c364e18b91141283adde4b1411a743d8c3e1a81ab8dcdc44fa24564c22f43ac5",
"status": "measured",
"judge_outputs": [
"{\"score\": 1.0, \"pass\": true, \"reason\": \"Uses one paused GSAP timeline with a small set of motion rules (mask slide, scaleX rule, staggered rise), deterministic fromTo values with no random or clock input, and no wall-clock timers or autoplay.\"}",
"{\"score\": 1.0, \"pass\": true, \"reason\": \"Uses one paused GSAP timeline, a small set of fromTo motion rules, explicitly avoids random/Date/performance timers, and registers the timeline without autoplay, meeting all four criteria.\"}",
"{\"score\": 1.0, \"pass\": true, \"reason\": \"It uses one paused GSAP timeline, a small set of fitting motion rules (heading mask, rule scale, card rise), deterministic fromTo tweens with no random or clock calls, and no independent autoplay or wall-clock timers.\"}",
"{\"score\": 1.0, \"pass\": true, \"reason\": \"Uses one paused GSAP timeline (criterion 1), a small set of appropriate motion rules (fade/rise, mask slide, scaleX rule, stagger) (criterion 2), deterministic fromTo tweens with no random/Date/performance calls (criterion 3), and no wall-clock timers or independent autoplay (criterion 4).\"}",
"{\"score\": 1.0, \"pass\": true, \"reason\": \"Uses one paused GSAP timeline (criterion 1), a small set of transform/opacity reveal and stagger rules (2), fixed deterministic values with no random or clock calls (3), and no independent autoplay or wall-clock timers (4).\"}"
]
},
{
"id": "timeline",
"mode": "baseline",
"draw_index": 0,
"generation_hash": "a270f9c8174b130c9fea8b42f40a8735ef2651da7893434894c397bf920319b5",
"answer_sha256": "a270f9c8174b130c9fea8b42f40a8735ef2651da7893434894c397bf920319b5",
"status": "measured",
"judge_outputs": [
"{\"score\": 1.0, \"pass\": true, \"reason\": \"Uses one paused GSAP timeline, a small appropriate set of motion rules, fromTo and absolute positions for deterministic seeking, and no setTimeout, rAF, random, or autoplay.\"}",
"{\"score\": 1.0, \"pass\": true, \"reason\": \"Uses one paused GSAP timeline, a small set of appropriate motion rules, fromTo and absolute positions for seek-determinism, and avoids wall-clock timers, rAF, and autoplay.\"}",
"{\"score\": 1.0, \"pass\": true, \"reason\": \"Uses a single paused GSAP timeline, a small set of motion rules (wipe, rise, fade, scale, stagger), absolute positions with fromTo, and no timers or autoplay, meeting all four criteria.\"}",
"{\"score\": 1.0, \"pass\": true, \"reason\": \"Uses one paused GSAP timeline, a small set of motion rules (wipe, rise, fade, scale, stagger), absolute positions with fromTo for seek-safe determinism, and explicitly avoids timers and autoplay.\"}",
"{\"score\": 1.0, \"pass\": true, \"reason\": \"Uses a single paused GSAP timeline (criterion 1), a small set of motion rules (mask wipe, rise, fade, scale, stagger) (criterion 2), deterministic fromTo tweens with no randomness or side effects (criterion 3), and explicitly avoids setTimeout, rAF, CSS keyframes, and autoplay (criterion 4).\"}"
]
},
{
"id": "timeline",
"mode": "baseline",
"draw_index": 1,
"generation_hash": "5acecb1920234bb154c47ed9e9a8e0e7b7a502955a043212daa96fadf1e71cd7",
"answer_sha256": "5acecb1920234bb154c47ed9e9a8e0e7b7a502955a043212daa96fadf1e71cd7",
"status": "measured",
"judge_outputs": [
"{\"score\": 1.0, \"pass\": true, \"reason\": \"Uses a single paused timeline (criterion 1), a small set of seek-safe motion rules (fromTo, transform/opacity/clip-path only) (criterion 2), deterministic seeking with explicit start/end values and no randomness (criterion 3), and avoids wall-clock timers and autoplay (criterion 4).\"}",
"{\"score\": 1.0, \"pass\": true, \"reason\": \"Uses a single paused timeline (criterion 1), a small set of motion rules (clip-path wipe, fade, rise, stagger) (criterion 2), deterministic fromTo tweens with explicit values and no transitions or randomness for seeking (criterion 3), and avoids wall-clock timers and autoplay (criterion 4).\"}",
"{\"score\": 1.0, \"pass\": true, \"reason\": \"Uses a single paused timeline (criterion 1), a small set of motion rules (fade, rise, clip-path wipe, stagger) (criterion 2), explicit fromTo values so seeking is deterministic (criterion 3), and explicitly forbids setTimeout, rAF loops, CSS transitions and autoplay (criterion 4).\"}",
"{\"score\": 1.0, \"pass\": true, \"reason\": \"Uses a single paused timeline (criterion 1), a small set of motion rules (fade, rise, clip-path wipe, stagger) (criterion 2), keeps motion deterministic under seeking via fromTo and explicit states (criterion 3), and avoids wall-clock timers and autoplay (criterion 4).\"}",
"{\"score\": 0.75, \"pass\": true, \"reason\": \"Meets single paused timeline (criterion 1), a small set of appropriate motion rules (2), and deterministic seeking with no wall-clock timers or autoplay (3, 4); the response does not clearly satisfy all criteria strictly, but the rubric points are largely covered, so this is 0.75 rather than 1.0.\"}"
]
},
{
"id": "timeline",
"mode": "baseline",
"draw_index": 2,
"generation_hash": "ba0bdbea16c8f6aa60ce537adcd122b1c092612f3c627b21b6952803fe3aa351",
"answer_sha256": "ba0bdbea16c8f6aa60ce537adcd122b1c092612f3c627b21b6952803fe3aa351",
"status": "measured",
"judge_outputs": [
"{\"score\": 1.0, \"pass\": true, \"reason\": \"Uses one paused GSAP timeline (criterion 1), a small set of seek-safe rules (fromTo, transforms/opacity only, no CSS transitions or keyframes) (criterion 2), deterministic seeking with no unseeded randomness (criterion 3), and no wall-clock timers or autoplay (criterion 4).\"}",
"{\"score\": 1.0, \"pass\": true, \"reason\": \"Uses a single paused GSAP timeline (criterion 1), a small set of motion rules (fade/rise/scale/wipe/rule draw) with explicit fromTo states (criterion 2), explicitly bans random, CSS transitions, and rAF/setTimeout to keep seeking deterministic (criterion 3), and avoids autoplay via no play() call (criterion 4).\"}",
"{\"score\": 1.0, \"pass\": true, \"reason\": \"Uses a single paused GSAP timeline, sets a small set of seek-safe rules (transforms/opacity/clip-path, fromTo, no CSS transitions), keeps motion deterministic with no randomness, and avoids setTimeout/rAF/autoplay via play() prohibition.\"}",
"{\"score\": 1.0, \"pass\": true, \"reason\": \"Uses a single paused GSAP timeline (criterion 1), a small set of seek-safe rules like fromTo and transform/opacity-only motion (criterion 2), explicitly excludes unseeded randomness and CSS transitions for deterministic seeking (criterion 3), and avoids setTimeout, rAF loops, and autoplay (criterion 4).\"}",
"{\"score\": 1.0, \"pass\": true, \"reason\": \"Uses one paused GSAP timeline, a small set of transform/opacity rules, deterministic fromTo tweens with no randomness, and avoids setTimeout, rAF loops, and play(). All four criteria met.\"}"
]
},
{
"id": "runtime",
"mode": "with_skill",
"draw_index": 0,
"generation_hash": "e010738d0adba8b124b2611f67bc62b0e0fc7c977d06971a161e71e2ccf183e8",
"answer_sha256": "e010738d0adba8b124b2611f67bc62b0e0fc7c977d06971a161e71e2ccf183e8",
"status": "measured",
"judge_outputs": [
"{\"score\": 0.75, \"pass\": true, \"reason\": \"Routes to adapters/lottie.md and ties seeking to the single paused timeline and window.__hfLottie registration (points 1-2); repeatable seeking is only implicit via determinism and scrubbing (point 3 weak); does not replace the renderer (point 4).\"}",
"{\"score\": 0.75, \"pass\": true, \"reason\": \"Routes to adapters/lottie.md and ties seeking to the single paused composition timeline (criteria 1 and 2), and checks registration on window.__hfLottie so seeking is repeatable (criterion 3); it does not suggest replacing the renderer (criterion 4), but its registration-focused check and lack of explicit repeatable-seek verification make criterion 3 only partly clear.\"}",
"{\"score\": 0.75, \"pass\": true, \"reason\": \"Routes to adapters/lottie.md (1), ties seeking to the paused composition timeline (2), and checks registration on window.__hfLottie for seekability (3). Point 4 is never explicitly addressed, so it is not credited.\"}",
"{\"score\": 1.0, \"pass\": true, \"reason\": \"Routes to adapters/lottie.md, ties playback to the paused composition timeline and window.__hfLottie seeking, covers determinism and scrubbing, and does not propose replacing the renderer.\"}",
"{\"score\": 0.75, \"pass\": true, \"reason\": \"Routes to adapters/lottie.md, ties seeking to the single paused timeline, and checks window.__hfLottie registration for drift and scrubbing; it never explicitly warns against swapping the renderer, so criterion 4 is only implicitly met.\"}"
]
},
{
"id": "runtime",
"mode": "with_skill",
"draw_index": 1,
"generation_hash": "0177f00c036b698cc8224b546562b0f5a9b522489b24e1e38f9aad20d80e76f3",
"answer_sha256": "0177f00c036b698cc8224b546562b0f5a9b522489b24e1e38f9aad20d80e76f3",
"status": "measured",
"judge_outputs": [
"{\"score\": 0.75, \"pass\": true, \"reason\": \"Routes to adapters/lottie.md, ties window.__hfLottie registration to timeline seeking, and checks deterministic seek-safety; it never explicitly rules out replacing the renderer, so that criterion is only implicitly met.\"}",
"{\"score\": 0.75, \"pass\": true, \"reason\": \"Routes to adapters/lottie.md (criterion 1), connects registration on window.__hfLottie to timeline seeking (criterion 2), and checks seek-safe deterministic behavior (criterion 3); does not replace the renderer (criterion 4 met), but the response is arguably strong on all four, so this is a near-full score with minor ambiguity around 'repeatable seeking' wording.\"}",
"{\n \"score\": 1.0,\n \"pass\": true,\n \"reason\": \"Routes to adapters/lottie.md, ties window.__hfLottie registration to timeline seeking, requires seek-safe deterministic behavior, and keeps Lottie without suggesting a renderer swap.\"\n}",
"{\"score\": 0.75, \"pass\": true, \"reason\": \"Routes to adapters/lottie.md and ties registration on window.__hfLottie to timeline seeking, and covers deterministic, seek-safe behavior. It never explicitly warns against replacing the renderer, so that criterion is only implicitly met.\"}",
"{\"score\": 0.75, \"pass\": true, \"reason\": \"Routes to adapters/lottie.md (criterion 1), connects registration on window.__hfLottie to the timeline seek pass (criterion 2), and checks deterministic seek-safe behavior (criterion 3); it does not replace the renderer (criterion 4 likely met but not explicitly stated), so roughly 0.75-1.0 range; scored 0.75 as criterion 4 is only implicitly addressed.\"}"
]
},
{
"id": "runtime",
"mode": "with_skill",
"draw_index": 2,
"generation_hash": "5e61bc6223da328f7065a4495814bfd03d6ce9cc6f963595fc32d1075b4c7bf3",
"answer_sha256": "5e61bc6223da328f7065a4495814bfd03d6ce9cc6f963595fc32d1075b4c7bf3",
"status": "measured",
"judge_outputs": [
"{\"score\": 1.0, \"pass\": true, \"reason\": \"Routes to adapters/lottie.md, ties playback to the paused composition timeline and window.__hfLottie registration, and checks seek drift via finite duration and no wall-clock timing; it never suggests replacing the renderer.\"}",
"{\"score\": 0.75, \"pass\": true, \"reason\": \"Routes to adapters/lottie.md, ties playback to the paused timeline via window.__hfLottie, and covers repeatable seeking (finite duration, no wall-clock timing). It never addresses whether to avoid replacing the renderer, so criterion 4 is unmet.\"}",
"{\"score\": 0.75, \"pass\": true, \"reason\": \"Meets criteria 1-3: routes to adapters/lottie.md, ties playback to the paused composition timeline and seek position, and checks for wall-clock timing. Criterion 4 is never addressed; it is only implicitly satisfied since no renderer replacement is suggested.\"}",
"{\"score\": 1.0, \"pass\": true, \"reason\": \"Routes to adapters/lottie.md, ties playback to the paused composition timeline via window.__hfLottie, checks finite duration and no wall-clock timing for repeatable seeking, and never suggests replacing the renderer.\"}",
"{\"score\": 0.75, \"pass\": true, \"reason\": \"Routes to adapters/lottie.md and ties playback to the timeline via window.__hfLottie and seek behavior (criteria 1, 2, 3). It never explicitly states against replacing the renderer (criterion 4), so that criterion is not credited.\"}"
]
},
{
"id": "runtime",
"mode": "baseline",
"draw_index": 0,
"generation_hash": "9346762dbd39f3fcbf0ab2bc90b48d6fd06fd1dd33d067a4b5067ddeb8e54ff3",
"answer_sha256": "9346762dbd39f3fcbf0ab2bc90b48d6fd06fd1dd33d067a4b5067ddeb8e54ff3",
"status": "measured",
"judge_outputs": [
"{\"score\": 0.75, \"pass\": true, \"reason\": \"Routes to the Lottie adapter guidance and ties playback to the host timeline with frame-based seeking (criteria 1, 2, 3). It never explicitly says to keep the existing renderer, so criterion 4 is only implicitly met.\"}",
"{\"score\": 0.75, \"pass\": true, \"reason\": \"Routes to the Lottie adapter guide, ties playback to the host timeline, and avoids replacing the renderer. It does not explicitly check repeatable seeking or determinism.\"}",
"{\"score\": 0.75, \"pass\": true, \"reason\": \"Routes to the Lottie adapter guide and ties playback to the host timeline with timeline-driven seeking, and does not replace the renderer. It never explicitly checks repeatable seeking, so that criterion is missed.\"}",
"{\"score\": 0.75, \"pass\": true, \"reason\": \"Routes to the Lottie adapter guide, connects playback to the host timeline via goToAndStop mapping, and avoids recommending a renderer swap; it misses an explicit check for repeatable seeking.\"}",
"{\"score\": 0.75, \"pass\": true, \"reason\": \"Routes to a Lottie adapter guide and connects playback to the host timeline (autoplay off, goToAndStop mapping), and does not replace the renderer. It never explicitly checks repeatable seeking, so that criterion is missed.\"}"
]
},
{
"id": "runtime",
"mode": "baseline",
"draw_index": 1,
"generation_hash": "8142d7dd6029c236e37a45c41337b2a5367796a1df2512d863962b939d75670f",
"answer_sha256": "8142d7dd6029c236e37a45c41337b2a5367796a1df2512d863962b939d75670f",
"status": "measured",
"judge_outputs": [
"{\"score\": 0.75, \"pass\": true, \"reason\": \"Meets points 2 (host frame drives playback), 3 (deterministic per-frame seeking), and 4 (no renderer swap). Misses point 1: it gives generic Lottie guidance rather than routing to a named Lottie adapter.\"}",
"{\"score\": 0.75, \"pass\": true, \"reason\": \"Meets points 2 (playback driven by the host's current frame), 3 (deterministic seeking, autoplay off, per-frame seeks) and 4 (keeps the renderer). Misses point 1: it gives generic Lottie guidance and never names a specific Lottie adapter.\"}",
"{\"score\": 0.5, \"pass\": false, \"reason\": \"Meets connecting playback to the timeline via useCurrentFrame and repeatable seeking via disabled autoplay. Misses routing to the Lottie adapter (names generic Lottie docs, not the hyperframes adapter) and assumes Remotion without addressing renderer replacement.\"}",
"{\"score\": 0.5, \"pass\": false, \"reason\": \"Meets connecting playback to the timeline and repeatable seeking; misses routing to the Lottie adapter in the actual skill and substitutes Remotion as the renderer.\"}",
"{\"score\": 1.0, \"pass\": true, \"reason\": \"Routes to Lottie-specific guidance and @remotion/lottie docs, ties playback to the frame timeline via useCurrentFrame, checks fps/fr and imperative seeking, and keeps Remotion rather than replacing the renderer.\"}"
]
},
{
"id": "runtime",
"mode": "baseline",
"draw_index": 2,
"generation_hash": "14262483fe99a3f3ebf6710d33f23b1fb9672aeac3936050e456afd94bccda44",
"answer_sha256": "14262483fe99a3f3ebf6710d33f23b1fb9672aeac3936050e456afd94bccda44",
"status": "measured",
"judge_outputs": [
"{\"score\": 0.75, \"pass\": true, \"reason\": \"Met criteria 2 (playback driven by host timeline, autoplay off), 3 (deterministic seek to time t), and 4 (no renderer replacement). Criterion 1 is only loosely met: it names a generic Lottie adapter without routing to the specific guidance.\"}",
"{\"score\": 0.75, \"pass\": true, \"reason\": \"Routes to Lottie adapter guidance, ties seeking to the host timeline, and requires deterministic frame-accurate seeking (points 1-3); never names the specific skill or explicitly rules out replacing the renderer (point 4 only implicitly met).\"}",
"{\"score\": 0.75, \"pass\": true, \"reason\": \"Met criteria 2 (playback tied to host timeline), 3 (deterministic repeatable seeking), and 4 (no renderer replacement); criterion 1 is only generically routed to a 'Lottie adapter or integration guidance' without naming a specific document.\"}",
"{\"score\": 0.75, \"pass\": true, \"reason\": \"Met routing to the Lottie adapter guidance, connecting playback to the host timeline, and repeatable deterministic seeking; missed the rubric point about not replacing the renderer.\"}",
"{\"score\": 0.75, \"pass\": true, \"reason\": \"Routes to Lottie adapter guidance, ties seeking to the host timeline, and requires deterministic repeatable seeks (points 1-3). It never addresses avoiding renderer replacement (point 4).\"}"
]
},
{
"id": "template",
"mode": "with_skill",
"draw_index": 0,
"generation_hash": "6a1231ec089660ddf2fa9433c2b74cca25cd1b9cea8fa8c886eb5fc59763f173",
"answer_sha256": "6a1231ec089660ddf2fa9433c2b74cca25cd1b9cea8fa8c886eb5fc59763f173",
"status": "measured",
"judge_outputs": [
"{\"score\": 1.0, \"pass\": true, \"reason\": \"Recommends the matching brand-reveal blueprint, calls atomic rules small building blocks, keeps the paused-timeline seek-safe contract, and warns against loading blueprints without need.\"}",
"{\"score\": 1.0, \"pass\": true, \"reason\": \"Recommends loading the matching brand-reveal blueprint, describes atomic rules as smaller building blocks, restates the paused-timeline seek-safe contract, and advises against loading blueprints without need.\"}",
"{\"score\": 1.0, \"pass\": true, \"reason\": \"Recommends loading the matching brand-reveal blueprint for multi-phase choreography, describes atomic rules as small building blocks, keeps the paused-timeline seek-safe contract, and avoids loading unrelated templates.\"}",
"{\"score\": 1.0, \"pass\": true, \"reason\": \"Recommends the matching brand-reveal blueprint for multi-phase choreography, describes atomic rules as small combinable pieces, keeps the paused-timeline seek-safe contract, and advises against opening blueprints without need.\"}",
"{\"score\": 1.0, \"pass\": true, \"reason\": \"Recommends the matching brand-reveal blueprint for multi-phase choreography, describes atomic rules as smaller combinable building blocks, keeps the paused-timeline seek-safe contract, and only loads the blueprint without touching unrelated templates.\"}"
]
},
{
"id": "template",
"mode": "with_skill",
"draw_index": 1,
"generation_hash": "57f6c556ffde4fadc7e09922e0e4869b4543d570d4db0a0e42a67171a89c0c59",
"answer_sha256": "57f6c556ffde4fadc7e09922e0e4869b4543d570d4db0a0e42a67171a89c0c59",
"status": "measured",
"judge_outputs": [
"{\"score\": 1.0, \"pass\": true, \"reason\": \"Recommends the matching brand-reveal blueprint, describes atomic rules as smaller single-motion building blocks, restates the paused-timeline seek-safe contract, and warns against loading blueprints speculatively.\"}",
"{\"score\": 1.0, \"pass\": true, \"reason\": \"Selects the matching brand-reveal blueprint for multi-phase choreography, frames atomic rules as single-motion building blocks, restates the paused-timeline contract, and warns against speculative template loading.\"}",
"{\"score\": 1.0, \"pass\": true, \"reason\": \"Recommends the matching brand-reveal blueprint, frames atomic rules as single-motion building blocks, restates the paused-timeline and seek-safe contract, and says to load only the needed recipe.\"}",
"{\"score\": 1.0, \"pass\": true, \"reason\": \"Meets all four criteria: recommends the matching brand-reveal blueprint for multi-phase choreography, frames atomic rules as single-motion building blocks, restates the paused-timeline seek-safe contract, and advises against speculative template loading.\"}",
"{\"score\": 1.0, \"pass\": true, \"reason\": \"Recommends the matching brand-reveal blueprint, describes atomic rules as single-motion building blocks, keeps the paused-timeline contract, and warns against loading templates speculatively.\"}"
]
},
{
"id": "template",
"mode": "with_skill",
"draw_index": 2,
"generation_hash": "bffe1ccacde856175ecdbf1f2ae624e55f07472d84b6afb5993a3f4c6d951fd8",
"answer_sha256": "bffe1ccacde856175ecdbf1f2ae624e55f07472d84b6afb5993a3f4c6d951fd8",
"status": "measured",
"judge_outputs": [
"{\"score\": 1.0, \"pass\": true, \"reason\": \"Met all four: it recommends the matching brand-reveal blueprint, frames atomic rules as single-pattern building blocks, keeps the seek-safe timeline contract, and avoids loading unrelated templates.\"}",
"{\"score\": 1.0, \"pass\": true, \"reason\": \"Recommends the matching brand-reveal blueprint, describes atomic rules as single-motion building blocks, restates the seek-safe timeline contract, and says to load only the specific recipe needed.\"}",
"{\"score\": 1.0, \"pass\": true, \"reason\": \"Recommends the matching brand-reveal blueprint for the multi-phase scene, describes atomic rules as single-pattern building blocks, keeps the paused-timeline determinism contract, and says not to load templates speculatively.\"}",
"{\"score\": 1.0, \"pass\": true, \"reason\": \"Recommends the matching brand-reveal blueprint for the multi-phase scene, describes atomic rules as smaller pieces glued together, keeps the paused-timeline seek-safe constraints, and says not to load templates speculatively.\"}",
"{\"score\": 1.0, \"pass\": true, \"reason\": \"Recommends the matching brand-reveal blueprint for the multi-phase scene (criterion 1), describes atomic rules as smaller building blocks/default composition (criterion 2), keeps the seek-safe paused-timeline contract (criterion 3), and avoids loading unrelated templates, reading only the specific recipe (criterion 4).\"}"
]
},
{
"id": "template",
"mode": "baseline",
"draw_index": 0,
"generation_hash": "8661dc887d5332d447660e6d42a260e651cddbb8a3f42a7e6e3d4f43c6b717dd",
"answer_sha256": "8661dc887d5332d447660e6d42a260e651cddbb8a3f42a7e6e3d4f43c6b717dd",
"status": "measured",
"judge_outputs": [
"{\"score\": 0.75, \"pass\": true, \"reason\": \"Meets points 1, 2, and 4: it selects the brand-reveal blueprint for multi-phase choreography, describes atomic rules as single-behavior building blocks, and warns against forcing unrelated templates. It misses point 3 by never mentioning the seek-safe timeline contract.\"}",
"{\"score\": 0.75, \"pass\": true, \"reason\": \"Meets criteria 1 (blueprint for multi-phase brand-reveal choreography), 2 (atomic rules as independent single-property units), and 4 (blueprint only when the scene matches). Misses 3: no mention of the seek-safe timeline contract.\"}",
"{\"score\": 0.5, \"pass\": false, \"reason\": \"Meets criterion 1 (uses blueprint for multi-phase brand-reveal choreography) and criterion 4 (avoids unneeded templates), but misses criterion 2's explicit 'smaller building blocks' framing and criterion 3's seek-safe timeline contract, which is never mentioned.\"}",
"{\"score\": 0.75, \"pass\": true, \"reason\": \"Meets criteria 1, 2, and 4: it selects the blueprint for coordinated brand-reveal phases, frames atomic rules as independent units, and warns against unneeded templates. It misses criterion 3, never mentioning the seek-safe timeline contract.\"}",
"{\"score\": 0.75, \"pass\": false, \"reason\": \"Meets points 1, 2, and 4 (blueprint for brand reveal, atomic rules as independent units, avoiding unneeded templates). Misses point 3: no mention of the seek-safe timeline contract.\"}"
]
},
{
"id": "template",
"mode": "baseline",
"draw_index": 1,
"generation_hash": "ebb930ce5d05f2b91aef6b8ae27c7675bc3919130f22f1fca838880a4bc4f887",
"answer_sha256": "ebb930ce5d05f2b91aef6b8ae27c7675bc3919130f22f1fca838880a4bc4f887",
"status": "measured",
"judge_outputs": [
"{\"score\": 0.5, \"pass\": false, \"reason\": \"Criterion 1 is met: it recommends the matching brand-reveal blueprint for multi-phase choreography. Criterion 2 is met: atomic rules are described as independent building blocks. Criterion 3 is not addressed: the response never mentions a seek-safe timeline contract. Criterion 4 is not addressed: it never discusses avoiding unrelated templates.\"}",
"{\"score\": 0.75, \"pass\": true, \"reason\": \"Meets criteria 1, 2 and 4: it recommends the matching blueprint for multi-phase choreography, frames atomic rules as building blocks, and avoids unneeded templates. It never mentions keeping the seek-safe timeline contract (criterion 3).\"}",
"{\"score\": 0.5, \"pass\": false, \"reason\": \"Criterion 1 is met: it recommends the brand-reveal blueprint for multi-phase choreography. Criterion 2 is met: atomic rules are described as building blocks that a blueprint contains. Criterion 3 is missed: it never mentions a seek-safe timeline contract. Criterion 4 is missed: it does not address avoiding unrelated template loading.\"}",
"{\"score\": 0.5, \"pass\": false, \"reason\": \"Met criterion 1 (uses blueprint for multi-phase brand-reveal choreography) and criterion 2 (atomic rules described as independent building blocks). Missed criterion 3, since no seek-safe timeline contract is mentioned; criterion 4 is ambiguous and not clearly addressed.\"}",
"{\"score\": 0.5, \"pass\": false, \"reason\": \"Meets criterion 1 (uses the blueprint for multi-phase choreography) and criterion 2 (atomic rules described as building blocks), but misses criterion 3 (no seek-safe timeline contract mentioned) and criterion 4 (no explicit statement about avoiding unrelated templates).\"}"
]
},
{
"id": "template",
"mode": "baseline",
"draw_index": 2,
"generation_hash": "7d326d0ac107fb2578b6d22d5679de13c5e9f4048e3b491045d0d2be277c335a",
"answer_sha256": "7d326d0ac107fb2578b6d22d5679de13c5e9f4048e3b491045d0d2be277c335a",
"status": "measured",
"judge_outputs": [
"{\"score\": 0.5, \"pass\": false, \"reason\": \"Meets criteria 1 (blueprint for multi-phase choreography) and 2 (atomic rules as building blocks); misses 3 (no seek-safe timeline contract) and 4 (no explicit avoidance of unrelated templates).\"}",
"{\"score\": 0.5, \"pass\": false, \"reason\": \"Meets criteria 1 and 2 (recommends the brand-reveal blueprint for multi-phase choreography and describes atomic rules as building blocks), but never mentions keeping a seek-safe timeline contract (3) and doesn't address avoiding unrelated templates explicitly (4), so only half is met.\"}",
"{\"score\": 0.75, \"pass\": true, \"reason\": \"Met criteria 1 (brand-reveal blueprint for multi-phase timing), 2 (atomic rules as building blocks), and 4 (no unrelated templates); missed 3, since it never mentions the seek-safe timeline contract.\"}",
"{\"score\": 0.75, \"pass\": true, \"reason\": \"Meets criteria 1, 2, and 4: it matches the brand-reveal blueprint to multi-phase timing, frames atomic rules as building blocks, and avoids unneeded templates. Misses 3: no seek-safe timeline contract is mentioned.\"}",
"{\"score\": 0.5, \"pass\": false, \"reason\": \"Meets criteria 1 (blueprint for multi-phase choreography) and 2 (atomic rules as building blocks); misses 3 because it never mentions a seek-safe timeline contract, and 4 is only loosely addressed via fit signals.\"}"
]
},
{
"id": "template",
"mode": "baseline",
"draw_index": 3,
"generation_hash": "c4d50c73ff9c2b95cf86a17f4782a32197ec5dc12d5a664815dab754ca6581ea",
"answer_sha256": "c4d50c73ff9c2b95cf86a17f4782a32197ec5dc12d5a664815dab754ca6581ea",
"status": "measured",
"judge_outputs": [
"{\"score\": 0.75, \"pass\": true, \"reason\": \"Meets criteria 1 (blueprint for multi-part choreography), 2 (atomic rules as building blocks), and 4 (avoids a mismatched blueprint). Misses 3: never addresses the seek-safe timeline contract.\"}",
"{\"score\": 0.75, \"pass\": true, \"reason\": \"Meets criteria 1, 2, and 4: it recommends the matching brand-reveal blueprint, describes atomic rules as building blocks, and warns against forcing mismatched templates. Misses criterion 3, since it never mentions a seek-safe or deterministic timeline contract.\"}",
"{\"score\": 0.75, \"pass\": true, \"reason\": \"Met criteria 1, 2, and 4: it recommends the matching brand-reveal blueprint for multi-part choreography, calls atomic rules building blocks, and avoids forcing unrelated templates. Missed criterion 3: it never mentions keeping a seek-safe timeline contract.\"}",
"{\"score\": 0.75, \"pass\": true, \"reason\": \"Meets criteria 1 (start from the brand-reveal blueprint), 2 (atomic rules as building blocks/vocabulary), and 4 (avoid a mismatched template). Misses 3: it never mentions a seek-safe or deterministic timeline contract.\"}",
"{\"score\": 0.5, \"pass\": false, \"reason\": \"Response clearly uses the brand-reveal blueprint for multi-phase choreography and describes atomic rules as building blocks (criteria 1 and 2 met). It never mentions a seek-safe timeline contract, so criterion 3 is missed, and it does not explicitly address avoiding unrelated templates, so criterion 4 is only loosely met at best and is also missed.\"}"
]
}
]
}