refactor!: rename the project from Monitor to MoShiro

Namespaces, assemblies, projects and directories, the solution, binaries,
images, systemd units, config paths, environment variables, protocol method
names, the media type and the raw chunk magic all move to MoShiro/moshiro.
Existing data and deployments are not compatible and must be recreated.
Also fix the architecture tests after the solution layout change and make
the update tests independent of their order.

docs/analysis.md

@@ -135,7 +135,7 @@ chunk 入库 ─┬─> 流式路径：按 1s 桶计算累加器 → 热层环
 ## 9. 项目结构
 
 ```text
-backend/src/Monitor.Backend.Analysis/     依赖：Monitor.Protocol、Fleet.Core（纯计算，没有 I/O）
+backend/src/MoShiro.Backend.Analysis/     依赖：MoShiro.Protocol、Fleet.Core（纯计算，没有 I/O）
 ├─ Accumulators/  Counter Ratio Sum Min Max Histogram RunLength Series + AccumulatorCodec
 ├─ Ops/           Rtt Loss OwdVar LossRuns Reorder Gap KernelDelta Rate PhaseMs Outcome ChangePoint
 ├─ Metrics/       LinkMetrics TcpMetrics UdpTrainMetrics ConnectMetrics …（只包含声明）
@@ -144,4 +144,4 @@ backend/src/Monitor.Backend.Analysis/     依赖：Monitor.Protocol、Fleet.Core
 └─ Clock/         ClockDriftFit（估计两端的时钟偏移和漂移）
 ```
 
-分析库没有 I/O，可以直接用于离线 CLI `tools/monitor-analyze`，对下载的原始块做实验。
+分析库没有 I/O，可以直接用于离线 CLI `tools/moshiro-analyze`，对下载的原始块做实验。

docs/api-guidelines.md

@@ -16,7 +16,7 @@ web：openapi-typescript 生成类型，调用方的类型错误会直接暴露
 
 - 端点**必须**声明精确的返回类型，例如 `Results<Ok<AgentDto>, NotFound<ProblemDetails>>`，不能返回 `IResult` 或匿名对象，否则 OpenAPI 文档会不准确。
 - 每个端点都必须设置 `WithName("agents_list")`（即 operationId，snake_case、`资源_动作`）、`WithSummary`、`WithTags`。
-- 请求和响应 DTO 放在 `Monitor.Backend.Api/Contracts/`，并注册到 Backend 的 JSON 源生成上下文。**不要直接暴露 `Monitor.Protocol` 中的线协议类型**，因为 REST 与线协议的演进节奏不同。
+- 请求和响应 DTO 放在 `MoShiro.Backend.Api/Contracts/`，并注册到 Backend 的 JSON 源生成上下文。**不要直接暴露 `MoShiro.Protocol` 中的线协议类型**，因为 REST 与线协议的演进节奏不同。
 - **结构强类型，指标弱类型**：资源结构（Agent、任务、测试等）必须是强类型 DTO；而**指标值和评分**统一使用字典 `metrics: { "<metric_id>": number }`、`scores: { "<model_id>": number }`，键的含义、单位、版本由 `/api/public/catalog/*` 给出。这样新增指标或模型不需要改 OpenAPI，也不需要改前端类型。
 
 ## 2. 版本与兼容性

docs/api.md

@@ -95,7 +95,7 @@
 `GET /api/public/about`：`{show_build, backend}`。`show_build` 关着时 `backend` 是 `null`；打开后 `backend` 是 `{version, tag, built_at}`（后端自己的版本、tag、构建时间，不含提交号）。
 
 - 系统和架构是节点自报的：Agent 和 Probe 都在各自连面板时的 `fleet.hello` 里自报。只有粗粒度的名字，没有主机名、内核版本、CPU 型号。
-- 国家和运营商由 **Backend** 用节点的来源地址向 IP 归属服务查一次（`Monitor__GeoLookupUrl`，缺省 `https://ip.007995.xyz`，留空就不查）：Probe 用 Agent 看到的来源 IP，Agent 用它的公开地址。**Probe 和 Agent 不访问任何外部服务。** 只查公网地址（回环、内网、CGNAT、链路本地一律不发出去）；同一个地址一周内只查一次，失败 10 分钟后再试；查到的只留国家代码和运营商，地址只存在 Backend 内部的 `node_meta.geo_host`，不对外。
+- 国家和运营商由 **Backend** 用节点的来源地址向 IP 归属服务查一次（`MoShiro__GeoLookupUrl`，缺省 `https://ip.007995.xyz`，留空就不查）：Probe 用 Agent 看到的来源 IP，Agent 用它的公开地址。**Probe 和 Agent 不访问任何外部服务。** 只查公网地址（回环、内网、CGNAT、链路本地一律不发出去）；同一个地址一周内只查一次，失败 10 分钟后再试；查到的只留国家代码和运营商，地址只存在 Backend 内部的 `node_meta.geo_host`，不对外。
 
 ### 2.4 测试结果与目录
 
@@ -105,7 +105,7 @@
 
 ### 2.5 跨域访问
 
-默认前端和 Backend 同源（Cookie 会话）。前端在别的来源时（比如本机跑前端、连线上的 Backend），Backend 设 `Monitor__CorsOrigins`（逗号分隔的来源，或 `*`；默认空 = 不允许）。只对 `/api/*` 生效，响应带 `Access-Control-Allow-Origin`，预检请求（`OPTIONS`）返回 204，允许的头是 `Authorization, Content-Type, X-CSRF-Token`。**不带凭据**，Cookie 不会跨域，所以跨域的调用只能用 `Authorization: Bearer <API 令牌>`：展示端用只读令牌（站点私有时需要），管理端用 admin 范围的令牌（`/api/admin/auth/me` 对令牌同样可用）。SSE 在跨域时前端用 fetch 读流，因为 `EventSource` 带不了请求头。
+默认前端和 Backend 同源（Cookie 会话）。前端在别的来源时（比如本机跑前端、连线上的 Backend），Backend 设 `MoShiro__CorsOrigins`（逗号分隔的来源，或 `*`；默认空 = 不允许）。只对 `/api/*` 生效，响应带 `Access-Control-Allow-Origin`，预检请求（`OPTIONS`）返回 204，允许的头是 `Authorization, Content-Type, X-CSRF-Token`。**不带凭据**，Cookie 不会跨域，所以跨域的调用只能用 `Authorization: Bearer <API 令牌>`：展示端用只读令牌（站点私有时需要），管理端用 admin 范围的令牌（`/api/admin/auth/me` 对令牌同样可用）。SSE 在跨域时前端用 fetch 读流，因为 `EventSource` 带不了请求头。
 
 ## 3. Admin API
 
@@ -130,7 +130,7 @@
 | POST | `/api/admin/lines/{line_id}/tests` | `{plan, params?}` → **202** + `Location: /api/public/tests/{id}`；Probe 离线时返回 409 `probe_offline`，节点繁忙时返回 409 `test_busy` |
 | POST | `/api/admin/tests/{id}/cancel` | |
 | GET | `/api/admin/raw/chunks?agent_id=&kind=&from=&to=&test_id=` | 原始块元数据 |
-| GET | `/api/admin/raw/chunks/{chunk_id}` | 下载原始块（`application/vnd.monitor.rawchunk`）；过期返回 410 `raw_expired` |
+| GET | `/api/admin/raw/chunks/{chunk_id}` | 下载原始块（`application/vnd.moshiro.rawchunk`）；过期返回 410 `raw_expired` |
 | GET | `/api/admin/events?agent_id=&kind=&from=&to=` | 事件 |
 | GET | `/api/admin/analysis/recompute` | 指标重算进度 |
 | GET/POST/DELETE | `/api/admin/api-tokens` | 作用域为 `read`、`admin` 或 `release`（只能登记发布清单，给 CI 用，什么都读不了）；明文只显示一次 |
@@ -157,7 +157,7 @@
 | 方法 | 路径 | 说明 |
 | --- | --- | --- |
 | POST | `/api/agent/v1/enroll` | 由 `MapFleetEnrollment` 提供（使用加入令牌认证），见 [fleet/link.md](fleet/link.md) 第 3 节 |
-| GET | `/api/agent/v1/rpc` | 由 `MapFleetLink` 提供，升级为 WebSocket；Monitor 的方法见 [protocol.md](protocol.md) |
+| GET | `/api/agent/v1/rpc` | 由 `MapFleetLink` 提供，升级为 WebSocket；MoShiro 的方法见 [protocol.md](protocol.md) |
 | GET | `/fleet/releases/{app}/{channel}/latest.json`、`/fleet/releases/{app}/{version}/…` | 由 `MapFleetReleases` 提供的公开发布源（清单和制品），供 `fleet-updater` 轮询；也可以改用 GitHub Releases |
 
 ## 5. 运维端点

docs/architecture.md

@@ -53,13 +53,13 @@
 
 | 主题 | 要点 | 文档 |
 | --- | --- | --- |
-| 节点框架 | 注册、身份、连接、RPC、可靠上报、状态同步、宿主、更新都由与业务无关的 **Fleet** 提供；Monitor 只写业务，其他产品也能复用 | [fleet/overview.md](fleet/overview.md) |
+| 节点框架 | 注册、身份、连接、RPC、可靠上报、状态同步、宿主、更新都由与业务无关的 **Fleet** 提供；MoShiro 只写业务，其他产品也能复用 | [fleet/overview.md](fleet/overview.md) |
 | 注册与身份 | 使用 `fleet-enroll` 和加入令牌自动注册，之后用签名认证；Probe 用自己的身份直连面板，Agent 列表由面板下发 | [enrollment.md](enrollment.md) |
-| 更新 | 只接受发布密钥签名的清单，更新策略由节点本地决定，失败自动回滚。容器节点（Agent、Probe）已实现：CI 对镜像 digest 签名，宿主机上的 `monitor-update` 验签、按 digest 拉取、重启；纯二进制的 `fleet-updater` 还只是设计 | [deployment.md](deployment.md)、[fleet/update.md](fleet/update.md) |
+| 更新 | 只接受发布密钥签名的清单，更新策略由节点本地决定，失败自动回滚。容器节点（Agent、Probe）已实现：CI 对镜像 digest 签名，宿主机上的 `moshiro-update` 验签、按 digest 拉取、重启；纯二进制的 `fleet-updater` 还只是设计 | [deployment.md](deployment.md)、[fleet/update.md](fleet/update.md) |
 | 任务模型 | `Task = {kind, target, params, schedule}`；持续采集、按需测试、目标任务统一建模；下发“期望任务集”，由节点自行调和 | [measurement.md](measurement.md) |
 | 采集扩展 | Kind 由积木组合声明；采集密度靠参数调整；原始块自描述 | [measurement.md](measurement.md) |
 | 统计扩展 | 指标注册制：少数几种累加器 + 统计算子；一行 `MetricDef` 就是一个新指标 | [analysis.md](analysis.md) |
-| 协议 | 控制链路使用 Fleet（JSON-RPC 2.0 + 二进制通道）；Monitor 只定义 `monitor.*` 方法、`TaskSet` 状态文档和 UDP/TCP 数据面 | [protocol.md](protocol.md) |
+| 协议 | 控制链路使用 Fleet（JSON-RPC 2.0 + 二进制通道）；MoShiro 只定义 `moshiro.*` 方法、`TaskSet` 状态文档和 UDP/TCP 数据面 | [protocol.md](protocol.md) |
 | 存储 | 原始块追加写入段文件，SQLite 记录偏移量；指标窗口通用存储并降采样 | [storage.md](storage.md) |
 | 展示查询 | 任意时间段（相对或绝对）；自动步长（每条曲线最多约 720 个点）；1s 内存热层（1 小时）加上 10s/1m/5m/1h 各层；累加器现场合并，汇总精确；列式响应；SSE 实时跟随 | [query.md](query.md) |
 | API | `/api/public`（只读，可设为公开）、`/api/admin`（登录）、`/api/agent`（注册与 RPC）；实时数据用 SSE | [api.md](api.md) |
@@ -70,7 +70,7 @@
 CI ──签名的发布清单（镜像 digest）──▶ Backend ──原样转发（offer）──▶ Agent / Probe 进程
                                                                       │ 只写进数据目录的 update/
                                                                       ▼
-宿主机 monitor-update（root）：用本机公钥验签 → 核对组件、仓库和 seq → podman pull 仓库@digest → 重启 → 不健康就回滚
+宿主机 moshiro-update（root）：用本机公钥验签 → 核对组件、仓库和 seq → podman pull 仓库@digest → 重启 → 不健康就回滚
                                                                       │ 状态写进只读的 update-status/
                                                                       ▼
                                              节点随心跳上报更新状态 ──▶ Backend ──▶ 管理端（有新版本时点「更新」）
@@ -97,13 +97,13 @@ Agent / Probe 能做的   执行编译在二进制中的 Kind；监听和访问
 
 - **本地硬上限**写在节点本机的配置文件中，Backend 下发的任务如果超出，节点直接拒绝：允许访问的目标网段（默认为空，即不开放目标任务）、总码率和包速率上限、允许监听的端口。
 - **构建期强制**：常驻节点进程使用 `BannedSymbols.Node.txt`，禁用 `System.Diagnostics.Process`、`Assembly.Load*`、`NativeLibrary.Load`、`HttpClient`，以及 `ConfigStore` 以外的文件写入 API，详见 [project-layout.md](project-layout.md) 第 7 节。
