docs: pin G14 HWLAB workspace

docs/reference/g14.md

@@ -8,7 +8,22 @@ For Code Queue and CI/CD migration preparation, G14 uses native k3s labels `unid
 
 ## HWLAB DEV Staging
 
-G14 can host a build-only HWLAB DEV staging cluster in the native k3s namespace `hwlab-dev`. The source checkout is `/root/hwlab`, and images should be built on G14 with the HWLAB repo-owned artifact script in build-only mode, then loaded or pushed to the G14-local registry before applying Kubernetes manifests.
+G14 can host a parallel HWLAB DEV staging cluster in the native k3s namespace `hwlab-dev`. The canonical G14 HWLAB source workspace is `/root/hwlab` on branch `G14`, with `origin` set to `git@github.com:pikasTech/HWLAB.git`; G14 source edits, CI/CD script changes, render work and manual polling must be done from that workspace through UniDesk SSH passthrough. Do not use `/root/HWLAB`, `/home/ubuntu/hwlab`, `/workspace/hwlab` or a master-server checkout as persistent G14 source truth. G14-local details are mirrored on the node in `/root/docs/hwlab-g14-workspace.md`.
+
+The standard entry forms are:
+
+```bash
+bun scripts/cli.ts ssh G14 script <<'SCRIPT'
+set -eu
+cd /root/hwlab
+git status --short --branch
+SCRIPT
+
+bun scripts/cli.ts ssh G14 apply-patch < patch.diff
+bun scripts/cli.ts ssh G14:k3s kubectl get pods -n hwlab-ci
+```
+
+`G14:k3s` is the only supported k3s route form. Do not use `ssh G14 k3s ...`; the first token must locate the distributed target, and the following tokens must be the operation.
 
 The G14 HWLAB DEV boundary is:
 
@@ -19,6 +34,7 @@ The G14 HWLAB DEV boundary is:
 - Use only G14-local placeholder Codex auth for mount/readiness tests unless real Code Agent execution on G14 has been separately authorized; do not copy D601 or production auth material.
 - Set `HWLAB_CLOUD_API_PORT=6667` explicitly in the G14 cloud-api Deployment. Kubernetes otherwise injects a `HWLAB_CLOUD_API_PORT=tcp://...` Service environment variable that breaks the Node port parser.
 - Override `HWLAB_PUBLIC_ENDPOINT` to a cluster-local G14 endpoint while no public tunnel is active, so staging services do not advertise the D601 production endpoint.
+- Do not run HWLAB repository `check`, Playwright/browser smoke, image builds or other heavy validation on the master server. Run those through G14 `/root/hwlab`, G14 k3s/Tekton, or another explicitly approved external execution plane.
 
 After the G14-local database is provisioned, run the HWLAB migration CLI only against the G14 DEV database with explicit non-production confirmations:
 

docs/reference/hwlab.md

@@ -9,6 +9,8 @@
 - HWLAB 项目内长期规则入口：`/workspace/hwlab/AGENTS.md`。
 - D601 HWLAB 运行副本：通过 `bun scripts/cli.ts ssh D601` 进入，优先使用 `/home/ubuntu/workspace/hwlab`；该目录是 D601 上的部署/构建副本，开始前也要 `git -C /home/ubuntu/workspace/hwlab pull --ff-only origin main`。
 - D601 上 `/home/ubuntu/hwlab` 可能是 runner 或并行任务工作区。指挥官不能把它当作部署真相，也不能清理、reset 或复用其中的 runner worktree。
+- `G14:HWLAB` 固定 workspace：只能通过 UniDesk SSH 桥进入 G14 的 `/root/hwlab`，固定使用 `G14` 分支和 `origin git@github.com:pikasTech/HWLAB.git`。每次开始 G14 工作前必须执行 `cd /root/hwlab && git status --short --branch && git remote -v`，期望分支是 `G14...origin/G14`；若不满足，先修正 workspace，不能继续开发、render、polling 或部署。
+- G14 k3s 操作必须使用 route 语法 `G14:k3s`，例如 `bun scripts/cli.ts ssh G14:k3s kubectl get pods -n hwlab-ci`；禁止写成 `ssh G14 k3s ...`。`/root/HWLAB`、`/home/ubuntu/hwlab`、`/workspace/hwlab`、D601 workspace、master-server checkout 或临时 clone 都不能作为 `G14:HWLAB` source truth。
 
 ## 关键 GitHub 入口