soulteary · soulteary · Sep 2, 2026 · Sep 2, 2026
diff --git a/CHANGELOG.md b/CHANGELOG.md
@@ -2,6 +2,16 @@
 
 ## [Unreleased]
 
+### Changed
+
+- Marked `2026.09.02-r2` as published after both registries, supply-chain
+  evidence, signatures, and mutable aliases passed verification; switched the
+  Quick Start and Compose example from a local `main` build to the immutable
+  release image.
+- Corrected the release and contribution guides to consistently describe
+  protected lightweight and annotated tag support and the GitHub Release
+  publication order.
+
 ## [2026.09.02-r2] - 2026-09-02
 
 ### Fixed
@@ -10,7 +20,7 @@
   `2026.09.02-r1` as a lightweight tag. The release workflow rejected that tag
   during annotated-tag preflight, before registry login or image construction.
 - Aligned the image version, validation examples, deployment examples, and
-  release documentation on the same `2026.09.02-r2` candidate.
+  release documentation on the same `2026.09.02-r2` release.
 
 ### Changed
 
@@ -25,9 +35,10 @@
 
 ### Release status
 
-- Prepared as the next immutable release for 2026-09-02. Until its protected
-  annotated tag is published and verified, `2026.09.01-r1` remains the current
-  complete release.
+- Published to Docker Hub and GHCR as matching five-platform indexes at
+  `sha256:9a5ceb20d80485de3e71bfe4a454f913408c6cdc995df17c2805e90fea5a049a`.
+  Per-platform SBOM and provenance evidence and both registry signatures were
+  verified before the `2026.09.02` and `latest` aliases were promoted.
 
 ### Release notes
 

diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
@@ -200,14 +200,16 @@ Please search for existing issues before opening a new one. When reporting a bug
 
 - **Dockerfile**: Keep the multi-stage build structure clear; keep necessary comments for non-obvious trade-offs (such as skipping the Rust build per platform).
 - **PHP** (`sqlite-select-id-key-fix.php`, etc.): Follow the WordPress coding standards and keep behavior conservative and safe to fall back on, avoiding destructive changes for cases that cannot be fully reasoned about.
-- **YAML workflows**: Keep pull-request validation and the tag-driven `Release` workflow consistent with the supported platform matrix and release policy.
+- **YAML workflows**: Keep pull-request validation and the release-triggered `Release` workflow consistent with the supported platform matrix and release policy.
 - Comments should explain intent and constraints, not restate what the code already expresses.
 
 ## Versioning and Releases
 
