feat(studio): sync origin, out-of-sync repair, linked selection toggle and grouped clip menu (7/8)

[vanceingalls]

Summary

Premiere-style sync for linked pairs, plus a grouped clip menu. data-sync-origin records where the audio belongs against its video. Out-of-sync badges offer Move into Sync and Slip into Sync, and a Linked Selection toggle sits in the timeline toolbar. The clip menu is ordered into Time, Sound, Picture, Clipboard and Delete groups (host items from #4784 stay on top), and speed edits fan out to every link member in one undo step.

Changes

• core: sync origin, offset math and move/slip into sync.
• studio: detach, link and keep-sound cutout write a sync origin that unlink keeps. Linked Selection toggle (on by default). Link groups share a label colour (theme tokens). OutOfSyncBadge with Move/Slip into Sync. Grouped ClipContextMenu with a measured height. Link/unlink items name the partner. Linked speed edits (linkedSpeedEdits). The audio parent tick is replaced by the data-link chain badge.
• studio-server: freeze-frame and split halves mint lk-N links and re-mint sync origins.
• sdk: syncOffset, moveIntoSync, slipIntoSync.
• cli: hyperframes timeline rows report syncOffsetFrames and print out-of-sync.
• skills: data-sync-origin in hyperframes-core.

Testing

Static gates on the layer tip: bun install, bun run build, tsc --noEmit for every touched package (0 errors), oxlint and oxfmt --check on files changed vs main (clean), gen:skills-manifest --check (in sync), scripts/comment-ratchet.mjs (ok).

• Scoped vitest: core 3815, sdk 573, studio 6374, studio-server 999. All pass.
• cli 3956 pass; 2 upstream tests are timing-flaky under the parallel run. cloud/download passes alone. studioServer.stampOnOpen passed 1 of 2 runs alone on the same tree: it sometimes catches an atomic-write .tmp from fix: readers never see an empty or half-written project file #4777.

Notes

• SDK moveIntoSync on a linked clip unlinks it, and slip isn't capped at the media end.
• Part of the audio-on-video stack. See the bottom PR for the overview.

🤖 Generated with Claude Code

Before

After

Out-of-sync badge (-15) with Move into Sync and Slip into Sync; Linked Selection toggle in the toolbar.

[jerrai-bot-heygen]

Reviewed the #4820 delta at exact ca563f775fcd9f0adba2c468f538f1dca6d6d037 against stacked #4818 dddeeddfd677618b68b0aa2c5abf81ac19910c55. Two correctness holds are inline: a one-sided cut loses the uncut source partner's sync origin; and SDK Slip into Sync can write a lower-precedence trim attribute, report zero offset, yet leave playback unchanged. The out-of-sync badge menu also has only a horizontal viewport adjustment; near the bottom edge its actions can render off-screen (OutOfSyncBadge.tsx:33–41), a UI follow-up. Hosted Comments is red on seven raised-comment-share files (the full job log names them), separately blocking the stack. #4818 remains held below this PR. I did not run local tests or a browser, and took no merge/release action. — Jerrai

[jerrai-bot-heygen]

relinkSplitHalves remints a right half's data-sync-origin even if only one member of an unlinked video/audio source pair is cut. This is reachable from Studio's razor path: useRazorSplit.ts expands only data-link members (and can split a single unlinked clip), then the server calls this helper on the right-half IDs. If video and audio share origin lk-1, unlink them and cut only the audio, the new right audio gets lk-2 while the uncut video stays lk-1; findSyncPartner returns null and the new half loses its out-of-sync badge/Move/Slip actions. The added server test cuts both members, so it cannot catch this. Preserve the source origin for a one-sided cut or otherwise map both source halves and test that case.

[jerrai-bot-heygen]

When an authored clip has both data-playback-start and data-media-start, this chooses to write data-media-start because it exists. But packages/parsers/src/mediaDuration.ts:19–22 and core runtime readMediaStart prioritize data-playback-start; the write does not change playback. For example, video and audio source peers with equal timeline start, audio data-playback-start="0" and data-media-start="0"; move the audio later by 0.5 s, then Slip into Sync. This action writes only data-media-start="0.5", the SDK's offset reader reports zero, but playback continues at the old data-playback-start="0" and stays late. Please use the actual playback-precedence attribute consistently (or reconcile/remove the overridden alias), with a both-attributes regression that checks rendered source timing rather than only the SDK offset.

[github-actions]

Edit accuracy: 953 passing here, 953 on the base branch

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)

