fix(core): split-into-property-groups and replace-with-keyframes mutations

[miguel-heygen]

Summary

• Add split-into-property-groups server mutation for atomic property-group splitting
• Add replace-with-keyframes server mutation for keyframe replacement
• Client commitMutation returns early on changed:false instead of throwing

Test plan

• Build passes
• Typecheck clean
• Mutation endpoints return correct responses

Stack: 2/7 — depends on #1354

[miguel-heygen]

• feat(studio): off-screen element indicators + unclipped overlay #1360
• fix(studio): gesture recording replaces existing position keyframes #1359
• fix(studio): property panel group-aware keyframe routing #1358
• fix(studio): keyframe cache propertyGroup tagging + timeline UI #1357
• fix(studio): per-property-group intercept routing + drag/resize fixes #1356
• fix(core): split-into-property-groups and replace-with-keyframes mutations #1355 👈 (View in Graphite)
• fix(core): per-property-group keyframe foundations #1354
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

[james-russo-rames-d-jusso]

Verdict: LGTM with one validation nit. Wire shape correct; new mutations land cleanly.

R2 carry-overs

• RC5 throw flip ✅ — files.ts:1106 — changed boolean drives both write-skip and response payload; client (useGsapScriptCommits.ts:135-147) returns early on result.changed === false without throwing. Matches the R2 ask.
• splitIntoPropertyGroups mutation ✅ — gsapParser.ts:2352-2480 emits per-group tweens; downstream IDs flow through addAnimationWithKeyframesToScript/addAnimationToScript, then re-suffixed via ${baseId}-${propertyGroup} at gsapParser.ts:1047. ID-suffix wire is coherent.
• replace-with-keyframes purpose — gesture/drag-commit primitive. Consumers at gsapDragCommit.ts:132 and gsapRuntimeBridge.ts:394 (land in #1357) call it to atomically replace a flat tween with a keyframed version.

Concern (validation)

• files.ts:639-648 — replace-with-keyframes doesn't validate body.keyframes is a non-empty array. addAnimationWithKeyframesToScript with an empty list silently no-ops the add, but removeAnimationFromScript still runs → data loss on a malformed client call. Wrap in the same shape check as split-animations (line 645).

Test coverage

5 cases for splitIntoPropertyGroups in gsapParser.test.ts:2163-2245 (flat-3-group, flat-2-group, no-op single-group, position/duration/ease preservation, keyframed split). Good coverage. No test for the new replace-with-keyframes route or for changed: false short-circuit in commitMutation.

Cross-PR coherence

Emits propertyGroup on every split-output animation via the re-parse path (anim.propertyGroup line 941). #1357 caches it, #1358 reads it.

— Review by Rames D Jusso

[james-russo-rames-d-jusso]

R3 verification — concerns. Both R2 nits still open.

• files.ts:649-660 — case "replace-with-keyframes" still calls addAnimationWithKeyframesToScript(script, ..., body.keyframes, body.ease) with no body.keyframes.length > 0 guard. A request with an empty array silently removes the animation and adds nothing back. Guard at top of case.
• useGsapScriptCommits.ts:116 — R3 introduced throw new Error(\Mutation failed: ${mutation.type}`)on!result. No toast, no .catch()at the call site. Combined withvoid commitMutation(...)elsewhere this propagates as an unhandled rejection. Either wrap inshowToast(style consistent with #1359'sshowToast("Selection lost during recording", "error")) or attach .catch(showErrorToast)` at call sites.

Review by Rames D Jusso

[vanceingalls]

Verification pass — R3 items checked against current HEAD (ec57455).

1. Empty-keyframes guard — case

NOT fixed. HEAD still has no guard:

case "replace-with-keyframes": {
  const script = removeAnimationFromScript(block.scriptText, body.animationId);
  const added = addAnimationWithKeyframesToScript(script, body.targetSelector, body.position, body.duration, body.keyframes, body.ease);
  return added.script;
}

No body.keyframes.length > 0 check. Empty array → silent remove with no replacement, same as R3.

2. Unhandled throw —

NOT fixed. throw new Error(Mutation failed: ...) is still present at line 138, and there are 10+ void commitMutation(...) call sites (lines 205, 242, 255, 337, 347, 362, 376, 386, 486, 508, 527, 537) with no .catch(). These throw as unhandled rejections.

Both R3 blockers remain open. Not stamp-ready.

— Vai (verification pass)