[finding] dispatch-gates reads a package-root-anchored literal as repo-root-anchored, so real paths are reported as dead leads (check:generated names three)

[claude]

Found while repairing #13518 (PR #14207), out of that card's scope and deliberately not fixed there.

The defect

extractWatchHints resolves a path literal against exactly ONE anchor: the writer's own directory, and only when the author spelled it with a ./ or ../ prefix. A literal with no such prefix is taken as REPO-ROOT anchored, verbatim.

Gate scripts that live inside a package routinely use a third anchor -- a package-root binding:

const PKG_DIR = resolve(fileURLToPath(new URL('.', import.meta.url)), '..');
// ... then, against that binding:
resolve(PKG_DIR, 'api-surface') // means packages/spec/api-surface
resolve(PKG_DIR, 'src/index.ts') // means packages/spec/src/index.ts

The extractor reads those literals as api-surface and src/index.ts -- at the REPO root, where nothing of the sort exists. They are then reported as dead leads.

Measured (on 987fe370)

node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack --residue packages/spec/src/index.ts

check:generated prints, among its dead leads:

• src/meta-spelling/meta-url-data.generated.ts -- "no tracked path under its first segment; never was a repo path"
• api-surface -- same
• export-origins -- same

All three are alive under packages/spec/. The reason text is also wrong in a way worth naming: it says the literal never was a repo path, when in fact it is a real path under a base the resolver did not apply.

Why this is not what PR #14207 fixed

That PR closes a different edge -- a gate that re-derives from a package's exports map inherits that package's source. check:generated reads the manifest for its scripts map, not its exports map, so it correctly does NOT follow that edge. Its under-matching has this separate cause, and folding it in would have meant loosening a narrowing that is doing real work (it withdraws 1678 fabricated pairs).

Not claimed here

• No remedy prescribed. In particular it is NOT obvious that resolving these against the package root is safe: moduleRelativeDirectoryHint's docblock already prices a naive widening of the resolved form at +53 hints of which only 1 was a true lead, and the bare-word refusal is worth +139084 pairs. Any repair here has to be measured against those.
• The blast radius is unmeasured. check:generated is one confirmed instance found incidentally; the population of gate scripts using a package-root binding was not swept.

---

Generated by Claude Code

[huangyiirene]

Triage (R+89, triage seat, session session_019kDRpB7D2XzVzkaLp57T5D): pm:queue · priority:p3 · domain:devx · tooling · type Bug.

Lands in: scripts/pm/dispatch-gates.mjs — extractWatchHints' anchor resolution and the dead-lead reason text. Measure-first, as the card says: step one is the population of gate scripts that bind a package root (resolve(fileURLToPath(…), '..')-shaped) and the hint delta a package-root anchor would add, priced against the two figures moduleRelativeDirectoryHint's docblock already records (+53 hints / 1 true lead for the naive resolved form; +139084 pairs for bare words). Repair only if the delta survives that pricing; otherwise the deliverable is the corrected reason text alone ("a real path under a base the resolver did not apply", never "never was a repo path") plus the measurement on the card. p3: the mis-reporting under-matches (a dead-lead label on a live path), which costs a dev a look, not a missed gate.

⚠️ Hot file: #14289 and #14290 (same file, same audit) — the devx seat answers fold-or-serial once for the three; this one is the only behaviour change of the three.

Size/model suggestion: M (measurement is the work), opus.

---

Generated by Claude Code