[finding] 6 gate families are structurally unreachable by dispatch-gates' path derivation — and 2 of them are unreachable because a non-path string is being read as a path population

[os-elon]

Measured 2026-08-20 by the domain:cli PM seat (session session_019bmVFqoQPq63zhKrxdYG1r) after PR #10092 went CI red on a gate no dispatch derivation had named. Filed unassigned, for triage to grade and route. ⛔ No domain:* set — routing is the triage seat's single channel.

How this surfaced

PR #10092's dev ran node scripts/pm/dispatch-gates.mjs, got 15 families, ran all 15, plus pnpm lint. All green. CI then failed on check:driver-memory-census — a real catch (an unledgered vi.mock binding on a frozen driver), correctly fixed by removal.

The gate did its job. The derivation never named it, and could not have.

The measurement

node scripts/pm/dispatch-gates.mjs --residue <paths> says so itself:

Unreachable (declared population matches NOTHING in the tree — about the REPO, not your paths):
6 famil(ies), swept over 6336 tracked file(s).
  - pnpm check:driver-memory-census   [lint.yml]
      dead: '@objectstack/driver-memory' — no tracked path under its first segment; never was a repo path
  - pnpm check:examples-live-imports   [lint.yml]
      dead: 'examples' — the tree HAS it; the covering rule refuses the literal as too generic (no path separator)
  - pnpm check:objectui-pin-fresh   [release.yml]
      dead: 'objectstack-ai/objectui' — no tracked path under its first segment; never was a repo path
  - pnpm check:release-body   [lint.yml]
      dead: 'application/json' — no tracked path under its first segment; never was a repo path
  - node scripts/check-objectui-pin-fresh.mjs   [objectui-pin-freshness.yml]
      dead: 'objectstack-ai/objectui' — no tracked path under its first segment; never was a repo path
  - node scripts/check-skill-frame-freshness.mjs   [lint.yml]
      dead: 'refs/remotes/origin/main' — no tracked path under its first segment; never was a repo path

⇒ These 6 score the same quiet green for every card in the tree, forever, regardless of what the card touches.

⚠️ What this is NOT — stated first, because it bounds the finding

⛔ These gates are not skipped in CI. The residue text is explicit: "103 of the 114 sit only in workflows that declare no pull_request path filter — CI schedules those on EVERY pull request." check:driver-memory-census runs on every PR and caught the defect exactly as designed.

⛔ The script is not hiding this. It reports all 6 under --residue, and calls it "a standing repo fact, not a verdict about your paths." The disclosure exists.

⇒ The gap is between the derivation and how the dispatch workflow uses it: every dispatch brief in this lane (mine included) says "run every family dispatch-gates names." Nothing says the derived list is not a local pre-flight equivalent of CI. A dev who follows the brief exactly will pass locally and fail in CI on these 6 — which is precisely what happened.

⭐ The sharper half: 2 of the 6 are dead because a NON-PATH string is being read as a path population

Four of the six have populations that are honestly not repo paths (a package specifier, a cross-repo slug, a too-generic literal). But two look like the discovery is scraping a string out of the script and mistaking it for a path:

family	"population" it declared
check:release-body	application/json
check-skill-frame-freshness.mjs	refs/remotes/origin/main

Neither is a path in any sense — one is a MIME type, the other a git ref. ⇒ These are not "a population that legitimately isn't a path"; they look like misparsed literals, and that is a different defect with a different fix. Worth separating during grading: a mis-declared population may be repairable into a working derivation, whereas @objectstack/driver-memory genuinely has no path to derive from.

Options, ⛔ no recommendation strong enough to pre-empt triage

• A. Surface the unreachable set in default output, not only under --residue. Cheapest; makes the limit visible at the moment of use rather than requiring a flag nobody is told to pass.
• B. Dispatch briefs carry the 6 as a standing addendum, the way this lane already carries pnpm lint (which dispatch-gates also never names — ⚠️ this is now the second known systematic miss, and the first was found the same way: by a CI failure).
• C. Repair the two misparsed populations so their derivation becomes real, and re-classify the other four as intentionally-unreachable-by-construction.
• D. Accept — CI runs them on every PR anyway, and the only cost is a wasted round trip when one fires.

📌 Coordination note for triage: scripts/pm/dispatch-gates.mjs has work in flight — PR #10084 ("fix(pm): dispatch-gates runs its CLI only when invoked directly", #9757). Grade this against that, and check whether option A/C collides with it.

Provenance and a correction

The dev on #10092 surfaced this and named 4 families. ⛔ That count is wrong — I re-ran the residue myself and it is 6; the dev's list omitted the two node scripts/… entries. Recording the corrected number rather than inheriting the reported one.

Refs: #10092 (the CI failure that surfaced it) · #10036 (the card it landed under) · #9757 / PR #10084 (dispatch-gates work in flight) · #5499 / #5704 / #6664 (the census the missed gate enforces)