chore: release v0.8.11

[miguel-heygen]

What

Prepare the reviewed stable v0.8.11 release across all 13 npm packages and three agent-plugin manifests.

Why

Ship the static-frame dedup correctness/performance fix from #3438 and the Studio grouping-dialog viewport fix from #3421 to the stable latest channel.

How

• Bump publishable packages and plugin manifests from 0.8.10 to 0.8.11.
• Add reviewed GitHub release notes at releases/v0.8.11.md.
• Add the matching user-facing docs changelog entry.
• Keep the local release tag unpushed; the immutable merged-PR publish workflow will create the canonical tag at the squash merge SHA.

Test plan

• Unit tests added/updated

• Manual testing performed

• Documentation updated (if applicable)

• bun run test:scripts: 184 Node tests + 42 catalog Vitest tests passed.

• bun run build: all workspaces built successfully.

• bun run verify:packed-manifests: all 13 published workspaces verified publish-safe.

• fix(engine): preserve static dedup across caption runs #3438 exact-head CI and the real 939-frame transparent render were green before merge.

[mintlify]

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

Project	Status	Preview	Updated (UTC)
hyperframes	🟡 Building	–	Aug 23, 2026, 6:48 PM

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

[terencecho]

COMMENT — release-scope verification for v0.8.11. No code paths touched; version bumps + changelog only. Both cited PRs are already merged, base is stacked on #3438. CI clean at head so far (windows/perf/publish/typecheck/regression still running, no failures). Withholding approval — release PRs need Terence's explicit go regardless of trust list.

