diff --git a/.github/workflows/package-version-guard.yml b/.github/workflows/package-version-guard.yml
index 9c493ec886..78a35b64f0 100644
--- a/.github/workflows/package-version-guard.yml
+++ b/.github/workflows/package-version-guard.yml
@@ -17,7 +17,11 @@ name: Package Version Guard
 on:
   pull_request:
     branches: [ main ]
-    types: [opened, synchronize, reopened, ready_for_review]
+    # `edited` catches base-branch retargeting — see the note in
+    # pr-base-freshness.yml. A stacked PR retargeted to main after its parent
+    # merges enters this guard's population without any event in the list
+    # below ever firing for it.
+    types: [opened, synchronize, reopened, ready_for_review, edited]
 
 permissions:
   contents: read
diff --git a/.github/workflows/pr-base-freshness.yml b/.github/workflows/pr-base-freshness.yml
index 655f8136ee..3273fa6f86 100644
--- a/.github/workflows/pr-base-freshness.yml
+++ b/.github/workflows/pr-base-freshness.yml
@@ -20,7 +20,16 @@ name: PR Base Freshness
 on:
   pull_request:
     branches: [ main ]
-    types: [opened, synchronize, reopened]
+    # `edited` is load-bearing, not tidiness. This guard is deliberately
+    # scoped to base=main (see tests.yml) — a stacked PR's base freshness is
+    # meaningless while it targets a feature branch. But when its parent
+    # merges, GitHub RETARGETS the child to main, and that is the exact moment
+    # the stale-base footgun applies. Retargeting fires `edited`, never
+    # `synchronize`, so without this the child crosses into the guard's
+    # population and is never inspected: it arrives already-passing on a check
+    # set it was never subject to. Cost is a re-run on title/body edits too —
+    # one fetch and a merge-base, seconds.
+    types: [opened, synchronize, reopened, edited]
 
 permissions:
   contents: read