[miguel-heygen]

What

Release HyperFrames 0.8.150 with the renderer memory fix from #5494, composition-wide audio effects, audio tail/seek fixes, and corrected scene media placement in exports. All 13 publishable packages and five plugin manifests use 0.8.150.

The reviewed notes in releases/v0.8.150.md match the new docs changelog entry. They call out that a top-level root audio chain now runs, and that engine frame injection leaves temporary image URLs that expire after decoding.

Why

Ship the fix for #5492 in the next stable release, as authorized by @miguel-heygen. The branch starts at the merged fix, fbbc4e88c59c01bfec69368a9a587d3438a7d32a.

How

Prepared through release:prepare, edited both changelog artifacts, then reran it to create the signed version commit. Only the release branch was pushed. After merge, the publish workflow creates the stable tag at the merge SHA, publishes npm packages, and creates the GitHub Release.

No visible change

This PR changes version fields and release documentation only. It adds no Studio/player UI or runtime behavior beyond what is already on main, so before/after captures do not apply.

Test plan

• Signed commit and clean worktree verified; merged fix is an ancestor.
• Release channel validation (latest, release/v0.8.150), workspace contracts, and all 13 public package subpaths pass.
• Format, large-file, tracked-artifact, and commitlint hooks pass.
• The underlying fix passed required PR and merge-queue CI, focused browser tests, and a real producer render in fix(engine): bound injected video frame resource retention #5494.
• After merge: verify immutable tag/release SHA, all npm latest package versions, and the released CLI.

[mintlify]

Preview deployment for your docs. Learn more about Mintlify Previews.

Project	Status	Preview	Updated
hyperframes	🟢 Ready	View Preview	Oct 12, 2026, 1:25 PM

💡 Tip: Enable Automations to automatically generate PRs for you.

[github-actions]

Edit accuracy: accurate 2061 (base branch 2061), smooth 1646 of those

The gate passes.
Smoothness is reported in the artifact, not gated. A case fails only if it fails 2 of 3 runs.

Quarantined, measured but not gated (0)

Unstable (1)

• seqheldtwice-tlhold-px-r0-nested-z100: tracking 0.41, pressJump 60.41, drop 0.39, reload 0.39, render 0.02, renderKey -, undo true, teleport true / tracking 0.09, pressJump 0.11, drop 0.39, reload 0.39, render 0.02, renderKey -, undo true, teleport true / tracking 0.09, pressJump 0.11, drop 0.39, reload 0.39, render 0.02, renderKey -, undo true, teleport true

[terencechotai2-commits]

Reviewed release commit c0bb10e9, signed, and GitHub reports it verified. Its parent is the #5494 merge, fbbc4e88, which is the current tip of main. No blockers, approving. CI is fully green at this head, with 88 checks passed, 0 failed and 0 pending, including all 11 required checks.

Scope: v0.8.149..fbbc4e88 contains 10 commits, all accounted for.

• The notes cover the 7 user-facing ones: #5420, #5454, #5474, #5478, #5481, #5489 and #5494.
• Three are left out of the notes, correctly: #5480 (catalog CI), and #5475 and #5476 (Studio e2e tests only).
• The release commit touches the same 20 files as the v0.8.149 release commit, and nothing else.

Versions

• All 13 public packages are at 0.8.150, and so are the 5 manifests (plugin.json, .claude-plugin, .codex-plugin, .cursor-plugin, gemini-extension.json).
• No 0.8.149 is left outside the changelog and release notes.
• The private sdk-playground stays at 0.6.106, as in earlier releases.
• Internal dependencies are all workspace:* or workspace:^. pnpm publish rewrites those when it packs.
• The CLI is published with npm publish and has no workspace: runtime dependencies.
• bun install --frozen-lockfile passes at this head. The bun.lock workspace version fields are still 0.8.128, the same as in previous releases.

Notes: I checked each bullet against its PR. They are accurate:

• #5420: a root data-fx-chain was previously applied to nothing, so the compatibility note is correct: an unused root chain now affects the mix.
• #5474:
  • The standalone scene uses its own root chain.
  • Mixes over 512 MiB of samples render in 5-minute windows.
  • Automation past 2 GiB now fails with a named AudioFxRenderError.
• #5494: the temporary-URL note is right.
  • Nit, non-blocking: only base64 data:image/... frames get these URLs. Caller-provided frame URLs pass through unchanged. "replaces inline data: frame URIs with temporary URLs" would be more precise.
• releases/v0.8.150.md and the new docs/changelog.mdx entry have the same content.

Publish path: publish.yml, validate-release-channel.mjs, verify-packed-manifests.mjs and package-agent-plugin.mjs are unchanged since v0.8.149.

• Trigger: a stable release publishes only from a merged pull_request from a release/vX.Y.Z branch. A stable tag push is rejected (v*-* only). The checkout is pinned to merge_commit_sha and verified.
• Tag: the tag is created at that SHA, or verified if it already exists there.
• Channel: VERSION=0.8.150 EVENT_NAME=pull_request PR_HEAD_REF=release/v0.8.150 passes the validator with dist-tag latest.
• Not yet published: npm view shows no 0.8.150 for hyperframes or @hyperframes/engine. Neither the v0.8.150 tag nor the GitHub Release exists yet.
• Provenance: the workflow publishes with id-token: write. hyperframes@0.8.149 and @hyperframes/engine@0.8.149 both have SLSA v1 provenance on npm, so this path has produced it before.
• Build and pack: I ran the same steps the post-merge job runs before publishing, at this head, with pnpm 10.17.1 from corepack as in the workflow:
  • bun install --frozen-lockfile and bun run build both pass.
  • bun run verify:packed-manifests reports all 13 packed manifests "publish-safe". It resolved 163 packed exports and ran 153 Node exports. A clean consumer install, TS/Vite resolution and CLI startup all pass, and all 13 packages are within their size budgets.

Note for the post-merge run: the job pushes the v0.8.150 tag before bun run build and before publishing. If build or publish fails, the tag stays while npm has nothing. The fix is to rerun the same merge event, since the tag step verifies an existing tag. That behavior is already there, and this PR doesn't change it.

— tai2