docs: rewrite README and AGENTS.md etc..

docs/ops/deployment.md

@@ -54,9 +54,9 @@ macOS 的 Apple Silicon 产物带临时 ad-hoc 签名，Intel 产物未签名。
 
 Backend 使用 OCI 标准镜像，通过 `registry.oeo.one/moshiro/moshiro-backend:<version>` 分发，支持 `linux/amd64` 和 `linux/arm64`。容器使用 glibc NativeAOT 单文件程序（动态链接，运行时要加载 libssl；musl 的静态产物做不到），基底为 `mcr.microsoft.com/dotnet/runtime-deps:10.0`（Debian），以非 root 用户运行，在 `8080/tcp` 提供 HTTP 服务；数据库和原始数据统一写入 `/data`。程序启用 InvariantGlobalization，无需 .NET 运行时或 ICU；时间查询使用 UTC。SQLite 从固定版本的官方源码编译并静态链接，不再随镜像携带 `libe_sqlite3.so`。将 `/data` 挂载为持久卷，并在反向代理处配置 HTTPS。
 
-**前端内嵌在 Backend 里**：CI 构建 Backend 前先构建 `web/display` 和 `web/admin`，`Backend.Api` 把两个 `dist` 嵌进程序，展示端在 `/`，管理端在 `/admin/`，所以面板的域名（如 `https://mo.oeo.one/admin/`）打开就是管理端，passkey 才能绑定在这个域名上（浏览器只允许页面的来源与 RP 域名一致，本机 `localhost` 上的页面注册不了绑定 `mo.oeo.one` 的 passkey）。本地没有构建前端时不嵌入，Backend 只提供 API。文件是启动时读进内存的白名单，请求时不访问文件系统；带 `..`、反斜杠、`%`、控制字符或空段的路径一律 404，缺失的文件（带扩展名）404，只有无扩展名的路径回退到入口页；`/api`、`/openapi`、`/install`、`/healthz` 下没有匹配到的路径仍是后端的 JSON 404。页面带 CSP（脚本只许同源）、`nosniff`、`X-Frame-Options: DENY`，入口页 `no-cache`，哈希文件名的资源 `immutable`，不嵌入 source map。部署时设置 `MoShiro__PublicUrl=https://<面板域名>`（`deploy-node.sh backend --public-url …`），WebAuthn 的域名和允许的来源由它派生。
+前端内嵌在 Backend 里：CI 构建 Backend 前先构建 `web/display` 和 `web/admin`，`Backend.Api` 把两个 `dist` 嵌进程序，展示端在 `/`，管理端在 `/admin/`，所以面板的域名（如 `https://mo.oeo.one/admin/`）打开就是管理端，passkey 才能绑定在这个域名上（浏览器只允许页面的来源与 RP 域名一致，本机 `localhost` 上的页面注册不了绑定 `mo.oeo.one` 的 passkey）。本地没有构建前端时不嵌入，Backend 只提供 API。文件是启动时读进内存的白名单，请求时不访问文件系统；带 `..`、反斜杠、`%`、控制字符或空段的路径一律 404，缺失的文件（带扩展名）404，只有无扩展名的路径回退到入口页；`/api`、`/openapi`、`/install`、`/healthz` 下没有匹配到的路径仍是后端的 JSON 404。页面带 CSP（脚本只许同源）、`nosniff`、`X-Frame-Options: DENY`，入口页 `no-cache`，哈希文件名的资源 `immutable`，不嵌入 source map。部署时设置 `MoShiro__PublicUrl=https://<面板域名>`（`deploy-node.sh backend --public-url …`），WebAuthn 的域名和允许的来源由它派生。
 
-**用 compose 部署**（Docker 和 Podman 通用，需要 `docker compose` 或 `podman compose`）：compose 文件是静态的，在仓库的 `packaging/compose/backend/compose.yaml`，每个发布版本的 Gitea Release 里也有一份 `moshiro-compose-backend.yaml`（第一次部署时还没有面板，就从这里下载）。镜像用 `:${MOSHIRO_VERSION:-latest}`：
+用 compose 部署（Docker 和 Podman 通用，需要 `docker compose` 或 `podman compose`）：compose 文件是静态的，在仓库的 `packaging/compose/backend/compose.yaml`，每个发布版本的 Gitea Release 里也有一份 `moshiro-compose-backend.yaml`（第一次部署时还没有面板，就从这里下载）。镜像用 `:${MOSHIRO_VERSION:-latest}`：
 
 ```sh
 mkdir moshiro-backend && cd moshiro-backend
@@ -68,9 +68,9 @@ EOF
 podman compose up -d        # Docker 用 docker compose
 ```
 
-**更新**：先备份数据卷，再 `podman compose pull && podman compose up -d`。新版启动时自动迁移数据库，但**旧版不认比自己新的数据库**：想回滚要先恢复备份，只改 `MOSHIRO_VERSION` 不够。Backend 能指挥所有节点，更新它尽量用 Quadlet（`packaging/quadlet/moshiro-backend.container`，见下文「Backend 的更新」：管理端确认，更新前自动备份数据库），或者在 `.env` 里把 `MOSHIRO_VERSION` 固定到经过核对的版本或 digest。
+更新：先备份数据卷，再 `podman compose pull && podman compose up -d`。新版启动时自动迁移数据库，但旧版不认比自己新的数据库：想回滚要先恢复备份，只改 `MOSHIRO_VERSION` 不够。Backend 能指挥所有节点，更新它尽量用 Quadlet（`packaging/quadlet/moshiro-backend.container`，见下文「Backend 的更新」：管理端确认，更新前自动备份数据库），或者在 `.env` 里把 `MOSHIRO_VERSION` 固定到经过核对的版本或 digest。
 
-**首次认领（没有默认管理员）**：面板里还没有任何用户时，打开 `/admin/` 会进入认领向导：
+首次认领（没有默认管理员）：面板里还没有任何用户时，打开 `/admin/` 会进入认领向导：
 1. 填认领码（首次启动时随机生成并写进后端日志，`journalctl -u moshiro-backend` 或 `docker logs`；也可以用 `MoShiro__ClaimCode` / `MOSHIRO_CLAIM_CODE` 指定）、管理员的用户名和密码；
 2. 注册你的第一把 passkey；
 3. 用它给操作员集合签名，建立信任根。
@@ -80,11 +80,11 @@ Compose 将容器端口只绑定到宿主机 `127.0.0.1:8080`，适合由同机
 
 Backend 的 NativeAOT 发布默认启用 `SqliteStaticLink`，支持 Linux glibc/musl、macOS、Windows 的 x64/arm64 RID；跨平台构建使用 `-p:UseAotAnywhere=true`。SQLite 源码版本、下载年份和 SHA-256 统一配置在根目录 `Directory.Packages.props`，构建会校验下载文件并按 RID 缓存原生对象。普通 JIT 开发构建仍使用 NuGet 原生库。发布 Backend 时设置 `-p:OpenApiGenerateDocuments=false`，API 文档在普通开发构建中生成。
 