-- **权限分离**：注册（`fleet-enroll`，一次性运行）、采集（`monitor-agent` / `monitor-probe`）、更新是不同的进程。容器节点里，采集进程在容器内以 UID 1654 运行（只读文件系统、不带额外能力），更新由宿主机上 root 运行的 `monitor-update` 完成：它只读取节点放进 `update/` 的普通文件、复制到自己的临时目录后验签，状态写在节点只读的 `update-status/`；采集进程改写不了自己的二进制，更新器也读不到节点身份私钥。纯二进制安装的 `fleet-updater` 还只是设计。
+- **权限分离**：注册（`fleet-enroll`，一次性运行）、采集（`moshiro-agent` / `moshiro-probe`）、更新是不同的进程。容器节点里，采集进程在容器内以 UID 1654 运行（只读文件系统、不带额外能力），更新由宿主机上 root 运行的 `moshiro-update` 完成：它只读取节点放进 `update/` 的普通文件、复制到自己的临时目录后验签，状态写在节点只读的 `update-status/`；采集进程改写不了自己的二进制，更新器也读不到节点身份私钥。纯二进制安装的 `fleet-updater` 还只是设计。
 - **容器运行**：Agent、Probe 的镜像基于 Alpine（musl，NativeAOT），宿主机用 rootful podman 加 systemd 运行：UID/GID 1654、只读文件系统、`--cap-drop all`、`no-new-privileges`、`/tmp` 用 tmpfs；配置和身份放在挂载的数据目录里。
 - **最小权限运行**：非 root 用户；只在需要时授予 `CAP_NET_RAW`（ICMP）；默认端口都高于 1024，不需要 `CAP_NET_BIND_SERVICE`，只有在 Agent 本地显式开启 443 时才授予。
 - **身份**：节点使用本地生成的 ECDSA P-256 密钥对签名认证（Probe 的密钥由面板生成、只返回一次，同一把用来连面板和连 Agent），Backend 只存公钥，数据库泄露也无法冒充节点。
 - **防放大**：未认证的包静默丢弃；回复长度与请求相等；每个流按声明速率限速；使用重放窗口。
 - **容器里的主机指标**：容器里的 Agent 通过只读挂载宿主机的 `/proc`、`/sys`、根目录和 `/etc/os-release`（环境变量 `HOST_PROC`、`HOST_SYS`、`HOST_ROOT`）读取宿主机的资源占用和系统名；读不到的项返回空值，不会退回去读容器自己的数据。Probe 只需要挂载 `/etc/os-release`。
-- **自身状态**：节点上报进程内的计数（会话数、包速率、队列、丢弃数）；Agent 另外每隔几秒用 `monitor.host` 上报一份主机资源占用的汇总数字（可以在 `agent.json` 里用 `reporting.host_stats = false` 整个关掉），最新值实时推给展示页，Backend 每分钟存一个样本（默认保留 7 天，`retention.host_days`）。
+- **自身状态**：节点上报进程内的计数（会话数、包速率、队列、丢弃数）；Agent 另外每隔几秒用 `moshiro.host` 上报一份主机资源占用的汇总数字（可以在 `agent.json` 里用 `reporting.host_stats = false` 整个关掉），最新值实时推给展示页，Backend 每分钟存一个样本（默认保留 7 天，`retention.host_days`）。
 
 ## 6. 可扩展性目标
 
@@ -119,7 +119,7 @@ Kind 目录编译在二进制中，节点不接受远程下发代码（安全边
 
 ## 7. 可靠性与资源
 
-- Probe：每个 Agent 未交付的原始列 ≤ 8 MB；Agent：上传队列 ≤ 64 MB，满时丢弃最旧的块，并通过 `monitor.event(gap)` 上报缺口。
+- Probe：每个 Agent 未交付的原始列 ≤ 8 MB；Agent：上传队列 ≤ 64 MB，满时丢弃最旧的块，并通过 `moshiro.event(gap)` 上报缺口。
 - 至少一次投递：Backend 持久化之后才回复 ACK，按 `chunk_id` 去重。
 - 节点重启会丢失未上传的数据，并体现为数据缺口。
 - 窗口时间以 Agent 时钟为准；时钟偏差超过 5 秒时记录告警事件。
@@ -144,7 +144,7 @@ Kind 目录编译在二进制中，节点不接受远程下发代码（安全边
 | D13 | Probe/Agent 运行时只依赖 BCL；.NET 10 NativeAOT | 轻量 |
 | D14 | 节点机制抽成与业务无关的 Fleet 框架，放在同一仓库的 `backend/fleet/` 目录，暂不独立（由用户确认；不设拆分时间表，需要时再评估；不使用 PublicApiAnalyzers） | 可复用；`samples/EchoNode` 作为第二个使用者，防止过度设计 |
 | D15 | 注册独立为 `fleet-enroll` 工具；常驻进程不包含注册代码 | 常驻进程去掉 HttpClient，边界更纯 |
-| D16 | 更新与业务进程分离：发布密钥签名、本地策略、健康确认与回滚。容器节点已实现（宿主机 `monitor-update`，清单里是镜像 digest）；纯二进制的 `fleet-updater` 待做 | 面板被攻破时也无法推送恶意二进制；可以同时管理多个产品 |
+| D16 | 更新与业务进程分离：发布密钥签名、本地策略、健康确认与回滚。容器节点已实现（宿主机 `moshiro-update`，清单里是镜像 digest）；纯二进制的 `fleet-updater` 待做 | 面板被攻破时也无法推送恶意二进制；可以同时管理多个产品 |
 | D17 | Probe 支持 OpenWrt：正式支持 `linux-musl-x64`、`linux-musl-arm64`；armv7 视工具链验证结果决定；MIPS 不支持，改为在局域网设备上运行 Probe | 由用户确认；NativeAOT 不支持 MIPS |
 | D18 | 默认测量端口不使用 443：控制 7443/tcp，UDP 数据 7443/udp，TCP 数据 7444/tcp；443 只在 Agent 本地显式开启时才允许使用 | 由用户确认；避免与 VPS 上的真实服务冲突；结果会记录实际端口 |
 | D19 | 展示查询最细 1s：最近 1 小时来自内存热层，更早的数据来自 10s/1m/5m/1h 各层，现场合并；时间段内的汇总由累加器精确合并得出 | 由用户确认；5 分钟、15 分钟这类视图足够精细且快 |

docs/coding-style.md

@@ -5,7 +5,7 @@
 ## 1. 格式与命名（`.editorconfig` 强制）
 
 - 使用 Allman 大括号（左大括号独占一行），四空格缩进，不使用 Tab；`if`/`for` 等语句必须加大括号。
-- 使用文件作用域 namespace；namespace 与目录一致（`Monitor.Agent.Sessions` 对应 `Sessions/`）。
+- 使用文件作用域 namespace；namespace 与目录一致（`MoShiro.Agent.Sessions` 对应 `Sessions/`）。
 - `using` 放在文件顶部、namespace 之外，`System.*` 排在最前面，其余按字母排序。
 - 始终显式写出可见性，并且放在修饰符的第一位；`static readonly` 的顺序固定。
 
@@ -82,8 +82,8 @@
 
 ## 9.1 Fleet 的通用性
 
-- `backend/fleet/**` 不能引用任何 `Monitor.*`，也不能出现产品相关的概念、命名或默认值（例如端口 7443、`monitor` 字样），由 `scripts/check-deps` 和代码评审把关。
-- Fleet 的每个公开 API 都要在 `samples/EchoNode` 或 `EchoServer` 中有用法。新增的公开 API 如果只有 Monitor 使用，应先放在 Monitor 中，等出现第二个使用者后再下沉到 Fleet。
+- `backend/fleet/**` 不能引用任何 `MoShiro.*`，也不能出现产品相关的概念、命名或默认值（例如端口 7443、`moshiro` 字样），由 `scripts/check-deps` 和代码评审把关。
+- Fleet 的每个公开 API 都要在 `samples/EchoNode` 或 `EchoServer` 中有用法。新增的公开 API 如果只有 MoShiro 使用，应先放在 MoShiro 中，等出现第二个使用者后再下沉到 Fleet。
 - Fleet 永远不提供 exec、shell、文件读写或远程下发代码的方法，这条规则不接受例外。
 - 公开 API 的变更记录在 `PublicAPI.Unshipped.txt` 中；PR 描述需要说明是否属于破坏性变更。
 
@@ -107,5 +107,5 @@
 ## 12. 提交与评审
 
 - 提交信息使用 `<范围>: <摘要>` 格式，范围取值为 `probe`、`agent`、`backend`、`shared`、`web`、`docs`、`scripts`。
-- 修改 `backend/shared/Monitor.Protocol` 的 PR 必须说明兼容性影响（新增字段、行为变化、需要升级版本）。
+- 修改 `backend/shared/MoShiro.Protocol` 的 PR 必须说明兼容性影响（新增字段、行为变化、需要升级版本）。
 - 修改 `backend/openapi/v1.json` 的 PR 必须按照 [api-guidelines.md](api-guidelines.md) 第 2 节判断是否属于破坏性变更。

docs/deployment.md

@@ -6,10 +6,10 @@
 
 ```text
 scripts/publish.sh <agent|probe|backend|fleet-enroll> <rid>      → backend/artifacts/publish/<project>/<rid>/
-scripts/package.sh <agent|probe> <rid>                           → backend/artifacts/packages/monitor-<role>-<version>-<rid>.tar.gz（附 .sha256）
+scripts/package.sh <agent|probe> <rid>                           → backend/artifacts/packages/moshiro-<role>-<version>-<rid>.tar.gz（附 .sha256）
 ```
 
-构建信息（程序里显示的 tag、提交、构建时间）：`publish.sh` 会用 `git describe --tags --always --dirty`、`git rev-parse` 和当前时间自动设置环境变量 `MONITOR_TAG`、`MONITOR_COMMIT`、`MONITOR_BUILT_AT`，直接用 `dotnet publish` 或 CI 构建时自己设置它们（容器镜像的 `*.NativeBuild.Containerfile` 用同名的 `--build-arg`，CI 脚本会传）；不设置就是空，本地构建照常可重复。版本号取自 `backend/Directory.Build.props` 的 `Version`。前端的信息由 `web/build-info.mjs` 在构建时写入（版本取自 `web/package.json`）。
+构建信息（程序里显示的 tag、提交、构建时间）：`publish.sh` 会用 `git describe --tags --always --dirty`、`git rev-parse` 和当前时间自动设置环境变量 `MOSHIRO_TAG`、`MOSHIRO_COMMIT`、`MOSHIRO_BUILT_AT`，直接用 `dotnet publish` 或 CI 构建时自己设置它们（容器镜像的 `*.NativeBuild.Containerfile` 用同名的 `--build-arg`，CI 脚本会传）；不设置就是空，本地构建照常可重复。版本号取自 `backend/Directory.Build.props` 的 `Version`。前端的信息由 `web/build-info.mjs` 在构建时写入（版本取自 `web/package.json`）。
 
 | rid | 目标 | 构建方式 |
 | --- | --- | --- |
@@ -24,15 +24,15 @@ macOS 的 Apple Silicon 产物带临时 ad-hoc 签名，Intel 产物未签名。
 
 ## Backend 容器
 
-Backend 使用 OCI 标准镜像，通过 `registry.oeo.one/monitor/monitor-backend:<version>` 分发，支持 `linux/amd64` 和 `linux/arm64`。容器使用 musl NativeAOT 单文件程序，基底为 `mcr.microsoft.com/dotnet/runtime-deps:10.0-alpine`，以非 root 用户运行，在 `8080/tcp` 提供 HTTP 服务；数据库和原始数据统一写入 `/data`。程序启用 InvariantGlobalization，无需 .NET 运行时或 ICU；时间查询使用 UTC。SQLite 从固定版本的官方源码编译并静态链接，不再随镜像携带 `libe_sqlite3.so`。将 `/data` 挂载为持久卷，并在反向代理处配置 HTTPS。
+Backend 使用 OCI 标准镜像，通过 `registry.oeo.one/moshiro/moshiro-backend:<version>` 分发，支持 `linux/amd64` 和 `linux/arm64`。容器使用 musl NativeAOT 单文件程序，基底为 `mcr.microsoft.com/dotnet/runtime-deps:10.0-alpine`，以非 root 用户运行，在 `8080/tcp` 提供 HTTP 服务；数据库和原始数据统一写入 `/data`。程序启用 InvariantGlobalization，无需 .NET 运行时或 ICU；时间查询使用 UTC。SQLite 从固定版本的官方源码编译并静态链接，不再随镜像携带 `libe_sqlite3.so`。将 `/data` 挂载为持久卷，并在反向代理处配置 HTTPS。
 
-在部署目录保存此仓库的 `compose.yaml`，先通过部署平台的环境变量或密钥管理设置 `MONITOR_ADMIN_PASSWORD`（可选设置 `MONITOR_ADMIN_USER`、`MONITOR_VERSION`），然后启动：
+在部署目录保存此仓库的 `compose.yaml`，先通过部署平台的环境变量或密钥管理设置 `MOSHIRO_ADMIN_PASSWORD`（可选设置 `MOSHIRO_ADMIN_USER`、`MOSHIRO_VERSION`），然后启动：
 
 ```sh
 docker compose up -d
 ```
 
-Compose 将容器端口只绑定到宿主机 `127.0.0.1:8080`，适合由同机 HTTPS 反向代理转发；数据保存在 Docker 命名卷 `monitor-data`。首次启动成功创建管理员后，改密应在管理端完成。
+Compose 将容器端口只绑定到宿主机 `127.0.0.1:8080`，适合由同机 HTTPS 反向代理转发；数据保存在 Docker 命名卷 `moshiro-data`。首次启动成功创建管理员后，改密应在管理端完成。
 
 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 文档在普通开发构建中生成。
 
