Merge remote-tracking branch 'origin/main' into claude/issue-16752-collectflowgraphs-nonrecord-members

Author: claude

.github/workflows/ci.yml

@@ -4,9 +4,33 @@ on:
   push:
     branches:
       - main
+  # ⭐ NO `branches:` filter here, deliberately (#16482). A `pull_request:`
+  # trigger filtered to `branches: [main]` does not run at all when the PR's
+  # base is a feature branch — and a workflow that does not run publishes NO
+  # check run, which is an ABSENCE, not a skip. Branch protection reads that as
+  # permanently pending, so every required context this file publishes reports
+  # nothing on such a PR. Measured on the #14478 stack: six card PRs showed
+  # 8-11 light checks and ZERO of the six required contexts; the first real
+  # signal arrived at the trunk PR, after every card was written, reviewed and
+  # merged. Correctness rested on local runs quoted into PR bodies — a
+  # discipline, not a gate.
+  #
+  # Runner cost of removing the filter, measured 2026-09-08 over the 30 days
+  # 2026-08-09 → 2026-09-08 (4000 PRs read, `sort=created&direction=desc` paged
+  # until the window closed): 6 of 4000 PRs had a base other than `main`
+  # (0.15%), all six the #14478/#15679 stack. At the window's measured 7008
+  # pull_request runs per workflow, 0.15% is ~10.5 extra runs per workflow per
+  # 30 days ≈ 2.5/week, or ~57 job-runs/week across both files at 23 job-runs
+  # per PR event. Even the pessimistic bound — one uncancelled run per one of
+  # those PRs' 115 commits — is 1.6% of current pull_request spend. Small, so
+  # the trigger is widened unconditionally rather than gated on a label or on
+  # "the base is an open PR's head" (#16482 records the arithmetic).
+  #
+  # ⛔ Do NOT mirror this widening onto the `push:` trigger above. `push:` is
+  # per-branch, not per-PR: unfiltering it would run this workflow on every
+  # push to every agent branch in the repo, which is a different and far larger
+  # population than the 6 PRs measured here.
   pull_request:
-    branches:
-      - main
   # Merge queue: the queue builds each PR as speculatively merged onto the
   # current main and only lands it if this workflow is green on that result —
   # the race-free version of the "pull main and re-verify before merging"

.github/workflows/lint.yml

@@ -4,9 +4,23 @@ on:
   push:
     branches:
       - main
+  # ⭐ NO `branches:` filter here, deliberately (#16482) — see ci.yml's `on:`
+  # block for the full rationale and the measured runner cost; both files carry
+  # required contexts and are widened together, because six contexts split
+  # across two files are only as reachable as the less reachable file.
+  #
+  # ⚠️ The MEASURED 2026-08-25 (#12211) block immediately below does NOT bind
+  # on this widening, and it is not touched by it. Read what it measured: it is
+  # a `merge_group` COVERAGE result — "is there a queue-build gap to close" —
+  # answered NO, plus a ⛔ against adding `merge_group` to the ADVISORY
+  # workflows. It says nothing about the `pull_request:` trigger's `branches:`
+  # filter, and its residual is explicitly named as two repository SETTINGS
+  # (a commit reaching main with no queue build; `strict_required_status_checks
+  # _policy: false`), "neither reachable from this file". Removing a base-branch
+  # filter from `pull_request:` changes no merge_group behaviour whatsoever:
+  # `merge_group:` is a separate trigger key, still present below, and
+  # `check:required-contexts` assertion 6 fails the build if it ever is not.
   pull_request:
-    branches:
-      - main
   # Merge queue (see ci.yml for the full note): required checks must report on
   # queue builds or the queue stalls. This workflow has no PR-only steps, so
   # the trigger alone is enough.

.github/workflows/pr-automation.yml

@@ -1,8 +1,41 @@
 name: PR Automation
 
+# `edited` is load-bearing, not decoration (#16776). The PR BODY is an input to
+# the Check Changeset job below: `check-changeset-no-major.mjs` reads the
+# clause-② declaration out of `github.event.pull_request.body`, and that job
+# refuses a PR whose declaration is unreadable while a changeset grades `patch` a
+# package the diff grew. A verdict whose input is the body has to re-fire when
+# the body changes, for the reason this file already writes out twice for labels:
+# the payload is a SNAPSHOT, and `rerun_failed_jobs` replays that same frozen
+# payload, so without `edited` a red cleared by writing `Clause-②: no` in the
+# body could not be cleared at all without pushing a commit. Manufacturing a
+# `synchronize` to get a body read is not hypothetical -- PR #16342 took a
+# deliberate `git merge origin/main` after a body edit for exactly that, and the
+# run it produced is the first measured pass in that round where the gate read
+# the line.
+#
+# Sibling shape, deliberately copied rather than reinvented: this repo's two
+# other PR-body-scoped blocking checks -- `duplicate-fix-guard.yml` and
+# `partof-closing-keyword-guard.yml` -- already take `edited` and already carry
+# this argument.
+#
+# COST, measured rather than waved at (2026-09-01..09-08, this repo's own run
+# counts through `GET /actions/workflows/<file>/runs?event=pull_request`):
+# a workflow on the DEFAULT types (`check-links.yml`, [opened, synchronize,
+# reopened]) recorded 1967 runs; the two `edited`-subscribed workflows above
+# recorded 2524 each, agreeing exactly. So `edited` is ~557 events / 8 days
+# (~70/day), against this workflow's own 3684 -- about +15%. One Check Changeset
+# job is ~46s (job 101999797457). The two jobs above it are excluded from
+# `edited` below, so that +15% buys exactly one job and not three.
+#
+# NOT filtered to `github.event.changes.body`, and that is deliberate. Such a
+# filter would trim title-only edits, and its failure direction is the defect
+# coming back silently -- an expression that misjudges `changes.body` on an
+# empty previous body stops the gate re-reading and nothing says so. The volume
+# above does not buy that risk.
 on:
   pull_request:
-    types: [opened, synchronize, reopened, labeled, unlabeled]
+    types: [opened, synchronize, reopened, labeled, unlabeled, edited]
 
 jobs:
   # ===========================================================================
@@ -96,7 +129,14 @@ jobs:
     name: Check PR Size
     # A `labeled`/`unlabeled` event cannot change this job's input (the diff),
     # so running it there recomputes the same answer for a fee. See above.
-    if: github.event.action != 'labeled' && github.event.action != 'unlabeled'
+    # `edited` (#16776) is excluded by the SAME sentence and not by a new one: a
+    # title or body edit moves no file either. Excluding it also keeps this job's
+    # behaviour byte-identical to what it was before `edited` was subscribed --
+    # the trigger was added for the changeset job's body reading and buys one job.
+    if: >-
+      github.event.action != 'labeled'
+      && github.event.action != 'unlabeled'
+      && github.event.action != 'edited'
     runs-on: ubuntu-latest
     permissions:
       # `contents: read` is for the checkout the label writer needs. Declaring
@@ -159,10 +199,15 @@ jobs:
     # scans only `needs.*.outputs.*` reads, so this one is out of its scope and
     # has to state its intent by hand.)
     needs: pr-size
+    # `edited` excluded for the same reason as the size job above (#16776): the
+    # path labels are a function of the changed FILES, which a body or title edit
+    # does not move. The `edited` trigger was added for the Check Changeset job's
+    # body reading, and nothing here reads the body.
     if: >-
       !cancelled()
       && github.event.action != 'labeled'
       && github.event.action != 'unlabeled'
+      && github.event.action != 'edited'
     runs-on: ubuntu-latest
     permissions:
       contents: read