-健康检查端点为 `GET /healthz`。容器定义见 [`../packaging/container/Backend.Containerfile`](../../packaging/container/Backend.Containerfile)。
+健康检查端点为 `GET /healthz`。容器定义见 [`packaging/container/Backend.Containerfile`](../../packaging/container/Backend.Containerfile)。
 
 ## 节点二进制发布
 
-Woodpecker 在 `vMAJOR.MINOR.PATCH` tag 上，由 Windows runner 使用 AotAnywhere 并行构建 Agent/Probe 的 Linux glibc、Linux musl、macOS 和 Windows 产物。Agent 包还包含一次性注册工具 `fleet-enroll`。Linux 归档带有安装脚本和 systemd/OpenWrt 单元；Windows 产物为 `.zip`，Linux/macOS 产物为 `.tar.gz`。glibc sidecar 选用 Debian 12 兼容构建，musl sidecar 来自 Alpine v3.22。Linux musl 的 Agent 与 Probe 二进制还会打包为 OCI 镜像，基底为 `mcr.microsoft.com/dotnet/runtime-deps:10.0-alpine`，支持 `linux/amd64` 和 `linux/arm64`；镜像直接带有归档中的 MsQuic、NUMA 和 LTTng 共享库，并通过 `LD_LIBRARY_PATH` 加载。Linux 原生库包按 RID 缓存在 CI runner 的 `.nuget/moshiro-quic-runtime`，索引最多缓存 24 小时，已下载的版本包会复用。所有平台产物和 OCI 镜像发布成功后，CI 会创建对应的 Gitea Release，并附上压缩包和 SHA-256 校验文件。macOS 产物目前未签名/公证。安装说明见 [`../backend/agent/README.md`](../../backend/agent/README.md) 与 [`../backend/probe/README.md`](../../backend/probe/README.md)。
+Woodpecker 在 `vMAJOR.MINOR.PATCH` tag 上，由 Windows runner 使用 AotAnywhere 并行构建 Agent/Probe 的 Linux glibc、Linux musl、macOS 和 Windows 产物。Agent 包还包含一次性注册工具 `fleet-enroll`。Linux 归档带有安装脚本和 systemd/OpenWrt 单元；Windows 产物为 `.zip`，Linux/macOS 产物为 `.tar.gz`。glibc sidecar 选用 Debian 12 兼容构建，musl sidecar 来自 Alpine v3.22。Linux musl 的 Agent 与 Probe 二进制还会打包为 OCI 镜像，基底为 `mcr.microsoft.com/dotnet/runtime-deps:10.0-alpine`，支持 `linux/amd64` 和 `linux/arm64`；镜像直接带有归档中的 MsQuic、NUMA 和 LTTng 共享库，并通过 `LD_LIBRARY_PATH` 加载。Linux 原生库包按 RID 缓存在 CI runner 的 `.nuget/moshiro-quic-runtime`，索引最多缓存 24 小时，已下载的版本包会复用。所有平台产物和 OCI 镜像发布成功后，CI 会创建对应的 Gitea Release，并附上压缩包和 SHA-256 校验文件。macOS 产物目前未签名/公证。安装说明见 [Agent](../../backend/agent/README.md) 与 [Probe](../../backend/probe/README.md) 文档。
 
 ## CI 工作流
 
@@ -106,11 +106,11 @@ Pull request 和 `main` 的 push 会跑三个 workflow：
 
 - `verify`：后端的快测试（除了标了 `Category=Slow` 的全部，约 20 秒）；
 - `web-build`：前端构建和 CSS 检查，和 `verify` 并行（约 15 秒）；
-- 标了 `Category=Slow` 的端到端测试（真实时间的 Hy2 阶梯、IPv6 和真探针的几条，一百来秒）：带 `[CI]` 的推送，在 `dev-image` 里**等三个镜像都构建、推送完**再跑（不和 NativeAOT 编译抢内存——同时跑过一次，Backend 的 AOT 编译被内存不足杀掉了）；PR 和没带 `[CI]` 的推送由 `e2e` workflow 在 `verify` 之后跑。失败照样红，但不影响已经推出去的镜像。
+- 标了 `Category=Slow` 的端到端测试（真实时间的 Hy2 阶梯、IPv6 和真探针的几条，一百来秒）：带 `[CI]` 的推送，在 `dev-image` 里等三个镜像都构建、推送完再跑（不和 NativeAOT 编译抢内存——同时跑过一次，Backend 的 AOT 编译被内存不足杀掉了）；PR 和没带 `[CI]` 的推送由 `e2e` workflow 在 `verify` 之后跑。失败照样红，但不影响已经推出去的镜像。
 
 后端测试用增量编译（`ci/verify-backend.sh`）：源码按内容同步到 CI 主机上一个固定目录，保留 `obj/bin`，只重编译变了的项目；同一时间只有一条流水线用这份缓存。失败的测试会单独重跑（最多两次），重跑通过算通过。给新的慢测试打标记：`[Trait("Category", "Slow")]`。
 
-提交信息后缀 `[SKIP TESTS]` 跳过 `verify` 和 `e2e` 里的后端测试，前端构建仍会运行。Gitea PR 事件的 `CI_COMMIT_MESSAGE` 是 PR 标题，因此在 PR 中跳过测试时，把后缀写入 PR 标题；普通分支 push 则写在 commit message 中。项目只用 `main` 一个工作分支，旧的 `dev` 分支不再被任何流水线使用。
+提交信息后缀 `[SKIP TESTS]` 跳过 `verify` 和 `e2e` 里的后端测试，前端构建仍会运行。Gitea PR 事件的 `CI_COMMIT_MESSAGE` 是 PR 标题，因此在 PR 中跳过测试时，把后缀写入 PR 标题；普通分支 push 则写在 commit message 中。项目只使用 `main` 一个工作分支。
 
 ### 版本号
 
@@ -145,7 +145,7 @@ Agent 和 Probe 的默认发布配置：NativeAOT、完整裁剪、`Optimization
 
 `fleet-enroll` 使用同一套体积优化开关。Fleet 共享库已声明 AOT 兼容，由 Agent、Probe、Backend 或注册工具的最终发布一起裁剪；GC 和运行时功能开关配置在各可执行项目中。
 
-以下是 NativeAOT 可执行文件本身的历史体积，不包含 Linux 包现在附带的 MsQuic sidecar（后续以各 RID 的 CI 产物为准）：
+NativeAOT 可执行文件本身的体积如下，不包含 Linux 包附带的 MsQuic 等共享库，最新数值以各 RID 的 CI 产物为准：
 
 | 程序 | linux-musl-x64 | linux-x64 | win-x64 |
 | --- | --- | --- | --- |
@@ -153,7 +153,7 @@ Agent 和 Probe 的默认发布配置：NativeAOT、完整裁剪、`Optimization
 | moshiro-agent | 8.4 MB | 8.4 MB | 7.3 MB |
 | fleet-enroll | 6.4 MB | 6.4 MB | — |
 
