docs: resolve HWLAB targets by node lane config

This commit is contained in:
Codex
2026-06-14 16:20:34 +00:00
parent 43b713a553
commit 19a28a91bd
3 changed files with 67 additions and 68 deletions
+26 -26
View File
@@ -94,12 +94,12 @@ UniDesk 是一个以主 server 为统一入口的分布式工作平台;本文
## Critical HWLAB Issue Closure CLI Validation Rule
- P0: HWLAB/G14/v0.2 的用户反馈、CLI、Cloud Web、AgentRun、device-pod、公开 API 或运行面工作流 issue,关闭前必须完成用户入口或原入口真实验证;仅有源码检查、构建检查、PR 合并或源码层证据不得关闭 issue。
- P0: CLI 相关 issue 未完成目标 runtime 上的真实 CLI 验证时必须保持打开或重新打开;关闭评论必须写明实际 CLI/入口命令、目标 lane/URL/namespace、trace/session/thread/PipelineRun 等证据和结果,细则见 `docs/reference/g14.md`
- P0: HWLAB 的用户反馈、CLI、Cloud Web、AgentRun、device-pod、公开 API 或运行面工作流 issue,关闭前必须按 issue/CLI 明确的 lane+node 完成用户入口或原入口真实验证;仅有源码检查、构建检查、PR 合并或源码层证据不得关闭 issue。
- P0: CLI 相关 issue 未完成目标 runtime 上的真实 CLI 验证时必须保持打开或重新打开;关闭评论必须写明实际 CLI/入口命令、目标 node/lane/URL/namespace、trace/session/thread/PipelineRun 等证据和结果,细则见 `docs/reference/hwlab.md`
## Critical CI/CD CLI Control Rule
- P0: 任何 agentrun、HWLAB 或其他 G14 k3s 服务的代码变更需要部署时,必须加载并遵循 `unidesk-cicd` skill 的标准流程(git-mirror sync → trigger-current → status 轮询)禁止手动 `kubectl exec/cp/delete`、直接操作 pod 容器、或绕过 PipelineRun 做原地热补。skill 路径:`.agents/skills/unidesk-cicd/SKILL.md`
- P0: 任何 agentrun、HWLAB 或其他 k3s 服务的代码变更需要部署时,必须先解析目标 node/lane 并走 UniDesk 受控 CI/CD CLIG14 target 按 `unidesk-cicd` skill 的标准流程(git-mirror sync → trigger-current → status 轮询)D601 HWLAB v0.3 target 按 `bun scripts/cli.ts hwlab nodes ... --node D601 --lane v03` 等 node-scoped 入口执行。禁止手动 `kubectl exec/cp/delete`、直接操作 pod 容器、或绕过 PipelineRun 做原地热补。skill 路径:`.agents/skills/unidesk-cicd/SKILL.md`
- P0: CI/CD、GitOps、rollout、artifact 发布、PR 合并后 DEV/PROD 滚动、PipelineRun 重跑/清理、Argo refresh 和运行面 retention 这类控制动作必须走 UniDesk CLI 的受控子命令;禁止把原生 `kubectl``argo``tkn``gh``curl` 或临时 shell 当作正式控制入口。
- P0: `trans <route> kubectl|logs|get|describe` / `tran <route> ...` 只作为 CLI 介导的短查询诊断和证据采集底座;一旦某个 CI/CD 写操作需要重复使用,必须先补齐 `bun scripts/cli.ts ...` 高层子命令并把用法写入 `docs/reference/cli.md`,不能长期靠低层 route 手工 patch/annotate/delete。
- P0: 若现有 CLI 字段、状态、权限或动作不够,默认先改进 UniDesk CLI 后继续发布;不得绕过为原生命令直连 GitHub、Kubernetes、Tekton、Argo 或 registry。长期细则见 `docs/reference/cli.md`
@@ -110,9 +110,9 @@ UniDesk 是一个以主 server 为统一入口的分布式工作平台;本文
## Critical HWLAB_API_KEY Discovery Rule
- P0: `HWLAB_API_KEY` 已在 master server 和 G14 固化,统一来源路径`/root/.config/hwlab-v02/master-server-admin-api-key.env`处理 HWLAB CLI、Code Agent、HWPOD、trace/result、Web 等价 CLI 或 v0.2 验收前,必须先从当前执行 host 的该文件加载或确认 key,禁止先把问题定性为缺少 API key。
- P0: master server 和 G14 的 `~/.bashrc` 会加载该固定文件,并通过 `BASH_ENV=$HOME/.bashenv` 让从交互 shell 派生的非交互 bash 也能读取 `HWLAB_API_KEY`;若当前进程没有继承环境,先显式 `source ~/.bashrc` 或确认该固定文件,不得改走别名、token、cookie 或临时 fallback。
- P0: 查询 key 时只能输出 `HWLAB_API_KEY=present/missing`、source path 或 redacted prefix;禁止在 stdout、issue、trace、日志、AGENTS 或 docs 中打印完整 key。G14/HWLAB runtime 中环境变量缺失不代表 key 不存在,应先通过同一固定来源注入再继续排查。
- P0: `HWLAB_API_KEY` 来源必须按 issue/CLI 选中的 node/lane 和目标 HWLAB repo 规则解析;v0.2 的既有固定路径是 `/root/.config/hwlab-v02/master-server-admin-api-key.env`,但不得把它当成 v0.3/D601 或其他 lane 的隐藏默认。处理 HWLAB CLI、Code Agent、HWPOD、trace/result、Web 等价 CLI 或验收前,必须先从目标 lane 的声明来源加载或确认 key,禁止先把问题定性为缺少 API key。
- P0: 当前执行 host 的 shell 启动文件可能会加载 lane-local API key;若当前进程没有继承环境,先显式读取目标 lane 规则或 source 文件,只能输出 source path、present/missing 或 redacted prefix,不得改走别名、token、cookie 或临时 fallback。
- P0: 查询 key 时只能输出 `HWLAB_API_KEY=present/missing`、source path 或 redacted prefix;禁止在 stdout、issue、trace、日志、AGENTS 或 docs 中打印完整 key。目标 runtime 中环境变量缺失不代表 key 不存在,应先通过选中 node/lane 的声明来源注入再继续排查。
- P0: HWLAB v0.2 Code Agent provider profile 的 `config.toml` 与完整 Codex `auth.json` 提交、Secret 证据和真实试机验收规则统一见 `docs/reference/hwlab.md#code-agent-provider-profile-配置与验收`;AGENTS.md 只保留索引,不重复凭证语义。
## Critical AgentRun Worktree Rule
@@ -120,30 +120,30 @@ UniDesk 是一个以主 server 为统一入口的分布式工作平台;本文
- P0: `pikasTech/agentrun` 是新的共享 Agent 执行基础设施仓库,不是现有 Code Queue 的就地替换;`v0.1` source truth 是 G14 节点固定 source worktree `G14:/root/agentrun-v01`,固定使用 `v0.1` 分支和 `origin git@github.com:pikasTech/agentrun.git`
- P0: AgentRun `v0.1` 开发必须先预检 `G14:/root/agentrun-v01` 的路径、分支、remote 和 clean 状态,再在 `/root/agentrun-v01/.worktree/{pr_branch}` 创建独立 worktree 修改;不要把固定 source worktree、UniDesk、HWLAB、D601 或临时 clone 当作 AgentRun scratch 区。
- P0: AgentRun 废弃旧 `dev/prod` 运行口径;`v0.1` 固定部署目标是 `G14:k3s` 上的 `agentrun-v01` namespace,后续按 `v0.1``v0.2``v0.3` lane 滚动。
- P0: HWLAB 到 AgentRun 的 `gitbundle` 资源装配必须以 repo URL + workspace ref 为 checkout authorityHWLAB 默认通过 G14 git mirror 拉取 `v0.2`cloud-api、CI/CD 或 rollout 注入的旧 commit 只能作为 requested hint,不得重新成为默认物化来源,细则见 `docs/reference/agentrun.md`
- P0: HWLAB 到 AgentRun 的 `gitbundle` 资源装配必须以 repo URL + issue/CLI 选中 node/lane 的 workspace ref 为 checkout authoritycloud-api、CI/CD 或 rollout 注入的旧 commit 只能作为 requested hint,不得重新成为默认物化来源,细则见 `docs/reference/agentrun.md`
- P0: 所有 AgentRun k3s 操作必须使用 route 语法 `G14:k3s`UniDesk 侧只维护 AgentRun 的开发和部署运维约束,细则见 `docs/reference/agentrun.md`
- P0: AgentRun 的文档、issue、PR、review 和交付说明一律中文;代码标识符、API path、配置键、命令和必要英文专有名词可保留英文,解释性文字必须中文。
## Critical G14 HWLAB Workspace Rule
## Critical HWLAB Node/Lane Workspace Rule
- P0: HWLAB legacy G14 DEV/PROD 运行面已退役;`G14`/`G14-gitops``hwlab-dev`/`hwlab-prod`、17666/17667 和 18666/18667 不再作为当前开发、发布、验收或回归真相。退役状态、计划和执行入口固定为 `bun scripts/cli.ts hwlab g14 retirement status|plan|execute --confirm`,且该入口只允许触碰 legacy Argo Application 与 legacy namespace,必须保护 `hwlab-v02`/`hwlab-v03`
- P0: HWLAB 当前 G14 运行面默认收敛到 runtime lane`v0.2` 固定使用分支 `v0.2`、开发 workspace `G14:/root/hwlab-v02`、CI/CD 专用 source repo `G14:/root/hwlab-v02-cicd.git`、namespace `hwlab-v02`、19666/19667 FRP 入口;`v0.3` 使用 `hwlab-v03` namespace 和 20666/20667 FRP 入口;`v0.3+` 通过 `hwlab nodes --node G14 --lane vNN``config/hwlab-node-lanes.yaml` 管理,长期细则见 `docs/reference/g14.md`
- P0: 每次开始 G14 HWLAB runtime lane 分布式开发、切换任务、恢复中断或上下文压缩后,必须重新读取目标 lane workspace 的 `AGENTS.md`,并以该文件和其引用的 HWLAB repo 内规则为当前任务约束;禁止只凭压缩摘要或主 server 记忆继续改代码。`/root/hwlab` 只在显式 legacy/retirement follow-up 时使用。
- 操作入口必须通过 UniDesk SSH 维护桥:host/source 操作用 `trans G14 script` 或 workspace route 加 `apply-patch`,远端文本 patch 默认使用 `apply-patch` 的 v2 引擎、旧 helper 仅通过 `apply-patch-v1` 显式调用;k3s 操作用 `trans G14:k3s ...`;禁止使用 `ssh G14 k3s ...`,定位必须写在第一个 route token,后续 token 才是 operation。
- P0: 每次开始 G14 HWLAB runtime lane 工作前,目标固定仓库必须先即时快进到目标 remote 分支最新;例如 v0.2 使用 `trans G14:/root/hwlab-v02 script -- 'git fetch origin v0.2 && git pull --ff-only origin v0.2 && git status --short --branch && git remote -v'`。若有未提交并行变更阻碍快进,必须先判断是否能与最新 remote 快速合并;能合并则立即合并,禁止默认 stash、丢弃或绕到落后 worktree;只有确实无法自动合并时才隔离保存并停止交给人工决策。禁止用落后的固定仓库继续预检、创建 worktree、开发、render、polling 或部署。
- G14 HWLAB service/runtime 开发必须先以目标 runtime lane 固定 repo 做预检,再按目标 lane 创建独立 worktree/PRv0.2 CaseRun、短连接 CLI、trace、docs/reference 和配置治理这类无服务任务按 `docs/reference/g14.md``direct-lightweight` 规则可在 `G14:/root/hwlab-v02` 直接提交推送,不触发 PR/CI/CD/rollout。
- P0: HWLAB 目标选择必须以 issue/CLI 明确的 lane+node 为准;没有明确目标时才读取 `config/hwlab-node-lanes.yaml` 默认值。node、lane、workspace、CI/CD repo、namespace、GitOps path、公网入口、Secret sourceRef 和执行 route 都以 YAML 为 source of truth,禁止把 G14、D601、v0.2 或 v0.3 写成隐藏默认
- P0: 每次开始 HWLAB node/lane 分布式开发、切换任务、恢复中断或上下文压缩后,必须先解析目标 node/lane重新读取目标 workspace 的 `AGENTS.md`,并以该文件和其引用的 HWLAB repo 内规则为当前任务约束;禁止只凭压缩摘要或主 server 记忆继续改代码。
- 操作入口必须通过 UniDesk SSH 维护桥:host/source 操作用 `trans <node>:/<workspace> ...` 或 workspace route 加 `apply-patch`,远端文本 patch 默认使用 `apply-patch` 的 v2 引擎、旧 helper 仅通过 `apply-patch-v1` 显式调用;k3s 操作用 YAML 解析出的 route,例如 `trans D601:k3s ...` `trans G14:k3s ...`;禁止使用 `ssh <node> k3s ...`,定位必须写在第一个 route token,后续 token 才是 operation。
- P0: 每次开始 HWLAB node/lane 工作前,目标固定仓库必须先即时快进到目标 remote 分支最新;例如 D601 v0.3 使用 `trans D601:/home/ubuntu/workspace/hwlab-v03 script -- 'git fetch origin v0.3 && git pull --ff-only origin v0.3 && git status --short --branch && git remote -v'`。若有未提交并行变更阻碍快进,必须先判断是否能与最新 remote 快速合并;能合并则立即合并,禁止默认 stash、丢弃或绕到落后 worktree;只有确实无法自动合并时才隔离保存并停止交给人工决策。禁止用落后的固定仓库继续预检、创建 worktree、开发、render、polling 或部署。
- HWLAB service/runtime 开发必须先以目标 node/lane 固定 repo 做预检,再按目标 lane 创建独立 worktree/PRCaseRun、短连接 CLI、trace、docs/reference 和配置治理这类无服务任务按目标 repo 规则可直接提交推送,不触发 PR/CI/CD/rollout。
- P0: G14 已有节点本地 GitHub/Google/DockerHub/npm 等 bootstrap 加速 proxy;在 G14 host、临时 pod、构建 pod 或透传 pod 里拉 GitHub/Google 资源前必须优先使用该 proxy,避免把网络直连失败当作代码阻塞。主入口:HTTP/HTTPS `http://127.0.0.1:10808`、SOCKS `socks5h://127.0.0.1:10808`,备份入口和 NO_PROXY 规则见 `docs/reference/g14.md`
- P0: G14 platform PostgreSQL 是 host-native 底层基础设施,HWLAB v0.3+ 通过 namespace-local `g14-platform-postgres` bridge 使用它;迁移后必须清理旧自有 Postgres StatefulSet/Service/ConfigMap/Secret/PVC,长期规则见 `docs/reference/g14-platform-db.md`
- 禁止把 master server、D601`/root/HWLAB``/home/ubuntu/hwlab``/workspace/hwlab`、retired `/root/hwlab` 或临时 clone 当作当前 G14 runtime lane source truthmaster server 也不得运行 HWLAB check、Playwright/browser smoke、镜像构建或其他重型验证,验证必须走目标 runtime lane workspace、G14 k3s/Tekton 或其他获批外部执行面。
- 长期细节见 `docs/reference/g14.md`G14 节点本地也保留 `/root/docs/hwlab-g14-workspace.md`两处口径必须保持一致
- 禁止把 master server、未由 YAML 选中的 workspace`/root/HWLAB``/home/ubuntu/hwlab``/workspace/hwlab`、retired `/root/hwlab` 或临时 clone 当作当前 HWLAB source truthmaster server 也不得运行 HWLAB check、Playwright/browser smoke、镜像构建或其他重型验证,验证必须走目标 node/lane workspace、k3s/Tekton 或其他获批外部执行面。
- 长期细节见 `docs/reference/hwlab.md`G14 节点本地也保留 `/root/docs/hwlab-g14-workspace.md`该文档只约束 G14 target,不得覆盖 issue/CLI 明确选择的 D601 target
## Critical D601 HWLAB Legacy And Hardware Bridge Rule
## Critical D601 HWLAB Node And Legacy Boundary
- P0: `D601:HWLAB` 不再是 HWLAB 默认开发主阵地或运行面真相;`/home/ubuntu/workspace/hwlab-dev` 只作为历史迁移、D601 legacy 回滚、显式指定的 D601 补丁收敛和故障对照 workspace 使用
- P0: 新的 HWLAB 代码、文档、render、polling、CI/CD、GitOps、runtime lane 和验收默认必须走 G14 runtime lane;只有用户明确指定 D601 legacy 或 D601 Windows 硬件桥接时,才进入 D601 HWLAB 路径
- D601 仍是 ConStart/71-FREQ 等 Windows 硬件与 Keil/串口资源的 bridge host最小 device-agent 实验中,D601 Windows `hwlab-gateway` 可以作为外部 gateway 连接到当前 G14 runtime lane cloud-api,而不改变 HWLAB source/runtime truth
- 每次确需进入 D601 legacy HWLAB workspace 前,仍必须通过 UniDesk SSH 桥执行 `cd /home/ubuntu/workspace/hwlab-dev && git status --short --branch && git remote -v`,并重新读取 `/home/ubuntu/workspace/hwlab-dev/AGENTS.md`;发现 D601 口径与当前 G14 runtime lane 规则冲突时,以 G14 runtime lane 规则为准
- `/home/ubuntu/workspace/hwlab``/tmp/hwlab-*``/home/ubuntu/workspace/hwlab-*` 一次性目录、`/home/ubuntu/hwlab` runner 历史目录和 master-server checkout 都不能作为 HWLAB 当前开发真相。
- P0: D601 node-scoped runtime 不是 legacy;当 issue/CLI 明确写出 `目标节点: D601` 和当前 lane(例如 `HWLAB v0.3`)时,必须按 `config/hwlab-node-lanes.yaml` 的 D601 target 进入对应 workspace、k3s route、namespace 和 public endpoint
- P0: D601 legacy 只指旧 DEV/迁移/回滚对照路径,例如 `/home/ubuntu/workspace/hwlab-dev`、16666/16667 或历史 `deploy/deploy.json` wrapper;只有 issue/CLI 明确写成 D601 legacy、迁移对照、回滚或旧 DEV 端口排障时才使用
- D601 仍是 ConStart/71-FREQ 等 Windows 硬件与 Keil/串口资源的 bridge host硬件桥接身份不覆盖 D601 node-scoped runtime 身份,二者必须按 issue/CLI 目标区分
- 每次确需进入 D601 legacy HWLAB workspace 前,仍必须通过 UniDesk SSH 桥执行 `trans D601:/home/ubuntu/workspace/hwlab-dev script -- 'git status --short --branch && git remote -v'`,并重新读取该目录的 `AGENTS.md`
- `/home/ubuntu/workspace/hwlab``/tmp/hwlab-*``/home/ubuntu/workspace/hwlab-*` 一次性目录、`/home/ubuntu/hwlab` runner 历史目录和 master-server checkout 都不能作为 HWLAB 当前开发真相,除非它们正是 YAML 或明确 legacy issue 指定的目标 workspace
- 长期细节见 `docs/reference/hwlab.md`
## Critical D601 UniDesk Workspace Rule
@@ -184,8 +184,8 @@ UniDesk 是一个以主 server 为统一入口的分布式工作平台;本文
- 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 整体不可用。
- P0: backend-core 主 server 上线是唯一受控例外:当用户或 issue 明确要求把当前 backend-core 修复上线到 master server 时,可以在 master server 上用 `CARGO_BUILD_JOBS=1``--jobs 1` 或 CLI 内置等价限流执行 backend-core 专属 Rust 编译或 `server rebuild backend-core`;该例外不得扩展为仓库级 `check``cargo test`、Go/前端/其他服务构建或常规迭代路径,完成后必须用异步 job/status/health 证据回写 issue。
- Master server 资源也不足以承载仓库级 `check`/`test`/smoke 验证;禁止在 master server 上运行 `bun scripts/cli.ts check``node --test``node web/hwlab-cloud-web/scripts/check.mjs`、Playwright/browser smoke 或其他会遍历大仓库、启动浏览器、长时间占用 CPU/内存的校验命令。HWLAB 正式验证必须改在目标 G14 runtime lane workspace、G14 k3s/Tekton 或其他获批外部执行面完成;非 HWLAB 的 D601 服务仍按各自 reference 使用 D601 原生 k3s/CI runner。
- 镜像和编译产物必须通过标准 CI/CD 在外部构建资源上生成;HWLAB 默认使用 G14 k3s/Tekton/GitOps 或经过批准的外部 builder,非 HWLAB 服务按各自 reference 使用 D601 原生 k3s/Tekton 或其他获批外部 builder;源码以 Git remote 为 source of truthCI 产出 commit-pinned image/artifact。
- Master server 资源也不足以承载仓库级 `check`/`test`/smoke 验证;禁止在 master server 上运行 `bun scripts/cli.ts check``node --test``node web/hwlab-cloud-web/scripts/check.mjs`、Playwright/browser smoke 或其他会遍历大仓库、启动浏览器、长时间占用 CPU/内存的校验命令。HWLAB 正式验证必须改在 issue/CLI 选中的 node/lane workspace、k3s/Tekton 或其他获批外部执行面完成;非 HWLAB 的 D601 服务仍按各自 reference 使用 D601 原生 k3s/CI runner。
- 镜像和编译产物必须通过标准 CI/CD 在外部构建资源上生成;HWLAB 使用 issue/CLI 选中的 node/lane 对应 k3s/Tekton/GitOps 或经过批准的外部 builder,非 HWLAB 服务按各自 reference 使用 D601 原生 k3s/Tekton 或其他获批外部 builder;源码以 Git remote 为 source of truthCI 产出 commit-pinned image/artifact。
- Prod 发布必须走 CD pull-only 流程:由 `deploy.json` 声明期望服务版本,生产侧 CD 拉取已经构建好的镜像或 artifact 并按 `deploy.json` 部署;禁止把 master server 本地 Docker image、临时容器层或本地编译产物作为部署真相。
- 在 master server 上只允许轻量源码编辑、Git 操作、状态/健康/日志/诊断、JSON CLI 控制面操作和受控 CD 观察;除 backend-core 主 server 上线受控例外外,一旦步骤需要构建镜像或编译 Rust/Go 等重型产物,必须停止在 master server 执行并改走 CI/CD 或 D601 构建路径。
@@ -246,7 +246,7 @@ UniDesk 是一个以主 server 为统一入口的分布式工作平台;本文
- `bun scripts/cli.ts commander contract|plan --dry-run|smoke --dry-run|approval request --dry-run`:查看 host Codex 指挥官直管微服务 skeleton 的 source summary、无 daemon smoke 验证计划、.state/commander/ 状态模型、trace summary 聚合和 ClaudeQQ 高风险请示草案;当前只返回 dry-run 计划和 backend-core `microservice proxy claudeqq` 授权后候选命令,不接 live bridge、不接管人工指挥官,不发送消息,AgentRun 派单边界由指挥官直接审查,规则见 `docs/reference/host-codex-commander.md`
- `bun scripts/cli.ts hwlab g14 retirement status|plan|execute --confirm`:受控退役 legacy G14 DEV/PROD Argo Application 和 namespace,并写本地退役 marker 记录执行证据;base=`G14` monitor 按退役合同固定阻止重启,`bun scripts/cli.ts hwlab g14 monitor-prs --lane v02|v03` 是当前 runtime lane PR 自动 CI/CD 入口,规则见 `docs/reference/g14.md``docs/reference/cli.md`
- `bun scripts/cli.ts agentrun control-plane status|trigger-current|refresh|cleanup-runs|cleanup-released-pvs [--dry-run|--confirm]`:通过 G14 route 只读观察、手动触发、刷新 Argo 或清理 AgentRun `v0.1` completed CI workspace retention,规则见 `docs/reference/agentrun.md``docs/reference/gc.md``docs/reference/cli.md`
- `bun scripts/cli.ts hwlab cd audit --env dev` / `status|preflight|apply --dry-run`:旧 D601 HWLAB DEV CD 指挥侧 wrapper,仅用于显式 legacy 诊断和迁移对照;当前 HWLAB runtime truth 已迁到 G14 runtime lane,规则见 `docs/reference/hwlab.md`
- `bun scripts/cli.ts hwlab cd audit --env dev` / `status|preflight|apply --dry-run`:旧 D601 HWLAB DEV CD 指挥侧 wrapper,仅用于显式 legacy 诊断和迁移对照;当前 HWLAB runtime truth 以 issue/CLI 选中的 node/lane 和 `config/hwlab-node-lanes.yaml` 为准,规则见 `docs/reference/hwlab.md`
- `bun scripts/cli.ts ci install/status/run/publish-backend-core/publish-user-service/run-dev-e2e/logs`:在 D601 原生 k3s 上安装和运行 Tekton CI,支持每 commit 检查、Code Queue 只读性能门禁、`CI.json` catalog 驱动的 backend-core 与 user-service commit-pinned 镜像发布和手动触发的 `origin/master:deploy.json#environments.dev` 临时 namespace e2ecatalog/producer/consumer 分工见 `docs/reference/cicd-standardization.md``run-dev-e2e` 的 Git 控制 runner、短 launcher 和 no-CD 边界见 `docs/reference/dev-ci-runner.md`Tekton 规则见 `docs/reference/ci.md`
- `bun scripts/cli.ts codex deploy <commitId>`:旧 Code Queue 兼容部署入口已禁用,原因是它会绕过受控部署边界直连 D601 部署 Code Queue;规则见 `docs/reference/codex-deploy.md`
- `bun scripts/cli.ts codex submit [prompt] [--prompt-file path|--prompt-stdin] [--queue <id>]` / `codex execution-plane [--full|--raw]` / `codex pr-preflight [--remote]``submit` 等旧写入口已冻结并返回 AgentRun 替代命令;`execution-plane` 通过 `trans D601:k3s` 只读观察 D601 原生 k3s 正式 Code Queue 执行面、旧 Compose 残留、commit/digest/worktree drift`pr-preflight` 只读检查 D601 scheduler/runner 的 GitHub token、egress 和 PR 能力,PR 型派单前必须使用,规则见 `docs/reference/cli.md``docs/reference/code-queue-supervision.md`
@@ -280,8 +280,8 @@ UniDesk 是一个以主 server 为统一入口的分布式工作平台;本文
- `docs/reference/staff-reference.md`:幕僚长期参考、决策过程和用户偏好摘要;与 `strategy-governance``code-queue-supervision` 配套。
- `docs/reference/secretary-reference.md`:秘书日程管理、时间盒、短期待办捕获和 Todo Note / Decision Center 分流规则。
- `docs/reference/code-queue-supervision.md`AgentRun Queue 与旧 Code Queue 指挥监督策略、并发窗口、轮询节奏、终态读取、阻塞拆分、PR handoff 和验收收口规则。
- `docs/reference/hwlab.md`HWLAB 指挥侧固定 workspace、G14 主运行面、D601 legacy/硬件桥接边界、最小 device-agent/gateway 桥接模型和受控发布边界。
- `docs/reference/g14.md`G14 provider 节点、k3s 控制桥、legacy DEV/PROD 退役边界、当前 HWLAB runtime lane、device-agent 手动实验边界、Code Queue/CI 候选目标和节点本地 VPN proxy bootstrap 边界。
- `docs/reference/hwlab.md`HWLAB 指挥侧 node/lane 目标解析、D601 v0.3 与显式 legacy 边界、最小 device-agent/gateway 桥接模型和受控发布边界。
- `docs/reference/g14.md`G14 provider 节点、k3s 控制桥、legacy DEV/PROD 退役边界、G14 target 的 HWLAB runtime lane、device-agent 手动实验边界、Code Queue/CI 候选目标和节点本地 VPN proxy bootstrap 边界。
- `docs/reference/pk01.md`PK01 腾讯云 provider-gateway、pikanode/MET Docker workload、SSH 透传、磁盘 GC 和 pikanode temp 长效 retention 边界。
- `docs/reference/yaml-first-ops.md`YAML-first 异构分布式运维架构、现有 YAML 归属优先、公共 ops 层抽取、禁止硬编码 node/service 和薄 domain CLI 规则。
- `docs/reference/platform-infra.md`G14 `platform-infra` namespace、YAML-first shared service 配置、YAML-controlled Secret distribution/no runtime reverse inference、Sub2API/Codex pool、WeChat archive / D601 WeChatFerry read-only upstream、FRP 暴露和 on-demand availability probe 开发边界;Sub2API 日常操作统一见 `$unidesk-sub2api``.agents/skills/unidesk-sub2api/SKILL.md`)。