docs: sync v02 cicd source isolation

2026-06-01 07:39:05 +08:00
parent 84c49afe53
commit 61f58de2d9
7 changed files with 19 additions and 18 deletions
@@ -23,7 +23,7 @@
 - 常规 runner 和指挥官工作区是 `/workspace/hwlab`。
 - 进入仓库先检查分支和工作树状态。
 - G14 人工/指挥官开发必须先在固定 repo `/root/hwlab` 做 `pwd`、`git status --short --branch`、`git remote -v` 和 `fetch` 预检，再在 `/root/hwlab/.worktree/<task>` 从最新 `origin/G14` 创建任务专属 worktree；代码、文档、测试补丁、提交和 PR 准备都在该独立 worktree 中完成。
- G14 `v0.2` 固定 workspace 是 `/root/hwlab-v02`，固定跟踪 `origin/v0.2`。所有 `v0.2` 文档、计划、CI/CD lane 和 namespace 设计必须在该 workspace 或其明确创建的 `v0.2` worktree 中完成；不得使用 `/root/hwlab` 根目录或现有 `hwlab-dev`/`hwlab-prod` 运行面作为 `v0.2` scratch 区。
+- G14 `v0.2` 固定开发 workspace 是 `/root/hwlab-v02`，固定跟踪 `origin/v0.2`。所有 `v0.2` 文档、计划、CI/CD lane 和 namespace 设计必须在该 workspace 或其明确创建的 `v0.2` worktree 中完成；不得使用 `/root/hwlab` 根目录或现有 `hwlab-dev`/`hwlab-prod` 运行面作为 `v0.2` scratch 区。CI/CD source commit 选择只使用 `/root/hwlab-v02-cicd.git` 自动 fetch 后的 commit-pinned detached worktree，不能因为 `/root/hwlab-v02` dirty、stale 或存在 `.worktree/` 就阻塞或改变发布。
 - 固定 repo `/root/hwlab` 是 source truth 和 worktree 管理入口，不是并行任务 scratch 区；不要在固定 repo 根目录堆叠未提交改动，也不要复用其他任务遗留 `.worktree/<task>`。
 - D601 `/home/ubuntu/workspace/hwlab` 只作为 legacy 事故回放和迁移对照工作区；当前 G14 DEV/PROD 与 `v0.2` 发布、rollout 和验收不使用 D601 作为运行面真相。
 - 不要清理、reset 或复用无关 runner worktree 作为发布真相。
@@ -36,7 +36,7 @@ master hwlab-frps-dev :19666/:19667

 G14 PROD is rendered by GitOps as namespace `hwlab-prod` and Argo CD application `hwlab-g14-prod`; it uses the `:18666/:18667` public endpoints when enabled. G14 desired state is generated into `deploy/gitops/g14/runtime-dev` and `deploy/gitops/g14/runtime-prod` and promoted through the `G14-gitops` branch.

-G14 `v0.2` is an additive lane, not a replacement for DEV or PROD. It uses source branch `v0.2`, fixed workspace `G14:/root/hwlab-v02`, namespace `hwlab-v02`, and public ports `19666/19667`. The `v0.2` GitOps branch, runtime path and Argo Application must be distinct from DEV/PROD before any automated rollout is enabled.
+G14 `v0.2` is an additive lane, not a replacement for DEV or PROD. It uses source branch `v0.2`, fixed development workspace `G14:/root/hwlab-v02`, dedicated CI/CD source repo `G14:/root/hwlab-v02-cicd.git`, namespace `hwlab-v02`, and public ports `19666/19667`. The `v0.2` GitOps branch, runtime path and Argo Application must be distinct from DEV/PROD before any automated rollout is enabled.

 ## G14 k3s Source Of Truth

@@ -52,7 +52,7 @@ Do not use D601 kubeconfig, D601 `dev-cd-apply`, old JS `ci-publish`, Docker Des

 ## Branch Role Boundary