• seqab-none-px-r0-nested-z100: tracking 0.07, pressJump 0, drop 0, reload 0, render 0.03, undo false, teleport true / tracking 0.07, pressJump 0, drop 0, reload 0, render 0.03, undo true, teleport true / tracking 0.07, pressJump 0, drop 0, reload 0, render 0.03, undo true, teleport true

[jerrai-bot-heygen]

Re-reviewed exact c02dae4228460a446228a75934277e0fafec7561 against current #4818. The prior two code holds are repaired: a one-sided cut keeps the original sync origin so its uncut video/audio partner remains discoverable; Slip into Sync now reads playback's in-point precedence and writes data-playback-start when authored, with corresponding regression assertions. Comments and SDK checks pass. I did not run a live Studio/browser or one-sided-cut end-to-end test.

This is not an approval: current-head File size check and Studio and player captures are red, and no per-PR evidence waiver was routed. Please clear the file-size gate and supply required Before/After captures or explicitly waive the capture evidence for this PR; recheck the live head after that. The older CHANGES_REQUESTED state and the lower #4818 stack holds still block landing. No merge/release action. — Jerrai

[jerrai-bot-heygen]

At exact fc172418abe4561eb1a8ea53c5c2c855b9873047, the previously reviewed one-sided sync-origin and slip-precedence repairs remain in place; the current head now passes the file-size and Comments gates (I am not repeating the prior red status). The SDK and Studio hosted tests ran green. I found no new confirmed code hold in this bounded re-review, but Studio and player captures ran and failed because the PR body still lacks Before/After media and no per-PR waiver was provided. No approval yet; my earlier CHANGES_REQUESTED state continues until this visual evidence or explicit waiver arrives. I did not run live Studio/audio or merge/release. — Jerrai

[jerrai-bot-heygen]

Reviewed #4820 at e9f8992e against #4818 367fd138. findSyncPartner and same-origin pairing now use nearest inline/file composition scope, with negative cases for reused link IDs; playback-start precedence also remains aligned with the SDK. No new #4820-specific blocker found. The parent #4818 still has an SDK ambiguous-ID isolation hold in my current-head review, so the complete stack is not ready. This layer’s required Studio/player captures check is FAILED without Before/After evidence or waiver; edit-accuracy and Comments pass. No local test or playback. — Jerrai

[jerrai-bot-heygen]

Re-reviewed this exact #4818-based layer: the previously identified one-sided sync-origin and playback-start precedence repairs remain in the preserved 75-file layer patch, and nearest composition scope prevents reused link IDs crossing inline/file hosts. The only concurrent main overlap adds the shared typing-target guard and test to the snap key without dropping the layer changes. Captures and current code checks pass; pending checks and other reviewers' holds remain separate. — Jerrai

[jerrai-bot-heygen]

Exact d03ecc53 rebase review: all 75 layer paths and patch hunks match the old approved parent→head delta. The sole concurrent overlap is Studio's public index.ts: new-parent WebMCP exports coexist with this layer's separate audio-meter export. The prior one-sided relink and playback-start sync precedence repairs remain in the layer. This approves the layer code only; #4815's viewport failure and hosted checks still gate the stack. No merge/release action. — Jerrai

[jerrai-bot-heygen]

The rebased #4820 layer has the same 75 changed paths and the same addition/deletion hunks as the previously approved layer (only hunk offsets move around the new #4818 remote-URL fix). The one-sided split repair remains in the exact-head source; I also read the new parent’s serialized remote path/query identity and its collision tests. CI is still pending. This code approval does not merge or release. — Jerrai

[jerrai-bot-heygen]

Fresh review of the rebased layer at exact a8a9f431382490a00335658a66c26d86f64e0a24, now based on merged #4818 (0559be0b). I independently compared its complete parent→head patch with the previously approved #4820 layer (3283d701→f5e1b467): 25 commits, 75/75 paths, identical statuses and +2,046/−253 line totals, with zero normalized-hunk differences or missing patches. At the new head, one-sided splits retain the source sync origin and Slip into Sync writes data-playback-start when it takes precedence. This approval covers the unchanged layer, not CI completion or an authorization to enqueue/merge. Hosted checks were still running, with no failing check displayed at click time; no local tests were run. — Jerrai