mirror of
https://github.com/heygen-com/hyperframes.git
synced 2026-11-06 22:57:12 +00:00
Vance IngallsandClaude Fable 5.1
4502831f8d
The opt-out was silently ineffective under --docker. `--no-motion-blur` resolves the plan's `motionBlur` to `undefined`, and `buildDockerRunArgs` emitted nothing at all for that state, so the container received no motion-blur argument. The in-container CLI then ran its own `resolveMotionBlurArg(undefined) ?? projectRenderConfig?.motionBlur` and re-enabled exactly the blur the caller switched off — with no diagnostic. That is the AE exporter's own workflow inverted: the exporter writes `render.motionBlur` into `hyperframes.json` for every comp with MB on, so `hyperframes render --docker --no-motion-blur` on such a project rendered blurred, doing the opposite of the flag. `RenderPlan` and `RenderOptions` now carry `motionBlurOff` separately from the resolved `motionBlur`, and `buildDockerRunArgs` forwards it as `--no-motion-blur` — the negated form the in-container citty parser reports as the boolean `false`, the same opt-out the host resolved. When both are set the opt-out wins, matching the host's own precedence. Without this, an absent `--motion-blur` plus a project config is indistinguishable inside the container from `--no-motion-blur` plus that same config. Tests: `buildDockerRunArgs` emits `--no-motion-blur` and no positive flag for the opt-out (and drops the positive flag when both are set); `createRenderPlan` records the durable opt-out alongside the absent option; the real `render` command definition parses `--no-motion-blur` to `false` through citty. Reverting the dockerRunArgs change turns the first two red. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>