diff --git a/DEVELOPMENT.md b/DEVELOPMENT.md
index 7d73e44..abbea14 100644
--- a/DEVELOPMENT.md
+++ b/DEVELOPMENT.md
@@ -77,20 +77,20 @@ output and isn't committed, `ci_scripts/ci_post_clone.sh` runs on every Xcode
 Cloud build to pull git-lfs assets, generate the project, and copy the committed
 package pins into place.
 
-Build numbers come from Xcode Cloud's run counter plus `BUILD_OFFSET` (59, the
-last build uploaded by hand), so the first Xcode Cloud build is 60.
-`CURRENT_PROJECT_VERSION` in `project.yml` is only rewritten on the CI runner —
-the committed value stays put.
+Build numbers are assigned by Xcode Cloud, which overwrites `CFBundleVersion`
+with its own run counter at archive time — `CURRENT_PROJECT_VERSION` in
+`project.yml` is ignored on CI. They only need to be unique and increasing
+within a marketing version, so a new train starting at a low number is fine.
 
 `MARKETING_VERSION` is still bumped by hand. Once a marketing version is
 approved on the App Store that train closes, and further uploads against it fail
 with `90186`/`90062` — so raise it in `project.yml` before releasing against an
 already-approved version.
 
-`just release` still archives and uploads from your Mac if you need it, but it
-bumps `CURRENT_PROJECT_VERSION` in `project.yml` and would collide with the
-Xcode Cloud sequence. If you use it, raise `BUILD_OFFSET` past the number it
-burned.
+`just release` still archives and uploads from your Mac if you need it, but
+don't mix the two: it uploads `project.yml`'s `CURRENT_PROJECT_VERSION`, which
+is far ahead of Xcode Cloud's run counter, and once a higher build number exists
+on the current train Xcode Cloud's next run would be rejected as not increasing.
 
 When SPM dependencies change, refresh the committed pins — Xcode Cloud disables
 automatic package resolution, and the live file lives inside the gitignored
diff --git a/ci_scripts/ci_post_clone.sh b/ci_scripts/ci_post_clone.sh
index 3aa8000..733e930 100755
--- a/ci_scripts/ci_post_clone.sh
+++ b/ci_scripts/ci_post_clone.sh
@@ -36,18 +36,14 @@ export APPLE_TEAM_ID="${APPLE_TEAM_ID:-YN68LN9T7Z}"
 export BUNDLE_ID="${BUNDLE_ID:-social.grain.grain}"
 export BUNDLE_NAME="${BUNDLE_NAME:-Grain}"
 
-# TestFlight rejects duplicate build numbers, and Xcode Cloud's run counter
-# starts at 1 while builds up to 59 already shipped from `just release`. Offset
-# the counter past the last manually uploaded build so the first Xcode Cloud
-# build is 60. Override BUILD_OFFSET as an environment variable in the App Store
-# Connect workflow if the sequence ever needs to jump again.
-BUILD_OFFSET="${BUILD_OFFSET:-59}"
-BUILD_NUMBER=$((${CI_BUILD_NUMBER:-1} + BUILD_OFFSET))
-
-# project.yml keeps CURRENT_PROJECT_VERSION as a literal so `just release` can
-# still bump it locally; CI overwrites it here rather than in the committed file.
-# MARKETING_VERSION is deliberately left alone — bumping the train is manual.
-sed -i '' "s/CURRENT_PROJECT_VERSION: \".*\"/CURRENT_PROJECT_VERSION: \"$BUILD_NUMBER\"/" project.yml
+# Build numbers are Xcode Cloud's to assign — it overwrites CFBundleVersion with
+# its own run counter when it archives, so writing one into project.yml here has
+# no effect (run 45 set CURRENT_PROJECT_VERSION to 104 and still uploaded as
+# build 45). Build numbers only have to be unique and increasing *within* a
+# marketing version, so restarting at a low number on a new train is fine.
+#
+# MARKETING_VERSION is left alone: bumping the train is manual and deliberate,
+# and it has to happen before the current version is approved (see DEVELOPMENT.md).
 
 xcodegen generate