diff --git a/.github/workflows/cut-release.yml b/.github/workflows/cut-release.yml
index e5fe311..44978e5 100644
--- a/.github/workflows/cut-release.yml
+++ b/.github/workflows/cut-release.yml
@@ -111,20 +111,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
diff --git a/.github/workflows/release.yml b/.github/workflows/release.yml
index 2d3f099..e1a4f4d 100644
--- a/.github/workflows/release.yml
+++ b/.github/workflows/release.yml
@@ -4,11 +4,11 @@ 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.
+        description: Which part of the version to raise.
         required: true
         type: choice
-        default: patch
         options:
+          - (choose one)
           - patch
           - minor
           - major
diff --git a/README.md b/README.md
index cd721d7..fc38592 100644
--- a/README.md
+++ b/README.md
@@ -63,11 +63,11 @@ 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.
+        description: Which part of the version to raise.
         required: true
         type: choice
-        default: patch
         options:
+          - (choose one)
           - patch
           - minor
           - major
@@ -95,8 +95,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.