The gap
With the SDK shadow removed in #1462 (dark-launch cutover), the offline corpus is the only thing verifying that the SDK serializes a mutation identically to the legacy path. That coverage exists for the GSAP writer (gsapWriterParity.corpus.test.ts, recast vs acorn, AST level) but not for the DOM-edit surface.
setStyle / setText / setAttribute (sdkCutover.ts:208-243, inline-style cut over in #1522) have no differential test. sdkCutover.test.ts runs against a mocked session (makeSession, :123), so it pins which op dispatches, not that the serialized HTML matches the legacy patch-element output. Nothing in the test tree references patch-element.
Since this is a hard cutover, a correct-but-different SDK serialization is what ships. Untested shapes I'd expect to drift first:
- multi-property
setStyle coalescing (transform + transform-origin + --x)
- single-property
null-removal out of a multi-prop style
- shorthand vs longhand (
inset vs top/right/bottom/left)
- quote, semicolon, and ordering style inside the serialized
style=""
The GSAP-writer corpus is strong for what it covers, so this is specifically about the DOM-edit surface, plus a byte-level tier the AST-level harness can't see by construction.
Question
Is DOM-edit serialization parity intentionally left to manual QA during dark-launch, or would a differential corpus be welcome here? If welcome, I can build it incrementally (apply each cutover op through the SDK and the legacy path, assert HTML parity, starting with inline-style), in the same exported-harness shape as runParity / modelOf. Glad to fit it to whatever direction you'd prefer it dovetail with.
The gap
With the SDK shadow removed in #1462 (dark-launch cutover), the offline corpus is the only thing verifying that the SDK serializes a mutation identically to the legacy path. That coverage exists for the GSAP writer (
gsapWriterParity.corpus.test.ts, recast vs acorn, AST level) but not for the DOM-edit surface.setStyle/setText/setAttribute(sdkCutover.ts:208-243, inline-style cut over in #1522) have no differential test.sdkCutover.test.tsruns against a mocked session (makeSession,:123), so it pins which op dispatches, not that the serialized HTML matches the legacypatch-elementoutput. Nothing in the test tree referencespatch-element.Since this is a hard cutover, a correct-but-different SDK serialization is what ships. Untested shapes I'd expect to drift first:
setStylecoalescing (transform+transform-origin+--x)null-removal out of a multi-propstyleinsetvstop/right/bottom/left)style=""The GSAP-writer corpus is strong for what it covers, so this is specifically about the DOM-edit surface, plus a byte-level tier the AST-level harness can't see by construction.
Question
Is DOM-edit serialization parity intentionally left to manual QA during dark-launch, or would a differential corpus be welcome here? If welcome, I can build it incrementally (apply each cutover op through the SDK and the legacy path, assert HTML parity, starting with inline-style), in the same exported-harness shape as
runParity/modelOf. Glad to fit it to whatever direction you'd prefer it dovetail with.