ci: the install rehearsal needs compose v2, and says so

The v1 fallback I added a commit ago cannot work: deploy/compose/docker-compose.yml
uses v2-only syntax — a top-level `name:` and long-form
`env_file: {path, required}` — so docker-compose 1.29 rejects the file outright
("'name' does not match any of the regexes"). A fallback that always fails is
worse than no fallback, so the script now requires v2 and fails immediately with
what to do about it.

$COMPOSE overrides the detection. gw-04 is deliberately left WITHOUT a
`docker compose` plugin: installing one system-wide would flip the production
rolling deploy (clawmates-deploy.sh prefers v2 when present) off docker-compose
v1 as an invisible side effect of a release change. The runner gets a standalone
v2 binary at /opt/act-runner/bin/docker-compose and the workflow passes it in,
so prod keeps rolling exactly as it did.

Verified on gw-04: standalone v2.32.4 runs, and `docker compose` still resolves
to nothing, so clawmates-deploy.sh takes its v1 branch unchanged.

Co-Authored-By: Claude Opus 5 <[email protected]>

.gitea/workflows/release.yml

@@ -157,7 +157,14 @@ jobs:
           docker tag "clawmates/broker:$VERSION"   clawmates/broker:latest
           # Absolute path: the script cds around, and it needs the binary we
           # already built rather than a cargo this host does not have.
-          CLAWMATES_BUNDLER="$PWD/.tools/clawmates-bundler" ./scripts/rehearse-install.sh
+          # COMPOSE points at a STANDALONE v2 binary. gw-04 intentionally has no
+          # `docker compose` plugin: installing one would switch the production
+          # rolling deploy (clawmates-deploy.sh) off docker-compose v1 as a side
+          # effect. The compose file needs v2 syntax, so the rehearsal gets its
+          # own copy rather than changing what prod rolls with.
+          CLAWMATES_BUNDLER="$PWD/.tools/clawmates-bundler" \
+          COMPOSE=/opt/act-runner/bin/docker-compose \
+            ./scripts/rehearse-install.sh
 
       # Gitea's release API, not softprops/action-gh-release (GitHub-only).
       # Create-or-reuse, so a re-run of the same tag updates instead of 409ing.

scripts/rehearse-install.sh

@@ -10,15 +10,26 @@ set -euo pipefail
 
 ROOT="$(cd "$(dirname "$0")/.." && pwd)"
 
-# Prefer `docker compose` (v2 plugin), fall back to legacy `docker-compose`.
+# Compose v2 is REQUIRED here, and an explicit $COMPOSE wins.
-# Same portability the rolling deploy already needs: gw-04 — where the release
+#
-# job runs — ships only docker-compose 1.29.2, and `docker compose` there fails
+# deploy/compose/docker-compose.yml uses v2-only syntax — a top-level `name:`
-# with "unknown flag: --project-directory", which reads like a bad argument
+# and the long-form `env_file: {path, required}` — so legacy docker-compose
-# rather than a missing plugin. Mirrors deploy/gw-04/clawmates-deploy.sh.
+# 1.29 cannot parse it at all ("'name' does not match any of the regexes"). A
+# v1 fallback would not degrade, it would fail, so there is no point pretending
+# otherwise: say so up front instead of dying twenty lines later.
+#
+# The override exists because the release runner (gw-04) deliberately has NO
+# `docker compose` plugin: installing one system-wide would silently switch the
+# PRODUCTION rolling deploy off docker-compose v1, which is a change nobody
+# asked for. It gets a standalone v2 binary and passes it in instead.
+if [ -z "${COMPOSE:-}" ]; then
   if docker compose version >/dev/null 2>&1; then
     COMPOSE="docker compose"
   else
-  COMPOSE="docker-compose"
+    echo "compose v2 not found. Install it, or set COMPOSE=/path/to/docker-compose (v2)." >&2
+    echo "docker-compose v1 cannot read this compose file — it is not a supported fallback." >&2
+    exit 1
+  fi
 fi
 WORK="$(mktemp -d)"
 export CLAWMATES_HOME="$WORK/opt"