diff --git a/.github/workflows/release.yml b/.github/workflows/release.yml
index 135857d..a2583ee 100644
--- a/.github/workflows/release.yml
+++ b/.github/workflows/release.yml
@@ -8,7 +8,8 @@
 #            dl.shellrs.com, creates the GitHub release, and only then
 #            replaces the channel's manifest, which is what clients follow;
 #            the manifest lists the GitHub release as each package's
-#            second address
+#            second address; last, it has Cloudflare rebuild shellrs.com,
+#            whose download page and changelog read that manifest
 #
 # A tag with a pre-release (v0.3.0-beta.1) goes to the beta channel only. A
 # stable release also becomes the beta channel's, unless beta is ahead.
@@ -22,7 +23,7 @@
 #               (base64), APPLE_API_KEY_ID, APPLE_API_ISSUER
 #   environment `release`: MINISIGN_SECRET_KEY, MINISIGN_PASSWORD,
 #               R2_ACCOUNT_ID, R2_ACCESS_KEY_ID, R2_SECRET_ACCESS_KEY,
-#               R2_BUCKET, CF_ZONE_ID, CF_API_TOKEN
+#               R2_BUCKET, CF_ZONE_ID, CF_API_TOKEN, SITE_DEPLOY_HOOK
 name: release
 
 on:
@@ -335,3 +336,8 @@ jobs:
           curl -fsS -X POST "https://api.cloudflare.com/client/v4/zones/$CF_ZONE_ID/purge_cache" \
             -H "Authorization: Bearer $CF_API_TOKEN" -H "Content-Type: application/json" \
             --data "$files"
+      # After the purge: the site's build reads the manifests from dl.shellrs.com.
+      - name: Rebuild shellrs.com
+        env:
+          SITE_DEPLOY_HOOK: ${{ secrets.SITE_DEPLOY_HOOK }}
+        run: curl -fsS -X POST "$SITE_DEPLOY_HOOK"
diff --git a/CLAUDE.md b/CLAUDE.md
index bdb78e9..69e512b 100644
--- a/CLAUDE.md
+++ b/CLAUDE.md
@@ -119,7 +119,7 @@ cargo test -- --ignored                     # 会读写真实钥匙串的测试
   - 连不上（没在运行，或崩溃留下的套接字文件）才正常启动。两个同时启动、都没连上对方的话，后一个建套接字失败，只弹「外部 CLI 无法启动」。不做多窗口：并排看靠 Dock 分栏；将来要做，共享的数据和服务得先提到应用层。
 - **macOS 上关窗口是隐藏，不是退出。** ShellRS 只有一个窗口，在跑的东西（连接、传输、端口转发、外部 CLI）都归窗口里的工作区；GPUI 在 macOS 上默认不随最后一个窗口退出（`QuitMode::Default`），真关掉窗口会停掉这一切，却留下一个没有窗口、点 Dock 图标也唤不回的进程。所以 `main` 给窗口挂 `app::hide_when_closed`（`on_window_should_close` 里 `cx.hide()` 并返回 `false`），点 Dock 图标（`Application::on_reopen`）和再次打开 ShellRS（`come_forward_when_opened_again`）都走 `app::bring_forward`：先 `NSApplication::unhide`（只 `activate` 不一定让隐藏的窗口重新出现），再激活窗口。⌘Q 才退出。Windows / Linux 关窗口即退出（GPUI 的默认）。测试平台的 `hide()` 是 `unimplemented!()`，所以这条只挂在生产路径上，没有 UI 测试，改动后要在真实窗口里试。
 - **在线升级的接入照外部 CLI 的先例。** `new_with_services` 只建一个没有服务的 `Updater`（阶段 `Off`、从不联网），生产路径 `Workspace::new` 再 `set_services(UpdateServices::system(cx.app_path()))` 和 `start()`；UI 测试经 `workspace.updater()` 注入假的 feed、安装器、测试公钥和临时目录。「自动升级」和「更新渠道」存在 `AppSettings::update`（`automatic`、`channel`，后者直接用 `update::Channel`，在 settings 里实现 `Choice`），工作区在 `observe_in(&settings)` 里 `sync_updater`（`set_automatic`、`set_channel`），`update` 模块不依赖 `settings`。动作是 `CheckForUpdates` / `DownloadUpdate` / `ShowUpdate` / `RestartToUpdate` / `OpenDownloadPage`，处理器在 `workspace/updates.rs`；对话框里「重启会中断什么」由工作区数（`restart_impact`：运行中的远程终端、已连接的 SFTP 标签、本地终端、传输、端口转发）。重启走 gpui 的 `cx.set_restart_path` + `cx.restart()`，它会照常跑 `on_app_quit`（SFTP 借此保存续传进度）；脚本没能起来时 2 秒后报失败。**Windows 不在退出过程中起进程**：gpui 退出时在 App 仍被借用的状态下跑 `on_app_quit`，而创建进程会泵消息循环、重入 GPUI，所以安装程序的等待进程交给 `update::start_handed_over()`，由 `main` 在 `run()` 返回之后启动（Windows 的事件循环结束后 `run` 会返回）。更新前写 `updates/applied.json`（from、to），新进程据此通知「已更新到」或「更新没有完成」。下载目录是 `app::updates_dir()`（用户缓存目录；设了 `SHELLRS_DATA_DIR` 时在数据目录下）。