@@ -50,30 +50,30 @@ Pull request 和 `dev` push 会运行 Backend tests；通过后，独立的 `web
 
 ### main 开发镜像
 
-`main` 上只有提交信息包含 `[CI]` 的 push 才构建镜像。合并 PR 时，请把 `[CI]` 放入 PR 标题或合并提交标题。Backend、Agent、Probe 的 Linux/amd64 镜像会并行构建，并推送到同一个 Zot Registry 下独立的 `monitor-dev/` 仓库：
+`main` 上只有提交信息包含 `[CI]` 的 push 才构建镜像。合并 PR 时，请把 `[CI]` 放入 PR 标题或合并提交标题。Backend、Agent、Probe 的 Linux/amd64 镜像会并行构建，并推送到同一个 Zot Registry 下独立的 `moshiro-dev/` 仓库：
 
 | 镜像 | 滚动标签 | 固定提交标签 |
 | --- | --- | --- |
-| Backend | `registry.oeo.one/monitor-dev/monitor-backend:latest` | `registry.oeo.one/monitor-dev/monitor-backend:dev-<12位SHA>` |
-| Agent | `registry.oeo.one/monitor-dev/monitor-agent:latest` | `registry.oeo.one/monitor-dev/monitor-agent:dev-<12位SHA>` |
-| Probe | `registry.oeo.one/monitor-dev/monitor-probe:latest` | `registry.oeo.one/monitor-dev/monitor-probe:dev-<12位SHA>` |
+| Backend | `registry.oeo.one/moshiro-dev/moshiro-backend:latest` | `registry.oeo.one/moshiro-dev/moshiro-backend:dev-<12位SHA>` |
+| Agent | `registry.oeo.one/moshiro-dev/moshiro-agent:latest` | `registry.oeo.one/moshiro-dev/moshiro-agent:dev-<12位SHA>` |
+| Probe | `registry.oeo.one/moshiro-dev/moshiro-probe:latest` | `registry.oeo.one/moshiro-dev/moshiro-probe:dev-<12位SHA>` |
 
-Dev 镜像目前仅支持 amd64；Agent/Probe 在 `sdk:10.0-alpine-aot` 中构建 `linux-musl-x64` 产物，运行基底为 `runtime-deps:10.0-alpine`。它们不创建 Gitea Release，也不修改正式版 `monitor/` 仓库中的标签。普通 main push 不会构建镜像。
+Dev 镜像目前仅支持 amd64；Agent/Probe 在 `sdk:10.0-alpine-aot` 中构建 `linux-musl-x64` 产物，运行基底为 `runtime-deps:10.0-alpine`。它们不创建 Gitea Release，也不修改正式版 `moshiro/` 仓库中的标签。普通 main push 不会构建镜像。
 
 ### 正式版发布
 
-推送匹配项目版本的 `vMAJOR.MINOR.PATCH` tag 会触发完整跨平台构建、正式 OCI 镜像推送和 Gitea Release。正式镜像使用 `registry.oeo.one/monitor/` 路径；Agent、Probe 提供 amd64 与 arm64 多架构标签，稳定版本更新正式仓库自己的 `latest`。这与 `monitor-dev/` 的 dev `latest` 相互独立。
+推送匹配项目版本的 `vMAJOR.MINOR.PATCH` tag 会触发完整跨平台构建、正式 OCI 镜像推送和 Gitea Release。正式镜像使用 `registry.oeo.one/moshiro/` 路径；Agent、Probe 提供 amd64 与 arm64 多架构标签，稳定版本更新正式仓库自己的 `latest`。这与 `moshiro-dev/` 的 dev `latest` 相互独立。
 
-Agent 和 Probe 镜像分别发布为 `registry.oeo.one/monitor/monitor-agent:<version>` 与 `registry.oeo.one/monitor/monitor-probe:<version>`，包含 amd64、arm64 多架构索引；也可指定 `:<version>-amd64` 或 `:<version>-arm64`。稳定版本同时更新 `latest`。镜像以非 root 用户（UID/GID 1654）运行，默认读取 `/etc/monitor/agent.json` 或 `/etc/monitor/probe.json`。运行容器时挂载对应配置目录；Probe 还会在该目录写入 `agents.json`，因此目录需可由 1654 用户写入。Agent、Probe 需使用宿主网络以保持节点端口和测量流量行为，并按需添加 `NET_RAW` 能力以执行 ICMP 测量：
+Agent 和 Probe 镜像分别发布为 `registry.oeo.one/moshiro/moshiro-agent:<version>` 与 `registry.oeo.one/moshiro/moshiro-probe:<version>`，包含 amd64、arm64 多架构索引；也可指定 `:<version>-amd64` 或 `:<version>-arm64`。稳定版本同时更新 `latest`。镜像以非 root 用户（UID/GID 1654）运行，默认读取 `/etc/moshiro/agent.json` 或 `/etc/moshiro/probe.json`。运行容器时挂载对应配置目录；Probe 还会在该目录写入 `agents.json`，因此目录需可由 1654 用户写入。Agent、Probe 需使用宿主网络以保持节点端口和测量流量行为，并按需添加 `NET_RAW` 能力以执行 ICMP 测量：
 
 ```sh
-docker run -d --name monitor-agent --restart unless-stopped --network host \
-  --cap-add NET_RAW -v "$PWD/agent-config:/etc/monitor" \
-  registry.oeo.one/monitor/monitor-agent:<version>
+docker run -d --name moshiro-agent --restart unless-stopped --network host \
+  --cap-add NET_RAW -v "$PWD/agent-config:/etc/moshiro" \
+  registry.oeo.one/moshiro/moshiro-agent:<version>
 
-docker run -d --name monitor-probe --restart unless-stopped --network host \
-  --cap-add NET_RAW -v "$PWD/probe-config:/etc/monitor" \
-  registry.oeo.one/monitor/monitor-probe:<version>
+docker run -d --name moshiro-probe --restart unless-stopped --network host \
+  --cap-add NET_RAW -v "$PWD/probe-config:/etc/moshiro" \
+  registry.oeo.one/moshiro/moshiro-probe:<version>
 ```
 
 宿主机配置目录应允许 UID/GID 1654 读写；Probe 需要写权限来更新 `agents.json`。也可通过 Docker Compose 配置相同的网络、卷和能力。
@@ -86,8 +86,8 @@ Agent 和 Probe 的默认发布配置：NativeAOT、完整裁剪、`Optimization
 
 | 程序 | linux-musl-x64 | linux-x64 | win-x64 |
 | --- | --- | --- | --- |
-| monitor-probe | 7.7 MB | 7.7 MB | 5.6 MB |
-| monitor-agent | 8.4 MB | 8.4 MB | 7.3 MB |
+| moshiro-probe | 7.7 MB | 7.7 MB | 5.6 MB |
+| moshiro-agent | 8.4 MB | 8.4 MB | 7.3 MB |
 | fleet-enroll | 6.4 MB | 6.4 MB | — |
 
 Linux 上比 Windows 大，是因为 .NET 的加密、压缩、网络本机库被静态链接进来。tar.gz 压缩后 Probe 约 3.6 MB。
@@ -108,31 +108,31 @@ Linux 上比 Windows 大，是因为 .NET 的加密、压缩、网络本机库
 
 | 位置 | 内容 | 所有者 |
 | --- | --- | --- |
-| `/usr/lib/monitor/` | 二进制 | root，0755：采集进程不能改写自己的可执行文件 |
-| `/etc/monitor/` | `agent.json` 或 `probe.json`、身份（`node.json`、`node.key`、`tls.pfx`）、`agents.json` | `monitor` 用户，0750 |
+| `/usr/lib/moshiro/` | 二进制 | root，0755：采集进程不能改写自己的可执行文件 |
+| `/etc/moshiro/` | `agent.json` 或 `probe.json`、身份（`node.json`、`node.key`、`tls.pfx`）、`agents.json` | `moshiro` 用户，0750 |
 
-安装脚本会：检查 OpenSSL、创建 `monitor` 用户（`useradd`、busybox `adduser`，OpenWrt 没有这些时直接写 `/etc/passwd`）、安装二进制和服务文件；缺少配置时只安装、不启动，并打印下一步。
+安装脚本会：检查 OpenSSL、创建 `moshiro` 用户（`useradd`、busybox `adduser`，OpenWrt 没有这些时直接写 `/etc/passwd`）、安装二进制和服务文件；缺少配置时只安装、不启动，并打印下一步。
 
 ### systemd（`packaging/systemd/*.service`）
 
-以 `monitor` 用户运行，沙箱：`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）。
+以 `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/monitor` 只读；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+udp（Probe 控制通道和 UDP 数据面）、7444/tcp。
 
 ### OpenWrt（`packaging/openwrt/`）
 
-只支持 Probe（Agent 面向服务器）。`install.sh probe` 安装 `/etc/init.d/monitor-probe`（procd，崩溃自动重启，日志进 logd）并写入 `/lib/upgrade/keep.d/monitor`，sysupgrade 时保留 `/etc/monitor/`。
+只支持 Probe（Agent 面向服务器）。`install.sh probe` 安装 `/etc/init.d/moshiro-probe`（procd，崩溃自动重启，日志进 logd）并写入 `/lib/upgrade/keep.d/moshiro`，sysupgrade 时保留 `/etc/moshiro/`。
 
 OpenWrt 默认不带 OpenSSL：`opkg install libopenssl3`（较新的快照和 24.10 之后用 `apk add libopenssl3`）。闪存很小时注意：二进制 7.7 MB，配置只在 Agent 列表变化时才写。路由器上建议把 `probe.json` 的 `limits.max_test_mbps` 调低。
 
 ## 3. 验证
 
-`scripts/smoke-linux.sh` 在 Linux 容器里用发布的二进制跑完整链路（后端 → 注册 → Agent → Probe → 数据落库），`MODE=install` 用打包产物和 `install.sh` 安装、以 `monitor` 用户运行。`scripts/smoke-systemd.sh` 在 systemd 容器里验证服务单元。已经验证过：
+`scripts/smoke-linux.sh` 在 Linux 容器里用发布的二进制跑完整链路（后端 → 注册 → Agent → Probe → 数据落库），`MODE=install` 用打包产物和 `install.sh` 安装、以 `moshiro` 用户运行。`scripts/smoke-systemd.sh` 在 systemd 容器里验证服务单元。已经验证过：
 
 - Alpine 3.22（musl）、Debian 12（glibc）：直接运行和 `install.sh` 安装都通；
 - OpenWrt（官方 rootfs，busybox，无 `install`/`useradd`/`su`）：安装、建用户、卸载、二进制启动和 OpenSSL 自检；
-- systemd（Debian 12）：两个服务 active，Agent 只有 `CAP_NET_RAW`、Probe 没有 capability，`NoNewPrivs`、seccomp 生效，Agent 无法写 `/etc/monitor`，没有重启和错误日志。
+- systemd（Debian 12）：两个服务 active，Agent 只有 `CAP_NET_RAW`、Probe 没有 capability，`NoNewPrivs`、seccomp 生效，Agent 无法写 `/etc/moshiro`，没有重启和错误日志。
 
 没有验证的：arm64 构建、真正的 OpenWrt 设备（有 procd 和真实的内存/闪存限制）、跨公网的真实线路。
 
@@ -172,20 +172,20 @@ OpenWrt 默认不带 OpenSSL：`opkg install libopenssl3`（较新的快照和 2
 
 - **Backend 通过隧道暴露**：隧道把一个公网域名转到家宽机器的 `29181`；Backend 监听 `http://0.0.0.0:29181`（只写一个监听地址，同时写 `0.0.0.0` 和 `[::]` 会报地址已被占用），家宽路由器的防火墙不放行这个端口，公网只能经隧道进来。Agent 用 `fleet-enroll --server https://<公网域名>` 注册，之后用 WSS 连回 Backend。
 - **经隧道注册之后，检查 Agent 的 `public_host`**：Backend 看到的来源地址是隧道的出口，不是 VPS 的地址，要改成 VPS 的真实地址，Probe 才连得上。
-- **Probe 直连面板**：`probe.json` 里的 `server` 就是面板地址（取自 `Monitor__PublicUrl`，没配就用创建它时的请求地址），Probe 用它连面板，Agent 列表由面板下发；先注册还是先创建 Probe 都可以。
+- **Probe 直连面板**：`probe.json` 里的 `server` 就是面板地址（取自 `MoShiro__PublicUrl`，没配就用创建它时的请求地址），Probe 用它连面板，Agent 列表由面板下发；先注册还是先创建 Probe 都可以。
 - **小 VPS 把 `limits.max_total_mbps` 调低**（试跑时用 100）；Agent 常驻约 23 MB，VPS 上原有的服务不受影响，结束后删除 `/opt/…`、停掉进程即可，没有留下任何东西。
 - 家宽的 IPv6 前缀会在路由器重新拨号（比如停电）后变化，SSH 地址要跟着换；面板走隧道的域名，不受影响。
 - 本地电脑没有直连 VPS 的路径时，用家宽机器当跳板（`SSH_ASKPASS` + `SSH_ASKPASS_REQUIRE=force`，密码放环境变量，不写进文件）。
 
 **常驻（开机自启）**：
 
-- 家宽机器（没有 root 时）：`~/.config/systemd/user/monitor-backend.service` 和 `monitor-probe.service`，`EnvironmentFile` 指向放配置的 `backend.env`，`Restart=always`，`systemctl --user enable --now …`，再用 `sudo loginctl enable-linger <用户>` 让它们不登录也能起来。Probe 的命令行是 `monitor-probe --config <probe.json 路径>`（默认路径是 `/etc/monitor/probe.json`）。
-- VPS：`/etc/systemd/system/monitor-agent.service`，`Restart=always`，加 `NoNewPrivileges`、`ProtectSystem=strict`、`ReadWritePaths=/opt/monitor`、`ProtectHome`、`PrivateTmp`。这是不走安装脚本的手动方式；正式安装用上面的 `packaging/systemd`。
-- 日志进 journal：`journalctl -u monitor-agent`、`journalctl --user -u monitor-probe`。重启 Backend 用 `systemctl` 而不是手动再起一个进程，否则会端口冲突。
+- 家宽机器（没有 root 时）：`~/.config/systemd/user/moshiro-backend.service` 和 `moshiro-probe.service`，`EnvironmentFile` 指向放配置的 `backend.env`，`Restart=always`，`systemctl --user enable --now …`，再用 `sudo loginctl enable-linger <用户>` 让它们不登录也能起来。Probe 的命令行是 `moshiro-probe --config <probe.json 路径>`（默认路径是 `/etc/moshiro/probe.json`）。
+- VPS：`/etc/systemd/system/moshiro-agent.service`，`Restart=always`，加 `NoNewPrivileges`、`ProtectSystem=strict`、`ReadWritePaths=/opt/moshiro`、`ProtectHome`、`PrivateTmp`。这是不走安装脚本的手动方式；正式安装用上面的 `packaging/systemd`。
+- 日志进 journal：`journalctl -u moshiro-agent`、`journalctl --user -u moshiro-probe`。重启 Backend 用 `systemctl` 而不是手动再起一个进程，否则会端口冲突。
 
