Path: none | instrument (scripts/pm/dispatch-gates.mjs --commands, the type-check lanes) | 北极星「优先级」2
Filed by the domain:devx PM seat, session session_017ef78bLdybu3AffehKkhfk, out of PR #19168's red CI lap. The 施工席 named the gap; ⭐ this seat's own measurement sharpens it from「缺口」to「假保证」, which is a different and worse shape.
The defect
scripts/pm/dispatch-gates.mjs --commands is what a dispatch order is built from: it derives the gate families a diff owes. PR #19168 ran all 82 derived families green and was still RED in CI — Type Check · workspace and the required TypeScript Type Check both completed failure, from packages/spec's pnpm run typecheck exiting 2 with two TS7016 errors.
The reason is structural: the four lanes behind the required TypeScript Type Check context are CI jobs running turbo run typecheck / tsc --noEmit -p <config>, and they are in none of the tool's buckets — not the runnable list, not the 11 wide-population families, not the path-scheduled ci.yml jobs, not the Artifact rosters.
⭐ The part that makes it worse than an absence
The tool does emit two typecheck-named commands for a TypeScript-touching path. Measured on 7992d19d5 with the real paths of that PR (2026-09-19T04:53:54Z):
node scripts/pm/dispatch-gates.mjs --commands \
packages/spec/scripts/sharded-artifacts.test.ts scripts/git-env.d.mts
→ 70 commands, of which grep -i 'typecheck|type-check|tsc' matches 2:
pnpm check:type-check-coverage
pnpm check:type-check-debt
⛔ Neither of those is a lane that can fail the way this PR failed. They are check:* gate families; the thing that went red is a per-package tsc program. ⇒ A reader who greps the tool's output for "typecheck" finds something, and can reasonably conclude the type-check surface is accounted for. That is a false reassurance, ⛔ not a silence they could notice.
Control for that reading, from the same invocation: the tool emits 70 node/pnpm commands for those paths, so it is answering about the right population and the 2 hits are a real subset, ⛔ not an empty run.
The rule this cost us, stated so it transfers
⭐ A diff that changes what any TypeScript program can SEE — a new import, a new root-level declaration — owes pnpm --filter <pkg> run typecheck per affected package, independently of dispatch-gates. In PR #19168 the trigger was a single added import line in a .test.ts file; nothing about the isolation work itself was wrong.
⭐ And the pair of statements that must stay apart: 「all N derived families green」 is not 「CI green」. The tool prints its own warning (「Not a complete account of what CI runs on this PR」) and that warning is true — but it does not name which surfaces it cannot see, so a dev cannot turn it into a checklist.
Remedy candidates (⛔ verify before taking any; they are not equivalent)
- Name the uncovered surface. Have the tool print the type-check lanes as an explicit NOT-MEASURED bucket, the way it already does for wide-population and workflow-valued families. Cheapest, and it turns the generic warning into something actionable. ⚠️ This is a claim about what CI runs, so it needs its own source of truth, not a hardcoded list that goes stale.
- Derive them. Read the
typecheck scripts of the affected packages and emit pnpm --filter <pkg> run typecheck as real commands. Strongest, and the most work.
- ⛔ Do not simply rename or drop
check:type-check-coverage / check:type-check-debt to remove the confusion: they are real gates that a diff can owe, and removing them trades one absence for another.
Relationship to the open dispatch-gates family, which this is NOT
#19104 / #19105 / #19106 / #19070 all concern the Artifact-rosters block — a silent verdict that is a fact about a list rather than about the caller's paths. ⛔ Different mechanism: those are families the tool does enumerate and scores misleadingly; this card is about lanes the tool does not enumerate at all, while emitting neighbours whose names read as if it had. Cross-referenced, ⛔ not folded.
Dedupe
525 open non-PR issues enumerated over 6 REST pages (2026-09-19T04:55:26Z). dispatch-gates + typecheck co-occurrence → 0; TypeScript Type Check → 2, both of them PM seat posts (#6026, #6017), neither a card. Must-hit control from the same population: dispatch-gates → 25. ⛔ A zero with no control is not a reading.
Dedupe words: dispatch-gates typecheck lane not enumerated, 82 derived families green not CI green, check:type-check-coverage false reassurance, TS7016 dispatch-gates blind spot.
Generated by Claude Code
Path: none | instrument (
scripts/pm/dispatch-gates.mjs --commands, the type-check lanes) | 北极星「优先级」2Filed by the
domain:devxPM seat, sessionsession_017ef78bLdybu3AffehKkhfk, out of PR #19168's red CI lap. The 施工席 named the gap; ⭐ this seat's own measurement sharpens it from「缺口」to「假保证」, which is a different and worse shape.The defect
scripts/pm/dispatch-gates.mjs --commandsis what a dispatch order is built from: it derives the gate families a diff owes. PR #19168 ran all 82 derived families green and was still RED in CI —Type Check · workspaceand the requiredTypeScript Type Checkbothcompleted failure, frompackages/spec'spnpm run typecheckexiting 2 with twoTS7016errors.The reason is structural: the four lanes behind the required
TypeScript Type Checkcontext are CI jobs runningturbo run typecheck/tsc --noEmit -p <config>, and they are in none of the tool's buckets — not the runnable list, not the 11 wide-population families, not the path-scheduledci.ymljobs, not the Artifact rosters.⭐ The part that makes it worse than an absence
The tool does emit two typecheck-named commands for a TypeScript-touching path. Measured on
7992d19d5with the real paths of that PR (2026-09-19T04:53:54Z):⛔ Neither of those is a lane that can fail the way this PR failed. They are
check:*gate families; the thing that went red is a per-packagetscprogram. ⇒ A reader who greps the tool's output for "typecheck" finds something, and can reasonably conclude the type-check surface is accounted for. That is a false reassurance, ⛔ not a silence they could notice.Control for that reading, from the same invocation: the tool emits 70
node/pnpmcommands for those paths, so it is answering about the right population and the 2 hits are a real subset, ⛔ not an empty run.The rule this cost us, stated so it transfers
⭐ A diff that changes what any TypeScript program can SEE — a new import, a new root-level declaration — owes
pnpm --filter <pkg> run typecheckper affected package, independently ofdispatch-gates. In PR #19168 the trigger was a single added import line in a.test.tsfile; nothing about the isolation work itself was wrong.⭐ And the pair of statements that must stay apart: 「all N derived families green」 is not 「CI green」. The tool prints its own warning (「Not a complete account of what CI runs on this PR」) and that warning is true — but it does not name which surfaces it cannot see, so a dev cannot turn it into a checklist.
Remedy candidates (⛔ verify before taking any; they are not equivalent)
typecheckscripts of the affected packages and emitpnpm --filter <pkg> run typecheckas real commands. Strongest, and the most work.check:type-check-coverage/check:type-check-debtto remove the confusion: they are real gates that a diff can owe, and removing them trades one absence for another.Relationship to the open dispatch-gates family, which this is NOT
#19104 / #19105 / #19106 / #19070 all concern the Artifact-rosters block — a
silentverdict that is a fact about a list rather than about the caller's paths. ⛔ Different mechanism: those are families the tool does enumerate and scores misleadingly; this card is about lanes the tool does not enumerate at all, while emitting neighbours whose names read as if it had. Cross-referenced, ⛔ not folded.Dedupe
525 open non-PR issues enumerated over 6 REST pages (2026-09-19T04:55:26Z).
dispatch-gates+typecheckco-occurrence → 0;TypeScript Type Check→ 2, both of them PM seat posts (#6026, #6017), neither a card. Must-hit control from the same population:dispatch-gates→ 25. ⛔ A zero with no control is not a reading.Dedupe words:
dispatch-gates typecheck lane not enumerated,82 derived families green not CI green,check:type-check-coverage false reassurance,TS7016 dispatch-gates blind spot.Generated by Claude Code