docs: explain development and CI workflow [SKIP TESTS]

README.md

@@ -40,6 +40,8 @@ dotnet build Monitor.slnx -c Release
 ```sh
 npm ci --prefix web
 npm run build --prefix web
+npm run gen:api --prefix web  # API schema changed after Backend edits
+npm run lint:css --prefix web
 ```
 
 前端产物位于 `web/display/dist/` 和 `web/admin/dist/`。NativeAOT 目标平台和 Windows 上使用 AotAnywhere 交叉构建的说明见 [`docs/deployment.md`](docs/deployment.md)。
@@ -64,6 +66,15 @@ npm run dev --prefix web
 
 打开 <http://localhost:5173/> 使用展示端，或访问 <http://localhost:5174/admin/> 进入管理端。依赖安装和前端配置见 [`web/README.md`](web/README.md)；Backend 的首次启动与配置见 [`backend/README.md`](backend/README.md)。
 
+### CI 构建规则
+
+- Pull request 和 `dev` 分支 push：先跑 Backend tests，通过后再构建前端。
+- 在需要跳过 Backend tests 的提交信息后加 `[SKIP TESTS]`；Gitea pull request 需要把标记写进 PR 标题。前端构建仍会运行。
+- `main` 上的提交信息包含 `[CI]` 时，并行构建 Backend、Agent、Probe 的 Linux/amd64 镜像，推送到 Zot 的 `monitor-dev/` 仓库；普通 main push 不构建。
+- 推送 `vMAJOR.MINOR.PATCH` tag 会触发全平台正式构建和 Release 发布。
+
+完整触发条件、开发镜像标签和发布路径见 [`docs/deployment.md`](docs/deployment.md)。
+
 ## 项目布局
 
 | 路径 | 说明 |

docs/deployment.md

@@ -38,7 +38,27 @@ Compose 将容器端口只绑定到宿主机 `127.0.0.1:8080`，适合由同机
 
 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`。Linux glibc 的 Agent 与 Probe 二进制还会打包为 OCI 镜像，支持 `linux/amd64` 和 `linux/arm64`；musl、macOS、Windows 仍通过对应平台归档分发。所有平台产物和 OCI 镜像发布成功后，CI 会创建对应的 Gitea Release，并附上压缩包和 SHA-256 校验文件。macOS 产物目前未签名/公证。安装说明见 [`../backend/agent/README.md`](../backend/agent/README.md) 与 [`../backend/probe/README.md`](../backend/probe/README.md)。
 
-当推送到 `main` 的提交信息包含 `[CI]` 时，Woodpecker 会并行构建 Backend、Agent 和 Probe 的 Linux/amd64 镜像，并推送到同一个 Zot Registry 的开发仓库 `registry.oeo.one/monitor-dev/`。每个镜像更新 `latest`，并保留 `dev-<提交SHA>` 标签用于回滚；例如 `registry.oeo.one/monitor-dev/monitor-agent:latest`。开发镜像仅包含 amd64，不创建 Gitea Release，也不改动正式镜像仓库 `monitor/`。不带 `[CI]` 的 main push 不会启动此构建。版本 tag 流水线仍负责全平台构建，并发布正式镜像和 Gitea Release。
+## CI 工作流
+
+### Pull request 与 dev 验证
+
+Pull request 和 `dev` push 会运行 Backend tests；通过后，独立的 `web-build` workflow 才会构建前端并检查 CSS。提交信息后缀 `[SKIP TESTS]` 只跳过 Backend tests，前端构建仍会运行。Gitea PR 事件的 `CI_COMMIT_MESSAGE` 是 PR 标题，因此在 PR 中跳过测试时，把后缀写入 PR 标题；普通分支 push 则写在 commit message 中。
+
+### main 开发镜像
+
+`main` 上只有提交信息包含 `[CI]` 的 push 才构建镜像。合并 PR 时，请把 `[CI]` 放入 PR 标题或合并提交标题。Backend、Agent、Probe 的 Linux/amd64 镜像会并行构建，并推送到同一个 Zot Registry 下独立的 `monitor-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>` |
+
+Dev 镜像目前仅支持 amd64。它们不创建 Gitea Release，也不修改正式版 `monitor/` 仓库中的标签。普通 main push 不会构建镜像。
+
+### 正式版发布
+
+推送匹配项目版本的 `vMAJOR.MINOR.PATCH` tag 会触发完整跨平台构建、正式 OCI 镜像推送和 Gitea Release。正式镜像使用 `registry.oeo.one/monitor/` 路径；Agent、Probe 提供 amd64 与 arm64 多架构标签，稳定版本更新正式仓库自己的 `latest`。这与 `monitor-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 测量：