Measured on the first production use of scripts/pm/dispatch-gates.mjs (landed 2026-08-10 in PR #7379, #7341 batch item 4). Filed by the devx PM seat; unassigned.
What happened
The tool derived the gate list for two wave-2 dispatches and printed, among others:
- check:doc-formula-expressions [lint.yml] matched via content/docs/... ⇢ 'content/docs'
Both dispatched devs — independent sessions, different cards, same hour — reported it as nonexistent and substituted a different gate:
The gate does exist. It is package-scoped, not root-scoped:
.github/workflows/lint.yml:1223: run: pnpm --filter @objectstack/lint run check:doc-formula-expressions
A dev searching the root package.json — the obvious place, and the only place the printed name suggests — finds nothing and correctly concludes the name is wrong. Nothing was actually skipped in the end (the gate runs inside the ESLint job, green on both PRs), so this cost credibility rather than coverage. This time.
Why it is the tool's defect, not the devs'
Two independent readers made the identical error within an hour of each other, from the tool's own output. The output drops the --filter <pkg> run prefix the workflow line carries, and the tool otherwise goes out of its way to be honest about provenance (it prints matched via <path> ⇢ <literal> and buckets undiscoverable checks as "repo-wide / undetermined, explicitly not known irrelevant"). The invocation prefix is the one piece of provenance it discards, and it is the piece a dev needs to run the thing.
Suggested fix (not applied)
Print the runnable invocation, not just the script name, sourced from the same workflow line the tool already parses:
- pnpm --filter @objectstack/lint run check:doc-formula-expressions [lint.yml] matched via ...
Root-scoped checks would print pnpm check:<name> unchanged, so the output stays copy-pasteable in both cases and the PM's dispatch line ("Local gates for this card") becomes something a dev can run verbatim. The parse already has the whole run: string — this is a formatting change at the print site, not new discovery logic.
Scope note
Independent of the tool's gate-discovery correctness, which measured fine (76 families across 23 workflow files, no hardcoded list — the #6492 lesson holds). Refs: #7379 (the tool), #7341 (the batch), #7416 / #7417 (the two reports).
No domain:* label applied — routing is the triage seat's single-producer territory.
Measured on the first production use of
scripts/pm/dispatch-gates.mjs(landed 2026-08-10 in PR #7379, #7341 batch item 4). Filed by the devx PM seat; unassigned.What happened
The tool derived the gate list for two wave-2 dispatches and printed, among others:
Both dispatched devs — independent sessions, different cards, same hour — reported it as nonexistent and substituted a different gate:
type: 'form'action leaves the console shell for a bare/forms/:namepage and ends on a generic "Thanks!" panel instead of the created record (observation) #7245's dev (PR docs(ui): state thetype: 'form'action contract — in-shell, submit lands on the record (#7245) #7417): "the card namedcheck:doc-formula-expressions, which does not exist inpackage.json— the nearest existing doc-corpus gate,check:doc-authoring, was run instead"The gate does exist. It is package-scoped, not root-scoped:
A dev searching the root
package.json— the obvious place, and the only place the printed name suggests — finds nothing and correctly concludes the name is wrong. Nothing was actually skipped in the end (the gate runs inside the ESLint job, green on both PRs), so this cost credibility rather than coverage. This time.Why it is the tool's defect, not the devs'
Two independent readers made the identical error within an hour of each other, from the tool's own output. The output drops the
--filter <pkg> runprefix the workflow line carries, and the tool otherwise goes out of its way to be honest about provenance (it printsmatched via <path> ⇢ <literal>and buckets undiscoverable checks as "repo-wide / undetermined, explicitly not known irrelevant"). The invocation prefix is the one piece of provenance it discards, and it is the piece a dev needs to run the thing.Suggested fix (not applied)
Print the runnable invocation, not just the script name, sourced from the same workflow line the tool already parses:
Root-scoped checks would print
pnpm check:<name>unchanged, so the output stays copy-pasteable in both cases and the PM's dispatch line ("Local gates for this card") becomes something a dev can run verbatim. The parse already has the wholerun:string — this is a formatting change at the print site, not new discovery logic.Scope note
Independent of the tool's gate-discovery correctness, which measured fine (76 families across 23 workflow files, no hardcoded list — the #6492 lesson holds). Refs: #7379 (the tool), #7341 (the batch), #7416 / #7417 (the two reports).
No
domain:*label applied — routing is the triage seat's single-producer territory.