Head: d9989b5f588bbd9c14bbe046d05acae268518eda — base 65b2299db284ece3232de26ed7afbe0360e097bd (= #3438's merge commit).

Release-only scope — VERIFIED

18 files changed, 53/-16 — every one is a version bump, changelog, or release-notes file. No .ts/.tsx/.js/.py/.rs/Dockerfile/workflow/test file. Same shape as #3426 (v0.8.10 release) precedent.

• 13× packages/*/package.json — all public @hyperframes/* (aws-lambda, cli, core, engine, gcp-cloud-run, lint, parsers, player, producer, sdk, shader-transitions, studio-server, studio).
• 3× .{claude,codex,cursor}-plugin/plugin.json.
• docs/changelog.mdx (+19) + releases/v0.8.11.md (+18).

Excluded (correctly, all "private": true): root hyperframes-monorepo, packages/sdk-playground (own version track 0.6.106), packages/studio/frontend, e2e test fixtures, remotion-to-hyperframes test corpus.

Version-bump completeness — VERIFIED

• 16/16 pairs - "version": "0.8.10" → + "version": "0.8.11" (13 npm packages + 3 plugin manifests).
• No stragglers at 0.8.10. No accidental over-bump to 0.8.12/0.9.x.
• Lockfile (bun.lock) intentionally not touched: internal deps use workspace:*/workspace:^, and bun.lock contains zero 0.8.10/0.8.11 strings — workspace resolution is symbolic, so no lockfile churn is expected on a workspace version bump. Matches v0.8.10 precedent (#3426 also didn't touch the lockfile).

Changelog accuracy — VERIFIED

• #3438 entry ("Keep static-frame dedup active across dense caption changes while preserving mounted clip boundaries and safe verification fallbacks") accurately reflects PR #3438 title fix(engine): preserve static dedup across caption runs and its body ("Fix static-frame dedup for normalized mounted-composition timing and bound verification work across caption-heavy static runs"). Commit SHA link 65b2299db matches its merge commit.
• #3421 entry ("Stop the grouping dialog opening off the bottom of the window") matches the PR title verbatim; commit SHA dd0626a55 matches its merge commit.
• Extra Internal entry for #1575 (test(sdk): render-faithfulness test for serialize() bake contract (WS-F)) is honest and its SHA f11b60854 matches the merge commit — beyond Magi's summary but correctly categorized as Internal.
• docs/changelog.mdx <Update> block content is identical to releases/v0.8.11.md.

Ordering dependency — CLEAR

• #3438: MERGED at 2026-08-23T17:18:19Z (base of this PR is exactly its merge SHA).
• #3421: MERGED at 2026-08-23T00:04:46Z.
• #1575: MERGED at 2026-08-22T23:42:41Z.

No unmerged referent in the notes.

CI at head

No failures. IN_PROGRESS: Analyze (javascript-typescript), Build, CLI smoke (required), Perf: drift/fps/load/parity/scrub, Producer: integration tests, Publish, Render on windows-latest, Tests on windows-latest, Typecheck, regression-shards (1–9). CodeQL returned NEUTRAL (informational). All green so far: preflight, format, lint, semantic PR title, docs validate, sdk unit+contract+smoke, studio load/timeline smokes, producer unit, npx shim (mac/ubuntu/windows), fallow audit, codex plugin package, preview parity, preview-regression, mintlify.

Prior reviews

None at head.

Notes for the merge decision

• Author miguel-heygen is on the auto-approve trust list, but release PRs require Terence's explicit go — holding.
• Publish job is IN_PROGRESS on this PR; per PR body, the "immutable merged-PR publish workflow will create the canonical tag at the squash merge SHA," so on this PR it should be a dry-run/validation only. Worth eyeballing before merge.
• Regression shards and windows tests are still running; wait for them to close green before stamping.

— Review by tai (pr-review)

[jrusso1020]

Post-merge advisory review (this PR is already merged into main, and the npm publish has completed). Findings are follow-ups, not gating.

I reviewed this as the reviewer of #3438, which this release ships — so the relationship between the two is covered explicitly at the bottom.

Audited: all 18 files; .github/workflows/publish.yml, scripts/set-version.ts, scripts/publish-workflow.test.mjs, scripts/set-version.test.ts at main; every packages/*/package.json at the merge commit 32d58a73e; the npm registry; the check-run timeline on d9989b5f5.

Release contents — verified clean

Everything I could mechanically check on the packaging came back correct:

• File count reconciles exactly. 13 package.json + 3 plugin manifests + docs/changelog.mdx + releases/v0.8.11.md = 18. Nothing rode along.
• No missed package. There are 14 packages/*/package.json at 32d58a73e; all 13 public ones are at 0.8.11, and the 14th (@hyperframes/sdk-playground, private: true, still 0.6.106) is correctly excluded. Plugin manifests are all 0.8.11; root stays private and unversioned.
• Release notes carry no placeholder. releases/v0.8.11.md is free of the CHANGELOG_REVIEW_TODO marker that scripts/set-version.ts:247,292 validates.
• Changelog matches what actually merged, not what was planned. The three entries are exactly the three non-release commits in v0.8.10..32d58a73e: f11b60854 (#1575), dd0626a55 (#3421), 65b2299db (#3438). I checked #1575 specifically because a four-digit-low number in a repo at #3440 looks like a stale link — it is genuine, merged 2026-08-22 with that squash commit.
• All 13 packages are live on npm at 0.8.11. Worth recording one non-finding so nobody else chases it: @hyperframes/cli 404s on the registry, which looks like a partial publish and is not one. The CLI ships unscoped as hyperframes (latest = 0.8.11), by the deliberate name rewrite at publish.yml:165-179.

important — the publish outran its own verification

The merge landed at 18:49:14Z, roughly a minute after CI started on d9989b5f5. At that moment, of the 8 required contexts on main's ruleset (Semantic PR title, Test: runtime contract, Typecheck, Build, regression, Test, Render on windows-latest, Tests on windows-latest), exactly one — Semantic PR title, done at 18:48:12Z — had reported. The rest finished afterwards or are still running:

context	started	finished
Publish (npm)	18:49:22	18:53:42
Test (required)	18:51:01	18:57:54 ✅
Build / Typecheck (required)	18:48:29	18:51:28 / 18:51:55 ✅
Tests on windows-latest (required)	18:49:24	still running
regression-shards (required)	18:49:18	earliest finished 18:56:27; 6 of 9 green, 3 still running

So 0.8.11 was published to the latest dist-tag at 18:53:42 — before Test reported (18:57:54), before any of the nine regression shards had finished (earliest 18:56:27), and while Tests on windows-latest was still running, as it is at the time of writing.

To be clear about severity: everything that has completed is green — Test, Build, Typecheck, Render on windows-latest, Test: runtime contract, and 6 of 9 shards — so this is very likely a fine release, and I am not asking anyone to undo it. The cost is that the failure mode moved. With the gate in place, a red shard blocks a merge; published first, a red shard means a bad latest on npm and a 0.8.12 to walk it back — and the render regression shards are exactly the checks a caption/dedup change like #3438 would trip. Worth watching the last three shards and the Windows run to completion.

This also interacts with the workflow's own stated design. publish.yml:6-8 says "Stable tags are created only by a merged, reviewed release PR", and the stable path is deliberately routed through the PR gate rather than tag push. That gate is carrying both the review and the CI guarantee, so an admin merge one minute after opening removes both at once. Purely mechanical observation about where the safety property lives — the merge decision itself is the maintainer's call.

should-be-follow-up-ticket — two hand-maintained package lists, and the omission direction is silent

The set of publishable packages is hardcoded twice, independently:

• scripts/set-version.ts:23-37 — a 13-entry PACKAGES array.
• .github/workflows/publish.yml:152-163 — 12 explicit publish_pkg calls, plus the CLI block at 165-179.

Nothing reconciles either list against the actual workspace (packages/* in the root package.json). I checked for a guard before raising this: scripts/publish-workflow.test.mjs covers the event path, the checkout guard and tag-recovery idempotency, but never the package list; scripts/set-version.test.ts does not compare PACKAGES to the directory either.

Both lists happen to agree today. The asymmetry is in how they fail. Forgetting set-version.ts is loud — the new package keeps the old version and the publish step's npm view check trips over it. Forgetting publish.yml is silent: no publish_pkg call is made, FAILED is never set, the job reports success, and the package simply never reaches npm at a version the rest of the release advertises. An omission cannot fail a list it was omitted from.

Cheapest fix: derive both from packages/* filtered on private !== true, or keep the arrays and add one test asserting each equals that set.

note — the publish trigger surface, for anyone carrying an older mental model

publish.yml has two triggers, not three, and there is no workflow_dispatch:

• push: tags: ["v*-*"] — the pattern requires a hyphen, so this matches v0.8.11-rc.1 and cannot match a stable v0.8.11. Prerelease channels only.
• pull_request: [closed] on main, gated by github.event.pull_request.merged == true && startsWith(head.ref, 'release/v').

So the claim that merging this PR was the only way to publish 0.8.11 is correct, and for a stronger reason than "no tag was pushed": a stable tag push would not have triggered the workflow at all.

on #3438, which this release ships

My review there was a COMMENT pinned to 247487bb3, and I withheld a stamp for an authorization reason, not a code one. Since the branch moved again afterwards, I re-anchored rather than assume:

• Merged head is f0d0d2176 — a fifth head after the four I reviewed against. I fetched all 15 files at both SHAs and compared: only timeline.ts (+5) and timeline.test.ts (+45) differ. The other 13, including all of frameCapture.ts, are byte-identical to what I already reviewed.
• That delta is precisely the one substantive finding I raised, fixed. parseElementDurationAttr now returns 0 rather than null when either duration attribute is explicitly non-positive, so an explicit data-duration="0" is authoritative again and the clip is dropped, while data-duration="0" + data-hf-authored-duration="3.5" correctly yields 3.5. Both cases are pinned by the new tests, including the it.each(["0","-2"]) drop case. Good fix, and better than the narrower one I had in mind.
• I re-verified all three call sites against the pre-#3438 baseline dd0626a55: site timeline.ts:364 is restored to baseline behaviour, and sites 263 and 604 gate on > 0 / <= 0, so 0 and null are equivalent there — unchanged in both directions.
• One verified non-finding, so nobody spends time on it: parseElementEndAttr was not given the matching treatment, which looks like an oversight and is inert. Its only call site (timeline.ts:604-609) collapses 0 and null into the same branch, and init.ts:475-491 strips both data-duration and data-end after copying them to the authored attributes — so the one attribute pair that could distinguish them is never produced by normalization. Nothing to chase.

Which means the code concern I raised on #3438 was addressed before it shipped, and I am not going to imply this release is unsound on the strength of a process disagreement. The packaging is clean; my one real reservation about #3440 is the sequencing in the section above, and it applies to any release merged that way rather than to this change.

Verdict: COMMENT (post-merge: Ready — contents verified clean; one important process follow-up on publish-before-verify, one ticket-sized follow-up on the duplicated package lists)
Reasoning: Every mechanical release check passes — all 13 packages bumped and live, file count reconciled, changelog accurate against the commit range, no placeholder markers. The two findings are about the release process, not this release's contents: the npm publish completed before the required test suite reported, and the publishable-package list is hardcoded in two places with no reconciliation, where an omission fails silently.

— Rames Jusso