@@ -184,6 +184,8 @@ Give the agent a hot-swappable library of expertise it picks *implicitly* per ta
 
 **M8 — Mac polish + release prep.**
 Native menus, traffic-light integration, cold-start optimization; auto-update channel; final name + original logo + trademark check; notarized public/personal release. *Exit test: the app feels native and updates itself.*
+- **🚫 RELEASE-BLOCKER — rename off "Atom" before any public release.** "Atom" is GitHub's trademark for the editor they sunset (Dec 2022); the name **and** the atom-orbit logo carry real IP risk if reused publicly. **"Atom++" is a working CODENAME only** — keep building under it, but ship the first public release under a final, **trademark-cleared original name + an original logo** (keep the Atom feel — hackable, friendly, power-user — without the protected mark/orbit motif). *Build-blocker: no. Release-blocker: yes.* **Two real decisions** (everything else is mechanical find/replace): (1) the **final name** — needs a basic USPTO/EUIPO + domain + npm/Open-VSX-publisher availability check; (2) an **original logo** — replaces `branding/icons/*` (the atom-orbit PNGs/`.icns`/`.svg`) and the spinning-atom footer indicator in `media/chat.html`. *The rename surface (finite, mapped):* `branding/product.overlay.json` (`nameShort`/`nameLong`/`applicationName`/`serverApplicationName`/`dataFolderName`/`darwinBundleIdentifier`/`win32MutexName`/`urlProtocol`/`licenseUrl`), the `atompp` extension `publisher` + ~94 `atompp.*` setting/command IDs, the `.app`/`.dmg`/`VOL_NAME` in `scripts/*`, and doc/README strings. **Why strictly pre-release:** `dataFolderName` (`~/.atom-plus-plus`), `darwinBundleIdentifier`, the `urlProtocol`, and the `atompp.*` settings namespace become **migration-locked the moment real users exist** (renaming them later orphans user settings/data + breaks the auto-update identity). So this lands once, cleanly, before the first signed/notarized build ships — and pairs naturally with the M8 signing step.
+- **🚫 RELEASE-BLOCKER — point `configurationSync.store` at the managed sync host before any signed build.** `branding/product.overlay.json` → `configurationSync.store.url`/`stableUrl`/`insidersUrl` are a **dev placeholder (`http://localhost:9595`)** so Atom++ Sync round-trips against the local reference server (`tools/sync-server/`). Shipping as-is points every user's built-in Settings Sync at a dead localhost host → **silent total sync failure**. Before the first signed/notarized build, set the three URLs to the managed **Atom++ Cloud** sync host (thin.ly, once the `/v1` contract is implemented — design: [`docs/atompp-sync-design.md`](docs/atompp-sync-design.md) §S2). *Build-blocker: no. Release-blocker: yes.* (The inline `_syncComment` in the overlay is stripped by `apply-branding.mjs` and never reaches the shipped `product.json`, so this canonical entry is the source of truth.)
 - **Signing & notarization** — full step-by-step runbook in [`docs/SIGNING-NOTARIZATION.md`](docs/SIGNING-NOTARIZATION.md): Apple Developer enrollment → *Developer ID Application* cert → notarization credential → inside-out hardened-runtime signing + Electron/V8 entitlements → `notarytool` notarize → `stapler` staple → verify. *Status: enrollment in progress (awaiting Apple, ~2 business days); `make-dmg.sh` stays ad-hoc until the cert lands. Repo integration (entitlements plist + `sign-notarize.sh`, env-gated so ad-hoc still works without a cert) is staged in the runbook's §10.*
 
 **M9 — Atom++ Cloud: accounts & sync. — strategic, opt-in, privacy-preserving.**