[miguel-heygen]

What changed

hyperframes lambda render, lambda render-batch and cloudrun render pick the composition's data-fps when --fps is not passed. When that rate is not one cloud renders support (for example 50 or 30000/1001), they rendered at 30 fps without saying anything, so a 50 fps project came back at 30 fps with no hint why.

They still render at 30 fps, but now print a warning naming the declared rate, the supported set and --fps. The 30 fps default moved into the helper (defaultCloudFps), so the three call sites no longer each carry their own ?? 30.

I chose a warning over an error so existing renders keep working; turning it into an error is a one-line change if that is preferred.

What I measured

• packages/cli/src/utils/compositionFps.test.ts: exit 0, 15 passed. New cases: supported rates (24, 25, 30, 60) return themselves with no warning; 48, 50 and 30000/1001 return 30 and warn once naming the declared value; no data-fps or no index.html returns 30 with no warning.
• tsc --noEmit in packages/cli: clean.
• Mutation: removing the warning makes exactly the three "falls back to 30 and warns" cases fail (3 failed, 12 passed).

What I did NOT exercise

• No real lambda / cloudrun render; the change is in the CLI's fps default only.

[jrusso1020]

The code is fine at 9ba7ee4e. I'm holding the approval only because of the stack.

The PR targets cloudrender/fps-owner (#5756's branch), which has no branch protection. An approval here would let this merge into #5756's branch before #5756 lands, and only a handful of checks run against that base: the required main contexts (Build, Test, Typecheck, windows, edit accuracy, and the rest) haven't run on this head. Once #5756 merges and this is retargeted or rebased onto main with green CI, re-pin and I'll approve.

What I checked:

• defaultCloudFps keeps the old resolution order exactly: --fps flag, then a supported data-fps, then 30. It only adds a console.warn (stderr, so --json stdout is untouched) when the project declares a rate outside DISTRIBUTED_FPS. A missing data-fps or an unreadable index.html still falls back to 30 silently, which is right: nothing was declared.
• All three call sites are converted (lambda render, lambda render-batch, cloudrun via resolveCloudRunFps), and code search finds no other caller of the removed readAllowedCompositionFpsFromDir.
• An explicit --fps 50 still errors as before, since the flag path doesn't go through the helper.
• The tests cover each branch, including the fractional 30000/1001 rate.

No live run.

— Rames

[github-actions]

Edit accuracy: accurate 271 (base branch 271), smooth 188 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)

Unstable (1)

• resize-keys-px-r0-nested-z100-on: tracking 0.07, pressJump 0, drop 0, reload 0, render 0.03, renderKey 0.03, undo true, teleport true / tracking 0.07, pressJump 0, drop 0, reload 0, render 0.03, renderKey 0.03, undo true, teleport true / tracking 0.07, pressJump 0, drop 0, reload 0, render 0.03, renderKey 0.03, undo true, teleport true

[jrusso1020]

Approving at 4592b572. This is the hold I posted at 9ba7ee4e (stacked on #5756), now lifted. #5756 has merged, this PR targets main, and its own commit is unchanged: the same four files, +50/−60, the same hunks as the commit I reviewed. A search on the rebased head finds no caller of the removed readAllowedCompositionFpsFromDir.

The earlier read still holds:

• defaultCloudFps keeps the order: --fps, then a supported data-fps, then 30.
• It only adds a stderr warning when the declared rate isn't in DISTRIBUTED_FPS.
• All three call sites (lambda render, lambda render-batch, cloudrun) use it, and an explicit unsupported --fps still errors.

Required CI is green at this head. No live run.

— Rames