-Current runtime work uses explicit branch lines: G14 DEV/PROD uses `origin/G14`, and the additive `v0.2` lane uses `origin/v0.2` plus `hwlab-v02`. Do not merge `origin/main` as a routine precondition for G14 or `v0.2` runtime work. Treat `main` only as a historical branch-governance or D601 legacy reference unless a current issue explicitly assigns a `main` migration task. The `v0.2` lane remains separate from G14 DEV/PROD; its CI/CD branch, runtime path and acceptance rules are authoritative in [spec-v02-cicd.md](spec-v02-cicd.md).
+Current runtime work uses explicit branch lines: G14 DEV/PROD uses `origin/G14`, and the additive `v0.2` lane uses `origin/v0.2`, `/root/hwlab-v02-cicd.git`, `devops-infra` git mirror/relay and `hwlab-v02`. Do not merge `origin/main` as a routine precondition for G14 or `v0.2` runtime work. Treat `main` only as a historical branch-governance or D601 legacy reference unless a current issue explicitly assigns a `main` migration task. The `v0.2` lane remains separate from G14 DEV/PROD; its CI/CD branch, runtime path and acceptance rules are authoritative in [spec-v02-cicd.md](spec-v02-cicd.md).

 ## Distributed Passthrough Hygiene

@@ -32,7 +32,7 @@ G14 Tekton 日志中的分段耗时统一使用 JSON 行事件：`event="g14-cic

 ## 当前基线

-当前 G14 pipeline 已具备关键架构优化：一分钟 source polling、组件级 lazy build、per-service fan-out、G14 本地 registry、本地 base image、BuildKit-only publish、GitOps/Argo 分离。`v0.2` 进一步引入手动 CLI trigger、`devops-infra` git mirror 只读路径、env image 复用和 code-only boot commit rollout。剩余耗时主要集中在固定开销、GitOps promotion、runtime-ready 等待和镜像构建机制上。
+当前 G14 pipeline 已具备关键架构优化：一分钟 source polling、组件级 lazy build、per-service fan-out、G14 本地 registry、本地 base image、BuildKit-only publish、GitOps/Argo 分离。`v0.2` 进一步引入手动 CLI trigger、专用 CI/CD source repo、`devops-infra` git mirror/relay 读写路径、env image 复用和 code-only boot commit rollout。剩余耗时主要集中在固定开销、GitOps promotion、runtime-ready 等待和镜像构建机制上。

 ## v0.2 实测对比

@@ -50,15 +50,15 @@ G14 Tekton 日志中的分段耗时统一使用 JSON 行事件：`event="g14-cic

 git mirror 本身不是 50 秒级瓶颈。集群内临时 pod 对 `http://git-mirror-http.devops-infra.svc.cluster.local/pikasTech/HWLAB.git` 的早期实测结果为：`git ls-remote refs/heads/v0.2` P50 约 19ms，`git clone --no-checkout` P50 约 787ms，`git checkout --detach` P50 约 64ms。修复 atomic/manual sync 后，对已发布 commit 的 `git ls-remote` 为 49-53ms，`git cat-file <commit>^{tree}` 为 40-43ms。Tekton `prepare-source` 的 37-65s wall time 是混合耗时，包含 entrypoint/PVC/workspace 启动、proxy/npm probe、source clone、GitOps catalog 读取、`npm ci` 和脚本收尾，不能直接归因给 mirror。

-已观测的 prepare-source 内部分段：source clone 经 mirror 后约 0.9-1.1s；GitOps catalog 读取若仍走 canonical GitHub SSH 约 9s；catalog lookup/fetch 改走 mirror 后，`catalog-ls-remote` 为 47-58ms，`catalog-fetch` 为 92-113ms，`catalog-fetch` JSON timing 总计 277-348ms；`npm ci --ignore-scripts` 约 15-18s；剩余为 Tekton entrypoint、PVC/workspace、探针和 shell/Node 启动固定开销。只读 catalog lookup/fetch 与 source clone 一样走 `git-read-url` mirror；GitOps promotion push 仍必须走 canonical GitHub remote。
+已观测的 prepare-source 内部分段：source clone 经 mirror 后约 0.9-1.1s；GitOps catalog 读取若仍走 canonical GitHub SSH 约 9s；catalog lookup/fetch 改走 mirror 后，`catalog-ls-remote` 为 47-58ms，`catalog-fetch` 为 92-113ms，`catalog-fetch` JSON timing 总计 277-348ms；`npm ci --ignore-scripts` 约 15-18s；剩余为 Tekton entrypoint、PVC/workspace、探针和 shell/Node 启动固定开销。只读 catalog lookup/fetch 与 source clone 一样走 `git-read-url` mirror；`v0.2` GitOps promotion 写入 `devops-infra` 本地 mirror/relay，GitHub flush 异步完成，不在 CI 关键路径直接 push canonical remote。

