ci: define and enforce prerelease payload identity

.github/workflows/test.yml

@@ -3,8 +3,15 @@ name: Test pg_ash
 on:
   push:
     branches: [main]
+    tags: ['v*']
   pull_request:
     branches: [main]
+  workflow_dispatch:
+    inputs:
+      release_tag:
+        description: Intended release tag to verify before tagging
+        required: true
+        type: string
 
 # Default to least-privilege; this workflow only runs tests against a service
 # container and needs no write access to repo contents, issues, or PRs.
@@ -20,6 +27,20 @@ jobs:
         with:
           fetch-depth: 0
 
+      - name: Test release stamp checker
+        run: python3 devel/scripts/test_release_stamp.py -v
+
+      - name: Verify release tag matches payload stamp
+        if: >-
+          github.ref_type == 'tag' ||
+          github.event_name == 'workflow_dispatch'
+        env:
+          RELEASE_TAG: >-
+            ${{ github.event_name == 'workflow_dispatch'
+                && inputs.release_tag
+                || github.ref_name }}
+        run: python3 devel/scripts/check_release_stamp.py --tag "$RELEASE_TAG"
+
       - name: Guard SQL release workflow
         if: github.event_name == 'pull_request'
         env:
@@ -10390,6 +10411,8 @@ jobs:
           # 1.3-to-1.4 shim intentionally replays the current installer, so it
           # now jumps directly to 2.0 before the 1.5-to-2.0 wrapper is reached.
           git show v1.5:sql/ash-install.sql > /tmp/ash-v1.5-install.sql
+          python3 devel/scripts/ash_sql_chain.py pinned-upgrade-chain 1.5 \
+            > /tmp/ash-v1.5-upgrade-chain.sql
           psql \
             --no-psqlrc \
             --host=localhost \
@@ -10510,7 +10533,7 @@ jobs:
               'sanity: grant_reader should cover a non-trivial function set';
           end $$;
 
-          \i sql/ash-1.5-to-2.0.sql
+          \i /tmp/ash-v1.5-upgrade-chain.sql
 
           -- Release identity, surface convergence, and persisted state must
           -- all be correct on the first real v1.5-to-current transition.
@@ -10790,9 +10813,9 @@ jobs:
           end $$;
           reset role;
 
-          -- Re-apply the public release wrapper, not merely the installer: the
-          -- documented v1.5-to-2.0 entrypoint promises to be re-apply-safe.
-          \i sql/ash-1.5-to-2.0.sql
+          -- Re-apply the helper-generated public-wrapper + candidate-overlay
+          -- chain: both layers promise to be re-apply-safe.
+          \i /tmp/ash-v1.5-upgrade-chain.sql
 
           do $$
           declare
@@ -10951,6 +10974,8 @@ jobs:
 
           python3 devel/scripts/ash_sql_chain.py full-upgrade-chain > /tmp/ash_full_upgrade_chain.sql
           git show v1.5:sql/ash-install.sql > /tmp/ash-v1.5-install.sql
+          python3 devel/scripts/ash_sql_chain.py pinned-upgrade-chain 1.5 \
+            > /tmp/ash-v1.5-upgrade-chain.sql
 
           # 1) Fresh install → snapshot
           "${psql_base[@]}" \
@@ -10978,17 +11003,18 @@ jobs:
             --command="select ash.uninstall('yes')" \
             > /dev/null 2>&1
 
-          # 3) Actual previous release → current release wrapper → snapshot.
-          # This must remain separate from full-upgrade-chain: historical
-          # installer shims replay the current installer and therefore cannot
-          # prove the final v1.5-to-current edge after a release stamp.
+          # 3) Actual previous release → public wrapper + candidate overlay →
+          # snapshot. This must remain separate from full-upgrade-chain:
+          # historical installer shims replay the current installer and
+          # therefore cannot prove the final v1.5-to-current edge after a
+          # release stamp.
           "${psql_base[@]}" \
             --set=ON_ERROR_STOP=1 \
             --file=/tmp/ash-v1.5-install.sql \
             > /dev/null 2>&1
           "${psql_base[@]}" \
             --set=ON_ERROR_STOP=1 \
-            --file=sql/ash-1.5-to-2.0.sql \
+            --file=/tmp/ash-v1.5-upgrade-chain.sql \
             > /dev/null 2>&1
           "${psql_base[@]}" \
             --set=ON_ERROR_STOP=1 \

CLAUDE.md

@@ -10,11 +10,12 @@ SQL style guide: https://gitlab.com/postgres-ai/rules/-/blob/main/rules/developm
 
 CI via GitHub Actions:
 
-- **test.yml**: runs on push and PRs — tests across PostgreSQL 14, 15, 16, 17, 18, 19 beta
+- **test.yml**: runs on pushes, PRs, and manual pre-tag dispatches — tests
+  across PostgreSQL 14, 15, 16, 17, 18, 19 beta
 - Tests: fresh development install, discovered full upgrade chain up to the in-progress release, schema equivalence between fresh install and upgrade chain, idempotent re-apply of discovered re-apply-safe upgrade scripts, degraded mode (no pgss/pg_cron)
 - Version schema: `vMAJOR.MINOR` (e.g. `v1.3`). Tag on main after all PRs merged.
 
-After a release tag, keep `sql/` frozen at the latest released baseline until the next release-stamp PR. During a development cycle, SQL changes live under `devel/sql/`: the future final installer and the future upgrade script. CI must discover version chains from files via `devel/scripts/ash_sql_chain.py`, not hardcode concrete version numbers. At release stamp time, promote the development installer into `sql/ash-install.sql`, promote the upgrade script into `sql/migrations/`, keep a root-level compatibility wrapper, bump `ash.config.version`, and remove or recreate `devel/sql/` for the next cycle. See `docs/RELEASE_PROCESS.md`.
+After a release tag, keep `sql/` frozen at the latest released baseline until the next release-stamp PR. During a development cycle, SQL changes live under `devel/sql/`: the future final installer and, for a new stable release line, the future cumulative upgrade script. After a prerelease, the discovery helper validates released-chain reachability and same-line payload identity before appending a lone development installer to full, re-apply, and pinned public-wrapper upgrade paths as the current-line overlay; after a final release, a connected development migration is mandatory. CI must discover version chains from files via `devel/scripts/ash_sql_chain.py`, not hardcode concrete version numbers. At release stamp time, promote the development installer into `sql/ash-install.sql`, promote or update the current-line upgrade script under `sql/migrations/`, keep a root-level compatibility wrapper, bump `ash.config.version`, and remove or recreate `devel/sql/` for the next cycle. See `docs/RELEASE_PROCESS.md`.
 
 ## Testing