-Linux 上比 Windows 大，是因为 .NET 的加密、压缩、网络本机库被静态链接进来。Linux tar.gz 还包含 MsQuic 和支持库，所以以前 Probe 压缩包约 3.6 MB 的数字已不适用。
+Linux 产物比 Windows 大，是因为 .NET 的加密、压缩、网络本机库被静态链接进来；Linux tar.gz 另含 MsQuic 和支持库。
 
 ## 2. 安装
 
@@ -180,14 +180,14 @@ Linux 上比 Windows 大，是因为 .NET 的加密、压缩、网络本机库
 
 以 `moshiro` 用户运行，沙箱：`NoNewPrivileges`、`ProtectSystem=strict`、`ProtectHome`、`PrivateTmp/Devices`、`ProtectKernel*`、`RestrictAddressFamilies=AF_INET AF_INET6`、`RestrictNamespaces`、`MemoryDenyWriteExecute`（NativeAOT 不 JIT）、`SystemCallArchitectures=native`，`MemoryMax`（Agent 128 MB、Probe 64 MB）。
 
-- **Agent** 只保留 `CAP_NET_RAW`（ICMP 目标任务用），`/etc/moshiro` 只读；Probe 没有任何 capability，只对 `agents.json` 所在的目录可写。
+- Agent 只保留 `CAP_NET_RAW`（ICMP 目标任务用），`/etc/moshiro` 只读；Probe 没有任何 capability，只对 `agents.json` 所在的目录可写。
 - 监听 1024 以下的端口（例如把数据面放到 443）需要在 drop-in 里加 `AmbientCapabilities=CAP_NET_BIND_SERVICE` 和对应的 `CapabilityBoundingSet`。默认端口是 7443/tcp（Probe 控制通道）、7443/udp（QUIC Datagram 数据面）、7444/tcp（TCP 测量）。Agent 在 UDP 端口固定监听；Probe 的 QUIC 连接使用轮换的临时本地源端口。
 
 ### OpenWrt（`packaging/openwrt/`）
 
 #### 原生一键安装与自动更新
 
-管理端「添加 Probe」提供 **OpenWrt · 原生二进制** 命令，以 root 执行。支持 ARM64/aarch64 和 x86_64，不需要容器或 .NET；自动安装依赖、验签下载、固定属主并注册、配置 procd。身份在 `/etc/moshiro/`，更新策略在 `/etc/moshiro-native.conf`（`CHANNEL=dev|release`、`POLICY=auto|manual`、`INTERVAL=30`）。动态 musl 正式包仍需 `libopenssl3`，实际设备兼容性需实机验证。
+管理端「添加 Probe」提供 OpenWrt · 原生二进制 命令，以 root 执行。支持 ARM64/aarch64 和 x86_64，不需要容器或 .NET；自动安装依赖、验签下载、固定属主并注册、配置 procd。身份在 `/etc/moshiro/`，更新策略在 `/etc/moshiro-native.conf`（`CHANNEL=dev|release`、`POLICY=auto|manual`、`INTERVAL=30`）。动态 musl 正式包仍需 `libopenssl3`，实际设备兼容性需实机验证。
 
 带 `[CI]` 的 main push 发布 dev，稳定 tag 发布 release，沿用 `gitea_token` 和 `release_signing_key`；Gitea generic package `moshiro-openwrt` 需允许匿名下载。制品发布后，在线节点收到通知就唤醒更新器，另有 30 秒轮询兜底，不等待 10 分钟。更新器验签、防重放、原子切换完整版本，健康检查失败回滚；Probe 本身不下载、不执行命令。
 
@@ -229,15 +229,15 @@ OpenWrt 默认不带 OpenSSL：`opkg install libopenssl3`（较新的快照和 2
 
 没有公网入站的家宽机器上跑 Backend 时，用隧道（Cloudflare Tunnel 之类）把一个公网域名转到 Backend 的端口；Backend 只写一个监听地址（同时写 `0.0.0.0` 和 `[::]` 会报地址已被占用）；Probe 的 `fleet.server` 就是这个面板地址。小 VPS 上把 `limits.max_total_mbps` 调低。家宽的 IPv6 前缀会在路由器重新拨号（比如停电）后变化，用 IPv6 直连时地址要跟着换；走隧道的域名不受影响。
 
-**国家和运营商**：Backend 用 Probe、Agent 的来源地址向 IP 归属服务查一次，展示在国旗和运营商图标上（`MoShiro__GeoLookupUrl`，缺省 `https://ip.007995.xyz`；留空就不查；这个服务只供公益使用，署名和使用条款由部署的人自己遵守）。Probe、Agent 自己不访问外部服务，所以客户的防火墙审计里不会多出出站连接；Backend 发出去的只有公网 IP（内网地址不发）。Agent 的地址优先用它的对外地址（`public_host`），没有就用 IPv6 地址，再没有（NAT 后面、没有上报公网地址）才用它连面板的来源地址；面板前面有反向代理时，要配置 `MoShiro__TrustedProxies`，否则来源地址是代理的内网地址，这类节点查不到国家。没查到的节点每隔十分钟在心跳里重试一次。
+国家和运营商：Backend 用 Probe、Agent 的来源地址向 IP 归属服务查一次，展示在国旗和运营商图标上（`MoShiro__GeoLookupUrl`，缺省 `https://ip.007995.xyz`；留空就不查；这个服务只供公益使用，署名和使用条款由部署的人自己遵守）。Probe、Agent 自己不访问外部服务，所以客户的防火墙审计里不会多出出站连接；Backend 发出去的只有公网 IP（内网地址不发）。Agent 的地址优先用它的对外地址（`public_host`），没有就用 IPv6 地址，再没有（NAT 后面、没有上报公网地址）才用它连面板的来源地址；面板前面有反向代理时，要配置 `MoShiro__TrustedProxies`，否则来源地址是代理的内网地址，这类节点查不到国家。没查到的节点每隔十分钟在心跳里重试一次。
 
-**从别处看这个面板**：本机跑前端，在页面里把数据源指向面板的地址，用 API 令牌访问，Backend 设 `MoShiro__CorsOrigins` 放行前端的来源（见 [web/README.md](../../web/README.md)）。
+从别处看这个面板：本机跑前端，在页面里把数据源指向面板的地址，用 API 令牌访问，Backend 设 `MoShiro__CorsOrigins` 放行前端的来源（见 [web/README.md](../../web/README.md)）。
 
 ## 容器部署（Podman Quadlet 优先，Docker 用 compose）
 
 普通用户执行 Podman 即为 rootless，使用命名 volume 不需要 `keep-id` 或手动 `chown`。Agent 的配置、原有身份和缓存保存在 `moshiro-agent-config`，Probe 保存在 `moshiro-probe-config`，更新状态使用独立的 `moshiro-<role>-status` volume，在业务容器内只读。不会重新生成已有身份。更新/重建容器不删除 volume；不要删除这些 volume（`podman volume rm`），会丢身份和配置。
 
