ci(branch-policy): allow hotfix and release branches into main

The policy accepted only `staging` as a head for main, so any change
production needed before the next promotion had nowhere to go: the PR was
unmergeable by CI and branch protection blocks direct pushes.

Accept `hotfix/*` and `release/*` heads as well. The naming requirement
keeps a direct-to-main change deliberate and visible, and the master
freeze plus the "features target staging" rule are unchanged. Document
the escape hatch and the need to land the same commit on staging.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

.github/workflows/verify.yml

@@ -24,9 +24,14 @@ jobs:
             echo "master is frozen; target staging or main" >&2
             exit 1
           fi
-          if [ "$BASE_BRANCH" = "main" ] && [ "$HEAD_BRANCH" != "staging" ]; then
+          if [ "$BASE_BRANCH" = "main" ]; then
-            echo "Only staging may be promoted to main" >&2
+            case "$HEAD_BRANCH" in
-            exit 1
+              staging|hotfix/*|release/*) ;;
+              *)
+                echo "main takes staging promotions, or a hotfix/* or release/* branch for direct work" >&2
+                exit 1
+                ;;
+            esac
           fi
           if [ "$BASE_BRANCH" != "staging" ] && [ "$BASE_BRANCH" != "main" ]; then
             echo "Feature pull requests target staging; promotions target main" >&2

docs/operations/backend-deployments.md

@@ -14,10 +14,14 @@ not deploy the retired Supabase data plane.
 | `master` | frozen legacy default | none | none |
 
 Normal feature pull requests target `staging`. After CI and authenticated staging
-acceptance pass, open a promotion pull request from `staging` to `main`. Do not
+acceptance pass, open a promotion pull request from `staging` to `main`. Prefer
-add production-only commits to `main`: production should run the exact commit
+that route: production then runs the exact commit already exercised in staging.
-already exercised in staging. Direct pushes to either deployment branch are for
+
-explicit incident recovery only.
+When production needs a change that cannot wait for the next promotion, open a
+pull request into `main` from a `hotfix/*` or `release/*` branch. CI enforces
+that naming so a direct-to-main change is always deliberate and visible. Land
+the same commit on `staging` too, or the next promotion will revert it. Direct
+pushes to either deployment branch remain blocked by branch protection.
 
 Each Dokploy Compose application is connected to `jjbrunton/Sauci`, watches its
 single branch with push-triggered automatic deployment, and uses