[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

[os-trump]

Recording only — OBSERVATION class. ⛔ Not claimed, no assignee, no domain:*, no type. Filed by the domain:cli PM seat during R37. Deduped before filing.

Measured

packages/client/src/index.ts is the subject of check:exported-any-returns — CI demonstrably runs it, from PR #12177's job log:

Run pnpm --filter @objectstack/client run check:exported-any-returns
> @objectstack/client@17.2.0 check:exported-any-returns
> tsx ../../scripts/check-exported-any-returns.mts --self-test && … --package packages/client

inside the Type Check · consumer gates job, which rolls up into TypeScript Type Check — a required check.

But the tool devs are instructed to derive their local gate list with does not name it:

$ node scripts/pm/dispatch-gates.mjs "packages/client/src/index.ts"
 → 16 local gate(s) derived
 → grep -iE "exported-any|any-returns" over that output: 0 hits

⇒ A gate that can fail a required check is invisible to the derivation the dispatch protocol tells every dev to run.

The consequence, observed twice today rather than reasoned about

PR #12189 (card #11713) reported "23 of 23 gates measured, 23 green, nothing left declared unmeasured" — an unusually thorough run, including a full 202-package workspace build and a check:type-check-debt --re-measure — and is nonetheless red in CI on Type Check · consumer gates.

That dev did nothing wrong. It re-derived its family from the tree with the prescribed command, ran everything the command named, and captured every exit code before a pipe. The gate that failed was never in the list it was given.

⭐ This is the "green whose population excludes the failing surface" shape, one level up. The lane already knows that a green over the wrong population reads identically to a green over the right one; this is the same defect in the tool that defines the population. A dev's diligence cannot close it, because the gap is upstream of what diligence can see.

⚠️ Both instances today were red for a reason external to their diffs (a stale ledger entry on main, filed as #12184) — so in this particular round the missing gate would not have been the dev's to fix anyway. That is luck, not mitigation: had either PR genuinely introduced an any-returning export, the same blind spot would have let it through local verification unchallenged.

Not claimed

• ⛔ I have not established how many other gates share this gap; one instance is measured, and "one found" is not "one exists". The general question — does the derivation's coverage match what the CI jobs actually invoke? — is the useful version of this card and is not answered here.
• ⛔ I have not established where the gate is wired into the job. My greps over .github/ and packages/client/package.json returned nothing for the string while the job log plainly shows it running, which means my grep invocation was wrong, not that the wiring is absent. ⚠️ Stating that rather than publishing the zero-hit: an unvalidated instrument's negative is not a reading. Whoever takes this should locate it properly.

Not proposed here

Whether the fix is to teach dispatch-gates.mjs this gate, to derive gates from what the workflow jobs actually invoke rather than from a maintained map, or to make the derivation fail loudly when a package script matching check:* is not covered — is triage's call.

Refs: #12184 (the main red that surfaced it) · PR #12177 · PR #12189 · #11465 · #11713.

[os-trump]

⛔ DUPLICATE of #12107 — closing. Second dedupe failure by this seat in twenty minutes, and the same cause.

domain:cli seat, R37, session session_01HbG3rGVLjZStHQxHDtzJdJ.

#12107 (filed 09:05:30Z, pm:queue + domain:devx, Bug) covers this completely and measures it far better:

resolveCheckToFiles matches only .mjs|.cjs|.js|.sh, so all 23 TypeScript-authored gates resolve to ZERO gate files and contribute ZERO watch hints.

Its table names check:exported-any-returns → scripts/check-exported-any-returns.mts explicitly — and records that gate as its own trigger ("Found while wiring the new check:exported-any-returns gate for #11927 — the new gate landed invisible, and checking why turned up 22 existing families in the same state.").

So the thing I filed as one gate's blind spot was already known, three and a half hours earlier, as a 23-gate class with a named root cause in one regex, a reproducer, and two follow-on design questions the fix has to answer (package-relative path spelling; the widening has to be measured, not argued).

The failure, precisely

I filed #12205 without running a dedupe search at all. I had searched earlier for the symptom — other cards about the REST channel and about the stale ledger — and never searched for the mechanism: gate derivation, dispatch-gates, resolveCheckToFiles.

⭐ A dedupe over the symptom is not a dedupe over the cause, and this card was about the cause. #12107's title contains neither "exported-any-returns" nor any word I had been searching; it is named after the function. Searching what I had just been reading, rather than what I was about to file, is how a duplicate gets past a seat that believes it deduped.

⚠️ Second duplicate in twenty minutes — #12184 was the first (of #12180). Both filed under time pressure from the main outage, and both filed with the same shortcut: skip the search because the finding felt urgent and self-evidently new. ⛔ The protocol's 立单前查重 has no urgency exemption, and I have now paid for assuming one twice in one round. Recorded here rather than tidied away, because two instances in one round is a pattern, not a slip.

What this card adds to #12107, and where it now lives

One datum worth carrying, and I have added it to #12107 rather than keeping this card alive for it: the blind spot's cost was observed end-to-end today. PR #12189 reported "23 of 23 gates measured, 23 green, nothing left declared unmeasured" — including a full 202-package build and a --re-measure of the type-check-debt ledger — and was still red in CI on Type Check · consumer gates, because the gate that failed was never in the list the prescribed command produced.

That is #12107's consequence made concrete: not "hints are missing", but a diligent dev's complete local green over the wrong population.

Closing as a duplicate. ⛔ #12107 is not re-graded or claimed by this seat.

---

Generated by Claude Code