-**Quadlet 安装（Agent 和 Probe，Podman 系优先，Linux + Podman 4.6 及以上）**：管理端「添加 Agent」「添加 Probe」生成加入令牌之后，第一条命令就是它（面板地址、一次性码、信任根指纹和属主都是公开的值，没有私钥）：写 env（权限 600）、从面板下载静态的 Quadlet 单元并核对 SHA-256、用一个 drop-in 把镜像仓库指向面板配置的、启动用户服务：
+Quadlet 安装（Agent 和 Probe，Podman 系优先，Linux + Podman 4.6 及以上）：管理端「添加 Agent」「添加 Probe」生成加入令牌之后，第一条命令就是它（面板地址、一次性码、信任根指纹和属主都是公开的值，没有私钥）：写 env（权限 600）、从面板下载静态的 Quadlet 单元并核对 SHA-256、用一个 drop-in 把镜像仓库指向面板配置的、启动用户服务：
 
 ```sh
 mkdir -p ~/.config/moshiro ~/.config/containers/systemd/moshiro-probe.container.d && cat > ~/.config/moshiro/probe.env <<'EOF'
@@ -254,11 +254,11 @@ chmod 600 ~/.config/moshiro/probe.env && curl -fsSL 'https://panel.example.com/i
 - 只读根文件系统、丢掉全部能力、`no-new-privileges`、命名卷；用宿主网络（Agent 对外暴露端口，也靠它识别本机公网地址），并只读挂载 `/proc`、`/sys`、`/` 读主机指标。
 - 身份和配置在命名卷 `moshiro-<role>-config` 里：镜像入口脚本（`packaging/container/entrypoint.sh`）第一次启动用 `MOSHIRO_SERVER`、`MOSHIRO_JOIN`（和信任根指纹、属主）注册并写配置，之后重启、换新镜像重建容器都不需要再给参数，所以注册成功之后可以把 env 里的 `MOSHIRO_JOIN` 删掉。缺了信任根指纹或属主就不注册（只有还没有信任根的老面板才用 `MOSHIRO_ALLOW_NO_OWNER=1`）。
 - 开机自启：单元的 `[Install]` 已经写了，退出登录后继续运行需要管理员执行一次 `loginctl enable-linger <用户>`。
-- **更新**：见下一节，默认自动。想固定版本，把 drop-in 里的 `:latest` 换成版本号。回滚就是改回旧版本再 `systemctl --user restart moshiro-<role>`。
-- **信任**：和之前一样信任镜像仓库（Podman 校验它的 TLS 证书），面板被攻破也改不了镜像地址，因为单元和命令都有哈希；节点不验发布签名。
+- 更新：见下一节，默认自动。想固定版本，把 drop-in 里的 `:latest` 换成版本号。回滚就是改回旧版本再 `systemctl --user restart moshiro-<role>`。
+- 信任：节点信任镜像仓库（Podman 校验其 TLS 证书）；单元和命令带有哈希，面板被攻破也改不了镜像地址；节点不验发布签名。
 - 没有 Podman 4.6 或不是 Linux：用下面的 compose（Docker）、一行安装脚本或发布的二进制。
 
-**compose 安装（Agent 和 Probe，Docker；Podman 系请优先用上面的 Quadlet）**：管理端「添加 Agent」「添加 Probe」生成加入令牌之后，给出一段命令（面板地址、一次性码、信任根指纹和属主都是公开的值，没有私钥）：建一个目录，把参数写进 `.env`（权限 600），下载面板提供的静态 compose 文件、核对 SHA-256，一致才启动：
+compose 安装（Agent 和 Probe，Docker；Podman 系请优先用上面的 Quadlet）：管理端「添加 Agent」「添加 Probe」生成加入令牌之后，给出一段命令（面板地址、一次性码、信任根指纹和属主都是公开的值，没有私钥）：建一个目录，把参数写进 `.env`（权限 600），下载面板提供的静态 compose 文件、核对 SHA-256，一致才启动：
 
 ```sh
 mkdir -p moshiro-probe && cd moshiro-probe && cat > .env <<'EOF'
