diff --git a/README.md b/README.md
index d4d120a..8593869 100644
--- a/README.md
+++ b/README.md
@@ -20,7 +20,8 @@ AppolyDroid Toolbox is a comprehensive collection of Android utility modules tha
 
 ## Installation
 
-Add the JitPack repository to your project build file:
+The toolbox is published to Maven Central, so no custom repository is required — if
+`mavenCentral()` is already in your repositories list, there is nothing to add:
 
 ```gradle.kts
 dependencyResolutionManagement {
@@ -30,15 +31,13 @@ dependencyResolutionManagement {
 }
 ```
 
-The toolbox is published to Maven Central, so no custom repository is required — if `mavenCentral()`
-is already in your repositories list, there is nothing to add.
-
 > **Migrating from 1.8.3 or earlier?** Those versions were published on JitPack under
 > `com.github.appoly.AppolyDroid-Toolbox` with PascalCase artifact names. From 1.9.0 the coordinates
 > are `uk.co.appoly.droid` with lowercase names — for example
 > `com.github.appoly.AppolyDroid-Toolbox:BaseRepo` becomes `uk.co.appoly.droid:baserepo`, and
-> `AppolyDroid-Toolbox-bom` becomes `bom`. The `jitpack.io` repository entry can be removed unless
-> something else needs it.
+> `AppolyDroid-Toolbox-bom` becomes `bom`. Keep your `jitpack.io` entry unless you have checked
+> that nothing else needs it — the toolbox no longer does, but other dependencies may, and a group
+> like `com.github.projectdelta6` looks deceptively like the toolbox's old coordinates.
 
 ### Testing an unreleased change
 
diff --git a/docs/maven-central-migration.md b/docs/maven-central-migration.md
index a7edc0e..213a91f 100644
--- a/docs/maven-central-migration.md
+++ b/docs/maven-central-migration.md
@@ -2,7 +2,7 @@
 
 Migration of AppolyDroid Toolbox publishing from JitPack to Maven Central.
 
-**Status as of 26 Aug 2026** — phases 1–3 complete, 1.9.0 not yet released.
+**Status as of 26 Aug 2026** — 1.9.0 released to Maven Central. Phase 5 (consumers) remains.
 Current release: 1.8.3 on JitPack. 26 published modules.
 
 Two attempts to fix AAR source navigation were defeated by the same JitPack rewrite.
@@ -17,10 +17,9 @@ Publishing to Maven Central removes the rewriter rather than working around it.
 | Namespace `uk.co.appoly` | TXT record absent from authoritative NS | **Verified** on the Central portal |
 | Publishing configuration | 26 hand-written blocks, JitPack workarounds | **Landed** — `e48652e` |
 | Release path | Planned as a tag-triggered CI job | **Superseded** — manual local run |
-| 1.9.0 on Central | Not started | **Ready to publish** — nothing outstanding |
+| 1.9.0 on Central | Not started | **Released** — 26 coordinates live, sources verified |
 
-Nothing blocks cutting 1.9.0 except the decision to run it. After the release, four
-in-house consumers move over.
+1.9.0 is released and serving. All that remains is moving the four in-house consumers.
 
 ---
 
@@ -127,7 +126,7 @@ script exports all five:
 export OP_ACCOUNT=appoly.1password.com   # required: two accounts are registered
 ```
 
-### 4. Publish 1.9.0 and verify — next
+### 4. Publish 1.9.0 and verify — done
 
 A minor bump, not a patch — the coordinates change, so consumers must act.
 `TOOLBOX_VERSION` is already `1.9.0`; no `1.9.0` tag exists and Central returns 404 for the
@@ -141,7 +140,22 @@ module — not just the one JVM module.
 **Immutability bites here.** A released version can never be re-uploaded or corrected.
 Iterate with `--local` *before* the release, not after.
 
-A full `--dry-run` passed on 26 Aug: all five vault fields read, tests and coverage green,
+**Released 26 Aug 2026.** Deployment `6dde9178-1023-4072-b6a4-d920bdae35bd`, 48/48 components
+validated by Central, tag `1.9.0` → `e400b22`. Verified against the bytes Central actually
+serves, not against the local build:
+
+- All 26 coordinates return their POM from `repo1.maven.org`.
+- `baserepo` — an **AAR** module, the case that defeated JitPack twice — serves a
+  `releaseVariantReleaseSourcePublication` variant whose file entry is
+  `baserepo-1.9.0-sources.jar`, classifier intact. This is precisely what JitPack stripped.
+- That sources jar downloads (19,981 bytes) and is a valid archive containing 14 `.kt` files,
+  so it is real source rather than an empty placeholder.
+
+The remaining check is human: cmd+B in a consuming project should land on source rather than
+decompiled bytecode. Do it against an AAR module — 1.8.3 passed verification because only the
+one JVM module was checked.
+
+The earlier `--dry-run` passed on 26 Aug: all five vault fields read, tests and coverage green,
 consumer keep rules intact, 26 modules signed and installed to `~/.m2`, and the variant gate
 clean (4 toolbox modules at 1.9.0, no `-jvm` duplicates). The only untested step is the
 upload itself — reading the portal token proves it is fetchable, not that Central accepts it.
@@ -163,6 +177,29 @@ as the last release there.
 Worth pairing deliberately: WenWe and AssistantHood exercise different module sets, so a
 single green consumer proves little about the other.
 
+**WenWe migrated first, 26 Aug — passed.** Three findings that apply to the remaining three:
+
+1. **FlexiLogger moves 2.1.3 → 2.1.4.** The toolbox's own source is unchanged from 1.8.3 apart
+   from publishing config, but `81d5aac` bumped FlexiLogger, and it arrives transitively via
+   `baserepo`, `datehelperutil`, `connectivitymonitor` and `s3uploader`. A consumer that does
+   not declare a FlexiLogger version inherits the bump silently — and it is the layer logging
+   and crash reporting go through. A resolved-classpath diff on WenWe (949 → 948 coordinates)
+   showed this and the toolbox group/case swap were the *only* changes.
+
+2. **Do not remove `jitpack.io` by default.** The toolbox no longer needs it, but consumers may:
+   WenWe still resolves `com.github.projectdelta6:PrefsHelperBase` and `ComposeReorderable`
+   from JitPack. Removing it there would have broken the build. Check per consumer; assume it
+   stays until proven otherwise.
+
+3. **The `mavenLocal()` warning is per-consumer, not universal.** WenWe never declares it, so
+   the stale local 1.9.0 in `~/.m2/repository/uk/co/appoly` could not shadow anything. Check
+   before advising anyone to clear it.
+
+Also confirmed in WenWe: `okhttp-android` resolving beside `okhttp` is pre-existing (the normal
+okhttp 5.x split, present on both sides of the diff), not a migration artefact; no `-jvm` beside
+an `-android`; and `assembleStagingRelease` passes under R8 with no new missing-class warnings,
+which is the honest duplicate-class test since dexing is what would fail.
+
 Owner: per-app sessions, roughly 30 minutes each.
 
 ---