-**国家和运营商**：Backend 用 Probe、Agent 的来源地址向 IP 归属服务查一次，展示在国旗和运营商图标上（`Monitor__GeoLookupUrl`，缺省 `https://ip.007995.xyz`；留空就不查；这个服务只供公益使用，署名和使用条款由部署的人自己遵守）。Probe、Agent 自己不访问外部服务，所以客户的防火墙审计里不会多出出站连接；Backend 发出去的只有公网 IP（内网地址不发）。
+**国家和运营商**：Backend 用 Probe、Agent 的来源地址向 IP 归属服务查一次，展示在国旗和运营商图标上（`MoShiro__GeoLookupUrl`，缺省 `https://ip.007995.xyz`；留空就不查；这个服务只供公益使用，署名和使用条款由部署的人自己遵守）。Probe、Agent 自己不访问外部服务，所以客户的防火墙审计里不会多出出站连接；Backend 发出去的只有公网 IP（内网地址不发）。
 
-**从别处看这个面板**：本机跑前端，在页面里把数据源指向这个域名，用 API 令牌访问，Backend 设 `Monitor__CorsOrigins` 放行前端的来源（见 [web/README.md](../web/README.md)）。
+**从别处看这个面板**：本机跑前端，在页面里把数据源指向这个域名，用 API 令牌访问，Backend 设 `MoShiro__CorsOrigins` 放行前端的来源（见 [web/README.md](../web/README.md)）。
 
 实测（Probe 在广东移动家宽，Agent 在日本 IIJ）：
 
@@ -203,24 +203,24 @@ OpenWrt 默认不带 OpenSSL：`opkg install libopenssl3`（较新的快照和 2
 
 ## 容器部署（Docker / Podman 共用命名 volume）
 
-镜像和 Compose 配置共用。普通用户执行 Podman 即为 rootless，使用命名 volume 不需要 `keep-id` 或手动 `chown`。Agent 的配置、原有身份和缓存保存在 `monitor-agent-config`，Probe 保存在 `monitor-probe-config`，更新状态使用独立的 `monitor-<role>-status` volume，在业务容器内只读。不会重新生成已有身份。更新/重建容器不删除 volume；不要使用 `compose down -v`，该参数会删除数据。
+镜像和 Compose 配置共用。普通用户执行 Podman 即为 rootless，使用命名 volume 不需要 `keep-id` 或手动 `chown`。Agent 的配置、原有身份和缓存保存在 `moshiro-agent-config`，Probe 保存在 `moshiro-probe-config`，更新状态使用独立的 `moshiro-<role>-status` volume，在业务容器内只读。不会重新生成已有身份。更新/重建容器不删除 volume；不要使用 `compose down -v`，该参数会删除数据。
 
 在 `packaging/compose/agent` 下首次注册，并写配置（下列 `podman` 可替换为 `docker`）：
 
 ```sh
 podman compose run --rm --entrypoint /usr/local/bin/fleet-enroll agent \
-  --server https://<backend> --join <token> --name <name> --identity-dir /etc/monitor/agent-id
-podman compose run --rm -T --entrypoint /bin/sh agent -c 'cat > /etc/monitor/agent.json' <<'JSON'
-{"fleet":{"server":"https://<backend>","identity_dir":"/etc/monitor/agent-id"},"listen":{"bind":"0.0.0.0"}}
+  --server https://<backend> --join <token> --name <name> --identity-dir /etc/moshiro/agent-id
+podman compose run --rm -T --entrypoint /bin/sh agent -c 'cat > /etc/moshiro/agent.json' <<'JSON'
+{"fleet":{"server":"https://<backend>","identity_dir":"/etc/moshiro/agent-id"},"listen":{"bind":"0.0.0.0"}}
 JSON
 podman compose up -d
 ```
 
-Probe 在 `packaging/compose/probe` 下，将面板下载的身份文件通过标准输入导入 volume：`podman compose run --rm -T --entrypoint /bin/sh probe -c 'umask 077; cat > /etc/monitor/probe.json' < probe.json`，再 `podman compose up -d`。私钥权限为 600。已有部署迁移时，应把原配置与身份原样复制进 volume，不重新注册或轮换密钥。Docker 与 Podman 各自管理 volume，切换引擎不会自动共享数据。
+Probe 在 `packaging/compose/probe` 下，将面板下载的身份文件通过标准输入导入 volume：`podman compose run --rm -T --entrypoint /bin/sh probe -c 'umask 077; cat > /etc/moshiro/probe.json' < probe.json`，再 `podman compose up -d`。私钥权限为 600。已有部署迁移时，应把原配置与身份原样复制进 volume，不重新注册或轮换密钥。Docker 与 Podman 各自管理 volume，切换引擎不会自动共享数据。
 
-纯 Compose 使用 `compose pull && compose up -d` 更新镜像；面板自动更新使用下述 systemd 单元和更新器。Rootless Podman 使用 `monitor-<role>-rootless.service`，安装到 `~/.config/systemd/user/`，镜像文件为 `~/.config/monitor/<role>.image`；rootful Podman 使用 `monitor-<role>-container.service`，Docker 使用 `monitor-<role>-docker.service`，安装到 `/etc/systemd/system/`，镜像文件为 `/etc/monitor-update/<role>.image`。所有单元均使用相同的配置和状态 volume 名称。自动启动分别使用 `systemctl --user enable --now <unit>` 或 `sudo systemctl enable --now <unit>`。Rootless 在退出登录后继续运行需管理员执行一次 `loginctl enable-linger <用户名>`。
+纯 Compose 使用 `compose pull && compose up -d` 更新镜像；面板自动更新使用下述 systemd 单元和更新器。Rootless Podman 使用 `moshiro-<role>-rootless.service`，安装到 `~/.config/systemd/user/`，镜像文件为 `~/.config/moshiro/<role>.image`；rootful Podman 使用 `moshiro-<role>-container.service`，Docker 使用 `moshiro-<role>-docker.service`，安装到 `/etc/systemd/system/`，镜像文件为 `/etc/moshiro-update/<role>.image`。所有单元均使用相同的配置和状态 volume 名称。自动启动分别使用 `systemctl --user enable --now <unit>` 或 `sudo systemctl enable --now <unit>`。Rootless 在退出登录后继续运行需管理员执行一次 `loginctl enable-linger <用户名>`。
 
-Backend 的 `packaging/compose/backend/compose.yaml` 使用 `monitor-backend-data` 保存数据库和原始数据，设置 `MONITOR_INITIAL_ADMIN_PASSWORD` 后即可启动。首次安装 Podman 与用户 subuid/subgid 映射需要管理员权限，之后普通用户运行无需 sudo。
+Backend 的 `packaging/compose/backend/compose.yaml` 使用 `moshiro-backend-data` 保存数据库和原始数据，设置 `MOSHIRO_INITIAL_ADMIN_PASSWORD` 后即可启动。首次安装 Podman 与用户 subuid/subgid 映射需要管理员权限，之后普通用户运行无需 sudo。
 
 ### Agent 的系统指标挂载
 
@@ -247,16 +247,16 @@ Rootless Podman 普通用户安装示例（先将对应 rootless 服务单元复
 
 ```sh
 sh packaging/update/install-updater.sh agent --user \
-  --volume monitor-agent-config --status-volume monitor-agent-status \
-  --helper-image registry.oeo.one/monitor/monitor-agent:<version> \
-  --image-repo registry.oeo.one/monitor/monitor-agent \
-  --unit monitor-agent-rootless.service --policy auto
+  --volume moshiro-agent-config --status-volume moshiro-agent-status \
+  --helper-image registry.oeo.one/moshiro/moshiro-agent:<version> \
+  --image-repo registry.oeo.one/moshiro/moshiro-agent \
+  --unit moshiro-agent-rootless.service --policy auto
 ```
 
-使用 Docker 时以管理员运行相同安装命令，去掉 `--user`，加 `--engine docker`，单元选择 `monitor-agent-docker.service`。rootful Podman 去掉 `--user`，单元选择 `monitor-agent-container.service`。Probe 替换角色名。初始化对应 `<role>.image` 为 `IMAGE=<当前镜像引用>` 后启动容器单元。辅助镜像可用本机已有的 digest 引用，避免标签变化。Docker rootless 更新尚未适配。
+使用 Docker 时以管理员运行相同安装命令，去掉 `--user`，加 `--engine docker`，单元选择 `moshiro-agent-docker.service`。rootful Podman 去掉 `--user`，单元选择 `moshiro-agent-container.service`。Probe 替换角色名。初始化对应 `<role>.image` 为 `IMAGE=<当前镜像引用>` 后启动容器单元。辅助镜像可用本机已有的 digest 引用，避免标签变化。Docker rootless 更新尚未适配。
 
 命名 volume 的更新服务由 systemd timer 每 30 秒检查一次。`--policy auto` 验签后自动应用，默认 `manual` 等待面板写入应用请求。清单必须通过 ECDSA P-256 签名校验，组件、镜像仓库和递增 seq 都必须匹配本机配置；镜像按签名清单中的 digest 拉取。更新后观察服务 20 秒，启动失败或崩溃循环会恢复旧镜像引用并重启。无效签名、重放清单、拉取失败不会切换当前镜像。同一组件的更新通过 flock 串行处理。
 
-更新器依赖 Linux、systemd、OpenSSL、util-linux/flock 和所选引擎。用户部署把配置、公钥和镜像引用放在 `~/.config/monitor/`、版本记录放在 `~/.local/state/monitor-update/`；系统部署使用 `/etc/monitor-update/` 和 `/var/lib/monitor-update/`。私有仓库的 `--authfile` 对 Podman 使用其认证文件，对 Docker 使用标准 `config.json`，不改写全局 Docker 配置。旧 `--data-dir` 安装方式保留兼容，但新部署统一使用 `--volume`。
+更新器依赖 Linux、systemd、OpenSSL、util-linux/flock 和所选引擎。用户部署把配置、公钥和镜像引用放在 `~/.config/moshiro/`、版本记录放在 `~/.local/state/moshiro-update/`；系统部署使用 `/etc/moshiro-update/` 和 `/var/lib/moshiro-update/`。私有仓库的 `--authfile` 对 Podman 使用其认证文件，对 Docker 使用标准 `config.json`，不改写全局 Docker 配置。旧 `--data-dir` 安装方式保留兼容，但新部署统一使用 `--volume`。
 
 发布私钥只放在 Woodpecker 的 `release_signing_key` secret；发布公钥位于 `packaging/update/release-key.pub.pem`。CI 的 `release_api_token` 只有发布登记权限，`RELEASE_API_URL` 指向面板。面板保存并转发签名清单，Agent/Probe 将它与更新请求写进配置 volume；更新器验签后才调用容器引擎和 systemd。管理端仍能看到可更新、更新中、已回滚和无效清单状态。纯二进制更新器尚未实现。

docs/enrollment.md

@@ -1,6 +1,6 @@
-# Monitor 的注册与身份
+# MoShiro 的注册与身份
 
-通用的注册、身份、认证机制由 Fleet 提供，见 [fleet/link.md](fleet/link.md) 第 2～3 节。本文只描述 **Monitor 在 Fleet 之上的约定**：Agent 注册后如何自动接入测量、Probe 的身份以及 Agent 列表同步，以及节点本地的硬上限。
+通用的注册、身份、认证机制由 Fleet 提供，见 [fleet/link.md](fleet/link.md) 第 2～3 节。本文只描述 **MoShiro 在 Fleet 之上的约定**：Agent 注册后如何自动接入测量、Probe 的身份以及 Agent 列表同步，以及节点本地的硬上限。
 
 ## 1. 身份一览
 
@@ -10,7 +10,7 @@
 | Probe | Fleet 节点身份（同时用于连面板和连 Agent） | 面板生成 `probe.json`（可以有多个 Probe，每个独立吊销） | 公钥 |
 | 面板用户 | 账号 + 密码（PBKDF2-SHA256） | 面板 | 密码哈希 |
 | API 令牌 | 随机高熵令牌，作用域为 `read` 或 `admin` | 面板 | SHA-256 |
-| 发布签名 | ECDSA P-256 发布密钥 | CI（Woodpecker 密钥 `release_signing_key`）或离线环境 | 只在节点宿主机的更新器里配置公钥（容器节点是 `monitor-update`，见 [deployment.md](deployment.md)；纯二进制方案的 `fleet-updater` 还只是设计），**面板不保存私钥，也不验签** |
+| 发布签名 | ECDSA P-256 发布密钥 | CI（Woodpecker 密钥 `release_signing_key`）或离线环境 | 只在节点宿主机的更新器里配置公钥（容器节点是 `moshiro-update`，见 [deployment.md](deployment.md)；纯二进制方案的 `fleet-updater` 还只是设计），**面板不保存私钥，也不验签** |
 
 ## 2. Agent 接入流程
 
@@ -20,14 +20,14 @@
            curl -fsSL https://panel/install.sh | sh -s -- --join jt_xxx --name jp-1
 
 install.sh（只做安装，不包含任何远程控制功能；下面的更新器部分是纯二进制方案的设计，还没有实现，容器节点的做法见 deployment.md）
-  ├─ 下载 monitor-agent、fleet-enroll、fleet-updater，并验证发布签名
-  ├─ 创建系统用户：monitor（运行 Agent）、fleet-update（运行更新器）
-  ├─ fleet-enroll --server https://panel --join jt_xxx --name jp-1 --identity-dir /etc/monitor
-  │     └─ 注册元数据（Monitor 定义）：{ probe_tcp_port, probe_udp_ports, public_host?, kinds[] }
+  ├─ 下载 moshiro-agent、fleet-enroll、fleet-updater，并验证发布签名
+  ├─ 创建系统用户：moshiro（运行 Agent）、fleet-update（运行更新器）
+  ├─ fleet-enroll --server https://panel --join jt_xxx --name jp-1 --identity-dir /etc/moshiro
+  │     └─ 注册元数据（MoShiro 定义）：{ probe_tcp_port, probe_udp_ports, public_host?, kinds[] }
   ├─ 写入 agent.json（本地硬上限）和 /etc/fleet/updater.json
-  └─ 启用 monitor-agent.service 和 fleet-updater.service
+  └─ 启用 moshiro-agent.service 和 fleet-updater.service
 