@@ -271,14 +271,14 @@ EOF
 chmod 600 .env && curl -fsSL 'https://panel.example.com/install/compose/probe.yaml' -o compose.yaml && echo "<sha256>  compose.yaml" | sha256sum -c - && podman compose up -d
 ```
 
-- compose 文件是静态的（`packaging/compose/agent|probe|backend/compose.yaml`，作为嵌入资源打进 Backend，由 `/install/compose/{agent,probe,backend}.yaml` 原样提供，不含任何一次性的值）。镜像是 `${MOSHIRO_IMAGE}:${MOSHIRO_VERSION:-latest}`，由 CI 渠道决定，**不由面板决定**；`MOSHIRO_IMAGE` 取自面板的 `MoShiro__NodeImageRegistry` 和 `MoShiro__ImageNamespace`（默认 `registry.oeo.one/moshiro`，开发镜像 `moshiro-dev`）。
-- 只读根文件系统、丢掉全部能力、`no-new-privileges`、命名卷；Linux 上用宿主网络（Agent 对外暴露端口，也靠它识别本机公网地址，并只读挂载 `/proc`、`/sys`、`/` 读主机指标）。**Agent 的 compose 只适用于 Linux**；Probe 在 macOS 和 Windows（Docker Desktop）上没有宿主网络，面板给的命令会在 `.env` 里写 `MOSHIRO_NETWORK_MODE=bridge`。
+- compose 文件是静态的（`packaging/compose/agent|probe|backend/compose.yaml`，作为嵌入资源打进 Backend，由 `/install/compose/{agent,probe,backend}.yaml` 原样提供，不含任何一次性的值）。镜像是 `${MOSHIRO_IMAGE}:${MOSHIRO_VERSION:-latest}`，由 CI 渠道决定，不由面板决定；`MOSHIRO_IMAGE` 取自面板的 `MoShiro__NodeImageRegistry` 和 `MoShiro__ImageNamespace`（默认 `registry.oeo.one/moshiro`，开发镜像 `moshiro-dev`）。
+- 只读根文件系统、丢掉全部能力、`no-new-privileges`、命名卷；Linux 上用宿主网络（Agent 对外暴露端口，也靠它识别本机公网地址，并只读挂载 `/proc`、`/sys`、`/` 读主机指标）。Agent 的 compose 只适用于 Linux；Probe 在 macOS 和 Windows（Docker Desktop）上没有宿主网络，面板给的命令会在 `.env` 里写 `MOSHIRO_NETWORK_MODE=bridge`。
 - 身份和配置在命名卷 `moshiro-<role>-config` 里：镜像入口脚本（`packaging/container/entrypoint.sh`）第一次启动用 `MOSHIRO_SERVER`、`MOSHIRO_JOIN`（和信任根指纹、属主）注册并写配置，之后重启、换新镜像重建容器都不需要再给参数，所以注册成功之后可以把 `.env` 里的 `MOSHIRO_JOIN` 删掉。缺了信任根指纹或属主就不注册（只有还没有信任根的老面板才用 `MOSHIRO_ALLOW_NO_OWNER=1`）。
 - Podman 的开机自启要靠 `podman-restart.service`（`systemctl enable --now podman-restart`；rootless 用 `--user`，并 `loginctl enable-linger`）；Docker 用 compose 里的 `restart: unless-stopped`。
-- **更新**：`podman compose pull && podman compose up -d`（Docker 用 `docker compose`），只重建镜像变了的容器，身份和配置不动，节点几十秒内重连。想固定版本，在 `.env` 里写 `MOSHIRO_VERSION=<版本号>`；想要更严，写成 `MOSHIRO_VERSION=<版本号>@sha256:<digest>`，digest 取自面板信任页或签名清单（那里有发布签名）。回滚就是改回旧版本再 `up -d`。
-- **信任**：compose 来自面板或 CI 渠道，面板被攻破也改不了镜像地址；但客户端不再验发布签名，拉取靠 TLS 加「注册表可信」这个假设（文档里本来就把 CI、Gitea、注册表放在可信范围内）。compose 不会自动更新（见下节），也没有管理端的「更新」列和确认更新按钮。
+- 更新：`podman compose pull && podman compose up -d`（Docker 用 `docker compose`），只重建镜像变了的容器，身份和配置不动，节点几十秒内重连。想固定版本，在 `.env` 里写 `MOSHIRO_VERSION=<版本号>`；想要更严，写成 `MOSHIRO_VERSION=<版本号>@sha256:<digest>`，digest 取自面板信任页或签名清单（那里有发布签名）。回滚就是改回旧版本再 `up -d`。
+- 信任：compose 来自面板或 CI 渠道，面板被攻破也改不了镜像地址；但客户端不再验发布签名，拉取靠 TLS 加「注册表可信」这个假设（文档里本来就把 CI、Gitea、注册表放在可信范围内）。compose 不会自动更新（见下节），也没有管理端的「更新」列和确认更新按钮。
 
-**一行安装脚本（备用，Docker 或 Podman，Agent 和 Probe 共用）**：管理端的弹窗里折叠着一条旧的一行命令，先核对脚本哈希再执行，脚本向面板取签名清单、用内置发布公钥验签、按 digest 拉镜像：
+一行安装脚本（备用，Docker 或 Podman，Agent 和 Probe 共用）：管理端弹窗中折叠着一行安装命令，先核对脚本哈希再执行，脚本向面板取签名清单、用内置发布公钥验签、按 digest 拉镜像：
 
 ```sh
 f=$(mktemp) && curl -fsSL 'https://panel.example.com/install' -o "$f" && echo "<sha256>  $f" | sha256sum -c - >/dev/null \
@@ -288,7 +288,7 @@ f=$(mktemp) && curl -fsSL 'https://panel.example.com/install' -o "$f" && echo "<
 
 脚本是静态的（`packaging/install/install.sh` 和 `install.ps1`，嵌入 Backend，不替换任何值），所以它的 SHA-256 在一个版本内固定；角色、面板地址、代码和属主走环境变量。环境变量 `MOSHIRO_NAME`、`MOSHIRO_ENGINE=docker|podman`、`MOSHIRO_DRY_RUN=1`（只打印 run 命令）；Podman 会顺便启用 `podman-restart`。
 
-**用脚本部署和更新（Agent、Probe；推荐用 Quadlet，Backend 只有 Quadlet 和 compose）**：`packaging/container/deploy-node.sh` 可以重复运行，每次都会拉取镜像并固定到 digest、把配置迁移到当前版本需要的样子（例如旧的 `listen.bind` 为 `0.0.0.0` 的 Agent 改成 `::`，这样 IPv6 线路才能建立）、重装单元和更新器，然后重启节点；已有的身份不会动，更新策略沿用上次的。
+用脚本部署和更新（Agent、Probe；推荐用 Quadlet，Backend 只有 Quadlet 和 compose）：`packaging/container/deploy-node.sh` 可以重复运行，每次都会拉取镜像并固定到 digest、把配置迁移到当前版本需要的样子（例如旧的 `listen.bind` 为 `0.0.0.0` 的 Agent 改成 `::`，这样 IPv6 线路才能建立）、重装单元和更新器，然后重启节点；已有的身份不会动，更新策略沿用上次的。
 
 ```sh
 # 首次部署（需要 root；脚本和 packaging/ 里的 systemd/、update/ 放在一起）
@@ -310,8 +310,8 @@ Backend 用 `packaging/compose/backend/compose.yaml`（见上文「Backend 容
 
 Agent 和 Probe 每天固定时刻有序退出一次，由服务管理器拉起（所有 systemd 单元和 OpenWrt 的 procd 脚本都是「总是重启」，正常退出也会被拉起）。节点只是自己退出，没有任何执行命令的能力；重启期间测量会中断几十秒。
 
-- **在管理端控制**：系统 → 设置 →「定时重启」，开关、时刻和时区（默认**开**，北京时间 04:30）。保存后马上通知所有在线节点，新连上的节点会补发。
-- **节点本地覆盖**：节点本地写了就以本地为准（面板的设置对它不生效）。`agent.json` 或 `probe.json` 里加 `"restart_at": "04:30+08:00"`，或者设置环境变量 `MOSHIRO_RESTART_AT`（优先）。写法 `HH:mm`（按 UTC）、`HH:mmZ` 或 `HH:mm±hh:mm`；写错了启动时就会报错。Probe 的容器同样可以用环境变量。
+- 在管理端控制：系统 → 设置 →「定时重启」，开关、时刻和时区（默认开，北京时间 04:30）。保存后马上通知所有在线节点，新连上的节点会补发。
+- 节点本地覆盖：节点本地写了就以本地为准（面板的设置对它不生效）。`agent.json` 或 `probe.json` 里加 `"restart_at": "04:30+08:00"`，或者设置环境变量 `MOSHIRO_RESTART_AT`（优先）。写法 `HH:mm`（按 UTC）、`HH:mmZ` 或 `HH:mm±hh:mm`；写错了启动时就会报错。Probe 的容器同样可以用环境变量。
 - 启动后不满 10 分钟不会触发，所以重启之后不会立刻又重启一次。日志里有 `restart scheduled at=… source=panel|local` 和 `stopping result=scheduled_restart`。
 - Windows 上没有自带的服务单元，需要服务管理器配置为退出后重启。
 
@@ -334,7 +334,7 @@ Probe 也上报同样的汇总数字（`probe.json` 的 `reporting.host_stats`
 
 ## Podman（Quadlet）的更新（Agent、Probe、Backend，推荐）
 
-节点跑成一个 Podman Quadlet 单元（`packaging/quadlet/moshiro-agent.container`、`moshiro-probe.container`，Podman 4.6 及以上），更新是**销毁容器、重新拉最新镜像再启动**：节点自己不下载、不替换任何东西，只是有序退出；Quadlet 生成的 systemd 服务用 `podman run --pull always` 启动，所以被拉起时先从镜像仓库拉最新的镜像。**默认自动更新**：面板发现新版本后，节点运行满 10 分钟（防止重启循环）就自己退出重启；想改成在管理端点「更新」才更新，在 env 文件里写 `MOSHIRO_UPDATE_POLICY=manual`。
+节点跑成一个 Podman Quadlet 单元（`packaging/quadlet/moshiro-agent.container`、`moshiro-probe.container`，Podman 4.6 及以上），更新是销毁容器、重新拉最新镜像再启动：节点自己不下载、不替换任何东西，只是有序退出；Quadlet 生成的 systemd 服务用 `podman run --pull always` 启动，所以被拉起时先从镜像仓库拉最新的镜像。默认自动更新：面板发现新版本后，节点运行满 10 分钟（防止重启循环）就自己退出重启；想改成在管理端点「更新」才更新，在 env 文件里写 `MOSHIRO_UPDATE_POLICY=manual`。
 
 ```text
 CI 推镜像到 registry ─▶ 面板收到 CI 签名的清单 ─▶ 转发给节点（只是「建议」）