-`devops-infra` git mirror sync 是写侧刷新成本，不是 CI 读路径成本。mirror 不设 CronJob，标准入口是 `bun scripts/cli.ts hwlab g14 git-mirror sync --confirm` 手动创建一次性 Job；旧 `git-mirror-hwlab-sync` CronJob 已删除。2026-05-29 的最终手动 sync 样本中，Job 脚本内 total 为 12.1s，其中 GitHub fetch 4.6s、object closure validate 6.0s、publish update-ref 1.1s、fsck 0.12s；UniDesk route 从创建 Job 到返回日志总计约 18.9s。这个 12-19s 不代表 mirror clone 速度，而是 GitHub SSH fetch、对象校验、Kubernetes Job 启动/轮询和日志采集的总成本。
+`devops-infra` git mirror sync/flush 是 mirror 边界维护成本，不是 CI 读路径成本。mirror 不设 CronJob，`trigger-current --lane v02` 会在创建 PipelineRun 前按需执行一次 bounded pre-sync；`bun scripts/cli.ts hwlab g14 git-mirror sync --confirm` 和 `git-mirror flush --confirm` 只作为显式 mirror 维护或诊断入口。代表性手动 sync 样本中，Job 脚本内 total 为 12.1s，其中 GitHub fetch 4.6s、object closure validate 6.0s、publish update-ref 1.1s、fsck 0.12s；UniDesk route 从创建 Job 到返回日志总计约 18.9s。这个 12-19s 不代表 mirror clone 速度，而是 GitHub SSH fetch、对象校验、Kubernetes Job 启动/轮询和日志采集的总成本。

 当前滚动基线量级：

 | 阶段 | 典型范围 | 说明 |
 | --- | --- | --- |
-| Source trigger | 0-60s | poller 每分钟运行一次；平均等待应接近 30s。 |
+| Source trigger | 0-60s 或手动触发开销 | G14 poller 每分钟运行一次，平均等待应接近 30s；`v0.2` 不设 poller，由 UniDesk 手动 trigger 自动 fetch 专用 CI/CD repo 并按需 pre-sync mirror。 |
 | `prepare-source` | 37-175s | source+catalog mirror 的 code-only 样本为 37-38s；旧路径、多 build 或未优化样本可到 75-175s。当前主要固定成本已转为 Tekton/PVC/entrypoint 和 `npm ci`。 |
 | Primitive validation | 每项 5-10s | source 准备后并行运行，目前不是主要瓶颈。 |
 | `plan-artifacts` | 6-10s | 当前可接受，重点是保持只读和确定性。 |
@@ -126,7 +126,7 @@ retention cleaner 会删除超过保留窗口的 completed PipelineRuns，但近
 | P0 | 构建并使用包含 production `node_modules`、Codex package 和平台专用 Codex binary 的 runtime base image。 | 减少服务镜像重复依赖工作。fast build 维持约 20-35s；heavy build 从 120-220s 降到约 45-90s；full rebuild 预计节省 1-3m。 |
 | P0 | 为服务镜像增加生成式 `.dockerignore` 或 pruned BuildKit context，排除 `.git`、prepared `node_modules`、无关 generated files 和可排除的无关 service directories。 | 降低 context transfer 和 cache invalidation。小型 build 预计节省 10-40s，heavy build 预计节省 30-90s，同时降低磁盘压力。 |
 | P1 | 将 unchanged services 从 BuildKit-shaped tasks 拆出。可让 `plan-artifacts` 直接输出 catalog-backed service results，或给 reused service 使用无 sidecar 的轻量 task，changed services 保持 BuildKit。 | reuse-only 和 single-component fan-out 预计节省 10-30s，并显著减少 sidecar/pod 噪声；主要收益是稳定性和可观测性。 |