-- **发布走 tag。** 推 `v<版本>`（和 `Cargo.toml` 一致，`CHANGELOG.md` 里要有 `## [版本]` 一节）触发 `.github/workflows/release.yml`：分平台构建打包（`packaging/macos/bundle.sh`、`packaging/windows/shellrs.iss`、`packaging/linux/appimage.sh`），在需要人工批准的 `release` 环境里上传 R2、建 GitHub Release，**最后**才用 `packaging/make-manifest.sh` 生成并上传清单、清 CDN 缓存。清单格式见 `packaging/manifest.example.json`（`the_example_manifest_parses` 守着它和解析器一致，`the_release_script_signs_what_the_client_accepts` 守着脚本和验签一致）。一次性准备和 secrets 见 `docs/release.md`。
+- **发布走 tag。** 推 `v<版本>`（和 `Cargo.toml` 一致，`CHANGELOG.md` 里要有 `## [版本]` 一节）触发 `.github/workflows/release.yml`：分平台构建打包（`packaging/macos/bundle.sh`、`packaging/windows/shellrs.iss`、`packaging/linux/appimage.sh`），在需要人工批准的 `release` 环境里上传 R2、建 GitHub Release，**最后**才用 `packaging/make-manifest.sh` 生成并上传清单、清 CDN 缓存，再调用部署挂钩（`SITE_DEPLOY_HOOK`）让官网 shellrs.com 重新构建。清单格式见 `packaging/manifest.example.json`（`the_example_manifest_parses` 守着它和解析器一致，`the_release_script_signs_what_the_client_accepts` 守着脚本和验签一致）。一次性准备和 secrets 见 `docs/release.md`。
 - **库只往前升，旧版本不碰新库。** `migrate` 遇到 `user_version > SCHEMA_VERSION`（或早于第一步）直接报错、不动文件（`open_store` 退回内存 store 并提示）；迁移已有的库之前先 `VACUUM INTO '<库>.v<旧版本>.bak'`（WAL 下不能直接复制文件），备份失败只打日志、照样迁移。
 - **窗口还在搭的时候不能直接弹通知。** 通知层属于窗口的 `Root`，而 `Root` 要等 `open_window` 的构造闭包返回才挂上；在那之前 `window.push_notification` 会 panic（「window first layer should be a gpui_component::Root」），应用启动即崩溃。`main` 里读库 / 读设置的问题、`Workspace::new` 里外部 CLI 启动失败，都用 `workspace::notify_once_open`（`window.defer`）延后到窗口建好。`cx.emit` 出去的事件本来就在构造结束后才送达，订阅里弹通知没有这个问题（自动开启的转发启动失败就是这样报的）。
 - **一个命令一个处理器。** 按钮、菜单、右键菜单、快捷键都只派发 `app/actions.rs` 里的动作，由 `Workspace` 处理。新增命令加在那里，不要写临时闭包直接改状态。
diff --git a/docs/release.md b/docs/release.md
index 8279ba6..ac1dd91 100644
--- a/docs/release.md
+++ b/docs/release.md
@@ -6,16 +6,16 @@
 
 1. 核对 tag 与 `Cargo.toml` 一致，截出更新说明，确认代码里有发布公钥；
 2. 构建并打包：macOS 合成 universal，签名、公证、staple，产出升级用的 `.app.zip` 和首次安装用的 `.dmg`；Windows 用 Inno Setup 打安装程序；Linux 打 AppImage；
