test(core,studio): add T3+T7 hfId targeting stubs (spec for R1)

[vanceingalls]

Summary

• T3 (packages/studio/src/utils/sourcePatcher.test.ts): 5 it.todo stubs for PatchTarget.hfId targeting — inline style patch, text content patch, attribute patch, hfId preservation after patch, and fallthrough when hfId not found
• T7 (packages/core/src/studio-api/helpers/sourceMutation.test.ts): 2 it.todo stubs for SourceMutationTarget.hfId — basic style patch by data-hf-id and data-hf-id attribute survival after patch

Neither interface has hfId yet. R1 adds the field to both PatchTarget and SourceMutationTarget, implements the [data-hf-id="…"] lookup branch in findTagByTarget / findTargetElement, then converts these stubs to real assertions.

Test plan

• bun run --cwd packages/studio test -- sourcePatcher.test.ts — 24 pass, 5 todo
• bun run --cwd packages/core test -- sourceMutation.test.ts — 37 pass, 2 todo

[vanceingalls]

• test(core,studio): add T3+T7 hfId targeting stubs (spec for R1) #1267 👈 (View in Graphite)
• test(core): add T6a GSAP parser golden baselines (Recast/Babel snapshot) #1263
• test(core): add T10 PreviewAdapter contract stubs (spec for R7) #1262
• refactor(core): extract maxEndTime+serialize to parsers/test-utils.ts (TU) #1261
• test(studio): add T5c review-fix gaps in manualEditsDomPatches characterization #1259
• test(studio): add T5b rotation+motion build-patches characterization #1258
• test(studio): add T5a pathOffset+boxSize build-patches characterization #1257
• main

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

[miguel-heygen]

5 stubs in sourcePatcher.test.ts (T3) and 2 in sourceMutation.test.ts (T7) for the hfId targeting path.

The stubs cover the right cases for R1:

• PatchTarget.hfId: inline style, text content, attribute ops — the three op types applyPatch handles
• hfId preservation after patch — important since the patch applies to source HTML and could in principle clobber data-hf-id if the rewriter isn't careful
• Fallthrough to selector when hfId not found — this is the key contract boundary: fail gracefully, don't silently no-op

The corresponding SourceMutationTarget.hfId stubs in T7 are leaner (2 stubs vs 5), which makes sense — sourceMutation goes through findTargetElement which is a single lookup vs sourcePatcher's more complex AST rewriting path.

P3 nit: the stub "uses [data-hf-id=...] selector when resolving target" in T7 slightly pre-specifies the implementation (bracket-attribute selector). If R1 uses a different internal lookup (e.g. querySelector without necessarily constructing a CSS selector string), the stub name could cause confusion. Consider: "resolves element by hfId attribute".

No blockers. The two existing test suites (sourcePatcher.test.ts should have 24 pass + 5 todo; sourceMutation.test.ts 37 pass + 2 todo) must pass with 0 failures for CI to be green.

[james-russo-rames-d-jusso]

Round-1 review of T3 + T7 (hfId targeting stubs, spec for R1). +24/-0, two files: 5 it.todo stubs for PatchTarget.hfId in Studio's sourcePatcher, 2 it.todo stubs for SourceMutationTarget.hfId in Core's sourceMutation.

What's right

Stubs are paired to the R1 implementation points. PR body names them: findTagByTarget in Studio and findTargetElement / sourceMutation.ts:34 in Core. Both functions live where you'd expect the lookup branch to land — keeping the spec stubs in the same test files as the existing selector/id tests means R1's PR-author flips them from it.todo to it(...) without scaffolding new infrastructure.

T3's fallthrough case is the critical one. Line 533:

it.todo("hfId lookup falls through to selector when hfId not found");

This is the load-bearing semantic for migration safety. If R1 lands and existing compositions don't yet have data-hf-id attrs, the new code path has to gracefully fall back to selector-based targeting. Pinning this as an explicit test in the spec means R1 can't ship without the fallback. ✓

T3's "hfId attribute is preserved after a patch" guards the round-trip invariant. Same shape as the existing motion attribute round-trip via sourcePatcher test block above it — if a patch strips the data-hf-id attr accidentally, subsequent patches lose the addressability and the editor's reference graph breaks.

Concerns

[concern — T3 / T7 surface asymmetry needs a one-line explanation] T3 has 5 stubs covering style, text, and attribute patch types plus preservation and fallthrough. T7 has 2 stubs covering only style patch + attribute survival. This is either:

(a) SourceMutationTarget only supports a narrower patch surface than PatchTarget — in which case 2 stubs is correct AND the PR body should say "T7 is intentionally narrower because Core's sourceMutation only exposes the style branch over the data-hf-id path", or

(b) SourceMutationTarget supports the full surface and T7 is missing three stubs (text-by-hfId, attribute-by-hfId, and the fallthrough case).

The PR body says T7 covers "basic style patch by data-hf-id and data-hf-id attribute survival after patch" — "basic" implies (a), but doesn't confirm it. Worth a one-line clarification so R1's PR author doesn't have to dig through sourceMutation.ts to figure out which branches need test coverage. If (b), this PR is missing three stubs.

Also: T7 has no fallthrough stub. If the Core surface DOES need fallback semantics ("hfId-not-found falls through to the selector branch"), R1 will land without that test pinned. If it doesn't (because Core mutation always has an id available by contract), that's worth noting in the test file.

[nit — stub naming inconsistency between T3 and T7] T3 uses imperative-active voice ("updates inline style by data-hf-id"). T7 uses the same pattern but for one case writes "patches element by data-hf-id" rather than "updates element by data-hf-id" — and the second T7 stub uses noun-phrase voice ("data-hf-id attribute survives the patch"). Tiny noise; converging on one voice across both files (e.g. "updates X via data-hf-id" and "data-hf-id is preserved after a Y") makes the stubs feel like one spec rather than two.

Plan-doc alignment

T3 + T7 are explicit specs for R1 (the hfId?: string field + [data-hf-id="..."] lookup branch on both PatchTarget and SourceMutationTarget). Stub-only structure matches the T4 / T10 pattern in this stack. Test plan checklist (24 pass, 5 todo / 37 pass, 2 todo) confirms the stubs compile and the existing suites still pass.

Verdict

Clean stub PR. The T3/T7 asymmetry is the only thing worth resolving before this lands — if (a) above is correct, one sentence in the file or PR body documents it; if (b), three more stubs in sourceMutation.test.ts close the gap. Either way, the answer is short. Leaving as a comment.

— Review by Rames D Jusso

The base branch was changed.