[miguel-heygen]

What

hyperframes check now waits for the composition to become render-ready for 45 s by default, the same constant snapshot and render use (DEFAULT_CONFIG.playerReadyTimeout). The --timeout flag default and DEFAULT_CHECK_OPTIONS.timeout both come from it; the docs line is corrected (it said 3000).

Why

On slow machines and heavy scenes (a 4-core, 4 GB Windows laptop; a local 3D scene) check failed with "Runtime did not become render-ready within 10000ms" while snapshot and render of the same project were allowed 45 s. The 10 s lived in two places (the option default and the flag default), apart from the constant the other commands use.

Related work

Refs the report that check should wait while the page still makes progress and fail only when it stalls; this change only removes the disagreement with snapshot/render and does not add progress detection.

How

DEFAULT_CHECK_OPTIONS.timeout takes DEFAULT_CONFIG.playerReadyTimeout; the flag's default is String(DEFAULT_CHECK_OPTIONS.timeout), so there is one owner. An explicit --timeout still wins.

Test plan

• Unit test added: waits for the composition as long as snapshot and render do unless --timeout says otherwise (packages/cli/src/commands/check.test.ts). fails without the fix: before the change it received 10000 where 45000 was expected; after, check.test.ts 157 passed, checkBrowser.test.ts 68 passed.

• Manual testing performed: not run on a slow machine.

• Documentation updated (if applicable)

• Comments follow CONTRIBUTING.md "Comments"

• Review fix: the warning that tells a person to raise --timeout (checkBrowser.ts, two places) named 20s, which now lowers the 45 s default. It is one exported constant (RENDER_READY_WARNING_SUFFIX) whose example is twice the default (90s), and the stale 3000ms doc comment now says 45 s. fails without the fix: names a --timeout above the default, so following it never lowers the wait (checkBrowser.test.ts) is red alone with the example shrunk (expected 18000 to be greater than 45000); checkBrowser.test.ts + check.test.ts 226 pass.

Size

A lone one-constant fix (the change is the constant, one test and one docs line); nothing open to fold it into.

[mintlify]

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

Project	Status	Preview	Updated
hyperframes	🟢 Ready	View Preview	Nov 1, 2026, 10:07 PM

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

[heygengenesis]

Verdict: APPROVE · 0 blocker · 1 important · 1 nit · head 9d3c07ca

The default check timeout now comes from one place, and the body has the fails without the fix: line naming the new test.

• important: this change makes the timeout hint wrong. packages/cli/src/utils/checkBrowser.ts:385 and :542 still say raise --timeout (for example 20s). Now that the default is 45 s, a user who hits that warning and follows the hint would lower the budget. Change the example to something above the default (e.g. 2m) or drop the number.
• nit: the doc comment at checkBrowser.ts:197 still says check's render-ready wait "defaults to 3000ms (DEFAULT_CHECK_OPTIONS.timeout)".

Scope

Read the full diff. Traced options.timeout at head through idleWindow (still max(120s, timeout+10s), so 120 s), the navigation and render-ready timeouts of openSettledCompositionPage (×3), and auditClipDurations. That last one now waits up to 45 s for media that never loads, which matches what snapshot and render allow. The cli package already depends on @hyperframes/engine, and DEFAULT_CONFIG.playerReadyTimeout is the fixed 45_000, separate from env resolution. CI and Docs were still running when I reviewed. No earlier reviews.

— Genesis V2

[github-actions]

Edit accuracy: accurate 271 (base branch 271), smooth 114 of those

The gate passes.
Smoothness is reported in the artifact, not gated. A case fails only if it fails 2 of 3 runs.

Quarantined, measured but not gated (0)

[heygengenesis]

Verdict: REQUEST CHANGES — 2 resolved, 0 open, 1 new (blocker) · 9d3c07ca → 8bf6fd36

The 20s hint and the 3000ms comment are fixed. The blocker is that this head breaks two checks in packages/cli/src/utils/checkBrowser.ts:

• Preflight format:check fails on this file (job). The cause is the double blank line after RENDER_READY_WARNING_SUFFIX and the two renderReadyWarningSuffix: values split onto their own lines. Preflight failing also turns Windows render verification and preview-regression red. Fix: bun run format.
• Comments ratchet fails (run): checkBrowser.ts comment share rose from 4.0% to 4.1%, and a file's share may only go down. The new /** What a render-ready warning tells… */ line is the added comment. Drop it; the constant's name already says it.

— Genesis V2