4311 Commits

This Branch

This Branch

All Branches

Author	SHA1	Message	Date
miga-heygen	b65933b112	fix: honor FFMPEG_PROCESS_TIMEOUT_MS during video-frame extraction ... FFMPEG_PROCESS_TIMEOUT_MS resolves correctly into EngineConfig and is correctly forwarded to the audio-extraction ffmpeg call, but runExtractVideosStage (shared by both the in-process renderer and distributed plan()) built the config object it passes to extractAllVideoFrames with only { extractCacheDir, extractCacheMaxBytes }, silently dropping ffmpegProcessTimeout even though the full EngineConfig was already in scope. That config flows straight into extractVideoFramesRange, which falls back to a hardcoded 300s deadline whenever the field is undefined -- so video-frame extraction always used a fixed 300s timeout no matter what the env var was set to. Threads cfg.ffmpegProcessTimeout into that config literal the same way the two cache fields already are. Co-Authored-By: Miguel Angel <miguel.sierra@heygen.com>	2026-09-13 02:37:40 +00:00
Miguel Ángel	f86aae655a	chore: release v0.8.36 (#3911) v0.8.36	2026-09-12 13:03:01 -04:00
Miguel Ángel	4c6fa9a790	fix(studio): the preview stays paused, survives typing, and opens without a re-encode (#3910) ... * chore(studio): remove the write-only self-write timestamp ref `domEditSaveTimestampRef` was assigned at 26 sites across 54 files and read nowhere. It used to feed a 2 s "suppress the watcher reload after our own write" window; that mechanism was replaced by content-hash identity in sdkSelfWriteRegistry, whose header still says why (a clock cannot tell an SDK self-write echo from an undo landing in the same window). The reader went with that change, the writers did not, and three comments kept describing the timestamp as protection that no longer existed. Pure deletion: the ref, every prop and parameter that threaded it, every assignment, the five comments citing it, and the orphaned test helpers. No behaviour change; the studio suite, typecheck, lint and format are green. Not removed: the __hfSuppressSceneMutations wrapper in gsapSoftReload.ts. It looked undefined from inside the studio package, but shader-transitions installs it on the preview window (hyper-shader.ts) so soft reloads do not invalidate cached transitions. It is live. * docs(studio): plan for loading the preview during the shell's first layout * fix(runtime): a paused preview stays still after any seek Sub-compositions kept animating while the transport was paused and the Studio button showed play. A render-seek unpauses every sibling timeline so GSAP propagates the root's totalTime into them, and nothing paused them again; parented to the global ticker, they free-ran at 1x while the master timeline and the clock stayed stopped. The Studio reaches that seek path through its seek-driven fallback adapter right after a preview reload, which is why editing text was what set it off. Captured live in the user's preview: seven child timelines advancing 0.210s per 200ms sample, all gsapPaused=false, transport not playing. Three fixes under one invariant: while the clock is paused nothing runs, and the button never disagrees with the runtime. - The sibling rearm is a lease, not a resting state: seekTimelineAndAdapters now returns every timeline it unpaused to paused in a finally. The second rearm after the child re-seek only ever changed the leaked state and is gone, with the comment that justified the leak by describing one caller. - The paused side of the transport tick policed nothing; it now stops any timed media element found running. A parked transport runs no ticks, so a capture-phase play listener wakes it. - Studio's canvas click resumed by setting the store flag alone; it now requests playback through the player so adapter, rAF loop and flag agree. Regression tests fail without each of the three changes. * perf(studio-server): stop re-encoding videos the browser already plays on open Opening a project kicked off a background transcode for every asset whose codec some browser might not decode. VP9 is on that list for Safari's sake, so a Chrome user opening a project with a VP9 avatar paid a ~10s, ~60 CPU-second re-encode across six cores on every open, concurrently with the browser's first layout, for an output nothing ever requested: across four recorded sessions the browser asked for the proxy zero times. One predicate was doing two jobs. "Could some browser fail on this" is a property of the asset and decides what gets injected into the page; "will this client request the substitute" decides whether to spend CPU before being asked. The codec table now carries an explicit prewarm flag: HEVC and ProRes (no browser decodes them) still warm; VP9 and AV1 are injected but transcoded lazily by the existing ?hf-proxy= request, which already reports failure as a 502. Pre-warms requested and proxies served are now counted on the existing structured-stderr telemetry channel, because a speculative job with a 0% hit rate emits no error and had been invisible. A single lookup helper also closes a prototype-key gap where one path used Object.hasOwn and the other a bare index. Regression test: a VP9 and an HEVC asset in one composition yield exactly one pre-warm, for the HEVC. Fails on the previous gate. * perf(cli): serve the studio bundle compressed and cache hashed assets The 4.1MB studio bundle was served uncompressed with Cache-Control: no-store, so every open of the studio re-downloaded and re-parsed it. Vite names built assets with an 8-character content hash, so their bytes can never change: those now ship gzip-compressed (1.25MB on the wire, byte-identical after inflation) with a one-year immutable cache policy. Unhashed files under public/ keep no-store, and the HTML shell, which previously sent no Cache-Control at all, now sends no-store explicitly: it is the only thing that names the current hashed bundle, and it must keep revalidating for the immutable policy to be safe. The hash test only accepts the segment after the last hyphen and requires a digit, underscore or capital, so an ordinary hyphenated name like user-Guide-v2.js is not mistaken for a hash and served forever. * perf(cli): warm the preview route before the browser opens The browser's first request for a project's preview paid the server's cold compiler import and first bundle in the request path, after the studio shell's own first-layout stall, so both costs landed on the user's time-to-first-frame in series. The CLI now issues one fire-and-forget request for the preview route from openStudioBrowser, the single funnel for every launch path, before the --no-open early return so pasted URLs benefit too. Measured on the demo project: first client request 231ms before, 101ms after; the ETag 304 path afterwards is under 1ms. The fetch carries a 10s abort so an unsettled connection cannot keep an otherwise-finished CLI process alive, matching the package's existing convention. The shader query params the player appends are not part of the route's cache key, so the plain route URL warms the same entry. * perf(studio): request the player chunk before the shell's first layout The dynamic import of @hyperframes/player ran inside the preview's mount effect, which React schedules after the shell's first layout. On a cold open that layout stalls the main thread for seconds, so the chunk request waited behind it for no reason. The import is now kicked at module scope, behind a typeof window guard that preserves the documented SSR contract (the module registers a custom element at load), and the mount effect awaits the already-in-flight promise. Verified in the built bundle: the preload call sits at module top level, so the request goes out on bundle evaluation. * fix(studio): editing a text property no longer reloads the preview Every keystroke in the Design panel writes the composition file, the file watcher announces the change to the studio, and the studio decides whether the change was its own. Over the CLI's event stream that decision has never worked: the browser hands the handler a MessageEvent whose data is a JSON string, and three of the four payload readers (version, write token, content) only understood an already-parsed object, so they read every field as absent. An absent token means "someone else edited the file", and the studio hard-reloaded the preview iframe on its own edit, blanking it for seconds. The path reader alone knew how to unwrap the string, which is why the event was recognised well enough to reload and never well enough to suppress. The envelope is now decoded once, at the boundary, by one function that all three transports feed; the readers share one field accessor so they cannot diverge again. The production event-stream rung is extracted into an exported channel so a test can drive a real MessageEvent through the listener it registers, which was impossible before because vitest defines import.meta.hot and the selection never reached that rung under test. A second, smaller cause: the server attached the write receipt to the first subscriber only and deleted it on read, so any other listener saw an unlabelled change. Reads are now non-destructive with the TTL as the only eviction, scanning newest-first because identical bytes written twice inside the TTL (undo, retyping a value) share a version and the older token was already spent. The file version now ships with every event, receipt or not, so duplicate deliveries of one change dedupe instead of reloading once each. shouldReloadSdkSession had no production callers and a signature that invited an undecoded delivery straight back into this bug; it is removed. consumeFileWriteReceipt stays as a deprecated alias for one release. Regression tests: a Studio write delivered as a real SSE MessageEvent is suppressed; two subscribers of one watcher event reload once; a genuinely external write still reloads; a repeat of earlier bytes gets the newest token; a receipt past the TTL is not recognised. Each fails on the code before it. * fix(runtime): paused-time media playback is borrowed, not banned The paused-side enforcement added in the previous commit had no notion of provenance, so it stopped two features that legitimately play media while the transport clock is paused. Both were deterministic, not racy: the capture-phase `play` listener means the very play() that starts them wakes the transport that stops them. - The colour-grading preview (colorGrading.ts startPreviewPlayback) plays a video while paused to render grading previews. It went dark on the first paused tick. - The Studio's scrub audition (timelineIframeHelpers.ts applyScrub) plays the music track for ~140 ms while paused so a playhead drag is audible. Same path killed it. A runtime-owned lease fixes both without weakening the enforcement. One owner: a WeakSet in the runtime closure, with lease/release published on the existing window.__hf surface for the Studio, which reaches the element across the iframe boundary and cannot call into the closure. The grading runtime is constructed with the pair directly. Both the cheap probe and the sync path skip leased elements while the clock is paused; during playback the transport owns everything again. Anything that plays while paused without a lease is, by definition, the defect the enforcement exists for, and is still stopped. Two corrections to the previous commit's reasoning: The old leak broke the render path too, deterministically, not only the preview. packages/producer/src/services/fileServer.ts:375-379 seekToTime flushes the virtualized rAF queue, and GSAP's global ticker with it, after renderSeek and before the frame screenshot (fileServer.ts:657-664, hf.seek). A sibling left unpaused therefore advanced by the full inter-frame delta into the captured frame. The finally added in the previous commit fixes that as well. Deleting the second activateSiblingTimelines is safe because nothing between frames reads a sibling's paused(), verified by grep over the deterministic adapters, syncTimedElementVisibility, the hf-timelines-built handler and __hfReseekGpu. Not merely because seekStandaloneRegisteredTimelines pauses each child. The code comment now gives that reason. Tests, each proven non-vacuous by reverting the piece it guards: - a leased element survives repeated paused ticks and is stopped once released - the colour-grading preview survives, through the real init wiring - the scrub borrows the element and gives it back on stop - the existing test that an unleased element is still stopped keeps passing * test(runtime): a lease ends when the transport plays or the borrower stops Two assertions the review found not load-bearing. Dropping the isPlaying branch so leased media stayed exempt during playback left every test green; a leased out-of-window clip is now asserted stopped the moment the transport plays. Deleting the release in the grading stop closure also left the suite green, because the pause on the next line satisfied the assertion; a restart after stop is now asserted stopped, which only the release makes true. * test(studio): the event-stream channel must open /api/events * fix(studio-server): stop printing a proxy diagnostic line per clip on every render Review of the pre-warm commit found the diagnostic louder than the thing it diagnoses, and the two counters measuring different things under one name. The per-asset `prewarm_requested` line is now behind HYPERFRAMES_DEBUG_MEDIA_PROXY, matching isGpuProbeDebugEnabled in packages/engine/src/utils/gpuEncoder.ts. A composition with fifty hostile clips printed fifty JSON lines into a clack-formatted terminal on every re-render. One summary line is written at process exit instead, using the same process.on("exit") shutdown hook as packages/cli/src/cli.ts. The counters now share a unit. prewarmsRequested counts per asset per render; proxyRequests counted every HTTP request, including 304s. It now increments once per resolveProxy call, after the ETag shortcut, so a revalidated repeat no longer reads as fresh demand. An unconditional Range refill still counts, and the docstring says so rather than claiming otherwise. The HEVC justification was false on macOS Chrome, which answers canPlayType for hvc1 with "probably" and keeps the source, so the pre-warm is redeemed there only through the reactive zero-videoWidth path. prewarm stays true because Chrome on Windows/Linux and Firefox do need the substitute; the comment and test names now say "no cross-platform decode" instead of "browsers never decode it". Two test gaps closed. Nulling vp9's representativeMime left the suite green while making the client skip canPlayType and proxy on every browser, which would reinstate exactly the transcodes this work removed; the mimes are now pinned. The Object.prototype test passed with the hasOwn guard deleted, so it now goes through probeAssetCodec, the input that actually misbehaves without it. Both fail when the change is reverted. * perf(cli): stop gzipping the studio bundle on loopback Compression made the cold open slower on the only transport this server has. It binds 127.0.0.1 with no --host, and measured there the six bundle assets took 69.8 ms with gzip against 7.9 ms raw; the 4.1 MB chunk alone was 49.4 ms against 3.1 ms. hono/compress is removed, which also retires the Vary header question it raised. If remote serving ever matters, compress at build time rather than per request. The cache policy is now decided by route instead of by filename. Reading a content hash out of a name cannot work: rollup's alphabet is base64url and includes a hyphen, so roughly one hashed file in ten was misread as unhashed, and the immutable header also leaked onto hand-authored public/ files served by the same handler. packages/studio/vite.config.ts sets neither build.assetsDir nor publicDir, so dist/assets holds only rollup's hashed emits and every public/ file lands at the dist root. /assets/* is therefore immutable and /icons/* and /favicon.svg keep revalidating, with no heuristic in between. The shell is no-cache rather than no-store. It carries no ETag, so both force the same full refetch, but no-store puts the document on Chrome's bfcache blocklist: leaving Studio and pressing Back would cold-boot the app instead of restoring it. * docs(runtime): say what the paused-media probe actually filters * revert(cli): drop the preview prewarm that held the CLI event loop The fire-and-forget warm added in c9b4263c7 keeps the CLI alive until it settles. cli.ts drains the event loop instead of calling process.exit, and two launch paths return straight into exit, so the warm delays them: 2660 ms with the warm suppressed, 8779 ms against a server answering in 6 s, 13293 ms against one that hangs. The 10 s abort bounds the hold, it does not remove it. This is the hazard already documented at preview.ts:1605-1609. Moving the warm into the server process was the obvious fix, but measurement says there is nothing there to warm. tsup bundles @hyperframes/core/compiler into cli.js -- bundleToSingleHtml is a plain inline function in the artifact -- so the await import() at studioServer.ts:397 resolves an already-evaluated namespace. A probe at listen time measures that import at 1 ms, and a paired run shows no gain: first request 256 ms without a compiler kick, 308 ms with one. The cold cost the plan attributed to the module load is somewhere else. Two claims in the reverted comment were also wrong: routes/preview.ts:332 is an ETag, not a bundle cache, and the player appends no shader params -- the only query param is variables, which IS part of the ETag. Reverts packages/cli to origin/main exactly. * fix(studio): let a remount retry the player chunk after a failed load 1037456aa hoisted the dynamic import to module scope and shared one promise across every mount. On rejection the .then never ran again: retryPreviewRef and previewError stayed null, compositionLoading stayed true, so the preview sat on an infinite spinner with the retry button at Player.tsx:462 unreachable, and remounting <Player key={activeKey}> -- the recovery path that used to work -- awaited the same rejected promise. Memoize through a getter that clears the memo on rejection instead. The module-scope kick still fires the chunk request before the shell's first layout, and a remount performs a fresh import as it did before the hoist. Discloses what the earlier commit did not: the player barrel re-exports Player, so every studio module importing that barrel now evaluates this one and eagerly loads the real player bundle. That is 27 DOM-env test files; the full studio suite passes, 439 files and 4838 tests. * docs(studio-server): trim the proxy-counter comment to the repo's four-line cap * fix(studio): stop one failed player import poisoning every later mount The previous commit claimed a remount could retry the player chunk after a failed load. In a browser it cannot: the module map caches a failed fetch as an errored entry for the document's lifetime, so a repeated import of the same specifier rejects from cache without touching the network (measured in headless Chrome: three attempts, one request). Clearing the memo on rejection is still right, because it stops every later mount awaiting the same poisoned promise, but recovery is a page reload, and the comment now says so. The tests said what vitest does, not what the browser does. Two assertions survived their own mutation: removing the memoisation left the attempt counter unchanged because vitest caches a resolved mock, and deleting the module-scope kick, the optimisation this branch exists for, left the suite green. Both are now asserted directly: the kick has run once at import time before any mount, and every mount receives the identical promise. * chore(ci): allow the deletion of the dead sdk-session reload test * fix(runtime): the timeline resolver no longer unpauses children it cannot drive Exercising the branch in a real browser still showed sub-compositions free-running while paused, on a path no seek follows: the timeline resolver, which runs on every rebind (after an edit, on the periodic bind), unpaused every registered child BEFORE trying to nest it into the root. A child the root actually holds is driven by the paused root and is harmless; a child the root never takes stays on GSAP's global ticker, and unpaused there means running. The seek fix in this branch could not reach it, because a rebind is not a seek. The resolver now reads back which children the root holds and unpauses only those; the same rule applies to the composite fallback timelines. Standalone registry children stay paused, as the transport's per-child seek already requires. Regression test: a hosted registry child whose root cannot nest it stays paused across a forced rebind. Fails on the previous resolver. * test(runtime): pin that the resolver unpauses a child only once the root holds it The resolver's positive half had no fixture: nothing anywhere nested a candidate for real, so computing the held set before the add loop instead of after it left the suite green. A root that reports children only once added now distinguishes the two orders, and the unpause is asserted at the moment it happens, because the transport's first seek pauses every hosted child again straight after resolution. Also drops a cast that re-declared getChildren, which RuntimeTimelineLike already has. * fix(runtime): the paused side stops every clip the transport drives The paused-side enforcement scanned only media carrying its own data-start. A clip inside a composition inherits its timing from the host and has no data-start of its own, yet the transport plays it, so it could start while paused and run unopposed, exactly the hole the invariant was written to close. Reviewer probe: a hosted video with data-duration only kept running while paused; the same element started under __player.play(). "Media the transport drives" now has one definition, shared by the media cache and the paused-side probe, so neither can be narrower than the other. Regression test: hosted media with no data-start started while paused is stopped. Fails against the data-start-only scan.	2026-09-12 12:56:00 -04:00
Miguel Ángel	51a88b9566	docs(catalog): put the install command above the preview (#3888) ... The install command is the one line a reader comes to a catalog page to copy, and it sat below the whole variables explorer, under its Customize panel, a screen or more down on long items. Move the Install section above the preview and regenerate all 399 pages.	2026-09-11 18:15:00 -04:00
Vance Ingalls	63574a7c7f	Merge pull request #3887 from heygen-com/release/v0.8.35 ... chore: release v0.8.35 v0.8.35	2026-09-11 14:35:39 -07:00
Vance Ingalls	4ba8396c27	chore: release v0.8.35 ... Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>	2026-09-11 14:30:23 -07:00
Vance Ingalls	b848d81681	Merge pull request #3878 from heygen-com/docs/require-voiceover-carve ... feat(audio): require the voiceover carve, default strength 0.8, slower release	2026-09-11 14:20:04 -07:00
Miguel Ángel	849ce0176a	fix(catalog): name the better search tier when a search finds nothing (#3872) ... * fix(catalog): name the better search tier when a search finds nothing The hint that tells a scripted caller the on-device tier exists was wired to the branch where the search succeeded, and was silent on the branch where it found nothing. The caller with the most reason to hear it was the only one who never did. It also only ever reached stderr, so a --json caller never saw it at all. The hint is now a returned sentence pushed into the same warnings array the zero-result envelope already serializes, and printed from that one value, so the terminal and the envelope cannot drift. Withheld when the query parsed to no searchable tokens, where the advice is already to search in English, and when a warning has already explained why the tier cannot run here. The consent gate is untouched: nothing downloads, and the sentence still asks the caller to check with a person before enabling it. * fix(review): pass the resolved model status, and pin both hint guards Deriving the status inside the hint helper re-read and re-hashed the on-device model from disk to answer a question the caller had already answered a few lines earlier. It now takes the resolved value. Both guards below the status check were invisible to the suite: every other case pinned a status that already returned null, so deleting either guard passed everything. Two tests now hold them, and each fails for its own mutation. * docs(skills): tell agents to read the tier hint the envelope now carries The CLI skill said that under --json nothing about the offline tier is printed at all. An agent following that sentence would never read the warnings array this branch writes the tier sentence into, so the fix would land in the code and never reach the caller it was written for. It also described warnings as firing only when a tier was asked for and could not run. That is now too narrow: a zero-result search emits the hint with no tier requested. Regenerate skills-manifest.json for the changed content hash.	2026-09-11 17:14:10 -04:00
Vance Ingalls	06897fe0be	style(audio): format carve.test.mjs and re-sync the skills manifest ... The pre-commit format hook's glob does not include .mjs, so the new test file reached CI unformatted while oxfmt --check . covers it. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>	2026-09-11 14:08:10 -07:00
Miguel Ángel	26513984f3	fix(producer): non-DE parallel-stream router silently refused on macOS multi-worker renders (#3886) ... * fix(producer): read useDrawElement post-clamp for the parallel-stream router The non-DE parallel-streaming router read cfg.useDrawElement before the default-on drawElement clamp ran, so on every macOS/GPU-default host with multi-worker renders it saw a stale true and refused to stream even though the render was about to fall back to non-DE screenshot capture anyway. * refactor: trim fix-narrating comments to durable invariants Adversarial simplify pass flagged two comments that described the diff itself (what used to happen, what changed) instead of the invariant that matters going forward. Kept only the forward-looking reasoning. * fix(producer): capture probe console before closing on the DE clamp path; add regression coverage - Extract the default-on drawElement clamp condition into a named, exported, unit-tested pure predicate (shouldClampDefaultDrawElement), matching this file's existing convention for the sibling router predicate. - Preserve lastBrowserConsole when the clamp closes a drawElement probe session, matching every other probe-close site in this function (an adversarial review caught this: on the auto-worker-calibration path, a render that throws after the clamp would report the calibration browser's console instead of the probe's). - Add tests proving the router requires the clamp's post-clamp output, not its input — the exact ordering bug PRINFRA-689 was about. * test: drop internal link and fix-narrating comment from new regression test A test comment I added carried an internal Slack archive link (this is a public repo) and described the diff instead of the invariant — the user caught it in review after my own simplify pass had already run and missed it, since that pass ran before this test file existed. * refactor: collapse duplicated ordering-invariant comment into one place Two comment blocks explained the same 'why deParallelStreamForced alone is safe here' reasoning, one forward-referencing the other. Stated once.	2026-09-11 17:06:32 -04:00
Vance Ingalls	e488871ce1	fix(audio): pin the slower release and the carve default, fold the requirement, sync the manifest ... Review at fe53f51a: the moved test points passed at both 1.6s and 2.4s, so a revert of DUCK_RELEASE_S was silent. Add the 9s probe that reds on 1.6s. Export DEFAULT_STRENGTH and parseArgs from carve.mjs and pin 0.8 in carve.test.mjs. Fold the new requirement paragraph into the existing 'Carve by default' one so the rule is stated once. Regenerate skills-manifest.json after the last edit. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>	2026-09-11 13:57:07 -07:00
miga-heygen	42a3e7a519	fix(skills): loop-extended BGM writes .mp3, not MP3-in-a-.wav (#3884) ... ensureBgmCovers() (duplicated in faceless-explainer, pr-to-video, and product-launch-video's assemble-index.mjs) always re-encodes a short BGM track with libmp3lame, but preserved the source asset's own extension when naming the loop-extended output — so a "bgm.wav" source produced "bgm.loop.wav" containing genuine MP3 audio. ffprobe/ffmpeg/Chromium all decode this correctly via the WAVE_FORMAT_MPEGLAYER3 tag, but a naive/strict WAV parser (e.g. Python's stdlib `wave` module) hard-fails on it. The function's own doc comment already documented the intended output as "*.loop.mp3" — the code just didn't match it. Fix: always emit a .loop.mp3 path regardless of the source extension. music-to-video's assemble-index.mjs does not have this function (it uses the raw BGM asset directly, no loop-extension), so only 3 of the 4 skills needed the change. Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-11 16:07:49 -04:00
Vance Ingalls	fe53f51adb	fix(core): slow the voiceover carve's level release to 2.4s ... At 1.6s the bed audibly came back at every sentence break on narrated builds, which reads as the effect switching off rather than the mix breathing. 2.4s lets it swell back over a breath. Band-filter release is unchanged; a notch closing is inaudible. Test timings move with the constant. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>	2026-09-11 11:27:37 -07:00
Vance Ingalls	2e2b5c8530	feat(hyperframes-audio): default the voiceover carve strength to 0.8 ... 0.25 left the bed audibly fighting the voice; a build carved at 0.25 had to be redone at 0.8 before it was accepted. Make carve.mjs default to 0.8 and rewrite the strength prose and the sample output to match. The core DEFAULT_CARVE used by the Studio panel is unchanged. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>	2026-09-11 11:24:18 -07:00
Vance Ingalls	0b9852fee4	docs(skills): require the voiceover carve whenever music plays under a voice ... The hyperframes-audio skill described the carve as one option among several, so builds with BGM under narration shipped with only a volume duck. Make it a requirement in the three places an agent reads while assembling audio: the carve section of hyperframes-audio, general-video's Assemble step, and the production loop's Audio stage. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>	2026-09-11 10:25:50 -07:00
miga-heygen	ea7e1dbd0b	fix(cli): surface a warning when doctor's HYPERFRAMES_PYTHON override is rejected (#3870) ... ## Summary - `findPython()` correctly resolves `HYPERFRAMES_PYTHON` before falling back to the PATH probe — that part already works, confirmed by direct testing. But when the override is set and fails validation (nonexistent path, non-executable, non-Python-3 output, timeout), it silently falls through to the PATH probe with zero diagnostic. A user whose override had any subtle issue got a plain "Not installed" from `doctor` with no signal the variable was even seen. - This is a corrected, narrower version of a report that originally claimed `doctor` ignores `HYPERFRAMES_PYTHON` entirely — that claim was refuted directly (the override resolution works). The real defect is the silent validation-failure path. - Extracts the override-validation logic into `validatePythonOverride()` and adds `describeRejectedPythonOverride()`, which `doctor`'s TTS (Kokoro) and BGM (MusicGen) checks now call to append the rejection reason to their `detail` when applicable. `findPython()`'s own behavior (including its fallback) is unchanged. PRINFRA-669 ## Test plan - [x] New `packages/cli/src/tts/python.test.ts`: `describeRejectedPythonOverride` returns null when unset / when the override validates; names the override + exception message when the override can't run; names the override + actual output when it isn't Python 3; `findPython` still falls back to the PATH probe when the override is rejected (unchanged behavior) and still uses a valid override directly. - [x] Confirmed RED against the pre-fix source (tagged stash) — all 4 new `describeRejectedPythonOverride` tests failed with "not a function"; GREEN after restoring the fix. - [x] `bunx tsc --noEmit`, `bunx oxlint`, `bunx oxfmt --write` clean on changed files. - [x] `bunx fallow audit --base origin/main --fail-on-issues`: no issues in the 3 changed files. - [x] Full `packages/cli` vitest suite: 3033/3038 passing (2 pre-existing unrelated failures — a PID/socket sandbox quirk and an agent-env-var-pollution test — plus 4 browser-test files failing at collection on a pre-existing `node:` builtin import issue under this sandbox's happy-dom setup; all confirmed identical on pristine `origin/main` and unrelated to this change, consistent with every other fix from this backlog-drain session). 🤖 Generated with [Claude Code](https://claude.com/claude-code)	2026-09-10 23:57:11 -04:00
miga-heygen	2ef76bf97b	fix(lint): flag an unclosed tag that swallows a nested element as bogus attribute text (#3869) ... A start tag missing its closing `>` before the next `<` (e.g. a bad string-replace that leaves `<img ... <div class="hl"></div>` behind) is parsed leniently by the browser's HTML5 tokenizer: the `<div` text is consumed as a bogus attribute name on the still-open `img` tag, and the intended element never becomes a real DOM node. No existing lint/check gate catches this — they all operate on the resolved DOM, which looks structurally valid once the browser has already dropped the element. Adds `unclosed_tag_swallowed_element`, a new core lint rule that flags any parsed tag whose attribute text contains a `<` outside a quoted value (a legitimate attribute value may itself contain a raw `<`, e.g. `data-expr="x < y"`, which htmlparser2 parses correctly and is not flagged). PRINFRA-668 Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-11 03:46:54 +00:00
miga-heygen	bafc7b4e00	fix(cli): stop promising a universal per-time filmstrip for --layout strip (#3867) ... ## What `keyframes --shot --layout strip`'s help text, its type's inline doc comment, and the CLI reference docs all described `strip` as an unqualified "filmstrip by time." The tool doesn't actually do that for the overwhelmingly common case. ## Why A real per-time pixel filmstrip is only produced when the sampled selector is an SVG element (gated by an internal shape check — `typeof element.getBBox === "function" && typeof element.getScreenCTM === "function"`). Any other selector — including every nested sub-composition host, which is always a `<div data-composition-src>` — silently falls back to one live screenshot plus vector position markers instead. This isn't a capture bug: for a non-SVG selector, real per-time pixel compositing was never implemented, only 3D bbox/marker sampling. But the documented behavior over-promised what the tool does, so a user following the docs on the common case (a DOM/sub-composition selector) sees root captions and empty image boxes where they expected the nested composition's actual content to move across frames — the diagnostic strip is misleading, even though the real render is correct. ## How Reworded all three descriptions (CLI help text, `ShotOptions.layout` TSDoc, and the reference docs table) to state the SVG-only condition and the DOM/sub-composition fallback explicitly. No behavior changed — this is a documentation-accuracy fix, per the ticket's own framing that a doc-only fix fully resolves the reported symptom (a silent, misleading omission) for a P3. ## Testing Added a test asserting the CLI help text no longer makes the unqualified "filmstrip by time" claim and does disclose the SVG-only condition — guards against a future regression back to the misleading wording. Verified RED (fails against the pre-fix string) and GREEN (passes after the fix) via a local before/after comparison. - `bunx vitest run src/commands/keyframes.test.ts src/commands/motionShotLayout.test.ts` — 46/46 passing - `bunx tsc --noEmit` in `packages/cli` — clean - `bunx oxlint` / `bunx oxfmt --write` on changed files — clean - Full CLI suite (excluding known-broken-in-sandbox browser-launch tests, unrelated to this change): 217 test files / 3025 tests passing 🤖 Generated with [Claude Code](https://claude.com/claude-code)	2026-09-10 23:22:14 -04:00
miga-heygen	5a95211e36	fix(cli): apply the canvas/video pixel-hash carve-out to img (#3865) ... ## What `check`'s sweep_static guard false-positives on a composition that swaps between equal-size, equal-position opaque `<img>` elements — a common authoring pattern for revealing frame N of a still sequence from a paused GSAP cursor. The render itself is correct; only `check`'s verdict is wrong. ## Why The sweep guard fingerprints every visible element's box + opacity + font-variation-settings per seeked sample. That's deliberately blind to pixel-only motion (a canvas repainting, a video playing) with no element moving, so an existing carve-out downsamples each visible `canvas`/`video` to 8x8 and folds its pixels into the fingerprint specifically to catch that class of motion. That carve-out's element selector (`root.querySelectorAll("canvas, video")`) never included `img`. An img src/visibility swap between equal-size opaque images moves zero geometry and zero opacity, so it stays outside both the base fingerprint and the pixel-hash carve-out — the whole-run fingerprint reads byte-identical across every sample and `sweep_static` fires on an animating composition. ## How Widened the selector to `canvas, video, img`. No other change was needed: `mediaPixelHash` already handles `img` correctly — `drawImage` accepts any `CanvasImageSource`, and its width/height detection already falls back to the element's bounding rect the same way it does for `canvas`/`video`. **Scope note:** this repo has an open PR (#3707) touching the same function (`collectLayoutGeometry` in this same file) for a different, unrelated bug (text/counter fingerprinting). This change is deliberately isolated to the `canvas, video` → `canvas, video, img` selector line and a new comment above it — verified against #3707's current diff that neither touches this exact loop, so the two PRs shouldn't conflict regardless of merge order. ## Testing Added a test mirroring the existing "changes the sweep fingerprint when visible video pixels advance" test, using an `<img>` element instead of `<video>` with the same pixel-mock approach. - `bunx tsc --noEmit` in `packages/cli` — clean - `bunx oxlint` / `bunx oxfmt --write` on changed files — clean, no changes needed - Full CLI suite (excluding known-broken browser-launch tests unrelated to this change): 217 test files / 3023 tests passing One local-environment caveat, disclosed for transparency: `layout-audit.browser.test.ts` (the file the new test lives in) can't execute in my local sandbox — it fails identically with or without this change (`No such built-in module: node:`, a happy-dom + Vite externalization issue affecting every test file in this repo that imports Node builtins at the top under `@vitest-environment happy-dom`, not specific to this change). I verified the new test's logic and mocking approach are structurally identical to the existing, CI-passing video test it's modeled on, and will confirm via this PR's CI run rather than a local one. 🤖 Generated with [Claude Code](https://claude.com/claude-code)	2026-09-10 23:21:48 -04:00
miga-heygen	9c84277d28	fix(cli): let .hyperframesignore negation re-include hidden directories (#3859) ... ## What `.hyperframesignore` negation rules (e.g. `!/.media/`) could never re-include a hidden (dot-prefixed) directory in the publish or cloud-render project archive, even though negation works correctly for every other kind of path. ## Why `collectProjectFiles`'s walker called `shouldIgnoreSegment` first for every directory entry, and that check unconditionally excluded any name starting with `.` — before the project's ignore matcher (built from `DEFAULT_PROJECT_IGNORE` + `.hyperframesignore`, where negation is evaluated) ever ran on that path. A hidden directory was discarded at the walk step, so no negation rule downstream could ever reach it. ## How - Moved the dot-prefix exclusion out of the hard `shouldIgnoreSegment` short-circuit and into the same ignore matcher that already parses `.hyperframesignore`, as a new default pattern (`.*`) in `DEFAULT_PROJECT_IGNORE`. Dot-prefixed paths are still excluded by default, but now via the same gitignore-style negation path as everything else, so a project's `.hyperframesignore` can override it. - `shouldIgnoreSegment` is now reserved for the fixed, non-negotiable exclusions only (`.git`, `node_modules`, `dist`, `.next`, `coverage`, `.DS_Store`, `Thumbs.db`) — the set no `.hyperframesignore` rule should ever be able to reach. - Added regression coverage for both directions: a `.hyperframesignore` negation re-including a hidden directory, and an unmatched hidden directory still being excluded by default (no behavior change for existing projects without an explicit negation rule). ## Testing - `bunx vitest run packages/cli/src/utils/publishProject.test.ts` — 40/40 passing (2 new) - `bunx vitest run packages/cli/src/commands/cloud/render.test.ts` — 10/10 passing (cloud render reuses the same archive builder) - `bunx tsc --noEmit` in `packages/cli` — clean - `bunx oxlint` / `bunx oxfmt --write` on changed files — clean, no changes needed 🤖 Generated with [Claude Code](https://claude.com/claude-code)	2026-09-10 23:20:33 -04:00
Vance Ingalls	c93c765403	Merge pull request #3805 from heygen-com/fix/prinfra-600-fresh-screenshot-fallback ... fix(render): retry drawElement failures on a fresh screenshot page	2026-09-10 17:25:49 -07:00
miga-heygen	14b9e2039b	fix(studio): tolerate WebMCP execute calls without an options object (#3860) ... * fix(studio): tolerate WebMCP execute calls without an options object Every Studio write tool (studio_set_text, studio_set_style, studio_transform, studio_add_animation, studio_update_animation, studio_add_keyframe, studio_delete_animation) registered its handler as `execute: (input, { signal }) => ...`. The W3C shape passes an options object, but the bundled `@mcp-b/global` polyfill invokes a registered `execute` with the input alone, both from its in-page BrowserMcpServer wrapper and from the descriptor it mirrors into a native `document.modelContext`. The destructure therefore threw `TypeError: Cannot destructure property 'signal' of 'undefined'` before the handler ran, while the read tools, which ignore the second parameter, kept working. Route the seven signal-taking tools through one `writeTool` helper in `buildStudioTools` that reads `options?.signal`, so a missing options object yields an undefined signal at a single boundary. The handlers already default an undefined signal to a never-aborted one, so nothing downstream changes. `ModelContextTool.execute` now declares `options` optional to match what callers actually do. Upstream check: `@mcp-b/global` 5.0.1 (pinned), 5.0.3 and 5.1.0 ship a byte-identical `@mcp-b/webmcp-polyfill` chunk and the same one-argument call in `@mcp-b/webmcp-ts-sdk`, so a dependency bump would not fix this. Tests: drive `studio_set_text` through the real `@mcp-b/global` package under jsdom (registry entry `execute` and Chromium-style `executeTool`) and assert a saved result; call every write tool with one argument against a fake model context and assert none reports an `internal` failure. The existing spec-shaped tests, including the early abort path, still pass, which proves a provided signal still reaches the handler. Shared inert deps builders move to `webmcpTestUtils.ts`. Closes #3858 Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * test(studio): cover the native-mirror WebMCP execute path Install a native-looking `document.modelContext` before importing `@mcp-b/global` so the bridge wraps it and mirrors every Studio registration into it. One setup then exercises both one-argument call paths the package ships: the in-page BrowserMcpServer wrapper (registry entry and Chromium-style `executeTool`) and the descriptor mirrored into the native context. Both fail with "Cannot destructure property 'signal' of 'undefined'" without the fix and save with it. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> --------- Co-authored-by: Claude Fable 5.1 <noreply@anthropic.com>	2026-09-10 20:12:14 -04:00
James Russo	8820a01090	fix(skills): exclude repo-native skills from public installs (#3856)	2026-09-10 12:35:29 -07:00
Miguel Ángel	59def1b66d	chore(release): v0.8.34 (#3854) v0.8.34	2026-09-10 14:45:17 -04:00
Miguel Ángel	9549e038c4	perf(studio): a paused editor stops redrawing its overlays sixty times a second (#3846) ... * perf(studio): run the editor overlays on one parkable frame loop The composition rect, the selection and hover boxes, the off-canvas indicators and the snap guides each owned an animation-frame loop that re-armed unconditionally. On a paused, untouched editor that is four callbacks per frame reading layout, and the snap-guide loop writes style on every one of them, so the compositor kept committing 55 frames a second with nothing moving. None of the four has a clock of its own; each only changes when something observable happens. They now share one loop that runs at full rate for a moment after a pointer, key, wheel, scroll, resize or visibility change, after a preview message reporting a frame the overlays have not drawn, or after a mutation inside the preview document, and otherwise polls four times a second so a wake source nobody thought of costs a quarter second of staleness rather than a frozen overlay. The frame comparison on preview messages is load-bearing rather than an optimisation: the paused preview posts an unchanged status message every 80 ms so any listener can confirm its position, and treating that as news held the overlays at 60 fps for the life of the tab. * fix(studio): one overlay's throw must not stop the other four The shared frame loop re-armed after running its subscribers, so a subscriber that threw took down the loop and its idle-poll safety net permanently. The four loops it replaced each re-armed first, which kept that failure to the one overlay that caused it. It now re-arms before running anything and isolates each subscriber, rethrowing out of band so the error still reaches the page's error reporting. The wake also sat outside the recognised-message check, so postMessage traffic from an extension, devtools or any other embed on the page held the overlays awake for 400ms at a time. Only the preview's own messages wake it now, and a repeated paused status post still does not. useMotionPathData had the same unconditional loop and is live whenever a keyframed element is selected; it joins the shared one. * fix(studio): wake the overlays only for the preview	2026-09-10 18:20:37 +00:00
renovate[bot]	eae4892ae8	chore(deps): update dependency vitest to v4 [security] (#3789) ... * chore(deps): update dependency vitest to v4 [security] * fix(test): preserve test behavior on Vitest 4 --------- Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com> Co-authored-by: James <james.russo@heygen.com>	2026-09-10 13:55:52 -04:00
James Russo	c98d6fbac8	fix: keep caption transcript data inside generated scripts (#3847) ... * fix: keep caption transcript data inside generated scripts * test: locate caption data without an HTML filtering regex	2026-09-10 12:53:30 -04:00
Miguel Ángel	c752b89bc9	fix(runtime): the editor keeps waking during a drag on a preview it did not build (#3850) ... The manual-edit gesture watch tested mutation targets with `instanceof Element`. The composition body is adopted into the preview frame, so its nodes answer to another realm's Element and the check is false for every one of them: the watch never sees a gesture, and the paused transport it gates does not wake while the user drags. Routes the check through the runtime's structural predicate, which is what the preview-guard lint added alongside it now requires. Main is red on that lint for this line, so this also unbreaks it. Test adopts an element from a second realm and asserts the marker is seen and cleared; it fails with the identity check restored.	2026-09-10 16:29:32 +00:00
Miguel Ángel	d4fba55a4e	perf(runtime): a paused preview stops burning CPU (#3845) ... * perf(runtime): stop the preview transport ticking when the editor is paused A paused, untouched preview asked the browser for a fresh frame sixty times a second and re-read the page on each one. Nothing it looked at could change without some observable event firing, so the loop now stands down and wakes on that event instead, with a slow timer as the safety net. Parked, the loop keeps two jobs the 60 Hz version did implicitly: the control bridge's paused heartbeat, on the same interval as before, and a re-read of the timeline registry, which is a plain object no observer and no event can report. Everything else arrives by an event now: timing-attribute edits, mounted or removed timed elements and media metadata through the composition-timing observer that already existed; a manual-edit gesture starting or ending through a new attribute-filtered observer, which also replaces a whole-document query that ran on every paused frame; and playhead or play-state changes through the forced state post every transport mutation already ends in. Three periodic jobs (re-binding the root timeline, posting the clip manifest, binding media-metadata listeners) used a frame counter as a proxy for "the document may have changed". They now ask that question directly, because the counter stops advancing while the loop is parked. The render path is untouched: the loop never parks while an export render is driving frames. That test is the pair of renderCaptureSeekStarted and the producer's injected seek config, not the flag alone, because Studio's own preview falls back to renderSeek for overhanging timelines. Idle, paused, no input, on a 1689-element project: main-thread self time 128 -> 8.5 ms/s and animation-frame callbacks 282 -> 4.3 per second, both measured with the runtime and editor changes in place. * fix(runtime): keep the rebind policy the only owner of "may rebind now" The parked-loop change let a composition-timing change OR its way past shouldAttemptPeriodicTimelineBind, which removed the hold that keeps an async rebind off the first two seconds of playback, and let the clip manifest post on every frame of a composition that mutates the DOM every frame (measured: 30 posts in 30 frames against one). The change is now an input to that policy, which still applies the hold, and the change-driven path is confined to the paused path and rate-limited to the posts per second the frame counter already produced. A change it defers stays pending, and a pending change keeps the loop awake, so deferring can never drop it. Two more holes from the same review: The parked poll compared only the composition timing revision, so an adapter duration floor that grew was never noticed. Adapters infer duration from live animation objects that change with no DOM mutation and no media event, which makes it the second input nothing can push; both are now in one witness. Draining the gesture observer's records to answer within a task suppressed the observer's own callback for them, so a reader could consume the notification that un-parks the transport. Draining now notifies. The watch reports whether it is observing at all, and the loop refuses to park when it is not. That path is unreachable today because the colour-grading runtime constructs a MutationObserver unconditionally during the same init; the flag is the explicit statement of the invariant for the day that changes. * fix(runtime): clear the pending-change latch after the post, not before postTimeline walks author DOM and can throw. The tail scheduler runs in the tick's finally either way, so clearing the latch first let it see nothing owed and park with the change undelivered — and nothing would deliver it until some unrelated change happened to wake the loop again. Clearing after the post means a throw leaves the change owed, the loop stays awake, and the frame counter retries it within twenty frames. Same rule the shared editor loop already follows for its own re-arm. Also rewords the note on draining the gesture observer's records: that is hardening, not a fix for a live lost wake. isActive has exactly one caller today, inside transportTick, and a tick is its own task, so the observer's microtask has already run by then. * fix(runtime): stop the parked heartbeat when the page has gone away The parked transport holds a timer where the old loop held only an animation frame, and a frame is discarded when a page or a test environment is torn down while a timer is not. A test that initialises a runtime and abandons it therefore left an 80ms timer to fire into a dead global, which CI reported as an unhandled ReferenceError attributed to whichever file was running when it landed. Two changes, because the leak has two ends. The heartbeat stops instead of re-arming when window or document is gone: nothing is left to report a state change to, so stopping is the answer rather than throwing. And the one test that initialised a runtime without ever tearing it down now tears it down.	2026-09-10 08:29:22 -07:00
Miguel Ángel	73dfe35e46	fix(preview): show the correct scene instead of every scene at once on some loads (#3848) ... * fix(runtime): show the right scene when the preview DOM comes from another window The Studio preview sometimes builds the composition body in the editor window and adopts it into the preview frame's document. Adopted nodes keep the prototypes of the realm that created them, so `node instanceof HTMLElement` is false for every element in the composition even though the elements are ordinary HTML sitting in that document. Every guard in the runtime written as `if (!(node instanceof HTMLElement))` then skipped the whole document, silently: nothing threw, nothing logged, and readiness still reported success. The timed-element visibility pass wrote no inline visibility at all, so on those loads the preview painted every scene on top of every other and the editor drew off-canvas markers for elements the user could not see. The auto-stamp pass stopped stamping too, which is why the composition came up one timeline clip short. Replace every realm-sensitive element check in the runtime with structural predicates that ask what a node IS (node type, namespace, tag name) rather than which window's constructor made it. Two local `doc.defaultView.HTMLElement` workarounds are deleted with it: they fix only the case where the nodes belong to the document's own realm, and adoption is exactly what breaks that. * fix(studio): scrub the music track the timeline named, not the first audio `resolveScrubAudioEl` tested `byId instanceof HTMLAudioElement` on a node from the preview iframe's document. That node is an instance of the IFRAME's `HTMLAudioElement`, never this module's, so the check was false on every load and the `musicId` hint was dead. Scrub fell through to the first `<audio>` in the document, which the comment right above it warns can be the voiceover, so dragging the playhead could preview the wrong track. Ask what the node is instead. Also close the gaps an independent review found in the runtime fix: - the cross-realm predicate test had no `<audio>` and no `<img>`, so reverting `isAudioElement` or `isImageElement` to `instanceof` left it green. It no longer does, and the audio case also pins `isMediaElement`, which composes from it and gates the media sync path. - nothing stopped the runtime regressing. `lint-runtime-preview-guards.ts` gains a second check kind: patterns that must be ABSENT under a directory, seeded with DOM-typed `instanceof` under `src/runtime`, pointing at domRealm.ts. Comment lines and tests are exempt, both on purpose. - domRealm.ts stated the adoption mechanism as settled fact. The mixed prototypes are measured; how the nodes get into the frame is not identified, and the docstring now says which is which. Its ownership claim is scoped to the runtime, since packages/studio still hand-rolls its own checks.	2026-09-10 08:06:43 -07:00
Miguel Ángel	0408fbcd99	perf(studio): scrubbing a large composition no longer stalls the editor (#3842) ... * perf(studio): ask each ancestor once per off-canvas rebuild, not once per element The dashed off-canvas markers are rebuilt whenever anything in the preview changes, which during playback or a scrub is several times a second. Most of what a rebuild asked about an element was really a question about its ANCESTORS: does each node up to the root render, what does each contribute to the composed transform, which node is the source-file boundary. Two siblings share their whole chain, so a preview of a thousand elements asked the platform the same questions about the same ancestors a thousand times over. A rebuild now threads one measure pass through the walk, and each node answers once. On a 1689-element carousel that takes computed-style reads from 11,159 to 2,526 per rebuild and the rebuild itself from 59 to 12-18 ms per seek, with the rendered marker set byte-identical. The pass is deliberately not a cache. A cache would have to say what could have changed since last time, and for a measurement the answer is anything: an image finishing decode, a font swapping in, a transition frame, a container query, an inserted stylesheet rule all move an element's box with nothing written to the DOM and no record to invalidate on. A pass lives inside one synchronous measurement that only reads, so nothing can move under it, and it is dropped when the measurement ends. Every rebuild still measures every element. Layout reads are untouched on purpose: each element still takes its own client rect every rebuild, because that is the read that cannot be shared and must not be remembered. * test(studio): give one PropertyPanel case the file's own render timeout Every other render test in that file passes RENDER_TIMEOUT_MS; this it.each was left on vitest's 5s default and times out when the whole suite runs on a loaded machine. Unrelated to any behaviour: it passes on either side of the change when the machine is quiet, and fails in a full-suite run on either side when it is not. * refactor(studio): share the source-boundary walk and dedupe the rebuild fixtures Three follow-ups from review of the measure pass, none of them behaviour: The source boundary was memoized against the element that asked for it, so two siblings still walked their whole chain separately and only the answer was reused. It now memoizes every node on the way up, like the other two walks: an element's boundary IS its parent's unless the element is one itself. `isElementVisibleThroughAncestors` returns what it always returned, but it now resolves top-down, so the set of nodes it takes a style read for is different (smaller for a subtree hidden near the root). Three callers use it with no memo, so that is written down next to it rather than left to be discovered. The three rebuild fixtures in the indicator tests each carried their own copy of the iframe/overlay/layout-stub scaffolding, which is four clone groups and 126 duplicated lines. One `mountPreview` helper now serves all of them and the pre-existing selector-index fixture too. * test(studio): pin the measure pass to one rebuild through an ancestor-derived input The existing no-mutation-record test varies an element's own box, and the pass never memoizes a box — so hoisting the pass to module scope, which is exactly the mistake that would reintroduce cross-rebuild staleness, left every test green. This one fades a wrapper between two rebuilds and asserts the marker under it goes away. Visibility through ancestors IS memoized, so the pass surviving the rebuild serves the stale answer: with `createOverlayMeasurePass()` hoisted the suite exits 1 on this test alone, and exits 0 at head.	2026-09-10 14:48:30 +00:00
James Russo	cd1a996ba4	fix(catalog): confine hosted preview asset downloads (#3843) ... * fix(catalog): confine hosted preview asset downloads * test(catalog): pin credential and port refusal with finite streams	2026-09-10 08:21:49 -04:00
James Russo	96637aeb1c	fix(capture): share the render host policy and block localhost aliases (#3844)	2026-09-10 07:59:30 -04:00
James Russo	a7e2e3853a	fix(media): validate every download redirect target (#3841) ... * fix(media): validate every download redirect target * fix(media): apply redirect policy to logo HEAD probes	2026-09-10 06:16:25 -04:00
James Russo	d393541c2b	fix(cloud): preserve existing output when downloads fail (#3840) ... * fix(cloud): preserve existing output when downloads fail * test(cloud): pin same-directory download staging	2026-09-10 05:44:40 -04:00
James Russo	962c95406d	fix(registry): verify staged asset content before publishing manifests (#3832) ... * fix(registry): verify staged asset content before publishing manifests * test(registry): run asset staging regression in script CI * refactor(registry): separate verified manifest publication	2026-09-10 04:28:58 -04:00
Vance Ingalls	4c7fbde51e	fix(engine): emit pipelined frame diagnostics before the recoverable wrapper ... Review feedback on #3805. captureFrameToBufferPipelined checked isRecoverableDrawElementError and threw DrawElementCaptureError before reaching captureFrameErrorDiagnostics, so the NCPR/canvas failures that now abort the whole attempt produced no frame-error PNG/HTML/JSON bundle — the exact case worth debugging, and the one the adjacent comment promised mirrored the serial path. The serial path was unaffected because its own DrawElementCaptureError throw propagates through captureFrameCore's outer diagnostics catch. Run diagnostics first, then the recoverable wrapper. Bounded to at most one bundle per attempt, since a recoverable error fails the whole attempt, and captureFrameErrorDiagnostics self-catches, so a dead page cannot mask the structural error the producer's fresh-page retry depends on. Covered by a new test asserting the bundle lands for a recoverable pipelined failure; verified by mutation (restoring the old order fails it). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-09 22:54:33 -07:00
Vance Ingalls	6a206ffea6	fix(render): retry drawElement failures on a fresh screenshot page	2026-09-09 22:54:33 -07:00
Miguel Ángel	8bf5b4423e	perf: sublinear Studio rebuilds and seeks (#3837) ... * perf(studio): resolve the overlay coordinate basis once per composition The iframe->overlay basis (composition root, root scale, iframe and overlay rects) was resolved inside every geometry call, so measuring a preview cost one querySelector("[data-composition-id]") plus three layout reads PER ELEMENT to rediscover something that is a property of the composition and the canvas zoom. It is now threaded through orientedGroupAwareOverlayRect, groupAwareOverlayRect, orientedOverlayRect, orientedVisibleOverlayRect and toVisibleOverlayRect the way toVisibleOverlayRects already batched it, and resolved once by the two callers that measure many elements in one synchronous pass: the off-canvas indicator rebuild and the overlay RAF loop. Both passes only read the DOM, so nothing can move the canvas between two measurements inside one of them. * perf(studio): rebuild the layer walk from the mutation, not the document A MutationObserver marked the off-canvas indicators dirty and the rebuild then re-derived every element in the preview from scratch. The observer's loudest source is inline style, which is what animation writes, so a composition just sitting there re-derived the whole document several times a second, and each element costs two getComputedStyle reads, two ancestor walks for its source file, and a textContent read over its whole subtree. The records now say WHAT to drop, not merely that something changed, and the per-element derivations are memoized between rebuilds. Two lifetimes, because they do not go stale together: whether an element renders (and how many layer children it has) dies on any nearby attribute write, while how it is ADDRESSED survives every style write and dies only on something that can renumber a selector. That split is what makes an ordinary animation frame cost no document queries at all. Not attributable to specific elements, so still a full rebuild: nodes added or removed, and any change to an identity attribute, which renumbers every element sharing a selector. Two supporting changes: - getDirectLayerChildren asked getDomLayerPatchTarget for a full patch target per child and used it as a boolean. The target carries the selector's occurrence index, which is a whole-document query the yes/no does not depend on. isDomLayerElement answers it without one, for every caller. Its unused options parameter goes with it. - The observer no longer filters attributes. An attribute it never hears about is one the cache would answer stale for, and the old filter omitted id and the data-composition-* attributes that decide a layer's identity. Widening only makes indicators refresh sooner; a rebuild is a pure read and is throttled either way. Every other caller of collectDomEditLayerItems passes no cache and is unchanged. * perf(runtime): visit only the clips a seek can flip Every seek, and every frame of playback, rebuilt the window of every video and audio element in the document and handed all of them to the per-clip sync loop. On a composition of eighty videos that is eighty window derivations and eighty per-clip passes to conclude that one clip is on screen. A clip is active only while start <= t < end, so a clip whose window excludes the new time is inactive there whatever its element state is. Sorting the windows by each endpoint turns a seek into two binary searches: the clips whose start or end lies between the old time and the new one, plus the ones that were in window at the old time. Anything outside both was out of window before and is out of window now, and was already paused and already evicted by the pass that last saw it go out. A one-frame step visits the clip or two that flip; a jump over a hundred clips still visits the hundred boundaries it crosses. The index carries only the windows, and it rides the revision the duration floors already ride: the same timing attributes, the same media metadata events, the same timeline registry signature. Nothing else is cached. Every field handed to syncRuntimeMedia is re-read from the element on every pass, because el.duration can be reset under us by the load() retry, and a cached copy of it would be exactly the stale duration the two-resolver-scope rule exists to prevent. The render/export path does not consult the index at all and visits every element on every frame, and a render seek clears the sweep so a later live seek cannot inherit a position it did not establish. Also folds the duration floors' own invalidation into that shared revision. Draining the observer is what detects a change, and only the first reader in a task gets the records, so two caches each checking for themselves would have had the second told nothing changed. * refactor(studio): split the overlay basis and the layer-walk read into their own modules Clears the 600-line file cap and the fallow audit on this branch. Behaviour is unchanged: this moves code, it does not alter any of it. File size. Both files were already near the cap on main and my three levers pushed them over (615 vs 598, and 605 vs 584): - domEditOverlayGeometry.ts -> 561. The iframe->overlay coordinate basis (OverlayRootScale, computeOverlayRootScale and the root/dimension lookups it owns) moves to domEditOverlayBasis.ts. It is the one piece of that file every other piece depends on, and nothing in it is about a single element's geometry. Its two callers now import it from there. - domEditingLayers.ts -> 587. The per-element read that the walk performs moves to readDomEditLayerWalkEntry in domEditLayerWalkCache.ts, the module that owns the memoization it reads through. The walk keeps the traversal and the depth bookkeeping, which are the parts that are actually about walking. No unrelated code was trimmed to make room. Duplication, all three clone groups fallow flagged: - The runtime seek fixture (createMockTimeline, the synchronous animation-frame clock, the CSS.escape shim, stubDuration) was copied between init.timingResolver.test.ts and init.mediaClipIndex.test.ts. It moves to runtimeSeekFixture.test-helpers.ts. Each suite keeps its own vi.mock calls, which are file-scoped and cannot be shared. The file is excluded from tsconfig.runtime.json alongside the test files it serves, for the same reason. - domEditLayerWalkCache.test.ts repeated its mount/observe/first-walk setup in three tests; that is now withWarmWalk. Complexity. Only one of fallow's three findings is attributable to this branch, and fallow agrees: it marks the other two inherited and excludes them from the gate. - offCanvasIndicatorRefresh.ts update was NEW (absent from main's report, 10 cyclomatic / 31.6 CRAP here). The optional-chain-and-default I added to drain the observer becomes drainPendingLayerMutations, with its own unit tests, and the function drops off the report entirely. - useDomEditOverlayRects.ts update: 37 cyclomatic / 69 cognitive on main AND here. My change added one statement and no branch; the function grew 139 -> 147 lines, which is what resurfaced it. Left alone. - domEditingDom.ts escapeCssIdentifier: 24 cyclomatic / 19 cognitive / 148.4 CRAP on main AND here. Untouched by this branch; only its line number moved (173 -> 182) because the composition-source-map revision counter sits above it. Left alone.	2026-09-10 03:55:28 +00:00
Miguel Ángel	622ea5b38c	test(skills): pin the catalog exemption as a capability and lint the templates list (#3838) ... The two skills exempt from the catalog search were pinned only by the sentence that declares the exemption, so the exemption would go stale the day either gained a way to install a registry item. The test now also asserts neither skill contains an install command or a registry path. The templates list in the scaffold reference claimed to be lint-checked but lacked the marker that arms the check, so a misspelt template would have passed. It now carries the marker with its presets and skill names allowlisted, and a misspelt template fails the lint.	2026-09-10 03:49:21 +00:00
Miguel Ángel	0f8eb892e3	fix(skills): search the component catalog before hand-building a look (#3829) ... * fix(motion-graphics): make the catalog search fire before hand-authoring The workflow's only reuse instruction pointed at catalog-map.md, a hand-maintained snapshot of ~60 registry items, and no file in the skill ever named `hyperframes catalog --query`. An agent asked mid-build for CRT scanlines and a glitch effect had no instruction to search, so it hand-authored both while caption-glitch-rgb ("RGB chromatic aberration with CRT scanline overlay") ranks first for that query on either tier. The search reads the hosted registry and needs nothing installed, from any directory with no project, so "the components were not installed" was never the cause. Say that where the reader is, since the wrong diagnosis is the intuitive one. Director Part 2 and the Builder now run the search before naming a block, and catalog-map.md is labelled a partial snapshot whose misses prove nothing. Pinned by a content test in coreSkillContent.test.ts. * fix(skills): search the component catalog before hand-building a look Authoring workflows never told the agent to search the component library, so agents rebuilt effects the registry already shipped. A user reported building an effect from scratch that the registry already contained; the search that would have found it needs nothing installed, which is why the usual self-diagnosis ("I forgot to install the components") is wrong. All ten workflow skills carried zero mentions of `hyperframes catalog`. The instruction lived only in hyperframes-cli and hyperframes-registry, both loaded on demand, and the registry skill's own trigger named the command rather than the symptom - circular, because an agent that never thought to search could not reach the doc telling it to search. - Eight workflows now run the search at the point they decide what to build, before authoring. The two that compile through a closed authoring vocabulary (embedded-captions, talking-head-recut) document why they deliberately do not. - hyperframes-registry triggers on the symptom (a named look, effect, treatment or transition) instead of the command name; the router table and the catalog surfaces carry the same framing. - Fixes hand-maintained lists that had drifted: bar-chart-race was listed as a hand-author gap in two files while shipping in the registry; stat-motion was named as an installable block and is not one; the caption-* family count was one high; the registry discovery tables claimed to be the block list while covering 97 of 180. - bun run lint:skills now fails when a doc marked as a registry snapshot names an item the registry does not have. * refactor(scripts): reuse native recursive readdir and the shared registry type Simplify pass on the new registry-snapshot check, behaviour identical: - collectMarkdownFiles uses readdirSync({ recursive: true }) instead of hand-rolled recursion, matching scripts/generate-template-previews.ts. - registryItemNames types registry.json with the exported RegistryManifest instead of an ad hoc inline shape, matching scripts/catalog/build-local-vectors.ts. The runtime guard stays: a cast describes the file, it does not validate it. - One report() helper replaces the duplicated print-and-count block in both lint passes. * refactor(scripts): name the registry check's blind spots and stop self-arming Applies the review findings on the new check, behaviour identical except where noted: - lintRegistryItemRefs returns null for an unmarked file instead of an empty array, so "not a snapshot" and "a clean snapshot" have one owner and the marker is matched once rather than twice. - Marker detection ignores fenced blocks, so a doc that documents the marker syntax in an example no longer arms the check on itself. The id scan still reads full content, so fenced examples stay covered. - The header comment and two tests now pin both known false negatives: identifiers outside backticks, and single-word item names. Measured on the six marked files, dropping the hyphen requirement would monitor 3 more items and force 46 allow= entries for ordinary prose words, so the requirement stays and the gap is stated instead of silent. * chore(skills): regenerate skills manifest after catalog-search edits	2026-09-10 03:21:33 +00:00
Miguel Ángel	db51d5479d	fix(ci): generated files never read half-written, lint scaling test runner-proof, probe cache test off disk (#3834) ... * fix(build): stop generated files from being read half-written during the build Two unrelated pull requests kept failing CI for reasons that had nothing to do with their changes. Typecheck failed with "TS1002: Unterminated string literal" pointing at a generated file. The root build compiles several packages at the same time, and more than one of them regenerates files under a package's src/generated while a sibling's tsc is already reading them. A plain write empties the file and then refills it, so for a few milliseconds what is on disk is the first half of the new file. Whichever build read it in that gap saw a truncated file and stopped. It never happened locally because locally nothing else is reading. Every generator now writes the new version under a temporary name and then renames it over the target, which the filesystem does in one step. A reader either gets the whole previous version or the whole new one; there is no moment where it can see half of either. Content that has not changed is not rewritten at all, so repeat builds no longer touch these files. Four generators were affected and all four now go through one shared helper, which is where the rule lives from now on. The build also rebuilt the core package a second time, in parallel with the packages that read it. That second rebuild was already redundant, and removing it takes the writers out of the window entirely. Renaming is what makes the file safe; dropping the duplicate build makes the build shorter as well. Separately, a linter performance test failed on four of the last ten failed runs on main. It timed a scan with a stopwatch and demanded the result come in under two seconds; one run took 3.7s. That is a statement about how busy the shared runner was, not about the code, because a stopwatch also counts the time the machine spent running someone else's job. The test now counts only the processor time this process actually used, and checks that the cost grows in step with the input rather than against a fixed number of milliseconds. Measured on a machine under load, the stopwatch ratio for the same input reached 45x while the processor-time ratio stayed at 20x. Both fixes come with a check that fails if the fix is removed. * fix(build): keep the shared write helper inside the core package The helper the generators call had been placed in the repo-root scripts folder. Every container image that builds a package copies the packages folders whole but cherry-picks root scripts one file at a time, so the image builds failed on a missing module. The repo already shows both halves of that convention: the one root script a package build imports has a matching copy line in the image, and cross-package imports into the core package need none. The helper now lives with the core package's other build scripts, and the one generator outside that package reaches it the way the engine package already reaches core. * test(engine): keep the probe cache bound test off the filesystem The eviction test wrote, stat'ed and deleted 129 temp files to exercise an in-memory LRU rule. Its runtime tracked filesystem contention rather than the code under test, and on a busy Windows runner the file churn alone pushed a ~300ms test past the 5s timeout, failing unrelated pull requests. Cache identity comes from stat, so the test now synthesises stat results and never touches disk. While here, the test also asserts the LRU touch: re-probing an entry before the bound is hit must keep it resident and evict the next-oldest one instead. The previous shape never hit the cache during the fill, so that branch was untested. * test(lint): keep the scaling check inside the scanner's linear range The CPU-ratio version sampled 320k characters, where the output string's own growth dominates and the whole test cost seconds of CPU; on a shared runner that tripped the default test timeout, the failure this change exists to remove. Sample 10k and 80k characters instead, where 8x input measures ~8x and a quadratic scan still measures 60x or more, and give the test an explicit timeout so a slow runner reports the ratio. * test(core): snapshot file identity through a descriptor The before/after inode and mtime checks read the file through a path stat and then exercised the writer on the same path, which reads as a check-then-use race to static analysis. Snapshot through an open descriptor instead; the assertions are unchanged.	2026-09-10 03:08:58 +00:00
Miguel Ángel	5973273f8d	fix(runtime): resolve media clip start once for playback, manifest, and audio (#3833) ... * fix(core): play and draw media clips at the same time A clip placed inside a scene could be drawn on the editor's timeline at one time and actually play at another. Nothing failed; the timeline just showed the clip in the wrong place, and a clip pushed past the end of the composition disappeared from it entirely. The cause was that the code drawing the timeline and the code playing the video each worked out the clip's start time from the same HTML attributes in their own way, and only one of them knew about the marker that says "this start time is already measured from the beginning of the whole video". Both now ask the same function. The same function also answers for the visibility pass, the audio scheduling paths, and the volume-fade probe, all of which were reading the raw attribute and so placed a nested clip's audio at the wrong moment. Also folds the duplicated media-length helper into one shared version. * refactor(core): resolve the volume probe window once per element * fix(core): resolve media starts through the pass-scoped timing resolver After rebasing onto the resolver-reuse change, the shared media start resolver was building a fresh start-time resolver per call, which is the per-element construction that change removed. Route it through the scoped resolver so one pass shares one set of caches.	2026-09-10 02:30:16 +00:00
Miguel Ángel	ac27b1534f	perf(studio): resolve a selector's occurrence index once per layer walk (#3831) ... The preview flattens several composition files into one DOM, so a layer's identity is its selector plus its occurrence index WITHIN its own source file. `getSourceScopedSelectorIndex` derived that per element: a whole -document `querySelectorAll(selector)`, `resolveSourceFile` on every match, then `indexOf`. Every element sharing a class paid for all of them, so a walk over n such elements did n whole-document queries and n^2 source-file resolutions — the shape a composition of repeated cards or tiles has by construction. Build the occurrence index ONCE per selector instead and share it across one walk. `withSelectorIndexPass(doc, run)` opens that scope; outside it the helper behaves exactly as before, per call. The pass lives in `collectDomEditLayerItems`, which owns the loop, rather than at a call site — its four callers (off-canvas indicators, the layers panel, the marquee hit-test and the agent look tool) all walked the same way and all paid the same cost. Behaviour is unchanged. The occurrence indices are identical, including the misses: an element outside the requested source file, or one not matching the selector, still yields undefined, as do `#`-prefixed and `[data-composition-id=` selectors and an invalid selector. Measured on a 1689-element preview over 80 single-frame seeks, per rebuild: class-selector document queries 171.6 -> 10.8, and the walk's self-timed cost 15.25ms -> 5.37ms. Elements walked per rebuild is unchanged at 973.7, so the two arms did the same work. Tests assert complexity invariance rather than a threshold: the query count must be IDENTICAL at n and 4n elements sharing a selector, which a fixture -sized threshold would not catch. Both fail on the previous algorithm.	2026-09-09 19:11:22 -07:00
Miguel Ángel	3ea2f909e1	perf(runtime): reuse one timing resolver per pass and derive duration only when the composition changes (#3824) ... * perf(runtime): reuse one timing resolver per synchronous pass `createRuntimeStartTimeResolver` memoizes element start and duration lookups in WeakMaps, but `resolveStartForElement` and `resolveDurationForElement` each constructed a brand-new resolver per call and discarded it. The caches never served a second lookup, so a single pass re-walked the composition ancestry of every element, and per-seek work scaled with total timeline content rather than with what changed. `withTimingResolver(fn)` installs one resolver for the duration of a synchronous callback and restores the previous one in a `finally`, so a throw cannot leak the scope. Callers outside a scope keep today's construct-per-call behaviour unchanged. Three separate scopes, deliberately not one: - the media-cache build in `syncMediaForCurrentState` - the body of `syncTimedElementVisibility` - the media scan in `resolveMediaWindowDurationSeconds` They must stay separate. `syncRuntimeMedia` calls `el.load()` on the seek-past-buffered-range retry, which synchronously resets `el.duration` to NaN, and `resolveDurationForElement` reads `element.duration`. A cache spanning that write would serve the pre-`load()` duration to a post-`load()` read. Splitting at the write makes the staleness unrepresentable instead of merely handled. The third scope sits on `resolveMediaWindowDurationSeconds` rather than its caller `getSafeTimelineDurationSeconds`, which would look like the tidier boundary: that caller also invokes author-supplied `timeline.duration()` and third-party adapter `getInferredDurationSeconds()`, and foreign code inside a cache scope can mutate the DOM between two resolves. Resolver constructions per seek plus transport tick go from 15 per media element to a flat 4, and self time in `resolveStartForElementInternal` falls about 70% on a 79-video composition. * perf(runtime): derive composition duration only when the composition changes The runtime re-derived the composition's total duration on every animation frame. transportTick called getSafeTimelineDurationSeconds unconditionally, and deriving it scans every media element in the document and walks each one's composition ancestry to resolve an absolute start and duration. That value is a function of the composition, not of the playhead, so a paused editor with nothing happening recomputed the same answer ~60 times a second. On a 91-media-element composition the media scan ran 1.05 times per frame while the editor sat idle and untouched. Derive it once and reuse it until an input could have changed. The inputs, and the signal that catches each: - timing attributes edited (live editing, variables re-applied, the runtime's own autostamping) -> MutationObserver with an attribute filter - timed elements added or removed, including nested compositions that mount asynchronously after init -> the same observer, childList+subtree - media metadata arriving, or el.load() resetting duration to NaN, neither of which mutates the DOM -> capture-phase media event listeners - a timeline registered or lengthened in window.__timelines, a plain object nothing can observe -> a registry signature compared on read Observer records are delivered in a microtask, so the queue is drained on read as well; otherwise an edit read back in the same synchronous block, the ordinary live-editing case, would be served the pre-edit value. The render path does not read the cache at all. Capture depends on the exact duration and a frame rendered against a wrong one cannot be recovered, so it pays the full derivation on every frame exactly as before. Measured on the 91-media-element composition, idle and untouched: media scans per frame 1.05 -> 0.05. Across 100 single-frame seeks: 2.28 -> 0.11 per seek, so seeking does not invalidate the cache either. The residual is a separate per-20-tick caller in timeline.ts, untouched here.	2026-09-09 18:53:15 -07:00
James Russo	0665249ca9	fix(playground): render initialization errors as text (#3825)	2026-09-09 19:57:39 -04:00
James Russo	ff749b8705	fix(security): verify CDN script integrity before inlining (#3822) ... * fix(security): verify CDN script integrity before inlining * fix(producer): normalize SRI algorithm case * fix(producer): abort compilation on integrity mismatch * fix(compiler): preserve nested script integrity requirements * fix(compiler): defer local inlining until integrity is known	2026-09-09 19:37:00 -04:00
James Russo	8d80530ff4	fix(player): authenticate slideshow navigation senders (#3820) ... * fix(player): authenticate slideshow navigation senders * test: isolate playground message boundary imports	2026-09-09 15:25:38 -04:00
James Russo	c6010f2eb8	fix(registry): authenticate deck sound effect messages (#3819)	2026-09-09 14:22:41 -04:00
James Russo	05d7261052	fix: restrict runtime and playground message dispatch (#3816)	2026-09-09 13:56:58 -04:00