-面板收到 OnEnrolled（Monitor 挂钩）
+面板收到 OnEnrolled（MoShiro 挂钩）
   ├─ public_host 未提供时，取注册请求的来源 IP
   ├─ 按“线路任务模板”为该 Agent 计算有效任务集（TaskSet）
   └─ 面板把新的 Agent 列表作为期望状态推给所有 Probe → Probe 自动连接新 Agent
@@ -58,11 +58,11 @@ Probe 启动
 - **哪些 Probe 连哪些 Agent 由面板决定，始终是 Probe 主动拨出**：设置 `fleet.auto_link`（默认开）打开时，所有未吊销的 Probe 和所有 Agent 两两连；关闭时只连手动选中的。每一对还可以在管理端 Probe 页的「线路」矩阵里手动强制开或关（`PUT /api/admin/links/{probe_id}/{agent_id}`），手动设置优先于自动连接。结果同时用在 Probe 的 Agent 列表、Agent 的 `peers` 和线路目录（关掉的线路从总览里消失，历史数据还在）。
 - 吊销 Probe：在面板上重新生成身份，旧公钥立即从所有 Agent 的期望状态中移除，旧会话随之断开。
 
-## 4. Agent 本地配置（`/etc/monitor/agent.json`，面板无法修改）
+## 4. Agent 本地配置（`/etc/moshiro/agent.json`，面板无法修改）
 
 ```json
 {
-  "fleet": { "server": "https://panel.example.com", "identity_dir": "/etc/monitor" },
+  "fleet": { "server": "https://panel.example.com", "identity_dir": "/etc/moshiro" },
   "listen": { "control_port": 7443, "udp_ports": [7443], "tcp_ports": [7444] },
   "limits": {
     "max_total_mbps": 200,
@@ -70,7 +70,7 @@ Probe 启动
     "allowed_target_cidrs": [],
     "max_concurrent_tests": 1
   },
-  "fleet_policy": { "allow_methods": ["monitor.test.run", "monitor.test.cancel"] }
+  "fleet_policy": { "allow_methods": ["moshiro.test.run", "moshiro.test.cancel"] }
 }
 ```
 
@@ -101,4 +101,4 @@ Probe 启动
 { "reporting": { "host_stats": true, "host_interval_s": 2 } }
 ```
 
-`host_stats` 为 true（默认）时，Agent 每隔 `host_interval_s` 秒用 `monitor.host` 上报一份主机资源占用的汇总数字（CPU、内存、根分区、网卡累计流量与网速、运行时长；没有型号、主机名、IP）；设为 false 就一个字也不上报。
+`host_stats` 为 true（默认）时，Agent 每隔 `host_interval_s` 秒用 `moshiro.host` 上报一份主机资源占用的汇总数字（CPU、内存、根分区、网卡累计流量与网速、运行时长；没有型号、主机名、IP）；设为 false 就一个字也不上报。

docs/fleet/link.md

@@ -49,7 +49,7 @@
 
 ## 4. RPC（Fleet.Rpc）
 
-- 信封采用 JSON-RPC 2.0；方法名为 `领域.动作`。`fleet.*` 保留给框架，产品使用自己的前缀，例如 `monitor.*`。
+- 信封采用 JSON-RPC 2.0；方法名为 `领域.动作`。`fleet.*` 保留给框架，产品使用自己的前缀，例如 `moshiro.*`。
 - 二进制帧：`u8 channel | 正文`。channel `0` 到 `15` 保留给框架，产品从 `16` 开始注册自己的二进制通道。
 - 错误：`error.data.code` 为 snake_case 字符串，框架的错误码以 `fleet_` 开头，产品可以扩展。
 - **与传输方式无关**：同一套路由既可以跑在 wss 上，也可以跑在 TLS 帧（`u32 长度 | u8 类型 | 正文`）上。
@@ -86,7 +86,7 @@ connect(wss) → fleet.challenge → fleet.auth → fleet.hello → 状态同步
 - 投递语义为**至少一次**：每条消息都带有 `msg_id`（UUIDv7），服务端按此去重。
 - 在途数据按字节限制（默认 4 MiB），保证服务端慢时不会把内存撑爆。
 - 丢弃消息时会累计缺口计数，通过 `OnGap` 回调通知产品，由产品决定如何上报。
-- 默认只保存在内存中，不落盘。产品如果需要持久化，可以自行实现 `IOutboxStore`（Monitor 不使用）。
+- 默认只保存在内存中，不落盘。产品如果需要持久化，可以自行实现 `IOutboxStore`（MoShiro 不使用）。
 
 ## 7. 期望状态同步（State Sync）
 
@@ -134,4 +134,4 @@ public interface IFleetStore
 }
 ```
 
-产品可以使用 `Fleet.Server.Sqlite`，也可以把这些表放进自己的数据库中。Monitor 的做法是把它们放进自己的 `monitor.db`，并由同一个单写入者负责写入。
+产品可以使用 `Fleet.Server.Sqlite`，也可以把这些表放进自己的数据库中。MoShiro 的做法是把它们放进自己的 `moshiro.db`，并由同一个单写入者负责写入。

docs/fleet/overview.md

@@ -1,8 +1,8 @@
 # Fleet：通用节点框架
 
-> **实现状态**：`Fleet.Update`、`Fleet.Server.Releases`、`fleet-updater`、`fleet-release` 还只是设计；容器节点的更新目前由宿主机上的 `monitor-update` 脚本和 Monitor 的 `ReleaseService` 完成（见 [deployment.md](../deployment.md)）。其余组件已实现。
+> **实现状态**：`Fleet.Update`、`Fleet.Server.Releases`、`fleet-updater`、`fleet-release` 还只是设计；容器节点的更新目前由宿主机上的 `moshiro-update` 脚本和 MoShiro 的 `ReleaseService` 完成（见 [deployment.md](../deployment.md)）。其余组件已实现。
 
-> 名称暂定。Fleet 与业务无关，Monitor 是它的第一个使用者。
+> 名称暂定。Fleet 与业务无关，MoShiro 是它的第一个使用者。
 
 ## 1. 定位
 