@@ -343,12 +343,12 @@ CI 推镜像到 registry ─▶ 面板收到 CI 签名的清单 ─▶ 转发给
 然后：systemd 重启单元（Pull=always）─▶ 新镜像、新容器
 ```
 
-- **安装**（rootless，普通用户）：管理端「添加 Agent / Probe」的第一条命令（Linux + Podman）就是它：env 写进 `~/.config/moshiro/<role>.env`（权限 600），从面板的 `/install/quadlet/<role>.container` 下载单元并核对 SHA-256，用一个 drop-in 把镜像仓库指向面板配置的（开发通道是 `moshiro-dev`），`systemctl --user start`。再让管理员执行一次 `loginctl enable-linger <用户>`。rootful 的路径和改法写在模板开头的注释里。身份和配置仍在命名卷 `moshiro-<role>-config`，换新镜像不丢。
-- **compose 不能自动更新**：compose 的 `restart: unless-stopped` 是引擎直接重启同一个容器，不会拉新镜像（`pull_policy: always` 只在 `compose up` 时生效），容器自己又没法重建自己，所以 compose（Docker）仍是手动 `compose pull && compose up -d`；要自动更新就用 Quadlet。
-- **信任**：信任镜像仓库（`registry.oeo.one`，Podman 校验它的 TLS 证书），并按标签拉取（默认 `latest`，想固定版本就把模板里的标签换成版本号）。节点不验证清单：它不安装任何东西，最多被管理员请求一次重启，和定时重启是同一种能力。
-- **只有设了 `MOSHIRO_UPDATE=restart` 的节点才报告更新状态**（模板里写好了）：别的部署方式退出之后不会重新拉取，开了也不会更新。
-- **别的自动更新方式**：另外启用 `podman-auto-update.timer` 并在模板的 `[Container]` 里加 `AutoUpdate=registry`，Podman 按计划比对镜像 digest 并重启，不依赖面板。
-- **回滚**：新镜像起不来时 systemd 一直重试；把模板里的标签改回旧版本再 `systemctl --user restart` 即可。
+- 安装（rootless，普通用户）：管理端「添加 Agent / Probe」的第一条命令（Linux + Podman）就是它：env 写进 `~/.config/moshiro/<role>.env`（权限 600），从面板的 `/install/quadlet/<role>.container` 下载单元并核对 SHA-256，用一个 drop-in 把镜像仓库指向面板配置的（开发通道是 `moshiro-dev`），`systemctl --user start`。再让管理员执行一次 `loginctl enable-linger <用户>`。rootful 的路径和改法写在模板开头的注释里。身份和配置仍在命名卷 `moshiro-<role>-config`，换新镜像不丢。
+- compose 不能自动更新：compose 的 `restart: unless-stopped` 是引擎直接重启同一个容器，不会拉新镜像（`pull_policy: always` 只在 `compose up` 时生效），容器自己又没法重建自己，所以 compose（Docker）仍是手动 `compose pull && compose up -d`；要自动更新就用 Quadlet。
+- 信任：信任镜像仓库（`registry.oeo.one`，Podman 校验它的 TLS 证书），并按标签拉取（默认 `latest`，想固定版本就把模板里的标签换成版本号）。节点不验证清单：它不安装任何东西，最多被管理员请求一次重启，和定时重启是同一种能力。
+- 只有设了 `MOSHIRO_UPDATE=restart` 的节点才报告更新状态（模板里写好了）：别的部署方式退出之后不会重新拉取，开了也不会更新。
+- 别的自动更新方式：另外启用 `podman-auto-update.timer` 并在模板的 `[Container]` 里加 `AutoUpdate=registry`，Podman 按计划比对镜像 digest 并重启，不依赖面板。
+- 回滚：新镜像起不来时 systemd 一直重试；把模板里的标签改回旧版本再 `systemctl --user restart` 即可。
 - 测试：`packaging/quadlet` 里的模板用 `/usr/libexec/podman/quadlet -dryrun -user` 检查过（Podman 5.4）；节点一侧的逻辑见 `RestartUpdaterTests`。
 
 ## 宿主机更新器（一行脚本装的节点）
@@ -375,9 +375,9 @@ sh packaging/update/install-updater.sh agent --user \
 
 发布私钥只放在 Woodpecker 的 `release_signing_key` secret；发布公钥位于 `packaging/update/release-key.pub.pem`。`RELEASE_API_URL` 指向面板，CI 把签名清单 POST 到 `/api/release/offer`：这个入口不需要令牌，面板用内嵌的发布公钥验签，签名无效就拒绝，所以 CI 不需要在面板里持有任何凭证（清库或重装后照常登记，也没有长期令牌可偷）。面板保存并转发签名清单，Agent/Probe 将它与更新请求写进配置 volume；更新器验签后才调用容器引擎和 systemd。管理端仍能看到可更新、更新中、已回滚和无效清单状态。纯二进制更新器尚未实现。
 
-**自有发布密钥**（自己构建、自己发布的部署；默认关闭）：管理端「系统 → 信任 → 可信资产来源」。官方 CI 发布密钥始终信任，不能关；另外导入**自己的发布公钥**（P-256 的 PEM，面板拒绝私钥，私钥留在你自己的机器或 CI 密钥库）之后，用你的私钥签的清单也会被面板登记和分发。签名方法：`openssl dgst -sha256 -sign release.key -out manifest.sig.bin manifest.json`，再 `base64 -w0` 得到签名；清单是一行扁平的 JSON（字段见 `ci/release-manifest.sh`），交给面板用 `POST /api/release/offer`，或者像官方那样放进你镜像仓库里的清单镜像。节点宿主机的更新器只认本机的公钥文件，所以用你自己的密钥发布时，还要把你的公钥放进这些节点的 `release-key.pub.pem`，并且清单里的 `image` 必须等于它本机配置的镜像仓库。停用自有密钥时，只有它签过的已登记清单会被丢掉。
+自有发布密钥（自己构建、自己发布的部署；默认关闭）：管理端「系统 → 信任 → 可信资产来源」。官方 CI 发布密钥始终信任，不能关；另外导入自己的发布公钥（P-256 的 PEM，面板拒绝私钥，私钥留在你自己的机器或 CI 密钥库）之后，用你的私钥签的清单也会被面板登记和分发。签名方法：`openssl dgst -sha256 -sign release.key -out manifest.sig.bin manifest.json`，再 `base64 -w0` 得到签名；清单是一行扁平的 JSON（字段见 `ci/release-manifest.sh`），交给面板用 `POST /api/release/offer`，或者像官方那样放进你镜像仓库里的清单镜像。节点宿主机的更新器只认本机的公钥文件，所以用你自己的密钥发布时，还要把你的公钥放进这些节点的 `release-key.pub.pem`，并且清单里的 `image` 必须等于它本机配置的镜像仓库。停用自有密钥时，只有它签过的已登记清单会被丢掉。
 
-**换发布密钥**（泄露或定期轮换，不用重装节点）：
+换发布密钥（泄露或定期轮换，不用重装节点）：
 
 1. 生成新密钥对；CI 给发布流水线加 `RELEASE_NEXT_KEY`（新公钥 PEM），仍用旧私钥签名。清单里会带 `next_key`（SPKI DER 的 base64）。
 2. 宿主机更新器验过这份清单后，把新公钥存到自己的状态目录（`<组件>.key.pem`），之后只认新密钥，旧密钥签的清单一律拒绝。清单里的 `next_key` 不是合法公钥就整份拒绝。
@@ -388,7 +388,7 @@ sh packaging/update/install-updater.sh agent --user \
 
 ## 签名清单放在镜像仓库里（更新和首次部署都不依赖面板）
 
-CI 给每个镜像的 digest 签名之后，除了（面板在线时）登记给面板，**一定会把签名清单推到镜像仓库**：`<镜像仓库>-manifest:<通道>`，例如 `registry.oeo.one/moshiro-dev/moshiro-backend-manifest:dev`、`registry.oeo.one/moshiro/moshiro-backend-manifest:release`。它是一个没有任何文件层的小镜像，清单和签名放在标签 `org.moshiro.manifest`（base64）和 `org.moshiro.signature` 里。`dev` 通道每次 `[CI]` 构建都会更新，`release` 通道只在打 tag 时更新，所以不发 Release 的构建照样能被更新到。
+CI 给每个镜像的 digest 签名之后，除了（面板在线时）登记给面板，一定会把签名清单推到镜像仓库：`<镜像仓库>-manifest:<通道>`，例如 `registry.oeo.one/moshiro-dev/moshiro-backend-manifest:dev`、`registry.oeo.one/moshiro/moshiro-backend-manifest:release`。它是一个没有任何文件层的小镜像，清单和签名放在标签 `org.moshiro.manifest`（base64）和 `org.moshiro.signature` 里。`dev` 通道每次 `[CI]` 构建都会更新，`release` 通道只在打 tag 时更新，所以不发 Release 的构建照样能被更新到。
 
 ```text
  信任锚点：仓库里的发布公钥 packaging/update/release-key.pub.pem（随安装脚本和 deploy-node.sh 分发）
