docs: ban master server builds

AGENTS.md

@@ -10,6 +10,13 @@ UniDesk 是一个以主 server 为统一入口的分布式工作平台；本文
 - 提交前必须用 `git status` 和 `git diff` 区分并只提交当前任务相关文件，保留并避开并行任务产生的无关修改；所有 UniDesk agent 变更只允许在 `master` 上开发并 `git push origin master`，禁止新建、切换到或推送其他分支；长期规则见 `docs/reference/arch.md`。
 - `release/v1` 是规划中的稳定维护线，不是普通 feature/fix 分支；创建、更新或启用必须作为显式 release operation，先满足 `docs/reference/release-governance.md` 和 GitHub issue #6 的 CLI/CI/CD/文档条件。当前常规 agent 任务仍按 master-only 规则执行。
 
+## Critical Master Server Build Ban
+
+- Master server 是生产入口和控制面，不得当作构建机使用；严厉禁止在 master server 上执行 Docker 镜像构建、`docker build`、`docker buildx build`、`docker compose build`、`docker compose up --build`、Rust 编译/测试（`cargo build`、`cargo test`、`rustc`）、Go 编译/测试（`go build`、`go test`）以及其他高 CPU/高内存编译构建任务。这类任务可能拖垮生产服务器，造成 UniDesk 整体不可用。
+- 镜像和编译产物必须通过标准 CI/CD 在外部构建资源上生成，通常是 D601 原生 k3s/Tekton 或经过批准的外部 builder；源码以 Git remote 为 source of truth，CI 产出 commit-pinned image/artifact。
+- Prod 发布必须走 CD pull-only 流程：由 `deploy.json` 声明期望服务版本，生产侧 CD 拉取已经构建好的镜像或 artifact 并按 `deploy.json` 部署；禁止把 master server 本地 Docker image、临时容器层或本地编译产物作为部署真相。
+- 在 master server 上只允许轻量源码编辑、Git 操作、状态/健康/日志/诊断、JSON CLI 控制面操作和受控 CD 观察；一旦步骤需要构建镜像或编译 Rust/Go 等重型产物，必须停止在 master server 执行并改走 CI/CD 或 D601 构建路径。
+
 ## Critical Provider Gateway Upgrade Rule
 
 - `src/components/provider-gateway` 有任何代码或行为变更时，必须在同一变更集中递增 `src/components/provider-gateway/package.json` 的版本号，并在升级后通过 frontend 或 `debug health` 确认目标节点上报新版本；权威规则见 `docs/reference/provider-gateway.md`。