1.5.4: the text follows the rename, and a check keeps it that way

Kristian read the readme and found it still telling people to configure the
plugin under WooCommerce, for a page that moved to the Nolimit menu three
releases ago. Sweeping for it found seven stale places, and three of them are
notices THE PLUGIN SHOWS THE USER — the missing-WooCommerce notice, the
activation error and the incomplete-install warning all still called it
WooCommerce Email Discount Manager.

That is the mimir.guide failure exactly: the code moved, the text stood still,
and nothing failed. It was found by somebody reading, which is the only way it
could be found, and that is the argument for the check rather than for being
more careful next time.

ci/static.sh now asserts two things. The name in readme.txt's title matches the
Plugin Name header, because the header is what WordPress shows and everything
else has to agree with it. And no shipped PHP file contains OLD_PLUGIN_NAME,
which is now a value in ci/plugin.conf rather than a habit.

The changelog is deliberately exempt: an entry describes what was true for that
release, and rewriting it would be a different lie. Only text describing the
CURRENT state is checked.

Both halves proven red — a readme title that disagrees, and the old name put
back into one notice.

Not changed: the page stays under Nolimit rather than gaining a second entry
under WooCommerce. One menu is the family's shape, and a duplicate entry is
clutter rather than a fix for a readme that was simply wrong.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

ci/lib.sh

@@ -22,7 +22,7 @@ ci_load_conf() {
   # leaves the floors empty, every comparison becomes a no-op, and the hollow
   # checks these were added to fix come back silently — the same shape of bug.
   local missing=
-  for var in PLUGIN_SLUG PLUGIN_MAIN TEXT_DOMAIN NEEDS_WOOCOMMERCE MIN_SHIPPED_PHP_FILES MIN_TRANSLATION_CALLS RELEASE_REPO WPMGR_MENU_SHA; do
+  for var in PLUGIN_SLUG PLUGIN_MAIN TEXT_DOMAIN NEEDS_WOOCOMMERCE MIN_SHIPPED_PHP_FILES MIN_TRANSLATION_CALLS RELEASE_REPO WPMGR_MENU_SHA OLD_PLUGIN_NAME; do
     [ -n "${!var:-}" ] || missing="$missing $var"
   done
   if [ -n "$missing" ]; then

ci/plugin.conf

@@ -92,3 +92,8 @@ RELEASE_REPO=kw/nolimit-discounts-dist
 # string with. Verified here against seven hostile inputs.
 # Earlier frozen hashes: 184cebdc = 1.1.0, f4862d5c = 1.0.0.
 WPMGR_MENU_SHA=471b0a2aab47b6b7f8d839ac8b12d60637bbe2c07df86f7e40089c677fbab3cc
+
+# The name this plugin used before the Nolimit rename. Kept so ci/static.sh
+# can fail when it reappears in text a user reads — a sentence that goes stale
+# breaks nothing by itself, which is why it survives.
+OLD_PLUGIN_NAME="WooCommerce Email Discount Manager"

ci/static.sh

@@ -141,6 +141,37 @@ else
   echo "  $checked plugin-relative include(s) checked"
 fi
 
+readme=
+for f in readme.txt README.txt; do [ -f "$f" ] && readme=$f && break; done
+
+ci_step "the plugin is called the same thing everywhere"
+# 🔴 The rename moved the code and left the text behind: the readme still told
+# people to look under WooCommerce for a page that had moved to the Nolimit
+# menu, and three notices the PLUGIN SHOWS THE USER still used the old name.
+# Kristian found it by reading the readme, which is the only reason it was
+# found at all — nothing fails when a sentence goes stale.
+#
+# Same failure as a privacy page standing still while the code moves. The name
+# in the header is the one WordPress shows, so it is the one everything else
+# has to agree with.
+header_name=$(ci_plugin_header 'Plugin Name')
+echo "  header:  $header_name"
+readme_name=$(sed -n -E 's/^=== (.+) ===$/\1/p' "$readme" 2>/dev/null | head -1)
+echo "  $readme: $readme_name"
+[ "$header_name" = "$readme_name" ] \
+  || note_fail "The plugin header says '$header_name' but $readme says '$readme_name'."
+
+# Old names in text a user reads. The changelog is exempt: an entry describes
+# what was true for that release, and rewriting it would be a different lie.
+stale=$(./ci/dist-files.sh | grep -E '\.php$' \
+  | xargs grep -nF "$OLD_PLUGIN_NAME" 2>/dev/null || true)
+if [ -n "$stale" ]; then
+  printf '%s\n' "$stale" | sed 's/^/    /'
+  note_fail "The old plugin name '$OLD_PLUGIN_NAME' is still in shipped code."
+else
+  echo "  no shipped file still says '$OLD_PLUGIN_NAME'"
+fi
+
 ci_step "one version, stated once"
 # WordPress compares the update feed against the header and nothing else, so a
 # constant or a readme that disagrees with it is how a release ends up either
@@ -323,8 +354,7 @@ behind() { # claimed current -> true when claimed is the older of the two
 # plugin header, so checking the header for it reports "missing" on a plugin
 # that states it correctly. "WC tested up to" is the opposite: WooCommerce
 # reads that one from the plugin header and nowhere else.
-readme=
-for f in readme.txt README.txt; do [ -f "$f" ] && readme=$f && break; done
+
 
 tested_wp=
 [ -n "$readme" ] && tested_wp=$(sed -n -E 's/^Tested up to:[[:space:]]*([^[:space:]]+).*/\1/p' "$readme" | head -1)