Context: a multi-scene HyperFrames project (index.html mounts scene files from compositions/ via data-composition-src). Rendering one scene alone with npx hyperframes render -c compositions/m1-bold.html -o renders/m1-bold.mp4 --quality delivery on hyperframes CLI 0.8.82.
Observed: the render logs sub_timeline_readiness_timeout ... still unregistered: main and sits for ~45 s before frame capture starts, on every -c render. The scene file registers its own timeline correctly (window.__timelines["m1-bold"] = tl), and the finished MP4 is correct: 1080x1920, 30/1, exact duration, animation plays (verified by extracting frames at 0, 1.6, 2.3, 3.0, 7.9 s). Rendering the full root (render -o renders/reel.mp4, where index.html registers window.__timelines["main"]) has no stall.
Takeaway: the stall is a harmless wait for a root timeline id that a lone scene file never defines, not a sign the scene is broken. Don't debug the scene's timeline registration over it. For batch per-scene renders, either accept ~45 s overhead each (parallelize with xargs -P), or render each scene through a tiny root file that mounts it and registers main.
Related on the same version: snapshot --review is not available (use snapshot --at t1,t2,... --no-end -o dir for contact sheets), and hyperframes usage is an unknown command.