-Releases are triggered by maintainers pushing a protected annotated tag in the
-CalVer form `YYYY.MM.DD-rN`. The workflow publishes the same signed multi-arch
-manifest under an immutable exact tag to
+Normal releases are triggered when maintainers publish a GitHub Release for a
+protected CalVer tag in the form `YYYY.MM.DD-rN`. The Releases form may create a
+protected lightweight tag or select an existing protected annotated tag; a tag
+push alone does not publish images. The workflow publishes the same signed
+multi-arch manifest under an immutable exact tag to
 [Docker Hub](https://hub.docker.com/r/soulteary/sqlite-wordpress) and
 [GHCR](https://github.com/soulteary/docker-sqlite-wordpress/pkgs/container/sqlite-wordpress),
 then separately promotes the mutable date and `latest` aliases. Component

diff --git a/README.md b/README.md
@@ -4,15 +4,13 @@
 
 WordPress with SQLite, ready to use out of the box.
 
-<!-- release-availability: pending -->
-> **Container release availability:** `2026.09.02-r2` is prepared but is not published yet
-> as a verified container image. The previous verified release,
-> [`2026.09.01-r1`](https://github.com/soulteary/docker-sqlite-wordpress/releases/tag/2026.09.01-r1),
-> remains available from Docker Hub and GHCR with matching manifest digest
-> `sha256:a2ab943b2f9c9818528153e5b9ac70f9f84625a1f58a24d14a0bb35b91387666`.
-> Until the protected annotated `2026.09.02-r2` tag succeeds in both registries,
-> build current `main` as shown in Quick Start. The existing `latest` alias still
-> represents the previous release and does not include this candidate's fixes.
+> **Latest container release:**
+> [`2026.09.02-r2`](https://github.com/soulteary/docker-sqlite-wordpress/releases/tag/2026.09.02-r2)
+> is published to Docker Hub and GHCR as matching five-platform indexes at
+> `sha256:9a5ceb20d80485de3e71bfe4a454f913408c6cdc995df17c2805e90fea5a049a`.
+> The verified `2026.09.02` and `latest` aliases were promoted from the same
+> release. Pin the exact CalVer tag or manifest digest for reproducible
+> deployments.
 
 - Based on [official image](https://hub.docker.com/_/wordpress), Easier and more sustainable solution.
 - DockerHub Page: https://hub.docker.com/r/soulteary/sqlite-wordpress
@@ -61,32 +59,26 @@ docker exec -it <container> ls -l /var/www/html/wp-content/mu-plugins/
 
 ## Quick Start
 
-Until `2026.09.02-r2` is published, build current `main` locally:
+Pull the immutable CalVer release for reproducible deployments, or use the
+rolling `latest` alias when automatic version movement is intentional:
 
 ```bash
-docker build -t sqlite-wordpress:main .
-```
-
-After the protected release workflow succeeds, pull the rolling tag for
-convenience or the immutable CalVer release for reproducible deployments:
-
-```bash
-# Docker Hub: use latest
-docker pull soulteary/sqlite-wordpress
 # Docker Hub: use an immutable release
 docker pull soulteary/sqlite-wordpress:2026.09.02-r2
-# GHCR: use latest
-docker pull ghcr.io/soulteary/sqlite-wordpress:latest
 # GHCR: use an immutable release
 docker pull ghcr.io/soulteary/sqlite-wordpress:2026.09.02-r2
+# Docker Hub: use latest
+docker pull soulteary/sqlite-wordpress
+# GHCR: use latest
+docker pull ghcr.io/soulteary/sqlite-wordpress:latest
 ```
 
-Launch the locally built image on port `8080`:
+Launch the published image on port `8080`:
 
 ```bash
 docker run --rm -it -p 127.0.0.1:8080:80 \
   -v "$(pwd)/wordpress:/var/www/html" \
-  sqlite-wordpress:main
+  soulteary/sqlite-wordpress:2026.09.02-r2
 ```
 
 You can also use docker compose to start wordpress:
@@ -95,9 +87,7 @@ You can also use docker compose to start wordpress:
 services:
 
   wordpress:
-    build:
-      context: .
-    image: sqlite-wordpress:main
+    image: soulteary/sqlite-wordpress:2026.09.02-r2
     restart: always
     ports:
       # Safe local default. Change this only when intentionally publishing the
@@ -107,7 +97,7 @@ services:
       - ./wordpress:/var/www/html
 ```
 
-Save the file as `docker-compose.yml` and execute `docker compose up --build`,
+Save the file as `docker-compose.yml` and execute `docker compose up -d`,
 then use a browser to access `localhost:8080`.
 
 ![](.github/ready-to-use.jpg)
@@ -193,7 +183,7 @@ messages, and publishes only its Web inbox to the host:
 docker compose \
   -f docker-compose.yml \
   -f docker-compose.owlmail.yml \
-  up --build -d
+  up -d
 ```
 
 Open WordPress at `http://localhost:8080`, visit **Settings → SMTP**, and enable
@@ -214,7 +204,7 @@ export WORDPRESS_SMTP_AUTH=false
 docker compose \
   -f docker-compose.yml \
   -f docker-compose.owlmail.yml \
-  up --build -d --force-recreate
+  up -d --force-recreate
 ```
 
 Send a test message through the real WordPress mail path:

diff --git a/RELEASING.md b/RELEASING.md
@@ -17,10 +17,11 @@ reviewers when an explicit publication approval is desired.
 
 Repository rulesets cannot be installed by a pull request. An administrator
 must configure and verify this policy in **Settings → Rules → Rulesets**. The
-workflow independently requires GitHub's `ref_protected` signal and rejects
-branch dispatches, lightweight tags, tags outside `main`, and tags whose target
-does not match the checked-out commit. Server-side tag protection remains the
-authoritative control.
+workflow independently requires GitHub's `ref_protected` signal and accepts both
+lightweight (`commit`) tags created by the Releases form and existing annotated
+(`tag`) tags. It rejects branch dispatches, tags whose target commit is not on
+`main`, and tags whose target does not match the checked-out commit. Server-side
+tag protection remains the authoritative control.
 
 ## Prepare
 
@@ -67,7 +68,8 @@ release-triggered run is active.
 
 For an annotated tag, create and push it first, then select that existing tag
 in the GitHub Releases form. A tag push alone no longer starts publication;
-publishing the GitHub Release is the single fresh-release trigger.
+publishing the GitHub Release is the normal automatic fresh-release trigger.
+Manual dispatch remains the explicit operator path described below.
 
 The `Release` workflow builds each runtime platform once and publishes the same
 manifest digest to Docker Hub and GHCR under the immutable exact tag:
@@ -171,8 +173,10 @@ release=2026.09.02-r2
    ./scripts/verify-published-release.sh "${release}"
    ```
 
-   Create the GitHub Release from the existing annotated tag only after all
-   image checks succeed.
+   The GitHub Release already exists at this stage because its `published`
+   event starts normal fresh publication. Record the verified digest in the
+   post-release documentation and announcement; do not create another tag or
+   Release.
 
 4. If the release pull request carried the `release-availability: pending`
    README marker and local-build Compose configuration, open a documentation

diff --git a/docker-compose.yml b/docker-compose.yml
@@ -1,9 +1,7 @@
 services:
 
   wordpress:
-    build:
-      context: .
-    image: sqlite-wordpress:main
+    image: soulteary/sqlite-wordpress:2026.09.02-r2
     restart: always
     ports:
       # Safe local default. Replace 127.0.0.1 only when intentionally publishing