diff --git a/admin_ui_cleanup.md b/admin_ui_cleanup.md
index 782e5c1..b4187d1 100644
--- a/admin_ui_cleanup.md
+++ b/admin_ui_cleanup.md
@@ -236,10 +236,20 @@ foundation branch merges — all branches build independently and compose at mer
    .btn-group-sm > .btn, .btn-sm { --bs-btn-font-size: .78rem; --bs-btn-padding-y: .25rem; --bs-btn-padding-x: .6rem; }
    ```
 
-   This normalizes every unsized button app-wide without touching call sites. **Upstreaming
-   candidate**: this block is now duplicated in ignitionoee `app.css` and OtOpcUa `site.css`; when a
-   `ZB.MOM.WW.Theme` release ships a `.btn` rule, delete the local copies (both files carry a header
-   comment saying exactly this).
+   This normalizes every unsized button app-wide without touching call sites. **Upstreamed in
+   `ZB.MOM.WW.Theme` 0.4.0** — the kit now ships this block in `layout.css`, after all five apps had
+   independently written it. On bump to 0.4.0+ it arrives automatically, so remove the local copy in
+   the same change or the rule is declared twice.
+
+   **Trim the local block, don't delete it wholesale.** The upstreamed rule covers *sizing* only —
+   the four `--bs-btn-*` variables and the `.btn-group-sm > .btn, .btn-sm` rule. A local `.btn` may
+   also carry app-specific *shape* declarations that predate the sweep and that the kit does not
+   ship; mxgw's carried `border-radius: 5px; font-weight: 500; white-space: nowrap`, and a wholesale
+   delete would have silently dropped all three. Diff your block against the kit's before removing
+   anything: three of the five apps' blocks were pure sizing and safe to delete outright, one was
+   not, and the difference is invisible unless you look. Note also that a retained `border-radius`
+   should stay a **literal** rather than becoming `--bs-btn-border-radius` — `.btn-sm` redefines
+   that variable, so the switch would shrink small buttons to Bootstrap's small radius.
 3. **Phantom tokens → a real class**, not a token alias. OtOpcUa's pattern:
    `.notice-alert { color: var(--bad); background: var(--bad-bg); border-color: var(--bad-border); }`
    then migrate the inline `style="border-color:var(--alert)"` hacks to the class in the page
@@ -344,7 +354,15 @@ dies at setup and never enqueues. That is a rig capability ceiling — don't man
 don't claim the sites you couldn't reach.
 
 Rebuild/redeploy the app's dev rig (**all** instances behind the load balancer — round-robin serves
-you the stale one otherwise), then walk:
+you the stale one otherwise), then **hard-reload** and walk the checks below.
+
+**The cache bypass is not optional, and skipping it inverts the result.** After a kit-CSS change
+(a `ZB.MOM.WW.Theme` bump, a new rule in `layout.css`), a normal reload can serve the *previous*
+version of `layout.css` from cache while the server is serving the new one correctly. The symptom
+is precisely the signature of a failed change — HistorianGateway saw `.btn` computing at
+Bootstrap's 16px, exactly what an unreached override looks like — so the natural next move is to
+"fix" it by restoring the local rule you just deleted, entrenching the duplication the change
+removed. Hard-reload first; only then trust a computed-style probe.
 
 1. Computed-style probes (one `javascript` eval): a `.btn`'s `font-size` vs body; the phantom-token
    replacement class resolving to real colors; the scoped bundle present in `document.styleSheets`.