@@ -57,7 +57,7 @@ jobs:
         uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1  # v7.0.1
         with:
           repository: CryptOS-PKI/cryptos-web
-          ref: ${{ vars.WEB_RELEASE_REF || 'main' }}
+          ref: main
           path: web
 
       - name: 🛠️ Set up Docker Buildx
 
@@ -1,7 +1,8 @@
 name: "🚀 Release image"
 
-# A v* tag publishes the manager image and its Helm chart: build from the
-# pinned web ref, prove the image with the read-only health check, then push
+# A v* tag publishes the manager image and its Helm chart: build with the
+# web console from cryptos-web's tag of the same name (the two repos are
+# versioned in lockstep), prove the image with the read-only health check, then push
 # only if that check passes. `latest` moves only on a stable tag (no "-"
 # prerelease suffix); an rc tag publishes its own tag but never latest. The
 # chart version always matches the tag (without its leading "v"). The node
@@ -29,29 +30,32 @@ jobs:
       NET: fleet-release-check
       REGISTRY_IMAGE: ghcr.io/cryptos-pki/cryptos-manager
     steps:
-      # A tagged image has to be rebuildable from the tag. Falling back to
-      # web's main would embed whatever web happened to be at build time, so
-      # the release refuses to build until the web ref is pinned.
-      - name: Require a pinned web ref
+      # cryptos-manager and cryptos-web are versioned in lockstep: the image
+      # for vX.Y.Z embeds the web console from cryptos-web's vX.Y.Z. That
+      # release has to be published first; the releases/tags endpoint only
+      # returns published releases, so a draft or a missing tag fails here.
+      - name: Require the matching cryptos-web release
         env:
-          WEB_RELEASE_REF: ${{ vars.WEB_RELEASE_REF }}
+          GH_TOKEN: ${{ github.token }}
+          TAG: ${{ github.ref_name }}
         run: |
-          if [ -z "$WEB_RELEASE_REF" ]; then
-            echo "::error::Set the WEB_RELEASE_REF repository variable to a web tag or commit SHA before cutting a release."
+          set -euo pipefail
+          if ! draft="$(gh api "repos/CryptOS-PKI/cryptos-web/releases/tags/$TAG" -q .draft 2>/dev/null)" || [ "$draft" != "false" ]; then
+            echo "::error::cryptos-web has no published release at $TAG. The two repos are versioned in lockstep: publish cryptos-web's $TAG draft first (with the same version), then re-run this workflow."
             exit 1
           fi
-          echo "web ref: $WEB_RELEASE_REF"
+          echo "web release: $TAG"
 
       - name: Checkout manager
         uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1  # v7.0.1
         with:
           path: manager
 
-      - name: Checkout web (pinned)
+      - name: Checkout web (same tag)
         uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1  # v7.0.1
         with:
           repository: CryptOS-PKI/cryptos-web
-          ref: ${{ vars.WEB_RELEASE_REF }}
+          ref: refs/tags/${{ github.ref_name }}
           path: web
 
       # Resolve what is actually being built, so the image can report it (#81).
 
@@ -12,7 +12,18 @@ name: Release Drafter
 on:
   push:
     branches: [main]
+  # cryptos-manager and cryptos-web are versioned in lockstep, but each repo
+  # resolves its next version from its own labels, so the two drafts can come
+  # out different. Dispatching with a version (no leading "v", e.g.
+  # 0.1.0-rc.2) sets this repo's draft to it. Both drafts must carry the same
+  # version before either is published; the merge freeze keeps a later push
+  # from resolving it again.
   workflow_dispatch:
+    inputs:
+      version:
+        description: "Draft this version instead of the one resolved from labels (no leading v, e.g. 0.1.0-rc.2)"
+        required: false
+        default: ""
 
 permissions:
   contents: read
@@ -44,3 +55,4 @@ jobs:
           first-version: 0.1.0
           prerelease: true
           prerelease-identifier: rc
+          version: ${{ inputs.version }}
@@ -348,13 +348,17 @@ After a stacked pull request is retargeted onto `main`, CI starts on its next pu
 
 ## 📦 Releasing
 
-Nothing tags automatically. On push to `main`, release-drafter categorises the merged conventional-commit PRs into the draft release notes. The maintainer then publishes the GitHub Release by hand, which creates the `vX.Y.Z` tag. That tag triggers `job-release-image.yaml`, which builds the container image from the pinned web ref with BuildKit, runs it read-only against the health check, and — only once that passes — pushes `ghcr.io/cryptos-pki/cryptos-manager:vX.Y.Z` and packages and pushes the chart to `oci://ghcr.io/cryptos-pki/charts/fleet-manager` at the same version. `latest` moves only on a stable tag (no `-` prerelease suffix); an rc publishes its own tag but never `latest`. Neither push carries any provenance, SBOM or other attestation. The node ISO ships from [`cryptos-appliance`](https://github.com/CryptOS-PKI/cryptos-appliance), source only. Adopters who want something other than the published image or chart build and push their own from the tagged source (see [*Building the image yourself*](#building-the-image-yourself)). (The repo's own release/governance tooling — release-drafter, golic — is the maintainer's; adopters don't need it.)
+Nothing tags automatically. On push to `main`, release-drafter categorises the merged conventional-commit PRs into the draft release notes. The maintainer then publishes the GitHub Release by hand, which creates the `vX.Y.Z` tag. That tag triggers `job-release-image.yaml`, which builds the container image with BuildKit, with the web console from `cryptos-web`'s tag of the same name, runs it read-only against the health check, and — only once that passes — pushes `ghcr.io/cryptos-pki/cryptos-manager:vX.Y.Z` and packages and pushes the chart to `oci://ghcr.io/cryptos-pki/charts/fleet-manager` at the same version. `latest` moves only on a stable tag (no `-` prerelease suffix); an rc publishes its own tag but never `latest`. Neither push carries any provenance, SBOM or other attestation. The node ISO ships from [`cryptos-appliance`](https://github.com/CryptOS-PKI/cryptos-appliance), source only. Adopters who want something other than the published image or chart build and push their own from the tagged source (see [*Building the image yourself*](#building-the-image-yourself)). (The repo's own release/governance tooling — release-drafter, golic — is the maintainer's; adopters don't need it.)
 
 The release image is meant to be rebuildable from its tag. Every base image in the
 `Dockerfile` is pinned by digest, the build date is the tagged commit's time rather than
-the clock, and the release refuses to build until the `WEB_RELEASE_REF` repository
-variable pins the `web` checkout to a tag or commit (falling back to `web`'s `main` would
-embed whatever was there that day). A pull request that touches the image runs
+the clock, and the `web` checkout is `cryptos-web`'s tag of the same name. The two repos are
+versioned in lockstep: `vX.Y.Z` of the manager embeds `vX.Y.Z` of the web console, so
+`cryptos-web`'s release is published first, and the image workflow fails with a clear error
+when `cryptos-web` has no published release at that tag. Each repo's Release Drafter resolves
+its next version from its own labels, so the two drafts can differ; before either is
+published both must carry the same version. Dispatch the Release Drafter workflow with a
+`version` input (for example `0.1.0-rc.2`) to set one to match. A pull request that touches the image runs
 `.github/workflows/ci-image.yaml`, which builds it without pushing, runs it read-only with
 every capability dropped against a Postgres container, and checks that it turns healthy,
 that the node-creds volume is owned by 65532, and that `/healthz` answers 503 once the