chore: release v0.6.6

[terencecho]

Stable release v0.6.6.

Merging this PR will trigger the publish workflow to push all packages to npm with the latest dist-tag.

[jrusso1020]

APPROVE at f5190729. Smallest possible release PR — 7 package.json files, 0.6.5 → 0.6.6 patch bump across the monorepo. Nothing else in the diff.

Version-bump consistency

Verified all 7 packages are bumped in lockstep:

Package	Before	After
@hyperframes/cli	0.6.5	0.6.6
@hyperframes/core	0.6.5	0.6.6
@hyperframes/engine	0.6.5	0.6.6
@hyperframes/player	0.6.5	0.6.6
@hyperframes/producer	0.6.5	0.6.6
@hyperframes/shader-transitions	0.6.5	0.6.6
@hyperframes/studio	0.6.5	0.6.6

Sequential patch bump, no skipped numbers. ✓

Two minor process notes (non-blocking)

1. No CHANGELOG / release notes in this PR. The body says "Stable release v0.6.6" but doesn't enumerate what's in it. If the publish workflow auto-generates release notes from commit messages between v0.6.5 and the merge SHA (common pattern), this is fine — the GitHub Release page becomes the user-facing changelog. If not, worth adding a one-line summary of the changes since v0.6.5 (notably: hf#739/#805 Electron rAF tick fix, hf#741 layers panel, hf#779 three-dissolve block, hf#801 manual-edits persistence fix, hf#802 Studio auto-reconnect, hf#806 favicon fix, hf#811 work-area I/O markers, plus the worker-pool stack hf#756/#757/#758 if those landed).

2. No lockfile change. Whether pnpm-lock.yaml needs updating depends on how workspace dependencies are declared in the packages' package.json files. If they use "@hyperframes/core": "workspace:^", the version bumps propagate automatically through workspace resolution and the lockfile doesn't change. If they use "^0.6.5", the lockfile would need an update to track the new resolved version. Worth confirming the workspace-deps convention (pnpm-workspace.yaml) is workspace: style and not concrete-range style — a one-line grep across the package.json files.

Per the release-merge discipline memory

This is a release PR but a TINY one (version-bumps only, no merged feature payload). The "scope-down don't stand down" calibration from feedback_release_merge_standdown_was_wrong.md applies to release-MERGES that bundle large feature payloads (like hf#746's 22k LoC where conflict-resolution discipline matters). A version-bump-only PR has no conflict-resolution surface to audit — the diff IS the entire change.

The substantive merge already happened on main between v0.6.5 and now; this PR is the publish trigger. The audit point is "do the published packages match the main branch state and the version label?" — answered yes by:

• The version bump being sequential
• All 7 packages aligned
• CI matrix re-running on the release branch (Lint ✓, Format ✓, File size check ✓, Semantic PR title ✓, CodeQL neutral, plus all the in_progress matrix workers)

CI

Mostly in_progress; no failures yet. Completed and green: Lint ✓, Format ✓, File size check ✓, Semantic PR title ✓, Detect changes ✓, CodeQL neutral (no findings — not a failure). Build, Test, Typecheck, CLI smoke, Test: runtime contract, all 5 Perf jobs, all 10 regression-shards, both Windows jobs, Preview parity still running. Given the diff is 7 lines of version-bumps in non-code files, expectation is comprehensive green.

Verdict

APPROVE. Ship 🚀 once CI matrix completes — the publish workflow trigger handles the rest. If the publish workflow has any pre-publish guard scripts (e.g., "tag doesn't already exist" or "all packages have matching version"), those should fire automatically on merge.

— Rames Jusso (pr-review)