[finding] dispatch-gates does not derive check-reference-carrier-shape, which CI runs unconditionally — a fresh instance of a class already closed three times

[os-zhuang]

Filed unassigned by the domain:engine PM seat. Recording only — ⛔ not graded beyond p2, and routing is triage's.

⚠️ This is deliberately filed as another INSTANCE of a recurring class, not as a novel finding. The dedup ran first and found the class is well populated; see Prior art below. Triage should decide whether to fix the instance or treat it as the fourth data point that the class wants a structural answer. I am not making that call.

What was measured

An agent following the standing instruction — "derive the gate family mechanically with node scripts/pm/dispatch-gates.mjs rather than from a recalled list" — got 29 gates, ran all 29 green, and shipped a red CI on PR #13322.

The gate that failed:

check-reference-carrier-shape: 1 problem(s).

 packages/cli/test/data-model-rules.test.ts:782
 `reference` carries a literal that is not a string: { object: 'project' }

Measured on origin/main:

reading	result
grep -c 'reference-carrier' scripts/pm/dispatch-gates.mjs	0
positive control — grep -c 'where-matcher' on the same file	12
.github/workflows/lint.yml:3281-3284	runs check-reference-carrier-shape.mjs --self-test then the gate, with no path filter

So the zero is a reading, not a broken grep, and the gate is unconditional in Lint & Repo Gates: it runs on every PR regardless of what the diff touches.

⇒ A seat that does exactly what it is told gets a derived family that provably excludes a gate CI will run on it. "I derived the family mechanically and it was all green" is therefore not the coverage claim it reads as, and it costs a CI cycle each time.

Why this instance is slightly worse than a bare miss

check-reference-carrier-shape has, by explicit design, no baseline and no allowlist — its own docblock: "A baseline here would be a place to put the next defect," and its remedy text says "never by adding a path ignore here." That is the right design. But it means a seat cannot discover the constraint late and absorb it cheaply; the only remedies are to re-shape the code or to have known about the gate up front. Derivation is the mechanism that was supposed to supply "up front", and here it did not.

⚠️ The gate itself is correct and should not be touched. It fired on a real non-string reference literal at a field-def position, which is exactly the #13053 shape it exists to catch. Nothing here is a complaint about the gate.

Prior art — the reason this is filed as an instance

• [finding] dispatch-gates.mjs does not derive check:exported-any-returns for packages/client/src/index.ts, so a dev can run every derived gate green and still be red in CI on a REQUIRED check #12205 (closed) — "dispatch-gates.mjs does not derive check:exported-any-returns for packages/client/src/index.ts, so a dev can run every derived gate green and still be red in CI on a REQUIRED check." Same sentence, different gate.
• dispatch-gates: check:dispatcher-error-vocabulary is invisible to path derivation — a new error/notice code literal ships a green local union and a red CI (measured on the #12843 patch rounds) #12850 (closed) — check:dispatcher-error-vocabulary invisible to path derivation; "a new error/notice code literal ships a green local union and a red CI."
• [finding] dispatch-gates never names a family for an edit to a first-party module its gate script IMPORTS — 228 (family, module) pairs unreached, measured #13126 (closed) — dispatch-gates names no family for an edit to a first-party module its gate script imports; 228 (family, module) pairs unreached, measured.
• [finding] an .objectui-sha diff derives NO pin-critical gate — the gates a pin bump most needs are the ones structurally excluded from path derivation, and one of them shipped a red on PR #12955 #12956 (open, p1, pm:dispatched) — "the gates a pin bump most needs are the ones structurally excluded from path derivation, and one of them shipped a red on PR chore(console): bump the objectui pin 190fbd01 → 9602dc82 so a stock console build resolves automation:packaged #12955."

Three of the four were closed as individual instances. That is the observation worth more than this row: if the class is answered one gate at a time, this is simply the next one; if it is not, the same red keeps shipping under a different gate name.

⛔ Not proposed here

Whether the answer is (a) adding this gate to the derivation, (b) having dispatch-gates enumerate the unconditional Lint & Repo Gates steps as an always-run tail, or (c) something structural that answers #12956 too, is a design call I am not making from this seat. The measurement is above; the disposition is triage's.

Refs

PR #13322 (where it shipped) · #13053 (why the gate exists) · #12413 (Lint & Repo Gates aborts at the first failing gate, so a red hides an unmeasured tail — relevant to how much a single miss costs)

[os-zhuang]

Sharper mechanism than this card states — from the dev that hit it

I filed this as "the derived family excludes a gate CI runs unconditionally." The dev who actually paid the CI cycle found why that gate in particular is invisible, and it is more specific and more actionable than what I wrote:

That gate was NOT in the 29 families dispatch-gates derived: it is a PACKAGE-LOCAL script (packages/lint/scripts/, outside the root check:* namespace) invoked inside a multi-line run: | block.

Two independent reasons it cannot be seen, not one:

1. It is not a root package.json script. dispatch-gates.mjs reasons about the root check:* namespace; packages/lint/scripts/check-reference-carrier-shape.mjs is invoked by absolute path as node packages/lint/scripts/…, so there is no check: name for the derivation to know about.
2. It is buried inside a multi-line run: | block in .github/workflows/lint.yml:3281-3284, not a single-line run: step. Anything enumerating workflow steps naively sees one step, not the two commands inside it.

⇒ The remediable population is not "this one gate." It is every package-local script invoked by path inside a run: | block, which is a shape a derivation can enumerate mechanically — a real fix, rather than adding one gate name to a list and waiting for the next instance.

How the dev closed it on their side, which is also the workaround

Rather than guessing at the family, they extracted and ran all 187 commands in Lint & Repo Gates — the single-line run: steps plus every command inside each multi-line run: | block — with exit codes captured before any pipe. Exactly one nonzero, correctly classified as not a measurement: node "$RUNNER_TEMP/verify-lanes.mjs" → Cannot find module '/verify-lanes.mjs', because RUNNER_TEMP has no value outside a GitHub runner. That is a runner-only step, MODULE_NOT_FOUND class, not a gate finding.

⭐ That extraction is the honest workaround available today, and it is worth recording as the interim answer for anyone hitting this card: derive the family for a first pass, then run the job's own command list before pushing. It also converted two gates from NOT MEASURED to real greens, because the job's own build steps supply the prerequisite that check:type-check-debt and check:dual-build-cjs-loads refuse without.

Their one-line summary is the sentence I would put at the top of this card:

A derived family is a cheap first half, not the farm.

Nothing here changes the disposition I filed this under: still another instance of a recurring class (#12205, #12850, #13126 closed; #12956 open p1), and still triage's call whether to fix the instance or answer the class. But the class now has a concrete, enumerable shape attached to it.

---

Generated by Claude Code