@@ -396,20 +396,20 @@ CI 给每个镜像的 digest 签名之后，除了（面板在线时）登记给
  仓库、网络、面板都不需要可信：被改只会让验签失败；面板不在线、清库、没有 CI 都不影响
 ```
 
-- **更新器**：配置里 `FEED=auto`（默认）时先看仓库里的清单，验签通过才用；取不到或验不过就用面板放进信箱的那份。`MANIFEST_REF` 可以指定清单镜像，`FEED=off` 关掉；通道取配置里的 `CHANNEL`，没有就按仓库路径推断（`moshiro-dev` → dev，`moshiro` → release）。仓库里的清单验签失败而信箱里又没有东西时，状态会报「无效清单」而不是悄悄当作没有更新。
-- **面板自己取**：安装脚本向面板要某个组件的签名清单时，面板里没有（清过库、CI 登记那一步网络失败）或者已经放了十分钟以上，面板就按 OCI 分发协议**匿名**读一次仓库里的清单镜像（只读清单和它的配置两个小 JSON，不拉镜像层），用内嵌的 CI 发布公钥验过签才登记；验不过（仓库或路上被改）就当没有。所以清库之后不用手工补登记，也不会被一份伪造的清单骗到。后台还每 5 分钟替 Agent、Probe 和 Backend 自己各取一次：CI 把清单登记给面板那一步是尽力而为的（网络不通只警告，流水线仍是绿的），没有这个后台轮询的话，面板收不到登记就看不到 Backend 的新版，宿主机上旧版的更新器也就一直报「最新」。仓库要匿名可读（`moshiro/**`、`moshiro-dev/**`）。
-- **发版**：打 `vMAJOR.MINOR.PATCH` tag 时，节点镜像（Agent、Probe 的多架构镜像）也和 Backend 一样签清单，放到 `moshiro/…-manifest:release`。
-- **压缩包的校验和也签名**：Release 里除了每个压缩包的 `.sha256`，还有汇总的 `SHA256SUMS` 和 `SHA256SUMS.sig`（用发布私钥签，base64 的 DER ECDSA P-256，和清单同一把密钥）。验证：`base64 -d SHA256SUMS.sig > s.bin && openssl dgst -sha256 -verify packaging/update/release-key.pub.pem -signature s.bin SHA256SUMS`，通过之后再 `sha256sum -c SHA256SUMS`。macOS 的 Developer ID 签名和公证、Windows 的 Authenticode 需要苹果和微软的证书，目前没有做。
-- **首次部署**：`deploy-node.sh` 默认就走这条路，不需要面板，也不用手动指定镜像（Backend 第一次部署时本来就没有面板）。`--tag` 指定标签时不验签并有警告；`--image` 直接用你给的引用。
-- **别人自己部署后端，什么都不用改**：仓库对匿名读开放（`moshiro/*` 和各 `*-manifest` 仓库），然后按 `packaging/quadlet/moshiro-backend.container` 的说明装 Backend（`MoShiro__PublicUrl` 写自己的域名），只是配置，不改代码、不需要自己的 CI；passkey 绑定在自己的域名上。自己 fork 并自建镜像的人要换自己的发布公钥和仓库地址（`--image-repo`）并重新构建，这是 fork 的正常代价。
+- 更新器：配置里 `FEED=auto`（默认）时先看仓库里的清单，验签通过才用；取不到或验不过就用面板放进信箱的那份。`MANIFEST_REF` 可以指定清单镜像，`FEED=off` 关掉；通道取配置里的 `CHANNEL`，没有就按仓库路径推断（`moshiro-dev` → dev，`moshiro` → release）。仓库里的清单验签失败而信箱里又没有东西时，状态会报「无效清单」而不是悄悄当作没有更新。
+- 面板自己取：安装脚本向面板要某个组件的签名清单时，面板里没有（清过库、CI 登记那一步网络失败）或者已经放了十分钟以上，面板就按 OCI 分发协议匿名读一次仓库里的清单镜像（只读清单和它的配置两个小 JSON，不拉镜像层），用内嵌的 CI 发布公钥验过签才登记；验不过（仓库或路上被改）就当没有。所以清库之后不用手工补登记，也不会被一份伪造的清单骗到。后台还每 5 分钟替 Agent、Probe 和 Backend 自己各取一次：CI 把清单登记给面板那一步是尽力而为的（网络不通只警告，流水线仍是绿的），没有这个后台轮询的话，面板收不到登记就看不到 Backend 的新版，宿主机上旧版的更新器也就一直报「最新」。仓库要匿名可读（`moshiro/`、`moshiro-dev/`）。
+- 发版：打 `vMAJOR.MINOR.PATCH` tag 时，节点镜像（Agent、Probe 的多架构镜像）也和 Backend 一样签清单，放到 `moshiro/…-manifest:release`。
+- 压缩包的校验和也签名：Release 里除了每个压缩包的 `.sha256`，还有汇总的 `SHA256SUMS` 和 `SHA256SUMS.sig`（用发布私钥签，base64 的 DER ECDSA P-256，和清单同一把密钥）。验证：`base64 -d SHA256SUMS.sig > s.bin && openssl dgst -sha256 -verify packaging/update/release-key.pub.pem -signature s.bin SHA256SUMS`，通过之后再 `sha256sum -c SHA256SUMS`。macOS 的 Developer ID 签名和公证、Windows 的 Authenticode 需要苹果和微软的证书，目前没有做。
+- 首次部署：`deploy-node.sh` 默认就走这条路，不需要面板，也不用手动指定镜像（Backend 第一次部署时本来就没有面板）。`--tag` 指定标签时不验签并有警告；`--image` 直接用你给的引用。
+- 别人自己部署后端，什么都不用改：仓库对匿名读开放（`moshiro/*` 和各 `*-manifest` 仓库），然后按 `packaging/quadlet/moshiro-backend.container` 的说明装 Backend（`MoShiro__PublicUrl` 写自己的域名），只是配置，不改代码、不需要自己的 CI；passkey 绑定在自己的域名上。自己 fork 并自建镜像的人要换自己的发布公钥和仓库地址（`--image-repo`）并重新构建，这是 fork 的正常代价。
 - 测试：`bash packaging/update/tests/feed-test.sh`（假的 podman + 真的 openssl，覆盖篡改、别的密钥、旧 seq、换钥、仓库不可用回退、首次部署的验签）。
 
 ## Backend 的更新
 
 Backend 和节点是同一种更新：`packaging/quadlet/moshiro-backend.container`（Quadlet，`Pull=always`、`Restart=always`、`Environment=MOSHIRO_UPDATE=restart`）。CI 推镜像并把 CI 签名的清单登记到面板，管理端显示「Backend 有新版本」，管理员点「更新并重启」（`POST /api/admin/backend/update`，带当时登记的清单 `seq`，清单变了就要重新确认）；Backend 先把数据库备份到数据卷的 `backups/pre-update-<时间>-<seq>.db`（`VACUUM INTO`，保留最近 3 份，备份失败就不更新），再有序退出，systemd 重启单元并拉最新镜像。
 
-- **不自动重启**：Backend 指挥所有节点，重启会让它们全部断一两分钟，所以只提示，不像节点默认那样自动退出。
-- **没有 `MOSHIRO_UPDATE=restart` 就不能从管理端更新**（compose、一行脚本装的 Backend 没有重新拉取的机制），管理端会提示；这种部署继续用 `compose pull && compose up -d`。
-- **通道**：`MoShiro__UpdateChannel` 为 `auto` 时，镜像命名空间 `moshiro-dev` 选 `dev`，`moshiro` 选 `release`；没写命名空间就按当前运行的构建 tag 判断。
-- **回滚**：新版启动时会迁移数据库，旧版不认比自己新的库。要回旧版：停服务，把 `backups/pre-update-*.db` 复制成数据卷里的 `moshiro.db`（删掉旧的 `-wal`、`-shm`），把单元里的标签固定成旧版本号再启动。新版起不来时 systemd 会一直重试同一个镜像，没有自动回滚，也没有 `/healthz` 的探针（镜像里没有 curl）。
-- **首次升级**：还没有这个机制的旧版 Backend 不认 `MOSHIRO_UPDATE`，第一次要手动 `systemctl --user restart moshiro-backend`（Pull=always 拉到新镜像），之后就能从管理端更新。
+- 不自动重启：Backend 指挥所有节点，重启会让它们全部断一两分钟，所以只提示，不像节点默认那样自动退出。
+- 没有 `MOSHIRO_UPDATE=restart` 就不能从管理端更新（compose、一行脚本装的 Backend 没有重新拉取的机制），管理端会提示；这种部署继续用 `compose pull && compose up -d`。
+- 通道：`MoShiro__UpdateChannel` 为 `auto` 时，镜像命名空间 `moshiro-dev` 选 `dev`，`moshiro` 选 `release`；没写命名空间就按当前运行的构建 tag 判断。
+- 回滚：新版启动时会迁移数据库，旧版不认比自己新的库。要回旧版：停服务，把 `backups/pre-update-*.db` 复制成数据卷里的 `moshiro.db`（删掉旧的 `-wal`、`-shm`），把单元里的标签固定成旧版本号再启动。新版起不来时 systemd 会一直重试同一个镜像，没有自动回滚，也没有 `/healthz` 的探针（镜像里没有 curl）。
+- 首次升级：还没有这个机制的旧版 Backend 不认 `MOSHIRO_UPDATE`，第一次要手动 `systemctl --user restart moshiro-backend`（Pull=always 拉到新镜像），之后就能从管理端更新。