diff --git a/CHANGELOG.md b/CHANGELOG.md
index 5bb7e78..0af97aa 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -14,12 +14,27 @@ Pre-v1.0.0 tags followed the pi npm version (`v{pi_version}[letter]`).
 ## v1.8.13 — 2026-09-06
 
 **Version audit + three pins moved, one deliberately not moved.** `pi`
-0.84.4 -> 0.85.1, `mempalace` 3.8.0 -> 3.9.0, `pi-atelier` v0.10.0 -> v0.10.1,
-and `PI_STUDIO_VERSION` relabelled `none` -> `v0.9.60-rc.0` to record what the
-floating `main` ref actually resolves to. `PI_FORK_REF=master` stays floating
-and therefore adopts e69725c. Each rationale is written at the ARG itself
-rather than only here, because that is where the next person doing the audit
-will be standing.
+0.84.4 -> 0.85.1, `mempalace` 3.8.0 -> 3.9.0, `pi-atelier` v0.10.0 -> v0.10.1.
+`PI_FORK_REF=master` stays floating and therefore adopts e69725c. Each rationale
+is written at the ARG itself rather than only here, because that is where the
+next person doing the audit will be standing.
+
+**Correction, made mid-release while run 639 was building:** the audit
+originally recorded a fourth change — "`PI_STUDIO_VERSION` relabelled `none` ->
+`v0.9.60-rc.0`, RC adopted deliberately" — and that was wrong. It was measured
+at the wrong layer. `resolve-versions` passes BOTH `PI_STUDIO_REF` and
+`PI_STUDIO_VERSION` as build-args and selects the newest **stable** semver tag
+(its filter `^v?[0-9]+\.[0-9]+\.[0-9]+$` excludes pre-releases), so a Dockerfile
+default cannot answer "what will CI publish?". Measured from the run itself:
+`studio_tag=v0.9.59`, `studio_ref=9eed84f` (= `refs/tags/v0.9.59^{}`), while
+`main`/`v0.9.60-rc.0` is 658536f and is not built. **Published v1.8.13 studio
+images therefore contain pi-studio v0.9.59, not the RC**, and the ARG is back at
+`none` rather than pinned to a pre-release that goes stale the moment main
+moves. Consequence kept deliberately: the RC's opt-in Studio network binding is
+absent from every published v1.8.13 image, so it needs no audit for this
+release. Adopting an RC from CI would require changing that tag filter, which
+exists on purpose — upstream stopped publishing Releases at v0.5.55 but keeps
+tagging and pushing to main, so pinning main risked baking half-finished commits.
 
 0.85.0 is SKIPPED on purpose: it shipped internal experimental code and extra
 subpaths that broke SDK imports (upstream #9132), and 0.85.1 exists to undo
diff --git a/Dockerfile.variant b/Dockerfile.variant
index 7e9f8e4..ed54d8e 100644
--- a/Dockerfile.variant
+++ b/Dockerfile.variant
@@ -283,16 +283,30 @@ ARG PI_STUDIO_REF=main
 # was resolved from; recorded as a label below for at-a-glance identification.
 # Only meaningful for the studio variant (default `none` otherwise).
 #
-# v1.8.13: PI_STUDIO_REF stays floating on `main`, which resolves to
-# v0.9.60-rc.0 — a RELEASE CANDIDATE, not the latest stable (v0.9.59).
-# Adopted deliberately (JOA, 2026-09-06); recording the label is what makes
-# that choice visible via `docker inspect` instead of someone discovering an
-# RC in production later. Of the 15 commits since 0.9.55, one adds an OPT-IN
-# network binding for the Studio server: that is network-facing and deserves
-# its own audit before anyone enables it. The container default is unchanged —
-# pi-studio still hard-binds 127.0.0.1 (see the STUDIO_EXPOSE bridge below),
-# so adopting the RC does not by itself expose Studio to the LAN.
-ARG PI_STUDIO_VERSION=v0.9.60-rc.0
+# v1.8.13 — READ THIS BEFORE REASONING ABOUT WHICH pi-studio SHIPS. Neither
+# default below survives a CI build. `resolve-versions` in
+# .gitea/workflows/docker-publish.yml passes BOTH as build-args (studio_ref and
+# studio_tag), and it deliberately selects the newest STABLE semver tag: its
+# filter is `^v?[0-9]+\.[0-9]+\.[0-9]+$`, which excludes pre-releases. So a
+# PUBLISHED v1.8.13 studio image contains pi-studio v0.9.59 (commit 9eed84f,
+# = refs/tags/v0.9.59^{}), NOT the v0.9.60-rc.0 that `main` currently points at
+# (658536f). The `main` default here only applies to a local `docker build`
+# that passes no studio args.
+#
+# That upstream-tag-over-main choice is intentional and documented at the
+# resolve step: pi-studio keeps tagging every version but stopped publishing
+# GitHub Releases at v0.5.55 and pushes freely to main, so pinning main risked
+# baking half-finished commits that land after a tag.
+#
+# Corrected here on 2026-09-06 after reading the run-639 resolve-versions
+# output: the v1.8.13 audit had recorded "RC adopted deliberately" and set this
+# ARG to v0.9.60-rc.0, which was measured at the wrong layer — a Dockerfile
+# default cannot answer "what will CI publish?" when CI overrides it. Left at
+# `none` rather than pinned to a tag, because a hardcoded pre-release here goes
+# stale the moment main moves and would re-tell the same lie to the next reader.
+# Consequence worth keeping: the RC's opt-in Studio network binding is NOT in
+# any published v1.8.13 image, so it needs no audit for this release.
+ARG PI_STUDIO_VERSION=none
 RUN if [ "${INSTALL_STUDIO}" = "true" ]; then \
       set -e; \
       rm -rf /opt/pi-studio && mkdir -p /opt/pi-studio && \