@@ -10,7 +10,7 @@
 
 ```text
 ┌──────────────────────────── 产品层（各产品自己写） ─────────────────────────────┐
-│ Monitor：  Protocol(Kind/任务) · Measurement(积木) · Agent · Probe · Backend     │
+│ MoShiro：  Protocol(Kind/任务) · Measurement(积木) · Agent · Probe · Backend     │
 │ 其他产品：  YourApp.Node · YourApp.Server                                        │
 └──────────────────────────────────┬─────────────────────────────────────────────┘
                                    │ 只依赖 Fleet；Fleet 不认识任何产品
@@ -29,14 +29,14 @@
 
 ## 2. 设计原则
 
-1. **与业务无关**：Fleet 中不出现任何产品概念。产品通过扩展点接入：元数据类型、RPC 方法、发件箱消息类型、期望状态文档类型。`scripts/check-deps` 强制规定 `backend/fleet/**` 不能引用 `Monitor.*`。
+1. **与业务无关**：Fleet 中不出现任何产品概念。产品通过扩展点接入：元数据类型、RPC 方法、发件箱消息类型、期望状态文档类型。`scripts/check-deps` 强制规定 `backend/fleet/**` 不能引用 `MoShiro.*`。
 2. **安全默认值**：
    - Fleet **永远不提供** exec、shell、文件读写、远程下发代码这类方法；
    - 节点只响应本地注册过的方法，本地策略 `allow_methods` 还可以进一步收窄；
    - 更新必须通过离线密钥签名验证，面板即使被攻破也推不出恶意二进制。
 3. **权限分离**：注册（`fleet-enroll`，一次性运行）、常驻业务进程、更新（`fleet-updater`）是三个独立的进程，使用不同的系统用户，各自只拥有最小权限。
 4. **NativeAOT 优先**：节点侧只依赖 BCL；泛型扩展点通过产品传入的 `JsonTypeInfo<T>` 实现序列化，不使用反射。
-5. **只抽取真正用到的**：每项能力都必须同时被 Monitor 和 `samples/EchoNode` 使用，防止过度设计。
+5. **只抽取真正用到的**：每项能力都必须同时被 MoShiro 和 `samples/EchoNode` 使用，防止过度设计。
 
 ## 3. 组件
 
@@ -67,15 +67,15 @@ fleet/                              以后可以原样拆成独立仓库并发
 │  ├─ Fleet.Enrollment.Client/
 │  └─ Fleet.Server.Enrollment/  Fleet.Server.Link/  Fleet.Server.Releases/  Fleet.Server.Sqlite/
 ├─ tools/  fleet-enroll/  fleet-updater/  fleet-release/
-├─ samples/  EchoNode/  EchoServer/   最小示例：不依赖 Monitor 的第二个使用者
+├─ samples/  EchoNode/  EchoServer/   最小示例：不依赖 MoShiro 的第二个使用者
 ├─ tests/
 └─ docs → 仓库 docs/fleet/
 ```
 
 ## 5. 演进策略
 
-- **现阶段**（已确认，暂不独立）：放在 monitor 仓库的 `backend/fleet/` 目录中，通过项目引用使用，一处修改两边同时编译。
-- **拆分条件**：公开 API 连续两个里程碑没有破坏性变更，并且 `samples` 能覆盖全部能力。满足后拆成独立仓库，按 semver 发布 NuGet 包，Monitor 改为包引用。
+- **现阶段**（已确认，暂不独立）：放在 MoShiro 仓库的 `backend/fleet/` 目录中，通过项目引用使用，一处修改两边同时编译。
+- **拆分条件**：公开 API 连续两个里程碑没有破坏性变更，并且 `samples` 能覆盖全部能力。满足后拆成独立仓库，按 semver 发布 NuGet 包，MoShiro 改为包引用。
 - **公开 API 审查**：`backend/fleet/src/*` 的 public 类型使用 `PublicAPI.Shipped.txt` / `PublicAPI.Unshipped.txt` 跟踪（使用 `Microsoft.CodeAnalysis.PublicApiAnalyzers`，只在构建期生效），任何变更都会在 PR 中显示出来。
 
 ## 6. 产品接入一览

docs/fleet/update.md

@@ -1,6 +1,6 @@
 # Fleet：通用更新（Fleet.Update / fleet-updater）
 
-> **实现状态**：容器节点（Agent、Probe）的更新已经实现，见 [deployment.md](../deployment.md) 的「容器节点的更新」：同样的信任模型（离线发布密钥签名、本机配置公钥和仓库、`seq` 防重放、面板只通知和请求），清单里是镜像 digest，更新器是宿主机上的 `monitor-update`。本文下面描述的纯二进制方案（`Fleet.Update`、`fleet-updater`、`fleet-release`、健康信标）还没有实现。
+> **实现状态**：容器节点（Agent、Probe）的更新已经实现，见 [deployment.md](../deployment.md) 的「容器节点的更新」：同样的信任模型（离线发布密钥签名、本机配置公钥和仓库、`seq` 防重放、面板只通知和请求），清单里是镜像 digest，更新器是宿主机上的 `moshiro-update`。本文下面描述的纯二进制方案（`Fleet.Update`、`fleet-updater`、`fleet-release`、健康信标）还没有实现。
 
 ## 1. 原则
 
@@ -30,15 +30,15 @@
   "check_interval_s": 3600,
   "apps": [
     {
-      "id": "monitor-agent",
-      "sources": ["https://panel.example.com/fleet/releases", "https://github.com/org/monitor/releases/download"],
+      "id": "moshiro-agent",
+      "sources": ["https://panel.example.com/fleet/releases", "https://github.com/org/moshiro/releases/download"],
       "channel": "stable",
       "policy": "notify",
       "rid": "linux-x64",
-      "install_dir": "/opt/monitor-agent",
+      "install_dir": "/opt/moshiro-agent",
       "keep_versions": 2,
-      "service": { "kind": "systemd", "name": "monitor-agent" },
-      "health": { "kind": "beacon", "path": "/run/fleet/monitor-agent.beacon", "timeout_s": 60 }
+      "service": { "kind": "systemd", "name": "moshiro-agent" },
+      "health": { "kind": "beacon", "path": "/run/fleet/moshiro-agent.beacon", "timeout_s": 60 }
     }
   ]
 }
@@ -53,16 +53,16 @@
 ```json
 {
   "schema": 1,
-  "app": "monitor-agent",
+  "app": "moshiro-agent",
   "channel": "stable",
   "version": "0.4.2",
   "released_at": "2026-10-01T00:00:00Z",
   "min_from": "0.3.0",
   "artifacts": [
-    { "rid": "linux-x64",   "url": "monitor-agent-0.4.2-linux-x64.tar.gz",   "sha256": "…", "size": 4120334 },
-    { "rid": "linux-arm64", "url": "monitor-agent-0.4.2-linux-arm64.tar.gz", "sha256": "…", "size": 3987112 },
-    { "rid": "linux-musl-arm64", "url": "monitor-agent-0.4.2-linux-musl-arm64.tar.gz", "sha256": "…", "size": 3990021 },
-    { "rid": "win-x64",     "url": "monitor-agent-0.4.2-win-x64.zip",        "sha256": "…", "size": 4455010 }
+    { "rid": "linux-x64",   "url": "moshiro-agent-0.4.2-linux-x64.tar.gz",   "sha256": "…", "size": 4120334 },
+    { "rid": "linux-arm64", "url": "moshiro-agent-0.4.2-linux-arm64.tar.gz", "sha256": "…", "size": 3987112 },
+    { "rid": "linux-musl-arm64", "url": "moshiro-agent-0.4.2-linux-musl-arm64.tar.gz", "sha256": "…", "size": 3990021 },
+    { "rid": "win-x64",     "url": "moshiro-agent-0.4.2-win-x64.zip",        "sha256": "…", "size": 4455010 }
   ],
   "notes_url": "https://…/CHANGELOG#0.4.2",
   "key_id": "rel-2026a",

docs/measurement.md

@@ -3,7 +3,7 @@
 ## 1. 原则
 
 - **只采集原始数据**：逐包、逐消息、逐事件，TCP 另加周期性的内核采样；不计算任何统计，解释全部放在 [analysis.md](analysis.md)。
-- **一处声明，处处生效**：采集方法（Kind）由积木组合**声明**而成。Probe 和 Agent 共用同一套积木（`backend/shared/Monitor.Measurement`）。
+- **一处声明，处处生效**：采集方法（Kind）由积木组合**声明**而成。Probe 和 Agent 共用同一套积木（`backend/shared/MoShiro.Measurement`）。
 - **密度即参数**：频率、包大小、采样间隔全部是任务参数，由 API 下发，不需要改代码。
 
 ## 2. 任务模型
@@ -26,7 +26,7 @@ schedule  continuous   持续运行，按时间切块
 
 ## 3. Kind 目录：积木组合
 
-### 3.1 积木（`Monitor.Measurement`，只有新增积木才需要写代码）
+### 3.1 积木（`MoShiro.Measurement`，只有新增积木才需要写代码）
 
 | 类别 | 积木 | 参数示例 |
 | --- | --- | --- |
@@ -39,7 +39,7 @@ schedule  continuous   持续运行，按时间切块
 
 **两种角色互相独立**：连接角色（Probe 永远是拨号方，适配 NAT）与数据角色（发送端、接收端、回显端，由 `direction` 决定）无关。每种积木只实现一次，Probe 和 Agent 共用。
 
-### 3.2 Kind 声明（`Monitor.Protocol/Catalog/Kinds`）
+### 3.2 Kind 声明（`MoShiro.Protocol/Catalog/Kinds`）
 
 ```csharp
 public static readonly KindSpec TcpEcho = new(
@@ -109,7 +109,7 @@ RawChunk
 - **列定义写在块头中**：新增列或新增 Kind 时，**不需要升级 `container_version`**。只有容器格式本身变化时才升级。Backend 可以通用地解码任何块，不认识的列会被保留，但会被分析层忽略。
 - **切块规则**：持续任务每 **10 秒**切一块，或者记录数达到上限（默认 50 000）时提前切块。这样采集密度提高后，单块大小仍然有界，实时显示和持久化也共用同一条链路。
 - 按需测试按阶段切块，阶段内同样受记录数上限约束。
-- 编解码器位于 `Monitor.Protocol/Raw`，Probe、Agent、Backend、离线工具使用同一份代码。
+- 编解码器位于 `MoShiro.Protocol/Raw`，Probe、Agent、Backend、离线工具使用同一份代码。
 
 ## 5. 列的归属与合并
 
@@ -131,12 +131,12 @@ RawChunk
 
 新增一种记录流只需要写声明，不需要写合并代码。Probe 的列在规定时间内没有送达时，目前 Agent 带着已有的数据继续（不上传只有 Agent 一侧的 `partial` 块，见已知缺口）。
 
-## 6. 代码结构（`backend/shared/Monitor.Measurement`）
+## 6. 代码结构（`backend/shared/MoShiro.Measurement`）
 
 同一种采集方法的两端是**一对角色**写在同一个文件里：拨号方（Probe 永远是拨号方，适配 NAT）和监听方（Agent）。两端共用包的构造和校验、时钟、行表和合并；Probe 和 Agent 只负责组装自己那一侧。
 
 ```text
-Monitor.Measurement/                    依赖：Monitor.Protocol（仅 BCL，零 NuGet）
+MoShiro.Measurement/                    依赖：MoShiro.Protocol（仅 BCL，零 NuGet）
 ├─ Core/
 │  ├─ Contracts.cs         IBlock、BlockSpec、BlockEnv、DataSession、IAdmission、IFragmentSink……
 │  ├─ RowStore.cs          本侧记录的行：只含本侧拥有的列，按键索引的环形缓冲，热路径不分配

docs/project-layout.md

@@ -3,8 +3,8 @@
 ## 1. 目标
 
 1. **三个独立项目加一个前端**：Probe、Agent、Backend 各自拥有解决方案，可以单独构建、测试和发布；Web 是独立的 Vite 项目（`web/`）。
-2. **通用能力只写一次**：TCP/UDP/TLS/ICMP 采集积木（类似 iperf3 的能力，但只记录原始数据）放在 `Monitor.Measurement` 中，Probe 和 Agent 共用；采集方法（Kind）由积木组合声明而成。
-3. **节点机制通用化**：注册、身份、连接、RPC、可靠上报、状态同步、宿主、更新，由与业务无关的 **Fleet** 框架提供（见 [fleet/overview.md](fleet/overview.md)）。Monitor 只写业务，其他产品也可以复用 Fleet。
+2. **通用能力只写一次**：TCP/UDP/TLS/ICMP 采集积木（类似 iperf3 的能力，但只记录原始数据）放在 `MoShiro.Measurement` 中，Probe 和 Agent 共用；采集方法（Kind）由积木组合声明而成。
+3. **节点机制通用化**：注册、身份、连接、RPC、可靠上报、状态同步、宿主、更新，由与业务无关的 **Fleet** 框架提供（见 [fleet/overview.md](fleet/overview.md)）。MoShiro 只写业务，其他产品也可以复用 Fleet。
 4. **改一处，整条链路受益**：协议、原始数据格式、测试方案、指标、错误码、版本号、编译设置、代码风格都只有**一个真源**。改动之后，下游要么自动更新，要么在编译期或 CI 中直接报错。
 5. **模块化**：Probe/Agent 由可插拔的模块组成；Backend 按层分成多个项目，层之间的依赖在编译期强制。
 6. **Probe/Agent 轻量**：运行时只依赖 BCL 和仓库内的库，不引用任何 NuGet 包。
@@ -12,45 +12,45 @@
 ## 2. 仓库布局
 
 ```text
-monitor/
+moshiro/
 ├─ README.md  .gitignore
 ├─ docs/   docs/fleet/
 ├─ scripts/                                   # publish / package / smoke / stability 等脚本（check-deps 等检查也放这里）
 ├─ packaging/                                 # install.sh、systemd 单元、OpenWrt 文件
 ├─ web/                                       # 前端：Vite + React + TypeScript（自写），只依赖 backend/openapi/v1.json
 │
-├─ global.json  Directory.Packages.props  Monitor.slnx  # SDK、NuGet 版本和全部 .NET 项目入口
+├─ global.json  Directory.Packages.props  MoShiro.slnx  # SDK、NuGet 版本和全部 .NET 项目入口
 ├─ .editorconfig  BannedSymbols.txt           # 风格与禁用 API（构建期强制）
 ├─ BannedSymbols.Node.txt                     # 仅用于常驻节点进程：纯采集边界
 │
-├─ ci/Monitor.Tar/                            # CI 归档工具，也加入根解决方案
+├─ ci/MoShiro.Tar/                            # CI 归档工具，也加入根解决方案
 └─ backend/                                   # 服务和节点 C# 代码（构建产物在 backend/artifacts/）
-   ├─ Directory.Build.props  Monitor.slnx      # 后端编译设置和后端目录解决方案
-   ├─ fleet/                                  # 通用节点框架（不认识 Monitor，以后可以拆成独立仓库）
+   ├─ Directory.Build.props  MoShiro.slnx      # 后端编译设置和后端目录解决方案
+   ├─ fleet/                                  # 通用节点框架（不认识 MoShiro，以后可以拆成独立仓库）
    │  ├─ src/     Fleet.Core Fleet.Identity Fleet.Rpc Fleet.Link Fleet.Hosting Fleet.Update
    │  │           Fleet.Enrollment.Client  Fleet.Server.{Enrollment,Link,Releases,Sqlite}
    │  ├─ tools/   fleet-enroll  fleet-updater  fleet-release
    │  ├─ samples/ EchoNode  EchoServer
    │  └─ tests/
-   ├─ shared/                                 # Monitor 自己的共享库
-   │  ├─ Monitor.Protocol/      # 契约真源：Kind/Plan 目录、任务集、monitor.* 方法、UDP 包、RawChunk、错误码
-   │  ├─ Monitor.Measurement/   # 采集引擎：积木、Recorder、任务调和（见 measurement.md）
+   ├─ shared/                                 # MoShiro 自己的共享库
+   │  ├─ MoShiro.Protocol/      # 契约真源：Kind/Plan 目录、任务集、moshiro.* 方法、UDP 包、RawChunk、错误码
+   │  ├─ MoShiro.Measurement/   # 采集引擎：积木、Recorder、任务调和（见 measurement.md）
    │  └─ tests/
-   ├─ probe/   src/Monitor.Probe/    tests/   # 家宽端采集器
-   ├─ agent/   src/Monitor.Agent/    tests/   # VPS 端采集器
+   ├─ probe/   src/MoShiro.Probe/    tests/   # 家宽端采集器
+   ├─ agent/   src/MoShiro.Agent/    tests/   # VPS 端采集器
    ├─ src/                                    # Backend（面板）
-   │  ├─ Monitor.Backend/                     # 宿主与组合根（Program.cs）
-   │  ├─ Monitor.Backend.Api/                 # API 层：HTTP 端点、DTO、错误映射
-   │  ├─ Monitor.Backend.Gateway/             # 在 Fleet.Server.Link 上注册 Monitor 的方法、状态与收件箱
-   │  ├─ Monitor.Backend.Application/         # 用例层 + 端口接口
-   │  ├─ Monitor.Backend.Analysis/            # 分析（纯计算，见 analysis.md）
-   │  └─ Monitor.Backend.Storage.Sqlite/      # 端口接口的实现，同时实现 IFleetStore
+   │  ├─ MoShiro.Backend/                     # 宿主与组合根（Program.cs）
+   │  ├─ MoShiro.Backend.Api/                 # API 层：HTTP 端点、DTO、错误映射
+   │  ├─ MoShiro.Backend.Gateway/             # 在 Fleet.Server.Link 上注册 MoShiro 的方法、状态与收件箱
+   │  ├─ MoShiro.Backend.Application/         # 用例层 + 端口接口
+   │  ├─ MoShiro.Backend.Analysis/            # 分析（纯计算，见 analysis.md）
+   │  └─ MoShiro.Backend.Storage.Sqlite/      # 端口接口的实现，同时实现 IFleetStore
    ├─ tests/
    ├─ openapi/v1.json                         # 构建生成并提交
-   └─ Monitor.Backend.slnx
+   └─ MoShiro.Backend.slnx
 ```
 
-节点机器上的发布物是三个独立进程，使用不同的系统用户：`monitor-agent`（或 `monitor-probe`）、`fleet-enroll`（一次性运行）、`fleet-updater`（常驻或定时运行）。
+节点机器上的发布物是三个独立进程，使用不同的系统用户：`moshiro-agent`（或 `moshiro-probe`）、`fleet-enroll`（一次性运行）、`fleet-updater`（常驻或定时运行）。
 
 ## 3. 依赖关系
 
@@ -65,21 +65,21 @@ monitor/
    │ └─────┬──────┘          │               │
    ▼       ▼                 ▼               ▼
  ┌──────────────────────────────────┐   ┌─────────────────────────┐
- │         Monitor.Protocol         │   │ Fleet.Server.*          │
+ │         MoShiro.Protocol         │   │ Fleet.Server.*          │
  └────────────────┬─────────────────┘   └───────────┬─────────────┘
                   ▼                                 ▼
  ┌──────────────────────────────────────────────────────────────────┐
  │ Fleet（节点侧）：Core · Identity · Rpc · Link · Hosting              │
  └──────────────────────────────────────────────────────────────────┘
-      反向依赖一律禁止：fleet/** ✗→ Monitor.*
+      反向依赖一律禁止：fleet/** ✗→ MoShiro.*
 ```
 
 简要来说：
 
 ```text
-Probe, Agent  ──> Measurement ──> Monitor.Protocol ──> Fleet.Core / Fleet.Rpc
+Probe, Agent  ──> Measurement ──> MoShiro.Protocol ──> Fleet.Core / Fleet.Rpc
 Probe, Agent  ──> Fleet.Link / Fleet.Hosting / Fleet.Identity
-Backend.*     ──> Monitor.Protocol + Fleet.Server.*                （不引用 Measurement）
+Backend.*     ──> MoShiro.Protocol + Fleet.Server.*                （不引用 Measurement）
 fleet-enroll  ──> Fleet.Enrollment.Client ──> Fleet.Identity / Core
 fleet-updater ──> Fleet.Update ──> Fleet.Core                      （不引用 Link，也不读取节点身份）
 Web           ──> openapi/v1.json
@@ -87,12 +87,12 @@ Web           ──> openapi/v1.json
 
 | 项目 | 允许依赖 | 禁止 |
 | --- | --- | --- |
-| `Fleet.*`（节点侧） | BCL、其他节点侧 Fleet 库 | 任何 NuGet 运行时包；任何 `Monitor.*` |
-| `Fleet.Server.*` | ASP.NET Core、`Microsoft.Data.Sqlite`（仅 Sqlite 项目）、节点侧 Fleet 库 | 任何 `Monitor.*` |
-| `Monitor.Protocol` | Fleet.Core、Fleet.Rpc | 任何 I/O、套接字、日志 |
-| `Monitor.Measurement` | Monitor.Protocol、Fleet.Core | NuGet；日志（只通过计数接收器上报）；读取配置；统计或解释逻辑 |
+| `Fleet.*`（节点侧） | BCL、其他节点侧 Fleet 库 | 任何 NuGet 运行时包；任何 `MoShiro.*` |
+| `Fleet.Server.*` | ASP.NET Core、`Microsoft.Data.Sqlite`（仅 Sqlite 项目）、节点侧 Fleet 库 | 任何 `MoShiro.*` |
+| `MoShiro.Protocol` | Fleet.Core、Fleet.Rpc | 任何 I/O、套接字、日志 |
+| `MoShiro.Measurement` | MoShiro.Protocol、Fleet.Core | NuGet；日志（只通过计数接收器上报）；读取配置；统计或解释逻辑 |
 | Probe / Agent | 上述库，以及 Fleet.Link / Hosting / Identity | NuGet 运行时包；彼此互相引用；Fleet.Update；Fleet.Enrollment.Client |
-| Backend.* | Monitor.Protocol、Fleet.Server.*，以及第 5.2 节列出的包 | Measurement、EF Core 等依赖反射的库 |
+| Backend.* | MoShiro.Protocol、Fleet.Server.*，以及第 5.2 节列出的包 | Measurement、EF Core 等依赖反射的库 |
 
 分析器类包（`PrivateAssets="all"`）不受限制。`scripts/check-deps` 在 CI 中检查上述规则。
 
@@ -102,28 +102,28 @@ Web           ──> openapi/v1.json
 
 组件、扩展点与接入方式见 [fleet/overview.md](fleet/overview.md)，连接细节见 [fleet/link.md](fleet/link.md)，更新见 [fleet/update.md](fleet/update.md)。
 
-> **实现状态**：`Fleet.Core`、`Fleet.Identity`、`Fleet.Rpc`、`Fleet.Link`、`Fleet.Hosting`、`Fleet.Enrollment.Client`、`Fleet.Server.*`（Abstractions、Enrollment、Link）和 `fleet-enroll` 已实现。`Fleet.Update`、`Fleet.Server.Releases`、`fleet-updater`、`fleet-release` 还只是设计（纯二进制方式的更新）；容器节点的更新是宿主机上的 `monitor-update` 脚本和面板的 `ReleaseService`，见 [deployment.md](deployment.md)。原来的 `Monitor.Common` 和 `Monitor.NodeHost` 已经并入 Fleet：
+> **实现状态**：`Fleet.Core`、`Fleet.Identity`、`Fleet.Rpc`、`Fleet.Link`、`Fleet.Hosting`、`Fleet.Enrollment.Client`、`Fleet.Server.*`（Abstractions、Enrollment、Link）和 `fleet-enroll` 已实现。`Fleet.Update`、`Fleet.Server.Releases`、`fleet-updater`、`fleet-release` 还只是设计（纯二进制方式的更新）；容器节点的更新是宿主机上的 `moshiro-update` 脚本和面板的 `ReleaseService`，见 [deployment.md](deployment.md)。原来的 `MoShiro.Common` 和 `MoShiro.NodeHost` 已经并入 Fleet：
 
 | 原位置 | 现位置 |
 | --- | --- |
-| `Monitor.Common`（Result、缓冲区、VarInt、有界队列、重放窗口、退避、ID、令牌哈希） | `Fleet.Core` |
-| `Monitor.NodeHost`（模块宿主、日志、配置、ConfigStore、服务外壳） | `Fleet.Hosting` |
+| `MoShiro.Common`（Result、缓冲区、VarInt、有界队列、重放窗口、退避、ID、令牌哈希） | `Fleet.Core` |
+| `MoShiro.NodeHost`（模块宿主、日志、配置、ConfigStore、服务外壳） | `Fleet.Hosting` |
 | 节点密钥与签名 | `Fleet.Identity` |
 | JSON-RPC 信封与路由 | `Fleet.Rpc` |
 | Agent 注册 | `Fleet.Enrollment.Client` + `fleet-enroll` |
 
-### 4.2 Monitor.Protocol（Monitor 的契约真源）
+### 4.2 MoShiro.Protocol（MoShiro 的契约真源）
 
 ```text
-Monitor.Protocol/
-├─ ProtocolVersion  ProtocolLimits  MonitorErrorCode（在 Fleet 错误码基础上扩展）
+MoShiro.Protocol/
+├─ ProtocolVersion  ProtocolLimits  MoShiroErrorCode（在 Fleet 错误码基础上扩展）
 ├─ Ids/          AgentId(= Fleet NodeId)、ProbeId、TaskId、TestId、ChunkId、StreamId
 ├─ Catalog/
 │  ├─ Kinds/     KindSpec 声明（积木组合 + ParamSpec + 记录列 + 预算）
 │  ├─ Plans/     多阶段测试方案
 │  └─ ParamSpec  参数定义（类型、默认值、上下限），节点与 Backend 共用同一套校验
 ├─ Tasks/        TaskSet（Fleet 期望状态的文档类型）、调和结果
-├─ Rpc/          monitor.* 方法名、params/result、二进制通道号（从 16 开始）
+├─ Rpc/          moshiro.* 方法名、params/result、二进制通道号（从 16 开始）
 ├─ Wire/         UDP 包、数据连接首帧
 ├─ Raw/          自描述 RawChunk：头部、列类型、列编解码、Brotli、crc32c
 └─ Json/         AgentRpcContext、ProbeRpcContext（按信道拆分，便于裁剪）
@@ -131,7 +131,7 @@ Monitor.Protocol/
 
 累加器、直方图等统计类型**不在 Protocol 中**，只属于 `Backend.Analysis`。
 
-### 4.3 Monitor.Measurement（采集引擎）
+### 4.3 MoShiro.Measurement（采集引擎）
 
 包含：
 
@@ -147,14 +147,14 @@ Monitor.Protocol/
 
 ### 5.1 Agent 与 Probe：组装
 
-节点的组装点是 `AgentApp` 和 `ProbeApp`：在构造函数里**显式组装**，不使用 DI 容器，也不做反射扫描；没有全局状态，测试可以在同一进程里启动多个。连接、认证、重连、发件箱、状态同步都由 Fleet 提供，Monitor 只写业务：
+节点的组装点是 `AgentApp` 和 `ProbeApp`：在构造函数里**显式组装**，不使用 DI 容器，也不做反射扫描；没有全局状态，测试可以在同一进程里启动多个。连接、认证、重连、发件箱、状态同步都由 Fleet 提供，MoShiro 只写业务：
 
 ```text
 AgentApp                                  Probe（ProbeApp）
   FleetLink（到面板）                       FleetLink（到面板）
-    状态 TaskSet、方法 monitor.test.*         状态 probe_agents（Agent 列表）、hello 带系统和构建信息
-    发件箱 RawChunk（通道 16）                心跳带更新器的状态；monitor.update.* 通知
-    心跳带更新器的状态；monitor.update.*      AgentDirectory → 每个 Agent 一个 AgentConnection（点对点会话）
+    状态 TaskSet、方法 moshiro.test.*         状态 probe_agents（Agent 列表）、hello 带系统和构建信息
+    发件箱 RawChunk（通道 16）                心跳带更新器的状态；moshiro.update.* 通知
+    心跳带更新器的状态；moshiro.update.*      AgentDirectory → 每个 Agent 一个 AgentConnection（点对点会话）
   PeerListener / PeerHub（Probe 会话）          会话内：线路任务集 line_task_set 的调和、角色、列块发件箱（通道 17）
   UdpMux / TcpAcceptor（数据端口）
   TaskManager / TestRunner / ChunkAssembler
@@ -163,7 +163,7 @@ AgentApp                                  Probe（ProbeApp）
 
 模块之间通过构造函数传入的接口或 `Channel<T>` 通信，禁止通过静态全局状态共享数据。
 
-**新增 RPC 方法**：在 `Monitor.Protocol/Rpc` 中定义 params/result，然后在组装处加一行 `.On(Methods.X, HandleX)`。
+**新增 RPC 方法**：在 `MoShiro.Protocol/Rpc` 中定义 params/result，然后在组装处加一行 `.On(Methods.X, HandleX)`。
 
 ### 5.2 Backend：分层与 API 层
 
@@ -172,7 +172,7 @@ AgentApp                                  Probe（ProbeApp）
                 │                              │                                    ▲
  ┌──────────────▼───────────────┐  ┌───────────▼──────────┐                         │
  │ Backend.Api                  │  │ Backend.Gateway      │                         │
- │ Public/ Admin/               │  │ 注册 monitor.* 方法    │                         │
+ │ Public/ Admin/               │  │ 注册 moshiro.* 方法    │                         │
  │ 认证（Cookie/CSRF/令牌）       │  │ TaskSet 状态提供者     │                         │
  │ 错误映射 · OpenAPI · SSE 端点  │  │ RawChunk 收件箱        │                         │
  └──────────────┬───────────────┘  └───────────┬──────────┘                         │
@@ -187,7 +187,7 @@ AgentApp                                  Probe（ProbeApp）
                              │ 实现端口
  ┌───────────────────────────┴─────────────────────────────┐
  │ Backend.Storage.Sqlite：段文件 + SQLite（只做读写）         │
- │ 同时实现 IFleetStore（Fleet 的节点和令牌表放在 monitor.db 中）│
+ │ 同时实现 IFleetStore（Fleet 的节点和令牌表放在 moshiro.db 中）│
  └─────────────────────────────────────────────────────────┘
 
  端口：IAgentStore、ITaskStore、IRawStore、IMetricStore、ITestStore、IAuthStore
@@ -198,16 +198,16 @@ AgentApp                                  Probe（ProbeApp）
 - **Api 不能引用 Storage**（编译期保证）；Api 和 Gateway 只调用 Application。
 - Application 返回 `Result<T>`。**错误码到 HTTP 状态的映射只在 Api 层做一次**（`ErrorCodeHttpMap`）；到 JSON-RPC 错误的映射由 Fleet.Rpc 统一完成。
 - Api 层按调用方分目录：`Public/`、`Admin/`，公共部分放在 `Common/`（分页、ETag、认证过滤器、ProblemFactory、`EndpointConventions`）。每类资源一个端点文件，新增资源时在 `ApiModule.Map` 中加一行。
-- 注册端点、签名认证、连接注册表、状态推送、收件箱 ACK、发布通道都来自 Fleet（`MapFleetEnrollment`、`MapFleetLink`、`MapFleetReleases`）。Monitor 只提供：
+- 注册端点、签名认证、连接注册表、状态推送、收件箱 ACK、发布通道都来自 Fleet（`MapFleetEnrollment`、`MapFleetLink`、`MapFleetReleases`）。MoShiro 只提供：
   - `IFleetStore` 的实现；
   - `TaskSet` 的状态提供者；
   - `RawChunk` 的收件箱；
-  - `monitor.*` 方法。
+  - `moshiro.*` 方法。
 - public 层的 DTO 单独定义，只暴露可以公开的字段，并统一经过“可见性过滤器”。
 - 请求校验：简单字段约束使用 .NET 10 内置的 Minimal API 校验；任务参数统一用 `ParamSpec` 校验（与节点共用）；跨字段规则放在 Application 层。
 - Backend 使用 ASP.NET Core 自带的 DI 容器，只在组合根显式注册。
 
-Backend.Analysis 只依赖 Monitor.Protocol 和 Fleet.Core，没有 I/O，可以单独做成离线 CLI 使用。
+Backend.Analysis 只依赖 MoShiro.Protocol 和 Fleet.Core，没有 I/O，可以单独做成离线 CLI 使用。
 
 Backend 允许的包：ASP.NET Core 共享框架、`Microsoft.Data.Sqlite`、`Microsoft.AspNetCore.OpenApi`、`Microsoft.Extensions.ApiDescription.Server`（仅构建期使用）。
 
@@ -221,11 +221,11 @@ Backend 允许的包：ASP.NET Core 共享框架、`Microsoft.Data.Sqlite`、`Mi
 | 原始数据格式 | `Protocol/Raw`（自描述） | 新增列不需要升级版本；四处使用同一份编解码器 |
 | 新增统计指标 | `Analysis/Metrics` 中加 1 行 `MetricDef` | 存储、降采样、API、SSE、目录全部自动处理；回填 30 天历史 |
 | 服务评分 | `Analysis/Models` | 查询时计算，立即对全部历史生效 |
-| 新增 RPC 能力 | `Monitor.Protocol/Rpc` + 组装处加 1 行 | 通过 Fleet 的 capabilities 协商，旧节点不受影响 |
-| 注册、认证、重连、发件箱、状态同步 | `backend/fleet/` | Monitor 和所有其他产品同时受益 |
+| 新增 RPC 能力 | `MoShiro.Protocol/Rpc` + 组装处加 1 行 | 通过 Fleet 的 capabilities 协商，旧节点不受影响 |
+| 注册、认证、重连、发件箱、状态同步 | `backend/fleet/` | MoShiro 和所有其他产品同时受益 |
 | 更新机制 | `Fleet.Update` + `fleet-updater` | 所有产品共用；产品只提供发布清单 |
 | REST DTO 与端点 | `Backend.Api` | 生成 OpenAPI，CI 检查 diff，前端的 TS 类型随之更新 |
-| 错误码 | Fleet 错误码 + `MonitorErrorCode` | REST、JSON-RPC、OpenAPI、TS 全部一致 |
+| 错误码 | Fleet 错误码 + `MoShiroErrorCode` | REST、JSON-RPC、OpenAPI、TS 全部一致 |
 | 版本、编译设置、风格、禁用 API | `backend/` 下的 props、`.editorconfig`、`BannedSymbols*.txt` | 所有项目 |
 
 ## 7. 编译设置
@@ -334,10 +334,10 @@ M0 阶段先测出基线，之后作为 CI 的回归门槛（超出 10% 即失
 | C 库 | musl：使用 `linux-musl-*` 目标发布 |
 | TLS | .NET 在 Linux 上依赖 OpenSSL，而 OpenWrt 默认使用 mbedTLS/wolfSSL。需要安装 `libopenssl3`（安装脚本自动检查并提示）。启动时自检，缺少时明确报错，不会静默降级 |
 | 全球化 | 已启用 `InvariantGlobalization`，不依赖 ICU |
-| 服务管理 | procd：提供 `/etc/init.d/monitor-probe`（`procd_set_param respawn`，前台运行，日志输出到 logd）；`Fleet.Hosting.ServiceShell` 在 procd 下不需要 `sd_notify` |
-| 存储 | 闪存很小，而且需要避免频繁写入：二进制放在 `/usr/lib/monitor/`，配置和身份放在 `/etc/monitor/`（sysupgrade 时通过 `/lib/upgrade/keep.d/` 保留）；测量数据本来就不落盘；`ConfigStore` 只在 Agent 列表变化时写入 |
+| 服务管理 | procd：提供 `/etc/init.d/moshiro-probe`（`procd_set_param respawn`，前台运行，日志输出到 logd）；`Fleet.Hosting.ServiceShell` 在 procd 下不需要 `sd_notify` |
+| 存储 | 闪存很小，而且需要避免频繁写入：二进制放在 `/usr/lib/moshiro/`，配置和身份放在 `/etc/moshiro/`（sysupgrade 时通过 `/lib/upgrade/keep.d/` 保留）；测量数据本来就不落盘；`ConfigStore` 只在 Agent 列表变化时写入 |
 | 内存 | 预算 ≤ 32 MB，适合 ≥ 256 MB 内存的路由器；在本地配置中限制重负载测试的码率（`limits.max_test_mbps`），防止路由器 CPU 成为瓶颈，反过来影响测量结果 |
-| 测量偏差 | Probe 运行在网关上时，自己没有 NAT；一旦路由器 CPU 饱和，结果就会失真。因此 Probe 在 `monitor.event` 中上报自身的 CPU 繁忙标记（仅进程级别），分析层据此标注置信说明 |
+| 测量偏差 | Probe 运行在网关上时，自己没有 NAT；一旦路由器 CPU 饱和，结果就会失真。因此 Probe 在 `moshiro.event` 中上报自身的 CPU 繁忙标记（仅进程级别），分析层据此标注置信说明 |
 | 打包 | 提供 `tar.gz` 和 procd 脚本；包格式（ipk 或 apk）按目标 OpenWrt 版本提供 |
 | 更新 | `fleet-updater` 使用 procd 适配器；`keep_versions = 1`，下载前检查剩余空间，避免写满闪存 |
 

docs/protocol.md

@@ -1,35 +1,35 @@
 # 线协议
 
-Monitor 的两条控制链路都建立在 Fleet 之上：
+MoShiro 的两条控制链路都建立在 Fleet 之上：
 
 - **Agent ↔ Backend**：Fleet 连接服务端（wss），见 [fleet/link.md](fleet/link.md)；
 - **Probe ↔ Agent**：Fleet 节点间点对点会话（TLS），见 [fleet/link.md](fleet/link.md) 第 8 节。
 
-认证、心跳、重连、能力协商、可靠发件箱、期望状态同步、JSON-RPC 信封都由 Fleet 负责。本文只定义 **Monitor 自己的内容**：`monitor.*` 方法、状态文档、二进制通道，以及 Fleet 之外的数据面（UDP 包和数据连接）。所有类型都放在 `Monitor.Protocol` 中。
+认证、心跳、重连、能力协商、可靠发件箱、期望状态同步、JSON-RPC 信封都由 Fleet 负责。本文只定义 **MoShiro 自己的内容**：`moshiro.*` 方法、状态文档、二进制通道，以及 Fleet 之外的数据面（UDP 包和数据连接）。所有类型都放在 `MoShiro.Protocol` 中。
 
 ## 1. Fleet 能力的映射
 
-| Monitor 需要的能力 | 使用的 Fleet 机制 | Monitor 提供的内容 |
+| MoShiro 需要的能力 | 使用的 Fleet 机制 | MoShiro 提供的内容 |
 | --- | --- | --- |
 | 下发任务 | 期望状态 `fleet.state.sync` | 文档类型 `TaskSet`，包括 `tasks[]`、`peers`（允许连这个 Agent 的 Probe 公钥，已按线路开关过滤） |
 | 下发 Agent 列表给 Probe | 期望状态 `fleet.state.sync`（Probe 直连面板） | 文档类型 `probe_agents`：`version`、`agents[]`（`agent_id`、`host`、`tcp_port`、`udp_ports`、`spki`），已按线路开关过滤；Agent 集合或线路开关变化时重新推送 |
-| 更新 | 通知 `monitor.update.offer` / `monitor.update.apply`（B→A、B→P），心跳附加字段 `update` | `offer` 带 CI 签名的发布清单原文和签名，节点只写进数据目录；`apply` 请求更新；`update` 是宿主机更新器的状态（`state`、`current`、`available`、`error`、`at`），见 [deployment.md](deployment.md) |
+| 更新 | 通知 `moshiro.update.offer` / `moshiro.update.apply`（B→A、B→P），心跳附加字段 `update` | `offer` 带 CI 签名的发布清单原文和签名，节点只写进数据目录；`apply` 请求更新；`update` 是宿主机更新器的状态（`state`、`current`、`available`、`error`、`at`），见 [deployment.md](deployment.md) |
 | 上报原始块 | 发件箱，二进制通道 **16** | `RawChunk`（自描述，见 [measurement.md](measurement.md) 第 4 节），`msg_id = chunk_id` |
 | Probe 交付列块 | 点对点会话的发件箱，二进制通道 **17** | 列块：`u32 stream_id \| u32 first_seq \| u32 count \| 列数据(Brotli)` |
 | 节点自身状态 | `fleet.heartbeat` 的附加字段 | Agent：`sessions`、`probes[]`、`pps_in/out`、`dropped_invalid`、`dropped_rate_limited`、`queue_bytes`、`update`；Probe：只有 `update` |
-| 版本与能力 | `fleet.hello` | capabilities 包括 `monitor.kinds:<列表>`、`monitor.blocks:<列表>`；Agent 附加 `platform`（系统、架构、版本、tag、提交、构建时间）、`tls_spki`、`probe_ports`、`local_limits` 摘要；Probe 附加 `platform` |
+| 版本与能力 | `fleet.hello` | capabilities 包括 `moshiro.kinds:<列表>`、`moshiro.blocks:<列表>`；Agent 附加 `platform`（系统、架构、版本、tag、提交、构建时间）、`tls_spki`、`probe_ports`、`local_limits` 摘要；Probe 附加 `platform` |
 
-## 2. `monitor.*` 方法
+## 2. `moshiro.*` 方法
 
 ### Agent ↔ Backend
 
 | 方法 | 方向 | 类型 | 参数与结果 |
 | --- | --- | --- | --- |
-| `monitor.test.run` | B→A | 请求 | `test_id`、`probe_id`（在哪个 Probe 上跑）、`plan`、`phases[]` → `accepted`，或错误 `test_busy`、`probe_offline` |
-| `monitor.probe.disconnect` | B→A | 请求 | `probe_id` → `accepted`（Agent 是否真的有这个会话）；Agent 关闭该 Probe 的会话 |
-| `monitor.test.cancel` | B→A | 请求 | `test_id` |
-| `monitor.test.status` | A→B | 通知 | `test_id`、`status`（`running`、`phase_done`、`succeeded`、`failed`、`aborted`）、`phase?`、`error_code?` |
-| `monitor.event` | A→B | 通知 | `kind`（`probe_connected`（`detail` 是 `probe_id`，`probe` 里带版本、远端地址和连接时间）、`probe_disconnected`、`endpoint_changed`、`session_rejected`、`clock_step`、`gap`、`cpu_saturated`（节点进程 CPU 饱和，可能影响测量，由 Probe 或 Agent 上报））、`at_utc`、`detail` |
+| `moshiro.test.run` | B→A | 请求 | `test_id`、`probe_id`（在哪个 Probe 上跑）、`plan`、`phases[]` → `accepted`，或错误 `test_busy`、`probe_offline` |
+| `moshiro.probe.disconnect` | B→A | 请求 | `probe_id` → `accepted`（Agent 是否真的有这个会话）；Agent 关闭该 Probe 的会话 |
+| `moshiro.test.cancel` | B→A | 请求 | `test_id` |
+| `moshiro.test.status` | A→B | 通知 | `test_id`、`status`（`running`、`phase_done`、`succeeded`、`failed`、`aborted`）、`phase?`、`error_code?` |
+| `moshiro.event` | A→B | 通知 | `kind`（`probe_connected`（`detail` 是 `probe_id`，`probe` 里带版本、远端地址和连接时间）、`probe_disconnected`、`endpoint_changed`、`session_rejected`、`clock_step`、`gap`、`cpu_saturated`（节点进程 CPU 饱和，可能影响测量，由 Probe 或 Agent 上报））、`at_utc`、`detail` |
 
 心跳的附加字段里有 `probes[]`：Agent 当前连着的每个 Probe（`id`、`version`、`remote`、`since_utc_ms`），每次都是完整快照，Backend 靠它纠正错过的连接事件。点对点握手的认证消息里可以带 Probe 的 `version`（只用于展示）。块头里的 `probe_id` 以 Agent 认证过的会话为准，Probe 自报的值会被覆盖。
 
@@ -38,10 +38,10 @@ Monitor 的两条控制链路都建立在 Fleet 之上：
 | 方法 | 方向 | 类型 | 参数与结果 |
 | --- | --- | --- | --- |
 | `fleet.state.sync`（文档类型 `line_task_set`） | A→P | 请求 | 这条线路的任务（`id`、`kind`、`params`、`stream_id`、`port`）和 Agent 的数据面端口 |
-| `monitor.clock` | P→A | 请求 | `probe_mono_us` → `agent_mono_us`；Probe 按往返中点估计两端单调时钟的偏移（取最小往返的一次），记入块头 `probe_offset_us` |
-| `monitor.test.phase` | A→P | 请求 | 测试的一个阶段：`test_id`、`phase`、`kind`、`params`、`stream_id`、`duration_s`、`port` → `accepted`；Probe 在回复之前准备好自己一侧的角色（单向数据流：先发几个探活包让 Agent 学到源地址） |
-| `monitor.test.phase_end` | A→P | 请求 | `sent_count`（Agent 发出的包数）→ `fragments`：Probe 收尾，把列块交给 Agent，回复交出的个数；Agent 等全部列块合并上传之后才进入下一阶段 |
-| `monitor.test.abort` | A→P | 通知 | `test_id` |
+| `moshiro.clock` | P→A | 请求 | `probe_mono_us` → `agent_mono_us`；Probe 按往返中点估计两端单调时钟的偏移（取最小往返的一次），记入块头 `probe_offset_us` |
+| `moshiro.test.phase` | A→P | 请求 | 测试的一个阶段：`test_id`、`phase`、`kind`、`params`、`stream_id`、`duration_s`、`port` → `accepted`；Probe 在回复之前准备好自己一侧的角色（单向数据流：先发几个探活包让 Agent 学到源地址） |
+| `moshiro.test.phase_end` | A→P | 请求 | `sent_count`（Agent 发出的包数）→ `fragments`：Probe 收尾，把列块交给 Agent，回复交出的个数；Agent 等全部列块合并上传之后才进入下一阶段 |
+| `moshiro.test.abort` | A→P | 通知 | `test_id` |
 | `fleet.outbox.ack` | 双向 | 通知 | Probe 的列块（通道 17）是至少一次投递，Agent 每收到一个就确认，重复到达的只处理一次 |
 
 会话密钥不需要单独的方法：点对点握手（TLS 固定证书 → `peer.challenge` → Probe 用身份私钥签 `(peer_id, nonce, client_pub, server_pub)` → 两端各自 ECDH + HKDF）直接得到 `session_id` 和 `session_key`，`peer.auth` 的应答只回显 `session_id` 用来互相确认。
@@ -58,7 +58,7 @@ Probe 只记录自己一侧的列，Agent 在数据面记录另一侧，由 Agen
 
 单块最多 `MaxRecordsPerChunk`（50 000）条记录：Probe 必须把大的阶段按序号范围切成多个列块（例如 100 Mbit/s、1000 B 的 10 秒阶段是 125 000 个包 → 4 个列块），`phase_end` 的应答报告总块数。块头里 Probe 必须带上 `agent_id`（它知道自己在和哪个 Agent 通信）。
 
-新增方法只需要在 `Monitor.Protocol/Rpc` 中定义，并在节点组装处加一行 `.On(...)`。旧节点会通过 capabilities 协商自动避开不支持的方法。
+新增方法只需要在 `MoShiro.Protocol/Rpc` 中定义，并在节点组装处加一行 `.On(...)`。旧节点会通过 capabilities 协商自动避开不支持的方法。
 
 ## 3. 数据面（不属于 Fleet）
 
@@ -95,7 +95,7 @@ Probe 只记录自己一侧的列，Agent 在数据面记录另一侧，由 Agen
 ## 4. 版本演进
 
 - Fleet 层的兼容规则见 [fleet/link.md](fleet/link.md)。
-- `monitor.*` 方法：新增方法或可选字段不需要升级版本，接收方忽略未知字段。
+- `moshiro.*` 方法：新增方法或可选字段不需要升级版本，接收方忽略未知字段。
 - RawChunk：块头自描述，新增列或新增 Kind 不需要升级 `container_version`；只有容器格式变化时才升级。
 - UDP 包和数据连接首帧的布局变化时，必须升级 `protocol_version`，并更新黄金字节测试。
 - Agent 同时支持当前版本和上一个版本的 Probe；Backend 能解码保留期内所有的 `container_version`。

docs/storage.md

@@ -1,12 +1,12 @@
 # Backend 存储
 
-实现位于 `Monitor.Backend.Storage.Sqlite`，负责实现 `Backend.Application` 中定义的端口接口，**只做读写，不含业务逻辑**。降采样和分析由 Application 调用 Analysis 完成。
+实现位于 `MoShiro.Backend.Storage.Sqlite`，负责实现 `Backend.Application` 中定义的端口接口，**只做读写，不含业务逻辑**。降采样和分析由 Application 调用 Analysis 完成。
 
 ## 1. 目录布局
 
 ```text
 data/
-├─ monitor.db                         # SQLite：配置、身份、原始块索引、指标、测试结果
+├─ moshiro.db                         # SQLite：配置、身份、原始块索引、指标、测试结果
 └─ raw/
    └─ 2026-09-27/                     # 按 UTC 日期分目录，保留期满整目录删除
       ├─ agt_01J…/                    # 每条线路或每个 Agent 一个目录
@@ -28,7 +28,7 @@ data/
 
 ## 3. 表结构
 
-`agents`、`join_tokens` 以及公钥和状态版本字段，同时作为 Fleet 的 `IFleetStore` 存储（由 `Monitor.Backend.Storage.Sqlite` 实现），和 Monitor 的其他数据放在同一个 `monitor.db` 中，由同一个单写入者写入。发布与灰度相关的表（`fleet_releases`、`fleet_rollouts`）由 `Fleet.Server.Releases` 自带的迁移脚本创建（职责见 [fleet/update.md](fleet/update.md) 第 6 节）。
+`agents`、`join_tokens` 以及公钥和状态版本字段，同时作为 Fleet 的 `IFleetStore` 存储（由 `MoShiro.Backend.Storage.Sqlite` 实现），和 MoShiro 的其他数据放在同一个 `moshiro.db` 中，由同一个单写入者写入。发布与灰度相关的表（`fleet_releases`、`fleet_rollouts`）由 `Fleet.Server.Releases` 自带的迁移脚本创建（职责见 [fleet/update.md](fleet/update.md) 第 6 节）。
 
 ```sql
 -- 身份与注册 -------------------------------------------------------------