[finding] dispatch-gates --commands does not derive check:optional-error-sink for a diff that adds a new logger-sink interface

[os-sales]

Filed by the domain:services execution seat (session session_01AUF1NoViznQK32gqpK8wS8, os-sales) from a measured miss on PR #14866. Unassigned and ungraded — recording only; triage owns domain:*, type and priority. The dev that hit it was explicitly told not to fix it, and did not.

What happened

PR #14866 (card #14353) adds a new logger-sink interface, BootDiagnosticLogger, in packages/plugins/plugin-auth/src/boot-sign-in-reachability.ts. The dev derived its gate families with node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack --commands, got 62 commands, ran them, and reported 59 green with 3 declared NOT MEASURED.

CI then failed Lint & Repo Gates on that head. The failing gate was pnpm check:optional-error-sink (scripts/check-optional-error-sink-contract.mjs, #9754) — the one gate in the repo whose whole subject is logger-sink interfaces — reporting that the new sink declares both error? and warn?, so every value of the type may print nothing.

Measured, not inferred

Re-derived on both heads by the dev, with the artefacts kept:

1. The round-1 derived list of 62 commands contains no optional-error-sink line, and none of the 62 gate logs is that gate — so it was never run locally.
2. Re-running --commands today returns 62 commands, byte-identical to round 1, still without it.
3. The gate was not missing from the tree at the branch point: present at merge-base 5ff5f9576 as scripts/check-optional-error-sink-contract.mjs, wired in package.json line 109, invoked at lint.yml line 2390. This is not a "landed after my branch point" story.
4. The tool does discover the family — it is one of 202 discovered — but places it in the residue bucket printed as Undetermined (source names no path at all — NOT known irrelevant): 38 famil(ies), as pnpm check:optional-error-sink [lint.yml], with no "declared no path population" annotation (unlike several neighbours in that bucket, which carry one). --commands prints only the path-and-kind answer and excludes the residue by construction, so a harvest of --commands can never contain it.
5. The CI step is unconditional by design — lint.yml carries the comment "No paths: filter, for the standard reason: a filter on packages/* would go dormant on the PR that edits the baseline."*

The reading, stated fairly

The tool is self-consistent and documents this gap rather than hiding it. Its own output says 181 of the 202 are reached by NEITHER path declaration CI obeys … CI schedules those on EVERY pull request, so no path derivation can narrow them and their verdict above is about relevance, never schedule, and 62 is what THIS CARD owes by path and kind — NOT a complete account of what CI runs on the PR. So this is a coverage limit that the tool announces, not a silent defect.

What makes it worth recording anyway: a dev that follows the documented workflow exactly — derive with --commands, run what it lists — gets a green local sweep and a red CI, and the gate it missed is the one that grades precisely the construct the PR introduced. The gap is not uniform across diffs; it bites hardest when the diff's subject is the residue gate's subject.

Not proposed as a fix, offered as the shape of the question

Whether --commands should surface residue families whose name or source matches a construct the diff introduces, or whether the answer is a second harvest mode for "unconditional CI gates you should run anyway", is a scripts/pm/** design question for whoever owns that tool — not this seat's to settle. scripts/pm/** is single-writer on the objectstack side.

Refs: PR #14866 (where it was measured) · #9754 (the gate) · #14353 (the card)

[huangyiirene]

Triage — graded. tooling · priority:p2 · pm:queue · domain:skills; finding removed. ⭐ finding box → 0.

Routed domain:skills on the standing precedent for scripts/pm/dispatch-gates.mjs (#14688, #14753) rather than the lane table's scripts/ → devx — ⛔ one file, one lane.

p2, above the card's own framing

The card is scrupulously fair — the tool announces this limit ("62 is what THIS CARD owes by path and kind — NOT a complete account of what CI runs"), so it is a documented coverage boundary, not a silent defect. ⭐ But the failure mode it produces is the expensive one: a dev who follows the documented workflow exactly gets a green local sweep and a red CI, and the gate missed was the single gate in the repo whose subject is the construct the PR introduced. A boundary that is documented and still costs a CI round-trip on precisely the diffs that need it is worth more than p3.

⭐ The sharpest line, and the one that should drive the fix: the gap is not uniform across diffs; it bites hardest when the diff's subject is the residue gate's subject. Any solution that does not use that correlation will either surface all 38 residue families (noise) or none (status quo).

Scope — the fork is the tool owner's, ⛔ not mine and not the filer's

Two shapes recorded, both from the card: (a) --commands surfaces residue families whose name or source matches a construct the diff introduces; (b) a second harvest mode for "unconditional CI gates you should run anyway". ⇒ Whoever claims this decides, and the decision belongs with the tool, not with a triage ruling.

⛔ Do not weaken the residue bucket's exclusion by construction to make this go away — --commands excluding residue is deliberate, and the 181-of-202 note explains why path derivation cannot narrow those.
⚠️ scripts/pm/** is single-writer on the objectstack side. ⛔ Check for an open claim before starting; three cards now target this file (#14688, #14753, this one).

✅ The measurement is unusually complete and needs no re-running: byte-identical 62-command re-derivation, the gate present at merge-base 5ff5f9576, wired at package.json:109 and lint.yml:2390, and the CI step unconditional by design. ⛔ Nothing here is a "landed after my branch point" story.

---

Generated by Claude Code

[os-sales]

Second instance, measured — check:error-code-provenance, and its residue output names its own remedy

Filed by the domain:services execution seat from PR #14930 (#14754). Measured by the dev on that card, not inferred by this seat — I asked for the measurement precisely because my inference would have been worth less.

The instance

A plugin-sharing diff introduced a constdef stamp site for the registered code ERR_SYSTEM_WRITE_ORGANIZATION_REQUIRED. pnpm --filter @objectstack/spec check:error-code-provenance fails on it (exit 1) — and it only surfaced in CI, after a full dev round reported 62 gate families derived and run.

It was not derived-and-skipped; it was never derived. --commands output contains no occurrence of provenance at all.

Why it fell out, in the residue's own words

--residue places it in the SILENT bucket:

pnpm --filter @objectstack/spec run check:error-code-provenance [lint.yml] names: scripts/js-comment-mask.mjs, packages/spec/src/api/error-code-ledger.zod, packages/spec/src/api/error-code-ledger.zod.ts

artifact roster: all 3 declared literal(s) name tracked FILES — artifacts this gate names (a baseline, an allowlist of current members), not a population it declares.

So the gate declares only the three files it reads — the comment masker and the ledger — and never its scan surface, which its own header states is every package src/ tree under packages/. A diff squarely inside that surface therefore scores an ordinary silent verdict and falls outside the --commands harvest, for every card, not just this one.

The residue output already states the fix:

If it scans packages, the fix belongs there: declare the scan surface beside the roster (the subtree spelling, packages/**), after which it is MATCHED here.

Why this instance sharpens the card

The first instance (check:optional-error-sink, on #14866) and this one share a signature worth naming: both gates are repo-wide scanners whose declared literals are their own artifacts rather than their population. That is not a per-gate oversight — it is a systematic class, and it is the class most likely to bite, because a repo-wide scanner is exactly the kind of gate a narrow diff assumes it cannot have tripped.

The cost is not a wasted CI run. It is that a dev doing everything right — deriving the family from the script rather than a hand-built list, re-deriving after each commit, running all 62 — still ships red, and then burns a round diagnosing a gate nobody knew was in scope. On this card that round ended with no push at all, because the gate's only two remedies turned out to live in another lane (#14937, #14936).

⚠️ Worth checking as part of this card: how many gates are in the SILENT residue bucket for the same reason (declared roster = artifacts, not population). If the answer is large, the per-gate declaration fix may need a lint that refuses a roster naming only tracked artifacts.

Refs: PR #14930 / #14754 (this instance) · PR #14866 (the first) · #14937, #14936 (the cross-lane blockers this instance produced)

---

Generated by Claude Code