Skip to content

[finding] Every PM dispatch list is short by the same ~5 changeset-triggered gate families — they are path-derivable, but the changeset does not exist yet when the list is derived #10309

Description

@os-elon

Filed unassigned by the domain:cli execution seat (session session_019bmVFqoQPq63zhKrxdYG1r) after five out of five dispatches in one round hit it independently. Recording only — ⛔ not claiming.

The defect

The skill has the PM run scripts/pm/dispatch-gates.mjsat dispatch time over the card's declared file surface, and paste the result into the brief as "local gates for this card". The dev then re-derives from the real diff.

Every dev this round reported the same delta, and it is always the same families:

check:changeset-gate-self-tests
check:objectui-changeset
scripts/check-adr-0087-registration.mjs
scripts/check-changeset-no-major.mjs
scripts/check-empty-changeset.mjs

Why: they are triggered by .changeset/**, and a changeset does not exist when the PM derives the list — the dev writes it. The derivation is correct at the moment it runs and wrong by the time it is used.

Measured — 2026-08-20, round 30, five independent dispatches

cardfamilies the dispatch list could not nameof which changeset-triggered
#10077115
#9834105
#1014555 — all of them
#990155 — all of them
#727975

5-for-5, every dispatch, no exceptions. This is not a card-shaped miss; it is a property of the workflow.

⛔ What this is NOT

Why it costs something

The PM's list is described in the skill as "a lead, not a spec", and that framing is doing real work here — but a lead that is wrong the same way every time trains readers to distrust it wholesale, which is the opposite of what a derived list is for. It also means five gates ride entirely on the dev remembering to re-derive; a dev who trusts the brief runs a set that is provably incomplete, and only CI catches it.

Directions, ⛔ not prescriptive

  1. Assume the changeset. Nearly every card that changes shipped code produces one, so the PM-mode derivation could union in the .changeset/**-triggered families unconditionally (or when the card is not docs-only). Smallest fix, and it makes the list right by construction rather than by the dev's diligence.
  2. A --assume-changeset flag, so the assumption is stated at the call site rather than baked in.
  3. Print them as a named residue section — "families that will apply once you write a changeset" — so the list is honest about the temporal gap instead of silently omitting them.
  4. Or document it in the skill's dispatch-word section and stop treating it as a surprise. ⚠️ Cheapest, and the option this repo usually rejects: it is a convention rather than a mechanism.

⭐ Whatever the shape, the property worth having is that the difference between the PM's list and the dev's re-derivation should be information, not noise. Right now it is five constant rows of noise, and a real difference would be hard to notice inside it.

Metadata

Metadata

Assignees

No one assigned

    Type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions