diff --git a/.github/workflows/publish-release.yml b/.github/workflows/publish-release.yml
index 5c9594e..70f7e8f 100644
--- a/.github/workflows/publish-release.yml
+++ b/.github/workflows/publish-release.yml
@@ -130,7 +130,7 @@ jobs:
           payload="$(jq -nc \
             --arg tag "$RELEASE_TAG" \
             --arg url "$RELEASE_URL" \
-            '{text: (":rocket: Rabbit Automation Action *" + $tag + "* is published.\n" + $url + "\n\nNext:\n• Wait for *Verify release* to pass.\n• Publish it in GitHub Marketplace (Deployment, Security).\n• Verify the listing and complete the caller canary before moving `v1`.")}')"
+            '{text: (":rocket: Rabbit Automation Action *" + $tag + "* is published.\n" + $url + "\n\nNext:\n• Wait for *Verify release* to pass.\n• Verify Marketplace shows this version and current metadata/README.\n• Run a plan-only non-production caller canary with `@production`, then move `v1`.")}')"
           curl --fail-with-body --silent --show-error \
             --request POST \
             --header 'Content-type: application/json' \
diff --git a/.rabbit/repo.yaml b/.rabbit/repo.yaml
index 6118844..40bd427 100644
--- a/.rabbit/repo.yaml
+++ b/.rabbit/repo.yaml
@@ -9,6 +9,8 @@ branches:
     rules: {}
   - name: chore/publish-versioned-releases
     rules: {}
+  - name: docs/clarify-marketplace-releases
+    rules: {}
   - name: fix/dispatch-release-verification
     rules: {}
   - name: fix/gcp-credential-mount
diff --git a/CHANGELOG.md b/CHANGELOG.md
index 4abbbcf..f8f1d62 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -3,6 +3,11 @@
 All notable changes to this action are recorded here. Versions follow semantic
 versioning; callers should normally use the maintained `v1` major tag.
 
+## v1.0.4 - 2026-08-24
+
+- Clarified the one-time GitHub Marketplace setup and the checks required for
+  each subsequent action release. No action runtime behavior changed.
+
 ## v1.0.3 - 2026-08-18
 
 - Added release verification, workflow linting, and a production release
diff --git a/docs/releasing.md b/docs/releasing.md
index 3c09978..662d3d4 100644
--- a/docs/releasing.md
+++ b/docs/releasing.md
@@ -9,8 +9,6 @@ The action is released from `production`. Patch releases are immutable
    user-facing notes at the top of `CHANGELOG.md` in the pull request that
    changes action behavior.
 2. Merge the focused, reviewed pull request into `production`.
-3. Test the exact `production` commit from a caller's non-production
-   environment. Use `@production` only for that canary.
 
 The `Publish release` workflow runs after every `production` push. It does
 nothing unless that push changes the `package.json` version; then it runs
@@ -18,9 +16,9 @@ nothing unless that push changes the `package.json` version; then it runs
 release from the merged commit. It explicitly dispatches `Verify release` for
 the published tag, because release events created with `GITHUB_TOKEN` do not
 start other workflows.
-After the GitHub release is created, `#rabbit-support` receives the Marketplace
-handoff through `SLACK_WEBHOOK_RABBIT_SUPPORT`; the message directs the
-operator to wait for verification before publishing to Marketplace.
+After the GitHub release is created, `#rabbit-support` receives a handoff
+through `SLACK_WEBHOOK_RABBIT_SUPPORT` to wait for verification and check the
+Marketplace listing.
 
 `package.json` is the single release-version source. Its semantic version maps
 to the Git tag by adding `v` and must match the first semantic heading in
@@ -28,28 +26,38 @@ to the Git tag by adding `v` and must match the first semantic heading in
 published. A production push creates a release only when this version changes,
 and its version must increase.
 
-## Publish to GitHub Marketplace
+## GitHub Marketplace
 
-1. Confirm the `Verify release` workflow passed for the automatically
-   published semantic GitHub release, for example `v1.0.3`.
-2. Open that release and, in the release form, select **Publish this Action to
-   the GitHub Marketplace**. GitHub requires this UI step and may require 2FA;
-   a release created only through the REST or CLI release API is not enough.
-3. Keep `Deployment` as the primary Marketplace category and `Security` as the
-   secondary category unless the action's public purpose changes.
-4. Verify the Marketplace listing shows the new version, current `action.yml`
-   metadata, and current README before changing any caller references.
+Publishing an action to GitHub Marketplace is a one-time UI setup. This action
+already has a Marketplace listing, so a published versioned release updates the
+existing listing without another manual publishing step.
 
-The published-tag verification does not replace the pre-release caller canary
-or the Marketplace UI verification.
+For the first Marketplace release only, open the release form and select
+**Publish this Action to the GitHub Marketplace**. GitHub may require 2FA.
+Use `Deployment` as the primary category and `Security` as the secondary
+category unless the action's public purpose changes.
+
+For every release:
+
+1. Confirm `Verify release` passed for the published semantic tag, for example
+   `v1.0.4`.
+2. Confirm the Marketplace listing shows that version, the current `action.yml`
+   metadata, and the current README.
+
+Published-tag verification does not replace the caller canary or the
+Marketplace listing check.
 
 ## Promote callers
 
-1. Move the `v1` tag to the tested immutable release commit.
-2. Confirm `v1` and the patch tag resolve to the same commit with
+1. In a caller repository's non-production environment, run a plan using
+   `udx/github-rabbit-action@production`. This caller canary proves the exact
+   release commit works in a real consumer workflow; it must not apply
+   infrastructure.
+2. Move the `v1` tag to the tested immutable release commit.
+3. Confirm `v1` and the patch tag resolve to the same commit with
    `git ls-remote --tags origin 'v1*'`.
-3. Update reusable workflows and callers from `@production` to `@v1`.
-4. Run a non-production caller plan using `@v1` before merging the consumer
+4. Update reusable workflows and callers from `@production` to `@v1`.
+5. Run a non-production caller plan using `@v1` before merging the consumer
    change.
 
 Use a new major tag for breaking input, output, safety, or lifecycle-contract
diff --git a/package.json b/package.json
index 65a9cdf..70cb43f 100644
--- a/package.json
+++ b/package.json
@@ -1,6 +1,6 @@
 {
   "name": "@udx/github-rabbit-action",
-  "version": "1.0.3",
+  "version": "1.0.4",
   "private": true,
   "description": "Rabbit Automation Action release manifest",
   "license": "GPL-2.0-only",