diff --git a/patches/README.md b/patches/README.md
index 752e30ff29e4df957b03b6b8123863fdfcd46c82..4a67ac4e10367748a113e99fe086c322e06af8b0 100644
--- a/patches/README.md
+++ b/patches/README.md
@@ -65,7 +65,7 @@ - **`api.sr.ht` is excluded** alongside `paste` and `pages`. The federated GraphQL gateway serves no pages of its own; it is listed *before* the instance deploys one, because a section appearing in the config is all it takes for a service to enter the switcher.
 
 The logic lives in a new module, `srht/app/nav.py`, rather than in more lines of `flask.py`. That keeps the patch's contact with upstream down to three small hunks — an import, one list entry, three context keys — and it gives the Go half a single function to be compared against.
 
-**Status.** Written 2026-08-23 against `docs/SPEC.nav.md` in `sr-ht-ecore` (stages 0–1); **not applied anywhere yet.** The Go half is already released in `sr-ht-ecore/chrome`; this patch is the statement of the Python half, and how it reaches production is still an open decision — see below.
+**Status.** Written 2026-08-23 against `docs/SPEC.nav.md` in `sr-ht-ecore` (stages 0–1). The Go half is released in `sr-ht-ecore/chrome`; the Python half is committed to phoebe-lab as an image-build patch (see below) and **reaches the instance on the next `labng push srht`**, which nobody has run yet. Not upstreamed.
 
 **How it would reach production, and why that is not settled.** The spec's chapter 7 says to add the patch to `source=` in `sr.ht-apkbuilds/sr.ht/core.sr.ht/APKBUILD`. That is wrong for this instance, and the reason is worth writing down because it applies to every future core.sr.ht patch:
 
@@ -73,7 +73,9 @@ - `~/data/home/sourcehut/sr.ht-apkbuilds` is a read-only clone of **upstream's** repo (its only remote is `git.sr.ht/~sircmpwn/sr.ht-apkbuilds`), and its `core.sr.ht` APKBUILD still pins `0.83.0` while the instance runs **0.84.5**. Nothing here builds core.sr.ht from it.
 - The apk comes from `~bigbes/srht-upstream`, a channel that **mirrors upstream's prebuilt packages** (`mirror.sr.ht` → `apk-mirror` → Garage → the channel). No local build step exists to hook a patch into.
 - The mechanism actually in use for core.sr.ht is `phoebe-lab/srht/scripts/patch-*.py` — idempotent scripts that rewrite the *installed* files in `Dockerfile.base`. `nav.html` is already patched twice that way, by `patch-nav-brand.py` and `patch-nav-register.py`, and neither touches the `<ul class="navbar-nav">` this patch rewrites.
 
-The Python and template hunks therefore want to become a `patch-nav-groups.py` beside those two. The `scss` hunks are the harder half and have no answer yet:
+The Python and template hunks are therefore carried as `phoebe-lab/srht/scripts/patch-nav-groups.py` plus `phoebe-lab/srht/overlay/core/nav.py`, wired into `Dockerfile.base` — the module dropped into site-packages beside upstream's, the script only teaching `flask.py` to import it and `nav.html` to render it. This `.patch` stays as the statement of the change and as what a future upstream submission would look like; the script is what actually runs. **Keep them in step**: the script's `NAV_NEW` and the module are the same text as this patch's, and a fix applied to one and not the other is a divergence nothing checks.
+
+The `scss` hunks are the harder half and have no answer yet:
 
 - The **Python services'** CSS is compiled at *their own* apk build (`SASSC_INCLUDE=-I$(ASSETS)/scss/` in each service's Makefile) and arrives prebuilt inside upstream's package. Editing core.sr.ht's scss cannot reach it; only patching the built CSS in the image, or serving an extra stylesheet, can.
 - The **Go services'** CSS is compiled in each service's own CI, which clones core.sr.ht at `CORE_VER` and runs `make css`. There the scss hunks do apply — by `git apply`ing this patch after the clone, exactly as `Dockerfile.pages` and `Dockerfile.builds-worker` already do for `core-go-checksum.patch`. That is ten `.build.yml` files.