diff --git a/.github/workflows/ci.yml b/.github/workflows/ci.yml
index 25a27f1..01a290b 100644
--- a/.github/workflows/ci.yml
+++ b/.github/workflows/ci.yml
@@ -8,6 +8,16 @@ on:
   push:
     branches: [master]
   pull_request:
+# CAT_TOOLS_GIT_REF is the Makefile's opt-in override (see its comment there)
+# to install cat_tools from a git ref instead of PGXN, for exactly this CI --
+# PGXN's published cat_tools is stuck at a stale 2017 release missing the
+# function extension_drop's SQL calls. Set at workflow level (not per-job) so
+# every job that builds/installs the extension, including ones in other
+# stacked PRs, picks it up automatically without its own copy of this value.
+# Revert this once cat_tools 0.3.0 is actually published to PGXN -- see
+# RELEASE.md's guardrail against cutting a release while this is still set.
+env:
+  CAT_TOOLS_GIT_REF: 0.3.0
 jobs:
   # Style linter (https://github.com/Postgres-Extensions/linter, vendored at
   # .vendor/linter). Deliberately checked out WITHOUT submodules -- `make
diff --git a/META.in.json b/META.in.json
index 71aa541..d7c8cdb 100644
--- a/META.in.json
+++ b/META.in.json
@@ -73,13 +73,13 @@
     "X_comment": "Valid keys for 'prereqs' are configure, build, runtime, or test.",
     "X_comment": "Valid keys for 'requires' are requires, recommends, suggests, or conflicts.",
     "X_comment": "Requires event_triggers, introduced in 9.3",
-    "X_comment": "cat_tools: requires extension support, added in 0.2.1",
+    "X_comment": "cat_tools: requires cat_tools.routine__parse_arg_types_text, added in 0.3.0",
     "prereqs": {
 
         "build": {
             "requires": {
                 "PostgreSQL": "9.3.0",
-                "cat_tools": "0.2.1"
+                "cat_tools": "0.3.0"
             }
         },
         "runtime": {
diff --git a/META.json b/META.json
index ba237c7..70608a2 100644
--- a/META.json
+++ b/META.json
@@ -73,13 +73,13 @@
     "X_comment": "Valid keys for 'prereqs' are configure, build, runtime, or test.",
     "X_comment": "Valid keys for 'requires' are requires, recommends, suggests, or conflicts.",
     "X_comment": "Requires event_triggers, introduced in 9.3",
-    "X_comment": "cat_tools: requires extension support, added in 0.2.1",
+    "X_comment": "cat_tools: requires cat_tools.routine__parse_arg_types_text, added in 0.3.0",
     "prereqs": {
 
         "build": {
             "requires": {
                 "PostgreSQL": "9.3.0",
-                "cat_tools": "0.2.1"
+                "cat_tools": "0.3.0"
             }
         },
         "runtime": {
diff --git a/RELEASE.md b/RELEASE.md
index c93afd7..92b4fb4 100644
--- a/RELEASE.md
+++ b/RELEASE.md
@@ -34,13 +34,35 @@ Keep the next release ready to cut at any time:
 This way, a release is just renaming things — see step 2 below — not writing
 a changelog or an upgrade path from scratch under time pressure.
 
+## Critical: never cut a release while CI needs a git-source dependency override
+
+The `Makefile`'s `cat_tools` target normally does a plain `pgxn install` — but
+CI currently sets `CAT_TOOLS_GIT_REF` (see `.github/workflows/ci.yml`'s
+top-level `env:`) to build cat_tools from a git ref instead, because PGXN's
+published cat_tools doesn't yet have the version this distribution actually
+requires. While that's true, `META.in.json`'s declared `cat_tools` floor
+isn't actually satisfiable via `pgxn install` — cutting a release in that
+state produces a real, publishable zip that can't actually be built by
+anyone who downloads it from PGXN.
+
+**Before starting step 1 below**, check whether `ci.yml` still sets
+`CAT_TOOLS_GIT_REF` (or `CAT_TOOLS_SKIP_INSTALL`) to a non-empty value. If it
+does, stop — wait for the real dependency version to land on PGXN (and
+revert `ci.yml`'s override back to unset) before proceeding. Checking
+`ci.yml`'s actual value is the real signal here, not whether the Makefile
+*declares* the variable — `CAT_TOOLS_GIT_REF` always exists in the Makefile
+now, as a normally-empty, opt-in override; its mere existence doesn't mean
+anything is pinned.
+
 ## Cutting a release
 
 1. Make sure `master` is in the state you want released, and CI is green.
    **Caveat:** as of this writing, CI passing doesn't actually mean the test
    suite passed — see "CI doesn't fail on test failures" below. Until that's
    fixed, also eyeball the actual `pg_regress` output in the CI logs (or run
-   `make test` locally), not just the green checkmark.
+   `make test` locally), not just the green checkmark. **Also check for a
+   dependency override** — see "Critical: never cut a release while CI needs
+   a git-source dependency override" above — before proceeding.
 
 2. Rename the accumulated `STABLE` markers to the real version number:
    - Edit `META.in.json`: bump the top-level `version` field AND the matching