-3. 在 `release` 环境里人工批准后：给每个包签名，上传到 R2（`dl.shellrs.com/releases/<版本>/`），建 GitHub Release，**最后**才替换更新清单 `dl.shellrs.com/update/v1/<通道>.json` 并清 CDN 缓存。清单里每个包有两个下载地址：先 R2，下载失败时客户端接着试 GitHub Release（仓库是公开的，下载不用登录）。
+3. 在 `release` 环境里人工批准后：给每个包签名，上传到 R2（`dl.shellrs.com/releases/<版本>/`），建 GitHub Release，**最后**才替换更新清单 `dl.shellrs.com/update/v1/<通道>.json` 并清 CDN 缓存，然后调用官网的部署挂钩重新构建 shellrs.com（官网的下载页和更新日志在构建时读这份清单）。清单里每个包有两个下载地址：先 R2，下载失败时客户端接着试 GitHub Release（仓库是公开的，下载不用登录）。
 
 版本号带 `-` 的（如 `0.3.0-beta.1`）只发到 beta 通道；正式版同时成为 beta 通道的最新版。在 Actions 里手动运行这个 workflow 只构建打包、不发布，用来演练。客户端只接受比自己新的版本，所以发错的版本撤不回来：把清单改回上一版能阻止更多人升级，修复要发新的补丁版。
 
 一次性准备：
 
 - **更新签名密钥**：`minisign -G -p shellrs-update.pub -s shellrs-update.key` 生成两对（一对日常用，一对离线保存备用），把两个公钥（`.pub` 文件的第二行）填进 `src/update/build_info.rs` 的 `TRUSTED_KEYS`。私钥和口令只放进 GitHub 的 `release` 环境，另外离线备份；丢了私钥，已发出去的 ShellRS 就再也收不到更新。换钥匙时先发一版带上新公钥，再换签名用的私钥。
-- **Cloudflare**：shellrs.com 的 DNS 托管在 Cloudflare；建 R2 bucket，绑定自定义域 `dl.shellrs.com`，关闭 `r2.dev` 地址；Cache Rules 让 `/releases/*` 和 `/update/*` 按源站的 Cache-Control 缓存（默认不缓存 `.json`、`.AppImage`）；一个只能写这个 bucket 的 R2 API Token，一个只能清这个 zone 缓存的 API Token。
+- **Cloudflare**：shellrs.com 的 DNS 托管在 Cloudflare；建 R2 bucket，绑定自定义域 `dl.shellrs.com`，关闭 `r2.dev` 地址；Cache Rules 让 `/releases/*` 和 `/update/*` 按源站的 Cache-Control 缓存（默认不缓存 `.json`、`.AppImage`）；一个只能写这个 bucket 的 R2 API Token，一个只能清这个 zone 缓存的 API Token；官网项目（独立的私有仓库，由 Cloudflare 连着仓库构建）在「设置 › 构建 › 部署挂钩」里建一个构建 `main` 分支的挂钩。
 - **Apple**：Developer ID Application 证书（导出 .p12）和 notarytool 用的 App Store Connect API Key。`packaging/macos/Info.plist.in` 里的 bundle id `com.shellrs.ShellRS` 和签名的 Team ID 一经发布就不能再改：钥匙串按它们授权，改了之后每条保存的密码都要重新允许。
 - **图标**：`assets/logo/` 里的 `shellrs.icns`（macOS）、`shellrs.png`（1024×1024，Linux，macOS 没有 icns 时也由它生成）和 `shellrs.ico`（Windows 安装程序）。
-- **GitHub secrets**：仓库级的 `APPLE_CERTIFICATE_P12`（base64）、`APPLE_CERTIFICATE_PASSWORD`、`APPLE_SIGNING_IDENTITY`、`APPLE_TEAM_ID`、`APPLE_API_KEY_P8`（base64）、`APPLE_API_KEY_ID`、`APPLE_API_ISSUER`；`release` 环境（设为需要审批）里的 `MINISIGN_SECRET_KEY`、`MINISIGN_PASSWORD`、`R2_ACCOUNT_ID`、`R2_ACCESS_KEY_ID`、`R2_SECRET_ACCESS_KEY`、`R2_BUCKET`、`CF_ZONE_ID`、`CF_API_TOKEN`。
+- **GitHub secrets**：仓库级的 `APPLE_CERTIFICATE_P12`（base64）、`APPLE_CERTIFICATE_PASSWORD`、`APPLE_SIGNING_IDENTITY`、`APPLE_TEAM_ID`、`APPLE_API_KEY_P8`（base64）、`APPLE_API_KEY_ID`、`APPLE_API_ISSUER`；`release` 环境（设为需要审批）里的 `MINISIGN_SECRET_KEY`、`MINISIGN_PASSWORD`、`R2_ACCOUNT_ID`、`R2_ACCESS_KEY_ID`、`R2_SECRET_ACCESS_KEY`、`R2_BUCKET`、`CF_ZONE_ID`、`CF_API_TOKEN`、`SITE_DEPLOY_HOOK`（官网部署挂钩的地址，拿到它的人能触发官网重新构建，泄露了就删掉重建）。
 
 清单格式见 `packaging/manifest.example.json`，由 `packaging/make-manifest.sh` 生成：一个文件里是清单原文和它的 minisign 签名，签名的 trusted comment 写明通道和版本。格式只增加字段、不改已有的；已发出去的 ShellRS 一直按 `/update/v1/` 这个地址检查。