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

[os-steve]

Observed while implementing #11093 (PR #11486); measured on origin/main at 7f30b6be, not reasoned.

The claim the file makes

scripts/check-cross-package-test-inputs.mjs states, twice, that an argument it cannot read costs the NAME and keeps the DEPTH, because the escape verdict is a lower bound:

An argument this scan cannot read leaves the DEPTH walk where it was — deliberately, since the escape verdict is a lower bound and has always been computed this way — but the NAME is gone

and lists a template-literal path among the shapes that yield "NO name — never a wrong one".

What is measured

PATH_LITERAL is /^(['"])([^'"]*)\1$/. A BACKTICK-delimited argument whose content holds no quote characters matches it — which includes an interpolating template such as `${someVar}`. walkLiteral() then treats ${someVar} as an ordinary segment and walks it as one descent.

That is not a lower bound. It biases the walk upward, and it can hide an escape that the documented trade catches. Same climb, same file, only the unreadable middle argument differs:

FLAGGED unreadable argument (documented trade: depth unchanged) -> [{"name":"P","depth":-1}]
NOT SEEN template literal argument (counted as ONE descent) -> []

produced by

const HERE = dirname(fileURLToPath(import.meta.url));
const P = join(HERE, someVar, '../../other-pkg/src/y.ts'); // flagged, depth -1
const P = join(HERE, `${someVar}`, '../../other-pkg/src/y.ts'); // NOT flagged

both at hereDepth = 1, through the exported escapingBindings().

The NAME half is currently harmless in practice but for a reason one level away from the resolver: pathExpression() does hand back segments containing the literal text ${someVar}, and it is findEscapingPackages()'s statSync(...).isFile() filter that drops the resulting roster entry. So "never a wrong name" holds today by a downstream filesystem check, not by the resolver the sentence is written against.

Why this is a finding rather than a defect card

No test in the tree spells a path this way today, so nothing is currently mis-verdicted — this is a property of the detector, not an outage. It is filed because the shape is the exact inverse of the trade the file relies on everywhere else: an unreadable argument is safe, and a template literal reads as readable while being less safe than unreadable.

Two dispositions, for triage rather than a recommendation:

1. Reject an interpolating template in PATH_LITERAL (a backtick literal containing ${), so it falls into the existing unreadable-argument branch — depth held, name dropped. Smallest change; makes the stated lower bound true.
2. Resolve a template whose interpolations are all statically knowable bindings, and reject the rest. Larger, and widens the recognised set, which check-cross-package-test-inputs: a resolve() call whose literal sits on a following line yields no roster name — multi-line new URL() is recognised, multi-line resolve() is not #11093's own scope note argues against doing without a pull.

Either way it wants a --self-test case per the header's own rule.

Refs: #9763 (the reconstruction that added the RESOLVED half and wrote the lower-bound sentence) · #11093 / PR #11486 (the line-spanning spelling, same resolver).

---

Generated by Claude Code

[claude]

Concentrated triage batch: finding → pm:queue, Bug, S (domain:devx stands) — the scan's own stated invariant ("the escape verdict is a lower bound") is violated: PATH_LITERAL matches a backtick template with interpolation, so ${someVar} walks as ONE descent and biases the verdict upward. Fix: make an interpolating template take the documented cannot-read path (no name, depth preserved); pin both directions in the self-test.

---

Generated by Claude Code

[yinlianghui]

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

field	value
branch	claude/issue-11487-template-literal-descent
worktree	../objectstack-11487 (dedicated)
domain	domain:devx — landing repo objectstack
file surface	scripts/check-cross-package-test-inputs.mjs
model tier	sonnet — triage graded S and the fork is already decided, so the expensive judgement is out of this card. dispatch-gates --tier returns no path-derived mandate.
Clause ②	not triggered. A repo gate's internal detector; no published contract accept/reject behaviour moves, no public surface widens. ⚠️ Note the direction: this narrows what the scan treats as readable, i.e. it makes the gate stricter. Strengthening needs no maintainer; weakening would.

Premise re-verified against origin/main = 402113d57, not against the card body (filed 2026-08-23 against 7f30b6be):

557:const PATH_LITERAL = /^(['"`])([^'"`]*)\1$/;
653: const lit = a.match(PATH_LITERAL);

Unchanged, and the character class still excludes only quote characters — so a backtick template with no quotes inside it matches, exactly as the card measured. Positive controls: the file reads at 2250 lines, and a search for an existing interpolation guard returns zero hits, so nothing has been fixed under the card since it was filed.

Serial constraints. No hot-file collision. scripts/check-cross-package-test-inputs.mjs is not in this seat's serial queue and no in-flight claim touches it. ⚠️ One adjacency worth knowing: this gate is a dependency of several other gate derivations (check-ci-filter-parity.mjs derives through it), so a change here can move other gates' family lists — which is why the derived list below is larger than the one file suggests.

Fold-or-serial: not folded with anything. No other queued card in this lane touches this file.

---

Dispatching now with the two dispositions already narrowed to one by triage's grade, and with PATH_LITERAL's second call site (line 653 is one of at least two uses) flagged as the thing to measure before changing the constant.

---

Generated by Claude Code