Repository navigation
feat(cli): lambda render --width/--height at a whole-number multiple renders at that scale - #6390
Conversation
…renders at that scale
Edit accuracy: accurate 271 (base branch 271), smooth 135 of thoseThe gate passes. Quarantined, measured but not gated (0) Unstable (3)
|
![heygengenesis[bot]](https://avatars.githubusercontent.com/in/2913576?s=60&v=4){kind=small}
There was a problem hiding this comment.
Verdict: APPROVE · 0 blocker · 1 important · 1 nit · head ef8d4ef7
- important —
skills/hyperframes-cli/references/lambda.md:104(the agent-facing CLI skill) still says a mismatched--width/--height"silently produces 1080p" and prints a warning that's suppressed under--json. At this head the same input renders at scale 2 or fails before deploy. Agents reading that reference will give wrong advice. Rewrite the paragraph to the new rule and regenerateskills-manifest.json.docs/packages/cli.mdx:2250("Render dimensions in pixels") could take the same wording as the new flag help.
Scope
I read every changed file. The distributed planner only validates config.width/height and lays out from the composition, so a derived outputResolution takes the same path as --output-resolution. The aspect-agnostic flag stays false on the derived path, which is correct because the preset is concrete. In render-batch the check runs before the variable pre-validation and before any AWS call. CI is green at this head. cloudrun render still ignores a mismatched --width/--height without a word. That predates this PR and is out of its scope; parity there is a possible follow-up.
| if (width < compositionWidth || height < compositionHeight) { | ||
| return { | ||
| ok: false, | ||
| message: `${width}×${height} is smaller than the composition (${composition}). Use the composition's size, or a whole-number multiple of it.`, |
There was a problem hiding this comment.
nit — this branch also catches a wrong orientation, not just a smaller size. A portrait 1080×1920 composition run with the --width 1920 --height 1080 that every documented example uses gets "1920×1080 is smaller than the composition (1080×1920)", and that's probably the most common way to land here. Something like "does not match the composition (1080×1920)" when one side is larger and the other smaller would point at the real fix.
lambda render --width 3840 --height 2160on a 1920×1080 composition used to render at 1080p and only print a warning, so a 4K export meant rewriting the canvas.A size that is a whole-number multiple of the composition's own now renders at that scale (3840×2160 on 1920×1080 is scale 2), through the same output-resolution path as
--output-resolution. The rule lives next to the existing preset compatibility check, so the aspect and whole-number constraints are the same ones the render pipeline enforces. The composition's own size changes nothing. A smaller size, or one that is not a supported multiple, fails before anything is deployed with a message naming the composition's size and the sizes available. An explicit--output-resolutionstill wins, and a site with no local project is passed through untouched.Tests cover the multiple, the composition's own size, an unsupported or smaller size, an explicit preset, and a missing project.
Not covered: only multiples that match a preset size (for example 3840×2160, 2160×3840, 2160×2160) are accepted; any other multiple, like 2560×1440 on 1280×720, is refused until the pipeline takes an arbitrary scale. Local
hyperframes renderhas no width/height flags, so it keeps using--resolutionand the same compatibility check.