-| P1 | 优化 `gitops-promote`：对 `G14-gitops` 使用 shallow/sparse checkout，复用已 render 的输出做 check，避免复制或提交未变化的 generated paths。 | 将 `gitops-promote` 从 50-105s 降到约 20-45s。每轮 promotion 预计节省 30-60s。 |
+| P1 | 优化 `gitops-promote`：G14 DEV/PROD 对 `G14-gitops` 使用 shallow/sparse checkout；`v0.2` 对 `devops-infra` mirror/relay 使用最小写入，并复用已 render 的输出做 check，避免复制或提交未变化的 generated paths。 | 将 `gitops-promote` 从 50-105s 降到约 20-45s。每轮 promotion 预计节省 30-60s。 |
 | P1 | GitOps push 成功后触发 Argo hard refresh，再用短轮询观察 sync。 | 当 workload 本身健康时，CI succeeded 到 DEV Healthy 从 10-220s 降到约 10-60s。 |
 | P1 | 扩展 failed-run retention：给 failed PipelineRuns 和 orphan Error pods 设置明确的短保留窗口，同时禁止删除 active PipelineRuns 和 runtime namespaces。 | 对 pipeline 直接加速有限，但能显著降低 bad-run burst 后的诊断噪声和 API/list 噪声。 |
 | P2 | 保持一分钟 polling，除非 source-trigger wait 成为主瓶颈；在固定开销降低前不要优先引入 GitHub webhook 复杂度。 | 理论平均最多节省约 30s；当前收益低于 `prepare-source`、BuildKit 和 GitOps promotion。 |
@@ -178,7 +178,7 @@ retention cleaner 会删除超过保留窗口的 completed PipelineRuns，但近

 - Source commit 仍是唯一 artifact identity。
 - 镜像仍使用 commit tag 和 digest 作为发布身份。
- `G14-gitops` 仍是 Argo CD 消费的 desired-state truth。
+- G14 DEV/PROD 的 `G14-gitops` 或 `v0.2` 的本地 mirror/relay `v0.2-gitops` 仍是 Argo CD 消费的 desired-state truth。
 - Unchanged services 不会因为全局 source commit 变化而滚动。
 - Failed/stale PipelineRun cleanup 不触碰 `hwlab-dev`、`hwlab-prod`、Argo runtime state、registry storage 或 active PipelineRuns。
 - Runtime success 仍由 Argo Application revision、workload readiness 和必要公网 health 证明。
@@ -8,7 +8,7 @@ G14 是 HWLAB 当前 DEV/PROD 原生 k8s 与 GitOps 运行面目标。G14 CI/CD
 - CI：Tekton 在 G14 k3s 内运行 `hwlab-g14-ci-image-publish` Pipeline，由 `scripts/g14-gitops-render.mjs` 直接生成原生 task；最小校验固定为 `repo-reports-guard`、`g14-contract-check`、`codex-api-forwarder-check`，随后按 component plan 做 per-service BuildKit publish 与 GitOps promote；没有 `CI.json` runner、DIND 单任务发布或 Docker fallback。
 - Artifact：镜像使用 commit tag，例如 `127.0.0.1:5000/hwlab/hwlab-cloud-api:<shortCommit>`；digest 由 registry 返回，CI report 只作为审计证据，不作为 CD 真相。发布态 artifact catalog 由 Tekton 写入 `G14-gitops:deploy/artifact-catalog.dev.json`。
 - Branch split：`G14` 是源码监控分支，只保存人写源码、声明和 seed contract；`G14-gitops` 是 Tekton promotion 写入的生成分支，保存 `deploy/artifact-catalog.dev.json` 与 `deploy/gitops/g14/**` desired state。CI/CD 不再把 catalog promotion commit 写回 `G14`。
- v0.2 扩容线：`v0.2` 必须从当前 `G14` fork 出来，并以 `G14:/root/hwlab-v02` 作为固定 source workspace、`hwlab-v02` 作为固定 runtime namespace。`v0.2` CI/CD 只能作为新增 lane 接入现有 G14 Tekton/Argo 体系，不得改写、删除、暂停或重定向现有 `G14` poller、`G14-gitops` DEV/PROD desired state、`hwlab-dev` 或 `hwlab-prod`；详细规格见 [spec-v02-cicd.md](spec-v02-cicd.md)。
+- v0.2 扩容线：`v0.2` 必须从当前 `G14` fork 出来，并以 `G14:/root/hwlab-v02` 作为固定开发 workspace、`G14:/root/hwlab-v02-cicd.git` 作为固定 CI/CD source repo、`hwlab-v02` 作为固定 runtime namespace。`v0.2` CI/CD 只能作为新增 lane 接入现有 G14 Tekton/Argo 体系，不得改写、删除、暂停或重定向现有 `G14` poller、`G14-gitops` DEV/PROD desired state、`hwlab-dev` 或 `hwlab-prod`；详细规格见 [spec-v02-cicd.md](spec-v02-cicd.md)。
 - CD：Argo CD 只消费 `G14-gitops:deploy/gitops/g14/runtime-dev` 与 `deploy/gitops/g14/runtime-prod` 的 Git desired state，不重新构建镜像，不读取 D601 状态，不获取 legacy DEV CD Lease。
 - FRP：G14 DEV 通过 `hwlab-dev/hwlab-g14-frpc` 暴露 `17666/17667`，G14 PROD 通过 `hwlab-prod/hwlab-g14-prod-frpc` 暴露 `18666/18667`；`v0.2` 规划通过 `hwlab-v02` 内独立 frpc 暴露 `19666/19667`。master frps 的 `deploy/frp/frps.dev.toml` 与实际 `/etc/frp/frps.toml` 必须放行对应端口，但 `v0.2` 放行只能新增 19xxx 入口，不能复用或覆盖 DEV/PROD 入口。
 - 并行性：不同 source commit 的 CI build 不共享发布锁；并行安全由 immutable commit tag/digest 和 Git desired state 保证。最终运行版本由 Argo CD 当前同步的 Git revision 决定。
