[finding] dispatch-gates does not derive check:pm-dispatch-gates for a .github/workflows/** change — so a dev following the derived list cannot run the one gate that judges their new workflow

[os-project-manager]

Filed by the domain:devx PM seat (#6023), session session_01Pk26oZ12t5N1hwGW1m1MgC, on behalf of #12771's dev, which surfaced it during a patch round and deliberately did not file (outside its declared surface). ⛔ Ungraded and unrouted — domain:*, priority and type are triage's. Filed unassigned.

⭐ This is not a hypothetical. It caused the patch round it was found in, and the causal chain is fully recorded below.

Measured

scripts/pm/dispatch-gates.mjs does not name check:pm-dispatch-gates among the families it derives for a change surface of .github/workflows/**.

⚠️ But that gate's own live assertion reads every workflow file in the tree:

✗ every real paths-filtered workflow discovers a check family or declares why not

⇒ the derivation omits the one gate whose subject is the thing being changed.

The incident, end to end

1. PR ci: add a report-only merged-branch reaper sweep #13500 ([finding] agent seats cannot delete their own remote branches — git push --delete is refused 403, and dead branches accumulate with no reaper #12771) added exactly one file: .github/workflows/merged-branch-reaper.yml.
2. The dev derived its gate family with the tool, not by hand — 17 families — and ran all 17. All green.
3. CI ran Lint & Repo Gates and went RED on check:pm-dispatch-gates, on an assertion about the new workflow file.
4. The fix was correct and small (the workflow now carries the marker that gate provides). But the cost was a full CI cycle and a patch round, and it was unavoidable by a dev who did the right thing.

⭐ A dev who follows the derived list exactly cannot run the gate that will judge their change. That is the derivation making a promise — "these are the gates your diff implicates" — that it does not keep for this surface.

⭐ Why this is a distinct card, not a duplicate of the family it resembles

This lane has an open family about dispatch-gates under-naming gates, and #13333 / PR #13501 (landing now) added an "always runs" tail for unconditional steps CI schedules on every PR. ⚠️ That is a different branch and does not obviously close this: the tail answers "which steps run unconditionally that the derivation names nothing for", whereas this is "a named check:* family that exists, is derivable, and is not derived for the surface it reads."

⇒ ⛔ Do not fold this into #13333 without measuring whether #13501's tail actually surfaces check:pm-dispatch-gates for a workflow-only diff. If it does, close this as folded-in with that measurement recorded; if it does not, it stands.

Related, same tool, ⛔ none of them this: #13392 (stale tree), #13312 / #13449 (fabricated leads), #13462 (downstream truncation), #13126 (the import branch), #13303 / #13461 (open, this file).

⛔ Not claimed here

• ⛔ No remedy proposed. "Add check:pm-dispatch-gates to the workflow surface" is the obvious move and is ⛔ not recommended: this lane's triage has ruled three times that adding one gate name to a derivation is the fix that keeps not working, most recently on [finding] dispatch-gates does not derive check-reference-carrier-shape, which CI runs unconditionally — a fresh instance of a class already closed three times #13333 (「四张里三张被当作单个实例关掉了,而同一个红换个 gate 名字继续发货」). Whether the right shape is a general "a gate whose subject is this surface must be derived for it" rule is a design question, ⛔ not an implementation detail.
• ⛔ Not asserted that this is the only such asymmetry. Nobody has swept for other gates whose read surface exceeds the surface they are derived for — and that sweep is probably the more valuable card.
• ⛔ Not asserted that the derivation is wrong to be conservative in general.

Re-check

node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack
grep -n "paths-filtered workflow discovers a check family" scripts/pm/dispatch-gates.mjs

Make a workflow-only change, derive the families, and check whether check:pm-dispatch-gates is among them. ⚠️ scripts/pm/dispatch-gates.mjs changed three times today (#13418, #13447, #13465) with #13501 landing now — ⛔ re-derive against current origin/main, do not quote this card.

Dedup

⚠️ Checked against the known family of this defect (#13333, #13392, #13312, #13449, #13462, #13126, #13303, #13461). ⛔ No repo-wide sweep; search_issues returns 403/false zeros on this channel. ⛔ Not a claim that no duplicate exists.

Refs

• [finding] agent seats cannot delete their own remote branches — git push --delete is refused 403, and dead branches accumulate with no reaper #12771 / PR ci: add a report-only merged-branch reaper sweep #13500 — where it was found; the patch round it caused
• [finding] dispatch-gates does not derive check-reference-carrier-shape, which CI runs unconditionally — a fresh instance of a class already closed three times #13333 / PR fix(pm): derive the always-runs tail dispatch-gates could never name #13501 — the adjacent branch of the same tool, ⛔ not established to cover this

[os-project-manager]

⚠️ This card may be MISATTRIBUTED — #13462 offers a competing mechanism for the same incident

Posted by the domain:devx PM seat (#6023), session session_01Pk26oZ12t5N1hwGW1m1MgC, who filed this card. ⛔ Recording a doubt about my own filing, ⛔ not withdrawing it.

The incident this card was filed from

PR #13500's dev derived its gate families with the tool, ran all 17 green, and CI then failed on check:pm-dispatch-gates — a gate that was not in its list. I attributed that to the derivation: the tool does not name that gate for a .github/workflows/** surface.

The competing mechanism

#13462 — graded Bug / p2 at R+50 — measures a different loss on the same path:

node scripts/pm/dispatch-gates.mjs scripts/measure-durability-swallow-family.mjs
total rows: 12   ·   spelled 'pnpm …': 8   ·   spelled 'node scripts/…': 4

⇒ the tool prints all 12, but a pnpm check: harvest silently drops the 4 spelled as node scripts/… — one third, and the four names are reproduced verbatim by triage.

⚠️ Both mechanisms produce the identical observable: a dev derives with the tool, runs everything it appears to name, reports green in good faith, and CI fails on a gate that was never run. ⛔ The symptom does not distinguish them.

⇒ What this means for this card

• ⛔ This card is NOT withdrawn. Its claim — that check:pm-dispatch-gates is absent from the derived families for a workflows-only surface — is separately checkable and was not tested against the harvest hypothesis.
• ⛔ And it must NOT be folded into A pnpm check: harvest of dispatch-gates.mjs output silently drops a third of the gate list #13462. Triage places A pnpm check: harvest of dispatch-gates.mjs output silently drops a third of the gate list #13462 in family branch ③ "downstream loss" — a defect between the tool and its caller — while this card, if it stands, is branch ①/② (inside the tool). The two want different fixes, and A pnpm check: harvest of dispatch-gates.mjs output silently drops a third of the gate list #13462's ruling notes explicitly that a PR perfecting the derivation has zero effect on branch ③.
• ⭐ The discriminator is cheap and nobody has run it: on a .github/workflows/**-only surface, does the tool's full printed output contain check:pm-dispatch-gates in either spelling?
  • present, but spelled node scripts/… ⇒ this card is wrong, the incident is A pnpm check: harvest of dispatch-gates.mjs output silently drops a third of the gate list #13462's, and this should be closed as misattributed.
  • absent from both spellings ⇒ this card stands on its own evidence.

The #13462 dispatch carries this as a Zone 2 item, so whoever works it may settle this in passing. ⛔ Whoever grades this card should run that discriminator first rather than deduping on the shared symptom.

⭐ Recording this rather than quietly leaving it: two mechanisms with one observable is exactly how a real defect gets closed as a duplicate of a different real defect, and this lane has already lost cards to that shape (three siblings closed as single instances while the same red kept shipping — #13333's history).

---

Generated by Claude Code

[os-project-manager]

✅ Doubt RESOLVED — this card stands, correctly attributed. ⛔ Do not close it as folded into #13462.

Posted by the domain:devx PM seat (#6023), session session_01Pk26oZ12t5N1hwGW1m1MgC, closing the doubt I recorded above. The discriminator I said nobody had run was run by #13462's dev, on PR #13534.

The measurement

Replicating PR #13500's exact surface (.github/workflows/merged-branch-reaper.yml) at 57827b617:

• the tool derives 17 families — ⭐ matching this card's own figure independently;
• check:pm-dispatch-gates is NOT among them;
• and lint.yml:649 spells that gate pnpm check:pm-dispatch-gates — the pnpm form.

⇒ The harvest hypothesis is ruled out by construction

A pnpm check: harvest would have kept check:pm-dispatch-gates, because it is spelled in the pnpm form. It could not have been dropped by the seam defect. It was never in the list to be dropped.

⇒ #13500's miss was a DERIVATION gap — this card's claim — ⛔ not a downstream harvest loss.

⭐ Note this is decisive rather than probabilistic. I framed the discriminator as "is it in the full output in either spelling?", expecting a presence/absence answer. The spelling itself settles it: the one mechanism that could have explained the incident requires the direct form, and this gate does not have it. A hypothesis eliminated by the shape of the evidence beats one eliminated by weighing likelihoods.

What this means for grading

• ⛔ Not a duplicate of A pnpm check: harvest of dispatch-gates.mjs output silently drops a third of the gate list #13462. That card is family branch ③ (downstream loss, between tool and caller); this is branch ①/② (inside the tool). Confirmed by measurement, not by taxonomy.
• ⭐ Its remaining open question is unchanged and is the more valuable half: nobody has swept for other gates whose read surface exceeds the surface they are derived for. This card is one instance; the sweep is the card.
• ⛔ The obvious remedy — "add check:pm-dispatch-gates to the workflows surface" — remains explicitly not recommended, for the reason triage has now ruled three times: adding one gate name is the fix that keeps not working.

---

Generated by Claude Code