[miguel-heygen]

What changed

The render's compile step now resolves a data-composition-src through one helper, resolveCompositionSrc (utils/paths.ts), at its three sites in htmlCompiler.ts (the pre-flight check, the sub-composition reader and the inliner's reader). It decodes %xx, treats a leading / as the project root (the stylesheet reader already does both), keeps a name that exists only as written, and returns null when the decoded path is not inside the project. Each data-composition-src is also rewritten once, in the entry html and in every sub-composition file the compiler reads, to the decoded project-relative path, so the asset rewriting (rewriteAssetPath) sees the real folder and an encoded folder's sibling images are re-pointed. A null is reported by the pre-flight as "it is outside the project folder" and read as missing elsewhere.

Why

A compositions/my%20scene.html or /compositions/scene.html source is read by the Studio preview but rendered as "the file does not exist" (composition file referenced by data-composition-src cannot be rendered). Reproduced on GitHub runners for 0.9.16 and 0.9.19: plain, ./ and (on Windows) backslash and wrong-case spellings render; the encoded name and the leading slash fail on both Windows and Linux with that text.

The guard matters because decoding opens a way out: before this change resolve(projectDir, src) already followed ../ and an absolute path anywhere on the disk, and %2e%2e%2f would have followed once decoded. A decoded path that leaves the project is now refused.

What I measured

• fails without the fix: packages/producer/src/services/htmlCompiler.test.ts, six new cases: "compileForRender reads a data-composition-src written with a %20-encoded name" / "...a leading slash for the project root", and "compileForRender refuses a data-composition-src that leaves the project through" dot-dot segments, an encoded ../, a leading slash and dot-dot, an encoded leading slash and dot-dot. With htmlCompiler.ts and paths.ts at main: 6 fail, 2 pass; with the change that file and utils/paths.test.ts give 202 pass, 0 fail (bun test, Linux box). Also "compileForRender re-points a sibling asset of a sub-composition whose folder is %20-encoded": fails (1 fail) with the previous head's htmlCompiler.ts, passes with this one.
• The GitHub runner repro above.

What I did NOT exercise

• Studio-server and the core bundler's own source resolution (the preview path) are not changed or audited here.
• Windows drive-letter paths and UNC sources go through isPathInside but have no test of their own.
• No full render of a project with an encoded source; the compile step is what the tests run.

Size

About 60 changed lines in 3 files, 40 of them tests: a lone fix on one resolver; nothing open on it to carry it.

[heygengenesis]

Verdict: REQUEST CHANGES · 1 blocker · 1 important · 0 nits · head 6e1404cb

• blocker: Preflight (lint + format) fails (oxfmt --check: htmlCompiler.test.ts). Because of that, regression-shards was skipped and regression is red, so this compile-path change has not been through the render regression suite. ↓ inline
• important: the encoded-directory case is only half supported. ↓ inline

Scope

Read all 3 files. Checked every data-composition-src resolution in producer: the three sites changed here, plus recompileWithResolutions, which runs after the pre-flight. Refusing paths outside the project matches the preview bundler (resolveEntryPath → isSafeProjectPath). The tests named on the 'fails without the fix:' line fail at main as claimed: dot-dot used to read the outside file, and a leading slash resolved to the filesystem root. Studio-server resolution was not audited, as the PR says. Windows render verification also fails on main at 410a516c.

[heygengenesis]

blocker (CI): oxfmt --check flags this file, most likely this over-long it.each(...)(...) line. Preflight fails, so regression-shards is skipped and regression fails with "Regression shards did not succeed." Run bun run format and push, so the render regression suite actually runs on a producer change.

[heygengenesis]

important: this decodes the src to find the file, but the inliner and the gsap rewrite still pass the raw srcPath to rewriteAssetPath (parsers/src/rewriteSubCompPaths.ts:79-86). There, compDir keeps %20, so assetExists("my%20dir/img.png") is false. As a result, data-composition-src="my%20dir/scene.html" now renders, but its sibling <img src="img.png"> is not re-pointed and loads from the project root (missing). The new tests only encode the file name. Pass the decoded project-relative path as compSrcPath, or add a case with the encoding in the directory part.

[github-actions]

Edit accuracy: accurate 267 (base branch 267), smooth 120 of those

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 (8)

• seqplainkeys-none-center-r0-nested-z100 (fixed by studio: undo/redo on a keyframed plain element sometimes leaves the box 230-400px off (edit-accuracy seqplainkeys-none-*) #6989): pass, passes
• seqplainkeys-none-center-r0-root-z100 (fixed by studio: undo/redo on a keyframed plain element sometimes leaves the box 230-400px off (edit-accuracy seqplainkeys-none-*) #6989): fail / pass / pass, passes
• seqplainkeys-none-center-r30-root-z100 (fixed by studio: undo/redo on a keyframed plain element sometimes leaves the box 230-400px off (edit-accuracy seqplainkeys-none-*) #6989): not run
• seqplainkeys-none-pct-r0-root-z100 (fixed by studio: undo/redo on a keyframed plain element sometimes leaves the box 230-400px off (edit-accuracy seqplainkeys-none-*) #6989): pass, passes
• seqplainkeys-none-pct-r30-root-z100 (fixed by studio: undo/redo on a keyframed plain element sometimes leaves the box 230-400px off (edit-accuracy seqplainkeys-none-*) #6989): not run
• seqplainkeys-none-px-r0-nested-z100 (fixed by studio: undo/redo on a keyframed plain element sometimes leaves the box 230-400px off (edit-accuracy seqplainkeys-none-*) #6989): pass, passes
• seqplainkeys-none-px-r30-nested-z100 (fixed by studio: undo/redo on a keyframed plain element sometimes leaves the box 230-400px off (edit-accuracy seqplainkeys-none-*) #6989): not run
• seqplainkeys-none-px-r30-root-z100 (fixed by studio: undo/redo on a keyframed plain element sometimes leaves the box 230-400px off (edit-accuracy seqplainkeys-none-*) #6989): not run

[miguel-heygen]

Head 9469790: oxfmt applied (Preflight/Format blocker); the encoded-folder finding is fixed at the root: every data-composition-src is rewritten once to its decoded project-relative path (entry html and each sub-composition file read), so rewriteAssetPath and the gsap rewrite see the real folder. New test: an encoded folder with a sibling image fails with the previous head's htmlCompiler.ts and passes now; compiler and paths tests 202 pass, 0 fail.

[heygengenesis]

Verdict: APPROVE — 2 resolved, 0 open, 0 new · 6e1404cb → 9469790c

Formatting passes, and the regression shards ran and passed on this head (run 42228938094, shards 1–10). The data-composition-src values are normalized in both the entry and the sub-composition HTML. The subCompositions keys and the inliner's lookups therefore agree, and rewriteAssetPath now gets the decoded folder; the new encoded-folder test covers this. Windows render verification was still running; it also fails on main.