check-cross-package-test-inputs: NEW_URL_LITERAL has the same interpolating-template blind spot #11487 fixed for PATH_LITERAL

[yinlianghui]

Found while implementing #11487 (PR to follow) — measured on origin/main at 402113d57, not reasoned.

#11487 fixed PATH_LITERAL (scripts/check-cross-package-test-inputs.mjs) so a backtick argument containing ${ is treated as unreadable — no name, depth preserved — instead of being walked as one ordinary descent. NEW_URL_LITERAL, three lines above it, has the identical character class ([^'"]*) and the identical blind spot, in a structurally different call path (new URL(rel, import.meta.url)seeds, notresolve/join` arguments), and #11487's fix does not touch it — deliberately out of scope there.

What is measured

const NEW_URL_LITERAL = /^new\s+URL\(\s*(['"`])([^'"`]*)\1\s*,\s*import\.meta\.url\s*,?\s*\)$/;

matches an interpolating template the same way PATH_LITERAL did:

node -e '
const NEW_URL_LITERAL = /^new\s+URL\(\s*([\x27"\x60])([^\x27"\x60]*)\1\s*,\s*import\.meta\.url\s*,?\s*\)$/;
console.log("new URL(`${someVar}`, import.meta.url)".match(NEW_URL_LITERAL));
'
# => matches, capturing content "${someVar}"

The captured content is fed straight into walkLiteral(hereDepth, url[2], dirSegs) (no intervening "can I read this" branch — that branch only exists inside pathExpression()'s resolve/join argument loop, which NEW_URL_LITERAL does not go through). ${someVar} is walked as one ordinary path segment, so:

• new URL(\${someVar}`, import.meta.url)athereDepth = 1currently resolves to depth2` (a normal descent) instead of being rejected as unrecognised.
• A literal like `../../${someVar}` would have its .. segments walked correctly and its interpolation walked as one ordinary segment in the middle — the same "biased upward, can hide an escape" shape finding: check-cross-package-test-inputs counts a template-literal argument as ONE descent, so it is LESS safe than an argument the scan cannot fold #11487 described for PATH_LITERAL, just reached through new URL() instead of join()/resolve().
• With a real fileSegs supplied, the same call can push the literal text ${someVar} onto the roster's segs array (a fabricated NAME), the same risk finding: check-cross-package-test-inputs counts a template-literal argument as ONE descent, so it is LESS safe than an argument the scan cannot fold #11487's Zone 2.3 discussion raised for PATH_LITERAL — there it turned out to be caught by findEscapingPackages()'s downstream statSync(...).isFile() filter; whether that filter also catches this shape was not re-verified here.

Unlike the PATH_LITERAL call site, an unmatched NEW_URL_LITERAL does not fall into an explicit "cannot read, keep depth" branch — pathExpression() just returns undefined for the whole new URL(...) expression (the same outcome as any other unrecognised seed shape, already accepted and self-tested at "does NOT flag a read argument that is an unrecognised expression"). So the fix shape is likely the same narrowing (reject a backtick literal containing ${), but the consequence of matching a template today is not "wrong depth kept" so much as "the whole seed is silently misread instead of being silently unrecognised" — worth its own triage read rather than assuming #11487's exact disposition applies unchanged.

Why this is a finding rather than a defect card

No test in the tree spells a new URL() seed with interpolation today (a search for NEW_URL_LITERAL returns exactly the two lines above), so nothing is currently mis-verdicted — this is a property of the detector, not an outage, same as #11487 was.

Refs: #11487 (the PATH_LITERAL fix this is the sibling of, same file, same character-class shape) · #9763 (the reconstruction that introduced the RESOLVED half and walkLiteral).

---

Generated by Claude Code

[yinlianghui-tw]

Triage: pm:queue + domain:devx, Task, S — lands in scripts/check-cross-package-test-inputs.mjs (gate face). The fix shape is the #11487 narrowing applied to NEW_URL_LITERAL (reject a backtick literal containing ${), with the card's own caveat honored: the unmatched path here falls to "whole seed unrecognised" rather than "depth kept", so the self-test case must pin that outcome, not PATH_LITERAL's.

⛔ Hard serial behind #11487's in-flight PR — same file. Claimant answers fold-or-serial against the five gates if #11487 has not landed by claim time; if it has, re-verify the regex neighborhood on merged main first (the fix may have moved lines or generalized the class).

Size/model suggestion: S, sonnet floor acceptable (mechanical regex + self-test with a worked sibling), opus if the seat prefers.

---

Generated by Claude Code

[yinlianghui]

Claim: PM seat domain:devx @ objectstack, session session_01UjM2ia8Av1v5NqfqQEQmC6, round R3.

field	value
branch	claude/issue-12085-new-url-literal-interpolation
worktree	../objectstack-12085 (dedicated)
domain	domain:devx — landing repo objectstack
file surface	scripts/check-cross-package-test-inputs.mjs
model tier	sonnet — triage's own suggestion, and the worked sibling landed an hour ago.
Clause ②	not triggered. A repo gate's internal detector; strengthening only.

Triage's hard serial is satisfied, and I did the re-verification it asked for

⛔ "Hard serial behind #11487's in-flight PR — same file … if it has [landed], re-verify the regex neighborhood on merged main first (the fix may have moved lines or generalized the class)."

#12087 merged at 08:56Z. So the serial is clear and the fold-or-serial question is moot — this card now runs alone in that file. I re-verified the neighbourhood on merged main = a933ed720 rather than assuming:

557: const PATH_LITERAL = /^(['"`])([^'"`]*)\1$/;
558: const NEW_URL_LITERAL = /^new\s+URL\(\s*(['"`])([^'"`]*)\1\s*,\s*import\.meta\.url\s*,?\s*\)$/;
574: function readablePathLiteral(arg) { … }
662: const url = expr.match(NEW_URL_LITERAL);
663: if (url) return walkLiteral(hereDepth, url[2], dirSegs);
674: const lit = readablePathLiteral(a);

⇒ The class was NOT generalized. #12087's readablePathLiteral() wrapper is deliberately scoped to PATH_LITERAL's single call site — its own docblock says "This is the ONE call site PATH_LITERAL …". NEW_URL_LITERAL's character class is byte-unchanged, and its call site at 662 still hands url[2] straight to walkLiteral() with no readability branch at all. The card's premise holds exactly as filed.

⭐ And the card's caveat — which triage carried forward — is the whole reason this is not a copy-paste. At PATH_LITERAL's site an unreadable argument falls into an explicit "cannot read, keep depth" branch. Here there is no such branch: an unmatched NEW_URL_LITERAL makes pathExpression() return undefined for the whole new URL(...) seed. So the consequence of today's behaviour is "the seed is silently misread", not "the depth is wrong" — and the --self-test case must pin that outcome, not PATH_LITERAL's. Copying #12087's assertion would produce a green test that proves the wrong thing.

Serial constraints. None live — #12087 landed, and nothing in flight touches this file. Fold-or-serial: nothing to fold.

---

Generated by Claude Code