@@ -19,7 +19,7 @@ G14 是 HWLAB 当前 DEV/PROD 原生 k8s 与 GitOps 运行面目标。G14 CI/CD

 旧 DEV/D601/main 门禁如果阻碍当前 G14 或 `v0.2` 路径，默认处理是从当前调用链删除，而不是做兼容性迁移、fallback、legacy mode、双路径绕行或在旧门禁上叠加例外。新增门禁只能覆盖明确高价值风险，且必须最小、低噪声、容易删除；资源配额、RBAC 命名、清理策略、回滚顺序、人工同步策略等默认是设计约定或 runbook，不是 CI/CD 通过条件。

-`v0.2` 的硬边界只包括：source branch 必须是 `v0.2`，GitOps branch 必须是 `v0.2-gitops`，runtime namespace 必须是 `hwlab-v02`，runtime path 必须是 `deploy/gitops/g14/runtime-v02`，Argo Application 必须指向 `v0.2` GitOps lane，公网入口只能是 `19666/19667`，`v0.2` source branch 不跟踪生成物，旧 DEV/D601/main 门禁不进入 `v0.2` 调用链。其他事项先写成决策表或 runbook；只有被证明无法靠上述边界和标准入口自然收敛时，才允许新增最小检查。
+`v0.2` 的硬边界只包括：source branch 必须是 `v0.2`，CI/CD source repo 必须是 `/root/hwlab-v02-cicd.git`，GitOps branch 必须是 `v0.2-gitops`，Git mirror/relay 必须来自 `devops-infra`，runtime namespace 必须是 `hwlab-v02`，runtime path 必须是 `deploy/gitops/g14/runtime-v02`，Argo Application 必须指向 `v0.2` GitOps lane，公网入口只能是 `19666/19667`，`v0.2` source branch 不跟踪生成物，旧 DEV/D601/main 门禁不进入 `v0.2` 调用链。其他事项先写成决策表或 runbook；只有被证明无法靠上述边界和标准入口自然收敛时，才允许新增最小检查。

 ## 生成入口

@@ -132,7 +132,7 @@ DeepSeek proxy manifest 是 GitOps desired state 的一部分，DEV/PROD 分别

 G14 不要求 GitHub webhook 或 GitHub Actions 配置。`hwlab-ci/hwlab-g14-branch-poller` CronJob 每 1 分钟通过 Git SSH 拉取 `G14` HEAD，并用 source commit 的前 12 位生成 PipelineRun 名称 `hwlab-g14-ci-poll-<short12>`。

-`v0.2` 接入不再新增 HWLAB 发布触发 CronJob；标准入口是 UniDesk CLI `bun scripts/cli.ts hwlab g14 control-plane trigger-current --lane v02 --confirm`，由该入口解析当前 `origin/v0.2` HEAD 并直接创建可区分的 commit-pinned PipelineRun，例如 `hwlab-v02-ci-poll-<short12>`。该 lane 的 GitOps promotion 只允许写入 `v0.2` 专属 catalog、runtime path 和 GitOps branch；不得向 `G14` 或现有 DEV/PROD runtime path 写入生成物。
+`v0.2` 接入不再新增 HWLAB 发布触发 CronJob；标准入口是 UniDesk CLI `bun scripts/cli.ts hwlab g14 control-plane trigger-current --lane v02 --confirm`，由该入口自动 fetch `/root/hwlab-v02-cicd.git`、解析当前 `origin/v0.2` HEAD，并直接创建可区分的 commit-pinned PipelineRun，例如 `hwlab-v02-ci-poll-<short12>`。该 lane 的 GitOps promotion 只允许写入 `v0.2` 专属 catalog、runtime path 和 GitOps branch；不得向 `G14` 或现有 DEV/PROD runtime path 写入生成物，也不得从 `/root/hwlab-v02` 工作树状态选择待发布 commit。

 G14 lane 中如果同名 PipelineRun 已存在，poller 直接跳过；如果不存在，则创建新的 PipelineRun。这样可以用 Kubernetes 原生 CronJob、ServiceAccount、RBAC 和 Tekton API 实现无 GitHub webhook 的分支监控，同时避免同一个 commit 被反复派单。历史上的 `chore: promote G14 GitOps source ...` source 分支生成提交已经废弃；G14 poller 只应该看到人写 source commit。

