feat(skills): remotion-to-hyperframes corpus T3 (4/7)

[jrusso1020]

What

Tier 3 of the test corpus — a purpose-built data-driven fixture (option 2 from the stack discussion, not a port of PR #214's examples/remotion-full/) that exercises the realistic shape of a production Remotion composition.

Stargazed.tsx — 10 s @ 30 fps, 1280×720:

Sequence 0–3 s    TitleScene    (title + subtitle, spring + linear fade)
Sequence 3–7 s    StatsScene    (3 reused StatCards staggered 12 frames apart)
Sequence 7–10 s   OutroScene    (UnderlinedText with scaleX-from-left underline)

Custom React subcomponents:

• StatCard(label, value, color, delayInFrames) — used 3× with different props
• AnimatedNumber(from, to, durationInFrames) — frame-driven count-up
• UnderlinedText(text, color) — text with scaleX underline reveal

End-to-end validation

Validated mean SSIM: 0.953 · threshold 0.90 · margin +0.038 from p05 (0.938).

Frame-strip inspection: the count-up shows minor frame-level digit mismatches mid-animation (Remotion 913, HF 1032 around 3.5 s) but converges to identical final values. Both formulas (Remotion's manual 1 - (1-t)^3 and GSAP's power3.out) are mathematically equivalent — the offset comes from sub-frame seek timing of when GSAP's onUpdate callback fires relative to Remotion's per-frame React render. No SSIM impact above the noise floor.

The wider threshold gap vs T1/T2 (0.04 vs 0.02 below p05) reflects T3's bigger approximation budget: 2 spring instances + count-up timing + font fallback on multiple text sizes (160 px title, 72 px stat number, 80 px outro). Mean SSIM below 0.90 = structural mismatch (wrong durations, wrong stagger, missing prop wiring), not approximation drift.

Why

This is #4 in the 7-PR stack and the largest tier in the corpus. T1 + T2 covered the basic API surface (Sequence, AbsoluteFill, interpolate, spring, Audio, Img, staticFile). T3 adds the shape of real production compositions:

• <Composition schema={z.object({...})} defaultProps={...} /> — Zod-typed props
• nested array prop (stats[]) materialized as repeated markup
• custom React subcomponents reused with different props
• frame-driven count-up animation (AnimatedNumber)
• two different spring configs in the same composition
• useVideoConfig() for fps

If a translation passes T3, the skill correctly handles the patterns 80% of real-world Remotion code uses.

The choice not to port examples/remotion-full/ from PR #214: that fixture's HF half uses the runtime adapter pattern (Remotion's render pipeline running inside the HF page). Including it in the corpus would mix runtime-adapter idioms into the translation evaluation, which is the wrong target — the skill produces pure HTML+GSAP. A purpose-built fixture exercising the same APIs is more honest.

How

Translation choices documented in README.md and expected.json:

Remotion	HyperFrames
<Composition schema={z.object({...})} defaultProps={...} />	data-* attrs on root #stage div
nested array prop (stats[])	repeated HTML markup with per-instance data-* attrs
custom React subcomponent	inline repeated HTML using the component's prop interface as the template
<AnimatedNumber from={0} to={value} dur={45} /> (cubic ease-out count-up)	tween on { v: 0 } object with onUpdate rewriting textContent, ease power3.out
spring({damping:12, stiffness:100})	back.out(1.4) over ~0.7 s
spring({damping:14, stiffness:90})	back.out(1.2) over ~0.7 s
delayInFrames={i * 12} (per-instance)	GSAP timeline offset (i * 0.4) s

Same Remotion config as PR #508: setVideoImageFormat("png") + setColorSpace("bt709") to match HF's yuv420p output.

Stack

#506 (1/7) — scaffold
#507 (2/7) — eval harness
#508 (3/7) — T1 + T2 fixtures
this PR (4/7) — T3 data-driven fixture
5/7 — T4 escape-hatch fixtures
6/7 — references/*.md (translation map)
7/7 — SKILL.md body + corpus orchestrator

Test plan

• lint_source.py over T3 Remotion source: 9 files scanned, 0 blockers / 0 warnings / 0 infos
• All fixture .tsx, .ts, .json, .md files pass oxfmt --check and oxlint
• Lefthook pre-commit (lint + format + typecheck) passes
• End-to-end render + SSIM diff (mean 0.953, ≥ 0.90 threshold)

[miguel-heygen]

T3 has the same threshold-contract drift as T1/T2. The fixture itself is useful, but the README and executable metadata need to agree.

[miguel-heygen]

This section says the threshold is 0.85 and line 56 says below 0.85 is the structural-mismatch signal, but expected.json sets ssim_threshold to 0.90 and the PR body/final skill also cite 0.90. Please align this README with the threshold the orchestrator actually enforces.

[jrusso1020]

@miguel-heygen — addressed in the amended commit 7e93bf8f:

T3 README: The "## The lossy parts (and why threshold = 0.85)" header is now "= 0.90" (matching expected.json). The closing paragraph "A mean SSIM below 0.85 in T3 indicates a structural mismatch" → "below 0.90". Validated mean (0.953) appended so the reader sees the calibrated number alongside the gate.

grep -n "0\.85" over T3 returns no matches now.

[miguel-heygen]

Re-reviewed the latest head. The T3 README now uses the same 0.90 threshold as expected.json and the final skill, so my prior blocker is resolved.