fix(studio): make SDK shadow telemetry fire + be correct (5 fixes, E2E-verified)

[vanceingalls]

Five fixes that make SDK shadow telemetry (#1473/#1474) work end-to-end. All found via live E2E testing of hyperframes preview (browser-use driving the studio + a PostHog network-capture shim); none caught by the unit tests. Every fix verified live.

1. Session never opened in master view — useSdkSession got activeCompPath=null (master = entry comp); guard bailed → SDK session never opened in the default editing surface → all shadow taps no-op → zero telemetry. Fix: activeCompPath ?? "index.html". (phase: skipped_no_ids → opened)

2. Property kebab/camel false-mismatch — inline-style parity read flat.styles[op.property] (kebab) but inlineStyles are camelCase → null read-back → false mismatch on every hyphenated CSS prop (background-color, …). Fix: kebab→camel read-back. (live color edit mc:1 → 0)

3. op:delete never fired for clips — the Delete hotkey routes to handleTimelineElementDelete (not shadow-wired) for any timeline element, returning before handleDomEditElementDelete. Fix: tap runShadowDelete in the timeline-delete path. (clip delete → op:delete mc:0)

4. gsap_fidelity selector-form divergence on add — the SDK writes [data-hf-id="X"] selectors, the server writes .class; id-keyed diff saw them as different tweens → mc:2 on every add. Fix: key by resolved element + method + position. (add mc:2 → 0)

5. Property false-mismatch on data-hf-studio-* markers — canvas-drag/path-offset edits emit attribute ops the parity double-prefixed (data-data-hf-…) and the SDK model excludes (data-hf-*). Fix: attrName() (no double-prefix) + isShadowableOp() drops data-hf-* markers. (drag → op:property mc:0)

Live op matrix (all clean after fixes)

property (color/bg/path-offset), timing (drag + input), delete (clip), gsap (add/update/remove/keyframe), gsap_fidelity (add/update/remove) — all dispatched:true mismatchCount:0.

🤖 Generated with Claude Code

[miga-heygen]

Thorough review of all five fixes. Each one is targeted, correctly identified at the root cause, and test-covered. CI (40+ checks including 8 regression shards) all green.

Fix-by-fix:

1. activeCompPath ?? "index.html" — Master view had null path, guard bailed, zero telemetry. The fallback to "index.html" is the right convention for the entry comp. Clean.

2. Kebab→camel read-back — flat.styles["background-color"] was always null because CSSStyleDeclaration keys are camelCase. kebabToCamel + fallback chain (camel ?? raw ?? null) handles both forms gracefully. Good defensive coding.

3. runShadowDelete in timeline path — The Delete hotkey routed through handleTimelineElementDelete which was never shadow-wired. Single-line addition, sdkSession correctly added to the useCallback deps array. Tight.

4. GSAP fidelity selector resolution — This was the most substantial fix. tweenKey(anim, resolveSelector) normalizes [data-hf-id="X"] vs .class selectors to the same canonical element id via makeSelectorResolver (DOMParser on pre-op HTML, graceful fallback). Since method + position are now part of the key, they're correctly removed from the field-by-field comparison. The posKey numeric normalization handles string/number position ambiguity.

5. data-hf-* marker filtering — isShadowableOp() drops attributes the SDK model explicitly excludes, and attrName() prevents the double-prefix (data-data-hf-...). Applied before both dispatch and parity check — correct, since filtering after dispatch would still report false mismatches.

Tests cover the three most subtle failure modes (kebab-case styles, data-hf-* markers, cross-selector-form matching). The selector resolver test is nicely structured — asserts that without a resolver you GET mismatches, with one you don't.

No issues found. Ship it.

— Miga

[james-russo-rames-d-jusso]

Review at HEAD 02cdd37c.

This PR addresses separate scope from my held #1473 (double-writer race) and #1474 (shadowGsapOp per-property gap) — it's five downstream fixes that make the shadow telemetry from those PRs actually fire + report correctly under live E2E. Each fix is targeted at a real root cause the unit tests missed, all CI green, and Miga already approved with a thorough fix-by-fix breakdown. I agree with the approval on substance; layering a few smaller observations + two questions on the gsap-fidelity selector resolver.

Re-reading my #1473 hold: the race I held on doesn't exist at HEAD — useSdkSession.ts:25-32 confirms the session is opened WITHOUT persist ("shadow-telemetry + selection-sync only — reads from the server but must NEVER write back"). That's resolution path (a) from my hold. I'd missed that #1473's session-open path landed without persist; the load-bearing TODO I quoted was rewritten in-PR to clarify the no-persist contract. Apologies for the false-flag in that review round. #1491 is NOT contingent on the #1473 hold — the race never materialized.

#1474's shadowGsapOp per-property gap is also untouched here; this PR only touches the fidelity diff key, not the per-property emission shape, so that hold is independent and remains open.

Fix-by-fix agreement with Miga:

1. activeCompPath ?? "index.html" — correct entry-comp fallback. (App.tsx:178)
2. kebabToCamel + flat.styles[camel] ?? flat.styles[raw] ?? null — handles both forms gracefully; empty-string CSS values are not nullish so they short-circuit cleanly. (sdkShadow.ts:118-128)
3. runShadowDelete in handleTimelineElementDelete with sdkSession correctly added to the useCallback deps array. (useTimelineEditing.ts:291,304)
4. GSAP fidelity selector resolution via tweenKey(anim, resolveSelector) — element-keyed match across [data-hf-id="X"] vs .x selector forms. Method + position correctly removed from field comparison since they're now part of the key. (sdkShadowGsapFidelity.ts:48-58)
5. attrName() + isShadowableOp() — correct filter applied before BOTH dispatch and parity check; html-attribute and attribute paths both covered. (sdkShadow.ts:29-40,185-189)

Test coverage is right where it should be: kebab-style, data-hf-* marker, and the cross-selector-form match test that asserts the resolver-on vs resolver-off behavior explicitly.

---

Questions / small notes (non-blocking):

• sdkShadowGsapFidelity.ts:184-201 makeSelectorResolver — doc.querySelector(sel) returns the first match; if the pre-op HTML happens to have two elements sharing .x class and the SDK side targets one of them via [data-hf-id="hf-X"], the resolver may map them to different ids and the diff still flags present/absent. Probably rare for studio-emitted templates (one tween per data-hf-id), but worth a sentence in the docstring noting "first-match heuristic — ambiguous selectors may not unify." Or upgrade to querySelectorAll + uniqueness check. Question, not blocker.

• sdkShadowGsapFidelity.ts:48-58 tweenKey collision risk — two tweens on the same resolved element + method + position with different properties (e.g. tl.to(x, {opacity:1, duration:0.5}, 0) + tl.to(x, {scale:2, duration:1}, 0)) would map to the same key; the second map.set overwrites the first and the fidelity diff under-reports. Narrow real-world hit (GSAP authors rarely write coincident tweens on one target), but the fail-mode is silent. Worth a comment noting the assumption "one tween per (element, method, position) — coincident tweens collapse," or a key disambiguator on the props hash if you've seen this in the wild.

• kebabToCamel (sdkShadow.ts:120-122) — regex replace(/-([a-z])/g, ...) handles standard CSS props but doesn't handle vendor prefixes properly (-webkit-transform → WebkitTransform is the correct DOM form, regex gives WebkitTransform too — actually fine). Confirming: -webkit-transform → WebkitTransform via the regex. Works. (Not a finding — just verified.)

• useSdkSession.ts:25-32 docstring is the right shape — explicitly calls out "must re-add persist TOGETHER WITH self-write suppression" for any future cutover. Excellent prereq fencing for whoever picks up Step 3c.

Per established lane split with @rames Jusso (the OG): I review at --comment; he handles stamps. He has the go-ahead to approve from me — Miga's approve already satisfies the human-reviewer bar, and the two questions above are non-blocking design notes the author can address in a follow-up or wave off.

— Rames D Jusso

[vanceingalls]

Thanks @james-russo-rames-d-jusso — both notes addressed in 91a23b989 (docstring ceilings, per your "comment noting the assumption" option):

1. tweenKey collision — documented as a one-tween-per-(element, method, position) assumption with last-wins collapse. Note on why props can't join the key: a matched pair must share a key for the field-diff to run, so raw props would split real value-drift into present/absent. Upgrade path named (property-name hash, which survives value drift). Not building it — not seen in studio templates.

2. makeSelectorResolver first-match — documented the first-match heuristic + the ambiguous-shared-class fail-mode; upgrade path named (querySelectorAll + uniqueness). Safe for studio templates (one tween per data-hf-id).

vendor-prefix + useSdkSession no-persist confirmations noted — agreed on both. Leaving the disambiguators as YAGNI follow-ups.