docs: codify JD01 k3s registry bootstrap

docs/reference/hwlab.md

@@ -12,6 +12,7 @@
 - D518 的 HWLAB v0.3 固定主 workspace 是 `D518:/home/ubuntu/workspace/hwlab-v03`，固定跟踪 `github/v0.3`。D518 上的源码修改、PR 准备、运行面修复和 rollout 前 source truth 检查必须在该固定 workspace 下创建任务级 `.worktree/<task>`；master server 本地 `/root/HWLAB`、一次性 clone 或未由 YAML 选中的路径只能做只读对照，不能承担 D518 source truth。
 - JD01 的 HWLAB v0.3 固定主 workspace 是 `JD01:/root/workspace/hwlab-v03`，固定跟踪 `github/v0.3`。JD01 上的源码修改、PR 准备、运行面修复和 rollout 前 source truth 检查必须在该固定 workspace 下创建任务级 `.worktree/<task>`；如果固定目录尚未初始化，先建立该目录的固定 repo，再继续当前任务。
 - JD01 的出网、依赖拉取、k3s/bootstrap、git-mirror 和 web-probe 浏览器依赖都以 UniDesk YAML 中的 host-route/host-proxy 声明为准：`config/hwlab-node-control-plane.yaml` 的 `nodes.JD01.egressProxy`、`config/platform-infra/host-proxy.yaml#targets.JD01`，以及 `config/hwlab-node-lanes.yaml` 的 JD01 network/download/sourceWorkspace 配置。JD01 的 MDTODO、Cloud Web、web-probe 或 rollout 任务不是 Sub2API 任务；除非 issue/CLI 明确指向 Sub2API runtime、Codex pool 或 platform-infra sub2api target，不要把这类故障默认归因到 Sub2API，也不要把 JD01 egress 临时切到 Sub2API 路径。
+- JD01 的 node-local registry 是 k3s workload/PVC，不是 host Docker registry。`hwlab nodes control-plane infra status --node JD01 --lane v03` 应显示 registry workload ready、PVC bound、endpoint ready、`zeroSeeded=true` 和 `seededFromOldRegistry=false`；旧 host Docker `registry` 容器应保持停止。零种子 registry 迁移后，必须通过受控 `runtime-image preload` 和 `infra tools-image build/status` 补齐 BuildKit、runtime/base 和 tools image，再把 HWLAB/AgentRun status 与 web-probe smoke 作为可用性证据。
 - HWLAB 项目内长期规则入口仍以目标 repo 的 `AGENTS.md` 为准。进入已解析的目标 workspace 后，必须重新读取该 workspace 的规则文件；不能只凭主 server 的压缩上下文继续操作。
 - 每次开始 node/lane 工作前必须通过 UniDesk SSH 桥检查目标 workspace，例如 `trans <node>:<workspace> sh -- 'git fetch origin <branch> && git pull --ff-only origin <branch> && git status --short --branch && git remote -v'`；若不满足目标 lane 预期，先修正 workspace，不能继续开发、render、polling 或部署。
 - k3s 操作必须使用 YAML 解析出的 route 语法，例如 `trans D601:k3s ...` 或 `trans G14:k3s ...`。第一个 route token 必须定位分布式目标，后续 token 才是 operation。

docs/reference/yaml-first-ops.md

@@ -92,6 +92,14 @@ For fresh VPS bring-up, do not use provider-gateway WebSocket egress as the bulk
 
 Host proxy use has a privacy boundary. A plain `http_proxy=http://...` proxy can observe destination hosts, request metadata and any proxy credential embedded in the URL or process environment; TLS protects encrypted request bodies from the proxy but does not hide the destination metadata from the proxy operator. Do not place private API keys in proxy URLs, logs or CLI output. `NO_PROXY`/`no_proxy` must preserve local, cluster, metadata and explicitly declared direct domains, including `hyueapi.com` and `.hyueapi.com` for Codex direct API access.
 
+## K3s-First Local Registry
+
+Fresh node bootstrap must not require an already-populated host Docker registry in order to deploy the node-local registry itself. The durable path for a new k3s node is to render the registry from YAML as a k3s workload with declared namespace, Deployment, Service, PVC, endpoint and image source. Host-Docker registry containers are legacy or migration sources only; they must not be the source of truth for a new node's ability to come up from zero.
+
+When migrating from a host-Docker registry to a k3s registry, the control path must make the data provenance explicit. If the goal is to prove from-zero deployment, stop the old host registry first and do not seed from it. The status output should say whether the new registry was seeded from an old registry or zero-seeded, whether the PVC is bound, whether the endpoint is ready, and which workload owns the registry. After a zero-seeded migration, required runtime images, BuildKit images and tools images must be re-created or preloaded through YAML-first control commands before claiming the lane can build or roll out.
+
+The registry is not a general reason to keep host Docker as a long-running dependency. Host Docker may still appear as a temporary build or image-transfer tool while a lane is being migrated, but the owning issue should classify it as a remaining Docker dependency and move durable builds toward k3s/Tekton/BuildKit or an equivalent rootless builder. Runtime status should distinguish long-running host Docker services from one-shot controlled build/preload operations.
+
 ## Cross-Repository Operational Truth
 
 When UniDesk prepares or supervises runtime data for another repository, the owning YAML still belongs in UniDesk if the data is part of node/lane operations rather than that repository's application source. Examples include HWLAB test/admin account inventories, operator-only API key source references, runtime DB sync inputs, public exposure targets and cross-node workbench preparation. The service repository may contain application code and app-native migrations, but it must not become a second desired-state truth for UniDesk-operated accounts, credentials, nodes, lanes, namespaces or sourceRef bindings.