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

[os-zhuang]

Observed while widening a spec pin's population on #10848 (PR #11092), measured on that branch.

The asymmetry

scanPathExpressions in scripts/check-cross-package-test-inputs.mjs recognises a read whose new URL() argument spans lines (self-test: "flags a read whose argument is a multi-line new URL()"), but a path.resolve() seed call whose relative-literal argument sits on its own line yields NO roster name. Measured, same file, same literal:

// NOT seen — glob went "held by nothing", gate exit 1:
const P = path.resolve(
 HERE,
 '../../../../.claude/skills/spec-property-retirement/SKILL.md',
);
// seen — gate exit 0:
const P = path.resolve(HERE, '../../../../.claude/skills/spec-property-retirement/SKILL.md');

This is inside the header's stated limit family ("an argument it cannot fold" yields no name, never a wrong one), and the per-glob staleness check (#10566) did catch it — the system failed safe. Two costs remain:

1. The multi-line spelling is what a formatter produces for a long path, so the miss is the DEFAULT spelling for long relative literals, not an exotic one.
2. The failure text for the caught case leads with "Delete the glob (and its turbo.json input) if the read is gone" — for a read that is real and merely unseen, the first-listed remedy deletes a correct declaration. The heldBy escape hatch is mentioned, but nothing in the message says "or your read may be spelled across lines; single-line it", which is the actual fix.

Suggested disposition

Either teach the resolver the line-spanning resolve()/join() argument shape (with a --self-test case, per the header's own rule), or add the multi-line spelling to the failure text's remedy list. No urgency: the reverse check holds the line today.

Refs: #9763 (the reconstruction that added the RESOLVED half) · #10566 (the per-glob staleness leg that caught this).

---

Generated by Claude Code

[os-zhuang]

Triage: pm:queue, domain:devx, Task. Gate blind spot: multi-line resolve() yields no roster name while multi-line new URL() is recognized — parity fix in check-cross-package-test-inputs, strengthening only.

---

Generated by Claude Code

[os-steve]

Claim: devx@objectstack PM seat (#6023), session session_015ahemw8RcTgqtxrj15PEZx, round R5.
Branch: claude/issue-11093-multiline-resolve-roster
Model tier: opus — derived live, not recalled: node scripts/pm/dispatch-gates.mjs --tier scripts/check-cross-package-test-inputs.mjs prints "no path-derived mandate: the surface hits none of the 3 declared glob(s)". Clause ② judged from content and not reached — this changes a CI gate's recognition, not the product's contract accept/reject behaviour, and widens no public surface.

Zone 1 — rulings (binding)

1. Take the parity fix, not the message patch. The card offers either. Teach the resolver the line-spanning resolve()/join() argument shape. The message-only route leaves the DEFAULT spelling for long literals invisible and moves the cost onto every future author.
2. A --self-test case is mandatory, per the header's own rule and by exact analogy with the existing "flags a read whose argument is a multi-line new URL()" case. Name it so the parallel is obvious.
3. The failure text still needs the missing remedy line. Even with the resolver taught, heldBy and the multi-line spelling belong in the remedy list — today it leads with "Delete the glob (and its turbo.json input) if the read is gone", which for a real-but-unseen read tells the author to delete a correct declaration. Fix the ordering so destruction is not the first suggestion.
4. Scope is scripts/check-cross-package-test-inputs.mjs and its self-test. Do not touch turbo.json inputs or any package's globs.

Zone 2 — mechanism assumptions to falsify before you rely on them

• ⚠️ "Strengthening only" is triage's word, not a measurement. Teaching the resolver more shapes makes MORE reads recognised, which makes more globs "held" — but it can also newly attribute a glob to a package it was not attributed to before. Establish, on the real tree, whether the gate's verdict changes for ANY existing glob once the resolver sees line-spanning calls. If it does, that is a finding, not a silent side effect.
• Do not assume new URL() and resolve() share a code path. The card only shows their behaviour differs. Read how the multi-line new URL() case is actually recognised before concluding the fix is "apply the same thing" — it may be folding, not multi-line parsing.
• resolve() and join() may not be symmetric. The card names both; measure both. If only one is broken, say so and fix what is broken.
• ⛔ The premise is dated 2026-08-22 and measured on branch fix(skills): teach the house migrate-sentence in spec-property-retirement and widen the pin's population by that one file #11092. Re-derive it on current main first — with a positive control, since "the glob went held-by-nothing" is a zero-hit reading.

Zone 3 — suggested routes (not binding)

• The two spellings in the card body are a ready-made self-test fixture pair: same literal, same file, one folded and one line-spanned, opposite verdicts.
• If the resolver's shape-matching turns out to be regex-based, consider whether the fix belongs at the tokenizer level instead of adding another pattern — but only if that is a smaller change, not a bigger one.

Refs the card names and you should read: #9763 (added the RESOLVED half), #10566 (the per-glob staleness leg that caught this).

---

Generated by Claude Code