[vanceingalls]

What

Documents capture motion blur (opt-in, shipped in #5875–#5992), which had no docs and no agent guidance.

• docs/guides/motion-blur.mdx (nav: after HTML in Canvas): how to opt in, the data-motion-blur* attributes and defaults, browser requirements for preview and render, the cases where blur turns itself off, the hyperframes check findings, cost and known limits.
• skills/hyperframes/references/motion.md: one bullet telling agents when to suggest data-motion-blur="on", when to skip it, and to verify with hyperframes check.
• skills-manifest.json: content hash for the edited skill.

Notes

• Chrome 157/158 "no flag" was verified on headless and Chrome-for-Testing builds only, not stable. The page states it as builds that expose the API.
• Render cost (about 1.7x median) and the limits list come from the stack's PR bodies.

🤖 Generated with Claude Code

[mintlify]

Preview deployment for your docs. Learn more about Mintlify Previews.

Project	Status	Preview	Updated
hyperframes	🟢 Ready	View Preview	Oct 22, 2026, 10:17 PM

💡 Tip: Enable Automations to automatically generate PRs for you.

[miguel-heygen]

Reviewed exact head 64447cf481b0979e0afaf8f9b6cc67538fa1295d against 4371981b740d92f70e520cfbec34db68a1c93434. The attribute defaults (docs/guides/motion-blur.mdx:29–32), opt-out discovery, and check finding codes/severities (:74–76) match the current core/CLI implementations. Full four-file delta read, including skill and generated manifest.

Two documentation corrections are inline: qualify the first-frame guarantee to defects found by the timeline scan, and scope the Chrome 157/158 no-flag statement to the measured headless/Chrome-for-Testing builds. These change what readers can rely on, rather than requesting runtime changes.

CI evidence at 22:51Z: Lint, formatting, skills manifest and skills tests passed. I read the underlying completed logs: manifest is in sync. Validate docs failed before validating MDX because npm could not resolve @mintlify/link-rot@3.0.1508 during npx mint validate; schema sync passed. This is a tool dependency failure, not evidence of invalid MDX, but docs validation remains unperformed. Build and several other checks were still running at that snapshot. The reported 1.7×/20-composition cost and visual measurements match recorded stack author evidence; I did not reproduce benchmarks, browser support or pixel measurements. No install, runtime/browser run, worktree, merge or deployment.

Nonblocking accuracy: docs/guides/motion-blur.mdx:36,82 should distinguish no per-frame blur work from the nonzero one-time discovery scan; :78 can mention the additional session-end log when failedFrames > 0.

— Magi / desktop-review
Verdict: REQUEST CHANGES
Reasoning: The guide currently promises stronger fallback behavior and browser availability than the source and recorded measurements establish. Correct those claims and obtain actual docs validation through the normal check.

[miguel-heygen]

[P2] Limit the first-frame guarantee to defects found by the initial scan

This promises that a listed defect never switches blur during a render, but captureMotionBlur/index.ts deliberately handles defects missed by the scan through plainFrame(): it unwraps only that frame, increments failedFrames, and keeps state: "on". The existing tests at index.test.ts:405–475 cover a late WebGL canvas, a root shake between samples, and a briefly flipped hidden face; frames before/after can still blur. Please say that scan-detected defects disable the composition from the start, while late/missed defects can produce individual sharp fallback frames (and mention failedFrames for diagnosis). This needs a documentation correction, not a change to the intended runtime behavior.

[miguel-heygen]

[P2] Put the measured browser-channel limitation in the published guide

In the “Studio preview uses your own browser” requirements, “Chrome 157 and 158 builds expose the API without a flag” reads as a browser-version support promise. The PR body explicitly says the no-flag observation was only on headless and Chrome-for-Testing builds, not stable. That limitation is absent from the page users will read. Please name those tested build types here and say stable availability is unverified; keep feature detection/the sharp fallback as the actual contract. No new browser benchmark is required.

[miguel-heygen]

Re-review at 2e02444a2737254c5d422ef100ff1e2ed6add4f5: both earlier documentation blockers are resolved.

docs/guides/motion-blur.mdx:51 now distinguishes scan-wide disabling from per-frame sharp fallback and failedFrames, matching blockedByScan, plainFrame and the late-defect tests. Line 45 confines the Chrome 157/158 observation to headless/Chrome-for-Testing and explicitly leaves stable Chrome unverified. Lines 36 and 78 also clarify discovery cost and the session-end log.

I read the complete four-file delta and rechecked the current runtime, feature detection and render logging; those runtime blobs are unchanged from the previously audited head. The manifest-sync job executed successfully. Build and Validate docs are still running in my current job reads, so their earlier failures are not claimed cleared by this review. No current failure was reported in the head check snapshot. Browser availability, performance and parity measurements remain author evidence; I did not run a browser or benchmark.

Verdict: APPROVE
Reasoning: The two requested factual corrections now match the shipped implementation and accurately bound the browser evidence. Normal remaining CI still governs landing.

— Magi desktop-review