{
"format": "driftproof-answers/2",
"receipt_hash": "b9f499c15c4f83c9a4e1171e88681271c6d6d2cc8637bac97659c5c05a6ab0ce",
"model_id": "claude-sonnet-5-5",
"answers": {
"fcf335058b6b4d53d7cabc6fb7612f8ff0d7cb5b1e9b6b40dac75b92c28057f9": "# Heading reveal + card entrance\n\nThis uses only the constraints from the animation skill. I haven't checked `rules-index.md` or `hyperframes-core`, so the markup attributes below are placeholders to adapt.\n\n## Motion plan (about 1.6s total)\n\n| Time | Element | Motion |\n|---|---|---|\n| 0.0-0.6s | Heading | Fade in with a 40px rise (`y: 40 → 0`, `opacity: 0 → 1`), `power3.out` |\n| 0.35-1.0s | Heading underline | `scaleX: 0 → 1` from the left, `power2.out` |\n| 0.7-1.4s | Cards (3) | Fade in with a rise and slight scale (`y: 60 → 0`, `scale: 0.94 → 1`), `back.out(1.4)`, 0.12s stagger |\n\nThe heading settles before the cards start, with a small overlap so it reads as one continuous move.\n\n## Code sketch\n\n```html\n\n
Heading
\n
\n
A
\n
B
\n
C
\n
\n
Title here
\n\n…
\n…
\n…
\n```\n\n```js\nconst tl = gsap.timeline({ paused: true });\n\ntl.fromTo(\".heading\",\n { yPercent: 100, opacity: 0 },\n { yPercent: 0, opacity: 1, duration: 0.7, ease: \"power3.out\" },\n 0\n);\n\ntl.fromTo(\".card\",\n { y: 40, scale: 0.96, opacity: 0 },\n { y: 0, scale: 1, opacity: 1, duration: 0.8, ease: \"power2.out\", stagger: 0.12 },\n 0.35\n);\n\n// Register only after the timeline is fully built\nwindow.__timelines = window.__timelines || {};\nwindow.__timelines[\"main\"] = tl;\n```\n\n### Why it seeks correctly\n\n- **Single paused timeline.** The renderer or preview scrubs it, so there is no real-time playback to desync.\n- **`fromTo` with explicit start and end values.** Seeking to 0.5s, then 0.1s, then 1.0s gives the same frame every time.\n- **Transform aliases only** (`yPercent`, `y`, `scale`) plus `opacity`. No `width`, `height`, `top` or `left`.\n- **No `Math.random`, `Date.now` or `repeat: -1`.** The stagger is fixed, not randomized.\n- **No `getBoundingClientRect()` at tween time.** Distances are fixed constants (`40`, `100%`), and the mask gives the reveal a clean edge without measuring.\n- **No `display` or `visibility` tweens.** Hiding is done through `opacity` and the mask.\n\n### Caveats\n\nI haven't read `hyperframes-core`, `rules-index.md` or any rule files, so a few details are unverified:\n\n- The exact `window.__timelines` key and the clip data attributes (`data-duration` and so on) need checking against core.\n- If this scene is a later clip, avoid page-load `gsap.set` on the clip itself. Apply the `fromTo` tweens only to inner elements, not the `.clip` element, since the framework owns clip lifecycle.\n- Core's `data-duration` governs scene length, so set it to cover at least 1.2s.\n\nIf you want, I can check these against the rules index and refine the easing choices.",
"428dec8afe5b0eb611e66bafa2278c8bf926f480f109b91a27cc92857171a6da": "## Proposal: heading reveal + card entrance\n\nThis is a single paused GSAP timeline with about 1.4s of motion. Every tween is a `fromTo` with explicit start and end values, so jumping to any time gives the same state without relying on earlier tweens having run.\n\n**Beats**\n\n| Time | Element | Motion |\n| --- | --- | --- |\n| 0.00-0.60s | Heading | `y: 40 → 0`, `opacity: 0 → 1`, ease `power3.out` |\n| 0.20-0.80s | Heading underline/accent (optional) | `scaleX: 0 → 1`, `transformOrigin: \"left center\"`, ease `power2.out` |\n| 0.50-1.30s | Card | `y: 60 → 0`, `scale: 0.96 → 1`, `opacity: 0 → 1`, ease `power3.out` |\n| 0.65-1.40s | Card children | Same `y`/`opacity` entrance with a fixed `0.08s` stagger |\n\nThe card starts about 0.1s before the heading finishes, so the two read as one continuous gesture rather than two separate steps.\n\n**Sketch**\n\n```html\n\n```\n\n```js\nconst tl = gsap.timeline({ paused: true });\n\ntl.fromTo(\"#title\",\n { y: 40, opacity: 0 },\n { y: 0, opacity: 1, duration: 0.6, ease: \"power3.out\" }, 0);\n\ntl.fromTo(\"#card\",\n { y: 60, scale: 0.96, opacity: 0 },\n { y: 0, scale: 1, opacity: 1, duration: 0.8, ease: \"power3.out\" }, 0.5);\n\ntl.fromTo(\".card-item\",\n { y: 20, opacity: 0 },\n { y: 0, opacity: 1, duration: 0.5, ease: \"power2.out\", stagger: 0.08 }, 0.65);\n\n// Register only after the timeline is fully built\nwindow.__timelines = window.__timelines || {};\nwindow.__timelines[\"scene-1\"] = tl;\n```\n\n**Why this seeks correctly**\n\n- **Paused, single timeline:** the preview can drive it to any time, forward or backward.\n- **`fromTo` everywhere:** each tween defines its own start state, so scrubbing backward or jumping past tweens never leaves stale values.\n- **Transform aliases and opacity only:** `x`/`y`/`scale` plus `opacity`, with no `width`/`height`/`top`/`left` tweens, so no layout dependence.\n- **No randomness or wall-clock calls:** no `Math.random`, `Date.now` or `performance.now`. The stagger is a fixed number.\n- **No `repeat: -1`, `display` or `visibility` tweens:** none are needed, and the timeline has a finite length.\n- **No measurement at tween time:** offsets (40, 60, 20) are hard-coded constants, not read from `getBoundingClientRect()`.\n\n**Caveats**\n\nI had no tool access here, so I haven't checked this against `rules-index.md` or the `hyperframes-core` contract. Before implementing, I'd pick the matching heading-reveal and card-entrance rules from the index and adapt their recipes. I'd also confirm the exact `window.__timelines` key convention and set `data-duration` on the clip to cover the 1.4s of motion plus any hold time.",
"8b16c20028f6e4338770f13cf84c2be85d82163fa5c99794fd4c0d7c557eba7c": "I don't have HyperFrames' API in the facts supplied, so this is written as a pure function of time that you can map onto whatever seek or render hook the scene exposes.\n\n## Proposal (total about 1.3 s)\n\n**Heading reveal (0.00 to 0.60 s)**\n- Split the heading into words. Each word starts 0.06 s after the previous one.\n- Each word animates over 0.45 s with `easeOutCubic`.\n- `translateY` goes from 24px to 0, `opacity` from 0 to 1, and `clip-path` from `inset(0 0 100% 0)` to `inset(0 0 0 0)`, so the word looks like it rises out of a mask.\n\n**Card entrance (starts at 0.35 s, overlapping the heading's tail)**\n- Cards stagger 0.12 s apart.\n- Each card animates over 0.5 s with `easeOutCubic`.\n- `translateY` goes from 40px to 0, `scale` from 0.96 to 1, and `opacity` from 0 to 1.\n\nThree cards would end at 0.35 + 2×0.12 + 0.5 = 1.09 s. Four cards would end at 1.21 s.\n\n## Making it seekable\n\nThe key rule is that every visual value is computed from the current time `t` and nothing else:\n\n```js\nconst clamp = (x) => Math.min(1, Math.max(0, x));\nconst easeOutCubic = (x) => 1 - Math.pow(1 - x, 3);\nconst prog = (t, start, dur) => easeOutCubic(clamp((t - start) / dur));\n\nfunction render(t) {\n words.forEach((el, i) => {\n const p = prog(t, i * 0.06, 0.45);\n el.style.opacity = p;\n el.style.transform = `translateY(${24 * (1 - p)}px)`;\n el.style.clipPath = `inset(0 0 ${100 * (1 - p)}% 0)`;\n });\n cards.forEach((el, i) => {\n const p = prog(t, 0.35 + i * 0.12, 0.5);\n el.style.opacity = p;\n el.style.transform = `translateY(${40 * (1 - p)}px) scale(${0.96 + 0.04 * p})`;\n });\n}\n```\n\nWhy this supports jumping to any time:\n- **No accumulated state.** Nothing depends on the previous frame, so `render(0.7)` gives the same result whether you got there by playing or by scrubbing.\n- **Clamping.** Before an element's start it sits at its initial state, and after its end it holds the final state, so seeking backward or past the end is safe.\n- **No wall-clock timing.** Avoid `setTimeout`, CSS transitions or animations, and `Date.now()` inside the scene. The host's time value should be the only driver.\n- **Deterministic stagger.** Delays come from the index (`i * 0.06`), not from random values or measured layout. If you need randomness, seed it.\n\nHook `render(t)` to the scene's seek or time-update callback, and also call it once at `t = 0` so the first frame is correct.",
"22baa12fb6cb27497a7b59914c354e5a7d067b9271b712f40bf0ba46d93ae740": "I haven't been given HyperFrames' API, so this is a framework-agnostic spec with a small sketch. Map the `render(t)` function onto however HyperFrames exposes seekable time.\n\n## Core rule for seekability\n\nEvery visual property is a pure function of the scene time `t`. Nothing is driven by wall-clock timers, CSS animations that run on their own, or state carried over from the previous frame. Jumping to any `t` then gives the same result as playing up to it.\n\n## Timeline (1.4s total)\n\n| Element | Start | Duration | Motion |\n|---|---|---|---|\n| Heading, word by word | 0.00s + 0.08s per word | 0.60s | Each word slides up from `translateY(100%)` to 0 inside an `overflow: hidden` line mask. Opacity goes 0 to 1 over the first 40% of the word's duration. |\n| Card 1, 2, 3 | 0.45s + 0.12s per card | 0.55s | `translateY(32px)` to 0, `scale(0.96)` to 1, opacity 0 to 1. |\n\nEasing is easeOutCubic for everything: `1 - (1 - p)^3`.\n\n## Sketch\n\n```js\nconst clamp01 = x => Math.min(1, Math.max(0, x));\nconst easeOut = p => 1 - Math.pow(1 - p, 3);\nconst prog = (t, start, dur) => easeOut(clamp01((t - start) / dur));\n\nfunction render(t) {\n words.forEach((el, i) => {\n const p = prog(t, i * 0.08, 0.6);\n el.style.transform = `translateY(${(1 - p) * 100}%)`;\n el.style.opacity = clamp01(p / 0.4);\n });\n\n cards.forEach((el, i) => {\n const p = prog(t, 0.45 + i * 0.12, 0.55);\n el.style.transform = `translateY(${(1 - p) * 32}px) scale(${0.96 + 0.04 * p})`;\n el.style.opacity = p;\n });\n}\n```\n\n## Why this supports jumping to any time\n\n- **Clamped progress:** at `t < start` an element sits at its initial state, and at `t > start + dur` it sits at its final state. Scrubbing backward or past the end is safe.\n- **Idempotent:** `render(t)` sets every property explicitly on every call, so there is no dependence on the previous frame.\n- **Index-based stagger:** delays come from the element's index, not from a sequence of callbacks.\n- **No randomness:** if you add jitter or variation, derive it from a seeded value per element, never `Math.random()` at render time.\n- **Initial state before first render:** call `render(0)` on mount so nothing flashes in its final position.\n\nIf HyperFrames provides its own timeline or tween primitive, express the same offsets and durations there and make sure it is paused and driven by the scene's seek time rather than running freely.",
"11ecb32eb83647078430cdbcf2900cbce44ce16e02541b3e61834caf42456594": "I don't have HyperFrames API details in the facts supplied, so this is written as a pure function of time. You can map it onto whatever timeline or seek hook the framework provides.\n\n## Seekability principle\n\nEvery visual property is computed directly from the scene time `t` (seconds). There is no accumulated state, no delta-time stepping, no `Date.now()`, no event-triggered tweens, and no randomness without a fixed seed. Jumping to any `t`, forward or backward, then renders exactly the same frame as playing through to it.\n\n## Timing (total about 1.1 s)\n\n| Element | Start | Duration | Motion | Easing |\n|---|---|---|---|---|\n| Heading, word *i* | `0.00 + i·0.06` | 0.50 | Slides up from `translateY(100%)` to `0` inside an `overflow:hidden` mask, with opacity 0→1 over the first 40% | easeOutCubic |\n| Heading underline or accent (optional) | 0.40 | 0.40 | `scaleX` 0→1, origin left | easeInOutCubic |\n| Card | 0.35 | 0.55 | `translateY` 28px→0, `scale` 0.96→1, opacity 0→1 | easeOutCubic |\n| Card contents (optional) | 0.55 + i·0.08 | 0.35 | Fade and rise 8px | easeOutQuad |\n\nThe card begins while the heading is still finishing, so the two read as one gesture.\n\n## Sketch\n\n```js\nconst clamp01 = x => Math.min(1, Math.max(0, x));\nconst prog = (t, start, dur) => clamp01((t - start) / dur);\nconst easeOutCubic = p => 1 - Math.pow(1 - p, 3);\n\nfunction render(t) {\n // Heading\n words.forEach((el, i) => {\n const p = easeOutCubic(prog(t, i * 0.06, 0.5));\n el.style.transform = `translateY(${(1 - p) * 100}%)`;\n el.style.opacity = clamp01(p / 0.4);\n });\n\n // Card\n const c = easeOutCubic(prog(t, 0.35, 0.55));\n card.style.transform = `translateY(${(1 - c) * 28}px) scale(${0.96 + 0.04 * c})`;\n card.style.opacity = c;\n}\n```\n\n`render(t)` is called on every seek and every playback tick. Because progress is clamped, `t < start` gives the hidden initial state and `t > start + dur` gives the final state, so scrubbing past either end is safe.\n\n## Notes for the preview\n\n- Set initial hidden styles through `render(0)`, not CSS-only defaults, so a seek to 0 is identical to first load.\n- Split the heading into word spans up front, not during animation, so layout is stable at every `t`.\n- If the framework provides its own timeline object, register these as tweens on it rather than running a separate clock. Two clocks will drift out of sync when you seek.\n- If you use `will-change: transform, opacity` on the card, remove it after the animation ends to avoid holding a compositor layer.",
"e0e750cba7f8dbe35b8c474cafb60e0f52024c055eebd723d8ecb040030eadc4": "**Guidance to consult:** `adapters/lottie.md` in the hyperframes-animation skill. The routing table points Lottie and dotLottie (After Effects exports) there. The prerequisite contract in `hyperframes-core` (determinism, one paused timeline) also applies.\n\n**Property to check:** `window.__hfLottie`. Each Lottie instance in the scene must be registered on that global. HyperFrames seeks every runtime in one pass through its runtime-specific global, so an unregistered instance won't follow seeks and will drift or play on its own.\n\nI haven't opened `adapters/lottie.md` or the scene code, so the exact registration details (such as whether the player must be paused or manually driven) should be confirmed in that file.",
"a40b5dc233cdaaad1965d8c1beb239d0194b191e578f2f464049cf6579af3b7f": "Consult `adapters/lottie.md`, the Lottie / dotLottie adapter guidance in the hyperframes-animation skill. It covers After Effects exports and the `window.__hfLottie` registration.\n\nThe property to check is `window.__hfLottie`. Each runtime registers its instances on its own global so HyperFrames can seek all of them in one pass. If the Lottie animation instance isn't registered there, HyperFrames can't seek it, which would explain broken seek behavior.\n\nThe skill doesn't spell out the other details, so I can't say them from the supplied facts alone. I'd also check that the scene follows the `hyperframes-core` contract: a single paused timeline, no non-deterministic calls like `Math.random` or `Date.now`, and the timeline registered only after it is fully built.",
"b9c3f1fbe4d0df9fcb110b5bfd9e5ac19e0394ebc116e0f3e64f20c8743e89cb": "Consult `adapters/lottie.md`, the Lottie / dotLottie adapter guidance. If the scene is a character animation, also read its Characters section. The `hyperframes-core` contract (single paused timeline, deterministic rendering) is the prerequisite.\n\nThe property to check is `window.__hfLottie`. Each runtime registers its instances on its own global so HyperFrames can seek all of them in one pass. If the scene's Lottie instances aren't registered there, HyperFrames can't seek them, which would explain the broken seek behavior.\n\nI haven't opened `adapters/lottie.md`, so I can't give the exact registration shape or any other requirements. The routing table only points to `window.__hfLottie` as the hook, and the details are in that file.",
"8ebfcbfbd02b24343e7fb681d62262dd6699f1f0a2283a16de67437444bded51": "Consult `adapters/lottie.md` in the hyperframes-animation skill. It covers Lottie and dotLottie (After Effects exports) and the `window.__hfLottie` registration. The composition contract in `hyperframes-core` also applies.\n\nThe property to check is **`window.__hfLottie`**. Each Lottie instance must be registered there so HyperFrames can find it and seek it along with the other runtimes in one pass. If the scene's animation isn't registered on that global, or is registered incorrectly, seeking will drift or not work.\n\nThe supplied facts don't spell out the exact seek mechanics, such as the expected instance shape or how frames map to time. Those details are in `adapters/lottie.md`, so confirm them there before changing anything.",
"04edecfcee70f2fe14c6c5942e62b3b1ef423ba4e2266cf2e7771a5630052c60": "**Guidance to consult:** `adapters/lottie.md`, the Lottie / dotLottie adapter doc in the hyperframes-animation skill. If the scene is a character (walk cycle, mascot), its Characters section is relevant too. The prerequisite is the `hyperframes-core` determinism contract, which the skill says to read first.\n\n**Property to check:** `window.__hfLottie`. Each Lottie instance has to be registered there, because that is how HyperFrames finds and seeks all Lottie animations in one pass. If an instance isn't registered, or the player is autoplaying on its own clock instead of being driven by the seek, the scene will drift or fail to seek correctly.\n\nI haven't opened `adapters/lottie.md`, so I can't confirm the exact registration shape or any other requirements it lists. Those details are in that file.",
"453e5644ac57cf44c3bb41bec49ea7d3ddbf475571b5f7ee8f347be4f1de1c70": "I don't have a specific guidance document in the facts you supplied, so this is based on general Lottie knowledge rather than a named source.\n\n**Guidance to consult:** the Lottie player's own seek/playback API docs for the runtime the scene uses. For lottie-web that means `goToAndStop` / `goToAndPlay` and `goToAndStop(value, isFrame)`. For `lottie-player` or dotLottie it means `seek()`. If your project has its own scene or animation guidelines for Lottie, check those first, since they would override the generic docs.\n\n**Property to check:** whether the seek value is interpreted as a **frame number or a time in milliseconds**. In lottie-web this is the `isFrame` flag. It matters together with the animation's **frame rate** (`fr`) and its in/out points (`ip`/`op`, i.e. `totalFrames`). Seeking drifts or lands in the wrong place when a time-based value is passed as a frame, or the reverse, or when the frame rate is assumed rather than read from the animation.\n\nIf seeking is still off after that, the next things to check are:\n- whether the seek is relative to the full animation or to a playing segment\n- whether the animation has loaded before the seek is called",
"6ad098e458d02fdd08c8de769b5779cb3bb1b357285c4c89f0f2f64f251bb9e9": "The facts you supplied don't name a specific guidance document, so I can't say which one applies without guessing. If the repo has its own guidance for scenes or animation (a skill, README, or contributing doc), consult that first. Otherwise, consult the docs for the exact Lottie player and version the scene uses, since seek APIs differ between them (lottie-web, lottie-react, dotLottie, and so on).\n\nThe property to check first is the time base of the seek: whether the seek value is in frames or in time, and how it maps to the animation's frame rate and range. Specifically:\n\n- **Units:** whether the seek call expects a frame number or milliseconds/seconds. For example, lottie-web's `goToAndStop(value, isFrame)` depends on the `isFrame` flag.\n- **Frame rate and range:** the animation's `fr` (frame rate), `ip` (in point), and `op` (out point), which determine the total frames and duration.\n- **Timing source:** whether the scene drives the animation from its own clock or lets the player run on its own. Combining the two is a common cause of drift or wrong seeks.\n\nI haven't inspected the scene's code, so I can't confirm which of these is causing the problem.",
"eaa4792ee381c906212a21012acdd35b94699818a1b14c455691f2273645a734": "The facts you supplied don't name a specific guidance document or property, so I can't say which one your project intends. I'd rather not invent one.\n\nWithout tool access, the most I can offer is general Lottie knowledge:\n\n- **Guidance to consult:** the docs for the Lottie runtime the scene actually uses (for example lottie-web, lottie-player, or a wrapper such as Remotion's Lottie package), specifically its seek API. If the project has its own guidance on animation or scene timing, that takes precedence.\n- **Property to check:** whether the seek value is interpreted as frames or as time. In lottie-web, `goToAndStop(value, isFrame)` treats the value as milliseconds unless `isFrame` is true. Next check the animation's frame rate and total frames (`frameRate`, `totalFrames`, `fr`/`ip`/`op` in the JSON). A mismatch there is the usual cause of seeks landing on the wrong frame or drifting.\n\nIf you point me to the scene's file or the guidance you meant, I can check against it directly.",
"85f36702287bee59ce71cc1d3a62a59f051779c044f4acddd48381fc94ff0251": "**When a blueprint is appropriate**\n\nSince your scene already matches a complex brand-reveal template, this is the case the skill reserves blueprints for. Load one when:\n\n- The scene matches an existing pre-designed multi-phase template (brand-reveal, social-proof, etc.), and reusing its phase pipeline saves real authoring time.\n- You want runnable ground-truth code for a complex 4-5 phase choreography.\n\nLook up the template in `blueprints-index.md`, then read the matching `blueprints/.md` recipe. Only open it once you've decided you need scene-level orchestration, not speculatively.\n\n**How it differs from atomic rules**\n\n| | Atomic rules | Blueprints |\n|---|---|---|\n| Scope | One motion pattern (a single effect or trigger) | A whole scene with multiple sequenced phases |\n| Source | `rules-index.md` → `rules/.md` | `blueprints-index.md` → `blueprints/.md` |\n| Usage | Pick 2-4 and glue them together on one paused GSAP timeline | Follow a pre-built phase pipeline as a unit |\n| Default? | Yes. Faster and produces less code | No. Used only when the scene matches a template |\n| Authoring effort | You do the composition and timing | The choreography is already worked out |\n\n**What stays the same**\n\nEither route has to obey the `hyperframes-core` contract:\n\n- A single paused timeline, registered only after it is fully built.\n- No `Math.random`, `Date.now` or `performance.now`.\n- Spatial motion through GSAP transform aliases only.\n- Pre-calculated layout constants rather than tween-time measurements.\n\nA blueprint saves you the choreography design, not the determinism rules.\n\n**Recommendation**\n\nSince the match is already established, use the brand-reveal blueprint as your base rather than rebuilding it from atomic rules. Afterward, you can run `animation-map.mjs` to audit the result for dead zones and stagger consistency. I haven't opened any files here, per your instructions, so I can't speak to the specific phases the template contains.",
"325e3b14cfb2e6912828a9fe6e1b470b0632bb7aafacda0196cf02d52560b542": "**When a blueprint is appropriate**\n\nSince your scene already matches an existing brand-reveal template, this is one of the cases where loading a blueprint makes sense. The skill's guidance is to reach for one when:\n\n- The scene matches a pre-designed multi-phase template (brand-reveal, social-proof, etc.), and reusing its phase pipeline saves real authoring time.\n- You want runnable, ground-truth code for a complex 4-5 phase choreography rather than building the sequencing yourself.\n\nYou'd look up the template in `blueprints-index.md`, which points to `blueprints/.md` for the full recipe. The skill advises against reading blueprints speculatively. Load one only once you've decided you need scene-level orchestration, which you have here.\n\n**How it differs from atomic rules**\n\n| | Atomic rules | Blueprints |\n|---|---|---|\n| Scope | A single motion pattern (one HTML/CSS/GSAP recipe) | A whole scene with multiple sequenced phases |\n| Selection | Pick 2-4 from `rules-index.md` by trigger or tag | Pick one scene-level template from `blueprints-index.md` |\n| Composition | You glue them together on one paused GSAP timeline | The phase pipeline and choreography are already worked out |\n| Default? | Yes, faster and produces less code in most cases | No, used when the scene matches a template |\n| Source | `rules/.md` | `blueprints/.md` |\n\nIn short, atomic rules are building blocks you assemble yourself, while a blueprint is a pre-assembled, multi-phase scene. For a complex brand reveal that already matches a template, starting from the blueprint avoids re-deriving the phase timing and ordering from individual rules.\n\nEither way, the same constraints from `hyperframes-core` apply: a single paused timeline registered only after it's fully built, no `Math.random`/`Date.now`, pre-calculated layout constants, and spatial motion via GSAP transform aliases only. If you want to audit the result afterward, `scripts/animation-map.mjs` can check for dead zones and stagger consistency.",
"bd54a70298283e583d10ef0132ed9c7f39316c2385a7f921148a3976340e74e8": "Since your requested scene already matches a complex brand-reveal template, a blueprint is the right call here.\n\n**When a blueprint is appropriate**\n\nLoad a blueprint when both of these hold:\n\n- 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.\n- You want runnable ground-truth code for a complex 4-5 phase choreography.\n\nBoth apply to a brand-reveal scene. The next step would be to look up the entry in `blueprints-index.md`, which points to `blueprints/.md` containing the full recipe. You should read that file only once you've decided you need scene-level orchestration, not speculatively.\n\n**How it differs from atomic rules**\n\n| | Atomic rules | Blueprints |\n|---|---|---|\n| Scope | One motion pattern (e.g. a single reveal or stagger) | A whole scene with multiple sequenced phases |\n| Source | `rules-index.md`, then `rules/.md` | `blueprints-index.md`, then `blueprints/.md` |\n| Usage | Pick 2-4 and glue them together on one paused GSAP timeline | Adopt a pre-built phase pipeline as the scene's backbone |\n| Effort | Faster, less code by default | Worth it when the choreography is complex enough that rebuilding it from rules would cost more |\n| Role | The default approach | The exception, used when the scene matches a template |\n\nAtomic rules are the building blocks and you do the orchestration. A blueprint is that orchestration already worked out, with the phases timed and sequenced as a unit.\n\n**What stays the same either way**\n\nThe core constraints still apply: a single paused timeline registered only after it is fully built, no `Math.random` / `Date.now`, precomputed layout constants instead of tween-time measurements, and spatial motion via GSAP transform aliases only. If a blueprint doesn't fit one beat of your scene exactly, you can still swap in an atomic rule for that part.",
"7d44f86047cd62ad0dc2edd4b05e72885008e04c6eca53a0f7fe9d8d6c402ffa": "**Use a blueprint when the requested scene already matches a complete, known pattern.** Here the scene fits a complex brand-reveal template, so start from the blueprint instead of assembling it from scratch.\n\n**What a blueprint is:** a pre-composed, end-to-end structure for a recognizable kind of scene. For a brand reveal, that would typically mean the sequence of beats (tease, build, reveal, settle), how the elements relate to each other, and the pacing and transitions between them. You get a coherent whole whose parts were designed to work together.\n\n**What atomic rules are:** small, independent constraints or instructions, each covering one narrow concern, such as \"logo ends centered,\" \"use this easing,\" or \"hold the final frame for N seconds.\" They don't know about each other or about the overall shape of the scene.\n\n**How they differ:**\n\n| | Blueprint | Atomic rules |\n|---|---|---|\n| Scope | Whole scene | One concern each |\n| Coordination | Built in: timing, order, and dependencies are already resolved | You must ensure the rules don't conflict or leave gaps |\n| Effort | Low when the scene fits; adapt by tweaking parameters | Higher; you compose the structure yourself |\n| Flexibility | Constrained by the template's shape | High; can express anything the rules can combine into |\n| Failure mode | Poor fit if the scene deviates a lot from the template | Drift, inconsistency, or missing pieces across a complex scene |\n\n**When each is appropriate:**\n- **Blueprint:** the scene is complex, interdependent, and matches a known template, as in your case. Re-deriving the structure from atomic rules would risk inconsistencies and waste effort.\n- **Atomic rules:** the scene is novel, simple, or doesn't match any template, or you need fine-grained control over a single aspect.\n- **Both:** the usual best practice is to pick the blueprint for the overall structure, then layer a few atomic rules on top for brand-specific details (colors, timing tweaks, final-frame behavior). Keep those overrides minimal so they don't fight the template's internal logic.\n\n**Recommendation:** use the brand-reveal blueprint as the base, and add atomic rules only for the specific customizations the blueprint doesn't already cover.\n\nI only have the one fact you supplied, so I can't say how your particular system implements blueprints or what parameters this template exposes.",
"99aee16c8385f11ad2b0fbfe540e4b62a4f95fc54cdcc360edb521443c1f71d2": "I don't have your system's definitions of \"blueprint\" or \"atomic rules\" in front of me, so this rests on the usual meaning of those terms and on your premise that the scene already matches a complex brand-reveal template.\n\n**When a blueprint is appropriate**\n\nUse the blueprint when the request matches a known, multi-part pattern as a whole. A brand reveal is a good example because its pieces depend on each other:\n\n- It has a fixed sequence, such as tease, build, reveal, then hold on the logo or tagline.\n- Timing, pacing, camera moves, transitions, and audio hits are coordinated, so changing one affects the others.\n- The result depends on the pieces working together, not on each piece being individually correct.\n- The template encodes proven decisions, so reusing it is faster and more consistent than rebuilding them.\n\nIf the scene fits the template's intent and needs only parameters swapped in (brand name, colors, logo, duration, tone), the blueprint is the right choice.\n\n**How it differs from atomic rules**\n\n| | Blueprint | Atomic rules |\n|---|---|---|\n| Scope | A whole scene or composition | A single constraint or behavior |\n| Structure | Ordered, interdependent parts | Independent, standalone statements |\n| Reuse | Applied as a unit, then customized | Combined freely as needed |\n| Strength | Coherence and speed for known patterns | Flexibility and precise control |\n| Risk | Rigid if the request deviates from the pattern | Can produce an incoherent whole, with no guarantee the parts fit together |\n\n**Recommendation**\n\nStart from the blueprint, since the scene already matches it. Then layer atomic rules on top only for specific deviations, such as a different aspect ratio, a banned color, or a shorter runtime. If you find yourself overriding most of the blueprint, the scene doesn't really fit the template, and building from atomic rules is cleaner.\n\nIf you share how your system defines these two terms, I can tighten this to match.",
"337551288f6094202ca321a54fa437774266261777b842a27753185b2694f11e": "**Short answer:** if the requested scene already matches your brand-reveal template, use the blueprint. Don't rebuild it from atomic rules.\n\nI only have your description, not the template or rule definitions, so this is the general distinction. Adjust it to how your system defines the terms.\n\n**When a blueprint is appropriate**\n- The scene's overall shape matches a known pattern, such as a brand reveal with a fixed sequence of beats (build-up, reveal, hold, tagline).\n- The parts depend on each other. Timing, pacing, camera, audio cues, and logo treatment only work when chosen together.\n- You want predictable, repeatable output that looks consistent across scenes or campaigns.\n- The scene is complex enough that assembling it rule by rule would risk missed steps or conflicting choices.\n\n**How it differs from atomic rules**\n- **Scope:** A blueprint is a composed, end-to-end structure. An atomic rule is a single constraint or behavior, like \"logo holds for 2 seconds\" or \"use brand palette only.\"\n- **Ordering and relationships:** A blueprint encodes sequence and the dependencies between elements. Atomic rules are independent and don't know about each other unless you wire them together.\n- **Decisions already made:** A blueprint carries tested defaults for the whole scene. With atomic rules, you or the system make each decision and then reconcile conflicts.\n- **Flexibility:** Atomic rules are better for novel or unusual scenes, small tweaks, and cross-cutting constraints. Blueprints are less flexible, since deviating means overriding parts of a pre-built whole.\n- **Failure mode:** Blueprints can force a poor fit onto a scene that only looks similar. Atomic rules can produce incoherent results when many are combined without structure.\n\n**Practical recommendation**\nStart from the blueprint, then layer atomic rules on top for specifics, such as brand-specific colors, a shorter duration, or a legal-mandated disclaimer. Treat the blueprint as the structure and the atomic rules as the overrides and guardrails. If you find yourself overriding more than a few of its core beats, the match is probably superficial, and you should drop down to atomic rules instead."
},
"draws": [
{
"id": "timeline",
"mode": "with_skill",
"draw_index": 0,
"generation_hash": "fcf335058b6b4d53d7cabc6fb7612f8ff0d7cb5b1e9b6b40dac75b92c28057f9",
"answer_sha256": "fcf335058b6b4d53d7cabc6fb7612f8ff0d7cb5b1e9b6b40dac75b92c28057f9",
"status": "measured",
"judge_outputs": [
"{\"score\": 1.0, \"pass\": true, \"reason\": \"Meets all four criteria: uses one paused timeline (tl), a small set of fade/rise/scale/scaleX motion rules with fromTo, avoids Math.random/Date.now/repeat:-1 for deterministic seeking, and has no wall-clock timers or autoplay.\"}",
"{\"score\": 1.0, \"pass\": true, \"reason\": \"Uses a single paused timeline (criterion 1), a small set of appropriate rules (fade/rise, scaleX reveal, stagger with back ease) (criterion 2), deterministic fromTo tweens with no random/Date.now (criterion 3), and no wall-clock timers or autoplay (criterion 4).\"}",
"{\"score\": 1.0, \"pass\": true, \"reason\": \"Uses a single paused GSAP timeline, a small set of appropriate motion rules (heading rise, underline scale, staggered cards), deterministic fromTo tweens with no random or Date.now, and no wall-clock timers or autoplay.\"}",
"{\"score\": 1.0, \"pass\": true, \"reason\": \"Uses a single paused gsap timeline, a small set of fade, rise, scale, and stagger rules, fromTo tweens with explicit start times, and no timers or autoplay, meeting all four criteria.\"}",
"{\"score\": 1.0, \"pass\": true, \"reason\": \"Meets all four criteria: one paused gsap timeline, a small set of fitting motion rules, deterministic fromTo tweens with explicit positions, and no wall-clock timers or autoplay.\"}"
]
},
{
"id": "timeline",
"mode": "with_skill",
"draw_index": 1,
"generation_hash": "dc036c094be37de821166b2f15047c88cb7bf1e95a9e050fd5e3c3727fbce2b1",
"answer_sha256": "dc036c094be37de821166b2f15047c88cb7bf1e95a9e050fd5e3c3727fbce2b1",
"status": "measured",
"judge_outputs": [
"{\"score\": 1.0, \"pass\": true, \"reason\": \"Uses a single paused GSAP timeline (1), limits motion to fromTo transform/opacity rules with fixed stagger (2), avoids random/Date/repeat:-1 for deterministic seeking (3), and has no wall-clock timers or independent autoplay (4).\"}",
"{\"score\": 1.0, \"pass\": true, \"reason\": \"Uses one paused GSAP timeline, a small set of appropriate fromTo transform/opacity tweens, explicitly avoids random, Date.now, and repeat:-1 for deterministic seeking, and has no autoplay.\"}",
"{\"score\": 1.0, \"pass\": true, \"reason\": \"Uses one paused GSAP timeline (criterion 1), a small set of deterministic motion rules (fromTo, fixed stagger, transform/opacity only) (criterion 2), explicitly keeps seeking deterministic (criterion 3), and avoids wall-clock timers, repeat:-1, and autoplay (criterion 4).\"}",
"{\"score\": 1.0, \"pass\": true, \"reason\": \"Meets all four criteria: one paused GSAP timeline, a small set of fixed fromTo/transform/opacity rules, deterministic seeking with no random or Date.now, and no wall-clock timers or autoplay.\"}",
"{\"score\": 1.0, \"pass\": true, \"reason\": \"Uses one paused GSAP timeline, a small set of fitting motion rules, fromTo tweens with no random or wall-clock input for deterministic seeking, and no autoplay or timers.\"}"
]
},
{
"id": "timeline",
"mode": "with_skill",
"draw_index": 2,
"generation_hash": "428dec8afe5b0eb611e66bafa2278c8bf926f480f109b91a27cc92857171a6da",
"answer_sha256": "428dec8afe5b0eb611e66bafa2278c8bf926f480f109b91a27cc92857171a6da",
"status": "measured",
"judge_outputs": [
"{\"score\": 1.0, \"pass\": true, \"reason\": \"Uses a single paused GSAP timeline, a small set of appropriate heading and card entrance rules, fixed fromTo values with no randomness, and no wall-clock timers or autoplay.\"}",
"{\"score\": 1.0, \"pass\": true, \"reason\": \"Uses a single paused GSAP timeline, a small set of transform and opacity rules, fromTo tweens with no randomness or wall-clock calls, and no independent autoplay, meeting all four criteria.\"}",
"{\"score\": 1.0, \"pass\": true, \"reason\": \"Uses one paused GSAP timeline, a small set of transform and opacity rules, fromTo tweens with fixed offsets for deterministic seeking, and no wall-clock timers or autoplay.\"}",
"{\"score\": 1.0, \"pass\": true, \"reason\": \"Uses a single paused GSAP timeline, a small set of transform and opacity rules, fromTo tweens with no randomness or wall-clock calls, and no independent autoplay or timers.\"}",
"{\"score\": 1.0, \"pass\": true, \"reason\": \"Uses a single paused GSAP timeline, a small set of appropriate entrance rules (fromTo y/opacity/scale with stagger), explicit deterministic values with no randomness, and no wall-clock timers or autoplay.\"}"
]
},
{
"id": "timeline",
"mode": "baseline",
"draw_index": 0,
"generation_hash": "8b16c20028f6e4338770f13cf84c2be85d82163fa5c99794fd4c0d7c557eba7c",
"answer_sha256": "8b16c20028f6e4338770f13cf84c2be85d82163fa5c99794fd4c0d7c557eba7c",
"status": "measured",
"judge_outputs": [
"{\"score\": 0.75, \"pass\": true, \"reason\": \"Meets criteria 2 (two small motion rules with easing and stagger), 3 (purely time-driven, deterministic seeking), and 4 (explicitly forbids setTimeout, CSS animations, and Date.now). Misses criterion 1 because it never mentions a paused timeline, only a render(t) function.\"}",
"{\"score\": 0.5, \"pass\": false, \"reason\": \"Meets criterion 3 (deterministic under seeking via pure render(t)) and criterion 4 (avoids wall-clock timers, autoplay, CSS transitions), but does not use a single paused timeline and mentions only a seek/time-update hook without a timeline structure; motion rules are reasonable but the single-timeline criterion is missed.\"}",
"{\"score\": 0.5, \"pass\": false, \"reason\": \"Criteria 3 and 4 are met: the response has no accumulated state, avoids wall-clock timers and CSS autoplay, and drives everything from t. Criterion 1 is missed because it never describes a single paused timeline, instead giving a render(t) function with a hook to a host seek callback. Criterion 2 is only partly met: it gives two motion rules (stagger reveal and easing), but the mask/scale/offset set is arguably more than a small set.\"}",
"{\"score\": 0.75, \"pass\": true, \"reason\": \"Meets criteria 2 (small set of easing, stagger, and clamp rules), 3 (explicitly deterministic under seeking), and 4 (explicitly forbids setTimeout, CSS animations, and Date.now). Criterion 1 is only implied by the single render(t) function and never names a paused timeline.\"}",
"{\"score\": 1.0, \"pass\": true, \"reason\": \"Meets all four criteria: a single host-driven time function acts as a paused timeline, motion rules are small and appropriate, seeking is deterministic, and it avoids wall-clock timers and autoplay.\"}"
]
},
{
"id": "timeline",
"mode": "baseline",
"draw_index": 1,
"generation_hash": "22baa12fb6cb27497a7b59914c354e5a7d067b9271b712f40bf0ba46d93ae740",
"answer_sha256": "22baa12fb6cb27497a7b59914c354e5a7d067b9271b712f40bf0ba46d93ae740",
"status": "measured",
"judge_outputs": [
"{\"score\": 1.0, \"pass\": true, \"reason\": \"Meets all four criteria: a single time-driven render(t) with a paused-timeline note, a small set of heading and card motion rules, explicit determinism under seeking, and no wall-clock timers or autoplay.\"}",
"{\"score\": 0.5, \"pass\": false, \"reason\": \"Meets criterion 3 (deterministic under seeking via pure render(t)) and criterion 4 (no wall-clock timers or autoplay), but it does not clearly establish a single paused timeline (it uses a custom render function, mentioning HyperFrames' timeline only conditionally) and the motion set is arguably not a small set of appropriate rules, so criteria 1 and 2 are only partially satisfied.\"}",
"{\"score\": 0.75, \"pass\": true, \"reason\": \"Meets criteria 2 (small set of heading and card motion rules), 3 (pure, idempotent render(t) under seeking), and 4 (explicitly bans wall-clock timers and self-running CSS animations); criterion 1 is weak because it uses a render function rather than an explicit single paused timeline.\"}",
"{\"score\": 1.0, \"pass\": true, \"reason\": \"Meets all four criteria: a single time-driven render(t) with a paused timeline note, a small heading/card motion set, explicit idempotent determinism, and no wall-clock timers or autoplay.\"}",
"{\"score\": 0.75, \"pass\": true, \"reason\": \"Meets criteria 2 (small, appropriate motion rules), 3 (deterministic under seeking), and 4 (no wall-clock or autoplay); misses criterion 1 because it uses a render(t) function and only conditionally mentions a paused timeline.\"}"
]
},
{
"id": "timeline",
"mode": "baseline",
"draw_index": 2,
"generation_hash": "11ecb32eb83647078430cdbcf2900cbce44ce16e02541b3e61834caf42456594",
"answer_sha256": "11ecb32eb83647078430cdbcf2900cbce44ce16e02541b3e61834caf42456594",
"status": "measured",
"judge_outputs": [
"{\"score\": 0.75, \"pass\": true, \"reason\": \"Meets criteria 2 (small, fitting motion set), 3 (pure render(t) is deterministic under seeking), and 4 (bans Date.now() and separate clocks). Criterion 1 is only implied: it never says the single timeline is paused.\"}",
"{\"score\": 0.75, \"pass\": true, \"reason\": \"Meets criteria 2 (small, appropriate motion set), 3 (pure function of t, seek-safe), and 4 (no Date.now or independent clock); misses 1 because it never explicitly specifies a single paused timeline.\"}",
"{\"score\": 0.75, \"pass\": true, \"reason\": \"Meets motion-rule selection (small, appropriate set), deterministic seeking via pure render(t), and avoids wall-clock timers and independent clocks; misses the explicit single paused timeline criterion.\"}",
"{\"score\": 0.75, \"pass\": true, \"reason\": \"Meets criteria 2 (small, appropriate fade/slide/scale rules), 3 (explicit pure-function seeking determinism), and 4 (bans Date.now, independent clocks, autoplay). Misses criterion 1: never names a single paused timeline, only a render(t) function.\"}",
"{\"score\": 0.75, \"pass\": true, \"reason\": \"Meets criteria 2 (small, appropriate heading and card motion set), 3 (pure function of t, safe seeking), and 4 (no Date.now(), no separate clock). Misses 1: it never explicitly calls for a single paused timeline, only a generic timeline hook.\"}"
]
},
{
"id": "runtime",
"mode": "with_skill",
"draw_index": 0,
"generation_hash": "e0e750cba7f8dbe35b8c474cafb60e0f52024c055eebd723d8ecb040030eadc4",
"answer_sha256": "e0e750cba7f8dbe35b8c474cafb60e0f52024c055eebd723d8ecb040030eadc4",
"status": "measured",
"judge_outputs": [
"{\"score\": 0.75, \"pass\": true, \"reason\": \"Routes to adapters/lottie.md (criterion 1) and checks repeatable seeking via window.__hfLottie (criterion 3). Ties playback to the timeline only implicitly via the one-paused-timeline contract (criterion 2), and never addresses renderer replacement (criterion 4).\"}",
"{\"score\": 0.75, \"pass\": true, \"reason\": \"Routes to adapters/lottie.md and ties registration on window.__hfLottie to seek-driven playback and repeatable seeking; it never addresses avoiding a renderer replacement, so criterion 4 is missed.\"}",
"{\"score\": 0.5, \"pass\": false, \"reason\": \"Meets rubric point 1 by routing to adapters/lottie.md; point 3 is only implied via seek-following, and points 2 and 4 are not explicitly addressed.\"}",
"{\"score\": 0.75, \"pass\": true, \"reason\": \"Routes to the Lottie adapter (1), ties seeking to HyperFrames' timeline and repeatable seek behavior (2, 3), but never explicitly says to keep the existing renderer rather than replace it (4 missed).\"}",
"{\"score\": 0.75, \"pass\": true, \"reason\": \"Routes to adapters/lottie.md (criterion 1), ties seeking to the HyperFrames-driven paused timeline and window.__hfLottie (criterion 3), and does not replace the renderer (criterion 4). Criterion 2 is only implicit, not stated outright.\"}"
]
},
{
"id": "runtime",
"mode": "with_skill",
"draw_index": 1,
"generation_hash": "a40b5dc233cdaaad1965d8c1beb239d0194b191e578f2f464049cf6579af3b7f",
"answer_sha256": "a40b5dc233cdaaad1965d8c1beb239d0194b191e578f2f464049cf6579af3b7f",
"status": "measured",
"judge_outputs": [
"{\"score\": 0.5, \"pass\": false, \"reason\": \"Routes to the Lottie adapter and avoids replacing the renderer, but does not clearly connect Lottie playback to the composition timeline or check repeatable seeking.\"}",
"{\"score\": 0.75, \"pass\": true, \"reason\": \"Routes to the Lottie adapter (met) and avoids replacing the renderer (met); connects playback to the timeline and determinism only indirectly via window.__hfLottie and the core contract, so repeatable seeking is only partly addressed.\"}",
"{\"score\": 0.5, \"pass\": false, \"reason\": \"Routes to the Lottie adapter (met) and does not suggest replacing the renderer (met); it only loosely links playback to the timeline and never addresses repeatable seeking (missed).\"}",
"{\n \"score\": 0.5,\n \"pass\": false,\n \"reason\": \"Routes to the Lottie adapter and avoids replacing the renderer (criteria 1 and 4), but never explicitly connects Lottie playback to the composition timeline or addresses repeatable seeking (criteria 2 and 3).\"\n}",
"{\"score\": 0.5, \"pass\": false, \"reason\": \"Routes to the Lottie adapter and avoids replacing the renderer, but does not connect Lottie playback to the composition timeline and only loosely addresses repeatable seeking.\"}"
]
},
{
"id": "runtime",
"mode": "with_skill",
"draw_index": 2,
"generation_hash": "b9c3f1fbe4d0df9fcb110b5bfd9e5ac19e0394ebc116e0f3e64f20c8743e89cb",
"answer_sha256": "b9c3f1fbe4d0df9fcb110b5bfd9e5ac19e0394ebc116e0f3e64f20c8743e89cb",
"status": "measured",
"judge_outputs": [
"{\"score\": 0.75, \"pass\": true, \"reason\": \"Routes to adapters/lottie.md and avoids renderer replacement; ties seeking to the paused timeline and window.__hfLottie registration, though repeatable-seek checking is only implied, not stated.\"}",
"{\"score\": 0.75, \"pass\": true, \"reason\": \"Routes to adapters/lottie.md (criterion 1) and ties seeking to the single paused timeline and window.__hfLottie registration (criteria 2-3, though weakly), and does not propose replacing the renderer (criterion 4).\"}",
"{\"score\": 0.75, \"pass\": true, \"reason\": \"Routes to adapters/lottie.md and ties seeking to the single paused timeline and window.__hfLottie, and does not propose replacing the renderer. It does not explicitly say to verify repeatable seeking, so that criterion is only weakly met.\"}",
"{\"score\": 0.75, \"pass\": true, \"reason\": \"Routes to adapters/lottie.md and checks window.__hfLottie for repeatable seeking, and ties playback to the single paused timeline. It never addresses not replacing the renderer.\"}",
"{\"score\": 0.5, \"pass\": false, \"reason\": \"Routes to adapters/lottie.md and does not suggest replacing the renderer. It only implies timeline connection via the single-paused-timeline prerequisite, and never explicitly calls for repeatable seeking checks.\"}"
]
},
{
"id": "runtime",
"mode": "with_skill",
"draw_index": 3,
"generation_hash": "8ebfcbfbd02b24343e7fb681d62262dd6699f1f0a2283a16de67437444bded51",
"answer_sha256": "8ebfcbfbd02b24343e7fb681d62262dd6699f1f0a2283a16de67437444bded51",
"status": "measured",
"judge_outputs": [
"{\"score\": 0.75, \"pass\": true, \"reason\": \"Routes to the Lottie adapter and ties playback to the timeline via window.__hfLottie, and avoids replacing the renderer. It only implies repeatable seeking through drift warnings rather than stating a repeatability check.\"}",
"{\"score\": 0.75, \"pass\": true, \"reason\": \"Routes to the Lottie adapter and ties registration to HyperFrames' composition seeking, and does not suggest replacing the renderer; it never explicitly calls for repeatable seeking.\"}",
"{\"score\": 0.5, \"pass\": false, \"reason\": \"Met: routes to adapters/lottie.md and ties window.__hfLottie registration to HyperFrames seeking. Missed: repeatable seeking is not stated, and renderer replacement is never addressed.\"}",
"{\"score\": 0.5, \"pass\": false, \"reason\": \"Met criterion 1 by routing to adapters/lottie.md and criterion 2 via __hfLottie timeline registration; missed explicit repeatable-seeking check and did not address not replacing the renderer, so 0.5.\", \"_note\": \"Response does route to the Lottie adapter and ties playback to the HyperFrames timeline through window.__hfLottie. It does not state a repeatable-seeking check, and it says nothing about avoiding replacement of the renderer.\"}",
"{\"score\": 0.75, \"pass\": true, \"reason\": \"Routes to the Lottie adapter (met) and ties window.__hfLottie registration to timeline seeking (met). Does not address repeatable seeking (missed). Suggests no renderer replacement (met).\"}"
]
},
{
"id": "runtime",
"mode": "with_skill",
"draw_index": 4,
"generation_hash": "04edecfcee70f2fe14c6c5942e62b3b1ef423ba4e2266cf2e7771a5630052c60",
"answer_sha256": "04edecfcee70f2fe14c6c5942e62b3b1ef423ba4e2266cf2e7771a5630052c60",
"status": "measured",
"judge_outputs": [
"{\"score\": 0.5, \"pass\": false, \"reason\": \"Routes to adapters/lottie.md and ties playback to the seek-driven timeline via window.__hfLottie, but never explicitly checks repeatable seeking and never states not to replace the renderer.\"}",
"{\"score\": 0.5, \"pass\": false, \"reason\": \"Meets routing to the Lottie adapter and playback-to-timeline seek control; repeatable seeking is only implied, and it never states against replacing the renderer.\"}",
"{\"score\": 0.75, \"pass\": true, \"reason\": \"Routes to adapters/lottie.md and connects playback to the timeline via window.__hfLottie seeking (criteria 1, 2); no renderer replacement suggested (4). Does not explicitly say to verify repeatable seeking (3).\"}",
"{\"score\": 0.5, \"pass\": false, \"reason\": \"Routes to adapters/lottie.md and ties playback to the seek-driven timeline, but never says to check repeatable seeking and does not state that the renderer should be kept.\"}",
"{\"score\": 0.75, \"pass\": true, \"reason\": \"Routes to the Lottie adapter and connects playback to timeline seeking via __hfLottie, and doesn't replace the renderer. It only weakly addresses repeatable seeking, mentioning the determinism contract without explaining how to verify it.\"}"
]
},
{
"id": "runtime",
"mode": "baseline",
"draw_index": 0,
"generation_hash": "453e5644ac57cf44c3bb41bec49ea7d3ddbf475571b5f7ee8f347be4f1de1c70",
"answer_sha256": "453e5644ac57cf44c3bb41bec49ea7d3ddbf475571b5f7ee8f347be4f1de1c70",
"status": "measured",
"judge_outputs": [
"{\"score\": 0.25, \"pass\": false, \"reason\": \"Does not route to a Lottie adapter or connect playback to the composition timeline, and only implicitly addresses repeatable seeking. It also does not suggest replacing the renderer, which earns the one criterion.\"}",
"{\"score\": 0.25, \"pass\": false, \"reason\": \"Only the no-renderer-swap criterion is met; it never routes to a Lottie adapter, never ties playback to the composition timeline, and does not address repeatable seeking.\"}",
"{\"score\": 0.25, \"pass\": false, \"reason\": \"Meets only point 4 (keeps Lottie, no renderer swap). Misses point 1 (no Lottie adapter routing), point 2 (no composition timeline link), and point 3 (no repeatable-seek check; it covers frame/time interpretation instead).\"}",
"{\"score\": 0.0, \"pass\": false, \"reason\": \"Misses all four points: no Lottie adapter routing, no link to the composition timeline, no repeatable-seek check, and no explicit statement against swapping the renderer.\"}",
"{\"score\": 0.0, \"pass\": false, \"reason\": \"Points to generic lottie-web and lottie-player seek docs and checks frame-versus-time seek values, but never routes to a Lottie adapter, ties playback to the composition timeline, checks repeatable seeking, or warns against swapping renderers.\"}"
]
},
{
"id": "runtime",
"mode": "baseline",
"draw_index": 1,
"generation_hash": "6ad098e458d02fdd08c8de769b5779cb3bb1b357285c4c89f0f2f64f251bb9e9",
"answer_sha256": "6ad098e458d02fdd08c8de769b5779cb3bb1b357285c4c89f0f2f64f251bb9e9",
"status": "measured",
"judge_outputs": [
"{\"score\": 0.25, \"pass\": false, \"reason\": \"Meets only point 4 by not replacing the renderer. Misses point 1 (no Lottie adapter route, only generic docs), point 2 (no explicit composition-timeline connection), and point 3 (no repeatable-seeking check).\"}",
"{\"score\": 0.0, \"pass\": false, \"reason\": \"The response gives generic seek-unit and frame-rate advice but does not route to a Lottie adapter, connect playback to the composition timeline, check repeatable seeking, or warn against replacing the renderer.\"}",
"{\"score\": 0.25, \"pass\": false, \"reason\": \"Criterion 2 is partly met by the timing-source discussion, but the response never routes to a Lottie adapter, never checks repeatable seeking, and never addresses keeping the renderer.\"}",
"{\n \"score\": 0.25,\n \"pass\": false,\n \"reason\": \"Routes to Lottie-specific player docs (criterion 1) but never ties playback to the composition timeline, never checks repeatable seeking, and never addresses keeping the existing renderer (criteria 2-4 missed).\"\n}",
"{\"score\": 0.25, \"pass\": false, \"reason\": \"Mentions consulting repo guidance and checking timing source, but never names a Lottie adapter, a composition timeline, repeatable seeking, or warns against replacing the renderer.\"}"
]
},
{
"id": "runtime",
"mode": "baseline",
"draw_index": 2,
"generation_hash": "eaa4792ee381c906212a21012acdd35b94699818a1b14c455691f2273645a734",
"answer_sha256": "eaa4792ee381c906212a21012acdd35b94699818a1b14c455691f2273645a734",
"status": "measured",
"judge_outputs": [
"{\"score\": 0.25, \"pass\": false, \"reason\": \"Meets only point 4 by not replacing the renderer. Misses routing to the Lottie adapter, connecting playback to the composition timeline, and checking repeatable seeking; it cites generic lottie-web docs instead.\"}",
"{\n \"score\": 0.25,\n \"pass\": false,\n \"reason\": \"Meets only point 4 by staying on the scene's existing Lottie runtime. Misses routing to the Lottie adapter guidance, connecting to the composition timeline, and an explicit repeatable-seek check.\"\n}",
"{\n \"score\": 0.5,\n \"pass\": false,\n \"reason\": \"Meets point 4 by not suggesting a renderer swap and partly meets point 2 via frame/time and frame-rate checks. Misses point 1, since it never names a Lottie adapter, and point 3, since repeatable seeking is not explicitly checked.\"\n}",
"{\"score\": 0.25, \"pass\": false, \"reason\": \"Meets only point 4 by keeping the existing Lottie runtime. Misses routing to the Lottie adapter guidance, connecting playback to the composition timeline, and explicitly checking repeatable seeking.\"}",
"{\"score\": 0.0, \"pass\": false, \"reason\": \"Response never routes to a Lottie adapter tied to the scene's HyperFrames guidance, never connects playback to the composition timeline, never addresses repeatable seeking, and only offers generic lottie-web frame/time advice, missing all four rubric points.\"}"
]
},
{
"id": "template",
"mode": "with_skill",
"draw_index": 0,
"generation_hash": "85f36702287bee59ce71cc1d3a62a59f051779c044f4acddd48381fc94ff0251",
"answer_sha256": "85f36702287bee59ce71cc1d3a62a59f051779c044f4acddd48381fc94ff0251",
"status": "measured",
"judge_outputs": [
"{\"score\": 1.0, \"pass\": true, \"reason\": \"Recommends the matching brand-reveal blueprint for multi-phase choreography, describes atomic rules as smaller building blocks, keeps the paused-timeline determinism contract, and warns against speculative template loading.\"}",
"{\"score\": 1.0, \"pass\": true, \"reason\": \"Recommends the matching brand-reveal blueprint for multi-phase choreography, describes atomic rules as single-pattern building blocks, restates the paused-timeline determinism contract, and avoids loading unrelated templates.\"}",
"{\"score\": 1.0, \"pass\": true, \"reason\": \"Recommends the matching brand-reveal blueprint, frames atomic rules as smaller 2-4 pattern building blocks, restates the paused-timeline seek-safe contract, and warns against speculative template loading.\"}",
"{\"score\": 1.0, \"pass\": true, \"reason\": \"Recommends the matching brand-reveal blueprint for multi-phase choreography, describes atomic rules as smaller building blocks, keeps the paused-timeline determinism contract, and warns against opening templates speculatively.\"}",
"{\"score\": 1.0, \"pass\": true, \"reason\": \"Recommends the matching brand-reveal blueprint, describes atomic rules as smaller building blocks, restates the seek-safe paused-timeline contract, and warns against loading templates speculatively.\"}"
]
},
{
"id": "template",
"mode": "with_skill",
"draw_index": 1,
"generation_hash": "325e3b14cfb2e6912828a9fe6e1b470b0632bb7aafacda0196cf02d52560b542",
"answer_sha256": "325e3b14cfb2e6912828a9fe6e1b470b0632bb7aafacda0196cf02d52560b542",
"status": "measured",
"judge_outputs": [
"{\"score\": 1.0, \"pass\": true, \"reason\": \"Meets all four: recommends the matching brand-reveal blueprint, describes atomic rules as building blocks, keeps the single paused timeline contract, and loads no unrelated templates.\"}",
"{\"score\": 1.0, \"pass\": true, \"reason\": \"Recommends the matching brand-reveal blueprint for multi-phase choreography, describes atomic rules as building blocks, keeps the paused-timeline seek-safe contract, and warns against loading templates speculatively.\"}",
"{\"score\": 1.0, \"pass\": true, \"reason\": \"Meets all four criteria: recommends the matching brand-reveal blueprint for multi-phase choreography, describes atomic rules as building blocks, restates the seek-safe paused-timeline contract, and warns against loading templates speculatively.\"}",
"{\"score\": 1.0, \"pass\": true, \"reason\": \"Recommends the matching brand-reveal blueprint for multi-phase choreography, calls atomic rules building blocks, keeps the single paused timeline contract, and warns against loading templates speculatively.\"}",
"{\"score\": 1.0, \"pass\": true, \"reason\": \"Recommends the matching brand-reveal blueprint, calls atomic rules building blocks, restates the seek-safe paused-timeline constraints, and warns against loading templates speculatively.\"}"
]
},
{
"id": "template",
"mode": "with_skill",
"draw_index": 2,
"generation_hash": "bd54a70298283e583d10ef0132ed9c7f39316c2385a7f921148a3976340e74e8",
"answer_sha256": "bd54a70298283e583d10ef0132ed9c7f39316c2385a7f921148a3976340e74e8",
"status": "measured",
"judge_outputs": [
"{\"score\": 1.0, \"pass\": true, \"reason\": \"Recommends the matching brand-reveal blueprint for multi-phase choreography, describes atomic rules as building blocks, keeps the single paused seek-safe timeline constraints, and says not to read unrelated blueprint files speculatively.\"}",
"{\"score\": 1.0, \"pass\": true, \"reason\": \"Recommends the matching brand-reveal blueprint, describes atomic rules as building blocks, keeps the paused single-timeline seek-safe contract, and avoids loading unrelated templates.\"}",
"{\"score\": 1.0, \"pass\": true, \"reason\": \"Recommends the matching brand-reveal blueprint, describes atomic rules as building blocks, keeps the single paused seek-safe timeline contract, and loads only the matching blueprint when needed.\"}",
"{\"score\": 1.0, \"pass\": true, \"reason\": \"Met all four criteria: it recommends the matching brand-reveal blueprint, calls atomic rules the building blocks, keeps the paused single-timeline contract, and avoids loading blueprints speculatively.\"}",
"{\"score\": 1.0, \"pass\": true, \"reason\": \"Recommends the matching brand-reveal blueprint, describes atomic rules as building blocks, restates the single paused timeline contract, and avoids loading unrelated templates.\"}"
]
},
{
"id": "template",
"mode": "baseline",
"draw_index": 0,
"generation_hash": "7d44f86047cd62ad0dc2edd4b05e72885008e04c6eca53a0f7fe9d8d6c402ffa",
"answer_sha256": "7d44f86047cd62ad0dc2edd4b05e72885008e04c6eca53a0f7fe9d8d6c402ffa",
"status": "measured",
"judge_outputs": [
"{\"score\": 0.75, \"pass\": false, \"reason\": \"Meets criteria 1 (brand-reveal blueprint for tease/build/reveal/settle beats), 2 (atomic rules as narrow building blocks), and 4 (blueprint as base, extras only as needed); misses 3, never mentions a seek-safe or deterministic timeline contract.\"}",
"{\"score\": 0.5, \"pass\": false, \"reason\": \"Meets the blueprint-for-multi-phase-choreography and atomic-rules-as-building-blocks criteria, but never mentions a seek-safe timeline contract and does not address avoiding unrelated template loading.\"}",
"{\"score\": 0.5, \"pass\": false, \"reason\": \"Meets criteria 1 (matching brand-reveal blueprint for multi-phase beats) and 2 (atomic rules as small, narrow building blocks). Misses 3 (no seek-safe timeline contract) and does not explicitly address avoiding unrelated templates (4).\"}",
"{\"score\": 0.75, \"pass\": true, \"reason\": \"Meets criteria 1, 2, and 4: it names the brand-reveal blueprint for multi-phase beats, describes atomic rules as narrow building blocks, and avoids unneeded templates. It misses criterion 3, never mentioning a seek-safe timeline contract.\"}",
"{\"score\": 0.5, \"pass\": false, \"reason\": \"Meets criteria 1 (brand-reveal blueprint for multi-phase beats) and 2 (atomic rules as small building blocks). Misses 3 (no seek-safe timeline contract) and 4 (no guidance on avoiding unrelated templates).\"}"
]
},
{
"id": "template",
"mode": "baseline",
"draw_index": 1,
"generation_hash": "99aee16c8385f11ad2b0fbfe540e4b62a4f95fc54cdcc360edb521443c1f71d2",
"answer_sha256": "99aee16c8385f11ad2b0fbfe540e4b62a4f95fc54cdcc360edb521443c1f71d2",
"status": "measured",
"judge_outputs": [
"{\"score\": 0.75, \"pass\": true, \"reason\": \"Met criteria 1 (blueprint for the multi-phase brand reveal), 2 (atomic rules as single, independent building blocks), and 4 (no unrelated templates loaded). Missed criterion 3: no mention of the seek-safe timeline contract.\"}",
"{\"score\": 0.5, \"pass\": false, \"reason\": \"Meets criterion 1 (recommends the brand-reveal blueprint for multi-phase choreography) and criterion 2 (atomic rules as single standalone constraints); misses the seek-safe timeline contract and does not address avoiding unrelated templates.\"}",
"{\"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 standalone building blocks); missed criterion 3 (no seek-safe timeline contract mentioned) and criterion 4 (does not explicitly avoid loading unrelated templates, though it implies reuse of the matching one).\"}",
"{\"score\": 0.5, \"pass\": false, \"reason\": \"Meets criterion 1 (uses blueprint for multi-phase brand-reveal choreography) and criterion 2 (atomic rules as standalone building blocks); misses criterion 3 (no seek-safe timeline contract discussed) and partly criterion 4 (does not address avoiding unrelated templates explicitly).\"}",
"{\"score\": 0.5, \"pass\": false, \"reason\": \"Criterion 1 is met: the response recommends the blueprint for multi-phase brand-reveal choreography. Criterion 2 is met: atomic rules are described as independent standalone statements. Criterion 3 (seek-safe timeline contract) is not addressed. Criterion 4 (avoiding unrelated templates) is only loosely implied, not explicitly discussed.\"}"
]
},
{
"id": "template",
"mode": "baseline",
"draw_index": 2,
"generation_hash": "337551288f6094202ca321a54fa437774266261777b842a27753185b2694f11e",
"answer_sha256": "337551288f6094202ca321a54fa437774266261777b842a27753185b2694f11e",
"status": "measured",
"judge_outputs": [
"{\"score\": 0.75, \"pass\": true, \"reason\": \"Meets blueprint-for-multi-phase-choreography and atomic-rules-as-smaller-blocks, and implicitly avoids unneeded templates. Misses the seek-safe timeline contract entirely.\"}",
"{\"score\": 0.5, \"pass\": false, \"reason\": \"Criterion 1 is met: it says to use the blueprint when the scene matches the template. Criterion 2 is met: it calls atomic rules single constraints or behaviors. Criterion 3 is missed: the response never mentions a seek-safe timeline contract. Criterion 4 is missed: it does not address avoiding loading unrelated templates.\"}",
"{\"score\": 0.5, \"pass\": false, \"reason\": \"Criterion 1 is met: it says to use the blueprint when the scene matches the template and explains when it fits. Criterion 2 is met: atomic rules are described as independent single constraints. Criterion 3 (seek-safe timeline contract) is not addressed. Criterion 4 (avoid unrelated templates) is only loosely touched, so it is not clearly met.\"}",
"{\"score\": 0.5, \"pass\": false, \"reason\": \"Meets criterion 1 (uses blueprint when scene matches) and criterion 2 (atomic rules as single, independent constraints). Misses criterion 3 (no seek-safe timeline contract) and criterion 4 (no mention of avoiding unrelated templates).\"}",
"{\"score\": 0.5, \"pass\": false, \"reason\": \"Meets the blueprint-selection criterion and implicitly frames atomic rules as narrower units. Misses the seek-safe timeline contract entirely and never addresses avoiding unrelated template loading.\"}"
]
}
]
}