@@ -38,7 +38,7 @@ CI/CD 内部由 UniDesk 手动触发入口、CI/CD 专用 source repo、devops-i
 | 对象 | v0.2 规格 |
 | --- | --- |
 | Source branch | `v0.2` |
-| Source workspace | `G14:/root/hwlab-v02`，仅用于人工开发、短连接源码工具和可见性对照，不作为 CI/CD source commit 选择入口 |
+| Development workspace | `G14:/root/hwlab-v02`，仅用于人工开发、短连接源码工具和可见性对照，不作为 CI/CD source commit 选择入口 |
 | CI/CD source repo | `G14:/root/hwlab-v02-cicd.git` bare repo，由 UniDesk control-plane 自动 fetch `origin/v0.2`，再从 commit-pinned detached worktree render/apply 控制面 |
 | GitOps branch | `v0.2-gitops` |
 | Artifact catalog | `v0.2-gitops:deploy/artifact-catalog.v02.json` |
@@ -69,7 +69,7 @@ CI/CD 内部由 UniDesk 手动触发入口、CI/CD 专用 source repo、devops-i
 4. devops-infra mirror/relay 中的 GitOps branch：`v0.2-gitops` 中的 `deploy/artifact-catalog.v02.json` 与 `deploy/gitops/g14/runtime-v02/**`。
 5. Tekton 执行证据：UniDesk `trigger-current` 返回的 PipelineRun、TaskRun result、`gitops-promote` 终态。
 6. GitHub 上游归档状态：mirror/relay flush 后的 `origin/v0.2-gitops` 与 `origin/v0.2`。
-7. 固定 source workspace：`/root/hwlab-v02` 的 `HEAD`、dirty 状态和 `origin/v0.2` 只作为人工开发对照线索；即使 workspace 脏或落后，也不得影响 CI/CD source commit 选择。
+7. 固定开发 workspace：`/root/hwlab-v02` 的 `HEAD`、dirty 状态和 `origin/v0.2` 只作为人工开发对照线索；即使 workspace 脏或落后，也不得影响 CI/CD source commit 选择。

 旧 commit 记忆、`G14`/`G14-gitops` DEV/PROD 产物、D601 legacy 路径、GitHub 上游尚未 flush 的短暂落后、source branch 中历史 generated 文件、固定开发 workspace 脏状态和临时 worktree 只能作为线索，不能作为 `v0.2` 发布通过证据。

@@ -35,7 +35,7 @@
 ## D601/G14 口径处理

 - 当前 HWLAB DEV/PROD 真相是 G14 k3s、`G14`/`G14-gitops` 和 `hwlab-dev`/`hwlab-prod`。
- `v0.2` 真相是 `origin/v0.2`、`v0.2-gitops`、`hwlab-v02` 和 `19666/19667`，权威规格见 [spec-v02-cicd.md](spec-v02-cicd.md)。
+- `v0.2` 真相是 `origin/v0.2`、`/root/hwlab-v02-cicd.git`、`devops-infra` git mirror/relay、`v0.2-gitops`、`hwlab-v02` 和 `19666/19667`；`/root/hwlab-v02` 只作为人工开发和短连接源码工具 workspace，权威规格见 [spec-v02-cicd.md](spec-v02-cicd.md)。
 - D601 只允许作为 legacy 事故回放、迁移对照或 Windows 硬件 bridge 背景出现在长期参考中；不得作为当前 `v0.2` 发布、验收或权限规格。
 - 任何根文档或计划文档如果仍把 D601、旧 DEV gate、旧 `main`、旧 `16666/16667` 或 simulator/patch-panel 写成当前规格，应删除或改为引用新 spec。