[finding] The shared workspace-enumerator consolidation is blocked on dispatch-gates following first-party imports — today it would DELETE the population declarations it is meant to centralise

[os-zhuang]

Measured while fixing #10542 (PR #11189), which landed the per-gate half and deliberately deferred this one. Filed unassigned; not fixed there.

What #10542 proposed

That card's closing section observed that twelve scripts each carry their own pnpm-workspace.yaml parser, several admitting it in a comment ("Minimal pnpm-workspace.yaml block parsers (same approach as …)"), and that two of them once carried byte-identical 11-entry WORKSPACE_PARENT_DIRS arrays with the same blind spot in both. It concluded that a shared enumerator — the shape scripts/i18n-bundle-surface.mjs already sets — "would make the population declarable in one place instead of twelve, which is the same refactor as the fix rather than a separate one".

Why it is not the same refactor, measured

Under the current derivation it is the opposite of a fix, and the mechanism is two functions in scripts/pm/dispatch-gates.mjs:

• resolveCheckToFiles extracts script paths from the npm script's command string (/(scripts\/[\w./-]+\.(?:mjs|cjs|js|sh))/g over scriptsMap[checkName]);
• discoverFamilies then scans exactly those files for watch hints.

A module a gate imports is never opened. So a population declaration moved out of a gate and into a shared enumerator stops contributing hints to every gate that imports it. Concretely, that would silently undo:

• check:test-source-alias and check:type-source-resolution, whose WORKSPACE_PARENT_GLOBS arrays (finding: dispatch-gates cannot name check:test-source-alias — the trigger is a NEW cross-package import inside a test, which no path literal describes #9955 / PR fix(gates): declare the workspace parents as globs, so dispatch-gates can read the whole declared population #10540) are the reason they name all four of [finding] 7 of 119 gate families enumerate the workspace at RUNTIME from pnpm-workspace.yaml, so they carry no population literal and dispatch-gates can never name them for any package #10542's layout specimens today;
• check:published-files, whose declaration PR fix(pm): declare the runtime-enumerated gate populations dispatch-gates could never name (#10542) #11189 just added on exactly the same pattern.

All three would go back to naming no card in the tree, with every gate still green and nothing in the output saying so — the same invisible failure #10542 exists to retire, reintroduced by the tidy-up meant to prevent it.

PR #11189 pins this as an assertion rather than leaving it as prose: dispatch-gates' self-test now asserts that a family's hints are exactly those of the scripts its command names, so a later author measures the constraint instead of trusting a paragraph.

What the work actually is, in order

1. Teach the derivation to follow first-party imports (one level, scripts/-relative, no node_modules). This is the enabling change and it is the one with a fabrication budget to measure: hintCovers' docblock prices bare-top-level-word admission at +139084 (gate, file) pairs, and following imports is a different and probably far smaller widening — but it has never been measured, and the measurement is the deliverable, not the guess. Sweep the (gate, file) pair count and the per-family matched counts before and after, the way [finding] dispatch-gates never names check:doc-anchors for a content/** card — its population root 'content' is not "pathy" #9626 and fix(gates): declare the workspace parents as globs, so dispatch-gates can read the whole declared population #10540 did.
2. Only then consolidate the twelve parsers, moving each gate's population declaration into the shared module, and confirm on the same sweep that no family loses coverage.

Doing 2 without 1 is a regression with no red gate.

The duplication itself, for whoever picks this up

Fifteen discovered families read pnpm-workspace.yaml at runtime (re-measured on main at 137 discovered families — #10542's figure of twelve was taken when the farm was 119). scripts/i18n-bundle-surface.mjs is the shape the consolidation should take.

Adjacent, noticed in the same sweep and NOT part of the above

check:cross-package-test-inputs is discovered as two families — check:cross-package-test-inputs from lint.yml and the direct scripts/check-cross-package-test-inputs.mjs from ci.yml — because extractCheckInvocations keys a pnpm check:x invocation and a node scripts/check-x.mjs invocation separately. Anything keyed by family name therefore reaches only one of the pair: PR #11189's CHANGE_KIND_GATES entry rescues the check: spelling and leaves the direct one unrescued. This is a discovery-keying question, not a population one, and is recorded here rather than folded into either card above.

Related

#10542 (the parent finding, closed by PR #11189), #10540 / #9955 (the declarations this would delete), #9626 (why hintCovers refuses bare literals, with the +139084 measurement), #10114 (the merged precedent for declaring a population).

[os-zhuang]

First-touch (triage): promoted pm:queue, domain:devx, Task — the card already carries the ordered two-step shape with the load-bearing constraint pinned in dispatch-gates' self-test. Dispatch constraints: step 1 (follow first-party imports, one level, scripts/-relative) is measurement-first — the before/after (gate, file) pair count and per-family matched counts ARE the deliverable, per the #9626/#10540 precedent; step 2 (consolidate the twelve parsers) only after step 1's sweep confirms no family loses coverage. ⛔ Doing 2 without 1 is a regression with no red gate — the card's own words, now a dispatch condition. The adjacent discovery-keying observation (check:cross-package-test-inputs as two families) stays out of scope; it is recorded on #11199, which is in this lane's finding pool separately.

---

Generated by Claude Code