ci: address Copilot feedback on the release workflows

.github/workflows/initialize-edge-app.yml

@@ -27,7 +27,25 @@ permissions:
 run-name: Initializing ${{ inputs.edge_app_name }} in ${{ inputs.environment }}
 
 jobs:
+  # The reusable workflow builds whatever ref this run was started from, so
+  # refuse anything but the default branch rather than initializing an app
+  # (possibly in production) from unreleased code. This fails loudly instead
+  # of skipping, so a run from the wrong branch can't look like a success.
+  verify-ref:
+    name: Verify default branch
+    runs-on: ubuntu-latest
+    steps:
+      - name: Require the default branch
+        env:
+          DEFAULT_BRANCH: ${{ github.event.repository.default_branch }}
+        run: |
+          if [ "$GITHUB_REF" != "refs/heads/$DEFAULT_BRANCH" ]; then
+            echo "::error::Initialize Edge App must be run from $DEFAULT_BRANCH, not $GITHUB_REF_NAME."
+            exit 1
+          fi
+
   initialize:
+    needs: verify-ref
     uses: Screenly/edge-apps-actions/.github/workflows/initialize.yml@v26.10.2
     with:
       environment: ${{ inputs.environment }}

.github/workflows/update-rss-reader-apps.yml

@@ -5,8 +5,9 @@ on:
   push:
     branches:
       - main
+    # Numeric CalVer tags only, matching update-edge-app.yml
     tags:
-      - 'v*'
+      - 'v[0-9]*'
   workflow_dispatch:
     inputs:
       app_key:
@@ -59,22 +60,14 @@ jobs:
         with:
           fetch-depth: 0
 
-      # Same rule as update-edge-app.yml: production only from tags on the default branch.
-      - name: Verify tag is on the default branch
-        if: startsWith(github.ref, 'refs/tags/v')
-        env:
-          DEFAULT_BRANCH: ${{ github.event.repository.default_branch }}
-        run: |
-          git fetch --no-tags origin "$DEFAULT_BRANCH"
-          if ! git merge-base --is-ancestor HEAD FETCH_HEAD; then
-            echo "Tag $GITHUB_REF_NAME is not on $DEFAULT_BRANCH; refusing to deploy to production."
-            exit 1
-          fi
-
+      # Only numeric CalVer tags (v26.11.0) are releases, matching the tag
+      # filter above and update-edge-app.yml. This is the one place that
+      # decides; a manual run on any other ref, including a tag such as vrc1,
+      # stays on stage.
       - name: Set environment
         id: set-env
         run: |
-          if [[ "${{ github.ref }}" == refs/tags/v* ]]; then
+          if [[ "$GITHUB_REF" =~ ^refs/tags/v[0-9] ]]; then
             echo "environment=production" >> "$GITHUB_OUTPUT"
             echo "api_base_url=https://api.screenlyapp.com" >> "$GITHUB_OUTPUT"
             echo "manifest_file_name=screenly.yml" >> "$GITHUB_OUTPUT"
@@ -84,6 +77,18 @@ jobs:
             echo "manifest_file_name=screenly_qc.yml" >> "$GITHUB_OUTPUT"
           fi
 
+      # Same rule as update-edge-app.yml: production only from tags on the default branch.
+      - name: Verify tag is on the default branch
+        if: steps.set-env.outputs.environment == 'production'
+        env:
+          DEFAULT_BRANCH: ${{ github.event.repository.default_branch }}
+        run: |
+          git fetch --no-tags origin "$DEFAULT_BRANCH"
+          if ! git merge-base --is-ancestor HEAD FETCH_HEAD; then
+            echo "Tag $GITHUB_REF_NAME is not on $DEFAULT_BRANCH; refusing to deploy to production."
+            exit 1
+          fi
+
       - name: Setup yq
         uses: ./.github/actions/setup-yq
 

README.md

@@ -48,18 +48,18 @@ screenly edge-app instance create
 
 ### Releasing
 
-Pushes to `main` start a stage deploy, which waits for approval. To release to production, tag a commit on `main` and push the tag (the workflow refuses tags not on `main`); the production deploy also waits for approval:
+Pushes to `main` start a stage deploy, which waits for approval. To release to production, tag a commit on `main` with the next CalVer version (`vYY.MM.N`, e.g. `v26.11.0`; check `git tag --sort=-v:refname | head -1` for the latest) and push the tag. The workflows refuse tags not on `main` and only treat numeric `v[0-9]*` tags as releases; the production deploy also waits for approval. Replace `vYY.MM.N` below with the new version:
 
 ```bash
 git checkout main && git pull
-git tag v26.10.0
-git push origin v26.10.0
+git tag vYY.MM.N
+git push origin vYY.MM.N
 ```
 
 Then publish a GitHub Release whose notes list the pull requests merged since the previous release. Add `--draft` to review the notes before publishing:
 
 ```bash
-gh release create v26.10.0 --verify-tag --generate-notes --title v26.10.0
+gh release create vYY.MM.N --verify-tag --generate-notes --title vYY.MM.N
 ```
 
 ## Configuration