@@ -50,6 +50,11 @@ jobs:
       # confusing place to find out. Checked in the shell rather than an `if:`
       # because workflow expressions compare case-insensitively, so `Major`
       # would clear one and then fail inside the action.
+      #
+      # This also catches the placeholder a caller's dropdown opens on. A
+      # dispatch that never answered the question arrives here as an
+      # unrecognised bump and stops, which is why no step downstream has to
+      # care what a first release looks like.
       - name: Check the requested bump
         env:
           BUMP: ${{ inputs.bump }}
@@ -111,20 +116,6 @@ jobs:
             echo "| Dry run | ${DRY_RUN} |"
           } >> "${GITHUB_STEP_SUMMARY}"
 
-      # Only fires on the first release, where the baseline is 0.0.0. A patch
-      # from there lands v0.0.1 permanently, so this is enforced rather than
-      # left to the input description. Reads `previous_version` rather than
-      # `previous_tag`, which carries the action's tag prefix and would make
-      # this a second copy of a default owned elsewhere.
-      - name: Require the first release to be major
-        if: ${{ steps.version.outputs.previous_version == '0.0.0' && inputs.bump != 'major' }}
-        env:
-          BUMP: ${{ inputs.bump }}
-        run: |
-          echo "This repository has no releases yet, so the first one has to be a" >&2
-          echo "major bump to land v1.0.0. This run asked for ${BUMP}." >&2
-          exit 1
-
   publish:
     needs: version
     # `success()` is implicit here, and it is what keeps the version job's
 
@@ -4,11 +4,15 @@ on:
   workflow_dispatch:
     inputs:
       bump:
-        description: Which part of the version to raise. The first release has to be major, because the count starts from 0.0.0.
+        # The dropdown always opens on something, and there is no way to make
+        # it open on nothing, so it opens on a value the called workflow
+        # rejects. A dispatch that skipped the question fails instead of
+        # quietly shipping whichever bump happened to be first.
+        description: Which part of the version to raise.
         required: true
         type: choice
-        default: patch
         options:
+          - (choose one)
           - patch
           - minor
           - major
 
@@ -63,11 +63,15 @@ on:
   workflow_dispatch:
     inputs:
       bump:
-        description: Which part of the version to raise. The first release has to be major, because the count starts from 0.0.0.
+        # The dropdown always opens on something, and there is no way to make
+        # it open on nothing, so it opens on a value the called workflow
+        # rejects. A dispatch that skipped the question fails instead of
+        # quietly shipping whichever bump happened to be first.
+        description: Which part of the version to raise.
         required: true
         type: choice
-        default: patch
         options:
+          - (choose one)
           - patch
           - minor
           - major
@@ -95,8 +99,12 @@ jobs:
 
 The workflow refuses to run against anything but the calling repository's default
 branch, refuses any re-run of a run it has already started, and refuses to publish over
-a tag it did not create. A retry means dispatching again. The first release has to be a major bump, because the version
-walk starts from 0.0.0 and a patch from there spends `v0.0.1` permanently.
+a tag it did not create. A retry means dispatching again.
+
+The `bump` dropdown opens on `(choose one)`, which the workflow rejects. The version
+walk starts from 0.0.0, so on a repository with no tags patch opens at `v0.0.1`, minor
+at `v0.1.0` and major at `v1.0.0`. Which of those a repository wants is its own call,
+so the workflow asks rather than assumes.
 
 `STEP_SECURITY_API_KEY` is optional. Without it the Harden Runner step is skipped and
 the rest runs unchanged.